⚡

代码审查Skill ReviewingCode

代码审查技能用于系统地评估代码变更，确保安全性、正确性、性能和规范对齐。它涉及审查拉取请求（PR）、评估代码质量，并验证实现是否符合需求，以提升软件开发和维护效率。关键词：代码审查、代码质量、安全性评估、性能优化、规范对齐、PR审查、软件开发、质量控制、代码评审。

测试 0 次安装 0 次浏览 更新于 3/8/2026

name: 代码审查 description: 系统地评估代码变更的安全性、正确性、性能和规范对齐。用于审查PR、评估代码质量或验证实现是否符合需求。

代码审查

评估代码变更的安全性、正确性、规范对齐、性能和可维护性。根据范围应用顺序或并行审查。

快速开始

顺序（小型PR，<5个文件）：

  1. 从功能规格和验收标准收集上下文
  2. 按关注领域顺序审查
  3. 按优先级报告发现
  4. 推荐批准/修订/重做

并行（大型PR，>5个文件）：

  1. 确定独立的审查方面（安全、API、UI、数据）
  2. 为每个维度生成专家代理
  3. 整合发现
  4. 报告总体评估

上下文收集

阅读文档：

  • docs/feature-spec/F-##-*.md — 技术设计和需求
  • docs/user-stories/US-###-*.md — 验收标准
  • docs/api-contracts.yaml — 预期的API签名
  • docs/data-plan.md — 事件跟踪需求（如适用）
  • docs/design-spec.md — UI/UX需求（如适用）
  • docs/system-design.md — 架构模式（如可用）
  • docs/plans/<slug>/plan.md — 原始实施计划（如可用）

确定范围：

  • 更改的文件和受影响的功能（F-## IDs）
  • 实现的故事（US-### IDs）
  • API、数据库或架构更改

质量维度

安全性（/25）

  • 输入验证和清理
  • 认证/授权检查
  • 敏感数据处理
  • 注入漏洞（SQL、XSS等）

正确性（/25）

  • 逻辑匹配验收标准
  • 边缘情况正确处理
  • 错误处理完整
  • 空值/未定义检查存在

规范对齐（/20）

  • API匹配 docs/api-contracts.yaml
  • 数据事件匹配 docs/data-plan.md
  • UI匹配 docs/design-spec.md
  • 实现遵循功能规格

性能（/15）

  • 算法效率
  • 数据库查询优化
  • 资源使用（内存、网络）

可维护性（/15）

  • 代码清晰度和可读性
  • 与代码库模式一致
  • 适当的抽象级别
  • 需要时的注释

总计：/100

发现优先级

🔴 严重（必须修复后才能合并）

  • 安全漏洞
  • 功能损坏
  • 规范违反（API合同中断）
  • 数据损坏风险

格式：

位置：file.ts:123
问题：[描述]
影响：[风险/后果]
修复：[需要的具体更改]
规范参考：[docs/api-contracts.yaml 行 X]

🟡 重要（应该修复）

  • 边缘情况中的逻辑错误
  • 缺少错误处理
  • 性能问题
  • 缺少分析事件
  • 可访问性违反

🟢 可选的（可选）

  • 代码风格改进
  • 更好的抽象
  • 增强文档

✅ 良好实践

突出做得好之处以学习

审查策略

单代理审查

最适合<5个文件，单一关注点：

  1. 按关注领域顺序审查
  2. 集中在1-2个受影响最大的区域
  3. 生成统一报告

并行多代理审查

最适合>5个文件，多个关注点：

  1. 生成专门代理：

    • 安全性： senior-engineer 用于漏洞评估
    • 架构： Explore 用于模式合规性
    • API合同： programmer 用于端点验证
    • 前端： programmer 用于UI/UX和可访问性
    • 文档： documentor 用于注释质量和文档

  2. 每个代理审查特定质量维度

  3. 将发现整合到单一报告中

报告结构

# 代码审查：[功能/PR]

## 摘要
**质量分数：[X/100]**
**问题：** 严重：[N]，重要：[N]，可选：[N]
**评估：** [批准 / 需要修订 / 重大重做]

## 规范合规性
- [ ] API匹配 `docs/api-contracts.yaml`
- [ ] 事件匹配 `docs/data-plan.md`
- [ ] UI匹配 `docs/design-spec.md`
- [ ] 逻辑满足故事AC

## 发现

### 严重问题
[有修复建议的问题]

### 重要问题
[应该解决的问题]

### 可选建议
[可选改进]

### 良好实践
[做得好之处]

## 建议
[下一步：批准、需要修订等]

修复实施

提供选项：

  1. 修复严重 + 重要问题
  2. 仅修复严重问题（安全性最低要求）
  3. 提供详细解释以学习
  4. 仅审查（无更改）

并行修复大型修订：

  • 为独立修复区域生成代理
  • 协调共享依赖
  • 记录每个修复，包括位置、更改和验证方法

文档格式：

✅ 已修复：[问题名称]
文件：[路径:行号]
更改：[更改内容]
验证：[如何测试]

文档更新

检查是否需要更新规格：

  • 功能规格“决策”或“偏差”，如果实现不同
  • 设计规格，如果UI更改
  • API合同，如果端点修改（需要批准）
  • 数据计划，如果事件更改

在修改规格前总是标记给用户批准。

关键点

  • 在开始前阅读所有上下文文档
  • 首先关注受影响最大的区域
  • 对安全敏感代码、API更改和关键用户流程进行彻底审查
  • 使用评分框架进行全面审查
  • 并行审查扩展到大PR
  • 标记规范偏差以供用户决策