你还在手动 prompt AI 写代码？Loop Engineering 把这件事自动化了

你还在手动 prompt AI 写代码？Claude Code 负责人已经不这么干了。

Claude Code 的负责人 Boris Cherny 在一次分享里说了这么一句话：

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

翻译一下就是：他已经不再自己 prompt Claude 了。他写的是"循环"，让循环去 prompt Claude。他的工作是设计循环本身。

Peter Steinberger 也说过类似的话："你不应该再手动给编程 agent 发指令了。你应该设计循环，让循环去驱动你的 agent。"

Addy Osmani 在今年六月的一篇文章里给这个做法起了个正式名字：Loop Engineering——不再是"给 AI 写提示词"，而是"设计一个自动发现任务、分派任务、验证结果的计算系统"。

从手动挡到自动驾驶

这个转变不是突然发生的。Cherny 自己描述过这条演化路径：

2024 年底，Claude Code 大概写 10–20% 的代码。他用 IDE 加自动补全，大部分时间还是自己在写。

2024 年 11 月，他卸载了 IDE。同时开 5 到 10 个 Claude 会话，手动给每个会话发指令，像流水线工人一样逐个喂 prompt。

2026 年年中，他不再手动 prompt Claude 了。循环程序在替他做这件事。每晚跑几百甚至上千个 agent，自动处理 PR 维护、CI 修复、反馈分析。

Cherny 说这个过渡期"大概持续了几个月，可能贯穿了整年"——它不是目的地，是一个阶段。但这个阶段揭示了一个结构性的变化：你从 AI 的操作员变成了 AI 工作流的设计师。

Loop Engineering 是什么

Loop Engineering 的核心不是写 prompt，是设计一个闭环系统，这个系统自动完成四件事：

发现工作——自动扫描需要处理的任务（新的 issue、失败的 CI、未审核的 PR）
分派任务——根据任务类型选择合适的 agent 和工具
执行工作——agent 在隔离环境中完成编码、测试、文档等工作
验证结果——通过 CI、测试套件或其他可自动检查的标准确认输出质量

Addy Osmani 把 Loop 拆成了五个组件：

组件	作用
Automations	定时触发器（cron、/loop、/goal），自动发现和分派任务
Worktrees	隔离的 Git worktree，并行 agent 互不干扰
Skills	SKILL.md 文件存储项目知识、约定和经验教训
Plugins & Connectors	MCP 集成的 issue 跟踪、Slack、数据库、CI/CD
Sub-agents	将"制造者"和"检查者"分开——一个 agent 写代码，另一个验证

再加一个贯穿始终的：Memory。会话之间的状态文件或项目看板，因为模型每次运行之间的上下文会丢失。

有趣的是，Claude Code 和 OpenAI Codex 现在都内置了这五个原语。Loop Engineering 不是某个工具的专属技能，是一套可以跨工具复用的思维框架。

案例一：自动化 CI 修复（从手动拼命令到 GitHub Action）

原始做法：

bash

# 手动拼一长串参数
claude -p "检查最近的 CI 失败，修复测试" --model claude-sonnet-4-6 --max-turns 10

这只把"手动改代码"变成了"手动写 prompt"，本质上没有自动化。

Loop Engineering 的做法：

在 Claude Code 里运行：

/install-github-app

几秒钟生成一个可用的 GitHub Actions workflow，背后是官方 claude-code-action@v1。每当 CI 失败时自动触发，agent 读取失败日志，定位问题，提交修复 PR。

yaml

name: Auto-fix CI
on:
  workflow_run:
    workflows: ["Test"]
    types: [completed]
    branches: [main]

jobs:
  fix:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          prompt: "检查这个 workflow run 的失败原因并修复"
          max-turns: 10

Codex 那边的做法不同：用 codex exec 在云 sandbox 里跑。因为 sandbox 是隔离环境，提交修复后自动生成 PR。

bash

# Codex 在 CI 里跑
codex exec --mode workspace-write \
  "CI 失败了，读日志修 bug 并提 PR"

社区里已经有人在用这个模式——叫"gh-fix-ci"——把 CI 失败自动转成 background task。大部分 CI 失败本质就是那几类问题换皮：依赖版本锁定过期、快照测试没更新、lint 规则新增。

关键区别：手动挡是把"修 bug"这个动作从人换成了 AI，但人还是得盯着 CI 结果、触发修复流程。Loop 是把"监控 → 诊断 → 修复 → 提 PR"整条链路自动化了。

案例二：自动维护 API 文档（从 cron + bash 到 Routine）

原始做法：

一个定时任务脚本：

bash

# crontab
0 2 * * * /usr/local/bin/sync-docs.sh

脚本里做的事情：对比 handler/ 和 docs/ 的变更时间戳，找出不一致的文件，生成 diff，提交 PR。

问题是：这个脚本的 diff 逻辑很脆弱，只能做机械对比，看不出"文档描述和实际行为是否一致"。它知道的只是文件改没改，不知道改得对不对。

Loop Engineering 的做法：

在 Claude Code 里直接配一个 Routine：

text

/schedule

每天凌晨2点，检查过去24小时内 handler/ 目录下变更的文件，
对比 docs/api/ 下对应文档，更新不一致的部分，
如有变更则开 PR 给 @frontend-team

这不是一个 bash 脚本，是一个有理解能力的 Routine。它不是比时间戳，是读代码改了什么，再读文档写的是什么，判断两者是否匹配。

Routine 是 Anthropic 在 2026 年 4 月 14 日上线正式的功能。可以在 Anthropic 的云基础设施上运行，不依赖你的本地机器。支持三种触发器：

定时触发（每小时、每天、工作日、自定义 cron）
API 触发（HTTP POST 到指定端点，适合接入 Sentry 告警、CI 回调）
GitHub 触发（PR 事件、release 事件，可按作者、标签、分支筛选）

官方给的场景示例里，文档同步正好是最典型的例子之一。

关键区别：cron + bash 做的是机械对比，只能发现"文件改了"；Routine 做的是语义理解，能发现"行为变了但文档没跟上"。

案例三：批量处理 20 个 Issue（从人工分派到 Agent Teams）

原始做法：

一个一个来处理。开一个 session，处理完一个 issue，提 PR，关掉，开下一个。20 个 issue 意味着 20 次上下文加载和 20 次冷启动。

如果同时开多个终端窗口手动分派，又面临文件冲突的问题——两个 agent 同时改同一个文件，互相覆盖。

Loop Engineering 的做法：

启用 Claude Code 的 Agent Teams（实验特性，2026 年 2 月 5 日随 Opus 4.6 上线）：

bash

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude

然后在会话里说：

text

我们有20个标了 good first issue 的 issue。
你是 team lead，分配给4个 teammate，每人处理5个，
独立修复、写测试、提 PR，完成后汇总结果给我。

Agent Teams 的架构是一个 Team Lead 负责分配和协调，每个 Teammate 拥有独立的 1M token 上下文窗口。Teammate 之间通过共享任务列表（.claude/tasks/{team-name}/）通信，包含依赖跟踪和文件锁。互相之间可以直接发消息，不需要经过 Team Lead 中转。

推荐 3 到 5 个 teammate，成本是单 session 的 3 到 7 倍。

Codex 的做法更直接——排队提交 20 个任务，各自在云端 sandbox 并行跑完变成 PR：

bash

# 20 个 issue，并行 20 个任务
for issue in $(gh issue list --label "good-first-issue" --json number -q '.[].number'); do
  codex exec --mode workspace-write \
    "处理 issue #$issue，修复并提 PR" &
done
wait

不需要任何编排代码。每个任务有独立的云端 sandbox，多个 sandbox 同时运行互不干扰。结果各自变成 PR 推送回来。

关键区别：手动分派的问题是串行 + 文件冲突。Agent Teams 用隔离上下文 + 文件锁解决并行问题，Codex 用云端 sandbox 解决隔离问题。路径不同，但都实现了"20 个任务并行处理"这个目标。

为什么现在才出现这个趋势

不是技术没到，是成本结构变了。

2024 年大家还在纠结"一个 prompt 多少钱"。到了 2026 年，Token 成本已经降到可以支撑日常自动化任务的水平。Cherny 团队内部的数据是：

工程团队规模翻倍
人均产出（每天合并的 PR 数）增长 200%
新工程师上手时间从几周缩短到约 2 天
Claude Code 团队 90% 以上的代码是用 Claude Code 写的

但注意一个细节：Cherny 公开命名的几个 loop 全是看门型任务——不是"开发新功能"，是"维护现有系统"：

Loop	做什么	验证方式
PR Babysitter	自动 rebase、修复 CI、合并	CI / git
CI Health Keeper	修复 flaky 测试	测试套件
Twitter Feedback Cluster	每 30 分钟拉一次反馈	无需验证（仅供参考）

这些任务的共同点：验证成本极低。CI 通没通？测试过没过？这些都是机器可以自动判断的。Blake Crosley 在一篇分析里点出了关键：决定你能不能放一个 loop 去跑，不是 loop 怎么写，是验证成本有多高。

五个核心组件怎么配

1. Automations（自动化触发器）

不只是定时任务。一个合格的自动化触发逻辑要回答三个问题：

什么时候触发：定时（凌晨低峰期）、事件驱动（CI 失败）、按需（/schedule run）
做什么：每个触发器绑定一个具体的 agent 指令
谁负责：一个 agent 执行，另一个 agent（或 CI）验证

Claude Code 的 /schedule 支持自然语言描述，最小间隔 1 小时。Pro 计划每天 5 次 routine 运行，Max 计划 15 次，Team/Enterprise 25 次。

2. Worktrees（工作隔离）

多个 agent 并行工作时最怕的事：同时改一个文件。

Git worktree 的解法是给每个任务一个独立的工作目录，共享同一个 Git 仓库。Claude Code 的 /worktree 命令直接封装了这套流程。Codex 的解法是云 sandbox——每个任务在独立的容器环境里跑，彻底物理隔离。

两种路径都能到达同一个终点：并行 agent 互不覆盖。

3. Skills（项目记忆）

模型记不住你项目的特殊约定。每次冷启动都要重新解释一遍"我们项目的测试命名规范""数据库迁移的注意事项""代码审查的标准"。

Skills 就是把这些东西固化下来。在项目根目录放一个 .claude/skills/ 目录，每个 skill 是一个 markdown 文件，描述一个具体的任务模板。

例如，一个 PR review skill 可能包含：

markdown

# PR Review Checklist

1. 检查是否有调试代码残留（console.log、debugger、TODO）
2. 确认新加的错误处理覆盖了所有分支
3. 验证数据库迁移脚本向下兼容
4. 检查变更是否涉及 API 文档更新

模型在每次运行时自动加载这些 skill，不需要人工提示。

4. Connectors（外部连接）

用 MCP（Model Context Protocol）打通 agent 和外部系统。已经验证有效的集成场景：

Slack：agent 可以在 Slack 频道里报告任务进度、请求人工确认
Linear/Jira：agent 自动更新 issue 状态、创建子任务
Sentry：异常告警直接触发 agent 诊断流程
GitHub：PR 事件驱动 agent 做代码审查

Routine 的 connector 支持在 web UI 里配置，可以和定时触发器任意组合。

5. Sub-agents（分离制造和检查）

这是最容易被忽略但最重要的一条原则：不要让写代码的 agent 自己验证自己的代码。

人类的代码审查制度之所以有效，不是因为审查者技术更高，是因为审查者没有"写了这段代码"的路径依赖。Agent 也一样。一个 agent 写代码时已经决定了实现思路，让它自己 review，它大概率沿着同样的思路再看一遍。

正确的做法是配两个 agent：一个写，另一个用不同的 prompt 和不同的角度去验证。

应该从哪开始

如果你刚接触到 Loop Engineering 这个概念，直接上手设计并行 Agent Teams 或者配多任务 pipeline 是不现实的。正确的启动路径是：

第一步：只读观察

不要一开始就让 agent 改代码。先让它观察、对比、报告。

比如：写一个每天早上 9 点运行的 Routine，读取昨天的 CI 日志，总结失败案例的类型分布。不发 PR，不改代码，只输出一份报告到 Slack。如果报告质量稳定，再考虑下一步。

第二步：选择验证成本最低的任务

什么样的任务适合第一个跑循环？

验证成本低的特征：结果可以被机器自动判断。CI 修好了就是修好了，测试通过了就是通过了，文档更新了就是更新了。这些判断不需要人看一遍代码再决定。

验证成本高的特征：结果需要人做主观判断。"这个 API 设计好不好"、"这个错误提示用户看得懂吗"——这些任务目前还不适合放进 loop。

第三步：先设计报告，再设计循环

在你写第一个 loop 之前，先想清楚你要看到什么样的输出。

如果你收到一个通知说"工作完成了"，你需要在 10 秒内判断它是真的完成了还是只是跑完了。这意味着输出必须包含足够的信息让你快速决策：改了什么、验证结果是什么、还有哪些风险。

如果做不到这一点，说明验证环节还没设计好。

第四步：分离制造者和检查者

这步可以和你第一个 loop 一起配。

写 agent 的 prompt 专注于"实现需求"：读 issue、读代码、写出实现方案、提 PR。检查 agent 的 prompt 专注于"找问题"：读需求、读 PR diff、跑测试、看有没有遗漏边界情况。

同一个任务，两个角度，结果比单个 agent 自写自检查可靠得多。

需要注意的风险

Token 成本

Loop 跑起来这事本身不贵。但 sub-agent 层层展开，加上短间隔的例行检查，会把用量推高到超出预期的水平。一个每 5 分钟跑一次的状态检查 loop，早饭还没吃完就可能烧掉可观的 token。

建议的做法：给重要任务分配 budget，用 token 上限来做安全网。

验证不是万能

"Done" 是一个声明，不是一个证明。无人值守的 loop 会制造无人值守的错误。

一个 CI 全绿的 PR 不代表代码质量没问题——只是测试覆盖到的地方没问题。当 loop 开始自动合并 PR 时，"测试未覆盖的代码"就变成了一个需要人工关注的风险敞口。

理解负债

速度会掩盖"你实际理解了多少"这个问题。

当 agent 每天合入十几个 PR，而你只是扫一眼摘要就点 approve，你和代码库之间的理解差距就在慢慢积累。某天你发现需要手改一个地方，却已经看不懂依赖关系了。

关键追问：你是在加速交付，还是在加速制造你不理解的代码？

认知投降

最隐性的风险是：习惯了 loop 自动产出之后，你不再主动判断"这个需求该不该做"——你的姿势从主动设计变成了被动接受。

Addy Osmani 说得好：构建循环，但要像打算一直做这个项目的工程师那样去构建它，而不是像一个按了"启动"按钮之后就转身离开的人。

写在最后

Cherny 说那话的时候没有任何炫耀的意思。他只是在描述一个事实：手动 prompt 已经变成了瓶颈。不是 AI 不够聪明，是人的注意力不够分。

Loop Engineering 的核心洞察是：验证成本，而非循环构造，才是决定你能自动化什么的关键。

你的第一个 loop 不需要很复杂。可以从每天早上 9 点跑一个只读的 CI 日志分析报告开始。确认质量，再放权让它修。确认稳定，再放权让它提 PR。过程走扎实了，循环才能真正为你工作。

字节笔记本

你还在手动 prompt AI 写代码？Loop Engineering 把这件事自动化了

从手动挡到自动驾驶

Loop Engineering 是什么

案例一：自动化 CI 修复（从手动拼命令到 GitHub Action）

案例二：自动维护 API 文档（从 cron + bash 到 Routine）

案例三：批量处理 20 个 Issue（从人工分派到 Agent Teams）

为什么现在才出现这个趋势

五个核心组件怎么配

1. Automations（自动化触发器）

2. Worktrees（工作隔离）

3. Skills（项目记忆）

4. Connectors（外部连接）

5. Sub-agents（分离制造和检查）

应该从哪开始

第一步：只读观察

第二步：选择验证成本最低的任务

第三步：先设计报告，再设计循环

第四步：分离制造者和检查者

需要注意的风险

Token 成本

验证不是万能

理解负债

认知投降

写在最后