软件工程界流传一句老话：永远不要重写代码库。Joel Spolsky当年那句告诫几乎是共识——重写会丢掉藏在旧代码里的隐性业务逻辑，耗时耗钱，十有八九砸锅。但最近有位长期写代码的博主翻出这条铁律，说AI正在悄悄改写这笔账。
他的逻辑不复杂：AI理解代码靠的是训练数据里见过的模式，加上你现场给的上下文。代码库越贴近主流语言和常见框架，AI读起来越省力，输出质量越高；反过来，私有DSL、历史包袱重的遗留系统，模型得先花上下文现学，结果是更多token、更多变量、更差输出。于是他得出结论：重写不只是技术升级，更是一次把代码库改造成"AI友好范式"的机会。
这话听着顺理成章，但漏了一个关键问题——产出变快，不等于有人真看懂了这堆新代码。
AI偏爱什么样的代码库
原文给出的两条工作流值得摆在一起看：面对结构清晰的代码库，AI读完规格说明、读完代码，直接生成实现；面对遗留系统，AI得多插一步——补读文档和历史示例，才敢下手。多出来的这一步，吃的是上下文窗口，代价是更高成本和更大方差。
这个机制本身没问题，金融、电信、政府里那些跑了二三十年的COBOL和自研框架，确实是AI的重灾区。语言越小众，AI先验知识越薄，重写这类系统去换取AI杠杆，账面上算得过来。
厂商基准和独立研究，不是一回事
问题是，"重写经济学已经改变"这个结论，目前站在什么证据上？
GitHub Copilot这一侧证据相对扎实：独立研究和官方数据都指向功能性、可读性、可维护性上的统计显著提升，这类结论经得起第三方检验。Cursor这一侧就单薄得多——CursorBench是厂商自建的基准，Salesforce那个"测试覆盖率编写时间大幅缩短"的案例，来自单一企业工程团队的实践分享，不是对照实验。
这不是说Cursor不好用，而是"重写划算"这个判断，眼下更像是从业者的观察和厂商的叙事，还够不上严谨结论。谁在推这个叙事也不难猜——工具厂商天然有动机让"重写为AI铺路"听起来顺理成章。
更快不等于更懂
真正打脸原文隐含假设的，是一项针对遗留代码理解任务的研究：使用Copilot的开发者完成任务更多，但对代码库本身的理解并没有变好。产出和理解之间出现了落差——AI替你干得快，不代表你脑子里那张代码地图更清楚了。
这一点原文完全没碰。它默认重写成"AI友好范式"之后，人和AI都能更好驾驭代码库，但证据指向的是另一种可能：为AI优化的整洁代码库，可能只是把旧技术债换成一堆语法漂亮、但同样没人真正吃透的新代码。出事故的时候，排查责任的还是人，不是模型。
- 风险.如果重写决策只为讨好AI模型，遗漏隐性业务逻辑的锅，最终还是人来背。
检索资料里还提了一条原文没走的路：与其整体重写，不如先用AI给遗留系统补测试、提文档、画依赖关系图，把上下文质量做上去，再决定要不要动刀。这条路成本更低，也不用赌一次性重写不出错。
谁该多留一个心眼
真正被这套叙事牵动的，是那些抱着COBOL、私有DSL过日子的传统机构——金融、电信、政府系统，它们的语言小众性带来的AI劣势最直接，也最容易被"重写划算"的说法说动心。CTO在批预算的时候，得分清楚哪些证据来自独立研究，哪些只是厂商基准和单一案例的自我证明。
代码翻新讨好模型，未必等于组织真的看懂了自己的系统。
AI确实改变了重写的成本一侧，让"是否值得重写"这道题多了一个变量。但账不能只算AI友好度，还得算清楚：新代码库跑一两年后，出问题时有没有人真能看懂、能修。速度是省下来了，理解这笔债，迟早要还。