不能直接使用。 将AI生成的测试用例未经审查就投入生产，在大多数场景下是高风险的。现有研究和工业实践反复指向一个结果AI是高效的测试用例初稿生成器和思路扩展工具，但人仍是不可或缺的质量检验。

为什么不能拿来即用？

系统性遗漏业务规则：AI擅长生成看起来合理的场景（正常支付、余额不足），但难以自主推理出系统内部的状态流转、并发控制、幂等性、消息重试等深层业务。如AI可能不会想到用户连续发起两次支付请求是不是会导致重复扣款，或第三方支付成功但回调丢失时系统怎样处理。这类遗漏在格式完整的用例集中极难被察觉，却恰恰是线上故障的高发位置。

幻觉导致断言错误：LLM根据统计方式生成内容，而不是对代码语义的真正理解，因此会产生幻觉。后果是AI可能错误理解API的预期行为，生成错误的断言。意味着一个通过了执行的AI测试，实际上是在证实一个bug的存在，研究指出，在没有独立预言或人工审查的情况下，独立LLM生成的测试是不安全的。

在复杂场景和环境感知上乏力：AI在简单函数或接口测试上表现尚可，但在复杂业务场景中局限性显著。同时AI生成的测试往往缺乏环境意识，倾向于依赖文件I/O和非确定性思维，导致测试的不稳定性更高（研究显示代理生成测试的不稳定候选率为0.41，而人工测试为0.30）。虽然AI在边界条件的多样性上可能超过人类，但这并不能弥补在业务深度和环境稳定性上的缺陷。

数据佐证：可执行不等于有效：尽管部分研究报告了较高的包括率（如单元测试包括率达94%-98%）和可执行率，但另一项针对Selenium测试的研究给出了87.5%的AI生成测试是可执行的，但只有51.5%真正符合预期行为。经验也印证了批量生成的用例中，30%需要大幅修改，20%根本无法执行，真正有作用的不到一半。

那么AI用例的正确用法是什么？

尽管不能直接使用，但AI在特定步骤的作用是确定的。重点是改变使用范式：从“批量生成，直接使用”转向“准确补全，人机协同”。

让AI做它擅长的事：生成样板代码、标准CRUD接口用例、基础参数检查（空值、类型错误），以及作为思路扩展器，帮助你发现可能忽略的边界条件变体。

人类聚焦于高作用判断：将精力从编写重复用例中解放出来，投入到AI不擅长的领域：业务规则建模、复杂状态流转设计、并发和一致性场景、以及最后的质量裁决。

一套可操作的人机协作工作流流程一般包含步骤：

提供高质量上下文：不要只丢给AI一个模糊的需求标题。向其提供业务规则说明、状态机描述、相关代码片段、API文档（如OpenAPI规范）、以及历史缺陷记录。上下文的质量直接决定输出的相关性。

采用阶段生成方法：

第一阶段（AI主导）：让AI提取功能点、生成初版用例草稿，特别是正常流程和显而易见的异常分支。

第二阶段（人主导）：测试工程师进行风险分析，确定系统在并发、故障恢复、数据一致性、权限越权等方面的场景，然后定向提示AI生成补充用例。这比给我生成100条用例有效得多。

执行严格的人工复核：

业务规则：断言是不是和真实业务思路一致？AI是不是编造了不存在的规则？

重点遗漏：对照风险分析清单，并发、幂等、状态回滚等场景是不是被包括？

可维护性和稳定性：用例是不是依赖脆弱的环境假设（如硬编码途径、特定时间）？是不是存在导致Flaky的隐患？

建立反馈流程：将人工复核中发现的问题（错误的断言、遗漏的场景类型）反馈到提示词或知识库中，不断优化后续生成的质量。

AI生成的测试用例是一份有作用的初稿不是终稿。作用是扩展思路和提升编写效率，但正确性、业务相关性和稳定性必须由人类来担保。在当前技术阶段，最有效的方式是AI负责广度和速度，人类负责深度和裁决。