一条推文引发的讨论 2026 年 6 月初，OpenClaw 创始人 Peter Steinberger 在社交平台上写了一句话，大意是：别再手动给 AI 编码代理写提示词了，应该去设计一个能替你写提示词的系统。几天之内，Claude Code 的负责人 Boris Cherny 在公开场合跟上，他现在的日常工作就是写循环（Loop），让循环去调度 Claude，自己不再逐条下达指令。Google Cloud 工程总监 Addy Osmani 随后给这套做法做了系统性的拆解，并赋予它一个正式的名字：Loop Engineering，即循环工程。 三个人，三家公司，同一周，同一个结论。这当然不是巧合，而是标志着 AI 编程工具在2026年新阶段的到来。 什么是循环工程 循环工程是一种面向 AI Agent 的工作流设计方法。它的目标搭建一个完整的执行系统，这个系统能够自动发现任务、分配给 AI 代理去执行、检查产出质量、记录进度，并决定下一步是继续、重试还是停止。整个过程可以在无人值守的状态下持续运转，直到满足预设的退出条件，我愿称之为 AI 界的永动机。 打个比方，如果提示词工程（Prompt Engineering）是在棋盘上走好每一步棋，那循环工程就是在设计下棋的规则和裁判机制，让 AI 按照规则自己完成一整盘棋。 尽管 Loop Engineering 目前主要应用在软件开发领域，但它的底层逻辑并不局限于写代码。任何需要反复执行、反复判断的流程，从运维巡检、内容生产、客服分流、到数据清洗，都可以用同样的思路来构建。只不过编程领域的工具链最先成熟，实践和讨论也最密集。 从提示词工程到循环工程，经历了什么 回顾 AI 辅助编程的发展路径，可以看到三个阶段，每个阶段解决的问题不同，工程师扮演的角色也在变化。 第一阶段：提示词工程（Prompt Engineering） 这是最早被广泛讨论的 AI 协作方式。工程师通过精心设计提示词，设定角色、给出示例、加入链式思考引导，来让模型产出更准确的结果。但是这个方式的缺点是措辞方式会显著影响模型输出。 因为它有一个结构性的问题，提示词是手工制品，高度依赖特定模型版本和上下文长度。模型一更新，或者输入稍有变化，之前调好的提示词就可能悄悄失效。很多团队甚至为提示词写了回归测试，像测试函数一样测试措辞，然后看着它们在每次模型升级后批量过期。这种现象被称为 Prompt Drift（提示词漂移），这可不是偶发情况，而是把确定性期望绑定在概率系统上的必然结果。 第二阶段：上下文工程（Context Engineering） 业界很快意识到，与其在措辞上反复打磨，不如把精力放在模型的输入数据上。RAG 管线、向量数据库、嵌入策略陆续出现，上下文窗口也从几千 Token 扩展到百万级别。工程师的工作重心也从「怎么说」变成了「让模型看到什么」。 上下文工程解决了信息供给问题，但也不是完美的，一个被充分喂养了上下文的模型，如果第一次就答错了，它不会自己发现，也不会主动验证。整个管线里没有任何机制推动它做二次检查。 第三阶段：循环工程（Loop Engineering） 循环工程补上的正是这个缺点。它不再试图优化单次输入，而是围绕模型搭建一个闭环系统：模型执行操作 → 确定性工具（编译器、测试框架、Lint 工具）评估结果 → 评估反馈回传给模型 → 模型修正后再次执行 → 如此反复，直到通过所有预设的验证门禁。 工程师的角色也随之改变。不再是每一轮对话的参与者，而是这个闭环系统的设计者。他们要定义什么算完成、用什么来验证、失败后怎么处理、何时需要人工介入。 三个阶段之间并非替代关系。好的提示词和充足的上下文依然有用，但它们已经从主要工程挑战变成了循环内部的子模块。真正决定产出质量的，是循环本身的设计。 一个可用的循环需要哪些组件 根据 Addy Osmani 的拆解，一个能投入实际使用的循环需要五个结构性组件，加上一个贯穿始终的记忆层。 1. 自动化触发（Automations） 自动化触发是让一个循环区别于一次性脚本的关键。它可以是定时任务（比如每 30 分钟扫描一次依赖漏洞）、事件钩子（比如PR 被合并后自动启动检查）或者持续监听（每小时检查一次 Bug 反馈区）。 在 Claude Code 中，可以通过 /loop 设置定时巡检，也可以通过 GitHub Actions 实现在关闭终端后继续运行。Codex 则提供了一个 Automations 面板，可以直接配置项目、提示词、执行频率和运行环境，结果自动归集到分类收件箱中。 没有触发机制的循环不是循环，只是一个需要手动启动的脚本。 2. 工作树隔离（Worktrees） 当多个 AI 代理同时处理同一个代码仓库时，文件冲突是第一个会爆发的问题。
留言框-
