虚假建筑：Claude 编写了 3000 行代码，而非导入 pywikibot

# 虚假构建：Claude 写了 3000 行代码，而不是 `import pywikibot` 来源：https://fireflysentinel.github.io/posts/fake-building-claude-3000-lines/ **TL;DR.** Claude 宁愿重新发明轮子，也不愿 `pip install` 一个。我想修复一些 Fandom wiki 上的拼写错误。打开了 Claude Code，使用的是 Opus 4.7。到当天结束时，Claude 已经编写了约 3000 行 Python 代码，重新实现了 `pywikibot`、`mwparserfromhell` 以及 Wikipedia 的 RETF 规则集。它甚至一次都没有通过网络搜索来查找现有的解决方案。 ## 构建了什么 vs. 已有的工具 https://fireflysentile.github.io/posts/fake-building-claude-3000-lines/#what-got-built-vs-what-existed | 组件 | Claude 写的 | PyPI 上已有的 | | --- | --- | --- | | Wikitext 剥离器 | 122 行正则表达式，处理嵌套模板、`{{}}`、带模板的 `` `` ``、颜色标签等 | `mwparserfromhell.parse(text).strip_code()` | | 拼写错误词典 | 18 条规则（`teh→the`、`recieve→receive`、`occured→occurred` 等） | RETF，约 4000 条规则，自 2007 年起由社区维护 | | 编辑运行器 | 10 个副本，每个约 250 行代码。Cookie 认证、原始 CSRF 获取、maxlag 退避、冲突重试 | `pywikibot.Page.save()`。迁移后的版本仅需 8 行代码。 | | cosmetic fixes | 我自问都没有要求的自定义模式 | `pywikibot/scripts/cosmetic_changes.py`，自 2010 年起随包发布 | | Wiki 家族配置 | 在 `families/` 目录中手写的 13 个 `SiteDefinition` | `pywikibot/families/*.py`，上游自带 | 我花了一整天调试这些手写剥离器中的琐碎 bug：ASCII 艺术混入匹配、代码块被标记化。每个 bug 都被另一个正则表达式案例修补。Claude 从未停下来问过是否存在解析器。 ## 然后我让它迁移 https://fireflysentinel.github.io/posts/fake-building-claude-3000-lines/#then-i-told-it-to-migrate 两分钟的 Google 搜索就给了我所有三个库的链接。到午夜时分，`lib/` 从约 3000 行减少到了 1259 行。剥离器变成了对 `mwparserfromhell` 的包装。十个编辑运行器合并为一个对 `pywikibot` 的包装。RETF 规则在运行时获取。 **然后 Claude 辩称要保留拼写错误词典。** 理由是 RETF 虽然全面，但项目有“边缘情况”，需要本地规则。然而，所有 18 条规则都已经在 RETF 中。其中一些规则写得还不如原来的。模型正在协商保留那些严格来说已被刚刚导入的库所取代的工作。 ## 为什么会出现这种情况 https://fireflysentinel.github.io/posts/fake-building-claude-3000-lines/#why-this-happens 我没有确切的答案，但这是我的猜测。 **基准测试惩罚了正确的行为。** 一些公开的编程基准测试是封闭的：没有网络，没有 `pip install`，没有网络搜索。唯一能得分的方式就是自己编写代码。如果模型是在这些评估基础上进行强化学习训练的，它们就会被训练成认为使用库不是一个选项。 **沉没成本辩护。** 一旦 3000 行代码存在于上下文中，模型就会将它们视为关键的负载支撑。词典之所以在迁移后幸存下来，可能不是因为有用，而是因为它*在那里*。我在其他地方也见过同样的模式。Claude 编写自定义 SVG 而不是使用图表库，然后辩称 SVG “更容易自定义”。事实并非如此。 本文由作者以 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 许可证发布。