别只看表面，要学会「挖」问题
上一节讲了让 Codex 审查。这一节进阶：怎么让它发现潜在的缺陷和优化点——不只看「这段对不对」，而是看出「这里将来会出事」「这里还能更好」。
好审查，是「挖」出来的，不是「扫」出来的。
file-lib 表面看着都正常，但很多问题藏在「极端输入」「调用链」「并发」这些不常走到的路径里。这一节我们专门用「四个深挖角度」给 file-lib 的模块做一次「深度体检」——比如 io.js 在读到超大文件时会不会内存爆炸、path.js 传入非法路径会不会崩。这些不是表面扫描能发现的，得带着场景去「挖」。从「扫描」到「深挖」
浅层的审查是「扫描」：逐行看有没有明显的错。深层的审查是「深挖」：结合调用链和场景，推断潜在的坑。
让 Codex 深挖，靠的是引导：
❌ 「看看有没有 bug」→ 它可能只扫一遍 ✅ 「结合这个函数的调用方，分析：输入极端值时会不会崩？并发时会怎样？边界漏没漏？」
给它具体的深挖角度，它才能挖出真东西。对 file-lib，把四个角度直接列给 Codex，它就不会只停留在「扫描」。
四个深挖角度
1. 边界（Edge Case）
极端输入会不会出事？
「如果传入空数组、超大数字、null，这个函数会怎样？」
对 file-lib 的 io.js，可以这么问：
「
readDir在传入一个不存在的路径、或一个没有权限的路径时，会返回什么？会不会直接 throw 崩溃？」
2. 调用链（Call Chain）
它被谁调用？改了它会牵连谁？
「这个函数的返回值，在调用方是怎么被使用的？改了返回结构会不会破坏调用方？」
对 file-lib，index.js 汇总导出所有模块，改任何一个模块的导出签名，都会牵连到 index.js 和所有用到的人。让 Codex 顺着调用链查，能提前发现「改一个函数会踩一片」的连锁问题。
3. 并发/状态（Concurrency/State）
多线程、多请求下会不会出问题？
「这个全局变量在并发下会不会被竞态改写？」
file-lib 虽然是工具库，但若有模块里缓存了全局状态（比如一个模块级的缓存对象），并发调用时就有竞态风险。让 Codex 专查「模块级变量」和「共享状态」。
4. 性能/资源（Performance）
有没有隐藏的性能坑？
「这个循环里有没有重复计算？这个列表会不会无限增长？」
对 file-lib 的 io.js，一个典型性能坑是「一次性读整个文件」——文件大了内存就爆，应该改为流式读取。让 Codex 专门从「大数据量」角度挖。
一个「深挖」示例
你：审查 file-lib 的 lib/io.js，重点结合边界、调用链、性能和状态。
Codex：
- 边界：readFile 遇到不存在的文件时直接 throw，调用方没兜底 → 会崩
- 调用链：index.js 导出了这个函数，改了返回结构会破坏入口
- 性能：一次性 readFile 读全量内容，大文件时内存占用高 → 建议流式
- 状态：模块级 cache 对象在并发读不同文件时会互相覆盖 → 竞态
这些都是「扫描」看不出来、需要「结合场景想」才发现的真问题。你会发现，给的角度越多，它挖出的层次越深——这正是引导的力量。
让 Codex 输出「可行动的优化」
发现优化点后，别停在「可以优化」，要它给出具体的改法：
✅ 「N+1 问题：改为一次性
IN查询所有用户再映射，预计数据量 1000 时响应从 5s 降到 0.3s。」
有依据、有量化、有改法，才是可落地的优化。放到 file-lib 的 io.js，要求 Codex 这么给：
你说的「一次性读全量」性能问题，给我具体的改法：
- 改成 fs.createReadStream 流式读取要改哪几行
- 改完对内存占用的影响量级大概多少
- 会不会破坏现有调用方的返回结构
有了「改法 + 影响 + 风险」，你才知道这个优化值不值得做，而不是看完一句「可以优化」就忘了。
深挖的边界
- 深挖靠引导：你给的角度越多，它挖得越深
- 别让它瞎猜：让它「基于代码和调用链」，别臆想不存在的场景
- 人复核：AI 可能过度解读，关键结论人工确认
io.js；再把每个「优化点」追问成可行动的改法（具体改几行 + 影响量级 + 会不会破坏调用方）；最后人工复核每条结论。②怎么判断做对了：至少挖出 1 个「不常走到的路径」下的隐患（如大文件、非法路径）、每条优化都有可落地的改法而不是空话、你没有为了某个「特定场景隐患」推翻够用的代码。③卡住了怎么办：如果它只扫表面，把你关心的场景直接喂给它（如「传入 2GB 文件会怎样」）；如果它开始臆想不存在的场景，要求它「必须基于代码里真实存在的行来论证」。常见坑：深挖过度，为了「挖」而挖
引导它深挖之后，新问题出现了：Codex 开始为了「显得专业」硬造问题。比如给一个纯函数（无副作用、无 I/O）硬说它有并发问题，或把「字符串可能为空」说成「严重安全漏洞」。这反而增加了你的噪音负担。
避坑办法：给深挖设一个「必须基于代码」的底线，并要求它评估「真实触发概率」：
每条结论请回答：
- 具体是哪一行代码导致的？贴出代码
- 什么真实场景会触发？触发概率高不高？
- 如果不改，后果有多严重？
无法回答这三条的结论，视为「不够有依据」，不要输出。
这样能把「为挖而挖」的噪音过滤掉，只留下真正值得你花时间处理的问题。深挖的目的是发现真问题，不是制造问题。 把握住这个度，Codex 才能从「辅助」升级成「质检」的可靠伙伴。
小结
- 好审查是「挖」出来的：结合调用链和场景
- 四个深挖角度：边界、调用链、并发状态、性能资源
- 引导它深挖：给具体的角度，别只问「有没有 bug」
- 优化要给依据、量化、改法；人复核关键结论
下一节，讲审查反馈的落地实践。