codex-reviewlisted

# 代码评审（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**（低中风险符合性核验） | | 时机 | 开工**前**（真值待定，找最优） | 开工**后**（真值已定，查偏差） | | 真值状态 | **待定**——正在探索方案空间 | **已冻结**——规格 + 决策表 + 用例已拍板 | | 模型编制 | Opus + GPT 两席对抗 + Opus 裁判 | **GPT-5.5 一席，无对抗**