解剖 Gemini CLI 的 code-reviewer 技能：Google 如何打造规范化的 AI 代码审查员
深度解剖 Google 官方在 google-gemini/gemini-cli 开源的 code-reviewer 技能，探索其七大分析维度与结构化审查流程。
落梦陳4 分钟阅读3 次浏览解剖 Gemini CLI 的 code-reviewer 技能：Google 如何打造规范化的 AI 代码审查员
在 AI 驱动的代码编写与重构逐渐成为日常的今天，代码审查（Code Review）成为了保障项目质量的最后一道关卡。Google 官方在 google-gemini/gemini-cli 仓库中开源的 .gemini/skills/code-reviewer 技能，展示了一套高度结构化、严谨且可落地的 AI Code Review 最佳实践。
图 1：Gemini CLI 项目展示图（来源：Google Gemini / GitHub 官方仓库）
不同于随意提示 AI“帮我审查一下这段代码”，Gemini CLI 的 code-reviewer 技能通过定义明确的工作流（Workflow）、七大分析维度（Pillars of Analysis）以及规范的反馈结构，让 AI 助手能够像资深技术专家一样处理本地修改与远程 Pull Request。
本文将深入解剖 code-reviewer 技能的核心设计、工作流程与规范逻辑，探讨其给 AI 编程助手落地带来的启示。
技能定位与核心工作流
code-reviewer 是一个面向 Gemini CLI 开发的 Agent Skill，遵循标准的 SKILL.md 规范。它的核心目标是帮助 AI 智能体在处理代码审查任务时，兼顾正确性、可维护性与项目规范。
其工作流（Workflow）分为五个阶段：
1. 确定审查目标 (Target)
├── 远程 PR (如 "Review PR #123")
└── 本地修改 (Staged / Unstaged Working Tree)
2. 准备阶段 (Preparation)
├── 远程: gh pr checkout + npm run preflight
└── 本地: git status + git diff + 可选预检
3. 深度分析 (In-Depth Analysis)
└── 围绕 7 大维度全面评估代码质量
4. 结构化反馈 (Feedback)
└── Summary -> Critical/Improvements/Nitpicks -> Conclusion
5. 清理恢复 (Cleanup)
└── 提示切回默认分支 (Main/Master)深度解剖：七大分析维度（The 7 Pillars of Analysis）
评估一份代码的好坏不能仅看能否运行。code-reviewer 技能明确指出了 AI 在审查代码时必须考量的 7 大关键维度：
维度 | 审查要点 | AI 关注细节 |
|---|---|---|
正确性 (Correctness) | 逻辑与功能实现 | 是否符合预期功能？是否存在隐蔽的逻辑错误或 Bug？ |
可维护性 (Maintainability) | 结构与扩展性 | 代码是否干净清晰？模块划成分隔是否合理？是否遵循已知设计模式？ |
可读性 (Readability) | 格式与注释 | 是否遵循项目代码风格？复杂逻辑是否有必要的注释说明？ |
效率 (Efficiency) | 性能与资源 | 变更是否引入了明显的性能瓶颈或资源浪费？ |
安全性 (Security) | 漏洞与安全实践 | 是否包含潜在的安全漏洞、不安全 API 或敏感泄漏风险？ |
边界条件与错误处理 (Edge Cases & Errors) | 健壮性 | 是否充分考虑了边界情况？异常处理是否得当？ |
可测试性 (Testability) | 测试覆盖 | 变更是否附带测试？预检通过后是否仍需补充边缘测试用例？ |
这种维度划分让 AI 摆脱了泛泛而谈的“这段代码写得不错”，转而针对具体指标给出精准、可衡量的评价。
标准化的反馈格式与语气规范
良好的 Code Review 不仅需要找到问题，更需要清晰、建设性的沟通。code-reviewer 在反馈格式与沟通语气上设定了明确要求。
结构化反馈模版
AI 生成的审查报告必须包含以下三大区块：
- Summary（概要）：简明扼要地总结本次变更的范围与总体印象。
- Findings（审查发现）：
- Critical（致命问题）：Bug、安全漏洞、破坏性变更（Breaking Changes），属于 Blocking 问题。 - Improvements（改进建议）：可提升代码质量、架构或性能的非阻塞性建议。 - Nitpicks（细节挑剔）：代码格式、命名规范等微小调整（可选）。
- Conclusion（最终结论）：明确给出评价结果——
Approved（通过）或Request Changes（需要修改）。
语气指导（Tone Guidelines）
- 建设性与专业性：保持友善、专业的语气，指出问题时必须说明原因（Why）而不仅是结论。
- 正面反馈：对于批准（Approved）的 PR，应当明确肯定作者的具体贡献价值。
实践示范：远程 PR 与本地修改的差异化处理
code-reviewer 技能在设计上非常注重自动化工具的协同。
处理远程 PR
当用户要求审查特定 PR（如 Review PR #42）时，技能指导 AI 执行工具链结合：
# 1. 自动检出 PR 分支
gh pr checkout 42
# 2. 执行项目自动验证套件，先拦截编译错误和单测失败
npm run preflight只有当预检（Preflight）通过后，AI 才开始阅读 PR 的 Description 和历史评论，开展人工级别的逻辑审查。最后还会贴心地提示用户是否切回主分支。
处理本地未提交变更
对于开发过程中的本地代码审查，AI 会通过：
git status
git diff
git diff --staged准确获取暂存区与工作区变更，协助开发者在 commit 之前就完成自我审查（Self-Review），避免将低级错误带入代码库。
总结与启示
google-gemini/gemini-cli 仓库中的 code-reviewer 技能提供了一个极其优秀的规范样本。它告诉我们：
- 规范化 Workflow 胜过复杂的 Prompt：把复杂任务拆解成确定性的准备阶段、分析阶段和收尾阶段，能极大提升 AI 的输出质量。
- 多维度检查清单保证全面性：7 大分析维度为 AI 提供了清晰的标准规程，防止遗漏安全和边界测试。
- 分级反馈提升沟通效率：区分 Critical、Improvements 和 Nitpicks，让代码作者能第一时间解决最核心的缺陷。
通过将这套 Skill 引入团队的 AI 工具链，能够显著提升代码审查的标准化水平与开发效率。