📄 本页由源文件 skills/dev-flow/steps/step-5-execute.md 自动投影生成（单一权威源）。请勿直接编辑本页。

步骤 5：执行修改（严格遵循锁定计划）

本文件仅在执行步骤 5 时加载。执行完毕后输出完成标记 JSON，通过门控后加载步骤 5.5。 ⛔ 加载本文件前必须已通过编码前置硬卡点（step-router.md）。如果工作上下文不存在、.flow 文件不存在、或步骤 4 用户决策未完成 → 立即停止，回退到缺失的步骤。禁止以任何理由绕过此校验。

目标

按步骤 4 中用户已确认的锁定计划执行代码修改。

执行锁定原则

✅ 允许：按计划修改文件、修复执行中发现的 lint/类型错误
❌ 禁止：增加/删除计划外的步骤、改变技术方案、触碰"不做什么"中声明的区域
⚠️ 遇到计划无法执行的情况 → 暂停，说明原因后必须使用 ask_followup_question 弹出交互式选项让用户决策：

text

当前计划无法按预期执行，原因：{原因描述}。请选择：

选项	说明
🔄 调整计划	回到步骤 4，基于新情况调整方案和计划
🛠️ 我来处理	暂停流程，由我手动处理后告诉你继续
❌ 终止任务	终止本次任务

1. TDD 模式检查（执行前）

步骤 5 开始时，AI 评估当前任务是否适合 TDD 模式：

自动评估：扫描计划中的改动内容，识别是否包含纯逻辑函数/工具函数/Hooks 等适合 TDD 的场景
主动建议：识别到适用场景时，向用户建议开启 TDD 模式（默认关闭）
用户触发：用户说"用 TDD"/"写测试"等
加载规范：开启 TDD 模式时 → read_file("references/tdd-mode.md") 加载完整 TDD 流程

2. 修改后自检

每次写入文件后立即 read_lints 检查。

2.1 编码可读性规范（编码时强制遵循）

2026-05-21 新增。来源：嵌套三元、分号空格、JSX 内复杂逻辑的反复出现。

条件表达式：

❌ 禁止 ≥2 层嵌套三元（a ? X : (b ? Y : Z)）
✅ 拆分为独立变量 + if 早返回，或 useMemo
✅ 多个 if 分支体相同时，用 || 合并条件

JSX props：

❌ 禁止在 JSX props 中写超过单层三元的条件逻辑
❌ 禁止在 JSX 中使用 IIFE {(() => { ... })()}
✅ 条件派生值提取为 useMemo 变量，JSX 中直接引用

useState 初始值：

❌ useState(a ? X : (b ? Y : Z)) — 嵌套三元难读
✅ useState(() => { if (a) return X; if (b) return Y; return Z; }) — 惰性初始化 + if 早返回

格式：

分号前禁止空格：return 290; ✅ / return 290 ; ❌
useMemo 逗号紧跟闭括号：}, [deps]); ✅ / }\n, [deps]); ❌

2.5 步骤 5 内部多轮修复（2026-05-13 新增）

场景定义：步骤 5 执行期间（status 非 completed/delivered/testing），因用户自测、联调反馈、Code Review 反馈等原因，在同一轮次内进行多次代码修改。与「迭代修复」（iteration-fix）的区别是不涉及轮次递增、场景分类、分支切换，但质量检查规则完全一样。

触发信号（满足任一）

用户在步骤 5 进行中给出新的修复反馈（"这里还有个问题"/"联调发现 xxx"/"CR 反馈"）
用户提供截图/日志指出当前改动的缺陷
AI 自测发现需要追加修改

行为规则

每个反馈改完都走 5.5：

text

用户反馈 A → 编码修复 A → 执行 5.5（L1 审查）→ 汇报完成
用户反馈 B → 编码修复 B → 执行 5.5（L1 审查）→ 汇报完成

用户一次性给多个反馈时，批量改完再走 5.5：

text

用户反馈 A+B+C → 编码修复 A → 编码修复 B → 编码修复 C → 执行 5.5（L1 审查，覆盖 A+B+C 所有改动文件）→ 汇报完成

判断标准：用户一条消息中包含多个修复点 = 批量；用户分多条消息逐个反馈 = 每个都走。

5.5 执行规范（多轮修复中）

调用 use_skill('code-review') 执行 L1 基础审查（完整 8 项检查）
🔴 问题必须当场修复 → 重新审查
🟡 建议项自动跳过（不弹交互选项），减少打断
不输出完成标记 JSON、不弹推进选项——静默执行后直接汇报结果
commit/收尾前的最终 5.5 仍需输出完成标记并走门控校验

5.5 静默累计 ≥3 必弹 dev:sync 提醒（硬规则）：

计数器 silent_55_count 由 scripts/hooks/post-step.sh 物理层兜底维护（见 case 5.5|5_5 分支），AI 仅消费不维护
静默路径判定：post-step.sh 收到 STEP_ID=5.5 但 validate-output.sh 未生成 .step-5_5.validated.json 时，自增 .flow.silent_55_count
AI 在每次响应前必须读取 .flow.silent_55_count（用 df_get_flow_field）；累计 ≥3 → 必须 ask_followup_question 弹出 dev:sync 提醒（场景 A），不得静默推进
重置时机：用户接受 dev:sync 完成同步 → 归零；流程进入步骤 7 H 环节 → 归零
完整规范 → references/in-flow-sync.md §1.2；权威条款 → ~/.codebuddy/rules/AI行为规范.mdc §「主动文档同步弹框提醒」
🔴 dev:sync ≠ 5.5b 替代品：禁止以"反正 dev:sync 会兜底"为由偷工 5.5b

与迭代修复（iteration-fix）的对比

维度	步骤 5 内部多轮修复	迭代修复（iteration-fix）
触发条件	status = in_progress	status = completed/delivered/testing
轮次递增	❌ 同一轮内	✅ iteration+1
场景分类	❌ 不需要	✅ 提测 vs 上线
分支策略	继续当前分支	可能需要 bugfix 分支
devlog Round	不新建	新建 Round N
5.5 L1 审查	✅ 每轮必走	✅ 每轮必走
🟡 建议项	自动跳过	自动跳过

3. 代码安全规则（强制）

执行修改时必须遵循 → read_file("references/code-safety-rules.md") 加载完整规则。包含：

大文件代码移动安全规则（>500 行文件强制）
代码修改后即时验证+审查规则

❌ 禁止修改代码后不验证就进入下一步或向用户汇报完成 ❌ 禁止连续多次修改后才批量验证

4. 场景加载辅助技能

场景	技能/工具
React 组件/Hooks	`frontend-patterns`
TS/JS 代码	`coding-standards`
E2E 验证	`e2e-testing`
浏览器操作/调试（自动化、页面交互、截图、已登录环境、性能分析、跨浏览器）	`use_skill('browser-toolkit')`（基于任务特征在 agent-browser / Playwright / Chrome DevTools 间智能路由）
编码中需要模块知识参考	`knowledge-loop`（检索模式，按文件类型动态加载）

5. 场景加载参考规范（按需）

场景	加载指令
涉及 UI 组件库使用	`read_file("references/component-library.md")`
涉及 React 开发	`read_file("references/react.md")`

🔀 可并行子任务

⚠️ 此处「并行」指主 Agent 并行工具调用（并行读取多个待改文件），非子 Agent 并行写入。文件写入始终由主 Agent 串行执行。子 Agent 不参与步骤 5（详见 shared-rules.md §3「子代理调度指引 > 步骤 5」）。

当计划包含 ≥3 个独立子任务（不同文件/不同模块）时，可并行执行：

并行任务	说明
文件 A 修改	按计划修改文件 A + 即时 lint 检查
文件 B 修改	按计划修改文件 B + 即时 lint 检查
文件 C 修改	按计划修改文件 C + 即时 lint 检查

⏳ 全部完成后汇聚 → 做一致性检查 + 跨文件依赖验证 ⚠️ 有依赖关系的文件（如 A import B）必须串行：先 B 后 A

并行任务审查（多任务场景）

当步骤 5 涉及 ≥3 个子任务且使用并行调度时（按 shared-rules.md §3 检测到的执行模式），每个并行任务完成后执行规范合规自检：

自检清单（并行任务完成后立即执行）：

[ ] 改动是否在锁定计划范围内（无计划外变更）
[ ] 是否遵循项目已有代码风格
[ ] 是否处理了边界条件（空值/undefined/异常输入）
[ ] 链式属性访问是否使用可选链 ?.
[ ] 是否有未清理的调试代码（console.log/debugger）

自检未通过：标记问题点，汇总后统一修复
自检通过：合并结果时做最终一致性检查

此机制是 L1 审查的前置补充，减少步骤 5.5/6 的回退概率。

⛔ 退出自检清单（逐项口播确认后才能输出完成 JSON）

在输出完成标记 JSON 之前，逐项确认并口播：

[ ] TDD 模式检查：已完成评估（开启/跳过）？
[ ] 所有计划步骤已执行？plan_steps_executed = "N/M"（N > 0）？
[ ] 每次文件修改后 read_lints 已执行？
[ ] lint_errors_remaining = 0（有 lint 错误必须先修复）？
[ ] 计划外变更（unplanned_changes）已如实记录？
[ ] 步骤 5 内部多轮修复（如有）已完成对应的 5.5 审查？
[ ] 代码安全规则已遵循（大文件安全 / 即时验证）？
[ ] 编码可读性规范已遵循（嵌套三元/JSX/分号空格）？
[ ] files_modified 非空数组？
[ ] 上述全部完成 → 才可输出完成标记 JSON

必须输出

步骤推进选项（标准模式必须）

按 steps/step-router.md §「步骤流转交互规则」，完成标记 JSON 输出并状态同步后，若 interaction_mode 为 streamlined 则静默自动进入步骤 5.5（references/interaction-mode.md §🟢）；标准模式下必须调用 ask_followup_question 弹出推进选项：

选项	说明
▶️ 继续步骤 5.5（编码后置钩子）	编码完成，进入 L1 审查+文档同步+自检
⏸️ 暂停，我有补充/疑问	暂停等待用户输入（如发现计划外问题需讨论）
🔁 回退步骤 4 调整方案	执行中发现方案需要调整

精简模式豁免：步骤 5→5.5 属于 step-router.md §「步骤流转交互规则」豁免范围，精简模式下自动推进。

结构化完成标记（必须输出，缺字段视为未完成）

json

{
"step": 5,
"name": "执行修改",
"status": "completed | partial | blocked",
"outputs": {
"plan_steps_executed": "已执行的计划步骤数 / 总步骤数",
"files_modified": ["实际修改的文件列表"],
"files_created": ["实际新增的文件列表"],
"lint_errors_remaining": 0,
"unplanned_changes": "none | 描述计划外变更（如有）"
},
"working_context_updated": true,
"next_step": "5.5"
}

完成标记校验规则：

plan_steps_executed 格式为 "N/M"，N 必须 > 0
lint_errors_remaining 必须为 0（有 lint 错误必须先修复）
unplanned_changes 为 none 或有合理说明
status 为 partial 时表示部分执行，记录已执行范围
status 为 blocked 时表示计划无法执行，需回退步骤 4

步骤 5：执行修改（严格遵循锁定计划） ​

目标 ​

执行锁定原则 ​

1. TDD 模式检查（执行前） ​

2. 修改后自检 ​

2.1 编码可读性规范（编码时强制遵循） ​

2.5 步骤 5 内部多轮修复（2026-05-13 新增） ​

触发信号（满足任一） ​

行为规则 ​

5.5 执行规范（多轮修复中） ​

与迭代修复（iteration-fix）的对比 ​

3. 代码安全规则（强制） ​

4. 场景加载辅助技能 ​

5. 场景加载参考规范（按需） ​

🔀 可并行子任务 ​

并行任务审查（多任务场景） ​

⛔ 退出自检清单（逐项口播确认后才能输出完成 JSON） ​

必须输出 ​

步骤推进选项（标准模式必须） ​

结构化完成标记（必须输出，缺字段视为未完成） ​

步骤 5：执行修改（严格遵循锁定计划）

目标

执行锁定原则

1. TDD 模式检查（执行前）

2. 修改后自检

2.1 编码可读性规范（编码时强制遵循）

2.5 步骤 5 内部多轮修复（2026-05-13 新增）

触发信号（满足任一）

行为规则

5.5 执行规范（多轮修复中）

与迭代修复（iteration-fix）的对比

3. 代码安全规则（强制）

4. 场景加载辅助技能

5. 场景加载参考规范（按需）

🔀 可并行子任务

并行任务审查（多任务场景）

⛔ 退出自检清单（逐项口播确认后才能输出完成 JSON）

必须输出

步骤推进选项（标准模式必须）

结构化完成标记（必须输出，缺字段视为未完成）