LobeHub Deep Review Claude Code 编排手册多代理深度代码审查的八步全流程解析【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub本文以 LobeHub 仓库中 deep-review 技能的 Claude Code 环境手册references/claude-code/main.md为主体完整解读 deep mode 从范围确定、维度选择、并行派生审查代理到验证、去重、渲染报告与交互式修复的端到端编排流程。读完本文你能掌握这套多代理代码审查系统如何在 Claude Code 的 Task 机制上实现并行审查 对抗式验证 全局去重并能对照源码理解每一步的校验契约与不变量约束。手册定位环境专属的执行剧本deep-review 是 LobeHub 仓库内定义在 SKILL.md 中的一个多维度代码审查技能。它把审查宽度交给并行的维度覆盖把精度交给对抗式验证adversarial verification和全局重复归并。SKILL.md 把完整流程划分为两种入口模式Light默认单个独立审查者对照各维度的 Quick checklist和 Deep仅当用户显式触发/deep-review时运行完整编排。Deep 模式按运行环境选择手册SKILL.md 中明确列出环境手册Claude Codereferences/claude-code/main.mdCodexreferences/codex/main.md本文聚焦前者。手册开篇给出两条贯穿全程的总纲后续所有步骤都由它们派生每个 Task 提示词必须自包含——子代理不继承主代理的会话上下文严禁依赖上文提到过的信息。审查与验证统一使用 balanced/fast 模型档位质量由规则rules而非更强的模型来保证对应 SKILL.md 的核心原则Rules over model。此外 SKILL.md 还规定了一个Deep 模式预算同一逻辑需求同一需求、PR 或分支默认最多运行一次 Deep修复后的复核、rebase、清理、上下文压缩或会话恢复一律走 Light 模式不重置预算。Step 0 — 确定审查范围与背景手册要求第一步执行 scoping.md产出三个东西{changes}、不超过 200 词的范围摘要scope summary以及 PR 模式下的 PR 元数据。这一步看似是取 diff实际上 scoping.md 里定义了一套相当严格的 git 规则直接决定审查对象是否干净三点 diff 铁律git diff一律使用三点形式base...HEAD绝不使用两点。两点形式对比一个已移动的 base 会把他人新合并的提交反向注入 diff。同时 base ref 不能落后于分支真实 fork 点——rebase 后本地默认分支可能已指向旧提交local-default...HEAD的 merge-base 会落在陈旧提交上。base 的选择顺序为PR 模式优先用gh pr diff num其次先git fetch再用origin/default...HEAD本地默认分支仅在确认未落后git rev-list --count local-default..origin/default为 0时才可用。log 与 diff 的不对称校验用git log --oneline base..HEAD必须是两点列表里出现他人提交说明 base 选错了——应修 base而不是绕开问题继续审查。先统计后取全量先用--stat类命令探大小且必须先剔除 lockfilepnpm-lock.yaml等、快照*.snap、生成文件与构建产物dist/、build/、.next/再判断规模超过 1500 行按目录拆批小 diff 定义为 ≤ 200 行且 ≤ 5 个文件此时完整 diff 文本直接成为{changes}其余情况不预取把带排除规则的命令本身作为{changes}由子代理自行执行。PR 模式的触发条件用户给出 GitHub PR URL 或无歧义的PR #123/pr 123/pull request 123才进入 PR 模式裸#123是有歧义的不触发。PR 模式下还需追加gh pr view num --json title,body,files,baseRefName,headRefName的元数据。子模块一并审查默认把主仓库与 submodule 的变化合在同一审查里定位前缀子模块路径例如lobehub/src/x.ts:42。范围摘要之所以重要是因为它会塞进每一个子代理提示词是判断这次改动是否违背需求的首要标尺。Step 1 — 选择审查维度这一步做两件事应用 SKILL.md 的剪枝表pruning table并记录每个被跳过维度的单行理由。SKILL.md 为 14 个内置维度各定义了跳过条件例如performance在未触碰服务端/数据库/循环/渲染路径代码时跳过ux在无用户可见界面变化时跳过security仅对仅 lockfile/生成文件的 diff 跳过文档与文案仍要跑因为文本本身可能是泄露向量ai-coding-bad-habits、code-style、logic、business-logic、reuse-architecture几乎从不跳过仅纯文档/纯 lockfile diff 例外。有疑虑时宁可多跑一个维度。检测同级的deep-review-*扩展包。任何位于活动 skills 根目录下、名称匹配deep-review-*的兄弟技能目录如.agents/skills/deep-review-cloud/都是扩展包其dimensions/*.md若与内置维度同名则扩展该维度两个文件都加载若为新名称则新增一个维度。对每个幸存维度收集内置 扩展的规则文件路径。值得注意的一个边界定义SKILL.md 明确docs-only 仅指面向人的散文——给代理执行的可文件.agents/skills/**、AGENTS.md/CLAUDE.md、提示词模板、编排手册在剪枝目的上算代码因为它们的散文承载控制流、契约与规则。Step 2 — 并行派生审查者手册要求在同一个响应里并发启动所有已选维度每个维度一个 Task。每个 Task 的提示词由实例化 review-prompt.md 得到需要填入四个占位符{dimensions}本 Task 负责的维度 idClaude Code 下一个 Task 对应一个维度{dimension_files}维度规则文件路径包含扩展包对应文件{scope_summary}Step 0 的 ≤ 200 词范围摘要{changes}小 diff 的完整 diff 文本包裹在diff围栏内或大 diff 的获取命令。Task 的元数据约定为description: review: dimension、subagent_type: general-purpose。review-prompt.md 对提示词内容本身有强约束这里挑出对理解整体设计最关键的部分校准硬规则Calibrationdiff 按代码库现有标准衡量而非理想化标准——该模式在存量代码中广泛存在且本 diff 没有使其恶化则不报告声明为临时的代码限时活动、实验、一次性脚本按其生命周期评判不要求可配置性。calibration_exempt: true的维度如 security豁免校准。产出 JSON 契约每条 finding 必须含id、dimension、issue_type、natureintroduced/exposed_legacy、severityp0/p1/p2、likelihoodhigh/medium/low、location、summary、core_problem、fix_cost、至少一条fix_options和need_testexposed_legacy必须附exposuretriggered/bystander与scenario。severity 只表达触发后多严重likelihood 独立表达触发频率两者正交。职责边界审查者是 finder 而非终审法官——拿到file:line证据即停深度证伪留给验证阶段verify: false的维度workflow、skill-freshness直接进报告。Step 3 — 验证、聚合与校验这是整个流程的核心。手册要求主代理在整个运行期间维护六个累积器reportPool、releaseChecks、missingSources、workflowFeedback、needsContext以及验证统计。每个审查者返回时用bun run .agents/skills/deep-review/scripts/validate-output.ts review校验其围栏 JSON通过 stdin 或任务级临时文件传入。校验失败 → 拒绝该结果用同一提示词重新派生该审查者。在切分 findings 之前先把missing_sources、release_checks、workflow_feedback追加到对应累积器。verify: false维度的 findings 直接进入reportPool。可验证的 findings 实例化 verify-prompt.md——只包含该 payload 实际需要的维度专属验证附录release-risk 与 reuse-architecture 各有附录文件。验证在该审查者一返回就立即派生不等待其他审查者完成即验证流水线化、没有全局屏障。每个验证者返回时用validate-output.ts verify校验。输入与输出 id 逐一比对缺失、重复或凭空捏造的 id → 对这些未解决的原始 id 重新派生一个全新验证者。先应用severity_override以及 nature/exposure 覆盖再交叉检查三条不变量有效 P0 必须阻断发布有效 P2 不得阻断有效release-risk或exposed_legacyfinding 不得是自动修复项。仅当有效值仍违反不变量时才重派验证者。追加验证者的workflow_feedback。三路裁决分流confirmed→ 应用覆盖后进入reportPoolfalse_positive→ 只进统计need_more_context→needsContext。两个硬约束收尾验证者 payload仅在超过 20 条 findings 时才允许拆分主代理永不亲自复核任何候选 finding对应 SKILL.md 的Anti self-approval原则——刚写完代码的代理给自己打分必然放水且主代理也不得静默降级为自己审自己。验证提示词verify-prompt.md定义了can_auto_fix的完整判定fix_cost为 low、存在唯一显然修复、无需外部资源或产品决策、且改动少于 3 个文件、不触碰架构层/数据库 schema/外部契约/用户可见行为/路由/热键/文案/权限边界四项全真才可自动修复release-risk与exposed_legacy永不自动修复。blocks_release的判定则锚定有效 severity 覆盖之后P0 必须阻断、P2 不得阻断、低 likelihood 非阻断除非影响是灾难性且不可逆。Step 4 — 归并重复根因当 confirmed findings至少剩两条时派生一个全新 Task 执行 consolidate-prompt.md传入经验证者覆盖处理后的 confirmed findings顺序为报告顺序。该阶段不做正确性复核只识别跨验证 payload 重复的根因——共享根因的定义是一条具体修复能同时解决两条 finding位置、主题或维度相近不算。产物同样要过validate-output.ts consolidate且主代理还要人工拒绝四类非法输出捏造的 id、自映射map 到自身、环、以及根因出现在其重复项之后。非法 → 重新派生归并只有验证通过后才应用映射。confirmed 为 0 或 1 条时跳过此步。consolidate 的返回结构极简{same_root: [{id: style-2, same_root_as: ai-1}]}无重复时返回{same_root: []}。Step 5 — 渲染报告报告严格按 report-template.md 渲染。该模板是 deep mode 的输出契约覆盖任何环境默认格式要点包括结构强制标题、头部元数据Scope/Background/Execution含被剪枝维度及单行理由、TL;DR、Findings、Statistics 恒定渲染即使零 confirmed finding只渲染verdict: confirmed的 findings按 p0 → p1 → p2 排序同级内按 SKILL.md 维度表分组exposed_legacy走Hand off to owner附 Linear issue 草稿与culprit归因不在本 PR 内修复唯一例外是exposure: triggered的 P0按正常 finding 渲染且阻断合并release_checks渲染为 Pre-deploy checklist不计入 finding 统计、永不作为合并前置条件P2 超过 6 条时只完整渲染前 6 条其余折叠为单行 More P2低 likelihood 排最后PR 模式下主代理不委派填 Merge verdict决策表首匹配生效draft / 冲突 / 检查 FAILURE → do not merge yet范围内in-scopeP0、P1 confirmed 0 → fix before merge否则 → good to merge。in-scope 定义为introduced或exposed_legacy且triggered且 P0。发送前执行模板内置的 self-check 清单缺项必须修复重渲染。Step 6–8 — 交互式修复流转Step 6 提供安全批修复当 Safe to fix now 非空时用AskUserQuestion询问——问题固定为Safe to fix now has N low-risk findings — apply them all in one pass?选项Fix all/Not now自由文本支持部分勾选。对选中项应用修复need_test: true的补回归测试批次为空则静默跳过。Step 7 逐条处理剩余决策针对 confirmed 且can_auto_fix: false的 findings 与needsContext每次调用最多问 4 个问题排序为 P0 → P1 → P2、阻断者优先排除所有 legacy 移交项重复审查时跳过低 likelihood 非阻断项除非用户主动要求。Step 8 提供 legacy 移交 issue当 Hand off to owner 非空时一次性询问是否创建全部/部分/无 Linear issue批准前不创建任何东西批准后使用linear技能创建内容须包含位置、culprit、场景、likelihood 与验证证据。Notes三条边界规则手册末尾的 Notes 定义了三个容易踩坑的边界小 diff 判定≤ 200 行且 ≤ 5 个文件才内联完整 diff否则传获取命令与 scoping.md 的阈值一致PR 模式触发GitHub URL 或无歧义的PR #123/pr 123/pull request 123裸#123不算无法派生 Task 时停止并主动提供 light 模式绝不允许主代理模拟 deep mode。第三条与 SKILL.md 的禁令呼应不得自行发明其他环境的机制、不得把 deep 模拟成一个打包的审查者未知环境应告知用户暂不支持 deep 并回退 light。校验层validate-output.ts 的契约实现编排手册中反复出现的validate-output.ts在 scripts/validate-output.ts 实现它把提示词里的 JSON 契约变成可执行的硬约束值得作为工程细节细看基于 zod 定义三套严格模式strict()多余字段一律拒绝ReviewOutputSchema、VerificationOutputSchema、ConsolidationOutputSchema通过validateOutput(kind, value)统一入口OutputKind即review | verify | consolidateextractJsonPayload负责从子代理回复中提取围栏 JSON无围栏时容忍裸 JSON 直接输入存在围栏时必须唯一且闭合否则抛出JSON fence is not closed/Multiple JSON fences found交叉校验用superRefine实现例如exposed_legacy必须带exposure与scenariointroduced不得带exposurelikelihood: low必须带scenarioreuse-architecture必须带existing_implementations所有 id 集合去重后大小必须与原始一致查重复验证侧用discriminatedUnion(verdict, ...)保证每种裁决只携带属于自己的字段——false_positive上出现evidence字段即报错不变量的另一半非自动修复的 confirmed 必须给auto_fix_reason同样在此强制CLI 入口validate-output.ts review|verify|consolidate [input-file]无文件参数时从 stdin 读入成功打印Valid kind outputzod 错误以 JSON 形式输出到 stderr 并置退出码 1。对应的测试文件 validate-output.test.ts 覆盖了围栏提取的五个分支含多围栏拒绝、未闭合围栏拒绝以及三类 payload 的正反例如severity: p3拒绝、exposed_legacy缺 exposure 拒绝、重复 consolidate id 拒绝可视为整套输出契约的可执行规约。小结规则即质量的编排哲学回看这份 Claude Code 手册八步流程与 SKILL.md 的五条核心原则一一对应审查者只见 diff 碎片必然虚构 bug因此独立验证子代理逐条证伪并给出三路裁决anti-hallucination审查与验证绝不共用同一代理、主代理永不亲自复核anti self-approval所有子代理跑 balanced/fast 档位质量由维度规则文件承载rules over model校准规则让 diff 按代码库现状与生命周期评判一波并行 逐维度流水线验证 前置剪枝则把速度本身当作特性。整个编排中没有一处依赖更强的模型或更长的上下文取而代之的是自包含提示词、可执行 JSON 契约、id 一对一比对与不变量重派——这套机制正是 LobeHub 将多代理代码审查从演示变成可重复流程的关键。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考