技术债台账要长期可用，关键是把更新接入研发节奏：每条债务有唯一编号和责任人，状态由新增、评审、排期、偿还、关闭等事件推动，定期评审负责兜底。本文给出字段表、状态机、触发清单、角色分工、评审议程和健康度检查，可按团队规模裁剪后直接落地。
要点总览（TL;DR）
- 先定最小字段集和六状态状态机，让每条债务有唯一编号、单一责任人和可追溯的状态流转，再按运行情况补充字段。
- 更新由事件驱动：代码评审、故障复盘、需求评审、架构评审负责登记，排期、偿还、关闭、豁免在事件现场改状态并留证据。
- 每条债务落到单一更新责任人，技术负责人把关确认与严重度，迭代负责人带入计划，评审角色审批豁免并抽查台账。
- 按需更新配合定期评审：两周迭代的团队每两到四周评审一次，议程固定为新增确认、优先级调整、逾期处理、豁免审批。
- 每季度做健康度检查，看字段完整率、状态滞留、逾期数量、与迭代计划的一致性以及豁免到期复核，异常条目回到规则层修订。
台账先定哪些字段和状态
台账字段决定后续能否用于排序和决策。字段过多会增加维护负担，过少则无法判断优先级。建议先落一张最小字段表，运行一到两个迭代后再补充。下表可作为初始版本，其中“必填”指登记时即须填写，“推进必填”指进入对应状态前必须补齐。
| 字段 | 填写要求 | 说明 |
|---|---|---|
| 编号 | 必填，系统生成 | 全局唯一，格式如 TD-年份-序号，关闭后不复用 |
| 标题 | 必填 | 一句话说明债务对象和问题，如“订单服务同步调用支付网关导致超时扩散” |
| 来源 | 必填 | 代码评审、故障复盘、需求评审、架构评审、日常巡检 |
| 影响范围 | 必填 | 涉及的模块、服务或业务链路，便于评估波及面 |
| 类型 | 必填 | 代码质量、架构设计、测试覆盖、文档缺失、依赖与版本、环境与工具 |
| 严重度 | 必填 | 高、中、低，与偿还窗口挂钩，见下文对应关系 |
| 责任人 | 必填 | 单一责任人，负责推动状态更新，不要求本人完成全部偿还工作 |
| 发现时间 | 必填 | 登记日期，用于计算滞留时长 |
| 目标偿还窗口 | 推进必填 | 确认优先级后填写，如“本季度内”“下两个迭代” |
| 状态 | 必填 | 按下方状态机取值 |
| 关联工作项 | 选填 | 关联需求、缺陷或迭代任务，便于追踪偿还进度 |
| 证据与备注 | 选填 | 评审结论、豁免理由、关闭验证记录 |
严重度与偿还窗口建议建立默认对应关系，减少每次评审重新讨论：高严重度默认在当前或下一个迭代排期，中严重度默认在本季度内处理，低严重度进入待办池并按季度批量评估。对应关系是默认值，评审时可以调整，但调整需在备注中写明理由。
状态机建议设六个状态，并规定允许的流转方向，避免状态被随意跳转：
| 状态 | 含义 | 允许流转到 | 进入条件 |
|---|---|---|---|
| 待评估 | 已登记，尚未确认是否成立 | 已确认、已豁免 | 登记完成最小字段 |
| 已确认 | 确认为真实债务，待定优先级 | 已排期、已豁免 | 评审确认影响与类型 |
| 已排期 | 已进入某个迭代或版本计划 | 偿还中、已确认 | 填写目标偿还窗口并关联工作项 |
| 偿还中 | 正在实施偿还 | 已关闭、已排期 | 关联工作项进入进行中 |
| 已关闭 | 偿还完成并验证 | — | 附验证证据 |
| 已豁免 | 决定暂不处理 | 已确认 | 记录豁免理由、审批人和复核时间 |
“已豁免”不等于删除。豁免条目应保留在台账中并设置复核时间，到期后重新评估，防止被遗忘的债务长期沉底。
更新由哪些事件触发
台账失真的常见原因是依赖定期集中补录，导致记录滞后、细节丢失。更稳妥的做法是为每类研发活动规定登记入口，让更新发生在事件现场。下表列出常见触发事件与对应动作。
| 触发事件 | 更新动作 | 执行人 |
|---|---|---|
| 代码评审发现设计妥协或临时方案 | 登记新条目，填写来源、影响范围、类型，状态置为待评估 | 评审发起人或评审人 |
| 故障复盘确认存在结构性原因 | 登记新条目，关联复盘记录，严重度初判为高或中 | 复盘负责人 |
| 需求评审发现为赶工期简化设计 | 登记新条目，注明简化点和后续补齐条件 | 需求负责人或技术负责人 |
| 架构评审识别出耦合、单点或技术选型风险 | 登记新条目，影响范围写到服务或链路级别 | 架构评审参与人 |
| 债务进入迭代计划 | 状态改为已排期，填写目标偿还窗口，关联迭代工作项 | 迭代负责人 |
| 偿还工作开始 | 状态改为偿还中，关联工作项同步为进行中 | 债务责任人 |
| 偿还完成并通过验证 | 状态改为已关闭，附验证方式与结果 | 债务责任人，验证人确认 |
| 评审决定暂不处理 | 状态改为已豁免，记录理由、审批人和复核时间 | 评审主持人 |
关闭与豁免都需要证据，不能只改状态。关闭的证据可以是测试通过记录、监控指标改善、代码合并记录或架构评审结论；豁免的证据是明确的取舍理由，例如“该模块将在下个版本整体替换，单独偿还成本高于重写”。证据写在备注字段，便于后续审计和复盘。
如果团队已经在用工作项工具管理研发任务，可以把台账建成一类独立工作项，让状态流转、关联迭代和评论记录直接沉淀在工具里。以ONES为例，工作项可承载字段、状态和关联关系，评审结论以评论或文档形式留痕，减少台账与执行记录两套系统对不上的情况。具体字段配置需按团队实际流程设置。
谁负责维护，各角色交付什么
台账无人认领时，最常见的结果是登记后长期停在待评估。分工原则是：每条债务有单一更新责任人，评审角色负责把关，迭代负责人负责把债务带进计划。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 债务责任人 | 维护本条债务的字段完整性和状态推进，发起排期申请，提交关闭证据 | 完整的债务记录、关闭验证材料 |
| 技术负责人 | 确认债务是否成立，判定类型和严重度，参与优先级排序 | 评审确认意见、优先级结论 |
| 迭代负责人 | 在迭代规划中为已确认债务分配容量，更新排期状态 | 迭代计划中的债务条目、排期记录 |
| 质量或架构评审角色 | 复核高严重度债务，审批豁免，抽查台账质量 | 豁免审批记录、抽查结论 |
| 台账管理员（可兼任） | 维护字段口径和状态规则，组织定期评审，输出健康度报告 | 评审纪要、健康度检查结果 |
评审会议的输入应提前准备：待评估条目清单、逾期条目清单、申请豁免条目清单。输出包括确认结论、优先级调整、排期决定和豁免审批。记录方式建议在台账条目上直接留痕，同时在会议纪要中汇总本次变更的编号列表，方便未参会人员追溯。
维护节奏：定期评审与按需更新怎么配合
按需更新解决时效问题，定期评审解决积压和优先级漂移问题，两者缺一不可。按需更新由上一节的触发事件驱动，责任人在事件发生时完成；定期评审由台账管理员组织，集中处理需要多人判断的事项。
评审频率可按团队节奏设定：两周一个迭代的团队，建议每两到四周评审一次，与迭代规划会衔接；迭代周期更长或债务量较大的团队，可每月一次。频率没有统一标准，判断依据是待评估条目是否在下一个规划周期前完成确认。
评审议程建议固定为四项，每项限时：
- 新增确认：逐条处理待评估条目，确认成立、合并重复或豁免，给出类型和严重度。
- 优先级调整：复核已确认但未排期的条目，结合业务影响和偿还成本调整顺序。
- 逾期处理：列出超过目标偿还窗口的条目，决定重新排期、升级严重度或豁免。
- 豁免审批：审批本期申请豁免的条目，设定复核时间。
与迭代规划的衔接点是：评审确认的条目进入候选池，迭代负责人在规划会上按容量选取，选取后状态改为已排期。与版本发布的衔接点是：版本发布前检查本版本承诺偿还的债务是否关闭，未关闭的条目在发布复盘中说明原因并重新排期。
示例：一条债务从登记到关闭的完整记录
以下为演示情景，用于说明字段填写和状态推进方式，不代表真实项目数据。
初始登记。编号 TD-2025-017，标题“订单查询接口同步调用库存服务，高峰期超时扩散”，来源为故障复盘，影响范围为订单查询链路，类型为架构设计，严重度初判为中，责任人订单域开发负责人，发现时间 3 月 12 日，状态待评估。备注中关联复盘记录编号。
第一次状态变更。3 月 18 日技术评审确认债务成立，严重度调整为高，理由是大促期间超时会影响下单转化，状态改为已确认，责任人和评审人留痕。
第二次状态变更。3 月 25 日迭代规划会决定在下一个迭代偿还，目标偿还窗口填写“4 月第 1 个迭代”，关联迭代工作项，状态改为已排期。
第三次状态变更。4 月 2 日偿还工作启动，改为异步调用并增加降级策略，状态改为偿还中，关联工作项同步为进行中。
关闭。4 月 11 日完成上线，附压测结果和一周监控数据，确认高峰期超时率回到阈值内，状态改为已关闭，验证人确认。整条记录保留了每次变更的时间、触发事件、责任人和证据，复盘时可直接引用。
完成检查：台账是否还在支撑决策
台账是否有效，不看条目数量，而看它能否回答“先还哪个、谁来还、什么时候还”。建议每季度做一次健康度检查，逐项核对：
- 字段完整率：已确认及以上状态的条目，必填字段缺失比例是否低于约定阈值，例如 5%。
- 状态滞留：待评估状态停留超过一个评审周期的条目数量，是否已在本期评审中处理。
- 逾期债务：超过目标偿还窗口仍未关闭的条目数量，每条是否有重新排期或豁免记录。
- 一致性：台账中已排期条目是否都能在迭代计划中找到对应工作项，复盘结论中提到的债务是否已登记。
- 重复与失效：同一问题是否被重复登记，已整体替换的模块下债务是否已批量关闭或豁免。
- 豁免复核：到期豁免条目是否已重新评估，避免豁免变成事实上的删除。
检查结果应形成简短报告，列出异常条目编号和处理动作，在下一次评审会上确认闭环。连续两个周期出现同类异常的，说明字段口径或触发规则需要调整，应回到第一节修订规则，而不是靠增加评审次数弥补。
常见问题
团队刚开始建台账，字段和状态可以一次定全吗？
不建议一次定全。先用最小字段集运行一到两个迭代，观察哪些字段在实际评审中真正被用到，再补充关联工作项、证据备注等选填项。状态机同样可以先跑六个状态，如果团队规模小、债务量少，可以把“已确认”和“已排期”合并，但合并后要保证排期信息仍能记录在字段里，否则无法判断哪些债务真正进了计划。
债务责任人离职或转岗，台账条目怎么交接？
把责任人变更作为一次正式的状态事件处理：在原条目备注中记录交接原因、原责任人和新责任人，由技术负责人确认后更新责任人字段。交接时同步检查该条目的字段完整性和当前状态，处于偿还中的条目要确认关联工作项是否一并移交。建议在定期评审议程中增加一项交接确认，避免出现无人推动的滞留条目。
豁免的债务多久复核一次比较合适？
复核时间按豁免理由设定：因模块整体替换而豁免的，复核时间对齐替换计划的里程碑；因成本高于收益而豁免的，建议不超过两个季度复核一次。豁免条目到期后回到评审议程，重新判断是继续豁免、转为已确认还是关闭。连续多次豁免的条目应在健康度检查中单独列出，确认它是否已经变成事实上的删除。
台账条目和迭代任务需要重复维护吗？
不需要两套并行维护。常见做法是台账条目作为独立记录保留完整历史，偿还时关联一个迭代工作项，状态推进以工作项的实际进展为准，台账只同步状态和关键节点。如果团队使用工作项工具承载研发任务，可以把台账建成一类独立工作项，让状态流转、关联迭代和评论记录沉淀在同一处，减少两边对不上的情况。具体字段和状态配置需按团队实际流程设置。
健康度检查发现大量逾期债务，应该先改流程还是先集中偿还？
先判断逾期原因。如果逾期集中在少数模块，通常是排期容量不足，应在迭代规划中为债务预留固定容量；如果逾期分散且状态长期停在待评估，说明触发规则或责任人机制没有落地，应先修订登记入口和责任人分工。集中偿还可以作为短期动作，但需要配合规则调整，否则清理完一批后逾期会再次累积。
