---
title: "生成式 AI 能全部替代传统软件测试吗？——偏差放大、代码膨胀与关键基础设施的验证之道"
date: 2026-10-28
description: "生成式 AI 不能全部替代软件测试，但会重构测试。本文梳理传统测试未解难题，用 Knight-Leveson 实验、LLM 断言与自评研究说明“AI 测 AI”为何放大同源偏差，结合 GitClear、DORA、Google 变异测试与形式化验证给出应对代码膨胀的办法，并依据 DO-178C/DO-330 与 CrowdStrike 事故，回答关键基础设施该怎么测、能否全盘生成代码。"
tags: ["生成式AI", "软件测试", "AI编程", "测试预言", "变异测试", "形式化验证", "关键基础设施", "DO-178C"]
schema_type: Article
references:
  - title: "An experimental evaluation of the assumption of independence in multiversion programming"
    url: "https://doi.org/10.1109/tse.1986.6312924"
    source: "Knight & Leveson，IEEE Transactions on Software Engineering，1986"
  - title: "Can we find bugs using LLM-generated oracles?"
    url: "https://arxiv.org/abs/2410.21136"
    source: "Konstantinou, Degiovanni, Papadakis，arXiv，2024（2026-10 修订）"
  - title: "LLM Evaluators Recognize and Favor Their Own Generations"
    url: "https://arxiv.org/abs/2404.13076"
    source: "Panickssery, Bowman, Feng，arXiv，2024"
  - title: "Automated Unit Test Improvement using Large Language Models at Meta"
    url: "https://arxiv.org/abs/2402.09171"
    source: "Meta，FSE 2024"
  - title: "2025 GenAI Code Security Report"
    url: "https://www.veracode.com/blog/genai-code-security-report"
    source: "Veracode，2025-07"
  - title: "AI Copilot Code Quality: 2025 Look Back at 12 Months of Data"
    url: "https://www.gitclear.com/ai_assistant_code_quality_2025_research"
    source: "GitClear，2025-02"
  - title: "Announcing the 2024 DORA report"
    url: "https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report"
    source: "Google Cloud / DORA，2024-10"
  - title: "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
    url: "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/"
    source: "METR，2025-07"
  - title: "We are Changing our Developer Productivity Experiment Design"
    url: "https://metr.org/blog/2026-02-24-uplift-update/"
    source: "METR，2026-02"
  - title: "External Technical Root Cause Analysis — Channel File 291"
    url: "https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf"
    source: "CrowdStrike，2024-08"
  - title: "Practical Mutation Testing at Scale: A view from Google"
    url: "https://arxiv.org/abs/2102.11378"
    source: "Petrović 等，IEEE TSE，2021/2022"
  - title: "Please Fix This Mutant: How Do Developers Resolve Mutants Surfaced during Code Review?"
    url: "https://dl.acm.org/doi/10.1109/ICSE-SEIP58684.2023.00019"
    source: "Google，ICSE-SEIP 2023"
  - title: "Prediction: AI will make formal verification go mainstream"
    url: "https://martin.kleppmann.com/2025/12/08/ai-formal-verification.html"
    source: "Martin Kleppmann，2025-12"
  - title: "A benchmark for vericoding: formally verified program synthesis"
    url: "https://arxiv.org/abs/2509.22908"
    source: "Bursuc 等（含 Max Tegmark），arXiv，2025-09"
  - title: "DO-178C & Structural Coverage Analysis"
    url: "https://ldra.com/ldra-blog/do-178c-structural-coverage-analysis"
    source: "LDRA，2025"
  - title: "AC 20-115D: Airborne Software Development Assurance Using EUROCAE ED-12() and RTCA DO-178()"
    url: "https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-115D.pdf"
    source: "美国联邦航空管理局（FAA）"
  - title: "Cost of Poor Software Quality in the U.S.: A 2022 Report"
    url: "https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report"
    source: "CISQ，2022"
---

**一句话结论：生成式 AI 不能全部替代软件测试，但会彻底重构测试——它最适合做“大量产出候选测试和候选代码”的一方，而“判定对错”的那一方必须独立于模型，并且尽量是确定性的。**

**用 AI 测 AI 确实会放大偏差。原因不是 AI “不够聪明”，而是同源：同一份理解、同一套训练数据、同一种思维盲区，写出的代码和测试会在同一个地方一起错（来源1、2、3）。**

**代码膨胀会把瓶颈从“写”推到“审”。出路不是让人读得更快，而是让需要人读的东西变少：人审规格与风险，机器做穷举、变异、差分与证明（来源6、7、11、13）。**

**对关键基础设施，本文判断：现阶段不应让生成式 AI 全盘生成核心代码；可行的路线是“人写规格、AI 写代码和证明、小型可信检查器把关”，责任始终由人和组织承担（本文分析）。**

---

> 素材说明：本文依据软件工程经典实验、2024—2026 年的公开研究与行业报告、CrowdStrike 官方根因分析，以及航空软件标准 DO-178C/DO-330 的公开解读写成。各项数据的口径与限定条件在文中注明；凡属推论，标注“本文分析”。

## 一、先给结论：替代的不是“测试”，而是“测试中的体力活”

要回答“能不能全部替代”，先拆开测试到底在做什么。一次完整的测试活动至少包含五件事：

1. **理解意图**：系统“应该”做什么？——需求、规格、业务规则。
2. **设计用例**：从无穷多的输入中挑出最可能暴露问题的那些。
3. **执行与观察**：运行程序，收集输出、日志、性能、资源消耗。
4. **判定对错**：输出是对的还是错的？——这就是“测试预言”（test oracle）。
5. **承担责任**：对“可以上线”这个结论签字负责。

**本文分析**：生成式 AI 在第 2、3 步已经很强，在第 1 步能当好助手，在第 4 步最危险，在第 5 步原则上不能替代。所以准确的说法是：**AI 会替代测试中大量的体力劳动，但替代不了“独立判定”和“承担责任”**——而这两件恰恰是测试存在的根本理由。

## 二、传统软件测试：人机协同了几十年，还有哪些问题没解决

传统测试已经是“人工 + 自动化”的协同体系：人负责探索性测试、业务验收和风险判断，机器负责单元测试、回归测试、接口测试、性能压测和静态扫描。但下面这些老问题，几十年来一直没有被根治。

### 1. 测试预言问题：知道“怎么跑”，不知道“对不对”

自动化可以生成无数输入，却很难自动知道每个输入的正确输出应该是什么。传统的自动生成工具（如 Randoop、EvoSuite）常把程序**当前的实际行为**直接写成断言——如果代码本身就错了，测试只会把错误“固化”下来（来源2）。这一点后面会成为理解“AI 放大偏差”的钥匙。

### 2. 穷尽不可能：测试只能证明有错，不能证明无错

计算机科学家 Dijkstra 的名言是：测试能证明缺陷存在，但永远不能证明缺陷不存在。即便是航空标准要求的 MC/DC 覆盖，一个含 6 个条件的判断有 64 种组合，满足 MC/DC 只需要 7 个测试（来源15）——覆盖是一种“有代表性的抽样”，不是穷举。

### 3. 需求本身就有歧义或缺失

很多缺陷不是“代码没按需求写”，而是“需求本来就没写清楚”。Knight 与 Leveson 的经典实验中，研究者事先专门消除了规格里的歧义，但 27 个独立团队仍然在相同的“难点”上犯了等价的逻辑错误（来源1）。规格不清，测试只能对着一个模糊的靶子开枪。

### 4. 覆盖率高 ≠ 测得好

2024 年 7 月 CrowdStrike 事件是最好的反面教材。根据其官方根因分析：新模板类型定义了 21 个输入字段，但调用代码只提供 20 个；**用于测试的 12 个静态用例在第 21 个字段上全部使用了通配符**，因此测试全部通过；内容校验器本身也有逻辑错误；直到一次更新首次对第 21 个字段使用非通配条件，传感器发生越界读并导致系统崩溃（来源10）。测试有、校验有、压测也有，但它们共享了同一个错误假设。

### 5. 测试的维护成本与“不稳定测试”

自动化测试本身也是代码，会过时、会脆弱、会随机失败。大型工程组织普遍要为不稳定测试（flaky tests）专门建隔离、重跑和统计机制；被噪声淹没的失败，可能正是真正的缺陷。

### 6. 环境、配置与集成的组合爆炸

单元测试全绿，系统照样可能在某个配置、某个版本组合、某种数据分布下出事。CrowdStrike 出问题的就不是传感器代码本身的一次发布，而是一份“配置内容”的更新（来源10）。

这些问题的代价是真实的：美国信息与软件质量联盟（CISQ）估算，2022 年美国劣质软件造成的成本至少 2.41 万亿美元（来源17）。

## 三、生成式 AI 写代码，偏差从哪里来

生成式 AI 本质上是在给定上下文下预测最可能的下一个 token。这带来三类结构性偏差：

| 偏差来源 | 表现 | 例证 |
|---|---|---|
| 概率性 | 同一需求多次生成，结果不同；“看起来最常见”的写法未必是正确或安全的写法 | Veracode 测试 100 多个模型、80 个任务：45% 的情况下选择了不安全的实现；更大、更新的模型在安全性上并无明显改善（来源5） |
| 自然语言到代码的对齐缺口 | 自然语言天然模糊，模型会“自动补全”你没说的部分，而补全依据是训练数据里的常见做法，不是你的业务 | Java 任务的安全失败率超过 70%，跨站脚本（CWE-80）防护失败率达 86%（来源5） |
| 训练数据的历史偏见 | 公开代码库中的不安全模式、过时 API、重复代码会被学习和复现 | 2024 年复制粘贴代码行占比升至 12.3%，首次超过“移动”（重构）行（来源6） |

**本文分析**：所以“生成的软件总会有偏差”这个判断是成立的。关键问题是：**偏差能不能被一个独立的过程发现？**

## 四、用生成式 AI 来测试，会不会放大偏差？

会——**如果测试和代码来自同一个信息源、同一个模型、同一种理解**。这是本文最核心的论点，有三组证据支持。

### 证据一：独立开发也会“一起错”（1986）

N 版本编程的设想是：让多个团队按同一规格独立开发，投票表决，假设它们会独立失效。Knight 与 Leveson 让两所大学的学生独立写出 27 个版本，用 100 万个输入测试。结果：每个版本单独看都极其可靠，但**多个版本在同一输入上同时失效的次数远超独立假设**，最极端的一个测试输入让 8 个版本同时失败（来源1）。后续分析发现，程序员会在问题的“难点”上犯等价的逻辑错误。

**本文分析**：人类团队尚且如此，同一个大模型写代码再写测试，“独立性”只会更差——它们几乎是同一个“程序员”。

### 证据二：LLM 写的断言主要“照抄”代码的实际行为（2024—2026）

卢森堡大学团队针对 24 个 Java 仓库做了对照实验，结论是：**基于 LLM 的测试生成方法主要捕获的是程序的实际行为，而非预期行为，因此难以发现缺陷**；同时 LLM 生成断言的能力强于判断断言对错的能力（来源2）。

这就是“镜子效应”：让 AI 读代码写测试，它很可能把 bug 当成功能写进断言。测试全绿，信心上升，缺陷被“认证”了。

### 证据三：LLM 评审偏爱自己写的东西（2024）

研究发现，GPT-4、Llama 2 等模型能以不低的准确率认出自己的生成内容，而且**自我识别能力越强，自我偏好越强**——在人类认为质量相同的情况下，模型会给自己的输出打更高分（来源3）。用同一个模型做“代码评审员”，存在系统性放水的风险。

### 放大是怎么发生的

**本文分析**：偏差放大通常经过四步循环——

1. 模型对需求产生一个误解；
2. 按误解写出代码；
3. 读着这份代码写出测试，测试与代码“完美一致”；
4. 覆盖率、通过率等指标全部漂亮，组织因此**降低了**人工审查力度。

第 4 步最致命：它不是让错误多了一个，而是让组织对错误的“免疫力”下降了。DORA 2024 报告的发现与此一致：AI 采用率每提高 25%，代码质量自评约提升 3.4%，但**交付稳定性估计下降 7.2%**（来源7）。

### 但 AI 测试并非必然放大偏差：关键在“谁当裁判”

Meta 的 TestGen-LLM 给出了另一种做法：LLM 只负责生成候选测试，候选必须依次通过一组**与模型无关的确定性过滤器**——能编译、能稳定通过、确实提高了覆盖率——才会被推荐给工程师。在 Instagram 的评估中，75% 的候选能正确构建，57% 稳定通过，25% 提高了覆盖率；在测试马拉松中，它改进了所应用类的 11.5%，73% 的推荐被工程师接受上线（来源4）。

**本文分析**：这组数字说明两件事。第一，多数 AI 产出会被过滤掉——如果没有过滤器，这些就是噪声甚至错误。第二，过滤器只能保证“有改进”，不能保证“断言正确”，所以人对断言语义的把关仍不可少。

### “去相关化”五原则

| 原则 | 做法 | 为什么有效 |
|---|---|---|
| 信息源独立 | 测试从需求/规格生成，**不让测试生成器看实现代码** | 切断“读代码写断言”的镜子效应 |
| 模型多样 | 写代码与写测试、做评审用不同厂商/不同架构的模型 | 降低同源盲区，规避自我偏好（来源3） |
| 确定性裁判 | 编译器、类型系统、静态分析、属性测试、差分测试、模糊测试、形式化证明 | 裁判不会被“说服” |
| 测试的测试 | 用变异测试检验测试本身能否杀死人为注入的缺陷 | 直接度量“测试有没有用”，而不是“跑了多少行” |
| 人拥有验收标准 | 关键断言、业务不变量、验收用例由人定义并签字 | 把“预期行为”的定义权留在人手里 |

## 五、AI 代码量大、不简洁，人类读不过来怎么办

这个担心有数据支撑。GitClear 分析了 2020—2024 年 2.11 亿行代码变更：重构（移动）行从 2021 年约 25% 降到 2024 年不足 10%，复制粘贴行从 8.3% 升到 12.3%，2024 年含 5 行以上重复块的提交频率增长约 8 倍（来源6）。METR 2025 年的随机对照实验中，16 位资深开源开发者在自己熟悉的大型仓库上使用 AI 后，完成任务反而**慢了 19%**，而他们自己以为快了 20%（来源8）。

需要说明的是，METR 在 2026 年 2 月表示，这一结果反映的是 2025 年初的工具；新一轮实验显示开发者“很可能已被加速”，但由于样本选择偏差，数据只是很弱的证据（来源9）。也就是说：**生成速度在快速提升，但“审查与验证”的成本并没有同步下降。**

**本文分析**：解决办法不是“让人读得更快”，而是从四个方向让“必须由人逐行阅读的代码”变少。

### 1. 在生成侧控制体积：把简洁写进验收标准

- 设定复杂度和变更体积预算：单次变更超过阈值，直接要求拆分。
- 强制复用：先检索已有函数与组件，禁止“另起炉灶”的重复实现。
- 鼓励删除：把“删掉了多少代码”与“新增了多少功能”同等计入评价。
- 小批量提交：DORA 指出 AI 容易导致更大的变更批次，而批次越大越难审、越不稳定（来源7）。

### 2. 在审阅侧分级：人审风险，不审字符

- 按后果分级：涉及资金、权限、数据删除、并发、加密的代码必须人工深审；样板代码、UI 文案、测试脚手架可抽查。
- 审规格与差异，而不是审全文：先确认“它应该做什么”的规格，再看实现是否偏离。
- 让 AI 做审阅的“分诊员”：解释变更、标出可疑点、列出受影响的调用链——但结论由人下。

### 3. 用机器去“读”代码：变异测试进入代码评审

Google 把变异测试做成了代码评审的一部分：只对**本次改动的代码**生成变异体，过滤掉开发者不关心的变异，每行、每次评审限量展示。该系统覆盖超过 24,000 名开发者、1,000 多个项目；评估涉及 76 万次代码变更，从近 1,700 万个变异体中只向评审展示了约 200 万个（来源11）。另一项研究显示，被展示的变异体中有 38% 通过修改代码或增加测试得到解决；被评审者认可的变异体中，60% 得到解决（来源12）。

这是一种很好的“注意力分配”：机器从海量可能的缺陷里挑出少数“你的测试没抓住的”，人只需要回应这几个。

### 4. 让 AI 证明，而不是让人阅读

剑桥大学的 Martin Kleppmann 在 2025 年 12 月提出：**与其让人审查 AI 生成的代码，不如让 AI 证明它生成的代码是正确的**——证明检查器是一小段本身经过验证的代码，AI 编造的无效证明会被直接拒绝（来源13）。他给出的历史成本对比是：2009 年 seL4 微内核约 8,700 行 C 代码，证明其正确性用了约 20 人年、20 万行 Isabelle 证明——相当于每行实现需要 23 行证明、半个人日（来源13）。

这一方向正在变得可行。2025 年 9 月发布的“vericoding”基准包含 12,504 个形式化规格，现成大模型的成功率在 Lean 中为 27%、Verus/Rust 中为 44%、Dafny 中为 82%；纯 Dafny 验证任务的成功率在一年内从 68% 升至 96%（来源14）。

Kleppmann 同时提醒：证明自动化之后，难点转移到**规格本身是否正确**——你证明的性质是不是你真正关心的性质（来源13）。**本文分析**：这恰好把人放回了最该在的位置：人不再逐行读实现，而是读一份短得多、精确得多的规格。

## 六、重要基础设施软件，到底应该怎么测

关键基础设施（电力、通信、金融清算、交通、医疗、航空）的共同特征是：**失效后果不可接受，且难以快速回滚**。对这类软件，测试的目标不是“发现大部分缺陷”，而是“为不存在不可接受的缺陷提供充分证据”。

### 1. 先看航空业怎么做：DO-178C 与 DO-330

航空机载软件按失效后果分为 A—E 五级。A 级软件除语句覆盖和判定覆盖外，**必须达到 MC/DC 覆盖**，即证明每个条件都能独立影响判断结果（来源15）；验证活动还包括基于需求的测试、鲁棒性测试，以及与级别相称的独立性要求。

更关键的是工具鉴定。按照 DO-178C 与配套的 DO-330，如果某个工具取代、减少或自动化了保证过程，而其输出又没有被验证，就必须对工具本身进行鉴定（来源16）。工具按三类标准区分：输出成为机载软件一部分、可能引入错误的工具（标准1）；自动化验证、可能漏检错误的工具（标准2、3）。用于生成 A 级软件的工具需要最严格的 TQL-1 鉴定。

**本文分析**：把生成式 AI 放进这个框架，它属于“标准1”工具——它的输出直接成为软件的一部分。而一个非确定性、无法完整说明其需求与行为的大模型，现实中几乎不可能按 TQL-1 被鉴定。因此唯一可行的路径是：**不信任工具，而是对其输出进行与人工代码同等甚至更严格的完整验证**。这已经回答了“能不能全盘生成”的一半。

### 2. 再看 CrowdStrike 教训：配置也是代码，测试器也要被测试

CrowdStrike 事后采取的措施几乎就是一份关键系统测试清单（来源10）：

- 在编译期校验模板输入字段数量；
- 在运行时增加数组边界检查；
- 对每个字段使用**非通配**条件的自动化测试；
- 修复并扩充内容校验器自身的检查；
- 对模板实例进行模糊测试；
- 分阶段、分环发布，每一环都有观察期，并把发布控制权交给客户。

**本文分析**：这份清单的共同精神是“不要只有一道防线，而且各道防线不能共享同一个假设”。这与第四节的“去相关化”原则是同一回事。

### 3. 关键基础设施软件的纵深验证框架（本文分析）

| 层次 | 验证手段 | 生成式 AI 的角色 |
|---|---|---|
| 需求与规格 | 形式化或半形式化规格、可追溯矩阵、危害分析 | 辅助起草与一致性检查；**人定稿** |
| 设计 | 架构评审、模型检查（如 TLA+）、失效模式分析 | 生成候选不变量与反例场景 |
| 实现 | 安全编码子集、静态分析、内存安全语言、关键模块形式化证明 | 可生成候选代码与证明，**由证明检查器与人裁决** |
| 单元/集成测试 | 基于需求的测试、MC/DC、变异测试、属性测试 | 大量生成候选用例；**测试生成器不看实现** |
| 系统测试 | 差分测试（与参考实现对照）、模糊测试、故障注入、混沌工程 | 生成异常输入与故障场景 |
| 发布 | 灰度/分环发布、自动回滚、运行时监测与熔断 | 辅助异常检测，**不自动决定全量发布** |
| 运行 | 运行时断言、边界检查、审计日志、事后复盘 | 辅助日志分析与复盘归纳 |

## 七、能不能用生成式 AI 全盘生成代码？

**本文分析**：答案取决于软件的风险等级，可以分成三档。

**第一档：低风险软件——可以大比例生成。** 内部工具、原型、一次性脚本、营销页面。失效代价小、容易回滚，“生成 + 自动化测试 + 抽查”即可。

**第二档：一般业务系统——AI 生成，强验证兜底。** 电商、办公、一般业务应用。可以让 AI 承担大部分编码，但必须配套：独立于实现的测试生成、变异测试、安全扫描、小批量提交、按风险分级的人工评审。Veracode 的 45% 数据意味着，不做安全验证就上线是不可接受的（来源5）。

**第三档：关键基础设施——现阶段不应全盘生成核心代码。** 理由有三：

1. **无法鉴定**：生成式 AI 作为“输出即软件”的工具，无法满足 DO-330 这类最严格的工具鉴定要求（来源16）。
2. **无法独立**：AI 测 AI 存在同源偏差，而关键系统恰恰最依赖验证的独立性（来源1、2、3）。
3. **无法问责**：事故发生时，监管、法律和公众要求的是一条清晰的责任链，而“模型生成的”不是一个可接受的答案。

但这不等于关键系统要拒绝 AI。在关键系统里，AI 最有价值的位置是**验证侧**而非生成侧：生成海量测试候选、构造模糊测试输入、辅助写形式化证明、做静态分析告警的分诊、维护需求与测试的追溯关系。

### 一条值得押注的路线：可验证的生成

把 Kleppmann 的设想与 vericoding 的进展合在一起，可以得到一条面向关键软件的新路线（来源13、14）：

1. **人**用形式化或半形式化的语言写出规格：系统必须满足的安全性、活性和业务不变量；
2. **AI** 同时生成实现代码与正确性证明；
3. **一个小型、可信、经过验证的检查器**判定证明是否成立；
4. **人**审查的对象从数万行实现，缩小为几百行规格。

在这条路线上，AI 越“会编”越没关系——编造的证明过不了检查器。真正需要警惕的风险变成了一个：**规格写错了**。所以未来关键软件工程师最核心的能力，很可能不是写代码，而是写规格、审规格。

## 八、对银行与金融 IT 的启示（本文分析）

银行核心系统、支付清算、反洗钱与风控模型，都是事实上的关键基础设施。几点建议：

- **建立分级清单**：明确哪些系统允许 AI 大比例生成，哪些只允许 AI 参与测试与审查；把这一分级写进研发制度，而不是留给各团队自行判断。
- **把“独立验证”制度化**：AI 生成的代码，测试必须由不同来源生成，验收用例由业务与测试团队定义；禁止同一模型“自写自测自评”。
- **度量要换**：不再只看覆盖率和通过率，引入变异得分、缺陷逃逸率、变更失败率、回滚次数。
- **配置与规则即代码**：风控规则、参数表、路由配置的变更，与代码变更执行同等的测试、灰度与回滚要求——CrowdStrike 就是前车之鉴。
- **培养“规格工程师”**：投资形式化方法与属性测试能力，从清算对账、额度控制、利息计算这类规则清晰的模块开始试点。

## 九、结语

生成式 AI 让“写出代码”变得几乎免费，于是软件工程中真正稀缺的东西浮出水面：**知道什么是对的，并能证明它是对的**。测试的本质从来不是“跑用例”，而是在开发者之外建立一个独立的判断。AI 可以让这个判断更快、更全面，但不能让它不再独立。

所以，与其问“AI 能不能替代测试”，不如问：**在我的系统里，谁来当那个不会被说服的裁判？** 对普通软件，它可以是编译器、测试和抽查；对关键基础设施，它应该是规格、证明检查器，以及愿意签字负责的人。

## 常见问题

Q: 生成式 AI 能完全替代软件测试工程师吗？

A: 不能。AI 可以替代大量用例编写、执行和日志分析等体力工作，但测试的核心是独立判定“预期行为”并对上线结论负责。研究表明 LLM 生成的断言主要反映代码的实际行为而非预期行为，因此需要独立的人和确定性工具来定义与裁判正确性（来源2）。

Q: 用 AI 生成代码、再用 AI 生成测试，为什么会放大偏差？

A: 因为两者同源。Knight 与 Leveson 1986 年的实验发现，即使独立开发的 27 个程序版本，也会在相同输入上同时失效；同一个模型写代码和测试，独立性更差。LLM 读代码写测试时容易把缺陷写成断言，LLM 评审还会偏爱自己的输出（来源1、2、3）。

Q: 怎样降低“AI 测 AI”的偏差？

A: 让测试从需求而非实现生成，代码与测试使用不同模型，用编译、静态分析、属性测试、差分测试、变异测试和形式化证明等确定性方法做裁判，关键验收标准由人定义。Meta 的 TestGen-LLM 就是让 LLM 只生成候选、由确定性过滤器筛选的例子（来源4）。

Q: AI 生成的代码太多、人看不过来怎么办？

A: 在生成侧设定复杂度与变更体积预算、强制复用、小批量提交；在审阅侧按风险分级，人审规格与高风险变更；用 Google 式的增量变异测试让机器挑出测试没抓住的问题；对关键模块逐步引入形式化证明，让人只审规格（来源6、11、13）。

Q: 关键基础设施软件能用生成式 AI 全盘生成代码吗？

A: 现阶段不建议。航空标准要求 A 级软件达到 MC/DC 覆盖，且“输出即软件”的工具需要最严格的 TQL-1 鉴定，非确定性大模型难以满足；关键系统也最依赖验证独立性与清晰的责任链。AI 更适合用在测试生成、模糊测试、形式化证明辅助等验证侧（来源15、16）。

## 事实来源

1. **Knight & Leveson（1986）**（来源1）：27 个独立版本、100 万次测试、同时失效远超独立假设、最多 8 个版本同时失败。
2. **Konstantinou 等（2024/2026）**（来源2）：LLM 测试生成主要捕获实际行为；传统工具断言镜像实际行为。
3. **Panickssery 等（2024）**（来源3）：LLM 自我识别与自我偏好。
4. **Meta TestGen-LLM（2024）**（来源4）：75%/57%/25%/11.5%/73% 等数据。
5. **Veracode（2025）**（来源5）：45% 不安全实现、Java 超 70%、CWE-80 失败率 86%、模型变大未改善安全性。
6. **GitClear（2025）**（来源6）：2.11 亿行变更，重构行与复制粘贴行变化，重复块增长约 8 倍。
7. **DORA 2024**（来源7）：AI 采用率与交付稳定性、吞吐量、代码质量的关系。
8. **METR（2025、2026）**（来源8、9）：19% 变慢及其后续更新与局限。
9. **CrowdStrike 根因分析（2024）**（来源10）：21 与 20 个输入不匹配、12 个通配测试用例、校验器逻辑错误及整改措施。
10. **Google 变异测试（2021—2023）**（来源11、12）：规模与变异体解决比例。
11. **Kleppmann（2025）**（来源13）：AI 推动形式化验证主流化、seL4 成本数据。
12. **vericoding 基准（2025）**（来源14）：12,504 个规格及各语言成功率。
13. **DO-178C/DO-330 解读与 FAA AC 20-115D**（来源15、16）：MC/DC 要求与工具鉴定。
14. **CISQ（2022）**（来源17）：劣质软件成本 2.41 万亿美元。

**本文推论部分（非来源表述）**：第一节测试五要素拆解、第四节“放大循环”与“去相关化五原则”、第五节四个方向的建议、第六节第 1 条中关于生成式 AI 工具鉴定的判断及纵深验证框架、第七节三档划分与“可验证的生成”路线、第八节与结语。

**本文不构成任何工程认证、合规或投资建议；关键系统的验证方案应以所在行业的适用标准与监管要求为准。**

*（内容由AI生成，仅供参考）*