企业官网建设流程全解析

写在前面

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

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

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

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

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

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

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

一、先说说 Loop Engineering 吧

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在我个人开发流中的真正起点。

注意：虽然大家都在用，但是准确命名为Loop Engineering由OpenClaw创始人Peter Steinberger在 2026 年 6 月的一条推文中正式提出，随后Google工程师Addy Osmani与Anthropic Claude Code负责人Boris Cherny共同推波助澜，让它成为继Prompt / Context / Harness Engineering之后的第四代 AI 工程范式。

1.2 Loop Engineering 是什么

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

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

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

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

但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毕竟喂了食）。

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

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

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

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

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

2.1 Loop下的 token 循环爆炸

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

让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就越可控，钱就花的越少，做的项目就会越多，钱也会花的越多，即“钱花的越少==钱花的越多”。

为啥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 润色…

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