技术债治理

能力定位

技术债不是“看着不顺眼的代码”，而是当前设计与未来要求之间已经产生、或即将产生的可解释代价。本能力将口头抱怨、注释、事故和重复劳动转成可追踪台账，并帮助团队决定偿还、控制、接受还是淘汰。

它侧重治理与优先级，不替代具体代码审查、缺陷修复或架构设计。首轮默认只读，不因发现问题就擅自重构。

快速导航

• 接手陌生老项目：先读 发现与证据清单。
• 已有很多债项、不知道先做什么：使用 分级与偿还策略。
• 只有一句“这里以后要改”：补齐上限、触发器和退出路径后再入账。
• 紧急线上故障：先按事故流程恢复服务，技术债登记放在复盘阶段。

新手30秒入门

提供仓库或模块范围、最近困扰、业务时间点和本轮是否只审计。例如：“审计支付服务近半年累积的技术债，只输出台账；双十一前只能安排两周，优先降低发布与回滚风险。”

首轮交付 债务地图：证据来源、候选债项、影响链、置信度、紧迫度和需要补充的数据。未经确认的猜测不会直接进入正式清单。

功能索引

标准工作流

1. 明确治理边界

写清系统、模块、时间窗口、业务节点和允许读取的材料。区分只读审计、规划和获准实施三种模式；默认不改代码、不改工单、不指派人员。

2. 多源发现

搜索待办注释、临时开关、废弃接口、重复实现、单一实现的抽象、长期跳过的测试和手工发布步骤；同时结合事故、回滚、缺陷、变更失败和新人上手反馈。发现方法见 发现与证据清单。

3. 建立债项卡

每项必须写：位置、现状、形成原因、当前收益、已知代价、影响对象、证据、上限、触发器、退出路径和负责人角色。只有“不优雅”且没有可观察代价的内容标为改进建议，不冒充技术债。

4. 合并根因，拆开症状

多个告警可能由同一根因造成，一个“大重构”也可能包含多个独立风险。按可单独决策、可单独验证、可单独回退的粒度切分，避免一条台账覆盖半个系统。

5. 评估暴露面

从发生概率、影响强度、触发频率、变化速度和不可逆性评估风险；再估算偿还成本、机会成本和可获得收益。数字缺证据时使用区间与置信度，不伪造精确分数。

6. 选择处置方式

四种动作分别是：立即止血、分段偿还、接受并设护栏、随系统退休。不是每笔债都值得偿还；临近下线的模块通常只需控制风险和保留退出条件。

7. 排入真实交付节奏

优先把债务动作绑定到即将修改的功能、事故整改、依赖升级或容量节点，减少纯清债大项目。高风险债项若不能立即解决，先加观测、限流、测试或回滚护栏。

8. 定义关闭证据

“代码已重构”不是完成。关闭条件应对应原代价，例如变更时间下降、失败率降低、删除依赖、恢复演练通过或新人操作步骤减少，并保留前后基线。

9. 定期复查台账

到达触发器、负责人变化、系统边界变化或债项过期时复查。长期没有触发器、没有负责人或没有证据更新的债项应重新确认、拆分或关闭，而不是永久堆积。

输出规范

默认输出：范围与模式、证据目录、债务地图、债项台账、优先级理由、本期动作、护栏、关闭标准、待决策项。每项标注 已证实 / 高概率 / 待验证。

台账字段至少含 ID、位置、类型、代价、证据、上限、触发器、动作、负责人角色、目标窗口、关闭证据。排序必须给出理由，不只给一个神秘分数。

能力边界

• 不把功能缺陷、安全漏洞和性能事故统一降格为技术债；它们可能需要立即进入专门流程。
• 不把代码行数多、技术栈旧或个人不喜欢当成充分证据。
• 不在只读审计中改代码、创建工单、指派负责人或承诺排期。
• 不以“大重写”作为默认答案；必须比较渐进改造、护栏和退役方案。
• 不把作者或提交者等同于债务责任人，避免用历史归责代替系统治理。

稳定性保障

债项引用稳定位置、提交或工单，并记录首次发现和最近复查时间。对自动扫描结果进行人工语境复核；生成代码、测试夹具和兼容层不因“重复”自动判债。

每个偿还任务都要有最小可回退边界和验证基线。若范围持续膨胀，退回债项卡重新切分，不让治理活动变成无止境重构。

深度定制

单体系统可按模块和发布路径治理；微服务关注跨服务契约、共享库和级联故障；数据平台关注口径漂移、补数与血缘；移动端关注版本碎片和兼容窗口；AI 系统关注提示、模型、评测集与数据版本耦合；遗留系统关注知识集中和不可复现操作。

FAQ

待办注释都是技术债吗？ 不是。只有明确产生代价、风险或未来约束的项才进入台账。

技术债越少越好吗？ 不是。为了验证市场而有意识借债可能合理，关键是上限、触发器和退出路径清楚。

怎么说服业务排期？ 用交付延迟、故障、人工成本和机会窗口说明影响，不用“代码洁癖”做理由。

能自动算出优先级吗？ 可以辅助排序，但输入常含不确定性，最终需要业务与工程共同确认。

反模式与修正

按需 references

发现与证据清单 用于系统盘点和去误报；分级与偿还策略 用于确定动作、窗口和关闭标准。