Claude Code 源码一泄漏，大家才发现真正敏感的不是模型

这次 Claude Code 爆出来后，开发者社区吵得最凶的，居然不是“模型到底强不强”。

大家盯着看的，反而是一些平时很少会出现在发布页上的东西：它会不会替用户隐藏 AI 痕迹，工具壳里有没有故意塞进去的假工具，产品团队还藏着哪些没公开的路线图。

说白了，这次最值得看的，不是“源码被看光了”这件八卦本身。

而是我们第一次比较完整地看见了：一个 AI 编程工具，到底会在模型外面偷偷再包上一层什么东西。

先别急着围观 50 万行代码

铺天盖地的热度已经说明一件事：大家在意的不是普通 bug。

如果只是“某个 npm 包带出了 source map”，它不会引发这么大讨论。真正把人吸过来的，是泄漏之后暴露出来的那些产品策略。

因为平时你看到的 Claude Code，只是一个会在 terminal 里帮你写代码、跑命令、提 PR 的工具。

你看不到它默认怎么定义自己。 你也看不到它默认替你做哪些决策。

这次泄漏，刚好把这层壳掀开了一角。

第一个争议点，不是能力，是“要不要让 reviewer 知道”

泄漏代码和讨论里，最容易让人不舒服的一段，是 undercover mode。

相关提示词会要求 commit message 和 PR description 里不要出现 “Claude Code” 这个词，不要提自己是 AI，也不要带 Co-Authored-By attribution。

这件事为什么争议这么大？

因为它碰到的不是效率问题，是透明度问题。

如果你只是把它理解成“帮内部员工隐藏公司内部代号”，那还只是保密措施。

但从外部开发者看到的那些提示词片段来说，争议点已经不只是“别泄漏内部信息”，而是：当 AI 参与写代码时，工具是否在默认帮用户把这件事藏起来。

有人会说，这没什么，commit message 本来就不该写“Generated by xxx”这种广告。

这话有一部分是对的。

但另一部分问题也确实存在：对 reviewer 来说，AI 是否深度参与过 PR，本身就是上下文。不是每个维护者都在意，可也不是每个维护者都不在意。工具如果默认替你把这层信息抹掉，它其实已经不只是“帮你写代码”，而是在替你决定“哪些上下文不需要让对方知道”。

这就不再是 UI 细节了。

这是信任边界。

第二个争议点，是 agent 外壳已经开始替模型打仗

另一个很有代表性的发现 fake tools。

Claude Code 某些请求里会带上和 anti-distillation 相关的字段，用来让服务端注入诱饵工具定义，目的是污染潜在竞争对手录下来的训练数据。

这类机制最终有没有长期效果，其实可以讨论。

连分析者自己也提到，真要绕过去，未必有多难。

但真正值得注意的不是“它防得住吗”，而是这件事说明：AI 编程工具外面那层壳，已经不仅在服务用户，也在服务平台竞争。

以前你觉得壳层只是管权限、管 UI、管缓存、管快捷命令。

现在看起来不是了。

它也在承担商业策略。 它在决定哪些请求长什么样，哪些行为该不该暴露，哪些信息该不该被别人学走。

这意味着以后你评估一个 AI 编程工具，不能只看“模型输出像不像人”。你还得看，这个产品壳在替谁优化。

是主要替你优化。 还是顺手也在替平台优化。 还是有时候会把平台利益悄悄放到你前面。

01-compare

第三个争议点，是大家第一次看见路线图比代码更值钱

泄漏之后，很多人并没有把注意力放在某个函数写得好不好。

他们更关心 feature flags。

比如讨论里频繁出现的 KAIROS，还有任务系统、后台 worker、定时刷新、append-only logs 这类线索。再比如被不少人当成彩蛋的 companion / buddy system。

这些东西不一定都已经成熟，也不一定最后都会上线。

但对竞争对手来说，代码风格不是重点，产品下一步想往哪走 才是重点。

Anthropic 真正损失的可能不是代码本身，而是路线图暴露。

因为今天做 AI 编程工具，单看模型能力，大家差距已经没那么像去年那样一眼拉开。

真正开始拉开差距的，是产品层：

• 你怎么组织工具
• 你怎么设计默认工作流
• 你怎么处理上下文和缓存
• 你怎么在 PR、commit、review 这些环节里定义透明度

模型是引擎。 但外壳开始决定车往哪开。

这件事为什么和普通开发者有关

有人会觉得，这种源码泄漏最多算 Anthropic 的尴尬时刻，和普通用户没多大关系。

我觉得恰恰相反。

因为它提前把一个以后大家都会遇到的问题，摊开给你看了：

当 AI 工具越来越像同事，它到底有没有权力替你“做人”？

比如：

• 它能不能默认决定 PR 里要不要披露 AI 参与
• 它能不能默认改写你的措辞，让 reviewer 看不出是机器写的
• 它能不能在你不明显感知的情况下，对请求做额外注入
• 它能不能把平台策略藏进“工具体验”里

这些问题以前看起来都很抽象。

现在不抽象了。

因为你已经看到一点实物了。

而且它们都不是单纯的“技术实现问题”。

它们是产品价值观问题。 也是协作伦理问题。

所以，以后该怎么看 AI 编程工具

我觉得至少要多问三句。

第一句：它不只会写什么代码，还会替我做什么决定？

第二句：这些决定里，哪些是为了体验，哪些其实是在改写透明度？

第三句：如果我不接受这些默认策略，我有没有办法关掉，或者至少知道它存在？

这三句，比跑多少 benchmark 都更像真实世界的问题。

因为 benchmark 只能告诉你它会不会写。

但团队协作里更麻烦的，往往是它怎么写、怎么解释、怎么归因、怎么隐藏。

这次泄漏最有价值的地方，就是它让很多人第一次意识到：

AI 编程工具真正难管的，不只是模型输出。

而是模型外面那层越来越厚、越来越聪明、也越来越有主见的产品外壳。

02-workflow

最后

我写过一篇，讲 Claude Code 为什么需要一层更好用的工作流外壳。

CLI 成为主流后，多 agent 对抗正在变成 AI 编程的最佳实践

那篇的重点是，外壳能把复杂能力变成更顺手的日常工作流。

今天这篇刚好是另一面。

外壳一旦越来越重要，它就不只是在提升效率。

它也在掌握解释权、归因权，甚至是你和 reviewer 之间的信息分配权。

未来 AI 编程工具的竞争，当然还是模型大战。

但不只是模型大战。

它也会是一次信任边界大战。

如果一个 AI 工具默认不在 PR 里披露 AI 参与，你会接受吗？