两个工具,两种脾气
过去一年我同时深度使用 Cursor 和 Claude Code。一个是 IDE,一个是 CLI 加 Agent,定位并不重叠。在某科技公司的统一认证中心、知识库问答服务后端,以及 alchemy-furnace 全栈项目里,我慢慢形成了「日常写代码用 Cursor,复杂重构和跨服务任务用 Claude Code」的组合,而不是二选一。
各干各的活
Cursor 的 Tab 补全和 Cmd+K 内联编辑最跟手。写熟悉的业务代码、前端 JSX、SQL 时效率极高,适合「我知道要写什么,只是想快一点」。Claude Code 的 Plan 模式、子任务和工具调用(Bash/Read/Edit)适合另一类活:「我知道目标,但需要它自己摸代码、跑测试、改一轮」,比如跨多个微服务加一个字段、批量修复 lint、写数据迁移脚本。
两份规则文件
Cursor 的 .cursorrules:
| |
Claude Code 的 CLAUDE.md 在上一篇已经展示过,重点是项目结构、命令和领域术语。两份文件内容不同,思路一致:把团队约定固化下来,而不是每次靠 prompt 提醒。
两个工具我都要求同一件事:改完代码自己跑测试。Cursor 用 Composer 执行 go test ./...,Claude Code 直接调 Bash 工具,看到失败再回头改。
踩过的坑
第一,上下文管理思路不同。Cursor 靠 @file、@git、@docs 手动引用,精确,但前提是你得知道该引用什么;Claude Code 会自己 grep 和 read,容易把上下文撑爆,得靠 Plan 模式和子任务控制范围。
第二,补全质量。Cursor 在短片段补全上更跟手,尤其前端 props;Claude Code 不做实时补全,但整段生成和跨文件重构更强。
第三,价格与合规。Cursor 可以切不同模型,但企业代码要考虑合规;Claude Code 走我自己的 API Key 或订阅,代码不外传到第三方索引,对公司项目更安心。我们在统一认证中心项目里明确禁止把含密钥或客户数据的文件贴到任何 SaaS 工具。
第四,终端场景。Claude Code 在服务器、容器、tmux 里能直接跑,改 KubeSphere 部署脚本、调试线上 Pod 时比 SSH 加本地 IDE 方便;Cursor 需要本地有仓库或 Remote-SSH。
第五,别迷信任何一个工具。我见过同事一路 Tab 出几百行没跑过的代码,也见过让 Agent 自主改一下午、最后全是幻觉 API 的。生成越顺手,检查越不能省。
第六,两者都需要一份清晰的项目规则文件。没有 .cursorrules 或 CLAUDE.md,它们都会按「通用最佳实践」写,和你项目的真实风格完全不搭。
我的组合
Cursor 当主力编辑器,处理日常 CRUD 和前端;Claude Code 当 Agent,处理跨文件、跨服务、需要自己跑命令的任务。两个工具都配好项目规则,都要求改完自跑测试,都不让它碰密钥。这三个「都」,比选哪个工具更重要。
封面图:MattsMacintosh / Flickr · CC BY 2.0
