返回列表
🧠 阿头学 · 💬 讨论题 · 💰投资

DeepWiki、智能体与“细菌式代码”：库时代真的要结束了吗？

作者用一个成功“抠代码”案例，提出“库的时代式微、LLM 成新编译器”的判断，这在工程实务上是新选项但不是新常态，目前更像激进黑客范式而非主流软件未来。
打开原文 ↗

2026-02-12 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • LLM 直读代码 > 人类读文档，是已经发生的范式变化 作者认为库文档往往零散、过时且不完整，而代码才是唯一权威来源；DeepWiki 让 LLM 直接对仓库代码进行问答与检索，实际使用中对 torchao 等项目的理解效率显著优于查文档，这一判断与当下大量开发者体验基本一致。
  • “DeepWiki MCP + GitHub CLI + LLM”让“从大库精准抠功能”首次变得经济可行 文章展示了一个强案例：通过智能体从 torchao 仓库中“抠出” fp8 训练实现，得到 150 行自包含代码，接口兼容、带测试且性能快 3%，从而删掉对整个 torchao 的依赖；这证明“按需萃取小功能而非引入整库”在部分场景已经跑得通。
  • “细菌式代码”：为智能体优化的代码写作范式 作者提出未来可能有更多“细菌式代码”：更少纠缠、更自包含、更少依赖、更无状态，以便被智能体从大型仓库中精准分离和定制；这一判断抓住了 AI 辅助开发下“代码需更易被机器理解和重组”的真实趋势。
  • “库的时代结束、LLM 是新编译器”是口号化的强烈主张，而不是被充分论证的事实 作者从单一成功样本直接外推出“库的时代结束了，LLM 才是新的编译器”，但没有给出跨领域、跨规模的系统性证据，忽略了边界条件、维护、安全与合规等现实成本，这个判断目前更像观点宣言而非结论。
  • 软件可塑性确实被抬升，但代价是把“依赖风险”换成“维护与合规风险” “抠代码”看似减少了 100MB 依赖和配置复杂度，但同时引入了自维护代码、许可证合规、长期安全补丁同步等隐性成本；作者承认“有明显缺点与风险”但没有展开，实际问题比文中呈现的更严重。

跟我们的关联

1. 对 ATou：重新思考“调库 vs 自写”的边界 这篇文章提示你：在计算密集、逻辑相对封闭的场景（如数值核函数、转换模块）上，可以尝试用智能体从大库里抠一段自包含实现，换来更小依赖与更可控性能；下一步可在个人项目中选 1–2 个非关键模块做实验，顺便练“如何给 Agent 下精确技术指令”的能力。 2. 对 Neta：产品与架构选型的新维度 作为产品/技术决策者，你需要把“Agent 能否轻松从中抠出功能”纳入对技术栈和第三方库的评估维度；下一步可以在评审外部依赖时，多问一句：“这个库我真正只需要哪 5–10%？抠出来自己维护是否更经济？”并为团队尝试设计一条标准化的“功能萃取工作流”。 3. 对 Uota：代码风格与工程规范的前瞻调整 对关注长期工程质量的人，这篇文章说明：未来好的代码不仅要让人容易读，还要让机器容易拆；下一步可以在 code review 和规范中，加入“细菌式代码”指标（依赖少、接口清晰、状态边界明确），让新代码天然更适合被 Agent 分析和重组。 4. 对 ATou/Neta/Uota：投资与布局 AI 开发工具生态 无论你是开发者、产品还是关注投资的人，这里都指向一个清晰赛道：围绕“代码理解 + 功能萃取 + 自动测试生成”的 Agent 工具链；下一步可以关注或参与类似 DeepWiki / MCP 生态，尝试构建把“任意 GitHub 仓库”当作可编程知识图谱的工具或服务。

讨论引子

1. 在你现在负责的项目里，有哪些模块其实只用到了大库的 5–10%，如果有一键“抠出来 + 自动生成测试”的 Agent，你会愿意放弃库依赖吗？为什么？ 2. 对长期维护和安全要求高的团队，“细菌式代码 + 自包含实现”到底是降低风险（少依赖）还是增加风险（更多私有代码要自己维护）？ 3. “LLM 是新的编译器”这句话在你看来是合理隐喻、夸张宣传，还是未来 5–10 年有可能接近真实的技术路线？

这篇文章一开始算是对 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 的依赖吗？

On DeepWiki and increasing malleability of software.

This starts as partially a post on appreciation to DeepWiki, which I routinely find very useful and I think more people would find useful to know about. I went through a few iterations of use:

Their first feature was that it auto-builds wiki pages for github repos (e.g. nanochat here) with quick Q&A: https://t.co/DQHXagUwK0 Just swap "github" to "deepwiki" in the URL for any repo and you can instantly Q&A against it. For example, yesterday I was curious about "how does torchao implement fp8 training?". I find that in many cases, library docs can be spotty and outdated and bad, but directly asking questions to the code via DeepWiki works very well. The code is the source of truth and LLMs are increasingly able to understand it.

But then I realized that in many cases it's even a lot more powerful not being the direct (human) consumer of this information/functionality, but giving your agent access to DeepWiki via MCP. So e.g. yesterday I faced some annoyances with using torchao library for fp8 training and I had the suspicion that the whole thing really shouldn't be that complicated (wait shouldn't this be a Function like Linear except with a few extra casts and 3 calls to torch._scaled_mm?) so I tried:

"Use DeepWiki MCP and Github CLI to look at how torchao implements fp8 training. Is it possible to 'rip out' the functionality? Implement nanochat/fp8.py that has identical API but is fully self-contained"

Claude went off for 5 minutes and came back with 150 lines of clean code that worked out of the box, with tests proving equivalent results, which allowed me to delete torchao as repo dependency, and for some reason I still don't fully understand (I think it has to do with internals of torch compile) - this simple version runs 3% faster. The agent also found a lot of tiny implementation details that actually do matter, that I may have naively missed otherwise and that would have been very hard for maintainers to keep docs about. Tricks around numerics, dtypes, autocast, meta device, torch compile interactions so I learned a lot from the process too. So this is now the default fp8 training implementation for nanochat https://t.co/3i5cv6grWm

Anyway TLDR I find this combo of DeepWiki MCP + GitHub CLI is quite powerful to "rip out" any specific functionality from any github repo and target it for the very specific use case that you have in mind, and it actually kind of works now in some cases. Maybe you don't download, configure and take dependency on a giant monolithic library, maybe you point your agent at it and rip out the exact part you need. Maybe this informs how we write software more generally to actively encourage this workflow - e.g. building more "bacterial code", code that is less tangled, more self-contained, more dependency-free, more stateless, much easier to rip out from the repo (https://t.co/iKJUoHiIpl) There's obvious downsides and risks to this, but it is fundamentally a new option that was not possible or economical before (it would have cost too much time) but now with agents, it is. Software might become a lot more fluid and malleable. "Libraries are over, LLMs are the new compiler" :). And does your project really need its 100MB of dependencies?

这篇文章一开始算是对 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 的依赖吗？

相关笔记

This starts as partially a post on appreciation to DeepWiki, which I routinely find very useful and I think more people would find useful to know about. I went through a few iterations of use:

Their first feature was that it auto-builds wiki pages for github repos (e.g. nanochat here) with quick Q&A: https://t.co/DQHXagUwK0 Just swap "github" to "deepwiki" in the URL for any repo and you can instantly Q&A against it. For example, yesterday I was curious about "how does torchao implement fp8 training?". I find that in many cases, library docs can be spotty and outdated and bad, but directly asking questions to the code via DeepWiki works very well. The code is the source of truth and LLMs are increasingly able to understand it.

But then I realized that in many cases it's even a lot more powerful not being the direct (human) consumer of this information/functionality, but giving your agent access to DeepWiki via MCP. So e.g. yesterday I faced some annoyances with using torchao library for fp8 training and I had the suspicion that the whole thing really shouldn't be that complicated (wait shouldn't this be a Function like Linear except with a few extra casts and 3 calls to torch._scaled_mm?) so I tried:

"Use DeepWiki MCP and Github CLI to look at how torchao implements fp8 training. Is it possible to 'rip out' the functionality? Implement nanochat/fp8.py that has identical API but is fully self-contained"

Claude went off for 5 minutes and came back with 150 lines of clean code that worked out of the box, with tests proving equivalent results, which allowed me to delete torchao as repo dependency, and for some reason I still don't fully understand (I think it has to do with internals of torch compile) - this simple version runs 3% faster. The agent also found a lot of tiny implementation details that actually do matter, that I may have naively missed otherwise and that would have been very hard for maintainers to keep docs about. Tricks around numerics, dtypes, autocast, meta device, torch compile interactions so I learned a lot from the process too. So this is now the default fp8 training implementation for nanochat https://t.co/3i5cv6grWm

Anyway TLDR I find this combo of DeepWiki MCP + GitHub CLI is quite powerful to "rip out" any specific functionality from any github repo and target it for the very specific use case that you have in mind, and it actually kind of works now in some cases. Maybe you don't download, configure and take dependency on a giant monolithic library, maybe you point your agent at it and rip out the exact part you need. Maybe this informs how we write software more generally to actively encourage this workflow - e.g. building more "bacterial code", code that is less tangled, more self-contained, more dependency-free, more stateless, much easier to rip out from the repo (https://t.co/iKJUoHiIpl) There's obvious downsides and risks to this, but it is fundamentally a new option that was not possible or economical before (it would have cost too much time) but now with agents, it is. Software might become a lot more fluid and malleable. "Libraries are over, LLMs are the new compiler" :). And does your project really need its 100MB of dependencies?

📋 讨论归档

讨论进行中…