如果你平时就在用 Claude Code 这类 AI 编程工具，大概率遇到过这样的情况：让 AI“帮我 review 一下代码”，它象征性扫了两眼，丢一句“整体还不错，注意几个小问题”就交差了。轻量场景倒无所谓，但稍微复杂一点的改动，这种敷衍式审查基本帮不上忙。我一开始也是这么将就的，直到把 superpowers 项目里的 requesting-code-review 这个基本 Skill 用上，才发现原来 AI 代码审查可以做得这么结构化、这么有章法。这篇就把这个 Skill 的机制、用法和我在实际项目里踩过的坑一次说清楚。
先说它适合谁：如果你正在用 Claude Code、Codex、opencode 这类工具写代码，并且团队对代码质量有要求，或者你一个人维护多个项目、需要 AI 分担一部分 review 压力，那这个 Skill 基本属于必装。它解决的问题很直接：把“帮我看看代码”这种模糊指令，变成一套可重复、可预期、有明确产出物的审查流程。下面我会从设计思路、工作原理、实操步骤到问题排查，完整过一遍。
1. requesting-code-review 技能到底是什么
1.1 先认识 superpowers 这套 Skill 体系
在深入这个技能之前，有必要先交代一下 superpowers 项目本身。它是一套面向 AI 编程助手设计的 Skill 集合，作者是 GhostInTheWire，核心思路是给 AI 预置一套“专家级工作方法”，而不是让 AI 每次都靠通用推理临时发挥。你可以把它理解为一份“技能插件包”，里面有写代码的规范、拆任务的流程、做重构的检查清单，而 requesting-code-review 只是其中一个基础能力。
安装之后，superpowers 会在你的项目里生成一套.claude/skills目录，每个子目录就是一个 Skill，目录里有一个SKILL.md文件，里面用结构化的方式描述这个技能的名称、触发条件、执行步骤和输出要求。AI 读了这个文件，就等于拿到了一份“操作手册”，知道用户在请求代码审查时该按什么路径走，而不是自由发挥。
我最初接触时也怀疑过：这不就是把提示词拆成文件吗？但用了一段时间之后发现，区别非常大。通用提示词是一次性的，AI 上下文一滚动就可能漏掉关键约束；而 Skill 是持久化的，每次触发都会完整加载，审查标准始终一致。这种“把方法论固化下来”的思路，才是 superpowers 真正值钱的地方。
1.2 这个 Skill 到底解决了什么问题
不装这个 Skill 的时候，我让 AI 审查代码，最常遇到的几个问题：
第一，审查深度不稳定。状态好的时候 AI 能指出几个边界条件，状态不好的时候只会夸代码写得漂亮。第二，审查范围不明确。我只想让它看某个函数的异常处理，它结果把整个文件都点评了一遍。第三，审查结果不好沉淀。AI 说了一堆零散意见，但没人整理哪些必须改、哪些可以忽略，review 完跟没 review 差不多。
requesting-code-review 这个 Skill 解决的就是这些问题。它会引导 AI 按固定流程走：先理解本次改动的目标和上下文，再逐模块分析代码逻辑、边界条件、潜在缺陷，最后输出一份结构化的审查报告，包含问题列表、严重等级、修改建议。整个过程是可预期的，每次审查的产出格式都差不多，团队协作时更容易对齐。
我在一个中型项目里实测下来，最直观的感受是：AI 的审查视角从“像在读代码”变成了“像在维护代码”。它不再只盯着语法和表面问题，会主动去思考这个改动会不会影响其他调用方、错误处理是否完整、测试覆盖有没有缺口。这些恰恰是代码审查最该关注的东西。
1.3 和普通“帮我 review 一下”有什么本质区别
说句实话，不借助 Skill 的情况下，Claude Code 本身也能做代码审查，毕竟模型能力摆在那里。但关键是稳定性和完整性。普通指令下，AI 容易陷入“你说什么我就答什么”的被动模式——你让它看错误处理，它真就只看错误处理，别的漏洞全当没看见。
而有了 Skill 之后，AI 会主动按照一套完整的审查框架来执行。我看了这个 Skill 的 SKILL.md 文件，里面把审查步骤拆得非常细，每一步都有明确要求。比如说，它不会在拿到代码的瞬间就急着下结论，而是先要求自己整理一份“改动目标摘要”，再对照代码逐一验证；遇到不清楚的代码路径，它会明确标注“需要人工确认”，而不是猜一个结论给你。
这背后其实是对 AI 行为模式的一种约束。模型的默认行为是“尽快给出看似合理的回答”，而 Skill 的作用恰恰是把这种冲动按下来，强制它走完整的分析链路。所以同样的代码、同样的模型，带不带 Skill 跑出来的审查质量，差距非常大。这一点我在后面讲执行流程的时候会展开。
2. Skill 的工作原理与执行流程
2.1 一次审查请求是如何被拆解执行的
要理解这个 Skill 的价值，最好直接看它的执行链路。当你发起一个代码审查请求时，Skill 会引导 AI 按以下步骤走完整个流程。
第一步是收集上下文。AI 会先明确这次要审查的代码范围，是全量文件还是某个变更集中的改动；同时它会读取相关文件的内容，确保自己不是凭空猜。比如你刚改完一个支付回调函数，Skill 会要求 AI 先搞清楚这个函数被哪些地方调用、依赖哪些外部接口，再开始找问题。
第二步是整理理解摘要。AI 不会直接跳到“找 bug”环节，而是要先用一两段话描述它理解的这次改动的目标、关键逻辑和潜在风险点。这一步很有价值，因为它强制 AI 输出推理过程，方便你判断它是否真的看懂了代码。如果摘要里出现事实性错误，那说明 AI 的理解有偏差，后续的审查结论也要打个问号。
第三步是逐模块分析。按照 Skill 里预设的审查维度，AI 会从代码逻辑正确性、边界条件覆盖、错误处理完整性、性能隐患、安全风险、可维护性等角度，逐个模块过一遍。每个模块的问题都会被单独记录，不会混在一起。这一步是整个流程中最耗时的部分，也是产出质量的核心来源。
第四步是生成审查报告。AI 会把发现的问题整理成清单，附上严重等级、问题描述、复现路径和修改建议。报告的结构是固定的，通常包含“问题列表”“修改建议”“整体评价”三个部分，方便你直接贴到 PR 评论区或者发给同事。整个过程走下来，AI 的角色从一个“应答者”变成了“质检员”。
2.2 Skill 文件里到底写了什么
对于想深入理解这个 Skill 原理的人来说，直接去读它的SKILL.md文件是最直观的。文件本身不复杂，但设计得非常讲究。
文件头部有 YAML frontmatter，定义了技能的名称和描述信息，这些信息决定了 AI 什么时候会主动加载这个技能。往下就是正文，也就是具体的执行指令。有意思的是，正文并没有写一堆泛泛的“你应该认真审查”这类废话，而是用非常具体的执行条目来约束 AI 的行为。比如它会明确要求 AI 在动手之前先整理上下文，“在提出任何修改建议之前，先确认自己理解了代码的意图”这种话术，实际上就是在对抗模型那种“急于给结论”的倾向。
另外，文件里还内置了一条“输出控制”逻辑：在没有足够上下文的时候，AI 应该主动提问，而不是硬着头皮给建议。这个设计很关键。我在使用中经常遇到一种场景，就是让 AI 审查一段依赖大量外部配置的代码，如果它不先问清楚这些配置的来源，给出的建议基本都是隔靴搔痒。Skill 把这个“主动提问”的步骤前置了，审查质量自然就上去了。
2.3 为什么把流程固化下来比实时发挥更可靠
这里有个值得展开的原理性问题：为什么一套固定的流程，会比模型实时发挥更可靠？
我的理解是，AI 模型本质上是一个“概率预测器”，它在生成每个 token 时都会从概率分布中采样。这带来了一个天然问题：同一个请求，两次运行可能得到完全不同的结果。第一次审查发现了三个问题，第二次可能只发现一个，甚至结论方向都不一样。这种不确定性在代码审查这种强逻辑场景里是很伤的，因为开发者无法判断这次审查到底靠不靠谱。
Skill 的介入，本质上是给模型套上了一层“思维约束”。它通过预置的执行步骤，把不确定性压缩到一个可控范围内。虽然模型在细节上仍然会有随机性，但整体的分析路径是稳定的，每一次都会覆盖同样的审查维度，输出同样的报告结构。这种稳定性的价值在团队协作中尤其明显，毕竟 CI 里的自动化检查不会管你今天心情好不好，代码审查工具也不应该。
3. 实际使用指南与实操步骤
3.1 安装 superpowers 的前提条件
聊完了原理，进入实操部分。想把requesting-code-review用起来，第一步是安装 superpowers 技能集。这里有一个前提条件要提醒大家：这个 Skill 是给 Claude Code 这类支持 Skill 机制的 AI 编程工具设计的，你用的工具得支持加载自定义 Skill。如果你用的是其他工具，先确认一下有没有类似的机制，否则装了也白装。
安装方式其实很直接。我是直接从 GitHub 上拉取 superpowers 项目到本地，然后把项目里的.claude/skills目录复制到自己工作目录下。如果你用的是 Claude Code，它会自动识别这个目录下的所有 Skill，不用额外配置。网上有些教程说还要改配置文件，我实测下来是不需要的，只要目录结构对就行。
装完之后，你可以先验证一下。在 Claude Code 里输入/命令，看看能不能看到新增的 Skill 列表。如果能看到，说明加载成功了。需要注意的是，安装之后最好重启一下 Claude Code，有些版本对 Skill 的加载是会话启动时才扫描的，不重启的话可能读不到新装的技能。
3.2 如何正确发起一次代码审查请求
装好之后，最核心的问题就是：怎么用？这里我直接给你一套我验证过非常有效的请求模板，你可以直接复制使用：
请使用 requesting-code-review 技能审查我最近的改动。 改动范围：src/modules/payment/ 目录下的所有文件，以及 src/utils/refund.ts。 审查重点： 1. 支付回调的幂等性处理是否合理 2. 退款流程中异常分支是否覆盖完整 3. 并发场景下是否存在数据竞争风险 请按技能定义的标准流程执行，最后输出结构化审查报告。这个模板有几个关键设计：
第一，明确指定了审查范围。如果没有这个，AI 很可能把整个项目都扫一遍，既浪费时间又稀释了重点。第二，列出了具体的审查侧重点。这相当于给 AI 划定了优先级，让它把注意力集中在高风险区域。第三，要求按标准流程执行。这句话很关键，等于强制触发 Skill 的完整执行链路，而不是让 AI 只做表面功夫。
我实际用下来的感受是，越是明确的请求，审查结果越有价值。如果你只丢一句“帮我看看代码”，Skill 虽然也会执行，但 AI 很难判断你的真实关注点，产出的报告会比较泛。所以这里建议你养成“带边界和重点发起审查”的习惯，收益会大很多。
3.3 审查报告到底该怎么读
Skill 输出的审查报告是有固定格式的，这一点做得非常实用。报告通常包含几个部分：问题列表、修改建议和整体评价。其中问题列表是最核心的，每一条问题都会标出严重等级，大致分三类：
- 高严重度：可能导致线上事故的问题，比如空指针、并发冲突、数据不一致。这类问题必须先处理。
- 中严重度：在特定场景下才会触发的问题，比如某个边界条件没覆盖、错误信息不够明确。这类问题建议在本轮迭代中解决。
- 低严重度：不影响功能但影响维护性的问题，比如命名不规范、重复代码、注释过时。这类问题可以排期处理，但不要忽略。
我习惯拿到报告之后，先扫一遍高严重度问题，确认是不是真实存在的；如果 AI 误报了，点开代码核对一下，然后把结论记录到 PR 评论里。之后再看中低严重度的问题，挑选一些有价值的部分合并处理。
要注意的是，AI 的审查报告不是“圣旨”。虽然 Skill 已经把流程做得很完整，但它终究受限于上下文窗口和模型能力，偶尔会给出不准确的建议。我的处理原则很简单：把 AI 报告当作“第一轮人工检查”的辅助输入，而不是最终结论。它帮你找到了 80% 的问题，剩下的 20% 需要你自己结合业务上下文去判断。
3.4 如何调整审查的严格程度
不同项目对代码审查的严格程度要求不一样。个人项目可以宽松一些，核心逻辑没问题就行；核心支付系统那必须严苛到每一行都过一遍。好消息是，这个 Skill 可以灵活调整审查强度，方法就是——在请求里加一句指示。
如果你想快速过一遍主要问题，可以加：本次审查请重点关注逻辑正确性和数据一致性，其他维度从简。得到的结果会更聚焦，效率更高。
如果你想做完整深度的审查，可以加：请按 Skill 定义的所有维度逐项审查，不要遗漏，并在报告中列出每个维度的检查结果。这样 AI 会覆盖所有审查维度，报告的篇幅也会更长，适合在合并大型 PR 之前使用。
这个灵活性是我觉得 Skill 设计得比较聪明的地方。它没有把流程写死成“必须怎样”，而是把控制权交给使用者，你要严格它就严格，你要快速它就快速。通过自然语言去调节控制粒度，比去改配置文件方便多了。
4. 常见问题与排查技巧实录
4.1 典型问题速查表
在实际使用中，我遇到过不少问题，也帮朋友排查过一些。挑几个出现频率最高的整理成表格，你可以直接对照排查。
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 发起审查后 AI 没有按 Skill 流程执行 | Skill 没有正确加载，或工具版本不支持 | 检查.claude/skills目录结构，重启会话后重试 |
| 审查报告很简短，像没加载 Skill | 请求里的触发词不够明确，AI 没识别出意图 | 在请求中明确写出“使用 requesting-code-review 技能” |
| AI 大量误报，报告可信度低 | 上下文窗口里相关代码信息不足 | 先让 AI 读取相关文件，再发起审查请求 |
| 审查范围跑偏，AI 评论了无关文件 | 没有明确指定审查范围 | 在请求中列出具体文件路径或目录 |
| 报告格式混乱，没有结构化输出 | Skill 版本过旧，或和其他 Skill 冲突 | 更新 superpowers 到最新版本，检查冲突情况 |
| AI 提出修改建议时直接改代码 | 缺少“只审查不修改”的约束 | 请求中注明“仅输出审查报告，不要修改任何文件” |
4.2 我踩过的几个坑
第一个坑：上来就审查，不先让 AI 读文件。有一次我直接让 AI 审查一个刚写完的模块，结果它报告里写“这个函数缺少参数校验”，但实际上参数校验写在另一个工具函数里。原因就是 AI 根本没读到那个文件，信息不全就急着下结论。现在我都会先让 AI 把相关文件列出来，或者直接用@文件路径的方式把核心文件引入上下文，确保它是在“有信息”的前提下审查。
第二个坑：一个会话里同时发起多个审查请求，导致上下文被大量消耗。Claude Code 的上下文窗口是有限的，如果你让 AI 连续审查三四个模块，后面审查的可用上下文就会越来越少，质量明显下滑。我的做法是一次只审查一个模块，或者审查完一个之后主动清理上下文，开新会话继续下一个。
第三个坑：和其他 Skill 一起用时产生行为冲突。我遇到过requesting-code-review和一个代码生成 Skill 同时被加载，结果 AI 在审查过程中开始“顺手”重构代码，搞得我一脸懵。后查明白是 Skill 之间的边界没有被约束清楚。解决办法是在请求中明确写一句“本次只做审查，不要执行其他技能”，把边界划定清楚。
4.3 把代码审查玩得更深：让 Skill 适配你的团队标准
requesting-code-review作为基础 Skill，默认的审查维度已经覆盖了大部分通用场景。但如果你想让 AI 的审查标准更贴合团队规范，其实可以手动调整。
操作逻辑不复杂。superpowers 的 Skill 文件本身就是文本，你对它做二次编辑即可。比如你们团队特别强调错误处理必须显式记录日志，那你可以在SKILL.md的审查维度里增加一条：“在错误处理环节，检查是否包含明确的日志输出”。这样 AI 在后续的审查中就会额外关注这个维度。这个操作对不熟悉代码的人也很友好，本质上只是在文档里加一段话，不需要改逻辑。
我建议改完之后跑一两个测试样本，看看 AI 的输出是否真的符合预期。如果效果不好，可以再微调措辞。Skill 的优势就在这里，它是你的方法论沉淀，可以根据你的需要不断演化。用上一个月之后，它就不再是别人的通用技能了，而是你团队自己的代码审查手册。
4.4 一个提升审查效率的组合技巧
最后分享一个我个人用下来效率很高的组合打法：把requesting-code-review和 Git 的 diff 结合起来用。
不要直接让 AI 审查整个文件，而是先获取本次改动的 diff 内容，然后把 diff 附加到请求里，让 AI 只针对变更行进行审查。这样做有两个好处：第一，上下文消耗大幅降低，AI 不需要读取完整文件；第二，审查聚焦在“改动引入的风险”上，而不是把历史代码重新审一遍。
实际执行大概是这样的：
- 在终端运行
git diff，把输出复制出来。 - 在 Claude Code 里发起审查请求，把 diff 内容粘贴进去，并注明“这是本次改动的 diff，请基于此内容进行审查”。
- 按之前提到的请求模板，加上审查范围和重点。
这样组合下来，我单次审查的时间从原来的七八分钟缩短到两分钟左右，问题检出率反而更高了。原理也简单，diff 天然的“缩小范围”能力，和 Skill 的“深度分析”能力结合在一起，正好互补。如果你现在还在用整文件审查的方式，强烈建议试试这个组合。
5. 写在最后的个人体会
用requesting-code-review到现在也有几个月了，最大的感受是：AI 代码审查的价值，不在于它能完全替代人工 review，而在于它把“查漏补缺”的兜底工作自动化了。以前我提交 PR 之前，要靠自己反复检查代码，总会漏掉一些细节；现在有了这个 Skill 的固定流程，等于每次都有一双相对客观的眼睛帮你先把一遍关，剩下要处理的就是高价值的判断和决策了。
最后再分享一个小技巧：别每次都把审查报告读完，重点看高严重度问题，中低严重度的可以攒起来，每周集中处理一次。这样既保证了代码质量的底线，又不会让审查流程拖慢开发节奏。代码审查这件事，本来就是重质不重量的活，工具再好，最终靠的还是你对质量的坚持。
