你经历过这一幕吗？需求丢给 AI，屏幕上的代码像瀑布一样往下刷，五分钟给你一套完整接口。你说"帮我检查一下"，它飞速回你：自检完成，逻辑闭环，未发现问题。
接下来发生的事，就是 10 月下旬知乎刷屏的"崇祯模拟器"：你手下每个"臣子"都自称忠臣，汇报时单元测试、冒烟测试、功能测试全"绿"，一上战场就全垮。这条回答攒下 647 次收藏、100 条评论，高赞评论一针见血——“让英雄去查英雄，让好汉去查好汉。”知乎小红书
为什么自审没用？小红书上一篇实操帖（剧情演绎）说透了：你问它哪有问题，它回你三段为什么这么写——同一个会话审自己写的代码，会替自己辩护。不是 AI 找不到错，是它现在是"写代码的人"。小红书
真正的问题叫瓶颈转移。代码产出越来越便宜——知乎从业者分享的客户 AI 工作流，周一提需求、周末就出样。而验收这件事上，人的时间一分钟没多出来，"Review 不过来，要不要放弃 Review"才能冲上热榜。但这道题下面真正被认可的，只有半句：review 没有用，有用的是有效的 review。目前社区流传的实操配方，就是这四步：知乎知乎知乎
换个会话，甚至换个模型。新开一个干净会话，只喂需求原文 + diff，写代码时的聊天记录一个字都别带。更狠的玩法是 A 模型写、B 模型审、C 模型做最终测试——效果真实，token 消耗也飞起。知乎
开场改人设：“你没写过这段代码，是来挑错的。只报会导致行为错误的问题——漏做的需求、边界条件、权限、错误处理——风格别提，最多 5 条，按严重程度排”。不写"只报会出错的"，它会列 11 条，一大半是命名和缩进。小红书
需求贴全。只贴工单，它没报出那个权限 bug；把群里补的那句"只给新用户"加进需求，同一问题立刻排第一。AI 读不懂没写下来的需求。
每条复现了再改。它挑的不一定都对，按它给的复现步骤挨个跑，真复现得了才算数。
这套方法背后那句被广泛认同的话，别忘了——AI 写的代码，尤其擅长"运行成功"，但代码运行成功 ≠ 建对了。知乎上"不会编程直接用 AI 写靠谱吗"的高赞回答把底线说得很直白：可以让 AI 承担相当多的代码编写，但别把验收也完整交给它——人写的代码一样会出错，关键是有没有发现、定位和修正的机制。小红书知乎
底线从来没变：AI 负责挑错，人负责拍板。AI 时代真正变贵的从来不是代码，是判断。Review 不过来？砍审查范围，别砍审查。小红书
