devgo.cn如果你正在用 AI 辅助开发，最该养成的习惯不是让模型直接生成功能代码，而是先让它写测试。这是作者在长期使用各种模型开发、维护、优化项目后总结出的最重要经验，也是他此前分享技巧时遗漏掉的一点。
为什么测试先行如此关键？因为 AI 生成代码的不确定性太强。你给它一个需求，它可能写出一个看似合理但实际跑不通的实现，甚至悄悄偏离你的本意。而如果你先要求它写测试，就等于在动手之前先立下一道护栏：测试定义了“什么算完成”，AI 后续的所有工作都必须围绕让这些测试通过来展开。这样一来，无论模型怎么发挥，最终结果都会被拉回到你真正想要的方向上。
具体做法很简单：在给 AI 下达任务时，明确要求它“先为你要创建或修复的功能编写测试，然后再实现功能或修复缺陷”，并且每个任务都重复这个流程。作者特别提醒，很多模型习惯在功能写完后再补测试，所以你可能需要把“先写测试”这句话说得非常直白，甚至反复强调。
测试先行带来的保护是多重的。第一，你可以在写功能前先运行这些测试，确认对应功能确实缺失或确实存在 bug——这一步也建议你亲自审查并运行测试，至少抽查一部分，而不是完全信任 AI 的输出。第二，测试像护栏一样约束 AI 的行为，防止它在实现过程中跑偏，任何偏离都会导致测试失败，从而迫使它回到正轨。第三，当 AI 声称“已完成”时，测试通过就是最直接的验收证据，你不用靠肉眼逐行审查代码来猜测它是否真的做对了。第四，这个过程也能让你自己始终聚焦在问题上，不会被 AI 生成的无关改动带偏。
作者的身份很有意思：他自认为是前端开发者优先、Web 开发者其次、程序员最后。这个定位让他对很多开发流程持有一种“局外人”的视角，但也正因为如此，他的经验对非强编程背景的人更有参考价值。他坦言，自己过去对测试先行并不敏感，是 AI 协作让他真正体会到这条规则的价值。如果你也不是很强的程序员，完全可以试试从测试入手——虽然你需要花时间适应写测试这件事，但它比“直接让 AI 写功能然后盲目上线”要更安全、更可控。
一个值得注意的细节是，作者最初把这种方法称为“测试驱动开发”（TDD），但经读者提醒后修正为“测试先行”（test first）。TDD 通常包含严格的“红-绿-重构”循环，强调测试驱动设计；而“测试先行”更宽泛，只强调先写测试再写实现，不强制重构步骤。作者认可这个区分，并认为“测试先行”更准确地描述了他所验证有效的方法。这个修正也提醒我们：在 AI 协作场景下，不必拘泥于经典 TDD 的完整仪式，只要抓住“先测试、后实现”这个核心，就能获得大部分收益。
这套思路能直接用到哪些场景？凡是让 AI 修改现有代码、修复 bug、新增功能，都可以先要求它产出测试。尤其是当你面对一个不熟悉的代码库，或者 AI 经常“自作主张”改动无关代码时，测试先行能显著降低风险。需要注意的坑是：测试本身也可能被 AI 写得过于宽松或流于形式，所以关键测试最好人工审查，并确保它们真的能失败——如果测试在功能未实现时就通过，那它就没有任何保护作用。另外，不要一次性让 AI 写太多测试，聚焦在当前这个功能或修复上，小步快跑，效果更好。
内容与图片版权归原作者所有 · 原文: https://meiert.com/blog/ai-and-tests/