## 写在前面
***前面可以不看，就是说说话，很久不写文了。***

沉寂了一段时间后，最近我又把精力投入到了 `AI Agent` 的开发中。在查阅资料时，我发现 `Loop Engineering`（循环工程）这个词突然在各大技术社区霸屏。初步了解下来，它给我的第一印象是：将 `AI` 烧钱这件事更深的刻到了每个开发者心里，会导致 `Token` 爆炸起飞；但它在复杂任务上的最终完成度却出奇的高。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/6f7bfcb6599bad4a2a182ecc0c54f3df.png)


刚好这两天手头的项目告一段落，我终于可以带着偏见来研究一下。结果查看了几篇文章之后，我猛然发现：`Loop Engineering` 不就是我一直在用的开发模式吗？ 并且我们开发的 `AI` 项目已经落地了这种模式，只是我之前 日用而不知。

回想刚开始接触这个概念时，我被网上的一些文章带偏了。我以为，`Loop Engineering` 就是 用户丢进一句 `Prompt`，系统就能全自动理解需求并完美达成目标 的神奇的东西？直到最近，在查阅了一些专业文档后并与群里的大佬们讨论后，我才彻理清了它的真实边界与运作机制。

当然，`Loop Engineering` 确实伴随着一个致命的痛点：`Token` 爆炸。但刚好，今年以来我一直在这种模式下摸爬滚打（省钱），在如何控制上下文、实现 `Token` 收敛，刚好积累了一些行之有效的实战经验。

在正式进入技术细节前，我想先澄清一个被严重误导的误区。最近网上充斥着诸如《***SDD（规格驱动开发）已过时...***》、《***开发新范式 Loop Engineering ...***》等博眼球的标题，让我一度以为 `Loop Engineering` 是要 消灭 其他范式。但实际上，工程界从来没有银弹，`Loop Engineering` 与 `SDD` 等范式绝不是非此即彼的替代关系，而是互补共存的。

接下来，我将结合最近的思考与项目实践，聊聊我对 `Loop Engineering` 的真实理解，以及如何在这个 `Token` 爆炸 的时代，把成本死死按住。

# 一、先说说 Loop Engineering 吧
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/632240ed401c617f47bad116d85365a9.png)

## 1.1 我的 AI 编程 “进化史”

在正式聊 `Loop Engineering` 之前，我想先回顾一下自己的 `AI` 编程心路历程。因为正是这些工具的演进，把我一步步推向了 `Loop Engineering`。

**阶段一：把 AI 当“高级搜索引擎”（2022年）**

记忆拉回 `2022` 年，`ChatGPT` 刚上线那会儿。那时的我，终于体验到了不用在浏览器里开十几个窗口查资料的快感。遇到报错，直接把日志丢给 `GPT` 排错；需要写点小脚本，也让它生成后复制粘贴到项目里。那时候，`AI` 在我眼里只是一个极其聪明的助手，脏活累活都给他做就对了。

**阶段二：深度依赖与“技术戒断反应”（Cursor 爆发期）**

后来，`Cursor` 横空出世。说实话，早期的 `Cursor` 生成的代码质量有时让人一言难尽，但它带来的效率提升是颠覆性的，帮我省去了无数繁琐的机械劳动。

也就是从那时起，我产生了一种深深的 技术依赖 ——甚至偶尔会恐慌：如果有一天断网了、用不了 `AI` 了，那个扫地、打扫厕所的人又是我自己了，自己手写代码太累了，我已经彻底躺平在 `AI` 的 石榴裙 下了。

**阶段三：Vibe Coding（氛围编程）的狂欢**

因为我个人就像失败的 `winer` 一样，终端在上学时期（交换机路由器配置）有着非常恐惧的不好印象，所以我热衷于尝试各种 `IDE`，只要不是终端我都心理门槛下降一百倍。

我忘记什么原因了，之后 `Cursor` 用不了后，我就开始用 `vscode` 中 `codebuddy` 插件，免费又好用，在之后得知腾讯 `codebuddy` 中的 `default` 就是克劳德后一直用了很长一段时间，并且开销也不大。

在这个阶段，我和我那些用着 `API` 中转站的同事们一样，都进入了一种被称为 “`Vibe Coding`（氛围编程/直觉编程）” 的状态：我们不再关心底层的具体实现，遇到问题就敲 `Prompt`，想做什么就写 `Prompt`。 代码是在一种“凭感觉、靠氛围”的对话中拼凑出来的。

**阶段四：觉醒时刻——从 Vibe 到 Loop**

这种“一问一答”的 `Vibe Coding` 状态持续了很久，直到最近 2026年初，随着 `Qwen3.5` 等优秀开源模型的推出（当时铺天盖地的宣传），我的开发模式迎来了真正的拐点。

当时为了找 `Qwen3.5` 的模型试用，想到了同为阿里系的 `Qoder`，却意外发现了它的  `Quest` 模式 （一种多步自主执行/`Agent` 模式），而 `Quest` 是 25年8月上线的（不是软广，是因为刚好当时找 `qwen3.5`）。

当看到 `AI` 不再是被动地等我输入 `Prompt`，而是开始自主拆解任务、循环执行、自我纠错时，我恍然大悟：这一切，就是从这个时候开始改变的。而这，正是 `Loop Engineering` 在我个人开发流中的真正起点。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/4d50d2cc49d7847569a738ac5a10bfa7.png)


*注意：虽然大家都在用，但是准确命名为 `Loop Engineering` 由 `OpenClaw` 创始人 `Peter Steinberger` 在 2026 年 6 月的一条推文中正式提出，随后 `Google` 工程师 `Addy Osmani` 与 `Anthropic Claude Code` 负责人 `Boris Cherny` 共同推波助澜，让它成为继 `Prompt / Context / Harness Engineering` 之后的第四代 AI 工程范式。*
## 1.2  Loop Engineering 是什么
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/523af39128a45c348b077419865fd2c0.png)

在历经了 提示词工程、上下文工程、编排工程等一系列“调教 AI”的漫长摸索后，大佬们终于迈出了统一的步伐，走到了一起，引用在群里讨论时一个大佬说的话“**大部分做工程的，为了解决问题最终都会选择相似的道路。**”。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/e51bcc03a92042e6c6cf931e23c14555.png)

其实 `Loop Engineering` 并没有网上吹的那么晦涩难懂，它的核心逻辑非常直白：“你只管输入目标，系统自己把活干完”。听到这儿，你大概率会想：“这个作者那么水吗？解释不明白别解释，跟以前有什么区别？...”

确实，表面上看都是提需求到拿结果。但你仔细回想一下以前的痛苦经历：`AI` 给你生成了一坨代码，你满怀期待地一品，臭不可闻（报错了确实是shi）。然后呢？你得自己去看日志，把报错信息复制下来，再丢给 `AI` 让它改。改完再跑，再报错，再复制……然后这是个 `loop`。

在这个过程中，你其实一直是个人肉质检员兼擦屁股的。在 `AI` 达成最终目标前，你必须死死盯着，不断介入，还要端着臭不可闻的一坨代码给`AI`，告诉他这是一坨，心累得很。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/e5182313507c4315ecb2f915aac98c39.png)


但 `Loop Engineering` 就不一样了，这个时候就强迫 `AI` 自己的一坨自己看。它接收目标后，会自己去理解、自己制定计划、自己执行。最爽的是，遇到报错了，它自己捕获、自己分析、自己修复，在内部疯狂 `loop`（循环），直到把代码跑通。

最后交到你手里的，就是一个高完成度的结果。哪怕中间某些细粒度的实现细节跟你脑子里想的稍微有点出入，但大方向绝对死死咬住你最初定下的目标。而这，就是 `Loop Engineering`。

## 1.3 误闯 Loop Engineering 
在明白了 `Loop Engineering` 是啥之后，突然意识到，我自己的 Agent 项目不就是使用了 `Loop Engineering` 思想吗？

由于之前一直在用 `Qoder` 之类的工具，在很长的一段时间里，我下意识地觉得“正常的 `Agent` 不就应该是这样跑的吗？”。为了印证这个直觉，我回头翻了翻几个开源框架的源码，比如 `Hive`。

Hive 是一个目标驱动的自动化  `Agent` 项目，同时支持事件触发（`IM` / `Webhook` / 定时任务）作为系统入口。下面我就拿它开刀，扒一扒 `Loop Engineering` 思想到底是怎么被塞进系统里的。

**1.主 Agent Loop（事件/定时驱动）**
`Hive` 的心脏就是一个主 `Agent Loop`。当某个事件被触发时，系统就会围绕这个事件进入循环，一遍遍地迭代，直到这个事件被彻底消化完成。

**2.动态任务编排与 Skill 调用**
主 `Agent` 拿到宏观目标后，不会像个无头苍蝇一样直接开干。它会先把目标拆解成一整条计划链/任务链，然后创建多个带有特定功能的子 `Agent` 去干活。
重点来了：这些子 `Agent` 可不是写死的硬编码模块，而是主 `Agent`  在运行时动态编排出来的。每个子  `Agent`  拥有独立的垂直能力，可以调用各种底层 Skill，专攻固定目标。说白了，主 `Agent` 就是个项目经理，临时招人、临时分组、临时派活。

**3.一个 Agent 一个对话 的硬隔离：**
在干活的时候，每个子  `Agent`  都有自己独立的对话上下文。这样能保证它们各司其职，不会被其他不相关的任务信息干扰。专门写测试的就看测试相关的上下文，专门写业务逻辑的就看业务逻辑，各做各的，防止多对话多目标之间的互相干扰。

**4.沙箱运行与 裁判 机制：**
子  `Agent` 把活干完后，代码绝对不能直接提交或者上线，甚至都不能直接让它说“我写完了”。裁判（审计/验证器）会直接把生成的代码扔进一个隔离的沙箱里，自动执行编译、运行服务、跑测试用例。裁判会盯着沙箱的运行结果、标准输出、标准错误和日志信息，做出判断：“这事儿到底办成没有？有没有产生新的回归 `Bug`？”

**5.不通过？吃药重来（正式进入自主死磕循环）：**
如果裁判判断没通过，或者沙箱直接崩了，拿裁判就可以拿着鞭子，尽情的鞭打地里干活的  `Agent` 。这个 `Agent` 得到反馈后，自动进入下一个循环：自我`PUA`、自我分析原因、自我重写代码、自我再次提交沙箱、再次接受裁判打分。这时候，用户不会参与这个过程，如果`Agent` 在干活干不下去了没有任何结果，裁判就会让 `Agent` 不在继续（但也浪费了`Token` 毕竟喂了食）。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/2f34d0b89a646dbb1748ab69b0bcaf9e.png)


**6.通关，推进下一题：**
只有当裁判点头说 “`bor`，你完成的不错，代码编译通过，测试用例全部 `Clear`，完全符合要求，你可以休息了。”，这一步的任务才算彻底完成。系统才会依次按照编排好的任务链，找到下一个任务，分配下一个 子  `Agent` ，直到所有子任务执行完毕，完成最初的目标。


上面这套流程：`Plan`（规划） → `Do`（执行） → `Check`（沙箱与裁判） → `Act`（自动修复）。这不就形成了一个完整的自动化闭环。

在这种模式下，咱们作为开发者的身份算是彻底变了。咱们不再是那个在一线苦哈哈改拼写错误、盯着调用栈找 `Bug` 的“高级牛马”了，而是牛马都不是了。但也有可能直接退后到了更高的一层——变成了这个闭环系统的“规则制定者”，甚至是“裁判的裁判”。

这，就是 `Loop Engineering` 的庐山真面目，似乎再见 闭环控制系统？

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/6ebe70d5e96956ec40c9bf8035e3ca64.png)


# 二、 Spec-Driven Development（SDD） 下的 token 收敛

## 2.1 Loop下的 token 循环爆炸
看到这里，相信每一个钱包不够鼓、或者天天要向财务报销（或者贷款上班） API 账单的开发者，敏锐的雷达已经开始疯狂报警了。（还有一个大事，国外的模型报不了啊，没有发票！！！）

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/54451bc3e11217a382c0973492ae6d1b.png)


让 `AI` 搁这儿自己无限循环、疯狂死磕，直到通过为止？这听起来确实爽，但代入一下实际的工程场景，你就会发现这是一个多么恐怖的无底洞，这也是我第一次看到  `Loop Engineering` 后置之不理的原因，这也是我后面明白为什么 `DeepSeek` 市场占用率那么高的原因。

早期的 `Vibe Coding`，你顶多是输入了同样的问题，或者输入了错误的问题，顶多浪费不多的 `Token`；而在 `Loop Engineering` 时代，由于它是全自动的，你可能去上个摸鱼，后台的 `Agent` 已经在一个逻辑死胡同里撞墙撞了 10 回，等你回来的时候，你收到的不是一份完美的代码，而是一张足以让你肉疼 `-2000 credits` 的余额衰减，和一堆被彻底玩坏的、上下文。

在使用   `Loop Engineering` 的早期，我天天跟这头 `Token` 吞吞兽斗智斗勇，生为一个穷酸普通程序员，硬生生的用下了一天快 200 刀的花费记录。

后面为了省下那点买排骨的钱，我硬生生逼着自己，在一次次项目中，摸索出了一套把这头吞噬兽死死按在地上摩擦的控本绝招。而最后证实“**大部分做工程的，为了解决问题最终都会选择相似的道路。**”（现在又突然想到，以前在 `vibe coding` 的时候，还会自动的让`AI`总结对话记录并且读取的另类知识库。）

而让 token 收敛的方式，就是以 `SDD` 最详细的边界控制（`GitHub Spec-Kit` 范式）编写的文档，以最近的项目为例，我用 `SDD` 四层规范（`Constitution / Specify / Plan / Tasks`）做需求治理——41 份分层 `spec` 文档，把 `AI` 的搜索空间压到最小，`token` 可预测、产出可验证、需求可追溯。`2100 credits` 完成一个复杂项目。

## 2.2 SDD 下的 token 收敛
虽然 `SDD` 并不是为了省 `token` 诞生的，主目标是 对齐 + 可复现 + 可验证。但在当前烧 `token` 的时期，对于我来说省 `token` 就是提升生产力，因为定义得越死，`AI` 能瞎发挥的地方越少，`token` 就越可控，钱就花的越少，做的项目就会越多，钱也会花的越多，即“钱花的越少==钱花的越多”。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-3919285/5cd659ee93cb27fd12f5397f5050b80f.png)

为啥 `SDD` 能省 `token`？这事儿说起来其实就一句话：用规格把 AI 的搜索空间，从全宇宙压缩到一个小房间。例如你对 `AI` 说："给我做个电商网站。" 

`AI` 的内心 `OS` 是：妈呀，电商网站？淘宝那种？拼多多那种？还是 `Shopify` 那种？要不要带支付？要不要多语言？要不要后台管理？……（这就像AI的思考链）

它的搜索空间是整个知识库。它要从所有可能的电商网站里，挑一个最像你想要的。这中间要试错无数次，每一次试错都在烧 `token`。

而 `SDD` 模式下，你递给 `AI` 一份 100 页的 `spec`，里面写清楚了：

 - 用什么技术栈（`React + Node + PostgreSQL`）
 - 有哪些页面（首页、商品列表、商品详情、购物车、结算）
 - 哪些功能不做（不做优惠券、不做会员体系、不做直播）
 - 验收标准是什么（首屏加载 < 2s，购物车数据持久化）

`AI` 一看 `spec`，心里就有数了：哦，不是淘宝那种，是个小而美的独立站，技术栈定好了，功能边界定好了。

它的搜索空间瞬间从没有方向的乱闯变为一个 10 平米的小房间。它几乎不需要猜，因为答案已经在你写的 `spec` （你按照`SDD`写的文档）里了。猜的次数少了，`token` 自然就少了。

古法手敲，当前这篇文章 70% AI 润色...

**确实很久没写文了，有感后就直接写了，如有错误望请纠正...**




沉寂了一段时间后，最近我又把精力投入到了 AI Agent 的开发中。在查阅资料时，我发现 Loop Engineering（循环工程）这个词突然在各大技术社区霸屏。初步了解下来，它给我的第一印象是：将 AI 烧钱这件事更深的刻到了每个开发者心里，会导致 Token 爆炸起飞；但它在复杂任务上的最终完成度却出奇的高。

Loop Engineering 与 Spec-Driven Development 结合下的 token 收敛

人工智能

编程语言

开发工具

探索AI开发新范式LoopEngineering：从VibeCoding到自主循环的工程革命。揭秘如何通过SDD规范控制Token爆炸，实现41份文档管理2100credits完成复杂项目的实战经验。解析主Agent动态编排、沙箱验证的闭环系统，分享从Prompt依赖到自主修复的AI开发进化路径。

提示词工程

Vibe Coding

PostgreSQL

路由器

OpenClaw

AI Agent

ChatGPT

GitHub

路由

Agent

React

Hive

2026上云采购 | AI焕新·智启新局

lexiang

9.9元起，最快1天搭建自有直播平台


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Loop Engineering 与 Spec-Driven Development 结合下的 token 收敛-腾讯云开发者社区-腾讯云

Loop Engineering 与 Spec-Driven Development 结合下的 token 收敛

Loop Engineering 与 Spec-Driven Development 结合下的 token 收敛

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐