技术债四象限是什么
Fowler 用两根轴划分技术债：有意还是无意，审慎还是鲁莽。「审慎且有意」是主动取舍，需要登记与偿还计划；「鲁莽且有意」是明知故犯，风险最高；无意型来自知识缺口，往往要等团队水平提升后才会被识别。分象限的意义在于：不同类型的债要用不同方式处理，不能统一压成一句「以后重构」。
基本信息
| 提出 | Martin Fowler（2019 年的 TechnicalDebtQuadrant 一文） |
|---|---|
| 两根轴 | 有意 / 无意 与 审慎 / 鲁莽 |
| 处理差异 | 主动取舍需登记；鲁莽型需复盘；无意型需补能力 |
| 登记要素 | 债务描述、成因、利息、偿还计划与验收标准 |
典型使用场景
- 交付窗口压缩时的临时方案：有意且审慎，必须登记
- 来不及做设计直接上线：有意但鲁莽，值得复盘而不是夸奖速度
- 当时不知道有更好做法：无意且审慎，属于学习成本
- 基础概念缺失导致的错误结构：无意且鲁莽，需要培训
- 季度回顾排序：按利息高低决定先还哪一笔
四象限与处理方式
| 象限 | 典型说法 | 处理方式 |
|---|---|---|
| 有意且审慎 | 先交付，回头补上 | 登记台账，排入版本计划并给出验收标准 |
| 有意且鲁莽 | 来不及做设计，先上 | 复盘决策过程，补上必要的设计约束 |
| 无意且审慎 | 现在才明白应该怎么做 | 写进团队经验，修正相关模块 |
| 无意且鲁莽 | 不知道这样有什么问题 | 补培训与规范，必要时加评审检查项 |
登记模板
登记模板
债务：订单模块直接拼接 SQL，没有参数化
成因：上线窗口压缩（有意 / 审慎）
利息：每次改动都要回归注入风险，SQL 复用困难
偿还：下一季度引入仓储层，预计 3 人日
验收：注入测试通过，订单查询全部走参数绑定分象限不是为了贴标签：它决定这笔债是登记、复盘还是培训，处理路径不同，优先级也不同。
只承认「有意」却不登记：偿还遥遥无期，利息没人计数，下一次交付只会更慢。