尼克·G（Nick G.）来自 Anthropic，已在 Hacker News 上回应，Anthropic 的博客也补充了充分署名，作者仍坚持当时帖子中的说法。应昨日关于 Anthropic 的 Scion 抄袭物怪（Mononoke）的帖子，他收到不少疑问，于是写下这篇跟进。作者说，昨天发文时尽量宽容，以为相似多属无意、缺署名只是未尽职调查；但发布后私下确认，Scion 有意且公然抄袭物怪（Mononoke），人员有重叠，不可能是无意致敬。他昨天虽有预感，却因当时所知不便说。

更新：Anthropic 的 Nick G. 已在 Hacker News 上回应，Anthropic 的博客文章也添加了充分的署名。对我撰文当时的说法，我依然坚持。

在回应昨天那篇关于 Anthropic 的 Scion 抄袭 Mononoke 的文章时，我收到了不少提问和意见。下面这篇后续回答其中最主要的一些。

这就是抄袭。 我昨天那篇文章在当时所知的情况下，已经尽量往善意方向解释了，尤其是认为它与 Mononoke 的相似多半是无心之失，缺署名只是没做足背调。但文章发布后，我私下得到确认：Scion 是故意、公然抄袭 Mononoke，而且双方人员还有重叠。这根本不可能是无意的致敬。这一点我昨天就有预感，但鉴于当时掌握的信息，还不便说出来。

相似之处远不止“派生数据”这个概念。 有人指出，派生数据不过是一种索引，属于常见概念。我要澄清的是，派生数据只是最显眼的相似点；实际相似要深得多，延伸到整个数据模型，以及围绕它构建的许多结构。

Anthropic 是这样描述 Scion changeset 的：

Mononoke 也有完全相同的概念，我们称之为 Bonsai changeset。在 2022 年同一份 Oxide 材料里，我是这样描述它们的：

它们完全一样。就连“Scion”这个名字，也是把“Bonsai”的音节颠倒过来、再去掉开头的“B”！这可能是巧合，也可能不是。

关于派生数据，我还想让人注意所构建的索引类型，比如用于 blame 的索引。需要这么做是 Bonsai 数据模型的自然结果，所以要构建索引并不奇怪；我要强调的是术语和表述方式上的惊人相似，因为我在 Meta 源代码控制团队时，确实就是这么思考这个问题的。

另一组相似之处在服务端 API 上，用于执行版本控制查询和变更。Mononoke 实现了这一点，但我认为在 Mononoke 之前的其他系统也有，所以我不宣称这是我们的独创。不过，如果你做的事就是让 Claude 对着 Mononoke，然后要求它重建这套东西，那你设计出来的 API 大概也会非常相似。

Bonsai 数据模型极其反主流。 我要强调的是，源代码控制领域的主流共识是类 Git 的数据模型。在 2018 年，构建预写日志风格的 Merkle DAG 与当时所有人做的东西都相差极远，并且过程中必须解决几个难题，比如如何执行服务端 rebase（据我所知，这是 Mononoke 几项新算法之一）。2018 年我带领团队设计并实现这个模型时，曾亲自向 Meta 的好几层管理层做解释。能让隔级上级被拉来深入讨论一个系统的数据模型，是相当罕见的事。

Bonsai 数据模型也极其成功。 差不多十年过去，这个模型被远远拉伸到最初设计参数之外，却仍在稳定运行。当年团队构建它的工作，至今仍是我职业生涯中最自豪的成就之一。鉴于人员有重叠，Scion 团队不可能不知道这些。（所以他们照搬也完全合理！）这就引出了我的下一点：

问题在于署名，而不在于抄袭。 我在原文里提到过，好想法被抄袭，我完全无所谓。让我无法接受的是，作品的“序列号”被无意中抹去；而如果是故意抹去，那当然更不能接受。

只把功劳记给 Sapling 的“来之不易的教训”是不够的。 有人指出 Mononoke 是 Sapling 生态的一部分。问题在于，Sapling 既可以指 VCS 客户端（sl，最初从 hg 分叉而来），也可以指整个系统。如果你曾在 Meta 源代码控制团队待过，绝对清楚两者的区别。更何况，Scion 的相似程度远远超过“来之不易的教训”这个说法。Lore VCS 可以说受到了 Mononoke 的启发，但它在若干方面也有不同。Scion 与 Mononoke 的相似远远超出这种程度；仅仅把“来之不易的教训”归功于 Sapling（甚至连 Mononoke 都没提）是不诚实的。（具体来说，我认为 Scion 讲 changeset 的那部分应该说明，它们复制自 Bonsai changeset。）

这让 Anthropic 的成就大打折扣。 任何把分布式系统推上生产环境的人都知道，在生产化过程中会冒出多少问题。“我们的 LLM 造出了这东西，把它生产化，并在 5 个月里解决了所有随之而来的挑战”，这种说法比“Meta 的源代码控制团队花了 10 年构建并生产化这个系统，而我们能把 LLM 对准它、在 5 个月内重建出来”要有说服力得多。

……但它依然是一项相当了不起的成就。 能够对着一个现有系统，在这么短的时间里重建它，依然相当惊人。让我震惊的是，Anthropic 居然没有直接说他们抄了 Mononoke，然后在 5 个月内重建出来。即便没有那么宏大，这也仍然值得注意。他们难道不知道自己会被揭穿吗？

把自己的工作放在更大的背景中，总是好的。 我们都是站在巨人的肩膀上！借用并改造现有工作、把它适配到新环境，这并没有错——作为工程师，我做的绝大部分工作就是如此。当你把自己的工作定位为衍生作品时，你是在承认前人的贡献，正如你希望后来者也会承认你一样。

没有团队，就什么都不是。 说点个人感受：我离开 Mononoke 已经很多年了。这么多年过去，仍有一个团队在薪火相传。Anthropic 把 Bonsai 数据模型抄走，对我打击很大，但也请想想现在还在做这个项目的团队：他们才是最直接被剽窃的人。想象一下，看到自己的工作被他人蓄意整体抄走、还被故意说成是别人的成果，他们会是什么感受。

我最早在 Bluesky 和 LinkedIn 上发这件事，已经过去两天了，但对方那篇原文章至今还没有更新。这依然是大型 AI 公司侵占公共成果、把别人的工作说成是自己的又一个可耻例子。我不知道要从这里重新搭建桥梁需要什么，但我现在的默认假设是：Anthropic 公开的技术分享大多都是不怀好意的抄袭。这真令人遗憾。

讨论明显分裂：较多人质疑 Anthropic 的 Scion 未充分致谢地借鉴甚至照搬 Meta 的 Mononoke/Sapling，并抨击其一面反对模型蒸馏、一面拿开源成果的双标；但也有较多人认为这只是在开源许可下的正常思想借鉴，Anthropic 已注明灵感，算不上抄袭。

认为 Anthropic 未充分致谢地抄袭，且对待蒸馏问题双标

• Anthropic 的 Scion 被指大量借鉴 Meta 的 Mononoke/Sapling 设计，却没有足够署名；更引发不满的是，Anthropic 一直抱怨外界对其模型做蒸馏，自己却把开源社区的既有成果收进闭源工程叙事，被视为大型 AI 公司侵占公共成果、虚伪双标。（较多人） > “Anthropic 要怎么为这样公然拿走别家公司成果辩护，尤其还不给署名？他们自己一直在对别人的蒸馏行为满腹抱怨。”（@HarHarVeryFunny）

认为这只是开源许可下的正常借鉴，不算抄袭

• 反对抄袭指控：Sapling 本身是 GPL 开源项目，在开源项目里主张对抽象思想的所有权被指是概念混淆；只要遵守许可证，使用者并没有义务逐一署名灵感来源，而 Anthropic 原文其实已写明借鉴 Google Piper 与 Meta Sapling 的经验。开源项目的正常借鉴被形容为无谓闹剧，原帖反而像“酸葡萄”。（较多人） > “在开源项目里主张对抽象思想的所有权是概念混淆；只要遵守许可证，就没有义务署名。”（@theptip）
• 也有人从信息系统角度认为，这更像并行发明或对同一问题最优解的趋同：若优化目标相同，不同团队最终会收敛到相似设计，未必是谁抄谁。（少数人）

认为批评者 Meta 同样虚伪，没资格以公共领域名义指责

• 有人指出，发帖批评者来自 Meta——一家本身被视作惯于破坏社会公共领域的大型 AI 公司；由它来指控 Anthropic 侵占公共成果，被认为是缺乏自省的双重标准。这与 Anthropic、OpenAI 被指在违反知识产权建好模型后，又对他人蒸馏感到愤怒如出一辙。（少数人） > “最恶劣公司之一的员工抱怨另一家可能最恶劣公司未署名拿走东西，这恰恰呼应了 Anthropic 和 OpenAI 违反知识产权建好模型后，又对他人蒸馏暴怒。”（@jsrozner）

认为更深层问题是公共知识被私有化，且 LLM 自研叙事掩盖依赖

• 即便人员流动让 Anthropic 招到懂 Mononoke 的人、设计借鉴难以避免，真正争议仍在于：这些能力被装进带“投币口”的私有系统，播种者并未分到果实；放到 AI 工程看，模型产出几乎都建立在人类公开分享的成败经验之上，“LLM 自研”的叙事反而遮蔽了这种依赖。（少数人） > “这个‘井’旁边装的是投币计费器，而不是公地；种下种子的人分不到果实。”（@gopalv）

有价值的补充

• 反直觉点：即便 Mononoke/Sapling 的设计已存在，Anthropic 仍花了约 5 个月、7 名人力才做出 Scion；这意味着对当前编码智能体来说，给定现成详细设计也并不能自动把系统实现出来，所谓“LLM 自己造了系统”的能力被高估。（@HarHarVeryFunny）
• 技术事实：开源版 Mononoke 与 EdenFS 在 Meta 之外并不真正可用；有人几年前为大 monorepo 评估后认定无法工作而搁置，因此 Anthropic 若真要用，选择重写而非直接采用 Sapling 代码库是合理的。（@fcarraldo）
• 设计差异：Scion 是从已有的大型 Git 仓库出发，而非像 Mononoke 那样基于 Mercurial，因此在数据结构之外还需要许多新设计；作者强调并非让 Claude 直接生成，并已补充脚注说明沿用 Meta 对系统的称呼来致谢。（@nickg-anthropic）
• 面向未来的提议：若真为开源场景重做版本控制，需要考虑海量开发者用编码智能体提交缺陷报告或补丁；接受补丁时应要求可验证的溯源信息，例如编码智能体的签名会话、所用提示与改动代码的配对，这样开源维护才能更去中心化。（@espeed）