1. 为什么“推代码前先 /review”值得单独拎出来讲很多人第一次听到“推代码前先 /review”这个说法第一反应是不就是提交前看一眼吗能有多大事。但真正在团队里待过、被线上事故教育过的人会明白代码审查这件事最怕的不是“没人看”而是“看的人以为别人会看”。我见过太多团队把质量审查和安全审查混成一个动作结果就是两边都没做到位——质量上漏掉了边界条件安全上放过了越权访问最后一起在复盘会上大眼瞪小眼。这个标题里有个很关键的斜杠/review。它不是一个随便起的名字而是一种把审查动作“命令化”“流程化”的思路。你可以把它理解成在提交代码之前主动触发一次结构化的检查而不是靠记忆和自觉。关键词里出现的 Bugbot、Security Review、Cursor其实指向的是同一件事把审查从“人肉盯”变成“有工具辅助、有固定入口、有明确分工”的流程。这篇文章适合谁看如果你是刚进团队、还在适应提交规范的开发者它能帮你建立一套可复用的自查习惯如果你是带小团队的技术负责人它能帮你把“质量”和“安全”这两条线拆开避免审查流于形式如果你只是自己写 side project它也能让你在推代码前少留几个明显的坑。我不打算讲空泛的“代码审查很重要”而是把审查拆成可操作的步骤、可对照的清单、可复现的排查链路让你看完就能用。先说一个我自己的教训。早些年我在一个项目里负责一个用户资料接口提交前自己跑了一遍主流程觉得没问题就推了。结果上线第二天有人反馈说改别人的资料也能成功。问题出在权限校验写在了业务逻辑之后而且只校验了“是否登录”没校验“是否本人”。当时如果有一个固定的/review动作专门盯安全边界这个坑大概率能在提交前拦住。质量审查看的是“能不能跑通”安全审查看的是“能不能被滥用”这两件事的视角完全不同混在一起做必然有一边被牺牲。所以这篇内容的核心就是把“推代码前先 /review”拆成两条独立的审查线再讲清楚工具怎么配合、流程怎么落地、坑怎么排。下面我会从审查分工、工具选型、实操步骤、排查链路几个角度展开尽量把每个“为什么”都讲透。2. 质量审查和安全审查到底差在哪一次把边界划清楚2.1 质量审查盯的是“正常路径”安全审查盯的是“异常路径”质量审查的典型问题是这个函数在输入为空的时候会怎样循环边界有没有差一异常有没有被吞掉它的思维模式是“假设用户按预期操作”。而安全审查的思维模式恰恰相反假设用户不按预期操作甚至假设用户是恶意的。比如一个查询接口质量审查会看 SQL 拼得对不对、返回结构是否一致安全审查会看这个接口能不能查到别人的数据、参数能不能注入、返回里有没有多余字段泄露。我习惯把这两类审查比作“体检”和“安检”。体检是看身体各项指标是否正常安检是看有没有人带了不该带的东西。你不可能用体检代替安检也不可能用安检代替体检。很多团队的问题就在于代码审查只有“体检”没有“安检”或者把安检简化成一句“注意安全”等于没做。2.2 把两者混在一起最常见的三种翻车方式第一种是“审查疲劳”。一个人既要看逻辑又要看安全注意力有限通常会把精力放在更容易理解的逻辑上安全项被草草带过。第二种是“责任稀释”。因为审查清单里既有质量又有安全出了问题之后很难界定是哪一环漏了最后变成“大家都看了但都没看到”。第三种是“工具误用”。有些工具擅长静态质量检查有些工具擅长依赖漏洞扫描如果用一个工具去覆盖所有审查就会产生“已经扫过了”的虚假安全感。我自己的做法是在提交前把审查分成两个独立的动作先过质量再过安全每个动作有独立的清单和独立的通过标准。这样做的代价是多花几分钟但收益是漏检率明显下降。下面这张表是我常用的对照你可以直接拿去改审查维度质量审查关注点安全审查关注点输入处理空值、类型、长度边界注入、越权、参数篡改数据访问查询是否正确、性能是否可接受是否校验数据归属、是否最小权限错误处理异常是否被捕获、日志是否完整错误信息是否泄露内部细节依赖使用版本是否兼容、API 是否用对依赖是否有已知漏洞、是否引入多余权限输出内容结构是否一致、字段是否完整是否返回了敏感字段、是否做了脱敏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说到底不是多做一个动作而是把“质量和安全审查当成一个”这个习惯改掉。拆开之后你会发现两边都更清晰也更容易坚持。
