技术债分类是把团队为赶进度或取巧而留下的、未来需要额外投入才能偿还的工程欠账，按成因、可见程度、影响范围和偿还紧迫性归入不同类别，以便决定先还哪一笔、由谁负责、何时偿还。分类的对象是工程决策留下的欠账，输出应是一份可排序、可指派、可跟踪的治理清单，而不是给代码贴标签。
要点总览（TL;DR）
- 技术债分类是把团队为赶进度或取巧而延迟的必要投入，按成因、可见度、影响范围和偿还紧迫性归入不同类别，输出一份可排序、可指派、可跟踪的治理清单。
- 已确认的功能 Bug 归缺陷管理，需求变更导致的返工归范围管理，两者都不进入技术债清单；技术债强调主动取舍与延迟偿还。
- 常用维度可以组合使用：成因分有意债与无意债，可见度分显性债与隐性债，影响范围分代码级、架构级、流程与文档级，紧迫性分需排期偿还与可观察偿还。
- 分类结果要落到优先级、责任角色和偿还窗口，并映射到工作项状态，才能跟踪偿还进度。
- 常见误解包括把遗留代码都当技术债、要求全部立即偿还、把登记债务视为能力不足；登记是对取舍的如实记录。
技术债分类到底分的是什么
技术债借用了金融里的借贷关系：团队在当下选择了一种更省事、更省时的做法，把成本推迟到未来，未来需要以额外投入的形式偿还。这里的“省”可能是少写一层校验、少做一次抽象、跳过一轮文档更新，也可能是明知方案不理想但为了赶节点先上线。债务成立的关键在于“主动或被动地延迟了必要投入”，并且这笔延迟会在后续开发、维护或变更中产生可感知的额外成本。
分类的对象是工程决策留下的欠账，而非所有代码问题。一段代码写得不够优雅、命名不够清晰，如果没有对应的决策背景和未来成本，它只是一个待改进点，不构成需要登记和排序的技术债。判断一笔债务是否成立，通常看三个要素：当时是否存在可替代的更优做法；团队是否知情地选择了当前做法；未来是否因此需要额外投入。三者齐备，才值得进入分类清单。
分类的输入是散落在代码评审、架构讨论、故障复盘和日常开发中的取舍记录，输出则是一份治理清单。这份清单至少应包含：债务描述、所属类别、影响范围、预估偿还成本、责任角色和建议偿还窗口。清单的价值在于可排序、可指派、可跟踪——能回答“先还哪个”“谁来还”“什么时候还”这三个问题。缺少其中任何一项，分类就容易退化为一份无人认领的问题列表。
技术债的边界：哪些问题不算技术债
把边界划清，分类才有意义。技术债强调主动取舍与延迟偿还，它与被动发现的故障、外部输入引起的变更、以及日常的代码优化任务在管理路径上并不相同。已确认的功能 Bug 归缺陷管理，按缺陷的严重程度和修复流程处理；需求变更导致的返工属于范围管理问题，应回到需求评审和变更控制中解决；普通重构任务如果没有对应的债务背景，按常规工程任务排期即可。
下面的边界表给出常见的纳入与不纳入判断，供登记时对照使用。
| 问题类型 | 是否纳入技术债清单 | 判断依据与归属 |
|---|---|---|
| 为赶版本临时绕过的鉴权校验 | 纳入 | 知情取舍、未来需补做，属于有意债 |
| 已确认的功能 Bug | 不纳入 | 归缺陷管理，按缺陷流程修复 |
| 需求变更引起的接口返工 | 不纳入 | 归范围管理，走变更评审 |
| 缺少自动化测试的核心模块 | 纳入 | 延迟投入的工程质量欠账 |
| 文档长期未更新导致交接困难 | 纳入 | 流程与文档级债务 |
| 命名不规范但无未来成本的代码 | 视情况 | 无决策背景时按普通改进项处理 |
边界判断需要保留一定的弹性。同一处问题在不同阶段可能改变归属：一个被临时绕过的校验，如果后来引发了线上故障，它既是一笔技术债，也产生了一个缺陷，两条路径应分别记录、分别跟踪，避免用缺陷流程掩盖债务，也避免用债务清单拖延故障修复。
常用分类维度：成因、可见度与影响范围
技术债的划分维度不止一种，常见的有成因、可见度、影响范围和偿还紧迫性四类。这些维度之间不互斥，一笔债务可以同时是有意债、隐性债、架构级债务，并且需要排期偿还。实际使用时通常选取两到三个维度组合，形成团队能理解、能执行的分类口径。
| 维度 | 类别 | 典型特征 | 适用场景 |
|---|---|---|---|
| 成因 | 有意债 | 团队知情地选择短期方案，留有偿还计划 | 版本冲刺、临时方案上线 |
| 成因 | 无意债 | 当时未意识到，事后才发现的欠账 | 知识不足、技术演进带来的过时设计 |
| 可见度 | 显性债 | 有明确记录，团队普遍知晓 | 评审记录、待办事项中的已知问题 |
| 可见度 | 隐性债 | 尚未被识别，潜伏在代码或流程中 | 依赖排查、故障复盘时逐步暴露 |
| 影响范围 | 代码级 | 局限在单个模块或函数 | 局部重构、单元测试补齐 |
| 影响范围 | 架构级 | 涉及模块边界、数据流、集成方式 | 架构评审、跨团队协作 |
| 影响范围 | 流程与文档级 | 涉及发布流程、规范、知识沉淀 | 交接、合规、新人上手 |
| 偿还紧迫性 | 需排期偿还 | 已影响交付或存在明确风险 | 纳入迭代计划，设定偿还窗口 |
| 偿还紧迫性 | 可观察偿还 | 暂不影响交付，持续观察 | 定期复查，条件成熟再处理 |
成因维度帮助团队区分“当时知道”和“当时不知道”，前者可以通过复盘改进决策，后者需要通过评审和排查提升识别能力。可见度维度提醒团队，隐性债往往比显性债更危险，因为没人认领也就没人偿还。影响范围维度决定偿还的组织方式：代码级债务通常由模块负责人处理，架构级债务需要跨角色协作，流程与文档级债务则往往落在团队规范和工具配置上。偿还紧迫性维度直接服务于排序，是分类走向治理的桥梁。
组合使用时，建议先按影响范围分组，再在组内按成因和紧迫性排序。这样既能保证架构级债务得到足够重视，也能避免大量代码级小债务淹没真正需要优先处理的事项。
分类之后怎么用：从标签到治理决策
分类结果要转化为治理决策，核心动作有三步：定优先级、定责任人、定偿还窗口。优先级由影响范围与紧迫性组合得出，影响面越大、越接近交付或风险敞口，优先级越高。例如架构级且需排期偿还的债务应优先进入迭代计划，代码级且可观察偿还的债务可以进入待办池定期复查。
责任人的指定应跟随债务的影响范围。代码级债务由模块负责人认领，架构级债务由架构角色牵头并明确协作方，流程与文档级债务由团队负责人或规范维护者负责。偿还窗口则需要与迭代节奏对齐：需排期偿还的债务给出目标迭代或时间范围，可观察偿还的债务设定复查周期，避免长期无人过问。
分类结果落到工作项状态，才能跟踪偿还进度。常见的状态流转是：已登记、已评估、已排期、偿还中、已关闭。每个状态对应明确的完成标志，例如“已评估”要求补齐影响范围和预估成本，“已关闭”要求验证债务确实消除并有记录。把债务当作普通工作项管理，可以让偿还进度和业务需求在同一视图中被看见，减少“永远排在需求后面”的情况。在 ONES 这类研发管理平台中，技术债可以作为工作项类型登记，配合状态流转、负责人字段和迭代关联，把分类清单变成可跟踪的治理对象；具体字段和流程配置需结合团队现有实践设定。
容易混淆的相邻概念
技术债与几个相邻概念经常被混用，区分它们有助于把问题送到正确的管理路径上。缺陷是已确认的功能不符合预期，按缺陷流程修复；重构是改善代码结构的手段，本身不是债务，而是偿还债务的方式之一；代码坏味道是识别信号，提示可能存在债务，但不等于已登记的技术债；架构演进是有计划的架构调整，可能顺带偿还债务，也可能引入新的取舍。
| 概念 | 核心含义 | 与技术债的关系 |
|---|---|---|
| 缺陷 | 功能不符合预期，已确认 | 归缺陷管理，不进入技术债清单 |
| 重构 | 不改变外部行为的前提下改善结构 | 偿还技术债的常用手段 |
| 代码坏味道 | 结构或写法上的可疑信号 | 识别线索，需评估后才登记为债务 |
| 架构演进 | 有计划的架构调整 | 可能偿还债务，也可能产生新债务 |
| 需求变更 | 外部输入引起的范围调整 | 归范围管理，返工不计入技术债 |
区分这些概念的实际意义在于分工。缺陷有明确的修复责任和时限，技术债需要排序和窗口；重构是手段，债务是对象；代码坏味道是线索，债务是结论。把线索当结论会让清单膨胀，把手段当对象会让治理失去焦点。
一个具体例子与常见误解
假设一个团队为赶版本上线，跳过了某个内部接口的鉴权校验，计划下个版本补上。这笔欠账在分类时可以这样登记：成因上属于有意债，团队知情并留有补做计划；可见度上属于隐性债，因为代码里没有明显标记，只有参与决策的人知道；影响范围上属于架构级，鉴权涉及接口边界和调用方；偿还紧迫性上属于需排期偿还，存在明确的安全风险。组合起来，它是一笔“有意、隐性、架构级、需排期”的债务，应指定架构角色牵头，在下一个迭代窗口内完成补做，并验证调用方全部覆盖。
这个例子也说明分类不是一次性动作。补做完成后，债务状态从“偿还中”转为“已关闭”；如果补做过程中发现其他接口存在同类问题，应作为新的债务登记，而不是并入原条目。
常见误解有三个。其一，认为所有遗留代码都是技术债。遗留代码只是存在时间较长的代码，只有具备决策背景和未来额外投入的欠账才构成债务，否则按普通改进项处理。其二，认为技术债必须全部立即偿还。债务的偿还取决于影响范围和紧迫性，可观察偿还的债务允许在条件成熟时处理，强行全部立即偿还反而会挤占业务交付。其三，认为登记技术债等于承认团队能力不足。登记是对取舍的如实记录，有意债本身就是一种管理选择，把选择记录下来并安排偿还，恰恰是工程成熟度的体现。
常见问题
技术债清单应该由谁维护，多久更新一次？
维护责任通常落在工程负责人或架构角色身上，由他们牵头汇总代码评审、架构讨论和故障复盘中出现的取舍记录。更新频率与迭代节奏对齐比较实用：每个迭代开始前复查一次清单，补充新登记的债务、调整优先级、确认已关闭条目。清单长期不更新，分类就会失去排序价值，退化为一份历史问题列表。
隐性债在登记前无法识别，怎么处理？
隐性债的识别依赖日常排查动作，可以在依赖升级、故障复盘、交接评审等场景中顺带检查，把发现的欠账补登记。登记时如果无法确认成因，可以先按影响范围和紧迫性归类，成因留待后续复盘补充。隐性债的风险在于没人认领，因此登记后应尽快指定责任角色，哪怕偿还窗口定得较远。
技术债的偿还成本怎么估算，需要精确到人天吗？
估算精度应与决策需要匹配。用于排序时，用相对量级（如小、中、大）即可区分先后；进入排期前再细化到可执行的粒度。估算时把验证和回归的成本一并考虑，避免只算改代码的时间。估算本身不必追求精确，重点是让不同债务之间可以横向比较。
同一处问题既是技术债又引发了缺陷，应该怎么记录？
两条路径分别记录、分别跟踪。缺陷按缺陷流程修复，解决当前的功能异常；技术债条目保留，记录当初的取舍背景和后续需要补做的投入。用缺陷流程掩盖债务，会让同类问题反复出现；用债务清单拖延故障修复，则会影响当前交付。分开记录可以让两类工作各自有明确的责任人和时限。
团队规模较小，是否也需要完整的技术债分类体系？
小团队可以简化维度，保留影响范围和紧迫性两个维度通常就够用，成因和可见度可以在复盘时口头讨论。关键是保留“可排序、可指派、可跟踪”这三个特征，哪怕清单只有十几条，也要有负责人和复查节奏。随着团队和系统规模增长，再逐步补充维度，不必一开始就追求完整的分类口径。
