Loop Engineering 实战：/goal 命令让 AI 自己写完整项目

Loop Engineering 实战：/goal 命令让 AI 自己写完整项目

导读：适合正在用或想尝试 Claude Code 的程序员。读完你会知道 Loop Engineering 到底是什么、/goal 和 /loop 怎么用、怎么把普通提示词改造成自动循环，以及踩坑避雷经验。

---

AI 编程圈又出新概念了------这次叫 Loop Engineering 循环工程。

起因是 Claude Code 之父 Boris Cherny 在最新访谈里说了一段话：

我不再提示 Claude 了。我有一堆循环在运行，它们才是在提示 Claude 并判断接下来该做什么。我的工作变成了写循环。

Boris Cherny 预测，编程史的下一次跃迁，Loop 时代来了！

紧接着 OpenAI 的 Peter Steinberger（OpenClaw 之父） 也公开表示：你不该再给编程 Agent 写提示词了，应该设计一套循环机制，让这些循环去提示你的 Agent。

两家顶级 AI 公司的核心人物，同时在说一件事：AI 编程的范式要升级了，从手动写提示词，变成设计循环系统。

说实话，我第一反应也是「又来？Harness Engineering 还没学完呢」。但上周三晚上，我在 Claude Code 里敲了一行 /goal 命令然后去洗澡，回来发现 AI 已经自己建好了项目结构、写完了数据库 Schema、搭了 4 个页面，还自己跑通了构建验证。整个过程我一个字没打。

体验完之后我不得不说：这玩意儿是真的有用。

这篇文章我就把 Loop Engineering 从头给你讲明白------它是什么、跟之前那堆 Engineering 有什么关系、Claude Code 里怎么用、怎么把你现在的提示词升级成 Loop。跟着敲一遍就能上手。

---

一、Loop Engineering 到底是什么

Loop Engineering（循环工程）：一种 AI 编程范式，你设计一套自动运转的循环系统，代替你去给 AI 下达指令、检查输出、记录进度、决定下一步做什么，不断循环直到达成目标。你可以理解为「给 AI 装上自动驾驶系统」。

第一次听可能有点抽象，拿开车打比方就清楚了。

Loop Engineering 像一个自动导航系统。以前你得盯着地图，在每个路口告诉 AI「前面左转」「下一个出口下高速」。现在你只需要输入目的地，导航自己规划路线------堵车了自己绕、走错了自动重新算路、到了目的地语音提醒你。你手不用离开方向盘，但脑子已经不用一直想着怎么走了。

你从「一步一步指挥 AI」的操作者，变成了「定方向 + 最后验收」的监督者。

上图就是 Loop 的基本骨架。不是让 AI 随便跑，而是一个严格的「执行 → 验证 → 反馈 → 决策」闭环。

Loop 的 3 个核心要素

一个真正能用的 Loop，需要三样东西：

1）可验证的停止条件

你得告诉 Loop 什么时候算完成，而且这个标准必须能被自动验证。比如「npm run build 通过」「所有测试绿了」「lint 零报错」------这些都是好条件。而「把代码优化一下」就不行，没人知道什么叫优化好了。

2）反馈闭环

每轮循环结束后，Loop 得自己检查这轮结果，判断继续跑还是停下。最常见的形式：写完代码自动跑测试，没过就自己修，修完再跑，通了才停。

3）状态记忆

AI 的对话窗口有长度限制，关了就没。Loop 需要一个外部文件（比如 PROGRESS.md）记录当前进度------哪些做完了、哪些还在做、上一轮出了什么错。中间断了重启，不会从零开始。

两张图一对比就很清楚。传统模式是「人 → AI → 人等 AI → 人再推」，Loop 是「人定目标 → AI 自己跑 → 人验收」。

可能有人会问：Loop 不就是个 while 循环吗？写个脚本让 AI 反复执行不就行了？

不是。没有判断能力的循环，AI 可能把错误当正确答案继续跑，越跑越偏。Loop Engineering 和 cron 定时脚本的本质区别，就在于那个反馈闭环------它能自己判断这轮做得好不好，不好就换策略，不是无脑重试。

---

二、AI 编程是怎么一步步走到 Loop 的

Loop 不是突然冒出来的，它是从前几代方法论一层层长出来的。了解这条进化线，你才知道 Loop 到底解决了什么问题、为什么现在才出现。

1、提示词工程 Prompt Engineering（2022～2024）

核心问题是 AI 经常答非所问。解法是研究怎么通过对话让 AI 听懂你------设定角色、约束输出格式、用思维链让它逐步推理。这个阶段你大部分精力花在打磨那几段提示词上。

2、上下文工程 Context Engineering（2025）

提示词写好了，但 AI 不了解你的项目，给的回答常常脱离实际。上下文工程解决的就是这个------在对的时候把对的信息喂给 AI。比如写 CLAUDE.md 规则文件、用 RAG 检索项目文档、建立跨会话记忆。AI 的输出开始贴合你的实际场景了。

3、驾驭工程 Harness Engineering（2026 年初）

AI 能理解项目了，但产出不稳定------有时候写得好，有时候跑偏。Harness 的思路是给 AI 搭一整套靠谱的工作环境：配好工具链、写好测试、定好架构约束、拆好任务。相当于你给 AI 修了一条跑道，它在这条跑道上不容易翻车。

4、循环工程 Loop Engineering（2026 年中）

前面三步都做好了，AI 已经能在靠谱的环境里干活了。但你还是得一步步推着它走------写完这一步，你看了觉得 OK，再告诉它下一步干什么。Loop 解决的就是这个------把「提示、检查、决定下一步」交给一套自动循环系统，你只设定目标和停止条件，然后等着验收。

这四层不是替代关系，是层层叠加的。提示词技巧、上下文管理、Harness 搭建，在 Loop 里全都要用。Loop 只是在最上面多了一层「自动循环 + 反馈闭环」。

很多人搞不清 Harness 和 Loop 的区别，我拿工厂流水线打个比方。

Harness 相当于你建了一条生产线，每个工位配好了工具和质检标准，然后你站在产线旁边盯着------哪个环节卡住了你过去疏通，哪个零件不合格你挑出来。产线跑起来了，但离不开你的实时指挥。

Loop 是你把整条产线的流程写成程序，设定好质检规则和异常处理逻辑，按下启动键就走了。机器自己投料、加工、质检，不合格的自动回炉重做，产线卡住了自动报警。你从产线管理员变成了工厂设计师。

阶段	核心问题	你做什么	典型手段
Prompt Engineering	AI 答非所问	写更好的提示词	角色设定、思维链
Context Engineering	回答脱离实际	喂项目背景	CLAUDE.md、RAG
Harness Engineering	产出不稳定	搭工作环境	工具链、测试、规范
Loop Engineering	需要人推着走	设计自动循环	/goal、/loop、PROGRESS.md

---

三、Claude Code 里的两种循环

（2026 年 6 月实测，/goal 需要 Claude Code v2.1.139 或更高版本，/loop 适用于 v2.0+）

Claude Code 目前内置了两个 Loop 命令，分别对应不同场景。第一次用容易搞混，这里说清楚。

/goal ------ 跑到完成为止

/goal 的机制：你给出一个目标 + 可验证的完成条件，AI 开始工作。每一轮结束后，有一个独立的判断模型来检查「目标达成了没」。没达成就自动下一轮，达成就停止并报告。

注意，判断目标的和执行任务的是两个模型，避免了自己改自己卷子的偏差。

/goal 从零搭建 AI 开发日志项目，包含前端页面和 SQLite 数据库，直到 npm run build 通过且 dev server 能正常访问所有页面

加熔断限制防止跑飞：

/goal 修复项目里所有 TypeScript 类型错误，直到 tsc --noEmit 零报错。最多跑 20 轮，超了自动停止

/loop ------ 定时反复跑

/loop 按固定时间间隔执行操作：

/loop 5m 检查项目前后端的部署状态，如果有报错就通知我

维度	/goal	/loop
运行方式	跑到目标达成为止	按固定时间间隔重复
适合场景	有明确终点的一次性任务	没有明确终点的持续监控
验证机制	独立判断模型检查目标	每轮执行后等下一轮触发
停止方式	目标达成 / 熔断触发	手动停止
典型用例	从零搭项目、批量重构	等部署、监控报错、定时扫描

---

四、实战：用 /goal 从零搭建「AI 开发日志」项目

概念和命令讲完了，直接上手。

项目是什么

做一个叫「AI 开发日志」的全栈小项目，功能很简单：

• 记录每次 AI 编程会话的内容、Token 消耗、产出代码量
• 仪表盘页面展示本周统计
• 历史记录列表，支持搜索和筛选

技术栈：Next.js 14 + SQLite（better-sqlite3）+ Tailwind CSS。

设定目标

在 Claude Code 工作目录下输入：

/goal 从零搭建"AI 开发日志"全栈项目。

技术栈：Next.js 14 (App Router) + TypeScript + Tailwind CSS + better-sqlite3。

功能要求：
1. 首页：仪表盘，展示本周 AI 会话次数、总 Token 消耗、代码产出量
2. 历史页：所有会话记录列表，支持按日期搜索和按项目筛选
3. 新增页：表单，填写会话内容、Token 数、代码行数、项目名
4. API 路由：/api/sessions 支持 GET 和 POST

停止条件：npm run build 无报错，npm run dev 能正常启动，浏览器访问首页、历史页、新增页均能正常渲染。

每完成一个模块就跑一次构建验证，有报错自己修，修完再继续。同一问题修复超过 5 次就记录到 PROGRESS.md 跳过。

完成后输出 Token 总消耗和项目文件清单。

回车，AI 就自己开始干了。

AI 自己的开发节奏

整个过程我没有干预，AI 按这样的节奏跑：

1. npx create-next-app 初始化项目，安装依赖
2. 创建 SQLite 数据库和 API 路由
3. 写仪表盘页面，跑 npm run build------报错，自己修
4. 写历史列表页，跑构建------通过
5. 写新增表单页，跑构建------又报错，修了 2 轮通过
6. 最终全量验证 npm run build && npm run dev

AI 自己维护了一个 PROGRESS.md，记录每轮做了什么、碰到什么问题、怎么修的。这就是前面说的状态记忆。

验收

大概跑了 11 分钟，AI 建了 12 个文件，碰到 3 次构建报错全自己修了，最后 npm run build 一次通过。http://localhost:3000 三个页面正常渲染，CRUD 功能跑通。

可能有人会问：这不就是让 AI 一把梭吗？跟我直接说"帮我写个项目"有区别吗？

区别大了。直接说「帮我写个项目」，AI 一次性输出所有代码，你复制进去大概率跑不通------AI 不知道你的 Node 版本、依赖冲突、文件路径。而 /goal 是逐轮执行、每轮验证的，写一个模块就跑一次构建，报错了当场修。反馈闭环的价值就在这------不是最后才检查，是每一步都在检查。

---

五、实战：用 /loop 做定时任务

如果 /goal 是让 AI 替你干活，/loop 就是让 AI 替你盯着。

举个我实际在用的场景：有个小项目的服务偶尔会挂，时间不固定。以前每隔一会就手动 curl 一下，烦得很。现在：

/loop 10m 检查 http://localhost:3001/api/health 是否返回 200。连续 2 次返回非 200，给我桌面通知。每次检查结果记录到 health-check.log

AI 每 10 分钟盯一次，挂了就通知，我该干嘛干嘛。

更多实用场景：

• /loop 30m 扫描代码库，检查是否有新的安全漏洞上报
• /loop 1h 检查 GitHub Issues 有没有新带 bug 标签的 issue，有就汇总通知
• /loop 5m 检查 CI/CD 构建状态，构建完成就通知

记住：/loop 会一直跑，任务达成就停掉。

---

六、把普通提示词改造成 Loop 的三步法

你可能会想：我用的是 Cursor 或者 Codex，没有 /goal 命令怎么办？

Loop Engineering 的核心不是某个命令，是一套方法论。在任何工具里，只要在提示词里嵌入循环机制，一样能跑出 Loop 效果。

第一步：模糊需求改成可验证的停止条件

改前：

帮我写一个博客项目。

改后：

从零搭建博客项目，直到 npm run build 通过，且浏览器能正常访问首页、文章详情页、管理后台。

有了明确的可验证条件，AI 才知道什么时候算做完了。

第二步：加状态追踪文件

在项目根目录维护 PROGRESS.md，记录当前阶段、已完成事项、进行中事项、遇到的问题和解决方案。每完成一个模块更新一次。

这样 AI 不会忘了自己做过什么，你也能随时看进度。

第三步：加反馈闭环

每完成一个功能模块，立即运行编译或测试验证。有报错就先修复再推进。同一问题修复超过 5 次仍未解决，记录到 PROGRESS.md 后跳过，继续推进其他任务。

这就是开发-验证闭环加防死循环熔断。

完整模板

以上三步整合起来，直接套用：

## 任务目标
{你的项目描述，尽量具体}

## 停止条件
{1～3 个可自动验证的条件，如：npm run build 通过、所有测试绿、lint 零报错}

## 自主开发循环
1. 状态追踪：项目根目录维护 PROGRESS.md，记录当前阶段、已完成事项、进行中事项。每完成一个模块更新一次
2. 开发-验证闭环：每完成一个模块，立即编译或运行验证。有报错就修复，通过后才推进
3. 防死循环：同一问题修复超过 5 次仍未解决，记录到 PROGRESS.md 后跳过，继续推进
4. 最终验证：全部完成后做一次端到端验证

全程自主开发，不要停下来等我确认，除非遇到无法自行解决的阻塞问题。

在 Cursor 或 Codex 里用这个模板，效果跟 /goal 很接近。

为什么需要防死循环

Loop 跑久了最常见的翻车就是陷入死循环------AI 反复修同一问题修不好，或者修好了又引入新问题。所以我建议三个熔断条件都配上：

• 同一问题重试上限（建议 5 次）

• 单轮 Token 预算（比如 200K tokens）
• 进度停滞检测（连续 3 轮 PROGRESS.md 无变化说明 AI 卡住了）

---

七、踩坑与省钱指南

Loop 用起来爽，坑也不少。下面是我亲自踩过的几个。

Token 不是烧的，是放烟花

第一次用 /goal 没设熔断，目标写了个「重构整个项目」。AI 跑了 50 分钟，花了快 80 万 Token，效果还不如我自己花 2 小时重写。

Loop 是个杠杆------能撬动你的工程能力，也能撬翻你的项目。

启动前先想三件事：目标能不能量化？做完值不值这个 Token 钱？跑崩了有没有 Plan B？一个 /goal 省 2 小时手工操作，花 5 块钱 Token，值。跑了 50 块还搞砸了要返工，纯浪费。

Overbaking：AI 开始自己加戏

这是我碰到的最有意思的坑。有一次让 AI 搭一个 CRUD 后台，目标写太松------「做一个功能完善的管理系统」。跑了 20 分钟，AI 开始给项目加用户权限系统、操作日志、甚至还有个「暗黑模式切换」。

这些功能我一个没要，但 AI 觉得「功能完善」就该有这些。

这个现象社区叫 Overbaking 过度烘焙------Loop 跑太久、目标约束太松，AI 开始给自己加需求。最早在 Ralph Wiggum Loop 的实践中就被发现了，有人用它让 AI 在循环里不断重构代码，跑太久之后 AI 开始乱加功能、乱删测试。

解决：目标写清楚做什么和不做什么，设轮次上限，跑完人工审查再合并。

调试比提示词难十倍

Loop 跑了 47 轮后出问题，很难定位是第几轮埋的坑。建议：从小目标开始，每轮让 AI 写清楚做了什么、结果如何，PROGRESS.md 就是你的调试日志。

学习路径

刚开始用 AI 编程、还在 Vibe Coding 阶段的话，先别急学 Loop。把提示词技巧练好，学会用 CLAUDE.md 给 AI 项目上下文。等你到了「AI 能写出我想要的代码，但每次都得我一步步推」这个阶段，Loop 该上场了。

从 /goal 开始就够，给 AI 一个小目标让它跑一轮，感受下节奏和 Token 消耗。顺手之后再加定时循环、熔断机制这些进阶玩法。

---

最后

Loop Engineering 不是什么魔法，就是把「你推着 AI 走」换成了「你定规则，AI 自己走」。

从提示词工程到上下文工程，再到 Harness 和 Loop，AI 编程的自动化程度越来越高。但工具越强，你作为决策者的角色越重要------Loop 设计得好不好、目标拆得清不清楚、反馈机制靠不靠谱，全看你的工程判断力。

Loop 像一台大功率音响------你给它放什么歌，它就放大什么。放好歌，整个场子都炸了。放噪音，全场捂着耳朵跑。

用它来加速你真正理解的工作，别让它替你思考本该自己搞懂的问题。