不是比谁写代码快，Claude Code 真正的革命是循环工程

题图摄于北京月坛

Anthropic 的 Claude Code 团队表示，真正的突破在于验证（verification）、例行程序（routines）、自动模式（auto mode）和上下文极简主义（context minimalism）。

最近看了 Claude Code 团队几场分享，我脑子里一直冒出一个问题：AI 编程工具的下一站，可能不是“更会写代码”，而是“不用我一句一句追着它写代码”。

说真的，我之前一度觉得 AI 编程工具也就这样了。代码补全更准一点、改 bug 更快一点，当然有价值，但好像也没有改变软件工程的基本节奏。直到看懂 Claude Code 里那个 agent loop（智能体循环） 的逻辑，我才意识到，是我自己用浅了。

之前用其他编程工具，我最强烈的体感不是“它们不够聪明”，而是我太累。

我像一个人肉节拍器。描述需求，等它写；发现不对，再补一句说明；测试报错，再把报错贴回去。AI 很聪明，但它是被叫醒的助手。你不推它，它就停在那里。

Claude Code 真正有意思的地方，就在这里：它不只是把单次写代码做得更快，而是把软件工程从提示工程推向了循环工程。以前是我不断问 AI，现在是开始设计一个系统，让系统去驱动AI。

先看三阶段：代码、代理、循环

Claude Code 的创造人Boris Cherny 有一个判断很值得参考。第一阶段，人直接编辑代码。第二阶段，人对代理说话，让代理编辑代码。第三阶段，人不再一句一句提示代理，而是设计一个 loop、goal 或 routine，让系统去提示代理。

如果你平时打开 AI 编程工具，让它改一个函数、补一个测试或者修一个报错，你大概率就在第二阶段：不再手写每一行代码，但仍然在对话框里追着代理跑。

真正的第三阶段，是把“追着它跑”变成“让它自己跑一小圈，再回来交账”。这一步听起来简单，真正落地很难。因为循环经常会断。

什么叫循环？简单说，就是：看状态，做决定，动手改，自己验证，记录经验，然后进入下一轮。它会断在记忆上，断在验证上，断在触发上，也断在信任边界上。Claude Code 的价值，就是尝试把这些断点一个个补起来。

断点一：它会犯错，但不能每次都从零学

用 AI 写代码的人，应该都遇到过这种小崩溃：文件路径写错，测试命令写错，代码风格和项目规范冲突。更烦的是，上轮明明提醒过，下一轮它又忘了。

我以前也常在对话里纠正它：“这里不是 src/index，是 ./src/index。”这种破事我至少重复过很多次，每次都觉得它不长记性，现在想想，其实是我自己的方法不对。

当场纠正当然有用，但它解决的是当前这一次。Boris 的做法更像工程师：当 Claude 反复犯同类错误，就让它把教训写进 CLAUDE.md，或者沉淀成一个 Skill。下次启动时，Claude 会先读到这些项目规则。

普通使用者把 AI 当助手，工程化使用者让错误变成系统记忆。三周后你新开一个会话，或者团队里换了另一个人接手同一个 repo，它仍然知道你的路径规范、启动命令和常见坑。

一个很简单的 CLAUDE.md 可以这样写：

项目规则

1. 源码路径统一使用 ./src/xxx，不要写成 src/xxx。
2. 本地前端启动命令是 npm run dev，不是 npm start。
3. 修改按钮逻辑时，必须检查 onClick 与组件状态是否联动。

循环工程的核心价值，不是追求 AI 零错误，而是让每一次错误都能变成可复用经验。错误可以发生，但不能白发生。

断点二：写完了，不等于真的能用

AI 写代码最危险的地方，不是它不会写，而是它看起来很会写。可真正跑起来，按钮没反应，接口调不通，边界场景直接炸。

我见过很典型的一种情况：AI 很快改好了一个前端按钮，代码看着也规整，但本地页面一打开，点击没有反应。原因很小，状态没有联动，事件绑定也没走到预期分支。如果人不点开页面，这个 bug 就会被包装成“任务已完成”。

后端也会出现同样的问题。比如它给订单状态接口补了一段逻辑，代码审查时看不出明显问题，服务也能启动。可真正拿一个不存在的 orderId 去请求，接口没有返回错误，反而给了一个空结果；前端拿到这个空结果，还把页面当成“查询成功”继续往下走。这个问题不是“代码写完了”能发现的，必须让它真的跑一次和看一次返回。

所以 Claude Code 团队反复强调 verification（验证）。过去我们说验证，往往想到单元测试、lint和类型检查。这些当然重要，但 Boris 提出的标准更直接：代理能不能真正运行它刚刚改过的东西？

如果 Claude 改完按钮，不只是告诉我“代码已经完成”，而是自己启动本地项目，点开页面，点击按钮，发现没反应再回来修，修完再点一遍，那它做的就不是一次文本修改，而是一小段完整的软件工程闭环。

没有验证的自动化，是一条更快生产垃圾的传送带。它会把同一个错误复制到更多文件、更多分支、更多 PR 里。只有带验证的自动化，才可能变成真正的工程杠杆。

断点三：它不能总等我想起来

光有记忆和验证还不够。很多工程任务的问题，不在于没人会做，而在于没人及时想起来做。

PR 卡住了，CI 红了，低级 bug 没人认领，分支太久没 rebase。每一件单独看都不大，但堆在一起，就会拖慢整个团队。

Routine 就是循环工程最贴近实操的落地形态。你可以把它想象成低噪音的后台值班同事。GitHub 上来了一个简单 bug，它先看一眼；某个 issue 放了几小时没人处理，它先尝试修；CI 又失败了，它先判断是不是常见问题；能修就起草 PR，不能修再叫人。

以前是：人想起任务 → 打开 AI → 解释上下文 → 等回答。

Routine 反过来：系统先看见任务 → 系统启动代理 → 系统先处理一轮 → 最后只把需要判断的部分交给人。

这对大团队当然有用，对小团队也有现实意义。小团队未必一开始就做复杂的 Agent SDK，也可以先从低风险 routine 开始：自动检查失败的 CI、整理未处理 issue、给 PR 补测试建议、把重复报错写进项目规则。先让它“看队列”，再逐步让它“动手修”。

断点四：敢放手，但不能闭眼相信

循环一旦能自动触发，最敏感的问题就来了：到底能放手到什么程度？

我不太喜欢把 auto mode 理解成“大胆交给 AI”。这说法太危险。更准确的理解是分层放权：低风险动作让系统自动做，高风险动作必须让人决定。比如整理 issue、跑测试、起草 PR，可以自动化程度高一点；改数据库结构、动生产配置、删除数据和合并关键分支，就必须停下来叫人。

如果人类 99% 的审批都在点同意，审批本身其实已经失效了。真正有价值的做法，是把人的注意力留给边界、风险和最终责任，而不是让人淹没在一堆“是否允许运行命令”的弹窗里。

上下文极简主义也服务于这个目标。别喂模型整本说明书，只给它一张地图和一盏手电筒。不是不给上下文，而是告诉它去哪里找、按什么规则找、找到以后怎样证明自己没走偏。

这也是控制成本和风险的办法。上下文越大，token 成本越高，模型越容易被无关信息带偏。循环跑得越久，越需要预算、日志、回滚和人工检查点。否则 loop 不是生产力工具，而是一个会持续花钱、持续制造噪音的机器。

这件事为什么重要

我把 Claude Code 和循环工程放在一起看，最大的感受是：软件工程正在从个人效率工具，变成组织级生产系统。

提示词提高的是一个人的效率。循环（ loop）改变的是任务如何被发现、错误如何被沉淀和责任如何回到人手里。

这也会改变“谁能做软件”。Anthropic 内部已经不只是工程师在用 Claude Code，产品经理、设计师、数据科学家，甚至财务人员也在用。我的理解不是“人人都要变成程序员”，而是离问题最近的人，终于可以离实现更近一点。

设计师能直接改一个按钮，PM 能做一个原型，数据同事能把分析流程自动化。工程师当然不会消失，但角色会变：少写一些胶水代码，多设计系统、约束、接口和回滚机制。

未来真正稀缺的，可能不是写出漂亮提示词，而是设计出可靠循环：让它知道什么时候开始，什么时候停，怎样证明自己做对了，出错以后又怎样让系统变得更好。

不要神化循环工程

当然，循环工程不是魔法。这也是为什么 Addy Osmani 会特意提醒，loop 会带来 token 成本、质量下降和“自动制造垃圾”的风险。失控的循环，跑得越快越危险。

所以我的建议是，第一版 loop 一定要小、窄、可回滚。让它从一个可以被验证的小任务开始：修一个可复现 bug，补一个失败测试，处理一个低风险 issue。

如果它每一步都有日志，每个结果都有验证证据，每个高风险动作都会叫人，那它才值得被放出去跑。否则，跑得越快，错得越远。

所以我现在判断一个 AI 编程工具好不好，不再只问它能不能一次写对。

我更关心：如果我把它放走 10 分钟，它会弄坏我的项目吗？弄坏了能自己发现吗？发现以后能自己修吗？修不好，会不会回来告诉我？

能回答这几个问题的工具，才值得被放走 10 分钟。到那时，我终于不用再一句一句地追着它写代码了。