本文基于 𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰（@techwith_ram）的《Loop Engineering Isn't What You Think》整理，英文原文和中文译文链接见文末。
最近，AI 编码圈流行着一句话：别再给 AI 写提示词了，去设计替你写提示词的循环（Loop）。
Claude Code 背后的工程师 Boris Cherny 曾表示，他现在很少直接向模型下指令，而是让一套循环系统替自己完成这件事；OpenClaw 的创建者 Peter Steinberger 也表达过类似观点：真正重要的工作，不再是 prompt，而是构建会自动 prompt AI 的系统。
这听起来像是未来已经到来：你写好需求文档，按下启动键，AI 便会自动生成代码、检查结果、修复问题，直到任务完成。
但现实远没有宣传中那么简单。
事实上，你一直都在运行一个 loop。只是过去，这个循环里有人——你自己。
打开 Cursor、Claude Code 或 Codex，输入需求；审查输出；指出问题；调整方向；再生成下一版。生成、审查、修正、重复，这套流程被称为 human-in-the-loop。AI 负责执行，而人负责判断、纠偏和掌舵。
如今最热门的趋势，是试图把人从循环中拿掉。开发者提供一份 PRD 或 spec，随后 AI 自己生成结果、检查输出、判断是否完成，再继续下一轮迭代。各种 /goal、/loop 命令，本质上都是同一个想法：目标已经给出，在达到目标之前不要停下来。
问题在于，自动循环并不等于自动正确。
任何需求文档都无法覆盖所有细节。当 AI 连续替你做出几十、上百个决策时，它必然会填补那些未被定义的空白。而这些空白，恰恰藏着产品的品味、用户体验与真正的业务判断。最终交付的结果，有时令人惊艳，有时却像拉老虎机一样不可预测。
更现实的问题是：loop 并不便宜。
每一次循环都会消耗 token。十轮、二十轮甚至五十轮迭代，都会携带上下文不断累积成本。对于预算充足的团队，这或许不是问题；但对于大多数开发者而言，一个开放式 loop 很可能在不知不觉中烧光额度。
因此，真正的问题不是“要不要用 loop”，而是“什么时候该用”。
一个简单原则是：成功标准越客观，loop 越有效。
测试是否通过？代码审查是否达到 4 分以上？输出是否符合固定模板？这些问题都有明确答案，AI 可以持续优化，直到满足条件。
但如果问题变成：“这个产品感觉对吗？”“用户真的会喜欢它吗？”“这是不是一个好创意？”答案往往依赖品味、经验与洞察，而这些恰恰是规范文档无法完全描述的东西。
因此，loop 最适合那些枯燥却标准明确的工作：自动代码审查、批量迁移、执行测试、修复 lint、生成模板化内容。它们拥有可衡量的目标，也应该拥有明确的退出条件。
至于那些需要愿景与判断的部分，方向盘依然应该握在人类手中。
AI 可以替你完成重复劳动，甚至复制已有的方法论；但它很难定义什么才是真正值得追求的结果。
所以，不要试图造一个巨大的循环，让它替你创造一家伟大的公司。更好的做法，是围绕那些二元、客观、可验证的任务，构建一个个小而可靠的 loop，把时间留给真正需要人类品味与判断的地方。
这不是在对抗趋势，而是在理解趋势：自动化值得拥抱，但别太早把自己请出循环。
原文：https://x.com/techwith_ram/status/2064925285003542820 ｜ 译文：https://kn.dingzhihao.org/view/raw/agents-series/loop-engineering-isnt-what-you-think