夜雨聆风用 PDLC 写项目，少不了被问一句：文档一堆，PRD、设计、评审一路下来，token 不烧爆吗？
这问题不是没道理——流程拆得细、每步都留产物，看着确实比"直接让 AI 把代码写出来"费。但要我说，不能把 token 烧得凶这笔账算到文档头上。
先把结论摆前面：第一，文档多和 token 烧得凶，不是一回事；第二，就算真要省 token，办法是把工具用对，而不是把文档砍掉。
我没精确测过 token，没拿同一个项目跑两遍"有文档 vs 没文档"的对比，算不出漂亮的百分比。讲的是体感和方法。
烧 token 的锅，不在 PDLC
把账算清楚之前，先得找对欠债的。
烧 token 这件事，大多数时候不是 PDLC 带来的，是工具用得不对。这里的"不对"很具体，就三块：
•上下文：该清的不清。一个对话从早开到晚，几万字的历史每一轮都在重算，你问的是新问题，付的是旧账。
•提示词：写得含糊。AI 来回猜你到底要什么，一次能说清的事，问三轮才对上。
•工具调用：动不动让它通读整个仓库，其实你只改一个文件。
再加一条最常见的：能省 token 的方法压根没用上，然后回头怪流程重。
把这些账不能算到"PDLC 文档多"头上。文档安安静静躺在 docs/ 里，不会主动烧你一个 token；真正烧的是上面这几种用法。
真正烧 token 的，是返工
我自己用下来，最烧 token 的从来不是生成文档，是返工。
方向错了重写、需求理解偏了推倒、改完这块发现那块连带坏了再回头——这种来回，每一轮都是实打实的 token。生成一份 PRD 是一次性的支出；方向错了返工，是会复利的。
PDLC 这套看着重的流程，恰恰是拿"前面多写一点"换"后面少返工"。用了之后，整体流程稳、最后的产出也稳，不至于来回改。少返工，本身就是少烧 token。
所以我的看法是：文档不是成本，是资产。它把设计决策、为什么这么做都留了痕，可以回溯、可以审计。下次 AI 接手，读一遍文档就懂，不用我从头再讲一遍——这一段省下来的，又是 token。
那 token 到底该省在哪
省 token 不是不写文档，是省在该省的地方。我机器上实际在用的，大概这几处：
•降上下文：该清就清，别让一个对话拖着几万字历史硬跑。
•模型分层：别大炮打蚊子。探索、搜索、读文件这种粗活，交给便宜的小模型；真正要动脑的分析、写代码，才上最强的那档。
•精准读文件：只读跟这次改动相关的，别张口就"通读整个项目"。
•prompt caching：能命中缓存的部分按折扣计费，而且不是 1:1 的线性关系，用好了省得明显。
•给日常命令套层 token 代理：像 git status 这类高频操作，输出压一压，积少成多。
•并行：互不依赖的活儿一次发出去，少几轮往返。
这几条里，没有一条是"少写文档"。
它不是所有场景都得上满
话说回来，PDLC 也不是什么改动都得走全套。
一行小 bug，你要不要 PRD、要不要设计评审？看情况，多数时候没必要走重流程，该简化就简化。判断标准很朴素：这个改动值不值得为它留一份资产。值，就走全套；一次性的小修小补，裁掉几步也没人怪你。
还有"省 token = 省钱"这句，得分计费方式说，不然容易误导人：
•包月订阅那种固定额度的，你省的是额度窗口——省下来的 token，让你同样的钱干更多的活。
•按量计费的 API，你省的是真金白银，每个 token 都直接进账单。
这两种我都在用。先搞清楚自己是哪一种，才知道"省 token"对你到底意味着什么。
最后
总结下，文档多，不等于烧 token；真要省，省在工具用法上，不在文档上。
我最想说的一句：文档是资产，不是成本。想靠"不写文档、直接让 AI 出代码"来省 token，短期看着是省了，项目走不远——没有留痕、没有回溯，过两个月你自己都说不清当初为什么这么设计，那时候的返工，比你省下的那点文档 token 烧得狠多了。
今天能做的一个动作：回头看自己有没有把省 token 的方法用上——上下文降了吗？模型还是一律上最强的，没分层？该省的成本省了吗？顺手再想想，PDLC 你是不是也没用好。
省 token 这事拆开能讲的还有不少，比如模型到底怎么分层、上下文什么时候该清、caching 怎么吃到折扣，下次挑一个聊细一点。
