mcpField
M
multi-model-code-review

multi-model-code-review

github.com/cosmastech测试与质量543 次安装4 周前更新
代码仓库

关于 multi-model-code-review

multi-model-code-review 是通过多个 AI 模型审查代码改动的工作流技能，面向希望在人工审查前发现问题的开发者。它并行收集评审意见、综合反馈、实施修复，并可重复审查。

主要功能

  1. 01准备分支专属审查上下文
  2. 02并行调用多个模型评审
  3. 03分类并综合评审反馈
  4. 04根据反馈实施修复
  5. 05必要时重复审查

适用场景

  1. 01在提交人工审查前检查改动
  2. 02比较不同模型发现的问题
  3. 03根据评审意见迭代修复代码

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/cosmastech/skills --skill multi-model-code-review

安装后在 Claude Code 中输入/multi-model-code-review确认已加载。

附带文件assets/code-review-prompt-template.md

详细介绍

多模型代码审查

使用多个 AI 模型审查代码变更，在人工审查前发现问题。每个模型独立审查，汇总反馈、进行修改，然后重复这一流程，直到代码足够完善。

前提条件

至少安装并完成身份验证的智能 CLI：

CLI验证方式打印模式标志
Cursor Agentagent --versionagent --model <model> --print "<prompt>"
Claude Codeclaude --versionclaude --model <model> -p "<prompt>"
OpenAI Codexcodex --versioncodex --model <model> -q "<prompt>"

如果已安装 Cursor 的 agent，始终优先使用它并指定模型，而不是混用不同的 CLI 工具。

工作流

1. 准备审查上下文

创建一个限定于当前分支的工作目录，确保不同审查的产物不会相互冲突：

BRANCH=$(git rev-parse --abbrev-ref HEAD)
REVIEW_DIR="/tmp/code-review-${BRANCH}"
mkdir -p "$REVIEW_DIR"

收集差异内容以及审查者所需的相关上下文。使用 assets/code-review-prompt-template.md 中的模板，将其写入 $REVIEW_DIR/。

git diff <parent-branch>...HEAD > "$REVIEW_DIR/diff.txt"

在 $REVIEW_DIR/review.md 中编写审查提示词。内容包括：

  • 来源 — 工作的来源（工单链接、用户对话、事件、规格说明/RFC）。这能让审查者了解“原因”。
  • 变更内容及原因 — 简要概述目标。
  • 差异内容 — 实际的代码变更。
  • 关键文件 — 新建或大幅修改文件的完整内容（仅有差异可能无法为新类提供足够上下文）。
  • 相关约定 — 审查者应遵循的项目专属模式（例如命名、日志记录和测试约定）。
2. 并行发送给模型

在一条消息中同时发起两项审查请求，让它们并行运行。 使用用户偏好的 CLI 和模型。如果用户没有指定，则应始终使用来自两个不同提供商的最新高思考能力模型。

不要假设哪些模型可用。始终先通过 CLI 工具检查。

例如：

将每个模型的输出保存到 $REVIEW_DIR/，以便结果与生成它们的提示词一同保留：

# Cursor Agent
agent --model gpt-5.5-extra-high --print "$(cat "$REVIEW_DIR/review.md")" 2>&1 | tee "$REVIEW_DIR/response-gpt.md"
agent --model claude-opus-4-7-thinking-xhigh --print "$(cat "$REVIEW_DIR/review.md")" 2>&1 | tee "$REVIEW_DIR/response-opus.md"

# Claude Code
claude --model claude-sonnet-4-20250514 -p "$(cat "$REVIEW_DIR/review.md")" 2>&1 | tee "$REVIEW_DIR/response-sonnet.md"

# OpenAI Codex
codex --model o3 -q "$(cat "$REVIEW_DIR/review.md")" 2>&1 | tee "$REVIEW_DIR/response-o3.md"
3. 汇总反馈

收到两份回复后：

  1. 将每条反馈归类为关键、建议或琐碎。
  2. 找出共识——这些是可信度较高的问题。
  3. 找出分歧——通过检查实际代码库来判断哪个模型的看法正确。
  4. 对错误的反馈提出质疑（参见下方的指南）。
  5. 向用户总结汇总结果。
4. 实施修复

处理关键和建议类反馈。对于每项修复：

  • 进行修改。
  • 说明这项修改是由哪位审查者的反馈促成的。
5. 必要时重新审查

将更新后的代码发回进行新一轮审查。 琐碎修复（拼写错误、注释调整）无需重新审查。

重复上述流程，直到：

  • 没有尚未解决的关键问题。
  • 两个模型都通过，或仅建议进行少量修改后通过。
6. 提交人工审查

AI 审查者认可后，推送分支并创建 MR/PR。 AI 审查轮次是质量门槛，而不是人工审查的替代品。

准则

  • 始终使用思考型模型。 代码审查需要深入推理代码行为、边界情况和执行顺序。切勿使用非思考型模型（例如 gpt-4o、claude-sonnet）。请使用具备扩展思考能力的模型（例如 gpt-5.3-codex-high、composer-2、claude-sonnet-4-thinking、o3）。
  • 使用不同的提供商。 同一提供商的模型存在相同的训练偏见。至少使用两个不同的提供商，以获得真正多元的观点。
  • 在不提供先前背景的情况下发送审查请求。 不要在审查提示词中加入你自己的评估或观点。每个模型都必须仅根据代码独立判断。
  • 质疑错误的反馈。 达成共识不等于盲从。如果审查者建议的修改与项目惯例相矛盾、误读了代码或会引入回归，就要提供证据并提出异议。在下一轮审查中附上更正，让模型结合背景进行判断。模型再自信，也不代表它一定正确。
  • 让审查者查看代码库。 使用支持工作区访问的 CLI 时（例如带有 --print 参数的 agent），请从仓库根目录运行，以便审查者读取差异之外的文件，了解更多背景。
  • 不要敷衍了事。 如果两个模型都认为“看起来没问题”，但你发现了问题，就要指出来。模型是审查者，不是权威。
  • 保留现有测试覆盖率。 如果审查者建议移除或削弱测试，除非有明确理由（例如测试断言的是已更改的实现细节），否则应拒绝。

评论

支持 Markdown