用Cursor这么久，我才发现这3个模式不是随便切的

最新推荐文章于 2026-06-25 20:29:15 发布

原创最新推荐文章于 2026-06-25 20:29:15 发布 · 307 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能 #agent #cursor

AI使用技巧专栏收录该内容

4 篇文章

订阅专栏

上周末帮一个朋友调一个React组件，他盯了十分钟屏幕说：“这破Agent又在改无关文件了。”

我凑过去一看，他在写一个 onClick 处理器，明明就是两三行的事，他非要用 Cmd-I 切到 Composer 还勾了 Agent。我问他为什么，他说：“Agent看着牛啊，让它把整个组件优化一下不是更好？”

这就是大部分 Cursor 用户的真实状态：Tab、Composer、Agent 三个模式傻傻分不清，凭感觉切着用。早期我也是这么过来的，吃了不少亏。

今天把这些年的踩坑遇到的问题经验整理一下，帮你搞清楚这三种模式到底什么时候该用、什么时候千万别用。

一、先搞清楚这三个模式到底是什么

Cursor 这三个模式，本质上是三种粒度完全不同的工作流：

Tab 补全：单文件、单行、单函数的精准补全，模型只看当前文件上下文
Composer（Cmd-I）：基于任务意图的多文件编辑，能跨文件改代码但不会主动跑命令
Agent：一个能跑命令、读终端输出、装依赖、读 git 历史的"初级程序员"

用一个不太恰当的比喻：Tab 像你的结对编程伙伴，你写一行他补一行；Composer 像你的助手，你说一句"把这个函数重构一下"，他给你改好；Agent 像一个实习生，你说"做个登录页"，他真去 npm install、建文件、跑起来了。

搞清楚这层区别，后面才好选。

二、我踩过的三个最惨的坑

1：写小函数开 Agent，结果改了五个文件

最早用 Cursor 的时候，我沉迷 Agent 模式那种"全自动"的感觉。有一次写一个很简单的小工具函数：

// 我当时的需求
function formatDate(timestamp) {
  // 帮我补全一下时间戳格式化的逻辑
}

Tab 一下就能补完的事，我手贱切到 Agent，顺手输入：“帮我写个日期格式化函数，要支持时区。”

Agent 干了啥？它：

看了我的项目结构，发现已经有了一个 dateUtils.js
直接在那个文件里改了一通
还顺手把 package.json 里没用的 moment 依赖删了
跑了一下 npm test，发现有两个测试挂了，又开始改测试
改完测试发现还有别的文件引用了原来的 API，又开始改调用方

最后我只是想加一个 5 行的函数，它搞了 30 分钟动了 5 个文件，还给我提了一堆莫名其妙的 PR。

从那以后我给自己立了个规矩：改动预估不超过 20 行的，坚决用 Tab 补全。Tab 的好处是边界完全在你手里，它绝不会越界去动你没让它动的东西。

2：跨文件重构死磕 Tab，熬到凌晨三点

吸取了坑1的教训之后，我矫枉过正，有段时间啥都想用 Tab 解决。

公司有个老项目，要给所有 API 请求加上一个统一的请求头（公司安全合规要求），涉及 30 多个文件。本来 Composer 一句话就能搞定的事，我非要一个文件一个文件 Tab。

结果呢？

Tab 补全对"跨文件模式"的感知几乎为零，它不知道你刚在前一个文件加了什么
改了 20 多个文件之后，我发现有 5 个文件的命名风格和其他不一致
写了一半发现之前改的某个文件又出现了新的引用，得回头补
到凌晨三点我才搞了 60%，早上还得继续

这次教训让我明白：当你心里有个"全局计划"的时候，Tab 救不了你，你得让 Composer 看到全貌。

3：调 Bug 用 Composer，修出一堆新问题

Composer 是"基于任务意图"的，它会"想"你要什么。但它不会真的去验证自己改对了。

有一次生产环境报了一个空指针错误，定位下来是某个用户对象可能是 null。我用 Composer 改：

当 user 对象为 null 时，返回默认值而不是抛错

Composer 干了啥？它在函数入口加了空检查，完事。

但实际上，调用方传过来的 user 是有默认值兜底的，真正的 bug 在更上游的一个 service 内部——user 被替换成了一个空对象，字段都是 undefined。Composer 不知道这个上下文，它只看到了我描述的那一行代码。

我以为修好了，提了上线，第二天同一个地方又崩了，还多了一个用户反馈"之前能用的某个功能没了"——原来 Composer 在重构的时候顺手优化了一段逻辑，把一个看似冗余的判断去掉了，那个判断实际上是处理老版本数据用的。

这次教训让我学到：修 bug 的时候，如果你能明确指出 bug 在哪一行、应该怎么改，用 Composer；如果你还不确定根因在哪，老老实实用 Tab 局部改，别让 AI 帮你"顺手优化"。

三、我的判断标准（一个简单的决策树）

踩了这么多坑之后，我总结了一个特别简单的判断流程：

你这次的改动范围：
├─ 1 行内
│  └─ Tab 补全
│
├─ 1 个文件内，逻辑清晰
│  └─ Tab 补全 / Composer 都行
│
├─ 跨多个文件，但每个文件改什么你都想好了
│  └─ Composer（关闭 Agent）
│
├─ 跨多个文件，且具体怎么改你没完全想清楚
│  └─ Composer + Agent，但先在 dry-run 模式确认计划
│
└─ 全新功能、新模块、有依赖要装
   └─ Agent（开 YOLO 模式 + 人在旁边盯着）

简单说就一句话：你越清楚要改什么，就用越"笨"的模式；你越需要 AI 帮你想，就用越"聪明"的模式。

四、一些不太明显的细节

几个我后来才注意到的点：

Composer 也可以单文件用，不一定要多文件。不要因为"反正就改一个文件"就非用 Tab，有时候 Composer 一次生成的代码质量比 Tab 一次次猜要稳定。
Agent 模式吃 token 巨狠。Agent 要读终端、读 git、读依赖列表，每次操作的 context 是 Tab 的几十倍。日常用 Tab 或者 Composer 就行，Agent 只在"实在懒得自己动手"的时候用。
Agent 模式开 YOLO 之前，先看看它会跑什么命令。Cursor 0.45 之后有个 auto-run 的设置，第一次使用 Agent 模式建议把"自动跑命令"关掉，先让 Agent 把要执行的命令列出来给你看一眼，再决定要不要放行。
Composer 的 .cursorrules 比 Agent 的 .cursorrules 影响大。因为 Agent 会自己改自己看的规则文件……这个坑下次专门写一篇。
三种模式不是互斥的。我现在的日常是：Tab 写主体 → Composer 调整结构 → Agent 跑一下测试、补一下文档。一个项目里三种模式都在用，根本不是二选一。