代码质量与审查
AI 写得快，但会犯错——还会“看起来很确定地”犯错。 这一章教你不是去相信 AI 的代码，而是去验收它。
你将学会
- 说清 AI 代码最典型的几类缺陷；
- 用最小测试与手动回归清单验证功能；
- 跑 lint / 类型检查并看懂它们的报错；
- 用「六项检查」接住每一次改动；
- 换一双眼睛做独立审查。
前置知识
Vibe Coding 入门教程（尤其是“接受前先审查”一节）与调试与排错手册。
一、为什么 AI 代码必须审查
AI 代码的问题不在“跑不起来”，而在跑起来了但不对：
| 缺陷类型 | 表现 |
|---|---|
| 幻觉 API | 用了不存在的函数/参数，或记错了参数顺序 |
| 边界缺失 | 空输入、超长输入、重复操作没处理 |
| 静默吞错 | try/catch 什么都不做，出错不报 |
| 硬编码 | 把地址、密钥、魔数写死在代码里 |
| 安全疏漏 | 不校验输入、权限判断缺失、危险命令拼接 |
| 过度依赖 | 为一个功能引入一堆没必要的库 |
核心原则：能复现的行为才算“完成”，AI 说“完成了”不算。
二、测试入门
不必一上来就写完美的测试。按这个优先级来：
- 先有回归清单：把验收标准写成几条“手动怎么验”的步骤（见从想法到需求）。
- 修 bug 先写测试：能复现的 bug，先写一条会失败的测试，再修——修完测试通过，说明真的修好了。
- 关键路径写单测：核心计算、数据处理这类“错了很难发现”的地方，写最小单测。
text
# 一条最小测试该回答的问题
输入什么 → 期望什么 → 实际什么 → 一致吗三、lint 与类型检查
- lint：检查代码格式与潜在问题的工具（拼写、未使用变量、可疑写法）。命令通常是
npm run lint。 - 类型检查：检查数据类型是否一致（TypeScript 等）。命令通常是
npm run typecheck或tsc --noEmit。
它们的报错不要一律让 AI 关掉规则——规则存在是有原因的。先读懂报错，再决定是改代码还是真有例外。
四、六项检查（详版）
每次接受 AI 的改动前过一遍：
- 读摘要：它改了什么、为什么这么改？
- 看 diff：
git diff，有没有无关重构、删除、新依赖？ - 跑检查：测试 / lint / 类型检查 / 构建，真实执行且通过。
- 实际操作：按验收标准亲手走一遍主流程和失败流程。
- 安全检查：有没有密钥、任意命令执行、未校验输入、过宽权限？（详见安全与合规）
- 小步提交：一个可说明的行为 → 一次可回退的提交。
五、独立审查
自己审容易带着“我刚才想让它这么改”的预设。换一双眼睛：
- 打开一个新会话，只把 diff 交给它，要求只审不改、按严重程度列问题、给证据；
- 或用子代理 / 独立审查代理并行来做；
- 审查的结论要落到具体位置（文件 + 行）和证据，不接收“看起来没问题”。
六、AI 代码常见坑清单
- 有没有把地址、密钥、ID 写死？
catch里是不是空着 / 只打印不处理？- 输入为空、超长、非法类型时会发生什么？
- 有没有为了一个小功能引入大依赖？
- 重复代码是不是该抽出来？
- 错误提示能不能看懂、是不是中文？
- 有没有“只在某个环境下能跑”的假设？
动手练习
- 拿一段 AI 生成的代码，用六项检查走一遍，产出 findings 清单（位置 + 问题 + 证据）。
- 为一个会复现的 bug 先写一条失败测试，再修复它。
- 开一个新会话，让它只审你当前的
git diff，把它的结论与原实现对照。
检查点
- 能在不看实现的前提下，仅凭验收标准判断“是否完成”；
- 能跑通 lint / 类型检查 / 测试，并读懂它们的报错；
- 能对一次改动给出一份带位置与证据的审查结论。
常见问题
Q：小项目也要写测试吗？ 第一个项目回归清单就够。但只要出现“修好了又坏”的情况，就该补一条自动化测试。
Q：AI 说测试过了，我还用跑吗？ 用。声称执行不等于执行。你必须亲自跑一次，看到输出里的“通过”才算数。
小结与下一步
质量靠流程，不靠信任。下一步把项目交付出去：部署与上线。