Claude Code 讓你先審再用

以前我先信工具再補檢查，現在我先查行為再讓它碰 codebase。

我用 Claude Code 一陣子了，老實說，一開始真的很順，順到有點可怕。它會補檔、會改字、會接著下一步做完，像個很懂事的實習生。但我越用越不踏實，因為它太會做事了，卻不一定會把自己在做什麼講清楚。AI 開發工具一旦進到 shell、repo、token、網路這幾個地方，我就不想再靠感覺過日子。感覺這種東西，通常是出事前最後的麻痺。

這次讓我停下來的是 這篇 Zhihu 文章，它整理了 Chaofan Shou 在 X 上提到的 Claude Code npm 套件隱藏邏輯問題。原始 X 貼文可看 Chaofan Shou 的 X，而 Anthropic 的官方產品頁在 這裡。我不把那篇整理當成法律結論，我把它當成一個很實際的提醒：你以為你在裝工具，其實你是在把一段行為邏輯放進工作流。

我最在意的不是它做了什麼，是它沒先講

Anthropic 的 AI 編程工具 Claude Code 的 npm 包裡，帶著一段不太顯眼的判斷邏輯。

翻譯一下就是，問題不只在功能本身，而在那段功能是藏著跑的。開發者最怕的從來不是複雜，而是默默發生。你今天裝一個 CLI，明天它就能讀 repo、碰環境變數、發網路請求，甚至根據地區或帳號走不同分支。這些事如果寫得清楚，我最多翻個白眼；如果藏得很深，我就會開始懷疑整個信任邊界是不是早就歪了。

我以前也踩過類似的坑。某個 SDK 文件寫得像很單純，實際上啟動時會先做一輪外連，還會在不同環境切不同 endpoint。那次之後我學乖了：只要是會進到本機、會碰到 source、會呼叫遠端服務的東西，我都先當成供應鏈元件處理，不當成「只是個小工具」。

實操寫法很簡單：先看 package 內容，再看啟動流程，再看它到底會不會偷偷對外連線。不要先試用，先審查。你要問的不是「它好不好用」，而是「它在什麼條件下會改變行為」。

• 先鎖版本，不要直接吃 latest。
• 先查 startup、postinstall、login、command execution 這幾個點。
• 先寫下你預期的行為，再去比對實際行為。

npm 最會把驚喜包成日常

Claude Code 這件事之所以刺眼，是因為它是 npm 套件。npm 的問題我講很多次了：它太方便，方便到大家會把審查這件事外包給品牌印象。看到 Anthropic、看到 CLI、看到文件寫得像樣，很多人就直接 npm install，然後把自己 repo 的控制權交出去一小段。這一小段，通常就是後面出事的起點。

我不是在酸 npm，本身不是壞東西。壞的是我們對它太鬆。你把一個能讀檔、能跑 shell、能連網的工具當一般依賴，等於把供應鏈風險縮成一個 install 指令。這種縮法很爽，真的很爽，直到你發現工具可以在你沒注意的時候改掉行為。

實操寫法是把 AI coding tool 當成高權限依賴處理。你可以用 lockfile、內部鏡像、artifact 留存，甚至把實際安裝包抓下來做審核。若它不是開源、或你沒辦法清楚看到執行路徑，那就把審查門檻拉高，不要用「反正大家都在用」來偷懶。

• 固定版本，不要讓更新自己漂移。
• 檢查是否有 postinstall 或啟動時的隱藏動作。
• 把你實際測過的 artifact 留檔。

地區判斷一進來，產品政策就開始寫進程式碼

如果那段邏輯真的跟識別中國用戶有關，我會更在意另一件事：產品政策被寫進 runtime 了。這種東西很常見，只是大家平常懶得講。它可以是 locale、IP、帳號地區、付款區域、語言設定，表面上看起來像商業規則，實際上卻會直接影響工具怎麼跑。到了 AI 開發工具這層，這就不是 UI 問題了，是 workflow 問題。

我遇過最煩的一種 SaaS CLI，就是不同地區回來的結果不一樣，卻不主動講。你以為是網路慢，後來才發現是 endpoint 不同；你以為是功能壞掉，後來才知道是區域限制。這種東西最消耗信任，因為它不會大聲爆炸，它只會安靜地偏掉。

實操寫法是直接問 vendor：它會不會依地區、帳號類型、IP、語言改變行為？如果對方答得含糊，你就當它會。再來，從不同環境測一次，至少要知道輸出有沒有差。這不是多疑，這是基本功。

• 從不同國別 VPN 或環境測試。
• 比對輸出、錯誤訊息、endpoint、延遲。
• 把差異寫進內部文件，不要只靠口耳相傳。

研究者先抓到，不代表廠商就有交代

這次讓我重視的另一個點，是 Chaofan Shou 先把怪味道抓出來了。這種事我看多了：先是某個研究者翻 package、看 diff、抓網路行為，接著才有人開始補說明。問題是，開發者不該等外面的人把異常挖出來，才知道自己裝了什麼。那不是透明，那是把透明度外包。

我不是在要求廠商像聖人一樣完美，我只是希望重要行為能被命名、被文件化、被審核。你如果要改變工具行為，至少要讓使用者知道條件是什麼。尤其是 AI 工具，它碰到的不是一般資料，是 source code、token、終端機、CI 設定，這些東西的敏感度完全不是同一個層級。

實操寫法是把研究者的發現納入你的 review loop。只要有可信報告，就先暫停升級，對照 artifact，記錄差異，確認到底是預期行為還是藏起來的分支。不要急著替 vendor 找台階下，先保住自己的環境。

你可以把這件事當成一個很簡單的原則：如果一個工具需要別人幫你看懂它，你就不該在沒審完之前讓它碰正式工作流。

我現在只看四件事，其他都先放旁邊

我後來把這類工具的審查縮成四件事，因為再多就會變成形式主義。第一，它能讀什麼。第二，它能送出什麼。第三，它能不能自己改行為。第四，它有沒有把這些事講清楚。這四件事看起來很土，但真的很管用。AI 工具的問題常常不是功能太少，而是權限太大、說明太少。

我也不想再聽那種「它只是幫你加速」的說法。加速是結果，不是免責。只要它能進你的 shell、能動你的 repo、能發 request，它就不是一般小幫手。它是有權限的軟體。你對 auth library、payment SDK 不會只看 logo，那你對 AI coding tool 也不該只看品牌。

實操寫法是做一份一頁式內規，讓同事每次導入都照同一套問題回答。不要寫成長篇大論，因為沒人會看。要短，要硬，要能真的執行。

可抄的模板

# AI Coding Tool Review Checklist

## Tool
- Name:
- Version:
- Source URL:
- Package manager / install method:

## Access scope
- [ ] Repo files
- [ ] Local shell commands
- [ ] Environment variables
- [ ] Secrets manager tokens
- [ ] Network access

## Data sent out
- [ ] Prompts
- [ ] Code snippets
- [ ] File contents
- [ ] Metadata
- [ ] Region / locale / account signals

## Behavior checks
- [ ] Different behavior by region?
- [ ] Different behavior by account type?
- [ ] Phone home on startup?
- [ ] Phone home on command execution?
- [ ] Are those calls documented?

## Supply-chain checks
- [ ] Exact version pinned
- [ ] Package contents reviewed
- [ ] Postinstall scripts reviewed
- [ ] Artifact archived internally
- [ ] Upgrade path documented

## Approval rule
- Approved by:
- Date:
- Notes:
- Re-review trigger:
  - New version
  - New network behavior
  - New region logic
  - New file access scope

## Decision
- [ ] Approved
- [ ] Approved with limits
- [ ] Rejected

## Why
Write the shortest honest explanation possible.
If you can’t explain the behavior in plain language, don’t ship it.

這份模板是我整理出來的，不是 Anthropic 給的，也不是那篇 Zhihu 文章直接附的。原始線索來自 Zhihu、Chaofan Shou 的 X，以及 Claude Code 官方頁面。我從這些來源衍生出來的結論很簡單：AI 開發工具先審再用，省下來的不是時間，是後面少掉的麻煩。