AI 产研协作探索 · 2/4
在群里放一个 AI 助手之后，团队很快会想到很多用法：整理讨论、分析需求、生成原型、拆开发任务、查代码、追进度、建缺陷。
每一项看起来都合理。合在一起，“小智可以干什么”却越来越难回答。成员不知道应该给它什么材料，也不知道它回复之后，实际工作是否已经完成。
我在梳理这套产研方案时，做过一次收窄：需求分析、原型、内审和评审准备，由产品经理通过本地 Codex 完成；专业实现由开发及其工具完成；小智重点承担 PMO 职责。
PMO 可以理解为项目协调职能：让责任、计划、交接和进度有据可查，并推动该发生的工作发生。这里讨论的是职责设计，具体工具仍待接入，不是已经上线的数字员工案例。
先分清哪些信息需要团队共享
产品经理分析一个需求，可能反复调整假设，生成几版草稿。开发也可能试过多种实现，再决定保留其中一种。
这些过程对本人有价值。团队接手时，优先需要的通常是已经确认的范围、有效材料、关键决定和交付结果。把所有中间过程都搬到群里，会增加阅读和判断成本。
因此，我会把工作分成两部分：成员用自己的工具完成专业工作；达到约定节点时，把团队继续工作所需的结果交出来。
| 工作 | 专业人员与自己的 AI 工具 | 小智承担的协调工作 |
|---|---|---|
| 需求分析、原型和评审准备 | 梳理场景、比较方案、修改材料 | 接收有效材料和阶段结论，关联需求 |
| 开发实现 | 阅读代码、实现、运行约定检查 | 定位需求和负责人，关联分支与交付结果 |
| 测试与产品验收 | 执行验证，判断质量和业务预期 | 记录接收、结果与下一步，通知相关人员 |
| 排期和阻塞处理 | 提供估算、约束及实际情况 | 记录承诺、当前预计和阻塞，交给有权处理的人 |
这能保留个人工作方式，也让团队共享结果有统一口径。小智不需要知道产品经理每次改了哪个句子，但需要知道开发现在应该使用哪个需求版本。
共享结果也不等于每条聊天都成为正式决定。尚在讨论的选项、已确认的规则、后来被替换的结论，要能区分。否则，AI 读到了很多上下文，仍可能引用一条已经失效的话。
协调岗位可以执行具体操作
把小智定位为 PMO，并不意味着它只能汇总和催办。
如果开发已经提供了可用的工程执行入口，小智可以接收“领取这个需求并准备分支”的指令，定位需求，再调用工具完成领取、分支获取、关联和状态写回。
这里的职责区别在于，小智推动的是明确节点。至于代码怎样实现、方案是否满足业务规则，仍由专业人员及其工具处理。
一句“拉取代码”背后的完成条件应该写清楚：
- 需求能够从当前话题准确定位。
- 开发交付负责人已经更新并核对。
- 实际分支已经创建、获取，并与需求绑定。
- 需求状态已按约定写回。
- 原话题收到真实结果和分支信息。
其中，群里发出了“请拉取代码”的提醒，只完成了通知。它没有证明分支已经存在，也没有证明负责人和状态已经更新。
同样，从聊天创建需求，也需要经过提取、草稿确认、写入、读取新增记录核对，再返回链接。整理出一段漂亮的需求描述，是这个动作的一部分。
判断一个 AI 能力是否值得进入团队流程，应该看这项业务动作最后完成到了哪里。
用动作介绍能力，成员更容易调用
“我是你的智能产研协作伙伴”很难帮助一个忙碌的开发决定下一句该说什么。
能力介绍可以直接写成：“我可以帮你从聊天创建需求、领取需求并准备分支、同步提交与自测结果、查询当前交付进度。请在对应话题明确说出要做的动作。”
给 AI 安排一个 PMO 岗位，先说清四件事：负责什么、何时触发、实际做什么、什么结果算完成。下面这张表可以作为能力设计模板，描述应实现的操作约定，不表示这些能力已经接入。
| 能力 | 用户怎样触发 | 小智实际做什么 | 什么结果允许说完成 |
|---|---|---|---|
| 从聊天创建需求 | 明确 @ 并要求创建 | 读取限定聊天，提取草稿，确认后写入 | 新增记录可读取，字段与确认内容一致，返回链接 |
| 领取并准备分支 | 在绑定话题明确发起 | 登记负责人，调用工程入口，保存关联并写回状态 | 实际分支、负责人和状态均可核对 |
| 同步工程结果 | 接收项目工具回传或已接入事件 | 关联对应需求，汇总本轮提交、自测与 MR | 结果和版本有来源，可从原话题追溯 |
| 查询进度 | 指定需求或在绑定话题询问 | 读取正式记录，结合已取得的交接结果 | 回复当前阶段、下一步、负责人及材料链接 |
把这四列填出来，比先给助手写一大段人设更有用。它们也能成为接入后验收能力的依据。
触发不一定都来自聊天。需求状态变化和工程结果也可以是触发来源，但要先约定哪些事件代表什么。一个普通 Push 只说明有代码推送，不能直接推导出需求完成。
人工确认放在需要决定的地方
如果每一步都要求人回复“确认”，成员很容易觉得自己是在替机器人维护流程。如果任何一句讨论又都能触发写入，责任就会变得不清楚。
我倾向于先按动作区分。
从聊天形成新需求，AI 对背景、范围和归属作了提取，需要展示草稿让人确认。明确授权后的领取操作，可以按已经约定的流程执行，并把真实结果返回。查询当前状态，则读取现有事实。
范围变化、重要承诺、测试验收和发布决定，仍由相应负责人作出。小智可以提供依据和选项，让这个决定更容易完成。
确认点应该对应一次真实取舍：准备创建哪条记录，接受哪个版本，是否通过哪项验收。反复确认一段没有变化的操作说明，通常没有增加新的判断依据。
同一条已完成的领取请求再次到来时，返回已经绑定的分支即可。这条规则针对业务启动动作，不限制开发正常同步代码。它能减少重复执行，也让成员知道这次回复到底做了什么。
再检查它有没有增加维护负担
小智把群消息、需求表和工程结果联系起来之后，团队仍需要一个正式进度来源。
在这套设计里，需求记录保存阶段与负责人，代码平台保存分支、提交和 MR。小智保留它们之间的关联、操作结果及交接摘要，不另外维护一套独立需求状态。
这个安排有一项很实际的检查：开发已经通过项目工具完成提交、自测和 MR 后，是否还要手动向小智重填同一批信息？如果答案是要，结果回传这一段就还没有完成。
通知也要服务具体行动。材料需要补齐时，告诉谁补、缺什么；需要接手时，给出需求、版本和下一步。没有新事实、也没有需要处理的事项，就不必再发一条泛泛的进度提醒。
接入前，可以用三个问题检查职责是否清楚：成员能否用一句话调用它；调用后是否发生了可核对的业务动作；这次操作是否让下一岗位更容易继续工作。
三个问题都答得清楚，再扩大能力范围。这样，小智的职责可以随着团队需要增长，而不必一开始承担整条产研链路的所有专业工作。