codex-review

代码评审（codex-review）

本 skill 是施工链路的收尾核验层，用户级通用，可跨项目使用。

它解决的问题：施工完成后需要一道独立检查，但这道检查最危险的失败模式不是"漏看 bug"，而是"把已拍板的正确做法当成 bug 报上来、又被照着改掉"——评审者缺乏前面多轮讨论的背景，很容易把刻意的取舍误判为缺陷。而最隐蔽的一种是：评审者根本不知道某做法是已拍板决策，于是理直气壮把它标成"缺陷"。 本 skill 的全部设计都围绕堵住这个口子，核心是一条默认方向：不改除非已证实是缺陷——证据责任压在"改"这一侧，不是压在"不改"这一侧。

作用 = 照答案做低成本符合性核验：标准答案是冻结的正式 L1–L7 + 规格物化覆盖报告 + goal 章程 + 工程红线。轻量设计只解释 SD/DP 的由来，不能覆盖正式规格。若两者不一致，说明 T5 物化失效，应返闸，不由评审者选边。

在施工链路里的位置：

轻量设计（SD-x） → 正式 L7（AC-x） → 真值收敛与规格冻结（覆盖报告全绿）
                                    ↓
                        goal 章程（红队评审过） → goal 自主执行：代码 + 测试 + 交付
                                    ↓
              【本 skill】codex 单模型符合性核验 ← 用户手动触发（goal 之外）
                                    ↓
        分流责任人按"不改除非已证实"分流 ── A 改 / B 待裁 / C 上浮
                                    ↓
        触承重面 / 上游规格错了？──是──→ 回炉（退回设计步，见 §6）
                                    否
                                    ↓
                              修完收口

不是门禁。 它不卡开工、不卡交付；只在用户说"跑一遍代码评审"时执行。

它在 goal 之外，这是有意的。 goal 内部的审核只能是 loop 闭环内的 AI 自审 + 机器检查器——引入 loop 外的观点会带来场景不同、上下文不同的噪音。本 skill 是事后的、用户主动要的第二双眼睛，不是 goal 的工序。

---

0. 与 adversarial-review 的分工（单模型够用的边界）

维度	adversarial-review（已有）	codex-review（本 skill）
评审什么	设计 / 用例 / goal 章程 / 任意方案，或高风险代码	已写完的代码 diff（低中风险符合性核验）
时机	开工前（真值待定，找最优）	开工后（真值已定，查偏差）
真值状态	待定——正在探索方案空间	已冻结——规格 + 决策表 + 用例已拍板
模型编制	触发时按用户本机可用桥接/模型选择至少一席	Codex 单席，无多模型对比
收口者	当前主线程直接裁决（不设裁判）	分流责任人（对照冻结真值分流）
产出	采纳/驳回裁决报告	三级分类意见（不自动改码）

单模型在"符合性核验"这件事上够用，但不要把它当充分代码审查：

符合性核验有标准答案（冻结规格 + 决策表 + 用例规格 + 红线就是答案），是对照答案查偏差，一个强模型够了；硬上多方对抗既贵又会把"已拍板的取舍"翻出来重吵——那正是本 skill 要堵的风险。

但代码评审里最高价值的发现常常是"答案没覆盖到的地方出了 bug"——并发竞态、边界态、错误处理、性能。这些规格通常不下沉到逻辑级（实现细节属代码自由范围），需要正交视角（adversarial-review 的强项），单模型会系统性漏检。所以本 skill 定位是低成本符合性核验，不宣称"一个强模型就够全部代码审查"；这类风险按 §1 升档。

单模型也没有裁判席兜 GPT 的误报——这个位置由分流责任人的对照真值分流（§5）补上，而分流的默认方向是"不改除非已证实"，证据责任在"改"侧。

---

1. 什么时候用 / 不用 + 升档硬门