AI Coding 质量治理：工程规范、代码评审与风险驱动测试

摘要：

AI Coding 正在改变软件研发与测试的工作方式。当大量代码由 AI 辅助生成，工程规范不统一、代码审查压力增加、测试覆盖不足等问题也更加突出。本文结合一项 31 万行代码的重构实践，从 AI Rule、Skill、AI Code Review、风险驱动测试和渐进式重构五个方面，分析 AI Coding 在复杂项目中的质量保障方法。

一、AI Coding 提高了开发效率，为什么技术债反而可能增加？

AI Coding 能够帮助工程师完成接口开发、业务逻辑编写、代码重构以及测试脚本生成，但生成速度快，并不意味着代码质量一定高。

在复杂项目中，AI Coding 的质量保障需要覆盖工程规范、代码评审、测试验证和持续重构，而不只是检查生成的代码能否运行。

一项公开的 Agent 评测系统重构实践，展示了这一问题。

该系统从 2025 年 6 月不足 5 万行代码，逐渐增长到约 31 万行。团队超过 90% 的代码由 AI 辅助编写，平均每月还需要完成约 16 个需求。

业务快速增长的同时，系统逐渐出现了几个典型问题。

首先，早期代码按照业务需求组织，缺少清晰的工程分层。Controller、业务逻辑和数据访问代码相互交织，模块之间存在较深的依赖。

其次，不同工程师使用 AI Coding 的习惯不同，生成代码的组织形式和实现思路也存在差异。

还有一些历史兼容逻辑隐藏在较长的调用链中，修改一个接口，可能影响多个业务模块。

这种情况下，继续提高代码生成速度，很可能让原本存在的架构问题扩散得更快。

团队需要解决两个问题：

一是如何清理已有技术债，二是如何避免 AI 继续制造新的技术债。

缺少统一约束与建立质量治理后的两种开发模式，对比代码生成、工程规范、质量检查和交付结果的差异。

二、AI Coding 工程规范：让团队和 AI 遵循同一套开发标准

传统研发中，开发规范主要依靠技术文档、代码评审和工程师经验维持。

到了 AI Coding 阶段，规范还需要能够被 AI Coding 工具理解和使用。

不过，真正需要先统一的是团队内部的工程标准。

例如，业务逻辑应该放在哪一层？数据库对象能不能直接暴露给上层？哪些模块允许互相依赖？新增公共组件需要满足什么条件？

如果工程师对这些问题本身就没有统一认识，即使配置了 AI Rule，生成结果仍可能不一致。

1. 统一架构与业务模型

以典型后端业务系统为例，可以先明确以下约束。

规范确定后，再将其转换为 AI Coding 可以使用的工程约束。

2. 使用 AI Rule 约束代码生成

AI Rule 可以理解为项目级编码规则。

例如：

• 数据库持久化对象不得直接作为公共接口返回对象。
• Controller 不直接承担复杂业务逻辑。
• 修改公共接口时，需要检查上下游兼容性。
• 新增代码优先复用现有公共能力。
• 核心业务变更需要补充相应测试。

对于支持自动加载规则的 AI Coding 工具，可以将这些约束配置到项目规则文件中，让模型在编写代码时持续参考。

需要注意，AI Rule 本质上是对模型的行为约束，并不等同于静态检查器。

对于能够确定性验证的规则，还应通过架构测试、静态代码分析和 CI 质量门禁进行检查。

3. 使用 Skill 固化复杂开发任务

相比 AI Rule，Skill 更适合承载可重复执行的任务流程。

例如，团队需要将旧系统中直接传递的数据库对象，改造成具有明确边界的业务对象。

可以把迁移过程整理成标准化 Skill：

识别受影响对象 → 建立转换关系 → 调整接口契约 → 修复调用链 → 执行验证

工程师以后再处理类似模块时，可以复用已经验证过的任务步骤。

这样可以减少每次重新设计提示词和重复摸索改造方法的成本。

标准层、执行层、验证层之间的关系，以及 AI Rule、Skill 和 Coding Agent 如何配合完成规范化开发。

三、AI 辅助技术债排查：从人工阅读转向代码关联分析

当代码规模达到几十万行时，单靠人工逐个阅读文件，很难快速掌握完整的依赖关系。

尤其是数据库查询、状态管理、历史兼容和跨模块调用等问题，往往隐藏在代码细节中。

AI 可以辅助完成大范围代码检索、调用关系梳理和潜在问题分析。

在上述公开案例中，工程师借助 AI 排查复杂调用链，定位了 10 个较难通过常规人工阅读发现的性能隐患。

这类方法可以应用到多个场景。

但 AI 给出的风险线索仍需要验证。

例如，AI 发现某条调用链中存在多次数据库查询，并不意味着一定存在性能故障。

工程师还需要结合真实执行路径、数据规模、查询计划及运行指标判断问题的严重程度。

因此，更合理的分工是由工程师确定排查重点，AI 扩大代码分析范围，再通过实际证据确认问题。

对于测试开发工程师，这些分析结果同样具有价值。

历史缺陷集中、调用链复杂、业务状态较多的模块，可以优先纳入回归测试和专项测试范围。

四、AI Code Review：将质量检查前移到代码提交之前

随着 AI 生成代码的速度提高，Code Review 很容易成为研发流程中的新瓶颈。

过去工程师可能需要较长时间才能完成一个模块的实现，Reviewer 有相对充足的时间进行审查。

现在 AI 能够快速修改多个文件，甚至完成跨模块重构。如果所有问题都依靠人工逐行检查，代码审查的工作量会明显增加。

可以通过 Pre-PR 机制，把基础质量检查放在正式提交之前。

1. 建立 AI 预审流程

一套比较完整的流程是：

需求与技术方案 → AI Coding → 静态检查与 AI 预审 → 问题修复 → 人工 Code Review → 自动化回归 → 合并发布

其中，AI Code Review 可以重点检查：

对于检查出的缺陷，需要完成确认、修复和重新验证。

正式提交 PR 时，还应附上本次变更说明，包括修改模块、影响范围、测试情况以及需要 Reviewer 重点关注的问题。

2. 人工评审重点转向业务正确性

AI 可以发现一些明显的编码问题，但业务语义错误仍然需要重点关注。

例如，一个订单查询接口的返回结构完全符合规范，异常处理也没有明显问题。

但如果 AI 在修改过程中遗漏了用户数据隔离条件，就可能产生越权查询风险。

这种缺陷不是单靠检查代码格式就能发现的。

因此，人工评审需要更关注业务规则、技术方案、模块边界以及高风险场景。

3. 多模型审查提高问题发现机会

部分团队还会采用高能力模型审查代码，或者通过不同模型交叉检查。

这种方式有机会发现单一模型遗漏的问题，但不能保证审查结果完全正确。

对于关键业务，AI 审查仍需要配合确定性检查、自动化测试以及必要的人工复核。

需求、代码生成、静态检查、AI 预审、人工评审、自动化回归和发布监控之间的流程，以及出现问题后的回退机制。

五、AI 辅助测试：从自动生成用例转向风险驱动测试

AI 测试用例生成已经是较为常见的应用场景。

将需求文档或接口定义交给大模型，通常可以快速生成正常场景、异常场景和边界测试用例。

但实际工程中存在一个问题：

AI 能够生成大量测试用例，却不一定知道哪些业务场景最需要验证。

如果需求文档没有写清楚历史兼容逻辑、跨系统依赖和特殊权限要求，AI 可能遗漏重要场景。

另一种情况是生成大量低价值用例，增加审核与维护成本。

更适合复杂系统的方式，是以业务风险为依据，由工程师确定测试范围与重点，再让 AI 完成代码分析、测试组合和步骤生成。

1. 测试范围识别：确定哪些接口受到影响

首先根据代码变更和运行数据识别候选影响范围。

可以综合利用 Git Diff、接口定义、代码调用链以及流量监控信息。

例如，一次订单服务改动表面上只修改了查询逻辑，但相关结果也被订单详情页、售后系统和运营后台使用。

仅测试直接修改的接口，可能无法覆盖全部风险。

AI 可以辅助收集受影响接口清单，再由测试人员确认真实影响范围。

2. 风险分级：确定每个接口需要测试多深

接口影响范围确定后，需要进一步评估测试优先级。

可以重点检查三个问题：

① 本次代码修改涉及多少逻辑和依赖？

② 修改涉及哪些条件分支和状态转换？

③ 新逻辑是否兼容历史数据及原有调用方式？

对于涉及资金、权限、核心交易和历史数据迁移的变更，还需要提高相应测试优先级。

风险分级应由工程师结合业务背景完成，而不能仅根据修改代码的行数进行判断。

3. 测试设计：利用判定表减少无效组合

复杂业务接口经常具有多个输入条件。

例如，一个查询接口同时支持用户身份、订单状态和时间范围筛选。

如果直接生成全部组合，用例数量可能迅速增加。

可以先通过等价类、边界值和判定表拆分测试条件，再结合风险选择需要覆盖的组合。

AI 适合辅助整理条件、生成候选组合和检查重复场景。

测试人员则需要确认业务特殊规则及关键边界是否被完整覆盖。

4. 测试步骤生成：一次操作验证多个结果

测试设计完成后，可以让 AI 进一步生成结构化测试步骤。

例如，修改订单状态后，除了验证接口返回结果，还可以检查数据库状态、相关业务记录及下游服务的处理结果。

同一个测试操作可以覆盖多个验证维度。

需要特别注意，测试预期应来自已经确认的业务规则或接口契约，不能完全依据 AI 生成的实现代码反推。

否则可能出现代码实现错误，而测试用例也采用相同错误逻辑的情况。

5. 覆盖矩阵：检查哪些风险尚未验证

最后，将受影响接口与测试维度建立对应关系。

表格为示例，用于说明接口与测试维度之间的覆盖关系。

通过覆盖矩阵，可以快速发现仍然缺少验证的业务场景。

这比单纯统计生成了多少测试用例更有价值。

6. 将测试设计进一步接入自动化执行

如果团队已经建立了 Pytest、JUnit、Playwright 或其他自动化测试体系，还可以将经过审核的测试设计转换为自动化脚本。

完整流程可以扩展为：

代码变更分析 → 风险识别 → 测试设计 → 自动化执行 → 覆盖验证

其中，AI 可以参与代码分析、用例和脚本生成、失败日志归类等环节。

人工仍然需要负责测试范围确认、预期结果审核、异常分析以及最终质量判断。

这样才能形成从代码变更到验证结果的质量闭环。

代码变更分析、风险分级、测试设计、自动化执行和覆盖验证五个环节，以及 AI 能力与人工职责的分工。

六、工程示例：AI 修改订单查询接口后，测试应该如何设计？

假设一个订单系统需要新增按照订单状态筛选的功能。

AI Coding 已经完成接口参数、业务逻辑和数据库查询代码的修改。

正常调用返回成功，是否就可以认为本次变更已经通过测试？

显然不够。

需要重点关注以下场景：

其中，历史兼容和权限隔离往往比简单的正常查询更值得优先关注。

例如，原接口不需要订单状态参数，新增筛选条件后，如果没有兼容处理，可能导致旧客户端请求失败。

再如，AI 调整查询条件时遗漏用户 ID 限制，即使功能测试全部通过，也可能留下权限缺陷。

合理的测试流程应该先确认变更影响和关键风险，再由 AI 辅助生成测试设计，最后通过接口测试、数据验证和必要的性能测试完成检查。

这个案例也说明，AI 测试的核心不只是生成测试脚本，而是让测试范围、风险和验证结果建立明确关联。

七、渐进式重构：将技术债治理融入日常研发

对于持续交付的复杂系统，整体推倒重构通常意味着较高成本和风险。

渐进式重构提供了另一种选择。

将大型技术债拆分成可以独立验证的小任务，在正常业务迭代中逐步完成。

例如，历史系统存在数据库对象跨层传递的问题，可以在相关功能升级时同步完成数据对象转换、接口契约调整和调用链修复。

这种方式可以减少一次性大规模迁移带来的风险。

标准化迁移流程

对于重复性较高的重构任务，可以采用以下流程：

核心工程师完成样板模块 → 验证迁移方案 → 沉淀标准 SOP → AI 辅助迁移其他模块 → 执行回归验证

样板模块尤其重要。

因为 AI 即使能够快速完成类似代码修改，也需要一个经过验证的迁移标准。

实际执行时，还需要处理数据库兼容、接口变更、历史数据和回滚方案。

对于测试开发团队，可以将相关验证纳入持续集成流程，在每个重构阶段运行对应测试，避免技术债治理引入新的功能缺陷。

八、AI Coding 质量保障应该关注哪些指标？

代码生成速度可以衡量 AI Coding 的部分效率，但无法反映全部工程质量。

建议同时观察代码质量、测试效果、交付效率和线上稳定性。

特别是在 AI 辅助测试场景中，不能单纯把用例数量增加当作质量提升。

还需要关注测试是否能够发现真实缺陷、关键风险是否得到覆盖，以及测试脚本是否长期稳定。

有条件的团队可以进一步引入变异测试、契约测试和线上质量数据，验证自动化测试的实际有效性。

九、总结

AI Coding 的普及，让代码生产方式发生了变化，也让工程质量治理的重要性更加突出。

对于复杂业务系统，质量保障可以围绕以下几个方面展开。

首先，建立统一的架构规范、业务模型和接口契约，并通过 AI Rule 与 Skill 将工程约束应用到实际开发流程中。

其次，在代码提交之前引入 AI Code Review 和静态检查，将基础问题尽可能提前发现，同时保留人工对业务正确性的判断。

再次，利用 AI 分析代码变更、辅助风险分级和测试设计，并结合自动化测试、覆盖矩阵和执行证据完成验证。

最后，通过标准化 SOP 和渐进式重构，逐步治理历史技术债，同时避免新增代码继续破坏系统结构。

对于测试开发工程师来说，AI Coding 带来的工作变化不仅体现在测试脚本生成上。

代码变更影响分析、风险驱动测试、AI 辅助评审、自动化质量门禁和测试有效性评估，都会成为值得持续建设的工程能力。

AI 可以提高代码生产和测试设计的效率，而可靠的软件交付，仍然需要明确的工程标准、可验证的测试结果和持续运行的质量保障体系。