技术债台账用一张表逐条记录团队欠下的技术债，让“以后要还”的事项有编号、有责任人、有偿还计划。核心字段包括债务编号、名称与描述、类型、来源、影响范围、偿还成本估算、风险等级、责任人、计划偿还时间、状态和验证方式。本文先给一张可直接复制到表格工具的空白台账，再逐字段说明填写口径，区分必填与选填，并用一条完整示例演示从登记到关闭的过程。
要点总览（TL;DR）
- 技术债台账用一行一条债务的方式记录编号、名称与描述、类型、来源、影响范围、偿还成本估算、风险等级、优先级、责任人、计划偿还时间、状态和验证方式。
- 启动阶段保留编号、名称、描述、风险等级、责任人、状态六个必填字段即可运行，类型、成本估算、优先级等随治理深入补齐。
- 填写时把风险等级与偿还成本结合排序，验证方式写成可核验的结果，关闭由非经办人按验证方式核对。
- 台账按迭代或双周评审、每季度全量复核，新增字段需说明支撑哪个决策，关闭条目归档保留不删除。
- 已确认的功能缺陷走缺陷管理，技术债只记录能运行但存在长期结构或质量代价的问题。
可复制的技术债台账空白模板
下面这张表可以直接复制到 Excel、在线表格或协作工具的自定义视图中使用。使用原则只有一条：一行只记一条债务，不要把同一处代码的多个问题合并成一行，也不要把一条债务拆成多行。合并会让偿还成本估算失真，拆分会让责任人和状态难以跟踪。
| 债务编号 | 名称 | 描述 | 类型 | 来源 | 影响范围 | 偿还成本估算 | 风险等级 | 优先级 | 责任人 | 计划偿还时间 | 状态 | 验证方式 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TD-001 | ||||||||||||
| TD-002 | ||||||||||||
| TD-003 |
为了让不同人填出的取值一致，建议在台账旁附一张取值参考表，用下拉选项约束类型、风险等级和状态三个字段。
| 字段 | 建议取值 | 说明 |
|---|---|---|
| 类型 | 架构设计、代码质量、测试覆盖、依赖与版本、文档缺失、性能与容量、安全合规 | 按债务的主要成因归类，一条债务只选一个主类型 |
| 风险等级 | 高、中、低 | 按发生概率与影响后果综合判断，口径见下一节 |
| 状态 | 待评估、已确认、偿还中、待验证、已关闭、已搁置 | 状态只向前流转，“已搁置”需注明原因和复核时间 |
字段说明：每个字段记录什么、怎么判断
字段分为识别、评估、执行三组。识别类字段回答“这是什么债”，评估类字段回答“值不值得还、先还哪个”，执行类字段回答“谁来还、什么时候还、怎么算还完”。三组字段的填写口径需要在团队内统一，否则同一张表里会出现无法比较的记录。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 债务编号 | 台账内唯一标识 | 建议用“TD-序号”格式，创建后不再修改，便于在提交记录、会议纪要中引用 |
| 名称 | 一句话概括债务 | 写清对象和问题，例如“订单服务仍使用已停止维护的旧版序列化库”，避免只写“优化代码” |
| 描述 | 债务的具体表现与背景 | 说明现状、为什么形成、不处理会怎样，控制在几句话说清，细节可另附文档 |
| 类型 | 债务的主要成因分类 | 从取值表中选一个主类型；跨类型的债务按主要风险归类 |
| 来源 | 债务的产生场景 | 记录为赶发布临时简化、历史系统遗留、需求变更未同步重构、第三方依赖到期等具体来源 |
| 影响范围 | 债务波及的模块、系统或团队 | 写模块名或服务名，并注明是否影响线上稳定性、交付速度或新人上手成本 |
| 偿还成本估算 | 完成偿还所需投入 | 用相对单位（如人天）给出区间，注明是否包含测试与回归；估算依据写在描述或备注中 |
| 风险等级 | 不偿还的后果严重程度 | 综合发生概率与影响面判断：可能引发线上故障或安全问题的记高，拖慢局部开发效率的记中，仅影响可读性的记低 |
| 优先级 | 偿还排序 | 由风险等级与偿还成本共同决定，高风险低成本优先；优先级可与风险等级不同，需能解释差异 |
| 责任人 | 对偿还结果负责的人 | 填具体个人而非团队名，责任人负责推进评估、排期和验证，不一定是主要编码人 |
| 计划偿还时间 | 预计完成的时间点 | 填季度、迭代或具体日期，与团队排期粒度一致；未排期时填“待排期”并注明复核时间 |
| 状态 | 债务当前所处阶段 | 从取值表中选，状态变更时同步更新日期，便于统计停留时长 |
| 验证方式 | 判断债务已偿还的依据 | 写可核验的结果，例如“压测通过既定并发指标”“依赖升级后回归用例全部通过”“新成员可按文档独立完成部署” |
需要特别说明与缺陷管理的边界：已经确认、可复现、需要按缺陷流程修复的功能问题，走缺陷管理，不登记为技术债。技术债记录的是当前能运行、但结构或质量上存在长期代价的问题，例如重复代码、缺失的自动化测试、过期依赖、口头传递的部署步骤。若一条记录既有功能缺陷又有结构性成因，缺陷部分单独提单，结构性成因登记为技术债，并在描述中互相引用编号。
必填与选填：最小可用台账怎么填
启动台账时不必一次填满所有字段。最小可用台账保留六个必填字段，就能支撑“有什么债、谁来管、什么时候还、怎么算还完”这条主线；其余字段随治理深入逐步补齐。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 债务编号 | 必填 | 唯一标识是引用、统计和交接的基础 |
| 名称 | 必填 | 没有名称的台账无法在会议和排期中被讨论 |
| 描述 | 必填 | 至少说明现状与不处理的后果，避免记录变成只有标题的空壳 |
| 风险等级 | 必填 | 决定是否进入偿还计划，是排序的第一依据 |
| 责任人 | 必填 | 没有责任人的债务会长期停留在“已确认” |
| 状态 | 必填 | 支撑台账的日常筛选和进度统计 |
| 类型 | 选填 | 债务数量增多后用于分类统计和分配治理资源 |
| 来源 | 选填 | 用于复盘债务成因、改进流程时填写 |
| 影响范围 | 选填 | 跨团队协作或需要向上汇报影响时填写 |
| 偿还成本估算 | 选填 | 进入排期前补齐，用于和业务需求比较投入产出 |
| 优先级 | 选填 | 债务条目较多、需要统一排序时填写 |
| 计划偿还时间 | 选填 | 纳入迭代或季度计划时填写，未排期可先留空 |
| 验证方式 | 选填 | 进入偿还中状态前补齐，作为关闭依据 |
最小可用台账与完整台账的差异在于治理深度：前者适合刚建立台账、债务条目少于二三十条的团队，重点是把隐性债务显性化并指定责任人；后者适合债务跨多个系统、需要按季度规划偿还资源的团队，此时类型、成本估算和优先级成为排期会议的输入。两种形态使用同一张表，只是填写完整度不同，不需要维护两套模板。
填写示例：一条技术债从登记到关闭
以下示例为演示情景，用于说明字段取值方式，不代表任何真实团队的数据。
| 字段 | 填写内容 |
|---|---|
| 债务编号 | TD-014 |
| 名称 | 订单查询接口缺少自动化回归测试 |
| 描述 | 订单查询接口在两次大促前为赶进度由人工验证上线，目前无自动化用例覆盖。每次改动需人工回归约半天，且曾因漏测导致一次查询结果字段缺失，上线后由客服反馈才发现。 |
| 类型 | 测试覆盖 |
| 来源 | 赶发布临时简化验证流程，后续未补 |
| 影响范围 | 订单服务查询模块，影响该模块的每次发布及负责回归的两名开发 |
| 偿还成本估算 | 3～5 人天，含用例编写、测试数据准备与流水线接入 |
| 风险等级 | 高 |
| 优先级 | 高 |
| 责任人 | 订单服务负责人（示例中以角色代称） |
| 计划偿还时间 | 下一季度第一个迭代 |
| 状态 | 已确认 |
| 验证方式 | 核心查询场景自动化用例接入流水线，连续两个迭代发布均无人工回归遗漏 |
关键字段的取值理由：风险等级定为高，是因为该接口位于交易主链路，且已有漏测导致线上问题的记录；偿还成本给出区间而非单点，是因为用例范围需要在评估阶段与责任人确认；验证方式写成可观察的结果，而不是“补充测试”这类动作描述，这样关闭时有明确依据。
状态流转示例：登记时状态为“待评估”；责任人确认成本与范围后改为“已确认”；进入迭代开始补用例时改为“偿还中”；用例接入流水线并通过两个迭代观察后改为“待验证”；由非经办人按验证方式核对后改为“已关闭”。若该季度资源被业务需求占满，可改为“已搁置”，并在描述中注明复核时间为下季度初。
调整与维护：让台账持续可用
台账失效通常源于两个原因：只在建立时填过一次，之后无人更新；字段越加越多，填写成本高到没人愿意维护。维护规则应围绕固定节奏和克制的字段变更来设计。
- 评审节奏：建议每两周或每个迭代在固定例会上过一遍台账，只讨论状态变化、新增高风险条目和逾期未动的条目；每季度做一次全量复核，重新校准风险等级和计划偿还时间。团队规模小、债务条目少时，可合并为每月一次。
- 字段增删原则：新增字段需说明它支撑哪个决策，例如新增“所属系统”是为了按系统分配治理资源；连续两个季度无人使用的字段应删除或并入描述。字段口径变更时，在台账说明页记录变更日期和旧数据如何处理，避免历史记录无法比较。
- 关闭与归档规则：关闭必须由非经办人按验证方式核对，关闭时保留原记录并补充关闭日期与验证结论，不直接删除行。已关闭条目按季度归档到单独视图，主视图默认只显示未关闭条目，保证日常查看不被历史记录淹没。
- 与排期的衔接：进入偿还计划的条目应转化为团队排期中的具体任务，台账保留编号和状态，任务完成后回写验证结论，避免台账与执行系统两套记录各说各话。
当债务条目增多、跨团队协作频繁时，可以把台账放到协作工具中承载，减少手工同步。以 ONES 为例，可将每条债务建为工作项，用自定义字段承载类型、风险等级、偿还成本估算等列，用状态流转对应“已确认—偿还中—待验证—已关闭”，责任人字段直接关联成员；评审时按风险等级和状态筛选出待讨论条目，验证结论作为评论或附件留在同一条工作项上，台账视图与排期任务共享同一份数据。具体字段配置和视图能力以团队实际使用的产品版本为准。
常见问题
技术债台账和缺陷列表需要分开维护吗？
建议分开维护，但允许互相引用。已经确认、可复现、需要按缺陷流程修复的功能问题走缺陷管理；技术债记录的是当前能运行、但结构或质量上存在长期代价的问题，例如重复代码、缺失的自动化测试、过期依赖。若一条记录既有功能缺陷又有结构性成因，缺陷部分单独提单，结构性成因登记为技术债，并在描述中写明对应编号，方便后续追溯。
团队刚开始建台账，条目很少，需要一次填满所有字段吗？
不需要。条目少于二三十条时，先填编号、名称、描述、风险等级、责任人和状态六个必填字段，就能支撑“有什么债、谁来管、什么时候还、怎么算还完”这条主线。类型、来源、影响范围、偿还成本估算、优先级、计划偿还时间和验证方式可以随治理深入逐步补齐。最小可用台账和完整台账使用同一张表，只是填写完整度不同，不必维护两套模板。
风险等级和优先级看起来重复，能不能只保留一个？
两者回答的问题不同。风险等级判断不偿还的后果严重程度，综合发生概率与影响面；优先级是偿还排序，由风险等级与偿还成本共同决定，高风险低成本的条目通常排在前面。条目较少时可以先只填风险等级，进入排期阶段再补优先级。若两者取值不同，需要在描述或备注中写明理由，避免评审时无法解释排序依据。
债务一直排不进迭代，台账里应该怎么处理？
把状态改为“已搁置”，并在描述中注明搁置原因和复核时间，例如“本季度资源被业务需求占满，下季度初复核”。搁置不等于删除，条目仍保留在台账中，季度全量复核时重新评估风险等级和计划偿还时间。若搁置条目持续增多，说明偿还资源与债务积累速度不匹配，需要在评审会上把这一情况作为排期输入讨论。
台账放在表格里和放在协作工具里，怎么选？
条目少、参与角色单一时，表格工具上手快，复制模板即可开始。债务跨多个系统、需要与排期任务联动、多人频繁更新状态时，放到协作工具中承载可以减少手工同步。以 ONES 为例，可将每条债务建为工作项，用自定义字段承载类型、风险等级、偿还成本估算等列，用状态流转对应“已确认—偿还中—待验证—已关闭”，评审时按风险等级和状态筛选待讨论条目。具体字段配置和视图能力以团队实际使用的产品版本为准。
