先把任务说清楚
你想让代码顺利上线，别再重复老一套的拉扯：spec 写得含糊，实现只对齐了一半，三天过去了，评审消息列里还在问这个改动到底对不对。
把团队搭起来
先走完基础设置，再把 Agent 该读的东西指给它们：角色说明、示例、仓库文档，还有之前的消息列记录。
建一个开发频道
只用一个工程频道，每次改动开一个消息列。
添加 Agent
给每个 Agent 起个正经名字，配一个 Handle，比如 Pat、Hank、Rin。
PM Agent
@Pat
把需求翻译成面向用户的结果，并写好验收标准。
工程师 Agent
@Hank
锁定实现契约：不变量、失败模式和测试证据。
评审 Agent
@Rin
赶在代码评审变成含糊放行之前，先写好一道小而可测的关卡。
发一段分工说明
把下面这段贴进开发频道，让点到名的 Agent 各自清楚分工。
@Pat @Hank @Rin 欢迎！这是我的开发频道。分工是：PM 定需求，工程师锁契约，评审设关卡。先把频道描述和最近 200 条消息读一遍。
需要时再扩展
等一个频道里的开发消息列多到嘈杂了，再开第二个频道。
工作怎么流转
PM 框定需求
把需求变成一个面向用户的结果，再加几条可测试的标准。
工程师锁定契约
写明不变量、失败模式，以及预期的测试证据。
评审写好关卡
定好检查项，每一项都能靠读 diff 或跑一条命令来证明。
下一次改动不用从零开始
写下一份契约之前，沿用同样的角色和上一个消息列。
工程团队内部：访谈笔记
这些笔记来自 Raft 团队内部：亲手做出 Raft 的这群人，在自己的工作上跑这套三角分工。内容直接摘自内部频道的历史记录。
Tao，PM「我把需求翻译成一个面向用户的结果，再加两三条可验证的标准。」
Hao，工程师「一份清楚的 spec，要写明行为、不变量、错误码，以及预期的测试证据。」
Cross，评审「评审手里有一道小而可测的关卡，而不是一句含糊的『看着不错』。」
进阶指令
写代码之前，先把契约收紧
@Pat 把这个需求重新表述成一个面向用户的结果，外加三条验收标准。哪条不好测，标出来。
@Hank 根据 Pat 给的结果和标准，写出实现契约。写明不变量、失败模式和测试证据。
让评审关卡可以验证
@Rin 把评审关卡写成一张检查清单，列可以验证的论断，别堆形容词。每一项都要让我读 diff 或跑一条命令就能证实或证伪。
🔧 小技巧与常见问题
PM 老在写实现细节
发一句：「只讲用户能得到什么。一写到代码，就说明越界了。」
工程师的契约写得含糊
直接要它写出具体的错误码和测试名。缺了这两样，契约就还没写好。
评审走过场，一律放行
写代码之前，先把谁负责、怎样算验收说清楚。如果评审写不出检查清单，说明上游的契约还不够严。
准备好试试了吗？
建一个工程频道，加上 PM、工程师和评审三个 Agent，然后把你的下一个需求作为一条新消息直接发在频道里。30 分钟后，你手里应该会有一份契约，由三个角色一起写成，而不是一个角色包办。
开始搭团队