07 · Chat 模式深度用法

Cmd+L 打开的不仅仅是一个聊天窗口——它是 Cursor 的”智能接口层”，理解它才能真正释放 AI 编程的潜力。

01 Chat 模式是什么

Chat 模式是 Cursor 中按 Cmd+L（Windows: Ctrl+L）打开的侧边对话面板。但如果你只是把它当”聊天窗口”用，那你用掉的只是它全部能力的 10%。

真正理解 Chat 模式，需要先放下”聊天”这个字眼。它在 Cursor 中的角色其实是：

一个带完整项目上下文的 AI 对话界面，支持四种不同的 AI 行为模式。

换句话说：Cmd+L 打开的不是同一个 AI 换了个皮肤，而是四个不同的 AI 角色共享同一个入口。你选择的子模式决定了 AI 的行为边界——它能做什么、不能做什么、该怎么做。

这和 Composer / Agent 模式（Cmd+I）是并列关系，但定位不同：

心智模型：Chat 模式是 Cursor 的”参谋部”——它帮你理清问题、分析代码、设计方案。而 Composer / Agent 是”执行部”——方案定了，它去动手。这两个角色不分高下，只是分工不同。

02 四个子模式详解

Chat 模式下，你可以通过输入框上方的下拉菜单（或在输入框中输入 / 命令）切换四种子模式。每种模式对应完整的 System Prompt 差异——不只是”同一个 AI 给不同的初始提示”那么简单。

Agent 模式（默认）

一句话：它能做任何事——改文件、跑命令、搜代码、查文档。

Agent 模式是 Chat 模式的默认子模式，也是功能最完整的。它有完整的工具访问权：

• 读取项目中的任意文件
• 修改、创建、删除文件
• 在终端中执行命令（安装依赖、运行测试、部署）
• 搜索整个代码库
• 从网页获取最新信息
• 引用文档（@docs）

心智模型：像一个可以直接动手的技术搭档——你问一个问题，他从文件里翻答案；你说一句”这里需要改”，他直接改好文件给你看 diff。不用你切换工具、不用你复制粘贴，所有事情在对话中完成。

最适合的场景：

• “这个 API 返回的数据结构在哪定义的？帮我在类型上加一个新字段”
• “帮我在 src/utils/date.ts 里加一个格式化日期的工具函数，然后在 src/components/ 下找到所有用日期的地方，更新调用”
• “项目跑起来报了这个错（贴错误），帮我查一下原因并修复”
• “帮我检查一下 src/lib/db.ts 里的数据库连接，没有做重试逻辑，加上”

不擅长：当你只是想问个问题、完全不想改代码时，Agent 模式反而”用力过猛”——它会主动去翻文件、给建议，甚至”顺手”改了不该改的东西。这时候用 Ask 模式更安全。

Plan 模式

一句话：只动脑、不动手——调研、分析、出方案，但不碰你一行代码。

Plan 模式是 Chat 中最具战略价值的子模式。它把 AI 的”执行器”全部拿掉，只保留”分析器”：

• 可以读取文件
• 可以搜索代码库
• 可以思考和分析
• 不能修改任何文件
• 不能执行终端命令

心智模型：像一个只出方案不写代码的资深架构师。你不确定怎么做之前，先用 Plan 模式聊清楚——它会系统地分析你的项目结构、当前代码、依赖关系，然后给你一个详细的实施计划。等计划确认了，再切换到 Agent 模式去执行。

最适合的场景：

• “我想在这个项目里加上用户权限系统，支持 admin/user/guest 三个角色。先帮我分析一下现有的认证代码，出一个具体的实施方案”
• “这个模块越来越大了，我想拆成几个小文件。给我推荐一个拆分方案，包括接口设计和文件结构”
• “从 JavaScript 迁移到 TypeScript，需要多大的工作量？分几步走？每个文件的风险等级？”

核心价值：Plan 模式能避免”AI 提枪就上，打到一半发现方向错了”的悲剧。在没有 Plan 模式之前，开发者的典型痛点是：你让 Agent 实现一个功能，它咔咔改了 10 个文件，你 review 的时候才发现整体设计有问题。Plan 模式强制你”先想清楚再动手”。

使用建议：每次交给 Agent 超过 3 个文件改动的大任务前，先切到 Plan 模式聊一轮。这 5 分钟的投资能省掉后续 30 分钟的返工。

Debug 模式

一句话：专业的 Bug 猎人——自动插日志、分析运行时数据、定位根因。

Debug 模式是 Cursor 专门为调试场景定制的子模式。它和普通 Agent 模式的核心区别在于：

心智模型：像一个经验丰富的 Debug 专家——它不会凭经验瞎猜 bug 在哪，而是系统性地：先插探针（日志）→ 收集数据 → 分析 → 定位 → 给出修复建议。

最适合的场景：

• “这个接口有时候返回 500，有时候正常，查一下原因”
• “用户反馈页面白屏，帮我插日志定位问题”
• “这个 React 组件在特定情况下会无限重渲染，找出原因”
• “这段代码的算法跑大数据集时性能极差，帮我分析瓶颈”

一个实际的 Debug 工作流：

1. 把报错信息贴进 Chat，切换到 Debug 模式
2. AI 分析报错，在相关代码位置插入调试日志
3. 你跑一次复现场景，把新的日志输出贴回来
4. AI 根据日志分析数据流，定位出问题代码行
5. AI 给出修复方案（注意：Debug 模式不改代码）
6. 你确认方案后，切到 Agent 模式执行修复

Ask 模式

一句话：纯只读问答——问什么答什么，绝不碰你代码。

Ask 模式是四种模式中限制最严格的：

• 只能读取当前文件和 @ 引用的上下文
• 只能回答问题，不能改文件、不能写新代码
• 不能执行终端命令
• 最适合”学习代码”和”获取信息”的场景

心智模型：像一个项目的随身文档库——你问”这个函数是干什么的”、“这段代码为什么要这么写”、“这个模式是什么意思”——它给你准确、详细的回答，而且绝对不碰乱你的代码。

最适合的场景：

• “解释一下这个 React 组件的渲染流程”
• “这段正则表达式在匹配什么？”
• “这个 TypeScript 泛型约束 extends Record<string, any> 是什么作用？”
• “这个项目的 useAuth hook 是怎么用的？调用了哪些 API？”

什么时候用 Ask 而不是 Agent：

很多人在学习代码时习惯用 Agent 模式问问题——但 Agent 会”自作多情”地给出改进建议甚至直接改代码。Ask 模式让你可以”放心大胆地问”，AI 不会自作主张改任何东西。

使用建议：养一个习惯——当你只是想”学习”而不是”改造”时，先切到 Ask 模式。等需要动手改的时候再切到 Agent。

四种模式的切换时机

想学代码、理解项目  ──→  Ask 模式（只问不改）
想出方案、评估风险  ──→  Plan 模式（只分析不改）
发现 BUG、排查问题  ──→  Debug 模式（诊断不改）
确定方案、动手实现  ──→  Agent 模式（能干所有事）

03 @ 符号上下文系统

Chat 模式中，@ 符号是通往项目上下文的入口。在输入框中输入 @ 会弹出上下文选择菜单——这个设计看似简单，但用好它能让 AI 的输出质量翻倍。

@file —— 引用文件

直接在 @ 后面输入文件名或路径，AI 会读取该文件的完整内容。

@src/utils/api.ts 帮我看看这个文件的错误处理逻辑

文件引用支持多选，可以用 Cmd+点击（Mac）或 Ctrl+点击（Win）选择多个文件。

最佳实践：不要一次性 @ 太多文件（超过 5-6 个文件会让 AI 注意力分散）。如果确实需要跨大量文件问问题，用 @codebase 替代。

@folder —— 引用文件夹

引用一个文件夹时，AI 会了解这个目录的文件结构和所有文件的概要。

@src/components/ 分析一下这个目录的结构，哪些组件需要重构

适合问”这个目录里有什么结构性的问题”这类问题。

@git —— 引用 Git 上下文

@git 是代码 review 和 commit 场景的神器。它会引用当前的 Git 变更：

实用场景：

@git 帮我写一下这次改动的 commit message

@git diff main...HEAD 帮我 review 一下这个 PR 的改动，有什么问题吗

@git 这些改动里有没有可能引入安全问题的？

@codebase —— 搜索整个代码库

@codebase 是当你不确定某个东西在哪个文件中时用的。它会让 AI 搜索整个项目来找答案，并引用相关文件作为来源。

@codebase 这个项目的用户认证逻辑在哪？画一个完整的数据流图

@codebase 所有用到这个 `formatDate` 函数的地方，帮我列出来

注意：@codebase 的语义搜索质量高度依赖 Cursor 的索引。首次打开大型项目时，Cursor 会在后台建立索引（需要几分钟）。如果你的 @codebase 经常找不到东西，检查一下索引状态：Cmd+Shift+P → “Cursor: Rebuild Index”。

@web —— 联网搜索

让 AI 去搜索引擎获取最新信息（模型训练截止后发布的内容）。

@web 最新的 Next.js 15 App Router 在 Server Components 中怎么用 cookies

适合：

• 查最新版本的 API 文档
• 查错误信息（很多错误方案在 Stack Overflow 上有）
• 查第三方库的使用示例

小提示：如果你知道一个文档 URL，问 @web https://example.com/docs 帮我总结这个页面的 API 也可以——它直接去读你给的 URL。

@docs —— 引用文档

Cursor 内置了一批常用框架和库的文档索引。当你 @docs 后，可以看到一个列表：

React, Next.js, TypeScript, Tailwind CSS, Python, Node.js, Prisma, tRPC, ...

@docs React 的 useCallback 和 useMemo 有什么区别，什么情况下应该用

AI 会根据精选版的官方文档来回答，比基于训练数据的回答更准确、更权威。

如何添加自定义文档：如果有项目内部的私有文档，可以在 Cursor Settings → Docs 中添加自定义文档源（需要提供一个 URL，Cursor 会定期爬取并建立索引）。

@Notepad —— 引用记事本

Notepad（记事本）是 Cursor 中一个容易被忽视但极其强大的功能。它是一个持久化的上下文管理工具。

它解决什么问题：很多时候，你在 Chat 中给 AI 提供了一大段上下文（项目规范、代码风格约定、API key、数据库连接信息、部署流程……），但每次新对话 AI 都不记得了。Notepad 就是解决这个问题的。

基本用法：

1. 在 Chat 面板中点击 Notepad 图标（或按 Cmd+Shift+N）
2. 创建一个 Notepad，比如叫 “Project Conventions”
3. 写入项目规范——比如”我们使用 pnpm 而不是 npm”、“API 错误统一返回 { ok: false, error: string } 格式”
4. 在 Chat 中输入 @Notepad Project Conventions 引用它

高级用法：你可以创建多个 Notepad，分别用于不同场景：

@Notepad Project Conventions 根据项目规范，帮我在 src/api/ 下创建新的订单接口文件

引用组合技巧

@ 引用可以组合使用——这是最有技巧的部分：

@file src/config.ts @docs Next.js 帮我解释一下这个配置文件的每一行

@file src/types/user.ts @git 我刚改的 user 类型，检查一下有没有兼容性问题

@codebase @git diff 这些改动影响到了哪些其他文件？需要一起改吗？

04 Chat 历史管理

Chat 对话历史是一个经常被忽视但实际上严重影响使用体验的功能。

对话生命周期

每次按 Cmd+L 打开的 Chat 对话，其生命周期是：

1. 创建：按 Cmd+L → 新对话开始
2. 进行：一问一答，上下文不断累积
3. 重置：按 Cmd+L 再打开 → 新对话开始（旧对话的上下文不会自动带入）
4. 历史：可以通过对话历史列表查看之前的对话

什么时候该开新对话

一个常见的错误是”一个问题问到底”——在一个对话里不断追问不同的问题。这会带来两个问题：

• 上下文污染：前面的问题残留会影响后续回答的质量
• Token 浪费：长对话消耗更多 Token，如果使用自己的 API Key，意味着花钱更多

什么时候开新对话：

什么时候继续当前对话：

查看和恢复历史

Cmd+L 打开 Chat 面板后，点击输入框上方的”历史”图标（时钟形状）可以看到所有历史对话。历史对话按时间倒序排列，你可以：

• 点击恢复之前的对话
• 删除不再需要的对话
• 对话默认保存在本地，不会同步到云端

一个实用技巧：如果你的 Agent 在某个对话中做了一组修改，但你改了主意想回退——除了用 Git，你还可以从历史中恢复那个对话，让 Agent 帮你”反向修改”。

清除 Cursor 的”记忆”

注意：同一对话中，Cursor 不会”忘记”之前说过的话。如果你在对话中进行了一些错误的引导——比如让它做了一个错误的设计决定——它会在后续回答中延续这个错误。这种情况下：

1. 开新对话（重置所有上下文）
2. 重新提供正确的上下文
3. 不要偷懒继续用同一个对话

05 用 Chat 做代码 Review 和解释

Chat 模式的一个核心用途是代码理解。这是很多人低估了的能力——“我写的代码我怎么可能看不懂”——但在实际工作中，读别人的代码、读自己以前的代码、读第三方库的代码，占的时间往往比写代码还多。

代码解释

场景一：解释不熟悉的代码片段

选中一段代码 → Cmd+L → 输入：

解释这段代码，用逐行注释的方式

AI 会逐行或者说逐块解释代码的作用。特别适合：

• 从网上复制来的代码
• 接手老项目时看不懂的”魔法写法”
• 自己几个月前写的、现在已经忘记逻辑的代码

场景二：解释调用链

从这个函数开始，顺着调用链解释整个请求处理流程，包括每个中间件做了什么

AI 会顺着函数调用读取多个文件，画出一个完整的调用链。这个能力在调试复杂 bug 时特别有用。

场景三：模式识别

这段代码是用什么设计模式实现的？为什么要用这个模式？

AI 能识别常见的代码模式（工厂模式、策略模式、观察者模式、依赖注入等），并解释为什么在这个场景下选择了这个模式。

代码 Review

场景四：对本地改动做 Review

你改了一些代码，还没有 commit：

@git 帮我 review 这些改动，重点关注：
1. 有没有逻辑错误
2. 异常处理是否完善
3. 有没有性能隐患
4. 有没有类型安全问题

AI 会基于 diff 逐条审查。

场景五：对某个文件做 Review

@file src/services/payment.ts 帮我 review 这个文件，从以下维度：
- 代码质量
- 可维护性
- 安全隐患
- 性能问题
- 测试覆盖率建议

场景六：架构级 Review

@folder src/ @codebase 从架构角度看，这个项目的服务和数据层有没有设计问题？关注：
- 循环依赖
- 职责分配不合理
- 过于耦合的模块
- 可以抽象出来的公共逻辑

心智模型：Chat 作为代码理解的”第三视角”

很多开发者在 Review 自己代码时有一个盲区：太熟悉了反而看不清。你自己写了三个月的代码，看它就像看自己的孩子——觉得它哪儿都好，就算有点小毛病也看不出来。

Chat 模式提供了一个完美的”第三视角”——它像一个经验丰富但零情绪的新同事：

• 它不知道你的代码”应该是怎样的”，所以它能发现你的假设和实际实现之间的偏差
• 它不会因为是”你写的代码”就不好意思提意见
• 它不会累——你可以让它从 5 个不同维度 review 同一个文件

使用建议：养成”commit 前先让 Chat review 一轮”的习惯。这是一行测试代码都不用写的、零成本的代码质量提升手段。

06 Chat vs Composer 决策框架

这是 Cursor 用户问得最多的问题之一：Chat 模式和 Composer 模式，什么时候该用哪个？

先说结论：它们不是替代关系，而是上下游关系。

核心区别

决策树

你想问一个问题？
  └─→ Chat（任何子模式）
        ↓
你需要理解代码？
  └─→ Chat → Ask 模式

你需要设计方案？
  └─→ Chat → Plan 模式

你需要排查 Bug？
  └─→ Chat → Debug 模式

你需要改代码？
  ├─ 改 1-3 个文件，且需要边聊边改
  │     └─→ Chat → Agent 模式
  │
  ├─ 改 1-3 个文件，不需要聊，直接改
  │     └─→ Composer / Agent (Cmd+I)
  │
  ├─ 改多个文件，是一个完整的"任务"
  │     └─→ Composer / Agent (Cmd+I)
  │
  └─ 改的地方很多，但逻辑连贯
        └─→ Composer / Agent (Cmd+I)

一个实战流程

以”给登录页面加上 OAuth 微信登录”为例：

Step 1：理解现状
  Chat → Ask 模式
  "现有的登录逻辑是什么？在哪些文件里？"
  ← AI 解释现有登录流程和相关文件

Step 2：设计方案
  Chat → Plan 模式
  "我想加上微信 OAuth 登录，出个方案"
  ← AI 出方案：需要修改几个文件，前后端分别做什么

Step 3：执行实现
  Composer / Agent (Cmd+I)
  "按照方案实现微信 OAuth 登录"
  ← AI 跨文件改代码，你审查 diff

常见误区

误区一：所有一切都在 Chat 里做

Chat 的 Agent 模式确实能做和 Composer Agent 几乎一样的事。但如果你的任务超过 3-5 个文件的改动量，在 Chat 里做会面临：没有 diff 面板、没有统一的改动审查界面、无法批量接受/拒绝。这时候用 Composer (Cmd+I) 会高效得多。

误区二：从来不用 Chat 模式，总是直接 Cmd+I

Cmd+I 直接启动 Agent 的问题是——它默认就要干活。但很多场景下你根本还没想好要干什么。先 Chat 聊清楚，“先分析、后动手”，带来的收益远大于”先动手、再返工”的成本。

误区三：Chat = 问问题，Composer = 写代码

Chat 的 Agent 模式写代码能力并不差。区别是交互体验不同：Chat 更适合同一个话题的持续对话，Composer 更适合”接到一个明确任务，独立完成，然后交差”的工作方式。

我的推荐工作流

日常开发时，把 Cmd+L 当作默认入口：

按 Cmd+L
  如果 → 想清楚要改什么了 → 切换到 Composer (Cmd+I) 去执行
  如果 → 还没想清楚       → 在 Chat 里聊清楚再决定

这个流程的核心原则：多用 Cmd+L，少空降 Composer。

07 心智模型总结

把这一篇的核心心智模型总结在一起：

08 小结

下一篇：08 Agent 模式实战指南 —— 真正掌握 Cursor 的最强形态，从单文件操作到跨全栈项目开发。