技术债偿还机制的价值，在于把“看不见的欠账”变成可登记、可评估、可排期、可验收的治理闭环。本文给出一份演示情景下完整填写的示例：从债务条目登记、定级打分，到排期取舍与验收关闭，逐项解释字段取值和判断依据。示例中的登记与排期环节，可以借助 ONES 的工作项与迭代管理来承载，团队按自身情况调整参数即可。
要点总览（TL;DR）
- 技术债偿还机制由登记、定级、排期、执行、验收五个环节组成，缺一环闭环就会断掉。
- 登记表至少包含编号、条目、来源、影响面、偿还成本、风险等级、负责人、目标迭代八个字段，负责人和目标迭代必须落到具体的人和迭代编号。
- 优先级用影响分除以成本分做初筛，再对涉及核心链路等例外做人工校准；高成本低影响的条目适合放进专项窗口，而非塞进常规迭代。
- 排期可采用固定比例为主、专项窗口为辅的组合，示例取每迭代约 20% 容量，比例需按债务积累程度调整。
- 已确认的功能 Bug 归缺陷管理，不纳入技术债条目；判断边界看它是否改变用户可见的功能行为。
示例目标：这份技术债偿还机制要解决什么问题
先说明示例的设定。本文所有团队信息、债务条目、评分和排期均为演示情景，用于展示一份机制如何填写完整，不代表任何真实客户案例，也不附带实测效果。读者可以把它当作模板参照，替换成自己团队的数据。
示例假设一个 12 人左右的产品研发团队，采用两周一个迭代的节奏，系统已上线两年多，历史代码中存在若干积累问题。债务来源主要有三类：日常开发中顺手记录的小问题、线上故障复盘后发现的隐患、以及架构评审时提出的结构性改进点。这个设定覆盖了多数中型团队的常见情况，规模更小或遗留系统更重的团队需要相应调整。
机制要覆盖五个环节，缺一环闭环就会断掉：
- 登记：把口头抱怨或零散笔记转成有统一字段的条目，避免债务只存在个人记忆里。
- 定级：用影响面和偿还成本两个维度打分，形成可比较的优先级，减少“谁声音大谁先做”。
- 排期：按固定比例或固定窗口把偿还任务放进迭代，让偿还成为常态动作而非临时救火。
- 执行：明确负责人和目标迭代，条目进入开发流程，与普通需求一样被跟踪。
- 验收：用事先约定的验收标准和回归证据判断是否关闭，防止“改了一半就算完成”。
判断这套机制是否有效的标准很朴素：每个季度回看时，能说清楚登记了多少条、关闭了多少条、哪些条目被反复推迟以及原因。如果条目只进不出，或者关闭时拿不出验收依据，说明机制某个环节需要修正。
完整示例：一份填好的技术债登记与偿还计划
下面是一份已填写的登记表。字段设计围绕“能不能被评估和排期”展开：来源说明债务从哪来，影响面决定它有多急，偿还成本决定它有多重，风险等级是两者的综合结论，负责人和目标迭代则把条目落到具体的人和节奏上。
| 编号 | 债务条目 | 来源 | 影响面 | 偿还成本 | 风险等级 | 负责人 | 目标迭代 |
|---|---|---|---|---|---|---|---|
| TD-01 | 订单查询接口缺少缓存，高峰期响应时间波动明显 | 线上故障复盘 | 高：影响核心交易链路，日均调用量大 | 中：约 5 人日，涉及缓存层改造 | P1 | 后端 A | 迭代 12 |
| TD-02 | 用户模块与权限模块存在循环依赖，改动一处需回归多处 | 架构评审 | 中：影响三个业务模块的日常改动效率 | 高：约 15 人日，需要拆分与迁移 | P2 | 后端 B | 迭代 14–15（专项窗口） |
| TD-03 | 日志格式不统一，排查问题需人工比对多个服务 | 日常开发记录 | 低：只影响排查效率，不影响线上功能 | 低：约 2 人日，统一日志模板 | P3 | 后端 C | 迭代 13 |
| TD-04 | 前端构建脚本硬编码环境配置，新环境部署需手工改文件 | 日常开发记录 | 中：影响部署效率，易出错 | 低：约 1 人日，改为配置注入 | P2 | 前端 D | 迭代 12 |
定级规则采用两维打分：影响面按高、中、低分别记 3、2、1 分，偿还成本按低、中、高分别记 1、2、3 分，用“影响分 ÷ 成本分”得到优先级参考值，再结合是否涉及核心链路做人工校准。按此规则，TD-01 为 3÷2=1.5，TD-04 为 2÷1=2.0，TD-03 为 1÷1=1.0，TD-02 为 2÷3≈0.67。参考值越高越优先，但 TD-01 因涉及核心交易链路被上调为 P1，排在参考值更高的 TD-04 之前。
排期上，示例团队采用“固定比例为主、专项窗口为辅”的组合：每个迭代预留约 20% 的容量用于偿还 P1 和 P2 条目，P3 条目按季度集中清理一次。TD-02 成本高、涉及跨模块改造，20% 的常规容量无法容纳，因此安排在第 14–15 迭代的专项窗口集中处理，期间暂停非紧急需求。TD-01 和 TD-04 进入迭代 12，TD-03 进入迭代 13 的常规偿还容量。
验收标准在登记时就要写清楚，示例中约定：TD-01 以高峰期响应时间回到设定阈值内、并附压测报告为关闭依据；TD-02 以循环依赖消除、相关模块回归用例全部通过为关闭依据；TD-03 以三个服务的日志格式统一、抽查比对通过为关闭依据；TD-04 以新环境部署无需手工改文件、部署脚本评审通过为关闭依据。条目关闭时，负责人需附上对应证据，由技术负责人复核。
逐项解释：字段取值和排期取舍为什么这样定
影响面与偿还成本共同决定优先级，但两者的作用方向不同。影响面回答“不还会怎样”，偿还成本回答“还起来多贵”。只看影响面，团队会不断被高影响条目牵着走，忽略那些低成本高收益的小改进；只看成本，又容易把精力花在容易做但不重要的地方。用比值做初筛、再用人工校准处理例外，是兼顾效率和判断质量的常见做法。
TD-02 是理解排期取舍的关键例子。它的影响面是中，偿还成本是高，参考值在四条中最低，因此没有进入当前迭代。这不代表它不重要——循环依赖会持续拖慢日常改动，但它需要连续的大块时间和跨模块协调，塞进常规迭代只会被频繁打断，反而拉长周期。把它放进专项窗口，是为了给它匹配的资源形态。反过来说，如果一条债务影响面高、成本也高，就不能简单推迟，而应评估是否需要更早启动专项。
固定比例偿还和专项窗口适用于不同场景。固定比例适合条目多、单条成本可控的常态治理，好处是节奏稳定、对需求交付冲击小，风险是容易变成“每次做一点、始终做不完”。专项窗口适合结构性改造，好处是能集中资源一次解决，代价是期间需求交付让路，需要提前和业务方对齐。示例团队两者并用，正是因为债务组合里既有小条目也有大改造。
负责人和目标迭代两个字段的填写有硬性要求。负责人必须是实际执行的人，不能填“后端团队”这类集体名称，否则条目无人真正认领。目标迭代必须落到具体迭代编号，填写“尽快”“下季度”等于没有排期。这两个字段一旦空缺，条目就退化成待办清单里的一条备注，无法进入跟踪和验收。
可迁移规律：换到你的团队要改哪些地方
示例中可以直接复用的，是“登记—定级—排期—验收—关闭”这条骨架，以及每个环节对应的产物：统一字段的登记表、可比较的定级结果、落到迭代的排期计划、事先写明的验收标准、附证据的关闭记录。骨架不变，机制就不会因为团队换人而失效。
需要按团队情况调整的参数主要有三类：
- 偿还比例：示例取 20%，债务积累重、线上稳定性压力大的团队可以上调，交付压力紧的团队可以下调，但不宜长期为零。
- 定级权重：示例用影响分除以成本分，团队也可以给“是否涉及核心链路”“是否有合规要求”单独加权，权重应写进规则并保持一段时间稳定，避免每次评审临时改口径。
- 评审周期：示例按迭代排期、按季度回看，条目量大的团队可以改为每月评审一次登记表，及时清理过期条目。
债务条目与缺陷、需求的边界要在机制里写清楚。已经确认的功能 Bug 走缺陷管理流程，按缺陷的严重程度和处理时限跟进，不重复登记为技术债；新功能开发走需求流程。技术债条目针对的是“当前能运行、但持续增加未来成本”的问题，例如结构耦合、缺少防护、配置硬编码。边界模糊时，判断标准是：它是否改变用户可见的功能行为。改变行为的归缺陷或需求，不改变行为但增加维护成本的归技术债。
角色分工上，示例设三个角色：条目提出者负责写清来源和现象，技术负责人负责定级校准和验收复核，条目负责人负责执行和提交证据。评审节点有两个：迭代排期会确认本迭代纳入哪些条目，条目关闭时做验收复核。条目登记和排期如果放在 ONES 的工作项与迭代管理中，登记字段可以作为工作项属性统一维护，目标迭代直接对应迭代计划，验收证据随条目附件留存，回看时按迭代和状态筛选即可得到进出情况。
适用边界：这套机制在什么情况下需要调整
这套机制适用于已有稳定迭代节奏、债务来源相对分散的研发团队。它假设团队愿意为偿还预留固定容量，并且有基本的技术评审能力来判断影响面和成本。以下情形需要调整或另作安排。
已确认的功能 Bug 归缺陷管理，不纳入技术债条目。把 Bug 混进债务表会让优先级判断失真，也会模糊两类工作的处理时限。具体重构代码怎么写、缓存层如何设计，属于工程实践，本文只讨论治理机制，不展开代码教程。
团队规模和遗留系统比例会显著影响机制复杂度。十人以下的小团队，登记表可以精简到编号、条目、影响面、负责人、目标迭代五个字段，评审合并到周会；遗留系统占比高、债务条目数以百计的团队，则需要更细的分类维度（如按模块、按系统层级）和更频繁的清理节奏，否则登记表本身会变成新的负担。
机制失效有几个常见信号：条目连续多个迭代被推迟且没有记录原因；关闭条目时拿不出验收证据；登记表长期只有新增没有关闭；偿还容量被需求持续挤占且无人提出。出现这些信号时，先复核定级规则是否还符合当前业务重点，再检查排期容量是否被真实执行，必要时缩短回看周期，把问题暴露在更早的节点上。
常见问题
技术债条目登记后长期没人认领，机制该怎么补？
先检查负责人字段是否填成了集体名称。示例要求负责人必须是实际执行的人，填“后端团队”这类名称会让条目无人真正认领。补法有两个：一是在迭代排期会上逐条确认负责人，未确认的条目退回登记池；二是给登记表加一个“提出者”字段，由提出者负责在评审前找到愿意承接的人。如果条目反复无人认领，通常说明它的影响面被高估或偿还成本被低估，需要重新定级。
偿还容量每个迭代都被需求挤占，怎么让机制真正执行？
容量被挤占往往不是排期问题，而是优先级没有形成约束。可以把偿还容量写进迭代计划的准入规则：每个迭代排期时先锁定约定比例的容量，再排需求，而不是排完需求看剩多少。同时记录被挤占的次数和原因，按季度回看。如果挤占持续发生且无人提出，说明机制已经失效，需要由技术负责人和业务方重新对齐偿还节奏，必要时改为专项窗口集中处理。
技术债条目和缺陷、需求之间的边界模糊时怎么判断？
用一条标准判断：它是否改变用户可见的功能行为。改变行为的归缺陷或需求，按各自的流程和时限跟进；不改变行为但持续增加维护成本的，例如结构耦合、缺少防护、配置硬编码，归技术债。已经确认的功能 Bug 走缺陷管理，不重复登记为技术债，否则优先级判断会失真，两类工作的处理时限也会被混淆。
小团队照搬这套机制会不会太重？
十人以下的团队可以精简。登记表保留编号、条目、影响面、负责人、目标迭代五个字段即可，定级用简单的高中低判断，评审合并到周会，回看按季度进行。机制复杂度应与债务条目数量匹配：遗留系统占比高、条目数以百计的团队才需要更细的分类维度和更频繁的清理节奏，否则登记表本身会变成新的负担。
条目关闭时验收证据应该包含什么？
验收标准要在登记时就写清楚，关闭时按事先约定的标准提交证据。示例中，性能类条目附压测报告，结构改造类条目附回归用例通过记录，配置类条目附部署验证结果。证据由条目负责人提交，技术负责人复核。如果关闭时拿不出验收证据，说明验收标准在登记阶段就没有写清，应把这一条作为机制复核的重点信号。
