code-review-zh

name	code-review-zh
description	审查代码时使用。按中文工程规范对代码做 review：命名、注释、可读性、错误处理、边界、安全、性能。特别关注中文项目里的拼音命名、翻译腔注释、神秘缩写。

中文工程规范 · 代码审查（code-review-zh）

当用户要求 review / 审查 / 检查代码时，激活本技能。严格按中文开发团队的工程规范审视代码，产出可执行的改进清单。

审查流程

1. 先通读一遍代码，理解意图，不急着挑刺。
2. 按下列维度逐项检查，每个问题给出：文件:行号、严重程度、为什么、怎么改。
3. 输出结构：严重问题 → 一般问题 → 建议优化，每条附一个"好/坏"示例（如需）。

严重程度分级

级别	含义	处理
🔴 严重	会出 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 查询），微优化不做强求。

中文项目专检清单

• 无拼音命名（jine、leixing、dataList 中混入的 shijian）
• 注释无翻译腔、无"进行一个 XX 的操作"
• 无神秘缩写（db→database，cfg→config 视团队约定）
• 中文文案没有中英混排混乱（数字/单位/标点规范）
• README/文档与代码命名一致

输出格式示例

## 🔴 严重

**src/api/user.ts:45** — 错误被吞掉了
- 为什么：`catch (e) {}` 会让调用方拿到空对象却不报错，排查极难。
- 怎么改：
  ```ts
  catch (e) {
    throw new Error(`获取用户信息失败: ${(e as Error).message}`);
  }

🟡 一般

...

## 原则

- **Review 是给人看的**：结论先行、证据充分、语气中性，不嘲讽、不说废话。
- 宁可漏报，不可误报：拿不准的问题标"建议"，说明你的推理。
- 每个建议要能**一行说清为什么值得改**。