AI 写的代码怎么测试？2026 实操指南

AI 现在写代码很快，一句话就能生成几百行。但快出来的代码到底对不对，光看是看不出来的——尤其当你自己并不完全懂那段逻辑的时候。所以 AI 写的代码怎么测试，本质上是在问一件事：你凭什么相信这段不是你写的代码？答案不是「再让 AI 检查一遍」，而是建立一套能自动跑、能反复跑、失败了会拦住你的验证机制。这篇文章讲清楚测试策略怎么分层、AI 生成测试的典型翻车姿势、以及一套可以直接抄的命令和提示词。

为什么 AI 写的代码更需要测试

传统开发里，你写的每一行都在自己脑子里过了一遍，心里大概知道哪里脆。AI 写的代码不一样：它读起来通顺、结构完整、命名规范，看上去比很多人手写的还漂亮，但边界条件、空值处理、并发时序这些地方可能藏着你根本没意识到的坑。更麻烦的是「幻觉式正确」——AI 调用了一个不存在的方法名，或者用了某个库三年前的 API，代码在编辑器里看着毫无问题，一跑才炸。

所以 AI 编程时代的测试，角色变了。它不再只是「防止以后改坏」的回归网，而是你验收 AI 产出的唯一客观标准。你可以不逐行读懂那 300 行实现，但你必须读懂那 20 行测试——测试是你和 AI 之间的验收合同。

三层验证：不是所有代码都要写单元测试

别一上来就追求 100% 覆盖率，那是给自己找罪受。按投入产出比，AI 生成的代码分三层来验证：

一个实用的判断标准：如果这段代码错了，你会亏钱、丢数据、或者被用户投诉——那就写测试。如果只是页面上某个按钮颜色不对，肉眼看一眼就行。样板代码、纯配置、简单的 CRUD 转发层，写测试的收益很低。

AI 生成测试的 5 个典型翻车姿势

直接跟 AI 说「给这个文件写测试」，它十有八九会交出一堆看起来很丰满、实际上什么都没验证的代码。最常见的五种：

1. 1只测 happy path：全是「正常输入 → 正常输出」，一个空值、负数、超长字符串、并发调用都没有。而线上出事的永远是这些。
2. 2过度 mock：把所有依赖全 mock 掉，最后测的是「我 mock 的东西返回了我 mock 的值」，真实业务逻辑一行没跑到。典型症状是测试文件里 mock 的行数比断言还多。
3. 3同义反复断言：期望值写成 assert result == calculate(x)，用被测函数自己算出期望值。这种测试永远通过，哪怕逻辑全错。期望值必须是你手算或从需求里抄来的常量。
4. 4跟着 bug 走：你说「把这个失败的测试修好」，它直接改测试的断言去迁就错误的实现。测试绿了，bug 还在。
5. 5用例互相污染：共享全局变量、依赖执行顺序、往真实数据库里写数据又不清理。单跑能过，一起跑就随机失败。

正确姿势：先写测试，再让 AI 写实现

Anthropic 在 Claude Code 的最佳实践里，把测试驱动开发（TDD）列为和智能体协作最有效的模式之一。原因很简单：先有测试，AI 就有了明确、可自动判定的目标，它可以自己反复跑、自己改，直到全绿——你只需要在开头把「什么算对」定义清楚。注意 AI 默认习惯是先写实现再补测试，想走 TDD 必须显式要求。

1. 1先描述需求，让 AI 只写测试，并明确告诉它「现在还没有实现，不要写实现代码」。
2. 2自己审一遍测试：期望值对不对？边界情况全不全？这一步不能省，这是你唯一必须读懂的代码。
3. 3跑一次，确认测试是失败的。如果一上来就通过，说明它根本没测到东西。
4. 4把这些失败的测试先提交到 Git，做一个快照。
5. 5再让 AI 写实现，要求「不许修改测试文件，改到全部通过为止」。
6. 6全绿之后 git diff 看一眼测试文件有没有被偷偷改过。

# 第 3 步：确认测试确实是红的
pytest tests/test_pricing.py -v

# 第 4 步：把失败的测试先存档，这是你的安全绳
git add tests/test_pricing.py
git commit -m "test: 定价规则验收测试（实现尚未完成）"

# 第 6 步：AI 说做完之后，检查它有没有动过测试
git diff HEAD~1 -- tests/

常用测试命令速查

Python 项目用 pytest，前端 / Node 项目用 vitest，这两套目前最省心。把下面的命令直接丢给 AI，让它按这个跑：

# ---- Python: pytest ----
pip install pytest pytest-cov

pytest                                   # 跑全部
pytest tests/test_order.py               # 跑单个文件
pytest tests/test_order.py::test_refund  # 跑单个用例
pytest -x                                # 第一个失败就停
pytest -k "refund and not slow"          # 按名字筛选

# 覆盖率：term-missing 会直接列出哪几行没被覆盖
pytest --cov=myapp --cov-report=term-missing --cov-branch
pytest --cov=myapp --cov-report=html     # 生成 htmlcov/index.html

# ---- 前端 / Node: vitest ----
npm i -D vitest @vitest/coverage-v8

npx vitest run                  # 跑一次（CI 用这个）
npx vitest                      # watch 模式，改文件自动重跑
npx vitest run --coverage       # 带覆盖率
npx vitest run src/utils        # 只跑某个目录

覆盖率怎么看才不自欺欺人

覆盖率是个特别容易被误用的指标。它只能告诉你「哪些代码一次都没跑到」，不能告诉你「跑到的部分测对了没有」。一个把所有断言删光的测试套件，覆盖率照样很好看。

• 记得加 --cov-branch 开分支覆盖。只看行覆盖率的话，一个 if/else 只走了一半也可能显示 100%。
• 重点看 term-missing 列出来的未覆盖行号，逐个问自己：这行是不是错误处理？错误处理恰恰是最该测的。
• 别追求全局 100%。核心业务模块（算钱、权限、数据转换）尽量高，胶水代码和配置文件直接排除掉。
• 覆盖率只做趋势参考：新提交把它拉低了要问一句为什么，而不是设个硬指标逼大家凑数——凑数的结果一定是没有断言的假测试。

挂到 CI：让测试自动跑，而不是靠自觉

本地跑测试全靠自觉，而自觉是最不可靠的东西。把测试挂到 GitHub Actions，每次 push 和 PR 自动跑一遍，失败了直接拦住合并。文件放在 .github/workflows/test.yml：

name: test
on: [push, pull_request]

jobs:
  pytest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt pytest pytest-cov
      - run: pytest --cov=myapp --cov-report=term-missing

可以直接抄的提示词

写测试这件事，提示词质量直接决定产出质量。下面这段把前面所有的坑都堵上了，改改路径就能用：

请为 src/pricing.py 里的 calculate_final_price 函数写单元测试，用 pytest。

要求：
1. 现在只写测试，不要写任何实现代码，也不要修改被测文件。
2. 每个用例的期望值必须是手写的常量，禁止调用被测函数来生成期望值。
3. 必须覆盖：正常输入、边界值（0、负数、最大值）、空值/None、
   类型错误的输入，以及需求里写明的每一条特殊规则。
4. 不要 mock 纯计算逻辑。只有涉及数据库、网络、当前时间、随机数时才 mock。
5. 用例函数名要能说清它在验证什么，例如
   test_vip_discount_not_applied_when_order_below_threshold。
6. 用例之间必须互相独立：不依赖执行顺序，不共享可变全局状态。

写完先告诉我你打算分成哪几组用例，我确认后再落文件。

到了实现阶段，提示词要反过来强调约束：「只改实现，不许动 tests/ 目录下的任何文件，反复跑 pytest 直到全部通过」。这一句能挡掉大部分「改测试迁就实现」的情况。

测试是 AI 编程里最容易被跳过、也最能拉开差距的一环。会用 AI 快速产出代码的人越来越多，能让产出稳定到敢交付的人依然稀缺，差别就在于有没有一套属于自己的验证机制。IMAI 的实战课程会把测试、部署、排错这些「写完之后」的环节完整走一遍，帮你从「能做出来」进阶到「敢交付」。