Free Preview
先试读：Claude Code 修测试报错：先复现，再判断责任
测试报错很容易让人焦虑，尤其是输出一大串红色日志的时候。很多人会把整段报错丢给 Claude Code，说“帮我修”。这确实可能成功，但成功率不稳定，因为 AI 还不知道这个失败是在什么命令、什么环境、什么测试用例下出现的。
更稳的方式，是先让 Claude Code 识别测试命令，然后只运行最小范围的测试。比如模拟项目里全量测试很慢，但失败发生在 membership.test.ts，那就先复现这一个文件，而不是每次都跑全量。
这篇能解决什么问题
- 把一句模糊需求改成 AI 能执行、你能验收的任务卡。
- 知道执行前要先检查哪些文件、风险点和验证命令。
- 避免 AI 顺手改无关内容，最后只交付可审、可回退的改动。
付费后能看到哪些内容
- 测试失败时，第一件事不是改代码，而是复现同一个失败
- 错误栈不是从上到下全读，而是找第一处属于项目的线索
- 一次只盯一个失败，不要把所有红色日志混在一起修
- 不是所有测试失败都说明代码错了，也不是所有测试都能随便改
可以先照着试的一句话
这是我要改的功能：___。请先阅读项目结构，列出会动哪些文件、风险点和验证命令；等我确认范围后，再开始做最小改动。
试读到这里先判断是否对你的任务有用；完整文章会继续展开步骤、案例、模板和避坑细节。
测试失败时，第一件事不是改代码，而是复现同一个失败
如果失败不能稳定复现，任何修复都可能只是碰巧。
测试报错很容易让人焦虑，尤其是输出一大串红色日志的时候。很多人会把整段报错丢给 Claude Code，说“帮我修”。这确实可能成功，但成功率不稳定，因为 AI 还不知道这个失败是在什么命令、什么环境、什么测试用例下出现的。
更稳的方式，是先让 Claude Code 识别测试命令，然后只运行最小范围的测试。比如模拟项目里全量测试很慢，但失败发生在 membership.test.ts，那就先复现这一个文件，而不是每次都跑全量。
请先只定位测试失败，不要修改文件。
我需要你：
1. 找出这个项目的测试命令
2. 判断能否只运行失败的测试文件或测试用例
3. 复述失败信息：测试名、期望值、实际值、错误栈第一处项目代码
4. 输出你认为最可能相关的文件
限制：
- 不要先改代码
- 不要删除或跳过测试
- 不要为了通过测试而降低断言标准错误栈不是从上到下全读，而是找第一处属于项目的线索
很多错误栈前几行是测试框架或依赖库，真正要看的通常是项目文件。
假设测试输出里出现很多 node_modules、vitest、jest 或浏览器运行时信息，不代表这些地方就是问题。你要让 Claude Code 找“第一处项目代码路径”。例如 src/lib/permission.ts、src/pages/account.tsx、tests/membership.test.ts 这种路径更有价值。
| 日志内容 | 怎么判断 | 下一步 |
|---|---|---|
| 期望 true，实际 false | 多半是业务条件或测试数据不匹配 | 看输入数据、权限条件、返回值计算 |
| 找不到元素 | 可能是文案变了、DOM 结构变了、异步没等到 | 检查页面渲染和测试选择器 |
| 模块无法导入 | 可能是路径、构建配置、导出方式变化 | 检查 import/export 和别名配置 |
| 超时 | 可能是异步流程、网络 mock、定时器或等待条件 | 缩小异步链路，确认 mock 是否生效 |
一次只盯一个失败，不要把所有红色日志混在一起修
全量测试失败可能有很多连锁反应，先抓住最小的第一处失败。
如果一个改动导致 12 个测试失败，真实原因可能只有 1 个。比如一个权限函数返回值变了，所有依赖它的页面测试都会失败。Claude Code 应该先帮你找“源头测试”，而不是逐个修 12 个断言。
不是所有测试失败都说明代码错了，也不是所有测试都能随便改
关键是判断产品行为有没有变，测试是不是还在表达正确规则。
测试失败通常有三种情况：代码真的错了、测试跟不上新需求、测试本身写得不稳定。Claude Code 需要帮你判断属于哪一种，而不是为了让测试变绿就改断言。
代码错
需求没变，测试表达的规则仍然正确，但实现返回了错误结果。
测试该更新
需求已经明确变了，旧断言还在检查旧规则，需要同步测试。
测试不稳定
依赖时间、随机数、外部网络、异步等待，导致结果时好时坏。
把失败测试删掉、把断言改得更宽、把错误吞掉、跳过整组测试，这些都不是真正修复。除非你清楚说明需求变化，否则不应该为了“变绿”牺牲测试价值。
最小修复之后，要跑相关测试，而不是只跑刚才那一个
测试修复完成的标准，是相关路径都能证明没有退化。
当 Claude Code 找到原因后，修复仍然要控制范围。比如模拟项目里会员权限判断少考虑了“权限未过期但用户状态延迟加载”的情况，修法应该集中在权限判断或加载状态处理，而不是重写整个会员模块。
先跑失败测试
证明最小失败用例已经修复。
再跑相关测试
比如同一模块、同一页面、同一权限路径的测试。
最后跑关键全量
如果项目允许，跑完整测试或至少跑构建命令。
输出剩余风险
哪些没跑、为什么没跑、上线前需要人工验证什么。
一套完整的修测试提示词
把测试失败交给 Claude Code 时，最重要的是让它按顺序工作。
请帮我修复模拟项目里的测试失败，按阶段执行。
阶段 1：复现
- 找到测试命令
- 单独运行失败测试
- 复述失败测试名、期望值、实际值、第一处项目代码路径
阶段 2：定位
- 找最小失败用例
- 判断是实现错误、测试需要更新，还是测试不稳定
- 不要先修改文件
阶段 3：修复
- 只做最小必要修改
- 不删除测试，不跳过测试，不降低断言标准
- 说明为什么这样改
阶段 4：验证
- 跑失败测试
- 跑相关测试
- 说明哪些验证已完成，哪些仍需人工复查- 先稳定复现同一个失败。
- 从错误栈里找到第一处项目代码。
- 定位最小失败用例，不被连锁失败干扰。
- 判断代码错、测试该更新，还是测试不稳定。
- 最小修复后跑相关测试，并说明剩余风险。