Cursor Composer 完全指南：多文件编辑技巧与实战案例

说实话，我用了三个月 Cursor，才发现自己一直在”浪费”它。

之前改功能，需要修改 5 个文件：组件、API、类型定义、测试、配置。我就在 Chat 里一个个问，一个个复制粘贴代码。鼠标在文件之间来回切换，手指在 Cmd+C 和 Cmd+V 之间反复横跳。累。

有一天同事路过看到我这么操作，盯着我的屏幕看了三秒，说：“你怎么不用 Composer？”

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

“啊？”

“Cmd+I 那个浮动窗口，一句话描述需求，AI 自动识别要改哪些文件，全部改完。”

我当时就呆了。

他给我演示了一遍：打开 Composer，@ 引用几个相关文件，输入”把这个用户登录逻辑改成支持邮箱验证”，回车。AI 思考了几秒，一口气把组件、API、类型定义全改了。10 分钟搞定。

我之前花了 1 小时。

那一刻我突然意识到，这三个月我只用了 Cursor 20% 的能力。就像开着法拉利只用一档。

Composer 是什么？为什么你需要它

Composer vs Chat 的本质区别

先说个比喻。

Chat 就像一个 AI 顾问，坐在你旁边回答问题。你问它”这段代码怎么优化？“，它给你建议，你自己动手改。

Composer 是个 AI 施工队。你说”把这栋楼的所有窗户换成落地窗”，它直接动手，改完告诉你”搞定了，你验收一下”。

这是本质区别：一个是顾问，一个是施工队。

具体对比看这个表：

看到那个”对话历史不保存”了吗？这是我踩过最大的坑，后面会专门讲怎么避。

Composer 的三大核心能力

能力 1：跨文件理解

Chat 只能看到你当前打开的文件。Composer 能看到整个项目。

举个例子。你说”添加用户登录功能”，Chat 会问你”具体要改哪个文件？“，Composer 直接告诉你”我需要改这 5 个文件：Login.tsx、auth.ts、user.types.ts、api/auth.ts、App.tsx”。

它知道组件在哪、类型定义在哪、API 在哪、路由在哪。都给你改了。

能力 2：项目级修改

Chat 改代码，你得手动复制粘贴。Composer 改完直接应用到文件，你只需要点 Accept 或 Reject。

这个区别就像：Chat 是给你一张装修图纸，Composer 是把装修做完了给你验收。

能力 3：智能推理（Agent 模式）

开启 Agent 模式后，Composer 能做这些事：

• 运行 shell 命令（比如 npm install、git status）
• 搜索整个代码库（找出所有用到某个函数的地方）
• 自主分析依赖关系
• 创建或删除文件

Agent 模式就像给施工队配了个包工头，能自己做判断、自己找工具。但也更容易”过度装修”，后面会讲怎么控制。

必须用 Composer 的 3 个场景

场景 1：新功能开发（涉及多文件）

需求：添加评论功能。

Chat 做法：

1. 问 Chat 要改哪些文件
2. Chat 列出 5 个文件
3. 你一个个打开文件
4. 在 Chat 里问”帮我写 Comments 组件”
5. 复制代码，粘贴到文件
6. 再问”写评论 API”
7. 复制，粘贴
8. 循环 5 次

累死。

Composer 做法：

1. 打开 Composer（Cmd+I）
2. 输入”添加评论功能，用户可以发表、删除、查看评论”
3. 回车
4. AI 自动识别要改的文件，全部改完
5. 你检查 diff，点 Accept

10 分钟搞定。

场景 2：代码重构

需求：把状态管理从 Redux 迁移到 Zustand。

Chat 做法：几乎不可能完成。涉及 20+ 文件，每个都要手动改，容易遗漏，容易改错。

Composer 做法：

@src/store
@src/components

将 Redux store 迁移到 Zustand：
1. 保持现有 state 结构
2. 保持 API 不变
3. 移除 redux 依赖

开启 Agent 模式，AI 自己分析依赖，自己改文件，自己测试能不能跑。20 分钟搞定。

场景 3：批量修改

需求：统一错误处理方式，所有 API 调用都加上 try-catch。

Chat 做法：一个个文件改，容易遗漏。你得自己记住哪些改了、哪些没改。

Composer 做法：

@src/api

为所有 API 调用添加统一的错误处理：
- 用 try-catch 包裹
- 统一错误提示格式
- 记录错误日志

一次搞定 15 个文件。

Composer vs Chat：5 秒决策法则

现在你知道 Composer 和 Chat 的区别了。但实际写代码时，你还是会犹豫：“我该按 Cmd+L 还是 Cmd+I？”

给你个决策流程，3 步判断，5 秒决定。

决策流程

步骤 1：涉及几个文件？

• 1 个文件 → 继续判断
• 2 个以上 → Composer

就这么简单。跨文件就用 Composer。

步骤 2：是问问题还是要改代码？

• 问问题（学习、理解、调试） → Chat
• 改代码（生成、修改、重构） → Composer

Chat 是顾问，Composer 是施工队。记住了吗？

步骤 3：改动范围大吗？

• 小改动（几行代码） → Chat + Cmd+K
• 大改动（整个模块） → Composer

如果只是改个变量名、加个注释，用 Cmd+K 就行，不用动 Composer。

Chat 适合的 4 类场景

场景 1：快速问答

你："这段代码有 bug 吗？"
Chat："有，第 12 行数组越界了"

秒回。不需要改代码，只是想确认一下。Chat 完美。

场景 2：学习理解

你："解释一下这个算法的原理"
Chat："这是快速排序，核心思想是..."

学习新知识，Chat 的长项。它会耐心解释，还能举例子。

场景 3：单文件调试

你："帮我优化这个函数"
Chat："可以用 memoization 缓存结果..."

你自己动手改就行，不需要 Composer 全自动。

场景 4：代码审查

你："这里有什么潜在问题？"
Chat："第 15 行没处理 null 的情况，第 28 行有内存泄漏风险..."

审查代码，Chat 能看出很多问题。

Composer 适合的 4 类场景

场景 1：新功能开发

跨多个文件的功能实现。前面讲过了，不重复。

场景 2：代码重构

大范围的结构调整。比如：

• 拆分大文件
• 合并小文件
• 重新组织目录结构
• 统一命名规范

这些任务 Chat 根本做不了。

场景 3：依赖迁移

替换库或框架。比如：

• axios → fetch
• moment.js → dayjs
• styled-components → Tailwind CSS
• Redux → Zustand

涉及几十个文件，Composer 的舞台。

场景 4：批量修改

统一修改多处相似代码。比如：

• 所有 console.log 改成 logger
• 所有 var 改成 const
• 所有类组件改成函数组件

3 个对比案例

案例 1：修改 API 调用方式

任务：把所有 axios 改成 fetch。
涉及文件：15 个。

Chat：需要逐个文件操作，容易遗漏。你得自己记住哪些改了，哪些没改。累。

Composer：一条指令 @src/api 将所有 axios 改为 fetch，AI 批量修改，你只需审查 diff。

结论：Composer

案例 2：调试一个函数

任务：找出计算总价函数的 bug。
涉及文件：1 个。

Chat：直接贴代码，Chat 秒回答案。“第 12 行税率计算错了，应该是 total * 0.1”。

Composer：打开 Composer，等它分析，等它修改，等它应用…过于重量级，浪费时间。

结论：Chat

案例 3：添加用户权限系统

任务：实现 RBAC 权限控制。
涉及文件：10+（组件、中间件、数据库、API）。

Chat：几乎不可能完成。你要在 Chat 里逐个问，逐个改，还要自己保证逻辑一致。

Composer（Agent 模式）：AI 理解整体架构后，自动创建中间件、修改 API、更新组件、添加权限检查。你只需要告诉它”实现一个基于角色的权限系统，管理员能增删改查，普通用户只能查看”。

结论：Composer（Agent）

Composer 的正确打开方式

首次设置（3 步）

装完 Cursor，别急着用 Composer。先设置一下。

步骤 1：选择模型

Composer 推荐用 Claude 3.7 Sonnet。

为什么？

• 推理能力强：能理解复杂的多文件关系
• 错误率低：不容易改错代码
• 多文件理解好：知道哪些文件该一起改

千万别用 o1 或 o1-mini，它们不支持 Composer 功能。你会发现 Cursor 自动切换到其他模型，结果不如预期。

步骤 2：开启 Agent 模式（可选）

打开设置：Cursor Settings → Beta → Agent。

开启后，Composer 能做这些事：

• 运行 shell 命令（npm install、git status）
• 搜索代码库（Cmd+Enter，找出所有用到某个函数的地方）
• 创建/删除文件
• 自主分析项目结构

Agent 模式就像给 AI 配了个工具箱，能自己动手。但也更容易”过度施工”，后面会讲怎么控制。

步骤 3：了解收费规则

• 免费版：Composer 功能受限，每天几次请求
• Pro 版：500 次 premium 请求/月，够用
• Business 版：无限制

如果你是重度用户，建议 Pro 版。我自己用 Pro，一个月大概用 300-400 次。

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

界面布局解读

Composer 的界面长这样：

┌─────────────────────────────────┐
│  Composer  [Normal] [Agent]     │  ← 模式切换
├─────────────────────────────────┤
│  📝 输入框（描述需求）            │
│  @ 引用文件/文件夹/代码          │
├─────────────────────────────────┤
│  💬 对话历史                     │
│  📄 文件 diff 预览               │
│  ✅ Accept  ❌ Reject            │
└─────────────────────────────────┘

右上角能切换 Normal 和 Agent 模式。

下面的 diff 预览很重要，你能看到每个文件改了什么。千万别直接 Accept All，后面会专门讲这个坑。

@ 引用功能妙用

@ 符号是 Composer 的核心功能。你能用它引用各种东西。

@Files：引用特定文件

@src/components/Header.tsx
将这个组件改为响应式设计

AI 就知道只改这一个文件，不会乱动其他地方。

@Folders：引用整个文件夹

@src/utils
重构这个工具库，按功能分类拆分文件

AI 会看这个文件夹下的所有文件，理解整体结构，再重构。

@Code：引用代码块

先选中一段代码，再按 Cmd+I，就会自动引用：

@[已选中的函数代码]
优化这个函数的性能

这个特别适合小范围优化。

@Web：引用网页内容

@https://docs.react.dev/reference/react/useEffect
按照 React 官方文档的最佳实践，重构这个 effect

AI 会读取网页内容，按照文档说的来改。我经常用这个功能，让 AI 照着官方文档改代码，不容易出错。

@Docs：引用项目文档

@README.md
根据文档说明，实现这个功能

如果你的项目有规范文档，可以 @ 引用，AI 会按规范来。

@Codebase：搜索整个代码库

按 Cmd+Enter，输入：

找出所有使用 localStorage 的地方，改用 IndexedDB

Agent 模式下，AI 会搜索整个项目，找出所有相关代码，一起改。

Normal vs Agent 模式

这两个模式有什么区别？

Normal 模式：

• 适合明确的任务
• AI 只修改你指定的文件
• 更可控，不会意外改动其他文件
• 速度较快
• Token 消耗少

Agent 模式：

• 适合复杂的、需要推理的任务
• AI 可以自主搜索代码、运行命令、创建文件
• 更智能，但可能改动超出预期
• 速度较慢
• Token 消耗多

选择建议：

简单任务 → Normal。比如”改这个组件的样式”、“加个错误处理”。

复杂重构 → Agent。比如”迁移 Redux 到 Zustand”、“实现权限系统”。

不确定 → 先试 Normal，不行再用 Agent。

我自己 80% 的时间用 Normal，20% 用 Agent。Normal 够用了，Agent 太重。

多文件编辑的 5 个黄金法则

这部分是重点。我踩过很多坑，总结出 5 条法则，照着做能避开 90% 的问题。

法则 1：任务拆分

❌ 错误示范：

"重构整个项目，改用 TypeScript，优化性能，添加测试"

这种指令 Composer 会懵。它不知道从哪开始，不知道先做什么后做什么。结果就是改得乱七八糟，你得花 2 小时回滚。

✅ 正确做法：

拆成 4 次对话：

第 1 次："将 src/utils 目录的所有文件改为 TypeScript"
第 2 次："为 utils 添加单元测试"
第 3 次："优化 Header 组件的性能"
第 4 次："重构 API 调用逻辑，统一错误处理"

每次完成一个小目标，git commit 一次。清晰、可控、容易回滚。

为什么要拆分？

• 避免 AI 理解偏差（一次说太多，AI 抓不住重点）
• 方便逐步审查（diff 小，容易看出问题）
• 出错时容易回滚（只回滚这一步，不影响其他）
• 减少 token 消耗（任务小，AI 思考少，花钱少）

我自己的经验：单次 Composer 对话涉及的文件不超过 10 个。超过 10 个就拆分。

法则 2：明确范围

用 @ 引用明确指定文件范围。

比如你要改用户相关功能：

@src/components/User
@src/types/user.ts
@src/api/user.ts

将用户相关的 API 从 RESTful 改为 GraphQL

这样 AI 就知道：只改这 3 个地方，别的地方不要动。

不明确范围会怎样？AI 可能自作主张改了别的文件。比如你说”统一 API 调用方式”，AI 把第三方库的 API 也改了，项目崩了。

好处：

• AI 不会误改其他文件
• 更改可控
• 减少意外

我现在每次用 Composer，第一步就是 @ 引用相关文件。养成习惯。

法则 3：逐个审查

Composer 改完后，千万不要直接点 Accept All。

我知道 Accept All 很诱人。AI 改了 20 个文件，你点一下全部应用，爽。

但是…

真实踩坑案例：

有一次，我让 Composer”将所有 console.log 替换为自定义 logger”。

Composer 改了 30 个文件。

我看都没看，直接 Accept All。

结果：

• 把第三方库的 console.log 也删了
• 有些调试代码被误删了
• 项目跑不起来了

我花了 1 小时回滚、排查、手动修复。

正确流程：

1. 点击每个文件的 diff 预览
2. 逐行检查更改
3. 确认无误后，单独 Accept
4. 发现问题立即 Reject，重新描述需求

是的，很慢。改 20 个文件，你要看 20 次 diff。但这能避免 90% 的事故。

我现在的习惯：Composer 改完，泡杯咖啡，坐下来慢慢审查。急不来。

法则 4：及时提交

每完成一个小任务，立即 git commit。

# 完成一次 Composer 修改后
git add .
git commit -m "feat: 迁移用户 API 到 GraphQL"

为什么重要？

Composer 对话历史不保存。刷新页面就丢了。

如果你改了 10 个文件，没 commit，网页卡了，对话丢了…你不记得改了啥，也不知道改到哪了。只能重头来。

但如果你每步都 commit：

• 出问题容易回滚（git reset --hard HEAD）
• 便于追踪每次更改（git log 能看到改动记录）
• Composer 对话丢了也不怕（反正代码已保存）

我现在的节奏：Composer 改完 → 审查 diff → Accept → git commit。形成肌肉记忆。

法则 5：保持上下文

问题：

Composer 不会保存对话历史。刷新页面，之前的对话就消失了。

你问：“继续刚才的重构”，AI 会说：“啥重构？我不知道你在说什么”。

解决方案：

方案 1：重要对话截图保存

复杂任务开始前，把你的 Composer 指令截图。改到一半网络断了，你还能看截图回忆当时要做什么。

方案 2：复杂任务先在 Chat 里规划，再用 Composer 执行

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

Chat 的对话历史是保存的。你可以在 Chat 里和 AI 讨论方案，确定了再用 Composer 执行。

比如：

Chat 对话：
你："我想把 axios 迁移到 fetch，需要注意什么？"
AI："需要注意错误处理、拦截器、类型定义..."
你："好，帮我写个迁移计划"
AI："第一步...第二步...第三步..."

然后你照着计划，一步步用 Composer 执行。Chat 里的计划一直在，Composer 丢了也不怕。

方案 3：使用项目 README 记录改动意图

我会在 README 里维护一个”重构记录”章节：

## 2026-01-10 重构记录
- 任务：迁移 axios 到 fetch
- Composer 指令："将所有 axios 调用改为原生 fetch API，保持相同的错误处理逻辑"
- 涉及文件：src/api/*.ts
- 结果：成功迁移 15 个文件

以后你回看项目，能知道为什么这么改。

Composer 的 7 个常见坑及避坑指南

这部分我会把我踩过的坑全部列出来。你照着避就行。

坑 1：对话历史不保存

问题：

Composer 的对话刷新页面就消失。

你改到一半，网页卡了，或者你不小心关了标签页，或者 Cursor 崩了…之前的对话全丢了。

避坑方法：

✅ 重要指令截图保存（手机拍照也行）
✅ 在 Chat 里先规划，记录思路
✅ 使用 git commit message 记录每次改动意图
✅ 复杂任务分多次小对话完成（每次对话不超过 10 个文件）

坑 2：文件更新中断

问题：

Composer 改到一半卡住。

可能是网络波动，可能是 AI 服务抽风，可能是你的电脑风扇太吵 AI 听不清（开玩笑）。

结果：部分文件改了，部分没改。项目处于半残状态。

避坑方法：

✅ 改之前先 git commit（出问题直接回滚）
✅ 检查网络稳定性（Composer 对网络要求高，VPN 不稳别用）
✅ 任务拆小，减少单次改动文件数（文件少，更新快，不容易中断）
✅ 使用 git diff 检查实际改动（看看哪些文件真的改了）

我自己遇到过 2 次更新中断。第一次没 commit，手动修复了 2 小时。第二次有 commit，git reset 一秒回滚。

坑 3：模型自动切换

问题：

有些模型（如 o1）不支持 Composer。

你选了 o1，结果 Cursor 自动切换到其他模型。你以为在用 o1，实际在用 GPT-4o。结果不如预期。

避坑方法：

✅ 固定使用 Claude 3.7 Sonnet（Composer 最佳搭档）
✅ 查看右上角模型名称确认（别以为选了就是在用）
✅ Cursor Settings 里设置默认模型

我现在只用 Claude 3.7 Sonnet。稳定、可靠、错误率低。

坑 4：上下文丢失

问题：

你在 Composer 里连续对话：

第 1 次："将用户 API 改为 GraphQL"
第 2 次："继续，把评论 API 也改了"

结果 AI 说：“啥用户 API？我不知道你在说什么”。

上下文丢了。

避坑方法：

✅ 每次对话都重新 @ 引用相关文件
✅ 明确描述”基于上次的改动，继续…”
✅ 必要时重新开启新对话，重新说明完整背景

我现在的习惯：每次对话都当成第一次对话，把背景说清楚。

坑 5：文件检索失败

问题：

你按 Cmd+Enter，输入”@Codebase 找出所有用到 axios 的地方”。

AI 说：“没找到”。

但你明明有 15 个文件用了 axios。

避坑方法：

✅ 使用 @Files 明确指定文件（不依赖搜索）
✅ 检查 .cursorrules 和 .gitignore（可能屏蔽了某些文件）
✅ 大项目建议按模块拆分任务（别让 AI 搜索整个项目）

@Codebase 搜索在大项目里不太靠谱。我现在都用 @Files 明确指定。

坑 6：Agent 模式过于激进

问题：

开启 Agent 模式后，AI 自作主张：

• 创建了你不需要的文件
• 删除了你以为重要的代码
• 改动超出预期

比如你说”重构用户模块”，AI 把整个 src/user 目录删了重建。

避坑方法：

✅ 复杂任务先用 Normal 模式试试
✅ Agent 模式更适合明确的重构任务（比如”迁移依赖”）
✅ 逐个审查 diff，发现不合理的改动及时 Reject

Agent 模式很强大，但也很危险。我自己只在非常明确的任务（比如依赖迁移）才用。

坑 7：磁盘空间不足

问题：

Composer 创建临时文件。

如果你的磁盘空间不足，更新会失败。文件改到一半，报错”磁盘空间不足”。

避坑方法：

✅ 定期清理 node_modules、dist 等临时目录
✅ 确保有 5GB+ 可用空间
✅ 使用 df -h 检查磁盘使用率

这个坑我只踩过 1 次，但很隐蔽。报错信息不明显，我排查了半天才发现是磁盘满了。

实战案例：axios 迁移到 fetch API

说了这么多理论，来个实战案例。

案例背景：

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

• 项目：Next.js 博客系统
• 任务：将所有 axios 调用改为原生 fetch API
• 涉及文件：15 个 API 文件
• 预计时间：手动改需要 2 小时，Composer 20 分钟

我会 step-by-step 演示怎么用 Composer 完成这个任务。

第 1 步：在 Chat 里规划

别急着打开 Composer。先在 Chat 里和 AI 讨论一下。

我：我想把项目中的 axios 全部替换为 fetch API，需要注意什么？

Chat：
1. fetch 的错误处理与 axios 不同，需要手动检查 response.ok
2. fetch 默认不会 reject 4xx/5xx，需要额外处理
3. 需要手动设置 Content-Type
4. 请求拦截器需要用自定义函数实现

建议先创建一个 fetchWrapper 工具函数。

好。Chat 给了个思路。先写工具函数，再批量替换。

第 2 步：创建 fetchWrapper 工具

Cmd+I 打开 Composer：

@src/utils

创建一个 fetchWrapper.ts 文件，实现类似 axios 的 API 封装：
- 自动处理 JSON
- 统一错误处理
- 支持拦截器
- 兼容现有的 axios 调用方式

回车。

Composer 思考了几秒，创建了 fetchWrapper.ts，代码写得还不错。

我检查了一下：

• ✅ 类型定义完整
• ✅ 错误处理逻辑正确
• ✅ API 设计合理

Accept。

git commit -m "feat: add fetchWrapper utility"

第 3 步：逐模块迁移

不要一次改 15 个文件。拆成几次。

先改 posts 和 comments 模块：

@src/api/posts.ts
@src/api/comments.ts
@src/utils/fetchWrapper.ts

将 posts 和 comments 的 API 调用从 axios 改为 fetchWrapper，保持相同的函数签名和错误处理逻辑。

回车。

Composer 开始工作。改了 3 个文件。

第 4 步：审查 diff

这是最关键的一步。

我逐个文件检查：

posts.ts：

• import axios 改成 import { fetchWrapper } ✅
• axios.get() 改成 fetchWrapper.get() ✅
• 错误处理逻辑保持不变 ✅
• 函数签名没变 ✅

Accept。

comments.ts：

• 改动类似，没问题 ✅

Accept。

fetchWrapper.ts：

• 导入被正确引用 ✅

第 5 步：测试

npm run dev

打开浏览器，测试 posts 和 comments 功能：

• 加载文章列表 ✅
• 查看文章详情 ✅
• 发表评论 ✅
• 删除评论 ✅

全部正常。

git commit -m "feat: migrate posts and comments API to fetch"

第 6 步：继续迁移其他模块

照着第 3-5 步，继续迁移：

• users 模块
• auth 模块
• settings 模块

每个模块改完，审查、测试、commit。

25 分钟搞定全部 15 个文件。

踩坑经验

坑 1：Composer 把第三方库的 axios 也改了

第一次我没用 @Files 明确指定范围，结果 node_modules 里的代码也被改了。

解决：重新描述”只修改 src 目录下的代码，不要改 node_modules”。

坑 2：错误处理逻辑丢失

fetch 的错误处理与 axios 不同。直接替换导致有些错误未捕获。

解决：在指令中明确”保持相同的错误处理逻辑，手动检查 response.ok”。

坑 3：类型定义缺失

TypeScript 报错，fetchWrapper 的类型定义不完整。

解决：单独用 Chat 生成类型定义，然后用 Cmd+K 应用到 fetchWrapper.ts。

最终效果

✅ 15 个文件全部迁移完成
✅ 所有 API 功能正常
✅ 总耗时：25 分钟（含调试）
✅ 代码 review：无问题
✅ 包体积减少：axios 是 30KB，fetch 是原生 API

手动改估计要 2 小时。Composer 25 分钟。效率提升 5 倍。

经验总结

1. 复杂任务先在 Chat 里规划
2. 分步执行，每步完成后 git commit
3. 明确指定文件范围（用 @ 引用）
4. 逐个审查 diff，避免意外改动
5. 测试后再继续下一步

这 5 条经验适用于所有 Composer 任务。记住了。

结论

说实话，掌握 Composer 后，我的开发效率至少翻了 3 倍。

之前改个跨文件的功能，要在多个文件间来回切换，复制粘贴代码，容易出错，容易遗漏。累。

现在一条 Composer 指令，AI 自动识别需要改哪些文件，全部搞定。我只需要审查 diff，点 Accept。10 分钟搞定。

记住 5 个核心原则：

1. 涉及多文件 → 用 Composer
   跨文件就别用 Chat 了，浪费时间。

2. 任务要拆小 → 别一次改太多
   单次对话不超过 10 个文件。

3. 逐个审查 → 别直接 Accept All
   慢就慢点，总比事故强。

4. 及时提交 → 每步完成就 git commit
   Composer 对话不保存，代码要保存。

5. 保持上下文 → 重要对话截图保存
   截图、Chat 规划、README 记录，三管齐下。

快捷键记住两个：

• Cmd/Ctrl + L → Chat（问问题）
• Cmd/Ctrl + I → Composer（改代码）

5 秒决策法则：

涉及几个文件？
 → 1 个 → 是问问题还是改代码？
    → 问问题 → Chat
    → 改代码 → 改动大吗？
       → 小改动 → Chat + Cmd+K
       → 大改动 → Composer
 → 2 个以上 → Composer

别害怕 Composer。

刚开始你可能会觉得它”太智能了，不可控”。

但用几次你就会发现：只要遵守上面的法则，Composer 非常可控，非常好用。

行动建议：

现在就试试：

1. 打开 Cursor，按 Cmd+I
2. 找个小任务练手（比如”批量重命名变量”、“统一代码风格”）
3. 把这篇文章的 5 个法则、7 个避坑技巧保存下来
4. 以后遇到多文件改动，第一时间想到 Composer

别只用 Chat 了。

Composer 才是 Cursor 的核心能力。

试试就知道有多强大。

21 分钟阅读 · 发布于: 2026年1月10日 · 修改于: 2026年2月4日

Easton

技术开发