技术债务到底该「集中还债」还是「边用边还」？

背景：

做了 15 年技术产品，我几乎每个团队都绕不过「技术债」这个词。但每次排期会一开，分歧立刻出来：老板说「用户功能先上」，架构师说「再不上个季度就要重写」，一线开发说「每次都要先还债、KPI 永远完不成」。我统计过自己经手的 8 个团队，关于技术债的处理方式大致落在这三种：

1.「集中还债派」：每季度留 15%–20% 的容量专门做重构，平时只接新需求。逻辑是「不集中处理，永远处理不完」。 2.「边用边还派」：谁路过谁还一点，改到哪个模块顺手把周边烂代码清了。逻辑是「上下文热的时候改最便宜，集中还债反而要重新学一遍业务」。 3.「先欠后还派」：默认所有技术债都是需求驱动，谁提需求谁一起还（即「Boy Scout Rule」反过来——需求带 20% 还债预算）。

我的倾向与理由：

我明确站「边用边还 + 关键路径集中还债」的组合，但有一条硬规则：任何技术债必须先登记进一张「债清单」，每个债要写清三样东西——影响面（多少 QPS / 多少用户路径）、风险等级（会不会 P0）、偿还成本（几人日）。 我见过最痛的一次：一个团队口头说「这块代码太烂了，迟早重写」，一年之后「迟早」变成了「没人敢动」，最后一次大促前紧急重构，上线当晚直接 P1。如果当时有债清单，重写这件事在第 4 个月就会被排进容量，而不是第 12 个月。

具体做法我给三个数字： ① 每个 sprint 预留 10%–15% 容量给「债清单 Top 3」，不是随便挑一个改； ② 债清单按季度做一次「风险 × 成本」四象限排序，落在「高风险 + 低成本」象限的债当周必须排期，不许拖； ③ 每季度向业务方公开一次债清单的「不还会怎样」预估——用损失数字说话，而不是「代码很烂」这种形容词。

但我不否认「集中还债」在特定场景是对的：比如核心链路的存储引擎升级、框架大版本迁移，这种「上下文一次性切换」的成本远高于分散处理。关键判断标准只有一个：这件事的「学习成本」是不是每次都重新付一遍？是，就集中；不是，就分散。

想听大家聊聊：

• 你所在团队的「技术债」是怎么管理的？有没有正式的债清单，还是全靠架构师脑子记？
• 你们有没有被「集中还债」坑过的经历？（我猜有——集中还债最大的坑是「还完发现业务已经变了，还错了方向」。）
• 如果让你给业务老板做一次「技术债汇报」，你会用什么指标让他愿意批 20% 的容量？我见过最有效的一个数是「上个月因为这块烂代码多花了多少人日救火」，但大家有没有更好的？

期待看到不同立场的碰撞，尤其是「先欠后还派」的同学，我想听听你们的反驳。