技能使用指南

requesting-code-review（代码审查请求）Skill 是什么？如何下载？

代码审查请求Skill（requesting-code-review）把代码审查前置到每个任务完成后与合并前，通过调度代码审查员子代理、锁定 git 提交区间、按关键/重要/次要分级处置反馈，让问题在级联前被捕获。本文详解它的功能特点、分步用法、竞品对比与典型场景，帮你快速上手并判断是否适合自己。

代码审查请求Skillrequesting-code-review
8 个章节 约 15 分钟阅读 AI 智能生成

代码审查请求Skill：让代码审查在问题级联之前发生

在 AI 辅助开发越来越普遍的今天，一个人（或一个代理）连续写十几个任务、几百行代码已经成为常态。风险也随之而来：问题不是突然出现的，而是一层层叠加、级联放大的。requesting-code-review（代码审查请求）Skill 想解决的问题正是这一点——把代码审查变成开发流程里的一个固定动作，而不是等到合并前才想起的补救措施。

核心结论速览：

  • 它是什么：一个把「何时审查、如何审查、如何处理反馈」标准化的工作流技能，核心是调度「超级能力：代码审查员」子代理来完成审查。
  • 核心原则：早期审查，频繁审查。任务完成后、主要功能实现后、合并主分支前是三个强制审查点。
  • 怎么用：先取到 BASE_SHA 与 HEAD_SHA 两个提交点，再用 Task 工具按 code-reviewer.md 模板填写五个占位符并调度代码审查员子代理，最后按反馈分级处置。
  • 独特之处：它不只是「检查代码」，还给出了危险信号清单和「审查员判断有误时如何有理有据地回推」的处理方式。
  • 最适合谁：使用子代理驱动开发、按计划分批执行任务，或者任何希望把质量关口前移的开发者。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息：

  • 中文名：代码审查请求Skill
  • 英文名：requesting-code-review
  • 技能 ID：11206
  • 官方定位：在完成任务、实现主要功能或合并前使用，以验证工作是否符合要求

它解决什么问题？

在没有这个技能之前，代码审查往往有两个极端：要么完全不审，靠作者自己「感觉没问题」就提交；要么攒一大坨改动，等到合并前一次性审查，此时问题已经互相纠缠，改一处牵动三处，审查成本极高。这个技能把审查切碎、前置、常态化——在问题还没有级联之前就把它捕获。

「一键安装」的思路与步骤：

AI 技能的安装通常遵循「获取 → 注册 → 验证」三步，具体命令与入口请以官方说明为准，这里给出通用路径：

  1. 确认安装前提：你的 AI 编程助手需要支持「技能（Skill）」机制，并且支持「子代理（Sub-agent）」调度能力——因为本技能的核心动作是调度「超级能力：代码审查员」子代理，如果当前环境不支持子代理，就无法发挥完整效果。请以官方说明为准。
  2. 获取技能：按官方说明获取 requesting-code-review 技能的技能包，技能描述文件（name/description 的元数据）需与本技能一致，确保助手能正确识别触发时机。
  3. 放入技能目录或通过技能市场安装：按官方说明将技能注册到你的助手环境中，使助手在「完成任务、实现主要功能或合并前」这些时机能自动识别到它。
  4. 补齐依赖模板：本技能依赖 requesting-code-review/code-reviewer.md 这一审查模板文件，需要确保该文件随技能一同就位，否则调度子代理时缺少填写依据。
  5. 验证是否生效：随意完成一个小改动后，对助手说「在继续之前，先请求代码审查」，看它是否会主动去获取 git SHA 并调度代码审查员子代理；如果它能按模板输出五类信息（实现了什么、要求是什么、起始提交、结束提交、简要摘要），说明安装成功。

2. 该技能的主要功能和特点

  • 审查时机标准化：把「什么时候该审查」写成了明确规则，而不是凭手感。强制场景包括：子代理驱动开发中的每个任务后、完成主要功能后、合并到主分支前；可选但有价值的场景包括：遇到困难时、重构前、修复复杂错误后。
  • 提交区间精确定位：通过 git rev-parse 取 BASE_SHA 和 HEAD_SHA，把审查范围锁定在一段明确的提交区间内，避免「审全部」这种不可执行的要求。
  • 子代理调度机制：用 Task 工具调度「超级能力：代码审查员」子代理，让审查由一个专门角色完成，而不是让写代码的同一个角色自我评价——这是它比普通自查更强的关键。
  • 结构化审查模板：模板固定在 code-reviewer.md，占位符包括 {WHAT_WAS_IMPLEMENTED}（刚构建了什么）、{PLAN_OR_REQUIREMENTS}（它应该做什么）、{BASE_SHA}、{HEAD_SHA}、{DESCRIPTION}。结构化输入带来结构化输出，审查结果包含优点、问题分级和是否准备继续的评估。
  • 反馈分级处置：关键问题立即修复；重要问题在继续前修复；次要问题标记待后续处理。避免「所有问题一视同仁」导致的流程卡死。
  • 允许有理有据地回推：如果审查员判断有误，可以用技术理由回推、展示证明其工作的代码或测试、并请求澄清——这不是对抗，而是流程的一部分。
  • 与不同工作流集成：子代理驱动开发是「每个任务后审查」，执行计划是「每批 3 个任务后审查」，临时开发是「合并前审查 + 卡壳时审查」。
  • 危险信号清单：明确列出四种「从不」行为——因为「简单」而跳过审查、忽略关键问题、未修复重要问题就继续、与有效的技术反馈争论。

3. 如何使用该技能？

以下是基于技能内容整理的分步使用指南：

步骤 1：确认是否到达审查点

先看当前处于哪个阶段。如果刚完成一个任务、刚实现一个主要功能，或者马上要合并到主分支，就属于强制审查；如果正卡在一个难解的问题上、准备大改结构、或刚修完一个复杂错误，则属于「可选但有价值」的审查时机。

步骤 2：获取两个 git 提交点

在命令行中取到起始和结束提交：

BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)

如果想定位到某个具体任务，也可以先通过提交日志查找，例如：

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

步骤 3：调度代码审查员子代理

使用 Task 工具，类型选择「超级能力：代码审查员」，按 requesting-code-review/code-reviewer.md 中的模板填写五个占位符：

  • {WHAT_WAS_IMPLEMENTED}：你刚刚构建的内容
  • {PLAN_OR_REQUIREMENTS}：它应该做什么
  • {BASE_SHA}：起始提交
  • {HEAD_SHA}：结束提交
  • {DESCRIPTION}：简要摘要

步骤 4：阅读审查输出并分级

审查结果通常包含三块：优点、问题（按重要程度分级）、以及「是否准备继续」的评估。

步骤 5：按等级处置

关键问题立即修复；重要问题在继续下一个任务前修复；次要问题记录下来留待后续。如果认为审查员判断有误，用技术理由回推，并给出代码或测试作为证据。

一个可直接参考的输入输出示例：

[刚完成任务 2：添加验证功能]

输入：
  WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复功能
  PLAN_OR_REQUIREMENTS: 来自 docs/plans/deployment-plan.md 的任务 2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，包含 4 种问题类型

输出：
  优点：清洁架构，真实测试
  问题：
    重要：缺少进度指示器
    次要：报告间隔的魔法数字（100）
  评估：准备继续

后续动作：[修复进度指示器] → 继续任务 3

请注意这个例子中的处理方式：重要的「缺少进度指示器」被当场修掉，次要的「魔法数字 100」被标记后置，而不是阻塞整个流程。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
requesting-code-review（代码审查请求Skill） 面向 AI 辅助开发流程的「审查调度」技能 判断审查时机、取提交区间、调度代码审查员子代理、反馈分级处置、允许技术回推 需要支持技能机制与子代理调度的 AI 助手环境，具体以官方说明为准 子代理驱动开发逐任务审查、执行计划分批审查、合并前把关 优势：把审查嵌入流程而非事后补救，输出结构化、可执行；不足：依赖子代理能力，环境不支持时效果打折
GitHub Pull Request 评审 平台化的协作式合并前评审 差异对比、评论、Approval/Request changes、合并门禁 需托管在对应平台并配置分支保护 团队协作、开源项目合并 优势：流程规范、留痕完整、多人参与；不足：偏重人工评审，反馈速度取决于评审人，不适合单人高频小步提交
静态代码分析工具（如 SonarQube、ESLint 类） 规则驱动的自动化检查 代码规范、潜在缺陷、覆盖率、质量门禁 需配置规则集与 CI 集成，学习成本中等 规范统一、持续集成中的质量卡点 优势：可重复、可规模化、误报可通过规则调优；不足：只识别「规则能描述的问题」，对架构合理性、需求是否被满足缺乏判断
AI 代码审查机器人（如各类 PR 自动评论服务） 在代码托管平台上自动生成审查意见 自动生成评论、摘要、建议修改 通常需授权仓库访问，具体以官方说明为准 托管平台内的自动化初筛 优势：接入快、无需改变既有流程；不足：多为一次性评论，缺少「分级处置 + 回推 + 继续」的闭环流程约束

从对比可以看出，requesting-code-review 的差异点不在「能发现多少问题」，而在「把审查变成流程中的固定环节」，并且给出了问题分级与回推机制，这是多数纯工具型方案不涉及的。

5. 该技能的典型应用场景与实际体验情况

场景一：子代理驱动开发中的逐任务审查

角色：按任务清单逐条推进的开发者或代理。痛点：连续完成多个任务后，早期任务里的设计缺陷会被后续任务反复依赖，越改越贵。使用方式：每个任务完成后立刻取 SHA 并调度审查，在进入下一个任务前修掉重要问题。实际体验：这是本技能价值最高的用法，拦截点足够早，修一个函数的成本远低于修三个依赖它的模块。注意：需要克制「这个任务很简单，跳过吧」的冲动，技能里明确把「因为简单而跳过审查」列为危险信号。

场景二：合并主分支前的最后一道关

角色：个人开发者或小团队。痛点：改动攒到合并前已经很大，人工看一眼很难看出遗漏。使用方式：以 origin/main 为 BASE_SHA、当前 HEAD 为 HEAD_SHA，提交一次完整区间审查。实际体验：审查输出会明确给出「准备继续 / 需要修复」的评估，比自己反复读 diff 更省力。注意：合并前审查发现的问题往往较多，要按关键、重要、次要三级排优先级，不要试图一次全部清零。

场景三：遇到困难时换一个新鲜视角

角色：卡在一个难解问题上的开发者。痛点：长时间盯同一段代码，容易形成思维定式。使用方式：把当前进展和需求一起交给代码审查员子代理，让它从需求符合度角度给意见。实际体验：它未必直接给出解法，但常能指出「你实现的和计划里要求的不是一回事」这类盲区。注意：这类调用属于可选场景，不要期待它替代调试。

场景四：重构前的基准检查与复杂错误修复后的复查

角色：准备大改结构的开发者。痛点：重构前如果代码本身已有问题，重构会把问题一起带过去。使用方式：重构前先审一次，记录基线；复杂错误修完后再审一次，确认修复没有引入新问题。实际体验：相当于给重构和修 bug 各加了一个「存档点」，回滚判断更有依据。

整体上手难度：低。核心动作只有三步——取 SHA、填模板、调度子代理，命令都是常规 git 操作。真正的门槛在习惯养成：能否坚持在每个任务后都触发一次。

6. 该技能能为用户带来的价值

  • 把质量问题拦截在上游：强制审查点设在「每个任务后」和「主要功能完成后」，意味着大多数问题在还没被其他代码依赖时就被发现，修复成本按级联层数呈指数下降。
  • 降低审查的启动门槛：很多人不审查，不是不想，而是不知道审什么、从哪开始。技能把输入模板化（五个占位符），把输出结构化（优点/问题分级/评估），审查从一个模糊动作变成一个有明确边界的任务。
  • 减少无效争论与流程僵局：分级处置规则让「必须现在修」和「可以以后修」有明确区分；回推机制则保证审查意见不是圣旨，技术理由和测试证据可以推翻误判，团队不会因为一条错误意见停摆。
  • 提高 AI 辅助开发的可靠性：在代理连续执行任务的模式下，最大的风险是错误被后续任务当成既定事实。逐任务审查相当于给每一步加了一个校验点，让「快速生成」不至于变成「快速积累债务」。
  • 长期价值：形成可复用的质量习惯：危险信号清单（不因简单而跳过、不忽略关键问题、不带病继续、不与有效反馈争论）本身是一套可迁移的工程习惯，脱离这个技能也依然有效。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？

安装路径取决于你使用的 AI 助手是否支持技能机制与子代理调度，具体命令、入口与是否收费请以官方说明为准。可以确定的是，技能本身依赖两项能力：技能加载和子代理调度；同时需要确保 requesting-code-review/code-reviewer.md 模板文件随技能一同就位。

Q2：每个任务后都必须审查吗？小改动也要？

技能给出的规则是：子代理驱动开发中每个任务后、完成主要功能后、合并主分支前属于强制审查；遇到困难、重构前、修复复杂错误后属于可选但值得做。同时它明确把「因为简单而跳过审查」列为危险信号——小改动往往正是最容易被忽略、也最容易埋雷的地方。

Q3：如果代码审查员子代理的判断是错的怎么办？

技能明确允许回推，而且给出了方法：用技术理由说明、展示证明其工作的代码或测试、请求澄清。这与「与有效的技术反馈争论」是两回事——前者是基于证据的纠正，后者是危险信号。判断标准很简单：你手上有没有能跑通的测试或可验证的证据。

Q4：它和 GitHub PR 评审、静态代码分析工具怎么选？

三者并不冲突，定位不同：静态分析工具擅长规则能描述的问题（规范、潜在缺陷）；PR 评审擅长多人协作与留痕；requesting-code-review 擅长在 AI 辅助开发的流程内部设置审查时机并闭环处理反馈。实践中常见组合是：静态分析进 CI 做基础卡点，本技能做逐任务的早期拦截，PR 评审做合并前的最终确认。

Q5：适合谁用？

最适合使用子代理驱动开发、按计划分批推进任务的开发者，以及任何希望把代码审查从「合并前的大动作」变成「任务后的小习惯」的个人或小团队。如果当前环境不支持子代理调度，本技能的核心机制无法完整运行，建议先确认环境能力。