碳基智2026年05月21日预计 5 分钟我真的是麻了，AI 圈拜托能别这么每天造词吗：Prompt Engineering - Context Engineering - Harness Engineering - Loop Engineering两年不到，范式都特么「进化」到第四个了，我看还有哪些旧酒可以装到你们这些新瓶里。

        1  先说说 Loop Engineering 怎么来的，它的横空出世要得益于这三位 AI 仙人：6 月，Boris Cherny（Claude Code 创造者）演讲展示他"6 个月没打开 IDE、一个人靠 AI 循环产出 259 个 PR、497 次提交、4 万行代码"的实战模式。

        Peter Steinberger （OpenClaw 作者）发文推广 AI 循环编程方法。

        Addy Osmani（Google 工程师）2026 年 6 月 7 日发表系统性博客正式命名。

        Addy Osmani 的定义：Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.翻译成人话就是：以前你要人肉去写提示词调教 Agent，现在你搞个 Loop 工程让 AI 自己去驱动、评估、修正、执行。

        他们把 Loop 分成了 6 个阶段：Input Capture：自己找到下一件要做的事（cron、事件监听、上一轮输出触发）Context Assembly：自动从文件、向量索引、上一轮摘要中组装上下文Model Inference：Prompt 是 Harness 自动生成的，不是人写的Action Execution：写文件、跑测试、调 API、开 PRObservation & Logging：捕获结果并结构化记录Memory Update：将本轮学到的信息写回持久存储639b5c929a225e787a02545e1e37bfa0.png坦率讲，Loop 的每一项技术构件都不新：自动化调度 → cron job（1975 年）工作树隔离 → git worktree（2015 年）子 Agent 分工 → 多 Agent 协作（2022 年 ReAct 论文）反馈闭环 → 控制论（1948 年 Norbert Wiener）Maker-Checker 分离 → 四眼原则（金融行业用了几十年）我是真的不想再说一次，但很遗憾，AI 圈现在新造的这些工程范式，依旧在套《控制论》的公式，就像我之前写的那篇一样。

        2  Prompt Engineering - Context Engineering - Harness Engineering - Loop Engineering，这所谓的四次跃迁背后，其实也没多少新的变化，每次都遵循几乎完全相同的模式：触发条件：上一层范式的局限性被实践暴露。

        Prompt 的局限催生 Context；

        Context 的局限催生 Harness；

        Harness 的局限催生 Loop。跃迁方向：人的工作从「直接操作」升级为「”」设计操作规则」。

        本质上是控制论里的抽象层级跃迁：从直接施加力，到设计施力系统，到设计施力系统的调度规则。

        叠加关系：四者不是替代关系，是层叠嵌套关系。Loop 建立在 Harness 之上，Harness 建立在 Context 之上，Context 建立在 Prompt 之上。

        没有 Harness 的 Loop = 没装刹车的自动驾驶；没有 Loop 的 Harness = 停在车库里的好车。

        变与不变：技术底座始终没变，依然是 Prompt + LLM + 工具调用。

        改变的只是人与系统的交互界面所处的抽象层级。就这些东西，翻来覆去吹了两年，什么眩晕瘫痪啦，什么核弹爆炸啦，什么颠覆世界啦，什么 XX 已死啦，烦得很。

        3  要我说，Loop Engineering 解决的最大问题，就是 AI 仙人们 token 多得花不完的现象。

        当我们每天还在肉疼那 token 消耗量的时候，一群一天干掉几千上万（没那么少？）

        美刀的人，分享着何不食肉糜的所谓实战经验，我问你食不食油饼？

        这套东西背后最大的问题，首先就是成本的失控。Boris 和 Peter 的 4 万行 AI 代码背后，是 Anthropic 和 OpenAI 近乎无限的 Token 额度。

        实测数据：Loop 模式的总 Token 消耗是手动 Prompt 模式的 3-8 倍。

        单段自动化任务的成本是人工完成同类任务的 2-4 倍。

        我一个 20 美刀的 Codex 你让我跑自循环？

        好，假设你真有这么多 token。那我请问了，Loop 一天帮你 ship 20 个 PR，你真正理解其中几个？

        Addy Osmani 自己都说：Loop 越快交付你没写过的代码，仓库里存在的和你实际理解之间的差距就越大。

        代码库里有 30% 的代码你从未仔细看过，这个比例只会随 Loop 运行时间线性增长。

        更典的是，当 Loop 稳定运行几周后，你，还能有啥自己的想法？

        Loop 给你啥你就接受啥，一坨巧克力味的粑粑你吃不吃？

        Osmani 的原话："The danger is stopping having an opinion when loops run autonomously." 两个人搭建完全相同的 Loop，可能得到完全相反的结果：一个用它加速自己深入理解的工作，另一个用它逃避理解工作这件事情。

        程序员花了很多年做可观测性的事情，一 Loop 就全玩完。

        当 Loop 在凌晨 3 点跑了 47 轮输出一坨垃圾代码，你怎么 debug？

        当下没有成熟的 Loop Observability 方案。

        传统 APM 监控的是确定性请求链路，Loop 的链路是动态生成的、非确定性的、跨多个 Agent 的。

        难搞啊！Prompt Engineering 有 benchmark 和 eval 框架，Loop Engineering 连什么算一个好的 Loop 都还在争论。

        没有一个量化的标准去评估，也没有像 Harness 那样的脚手架，你这玩意儿怎么整呢。消停会吧，别吹了。