prompt 的热度还没消退，graph 又悄然来袭。AI 编程圈的造词速度，实在让人应接不暇。

龙虾之父 Peter Steinberger 再次发声，正是那位写出 OpenClaw 的技术大牛。

他那句“别再把时间花在逐条提示 Agent 上，去设计能驱动 Agent 的循环体系”，刚刚获得了 840 万关注。

说实话，第一反应是疲惫。

prompt engineering 还没完全掌握，context engineering、harness engineering、loop engineering 又接踵而至，现在又冒出个 graph。AI 编程圈造新词的速度，比我背单词的效率快得多，实在令人无奈。

你可能也想吐槽，这不就是工作流引擎换个马甲吗？二十年前就有了。非常理解这种第一反应，难题确实都是老问题——拆解任务、表达依赖关系、失败重试，软件工程领域已经争论了三十年。

但翻完这场上百条的讨论串之后，我决定换个角度看待。

我的判断是：这些词说的根本不是五件事，而是一件事的五次迁移。迁移的是什么？是“下一步该干什么”这个判断权。每迁移一次，你手里的东西变得更轻，你掌控的范围变得更大。

写代码的时候手里是键盘，写 prompt 的时候手里是一句话，写循环的时候手里是一条流水线，到了图，手里只剩一张架构图。

• 写 prompt 时，判断权全在你手里——你给演员递一句台词，他演一句。

• 写循环时，你把排练流程交出去了，演员照着流程反复排练，排到达标自动下台。去年有位工程师用 bash 死循环驱动 Claude Code，从零实现了一门编程语言，验证的就是这个思路。

• 而到了图，你交出去的是整个剧团的架构。谁演什么角色，谁等谁的信号，有人演砸了谁来接替。你盯的不再是一场戏，而是整个演出季。

回头看看使用习惯的变化，这条线索非常清晰。

写 prompt 那阵子，大家收藏了一硬盘的神级模板。后来玩循环，比的是谁能把验收标准写清楚。今年春天 Codex 和 Claude Code 干脆把循环做成了内置命令，你只需给出达标条件，剩下的它自己跑。

那大家实际拿循环干什么？社区里最高频的答案特别朴实：定时干活。夜里自动啃一块技术债，早上起来，审查报告已经摆好了。

为什么非得走到这一步？因为单个循环是可以装糊涂的——跑不通就再跑一遍，反正只有它自己。可一旦几个循环要互相等待结果，糊涂就装不下去了。谁依赖谁，哪步先哪步后，不画明白就是一团乱麻。循环允许你把决定拖到明天，图要求你现在就想清楚。

还有一个共识正在社区里形成：成熟的系统里其实跑着两张图。一张像排班表，定好谁长期管哪摊事，轻易不动。另一张像当天的工单，随任务生成，干完就扔。一张管人，一张管事。

顺着这个逻辑，我突然想到一件一百多年前的事。

泰勒当年拿着秒表站在工厂里，把工人的每个动作拆成标准工序，管理学就此诞生。那时候被建模的是体力活。而现在，轮到我们这些脑力工作者，拿起秒表对准自己了。图工程，说穿了就是给自己的工作做一次泰勒化。

循环没有过时，它只是降级成了图里的一块砖。真正变的是搬砖的人，又被往上赶了一层。

以前比谁的代码写得好，后来比谁的 prompt 写得巧，再往后，可能比的是谁能带好一个团队——哪怕这个团队里，没有一个是人。

这个趋势，不会因为谁在网上吵赢了而停下来。唉，刚学会的循环还没捂热，又要开始学画图了。