AI编程第三篇：TDD让你安心让AI写代码
AI为你生成了一段登录代码。
你快速浏览，逻辑看似没问题。但盯着屏幕，脑海中却冒出各种疑问：密码为空怎么办？用户不存在怎么办？邮箱格式错误怎么办？
你不清楚——AI只提供了代码，没说明它如何验证的。
最终你还是打开测试环境，手动输入各种边界情况逐一测试。半小时过去了，你才敢提交这段本该3分钟完成的代码。
问题不在于AI写得不好，而在于它给你的是“无防护”的代码——没有验证、没有保障、你不知道它是否正确。
上一篇我介绍了SDD（规格驱动开发）如何用规格控制“AI写什么”。但即使有了规格，你得到的依然是裸代码——你不知道AI自己是否验证过。
今天我想探讨的是：让AI按照TDD流程工作，给你的不再是裸代码，而是“自带验证”的代码。
许多人使用AI写代码的流程如下：
1. 给AI一段需求描述 2. AI返回代码 3. 你盯着代码仔细检查 4. 手动测试几个场景 5. 提交（但心里没底）
AI的产出是“黑盒验证”的。
AI写代码时，它究竟考虑了哪些场景？
正常情况？考虑到了。
边界情况？可能考虑到了。
异常情况？不一定。
极端情况？谁知道呢。
你得到的只有结果，没有它的验证过程。
就像学生交作业只写答案不写解题步骤，你得倒推他是如何计算的——费时费力，还不一定能发现错误。
更麻烦的是，即使AI写对了，你也很难确认它是对的。
人类写代码时，你能从代码结构、命名、注释中看出思路。但AI生成的代码往往是“突然冒出来”的——逻辑跳跃、结构紧凑、你懂每一行但看不清整体。
你花费的时间不是在找Bug，而是在说服自己“这代码应该没问题”。
AI不负责验证，验证成本全部落在你身上——你得构思测试场景、手动执行测试、确认边界覆盖，出了问题还得你背锅。
这就是你不敢放手的原因——不是AI写得不好，而是它给你的产出没有任何质量保证。
小结：AI直接写代码的问题：黑盒验证、难以确认、验证成本高。
解决办法不是“更仔细地审查代码”，而是改变AI的工作流程。
与其让AI直接写代码，不如让它先写测试用例，再写代码通过测试——这就是TDD（测试驱动开发）。
传统方式： 需求 → AI写代码 → 你盯着看半小时 → 手动测试 → 提交（忐忑）
TDD方式： 需求 → AI列测试用例 → AI写代码通过测试 → 你审查测试覆盖 + 代码质量 → 提交（有底气）
核心区别：AI给你的是“已测试通过”的代码，不是“不知道对不对”的裸代码。
假设你要让AI实现一个“计算订单折扣”的函数。
传统方式：
你：帮我写一个计算订单折扣的函数，会员打9折，VIP打8折 AI：[给你一堆代码] 你：嗯……看起来没问题……但是订单不存在怎么办？订单金额是0呢？负数呢？
TDD方式：
你：帮我写一个计算订单折扣的函数，会员打9折，VIP打8折。先列测试用例。 AI：
测试用例1：普通用户，订单100元 期望：折扣后100元（无折扣）
测试用例2：会员用户，订单100元 期望：折扣后90元
测试用例3：VIP用户，订单100元 期望：折扣后80元
测试用例4：订单金额为0 期望：折扣后0元
测试用例5：用户类型未知 期望：按普通用户处理
你：等等，订单金额是负数怎么办？加一个用例。 AI：好的，补充：
测试用例6：订单金额为负数 期望：抛出“订单金额不能为负”异常
现在写代码…… [代码] ……所有测试通过。
TDD方式下，你在代码生成前就能看到AI的思考过程（测试用例）。
你可以在它写代码前补充遗漏的场景，而不是写完代码后再返工。
有了测试后，你的人工审查就不用再纠结“对不对”了，而是聚焦在：
-测试用例覆盖是否完整：AI列的这些场景够不够？有没有遗漏的边界情况？ -代码质量如何：命名清不清晰、结构合不合理、好不好维护
“对不对”交给测试，“好不好”交给人。这才是合理的分工。
小结：TDD让验证过程透明化，你的审查重点从“对错”转向“完整性和质量”。
采用TDD流程后，你会发现“敢不敢用AI代码”这件事的心理负担明显降低了。
以前AI给你的是裸代码，像个半成品——能不能用你得自己验证。
现在AI给你的是“测试通过的代码”，像个成品——基本功能已经验证过了。
你看到的不是“不知道对不对的代码”，而是“已经跑通测试的代码”。
这种心理差异很大。就像你网购，收到的是“已通过质检”的商品 vs “未经检验”的商品，你的信任度完全不同。
以前你得自己想测试场景、自己手动测、自己确认覆盖——全流程验证。
现在AI已经完成了基础验证，你只需要：
- 抽查测试用例是否完整（看列表就行） - 补充AI遗漏的边界场景（如果有） - 审查代码质量（命名、结构、可维护性）
验证模式从“全面验证”变成“抽查验证”。
举个例子：AI列了8个测试用例并全部通过，你扫一眼发现“并发场景”没考虑，你让AI补一个并发测试——10秒搞定。
而以前，你得自己写并发测试、自己跑、发现Bug、让AI改、再测——循环好几轮。
以前你既要验证正确性（但验证不出来），又要审查质量（但没时间细看）——两头不讨好。
现在你的角色清晰了：你是质量审查者，不是验证执行者。
AI负责：写测试 → 写代码 → 跑测试
你负责：审查测试覆盖 + 审查代码质量
这才是人和AI的合理分工——AI做机械化验证（它擅长的），人做判断和决策（人擅长的）。
你不再盯着代码发呆想“这代码对不对”，而是快速扫一眼测试用例想“这覆盖全不全”。
后者的效率是前者的10倍。
小结：TDD带来三个收益：产出自带验证、验证成本降低、人机分工清晰。
回到开头那个场景：AI给了你代码，你盯着看半小时，还是不敢提交。
问题不在AI能力，在于你和AI的协作方式。
如果你让AI直接写代码，它给你的就是裸产出——你得花大量时间验证。
如果你让AI按TDD流程工作，它给你的是自带验证的产出——你只需要抽查和审核。
AI会越来越强，但无论它多强，它产出的代码都需要你敢用才有价值。
下次让AI写代码时，加一句话：
“先写测试用例，再写代码。”
六个字，决定了你拿到的是裸代码，还是带保障的代码。
你会发现：
- AI的思考过程透明了（你看得见测试用例） - 你的验证成本降低了（不用从头全测） - 你的信心提升了（看到“测试通过”就敢用）
TDD不只是人的开发方法论，也是AI的工作流程。
让AI按TDD工作，不是给它加限制，而是给你自己加保障——保障你敢放手让它写，保障你敢直接用它的产出。
AI编程的工程化，不是让AI写得多，而是让你敢用得多。
后续持续更新AI编程实战技巧。
往期文章请查看：AI编程系列
关注本号，不错过AI编程干货，转发收藏，开发遇到问题随时翻阅。