我过去一直认为Vibe Coding 只是给非程序员准备的一种“玩具式写法”。直到我自己用一个星期把五个项目全部“聊”了出来才意识到这个判断是错的。那一周我几乎没有手写过完整函数。所有需求、改动、重构都是靠自然语言描述由 AI 编码工具代劳。整个过程当然很爽但爽是有账单的。粗略统计下来那一周我烧掉了接近 100 亿 Token。100 亿是个什么概念如果你也正在用这类工具或者正打算投入一个类似的尝试这篇文章可能正是你需要的。我不会只讲“AI 真棒大家快用”。我更想拆清楚三件事这 100 亿 Token 到底烧在了哪里五个项目是怎么从零到一被“聊”出来的以及哪些看起来不起眼的坑让我半夜爬起来改代码。1. 那一周我把自己从“写代码的人”变成了“项目主理人”1.1 五个项目五种完全不同的“Vibe Coding 尝鲜”我那一周做的五个项目大概是这样几类一个内部数据看板一个批量文件处理脚本一个带简单前端页面的 API 小服务一个多轮对话 demo还有一个围绕既有系统做自动化的工具。把它们列在一起不是为了展示我有多高产。我想说的是另一件事这五个项目在传统开发方式下哪怕每个只算半天工作量加起来也够我忙两周。但在 Vibe Coding 的工作流里时间和精力主要不在“敲键盘”而在“把需求说清楚、让 AI 理解边界、修它写错的地方、最后把能跑的代码变成能交付的代码”。整个过程像什么呢有点像你不再是工地上的工人而是变成了甲方代表。你不需要自己砌砖但你要看得懂图纸知道哪里该用承重墙也必须在验收时把每个房间都走一遍。1.2 为什么“近 100 亿 Token”是一个值得停下来看的数字先解释一下这 100 亿是什么量级。粗略换算一下一本 100 万字的书按常见分词规则折算大概有 150 万到 200 万 Token。100 亿 Token 相当于你把这本书来回读了五六千遍。但对编码 Agent 来说这个量级并不意味着真的“产生”了那么多新代码。它更像一个装卸工在反复读取文件、拼装上下文、补全片段、失败重试的过程中把同样的内容来回搬运了很多次。这里有一个很关键的判断Token 消耗量的多少和最终代码行数几乎无关和上下文管理方式高度相关。同样是写一个 500 行的功能有的人可能只烧掉几百万 Token有的人却要烧掉上亿。差别不在模型聪明不聪明而在你怎么组织对话、怎么喂文件、怎么避免让模型反复读重复的内容。2. Token 不是“字数”它是最容易被误解的搬运量2.1 一个请求的真正成本是整个上下文被重新处理一遍Token 是模型处理文本的最小单位你可以把它理解成把文字切成的小片段。大致上一个汉字在常见模型里对应 1 到 2 个 Token一个英文单词差不多也是 1 到 2 个 Token。你输入一句话模型要把它转成 Token 才能理解。但真正的开销秘密不在这里。关键是每一轮请求模型不是只处理你新输入的那一小段话而是会把当前对话的上下文、关联文件、历史记录全部放进去重新处理一遍。你会觉得“我明明只加了一句修改要求为什么 Token 跑得这么快”因为模型其实把你前面对话里贴过的所有代码、所有报错、所有讨论都重新算了一遍。长对话、大文件、反复粘贴错误堆栈是 Token 消耗膨胀的三个最主要原因。2.2 从“单次问答”到“Agent 自动循环”消耗量是滚雪球的如果你只是把 AI 当成问答工具一次问一句Token 消耗其实很可控。但当你进入 Agent 模式事情就不一样了。现在主流 AI 编程工具基本都支持 Agent 模式。它的工作方式大致是观察项目结构 → 读相关文件 → 决定改哪里 → 执行修改 → 跑一下验证 → 发现问题 → 再读日志 → 再改。这一整个循环里每一步都可能触发模型调用而且每一步都要重新携带上下文。我见过不少新手明明没让 AI 写多少行代码却在一个下午就撞上额度上限。原因不是因为 AI 写得慢而是 Agent 在“读文件—改代码—看结果—继续改”的循环里自动烧掉了大量 Token。你看起来只点了一次按钮背后可能已经跑了三十轮工具调用。2.3 “Token”这个词背着三种完全不同的事这里要专门澄清一个误区因为我在检索资料时看到很多开发者把“sign-in could not be completed, token exchange failed”这类报错当成模型 Token 的问题来搜索。这不是一回事。目前技术圈说的 Token 至少有三种含义模型 TokenAI 计费和处理文本的单位本文讨论的核心。认证 Token登录态、access token、JWT、cookie/session 这类身份凭证。平台积分credits部分工具用积分来代替 Token 计费方便用户理解套餐额度。你可以把认证里的 token 理解成“门禁卡”把模型 Token 理解成“这个月搬运了多少货物”。门禁卡刷不进去和这个月搬了多少货完全是两码事。不过在真实使用中这两类问题会一起出现。比如你可能在连续使用 AI 编程工具几小时后突然遇到“login server error: token exchange failed”或者“401 unauthorized: invalid token”这通常是工具自己的登录凭证过期了不是你项目代码的问题。而当你对话窗口太长、内容太大时又会遇到“400 invalid request: your request exceeded model token limit”这才是真·模型 Token 超限。排查时要先分清是哪一种。3. 五个项目的真实流程走的是同一条路径3.1 第一步把想法拆成“能验证的最小闭环”很多人一上来就喜欢对 AI 说“帮我做一个 CRM”“帮我实现一个电商后台”。这种宽泛需求的后果通常是AI 给你生成一坨庞然大物文件结构混乱很多功能不是你想要的而且你根本不知道从哪开始改。我那一周的做法正好相反。每个项目开始前我都会先拆一个“最小闭环”。所谓的 CRM被我拆成一张客户数据表、一个列表页、一个新增表单、一个搜索框、一个导出按钮。就这五个点先跑通再谈别的。拆完以后我才会把需求写成提示词。写提示词时我不追求花哨只要求包含四个要素任务背景、涉及文件、当前问题、验收标准。一个很典型的模板长这样任务在现有项目里新增导出功能 文件src/utils/export.js、src/pages/list.js 当前问题点击导出按钮没有反应 期望行为点击后生成 CSV 文件并自动下载 验收标准 - 空数据时给出提示不卡死 - 文件超过 5 万行也能生成 - 导出文件名带当前日期这个阶段消耗的 Token 不多但它决定了后面所有步骤省不省。需求拆得越细AI 跑偏的概率越低你返工烧掉的 Token 就越少。3.2 第二步让模型先出骨架再往里填肉很多人在第二步就急着让 AI 直接生成完整功能这是烧 Token 的大坑。让模型一次生成几百行相互依赖的代码往往会出现“看起来完整、一跑就跑偏”的情况排查起来比手写还痛苦。我更建议先要项目骨架。请模型先输出文件结构和核心数据流确认整体思路没问题再开始填充具体模块。一个典型骨架长这样project/ ├── src/ │ ├── api/ │ ├── pages/ │ ├── utils/ │ └── components/ ├── tests/ ├── .env.example ├── .gitignore └── README.md看到骨架后先思考这个结构是否符合我的预期数据流向是否合理如果骨架就有问题宁愿这一轮完全推倒重来也不要往下填。等到确认骨架没问题再按“骨架 → 一个模块 → 跑通 → 下一个模块”的顺序推进。每个模块都用上一步的最小闭环来验证。一次只让 AI 做一件事看起来慢实际反而快。3.3 第三步用“对话流”代替“一条大提示词”第一次接触 Vibe Coding 的人总希望一条提示词解决所有问题。我在那周里得到的教训是一次大的需求应该拆成多个小对话而不是塞进一个大对话。为什么因为模型对“当前会话”的依赖很强。对话太长前面的决策会被后面的内容覆盖对话太杂模型会把模块 A 的上下文带到模块 B 的修改里。我现在的习惯是每次只解决一个问题每条消息都尽量带上“当前问题 相关文件 期望行为 验收标准”。修复 bug 时可以贴报错信息但要把无关日志删掉只保留关键堆栈。不要在一个对话里同时改五个模块那等于让一个做后端的人顺手改前端样式模型分不清优先级。3.4 第四步跑通之后补工程外壳五个项目里有一个项目让我印象特别深代码在开发环境跑得很好一部署就挂。原因也很普通——缺环境变量、目录权限不对、没有日志输出挂了也不知道挂在哪。这类问题不是 AI 写代码能力不行而是它默认你只需要“能跑”不需要“能交付”。所以在功能跑通之后我通常会再让 AI 补几样东西统一的错误处理和日志记录环境变量说明文件和示例配置README 和启动说明.gitignore 和依赖锁定文件这一步做完“能演示”和“能交付”的差距就被补上了。注意演示能跑和你敢长期使用是两件事。功能跑通只是上半场工程化收尾才是下半场。4. Vibe Coding 真正的难点不在生成而在接管4.1 它写出来的代码你必须比它更懂关键路径如果你把 Vibe Coding 理解成“AI 写代码我负责验收”那大概率会踩到一个隐蔽的坑模型的代码看起来合理但关键路径可能藏在你看不懂的地方。我有一个数据看板项目AI 写的聚合函数在大多数情况下结果是对的但偶尔会漏掉某些分类。因为我没有逐行审查数据流直到演示现场才发现。那一刻的尴尬比烧 Token 更让人难受。所以我的建议是你不需要读懂每一行但必须读懂关键路径。数据流、状态管理、权限判断、第三方接口对接这些核心逻辑必须逐行理解。如果某个模块你真读不懂要么说明它超出了你的审查能力要么说明它过于复杂应该被拆小或者重写。4.2 上下文窗口再大也装不下一个真实项目的全部记忆现在的模型上下文窗口越来越大但一个真实项目包含的东西永远比窗口能装的多几十个文件、依赖关系、数据库结构、接口约定、历史决策。一开始我以为模型能记住我前面所有对话后来发现它经常在项目中期忘记早期定下的规则。这不是模型“笨”而是超出上下文承载范围后的自然表现。我的对策是把项目拆成模块每个对话只负责一个模块。同时把架构决策、命名规则、模块边界写成文档放到项目目录里让每次新开的对话都能快速读取。模型记不住文档来补——这是长期使用 Vibe Coding 最重要的工作习惯。4.3 最容易翻车的不是大改而是“小改引发大崩溃”另一个教训来自一次很小的改动。我让 AI“把按钮颜色改成主题色”它顺手把旁边一个弹窗组件的交互逻辑也一起改了。我本来只是想要个样式微调结果测试时发现弹窗行为变了。这类“小改引发大崩溃”是 Agent 模型的常见问题。因为模型在上下文里看到了太多相关内容它认为“顺手修复”是合理的但对你的项目来说这是没有预期的回归。为了应对这个问题我给自己定了三条铁律每次修改前先让 AI 列出它准备改哪些文件、改哪几行。改完后立刻跑一遍最小验证确认只影响了预期范围。用 git 提交对改动做对比审查看到任何无关改动就回退。# 提交前先看这次改了哪些文件 git diff HEAD --stat # 再具体看改动内容 git diff HEAD没有测试的项目回归全靠肉眼而肉眼一定会漏。所以越依赖 Vibe Coding越要重视快速反馈回路。4.4 有些场景我会立刻切回人手写Vibe Coding 适合很多场景但绝不是所有场景。我给自己定了一个判断标准如果出错会导致资损、安全事故或不可回滚就不该完全交给 AI。具体来说这几类我会切回人手写并发控制、分布式锁、消息队列消费逻辑支付、权限、加密、敏感数据脱敏性能敏感的核心循环第三方支付回调、登录认证等有严格契约的对接这些场景不是不能用 AI 辅助而是不能让它自由发挥。AI 可以帮你理思路、做代码审查、写测试但最终的关键逻辑应该由人主导。5. 从“疯狂”到“常态”我现在会这样安排 Vibe Coding5.1 把任务分成四类分别对待经历了那一周我不再把 Vibe Coding 当成“什么都交给 AI”的魔法而是把它当成一种需要分场景使用的工具。我现在会把任务分成四类任务类型典型示例使用建议界面搭建 / 原型表单、页面、数据看板放心用 AI速度快迭代成本低低风险脚本 / 自动化文件处理、批量转换、数据清洗AI 生成后读一遍主流程补上日志中风险业务功能CRUD、接口对接、状态管理小步迭代每步跑测试严格审查改动高风险核心支付、权限、并发、加密人肉主导AI 只做辅助和审查这个分类帮我避免了一个大坑不该让 AI 做主的地方不要因为“它写得快”就放手。5.2 控制 Token 消耗和质量的一个检查清单如果你认真把 Vibe Coding 用起来Token 消耗一定会成为你要面对的问题。我现在的习惯是每次开一个新项目前都过一遍这个检查清单每条指令只改一个点不要同时提多个需求。贴日志前先裁剪只保留关键报错和堆栈不要整页粘贴。按任务难度选模型简单改动用轻量模型复杂架构才用强模型。利用上下文缓存不要让模型反复读取同一个大文件。给每个任务设 Token 预算超了就停重新拆任务。保留 git 历史随时可以回滚降低试错成本。不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常。这个清单不是让我“少用 AI”而是让我把每一分 Token 都花在真正需要的地方。5.3 长期使用的边界它替换的是重复劳动不是你的判断回到最开始的主判断Vibe Coding 真正改变的不是“谁写代码”而是“从想法到可运行版本”的反馈循环变短了。以前做一个新功能要先搭环境、写骨架、调接口、处理边界可能两天才能看到一个能运行的版本。现在这些可以在几个小时内完成。这个变化是巨大的它让我敢尝试更多原型也敢更频繁地推倒重来。但有一点没变代码审查、测试、架构设计、异常处理这些成本并没有消失只是被推迟到了后面。如果只看见生成速度看不见维护成本那大概率会在项目中期突然翻车。所以我对 Vibe Coding 的定位一直是它替换的是重复劳动不是你的工程判断。你可以让 AI 写更多代码但你不能让 AI 替你做决定。6. 如果让我再烧一遍 100 亿 Token我会这样分配6.1 按“验证优先”分配预算那一周我是有点“乱烧”的——前期大量时间花在让模型生成超出需求范围的代码后期又花了两倍 Token 去改。如果让我重新分配我会更接近这个结构第一天只做骨架和最小闭环不碰完整功能。用最少 Token 验证技术路线可行。第二天到第五天80% 的 Token 花在跑通主流程和修正核心 bug 上避免反复让 AI 重写已经确认过的模块。最后半天专门做工程化收尾。补日志、补权限、补部署说明让项目真正“能交付”。这样安排的好处是问题会在早期暴露而不是在项目快完成时集中爆发。6.2 最值得投入的 Token其实是“让未来省 Token”的东西很多人会忽略最该花 Token 的地方不是让 AI 生成更多功能而是让它帮你生成“减少未来 Token 消耗”的东西。比如架构说明文档、模块拆分清单、自动化测试、数据流图。这些产物不会立刻带来新功能但它们会让后续每次调整的上下文更小、更精准。我第二个项目比第一个项目少烧了大量 Token并不是第二个项目更简单而是我提前把架构说明写清楚了AI 不需要每次都重新理解整个项目。6.3 结束之前记得做这三件事如果项目做到最后真的可以交付了我会在做完最后一遍验证之前先完成这三件事提交代码写清楚 commit message说明哪些模块是 AI 生成的、哪些经过了人工修改。把项目里的踩坑记录整理成简短文档方便后续维护的人包括未来的自己快速理解。把这次用过的提示词模板保存下来作为下一个项目的起点。我自己的经验是Vibe Coding 的提示词并不是一次性的而是可以积累的资产。第一个项目你可能要花半天写提示词第二个项目因为有模板和踩坑记录可能只需要一个小时。这种积累速度是传统手写代码很难做到的。一周烧掉 100 亿 Token听起来很夸张但真正值得记住的不是这个数字而是背后那套工作方式需求拆解、最小闭环、上下文控制、关键路径审查、工程化收尾。这套流程的每一步都在回答同一个问题——AI 负责把活干出来你负责把活干对。只要这个分工还在Vibe Coding 就永远只是你的杠杆而不是你的替代品。