AI 代码审查清单

Vibe coding 让 AI 生成代码后，按这个清单逐项检查。AI 写代码快，但不会主动考虑很多关键问题。

新手起步：刚开始不需要全部检查。先只看这 3 项：

数据层（第 1 节）— 数据模型对不对？索引建了吗？

并发安全（第 2 节）— 会不会超卖？事务边界对吗？

API（第 4 节）— 分页方式对吗？有限流吗？

随着你做更多项目，再逐步扩展到完整清单。

每一项包含：

→ 知识点：对应的深度参考手册编号，想深入理解时查阅
检查项：具体检查什么
AI常犯错误：典型的坑
修复指令：发现问题后怎么跟AI说

1. 数据层检查

1.1 数据模型是否合理（→ 知识点 2.1）

实体关系是否正确？有没有漏掉关键实体？
选择了合适的数据模型？（关系/文档/图）
外键和索引是否建了？

AI常犯错误：用一个巨大的JSON字段存储本应拆分的实体；遗漏必要的索引

修复指令：“请把 {字段} 拆成独立的表，加外键关联；对 {查询字段} 建索引”

1.2 索引是否有效（→ 知识点 2.3-2.7）

高频查询字段有索引？
复合索引的列顺序是否正确？（高选择性列在前）
有没有不必要的索引？（写入开销）

AI常犯错误：忘记给WHERE和JOIN字段建索引；复合索引顺序错误

修复指令：“对 {表} 的 {字段} 建索引，这是高频查询条件”

1.3 存储选型是否匹配（→ 知识点 2.4-2.6）

写密集场景有没有错用B-Tree？（应考虑LSM-Tree）
需要全文搜索有没有硬用LIKE？（应用Elasticsearch）
需要排行榜有没有每次全表排序？（应用Redis Sorted Set）

AI常犯错误：所有数据都塞PostgreSQL，不考虑场景适配

修复指令：“排行榜数据请改用Redis Sorted Set，用ZADD更新分数，ZREVRANGE取Top N”

2. 并发安全检查

2.1 竞态条件（→ 知识点 6.2-6.4）

“读取-判断-写入”操作是否有并发保护？
库存/余额/计数器是否用了锁或原子操作？
有没有这种模式：if (count > 0) { count-- } — 两个请求可能同时通过if

AI常犯错误：先SELECT查余额，再UPDATE扣减，中间没有锁 — 典型的TOCTOU（Time-of-check to time-of-use）漏洞

修复指令：“库存扣减请用 SELECT ... FOR UPDATE 或 UPDATE ... WHERE stock >= {amount} 的原子操作”

2.2 事务边界（→ 知识点 6.1）

需要原子执行的多步操作是否在同一个事务里？
事务范围是否过大？（锁持有时间过长影响并发）
外部调用（HTTP/消息）有没有放在事务里？

AI常犯错误：在事务里调用外部API（如支付接口），导致事务长时间持锁

修复指令：“把外部API调用移到事务外面，事务里只做DB操作，外部调用失败后用补偿逻辑”

2.3 幂等性（→ 知识点 7.8）

支付/扣款回调是否幂等？
表单提交是否防重复？
消息消费是否幂等？

AI常犯错误：支付回调每次调用都创建一条新记录，不检查是否已处理

修复指令：“加idempotency_key字段，处理前先查是否已处理，用UNIQUE约束防并发”

3. 缓存检查

3.1 缓存一致性（→ 知识点 4.2）

数据更新时缓存是否同步失效？
有没有”更新了DB但忘记删缓存”的路径？
顺序是否正确？（先更新DB，再删缓存）

AI常犯错误：只在查询时加了缓存，更新接口完全没处理缓存失效

修复指令：“在更新/删除操作后，加上缓存失效逻辑：删除对应的Redis key”

3.2 缓存故障防护（→ 知识点 4.4）

查询不存在的数据是否会穿透到DB？
大量key是否可能同时过期？
热点key过期后是否有保护？

AI常犯错误：缓存miss时直接查DB，没有任何保护措施

修复指令：“查询不到的key请缓存空值(TTL 60秒)；缓存TTL请加随机偏移(±10%)“

4. API 检查

4.1 分页方式（→ 知识点 1.8）

列表接口用的是什么分页？
数据频繁变化时（如信息流）是否用了cursor分页？
offset分页在深翻页时性能是否可接受？

AI常犯错误：所有列表都用offset/limit，数据插入频繁时会跳行或重复

修复指令：“信息流接口请改用cursor-based分页，用created_at或自增ID作为cursor”

4.2 限流与防护（→ 知识点 1.7）

公开接口是否有限流？
上传/导入接口是否限制了文件大小和频率？
登录/注册是否有频率限制？

AI常犯错误：完全不加限流，任何接口都可以无限调用

修复指令：“给公开API加限流中间件，每个IP每分钟最多{N}次请求”

4.3 输入验证与安全

用户输入是否做了校验和清理？
SQL查询是否用了参数化/ORM？（防SQL注入）
返回数据是否脱敏？（不返回password、token）

AI常犯错误：拼接SQL字符串；返回完整用户对象包含password hash

修复指令：“所有SQL请用参数化查询；用户返回对象过滤掉password和token字段”

5. 异步处理检查

5.1 该异步没异步（→ 知识点 5.1）

HTTP handler里有没有耗时操作？（发邮件、转码、爬取、报表生成）
用户是否真的需要等待这些操作完成？

AI常犯错误：在API handler里同步发送邮件，导致响应时间3-5秒

修复指令：“发送邮件/通知请改为异步：API立即返回202，任务放入消息队列，worker消费处理”

5.2 消费可靠性（→ 知识点 5.4, 5.7）

消费失败后是否有重试机制？
重试多次后是否进入死信队列？
消费逻辑是否幂等？（因为会重试）

AI常犯错误：消费失败直接丢弃；或有重试但消费逻辑不幂等导致数据重复

修复指令：“消费失败请重试3次（指数退避），仍失败进入死信队列；消费逻辑要幂等”

6. 扩展性检查

6.1 单点瓶颈（→ 知识点 3.1, 4.7, 8.1-8.2）

有没有所有请求都打到同一个数据库实例？
有没有单点故障？（某个服务只有一个实例）
读多写少的场景有没有读写分离？

AI常犯错误：所有读写都在主库，没有从库

修复指令：“请加读写分离：写操作走主库，读操作走从库”

6.2 N+1查询

有没有循环中查询数据库？（for循环里每次SELECT）
列表接口是否用了JOIN或批量查询？

AI常犯错误：获取10个帖子，然后循环10次查询每个帖子的作者信息

修复指令：“请用JOIN或IN查询批量获取关联数据，不要在循环里单条查询”

7. 分布式系统检查（进阶）

7.1 网络调用容错（→ 知识点 7.1-7.2, 8.5）

调用外部服务/API有没有设置超时？
超时后的处理逻辑是什么？（重试/降级/报错）
有没有熔断机制防止级联故障？

AI常犯错误：调用外部API没有设置timeout，默认无限等待

修复指令：“所有外部HTTP调用请设置超时(如5秒)，超时后返回降级响应或重试(最多3次)“

7.2 跨服务一致性（→ 知识点 6.7-6.9）

跨服务的数据是否有一致性保证？
一致性要求和实现是否匹配？

AI常犯错误：没有考虑跨服务调用失败后的数据不一致

修复指令：“请用Saga模式处理跨服务事务，每一步都有对应的补偿操作”

快速检查表（5分钟速查版）

Vibe coding 完成后，花5分钟过一遍：