协作 AI 进入团队几个月，最直接的体感是：工具能力的上限，远高于实际产出的提升幅度。原因不在 AI，在我们用它的方式。

下面几条是这段时间踩出来的经验，分享给团队。

提需求是一项独立技能

AI 实现的速度变快之后，瓶颈就从”敲代码”挪到了”想清楚”。一个含糊的需求跑三轮试错的时间，比花十分钟把需求写清楚要长得多。

每次开新对话之前，先用几行写明白：要做什么、输入输出是什么、约束是什么、怎么算完成。这一步看着笨，但稳。灵感型 prompt 是消耗品，跑一次就废；写清楚的需求是资产，能沉淀进 skill 反复用。

任务要分级再交给 AI

不是所有事都适合让 AI 全自动。我大概按三层来分。

最底下是重复活：commit 信息、版本号、changelog、模板代码这种。没什么判断空间，交给 skill 跑就行，越自动越好。

往上一层是工程判断——架构选型、命名、抽象边界。这一层让 AI 列几个选项加利弊是合适的，但选哪个得人来定。能讲清为什么选这个，本来就是工程师的本职。

最上面一层，是和业务、用户、产品场景强相关的判断。这一类不要交给 AI 主导。AI 只能基于你给的信息拟合，对真实场景没有体感——它不知道某个客户上次抱怨过什么，也不知道下个季度方向会变。

最大的隐患就是把这一层交出去。判断外包久了，能力会萎缩，而且自己感觉不到。

主 session 是协调，不是执行

实际工作流里，一个 session 通常扮演协调者：通过 skill 把任务分发给不同 agent，每个 agent 在自己干净的上下文里干活。这套架构的稳定性，取决于两件事。

一是 skill 的设计质量。skill 是协议层，写糙了下面所有 agent 都会歪。一个好 skill 应该把”做什么、输入是什么、输出是什么、怎么算完”写死，agent 拿到能直接跑，不需要回主 session 来回问。skill 越像一份接口契约，整个流水线越稳。

二是主 session 自己的克制。协调者一旦开始下场写代码，整个架构就破了——你既要协调又要实现，注意力分裂，agent 也用不好。主 session 该不该写代码，是一条很容易越过、但越过就有代价的边界。

没有数据就别谈提效

“AI 让我效率提升了 X 倍”这种话基本没意义，除非有数据。

最简单的办法是在任务记录里加三列：AI 估时、实际时长、不用 AI 估时。一个月后回头看，真正提效的任务往往不是你以为的那些。很多时候 AI 反而更慢——因为人在反复修需求。

配置会膨胀

.claude/ 下的 rules、skills、agents 是会膨胀的。每次踩坑都想加一条规则，半年后规则比代码还多，新人接入成本会高得吓人。

每条规则要标清来源：哪个项目、哪个场景、是不是通用。定期 review，把过期的删掉。配置膨胀是 AI 时代特有的技术债，比代码债更隐蔽。

最大的隐患不是 AI 不够强，是把工具当目的、把方法论当成果。

AI 协作走到现在，比”能不能用”更重要的，是”知道什么时候不用”。