2026年玩AI必备技能：不是提示词，是循环工程

你有没有想过，2026年玩AI，最重要的技能可能不再是写提示词了？上周，谷歌云AI总监Addy Osmani的一篇博客文章《Loop Engineering》引发了广泛讨论。这位在前端开发、Web性能优化及AI开发者工具领域深耕多年的技术领导者（曾任Chrome开发者体验团队负责人），提出了一个值得关注的趋势。

他所探讨的“循环工程”概念，关乎如何设计一套系统，让代码智能体能够自动执行循环验证并持续提升。Addy Osmani的结论很直接：

先看看他到底说了什么。

所谓“循环工程”，本质上就是不再由你亲自向编程智能体下达每条指令，而是设计一个能自动执行这一过程的系统。这个“循环”可以理解为一种递归式目标：你设定一个意图，AI则不断迭代，直到任务完成。这一模式包含五个核心组件，而Claude Code和Codex目前都具备了这些要素。

可以确定的是，这很可能是未来与编程智能体协作的主流方向。当然，目前还处于早期阶段，需要谨慎看待；此外，Token成本是一个必须警惕的问题——根据预算的充裕程度，使用模式可能会截然不同。同时，如何确保代码质量不滑坡也是个现实挑战，人们对产出低质量代码的担忧并非空xue来风。既然这样，就让我们深入看看这究竟是怎么一回事。

龙虾作者Peter Steinberger最近指出：“你不应再直接向编程智能体发送指令，而应设计能够自动向智能体发送指令的‘循环’。”Anthropic旗下Claude Code的负责人Boris Cherny也表达了类似的观点：“我不再直接向Claude发送指令了。我运行着一些循环程序，由它们负责向Claude发送指令并决定下一步做什么。我的工作变成了编写这些循环程序。”

那么，这一切具体意味着什么？

过去大约两年里，利用编程智能体完成任务的方式通常是：编写高质量的提示词并提供充足的上下文信息。你输入指令，查看反馈，再输入下一条指令。智能体就像一件工具，你始终握着它，进行着一轮又一轮的交互。这种模式某种程度上已经过时了——至少许多人认为它即将成为过去式。

如今，你需要构建一个小系统来发现任务、分配任务、检查结果、记录进度并决定下一步行动；由这个系统去驱动智能体，而不是由你亲自动手。此前有分析提到过“智能体支撑框架工程”——即构建单个智能体运行的环境，以及“工厂模型”（即构建软件的系统）。“循环工程”则处于支撑框架之上：它基于定时器运行，能生成小型辅助程序，并能实现自我驱动。

值得注意的是，这已不再仅仅关乎“工具”了。一年前，如果你想要实现这种循环，往往需要编写一大堆Bash脚本，并长期维护这堆代码——那完全是属于你个人的东西。如今，这些组件已直接内置于产品之中。

Steinberger提出的要素清单几乎完全对应于Codex应用，同时也基本适用于Claude Code。一旦你发现两者的模式如出一辙，便无需再纠结于选择哪款工具；你只需设计一套工作闭环，无论身处哪个平台，这套流程都能顺畅运行。

五大要素及相关说明

一个完整的工作闭环需要五个要素，外加一个用于存储信息的载体：

1. 按预定计划自动运行，并能自主进行任务发现与分拣的自动化机制。

2. 支持多工作树机制，能确保并行工作的智能体互不干扰。

3. 用于记录项目知识的Skill模块，避免智能体在缺乏信息时只能靠“猜”来行事。

4. 插件与连接器，用于将智能体接入你现有的工具链中。

5. 子智能体机制，实现由一个智能体构思方案，而由另一个进行验证的协作模式。

最后是第六个要素：记忆存储。这可以是一个Markdown文件、一块Linear看板，或是任何独立于单次对话之外、用于记录已完成工作及后续计划的载体。这听起来似乎微不足道，但这正是所有长期运行的智能体所依赖的关键机制——正如分析“长期运行智能体”时所指出的，模型在两次运行之间会遗忘所有信息，因此记忆必须存储在磁盘上，而不能仅依赖上下文。智能体会遗忘，但代码仓库会保留记录。

如今，

。

虽然各处的命名略有差异，但核心功能是一样的。细节往往决定了一个循环是能稳健运行，还是会悄无声息地出现各种问题。

自动化（Automations）核心驱动力

正是自动化让“循环”名副其实，使其不仅仅是一次性的单次运行。在Codex应用中，你可以在“自动化”标签页创建一个任务，指定项目、要运行的提示词、执行频率，以及是在本地检出的代码上运行，还是在后台工作树上运行。发现问题的运行结果会进入“分类收件箱”，而未发现问题的运行则会自动归档——这非常方便。OpenAI内部利用它来处理一些枯燥琐碎的任务，比如每日问题分类、总结CI失败情况、撰写提交摘要，或是查找上周有人引入的Bug。

此外，自动化任务还可以调用Skill，从而保证重复性任务的可维护性：只需触发$skill-name，而无需将一大段冗长的指令硬塞进一个没人会去更新的调度配置里。

Claude Code实现了同样的目标，但采用的是调度和hooks机制。你可以使用/loop按固定间隔运行提示词或命令，可以设置cron任务，可以通过钩子在智能体生命周期的特定节点触发Shell命令，或者将其推送到GitHub Actions，以便在你合上笔记本电脑后任务仍能继续运行。理念完全一致：定义一个自主任务，设定执行节奏，让结果自动反馈给你，而无需你亲自四处检查。

还有一个值得了解的会话内原语，它更贴近本文的主题。/loop是按节奏重复运行的；而/goal则会持续运行，直到满足你设定的条件为止。在每一轮运行结束后，会有一个独立的小型模型来检查任务是否完成，这意味着编写代码的智能体并不负责评估结果。你只需设定类似“test/auth目录下的所有测试通过且代码检查无误”这样的目标，然后就可以去做别的事了。

Codex也有同样的功能，同样称为/goal：它跨轮次持续工作，直到满足可验证的停止条件，并支持暂停、恢复和清除操作。同样的机制，同样的工具——这正是贯穿整篇文章的模式。

这就是将工作成果呈现出来的环节。循环的其余部分负责对它进行操作。

Worktree（工作树）避免并行操作引发混乱

一旦运行多个智能体，文件冲突就会导致失败。两个智能体写入同一个文件，就像两个工程师在未沟通的情况下修改同一行代码一样令人头疼。Git Worktree解决了这个问题：它是在同一仓库历史基础上、位于独立分支上的独立工作目录，因此一个智能体的修改绝对不会影响另一个智能体的检出内容。

Codex内置了对Worktree的支持，允许多个线程同时访问同一个仓库而互不干扰。Claude Code也通过Git Worktree提供了同样的隔离机制：使用--worktree标志可以在独立检出环境中开启会话，或者在子智能体上设置isolation: worktree，让每个辅助智能体获得一个全新的检出环境，并在任务结束后自动清理。此前分析过其中的“编排成本”：Worktree解决了机械性的冲突问题，但人依然是瓶颈所在——决定你能实际运行多少个智能体的，是你的代码审查能力，而不是工具本身。

Skills无需每次都重新解释项目

“技能”机制能让你摆脱那种像金鱼一样、在每次会话中都要反复解释项目背景的困境。这两种工具采用相同的格式：一个包含SKILL.md文件的文件夹（其中存有指令和元数据），以及可选的脚本、参考资料和资源文件。Codex会在用户通过$或/skills调用时，或者当任务与技能描述匹配时自动运行该技能——这正是精准、平实的描述要优于花哨描述的原因。Claude Code的运作方式也如出一辙。

“技能”也是解决“意图成本”反复消耗问题的关键。智能体每次会话都是从零开始的，它会自信地填补你意图中的任何空白。而“Skill”就是将这些意图（如约定俗成的规范、构建步骤、诸如“因为某次事故所以我们不这么做”之类的经验教训）显式地记录下来；只需编写一次，智能体每次运行时都会读取。如果没有技能，循环会在每个周期从零开始重新推导整个项目；有了技能，知识积累就能产生叠加效应。首先要明确一点：Skill指的是创作格式，而Plugin则是交付它的方式。当你需要在不同代码仓库间共享Skill，或者将多个Skill组合在一起时，就可以把它们打包成Plugin。这一逻辑在Codex和Claude Code中均适用。

Plugins与Connector让“循环”能够与你的实际工具交互

如果一个“循环”只能访问文件系统，那它的能力将非常有限。基于MCP构建的连接器则打破了这一局限，让智能体能够读取Issue追踪系统、查询数据库、调用预发布环境的API，甚至在Slack上发送消息。由于Codex和Claude Code都支持MCP标准，因此你为其中一个编写的连接器，通常也能直接在另一个中运行。此外，插件将连接器和Skill整合在一起，方便你的团队成员一键安装并使用整套配置。

这就是“只会说‘修复方案如下’的智能体”与“能自动提交PR、关联Linear工单并在CI通过后在频道通知的循环”之间的区别。正是因为有了连接器，循环才能在你的实际环境中采取行动，而不只是空谈它“如果能操作的话”会做什么。

子智能体将“执行者”与“检查者”分离

在循环机制中，最有用的结构性设计莫过于将编写代码的角色与检查代码的角色分离开来。负责写代码的模型在评估自己的“作业”时往往过于宽容；而另一个拥有不同指令（有时甚至使用不同模型）的智能体，则能发现第一个智能体因自我合理化而忽略的问题。

Codex仅在你明确要求时才会启动子智能体，让它们并行运行，最后将结果汇总为一个答案。你可以通过.codex/agents/目录下的TOML文件定义自己的智能体，每个智能体包含名称、描述、指令以及可选的模型和推理强度设置；这样，你的安全审查员可以是高推理强度的强大模型，而负责探索任务的智能体则可以是快速、只读的轻量级模型。Claude Code也有类似机制，利用.claude/agents/中的子智能体和智能体团队在彼此间传递任务。在这两种工具中，常见的角色分工通常是：一个负责探索，一个负责实现，另一个根据规范进行验证。

之所以在循环机制中这一点尤为重要，是因为循环是在你无人值守的情况下运行的；只有拥有一个你真正信任的验证者，你才能放心地离开。子智能体确实会消耗更多Token（因为每个智能体都要独立进行模型调用和工具操作），因此应将资源投入到那些值得获取“第二意见”的环节中。这其实也是Claude Code的/goal命令在底层运作的原理：由一个全新的模型（而非执行任务的那个模型）来判断循环是否结束——即将“执行者”与“检查者”分离的原则应用到了终止条件的判定上。

一个循环的典型形态

将这些组件组合起来，单一的执行流就变成了一个小型控制面板。以下是一种常见模式。

针对代码仓库，每天早上运行一次自动化任务。它的提示词会调用一个“分诊”技能，该技能读取昨天的CI失败记录、未解决的问题和最近的代码提交，并将分析结果写入Markdown文件或Linear看板中。对于每一项值得处理的问题，流程会创建一个独立的工作树，并派遣一个子智能体起草修复方案，随后由第二个子智能体根据项目的既有技能和现有测试用例对该草案进行审查。

通过连接器，该循环能够自动创建PR并更新工单状态。凡是循环无法处理的事项，都会进入“分诊收件箱”等待亲自处理。状态文件是整个系统的核心，它记录了已尝试的操作、已通过的任务以及未完成的工作，确保明早的运行能从今天中断的地方继续进行。

回想一下你实际做了什么：你只进行了一次设计，而无需针对后续的每一步骤单独下达指令。这正是Steinberger观点的具体实现；无论是在Codex还是Claude Code中，其循环逻辑都是一样的，因为底层的组件是相同的。

循环仍然无法代劳的事项

循环改变了工作方式，但并未将你从工作中剔除。事实上，随着循环能力的提升，有三个问题反而会变得更加棘手，而非变得简单。

验证工作依然由你负责。一个无人值守运行的循环，也可能在无人监督的情况下犯错。将验证子智能体与执行子智能体分离开来，其目的正是为了赋予循环所宣称的“已完成”状态以实质意义——即便如此，“已完成”也只是一种声明，而非确凿的证明。有句适用于AI时代代码审查的话：你的职责是交付那些经你确认可正常运行的代码。

如果你疏于维护，你对代码的理解就会逐渐退化。循环交付非你亲手编写代码的速度越快，现有代码与你实际掌握情况之间的鸿沟就越大。这就是“理解债务”；除非你亲自阅读循环生成的代码，否则高效的循环只会让这种债务积累得更快。

没错，那种看似舒适的状态往往伴随着风险。当循环自动运行时，人很容易放弃独立思考，转而全盘接受它给出的结果。这可以称为“认知投降”。设计循环时，若能保持判断力，它便是良方；若仅仅为了逃避思考而设计，它便成了加速恶化的催化剂——同样的动作，结果却截然不同。

构建循环，坚守工程师本色。这预示了我们工作方式的演变方向。话虽如此，如果我不亲自审查代码，或者完全依赖自动化循环来修复问题，产品的质量就会受损。恐怕会陷入恶性循环，越陷越深。

当然，你可以着手构建这些循环，但别忘了，直接向智能体下达指令依然行之有效。关键在于找到合适的平衡点。

同样的循环机制，因使用者不同，结果也可能截然不同。两个人构建完全相同的循环，可能会得出完全相反的结论：一个人利用它来加速处理自己深刻理解的工作，而另一个人则利用它来彻底回避对工作的理解。循环本身无法区分这两者，但你能。

正因如此，设计循环比编写提示词更具挑战性。

这是工程工作，并未变得更轻松。并非工作本身变简单了，而是关键的杠杆点发生了转移。

去构建这个循环吧。但构建时，要怀着一种“立志深耕工程领域”的心态，而不仅仅是做一个只会按下启动键的人。

参考内容：

https://x.com/addyosmani/status/2064127981161959567