技术债偿还机制要解决的是“知道有债、却总排不上”的问题。做法是把技术债纳入有台账、有分级、有决策规则、有固定排期的常规工作：先登记并分级，再明确谁提议、谁评估、谁批准，然后按固定比例或固定窗口排进迭代，最后用存量、滞留时长和完成率验证效果。本文按建立顺序给出字段表、评分表、决策规则和检查清单。
要点总览（TL;DR）
- 技术债偿还机制由台账、分级、决策规则、排期通道四个部件组成，按此顺序建立，缺一个就会退化成临时项目。
- 台账用统一字段登记债务描述、影响范围、产生原因、预估工作量、风险等级、责任人和发现时间，并与缺陷单、需求单划清边界。
- 分级按影响面、故障风险、变更成本、偿还紧迫度四个维度打分，权重公示且至少一个季度不变，高等级需附线上事件或变更耗时等证据。
- 决策规则按风险等级和是否阻塞重大需求触发，明确提出人、技术负责人、产品负责人、研发管理者的分工，被否决条目记录理由和重评日期。
- 排期可选固定容量比例或固定偿还窗口，偿还任务拆到1–3人天并写明验收标准；季度用存量变化、平均滞留时长、完成率检查机制是否运转。
机制先立四件事：台账、分级、决策、排期
技术债偿还机制的最小完整形态由四个部件组成，缺一个都会让机制退化成临时项目。台账解决“债在哪里、有多少”，分级解决“先还哪个”，决策规则解决“谁批准、什么条件下批准”，排期通道解决“什么时候做”。四者的依赖关系是单向的：没有台账就无法分级，没有分级就无法设定决策阈值，没有决策结论就进不了排期。因此建立顺序也应按此推进，先让台账跑起来，再补评分和规则。
| 部件 | 解决的问题 | 关键产物 | 建立顺序 |
|---|---|---|---|
| 登记台账 | 技术债分散在个人记忆和评审意见里，无法盘点 | 技术债台账（统一字段） | 1 |
| 分级标准 | 不同团队的债务无法横向比较，排序靠声音大小 | 评分表与分档说明 | 2 |
| 决策规则 | 偿还资源靠个人争取，结论不稳定 | 条件—角色—动作规则表 | 3 |
| 排期通道 | 债务长期挂在待办里，进不了迭代 | 容量比例或固定窗口规则 | 4 |
这套机制与一次性重构的区别在于持续性：集中重构是一次性投入，结束后债务会重新积累；机制要求每个迭代都有偿还动作，并保留存量数据供复核。它与缺陷修复的区别在于对象：已确认的功能 Bug 走缺陷管理流程，按故障响应处理；技术债指向的是当前可运行、但会抬高后续变更成本的结构性问题，例如重复逻辑、缺失的自动化测试、过时的依赖版本。
第一步：用统一字段登记技术债
登记环节的目标是让任何一名工程师都能在十分钟内把一条技术债写清楚，并让其他人读得懂。识别来源通常有四类：代码评审中反复出现的同类意见、架构评审指出的结构性风险、线上问题复盘时发现的深层原因、研发人员在日常工作中主动提出的改进点。这四类来源都应汇入同一张台账，避免分散在文档、聊天记录和会议纪要中。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 债务描述 | 一句话说明问题位置与现象，避免只写“代码质量差” | 订单服务与结算服务各有一份优惠计算逻辑，规则已出现不一致 |
| 影响范围 | 涉及的模块、服务或团队 | 订单、结算两个模块，影响三个研发小组 |
| 产生原因 | 历史赶工、需求变更、技术选型过时等 | 大促前临时复制逻辑，未做抽取 |
| 偿还预估工作量 | 以人天为单位给出区间 | 5–8 人天 |
| 风险等级 | 按分级标准填写，登记时先给初评 | 中 |
| 责任人 | 对该债务最熟悉的工程师，负责补充信息和推进评估 | 订单组某工程师 |
| 发现时间 | 首次登记日期，用于计算滞留时长 | 2025-03-12 |
边界划分需要在登记规则中写清楚：已确认导致功能异常的问题登记为缺陷，按缺陷流程处理；能带来用户可见新能力的登记为需求；技术债条目描述的是内部结构问题，其偿还结果通常不直接产生新功能。登记入口建议只保留一个，由技术负责人或轮值人员每周汇总去重。去重规则可以按“同一模块、同一根因”合并，合并后在描述中注明关联条目，保留原始提出人信息。
第二步：分级与评估，把主观感受变成可比排序
分级的作用是让两个不同团队提出的债务可以放在同一张表里排序。建议采用四个维度打分，每个维度 1–5 分，加权后得到总分并映射为高、中、低三档。权重不必追求精确，但要在团队内公示并保持至少一个季度不变，否则排序结果无法跨期比较。
| 维度 | 评分含义（1 分→5 分） | 建议权重 |
|---|---|---|
| 影响面 | 影响单文件→影响多个核心服务与团队 | 25% |
| 故障风险 | 几乎不引发问题→已多次引发线上异常 | 35% |
| 变更成本 | 改动局部→每次相关需求都要额外绕行 | 25% |
| 偿还紧迫度 | 可长期搁置→阻塞近期重大变更 | 15% |
评估由技术负责人牵头，提出人和相关模块的工程师参与，评估时点安排在债务登记后的两周内或月度评估会上。为避免评级通胀，可以设两条校准规则：一是高等级债务需要给出具体证据，例如线上事件记录或变更耗时数据；二是每季度抽查一部分评级，由未参与初评的技术人员复核，偏差较大的条目重新打分。评分表的价值在于形成排序依据，而不是追求分数精确。
第三步：定决策规则，明确谁在什么条件下批准偿还
决策规则把“要不要还”从讨论变成判断。角色分工上，提出人负责提供事实和预估，技术负责人负责评级与方案，产品负责人判断对需求排期的影响，研发管理者批准资源投入。规则表按条件触发，减少每次开会重新争论。
| 触发条件 | 决策角色 | 动作 |
|---|---|---|
| 风险等级为高，或已引发线上故障 | 研发管理者批准，技术负责人执行 | 当迭代插入，占用不超过当迭代 20% 容量 |
| 风险等级为中，且阻塞近期重大需求 | 技术负责人与产品负责人共同确认 | 作为需求的前置任务排入同一迭代 |
| 风险等级为中，无近期阻塞 | 技术负责人 | 进入偿还池，按固定比例排期 |
| 风险等级为低 | 技术负责人 | 合并处理或随相关模块改动顺带偿还 |
决策会建议每月一次，控制在 60 分钟内，议程固定为：新增高等级债务评审、上月偿还完成情况、被否决条目的复议。被否决的债务不删除，记录否决理由和重评日期，到期自动回到议程。这样既保留决策痕迹，也避免同一议题反复占用会议时间。
第四步：把偿还排进迭代，形成固定节奏
排期有两种常用方式，选择取决于团队需求波动程度。固定容量比例指每个迭代预留一定比例容量给技术债，适合需求相对稳定的团队，优点是节奏均匀，缺点是高优先级债务无法快速插入；固定偿还窗口指每个季度安排一个专门迭代集中偿还，适合需求波动大、平时难以预留容量的团队，缺点是对突发高等级债务响应慢。两种方式可以组合：日常按比例预留，季度窗口处理积压条目。
偿还任务的拆分粒度建议控制在 1–3 人天，单个任务对应可验证的完成标志，例如“优惠计算逻辑抽取为公共模块，两个服务改为调用同一实现，相关单测覆盖率达到约定水平”。验收标准在任务创建时写清，由技术负责人或指定评审人确认。与需求排期冲突时，按决策规则表中的容量上限处理，超出部分顺延到下一迭代并记录原因。偿还任务在工具中应有独立的状态流转，从待评估、已批准、已排期到已完成，并在迭代看板上与需求任务同屏可见，避免被当作隐形工作。
当台账和偿还任务需要长期维护时，可以把它们放进研发管理工具承载。ONES Project 支持自定义需求状态与多种属性，可将工作项规划至迭代并分配负责人，适合把技术债条目和偿还任务纳入同一套工作项管理；任务工时统计和看板、燃尽图可用于观察偿还任务的实际投入与进度。ONES Wiki 支持文档关联任务，可将台账说明、评分口径与对应工作项放在一起，减少文档与执行脱节。
角色与交付物：谁负责哪一段
机制落地时最常见的断点是交接：提出人写完就不管，技术负责人评完级没有排期，产品负责人不知道容量被占用。用一张对照表把输入、动作和输出固定下来，可以减少这类断点。
| 角色 | 输入 | 动作 | 输出物 |
|---|---|---|---|
| 研发工程师 | 评审意见、线上复盘、日常发现 | 按字段登记债务，补充影响范围与预估 | 台账条目 |
| 技术负责人 | 台账条目、评级证据 | 组织评估、给出方案与工作量、提出排期建议 | 评级结果、偿还方案 |
| 产品负责人 | 评级结果、需求计划 | 判断偿还对需求的影响，确认前置关系 | 排期意见 |
| 研发管理者 | 决策规则表、容量数据 | 批准高等级债务的资源投入，主持月度决策会 | 决策记录 |
| 质量角色 | 偿还任务的验收标准 | 确认测试覆盖与回归结果 | 验收结论 |
交接时点建议固定：登记后两周内完成初评，月度决策会前三天提交待议条目，迭代规划会前完成排期确认，任务完成后三个工作日内完成验收。每次交接以台账状态变更或会议记录为准，口头确认不作为完成依据。
示例：一个中等规模研发团队的首个季度运行
以下为演示情景，团队规模、比例和周期需按实际情况调整。某研发团队约 40 人，分 5 个小组，按双周迭代运行。第一个月建立机制：技术负责人牵头制定台账字段和评分表，各组用两周时间登记历史债务，共录入 46 条，去重合并后保留 38 条。首次评估会评出高等级 6 条、中等级 19 条、低等级 13 条，高等级条目集中在支付链路的重复逻辑和缺失的自动化回归测试。
第一次月度决策会议题为 6 条高等级债务，结论是其中 2 条当迭代插入，各占约 10% 容量；3 条进入偿还池按每迭代 15% 容量排期；1 条因依赖外部系统升级，记录重评日期为两个月后。会议记录包含每条债务的决策角色、结论和排期迭代，存入台账关联文档。第二、三个月的迭代规划会上，偿还任务与需求任务同屏排入，每个任务拆到 1–3 人天并写明验收标准。
季度末复盘数据：38 条债务中完成偿还 11 条，其中高等级 4 条；新增登记 9 条；存量从 38 条变为 36 条，高等级从 6 条降至 2 条；已批准债务的平均滞留时长从建立初期的约 70 天降至 35 天；偿还任务按期完成率 82%，未完成的主要原因是需求插入导致容量被挤占。复盘结论是下季度把容量比例从 15% 提高到 18%，并对连续两个迭代被挤占的条目设置升级提醒。
完成检查：机制是否真的在运转
机制是否落地，看的是台账和迭代里的实际记录，而不是制度文档写得多完整。以下清单可按季度逐项核对，任一项连续两个季度不达标，就应调整对应环节。
- 台账持续更新：本季度有新增登记，也有状态变更；不存在超过一个季度未评估的条目。
- 决策按期召开：月度决策会按计划召开，每次留有议题、结论、责任人和排期记录。
- 偿还真实进入迭代：已批准债务在迭代看板中可见，有负责人和验收标准，完成情况可查。
- 指标可观察：能给出债务存量变化、高等级占比、平均滞留时长、偿还完成率四项数据，且口径前后一致。
- 否决有闭环：被否决条目记录理由和重评日期，到期回到议程。
机制失效时按症状调整：台账长期不更新，说明登记入口太重或缺少责任人，应简化字段并指定轮值维护人；决策会流于形式，说明规则表没有真正触发，应检查阈值是否过高、容量是否从未预留；偿还任务完不成，说明排期方式与需求波动不匹配，可改用固定窗口或提高容量比例；指标无法计算，说明字段设计缺少发现时间和状态流转记录，应补齐后再谈度量。调整后保留一个季度的观察期，避免频繁改动规则导致数据不可比。
常见问题
技术债台账和缺陷单、需求单怎么划清边界？
按问题性质和结果来分：已确认导致功能异常的问题登记为缺陷，走缺陷管理流程；能带来用户可见新能力的登记为需求；技术债条目描述的是内部结构问题，例如重复逻辑、缺失的自动化测试、过时的依赖版本，偿还结果通常不直接产生新功能。登记规则里把这三条写清楚，并在台账中保留与关联缺陷、需求的引用关系，可以避免同一问题在多处重复登记。
团队规模较小、没有专职技术负责人时，决策角色怎么安排？
角色可以合并，但职责要分开记录。小团队可由研发管理者兼任技术负责人的评级职责，产品负责人由最熟悉需求排期的人承担。关键是每次决策留下记录：谁提出、谁评估、谁批准、排到哪个迭代。合并角色时建议把高等级债务的批准动作保留在两人以上确认，避免评级和批准由同一人完成而失去校准。
固定容量比例和固定偿还窗口，应该选哪一种？
看需求波动程度。需求相对稳定的团队适合固定容量比例，每个迭代预留一部分容量，节奏均匀；需求波动大、平时难以预留容量的团队适合固定偿还窗口，每季度安排一个专门迭代集中处理积压。两者可以组合：日常按比例预留，季度窗口处理积压条目。选择后至少运行一个季度再评估，频繁切换会让存量与滞留时长数据失去可比性。
高等级技术债已经批准，但连续几个迭代被需求挤占怎么办？
先看排期规则是否被执行：决策规则表中高等级债务的容量上限是否真的在迭代规划时预留。如果容量被反复挤占，可采取两个动作：一是对连续两个迭代被挤占的条目设置升级提醒，回到月度决策会重新确认优先级；二是检查容量比例是否偏低，按季度复盘数据适度上调。记录每次挤占的原因，也能为后续调整提供依据。
技术债台账和偿还任务放在研发管理工具里管理，有什么实际好处？
台账和偿还任务分散在文档、聊天记录里时，状态变更和排期结果难以追踪。放进研发管理工具后，技术债条目可以和需求、任务使用同一套工作项管理：ONES Project 支持自定义需求状态与多种属性，可将工作项规划至迭代并分配负责人，任务工时统计和看板、燃尽图可用于观察偿还任务的实际投入与进度；ONES Wiki 支持文档关联任务，可将台账说明、评分口径与对应工作项放在一起。具体字段配置以实际版本为准。
