Reviewing Code 是一个用于系统化评估代码变更的审查技能，评估维度包括安全、正确性、规范对齐、性能与可维护性。它根据变更规模选择顺序审查或并行审查方式。
用途
该技能适用于审查 Pull Request、评估代码质量，或验证实现是否符合规格说明。
快速开始
顺序审查（小型 PR，少于 5 个文件）：
- 从功能规格和验收标准中收集上下文
- 按关注领域依次审查
- 按优先级报告发现的问题
- 给出批准 / 修订 / 返工的推荐意见
并行审查（大型 PR，超过 5 个文件）：
- 识别相互独立的审查方面（安全、API、UI、数据）
- 为每个维度分配专门智能体
- 汇总发现的问题
- 报告整体评估结果
上下文收集
需要阅读的文档：
- 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-## ID）
- 已实现的故事（US-### ID）
- API、数据库或模式变更
质量维度（总分 100）
安全（/25）：输入验证与净化、认证/授权检查、敏感数据处理、注入漏洞（SQL、XSS 等）。
正确性（/25）：逻辑是否符合验收标准、边界情况处理、错误处理完整性、空值/未定义检查。
规范对齐（/20）：API 是否符合 docs/api-contracts.yaml、数据事件是否符合 docs/data-plan.md、UI 是否符合 docs/design-spec.md、实现是否遵循功能规格。
性能（/15）：算法效率、数据库查询优化、资源占用（内存、网络）。
可维护性（/15）：代码清晰度与可读性、与代码库模式的一致性、抽象层级是否恰当、必要处的注释。
发现问题的优先级
🔴 严重（合并前必须修复）：安全漏洞、功能损坏、规范违规（API 契约破坏）、数据损坏风险。 格式： Location: file.ts:123 Problem: [描述] Impact: [风险/后果] Fix: [所需的具体修改] Spec reference: [docs/api-contracts.yaml 第 X 行]
🟡 重要（应当修复）：边界情况中的逻辑缺陷、缺失的错误处理、性能问题、缺失的分析事件、无障碍违规。
🟢 可选（可做可不做）：代码风格改进、更好的抽象、增强文档。
✅ 良好实践：指出做得好的地方以供学习。
审查策略
单智能体审查：最适合少于 5 个文件、单一关注点。按关注领域依次审查，聚焦 1-2 个影响最大的领域，生成统一报告。
并行多智能体审查：最适合超过 5 个文件、多个关注点。分配专门智能体：安全由 senior-engineer 评估漏洞、架构由 Explore 检查模式合规、API 契约由 programmer 验证端点、前端由 programmer 检查 UI/UX 与无障碍、文档由 documentor 检查注释质量与文档。每个智能体审查特定质量维度，最后将发现汇总为单一报告。
报告结构
Code Review: [Feature/PR]
Summary
Quality Score: [X/100] Issues: Critical: [N], Important: [N], Nice-to-have: [N] Assessment: [APPROVE / NEEDS REVISION / MAJOR REWORK]
Spec Compliance
- [ ] APIs match
docs/api-contracts.yaml - [ ] Events match
docs/data-plan.md - [ ] UI matches
docs/design-spec.md - [ ] Logic satisfies story AC
Findings
Critical Issues
[问题及修复建议]
Important Issues
[应当处理的问题]
Nice-to-Have Suggestions
[可选的改进]
Good Practices
[做得好的地方]
Recommendations
[下一步：批准、需修订等]
修复实施
可提供的选项：修复严重 + 重要问题；仅修复严重问题（安全最低要求）；提供详细解释以供学习；仅审查（不做更改）。
大型修订的并行修复：为独立的修复领域分配智能体、协调共享依赖、为每个修复记录位置、变更和验证方法。
文档格式： ✅ FIXED: [问题名称] File: [path:line] Change: [变更内容] Verification: [如何测试]
文档更新
检查规格是否需要更新：若实现有差异，更新功能规格的"Decisions"或"Deviations"；若 UI 变更，更新设计规格；若端点修改，更新 API 契约（需批准）；若事件变更，更新数据计划。修改规格前始终标记并请求用户批准。
关键要点
开始前阅读所有上下文文档；优先关注影响最大的领域；对安全敏感代码、API 变更和关键用户流程要仔细；使用评分框架进行全面审查；并行审查可扩展到大型 PR；对规范偏差标记以供用户决策。