当 Loop 成为瓶颈：如何避免 AI Coding 陷入「正确但没有进展」

Loop 也会走向另一个极端：AI 严格遵守了流程，却迟迟没交付用户真正关心的结果。本文讲一种更隐蔽的失败——代码没错、流程没违规，团队却一直在建前置、修约束、反复审查，主线成果迟迟不可见。以及怎么用最近可见成果、双循环、审查预算把 Loop 拉回交付。

Vibe Coding

「vibe coding 工程化」系列第五篇。前四篇讲了为什么需要 Loop、怎么用 Claude Code + Codex 搭闭环、怎么用 Task Packet 防止主线漂移、怎么把 Prompt 约束升级为机器门禁。这一篇回答一个反方向的问题：当规则、审查、证据越堆越多，Loop 本身会不会变成瓶颈？

摘要

Loop Engineering 的目标，是让正确的事情持续发生。

但当规则、审查和证据不断增加，Loop 也可能走向另一个极端：AI 严格遵守了流程，却迟迟没有交付用户真正关心的结果。

本文讨论一种更隐蔽的 AI Coding 失败：代码没有明显错误，流程也没有违规，但团队一直在建设前置条件、修订约束和反复审查，主线成果却迟迟不可见。

一种「看起来很专业」的偏航

设想一个模型训练项目。

我们的最终目标，是在 GPU 上完成一次训练，看到 loss 下降，生成 checkpoint，并获得一组评估结果。

但 AI 接手后，连续完成了这些工作：

定义训练镜像；
设计存储清单；
编写数据访问策略；
增加安全守卫；
为守卫补充测试；
根据审查意见继续扩充边界情况；
多轮调用另一个 AI 复核实现。

所有工作都有理由，也都与最终目标相关。

问题是：几个工作周期过去了，GPU 上仍然没有真正跑起一次训练。

这是一种很典型的 Loop 偏航：

每一步都正确，但所有正确的步骤并没有及时汇聚成一个有价值的结果。

Loop 为什么会反过来阻碍交付

1. 控制目标替代了业务目标

最初的目标是「完成一次训练」。

执行一段时间后，AI 的局部目标逐渐变成：

Task Packet 是否完整；
Guard 是否覆盖所有文件；
审查是否没有遗漏；
每个边界条件是否都有测试；
台账是否更新。

这些事情本应保护交付，却在不知不觉中变成了交付本身。

判断 Loop 是否偏航，可以问一个简单的问题：

删除本轮新增的流程文档后，用户能够看到什么新的业务结果？

如果答案是「几乎没有」，就应该重新检查主线。

2. 横向铺设前置条件，代替纵向打通链路

AI 很容易采用「先把地基全部建设完」的方式推进复杂项目：

镜像 → 存储 → 权限 → 数据 → 标注 → 训练 → 评估

这条路线在架构上没有错，但反馈周期太长。任何一个前置环节膨胀，都会让最终成果无限后移。

更有效的方式是先完成一条最小纵向链路：

少量合成数据 → 最小训练脚本 → GPU Job
→ loss → checkpoint → eval

它不代表项目已经完成，却可以尽早证明关键假设：训练环境、模型、数据格式、反向传播和产物链路确实能够一起工作。

3. 所有任务使用同一种治理强度

数据权限、资金状态机和生产发布值得严格审查。

但注释调整、可逆配置、实验脚本和内部工具如果也采用同样的审查强度，治理成本很快会超过实现成本。

Loop 不应该只有「开启」和「关闭」，而应该根据风险选择强度。

强度	适用任务	推荐流程
轻量	文档、实验脚本、可逆配置	实现、自检、记录结果
标准	模块功能、普通业务逻辑	Task Packet、定向测试、一次集中审查
严格	生产状态机、资金、安全、数据权限	机器门禁、独立审查、回滚证据、用户裁决

判断强度时，重点看三个维度：影响范围、不可逆性和错误代价，而不是文件数量或任务名称。

用「最近可见成果」重新约束主线

复杂任务开始前，不应只定义最终目标，还要定义最近一个用户可感知的成果。

例如模型训练项目的最近成果可以是：

在 GPU 上使用合成数据完成一次可复现的 XLM-R 线性探针训练，生成 loss 曲线、checkpoint、恢复训练结果和 eval 输出。

这个成果必须同时声明边界：

它证明训练管线可以运行；
它不证明模型在真实数据上有效；
它不替代真实数据治理；
它不构成生产模型发布依据。

这样既能产生真实进展，又不会用漂亮的实验结果自欺。

双循环，而不是一个无限膨胀的循环

成熟的 Loop 应当拆成两个节奏不同的循环。

flowchart LR
    A["业务目标"] --> B["最小纵向成果"]
    B --> C["实现与验证"]
    C --> D["可运行结果"]
    D --> E["下一业务里程碑"]

    C --> F["发现流程问题"]
    F --> G["轻量记录"]
    G --> H["周期性聚合"]
    H --> I["更新通用规则"]
    I -.影响后续任务.-> B

第一个是交付循环，负责产生代码、运行结果和业务价值。

第二个是治理循环，负责收集偏航、误审、重复返工和规则漏洞。

除非发现高风险安全问题，治理循环不应在当前任务中不断打断交付循环。普通流程问题先记录，在固定周期统一复盘，而不是每发现一个问题就立即修改整套 Loop。

给审查设置预算

独立审查很有价值，但审查次数不是越多越好。

可以采用以下约束：

一个实现批次默认只进行一次集中审查。
审查只关注会改变行为、扩大风险或破坏不变量的问题。
APPROVE 后不继续修复无阻断性的细节建议。
同类问题连续两轮出现时，检查设计或测试策略，而不是继续逐项打补丁。
连续两轮只有规则、Prompt、台账变化，没有代码、决策或运行证据时，暂停并重新核对主线。
审查成本明显超过实现成本时，重新评估任务强度。

审查的目标不是获得一份没有任何意见的报告，而是把不可接受的风险降低到可以交付的范围。

Heartbeat 应该让人看懂

进度同步不是 AI 的内部执行日志，也不应该只包含 A1、B3、G6a 之类的局部编号。

一次有效的 Heartbeat 只需要回答四件事：

当前目标 正在完成什么用户可感知的结果。

已经完成 产生了哪些代码、运行结果或决策。

下一步 接下来最优先执行什么，以及为什么。

需要用户处理 是否存在必须由用户裁决的风险、权限或方向问题。

编号可以用于文档索引，但不能代替自然语言。用户不应为了理解进度，再回头查阅三份 Task Packet。

衡量 Loop 是否健康

Loop 的质量不能只看拦截了多少问题，还应该同时观察：

首个可见成果耗时；
业务实现时间与治理时间的比例；
每个任务的平均审查轮数；
连续前置任务数量；
用户为了纠正主线而介入的次数；
审查发现的真实缺陷比例；
已批准任务在集成后重新打开的比例。

如果问题拦截率提高，但首个成果耗时持续增长，说明 Loop 可能正在从质量系统变成流程系统。

安全与进度并不冲突

减少仪式不等于降低质量。

真正需要减少的是：

没有对应风险的文档；
没有新信息的重复审查；
为未来假设设计的复杂守卫；
无法产生运行证据的前置工作；
把边界情况完整性误认为 MVP 完整性。

应该继续保留的是：

架构不变量；
高风险操作的机器门禁；
可复现的测试结果；
明确的回滚能力；
独立审查；
诚实记录未覆盖边界。

好的 Loop 不是让 AI 在每一步都更加谨慎，而是让谨慎集中在真正可能造成损失的位置。

结语

AI Coding 最危险的状态，不一定是快速写出错误代码。

另一种更难察觉的失败，是 AI 变得极其认真：不断补充规则、修订文档、扩大测试、反复审查，却始终没有把系统推进到下一个真实状态。

Loop Engineering 的最终判断标准，不是流程执行得多完整，而是：

在风险受到控制的前提下，有价值、可验证的结果是否持续出现。

正确的事情持续发生，其中的「事情」，最终必须包括交付本身。