三年时间，AI 工程方法论完成了四次迭代：Prompt Engineering、Context Engineering、Harness Engineering，以及三天前刚被正式命名的 Loop Engineering。每一次迭代，人的介入深度都在降低，系统设计能力的权重都在上升。

一个值得注意的信号

Claude Code 的创造者 Boris Cherny，在今年 5 月初红杉资本 AI Ascent 2026 大会上说了一句话：“我不再提示 Claude 了。我有运行中的循环在提示 Claude，并决定接下来做什么。我的工作是写循环。”支撑这句话的，是一组可查证的数字：2025 年 12 月，他公开表示自己已经卸载了 IDE，因为前一个月单月 259 个 PR 全部由 Claude Code 完成，他没有亲手写过一行代码；到了 2026 年，按他在 AI Ascent 上的说法，他每天从手机上发出几十个 PR；另据报道，今年 3 月起，Claude Code 这个产品本身已经 100% 由 Claude Code 编写。

一个月后的 6 月 8 日，Google Cloud AI 总监 Addy Osmani（此前近 14 年负责 Chrome 开发者体验）发布长文，把这种工作方式正式命名为 Loop Engineering（循环工程），给出了迄今最系统的定义：“Loop Engineering，就是把你自己从‘提示 Agent 的那个人’的位置上挪开，改成设计一个系统替你干这件事。”也就是说，这个概念正式成型至今不到一周。但它不是凭空出现的，要理解它，得先回看这条演进线的前三段。

演变史：人是怎么一步步退场的

AI 工程方法论这三年，本质上是一部”人逐渐退场”的历史。

第一阶段：Prompt Engineering（2023 年起）。 人是绝对的主动方。你写提示词，AI 执行，一问一答。这个阶段的核心技能是”把指令说清楚”：角色设定、少样本示例、思维链。AI 是一个听话但需要精细指令的工具，你掌控每一个输入。

第二阶段：Context Engineering（2025 年中起）。 随着 Agent 处理的任务变长，单条提示词装不下所需的信息了。Karpathy 等人的讨论把”上下文工程”带入主流，Anthropic、LangChain 相继给出正式定义。核心技能从”写好一句话”变成”管理模型看到什么”：RAG、MCP、记忆机制、上下文窗口的取舍。人开始从逐字编写指令，后撤到设计信息供给。

第三阶段：Harness Engineering（2026 年 2 月起）。 HashiCorp 联合创始人 Mitchell Hashimoto 在 2 月 5 日的博客《My AI Adoption Journey》中提出”engineer the harness”：每当 Agent 犯一个错，不要去改提示词，而是改造它运行的环境，让这个错误在结构上不可能再发生，用 Linter 封死错误写法、用 AGENTS.md 固化项目规则、用钩子强制检查。几天后，OpenAI 发布实践报告：三名工程师用五个月，零手写代码，靠 Codex 构建了约一百万行的代码库。”Harness Engineering”一词由此确立。人的角色从”指挥 AI”变成”为 AI 修路”。

第四阶段：Loop Engineering（2026 年 6 月起）。 Harness 解决的是”单个 Agent 单次运行的可靠性”，但启动它的仍然是人。Loop 在 Harness 之上再加一层：让系统自己发现工作、分发工作、检验结果、记录进度、决定下一步。用 Osmani 的话说，循环就是”装上了定时器、会自己孵化助手、会自我喂养的 Harness”。人彻底退出执行环节，只保留设计权和验收权。

把四段连起来看，规律非常清楚：每一次迭代，被工程化的对象都上移了一层，从一句指令，到一段上下文，到一个运行环境，再到一个完整的工作系统。 而留给人的，始终是更上一层的设计工作。

一个循环由什么构成

按 Osmani 的拆解，一个完整的 Loop 由五个构件拼成，外加第六样东西。Claude Code 和 Codex 目前都已凑齐全套。

1. 自动化任务-循环的心跳。 有了它，循环才会自己转，而不是你手动跑一次就停。Claude Code 提供了两个原语：/loop 按节奏重复执行（适合周期性检查），/goal 持续运行直到完成条件成立。值得注意的细节是：判断”算不算完成”的，是一个独立的小模型，而不是写代码的那个 Agent 自己。

2. Skills-循环的长期知识。 解决”每开一个新会话都要从头介绍项目”的问题。它本质上是一个结构化文件夹，存放项目约定、构建步骤、历史踩坑记录。写一次，Agent 每轮运行都读得到。”这事我们不这么干，因为上次出过事故”——这类组织知识第一次有了机器可读的沉淀形态。

3. 子 Agent-创作者与检验者分离。 这是循环里最重要的结构性设计：写代码的 Agent 给自己打分，手太松；换一个指令不同、甚至模型不同的第二个 Agent 来审，能逮住第一个说服自己忽略的问题。常见分工是：探索 Agent → 实现 Agent → 验证 Agent。这和产品组织里”测试不能由开发自测”是同一个原理。

4. 连接器-循环的触角。 只能看到文件系统的循环是个微型循环。基于 MCP 的连接器让它能读问题追踪器、查数据库、开 PR、更新工单、往 Slack 发通知。接入回报的大致排序：GitHub → Linear/Jira → Slack → Sentry。

5. Worktrees-并行的隔离仓。 多个 Agent 同时工作时，各自在独立分支的独立目录上操作，互不污染，干完自动清理。这是”并行”不退化成”混乱”的前提。

第六样：记忆。 一个落在磁盘上的状态文件，记着”干完了什么、还剩什么、上次踩了什么坑”。模型每次重启都失忆，所以记忆必须活在单次对话之外。Agent 会忘，仓库不会。

五个构件拼起来，一条对话线就变成了一个小控制台：每天定时启动，调用 Skill 读取昨天的异常，为每条值得处理的发现开一个隔离工作区，派实现 Agent 起草、验证 Agent 审核，能搞定的自动提交，搞不定的落进分诊收件箱等人。你做的事是把它设计出来——理论上，只做一次。

适用边界：先过这道检查

不是所有任务都适合做成循环。四个条件全部满足，才值得投入：

1. 任务足够重复：至少每周发生一次，否则搭建成本永远摊不平。
2. 结果能自动验证：有测试、规则或明确完成标准，机器能判断对错。
3. Token 预算充足：循环要反复重读上下文、重试、探索，消耗远超单次对话。
4. 工具链已接通：Agent 看得到日志、跑得了流程、查得到结果。

适合做成循环的：CI 失败分诊、依赖升级、规范检查、Issue 转草稿。不适合的：架构决策、核心业务逻辑、生产环境操作，以及一切”做错了代价很高”或”好坏靠品味判断”的工作。

对 AI 产品经理意味着什么

这里有一个值得认真对待的重新定位：当 AI 承担执行层，人的核心价值就从“会用 AI”变成“会设计 AI 系统”。 而系统设计、流程拆解、规则定义、异常边界，这些恰好是产品经理的原生能力。Loop Engineering 对 PM 不是威胁，是一次能力变现的窗口。

具体到工作方式，有三层迭代：

重复性工作，从“人驱动”变成“系统自转”。 可以优先考虑的场景包括：用户反馈的自动分类与标签化（验证标准：分类规则命中率）、竞品动态的定期监控与摘要（验证标准：信源清单覆盖度）、数据指标的异常检测与预警推送（验证标准：阈值规则）、需求文档的格式与规范校验（验证标准：模板检查项）。注意每个场景后面都跟着验证标准 没有可自动验证的完成条件，就没有合格的循环，这是设计循环时第一个要回答的问题。

AI 的错误，从“靠提示词补救”变成“靠机制兜底”。 过去 Agent 跑偏，第一反应是改提示词；Loop 的思路是在架构层面预置检验机制、回退策略和升级路径，搞不定的自动升级给人，而不是硬着头皮蒙混过关。这正是 Harness 思想的延续：把纠错从”事后沟通”变成”事前结构”。

核心价值，从“会操作”升级为“会设计”。 写一个好提示词的门槛在快速归零，但设计一个能稳定运行、自我纠错、知道何时求助的循环系统，需要对业务流程、验证逻辑、异常边界的深刻理解。这个能力短期内不会被工具吃掉。

动手之前，先听几句实话

到这里为止，都是这套范式好的一面，也是你在任何一篇解读里都能读到的一面。但搭循环要投进去实打实的时间和 Token，所以有几个问题我自己反复琢磨之后仍然觉得别扭，值得在动手前摊开说。

第一个别扭的地方，是那些明星数字本身。Cherny 单月 259 个 PR，这个产量是工具作者在理想环境里做出来的：Claude Code 是他亲手写的，工具的每个脾气他都清楚；他跑循环的仓库，大概率早就按”适合 AI 干活”的标准收拾过——测试齐全、规范统一、文档同步。而大多数团队面对的是十年陈的存量系统，文档好几年没人更新，测试覆盖率拿不出手。拿创造者的吞吐量做对标，参考价值很有限。真正的门槛往往不是”会不会搭循环”，而是”代码库有没有达到能跑循环的状态”。就我的观察，多数企业代码库还没有。

第二个，是”只设计一次”这句承诺。它在现实里很难成立。提示词确实不用写了，但活换了个形态等着你：Skill 写完几个月就过期，连接器隔三差五要修，验证条件会被下一个需求绕开，状态文件慢慢和现实脱节。这些维护工作都得有人做，那个人还是你。工作量没有消失，只是从”调 Prompt”搬到了”养 Loop”。如果任务频次不够高、又难以自动验证——这恰恰是大部分团队的真实情况——这笔账目前算不回来。

第三个，是被夸得最多的”创作者与检验者分离”。道理本身没问题，开发不能自测。但这里有个绕不开的事实：两边都是 LLM，相近的训练数据、相近的盲区、相近的过度自信。第二个 Agent 能逮住低级笔误，可一旦第一个 Agent 的整个方向就是错的，两个模型很可能一起点头放行。这不是两个独立的审计员，更像一个人在照镜子。在统计意义上，它不构成独立验证。

第四个，做过数据指标的产品经理会很熟悉：Goodhart 定律。完成条件一旦写成”测试通过、检查干净”，循环优化的目标就悄悄从”把事做对”变成了”让指标变绿”——放松断言、给 Mock 注水、用 try/catch 吞掉异常，都是它找得到的捷径。指标一旦成为目标，就不再是好指标，这条老规律在循环身上应验得格外快，因为循环是不知疲倦、不会厌烦的指标博弈者。对要为自动化流程设计验收标准的 PM 来说，这是最直接的一条提醒。

最后还有一笔慢账：理解债。循环产出越快，你没亲手做过、也没仔细看过的东西就越多。当产出速度超过审阅速度，瓶颈就从”做”挪到了”看”，而审阅的人手不会因为搭了循环就自动变多。不读它产出的东西，相当于在按复利借理解债。

循环只奖励已经想明白的人

两个人搭出一模一样的循环，结果可能完全相反：一个拿它在自己吃透的流程上跑得更快，一个拿它绕开”吃透”这件事本身，循环分不出这两者，但你分得出。在搭一个 Loop之前，先回答三个问题：我最熟悉的那个重复性工作流，它的输入是什么？验证标准能否被机器执行？异常情况有哪些、各自升级给谁？

Loop Engineering 的杠杆点，从来不在工具上，而在你对自己工作的理解深度上。