渐进式重构（Progressive Refactoring）
定义
渐进式重构（Progressive Refactoring） 是技术债管理的"第三条路"：将技术债拆解为业务需求的"顺带动作"，借着迭代渐进式消化——在不停止业务交付的前提下完成大规模重构。
关键数据点
- 31 万行代码在不停止业务交付的前提下完成核心数据模型平滑升级。
- 没有申请一天专门的重构时间。
- 借着核心功能迭代需求完成新业务模型设计。
- 借着功能升级需求完成质检业务模型全量迁移（兼容多条业务链路 + 多视图 + 多区域复杂交叉验证）。
三条路径对比
传统只有两条路：
| 路径 | 做法 | 代价 | 风险 |
|---|---|---|---|
| 推倒重来 | 全面重写 | 风险极高，业务中断 | 可能引入更多 bug |
| 专项排期 | 申请专门重构时间 | 与业务争资源，零和博弈 | 业务方通常不同意 |
| 渐进式重构 | 借着业务需求"顺带"消化技术债 | 需要极强技术判断力 | 需要拆解粒度和执行纪律 |
执行机制
执行方式
- 拆解技术债到日常高优需求：识别哪些业务需求能"顺带"消化哪些技术债。
- 顺势设计新模型：借着核心功能迭代需求，设计并落地全新的业务模型。
- 平滑迁移：借着功能升级需求，完成全量迁移。
关键约束
- 不能让重构拖慢业务交付。
- 不能让业务需求绕过技术债继续堆新债。
- 需要逐个判断：哪些债能顺带消化，哪些必须专项处理。
执行路径
需求迭代 → 识别可顺带消化的技术债 → 设计新模型 → 在需求中落地 → 平滑迁移AI 时代对渐进式重构的影响
AI 编码效率提升使渐进式重构成为可能，也改变了它的成本结构：
| 维度 | 传统渐进式重构 | AI 时代渐进式重构 |
|---|---|---|
| 编码成本 | 高（占重构时间大头） | 低（Agent 生成代码） |
| 判断成本 | 中 | 高（核心瓶颈） |
| 验证成本 | 高（手动测试） | 中（可验证性 高的任务可自动化） |
| 风险 | 重构拖慢交付 | 编码不再是瓶颈，拆解和判断才是 |
关键转变是：编码成本降低后，渐进式重构的核心瓶颈从"写代码"变成"判断哪些债能顺带消化"。这意味着技术判断力的价值进一步上升。
前提与局限性
- 前提：需要极强的技术判断力——判断哪些业务需求能"顺带"消化哪些技术债。
- 前提：技术债的拆解粒度必须足够细，能嵌入单次迭代。
- 边界条件：适用于技术债积累速度 < 业务迭代速度的场景。如果技术债积累速度远超消化速度，渐进式重构可能来不及。
- 局限：深层架构性技术债（如业务模型根本性缺陷）可能无法通过"顺带"方式解决，仍需专项设计。
- 局限：文章未给出"哪些债能顺带消化、哪些必须专项"的判断标准——这是实践中最需要的决策框架。
关联概念
- Technical-Debt-Avoidance — 渐进式重构是更激进的版本：不是避免新债，而是主动消化旧债。
- 人机对齐 — 渐进式重构依赖人机对齐建立的工程规范，确保"顺带"过程中不产生新债。
- Compound-Engineering — 两者都强调持续改进而非一次性大修。
- Agentic-Engineering — AI 编码效率提升使渐进式重构成为可能。
- Verifiability — 可验证性高的技术债（如代码结构、测试覆盖）更适合渐进式消化。