AI编程工具该如何披露遥测?

AI 编程工具要不要收集遥测，我并不反对。崩溃日志、功能使用情况、请求失败原因，确实可能帮助团队修复问题。但我最在意的不是“有没有遥测”，而是工具有没有把这件事讲清楚：收集了什么、为什么收集、发到哪里、保存多久，以及我能不能拒绝。

最近围绕 Claude Code 的社区逆向讨论，之所以引发强烈不适，关键并不只是识别地区或使用环境本身，而是用户是否能在安装和使用前知道这套逻辑。如果相关分析属实，工具通过本地时区、ANTHROPIC_BASE_URL 和加密域名清单进行分类，再把标记藏进常规字段传回服务器，这就已经超出了普通用户对“错误报告”的直觉理解。即便企业有服务限制或反滥用需求，也不应依赖隐蔽编码来完成。

我认为合格的遥测披露，至少要说五件事

第一，列出数据字段，而不是只写“可能收集诊断信息”。时区、环境变量、项目名称、代码片段、设备标识，隐私风险完全不同。

第二，说明用途和必要性。某个字段如果与修复崩溃没有直接关系，就应该解释为什么需要它；如果只是为了用户分类，更应单独说明，而不能混在技术诊断里。

第三，公开传输对象、保存期限和访问范围。数据去了哪里、由谁处理、多久删除，这些都不能靠用户自己逆向客户端才能发现。

第四，提供真正有效的关闭选项。关闭后应停止相应采集，而不是只关闭界面上的统计开关，后台仍通过其他字段发送分类信息。

第五，遥测机制应有可审计记录。版本更新改变了哪些采集字段、是否新增数据用途，都应写进更新说明；企业用户还需要能够通过网络策略验证实际行为。

我自己选择 AI 编程工具时，已经把遥测透明度和代码生成能力放在同一张评估表里。工具可以不满足所有人的隐私偏好，但不能让用户在不知情的情况下替它做决定。对 AI 工具来说，最容易失去的不是一条日志，而是开发者愿意托付代码和工作流的信任。