应按文件层、内容层、逻辑层三步审查Codex改动：先用git status --porcelain确认实际变更文件；再用git diff --name-only筛选高危文件；最后逐文件用git diff --no-color检查删增内容及上下文，并验证分支结构、数据流向和单元测试。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想在 Codex 修改代码后立刻看清它到底动了哪些地方、删了什么逻辑、加了什么风险，又不想被满屏 diff 淹没——这时不能只靠肉眼扫，得用一套可复现的审查路径，把差异拆解成文件层、内容层、逻辑层三步来看。
第一步：确认 Codex 实际改动了哪些文件
进入项目根目录，执行：
git status --porcelain
这一步输出精简，每行以两个字符开头：M 表示已修改、A 表示新增、D 表示删除。比 git status 更适合脚本化判断。
如果输出为空，说明 Codex 没有真正写入任何变更，可能是它声称“完成”但实际卡在缓存或未触发保存。此时应中止后续审查，先检查 Codex 是否成功落地修改。
第二步：聚焦差异范围，跳过无关文件
运行：
git diff --name-only --diff-filter=MA
它只列出被修改（M）和新增（A）的文件名，不显示内容，适合快速判断是否越界。
重点盯住这几类文件是否出现在列表中：【package.json、.env、src/utils、src/api、global.css】——这些属于高影响面文件，除非你明确要求 Codex 调整依赖、环境或全局逻辑，否则它们出现在改动列表里就是危险信号。
若发现这类文件，暂停审查，先问 Codex：“请说明 src/api/index.ts 被修改的具体原因，是否与本次任务强相关？”
通过本地 MCP 桥接程序将 QQ 邮箱接入 Codex，配置所需的.env凭证信息、注册 MCP 服务端，并完成收件箱读取与邮件发送的全流程测试。适用场景：用户需要将 QQ 邮箱连接至 Codex、让 Codex 读取 / 发送 QQ 邮件、安装 / 修复qq_mail MCP 服务端，或是在 Windows 系统上排查 IMAP/SMTP 配置故障时，执行以上操作。
第三步：逐文件审查差异内容
对每个需审查的文件，执行：
git diff --no-color
注意：不要加 -w 或 --ignore-space-change，空格和缩进变化有时是逻辑变更的前兆，比如把 if (x) { ... } 改成 if(x){...} 可能是 Codex 删除了换行，也可能是它合并了多行条件判断。
审查时按以下顺序快速扫描：
- 先看所有 - 行（删除）：有没有删掉空值判断、权限校验、try/catch 包裹、console.warn 等调试残留——这些看似“冗余”，实为防御性设计；
- 再看所有 + 行（新增）：有没有硬编码 ID、写死 URL、漏掉 await、用 == 替代 ===、把 const 改成 let 导致变量可变；
- 最后看上下文：被修改行的前后 3 行是否还在？Codex 有时会误删整段注释或空行，导致后续 import 错位或类型定义失效。
遇到带 /* TODO */ 或 // HACK 注释的代码块要格外小心——Codex 常会直接删掉整块，理由是“注释不影响运行”，但它删掉的可能是团队约定的待修复标记或临时绕过方案。
第四步：验证关键逻辑是否被破坏
方法一：回溯原始判断分支
找到你最初让 Codex 修改的函数入口，在 diff 中定位该函数。检查所有 if/else、switch/case、三元表达式是否仍保留原有分支结构。Codex 在简化逻辑时常把 if (a && b) 合并为 if (a) 并删掉 b 的校验，【这会导致空指针或未定义行为在特定输入下爆发】。
方法二：检查数据流向
如果改动涉及状态更新（如 useState、useReducer、Vuex commit），确认所有 .dispatch()、setState()、commit() 调用是否仍在原位置。Codex 有时会把异步更新移到 useEffect 外部，造成状态不同步。
方法三：运行最小验证集
只运行与该文件直接相关的单元测试（如 jest --testPathPattern=Login.test.tsx），不跑全量。若测试通过但手动点按钮失败，大概率是 Codex 修改了事件绑定方式（比如把 onClick={() => fn()} 改成 onClick={fn} 却没处理 this 或参数传递）。
