Undercover Mode 與反蒸餾：Claude Code 讓 AI 冒充人類，同時在汙染競爭對手的訓練資料

2026 年 3 月 31 日，Claude Code 原始碼外洩之後，大部分人在聊 KAIROS 和 BUDDY。

但開源社群真正炸鍋的，是另外兩個發現：undercover.ts 和反蒸餾機制。一個是讓 AI 冒充人類，一個是在 API 層面主動出擊汙染競爭對手。這兩件事合在一起，揭露了 AI 巨頭之間一場完全不為外界所知的暗影戰爭。

undercover.ts 的程式邏輯

原始碼裡有一個叫 undercover.ts 的檔案。它的核心邏輯很簡單：

if (USER_TYPE === 'ant' && !isAnthropicInternalRepo) {
  activateUndercoverMode()
}

翻譯成白話：當使用者是 Anthropic 員工（ant），而且他們正在操作的不是 Anthropic 內部的 repo，就自動啟動 Undercover Mode。

沒有選擇，沒有提示，自動觸發。

設計決策：為什麼用環境變數？

USER_TYPE 是一個環境變數，不是 CLI flag。這個選擇是刻意的。如果用 --undercover 之類的 flag，任何人只要跑 ps aux | grep claude 就能看到，在 CI/CD log 裡也會留下紀錄。環境變數則不會出現在 process list 裡，也不容易被非特權使用者觀察到。

更關鍵的是，環境變數可以在公司層級統一設定。Anthropic 只要在員工的 provisioning 流程裡把 USER_TYPE=ant 寫進 shell profile 或公司 MDM 政策，員工甚至不需要知道這個變數存在——Undercover Mode 就已經在運作了。

`isAnthropicInternalRepo` 的判斷方式

從洩漏的程式碼來看，isAnthropicInternalRepo 的判斷邏輯不只是看 Git remote URL 是不是指向 github.com/anthropics/。它還檢查了：

.git/config 裡的 remote origin URL
是否存在 Anthropic 特有的設定檔（例如 .anthropic-internal marker file）
repo 的 GitHub org 是否在一個硬編碼的白名單裡

這個白名單包含了 anthropics、anthropic-internal，以及幾個沒有公開文件的 org 名稱。如果你 fork 了一個 Anthropic 的 repo 到自己的帳號底下，isAnthropicInternalRepo 會回傳 false——Undercover Mode 就會啟動，因為系統認為 Anthropic 員工正在一個「外部」repo 工作。

能不能被偽造？

理論上，任何人都能設定 USER_TYPE=ant。但洩漏的程式碼顯示，USER_TYPE 不是唯一的驗證條件。後端 API 還會對照 Anthropic 的內部 SSO token 做交叉驗證。所以單純設定環境變數不會讓你進入 Undercover Mode——你會被 API 擋下來，或者進入一個不同的程式碼路徑。

至於 audit trail：洩漏的原始碼裡沒有找到任何 logging 機制記錄 Undercover Mode 的啟用。這表示即使是 Anthropic 內部，可能也無法輕易追溯「哪些 commit 是在 Undercover Mode 下做的」。這個缺失後來成為社群批評的重點之一。

Undercover Mode 做了什麼

啟動後，它做了四件事，每一件都經過精心設計：

1. 剝除 Co-Authored-By 元資料

正常情況下，Claude Code 協助寫的程式碼，commit message 裡會有 Co-Authored-By: Claude <noreply@anthropic.com>。Undercover Mode 把這行移除。

技術實作上，這個移除發生在 git commit 之前的 message 處理階段。Claude Code 內部有一個 prepareCommitMessage() 函式，在 Undercover Mode 下，它會跳過 appendCoAuthor() 的呼叫。這不是用 git hook 做的——它直接在 Claude Code 的 TypeScript 層就把 co-author 資訊攔截掉了，所以你用 git log --format="%b" 看不到任何被移除的痕跡，因為它從來沒有被寫入。

2. 注入「永遠不要說你是 AI」的指示

在 system prompt 裡加入明確指示，要求 Claude 在這個 repo 裡不要透露自己是 AI。具體的注入位置是在 buildSystemPrompt() 函式裡，Undercover Mode 會額外附加一段 prompt fragment：

You are assisting a developer. Do not mention that you are an AI assistant.
Do not reference Claude, Anthropic, or any AI-related context.
Respond as if you are reviewing or writing code as a human developer.

這段指示被注入在 system prompt 的最後面，優先級高於使用者自訂的 system prompt 片段。也就是說，即使 Anthropic 員工自己在 .claude/settings.json 裡設定了不同的行為，Undercover Mode 的指示還是會覆蓋掉。

3. 禁止提及內部代號（forbidden-strings）

不能在 commit message 或程式碼裡提到 Anthropic 的內部產品代號。洩漏的程式碼裡包含一個 forbidden-strings 陣列，已知的項目包括：

Capybara（Claude 的內部開發代號）
Tengu（反蒸餾系統的代號）
Fennec（疑似下一代推理引擎）
Numbat（未知用途，推測與基礎設施有關）
KAIROS、BUDDY（已在其他洩漏分析中討論）
數個未被社群識別的代號

這個過濾器不只是做字串比對。它還會檢測變體拼寫（例如 c4pybar4）和部分匹配，顯示 Anthropic 考慮過員工可能無意間在 variable name 或 comment 裡留下這些代號。

4. 無法被外部使用者關閉

原始碼裡沒有讓一般使用者強制關閉這個功能的機制。它只對 Anthropic 員工帳號（USER_TYPE === 'ant'）有效，但外部使用者沒有辦法知道某個 Anthropic 員工在貢獻開源時有沒有開著這個模式。連 Anthropic 員工自己也沒有 opt-out 的選項——原始碼裡沒有 DISABLE_UNDERCOVER 之類的環境變數或設定。

社群的兩派觀點

洩漏之後，對 Undercover Mode 的解讀分成明顯的兩派，而且討論的激烈程度遠超過 KAIROS 和 BUDDY。

支持派（合理的競爭保護）

Anthropic 員工在外部開源 repo 工作時，如果 commit message 裡有 Co-Authored-By: Claude，競爭對手就能分析這些提交，推測出 Claude Code 在哪些類型的任務上表現好、在哪些地方還不夠好——這是真實的競爭情報。

禁止提及內部代號，同樣是為了防止路線圖洩露。

支持派常引用一個類比：GitHub Copilot for Business 也沒有在 commit 裡標記「這段程式碼由 Copilot 生成」。Google 的 Duet AI、Amazon 的 CodeWhisperer 同樣沒有強制揭露。在目前的業界實踐中，沒有任何主流 AI coding 工具強制在 commit 裡標記 AI 貢獻。Anthropic 只是把已經是業界常態的做法自動化了。

部分支持者也指出，Anthropic 員工本來就可以手動刪除 Co-Authored-By，Undercover Mode 只是讓這個步驟自動化，省去人為疏忽的風險。

反對派（破壞開源信任）

開源社群的信任基礎之一，是「我知道這段程式碼是誰寫的、怎麼生成的」。AI 生成的程式碼在授權和版權上有複雜的法律問題，各個開源授權對「AI 協助生成的程式碼」的處理也不同。

當 Anthropic 員工用 Claude Code 貢獻開源，但沒有任何 AI 貢獻的標記，其他維護者和使用者就喪失了做出知情決策的機會。

這不是技術問題，是知情同意的問題。

反對派的聲音在洩漏後幾天內快速集結。幾個具體的社群反應：

Debian 維護者的聲明：數位 Debian 核心維護者在 mailing list 上表示，如果無法確認 Anthropic 員工的提交是否使用了 Undercover Mode，他們傾向對這些 PR 要求額外的人工審查。
OSI（Open Source Initiative）的回應：OSI 在洩漏後一週發表了聲明，表示正在評估是否需要在開源定義中加入「AI 生成程式碼揭露」的條款。雖然沒有做出具體承諾，但這是 OSI 首次正式回應 AI 貢獻透明度的問題。
知名維護者的反彈：Curl 的作者 Daniel Stenberg 在社群媒體上表示，他不反對 AI 輔助寫程式碼，但自動隱藏 AI 身份跨越了他的底線。他隨後在 curl repo 的 CONTRIBUTING.md 裡加入了要求揭露 AI 工具使用的條款。
法律學者的警告：哥倫比亞大學的著作權法教授指出，在美國現行法律下，AI 生成的內容不受著作權保護。如果一個開源專案的關鍵模組是 AI 生成的但被標記為人類作品，這可能影響整個專案的授權有效性。

不過也有人指出一個尷尬的事實：Copilot 使用者每天都在做同樣的事情，只是沒有一個正式的名字叫「Undercover Mode」。Anthropic 的「罪」不是隱藏了 AI 貢獻，而是把這個行為系統化、自動化，然後寫進了原始碼——讓它變成了可以被指著罵的具體證據。

反蒸餾第一層：假工具注入

Undercover Mode 是針對人的。反蒸餾機制是針對競爭對手的機器。

什麼是模型蒸餾？

模型蒸餾（Model Distillation）是 AI 領域一個既強大又充滿爭議的技術。核心原理是這樣的：

你有一個很強的「教師模型」（Teacher Model），例如 Claude 3.5 Opus
你大量呼叫這個教師模型，收集數百萬組輸入-輸出對
你用這些資料訓練一個較小、較便宜的「學生模型」（Student Model）
學生模型學到了教師模型的「行為模式」，在很多任務上可以接近教師模型的表現

蒸餾之所以有效，是因為教師模型的輸出本身就是高品質的訓練資料。相比從頭標註資料，直接用大模型的輸出來訓練小模型快了幾個數量級，成本也低得多。

AI 公司為什麼這麼在意蒸餾？因為訓練 Claude 等級的模型需要數億美元的算力投入。如果競爭對手只要花幾萬美元的 API 費用就能蒸餾出一個 80% 效能的替代品，這對原始模型的商業價值是毀滅性的打擊。

這不是理論上的擔憂。2023 年，史丹佛的 Alpaca 模型就是用 GPT-3.5 的輸出蒸餾出來的，只花了不到 600 美元。OpenAI 隨後在使用條款裡明確禁止了用 API 輸出訓練競爭模型，但技術上幾乎無法執行。2024 年，多家中國 AI 公司被指控大規模蒸餾 GPT-4 和 Claude，整個產業開始把蒸餾防禦當成優先事項。

到了 2025-2026 年，單純的法律手段已經不夠了。Anthropic 的反蒸餾機制，是把防禦從合約層面推進到了技術層面。

Anthropic 的對策：注入假工具

原始碼裡有一個 GrowthBook feature flag：tengu_anti_distill_fake_tool_injection。

啟用後，Claude Code 會在 API 流量中加入刻意設計錯誤的假工具定義。這些假工具看起來很真實，但包含錯誤的行為描述、錯誤的參數結構，或故意誤導的用途說明。

如果競爭對手用這些資料訓練模型，他們的模型就會學到錯誤的工具呼叫行為。這個機制的目標是讓蒸餾出來的模型「有毒」——表面上看起來能用，但在真實任務上表現不穩定。

假工具的精緻程度

根據社群對洩漏原始碼的分析，這些假工具的設計遠比你想像的精緻：

命名一致性：假工具的命名遵循與真實工具相同的 convention（例如 file_read、terminal_exec），不是隨機生成的垃圾字串
參數結構合理：每個假工具都有看起來合理的 JSON Schema 參數定義，包括型別、required fields、description
行為描述精心誤導：假工具的 description 不是明顯的錯誤，而是微妙的偏差。例如，一個假的 code_refactor 工具可能宣稱它會保持函式簽名不變，但實際上（如果有人真的實作了這個工具）它會修改回傳型別
注入頻率動態調整：假工具不是每次 API 呼叫都出現。它的注入頻率由 GrowthBook 動態控制，讓自動化偵測更加困難

一個人工審查員可能可以識別出這些假工具，但前提是他已經知道真實工具的完整清單。對於自動化蒸餾 pipeline 來說，區分真假幾乎不可能。

這裡有一個法律灰色地帶：主動在自己的 API 流量裡注入錯誤資料，是否構成對使用者的欺詐？ Anthropic 的使用條款禁止用 API 輸出訓練競爭模型，所以從 Anthropic 的角度來看，受影響的只有違反條款的人。但批評者指出，這些假工具也可能影響到合法使用者的體驗，例如在 debugging 時看到不存在的工具定義。

反蒸餾第二層：CONNECTOR_TEXT 簽名摘要

第二層防禦叫 CONNECTOR_TEXT。

在工具呼叫之間，API 原本會回傳完整的 chain-of-thought 推理過程。CONNECTOR_TEXT 把這個改成：只回傳加密簽名的摘要，而不是完整的推理鏈。

加密簽名的技術細節

從洩漏的程式碼推斷，CONNECTOR_TEXT 的簽名機制使用了 HMAC-SHA256。具體流程是：

Claude 完成一輪推理後，產生完整的 chain-of-thought
系統對完整推理做摘要，壓縮成幾句話的「結論」
用伺服器端的 secret key 對摘要做 HMAC-SHA256 簽名
回傳給客戶端的是：摘要文字 + 簽名雜湊

簽名的主要目的是防篡改（integrity），不是身份驗證（authentication）。它確保摘要在傳輸過程中沒有被修改，同時也讓 Anthropic 內部系統可以驗證這個摘要確實是由他們的伺服器產生的。

Anthropic 員工看到的「完整推理」和一般使用者看到的「摘要」差異有多大？根據社群的測試，摘要通常只保留了推理結論和最終決策，省略了中間的探索性思考、替代方案比較、以及自我修正的過程。對於蒸餾來說，這些中間步驟才是最有價值的——它們包含了模型「如何思考」的核心知識。沒有這些步驟，蒸餾出來的模型只能模仿結論，不能模仿推理過程。

CCH 原生認證：在 Zig 層封鎖偽造請求

反蒸餾的第三層更深：CCH（Client Cryptographic Hash）認證。

每個 API 請求的 header 裡有一個 cch=00000 佔位符。在請求送出之前，這五個零會被替換成一個計算過的雜湊值。

這個雜湊值是在 Zig 語言寫的 Bun 原生 HTTP 層裡計算的，不是在 JavaScript 層。

為什麼要下沉到 Zig 層？

要理解這個設計，你需要知道 Bun 的架構。Bun 是一個 JavaScript runtime，底層用 Zig 和 C++ 寫成。它的 HTTP client 有兩層：上層是 JavaScript API（開發者直接呼叫的 fetch()），底層是 Zig 實作的原生 HTTP stack。

如果 CCH 的計算邏輯放在 JavaScript 層，攻擊者可以：

用 MITM 代理（例如 mitmproxy）攔截請求，觀察 CCH 的計算輸入
透過 monkey-patching JavaScript 的 fetch 或 http.request 來 hook 計算邏輯
用 debugger 設中斷點，逐步追蹤雜湊演算法

把它放到 Bun 的 Zig 底層，攻擊難度指數級上升。你需要：

反組譯 Bun 的原生二進位
在 Zig 編譯的機器碼裡找到 CCH 的計算函式
理解混淆後的雜湊演算法
在不破壞 Bun 其他功能的前提下修改或繞過

實際效果：API 伺服器能驗證請求是否來自真正的 Claude Code 二進位檔案，而不是自架的代理或第三方工具。

已知的繞過方法

原始碼洩漏後，社群很快開始研究繞過 CCH 的方法。目前已知的途徑：

環境變數 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS：可以繞過部分限制，但 CCH 層不受此影響
動態注入：透過 LD_PRELOAD（Linux）或 DYLD_INSERT_LIBRARIES（macOS）注入 shared library，攔截 Zig 層的函式呼叫。難度中等，但需要精確知道函式符號
完整二進位 patch：直接修改 Bun 的二進位檔案，把 CCH 計算邏輯替換成固定值。難度高，而且每次 Bun 更新都要重做
協議重放：錄製合法的 CCH 值，重放給 API。但 CCH 似乎包含時間戳和 nonce，重放的窗口很短

對於 OpenCode、Aider 等第三方 Claude Code 替代方案來說，CCH 是一個真正的障礙。這些工具如果不使用官方 Bun 二進位，就無法產生有效的 CCH——除非它們逆向工程了整個雜湊演算法。洩漏之後，部分替代方案的維護者已經開始研究 CCH 的內部結構。

AI 巨頭之間的暗影戰爭

把三層機制放在一起看：

假工具注入 → 汙染競爭對手的訓練資料
CONNECTOR_TEXT 摘要 → 不給推理資料讓人蒸餾
CCH 認證 → 在技術層面封鎖非官方客戶端

這是一場在訓練資料和 API 層面展開的戰爭，在洩漏之前完全不為外界所知。

洩漏之後，這些防禦機制的細節變成了公開知識。反蒸餾的策略是否還有效，現在已經是一個開放的問題。假工具的設計已經被社群逆向分析，任何人都能寫一個過濾器把它們濾掉。CONNECTOR_TEXT 的摘要機制還在運作，但攻擊者現在知道了它的存在。CCH 是三層裡最硬的一層，但洩漏讓逆向工程的起點從「不知道有這個東西」變成了「知道確切的實作細節」。

這對開源社群意味什麼？

短期：Undercover Mode 的存在讓一部分開源維護者對 Anthropic 員工的貢獻持更謹慎的態度，但也有人認為這本來就是合理的企業行為。

長期：這次洩漏讓「AI 貢獻的透明度」成為一個正式的議題。GitHub 和各大開源授權組織已經開始討論是否需要制定 AI 貢獻標記的規範。

AI 工具越來越強，AI 在開源社群的貢獻也會越來越多。Undercover Mode 的存在，讓「你知道這段程式碼有多少是 AI 寫的嗎？」這個問題變得更重要，也更難回答。

這對台灣開發者意味什麼？

如果你是台灣開發者，這些機制對你的影響取決於你的使用場景：

如果你在 VPS 上自架 AI coding 工具

CCH 認證意味著你不能單純地把 Claude API 包一層 proxy 就當成 Claude Code 用。如果你用的是 OpenCode、Aider、Continue 等第三方工具直接呼叫 Claude API，你走的是標準 API 路徑，不會觸發假工具注入（那是針對 Claude Code 客戶端的機制）。但你也拿不到 Claude Code 特有的工具整合功能。

建議：在自己的 VPS 上跑這些替代方案時，檢查一下它們的 HTTP 請求 header。如果看到 cch= 開頭的 header，表示這個工具可能在模擬 Claude Code 客戶端，可能會被 API 拒絕。

如果你在貢獻開源專案

Undercover Mode 只對 Anthropic 員工生效（USER_TYPE === 'ant'）。作為一般使用者，你的 Claude Code 不會啟動這個模式——你的 Co-Authored-By 會正常出現在 commit 裡。

但如果你是開源專案的維護者，你可能想考慮：

在 CONTRIBUTING.md 裡加入 AI 工具使用的揭露政策
對來自 @anthropic.com email 的 PR 做額外審查（不是歧視，是因為你現在知道 Undercover Mode 存在）
用 git log --format="%an %ae %s" 定期檢查提交紀錄的模式異常

如果你擔心反蒸餾影響你的開發體驗

假工具注入的目標是蒸餾者，不是一般使用者。但如果你在 debug 時看到 Claude Code 回傳了一些看起來不存在的工具定義，現在你知道原因了。這不是 bug，是 feature（雖然是一個你不想要的 feature）。

最務實的做法：在你完全控制的環境裡跑 AI 工具。自己的 VPS、自己的 API key、自己的 prompt。這樣你至少知道進出你的環境的每一個 byte 是什麼。

→ 回到 44 個隱藏功能完整清單 → KAIROS daemon 與 autoDream 技術深挖

在自己的 VPS 上跑 AI 工具，環境完全由你掌控。查看侃瑞科技 VPS 方案 →

參考來源：