真正危险的，不是 Claude Code 泄密，而是很多芯片公司还在假装保密

Claude Code 这次出事，最该警醒的不是“美国公司也翻车了”，而是“工具安全”从来不等于“资料主权”

Claude Code 这次事件，表面上看，是 Anthropic 在发布 npm 包时把 source map 一起打了进去，结果外界据此还原出大量客户端源码。Anthropic 对外的口径也很明确：这是发布流程中的人为失误，不是底层模型本身被攻破，也没有客户敏感数据或凭据因此暴露。换句话说，这不是“模型失守”，而是一次很典型、也很普通的工程交付失误。

真正值得中国本土芯片公司警惕的，不是“原来美国公司也会犯低级错误”，而是另一个更硬的事实：再强的外部工具，它的安全边界也只是工具边界，不是公司的资料边界。Claude Code 的官方文档写得很直白：它虽然在本地运行，但为了与模型交互，用户提示和模型输出仍然要通过网络发送；商业用户标准保留期通常是 30 天；Zero Data Retention 不是默认状态，而是需要按条件单独启用；使用 Anthropic 第一方 API 时，Statsig 遥测和 Sentry 错误上报默认开启。也就是说，企业账户、统一 API、内网代理，这些当然比随便乱用强，但它们仍然只是“接入方式”，不是“资料主权”本身。

这也是为什么，最近很多公司第一反应是“赶紧把 API 接到自己的保密服务器里”，这一步看起来很专业，实际上很可能把顺序彻底搞反了。因为如果一家公司的真实资料平时根本不在自己的主库里，而散在微信、钉钉、本地电脑、聊天截图、临时目录和“某某人手上最新版”里，那么 Claude 接进来以后，读到的也只是一个残缺、滞后、失真的切面。AI 不会自动把混乱变成秩序，它只会更快地把混乱组织起来，让混乱看上去更像系统。Claude Code 这次最该带来的反思，不是“还能不能接”，而是“接进来之前，公司自己的资料底座到底站没站住”。

很多公司最大的问题，不是没有保密系统，而是把“高保密”和“集中备份”硬揉成了一件事

很多公司的起点其实并不坏。为了防泄密，建一个独立服务器，把东西往里放，逻辑上“写得进去，拿不出来”。听起来很安全，问题是，真实工作根本不是按这个逻辑发生的。

真正推动项目往前走的，往往不是服务器里那份“正式文档”，而是微信里那几段讨论、钉钉群里那次结论、某台电脑上刚改好的脚本、某张还没来得及整理进报告的测试图。

于是就出现一种极其滑稽、却又极其普遍的场景：形式上要求在保密服务器里写报告，现实里写完以后，啪地一截屏，再发到微信里继续讨论。表面上像是“先保密再协作”，实际上却是“系统里留一份给检查，真正的工作还是在系统外推进”。这不是保密，这只是把“文件在服务器里”误当成了“信息已被控制”。这类风险不是想象出来的。

市场监管总局 2025 年公布的典型案例里，明确写到有员工通过钉钉项目群获取技术文件后发送到微信群，也明确点出社交软件正在成为商业秘密泄露的新型风险点；同一批案例里，还有通过手机偷拍图纸、通过个人邮箱带走技术资料等典型情形。

问题更深的一层在于，一旦把“集中保密”和“集中备份”绑死在一起，系统就会天然变得难用。真正需要最高保密的东西，比如 GDS、流片交付包、极少数核心版图和必须封闭流转的关键资产，确实应该进窄门，麻烦一点都值得，因为第一目标就是不扩散。可大量并不属于最高密级、却对公司极其重要的日常资料——周报、测试记录、项目报告、数字系统代码、脚本、规格草稿、应用笔记——它们真正需要的不是“锁死”，而是持续协作、自动回流、版本沉淀、集中备份、可检索、可恢复。把这两类东西硬塞进同一个高墙逻辑里，结果一定是：真正高频使用、最需要长期沉淀的资料，因为入口麻烦、登录繁琐、放进去以后不好继续协作，大家能不放就不放；真实工作于是继续留在系统外。保密系统最后没有减少扩散，反而在促进扩散；没有形成备份，反而把最该备份的东西赶到了墙外。

最危险的信号，往往不在员工身上，而在管理层自己的习惯里。判断一家公司的资料体系是真是假，其实有一个很直接的标准：当 CEO 真要一份关键资料时，第一反应是直接去系统里取，还是临时去微信里问人、去群里翻聊天记录、去催谁把“那个版本再发一遍”。如果最高层自己到了真要紧的时候，仍然习惯性地从聊天软件里找资料，那就说明这家公司真正依赖的不是资料系统，而是人肉转发链。

表面上看，资料属于公司；实际上，资料仍然寄存在若干人的微信、钉钉、电脑和记忆里。这样的体系，平时看起来也能运转，一到做网站、做 AI、做知识库、做客户交付追溯时，就会立刻暴露出底层空心化：资料不少，知识却不在。上海法院披露的全国首例涉人工智能芯片领域侵犯商业秘密罪案，就直接揭示了这类风险的硬边界：被告把芯片公司的大量保密数据复制、传输到本地电脑，再上传到个人网盘，最后构成犯罪。这类案件说明，被争夺的从来不只是“最终芯片”，而是代码、设计资料和整个资料系统本身。

国际半导体行业也一样。ASML 2023 年披露，一名前中国员工不当获取了与其专有技术相关的数据。公开报道进一步指出，这些数据来自其用于管理光刻设备技术信息的 PLM/Teamcenter 类系统。这个案例最值得看的一点，不是“高墙没用”，而是资料库本身就是战场。只要把真正高密的东西、项目正式版本、个人日常工作混在一个系统里，最后一定是谁都不舒服，谁都想绕开。

真正该补的，不是一台更大的保密服务器，而是三层分工清楚的资料结构

真正合理的结构:

第一层必须是高保密库，但它只负责极少数真正该进高墙的东西，比如 GDS、流片交付包、极少数核心版图和必须封闭流转的关键资产。这里最关键的不是“加密码”，而是“加边界”。更落地的政策，不该是“谁知道密码谁都能在任何地方登录”，而应该是：只有指定岗位、指定电脑、指定网段、指定地点，才能访问高保密库；访问行为默认留痕，拷出、打印、外发需要单独审批；普通员工不能在任何地方凭账号密码就把最高敏资产打开。高保密库应该是窄门，是少数关键资产的金库，而不是一切资料的总入口。只要高保密库承担了“大家平时都上去写报告、改文档、跑协作”的职责，它迟早会被绕开。

第二层必须是按项目组织的统一版本库，而且要具体到库，不能只说一句“我们有 Git”。比如一个芯片项目，至少可以稳定存在几个项目仓：proj-x-rtl.git 放 RTL、约束和关键提交；proj-x-fw.git 放固件和工具链相关代码；proj-x-docs.git 放规格书、设计说明、接口约定、评审纪要；proj-x-test.git 放测试计划、正式报告、关键结果和复现实验脚本。这一层不是把所有临时碎片都吞进去，而是把“项目正式知识主干”固定下来：哪些版本可以追溯，哪些文档可以复用，哪些测试结论已经形成组织资产。将来网站、产品页、内部知识检索和 AI 检索，优先吃的就应该是这层，而不是聊天记录和个人截图。

第三层则是很多公司最缺、却最该先做的一层：个人工作目录的强制无感同步备份。工程师还是在本地目录里工作，用自己熟悉的 IDE、仿真环境、脚本工具、实验路径，不要求所有人跑到服务器里写报告。但每个人都可以设定一个或若干工作目录，通过同步软件持续回流到公司服务器，形成个人工作镜像。这里默认只有本人可读写；管理侧不是“随便能看所有人”，而应该遵循最小必要访问原则，只在离职交接、事故恢复、合规调查等少数场景通过受审计的应急流程读取。否则，“集中备份”又会重新退化成“大家不愿意放真资料进去的共享盘”。

再往上加一条硬规则：活跃研发目录按小时做不可篡改快照，项目正式库按更长周期做快照和归档，高保密资产再叠加更严格的长期保存策略。这里不必把所有东西一刀切成“全都每小时快照”，但至少对真正高频变化、价值密度高的研发工作目录，小时级恢复点是合理的。NIST 关于存储基础设施安全和恢复保障的建议很明确：存储安全不只是权限控制，还包括数据保护、隔离、恢复保障和恢复验证；恢复点目标应根据业务需求设计，而不是拍脑袋决定。对芯片研发来说，上一个小时丢掉的，往往不是几页无关紧要的文档，而是一轮刚跑完的测试、一版刚收敛的脚本、一段刚定位出来的根因分析。不能恢复，就等于没备份。

如果大量有效资料天然产生在微信和钉钉里，就别再假装看不见，而是把“聊天流”制度化地收束成“知识流”

很多公司一说资料治理，第一句话就是“不要在微信和钉钉里聊这些”。这句话道理上没错，现实里却往往没用。因为项目推进、临时判断、测试结论、版本说明、客户反馈、问题定位，最先出现的地方，常常就是群聊和私聊。假装这些内容“不该存在”，并不能让它们消失，只会让公司对自己的真实知识流动视而不见。

真正成熟的做法，不是空喊“别在聊天里说”，而是承认聊天软件已经是事实上的前端工作界面，然后反过来建立制度，把聊天流里的有效内容定期、持续、低摩擦地收束成正式知识。因为聊天记录本质上只是信息流，不是知识库。它快、碎、临时、上下文强、版本弱。今天一句话有意义，是因为说的人、时间、背景都还在；过了三周，这句话很可能就无法单独理解。让聊天记录长期承担知识库角色，组织最后拥有的就不是知识资产，而只是“谁当时在那个群里”的人肉记忆。市场监管总局公开案例里，已经把钉钉项目群到微信群的泄露路径点得非常清楚，这不是管理学想象，而是真实的执法对象。

所以，如果大量资料天然产生在微信和钉钉里，公司就必须立一条铁律：聊天可以是入口，但不能是终点。凡是有长期价值的内容，都必须有后续动作，把它从聊天流中提取出来，落到正式文档、项目仓或知识库里。这个动作可以由人做，也可以由机器辅助做(钉钉微信都已经有了自动写总结的机器人可以自动总结聊天内容)，但不能没有。

更进一步的做法，是把正式写作入口前移到知识库或文档系统：正式内容直接写在文档里，讨论也直接发生在文档对应的位置，用评论、批注和修改建议承接协作，而不是把完整正文先发在聊天里，事后再指望有人去打捞。这里不必把某个具体平台写成唯一答案，关键是方法：文档是正式载体，讨论围绕文档位置发生，版本和归档进入公司主库，而不是永远漂在聊天流里。

这件事看起来只是“写作习惯”的变化，实际上是在争夺知识主权。只要关键结论长期停留在聊天记录里，知识就永远依附于人，而不是属于公司。谁参加了那个群，谁记得那次讨论，谁就掌握了事实解释权。这样的组织平时看起来很灵活，真到做网站、做 AI、做内部检索、做客户交付追溯时，就会立刻暴露出底层空心化：资料不少，知识却不在。

Claude Code 泄密之后，真正该先做的，不是“接进来”，而是把顺序倒过来

很多公司最喜欢跳过的，恰恰是这些最基础的事情。觉得备份、快照、项目仓、目录同步、恢复机制这些东西太基础、太不性感，于是总想先去做网站、做 AI、做知识库、做智能检索。结果往往是一到真的要做，谁手里都没有完整资料。测试记录在聊天群里，最新代码在某个人电脑里，项目报告有若干版互相打架，内部分析只存在于某次语音之后的几张截图里。到了这个时候，管理层最常犯的错误就是把问题理解成“大家不配合”，于是开始强制分配任务：你去补资料，他去整理文档，另一个人去追历史版本。

可这种强制补档为什么总会引发抵制？因为它不是在利用一个已经存在的资料底座做增值，而是在临时发动全员去偿还过去长期欠下的基础设施债。平时没有给出自然、低摩擦、可持续的资料回流路径，到了要做网站、做 AI 的时候，突然把“补资料”变成每个人额外的劳动，谁都会抵触。问题不在于员工不愿意支持新系统，而在于旧问题从来没有被诚实解决过。

所以，Claude Code 泄密之后，中国芯片公司最该吸取的教训，不是“以后买哪种账户更安全”，也不是“怎么通过买美国esim把 API 接得更巧妙”。真正该吸取的教训是：外部 AI 只能建立在内部资料主权之上。先把高保密区缩小、做实、做硬，甚至落实到“只有指定电脑、指定地点、指定岗位能看”；先把项目仓按项目建起来；先把个人工作目录的无感同步、分层快照、可恢复能力做起来；先把聊天流制度化地收束成知识流。只有到了那一步，Claude Code 才是生产力。否则，再强的 Agent 也只是一个更聪明的放大器，把原本就松散、分裂、不可恢复的资料现场，放大得更快、更像样，也更危险。