# 代码审查委员会（Copilot 多型号）使用 GitHub Copilot CLI 进行多轮代码审查流程，不同模型作为独立审查者，Claude 作为综合者和主持人。每个模型都充当小组中的单独审阅者。第一轮之后的每一轮都是可选的。与文档审查技能不同，这里的模型接收**审查目标**（PR 编号、分支、提交或“未提交”），并使用自己的工具来获取差异、浏览文件和调查代码库。没有差异通过管道传输到提示中。 ## 为什么选择副驾驶 * 单一 CLI、单一订阅——OpenAI、Google、Anthropic 没有单独的 API 密钥 * 访问 GPT、Claude 和 Gemini 系列的 16 多个模型 * Copilot 订阅涵盖的代币成本 * 无论型号如何，一致的 CLI 界面 ## 可用模型（动态发现）模型是在运行时发现的。不要对模型列表进行硬编码。 **要获取当前模型列表**，请运行： gh 副驾驶 -- --help 2>&1 | tr '\n' ' ' | grep -o '"claude-[^"]*"\|"gpt-[^"]*"\|"gemini-[^"]*"\|"o[0-9][^"]*"' | tr -d '"' | 排序这会解析帮助输出中的“--model”选项。随着提供商添加/删除模型，模型会随着时间的推移而发生变化。 **按提供商对发现的模型进行分类：** * `gpt-*` \-- OpenAI * `claude-*` \-- 人择 * `gemini-*` \-- 谷歌 * `o*`（例如`o3`、`o4-mini`）——OpenAI 推理 **要构建默认面板**，请使用以下优先顺序为每个提供商选择一个模型： * OpenAI：最大的`gpt-*-codex`变体>最大的`gpt-*`>任何`gpt-*` * 人择：`claude-sonnet-*`（平衡）> `claude-opus-*`（如果没有十四行诗） * 谷歌：任何“gemini-*” **要构建最大深度面板**，请为每个提供商选择最有能力的模型： * OpenAI：最大的“gpt-*-codex”或“gpt-*-codex-max”变体 * Anthropic：`claude-opus-*`（非快速变体） * 谷歌：任何“gemini-*” **要构建快速面板**，请选择最快/最便宜的： * 任何 `gpt-*-mini` 或 `claude-haiku-*` ## 先决条件必须安装 GitHub Copilot CLI： gh 副驾驶 -- --版本 2>/dev/null 如果不可用，则报告错误并停止。 ## 型号选择 ### 第 0 步：发现型号并选择面板 **首先，通过运行上面“可用模型”部分中的发现命令来发现可用模型**。将输出解析为列表并按提供者（OpenAI/Anthropic/Google）进行分类。 **然后，使用“可用模型”部分中的首选项规则从发现的模型动态构建预设面板**。 **然后询问**用户希望如何使用“AskUserQuestion”来组成评论面板。显示每个预设中的实际模型名称（不是硬编码名称）：我该如何组成评审小组？ 1) 默认面板（、、）——每个提供商都有一个（推荐） 2) 选择模型 -- 我将向您展示个可用模型的完整列表 3) 所有提供商，最大深度 -- 、、 4）快速回顾——、（快速，两个模型）如果用户选择“选择模型”，请呈现完整的发现模型列表，并让他们使用多选“AskUserQuestion”选择 2-4 个模型。存储所选模型以供所有回合使用。 ## 查看目标（4 个输入类型）该技能审查代码更改，而不是文档。从调用参数中检测审查目标： ### 检测规则 1. **PR 审查** \-- 参数匹配 `#` 或包含 `github.com/.*/pull/`。提取 PR 号。 2. **提交审核** \-- 参数是一个 7-40 个字符的十六进制字符串（匹配 `^[0-9a-f]{7,40}$`）。使用“git rev-parse --verify ”进行验证。 3. **未提交的更改** \--参数字面意思是“未提交”。 4. **分支审查** \-- 其他任何内容。使用“git rev-parse --verify ”验证分支是否存在。 **如果不明确**（例如，看起来像十六进制字符串的分支名称），请通过“AskUserQuestion”询问用户：““abc1234”是提交 SHA 还是分支名称？ **如果未提供参数**，请通过“AskUserQuestion”询问用户要查看的内容，选项包括：PR 编号、分支名称、提交 SHA 或未提交的更改。 ### 收集变更元数据检测到目标后，收集上下文前导码的元数据： * **PR:** `gh pr view --json 标题、正文、添加、删除、changedFiles、baseRefName、headRefName、文件` * **分支：** `git log --oneline main..` 用于提交列表，`git diff --stat main...` 用于文件统计信息 * **提交：** `git log -1 --format='%s%n%n%b' ` 用于消息，`git diff --stat ^..` 用于文件统计信息 * **未提交：** `git diff --stat` 用于暂存+未暂存，`git status --short` 用于未跟踪文件存储：更改摘要、文件计数、添加/删除、受影响区域。 ### 文件过滤在将差异发送给审阅者之前，排除产生噪音而不是信号的文件。将此说明添加到审阅提示中，以便模型也跳过它们。 **始终跳过这些模式**（生成的代码、供应商的 deps、锁定文件）： * `供应商/`、`node_modules/`、`第三方/` * `*.pb.go`、`*_pb2.py`、`*.pb.h`、`*.pb.cc` （生成 protobuf） * `*_generate.*`、`*_gen.go`、`*.gen.ts` * `*.lock`、`package-lock.json`、`yarn.lock`、`go.sum`、`Cargo.lock` * `*.min.js`, `*.min.css`（缩小资源） * `*.snap` （测试快照） * `swagger_*.go`、`*_swagger.json`、`openapi_*.yaml` （生成 API 规范） * `mocks/*`、`*_mock.go`、`mock_*.py` （生成的模拟） **在审核提示中包含以下内容：** 完全跳过这些文件——不检查生成的代码、供应商的依赖项或锁定文件：供应商/、node_modules/、第三方/、*.pb.go、*_pb2.py、*_ generated.*、*_gen.go、 *.lock、package-lock.json、go.sum、*.min.js、*.min.css、*.snap、mocks/* 如果更改的文件与这些模式匹配，请记下“已跳过（生成/供应）”并继续。 **收集更改元数据时**，还要计算跳过的文件数量，以便用户了解有效的审查范围。 ## 模式检测该技能支持两种模式。从调用参数中检测模式： * **审查模式**（默认）： `/code-review-copilot ` 或 `/code-review-copilot “焦点区域”` \-- 完整的 7 类代码审查，带有可选的反驳/共识回合。 * **辩论模式** : `/code-review-copilot Debate "question1" "question2"` \-- 将设计辩论集中在特定的代码问题上。 **检测规则：** 如果第一个参数字面意思是“辩论”，则进入辩论模式并将剩余参数解析为““question1”“question2”...`。否则，进入审阅模式。 **如果仅作为“/code-review-copilot Debt”调用而没有进一步的参数**，请通过“AskUserQuestion”询问审查目标和辩论问题。模式分割下的所有内容——CLI 调用、模型发现、目录访问、后台任务、上下文前导码、清理——在两种模式之间共享。 ## 复习重点（可选）用户可以选择在目标后指定焦点区域： * `/code-review-copilot #42“关注身份验证更改”` * `/code-review-copilot 未提交“专注于错误处理”` 如果存在，它将作为焦点指令添加到审阅提示中。如果没有它，模型就会对所有 7 个类别进行全方位审查。 ## 文件组织所有中间文件都位于项目根目录的临时工作目录中。最终的可交付成果位于项目根目录的“.code-reviews/”目录中。 **临时目录：** `$PROJECT_DIR/.code-review-copilot-<目标>/` * `<目标>` = `pr-42`、`branch-feature-x`、`commit-abc1234` 或 `未提交` 在工作流程开始时创建此目录。 **最终可交付成果**（在“$PROJECT_DIR/.code-reviews/”中）： * `-review-consolidated.md` \-- 始终生成（审核模式，第 1 轮） * `-consensus.md` \-- 仅当第 3 轮运行时（审核模式） * `-decisions.md` \-- 仅当第 4 轮运行时（审核模式） * `-debate.md` \-- 始终生成（辩论模式） **临时文件**（在工作目录中，最后清理）： * `context-preamble.md` \-- 审阅者的项目上下文和更改元数据 * `review-.md` \-- 每个模型的原始评论（评论模式） * `rebuttal.md` \-- 克劳德的反驳（评论模式） * `rebuttal-.md` \-- 每个模型对反驳的回应（审查模式） * `debate--q.md` \-- 每个问题的每个模型的原始参数（辩论模式） * `counter--q.md` \-- 第二轮的反驳回应（辩论模式） **清理：** 当工作流程完成时，询问用户是否保留或删除临时工作目录。默认：删除。 ### 设置命令 mkdir -p "$PROJECT_DIR/.code-review-copilot-<目标>" mkdir -p“$PROJECT_DIR/.code-reviews” ## CLI 调用详细信息所有评论都通过一个 CLI：“gh copilot”。 **重要的外壳细节：** * 使用 `-p` 进行非交互式提示执行。 * 使用“-s”（静默）来抑制统计数据并获得干净的输出。 * 使用 `--model` 为每个审阅者选择特定模型。 * 使用 `--add-dir` 为模型提供对项目代码库的访问权限。 * 使用 `--allow-all-tools` 让模型在没有提示的情况下浏览文件、运行 git 命令等。 * 使用 `--no-custom-instructions` 来防止本地仓库指令导致审查出现偏差。 * 对所有 Bash 调用设置“超时：600000”。 * 同时运行所有模型作为后台 Bash 任务 (`run_in_background: true`)。 * 使用带有“block: true”和“timeout: 300000”的“TaskOutput”来等待每个。 * 使用 `2>&1 | 捕获输出tee "$OUTPUT_FILE"` \-- 不要使用 `> file 2>/dev/null` 因为某些模型（特别是 Gemini）会使用 shell 重定向生成空文件。 ### 工作目录使用 git 存储库根作为“$PROJECT_DIR”。确定它： git rev-parse --show-toplevel 如果不在 git 存储库中，则报告错误并停止（代码审查需要 git）。 ### 目录访问（关键）外部模型需要三件事来浏览代码库： 1. **CWD 设置为项目根目录** \-- 在调用 `gh copilot` 之前`cd "$PROJECT_DIR"`。这使得项目成为模型的工作目录，以便正确解析相对路径。 2. **`--add-dir` 用于显式路径白名单** \-- 仍然传递 `--add-dir "$PROJECT_DIR"` 作为安全网。 3. **提示中的项目路径** \-- 明确告诉模型代码所在的位置：“项目源代码位于`$PROJECT_DIR`。”可以浏览文件的模型需要知道路径。 ### 代码状态约束（关键）当审查目标是分支或提交时，模型必须检查该特定 git ref 处的代码——而不是 HEAD、不是 main、不是 dev。如果没有显式约束，模型将浏览当前签出的所有内容，并可能引用审查目标中不存在的代码。 **根据评论类型构建git约束指令：** * **PR：** 不需要任何约束 - `gh pr diff` 返回正确的差异，无论结帐状态如何。 * **分支：** `重要提示：在浏览任何源文件之前，请运行“git checkout ”以确保您正在以正确的状态检查代码。不要查看 HEAD、main、dev 或任何其他分支。所有文件读取和 git 命令都必须反映“”的状态。` * **提交：** `重要提示：在浏览任何源文件之前，请运行“git checkout ”以确保您正在以正确的状态检查代码。不要查看 HEAD、main、dev 或任何其他分支。所有文件读取和 git 命令都必须反映提交“”的状态。` * **未提交：** 不需要任何约束——未提交的更改针对当前工作树。将此指令包含在发送给外部模型的所有提示中（评论、反驳、辩论、反驳）。 ### 调用模式（代码审查）与文档审阅不同，没有文件内容通过管道传送到提示中。模型获取自己的差异。对于面板上的每个型号： cd "$PROJECT_DIR" && gh copilot -- -p "${PROMPT}" --model "$MODEL" --add-dir "$PROJECT_DIR" --allow-all-tools --no-custom-instructions -s 2>&1 |三通“$OUTPUT_FILE” `$PROMPT` 包括上下文前导码和审查指令。模型使用 git 命令和文件浏览来调查更改。 ### 显示名称在所有输出文件中，使用模型 ID 作为审阅者名称（例如“gpt-5.2”、“claude-sonnet-4.5”）。当所有评论都来自同一个 CLI 时，这比发明别名更清晰。 ** ** ## 第一轮：初步审查 + 综合这一轮总是进行。 ### 第1步：解析审核目标使用上面的检测规则解析调用参数以检测审查目标类型（PR、分支、提交或未提交）。如果没有争论或不明确，请通过“AskUserQuestion”询问。如果提供的话，还提取可选的焦点区域（目标后面带引号的字符串）。 ### 第 2 步：验证和设置 1. 验证这是一个 git 存储库：`git rev-parse --show-toplevel`。如果没有，就停下来。 2. 验证审核目标是否存在： * PR: `gh pr view --json number` 必须成功 * 分支： `git rev-parse --verify ` 必须成功 * 提交： `git rev-parse --verify ` 必须成功 * 未提交： `git status --short` 必须显示更改（如果干净的工作树，则报告“无需审查”并停止） 3. 验证 Copilot CLI：`gh copilot -- --version 2>/dev/null`。如果不可用，请停止。 4. 如果尚未完成，请运行模型选择（上面的步骤 0）。 5. 收集变更元数据（请参阅上面的“收集变更元数据”部分）。 6. 创建临时工作目录和 `.code-reviews/` 目录。 7. 告诉用户：“审阅面板：。目标：”。无需确认。 ### 步骤 2.5：构建上下文序言外部模型仅收到审查提示——它们不了解项目、存储库或约束。克劳德确实从当前会话中获得了此上下文。使用它。 **生成上下文前导码**并将其写入`/context-preamble.md`。通过收集您从对话和文件系统中了解到的信息来构建序言。在项目根目录上运行“ls”以发现结构。检查 README、go.mod、package.json、Makefile、Dockerfile 等来识别技术堆栈。使用这个模板： ## 审稿人的背景 > 此上下文描述了正在审查的项目和变更。 > 用它来校准您的评论。 **项目：** <这个项目是什么> **技术堆栈：** <语言、框架、关键依赖项> **环境：** <运行的地方> **更改摘要：** <此 PR/分支/提交的作用，来自 PR 描述或提交消息> **更改的文件：** 个文件，<添加>+/<删除>- **受影响的关键领域：** <哪些包/模块/组件受到影响> **已知限制：** - <影响审核的限制> **查看焦点：** <如果用户指定了焦点区域，请在此处说明；否则“全方位审查”> --- **规则：** * 将其控制在 25 行以内。 * 仅包含您有信心的事实。 * 省略您没有信息的部分——更短、更准确的序言胜过填充的序言。 * 约束部分是最重要的——它指导审稿人关注的重点。 ### 第 3 步：收集评论将审阅提示并行发送到所有选定的模型。提示告诉每个模型要查看哪些内容以及如何获取更改。将 `$PROJECT_DIR`、`$TARGET_INSTRUCTION` 和 `$PREAMBLE_FILE` 替换为实际值。 **根据复习类型构建目标指令：** * **PR:** `审核拉取请求 #。运行“gh pr diff ”以查看完整的差异。运行“gh pr view ”以获取 PR 描述。 * **分支：** `查看分支 '' 与主分支相比的更改。运行“git diff main...”以查看完整的差异。运行“git log --oneline main..”以获取提交历史记录。 * **提交：** `审查提交。运行“git show ”以查看完整的差异和提交消息。 * **未提交：** `查看工作树中所有未提交的更改。对于未暂存的更改运行“git diff”，对于暂存的更改运行“git diff --cached”，并运行“git status”来查看未跟踪的文件。回顾所有这些。` **审核提示：** 您是执行代码审查的首席工程师。 $（猫“$ PREAMBLE_FILE”） $TARGET_INSTRUCTION 重要提示：项目源代码位于当前工作目录 ($PROJECT_DIR) 中。您必须使用 git 命令和文件浏览来调查更改。请按照下列步骤操作： 1. 使用上面的命令获取差异。 2. 仔细阅读 diff 输出。 3. 对于每个更改的文件，浏览完整文件以了解周围的代码和上下文。 4. 然后才开始审查——不要仅根据差异进行审查。检查更改是否与现有代码库模式一致。 $GIT_CONSTRAINT_INSTRUCTION $FOCUS_DIRECTIVE 查看这些类别的代码更改： 1) **正确性和逻辑性** - Bug、错误的假设、不正确的行为 - 相差一错误、竞争条件、逻辑缺陷 - 代码是否按照提交消息/PR 描述所述执行操作？ 2) **错误处理和边缘情况** - 缺少错误路径、未处理的异常 - 边界条件、nil/null derefs、空集合 - 当输入意外时会发生什么？ 3) **安全** - 注入漏洞（SQL、命令、XSS） - 身份验证绕过、权限提升 - 代码中的秘密或凭证、输入验证不足 - 数据暴露风险 4) **测试** - 是否有针对这些变化的测试？它们足够了吗？ - 未经测试的代码路径，缺少边缘情况测试 - 测试质量——测试实际上是验证行为还是只是练习代码？ 5) **性能和资源** - 不必要的分配、N+1查询、无限增长 - 缺少超时、连接泄漏、资源清理 - 算法复杂性问题 6) **API和接口设计** - 对公共 API 的重大更改 - 向后兼容性、版本控制 - 命名一致性、参数设计 7) **可维护性** - 可读性，不必要的复杂性 - 死代码、注释掉的代码 - 意图不明确，缺少未来读者的上下文 - 与代码库中现有模式不一致如果某个类别没有发现任何问题，请为该类别写“未发现问题”，而不是省略它。这有助于区分“已审核且干净”与“已跳过”。对于每个发现，您必须引用特定的文件和行号。使用格式：“path/to/file.go:42”或“path/to/file.go:42-55”作为范围。如果无法确定确切的行，请浏览带有行号的文件来查找它。不要引用未通过阅读实际文件验证的行号。直接指出缺陷。建议具体修复。如果代码是干净的，请这样说—— 不要发明问题。对扎实的代码进行简短的审查比填充的代码更好回顾一下挑剔的风格。目标是信号而不是音量。包含 8 个有充分依据的发现的综述优于 25 项调查结果中，一半是风格挑剔。仅标记此更改引入的问题。周围代码中预先存在的问题超出范围 - 即使您在浏览上下文时注意到它们，也不要标记它们。问问自己：“如果作者知道这个问题，他们会修复这个问题吗？”如果答案是 “不，因为它是故意的”或“不，因为它早于此更改”，请跳过它。如果您声称更改可能会破坏其他地方的某些内容，则必须确定具体的更改已证明受到影响的代码。 “这可能会破坏呼叫者”并不是一个发现。 “这破坏了`handler.go:88`，它传递了一个现在需要 int 的字符串”。不要标记以下内容——这些都是噪音，而不是发现： - 未更改的代码缺少文档字符串、注释或类型注释 - 导入排序或分组样式 - 变量命名风格首选项（camelCase 与 Snake_case）除非更改本身不一致 - 当前处理正确时建议更具体的异常类型 - const 与 let/var 风格偏好 - 将日志记录添加到故意省略的代码中 - 空格、格式或行长度，除非它会导致真正的可读性问题保持你的语气就事论事。不要表扬（“干得好……”）或道歉。陈述问题，陈述其重要性，提出解决方案。继续前行。对于每个发现，分配一个从 1 到 10 的严重性分数： - 9-10：将导致数据丢失、安全漏洞或生产中断 - 7-8：正常使用时会出现的错误 - 5-6：边缘情况错误、缺少验证或错误处理不正确 - 3-4：性能问题、测试差距或 API 设计问题 - 1-2：可维护性建议，轻微的可读性改进还指定一个从 0.0 到 1.0 的置信度分数： - 0.9-1.0：确定——您阅读了代码并验证了错误的存在 - 0.7-0.8：高——强有力的证据，但取决于运行时行为，您无法静态验证 - 0.4-0.6：中——看似合理的问题，但取决于有关输入或环境的未声明的假设 - 0.1-0.3：低——推测性的，基于模式而不是经过验证的代码路径将每个结果标题格式化为单行，并内嵌所有元数据： ### [S:N C:X.X] 查找标题 |路径/to/file.go:42-55 |介绍其中： - S:N 是严重性（整数 1-10） - C:X.X 是置信度（十进制 0.0-1.0） - 以竖线分隔的字段包括：标题、位置（从存储库根目录开始的完整相对路径）以及问题是“引入”（通过此更改）还是“预先存在” - 示例：### [S:7 C:0.9] 请求处理程序中缺少空检查 |内部/handler.go:42-48 |介绍这种格式既是人类可读的，又是可通过正则表达式提取的。对每一个发现都一致地使用它。在整个评论的末尾，附加元数据页脚： ---评论元--- discovery_count: <结果总数> categories_clean: <以逗号分隔的没有问题的类别列表> 此页脚可帮助合成器计算准确的统计数据，而无需从散文中进行计数。如果变革涉及战略问题（成本、团队结构、培训），简要记录它们，但不要深入研究，除非它们影响正确性。 **焦点指令**（仅当用户指定焦点区域时插入）：焦点：审稿人要求您特别注意：“<焦点区域>”。优先考虑此领域，但仍注意其他类别中的关键问题。作为后台任务同时运行所有模型。将每个保存到：`/review-.md`。 **捕获计时：** 在启动每个模型的后台任务之前记录“日期+%s”。当“TaskOutput”返回时，记录结束时间。计算每个模型的挂钟秒数。在综合期间存储在 Reviewer Stats 表的变量中。如果模型失败，请记录错误并继续处理其他模型。 ### 第 4 步：综合阅读所有评论文件。将每个发现分类为 7 个以代码为中心的类别之一。请注意哪些模型标记了每个发现以及有多少模型同意。对引用具有相同问题的相同代码位置的重复结果进行删除。使用单一模型，所有发现都是单一来源的。对于 2 个以上模型，注意一致性很重要——多个模型标记的结果具有更高的置信度。写入`-review-consolidated.md`（在`$PROJECT_DIR/.code-reviews/`中）： # 代码审查：<目标描述> 审核小组：<模型 ID 列表> 合成：克劳德目标： ## 总结 <2-3句话：变化范围、总体发现、关键主题> ## 审稿人统计数据 |型号|挂钟|调查结果|平均严重程度 |跳过（噪音）|信号速率| |------|---------|----------|--------------|-----------------|--------------| | <型号-a> | 45 秒 | 12 | 12 5.8 | 3 | 75% | | <模型-b> | 62 秒 | 8 | 6.2 | 1 | 88% | | <模型-c> | 38 秒 | 15 | 15 4.1 | 7 | 53% | > 挂钟 = 从任务开始到完成的时间。 > 跳过（噪音）= 结果得分为 1-2 或与“请勿标记”列表匹配，从审核中排除。 > 信号率 =（结果 - 跳过）/结果。 ## 关键问题（必须修复）错误、逻辑错误、安全漏洞或正确性问题会导致失败。 | ＃|问题 |严重性 |标记者 |地点 |风险| |---|--------|----------|------------|---------|------| ### 详细信息 #### 1. [S:9 C:0.95] <问题标题> | `path/to/file.go:42-55` |介绍 ** 说：** <引用或释义> ** 说：** <引用或释义>（如果有多个标记） **风险：** <损坏的地方> **建议修复：** <特定代码级建议> ## 错误处理和边缘情况缺少错误路径、未处理的条件、边界问题。 | ＃|问题 |标记者 |地点 |什么打破了| |---|-------|-----------|----------|------------| ### 详细信息（相同的格式——位置、型号报价、损坏的地方、修复） ## 安全问题注入、身份验证、秘密、输入验证、数据暴露。 | ＃|问题 |标记者 |地点 |安全影响| |---|-------|-----------|----------|------| ## 测试差距缺少或不充分的更改测试。 | ＃|差距|标记者 |地点 |需要测试什么？ |---|-----|------------|----------|--------------------| ## 性能问题资源问题、算法问题、缺少清理。 | ＃|关注|标记者 |地点 |影响 | |---|---------|------------|----------|--------| ## API 和接口问题重大更改、兼容性、命名。 | ＃|问题 |标记者 |地点 |影响 | |---|-------|-----------|----------|--------| ## 可维护性建议可读性、复杂性、死代码、模式不一致。 | ＃|建议 |标记者 |地点 |效益 | |---|-----------|------------|---------|---------| ## 矛盾（模型不一致）技术分歧需要工程判断。 | ＃|主题 |模特职位|地点 |推荐| |---|-------|----------------|----------|----------------| ### 详细信息（对于每个矛盾，提出每个模型的技术论据） ## 误报（已解决） | ＃|已标记问题 |型号|为什么它很好 | |---|---------------|--------|----------------| ## 行动项目（优先顺序，按严重性） - [ ] `[9]` `path/to/file.go:42` -- <操作> -- [关键/错误处理/安全/测试/性能/API/可维护性] - [ ] `[7]` `path/to/file.go:88` -- <操作> -- [类别] **严重性和置信度的综合规则：** * 使用正则表达式从每个发现的“### [S:N C:X.X]”标头中提取严重性和置信度：“/\[S:(\d+)\s+C:([\d.]+)\]/” * 如果模型偏离标头格式（例如，在散文中写入“[严重性：7，置信度：0.9]”），仍然提取值 - 合成器可以理解这两种格式。 * 使用模型分配的严重性评分。如果多个模型标记相同的发现，请使用最高的严重性。 * 使用模型指定的置信度得分。如果多个模型标记相同的发现，请使用最高置信度。 * 从综合报告中删除严重性为 1-2 的结果 - 将它们计入审阅者统计信息中的“跳过（噪音）”。 * 将置信度低于 0.4 的结果丢弃，除非多个模型独立标记同一问题（协议提高了有效置信度）。 * 按严重性降序对所有表格和操作项进行排序，然后按相同严重性内的置信度降序排序。 * 使用每条评论的“---REVIEW_META---”页脚来填充评论者统计表（findings_count、categories_clean）。如果页脚丢失或格式错误，则从散文中算作后备。 ### 第 5 步：展示并询问在聊天中向用户报告摘要。然后问：第一轮完成。您有三个选择： 1) 停在这里——从行动项目列表开始工作 2) 第 2 轮：反驳——我将对每个发现做出回应（接受/拒绝/部分），将反驳发送回模型，看看他们是否坚持自己的立场 3) 跳到修复——我将把已接受的修复直接应用到代码中将“AskUserQuestion”与这三个选项结合使用。如果用户在此停止，请继续执行 **清理**。 ** ** ## 第二轮：反驳（可选） ### 第 6 步：克劳德调查并撰写反驳 #### 6a：根据准则调查结果阅读综合审查和实际代码（对调查结果中引用的受影响文件使用“读取”工具）。对于每项发现，调查其是否不利于实施。 Claude 拥有模型所缺乏的会话上下文——代码库知识、架构约束、对话历史记录。使用该上下文。对每个发现进行分类： * **接受** \-- 调查结果有效，说明将发生什么变化 * **拒绝** \--发现错误，用具体代码引用解释原因 * **部分接受** \-- 核心问题有效，但建议的修复错误或范围不同 * **Defer** \-- 有效，但超出了此更改的范围 #### 6b：检查是否有什么可以反驳的如果克劳德接受所有调查结果（不拒绝或部分接受），请不要默默地进行橡皮图章反驳。相反，告诉用户：我针对代码调查了所有 N 个发现，并同意所有这些发现。将“我同意所有内容”发送回模型会浪费 3 个昂贵的呼叫，但没有新信息。如果你不同意基于我可能没有的背景的任何发现，请告诉我哪些以及为什么——我会将你的观点纳入反驳中。否则，我们可以跳过第 2 轮并直接从行动项开始工作。使用“AskUserQuestion”： *“跳过第 2 轮——从行动项目开始工作（推荐）” *“我想挑战具体的发现” 如果用户提供了要质疑的发现，请将他们的推理与 Claude 自己的分析一起纳入反驳中，然后继续进行 6c。如果用户跳过，则跳转到 **Cleanup** 或用户选择的下一轮。 #### 6c：写反驳仅当存在真正的分歧（来自 Claude 的调查、用户的输入或两者）时才继续此处。写入`/rebuttal.md`： # 反驳：<目标> ## 已接受（将修复） | ＃|原始发现|地点 |回应 |计划修复| |---|-----------------|----------|----------|----------| ## 拒绝（不同意） | ＃|原始发现|地点 |拒绝理由 | |---|-----------------|----------|---------------------| ### 详细信息 #### <查找标题> **位置：** `path/to/file.go:42` **原始主张：** <所说内容> **为什么错误：** <具体代码参考，逻辑解释> ## 部分接受 | ＃|原始发现|地点 |我们接受什么 |我们拒绝什么 | |---|-----------------|----------|----------------|----------------| ## 推迟（有效，不是这个 PR） | ＃|原始发现|地点 |为何延期 |追踪 | |---|-----------------|----------|--------------|----------| ### 第 7 步：向模特发送反驳将反驳并行发送回所有模型（与第 1 轮相同的模型），并显示以下提示：您之前查看了代码更改并提供了反馈。作者对你的发现进行了反驳。 $(猫“$REBUTTAL_FILE”) 对于反驳中的每一项： - 如果接受：确认，无需采取进一步行动 - 如果被拒绝：你还坚持你的立场吗？如果是，请解释为什么反驳不充分并引用具体代码。如果反驳说服了您，请撤回您的发现。 - 如果部分接受：部分接受是否足够？还缺少什么？ - 如果推迟：推迟是否合理，或者这是本次变更中必须解决的风险吗？项目源代码位于您当前的工作目录 ($PROJECT_DIR) 中。浏览代码以验证反驳中的主张。 $GIT_CONSTRAINT_INSTRUCTION 直接一点。如果你错了，请说出来。如果您仍然不同意，请通过代码引用来加强您的论点。将每个模型的响应保存到“/rebuttal-.md”。 ### 第 8 步：展示并询问总结第二轮的回应。亮点： * 模型退出的调查结果（已解决） * 模型推翻的调查结果（仍有争议） * 提出新的担忧然后问：第 2 轮完成。选项： 1) 到此为止——接受的项目+有争议的项目供您判断 2）第三轮：共识——我将对所有内容进行分类，并提出陷入僵局的项目供您决定如果用户在此停止，请继续执行 **清理**。 ** ** ## 第三轮：共识（可选） ### 步骤 9：建立共识文件 #### 9a：模型灵活性记分卡根据每个模型的反驳响应计算其灵活性得分： * **撤回** \-- 模型承认或撤回调查结果 * **保持** \--模型保持位置 * **升级** \--模型引发了新的担忧计算：`flexibility_rate = 退出/（退出 + 持有）` 如果出现以下情况，则将模型标记为**潜在的抵制**： * `flexibility_rate == 0` 且 3 项以上调查结果受到质疑 * 或升级超过撤回这提供了上下文，而不是自动解雇。 #### 9b：对结果进行分类 * **共识** \--各方同意 * **已解决** \--接受反驳，裁定撤回 * **陷入僵局** \-- 仍然不同意对于陷入僵局的项目： 1. 注意支持计数（有多少模型支持，有多少模型不同意） 2. 进行**事前剖析**（如果我们犯了这个错误，生产会出现什么中断？） 3. 如果标记了抵制，请添加上下文注释编写`-consensus.md`（在`$PROJECT_DIR/.code-reviews/`中）： # 共识：<目标> ## 模型灵活性记分卡 |型号|调查结果受到质疑|退出 |举办 |升级 |灵活率|旗帜| |--------|--------------------|----------|------|------------|------------------|------| ## 共识项（所有人都同意） | ＃|项目 |地点 |分辨率|业主| |---|------|----------|------------|--------| ## 已解决的项目（接受反驳） | ＃|项目 |地点 |最初的关注 |为什么解决了 | |---|------|----------|-----------------|------------------------| ## 僵局项目（需要人类决定） ### DL-X：<问题标题> **问题：** <代码中有什么问题> **位置：** `path/to/file.go:42-55` **模特职位：** - **:** <带有代码参考的技术参数> - **:** <带有代码参考的技术参数> - **:** <带有代码参考的技术参数> **支撑：** X型号支撑位置A，Y型号支撑位置B **持有者：** <哪个型号> <保留标志（如果适用）> **爆炸半径如果错误：** <生产中的具体故障场景> **选项：** A) <方法> -- 复杂性：[低/中/高]，风险：[低/中/高]，权衡：<你放弃什么> B) <方法> -- 复杂性：[低/中/高]，风险：[低/中/高]，权衡：<你放弃的东西> C) <方法> -- 复杂性：[低/中/高]，风险：[低/中/高]，权衡：<你放弃的东西> **建议：** <哪个选项以及原因> ## 最终行动项目 - [ ] `path/to/file.go:42` -- -- [共识/已解决/死锁-已决定] ### 第 10 步：呈现陷入僵局的项目向用户呈现每个陷入僵局的项目并提供选项。使用“询问用户问题”。做出决定后，更新共识文档。然后问：第 3 轮完成。选项： 1) 停在这里——从最终行动项目开始工作 2) 第四轮：决策记录如果用户在此停止，请继续执行 **清理**。 ** ** ## 第 4 轮：决策记录（可选） ### 步骤 11：生成决策记录写入`-decisions.md`（在`$PROJECT_DIR/.code-reviews/`中）： # 决策记录：<目标> ## DR-001：<决策标题> **状态：**已接受 **位置：** `path/to/file.go:42` **上下文：** <为什么需要这个决定> **考虑的选项：** 1. <选项A> -- <优点/缺点> 2. <选项 B> -- <优点/缺点> **决定：** <决定了什么> **后果：** <发生什么变化，接受什么风险> **审阅者：** <型号列表>、Claude、<用户> ### 第 12 步：最终报告总结旅程并列出所有输出文件。继续**清理**。 ** ** ## 辩论模式集中设计辩论，外部模型争论具体的代码设计问题，克劳德综合这些论点。对于诸如“这个抽象是否为时过早？”之类的有针对性的问题，请使用此模式而不是完整的审查模式。或“我们应该使用方法 A 还是 B 进行错误处理？”或者“缓存层有必要吗？” 辩论模式重用与审阅模式相同的基础设施：CLI 调用、模型发现、面板选择、上下文前导码、目录访问、后台任务和清理。 ### 第一轮辩论：开场辩论 #### 步骤 D1：解析参数从调用参数中提取审查目标和 1-4 个辩论问题。 * 参数遵循以下模式：`debate "question1" "question2" ...` * 如果提供了目标但没有问题，请通过“AskUserQuestion”并使用自由文本选项提问：“小组应该辩论哪些代码设计问题？（1-4 个问题）” * 如果既没有提供目标也没有提供问题，则要求两者都提供。 * 限制：每次辩论最多 4 个问题。如果提供更多，请获取前 4 个并通知用户。 #### 步骤 D2：验证和设置与审阅模式相同： 1. 验证 git 存储库并审查目标（审查模式的步骤 2）。 2. 验证 Copilot CLI。 3. 如果尚未完成，请运行模型选择（步骤 0）。 4. 收集变更元数据。 5. 创建临时工作目录和 `.code-reviews/` 目录。 6. 构建上下文前导码（审阅模式中的步骤 2.5）。 7. 告诉用户：“辩论小组：.目标：.问题：”。 #### 步骤 D3：收集参数将每个问题并行发送给所有模型。以与复习模式相同的方式构建目标指令。对于每个模型、每个问题，作为后台任务运行： cd "$PROJECT_DIR" && gh copilot -- -p "您是一位参与代码设计辩论的首席工程师。 $（猫“$ PREAMBLE_FILE”） $TARGET_INSTRUCTION 重要提示：项目源代码位于当前工作目录 ($PROJECT_DIR) 中。使用 git 命令获取差异并浏览代码库，以将您的论点融入到实际的实现中。 $GIT_CONSTRAINT_INSTRUCTION 回答有关代码的具体设计问题： \“<问题>\” 将您的回复构造为： ## 位置清楚地表明你的立场：这是合理的、过度设计的、设计不足的还是错误的方法？ ## 论证（为什么这个设计选择是合理的） - 参考特定文件和行号的具体技术参数 - 它能解决什么问题？没有它什么会崩溃？ ## 反对的论点（为什么这可能是不必要的或错误的） - 什么会更简单？这种复杂性的代价是什么？ - 是否存在一个重要的现实场景，还是理论上的？ ## 判决您的建议：保留、简化、删除或用替代方案替换。直接一点。采取明确立场。不要对冲。” --model "$MODEL" --add-dir "$PROJECT_DIR" --allow-all-tools --no-custom-instructions -s 2>&1 |三通“$OUTPUT_FILE” 将输出保存到：`/debate--q.md`（每个问题每个模型一个文件）。所有模型和所有问题都作为后台任务同时运行。使用带有“block: true”和“timeout: 300000”的“TaskOutput”来收集结果。如果模型在某个问题上失败，请记录错误并继续处理其他问题。 #### 步骤 D4：综合阅读所有辩论论证文件。对于每个问题，对小组的立场进行分类： * **共识** \-- 所有模型都同意相同的判决（保留/删除/简化/替换） * **分裂** \--模型不同意--向双方展示论据强度写入`-debate.md`（在`$PROJECT_DIR/.code-reviews/`中）： # 代码设计辩论：<目标> 辩论小组：<模型 ID 列表> 合成：克劳德目标： --- ## Q1：<问题文本> ### 面板位置 |型号|职位|信心| |--------|----------|------------| | <型号-a> |保留/简化/删除/替换 |强/中/弱| | <模型-b> |保留/简化/删除/替换 |强/中/弱| | <模型-c> |保留/简化/删除/替换 |强/中/弱| ### 论据 <支持设计的模型中最有力的论据，以及属性和代码参考> ### 反对意见 <来自反对设计的模型的最强论据，以及归属和代码参考> ### 克劳德的评估 <克劳德自己权衡双方的技术判断，参考代码> ### 结论：<共识：保留/分割：2 保留，1 删除/等等> --- ## Q2：<问题文本> （对每个问题重复） --- ## 总结 | ＃|问题 |判决 |行动| |---|----------|---------|--------| | 1 | <简短问题> |共识：保留/分裂：2-1 | <建议下一步> | | 2 | <简短问题> | ... | ... | **置信度评分：** 根据模型论证其立场的强度来推断置信度： * **强** \-- 立场明确，有多个具体参数引用特定代码 * **中等** \-- 立场明确，但论点更理论化 * **弱** \-- 对冲头寸，“这取决于”，或薄弱的论据 #### 步骤 D5：展示并询问在聊天中向用户报告摘要。然后问：辩论完毕。选项： 1）到此为止——使用判决 2）第二轮：反驳——我将挑战少数派的立场（如果我不同意，则挑战共识），发送回模型，看看是否有人改变主意将“AskUserQuestion”与这两个选项一起使用。如果用户在此停止，请继续执行 **清理**。 ** ** ### 第二轮辩论：反驳（可选） #### 步骤 D6：克劳德写反驳对于每个问题，确定要挑战的立场： * **如果模型不同意（分裂）：** 撰写反驳意见，挑战较弱/少数的立场。目标是压力测试少数人是否有道理或者多数人是否正确。 * **如果所有模型都同意但 Claude 不同意：** Claude 直接与对方争论。说明克劳德不同意的原因并提出反例。 * **如果所有模型都同意并且克劳德也同意：** 在第二轮中跳过这个问题 - 共识是牢固的。 #### 步骤 D7：向模型发送反驳对于每个受到质疑的问题，使用相同的后台任务模式将反驳发送给所有模型：您之前就代码设计问题提出了以下立场：问题：“<问题>” 您的职位：<模特原职位汇总> 这是挑战你的立场的反驳： <反驳文本> 项目源代码位于您当前的工作目录 ($PROJECT_DIR) 中。浏览代码以验证或反驳反驳中的主张。 $GIT_CONSTRAINT_INSTRUCTION 你坚持自己的立场还是改变主意？ - 如果您改变：解释是什么让您信服并陈述您的新立场。 - 如果你坚持：加强你的论点——直接用代码引用来解决反论点。直接一点。将响应保存到：`/counter--q.md` #### 步骤 D8：呈现最终位置用第二轮结果更新辩论综合。对于每个有挑战性的问题： * 注意谁改变了立场以及谁保持了立场 * 如果平衡发生变化则更新判决 * 呈现最终总结将“## Round 2: Counterarguments”部分附加到“-debate.md”： ## 第二轮：反驳 ### Q: <问题文本> **挑战：** <已发送的反驳摘要> |型号|原位置|最终位置|改变了？ | |--------|------------------|----------------|----------| | <型号-a> |保留|保留|不——强化论证| | <模型-b> |删除|保留|是的——被X说服了| | <模型-c> |保留|保留|没有 | **最终判决：** <更新判决> --- ## 最终总结 | ＃|问题 |第一轮判决 |第 2 轮判决 |行动| |---|----------|-----------------|-----------------|--------| 继续**清理**。 ** ** ## 处理战略/业务问题如果模型增加了成本、培训、容量规划或其他战略问题： 1. **在综合审查中简要确认**：“注意：模型标记了潜在的成本/培训问题。有关详细信息，请参阅单独的审查。” 2. **不要升级为僵局**，除非问题使解决方案在技术上不可行： * 提升：“每个节点需要 500TB RAM”（当最大值为 100TB 时）——阻止实现 * 不要提升：“这可能会增加每月 1 万美元的成本”——业务决策，而不是技术障碍 3. **请勿将**包含在事前分析或最终行动项目中。审查委员会重点关注工程质量。战略问题属于单独分析。 ** ** ## 清理 1.询问：“删除`/`中的中间审阅文件？” 2. 如果是（默认）：`rm -rf ""` 3. 如果不是：告诉用户路径。将“AskUserQuestion”与“删除临时文件（推荐）”和“保留临时文件”结合使用。 ** ** ## 使用的工具工具|目的 ---|--- `询问用户问题` |目标选择、模型选择、回合/辩论选项、僵局、清理 `阅读` |阅读源文件进行反驳验证 `重击` |检查 CLI、元数据的 git 命令、创建/删除目录 `Bash`（背景）|使用不同的模型并行运行“gh copilot”（回顾和辩论） `任务输出` |等待后台任务完成 `写` |保存所有输出文件（综合评论、辩论综合等） ## 错误处理 * 如果不在git仓库中，报错并停止 * 如果未安装 Copilot CLI，则报告错误并停止 * 如果审核目标不存在（PR号错误、分支不存在、SHA无效），报告错误并停止 * 如果工作树在“未提交”模式下是干净的，则报告“无需审查”并停止 * 如果一个模型失败，则继续其他模型（输出中注释） * 如果所有模型都失败，则报告错误并停止该轮 * 如果用户的 Copilot 订阅中没有可用型号，请跳过并发出警告 * 使用 `2>&1 | 捕获输出tee`（不是`> file 2>/dev/null`）

代码审查副驾驶

包含技能