楼主把 118 楼里有代表性的做法整理一下。
一、先看风险，再决定审多细
- 先问一句：这是不是一次性的项目？如果不是，就得想清楚 AI 在代码里「埋了雷」时你怎么排（#9 marsg）。
- 像 Linux 内核这种可靠性至关重要的项目，必须一行行审；大部分普通项目，人逐行审不现实，保证整体架构正确，再加强可观测性，出了问题能第一时间知道、第一时间解决（#39 zengxs）。
- 本质是风险、成本和收益的权衡：觉得够用就不加审核，想提高合格率就加（#33 iApp）。
- 算法细节可以交给测试，但改动范围、影响范围、处理流程，这些错了还是人背锅，要自己看（#66 fredweili）。
二、不逐行看，也有办法把关
- 审行为，不审实现：写好需求后，Agent 半小时能出三千多行，人工审要一个多小时，不现实。不如给 Agent 定好代码规约，然后测试它实现的行为是否符合预期（#43 blankll）。
- 但测试也得有人看：有人以为用测试盯住就行，结果发现 AI 写的测试如果人不看，即便全绿，也可能是到处「飞线」凑出来的（#117 RichardPlus）。
- 换个模型交叉审：Claude 写完，让 Codex 在新会话里
/review，把审查结果交给 Claude 修，修完再让 Codex 验证，通过了再提交（#69 zhaosong）。也有人用一个空白上下文、设定成代码审查员的 AI 再过一遍，审查要求写详细（#79 penll）；换模型审完，提交前自己再瞄一眼，常能发现低级 bug（#87 WashFreshFresh）。 - 看不懂就让它换写法：直接让 AI 改成不那么优雅、但你能看懂的写法（#20 meteora0tkvo）。
- 至少顺着入口链路通读一遍：留个印象，以后出了 bug，就算还是让 AI 改，你也能快速定位；不然 AI 写、AI 改，自己什么都不知道（#38 richard001）。
三、「编译器类比」之争
- 一派说：以前不用审编译器输出的汇编，以后也不用逐行审 AI 写的代码，做好测试、设好安全边界、出问题能回滚就行（#42 remarrexxar、#82 dreampuf）。
- 另一派说没法类比：编译器是确定的，同样的源码编译出来的汇编是固定的；同样的自然语言输入，模型的输出却做不到完全一致（#78 WashFreshFresh、#17 glacer）。
四、数据类项目要格外小心
楼主后来补充：功能类的项目，功能对了就行；但数据分析要求数据准确、计算路径确定，AI 用了错误的数据、指标或算法，结果看起来对，实际是错的（#80、#83）。这类代码，关键的口径和计算步骤值得自己核一遍。
相关的旧帖：把 AI 当员工、自己当老板，项目会不会越写越烂？、Claude 不按规范来怎么办。你现在审到什么程度？