保护旧代码的本能

开发者天生有一种想保留旧代码的冲动。我们重构、优化、小心迁移。但如果这种本能本身就是错的呢？

在生物学里，autotomy 指的是动物主动舍弃身体的一部分，比如蜥蜴为了逃生会断尾。尾巴原本有用，但为了活下来，它必须放手。之后新的尾巴还会长出来。

为什么重构很贵

在 AI-coded 的早期 MVP 里，第一版 auth flow 往往比任何人预期都更快上线。真正的麻烦出现在几周后：product 变了，team 开始小心翼翼地重构一套他们其实从未真正设计过的代码。这时 login 会坏，user state 会漂移，bug 数量会上升。他们其实是在努力保留一段本该被替换的代码。

在 AI 生成代码的场景里，这个问题会被放大。AI 建了你没设计过的抽象，做了你没批准过的耦合决策。去重构 AI 代码，本质上是在逆向推断一个你从未拥有过的意图。

替换是一条更便宜的路

那如果我们不重构，只做替换呢？

模块 A（Auth v1）→ 接口契约 → 模块 A'（Auth v2）

只要新的实现满足同样的接口契约，并通过同样的测试，它就是一个有效替换。你不需要理解旧模块内部是怎么写的，也不需要小心翼翼地迁移。直接切掉，换掉。

安全替换的前提

这套方法成立，前提是你已经有：

  1. 明确定义的接口：每个模块都有契约（TypeScript 类型、API Schema 等）
  2. 边界强制：模块不能伸手访问彼此内部实现
  3. 足够的测试：测试验证的是契约，不是实现细节
  4. 干净的依赖图：没有循环依赖，也没有隐式耦合

Autotomy 在实践里是什么样

在 Autotomy starter kit 里，每个模块都按“安全切除”来设计：

  • 认证模块？换掉。接口不变。
  • 支付提供方？切换。hooks 不变。
  • UI 组件库？替换。布局契约还在。

关键洞察只有一句：为删除而设计，而不是为保留而设计。当每个模块都能被安全移除时，你就不再需要重构，你只需要替换。