AI 产研协作探索 · 3/4
测试同学问“这个需求做到哪里了”，开发回了一条 MR 链接。产品点开之后，仍然要问：它对应哪版需求，自测过哪些内容，现在可以开始测试吗？
MR 是合并请求，承载代码审查和合并相关信息。它能回答一部分工程问题，却不会天然知道团队的需求约定。
这也是我梳理产研协作时，希望优先解决的关联问题：从聊天里的诉求，到需求记录，再到代码和验证结果，能否一直确认自己讨论的是同一件事。
下面用“导出筛选后的数据”走一遍设计。需求编号 REQ-017、仓库和分支都是示例，整条链路仍待接入验证；首期限定一个需求、一条交付话题、一位开发负责人、一个单仓库需求分支。
先入池，再决定进入交付
业务同学在群里提出：列表可以筛选日期和状态，但导出的文件没有按筛选条件取数。团队讨论之后，认为可以形成一个需求。
此时有人明确发起：“@小智，把刚才讨论的导出问题创建成需求。”
按这套设计，小智读取指定聊天范围，提取需求背景、标题、描述、提出人、需求负责人，以及有依据的优先级。先展示草稿，用户可以确认、修改或取消。
确认之后才写入需求表，再读取新增记录核对并返回链接。这里产生的是一条“待评估”需求，不是已经承诺开发的任务。产品经理仍要判断是否值得做，并确认范围和验收要求。
HiFox 的飞书实践提供了群聊与工作记录关联、后续结果回到来源话题的启发。我们的设计保留了这条关联思路，并将需求入池和进入交付分开。HiFox 飞书实践
这种区分也避免一个常见误解：聊天里形成了需求，不代表团队已经分配了交付资源。
交付话题用来持续关联结果
产品经理确认需要交付之后，通过约定的状态变化启动交付话题。当前约定是“待评估”首次进入设计中、待内审、待评审、待开发或开发中之一时创建；其他变化不触发这个动作。
话题创建后，关联需求记录，邀请产品负责人补充或链接有效材料，再安排开发进入。一个需求只建立一条交付话题，后续讨论和交付结果继续回到这里。
已有聊天可以作为需求来源。如果在需求 A 的话题里发现了新需求 B，A 的话题也只是 B 的来源，不能直接把它当作 B 的交付话题。
准确定位依靠需求记录 ID 和话题 ID。标题便于人阅读，却不适合承担唯一关联。需求改了名称，原话题仍应能找到同一条记录。
对 REQ-017，我们先在交付材料里明确三件事：导出当前筛选结果；字段沿用已确认的列表约定；权限与列表访问范围保持一致。无结果时怎样反馈等未定规则，也需要在开发前确认。
这些属于示例范围。真实项目必须根据现有产品行为补齐，不能因为示例写得完整就直接照搬。
一个需求交给一位开发，实施清单仍要保留
这套方案讨论过程中，交付模式从拆分多个前后端任务，调整为一位开发负责人完成整个需求。
对于边界清楚、开发者具备前后端处理能力的需求，这样做有机会减少接口解释和任务间等待。负责人能够围绕完整业务目标推进，也更容易判断什么时候具备交接条件。
但一位负责人仍需要拆解实施步骤。取消的是独立分派和维护状态的 WBS 任务层，WBS 指工作分解结构；需求内部的实施清单继续保留。
| REQ-017 的实施项 | 交付负责人需要核对的结果 |
|---|---|
| 确认筛选规则 | 日期、状态及组合筛选有明确预期 |
| 实现取数与导出 | 接口与页面使用一致的筛选条件 |
| 核对权限 | 导出不会扩大用户可访问的数据范围 |
| 准备自测与交接 | 结果、版本和检查范围能够追溯 |
这些条目帮助负责人和 AI 安排实现，不必再各自成为需要跨岗位领取的业务任务。
这个模式依赖范围和能力条件。涉及多个专门系统、关键迁移或复杂并行协作时，需要重新评估分工。代码评审、正式测试、产品验收和发布决定仍分别由相应角色负责。
领取时，建立真实分支关联
开发在 REQ-017 话题发起：“@小智，领取这个需求并拉取代码。”
首次操作按约定依次完成：登记领取人，更新开发交付负责人，调用工程入口创建并获取分支，保存关联；这些成功之后，写回“开发中”，在原话题返回结果。
一个示例关联可以这样保存：
| 对象 | 示例标识 | 用途 |
|---|---|---|
| 需求 | REQ-017 对应的正式记录 ID | 定位业务范围与状态 |
| 话题 | REQ-017 的交付话题 ID | 定位指令和结果返回位置 |
| 仓库 | sample-app 的项目 ID | 区分不同代码仓库 |
| 分支 | feature/req-017-export | 定位该需求的工作分支 |
| 版本 | 实际提交 SHA | 定位一次具体代码结果 |
| MR | 实际创建的 MR ID 与链接 | 关联审查和合并记录 |
SHA 可以理解为提交的版本标识。它帮助团队区分“同一个分支上的两轮代码”。仓库项目 ID 加分支名，才能准确定位分支；名称本身不能保证跨仓库唯一。GitLab 事件字段说明
分支命名和创建基准由项目规范决定，上表中的名字只是示意。需要保存的是工具实际返回的结果。
同一需求已经完成首次领取后，再次请求这个业务启动动作，只返回已绑定分支，不重新领取或创建。开发日常获取最新代码继续按正常 Git 流程进行，返回既有分支不表示本次已经同步了最新代码。
两个操作入口，对应同一轮结果
开发可以在群里要求执行提交，也可以直接在 Codex 中通过项目 Skill 完成提交、自测和 MR。Skill 是项目约定的可复用执行方法，具体包含哪些操作，要以实际项目能力为准。
两条入口使用同一规则：提交代码，完成开发侧自测，自测通过后发起或更新 MR。群内发起时，小智调用已经接入的工程入口；开发直接完成时，小智接收结果，做关联、记录和状态同步。
外部入口已经完成的提交、自测和 MR，不再由小智重新执行一次。
GitLab 可以提供 Push、MR 和 Pipeline 等事件，分别反映远端推送、合并请求变化和流水线变化。本地尚未推送的提交，则需要本地项目工具回传；代码平台不能据此知道开发者此刻在电脑上处理什么。GitLab Webhook 文档
假设本轮代码版本是 A，交接记录应说明：提交是 A，自测检查的是 A，MR 也对应 A。如果自测后又产生了影响交付内容的新提交，原来的通过结果不能直接代表新版本。
团队可以统一一条结果摘要：
需求：REQ-017，导出筛选结果。
负责人：本次开发交付负责人。
分支与提交：实际分支链接、版本 A。
自测：执行范围、实际结果、报告链接。
MR：实际链接与对应版本。
下一步：进入测试流转，测试接收情况另行记录。
这里每个“实际”都应能打开记录核对。群内摘要引用结果，不要求成员把整份日志复制进聊天。
“测试中”还需要一个接收结果
当前已确认的流转规则是：本轮提交、自测通过、MR 发起三项齐备，并且对应同一轮代码后，将需求状态更新为“测试中”，读取同一记录核对，再反馈原话题。
这表示进入测试流转。测试同学是否已接手、实际测试环境是否就绪，以及怎样整体提测，仍需要在后续场景中明确。文章不把这些待定步骤写成已经接通的功能。
MR 发起、自测通过、测试接收、产品验收、正式发布，各自回答不同问题。把它们合成一个“完成”，看板虽然简洁，接手人却会失去判断依据。
这条链路的验收，可以让测试同学从 REQ-017 的话题出发，找到有效需求、对应代码、自测范围和 MR，再明确接收条件还缺什么。
能沿着关联找到这些材料，团队才有条件减少反复询问。至于有没有缩短周期，要等真实接入之后继续观察。