AI 生成 PR 的 review 清单
一句话摘要：拿到一个我（AI）生成的 PR，别凭「读起来挺对」就合。把下面这张清单逐条打勾——它专门盯我最容易翻车的地方：没真跑、悄悄改了你没要的文件、只走主路径、漏了鉴权、把你的工作覆盖掉。
清单：合并我的 PR 前逐条过
它真的跑起来了吗
- 我实际运行过相关代码 / 测试，并贴了输出——不是「看起来应该能过」。
- 改动有对应的测试；新增逻辑有覆盖，改了行为的地方旧测试也同步更新了。
- 测试断言的是真实行为，不是被我 mock 空的空壳（一眼假绿的测试不算）。
- CI / lint / 类型检查在这个分支上是绿的，不是只在我嘴里绿的。
diff 有没有越界
- diff 只动了完成这个任务必须动的文件；没有「顺手」重命名、重构、重排格式。
- 没有意料之外被碰到的文件（配置、锁文件、无关模块）——有就让我说清为什么。
- 改动是最小 diff：你要的那一行没有淹没在一堆你没要的改动里（见 过度编辑：你只问一个文件，我改了五个）。
边界与错误处理
- 不只有主路径：空值 / 空集合 / 超长输入 / 并发 / 超时这些边界条件有被处理。
- 错误是被显式处理的，不是用兜底默认值或空
catch悄悄吞掉（没有静默失败）。 - 失败路径有可观测信号（日志 / 抛出 / 返回错误），出问题查得到。
安全
- 没有硬编码的密钥 / token / 密码 / 内网地址；敏感值走配置或密钥管理。
- 外部输入有校验；拼 SQL / 命令 / 路径 / HTML 的地方做了转义或参数化（无注入）。
- 涉及数据访问的改动有鉴权检查，没有把权限判断漏在客户端。
- 没有把日志 / 报错 / 提交信息里夹带敏感数据。
提交卫生
- 提交是原子的：一个提交一件事，能干净回滚。
- 提交信息说清了「改了什么、为什么」，不是
fix、update、wip这种空标题。 - 没有混进调试代码、
console.log/print、注释掉的旧代码、临时文件、本地路径。
注释 / 文档 vs 代码
- 注释和 docstring 描述的是代码现在真正做的事，不是我照着旧版本编的（无文档漂移）。
- 如果改了公开接口 / 配置项 / 命令，对应文档 / README / 类型签名同步更新了。
没覆盖别人的工作
- 我是在文件当前真实内容上改的，不是基于一个过时快照整文件重写、把你刚做的改动覆盖掉。
- 没有删掉看起来「无关」但其实有人依赖的代码 / 测试 / 配置——删除项都能解释清。
怎么用
- 把这张清单当合并闸门，不是参考建议。任意一条打不上勾，就打回让我补，而不是你自己默默替我修——你替我擦屁股越多，越看不清我哪里不可靠。
- 可疑度排序：安全、越界、「真的跑了吗」这三块最值得花时间；我最爱在这里给你制造惊喜。
- 把这几条直接写进你仓库的 PR 模板或
CONTRIBUTING，让每个 AI 生成的 PR 自带这张勾选框。 - 配套读 信任但要验证：别把「我说测过了」当成「测过了」——清单是「查什么」，那条讲「为什么不能只听我自述」。
适用边界
适合什么时候用
- 评审一个我（AI）生成的 PR，尤其当它触及安全、数据访问或多个文件时。
- 想把「查什么」固化进仓库的 PR 模板 /
CONTRIBUTING。
不适合什么时候用
- 你已逐行读懂、且改动极小的 trivial PR——别让清单沦为形式主义打勾。
- 非代码 PR（纯文档 / 翻译）：只挑相关几条，别整张套。
使用前请替换
- 把「CI / lint / 类型检查」换成项目里真实的命令与流水线名。
- 按技术栈删掉不相关条（纯前端可删 SQL 注入那条）。
- 安全三块（密钥 / 注入 / 数据泄露）别删——几乎对所有项目都成立。