autorenew

类型 Evals 同步日期: 2026-08-10

代码审查

作者: naodeng

何时使用

  • 需要审查 PR / Diff / 提交,拦截合入前的逻辑、安全、资损与可维护性风险。
  • 需要按 P0/P1/P2 分级、带定位与可落地修复建议的审查报告。
  • 需要从 QA / 工程质量视角补充开发自审未覆盖的风险点。

执行流程

  1. 阅读并遵循「按需加载」中的主提示词(覆盖清单、输出结构、质量要求)。
  2. 只补充真正影响结果的项目上下文:变更范围、业务目标、技术栈、上下游依赖、已知风险、团队规范。
  3. 信息不全时先给可用初版,并显式标出假设与信息缺口。
  4. 默认 Markdown;用户指定其他格式时再切换。

核心约束

  • 风险驱动:优先线上故障、资损、安全与核心可维护性;不做命名/缩进类噪声清单。
  • 证据导向:每条发现尽量给出文件路径、行号或代码片段,并说明触发路径与后果。
  • 严格分级:P0 阻塞合入、P1 建议本迭代修复、P2 可纳入技术债。
  • 把「已确认事实」和「当前假设」分开写;不要编造用户未提供的接口、字段、环境或根因。
  • 对事不对人;尊重现有技术栈,未经授权不要求换框架/推翻架构。
  • 结果必须可执行:每条问题有修复方向或修改前后示例。

按需加载

  • 产出前必须阅读并遵循 prompts/code-review.md(最低覆盖清单、输出结构、质量要求)。
  • 需要 Excel/CSV/JSON/Word 等格式时:读 output-formats.md,并按用户格式要求输出。
  • 需要套用现成模板时:读 output-templates/ 中匹配的模板,不要自创冲突结构。
  • 需要审查维度细化或分级细则时:读 references/review-dimensions.md
  • 用户要示例或对标现有资产时:读 examples/ 中相关样例。
  • 需要格式转换或辅助校验时:优先使用 scripts/ 中已有脚本,而不是重写一遍。
  • 用户只要最短上手路径时:读 quick-start.md
  • 需要评测/回归本 skill 时:使用 evals/,并用 skill-up 校验与运行。

交付前自检

  • 已遵循主提示词的输出结构
  • 最低覆盖关注:变更摘要、综合风险评级、P0/P1/P2 清单、可测性与可观测性、API/契约兼容、修复优先级、剩余风险与假设…(细节以主提示词为准)
  • 已覆盖最低清单,或标明为何省略
  • 高风险项有明确 P0/P1 分级与依据
  • 未编造用户未提供的细节
  • 假设与信息缺口已标明

常见误区

  • 范围和 Diff 都不清楚时,不要假装已经完整可用。
  • 不要把所有项写成同等重要,或堆砌风格类低价值意见。
  • 不要跳过假设与信息缺口。
  • 不要对未在本次变更范围内的存量逻辑强制重构。
  • 不要输出大段与当前变更无关的空泛理论。

安装与调用

平台

AI 工具

快速安装(一行命令)

完整脚本

调用示例

@skill code-review
结合当前项目上下文,按该技能的要求给出可执行结果。
分享