2026 年 6 月 8 日凌晨 0 点 28 分，OpenClaw 创始人 Peter Steinberger 在 X 上发了两句话。没有任何图，没有任何代码链接，纯粹是 6 个英文单词（外加一个省略号）：「You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.」

这条推 6.5 百万次围观，评论破万，把整个 AI 编码圈吵了一周。

4 天后，Google Chrome 工程负责人 Addy Osmani 发了一篇 5000 字长文，把这条推背后的方法论系统化成一个新学科：Loop Engineering。再 3 天后，Anthropic 的 Claude Code 负责人 Boris Cherny 转发说：「我不再给 Claude 写 prompt 了。我写 loop。它们在替我给 Claude 发 prompt。」

这不是又一波概念炒作。这是一次工程范式的真正转移。写 prompt 的人，会被会设计 loop 的人淘汰。 你今天学的不是「新名词」，是「下一份简历上的新能力」——这是会写进 2027 年 AI 工程师岗位描述里的硬通货。

💡 你不再按按钮，你设计让按钮自己响应的机器。

这篇文章是 AI 学习拼图系列的特别篇（接续 6/17 Context Engineering 8690、6/7 Claude Code 8353、6/11 Codex CLI 8382），把 Loop Engineering 这套 2026 年 6 月最新冒出来的工程范式讲透。

一、起源：6/8 凌晨那 6 个字，怎么把 AI 圈炸了

先还原一下那条「宇宙级推文」的现场。

6 月 8 日 00:28 AM，Peter Steinberger 在 X 发了那两句话。Peter 是谁？他是 PSPDFKit 的创始人，那个被全球无数 PDF App 集成的核心 SDK 卖身后，他又做出了 OpenClaw 编程智能体框架，被 OpenAI 收编。他不是普通程序员，他是看着这一代 AI Agent 一路长大的当事人。

他说的话只有 6 个英文单词命中要害：「prompts are out, loops are in」。

6.5 百万次围观意味着什么？大概等于马斯克那条「X.com is now live」的同期热度。这在开发者垂直领域，是个异常值。

为什么这么炸？因为这两个字把过去两年 AI 工程师的「肌肉记忆」按在地上摩擦了：过去两年我们学的都是「怎么写一个完美的 prompt」。而 Peter 直接告诉你：别写了，写系统。

💡 Loop 不是 prompt 的升级，Loop 是 prompt 的容器。

6 月 9 日，Anthropic 的 Boris Cherny（Claude Code 团队负责人）跟了一句更狠的话：

> 「I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do.」

翻译：我不再给 Claude 发 prompt 了。我有 loop 在跑。是它们在替我给 Claude 发 prompt，并且自己决定下一步该做什么。

6 月 12 日，Google Chrome 工程负责人 Addy Osmani 发了 5000 字长文，正式把这一系列讨论系统化为「Loop Engineering」这个学科，配套一个 GitHub 仓库作为社区标准。Hacker News 头条、GeekNews 编辑精选、YouTube 头部频道 Matthew Berman 24 小时内解读完——一个新词在一周内完成了从「个人吐槽」到「行业共识」的转变。

这是 2026 年 6 月 AI 圈最值得跟的范式转移。

💡 Loop 不是 prompt 的升级，Loop 是 prompt 的容器。

💡 Prompt 是代码的「问句」，Loop 是代码的「主函数」。从问句到主函数，是软件工程的一次质变。

💡 2026 年不是「AI 取代程序员」的一年，而是「会设计 loop 的程序员取代只会写 prompt 的程序员」的一年。

可能你还没意识到这条推的份量。Peter Steinberger 是个连续创业者，PSPDFKit 在 2017 年被卖给 DocumentCloud（Adobe 旗下），累计集成数十亿台设备；他 2024 年做出 OpenClaw 编程智能体框架（GitHub 上 89K Star），2025 年被 OpenAI 收编——也就是说，他既是被 OpenAI 收编的「外人」，又是看着 Claude Code、Codex、Cursor 这一整代 AI 编程工具长大的当事人。 他在用自己的产品经验告诉你一件事：写 prompt 的时代过去了，写 loop 的时代来了。

二、核心定义：你不再是「按按钮的人」，你是「设计循环的人」

用一句话定义 Loop Engineering：

Loop Engineering = 设计那个替你给 AI Agent 发 prompt 的系统。

这里有一个微妙的、也是最关键的语言转换：

维度 Prompt Engineering Loop Engineering
你是谁 按按钮的人 设计循环的人
你的产出 一条精心打磨的 prompt 一个能跑一整晚的 loop 配置
Agent 的角色 你手边的工具 loop 里的一个执行者
你的注意力 单次提示的措辞 系统在什么条件下推进、什么条件下停
评估对象 输出的字面质量 输出是否满足可验证的终止条件

Addy Osmani 的原话特别精炼：

> 「Prompt engineering asks: What should I say to get the best output?」

> 「Loop engineering asks: What system should I build so the agent finds the work, does it, verifies it, and remembers what it did — without me in the loop at all?」

翻译：Prompt 工程问「我该说什么才能拿到最好的输出」。Loop 工程问「我该搭一个什么系统，让 agent 自己找到工作、做完、验证做完、记下做完了什么——而我完全不在循环里」。

💡 Loop 的本质：让系统做重复的判断，让人做不可替代的判断。

这里还有一个容易忽略的层次：Loop Engineering 不是 Context Engineering 的替代品，而是它的上层建筑。

工程范式 关注问题 典型工具/操作
Prompt Engineering 给模型看什么字 调提示词、Few-shot、CoT
Context Engineering 给模型看什么信息 RAG、Memory、Skills、Tools
Loop Engineering 如何让系统自动循环往复地完成目标 /loop、/goal、Stop hook、Sub-agent、worktree

我们之前发过的两篇文章（6/7 Claude Code 8353、6/17 Context Engineering 8690）属于前两个阶段。Loop Engineering 是第三个阶段，也是目前 AI 工程师最稀缺的能力。

三、5 大核心模块：组成一个能跑的 Loop

文内图3

Addy Osmani 在那篇 5000 字长文里，把一个能稳定跑的 Loop 系统拆成了 5 大模块 + 1 个 Memory。每一块都对应着成熟工具的具体实现。

3.1 自动化与调度（Automation & Scheduling）

这是 Loop 跑起来的根基。 把任务从「我手动按一次」变成「按某种规则自动跑」。

三种调度方式：

  • 定时任务（Scheduled）：类似 cron 的机制，固定频率（每天、每小时）跑同一个 prompt。典型场景：每天早上自动拉昨天所有 PR 跑一遍代码审查、每 4 小时检查一次线上服务状态。
  • 事件驱动（Event-Driven）：由代码 commit、PR 打开、agent 生命周期节点等事件触发的 hook。典型场景：用户提了个新 issue，loop 自动启动去分析能不能修、给作者回复。
  • 目标驱动（Goal-Driven）：用 /goal 类命令，loop 跑到某个可验证的终止条件满足为止。典型场景：「/goal 把 src/api/ 里所有 fetch() 调用都换成 apiClient，且 tsc –noEmit 通过」，agent 跑十几轮自动干完。

💡 /goal 是干到条件满足，/loop 是每隔 N 秒干一次，Stop hook 是你自定义判断要不要停。

3.2 工作区隔离（Workspace Isolation）

当多个 Loop 同时跑时，文件会被它们互相覆盖。 这就是工作区隔离要解决的问题。

实现方式：git worktree。每个 Loop 在自己的 worktree 里操作，最后通过 merge 或 push 把改动合回主分支。

Claude Code 的 Agent View 已经把这个机制做成了产品：每个后台会话在编辑文件之前会自动创建一个独立的 git worktree，多个会话并行改同一份代码互不干扰。

3.3 技能（Skills）：把项目知识编码到文件里

别再让 Loop 每次都从零学你的项目约定。 把项目知识（构建命令、代码风格、测试规范、常见 bug 的修复套路）编码成可复用的 SKILL.md 文件，Loop 按需调用。

对比一下：

方式 第一次 第二次 第三次
把指令塞到 prompt 里 2000 token 2000 token 2000 token
调用 skill “build-typescript-project” 100 token 100 token 100 token

每条指令节省 1900 token，跑 100 轮就是 19 万 token。这是 Loop 能不能在经济上跑得动的关键。

3.4 插件与连接器（Plugins & Connectors）

Loop 离开工具就是纸上谈兵。 它必须能跑测试、读文件、调 API、写 Linear 任务、推 GitHub。

这就是 MCP（Model Context Protocol）大显身手的地方。Anthropic 提出的 MCP 协议让 Loop 通过统一接口访问真实世界的工具——读 Slack、写 Notion、推 GitHub PR、跑 CI。

如果你的 Loop 不能跑自己的代码，那它只能猜。

3.5 子代理（Sub-Agents）：把「写」和「验」分开

这是 Loop 可靠的命门。

一个 agent 写了代码，让另一个 agent 评审。这种「写的人不是评的人」的分离，是 agentic 系统里最强的可靠性模式之一。

为什么？因为「同一个模型自评自己的产出」天然带偏见——它倾向于说「是的我做完了」。引入独立的 verifier（评估者）模型后，bias 大幅下降。

Anthropic 的 Boris Cherny 在 Claude Code 里就是这么用的：主 agent 干活，Haiku 这个轻量小模型每轮结束后读对话历史，回答「条件满足了吗」，「不满足的话理由是什么」，「满足」则停，「不满足」则带着 Haiku 给的理由继续下一轮。

3.6 Memory：让 Loop 跑一整晚不丢上下文

模型每次会话都是失忆患者。 Loop 必须把「我是谁、我在干什么、上次做到哪了」写到外部存储里。

Memory 形式 适用场景
Markdown 文件（PROGRESS.md、LEARNINGS.md） 单人小项目
Linear / Jira board 团队协作
SQLite / Postgres 多 Loop 共享
Vector DB（嵌入检索） 大规模历史知识

没有 Memory 的 Loop 是失忆患者，每个会话都在从零开始。

Addy Osmani 给出了一个最朴素的实操建议：「哪怕只是一个 markdown 文件，写在 repo 里，也比没有强 100 倍。」

3.7 Loop 遥测：观察 Loop 本身

Loop 跑起来后，最大的问题是「它到底在干什么」。 如果没有可观察性，你只能靠 Slack 通知「loop 完成了」来被动接收信息。

实战中，每个 Loop 应该输出 4 个核心指标：

指标 计算方式 意义
完成率 成功轮数 / 总轮数 Loop 稳不稳定
Token / 任务 总 token / 完成的任务数 经济性
Verifier 一致性 独立 verifier 同意率 验证是否真的有效
平均收敛轮数 达成 goal 的平均轮数 goal 写得清不清楚

把 4 个指标推到 Datadog / Grafana，你就能像看 SRE 仪表盘一样看自己的 Loop 健康度。

四、6 个真实 Loop 实战场景

光说不练假把式。下面是 6 个已经被验证过的真实 Loop 场景，全部来自一线开发者的实测。

4.1 批量迁移 API 调用

问题：一个老项目要把 200+ 个文件里的 fetch() 调用全换成 apiClient。

Loop 配置（Claude Code /goal）：

/goal 项目中不再有直接的 fetch() 调用（apiClient 内部除外），tsc –noEmit 通过

实际跑：agent 自己找文件、改代码、跑类型检查、发现问题再修，大概跑了 15 轮，全程不需要人介入。如果用人来手动改，单文件平均 5 分钟，200 个文件就是 16 小时。Loop 用了不到 2 小时。

4.2 修测试套件到全绿

问题：接手的 Python 项目有 47 个集成测试，其中 12 个 flaky。手动一个个修烦死。

Loop 配置：

/goal pytest tests/integration/ 全部通过，不跳过任何用例

实际跑：agent 跑测试、看失败 stack trace、定位代码、改、重跑。循环到全绿。整个过程 3 小时，期间人只在最后接了个 Slack 通知。

4.3 每天自动审查新 PR

问题：5 人小团队，每天 10+ PR，code review 成了瓶颈。

Loop 配置（GitHub Actions + claude -p）：

on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– run: |
claude -p "审查这个 PR 的代码质量和潜在 bug，给出 review 建议" \
–output review-comment.md
– uses: actions/upload-artifact@v4
with:
name: review
path: review-comment.md

实际跑：每个 PR 触发后 5 分钟内拿到 review 草稿，人只需对关键问题二次确认。

4.4 CHANGELOG 自动生成

问题：项目活跃，每天 20+ commit，CHANGELOG.md 永远跟不上。

Loop 配置（CI cron）：

0 9 * * * claude -p "扫 git log 找出昨天所有 commit，按类型分组写到 CHANGELOG.md"

实际跑：每天早上 9 点自动生成，人只需在 release 时 review 合并。

4.5 全自动数据 ETL

问题：每周要把 5 个 SaaS 平台的 API 数据同步到仓库。

Loop 配置（dbt + agent verifier）：

/goal 5 个平台的本周数据全部同步到 warehouse/data/，
dbt run 通过，
dbt test 通过，
数据行数与上周对比偏差 <1%

实际跑：每周日凌晨跑一次，30 分钟内完成，比人工同步快 10 倍。

4.6 多人协作的 agent 任务管理

问题：产品经理同时想跑 3 个调研任务：竞品分析、用户访谈整理、PRD 草稿。

Loop 配置（Claude Code Agent View）：

claude –bg "分析 5 个主要竞品的 6 月功能更新"
claude –bg "把上周 12 段用户访谈整理成 3 条核心洞察"
claude –bg "基于 Q2 数据起草 Q3 PRD 框架"
claude agents # 打开管理面板

实际跑：3 个任务并行跑，git worktree 自动隔离文件冲突，管理面板实时显示每个任务状态（Working / 等待 / 完成 / 错误）。人在面板里扫一眼就够，需要介入的用 Peek 弹窗预览，要深入就 Attach 接管。

五、3 大风险：Loop 不是万能药

文内图2

Addy Osmani 在文末很坦诚地列了 3 个必须直面的风险。这不是吓唬人，是保护你不被 Loop 烧掉预算和时间。

5.1 Token 成本爆炸

Loop 一旦跑起来，每小时可以消耗几万到几十万 token。 报价不高的代码任务，跑一晚上可能就要 50 美元。Anthropic 内部员工的实测数据显示，在闭环良好的 Loop 上，Token 经济学是「Token 越用越便宜」；在目标模糊的 Loop 上，Token 经济学是「Token 越用越贵」。

应对策略：

  • 给 Loop 加轮次硬上限（如 20 轮后强制停止）
  • 给 Loop 加预算硬上限（如 5 美元/任务的硬限额）
  • 用轻量 verifier（Haiku、GPT-4o-mini）而不是主力模型做评估
  • 把 skill 抽出来——别再让 prompt 里塞 2000 token 的项目说明

5.2 目标模糊导致无限循环

最经典的翻车：loop 跑去「让代码质量更好」——这根本没有终止条件。 Agent 改完你再改，陷入死循环。这是目标工程问题，不是 agent 问题。

应对策略：

  • 目标必须可量化：「测试通过」、「lint 警告清零」、「文件数从 200 降到 150」比「代码质量提升」强 100 倍
  • 目标必须可验证：「npm test 退出码 0」比「测试通过」更精确
  • 给目标加轮数上限：「/goal 所有 lint 警告清零，20 轮还没搞定就停」

5.3 验证不严导致不可靠产出

如果 verifier 写得像「觉得差不多了就停」，那这个 loop 一定会产出「看起来差不多」的代码。 Anthropic 内部出过这种事故：一个 production loop 跑了 4 小时，最后产出的代码通过了所有 verifier，但人工 review 发现核心逻辑错了。

应对策略：

  • 优先用确定性 verifier（测试、Lint、Typecheck、CI），不要用 LLM「自评」
  • 加 LLM 验证层用于模糊目标（语义检查、风格审查），但必须双盲（用不同的模型、用不同的 prompt）
  • 关键操作加 Human-in-the-Loop（HITL）：删库、推 main、付钱、调权限等必须人工确认

Addy Osmani 给出的精辟总结：

> 「The hard part is not autonomy itself. It is verification, stopping conditions, and Human in the Loop escalation.」

翻译：难的部分不是自主性本身，而是验证、终止条件、人类介入升级机制。

5.4 一个真实翻车：Token 失控的 ETL Loop

某数据团队 5 月份搭了一个 /goal 把 5 个 SaaS 数据源同步到 warehouse 的 Loop，第一周花了 800 美元。原因：终止条件写的是「数据完整性提升」，verifier 也是用 LLM 自我判断「差不多就完了」。结果 loop 跑了一整晚，把数据来回校验、改 schema、再校验，token 消耗 2.3 亿。修复办法：把终止条件改成「行数与上周偏差 <1%」、加 20 轮硬上限、换 Haiku 做 verifier。第二周成本降到 35 美元。

这就是 Loop Engineering 的真功夫：80% 的时间花在「怎么写好终止条件」上，20% 的时间花在「怎么让 agent 干完」。

六、5 步上手：从「按按钮」到「设计循环」

看完上面这些，你可能觉得 Loop Engineering 离自己还有点远。下面是 5 步落地路径，一周内你也能跑起来。

6.1 第 1 步：选 1 个最烦的重复任务

不要贪大。找一个你每周做 1 次以上、每次 30 分钟以上、规则明确的任务。比如：

  • 把上周的 commit 写进 CHANGELOG
  • 每天早上把客服邮件分门别类
  • 每周把 Stripe 账单同步到 Notion 数据库

6.2 第 2 步：写一个「明确终止条件」的 prompt

把这个任务的目标写成 /goal 形式。例如：

/goal 每天 9 点自动把昨天 24h 的 git commit 分类，
按 Added/Changed/Fixed/Removed 写入 CHANGELOG.md 末尾，
然后 commit 这个文件，
整段过程 < 5 分钟完成

注意 3 个要素：可量化的终态 + 明确的验证方式 + 时间约束。

6.3 第 3 步：先用手动 + cron 跑 1 周

不要一上来就全自动。前 1 周，每天 9 点手动触发一次，把输出对一下、看 verifier 是否真能识别「做完」和「没做完」。

如果一周内出现 3 次以上「agent 觉得做完了但实际没做完」，说明你的终止条件写得太模糊。重写 goal，不要升级 agent 能力。

6.4 第 4 步：抽 1 个 SKILL.md

跑稳之后，把项目知识（构建命令、文件结构、命名规范）抽成 SKILL.md。一个 skill 平均能省 1500 token/次，跑 100 轮就省 15 万 token。

6.6 一个最小可跑 Loop 模板（GitHub Actions + Claude）

下面是一个生产可用的最小 loop 模板，复制即可用：

# .github/workflows/daily-changelog.yml
name: Daily CHANGELOG Update
on:
schedule:
– cron: '0 9 * * *' # 每天 9 点
workflow_dispatch: # 支持手动触发

jobs:
update-changelog:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
– uses: actions/checkout@v4
with:
fetch-depth: 50

– name: Update CHANGELOG
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude -p "/goal 扫描过去 24 小时的 git log，\
按 Added/Changed/Fixed/Removed 分类，\
追加到 CHANGELOG.md 末尾，\
最后 git commit 这个文件" \
–max-turns 15 \
–output-format json > result.json

– name: Verify Result
run: |
# 校验 CHANGELOG.md 确实被更新了
if ! git diff –exit-code CHANGELOG.md; then
echo "✅ CHANGELOG.md updated successfully"
git push
else
echo "⚠️ No changes detected"
exit 0
fi

这个 loop 有 4 个关键设计：

  1. 可量化终态（CHANGELOG.md 必须有 diff）
  2. 轮数硬上限（--max-turns 15）
  3. 手动触发逃生口（workflow_dispatch）
  4. 失败不报警（exit 0），避免每天早上 9 点收一堆 false alarm

6.5 第 5 步：加 HITL 安全网

最后一步，给关键操作加 human-in-the-loop 确认。例如：

最后一步，给关键操作加 human-in-the-loop 确认。例如：

  • 推 main 分支前要人确认
  • 删除文件前要人确认
  • 发送外部通知前要人确认
  • 任何调用付费 API 前要人确认

Claude Code 的 Stop hook / Approval hook / MCP approval 都能干这个。

七、和 aizxs.com 之前文章的串联

文内图1

Loop Engineering 不是孤立概念，它和 aizxs.com 之前发的几篇文章形成完整的 AI 工程师能力链：

文章 ID 主题 在 Loop Engineering 体系中的位置
6/7 Claude Code 8353 终端 AI 编程 Loop 跑起来的载体（/loop / /goal 命令）
6/8 Cursor 8361 AI-First IDE Loop 中的编辑工具
6/10 Dify 8375 企业 RAG Loop 中的Context Engineering 层
6/11 Codex CLI 8382 命令行 AI 工具 Loop 中的执行器（类似 Claude Code）
6/17 Context Engineering 8690 上下文工程 Loop 中的Memory 与 Skill 层
本篇 Loop Engineering 系统的最外层：调度 + 验证 + 隔离

简单说：Context Engineering 是「给 agent 看什么」，Loop Engineering 是「让 agent 持续做对的事」。两个范式互为表里。

八、未来 6-12 个月的 3 个观察点

Loop Engineering 是个新东西，2026 年下半年这 3 个方向值得重点观察：

8.1 Loop-as-a-Service 平台会不会出现

目前每个团队都在自己搭 loop 配置（cron + claude -p + verifier）。会不会出现类似 Zapier / n8n 的 Loop-as-a-Service 平台？这将是 AI 工程师工具链的下一波洗牌。

8.2 /goal 类命令会不会成为 Agent 的标准配置

Claude Code 有 /goal、Codex 也有 /goal。这种「把终止条件作为一等公民」的范式，大概率会被所有主流 Agent 框架采纳。Cursor、Cline、Roo Code 谁先全量支持？谁就会抢走一波开发者。

8.3 Verifier 模型市场会不会独立

当 verifier 决定 Loop 的可靠性时，独立的轻量 verifier 模型市场就会出现。 现在的 Haiku、4o-mini、DeepSeek-V3-Fast 都可能成为 verifier 市场的早期玩家。这可能是 AI 应用层下一个百亿赛道。

8.4 一个能干的 verifier 是什么样的

未来 verifier 模型的几个关键能力：首先，它必须能基于事实做判断，而不是「觉得差不多」；其次，它要支持可解释——为什么这个产出算「达成」或「不达成」，必须给出明确理由；最后，它要可控——能通过 prompt 调整判断阈值，适配不同业务场景。 Anthropic 的 Haiku 已经在 verifier 场景上跑了 6 个月，是目前最成熟的实验样本。如果未来某家公司专门做「verifier-as-a-service」，大概率会从 verifier 工具起家，慢慢演化为 Loop 操作系统。

九、Loop Engineering 的 5 大反共识

写完这 6 个真实场景和 3 大风险后，我想给你 5 个反共识观点。这些观点和主流叙事相反，但都是经过一线 Loop 实践验证的：

反共识 1：Loop Engineering 不需要 AI 工程师背景

很多人以为这是程序员的事。实际上，写好终止条件的人是产品经理。一个 5 年经验的产品经理，比一个刚毕业的研究员，更知道「什么叫真正的完成」。

反共识 2：第一个 Loop 不要超过 30 行配置

很多人上来就搭 500 行的 pipeline。错。第一个 Loop 应该 30 行以内，3 个模块以内。 跑通后，再加功能。先活下来，再长大。

反共识 3：Loop 的成本不是 prompt 的成本，是 verifier 的成本

prompt 1000 token 一轮，verifier（即使 Haiku）也要 500 token 一轮。如果 loop 跑 30 轮才达成，verifier 占了 60% 的成本。所以选轻量 verifier，是降本的第一要务。

反共识 4：失败的 Loop 比成功的 Loop 价值高 10 倍

跑成功的 Loop 让你拿到产出，跑失败的 Loop 让你拿到「这个 goal 条件写错了」的认知。每个失败都要写进 PROGRESS.md，下次不再踩。

反共识 5：Loop Engineering 的天花板是「敢于不自动化」

最高级的 Loop 设计师，会主动选择「这一步我不自动化」。比如：删库、推 main、付款、调权限这些操作，永远留给人做。Loop 的优雅不是「自动一切」，是「知道什么该自动、什么不该自动」。

读完这 5 个反共识，你会发现 Loop Engineering 其实是个「节制工程」——节制你的自动化冲动，节制你对模型的信任，节制你对 100% 自主的执念。 这是它和过去 5 年所有「AI 全自动」叙事的根本区别。

十、互动话题

你日常工作中，有哪个任务已经烦到你想让一个 loop 来替你跑？如果让你设计一个 loop，你会怎么写它的 goal 条件？欢迎评论区聊聊，看看谁的 loop 最”狠”。

如果你是开发者，你现在的开发流里有几个 loop 在跑？用 crontab -l | grep -i claude 命令看看，说不定会吓你一跳。

参考资料

  1. Peter Steinberger 原推，2026 年 6 月 8 日 0:28 AM：https://x.com/steipete/status/…
  2. Addy Osmani《Loop Engineering》原文，2026 年 6 月 12 日：https://addyosmani.com/blog/loop-engineering/
  3. Lushbinary《Loop Engineering: The Guide for AI Agents》，2026 年 6 月 9 日：https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide
  4. ExplainX《What Is Loop Engineering? Beyond Prompt Engineering in 2026》，2026 年 6 月 13 日：https://explainx.ai/blog/what-is-loop-engineering-ai-agents-2026
  5. ExplainX《Loop Engineering: Coding Agent Loops That Run While You Sleep》，2026 年 6 月 9 日：https://explainx.ai/blog/loop-engineering-coding-agents-claude-code-guide-2026
  6. X 趋势页《Loop Engineering Replaces Manual AI Coding Prompts》：https://x.com/i/trending/2064013693747380450
  7. Youngju Kim《Loop Engineering — Design the System That Prompts Your Agent》，2026 年 6 月 12 日：https://www.youngju.dev/blog/ai/2026-06-12-loop-engineering-agentic-coding-systems.en
  8. WisdomAI《Why Loop Engineering Is the Next Step for AI Coding Teams Today》，2026 年 6 月 9 日：https://www.wisdomai.com/insights/matthew_berman/loop-engineering-agent-automation-ai-coding-automation-triggers-020a2af0
  9. SmartScope《What Is Loop Engineering? From Writing Prompts to Designing Agent Loops》，2026 年 6 月 12 日：https://smartscope.blog/en/generative-ai/methodology/loop-engineering-agent-loops-2026/
  10. DeskTheory《When to use /goal vs. /loop in Claude Code》，2026 年 6 月 8 日：https://desktheory.com/workflows/goal-vs-loop-claude-code
  11. CSDN 奇牙 coding123《Claude Code 两个被低估的新命令：/goal 让它自己干到底》，2026 年 5 月 13 日：https://deepseek.csdn.net/6a056c9554b52172bc7425fc.html
  12. 腾讯云《Claude Code 番外篇：内置 /loop 全解》，2026 年 4 月 2 日：https://cloud.tencent.com/developer/article/2649822
  13. Claude Code 官方文档 /loop 与 /goal：https://code.claude.com/docs/en/overview
  14. LangChain《Context engineering in agents》：https://docs.langchain.com/oss/python/langchain/context-engineering
  15. aizxs.com《Context Engineering 上下文工程实战》（6/17 已发）：https://aizxs.com/xuexijiaocheng/jinjieshizhan/8690.html