第 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而是先识别页面壳、搜索状态、列表状态、接口转换、表格展示、分页和弹窗分别由谁负责。本系列持续更新。接下来会从方法框架进入高频业务页面逐项验证闭环在真实前端结构中的适用边界。
（支持资料、图片参考_相关定制）_)
