AI辅助重构与优化：代码质量提升

CH-11-06-010·约 18 分钟·AI应用开发·更新 2026-08-11

想象你家的老房子住了十年：墙皮开裂、管线缠绕、客厅和厨房之间被一道多余的隔断切成两半，每次想挪张桌子都得绕一大圈。请一位经验丰富的老工匠来翻修，他能一眼看出哪些墙能拆、哪处渗水才是根源、哪笔修补再拖下去会越裂越大。AI 辅助代码重构，就是给软件团队请来这样一位「持证工匠」：它能嗅出代码里的坏味道，给出拆墙重排管线的具体方案，算出每笔改造的性价比，还始终守着「装修不能碰承重墙」的底线——优化结构，但绝不改变代码对外的行为。这篇内容，就带你看懂这位智能工匠的整套手艺：从识别异味、给出重构建议，到性能优化、复杂度治理、技术债务管理，直至把它装进团队的日常研发流程。

岗位关联

掌握 AI 辅助重构与优化，是 AI 工程师把大模型能力落进研发流水线的关键一步：从此代码质量治理有据可查、优化建议有量可依，你也将从「会写代码」进化成「会带队翻修老屋的工匠头」。

可视化演示
代码异味识别
智能重构建议
性能优化分析
复杂度治理
技术债务管理
工具协同流程
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示AI辅助代码重构与性能优化流程，包括代码分析、模式识别、自动重构与性能提升评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI辅助重构代码分析：AST解析与模式识别自动重构：提取函数、简化条件质量提升：圈复杂度降低 Quality = f(Complexity, Duplication, Coverage) AI驱动的代码重构与质量提升

代码异味识别

老工匠进屋后的第一件事不是抡锤子，而是慢慢走一圈：手指沿着墙根摸过，在窗台边眯起眼，鼻子凑近墙角深深一吸。哪里有渗水留下的黄斑，哪块地板踩下去微微发软，他都会记在随身的本子上。这些细微的「屋况异常」，就是他判断翻修方案的起点。

代码世界里有同样的「屋况异常」，工程师们称之为代码坏味道。它们不是 bug，程序照样能跑，但就像漏水的墙角，迟早要出大事。AI 代码助手经过海量工程数据训练，能像老工匠一样扫视整个代码库，自动标出「这里味道不对」。它扫描的不是空气，而是抽象语法树（AST）——把每个文件拆成结构清晰的语法树，相当于给房子画一张精确到螺丝的管线图。

最常见的坏味道包括：重复代码、长函数、过深嵌套、魔法数字和臃肿类。其中重复代码最普遍——同一个逻辑被复制到十几个地方，改一处漏一处。AI 会把源码切成 token 序列，token 相当于句子里的词语，是代码的最小语言单位，再用相似度公式度量两段代码的重复程度。

勘察结束，工匠的笔记本上写满了红圈。他不会立刻动工，而是把清单交给房东过目——你拍板，我动手。AI 的「嗅探报告」也同样只是起点，具体拆不拆、怎么拆，还需要后面的手艺来回答。

\displaystyle S(A, B) = \frac{2 \times |A \cap B|}{|A| + |B|}

这个公式算的是「两段代码长得有多像」：共同词语越多，越像；超过 0.8 就可以判定为需要合并的重复代码。

token 总数$|A|$ 与 $|B|$ 分别代表两段代码各自包含的 token 数量，token 相当于句子里的词语，是代码的最小语言单位。
$\displaystyle |A|,\ |B|$
共同部分$|A \cap B|$ 是两段代码共同拥有的 token 数量，重合越多，结构就越像。
$\displaystyle |A \cap B|$
放大分子$2\times$ 把共同数量翻倍，让最终结果落在 0 到 1 之间，便于所有项目统一设定阈值。
$\displaystyle 2 \times |A \cap B|$
相似度判定$S(A,B)$ 越接近 1 越可能是复制粘贴的产物，超过阈值（通常取 0.8）就触发重构建议。
$\displaystyle S(A,B) = \frac{2 \times |A \cap B|}{|A| + |B|}$

智能重构建议

确认了墙皮裂纹和管线纠缠之后，老工匠才会铺开图纸。他说：这道隔断可以打通，两个房间合成一个通透的客厅；这根旧水管动线不对，挪个位置能少拐三个弯。每一条建议都配着工序说明——先拆什么、后补什么、用哪种材料。

AI 重构建议与之同构。它不只说「这里有坏味道」，而是给出精确到行的修改方案：把大函数拆成几个小函数、给晦涩的变量重新命名、把公共逻辑提取成工具函数。这些手法在软件工程里叫重构手法，最常用的有 Extract Method（提取函数）、Rename（重命名）、Move（移动代码位置）、Inline（内联合并）等。

但翻修最怕砸了承重墙。重构的铁律是「行为保持」——优化内部结构的同时，绝不能改变程序对输入的处理结果。AI 助手会对照测试用例反复检查：重构前后，同一份输入是否得到完全相同的输出。为了做到这点，它会先收集现有测试，再为关键分支补上测试样例，把「人眼看不出的差异」变成「机器一跑就知道的差异」。

房东听着工匠的解释，心里踏实了：原来每一条建议后面都有一道「承重校验」。但他也明白，校验不能光靠嘴上保证——下一件事，他正好想请教工匠：能不能顺手把这房子的能耗账也算一算？

\displaystyle \forall x \in X, \quad f_{old}(x) = f_{new}(x)

这句话的意思是：对测试集里的每一个输入，重构前和重构后算出的结果必须一模一样——行为是承重墙，谁都不能碰。

遍历输入$\forall x \in X$ 表示遍历测试集中的每一个输入用例，一个都不能漏，包括边界值和异常值。
$\displaystyle \forall x \in X$
输入空间$X$ 是全部有效输入构成的集合，测试覆盖得越全，行为保持的验证就越有说服力。
$\displaystyle X$
前后对比$f_{old}(x)$ 与 $f_{new}(x)$ 分别代表重构前与重构后的函数对输入 $x$ 的计算结果。
$\displaystyle f_{old}(x),\ f_{new}(x)$
等式成立若每个输入下前后结果都相等，则说明结构变了、行为没变，这次重构才是安全的。
$\displaystyle f_{old}(x) = f_{new}(x)$

性能优化分析

房子住久了还有一个隐痛：冬冷夏热。房东想当然地决定「把整面墙都换成加厚保温层」，老工匠却摆摆手，先掏出一台热成像仪对着墙壁扫了一圈。结果显示：热量主要从三扇老窗户的缝隙溜走，墙体本身保温还算合格。先补缝、再加厚，才能花小钱办大事。

代码的性能优化同样容易「拍脑袋」。程序员常凭直觉去优化某段代码，结果整体没变快多少。AI 性能分析的第一步是用剖析器（profiler）跑出热点——剖析器像一台给代码计时的秒表，能标出真正消耗大量时间或资源的那部分代码，正如热成像仪把窗缝发红的位置照得清清楚楚。

找到热点后，AI 会用阿姆达尔定律帮你算清优化收益的上限。它揭示了一个反直觉的事实：整体加速比受制于「无法优化的串行部分」。假设某部分只占整体耗时的 10%，就算把它优化到无限快，整体最多也只快 11%——这就是为什么先定位热点比急着换算法重要得多。

看完热成像报告，房东放弃了砸墙的冲动，决定先换密封条。这个道理放之四海而皆准：先找准问题症结，再动手改造。对代码而言同样如此——性能优化的首要技能不是改代码，而是算清楚「该改哪里」。

\displaystyle S = \frac{1}{(1 - p) + \frac{p}{n}}

整体能快多少倍，主要看你优化的部分占了多少比例（p），以及这部分被加速了多少倍（n）。占比太小，怎么优化都是白忙活。

可优化占比$p$ 表示被优化部分占整体耗时的比例，只有热点占比高，优化才有意义。
$\displaystyle p$
优化倍数$n$ 是这部分代码提速的倍数，比如引入缓存后速度快了 10 倍，则 $n=10$。
$\displaystyle n$
串行拖累$(1-p)$ 是无法优化的部分，无论怎么加速它都原地不动，构成整体收益的天花板。
$\displaystyle (1-p)$
整体加速比$S$ 是优化后整体快了多少倍，当 $p$ 很小时 $S$ 逼近 1，说明这次优化近乎无效。
$\displaystyle S = \frac{1}{(1 - p) + \frac{p}{n}}$

复杂度治理

老匠人又指着屋子的平面图叹了口气：这房子一百年前只有三间房，后来每代人都随手隔出一间，如今竟有十七八个房间，门连着门、走廊套着走廊，住在这里的人每天找房间都得绕晕。房子的「迷宫指数」越高，翻修的风险就越大。

软件工程用圈复杂度来量这个「迷宫指数」。它统计代码控制流里有多少条独立路径——决策分支越多（if、else、for、while 都是分叉口），路径就越多，人就越难读懂，改动时越容易踩雷。行业共识是：单个函数的圈复杂度超过 10，就该考虑拆分了。

AI 能自动画出函数的控制流图，把每个判断点、每个循环变成图上的节点和箭头，再精确算出圈复杂度。更重要的是，它会进一步治理复杂度：消除模块之间的循环依赖（A 依赖 B、B 又依赖 A 的怪圈），把大模块拆成高内聚低耦合的小模块，让整个架构从蜘蛛网变成层次分明的树。

拆迷宫工程浩大，工匠却一副胸有成竹的样子：把仓库改成储物间、把走廊尽头封上、给每个房间挂上用途牌。代码的模块化拆分也是同理——不是把小房间砸通，而是让每个函数只做一件事，让每个模块有清晰的职责边界。

\displaystyle V(G) = E - N + 2P

圈复杂度 = 边数 − 节点数 + 2 × 连通分量数，本质是算「这个函数里有多少条不重样的走法」。

统计边数$E$ 是控制流图里的边数，每一条边代表一次执行流转，相当于迷宫里的每一条通道。
$\displaystyle E$
统计节点$N$ 是节点数，每个节点是语句、判断或汇合点，相当于迷宫里的房间。
$\displaystyle N$
连通分量$P$ 是连通分量的个数，单个函数通常为 1，表示整个迷宫没有断开的区域。
$\displaystyle P$
独立路径$V(G)$ 算出的就是独立路径条数，数值越大，测试要覆盖的路径越多，理解与维护越难。
$\displaystyle V(G) = E - N + 2P$

技术债务管理

翻修预算有限，房东盯着工匠的报价单犯了难。工匠说：有些修补可以放一放，但这车库漏水的账你可千万别拖——三年前修只要三百块，如今泡坏了墙根和电路，没个一万块下不来。欠着欠着，利息比本金还高。

软件世界把这种「明明知道该修却一直拖」的账叫技术债务。每一个临时补丁、每一处「先这样吧以后再说」的代码，都是一笔欠账。AI 重构助手能做债务盘点：扫描整个仓库，量化每处债务的位置、影响范围和修复成本，再给出偿还建议，让看不见的「烂账」变成清清楚楚的报表。

债务要分轻重缓急，AI 常用四象限分析法排优先级：横轴是修复成本，纵轴是业务价值。高价值低成本的债务立刻还；低价值高成本的债务可以等合适时机；而所有债务都会随复利增长——每拖一个迭代，周边代码继续在债务上面堆叠，修复成本呈指数攀升，这就是「利息」。

房东看到复利账本倒吸一口凉气，当即拍板：欠账要还，利息高的先还。AI 的债务报告就像那本账本——它不替你做决定，但让你清楚地看见每一笔拖延的真实代价，从此每一行临时代码都有了「还款日期」。

\displaystyle D(t) = D_0 \times (1 + r)^t

债务会复利滚动：现在修要花 1 天，拖十个迭代后可能要花 2.6 天甚至更多，拖得越久越还不起。

本金$D_0$ 是债务的初始修复成本，也就是「现在立刻修要花多少时间」。
$\displaystyle D_0$
利息率$r$ 是每个迭代周期的利息率，反映代码继续腐烂、周边继续堆叠的速度。
$\displaystyle r$
周期数$t$ 是拖欠的迭代周期数，拖得越久，指数增长越可怕。
$\displaystyle t$
累计债务$D(t)$ 是拖欠 $t$ 个周期后的总成本，它提醒你还债要趁早，别让利息超过本金。
$\displaystyle D(t) = D_0 \times (1 + r)^t$

工具协同流程

翻修队进场了，工匠却立下三条规矩：第一，每面墙动工前必须先出方案给我过目；第二，每次拆完都要做承重检测；第三，每天收工写施工日志。房东嫌麻烦，工匠说：翻修塌过房的人，才知道这些规矩是保命的。

AI 辅助重构的落地同样依赖一套协同流程。首先是 IDE 集成——重构建议出现在编辑器侧边栏和命令面板里，随叫随到；其次是建议审查机制——每条 AI 建议都走代码评审，不直接合并；再次是测试保障——重构必须配合自动化测试回归，通过才允许上线；最后是团队协作模式——约定「每次重构一个独立分支 + 独立 PR」，改坏了可以随时回滚。

团队还要为 AI 建议建立「验收账本」，用采纳率衡量 AI 重构助手的真实价值：如果一个助手的建议总被否掉，要么是模型不合适，要么是提示词和上下文没喂对，需要及时校准，而不是盲目信任或彻底放弃。

三个月后，老屋翻修完工：房间通透了、暖气均匀了、车库再也不漏了。房东感慨，施工队再能干，也离不开监理手里的检测仪和那本厚厚的日志。AI 代码重构也是如此——再聪明的大模型也只是那把更快的扳手，真正让老屋焕然一新的，是「AI 提议、人拍板、测试兜底」这套默契的协作节奏。

\displaystyle R = \frac{N_{accept}}{N_{total}}

采纳率 = 被团队评审通过的 AI 建议数 ÷ AI 给出的全部建议数，它是人机协作默契度的温度计。

采纳数$N_{accept}$ 是经过代码评审后被团队采纳的 AI 建议数量，代表被「监理放行」的方案。
$\displaystyle N_{accept}$
建议总数$N_{total}$ 是 AI 本轮给出的全部建议数量，包含被采纳和被否掉的。
$\displaystyle N_{total}$
占比公式$R$ 是采纳率，反映 AI 建议与团队编码规范的匹配程度。
$\displaystyle R = \frac{N_{accept}}{N_{total}}$
校准意义采纳率长期过低时，团队应调优提示词或改用更合适的模型，而不是盲目接受所有建议。
$\displaystyle R \rightarrow 1$

AI 应用场景

遗留系统体检与重构排期

阶段：代码分析阶段（重构前评估）

解决的问题：一家保险公司有一套运行十年的订单系统，无人敢动。传统做法是靠老员工回忆「哪块代码别碰」，风险极高、全凭经验。AI 先对整个仓库做坏味道扫描，输出「异味地图」，再结合四象限分析法给出重构优先级，让团队第一次拿到量化的改造计划，告别拍脑袋排期。

具体案例：架构师把 AI 报告带进评审会，挑出 3 个高价值低成本的模块先试点，配合测试补丁和灰度发布，两个月完成试点重构，线上故障率反而下降了 15%。

大促前性能热点定位

阶段：性能分析阶段（优化方案设计）

解决的问题：电商团队大促前压测发现接口超时，传统做法是全员猜谜：有人怀疑数据库、有人怀疑网关，争论几天没有结论。AI 用剖析器沿调用链扫描，按阿姆达尔定律评估每处优化的收益上限，把火力集中到收益最大的瓶颈上。

具体案例：AI 分析指出 70% 的耗时集中在一个 JSON 序列化函数，建议引入缓存并换用更快的序列化库。改造后整体时延下降 40%，而投入只花了两个工作日。

技术债务月度巡检

阶段：持续治理阶段（质量门禁）

解决的问题：团队平时只顾交付功能，技术债越堆越高，直到某次需求改动牵扯十处旧代码才叫苦不迭。AI 在每个迭代结束时自动生成债务报告，对比 D(t) 曲线，标记新增坏味道，并接入 CI 流水线设置复杂度门禁。

具体案例：团队在 CI 中加入「新代码圈复杂度超过 10 自动拦截并要求重构」的门禁，半年后仓库健康度从 60% 升到 85%，新需求平均交付周期缩短了三分之一。

Python 演示

python50 行

"""AI 辅助重构演示：圈复杂度检测与重复代码嗅探。"""import astimport re  def cyclomatic_complexity(source):    """解析源码, 统计判断与循环节点, 计算圈复杂度。"""    tree = ast.parse(source)    decisions = 0    for node in ast.walk(tree):        if isinstance(node, (ast.If, ast.While, ast.For, ast.ExceptHandler, ast.BoolOp)):            decisions += 1    return decisions + 1  def token_set(source):    """把源码切成 token 集合, 作为重复检测的特征。"""    return set(re.findall(r"[A-Za-z_]\w*|\d+", source))  def dice_similarity(a, b):    """用 Dice 相似度衡量两段代码的重复程度。"""    ta, tb = token_set(a), token_set(b)    if not ta or not tb:        return 0.0    return 2.0 * len(ta & tb) / (len(ta) + len(tb))  def smell_report(sources):    report = []    for idx, src in enumerate(sources, 1):        cc = cyclomatic_complexity(src)        if cc > 8:            report.append("函数%d 圈复杂度%d 超出阈值, 建议拆分" % (idx, cc))    for i in range(len(sources)):        for j in range(i + 1, len(sources)):            score = dice_similarity(sources[i], sources[j])            if score > 0.6:                report.append("函数%d与%d 重复度%.2f 建议提取公共函数" % (i + 1, j + 1, score))    return report  if __name__ == "__main__":    samples = [        "def sum_positive(data):\n    total = 0\n    for x in data:\n        if x > 0:\n            total += x\n        else:\n            total -= x\n    return total",        "def sum_positive_v2(data):\n    total = 0\n    for x in data:\n        if x > 0:\n            total += x * 2\n        else:\n            total -= x\n    return total",        "def validate(user):\n    if not user:\n        return False\n    if user.age is None:\n        return False\n    if user.age < 0:\n        return False\n    if user.age < 18:\n        return False\n    if user.name is None:\n        return False\n    if len(user.name) > 10:\n        return False\n    if user.email is None:\n        return False\n    if '@' not in user.email:\n        return False\n    return True",    ]    for msg in smell_report(samples):        print(msg)

目的：在本地复现 AI 重构助手的两项核心能力——圈复杂度计算与重复代码嗅探，凡超标自动给出重构建议。

tree = ast.parse(source)把源码解析成语法树，AI 分析的第一步同样是「读懂结构」。
isinstance(node, (ast.If, ast.While, ast.For, ast.ExceptHandler, ast.BoolOp))判断与循环是控制流分叉的来源，也是复杂度的制造者。
return decisions + 1圈复杂度的简化算法：决策点数加一，对应独立路径数。
re.findall(r"[A-Za-z_]\w*|\d+", source)用正则提取标识符与数字，构成代码的「指纹」特征集合。
return 2.0 * len(ta & tb) / (len(ta) + len(tb))Dice 相似度的直接实现，分子翻倍让分值落在 0~1。
if score > 0.6:超过阈值的「双胞胎代码」被标记出来，提示提取公共函数。
if __name__ == "__main__":入口约定，让工具既能被 import 调用也能直接命令行运行。

常见误区

误区AI 都建议得这么详细了，直接让它在流水线里自动改、自动合并不就行了？省得人来来回回评审。

正解重构最大的风险是行为被悄悄改变。AI 给出的 diff 看似完美，但可能漏掉边界条件或上下文依赖。正确做法是「AI 提议、人评审、测试兜底」——每个重构都走独立分支，配合自动化测试回归，通过后才能合并。这就像翻修砸墙前必须先做承重检测，再厉害的工匠也不能跳过。

为何常见：大模型生成的代码往往看起来合情合理，人容易产生「它能写好就能改好」的错觉，忽略了模型没有真实运行环境验证能力的事实。

误区圈复杂度是越低越好，那我干脆把所有函数都拆成三行一截的小函数，分数一漂亮，代码质量就上去了。

正解圈复杂度只是信号不是目标。盲目拆分会让代码碎片化：调用链变长、上下文被切断，反而更难看懂。合理的做法是把复杂度控制在 10 以内，同时保证每个函数有清晰的语义边界——就像老屋隔间不是越少越好，而是每个房间用途要明确。

为何常见：指标一旦被当成 KPI，人就会「优化指标」而不是「优化代码」，这是典型的古德哈特定律：当度量变成目标，它就不再是好度量。

误区反正现在功能都在跑，代码乱点就乱点吧，等有空了再一起还技术债，现在动它反而容易出 bug。

正解技术债务的可怕之处在于复利：拖得越久，周围代码越会「长」在债务代码上，修复成本指数上升。AI 债务报告的意义就是让你看见 D(t) 曲线——正如车库漏水，第一年几百块，第三年上万块。应该用四象限法排出优先级，每个迭代偿还一部分，而不是攒到系统崩溃才动手。

为何常见：债务成本是隐性的，眼前功能交付看得见，未来维护成本看不见，人天然低估远期风险。

误区性能不行，肯定是算法不够高级，让 AI 帮我换个更炫的算法肯定就好了。

正解不先做热点分析就换算法，等于不看热成像就砸墙。如果瓶颈在 I/O 等待或重复计算，换算法可能毫无收益。先用剖析器定位热点，再用阿姆达尔定律估算上限——当可优化部分占比 p 很小时，整体收益注定有限。

为何常见：算法听起来最「技术」，人们倾向于用体面的方式解决问题，却忽略了 profiling 这种朴素但有效的排查手段。

面试题

Q1. 重构的首要原则是什么？

单选题 · easy

A.重写所有代码迁移到新框架
B.保持外部行为不变改善内部结构← 正确答案
C.尽可能删除冗余的多余函数
D.让代码总行数越少就越优秀

答案：B。重构的核心是「行为保持」：结构变了、结果不变。A 是重写而不是重构；C 无差别删函数可能删掉必要逻辑；D 行数少不等于质量高。就像翻修老屋可以打通隔断，但承重墙绝对不能动，B 正是重构的定义。

Q2. 圈复杂度衡量的核心是什么？

单选题 · easy

A.代码的执行耗时时长
B.代码的缩进宽度大小
C.代码的独立路径数量← 正确答案
D.代码的注释占比比例

答案：C。V(G)=E−N+2P 算的是控制流图中的独立路径条数。路径越多，分支越多，越难读越难测。A 属于性能范畴，B 和 D 与圈复杂度无关。就像迷宫房间越多，出口的路线选择越多，人越容易迷路。

Q3. 以下哪项最符合 AI 检测重复代码的原理？

单选题 · mid

A.比较两段代码的修改时间
B.比较两段代码的 token 相似度← 正确答案
C.统计两段代码的执行次数
D.比较两个函数的参数个数

答案：B。AI 把代码切成 token 集合，用 Dice 相似度公式计算重合度，超过阈值即判定重复。修改时间、执行次数、参数个数都无法反映「结构长得像」这个事实。这就像工匠用手摸墙砖缝隙判断是否同一批料，比看标签可靠得多。

Q4. 阿姆达尔定律指出整体加速比主要取决于什么？

单选题 · mid

A.可优化部分占整体耗时的比例← 正确答案
B.优化后代码总行数减少数量
C.团队成员数量多少
D.注释文档的详细程度

答案：A。S=1/((1−p)+p/n)，当可优化部分占比 p 很小，无论 n 多大整体都上不去。只有 A 指向这层天花板。这就是「先看热成像再砸墙」的道理——热点占比小，优化等于白费力气。

Q5. 技术债务中的「利息」通常指什么？

单选题 · easy

A.代码注释中文字的数量
B.买服务器支付的费用
C.未来修改代码额外付出的成本← 正确答案
D.每次评审会议耗时长短

答案：C。技术债务的利息是拖延带来的额外成本：债务代码周围持续堆叠新逻辑，改一处牵十处。D₀(1+r)^t 里的 r 就是每个迭代复利滚动的利息率。车库漏水第一年几百块、第三年上万块，这就是利息。

Q6. 某函数含 6 个 if 语句和 1 个 for 循环，圈复杂度约为多少？

单选题 · hard

A.约为 6
B.约为 7
C.约为 8← 正确答案
D.约为 9

答案：C。圈复杂度 = 决策节点数 + 1。if 和 for 都是决策节点，共 6+1=7 个，V(G)=7+1=8。这就是「V(G)=E−N+2P 的直觉版本」：决策越多路径越多。虽然 8 还没到 10 的红线，但已经该警惕了。

Q7. 重构时保证「行为保持」最可靠的依据是什么？

单选题 · hard

A.依赖代码注释的充分说明
B.完全信任 AI 生成的补丁
C.重构后立即人工重写一遍
D.重构前后自动化测试输出一致← 正确答案

答案：D。行为保持的校验公式是 ∀x∈X, f_old(x)=f_new(x)，唯一可行的方法是让测试集 X 覆盖足够多的输入，对比前后输出。注释会过期、AI 会漏判、人工重写又引入新风险，只有测试回归是硬验收。就像翻修后必须做承重检测，不能靠嘴说。

Q8. 以下哪些属于常见的代码坏味道？

多选题 · mid

A.超长函数分支众多← 正确答案
B.重复代码大量存在← 正确答案
C.职责清晰的短小函数
D.模块之间循环依赖← 正确答案

答案：ABD。坏味道包括长函数、重复代码、循环依赖、过深嵌套等。职责清晰的短小函数是优良结构而不是坏味道。AI 靠 AST 与 token 分析自动标记这些信号，就像工匠摸墙、闻霉、看裂缝一样。

Q9. AI 辅助重构真正落地需要哪些配套机制？

多选题 · mid

A.代码评审人工把关← 正确答案
B.自动化测试回归保障← 正确答案
C.将建议纳入团队编码规范← 正确答案
D.全自动静默合并代码

答案：ABC。协同流程四要素：IDE 集成、建议审查、测试保障、团队规范。D 恰恰是常见误区——全自动合并违背「AI 提议、人拍板」的原则，风险极高。没有评审和测试兜底，AI 重构等于蒙眼开车。

Q10. 关于技术债务四象限分析法，下列说法正确的是？

多选题 · hard

A.高价值低成本债务应优先偿还← 正确答案
B.四象限只是排序工具不能代替评审← 正确答案
C.所有债务应立即无条件全部清空
D.低价值高成本债务可以暂缓处理← 正确答案

答案：ABD。四象限横轴修复成本、纵轴业务价值。A 是「低垂的果实」先摘；D 性价比低的账可以等时机；B 说明象限是排优先级的方法论而非万能药；C 忽略了资源有限，债务偿还也要排序。还债像翻修预算——先修车库漏水，而不是先换门把手。