最近几个月，QoderWake 团队的钉钉群出现了几个“新人”，从PD到前后端、再到测试都有。我们没给他们安排Mentor，也没有设定新人到岗的landing期，但他们进群后很快就读完了项目仓库中的文件和代码，直接上手开始开发，“问下Waker”“让Waker做一下CR”一下子就成了团队内部的“流行语”。
他们是谁？他们有个共同的名字：Waker，也就是 QoderWake 产品研发的数字员工。现在 QoderWake 的产研流程中，我们和Waker们“深度协作“，把原本人找消息、人找人的协作卡点和重复的“找人测试找人改”的流程交给 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和代码，但做了所有关键决策：定方向、定分工、定安全红线、确认技术契约、验收成果。
让 Waker 进入更多真实产研场景
在我们团队的工作中，我们正不断探索，让 Waker 真正全方位的参与到产研流程当中：
在群里七嘴八舌讨论了一个新功能，我们会 @Waker 让他直接拉个分支，做出可体验、可交互的 Demo；
一个需求进入内部平台，Waker 自然地成为了项目管理的角色，在群里 cue 流程、跟进度；
收到一份 Bug 工单，Waker 能自己根据日志文件来查问题，创建一个待处理缺陷，带着它找到负责的研发同学；
需要 Code Review，可以在群里 @Waker 直接把链接给 Ta，Ta 会直接把 CR 写入代码平台；
产品新版本发布前，Waker 自动把发布前总览和紧急发布风险发到群里，直接@对应模块的负责同学……
这就是 QoderWake 正在做的事：让群里多了几个群成员，少了一些总是需要@好多次的对话，也少了一些记不清、找不到群里很久以前的消息的问题。Waker 让我们可以围绕一个任务，而不是围绕一次次会议和一次次排期，组织自己的工作方式。调研、定义、实现、评审、测试，这些环节之间的交接成本被大幅压缩——因为数字员工一直在这件事里，带着完整的上下文，随时可以被下一条消息唤醒继续推进。
QoderWake —— 不需要人来操作，也可以让待处理需求少一些，正在跑的代码多一些，产研流程更高效一些。
