技术债排优先级：看“利息”，不看“严重程度”

技术债清单很容易变成“什么都很严重”，最后谁声音大谁先修。更可操作的排序维度是“利息”：这笔债每天在消耗多少团队时间、多少事故成本、多少新功能延迟。

我会给每笔债估三个值：发生频率、单次影响、增长趋势。频率高、影响中等、还在增长的债，优先级高于频率低但标签“严重”的债。比如一个每次发布都要手动改配置的脚本，单次只花 10 分钟，但每周发布三次、涉及三个人，一个月就是十几个小时，还容易漏改出事故，这种债的利息很高。

第二个维度是“阻塞性”。有些债本身不痛，但挡住了后续优化。比如没有统一日志格式，导致可观测性做不了；没有幂等键，导致重试不敢开。这类债是杠杆债，修一次能解锁一批改进。

第三个维度是“可逆性”。越难回滚的债越要早处理，比如数据模型、权限边界、对外协议。UI 样式债可以晚点还，数据一致性债拖不得。

落地时不要追求“清空技术债”，那不可能。每个迭代留固定比例容量还高息债，其余按业务节奏。技术债管理的目标不是零债务，是让债务成本可预期、不失控。