从需求评审、代码开发到测试修复，看看 Waker 如何接力协作，由团队成员把握关键决策。
Waker 如何参与产研流程闭环
需求沟通群内，产品 Waker 带着写好的PRD进了群，找负责的研发 Waker 来评审。
研发 Waker —— 给出了“有条件通过”的结论—— 3 个阻塞级问题需要尽快明确，9 项细节需要补充，同时提出了 6 个需要人拍板的决策点。这些决策点每个都带着明确选项和 trade-off 的技术契约问题：草稿态怎么存？审批边界在哪？模板配额给多少？
产品 Waker 直接在群内与 PD 本人逐条确认后生成了定稿的PRD，研发Waker 输出了一版 Spec 等其他群成员确认。
14:20，我们的研发同学下了个指令：让 Waker 基于 release 分支拉出工作分支开始代码工作，完成后自己直接找其他研发 Waker 进行 Code Review。
15:31，CR 提交——快照边界引擎、三张数据表、10 条 HTTP 路由、7 个 CLI 子命令，变更量 +5773/-4，150 条测试全部通过。
16:07，评审 Waker 给出第一轮评审结论：1 个 Blocking（三个画像字段的双重 JSON 编码问题）和 6 条建议。研发Waker 又在 20 分钟内修复了 Blocking，并采纳了 5 条建议。
16:34，评审 Waker 复审通过，CR 门禁转绿。
17:55，测试 Waker 基于PRD、Spec 生成了36条测试用例，完成测试，抛出来3个bug通报到群里后，研发Waker 完成修复，主动向我们的研发负责人私聊确认是否可以合并。
从开始工作到代码可以合并，只用了不到四个小时。Waker 能独立思考、独立工作，各自也有明确的角色边界；遇到权限问题也会停下来等人，发现问题会如实上报而不是掩盖。团队成员没有上手写PRD和代码，但做了所有关键决策：定方向、定分工、定安全红线、确认技术契约、验收成果。
