Token 花在哪，能力就长在哪

2026-09-20 · Mini Mall 项目复盘

写给未来的我：当我又一次觉得"流程很完整、产出很有限"时，回来读这篇。

一、先说遇到的问题

做 Mini Mall——一个走通"浏览商品 → 注册登录 → 购物车 → 下单 → 模拟支付 → 后台管理"的迷你电商——我耗掉了几个亿 Token。

先澄清一个容易误会的地方：这几个亿里，模型实验、废弃会话、反复试错才是大头，计划文档本身只占零头——前者是付钱买判断力，后者才是交的税，性质完全不同。所以这篇文章不是在算 Token 总量，而是在算去向：每一笔消耗，最后沉淀成了什么。

项目做完之后，我看到别人的同类项目：工程量大约是我的 1/5 甚至 1/10，做出来的页面和功能，看起来跟我的差不多。面对这个对比，有两种现成的解释。一种是"我浪费了"。另一种是"看起来差不多，不等于一样"——我的代码在边界处理、安全、权限、数据一致性、测试这些地方确实更扎实，这不是自我安慰。两种解释都不算错，但它们都没有回答我真正关心的问题：

在烧掉的那几个亿 Token 里，有多少沉淀成了代码质量和工程认知，又有多少只是堆积进了越来越详细的计划和流程？

这篇复盘只回答这一个问题。

二、我原本为什么这么做

这个项目起步是一个 Demo，规模不大：6 张表、24 个种子商品，没有并发、没有分布式。开始做之后，我主动做了一个决定：既然要认真做，就把自己查阅到的真实工程实践和 AI Coding 工作流带进这个个人项目，按照我理解的企业级工程方式来做——先设计后编码，核心逻辑写单元测试，边界认真对待，决策记录在案。

这个决定本身没有问题。事实是，后面的代码质量正是靠它撑起来的。

问题出在别的地方。

三、计划是怎么一步一步做大的

先看项目 docs/ 目录的真实清单：

▼
text
复制代码
PLAN.md        233 行    总计划
PLAN_V0.md     355 行    阶段 0 执行记录
PLAN_V1.md     906 行    阶段 1 计划
PLAN_V1.1.md  1021 行    阶段 1 计划修订（只改执行流程）
PLAN_V1.2.md   368 行    阶段 1 执行记录
PLAN_V2.md     799 行    阶段 2 计划
PLAN_V2.1.md   268 行    阶段 2 执行记录
...

一个"认证"阶段（11 个任务），我为它写了 906 行计划：每个任务做什么、跑什么命令、期望输出是什么，乃至实现代码，都逐段誊进了计划。之后为了调整执行方式，又写了 1021 行的修订版，序言里白纸黑字："只改执行流程，不改交付范围。"执行完，再写 368 行执行记录。

计划里留着一个当时的实测数字：某个任务需要产出 31 行代码——计划里已经逐字写好的 31 行。实施者花了 50 秒、2 万 Token 把它们抄出来；审查者又花 54 秒、2.7 万 Token 把这次抄写审了一遍；中间还有一次等人的停顿。我当时得出的结论是："慢的不是范围，是颗粒度。"

现在回头看，这句话只归因了颗粒度，却没有问一句：那 31 行已经写好的代码，当初为什么要誊进计划？

四、真正的问题：计划超过了项目的需要

难就难在，那套计划里的每一步，单独看都有道理。

计划细一点，执行时的歧义就少一点。多一次 Review，灌进来的缺陷就少一点。多一个 Pause 点，方向跑偏的概率就低一点。每一次增加，都感觉是在提高确定性——每一种感觉都是真的。

但这些"小幅增加"叠加起来，发生了两件事。

第一件：**计划从工具变成了目的。**一开始是"为了让项目有序完成而制定计划"，后来变成"为了让计划完整而不断完善计划"。再往后，为了保证计划被正确执行，设计执行流程；为了保证执行流程被遵守，安排 Review、Pause 和验收；为了验证流程本身，再设计验证流程。一环扣一环，每一步都合理。结果是，一个 6 张表的项目，被 3,950 行过程文档驱动着往前走。规范服务项目，慢慢变成了项目服务流程。

第二件：**过程成本开始超过它保护的东西。**阶段 2 的验收是现成的例子：为了验证 11 条验收项，我写了一个探针脚本，脚本从 v1 改到 v5，出了 8 个 bug——正则吞掉点号、grep -c 的返回值被当成"不存在"、断言取反写反。8 个 bug 没有一个出在应用上，全是验收工具自己的问题。调试这个工具花的时间，超过了写应用本身。

到这里我终于看清了当时的处境：计划本来是为了降低开发成本，后来却变成了开发成本的一部分。

而且这和项目是不是 Demo 没有关系。就算这是一个真正的企业项目，我也一样可能把计划做过头。真正的问题不是工程标准太高，而是我渐渐失去了判断：这个标准当初为什么存在？在这个场景里，它现在还值这个成本吗？

五、不是所有多花的 Token 都是浪费

复盘的时候，我差点把这个结论推过头，把多花的 Token 全算成浪费。两件事把我拦住了。

第一件是 safeNextPath。登录成功后的跳转参数 next 不能允许站外地址，这是个典型的开放重定向问题。我前后做了三轮攻防：第一版的 startsWith("/") 判断被 //evil.com、/\evil.com、带 TAB 字符的载荷打穿；换成 origin 比对，又被 http://internal.invalid//evil.com 这种构造打穿；最后收敛成一个不变式——输入和输出都必须是纯相对路径。收尾时用 37 条载荷对抗扫描，0 条逃逸。

这三轮没有一轮白花：它改的是真实代码，给我的是真实攻击面的认知。协议相对地址、反斜杠归一化、占位 host 绕过，这些知识只在我亲手被打穿的地方长出来。到现在我还记得那些载荷的样子。

第二件是阶段末那轮十个角度的并行审查，从约 50 条原始发现里筛出三个真问题：并发注册同一邮箱会 500（实测 5 路并发、4 个 500）；超长密码会被 bcrypt 静默截断到 72 字节；JWT 校验只信 sub 字段。每一个都是真实缺陷。

这些 Token 换来的东西写进了代码，也写进了我的工程认知。这是值得的。

真正该砍的是另一类 Token：花在让计划更完整、让流程更漂亮、让过程记录更齐全上，最后没有产生对应的工程收益。

把这次项目里的 Token 消耗摊开看，无非四类：

Token 去向	最终沉淀	是否值得
探索未知、真实攻防、验证核心风险	工程认知 + 代码	值得
核心业务逻辑：权限、金额、一致性	代码质量	值得
重复规划、低风险重复 Review、流程包装	几乎没有新增能力	应该砍
为了流程而维护流程	过程复杂度	应该警惕

判断标准只有一条：这笔 Token 最后沉淀成了什么。沉淀成代码、认知、风险发现，多半值得；只沉淀成更厚的计划和更完整的流程，那就要重新算账。

六、我后来怎么改

意识到问题之后，我在后面的阶段做了几件具体的事。

阶段 3 到 5，docs/ 只新增了 3 份文档、共 378 行，全是执行记录，不再有独立的阶段计划。阶段的计划缩成 PLAN.md 里的一个小节；该拍板的决策在开工前一次性问完，执行中不再出现"决策 1/2/3、待裁定事项"。

审查从"每批次审 + 阶段末十路审 + 终审"，改成每个阶段交付前审一次；已经足够明确的任务不再重复派 Agent；验收从调试探针脚本回到手动点一遍。有意思的是，探针脚本后来回来了——阶段 6 的 9 条验收、阶段 8 的 18 项渲染探针都靠它。但那时它是验收标准稳定之后的工具选择，不再是每阶段的惯性动作。

阶段 6 以后，不再新建任何过程文档：执行记录并入 PLAN.md 对应阶段，决策一行一条进 DECISIONS.md。

项目照常做完：阶段 0 到 8 全部收官，76 个 commit，136 个单元测试全绿，最后还落地了一套完整的视觉设计系统。砍掉的全是过程，没有一件是产品。

七、最后的认识

我没有发现"认真做工程"是错的，也没有发现"企业级规范"是错的。

我发现的是：在认真做工程的过程中，我一度失去了工程判断。计划原本是工具；当我开始为了计划本身不断增加计划时，它就已经反过来消耗项目，而我没有察觉。

别人花 1/5 的 Token 做出看起来一样的东西，我的结论不是"应该照他们那样做"，而是：我的过程里确实有一部分，他们省掉省对了。

这篇文章如果只能带走一件事，就是：Token 消耗不是成本指标，Token 的沉淀方向才是。以后再写代码，少问一句"花了多少 Token"，多问一句"沉淀成了什么"。

真正的工程能力，不只是知道应该做什么，还包括知道什么时候已经够了。

练的是"企业级判断力"，不是"企业级流程表演"。