القائمة
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。
| name | chinese-code-review |
| description | 中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["code-review","chinese"]}} |
国内团队做 Code Review 常遇到两个极端：要么过度客气导致关键问题被放过，要么照搬西方直白风格让同事下不来台。本技能帮你找到平衡点——既不回避问题，又让人愿意接受反馈。
核心原则： 用"建议"代替"命令"，用"提问"代替"否定"，但绝不因为面子而放过 bug。
| 避免（命令式） | 推荐（建议式） |
|---|---|
| 你必须改成 X | 建议考虑用 X，因为 Y |
| 这里写错了 | 这里可能存在一个问题，是否考虑过 Z 的情况？ |
| 不要用这个方法 | 这个方法在 A 场景下可能有性能问题，可以看看 B 方案 |
| 这段代码不行 | 这段逻辑我理解得对吗？如果输入为空的话会怎样？ |
当你不确定对方意图时，先问再评：
# 好的方式
这里用 sync 方式读文件是出于什么考虑？如果并发量上来，可能会阻塞事件循环。
# 不好的方式
这里不应该用 sync 方式读文件。
统一使用优先级标记，让作者快速判断轻重缓急：
[必须修复] SQL 注入风险
第 42 行：用户输入直接拼接到 SQL 语句中。
原因：攻击者可以通过 name 参数注入 `'; DROP TABLE users; --`。
建议：使用参数化查询：
db.query('SELECT * FROM users WHERE name = $1', [name])
参考：https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
/**
* 计算用户的会员等级折扣
*
* 业务规则：
* - 普通会员 9.5 折
* - 银卡会员 9 折
* - 金卡会员 8.5 折
* - 钻石会员 8 折
*
* @param level - 会员等级（MemberLevel enum）
* @param amount - 原始金额（单位：分）
* @returns 折后金额（单位：分）
*/
function calculateDiscount(level: MemberLevel, amount: number): number {
// ...
}
// 好：中英文之间加空格
// 使用 Redis 缓存来减少 MySQL 的查询压力
// 坏：中英文之间没有空格
// 使用Redis缓存来减少MySQL的查询压力
// 好：技术术语保留英文
// 这里用 debounce 防抖处理，避免频繁触发 API 请求
// 坏：强行翻译技术术语
// 这里用防抖动处理，避免频繁触发应用程序接口请求
团队内部项目使用中文 commit message，采用约定式提交（Conventional Commits）的中文版：
<类型>(<范围>): <简要描述>
<详细说明（可选）>
<关联信息（可选）>
| 类型 | 含义 | 示例 |
|---|---|---|
| feat | 新功能 | feat(用户): 新增手机号登录功能 |
| fix | 修复 Bug | fix(支付): 修复微信支付回调重复处理的问题 |
| docs | 文档变更 | docs: 更新 API 接口文档 |
| style | 代码格式 | style: 统一缩进为 2 个空格 |
| refactor | 重构 | refactor(订单): 拆分订单服务，提取公共逻辑 |
| perf | 性能优化 | perf(列表): 虚拟滚动优化长列表渲染性能 |
| test | 测试 | test(auth): 补充登录模块单元测试 |
| chore | 构建/工具 | chore: 升级 Node.js 至 v20 |
fix(支付): 修复支付宝异步回调签名校验失败的问题
原因：升级 SDK 后签名算法从 RSA 变为 RSA2，但回调校验仍使用旧算法。
方案：回调处理中同时兼容 RSA 和 RSA2 签名校验。
Closes #1234
如果项目面向国际社区或有外籍成员，commit message 用英文，PR 描述中可附加中文说明：
fix(payment): fix Alipay async callback signature verification failure
The SDK upgrade changed the signature algorithm from RSA to RSA2,
but the callback handler still used the old algorithm.
Closes #1234
表现： 所有评论都是"我觉得可能也许大概好像这里有个小问题"。
后果： 关键 bug 被隐藏在一堆委婉语里，作者根本不知道哪些必须改。
对策： 使用分级标注。[必须修复] 就是必须修复，语气可以温和，但级别必须准确。
# 坏：过度客气
不知道我理解得对不对，这里好像可能有一点点并发问题，不过也许我看错了...
# 好：温和但清晰
[必须修复] 并发安全问题
这里的 map 在多个 goroutine 中同时读写，会触发 panic。
建议加 sync.RWMutex，或者换成 sync.Map。
复现方式：加 -race flag 跑测试就能看到。
表现： 高级开发者或 Leader 的代码直接 Approve，不仔细看。
后果： 代码质量双标，团队对 Code Review 失去信任。
对策： Code Review 对事不对人。可以换个表达方式：
# 提问式（适合给资深同事的反馈）
想请教一下，这里选择用递归而不是迭代，是出于什么考虑？
我在想如果递归深度超过 1000 层会不会有栈溢出的风险？
# 学习式
学到了一个新写法！不过有个小疑问——这里的类型断言在运行时不会做检查，
如果上游数据结构变了，这里会静默通过。是否考虑加个 runtime validation？
表现： 大量评论纠结于缩进、空格、花括号位置。
后果： 浪费时间，忽略真正的问题。
对策： 风格问题交给 ESLint / Prettier / gofmt 等工具自动处理。Code Review 聚焦逻辑、安全、性能。
表现： 随手一个 LGTM 就 Approve，没有实质性审查。
后果： Code Review 形同虚设，出了问题没人兜底。
对策： 即使代码质量很好，也要写出你关注了哪些方面：
LGTM
审查了以下方面：
- 并发安全：锁的粒度合理
- 错误处理：所有外部调用都有 error handling
- 向下兼容：新增字段都有默认值，不影响老版本
一个小建议 [仅供参考]：第 78 行的变量名 `d` 可以改成 `duration`，更易读。
审查结束后，给一段总结，包括：
总结：整体实现思路清晰，支付回调的幂等处理很到位。
主要问题：
1. [必须修复] 并发写 map 的问题（2 处）
2. [建议修改] 缺少对空值的校验（3 处）
3. [仅供参考] 几个变量命名可以更语义化
建议先修复并发问题，校验的部分可以本次一起改或者拆到下个迭代。
在提交审查意见前，确认：