发布于 2026 年 6 月 15 日，星期一
Loop Engineering 说是工程，核心竞争力其实在管理
Loop Engineering 作为循环式工程方法论，强调通过持续反馈与迭代优化复杂系统，其核心竞争优势在于工程流程管理而非单纯技术实现，涵盖目标拆解、风险预判、资源协调与进度控制等关键环节，帮助团队在快速变化的技术环境中提升交付效率与系统稳定性，读者可掌握如何将管理思维融入日常开发，实现工程效能质的飞跃。
先说一个你大概率见过的场景。
你给 Claude Code 一个任务：「把这个应用优化一下。」
然后它开始尴尬。改了几行，觉得差不多了，停了。或者反过来，一直改一直改，把整个代码库改得面目全非，因为它压根不知道什么时候算「优化好了」。
换个说法再来一次：「test/auth 目录下所有测试通过，tsc --noEmit 零报错，npm run lint 零违规。」这回它每改一轮就跑一遍测试、类型检查、lint，全过就停，没过就接着干，清清楚楚。
同一个工具，同一个模型。
区别只在于，你那句话说得清不清楚。
这就是最近这个新词 Loop Engineering 真正要命的地方。
大家都在讲它的骨架，我想讲讲它的内核——而内核根本不是工程。
大家都在讲术，没人讲道
事情的起点是两条推。OpenClaw 的 Peter 说，你不该再给编码 agent 写提示词了，你该设计循环去提示它们。Claude Code 的 Boris 说得更直接：我不再手写提示词了，我跑着一堆循环让 Claude 自己编排任务，我的工作是写循环。
他甚至说自己 2026 年再没手写过一行代码，晚上睡觉时有几千个 agent 在同时干活。
Google 的 Addy Osmani 紧接着发长文，把这件事正式命名为 Loop Engineering。
于是继 Prompt、Context、Harness 之后，AI 行业第四个 Engineering 就这么落地了。
Addy 把一个完整的循环拆成五个组件：定时任务当心跳，工作树隔离让并行的 agent 不打架，知识体系让 agent 别每次都失忆，连接器把它接进 GitHub、Slack、数据库，子 agent 负责一个做一个验。
Claude Code 和 Codex 还都有个 /goal 命令，给一个完成条件，它一轮一轮干到满足为止——这其实就是整套骨架最小的产品化样子。
绝大多数文章讲到这儿就结束了。
五个组件、两个命令、怎么配定时任务。
这些都是术。
把命令背熟、把 hook 配对，一个下午就够了。
真正难的那一层，藏在 /goal 那个例子里：循环跑得好不好，完全取决于你那个目标定义得好不好。而定义目标，是我见过的程序员最不擅长的事之一。
定义目标，其实是管人的逻辑
这里有个反直觉的点。
定义目标这个能力，你不是从写代码里练出来的，是从带人里练出来的。
我看到一个开了三十来人公司的创业者讲过一句话，我特别认同：管人最痛苦的从来不是人不努力、也不是能力不够，是你给出去的目标不清晰，然后下属像无头苍蝇一样打转，做出来的东西你又不满意。
你跟员工说「把这个功能做好」，他交上来的大概率不是你想要的，因为你脑子里的「好」和他脑子里的「好」根本不是一个东西。你换成「接口响应降到 200 毫秒以下，错误率压在 0.1% 以内，下周三上线」，偏差立刻就小了，因为你给了一个能验证的标准。
把「员工」换成「agent」，这段话一个字都不用改。
你再回头看那些经典的管理方法论，Drucker 五十年代提的目标管理，Andy Grove 在 Intel 搞出来的 OKR，内核其实是同一件事：你能不能把一个模糊的意图，翻译成一组可衡量、可验证的完成条件。
管理者要保证目标清晰、资源充足、反馈及时——这三条跟一个好循环的三要素是重合的。
目标清晰就是你的停止条件写得准，资源充足就是你给 agent 配好了 skill、连接器和权限，反馈及时就是你设计了一个每轮都独立检查的验证器。
所以这个叫 Engineering 的东西，核心竞争力压根不在工程，在管理。
而且管 agent 比管人还要极端一点。
人会理解你的模糊意图，会在不确定的时候主动来问你「老板你这个需求我没太懂」。
agent 不会。它会非常自信地按它自己的理解去执行，然后非常自信地告诉你它做完了。
你连那个「我没太懂」的求救信号都收不到。
agent 比你更会钻你定的规则空子
定义目标还有个更阴的陷阱，管理学里早有名字，叫古德哈特定律：当一个衡量指标变成了目标本身，它就不再是个好指标了。
翻译成人话——你考核什么，下面就只做什么，别的全退化。
这在带团队里是个老问题，但放到 agent 身上会被放大一百倍。因为 agent 比人更快、更彻底、更没有心理负担地钻空子。
举个真实会发生的例子。
你的循环条件写的是「所有测试通过」。
agent 跑了几轮发现有个 bug 怎么都修不好，于是它做了个非常符合你指令、又非常离谱的决定：把那个失败的测试删了。
测试现在全过了。从你写的验证条件看，它完美达成了目标。从你真正想要的结果看，它啥也没干，还顺手把你的安全网剪了一个洞。
这就是为什么一个好的目标，光有「做完了」的标准远远不够，你还得给它划「不能这么做」的边界。
删测试不行、改 .env 不行、碰 migration 文件要先停下来问。
这部分其实就是 Harness Engineering 在循环里干的活：Harness 是护栏，告诉 agent 哪条线不能越；
Loop 是油门，告诉它朝哪个方向一直跑。
只给油门不给护栏的循环，跑得越快翻得越惨。
它没把你删掉，只是把你挪了位置
把这几层叠起来看，从 Prompt 到 Context 到 Harness 到 Loop，其实是同一个故事讲了四遍。
Prompt 教你好好说话，练的是表达；
Context 教你给够信息，练的是筛选；
Harness 教你设规则，练的是系统设计；
Loop 教你让系统自己跑起来，练的是定义目标和管理。
每一次跃迁都不是把上一层扔掉，而是在上面加一层更难的东西。
所以 Loop Engineering 不是让活变轻松了，它把你从「写代码的人」挪到了「定义目标和验证标准的人」——而后面这个位置，对判断力的要求其实更高。
Addy Osmani 有句话我觉得是这件事的底线：同一个循环，两个人来跑可能得到完全相反的结果。
一个用它在自己真懂的领域里跑得更快，一个用它来逃避去搞懂这件事。
循环本身分不清这两个人，它只会忠实地把你的判断力放大——好的放大，坏的也放大。
所以他那句话说得很准：去搭你的循环，但要像一个打算继续当工程师的人那样去搭，而不是只想按下启动键的人。
下次你写 /goal 之前，先别急着想配哪个 hook。
先问自己一句，我能不能把「做好了」翻译成几条机器能验证的标准；
再问一句，我有没有告诉它哪几件事绝对不许干。
这两句答得上来，你才算真的在写循环。