写Prompts的时代已经过去！Claude创始人对话互联网大厂负责人：loop时代到来了

来源：市场资讯

（来源：51CTO技术栈）

编辑 | 大石

“Prompts很简单. Loops很难”

Claude官方这期访谈中，Boris Cherny多次聊到了verification loop。

Agent拿到任务后，会自己执行，中间甚至“without a human in the loop”。

到了这一步，最麻烦的地方就不再是Prompt写得够不够准确，而是它跑偏以后，有没有东西能把它拉回来。

坐在对面的Spotify负责人Niklas，把这个问题讲的更清楚。

因为他们面对的是超过2000万行的后端monorepo。一个API可能被包进函数、赋给变量、藏在条件分支里；一个迁移脚本最后可能写到几千行，只为了兜住各种边界。

Niklas：“code has an enormous API surface”。

Prompt只能把Agent叫起来，Loop才决定它能不能按流程跑完，失败后重来，最后交出一个能进代码库的结果。

Niklas Gustavsson做客Claude官方访谈。

AI从智能补全，变成能干实事的工具

Niklas：我感觉AI编程变了，是在模型从“smart autocomplete”变成“something that I could actually throw real problems at”之后。

以前他让模型写出七八成代码，最后还得回到IDE里做收尾。到Opus4/5出现之后，他发现自己越来越少回到IDE做收尾工作。

任务也跟着变大了。以前是讨论一段函数、一个报错、一个文件；现在是把一个完整目标交给Agent，让它自己看上下文、改代码、跑测试，再把结果拿回来。

开发者自然会更加关注工作的后半段，代码写出来只是前半段，流程有没有跑对，结果能不能验，这些事情已经被重视了。

Niklas谈AI从智能补全变成能处理真实问题。

20M行代码库，最先压上来的是维护债

Niklas：Spotify后端monorepo已经有“more than 20 million lines of code”。

这种体量下，团队经常被维护任务拖住。Java版本升级、依赖库更新、API迁移、配置改造，单看都不难，放到几千个组件、几百个团队里，就会把工程节奏拖慢。

Spotify早期做迁移，是把说明文档发给各个团队，让大家自己改。结果是同一件事被重复做很多遍，一次迁移拖几个月。后来他们做fleet management，把同类改动尽量推到整个代码库。

普通团队也会碰到类似问题，只是规模小一些。依赖升级、接口替换、lint修复、配置迁移，这些活可以先交给Agent试水。

Niklas谈Spotify超过2000万行后端monorepo。

传统脚本卡住的地方，LLM才有位置

Niklas并没有说传统脚本没用了。规则稳定、边界清楚的迁移，确定性脚本仍然好用。

但大量真实代码很快会让脚本变复杂。

Niklas：“code has an enormous API surface”。

一个API可能被直接调用，也可能被赋给变量、包进函数、藏在条件分支里。简单替换很快变成状态追踪、上下文判断和边界处理。Niklas提到，迁移脚本最后可能写到几千行，只是在框定各种边界。

LLM的价值就在这类灰区。规则明确的地方继续交给脚本，规则开始变形时，让模型读上下文、判断调用关系、参考仓库里已有写法。

Niklas讲维护自动化和fleet management。

Honk能跑起来，靠的是一整套兜底

Niklas所在团队后来把这套东西做成了Honk。

Niklas：HonkV2基于ClaudeAgentSDK，Agent跑在KubernetesPod里，可以访问内部工具，也能跑CI构建。

早期Honk还有LLMJudge，用来判断Agent生成的PR是否符合预期。

这个Judge曾把PR成功率从大约20%到30%拉到80%左右。后来模型和Agent能力上来，他们才把Judge拿掉。

普通团队不要只盯着“Judge后来被删掉”这一点。Honk能这么跑，是因为底下已经有CI、测试、组件Owner和内部工具兜底。基础设施没跟上，少一道验收只会让问题埋进代码库。

Honk基于Agent SDK运行，并能调用内部工具和CI。

Boris追问的验证循环，才是进生产的门槛

Boris：当Agent接到任务后，会自己拆解，继续往下做，并且在很长时间里没有人盯着。这个时候，验证循环就是“the single most important thing”。
Niklas：对的，你说的没错。
Boris：我看到的常见错误，是很多公司在verification loop上投入不够。你可以让Agent跑得更远，但必须先准备好它跑偏以后怎么被拉回来。

为了让自动PR进入代码库，Niklas所在团队先改了测试自动化。过去每个组件都有明确Owner，团队可以人工看每个PR。自动PR越来越多以后，很多变更会在Owner没看到的情况下合并，测试就必须顶上来。

让Agent修bug，至少要告诉它怎么复现、跑哪些测试、失败日志在哪里。让它改接口，也要准备类型检查、集成测试和回滚方案。

没有这些，Agent也能写代码，但它不知道自己写对没有。

Boris Cherny点出verification loop的重要性。

Karpathy那张LOOPS.md，解释了Honk为什么难

X上的用户Mo Elgaraihy转发了一张疑似卡帕西团队使用的《LOOPS.md》长图，那张图里最重要的句话是：Prompts容易，Loops才难。

《LOOPS.md》，核心观点是把Agent写成可运行的Loop，而不是只写Prompt。

图里第一条写的是“去写loop, 不要写prompt”。

Honk这类系统重要的地方，也在这里。Agent光靠一句提示词写不完真实任务，它需要一整套循环：拆任务、写代码、跑验证、读失败、再修一轮、交PR。

Prompt解决一次对话，Loop负责把一段任务往前推。AI编程进入真实项目以后，后者更难，也更值钱。

把《LOOPS.md》拆成开发者能落地的Loop规则。

速度和质量，不该被放到两边

Boris工程里经常把可靠性、质量放在一边，把速度放在另一边，好像二者只能选一个。但在他看来，这是“false dichotomy”。

他的意思很简单：如果你想更快，就要把质量实践自动化，写进Skill、Claude.md或者一组MCP里，变成Agent也能执行的东西。

Boris：engineering productivity is always about investing in infrastructure. It's not about working more hours.”生产力靠基础设施，不靠多熬几个小时。

这句话也把Loop的意义说清了。

Loop落到工程里，就是把测试、日志、权限、回滚、PR规则这些细节固化下来，让Agent按流程跑。

访谈聊到高频部署背后的质量和可靠性投入。

代码越统一，Agent越少走弯路

Niklas给工程负责人的建议一点也不花哨：测试、验证、标准化，别丢。

Claude会参考仓库里的其他代码来解决当前问题。同类代码有十种写法，模型会更困惑；仓库风格一致，Agent更容易照着正确模式改。

项目结构、命名、错误处理、测试命令、PR模板、文档入口，这些过去主要是给人看的工程规范，现在也在喂给LLM。

Niklas谈代码标准化对Agent的帮助。

Boris：我感受到一个明显变化，implementation time被Claude放到后台处理了，他把空出来的时间花在“thinking about what's next”、和客户交流，以及比预期更多的prototyping上。

Niklas：以前担心AI会拿走写代码里最有挑战的部分，后来发现自己喜欢的其实是解决问题。现在我会让多个Agent在后台跑，自己把注意力放到更大的问题上。

开发者要注意，编码能力仍然要在线，Agent越能干，越要知道怎么拆任务、怎么设边界、怎么验收、怎么从失败日志里把它拉回来。

代码不再是难题以后，计划、验证、品味、维护都会依次冒出来。

Prompt模板可以收藏，但别把希望都押在那上面。把README、测试命令、任务边界、日志、CI、回滚路径整理清楚，比多背十条提示词更管用。