最近看到一个概念突然火了起来Loop Engineering循环工程。名字听起来很技术但核心意思一句话就能说清楚——别再手把手地给 AI 下指令了设计一个能自己跑的循环让 AI 自己发现任务、交付结果、验证质量、记录过程、决定下一步。我的第一反应不是又造了个新词而是愣了一下。因为我自己这半年干的事不知不觉已经在走这条路了。半年前我还在纠结怎么写更好的 Prompt。那时候的思路是把指令写得越精确AI 的输出质量越高。后来发现不对。就算 Prompt 写得再好每次都得人去触发、去检查、去决定要不要重来。AI 是强了但它像一个需要你反复按开关的机器——你不按它就不动。再后来我把工作流拆成了两半一个 Agent 负责干活一个 Agent 负责检查。干活的不能自己说好了检查的不能动手改。两个互相制衡人只在最后拍板。当时我以为自己在做自动化。现在回头看这个做法有个名字——双 Agent 制衡架构是循环工程的核心零件之一。循环工程的标准流程是五步发现、交付、验证、记录、决策。听起来像项目管理的方法论确实。但区别在于这五步是 AI 自己跑的不是人在驱动。Claude Code 最近上了两个命令/goal和/loop。前者是进度驱动——你给一个可验证的终点它自己跑到终点为止后者是时间驱动——每隔一段固定时间轮询一次看看有没有新情况需要处理。这两个东西看着简单但边界很清晰。/goal适合有明确终点的任务比如把这个 bug 修好/loop适合持续监控的场景比如每半小时检查一次采集状态。混用就会出问题——拿时间驱动去跑一个需要明确终点的事要么提前停了要么白跑空转。我自己踩过这个坑。之前用定时任务去跑一个修完所有 lint 报错的活结果每次触发都从头扫一遍跑了十几轮还没修完。后来改成目标驱动一轮就搞定了。但循环工程不是银弹。它有四个隐性成本刚开始你根本感觉不到。第一个叫验证债。AI 自己跑、自己验但验的标准是你定的。如果标准本身有问题AI 会在错误的标准上反复通过债越积越深。等你发现的时候已经攒了一堆需要人工回溯的问题。第二个是代码理解脱节。AI 跑循环改代码改得越多你离代码越远。表面上一切正常但你已经看不懂它改了什么、为什么这么改。一旦出问题人工介入的成本比从头写还高。第三个是 Token 消耗失控。循环一旦跑起来每轮都在烧钱。如果没设好终止条件和频率一个跑飞的循环一晚上能烧掉你一周的预算。第四个最隐蔽人逐步丧失独立判断。AI 跑得越顺你越依赖它的结果。慢慢地你不再自己想问题只看 AI 给的答案。不是 AI 替代了你是你自己把判断力交出去了。所以我现在给自己定了一条规矩循环工程只用在那些我自己已经深度掌握的工作上。什么意思比如采集健康检查、数据格式转换、定时提醒——这些我闭着眼都知道正确结果长什么样的活交给循环跑没问题。AI 快、不知疲倦而且这些事的验证标准明确不存在模糊地带。但如果是一件我本身就不太懂的事——比如一个新方向的竞品分析、一个没做过的产品功能设计——绝不上循环。因为我不具备判断 AI 输出好坏的能力循环跑出来的东西我无法验收等于把方向盘彻底交出去了。工具的价值取决于使用者的初衷。同一个循环工程在懂行的人手里是提效利器在不具备判断力的人手里就是一个加速犯错的引擎。有个反方观点我觉得值得认真对待循环工程是不是只是定时脚本 大模型 Agent的组合换了个名字某种程度上是的。技术上没有本质突破。定时脚本跑了几十年了大模型也用了两年了Agent 编排也不是新东西。但概念的力量不在于技术突破在于共识凝聚。Addy Osmani 在 6 月 7 日那篇博客里把这套实践命名为 Loop Engineering 之前大家各干各的没有一个统一框架来讨论AI 自主循环该怎么做、边界在哪、风险是什么。花叔写的 32 页橙皮书Peter Steinberger 那条 830 万浏览的推文——这些不是在造技术是在造共识。让散落在不同团队的经验变成可以复用的方法论。真正的行业共识往往不是刻意造概念的结果而是众多从业者实践中遇到共同需求后自然形成的。回到我自己的工作流。现在我的状态是能用循环的尽量用但每次跑之前问自己三个问题——一这件事我自己会不会做如果不会不交给循环。二验证标准够不够硬如果需要感觉对了这种模糊判断不交给循环。三跑飞了能不能兜住如果一旦失控会造成不可逆的后果不交给循环。三个问题过完真正适合跑循环的其实不多。但那些适合的效率提升是实实在在的。以前每天花两小时检查采集状态、处理异常、手动重跑失败任务。现在设定好循环和告警大部分时候只需要看一眼通知知道正常还是需要介入。省下来的时间干什么想那些循环替不了的事——下一步写什么、方向对不对、用户到底要什么。AI 越能自己跑循环人的时间反而越该花在循环跑不了的地方。这才是分工。深入交流Any1tan