从写 Prompt 到Loop Engineering：AI 编程的下一次跃迁

TL;DR
[一、你不再是对 AI 说话的那个人了](#一、你不再是对 AI 说话的那个人了)
- [1.1 旧范式：乒乓球式的人机交互](#1.1 旧范式：乒乓球式的人机交互)
- [1.2 新范式：你退后一步，设计系统](#1.2 新范式：你退后一步，设计系统)
- [1.3 理论来源：从 Harness 到 Loop](#1.3 理论来源：从 Harness 到 Loop)
二、一个循环的五个零件，再加一本备忘录
- [2.1 五大零件全景图](#2.1 五大零件全景图)
- [2.2 零件一：自动化 --- 循环的心跳](#2.2 零件一：自动化 — 循环的心跳)
- [2.3 零件二：工作树 --- 让并行不变成混乱](#2.3 零件二：工作树 — 让并行不变成混乱)
- [2.4 零件三：技能 --- 别再每次都重新解释项目了](#2.4 零件三：技能 — 别再每次都重新解释项目了)
- [2.5 零件四：插件和连接器 --- 让循环触碰真实工具](#2.5 零件四：插件和连接器 — 让循环触碰真实工具)
- [2.6 零件五：子智能体 --- 把创作者和审查者分开](#2.6 零件五：子智能体 — 把创作者和审查者分开)
- [2.7 那个隐形的第六元素：状态](#2.7 那个隐形的第六元素：状态)
- [2.8 Codex vs Claude Code 能力对照](#2.8 Codex vs Claude Code 能力对照)
三、一个循环长什么样？
- [3.1 每日自动化流水线](#3.1 每日自动化流水线)
- [3.2 伪代码视角：循环的一天](#3.2 伪代码视角：循环的一天)
四、循环不能替你做的事
- [4.1 验证依然是你的事](#4.1 验证依然是你的事)
- [4.2 理解力依然会腐烂](#4.2 理解力依然会腐烂)
- [4.3 认知投降：最舒服的姿势最危险](#4.3 认知投降：最舒服的姿势最危险)
五、最后的提醒
参考

TL;DR

过去两年，我们使用 AI 编程助手的方式是一问一答、反复检查、来回修正，像打乒乓球。现在，一种叫 Loop Engineering（循环工程）的新范式正在成型：你不再亲自提示 AI，而是设计一套系统------它定时启动、自动发现任务、分配子智能体、检查结果、记录进度，然后决定下一步。这篇文章拆解了构成一个循环的五个核心组件（自动化、工作树、技能、连接器、子智能体），用通俗语言 + 代码示例 + 工具对比表，帮你理解这个正在改变 AI 编程工作流的新概念。

一、你不再是与 AI 对话的那个人了

1.1 旧范式：乒乓球式的人机交互

你有没有这样的体验：对着 AI 编程助手敲下一段精心打磨的提示词，等它生成代码，检查一遍，发现问题再补一句，它再改，你再查，来来回回，像个乒乓球比赛。这个过程累人，而且每次开新对话，你都得把项目的背景、规范、约定重新讲一遍。

Anthropic 旗下 Claude Code 的负责人 Boris Cherny 说过一句话：

"我不再亲自提示 Claude 了。我写了一些循环，它们会去提示 Claude、去搞清楚要做什么。我的工作是设计这些循环。"

另一位开发者 Peter Steinberger 说得更直接：

"你不再应该手动提示编程智能体了。你应该设计循环来替你提示它们。"

1.2 新范式：你退后一步，设计系统

过去两年，我们使用 AI 编程助手的方式基本一致：你写一句提示词，它输出一段代码，你检查，你修改，你再提示，循环往复。AI 是工具，你是握着工具的人，每一步都需要你亲力亲为。

而 Loop Engineering 要做的是，让你后退一步。你不再参与每一次具体的对话，而是搭建一个小型系统，这个系统会自己去发现任务、分配任务、检查结果、记录进度，然后决定下一步做什么。它像一个自动化的工头，而 AI 编程助手就是工地上的工人。

1.3 理论来源：从 Harness 到 Loop

这个概念不是凭空出现的。Addy Osmani 之前写过两篇相关文章：《Agent Harness Engineering》（为单个 AI 智能体打造运行环境）和《Factory Model》（让系统来构建软件）。Loop Engineering 在这两者的基础上再往上走了一层------它不仅为 AI 提供运行环境，还加上了一个"心跳"，让它定时启动、自动运转、自我补给。

三者之间的关系可以用下面的伪代码来理解：

python 复制代码

# 层级 1: Agent Harness Engineering --- 给单个智能体打造运行环境
class AgentHarness:
    """为一个 Agent 提供工具、权限和工作目录"""
    def __init__(self, agent, tools, workspace):
        self.agent = agent
        self.tools = tools
        self.workspace = workspace

    def run(self, task):
        return self.agent.execute(task, tools=self.tools)

# 层级 2: Factory Model --- 让系统来构建软件
class SoftwareFactory:
    """编排多个 Agent 协作完成项目"""
    def __init__(self, agents, pipeline):
        self.agents = agents
        self.pipeline = pipeline

    def build(self, spec):
        for stage in self.pipeline:
            stage.execute(self.agents[stage.role])
        return self.pipeline.artifacts

# 层级 3: Loop Engineering --- 加上定时器和自主决策
class Loop:
    """自动运转的循环：定时触发 → 发现任务 → 分配 → 检查 → 记录"""
    def __init__(self, automations, worktrees, skills, connectors, sub_agents):
        self.automations = automations    # 定时触发器
        self.worktrees = worktrees        # 并行隔离
        self.skills = skills              # 项目知识
        self.connectors = connectors      # 外部工具
        self.sub_agents = sub_agents      # 创查分离

    def tick(self):
        """每个周期自动执行一次"""
        tasks = self.automations.discover()
        for task in tasks:
            with self.worktrees.isolate(task) as workspace:
                fix = self.sub_agents.implement(task, self.skills)
                review = self.sub_agents.verify(fix, self.skills)
                if review.approved:
                    self.connectors.open_pr(fix)
                    self.connectors.update_ticket(task)
                else:
                    self.connectors.flag_for_human(task)
        self.state.record_progress()

可以看到，Loop 不是替代 Harness 或 Factory，而是在它们上面加了一层"自动驾驶"------让系统自己决定什么时候跑、跑什么、怎么检查、下一步做什么。

二、一个循环的五个环节，再加一本备忘录

2.1 五大零件全景图

要搭建一个能自主运行的循环，你需要五样东西，外加一个用来记录的本子。有趣的是，无论你使用的是 Codex 还是 Claude Code，这些核心部件都大致相同。

2.2 零件一：自动化 --- 循环的心跳

没有自动化，循环就只是一次性的手动操作，算不上真正的"循环"。自动化的作用是：定时启动，自动去发现问题、分类问题，然后将结果汇报给你。

在 Codex 中，你可以在 Automations 面板里新建一个自动化任务，选好项目、写好提示、设定频率，它就会按时运行。在 Claude Code 里，你可以用 /loop 命令设置定时任务，或者用 cron 表达式、GitHub Actions 来实现类似的效果。OpenAI 的团队已经在内部用这套机制处理日常事务了------每日 Issue 分类、CI 失败摘要、提交简报、回溯最近的 Bug，全是自动化在运行。

更妙的是，自动化可以调用技能（Skill），你无需将一大段指令直接塞进定时任务里，只需写一个 $skill-name，既简洁又可维护。

另外还有一个值得关注的命令：/goal。它不像 /loop 那样按固定频率执行，而是持续运行，直到某个条件被满足为止，例如"所有测试通过且 Lint 无报错"。每轮执行结束后，会有一个独立的模型来检查是否达标------写代码的模型不负责给自己打分。Codex 里也有同样的功能，名字也叫 /goal。

bash 复制代码

# Claude Code 中设置每日自动化循环的示例
# 方式一：使用 /loop 命令（交互式）
/loop "每天早上 9 点运行 triage skill，检查昨天的 CI 失败和未关闭 Issue"

# 方式二：使用 cron 表达式
# 每个工作日早上 9:00 执行
0 9 * * 1-5 claude run --skill triage --project my-repo

# 方式三：通过 GitHub Actions 触发
# .github/workflows/daily-triage.yml
name: Daily AI Triage
on:
  schedule:
    - cron: '0 9 * * 1-5'
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run AI Triage
        run: claude run --skill triage --output triage-report.md

2.3 零件二：工作树 --- 让并行不变成混乱

一旦你同时运行多个 AI 智能体，它们就会开始互相踩脚趾------两个智能体同时改同一个文件，效果和你与同事同时往同一行代码里提交改动一样灾难。

Git 的工作树（Worktree）机制解决了这个问题：它在同一个仓库里创建独立的工作目录，各自在不同的分支上操作，物理上就不会互相干扰。

bash 复制代码

# 创建一个隔离的工作树，供子智能体独立工作
git worktree add ../repo-agent-001 -b fix/agent-001-issue-42

# Claude Code 中指定工作树隔离
claude --worktree ../repo-agent-001 "修复 issue #42 的并发问题"

# 在子智能体配置中声明隔离模式
# .claude/agents/fixer.toml
isolation = "worktree"  # 每个子智能体获得独立工作树，完成后自动清理

Codex 把工作树直接内置了，，Claude Code 则通过 git worktree 命令和 --worktree 标志来提供同样的隔离能力。

不过 Osmani 提醒了一个关键点：工作树解决的是机械性的冲突，但你的审查带宽才是真正的天花板。你一次能认真审查多少个智能体的输出，决定了你能同时跑多少个并行任务，工具再好也绕不开这个限制。

2.4 零件三：技能 --- 别再每次都重新解释项目了

你有没有发现，每次开一个新的 AI 对话，你都得把项目的构建步骤、代码规范、注意事项重新解释一遍？这就是 Osmani 所说的"意图债务"（Intent Debt）------AI 每次都是从零开始，你留下的任何空白它都会用自信的猜测来填补。

技能就是解决这个问题的。一个 Skill 是一个文件夹，里面有一份 SKILL.md 文件，记录了项目的约定、构建步骤、"我们不用这种写法的原因是上次出了那个事故"之类的知识。写一次，每次循环运行都能读到。

markdown 复制代码

<!-- .claude/skills/code-review/SKILL.md 示例 -->
---
name: code-review
description: 代码审查规范，自动被审查类子智能体读取
---

## 审查检查清单
1. 所有公共函数必须有类型注解
2. 数据库查询必须带超时参数（上次生产事故的教训）
3. 不允许使用 `any` 类型，除非有充分理由并注释说明
4. 新接口必须同步更新 OpenAPI 文档

## 构建与测试
- 运行 `make test` 确保全部通过
- 运行 `make lint` 零警告
- 新增模块需要至少 80% 覆盖率

Claude Code 支持这种格式。技能是创作格式，而插件（Plugin）是分发格式------你想跨项目共享或打包分发一组技能时，就用插件。

2.5 零件四：插件和连接器 --- 让循环触碰真实工具

一个只能看到文件系统的循环是个"小循环"。连接器基于 MCP 协议，让 AI 能读取你的 Issue 追踪器、查询数据库、调用 Staging API、往 Slack 发消息。Codex 和 Claude Code 都"说"MCP 语言，所以为一个工具写的连接器通常也能在另一个工具里用。

这是"给你修好了"和"自动开了 PR、关联了 Linear 工单、CI 绿了之后在频道里通知了团队"之间的差距。连接器让循环真正在你的工作环境中行动，而不只是告诉你它会怎么做。

json 复制代码

// MCP 连接器配置示例 --- 让循环能操作 Linear 和 Slack
{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@linear/mcp-server"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@slack/mcp-server"],
      "env": { "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}" }
    }
  }
}

2.6 零件五：子智能体 --- 把创作者和审查者分开

循环里最有价值的设计，就是把"写代码的"和"查代码的"拆成两个不同的智能体。写过代码的那个模型，对自己写的东西打分时会心慈手软。换一个带着不同指令、有时甚至是不同模型的智能体来审查，能抓到前者自我说服时漏掉的问题。

toml 复制代码

# .claude/agents/verifier.toml --- 审查子智能体配置示例
[agent]
name = "verifier"
description = "严格审查代码变更，对照项目技能和测试规范"
model = "claude-sonnet-4-20250514"
reasoning_effort = "high"

[agent.instructions]
role = """
你是一个严格的代码审查者。你的唯一职责是找出问题。
不要对代码作者心软。对照以下检查清单逐一验证：
1. 对照项目 SKILL.md 中的规范
2. 确认所有现有测试仍然通过
3. 检查边界情况和错误处理
4. 验证安全性（注入、权限、数据泄露）
如果发现任何问题，标记为 REJECT 并给出具体原因。
"""

[agent.isolation]
mode = "worktree"  # 独立工作树，不污染主分支

在 Codex 里，你可以在 .codex/agents/ 目录下用 TOML 文件定义自己的子智能体，指定名称、描述、指令、模型和推理强度。Claude Code 同理，在 .claude/agents/ 里定义。通常的分工是：一个探索，一个实现，一个对照规范做验证。

Osmani 之前在两篇文章里分别讨论过这个主题（《The Code Agent Orchestra》和《Adversarial Code Review》），但在循环的语境下，它的重要性被放大了：循环在你不在场的时候运行，一个你真正信得过的验证者是你能放心走开的唯一理由。

当然，子智能体会消耗更多 Token，每个子智能体都要独立调用模型和工具，所以把它用在"值得花这笔钱买第二意见"的地方。

2.7 那个隐形的第六元素：状态

除了上面五个零件，还有一个看似微不足道但至关重要的东西：一份记录状态的备忘录。一个 Markdown 文件，或者一个 Linear Board------任何存在于单次对话之外、能记住"做了什么、下一步是什么"的东西。

听起来太简单了对吧？但这是所有长时间运行的智能体赖以生存的秘诀。模型在每次运行之间会忘记一切，所以状态必须写在硬盘上，而不是存在对话上下文里。模型会遗忘，但仓库不会。

markdown 复制代码

<!-- AGENTS.md --- 循环的状态文件示例 -->
## 2026-06-16 循环运行记录

### 已完成
- [x] ISSUE-42: 修复用户登录超时 → PR #1287 → 已合并
- [x] ISSUE-43: 更新依赖版本 → PR #1288 → 审查通过，等待合并

### 进行中
- [ ] ISSUE-44: 重构支付模块 → PR #1289 → verifier 驳回，需要补充测试

### 待处理
- [ ] ISSUE-45: 性能回归排查 → 自动化已标记，等待人工分配
- [ ] ISSUE-46: 文档更新 → 低优先级

### 已知问题
- verifier 对 ORM 查询的审查过于严格，考虑调整 skill 中的规范措辞

2.8 Codex vs Claude Code 能力对照

两个主流工具都已经内置了循环所需的全部五个零件，只是名称略有不同。下表对照了它们在每个维度上的对应实现：

循环零件	职责	Codex 实现	Claude Code 实现
自动化	定时发现与分类	Automations 面板：选项目、写提示、设频率；结果进 Triage 收件箱；`/goal` 命令运行直至达标	`/loop` 定时任务 + cron 表达式 + GitHub Actions + `/goal` 命令 + Hooks 生命周期钩子
工作树	并行隔离	内置 worktree，每个线程自动隔离	`git worktree` 命令；`--worktree` 标志；子智能体 `isolation: worktree` 配置
技能	项目知识固化	Agent Skills（`SKILL.md`），通过 `$name` 调用或自动匹配触发	Agent Skills（`SKILL.md`），通过 `/skills` 调用或自动匹配触发
连接器	打通外部工具	MCP 连接器 + 插件分发	MCP 服务器 + 插件分发
子智能体	创作与审查分离	在 `.codex/agents/` 下用 TOML 定义子智能体	在 `.claude/agents/` 下定义子智能体；支持 agent teams 协作
状态	跨运行记忆	Markdown 文件或 Linear（通过连接器）	Markdown 文件（如 `AGENTS.md`、进度文件）或 Linear（通过 MCP）

三、一个循环长什么样？

3.1 每日自动化流水线

将上述组件组合起来，一次对话就变成了一个小型控制台。Osmani 分享了他一直在用的一个模式：

每天早上，一个自动化任务在仓库上运行。其提示词调用了一个"分类技能"------读取昨天的 CI 失败记录、当前未关闭的 Issue、最近的提交，然后将分析结果写入一个 Markdown 文件或 Linear Board。

对于每个值得处理的发现，循环会打开一个隔离的工作树，派遣一个子智能体去起草修复方案，再派遣第二个子智能体对照项目技能和现有测试来审查该方案。连接器让循环自动创建 PR 并更新工单。循环处理不了的，才会出现在你的分类收件箱中等待你处理。

状态文件是整个系统的脊梁------它记住了哪些被尝试过、哪些通过了、哪些还开着。明天早上的循环启动时，它会从今天停下的地方继续。

注意：你设计了一次，你没有提示其中任何一步。这就是 Steinberger 所说的"你不再亲自提示 AI 了"。

3.2 伪代码视角：循环的一天

下面是一段伪代码，展示一个典型的每日循环在执行什么：

python 复制代码

def daily_loop():
    """每天早上 9:00 自动执行的循环"""
    
    # Step 1: 自动化 --- 定时触发，发现问题
    triage_report = run_skill("triage", context={
        "since": "yesterday 9:00",
        "sources": ["ci_failures", "open_issues", "recent_commits"]
    })
    
    # Step 2: 写入状态文件（跨运行记忆）
    state = load_state("AGENTS.md")
    state.add_findings(triage_report)
    
    # Step 3: 对每个值得处理的任务，并行执行
    for finding in triage_report.actionable_items:
        # Step 3a: 创建隔离工作树
        workspace = git_worktree_create(branch=f"auto/{finding.id}")
        
        # Step 3b: 派遣实现子智能体起草修复
        fix = sub_agent("implementer").run(
            task=finding.description,
            skills=load_skills(),
            workspace=workspace
        )
        
        # Step 3c: 派遣审查子智能体独立验证（不同模型！）
        review = sub_agent("verifier").run(
            change=fix.diff,
            against=load_skills(),
            tests=run_existing_tests(workspace)
        )
        
        # Step 4: 根据审查结果分流
        if review.verdict == "PASS":
            connector("github").open_pr(fix)
            connector("linear").update_ticket(finding.id, status="in_review")
            state.mark_completed(finding.id)
        else:
            connector("triage_inbox").flag_for_human(finding, review.reasons)
            state.mark_blocked(finding.id, review.reasons)
        
        # Step 5: 清理工作树
        workspace.cleanup()
    
    state.save()
    print(f"循环完成：{len(triage_report.actionable_items)} 项已处理")

四、循环不能替你做的事

循环改变了工作的方式，但它不能取代你的工作位置。而且随着循环变得越来越好，有三个问题反而会变得更尖锐。

4.1 验证依然是你的事

一个无人值守的循环，同时也是在无人值守地犯错误。你把验证者子智能体和创作者拆开，就是为了让循环说的"搞定了"多少有点含金量。但即便这样，"搞定了"也只是个声明，不是证明。

Osmani 在《Code Review in the Age of AI》里反复强调同一句话：你的工作是交付你确认能跑通的代码。 子智能体的审查能帮你过滤掉 80% 的低级错误，但剩下那 20% 的业务逻辑判断、架构决策、安全风险评估，仍然需要你的专业判断。循环可以加速你的工作，但不能替代你的判断。

4.2 理解力依然会腐烂

循环交付代码的速度越快，你实际理解的东西和已经存在的东西之间的差距就越大。Osmani 把这称为"理解债务"（Comprehension Debt），一个顺畅的循环只会让它增长得更快------除非你去阅读循环产出的内容。

这里有一个实际的风险场景：假设你的循环每周自动合并 10 个 PR。两个月后，代码库中 80% 的变更你都没有亲自读过。当线上出现一个由这些自动变更引发的诡异 bug 时，你甚至不知道该从哪个模块开始排查。这就是"理解债务"的利息------你借了速度，还的是排查时间。

4.3 认知投降：最舒服的姿势最危险

当循环自己运转时，你很容易停止思考，只是接受它给出的任何结果。Osmani 把这称为"认知投降"（Cognitive Surrender）。带着判断力去设计循环是解药，为了逃避思考而设计循环则是催化剂------同样的动作，相反的结果。

下表总结了循环使用中的三种典型模式，以及它们的后果：

模式	特征	短期效果	长期后果
主动设计者	精心设计技能，调整审查标准，阅读循环产出	前期投入大	理解力增长，质量持续提升
被动接受者	循环跑起来后就不管了，直接合并 PR	看起来省事	理解债务累积，排查成本飙升
完全放任者	不审查、不读代码、不维护技能	零投入	认知投降，代码库变成黑箱

五、最后的提醒

两个人可以搭建完全相同的循环，得到完全相反的结果。一个人用它来在自己深刻理解的工作上跑得更快，另一个人用它来逃避理解工作本身。循环不知道区别，但你知道。

这就是为什么设计循环比写提示词更难，而不是更简单。Boris Cherny 说的不是"工作变容易了"，而是"杠杆的支点移动了"。

去搭建你的循环吧。但请像一个打算继续做工程师的人那样去搭建，而不只是一个按下启动按钮的人。

参考

Addy Osmani, Loop Engineering
Addy Osmani, Agent Harness Engineering
Addy Osmani, The Factory Model
Addy Osmani, The Code Agent Orchestra
Addy Osmani, Adversarial Code Review
Addy Osmani, Code Review in the Age of AI
Addy Osmani, Long-Running Agents
Addy Osmani, Agent Skills
Addy Osmani, The Orchestration Tax
Addy Osmani, The Intent Debt
Addy Osmani, Cognitive Surrender