原文：Why AI-Assisted Development Is Raising the Value of E2E Testing（Satyam Nikhra，DZone，2026-04-23）
这篇文章回答了一个问题：AI 辅助编码时代，测试策略应该怎么调整？
作者的结论是：E2E（端到端）测试和冒烟测试的价值被低估了。不是因为它们本身变得更好用，而是因为 AI 辅助编码引入了一种新型风险，而这类测试恰好能有效应对。
传统的测试金字塔
经典的测试金字塔大家不陌生：底层大量单元测试，中间集成测试，顶层少量 E2E 或冒烟测试。这个模型成立是有原因的，E2E 测试有实实在在的成本：运行慢、容易因环境波动而失败（即 flaky test）、调试困难，因为失败可能发生在调用链的任何一层。
正因如此，业界长期以来对"大量 E2E 测试"持谨慎态度。有人用"冰淇淋蛋筒"来形容那种头重脚轻的测试结构：上宽下窄，维护成本极高。
AI 辅助编码改变了什么
AI 编码工具能显著加快写代码、重构和扩展的速度。问题不在于 AI 写的代码能不能编译通过或逻辑上是否正确。在孤立的上下文中，AI 生成的代码通常看起来没问题，甚至能通过它自己生成的测试用例。
真正的风险出现在集成层面和行为层面。
AI 生成的代码可能对 API 契约、认证流程、数据格式、事件时序、功能开关、模块间的状态流转做出错误假设。这种情况下，代码看起来没问题，单元测试也通过了，但实际的用户流程是断的。
单元测试为什么不够用
AI 工具擅长写三类代码：能通过自己生成的测试的代码、在局部上下文中看起来正确的代码、满足当前 prompt 要求的代码。
但真正的问题在于： AI 同时写实现和测试代码时，两者可能犯同样一种错 。
举个例子，AI 生成的代码可能引入这些问题：
- AI 以为模块 B 接收的是 JSON，实际上它要的是表单数据，模块间的接口约定被搞错了
- 需求说"用户点击后弹窗确认"，AI 写的是"点击后直接执行"，看似接近但行为偏了
- 改了某个函数的返回值，没注意到全局的错误处理和日志都依赖旧的返回格式，这些贯穿整个系统的公共逻辑被悄悄破坏了
如果 AI 写了实现代码又写了对应的单元测试，那测试验证的是实现是否符合 AI 自己理解的逻辑，而不是实现是否符合真实需求。两者互相通过，但都偏离了现实。
这正是单元测试的盲区：实现和测试可以"一致地错误"。
E2E 测试为什么重新变重要了
E2E 和冒烟测试的价值在于它们是 系统状态的外部验证 。它们不关心代码实现是否正确，只关心应用对真实用户是否表现正确。
这些测试更擅长捕获 AI 编码引入的那类回归：两个原本配合正常的模块改完之后接不上了（集成断裂）、功能还在但用户体验跟预期不一样了（行为不匹配）、之前能跑通的用户操作流程现在走不通了（用户流程回归）。
原文给了一个简洁的类比：单元测试验证每一块砖是否正确，冒烟测试检查墙是不是还立着。
务实的建议
作者强调，这不意味着要走向另一个极端、用 E2E 测试覆盖所有功能。那会重新制造业界早就认识到的问题。务实的做法是：
- 为 关键用户路径 写更多 E2E 测试
- 用 E2E 覆盖关键的集成接缝和业务流程
- 不要用它测每个边界情况和内部分支
- 继续以单元测试和集成测试作为覆盖面的主力
适合 E2E 覆盖的候选对象是那些对业务至关重要、出了问题会直接影响用户的流程：登录、注册、结账、支付、用户引导、账户恢复、文档上传等跨越多个系统的关键路径。
关键收获
AI 并没有让测试金字塔过时，但它提升了顶层（E2E 测试）的性价比。旧的教训是"不要在 E2E 测试上投入太多"。新的教训是"不要因为单元测试全绿就以为系统没问题，尤其是在 AI 同时帮你写了实现和测试的情况下"。
这不是要覆盖所有场景，而是用系统级的安全网保护那些最重要的用户旅程。