多模型代码审查

解决什么问题

当代码由同一模型生成并审查时，模型倾向于沿用相同的思考路径，导致自身逻辑盲区被忽略。这种「自我确认」在处理资金、登录、支付或批量脚本等高风险改动时尤为危险，可能漏掉终态判定错误、串号风险或幂等性缺陷。本技能通过强制 作者模型与审查模型分离，打破单一模型的思维惯性。

核心工作方式

技能通过「角色锁定」和标准化工作流确保审查的独立性：

• 角色分离：Writer（编写者）负责实现与修复，禁止自行宣布审查通过；Reviewer（审查者）仅负责只读分析与输出风险报告，禁止直接修改业务代码。两者必须由不同模型或会话扮演（如 Claude ↔ Codex）。
• 冻结变更集：锁定待审查的文件列表，防止「顺带重构半个仓库」导致审查范围失控。
• 结构化审查包：向 Reviewer 提供目标行为、变更文件、风险面（密钥、并发等）及测试命令，确保审查可独立运行。
• 强制输出格式：Reviewer 必须按 P0/P1/P2 分级输出问题，无问题时需明确标注 no P0/P1 found 并列出剩余风险，禁止空泛的「LGTM」。
• 证据化修复：Writer 需为每个 P0/P1 问题提供最小回归证明（如测试输出或 commit），二次确认环节仅检查问题是否关闭。

资金与加密货币额外检查

涉及链上操作、登录或批量任务时，Reviewer 必须核查：

• 成功判定是否依赖终态权威信号（如 txHash/回调），而非中间步骤。
• 是否存在串号风险（如钱包连接错误环境）。
• 私钥、助记词是否意外落入日志。
• 失败场景是否诚实计数，避免静默丢单。

适用边界与注意点

• 适用场景：功能合并前审查、批量脚本/钱包/支付改动、用户主动请求「找坑」。
• 不适用场景：单行文案微调、纯格式化等低风险改动。
• 常见陷阱：Writer 自审自称 multi-model、Reviewer 顺手改代码导致轨迹丢失、仅报风格问题而漏检资金/并发风险、无测试证据却宣布 clean。
• 合规约束：仅处理用户自有或已授权的系统与数据，日志必须脱敏；涉及支付、签名等不可逆操作前，必须取得用户明确确认。