Codex 辅助代码审查

让 Codex 帮你「审」代码

代码审查（Code Review）是保证质量的重要环节，但人肉审查很累、容易漏。Codex 可以帮你审查——它读代码快、不疲劳、能发现你容易忽略的问题。这一节学怎么用它辅助审查。

---

Codex 能审出什么

让 Codex 审查代码，它主要看这几个方面：

方面	例子
逻辑错误	条件写反、边界漏了
异常处理	该 try/catch 的没处理
性能问题	循环里做不该做的操作
可读性	命名不清、逻辑绕

它擅长发现「代码本身」的问题。拿 file-lib 里常见的 lib/io.js 举例，一个典型的逻辑错误可能是：

// 危险写法：async 函数里忘写 await
async function readFileSafe(path) {
  const data = fs.readFile(path, 'utf8'); // 漏了 await
  return data; // 返回 Promise，调用方拿不到内容
}

这种「代码本身」的错，Codex 一眼就能抓住。而你作为作者，因为太熟悉反而容易视而不见——这正是 AI 审查的价值。

---

怎么让 Codex 审查

给它代码 + 明确的审查要求：

审查 src/auth.ts，重点看：
- 有没有逻辑错误或边界漏洞
- 异常处理是否完整
- 有没有明显性能问题
只给出有依据的问题，别泛泛而谈。

给它范围 + 关注点 + 「要有依据」，它的审查才有价值。对 file-lib 可以这么下指令：

审查 lib/ 下所有模块，重点看：
- 异步函数有没有漏 await / catch
- 边界输入（空、null、超大值）会不会崩
- 有没有明显性能或资源问题
- 命名和导出是否一致
逐条给出「文件 + 行号 + 问题」，别泛泛而谈。

范围（lib/）、关注点（四项）、输出格式（文件+行号+问题）一次说清，审查才有料。

---

审查输出要有「依据」

最怕 Codex 给一堆「这段代码可以优化」的废话。要求它：

「指出问题 + 位置 + 依据 + 建议改法」

问题：第 42 行 `parseInt(user.id)` 在 id 为 'abc' 时会返回 NaN
位置：src/auth.ts:42
依据：parseInt 对非法输入返回 NaN，后续比较会异常
建议：改用 Number() 并校验 NaN

有依据的审查，你才好判断、好落地。在 file-lib 里，让 Codex 按这个四段式输出，你拿到的直接就是能改的东西，而不是「这段可以更好」的空话。你可以把「问题 + 位置 + 依据 + 建议」这个模板直接贴进提示词里要求它照做。

---

Codex 审查的边界

要清楚 Codex 审查的局限：

• 它能审「代码本身」：逻辑、写法、性能
• 它审不了「业务对错」：需求理解得对不对，它不知道
• 它可能漏：别把它当「全知」，当「辅助」

Codex 是辅助，人做最终判断。 它帮你扩大覆盖面，不代表你可以不看。对 file-lib 来说：它能审出「这个函数边界会崩」，但审不出「用户真正需要的是不是这个函数」——后者只有你知道。

---

一个审查小流程

1. 让 Codex 审指定文件/改动
2. 它给出「问题 + 位置 + 依据 + 建议」
3. 你复核每一条，判断真伪
4. 真的有问题的，让 Codex（或你）修
5. 修完再审一遍

Codex 审 → 你判断 → 修复 → 复审。给 file-lib 用，就是每次提交前都过一遍这个流程，把「质量体检」养成习惯。

---

常见坑：把「可能的问题」当成「确定的问题」

Codex 审查时有时会把「可能的隐患」说成「必然的 bug」，语气很笃定，容易让你误判严重性。比如它会说「这里并发下一定会崩」，但实际上在当前调用方式下根本不会并发。

避坑办法：区分「确定性」和「可能性」。要求 Codex 给每条问题标注它的判断依据和触发条件：

每条问题请标注：
- 触发条件（什么输入/什么场景才会触发）
- 严重程度（必现 bug / 特定场景 / 潜在隐患）
- 你的判断依据（代码里哪一行让你得出这个结论）

这样你就能区分「现在就得修的」和「将来才要注意的」，不会为了一个「特定场景隐患」推翻本来就够用的代码。AI 审查的价值在提醒，判断权永远在你手里。

---

小结

1. Codex 能辅助审查，速度快、不疲劳
2. 看四类：逻辑、异常、性能、可读性
3. 输出要有依据：问题 + 位置 + 依据 + 建议
4. 边界：审代码行得通，审业务不行；它辅助，人判断

下一节，学怎么发现潜在缺陷与优化点。