别每次都从头交代：把 AI 协作沉淀成可复用的"资产"

一、被低估的成本：重复交代

用 AI 编程助手久了，你会发现一个很隐蔽的消耗：你一直在重复交代同一件事。

新开一个会话，它不认识你的项目；换个任务，它又忘了你的偏好；同一个项目里，今天告诉它"测试用 Vitest"、明天还得再说一遍。模型本身没有跨会话的长期记忆，你不写下来，它就永远从零开始。

单次看起来没什么，累积起来却相当可观——更糟的是，同一个要求每次说得不一样，AI 给出的结果也会飘。

所以真正值得投入的，不是"再快一点写代码"，而是把那些反复出现的东西，从口头交代变成可复用的资产。

二、沉淀的三个层次

我把它分成三层，从轻到重：

1. 项目级规则。 把"这个项目必须怎么做"固化成文件——技术栈、目录约定、构建与测试命令、哪些生成物要排除、哪些文件不许动。放进项目根的规则文件里，AI 每次进项目都能读到。这一层成本最低，收益却最直接：新人（和 AI）的冷启动时间会明显缩短。

2. 高频指令模板。 对经常重复的诉求，把措辞固定下来。与其每次重新组织语言，不如留一句"标准说法"，需要时直接复用。它的价值不只是省事，更在于让同一类任务的输入保持一致，输出自然更稳。

3. 技能（Skill）：把一整条工作流封装起来。 当某类任务不是"一句话"，而是"一串有先后顺序、有验收标准的步骤"时，就值得把它做成技能——写清触发条件、执行步骤、验收标准和边界。之后你只需抛出一个意图，它就会按固定套路走完，而不是每次自由发挥。

三、什么该沉淀：三次法则

不是所有东西都值得沉淀。我的判断标准很简单：同一件事出现第三次，就动手把它固化下来。

• 出现一次两次，可能是偶发，别急着抽象；
• 反复出现，说明它是这个项目/这位使用者的"稳定规律"，值得沉淀；
• 沉淀的对象应该是稳定的规矩，而不是一次性的任务——把某次具体改动写进规则，是污染，不是沉淀。

一句话：沉淀"怎么做"，别沉淀"做了什么"。

四、收益，以及代价

沉淀的收益很直接：冷启动更快、多人协作时大家用同一套规矩、AI 输出更可控。

但代价容易被忽略——资产是会腐坏的。

• 规则和现实分叉。 代码改了、依赖换了，规则文件却没更新，慢慢就没人信它了。
• 写太多反而稀释重点。 规则堆成一篇长文，AI 抓不住关键，人也懒得读。重点越少越锋利的规则，越有效。
• 重复与冲突。 我最实际的一次教训是：同一件事被写在三个地方，改了一个、忘了另外两个，结果不同文件互相打架，人和 AI 都无所适从。

所以沉淀不是"写得越多越好"，而是定期精简、去重、对齐——这件事得人来牵头，AI 不会主动帮你清理过期规则，除非你明确让它做。

五、几条边界

• 别什么都装进规则。 一次性的、易变的、强依赖个人临时偏好的，都不适合沉淀，硬塞只会制造噪声。
• 沉淀要"可执行"才有意义。 能对应到命令、模板、检查清单的规则才算数；只是一段读起来很舒服的文字，多半会被忽略。
• 它和"让 AI 读懂代码"是两件事。 代码库知识解决的是"这个项目长什么样"，而协作资产解决的是"你要 AI 怎么做"。前者喂给 AI 理解，后者喂给 AI 执行——互补，但不能互相替代。

结语

AI 的"记忆"其实攥在你手里。你不写，它就每次都从零开始；你写下来、并且持续维护，它才真正变成团队的一部分。

从"每次口头交代"到"一次沉淀、反复复用"，这就是从"会用一个大模型"走向"把 AI 用成一套体系"的那一步。省下的不只是重复的废话，更是输出质量的稳定性——而这恰恰是协作里最贵的东西。