很多人第一次用 AI 编程工具，最容易兴奋的是“它真的能把功能写出来”。但真正把项目跑久一点就会发现，风险往往不在第一版代码，而在后续修改：这次修了登录，可能把导出弄坏；这次改了样式，可能让移动端按钮错位。AI编程测试要解决的，就是让 Cursor、Claude Code、Codex 不只负责写代码，也参与补测试、跑回归和记录验收。
如果你还在整理项目目录，可以先看 AI编程项目结构怎么整理。结构清楚之后，测试入口、示例数据和验收标准才容易被 AI 读懂。本文更聚焦下一步：怎样把“让 AI 写测试”变成一套可重复的工作流。
先把测试目标说清楚
不要一上来就对 AI 说“帮我写测试”。这个指令太空，AI 很容易补一堆看起来完整、其实没有命中风险点的用例。更好的做法是先给它三个边界：
- 这次改动影响哪些功能，例如登录、支付、文章发布、文件上传；
- 最怕什么结果，例如数据丢失、权限绕过、重复提交、页面空白；
- 项目现在怎么跑测试，例如
npm test、pnpm test、pytest或浏览器手动验收。
这一步和 AI编程任务说明模板 是一脉相承的。需求写清楚，AI 才知道测试不是装饰，而是为具体风险服务。
让 AI 先读代码，再列测试清单
我更推荐先让 Cursor、Claude Code 或 Codex 输出测试清单，而不是直接写文件。可以这样提问：
请先阅读这次涉及的文件和现有测试，不要修改代码。列出需要覆盖的核心路径、边界情况和回归风险，并说明哪些适合单元测试，哪些需要集成测试或手动验收。
这个步骤能帮你判断 AI 有没有真正理解项目。如果它列出的都是“正常输入、异常输入、空值”这类泛泛内容，就继续追问具体业务路径；如果它能指出某个状态、缓存、权限或异步流程容易出问题，再让它进入编码。
单元测试只覆盖稳定规则
AI 很擅长为纯函数、校验逻辑、格式转换、价格计算、权限判断生成单元测试。这类测试成本低，运行快，适合放进日常回归。你可以要求它按“正常路径、边界路径、错误路径”三类来补：
- 正常路径：输入符合预期，输出必须稳定；
- 边界路径：空数组、极大值、重复数据、中文和特殊字符；
- 错误路径：权限不足、字段缺失、接口失败、状态不允许。
但不要让 AI 把所有东西都写成单元测试。涉及真实浏览器、第三方接口、支付回调、文件系统和数据库事务时，单元测试可能只是在模拟一个不存在的世界。这时应该让 AI 说明 mock 的边界，必要时补集成测试或人工验收步骤。
回归测试要围绕“旧功能不能坏”
AI 编程最大的隐患，是它会很认真地解决当前任务，却不一定知道旧功能的优先级。所以每次改动之后，都要让它补一段回归清单。例如做一个 WordPress 发布自动化，回归清单就不只是“文章能发布”，还应该包括摘要、SEO meta、特色图 alt、正文无 h1、内链数量和标签是否正常。
老达AI博客自己的发布流程就是这样设计的，相关思路可以看 AI 自动发布 WordPress 文章完整流程，也可以在 老达AI实践专题 里看更多实际案例。
让不同工具分工，而不是重复干活
如果你同时使用多款 AI 编程工具，可以把分工拆开：
- Cursor 适合在编辑器里快速补局部测试和修正断言；
- Claude Code 适合阅读较长上下文，梳理测试计划和风险点；
- Codex CLI 适合跑命令、修失败用例、把结果整理成最终验收记录。
这和 AI代码审查工作流 可以连起来：先让 AI 补测试，再让另一个 AI 以审查者身份看测试是否真的覆盖风险。不要让同一个工具从写代码到自我证明一路到底，否则很容易只验证它自己相信的路径。
失败用例比通过用例更有价值
测试第一次跑不过，不一定是坏事。让 AI 分析失败原因时，要要求它区分三类情况：
- 业务代码确实有 bug，需要修实现；
- 测试断言写错了，需要改测试；
- 测试环境缺依赖、缺数据或命令不对，需要修运行方式。
很多 AI 生成的测试会卡在第三类问题上。这个时候不要急着删测试，而是让它把环境假设写进 README 或项目说明。后续再用 AI编程调试工作流，排查速度会明显更快。
一个可复用提示词
下面这段可以直接放进你的项目任务里：
请基于本次改动生成测试方案。先阅读相关代码和现有测试，列出核心路径、边界路径和回归风险；再补最小必要测试，不要为了覆盖率堆无效用例；运行项目已有测试命令；如果失败，请区分实现问题、测试问题和环境问题；最后输出修改文件、测试命令、通过情况和仍需人工验收的项目。
这套方法的重点不是把测试全交给 AI，而是让 AI 把“风险识别、用例补齐、命令执行、结果记录”这几个重复环节承担起来。对个人站长、小团队和独立开发者来说，只要每次改动都留下可回归的测试记录，AI 编程就会从“快但心虚”变成“快而可控”。更多工具选择可以继续看 AI编程工具专题。
