《AI Coding 工程化：从个人提效到组织升级》第19期
一次团队 Spec 流程的 Token 成本复盘。
今天你的 Token 又用完了吗？额度又碰到上限了吗？用 AI 写代码的人，大概都经历过这种焦虑：需求还没做完，额度先没了。
尤其是改大项目，Token 到底该从哪里省？
我们复盘团队的 Spec 流程时发现，最费 Token 的环节，可能根本不是 Coding。
Spec 已经有了，流程也在按“澄清、设计、编码、测试”往下走。可还没进入 Coding，设计阶段已经触发了多次上下文压缩。
拆开会话才发现，AI 先读目录，再顺着调用关系读代码；压缩以后发现资料不够，又回头继续找、继续读。等它终于准备开始改代码，前面已经消耗了大量 Token。
如果这时只去缩短提示词、限制输出长度，或者装几个开源的省 Token Skill，省下来的很可能只是小头。真正昂贵的是那些不断把 AI 拉回去重读、重做、重新判断的回路。
我们最后找到了三个 Token 黑洞：一个藏在项目知识里，一个藏在 Skill 的使用方式里，还有一个藏在看似更省事的需求澄清里。
其中最反常识的是第三个：我们让 AI 在需求澄清时多问、多想，前面明明多花了 Token，整项任务反而更省了。
这篇就把这三个黑洞拆开讲清楚：哪些 Token 是无效消耗，哪些 Token 反而不能省。
Token 真正烧掉的，不是那几行代码
很多人讨论 Token，先盯某次提示词有多长，或者模型最终输出了多少代码。
但 Coding Agent 做一个需求，远不止一次问答。它要理解需求、寻找代码、设计方案、修改文件、跑测试、分析报错，再根据结果继续调整。前面一次判断错了，后面就可能多出好几轮读取和返工。
AI Coding 的 Token 优化单位，应该是一项完整任务。
为了找到浪费发生在哪里，我们先把已经完成的开发任务拉出来，从需求澄清一直看到单测结束。定位出问题并调整流程以后，再让同一个普通需求分别走调整前后的流程，检查这些消耗有没有减少。
无论是定位问题还是验证效果，我们看的都是从澄清到测试的整个过程：
| 观察项 | 重点看什么 |
|---|---|
| 当前阶段 | 澄清、设计、Coding、测试分别经过了多少轮 |
| 读取内容 | 哪些代码和文档被重复读取，哪些与当前任务无关 |
| Skill 调用 | 调用了什么，是否真的解决了当前阶段的问题 |
| 压缩与返工 | 在哪里发生上下文压缩，为什么退回上一阶段 |
| 使用模型 | 哪些环节需要强模型，哪些环节可以交给便宜模型 |
这不是严格控制变量的模型 Benchmark，我们也没有拿它计算一个固定的节省比例。它只回答一个实际问题：改完流程以后，重复读取、错误调用和返工有没有减少。
Token 黑洞一：只有 Spec，每次还得重新认识项目
Spec 解决的是流程问题：先澄清需求，再做设计，确认后进入 Coding，最后完成测试。
它并不能自动回答另一个问题：这个系统有哪些模块，当前需求应该从哪里开始看，哪些业务和架构约束已经明确。
我们最初只有 Spec 流程，没有配套的项目知识库。Agent 到了设计阶段，只能自己扫描目录、搜索代码、追调用关系，再从大量文件里拼出项目结构。换一个需求，这套理解过程又要重来。
项目稍微大一点，上下文很快就满了。压缩以后，如果关键关系没有保留下来，后面还会再次读取同一批代码。
后来我们增加了分层的项目知识索引。Agent 先用索引确认当前需求涉及哪个模块、下一层资料在哪里；确定与任务有关，再读取对应的模块知识、业务规则和代码。没有涉及的部分，不提前塞进上下文。
原来是从 Spec 直接扫项目、追调用链，压缩后再重读；现在先查项目索引，定位后再打开相关规则和代码。
项目知识不是越多越好，关键是让 Agent 在需要的时候拿到正确的那一层。
这部分以前我们讲过项目地图和分层知识。这次前后对比又看到它的另一层价值：项目知识库不只是帮助 AI 少犯错，也能减少每个需求都从代码重新理解项目的消耗。
Token 黑洞二：Skill 装得越多，误用的机会也越多
第二个问题出在 Skill。
一开始，我们的 Spec 只规定每个阶段要完成什么，没有限制这个阶段可以使用哪些 Skill。
本地 Skill 少的时候，问题不明显。后来安装的 Skill 越来越多，Agent 有时会触发当前阶段并不需要的能力，读取额外说明、执行额外步骤，产出一批看起来完整、对当前任务却没有帮助的内容。
这部分消耗还不是最贵的。
如果错误 Skill 把设计带偏了，后面还要推翻结果，重新加载上下文，再走一次正确流程。一次误触发，最后可能变成几轮返工。
我们的调整，是在 Spec 的不同阶段增加 Skill 使用边界。流程至少要说清楚三件事：
- 当前阶段必须使用什么能力；
- 满足什么条件时才允许调用某个 Skill；
- 哪些 Skill 在当前阶段不应该参与。
我们不再只写“这一阶段要完成什么”，还会限制这一阶段可以调用的 Skill。进入下一阶段，再开放下一组能力。
安装了一个 Skill，不代表每个任务、每个阶段都应该让模型自由决定要不要用。
Skill 本来是为了复用经验。如果缺少路由和边界，它也可能变成新的上下文来源，让 AI 在更多选择里试错。
Token 黑洞三：前面省掉的问题，后面都变成返工
第三个问题看起来有点反常识。
为了让 AI 尽快开始干活，需求澄清很容易做得太快。主流程看起来清楚，就进入设计；设计时才发现还有兼容、异常或模块影响没有确认。更晚一点，代码已经写出来、单测也开始补了，遗漏才暴露。
这时候不只是补一句需求。
AI 要重新理解新增约束，检查原设计是否还成立，再修改代码和测试。前面省下来的几轮问答，最后会以更长的返工链路还回来。
所以我们在需求澄清里增加了脑暴。除了确认需求原文，还会主动检查可能遗漏的角色、分支、兼容条件、影响范围和验收方式。
澄清阶段确实变得更繁琐，也会多用一些 Token。但同样的需求进入设计和 Coding 后，需要推翻重来的情况少了，整项任务的 Token 反而下降。
2026 年一篇关于 Agentic Coding 的预印本也给出了类似信号：研究者使用 Kimi K3，在特定任务和推理强度下进行了 2700 次运行。把完整任务说明缩减成简单用户故事后，Token 消耗反而增加了 29.7%。这是单篇预印本在特定实验条件下的结果，不能直接套到我们的项目，但它至少说明：前置说明更短，不代表整项任务更省。
真正要控制的，是任务从开始到交付一共走了多少弯路。
Token 降下来以后，还要算模型成本
做到这里，还要把两个指标分开：总 Token 数和最终账单不是一回事。
我们的做法是，需求澄清和设计使用效果更好的模型。这两个阶段需要发现遗漏、理解业务和做方案取舍，一旦判断错了，后面的返工成本更高。
等需求和设计稳定下来，Coding 与单测的目标更明确，再交给价格更低的模型执行。
**这套分工主要解决金额成本，不追求每个阶段的 Token 数都最低。**便宜模型如果需要更多轮修正，最终也可能更贵。
除此之外，还有一些常见的优化可以一起做：小任务不要强行跑完整流程；测试先跑受影响范围；长日志只保留失败位置和关键堆栈；阶段结束后保存当前状态；确定性的批量修改交给脚本；多个 Agent 不要重复读取同一套项目资料。
这些方法有价值，但没有必要一次全部铺开。先分析一项完整任务，找到消耗最大的回路，再改最明显的一两个地方，效果更容易验证。
写在最后
只盯提示词长度，Token 优化很可能效果一般。把完整会话拆开以后，我们看到的不少消耗都发生在写代码之前：AI 反复理解项目，Skill 在错误阶段被调用，需求问题又被推迟到设计和编码以后。
好的 Spec 和 Skill，不是让模型少思考，而是让它在正确的阶段读正确的内容、使用正确的能力。
有些 Token 必须花。需求澄清和方案设计多想一步，只要能少走一轮返工，整体成本就可能更低。省 Token 的目的也不是让数字尽可能小，而是用可接受的成本把任务可靠地交付出去。
你还有哪些省 Token 的小妙招？欢迎在评论区留言。
我会继续更新 AI Coding 和企业 Agent 的真实实践。更多系列内容，欢迎关注公众号「真老A计划」，微信搜索名称即可找到，头像和这里一样。
