AI 产研协作探索 · 4/4
准备做 AI 产研改造时，最容易越做越大的工作，是接入清单。
需求表要连接，聊天要读取，知识库要整理，代码、测试、发布和文档也都想一起打通。清单越来越完整，第一个可检查的结果却迟迟没有出现。
我更倾向于沿用现有工具，先接通一段交付链路。产品与开发继续用 Codex 和项目 Skill 完成专业工作，飞书承接协作，Git 保存工程事实。先确定它们怎样交出和接收同一份结果。
沿用上一篇的设计示例：REQ-017，要导出列表的筛选结果。它尚未实际接入，本文提供的是可交给产品和开发对齐的实施步骤。首期限定一个仓库、一个需求分支、一位开发交付负责人。
第一轮，从领取到进入测试流转
首期先选一条已经确认范围、具备开发条件的需求。聊天创建需求、自动建立交付话题，可以分开接入；它们不必都成为这一轮的前置项目。
需求记录与交付话题的关联，也可以先由有权人员登记并核对。这样可以尽早验证后面的工程结果关联，而不必等待全部自动化完成。
这轮试点的起点是：开发在已绑定话题中明确领取并准备分支。终点是：本轮提交、自测通过、MR 发起的结果齐备，需求状态写回“测试中”，原话题收到可核对的结果。
测试实际接收与测试环境验收继续按团队已有方式处理，并单独记录。“测试中”只表示进入测试流转。整体提测怎样执行、测试人员怎样加入，仍是后续需要细化的场景。
这个终点足够具体，产品和开发可以一起检查它。第一轮也不需要顺便建立每人一个助手、迁移缺陷系统或搭完整知识平台。
把现有工具的职责写在一张表里
先明确谁保存什么，再决定怎么接。下面是这套方案的分工建议，实际权限和接口必须由开发确认。
| 工具或角色 | 首期承担什么 | 接入前核对什么 |
|---|---|---|
| 飞书需求记录 | 正式阶段、产品与开发负责人、材料链接 | 目标表、实际字段、状态选项及读写权限 |
| 飞书交付话题 | 操作入口、结果摘要、下一步沟通 | 话题ID、机器人可见范围及回复能力 |
| 小智 | 定位关联，发起约定操作，接收结果，写回并通知 | 工程调用入口、结果保存与核对能力 |
| Codex＋项目 Skill | 复用项目拉取、提交、自测和 MR 约定 | 实际可执行动作、环境、检查项与回传方式 |
| Git／GitLab | 分支、提交、MR 及已运行的流水线事实 | 仓库项目、分支基准、保护与审查规则、可用事件 |
| 测试与产品负责人 | 正式验证、业务验收和后续交付决定 | 接收条件、环境与实际版本、验收人 |
Codex、项目 Skill 和 Git 已被选作工程工作方式，并不意味着它们之间已经有一个可调用的集成接口。接入任务必须落实到具体入口，以及入口真实返回什么。
也不必要求所有人的个人工具配置完全相同。与团队协作有关的动作、需求关联和交付结果口径要一致，个人怎样准备材料和实现代码可以保留差异。
产品先交出业务约定，开发再映射执行入口
“让机器人提交代码”还不是一项完整的接入需求。它没有说明提交哪个分支、自测到什么程度、结果如何回来。
产品与开发对齐时，可以直接使用下面这份首期接入单。
业务范围
需求：REQ-017，导出筛选结果。
当前有效需求与验收材料：已确认链接。
交付负责人：已明确的一位开发同学。
首期工程范围：一个仓库，一个需求分支。
试点终点：提交、自测通过与 MR 齐备，回写测试中并在原话题反馈。
业务动作
首次领取：登记负责人，实际准备分支并保存关联，再写回开发中。
群内提交：调用项目入口完成提交、自测、MR，再返回结果。
工具内提交：接收开发已完成的结果，不重复执行。
结果齐备：核对同一轮代码，更新对应需求并读回确认。
开发需要补充：在哪个环境执行，由哪个已授权身份执行，使用哪个实际项目 Skill 或工具入口，检查项在哪里维护，结果通过什么通道回传。
这些是实施前必须填实的内容。可以保留为待接入，但不能先用一段提示词替代，再宣称链路已通。
产品侧也要确认状态含义和负责人字段。尤其不能把“当前最后提交的人”直接当作开发交付负责人，或者把 MR 合并当作整个需求已上线。
先统一结果，再连接第二个入口
建议先让开发从现有项目工具完成一次实际操作，拿到真实结果。能识别这份结果，再接飞书指令入口。
这样可以先核对工程流程本身，减少“聊天入口出了问题”与“项目工具还不能执行”同时出现时的排查负担。
结果回传至少包含这些信息：
| 信息 | 要回答的问题 |
|---|---|
| 需求与本轮操作标识 | 这是哪条需求、哪一次业务操作？ |
| 操作人、时间、仓库和分支 | 谁在什么位置完成了什么？ |
| 提交版本 | 本轮代码具体是哪一版？ |
| 自测范围、结果及报告 | 实际检查了什么，针对哪个版本？ |
| MR 地址及对应版本 | 审查入口在哪里，与自测是否一致？ |
| 已完成和未完成项 | 是否满足本轮终点，还缺哪一步？ |
这是业务结果清单，不是固定 API 协议。开发可以按项目实现返回字段，但不能只传一段“全部成功”。
GitLab 官方提供 Push、MR、Pipeline 事件。它们能作为部分结果来源；本地提交和项目自测还需要相应工具回传。流水线成功是否包含本次约定自测，要检查实际执行范围。GitLab Webhook 文档
外部操作同步清楚以后，再把飞书指令接到同一个工程入口。群内触发和工具内触发共用关联及结果口径；同一次操作同时被工具回传和代码平台事件捕获时，合并成同一份记录。
按可观察结果验收这一轮
演示时，不只看机器人回复了什么。产品、开发和测试可以沿着 REQ-017 检查以下结果。
| 检查对象 | 通过条件 |
|---|---|
| 需求关联 | 话题能定位到同一正式需求，标题修改不会改变关联 |
| 首次领取 | 实际负责人、分支和开发中状态可核对 |
| 重复启动指令 | 返回已绑定分支，不再次创建或改写负责人 |
| 外部提交入口 | 已完成的提交、自测、MR被关联，没有重复执行 |
| 群内提交入口 | 调用真实工程入口，取得可追溯结果 |
| 版本对应 | 提交、自测及 MR 对应同一轮代码 |
| 状态写回 | 三项结果齐备才进入测试中，同一需求读回一致 |
| 交付材料 | 接手人能从原话题找到有效需求、代码、报告及 MR |
没有完成的项目标出当前结果和待补项，继续由约定人员处理。接手人需要看得出链路实际走到了哪里，才能安排下一步。
流程演示通过后，再用后续同类需求观察：开发是否减少了重复更新，接手人是否少了寻找材料的时间，新增核对和维护是否可接受。规则走通与收益成立，是需要分别检查的两件事。
下一段，从试点留下的缺口里选
首期结束后，再决定接聊天创建需求、自动建话题，还是细化整体提测和测试接收。
选择依据是这轮还有哪段工作需要重复维护，哪项材料经常缺失，哪个交接最值得继续改善。不要仅仅因为某个系统有接口，就把它加进下一轮。
移交给开发的成果可以很小：一张职责表，一份业务接入单，一套结果清单和验收记录。它们需要足够具体，让下一位同学知道要接哪段操作，以及产品会用什么结果判断完成。
把这一段做实，再扩大链路。工具数量可以慢慢增加，团队先获得一个能核对、能继续工作的交付结果。