SmartEDT/.trae/skills/code-reviewer/SKILL.md

name	description
code-reviewer	审查代码的正确性、安全性、可维护性与一致性。用户要求“代码审查/Review”、准备合并、或你完成较大改动后调用。

Code Reviewer（代码审查）

何时使用

• 用户明确提出“代码审查/Review/帮我看看这段代码/有没有坑”
• 你完成了较大改动（多文件、涉及业务逻辑/安全/性能/并发/数据库/鉴权），准备交付前自检
• 修复 bug 后，需要确认没有引入回归

输入要求（你需要我提供什么）

优先按可获得的信息审查，不强制全部具备：

• 需要审查的范围：文件路径/目录/提交 diff/粘贴代码片段
• 目标与约束：功能期望、性能目标、兼容性、上线环境、风格偏好
• 相关上下文：调用链入口、接口契约（请求/响应）、数据库表/索引、配置项

审查维度（检查清单）

正确性

• 边界条件、空值、异常路径、重试/幂等、并发与竞态
• 输入校验与错误信息一致性
• 资源释放（文件句柄、连接、锁）、超时设置

安全性

• 注入风险（SQL/命令/模板/路径穿越）、反序列化风险
• 鉴权/鉴别：敏感操作是否校验权限，是否存在越权路径
• 机密信息：日志/错误信息/返回值中是否泄露 token、密码、密钥、PII

可维护性

• 代码结构是否清晰，职责是否单一，命名是否表达意图
• 重复逻辑是否可抽取，是否遵循既有项目模式
• 配置/常量是否集中管理，错误码/异常是否统一

性能与稳定性

• 热路径复杂度、N+1、无界循环/递归、潜在阻塞 I/O
• 缓存策略、批处理、分页、索引友好性
• 观测性：日志粒度、指标点、错误上下文是否足够定位

风格与一致性

• 与仓库既有格式、依赖、工具链一致（类型、lint、格式化、文件组织）
• 公共工具与约定（例如 logger、配置、错误处理）是否复用而非自造

输出格式（你应如何给出审查结果）

按“可执行、可落地”的方式输出，默认用中文：

1. 结论摘要（风险等级：高/中/低）
2. 必须修复（Blockers）：每条包含 位置、问题、影响、建议修复
3. 建议改进（Suggestions）：同上，但不阻塞
4. 可选优化（Nice-to-have）
5. 若适用：给出最小改动的补丁方案（优先）或替代实现思路

约束

• 不凭空假设依赖已存在；若引入新依赖，先确认仓库已有或给出替代方案
• 不输出或建议写入任何密钥/token