Loop Engineering 实践教程：从写提示词到设计循环，2026 年 AI 编程的新范式

发布日期：2026-07-02 ｜ 数据来源：cobusgreyling/loop-engineering GitHub 仓库、Addy Osmani《Loop Engineering》博文（2026-06-07）、Andrew Ng《The Batch》第 359 期（2026-06-26），均实时抓取核实

Loop Engineering（循环工程）是 2026 年 AI 编程的新兴实践：开发者不再逐条向编码智能体写提示词，而是设计能自动生成提示词、自动编排任务的循环系统。这个概念因两句话走红——Claude Code 负责人 Boris Cherny 说"我已经不再 prompt Claude 了……我的工作是写循环"；OpenClaw 作者 Peter Steinberger 说"你不该再给编码智能体写提示词了，你该设计给它们写提示词的循环"。Andrew Ng 随后在《The Batch》中将其系统化为三层循环框架（分钟级智能体编码循环、小时级开发者反馈循环、天级外部反馈循环）。本文基于三个一手来源，拆解循环的六大构件、七个可落地模式、L1→L3 分级上线路径与三大反模式。

---

什么是 Loop Engineering：一次范式迁移

过去两年用编码智能体的方式是回合制：你出题、它作答、你验收、再出题——你全程握着工具。Loop Engineering 把你从"出题人"升级为"出题系统的设计者"：定义目的、验证标准和边界，让循环自我供给提示词、按时间表运行、按需生成帮手，直到目标达成。

Addy Osmani 给出的定位是：它比"Agent 框架工程"再高一层——同样的执行框架，但自我供给（self-feeding）、定时运行（on a timer）、自动分裂帮手（spawning helpers）。转折点在于循环原语已内置进产品本身（Codex 的 Automations、Claude Code 的 cron//loop//goal 等），不再需要自己写 bash 脚手架。

GitHub 上 loop-engineering 仓库（约 5k Star，MIT 协议）把这句话做成了口号："Stop prompting. Design the loop."——它同时支持 Grok、Claude Code、Codex、Cursor、Opencode 等主流智能体。

Andrew Ng 的三层循环框架：不止怎么建，还有建什么

Ng 在《The Batch》第 359 期给出了他做 0-to-1 产品的三个关键循环，节奏从分钟到天逐层放大：

循环	周期	内容	人的角色
智能体编码循环	分钟级	给定 spec（可选 evals），智能体写码、自测、迭代到无 bug 达标	定义 spec 与验收
开发者反馈循环	数十分钟~小时级	开发者评审产品并转向：功能、UI、用户流	行使"上下文优势"
外部反馈循环	天级	找朋友试用、alpha 测试、生产 A/B	塑造产品愿景

三个要点值得展开：

1. 内环已闭合：智能体自测能力（如在浏览器中检查自己的成果）让编码循环"去年底起飞"，Ng 的实例是给女儿做打字练习 App——智能体无人值守工作约一小时，每几分钟出一个可测版本
2. 中环不可自动化：Ng 用"上下文优势"（context advantage）替代"品味"一词——只要人类知道 AI 不知道的事（用户、场景），human-in-the-loop 就必须存在。开发者从"给智能体当 QA"中解放出来，转向更高层决策
3. 外环决定方向：外部反馈塑造愿景 → 愿景驱动 spec → spec 驱动编码循环。Ng 提醒工程师正越来越多承担产品职责："既要建造也要收集反馈——两者都重要"

循环的解剖学：六大构件

loop-engineering 仓库与 Osmani 博文共同给出循环的标准构件（五原语 + 记忆）：

构件	作用	产品对应
自动化/调度	按节奏做发现与分诊	Codex Automations、Claude Code cron//loop、GitHub Actions
Worktrees	并行智能体互不踩踏的隔离执行	git worktree、Codex threads 内置
Skills	沉淀项目知识，停止每次会话重新猜约定	SKILL.md 文件，偿还"意图债"
插件/连接器	让循环能行动而非只报告	MCP 接工单、数据库、Slack，开 PR、更新 ticket
子智能体	造与查分离——做事的和验收的不是同一个	不同 agent 甚至不同模型互查，模型给自己打分总是偏高
状态/记忆	跨运行持久状态，模型每轮之间会遗忘	STATE.md、Linear 看板等对话外存储

一个完整循环的运转（仓库 Mermaid 流程图）：调度触发 → 分诊 Skill 读写 STATE → 开隔离 worktree → 实现子智能体动手 → 验证子智能体跑测试与门禁 → MCP 落实到 Git/工单 → 安全动作自动提交 PR，高风险或含糊事项带全量上下文升级给人 → 循环重启。

七个开箱即用的循环模式

仓库给出七个实测模式及其成本画像，按 token 消耗选型：

模式	建议节奏	Token 成本	干什么
Daily Triage 每日分诊	1 天~2 小时	低	扫 issue/CI/提交，写分诊报告
Changelog Drafter	1 天或打 tag 时	低	自动起草变更日志
Post-Merge Cleanup	1 天~6 小时	低	合并后清理死代码、更新文档
Issue Triage	2 小时~1 天	低	新 issue 打标、去重、定级
Dependency Sweeper	6 小时~1 天	中	依赖升级 + 跑测试验证
PR Babysitter	5~15 分钟	高	盯评审意见、红 CI、冲突
CI Sweeper	5~15 分钟	极高	持续修复失败流水线

选型规律很直白：节奏越快、越接近"自动动手改码"，token 越烧。 新手从低成本的日报型模式起步，高频高成本模式等验证信任后再开。

落地路径：L1 → L2 → L3 分级上线

仓库的安全方法论是分级放权，配套 CLI 工具链降低起步门槛：

第一周（L1，只报告）——循环只观察和写报告，不改任何代码：

npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude-code

loop-init 会脚手架出 skills、STATE 文件与预算文件，并打出"Loop Ready"就绪评分。首个循环示例（原文）：

/loop 1d Run loop-triage. Update STATE.md. No auto-fix in week one.

第二阶段（L2，辅助修复）——循环可以起草修复并开 PR，但合并权在人。用 loop-cost 预估 token 开销、loop-audit --suggest 拿改进建议。

第三阶段（L3，无人值守）——仅对低风险、强验证覆盖的模式开放（如 Changelog、Post-Merge Cleanup），必须配 denylist（禁改文件清单）、预算熔断（loop-context 自带 circuit breaker）与人工升级通道。仓库安全文档明确覆盖：失败模式、反模式、多循环协调、auto-merge 风险与 MCP 权限最小化。

三大反模式：循环越顺，债务越隐蔽

三个来源不约而同给出同样的警告：

1. 验证外包：循环说"done"不是证明。Osmani："交付你确认能跑的代码"；仓库 README："无人值守的循环会犯无人值守的错误"——验证永远是人的责任
2. 理解债（comprehension debt）：循环越顺滑，你不读它产出的代码的诱惑越大，债务积累越快。对策是把"读循环的产出"本身排进日程
3. 认知投降（cognitive surrender）：Osmani 的观察最扎心——同一个循环，用它在已理解的工作上提速的工程师被加速，用它逃避理解的工程师被掏空。直接 prompt 依然有它的位置，平衡才是解

Addy Osmani 的收束句值得贴在工位上："Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."（建循环，但要以打算继续当工程师的姿态去建，而不是只当按下开始键的人。）

常见问题

Q：Loop Engineering 和 Prompt Engineering 是什么关系？
迭代关系而非替代关系。Prompt Engineering 优化单次交互质量；Loop Engineering 设计生成这些交互的系统。循环内部每一步仍受益于好的提示词——只是写它的从你变成了循环。

Q：需要什么工具才能开始？
主流编码智能体均可：Claude Code（cron//loop//goal + Skills + worktree 隔离）、Codex（Automations + threads）、Grok、Cursor、Opencode 等。npx @cobusgreyling/loop-init 提供跨工具脚手架。也可以完全不用框架——一个定时任务 + 一个 STATE.md 就是最小循环。

Q：token 成本会失控吗？
会，这是最实际的风险。三个来源都点名：子智能体和长运行会让成本爆炸。对策：从低成本模式起步、用 loop-cost 先估后跑、设预算熔断、把子智能体的"第二意见"花在真正值得的地方。对成本敏感的团队，循环内的实现/验证子智能体可路由到低价模型（如通过七牛云 AI 大模型广场统一接入多款模型按难度分配），主循环决策保留旗舰模型。

Q：哪些工作不该交给循环？
Ng 给出了理论边界：凡是依赖"人类上下文优势"的决策——用户想要什么、UI 该什么样、产品方向——不可自动化。实操边界：高风险变更（数据迁移、安全相关）、验证覆盖薄弱的代码域、你自己还没理解的系统。

Q：怎么衡量循环建得好不好？
仓库给出可量化入口：loop-audit 打 Loop Readiness 分数（支持 --badge 输出徽章）、loop-sync 检测 STATE.md 与 LOOP.md 漂移、loop-cost 对账 token 预算。定性标准更重要：你是否还读得懂它交付的每个 PR。

总结

Loop Engineering 的本质是把工程师的杠杆点从"每一次交互"上移到"生成交互的系统"：Boris Cherny 的"我的工作是写循环"是宣言，Andrew Ng 的三层循环是框架（内环闭合靠智能体自测、中环留人靠上下文优势、外环导航靠真实反馈），loop-engineering 仓库的七模式 + L1→L3 分级是落地手册。行动建议浓缩为三步：本周用一个只报告的 Daily Triage 循环起步；下周让它开 PR 但合并权留在手里；始终读它产出的每一行——建循环的人，别让自己沦为按开始键的人。

据 GitHub 仓库、Addy Osmani 博文与《The Batch》第 359 期（2026 年 7 月 2 日抓取核实）显示，本文观点与数据均来自一手来源。该领域正在快速演化（Ng 称智能体自测仍是"活跃的发明领域"），建议持续跟踪三个来源的更新。

---

延伸资源

• loop-engineering 仓库（模式/CLI/安全文档）：github.com/cobusgreyling/loop-engineering
• Addy Osmani《Loop Engineering》：addyosmani.com/blog/loop-engineering
• Andrew Ng《The Batch》第 359 期：deeplearning.ai/the-batch/issue-359
• Claude Code 调度与循环文档：code.claude.com/docs/en/scheduled-tasks
• 多模型统一接入（循环成本分层）：qiniu.com/ai/models