AI 产研协作探索 · 1/4
产品经理用 AI 写出了更清楚的需求，开发用 AI 更快地改完代码，测试也能更快地准备检查项。一项需求仍然可能在团队里走得很慢。
产品要解释哪份文档有效，开发要确认接口有没有变，测试要问这次改动在哪个环境。每个人都在使用 AI，下一岗位却还得自己找人、找材料、找版本。
这时继续追问“谁还没有学会用 AI”，很容易找错问题。
我在梳理产研协作时，更关心的是：个人已经产出了结果，团队为什么还不能顺利接着做？下面是一套正在讨论的流程改造思路，尚没有实际运行的收益数据。先把问题找准，才有依据决定接什么工具。
一项需求的时间，都花到哪里了
需求从确认做到上线，既包含实际工作，也包含等待。
分析业务规则、修改代码、执行测试，是实际工作。等补充材料、等确认范围、等接手、等环境，是另一类时间。两类时间需要分别记录，因为它们的改进办法不同。
如果需求描述含糊，AI 可以辅助检查规则和异常场景。如果已经准备好，却没人知道该谁接手，继续提高需求文档的写作速度就很难解决等待。
还有一种耗时不容易被看到：同一件事被维护多次。开发已经在代码平台提交了改动，还要更新需求表，再到群里解释一次。测试找到的问题已经在缺陷系统里，又要重新写进日报。
这些更新可能各有用途，也可能只是历史习惯。判断之前，需要先看谁真的会使用它们。
我建议拿一项最近完成的需求，把下面这张表填出来。没有准确时间时先标“未知”，不要为了画出完整流程而补数字。
| 节点 | 上一岗位交出了什么 | 下一岗位还缺什么 | 等待开始／结束 | 重复更新了哪里 |
|---|---|---|---|---|
| 产品交给开发 | 有效需求、原型、评审结论 | 未定规则、负责人或依赖 | 按实际记录填写 | 文档、表格、群消息 |
| 开发交给测试 | 代码版本、自测结果、提测材料 | 环境、版本核对或接收人 | 按实际记录填写 | 代码平台、需求表、群消息 |
| 测试交给验收人 | 验证结果、未通过项 | 待决定的业务问题 | 按实际记录填写 | 缺陷系统、验收记录 |
另行记录分析、实现和验证实际投入了多少工作时间。工作时间与等待时间分开看；各人的投入也不能直接相加当作需求的自然日周期。
填完之后，按实际原因标记等待：需要作出判断，正在寻找已有信息，接手人没有空档，或者环境及前置工作还没准备好。同一段等待也可能有多个原因。
待判断的问题可能要改职责和决策安排；寻找已有信息适合研究关联、通知和结果同步；容量不足及准备未完成，则要处理排期或依赖。一个机器人能把链接送到群里，却不能替一个没有时间的人完成测试。
先确定哪些更新可以停
很多 AI 改造从“增加一个助手”开始。我更愿意先检查，接入以后，团队能少维护什么。
例如，开发提交信息能从代码平台取得，就可以研究是否停止手填“今天提交了什么”。需求已有固定记录，就可以让交接通知引用它，不再让产品经理重新拼一份介绍。
但“自动汇总”和“取消重复维护”之间，还隔着一项管理决定：大家是否认可同一个正式来源。
如果需求表、排期表和群消息都能独立改状态，AI 只是帮忙把三份不同答案写得更快。团队仍要花时间判断哪个是真的。
可以先写一份很短的停止清单：
| 当前动作 | 保留它的理由 | 替代方式 | 停止条件 |
|---|---|---|---|
| 手填代码提交摘要 | 团队需要知道实现进展 | 同步真实提交与对应需求 | 关联和同步经过核对 |
| 每次交接重新整理背景 | 接手人需要有效材料 | 引用需求及当前有效文档 | 接手人能访问并理解材料 |
| 在多个位置改需求状态 | 不同人从不同入口查看 | 一个正式记录，其他入口引用 | 查询与写回指向同一记录 |
先确认用途和替代条件，再停旧动作。否则只是少填了一张表，信息缺口会在下一次交接时出现。
交接要交出可以继续工作的结果
“开发完成了”对下一岗位来说，仍然不够具体。
测试需要知道：这次验证哪个版本，在哪里验证，预期行为是什么，哪些检查已经完成。产品验收也需要知道，这个版本是否包含当初确认的范围。
HiFox 的研发工作流给我的一个启发，是把背景、范围和验收要求放到可持续跟踪的工作记录里，再让调研、执行、检查和人工验收围绕它推进。它的官方说明也明确，执行需要环境和权限，并非创建了任务就会自动完成全流程。HiFox 研发工作流
借鉴这类机制时，我会把一次交接约定具体到五项：
- 谁发起，谁接收。
- 对应哪条需求。
- 使用哪份有效材料和哪个代码版本。
- 接收后具体做什么。
- 怎样记录已经接收，以及这一轮的结果。
其中最容易被忽略的是“接收”。通知送达，说明消息发出去了；接收人确认材料具备条件，才说明工作可以继续。两者需要分别记录。
AI 在这里可以整理材料、执行约定的节点操作、核对结果、写回状态，并把下一步交给具体人员。它的价值要体现在这段协作里，而不是多生成一份看起来完整的周报。
第一个试点，选一段能结束的交接
“打通全部产研流程”很难作为第一轮目标。参与角色越多，越容易把工具接入、职责调整和工程规范混在一起。
更容易检查的起点是：选择一个范围清楚的需求，只改造从开发结果产生，到测试具备接收条件的一段工作。暂时保留其他环节的实际方式。
选择时看三个条件：这段工作是否反复发生，双方需要的材料是否能列清楚，结果是否能核对。仅仅“经常有人问进度”，还不足以说明应该做自动化。
试点前，把起点和终点写清。例如，起点是开发提交一轮可核对的交接材料，终点是测试确认接收。代码提交、自测、环境准备在什么时刻发生，也要分别记录，避免只剩一个模糊的“开发完成时间”。
这轮至少观察四件事：
- 从材料就绪到接收，中间等了多久。
- 接手人还需要追问几次，主要缺什么。
- 团队少维护了哪些记录，新增维护花了多少时间。
- 交接质量有没有下降，例如收到材料却仍找不到正确版本。
这些记录不需要做成复杂的绩效系统。它们的用途是帮助团队决定：继续接这一段，调整约定，还是缩小范围。
一次顺利演示可以证明某条路径能走通。要判断团队是否受益，还需要观察后续同类需求，以及人工核对和维护投入。没有对照时，就记录变化，不急着把变化全归因于 AI。
对产研负责人来说，一个很实际的检查办法是：下次交接时，接手人能否直接找到有效材料、明确下一步，而不用先在几个群里问一圈。
这个问题能把工具能力、责任分工和协作结果放到一起检查。团队是否更快，可以从这里开始确认。