如果 AI 在同一个项目里反复犯同一种错，问题通常不只是模型。

可能是任务合同不清楚，context package 缺了关键文件，停工条件没有写，测试没有覆盖，证据门禁太弱，或者项目规则只停留在聊天记录里。

项目专用 AI 交付流水线最后一层，是 feedback and knowledge capture。

不要只在聊天里纠正 AI

很多人会在聊天里告诉 AI：“下次不要这样。”

这几乎等于没有沉淀。

下一次换一个会话、换一个工具、换一个模型、换一个项目目录，这条经验很可能消失。即使同一个模型记得，也不一定知道这条经验适用于哪个项目、哪个场景、哪个文件范围。

真正的项目记忆应该进入项目机制。

失败应该被分类

每次失败之后，先不要急着写规则。先判断失败属于哪一类：

  • 需求不清；
  • 上下文错误；
  • 真相源错误；
  • 权限过大；
  • 工具调用缺保护；
  • 测试缺失；
  • 证据缺失；
  • 发布边界混乱；
  • source-specific 经验被错误泛化；
  • 项目规则没有被 AI 读取。

分类之后，才知道应该修哪里。

经验可以沉淀到不同层

不是所有经验都应该写成 skill。

有些应该进入 issue template，因为它影响任务入口。

有些应该进入 AGENTS.md，因为它是项目全局规则。

有些应该进入 skill，因为它是特定工作流。

有些应该进入测试或 fixture，因为它应该由机器验证。

有些应该进入 evidence gate，因为它是完成标准。

有些应该进入脚本，因为靠文字提醒不够。

有些只应该留在项目本地，不能晋升中央知识库。

有些足够通用，才适合晋升为中央知识。

skill 不是垃圾桶

skill 很容易变成另一个混乱文档夹。

如果每次 AI 犯错都往 skill 里加一句话，最后 skill 会越来越长、越来越矛盾、越来越难触发。

好的规则应该尽量放到最窄、最可验证的位置。

如果是代码行为，用测试。
如果是执行流程，用脚本或 state machine。
如果是任务填写规范，用 issue template。
如果是项目通用边界，用 AGENTS.md。
如果是某类任务的操作手册，用 skill。
如果是跨项目方法论，用中央知识库。

中央知识库的角色

中央知识库不应该接管每个项目的全部细节。

它应该沉淀跨项目稳定模式：任务合同、证据合同、项目上下文包、动态 skill 生命周期、publication boundary、release boundary 等。

项目本地保留项目事实、私有材料、source-specific interpretation 和具体实现细节。

这样中央知识库提供方法，项目流水线保留执行权。

结论

AI 交付流水线不应该只是执行一次任务。它应该从每次任务里学习项目如何更好地使用 AI。

重复失败不能只变成一句抱怨。它应该变成更好的合同、更准的上下文、更强的证据、更窄的权限、更明确的门禁，或者更可靠的项目规则。

这才是流水线比聊天强的地方：它能把一次经验变成下一次的结构。