执行阶段

你已经把执行前（Context Freeze）做到接近极致了，但现实是：

再完美的上下文，如果执行阶段不受控，AI 仍然会“写着写着就跑偏”。

所以我们现在讨论的已经不是“理解问题”，而是：

如何在编码“进行中”，持续约束 AI 的行为方式、节奏与决策粒度。

下面我会给你一个工程化、可落地的答案，不是理念。

---

一句话结论（先给结论）

执行期的核心不是“继续给信息”，而是：
把“写代码”拆解成一组可中断、可校验、可回滚的受控动作。

也就是说：
把 AI 从“一次性代码生成器”，变成“受控执行的工程协作者”。

---

一、执行期的三大失控来源（必须先认清）

在编码阶段，AI 失控通常来自三点：

1. 执行粒度过大（一次改太多）
2. 隐性决策不可见（为什么这么写你不知道）
3. 没有“停下来检查”的机制

执行期的治理，本质上就是解决这三点。

---

二、执行期治理的四个核心机制（重点）

---

1️⃣ 编码节奏控制：Step-by-Step Execution

禁止“直接写最终代码”

强制执行模型

Plan → Diff → Check → Apply

执行规则（给 AI 的硬约束）

• 每一步只做 一个最小可验证修改

• 每一步必须说明：

  • 修改动机
  • 修改范围
  • 风险点

示例执行指令

【执行约束】
- 不允许一次性输出完整实现
- 每一步仅提交一个 logical change
- 等待确认后再继续下一步

这是在模拟人类资深工程师的工作节奏。

---

2️⃣ 显性化“实现意图”（Implementation Intent）

不允许“默默做决定”

每一段代码必须绑定“意图说明”

## Step 2 – 修改缓存失效逻辑

意图：
- 保证与旧行为完全一致
- 仅修复并发下的 NPE

涉及文件：
- CacheService.java

潜在风险：
- 线程安全

如果 AI 无法清晰表达意图：

说明它并没有真的理解这一改动

---

3️⃣ 执行期实时护栏（Live Guardrails）

把执行前的 Snapshot 变成“实时约束器”

示例执行期护栏 Prompt

执行中强制约束：
- 不修改 SNAPSHOT 中标记为“高风险”的目录
- 不引入新的公共 API
- 不新增第三方依赖
- 不扩大方法职责

关键点：
护栏不是一次性的，而是每一步都重复注入。

---

4️⃣ 中断与升级机制（Interrupt & Escalation）

允许 AI “停下来求救”，而不是“硬写”

触发中断的标准（必须显式定义）

当出现以下任一情况，必须中断执行：
- 设计文档与代码现状不一致
- 遇到未覆盖的业务分支
- 需要做结构性决策

中断后的唯一合法行为：

停止编码 → 描述问题 → 提出选项 → 等待决策

---

三、把“执行期”结构化成一个状态机

这是一个非常重要的认知升级。

AI 编码状态机（Execution FSM）

INIT
 ↓
PLAN（计划）
 ↓
APPLY_STEP（最小变更）
 ↓
VERIFY（自检）
 ↓
REVIEW_GATE（人工/规则）
 ↓
NEXT_STEP / HALT

AI 不再是“生成器”，而是“执行状态机”。

---

四、最小可用的《AI 编码执行规范》

你可以直接在项目中放一个：

AI_EXECUTION_RULES.md

核心内容：

- 禁止一次性大规模修改
- 每次修改必须说明意图
- 每次修改必须可回滚
- 不确定即中断
- 默认保守

---

五、为什么这套东西有效？

因为它解决了 AI 编码的根因问题：

问题	传统 AI	你的体系
改动不可控	一次性生成	拆解为可审计步骤
风险不可见	隐性决策	显性意图 + 风险
错误发现太晚	写完才看	每一步校验

---

六、一个非常重要的判断

执行期治理，才是 AI 编码真正的“护城河”。

模型会越来越强
上下文会越来越大
但“如何写”永远需要工程约束

参考资料