技术债台账是什么
把债务当成可管理的工作项而不是口头抱怨：每条记录症状、成因、利息证据、偿还方案和估计，放在团队都能看到的地方，随偿还更新状态。有了台账，债务才和功能需求站在同一个排序池里竞争资源，而不是永远排在功能之后。台账的价值不在记录本身，而在于把「这段代码很难改」翻译成可排序、可估算、可验收的条目。
基本信息
| 字段 | 症状 / 成因 / 利息证据 / 偿还方案 / 估计 / 状态 |
|---|---|
| 排序依据 | 利息 × 变更频率，热点优先 |
| 节奏 | 每迭代固定比例（如 15%）与功能同排 |
| 可见性 | 团队可访问，不是个人笔记 |
| 验收 | 偿还完成的判定写清：看什么指标或行为 |
登记与维护要点
- 症状写可观察现象（「改价目表要动四处」），而不是主观评价
- 利息要有证据：返工耗时、缺陷数、发布受阻次数
- 排序用利息乘更改频率：改得勤又疼的地方优先
- 偿还方案写成可执行动作，避免「重构一下」这种无法估算的描述
- 每次迭代回顾更新状态，已偿还的移出而不是堆积
- 决定不还的条目也写清理由，避免反复讨论同一个东西
台账字段示例
台账字段示例
CREATE TABLE tech_debt (
id, area, -- 位置：模块/目录
symptom, -- 症状：可观察现象
cause, -- 成因：赶工/方案妥协/认知不足
interest_note, -- 利息证据：返工工时、缺陷数
change_freq, -- 近三个月改动次数
repay_plan, -- 偿还方案：具体到拆哪个类
estimate_days, -- 估计：人日
status -- 待排期/进行中/已偿还/主动不还
);排序示例
| 条目 | 改动频率 | 利息证据 | 优先级 |
|---|---|---|---|
| 报表口径模块 | 高 | 每次需求多花 2 天 | 高 |
| 日志格式工具 | 低 | 偶有新增格式 | 低 |
| 支付回调重试 | 中 | 季度内 3 次线上告警 | 高 |
| 旧导入脚本 | 极低 | 无 | 主动不还 |
| 用户表读写混用 | 高 | 两次并发问题 | 高 |
台账不是越长越好：条目超过几十条说明缺乏取舍。可以按模块聚合，只保留进入偿还候选的细项，其余作为背景记录；否则清单本身会变成一项新的维护负担。
配额如果只在「空闲时间」执行，等于没有配额：功能排期会永远吃掉空档。把债务项写进迭代计划、和需求一起承诺，才真的会还；同时要留出随时插入高利息项的空间。