国内团队代码审查话术技能，提供三级标注体系（必须修复/建议修改/仅供参考）和沟通模板。用「建议」代替「命令」，用「提问」代替「否定」，同时涵盖中英混排注释规范、Git Commit双语格式、常见四种反模式（过度客气/不敢提意见/风格之争/LGTM空洞）应对策略。

中文代码审查规范：分级标注与沟通话术

【适用场景】

当需要给同事代码提意见时，使用「建议」代替「命令」，「提问」代替「否定」。例如：「建议考虑用X，因为Y」而不是「你必须改成X」。

使用统一优先级标记让作者快速判断轻重缓急：[必须修复]、[建议修改]、[仅供参考]、[问题]。

业务逻辑用中文注释，变量名/函数名始终用英文，遵循「中英文之间加空格」格式要求。

团队内部项目使用中文commit message，采用约定式提交（Conventional Commits）中文版，如 `fix(支付): 修复微信支付回调重复处理`。

第一步：开始审查前 1. 先看PR描述，理解改动背景和目的 2. 看关联的Issue或需求文档 3. 先整体浏览，再逐文件细看

第二步：审查顺序 1. 架构层面——方案是否合理 2. 正确性——逻辑对不对，边界条件 3. 安全性——注入、越权、信息泄露 4. 性能——N+1查询、内存泄漏 5. 可维护性——测试覆盖 6. 风格——仅关注工具无法自动处理部分

第三步：给出反馈 使用分级标注，每条评论都标注优先级，给出具体修复建议。

第四步：总结 整体评价（一句话）、值得学习的地方、主要问题列表（按优先级）。

反馈模板 ``` [必须修复] SQL注入风险

第42行：用户输入直接拼接到SQL语句中。

原因：攻击者可以通过name参数注入`'; DROP TABLE users; --`。

建议：使用参数化查询： db.query('SELECT * FROM users WHERE name = $1', [name]) ```

Commit格式 ``` <类型>(<范围>): <简要描述>

<详细说明（可选）>

<关联信息（可选）> ```

类型对照：feat(新功能)、fix(Bug)、docs(文档)、style(格式)、refactor(重构)、perf(性能)、test(测试)、chore(构建/工具)

常见反模式 - 过度客气：所有评论都是「小问题」，关键bug被隐藏 - 不敢提意见：对高级开发者直接Approve不仔细看 - 风格之争：大量评论纠结缩进、空格、花括号位置 - LGTM空洞：随手一个LGTM没有实质性审查

检查清单 - [ ] 每条评论都标注了优先级 - [ ] [必须修复] 的问题都给出了具体修复建议 - [ ] 没有因为面子跳过关键问题 - [ ] 对好的代码给予了肯定 - [ ] 给出了整体总结

来源：GitHub https://github.com/jnmetacode/superpowers-zh/blob/main/skills/chinese-code-review/SKILL.md