经典的测试金字塔大家不陌生：底层大量单元测试，中间集成测试，顶层少量 E2E 或冒烟测试。这个模型成立是有原因的，E2E 测试有实实在在的成本：运行慢、容易因环境波动而失败（即 flaky test）、调试困难，因为失败可能发生在调用链的任何一层。

正因如此，业界长期以来对"大量 E2E 测试"持谨慎态度。有人用"冰淇淋蛋筒"来形容那种头重脚轻的测试结构：上宽下窄，维护成本极高。

AI 编码工具能显著加快写代码、重构和扩展的速度。问题不在于 AI 写的代码能不能编译通过或逻辑上是否正确。在孤立的上下文中，AI 生成的代码通常看起来没问题，甚至能通过它自己生成的测试用例。

真正的风险出现在集成层面和行为层面。

AI 生成的代码可能对 API 契约、认证流程、数据格式、事件时序、功能开关、模块间的状态流转做出错误假设。这种情况下，代码看起来没问题，单元测试也通过了，但实际的用户流程是断的。

AI 工具擅长写三类代码：能通过自己生成的测试的代码、在局部上下文中看起来正确的代码、满足当前 prompt 要求的代码。

但真正的问题在于： AI 同时写实现和测试代码时，两者可能犯同样一种错 。

举个例子，AI 生成的代码可能引入这些问题：

• AI 以为模块 B 接收的是 JSON，实际上它要的是表单数据，模块间的接口约定被搞错了
• 需求说"用户点击后弹窗确认"，AI 写的是"点击后直接执行"，看似接近但行为偏了
• 改了某个函数的返回值，没注意到全局的错误处理和日志都依赖旧的返回格式，这些贯穿整个系统的公共逻辑被悄悄破坏了

如果 AI 写了实现代码又写了对应的单元测试，那测试验证的是实现是否符合 AI 自己理解的逻辑，而不是实现是否符合真实需求。两者互相通过，但都偏离了现实。

这正是单元测试的盲区：实现和测试可以"一致地错误"。

E2E 和冒烟测试的价值在于它们是 系统状态的外部验证 。它们不关心代码实现是否正确，只关心应用对真实用户是否表现正确。

这些测试更擅长捕获 AI 编码引入的那类回归：两个原本配合正常的模块改完之后接不上了（集成断裂）、功能还在但用户体验跟预期不一样了（行为不匹配）、之前能跑通的用户操作流程现在走不通了（用户流程回归）。

原文给了一个简洁的类比：单元测试验证每一块砖是否正确，冒烟测试检查墙是不是还立着。

作者强调，这不意味着要走向另一个极端、用 E2E 测试覆盖所有功能。那会重新制造业界早就认识到的问题。务实的做法是：

• 为 关键用户路径 写更多 E2E 测试
• 用 E2E 覆盖关键的集成接缝和业务流程
• 不要用它测每个边界情况和内部分支
• 继续以单元测试和集成测试作为覆盖面的主力

适合 E2E 覆盖的候选对象是那些对业务至关重要、出了问题会直接影响用户的流程：登录、注册、结账、支付、用户引导、账户恢复、文档上传等跨越多个系统的关键路径。

AI 并没有让测试金字塔过时，但它提升了顶层（E2E 测试）的性价比。旧的教训是"不要在 E2E 测试上投入太多"。新的教训是"不要因为单元测试全绿就以为系统没问题，尤其是在 AI 同时帮你写了实现和测试的情况下"。

这不是要覆盖所有场景，而是用系统级的安全网保护那些最重要的用户旅程。