2000 年，Joel Spolsky 写了一篇让整个硅谷记住他的文章《Things You Should Never Do, Part I》。他拿 Netscape 开刀，说这家公司花了三年重写浏览器，从 4.0 到 6.0。结果市场被 IE 吞掉，公司被 AOL 收购，一代霸主灰飞烟灭。Joel 的结论简洁得像一句咒语：永远不要从头重写代码。这条铁律被印进了每一本软件工程教材，刻进了每一代 CTO 的决策本能。
二十六年过去了。AI 正在把这条铁律撕碎。
不是 Joel 错了。是成本结构变了。
两条路径，两种命运
假设你要让 AI 帮你写一个新功能。原文作者给出了一个极其清晰的对比。
路径 A 很直接。AI 读需求规格，然后读代码库，前提是代码库清晰、一致、模式成熟，然后生成实现。路径 B 就麻烦了。AI 先读需求规格，再读代码库，但代码库杂乱、用了专有语言、背了一身历史包袱。AI 还得读额外示例和文档，然后才能开始生成实现。
路径 A 的 AI 在干正事：理解需求，匹配模式，输出代码。路径 B 的 AI 在干苦力。它先花一半的上下文窗口学会你的代码库长什么样，然后才能开始解决问题。
多出来的每一步都在烧 Token。更多上下文意味着更长提示、更多方差、更低质量的输出。也就是更高的成本和更烂的结果。
“Popular tech stacks have an AI advantage because the model has seen millions of examples, including published sources. The opposite is true for proprietary languages and private frameworks, with inconsistent patterns.”
——thetruthasiseeitnow.com
这不是理论推演。任何一个在 2026 年深度使用过 Claude Code、Cursor 或 GitHub Copilot 的工程师都能感受到这种差异：当你写一个标准的 React 组件时，AI 几乎不需要额外提示；当你面对一个充斥着内部 DSL 和老旧框架的项目时，AI 的每一次输出都需要反复修正。区别不在于模型的能力，而在于你的代码库和训练数据之间的距离。
Slop 不是 AI 的错，是你代码库的错
2026 年，科技圈突然开始高频使用一个词，AI Slop。它描述的是那种看起来没问题、跑起来也没报错、但架构上是一团浆糊的 AI 生成代码。它表面上加速了开发，却悄悄在系统里种下一颗颗技术地雷。
行业正在经历一场认知转向：Slop 不是 AI 的错，是你代码库的错。
CAST 在 2025 年 9 月发布的一份报告提供了令人窒息的数字。这家软件智能公司分析了超过 100 亿行代码，覆盖 17 个国家 3000 家企业的 47000 个应用，发现全球企业和政府机构累计积压了 610 亿个工作日的技术债务。45% 的代码被判定为脆弱代码，在遇到意外条件时极易崩溃。消费者体验到的每一次网站崩溃、表单提交失败，背后都是这些代码在失灵。
而当 AI 被部署到这些脆弱的代码库之上时，它不是在帮你写代码。它在帮你把混乱放大。大语言模型的工作原理不是理解你的业务逻辑，而是根据海量训练数据中的模式做概率预测。当你的代码库充满了不一致的命名规范、混杂的架构风格、过时的依赖关系和自创的方言时，AI 输出的稳定性会急剧下降。
MIT 的 NANDA 研究项目在 2025 年发布了一份引起广泛关注的报告《The GenAI Divide: State of AI in Business 2025》。基于 150 场高管访谈、350 份员工调查和 300 个公开 AI 部署案例，报告得出了一个冰冷的数据：95% 的企业生成式 AI 试点未能产生可衡量的投资回报。报告作者 Aditya Challapally 指出，问题不在于 AI 模型的质量，而在于学习鸿沟，也就是企业和工具之间的学习断层。
换句话说，不是 AI 不够强，是你的代码库不够干净。
为什么 Joel 的魔咒曾经是对的
要理解 AI 为什么能打破 25 年的铁律，得先理解这条铁律为什么能活这么久。
Joel 2000 年的判断基于一个朴素但极其有力的观察：重写意味着丢掉所有隐性的组织知识。Netscape 的浏览器不是一团代码。它是一个包含了数千个已处理 Bug 的数据库、数百次用户调研的反馈沉淀、几十个工程师对产品如何运行的共同理解。重写把这些全部清零。
这个观察在 2000 年是颠扑不破的。在 2010 年也是。甚至在 2020 年仍然成立。因为在没有 AI 的时代，代码库的价值等于代码本身加上代码背后的人的经验。重写抹掉了人的经验那部分，而那是无法快速重建的。
AI 改变的是这个等式中的第一个变量。当 AI 可以自动填充大量标准模式的代码、自动处理常见边界情况、自动生成测试用例时，代码本身部分的恢复成本被急剧拉低。你得保留什么？架构决策、领域知识、业务规则。但要重写一个 React 组件或一个 CRUD 接口，AI 几秒钟就够了。
这意味着重写的成本公式变了。
旧公式：重写成本等于重新开发加丢失隐性知识，两者都极高。结果是灾难。
新公式：重写成本等于 AI 辅助开发加保留架构知识。前者中低，后者高。但整体风险更可控。
当旧代码库的混乱程度带来的 AI 效率损失大于重写带来的迁移成本时，重写的经济学就翻盘了。
三档企业，谁在裸泳
这个逻辑把今天的科技公司分成三档。
第一档：标准件玩家。它们用主流技术栈，Python、TypeScript、Rust、Go，一致的架构模式，清晰的代码规范。AI 在这类代码库上的表现像装了涡轮增压。模型见过几十亿行类似的代码，生成质量高、幻觉低、需要的人工审查少。这类公司正在获得一种隐性的 AI 杠杆红利，它们花在 AI 编码工具上的每一分钱，产出效率都比竞争对手高。
第二档：专有语言包袱户。它们用自研语言、内部框架，或者已经过时的商业技术栈。每个新需求进来，AI 先花一半上下文窗口学你的方言。结果是什么？更多 Token 消耗、更高出错率、更多的 Prompt 调试。你花在让 AI 理解代码库上的时间，已经超过了 AI 帮你省下来的时间。
第三档：混乱的遗产业主。这是最危险的一类。它们的代码库不仅用了专有技术，而且风格极度不一致。同一个项目里同时出现三种数据库访问模式、五种错误处理方式、没有统一的目录结构。AI 面对这类代码库时，不仅效率低下，还会主动制造 Slop。模型在概率预测中找不到稳定的模式，只能在各种碎片化的写法之间随机游走。
第三档的企业最应该考虑重写。不是因为新技术更酷，而是因为混乱本身在 AI 时代的成本已经高到不可持续。
重写不是回到 2000 年式的豪赌
有人会反驳：Joel 说重写会杀死公司，难道 Netscape 的教训不算数了？
算数。但 Netscape 的重写和 AI 时代的重写是两种完全不同的动物。
Netscape 的问题不是重写本身，而是闭着重写。整个团队埋头干了三年，没有任何外部的模式库可用，所有代码从零写起。那是工业时代的手工重写。
AI 时代重写的核心特征是模式外挂。当你用 React 重写一个 jQuery 应用时，AI 已经知道 React 的最佳实践、代码分割策略、状态管理方案。它不用学，它已经会了。你要做的是把业务逻辑翻译给 AI，而不是教 AI 怎么写 React。
这就是根本区别：2000 年的重写是从零写起，2026 年的重写是用已有的最佳模式做一次代码翻译。前者的成本和风险是后者的十倍以上。
Hacker News 上的一条高赞评论精准地抓住了这个矛盾：
“If we think from this angle, it really begs the question of what language/tech stack to use if a company wants to start a new project. On one hand, if company uses a very well tech stack, development and rewrites will be faster due to AI having way more examples to draw from. On the other hand, if this company choose a newer stack which may be better than older popular frameworks, development time will increase.”
——Hacker News 用户 lazy_dev_1_to_9
翻译成商业语言就是：你选的技术栈决定了 AI 能替你省多少钱。
重写的正确打开方式
AI 改变了重写的经济学，不代表现在可以随便重写了。恰恰相反，它意味着重写的决策需要更精密。
有些代码库值得重写。比如那些每次让 AI 生成代码时，花在教它理解代码库上的 Token 成本已经超过了它帮你写代码的收益。这是最直接的信号。你的代码库正在吃掉 AI 红利。
又比如你打算长期使用 AI 编码工具，在 2026 年，不用的团队已经很少了。那么一次性重写的迁移成本将被后续每次开发的 AI 效率提升摊薄。重写不是消费，是投资。
再比如你的核心语言被 AI 训练数据严重冷落。Haskell、Erlang、COBOL 或者自研 DSL，这些语言在训练数据中的占比微乎其微。AI 对它们的理解基本停留在语法层面，无法给出结构级建议。如果你的业务并不依赖这些语言的特殊优势，迁移到主流语言本身就是 AI 时代的降维打击。
但同样有些陷阱不能踩。
用重写替代重构，是陷阱。不是所有混乱都需要推到重来。如果代码库的核心架构仍然健康，只是局部风格不一致，用 AI 辅助渐进式重构远比重写安全。
低估领域知识迁移的成本，是陷阱。AI 可以做模式翻译，但它不知道你的 CRM 系统里那个奇怪的客户分层逻辑是 CEO 在 2019 年拍脑袋定的。领域知识仍然是重写中最脆弱的部分。
认为 AI 写了就完了，也是陷阱。MIT 的报告已经给出了警告，95% 的 AI 试点未能产生可衡量的 ROI。为什么？不是因为代码跑不起来，而是因为没人真正理解它。Comprehension Debt，理解债务，这是 2026 年软件工程领域的新热词。你让 AI 生成的每一行代码，都必须有人能在未来维护它。
赢家与输家已经开始分化
这场变革的赢家和输家轮廓已经清晰。
赢家：选择主流技术栈并保持代码纪律的团队。Python 加 React 加 PostgreSQL 加 AWS 的组合，在 AI 时代的开发效率增速远超其他技术栈。不是因为这些技术本身更好，而是因为 AI 见过它们最多。技术栈的网络效应正在被 AI 放大。更多人用等于更多训练数据，等于更好 AI 支持，等于更多人用。这是一个正反馈循环。
输家：坚持专有框架和混乱代码风格的组织。它们在 AI 红利中分到的羹最少，却在 AI Slop 中吃到的苦最多。更残酷的是，这种差距是自我强化的。因为 AI 帮不上忙，开发效率落后，更没时间清理代码库，混乱进一步加剧。
还有一种微妙的中间态：使用新兴但尚未被训练数据充分覆盖的技术栈，比如某些 2025 到 2026 年才出现的框架。短期来看，AI 支持度不如成熟栈；长期来看，随着使用量增长，训练数据会追上来。选择这类技术栈需要一定的耐心溢价。你赌的是 AI 会在 6 到 12 个月内学会它。
你写的不只是代码
Joel Spolsky 在 2000 年写的文章，本质上是关于信息不对称的。你知道的比你写到代码里的多得多。重写会丢失这些未编码的知识。
AI 没有消除信息不对称。但它改变了另一件事：它让代码本身的生产成本断崖式下降。当代码的生产成本低于维护成本时，重写的天平就倾斜了。
这个微妙的重心转移正在重塑整个软件产业的成本结构。那些最先意识到代码库的清晰度就是 AI 时代的核心生产力的团队，正在悄悄拉开和竞争对手的差距。不是靠更聪明的 Prompt，不是靠更贵的模型，而是靠一个 AI 能理解、能协作的干净代码库。
你写的不只是代码。你写的是 AI 能帮你做什么的说明书。
快报