AI agent 写代码越来越像样，但管理 AI agent 协作开发，至今没有成熟方案。Clowder AI（猫咖）项目的 feat-lifecycle skill 是我读过的最认真的一次尝试：600 行 Markdown，把一个功能从立项到收尾的完整流程写成了制度，而且几乎每条规则后面都标着它来自哪次翻车。
这个项目的背景值得交代一下：多个 AI agent（项目里叫「猫」）在一个人类负责人（operator）指挥下协作开发。人管人可以靠默契，人管 AI 只能靠白纸黑字。这份 skill 就是那套白纸黑字的核心。
读完整份文件，我觉得它本质上在对抗 AI agent 的三个顽疾。下面按这三个问题展开，每个问题只挑最有启发性的设计来讲。
第一个问题：重复造轮子
AI agent 有个致命习惯——接到任务就开干，不检查有没有人做过类似的事。人类开发者也会犯这个毛病，但人至少有组织记忆（开过的会、聊过的天、review 过的 PR），AI 没有。
这份 skill 的解法是在立项阶段设了两道强制检查。
第一道：记忆检索。 在动手之前，先搜项目的记忆系统（索引了 400 多份文档和历史讨论摘要），看有没有相关上下文。
第二道：关联检测。 扫描已有的 feature 文档和 BACKLOG，按结果分流——已有 feature 的子任务就挂上去，不新开；相关需求标关联让 maintainer 判断；太小的 enhancement 不立项。
这两道检查的触发点我觉得选得很好：放在「分配编号之前」，而不是「开始写代码之前」。因为 AI 一旦拿到编号，就会把它当成「这件事已确认要做」的信号，后面再说「其实不用做」的阻力会大得多。这和人类的沉没成本心理异曲同工——项目都立了，总不能说不做吧？
触发这条规则的事故也很有意思：有一次给社区 issue 批量打了 feature 标签，但没逐个审核，导致一堆重复需求各自立了项。文件的总结是「批量打标签 ≠ 审核通过」。听起来像废话，但 AI 就是会把「列表里的每一项」当作「已确认的每一项」。
我的判断： 这部分的设计是整份 skill 里投入产出比最高的。检查成本低（搜索 + 扫描），收益大（避免从源头就走歪）。如果只能从这份 skill 里学一条，我会选这个：让 AI 证明「没人做过」，比让 AI 证明「我能做」重要得多。
第二个问题：自我锚定
LLM 有个被广泛观察到的倾向：给它一个方向，它会顺着那个方向一路跑下去，很少主动质疑起点是否正确。在协作场景里，这个倾向有两种表现：
- AI 太早给出分析，反过来锚定人的思路——operator 本来还没想清楚，看到 AI 的分析后不自觉地顺着它走了
- 先发言的 AI 带偏后发言的 AI——第二只猫读到第一只猫的分析后，很难再独立思考
这份 skill 在讨论阶段做了两个有意思的设计来对抗这一点。
采访式讨论：先让人说完。 默认的讨论模式是 agent 只问问题（为什么要？现在怎么做？做完后怎么用？），一次只问一个，不给分析。等 operator 把自己的想法完整表达完，agent 才开始整理和分析。
这条规则对 AI 来说是反本能的。LLM 最擅长的事就是「你说一句我接一句」，让它忍住不分析、只提问，相当于在能力最强的地方主动加了一道锁。但这恰恰是它的价值——正因为 AI 太能顺杆爬，才需要制度性地让它闭嘴。
多猫讨论：保护观点独立性。 多只猫参与讨论时，分析部分标注「仅供参考，先自己想再看」，并且明确声明「这是讨论不是任务」。这是在防一个很微妙的问题：AI 很容易把「另一只猫说的话」当作「需要执行的指令」。
我的判断： 采访式讨论的设计很巧妙，值得任何用 AI 做需求分析的团队借鉴。但多猫讨论的独立性保护，我持保留态度——LLM 读到「先自己想再看」这句话，真的会先自己想吗？靠提示词防锚定，效果存疑。更可靠的做法可能是架构层面的隔离：每只猫独立生成分析，最后才合并。不过这份 skill 能做的也只是 Markdown 层面的约束，架构隔离不在它的管辖范围内。
第三个问题：谎报完成
这是 AI agent 最危险的毛病，也是这份 skill 下了最重笔墨的地方。
agent 的「完成」声明为什么不可信？因为它的判断依据通常是 checkbox——spec 里的验收标准全打勾了，就宣布完成。但 checkbox 只是记录工具，不是事实本身。一个 checkbox 可以被打勾但实际没做，也可以做了但效果和预期完全不同。
这份 skill 针对这个问题搭了一整套防御体系，从底层到顶层：
第一层：真相源核实
最基础的一条：声称「完成」之前，必须用 git log 和 gh pr list 核实实际代码状态。文件原话是「只读 .md 就下结论 = 睁眼说瞎话」。
这条规则简单到有点蠢，但它指向一个深层问题：AI 默认把文档当真相。你在 spec 里写「已完成」，它就信了。人类开发者不会这样——你说 bug 修好了，我会去跑一遍看看。但 AI 不会，除非你明确告诉它：文档不是证据，命令输出才是。
第二层：愿景对照
核实了代码确实合并了，还不够。这层要检查的是：做出来的东西和 operator 最初想要的是同一个东西吗？
触发这条设计的事故很典型：某个 feature 的 12 项验收标准全部打勾通过，但 UI 根本没法用。原因是验收标准在执行过程中悄悄偏离了最初的愿景——每一条单独看都合理，合在一起却不是 operator 要的东西。
解法是强制做一张「愿景守护证物对照表」：
| operator 原话（逐字引用） | 当前实际状态（截图/命令输出） | 匹配？ |
|---|---|---|
| “把旧 mode 删掉” | [截图: mode 入口已无旧选项] | ✅ |
注意第一列要求逐字引用 operator 的原话，不是 agent 对需求的理解。这个细节很关键：它堵死了「按我自己的理解重述需求，然后宣布需求已满足」这条路。AI 特别擅长干这件事——把模糊的需求重新表述得更具体，然后声称自己的表述和原始需求等价。逐字引用让这种偷换没有空间。
第三层：守护猫交叉验证
前两层都有一个问题：验证者是作者自己。人（和 AI）检查自己的工作时，天然倾向于确认而非质疑。
所以这份 skill 引入了「守护猫」——从花名册里排除作者和 reviewer 后选出的第三只猫，专门做愿景验收。守护猫提出的最高优先级问题是 blocker，只有两条路可以走：做完，或者 operator 亲自签字说不做。
特别值得注意的是，这份 skill 用枚举法封死了所有绕路话术。未达标的验收项只有三个出路：当场做完、从标准里删掉（写明原因）、operator 签字接受降级。然后文件列了一份违禁词清单：
follow-up / deferred / next phase / P2 / stub / TD / 后续 / 留个尾巴 / 先这样 / 下次一定 / 回头 / 以后再 / next PR / will address later
这份清单本身就是一份 AI 行为研究样本——每一个词大概都真实地被某只猫用来糊弄过验收。负面清单比正面要求有效，这是管理 AI 的一条重要经验：与其说「要做完」，不如把所有「看起来像做完但其实没做完」的话术逐一堵死。
第四层：用户可见性翻译
最后一层针对的是一个更隐蔽的问题：功能在技术上确实完成了，但有些东西被悄悄降级了，operator 根本不知道。
触发事故：某个 feature 收尾时，设置页少了 7 个开源版已有的组件，通知页从可配置变成了只读的诊断矩阵。技术决策里写的是「deferred」，但这个词从来没被翻译成用户能感知的语言。
解法是要求作者产出一张 User Visibility Disclosure 表，把技术决策翻译成「用户在界面上能做什么、不能做什么」。刻意的「deferred」必须 operator 在讨论里显式签字。
我的判断： 这四层防御的设计意图我都认同，但有两个保留意见。
第一，守护猫的效果取决于 AI 是否真的能做到「独立质疑」。同一个 LLM 换个名字就能独立了吗？如果底层模型相同、训练数据相同、系统提示高度相似，所谓的「独立第三方」可能只是换了个 ID 的同一个 agent。真正有效的独立需要不同的模型、不同的 prompt 策略，或者干脆让人来做这一步。
第二，这套体系的仪式成本很高。四层检查、逐字引用、截图存证、签字降级——对一个功能周期几天的小团队来说，验收流程本身可能比开发还重。但反过来想，这个项目的 agent 数量多、上下文容易丢失，重仪式的成本可能确实低于「翻车后返工」的成本。这是一个团队规模和风险容忍度的函数，不是普遍真理。
还有一个值得单独说的设计：愿景硬度自检
这条不属于上面三个问题的任何一个，但我觉得它可能是这份 skill 里最有洞察力的设计。
触发事故：某个 feature 立项时 Why 写的是「降低复杂度」，验收标准落成了「修 bug + 提升可测性」。执行过程中两者悄悄分叉，直到收尾才被发现。
自检只问三件事：
- 愿景用价值语言写了吗？「重构 X」不算，「X 每加个功能就要 7 轮 review」才算。
- 现状有实测数据吗？「感觉这块乱」不行，给复杂度数字、代码行数、复现步骤。
- 每条验收标准都能指回愿景吗？ 指不回的要么删、要么补愿景。
这个设计的精妙之处在于它抓住了一个根因：愿景写得模糊，验收标准就会漂移。「降低复杂度」这个愿景太软了，复杂度有十种度量方式，每种都可以宣称自己降低了。如果一开始就钉死「复杂度从 X 降到 Y」，后面的漂移就没有空间。
这条规则对人类团队同样成立，但 AI 尤其需要——因为 AI 不会主动追问模糊的目标，它会自行填充一个合理的解读然后沿着跑。人至少会在执行过程中产生「等等，这是我要做的东西吗」的直觉，AI 不会。
能带走的判断
跳出这个项目，有几条对任何用 AI 协作开发的团队都成立：
- 事故编号是最好的流程论据。 这份文件里每条规则都挂着事故编号，规则不是「最佳实践」的空话，而是「上次就是这么翻的车」。对 AI 来说，具体的失败案例比抽象原则更能约束行为。
- 真相源和记录工具要分开。 checkbox、讨论记录、spec 文档都是记录；
git log、PR 状态、真实页面截图才是真相。所有「完成」的声明必须从真相侧取证。 - 负面清单比正面要求管用。 与其定义什么是「完成」，不如枚举什么是「看起来像完成但不是」——然后逐一封死。
- 让 AI 证伪比让 AI 证实有效。 立项时要求「证明没人做过」而不是「证明值得做」，验收时要求「找出不匹配的地方」而不是「确认都匹配」。AI 做证实时倾向于确认，做证伪时倾向于挑刺，后者正好是你需要的。
关于 agent 行为约束的另一个视角——agent loop 层怎么用机制防卡死、防失控：
这份 skill 有明显的情境绑定：它服务于一个「人类 operator + 多只 AI 猫」的极端协作形态，多数团队用不上这么重的仪式。但它的底层判断我完全认同：AI 协作的主要风险不是能力不足，而是它太擅长给出看起来合理的完成声明。 流程的全部重量，都压在这一个判断上。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时