本项目里有多组与代码审查相关的插件code-review、pr-review-toolkit和security-guidance。它们关注的问题不同但组合起来可以覆盖 Pull Request 审查、专项质量检查和安全风险发现。这类能力的重点不是让 AI 取代人工 Review而是把重复、机械、容易遗漏的检查提前完成让人工审查者把注意力放在设计取舍、业务语义和长期维护成本上。code-review面向 PR 的自动审查流程plugins/code-review提供/code-review命令。它的流程比较完整判断当前 PR 是否需要审查跳过关闭、草稿、琐碎或已经审查过的 PR。收集仓库中的 CLAUDE.md 规范文件。总结 PR 变更。启动多个并行 Agent从不同角度独立审查。为每个问题打 0 到 100 的置信度分。过滤低于 80 分的问题。输出到终端或通过--comment写入 PR 评论。这个流程里最重要的是“独立审查”和“置信度过滤”。多 Agent 可以减少单一视角带来的遗漏置信度阈值则用来控制噪声。对于自动化 Review 来说低质量建议比没有建议更糟因为它会消耗审查者信任。pr-review-toolkit把审查拆成专项能力plugins/pr-review-toolkit的思路更细它提供多个专门 Agentcomment-analyzer检查注释准确性和文档维护风险。pr-test-analyzer关注测试覆盖、边界条件和测试质量。silent-failure-hunter寻找静默失败和不充分的错误处理。type-design-analyzer评估类型设计、约束表达和不变量 enforcement。code-reviewer做通用代码审查。code-simplifier关注简化和可读性。这种拆分很适合在 PR 临近完成时使用。比如新增了大量错误处理逻辑就让silent-failure-hunter专门看 catch 分支新增了数据模型就让type-design-analyzer评估类型是否真的表达了约束。专项 Agent 的优势在于问题定义更窄输出也更可执行。它不需要泛泛地说“代码质量一般”而是直接指出“这个 catch 分支吞掉错误且没有日志”或“这个类型允许无效状态”。security-guidance安全审查的三层防线plugins/security-guidance不是普通代码风格插件它把安全检查拆成三层第一层是正则模式提醒在编辑或写入时捕获常见危险模式例如不安全反序列化、硬编码密钥、原始innerHTML、命令执行等。第二层是会话结束时的 LLM diff review把变更差异发送给模型审查并把高严重度发现反馈回来。第三层是在git commit时执行 Agentic commit review读取相关文件并跨文件追踪数据流发现 IDOR、鉴权绕过、SSRF 等单文件模式难以识别的问题。这三层覆盖了不同时间点。模式提醒偏即时diff review 偏阶段总结commit review 偏提交门禁。安全问题越早暴露修复成本越低。如何组合使用一个比较稳妥的 PR 工作流可以这样设计开发过程中启用security-guidance让明显危险模式尽早暴露。功能完成后运行/code-review获取多 Agent 对 PR 的综合审查。对关键模块按需调用pr-review-toolkit的专项 Agent例如测试、错误处理、类型设计。提交前保留安全 commit review避免跨文件漏洞漏进主干。人工审查者基于自动化结果继续判断业务语义和架构取舍。这里不要把所有工具一次性堆满每个 PR。小改动可以只跑通用审查涉及鉴权、支付、数据导出、权限模型的 PR则应该引入安全和专项 Agent。自动审查的边界自动审查可以发现明显 Bug、规范违反、测试缺口、安全风险和复杂度问题但它无法完全理解组织优先级、业务策略和产品语境。比如某段代码是否符合长期路线、某个接口是否应该兼容旧客户、某个异常是否可以被业务接受仍然需要人判断。因此本项目给出的最佳实践不是“让 AI 批准 PR”而是“让 AI 提供高信号候选问题”。特别是code-review中 80 分置信度阈值的设计本质上就是把自动化审查定位为高精度辅助而不是无差别建议生成器。如果团队要落地这套能力建议先从一个明确目标开始减少明显 Bug、补齐测试缺口、检查错误处理或强化安全审查。等团队对输出质量建立信任后再逐步把它接入更正式的 PR 流程。