夜雨聆风本期概念
“Loop Engineering”
从写提示词，转向设计能自己提示、执行、验证和停止的 AI 工作循环
QincAI
沁菜
想象你雇了一个手脚麻利但不懂业务的新人：一开始你一五一十交代任务（这叫提示词工程），后来你发现更高效的办法是给他一套规则、检查标准、权限范围，让他自己反复试、自己校验，直到把活儿干好。
把一次对话，升级成一个可控循环
循环工程，英文叫 Loop Engineering。它不是一个具体产品，也不是某个模型能力，而是一种设计能调用工具的 AI 助手（agent）工作流的方法。
这个概念最近被 Addy Osmani 系统化地推到台前：重点不是人类不断手动提示 AI，而是设计一个系统，让系统去提示 AI 助手、给它工具、接收结果、做验证，再决定要不要进入下一轮。OpenAI 在 Codex CLI 的工程解释里也展示了底层 AI 工作循环（agent loop），即助手反复请求工具并反馈结果的过程：模型请求工具调用，外部程序执行工具，把结果放回上下文，直到模型给出终止信号。再往外一层，就是 AI 助手工作环境设计（harness engineering）：人类设计环境、约束、反馈和验证，让 AI 助手在更可靠的轨道上工作。
可以用三层来记：提示词是一句指令；AI 助手工作环境（agent harness）是一次任务环境，包括文件、工具、权限、上下文和约束；循环是把任务反复交给 AI 助手，并用检查条件决定继续、重试、转交人类或停止的系统。
它和提示词工程的区别在于，提示词工程优化的是“这一次怎么说”；循环工程优化的是“如果这一次没完成，系统如何发现、如何修正、如何防止无限做下去”。它和普通的 AI 多步工作流程（agentic workflow）也不完全一样。多步工作流程可能只是 A 到 B 到 C 的流程，循环则强调观察结果后的再次进入：执行、反馈、验证、再执行，直到满足条件或触发停止条件。
核心单元不是一句提示词，而是一次可重复的任务循环。循环必须有输入、执行、观察、验证、决策和停止。适合被循环化的任务，通常有便宜、明确、机器可检查的完成条件。
AI 从助手，变成需要管理的执行系统
循环工程突然变热，不是因为大家发明了新词，而是工具栈真的变了。
Claude Code 有 /loop 和定时任务功能，可以重复运行提示、轮询状态或安排一次性任务；Codex CLI 把 AI 工作循环（agent loop） 拆给开发者看；Cursor、Claude Code、Codex 这类工具开始支持自动触发的小规则（hooks）、技能（skills）、子任务助手（sub-agents）、隔离开的代码工作区（worktrees）、把外部工具接给 AI 用的协议（MCP）等能力。AI 不再只是聊天窗口里的建议者，而是能进入项目环境、调用工具、修改文件、跑检查的执行者。
一旦 AI 能执行，问题就变了。以前你担心的是“提示词写得够不够好”；现在你还要担心“它会不会一直跑”“会不会改错地方”“会不会为了通过测试写出奇怪补丁”“这轮花了多少模型调用成本（token，即按文字量计费的单位）和外部 API 成本”“什么时候必须让人介入”。循环工程的重要性，就在于把这些风险显性化。
Blake Crosley 对这一类实践有个很有用的判断：验证便宜的地方，循环最容易赢。比如测试是否通过、JSON 字段是否完整、文档有没有缺标题、代码自动测试（CI）有没有红、网页状态码是否异常，这些都能低成本检查。反过来，如果任务成功与否要靠人类审美、产品判断或复杂商业语境，循环就容易把错误放大。
所以，循环工程不是“让 AI 全自动替你工作”的魔法，而是“把能自动验证的部分交给 AI 重复做，把不能自动验证的部分留给人类判断”。这也是它对普通用户有价值的地方：你不必先会写复杂代码，也可以开始用循环思维改造低风险、重复、可检查的工作。
真实可用场景一：代码自动测试修复。失败测试就是明确反馈，循环可以尝试修复、跑测试、再修复，达到次数上限就停。真实可用场景二：代码合并请求（PR）看护。自动关注评论、冲突、检查结果，能处理的小问题交给 AI，涉及产品取舍时提醒人。真实可用场景三：资料整理。定时读取新增文本，生成摘要，检查标题、来源、日期是否齐全。
先设计边界，再设计自动化
一个可靠的循环，不是“让 AI 一直干”，而是“让 AI 在被限定的轨道里反复尝试”。
最小循环可以拆成七件事：触发条件、任务输入、提示模板、工具权限、验证器、决策规则、停止条件。触发条件决定什么时候开始，比如手动点击、每天早上、代码自动测试失败、文件夹出现新文件。任务输入决定 AI 看什么。提示模板告诉它目标和限制。工具权限决定它能读、能写、能不能联网、能不能调用付费服务。验证器负责判断结果是否合格。决策规则决定下一步是重试、换策略、提交结果还是叫人。停止条件保证它不会无限循环。
验证条件越清楚，循环越安全。对代码任务，验证可以是测试通过、lint 通过、构建成功、改动文件范围符合预期。对内容任务，验证可以是字段完整、格式符合模板、来源和日期存在、摘要长度在范围内。对监控任务，验证可以是状态码、关键词、时间戳或异常数量。不要把“看起来不错”当成唯一验证条件，那会把人类判断伪装成自动化。
停止条件至少要有四类：次数上限、时间上限、成本上限、风险上限。比如最多尝试三轮；超过二十分钟停止；模型调用成本或外部 API 成本超过某个额度停止；需要删除文件、提交生产环境、修改账单配置、处理隐私数据时停止并请求确认。还有一种常见停止条件是“连续两轮没有新进展”，这能避免 AI 在同一个错误里打转。
成本边界也要提前写出来。循环的成本不只是模型调用成本，还包括工具调用、搜索或抓取费用、代码自动测试机器时间、人工复核时间，以及出错后的恢复成本。对小白用户来说，最稳的开始方式是只读、不删、不覆盖、只写到一个固定输出文件；先手动跑，再半自动，最后才考虑定时自动跑。
先选低风险任务：资料摘要、日报整理、文档检查、测试项目里的代码修复。再写清成功条件：什么结果算完成，什么结果算失败，什么情况必须问人。权限从小开始：只读优先，写入固定位置，禁止删除和批量覆盖。
真正要避开的，是边界被说没了
概念越新，越要先看它在哪些地方容易被误读或滥用。
· 循环工程不是把提示词写长一点。
· 能循环不等于该全自动，尤其不等于能自动做产品决策。
· 没有验证条件的循环，本质上是放大不确定性。
· 停止条件不是保守，而是自动化系统的刹车。
· 预算不只算模型调用成本，还要算工具费、复核时间和出错成本。
我对 Loop Engineering 的判断是：它会成为 AI 编程和自动化里的基础思维，但不会替代人的判断。它最像从“雇一个聪明实习生”升级到“设计一条带质检的流水线”。你可以让 AI 在流水线上反复处理明确任务，但你必须定义质检标准、返工次数、报废条件和主管签字点。现在最值得普通用户学习的，不是复杂术语，而是三个问题：结果能不能便宜地检查？失败会不会造成不可恢复损失？跑到什么时候必须停？这三个问题答不清，就先不要 loop。
参考脉络来自 Addy Osmani 对 Loop Engineering 的系统化命名，OpenAI 对 Codex AI 工作循环（agent loop） 与 AI 工作环境设计（harness engineering） 的工程解释，Claude Code 对 /loop 和定时任务的官方说明，以及 Blake Crosley 关于“验证成本低的地方循环更有效”的边界判断。Firecrawl 的实践解释也有助于区分 prompt engineering、AI 多步工作流程（agentic 工作流程） 与 loop engineering。
[1]Loop Engineering
[2]Loop Engineering: Loops Win Where Verification Is Cheap
[3]Should You Stop Prompting Agents and Start Designing Loops
[4]Run prompts on a schedule - Claude Code Docs
[5]Unrolling the Codex agent loop
[6]Harness engineering: leveraging Codex in an agent-first world
