本文是「AI 效能」系列的第五篇，讨论流程边界、初始化加速与工程目录之后，自动链内部到底怎么组织。能力边界见 AI 自动开发的架构设计，状态推进见 AI 效能流程总设计，初始化见 all-repos 本地镜像。
这篇文章解决一个问题：把一条研发流水线交给 AI 执行时，怎样组织每一步，才能让产物可以被检查、被交接、被打回重做。它适合已经有一份稳定需求来源、固定的代码仓库和测试入口，想把重复环节交给 AI 的工程团队；不适合需求还在口头流转、仓库边界不清、没有可用测试入口的场景，也不适合直接承接跨模块的复杂需求。
需要先说明边界：本文按标准研发流程描述架构，构建、测试、发布等环节的落地程度取决于实际运行环境。文中给出的是一条可检查的链路，不是「交给 AI 就无人值守」的承诺；人工验收始终保留在链路末端。
先给出答案
一条自动 Loop 只需要三个节点：PRD 把标准任务变成可检查的需求，DEV 把需求变成代码提交，TEST 用白盒审查证明代码可以交付。三个节点都走同一套动作模型：in 准备环境，do 产出内容，out 校验交接。节点自己不写规则，规则放在原子能力里，节点之间靠交接物而不是对话推进。
关键要点
- 三个自动节点：PRD → DEV → TEST，TEST 完成即 Loop 结束。
- 每个节点统一走
in / do / out，这是 IPO 模式（输入、处理、输出）的简化命名。 - 节点只编排：9 个编排 Skill 决定顺序，18 个原子能力承担检查与产出。
- 节点之间靠
handoff交接物推进，不依赖对话上下文。 - 门禁不通过则打回对应节点重跑，失败不越过人工。
三个节点与一条流水线
AI Loop 位于上游需求流程与下游人工交付之间：上游把需求变成标准任务，Loop 产出 PRD、代码与测试报告，下游负责发布、验收与归档。
| 节点 | 角色 | 目标 | 核心产物 |
|---|---|---|---|
| PRD | 产品工程师 | 把标准任务变成可检查的 PRD | prd.md 与交接物 |
| DEV | 交付工程师 | 把 PRD 变成可交付的代码 | 目标分支提交、部署清单初稿 |
| TEST | 交付工程师 | 用白盒审查证明代码可以交付 | 测试报告、完整部署清单 |
三个节点全部完成后，current_node、current_action 与 blocked_reason 均为空，自动流程停止，任务交给下游人工。
每个节点都走 in / do / out
| 动作 | 职责 | 产物 |
|---|---|---|
in |
准备环境：工作区、知识物料、仓库、会话 | 就绪的执行现场 |
do |
产出内容：调用 Agent 完成一次执行 | PRD、代码改动、测试报告 |
out |
校验交接：按门禁检查产物并写入交接物 | {node}-handoff.json |
这套模型的价值在于定位问题：任何节点出问题，都能先判断是环境没准备好、内容没产出，还是交接没通过，而不是笼统地说「AI 没做好」。
节点之间靠交接物推进
每个节点在出口写一份 {node}-handoff.json，引擎读取其中的 result 决定是否进入下一站。对话会丢失、会被改写，文件不会：交接物可审计、可重跑，隔一天再看还是同一个结论，服务重启后也能按节点边界恢复。
门禁不通过就打回
out 是门禁。门禁不通过，打回对应节点重新跑，而不是让人临时补一版，也不是让后面的节点带着问题继续走。业务返工自动回退，返工原因写入 last_error；返工耗尽或技术失败转为阻断，写 blocked_reason 并等待人工恢复。
AI 物料：编排与原子能力
Loop 的执行能力不在业务服务里，而在与业务解耦的物料里，分两层。
| 层 | 职责 | 数量 |
|---|---|---|
| 编排 Skill | 每个节点的 in、do、out 各一个，只声明调用哪些能力、按什么顺序 |
9 个 |
| 原子能力 | 承担具体的检查、产出与交接物写入，可跨节点复用 | 18 个 |
编排与能力之间用 pipeline.yaml 连接。每个节点 Skill 配一份 pipeline，列出要调用的原子能力及顺序。
| 节点 | in | do | out |
|---|---|---|---|
| PRD | pm-in |
pm-do：生成 PRD |
pm-out：结构检查与质量审查 |
| DEV | dev-in |
dev-do：实现代码 |
dev-out：代码检查、构建与部署清单 |
| TEST | test-in |
test-do：白盒审查 |
test-out：报告判定 |
三条物料原则：编排只管顺序，能力可复用，与业务解耦。业务服务只决定在哪个节点注入哪些物料，不往 Skill 里塞业务规则。
三个节点各自做什么
PRD 节点
| 动作 | 做什么 | 产出 |
|---|---|---|
in |
准备任务工作区，注入背景知识、规范与 Loop 技能，建立 Agent 会话 | 就绪的执行环境 |
do |
按编排生成 PRD，并写明验证分类与入口覆盖 | prd.md |
out |
结构检查加独立质量审查，通过后写入交接物 | prd-handoff.json |
PRD 除需求内容外，还要写明验证分类与入口覆盖，作为研发与测试的核对依据。质量审查由独立审查官完成，只读产物、只写结论，不和写 PRD 的 Agent 共用上下文。
DEV 节点
| 动作 | 做什么 | 产出 |
|---|---|---|
in |
确定目标仓库与分支，从本地仓库镜像拉取最新代码 | 交付上下文 |
do |
按编排实现代码，核对仓库与入口覆盖 | 代码改动 |
out |
检查范围、符号与公共组件，安装依赖并构建，生成部署清单，通过后提交推送 | 目标分支提交 |
一个关键设计：Agent 只改代码，提交与推送由引擎在门禁通过后执行。只有过了门禁的改动才会进入目标分支，构建也在出口完成，确保交付后可以部署。
TEST 节点
| 动作 | 做什么 | 产出 |
|---|---|---|
in |
复用交付上下文，读取开发产物，确认测试范围 | 测试上下文 |
do |
独立审查官做白盒审查与源码影响面审查，补全部署清单 | testing-report.md |
out |
校验报告，并用 Intent 对报告做语义判定 | testing-handoff.json |
审查与开发分离：审查官只写报告，不改代码。门禁聚焦代码层问题，运行、联调、真机与人工验收项记录在报告中，交给下游完成。
怎样算跑通
搭一条最小自动链，可以按下面的顺序复现：
- 定义三个节点的
in / do / out，先只写步骤顺序，不写检查规则。 - 为每个节点准备一份 pipeline，把检查与产出拆成独立能力。
- 在
out统一写入交接物，让引擎只读交接物推进。 - 为每个节点设置返工上限与阻断出口，明确什么情况下停下来等人。
- 用一个真实的小任务跑完全链路，检查每个节点的产物是否可独立核对。
验收标准：
- 三个节点的产物都能在不看对话的情况下被理解和复核；
- 每个节点的门禁结论都落在交接物里，而不是口头说明；
- 任何一次打回都能定位到具体节点和具体原因；
- 阻断后人工能从指定节点恢复，而不是从头重跑。
边界与失败点
- 只适合边界清晰的任务：跨模块、需要业务判断的需求仍要人工协同，自动 Loop 不兜底。
- 依赖稳定的运行环境：构建、依赖安装、仓库镜像任一环节不可用，节点会直接失败，不做降级。
- 物料缺失不降级：知识物料或 Skill 同步失败时节点直接失败，宁可阻断，也不带着不完整的物料执行。
- 人工验收保留：真机、联调与验收项不由 Loop 判定，报告只记录，最终交付仍由人确认。
- 返工有上限：同一问题反复打回时转为阻断，避免无限循环消耗资源。