代码审查 Skill：代码改完了，要确认行为和风险真的没变
代码审查最没有价值的状态，是评论很多却没有指出行为风险。好的审查要把实现细节放回用户路径、边界条件和可维护性里判断。
代码审查 Skill 优先呈现有证据的发现，区分缺陷与偏好，并给作者清晰的验证路径。
本文将用明确的输入、边界和输出组织实践过程，帮助你把结论交给下一个需要据此行动的人。
Awesome QA Skills 按语言和测试阶段组织 Skill。项目结构与通用安装方式已经在系列总览说明，这里只讲 代码审查。
先看源 Skill
主 Prompt 把工作拆到 代码审查阻塞、质量要求、执行流程、核心约束、按需加载。这些标题只是导航，真正使用时还要回到项目材料。
源目录现有 2 份示例、1 份参考、17 个脚本入口。可以先看 代码审查 示例与使用说明、代码评审维度说明、模板批量转换脚本。
评审结果要能定位
评审一份修改退款状态机的 PR，找出行为回归、并发风险和缺失测试
“内容不够好”没法行动。下面这种写法更有用。
| 严重度 | 位置 | 发现 | 修复建议 |
|---|---|---|---|
| P0 | 权限与数据写入 | 改动可能扩大访问或写入范围 | 用授权矩阵和反向用例复核 |
| P1 | 异常路径 | 新分支吞掉错误或改变重试语义 | 补失败断言，并说明用户影响 |
每条发现都要指向具体位置。没有位置、影响和修法的意见，先别塞进评审报告。
看一处修改前后
以 评审一份修改退款状态机的 PR，找出行为回归、并发风险和缺失测试 为例，评审前的写法常常只有一句宽泛要求。
修改前：检查输出质量，确保结果准确完整。
修改后：每条结论必须包含 source、status 和 owner。
找不到来源时标记 assumption；没有运行记录时 status 不得写 passed。第二版能测，也能在失败时指出具体字段。围绕 代码审查阻塞、质量要求 做评审时，我会再查三件事。触发条件有没有误伤相邻任务，输入缺失时是否降级，示例是否偷偷承诺了工具没有执行的事情。
修完以后怎么复核
| 复核对象 | 方法 | 通过信号 |
|---|---|---|
| 行为 | 对主路径和失败路径做 diff 对照 | 结果、状态码和副作用符合预期 |
| 边界 | 用权限、空值、超时和重复请求试跑 | 未授权和异常输入被明确处理 |
| 测试 | 追踪新增或变更的断言 | 测试能证明风险，不只是提高覆盖率 |
| 回滚 | 检查配置、迁移和开关 | 出问题时有可执行的恢复步骤 |
一段可以直接改的调用词
把下面的方括号换成项目内容。材料越具体，Skill 越少猜。
请使用 code-review Skill。
任务：评审一份修改退款状态机的 PR，找出行为回归、并发风险和缺失测试
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]
逐条给出位置、严重度、影响和修改建议。区分契约缺失、事实错误和个人偏好，修改后附复核方法。
最后列出待确认问题，不要补写材料里没有的事实。第一次调用先看结构和缺口。补齐材料后再生成正式产物，能省掉不少来回修改。
进阶使用，从一次调用走到持续流程
把典型问题变成回归样例。每次修改 代码审查 后，同时跑应通过、应拒绝和缺失输入三组检查，评审结论才不会只停在文字层。
三段式 Skill 链
test-case-writing → code-review → test-reporting
| 交接 | 传递内容 | 接收方检查 |
|---|---|---|
| 上游到 code-review | 来源版本、范围、风险和未决问题 | 代码审查 输入是否过期，冲突是否标记 |
| code-review 到下游 | 主产物、证据索引、未完成项 | 代码审查 产物能否继续执行，Owner 是否明确 |
| 下游回写 code-review | 运行结果、缺陷和新风险 | 是否更新 代码审查 基线与回归范围 |
不要把三次输出复制进一个大 Prompt。代码审查 只接收结构化摘要和可访问的原始材料，能减少上下文浪费，也方便追错。
放进团队流程的门禁
| 门禁 | 建议检查 | 失败动作 |
|---|---|---|
| code-review 输入门禁 | 版本、环境、Owner、来源可访问 | 停止 代码审查 并列出缺口 |
| code-review 产物门禁 | 关键结论带依据和状态 | 退回 代码审查 补证据 |
| code-review 执行门禁 | 命令、退出码、报告可复现 | 标记基础设施或测试问题 |
| code-review 决策门禁 | 残余风险有接受人和日期 | 不进入下一阶段 |
团队可以每个 Sprint 看一次 代码审查 的采用率、人工修改率、无依据结论数和失败定位时间。数字的目标由团队自己定，先连续记录几轮再谈阈值。
评审时保留原文和证据
先引用位置，再写问题。区分契约缺失、表达问题和个人偏好。代码审查阻塞 相关的问题应说明会导致什么行为漂移。修完以后重新检查，不要只把措辞改得更顺。
相关 Skill
代码审查需要同时看实现、可测试性和运行风险：
- 技术质量视角：把代码特征连到稳定性和运行后果。
- 测试性分析：识别难以验证、隔离或观测的设计。
- Skill 变更验证：当审查对象是 Skill 时，复核原有约束和示例。
交付前复核：把判断落到证据
Skill 输出拿到手后，先核对四件事：输入版本是否明确，范围是否完整，每条结论能否回到证据，下一步由谁执行。少一项，报告就容易变成漂亮的猜测。
| 项目 | 需要留下 | 缺失时 |
|---|---|---|
| 输入边界 | 版本、环境、时间窗口和本次范围 | 标记假设，不写成事实 |
| 证据索引 | 日志、报告、Trace、截图或命令输出 | 标记 evidence_pending |
| 结论状态 | verified、assumption、blocked 或 pending | 停止扩大结论 |
| 后续动作 | 最小验证命令、负责人和截止时间 | 交付为待办，不进入门禁 |
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，下一次复核才知道结论从哪里变化。
安装与调用
安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review -g调用时直接写“请使用 code-review Skill”，然后附上真实材料。
常见问题
评审发现一定要全部修改吗？
不需要。先看严重度和契约影响。纯偏好问题可以不改，但要记录选择。
文案变短就代表更好吗？
不代表。触发条件、输入、输出和风险边界不能被一起删掉。
什么时候需要人工复核？
涉及范围取舍、风险接受、发布决定或材料冲突时必须由负责人确认。
输出怎么留档？
保存输入版本、Skill 输出、人工修改和最终证据。只留最后一份文档，很难解释结论怎么来的。
先拿一份真实材料跑 代码审查，保留输入、输出和复核意见。文章里的片段只能帮你搭起结构，项目证据还得在项目里产生。
参考
- Awesome QA Skills 项目主页：https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills 系列总览：https://inaodeng.com/zh-cn/blog/ai-testing/introduction_of_awesome_qa_skills/
- 代码审查 示例与使用说明：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review/examples/README.md
- 代码审查 补充参考资料：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review/references/review-dimensions.md
- 代码审查 辅助脚本：batch_convert_templates.py:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review/scripts/batch_convert_templates.py
- Awesome QA Skills：代码审查 Skill 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review
- 代码审查 Skill 详情页：https://inaodeng.com/zh-cn/qaskills/code-review/