重写系统为何总失败？技术债的终极解法与AI时代的新启示

背景：为什么现在值得聊技术债与重写？ 技术债是每个研发团队都会遇到的痛点。当系统变得难以维护时，最直观的冲动是“推倒重来”。但 Simon Willison 在他的博客中指出，这种做法在现实中极少成功。尤其在 AI 辅助编程日益普及的今天，代码生成速度远超测试与重构能力，技术债的积累速度可能呈指数级上升。重新审视“重写 vs 修补”的取舍，对每个技术负责人都有现实意义。

拆解：为什么重写总是失败？ 你以为重写是解决技术债的捷径，但其实它往往是个陷阱。旧系统在重写期间仍是业务核心，需求仍在不断涌入。开发旧系统的团队知道它即将被淘汰，自然只会做最小化改动，导致技术债继续恶化。与此同时，重写团队初期充满干劲，但随着时间推移，他们会发现旧系统的真实逻辑远比文档描述的复杂，甚至很多隐性规则根本没有被记录。最终，为了尽快交付，新系统只能先上线一小部分功能，与旧系统并存。结果就是：你不仅没有减少技术债，反而要同时维护两套系统，成本翻倍。

趋势洞察：AI 时代的技术债管理新范式 这件事揭示了一个深层趋势：在 AI 能快速生成代码的时代，技术债的“隐性成本”正在被严重低估。过去，技术债积累慢，团队有足够时间偿还；现在，AI 让代码产出速度大幅提升，但测试、文档和架构理解的速度并未同步跟上。这意味着，单纯依赖重写或人工修补已不再可行。相反，像 Will Larson 提出的“迁移是唯一可扩展的解决方案”正逐渐成为共识：通过建立全面的自动化测试网，再逐步进行目标明确的重构，才能在保证业务连续性的前提下降低技术债。

实用价值：技术负责人该如何应对？ 如果你正面临系统难以维护的困境，首先不要急于立项重写。先评估现有系统的核心逻辑是否已被充分测试。如果没有，优先补齐自动化测试覆盖，尤其是关键业务路径。其次，采用“绞杀者模式”（Strangler Fig Pattern），将新功能或高价值模块逐步迁移到新架构中，而不是一次性替换。最后，建立技术债的可视化度量机制，让团队和管理层清楚看到债务的增长趋势与偿还进度。在 AI 辅助编程工具日益普及的当下，更要警惕“代码写得快”带来的虚假安全感，把测试与重构纳入日常开发流程。

反常识：重写不是技术债的解药，而是放大器 大多数人认为重写能一劳永逸地解决技术债，但 Willison 的经验表明，重写往往会让技术债以更隐蔽的方式继续存在。新系统在上线初期看似干净，但为了兼容旧业务或快速交付，往往会引入新的妥协。更关键的是，重写过程中的知识流失是不可逆的——旧系统中那些“丑陋但能跑”的逻辑，往往承载着多年业务演进的隐性知识。与其追求一次性的完美重构，不如接受“持续演进”的现实，用测试和渐进式重构把技术债控制在可管理范围内。

原文地址: There's No Limit to How Bad Code Can Get