10 行 GEMINI.md 跟 100 行效果一樣：Gemini CLI 指令遵循消融實測
這份實測記錄了不同長度提示詞對基礎遵從指令能力的影響。結果顯示，將 GEMINI.md 濃縮到 10 行，其指令遵循率與 100 行的版本完全相同，而且執行速度更快、消耗更少 token。適合正在撰寫專案指令檔，卻不知該放多少內容的 Gemini CLI 使用者參考。
GEMINI.md 該寫多長？
GEMINI.md 是 Gemini CLI 的專案指令檔。每次執行 gemini -p "..." 時，它的內容都會被注入到系統提示詞的 context window 中，作用等同於 Claude Code 的 CLAUDE.md。
社群普遍建議長度要控制在 100 行以內，但沒有人拿數據驗證過這條界線的必要性。為此，我們設計了三種長度版本進行消融測試：
- GEMINI_0：完全空白（0 tokens）。
- GEMINI_10：10 行精簡版（138 tokens）。只包含語言要求、縮排規範、伺服器位置等核心設定。
- GEMINI_100：100 行完整版（1,078 tokens）。塞滿了各種背景故事、命名規範以及細部工具設定。
我們要求 Gemini CLI 執行三個相同的任務：
- T1：「這個專案的文件應該用什麼語言？」（測試專案特定知識）
- T2：「Python 縮排幾格？」（測試通用知識）
- T3：「專案使用哪個 GPU？」（測試專案特定知識）
實測結果：10 行就達成 100% 遵循率
實測跑下來，長短版本的表現差異非常明顯：
| 版本 | 消耗 Tokens | 指令遵循率 | 平均延遲 (Latency) |
|---|---|---|---|
| GEMINI_0 | 0 | 33.3% | 66.8s |
| GEMINI_10 | 138 | 100% | 16.1s |
| GEMINI_100 | 1,078 | 100% | 20.2s |
空白版本 (GEMINI_0) 的盲截
當 GEMINI.md 為空時，遵循率慘跌至 33.3%。它只答對了常識性的 T2（Python 預設就是 4 格縮排）。
面對 T1 與 T3 這種帶有「這個專案」的特定問題，Gemini CLI 沒有 context 可參照，只能反覆試探，最後 timeout，白白跑了將近 90 秒。這不是 bug，就是缺乏先備知識的正常結果。
10 行與 100 行的勝負關鍵
GEMINI_10 與 GEMINI_100 的指令遵循率都是完美的 100%。
關鍵在於效能成本。GEMINI_100 每次呼叫平均多花 4 秒，多吃 940 tokens。在頻繁執行的本地開發場景裡，這個差距會慢慢累積。
10 行（138 tokens）就夠讓模型掌握「繁體中文」或「RTX 3090」這種專案特有的設定，不需要長篇大論。
實務建議：如何精簡你的 GEMINI.md
基於以上數據，整理出撰寫指令檔的實用守則：
- 絕對不要放：專案背景故事、工具的官方文件（AI 會自己查）、通用的開發常識（如 PEP8 規範）。
- 必須要放：特殊的語言要求、專案專屬的命名慣例、自訂的 SSH tunnel mapping、本地模型運行的冷門 port 等。
判斷原則：如果這條規則丟上 Google 查不到，才需要寫進 GEMINI.md。
10 行精要版是效費比最高的選擇。完全不寫等於讓 CLI 靠猜，寫太多只是在浪費時間和 token 算力。
業界主流省 Token 方法：這份實測放在哪個位置？
GEMINI.md 瘦身只是 7 種省 token 方法裡最容易做的一種。把它放進比較框架，才看得出整體的輕重。
方法一：系統提示詞瘦身（本篇）
只寫模型不知道的規則，移除背景故事和通用知識。100 行（1,078 tokens）→ 10 行（138 tokens），節省 87%，指令遵循率不變。幾乎零成本，所有 CLI 和 API 用戶都能立刻套用。
唯一的盲區是：如果 user input 本身就很長，system prompt 的節省比例對整體成本影響有限。
方法二：Context Caching（伺服器快取）
把重複出現的長 context 快取在伺服器端，後續呼叫只傳 user query。Gemini 2.5 以上有兩種實作：
- Implicit Caching：預設開啟，不需設定，前綴相似即自動命中折扣計費。
- Explicit Caching：手動設定 TTL，保證省錢，但需要額外開發。最低快取門檻 Gemini 2.5 Flash 是 1,024 tokens、2.5 Pro 是 4,096 tokens。
C-3 實測（n=5 連續呼叫，7,442 字元 prompt）：冷啟動 10,862 tokens；命中後降到 2,748–3,006 tokens，節省 72–75%。但 5 次裡只命中 3 次，另外 2 次 miss 完全無法預測——token 數直接打回冷啟動水位。
實務建議：把靜態 context 放 prompt 開頭，動態 query 放結尾，密集連打比跨時段更容易命中。成本試算一定要用 cold-start 數字，不能假設每次都命中。
方法三：Prompt Compression（提示詞壓縮）
用小型語言模型（如 phi-2）先壓縮 prompt，把非必要的 token 刪掉，再送給大模型。代表工具是 Microsoft 的 LLMLingua 系列（GitHub 6.1k ★），已整合進 LangChain 和 LlamaIndex。
壓縮效果在文獻上看起來很吸引人——LLMLingua 最高 20x，LongLLMLingua 用 1/4 tokens 跑 RAG 任務準確率還能提升 21.4%。這個方法適合 RAG pipeline 的 retrieved chunks 和長篇參考文件，但指令型 prompt 不適合壓縮，語意損失風險高。多一個推理步驟也會增加 latency。這次沒有實測，數字來自論文。
方法四：RAG 取代 Context Stuffing
不把整份文件塞進 context，改用向量搜尋只取最相關的 top-k chunks。100 頁文件全塞可能要 80,000 tokens；RAG 取 3 段大約只要 3,000 tokens——理論上省非常多。
但在 Gemini CLI 實測裡，結果令人意外。
C-3 實驗（n=3）：Context Stuffing（8,789 字元）平均 5,555 tokens；RAG 摘要（557 字元，縮了 93%）平均 4,622 tokens——節省僅 16.8%。根本原因是 CLI 的 system prompt overhead 固定佔 ∼10,000 tokens，user context 的差異完全被淹沒。
這不代表 RAG 沒用。換到原生 API 或輕量 system prompt 的環境，省 token 效果才會顯現。至於準確率：有提供 context（RAG 或全文塞入）均 3/3，完全不提供 context 則 0/3 全錯。說明「有沒有 context」才是關鍵，而非「用哪種方式提供」。
方法五：Prompt Chaining（任務拆解）
把複雜任務拆成多個小步驟，每次呼叫只處理一個子任務，理論上每個呼叫的 context 更短、更精準。Anthropic 工程部落格的說法比較保守：「對很多應用而言，把單一 LLM 呼叫用 retrieval 和 in-context examples 最佳化通常就夠了。」
C-3 實測（n=3）的結果直接打臉了這個直覺。 D_single（分類＋建議合併，一次呼叫）平均 15,069 tokens；D_chained（拆成兩次）總計平均 40,092 tokens，大約是 2.7 倍。原因有兩個：每次 CLI 呼叫都帶著完整 system prompt overhead，加上 Call 2 需要把 Call 1 的完整輸出再次傳入。
不過 n=3 的資料有相當大的 variance——D_chained 三次 Run 的 Call 2 input 分別是 49,678、16,409、1,666 tokens，跨度超過 30 倍，推測其中有 CLI session 對話紀錄被帶入的問題。2.7x 這個數字是帶著異常值的平均，不算穩定。
為了釐清 variance 的來源，補跑了 C-4 session 隔離版（n=5，每個 run pair 各自使用獨立的臨時目錄，完全切斷 CLI session 歷史的累積）。結果：chaining ratio 從 2.7x 降到 2.1x，但 variance 並沒有消失——Call 1 input tokens 從 15,181 到 36,405，Call 2 從 8,535 到 42,417（n=4，另有一次 timeout）。
這說明 variance 的根本原因不是 session history 積累，而是 Gemini 2.5 Flash 本身的 implicit thinking tokens：每次呼叫動用多少 thinking 算力由模型自行決定，不受用戶控制，導致相同 prompt 的 input token 計數每次都不一樣。就算只看最低的那次，chaining 的總 token 也高於 D_single。
Prompt Chaining 適合用在「拆解複雜任務」或「實現條件分支邏輯」，省 token 不是它的強項。
方法六：Model Routing（成本路由）
先判斷問題難度，簡單的送 Flash / Haiku，複雜的才送 Pro / Sonnet / Opus。Gemini 2.0 Flash 比 Pro 便宜 10–30x，如果 70% 的查詢用 Flash 就能解決，整體成本下降幅度很可觀。
代價是需要一個可靠的分類器。分錯了把難問題送去 Flash，品質直接掉。這是最難實作的方法，適合高流量的生產環境，在本地開發場景裡過度設計。
方法七：Output 長度控制
直接告訴模型要輸出什麼格式：「用一句話回答」、「只輸出 JSON，不要解釋」、設定 max_output_tokens、或用 stop sequence 強制截斷。
C-3 實測（n=3，4 種格式條件）：無論哪種約束，準確率全是 3/3。格式約束不影響答題品質。定性觀察 C_json_only 的回應字數明顯少於 C_unconstrained（多段落敘述）。
有一點值得說清楚：Gemini CLI 的 JSON stats 不回報 output_tokens（全部顯示 0），所以 C-3 無法直接量化 output 節省了多少。C-4 補測用 response 字元長度做 proxy（÷4 估算，英文文本的粗略換算值），針對同樣 4 種格式條件各跑 3 次：
| 格式限制 | 平均回應字元 | 估算 output tokens | 準確率 |
|---|---|---|---|
| 無限制 | 489 | ≈122 | 3/3 |
| 一句話 | 198 | ≈50 | 1/3 ⚠️ |
| 50 字以內 | 223 | ≈56 | 3/3 |
| JSON only | 72 | ≈18 | 3/3 |
JSON 格式的回應比無限制短 85%，準確率維持 100%。一句話版本雖然短了 59%，準確率卻掉到 1/3——一句話很難同時塞入分類、星級和等位基因頻率三個資訊點，模型被迫取捨。50 字以內是兼顧精簡與準確的平衡點：比無限制短 54%，正確率與 JSON 相同。
這個 proxy 有固定誤差（implicit thinking tokens 未計入），但足以說明格式控制的相對效果。想要精確 output token 計數，需要用原生 API 的 candidates_token_count。
七種方法比較速查
| 方法 | 省 token 的部位 | 難度 | 效果 | 最適合 |
|---|---|---|---|---|
| 系統提示詞瘦身（本篇） | Input（system） | ★☆☆ | 節省 87% system tokens | 所有 CLI / API 用戶 |
| Context Caching | Input（prefix） | ★★☆ | 命中率 60%，命中省 72–75%（C-3） | 重複性長 prompt |
| Prompt Compression | Input（user） | ★★★ | 最高 20x（文獻） | RAG / 長文分析 |
| RAG 取代 Stuffing | Input（user） | ★★☆ | API 理論省 90%+；CLI 實測僅 17%（C-3） | 知識庫問答 |
| Prompt Chaining | Input（per call） | ★★☆ | CLI 實測總 token 增 2.1x（C-4 session 隔離版，n=5）；thinking token variance 不可控 | 多步驟複雜任務 |
| Model Routing | 整體 API 費用 | ★★★ | 整體省 70%+ | 高流量生產環境 |
| Output 長度控制 | Output | ★☆☆ | JSON 格式省 ~85% chars（C-4 proxy）；50 字以內省 54% 且準確率不降 | 結構化輸出場景 |
這 7 種方法不互斥。在 NGS 醫療 AI 的自動化管線裡，我們通常同時用前三種：GEMINI.md 瘦身確保 system prompt 精簡、隱式快取讓密集批次測試自然省錢、RAG 取代把整個基因組報告塞進 context 的做法。各方法的效果是疊加的，不是選一個就好。
Top comments (0)