代码跑通了就敢提交？跑得通，只是及格线。

上一篇给代码装了安全网——单元测试。测试好用，但有天然盲区：

测试只查”结果对不对”，管不了”这么写行不行”。

举几个例子：数据库密码直接写代码里——测试全绿，直到代码被人看到；用户输入搜索词原样拼进查询——测试全绿，直到有人输入带引号的东西拖走整个库；报错时完整堆栈返回前端——测试全绿，同时把目录结构、表名全告诉别人；循环里每转一圈查一次库——测试全绿，上线 100 条数据就查 100 次。

共同点：功能全对、测试全绿，但这些代码全都迟早出事。 这类问题传统靠 Code Review（代码审查）——提交前让更有经验的同事看一遍。可你要是没有那个同事呢？ 个人开发、小团队、外包、刚入行，绝大多数人根本没有”更有经验的同事”随时帮你看。

这一篇，教你怎么把 AI 变成那个同事。

一、为什么直接说”帮我 review”，得到全是废话

先做个实验。把代码丢给 AI 说”帮我 review 一下”，它八成给你：

“整体结构清晰，命名较规范。建议：1. 添加更多注释 2. 考虑增加错误处理 3. 变量命名更语义化 4. 考虑可扩展性……”

看着像回事，实际一条没用。 这些话对任何代码都成立，等于没说。你真正想知道的”我这段代码有没有要命的坑”，它一个字没提。

你没告诉它「按什么标准看」，它只能给你放之四海皆准的空话。

破法只有一个：给 AI 一张检查清单，逼它逐项过。 像医院体检——你说”帮我看看身体”，医生只能”注意休息多喝水”；你递上 20 项体检单，他就得一项项出数值。

二、Review 五关：正、安、错、洁、快

那清单该有什么？把新手最容易踩、后果最严重的问题归成五个关卡，口诀：正、安、错、洁、快。注意顺序就是优先级，越靠前越致命。

第一关：正（正确性）

功能是不是真的对？ 逻辑判断搞反（该”大于等于”写成”大于”）、边界漏了（正好等于阈值呢？）、算错（浮点直接比相等、金额用小数存）。这一关和上篇”四靶”一套东西，测试从外面验，review 从里面看。

第二关：安（安全）

最易被新手忽略，也是唯一”出事就没法挽回”的关卡。 三大高发死法点名：

① 密钥硬编码 数据库密码、API 密钥、token 直接写代码。代码被人看到（同事、外包、公开仓库、截图发群）密钥就泄。正确做法：放配置文件或环境变量，确保那文件不被一起提交。

② 用户输入直接拼进指令 把用户填的内容原样拼进查询语句、系统命令、文件路径。用户填的不一定是”数据”也可能是”指令”，这是绝大多数数据泄露源头。正确做法：用参数化传值，不是字符串拼接。

③ 敏感信息进日志或返回前端 把密码、身份证、手机号打进日志；把完整报错堆栈返前端。报错信息通常含文件路径、表名、框架版本——等于给别人画了张地图。 正确做法：详细报错记服务器日志，返前端的只有一句”操作失败，请稍后重试”。

第三关：错（异常处理）

顺利时都对，出问题呢？ 网络请求没设超时（对方不响应就永远卡）、取可能不存在字段没判空（直接崩）、除法没防除零、捕获异常却什么都不做（第 75 篇”假成功”，最阴险的 bug）。→ 一句话：凡”跟外面打交道”的地方（网络、库、文件、第三方），都必须假设它会失败。

第四关：洁（整洁）

就是第 77 篇「重构六味」：长、重、名、套、魔、杂。重要但不致命，排在安全和异常后面。

第五关：快（性能）

第 78 篇内容，只盯几个”一眼看出”的：循环里查库（N+1，头号元凶）、循环里发网络请求、一次读海量数据进内存、能批却不批。性能排最后，因为按”优化三问”，没测量前性能建议大多是猜的。

五关速查表：

三、提示词怎么写：四个关键技巧

清单有了，还得会问。四招决定 AI 给干货还是废话。

技巧一：禁止它夸你。 AI 改不掉先夸三句再说问题的毛病，夸完语气变软，”必须改”变成”可以考虑优化一下”，你一看就先不改了。直接堵死：“不要评价优点，不要写总结性褒奖，只挑问题。”

技巧二：要求按严重程度分级。 AI 一口气给 15 条全平铺，你分不清哪条”今天不改明天出事”哪条”改不改都行”。要求分三档：

• 🔴 必须改（安全漏洞、逻辑错、必崩空值）
• 🟡 建议改（不立刻出事，但欠债）
• 🟢 可以不改（纯风格）然后只处理红和黄，绿的直接跳过，15 条变 4 条，人不慌。

技巧三：每条必须给”四件套”。 要求每条含：1. 在哪（第几行/哪个函数）2. 什么问题（一句话）3. 为什么是问题（会造成什么后果，最关键）4. 怎么改（给改后代码）。第 3 条是过滤器——逼 AI 说清后果，一大半凑数假问题当场露馅。

技巧四：允许它说”没问题”。 AI 有强烈”必须交作业”倾向，你让它挑毛病它就一定挑，哪怕代码很好也开始挑鸡毛蒜皮甚至编造。明确给退路：“某一关确实没问题就写’本关无问题’，不要凑数硬找。”给了退路它反倒诚实。

四、AI 说的不一定对：三级过滤

拿到结果别急着照单全改。AI 的 review 结论分三类：

第一类：真问题（改）。 密钥硬编码、没判空、逻辑写反，占比约一半，直接改。

第二类：AI 看错了（不用改）。 AI 只看到你贴的这一段，看不到项目其他部分。 它可能说”这用户身份没校验”——可你在上层统一入口早校验过了，它不知道。识别法：你确定别处已处理，就是它上下文不全，回一句它会撤回。

第三类：风格之争（可不改）。 “建议改另一种写法”“建议提取独立函数”，没对错纯偏好，赶时间就跳过。

一句话验伪：让它举个会出事的场景

怎么快速分辨？万能追问：“这个问题在什么具体情况下会真的出事？给我能复现的场景：什么用户、什么操作、什么输入、最后什么后果。”

• 真问题 → 立刻说出：”用户搜索框输入带单引号内容时，查询被截断，攻击者可借此读整张用户表。”
• 假问题/凑数 → 开始打太极：”这主要提升可维护性和扩展性……”

说不出具体场景的，基本都能放一放。

五、实战：一段”跑得通”的代码被挑出了什么

假设你写了”用户登录”逻辑，功能正常、测试过了。丢进五关一过：

🔴 必须改（3 条）

1. 【安全·第 8 行】 数据库连接密码直接写代码 → 后果：代码被看到密码就泄，传公开仓库几分钟被扫到 → 改法：移环境变量，代码只读变量名。
2. 【安全·第 22 行】 用户名原样拼进查询 → 后果：输特殊字符可绕密码登录甚至读整张表 → 改法：参数化查询，用户名当”值”传不是”语句”。
3. 【异常·第 35 行】 登录失败把完整错误返前端 → 后果：暴露表名、字段名、框架版本，给攻击者递地图 → 改法：详情写日志，前端统一”用户名或密码错误”。

🟡 建议改（2 条） 4. 【异常·15 行】调短信接口没设超时→对方挂了会卡住 5. 【整洁·全函数】一个函数干 5 件事→建议拆。

🟢 可以不改（1 条） 6. 变量 res 建议改名 loginResult。

看到没——功能没毛病、测试全绿，但三个必须改里两个能直接致数据泄露。 这就是 review 的价值：测试盯”对不对”，review 盯”稳不稳、安不安全”。

六、提交前三分钟自查清单

最后一张随身表，每次提交前花三分钟过一遍：

□ 代码里有没有写死的密码 / 密钥 / token？
□ 用户输入有没有被原样拼进查询语句或命令？
□ 报错信息会不会原样返回给前端？
□ 网络请求设超时了吗？
□ 可能为空的地方判空了吗？
□ 有没有 catch 了异常却什么都不做的地方？
□ 循环里有没有查数据库 / 发网络请求？
□ 有没有临时调试打印、注释掉的死代码、写死测试账号？
□ 单元测试跑过了吗？（上篇）
□ 这次改动，我能一句话说清改了什么、为什么改吗？

最后一条是隐藏考题。 说不清自己改了什么，说明混进了不该混的东西——拆开分两次提交。

提示词模板盒子

模板 1：五关全量 Review（主力模板）

你现在的角色是一位严格的代码审查员，正在帮编程新手做提交前最后检查。

【要审查的代码】

（把完整代码贴在这里，不要贴片段）

【这段代码是干什么的】
（两三句大白话说明业务用途、谁用、什么时候被调用）

【技术背景】
（什么类型项目、跑在哪、有没有暴露给外部用户）

【审查要求】
请严格按以下五关逐项审查，每关单独给结论：
第一关·正（正确性）：逻辑有无写反、边界有无遗漏、计算有无隐患
第二关·安（安全）：①密码/密钥/token有无硬编码 ②用户输入有无原样拼进查询/命令/路径 ③敏感信息（密码、身份证、手机号、完整堆栈）有无写进日志或返前端
第三关·错（异常）：网络有无超时、空值有无判空、有无捕获异常后啥都不做、外部调用失败有无兜底
第四关·洁（整洁）：过长、重复、命名、嵌套、魔法数字、职责过多
第五关·快（性能）：循环查库、循环发请求、能批却逐条、一次读海量数据

【输出格式】
按严重程度分三档，每档内按行号排序：
🔴 必须改（安全漏洞、逻辑错、必崩）  🟡 建议改（欠债）  🟢 可以不改（纯风格）
每一条必须含四要素：1.位置 2.问题（一句话） 3.后果（什么情况真出事、造成什么损失，不许写"影响可维护性"） 4.改法（给代码）

【严格约束】
- 不评价优点、不写褒奖，只挑问题
- 某关确实没问题就写"本关无问题"，不要凑数硬找
- 大白话解释，新手术语顺带解释一句
- 不确定处明确说"我看不到上下文需你确认"，不要猜

模板 2：安全快查（最快见效，建议每次都跑 + 提交前三分钟）

【A. 只查安全，其他不管】

（贴完整代码）

请只查这七项，逐项给结论（有问题指行号，没问题写"未发现"）：
1. 有无硬编码密码、密钥、token、连接字符串
2. 用户输入有无原样拼进数据库查询
3. 用户输入有无原样拼进系统命令或文件路径
4. 有无把完整报错堆栈/内部路径/表名返前端
5. 有无把密码、身份证、手机号写进日志
6. 有无该做权限校验却没做（能操作别人数据）
7. 有无用不安全老旧加密或伪随机
对每个发现说明：攻击者怎么利用（给可复现输入例子）、最坏后果、正确写法。
七项全无问题就明确答"七项均未发现"，别硬找别的。

【B. 提交前三分钟快查】

（贴代码）

只回答下面 10 个是非题，格式「序号+是/否+若是指出行号」：
1. 有无写死密码/密钥/token  2. 用户输入有无原样拼进查询或命令
3. 报错会不会原样返前端  4. 网络请求漏设超时没
5. 有可能为空却没判空吗  6. 有无捕获异常啥都不做
7. 循环里查库或发请求没  8. 有无调试打印/死代码/写死测试账号
9. 有无本次改动外不小心带进的无关修改  10. 有无一眼可见逻辑错（判断反/边界漏）
最后一句话总结：这段代码现在能不能提交？不能只列必须先修那几条。

模板 3：验伪与纠偏（判别 AI 结论真假 + 补上下文）

【A. 验伪追问——对每条可疑结论用】
你刚才提的这条问题：
【把 AI 那条结论原样贴过来】
请给我一个能真实复现的具体场景：
- 什么身份用户 / 做了什么操作 / 输入了什么 / 最终什么后果（具体到用户看到啥、数据变啥）
如果你说不出具体可复现场景，或只是"理论上可能"，请直接答："这条不是真实风险，可以忽略。"
不要用"提升可维护性""增强健壮性""符合最佳实践"来搪塞。

【B. 上下文不全时的纠正】
你提的第 X 条问题（【贴那条】），我补充上下文：
【补充说明】这部分其实在别处已处理：（说明在哪层、怎么处理，最好贴那段代码）
请重新判断：1. 补了上下文这条还成立吗 2. 不成立请明确说"这条撤回" 3. 仍成立说明为什么现有处理不够、什么情况被绕过。
同时重新检查你其他结论，有没有同样因看不到全部代码而误判的。

80 篇速查卡

下篇预告

现在代码有两道防线：测试盯结果，review 盯风险。但还有个问题没解决——三个月后你自己看不懂自己写的代码。变量名取对了、逻辑没毛病，却想不起”当初为什么这么写”。代码能说清”做了什么”，说不清”为什么”。下一篇《第 81 篇：用 AI 生成注释与文档》讲注释该写什么、不该写什么（剧透：写”为什么”不写”是什么”）。下篇见。