AI 代码的 Code Review 清单

本节目标

• 建立一套针对 AI 代码的 Review 清单
• 能逐条审查 AI 产出
• 把"信任但验证"落到可执行的检查项

4 类审查清单：

【正确性】是否处理了边界/异常？是否有隐藏的 off-by-one、空值？
【安全】  有没有硬编码密钥、SQL 拼接、eval、危险依赖？
【性能】  有没有 O(n²) 循环、无限制的数组增长、N+1 查询？
【可维护】命名清楚吗？有魔法数字吗？结构和你项目一致吗？

逐条打法：把 AI 给的代码逐段过这 4 类，每条要么"通过"要么"记下要改"。不要整体扫一眼就合并。

示例红旗：

// ⚠️ 红旗：SQL 拼接（注入风险）
db.query(`SELECT * FROM u WHERE name='${name}'`)
// ✅ 改为参数化
db.query('SELECT * FROM u WHERE name=?', [name])

名词解释

• Code Review（代码审查）：他人/AI 写完后，逐条检查正确性、安全、性能、可维护性的过程。AI 代码更该 Review，因为它可能"跑通但埋雷"。
• SQL 注入（Injection）：把用户输入直接拼进 SQL 字符串，攻击者可篡改语义。参数化查询（占位符）是唯一正解。
• 信任但验证（Trust but Verify）：对 AI 产出保持"可用但不可全信"的态度——它大概率对，但你必须独立验证关键路径。

课后练习

1. 为什么 AI 生成的代码"能跑"也仍需 Review？
   • 答案：能跑只说明无语法/运行错误，不保证安全（注入）、正确（边界）、可维护；AI 会"自信地"写出带隐患的代码。
2. 上面 SQL 拼接除了注入，还有什么问题？
   • 答案：单引号、特殊字符会直接破坏语句导致报错；参数化同时解决安全性和健壮性。

总结

"AI 写的代码也要 Review"是这一章的灵魂。很多人以为 Vibe Coding 省掉了审查环节，恰恰相反——正因为代码不是你逐行写的，你更该用清单把它"盯"一遍。我给出的 4 类清单（正确/安全/性能/可维护）不是新发明，而是把资深工程师脑内的审视外化成可勾选的项。特别要警惕"能跑的假象"：AI 特别擅长产出"语法正确、逻辑埋雷"的代码，比如一句 SQL 拼接就让整个系统门户洞开。所以请把"信任但验证"刻进流程：AI 大大降低了写的成本，但把"把关"的责任更重地压回你肩上。审查不是不信任 AI，而是对自己交付的系统负责。