Roko's Dancing Basilisk 思想实验再引AI风险热议

背景

2025年12月2日，Hacker News上出现了一篇题为《Roko's Dancing Basilisk》的帖子，作者是一位拥有26年维护经验的老程序员，他测试了一个名为DeepWiki的网站——该网站声称可以为任意GitHub仓库自动生成“文档”。作者对LLM生成代码一直持保留态度，但对生成文档的效果感到好奇，于是用自己维护的两个项目（mod_blog和a09）进行了实测，结果发现了大量问题。

核心内容

第一次测试：mod_blog

作者首先用mod_blog（一个已有26年历史的C语言博客引擎，约7400行代码）进行测试。DeepWiki的使用方式很简单：输入仓库URL，提供邮箱接收通知，无需与聊天机器人交互。作者收到邮件后，看到了近30页的文档，总体概述令人印象深刻——它正确识别了tumbler存储结构、典型的新条目添加流程，甚至准确指出了cmd_cgi_get_today()函数会返回某个月份中所有日期对应的条目（跨年份）。但文档中有一个明显的错误：它声称“系统由三个主要层次组成”，但紧接着的示意图却显示了五个层次（Entry Layer、Processing Layer、Rendering Layer、Storage Layer、Configuration），且没有说明哪三个是“主要层次”。作者指出，这至少说明它数数有问题。

此外，作者对DeepWiki的网站界面评价不高：左侧菜单过长且滚动条设计过时；图表大小不一致，有的太小有的太大，布局混乱（水平、垂直、L形混用）；内容重复严重，甚至在同一页面内也反复出现。不过，作者也认可了部分优点：即使禁用JavaScript，页面仍可浏览（虽然图表会缺失、对比度低）；每个章节末尾都提供了指向源代码的链接，这是一个不错的细节。

关于文档本身，作者认为大部分正确，但存在若干小问题：

• 命令行示例中，如果$BLOG_CONFIG已设置，则不需要--config参数；但文档中关于$BLOG_CONFIG的检查位置写错了（实际在blog.c而非main.c）。
• mod_blog输出的是RSS 0.91，而非RSS 2.0。
• 文档称“核心引擎完全用C编写，没有Perl、Python或其他脚本依赖”，但作者实际上使用了Lua（仅用于配置文件）。
• 文档遗漏了SUID的使用方式（不是用于以root运行，而是作为博客所有者）。
• 文档对posthook脚本返回失败的解释有误：返回失败并不意味着条目未被添加，只是改变了返回的HTTP状态码。

更有价值的是，在审查DeepWiki生成的文档时，作者发现了两个代码中的实际缺陷：一个文件锁定的示意图暴露了缓存问题（实际代码中的bug），另一个是使用了字面常量而非定义常量。作者庆幸找到了这两个问题，尽管它们尚未造成实际可利用的漏洞（因为作者认为自己是mod_blog的唯一用户）。总体而言，对于可能只需10分钟生成的内容，结果不算太差。

第二次测试：a09

作者随后测试了a09（一个6809汇编器，约9500行代码，逻辑更复杂，且没有经过26年的持续改进）。这次发现的问题严重得多：

• 错误分类缺失：错误码是顺序按需创建的，没有固定范围。
• 死代码检测的关键要素被遗漏：它只会在下一条指令没有标签时才触发。
• 出现错误时，列表文件未被保留（文档描述错误）。
• 对生成输出文件的删除逻辑描述错误：实际只在pass 1或pass 2检测到错误时才删除，而非测试失败时。
• 同一页面内重复出现优先级表。
• 文档声称存在“不支持的markdown：blockquote”和“不支持的markdown：list”一元运算符，但实际代码中根本没有这些。
• 后端矩阵表完全错误：不仅支持/不支持标记搞反了，而且数据似乎是凭空捏造的；另一页上的相同信息也存在错误，只是程度稍轻，但格式不统一。
• RS-DOS版本的指令格式示例错误：类型和长度应各为2字节，而非1字节。
• -t选项的输出格式描述错误：除非使用了TRON指令，否则不会显示代码运行轨迹。
• 所有.ASSERT指令的示例都错了：没有使用正确的寄存器引用，内存解引用需要@（8位）或@@（16位）前缀。
• 关于.TRON指令可用位置的描述错误：它可以在任何位置使用；只有.OPT TEST TRON才限定在.TEST指令内使用。

作者认为，对a09的文档生成质量远差于mod_blog。他怀疑原因在于a09的圈复杂度更高（由于代码的横切性质），导致LLM的上下文窗口接近甚至溢出，从而产生幻觉（confabulations）。

对DeepWiki的总体评价

作者担心DeepWiki的目标用户是那些缺乏文档的遗留代码库。如果它在一个中等复杂但规模较小的代码库上都表现如此糟糕，那对于更大、更老、更复杂的代码库（比如作者手头一个约15.5万行、90年代初编写的C代码库）会是什么样子？作者表示自己不敢轻易尝试，因为面对那样的代码库，他无法自信地发现所有显眼错误，更别提更微妙的问题了。

另一个问题是仓库更新后的文档维护。DeepWiki自称是一个“wiki”，意味着用户需要花时间修正生成的文档，然后随着代码变化保持更新。但作者不清楚：在仓库变更后能否重新运行生成？如果能，更新是合并到现有文档中，还是彻底替换？如果是替换，那么之前修正的内容会丢失，需要重新修复。作者认为，这种生成的“文档”最终可能比代码中的糟糕注释还要差。以mod_blog为例，代码在26年间经历了至少三到四次重大重构（例如18年前去除了自定义IO层改用C标准FILE*，3年前移除了所有全局变量，最近一年则在删除不使用的功能），每次改动都需要重写大量文档。

关键要点

• DeepWiki能为GitHub仓库自动生成文档，使用简单（输入URL+邮箱），无需交互。
• 对于简单、经过长期维护的代码库（如mod_blog），生成结果大致正确，但存在细节错误（如层次计数错误、命令行参数、文件路径、输出格式等）。
• 对于逻辑更复杂、圈复杂度更高的代码库（如a09），错误率显著上升，出现大量幻觉，包括错误的语法、错误的数据、遗漏关键功能等。
• 作者认为LLM的上下文窗口限制可能是导致a09文档质量差的原因。
• 文档本身存在重复、图表不一致、布局混乱等界面问题，但提供了源代码链接等优点。
• 文档中甚至暴露了代码本身的bug（文件锁定问题、常量定义问题）。
• 对于大型遗留代码库，DeepWiki很可能不可靠，且维护更新困难（无法确定是否支持增量更新）。
• 作者整体认为，LLM生成文档虽比生成代码麻烦少一些，但准确性仍然不足以用于不熟悉的代码库——而这正是它声称的卖点。

意义与影响

这篇实测文章揭示了当前LLM在文档生成领域的真实能力边界。DeepWiki作为一款面向开发者的工具，其初衷是解决遗留代码库文档缺失的痛点，但从测试结果看，它存在以下问题：

1. 准确性受代码复杂度影响显著：简单代码库尚可，复杂代码库则错误百出，甚至可能误导开发者。
2. 幻觉问题突出：LLM生成的“事实”与代码实际行为不符，尤其在跨模块