Cursor硬核Review技能：为什么能提前暴露问题，却止不住劣质化？

说到 Cursor 的 Review 技能我的第一反应不是“它能不能一次审出十个 Bug”而是“它能不能阻止代码库一天天烂下去”。过去大半年AI 编程助手让代码产出速度明显变快但很多仓库的技术债也在同步增加提交越来越频繁、逻辑越来越绕、没有测试的函数越来越多。于是很多人开始把希望寄托在 Cursor 里的 Review 技能上想用一次硬核自动评审把劣质化趋势按住。我的判断是Review 技能确实值得认真搭一套但它本身止不住劣质化它只能把评审这件事变得便宜、高频、可复制真正的质量闸门还得靠流程和人来补。1. 先回答Review 技能到底算不算“硬核”1.1 技能不是模型不是插件而是一套可复用的评审协议在 Cursor 里“技能”并不是一个独立模型也不是传统意义上的插件。它更像是一份长期有效的评审协议模型根据这份协议读取输入、生成输出。你可以在项目目录下创建.cursor/skills/review/这样的技能目录里面放一个SKILL.md描述评审目标和规则也可以把技能放到全局目录里让所有项目共享一套基础规范。“硬核”这个形容词不来自技能名字而来自技能里的约束强度。同样的模型在没有技能时可能会输出“这段代码风格不错”这样的废话有了严格技能之后它会要求自己列出 P0/P1 级别问题指出具体文件、行号并给出修复示例。这不是模型突然变聪明了而是你给它建立了一套输出协议。所以判断一个 Review 技能是否硬核第一件事不是看它列了多少条规则而是看它的规则能不能把一套开放的“代码理解”动作压缩成可执行、可验证的评审流程。1.2 它真正改变的是评审成本与频率传统 code review 最贵的是人的注意力。一个 PR 合入前要等维护者抽出时间要对照上下文要判断改动是否合理。这个过程如果拖上两天要么合入变慢要么审核流于形式。AI 生成代码之后这个矛盾更明显代码产出变快了人脑评审速度却没变。Review 技能解决的是这个错位。它可以让代码在提交后、合入前先被一个成本很低的模型评审一遍。哪怕它的准确率只有七成只要它能稳定指出空指针、异常被吞、明显逻辑重复、安全拼接这类问题就能把人工评审的搜索范围缩小很多。人工 reviewer 不需要再从头读一遍而是直接看 AI 标出来的疑点。这才是它真正的价值把评审从低频高成本动作变成高频低成本动作。但代价也随之而来——如果技能搭得不好它会制造大量噪声反而让团队不再信任任何评审结果。2. 代码劣质化的原因比 AI 写码更早2.1 AI 只是把速度拉满质量债被提前暴露很多人觉得代码劣质化是 AI 编程带来的。这个判断一半对一半错。代码质量问题从来都存在命名混乱、魔法数字、重复封装、异常静默吞掉、函数越写越长。只是在人工写码时代产出速度限制了劣质化的速度。AI 出现后同样时间内能产出更多代码于是劣质代码的绝对量被放大了。Review 技能能在一定程度上筛掉单次变更里的低级问题但它改变不了劣质化的根因。如果团队的代码规范本身模糊、测试策略缺失、重构频率极低AI 只会更快地制造出大量“看起来能跑、但很难维护”的代码。Review 技能只是把问题提前暴露并没有消灭产生问题的环境。2.2 劣质化不是单点 Bug而是结构腐烂注意一个本质区别代码劣质化不等于某个函数写得烂。单点 Bug 是局部的修掉就完了。劣质化是结构性的表现为同一套逻辑散落在五个文件里修改时只改了一处。模块边界不清晰改一个功能要动三个层。函数职责混乱一个方法里既查数据库又写日志还处理按钮状态。没有测试兜底重构变成高危行为。Review 技能能发现“这个函数太长”“这里有重复代码”但它很难判断“这个模块是不是不应该存在”“这个业务逻辑是不是放错了层”。这些判断需要业务上下文需要架构取舍需要知道“三个月后这个系统要怎么演进”。所以如果你的目标是止住劣质化Review 技能只是其中一条腿不是全部。3. 搭建一套可运行的 Review 技能最小闭环3.1 先定义评审边界只审 diff不审全库最容易犯的错误是一上来让技能“评审整个仓库”。这几乎一定会导致两个结果一是上下文溢出模型抓不住重点二是输出全是历史遗留问题本次变更的真正风险被淹没。我更建议把评审对象限定在本次变更。在 Cursor 的 Agent 场景里可以先用 git 命令拿到变更范围git diff HEAD --stat git diff HEAD -- src/ | head -n 500然后把 diff 内容交给 Review 技能。实际落地时你不需要每次手动做这件事。可以把“读取 git diff”“分析变更”“输出评审结果”写进同一个技能流程里让 Cursor 的 Agent 自己执行命令。评审边界越窄信号越清晰。一次 100 到 300 行的变更是最合适的验证场景。不要贪多。3.2 一份 SKILL.md 示例下面是一份常见结构的技能文件示例。它不是官方模板而是一个可以照着改的起点。--- name: code-review description: 对 git 变更进行系统化代码评审 --- # Role 你是一名资深代码评审专家擅长发现逻辑错误、安全隐患、可读性问题和测试缺失。 # Input 优先读取当前变更的 git diff。如果没有提供 diff请主动提醒。 # Rules 1. 只评审本次变更不讨论旧代码的历史问题。 2. 按严重级别输出 - P0阻断合入必须修复 - P1应该修复会影响稳定性或可维护性 - P2建议优化不阻塞合入 - P3可选风格类意见 3. 每条问题必须包含文件、行号、问题描述、修复建议。 4. 遇到没有把握的问题标注“需要作者确认”不要臆测。 5. 不要输出“代码整体不错”这类概括性结论。 # Output Format - 变更摘要用三句话总结本次变更意图 - 问题列表按 P0/P1/P2/P3 分组 - 合入建议通过 / 修复后通过 / 不通过这套文件的关键不是 Markdown 结构而是里面的硬规则必须给行号、必须给级别、必须给修复建议。没有这些约束技能输出就容易变成“正确的废话”。3.3 单次流程先跑通再优化第一次使用不要直接压到所有 PR 上。按这个顺序跑一轮选一个小型 commit 或 MR变更量控制在 300 行以内。让 Agent 读取 diff并加载 Review 技能。看输出格式有没有行号有没有严重级别修复建议是否具体针对 P0/P1 问题让 Agent 给出具体修改。修复后再跑一次 Review确认问题是否消失。这个流程强调“先跑通”。单次跑通只代表技能路径没有断不代表它已经足够可靠。真正要调整的是后续的输出质量和误报率。4. 真正让评审有效的四个设计细节4.1 输入要窄评审要聚焦Review 技能喂进去的输入越杂输出越空。全量文件、一堆无关配置、历史代码都会稀释模型对本次变更的关注度。比较好的做法是只用 git diff 作为主输入。如果涉及某个模块可以附带该模块的接口定义。不要附加整个项目的 README除非里面有编码规范。“硬核”不等于把整个仓库都塞给它。评审越聚焦越容易发现真实问题。4.2 输出要硬拒绝“正确废话”评审技能最怕输出这种话“建议优化一下这段逻辑提升可读性。”这句话没有任何信息量。问题的关键不是“可读性不好”而是“哪里不好、为什么不好、应该改成什么”。所以我通常会在技能里写死一条规则不允许输出没有文件、行号和修复示例的泛化结论。你可以在技能里加一行如果没有明确的文件、行号和修复示例该问题视为无效输出。这条规则会显著改变输出质量。模型可以不给你找 20 个问题但只要列出问题就必须能让开发者直接定位到那一行。4.3 校验要闭环评审后要有修复验证Review 技能不应该只负责“提出问题”还应该参与“验证修复”。实际使用中我会在技能里让 Agent 在提出修复建议时额外判断改动是否会破坏现有测试。改动是否需要同步修改注释或文档。修复是否引入新的副作用。如果 Cursor 的 Agent 能执行命令可以让它在修复后重新跑相关命令比如对改动范围执行 lint、静态检查或单元测试。真正有用的 Review 不是一次性的体检报告而是一个“发现 - 修复 - 复检”的循环。4.4 结论要可追溯对 AI 评审结果做人工确认AI 评审结果默认只是“建议”不是“结论”。在团队协作里最好把 Review 技能的输出贴到 PR 描述或评审线程里让人工 reviewer 能看到模型判断的依据。这样既方便复核也能逐渐积累“模型误报”样本用来迭代技能规则。不要直接把 AI 的审核结论当成最终结论。一旦团队养成“AI 说没问题我就点通过”的习惯劣质化会以另一种形式回归模型漏报的问题没有人再看到。5. 它能止住劣质化吗我的答案是不能但能把问题提前暴露5.1 它能做什么以我目前的实际使用体验Review 技能在下面这些场景里帮助最大空指针、空值判断遗漏。异常被 catch 后静默吞掉。外部输入未做长度或格式校验。字符串 SQL 拼接或命令拼接。同样的逻辑在不同文件里重复出现。函数签名变化后调用方没有同步更新。缺少对应测试或测试断言太弱。它能把这些问题在合入前暴露出来降低人工 reviewer 的搜索成本。对于经验不丰富的开发者AI Review 还可以当“陪练”从具体问题里学到怎么修改。5.2 它不能做什么Review 技能做不到这些事判断“这个功能是否真的需要”。判断“这个模块的边界是不是错了”。判断“这次重构的风险是否可接受”。判断“这段代码在业务上是否满足未来半年需求”。判断“团队是否应该投入一周做技术债清理”。这些判断依赖上下文、历史和决策目标。模型看到的只是代码快照不是业务全景。所以能力边界很清楚它能处理“写得好不好”很难处理“应不应该这么写”。5.3 边界自动化评审可能带来的“信任偏差”这是最需要警惕的一点。当 Review 技能逐渐变强开发者和 reviewer 都可能产生一种错觉既然 AI 已经审过一遍代码应该没有大问题。结果就是人开始变懒。开发者不再自查reviewer 不再深度阅读团队把质量责任外包给了一个概率模型。一旦模型漏掉关键问题它不会被发现因为没有人再做第二次独立检查。所以我会把 AI Review 定位成“第一道闸门”而不是“最终裁判”。最终裁判必须是人而且这个人要有能力推翻 AI 的结论。否则Review 技能不是止住劣质化而是制造一种“已经评审过了”的假象。6. 从技能到质量闭环还需要补四块拼图6.1 把规范变成技能而不是口头文化很多团队的代码规范停留在文档里甚至根本没有。Review 技能要想有效第一步是把你所在团队最常犯的几类问题写进技能规则里。例如“禁止在 controller 里写业务逻辑。”“所有外部输入必须走 schema 校验。”“数据库查询禁止放在 for 循环里。”“新增对外接口必须补充错误码。”这些规则越具体AI 的评审越贴合项目现实。技能不是一套通用 Prompt它应该随着团队教训持续更新。6.2 在 CI/PR 流程里安排第一道门如果只在 Cursor 里跑 Review 技能它依赖开发者主动触发覆盖范围有限。更稳的做法是把评审能力放到 CI 或 PR 流程里每次 push 后自动跑一次评审把结果作为 PR 评论推送。社区里也有不少这方面的探索比如 open code review 这类项目经常出现在讨论里。具体工具选型要看团队基础设施但核心思路是一致的让 Review 从“某个人的自觉”变成“流程里的固定动作”。同时要设置逃生阀。AI 评审只是辅助不能因为 AI 报了一堆问题就让合入流程瘫痪。要有阈值比如只有 P0/P1 问题才阻断合入P2/P3 进 backlog。6.3 对 AI 评审结果做抽样复盘技能搭完不代表一劳永逸。我建议每两周做一次抽样复盘随机抽 5 个 AI 报出 P0/P1 的 PR看有多少是真正有效的问题。再抽 5 个 AI 没有报问题的 PR看是否漏掉了关键风险。把误报和漏报记录到技能规则里比如“不要再把某种模式当错误”。复盘的产出不一定是一次性改完 Prompt而是慢慢形成一份团队自己的“评审规则集”。这份规则集比任何一个通用模板都重要。6.4 处理“漏报”比处理“误报”更重要误报很烦但它至少发生在明处。漏报才是最危险的——它会让你以为质量有保障实际上问题已经在代码里生根。Review 技能的迭代重点应该放在漏报上。你可以用提交历史反推哪些线上故障或严重事故在合入前没有被 AI Review 发现把这些场景抽出来变成新的规则。长期下来技能才会往真正该看的方向生长而不是不停在一些无关痛痒的风格问题上打转。7. 如果 Review 技能没效果按这个顺序排查7.1 技能是不是真的被加载了如果你发现输出完全没有按 SKILL.md 里的格式走最可能的原因是技能没有被正确加载。检查技能目录路径、文件名是否叫SKILL.md、技能描述是否符合当前 Cursor 版本的约定。也可以故意在技能里写一条明显规则比如“输出第一行必须是 REVIEW-START”看模型是否遵守。7.2 评审范围是不是失控了如果输出问题很多但都很泛多半是输入范围太大。确认是不是把整个仓库喂进去了。把评审对象收窄到 git diff问题会立刻清晰很多。7.3 项目上下文是不是缺失如果模型看不懂项目里特殊的封装和命名它就会按通用经验提一堆“建议”而这些建议对项目不一定适用。最好在技能里引用一两个项目约定文件或者把 README 中与代码结构相关的段落加入上下文。7.4 输出建议是不是可执行如果每条意见都是“可以优化”“可以提取常量”说明规则不够硬。检查是否强制要求文件、行号、修复示例。没有这些宁可不要输出。7.5 修复后有没有重新验证最隐蔽的问题是AI Review 发现了一堆问题开发者改了一部分但没有人复检。结果代码质量并没有真正改善。修复后的第二次 Review 应该是流程的一部分不是可选项。8. 收尾不要指望技能要建立系统回到最初的问题Cursor 硬核 Review 技能能不能止住代码劣质化我的答案是不能直接止住但它能把质量问题的发现提前到每次代码变更而不是等代码腐烂到不可收拾。代码劣质化的本质不是“写得快、审得少”而是缺少一套持续反馈的约束系统。Review 技能只是这个系统里的一根探针。真正值得做的不是追求一个完美 Prompt而是搭起一个“生成 - 评审 - 修复 - 再评审 - 人工把关”的闭环然后每周校准一次。如果你还没搭过技能我建议从一个小仓库、一小段 git diff 开始先看它能不能说出让团队信服的问题再逐步扩大范围。这样技能才会成为质量系统的起点而不是一篇聊以自慰的自动化。