请求代码审查：在问题级联之前，把代码审查变成开发流程的固定动作
- 它是流程型技能，不是工具型技能：请求代码审查（requesting-code-review）不直接改写代码，而是把“什么时候审、审什么、怎么审”固化成一套可执行的动作，核心原则只有八个字——早期审查，频繁审查。
- 审查靠“派遣子代理”完成：技能会派遣
superpowers:code-reviewer子代理，按模板requesting-code-review/code-reviewer.md对指定提交区间做评审。 - 审查范围由 git SHA 精确定义：通过
BASE_SHA与HEAD_SHA锁定被审查的代码区间，避免“全仓库泛泛而谈”。 - 反馈有明确优先级：关键问题立即修、重要问题继续前修、次要问题标记后置，同时允许附技术理由对错误结论提出异议。
- 最适合与子代理驱动开发配合：每个任务完成后即审查，把缺陷拦截在任务边界，而不是等合并前集中爆发。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
该技能的中文名为请求代码审查，英文名为 requesting-code-review，技能 ID 为 13650。
它要解决的是一个非常具体的工程问题：AI 或开发者“做完一段就往下做”，中间没有质量关卡，导致问题层层级联，等到合并或联调时才发现，返工成本已经翻了几倍。这个技能把“完成任务 → 请求审查 → 处理反馈 → 继续”写成了一条闭环，让审查从事后补救变成流程中的固定动作。
关于“一键安装”，其思路可以概括为三步：
第一步：确认安装前提。 该技能依赖两个能力：一是能调用 Task 工具派遣子代理，二是技能目录中存在 superpowers:code-reviewer 子代理类型与 requesting-code-review/code-reviewer.md 模板。因此需要在一个支持 AI 技能（Skill）机制、且具备子代理（sub-agent）调度能力的 AI 编程环境中使用。具体支持的客户端与版本要求，以官方说明为准。
第二步：通过技能入口安装。 在支持该技能的平台中，通过技能市场、技能仓库或本地技能目录把 requesting-code-review 添加进可用技能列表。具体安装命令、仓库地址与目录路径，本技能详情中未给出，请以官方说明为准。安装完成后，建议确认 requesting-code-review/code-reviewer.md 模板文件随技能一同就位。
第三步：验证是否生效。 在一个已有 Git 提交记录的仓库中，完成任意一个小改动并提交，然后对 AI 说“在继续之前，请求代码审查”。若技能已生效，它应当引导你获取 BASE_SHA/HEAD_SHA，并以 superpowers:code-reviewer 子代理的身份返回“优点 / 问题（重要 / 次要）/ 评估”结构的反馈；如果它只是笼统地评价代码，说明子代理或模板未正确加载，需要回到第二步排查。
2. 该技能的主要功能和特点
- 强制审查时机管理：明确列出三个必审节点——子代理驱动开发中的每个任务之后、完成主要功能之后、合并到主分支之前。把这些节点写死，是为了防止“这次很简单，跳过吧”的自我妥协。
- 可选但高价值的审查时机：卡住时（借新鲜视角破局）、重构之前（先做基线检查）、修复复杂错误之后（防止修一个引出一个），这三类场景被单独列出，方便在非标准流程中也能主动调用。
- 基于 git SHA 的精确审查范围：先用
git rev-parse HEAD~1（或origin/main）拿BASE_SHA，再用git rev-parse HEAD拿HEAD_SHA，把“审哪一段”变成可复现的确定性信息，而不是凭印象描述。 - 结构化模板与五个占位符：派遣子代理时填写
code-reviewer.md模板，需要提供{WHAT_WAS_IMPLEMENTED}（刚构建了什么）、{PLAN_OR_REQUIREMENTS}（它应该做什么）、{BASE_SHA}、{HEAD_SHA}、{DESCRIPTION}（简要摘要）。核心特点是拿“计划”当标尺审“实现”，而不是无参照地评价代码好坏。 - 反馈分级处理机制：关键问题立即修复、重要问题在继续之前修复、次要问题标记待办。分级让“要不要现在停下来”不再靠感觉。
- 允许有理有据地提出异议：如果审查者判断有误，可以用技术理由提出异议、展示证明其可行的代码或测试、请求澄清——这避免了“AI 说错我也照改”的反向损耗。
- 与工作流的三种集成形态：子代理驱动开发（每个任务后审）、执行计划（每批次约 3 个任务后审）、临时开发（合并前或卡住时审）。
- 红旗警告清单：从不因为“它很简单”跳过审查、从不忽略关键问题、从不在重要问题未修复时继续、从不与有效的技术反馈争论。
和普通代码检查工具相比，它的差异在于管的是流程与判定标准：普通工具回答“这行代码有没有问题”，它回答“现在该不该停下来审、拿什么标准审、审完怎么处置”。
3. 如何使用该技能？
第 1 步：确认触发时机。 对照技能给出的时机表，判断当前属于哪一种：刚完成一个任务？刚完成主要功能？准备合并？还是卡住了/准备重构？时机决定了审查的严格程度。
第 2 步：获取起止提交 SHA。 在终端执行：
BASE_SHA=$(git rev-parse HEAD~1) # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)
如果是要定位到某个任务对应的提交，也可以用 git log --oneline 找到该任务的提交号。
第 3 步：准备四项内容。 在派遣前，把 {WHAT_WAS_IMPLEMENTED}、{PLAN_OR_REQUIREMENTS}、{DESCRIPTION} 想清楚。其中 {PLAN_OR_REQUIREMENTS} 最好指向具体文档，例如“来自 docs/plans/deployment-plan.md 的任务 2”，这样审查才有客观标尺。
第 4 步：派遣 superpowers:code-reviewer 子代理。 使用 Task 工具、以 superpowers:code-reviewer 类型发起调用，并按 code-reviewer.md 模板填写占位符。
输入示例（对应技能文档中的样例场景）：
WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复函数
PLAN_OR_REQUIREMENTS: 来自 docs/plans/deployment-plan.md 的任务 2
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，覆盖 4 种问题类型
第 5 步：解读输出。 子代理通常返回三段：优点（如“干净的架构、真实的测试”）、问题清单（按重要/次要分级，如“重要：缺少进度指示器”“次要：报告间隔存在魔术数字 100”）、以及一句总体评估（如“可以继续”）。
第 6 步：按分级处置反馈。 关键问题当场改；重要问题改完再进入下一个任务；次要问题记录到待办清单后续处理。若认为审查结论不成立，附技术理由提出异议并补充证明性代码或测试。
第 7 步：记录并进入下一轮。 修复完成后（例如补上进度指示器），再继续到任务 3。若采用“执行计划”模式，则在每约 3 个任务构成的批次结束后集中审一次。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 请求代码审查（requesting-code-review） | 流程化的 AI 代码审查调度技能 | 时机管理 + git SHA 定位区间 + 模板化派遣 code-reviewer 子代理 + 反馈分级 + 可异议机制 |
需支持技能机制与子代理调度的 AI 编程环境，并具备 Git 仓库；具体安装方式以官方说明为准 | 子代理驱动开发、任务级审查、合并前把关 | 优势：把审查嵌进流程，审的是“实现是否符合计划”，可复现；不足：依赖 Git 提交规范与计划文档质量，自身不做静态规则扫描 |
| 人工 PR 评审（Pull Request Review） | 团队协作式人工把关 | 逐行评论、讨论串、审批流、合并门禁 | 需代码托管平台与团队协作流程，依赖评审人时间 | 团队协作、上线前终审 | 优势：经验判断强、责任明确；不足：人力成本高、反馈延迟大，小任务常常等不到评审 |
| 静态代码分析工具（如 ESLint、SonarQube 等） | 规则驱动的自动化扫描 | 语法与风格规则、缺陷模式匹配、质量门禁 | 需配置规则集与 CI 集成，规则误报需长期调优 | 风格统一、常见缺陷拦截、持续集成 | 优势：快、稳定、零沟通成本；不足：不懂“需求意图”，无法判断实现是否满足计划要求 |
| 通用 AI 编程助手对话式审查 | 即席的 AI 代码点评 | 直接粘贴代码让 AI 提意见 | 门槛最低，随时可用 | 零散片段、快速自查 | 优势：灵活；不足：无固定时机、无审查基线、反馈粒度与可追溯性弱，容易“说好话” |
可以看到，请求代码审查补的正是表格中间那块空白：既有 AI 的自动化速度，又有“按计划审实现”的基线意识，还带流程约束。
5. 该技能的典型应用场景与实际体验情况
场景一：子代理驱动开发中的任务级审查。 使用者是独立开发者或小团队，把大需求拆成多个任务交给 AI 逐个实现。痛点是任务 1 埋下的隐患到任务 4 才爆发，排查成本极高。使用方式是在每个任务完成后立即请求审查，把问题拦在任务边界。实际体验：上手难度很低，只要会说“在继续之前，请求代码审查”就能触发；效果上最明显的是“问题不再跨任务传播”，注意事项是必须保持提交粒度与任务粒度大致对齐，否则 SHA 区间会混入无关改动。
场景二：执行计划中的批次审查。 使用者是按计划文档推进项目的工程团队。痛点是计划与实现逐渐漂移，越到后期越难对齐。使用方式是把 {PLAN_OR_REQUIREMENTS} 指向具体计划文件，按每批约 3 个任务审一次。实际体验：审查反馈会直接落在“计划要求做到但实现没做”的地方，比如缺少进度指示器这类功能完整性缺口，这是规则扫描工具很难发现的问题类型；注意事项是计划文档本身要足够具体，否则审查标准会变模糊。
场景三：合并前的最后一道门。 使用者是习惯“临时开发”的工程师。痛点是直接合并主分支后才发现问题，回滚成本高。使用方式是在合并前请求一次审查，或在与 origin/main 对比的区间上审。实际体验：相当于给自己加了一道低成本的终审，尤其在长时间未提交、改动面积较大时价值明显；注意事项是区间过大时审查反馈会变粗，建议拆成多次小范围审查。
场景四：卡住时与重构前的“新鲜视角”。 使用者是长时间 debug 后陷入思维定式的开发者。痛点是越陷越深，或重构时不清楚当前基线是否健康。使用方式是在卡住时、重构前、修复复杂错误后主动请求审查。实际体验：这类场景属于技能明确标注的“可选但有价值”，往往能指出被忽略的假设；注意事项是要接受审查者可能判断有误，此时应附技术理由提出异议，而不是照单全收或直接无视。
6. 该技能能为用户带来的价值
把质量关卡前移，压缩返工成本。 缺陷越晚发现越贵，这是工程常识。该技能把审查放到“每个任务之后”这个最便宜的位置，让问题在级联之前被捕获，而不是在合并或联调时集中暴露。
让 AI 协作开发变得可审计。 通过 BASE_SHA/HEAD_SHA 锁定区间、通过 {PLAN_OR_REQUIREMENTS} 锁定标准，每一次审查都有明确的输入与可复现的范围。这对需要向他人（或未来的自己）解释“这段代码为什么这么写”的场景价值很大。
降低流程执行门槛。 很多团队都知道要频繁审查，但真正难的是“什么时候审、怎么发起、反馈怎么处置”。技能把这三件事写成了固定动作和分级规则，新人依照执行即可，不需要靠经验判断。
减少无效沟通。 反馈分级机制明确了“什么必须现在改、什么可以稍后改”，避免了一次审查拖住整个开发节奏；异议机制则避免了盲目接受错误建议带来的反向损耗。
长期价值在于习惯养成。 “早期审查，频繁审查”加上红旗警告清单，本质上是在训练一种开发纪律：不因为“它很简单”就跳过关卡。这种纪律带来的收益会随着项目规模累积放大。
7. 常见问题 FAQ
Q1：这个技能怎么安装？安装后怎么确认它真的生效了？
在支持 AI 技能机制与子代理调度的环境中，通过技能市场或技能目录添加 requesting-code-review（技能 ID 13650），并确认 requesting-code-review/code-reviewer.md 模板就位。具体安装命令与入口以官方说明为准。验证方式：完成一次小改动后说“请求代码审查”，若它引导你获取 SHA 并以 superpowers:code-reviewer 子代理返回“优点/问题/评估”结构反馈，即说明生效。
Q2：它收费吗？ 技能详情中未涉及定价信息，是否收费取决于你使用的技能分发平台与订阅方案，请以官方说明为准。
Q3：它和 ESLint、SonarQube 这类静态分析工具冲突吗？ 不冲突，二者互补。静态分析工具靠规则匹配，擅长风格统一与常见缺陷模式；请求代码审查靠“计划与实现的对照”，擅长发现功能完整性缺口和结构性问题。它是流程层的关卡，规则引擎是执行层的检查，建议同时使用。
Q4：审查者（子代理）判断错了怎么办？ 技能明确给出了处置方式：用技术理由提出异议、展示证明其可行的代码或测试、请求澄清。不建议的两种极端是——不加判断地全部修改，以及直接忽略反馈。
Q5：什么情况下应该跳过审查？ 按技能的红旗警告，“它很简单”不是跳过审查的正当理由。真正需要调整的是审查的范围与频次：改动很小时可以缩小 SHA 区间，而不是取消关卡。相反，“卡住时”“重构前”“复杂错误修复后”这些场景属于可选审查，按需调用即可。