当你在调试里卡住、测试一连两轮还是红的、或面对多个修复方案难以取舍时，真正稀缺的不是“再多一个模型”，而是一套可审计、可复盘、边界清晰的协作流程。peer-consult 就是为此而生：
以 Codex 为主执行者，同时征询 Claude Code 与 Gemini CLI 的独立意见，再由 Codex 汇总优缺点并做可验证的裁决。这篇文章给你一个可直接落地的工作流，从安装到产物、从安全边界到常见问题，一次讲清。
一、适用场景（触发条件）
- 连续两轮定位 / 修复仍无进展，或关键测试失败且根因不清晰
- 需要在多个方案间做取舍（性能 / 兼容 / 侵入性 / 可维护性）
- 触及安全敏感面：鉴权 / 权限 / 反序列化 / 命令执行 / 依赖升级等
- 当你觉得“需要第二意见”，其实就是这条技能的入口。
二、前置条件
本机可执行命令：claude 与 gemini
python3
目标项目目录可写（产物落盘到 docs/peer_consult/）
三、推荐安装方式（用户级）
把 Skill 从仓库移到本机，全局复用，但产物仍写回目标项目：
mkdir -p ~/.codex/skills> 也可项目级运行（不推荐，但可用）：
> python3 .codex/skills/peer-consult/scripts/peer_consult.py 四、标准流程（必须按顺序）
1. 生成“咨询包”（上下文文件）
- 复制模板：~/.codex/skills/peer-consult/assets/request_template.md
- 保存为：docs/peer_consult/request.md 或 docs/peer_consult/request-<slug>.md
- 只保留关键段并完成脱敏
2. 运行脚本收集两方意见
python3 ~/.codex/skills/peer-consult/scripts/peer_consult.py \
--question "<一句话摘要>" \
--context-file docs/peer_consult/request.md- 若不在项目根目录执行：追加 --project-root <path>（或 --cd <path>）
- 如需保留原文用于调试：追加 --save-raw
3. 打开脚本生成的摘要文件，完善“Codex 裁决”
- 共识点（两方一致的根因 / 方案）
- 分歧点（各自方案的 trade-off）
- 你的选择与理由（最小改动 + 可验证性 + 风险最小）
- 测试计划（用于仲裁分歧）
4. 落地修复、跑测试、更新结论
五、输出与目录约定
默认在目标项目生成：
docs/peer_consult/
README.md
request.md # 可选：一次征询的上下文（脱敏后）
YY-MM-DD-HHMM-xxxx.md # 每次征询生成 1 份摘要（脚本自动生成）
raw/ # 仅失败或手动启用时保存原文（建议 gitignore）- 默认只保留摘要文件；原文仅在失败或 --save-raw 时写入 raw/
六、安全边界与约束（强制）
- 该 Skill 只做“意见采集”，不允许外部代理直接改代码
- 脚本不会自动读取 git diff/status；如需相关片段请手动脱敏后写入 docs/peer_consult/
- 上下文文件禁止包含密钥 / 令牌 / 个人数据；必要时先脱敏再记录
七、进阶：结构化输出契约（摘要生成用）
脚本会要求 Claude/Gemini 返回仅 JSON（无 Markdown），结构如下（数组必须存在）：
{
"root_cause_hypotheses": ["string"],
"recommended_fixes": [{"title": "string", "steps": ["string"], "risk": "low|medium|high"}],
"tests_to_run": ["string"],
"open_questions": ["string"]
}八、常见问题
Q1: 会不会改我的代码？
不会。该 Skill 只做“意见采集”和摘要汇总，最终改动仍由你执行。
Q2: 为什么不让脚本直接读 git diff/status？
为了可审计与安全边界可控，避免隐式读取敏感信息。需要的片段请手动脱敏后落盘。
Q3: 什么时候会生成 raw 原文？
当任一侧调用失败 / 解析失败，或你显式传入 --save-raw 时。
结语
peer-consult 的价值不在“再多一个模型”，而在把协作流程固定成可执行的约束：该问什么、怎么问、产物落盘、谁来裁决、如何验证。
当你把这条链路跑顺了，每一次“卡住”都会更快变成一次“确定性推进”。