Claude大神Boris Cherny对话Spotify负责人Niklas：Loop时代，不要困在“Prompt”幻觉里，成为缺乏闭环能力的人
很多人还在死磕万能模板、背诵所谓的神级框架时，真实世界的工程范式已经换了底牌。
Claude创始人Boris Cherny和Spotify工程负责人Niklas Gustavsson的对话把窗户纸捅得很干净：
Prompts很简单， Loops很难。
过去我们以为AI智能补全，现在它成了能独立跑完真实任务的执行体。
当Agent拿到指令后自己拆解、执行，甚至长时间脱离人类干预时，最致命的风险就不再是提示词写得够不够精准，而是它跑偏之后，你有没有一套机制能把它硬生生拽回来。
为什么大多数人还在原地打转？
因为他们把精力全押在了“怎么问”上，却彻底忽略了“怎么验”。
这本质上是弱者思维的延续：
渴望用一次完美的输入，换取确定性的输出，试图用话术掩盖系统能力的缺失。
但真实世界的规则从来不是靠许愿运转的。
AI编程的本质，已经从“辅助生成”切换到了“自主闭环”。
任务颗粒度彻底变了：
以前是修一个函数、调一个报错；
现在是把完整目标交出去，让它自己看上下文、改代码、跑测试、交结果。开发者必须把重心后移：
代码写出来只是前半段，流程跑没跑对、结果能不能验，才是决定生死的关键。
人性深处有一种对“确定性捷径”的贪婪。
我们总以为只要找到那个“对”的Prompt，就能一劳永逸地解决复杂问题。
然而，Spotify后端monorepo超过2000万行代码的现实，直接击碎了这种幻想。
一个API可能被包进函数、藏在条件分支里；
一次简单的版本升级，放到几千个组件和几百个团队里，就能把工程节奏拖垮。
传统脚本遇到这种灰区直接卡死，因为状态追踪和上下文判断根本写不完。
LLM的价值恰恰在于处理规则变形时的模糊地带，但前提是，你得有东西兜底。
没有兜底， Agent的每一次尝试都是盲盒；
没有循环，再聪明的模型也只是在真空中挥拳。
要把这套逻辑落地，不能靠玄学，得靠系统。
拆解下来，核心就3条：
01 验证循环是建立主体性的唯一门槛
很多团队在verification loop上投入严重不足。
你可以让Agent跑得更远，但必须先准备好它跑偏以后怎么被拉回来。
Boris反复强调，这是“the single most important thing”。
让Agent修bug，你得告诉它怎么复现、跑哪些测试、失败日志在哪；
让它改接口，你得备好类型检查、集成测试和回滚方案。
没有这些，Agent也能写代码，但它根本不知道自己写对没有。
见过太多团队，PR成功率卡在20%到 30%，就怪模型不行。
后来他们上了自动验收机制做判断，成功率直接拉到80%。
这不是模型变聪明了，是验收标准被具象化了。
后来模型能力上来，Judge被拿掉，但验证的逻辑已经固化在CI里。
这就是病灶所在：
很多人把验证当成事后补救，其实是前置约束。
你给Agent划的边界感越清晰，它走偏的概率就越低；
你留下的回滚路径越明确，它试错的底气就越足。
验证循环不是限制AI，是给系统装方向盘。
真正的主体性，不是自己干完所有活，而是建立能自我运转、自我纠偏的边界。
02 基础设施不跟上，少一道验收就是埋雷
工程生产力永远靠基础设施，不靠多熬几个小时。
Agent能跑起来，靠的不是一句提示词，而是一整套兜底机制。
普通团队不要只盯着“自动验收后来被删掉”这个表象，要看它底下垫着什么：
测试自动化、组件Owner机制、内部工具链。
过去每个组件有明确Owner，团队可以人工看PR；
自动PR多了以后，很多变更会在Owner没看到的情况下合并，测试就必须顶上来。
把测试、日志、权限、回滚、PR规则这些细节固化下来，变成Agent也能执行的Skill，速度和质量就不再是二选一。
Boris说得很清楚：
这是虚假的对立。
如果你想更快，就要把质量实践自动化，写进系统里。
基础设施没跟上，少一道验收只会让问题埋进代码库；
基建越扎实，Agent跑得越稳。
强者思维的核心，永远是运营思维：
把个人经验翻译成系统规则，用机制对抗人性的疏忽与惰性，实现对核心资源的绝对掌控。
03 标准化越彻底，执行路径越少内耗
Niklas给的建议一点也不花哨：
测试、验证、标准化，别丢。
模型会参考仓库里的其他代码来解决当前问题。
同类代码有十种写法，模型会更困惑；
仓库风格一致，Agent更容易照着正确模式改。
项目结构、命名、错误处理、测试命令、PR模板、文档入口，这些过去主要是给人看的工程规范，现在全在喂给LLM。
Niklas表示他的一位朋友带团队做迁移，早期把说明文档发下去，各团队自己改，同一件事重复做，一次拖几个月。
后来他们做统一调度，把同类改动推到整个代码库，统一规范。
Agent介入后，直接吃透标准写法，效率翻倍。
标准化不是限制创造力，是给执行提供可预测的上下文。
你喂给它的上下文越干净，它输出的结果就越稳定；
你留下的歧义越多，它生成的代码就越像拼凑。
减少内耗的世俗智慧，从来不是靠沟通技巧，而是靠规则前置与系统思维的降维打击。
但在这里必须纠偏一个致命误区：
把Prompt和Loop对立起来。
很多人觉得Loop难，就退回Prompt的舒适区，收藏一堆模板，指望靠话术解决工程问题。
Prompt只能把Agent叫起来，Loop才决定它能不能按流程跑完。
前者是点火，后者是传动系统。
没有传动系统，点火再猛也只是原地空转。
另一个误区是追求“无人值守”。
真正的工程实践从不鼓吹把人踢出局。
Agent越能干，开发者越要知道怎么拆任务、怎么设边界、怎么验收、怎么从失败日志里把它拉回来。
编码能力依然要在线，只是重心从“手写每一行”转移到了“设计验证路径”。
真相是：
真正的主体性，不是拒绝工具，而是驾驭工具；
不是追求单次完美，而是构建容错与迭代的闭环。
那怎么把这套逻辑落到你自己的项目里？
按步骤来。
第一步，盘点现有流程。
把测试命令、日志路径、回滚方案、PR模板全部文档化，别散落在口头沟通里
模糊的规范，只会喂养出模糊的结果。
第二步，搭建最小验证环。
先让Agent跑一个低风险任务，强制要求它跑完测试、输出日志、生成PR；
失败后自动重试或标记，人工只介入边界判断。
不要追求一步到位，先让循环转起来。
第三步，固化工程规范。
统一命名、错误处理、目录结构，把README和内部工具链打通，让Agent有迹可循。
把人的经验，翻译成机器能执行的规则。
第四步，迭代验收标准。
初期可以用规则或轻量模型做Judge，跑通后把逻辑下沉到CI/CD，逐步剥离人工干预。
把手术台搭好，剩下的交给流程。
别指望一步到位。
Loop是跑出来的，不是想出来的。
工程里没有银弹，只有不断迭代的闭环。
当实现时间被放到后台处理，空出来的时间自然会花在思考下一步、做更多原型上。
代码不再是难题以后，计划、验证、品味、维护会依次冒出来。
Prompt模板可以收藏，但别把希望全押在上面。
把README、测试命令、任务边界、日志、CI、回滚路径整理清楚，比多背十条提示词管用得多。
真正的强者思维，永远是：无相。
不执着于单次对话的完美，而是构建能自我修正的系统。
当你能把验证循环刻进工程基建，把标准化变成默认配置，你就拿到了真实世界的入场券。
别等风来，去造风。
文中观点仅为作者观点，不代表本平台立场
