ECC 多视角 PR 审查指南：基于 `/review-pr` 命令的特化 Agent 流水线实战

ECC 多视角 PR 审查指南基于/review-pr命令的特化 Agent 流水线实战【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC导读本文介绍 ECCThe agent harness performance optimization system中用于拉取请求Pull Request全面多视角审查的/review-pr命令。该命令面向 Claude Code、Codex、Opencode、Cursor 等 Agent 开发环境通过串联code-reviewer、comment-analyzer、pr-test-analyzer、silent-failure-hunter、type-design-analyzer、code-simplifier六类特化审查 Agent对 PR 的代码质量、安全性、测试覆盖、静默失败、类型设计与可维护性进行一站式交叉审查。读完本文你将掌握/review-pr的完整调用语法、--focus定向审查模式、其五步执行流水线以及「置信度 ≥ 80 才上报」的噪音过滤规则并理解这一机制在仓库源码与测试中的落地实现。命令概览一条命令完成多视角 PR 审查/review-pr的核心目标是不再依赖单一视角的泛泛检查而是用多个各司其职的特化 Agent 从不同维度并行审视同一个 PR最后聚合去重、按严重度排序输出。其完整用法如下命令定义/review-pr [PR番号またはURL] [--focuscomments|tests|errors|types|code|simplify]中文语境下的等价写法/review-pr [PR编号或URL] [--focuscomments|tests|errors|types|code|simplify]参数行为遵循两条默认规则未指定 PR 时自动审查当前分支对应的 PR未指定--focus时执行完整审查栈full review stack即六个特化 Agent 全部上场。--focus参数用于按需定向审查可选值与审查维度的对应关系如下focus 值审查维度对应特化 Agentcomments注释准确性、完整度与维护价值comment-analyzertests测试覆盖质量与行为覆盖pr-test-analyzererrors静默失败、吞掉的异常与缺失的错误传播silent-failure-huntertypes类型封装、不变式表达与强制力type-design-analyzercode代码质量、安全性与可维护性code-reviewersimplify代码简化与可读性提炼code-simplifier从 focus 值与 agents/ 目录下的特化 Agent 命名一一对应的关系可以推断--focus的每个取值会直接激活对应维度的单个特化 Agent而缺省时则执行全量六 Agent 的完整流水线。五步执行流水线/review-pr的内部流程分为五个阶段命令定义每一步职责清晰、可独立验证第一步识别 PR 并获取变更信息。命令通过 GitHub CLI 的gh pr view拉取 PR 详情、变更文件列表changed files与 diff。这一步是整个审查的事实基础——后续所有 Agent 都基于这一份 diff 开展工作。第二步检索项目规范与工程约定。在仓库中查找CLAUDE.md、lint 配置、TypeScript 配置如tsconfig、以及仓库约定repo conventions。这一步保证了审查不是通用模板化的而是贴合项目自身风格与规则的。ECC 仓库根目录即存在 CLAUDE.md、AGENTS.md 等工程指引文件特化 Agent 会把这类文件作为「项目专属审查准则」的依据详见code-reviewer中的 Project-Specific Guidelines 一节。第三步并行执行特化审查 Agent。依次或并行运行六个特化 Agentcode-reviewer资深代码审查专家覆盖安全性CRITICAL 级、代码质量HIGH 级、React/Next.js 模式、Node.js/后端模式、性能MEDIUM 级与最佳实践LOW 级等完整清单comment-analyzer从事实准确性、完整性、长期价值、误导性元素四个维度审查代码注释pr-test-analyzer核对 PR 的测试是否真正覆盖了变更行为区分 critical / important / nice-to-have 三类覆盖缺口silent-failure-hunter对空 catch 块、记录不足的日志、危险的默认回退、错误传播丢失、缺失的错误处理五类静默失败零容忍type-design-analyzer从封装性、不变式表达、不变式实用性、强制力四个维度评估类型设计code-simplifier在严格保持行为等价的前提下简化结构、提升可读性。第四步聚合与去重排序。汇总六个 Agent 的输出剔除重叠发现dedupe overlapping findings并按严重度排序rank by severity。ECC 的 orch-review.workflow.js 工作流脚本正是这一思想的工程化落地它声明了「Review每维度一个审查 Agent 并行 Verify对抗性反驳每一条 CRITICAL/HIGH 发现」两个阶段并对 diff 缺失等非法输入采取fail closed策略——宁可审查失败也不静默放行未审查的载荷。第五步按严重度分组输出报告。最终报告以 Critical / Important / Advisory 分级呈现便于维护者快速定位必须修复项与可延后项。置信度规则只上报有把握的问题/review-pr最核心的质量闸门是一条硬性置信度规则只报告置信度 ≥ 80 的问题。这一规则直接继承了code-reviewer等 Agent 的「Confidence-Based Filtering」机制code-reviewer其设计动机是LLM 审查者最主要的失败模式是制造噪声——编造发现、填充琐碎问题、抛出没有触发条件的假设性边界用例。与置信度规则配套的还有三条严重度分级标准Critical致命bug、安全漏洞、数据丢失。此类问题必须被标记它们会造成真实损害——典型包括硬编码凭据、SQL 注入、XSS、路径遍历、CSRF、认证绕过、不安全的依赖、日志泄露敏感信息Important重要测试缺失、质量问题、风格违规。例如超过 50 行的大函数、超过 4 层的深嵌套、缺失错误处理、未覆盖的新代码路径、死代码Advisory建议仅在明确要求时才提出。这与code-reviewer中不要为了显得严格而扣住批准的原则一脉相承——干净的 diff 应该得到 APPROVE 而不是被强行挑刺。在code-reviewer中还有一层更严格的「Pre-Report Gate」前置闸门可作为理解置信度规则的补充每条发现都必须能回答四个问题——能否引用精确行号能否描述具体失败模式输入、状态、坏结果是否读过周边上下文调用方、导入、测试严重度是否站得住脚任一项为否就应降级或丢弃。HIGH/CRITICAL 级别发现还额外要求提供代码片段与行号、具体失败场景、以及为何现有类型/校验/框架默认值无法拦截它这三项证据。内置防误报清单跳过这些常见假阳性为了让置信度 ≥ 80可执行特化 Agent 还内置了一份常见误报清单code-reviewer明确指示 LLM 审查者在以下场景中不要轻易标记除非有本仓库特有的证据错误路径已由调用方或框架处理如 Express 错误中间件、React error boundary、顶层try/catch却仍建议增加错误处理内部函数调用方已验证输入却标记缺少输入校验对众所周知常量200、404、1000ms、60、24、1024、索引0/-1、HTTP 状态码标记魔法数字对穷举式switch、配置对象、测试表、生成代码标记函数过长长度不等于复杂度对名称和签名自解释的单一用途内部辅助函数标记缺少 JSDoc变量确实被重新赋值时建议用const代替let前一行已收窄类型或存在if守卫时标记可能的空指针解引用对固定基数循环如遍历四元素枚举或已使用 DataLoader/批处理的路径标记N1 查询对刻意分离的 fire-and-forget 调用日志、指标、后台队列推送标记缺少 await在纯 JavaScript 文件中建议应该用 TypeScript对测试固件、示例代码、文档片段中的硬编码值标记硬编码在非密码学上下文动画、抖动、采样标记Math.random()或在显式作为代码加载面的插件系统中标记eval/Function。审查者遇到上述诱惑时的自检问题是这个团队的高级工程师真的会在 review 中改这个吗如果答案是否定的就跳过。这套机制在工程上直接抑制了 LLM 审查最常见的信息噪声是报告置信度 ≥ 80 的问题这条规则能够真正落地的前提。输出格式按严重度组织、以摘要收尾/review-pr的最终输出遵循 code-reviewer 定义的统一格式每条发现包含严重度标签、文件与行号、问题描述与修复建议报告末尾附上严重度统计摘要表与结论Verdict。典型的单条发现格式为[CRITICAL] Hardcoded API key in source File: src/api/client.ts:42 Issue: API key sk-abc... exposed in source code. This will be committed to git history. Fix: Move to environment variable and add to .gitignore/.env.example const apiKey sk-abc123; // BAD const apiKey process.env.API_KEY; // GOOD收尾摘要表与结论如下## Review Summary | Severity | Count | Status | |----------|-------|--------| | CRITICAL | 0 | pass | | HIGH | 2 | warn | | MEDIUM | 3 | info | | LOW | 1 | note | Verdict: WARNING — 2 HIGH issues should be resolved before merge.结论判定遵循三条标准Approval CriteriaApprove——无 CRITICAL 或 HIGH 问题包括零发现的干净审查这是有效且被期望的结果Warning——仅有 HIGH 问题可谨慎合并Block——发现 CRITICAL 问题必须在合并前修复。源码级佐证从命令文档到工作流与测试/review-pr不是孤立存在的文档命令它在仓库中有完整的工程支撑命令本体英文原版定义位于 commands/review-pr.md本文基于的日语版本位于 docs/ja-JP/commands/review-pr.md属于 ECC 多语言文档体系的一部分Agent 定义六个特化 Agent 分别定义在 agents/ 目录每个文件包含其角色描述、审查流程、检查清单、输出格式与 Prompt Defense Baseline提示词防御基线用于抵御提示注入与角色覆盖攻击工作流实现workflows/orch-review.workflow.js 将多维度审查 对抗性验证固化为原生工作流通过LANGUAGE_REVIEWER映射表按语言选择审查 Agenttypescript/javascript→typescript-reviewer、python→python-reviewer、go→go-reviewer 等并用SECURITY_TRIGGER正则匹配 auth、login、token、secret、sql、eval、crypto、fs、fetch 等敏感关键字决定是否触发安全专项审查最终产出blocking确认的 CRITICAL/HIGH 无法验证项与advisoryMEDIUM/LOW 已被有力反驳的项两类发现——这正对应/review-pr的聚合去重、按严重度分组步骤测试验证tests/docs/codex-navigation-map.test.js 中明确断言文档必须覆盖 PR Diff Packet、git diff origin/main...HEAD --stat、/pr、/review-pr等 PR 工作流标记确保/review-pr作为正式命令面canonical surface被持续文档化与测试保护。最佳实践与适用前提基于命令文档与 Agent 定义可以总结出几条实战建议日常合入前跑全量默认不带--focus执行完整审查栈让六个维度互相补充——例如code-reviewer发现的安全问题与pr-test-analyzer发现的覆盖缺口往往是同一处变更的两面定向返工时用--focus当修复集中在某一维度如补测试用--focustests、排查被吞掉的异常用--focuserrors定向审查能显著降低 token 成本与噪音理解严重度的行动语义Critical 必须修复、Important 应谨慎处理、Advisory 默认忽略——不要把建议当阻塞项也不要放过真正的致命问题先检索项目规范再审查流水线第二步强调读取CLAUDE.md、lint 配置与仓库约定说明/review-pr的设计前提是审查标准随项目自适应在引入该命令的项目中应确保这些规范文件存在且最新。需要说明的适用前提是/review-pr依赖 GitHub CLIgh pr view获取 PR 数据因此其完整流程面向托管在 GitHub 上的仓库当前分支若无关联 PR则需显式传入 PR 编号或 URL。命令、Agent 与工作流的具体行为以本仓库当前内容为准commands/review-pr.md、agents/目录及workflows/orch-review.workflow.js。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考