把 AI 用明白｜经验分享 03：让失败测试先说话
你让 AI 把一个输入校验补上。
0:00 / 5:35
把 AI 用明白｜经验分享 03：让失败测试先说话
这一期解决一个很具体的问题：AI 改完代码以后，测试全绿，怎样确认它真的守住了需求？答案不是让 AI 再解释一遍，而是先把一个本来应该失败的场景写成可检查的验收条件，再让实现面对它，最后检查测试有没有脱离真实环境。
这期会听到什么
- 怎样把“这个改动应该做对”写成输入、预期结果和禁止发生的事情。
- 为什么要保留失败测试，不能为了让结果变绿就删除、跳过或放宽断言。
- 单元测试、失败路径和真实交互分别能检查什么；
mock（模拟对象）为什么会让测试更快，却不自动代表真实服务也能正常配合。 - 哪些判断不能交给测试或 AI 自己完成，尤其是登录、权限、支付、隐私数据和数据库迁移等高风险改动。
GitHub 的官方指南建议先运行自动化测试和静态分析，再核对代码是否符合需求与项目结构，并留意被删除或跳过的测试。1 OpenSSF 在二〇二五年的指南中也强调，AI 生成的代码不能绕过代码审查、测试、静态分析和版本控制；对安全关键函数，可以加入确认“不该发生的事情没有发生”的负向测试。2
一期二〇二六年一月的预印本研究分析了二〇二五年两千一百六十八个真实代码仓库中的编程代理提交。研究观察到，代理提交更常修改测试，也更常在测试中加入模拟对象；这不是“模拟对象一定有问题”的证明，而是提醒你验收测试时还要问：它有没有碰到真实交互？3
今天就试一次
拿一个你本来就要改的小函数，先写两条必须通过的情况，再写两条必须失败的情况。把四条验收条件交给 AI，要求它先解释每条测试守住的行为，再修改代码；保留原有测试，不得用删除测试来消除失败。最后跑原有测试、新测试和静态检查；如果代码连接外部服务，再补一次真实交互检查。
最后随机挑一条失败场景，亲自确认测试检查的是需求，而不是实现细节。你要留下的不是一句“全部通过”，而是三个可回答的问题：需求有没有写成可检查的行为，失败路径有没有被认真测试，测试有没有和真实环境脱节？
References
- 1Review AI-generated code
docs.github.com
- 2Security-Focused Guide for AI Code Assistant Instructions
best.openssf.org
- 3
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.