Cursor Bugbot「思考深度」实测：高强度模式真的值得开吗？

同一个PR，默认模式给出的结论是「代码逻辑清晰，无明显问题」。

高强度模式在同一份diff上，找出了一个在并发请求下会触发的竞态条件——两个异步操作共享同一个未加锁的状态变量，低并发下几乎不会复现，但一旦上线流量上来，就是一个难以定位的随机性故障。

这个发现让我开始认真对待Bugbot的「思考深度」设置，而不是把它当成一个UI装饰。

---

一、「思考深度」到底是什么？

Cursor Bugbot在近期的更新中加入了可调节的思考深度选项，在PR审查界面可以看到一个下拉切换入口，选项通常是「默认（Default）」和「高强度（Max/Thorough）」两档。

这个设计的底层逻辑，和AI推理模型的「思考Token预算」高度相似。

简单说：大语言模型在生成最终答案之前，可以被允许花费更多Token进行「内部推理」——类似于你做数学题时，草稿纸上写了多少步骤。默认模式下，Bugbot会对diff做一次相对快速的扫描，侧重于模式匹配和常见问题识别；高强度模式下，模型会被允许花更多计算资源去追踪代码的执行路径、状态变化和跨函数的依赖关系。

一句话给小白：就像让代码审查员「粗读一遍」还是「逐行精读并写批注」——两者都在做同一件事，但投入的注意力完全不同。

---

二、测试设计：怎么保证对比公平？

我选取了8个真实PR作为测试样本，覆盖以下类型：

• 前端逻辑bug（React状态更新、条件渲染边界）
• 后端边界条件（空值处理、数组越界）
• 安全类问题（SQL参数拼接、XSS风险点）
• 类型安全（TypeScript类型断言滥用）
• 并发/异步问题（Promise竞态、共享状态）

---

三、逐类对比结果——差距到底在哪里？

汇总数据

⚠️ 以上数据为本次8个PR的实测结果，样本量有限，仅供参考趋势，不代表统计意义上的精确结论。

简单语法/命名问题：两者几乎无差异

这类问题两种模式的表现基本持平。命名不规范、明显的拼写错误、未使用的变量——这些都是模式匹配就能搞定的，花更多推理Token并不会带来额外收益。

逻辑边界/竞态条件：高强度模式明显占优

这是差距最显著的类型之一。以开头提到的竞态条件为例，相关代码片段大致如下：

// PR中的改动
async function updateUserStatus(userId, status) {
const user = await db.getUser(userId);
user.status = status;           // 修改内存中的对象
await db.saveUser(user);        // 异步写回
cache.set(userId, user);        // 更新缓存
}

这个差距是实质性的。默认模式只看到了「代码没有语法错误」，高强度模式追踪了执行路径并识别出了时序依赖。

安全类问题：高强度发现更多，但误报也增加了

高强度模式在安全类问题上多发现了2个有效问题，但同时也多了2个误报。具体来说，它把一个已经经过参数化处理的查询标记为「潜在SQL注入风险」，原因是变量名里包含了 rawInput 字样——这是一个典型的「看名字猜行为」的误判。

# 实际代码（已安全处理）
def get_user(rawInput):
sanitized = escape(rawInput)          # 已转义
return db.execute("SELECT * FROM users WHERE name = ?", (sanitized,))

高强度模式的评论：「rawInput 直接传入数据库查询存在注入风险，建议使用参数化查询。」——但代码已经在用参数化查询了，只是变量命名让模型产生了误判。

性能隐患：差距最大的类型

在8个PR中，有2个涉及性能问题。默认模式只发现了1处，高强度模式发现了4处，包括一个在循环内部重复调用的数据库查询（N+1问题）和一个未被默认模式识别的不必要的全量数据加载。

这类问题需要跨函数追踪调用链，正是推理深度能带来明显收益的场景。

---

四、成本账——高强度模式值不值得开？

Token消耗估算

根据对接API日志的记录，同一个中等规模PR（约300行diff）：

• 默认模式：输入+输出合计约 3,000–5,000 Token
• 高强度模式：输入+输出合计约 12,000–20,000 Token，差距约在3–4倍

以100次PR审查为单位，按主流模型定价粗略换算（仅作量级参考，实际以平台当前定价为准）：

注：实际费用取决于所用模型和平台定价，以上为量级估算，不作为精确报价。

三种场景的推荐策略

默认模式完全够用。日常的功能迭代PR，大多数问题是命名、边界处理这类，默认模式的发现率足够，速度更快，成本更低。

强烈建议开高强度模式。这类PR的改动范围大、影响面广，多花几倍Token换来一个并发bug的提前发现，ROI是正的。

推荐混合策略：在PR创建时用默认模式做快速扫描（拦截低级错误），在PR标记为「Ready for Review」时触发高强度模式做深度审查。这样既控制了成本，又保证了关键节点的覆盖质量。

---

如果你的团队想把Bugbot或类似的AI代码审查能力接入自己的工作流，但又不想被单一平台的定价锁死，可以看看 [api.884819.xyz](https://api.884819.xyz) ——它聚合了主流大模型的API访问，按量计费，没有月租订阅，适合做这类多模型对比测试或团队级CI集成。国产模型（Deepseek、通义千问等）完全免费，新用户注册即送体验Token，注册只需用户名+密码，门槛极低。

---

五、结论与选择框架

决策树：什么时候用哪个模式？

这个PR是否涉及以下任意一项？
├── 并发/异步逻辑改动
├── 安全敏感路径（认证、支付、数据读写）
├── 重构或大范围逻辑调整
├── 上线前最后一次审查
│
├── 是 → 开高强度模式（接受3-4倍Token消耗）
│         ↓
│         安全类结果需人工二次确认，过滤误报
│
└── 否 → 默认模式足够
↓
简单迭代/样式调整/文档更新 → 默认模式

最终判断

高强度模式是真实的能力提升，不是噱头。在逻辑边界、竞态条件和性能隐患这三类问题上，它的发现率明显更高，而这些恰恰是人工审查最容易遗漏、上线后最难定位的问题类型。

但它不是银弹：

• 简单PR上开高强度模式是浪费，发现率和默认模式没有差异
• 安全类问题上误报率会上升，需要人工过滤
• 对特定语言的支持存在差异（实测Python和TypeScript表现较好，部分小众语言的分析深度有限）
• 上下文窗口仍然是硬限制，超大PR（1000行以上diff）的深度分析效果会打折扣

---

写在最后

Bugbot能发现的，是代码层面的问题——逻辑错误、边界条件、安全漏洞。但有一类问题它永远看不到：架构决策的隐患。

一个在代码层面完全正确的PR，可能建立在一个错误的技术方向上。当AI开始参与技术方案评审（而不只是代码审查），它的建议到底能不能信？怎么设计Prompt让它给出真正有用的架构反馈，而不是一堆正确的废话？

下一篇，我们聊这个。

---

#Cursor #AI代码审查 #Bugbot #开发工具 #AI编程 #代码质量 #8848AI #效率工具