烧了200万Token才学会的AI编程方法论
烧了200万Token才学会的AI编程方法论
你让AI写一个登录页面，它噼里啪啦生成了800行代码。你看了两眼，感觉不太对，改了一句Prompt。它又噼里啪啦给你重写了800行——跟上一版完全不一样的800行。
这个循环你重复了多少次？三次？五次？
我见过最夸张的一位老哥，一个下午烧了两百万Token，最后还是自己手写了那个功能。他说了一句话让我印象深刻：”AI编程就像请了一个极其勤快但听不懂人话的实习生——你说得越多，它越乱来。”
这不是段子，这是大部分AI编程用户的日常。
Vibe Coding的坑，你踩够了吗
先说个名词。Andrej Karpathy（前特斯拉AI总监）给这种编程方式起了个很传神的名字：Vibe Coding，氛围编程。用他的原话说就是——”我只是看看东西、说说话、跑跑代码、复制粘贴，然后它就能工作了。”
听着挺美，对吧？问题是，它真的能工作吗？
业内有个说法叫”70/30困境”：AI可以飞快搞定70%的功能，但剩下的30%可能让你花上几天。更要命的是，修一个Bug冒出来三个新Bug，代码越改越面目全非。最终的结局往往是——开发者对AI彻底失去信任，退回手写模式。
Vibe Coding的本质问题其实就一条：你一次性往AI嘴里塞了太多东西。
你以为自己在提需求，其实你在制造噪音。你以为给的信息越多AI越聪明，实际上恰恰相反。就好比你跟一个新来的同事说：”把用户系统做了，要有登录注册、第三方OAuth、手机验证码、忘记密码、角色权限、操作日志、还要支持多租户。”
这同事就算是个天才，也得蒙圈。
反直觉的真相：给AI更少，它反而做得更好
这不是我拍脑袋说的。
Google工程师Addy Osmani在《Beyond Vibe Coding》里专门讨论了这个问题，国内几个技术团队也在实践中验证了同一个结论：渐进式披露策略可以减少高达90%的Token消耗，同时代码质量反而上升。
原理并不复杂。大语言模型的注意力机制有一个特点——上下文越长，关键信息被”稀释”的概率越大。你给它一份5000字的需求文档，它大概率会抓住一些细节、遗漏另一些，然后用它自己的”创造力”把遗漏的部分补上。这种创造力，说好听点叫脑补，说难听点叫幻觉。
所以真正的诀窍是：别一次把话说完。
渐进式AI编程的三板斧
讲方法论之前，先看一个真实场景。
我前阵子要给一个CLI工具加一个多轮对话功能。如果按Vibe Coding的套路，我会说：”给这个CLI工具加上多轮对话支持，要能记住上下文，支持退出命令，历史记录存本地。”
AI大概率会给我生成一个300行的God Function，把对话管理、文件IO、命令解析全揉在一起，看得人血压飙升。
换成渐进式的做法，我做了三件事：
第一板斧：Spec先行
在动手写任何代码之前，我先花5分钟写了一份不到200字的Spec：
功能：CLI多轮对话 输入：用户文本输入 输出：AI响应文本 核心行为：维护对话历史列表，每轮追加user和assistant消息 边界条件：输入”exit”退出，历史超过20轮截断最早记录 不做什么：不做持久化存储，不做多会话切换
这份Spec最值钱的不是它写了什么，而是它写了“不做什么”。
很多人不知道，给AI划定”不做”的边界，比告诉它”做什么”有效得多。因为AI的默认倾向就是往多了做——你不拦着，它能给你生成一个带数据库、带用户管理的完整SaaS系统。
第二板斧：拆成原子步骤
有了Spec之后，我把实现拆成了四个小任务，每个任务不超过50行代码：
- 对话历史的数据结构和增删接口
- 用户输入的读取和退出检测
- AI调用和响应追加
- 主循环的组装
关键在于：每个小任务完成后，我先跑一下验证，确认没问题再往下走。
这样做的好处是，如果AI在第三步搞砸了，我只需要重来这一步，而不是推翻全部重来。返工成本从”重写整个功能”变成了”修改一个函数”，这差距是数量级的。
第三板斧：用测试代替肉眼
最后一步也是最容易被忽略的——别用肉眼去检查AI写的代码，用测试。
人的注意力是有限资源，拿去逐行审核AI生成的代码纯属浪费。正确的做法是在每个原子步骤完成后跑自动化测试。测试通过，继续；测试失败，把错误信息丢给AI让它改。
整个多轮对话功能，我大概用了30分钟搞定。如果按Vibe Coding的方式，根据以往经验，至少得折腾半天。
为什么大多数人做不到
方法说起来简单，但我知道大部分人看完之后还是会继续Vibe Coding。
原因很朴素：写Spec、拆任务、写测试，每一步都在增加”启动摩擦”。 人天生倾向于走最短路径——打开终端，一句话丢给AI，看它噼里啪啦跑起来，那种即时反馈感真的很爽。
但这就像吃快餐一样，爽是一时的，债是要还的。你在前期省掉的5分钟Spec时间，后面会用50分钟的Debug来偿还，还要外加一肚子火。
好消息是，你不需要一步到位。根据我的经验，任务复杂度可以分成三档来区别对待：
简单任务（改个配置、加个字段）：直接用Vibe Coding就行，别给自己加戏。
中等任务（加一个独立功能模块）：写Spec + 拆步骤就够了，测试可以后补。
复杂任务（涉及多模块联动、状态管理）：三板斧一个不能少，最好再加上Git分支隔离。
不需要每次都走全套流程，但至少养成一个习惯：在让AI动手之前，花2分钟想清楚你到底要什么。
从”让AI帮我写代码”到”和AI一起做工程”
最后聊几句大的。
AI编程工具的竞争已经过了”谁家模型更聪明”的阶段。Cursor、Claude Code、Codex、Copilot，底层模型的差距在缩小，真正拉开差距的是使用方法。
同样一把锤子，有人用来钉钉子，有人用来砸自己脚。工具没变，变的是拿工具的人。
渐进式编程的本质不是什么高深的方法论，它就是把软件工程里最基本的东西——需求分析、任务拆解、测试驱动——用AI时代的语言重新讲了一遍。 只不过在Vibe Coding的狂欢里，太多人忘了这些基本功。
分水岭不在于你用什么工具，在于你有没有意识到：AI不是来替代你思考的，它是来替代你打字的。
思考的部分，永远是你的活儿。