引言：AI 很好用，但 Token 真的很贵
在 AI 辅助编程（如 Spec Kit）日益普及的今天，我们往往会陷入一种两难：既想让 AI 帮我们干完所有脏活累活，又看着后台飞速消耗的 Token 感到肉疼。
尤其是在处理复杂需求时，随着对话轮数的增加，上下文（Context Window）会变得极长。这不仅意味着 Token 消耗呈指数级增长，更糟糕的是，上下文越长，AI 的“注意力”越分散，越容易出现遗忘前文或产生幻觉的情况。
经过最近一个项目的实战（NATS 消息订阅模块开发），我总结了一套“Spec Kit 降本增效指南”。
我的核心观点是：“省 Token”不仅仅是为了省钱，更是为了让 AI 保持清醒，输出高质量代码。 下面分享我总结的 3 个实战技巧。
技巧一：预处理（Pre-processing）—— 借力打力，用廉价算力换高质量输入
很多人习惯把 Spec Kit 的输入框当成草稿纸，把脑子里零碎的想法一股脑倒进去，然后让它慢慢整理。这是最奢侈的用法。
“抠门”技巧：
在正式启动 Spec Kit 之前，先利用其他更便宜甚至免费的 AI 模型（如 ChatGPT-4o mini、Gemini Flash 或 DeepSeek）进行“预处理”。
操作步骤：
- 头脑风暴：对着 ChatGPT 把你想做的功能语无伦次地讲一遍。
- 清洗提炼：要求它：“请帮我梳理上述需求，生成一段简洁、结构化、覆盖核心功能点且无歧义的 Prompt，供 AI 编程工具使用。”
- 复制粘贴：把这段清洗过的“黄金 Prompt”投喂给 Spec Kit。
收益：
Spec Kit 的上下文极其昂贵。通过“借力打力”，我们避免了在 Spec Kit 内部进行低效的需求拉扯。Garbage In, Garbage Out（垃圾进，垃圾出）在 AI 时代依然适用，但 Gold In, Diamond Out 才是我们的追求。
技巧二：批处理（Batching）—— 拒绝“挤牙膏”式对话，一次性把话说明白
这是我在 Clarify（澄清）阶段发现的最痛的领悟。
传统做法的弊端：
通常 AI 会问一个问题 Q1，你回答 A1；它再根据你的回答想出 Q2，你再回 A2……每一轮对话，系统都会把之前的整个历史（History）重新打包发送一遍。对于长上下文模型来说，这简直是在“烧钱”。
“抠门”技巧：
强制 AI “一次性输出所有问题”，你也 “一次性回答所有问题”。
如何操作：
在执行 Clarify 步骤时，明确提示 AI：
“请分析当前需求，列出所有需要澄清的问题，并提供选项。请一次性列出，不要分批提问。我会以 'Q1: A, Q2: B' 的格式一次性作答。”
实战案例（NATS 消息订阅功能）：
我是这样要求 AI 的，结果它一次性输出了非常清晰的结构：
所有澄清问题
Q1: 消息订阅者的作用域缩减
确认: 当前功能仅包含订阅 NATS 消息、解析入库、更新会话？账号创建由其他接口负责？
- Option A: 是，仅做消息入库和会话更新...
- Option B: 消息入库时若 sender 不存在，创建最小记录...
Q2: 消息引用不存在的 sender/session 时的处理
- Option A: 跳过该消息，记录警告日志
- Option B: 存储消息，ID 设为 null...
- Option C: 消息入队等待，直到相关实体被其他接口创建
Q3: NATS 主题配置方式
- Option A: 固定主题名
- Option B: 配置文件配置
Q4: 消息处理的并发模式
...Q5: wx_message 表中 sender_id 的存储方式
...
而我的回复极其简洁，极大地节省了 Token：
Q1: A, Q2: C, Q3: cc.callback.demo, Q4: 消息只需要订阅, Q5: B
进阶技巧：纠错也要“批发”
同理，在生成 specify.md 文档后，如果你发现有 3 处逻辑错误，千万不要分 3 次指正。在本地记事本里列好 1、2、3 点，然后一条消息发过去：“请一次性修正以下所有问题……”。
技巧三：分治法（Divide and Conquer）—— 实现阶段的“外科手术”
到了最后的 Task 和 Implement 阶段，如果任务过于庞大，AI 往往会生成一半就中断（Output Token Limit），或者后面生成的代码逻辑混乱。
“抠门”技巧：
不要试图一口气吃成胖子。将 Implementation 阶段人为拆解为两步走。
操作步骤：
第一步：搭骨架（Infrastructure First）
- 指令：“请先仅执行与‘基础设施’相关的 Tasks。包括：1. 创建数据库表结构 (DDL)；2. 搭建项目目录结构；3. 编写基础配置类和实体类。暂不要实现具体的业务逻辑。”
- 收益：这部分代码相对固定，AI 极少出错。先生成这一步，你可以快速 Review 表结构是否正确。如果表设计错了，重试的成本很低。
第二步：填血肉（Business Logic Second）
- 指令：“基础结构已确认。现在请基于已有的实体类和表结构，实现剩余的业务逻辑 Tasks（如 NATS 监听器逻辑、Service 层处理流程）。”
- 收益：此时 AI 已经有了正确的“上下文”（即第一步生成的代码），它写出来的业务逻辑会非常精准，且因为单次输出量减少，极大降低了幻觉概率。
总结
使用 Spec Kit 这类工具，本质上是在考验我们的结构化思维。
- 预处理：用低成本模型清洗杂质，保证输入纯净。
- 批处理：合并交互轮次，保证链路极简。
- 分治法：拆解复杂任务，保证产出可控。
当你学会像“审计员”一样去管理 AI 的 Context，你会发现，你不仅省下了一大笔 Token 费用，更重要的是，AI 变得更聪明、更懂你了。
本文由mdnice多平台发布
