m.8方法⏱ 约 6 分钟

测试思维:让 AI 写测试并验证

用"自动检查"代替"肉眼觉得对"

🔎 最后验证 2026-05📚 来源:《AI编程实战三卷书》卷二🧰 Claude Code✅ 117 人学过👁 224 次阅读

为什么学这个

"我跑了一下,看起来没问题"——这是 AI 时代最危险的一句话。肉眼能验证的太有限了。这一节引入一种系统武器:测试。它让"对不对"有了自动、可重复的答案,是把 AI 代码从"能跑"推向"靠谱"的关键。

💡 打个比方

测试就像给产品装一排自动质检探头:每次改动后,按一下,所有探头同时检查"功能还正常吗"。靠人一个个手点,既慢又会漏;探头自动跑一遍,几秒就告诉你"哪里坏了"。

测试= 一段"用来检查另一段代码对不对"的代码,可反复自动运行
为什么对 AI 协作特别重要:
- AI 改 A 可能弄坏 B(回归),肉眼根本盯不过来;测试能自动抓出来
- 它把"对不对"从主观感觉,变成客观、可重复的结果
好用的做法:
- 让 AI 既写功能、也写对应的测试:"实现 X,并写几个测试覆盖正常和异常情况"
- 改完跑测试:全绿才算数,有红的就让它修
- 你来检查"测试本身合不合理"(别让它写假测试,见下方避坑)
⚠️ 但全绿 ≠ 没 bug:测试只能证明你写到的那些情况没问题,没覆盖的路径照样可能出错。绿灯是"没发现已知问题",不是"保证没问题"。另外,如果让同一个 AI 既写代码、又定测试的预期答案,它一旦理解错需求,会写出"错代码 + 自洽的错测试"一起变绿——所以关键用例的预期结果最好由你独立确定(手算/需求给定),别让它自说自话。

❓ 测验

为什么说测试对'和 AI 协作'尤其重要?

⚠️ 避坑警惕 AI 写'永远通过的假测试'

AI 有时会写出看着在测、其实测了个寂寞的测试(比如断言 1 === 1,或刚好顺着 bug 写),让你误以为"全绿=没问题"。所以你要审查测试本身:它真的在验证关键行为吗?让它"测正常情况也测异常/边界",并自己看一眼测试逻辑。这是 P4-B 陷阱里专门有一条的(测试造假)。

🤖 让 AI 带测试地实现功能

请实现【某功能】,并为它写几个测试:至少覆盖 1 个正常情况、1 个空/边界输入、1 个异常输入。写完后:1) 把测试逻辑用中文解释给我,确认它真在验证关键行为;2) 运行测试,把结果告诉我。如有失败,先分析原因再修。

🔎 来源与核验· 1 条,点开核对

本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。

「为 AI 生成的功能补充测试,可自动验证正确性并捕获回归」

你会看到:改坏了,测试立刻变红、精确指出哪条不对;而如果你只靠"肉眼跑一下看起来没问题",这种错根本发现不了。

为什么:"我跑了一下,看起来没问题"是 AI 时代最危险的一句话——肉眼能验证的太有限。测试让"对不对"有了自动、可重复的答案。

✅ 小结

你有了测试这件武器。可即使有测试,bug 还是会出现。下一节把 P3 的"用 AI 调试"升级成一套系统方法论,让你面对任何 bug 都不慌。

下一节 → 调试方法论:复现→定位→最小化→修复

都看到这了，打个赏呗！