Menu
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 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. [仅供参考] 几个变量命名可以更语义化
建议先修复并发问题，校验的部分可以本次一起改或者拆到下个迭代。
在提交审查意见前，确认：