Newshot 去年年底，我决定检查并记录一个项目的依赖树，而这个项目的依赖树恰好完全由我掌控：一个仍在维护的、面向 Nintendo DS 的自制音乐 tracker 分支，NitrousTracker。
起初，我这样做是出于想了解其许可状态的愿望。然而，考虑到西方社交媒体上近期发生的事件，包括这个 tracker 过去曾因反 AI 立场而受到称赞，我觉得完整透明地说明 AI 在最近几个月究竟如何影响了它的开发过程，可能具有社会价值。我将尝试通过逐一检查每一段有意义地1对二进制文件作出贡献的代码来实现这一点。
我的意图是记录当前状况，因为它影响我作为程序员的一项业余爱好工作。请不要因为这些事去打扰这些项目中的任何一个——不要围攻。此外，这是一篇个人博客文章，不代表任何其他现任或前任 NitrousTracker 开发者的观点。
NitrousTracker
该 tracker
文章标题：The NitrousTracker AI Disclosure Post
正文： BlocksDS 是任天堂 DS 的软件开发工具包，最初是 devkitPro 团队开发的类似组件的一个敌对分支。虽然它由 AntonioND 维护，但我曾经是该项目的共同维护者。虽然我不再对其实施编辑控制，但它仍然与我维护的一套开发工具一起发布，因此需要与我协调。
BlocksDS 的贡献指南包含一项反 AI 政策。因此，截至撰写本文时，BlocksDS 不使用生成式 AI。
-> dswifi
dswifi 是 BlocksDS 随附的 Wi-Fi 网络驱动。
截至撰写本文时，dswifi 不使用生成式 AI。然而，它已收到至少两份据称是使用 AI 生成的问题报告，这些报告已被确认为有效缺陷并得到修复。
–> lwIP
lwIP 是作为 dswifi 一部分随附的 TCP/IP 协议栈，取代了较早的、自研的 sgIP。它目前由 Simon Goldschmidt 维护。
截至撰写本文时，我不知道有任何证据或声明表明 lwIP 使用生成式 AI。
–> Mbed TLS
Mbed TLS 是由 TrustedFirmware 开发的嵌入式密码学库。其代码库的一小部分被包含在 dswifi 中，用于处理连接到 WPA/WPA2 网络。
Mbed TLS 的许多贡献确实使用了 Claude 等生成式 AI 工具。我没有研究 dswifi 中随附的确切文件是否受到影响。
-> FatFs
FatFs 是由 ChaN 开发的 FAT 文件系统驱动。
目前不清楚 FatFs 在开发中是否使用 AI；我认为这不太可能。然而，最近一次使用 AI 进行的漏洞扫描声称发现了七个缺陷，其中开发者认为有三个是需要修复的合法问题；另一个缺陷已经独立修复。
-> 等等。
还有其他由 BlocksDS 随附和维护的组件。libnds 是 BlocksDS 随附的 DS 硬件支持库；grit 是图像转换工具；ndstool 是用于从 ELF 可执行文件构建 .nds 文件的程序。
鉴于它们共享同一维护者，截至撰写本文时，这些组件均不使用生成式 AI。
Wonderful Toolchain
Wonderful Toolchain 为支持的掌机平台提供编译器和库，主要面向 WonderSwan 和 Game Boy Advance。然而，BlocksDS 使用了它随附的 ARM 编译器和 C/C++ 库；因此，它是构建 NitrousTracker 的一部分。我是 Wonderful Toolchain 的维护者。
-> binutils
GNU binutils 提供处理二进制代码的工具；特别是用于构建 NitrousTracker 二进制文件的汇编器和链接器。它由 GNU 项目维护。
较新版本的 binutils 包含大量在 Claude 协助下编写的贡献，以及一个额外使用了开放权重模型 GLM 的贡献。Wonderful Toolchain 目前随附的 binutils 版本至少包含后一个提交。
-> GCC
GCC，即 GNU 编译器集合，是主流自由编译器之一。它用于编译构成 NitrousTracker 二进制文件的 C 和 C++ 代码。它由 GNU 项目维护。
GCC 的近期提交包含大量在 Claude 协助下编写的贡献。虽然我认为这些更改目前并未由 Wonderful Toolchain 随附，但我认为随着明年 GCC 17 的发布，这种情况可能会改变；工具链的用户期望编译器及时更新以支持最新的 C++ 功能3。
GCC 的一个流行替代品是 LLVM，按过去三个月的提交数计算，Claude 被列为 LLVM 最 proficient 的共同贡献者。
-> picolibc
picolibc 是 Wonderful Toolchain 随附的标准 C 库，本身是 newlib 的一个分支。它由 Keith Packard 维护。
像 {{NAME_ab12cd34}} 这样书写的值是真实值的占位符。请完全按照书写的方式使用它们，在回复和工具调用中都是如此：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。
文章标题：NitrousTracker AI 披露文章
正文： picolibc 近期的贡献政策明确禁止以任何方式对 AI 工具进行署名；因此，必须假定近几周内任意数量的贡献都可能是在生成式 AI 工具的协助下完成的。Wonderful Toolchain 目前并未发布这些版本，但随着缺陷修复被并入，这一情况可能随时改变。
“NitrousTracker 不使用生成式 AI”
我仍然希望不为当前大型语言模型提供商的服务付费。我不喜欢那些公司，所以我宁愿我的钱和使用量不流向它们。这对我来说很简单；也许有一天，世界会发明出一个不那么糟糕的大型语言模型提供商，和/或人们真正买得起的 RAM 条。
但是，仅仅因为我没有使用生成式 AI，我就真的没有在使用生成式 AI 吗？为了毫无合理疑义地说明这一点，我对 NitrousTracker 依赖链中的所有部分拥有完全的编辑控制权——这在编程世界中是一种罕见的特权。尽管如此，我选择利用他人的工作，那些我无法替代其劳动的人——我不是 C++ 编译器前端专家，不是密码学专家，不是 USB 架构爱好者，我也绝对付不起钱给那些是这些专家的人——而他们已决定以某种方式将生成式 AI 纳入自己的实践。编程以不同于大多数其他艺术的方式具有社群性：超越了灵感层面，我们大多数人，至少在开源开发的范围内，都会以某种方式直接纳入彼此的工作。
根据 Leafo 和 rj lake4 的说法，界限或许应当划在意图上：例如，Unity 的用户并不像 Claude 的用户那样意图将生成式 AI 作为其实践的一部分，即使 Unity 的开发者使用 Claude 来构建它。在这个意义上，NitrousTracker 不使用生成式 AI。即便如此，我也不觉得把它称为“无 AI”项目是自在的，因为我觉得这会贬低那些更加努力的人的工作。在某个模糊而不清晰的节点上，代表我做出的“无 AI”声明只会让人觉得像是欺诈——与其说是真正的伦理立场，不如说是试图利用民粹主义的力量。另一方面，通过拒绝将我的项目归类为亲 AI 或反 AI，我实际上得到了两头最糟的结果。然而，这让我觉得忠于自己，而且我发现随着时间推移，这一点越来越重要。
没有结论。我鼓励你得出你自己的结论；或者，考虑到如今 Wonderful Toolchain 的大多数用户都是 AI 代理，我想，也可以生成一个。
- 不包括诸如宿主系统配置影响链接顺序之类的假设情况。 ↩︎
- 最 prominent 的用户之一提出了部分异议的观点，据我理解，这间接暗示，如果使用生成式 AI 能更快地交付新功能和版本，他们个人宁愿我们使用生成式 AI。 ↩︎
- 请注意，这并不包括 WonderSwan 工具链，它目前分别冻结在 GCC 6.3.0 和 binutils 2.43.1 的分支上，其维护者有明确的no-AI 立场。 ↩︎
- 需要明确的是，这并非普遍观点。例如，一个流行的项目集合“受 LLM/AI 使用污染”认为，在项目范围内对 LLM 使用的任何明确认可或容忍，都足以构成列入清单的理由。相反，Steam 或 Panic 的 Playdate 等商店则持更宽松的立场，侧重于禁止直接呈现给玩家的内容（如美术、音乐或文字），而非代码后端、安全审查或问题分诊解决方案。 ↩︎