wshuyi Codex 独立校验 Skill
核心理念
产出者 ≠ 审查者。用 Codex GPT-5.5 作为独立审查 Agent，对关键产出进行校验，避免自己审查自己的盲区。
降级后端（可选）：Codex 额度也有限。当 Codex 临时没额度或连不上时，自动降级到 GLM-5.2（Z.ai Coding Plan） 做独立第三方对抗式校验——GLM 是另一家厂商的模型，与产出方 Claude、主审方 Codex 都不同源，独立性成立。这是有意设计的降级路径（仅在 Codex 不可用时启用）：宁可换一个独立模型继续审，也不要因为主审方掉线就跳过校验。详见下文「## 降级到 GLM-5.2（Coding Plan）」。
关于外发的边界：默认后端是
auto——Codex 不可用时它会自动把待校验内容发给第三方 Z.ai（GLM-5.2），并在发送前打印一条 stderr 警告。若不希望任何内容外发给第三方，请用VERIFY_BACKEND=codex（Codex 挂了直接报错，绝不降级）。降级路径需要ZAI_API_KEY；未设置时auto在尝试降级时会以"key 未设置"明确报错。
触发词
- "codex 校验"、"独立验证"、"计划校验"
- "codex verify"、"verify plan"、"code review"
- "/codex-verify"
调用方式
主路径（开箱即用）：本 skill 自带脚本 scripts/verify.sh，不依赖任何额外插件。
| 场景 | 方式 | 说明 |
|---|---|---|
| 计划/方案校验 | bash verify.sh plan ... |
默认模式 |
| 代码审查 | bash verify.sh review [目录] |
需在 git 仓库内 |
| Skill 冲突检测 | bash verify.sh skill ... |
|
| Codex 没额度/连不上 | VERIFY_BACKEND=glm bash verify.sh ... 或 bash scripts/glm-review.sh "prompt" |
GLM-5.2 (Coding Plan) 独立校验 |
可选路径（需自行安装 codex 插件）：如果你的 Claude Code 另装了提供 /codex:rescue、/codex:review 等 slash command 的 codex 插件，交互场景下可直接用它们（无需 Bash）；先用 Read 读取待校验文件，将全文拼入 prompt（slash command 不支持 $(cat ...) 展开）。这些命令由该插件提供，不随本 skill 安装——没有它时一律走上面的脚本路径。
三种校验模式
模式 1：计划/方案校验（默认）
适用场景：修复方案、实施计划、调研报告事实卡片、任何关键结构化产出。
校验维度：
- 可行性：涉及的文件/API/依赖是否存在、版本是否正确
- 完整性：是否遗漏关键步骤或边界情况
- 一致性：步骤之间是否有矛盾或依赖冲突
- 数据准确性：关键数字/价格/版本号是否需要二次验证
调用方式：
bash ~/.claude/skills/codex-verify/scripts/verify.sh plan "待校验的完整内容"
或注入文件内容：
bash ~/.claude/skills/codex-verify/scripts/verify.sh plan "$(cat /path/to/plan.md)"
模式 2：代码审查
适用场景：跨多文件的复杂代码变更、需要追踪调用链的修改。
注意：简单的单文件局部改动不需要 Codex，用独立 Claude Agent 更快。
调用方式：
# 在 git 仓库中执行
bash ~/.claude/skills/codex-verify/scripts/verify.sh review [目录路径]
隐私提示：review 会把工作区相对 HEAD 的未提交变更交给审查后端。其中 GLM 降级路径会把 untracked 文本新文件的全文一并拼入 prompt（binary 文件按 git diff 表现）；Codex 原生 review 走 codex exec review --uncommitted，untracked 的处理以 codex CLI 行为为准。脚本在发送前会用 git ls-files --others 把 untracked 文件列出来警告。运行前先 git status --short 确认没有 .env、密钥、私人笔记等被一并带上；不想上传的文件先加进 .gitignore 或移出工作区。
模式 3：Skill 冲突检测
适用场景：向 Skill 写入新规则前，检测与现有规则的冲突。
校验维度：
- (A) 矛盾：新规则与现有规则的要求相反
- (B) 语义重叠但措辞冲突：说的是同一件事但表述不一致
- (C) 重复/可合并：新规则与现有规则高度重叠，应合并为一条
调用方式：
bash ~/.claude/skills/codex-verify/scripts/verify.sh skill \
"新规则草案" \
"/path/to/SKILL.md" \
"/path/to/references/file1.md" \
"/path/to/references/file2.md"
降级到 GLM-5.2（Coding Plan）
后端选择（VERIFY_BACKEND）
verify.sh 三种后端，由环境变量 VERIFY_BACKEND 控制：
| 值 | 行为 |
|---|---|
auto（默认） |
先用 Codex；Codex 没装 / 没额度 / 连不上 → 自动降级 GLM-5.2 (Coding Plan) |
codex |
只用 Codex，不降级（Codex 挂了直接报错） |
glm |
直接走 GLM-5.2 (Coding Plan)，跳过 Codex |
降级判定（脚本里的 codex_should_degrade）：仅当 Codex 进程非零退出时才考虑降级，分支如下——
- 命中明确的认证/配置错误特征（401 / 403 / unauthorized / login required …）→ 暴露，不降级（让你去修，例如
codex login）； - 命中明确的额度/连接/传输层特征（usage limit / 429 / 5xx / connection refused / timed out / overloaded …）→ 降级；
- 输出完全为空（纯传输崩溃，连错误信息都没有）→ 降级；
- 其余情况（有文字但无不可用特征，含未知短错误、脚本 bug）→ 暴露，不用 GLM 静默掩盖。
Codex 正常退出（rc=0）一律视为正常审查，绝不因为评审正文里恰好出现上述词就降级。
为什么走 Coding Plan 而不是按量计费 API
- 端点：API base 为
https://api.z.ai/api/coding/paas/v4（Coding-Plan 专属，没有按量计费通路），脚本实际请求的完整 URL 是…/paas/v4/chat/completions；需配套一把 Z.ai Coding Plan 的ZAI_API_KEY。若用GLM_REVIEW_ENDPOINT覆盖，必须填完整的 chat completions URL。 - 判定方式：Coding-Plan key 被 coding-exclusive 端点接受（HTTP 200）即说明计费归属 Coding Plan；Z.ai 计费在服务端按「端点 + key」判定，与客户端无关。
- 对比：
/api/anthropic是 dual-mode（既可 Coding Plan 也可按量），/api/paas/v4是按量计费——本 skill 默认不用这两个，只用 coding-exclusive 端点，零计费歧义。 - 例外：
GLM_REVIEW_ENDPOINT可覆盖默认端点。一旦你显式改写，计费与数据外发边界由你自负，上面的"零计费歧义"不再保证。
独立校验脚本 glm-review.sh
scripts/glm-review.sh 是独立的第三方对抗式审查器，可被 verify.sh 调用，也可单独用：
bash ~/.claude/skills/codex-verify/scripts/glm-review.sh "待校验的完整 prompt"
echo "prompt" | bash ~/.claude/skills/codex-verify/scripts/glm-review.sh
环境变量：GLM_REVIEW_MODEL(默认 glm-5.2)、GLM_REVIEW_MAX_TOKENS(默认 16000，GLM-5.2 是推理模型，reasoning 占用大)、GLM_REVIEW_RETRIES(默认 4，对 429/5xx/网络错误指数退避)。
GLM 的 system prompt 已内置「默认怀疑 / 无法访问本地文件，须核对的明说『需本地核对』/ 逐维度 PASS-FAIL + 总评」的对抗式审查立场。
GLM 降级后的 FAIL 处置
与 Codex 同规则（见下），唯一差异：GLM 同样无法访问本地文件系统，凡结论依赖本地核对的，它会标「需本地核对」——这类项由本机 shell 实测补证，不能臆断为通过。
FAIL 处置规则
正常 FAIL → 必须修正
Codex 返回 FAIL 时，逐条处理每个问题：
- 已修正：按 Codex 建议修改
- 反驳（附证据）：用可验证证据（DOI 查询、API 返回、测试结果）反驳
- 不适用（附理由）：说明当前语境下不适用
P0 级问题全部解决前，不得进入下一阶段。
Codex Sandbox 无法核对本地的误判
Codex GPT-5.5 在 read-only sandbox 中无法 shell 核对本地文件，因此可能对你的本地路径、配置载体、工具版本做出与实际不符的断言（例如猜错某个规则文件的位置，或假设了一个并不存在的默认配置）。
处置：仅当某条 FAIL 的唯一依据是这类「无法核对的本地断言」时，才记为「反驳（Codex sandbox 无法核对本地）」，并用本机 shell 实测补一份证据。如果同一轮 FAIL 还夹带其他实质问题，必须逐条处理，不得借此一并跳过。
二次判断权
可以质疑 Codex 的发现，但必须用可验证证据：
- 运行测试覆盖 Codex 指出的边界场景
- 提供 DOI 查询结果、原文截图、API 返回数据
- 将测试结果纳入修订版，重新提交 Codex 校验
铁律：不能用"Agent 也可能有误"等理由单方面否决审查结论。
校验通过后的行为
校验通过 → 直接执行/交付，不需要问用户"可以开始吗？"
只有以下情况才停下来向用户核对：
- 拿不准某个决策（多种合理方案，无法判断用户偏好）
- 无法继续（缺少信息、权限不足）
- 不可逆的高风险操作（删除生产数据、force push 等）
技术参数
下表参数用于 plan / skill / custom 模式（底层
codex exec）。review 模式走codex exec review，它本身要求在 git 仓库内，不传--skip-git-repo-check。
| 参数 | 值 | 说明 |
|---|---|---|
| 模型 | gpt-5.5 |
Codex CLI 默认校验模型（CODEX_MODEL 可覆盖） |
| 推理强度 | model_reasoning_effort=xhigh |
最高推理深度（CODEX_EFFORT 可覆盖） |
| 沙箱 | read-only |
只读，校验过程不修改任何文件 |
| 会话 | --ephemeral |
不持久化 session |
| Git 检查 | --skip-git-repo-check |
允许在非 git 目录运行（plan/skill/custom） |
| 降级模型 | glm-5.2 |
Codex 不可用时的独立第三方校验（Z.ai Coding Plan） |
| 降级端点 | https://api.z.ai/api/coding/paas/v4/chat/completions |
Coding-Plan 专属，非按量计费；GLM_REVIEW_ENDPOINT 覆盖须为完整 URL |
注意事项
- 校验 prompt 必须包含完整内容：不能简化/摘要后提交，否则 Codex 无法准确校验
- 文件内容用
cat注入：需要 Codex 审查文件时，将内容注入到 prompt 中 ~/.claude不是 git 仓库：必须加--skip-git-repo-check- Codex 无
--fast参数：速度通过model_reasoning_effort调节（xhigh/high/medium/low） - 提示注入防护是尽力而为，且按"后端 × 模式"分情况：
- Codex 后端：
INJECT_GUARD只加在 plan / skill；custom原样透传（注入边界调用方自负）；Codex 原生review（codex exec review）走 Codex 自身流程、不加 本 skill 的 guard。 - GLM 后端：
glm-review.sh的 system prompt 始终带不可信数据 guard，所以任何走到 GLM 的调用（含custom、降级的review）都带 guard。 - 这是缓解、不是硬保证——别因为返回 PASS 就对本不可信的产物照单全收。
- Codex 后端：