用 Cursor、Claude Code、Codex 改代码时，很多人已经习惯让 AI 先读项目、写方案、修改文件。但最后一步经常被忽略：改完以后到底跑了哪些检查？如果只是听 AI 说“已完成”，上线风险还是留在你这里。
AI 编程测试自动化要解决的不是“多写几个测试用例”，而是把改动后的验证动作固定下来：哪些命令必须跑，哪些页面必须看，哪些失败要回滚，哪些结果要写进交接记录。这样 AI 才不是只会写代码，而是能进入可交付流程。
如果你还在搭基础流程，可以先看 AI编程工具专题 和 AI智能体与自动化专题。站内的 AI编程测试怎么做 偏测试用例设计，本文更聚焦“让 AI 改完后自动执行检查”。
先把测试自动化拆成四层
不要一上来就要求 AI “全面测试”。这个指令太虚，最后很容易变成泛泛检查。更稳的做法，是把验证分成四层：
- 静态检查：lint、format、typecheck，先发现低级语法和类型问题。
- 单元测试：验证函数、组件、工具方法和边界条件。
- 集成测试：验证接口、数据库、缓存、权限和关键流程能连起来。
- 页面验收：用浏览器或截图确认真实页面没有视觉、交互和文案问题。
这四层不一定每次都全跑。小文案修改可能只需要静态检查和页面预览；支付、登录、权限、发布流程这类高风险改动，就应该至少跑到集成测试和页面验收。
第一步：让 AI 先识别项目里的现有命令
很多失败不是代码写错，而是 AI 猜错测试命令。比如项目实际用 pnpm test，它却跑 npm test；项目有 npm run typecheck，它只跑了 npm run build。
建议先给 Cursor、Claude Code 或 Codex 一个只读指令：
请先只读取项目配置，不要修改文件。
找出 package.json、README、CI 配置或项目文档里的验证命令。
按静态检查、单元测试、集成测试、构建、页面验收五类列出来。
如果没有明确命令，请说明缺口，不要自行猜测。这一步和 AI编程项目规则分层 很像：先把项目已有规则找出来，再让 AI 执行。不要把测试命令全靠临时聊天补充。
第二步：按改动类型选择最小检查集
测试自动化不是每次都跑最重流程，而是根据风险选择最小可接受检查集。可以把任务分成三档：
- 低风险：文案、样式、小组件展示。至少跑 lint 或格式检查，再做页面预览。
- 中风险：表单、列表、搜索、上传、数据展示。至少跑 typecheck、相关单测和页面验收。
- 高风险：登录、权限、支付、发布、数据库迁移、后台任务。必须跑完整测试、构建、关键流程回归和回滚说明。
如果你已经有 AI编程验收清单，可以把这三档直接写进去。之后每次让 AI 改代码，都让它先判断任务属于哪一档，再执行对应命令。
第三步：把测试命令写进项目规则
临时提醒 AI 跑测试，很容易漏。更好的办法是把命令写进项目规则，比如 AGENTS.md、CLAUDE.md、Cursor Rules 或 Codex 项目说明：
验证要求：
- 修改 TypeScript 代码后，优先运行 npm run typecheck。
- 修改业务逻辑后，运行 npm test -- --runInBand。
- 修改页面或组件后，运行 npm run build，并检查相关页面。
- 如果命令失败，不要继续扩大修改范围，先总结失败原因和下一步建议。
- 最终回复必须列出已运行命令、结果、未运行原因和残余风险。这段规则不追求复杂，关键是可执行。AI 每次都能看到同一套要求，就比你每次临时说“记得测试一下”可靠得多。
第四步：让 AI 输出可复核的测试报告
测试自动化的结果不能只写“已通过”。你需要知道它到底跑了什么、覆盖了什么、没覆盖什么。可以要求 AI 最终按固定格式交付：
测试结果：
- npm run typecheck：通过 / 失败，关键输出：
- npm test：通过 / 失败，覆盖范围：
- npm run build：通过 / 失败，关键输出：
- 页面验收：检查了哪些 URL 或截图：
- 未执行项：原因是什么：
- 残余风险：上线前还需要人工看什么：这对团队协作尤其重要。下一位接手的人不需要重新猜 AI 做过什么，只要看这份报告，就能知道当前改动是否可以继续推进。
第五步：失败时不要让 AI 盲目重试
很多 AI 编程事故发生在测试失败之后。AI 可能为了让测试变绿，顺手删断言、放宽校验、注释掉失败用例，表面上通过了，实际风险更大。
建议给失败处理加一条硬规则：
如果测试失败：
1. 先解释失败原因和相关文件；
2. 不要删除测试或降低断言；
3. 不要扩大修改范围；
4. 给出一个最小修复方案；
5. 等确认后再修改。这和 AI编程 Bug 复现报告 的思路一致：先把问题复现清楚，再修。自动化不是为了让 AI 更快乱改，而是为了让失败也可控。
适合直接复制的完整提示词
下面这段可以用于 Cursor、Claude Code、Codex 的测试自动化任务：
请为当前改动执行 AI 编程测试自动化检查。
要求：
1. 先读取项目配置，确认真实可用的 lint、typecheck、test、build 命令。
2. 根据本次改动范围判断风险等级：低 / 中 / 高。
3. 选择对应的最小检查集，不要自行发明不存在的命令。
4. 如果命令失败，先报告原因，不要删除测试或放宽断言。
5. 最终输出已运行命令、结果、未运行原因、残余风险和建议的人工验收点。
请先给出检查计划，等我确认后再执行。如果你希望 AI 直接执行，也可以把最后一句改成“请直接执行检查，并在每一步失败时停止”。但涉及生产数据、付费接口、真实发布和服务器操作时，仍然建议保留人工确认。
哪些项目最值得先做测试自动化
并不是所有个人项目都要一开始就做完整 CI。最值得优先做的是这几类：
- 经常被 AI 修改的代码库；
- 有登录、权限、支付、发布、表单提交等关键流程的项目；
- 多人协作或经常切换工具的项目；
- WordPress 主题、自动化脚本、内容发布流程这类容易影响 SEO 和线上展示的项目。
老达自己维护博客时，AI 不只写正文，也会改脚本、发布文章、生成图片和做 SEO 检查。越是这种跨步骤流程，越需要测试自动化把风险收住。你可以结合 AI自动发布 WordPress 文章流程 看，发布前后都应该有固定检查。
最后：让 AI 负责执行，让规则负责边界
AI 编程测试自动化的核心，不是把所有测试都交给 AI 决定，而是你先定义边界、命令和验收格式，再让 AI 稳定执行。工具会变，Cursor、Claude Code、Codex 的能力也会继续升级，但“改完必须可验证”这条规则不会过时。
如果你现在还没有测试流程，先从三件事做起：找出真实命令，写进项目规则，让 AI 每次输出测试报告。做到这一步，AI 编程就会从“看起来改好了”，逐步变成“能解释、能复核、能交付”。
延伸阅读
- AI编程工具专题：继续查看 Cursor、Claude Code、Codex 的实战流程。
- AI智能体与自动化专题：理解工具调用、人工确认和自动化边界。
- AI编程测试怎么做：学习如何让 AI 写出能回归的测试用例。
- AI编程验收清单怎么写：把测试结果接进最终交付标准。
