这篇继续围绕 Claude Code 展开，主题是「让 Claude Code 先写测试再改代码，成功率会高很多」。前面几篇已经讲过安装、settings.json、-p 模式和 CLAUDE.md，这次往真实使用流程里再拆细一点。
为什么 AI 改代码也需要测试
小白用 Claude Code 时，最大痛点是：它说改好了，但你不知道是不是真的好。这种「我说了算」的感觉很危险，因为模型偶尔会编出根本跑不通的代码。
解决方法不是让模型变更强，而是让你身边多一个「裁判」——这个裁判就是测试。
测试驱动的核心思路
传统 TDD 的口号是「红、绿、重构」：
- 写一个失败的测试（红）
- 写最简单的代码让它通过（绿）
- 在测试保护下重构
配合 Claude Code 时，这三步可以更朴素一点：
- 先描述你要的行为：用一句话说清楚函数应该接收什么、返回什么
- 让模型先写测试：根据你的描述，写一个最小可验证的单元测试
- 再让它改代码：让测试由红变绿
这种顺序的好处是：先写测试，模型就先有了「目标」，而不是凭印象写代码。
一个简单的例子
假设你要写一个判断邮箱合法的函数。
不要直接说「帮我写一个邮箱校验函数」。这种问法太开放，模型可能写得过于复杂。
换成：
我要一个 isValidEmail(s) 函数，规则是：必须包含 @，@ 前后都不能为空，整个字符串里不能有空格。先帮我写 5 个单元测试覆盖这些规则，再写实现让测试通过。
这样模型会按你的规则严格做。
第二个用法：用测试锁定 Bug
排查 Bug 时，同样可以走测试驱动：
- 让 Claude Code 先写一个「能稳定复现 Bug」的测试
- 确认这个测试当前是失败的
- 然后再让它改代码，让测试由红变绿
这种做法的好处是：以后这个 Bug 再也不会悄悄回来。
第三个用法：回归测试当文档
小项目常常没文档，全靠看代码理解。让 Claude Code 在写代码的同时补几条单元测试，这些测试本身就是「最忠实的文档」——因为它们和代码同步更新，比 README 更可信。
写测试时的几个小习惯
基于一般经验（不是绝对结论），让 AI 写测试时建议注意：
- 每个测试只验证一件事，不要让一个测试 assert 五条规则
- 测试名字要能读懂，比如
test_email_without_at_should_fail - 不要 mock 一切，能用真实数据就用真实数据，否则测试会沦为「测试模型自己」
- 测试要快，慢测试不会被频繁跑，跑不上的测试等于没写
常见误区
第一个误区：让模型自己决定要测什么。这样它会挑容易过的测，绕开真正容易错的部分。规则要你来定。
第二个误区：为了覆盖率而写测试。覆盖率不是目标，发现回归才是目标。
第三个误区：测试和代码一起改。如果你发现 Claude Code 在测试失败时直接去改测试而不是改代码，要立刻打住——这是它在「作弊通过」。可以在 CLAUDE.md 里写一条：「测试失败时优先修代码，不要直接改测试。」
小结
测试驱动对 Claude Code 来说，不是高门槛的工程实践，而是一种简单粗暴的「质量保险」。先写测试再改代码，AI 的乱跑空间会小很多，你的审查负担也会轻很多。
延伸阅读
如果你还没看前面的基础篇，可以先看《Claude Code 从零搭建》《settings.json 权限配置》《CLAUDE.md 项目规则》这几篇，再回来看本文会更顺。
小结
Claude Code 真正好用的地方，不是让它一次性替你完成所有事，而是把流程拆清楚：哪些让 AI 做，哪些必须人来确认，哪些结果要留下验证记录。这个习惯养成之后，它就更像一个靠谱的编程搭档。
