我以前让 AI 做 code review，最怕它一本正经地说废话
我以前真的很怕让 AI 帮我做 code review。
不是因为它看不懂代码，而是因为它太容易输出那种“看起来很专业、实际没法落地”的建议：
- 建议提高代码可读性
- 建议增强异常处理
- 建议注意安全风险
- 整体结构较为清晰
这种话不能说错，但你拿着它去改代码，会发现手里什么都没有。
真正有用的 review，应该至少回答 3 个问题：
- 哪个文件、哪一行有问题
- 这个问题严重到什么程度
- 我应该怎么改
所以我最近重新整理 claude-code-skills-zh 里的原创技能时，对 zh-code-reviewer 这个 skill 反而更有感觉了。
项目地址放这里，全文也只放这一个入口：
我想要的不是“夸我代码写得好”
很多人第一次让 AI 审代码，都会先被它哄开心。
它会说你的命名清晰、结构合理、模块划分不错。听着挺舒服，但真正进入项目后，这些评价的价值很有限。
我更希望它像一个有经验的同事：
“这里可能有空指针。”
“这个循环在数据量大时会拖慢接口。”
“这里把 token 写死了，赶紧改。”
“这个函数职责混在一起，后面维护会很痛。”
zh-code-reviewer 做的事很简单：把 Claude Code 的审查方向固定下来，不让它自由发挥成一篇空泛作文。
它会盯哪些问题
这个 skill 的审查维度不是玄学，大概就几类：
- 代码规范：命名、格式、注释是不是别扭
- 潜在 Bug：null pointer、越界、并发问题
- 性能问题：N+1 查询、内存泄漏、不必要的循环
- 安全漏洞：SQL injection、XSS、硬编码密钥
- 设计问题：模式用得对不对，有没有更简单的方案
我喜欢它的一点是，输出会按严重程度拆开。
严重问题就是严重问题，必须修。
建议改进就是建议改进，别把所有东西都说得像线上事故。
这对日常开发特别重要。因为 code review 最烦的不是问题多，而是优先级乱。你一眼看不出哪里该马上改，哪里可以等下个迭代再处理。
中文输出这件事，其实挺关键
我以前用一些英文 prompt 做 review，效果也不是不能用。
但问题是团队里真要流转起来，中文报告还是更顺手。
比如你把审查结果贴到 issue、PR 评论、群里讨论，中文描述会少很多沟通成本。尤其是新人看到“这里有 SQL injection 风险”，如果后面跟着一段中文解释和修改建议，比只甩几个英文术语友好多了。
zh-code-reviewer 的定位就是这个：不是炫技，而是让 AI 的审查结果更像能直接拿去用的中文 review 报告。
我会怎么用它
如果是一个普通业务项目，我大概会先从上面的 GitHub 仓库把 zh-code-reviewer 这个目录复制到 ~/.claude/skills/。
然后在 Claude Code 里直接让它审当前改动，重点看这几类：
- 最近提交的 diff
- 新增接口
- 数据库查询逻辑
- 鉴权、权限、token 相关代码
- 定时任务和批处理脚本
我不会指望它替代人类 reviewer。
但我会把它当成一层“低成本预检”。在把 PR 丢给同事之前，先让它扫一遍明显问题。哪怕只提前发现一个硬编码密钥、一个边界条件漏判，也已经值回票价了。
这个仓库现在更像一个技能工具箱
claude-code-skills-zh 现在不是单纯收链接。
README 里已经整理了 140+ 精选 Claude Code Skills / Agents / Plugins，还放了不少能直接安装的原创技能。除了 zh-code-reviewer，我自己也经常会看这些：
zh-readme：给项目写中文 READMEapi-tester：根据接口信息生成测试思路refactor-advisor：找代码坏味道和重构方向perf-profiler：排查性能瓶颈
它们解决的都不是“AI 能不能写代码”这种大问题，而是更具体的日常小场景。
写 README、审 PR、测接口、看性能、整理重构建议。每件事都不玄，但每件事都会消耗开发者的注意力。
我现在越来越觉得，AI 编码工具真正好用的形态，不是一个万能 prompt，而是一组场景明确的小 skill。
一个 skill 只解决一个问题，边界清楚，输出稳定，反而更容易长期用下去。
如果你也经常让 AI 帮忙审代码，你更在意它发现 Bug，还是更在意它给出可执行的修改建议？
