--- title: "AI 写完代码后，我只看这 5 个地方 | 行开心的颠倒世界" description: "Code Review AI 代码，传统清单全过，风险却藏在它替你做的默认选择里。五个该盯的落点：边界条件、错误处理、外部依赖的假设、状态一致性、权限边界——都是 AI 最容易自信做错的地方。十分钟把注意力收到这里，换半夜少接一次事故电话。" canonical: "https://xingkaixin.me/posts/ai-code-5-checkpoints/" language: "zh-CN" --- # AI 写完代码后，我只看这 5 个地方 Code Review AI 代码，传统清单全过，风险却藏在它替你做的默认选择里。五个该盯的落点：边界条件、错误处理、外部依赖的假设、状态一致性、权限边界——都是 AI 最容易自信做错的地方。十分钟把注意力收到这里，换半夜少接一次事故电话。 2026年6月15日·1,891 字·5 分钟 [AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[代码审查](https://xingkaixin.me/tags/%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5/)[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)[安全](https://xingkaixin.me/tags/%E5%AE%89%E5%85%A8/) ![AI 写完代码后，我只看这 5 个地方](https://xingkaixin.me/cover/ai-code-5-checkpoints.webp) AI 交上来的 PR，越来越难挑出毛病：命名规整，注释齐全，try-catch 层次清楚，测试全绿。你拿着传统 Review 清单从头过到尾，一条都没抓住，最后得出结论”写得挺好的”，点了合并。 **代码看起来好，是因为你的尺子量错了地方。** 前面几篇我一直在写 AI 代码验收有多难，有读者问：道理都认了，但我不可能每行都审，给个能用的东西。这篇就是。 AI 代码最大的风险集中在”选错”：它在你没有明确指定的地方自己做选择，而且选的时候没有任何犹豫。这些选择集中在五个位置。 ## 1\. 边界条件 AI 碰到一个问题，会从训练数据里检索一个最匹配的通用方案。方案本身是对的，教科书级，在大多数场景下跑得很好。你的产品可能不在”大多数”里。 我让 AI 给阅读器写过页面块缓存：已渲染的页面块缓在内存里，翻页不用重新解析。AI 用了 LRU 策略，保留最近访问的 10 个页面块，最久未用的踢出去。代码干净，策略经典。 但读技术书跟刷网页是两种行为。刷网页是线性的，一路往下翻，LRU 完美匹配。读技术书是震荡的：看到 50 页忘了前面的公式，翻回 30 页看一眼，再回到 50 页。第 30 页所在的页面块已经被 LRU 踢掉了，渲染引擎重新解析一遍。这不是缓存没命中，是命中条件和工作负载不匹配。 看边界条件，多问一句：这个实现背后，AI 默认了一个什么使用模式？这个模式是你的用户吗？AI 选的通用方案在教科书里是对的，在你的产品里呢？ ## 2\. 错误处理路径 AI 的错误处理有一个标志性特征：一定会写，而且结构完整。try-catch 层次清楚，错误类型分得明白，看上去很专业。 但 AI 对错误处理有一个默认假设：所有异常事件都会被通知。来电话了有 interruption 通知，进后台有 didEnterBackground 回调。API 文档里列出来的，AI 都覆盖了。 我让 AI 给语音笔记写过录音状态持久化：app 进后台时保存录音进度，回前台从中断点继续。AI 处理了所有文档事件：进后台存进度、回前台恢复、来电话暂停、通话结束继续。测试完美。 但移动系统在内存紧张时，可能直接终止后台进程，应用没有机会执行最后一次保存。用户在录音，切到微信回消息，系统恰好在那一刻回收进程。回到 app，从保存点恢复，录音接上了，但管线缓冲里那一小段音频蒸发了。app 没崩、没报错，录音文件里只多了一个你听不出来的断点。 AI 的错误处理覆盖了所有文档写了的事件。它漏了文档里没写的那条：运行环境可以在任何时候、不发任何通知地杀死你。这个事件不在 API 参考里，只在线上事故里。 一条判断标准：这段错误处理，假设了异常事件一定会通知你吗？如果你的运行环境有不发通知就动手的机制，比如系统直接回收进程、请求被取消但业务层收不到终态，仅靠注册通知和回调是不够的。 ## 3\. 外部依赖的假设 这是 AI 代码里最隐蔽的位置。 我让 AI 给 CLI 加过”工具调用耗时”：统计每个工具的平均响应时间。AI 解析了会话日志里的 tool\_call 记录，用 end\_time - start\_time 算耗时。数据干净，排行合理。 但我后来看 Agent 源码时发现：Agent 对某些工具调用做了本地缓存。read\_file 命中缓存时，根本没真读文件，但日志里仍然有一条 tool\_call 记录，start 到 end 间隔 30ms。那 30ms 不是磁盘 IO，是缓存查询加进程间通信。AI 统计的”工具耗时”，实际上是 Agent 内部处理工具调用的时间，不是工具本身执行的时间。 AI 信任了字段名的字面意思。但同一个字段名在上游和下游有不同定义：Agent 的 duration 是”Agent 内部响应时间”，你的”工具耗时”是”外部工具执行时间”。这个语义差不在类型定义里，在 Agent 的实现细节里。 检查方法：找到所有依赖外部字段做计算的地方，问一句，这个字段在对方系统里的真实定义是什么？字段名只提供意图，赋值逻辑才定义语义。 ## 4\. 状态一致性 AI 处理数据时，经常产生你没预料到的副作用。最典型的：读路径加了缓存，写路径没碰缓存，更新了数据，缓存还在返回旧值。这个案例在 Spec 那篇里完整讲过，但它在实际 Review 里出现的频率高得让人麻木。同类的还有：全局变量带着上一个请求的脏状态、事务里第二步失败但第一步没回滚。 这类问题在单次测试里几乎不暴露：第一次跑，缓存是空的、状态是干净的、事务是新的。跑一千次才冒头。 检查方式是影响面追踪：找到所有写操作，从每个写操作出发，画一条线到它影响的读路径。哪条线断了，哪里就是定时炸弹。 ## 5\. 权限边界 AI 几乎不会主动加安全措施，除非你明确要求。 “形式上”的安全现在的模型基本都会做：参数化查询、格式校验、接口鉴权，你不用说它也会加上。真正漏掉的，是它理解不了的东西。 我让 AI 给语音笔记写过分享链接。链接访问时做了登录校验，没登录就看不了。PR 描述里写了”已添加访问控制”。审的人扫一眼，有鉴权，过了。 但登录校验只回答了”你是谁”，没回答”你有没有被邀请看这条”。分享者设的”仅限好友可见”完全没生效，任何人登录后拿到链接都能看。AI 写完了认证，漏了授权。 看权限边界，不要被”有鉴权”三个字骗过去。问一句：它检查的是”这个人有没有登录”，还是”这个人对这条资源有没有权限”？前者 AI 经常会补，后者需要你明确写进验收标准。 * * * 这五个位置有一个共同特征：**都是 AI 最容易”自信地做错”的地方。** AI 在这些位置不会犹豫、不会标注”我不确定”、不会报警。它用跟处理所有代码一样的语气，给你一个在本地环境完美运行的实现。风险全部藏在本地和生产之间的差距里。 **把有限的注意力收到这五个位置。每个花两分钟，十分钟结束。** 过完心里有底了，合并。没底，就让 AI 补三样东西：假设说明、失败路径、针对性测试。 这十分钟换来的，是半夜少接一次线上事故电话。 ## 版权声明 作者 XingKaiXin 标题 AI 写完代码后，我只看这 5 个地方 发布时间 2026年6月15日 文章链接 [https://xingkaixin.me/posts/ai-code-5-checkpoints/](https://xingkaixin.me/posts/ai-code-5-checkpoints/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览