技术债务治理和架构治理的边界，落在“决策对象”和“决策时点”上：架构治理决定系统结构与技术选型的方向，判断某项取舍该不该接受；技术债务治理把已经接受的取舍记录下来，评估影响、安排偿还并设定止损条件。两者在架构级技术债上重叠，但主责可以分开。下面给出可直接用于研发治理职责分工的定义、归属判定表和交接流程。
要点总览（TL;DR）
- 技术债务治理管“已接受的取舍”：登记、评估代价、安排偿还并设定止损条件；架构治理管“结构方向与技术选型”：评审、约束和演进决策。
- 区分口径看两点：决策对象是否涉及系统结构与技术选型，决策时点是在方案确定前判断“该不该欠”，还是落地后管理“欠账怎么处理”。
- 架构级技术债由两条线共管：架构治理决定是否接受及可接受程度，技术债务治理随后成为该条目的管理主责，负责登记、跟踪与偿还推进。
- 已确认的功能 Bug 归缺陷管理，不进入债务台账；代码规范检查、静态扫描告警等日常守门归代码质量管理，为前两条线提供度量输入。
- 衔接靠固定交接物：架构评审结论作为债务条目来源，台账记录来源决策、影响范围与偿还触发条件，偿还方案涉及结构调整时回流架构评审。
一句话划清：技术债务治理与架构治理各管什么
技术债务治理是对已知取舍的管理：团队为了短期交付目标，主动或被动接受了某种不理想的实现方式，治理工作负责把这类取舍记录清楚、评估代价、安排偿还，并在代价失控时止损。它关心的是“这笔债还在不在、值不值得继续背、什么时候还”。
架构治理是对结构方向的决策管理：系统如何分层、模块如何划分、关键技术选型如何确定、哪些约束必须遵守、架构如何随业务演进。它关心的是“方向对不对、约束合不合理、变更该不该批准”。
区分两者最实用的口径有两个。第一看决策对象：涉及系统结构、技术选型、跨模块约束的，归架构治理；针对某笔已发生取舍的记录、评估与偿还安排，归技术债务治理。第二看决策时点：在方案确定之前判断“要不要这样欠”，属于架构治理；在方案落地之后管理“这笔欠账怎么处理”，属于技术债务治理。同一件事可能先后经过两条线，但每个时点的主责是明确的。
制定职责分工时，可以把这句话写进治理制度：架构治理对“是否接受某项结构性取舍”负责，技术债务治理对“已接受取舍的登记、评估、偿还与止损”负责。
边界落在哪里：四类事项的归属判定
实际分工争议多发生在具体事项上。用两个维度判断：该事项是否涉及结构方向决策，该事项是否已形成已知取舍。据此可把常见治理事项归入四条线。
| 事项类型 | 典型例子 | 是否涉及结构方向决策 | 是否已形成已知取舍 | 归属与主责 |
|---|---|---|---|---|
| 架构方向决策 | 服务拆分方案、数据库选型、跨系统集成方式 | 是 | 尚未形成，处于方案评审阶段 | 架构治理主责，输出决策结论与约束 |
| 架构级技术债 | 为赶版本采用临时集成方案、绕过既定分层直接调用 | 是 | 是，取舍已发生 | 架构治理判定是否接受及可接受程度，技术债务治理登记并推动偿还 |
| 局部实现债务 | 某模块内为赶工期写的重复逻辑、临时开关 | 否 | 是 | 技术债务治理主责，涉及结构调整时提请架构评审 |
| 日常质量守门 | 代码规范检查、静态扫描告警、单测覆盖率 | 否 | 否，属于持续度量 | 代码质量管理主责，为前两条线提供输入 |
| 已确认功能错误 | 线上功能不符合预期、逻辑错误 | 否 | 否，属于缺陷 | 缺陷管理主责，不进入债务台账 |
架构级技术债的双重归属需要一条主责规则：架构治理对“该不该欠、欠到什么程度”做决定，决定一旦作出，技术债务治理即成为该条目的管理主责，负责登记、跟踪和偿还推进。判断主责时可以问一句：当前要解决的是“方向选择”还是“欠账处理”。前者由架构负责人牵头，后者由技术债 owner 牵头。
已确认的功能 Bug 归缺陷管理，按缺陷流程修复和验证，不写入债务台账。把 Bug 混入债务台账会让债务规模失真，也会让缺陷修复的时效要求被债务排期稀释。代码规范、静态扫描告警等日常守门工作归代码质量管理，它持续产出度量数据，供架构治理和技术债务治理判断趋势，但不承担“是否接受某笔取舍”的决策。
两者如何衔接：从架构决策到债务偿还的连续流程
边界划清后最容易出现断点：架构评审会上同意了临时方案，散会后无人登记；或者债务台账里躺着一笔条目，却没人判断偿还方案是否改变结构。衔接流程要固定交接物和交接时点。
第一步，架构评审识别取舍。评审结论中明确写出：采用了什么临时方案、绕过了哪条架构约束、预期影响范围、计划何时重新评估。这份结论就是债务条目的来源。
第二步，登记为技术债条目。台账至少包含以下字段：来源决策（对应哪次架构评审结论）、影响范围（涉及哪些系统、模块或接口）、当前代价（维护成本、变更阻力、故障风险）、偿还触发条件（例如相关模块下次大改、性能指标跌破阈值、季度治理窗口）、owner 与计划偿还时间。
第三步，按触发条件推进偿还。技术债 owner 在触发条件满足时发起偿还评估，形成偿还方案。方案只涉及局部替换或清理的，由研发团队按常规排期执行；方案涉及结构调整、技术选型变更或跨模块约束调整的，回流架构评审，由架构治理重新决策后再执行。
角色交接物可以这样约定：架构负责人交付评审结论与约束说明；技术债 owner 交付台账条目、偿还方案与关闭结论；研发团队交付实现结果与验证记录。每次交接都以文档状态变化为标志，避免口头约定。
在工具承载上，这类交接需要把架构决策记录、债务台账条目和偿还任务关联在同一条链路上。ONES 可用于承载架构决策记录与债务条目，并把偿还任务关联到具体工作项，使来源决策、影响范围和偿还进度可以对照查看；具体字段与流程配置按团队实际治理制度设定。
容易混淆的相邻概念：与代码质量管理、缺陷管理的区别
代码质量管理关注守门与度量：规范是否被遵守、扫描告警是否清零、覆盖率是否达标。它回答“当前代码健康度如何”，不回答“某笔取舍是否值得接受”。当扫描发现一处复杂度过高的模块时，代码质量管理负责报告问题，是否将其认定为债务、是否安排偿还，由技术债务治理判断。
缺陷管理处理已确认的功能错误：功能不符合预期、逻辑错误、线上故障。它回答“哪里坏了、怎么修好”，与“为换取交付速度而主动接受的取舍”是不同性质的决策。缺陷修复有明确的时效和验证要求，债务偿还有触发条件和排期弹性，两者混在一起会同时削弱两种管理的严肃性。
四者的输入输出关系可以概括为：代码质量管理持续输出度量与告警，作为技术债务治理识别债务来源和架构治理评估结构风险的输入；缺陷管理输出缺陷分布与根因，帮助判断某些债务是否已转化为实际故障风险；技术债务治理输出债务台账与偿还状态，架构治理据此评估架构演进节奏；架构治理输出决策与约束，反过来约束代码质量管理的检查规则。
具体例子：一次架构简化如何走完两条治理线
以下为演示情景。某团队为赶一个重要版本，决定在新业务模块中直接调用另一系统的数据库表，跳过既定的服务接口层。这个决定在版本评审会上被提出并获准，条件是版本上线后三个月内完成接口化改造。
架构治理侧的动作是：评审会记录该取舍绕过了接口层约束，明确可接受的时间窗口和影响范围，给出改造方向，并将结论归档为架构决策记录。这一步回答的是“该不该欠、欠多久”。
技术债务治理侧的动作是：依据该决策登记债务条目，写明来源决策、影响范围（涉及两个系统的表结构与权限）、偿还触发条件（三个月到期或相关表结构变更时提前触发）、owner 和计划偿还时间。三个月内，owner 按触发条件发起偿还，形成接口化改造方案。由于方案涉及服务边界调整，回流架构评审确认接口契约后再实施，完成后关闭债务条目并更新决策记录状态。
这个情景里有两个常见误解需要纠正。其一，把技术债务治理等同于重构排期：排期只是偿还环节的一部分，治理还包括登记、评估、触发条件设定和止损，缺少这些环节，重构排期就失去依据。其二，把架构治理等同于架构图评审：画图和审图只是表达与检查手段，架构治理的实质是对结构方向和技术选型作出可追溯的决策，并约束后续变更。把这两点写进职责说明，两条治理线才能在同一个事项上各司其职、顺畅交接。
常见问题
架构级技术债由谁牵头，评审会上已经同意临时方案后该做什么？
评审会上同意临时方案，属于架构治理的决策动作，结论应写明采用了什么临时方案、绕过了哪条约束、影响范围和重新评估的时间点。会议结束后，技术债务治理即接手该条目：按评审结论登记债务条目，补齐来源决策、影响范围、当前代价、偿还触发条件、owner 和计划偿还时间。此后跟踪与偿还推进由技术债 owner 牵头，架构负责人保留对偿还方案中结构变更的决策权。
债务台账里的一笔条目，什么情况下需要重新走架构评审？
判断标准是偿还方案是否改变结构方向。只涉及局部替换、清理或参数调整的方案，由研发团队按常规排期执行即可；方案涉及服务边界调整、技术选型变更、跨模块约束修改时，应回流架构评审，由架构治理重新确认方案后再实施。把这条条件写进台账字段，可以避免技术债 owner 在偿还过程中自行作出架构级决定。
线上功能错误是否应该记入技术债务台账？
已确认的功能错误按缺陷管理流程处理，修复和验证有明确的时效要求，不写入债务台账。债务条目对应的是“为换取交付速度而接受的取舍”，与“功能不符合预期”是不同性质的决策。把 Bug 混入台账会让债务规模失真，也会让缺陷修复的时效被债务排期稀释。缺陷分布和根因分析可以作为输入，帮助判断某些债务是否已转化为实际故障风险。
团队规模较小、治理角色由同一人兼任时，边界划分还有意义吗？
有意义，但落地方式可以简化。角色兼任时，边界的作用从“分人”转为“分决策记录”：同一人在方案确定前作出“是否接受取舍”的判断，应留下架构决策记录；方案落地后登记债务条目，写明偿还触发条件。两类记录分开保存，可以在后续复盘时区分“当初为什么这样决定”和“这笔欠账处理到哪一步”。团队规模扩大或治理成熟度提高后，再按记录类型拆分职责即可。
代码质量管理已经持续报告高复杂度模块，还需要技术债务治理介入吗？
需要，两者输出不同。代码质量管理回答“当前代码健康度如何”，持续产出扫描告警和度量数据；是否把某个高复杂度模块认定为债务、是否安排偿还、偿还的优先级如何，属于技术债务治理的判断。可以约定一条衔接规则：当某模块的度量指标连续多个周期恶化，或已阻碍变更交付时，由技术债务治理评估是否登记为债务条目，并设定偿还触发条件。
