| name | code-review-zh |
| description | 审查代码时使用。按中文工程规范对代码做 review：命名、注释、可读性、错误处理、边界、安全、性能。特别关注中文项目里的拼音命名、翻译腔注释、神秘缩写。 |
中文工程规范 · 代码审查（code-review-zh）
当用户要求 review / 审查 / 检查代码时，激活本技能。严格按中文开发团队的工程规范审视代码，产出可执行的改进清单。
审查流程
- 先通读一遍代码，理解意图，不急着挑刺。
- 按下列维度逐项检查，每个问题给出：文件:行号、严重程度、为什么、怎么改。
- 输出结构：
严重问题 → 一般问题 → 建议优化，每条附一个"好/坏"示例（如需）。
严重程度分级
| 级别 | 含义 | 处理 |
|---|
| 🔴 严重 | 会出 bug、安全问题、明显违背团队规范 | 必须改 |
| 🟡 一般 | 可维护性问题、命名混乱、缺少校验 | 建议改 |
| 🟢 建议 | 风格、性能、可读性优化 | 可选 |
审查维度
1. 命名规范
- 变量/函数用英文命名（中文项目也如此），语义明确，拒绝拼音（
jine、mingcheng、shijian）。
- 全大写常量、
is/has/can 布尔前缀、动词开头的函数名。
- 拒绝神秘缩写：
data → orderData，resp → response，tmp → tempOrder。
- 类名 PascalCase、函数/变量 camelCase、常量 SCREAMING_SNAKE。
- 数据库字段/表名、URL、CSS 类统一风格，一处定义一处使用。
2. 注释质量
- 注释解释为什么，不解释是什么（"这是循环"这种注释删掉）。
- 拒绝翻译腔注释："对数据进行一个排序的操作" → "按创建时间倒序，让最新数据靠前"。
- 业务逻辑必须配注释，说明业务背景和取舍（"为什么不直接删而用软删：需要保留审计记录"）。
- 已废弃的注释、无意义注释（
// 修改、// xxx）删除。
- 注释语言与团队统一（中文项目用中文注释，术语保留英文）。
3. 可读性
- 函数尽量短小单一职责（>50 行的函数要拆分）。
- 魔法数字抽常量：
if (len > 3) → const MAX_TAGS = 3;
- 嵌套超过 3 层要早退（guard clause）或拆分。
- 重复代码抽取；
copy-paste 的相似片段合并。
4. 错误处理
- 外部调用（API、DB、文件、网络）必须有 try/catch，错误要有有意义的错误信息（含上下文），不要吞异常。
- 空指针/空值校验：明确空集合 vs null vs undefined。
- 资源必须释放（连接、文件句柄、临时文件）。
- 错误信息对用户友好、可操作；日志分级。
5. 边界与安全
- 输入校验：长度、类型、范围、空值、特殊字符（XSS / SQL 注入 / 路径穿越）。
- 并发/竞态：共享状态、缓存一致性。
- 敏感信息：不硬编码密钥，不打日志，不返回给前端。
- 权限校验：不能只做前端隐藏，后端必须校验。
6. 性能
- 明显低效：循环内查询 DB、重复计算、大对象深拷贝、未复用连接。
- 优先指出量级问题（O(n²)、N+1 查询），微优化不做强求。
中文项目专检清单
输出格式示例
## 🔴 严重
**src/api/user.ts:45** — 错误被吞掉了
- 为什么：`catch (e) {}` 会让调用方拿到空对象却不报错，排查极难。
- 怎么改：
```ts
catch (e) {
throw new Error(`获取用户信息失败: ${(e as Error).message}`);
}
🟡 一般
...
## 原则
- **Review 是给人看的**：结论先行、证据充分、语气中性，不嘲讽、不说废话。
- 宁可漏报，不可误报：拿不准的问题标"建议"，说明你的推理。
- 每个建议要能**一行说清为什么值得改**。
