这篇文章能帮你搞清楚什么
- Claude Code 的价格与导入讨论目前到了哪一步
- 哪一种方案或导入阶段更适合当前处境
- 下一篇该看哪篇，才能继续补齐费用、上手或全局理解
上周的文章里我写过「让我对 Vibe Coding 感到疲惫的原因并不是工具本身」这件事。看完文章的读者中有几位问我:「那到底该用什么呢?」
就在那个时候,正好有一份让我在意的数据公开了。
Pragmatic Engineer(实用工程师)这份全球工程师都在阅读的技术 Newsletter,公布了一份针对 906 名开发者的调研结果(2026 年 3 月公开)。结果相当震撼。
「最喜爱的 AI 编程工具」排名第一的是 Claude(克劳德) Code(克劳德编码),占比 46%。Cursor(光标)是 19%,GitHub Copilot(GitHub 副驾驶)是 9%。
Claude Code 是在 2025 年 5 月发布的。仅仅 8 个月,就以两倍以上的差距反超了原本领先的 Cursor。
不过,真正让我在意的并不是「46% 和 19%」这两个数字本身,而是「为什么会迁移」这一原因。
本文将基于调研数据,把「哪个更好」这种争论先放在一边,从三个维度梳理 906 名开发者做出选择的理由。读完之后,你应该能找到适合自己选工具时使用的判断标准。
8 个月发生逆转:Pragmatic Engineer 调研到底是什么
首先梳理一下这份调研的概要。
Pragmatic Engineer 是全球阅读量最高的面向软件工程师的 Newsletter 之一。作者 Gergely Orosz(盖尔盖伊·奥罗斯)是前 Uber 工程师,以详细解读 Uber、Booking.com、Microsoft 等公司工程组织内部情况而闻名。
读者群主要是「专业开发者」。本次调研(AI tooling in 2026)于 2026 年 1 月 27 日至 2 月 17 日期间实施,共收到 906 份回答。
调研结果的主要数据如下。
| 工具 | 「最喜爱」的比例 |
|---|---|
| Claude Code | 46% |
| Cursor | 19% |
| GitHub Copilot(副驾驶) | 9% |
| 其他 | 26% |
Claude Code 在 2025 年 5 月发布。同年年底已经在业界引起广泛讨论,而本次调研以「数字」的形式将这场逆转可视化了出来。
AI 整体的使用情况也很有意思。调研中 95% 的受访者回答「每周至少使用 1 次 AI」,75% 回答「工程业务中有一半以上都在使用 AI」。不使用 AI 进行开发的人已经是少数派——这就是这份调研的起点。
更进一步,70% 的人同时使用 2 到 4 款工具,15% 使用 5 款以上。比起「选 Claude Code 还是 Cursor」,「如何组合搭配」才更接近现场实际情况。这一点在后半部分会详细展开。
因素①:任务能在多大程度上「委托」出去
从调研数据和现场反馈中浮现出的第一个迁移理由维度,是「任务委托的深度」。
Cursor 是嵌入 VS Code(编辑器)中的 AI 编程辅助工具。接收代码建议,确认 diff,通过一键点击选择采纳或拒绝。以视觉反馈为中心,设计目标是「提升你自己写代码的速度」。
Claude Code 则是运行在终端(命令行)上的 AI 智能体。它不仅写代码,还能自主执行 git 提交、跑测试、部署等操作。它的设计更接近「把任务交出去等待完成」,而非「辅助你写代码」。
这个差异极大地改变了使用感受。
使用 Cursor 时,我的感觉像是「副驾驶」。AI 坐在我旁边,提出建议,我来判断是否采纳。我自己是司机,AI 是副驾驶。
使用 Claude Code 时,感觉就变了。我在终端里输入「请实现这个功能」,然后去倒杯咖啡。回来后代码已经写好了,测试也通过了。我自己变成了 PM(项目经理),而 AI 成了实现团队。
这种「委托的深度」决定了一个人会偏爱哪款工具。
「想自己写代码」「想边确认 diff 边把控质量」的人,Cursor 的视觉反馈更合适。「想把任务交出去只收结果」「希望文件结构和 git 操作也交给 AI」的人,Claude Code 的终端集成就发挥优势了。
作为一名曾经挫败过的工程师,老实说,我第一次用 Claude Code 时有点害怕。「在终端里做所有事」,这正是过去的我不擅长的世界。但真正用起来后,反而发现「不需要自己操作终端」,门槛反而降低了。
下面是一段展示 Claude Code 典型指令流程的代码。**对终端或代码不熟悉的读者可以跳过这一段。**只要能感受到「写完指令就有可运行的东西出来」这个画面就足够了。
# Claude Code 中的典型指令流程
# 在终端启动 claude,只需用自然语言写指令即可
$ claude
# 提示词示例:
# 「请在 src/api/users.ts 中添加用户删除接口。
# 按照现有 CRUD 实现的风格,顺便写好测试。
# 完成后请帮我 git commit」
# → Claude Code 会自动完成实现、测试编写、提交全流程我的立场是「能跑的代码胜过完美的代码」,而「下达指令就有可运行成果出来」这种体验,对于断档型工程师来说是最戳心的。
因素②:Token 成本的现实。33,000 vs 188,000 的差距
第二个维度稍微涉及一些技术话题,即「Token 效率」。不过你只需要知道数字就够了。
开发者社区中广为讨论的对比测试显示,同一任务下消耗的 Token 数差出了约 5.5 倍。Claude Code 约 33,000 Token,Cursor 约 188,000 Token。(此数据来源于社区实测报告,并非官方基准测试,请作为参考值理解)
「Token」是 AI 处理文本的单位(类似字符数)。通过 API 使用 AI 时,成本由消耗的 Token 数决定。
这个差距是从何而来的呢?
Cursor 嵌入在 IDE 中,经常会把编辑器中打开的文件内容整个发给 AI。由于「边展示代码边给建议」的设计,会持续发送超过必要量的上下文(背景信息)。
Claude Code 运行在终端,会自己判断「当下需要什么」,以最小化的上下文进行处理。虽然上下文长度最大支持 100 万 Token 非常大,但不会浪费地使用。
对于直接承担 API 成本的个人开发者或初创公司而言,这种差距会真切地影响钱包。Claude Code Pro 订阅(月费)和 API 按量付费哪个更划算取决于使用方式,但「集中处理重任务」时,Claude Code 在成本效率上的优势往往更明显。
还有一点是关于上下文长度的。
在处理大型代码库(跨多个文件的实现)时,AI 是否能在「理解整个项目」的状态下回答你,会产生差异。上下文长度越长,越能回答「这个文件在哪里被引用?」「这个函数在整个项目里是怎么被使用的?」这类问题。
从我做业务工具开发的实际感受来看,像电子表格联动的 Slack Bot(数个文件构成)这种规模,Cursor 和 Claude Code 都不会有太大差距。但开发对接多个 API 的内部 Dashboard 时,Claude Code「在把握整个项目的基础上回答」的体验明显帮了大忙。
下一段代码是请求跨多文件修改的示例。**不熟悉代码的读者也可以跳过。**只要能感受到「可以把多个文件一起交出去」这个意思就够了。
// 示例: 委托跨多个文件的修改时
// 给 Claude Code 的指令示例
// 「请一起读 src/components/Dashboard.tsx、
// src/hooks/useAnalytics.ts 和
// src/api/metrics.ts,
// 并为 API 响应添加缓存策略」
// → Claude Code 会跨文件理解,
// 返回一致性的实现
// Cursor 的情况:
// 对于打开的文件表现优秀,
// 但跨多文件的「整体把握」上 Claude Code 更胜一筹不是「谁更强」,而是「根据项目规模不同,成本效率会变化」——这才是关键。
因素③:企业规模决定「契合度」。初创公司 75% 的理由
第三个维度是企业规模与用途。
本次调研中最有意思的分歧就在这里。(以下数据是 Pragmatic Engineer 调研中按受访者属性进行汇总后所报告的趋势值。请注意根据企业规模定义和回答分布的不同,数据存在浮动可能)
| 企业规模 | Claude Code | Cursor | Copilot |
|---|---|---|---|
| 小型初创公司 | 75% | 42% | 较低 |
| 大企业(1 万人以上) | 较低 | 中等 | 56% |
初创公司 75% 选择 Claude Code,大企业 56% 选择 Copilot。为什么会这样?
大企业有信息安全和管控的需求。GitHub Copilot 与 GitHub 企业合约一体化,管理员可以掌握整个团队的使用情况,IT 部门也更容易审批通过。在重视「能在组织层面进行导入管控」的环境中,Copilot 优势明显。
初创公司则优先考虑速度和灵活性。这种文化下,「能用的人用最好的工具」很普遍。Claude Code 通过终端即可使用,几乎不需要特别的环境配置。「就想动手做点东西」的个人开发者,可以凭自己的判断轻松导入。
另一点,任务的性质也有关系。
大企业的开发现场,「在已有的大规模代码库上做修改」这类工作占多数。代码评审文化已经建立,有一套仔细审查 diff 的流程。Cursor 的「视觉确认 diff + 一键审批」的设计,与这种工作流非常契合。
初创公司的早期开发,则常常处在「从零开始造东西」的阶段。快速做出可运行的原型,边跑边改。Claude Code「把任务交出去等待完成」的设计,正好适合这种循环。
就我自己而言,客户成功部门的业务工具开发几乎是「自己一个人的项目」。也没有同事帮我做代码评审。比起「审批工作流」,「能不能产出可运行的东西」更重要,所以 Claude Code 的设计正好契合我的处境。
我相信有不少人「身在大企业但想用 Claude Code」。实际上,在个人笔记本或验证环境里使用的情况也不少。但如果要把含有业务数据的代码交给 AI 处理,请一定先确认贵公司的安全策略。
下一段代码是业务工具开发的典型案例。同样**不熟悉代码的读者可以跳过。**仅对「向 Claude Code 用自然语言下达指令后会得到怎样的代码」感兴趣的读者可以看一下。
# 业务工具开发典型示例: 电子表格→Slack 通知机器人
# 给 Claude Code 的指令:
# 「请写一个脚本,从 Google Sheets 读取特定列的值,
# 将满足条件的行通知到 Slack 的指定频道。
# 认证信息从 .env 文件中读取。
# 能在本地运行即可,无需部署」
# → 会生成如下代码
import os
from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
from slack_sdk import WebClient
from dotenv import load_dotenv
load_dotenv()
def check_sheet_and_notify():
# 初始化 Google Sheets API
creds = Credentials.from_authorized_user_file('token.json')
service = build('sheets', 'v4', credentials=creds)
# 从表格中获取数据
sheet = service.spreadsheets()
result = sheet.values().get(
spreadsheetId=os.getenv('SPREADSHEET_ID'),
range='Sheet1!A:E' # 获取 A 到 E 列
).execute()
values = result.get('values', [])
# 条件检查(示例: D 列为「待处理」的行)
slack_client = WebClient(token=os.getenv('SLACK_BOT_TOKEN'))
for row in values[1:]: # 排除表头行
if len(row) > 3 and row[3] == '待处理':
message = f"【待处理】{row[0]} 提交了咨询({row[2]})"
slack_client.chat_postMessage(
channel=os.getenv('SLACK_CHANNEL_ID'),
text=message
)
if __name__ == '__main__':
check_sheet_and_notify()能不能体验到「可运行的代码真的出来了」,会极大影响你对工具的评价。在业务工具开发的起步阶段,Claude Code「把任务整体交给 AI」的风格非常合适。
那么,自己到底该选哪一个?三轴判断标准
接下来进入「弄明白了三个因素,但到底该选哪一个?」这部分。
不存在「哪个更好」的标准答案。即使看调研数据,对那 906 名迁移者来说,Claude Code 只是「最喜爱的」工具而已,并不意味着 Cursor 不好。
把自己的情况按三个轴梳理一下,判断会更清晰。
轴 1: 主要做什么样的工作
如果以「对已有代码进行追加、修改」为主,Cursor 的「diff 确认 × 一键审批」更顺手。如果是「从零做新功能」「把跨多文件的大型实现交给 AI」,Claude Code 更合适。
轴 2: 是否想边看代码边工作
想保留「自己在写代码」感觉的人,Cursor 更合适。「只要产出成品,过程不限」的人,Claude Code 压力更小。
轴 3: 使用的编辑器和工作环境
如果你用 VS Code 并且在团队里开发,Cursor 几乎可以原样沿用 VS Code 的配置。如果你是个人开发,对编辑器没有偏好,Claude Code 只在终端中即可完成所有操作,环境配置更轻松。
如果工作场所的安全策略规定「禁止使用 GitHub 企业版以外的 AI 工具」,那只能选 Copilot。在没有这种约束的个人开发者或初创公司环境中,这三个轴就有了选择的余地。
在「选哪个」之前,先确认「自己的状况」更重要。906 人的调研数据是「处于这种状况的人选择了 Claude Code」的参考信息,而不是「不用 Claude Code 就会被淘汰」的恐吓。
多工具策略的现实:70% 的人同时使用 2 到 4 款工具
调研数据中还有一个容易被忽略的数字。
70% 的人同时使用 2 到 4 款工具,15% 使用 5 款以上。「二选一」这个前提本身,就和现场实际情况有些偏离。
实际上,调研中也有多人表示「Claude Code 和 Cursor 搭配使用是理想方案」。日常编程(IDE 上的细微修改、补全)用 Cursor 的速度更舒服;「把大任务整体交出去」「让 AI 思考复杂的设计」时,Claude Code 更有优势——这是分工方式。
我自己也是这么做的。
把 Cursor 作为主力编辑器,只在「这个功能要从头设计太麻烦」的时候切换到 Claude Code。90% 的日常工作用 Cursor 快速推进,把那 10% 的重任务交给 Claude Code,就是这个感觉。细微的修改 Cursor 压倒性地更快,「想用眼睛追踪 AI 是怎么改这段代码的」场合也存在。反之,「只给规格,实现交给 AI」这种大任务,Claude Code 更轻松。一旦习惯了这种分工方式,就不想退回到任何一方独用的状态了。
为了统一这种「跨 IDE 配置」,最近常被使用的是 CLAUDE.md 和 AGENTS.md 两文件策略。
# CLAUDE.md 示例(放在项目根目录)
## 项目概述
面向客户成功部门的内部 Dashboard。
React 前端 + FastAPI 后端。
## 编码规则
- TypeScript strict 模式开启
- 组件使用 function 声明(不使用箭头函数)
- API 响应使用 zod 进行验证
## 使用的技术版本
- React 18.3.1
- FastAPI 0.115.0
- Python 3.12
## 常用命令
- 启动开发服务器: npm run dev
- 执行测试: pytest tests/ -v
- 类型检查: npx tsc --noEmit
## 注意事项
- 不要把 .env 文件中的值直接写进代码
- API Key 全部通过 os.getenv() 获取把 CLAUDE.md 放在项目根目录后,Claude Code 在项目启动时会自动读取。Cursor 和 GitHub Copilot 也有 .cursorrules 或 .github/copilot-instructions.md 等类似机制。
让「本项目规则」统一传达给任何工具,可以降低切换工具的成本。
通过多工具策略,我亲身体会到的是:「工具之间不是竞争关系,而是可以分工的」。Cursor 的「IDE 集成的速度」和 Claude Code 的「深度推理与自主执行」,擅长的任务并不相同。结合两者的强项,实际开发速度比只用其中一款要更快。
不过,订阅成本会累加。同时使用 Claude Code Pro 和 Cursor,每月可能要支付几千到上万日元。「只用一款够不够」这件事,最好试一试再做判断。两款工具都提供免费试用或一定的免费额度。
总结:这不是「迁移」,而是「选择」
906 人的调研所揭示的并不是「应该迁移到 Claude Code」。
而是「什么样状况的开发者、出于什么理由选择了 Claude Code」的数据。我把这些理由从「任务委托的深度、Token 效率、企业规模与用途」三个维度做了梳理。
上周的文章里我写过「Vibe Coding 的疲劳并非来自工具,而是设计问题」。如果设计问题没解决,换工具也不会消除疲劳。但在解决设计问题的同时,保留「选择适合自己状况的工具」这个视角,仍然是有价值的。
我实际使用后的结论是:「Claude Code 对挫败型工程师很友好」。
即使你有「终端令我害怕」的感受,「写下指令就能产出可运行的东西」的体验,也会淡化你对终端的抵触。「即使不懂代码也能通过指令方式来弥补」这种感觉,成为了我重启 Vibe Coding 的起点。
Cursor 是「让会写代码的人提速」的工具,Claude Code 是「即使不写代码也能做出可运行成果」的工具。这就是我的整体印象。
本周建议尝试的 3 件事
- 记下一个在你当前工具(Cursor/Copilot)中感到「这里有点别扭」的场景。比如「边看建议边确认很麻烦」「多文件修改很费劲」「从零做新东西太慢」等,用具体的语言描述出来,下一步就会更清晰
- 用 Claude Code 的免费额度(或 Pro)把那个「别扭的任务」试着丢过去一次。第一次用小任务就行。「写一个整理电子表格数据的脚本」之类的开始体验,成本很低
- 比较的不是结果,而是「下达指令时的手感」。那才是工具选择的起点
不是「46% 都选了所以我也该换」,而是「让自己工作更轻松的选项变多了」——这种心态最实用,我是这么认为的。
正因为有过挫败经历,「看起来好难」的感觉我比任何人都懂。但只要哪怕体验一次「只要下指令就有可运行成果」的感觉,这种感受一定会改变。906 人的数据证明的不是工具的优劣,而是「什么状况的人会被哪款工具打动」。请务必用三轴框架确认一下你自己的状况。
参考资料:
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
