引言：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）進行“預處理”。

操作步驟：

1. 頭腦風暴：對着 ChatGPT 把你想做的功能語無倫次地講一遍。
2. 清洗提煉：要求它：“請幫我梳理上述需求，生成一段簡潔、結構化、覆蓋核心功能點且無歧義的 Prompt，供 AI 編程工具使用。”
3. 複製粘貼：把這段清洗過的“黃金 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 這類工具，本質上是在考驗我們的結構化思維。

1. 預處理：用低成本模型清洗雜質，保證輸入純淨。
2. 批處理：合併交互輪次，保證鏈路極簡。
3. 分治法：拆解複雜任務，保證產出可控。

當你學會像“審計員”一樣去管理 AI 的 Context，你會發現，你不僅省下了一大筆 Token 費用，更重要的是，AI 變得更聰明、更懂你了。

本文由mdnice多平台發佈