默认选择 refactor。只有当现有系统再也无法以可接受的成本演进以满足需求，且你能在重写期间持续交付价值时，重写才是合理的。大多数“我们需要重写”的直觉，其实是一个未被管理的 tech-debt 问题，而渐进式 refactor 能以小得多的风险解决它。
我如何推理
- 核心架构还可行吗？ 如果数据模型、边界和运行时能伸展到新需求，就 refactor。如果基础假设错了（错误的存储范式、无法扩展、语言/平台已 end-of-life），重写才成为真正的候选。
- 变更频率是多少？ 很少改动的代码不需要漂亮。把精力集中在团队每天工作的地方。
- 我们理解当前的行为吗？ 重写会扔掉多年编码进去的边界情况知识。如果没有测试也没有 spec，重写会重新引入旧的 bug。