有人说要解决loop AI的问题，就用更多loop

看到 yetone 分享自己的工作流让我感慨良多。我很久都没有用 loop 了，原因是我发现在无人监管的情况下 loop 会引入很多错误的决策、无效的功能、难以维护的代码和回归的异常。于是我还是回归了和 agent 手动审阅讨论的开发方式， 尽可能保持 human-in-the-loop。

没想到 yetone 的思路跟我完全相反——���然一个 loop 引入了问题，那就用更多的 loop 来解决它。我的用法保证了下限，但他的用法无限拔高了上限。唯一的问题就是比较废 token, 但当产品创造了价值，用更多的 token 其实是心甘情愿的事情。

这让 $200 plan 从未花光过的我不禁反思，或许这是 agent 时代必须掌握的一条高生产力道路。之前自己因为 agent 的缺陷而规避大量使用，眼光狭隘了，应该彻底接纳它，然后找到改进、解决问题之道。其实最近也已经慢慢进化到让 agent 自动分配工作的方式了，这也证明了认知是在实践中不断否定和更新的。

如果回想下 cursor 占主流的时期就会发现，彼时的思想相比现在又早一个代际，IDE 的界面代表的思维方式是人来决定代码的落库。这种情况下 token 使用量根本高不起来，我记得当时每天都用 cursor 几个小时却从未遇到额度报警。后来 claude code 的出现让我们从 IDE 转向到 ADE，而现在，正是从 ADE 到另一个更高层面工作方式的跨越中。

又想到 tokenmaxxing 这个词，出现几个月就已经过时了，仿佛是去年的事情。虽然现在看来有些好笑，但它的愿望是好的，想要让 AI 开发发挥最大化的效能，只不过没有正确的量化方式，是一种「大跃进」式的粗暴追求。而当我们真正把 agent 的效能提升起来，实现质量可控的自动化全天候开发，tokenmaxxing 只不过是个必然的附属结果。