Appearance
Code Review 技能解决的是“AI 说完成了，但代码能不能合并没人知道”的问题。审查时不要只看功能表面，要按正确性、可读性、架构、安全和性能五个角度检查，并把问题分成必须修和可以后续优化。
AI 写完代码怎么审：Code Review 技能怎么用
下载 code-review-and-quality 中文版 Skill ZIP
Claude Code 回了一句：“完成了。”
它确实改了文件，也可能跑了测试。
但“完成了”不等于“可以合并”。
code-review-and-quality 这个技能的目标，是把 AI 生成的代码重新拉回工程审查流程。不要把 Agent 的自我总结当成结论，要看 diff、看测试、看风险。
先看测试，再看实现
很多人 review AI 代码，会直接从实现文件开始看。
更稳的顺序是先看测试或验证证据。
因为测试能告诉你：AI 以为自己解决了什么问题。
如果测试写偏了，代码写得再漂亮也可能没意义。比如需求是“未登录用户不能访问设置页”，AI 却只测了“设置页能正常渲染”。这类测试不能证明权限逻辑正确。
如果没有测试，也要看它有没有真实验证：跑了哪个命令、打开了哪个页面、覆盖了哪个用户路径。
没有证据的“完成”，只能算待确认。
五个角度审 AI 代码
agent-skills 里的代码审查强调五个角度。你不需要写很长报告，但这五件事最好都过一遍。
正确性
它真的解决了原问题吗？
要检查：
- 核心需求是否满足。
- 边界条件是否覆盖。
- 旧行为是否被破坏。
- 错误路径是否合理。
AI 常见问题是只修 happy path。表面路径能跑，异常输入、空状态、权限边界都没管。
可读性
代码以后人能不能维护？
要检查：
- 命名是否清楚。
- 函数是否过长。
- 条件分支是否绕。
- 是否出现为了过测试写出的奇怪代码。
AI 有时会写出“能跑但不像人写的代码”。这种代码短期没问题，后面会拖慢维护。
架构
改动是否放在合适位置？
要检查：
- 是否绕过现有模式。
- 是否新增了不必要抽象。
- 是否把业务逻辑塞进 UI。
- 是否为了一个场景破坏公共接口。
AI 很容易因为没看全项目模式，写出一套局部自洽但和项目不搭的方案。
安全
有没有引入明显风险？
要检查：
- 用户输入是否被信任。
- 是否暴露 token、密钥、错误细节。
- 是否有权限绕过。
- 是否把敏感数据写进前端或日志。
只要涉及登录、权限、用户输入、文件系统、数据库、外部 API，就不能只看功能能不能跑。
性能
有没有明显浪费？
要检查：
- 是否在循环里重复请求。
- 是否引入无界查询。
- 是否让页面重复渲染。
- 是否把大对象塞进不必要的状态。
不需要提前优化一切，但明显的低级性能问题要拦住。
把问题分级，而不是全都重写
审查 AI 代码时，容易走两个极端：要么全盘接受，要么看不顺眼就重写。
更好的做法是分级：
- 必须修：功能错误、安全风险、数据丢失、测试失败。
- 应该修：明显可维护性问题、架构位置不对、边界遗漏。
- 可后续：命名小瑕疵、局部风格不统一、非关键优化。
这样 review 不会变成无限重构。
AI 写的代码不需要完美，但必须安全、正确、可维护。
给 AI 做自审也要有规则
你可以让 AI 自己先审一遍，但不要问“有没有问题”。
它大概率会说没有。
更好的 prompt 是：
md
请按下面五个角度审查刚才的 diff：
1. 正确性：是否满足需求，有没有边界遗漏。
2. 可读性：命名、函数长度、分支复杂度。
3. 架构：是否符合项目现有模式。
4. 安全：是否涉及用户输入、权限、敏感数据。
5. 性能：是否有明显重复计算、重复请求或无界操作。
只列出真实问题，不要为了凑数量编问题。
把问题分成：必须修、应该修、可后续。这比“帮我 review 一下”有效得多。
古法编程里的代码审查
古法编程不把“测试通过”当终点。
测试能证明一部分行为，review 负责看测试没覆盖的地方：设计是否合理，边界是否清楚，风险是否可控。
AI Agent 可以写代码，也可以帮你审代码。可最终判断要在人手里。
你可能还需要
同类技能：
如果 AI 已经写完代码，先别急着合并。先看测试证据，再按五个角度过一遍 diff。