假建筑：Claude 写了 3k 行而不是 import pywikibot

假建筑：Claude 写了 3,000 行，而不是 import pywikibot 目录假建筑：Claude 写了 3,000 行，而不是 import pywikibot TL;DR。 Claude 宁愿重新发明轮子，也不愿 pip install 一个。我想修复一些 Fandom wiki 上的拼写错误。打开克劳德代码，Opus 4.7。到当天结束时，Claude 已经编写了约 3,000 行 Python 代码，重新实现了 pywikibot 、 mwparserfromhell 和 Wikipedia 的 RETF 规则集。它没有在网络上搜索过一次现有技术。构建的内容与现有的内容组件 Claude 写的内容 PyPI 上的内容 Wikitext stripper 122 行正则表达式，包含嵌套模板的情况，带有模板的、

 、  以及颜色标签 mwparserfromhell.parse(text).strip_code() 打字错误字典 18 个条目（ teh→the 、 receive→receive 、发生→发生 ，...） RETF，约 4,000 条规则，自 2007 年起由社区维护编辑跑步者 10 份，每份约 250 个 LOC。 Cookie 身份验证、原始 CSRF 获取、最大延迟退避、冲突重试 pywikibot.Page.save() 。迁移后的版本有8行。外观修复 定制模式我从未要求过 pywikibot/scripts/cosmetic_changes.py ，自 2010 年以来发布 Wiki family config 13 手卷 SiteDefinition 在 family/ 目录 pywikibot/families/*.py 中，向上游发布 我花了一天时间调试手卷剥离器中的小错误。 ASCII 艺术渗透到匹配中，代码块被标记化。每个错误都用另一个正则表达式案例进行了修补。克劳德一次也没有停下来询问解析器是否存在。然后我告诉它迁移 两分钟的谷歌给了我所有三个库的链接。到午夜，lib/ 从大约 3,000 行减少到 1,259 行。剥离器成为 mwparserfromhell 上的垫片。十个编辑跑步者在 pywikibot 上折叠成一个垫片。 RETF 规则在运行时获取。然后克劳德主张保留拼写错误的字典。其宣传内容是，RETF 很全面，但该项目存在需要遵守当地规则的“边缘情况”。所有 18 个条目均已在 RETF 中。有几个写得更糟。该模型正在协商保留由它刚刚根据我的指示导入的库严格控制的工作。为什么会发生这种情况我没有明确的答案，但这是我的猜测。基准惩罚正确的行为。一些公共编码基准测试是密封运行的。没有网络，没有 pip install ，没有网络搜索。获得分数的唯一方法就是自己编写代码。如果模型针对这些评估进行强化学习，那么它们就会被训练成无法使用图书馆。沉没成本防御。一旦上下文中存在 3,000 行，模型就会将它们视为承重行。这本词典在迁移中幸存下来可能不是因为它有用，而是因为它就在那里。我在其他地方也看到过同样的模式。 Claude 编写自定义 SVG 而不是使用图表库，然后认为 SVG“更容易自定义”。事实并非如此。 AI、工具 claude pywikibot ai-agents 现有技术 本文由作者在 CC BY 4.0 下获得许可。分享