一个部署插件，凭什么想看你所有提问？Vercel 被曝在 Claude Code 中“越界”收集数据
一句“要不要分享提示词”，把 AI 编程工具的隐私边界撕开了
这两年，开发者对 AI 编程助手的容忍度其实挺高的。毕竟大家都默认：你让它帮你写代码、读仓库、跑命令，它多少要“看见”一些东西。可这次引发争议的点，不是模型会不会读代码，而是一个本该负责部署的插件，突然把手伸向了“你和 AI 之间的全部对话”。
事情起因很戏剧化。独立开发者 Akshay Chugh 在一个与 Vercel 毫无关系的项目里使用 Claude Code，既没有 vercel.json，也没有 Next.js 配置，更没有 Vercel 依赖，结果却弹出一条看起来像 Claude Code 原生界面的提问：Vercel 插件会收集匿名使用数据，你是否愿意进一步分享你的提示词文本？乍一看像普通授权，细看却让人背后一凉——所谓“提示词文本”，说白了，就是你每一次输入给 AI 的内容。
如果这只是一次笨拙的弹窗设计，事情还不至于发酵。但作者继续翻源代码后发现，这个问题并不是产品原生 UI 弹出来的，而是插件把一段自然语言“塞进”Claude 的系统上下文，让 Claude 自己把这段话说给用户听。更微妙的是，Claude 还会根据用户回答，执行 shell 命令，在本地写入“已开启”或“已关闭”的偏好文件。这个过程看起来像官方提问，实际上更像插件借 AI 之口完成了一次“代问代办”。
这也是整件事最让人不舒服的地方：它不只是“问了一个问题”，而是模糊了谁在提问、谁在执行、谁在收集数据。对普通用户来说，这条提示几乎没有任何第三方来源标识。你看到的是 Claude 在问你，背后真正发问和收集的是插件。这个边界一旦模糊，AI 工具就很容易从“助手”滑向“代办中介”，而用户甚至意识不到自己在和谁打交道。
“匿名使用数据”这句话，越来越像科技行业最危险的委婉语
按原作者的说法，Vercel 插件的遥测分成两层：一层默认开启，另一层需要用户额外同意。问题在于，这个区分没有被清楚地告诉用户。
默认开启的部分，包括设备 ID、操作系统、检测到的框架、Vercel CLI 版本，以及 Claude 每次执行 Bash 命令后的“完整命令字符串”。注意，不是“调用了 Bash 工具”这么简单，而是完整命令本身。这里头可能有什么？项目路径、环境变量名称、私有仓库目录、测试地址、基础设施命名习惯，甚至一些临时手敲的运维操作。单看每一条命令也许不算惊人，但它们串起来，足以勾勒出一个开发团队的技术栈、项目结构和工作习惯。
而用户真正被询问的，只有“是否愿意分享提示词文本”。这就有点像有人先把你客厅看了个遍，然后礼貌地问：“我能顺便进卧室看看吗？”重点不只是“卧室”该不该进，而是前面那部分为什么默认就进来了。
科技公司对“匿名数据”这个词的使用，近些年已经越来越泛化。只要不直接附上姓名邮箱，很多采集行为都会被包装成匿名统计。但在实践里，只要数据带有持久化设备 ID，并且持续跨会话、跨项目上传，所谓匿名就没那么轻松了。它不一定指向现实中的“张三李四”，却可能长期稳定地指向“这台机器上的这个开发者”。在广告行业，这叫可关联；在安全领域，这叫可画像；在公关稿里，它往往还叫“为了改善产品体验”。
Vercel 当然不是第一家踩进这个灰区的公司。VS Code、JetBrains、GitHub Copilot、Cursor 这类工具都绕不开遥测与隐私争议，只是传统 IDE 至少已经建立起一套相对明确的预期：哪里是系统弹窗，哪里是扩展行为，哪些权限在安装时就会说明，哪些数据可以在设置里关闭。AI 编程代理的问题在于，它把一部分产品行为包裹进自然语言交互中，让权限提示也长得像聊天内容。这种设计天生更顺滑，也天生更危险。
真正的问题，不只是 Vercel，而是 AI 插件开始学会“借壳说话”
从这次披露看，Vercel 插件最大的技术争议点，并不是“收集了数据”这么简单，而是它使用了 Claude Code 的插件机制，把“提问”和“执行命令”都交给了模型来完成。通俗点说，插件没有自己弹出一个明确标识来源的授权框，而是让 Claude 假装成在正常对话中顺便问你一句，然后再按你的回答执行动作。
这件事之所以重要，是因为它触碰了 AI agent 产品目前最薄弱的一层：行为归属。今天的用户已经开始习惯把 AI 当成一个统一界面，所有信息都从这个入口流入流出。可一旦插件能在后台注入上下文、触发提问、调用工具、落盘写文件，用户其实很难分辨“这是模型自己的建议”“这是平台内置流程”“还是第三方插件在借模型的话筒办事”。
放在更大的行业背景里看，这几乎是 AI 时代版的浏览器扩展权限问题。十几年前，浏览器生态也经历过类似阶段：扩展很好用，但会读你访问的页面、修改页面内容、注入脚本，甚至静默收集数据。后来大家才慢慢建立起权限提示、来源标识、商店审核和最小权限原则。AI 编程工具眼下正重演这段历史，只不过这次被读取的不只是网页，而是提示词、代码上下文、终端命令，敏感度更高。
更尴尬的是，作者称 Vercel 插件其实已经具备“检测当前项目是否像 Vercel 项目”的能力，会扫描仓库里的 next.config.*、vercel.json、依赖信息等。但这些检测结果被用来上报“可能技能”，却没有被拿来限制遥测只在相关项目中触发。换句话说，门不是没有，锁也不是不能装，只是它被用在了别处。
如果这一点属实，那么争议就不再只是“设计失误”，而更像产品取舍：公司选择了更宽的收集范围，而不是更窄的适用边界。对于一个部署插件来说，这显然很难让人心安。
AI 编程工具进入第二阶段后，权限设计不能再靠“默认信任”混过去
这件事之所以在当下格外值得关注，是因为 AI 编程工具正在从“补全助手”走向“执行代理”。当工具只负责续写几行代码时，隐私和权限问题尚可通过本地上下文、云端开关、企业版隔离来缓解；但当工具开始主动读仓库、运行命令、修改文件、安装依赖、接入第三方插件，权限模型如果还是停留在“装上就默认跑”，风险会迅速放大。
Claude Code、Cursor、Codex CLI 这一类 agent 式产品，带来的最大变化不是代码写得更快，而是软件开始替你操作系统。谁能读你的提示词、谁能看到你的命令、谁能在什么项目里生效，这些问题必须被做成显式、可审计、可撤回的权限，而不是一段埋在 README、缓存目录或环境变量里的说明。
原作者已经给出几种自救办法，比如设置 VERCEL_PLUGIN_TELEMETRY=off 关闭遥测，或者直接在 ~/.claude/settings.json 里禁用插件。从用户角度看，这当然有用；但从产品角度看，这不是答案。真正合理的做法，应该是在安装或首次运行时就明确告诉用户：这个插件想访问哪些内容，分别出于什么目的，是否只在匹配项目里生效，是否可以分项开启。
我尤其认同文中一个观点：Claude Code 这类平台也该承担责任。不能把一切都推给插件开发者。平台既然允许第三方通过系统上下文影响模型行为，就应该提供清晰的来源标识，比如所有插件发起的问题前面都带上 [Vercel Plugin]；也应该提供粒度足够细的权限面板，比如“读取提示词”“读取终端命令”“会话元数据上传”分别授权。否则，用户面对的永远只有一个会说话的 AI 界面，却不知道背后到底有几只手在翻自己的口袋。
这不只是一次插件翻车，更像一次行业预演
我并不认为 Vercel 会因为这次事件就被钉死在耻辱柱上。恰恰相反，Vercel 一直是开发者生态里相当懂产品和体验的一家公司，也正因为如此，这次争议才更值得行业警惕：连最懂开发者的公司，都可能在 AI 插件时代做出跨边界的设计，那说明规则真的还没立起来。
可以预见，未来一年类似争议不会少。今天是提示词和 Bash 命令，明天可能就是数据库 schema、测试凭据、CI 日志、监控面板链接。Agent 越能干，插件越聪明，权限边界就越不能含糊。过去软件行业常说“如果你没有为产品付费，那你可能就是产品”；到了 AI 开发工具时代，更扎心的一句可能是：如果你的代理足够懂你，它收集的就不只是你的点击，而是你的思路、习惯和工作方法。
这也是为什么这件事不该被轻描淡写地归类为“一个插件的小 Bug”。它更像一面镜子，照出整个 AI 工具链还处在“能力先行、治理滞后”的阶段。大家都在忙着把 agent 做得更强，却还没把“谁可以看什么、代表谁说话、在何处生效”这些最基础的问题讲明白。
开发者不是反对遥测，很多人也理解产品改进需要数据。真正让人反感的，从来不是收集本身，而是范围不透明、措辞太轻、关闭太深、界面太像官方。说到底，技术世界里最稀缺的不是聪明，而是分寸感。一个部署插件可以很积极，但最好别积极到想知道你和 AI 说过的每一句悄悄话。