一个价值 5000 元的 AI coding 思路：拉夫循环（Ralph Loop）

这是个大力出奇迹的方法。Ralph Loop 是 Geoffrey Huntley 提出来的，本质上就是一个极其朴素、甚至有点“土”的思路。

他的思想非常简单，是所有学过或者没学过编程的人都知道的东西：循环（loop）。不停地让 AI 改，改到 ok 为止。Ralph Loop 的核心不是“一次写对”，而是失败 → 复盘 → 再来一次 → 直到满足条件，只不过这件事不是人来干，是 AI 自己在后台循环干。

很多人一听会觉得这有什么新鲜的，但真正值钱的点恰恰在于：它把人从执行链路里拿掉了。

大多数人用 AI 写代码，其实用法都差不多：你提需求，AI 给一版，你看一眼不行，补一句，再改，又出新问题，再补一句。问题不在 AI 不聪明，而在于人被困在了“来回沟通”的循环里，既当产品经理，又当 QA，又当监工。

Ralph Loop 做的事情只有一件：你只说一次要什么，以及什么叫完成，剩下的事情交给循环。AI 会自己失败、自己重来，直到满足你定义的完成条件，或者撞到你设定的上限。

这个方法为什么值钱？因为它解决的不是“写得快一点”的效率问题，而是认知问题。很多人以为 AI coding 的上限就是帮你敲代码，但真正的分水岭在于：你是不是还在陪 AI 改代码。一旦你还在陪跑，本质上就没脱离人肉迭代。

当然，Ralph Loop 也不是拿来就能用好的。我踩过最大的坑只有一个：**什么任务都往 loop 里扔。**结果就是 token 像开闸放水一样烧，信用卡账单直接给你上强度（别问我怎么知道的）。后来我才意识到，这个方法只适合一类非常明确的任务。

第一类，是有明确完成条件的任务。比如所有测试通过、覆盖率达到某个数、每个导出函数都有注释、某个 bug 有回归测试。一句话总结：能被机器判断“完成 or 没完成”的任务。如果完成标准需要你“看一眼感觉”，那就别用。

第二类，是偏机械、偏体力的编程工作。比如大规模重构、升级依赖或框架、批量补文档和注释、修一堆同类型的 lint 或 test 问题。这些事情本身就不需要创造力，只是烦、重复、耗时间，交给循环反而更稳定。

第三类，是可以放着不管的任务。Ralph Loop 非常适合“你不在场”的时候跑，比如下班前丢一个任务、睡觉前启动、周五晚上跑，周一回来验收。如果你本来就打算一直盯着，那还不如手动改。

同样重要的是什么时候千万别用：架构设计、技术选型、安全相关逻辑、模糊需求（比如“优化一下”“重构得优雅点”）。一句话总结：凡是需要判断力的地方，都不适合循环。Loop 只会放大确定性，不会帮你补思考。

至于怎么避免 token 烧穿，这是很多人关心但很少说清楚的点。我现在基本遵守几个原则：永远设上限，不要无限 loop；先跑 1 次确认方向对，再放大循环；大任务拆小，不要一口气 all in；如果 5–10 次都在犯同一个错，说明任务描述有问题，而不是 AI 的问题。Loop 跑不出来，99% 是完成标准写得不对。

说句实话，Ralph Loop 本身并不复杂，甚至一点都不高级。它真正值钱的地方不在技术，而在于它逼你把“什么叫完成”想清楚。而这件事，本来就应该是人做的。一旦你把这一步想清楚，AI 才真的能变成一个可以放手的执行者，否则不管你用什么模型、什么插件，本质上都还是在陪跑。