用 AI 做单元测试：先写行为清单，再生成可审查的测试草案

AI 写单元测试最危险的用法，是把一段代码和一句“帮我补测试”交出去，然后直接相信通过率。测试的核心不是凑覆盖率，而是把程序应该怎样表现写清楚：正常输入得到什么、边界输入如何处理、失败时如何暴露问题。AI 可以提速，但测试仍要真实运行与人工审查。

从行为清单开始，而不是从测试框架开始

先为一个小函数写下输入、输出、副作用和错误条件。把外部依赖、当前时间、随机数和网络调用单独列出，避免测试既不稳定又看不懂。只要行为边界清楚，换任何语言或测试框架都能复用同一份思考。

把模型输出当成待审查的补丁

让模型说明每个用例覆盖的行为，再由你运行测试并检查断言是否真的会失败。不要向不受控的外部服务提交密钥、生产数据或未公开代码。对于复杂逻辑，优先让 AI 列测试场景，再手写关键断言。

可直接改写的提示词

根据以下函数说明和已有代码，先列出行为清单、边界条件、错误条件与外部依赖，再生成最小化的单元测试草案。每个用例说明它验证的行为；对不确定的异常类型、框架版本或业务规则标为待确认。不得假设测试已运行、不得编造覆盖率或通过结果，也不要输出任何密钥或敏感数据。

如果你还需要把过程变成团队可复用的工作流，可阅读AI 方案优化提示词：从问题现象到可验证的改进动作。

交付前的检查

确认输入来自真实材料，检查模型是否遗漏限定条件；将结论、待确认项和下一步分开写。AI 适合加快整理与初稿，不应替代事实核对、专业判断或责任人的最终确认。