name: 代码审查 description: 使用结构化检查表审查代码的质量、安全性和风格。在审查PR、提供代码反馈或审计代码质量时使用。

代码审查

使用结构化检查表审查代码的正确性、安全性、性能和可维护性。提供可操作、优先级的反馈。

何时使用

用户请求代码审查、PR审查或代码反馈
用户想在合并前检查代码质量、安全性或风格
用户正在审计文件或模块

工作流程

理解上下文：变更的目的是什么？（问题、功能、重构）
阅读差异：实际改变了什么？
收集所有问题—不要在第一个错误处停止：审查整个范围，返回发现的每个问题。不要当遇到第一个错误或建议时就停止。使用manage_todos、草稿文件或spawn_subagent（对于大型PR）来跟踪问题，然后输出完整列表。
收集使用上下文：在孤立评判变更前，收集足够上下文以提供完整反馈：
- 周围代码：阅读包含变更的函数/模块，而不仅仅是修改的行。存在哪些不变条件、前提条件或模式？
- 调用站点和用法：这段代码如何被调用？搜索调用者、导入或用法。调用站点是否存在边缘情况或误用模式？
- 集成点：是否涉及API、数据库、外部服务或共享状态？它如何融入更大的流程？
- 测试：如果该区域有测试，阅读它们以了解预期行为和覆盖差距。
运行检查表：逻辑、安全性、性能、风格、测试（使用收集的上下文）
考虑语言和框架最佳实践：代码是否遵循该技术栈的习惯模式？
优先级排序：关键→必须修复；建议→考虑；可有可无→可选
响应：总结 + 分类评论 + 具体建议 + 做得好的地方

高效使用git_diff

git_diff工具会截断大型差异（默认500行）。对于多文件或1000+行变更的PR：

首先获取文件列表：用commit（例如main...HEAD）和nameOnly: true调用git_diff。您收到paths—更改文件的完整列表。
分批获取内容：
- 小型PR（少数文件，总计约500行以下）：仅用commit调用git_diff获取完整差异。
- 大型PR：用commit和paths设置为每批5–10个文件（例如paths: ["src/foo.ts", "src/bar.ts"]）调用git_diff。如果批次大，使用maxLines: 2000。迭代直到审查完所有文件。
优先级排序：首先审查最高风险区域（身份验证、输入处理、外部调用）。安全敏感文件需要额外关注。

不要假设单个git_diff调用显示所有内容。如果结果说truncated或您只看到少数文件，使用上述分批工作流。

审查检查表

正确性与逻辑

[ ] 它是否做了它声称的事情？边缘情况？
[ ] 差一错误、null/undefined、空输入？
[ ] 错误处理：失败是否被捕获和处理？
[ ] 并发：竞争条件、死锁、共享状态？

安全性

[ ] 用户输入是否经过验证和清理？
[ ] 代码或日志中是否有秘密？
[ ] 在需要的地方检查了身份验证/授权？
[ ] 避免了危险函数（eval、exec、SQL拼接）？

性能

[ ] 明显的低效率？（例如，可避免时的循环中循环）
[ ] 大数据：流式处理、分页或限制？
[ ] 缓存或可重用的重复工作？

可维护性

[ ] 命名清晰？函数做一件事？
[ ] 可提取的重复代码？
[ ] 应该为常量的魔法数字/字符串？
[ ] 注释仅在需要时（为什么，而不是什么）？

测试

[ ] 新行为是否有测试覆盖？
[ ] 测试可读且稳定（无flake）？
[ ] 模拟/夹具适当？

风格与惯例

[ ] 匹配项目风格（lint、格式化器）？
[ ] 导入组织有序？死代码移除？

反馈格式

使用一致的严重性和格式：

## 代码审查：[PR/文件名]

### 总结
[1-2句话：整体评估和主要关注点]

### 做得好的地方
- [突出具体做得非常好的事情—清晰命名、稳固错误处理、习惯模式等]
- [认可语言/框架特性的良好使用]

### 关键（必须解决）
- **[位置]** [问题]。 [建议或修复]
- ...

### 建议（考虑）
- **[位置]** [问题]。 [可选改进]
- ...

### 可有可无
- [次要抛光或未来改进]

位置：文件路径、函数名或“第N行”（如果行号可用）。要具体，以便作者能跳转到它。

建议：优先具体修复（代码片段或确切变更），而不是模糊的“考虑改进X”。

语气

尊重且建设性
假设良好意图；解释请求背后的“为什么”
区分“这是错误的”和“这可能更清晰”
无价值时不挑剔；批量处理琐碎风格问题

不要做什么

不要跳过“做得好的地方”部分—认可好工作能激励并强化最佳实践
除非是项目惯例，否则不要强加个人风格偏好
不要重复差异已显示的内容（“你添加了一个函数”）
不要只留下“LGTM”而至少没有一行总结
不要混合严重性：关键项必须清晰标记

小型与大型PR

小型：完整检查表，快速通过。一轮反馈。
大型：按区域总结（例如“身份验证逻辑”、“UI组件”）。首先指出最高风险区域。如果有助于，建议拆分。

安全敏感区域

额外审查：

身份验证（登录、会话、权限）
输入处理（表单、API参数、文件上传）
外部调用（HTTP、数据库、shell）
加密和秘密

对于这些，明确注明：“未发现问题”或列出具体担忧。

反模式

❌ 孤立审查差异而不检查周围代码或调用站点—无上下文反馈通常不完整或错误
❌ 模糊反馈（“这可以更好”）
❌ 仅赞扬而无当问题存在时的可操作项
❌ 阻塞不在风格指南中的风格问题
❌ 错过主要错误或安全问题而评论格式