让 AI 稳定交付高质量工程任务：九步工作流、路由式指南与评审闭环

质量一致性的来源不是更好的模型，而是被固化的执行路径。

同一个工程任务交给 AI，这一次它规规矩矩读设计文档、写测试、走评审；下一次直接开写，顺手改了三个无关文件，还说”测试已通过”。本文讲清楚我们如何用四层结构把这种方差压下去。

问题：三条被随机填空的路径

为什么 AI 交付质量时好时坏？因为下面三件事没有被写死，每次都被随机决定：

• 要不要先读设计文档与仓库约定；
• 改完要不要跑测试；
• 发现设计偏差算不算自己的活。

代价有三重：质量随机、过程不可审计（事后无法还原这次走了哪几步）、规模不经济（连续多个任务时，人变成流水线上的确认按钮）。

在提示词里多写几句要求之所以无效，是因为要求没有被编码成可枚举、可打勾、有惩罚的结构。

方案选型

选择第三条的判断依据是：工程任务高度模式化，因此可标准化；而标准化恰是 AI 最擅长稳定复现的东西。

结构：四层 + 一条九步主干

角色定义层 → 模式开关层 → 路由式指南层 → 确定性脚本层
   (who)        (mode)       (rules by type)    (fixed sequences)
                                    ↓
                        九步标准工作流主干

• 角色定义层：先声明 AI 是一名对单个任务从理解到验证、再到状态更新全程负责的工程师，偏好小而稳的改动。
• 模式开关层：开工先判定”人在场 / 无人值守”，结果记入任务进度；无人值守时不阻塞等待，把待确认项记下来继续走。
• 路由式指南层：公共规则每个任务强制加载（尊重已批准的设计、范围纪律、测试是门槛、评审与提交纪律、绝不提交密钥），再按任务类型叠加专属指南——新功能防范围蔓延与端到端缺口；修缺陷先确认根因，不明则转诊断流程；优化任务回归是头号风险。
• 确定性脚本层：建隔离工作树、提交推送开 PR、云端合并、清理回收全部脚本化。原则是判断题留给 AI，流程题交给脚本。

主干是这个九步工作流：

1 读上下文        任务说明 + 设计文档 + 仓库约定 + 加载指南
2 写计划          改哪些文件 / 每文件怎么做 / 加哪些测试 / 最小安全序列
3 隔离实现        独立 worktree + 独占分支，先跑一遍既有 gate 验证环境
4 自验证          构建 / 检查 / 测试 + 代理侧核验；同一失败 ≤3 次重试
5 独立评审        回归 + 正确性 + 安全热点 + 测试有效性 + 范围纪律
6 生成摘要        唯一工件，PR 描述 / 状态 / 汇报三处复用
7 推送开 PR       仅云端合并，永不本地 merge 默认分支
8 更新状态        成功 merged=done；带阻塞则 blocked 且 PR 不合并
9 清理核对        删 worktree（确认目录真从磁盘消失）+ 分支与上游同步

两道闸门

闸门一：自验证带循环上限。 跑构建、检查与测试；测试覆盖不到的验收标准，用代理侧动作核验（发真实请求、查库、看构建产物），不允许”假设通过”。同一失败最多重试三次。

闸门二：独立评审带退出条件。 在完成实现且测试绿灯后，派独立评审者只看六项：回归、与验收标准的正确性、局部安全热点、测试是否真在测东西、日志与脱敏、范围纪律。核心是一条闭环规则：

任何一轮评审后只要改了代码——哪怕只改一行——都必须发起新一轮复审；循环只在”某轮之后无任何代码改动”时退出。

评审者必须独立核实发现，不能替实现者的分拣结论盖章；三轮封顶，仍有阻塞就停下如实记录，PR 保持不合并。

六条不变式

1. 绝不在默认分支写代码——任务分支加独立工作树。
2. 永不本地合并——进入默认分支的唯一入口是云端 PR 合并。
3. 测试是门槛——每条验收标准都有测试，套件不绿不评审、不提交。
4. 评审后凡改码必须重评——没有”就改了一行不用再看”。
5. 判断交给 AI，固定序列交给脚本——提示词里只留判断题。
6. 绝不编造验证结果——拿不到就记为阻塞或待人工确认。

批量编排：给违规定代价

逐个执行以下任务，全程无需人工介入：
- <任务1> / <任务2> / <任务3>

1. 目标：一次只做一个，完全做完再做下一个；禁止批量、合并或并行
2. 角色与技能绑定：只允许指定的角色定义与指定的技能完成
3. 开工前合规：读通完整工作流与规则；违规 / 遗漏 / 跳步 = 整个任务重做
4. 强制预读：组织约定、代理说明、仓库根目录约定文件
5. 产出：总结 + 逐任务的工作流合规清单；缺步即触发重做

没有真实代价的合规要求，在长执行链里形同虚设。

效果与反思

已确定拿到的是可审计性：模式判定、计划、评审轮次、阻塞全部留痕，事后可完整回放过程。量化指标尚未采集，登记三个信号：每任务平均返工轮次、首轮评审即通过的占比、编排执行中的违规重做次数。

三条反思：① 不该让模型即兴组织固定序列（抽成脚本后方差归零）；② 只写”发现问题就修”不写”改完必须重评”，评审会退化成仪式；③ 低估了编排层的难度。

可复用核查清单

• 每个任务写清目标、范围（IN/OUT）与验收标准
• 开工三件事：读任务与设计文档 → 读仓库约定 → 判定运行模式并留痕
• 公共规则强制加载 + 按类型叠加专属指南
• 固定序列全部脚本化，提示词里只留判断题
• 每条验收标准都有测试，套件不绿不进评审
• 评审写明维度与退出条件，改码即重评，轮数封顶
• 总结只生成一次，三处复用同一份
• 多任务逐个执行 + 绑定角色与技能 + 强制预读 + 逐任务合规清单
• 缺一步 = 整个任务重做

延伸阅读

接得住这套结构的下一步是把 DevOps 流水线本身接进来：自验证的那一步应该直接调用 CI 的同一套 gate，而不是在 Agent 侧重写一遍。欢迎 RSS 订阅，后续更新会同步到这里。

你的流水线最容易被悄悄跳过的是哪一步？欢迎留言交流。