团队里最怕的一种 AI Code Review，不是它说错了，而是它说得太像对的。
比如你丢给它一整个项目，然后问：
帮我 Review 一下这次改动有没有问题。
它可能会很认真地输出一堆建议：
这里可以抽函数；
这里命名可以优化；
这里建议重构；
这里可以换一种设计模式。
看起来很专业，但你真正关心的可能是：
这次改动有没有破坏旧逻辑？
有没有漏掉异常分支？
接口返回结构有没有变？
权限校验有没有绕过去？
测试有没有覆盖核心路径？
有没有引入线上风险？
AI 做 Code Review 的正确姿势，不是让它“通读整个项目”，而是让它围绕这次 PR 的目标看改动。
我现在更推荐一个很轻的方式：给 AI 准备一份 Review Packet。
它只包含 4 份材料：
- 这次 PR 想解决什么问题
- 这次改了哪些文件
- 这次真实的 git diff
- 测试结果或未测试原因
这样 AI 的注意力会集中很多，也更像一个靠谱的 Reviewer，而不是一个突然兴奋的重构爱好者。
1. 不要让 AI 先看项目，让它先看“改动意图”
Code Review 的第一步不是看代码，而是看目的。
同样一段代码，如果目标不同，Review 结论可能完全不同。
比如这个改动：
if (!user) {
return null;
}
如果目标是“避免页面崩溃”，这可能是合理兜底。
但如果目标是“登录态校验”，这可能掩盖了权限问题。
所以给 AI 的第一段信息，应该是 PR 目标，而不是代码文件。
可以这样写：
本次 PR 目标：
修复用户进入订单详情页时，偶发出现空白页的问题。
已知现象：
- 用户从消息通知进入订单详情页
- 某些订单状态下接口返回 order 字段为空
- 前端直接读取 order.status 导致页面崩溃
本次修改目标：
- 避免页面崩溃
- 保留原有订单状态展示逻辑
- 不修改后端接口结构
- 不改变路由跳转逻辑
这一段能帮 AI 判断：它应该重点看“空值兜底”“异常展示”“旧逻辑是否保留”，而不是突然建议你重写订单模块。
2. 用 Git 生成最小 Review 材料
如果你用 Git 管理项目，可以先生成几个材料。
查看本次改动文件：
git diff --name-only main...HEAD
查看改动统计：
git diff --stat main...HEAD
生成完整 diff：
git diff main...HEAD > review.diff
如果你是本地还没提交的改动，可以用：
git diff > review.diff
如果已经 git add 了，可以用：
git diff --cached > review.diff
如果想把最近一次提交拿出来给 AI 看：
git show --stat HEAD
git show HEAD > review.diff
这些命令的好处是：AI 看到的是“这次改了什么”，而不是“这个项目所有代码长什么样”。
这对 Review 很关键。
因为真正的代码审查，看的不是项目百科，而是变更影响。
3. 给 AI 的 Review Packet 模板
可以新建一个文件：
touch REVIEW_PACKET.md
把下面内容填进去：
# AI Code Review Packet
## 1. PR 目标
【写清楚这次改动要解决什么问题】
## 2. 背景信息
【用户场景、业务限制、历史兼容逻辑、不能改的地方】
## 3. 改动文件
```text
【粘贴 git diff --name-only main...HEAD 的结果】
```
## 4. 改动统计
```text
【粘贴 git diff --stat main...HEAD 的结果】
```
## 5. 核心 Diff
```diff
【粘贴 review.diff 中与本次问题最相关的部分】
```
## 6. 测试结果
```text
【粘贴 npm test / pnpm test / pytest / go test / mvn test 等结果】
```
## 7. 希望 AI 重点检查
请重点检查：
1. 是否偏离 PR 目标
2. 是否改变原有接口结构
3. 是否漏掉异常分支
4. 是否影响旧数据或历史兼容逻辑
5. 是否有权限、安全、空值、并发风险
6. 测试是否覆盖核心路径
7. 是否存在不必要的大范围重构
## 8. AI 输出要求
请不要直接重写代码。
请按以下格式输出：
1. 总体 Review 结论
2. 必须修改的问题
3. 建议修改但不阻塞的问题
4. 需要人工确认的问题
5. 建议补充的测试用例
6. 如果要改，只给最小 patch 思路
这个模板的重点是最后一句：
请不要直接重写代码。
AI 很容易从 Review 变成“帮你重构一下”。
但 Review 的目标不是让代码变得“更像 AI 喜欢的样子”，而是判断这次改动能不能安全合并。
4. 一个更适合掘金读者的 AI Review 提示词
你可以直接复制这段：
你现在是一个严格但克制的 Code Reviewer。
请基于我提供的 REVIEW_PACKET 做代码审查。
审查规则：
1. 只围绕本次 PR 目标和 diff 做判断
2. 不要提出和本次目标无关的大范围重构
3. 不要因为“风格更好”就建议改动
4. 优先发现会导致线上问题的风险
5. 对不确定的地方标注“需要人工确认”
6. 如果建议修改，请说明原因、影响范围和最小改法
7. 如果测试不足，请给出应该补充的测试场景
输出格式：
## 总体结论
一句话说明是否建议合并。
## 阻塞问题
列出必须修改的问题，没有就写“暂无”。
## 风险点
列出可能影响线上行为、历史兼容、权限、安全、数据一致性的风险。
## 测试建议
列出建议补充的测试用例。
## 非阻塞建议
只列真正有价值的建议，不要泛泛建议重构。
这个提示词比“帮我 Review 一下”稳定很多。
因为它提前限制了 AI 的角色、范围和输出格式。
5. 一个真实一点的例子
假设你这次改的是一个订单详情页。
原代码：
function getOrderStatusText(order: Order) {
return statusMap[order.status] || "未知状态";
}
export function OrderDetail({ order }: { order: Order }) {
return (
<div>
<h1>订单详情</h1>
<p>{getOrderStatusText(order)}</p>
</div>
);
}
为了修复空白页，你改成：
function getOrderStatusText(order?: Order | null) {
if (!order) {
return "订单不存在";
}
return statusMap[order.status] || "未知状态";
}
export function OrderDetail({ order }: { order?: Order | null }) {
return (
<div>
<h1>订单详情</h1>
<p>{getOrderStatusText(order)}</p>
</div>
);
}
你直接问 AI：
帮我看看这样改有没有问题。
它可能会说：
建议把 getOrderStatusText 改成 useMemo，或者封装成独立组件。
这不一定错，但不是最关键的问题。
如果你用 Review Packet，它更可能检查到：
order为空时展示“订单不存在”是否符合产品预期- 是否应该区分“订单不存在”和“接口加载中”
- 是否会影响原来必须传入
Order的组件类型约束 - 上层调用方是否也需要处理 loading / error 状态
- 是否需要补一个 order 为 null 的测试用例
这才是 Code Review 真正有价值的地方。
6. 可以顺手加一个小脚本
如果你经常让 AI 做 Review，可以写一个简单脚本自动生成基础材料。
新建：
touch make_review_packet.sh
chmod +x make_review_packet.sh
写入：
#!/usr/bin/env bash
set -e
BASE_BRANCH=${1:-main}
OUT_FILE=${2:-REVIEW_PACKET.md}
echo "# AI Code Review Packet" > "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 1. PR 目标" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "请在这里填写本次 PR 要解决的问题、业务背景和限制条件。" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 2. 改动文件" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo '```text' >> "$OUT_FILE"
git diff --name-only "$BASE_BRANCH"...HEAD >> "$OUT_FILE" || true
echo '```' >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 3. 改动统计" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo '```text' >> "$OUT_FILE"
git diff --stat "$BASE_BRANCH"...HEAD >> "$OUT_FILE" || true
echo '```' >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 4. 核心 Diff" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo '```diff' >> "$OUT_FILE"
git diff "$BASE_BRANCH"...HEAD >> "$OUT_FILE" || true
echo '```' >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 5. 测试结果" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "请粘贴测试命令和结果，例如 pnpm test、npm test、pytest、go test ./... 等。" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "## 6. 希望 AI 重点检查" >> "$OUT_FILE"
echo "" >> "$OUT_FILE"
echo "- 是否偏离 PR 目标" >> "$OUT_FILE"
echo "- 是否改变原有接口结构" >> "$OUT_FILE"
echo "- 是否漏掉异常分支" >> "$OUT_FILE"
echo "- 是否存在权限、安全、空值、并发风险" >> "$OUT_FILE"
echo "- 是否需要补充测试用例" >> "$OUT_FILE"
echo "Generated $OUT_FILE"
运行：
./make_review_packet.sh main REVIEW_PACKET.md
如果你的主分支叫 master：
./make_review_packet.sh master REVIEW_PACKET.md
生成后，你只需要补上 PR 目标和测试结果，就可以发给 AI 做 Review。
7. 这套方法适合哪些场景
比较适合：
前端组件改动；
接口返回结构调整；
表单校验逻辑；
Node.js / Java / Go / PHP 后端接口；
React / Vue / Next.js 页面逻辑；
测试用例补充；
小范围重构；
PR 合并前自查。
不太适合直接交给 AI 决策：
权限系统大改；
支付链路；
数据库迁移；
生产部署脚本；
核心加密逻辑；
复杂并发问题；
跨服务链路改造。
这些不是不能让 AI 看，而是不能让 AI 直接拍板。
AI 可以帮你列风险，但最终合不合，要人来判断。
8. AI Review 最容易踩的 3 个坑
坑 1：让 AI 追求“更优雅”
很多 AI Review 会倾向于让代码更抽象、更整洁。
但真实项目里，有些“不优雅”是历史兼容。
比如旧接口不能改字段名，老用户数据不能清理，某些 if 判断是为了兼容早期版本。
所以你要明确告诉 AI：
不要因为代码风格不够优雅就建议重构。除非它会导致 bug、风险或维护困难。
坑 2：不告诉 AI 测试结果
只看 diff，不看测试结果，Review 容易停在表面。
至少告诉 AI：
pnpm test 是否通过
npm run build 是否通过
接口测试是否通过
手动验证了哪些路径
哪些路径还没测
尤其是“哪些路径还没测”，对 AI 很重要。
它可以帮你补测试清单。
坑 3：让 AI 直接改最终代码
我更建议让 AI 先输出 Review 结论，再由你决定是否修改。
如果确实要它改，也要限制：
只针对阻塞问题给出最小 patch，不要顺手重构，不要改无关文件。
AI 写代码很快，但线上事故不会因为“是 AI 写的”就少背锅。
9. 关于工具本身
这套方法不绑定某一个工具。
你用 ChatGPT、Claude、Cursor、Kiro 都可以。Cursor 更适合结合编辑器和 diff 继续处理；Claude / ChatGPT 更适合先做 Review 分析；Kiro 适合把需求、任务和改动边界拆清楚。
如果你长期使用 ChatGPT Plus、Claude Pro、Grok、Gemini Advanced、Cursor、Kiro 这类工具，也可以顺手了解 gpt68.com。它是 AI会员充值平台，可以作为 AI 工具订阅充值入口之一。
但还是那句话：工具只是入口，真正决定效果的是你给 AI 的材料质量。
10. 验证范围说明
上面的 Git 命令属于常规 Git 工作流命令，适用于已经初始化 Git 仓库的项目。
脚本逻辑做了语法检查，使用场景如下：
项目必须是 Git 仓库；
本地需要安装 Git；
默认对比 main 分支；
如果主分支是 master，需要手动传参；
如果当前分支没有相对 main 的改动，生成的 diff 会为空；
如果项目没有提交历史，部分命令可能没有输出。
实际项目中，建议生成 REVIEW_PACKET.md 后人工看一眼，尤其注意不要把敏感信息、内部域名、真实 token、用户数据放进去。
11. 总结
AI 做 Code Review，不是把整个项目扔过去让它“自由发挥”。
更稳的方式是：
告诉它这次 PR 要解决什么；
只给它看本次改动；
补充测试结果；
限制它不要乱重构；
让它重点找风险、边界和遗漏测试。
很多时候，AI 不是不懂代码，而是你给它的信息太散。
把 Review Packet 准备好，它就更像一个认真看 PR 的同事；
不准备上下文，它就更像一个刚进项目、但话很多的新人。
对开发者来说，这可能才是 AI 编程时代最值得练的能力：不是让 AI 写更多代码，而是让 AI 更准确地参与工程判断。
