当 AI 开始替我们写代码，测试还像以前那样做就行了吗？

如果你最近关注过 AI 编程，大概率听过一个词——vibe coding。它不是普通的“AI 辅助编程”，而是一种更极致的开发方式：开发者用自然语言描述需求，AI 直接生成代码，然后“先跑起来，再修修补补”。甚至，很多人承认自己不再逐行审阅 AI 生成的代码，而是直接接受、运行、迭代。

听起来很爽，对吧？但问题是：质量怎么办？测试怎么做？

一场测试思维的“范式转移”

传统的软件测试，核心是 “验证我们写的代码对不对”——我们有明确的设计、可追溯的实现、清晰的架构边界。测试人员围绕这些“已知的细节”设计用例，单元测试测函数、集成测试测接口、E2E 测流程。

而 vibe coding 把这一切推倒重来。你面对的不再是自己一行行敲出来的、理解透彻的代码，而是一个“黑盒”：AI 生成的代码可能结构凌乱、逻辑诡异、甚至作者自己也解释不清它为什么能跑。这时候，测试的重心被迫从 “验证实现”转向“验证结果 + 验证风险 + 验证可维护性”。

这听起来有点抽象？我们把具体的变化拆开来看。

五大核心挑战，每一个都让你睡不着

1. 测试对象更“黑盒”了

以前测代码，你知道哪里可能有坑，因为是我们亲手挖的。现在代码是 AI 写的，它的工作方式、边界处理、异常路径你可能根本没看过。测试用例只能基于输入输出来设计，像在测一个外部服务。

后果：你很难通过“看代码”来补全测试覆盖，必须依赖更粗粒度的行为验证。

2. 回归测试和 E2E 测试变得生死攸关

AI 改代码有一个特点：快且猛。你让 AI 修一个 bug，它可能重写了半个模块；你换一个 prompt 重新生成，整个逻辑结构都变了。这种改动下，单个函数也许没错，但模块之间的拼接线、数据流转顺序，极容易出问题。

对策：局部单元测试远远不够。你需要坚固的 E2E 测试（覆盖核心用户路径）和全面的回归测试套件。每次 AI 改动后，自动跑一遍——否则“修好 A、搞崩 B”会成为日常。

3. 安全测试不再是“附加项”，是默认项

AI 生成的代码，安全习惯堪忧。它会硬编码 API key、忽略权限校验、使用有已知漏洞的依赖库，甚至写出“while(true) 调你的付费 API”这种致命逻辑。

Simon Willison 多次提醒：vibe coding 里要特别小心密钥泄露、隐私数据、按量计费风险。换句话说，你的测试流程里必须默认包含：

• 密钥扫描（CI 里自动检查）
• 依赖漏洞扫描
• 注入类攻击测试（SQL、Prompt 注入）
• 费用上限与速率限制验证

4. “能不能维护”比功能更难测

传统项目里，代码的可读性和可维护性通常由开发规范和代码审查兜底。但 vibe coding 下，代码可能迅速膨胀到连原作者都看不懂的程度。你问自己三个问题：

• 我能向别人解释这段代码在做什么吗？
• 出 bug 了我敢改吗？
• 下个迭代还能继续往上加功能吗？

如果答案是否定的，那你的测试再绿也没用——技术债务已经爆炸了。可维护性变成了一个需要被“测试”的维度，虽然它无法自动化，但你必须建立人工检查点（比如代码复杂度门禁、重构契约）。

5. 人工审查反而更省不掉

你可能以为 AI 写代码了，人工测试就可以减少。错。vibe coding 里，自动化测试能覆盖确定性行为，但语义正确性、业务合理性、长期可维护性依然需要人脑判断。IBM 的观点很明确：人类输入和监督，仍然是 AI 生成代码质量的必要条件。

所以，结对检查、上线前复核、架构走查，这些“传统动作”在 vibe coding 里反而更关键。

一份可以直接落地的测试清单

别怕，有对策。下面是一份实战版测试清单，你可以在下一个 vibe coding 项目里直接用。

① 单元测试 —— 专治 AI 的“看起来对，实际错”

• 强制测试边界条件（空值、极值、异常输入）
• 优先覆盖“你没仔细看过的函数”
• 给 AI 明确指令：“为这个函数生成包含边界条件的测试”

② 集成测试 —— 防止胶水代码拼接错误

• 测试模块间调用（API → Service → DB 全链路）
• 重点检查参数传递、异常处理、返回结构稳定性
• Mock 外部依赖，避免“假成功”

③ 端到端测试 —— 你的主防线 🔥

• 覆盖核心业务路径（用户最常用的流程，尤其是赚钱路径）
• 每次 AI 改代码后自动运行
• 工具推荐：Playwright / Cypress
• 核心原则：用户能不能用，比代码优不优雅更重要

④ 安全与风险测试 —— 默认开启 ⚠️

• 自动扫描密钥、token、敏感信息
• 测试非授权访问（越权）、注入攻击
• 设置 API 调用限额和速率限制
• 强制检查 .env 文件是否安全

⑤ 回归测试 —— 防止修 A 坏 B

• 每次改动后自动跑全部历史用例
• 每个 bug 修复必须补一个测试（否则等于没修）

⑥ 可维护性检查 —— vibe coding 特有 🧠

• 设置代码复杂度门禁（单文件行数、函数圈复杂度）
• 定期问团队：这代码我们还能继续改吗？
• 如果答案是否定的：重构，甚至重写

一个简单的思维模型

传统开发	Vibe Coding
验证代码实现	验证行为结果
单元测试优先	E2E + 回归优先
可读性默认存在	可读性需要验证
安全是补充	安全是默认
改动可控	改动不可预测

一句话策略（你可以只记住这句）

把 E2E + 回归测试当作主防线，单元测试当作辅助。

最后，别慌

vibe coding 不是要消灭测试，而是逼着我们重新思考：什么才是真正值得信赖的质量保障？

答案没有变：快速反馈、面向行为、风险驱动、人机协同。只是现在，我们需要更主动地把这些原则嵌进 AI 开发流程里。

如果你已经在用 vibe coding，不妨今天就把上面的清单打开，挑你最薄弱的一层开始加固。你的代码可以是由 AI 写的，但你的信心，必须由测试体系给。

---

欢迎留言讨论：你在 vibe coding 中遇到过什么奇葩的质量问题？