让 AI 写代码,最让人睡不着的不是它「不会写」,而是它写出看起来完全正确、跑起来却是错的代码,还一脸笃定地告诉你「应该没问题」。代码越长、越像模像样,这种错越隐蔽。解法只有一个:别靠肉眼审,给它一套能自己证明自己对的验证闭环——让机器替你判定对错,你只看结论。这篇把一套经过实战打磨的 AI 自动化验证方法讲透:从「什么是可判定的预期」,到四种验证策略、测试与修复分离、多轮部署门控,最后沉淀成可复用的用例三件套——多数人卡在最后两步:验完不等于改对,改对不等于部署对。
为什么「看起来对」最危险
人写的 bug 通常「看起来就不对」——逻辑断裂、风格突兀,review 时一眼能逮。AI 的 bug 恰恰相反:它风格统一、命名得体、注释齐全,把错误包装得和正确代码一模一样。最高频的几类:
- 幻觉 API:调用了一个看起来合理、实际不存在的方法或参数。
- 漏边界:happy path 完美,空值 / 超长 / 并发 / 越权全没处理。
- 静默吞错:
try/catch把异常吃掉,返回一个「看起来正常」的默认值。 - 过度实现:你要 A,它顺手做了 B、C、D,每个都「看起来有用」,每个都是新的出错面。
这些都骗得过肉眼。能逮住它们的,只有可判定的、机器能跑的验证。
可判定的预期:验证的第一性原理
一切验证的起点,是把「对」定义成机器能判定的东西。「页面正常显示」不是预期;「点击登录后跳转到 /dashboard、且接口返回 code:1000」才是预期。预期必须写到能被一条断言验证的程度:点哪个按钮、看到什么文案、什么状态码、哪个字段等于什么。
写不出可判定的预期,往往说明你自己还没想清要什么——这时让 AI 写代码,只是在批量制造「看起来对」。所以验证的第一步不在代码,在于先把验收标准写到能判定。
四种验证策略
本章节为知识库会员内容
登录测试与修复分离:别边测边改
本章节为知识库会员内容
登录把验证写进工作流
本章节为知识库会员内容
登录多轮验证与部署门控
本章节为知识库会员内容
登录实战:把验证沉淀成用例三件套
本章节为知识库会员内容
登录它总不懂你的项目?因为它没有上下文——下一篇,管好它的「工作记忆」。