这一章讲的是 vibecoding 里最容易被忽略的一步：审查。
AI 编程助手会写代码，但你不能因为它写完了就立刻提交。你需要学会让它自己先审一遍，再由你做最后判断。
学完这一章，你应该能做到：
- 让 AI 编程助手审查自己的改动；
- 发现明显 bug、无关修改和风险文件；
- 在提交前先看清楚 diff；
- 把“完成”变成“可验证的完成”。
如果还没有打开可用的 AI 编程工具，先按第一章从官网安装并完成第一个练习，再继续这一章。
本章可直接复制的提示词
你要做的事：AI 改完后，先让它审查 diff，不要马上提交。
【可直接复制给 AI】
请审查当前修改，不要继续改任何文件。
我的原始需求是：
（写下这次让你修改的目标）
请直接告诉我：
1. 这次改了哪些文件；
2. 每个文件是否和原始需求有关；
3. 有没有无关修改；
4. 有没有高风险改动；
5. 我应该运行什么命令验证；
6. 是否建议提交。
如果你不确定测试是否通过，请明确说“未验证”，不要说已经通过。
【说明】
- AI 会列出修改文件；
- 帮你找无关修改和风险点；
- 告诉你提交前该运行什么验证命令。
不满意继续这样问：
请不要总结成“看起来没问题”。
逐个文件说明：
1. 为什么要改；
2. 是否必要；
3. 有没有风险。
9.1 为什么 AI 编程工具改完代码后，不能马上提交
很多新手用 AI 编程工具最大的问题，不是不会让它写代码，而是它写完以后直接信了。
你让 AI 编程工具修一个按钮。
它说：
已完成修改。
你让 AI 编程工具修一个接口。
它说：
问题已修复。
你让 AI 编程工具改一个页面。
它说：
已优化页面布局。
很多人看到这句话就准备提交。
这很危险。
因为 AI 编程工具说“完成了”，只代表它认为完成了。
不代表：
它只改了该改的文件
它没有删掉原有逻辑
它没有编造数据
它没有改错价格
它没有引入新依赖
它没有让移动端崩掉
它没有让 build 失败
它没有让接口返回结构变了
所以第九章要讲一个非常重要的工作流：
AI 编程工具写完代码后，再让 AI 编程工具审查代码。
听起来像“让它自己检查自己”，但真正的做法不是让它随便夸自己，而是让它按一套固定标准审查：
看 diff
看范围
看风险
看测试
看无关修改
看安全问题
看能不能提交
这章会结合几个真实场景：
AI Chatbot 接口修完后怎么审
shadcn 页面改完后怎么审
Pricing 区域改完后怎么审
Auth 登录逻辑改完后怎么审
vibe coding 项目改完后怎么审
怎样让 AI 编程工具审查 GitHub PR
你要记住一句话：
让 AI 编程工具写代码只是第一步，让 AI 编程工具找它可能写错的地方，才是专业用法。
9.2 先做一个“代码审查 Skill”
和前面一样，这一章也可以做一个 Skill。
名字可以叫：
diff-review-doctor
中文叫：
代码改动审查 Skill
这个 Skill 的作用是：
每次 AI 编程工具改完代码后，强制它按同一套标准检查 diff。
它不负责继续写功能。
它只负责审查：
这次改动有没有越界。
Skill 内容示例
# 代码改动审查 Skill
当 AI 编程工具修改了代码、页面、接口、配置、文档或测试后，必须使用本 Skill 审查 git diff。
## 目标
判断这次改动是否安全、是否和需求一致、是否存在无关修改、是否可以提交。
## 审查顺序
1. 先读取 git diff，不要继续修改文件。
2. 总结本次改动涉及哪些文件。
3. 判断每个文件是否和原始需求直接相关。
4. 检查是否修改了无关文件。
5. 检查是否新增依赖或修改 lock 文件。
6. 检查是否修改了价格、套餐、支付、登录、权限、API Key、环境变量。
7. 检查是否引入硬编码、真实密钥或编造数据。
8. 检查是否可能影响移动端、构建、测试或接口返回结构。
9. 检查是否需要运行 build、test、lint。
10. 最后给出是否建议提交。
## 输出格式
- 改动摘要：
- 修改文件列表：
- 每个文件是否必要：
- 高风险改动：
- 无关修改：
- 需要人工确认的内容：
- 建议运行的验证命令：
- 是否建议提交：
- 提交前必须修复的问题：
## 禁止事项
- 不要继续修改代码。
- 不要只说“看起来没问题”。
- 不要忽略 package.json 和 lock 文件。
- 不要忽略 .env、auth、payment、pricing、API 文件。
- 不要替用户决定合并。
- 不要编造测试已经通过。
不做 Skill，也可以直接复制这段提示词
请作为代码审查助手，审查当前 git diff。
要求：
1. 不要继续修改任何文件
2. 总结修改了哪些文件
3. 判断每个文件是否和原始需求直接相关
4. 找出无关修改
5. 找出高风险修改
6. 检查是否修改了 package.json、lock 文件、环境变量、登录、支付、价格、API
7. 检查是否有编造数据或硬编码密钥
8. 给出需要运行的验证命令
9. 最后判断是否建议提交
输出格式：
- 改动摘要：
- 修改文件列表：
- 每个文件是否必要：
- 高风险改动：
- 无关修改：
- 需要人工确认的内容：
- 建议运行的验证命令：
- 是否建议提交：
- 提交前必须修复的问题：
9.3 案例一：AI 编程工具改了首页，但它是不是偷偷改多了？
第一个案例，接着第七章的页面改造。
你让 AI 编程工具优化首页首屏。
原始需求是：
只优化首页 Hero 文案和按钮布局。
结果 AI 编程工具改完后说：
已完成首页优化。
这时候不要直接满意。
你要先看它到底改了什么。
让 AI 编程工具审查 diff
请审查当前 git diff。
原始需求是：
只优化首页 Hero 文案和按钮布局。
请判断：
1. 这次修改涉及哪些文件
2. 每个文件是否和 Hero 文案、按钮布局直接相关
3. 是否修改了无关组件
4. 是否修改了全局样式
5. 是否修改了真实价格、套餐、链接或数据
6. 是否影响移动端
7. 是否建议提交
不要继续修改文件。
它应该重点检查什么
如果是首页改造，它应该关注：
首页页面文件
Hero 组件
Button 调用方式
全局 CSS
数据文件
Pricing 文件
导航链接
CTA 链接
移动端 className
如果它发现改了：
package.json
tailwind.config.ts
src/data/pricing.ts
src/app/api/*
就要警惕。
因为原始需求只是改 Hero。
这些文件大概率不该动。
让 AI 编程工具判断是否越界
请把这次修改分成三类：
A. 和需求直接相关
B. 可能相关，但需要人工确认
C. 明显无关，建议回滚
请按文件列出。
这种分类非常实用。
它会把一堆 diff 变成能看懂的清单。
如果发现无关修改
继续问：
请给出无关修改的回滚建议。
要求：
1. 不要直接执行回滚
2. 说明每个建议回滚文件的原因
3. 如果某个文件不确定，请标记“需要人工确认”
然后你可以自己用：
git restore 文件名
或者在 IDE 里手动撤销。
9.4 案例二：AI Chatbot 接口修完了，要检查有没有泄露 Key
第二个案例，接着第八章的 AI Chatbot 接口报错。
你让 AI 编程工具修了 /api/chat 的 500 问题。
它可能改了：
app/api/chat/route.ts
lib/ai/provider.ts
.env.example
lib/models.ts
这类改动一定要审。
因为 AI Chatbot 涉及：
API Key
模型名
Base URL
流式响应
用户输入
错误返回
上游接口
这里最怕的不是代码不优雅，而是安全和配置出问题。
审查提示词
请审查这次 AI Chatbot 接口修改。
原始需求是：
修复 /api/chat 返回 500 的问题。
请重点检查：
1. 是否把 API Key 写进代码
2. 是否把密钥输出到日志
3. 是否修改了模型名或 provider
4. 是否修改了 Base URL
5. 是否改变了请求体格式
6. 是否改变了前端依赖的返回结构
7. 是否对上游错误做了友好处理
8. 是否新增了不必要依赖
9. 是否需要更新 .env.example
不要继续修改文件，只输出审查结果。
它应该给出的审查重点
合理的审查结果应该关注：
密钥是否硬编码
错误日志是否泄露敏感信息
模型配置是否来自环境变量
返回格式是否保持兼容
stream 是否仍然正常
前端是否还能读取响应
.env.example 是否只写占位符
不应该只说：
代码看起来没问题。
你要逼它具体。
让 AI 编程工具生成接口验证清单
请给这次 /api/chat 修改生成验证清单。
要求包含：
1. 无 API Key 时的错误提示
2. API Key 错误时的错误提示
3. 模型名错误时的错误提示
4. 正常聊天是否可用
5. 前端是否能显示回复
6. 服务端日志是否不泄露密钥
7. build 是否通过
翻车点
错误问法：
接口修好了吧？
更好的问法：
请证明这次接口修改没有泄露密钥、没有改变返回格式、没有影响前端显示。
9.5 案例三：Pricing 改完后，先查价格有没有被动过
第三个案例，接着第七章 Pricing 区域。
你让 AI 编程工具优化 Pricing 展示。
原始需求是：
只优化 Pricing UI，不修改真实价格和套餐权益。
但 AI 编程工具有时会“顺手优化文案”。
比如把：
$19 / month
改成：
$9 / month
或者把：
10,000 requests
改成：
Unlimited requests
这就是大事故。
审查提示词
请审查这次 Pricing 修改。
原始需求是：
只优化 Pricing 区域展示，不修改真实价格、套餐权益、购买链接和支付逻辑。
请重点检查：
1. 价格有没有变化
2. 套餐名称有没有变化
3. 套餐权益有没有变化
4. 购买按钮链接有没有变化
5. 推荐套餐标记有没有变化
6. 是否修改了支付相关文件
7. 是否修改了 API 文件
8. 是否修改了数据文件
9. 是否只改了展示组件
不要继续修改文件。
让 AI 编程工具输出对照表
请把 Pricing 修改前后的关键信息做对照表：
字段：
修改前：
修改后：
是否允许修改：
风险等级：
重点包括：
- 套餐名
- 价格
- 额度
- 权益
- CTA 链接
- 推荐标记
这个表非常适合给新手看。
因为价格和权益是肉眼最容易漏的。
如果发现被改了
继续问：
价格或权益被修改了。
请给出只回滚数据变化、保留 UI 样式优化的方案。
不要直接执行。
9.6 案例四：Auth 登录逻辑改完后，要查有没有绕过权限
第四个案例，登录和权限。
你让 AI 编程工具修登录 401 / 403。
它可能改了：
auth.ts
middleware.ts
app/api/auth/*
lib/auth/*
这类文件一定要谨慎。
因为登录代码不是普通 UI。
它可能影响：
谁能登录
谁能访问后台
谁能调用 API
Session 是否安全
Cookie 是否安全
生产环境是否安全
审查提示词
请审查这次 Auth / 登录相关修改。
原始需求是：
修复登录失败问题，不降低安全性。
请重点检查：
1. 是否绕过了权限判断
2. 是否临时关闭了 middleware
3. 是否把 protected route 放开了
4. 是否降低了 cookie 安全配置
5. 是否把 secret 写死在代码里
6. 是否把错误信息暴露得太详细
7. 是否影响生产环境登录
8. 是否只修复了本地环境问题
9. 是否需要区分 dev 和 production
不要继续修改文件，只输出风险。
高风险信号
如果 AI 编程工具改了这些，要非常小心：
return true
跳过 auth check
注释掉 middleware
允许所有用户访问
删除 CSRF 检查
关闭 secure cookie
把 secret 写死
把用户 token 打印到日志
这些都不是“修 bug”，而是可能把门拆了。
让 AI 编程工具给安全结论
请把这次 Auth 修改分成：
安全改动：
需要人工确认：
高风险改动：
建议回滚：
并说明每一项原因。
翻车点
错误问法：
登录修好了就行。
正确问法：
登录修好以后，请确认没有降低鉴权、安全 cookie、middleware 和 protected route 的安全性。
9.7 案例五：vibe coding 项目改完后，检查有没有“看起来能跑，其实不可维护”
很多 vibe coding 工具生成的项目，第一眼很惊艳。
但继续改几轮后，容易出现：
组件越来越大
重复代码越来越多
状态管理越来越乱
样式 className 超长
没有类型定义
没有错误处理
没有 loading 状态
没有空状态
没有测试
你让 AI 编程工具改完一个功能后，不要只检查“能不能跑”。
还要检查：
这次改动会不会让项目更难维护。
审查提示词
这是一个 vibe coding 生成项目，刚刚用 AI 编程工具改了一轮功能。
请审查当前 git diff。
重点检查：
1. 是否让组件变得过大
2. 是否新增了重复代码
3. 是否把业务逻辑塞进 UI 组件
4. 是否缺少 loading / error / empty 状态
5. 是否硬编码数据
6. 是否有明显类型问题
7. 是否有未来维护风险
8. 是否需要抽出小组件或工具函数
注意：
- 不要为了重构而重构
- 只指出高价值问题
- 不要继续修改文件
让 AI 编程工具给维护性评分
请给这次改动做维护性评分。
评分维度：
1. 改动范围是否克制
2. 组件是否清晰
3. 状态处理是否完整
4. 错误处理是否完整
5. 是否引入重复代码
6. 是否方便后续继续开发
每项 1-5 分，并说明扣分原因。
不要让它挑一堆小毛病
AI 审查很容易挑细枝末节。
比如：
变量名可以更语义化
注释可以更完整
样式可以更统一
这些不是不能看，但新手会被淹没。
你要限制它：
只指出会影响运行、安全、维护、转化或后续开发的高价值问题。
不要输出纯风格偏好。
9.8 案例六：让 AI 编程工具审查 GitHub PR，但人要最后拍板
如果你已经把项目推到 GitHub，并且开了 PR，可以让 AI 编程工具做 PR 审查。
这适合：
PR 改动文件多
自己看 diff 看累了
想让 AI 编程工具先找风险
想让 AI 编程工具总结修改内容
想让 AI 编程工具检查有没有漏测试
但你要记住：
AI 审查不是最终审批。
它是第一轮筛查。
最后仍然要你自己判断。
适合交给 AI 初审的 PR
适合：
文案改动
README 改动
页面展示改动
小功能修复
API 错误处理
测试补充
构建配置小改
不太适合完全交给它的：
支付逻辑
登录鉴权
数据库迁移
权限模型
计费逻辑
生产部署配置
安全策略
这些可以让它辅助看，但不能让它直接决定合并。
PR 审查提示词
可以在 PR 里这样写：
请审查这次 PR 的改动。如果工具无法读取 PR，请先把改动内容复制到对话里。
请重点检查：
1. 是否有无关修改
2. 是否有安全风险
3. 是否影响 API 返回结构
4. 是否修改了价格、支付、登录或权限
5. 是否缺少测试或验证步骤
6. 是否有明显移动端问题
7. 是否建议合并
请只指出高价值问题，不要输出纯风格偏好。
如果 AI 编程工具给了很多评论
不要马上全部照做。
先让它分级：
请把这些 review comments 分成：
P0：必须修，否则不能合并
P1：建议修，影响质量
P2：可选优化，不影响合并
并说明原因。
这样你不会被一堆小建议拖死。
如果它说没有问题
也不能直接信。
你可以【继续追问】
请再从反方向检查一次：
1. 这次 PR 最可能隐藏的风险是什么
2. 哪个文件最值得人工复查
3. 哪个改动最可能影响线上
4. 哪个验证命令必须运行
9.9 案例七：让 AI 编程工具写提交说明，但不要让它美化问题
代码审查完后，下一步通常是提交。
AI 编程工具很适合帮你写：
commit message
PR title
PR description
变更摘要
测试说明
风险说明
但它也有一个问题：
它喜欢把事情写得太完美。
比如它可能写：
彻底优化了页面体验，全面提升稳定性。
这种话太虚。
更好的提交说明应该具体：
优化首页 Hero 文案和 CTA 按钮布局，移动端按钮改为纵向排列。
提示词：生成 commit message
请根据当前 git diff 生成 5 个 commit message 备选。
要求：
1. 简短
2. 具体
3. 不夸大
4. 不写没有发生的事
5. 使用中文
6. 不要包含“全面优化”“大幅提升”这类空话
提示词：生成 PR 描述
请根据当前 git diff 生成 PR 描述。
格式：
## 修改内容
## 修改原因
## 验证方式
## 风险点
## 需要人工确认
要求：
1. 只写 diff 里真实发生的事
2. 不编造测试已经通过
3. 如果测试没有运行，要写“未运行”
4. 如果有风险，要明确写出来
5. 不要美化问题
推荐 PR 描述风格
## 修改内容
- 调整首页 Hero 文案
- 优化 CTA 按钮在移动端的排列
- 保留原有按钮链接和业务逻辑
## 修改原因
首页首屏表达不够清楚，移动端按钮挤在一起。
## 验证方式
- 已运行 npm run build
- 已检查桌面端和移动端页面
- 已确认按钮链接未变化
## 风险点
- 主要是展示层修改，风险较低
- 仍需人工确认最终文案是否符合产品定位
## 需要人工确认
- Hero 标题是否符合品牌表达
- CTA 文案是否符合转化目标
翻车点
不要让 AI 编程工具写这种 PR 描述：
本 PR 全面提升了用户体验和系统稳定性。
这句话听起来好，但没信息量。
更好的要求：
请只描述真实 diff，不要写营销式总结。
9.10 本章通用模板
下面这些可以直接复制。
模板一：审查当前 diff
请作为代码审查助手，审查当前 git diff。
要求：
1. 不要继续修改任何文件
2. 总结修改了哪些文件
3. 判断每个文件是否和原始需求直接相关
4. 找出无关修改
5. 找出高风险修改
6. 检查是否修改了 package.json、lock 文件、环境变量、登录、支付、价格、API
7. 检查是否有编造数据或硬编码密钥
8. 给出需要运行的验证命令
9. 最后判断是否建议提交
输出格式：
- 改动摘要：
- 修改文件列表：
- 每个文件是否必要：
- 高风险改动：
- 无关修改：
- 需要人工确认的内容：
- 建议运行的验证命令：
- 是否建议提交：
- 提交前必须修复的问题：
模板二：首页改造后审查
请审查当前 git diff。
原始需求是：
只优化首页 Hero 文案和按钮布局。
请判断：
1. 是否只修改了相关文件
2. 是否修改了无关组件
3. 是否修改了全局样式
4. 是否修改了价格、链接、数据或 API
5. 是否可能影响移动端
6. 是否建议提交
不要继续修改文件。
模板三：AI Chatbot 接口修改后审查
请审查这次 AI Chatbot 接口修改。
原始需求是：
修复 /api/chat 返回 500 的问题。
请重点检查：
1. 是否把 API Key 写进代码
2. 是否把密钥输出到日志
3. 是否修改了模型名或 provider
4. 是否修改了 Base URL
5. 是否改变了请求体格式
6. 是否改变了前端依赖的返回结构
7. 是否对上游错误做了友好处理
8. 是否需要更新 .env.example
不要继续修改文件。
模板四：Pricing 修改后审查
请审查这次 Pricing 修改。
原始需求是：
只优化 Pricing 展示，不修改真实价格、套餐权益、购买链接和支付逻辑。
请重点检查：
1. 价格有没有变化
2. 套餐名称有没有变化
3. 套餐权益有没有变化
4. 购买按钮链接有没有变化
5. 是否修改了支付相关文件
6. 是否修改了 API 文件
7. 是否只改了展示组件
不要继续修改文件。
模板五：Auth 修改后审查
请审查这次 Auth / 登录相关修改。
原始需求是：
修复登录失败问题，不降低安全性。
请重点检查：
1. 是否绕过了权限判断
2. 是否临时关闭了 middleware
3. 是否把 protected route 放开了
4. 是否降低了 cookie 安全配置
5. 是否把 secret 写死在代码里
6. 是否把 token 打印到日志
7. 是否影响生产环境登录
8. 是否需要区分 dev 和 production
不要继续修改文件，只输出风险。
模板六：vibe coding 项目维护性审查
这是一个 vibe coding 生成项目，刚刚用 AI 编程工具改了一轮功能。
请审查当前 git diff。
重点检查：
1. 是否让组件变得过大
2. 是否新增重复代码
3. 是否把业务逻辑塞进 UI 组件
4. 是否缺少 loading / error / empty 状态
5. 是否硬编码数据
6. 是否有类型问题
7. 是否有未来维护风险
只指出高价值问题，不要输出纯风格偏好。
不要继续修改文件。
模板七：PR 审查请求
请审查这次 PR 的改动。如果工具无法读取 PR，请先把改动内容复制到对话里。
请重点检查：
1. 是否有无关修改
2. 是否有安全风险
3. 是否影响 API 返回结构
4. 是否修改了价格、支付、登录或权限
5. 是否缺少测试或验证步骤
6. 是否有明显移动端问题
7. 是否建议合并
请只指出高价值问题，不要输出纯风格偏好。
模板八：生成 PR 描述
请根据当前 git diff 生成 PR 描述。
格式：
## 修改内容
## 修改原因
## 验证方式
## 风险点
## 需要人工确认
要求：
1. 只写 diff 里真实发生的事
2. 不编造测试已经通过
3. 如果测试没有运行，要写“未运行”
4. 如果有风险，要明确写出来
5. 不要美化问题
9.11 本章总结
用 AI 编程工具写代码很爽，但专业工作流不是：
写完就提交。
而是：
写完先审。
这章你要记住 7 个重点：
第一，AI 编程工具说“完成了”，不代表真的安全。
第二，每次改完都要看 git diff。
第三，要检查无关修改，而不是只看功能有没有实现。
第四，涉及 API Key、登录、支付、价格、权限的改动必须重点审。
第五，vibe coding 项目不只要能跑，还要看能不能维护。
第六，GitHub PR 可以让 AI 编程工具先审查，但最后要人决定。
第七，PR 描述要写真实 diff，不要写营销话。
最终推荐流程：
AI 编程工具修改代码
查看 git diff
使用代码审查 Skill
分类风险
回滚无关修改
运行 build / test / lint
让 AI 编程工具生成 PR 描述
人工最后确认
再提交或合并
本章最重要的一句话：
AI 写代码越快，人越要会审代码。
下一章可以继续讲：
任务太长时，如何把需求拆成“先调查、再修改、最后验收”的小步，并在每一步检查 AI 编程工具的结果。