把”生成→执行→采错→反馈→再修→再验”包装成可重入的反馈回路，这条自动修复循环（Auto-fix Loop）路径在 2025 年已经是 AI 编程助手（Cursor、Claude Code、Devin、DeepSeek-TUI 等）共性的工程范式。它核心是用编译错误、单测结果、lint 输出这些可机读的客观判据驱动模型修改，而不是让模型自己”感觉修好了”。设计上真正的难点不在循环本身，而在多重退出策略的叠加和防震荡机制，否则模型会”改 A 坏 B”反复横跳，或在局部最优里无限烧 token。
一、闭环的四个阶段
自动修复循环分四阶段推进。每一阶段都有可机读的产出物，避免循环变成”黑盒自评”。
| 阶段 | 输入 | 输出 | 关键动作 |
|---|---|---|---|
| 生成 | 任务描述、上轮错误 | 代码补丁 | Diff 模式生成，最小改动 |
| 验证 | 补丁、命令配置 | 退出码、日志、单测报告 | 跑构建、类型检查、单测 |
| 采错 | 失败日志 | 结构化错误列表 | 截断、解析、定位文件行号 |
| 反馈 | 错误摘要 | 下轮 Prompt | 把原始错误喂回模型 |
注意：第 2 阶段必须用”外部工具”而非”模型自评”来判成功。模型判断”修好了”在生产里是严重的停机条件，因为它极擅长把”没修好”包装成”看起来很自信”。
下面是一段最小可运行的循环伪代码（Python 风格）：
def auto_fix_loop(task, max_rounds=5, budget_tokens=200_000):
last_fingerprint = None
for round_idx in range(max_rounds):
# 1. 生成补丁
patch = llm_generate(task, last_error=last_fingerprint)
# 2. 应用补丁
apply_patch(patch)
# 3. 验证（外部命令）
result = run(["npm", "test"]) # 或 pytest / go test / cargo test
if result.exit_code == 0:
return SUCCESS
# 4. 采错 + 指纹化
err = parse_errors(result.stderr)
fingerprint = hash(err.summary)
if fingerprint == last_fingerprint:
return STUCK # 触发卡住退出
last_fingerprint = fingerprint
# 5. 反馈给下轮
task = inject_error_context(task, err)
return EXHAUSTED # 达到最大轮次这段代码演示了”指纹化错误”这个关键技巧：用错误摘要的哈希判断是否陷入局部最优，比维护完整错误列表便宜得多。
二、退出策略的四种条件
循环必须有界。生产实践上通常叠加四种条件，取”先满足者”生效。
| 退出条件 | 触发 | 优先级 | 工程含义 |
|---|---|---|---|
| 成功退出 | 全部验证通过 | 最高 | 自然终止，输出结果 |
| 进展停滞 | 错误指纹连续 N 轮不变 | 高 | 判定卡住，转人工 |
| 退化检测 | 错误数或严重度上升 | 高 | 触发回滚到上一可用版本 |
| 资源熔断 | 超时/超 token 预算/超最大轮次 | 中 | 强制终止，留现场给人工 |
四种条件按从上到下的顺序排，是因为”成功”是唯一的好结局，其他三种都意味着”救场”。优先级倒过来设很容易让系统在卡住时继续烧 token 直到熔断，损失大量成本。
2.1 进展停滞的指纹策略
连续 N 轮错误指纹相同（典型 N=2 或 N=3）说明模型在同一个坑里打转。指纹不需要复杂：对错误摘要做规范化（去路径前缀、去行号、合并同类），然后哈希即可。如果两轮错误集合几乎相同但顺序不同，相似度阈值可以放宽到 80%-90%。
2.2 退化检测的关键信号
退化检测比进展停滞更隐蔽：模型可能每次都”看起来在进步”，但本轮的失败数比上轮多。最直观的判据是错误数量与严重级别两个维度同时观察——任一恶化就回滚。工程上的做法是每次只提交”如果失败就回滚”的原子事务，避免”越改越烂”的累积污染。
三、防震荡的三道闸
| 闸口 | 手段 | 防什么 |
|---|---|---|
| 最小改动 | Diff 模式生成、限制修改文件数 | 防”小修变成大重构” |
| 回归测试 | 已通过的用例必跑 | 防”改 A 坏 B” |
| 快照回滚 | 每次验证前 git stash | 防”累积污染” |
三道闸可以叠加使用。最小改动是最便宜的一道闸，它在 Prompt 层就能约束——”只修改报错文件，不要重构无关代码”。
四、验证信号的分层
验证不能只跑单测。一套稳健的验证栈通常包含四层：
- 编译/构建：语法、依赖、是否能产出可运行产物；
- 类型检查与 lint：静态层面的错误与风格；
- 单元测试与集成测试：行为是否正确；
- 运行时执行：是否抛异常、性能是否可接受。
每层产出的报错格式差异很大：编译错误有行列号、测试失败有断言差异、lint 警告有规则编号。把这些异构信号统一成结构化错误对象（包含 file/line/severity/message）再喂回模型，定位准确率远高于塞一坨原始日志。
五、几类工具的差异
| 工具 | 默认最大轮次 | 验证层 | 退出策略完整度 |
|---|---|---|---|
| Claude Code | 5-10 | 自定义命令链 | 完整，支持卡住检测 |
| Cursor Composer | 3-5 | 单测 + lint | 偏简单 |
| Devin | 可配置 | 构建 + 单测 + 端到端 | 较完整 |
| DeepSeek-TUI | 5 | 预设命令 | 完整，支持错误模式收敛 |
| IDE 内联补全 | 1 | 即时类型/语法 | 无循环 |
经验上，工具默认轮次大多落在 3-10 之间，3 是”够用但容易卡住”的下界，10 是”够用但成本不必要”的上界。多数生产团队会调到一个中间值（如 5-6），并配合卡住检测与回滚。
六、几个易错点
把”模型说修好了”当成终止条件是工程上最危险的反模式之一。语言模型极擅长把”没修好”包装成”看起来很自信”，所以验证必须外部化。第二个易错点是让模型”自由发挥修改范围”：失败次数一多，模型倾向于扩大改动范围去”找根因”，但这通常会把无关代码搞坏。第三个是忽略”不可观测错误”：循环对编译错误、单测失败有效，对业务逻辑错误、并发问题几乎无效——这类问题需要专门的测试或形式化校验补充。
常见问题（FAQ）
Q1：最大重试轮次设多少合适？
经验上 3-10 轮常见，5 轮是平衡成本与覆盖率的常用值。
Q2：进展停滞只能靠指纹判断吗？
还可以用错误集合的相似度、修复前后行覆盖率变化做补充判据。
Q3：自动修复能完全替代人工调试吗？
不能。不可观测错误、跨模块设计缺陷仍需人工介入，循环应设计为”卡住即转人工”而非”无限重试”。
