AI时代的软件工程质量保障：
Understand如何助力代码分析、软件理解与智能开发

从“生成代码”走向“理解代码、评价代码与维护代码”

引言：当代码生成不再困难，代码质量成为新的核心问题

过去几十年，软件工程的发展始终围绕一个核心目标展开：如何以更高效率、更低风险构建可靠的软件系统。从早期的手工编码，到集成开发环境中的语法提示与自动补全，再到今天由大语言模型驱动的代码生成，软件生产方式正在发生深刻变化。

以 GPT、Claude、DeepSeek 等为代表的大语言模型，已经能够完成函数实现、算法编写、测试生成、代码解释、局部重构和项目补全。开发者的工作方式也在由“逐行编写代码”逐渐转向“描述目标、约束方案、审查结果并完成工程决策”。

然而，代码生成能力的提升，并不意味着软件质量问题会自动消失。恰恰相反，当代码生产成本快速下降后，研发团队需要面对更多代码、更快的变更节奏以及更加复杂的人机协作过程。代码是否能够运行，只是最基本的要求；代码是否容易理解、便于维护、符合既有架构并能够长期演进，才决定了它能否真正进入工程环境。

因此，AI时代的软件工程关注点正在发生转移：从“能否生成代码”，进一步转向“能否持续生成、识别和维护高质量代码”。在这一背景下，静态分析与软件理解工具的重要性进一步凸显。Understand 作为一款面向软件度量、结构分析和可视化理解的专业工具，为研发团队、软件架构师和科研人员提供了观察代码内部结构的系统化方法。

一、AI生成代码带来的软件工程新挑战

1. 可运行代码不等于高质量代码

传统的软件质量保障通常依赖开发经验、编码规范、代码审查、自动测试和持续集成流程。AI生成代码同样可以通过语法检查和部分测试，但这并不能充分说明其工程质量。

一段代码可能在当前测试集上输出正确结果，却仍然存在控制流复杂、职责划分不清、异常处理冗余、模块耦合过高或命名表达不准确等问题。这些问题往往不会立即表现为运行错误，却会在后续修改、扩展和故障定位中显著增加成本。

def process(data):     result = []     for item in data:         if condition(item):             for value in item:                 if check(value):                     result.append(value)     return result

上述代码可能能够完成任务，但多层嵌套会增加理解难度和测试路径数量。对这类问题，仅依靠“是否通过测试”无法给出完整判断，还需要结合复杂度、嵌套层级、控制流和可维护性等指标进行评价。

2. 代码生产速度提高，质量管理压力同步增加

AI显著降低了代码生成门槛。过去需要数小时完成的实现，现在可能在几分钟内生成多个候选版本。这种效率提升带来了直接价值，但也使代码增长速度超过人工审查速度。

当大量AI生成内容进入代码库后，团队需要及时识别高复杂度函数、重复实现、过度依赖、异常调用链以及架构偏移。若仍然完全依赖人工逐文件检查，审查成本会迅速上升，关键风险也可能被淹没在大量变更之中。

• 项目代码规模快速增长，局部实现更容易出现冗余；
• 同一需求可能生成多个风格差异较大的实现；
• 生成代码可能绕开已有抽象，重新实现现有能力；
• 局部代码看似合理，但可能破坏项目整体依赖关系；
• 短期功能正确，长期维护成本却难以提前判断。

3. AI代码需要被放回真实软件系统中评价

在算法题或独立函数中，代码可以作为相对封闭的单元进行分析。但在真实项目里，代码质量不仅取决于某一个函数，还取决于它与目标文件、模块以及整个仓库之间的关系。

因此，对AI生成代码的评价应当从多个层次展开：既要观察目标代码本身的规模、复杂度和控制结构，也要观察其对目标模块调用关系、依赖结构和项目架构造成的增量影响。Understand 的软件实体模型、度量体系和图形分析能力，能够为这种多层次评价提供支撑。

二、静态代码分析：连接代码生成与质量保障的重要桥梁

静态代码分析是指在不实际执行程序的情况下，对源代码、语法结构、符号关系、控制流、调用关系和依赖结构进行分析。与动态测试主要回答“程序运行后是否得到正确结果”不同，静态分析更加关注“代码是如何组织的，以及这种组织方式会带来怎样的工程影响”。

在AI辅助开发场景中，静态分析并不是动态测试的替代方案，而是其重要补充。动态测试可以识别错误答案、运行异常、超时和性能问题；静态分析则能够揭示高复杂度、深层嵌套、过长调用链、模块耦合以及架构偏移。二者结合，才能形成更加完整的软件质量评价。

静态分析能够回答的关键问题

• 代码规模：项目包含多少文件、类、函数和有效代码行？
• 代码复杂度：哪些函数具有较多独立执行路径或较深嵌套？
• 调用结构：哪些函数处于核心位置，调用链是否过长？
• 依赖关系：模块之间如何引用，是否存在过度耦合或循环依赖？
• 维护风险：哪些实体更值得优先审查、测试或重构？
• 架构变化：新生成代码是否改变了原有层次边界和依赖方向？

需求描述    ↓ AI生成代码    ↓ 静态分析与动态测试    ↓ 质量评价与风险识别    ↓ 人工审查、修改与合并    ↓ 持续维护与软件演进

三、Understand：面向软件理解的专业静态分析平台

Understand 是 SciTools 推出的专业静态代码分析与软件理解工具。它不仅提供代码行数等基础统计，还能够建立源代码实体之间的语义关系，支持软件度量、交叉引用、调用分析、依赖分析、控制流分析和多种图形化视图。

与主要面向编码规范检查的工具相比，Understand 更强调对软件系统本身的理解。开发者可以从项目、目录、文件、类、函数和变量等不同粒度进入分析，查看实体属性、引用关系和结构图，从而由局部实现逐步理解整体系统。

Understand 支持 Python、C/C++、Java、C#、Ada、Fortran 等多种语言，适用于企业代码库分析、遗留系统理解、架构评审、重构准备、代码审查以及软件工程科研。

Understand的核心价值

1. 将分散的源代码转化为可查询的软件实体与关系网络。
2. 通过统一的软件度量指标，量化代码规模、复杂度和结构特征。
3. 通过调用图、依赖图、控制流图等视图降低复杂系统的理解成本。
4. 帮助团队从“凭经验判断”转向“结合数据和结构证据进行决策”。
5. 为人工代码、AI生成代码和人机协同代码提供统一分析基础。

四、Understand的核心分析能力

1. 软件规模与实体统计

软件规模是理解系统复杂程度的基础。Understand 可以围绕项目、文件、类和函数统计代码行数、有效代码行、声明数量、语句数量、函数数量和类数量等指标。

这些指标本身并不能直接决定代码质量，但能够帮助分析人员识别异常增长、超大文件、超长函数以及不均衡的模块划分。在AI生成场景中，还可以比较不同代码来源是否存在明显的代码膨胀或过度拆分。

指标类型	典型指标	可回答的问题
代码规模	CountLine、CountLineCode、CountStmt	代码是否明显膨胀，文件或函数是否过大
实体数量	函数数、类数、文件数	功能拆分是否合理，项目结构是否均衡
注释与空白	注释行、空白行及其比例	代码表达和书写风格是否具有差异
声明与执行语句	声明语句、可执行语句	实现方式是偏声明式还是偏过程式

2. 圈复杂度与嵌套分析

圈复杂度用于描述程序中独立执行路径的数量。条件判断、循环、异常处理和部分逻辑分支都会增加复杂度。复杂度越高，通常意味着需要覆盖的测试路径更多，理解和修改代码时也需要考虑更多状态组合。

Understand 可以提供函数级和文件级的复杂度指标，包括平均复杂度、最大复杂度以及复杂度汇总等。结合嵌套层级指标，可以进一步识别“分支不多但嵌套很深”或“函数数量较多且局部复杂度集中”等不同问题。

def handle(item):     if item is not None:         for value in item:             if validate(value):                 try:                     save(value)                 except StorageError:                     recover(value)

这类实现可能具备完整的防御性处理，但也可能形成较深的控制结构。通过复杂度和控制流分析，可以判断其是否值得拆分、简化或增加针对性测试。

3. Control Flow Graph：理解函数内部执行逻辑

控制流图（Control Flow Graph，CFG）以节点和边表示程序中的基本执行块及其跳转关系。它能够直观展示条件分支、循环、提前返回和异常路径。

对于代码审查人员而言，CFG 可以帮助快速识别路径数量较多、分支聚集或异常流程复杂的函数；对于AI生成代码研究，CFG还可以用于比较人工代码与模型生成代码在控制结构组织方式上的差异。

条件判断         /         分支 A      分支 B         \      /          后续处理              ↓            返回结果

4. Call Graph：理解函数之间的协作关系

调用图（Call Graph）描述函数或方法之间的调用关系。通过调用图，可以识别系统入口、核心服务、公共工具函数、回调链和跨模块调用路径。

在AI辅助开发场景中，新生成代码可能通过新增辅助函数完成任务，也可能绕开既有接口直接访问底层模块。单看生成函数本身难以发现这种影响，而调用关系分析可以将新代码放入系统上下文中观察。

调用图还可以辅助分析 fan-in 和 fan-out。较高的 fan-in 说明某个函数被大量实体依赖，修改时需要更加谨慎；较高的 fan-out 则可能说明函数承担了过多协作职责，值得检查是否需要拆分。

5. Dependency Graph：观察模块耦合与架构边界

依赖关系图（Dependency Graph）关注文件、模块、包或子系统之间的引用关系。对于真实项目而言，依赖方向和层次边界往往比单个函数的写法更能反映架构质量。

一个局部实现即使复杂度不高，如果引入了不合理的跨层依赖、循环依赖或对核心模块的额外耦合，也可能增加长期维护风险。Understand 能够帮助分析人员从项目结构中定位这些变化。

界面层    ↓ 业务服务层    ↓ 数据访问层    ↓ 基础设施层

当生成代码打破既有依赖方向，例如由界面层直接访问底层存储，或者在多个模块之间形成双向引用时，依赖图能够直观揭示这种架构偏移。

6. Butterfly Graph与交叉引用分析

Butterfly Graph 以某个实体为中心，同时展示其上游引用者和下游依赖对象，适合快速判断一个函数、类或文件在系统中的局部影响范围。

当开发者接手陌生代码，或者需要评估某次修改可能影响哪些模块时，Butterfly Graph 与交叉引用信息能够减少在大量文件中反复搜索的成本。对AI生成代码进行审查时，也可以利用这一视图观察目标实体与原项目之间是否形成了合理连接。

五、AI时代，Understand能够提供哪些具体帮助

1. 为AI生成代码建立统一、可量化的评价口径

不同开发者和不同模型生成的代码风格差异明显。仅依靠主观阅读，很难在大量样本中进行稳定比较。Understand 提供统一的实体定义和度量口径，可以将代码规模、复杂度、语句组成、调用关系和依赖结构转化为可比较数据。

这种量化能力尤其适合批量分析。研究人员可以比较人工代码与模型代码，企业也可以比较不同AI工具、不同提示策略或不同版本生成结果的工程特征。

2. 让代码审查从平均用力转向风险优先

代码审查资源通常有限。如果所有变更都采用相同审查强度，团队很难兼顾速度与质量。Understand 可以帮助识别复杂度较高、依赖范围较大、调用位置关键或结构变化明显的代码区域。

这使审查人员能够优先关注高风险实体，而对低风险、结构清晰的代码采用更轻量的检查方式。AI生成代码数量增加后，这种风险优先的审查模式具有更高价值。

3. 帮助理解陌生项目和遗留系统

AI时代并不会消除遗留系统。相反，新生成代码往往需要接入多年积累的现有代码库。文档缺失、人员流动和技术栈复杂，使开发者很难仅凭目录和文件名快速理解系统。

Understand 可以通过实体浏览、调用关系、依赖图和交叉引用，帮助开发者建立从局部到整体的理解路径。开发者可以先定位目标函数，再查看它被谁调用、调用了哪些实体、依赖哪些模块，最终判断其在系统中的实际职责。

4. 为重构和架构优化提供证据

重构不应只依靠直觉。高复杂度、深嵌套、高扇出、跨层依赖和循环依赖都可以作为重构候选的证据。Understand 能够帮助团队定位这些结构问题，并在修改前评估影响范围。

对于AI建议的重构方案，也可以在应用前后分别分析，比较复杂度、调用结构和依赖结构是否真正改善，从而避免“代码看起来更整洁，但系统耦合反而增加”的情况。

5. 支撑教学、科研与软件工程实验

在高校教学和科研中，Understand 可以用于展示复杂度、控制流、调用关系和模块依赖等抽象概念，也可以用于构建大规模静态分析数据。

在AI代码研究中，研究人员可以将不同来源代码置于同一分析环境，通过统一指标比较其可维护性、结构组织和项目影响，为“功能正确性之外的代码质量”提供实证依据。

六、从单个函数到完整项目：建立多层次分析视角

AI生成任务既包括独立函数和算法题，也包括真实仓库中的函数补全、模块修改和缺陷修复。不同任务需要采用不同的分析粒度。对于项目级代码，如果只把生成内容当作独立函数，往往会忽略其与原有系统之间的关系。

更合理的方法是建立由小到大的多层次分析框架。

分析层次	主要对象	重点关注
目标代码层	生成函数、类或代码片段	规模、复杂度、嵌套、语句结构、控制流
目标文件或模块层	生成代码所在文件与直接关联模块	函数组织、调用关系、局部依赖、职责变化
项目或仓库层	完整项目及其模块网络	架构边界、耦合、依赖增量、关键节点变化

在目标代码层，可以比较人工实现与AI实现的代码行、语句数量、圈复杂度和控制流结构。

在目标文件或模块层，可以观察新增实现是否改变函数组织方式，是否引入额外调用和依赖。

在项目或仓库层，更适合比较相对原始项目的增量，例如新增依赖数量、核心节点变化、跨层引用和耦合增量。

这种多层框架能够避免把项目级生成代码简化为孤立片段，也能够更准确地解释AI代码对真实软件系统造成的工程影响。

七、静态分析与动态测试应当如何结合

静态分析和动态测试关注不同问题。动态测试验证代码在特定输入和环境下的行为，静态分析则观察代码结构本身。对于AI生成代码，二者缺一不可。

一段代码可能结构清晰但功能错误，也可能功能正确但难以维护。只有同时考虑正确性、性能和结构质量，才能避免将“通过测试”等同于“工程质量优秀”。

评价维度	主要方法	典型问题
功能正确性	单元测试、官方测试、集成测试	代码是否得到正确结果
运行可靠性	异常、超时、边界测试	代码是否稳定处理各种输入
运行效率	执行时间、内存消耗	代码是否具有可接受的资源开销
代码复杂度	Understand Metrics、CFG	代码是否容易理解和测试
结构质量	Call Graph、Dependency Graph	代码是否符合项目组织和架构
长期维护性	静态指标与项目上下文综合分析	代码是否便于修改、扩展与演进

待评价代码                    │        ┌───────────┴───────────┐        │                       │    动态测试                静态分析        │                       │ 正确性、性能、稳定性     复杂度、结构、依赖        │                       │        └───────────┬───────────┘                    │              综合质量评价

八、Understand在不同应用场景中的价值

1. 企业AI代码审查

企业在引入代码生成助手后，可以将静态分析作为代码进入主干前的重要检查环节。对于复杂度异常、依赖范围扩大或关键模块发生变化的提交，安排更严格的人工审查；对于结构简单且影响范围有限的提交，则采用常规流程。

AI生成或修改代码         ↓ Understand静态分析         ↓ 复杂度、调用关系与依赖变化识别         ↓ 风险分级         ↓ 人工审查与代码合并

2. 大型代码库与遗留系统理解

在缺少完整文档的系统中，Understand 可以帮助新成员快速识别关键模块、公共接口和调用路径。AI可以辅助解释局部代码，而Understand则提供基于源代码事实的结构视图，两者结合能够降低误解陌生系统的风险。

3. 软件重构与技术债治理

团队可以依据复杂度、调用影响和依赖关系建立重构优先级，在重构完成后再次分析并比较指标变化。这样既能判断局部代码是否得到简化，也能观察项目级结构是否同步改善。

4. 软件架构评审

依赖图和调用关系能够帮助架构师检查模块边界是否被遵守、核心层是否被不合理依赖、公共组件是否承担过多职责。面对AI生成的大量变更，这类结构化审查比单纯查看代码差异更容易发现系统性问题。

5. 高校教学与科研实验

在教学中，Understand 可以将圈复杂度、控制流、调用和依赖等概念转化为直观实例；在科研中，可以作为统一静态分析平台，对人工代码和不同模型生成代码进行批量度量与结构比较。

九、案例实践：利用Understand分析AI生成代码的软件工程质量特征

为了更直观地说明Understand在AI时代的价值，可以设计一个“人工代码与大模型生成代码质量比较”案例。该案例不只考察代码是否通过测试，还将代码放在统一静态分析环境中，从规模、复杂度、控制流、调用关系和项目依赖等方面进行评价。

该方法既适用于算法题和独立函数，也适用于真实项目中的函数补全和模块生成。关键是保持任务、语言、输入要求和评价环境一致，保证不同代码来源之间具有可比性。

1. 实验对象与基本流程

代码任务或真实项目         ↓ 构建人工代码基线         ↓ 使用大语言模型生成对应代码         ↓ 统一进行动态测试         ↓ 导入Understand进行静态分析         ↓ 提取Metrics与结构图信息         ↓ 配对比较人工代码与AI代码         ↓ 解释功能、复杂度与项目影响差异

在算法题场景中，可以重点比较代码规模、语句组成、复杂度、嵌套和控制流。

在项目级场景中，则需要保留生成代码所在仓库的上下文，进一步比较目标文件、调用关系和项目依赖变化。

为了减少任务难度差异带来的干扰，宜采用同一道题或同一个代码补全位置的人工实现与模型实现进行配对分析。

2. 代码规模与书写结构比较

首先可以通过代码行、有效代码行、语句数量、函数数量和注释情况分析两类代码的基本形态。部分AI生成代码可能更加完整，包含更多输入检查、异常处理和辅助函数；也可能为了直接完成任务而产生较长的单体函数。

规模差异本身不应被简单解释为优劣。更重要的是结合任务需求判断：增加的代码是否提升了可靠性，还是形成了不必要的冗余；函数拆分是否改善职责边界，还是增加了调用层级。

3. 复杂度与控制流比较

通过圈复杂度、最大复杂度、平均复杂度和嵌套层级，可以判断模型生成代码是否引入了更多执行路径。再结合控制流图，可以观察这些复杂度来自必要的边界处理，还是来自重复判断和多层嵌套。

例如，两段代码均能通过测试，但人工实现使用线性处理流程，AI实现则增加多层条件和异常分支。此时动态正确性相同，而静态结构表明后者需要更多测试路径和维护成本。

人工实现： 输入 → 线性处理 → 返回结果 AI实现： 输入 → 多重判断 → 异常处理 → 辅助调用 → 返回结果

4. 调用关系与模块依赖比较

对于项目级任务，最有价值的分析往往不是生成函数本身，而是它如何接入原有系统。通过调用图，可以观察生成代码是否复用了现有接口、是否引入过长调用链以及是否改变核心函数的调用关系。

通过依赖图，可以进一步判断新增代码是否引入额外模块、跨越原有架构层次或形成双向依赖。分析时应优先关注相对原始项目的增量，而不是只比较两个完整项目的绝对规模。

5. 动态结果与静态特征联合解释

案例分析不应把静态指标孤立呈现。更合理的方式是先区分代码是否通过测试，再在功能状态相同的代码之间比较静态质量。这样可以避免将功能错误代码的结构优势误判为高质量，也可以发现“测试通过但结构风险较高”的实现。

例如，可以先将结果划分为语法错误、运行异常、超时、错误答案和通过，再对通过样本比较执行时间、内存和静态指标。对于项目级任务，还可以记录新增依赖、调用节点和目标模块复杂度变化。

分析问题	Understand支持方式	可能得到的结论
AI代码是否更长	代码行、语句、函数数量	识别代码膨胀或更完整的防御性实现
AI代码是否更复杂	圈复杂度、嵌套、CFG	判断测试与维护成本是否增加
AI代码是否改变调用结构	Call Graph、交叉引用	识别额外调用层级或核心节点变化
AI代码是否增加项目耦合	Dependency Graph、Butterfly Graph	识别跨层依赖、循环依赖和影响范围
AI代码能否用于长期维护	静态与动态结果综合	区分“功能可用”与“工程可维护”

6. 从科研案例走向工程流程

上述案例不仅适用于论文实验，也可以转化为企业内部的AI代码治理流程。企业可以根据自身规范设置复杂度阈值、依赖规则和重点模块名单，对AI生成或修改的代码进行自动筛查。

需要强调的是，Understand提供的是分析证据，而不是脱离上下文的最终裁决。某些复杂度可能来自业务本身，某些依赖也可能是合理设计。最佳实践是将度量、图形、测试结果和工程经验结合，由开发者做出最终判断。

大语言模型生成代码           ↓ 功能测试与性能测试           ↓ Understand结构分析           ↓ 风险指标与影响范围           ↓ 开发者审查和架构判断           ↓ 修改、合并与持续监测

十、从代码生成走向代码理解：AI软件工程的下一阶段

生成式AI正在改变程序员的工作方式，但它不会消除软件工程中的理解、判断和维护问题。随着生成能力逐渐普及，真正形成差异的将不再只是“能否生成代码”，而是“能否建立可靠的质量控制和持续演进机制”。

未来的软件开发流程更可能表现为人机协同：大模型承担代码草拟、局部实现和辅助解释；静态分析与动态测试提供客观证据；开发者和架构师负责需求权衡、风险判断和系统性决策。

在这一流程中，Understand 的作用并不是替代开发者，而是提升开发者理解复杂代码和识别风险的能力。它让AI生成内容不再以孤立文本的形式进入项目，而是被放入真实的软件结构中评价。

大语言模型：生成与修改代码            ＋ Understand：度量、结构与依赖分析            ＋ 动态测试：正确性、性能与可靠性验证            ＋ 工程人员：需求、架构与风险决策            ↓ 更可靠的人机协同软件工程

十一、结语：AI时代更需要专业的软件理解能力

AI显著提升了代码生产效率，也让软件团队能够以更快速度尝试方案和完成实现。但代码数量增长之后，如何理解代码、评价代码和维护代码，成为更加重要的问题。

Understand通过软件度量、控制流分析、调用关系分析、依赖关系分析和可视化软件理解，为开发者提供了一套从局部代码到整体架构的观察方法。它既可以用于传统代码库和遗留系统，也可以用于AI生成代码、人机协同代码和智能开发流程。

对于企业，Understand能够辅助代码审查、架构评审、重构和技术债治理；对于高校和科研人员，它能够支持软件质量实验、代码特征分析和AI生成代码研究；对于普通开发者，它则提供了一种更系统地理解陌生项目和复杂代码的方法。

AI解决的是代码生产效率问题，软件工程仍然需要解决质量、结构和演进问题。随着生成式AI进一步进入研发全流程，静态分析与软件理解不会被削弱，反而会成为连接自动生成与工程落地的重要基础能力。Understand的价值，也正在由传统的代码分析工具，延伸为AI时代软件质量保障和软件理解体系中的重要组成部分。