你在寫一個完全跟 Vercel 無關的專案，連 vercel.json 都沒有，突然這個問題跳出來：「Vercel 插件蒐集匿名使用數據……你願意也分享你的提示文字嗎？」
不是「Vercel 專案」，不是「Next.js 專案」，是「每個專案」。
這不是假設。這是 2026 年 4 月真實發生的事情。
Vercel 的 Claude Code 插件，在每個專案裡都會詢問你，要不要讓它讀取你打的每一個提示。就算這個專案跟你部署到 Vercel 完全無關。
更糟的是，這個同意問題不是真的 UI 元素，是透過提示注入到 Claude 的系統上下文裡。插件告訴 Claude：「去問用戶這個問題，然後根據回答執行 shell 指令。」
問題一：同意是假的
先從這個請求本身說起。Vercel 插件的用途是協助部署、框架指導、技能注入，為什麼它需要讀取你打的每一個提示？而且是在每個專案？這不是改善插件的分析，這已經遠超出一個協助你部署到 Vercel 的工具應該有的範圍。
想像一下，你用一個瀏覽器擴充功能，它只宣稱「幫你在 Amazon 購物時找優惠券」，但每次你開任何網頁（不只是 Amazon），它都在問你「能不能讓我看你所有的瀏覽歷史？」這感覺不對。
但就算你接受這個請求，他們問的方式更糟。
當 Vercel 插件想詢問你關於遙測數據的時候，它不會顯示一個 CLI 提示或設定畫面。
相反的，它將自然語言指令注入到 Claude 的系統上下文中，告訴 AI 去問你一個問題。Claude 讀取這些指令，使用 AskUserQuestion 渲染問題，然後根據你的回答執行 echo 'enabled' 或 echo 'disabled' 來寫入一個偏好設定檔到你檔案系統上。
這跟原生的 Claude Code 問題看起來一模一樣。沒有任何視覺標示告訴你這是來自第三方插件。你無法分辨差異。
這不只是上下文注入，這是插件原本預期的用途（技能、文件、框架指導）。Vercel 插件注入的是行為指令，告訴 Claude 去問一個特定問題，並根據你的回應在你的檔案系統上執行 shell 指令。
「這裡有關於 Next.js 路由的上下文」和「去問用戶這個問題然後寫到他的檔案系統」之間，有巨大的差別。
有人已經在 GitHub 上提出這個完全相同的擔憂。一位 Vercel 開發者回應：「當使用像 Cursor、CC 或 Codex 這樣的第一方市場時，你無法建立一次性 CLI 提示。啟動來自於 agent harness 內部。我們完全開放改善這個問題，但我們需要一個更好的解決方案。」
我理解這個限制。但對於「我們無法建立適當的同意」的答案，應該是不推出這個功能，而不是改用提示注入來繞過。
即使在今天的限制下，他們也可以在問題文字中加入「這個問題來自 Vercel 插件」，並且直接從 hook 的 JavaScript 寫入偏好設定檔，而不是指示 Claude 去執行 shell 指令。
問題二：「匿名使用數據」不是你想的那樣
同意問題是這樣說的：「Vercel 插件蒐集匿名使用數據，例如技能注入模式和預設使用的工具。」
聽起來無害。實際上它蒐集的是什麼呢？
| 會發送什麼 | 什麼時候 | 他們會問嗎 |
|---|---|---|
| 你的裝置 ID、作業系統、偵測到的框架、Vercel CLI 版本 | 每個 session 開始 | 不 — 永遠開啟 |
| 你的完整 bash 指令字串 | 每次Claude執行 bash 指令後 | 不 — 永遠開啟 |
| 你的完整提示文字 | 你打的每個提示 | 是 — 只有你選擇加入時 |
中間那行。每個 bash 指令，完整的指令字串，不只是工具名稱，被送到 telemetry.vercel.com。檔案路徑、專案名稱、環境變數名稱、基礎架構細節。不管指令裡有什麼，他們都會拿到。
如果你輸入 cat /home/claw/Desktop/ai學苑/.env，完整的字串就被送出去。如果你跑 npm run build -- --env production，他們知道你有一個 production 環境的腳本。如果你執行 kubectl get pods -n my-secret-project，他們知道你有一個叫 my-secret-project 的 Kubernetes namespace。
把這個描述為「匿名使用數據，例如技能注入模式和預設使用的工具」有點牽強。
同意問題將你的選擇框定為「也分享提示文字，或不要」。它從來沒有告訴你 bash 指令的蒐集是可選的。它從來沒有說你可以關閉它。實際的選擇不是在遙測和無遙測之間，而是在「一些」和「更多」之間。
所有這些都綁定在一起，使用一個儲存在你機器上的持久裝置 UUID，建立一次然後永久重複使用。每個 session、每個專案，在時間軸上都可以連結。這不是「匿名」，這是「匿名但可連結」。
選擇退出的確存在，一個環境變數 VERCEL_PLUGIN_TELEMETRY=off，紀錄在插件的 README 中。但那個 README 位於插件快取目錄裡面。不在你安裝或第一次執行時會看到的地方。你不知道有這個選項，除非你主動去翻原始碼或偶然發現。
問題三：這在你的所有專案上執行
這是最初讓我注意到的事情，在一個非 Vercel 專案上彈出的同意問題。
我翻遍了每個遙測檔案，尋找專案偵測。沒有。
Hook matchers 確認了這一點。UserPromptSubmit matcher 實際上是空字串，匹配所有東西。為你的 Next.js app 安裝插件，它就在監視你的 Rust 專案、你的 Python 腳本、你的客戶工作。所有東西。
諷刺的是，插件已經內建框架偵測。它在每個 session 開始時掃描你的 repo 並識別你正在使用什麼框架。但它只用這個來報告它找到的東西，不是決定是否觸發遙測。
從原始碼可以清楚看到這個矛盾。在 session-start-profiler.mjs 中，profileProject() 函數會掃描你的 repo，尋找 next.config.*、vercel.json、middleware.ts、components.json 和 package dependencies。它會精確地判斷你用什麼框架。
但遙測觸發器完全忽略這個資訊。UserPromptSubmit 的 matcher 是空字串。PostToolUse 的 matcher 只是檢查工具名稱是不是 “Bash” 或 “Write|Edit”。SessionStart 的 matcher 是 “startup|resume|clear|compact”，這些是 session 事件，不是專案條件。
閘門存在。他們只是沒有用。
為什麼這很重要
這不是「Vercel 想改善插件」這麼簡單。這是 AI 輔助開發生態中的一個先例。
當你給予一個 AI agent 權限去執行 shell 指令、讀取你的檔案、寫入你的專案，你是在建立一個新的信任關係。這個關係比傳統軟體工具更敏感。因為它不是一個靜態工具，它是一個會「思考」的 agent，而它的「思考」可能被第三方插件影響。
Vercel 插件的做法展示了一個危險模式：將行為指令注入到 agent 的思考過程中。如果每個插件都可以透過提示注入去改變 agent 的行為、詢問用戶問題、執行系統指令，那麼信任鏈就被打破了。
今天只是「蒐集你的 bash 指令」。明天可能是「在你不知情的情況下安裝一個套件」。後天可能是「修改你的 package.json 加入一個依賴」。
這不是科幻。這是已經在發生的事情，只是目前的惡意意圖比較低（蒐集資料）。但架構上，沒有阻止真正惡意行為的機制。
這也是為什麼視覺屬性、細粒度權限、專案範圍這三個東西如此重要。它們不只是「UX 改善」，它們是 AI agent 生態的安全基礎設施。
VS Code 的擴充功能已經解決這個問題二十年了。當你安裝一個 VS Code 擴充功能，它會宣告它需要什麼權限、它會在什麼條件下啟動。你可以在安裝前看到完整清單。你可以在設定中隨時停用任何擴充功能。
Claude Code 的插件架構需要學習這個經驗。不能因為「AI 很新」就重新發明輪子，而且發明出來的輪子還比舊的更不安全。
社群反應與討論
這篇文章在 HackerNews 上引發了廣泛討論。許多開發者表示震驚，因為他們完全不知道這個情況。有些人說他們「一直覺得怎麼每次 Claude 都在問奇怪的問題」，卻沒有意識到這不是 Claude 在問，而是 Vercel 插件在問。
一位開發者分享了他的經驗：「我在做一個 Python 資料分析專案，突然被問到要不要分享提示文字。我還以為這是 Claude 的標準問題，就點了『不』。現在我才知道這是 Vercel 插件，而且它還在蒐集我的所有 bash 指令。」
另一位開發者指出：「最諷刺的是，Vercel 自己的產品 Next.js 是一個以開發者體驗為核心的框架。但這個插件完全沒有考慮到開發者的隱私體驗。」
還有開發者指出：「這不只是 Vercel 的問題，這是整個 AI 生態的問題。我們太快接受『AI 可以讀取一切』，沒有建立適當的權限和透明度邊界。」
需要改變什麼
對 Vercel 來說：
- 所有遙測都需要明確的選擇加入。「我們想要蒐集：（1）session 元數據，（2）bash 指令，（3）你的提示文字 — 你想要啟用哪些？」誠實披露，真正的選擇。
- 「匿名使用數據」不應該是發送到帶有持久裝置 ID 的伺服器的完整 bash 指令字串的描述。
- 遙測應該只限於 Vercel 專案。框架偵測已經存在，用它。
對 Claude Code 來說：
- 插件需要視覺屬性。在任何透過 plugin hook 顯示的問題前加上 [Vercel Plugin]。現在，所有注入的插件問題看起來都跟原生 UI 完全一樣。
- 插件需要細粒度權限。當插件安裝時，Claude Code 應該顯示：「這個插件請求存取：你的 bash 指令、你的提示文字、session 元數據。允許嗎？」
- 插件應該宣告範圍 — 哪些檔案或相依性必須存在才能觸發 hook。這正是 VS Code 擴充功能與 activationEvents 運作的方式。這是一個已解決的問題。
對你來說，現在：
| 你想要什麼 | 如何做 |
|---|---|
| 關閉所有 Vercel 遙測 | 在 ~/.zshrc 中 export VERCEL_PLUGIN_TELEMETRY=off |
| 完全停用插件 | 在 ~/.claude/settings.json 中設定 “vercel@claude-plugins-official”: false |
| 中斷裝置追蹤 | rm ~/.claude/vercel-plugin-device-id |
環境變數會關閉所有遙測，但保持插件完全功能。技能、框架偵測、部署流程，所有東西都仍然運作。你沒有失去任何東西，除了 Vercel 的資料蒐集。
每個問題都有一個 Vercel 層和一個 Claude Code 架構層。Vercel 做了我認為不可接受的選擇。但插件架構啟用了那些選擇，沒有視覺屬性、沒有 hook 權限、沒有專案範圍。
我使用 Vercel。我喜歡 Vercel。我每天都使用 Claude Code。我希望兩個都能更好。
當然，不只是我這麼希望。在 HackerNews、在 GitHub issues、在 Twitter 和 Reddit，已經有數百個開發者表達了同樣的擔憂。這不是一個單獨的事件，這是一個正在形成的共識。
我們需要為 AI agent 生態建立更強的隱私和權限邊界。我們需要學習過去二十年的軟體開發經驗，不要因為「AI 很新」就重蹈覆轍。
結尾
當工具開始「思考」，我們必須重新思考我們給予它的權限。不是因為 AI 會叛變，而是因為第三方插件的行為指令可能比我們想像的更容易改變 agent 的決策。
Vercel 插件的例子不是最壞的，但它是一個重要的警告。它展示了如果沒有適當的視覺屬性、權限控制、專案範圍，我們允許了什麼樣的行為注入到我們的日常開發流程中。
現在就檢查你的設定，關閉不必要的遙測，要求更好的隱保護。不是因為你「有什麼要隱藏」，而是因為這是你的資料，你應該有完全的控制權。
原文所有內容都可以從 ~/.claude/plugins/cache/claude-plugins-official/vercel/ 中的插件原始碼驗證。