AI 辅助技术债识别与治理

技术债是指为求快速交付而欠下的代码质量账单：今天省下的设计、测试与清理，明天要以更高的维护成本连本带利偿还。随着 AI 编码助手普及，代码产出速度变快，技术债的累积也更快。好消息是，AI 同样擅长「读代码、找坏味、出方案」，可以反过来成为治理技术债的杠杆。本文先厘清技术债的类型，再给出用 AI 做静态嗅探与重构规划的落地方法，最后梳理工具链。

技术债有哪些类型

想治债，先要能认债。工程实践中最常见的几类技术债如下。

代码坏味

代码坏味（code smell）是不一定出错、但暗示设计出了问题的信号。典型包括过长函数、过大类、过度耦合、霰弹式修改（一个需求改动散落多处）、发散式变化（一个类因多种原因被改动）、临时字段、基本类型偏执等。坏味本身未必是 bug，却是后续缺陷与维护成本的温床。

重复代码

同一段逻辑在多处拷贝粘贴，是技术债里最容易被 AI 抓到的一种。重复意味着：改一处要同步改 N 处，漏改就是 bug；语义一旦漂移，行为就会出现微妙分歧。重复分三类：完全相同的拷贝、结构相同但变量名不同的近似重复、逻辑等价但写法不同的重复。

复杂度过高的函数

一个函数承担太多职责、嵌套过深、分支过多，圈复杂度（cyclomatic complexity）偏高，测不动也改不动。这类函数往往是缺陷高发区，也是重构的第一优先目标。可用「函数长度、嵌套深度、参数个数、分支数」四个粗略指标快速筛出候选。

测试缺失

没有测试覆盖，或者只有 happy path 没有边界与异常路径，意味着任何改动都在「盲飞」。测试缺失是一种隐性技术债：它不立刻报错，却让后续每次重构都风险陡增。对 AI 生成的代码尤其要注意，模型可能给出「高覆盖率、低有效性」的弱测试。

依赖陈旧

第三方库长期不升级，会累积安全漏洞、兼容风险与迁移成本。越拖越难升，最终被迫一次性大版本跳跃，对业务是高风险事件。依赖陈旧既是安全问题，也是典型的时间型技术债。

下表给出每类债务的常见信号与快速识别方式：

类型	常见信号	快速识别方式
代码坏味	过长函数、过大类、霰弹式修改	按函数/类行数排序，人工巡览
重复代码	相似片段多处出现	相似度检测、AI 读 diff 比对
复杂函数	嵌套深、分支多、参数多	圈复杂度扫描、AI 评估可读性
测试缺失	改动无测试、仅 happy path	覆盖率报告、AI 审查用例完整度
依赖陈旧	锁文件版本落后、有 CVE	依赖审计、AI 比对最新版本

用 AI 做静态嗅探

传统静态分析工具靠规则，能抓到明确违例；AI 的优势在于「读得懂意图」，能发现规则抓不到的设计层坏味，并给出可操作的重构建议。核心做法：把一段 diff 或某个模块丢给 LLM，明确要求它扮演资深 reviewer，逐项指出坏味与改进方向。

Prompt 思路

给 AI 嗅探时，比「帮我看看这段代码」有效的写法，是明确维度、明确输出格式、限定只报真问题。建议遵循四条原则：

指定视角：你是资深工程师，专注可维护性而不是纯风格。
给出范围：只针对提供的 diff 或指定文件，避免泛泛而谈。
要求结构化输出：每条给出「位置、类型、为什么、建议」。
要求可执行：建议要具体到重构手法，而非口号。

最小示例：嗅探一个坏味函数

假设仓库里有这样一个 Python 函数，用一长串 if 判断订单折扣，职责很重：

def calc_discount(order):
    # 这里集中了会员、促销、节日三类规则
    if order.user.level == "vip":
        rate = 0.8
    elif order.user.level == "svip":
        rate = 0.7
    else:
        rate = 1.0
    if order.promo and order.promo.code == "SUMMER":
        rate = rate * 0.9
    if order.festival:
        rate = rate * 0.95
    if order.amount > 1000:
        rate = rate * 0.9
    return order.amount * rate

把这段连同下面的提示词一起发给 LLM：

你是资深 Python 工程师。请审查以下函数 calc_discount。
只报告影响可维护性与正确性的设计问题，忽略纯风格偏好。
逐条给出：位置（函数名/行号）、问题类型、为什么是问题、具体重构建议。
最后给出一个重构后的函数骨架（用策略模式拆分折扣规则）。

LLM 通常会指出：单函数承担多类规则（违反单一职责）、魔法字符串、难以单测、新增规则要改同一函数。它会建议把折扣规则抽象成一组可组合的策略对象，使每种规则独立、可测、可扩展。

最小示例：读 diff 比读全文更省

对日常治理，更实用的入口是「读 diff」。把一次 PR 的 diff 贴给 AI，让它聚焦本次引入的坏味，而不是整个文件历史：

你是技术债审查员。阅读下面这段 git diff。
找出本次改动引入或加剧的技术债：重复代码、复杂函数、坏味、测试缺口。
对每条给出：文件:行号、债务类型、严重程度（高/中/低）、一句话建议。
不要修改代码，只输出清单。

对 Java 这类强类型代码，也可以让 AI 顺带评估复杂度。例如下面的方法嵌套了多层循环与条件，可读性与可测性都差：

public List<String> findActiveEmails(List<User> users) {
    List<String> result = new ArrayList<>();
    for (User u : users) {
        if (u != null && u.isActive()) {
            if (u.getEmail() != null && u.getEmail().contains("@")) {
                if (!u.getEmail().endsWith("@test.com")) {
                    result.add(u.getEmail());
                }
            }
        }
    }
    return result;
}

给 AI 同样的审查提示词，它会指出：空值判断与邮箱校验可以抽成谓词、多层 if 可换成流式过滤、方法名与返回值语义不匹配（返回 email 却叫 findUsers）。这类「读得懂意图」的判断，正是规则型 linter 的盲区。

嗅探原则：让 AI 当第一道滤网，先产出「债务清单 + 严重程度」，再由人决定先还哪一笔。AI 的产出是线索，不是判决。

用 AI 规划重构

嗅探出债务后，真正的难点是「怎么还而不引入新 bug」。AI 在规划重构上有三个可落地抓手：分批、保持行为等价、补测试。

分批推进，优先还高息债

不要一次性大扫除，那会制造巨大 review 面与回归风险。让 AI 把债务按「影响面、使用频率、改动成本」排序，给出分批路线图：

根据上面的债务清单，请排一个重构路线图。
规则：一次 PR 只还一类债，优先高使用频率且高严重度的项。
每一步给出：目标文件、改动范围、预计影响、需要补的测试、验收标准。
输出一个最多五步的序列，每步可独立合并。

这样保证每步都小、可测、可回滚，review 成本可控。

保持行为等价

重构的第一铁律是「外部行为不变」。让 AI 在动手前先写下「行为契约」：哪些输入输出必须保持，哪些属于可变的内部实现。可以这样要求：

重构前，先列出该函数的可观测行为契约：
输入域、边界条件、输出与副作用、异常情况。
重构后必须逐项保持等价。不要顺手改业务规则。

行为等价是后续补测试的依据，也是防止「重构顺便改需求」的护栏。

先补测试，再动手

对没有测试的函数，正确的顺序是「先补测试覆盖当前行为，确认绿灯，再重构，再保证仍绿灯」。把测试缺失的债和函数本身的债一起还：

为 calc_discount 先补 pytest 用例，覆盖：会员/普通用户、促销码、
节日标志、满减阈值、组合情况、空值。
运行确保全绿后再给出重构版本，并证明重构后用例仍全绿。

这一步把「测试缺失」和「复杂函数」两笔债一起清掉，且让重构有安全网。

一个可复用的重构循环

把上面三步串成固定循环，比零散指令更稳：

AI 嗅探：产出债务清单与严重程度。
人定优先级：挑一笔高息债。
AI 写行为契约 + 补测试（红灯确认现有行为）。
AI 重构，保持契约等价，测试仍绿。
人 review diff，合并，记录还债进度。

规划原则：AI 负责出方案与写代码，人负责定优先级与拍板合并。重构的风险控制永远留在人手里。

工具链

下面三类工具可单独使用，也可与 AI 助手组合，形成「自动嗅探 + 人工决策 + AI 辅助还债」的闭环。

SonarQube（静态分析平台）

SonarQube 是成熟的静态代码分析平台，可持续扫描代码库，检测 bug、漏洞、安全热点与代码坏味，并以 Clean Code 视角对问题分级。它支持多语言，能集成进 CI，把质量门禁（Quality Gate）作为合并门槛。对技术债治理，它的价值在于「常态化、可追溯、可量化」——让债务以指标形式持续可见。（能力描述，官方文档已核验）

CodeScene（行为化代码健康）

CodeScene 不做传统规则扫描，而是结合版本控制历史做行为化分析（behavioral code analysis）：它识别「频繁改动且复杂度高」的热点（hotspot），用 CodeHealth 指标预测缺陷与交付风险，并提供 PR 门禁与 refactoring agent。在 AI 编码普及后，CodeScene 还提出用 CodeHealth 作为 AI 生成代码的护栏，在合并前守住健康度下限。（能力描述，官方网站已核验）

各类 AI 代码助手

主流 AI 代码助手（如 GitHub Copilot、Cursor、各类 IDE 内联助手）已内建代码审查能力。以 GitHub Copilot 为例，它可作为 reviewer 自动审查 PR，给出包含建议修改的评论，并支持 Lite / Balanced 两档审查力度，还能通过 copilot-instructions.md 与 AGENTS.md 加载团队规范，使审查更贴合项目约定。这些助手适合做「随写随审」的轻量嗅探，与 SonarQube/CodeScene 的常态化扫描互补。（能力描述，GitHub 文档已核验）

组合建议

常态化层：SonarQube / CodeScene 进 CI，给出持续指标与门禁。
随写随审层：AI 助手在 PR 阶段做意图级嗅探与建议修改。
还债层：按本文的重构循环，用 LLM 分批规划、补测试、保持等价。

小结

技术债有五类典型形态：代码坏味、重复代码、复杂函数、测试缺失、依赖陈旧，先能认债才能治债。
用 AI 做静态嗅探时，应限定视角、范围与输出格式，读 diff 比读全文更省、更聚焦。
AI 的优势在「读得懂意图」，能发现规则型 linter 抓不到的设计层坏味并给出重构手法。
重构规划要分批推进，优先还高使用频率且高严重度的「高息债」，每步可独立合并。
保持行为等价是重构铁律：先写行为契约与补测试，再动手，让测试成为安全网。
工具链上，SonarQube/CodeScene 做常态化扫描与门禁，AI 助手做随写随审，三层互补。

参考与延伸阅读

SonarQube 官方文档（静态分析、代码坏味、Clean Code 与质量门禁能力，已核验）：https://docs.sonarsource.com/sonarqube/latest/
CodeScene 官方网站（CodeHealth、行为化热点分析、AI 代码护栏与重构代理，已核验）：https://codescene.com/
GitHub Docs，Using GitHub Copilot code review（PR 自动审查、建议修改、Lite/Balanced 力度、自定义指令，已核验）：https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review
Martin Fowler，《Refactoring: Improving the Design of Existing Code》（代码坏味与重构手法的经典源头，待核实）：https://martinfowler.com/books/refactoring.html
Adam Tornhill，《Software Design X-Rays》（行为化代码分析、热点与社会学视角的技术债，待核实）：https://www.adamtornhill.com/books.htm
延伸阅读：将本文「AI 嗅探 + 分批重构 + 补测试」循环，与 CI 中的 AI 代码审查工作流结合，参考本站「用 AI 做代码审查与测试」一文（待核实）。

本文累计阅读 — 次