Loop Engineering写提示词的时代结束了现在写循环适合人群用 AI 写代码的开发者、想让 AI 自动干活的效率控、关注 AI 前沿的技术人01 一个让全行业炸锅的宣言6月2日Claude Code 的负责人 Boris Cherny 在 WorkOS 主办的 Acquired Unplugged 活动上说了一句话我不再给 Claude 写提示词了。我有一堆循环在跑是它们在给 Claude 下指令、决定下一步做什么。我的工作就是写循环。几天后OpenClaw 的创始人 Peter Steinberger 也发了推别再给编程 Agent 写提示词了。去设计循环让循环替你提示 Agent。Google 的工程主管 Addy Osmani 紧接着发了一篇长文正式给这个概念命了名Loop Engineering循环工程。全网炸了。02 先说清楚你现在的痛点是什么举个常见场景。你让 AI 修一个 Bug。AI 改了代码你一看——漏了测试。你说补上测试它补了你又发现没处理边界情况。你再说它再改。来回五六轮Bug 修好了但你的一天也搭进去了。这就是现在绝大多数人用 AI 的方式你一句它一句。你不说话它就不动。问题不在 AI 不够聪明而在你一直是那个驱动循环的发动机。你想同时处理十个任务不可能。你想下班后让 AI 继续干活它不会自己启动。03 什么是 Loop Engineering一句话你不再亲手给 AI 写提示词而是设计一套系统让系统替你下指令、检查结果、不合格自己重来直到活干完。用一个类比传统方式— 你雇了一个聪明的实习生每天早上你告诉他做什么做完你检查不满意让他重做你全天都在管理他。Loop 方式— 你给这个实习生写了一本操作手册每天早上先看任务列表按优先级处理能做的自己做做不了的放待办箱。你只需要下班前打开箱子看看有什么需要你亲自决策的。区别不在实习生有多聪明而在你有没有设计一套让他自己运转的规则。04 四代工程一次比一次放手Loop Engineering 不是凭空冒出来的它是 AI 工程进化的第四阶段阶段核心问题你在做什么Prompt Engineering怎么问 AI 才能得到好答案写提示词Context Engineering怎么给 AI 足够的背景信息整理上下文Harness Engineering怎么管住 AI 不让它跑偏配工具、设规则Loop Engineering怎么让 AI 自己跑完全程设计循环系统每一层都在包裹上一层人的角色也在一步步后退Prompt 时代你是提问者Context 时代你是备课老师Harness 时代你是项目经理Loop 时代你是系统设计师05 Boris 的蜂巢三层循环怎么跑Boris 不只是说说而已。他过去一个月提了 259 个 PR没有一行代码是自己手写的——全是 Claude Code 在循环里自动完成的。他甚至删掉了自己的 IDE。他管这套系统叫THE HIVE蜂巢分三层层级名称运行环境频率典型命令第一层本地循环你的电脑每1分钟/loop、/goal第二层云端例程Anthropic 云端每1小时Routines第三层集群云端扇出按需/batch第一层本地循环最基础的循环。你给一个目标比如所有测试跑通Claude Code 会自动检查当前状态 → 找到要做的事 → 执行 → 验证 → 不通过就重来 → 通过就推进下一步。每分钟检查一次。第二层云端例程更像定时任务。你配置一个每天早上 9 点检查 GitHub 上所有 PR 的 CI 状态挂了的自动修。即使你关了电脑云端也在跑。第三层集群遇到大任务比如重构 20 个文件一次性扇出多个子 Agent 并行干活各自独立完成后合并。06 一个最简单的 Loop 长什么样你不需要 Boris 那套三层架构一个最基础的 Loop 就能用。拿 Claude Code 举例核心逻辑就三步第一步定义目标 让这个项目的 npm test 全部通过 第二步设定循环规则 - 运行测试 - 如果有失败把报错喂给 Claude - Claude 改完代码再跑测试 - 重复直到全部通过或最多试 50 次 第三步撒手 你去喝咖啡它自己跑这就是一个最简单的 Loop。它和你手动跑测试→看报错→告诉 AI 改的区别在于中间没有你。07 Loop 的六大构件Google 的 Addy Osmani 在文章中把 Loop 拆成了六个组成部分1. 发现Discover— 有什么值得做的事比如GitHub 上有 3 个 Issue 还没修。2. 分配Dispatch— 把任务丢给 AI。不是一句提示词而是把目标、约束、工具、上下文打包好。3. 执行Execute— AI 干活。调用工具、写代码、跑测试。4. 验证Verify— 检查结果。测试通过了吗代码审查过了吗有没有引入新问题5. 记忆Remember— 记录进度。哪些做完了哪些卡住了卡在哪里。6. 决策Decide— 下一步做什么。继续修换个思路还是叫人这六个动作不断循环直到目标达成或撞到预设的上限次数、时间、预算。08 你真的需要 Loop 吗说实话大多数人现在还不需要。Loop Engineering 解决的核心问题是当 AI 的执行能力已经远远超过你手动驱动它的能力时怎么让系统自动运转。适合用 Loop 的场景- 维护一个有大量 Issue 的开源项目- CI/CD 频繁挂需要自动修- 批量重构改 20 个文件的同一处逻辑- 你同时管多个 Agent手动切窗口已经忙不过来不适合的场景- 就改一两行代码 → 手动更快- 任务目标模糊帮我优化一下→ Loop 需要明确的验收标准- 不确定该做什么 → 先想清楚再自动化一个判断标准如果你发现自己在重复做给 AI 下指令 → 检查结果 → 再下指令这个循环超过三次就该考虑写个 Loop 了。09 一个容易踩的坑Loop 最大的风险不是 AI 做不好而是它做错了还停不下来。没有边界控制的 Loop 就像一辆没有刹车的车。2023 年 AutoGPT 就试过让 AI 自己跑循环没有验证、没有边界结果烧了一堆 Token产出的东西基本不能用。写 Loop 的关键不是循环本身而是那些防止它在死循环里烧掉两百美元的边界条件最多试多少次最多花多少钱什么情况下叫人什么情况下直接放弃写 Loop 最核心的功夫不在怎么循环而在怎么刹车。10 这件事的真正意义Loop Engineering 不是一个新工具而是一种新的思维方式。以前你想的是我该怎么问 AI才能得到好答案现在你要想的是我该怎么设计一个系统让 AI 自己找到好答案从写提示词的人变成写提示词的东西的人——这个转变才是 Loop Engineering 真正有意思的地方。不需要一步到位。从一个简单的跑测试→自动修循环开始慢慢你会发现你花在盯着 AI 干活上的时间越来越少花在思考该做什么上的时间越来越多。这不就是 AI 该干的事吗11 关于我国内某互联网上市公司高级研发工程师、研发组长致力于 AI 方面的研究和学习分享。关注我一起学习成长。《MC AI技术开发》