审查 AI 写的代码：先找「看着对但会坏」
收录 2026-11-05
AI 代码的错通常不是语法，而是看着合理的假设。
这段代码是 AI 生成的：[代码或说明]。请按「像对但不对」的角度审查：1）列出它默认成立却没有验证的假设（输入范围、调用顺序、外部状态）；2）找出可能静默出错的地方——不报错但结果错；3）标出它看起来处理了、其实只覆盖了常见路径的错误分支；4）区分哪些写法符合框架惯例、哪些是「编造出来的 API 用法」，后者要对照文档核实；5）给出必须补的测试用例，每条说明它能抓住哪种错。不要整段重写。
本站原创
中文原文
复制前替换这些占位符 1
把方括号里的内容换成你的具体信息，替换后再粘贴给 AI。
[代码或说明]
使用建议
AI 代码最危险的不是错得明显，是错得合理。
可以这样改
- 要求它先复述需求与约束，确认无误再写代码。
- 让它给出最小改动 + 回滚方式，而不是整文件重写。
交付物（这次应拿到什么）
- 可运行的最小改动（含直接可用的代码块）
- 影响面清单：改了哪些文件、哪些调用点要跟着改
常见错法
- 一次让它改十个文件，最后分不清哪处改动导致了新问题。
- 只贴报错不贴代码和版本，拿到无法落地的修法。
输出验收（怎么判断能用）
- 改动可运行、可回滚，且没顺手改无关代码。
- 边界条件（空值、超长、并发）有说明或测试。
适用场景与注意
- 适合：让它先复述需求和约束，再给最小可运行改动。
- 注意：贴报错时同时给版本号与最小复现，否则它容易给出看似合理但不适配的写法。
适合什么场景
- 这段代码能跑、测试也过，但你觉得哪里不对，尤其当它是 AI 一次生成的整段实现。
- 你要评审同事或 AI 写的改动，对方很自信，而你需要把「看着合理」和「真的安全」分开。
不适合的场景
- 代码根本跑不起来：先让它跑起来，再谈评审。
- 你只是想统一命名和缩进：用 lint/formatter，比让人逐行评价风格可靠。
示例
输入
AI 生成的列表接口：`page = int(request.args.get("page", 1))`，接着 `offset = page * size`，并把 `size` 直接拼进 SQL 的 LIMIT 子句。你会得到
指出两处「像对但不对」：1）page 的起始基数没有约定，按 0 偏移会跳过第一页数据，要写明并校验边界；2）size 没有白名单或上限，可被传成极大值、负数或注入片段，LIMIT 不能字符串拼接。再补空结果与越界页的行为未定义。每条给触发输入与最小修法，不评价命名与格式。
常见误用
- 只丢一句「帮我看看 AI 写的代码有没有问题」：没有改动意图和运行环境，它只能给通用清单。
- 让它顺手重写整段：你拿到的是另一份代码，而不是一份可核对的评审意见。
可以这样改
- 加一句「只报会导致数据错误、安全问题或静默失败的，其余不提」，能明显减少凑数条目。
- 把「按严重程度排序」换成「每条先给能触发它的输入，再给最小修复」，拿到的是可复现证据。