推代码前先 /review：质量与安全审查的独立流程与工具实践

1. 为什么“推代码前先 /review”值得单独拎出来讲

很多人第一次听到“推代码前先 /review”这个说法，第一反应是：不就是提交前看一眼吗，能有多大事。但真正在团队里待过、被线上事故教育过的人会明白，代码审查这件事最怕的不是“没人看”，而是“看的人以为别人会看”。我见过太多团队把质量审查和安全审查混成一个动作，结果就是两边都没做到位——质量上漏掉了边界条件，安全上放过了越权访问，最后一起在复盘会上大眼瞪小眼。

这个标题里有个很关键的斜杠：/review。它不是一个随便起的名字，而是一种把审查动作“命令化”“流程化”的思路。你可以把它理解成在提交代码之前，主动触发一次结构化的检查，而不是靠记忆和自觉。关键词里出现的 Bugbot、Security Review、Cursor，其实指向的是同一件事：把审查从“人肉盯”变成“有工具辅助、有固定入口、有明确分工”的流程。

这篇文章适合谁看？如果你是刚进团队、还在适应提交规范的开发者，它能帮你建立一套可复用的自查习惯；如果你是带小团队的技术负责人，它能帮你把“质量”和“安全”这两条线拆开，避免审查流于形式；如果你只是自己写 side project，它也能让你在推代码前少留几个明显的坑。我不打算讲空泛的“代码审查很重要”，而是把审查拆成可操作的步骤、可对照的清单、可复现的排查链路，让你看完就能用。

先说一个我自己的教训。早些年我在一个项目里负责一个用户资料接口，提交前自己跑了一遍主流程，觉得没问题就推了。结果上线第二天，有人反馈说改别人的资料也能成功。问题出在权限校验写在了业务逻辑之后，而且只校验了“是否登录”，没校验“是否本人”。当时如果有一个固定的/review动作，专门盯安全边界，这个坑大概率能在提交前拦住。质量审查看的是“能不能跑通”，安全审查看的是“能不能被滥用”，这两件事的视角完全不同，混在一起做，必然有一边被牺牲。

所以这篇内容的核心，就是把“推代码前先 /review”拆成两条独立的审查线，再讲清楚工具怎么配合、流程怎么落地、坑怎么排。下面我会从审查分工、工具选型、实操步骤、排查链路几个角度展开，尽量把每个“为什么”都讲透。

2. 质量审查和安全审查到底差在哪：一次把边界划清楚

2.1 质量审查盯的是“正常路径”，安全审查盯的是“异常路径”

质量审查的典型问题是：这个函数在输入为空的时候会怎样？循环边界有没有差一？异常有没有被吞掉？它的思维模式是“假设用户按预期操作”。而安全审查的思维模式恰恰相反：假设用户不按预期操作，甚至假设用户是恶意的。比如一个查询接口，质量审查会看 SQL 拼得对不对、返回结构是否一致；安全审查会看这个接口能不能查到别人的数据、参数能不能注入、返回里有没有多余字段泄露。

我习惯把这两类审查比作“体检”和“安检”。体检是看身体各项指标是否正常，安检是看有没有人带了不该带的东西。你不可能用体检代替安检，也不可能用安检代替体检。很多团队的问题就在于，代码审查只有“体检”没有“安检”，或者把安检简化成一句“注意安全”，等于没做。

2.2 把两者混在一起，最常见的三种翻车方式

第一种是“审查疲劳”。一个人既要看逻辑又要看安全，注意力有限，通常会把精力放在更容易理解的逻辑上，安全项被草草带过。第二种是“责任稀释”。因为审查清单里既有质量又有安全，出了问题之后很难界定是哪一环漏了，最后变成“大家都看了，但都没看到”。第三种是“工具误用”。有些工具擅长静态质量检查，有些工具擅长依赖漏洞扫描，如果用一个工具去覆盖所有审查，就会产生“已经扫过了”的虚假安全感。

我自己的做法是：在提交前把审查分成两个独立的动作，先过质量，再过安全，每个动作有独立的清单和独立的通过标准。这样做的代价是多花几分钟，但收益是漏检率明显下降。下面这张表是我常用的对照，你可以直接拿去改：

2.3 为什么“先 /review”比“提交后 review”更划算

提交后审查的问题在于，代码已经进入主干，修改成本变高，而且审查者容易产生“反正已经提交了”的心理松懈。提交前审查则是在你上下文最热的时候做检查，你对这段代码的记忆最清晰，改起来也最快。更重要的是，提交前审查可以把问题拦在进入 CI 之前，减少流水线反复失败带来的时间浪费。

我实测下来，提交前花五到十分钟做一次结构化/review，能省掉后面至少半小时的返工和沟通。尤其是安全类问题，一旦进入主干再发现，往往要牵扯到数据修复、权限回滚，成本完全不是一个量级。

3. 工具怎么选：Bugbot、Security Review 和 Cursor 各自站什么位置

3.1 Bugbot 类工具适合做“质量线的第一道筛子”

Bugbot 这类工具的核心能力是静态分析和模式识别，它擅长发现那些“看起来就不对”的代码：未使用的变量、可疑的空指针、明显的逻辑分支遗漏。它的优势是快、覆盖广、不依赖人工记忆。但它也有明显边界：它不理解你的业务语义，不知道“这个字段属于谁”，所以它很难发现越权这类需要业务上下文的问题。

我的用法是把 Bugbot 类工具放在质量审查的第一道，先让它扫一遍，把明显的低级问题清掉。这样人工审查就可以集中在业务逻辑和边界条件上，而不是浪费时间在看拼写错误和未使用变量上。注意，不要因为它扫过就跳过人工质量审查，工具只能减少噪音，不能替代判断。

3.2 Security Review 必须独立成项，不能挂在质量审查后面

Security Review 的关键在于“独立”。它需要单独的清单、单独的触发时机、单独的通过标准。我通常会在质量审查通过之后，专门花几分钟走一遍安全清单：这个接口的调用者是谁？数据归属怎么校验？输入有没有做白名单？返回有没有做脱敏？日志里有没有打印敏感信息？

这里有个容易被忽略的点：安全审查要覆盖“配置”而不只是“代码”。比如某个开关默认打开了调试模式，某个依赖引入了过大的权限，这些在代码层面看不出来，但在安全审查里必须过一遍。我见过一个案例，代码逻辑没问题，但配置文件里把某个内部接口暴露到了公网，这就是典型的安全审查漏项。

3.3 Cursor 在审查流程里的真实定位

关键词里出现了大量 Cursor 相关的内容，说明很多人正在用它写代码。Cursor 这类 AI 辅助编辑器的价值在于“加速理解和生成”，但它不能替代审查。我的经验是：用 Cursor 写代码可以很快，但正因为它快，更容易产生“看起来对但没想清楚”的代码。所以用 Cursor 的时候，提交前的/review反而更重要。

具体怎么配合？我通常会让 Cursor 帮我做两件事：一是生成审查清单的初稿，比如“帮我列出这个接口需要检查的安全项”；二是对某段代码做解释，帮助我快速判断它有没有隐藏的边界问题。但最终的判断必须由我自己做，因为 AI 不知道我们的业务规则和数据归属关系。

提示：不要把 AI 生成的审查结论直接当成通过标准。它可以帮你发现线索，但不能替你承担责任。

4. 一套可复现的提交前 /review 实操流程

4.1 第一步：冻结改动范围，先看 diff 而不是看文件

很多人审查的时候直接打开文件从头看，这是效率最低的做法。正确的第一步是看 diff，也就是这次到底改了哪些行。因为审查的目标是“这次改动有没有问题”，而不是“这个文件整体写得好不好”。看 diff 能让你快速聚焦，避免被无关代码分散注意力。

我通常会在命令行里先跑一次 diff，把改动按文件分组，然后逐个文件过。对于每个文件，先问三个问题：这次改动的意图是什么？改动是否只做了这件事？有没有顺带改了不该改的地方？第三个问题特别重要，因为很多事故源于“顺手改了一行”却没意识到影响。

4.2 第二步：质量清单逐项过，每项都要有结论

质量审查不能靠感觉，要有清单。下面是我常用的质量清单，你可以根据自己的技术栈调整：

• 输入边界：空值、超长、特殊字符、类型不符时，代码走向是否明确？
• 循环与递归：终止条件是否可达？有没有栈溢出风险？
• 异常处理：异常是否被捕获？捕获后是吞掉还是上报？日志是否包含足够上下文？
• 资源释放：文件、连接、锁是否在异常路径下也能释放？
• 并发安全：共享状态是否有保护？有没有竞态条件？
• 兼容性：改动是否影响已有调用方？接口签名是否变化？

每一项都要给出明确结论，不能写“应该没问题”。如果某项确实不适用，也要写明“不适用，原因是什么”。这样做的目的是让审查可追溯，后面出问题能快速定位是哪一项漏了。

4.3 第三步：安全清单单独走，重点盯权限和数据流

安全审查的清单和质量清单完全不同，我通常按数据流的方向走：数据从哪来、经过谁、存到哪、返回给谁。每个环节问对应的安全问题。

• 入口：参数是否做了白名单校验？是否限制了大小和频率？
• 身份：调用者是谁？身份凭证是否可伪造？会话是否可固定？
• 授权：这个操作是否校验了数据归属？是否存在水平越权或垂直越权？
• 存储：敏感数据是否加密？是否最小化存储？
• 输出：返回字段是否最小化？是否脱敏？错误信息是否泄露内部结构？
• 日志：是否打印了凭证、令牌、个人敏感信息？

这里我特别想强调“水平越权”。很多团队做了登录校验，就以为安全做完了，但登录只解决“你是谁”，不解决“你能操作谁的数据”。一个用户登录后能不能改别人的资料，这是授权问题，必须在安全审查里单独确认。

4.4 第四步：把审查结论落到提交信息里

审查做完不是结束，还要留下痕迹。我的习惯是在提交信息里写清楚：这次改动做了什么、质量审查过了哪些项、安全审查过了哪些项、有没有遗留风险。这样做的好处是，后面如果有人回溯，能快速知道当时的判断依据。而且写下来的过程本身就会逼你把没想清楚的地方想清楚。

注意：提交信息里不要写敏感细节，比如具体的漏洞利用方式。写“已校验数据归属”就够了，不需要写“原来可以通过改 ID 越权”。

5. 排查链路：一次真实的“以为过了其实没过”的复盘

5.1 现象：功能测试全过，上线后出现数据串号

我之前遇到过一个案例，一个列表接口在测试环境一切正常，上线后偶发返回别人的数据。测试的时候用的是同一个账号，所以没暴露。上线后多账号并发访问，问题就出来了。这个问题的根因是查询条件里漏了用户 ID 过滤，而测试用例没有覆盖多用户场景。

5.2 排查过程：从日志到 SQL 到代码逐层缩小

第一步是看日志，发现返回的数据确实不属于当前请求者。第二步是看 SQL，发现查询条件里只有状态过滤，没有用户过滤。第三步是回到代码，发现用户 ID 在上一层被取出来了，但传参的时候漏了。整个过程其实不复杂，但如果提交前有一次安全审查，专门问一句“这个查询有没有按数据归属过滤”，就能提前拦住。

5.3 修复与验证：补上过滤条件，并补多用户测试用例

修复本身很简单，加上用户 ID 过滤即可。但更重要的是补测试用例：至少两个用户，互相访问对方的数据，确认返回为空或报错。这个用例后来被加进了回归测试，防止类似问题再次出现。

5.4 举一反三：所有“按 ID 查询”的地方都要过一遍

这个案例之后，我把项目里所有“按 ID 查询”的接口都过了一遍，确认每个都有数据归属校验。结果又发现两处类似问题，虽然还没被触发，但风险是实实在在的。这就是安全审查的价值：它不是为了找已经发生的问题，而是为了找还没发生但可能发生的问题。

6. 把 /review 变成习惯的几个实操心得

6.1 审查清单要短，短到愿意每次都过

我见过很多团队写了很长的审查清单，结果没人用。清单太长本身就是一种负担。我的建议是质量清单控制在六到八项，安全清单控制在五到六项，每项一句话，能快速判断。清单不是越全越好，而是越能被坚持越好。

6.2 把审查动作绑定到具体命令或快捷键

习惯的养成靠的是降低启动成本。我会把/review绑定成一个快捷动作，比如在编辑器里配置一个命令，或者在终端里写一个脚本，一键拉出 diff 和清单。这样每次提交前，动作是自然的，不需要靠意志力提醒自己。

6.3 安全审查要有“假想敌”视角

做安全审查的时候，我会刻意切换视角：如果我是攻击者，我会怎么利用这个接口？这个参数能不能改成别人的 ID？这个返回能不能拿到额外信息？这个错误提示能不能帮我推断内部结构？这种“假想敌”视角能帮你发现很多正常视角看不到的问题。

6.4 不要追求一次到位，先做到“每次都做”

审查能力是练出来的，不是看几篇文章就能掌握的。一开始你可能只能发现明显问题，但随着次数增加，你会形成自己的检查直觉。关键是先做到“每次都做”，哪怕一开始只过三项，也比不做强。我自己的经验是，坚持一个月之后，很多检查项会变成条件反射，不需要刻意想就能发现。

6.5 团队协作时，把审查结论同步给相关人

如果你是团队协作，审查结论不要只留在自己脑子里。至少让相关的人知道：这次改动过了哪些审查、有没有遗留风险、需不需要别人补位。尤其是安全相关的改动，最好让负责安全的人知道，避免出现“以为对方看过了”的情况。

7. 关于 Cursor 使用中几个高频问题的顺手解答

既然关键词里出现了大量 Cursor 相关的问题，我顺手把几个和审查流程相关的点讲一下。比如很多人问 Cursor 怎么设置中文回复、怎么汉化、怎么设置中文界面，这些属于使用配置层面的问题，核心思路是在设置里找到语言相关选项，或者通过扩展和配置项调整。但我想提醒的是，界面语言不影响审查质量，真正影响审查的是你有没有固定的清单和动作。

另外，关于 Cursor 的响应速度、免费额度、注册方式这些问题，属于工具使用层面的细节，不同版本和地区可能有差异，建议以官方说明为准。我更想强调的是：无论用什么工具写代码，提交前的/review都不能省。工具越快，越容易产生“写完就推”的冲动，而审查正是对这种冲动的约束。

还有一个常见问题是“Cursor 和 IDEA 同时编辑”会不会冲突。我的经验是，只要注意文件保存时机和版本同步，一般不会有问题。但如果你在两个工具里同时改同一个文件，确实可能出现覆盖。所以审查的时候，先确认你审查的是最终版本，而不是某个中间状态。

8. 最后分享几个我踩过坑之后总结的小技巧

第一个技巧：审查的时候把“这次不改什么”也写下来。比如“这次不改数据库结构”“这次不改接口签名”。写下来之后，如果 diff 里出现了这些内容，你就能立刻警觉。这个技巧帮我拦住过好几次“顺手改”带来的意外。

第二个技巧：安全审查时，先看返回字段，再看查询条件。返回字段最容易泄露信息，查询条件最容易出现越权。这两个地方过一遍，大部分低级安全问题都能发现。

第三个技巧：如果时间紧，宁可跳过质量审查的细节，也不要跳过安全审查。质量问题的代价通常是返工，安全问题的代价可能是数据泄露。优先级要清楚。

第四个技巧：把每次审查发现的典型问题记下来，攒成自己的“坑库”。下次审查的时候对照坑库过一遍，效率会高很多。我自己的坑库里有几十条，都是从真实事故里攒出来的，比任何通用清单都管用。

推代码前先/review，说到底不是多做一个动作，而是把“质量和安全审查当成一个”这个习惯改掉。拆开之后，你会发现两边都更清晰，也更容易坚持。