关于 DeepWiki 与软件可塑性的不断增强
这篇文章一开始算是对 DeepWiki 的一点致谢：我经常用它，觉得非常好用，也认为会有更多人受益。我对它的使用，大概经历了几轮迭代：
它最初的功能，是为 GitHub 仓库自动构建 wiki 页面（比如这里的 nanochat），并提供快速问答： https://t.co/DQHXagUwK0 你只需要把任意仓库 URL 里的 “github” 换成 “deepwiki”，就能立刻对它进行问答。比如昨天我就好奇：“torchao 是怎么实现 fp8 训练的？”我发现，在很多情况下，库的文档可能零散、过时、质量也不佳；但通过 DeepWiki 直接向代码提问，效果却非常好。代码才是权威来源，而 LLM 也越来越能读懂代码。
但后来我意识到，在很多情况下，更强大的做法甚至不是由（人类）直接消费这些信息/功能，而是通过 MCP 把 DeepWiki 接到你的智能体上。比如昨天我在用 torchao 做 fp8 训练时遇到一些烦恼，我隐约觉得整套东西不该有那么复杂（等等，这不就应该是一个像 Linear 那样的 Function，只是多做几次 cast，再调用 3 次 torch._scaled_mm 吗？）于是我试了试：
“使用 DeepWiki MCP 和 GitHub CLI 看看 torchao 是如何实现 fp8 训练的。有没有可能把这部分功能‘抠出来’？实现一个 nanochat/fp8.py，API 完全一致，但完全自包含。”
Claude 跑了 5 分钟，回来给了我 150 行干净的代码：开箱即用，还有测试证明结果等价。这让我可以把 torchao 从仓库依赖里删掉；而且出于某个我还没完全弄明白的原因（我猜和 torch compile 的内部机制有关），这个更简单的版本反而快了 3%。智能体还找到了很多确实重要的细小实现细节——如果我自己写，很可能会天真地漏掉；而维护者要在文档里把这些都解释清楚，也会非常困难。比如数值计算、dtypes、autocast、meta device、以及与 torch compile 的交互等方面的各种技巧，所以我也在这个过程中学到了很多。因此，这现在成了 nanochat 的默认 fp8 训练实现： https://t.co/3i5cv6grWm
总之，TLDR：我发现 DeepWiki MCP + GitHub CLI 这套组合相当强大，可以把任何 GitHub 仓库里的某个具体功能“抠出来”，并定向适配你脑海里非常具体的使用场景；而且在某些情况下，它现在确实能跑得通。也许你不必下载、配置并依赖一个庞大的一体化库；也许你只需要把智能体指向它，然后把你需要的那一小块精确“抠”出来。也许这会反过来影响我们更普遍的软件写作方式，让我们主动去鼓励这种工作流——例如写出更多“细菌式代码”：更少纠缠、更自包含、更少依赖、更无状态、也更容易从仓库里被抠出来（https://t.co/iKJUoHiIpl） 当然这有明显的缺点与风险，但从根本上说，它是一种以前不可能或不划算的新选项（因为会耗费太多时间），而现在有了智能体就做得到。软件也许会变得更流动、更可塑。“库的时代结束了，LLM 才是新的编译器” :). 以及，你的项目真的需要那 100MB 的依赖吗？