Cherry Studio 多智能体代码评审实战gh-pr-review 技能中的 reviewer–verifier 对抗式审查机制【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio本篇聚焦 Cherry Studio 仓库内置的gh-pr-review代码评审技能中面向大型变更的多智能体引擎teams-review.md解析协调器coordinator如何调度 reviewer、verifier 与 fixer 三类子代理完成范围界定 → 产品门禁 → 对抗式审查 → 中立过滤 → 受控修复 → 报告的完整流水线。读完后你将掌握该评审体系的会话隔离契约、各阶段提示词要素、风险分级路由与修复安全约束并可将其作为在 Electron 多进程架构大型仓库中落地 LLM 代码评审的工程参照。1. 定位gh-pr-review 技能的两级引擎与团队引擎的前置条件gh-pr-review是 Cherry Studio 仓库中一个 Agent 技能skill用于对本地分支、PR、commit、文件和架构文档做自动化代码评审。其入口 SKILL.md 定义了按 diff 大小 运行时子代理能力选择引擎的路由规则小范围变更SMALL_SCOPE true走单代理引擎 local-review.md大范围变更且运行时具备独立子代理能力时走本文主角的多代理引擎 teams-review.md大范围变更但运行时无法启动子代理时退回单代理引擎并置LIMITED_SINGLE_AGENT true报告中必须显式声明大 diff 仅接受单代理审查、没有独立对抗验证。teams-review.md开篇即定义了协调者的硬性边界与前置条件协调器从不直接修改源码文件。它只调度 reviewer、verifier 和 fixer 代理读代码仅限仲裁arbitration、诊断和修复验证三个场景。独立子代理能力是硬性前置条件。进入流程前运行时必须能启动至少一个 reviewer之后在独立会话、零共享对话历史中再启动一个全新的 verifier。并行执行是可选的——顺序执行同样满足隔离契约。若运行时没有子代理能力停止遵循本文件路由回local-review.md并置LIMITED_SINGLE_AGENT true。协调器自我验证无法替代 reviewer–verifier 机制这是该文档最核心的设计立场审查质量不来自更用心的单智能体而来自结构性的对抗分工。引擎的输入契约来自SKILL.md的路由器有三项输入含义REVIEW_TARGET、已解析的评审范围、SMALL_SCOPE均由SKILL.md§ Scope derivation 派生阈值CHANGED_LINES 1000且CHANGED_FILES 20且无二进制文件才为小范围AUTHORIZED_FIX仅当调用显式授权修复fix修饰符或等价用户措辞时为truecommit/range 目标永远是只读报告模式。为false时整个 Phase 4 被跳过——所有确认问题只报告、不修复HAS_SUBAGENTS必须为true为false或缺失时不得继续按上文路由规则回退配套的参考文件全部位于 references 目录文件用途consumer-review.md消费者审查阶段变更新增/扩展共享面时code-checklist.md代码评审清单A 正确性/安全 → B → C 风格按优先级doc-checklist.md文档评审清单cherry-review-guidance.mdCherry Studio 项目专属审查边界judgment-matrix.md风险分级、值得修复判据与特殊规则checklist-evolution.md清单更新流程与规则2. 核心质量机制reviewer–verifier 对抗对文档将reviewer–verifier 对抗对称为核心质量机制core quality mechanism并用一段独立小节规定了两者的信息隔离规则两者运行在独立会话不共享任何对话历史verifier只接收归一化后的 findings问题主张 当前file:line引用与代码片段 审查推理 测试该问题所需的最小模块范围/证据禁止传递 reviewer 的对话历史、临时工件文件、附带/原始工具输出——除非某个特定工件或摘录被显式要求作为证据。这条最小信息披露契约的意义在于如果 verifier 能看到 reviewer 的推理过程它会倾向于顺着结论找补对抗性失效。只给结论 证据锚点才能迫使 verifier 从代码本身出发独立证伪。3. 流程总览与 Product gateAuthorized fix: Scope → Product gate → Review → Filter → Fix/Validate → Report Report-only (default): Scope → Product gate → Review → Filter → ReportProduct gate产品门禁是SKILL.md§ Review Stages 中的 stage 1由协调器在派发任何 reviewer 之前执行。它要求先检视变更实际表达或约束的语义判断是否影响产品语义、用户可见行为或产品方向——变更标签feat/fix/docs不构成充分证据。门禁分为三种状态且不得互相坍缩无产品影响完全跳过不作声方向已确立与已记录决策一致则继续冲突则报告产品方向失配并立即终止整个评审产品决策开放交互式会话中可向用户提问自动化会话中采用仅记录record-only行为并把产品影响摘要带入最终 Report——永远不能表述为已获产品批准。阶段 2–5Consumer、Architecture-First、Implementation、Style由 reviewer 覆盖。Filter 阶段按 judgment-matrix.md § Handling by Risk Level 路由问题若无任何问题可进入修复直接跳到 Report。4. Phase 1Scope —— 关联 PR 会话、CI 基线与模块划分4.1 关联 PR 的完整会话状态范围解析本身由SKILL.md§ Scope derivation 独占本流程不重述。若ghCLI 可用需检查当前分支是否有 open PRgh pr view --json number,state --jq select(.state OPEN) | .number 2/dev/null若存在 open PR需用 pr-review.md Step 2 收集完整的可访问会话状态PR_REVIEWS、PR_CONVERSATION_COMMENTS、整个REVIEW_THREADS以及当前 reviewer 的 pending draft——并保留各自的状态与可见性边界。若本引擎是从pr-review.md包装器进入的直接复用其已收集的数据。4.2 CI 基线绝不用本地命令替代有关联 PR 时以gh pr checks作为验证基线记录 failing、pending、successful 三类检查作为审查证据无关联 PR 时必须声明 CI 验证不可用继续纯静态审查绝不在评审期间运行本地 lint、test 或 format 命令pnpm lint/pnpm test/pnpm format一律禁止。这一CI 基线优先原则贯穿整个引擎只有当 Phase 4 实际应用了修复、会话变成编码任务时才按SKILL.md§ Validation after applied fixes 选择验证命令并在报告中说明已有 CI 验证的是远端已提交代码而非这些未推送的修复这一限制。4.3 模块划分面向并行审查的切分范围内的文件被切分为审查模块review modules以支持并行评审每个模块是自治的逻辑单元大文件按 section/函数组切分相关小文件归组每个模块被分类为code、doc或mixed。文档给出了 Cherry Studio 项目的建议模块边界这些边界与仓库真实目录结构一一对应src/main/data/— DataApi 处理器、数据服务、迁移、schemasrc/main/core/— lifecycle、application、windows、paths、loggersrc/main/services/— 主进程业务服务与副作用src/renderer/data/— DataApi hooks、Cache、Preference、渲染进程 storesrc/renderer/— React UI 组件、hooks、pages、features、windowspackages/aiCore/— AI SDK 中间件与 providerssrc/shared/— 跨进程原语、DataApi/IpcApi schema、类型、纯工具packages/ui/— 共享 UI 原语src/shared/ipc/、src/main/ipc/、src/preload/、src/renderer/ipc/— IpcApi 契约与桥docs/references/data/— 数据架构文档.agents/skills/— Agent 技能与评审指令这套划分本质上是沿 Electron 多进程边界main / renderer / shared / preload和项目分层core 基础设施 / services 业务 / data 数据层切分保证每个 reviewer 的上下文窗口聚焦于一个依赖方向清晰的单元。4.4 问题追踪模型协调器在整个会话中于内存追踪所有 issue每个 issue 的字段为简要描述brief description状态reported|fixed|failed风险low | medium | high位置file path:line修复选项、权衡与可选建议仅 medium/high 风险需要low 风险只有一种显然的修法无需额外指导5. Phase 2Review —— 代理装配、Reviewer 提示词与 Verifier 对抗验证5.1 代理装配原则每个模块一个独立 reviewer所有 reviewer 完成后再启动一个全新的独立 verifier独立会话。不指定运行时未暴露的工具名、代理类型或参数通过运行时的 spawn/delegate 接口下发任务并收集返回报告。上下文归一化职责在协调器不在 verifier——协调器负责把 reviewer 输出归一化为交接用的最小信息。运行时支持并行子代理时并发启动 reviewer不支持则顺序启动同样的代理——阶段、提示词与 reviewer/verifier 上下文隔离完全不变。5.2 Reviewer 提示词要素立场thoroughReviewer 的立场是彻底——尽可能多地发现真实问题提交前自我验证。每个 reviewer 收到的要素Scope文件列表 其模块的变更行范围。reviewer 自行获取 diff、按需读上下文——协调器不传递原始 diff 或文件内容Checklist代码模块取 code-checklist.md文档模块取 doc-checklist.mdmixed 两者都取清单内容逐字verbatim包含进 reviewer 提示词。代码、mixed、架构文档与项目技能模块逐字包含 cherry-review-guidance.md仅当纯文档模块描述项目行为、路径、工具或评审规则时才包含。React/性能密集模块还需加入vercel-react-best-practices技能的相关规则作补充检查该技能在 code-checklist.md 中被引用为 62 条细粒度规则的深参考Stages按顺序执行SKILL.md§ Review Stages 2–5。对 diff 新增或扩展共享面的模块——按 diff 语义判断绝不按变更标签——逐字包含 consumer-review.md 并最先执行报告每个面的决策只对存留的面继续做实现质量审查Mandatory docs评审前读取 cherry-review-guidance.md § Mandatory Baseline Docs 要求的相关进程文档以及所触子系统的按需文档。先做架构级审查——对照文档判定 placement、ownership、abstraction integrity再进入行级细节。任何不合规至少是 Warning 级 findingEvidence requirement每个问题必须有来自当前代码树的代码引用file:line 片段Checklist exclusion见对应清单的排除节上下文中加载的项目规则优先Self-check提交前重读相关代码逐条验证标记 confirmed 或 withdrawn只提交 confirmed 问题。若引用的路径/行已不存在先用git diff --name-only或文件搜索定位正确位置再报告Output format[file:line] [A/B/C] — [description] — [key lines]。其中 cherry-review-guidance.md 是 Cherry Studio 专属审查透镜其核心是引擎 声明面generic engine declaration surface的实体泄漏检测该代码库在每一层重复同一结构模式——WindowManagerwindowRegistry、lifecycle 容器 serviceRegistry phase/依赖装饰器、JobManager/SchedulerServicejobRegistry、DataApi/IpcApi 路由器 单点 schema-and-handler 注册等审查测试即识别所触模块的引擎/声明对然后检查变更落在哪一侧——落在引擎侧的按实例键控行为就是实体泄漏。渲染进程侧则对应 renderer 架构文档 的类型 × 域网格共享行必须域盲lint 只能禁止 import 边评审必须抓住不带 import 到达的域知识路由字符串、缓存键前缀、域 id 分支、feature-flag props。PR 会话 reviewer当存在历史评审线程时额外启动一个代理对每个整线程thread的当前结论对照当前代码做验证——线程的根评论、所有回复、resolved/outdated 状态要放在一起判断评审摘要和普通会话评论是独立的上下文。输出格式与验证流水线与常规 reviewer 相同。5.3 Verifier 对抗验证立场adversarialVerifier 的立场是对抗——默认怀疑 reviewer主动寻找每个问题可能错误的理由用真实证据拒绝REJECT站得住脚则确认CONFIRM。文档强调这是强制步骤协调器不得跳过、不得自己执行验证。唯一例外所有 reviewer 都明确报告零问题LGTM / no issues found时跳过验证直接进入 Phase 3。所有 reviewer 完成后协调器把每个 finding 归一化为问题主张、当前file:line引用与片段、reviewer 推理、测试所需的最小模块范围/证据然后在全新会话中启动单个 verifier。验证器提示词必须逐字包含以下内容原文You are a code review verifier. Your stance is adversarial — default to doubting the reviewers conclusion and actively look for reasons why the issue might be wrong. Your job is to stress-test each issue so that only real problems survive. For each issue you receive: 1. Read the cited code (file:line) and sufficient surrounding context. 2. Actively try to disprove the issue: Is the reviewers reasoning flawed? Is there context that makes this a non-issue (e.g., invariants guaranteed by callers, platform constraints, intentional design)? Does the code actually behave as the reviewer claims? Look for the strongest counter-argument you can find. 3. Output for each issue: - Verdict: REJECT or CONFIRM - Reasoning: for REJECT, state the concrete counter-argument. For CONFIRM, briefly note what you checked and why no valid counter-argument exists. Important constraints: - Your counter-arguments must be grounded in real evidence from the code. Do not fabricate hypothetical defenses or invent caller guarantees that are not visible in the codebase. - A CONFIRM verdict is not a failure — it means the reviewer found a real issue and your challenge validated it.注意第三条约束的措辞CONFIRM 不是失败——这从提示词层面消解了 verifier 的挑刺偏见保证对抗是双向的既防 reviewer 的误报也防 verifier 为显对抗而强行驳斥真问题。5.4 进入 Phase 3 前的门禁在进入 Filter 前必须确认(1) 所有 reviewer 已提交最终报告(2) verifier 已对每个 finding 给出 CONFIRM/REJECT 裁决或者所有 reviewer 报告零问题、验证被合法跳过。6. Phase 3Filter —— 协调者独有的中立仲裁此阶段立场是中立——不信任任何单方。reviewer 报告与 verifier 反驳被视为等权输入协调器用其项目全局视野考量局部 reviewer 可能遗漏的跨模块影响、约定与架构意图。6.1 去重移除跨 reviewer 重复项同一位置、同一主题。6.2 存在性检查Verifier 裁决动作CONFIRM合理性检查——验证描述与引用代码是否相符任何疑点都读代码REJECT读代码评估双方论点只有当反驳论证站得住脚时才丢弃值得注意即便 CONFIRM 也要做合理性检查即便 REJECT 也不自动丢弃——协调器对双方都保持独立复核这正是中立立场的操作化。6.3 风险分级与修复指导风险分级、值得修复判据与按风险级别的处理由 judgment-matrix.md 独占定义此处不重述。该矩阵的核心结构是风险是按问题而非按类型评估的同一个 rename 可以是 low 也可以是 highreport-only 模式下所有风险级别都只报告authorized fix 模式下只有 low 风险进入自动修复medium/high 一律报告选项与权衡。矩阵还包含两条项目特殊规则会改动测试基线截图对比、golden files的修复永远不自动应用main分支上 Redux 已移除、Dexie/ElectronStore 是一次性 v1 技术栈——不得修复或扩展它们新引入的 v1 用法要报告并路由到 Cache/Preference/DataApi/v2 迁移器。修复指导仅 medium/high 记录记录可行的同高度at-altitude选项、关键权衡与可选的 reviewer 建议及理由绝不把任何选项记录为已选定。low 风险只有一种显然修法无需额外指导。所有选项必须处于缺陷的高度per cherry-review-guidance.md § Fix Recommendation Policy局部 bug 做最小修正、结构性症状做根因修复、边界/实体泄漏问题做符合架构的重定位。低于缺陷高度的补丁side table、元数据 flag、额外特判、对结构性病因的症状式修复不得进入自动修复队列——应报告问题并给出同高度选项。6.4 路由所有确认问题都带风险级别被记录按 judgment-matrix.md § Handling by Risk Level 路由进入自动修复队列的去 Phase 4其余标记reported并附修复指导跨模块影响若修复需要动 fixer 模块之外的文件加入当前修复队列并指派给合适的 fixer自动修复队列非空则进 Phase 4否则直接跳 Phase 5Report绝不向用户询问要修哪些问题。7. Phase 4Fix/Validate —— 受控修复、协调器验证与校验仅当AUTHORIZED_FIX true且自动修复队列非空时运行。7.1 Fix精确立场与代理指派立场是精确——把每个修复完整正确地落地绝不扩大范围协调器不得亲自应用修复。代理指派策略用运行时提供的协调工具启动 fixer仅当运行时能保留该代理上下文时才优先复用已有 reviewer否则用最小已验证问题上下文启动新 fixer问题位于某 reviewer 已分析过的文件中 → 把该上下文带入 fixer 提示词跨模块问题 → 单个 fixer 代理携带全部相关文件路径多文件重命名 → 作为单个原子任务指派给一个代理一个代理可承接多个修复任务若它覆盖多个文件避免同一文件被多个代理同时编辑防止并发写冲突。每个 fixer 的提示词必须逐字包含以下修复规则原文Fix rules: 1. Do not stage or commit. The coordinator validates all edits before any commit. 2. Only modify files explicitly assigned by the coordinator. 3. If a fix requires changes to unassigned files, stop and report to the coordinator for re-assignment. 4. Keep each issues edits separable and report the exact changed files. 5. When in doubt, skip the fix rather than risk a wrong change. 6. Do not run build or tests. 7. Do not modify public API function signatures or class definitions (comments are OK), unless the coordinators issue description explicitly requires an API signature fix. 8. After each fix, check whether the change affects related comments or documentation within your assigned files (function/class doc-comments, inline comments describing the changed logic). If so, update them as part of the same fix. Cross-module documentation updates (README, spec files, other modules) are handled separately by the coordinator. 9. When done, report the changed files for each fix and list any skipped issues with the reason for skipping.关键的安全不变量fixer 的所有编辑保持未提交状态。即使修复已获授权评审工作流也永不 stage 或 commit经验证的补丁要交给独立的、用户另行授权的发布/提交工作流由该工作流负责带具体 kebab-case scope 和--signoff的 Conventional Commit。绝不 stage 用户已有的未提交变更。7.2 协调器验证修复等待所有 fixer 完成后、运行验证之前协调器读取每个被指派文件的工作树 diff并验证三点修复确实正确解决了原问题未引入新问题命名不一致、周边代码遗漏更新、逻辑错误修复范围与问题匹配——无意外变更。发现问题时携带具体细节启动一个纠正代理correction agent最多 1 次重试重试失败则标记failed移除不成功的 fixer 编辑时永不丢弃用户已有的变更。7.3 Validate把未推送修复当作编码任务处理重新读取每个 fixer diff重跑相关的 reviewer/verifier 检查。随后因为应用修复已使会话变成编码任务按SKILL.md§ Validation after applied fixes 选择的验证命令运行并写入报告。该节与仓库 package.json 的脚本定义直接对应文档/markdown-only 修复含技能自身文件→pnpm docs:check等价于docs:check-links docs:check-structure docs:check-frontmatter docs:check-index代码修复 →pnpm lint它本身以pnpm format结尾故不再单独调用format 覆盖变更的测试pnpm test:main file即vitest run --project main或pnpm exec vitest run file明确禁止pnpm test path——该脚本串联多次 vitest 调用路径只会传到最后一次完整pnpm test仅保留给无法点名受影响测试的宽范围变更pnpm test:lintoxlint --deny-warnings eslint ...用于需要 CI 等价 lint 门禁时pnpm lint容忍 oxlint warning 而 CI 不。CI 语义在验证后也须如实声明已有 CI 验证的是被评审的远端 commit不是这些未推送的修复若后续用户授权的发布工作流推送了修复应在宣称完全验证之前检查结果对应的 CI。验证通过→ 问题标记fixed若修复尚未发布注明 CI pending验证失败→ 携带失败细节经纠正代理重试最多 2 次仍未解决则标记failed并把移除其精确补丁视为安全阻断项safety blocker交互式会话中先询问再移除自动化会话中原地保留补丁并报告所需决策。绝不 reset、checkout 或以其他方式丢弃无关或用户已有的变更。进入 Phase 5 后failed 修复只报告、不再与用户重试移除不成功的 fixer 编辑时永不丢弃用户已有的变更。8. Phase 5Report 与 Checklist 演进报告必须覆盖以下要素缺项即披露不完整产品决策仍开放且会话为自动化时附Product Demand 摘要影响、方向、需人工确认的点显式标注等待产品决策——绝不表述为已批准diff 新增/扩展了共享面时逐面给出consumer review 决策问题统计found / fixed仅授权修复时/ reported / failed报告的问题列表带风险级别、file:line与同高度修复指导medium/high 含选项、权衡与可选建议应用过修复时附本地验证结果按SKILL.md§ Validation after applied fixes 选定的命令回滚的问题及原因关联 PR 的 CI 状态无 PR 时写 unavailable未推送修复CI pending直到发布来自先前 PR 评审线程的问题若曾存在固定提示语To verify fix quality, run/gh-pr-reviewagain.用再次运行评审来验证修复质量——形成可复现的回归闭环Checklist 演进复盘本次会话所有确认问题若有代表当前清单未覆盖的重复性模式读取 checklist-evolution.md 并把有效候选项以proposed状态记录在报告中。该演进文件定义了严格的三级状态模型proposed → accepted → persisted常规评审永不接受、插入或声称持久化清单规则——候选项只存在于报告而报告不是持久载体只有用户在显式维护流程/gh-pr-review checklist中选定、写入被指定的长期 checkout 并落入 commit/PR 等持久记录后该规则才可被描述为对后续评审可用。清单本身追求最小且高信号每条项目引导 AI 关注一类不同问题类别保持在 3–8 项宁少而广、不做穷举缺陷目录。9. 交互契约与安全不变量汇总teams-review.md遵循 SKILL.md § Interaction and interruption contract常规评审是零提示prompt-free的——不询问模式选择、不确认修复、不做 finding 选择、不做提交预览本流程除了其声明的failed-fix 清理安全阻断外不引入任何新的提示类别。结合全文该引擎可归纳出七条安全不变量协调器不写码——读代码仅限仲裁、诊断、修复验证会话隔离——reviewer 与 verifier 零共享历史verifier 只收归一化 findingsCI 基线优先——评审期禁本地 lint/test/formatgh pr checks是唯一验证基线风险分级路由——只有 low 风险可自动修复medium/high 永远只报告选项与权衡且测试基线类修复永不自动应用修复永远未提交——评审工作流不 stage/commit发布交给独立的显式授权工作流用户已有变更绝不被 stage 或丢弃失败修复是安全阻断项——交互式先问、自动化原地保留并报告绝不 reset/checkout 掉无关变更修复不降高度——低于缺陷高度的症状式补丁不进自动修复队列。这套机制的设计意图清晰LLM 评审的主要失效模式是误报false positive与自我确认偏差teams-review.md用独立会话 最小信息披露 强制对抗验证 中立仲裁四层结构将其工程化压制同时用权限模型report-only 为默认修复/提交均须调用时显式授权和 CI 基线约定把 LLM 的行为约束在可审计、不越权、可复现的范围内——对于 Cherry Studio 这类 main/renderer/shared 多进程边界严格、数据层与 IPC 契约敏感的 Electron 桌面应用仓库这正是大 diff 自动化评审可信运行的前提。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考