AI写代码，AI做审查。Money Forward 1000人、PlanetScale削减2FTE的现场到底发生了什么

「Composer 2的真面目，其实是Kimi K2.5」——TechCrunch发出这篇报道的2026年3月22日，我正在读一份一手数据。

那是海外数据库SaaS企业PlanetScale发布在Cursor官方博客上的一份报告。

“Code has become cheap. The bottleneck is now whether your code is correct and whether you understand what it does.”

「代码变便宜了。瓶颈现在变成了：你的代码是否正确，以及你是否理解它在做什么。」

我觉得这句话简明扼要地说明了Vibe Coding（与AI对话式编程的风格）已经进入了下一个阶段。

「能快速写出来」已经达成了。下一个问题是「能不能放心交给它」。

这次我会连同Composer 2发布后引发的争议一起，用数据解读这一变化的本质。从PlanetScale和Money Forward的一手数据，到如何在团队中落地的实战设计，都会一一覆盖。

---

Bugbot的当前位置——解决率76%、月处理200万PR的「现在」

Cursor Bugbot是一款能够自动审查Pull Request（PR：代码变更提案）并检测、修复Bug的AI Agent（自主运行的AI程序）。

请看一下2026年2月25日正式发布的当前版本的数字。

• 解决率：76%（从最初的52%出发，经过40轮改进实验达到）
• 月处理量：每月200万个Pull Request
• 自动合并率：Autofix的提案中有35%被直接合并到主分支

Bug发现数量几乎是旧版本的两倍。35%的自动合并率，意味着「AI修复的代码，几乎被人类原封不动地采用了」。

价格是每用户每月40美元（与Cursor本体分开计费），按每用户每月200个PR的池子供应。面向企业还提供了无限量套餐。

Rippling、Discord、Samsara、Airtable等公司已经引入。University of Chicago（芝加哥大学）的调查显示，将Bugbot设为默认审查者的企业，PR合并数量增加了39%。

针对「审查成为瓶颈，导致开发速度变慢」这一现场难题，Bugbot正在成为一个结构性的答案。

# 将Bugbot设置为默认审查者并与GitHub集成的配置示例
# .cursor/bugbot.yaml

bugbot:
  default_reviewer: true   # 自动为所有PR添加Bugbot
  autofix: true            # 对可修复的Bug自动创建Autofix PR
  severity_threshold: medium  # 报告medium级别以上的Bug（低于此级别跳过）
  languages:               # 明确指定目标语言
    - typescript
    - python
    - ruby

---

PlanetScale的证言——「削减2FTE」的真实内容

PlanetScale是一家提供MySQL兼容云数据库的企业，客户包括GitHub、Stripe等大型服务。

该公司引入Bugbot后，作为案例研究发布在Cursor官方博客上的数据如下。考虑到这是发布在自家媒体上，发布的语境对企业方较为友好，请读者留意这一点。不过，PlanetScale和Money Forward都是以实名披露，数据造假会直接影响企业信誉。作为参考信息，仍具备一定的可信度。

• 80%的Bugbot评论 在合并前已被处理
• 代码审查工时减少 相当于2FTE

FTE（Full-Time Equivalent：全职员工换算）是以一名全职员工的工时作为1FTE的单位。也就是说，Bugbot承担了相当于两名全职员工的代码审查工时。

为什么会出现这么显著的效果？背后的原因是AI Agent写出来的代码量呈爆发式增长。

在代码以人类书写的速度增长的时代，人类审查者还能勉强跟上。一旦AI开始写，速度就提升了10倍以上。审查者突破处理极限只是时间问题。

「代码变便宜了」的含义正在于此。生产成本下降的同时，质量保证的成本相对上升了。PlanetScale所面对的正是这个问题，而Bugbot正作为它的解决方案在发挥作用。

还有一个值得关注的点是「代码是否正确」这一问题。Vibe Coding大量产出的代码，可能虽然能跑但很危险。Sia Partners（战略咨询公司）2026年3月发布的调研指出，虽然AI编程带来了速度的暴增，但「组织能够捕获的价值并未跟上」。他们称之为「生产力悖论」。

Bugbot通过检测和修复76%的Bug，承担了填补这一「可捕获价值差距」的角色。

# Bugbot实际的审查评论示例（来自Cursor官方博客）
# PR：用户认证处理的重构

# Bugbot的指摘示例:
# 🔴 High severity：SQL注入漏洞
#    Line 42: f"SELECT * FROM users WHERE id = {user_id}"
#    Fix：请使用占位符
#    ↓
#    cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# 🟡 Medium severity：未处理的异常
#    Line 67: db.connect() 的返回值没有错误处理
#    Fix：用try/except包裹并适当记录日志

# 如果Autofix可适用，会自动创建PR

---

Money Forward中1000人使用的理由——向工程师以外的扩散

Money Forward的数据则展示了另一个视角。

根据该公司MEPAR（Money Forward Engineering Productivity & AI Research）部门的报告，目前超过1000人每天都在使用Cursor。令人惊讶的是它的构成。不仅是工程师，PM（产品经理）、设计师、QA（质量保证人员）也都在使用。

定量效果的数字如下。

• 工程师每周节省 15〜20小时
• QA团队的测试用例生成时间 削减70%

每周15〜20小时大约相当于一周实际工作时间的40%。也就是说，近一半的时间可以用在其他事情上。

Money Forward选择Cursor的官方理由之一是「模型无关的基础设施」。由于结构上不依赖特定的AI模型，即使遇到Composer 2这样的模型更新，也可以不改变业务流程地迁移。

「向工程师以外的扩散」这一点，特别戳到了我。作为CS（客户成功）出身的人，「工具超出了工程师领域」这一事实，意味着组织的变化。当PM和QA离代码越来越近，他们与工程师之间的认知偏差就会减少。整个团队对质量的敏感度也会提高。

「能让自己的工作自动化的人」的定义，正在发生变化。

---

解读Composer 2的争议——透明度问题的本质

2026年3月19日发布的Composer 2，伴随着架构的大幅变更。

主要规格如下。

• 基础模型：Moonshot AI的Kimi K2.5（任何人都可以查看内部结构的开源AI模型）
• 上下文长度：200,000 token（一次可处理约15万字的上下文）
• 价格：Standard每百万token 0.50美元，比Composer 1.5便宜86%
• 基准测试：在Terminal-Bench 2.0上超过Claude Opus 4.6

问题在于，Cursor最初并没有披露「基础模型是Kimi K2.5」。

3月22日，TechCrunch发布了题为「Cursor admits its new coding model was built on top of Moonshot AI’s Kimi」的报道，引发了舆论风波。随后Cursor承认了事实，并补充说明「持续预训练和RL所投入的计算成本中，约75%来自Cursor方」。

在我看来，这不是「欺诈」，而是「沟通失败」。虽然不是从零开始构建，但Cursor的独立调优确实带来了实质性的性能差距。基于开源模型由企业进行独立训练，如今已经是普遍做法，至于该披露到什么程度，业界尚未形成统一规范。

从这次风波中，可以得到一个实务层面的启示：比起模型的出身，按性能来判断才是务实的做法。

# Composer 2 价格对比（截至2026年3月）

# Standard模式
# 输入: 每百万token 0.50美元
# 输出: 每百万token 2.50美元
# 用途：草稿生成、大批量文本处理

# Fast模式
# 输入: 每百万token 1.50美元
# 输出: 每百万token 7.50美元
# 用途：复杂的多文件编辑、需要实时响应的场景

# 从Composer 1.5到2的变化
# 成本：-86%（Standard对比）
# 上下文：100K → 200K token
# 基准测试：在SWE-bench Multilingual上大幅提升

---

Automations × Bugbot的全栈设计

2026年3月3日发布的Cursor v2.6中包含的「Automations」，与Bugbot结合才能发挥真正的价值。

Automations是一个以Slack、Linear（项目管理工具）、GitHub、PagerDuty（事故管理工具）等的事件作为触发器，自动启动Cursor Agent的机制。说成「代码审查流水线的自动化」会更容易理解。

实际的流程是这样的。

1. GitHub上创建了一个PR
2. Automations触发并启动Cursor Agent
3. Agent解析代码并请求Bugbot审查
4. Bugbot自动解决76%的问题并创建Autofix PR
5. 剩下的24%才由人类来审查

这个流程跑起来之后，人类需要集中精力的部分，从「全部审查」变成了「复杂判断的24%」。在团队中运作时，这个变化是巨大的。

我实际试用后发现，PR第一轮审查所花的时间，感觉减少了一半以上。有错误的地方Bugbot已经提前指出，人类审查就集中在「确认和设计层面的讨论」上。

# .cursor/automations.yaml 配置示例（面向团队运营）
automations:
  - name: pr-review-pipeline
    trigger:
      event: github.pull_request.opened    # PR被创建时
      filter: "draft: false"               # 排除草稿PR
    steps:
      - agent: code-review
        action: analyze_changes            # 解析差异
        options:
          check_security: true             # 启用安全漏洞检查
          check_performance: true          # 检查性能问题
      - agent: bugbot
        action: scan_and_fix              # Bug扫描+Autofix
      - notify:
          channel: slack                   # 将结果通知到Slack
          template: "bugbot-summary"       # 使用摘要模板

「居然能配置到这种程度？」可能会有人这样想。最初我也是半信半疑。但看到Money Forward和PlanetScale的实绩，就知道这不是空中楼阁。团队规模越大，这套流程的收益就越大。

---

「质量保证阶段」的3个设计原则

作为实践篇，分享一下将Vibe Coding从「能快速写出来的阶段」过渡到「能放心交给它的阶段」所需的3个原则。

原则1：将人工审查设计为「异常处理」

Bugbot的Autofix率是35%。换句话说，65%是需要人类判断的。如果想把所有事都丢给AI，就会在这65%上栽跟头。

建议事先把「AI可以处理的问题」和「应该由人类判断的问题」列出来。比如，安全要求、性能要求、业务逻辑变更必须由人类审查，这样划清界限。

把这份清单在团队内共享，也能防止审查工作集中在某一个人身上。

原则2：制作不依赖模型的配置文件

正如Composer 2的风波所示，模型是会变的。Money Forward坚持「模型无关的基础设施」，理由就在这里。

把Prompt模板和配置文件纳入Git管理，即便模型变了，业务流程也不需要变。

# 用Git管理团队Cursor配置的结构示例
# .cursor/
#   ├── bugbot.yaml          # Bugbot配置（severity阈值、目标语言等）
#   ├── automations.yaml     # Automations配置（触发器和动作）
#   ├── rules/               # 编码规范
#   │   ├── typescript.md    # TypeScript专属规则
#   │   └── security.md      # 安全要求
#   └── prompts/             # 团队共享Prompt
#       ├── code-review.md   # 审查视角的Prompt
#       └── test-gen.md      # 测试生成的Prompt

# 提交示例
git add .cursor/
git commit -m "chore: add team cursor config for review pipeline"

原则3：关注「写出的代码量」与「能发布的代码量」的比例

正如Sia Partners指出的「生产力悖论」，即使速度提升，如果质量保证跟不上，代码也只会越堆越多。

建议每月确认一下「提交次数」与「最终发布到产品的代码量」的比例。如果Bugbot×Automations的设计在发挥作用，这个比例就会改善。如果没有改善，就需要检查Bugbot的阈值设置或Automations的流程。

---

总结——超越「速度」之后的问题

把这次涉及的数字整理一下。

指标	数值	表明的含义
Bugbot解决率	76%	AI审查已进入实用阶段
Autofix自动合并率	35%	AI的修复已达到可直接采用的水平
PlanetScale FTE削减	相当于2FTE	审查工时正在被结构性地替代
Money Forward引入规模	超过1000人	已进入向工程师以外人员扩散的阶段
Composer 2成本降低	便宜86%	形成了可以更大规模、低成本使用的基础

Composer 2的风波被报道为「透明度问题」，但从实务角度判断的指标其实是基准测试和成本。比Composer 1.5便宜86%、Terminal-Bench顶级分数的事实，作为选择标准才更为重要。

「能用Vibe Coding写出来」许多人已经能做到了。下一道门槛已经变成「能否在团队中运用」「能否保证质量」「自己是否理解写出代码的含义」。

借用PlanetScale的话说，正因为「代码变便宜了」，被追问的才是准确性和理解。Bugbot×Automations×Composer 2的组合，我认为是迈向那个阶段的现实入口。

CS出身的我之所以用「在团队中推广」的视角看待工具，是因为如果只有自己变快、组织的产出跟不上，就毫无意义。能否将速度带来的红利传递给团队，正是下一个问题。

---

参考・出处

• Cursor Blog「Bugbot Autofix is now generally available」(2026-02-25)
• Cursor Blog「PlanetScale: Cursor in Production」(cursor.com/blog/planetscale)
• Cursor Blog「Money Forward: Cursor in Production」(cursor.com/blog/money-forward)
• Cursor Blog「Introducing Composer 2」(cursor.com/blog/composer-2, 2026-03-19)
• TechCrunch「Cursor admits its new coding model was built on top of Moonshot AI’s Kimi」(2026-03-22)
• Cursor Changelog v2.6 — Automations (cursor.com/changelog, 2026-03-03)
• Sia Partners「Vibe Coding生产力悖论」(2026-03)
• University of Chicago调查数据（引自 cursor.com/blog/bugbot-autofix）