2019年深秋，游戏程序员 Casey Muratori 在自己的频道 Molly Rocket 上传了一条二十多分钟的独白视频，标题像一道费解的数学题：The Thirty Million Line Problem（三千万行代码问题）。他的论点当时听着刺耳：支撑你每天点开的每一个软件的，是一套大约三千万行、没有任何一个活人读得完的代码。软件越来越慢、越来越重、安全破绽越来越多，病根不在于程序员变笨了，而在于这种“没人读得懂”的规模本身。
按常理，这该是一条很快被时间埋掉的视频。恰恰相反，六年过去，它被翻出来重看的频率越来越高：AI 写代码让“随手引一个依赖”的成本降到了接近零，JavaScript 生态的目录黑洞越撑越大，开源供应链投毒事件接连爆雷。2019 年那段独白，今天读起来像一份提前六年发出的体检预警。
对每天写代码——或者让 AI 替自己写代码——的人来说，这二十分钟回答的是一个根本问题：你所依赖的那几千万行代码，出了事，你敢不敢、能不能对它负责？这条视频没有给答案，它给了你一套提出这个问题的方法。
| 项目 | 内容 |
|---|---|
| 视频标题 | The Thirty Million Line Problem（三千万行代码问题） |
| 频道 | Molly Rocket |
| 主讲人 | Casey Muratori，游戏行业出身的程序员、编程教学项目 Handmade Hero 作者、开源社区“手工软件运动”的发起人之一 |
| 发布时间 | 2019年（以视频页为准） |
| 时长 | 约 20 分钟独白 |
| 播放数据 | 百万级观看，长期被程序员社区引用（以视频页实时数据为准） |
| 观看方式 | YouTube 搜索 "Casey Muratori Thirty Million Line Problem" |
先交代主讲人的分量。Casey Muratori 不是那种只会出嘴的知识区博主：他从游戏行业一线写代码写上来，2014 年开了著名的 Handmade Hero 项目——从零开始、直播手写一个完整的商业级游戏，一行一行地写，写了数年，被称为“最长的一堂编程课”。他也是“手工软件”（Handmade）社区的发起人之一，这个社区的核心信条只有一句：软件应该像手工家具一样被理解、被亲手打磨，而不是像预制板一样层层拼装。这条视频，就是这套信条最系统的公开陈述。
视频的论证是一条清晰的因果链，可以拆成四步。
视频开场先立靶子：你最近在用的那个软件，一共有多少行代码？ Casey 给出的量级是：一套现代操作系统所牵涉的代码，大约在三千万行的规模。这个数字意味着什么？按一个职业程序员一天读几百行并真正理解的速率，读完它需要几辈子。
他真正的重点不是这个数字本身，而是我们对待它的态度：三千万行，没有任何一个人知道里面全部装着什么，但全世界的银行、医院、电站都跑在它上面——而大家觉得这很正常。在他看来，这才是最反常的地方：一个没人能全懂的系统，成了文明的承重墙。
怎么让人类协作写出一个没人能全懂的系统？工业界的老答案是抽象：你不需要懂底下的三千万行，你只需要会调用那层封装好的接口。操作系统封装硬件，运行库封装操作系统，框架封装运行库，包管理器封装框架。每个人只看见自己头顶那一层，分工于是成立。
Casey 承认抽象是必需品，但他指出这个机制在悄悄变质：抽象的粒度出了问题。你需要的是“把一段日志写进文件”，库给你的却是一整套配置体系、一整套生命周期、一整套你永远用不到的通用能力。为了芝麻大的功能，你把一整个“解决方案”拖进了项目。层与层之间的接缝，就是复杂度的藏身处：每多一层，就多一份你无法阅读、无法修复、甚至无法察觉的代码。
他的判词是：抽象本来是给人减负的，现在变成了把陌生人的代码塞进你项目的传送带。
抽象层落到今天的开发日常里，就是依赖。Casey 对着现代包管理生态开火：你的项目代码可能只有几千行，但拉进来的依赖树可能有几十万行——这些代码由谁写的？可能是某个天才，可能是某个学生的周末练手项目，可能是一个早就失去兴趣、再也不会维护它的人。而这些代码会在你的产品里运行很多年。
这里有个著名的黑色幽默，后来被画成了 xkcd 第 2347 号漫画：一栋所有现代基础设施都压在上面的小平台，支柱是一个“网上某个无名人士的业余项目”。 Casey 在 2019 年讲的就是这件事的结构性问题：依赖树上的每一片叶子，质量、动机、存续状态，全部不可见。你 import 的不是代码，是一份你从没读过的合同。
视频最后把账单摊开：
视频没有停在骂街。Casey 给出的出路有两个关键词。
第一个是手工精神（Handmade）：自己的问题，尽量自己写。不是让你重写一切，而是把默认值倒过来——默认不依赖，依赖必须值得。你业务里最核心的那一小块，值得你亲手写、亲手懂，而不是 import 一个全家桶。
第二个是他提出的“语义压缩”式写法：让代码贴合你的真实问题，而不是贴合某个假想的通用场景。从最具体、最朴素的代码写起，等同样的模式第三次出现，再把它们收拢成抽象。这样长出来的抽象，每一段都对应一个真实需求，没有为“将来可能用到”预付的复杂度。顺带一提，这也是社区里流传的“三次法则”（Rule of Three）的正统出处之一。
这条视频不是凭空开炮，它的每个论点都能在软件工程几十年的文献和事故史里找到亲戚。
本质复杂度与偶然复杂度。 Fred Brooks 在 1986 年的著名文章《No Silver Bullet》（没有银弹）里把软件复杂度分成两种：问题本身固有的“本质复杂度”，和工具、抽象、流程带来的“偶然复杂度”。Brooks 的结论是本质复杂度砍不掉。Casey 的矛头其实只对着后一半：过去四十年，我们的工具在消灭偶然复杂度的名义下，生产出了天量的新偶然复杂度。
“过早优化”的另一面。 Donald Knuth 在 1974 年写下那句被引用到烂的名言——“过早优化是万恶之源”。有趣的是，Casey 的立场像是把这句话对折了一下：过早抽象同样是万恶之源。为一个尚不存在的需求预先设计的通用性，和为一台不存在的机器手工调优的循环，是同一种病。
兼容税的第一手记录。 Windows 的元老博主 Raymond Chen 在专栏 The Old New Thing 里记录过无数 compat 案例，最著名的一个：Windows 95 团队发现《模拟城市》总会崩溃，追查后发现问题出在游戏当年写代码时耍的一个小花招，而游戏厂商早已无人在意。微软的解法是在系统里塞进一段“如果检测到是《模拟城市》，就换一种内存回收方式”的特殊处理。你今天用的系统里，塞着成千上万段这种为古董程序开的“后门”。这就是三千万行里最重的那部分。Linux 阵营同款铁律：Linus Torvalds 2012 年在一封著名的邮件里咆哮出的那句话——"we do not break userspace"（我们不弄坏用户态）——是同一个逻辑的内核版。
Hyrum 定律。 谷歌工程师 Hyrum Wright 总结的经验定律：当一个 API 的用户多到一定程度，它的所有可观察行为——包括 bug——都会有人依赖。这条定律精确解释了为什么三千万行动不得：不是维护者懒，是每一行都可能已经是某个下游系统的承重墙。
重写惨案。 Joel Spolsky 2000 年的檄文《Things You Should Never Do》复盘了网景的死亡：1998 年，网景决定推倒重写整个浏览器，旧代码一行不留。Joel 的论点毒辣而准确——旧代码里那些看似愚蠢的行，往往是修过的 bug，是踩过的坑的化石；重写等于把这些学费全部重交一遍。网景的这一把交掉了市场，等 Firefox 在 2004 年底扳回一城，战场早已易主。Casey 对“轻率引依赖”的批判，和 Joel 对“轻率重写”的批判，是同一条原理的两面：对已经工作的复杂度要有敬畏。
Worse is Better。 程序员 Richard Gabriel 那篇著名的《Worse is Better》论证过一个反直觉的事实：实现更简单、接口更糙的系统（Unix 与 C），恰恰因为简单好移植而统治了世界。把这条和 Hyrum 定律叠起来看，你会发现 Casey 说的“三千万行”其实是一场胜利的副产品——正因为简单的东西赢了，它才被用到远超设计预期的规模上。
证据扎实的部分。依赖风险的实证已经很充分：left-pad 事件（2016 年，一位开发者与平台发生纠纷后撤包，一个 11 行代码的小包让全球数千个项目构建失败）和 xz 后门是教科书级案例；“现代应用臃肿”是每个用户的共同体验；兼容税有 Raymond Chen 一线记录背书。这些主张，可以放心接受。
需要打折的部分。
第一，“三千万行”是个修辞数字。不同口径统计出的系统代码量差异巨大；有意思的是，据社区统计，Linux 内核到 2020 年代中期也长到了这个量级——Casey 当年随手引用的数字，如今恰好是整个开源世界共同依赖的地基的体量。这个数字的修辞意义大于工程意义：它的作用是让你对“不可读的规模”产生体感，而不是一个精确的工程参数。
第二，“自己写”有隐形成本。通用库背后是多年的安全审计和 bug 修复积累，这些不会出现在你的代码行数统计里。密码学领域有句铁律：“自己发明加密等于自动放弃安全性”——在加密、协议解析这类专业深水区，自己写不是勇敢，是鲁莽。OpenSSL 自己也出过 Heartbleed，说明“亲手写”并不自动等于“更安全”，它只是换了一种风险组合。
第三，样本偏差。Casey 的经验来自游戏和系统软件——一个对性能、对每一毫秒都要负责的领域。把“能自己写就自己写”原样搬到 CRUD 业务系统里，很可能沦为昂贵的情怀。对大多数业务开发来说，核心矛盾不是性能，而是交付速度与可维护性的平衡，此时“用成熟的依赖”常常仍然是对的选择。
第四，手工运动本身也受到批评——有人说它是精英主义的复古，毕竟不是每个团队都养得起“把轮子重造一遍”的人力。这条视频的价值，不在于让你照单全收它的结论，而在于它把“默认引依赖”这个从不过脑子的行业惯性，重新变成了一个需要论证的决定。
启示一：给你的项目建一份“依赖预算”。引入任何依赖前过三个问题：它替我解决了多大的一个问题？它出事时，我能不能在一小时内定位甚至自己修？五年后还会有人维护它吗？三个问题有两个答不上来，就先不引。顺手做一件具体的事：用依赖树工具（npm 的 npm ls、Python 的 pipdeptree）把项目的完整依赖树打出来看一眼——大多数人的第一反应是沉默。警惕“为了一个函数引全家桶”式的依赖，那正是 Casey 说的粒度错配。
提示二：按“三次法则”写代码。第一次和第二次重复，忍住，老老实实写两份具体代码；第三次出现同样的模式，再抽象。用真实出现的需求驱动抽象，而不是用想象中的需求。对 AI 时代的写码者，这一条还要加个后缀：AI 能替你生成贴合问题的代码，让“自己写”的成本降到历史最低——所以读完 AI 交给你的每一行，比以往任何时候都更可行，也更必要。vibe coding 可以有，vibe 依赖不行。
启示三：把“敢不敢改”当作质量指标。代码评审时多问一句：这一块如果出了问题，我们能不能快速定位到行并安全修复？如果一个模块“坏了你都不知道从哪儿查起”，它就已经是那个三千万行问题在你项目里的分身。规模不是问题，不可理解的规模才是。
flowchart TD
A[三千万行代码<br/>无人读得完] --> B[解法：分层抽象<br/>复用外部依赖]
B --> C[抽象粒度错配<br/>代码与问题脱节]
B --> D[依赖树失控<br/>质量与动机不可见]
C --> E[软件变慢变重<br/>没人敢动旧代码]
D --> F[供应链投毒<br/>一环出事全网陪葬]
E --> G[兼容税越滚越大<br/>历史包袱锁死演进]
F --> H[药方：手工精神<br/>自己的问题自己写]
G --> H
H --> I[语义压缩<br/>按真实需求长抽象]
H --> J[依赖须过审<br/>少一层依赖少一层险]
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。