Loop Engineering 为什么这么火：三个大佬同一周说了同一句话

6月7日，Peter Steinberger 发了一条推。两天，800万浏览。

他说：「别再手动 prompt 了。去设计 prompt 你的循环。」

这句话不算新。但接下来72小时里，两个完全不同阵营的人，几乎说了同一模一样的话。

三个人，同一个星期

6月8日，Anthropic Claude Code 负责人 Boris Cherny 上了一档播客。他说：「我不再 prompt Claude 了。我跑循环——循环自己 prompt Claude，自己判断该干什么。我的工作是写循环。」24小时，70万浏览。

同一天，Google Cloud AI 总监 Addy Osmani 发了一篇长文，正式命名这件事：Loop Engineering。

OpenAI 的 Steinberger、Anthropic 的 Cherny、Google 的 Osmani。三个不同公司，同一个结论。

命名是怎么走到这一步的

2023年叫 Prompt Engineering。写好一条提示词，搞定。

2025年初，Andrej Karpathi 提出 Context Engineering。重点从单条提示转向管理整个上下文窗口——系统提示、工具定义、历史记录，全部要编排。

2025年底出现 Harness Engineering。Harness 是脚手架，你在 AI 工作流外面套了一层控制框架。

2026年6月，Osmani 提出 Loop Engineering。

区别在哪？

Prompt Engineering 假设你和 AI 是一对一：你提问，它回答。

Loop Engineering 假设你设计的是一个自动循环。AI 执行任务、验证结果、不达标就重试。循环自动跑，你不在旁边盯着。

五个构建模块

Osmani 在博客里拆了五个核心组件。不需要全部同时上，先理解各自解决什么问题：

1. Automations（调度）

用 cron 或 GitHub Actions 定时触发 AI 任务。比如每天凌晨自动跑一次代码审查，扫描新引入的安全漏洞。

判断标准：每周手动做两次以上的任务，就值得自动化。

2. Worktrees（隔离）

让 AI 在独立的 git 分支里干活，不碰主代码库。Claude Code 和 Codex 都已内置这个能力。

不隔离的后果：AI 改错一个文件，你回滚要花半小时。

3. Skills（固化）

把反复用的提示词和流程写成 .md 文件，下次直接调用。相当于给 AI 建了一本操作手册。

常见坑：所有东西塞一个大文件。拆成小模块，按场景调用。

4. Verification（验证）

AI 完成任务后自动跑测试、lint、类型检查。不通过就重试。

没有验证的自动化只是脚本。有验证的才是 Loop。

5. Memory（记忆）

让 AI 跨会话记住项目上下文和决策历史。每次启动不用从头交代背景。

从零开始：五步跑通你的第一个 Loop

开始之前，确认你手上有这些：

• 一个 GitHub 仓库（或其他代码托管平台）
• Claude Code、Codex 或类似的 AI 编程工具
• 基本的终端操作能力
• cron 或 GitHub Actions 的访问权限

准备好了，往下走。

第一步：列清单。

打开你的日历和终端，列出每周重复做的 AI 相关任务。代码审查、文档生成、测试编写、PR 描述、Issue 分类——什么都算。

第二步：挑最简单的一个。

比如「每天检查 GitHub Issues，P0 级别的自动创建 Jira 工单」。别一上来就搞复杂的。

第三步：加验证。

不光跑通，还要检查输出格式对不对、字段全不全、优先级判断准不准。没通过验证，循环就不算完成。

第四步：定时触发。

用 cron 或 GitHub Actions 设定执行频率。观察一周，看有没有误判或漏判。

第五步：加 Memory。

让 AI 记住之前处理过的 issue，避免重复创建。记录决策原因，方便后续复查。

跑通一个之后，再扩展到更复杂的场景。

成本这件事

Osmani 自己也提醒了：token 成本要小心算。

Loop Engineering 一周的 token 消耗，按标准 API 定价，可能超过多数个人预算。不是所有任务都值得做成循环。

判断标准：手动做一次花10分钟、每周重复3次以上——才值得投入 token。

低于这个频率，手动做更划算。