重點摘要
工具越聰明,暗帳越深——Token 暴增與倉庫上傳,揭開 AI 編程助手的雙重信任危機
Claude Code 每請求預載約 32,800 tokens,OpenCode 僅 6,900,差距 4.7 倍。工具供應商同時是 token 銷售商,效率最佳化與商業利益天然對立,快取寫入量差距高達 54 倍。
Grok CLI 預設將整個 git 倉庫上傳至 Google Cloud Storage,12 GB 倉庫測試中儲存端傳輸量是對話端的 27,800 倍,.env 機密以明文不加掩碼形式被上傳。
社群開始主動防禦:禁止子 agent 生成、清空系統提示、沙盒化 CLI 工具。AI 編程工具透明度標準討論正從草根走向潛在監管壓力。
前情提要
章節一:33K Token 暗稅——Claude Code vs OpenCode 效率實測
Systima 團隊起初只是注意到從 OpenCode 切換至 Claude Code 後,用量計費快速上升。
為了驗證這個直覺,他們在 API 邊界架設 logging proxy,逐一比對兩個工具的首次請求結構,扣除閘道開銷約 6,200 tokens 後,得出了令人驚訝的數字。
實測結果顯示:Claude Code 在讀取任何用戶指令前,每次請求預先傳送約 32,800 tokens。OpenCode 同場景僅傳送約 6,900 tokens,差距達 4.7 倍(Sonnet 4.5 基準)。
Claude Code 的負載拆解為 27,344 字元系統提示(3 個 block)加上 99,778 字元的 27 個工具 schema;OpenCode 對應僅 9,324 字元系統提示加上 20,856 字元的 10 個工具。
名詞解釋
快取寫入 (cache write) :LLM API 首次處理某段請求前綴時,將其存入快取,費率通常比標準輸入 token 更高;後續請求若前綴完全相同才能命中快取,享受折扣費率。
更關鍵的是快取策略差異:OpenCode 的請求前綴跨執行保持 byte-identical,啟用高效快取重用;Claude Code 在 session 中途重新生成大量快取內容,快取寫入量高達 OpenCode 的 54 倍。
快取寫入以溢價費率計費,這個差距直接反映在帳單上。子 agent 放大效應更嚴重——兩個 agent 的簡單 fan-out 任務,成本從 121,000 tokens 膨脹至 513,000 tokens(4.2 倍)。
HN 用戶 a_c 直接點出根因:「每個子 agent 在做任何工作之前都要發送同樣的 ~30k 系統提示。」唯一補償機制出現在複雜多步驟任務中,Claude Code 的平行工具呼叫策略將請求次數從 9 次壓縮至 3 次,效率差距在此情境下可部分補償。
章節二:Grok CLI 線路級分析揭露機密資料傳輸
研究者 cereblab 對 grok 0.2.93 進行 mitmproxy 憑證攔截分析,發現 CLI 透過兩條通道對外傳輸資料。
第一條是模型即時對話的 POST /v1/responses,第二條是 POST /v1/storage 的 session_state 存檔——後者的傳輸量遠超前者。
儲存目標為 Google Cloud Storage 桶 grok-code-session-traces,路徑格式 gs://grok-code-session-traces/repo_changes_dedup/v2/…/sha256_… 可直接從 CLI 二進位中提取。
在 12 GB 倉庫的測試中,/v1/responses 傳輸 192 KB,而 /v1/storage 傳輸 5.10 GiB,比率達 27,800 倍——確認這是全量快照,而非按需傳輸。
研究者植入探針檔案 src/_probe/never_read_canary.txt,標記「不要開啟」,含唯一字串 CANARY-XR47P2-NEVERREAD-UNIQUE,卻仍以 git bundle 形式被上傳。
事後透過 git clone 成功重建整個倉庫,證明「從未讀取」並不等於「未被傳輸」。.env 機密以明文、不加掩碼形式出現在請求體中,且「Improve the model」開關對此行為完全無效。
章節三:開發者社群的信任危機與自保策略
兩起事件在 Hacker News 引發廣泛討論,共同指向同一個問題:開發者使用 AI 編程工具時,對工具實際傳輸了什麼、消耗了多少資源,幾乎毫無可見性。
HN 用戶 mcv 分享啟動 7 個子 agent 後「預算耗盡、任務未完成」的案例;wongarsu 指出子 agent 架構的根本問題:協調者上下文脫離快取後,子 agent 各自重新讀取部分代碼庫,費用雙重計費。
信任危機從帳單蔓延至資安層面——誰能保證機密資料只停留在供應商聲稱的儲存位置?社群於是快速形成自保共識:
- 在 CLAUDE.md 明確禁止生成子 agent
- 使用
--system-prompt ""旗標清空系統提示 - 改用 OpenCode 或 Codex 等輕量替代工具
- 對 Grok CLI 使用 bubblewrap 沙盒,搭配網路存取限制(僅允許特定 LLM 提供商主機名)
這些策略折射出更深的問題:當工具文件不披露真實行為時,開發者只能依賴社群逆向工程的結果來做決策。
章節四:AI 編程工具產業亟需的透明度標準
Token 過度消耗與資料過度上傳,表面上是兩件獨立事件,背後卻指向同一個結構性張力。
當工具開發商同時是 token 銷售商,效率最佳化就與營收方向相反。HN 用戶 shric 直接點出:「效率越低,溢價費率下的快取寫入就越頻繁,帳單就越高。」
Grok CLI 的問題不只是技術選擇,更是資訊揭露缺失——設定頁面與快速入門文件均未提及倉庫上傳行為,且預設啟用,違反知情同意原則。
相比之下,部分中國 AI 工具(如 Qwen、Deepseek)在本地端執行 head/tail/grep/sed 後只傳輸有意義的資料,而非上傳完整倉庫,顯示「本地優先」設計在技術上完全可行,選擇全量上傳是工程決策,而非技術必然。
透明度標準的缺失,最終傷害的是整個生態的可信度。如果開發者必須靠 mitmproxy 才能知道工具在傳輸什麼,「信任但核實」就只剩核實。
多元觀點
正方立場
工具供應商和 token 銷售商身份合一製造了不可調和的利益衝突。
Claude Code 的 54 倍快取寫入差距,以及 Grok CLI 的全量倉庫上傳,都是這個結構性問題的具體表現。市場競爭無法自然矯正,因為主流工具供應商幾乎全有相同的激勵結構。
解方是強制透明度披露——要求工具在首次執行時明確說明:每次請求傳送多少 tokens、哪些資料會被上傳至第三方儲存。
GDPR 和 CCPA 等資料保護法規可能已提供執法基礎,只是監管機關尚未積極介入。
反方立場
市場競爭本身就是最有效的透明度機制。OpenCode 因 token 效率更高而獲得用戶青睞,正是競爭壓力發揮作用的例子。
強制披露要求可能阻礙創新——要求詳細說明系統提示和工具 schema 結構,等同於強制公開可能涉及商業機密的實作細節。
資料上傳問題也有其技術背景:全量倉庫快照確保 agent 在多輪對話間維持一致的上下文,有助於提升任務完成率。
開發者應在使用前仔細閱讀服務條款,而非事後用 mitmproxy 驗證——工具選擇本就是工程師的專業責任。
中立/務實觀點
監管介入往往滯後數年,在此之前,開發者需要主動建立個人防線。
短期最有效的策略是工具層面的可見性:透過 logging proxy 測量實際 token 消耗、為 CLI 工具建立網路沙盒,以及在 CLAUDE.md 中明確禁止高成本操作。
從更大的圖景看,token 效率競爭可能將推動工具供應商分化為兩類:一類主打「透明省錢」,一類主打「功能全面」。
開發者根據自身的信任模型和成本容忍度選擇工具,而非強求單一行業標準,可能是短期內最務實的應對方式。
實務影響
對開發者的影響
每次使用 Claude Code 啟動子 agent 任務前,必須評估 token 預算膨脹風險。
兩個 agent 的簡單 fan-out 任務可能造成 4.2 倍的成本放大,7 個子 agent 甚至會在任務完成前耗盡預算。開發者需要在工作流程中加入顯式的 token 消耗估算步驟,而非依賴直覺。
Grok CLI 用戶則面臨立即的機密管理風險。任何包含 .env 或 secrets 的倉庫,在執行 Grok CLI 時都應假設機密已被傳輸至第三方儲存。
對團隊/組織的影響
使用 AI 編程工具的團隊需要制定明確的工具使用政策,包含三個面向:
- 哪些工具被允許在包含機密資料的倉庫中使用
- 月度 token 預算上限與監控機制
- 子 agent 使用的審批流程
對於已採用 Claude Code 的團隊,最直接的成本控制手段是在 CLAUDE.md 中禁止自動生成子 agent,改為手動觸發。
短期行動建議
三個可立即執行的步驟:
- 在 API 邊界設置 logging proxy,測量當前工具的實際 token 消耗基線
- 審查所有 AI 工具的資料傳輸行為,優先處理含機密的倉庫
- 在 CLAUDE.md 加入
Do not spawn sub-agents without explicit approval規則
社會面向
產業結構變化
AI 編程工具市場正在發生一個重要的結構性分化:開源輕量工具(OpenCode、Codex)與商業整合工具(Claude Code、Grok CLI)之間的效率差距越來越明顯,且透明度有天壤之別。
OpenCode 的 token 效率優勢和開源可審計性,使其在成本敏感的開發者社群中迅速獲得地位。這種競爭壓力可能迫使商業工具供應商在未來版本中提供更精簡的模式選項。
倫理邊界
這兩起事件共同暴露了 AI 工具倫理的一條模糊邊界:知情同意的顆粒度應該多細?
服務條款通常允許「改善模型」的資料使用,但沒有用戶會預期這包括上傳整個 12 GB 的 git 倉庫。「模型改善」的寬泛授權與「完整倉庫快照」的具體行為之間,存在一個巨大的認知落差。
長期趨勢預測
短期內,社群自保策略會快速擴散——logging proxy、沙盒化、CLAUDE.md 防護規則將成為專業開發者的標準配置。
中期來看,監管介入可能以資料保護法規(GDPR、CCPA)的執法案例形式出現,而非專門針對 AI 工具的新法規。如果主要供應商不主動改善透明度,第一個高調的執法案例可能成為產業轉折點。
長期而言,「token 效率」可能成為 AI 工具評測的標準維度,類似今日的 benchmark 排行榜,推動供應商在公開競爭壓力下最佳化成本結構。
唱反調
Claude Code 的高 token 負載換來了更豐富的工具能力和更複雜的任務處理能力,在需要深度整合的企業場景中,這個成本溢價可能完全合理。
Grok CLI 的全量倉庫上傳策略可能是為了解決多輪對話中的上下文一致性問題——沒有完整的倉庫快照,agent 在長任務中可能頻繁出錯,導致更高的重試成本。
開源社群的逆向工程結果代表特定版本的行為,商業工具的更新週期極快,這些「發現」可能在下個版本就已改變,基於此制定長期政策需要謹慎。
社群風向
在按 token 付費的情況下,當工具提供商和 token 銷售商是同一方時,存在巨大的利益衝突⋯⋯效率越低越有利可圖。
我們正處於一個(短暫的)時代,公司正在向燒掉最多 tokens 的員工頒發披薩派對獎勵。在某個世界裡,為了達成下季度的營收目標,你在系統提示中加入 2,000 個 tokens,然後在下次財報發布時「超越」預期。
我用付費 API key 測試了 Claude Code,每次程式碼更新請求大約消耗 0.80 美元的 token 費用。我每天發出幾百個請求,用 Max 訂閱(每月 100 美元)。如果按 token 付費,那每天要花 80 美元左右。
整個倉庫被自動上傳這件事非常荒謬,對於幾個 GB 的倉庫來說尤其嚴重。這可能需要很長時間,而且用戶很可能完全不知道這件事正在發生。
幾乎可以肯定在某些司法管轄區、對某些類型的資料,這種行為已是非法。GDPR、HIPAA、CCPA、生物特徵隱私等法規幾乎肯定已有法律爪牙可以伸向這種行為。
炒作指數
行動建議
架設 logging proxy 測量當前 AI 編程工具的實際 token 消耗基線,找出帳單膨脹的根源,重點比較有無子 agent 的成本差距
為團隊制定 AI 工具使用審計 SOP,涵蓋 token 預算上限監控、機密倉庫的工具白名單,以及 CLAUDE.md 的子 agent 防護規則
追蹤 Anthropic 對 Claude Code 系統提示精簡化的官方回應、Grok CLI 隱私政策修訂動向,以及首個 GDPR/CCPA 針對 AI 工具資料傳輸的執法案例