前三篇分别讲了规则文件、知识库、技能包。三个工具分开看都不难理解，但真正上手之后经常会卡在同一个问题上：一个具体任务来了，到底该先动用哪一个？这篇不再引入新概念，就把三件套串起来，走一次完整的真实任务，看它们具体怎么协同。
一、先说痛点
1. 分别学会了，遇到实际任务还是不知道从哪下手
规则文件会写了，知识库也搭起来了，技能包也装了，但接到一个具体需求的时候，还是会愣一下：这条信息该先补进规则，还是该先查知识库，还是该指望技能包自动接管？三件工具分开学的时候都清楚，合在一起用反而含糊了。
2. 边界不清，内容开始重复甚至冲突
一条"退款不能跳过审批"这样的信息，可能同时被写进了规则文件（当成红线）、知识文档（当成业务说明）、甚至某个技能的描述里（当成步骤前提）。改一处的时候很容易忘了另外两处，时间长了三份内容互相不一致，比什么都没写还麻烦。
3. 缺一个"这条信息该放哪"的判断依据
前面两个问题的根源都是一样的：没有一个简单、能随口用出来的判断标准，导致信息随意堆放，全靠个人记忆和习惯决定放哪。
二、解决方案：三层分工模型，一条判断口诀
三件套本质上是三层不同职责的记忆，各自回答一类问题：
- 规则文件：回答"任何时候都不能做什么 / 必须怎么做"——这是红线约束
- 知识库：回答"项目是什么 / 为什么这么设计"——这是事实性记忆
- 技能包：回答"这类任务该按什么步骤做"——这是可复用的方法论
拿到一条新信息时，可以用这个口诀快速判断放哪：
三层之间用引用代替复制——这正是篇一"统一入口"原则的延伸：一条信息只在它该待的那一层写一次，其他层要用的时候用链接或引用指过去，而不是抄一份内容过去。
三、动手教程：给 acme-order-service 加一个完整功能，走一遍三层协同
任务：给 acme-order-service 加"订单超时自动取消"功能——超过一定时间未支付的订单，系统自动取消。
步骤 1：技能包接管开场，先澄清需求
跟 AI 说"给订单加一个超时自动取消的功能"。因为装了篇三讲的 superpowers，brainstorming 技能会先被自动触发，AI 不会直接写代码，而是先问清楚：超时时长具体是多久、取消后要不要给用户发通知、超时判断是靠定时任务扫描还是靠延迟队列。这一步把"做什么"的边界定下来，比事后返工便宜得多。
步骤 2：过程中查知识库，避免设计冲突
需求聊清楚之后，进入设计阶段。AI 按篇二规则写进知识库的 order-state-machine.md 里记着一条决策：“订单状态只能单向流转，不允许回退”。这条记忆直接决定了"自动取消"该怎么设计——它不能被实现成"已支付回退到待支付再取消"，只能是"待支付"状态下的一条新的单向转移分支。如果没有这份知识库，AI 很可能凭常识去实现一个看似合理、实际违反已有设计决策的方案。
步骤 3：编码阶段，规则持续生效
设计定下来之后开始写代码，篇一里写进 AGENTS.md 的规则全程生效：Service 层命名规范约束着新加的 cancelExpiredOrder 方法怎么命名，异常处理规范约束着超时扫描逻辑里的异常必须记日志而不是吞掉，Git 操作红线约束着改完代码后 AI 会先展示 diff 等你确认，而不是自己直接提交。
步骤 4：踩坑触发反馈闭环，同时更新规则和知识库
测试阶段发现一个问题：定时扫描超时订单的逻辑里，捞取订单和更新状态之间存在一个竞态条件，两个扫描周期可能同时处理同一个订单。这次踩坑触发了篇一讲过的反馈闭环——AI 把"批量状态更新必须加乐观锁"这条转成新规则，追加进 AGENTS.md；因为这也是一次设计层面的补充（不仅是编码约束，也是"为什么这么设计"的一部分背景），同时在 order-state-machine.md 里补了一句"批量超时取消存在并发场景，处理时需加乐观锁"，并保证规则文件和知识文档这两处互相引用而不是互相复制——规则里只写约束本身，具体的"为什么会有这个坑"的背景留在知识库里，规则文件里用一句话链接过去。
步骤 5：收尾验证，不能只凭 AI 自己说完成了
代码改完、规则和知识库都同步之后，篇三里 verification-before-completion 这类技能会在 AI 准备宣称"任务完成"之前介入，强制要求真的跑一遍测试、确认结果，而不是看代码写完、编译通过就直接说"做完了"。这一步把"做完了"从一句话变成一个有真实核对过程支撑的结论。
走完这五步，一个功能从"提需求"到"交付并验证"的全过程里，规则、知识库、技能包三者各自在恰当的时机介入，没有一处是靠人凭记忆去补位的。
小结
四篇写下来，核心是同一个模型：规则管约束，知识库管记忆，技能包管方法论，三层各管一块，用引用代替复制。这套思路不依赖某个具体工具，就算你用的 AI 编码助手或者知识库软件换了一代，只要还认这三层分工，迁移过去的成本也不大。工具会一直更新，但"什么样的信息该放在哪一层"这个判断标准，大概率比任何一个具体工具都活得更久。
系列文章
本系列共四篇文章，建议按顺序阅读，构建完整的 AI 辅助开发工作流：
