Superpowers Writing Plans实操：计划写对了Token省一半

为什么你的Superpowers消耗Token那么多

用Superpowers做Vibe Coding时，很多人发现Token消耗惊人。表面上看是执行阶段烧的Token，但根本原因往往出在计划阶段——计划没写好，后续执行就会反复试错，Token白白浪费。

Vibe Coding是指开发者以自然语言描述意图、由AI完成大部分代码生成的编程范式。在这种模式下，Token消耗与任务质量之间存在强相关性：每一次AI的"猜测失败"都意味着额外的上下文填充、错误修复和重新生成，而这些都以Token计费。大语言模型的上下文窗口（Context Window）是有限的，当错误代码和修复记录不断堆积时，不仅消耗Token，还会稀释有效信息的比例，导致后续输出质量进一步下降——形成恶性循环。

本文通过一个实战项目，详细讲解如何正确使用Superpowers的Writing Plans技能，让AI生成高质量的开发计划，从源头控制Token消耗。

前情回顾：从头脑风暴到技术选型

在前一阶段，我们已经用Superpowers的头脑风暴技能完成了需求分析，产出了项目规格文档，并做好了技术选型。项目概况如下：

• 项目目标：开发一个Bug采集工具
• 核心功能：从多个数据源采集Bug信息
• 显示方式：命令行/TUI模式
• 开发语言：Rust

规格文档已经就绪，现在进入Writing Plans的实操环节。

理解Writing Plans的本质：计划细致到包含代码实现

首先要明确一个关键认知：Superpowers生成的计划是非常细致的，里面包含了具体的代码实现。这意味着，如果计划中的代码是错的，后果将是灾难性的。

大模型写代码的本质是概率推测

经常用AI编码的开发者应该都有体会：大模型写代码本质上是基于训练数据的概率推测。大语言模型生成代码的底层机制是基于海量训练语料的条件概率预测——模型并不"理解"代码逻辑，而是在预测"在这个上下文之后，最可能出现什么token序列"。GitHub、Stack Overflow、开源仓库等构成了训练语料的主体，因此React、Python标准库、常见REST模式等高频内容的生成质量远高于小众SDK或私有API。这种数据分布不均的现象被称为"训练数据偏差"（Training Data Bias）。对于主流技术栈，训练充分，输出质量较高；但对于小众场景（训练数据不足的领域），模型会倾向于"幻觉式补全"——生成看似合理但实际错误的API调用、参数名或返回结构，且模型本身无法感知这种错误，出错概率极高。

错误计划引发的连锁反应

如果拿着一个"方向正确但细节实现错误"的计划进入执行阶段，会发生什么？

1. 最好的情况：执行阶段的AI发现报错并修复——但这本身就浪费了大量Token
2. 最坏的情况：测试用例本身就是错的，AI所有的努力都在满足一个错误的测试用例，即使最终"通过"了测试，实际结果也与正确答案越来越远

结论很明确：想省Token，计划阶段就不能让AI产生错误的、误导性的代码。

实战：识别AI最容易出错的地方

回到Bug采集工具项目，AI最容易出错的地方是什么？

做减法原则

热门技术栈（如Rust标准库、常见框架）AI都训练过，这些不需要额外赘述。但要注意，给太多冗余信息也不是好事——关键是精准补充AI不知道的部分。

找到真正的盲区

在这个项目中，AI最容易出错的地方是Bug数据源的API规范。这些API文档在训练数据中覆盖有限，如果让AI盲写，几乎百分之百会出错。

解决方案：让AI参考文档写计划

解决方法很直接：把需要对接的三个数据源的API文档下载到本地，让AI参考文档来写计划。

具体操作步骤

第一步：用Default命令获取API文档

之前在「支出控制」章节讲到的Default命令，很多URL转Markdown的工具都是封装的它。直接在窗口中用感叹号执行命令，命令输出会填充到编辑器的上下文中。

API文档做了分页处理，直接下载到本地即可。

第二步：避免污染上下文

下载完成后，回到对话中告知AI文档已采集完毕。这里需要特别注意"上下文污染"问题：上下文窗口（Context Window）是大模型在单次推理中能处理的最大token数量，目前主流模型从32K到200K不等。API文档下载过程可能产生大量中间输出（如HTTP响应头、分页元数据等），若直接保留在对话流中，这些噪声会占用宝贵的上下文空间，并可能误导模型对文档结构的理解。将下载步骤与计划生成步骤隔离，是一种标准的"上下文卫生"（Context Hygiene）实践，能确保后续上下文窗口中只有高质量的有效信息。

第三步：先修复规格文件

在正式写计划之前，先让AI参考API文档修复规格文件中的错误部分。规格文档（Specification Document，简称Spec）是连接需求与实现的桥梁，在AI辅助开发流程中，它不仅是人类开发者的参考，更是AI生成代码时的"锚点"。一份准确的Spec能将模型的输出空间从"所有可能的实现"收窄到"符合业务约束的实现"，从而大幅提升生成质量。反之，Spec中的错误会被AI忠实地"放大"——模型会基于错误前提生成自洽但错误的代码，且越往后执行，偏差越难纠正。这也是"先修规格、再写计划"这一步骤的核心价值所在。

第四步：生成计划

修复完成后，正式让AI生成开发计划。最终生成的计划达到了2000多行，涵盖了详细的实现细节。

模型选择与成本优化策略

本节使用Claude 3.5 Sonnet（KM2.6）来生成计划。但在下一阶段的执行环节，将切换到MiniMax 2.5来实际编码。

这里引入了一个重要概念——顾问者模式。这是AI工程领域逐渐成型的一种多模型协作架构：用高能力、高成本的模型（如Claude 3.5 Sonnet、GPT-4o）负责规划、审查和关键决策，用低成本、高速度的模型（如MiniMax、Haiku、Gemini Flash）负责批量执行和重复性任务。这一策略的经济学逻辑类似于企业中"战略顾问+执行团队