1. 100亿Token烧完之后我重新理解了“Code is cheap”“Code is cheap”——代码很便宜这句话在过去两年里被反复引用几乎成了AI编程时代的信条。逻辑听起来无懈可击大模型能秒生成几百行代码写代码的门槛被拉到了地板那代码本身当然不值钱了。我一开始也信了甚至在自己的团队里推这套理念鼓励大家多用AI生成、少纠结手写。但当我真正把AI编程工具接入到日常开发流程累计消耗掉超过100亿Token之后我的结论完全反过来了Code is cheap 是最大的谎言。代码的字符确实变便宜了但围绕代码产生的一切——理解、验证、集成、维护、调试——成本不但没降反而在某些环节暴涨。你省下的是敲键盘的时间付出的是审查、返工和认知负荷的代价。这篇文章不是要唱衰AI编程恰恰相反我现在是重度用户。但我想把这一年多踩过的坑、算过的账、总结出的方法完整讲清楚。适合两类人看一是刚开始用AI写代码、还在“哇好神奇”阶段的朋友二是已经在团队里推AI编程、但发现效率没想象中高的技术负责人。我会围绕Token消耗、SDDSpecification-Driven Development规格驱动开发、CLAUDE.md这类上下文文件、Lint校验这几个关键词展开把“代码便宜”这个幻觉一层层拆开。先给一个最直观的账我统计过自己一个中等复杂度的功能模块纯手写大约需要6小时用AI辅助表面上2小时就能出第一版。但第一版到能合并进主分支中间经历了11轮修改、3次架构调整、2次因为AI“幻觉API”导致的返工。真实耗时是7.5小时。AI把“写”变便宜了却把“改”变贵了。这就是100亿Token教给我的第一课。2. Token账单背后的真相你买的不是代码是试错次数2.1 一次功能开发的Token消耗拆解很多人对Token的感知是模糊的觉得“反正按量付费用多少算多少”。但当你真的把账单拉出来会发现消耗结构和直觉完全不同。我拿一个真实案例拆解给一个后台管理系统加“批量导入用户并做字段校验”的功能涉及前端表单、后端接口、数据库写入、错误提示四块。阶段操作内容大约Token消耗占比需求描述与上下文投喂把相关文件、接口文档、数据表结构塞给模型约1.2万8%首版代码生成生成前后端代码约2.5万17%报错修复循环贴报错、贴日志、让模型改约6.8万46%逻辑微调与重构字段规则变更、边界处理约3.1万21%最终审查与注释让模型解释自己写的代码约1.2万8%看清楚了吗真正用于“生成代码”的Token只占17%将近一半的Token花在了“修AI自己制造的bug”上。这就是Code is cheap的第一个陷阱它只计算了生成成本完全忽略了修复成本。而修复成本恰恰是Token消耗的大头。2.2 为什么修复循环这么烧Token原因在于大模型的工作机制。它生成代码时是基于概率的不是基于对你项目真实运行环境的理解。它不知道你数据库里那个字段其实是varchar(50)而不是它以为的text不知道你前端用的组件库版本已经废弃了某个属性不知道你后端的中间件会对请求体做二次解析。这些“不知道”在生成时不会暴露只有在运行时才炸出来。而每一次修复你都得把报错信息、相关代码、上下文重新投喂一遍。上下文越长Token消耗越大。更麻烦的是模型有时候会“改错方向”——你给它一个报错它改了一个不相关的地方结果引入新bug于是你又要新一轮投喂。这个循环一旦失控Token就像漏水一样往外流。我做过一个粗略统计一个中等bug的平均修复轮次是3.2轮每轮平均消耗8000到15000 Token。如果一个功能引入5个bug光修复就是十几万Token。这就是为什么100亿Token听起来很多实际用起来很快就见底。2.3 一个反直觉的省钱策略先花Token做约束踩了足够多坑之后我总结出一个反直觉的做法在生成代码之前先花Token让模型帮你写约束条件。具体来说不是直接说“帮我写个导入功能”而是先让它输出一份规格说明字段有哪些、类型是什么、校验规则是什么、错误码怎么定义、边界情况怎么处理。这份规格说明本身要花几千Token但它能把后续的修复循环砍掉一半以上。这就是SDD规格驱动开发思路的雏形。先定规格再生成代码让模型的输出有明确的靶子而不是自由发挥。实测下来同样的功能先写规格再生成总Token消耗能降低35%到50%。省钱的秘诀不是少用Token而是把Token花在刀刃上。3. SDD不是新概念但AI时代它变成了刚需3.1 规格驱动开发到底在解决什么问题SDD这个概念在传统软件工程里早就有了核心思想是“先写清楚要做什么再写怎么做”。但在过去很多团队觉得写规格文档太慢、太形式化直接上手写代码更快。AI编程把这个逻辑彻底颠覆了因为AI生成代码太快了快到如果你不先约束它它就会用错误的方式飞快地生产一堆垃圾。我举个真实对比。同一个“用户积分兑换”功能两种做法做法A直接对模型说“帮我写一个积分兑换功能”它生成了一版代码逻辑大致对但兑换比例写死在代码里、没有事务保护、没有并发控制、错误提示是英文的。改这些花了4轮。做法B先让模型输出规格——兑换比例从配置读取、需要数据库事务、并发用乐观锁、错误提示走国际化。然后基于规格生成代码一次成型只改了1轮。做法B前期多花了约5000 Token写规格但后期省了约4万Token的修复。规格不是负担是给AI套的缰绳。3.2 一份能落地的规格应该包含什么不是让你写几十页的PRD而是写一份模型能直接消费的“技术规格”。我的模板通常包含这几块数据契约输入输出的字段名、类型、是否必填、默认值、取值范围。这部分直接决定模型会不会用错类型。行为规则核心业务逻辑的分支条件比如“余额不足时返回什么”“重复提交怎么处理”。边界与异常空值、超长、并发、超时这些情况分别怎么响应。依赖约束必须用项目里已有的哪个工具类、哪个中间件、哪个组件禁止引入新依赖。验收标准什么样的输出算合格最好能写成可执行的断言。这份规格写下来大概300到800字模型读一遍几千Token但它带来的确定性提升是巨大的。规格的本质是把“你脑子里的隐性知识”变成“模型能读懂的显性约束”。3.3 SDD和CLAUDE.md的配合打法如果你用的是支持项目级上下文文件的工具比如CLAUDE.md这类机制可以把通用规格沉淀进去。CLAUDE.md的作用是给模型一个“项目说明书”让它每次生成代码前都知道这个项目的技术栈、代码规范、目录结构、常用工具。我的CLAUDE.md里固定放这几类内容技术栈版本清单框架、语言、数据库、组件库的具体版本号代码风格约定命名、缩进、注释语言、错误处理方式目录职责说明哪个目录放什么避免模型乱建文件禁止事项不许用的API、不许引入的依赖、不许改的公共模块常用命令构建、测试、Lint的执行方式有了这个文件模型生成代码的“跑偏率”会明显下降。因为它不再需要你每次都在对话里重复这些背景而是从项目上下文里自动读取。CLAUDE.md是把SDD从“每次写”变成“一次写、长期用”的关键载体。4. Lint和自动化校验拦住AI代码的第一道闸门4.1 为什么AI生成的代码特别需要Lint人类写代码会累、会走神但基本会遵守自己熟悉的规范。AI写代码不会累但它也没有“规范”这个概念它只是在预测“什么样的代码看起来合理”。所以它会混用单引号和双引号、会生成未使用的变量、会写出永远为真的条件判断、会忘记处理Promise的reject。这些问题如果靠人眼审查成本极高。但靠Lint工具几秒钟就能扫出来。我在接入AI编程之后做的第一件事就是把Lint规则收紧并且把Lint作为AI生成代码的强制关卡。流程变成AI生成 → 自动Lint → 有错先让AI自己修 → 人再看。4.2 我实际配置的校验链路不同技术栈的Lint工具不一样但思路一致。以我常用的前端Node后端为例环节工具作用是否阻断语法与风格ESLint变量未使用、引号风格、分号是类型检查TypeScript tsc类型不匹配、隐式any是格式化Prettier缩进、换行、空格自动修复提交前检查husky lint-staged只检查改动文件是单元测试Jest/Vitest核心逻辑断言是关键点在于这些检查要在AI生成之后立刻跑而不是等到提交时。我通常会让AI生成完代码后紧接着执行Lint命令把报错直接贴回给模型让它修。这样一轮就能清掉大部分低级问题人只需要关注业务逻辑对不对。4.3 Lint报错怎么喂给模型最省Token这里有个技巧。Lint报错往往很多条如果全量贴给模型Token消耗大且容易让它抓不住重点。我的做法是先按错误类型分组同类错误只贴一条示例加总数。优先贴“阻断级”错误警告级先忽略。告诉模型“只修这些错误不要改其他逻辑”。这样一轮修复的Token消耗能控制在几千以内而不是动辄上万。Lint不是用来炫技的是用来给AI划定修改范围的。范围越清晰模型越不容易改出新问题。5. 那些让我付出惨痛代价的AI编程幻觉5.1 幻觉API最隐蔽的坑AI最危险的地方不是写错逻辑而是编造不存在的API。它会用非常自信的语气调用一个你项目里根本没有的方法参数签名看起来还挺合理。如果你不跑测试直接合并运行时就是一个undefined is not a function。我印象最深的一次模型调用了一个数据库客户端的bulkUpsert方法文档里确实有类似功能但当前版本的方法名是upsertMany。这个错误在代码审查时很难发现因为看起来太正常了。结果上线后批量导入功能直接报错回滚花了半小时。防幻觉的唯一有效手段就是跑起来。静态审查挡不住幻觉API只有真实执行才能暴露。所以我现在坚持一条铁律AI生成的代码必须至少跑通一次核心路径才能进入人工审查。5.2 上下文污染越聊越蠢长对话里模型会逐渐“忘记”早期的约束或者把不同任务的上下文混在一起。比如你先让它写A模块再让它写B模块它可能把A的变量名带到B里或者用A的架构去套B。我的应对策略是任务隔离一个功能一个独立会话做完就关。如果必须连续做多个相关功能就在每个新任务开始时重新贴一遍关键约束或者依赖CLAUDE.md这类持久化上下文。不要指望模型在长对话里保持清醒它没有“记忆”只有“当前窗口”。5.3 过度自信的注释和文档AI写的注释经常是废话比如// 初始化变量、// 返回结果。更糟的是它会写出与代码实际行为不符的注释比如注释说“这里做了缓存”实际代码根本没缓存。这种注释比没有注释更危险因为它会误导后来的维护者。我的做法是AI生成的注释一律先删掉只保留解释“为什么”的注释且必须人工确认。解释“是什么”的注释交给代码本身解释“为什么”的注释才需要人写。6. 把AI编程从“烧钱”变成“省钱”的实操框架6.1 分层使用什么任务适合AI什么不适合不是所有代码都适合AI生成。我总结了一个简单的判断标准任务类型适合度原因样板代码、CRUD高模式固定模型见过大量类似代码工具函数、格式化高逻辑独立边界清晰复杂业务逻辑中需要规格约束否则容易跑偏架构设计低需要全局视野模型容易局部最优性能敏感代码低模型不懂你的真实瓶颈安全相关代码极低幻觉可能导致严重漏洞把AI用在它擅长的地方而不是指望它包办一切。这是控制Token成本的第一原则。6.2 建立“生成-校验-修复”的闭环我的标准流程是这样的写规格用几百字描述清楚要做什么、约束是什么。生成代码让模型基于规格生成要求它同时输出关键决策的理由。自动校验跑Lint、类型检查、单元测试。定向修复把校验报错分组喂回模型限定修改范围。人工审查只看业务逻辑和架构合理性低级问题已被自动挡掉。沉淀上下文把这次的新约束补充进CLAUDE.md下次复用。这个闭环跑顺之后我的Token消耗结构发生了明显变化修复循环占比从46%降到了20%左右规格和生成占比上升。总消耗没降多少但有效产出大幅提升。6.3 团队协作中的Token管理如果是团队使用Token管理就更重要了。我们团队的做法是共享一份CLAUDE.md统一项目上下文避免每个人重复投喂。建立常用规格模板库新功能先找模板改而不是从零写。定期复盘Token消耗找出异常高的任务分析是规格没写好还是任务本身不适合AI。把Lint和测试作为强制关卡不通过不允许提交从源头减少返工。Token不是省出来的是管出来的。管住上下文、管住校验、管住任务边界成本自然就下来了。7. 写在最后Code is cheap但判断力越来越贵回到标题。100亿Token烧完我最大的体会不是“AI不好用”而是**“代码”这个词被偷换了概念**。AI让“代码字符”变便宜了但让“正确的代码”变贵了。因为生成越快筛选和验证的压力越大候选方案越多做决策的认知成本越高。真正稀缺的从来不是代码而是知道要写什么代码、知道写出来的代码对不对、知道什么时候不该用AI。这些判断力AI替代不了反而因为AI的普及变得更值钱。如果你也在用AI编程我的建议是别被“Code is cheap”带偏把省下来的时间投到规格、校验和架构思考上。Token会花完但判断力会一直跟着你。 
长河君 · 2026/10/26 20:21:02 · 阅读 1.2k 100亿Token后，我为何说Code is cheap是最大谎言
1. 100亿Token烧完之后我重新理解了“Code is cheap”“Code is cheap”——代码很便宜这句话在过去两年里被反复引用几乎成了AI编程时代的信条。逻辑听起来无懈可击大模型能秒生成几百行代码写代码的门槛被拉到了地板那代码本身当然不值钱了。我一开始也信了甚至在自己的团队里推这套理念鼓励大家多用AI生成、少纠结手写。但当我真正把AI编程工具接入到日常开发流程累计消耗掉超过100亿Token之后我的结论完全反过来了Code is cheap 是最大的谎言。代码的字符确实变便宜了但围绕代码产生的一切——理解、验证、集成、维护、调试——成本不但没降反而在某些环节暴涨。你省下的是敲键盘的时间付出的是审查、返工和认知负荷的代价。这篇文章不是要唱衰AI编程恰恰相反我现在是重度用户。但我想把这一年多踩过的坑、算过的账、总结出的方法完整讲清楚。适合两类人看一是刚开始用AI写代码、还在“哇好神奇”阶段的朋友二是已经在团队里推AI编程、但发现效率没想象中高的技术负责人。我会围绕Token消耗、SDDSpecification-Driven Development规格驱动开发、CLAUDE.md这类上下文文件、Lint校验这几个关键词展开把“代码便宜”这个幻觉一层层拆开。先给一个最直观的账我统计过自己一个中等复杂度的功能模块纯手写大约需要6小时用AI辅助表面上2小时就能出第一版。但第一版到能合并进主分支中间经历了11轮修改、3次架构调整、2次因为AI“幻觉API”导致的返工。真实耗时是7.5小时。AI把“写”变便宜了却把“改”变贵了。这就是100亿Token教给我的第一课。2. Token账单背后的真相你买的不是代码是试错次数2.1 一次功能开发的Token消耗拆解很多人对Token的感知是模糊的觉得“反正按量付费用多少算多少”。但当你真的把账单拉出来会发现消耗结构和直觉完全不同。我拿一个真实案例拆解给一个后台管理系统加“批量导入用户并做字段校验”的功能涉及前端表单、后端接口、数据库写入、错误提示四块。阶段操作内容大约Token消耗占比需求描述与上下文投喂把相关文件、接口文档、数据表结构塞给模型约1.2万8%首版代码生成生成前后端代码约2.5万17%报错修复循环贴报错、贴日志、让模型改约6.8万46%逻辑微调与重构字段规则变更、边界处理约3.1万21%最终审查与注释让模型解释自己写的代码约1.2万8%看清楚了吗真正用于“生成代码”的Token只占17%将近一半的Token花在了“修AI自己制造的bug”上。这就是Code is cheap的第一个陷阱它只计算了生成成本完全忽略了修复成本。而修复成本恰恰是Token消耗的大头。2.2 为什么修复循环这么烧Token原因在于大模型的工作机制。它生成代码时是基于概率的不是基于对你项目真实运行环境的理解。它不知道你数据库里那个字段其实是varchar(50)而不是它以为的text不知道你前端用的组件库版本已经废弃了某个属性不知道你后端的中间件会对请求体做二次解析。这些“不知道”在生成时不会暴露只有在运行时才炸出来。而每一次修复你都得把报错信息、相关代码、上下文重新投喂一遍。上下文越长Token消耗越大。更麻烦的是模型有时候会“改错方向”——你给它一个报错它改了一个不相关的地方结果引入新bug于是你又要新一轮投喂。这个循环一旦失控Token就像漏水一样往外流。我做过一个粗略统计一个中等bug的平均修复轮次是3.2轮每轮平均消耗8000到15000 Token。如果一个功能引入5个bug光修复就是十几万Token。这就是为什么100亿Token听起来很多实际用起来很快就见底。2.3 一个反直觉的省钱策略先花Token做约束踩了足够多坑之后我总结出一个反直觉的做法在生成代码之前先花Token让模型帮你写约束条件。具体来说不是直接说“帮我写个导入功能”而是先让它输出一份规格说明字段有哪些、类型是什么、校验规则是什么、错误码怎么定义、边界情况怎么处理。这份规格说明本身要花几千Token但它能把后续的修复循环砍掉一半以上。这就是SDD规格驱动开发思路的雏形。先定规格再生成代码让模型的输出有明确的靶子而不是自由发挥。实测下来同样的功能先写规格再生成总Token消耗能降低35%到50%。省钱的秘诀不是少用Token而是把Token花在刀刃上。3. SDD不是新概念但AI时代它变成了刚需3.1 规格驱动开发到底在解决什么问题SDD这个概念在传统软件工程里早就有了核心思想是“先写清楚要做什么再写怎么做”。但在过去很多团队觉得写规格文档太慢、太形式化直接上手写代码更快。AI编程把这个逻辑彻底颠覆了因为AI生成代码太快了快到如果你不先约束它它就会用错误的方式飞快地生产一堆垃圾。我举个真实对比。同一个“用户积分兑换”功能两种做法做法A直接对模型说“帮我写一个积分兑换功能”它生成了一版代码逻辑大致对但兑换比例写死在代码里、没有事务保护、没有并发控制、错误提示是英文的。改这些花了4轮。做法B先让模型输出规格——兑换比例从配置读取、需要数据库事务、并发用乐观锁、错误提示走国际化。然后基于规格生成代码一次成型只改了1轮。做法B前期多花了约5000 Token写规格但后期省了约4万Token的修复。规格不是负担是给AI套的缰绳。3.2 一份能落地的规格应该包含什么不是让你写几十页的PRD而是写一份模型能直接消费的“技术规格”。我的模板通常包含这几块数据契约输入输出的字段名、类型、是否必填、默认值、取值范围。这部分直接决定模型会不会用错类型。行为规则核心业务逻辑的分支条件比如“余额不足时返回什么”“重复提交怎么处理”。边界与异常空值、超长、并发、超时这些情况分别怎么响应。依赖约束必须用项目里已有的哪个工具类、哪个中间件、哪个组件禁止引入新依赖。验收标准什么样的输出算合格最好能写成可执行的断言。这份规格写下来大概300到800字模型读一遍几千Token但它带来的确定性提升是巨大的。规格的本质是把“你脑子里的隐性知识”变成“模型能读懂的显性约束”。3.3 SDD和CLAUDE.md的配合打法如果你用的是支持项目级上下文文件的工具比如CLAUDE.md这类机制可以把通用规格沉淀进去。CLAUDE.md的作用是给模型一个“项目说明书”让它每次生成代码前都知道这个项目的技术栈、代码规范、目录结构、常用工具。我的CLAUDE.md里固定放这几类内容技术栈版本清单框架、语言、数据库、组件库的具体版本号代码风格约定命名、缩进、注释语言、错误处理方式目录职责说明哪个目录放什么避免模型乱建文件禁止事项不许用的API、不许引入的依赖、不许改的公共模块常用命令构建、测试、Lint的执行方式有了这个文件模型生成代码的“跑偏率”会明显下降。因为它不再需要你每次都在对话里重复这些背景而是从项目上下文里自动读取。CLAUDE.md是把SDD从“每次写”变成“一次写、长期用”的关键载体。4. Lint和自动化校验拦住AI代码的第一道闸门4.1 为什么AI生成的代码特别需要Lint人类写代码会累、会走神但基本会遵守自己熟悉的规范。AI写代码不会累但它也没有“规范”这个概念它只是在预测“什么样的代码看起来合理”。所以它会混用单引号和双引号、会生成未使用的变量、会写出永远为真的条件判断、会忘记处理Promise的reject。这些问题如果靠人眼审查成本极高。但靠Lint工具几秒钟就能扫出来。我在接入AI编程之后做的第一件事就是把Lint规则收紧并且把Lint作为AI生成代码的强制关卡。流程变成AI生成 → 自动Lint → 有错先让AI自己修 → 人再看。4.2 我实际配置的校验链路不同技术栈的Lint工具不一样但思路一致。以我常用的前端Node后端为例环节工具作用是否阻断语法与风格ESLint变量未使用、引号风格、分号是类型检查TypeScript tsc类型不匹配、隐式any是格式化Prettier缩进、换行、空格自动修复提交前检查husky lint-staged只检查改动文件是单元测试Jest/Vitest核心逻辑断言是关键点在于这些检查要在AI生成之后立刻跑而不是等到提交时。我通常会让AI生成完代码后紧接着执行Lint命令把报错直接贴回给模型让它修。这样一轮就能清掉大部分低级问题人只需要关注业务逻辑对不对。4.3 Lint报错怎么喂给模型最省Token这里有个技巧。Lint报错往往很多条如果全量贴给模型Token消耗大且容易让它抓不住重点。我的做法是先按错误类型分组同类错误只贴一条示例加总数。优先贴“阻断级”错误警告级先忽略。告诉模型“只修这些错误不要改其他逻辑”。这样一轮修复的Token消耗能控制在几千以内而不是动辄上万。Lint不是用来炫技的是用来给AI划定修改范围的。范围越清晰模型越不容易改出新问题。5. 那些让我付出惨痛代价的AI编程幻觉5.1 幻觉API最隐蔽的坑AI最危险的地方不是写错逻辑而是编造不存在的API。它会用非常自信的语气调用一个你项目里根本没有的方法参数签名看起来还挺合理。如果你不跑测试直接合并运行时就是一个undefined is not a function。我印象最深的一次模型调用了一个数据库客户端的bulkUpsert方法文档里确实有类似功能但当前版本的方法名是upsertMany。这个错误在代码审查时很难发现因为看起来太正常了。结果上线后批量导入功能直接报错回滚花了半小时。防幻觉的唯一有效手段就是跑起来。静态审查挡不住幻觉API只有真实执行才能暴露。所以我现在坚持一条铁律AI生成的代码必须至少跑通一次核心路径才能进入人工审查。5.2 上下文污染越聊越蠢长对话里模型会逐渐“忘记”早期的约束或者把不同任务的上下文混在一起。比如你先让它写A模块再让它写B模块它可能把A的变量名带到B里或者用A的架构去套B。我的应对策略是任务隔离一个功能一个独立会话做完就关。如果必须连续做多个相关功能就在每个新任务开始时重新贴一遍关键约束或者依赖CLAUDE.md这类持久化上下文。不要指望模型在长对话里保持清醒它没有“记忆”只有“当前窗口”。5.3 过度自信的注释和文档AI写的注释经常是废话比如// 初始化变量、// 返回结果。更糟的是它会写出与代码实际行为不符的注释比如注释说“这里做了缓存”实际代码根本没缓存。这种注释比没有注释更危险因为它会误导后来的维护者。我的做法是AI生成的注释一律先删掉只保留解释“为什么”的注释且必须人工确认。解释“是什么”的注释交给代码本身解释“为什么”的注释才需要人写。6. 把AI编程从“烧钱”变成“省钱”的实操框架6.1 分层使用什么任务适合AI什么不适合不是所有代码都适合AI生成。我总结了一个简单的判断标准任务类型适合度原因样板代码、CRUD高模式固定模型见过大量类似代码工具函数、格式化高逻辑独立边界清晰复杂业务逻辑中需要规格约束否则容易跑偏架构设计低需要全局视野模型容易局部最优性能敏感代码低模型不懂你的真实瓶颈安全相关代码极低幻觉可能导致严重漏洞把AI用在它擅长的地方而不是指望它包办一切。这是控制Token成本的第一原则。6.2 建立“生成-校验-修复”的闭环我的标准流程是这样的写规格用几百字描述清楚要做什么、约束是什么。生成代码让模型基于规格生成要求它同时输出关键决策的理由。自动校验跑Lint、类型检查、单元测试。定向修复把校验报错分组喂回模型限定修改范围。人工审查只看业务逻辑和架构合理性低级问题已被自动挡掉。沉淀上下文把这次的新约束补充进CLAUDE.md下次复用。这个闭环跑顺之后我的Token消耗结构发生了明显变化修复循环占比从46%降到了20%左右规格和生成占比上升。总消耗没降多少但有效产出大幅提升。6.3 团队协作中的Token管理如果是团队使用Token管理就更重要了。我们团队的做法是共享一份CLAUDE.md统一项目上下文避免每个人重复投喂。建立常用规格模板库新功能先找模板改而不是从零写。定期复盘Token消耗找出异常高的任务分析是规格没写好还是任务本身不适合AI。把Lint和测试作为强制关卡不通过不允许提交从源头减少返工。Token不是省出来的是管出来的。管住上下文、管住校验、管住任务边界成本自然就下来了。7. 写在最后Code is cheap但判断力越来越贵回到标题。100亿Token烧完我最大的体会不是“AI不好用”而是**“代码”这个词被偷换了概念**。AI让“代码字符”变便宜了但让“正确的代码”变贵了。因为生成越快筛选和验证的压力越大候选方案越多做决策的认知成本越高。真正稀缺的从来不是代码而是知道要写什么代码、知道写出来的代码对不对、知道什么时候不该用AI。这些判断力AI替代不了反而因为AI的普及变得更值钱。如果你也在用AI编程我的建议是别被“Code is cheap”带偏把省下来的时间投到规格、校验和架构思考上。Token会花完但判断力会一直跟着你。