Loop Engineering: Claude Code背后的新工作法

Loop Engineering把AI开发工作变成持续反馈的循环流程。

2026年6月初，Anthropic 的 Boris Cherny，Claude Code 的创建者之一，抛出了一句很快被转发的话：他不再亲自给 Claude 写提示，而是让模型先做，再根据结果继续迭代。这个说法之所以火，是因为它把大模型时代的开发方式说透了：重点不在“写出完美提示词”，而在“把反馈回路跑起来”。

这个概念后来被不少人称为 Loop Engineering，中文可以直接理解成循环工程。它不是一个正式标准，更像一种工作方法：先让模型产出，再检查，再修正，再跑下一轮。对写代码、做产品文案、整理研究材料的人来说，这种方法比一次性写长提示更贴近真实工作。

Loop Engineering到底在说什么

如果把传统提示词方法比作“先写好说明书，再交给模型执行”，Loop Engineering 更像“先让模型做一个版本，再根据结果逐步收紧约束”。它接受一个现实：大模型第一次输出通常不够准，但第二轮、第三轮会明显更接近目标，只要你把检查点设计得足够清楚。

这也是为什么它和很多开发者过去熟悉的“prompt engineering”不一样。前者关注的是单次输入的质量，后者关注的是整个交互过程的质量。对复杂任务来说，后者往往更重要，因为真实问题通常不会在第一轮就被完整描述清楚。

以编码为例，模型先生成代码，接着运行测试，再读取报错，再修补，再测试。这个过程看起来普通，但它把“人类写提示”变成了“人类设计循环”。真正难的地方也在这里：你不是在写一句聪明的话，而是在定义什么时候停、什么时候改、改哪些地方。

• 第一轮输出：先拿到可运行的草案
• 第二轮检查：看测试、日志、结构和边界条件
• 第三轮修正：只改失败点，不推倒重来
• 后续收敛：把结果固定成可复用流程

为什么这个说法会突然流行

因为它和 Claude Code 这种工具的使用方式高度一致。Claude Code 本身就不是让你安静地写一条长提示、然后等待完美答案的那类工具。它更像一个可以反复对话、反复校正的编码搭档。你给它目标，它给你草案；你给它反馈，它继续改。

这种变化也解释了为什么 Addy Osmani 会对这个概念感兴趣。Addy Osmani 长期关注前端工程、开发体验和 AI 辅助编程，他讨论这类方法时，重点通常不是“AI 会不会写代码”，而是“人类如何把 AI 放进工作流里”。Loop Engineering 讨论的正是这件事。

“I no longer write prompts for Claude myself.” — Boris Cherny

这句话之所以被反复引用，是因为它把主动权从“提示词作者”转向“流程设计者”。如果模型已经足够擅长生成第一版，那么人的价值就会更多落在判断、验收和纠偏上。换句话说，开发者不再只是在和模型聊天，而是在编排一个持续运行的反馈系统。

这和很多人对 AI 的直觉相反。很多人还在追求一条更长、更细、更像说明书的提示词，但在复杂任务里，循环往往比一次性指令更有效。原因很简单：任务越复杂，越难在一开始把所有约束写全；而循环可以把遗漏的条件一层层补回来。

它和传统提示词方法差在哪

传统 prompt engineering 更像写简历：你希望一次性把背景、目标、格式、限制都交代清楚。Loop Engineering 更像做产品迭代：先发一个最小版本，再根据反馈改。两者都需要清晰表达，但后者更适合不确定性高、结果难一次命中的任务。

如果放到实际工作里，差异会很明显。写一份营销文案时，你可以先让模型出 3 个版本，再根据受众反馈筛选；做代码审查时，你可以让模型先找潜在问题，再让它按严重程度排序；整理研究摘要时，你可以先抽取事实，再要求它补上遗漏来源。每一步都比“请直接给我最终稿”更容易控制。

下面这组对比能说明问题：

• 一次性提示：适合简单任务、格式固定的输出
• 循环式工作流：适合代码、研究、长文写作、复杂决策
• 人工主导：人先写完整要求，模型再执行
• 流程主导：人定义检查点，模型在每轮里自我修正

从成本角度看，循环方法有一个现实好处：它能减少“全盘重来”。如果第一版就把所有要求塞满，模型常常会在细节上失控；如果先跑一轮，再只针对错误点修补，整体效率通常更高。这个差别在长任务里尤其明显，因为长任务最怕信息过载。

当然，循环也不是白送的。它要求你更会判断结果质量，也要求你会设计自动检查机制。没有测试、没有评估标准、没有明确的停止条件，循环就会变成无休止的来回修改，最后只是在消耗时间。

对开发者来说，真正有价值的部分是什么

Loop Engineering 最有价值的地方，不是它给了一个新名词，而是它把大模型使用方式说得更接近工程现实。开发者本来就熟悉循环：编译、测试、修复；构建、发布、回滚；抓日志、定位问题、再验证。把 AI 放进这个结构里，比把它当成“万能问答框”更靠谱。

这也解释了为什么很多团队开始把 AI 接进现有工具链，而不是只停留在聊天窗口。模型可以写代码、改文档、生成测试、总结 issue，但前提是你把每一步的输入和输出定义清楚。Loop Engineering 讲的就是这种“把人类判断嵌进流程”的思路。

如果把它落到日常开发里，可以关注这几件事：

• 把任务拆成可验证的小步，而不是一次性求最终答案
• 给每一步都加上明确的验收标准
• 让模型先产出，再用测试或规则筛选
• 把高频循环写成脚本、模板或代理流程

这类方法对个人开发者也有意义。一个人做项目时，最缺的往往不是灵感，而是稳定的执行节奏。Loop Engineering 提供的正是这种节奏：先生成，再校验，再修正，再固化。它把“和 AI 协作”从一次性对话，变成可重复的工程动作。

如果你想继续看这类 AI 编程方法，可以参考 OraCore.dev 的相关内容，比如 Claude Code 工作流 和 AI agent 开发模式。这些话题和 Loop Engineering 讨论的是同一件事：怎么让模型在真实任务里稳定产出，而不是只在演示里表现好看。

结尾：它更像一种工程习惯

Loop Engineering 不是某个公司推出的新产品，也不是一套必须照抄的官方规范，它更像一种开始成形的工作习惯。它提醒开发者，和大模型协作时，最值钱的能力可能不是写出最漂亮的提示，而是把反馈循环设计得足够短、足够清楚、足够可验证。

接下来值得观察的，不是这个词会不会继续火，而是它会不会真正进入团队流程：代码审查、测试生成、文档维护、研究摘要，这些地方都很适合做循环。如果你已经在用 AI 写代码，不妨问自己一个更实际的问题：你现在是在“提问”，还是已经在“设计循环”？