菜单
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用，不要根据上下文自动触发。
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用，不要根据上下文自动触发。
当存在 2 个以上互不关联的问题（测试失败、bug、独立任务），需要并行分派子代理并发排查或执行时
| name | chinese-code-review |
| description | 中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。 |
国内团队做 Code Review 常遇到两个极端：要么过度客气导致关键问题被放过，要么照搬西方直白风格让同事下不来台。本技能帮你找到平衡点——既不回避问题，又让人愿意接受反馈。
核心原则： 用"建议"代替"命令"，用"提问"代替"否定"，但绝不因为面子而放过 bug。
| 避免（命令式） | 推荐（建议式） |
|---|---|
| 你必须改成 X | 建议考虑用 X，因为 Y |
| 这里写错了 | 这里可能存在一个问题，是否考虑过 Z 的情况？ |
| 不要用这个方法 | 这个方法在 A 场景下可能有性能问题，可以看看 B 方案 |
| 这段代码不行 | 这段逻辑我理解得对吗？如果输入为空的话会怎样？ |
# 好的方式
这里用 sync 方式读文件是出于什么考虑？如果并发量上来，可能会阻塞事件循环。
# 不好的方式
这里不应该用 sync 方式读文件。
统一使用优先级标记，让作者快速判断轻重缓急：
[必须修复] SQL 注入风险
第 42 行：用户输入直接拼接到 SQL 语句中。
原因：攻击者可以通过 name 参数注入恶意 SQL。
建议：使用参数化查询：
db.query('SELECT * FROM users WHERE name = $1', [name])
参考：https://cheatsheetseries.owasp.org/...
/**
* 计算用户的会员等级折扣
*
* 业务规则：
* - 普通会员 9.5 折
* - 银卡会员 9 折
* - 金卡会员 8.5 折
* - 钻石会员 8 折
*
* @param level - 会员等级（MemberLevel enum）
* @param amount - 原始金额（单位：分）
* @returns 折后金额（单位：分）
*/
function calculateDiscount(level: MemberLevel, amount: number): number {
// ...
}
// 好：中英文之间加空格，技术术语保留英文
// 使用 Redis 缓存来减少 MySQL 的查询压力
// 这里用 debounce 防抖处理，避免频繁触发 API 请求
// 坏：中英文之间没有空格，强行翻译技术术语
// 使用Redis缓存来减少MySQL的查询压力
// 这里用防抖动处理，避免频繁触发应用程序接口请求
表现： 所有评论都是"我觉得可能也许大概好像这里有个小问题"。
对策： 使用分级标注。[必须修复] 就是必须修复，语气可以温和，但级别必须准确。
# 坏：过度客气
不知道我理解得对不对，这里好像可能有一点点并发问题……
# 好：温和但清晰
[必须修复] 并发安全问题
这里的 map 在多个 goroutine 中同时读写，会触发 panic。
建议加 sync.RWMutex，或者换成 sync.Map。
复现方式：加 -race flag 跑测试就能看到。
表现： 高级开发者或 Leader 的代码直接 Approve，不仔细看。
对策： Code Review 对事不对人。用提问式或学习式表达：
# 提问式
想请教一下，这里选择用递归而不是迭代，是出于什么考虑？
如果递归深度超过 1000 层会不会有栈溢出的风险？
# 学习式
学到了一个新写法！不过有个小疑问——这里的类型断言在运行时不会做检查，
如果上游数据结构变了，这里会静默通过。是否考虑加个 runtime validation？
表现： 大量评论纠结于缩进、空格、花括号位置。
对策： 风格问题交给 ESLint / Prettier / gofmt 等工具自动处理。Code Review 聚焦逻辑、安全、性能。
表现： 随手一个 LGTM 就 Approve，没有实质性审查。
对策： 即使代码质量很好，也要写出你关注了哪些方面：
LGTM
审查了以下方面：
- 并发安全：锁的粒度合理
- 错误处理：所有外部调用都有 error handling
- 向下兼容：新增字段都有默认值，不影响老版本
一个小建议 [仅供参考]：第 78 行的变量名 `d` 可以改成 `duration`，更易读。
审查结束后，给一段总结，包括：
总结：整体实现思路清晰，支付回调的幂等处理很到位。
主要问题：
1. [必须修复] 并发写 map 的问题（2 处）
2. [建议修改] 缺少对空值的校验（3 处）
3. [仅供参考] 几个变量命名可以更语义化
建议先修复并发问题，校验的部分可以本次一起改或者拆到下个迭代。
在提交审查意见前，确认：