第 014 篇里，我整理过一版 Codex 前端任务闭环。
第一版的核心链路是：
任务分流 → 定义结果 → 建立项目证据 → 设计计划 → 小步修改 → 分层验证 → 交付与沉淀
它解决了一个基础问题：不要让 Codex 从模糊需求直接跳到大面积改代码。
第 2 周继续往下拆以后，我发现只有顺序还不够。
真实前端任务不会沿一条直线稳定走到底：
-
读项目时会发现原计划范围不对；
-
查调用链时会发现局部组件实际属于公共契约；
-
差异审查会发现目标完成了，但修改已经越界；
-
构建通过以后，页面路径仍可能失败；
-
验证失败后，有时只需修一处，有时必须退回重新定义任务；
-
一次有效经验，也不一定适合直接写成长期规则。
所以第二版不再只回答"下一步做什么"，还要回答两个问题：
-
凭什么允许进入下一步；
-
新证据出现以后，应该退回哪一步。
我把这次升级概括成三条控制回路：证据回路、范围回路和纠偏回路。
第一版和第二版，区别不在步骤数量
如果只是把"调用链""差异审查""测试"继续追加到清单，流程会越来越长，却不一定更可靠。
第二版真正增加的是状态转换。
| 第一版关注 | 第二版增加 |
|---|---|
| 当前应该做什么 | 进入本步需要什么输入 |
| 本步产出什么 | 产出怎样证明可用 |
| 做完以后继续 | 什么情况必须暂停或退回 |
| 最后统一验收 | 每批改动都形成局部证据 |
| 发现问题再修 | 先分类错误，再选择返回节点 |
| 有经验就记录 | 先判断是否稳定、重复、可验证 |
流程第二版不是更重，而是让"继续"和"回退"都有依据。
第一条回路：证据回路
证据回路要求每一步都留下足以支持下一步的产物。
不是写很多说明，而是让结论可以复核。
任务定义的证据
-
用户结果；
-
必须改变和保持不变的行为；
-
允许范围与禁止范围；
-
已知事实、推断和未知项；
-
验收标准。
这些内容决定任务能否进入项目调查。
项目理解的证据
-
规则作用范围；
-
入口、职责和数据流；
-
同类实现与真实差异；
-
项目脚本和检查入口；
-
仍未确认的项目事实。
这些内容决定计划能否建立在仓库真实结构上。
实施过程的证据
-
本批唯一行为目标；
-
实际修改文件；
-
直接检查结果；
-
完整差异审查；
-
新发现与范围变化。
这些内容决定是否可以进入下一批修改。
最终交付的证据
-
行为和数据结果；
-
类型、Lint、测试与构建的实际范围；
-
真实页面路径；
-
受影响原有行为的回归；
-
未执行、无法判断和剩余风险。
这些内容决定"完成"是否成立。
证据回路的规则很简单：
上一步的输出，必须成为下一步的输入；最终交付必须能映射回最初目标。
如果中间有一段无法映射，就说明闭环在某个位置断了。
第二条回路：范围回路
前端任务最常见的问题之一，是范围在执行中悄悄扩大。
开始时只是"改一个字段"，后来进入类型、请求、回显、公共组件和多个调用方；开始时只是"修一个页面"，最后顺手调整了统一封装、全局样式和构建配置。
范围回路把三件事连起来：
调用链 → 影响范围 → 实际差异
调用链回答"谁有关"
查 Props、Emits、插槽、暴露方法、状态、请求、副作用、生命周期、DOM 和样式依赖，找到直接、间接和条件性关联。
影响范围回答"谁会变"
把关联位置区分为：
-
必须修改；
-
必须回归；
-
条件性验证；
-
观察记录；
-
明确排除。
实际差异回答"最终真的改了谁"
审查每一块差异属于：
-
目标变化；
-
必要支撑；
-
兼容调整；
-
无关变化。
范围回路要求这三份清单互相核对：
-
调用链中有直接影响，却没有进入计划，可能遗漏；
-
计划中没有依据，却出现在差异里，可能越界；
-
差异扩大到公共边界，原来的验证计划可能失效；
-
只标记"无需修改"的调用方，仍可能需要回归。
范围不是任务开始时确认一次就结束，而要在计划、每批修改和最终差异三个位置重复核对。
第三条回路：纠偏回路
第一版允许流程退回，但没有把错误类型与返回位置对应得足够具体。
第二版把错误分成五类：
| 错误类型 | 应返回的位置 | 典型动作 |
|---|---|---|
| 目标错误 | 任务卡与验收标准 | 重新定义目标并规划 |
| 范围错误 | 调用链、影响分析、差异审查 | 局部回退越界差异 |
| 契约错误 | 类型、接口和组件公开面 | 重建契约与兼容策略 |
| 局部实现错误 | 当前修改批次 | 聚焦修正并直接验证 |
| 环境错误 | 检查入口与运行条件 | 恢复环境或记录阻断 |
纠偏回路不接受一句泛化的"继续修复"。
它要求先固定错误现场：
-
原目标；
-
当前差异；
-
触发路径；
-
期望与实际；
-
已确认事实；
-
仍可保留的成果。
然后只选择三种动作之一：
-
聚焦修正；
-
局部回退到可信边界；
-
带着新证据重新规划。
这条回路的目标，是让错误回到真正出问题的节点，而不是在流程末端不断叠加补丁。
第二版完整状态图
我把前端任务拆成十个状态。
状态 0：任务分流
判断目标明确度、项目证据、错误影响和可验证性，决定：直接实施、分段确认、先调查，还是由人先作决定。
进入条件
收到明确请求或需要调查的问题。
输出
AI 与人的职责、风险等级、执行路线。
暂停条件
业务决策缺失，继续实施会导致不同结果。
状态 1：任务卡
写清用户结果、改变项、保持不变项、允许范围、禁止范围、事实、未知项和验收标准。
继续条件
关键目标可以观察，关键未知项不会改变实现方向。
返回条件
后续发现需求、契约或优先级变化。
状态 2：最小项目地图
读取适用规则、目录、配置、入口、职责、数据流、参考实现和真实检查脚本。
继续条件
知道从哪里改、为什么在这里改、改完到哪里验证。
返回条件
发现目标模块与原理解不同，或项目存在多个冲突范式。
状态 3：调用链与影响范围
追踪公开契约、调用方、状态、副作用、生命周期、DOM 与验证入口，划分修改、回归和排除范围。
继续条件
直接影响有处理方案，公共边界与未知项得到明确标记。
返回条件
风险从局部升级为公共、权限、安全或难回退修改，需要重新分流。
状态 4：带检查点的计划
按可验证行为拆批次。每一步写清单一结果、允许文件、完成证据和暂停条件。
继续条件
每批都能单独验证，顺序依赖清楚。
返回条件
计划依赖未确认契约，或验证方式无法覆盖目标风险。
状态 5：小批修改
Codex 只完成当前行为增量，不夹带无关重构。
每批输出
-
实际差异；
-
直接检查；
-
新发现；
-
下一动作。
返回条件
当前批次未通过，或出现计划外公共变化。
状态 6：差异审查
从正确性、范围和副作用三个层面审查完整差异，并按真实影响给问题排序。
继续条件
每块差异能映射到目标、必要支撑或明确兼容要求；阻断问题已经解决。
返回条件
发现遗漏、越界、公共契约变化或无法解释的差异。
状态 7：分层验证
根据任务风险分配类型检查、Lint、测试、构建和页面验证的职责。
输出状态
-
已通过；
-
未通过；
-
未执行；
-
无法判断。
继续条件
关键风险有直接证据，未验证项不会被包装成通过。
返回条件
验证失败，进入错误分类；环境不足，回到检查条件或明确阻断。
状态 8：纠偏
把失败归类为目标、范围、契约、实现或环境错误，选择聚焦修正、局部回退或重新规划。
输出
-
错误分类与依据；
-
保留和移除的差异；
-
返回节点；
-
本轮最小修改；
-
重新验证路径。
纠偏成功后，不是直接跳到交付，而是回到受影响节点重新通过证据链。
状态 9：交付
交付内容不复述全部过程，只保留决策需要的信息：
-
完成的用户结果；
-
实际修改范围；
-
已运行检查与页面路径；
-
差异审查结论；
-
未验证项、限制和剩余风险。
完成条件
目标、差异和证据可以一一映射，未知项已如实保留。
状态 10：沉淀候选
任务结束后，不立即把全部过程写进规则。
先判断：
-
是否重复；
-
稳定骨架是否清楚；
-
作用范围是否明确；
-
是否能够验证。
再决定放进任务记录、项目文档、AGENTS.md、项目脚本或 Skill。
一张返回路径表
第二版最有用的部分，不是状态数量，而是返回关系。
| 新发现 | 返回位置 | 为什么 |
|---|---|---|
| 用户结果或保持不变项改变 | 状态 1 | 原任务卡失效 |
| 项目职责与原理解冲突 | 状态 2 | 需要重新建立仓库事实 |
| 公共调用方比预期更多 | 状态 0 或 3 | 风险升级或影响范围扩大 |
| 实际差异出现计划外文件 | 状态 3 或 4 | 影响范围或计划需要调整 |
| 局部实现验证失败 | 状态 5 | 在当前批次聚焦修正 |
| 公开契约判断错误 | 状态 3 | 重新查调用方与兼容范围 |
| 构建因环境缺失失败 | 状态 2 或 7 | 恢复真实检查入口与条件 |
| 页面行为偏离验收 | 状态 1、4 或 5 | 根据错误类型返回对应节点 |
| 一次经验准备长期复用 | 状态 10 | 先过沉淀门槛 |
流程允许退回，才算闭环；只能向前的清单只是流水线。
我会让每个批次交付一张"最小状态卡"
不需要每次维护十份长文档。实际协作中，我会压缩成下面这张状态卡：
# 当前任务状态卡
## 当前节点
- 状态：
- 本轮唯一目标：
## 当前依据
- 任务目标：
- 项目事实：
- 影响范围：
- 允许与禁止范围：
## 本轮结果
- 实际差异：
- 直接检查：
- 差异审查：
- 新发现：
## 决策
- 继续 / 聚焦修正 / 局部回退 / 重新规划 / 证据不足
- 下一节点：
- 依据：
## 未验证
- 项目：
- 原因：
- 是否阻断：它让 Codex 在多轮任务中始终知道：现在在哪一步，为什么可以继续，出现什么要退回。
哪些小任务可以压缩流程
第二版不是要求每次都填写十个状态。
局部、低风险、证据充分的任务，可以合并：
任务卡与项目地图 → 单批修改 → 差异审查与直接验证 → 交付
但我不会省掉四个核心关系：
-
目标与差异要对应；
-
差异与影响范围要对应；
-
风险与验证证据要对应；
-
错误与返回节点要对应。
任务小，可以减少文档；不能取消判断。
公共组件、接口契约、权限、全局状态和难回退修改，则需要保留完整的影响、差异和纠偏回路。
第二版仍然不能替人决定什么
这套闭环可以暴露问题、控制范围和组织证据，但不能替代人的业务判断。
它不能自行决定：
-
多种合理行为中业务接受哪一种；
-
当前版本愿意承担多少兼容成本；
-
哪些未验证项可以接受；
-
是否为了截止时间延后非阻断问题；
-
一个项目约定是否应该升级为团队长期规范。
流程的价值不是消除判断，而是让判断发生在正确节点，并留下依据。
写在最后
Codex 前端任务闭环第二版，真正新增的不是更多步骤，而是三条控制回路：
-
证据回路：每一步凭什么继续；
-
范围回路：调用链、影响范围和实际差异是否一致；
-
纠偏回路：错误应该退回哪个节点，而不是在末端不断补丁。
最后再加一道沉淀判断，区分任务证据、项目规则、可复用流程和临时选择。
到这里，第 2 周从"接手陌生项目先看什么"开始，已经走完项目理解、规则约束、调用链、影响范围、差异审查、分层验证、错误纠偏和工作流沉淀。
下一篇会进入第二阶段的第 3 周：把这套闭环放进 Vue3 与 Element Plus 后台列表。第一步不是让 AI 直接拼搜索框和 el-table，而是先识别页面壳、搜索状态、列表状态、接口转换、表格展示、分页和弹窗分别由谁负责。
本系列持续更新。接下来会从方法框架进入高频业务页面，逐项验证闭环在真实前端结构中的适用边界。