AI Coding的5个阶段：好AI程序员都是token喂出来的

这个五一假期我在公司加了 4 天班，天天上午10点-晚上11点。说实话，人已经有点麻了，手也有点麻。

这是我这几天的token量消耗。在这些token量背后的，是15000+行代码，58次提交，23次合并，12次打包。外加12杯咖啡，是的，基本上就是一天3杯的量，咖啡因直接拉满。

在这种强度下写代码，经过了几天的折磨，我对AI编程的理解又深刻了一层。刚好最近看了 Anthropic 研究员 Erik Schluntz 的演讲《Vibe Coding in Production》，里面有个观点很打中我： AI 编程的终局不是人类不管代码，而是人类换一层抽象来管理代码 。

于是我结合自己的经历，把AI编程分成了 5 个阶段。

第一阶段：索取式使用

这个阶段最典型的状态，就是把 AI 当成一个更聪明的搜索框。需求提得比较粗，更关注让 AI 给一个结果。

比如：帮我生成一个投资网站，帮我写一个登录页面，帮我实现一个爬虫，帮我分析茅台的股价。

这个阶段不是不好。所有人第一次用 AI 编程，都是从这里开始的。但问题也很明显，给 AI 的上下文太少，它就只能靠猜，也就是所谓的 AI炼丹 。猜对了，会觉得它很神；猜错了，会觉得它很蠢。

第二阶段：上下文工程

到了第二阶段，我开始意识到，AI 的输出质量很大程度上取决于输入质量。

所谓Rubbish In， Rubbish Out。给它一堆含糊不清的需求，它大概率就会给你一坨看起来能跑、细看全是坑的代码。

所以，这个阶段开始从简单问问题，变成设计给 AI 的输入条件，开始研究Prompt工程。除了收藏了一堆Prompt最佳实践之外，也开始尝试用skill来优化自己的prompt，或者用比如用Figma MCP来提供更多的上下文，用 /rewind、/clear 来控制上下文的节点和长度。

本质上，就是 尽一切可能，把更干净、更完整、更有边界的上下文交给模型 。

那个时候我期待的是：只要输入足够大、足够全，AI 就能给我一个 Fantastic 的输出。

第三阶段：认知转换

这个阶段是一个重要的转折。 从人来提想法，AI来实现，变成了AI提方案，人来审核 。

这个变化挺大的。以前我总觉得，需求应该由我先想清楚，然后让 AI 执行。但后来发现，AI 的优势不是只会写代码，它的优势在于广度大、试错快、能快速铺开多个可能性。

人真正应该做的，不是把每个细节都想死，是站在更高一层，做关键监督、业务判断和隐性经验注入。

比如说我开工前，会先用 OpenSpec 花几分钟和 AI 对齐，让它自己探索项目结构，找到相关文件，把它对任务的理解整理出来，再给出计划。然后我再审核这个计划，补充业务背景，修改不靠谱的部分，确认边界之后，再让 Agent 执行。

这样做出来的质量和效果都是指数级的提升，越是复杂的项目收益越高。因为 AI 不再只是一个执行者，它变成了一个可以先帮你做预研、拆解和方案设计的协作者。

第四阶段：验证层提升

毋庸置疑，4天写15000行代码我是不可能细看的，我也看不过来啊。但是不看又不能保证项目的质量。今天种下的因，终将会成为明天的苦果。

Schluntz提了一个观点：Find an Abstraction layer you can verify。翻译过来就是， 找到你能验证的抽象层 。

CEO 如何检查会计？抽查关键事实。CTO 如何管理专家？验收测试。产品经理如何评审工程功能？亲自使用产品。

过去，工程师的验证层往往在底层代码上，逐行 Code Review。但现在面对 AI 生成的大量代码，我们需要重新思考验证层在哪里。能用测试验证的，就不一定要逐行看代码。能用产品体验验证的，就不一定要陷在实现细节里。核心不是放弃验证责任，而是重新定义 Code Review。

但这里也有个坑。只看表层，很容易变成：功能好像能跑，但内部已经是一团糟。相信大家都有 面对AI写的屎山，改造不如重写的经历 。

所以我的体会是， AI 编程越多，核心架构越要回到朴素的工程原则 。边界清晰、模块内聚、接口稳定、测试可跑、文档明确。人负责框架制定、方向判断、产品取舍和架构边界。AI 负责局部实现、测试回归和查 bug。

有点像雕刻断臂维纳斯。人负责骨架、姿态和比例，AI 负责填充肌肉和石膏，最后人再来审查和精修。风险高、影响大的核心模块，人要多看、多想、多把控。风险低、容易重构的叶子模块，可以让 AI 多推一点，然后在更高的验证层做验收。

第五阶段：并行心流

本次最大的挑战，不只是代码量大，而是我一个人在同一个仓库中里，同时面对3个业务方。业务方A要改bug，业务方B要打个包出来看看，业务方C要联调。

一开始我很乱。要知道，人的心力是会消耗的，混乱墒越多，消耗越快。

后来我参照 Egg.js 的架构理念，重新规划了自己的注意力分配。我把自己当成 master 进程，负责给所有子进程下命令，同时处理主链路上的事情，比如回钉钉、聊业务、判断优先级。

子进程分成两种。一种是 Agent，由 Cmux 担任，负责提醒我不同 AI 进程的状态。任务一旦开始，我就不用盯着，直到它需要我确认，或者完成了，再通知我。另一种是 Worker，也就是一个个具体的 AI 进程。我会在 Cmux 里同时开多个 Worker。

目前我比较舒服的是同时开两个 Worker 推进研发。比起让一个 AI 在那里跑、自己傻等着，效率确实明显提升。

这两个任务不一定都要写代码。可以一个 Agent 写 A 任务，另一个 Agent 探索 B 任务。探索型 Agent 只负责整理结论、风险点和需要修改的文件，然后再交给写代码的 Agent。这样能显著减少主 Agent 的探索时间，也更不容易产生冲突。

如果两个任务都必须写代码，文件不冲突就直接写；如果会冲突，就开 Worktree。效率大概能接近 x2，但心力消耗也会同步上涨。这个时候，最重要的是控制任务边界，尽量不要让两个 Agent 改同一批文件。否则后面合并的时候，会比较痛苦。

这次 OpenSpec 立了大功。

我以前把 OpenSpec 当成任务文档工具，但这次在多 Agent 并行时，我才发现它更像 任务契约和上下文路由器 。它不光帮 AI 串上下文，也帮人串 AI 的上下文。

多进程切换的时候，人是会恍惚的。尤其咖啡因拉满、业务又在催，你很容易忘了上一个任务推进到哪里了，哪个方案已经否掉了，哪个风险还没验证。OpenSpec 能把这些东西固定下来，让你切回来时不用从脑子里硬捞。

过去工程师讲究心流状态，听歌写代码，沉浸在一份代码实现里。现在我感觉，工程师要适应一种新的心流：并行心流。 把叶子节点交给 AI 去做，用 Cmux 把自己从多节点焦虑里解脱出来，然后把注意力重新放回核心架构、业务判断和关键验证上 。

最后

这次最大的体会是： 好战士是子弹喂出来的，好AI程序员是token喂出来的 。

没有公司给我提供的近乎无限token，没有高强度的需求，人很难触发到自己的边界。只有用得多，浪费得多，踩坑踩得多，才会逐渐知道 AI 到底能做什么、不能做什么，以及自己应该站在哪一层和它协作。

第二个体会是， AI Coding 初看省时间不省钱，再看又省时间又省钱 。

关键取决于需求有没有想清楚。如果需求没想清楚，AI 只会把混乱放大。它会很快生成一堆代码，然后你再花更长时间返工。那种感觉就像从一个错，快速跑向下一个错。

但如果需求清楚、边界清楚，AI Coding 的产出真的远超以前。一天能推进的事情，可能是过去一周的量。

而且我越来越觉得，AI Coding 造的不是子弹，更像是在造枪。子弹打出去就没了，但一把好枪，一次付出，后面可以持续收获。当然，前提是项目本身有价值。否则再快，也只是更快地把时间花在不重要的事情上。

这次 4 天加班下来，我不觉得自己只是多写了 15000 行代码。更重要的是，我学会了把自己放在更合适的抽象层上。

该亲自判断的地方，不偷懒。该交给 AI 的地方，不逞强。该验证的地方，一定验证。该停下来想清楚的地方，也不要被 token 推着一路狂奔。

写了这么多，才想明白大道至简。AI编程和投资的本质都是追求一点真正属于自己的掌控感。