技术债分类要能支撑偿还决策，做法是先明确分类结果用于哪类决策，再选定债务类型、影响面、偿还紧迫度和偿还成本四个维度，为每个维度定义可判定的取值，把分类动作嵌入需求评审、迭代回顾、技术评审和线上问题复盘，最后登记条目并定期复核。分类不追求穷尽，关键是让同类债务被一致识别、排序和分派。
要点总览（TL;DR）
- 技术债分类先定用途：分类结果要支撑是否偿还、何时偿还、由谁偿还中的一到两个决策，只保留能改变结论的维度。
- 常用四个维度是债务类型、影响面、偿还紧迫度和偿还成本，每个维度给出可观察的判定依据，让不同人分类结果一致。
- 分类动作嵌入需求评审、迭代回顾、技术评审和线上问题复盘，输出包含描述、位置、维度取值、判定依据、责任人和复核时间的登记条目。
- 开发提出并初判，技术负责人复核并维护维度表，产品/项目角色补充业务侧依据，排期或预算决策者使用分类结果。
- 用一致性、可追溯、时效和使用四项检查验收分类机制，某项反复不通过时优先修该环节的输入和交付物。
先定分类目的：分类结果要支撑哪个决策
技术债分类的第一步是写下分类结果要回答的问题。常见有三类：决定某条债务是否偿还、何时偿还；为技术债偿还申请预算或排期资源；向上级或跨团队上报风险。三类决策对分类的要求不同，维度取舍也不同。
以偿还排序为主要目的时，分类需要能区分债务的紧急程度和影响范围，维度粒度可以细到模块或用户路径，更新频率跟随迭代节奏。以预算申请为主要目的时，分类要能把多条债务归并成可估算成本的批次，维度粒度偏粗，更新频率按季度或半年度即可。以风险上报为主要目的时，分类要突出影响面和潜在后果，对成本精度的要求可以放低。
取舍原则是只保留能改变决策的维度。判断方法很直接：假设某条债务在某个维度上取不同值，偿还结论是否会变化。如果不会变化，这个维度就不必进入分类表。例如团队并不按债务类型分配偿还资源，那么债务类型可以只作为描述字段，不参与排序。
分类目的说明建议写成一页以内的文档，包含三项内容：本团队要支撑的一到两个决策、据此保留的维度清单、明确舍弃的维度及舍弃理由。这份说明是后续维度定义和流程设计的依据，也方便新成员理解分类表为什么这样设计。
四个常用分类维度及取值定义
下面四个维度覆盖了偿还决策最常需要的判断信息。每个维度都给出取值和判定依据，判定依据要指向可观察的事实，例如代码位置、调用关系、缺陷记录或依赖版本，避免使用“感觉比较乱”这类主观描述。
债务类型
债务类型描述问题属于哪一类，取值建议包括：代码结构、架构设计、测试覆盖、文档缺失、依赖过时、环境与工具。判定依据如下：
| 取值 | 判定依据 | 示例 |
|---|---|---|
| 代码结构 | 存在重复逻辑、过长函数、职责混杂的模块，且已影响修改效率 | 订单状态判断逻辑在三个服务中各写一遍 |
| 架构设计 | 模块间依赖方向与既定架构约定不一致，或存在绕开接口的直接访问 | 报表模块直接读取交易库表 |
| 测试覆盖 | 关键路径缺少自动化测试，或测试长期失败被跳过 | 支付回调链路无集成测试 |
| 文档缺失 | 接口、部署或运维步骤没有可查记录，交接依赖口头说明 | 定时任务清单只存在于某位成员本地 |
| 依赖过时 | 依赖版本落后于团队约定基线，或已停止维护 | 某日志库版本低于团队基线两个大版本 |
| 环境与工具 | 构建、部署或测试环境存在已知缺陷，需要人工绕过 | 测试环境数据需手工导入才能跑通用例 |
影响面
影响面回答“这条债务出问题时波及哪里”，从三个角度判定：受影响模块、涉及的用户路径、需要协同处理的团队范围。判定依据写具体对象，例如“影响结算模块与对账模块”“涉及下单到支付的成功路径”“需要财务系统团队配合修改”。影响面可以分三档：单模块内、跨模块但限于本团队、跨团队或涉及核心用户路径。分档标准写进分类表，判定时对照填写。
偿还紧迫度
紧迫度分三档即可：高、中、低。高的判定依据是已经造成线上问题、阻塞当前迭代交付或存在明确合规期限；中的判定依据是预计在下个季度内会阻碍计划中的需求；低的判定依据是当前无已知触发场景，仅作为长期改进项。分档依据要写成可核对的事实，例如关联的线上问题编号、被阻塞的需求单号。
偿还成本
成本同样分三档：小、中、大。小的判定依据是单个迭代内可由一名成员完成且不需要跨团队协调；中的判定依据是需要专门排期、涉及多个模块但团队内部可完成；大的判定依据是需要跨团队协作、涉及数据迁移或架构调整。成本估算允许粗粒度，但估算依据要记录，例如“涉及三个服务改造，预计需要一次联合发布”。
分类操作步骤：从识别到登记
分类动作嵌入既有研发节点执行，不另设独立会议。每个节点给出触发条件、分类动作和输出，保证分类有稳定的输入来源。
识别入口与触发条件
- 需求评审：当需求实现需要绕开既有设计约定，或评审中发现某模块难以支撑新需求时，触发识别。
- 迭代回顾：当团队讨论到反复出现的返工、延期原因时，触发识别。
- 技术评审：当设计评审发现依赖方向异常、测试缺口或文档缺失时，触发识别。
- 线上问题复盘：当问题根因指向代码结构、测试覆盖或环境缺陷时，触发识别。已确认的功能 Bug 按缺陷管理流程处理，不进入技术债分类。
分类动作
识别到候选条目后，由提出人按维度表逐项判定，每个维度填写取值和一句判定依据。判定依据要能让另一位成员对照代码或记录复核。四个维度判定完成后，提出人补充债务描述和位置信息，提交登记。
登记字段
| 字段 | 填写要求 |
|---|---|
| 描述 | 一句话说明问题是什么、造成什么影响 |
| 位置 | 模块、服务、文件或环境的具体指向 |
| 维度取值 | 类型、影响面、紧迫度、成本四项取值 |
| 判定依据 | 每个维度一句可核对的事实 |
| 责任人 | 负责跟进该条目的成员 |
| 复核时间 | 下次复核该条目的日期 |
完成标志
条目完成的标志是：另一位成员仅依据登记记录，能复现相同的四个维度取值。如果复核人对某个维度取值有异议，说明判定依据不够具体，应补充依据或调整取值定义，而不是口头解释后放过。
条目积累后需要统一存放和分派。ONES 的工作项与文档能力可以承载这类记录：把技术债作为独立工作项类型登记字段，用状态区分待复核、已确认、已排期和暂缓，责任人字段承接分派，复核时间进入提醒。这样分类结果与排期、评审记录在同一处关联，减少散落在个人笔记中的情况。
角色分工与各环节交付物
分类要持续运转，需要明确谁提出、谁判定、谁复核、谁使用。下表给出常见分工，团队可按规模调整，但复核角色应与提出角色分离。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 开发成员 | 在日常开发和评审中识别候选条目，完成初步判定 | 带判定依据的债务登记条目 |
| 技术负责人 | 复核维度取值与判定依据，裁定分歧，维护维度表 | 复核结论、维度表修订记录 |
| 产品/项目角色 | 提供影响面中的用户路径信息，确认紧迫度中的业务期限 | 影响面与紧迫度的业务侧依据 |
| 排期或预算决策者 | 使用分类结果做偿还排序和资源分配 | 排期结论、预算申请材料 |
复核节奏建议与迭代节奏对齐：每个迭代回顾时集中复核新增条目和到期条目，技术负责人主持，重点检查判定依据是否充分、取值是否一致。复核结果直接更新条目状态，过期未复核的条目在下次回顾中优先处理。
分类结果向排期流转时，交接物是按紧迫度和成本排序的条目清单，附影响面说明；向预算申请流转时，交接物是按类型和成本归并的批次说明；向风险上报流转时，交接物是影响面为跨团队或核心路径的高紧迫度条目清单。三种交接物都来自同一份登记数据，避免重复整理。
示例：一条技术债如何完成分类与登记
以下为演示情景，用于说明判定依据的写法。
背景与识别来源：某团队在需求评审中讨论新增发票类型，发现开票逻辑分散在订单服务和结算服务两处，新增类型需要改两个地方并手工对齐。该问题在需求评审中触发识别，提出人登记为候选条目。
逐项判定：
- 债务类型：代码结构。依据：开票金额计算逻辑在订单服务与结算服务各有一份实现，两处规则已出现一处差异。
- 影响面：跨模块但限于本团队。依据：涉及订单与结算两个模块，影响开票相关用户路径，无需其他团队配合。
- 偿还紧迫度：中。依据：下一次新增发票类型的需求预计在下个季度进入排期，届时两处逻辑需同步修改。
- 偿还成本：中。依据：需要抽取公共计算逻辑并改造两个服务的调用点，团队内部可完成，需专门排期一次联合发布。
登记与流转：条目登记描述、位置、四项取值、判定依据、责任人和复核时间。复核时技术负责人确认取值与依据一致，条目状态更新为已确认。由于紧迫度为中、成本为中，该条目进入下季度排期候选清单，与新增发票类型需求一并评估；若下季度需求推迟，复核时调整紧迫度取值并记录调整依据。
分类质量的完成检查
分类机制是否真正运转，可以用下面四项检查逐条核对。建议每个季度执行一次，检查结果作为维度表和流程调整的输入。
- 一致性检查：抽取若干条同类债务，请两位未参与登记的成员独立分类，比较结果是否一致。不一致时回到判定依据，补充可观察事实或细化取值定义。
- 可追溯检查：逐条确认登记条目是否包含四个维度的判定依据和责任人。缺少依据的条目退回补充，不允许只留结论。
- 时效检查：核对复核时间是否按期执行，过期条目是否已处理。连续过期说明复核节奏与团队实际节奏不匹配，应调整复核周期或合并到固定节点。
- 使用检查：核对分类结果是否实际影响了排期、预算或风险上报。可以查看排期清单中的条目是否来自登记表、预算材料是否引用了分类批次。若分类结果长期未被使用，应回到分类目的说明，删减不改变决策的维度。
四项检查都通过，说明分类已经形成从识别、判定、复核到使用的闭环；某一项反复不通过时，优先修该环节的输入和交付物，而不是增加更多维度或流程步骤。
常见问题
技术债分类需要一开始就做得很细吗？
不需要。分类粒度应跟随当前要支撑的决策：如果主要用途是偿还排序，维度可以细到模块或用户路径；如果主要用于预算申请，粗粒度归并成批次即可。建议先用四个维度跑一到两个迭代，观察分类结果是否真的影响了排期或预算，再决定是否增加取值档位。维度越多，判定成本和分歧也越高。
同一条债务在不同人眼里类型不同，怎么处理？
先回到判定依据，而不是争论结论。让持不同意见的两人各自写出依据指向的代码位置、调用关系或记录，对照维度表中的判定标准重新判定。如果依据都成立但取值仍不同，说明该维度的取值定义存在重叠，应在复核时修订维度表，例如把两个相邻取值合并或补充边界说明。修订记录由技术负责人保存，后续条目按新定义执行。
分类结果登记后长期没人用，问题出在哪？
常见原因有两个：分类目的没有对应到具体决策，或者登记条目没有进入排期和预算的输入。可以先做使用检查，核对排期清单中的条目是否来自登记表、预算材料是否引用了分类批次。若确实未被使用，回到分类目的说明，删减不改变决策的维度，并把复核节奏与迭代回顾对齐，让分类结果在固定节点被消费，而不是停留在登记表里。
线上问题和功能 Bug 要不要进入技术债分类？
已确认的功能 Bug 按缺陷管理流程处理，不进入技术债分类。线上问题复盘时，如果根因指向代码结构、测试覆盖或环境缺陷，可以由复盘参与者登记为技术债候选条目，按四个维度判定。这样缺陷修复和技术债偿还各自走对应流程，避免同一问题在两套清单中重复跟踪。
团队规模较小，角色分工可以简化吗？
可以合并提出和初判的角色，但复核角色建议与提出角色分离，哪怕由另一位成员兼任。小团队可以把复核并入迭代回顾，由技术负责人或轮值成员主持，重点检查判定依据是否充分。产品/项目角色的业务侧依据如果暂时缺位，紧迫度中的业务期限可以先由提出人标注来源，复核时再确认，避免因角色不全而跳过分类。
