技术债到底该不该专门留迭代去还？我的做法和代价

背景：我做了 3 年技术 PM，几乎每个季度规划都会卡在同一个问题——技术债要不要单独立专项迭代去还？这事在我们团队吵过至少 4 轮，每次结论都不完全一样，今天拿出来对线。

常见的三种做法：

1. 专项派：每个季度固定留 20%–30% 的容量专门还债（比如一个 8 人团队，每季留 1.6–2.4 人月）。优点是债有确定性、能盯指标；缺点是业务方会问"这 20% 产出了什么功能"，PM 背 KPI 时很被动。
2. 顺手派：不单独排期，谁路过谁顺手修。优点是零额外成本、上下文熟悉；缺点是没人真的去修，债只增不减，半年后变成"不敢动"的禁区。
3. 永不派：能跑就行，除非出事。优点是短期交付最快；缺点是事故概率随债线性甚至指数上升——我见过一个老服务，单测覆盖率 11%，每次改一个字段要回归 3 天。

我的倾向与理由：我选"专项 + 顺手"混合，但有一条硬规则——专项只还"会出事"的债，不还"只是不爽"的债。具体怎么算：

• 先给债打分：用"事故概率 × 影响面"估期望损失。比如一个没有幂等的支付回调，事故概率我估 5%/年、单次影响约 8 小时停机 + 人工补偿，期望损失很高 → 进专项；
• 一个纯代码风格、没人碰的模块 → 不进专项，谁路过顺手改；
• 专项容量我压到 15%（不是 20%），剩下的靠"顺手"和"重构搭车"（做相邻需求时顺带清 10%–20%）。
• 关键动作：每个专项债还清后，必须补一个能"锁住它"的自动化测试或监控告警，否则还会再烂回去。这一步我们漏过两次，债直接复发。

想听大家：你们团队还债是专项、顺手还是永不？在什么场景下你会专门留迭代去还、什么场景下直接放弃？小团队（3–5 人）和大团队（20+）的做法是不是完全不同？欢迎拿你踩过的真实例子来对线。