国内团队中文 Code Review：用建议式话术与分级标注…

在国内团队做中文代码审查、需要写评审评论/总结、统一中英混排注释与 Commit Message 规范时使用。

适用场景

解决思路

1. 核心原则：用“建议”代替“命令”，用“提问”代替“否定”，但绝不因为面子而放过 bug。
2. 用建议代替命令：避免“你必须改成 X”，改为“建议考虑用 X，因为 Y”。
3. 用建议代替命令：避免“这里写错了”，改为“这里可能存在一个问题，是否考虑过 Z 的情况？”
4. 用建议代替命令：避免“不要用这个方法”，改为“这个方法在 A 场景下可能有性能问题，可以看看 B 方案”。
5. 用建议代替命令：避免“这段代码不行”，改为“这段逻辑我理解得对吗？如果输入为空的话会怎样？”
6. 不确定对方意图时先问再评：例如“这里用 sync 方式读文件是出于什么考虑？如果并发量上来，可能会阻塞事件循环。”，而不是“这里不应该用 sync 方式读文件。”
7. 统一使用优先级标记：[必须修复] 用于安全漏洞、数据丢失风险、逻辑错误（不修不能合）。
8. 统一使用优先级标记：[建议修改] 用于性能问题、可维护性、缺少校验（本次或下次迭代修复）。
9. 统一使用优先级标记：[仅供参考] 用于命名优化、风格建议、替代方案（不改也行）。
10. 统一使用优先级标记：[问题] 用于不确定的地方，需要作者解释意图。
11. 使用审查评论模板：按“[优先级] 标题 + 位置 + 原因 + 建议 + 参考”的结构写，例如 SQL 注入风险评论中写明第 42 行、用户输入直接拼接 SQL、攻击者可注入 `'; DROP TABLE users; --`、建议使用参数化查询 `db.query('SELECT * FROM users WHERE name = $1', [name])`、附 OWASP 参考链接。
12. 中英混排注释：业务逻辑说明用中文解释业务背景和需求来源。
13. 中英混排注释：复杂算法注释用中文写思路，确保团队成员都能理解。
14. 中英混排注释：TODO / FIXME 用中文描述待办事项，方便搜索和追踪。
15. 中英混排注释：文档注释（内部项目）中 JSDoc / Javadoc 的描述文字用中文。
16. 中英混排注释：变量名、函数名、类名始终用英文命名，遵循团队命名规范。
17. 中英混排注释：Git commit message 参考 commit 规范；开源项目面向国际社区时注释统一用英文。
18. 中英混排注释：生产环境的 error message 用英文，避免编码问题。
19. 中英混排注释：对外暴露的 API 接口文档用英文。
20. 中英混排格式：中英文之间加空格，例如“使用 Redis 缓存来减少 MySQL 的查询压力”，不要写成“使用Redis缓存来减少MySQL的查询压力”。
21. 中英混排格式：技术术语保留英文，例如“这里用 debounce 防抖处理，避免频繁触发 API 请求”，不要强行翻译成“防抖动”“应用程序接口请求”。
22. Commit Message 推荐格式：团队内部项目使用中文 commit message，采用约定式提交（Conventional Commits）的中文版：`<类型>(<范围>): <简要描述>`，可附详细说明和关联信息。
23. Commit 类型使用：feat 新功能，如 `feat(用户): 新增手机号登录功能`。
24. Commit 类型使用：fix 修复 Bug，如 `fix(支付): 修复微信支付回调重复处理的问题`。
25. Commit 类型使用：docs 文档变更，如 `docs: 更新 API 接口文档`。
26. Commit 类型使用：style 代码格式，如 `style: 统一缩进为 2 个空格`。
27. Commit 类型使用：refactor 重构，如 `refactor(订单): 拆分订单服务，提取公共逻辑`。
28. Commit 类型使用：perf 性能优化，如 `perf(列表): 虚拟滚动优化长列表渲染性能`。
29. Commit 类型使用：test 测试，如 `test(auth): 补充登录模块单元测试`。
30. Commit 类型使用：chore 构建/工具，如 `chore: 升级 Node.js 至 v20`。
31. Commit 示例：`fix(支付): 修复支付宝异步回调签名校验失败的问题`，正文写原因（升级 SDK 后签名算法从 RSA 变为 RSA2，但回调校验仍使用旧算法）和方案（回调处理中同时兼容 RSA 和 RSA2 签名校验），并关联 `Closes #1234`。
32. 面向国际社区或有外籍成员的项目：commit message 用英文，PR 描述中可附加中文说明，例如 `fix(payment): fix Alipay async callback signature verification failure` 并附英文原因和 `Closes #1234`。
33. 反模式一“过度客气”：不要所有评论都用“我觉得可能也许大概好像这里有个小问题”；要使用分级标注，[必须修复] 就是必须修复，语气可以温和但级别必须准确。
34. 反模式一“过度客气”的正确示例：写“[必须修复] 并发安全问题”，说明 map 在多个 goroutine 中同时读写会触发 panic，建议加 sync.RWMutex 或换成 sync.Map，并给出复现方式“加 -race flag 跑测试”。
35. 反模式二“不敢给高级开发者提意见”：Code Review 对事不对人，可用提问式或学习式表达；提问式如“想请教一下，这里选择用递归而不是迭代，是出于什么考虑？如果递归深度超过 1000 层会不会有栈溢出的风险？”；学习式如“学到了一个新写法！不过有个小疑问——这里的类型断言在运行时不会做检查，如果上游数据结构变了，这里会静默通过。是否考虑加个 runtime validation？”
36. 反模式三“审查变成风格之争”：风格问题交给 ESLint / Prettier / gofmt 等工具自动处理，Code Review 聚焦逻辑、安全、性能。
37. 反模式四“只写 LGTM”：即使代码质量很好，也要写出关注了哪些方面，例如并发安全锁的粒度合理、错误处理所有外部调用都有 error handling、向下兼容新增字段都有默认值，并给出小建议如“第 78 行的变量名 `d` 可以改成 `duration`，更易读”。
38. 审查前：先看 PR 描述，理解改动的背景和目的。
39. 审查前：看关联的 Issue 或需求文档。
40. 审查前：先整体浏览，再逐文件细看。
41. 审查顺序：架构层面——方案是否合理？有没有更好的方式？
42. 审查顺序：正确性——逻辑对不对？边界条件处理了吗？
43. 审查顺序：安全性——有没有注入、越权、信息泄露？
44. 审查顺序：性能——有没有 N+1 查询、内存泄漏、不必要的循环？
45. 审查顺序：可维护性——半年后能看懂吗？测试覆盖了吗？
46. 审查顺序：风格——只关注工具无法自动处理的部分。
47. 给出总结：审查结束后给一段总结，包括整体评价（一句话）、值得学习的地方（先扬后抑）、主要问题列表（按优先级）、建议的修改方向。
48. 总结示例：整体实现思路清晰，支付回调的幂等处理很到位；主要问题按 [必须修复] 并发写 map 的问题（2 处）、[建议修改] 缺少对空值的校验（3 处）、[仅供参考] 几个变量命名可以更语义化列出；建议先修复并发问题，校验的部分可以本次一起改或者拆到下个迭代。
49. 提交审查意见前检查：每条评论都标注了优先级。
50. 提交审查意见前检查：[必须修复] 的问题都给出了具体的修复建议。
51. 提交审查意见前检查：没有因为面子而跳过关键问题。
52. 提交审查意见前检查：没有纠结于工具能自动处理的风格问题。
53. 提交审查意见前检查：对好的代码给予了肯定。
54. 提交审查意见前检查：给出了整体总结。

适用边界 · 注意事项

• 用户未显式输入 /chinese-code-review 时，不要根据上下文自动触发本技能。
• 当团队已经统一使用纯英文 review 且不需要中文话术时，不适用。
• 当只需处理可由工具自动修复的风格/格式问题时，不适用，应交给 ESLint / Prettier / gofmt 等工具。