AI 说“我做完了”，你敢信吗？

题图摄于国家体育中心

Loop Engineering：让概率模型进入真实世界......

和 AI 打交道时间久了，我有种感觉：AI 真正难的不是“会不会做”，而是“做完以后，我们敢不敢相信它”。

比如，周五傍晚，线上报表出了问题。

你把报错日志和相关代码交给 AI。几秒钟后，它给出一版修复方案：逻辑顺了，字段也判空了，看上去没有问题。

合了。

第二天，一批历史数据又触发了新的边界条件，报表再次异常。

问题不是 AI 不会写代码，而是它不知道：那剩下的一两分，在线上有多贵。

Loop Engineering，业内大多翻译为“循环工程”，但我觉得应该更贴切地理解为「AI闭环工程」。它不是让 AI 多想几轮，也不是给模型套“自动重试”的壳。核心是把会推理但未必正确的模型，放进能验证和能及时刹车的系统里。

大模型不是不会做事，而是还不能只凭一次回答就被放心交付任务。

聪明，不等于可以交付

大模型最容易制造的错觉，是“说得像对”被误当成“已经做对”。

它能写代码、整理纪要、生成客服回复，往往做得漂亮。但真实工作不是一次性问答：代码要跑测试，合同要核条款，客服要看权限，数据操作还要能追溯、回滚。

模型给出的，是当前上下文下“很可能成立”的下一步。

业务真正需要的，却是在真实约束下“可以验收”的结果。

我并不认为提示词工程已经过时。提示词决定 AI 从哪里起步；但当任务跨越多个步骤时，真正决定可靠性的，是后面的闭环。

能落地的 loop，到底长什么样？

以“让 AI 自动修复一个 GitHub Issue”为例，真正难点不在写代码，而在先把下面五件事设计清楚。

任务从哪里来？

是 Issue、监控告警，还是测试失败？不同来源决定输入可信度和任务优先级。

它能看到什么？

除报错信息外，还要给相关源码、项目规范、历史修改和已有测试。上下文不够，AI 很容易修对一点，却破坏另一片。

它能做什么？

它可以读取文件、在独立分支修改代码、新增测试；但不能直接合并主干或部署生产。权限不是技术细节，而是安全边界——少一分权限，就少一分不可逆风险。

谁来验证？

编译能否通过？单元测试是否通过？静态扫描有没有发现风险？这些都应由外部工具给出结果，而不是由 AI 自己宣布“已完成”。

什么时候停止？

例如，全量测试通过后生成待审核 PR；连续 3 次失败就转人工；涉及超过 50 行核心业务代码的改动，触发人工复核；达到预算或时间上限，立即停止。不同业务的阈值可以灵活调整，但提前定义停止规则是硬性要求。

一个默认规则：所有自动化操作默认隔离在沙箱、测试环境，未经人工审批，严禁直接操作生产环境。

任务触发→补足上下文→限权执行→外部验证→通过 / 重试 / 转人工 / 停止

如果少了这五层设计，AI只会漫无目的地反复重试，白白消耗资源，还悄悄埋下线上故障隐患。

这套逻辑不只适用于写代码。比如 AI 处理客服退款工单：由工单触发，读取订单、会员等级和服务话术；只生成回复草稿，或仅在测试环境发送；系统再做敏感词、退款政策和权限匹配；碰到投诉、金额超阈值或用户要求人工时，自动转交人工。

真实产品为什么也在做“闭环”？

这不是纸面上的理想流程。GitHub Copilot cloud agent 就是典型例子：它运行在 GitHub Actions 支撑的临时环境中，可在分支上研究、修改代码，并执行自动化测试和 lint 检查。

它不能自行批准或合并自己创建的拉取请求；默认情况下，相关 GitHub Actions 工作流也要在审阅后由有写权限的用户批准运行。分支限制、人工审查与审计记录，共同构成控制层。

它没有要求开发者“相信 AI 已经做对了”，而是把 AI 放进了分支、测试、审查和权限控制共同构成的流程。

别让 AI 既当答题人，又当阅卷人

在我看来，Loop Engineering 最关键的一条原则，是把验证尽量交给外部事实。

AI 反思自己的答案并非没价值。但让同一模型既写方案又判定正确，像让答题人自己阅卷：它很容易把错误解释得头头是道。

AI 可以起草合同条款，再说“这里没有法律风险”；但它未必知道交易背景、适用法律、对方议价能力和内部底线。模型的“自评”不能代替独立审查。

• 写代码：用编译、测试、静态扫描和真实运行结果验证。
• 做报表：用历史数据回测、口径校验和数据权限检查验证。
• 做客服：用敏感词、服务政策与用户权限规则验证。
• 高风险动作：把最终确认权留给人。

外部验证也不完美：测试有盲区，规则也可能配置错误。但它的优势在于全部逻辑显性可见、全程可审计，出问题后我们能单独调整规则。

验证不是让 AI 再想一遍，而是让真实世界给它一个答案。

循环不是越多越好

很多人抱有一个误区：只要让AI多循环重试几次，总能解决问题。但我一直对此持谨慎态度。一旦初始推理方向出错，无限制重试只会不断叠加开销、拉长处理耗时，甚至把错误越合理化。

Anthropic在Agent工程指南里也给出了务实建议：优先选用最简单可行的流程，只有确认增加自主性能带来明确收益，再提升循环复杂度。高自主Agent会持续累积错误、拉高成本，上线前必须在沙箱充分测试，并配套完整风险护栏。

好的 loop 至少有三道刹车：结果阈值——什么算完成；资源阈值——最多跑几轮、等多久、花多少预算；风险阈值——涉及删数据、付款、发外部消息、部署生产时，必须转人工。

Loop Engineering 的本质，不是让 AI 跑起来，而是让它跑得再快，也知道什么时候该刹车。

上线前，用这五个问题自查

这套自查逻辑不局限代码Agent，不管是自动化业务流程、批量数据处理工具都能直接套用。

□ 能否说清“完成”的客观标准？不能只写“处理好问题”，要写成可检查的结果。

□ 是否有独立于模型的验证？没有独立验证，系统就可能“看似成功”地失败。

□ 高风险动作是否必须人工确认？写入、发送、付款、删除、上线，都应有明确边界。

□ 是否设置了重试、时间和预算上限？没有停止条件，自动化很容易变成失控。

□ 能否追溯并回滚？出问题后，要知道它做过什么，也要能撤回来。例如，保留每次工具调用的输入输出日志，并让代码或配置能回退到上一个稳定版本。

如果这五项只能优先补一项，我会选“验证是否独立”。因为其他环节出问题，往往只是让任务失败；验证出问题，却会让任务看似成功地失败——这更难追回。

人不会退出流程，只是换了一个位置

我更愿意把这种变化理解为：人没有退出流程，只是换了一个位置。过去，我们强调怎样把提示词写得更准确；现在，人的角色在变：不再只是不断补充指令的操作员，而是流程设计者、规则制定者、异常处理者和最终责任人。

所以，别只问：“AI 能不能做好这件事？”

如果 AI 做错了，我的系统能不能在 3 秒内发现，并在 3 分钟内补救？

我越来越觉得，这个问题的答案，取决于你把多少精力花在了模型之外的工程上。

你的团队试过让 AI 自动修复 Bug、生成报表或处理客服工单吗？又在哪一步——合并代码、发送消息、部署生产——仍不敢放开权限？欢迎在评论区聊聊。

模型负责生成可能性；Loop Engineering 负责把可能性变成可交付的结果。

延伸阅读

建议按顺序读：先理解概念缘起，再看“刹车”如何设计，最后看真实产品怎样嵌入分支、测试与审查流程。

• Addy Osmani：《Loop Engineering》：想理解为什么话题从“提示词”走向“闭环”，先读这一篇。
• Anthropic：《Building Effective AI Agents》：想知道“先简单、再增加自主性”以及护栏为何必要，看这一篇。
• GitHub Docs：《About GitHub Copilot cloud agent》：想看真实编码 Agent 如何在临时环境、测试与 PR 流程中工作，看这一篇。
• GitHub Docs：《Risks and mitigations for GitHub Copilot cloud agent》：想看权限、审查、分支保护和审计如何落到产品机制，读这一篇。