Loop Engineering：从提示词操作者到循环设计者的14步路线图

• 手动写提示词已过时：从提示操作者到循环设计者完整落地手册

• 循环工程避坑：不满足 4 个条件，搭建 Loop 只会沦为 Token 成本黑洞

• 2026 工程师核心竞争力：Loop Engineering 循环设计 14 步路线图

还在手动向AI写提示词吗？那你可能正在用上个时代的方式做这件事。

2026 年 AI 编码领域最大范式转移已经落地。

Anthropic Claude Code 负责人 Boris Cherny 公开表示，自己早已不再手动编写提示词，全部交由循环系统自主驱动 Agent。

Google Addy Osmani 系统化提出 Loop Engineering 循环工程，彻底重构开发者与 AI 协作的杠杆支点。

过去两年，开发者比拼的是 Prompt 技巧、上下文编排能力；但 2026 年行业竞争维度全面上移，真正拉开生产力差距的，不再是单次提示词质量，而是能否搭建可自主调度、自我校验、持久运行的 AI 循环系统。

目前市面上很多讨论与教程只讲循环架构，却极少客观讲清落地门槛、成本约束与隐性风险。

近期，来自旧金山的AI研究员、独立顾问Lev Deviatkin写了一篇关于Loop Engineering14部路线图的文章，我感觉有助于大家理解与应用循环工程，遂翻译了这篇文章。

该文结合 Codex、Claude Code 双工具落地实践，完整拆解三层落地逻辑：先判断自身是否具备搭建循环的四大前置条件，吃透自动化、工作树、Skill 技能包、MCP 连接器、子 Agent 五大基础构件，最后分步搭建低风险、可落地的最小可用循环，同时拆解 Ralph Wiggum 失效循环、理解债务、安全攻击面等极易被忽略的关键隐患。

全文核心克制观点先行：循环工程并非适合所有开发者，缺少重复性任务、自动化校验、充足 Token 预算、完备工具链任意一项，搭建循环只会持续消耗成本，无法产生正向收益。

完整 14 步落地流程，可以帮大家从手动 Prompt 操作者，升级为自主 AI 循环系统设计者，对正在研究Loop Engineering的朋友会有所启发。

以下是正文。

循环工程：从提示词操作者到循环设计者的 14 步路线图

Loop engineering: the 14-step roadmap from prompter to loop designer

大多数开发者仍然需要手动来指挥他们的编程助手。他们输入代码，等待结果，查看代码差异，然后再输入代码。十分之九的开发者从未编写过任何能够自动指挥编程助手的代码。

无需自动化处理，无需状态文件，无需验证机制，也无需固定的时间表。重点已经发生了转变：不再是单纯输入提示词，而是设计出能够自动生成提示词的系统。以下是从“提示词输入工具”到“自动提示词生成系统”的 14 步实现路径。

本文是对这一 14 步路线图的系统梳理，内容来源于 Anthropic 工程文档、Addy Osmani 的循环工程深度文章，以及近期实测研究。

三个层次：判断你是否真正需要一个循环，学习五个基础构件，然后构建一个可运行、低风险的最小循环。

14 个步骤。3 个层次。停止手动提示，开始设计系统。

第一部分：为什么要做，以及如何测试 01. 循环工程，本质是用系统替代你这个提示词操作者 Loop engineering is replacing yourself as the prompter.

过去两年，从编码agent处获取成果的方式是：编写提示词、分享上下文、查看代码差异、再写下一条提示词。agent只是一个工具，而你始终亲自握着这个工具在操作。这个时代正在结束。

循环工程，是构建一个能够自主识别待处理工作、将其交给agent、检查结果、记录过程并决定下一步行动的小型系统。你只需设计这个系统一次，之后由系统代替你向agent发出提示词。

Addy Osmani 将其分解为六个部分。

Anthropic 工程师当前每日合并代码量是 2024 年的八倍，Anthropic 自身将这一数字称为"几乎可以肯定是对实际生产力提升的夸大"。

这个数字存在争议，但其背后的机制并无异议：杠杆点已从手动输入提示词，转移到设计能够自主驱动agent的循环。

02. 在构建任何东西之前，先进行四条件测试 Run the 4-condition test before you build anything.

循环只有在四个条件下才值回其成本。缺少任何一个条件，循环的代价便会超过其收益。以下是 AlphaSignal 分析中更坦率的判断，也是大多数相关讨论所略去的部分：

四个条件，用简明语言描述如下：

任务具有重复性。循环将设置成本分摊到多次运行中。对于一次性任务，一条优质提示词通常更快、更经济。如果工作不能每周重复发生，你拥有的不是一个循环，而是一段只运行过一次的脚本。

验证是自动化的。循环需要一种能够在无人值守的情况下判定工作是否失败的机制——测试套件、类型检查器、代码检查工具、构建流程，皆可。没有自动化检查，意味着你仍然回到椅子上逐一审阅每一处代码差异——而这正是循环本应消除的工作。

token预算足以承受消耗。循环会反复读取上下文、重试、探索。无论本次运行最终是否交付任何可用变更，这一过程都会消耗token。这项技术的收益随预算规模而扩大——这就是为什么它对拥有近乎免费token配额的人来说显而易见，对使用按量计费套餐的人来说却显得冒进。

agent拥有高级工程师的工具集。日志、可复现的运行环境、执行所写代码并观察错误的能力。缺少这些，循环的每次迭代都是盲目的。

03. 谁受益，谁受损：循环偏向有资源投入的一方 Who wins, who loses. Loops favor whoever can spend.

循环工程的经济逻辑并不普适。那些认为它理所当然的人，往往拥有不受限制的token配额。

那些认为它冒进的人，通常使用的是每月 20 美元的个人版套餐，试图在不触及限额或产生意外账单的情况下运行重型验证循环。

实际受益者包括：

• • 拥有重复性、可由机器检查的工作，且有预算运行循环的团队：持续测试分诊（triage，即故障分类与初步处置）、依赖项升级、lint-and-fix 检查、基于 Issue 生成 PR 草稿，且代码库具备高测试覆盖率；

• • 已具备完善测试套件的代码库：如果一名初级工程师能根据检查清单完成任务，而测试套件能捕获其错误，那循环就适用；

• • 已采用异步优先模式和多agent模式的团队：对这些团队而言，例程（Routines）是缺失的编排层。

目前应跳过循环的场景：

• • 使用个人版套餐的独立开发者：token账单会在生产力收益显现之前先行到来；

• • 代码库缺乏自动化验证的任何人：没有真实检查的循环，本质上只是agent在反复给自己背书；

• • 真正瓶颈在于审查吞吐量而非输入速度的团队：循环会生成更多代码，如果审查本已是瓶颈，它只会让队列更长。

对于一次性任务、探索性工作，或任何"完成"标准依赖主观判断的场景，一条精准的提示词仍然是更优选择。本文诚实的版本是：循环工程是真实存在的，但大多数开发者目前还不需要它。

04. 30 秒循环检查清单 The 30-second loop check.

第 02 步中的四条件测试是战略层面的决策。这是战术层面的决策，在将具体任务转化为循环之前需要执行的检查清单。

只要有一项不满足，就不要构建循环，继续采用手动提示词处理。

1. 1.任务至少每周发生一次。频率低于每周 → 设置成本永远无法摊薄。

2. 2.测试、类型检查、构建或代码检查工具能够拒绝不合格的输出。没有自动化质量门禁 → agent在批改自己的作业。

3. 3.agent能够运行它所修改的代码。没有可复现的运行环境 → 迭代是盲目的。

4. 4.循环设有硬性停止条件。token预算上限、迭代次数上限或时间限制，三者取其一。没有硬性停止，循环会一直运行，直到有人注意到账单为止。

5. 5.在合并、部署或依赖项变更前，须经人工审查。任何不可逆的操作，都需要在执行前设置人工审批关卡。

适合作为首个循环的场景：

• • CI 故障分诊——每晚定时扫描故障，按根因分类，为简单问题起草修复 PR；

• • 依赖项升级 PR——每周扫描可用更新，测试兼容性，创建 PR；

• • Lint-and-fix 检查——在每次 PR 创建事件触发时，自动应用代码风格修复；

• • 不稳定测试（flaky test）复现——持续循环，直到某个假设经测试仍然成立；

• • 基于 Issue 生成 PR 草稿，适用于测试套件能够拒绝不合格输出的高覆盖率代码库。

不适合作为首个循环的场景——这些需要人工主导：

• • 架构重构

• • 认证或支付相关代码

• • 生产环境部署

• • 模糊的产品需求工作

• • 任何"完成"标准依赖主观判断的场景

自动化是让循环真正成为循环而非一次性运行的关键。它按调度计划、按事件或按触发条件启动。自动化是心跳，循环中的所有其他部分都依附于它。

两款主流工具的实现方式：

Codex：在"自动化"选项卡中，选择项目、设置提示词、配置执行频率，选择本地检出或用于后台运行的工作树。有发现内容的运行会进入 Triage 分诊收件箱；没有发现内容的运行则自动归档。

Claude Code：由三种原语组合而成，形态相同：

/loop用于会话范围内的周期性执行；桌面计划任务用于实现跨重启持久运行；Routines 用于在笔记本离线或关机时执行云端运行。可配合 hooks 使用以处理生命周期事件。

区分有效循环与高耗循环的两个内置原语：

• •/loop按指定周期重复运行。适用于无论状态如何都需要定期检查的场景。

• •/goal持续运行，直到你编写的条件真正满足为止。由一个独立的小型模型检查是否达成，因此编写代码的agent不会充当结果的评判者。

这正是生成者—检查器分离原则在停止条件本身上的应用。

> /loop 30m /goal test/auth 中的所有测试通过，且 lint 检查无问题。
  扫描 src/auth 中的新故障，在 claude/auth-fixes 中提出修复方案，
  当目标条件满足时打开草稿 PR。


 ▲ Claude
  CronCreate(*/30 * * * * : 认证质量循环)
  停止条件：测试通过 + lint 检查无问题（由检查器验证）
✓ 已调度。即使中间阶段完成，也会继续运行，
  直到独立检查器确认 /goal 条件已满足。

一旦运行超过一个agent，文件就会开始产生冲突。两个agent写入同一个文件，与两名工程师在未沟通的情况下提交到同一行代码，是同一个问题。

Git 工作树（worktree）可以解决这个问题。它是一个独立的工作目录，在自己的分支上运行，但共享同一个仓库的历史记录，因此一个agent的修改在物理上不会影响另一个agent的检出。

两款工具的实现方式：

Codex：内置工作树支持——多个线程可同时访问同一个仓库，彼此互不干扰。

Claude Code：直接暴露git worktree，提供--worktree标志用于在独立检出中打开会话，并为子agent提供isolation: worktree配置，确保每个子agent获得独立的新鲜检出环境，并在完成后自动清理。

工作树消除了机械层面的冲突，但你仍然是瓶颈所在。你的审查吞吐量决定了你实际上能并行运行多少个agent，而不是工具本身。

07. 技能包（Skill）：项目知识只写一次，每次运行均可读取 Skills: write project knowledge once. Read on every run

Skill 是一种技能包，用于避免你在每次会话中重复向agent解释相同的项目上下文。两款工具采用相同格式：一个包含SKILL.md的文件夹，其中保存指令和元数据，并可包含脚本、参考资料和资源文件。

对循环来说，这一点尤为重要：没有 Skill，循环每个周期都要从零重新推导整个项目上下文；有了 Skill，项目意图和约定可以持续积累并复用。那些约定、构建步骤、"我们不这样做是因为那次事故"的经验，写入对话之外的持久文件一次，之后每次运行都读取。

name: ci-triage
description: 按根因对 CI 故障进行分类（env、flake、真实缺陷、
  依赖项、基础设施），为简单问题起草修复方案，其余问题升级处理。
  在工作流运行失败时或晨间分诊循环中触发。
---

 # CI 分诊技能

 ## 分类规则
- env：缺少密钥、环境变量错误、基础设施未预置。# 人工处理
- flake：不修改代码重试后通过。# 重试一次，然后建档
- bug：与最近提交相关的确定性故障。# 起草修复
- dependency：与版本升级相关的故障。# 起草回滚
- infra：超时、OOM、Runner 问题。# 升级处理

 ## 修复模式
- 认证测试 → 优先检查 src/auth/middleware
- 数据库测试 → 确认迁移已在 CI 环境中应用
- 端到端测试 → 对照最新 UI 快照检查选择器

 ## 禁止操作
- 禁止禁用失败测试——必须始终建档并升级处理
- 禁止在未经人工审批的情况下修改 CI 配置
- 禁止操作 src/payments/ 或 src/billing/（详见 claude/permissions.md）

 ## 状态
每次运行后更新 STATE.md：已检查的文件路径、分类结果、
已创建的 PR、已升级的问题。

只能访问文件系统的循环是一个极小的循环。连接器基于模型上下文协议（MCP）构建，能让agent读取问题追踪系统、查询数据库、调用预发布环境 API，或在 Slack 中发送消息。

Codex 和 Claude Code 均支持 MCP，因此为一款工具编写的连接器通常在另一款中同样可用。

这是"agent说：这是修复方案"与"循环自动创建 PR、关联 Linear 工单，并在 CI 变绿后通知频道"之间的区别。连接器让循环能够在你的真实环境中执行操作，而不仅仅是告诉你：如果它有权限，会怎么做。

对循环工作回报最快的连接器，按优先级排序：

• •GitHub：读取仓库、创建分支、创建 PR、在 Issue 上评论、响应 Webhook 事件。任何代码循环的第一天最大收益来源。

• •Linear 或 Jira：随循环进展更新工单、将 PR 关联回 Issue、在验证通过时自动关闭条目。

• •Slack：发布分诊结果，在问题升级处理时通知相关人员，在早晨汇总夜间运行摘要。

• •Sentry / 你的错误追踪系统：让循环调查实时告警，并为高频问题起草修复方案。

循环中最有价值的结构性设计，是将负责编写代码的agent与负责检查结果的agent分离开来。

Osmani 的表述精准到位：编写代码的模型在批改自己的作业时"太过宽松"。一个拥有不同指令、有时使用不同模型的第二个agent，能够捕捉到第一个agent在自我论证中合理化掉的问题。

这其实就是 Anthropic 2024 年 12 月工程文章中的"评估器—优化器模式"，只是换了一个新名称。一个模型生成，另一个批评，如此循环。这套词汇在 2026 年广泛流传，但在十八个月前就已经有文献记录。

两款工具的实现方式：

Codex：仅在你明确要求时生成子agent，并行运行，然后将结果汇总为一个答案。你可以在.codex/agents/目录中将agent定义为 TOML 文件——包含名称、描述、指令，以及可选的模型和推理强度配置。

你的安全审查agent可以使用高推理强度的强力模型，而探索agent则可以是一个权限只读、响应快速的轻量agent。

Claude Code：通过.claude/agents/中的子agent和agent团队实现相同的模式，agent之间可传递工作。常见分工：一个agent负责探索，一个agent负责实现，一个agent负责对照规格文档进行验证。

在循环中，这一点尤为重要：循环在无人值守的情况下运行，因此一个你真正信任的验证器是你能够放心离开的唯一理由。

子agent会消耗更多token，因为每个子agent都有自己的模型调用和工具调用，只在值得获取第二意见的地方使用它们。

第三部分：要么正确构建，要么不要构建 Build It Right or Don’t Build It 10. 状态文件：agent会遗忘，文件不会 The state file. The agent forgets. The file does not

这是那种听起来过于简单、实际上却是每个可用循环核心支撑的组件。一个 Markdown 文件、一个 Linear 看板、一段 JSON 状态，任何存在于单次对话之外、记录已完成内容和下一步任务的东西都可以。

为什么这很重要：agent默认的记忆是短暂的。它们在本次会话中学到的内容，明天就会消失，除非你将其写下来。

Osmani 的原则：agent会遗忘，仓库不会。没有持久状态的循环每次运行都从头开始；有了状态文件，循环可以从上次中断处继续。

# 循环状态 · ci-triage

 ## 上次运行
2026-06-09 03:30 UTC · 已分类 7 个故障，起草 3 个修复，升级 4 个问题

 ## 进行中
- claude/fix-auth-token-refresh — 本地测试通过，等待 CI
- claude/fix-flaky-payment-webhook — 已应用重试模式，正在监控

 ## 今日已完成
- claude/bump-axios-1.7.4 → 已合并（CI 正常，依赖项循环已验证）
- claude/lint-fix-pass-june-9 → 已合并

 ## 已升级至人工处理
- src/billing/refund.ts — 测试以 3 种方式失败，根因不明
- ci/staging-runner — 基础设施超时，非代码问题

 ## 经验记录（写在这里，而非聊天记录中）
- 2026-06-08：PowerShell 在此 Windows Runner 上遭遇 TLS 1.2 问题。请使用 bash。
- 2026-06-07：tests/e2e/checkout 需要环境中存在 Stripe Webhook 密钥。缺失时跳过。

 ## 自上次人工审查以来已满足的停止条件
- /goal "所有测试通过 + lint 检查无问题"已于 02:14 UTC 在提交 3a7b8c1 上达成

状态文件的两种存储模式：

仓库内的 Markdown 文件：STATE.md位于根目录或.claude/目录下。版本受控，结构简单，可通过代码差异读取。适合个人或小型团队使用。

外部系统（Linear、GitHub Issues、数据库）：跨仓库持久存在，可查询，支持全团队可见性。适合多人需要了解循环运行状态的生产级循环。

对于存在目标偏移风险的长期运行循环，建议将状态文件与一份常设的高层规范文件（VISION.md或AGENTS.md）配合使用，让agent在每次运行时重新读取。状态文件告诉agent当前位置，规范文件告诉agent目标方向。

11. 最小可行循环 The minimum viable loop

如果你通过了第 02 步的四条件测试，在尝试任何复杂构建之前，先构建最小的可用循环。四个部分即可，无需构建多agent蜂群。

四个部分，用简明语言描述如下：

• •一个自动化。一个按周期启动、在明确条件下停止的调度运行。在 Claude Code 中使用/loop，或在 Codex 中使用自动化功能。当你希望循环持续运行直到某个条件满足时，配合/goal使用。

• •一个 Skill。一个SKILL.md文件，存储agent否则需要每次运行从零重新推导的项目上下文。

• •一个状态文件。一个 Markdown 文件或 Linear 看板，记录已完成内容和下一步任务。明天的运行将从上次中断处继续，而不是重新开始。

• •一个质量门禁。能够自动拒绝不合格工作的测试、类型检查或构建流程。这是决定循环是在创造价值还是只是在烧钱的关键。

顺序很重要：先让一次手动运行变得可靠，再将其转化为 Skill，再将其包装为循环，最后进行调度。跳过这些步骤，你就是在为一个没有人真正理解的系统付钱。

真正重要的指标是每次被接受变更的成本，而不是消耗的token数、尝试的任务数或调度的循环数。如果被接受的变更比例低于 50%，说明你仍在承担大量本应由循环减少的审查工作，此时循环是在亏损。

12. Ralph Wiggum 循环：悄然失效的循环 The Ralph Wiggum loop. Loops that fail quietly

工程师 Geoffrey Huntley 记录并命名了这种失效模式。一个本应仅在完成时输出完成标记的agent提前输出了该标记，导致循环在任务尚未完成时便退出。没有硬性质量门禁，循环会悄然失效并持续消耗资源。

Ralph Wiggum 循环的成因：

• •没有真实验证器。只有一个被要求"审查"的第二agent，没有客观信号。两个乐观主义者在互相认同。

• •停止条件是软性的。"完成"由agent自行判断，而非由测试、构建或类型检查来定义。

• •没有硬性停止条件。循环持续运行，直到外部因素终止它（速率限制，或你注意到账单），而不是直到成功被验证。

修复方案是第 11 步中的质量门禁。一种能够对工作作出客观判定的机制：能够通过或失败的测试，能够编译或无法编译的构建，返回零或非零值的代码检查工具。不是一个有"意见"的验证器。

其他值得了解的已测量失效模式：

• •长会话中的目标偏移。每次摘要步骤都有信息损耗；到第 47 轮交互时，"不要执行 X"这类约束可能已经消失。缓解措施：在每次运行时重新读取常设的VISION.md或AGENTS.md。

• •自我优待偏差。编写代码的agent在批改自己的作业时过于宽松。缓解措施：使用一个独立的验证器子agent，且不暴露于生成者的推理过程。

• •agent惰性。循环在部分完成时声明"已经足够好了"。缓解措施：使用/goal并配合由未参与生成过程的独立模型实例检查的客观停止条件。

这是一种随着循环能力增强而变得更加突出，而不是减弱的失效模式。两种命名风险，均来自 Osmani 的文章：

理解债务。循环交付代码的速度越快，仓库中的实际内容与你所能理解的内容之间的差距就越大。真正让你付出代价的并不是token账单，而是你不得不调试一个团队中没有人读过的系统的那一天。

认知放弃。你会受到一种引力的影响，停止形成判断，直接接受循环返回的一切。以判断力来设计循环，它就是加速器；以逃避思考来设计循环，它就是加速崩溃的引信。同一个动作，截然相反的结果。

缓解措施不在技术层面：

审阅代码差异。如果你不读循环交付的内容，你就是在让理解债务按复利累积。

抽查质量门禁。随机抽取几个循环创建的 PR，验证批准它们的测试确实能够捕获你真正关心的失效模式。质量门禁会随时间退化。

阻止循环介入架构工作。将其限制在小规模、可由机器检查的变更范围内。一旦你让它触及需要主观判断的工作，理解债务就会加速积累。

与队友结对设计循环。在设计循环时多一双眼睛，能够发现那些否则会被循环永久利用的盲点。

14. 安全税：无人值守的循环就是无人值守的攻击面 The security tax. An unattended loop is an unattended attack surface

无人值守运行的循环，同时也是无人值守暴露的攻击面。

你的循环必须防御的威胁模型：

生成代码未经审查即合并或发布。循环创建 PR 的速度超过人工审阅速度。如果没有包含安全检查（SAST、依赖项审计、密钥扫描）的质量门禁，不安全的代码会自动合并。

技能包作为注入向量。自动安装技能包的循环，会继承其描述中隐藏的所有提示注入风险。在安装之前审计技能包来源。

日志中的凭据。长期运行循环的调试日志可能把凭据和其他敏感信息散布到你未监控的日志中。在生产级循环中禁用详细日志；对确实需要记录的内容进行脱敏处理。

权限范围蔓延。以只读权限测试的循环被"临时"添加了一个写权限以方便操作，然后再也没有重新审计过。每 30 天重新审计一次权限。

将循环变成成本黑洞的错误

• •未经四条件测试就构建循环。第 02 步的存在有其理由。大多数开发者至少有一个条件不满足。

• •没有客观质量门禁。一个被要求"审查"却没有测试、类型检查或构建支撑的第二agent，只不过是第二个乐观主义者。

• •同一个agent既负责编写又负责验证。自我优待偏差——生成者批改自己的作业，结果永远是"A+"。

• •没有状态文件。明天的运行会从零重新开始，而不是从上次中断处继续。

• •停止条件模糊。"看起来好了就算完成"永远不成立。请使用测试通过、类型检查通过或构建成功作为标准。

• •没有token预算上限。循环会反复读取上下文并重试。没有上限，复杂或激进的循环可能消耗预期 5–10 倍的token。

• •在个人版套餐上运行重型验证循环。最终会受到token费用或速率限制之一的约束。

• •自动安装社区技能包。在 17,022 个经审计的技能中，有 520 个存在凭据泄露问题。在安装前请阅读源码。

• •将循环用于需要主观判断的工作。架构设计、认证、支付、模糊的产品决策——将循环限制在 lint-and-fix 这类机械性任务上，而不是策略性决策。

• •不审阅代码差异。理解债务按复利累积。你不得不调试一个没有人读过的系统那一天的代价，远超所有token成本。

过去两年，与编码agent协作的杠杆点在于提示词。更好的提示词、更好的上下文、更好的单次输出。

这个阶段正在结束。agent已经足够强大，下一个杠杆点在更高一层：那个决定agent处理什么任务、何时处理、使用何种质量门禁、以及在运行之间保留哪些状态的系统。

但这个故事的诚实版本，并不是说所有人都应该立刻去构建循环。大多数开发者目前还不需要，不是在任务重复发生、验证实现自动化、预算能够承受消耗、agent拥有完整工具链之前。

缺少任何一个条件，循环的代价便会超过其收益。

如果你通过了测试，就小步构建。一个自动化，一个 Skill，一个状态文件，一个质量门禁。先让手动运行变得可靠，再将其转化为 Skill，再包装为循环，最后进行调度。顺序很重要。跳过步骤，你就是在为一个没有人真正理解的系统付钱。

Cherny 的观点并不是说工作变得更容易了。而是说杠杆点移动了。构建循环，同时保持工程师的判断力。

循环工程的核心，不是用自动化替代思考，而是把工程师的判断力提升到更高的抽象层次。

过去两年，提示词质量是与 AI 协作的杠杆所在；在 2026 年，这个杠杆已经上移。不是移到了更聪明的提示词，而是移到了系统设计本身：循环的触发机制、验证逻辑、停止条件，以及在运行之间持久存在的状态。

但本文最值得铭记的，或许恰恰是它的克制。四个条件缺一不可：任务重复发生、验证可以自动化、预算能够承受消耗、agent拥有完整的工具链。任何一个条件缺失，循环都会成为成本黑洞而非生产力杠杆。

理解债务与认知放弃，是随着循环能力增强而愈演愈烈的隐患。代码交付速度越快，"仓库中有什么"与"团队理解什么"之间的鸿沟就越深；一旦停止对差异的审阅与判断，工程师的核心价值也随之流失。

循环是工具，而判断力才是工程师不可让渡的资产。

Cherny 的结论简洁而深刻：构建循环，同时保持工程师的判断力。在自动化的时代，这或许才是最难守住、也最值得守住的东西。

Loop Engineering 代表 AI 编码工程的全新阶段，协作杠杆从单次提示词，上升到自主运行系统的顶层设计。

但循环不是万能提效工具，四大前置条件、客观质量门禁、持久化状态文件、硬性 Token 预算上限缺一不可，忽视任意一点都会形成成本黑洞、隐性失效循环与安全攻击面。

文中完整梳理的 14 步标准化路线图、五大基础构件、最小可用循环搭建规范、失效模式与安全防控方案，覆盖 Codex 与 Claude Code 双主流工具落地逻辑，区分团队与个人开发者适配场景，帮大家理性判断是否需要落地循环工程，避免盲目跟风踩坑。

原文：https://x.com/0xCodez/article/2064374643729773029

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。

全文完

王吉伟频道图书《一本书讲透Agentic AI》已出版，完整构建Agentic AI在企业应用中的全景式知识体系，内容跨越 “基础认知-技术原理-业务应用-组织战略-实操指南” 五大板块，为读者提供从认知共识、技术解构、业务对接到组织变革的端到端路线图，欢迎大家关注。

【赠书福利进行中】

感谢大家的长期关注与支持。欢迎小伙伴们在文末留言与转发，王吉伟频道会随机选取读者，《一本书讲透Agentic AI》包邮到家。

【 文末福利1 】：后台发消息研报2026，获取15篇 2026年 AI Agent研报 。

【文末福利2】： 后台发消息Workflow，获取 Agentic Workflow 相关25篇论文。

【文末福利3】：后 台发消息agentic，获取Agentic AI相关资源 。

【文末福利4】：后台发消息RPA Agent，获取 相关论文和研报。

1、

2、

3、

4、

5、

6、

7、

8、

8、

10、