AI Coding 为什么总在重复犯错？用复盘聚合建立会进化的 Loop

「vibe coding 工程化」系列第六篇。前五篇讲了为什么需要 Loop、 怎么用 Claude Code + Codex 搭闭环、 怎么用 Task Packet 防止主线漂移、 怎么把 Prompt 约束升级为机器门禁、 怎么避免 Loop 自己变成瓶颈。 这一篇回答再下一个问题：同一种错误反复出现，Loop 怎么才能真正从中学习，而不是每次都重新诊断？

摘要

AI 可以在一次会话里快速修复问题，却很难自然形成跨任务、跨项目的工程记忆。

结果是：同一种主线偏移、弱测试、审查返工和流程摩擦，会在不同任务里重复出现。团队每次都付出诊断成本，却没有真正让系统变得更好。

本文介绍 Loop Engineering 的复盘聚合层：把零散问题记录成最小事件，周期性识别重复模式，再由人决定将其沉淀为通用规则、项目约束、工具能力，或者直接放弃。

它的目标不是让 AI 自动修改自己的规则，而是建立一种受控的工程学习机制。

AI 修好了问题，为什么下次还会再犯

在一次 AI Coding 会话中，模型可能已经知道：

• Heartbeat 不能只写内部编号；
• 表征测试需要先证明它真的能拦住错误；
• 不应把一个同构功能拆成五个微型 Task Packet；
• 不能在一个实现阶段中途合并结构性变化；
• 审查通过后不应继续打磨无关细节。

但这些经验通常只存在于当前上下文。

会话结束、上下文压缩、模型切换或项目切换后，它们就可能消失。下一次执行时，AI 会再次从局部信息出发，重新走进相似的死胡同。

这说明：

会话上下文不是组织记忆，Prompt 也不是可靠的学习系统。

真正的工程记忆必须存在于模型之外。

最直接的做法，往往也是错误的

发现一次问题后，最容易采取的动作是立即增加规则：

text
发现问题 → 修改 Prompt → 增加 Guard → 增加 Hook → 增加检查项

这样做短期很有安全感，但长期会产生三个后果。

规则只增不减

一次偶发问题也可能永久变成所有项目的流程成本。

项目问题污染通用规则

某个业务特有的限制，被错误地推广到其他项目，形成误报和无意义确认。

当前任务被治理工作打断

AI 本来正在交付业务结果，却转而修改 Loop、Hook 和审查模板，主线再次被流程取代。

所以，Loop 不能在每次受伤后立刻长出一层新盔甲。

从"立即修规则"改成"先记录事实"

更健康的路径是：

text
真实任务出现问题
  → 记录最小事件
  → 继续当前主线
  → 周期性聚合
  → 识别重复模式
  → 人工判断 ┬→ 晋升通用规则
            ├→ 保留项目规则
            ├→ 改进工具
            └→ 不处理或退役

事件记录不需要保存完整对话和日志，只需包含：

• 哪个项目和任务；
• 问题属于安全、质量、主线、效率还是工具；
• 严重程度；
• 一个稳定的问题模式标识；
• 造成了多少返工或等待；
• 可选的证据路径。

例如：

text
category: efficiency
severity: MAJOR
recurrence_key: packet-over-fragmentation
summary: 同构实现被拆成多个微包，每包重复完整审查流程
friction_minutes: 90

关键是记录"问题形态"，而不是复制用户原话、源码、日志或模型长篇输出。

自动信号和人工信号必须分开

有些问题容易由工具自动识别：

• Codex 返回 REQUEST_CHANGES；
• 同一任务经过多轮返工；
• Guard 执行失败；
• 审查进程超时；
• Hook 频繁拒绝同类操作；
• 测试或机器结论无法解析。

另一些问题只能由人判断：

• AI 的进度说明看不懂；
• 执行方向正在偏离主线；
• 流程建设已经超过业务实现；
• AI 一直修复细节，却没有产生可见成果；
• 用户频繁在两个 Agent 之间搬运上下文。

自动化适合采集客观信号，不适合替人判断体验和方向。

不是出现一次，就晋升通用规则

普通问题至少满足以下一种条件，才值得进入通用候选：

• 同一种问题重复出现三次；
• 同一种问题出现在两个不同项目；
• 问题造成了明确、可复现的重大损失。

安全级 BLOCKER 可以一次触发紧急复盘，但仍然要证明它真实存在。

这种阈值非常重要。它把"模型偶尔犯错"和"系统性工程缺陷"区分开来。

一条经验应该落在哪里

进入候选不等于必须增加通用规则。每个候选都应该有四种去向。

晋升为通用规则

适用于跨项目重复发生、边界稳定、收益明确的问题。

例如：表征测试在首次审查前必须完成变异自证。

留在项目级

只与某个业务状态机、部署环境或数据语义有关。

例如：特定渠道错误不能计入健康失败率。

改进工具，但不加规则

如果脚本、Hook 或 Harness 可以直接消除问题，就不需要再要求模型"记住"。

例如：Task Packet 缺少 Guard Profile 时，由启动脚本直接拒绝执行。

不处理或退役

有些门禁误报高、收益低，或者已经被平台原生能力替代。这样的规则应该删除，而不是永远保留。

一个健康的 Loop 必须有删除能力。

四个真实的改进模式

弱测试变成变异自证

多个任务的首轮审查都发现：测试虽然通过，却没有证明它能检测错误。

最终沉淀的不是"再审查一轮"，而是把验证前移：

text
主动改坏实现 → 测试必须失败 → 恢复实现 → 测试重新通过

这样用一次确定性预检，替代多次昂贵返工。

微包过多变成按风险分级

同一组零行为、附加型实现被拆成多个子包，每个包都走完整确认和独立审查。

复盘后改为：同构、低风险子包共享一次确认和一次收尾审查；行为变更、接线和迁移仍保持严格流程。

这不是降低安全性，而是让治理强度与风险匹配。

中途合并变成 Packet 边界

上游结构变化在实现中途合入，会让已经完成的摸底、方案和测试基础同时失效。

最终规则不是禁止合并，而是要求结构性合并只发生在两个 Task Packet 之间。

高频确认不一定是缺陷

Git commit、push 和生产操作频繁触发确认，看起来是流程摩擦，但它们可能正是安全门按设计工作。

复盘的价值也包括证明：某些摩擦应该保留。

规则晋升也需要自己的门禁

一条通用规则正式生效前，至少应完成：

1. 有可复现的问题证据；
2. 能说明它影响了什么；
3. 评估新增流程成本和误报；
4. 为工具改动补充回归测试；
5. 由独立审查者复核；
6. 由人批准是否晋升。

复盘报告本身不能自动修改 Hook、Guard 或通用约束。

否则所谓"自我改进"，很容易变成不可控的自我改写。

如何判断学习闭环是否有效

不能只统计新增了多少规则，还应该观察：

• 同类问题复发率是否下降；
• 首轮审查通过率是否提高；
• 每个任务平均审查轮数是否下降；
• Hook 的无效确认是否减少；
• 主线被流程打断的次数；
• 每条新规则带来的额外等待；
• 有多少低收益规则被降级或删除。

如果规则越来越多，但同类问题仍在重复，说明系统只是在积累文档，并没有真正学习。

当前实现仍然只是第一步

复盘聚合并不意味着 AI 已经拥有自我进化能力。

事件可能存在噪声，Hook 次数也不一定等于真实问题。一次周期报告无法证明某条规则长期有效，流程收益还需要通过后续任务持续观察。

所以更准确的说法是：

Loop 获得了受控学习的基础设施，而不是获得了自动学习的权力。

结语

一个不会复盘的 Loop，只能保证当前任务更谨慎。

一个每次出问题都立即增加规则的 Loop，最终会被自己的流程压垮。

真正能够长期工作的 Loop，需要完成另一种闭环：

text
执行 → 暴露问题 → 记录事实 → 聚合模式
→ 人工判断 → 最小改进 → 验证效果 → 必要时退役

AI Coding 的成熟，不是模型从此不再犯错。

而是同一种错误不再让团队永远支付相同的代价。