1. 敏感代码外泄不是假设，是已经发生的事故上周三下午，我们团队收到安全中心的红色告警：某内部服务的 GitHub 仓库中，一段包含生产数据库连接串和密钥的初始化代码，被 Claude Code 在补全时直接生成并提交到了 dev 分支。这不是 prompt 写错了，也不是开发者手抖——它发生在一次常规的“快速修复日志格式”的 PR 中，AI 根据上下文自动补全了DataSourceConfig类，并顺手把.env里刚读进来的DB_PASSWORD变量名，原样塞进了硬编码字符串里。我立刻拉出 Git blame 和 IDE 日志，确认了三件事：第一，这段代码从未出现在任何人工编写的 commit 中；第二，补全触发前，编辑器光标正停在new DataSource(...)后面；第三，Claude Code 的本地日志显示，它在生成时引用了当前打开的.env文件片段作为上下文。这不是模型“胡说”，而是它太老实——你给它看什么，它就记什么、用什么。这件事让我彻底放弃“只要不写明密码，AI 就不会泄露”的侥幸。Claude Code 不会主动过滤敏感内容，它只忠实地建模你给它的所有输入。而现代 IDE 插件默认加载整个工作区文件、环境变量、甚至终端历史——这些全是它的“上下文”。一旦某个模块需要读取配置、解析 YAML、拼接 SQL 连接串，敏感数据就极可能在 token 流中裸奔。更麻烦的是，这种泄露很难靠人工 Code Review 发现。它不像明文写死的password: "123456"那样扎眼，而是藏在