你不在回路里：Loop Engineering 正在重新定义工程师这个职业

Prompt Engineering 已死。2026 年硅谷最热的词叫 Loop Engineering——不是你提示 AI，而是设计一个系统，让 AI 自己提示自己。

不，这不是又一个概念泡沫。

六月的第二周，一个想法重新组织了一整代开发者谈论 AI 的方式。它从一条 X 帖子开始，六天之内卷过 650 万次浏览。谷歌的 Addy Osmani 给了它命名。Anthropic 的 Boris Cherny 用一句话概括了它的分量："我不再提示 Claude 了。"

两个月前，Cherny 在 @Scale 大会上被观众追问："Loop 会是下一个 hype cycle 吗，还是玩真的？"

他回答得毫不犹豫："玩真的。两年前我们手写代码。然后我们过渡到让 agent 写代码。现在我们正在过渡到 agent 提示 agent，然后它们写代码。从源代码到 agent 那一步有多大，loop 这一步就有多大。"

这不是小题大做。这是一次悄无声息的职业重塑。

一、从你握着工具，到你不在回路里

1.1 一条清晰到刺眼的坐标轴

2022 到 2026 的进化路径，用一个表格就能讲明白：

每一行都代表一次抽象级的提升。而每一次提升，前一个阶段的核心技能就贬值一次。

2024 年，"写一个好的 prompt" 还是稀缺能力。2025 年变成"让多个 agent 并行跑"。到 2026 年，这些都已经是基础设施级的默认技能——不是优势，是入场券。

1.2 "我不提示 Claude 了"到底意味着什么

Boris Cherny 那句话不是夸张。他在多个场合重复过同一件事：他 2026 年以来没有手写一行代码。他每天从手机上合入几十个 PR。Claude Code 本身的所有代码——100%——是由 Claude 自己写的。

这不是一个技术演示。这是产品经理和工程师这两个角色在加速合并的信号。

Cherny 的日常工作流程：起床，在手机上打开 Claude Code，输入一个简短的 goal——"优化支付模块的错误处理"——然后模型自己理解代码库、拆解任务、写代码、跑测试、提 PR。他做 review。有时候连 review 也是另一个 loop 在做。

强调一下：这不是未来场景。Anthropic 内部超过 80% 的代码合并已经是 AI 生成。谷歌的同期数字约为 75%。

当你读到这些数字的时候想一下：剩下 20% 的人类写的代码是谁在写？是 Boris Cherny 这样创造了 Claude Code 的人。他们现在也不写了。

二、Loop 不是新技术，是旧知识被重新发明了

2.1 Loop 是什么

去掉所有包装，一个 agent loop 只有四个动作的循环：

发现 → 计划 → 执行 → 验证 →（重复直到满足条件）

你过去就是那个 loop。你站在 agent 每步之间，读输出，发现错误，决定下一步做什么，让它重试。Loop engineering 的核心是：把自己从那个内循环里抽出来，退后一层去设计 agent 运行的轨道。

任何一个学过计算机科学的本科生都认识这个模式——递归 + 终止条件。这不是新发明。真正的新事物是 loop 的判断逻辑变成了非确定性的：不是硬编码的 i < 100，而是一个子 agent 自己判断"好了吗"。

2.2 从 Prompt 到 Loop 的四层嵌套

Loop engineering 不是凭空冒出来的。它是四年演进的自然结果：

第一层：Prompt Engineering (2022–2024) —— 优化你写的每个词。给角色、拆步骤、加例子。天花板明确：再完美的 prompt 也补不了模型没收到的事实。

第二层：Context Engineering (2025) —— 注意力从"怎么说"转移到"给什么看"。对话历史、检索文档、工具输出、agent 状态——Karpathy 称之为"填充上下文窗口的精致艺术"。Prompt 成了 context 的一个子集。

第三层：Harness Engineering (2026 初) —— 当 agent 开始做自主的多步生产任务，需要一个新的关注层：harness——工具集、约束条件、反馈回路、权限控制等围绕 agent 的全部环境。

第四层：Loop Engineering (2026 中) —— 新的视角聚焦在 harness 中实际产生自主性的那一部分：迭代循环。Harness 问"agent 需要什么环境"，Loop 问"什么循环能驱使它持续朝着目标前进，以及何时停下来"。

这不是四波互相取代的潮水。它们是一组嵌套的关切层。你现在仍然要写 prompt，仍然要管 context，仍然要建 harness。Loop engineering 只是给所有这些装上了一台发动机。

三、"验证回路"才是真正的稀缺资源

3.1 每个 Loop 都有两半

生成器——产生工作。验证器——判断工作是否合格。

过去两年我们痴迷于生成器。调 prompt、换模型、争论 temperature。但在一个 loop 里，生成器一遍遍地跑，几乎是免费的。决定所有运动是否产生价值的，是验证器。

一个验证器薄弱的 loop 不会失败得轰轰烈烈——它会在你眼皮底下高效地、自信地、成百上千次地生产垃圾。

这就是被几乎所有 loop engineering 教程跳过的一句话：瓶颈不是模型，是验证器。

3.2 "Ralph Loop"与开放分类

到 2026 年 6 月，最流行的 loop 模式是一个名叫 "Ralph Loop" 的简单结构（名字来自《辛普森一家》的 Ralph Wiggum）。它的逻辑：每一次迭代后，汇总已完成的工作，问自己"目标达成了吗"——直到回答 "是"。

它的变种按照"开放度"分为了两类：

闭环：成功标准在 loop 启动前就定死了。比如"让测试套件全绿"。每一步可验证，越跑越收敛。好处是安全、可预测、不烧钱。坏处是它只完成你指定的任务，不输出惊喜。

开环：给目标和宽松条件，让 agent 自由探索。"优化这个 APP。" 输出可能真正惊艳——但也可能悄悄退化成非常昂贵的废话机。

一个工程化的 loop 会混合使用：用硬性检查做地板，留一个开放指令做天花板（"在满足所有通过条件的前提下，给我一个惊喜的版本"）。

3.3 一个真实 loop 系统的解剖

AI Jason——一个把 loop 体系跑在公司内部的实践者——的架构值得细看。

他只需要一个最简单的东西：一个支持 loop。每 30 分钟 cron 唤醒 agent，拉取所有支持工单，回复能回答的，把发现的摩擦点和产品点子记入一个共享文件夹叫 signals。

然后让 loop 叠加：同一个 loop 发现 bug 后，自动 spawn 一个编码 agent 去修复它，监控修复是否有效，如果用户仍然遇到相同问题意味着没有根治，loop 会重试。

他同时跑着 5–6 个 loop：

关键设计：它们共享同一个文件系统。SEO loop 的"这个关键词有转化但没内容"信号，直接喂给内容 loop。支持 loop 的重复 bug 信号，被产品 loop 拾取。共享大脑让效果指数级叠加——Jason 的产出是每天 20–40 篇高质量页面，他不需要盯着看。

四、"验证回路"不是技术问题，是组织问题

4.1 当测试覆盖率比你自己的判断更可信

在一个 loop 跑一整夜的世界里，agent 用来验证自己的信号不是"我感觉这样不错"——而是测试套件、类型检查、lint 规则和运行时错误。这些信号必须足够好，好到可以替代"你坐在旁边看着"。

这意味着一个残酷的推论：代码库的质量决定了 agent 输出的质量。

如果你的测试覆盖率低、架构混乱、文档缺失，agent 会迷失得更快，因为它连"正确"的定义都找不到。反之，一个具有良好测试、清晰的模块边界、精确 lint 规则的项目——AI Jason 称之为 agent-ready 的代码库——可以让 loop 在无人干预下稳定产出。

这不是关于 agent 有多强。这是关于你的组织有没有准备好让 agent 工作。

4.2 工程师的新姿势：从写代码到写验证

这引出了整个话题里最反直觉的结论：Loop engineering 没有让工程师变得不重要。它让"品味"变成了硬技能。

当模型负责"写"这一步，工程师最稀缺的产出变成了：

• 写好的验证条件：定义"正确"是什么。一个通过率 90% 的验证器对应一个 90% 的输出质量。
• 设计可验证的系统：模块边界清晰到可以让一个 agent 安全地修改一个模块而不会炸掉整个系统。
• 判断什么时候介入：同一个系统里，哪些任务可以交给 loop 自动跑，哪些必须有人类看。
• 迭代验证器：loop 跑完了，但结果不够好——问题通常不在 agent，在你的验证器没有定义对。

这和一个传统上被视为"软技能"的东西高度重合：判断力。在 Loop 时代，判断力是唯一无法被 loop 替代的工作。

4.3 代价：效率与 token 消耗的永恒对峙

Loop 的阴影面积是钱。

让 agent 不断迭代烧 token 很快。让五个 loop 并行、彼此喂信号、不断优化代码库——烧得更快。TechCrunch 在报道中点到：如果这个听起来很贵，它确实贵。

AI 模型解决一个问题的能力几乎与投入的计算量成正相关——Noam Brown 称之为"测试时计算的无限供应模型"。但"无限供应"的前提是你付得起。对于 Amazon、Google、Anthropic 来说，token 成本不是问题，因为它们在卖 token。但对于一个 50 人公司，每个 loop 跑一晚上等于几千美元的 API 账单——这不是一个所有人都能玩的游戏。

这意味着一个分化的未来：大公司用 Loop 做全自动的持续优化，中小公司用 Loop 处理精确的、有边界的任务——直到 token 成本降到足够低。

五、你不是一个人在 loop 里

Loop engineering 是一个转折点。不是因为技术本身——loop 在计算机科学里比大多数读者还要老。而是因为它的普及意味着一个关键的界限被跨越了：你不再和 AI 对话，你不是它的接口，你不是它和代码之间的中介。你退到了外面，在 loop 之外设计系统。

对于 2026 年的科技从业者，这个变化意味着四件事：

• 如果你是工程师：停止担心 AI 会不会取代你。开始担心你的品味有没有配得上你设计 loop 的权利。写验证条件比写代码更难，而这是你新的核心价值。
• 如果你是技术管理者：不要问"AI 能替掉多少人"。问"我的代码库配不配得上让 loop 去跑"。测试覆盖率、文档完整性、架构清晰度——这些以前是"技术债务"，现在是"自动化税"。
• 如果你在判断要不要投入：从一个小而精确的闭环开始——"每天凌晨 3 点跑一次测试套件，修复失败的测试，提 PR"——而不是追求什么都管的超级 loop。Loop 是一个工程师化的命题，不是一个大模型化的命题。你的架构设计能力，决定了你的 loop 能跑多远。
• 如果你在担心你的技能：当前最稀缺的技能不是写 prompt，不是调模型，不是训练数据。是做判断：什么时候 loop、什么时候人上、什么程度的"好"才算好。你的验证回路就是你的护城河。

来源：Addy Osmani "Loop Engineering" (2026)；Boris Cherny @Scale/Sequoia AI Ascent/The Pragmatic Engineer 访谈；AI Builder Club "Loop Engineering Guide" (2026)；TechCrunch "The AI world is getting loopy" (2026.6.22)；Tosea.ai "What Is Loop Engineering? A Complete Guide" (2026)