Chat 模式与 Inline Edit

Chat 模式与 Inline Edit

本节摘要:AI 编程工具通常提供两种「轻量级」交互:Chat(侧边栏对话)和 Inline Edit(原地编辑)。它们看似相似,实则定位完全不同——Chat 适合「讨论」(方案比较、原理解释、错误分析),Inline Edit 适合「执行」(选中代码,直接改)。用错模式会显著降低效率:该直接改的时候你去 Chat 讨论,多了一轮复制粘贴;该讨论的时候你用 Inline Edit,AI 没有足够空间解释方案。本节讲清两者的使用时机、操作方式和 @ 引用机制。

一、Chat 模式:你的技术顾问

定位

Chat 是一个「对话窗口」,AI 在这里回答问题、讨论方案、解释代码。它的输出是文本(可能包含代码块),不会直接修改你的文件。

典型使用场景

• 方案讨论:「用 Redis 还是内存缓存做 session 存储?各有什么利弊?」
• 代码解释:「这段正则表达式是什么意思?」(选中代码后问)
• 错误分析:把报错堆栈贴进去,「这个错误是什么原因?怎么修?」
• 学习探索:「FastAPI 的依赖注入是怎么工作的?」
• 代码审查:「帮我 review 这段代码,关注安全问题」

@ 引用:精准注入上下文

Chat 的质量取决于你喂给 AI 的上下文。各工具的引用语法略有不同,但核心逻辑一致:

Cursor 的 @ 引用:

• @file — 引用特定文件(输入 @ 后搜索文件名)
• @folder — 引用整个目录
• @codebase — AI 自动搜索项目中相关代码
• @web — 搜索互联网(获取最新文档)
• @docs — 引用你预配置的文档源(如某个库的官方文档)

Copilot Chat 的引用:

• @workspace — 全项目搜索
• @file — 特定文件
• /explain — 解释选中代码
• /fix — 修复选中代码的问题
• /tests — 为选中代码生成测试

💡 技巧:不确定该引用哪个文件时,先用 @codebase 让 AI 自己搜。如果搜索结果不理想(引用了不相关文件),再切换为手动 @file 精准指定。

Chat 的最佳实践

1. 一次只问一个问题——别把三个不相关问题塞进一条消息
2. 先给上下文再提问——「@file:src/api/auth.ts 这个文件的 login 函数为什么在并发时会重复创建 session?」
3. 不满意就追问——「你给的方案太重了,有没有更轻量的做法?」
4. 讨论完了切执行——方案确定后,别在 Chat 里让 AI 反复输出代码再复制粘贴,直接用 Inline Edit 或 Composer 执行

二、Inline Edit:原地手术刀

定位

Inline Edit 是「选中代码 → 描述修改 → AI 原地生成 diff → 你确认应用」。它的输出直接修改文件,不需要复制粘贴。

触发方式

典型使用场景

• 重构单个函数:选中 → 「改成 async/await,加错误处理」
• 加类型注解:选中一段 JS → 「转成 TypeScript,加上完整类型」
• 修改逻辑:选中条件判断 → 「把这个 if-else 改成 switch」
• 加注释:选中复杂逻辑 → 「给每步加上中文注释」
• 生成测试:选中函数 → 「给这个函数写单元测试,用 vitest」

Inline Edit 的工作流

1. 选中目标代码(也可以不选,光标定位即可)
2. 按 Cmd+K,输入修改意图
3. AI 生成 diff(绿色新增 / 红色删除)
4. 你审查 diff:
   • 满意 → Cmd+Enter 接受
   • 不满意 → Esc 拒绝,换个说法重来
   • 部分满意 → 手动微调后接受

⚠️ 注意:Inline Edit 的上下文默认只有「选中的代码 + 当前文件」。如果你的修改依赖其他文件的信息(比如要调用另一个模块的函数),需要在输入框中手动提及:「用 @file:src/utils/validator.ts 中的 validateEmail 函数」。

三、Chat vs Inline Edit:选择矩阵

简化规则:

• 需要 AI「说」→ Chat
• 需要 AI「改」→ Inline Edit
• 需要 AI「改很多文件」→ Composer(下一节)
• 需要 AI「自己想办法」→ Agent(第 1 章已讲)

四、常见错误与避坑

错误 1:在 Chat 里反复让 AI 输出完整代码再复制粘贴

• 问题:效率极低,还要手动对齐缩进和 import
• 正解:方案讨论完后,切到 Inline Edit 或 Composer 让 AI 直接改

错误 2:Inline Edit 时不给足够上下文

• 问题:选中 3 行代码说「优化一下」,AI 不知道优化方向
• 正解:要么多选一些上下文,要么在指令中说明「优化性能」还是「优化可读性」

错误 3:Chat 对话太长,上下文溢出

• 问题:聊了 30 轮后 AI 开始「忘事」,输出质量下降
• 正解:每完成一个独立任务就开新对话(Ctrl+Shift+L);或者把关键结论总结后开新轮

错误 4:对 AI 的输出不审查就接受

• 问题:AI 可能「自信地」引入 bug(比如用了不存在的 API)
• 正解:Inline Edit 的 diff 一定要看一眼;Chat 中的代码建议先理解再采纳

本节要点回顾

1. Chat 定位:讨论、解释、分析——AI 的输出是文本,不改文件
2. Inline Edit 定位:原地修改——AI 的输出是 diff,直接应用到文件
3. @ 引用:精准注入上下文的关键;@file 优于 @codebase(更可控)
4. 选择规则:需要「说」用 Chat,需要「改」用 Inline Edit,需要「改很多」用 Composer
5. 避坑核心:别在 Chat 里复制粘贴;Inline Edit 要给足上下文;长对话及时开新轮

当你需要修改的范围超出单个文件时,Inline Edit 就不够用了。下一节我们讲 Composer 和 Cascade 的多文件编辑机制。