什么是 AI 编程中的自动修复循环（Auto-fix Loop）？它的工作流程和退出策略怎么设计？

🏛 业务架构师

自动修复循环（Auto-fix Loop）指让 AI 自主执行"生成/修改→验证→分析失败→再修复"的闭环：代码改动后自动跑测试/构建/静态检查，失败则把错误信息喂回模型分析修复，循环直到通过或触发退出条件。它是 Agentic Engineering 的典型范式。

工作流程：触发（CI 失败/人工指派）→ 定位（读日志、读代码、生成修复假设）→ 修改（提交 patch）→ 验证（跑测试门禁）→ 通过则结束/失败则带错误上下文进入下一轮。

退出策略设计（这个题的关键）：

成功退出：全部检查通过 + 关键测试非侥幸通过（可加"重跑确认"）；
成本退出：最大循环次数（推荐 3~5 次）——经验表明多数可修复问题 2 轮内解决，超过 5 轮的多数是"修不对"而不是"没修完"；token/费用预算上限；总耗时上限；
停滞退出：连续两轮错误相同或 diff 几乎不变（检测相似度）——模型在原地打转，继续是烧钱；
升级退出：失败超阈值转人工，附完整尝试记录（改了什么、为什么失败）——让接手的人不从零开始；
安全退出：修改面超限（动到无关模块）、风险评分升高时中止。

业务视角：Auto-fix 的价值度量是"自动修复率×节省人力 - token成本 - 引入回归的风险"。门禁（测试覆盖）不健全的团队慎用——没有可靠验证器，循环就是在"自信地制造bug"。我的实施顺序：先补测试门禁，再开自动修，先限定安全模块，再扩大范围。

自动修复循环 = "生成/发现 → 验证 → 错误回喂 → 修复 → 再验证"的迭代机制，是 AI 编程可靠性的核心工程模式。我的设计分三部分：

工作流程：

生成与执行：AI 产出代码/变更 → 在受控环境执行验证（编译 tsc/mvn compile、静态检查 lint、测试 pytest/jest、运行冒烟）；
错误结构化回喂：失败时把结构化错误信息（错误类型、位置、堆栈、相关代码上下文、上次的修复尝试）回喂模型——不是贴原始日志，要裁剪到相关信息（否则错误输出本身又污染上下文）；
修复再验证：模型基于错误分析修复 → 重跑同一验证集 → 直到通过或达到退出条件。

退出策略（关键设计，防死循环烧钱）：

硬上限：最大修复轮次（3~5 轮是性价比拐点——统计数据上第 4 轮之后的成功率骤降）、token/时间预算熔断；
升级而非重试：连续 2 次同类错误未解决 → 换策略（重构该函数而不是打补丁）；仍失败 → 降级人工，附带完整尝试记录（错误轨迹是人工修复的宝贵输入）；
回滚保护：每轮变更做快照，修复失败回到最后可用状态——不留半成品；
错误分类器：可修复类（编译错、测试断言）继续循环；不可修复类（环境问题、需求矛盾）立即退出并上报——不是所有错误都值得重试。

工程要点：验证命令幂等且快（反馈周期决定迭代速度）；错误去重（同一错误重复出现即触发策略切换）；成功的修复对沉淀进示例库（few-shot 资产化）。

架构认知：auto-fix loop 的本质是把"模型的一次性准确率"转化为"系统的最终成功率"——这是 LLM 不可靠性的一剂工程解药。

自动修复循环（Auto-fix Loop）：AI 生成产物 → 自动验证 → 失败则把错误信息回喂 → AI 修复 → 再验证，循环直到通过或退出。用在代码生成（编译/测试/lint 当裁判）、数据处理（schema 校验当裁判）、配置生成等场景。

工作流程设计：

生成 → 验证（编译? 测试通过? Lint? Schema?）
  ├─ 通过 → 交付
  └─ 失败 → 组装修复上下文（原代码+错误输出+失败断言）
          → 修复生成 → 回到验证

关键设计点（踩坑总结）：

退出策略（核心考点）：

收益数据：我们 CI 的单测自动补全用了这套循环，一次通过率 45% → 循环 3 轮后 82%，人工介入聚焦真正的疑难。