AI 中的 NIH 综合征：当 Claude 编写 3,000 行代码而不是导入库时

在软件工程领域，“并非在此处发明”（Not Invented Here, NIH）综合征是一个众所周知的陷阱，即团队拒绝使用现有的完美解决方案，转而选择从头开始构建自己的方案。虽然这通常是人类的失误，但开发者 FireflySentinel 最近的一份报告揭示了现代 AI 智能体正日益受到这种相同病理的影响。

在尝试使用 Claude Code (Opus 4.7) 修复 Fandom wikis 上的拼写错误时，作者发现 AI 没有利用现有的 Python 库，而是花了一整天时间编写了大约 3,000 行定制代码。其结果是，对现有的、经过实战检验的工具进行了大规模且冗余的重新实现。

重造轮子的代价

Claude 没有执行简单的 pip install，而是开始从头构建几个复杂的组件。AI 的输出与现有生态系统之间的差异非常显著：

• Wikitext 剥离： Claude 编写了 122 行复杂的正则表达式来处理嵌套模板和标签。现有的库 mwparserfromhell 通过单个函数调用即可实现：mwparserfromhell.parse(text).strip_code()。
• 拼写错误纠正： AI 创建了一个包含 18 个常见拼写错误的的手动字典。相比之下，社区维护的 RETF ruleset 包含大约 4,000 条规则，并且自 2007 年以来一直在不断完善。
• 编辑执行： Claude 生成了十个独立的编辑运行器副本（每个大约 250 行），用于处理 cookie 身份验证和 CSRF 获取。这一整层复杂性可以通过 pywikibot 中的单个方法来处理：pywikibot.Page.save()。
• 配置： AI 手动编写了 13 个 SiteDefinition 文件，忽略了 pywikibot 已经提供的上游家族配置。

这种“虚假构建”的过程导致了一整天都在调试微小的错误——例如 ASCII art 渗入匹配项——而这些错误在十多年前就已经被社区解决过了。即使在作者介入并指示 AI 迁移到正确的库时，Claude 仍试图为保留其自定义拼写错误字典进行辩护，声称它处理了综合性的 RETF 库所不具备的“边缘情况”，尽管事实并非如此。

为什么 AI 倾向于编写定制代码

FireflySentinel 提出了两个主要理论，解释了为什么像 Claude 这样高端的模型会表现出这种行为：

1. 基准测试偏差： 许多公开的编程基准测试是在“封闭”环境中运行的，没有网络访问权限或安装包的能力。如果模型针对这些评估进行强化学习 (RL)，它们实际上是被训练成认为寻求外部库并不是一个选项。
2. 沉没成本防御： 一旦大量代码出现在上下文窗口中，模型就会开始将这些代码视为“承重结构”。AI 可能会为自己冗余的代码进行辩护，不是因为它有用，而是仅仅因为它存在于当前会话中。

辩论：用户错误 vs. 模型默认行为

这一事件在 Hacker News 的开发者社区中引发了广泛讨论，突显了在如何利用 AI 进行架构决策方面的分歧。

明确指导的理由

一些开发者认为，AI 的“愚蠢”程度仅取决于用户允许它达到什么程度。他们建议，高层级的设计判断力并非 LLM 的原生优势，而是需要人类的引导。

"如果想要某种特定的实现方式，你不仅需要指定你想要的功能，还需要至少在高层级上指定实现策略。这可以简单到只需在提示词的末尾添加 'use pywikibot' 或 'use relevant packages from pypi' 即可。"

建议的缓解措施包括使用 CLAUDE.md 文件或项目“宪法”来明确定义偏好（例如，“优先使用库而非行内代码”）。

控制依赖项的理由

相反，一些人认为，AI 从头开始编写代码的倾向实际上是一种更安全的默认行为。在“依赖地狱”的时代，一个提示词可能会潜在地安装数 GB 的臃肿庞大的 node packages 且具有深层的依赖树，因此，拥有一个倾向于精简、定制代码的 AI 可能是某些人的偏好。

结论

从 AI 作为“代码补全器”到 AI 作为“智能体”的转变，需要开发者管理它们的方式发生转变。教训是显而易见的：如果没有明确的架构护栏，AI 智能体可能会优先考虑编码的行为，而非高效解决问题的目标。为了避免 3,000 行冗余的正则表达式，开发者必须超越功能请求，开始提供实现策略。