季度规划会上，技术负责人把清单投到屏幕：二十七条，从「订单模块耦合严重」到「日志格式不统一」。业务方看了十秒，问「这些能不能下季度再说」。技术债排不进期，卡点往往在代价没说清——让 AI 帮忙把每条换算成人天，比在会上争「重不重要」有用得多。
排不进期，是因为代价说不清
「代码质量差」是一句评价，「这个模块每次改动要多花两天联调」是一个事实。前者没法排期，后者可以。沟通的难点就在这里：说的人在用工程语言描述，听的人在用心智成本估算，两边对不上，结论自然是被推后。
还有一层：清单越列越长，说服力反而越弱。二十七条摆在一起，看起来像永远还不完的账，对方的第一反应是回避。有效的做法是先砍到五条以内，每条都能说清代价，再谈排期。
把清单变成排期表
五步里第一步的分类不是学术问题，是为了让不同的人听懂：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 按影响归类，不按技术类型 | 四类清单：拖慢开发、影响稳定、阻碍扩展、只是不好看 | 按前端后端数据库分组，业务方看不懂跟自己的关系 |
| 给每条估一个持续成本 | 每条一行：每周多花几人时，或故障概率区间 | 只标严重中等轻微，没有可以互相比较的量 |
| 算偿还成本与回收周期 | 每条补上人天估算和预计省下的时间 | 只算改造成本，不算改完能省多少 |
| 排出顺序并指定负责人 | 一张排期表，含依赖关系与验收口径 | 排了期没有责任人，到期无人认领 |
| 把顺手能改的塞进需求 | 一份附带清单，写进对应需求的验收项 | 小事也单独立项，评审会开成流水席 |
按技术类型分组，只有工程师看得懂；按影响分组，业务方能判断哪一条跟他有关。「只是不好看」这一类单独拎出来，还解决了另一个问题——它不该占排期，顺手改就行。让它做归类时，把团队规模、业务窗口、历史故障记录一并写进提示词，产出才不会飘，结构可参考提示词里的角色加约束写法。
四类债务，处理方式不同
拖慢开发的债，衡量单位是时间：每次改动多花几小时、每周多开几次会。影响稳定的债，衡量单位是概率和影响面：多久出一次、出一次影响多少用户。阻碍扩展的债，衡量单位是未来成本：下一个功能要绕多少路、要不要推倒重来。只是不好看的债，衡量单位是心情，不该进排期表。
四类混在一张表里按「严重程度」排序，结果一定是稳定类永远第一、扩展类永远第二、拖慢类永远排不上。分开列、各自排序，反而更容易达成一致，也更容易在评审会上过。
把利息折算成人力成本
技术债的利息有个好处：它每天都在发生，可以估。某个模块每次改动多花两天联调，一个月改四次，就是八人天；换算成人月，再乘上人力成本，就是一个业务方能理解的数字。这个数字不需要精确到个位，量级对就够了。
故障概率也能粗估。按过去半年的故障记录数一数，算出平均间隔和平均恢复时长，再乘上影响范围。想更细一点，可以用模拟的方式跑一批随机场景看分布，思路见蒙特卡洛方法。这类估算的价值不在准确，在于把「感觉很重要」变成「大概值多少人天」。
AI 估不出你的故障概率
三个数它给不了。第一是你们的真实故障率，它看不到监控和工单。第二是团队的实际速度，同样的改造，熟手和新人差好几倍。第三是业务窗口，哪个月不能动核心链路，只有你们自己知道。它给出的「预计五天完成」是行业均值，不是你们的数。
它还会顺着你的话说。你问「这个改造值不值得做」，它多半列出三条好处、一条风险，语气还很确定。让它做反面论证更实用：要求它列出「不该做这件事的三个理由」，再看你能不能反驳。数字部分尤其要核，模型编造具体百分比的情况很常见，成因见AI 幻觉。
固定容量比集中偿还更可持续
「等这个版本上线就专门还债」这句话，多数团队说过不止一次，兑现的次数很少。更稳的做法是每期固定留出一小块容量，比如每轮迭代两成时间，专门处理排在最前面的两条。容量固定下来，它就不会被新需求挤掉；比例不大，业务方也更容易点头。
这块容量要有验收。改完之后指标要能对比：联调时间有没有降、故障间隔有没有拉长、新功能开发有没有变快。没有对比，第二期就没人愿意再批这块时间。
速查：排期会上要带的四样
- 四类分好的清单，每类不超过五条
- 每条一句代价，用人天或故障间隔说
- 一张排期表，含负责人与验收口径
- 一份顺手改清单，挂到已有需求上
