05 · Chat 模式深度用法

不只是问答：理解侧边栏 Chat 和 Inline Chat 的区别，掌握 @-mention 上下文管理，学会用 Chat 做代码审查，以及何时用 Chat、何时切 Builder/SOLO。

01 Chat 的两种形态

Trae 的 Chat 不是”一个对话框”这么简单。它实际上有两个入口，面向两类不同的使用场景：

这两个入口共享同一个 AI 引擎，但交互逻辑截然不同。

侧边栏 Chat：全局对话

侧边栏 Chat 是你和 AI 的主战场。它位于右侧面板，以气泡对话的形式呈现。它的特点是：

• 会话持续：你关掉再打开，历史记录还在
• 上下文可以很大：可以通过 @-mention 引用多个文件、终端输出、错误信息
• 修改需手动 Apply：AI 建议的每一处代码修改，都需要你点 Apply 按钮才能写入文件
• 适合讨论式任务：代码解释、方案设计、技术咨询

Inline Chat：瞄准镜式的精修

Inline Chat 更像一个”瞄准镜”——你先用鼠标高亮选中一段代码，然后按 Cmd+K，AI 会直接在选中区域旁边打开一个内嵌编辑框。

Inline Chat 的核心逻辑是：

你选中代码 → 按 Cmd+K → 输入修改指令 → AI 生成新代码
    → 你按 Cmd+Enter 接受 / 按 Esc 拒绝 / 继续对话

Inline Chat 不像侧边栏 Chat 那样有”会话”的概念。你关掉 Inline 编辑框，对话就结束了。它是一次性的、面向局部的、不需要上下文管理的工具。

两者的心智模型

• 侧边栏 Chat = 办公室里的讨论会。你坐下来，把资料摆桌上（引用的文件），和 AI 讨论方案，讨论完了再执行。
• Inline Chat = 伸手改一处细节。你看到一行代码不顺眼，选中它说”改成防抖版本”，AI 直接改好，你确认就行。

一个常见的工作流是：侧边栏 Chat 讨论方案 → 定下来怎么做 → Inline Chat 逐处修改。先用侧边栏想清楚，再用 Inline 一把一把地改。

02 @-mention 系统：给 AI 喂上下文

Chat 模式下 AI 默认只看你当前打开的编辑器文件。要想让 AI 理解更多上下文，你需要主动告诉它”看一下这个文件”或”注意这里的报错”。

这就是 @-mention 系统的价值。

支持的 @-mention 类型

@-mention 的最佳实践

原则一：先 @ 后问

错误的做法：

为什么这个函数不工作？

AI 只能猜你在说哪个函数。如果它猜的文件恰好没打开，回答可能就是错的。

正确的做法：

@src/utils/auth.ts 为什么这个 login 函数在异步调用时返回 undefined？

AI 读到了明确的内容，回答的准确率直线上升。

原则二：多文件引用建立全局上下文

当你的问题跨越多个文件时，把相关文件都 @ 进来：

@api/routes.ts @api/middleware.ts 我加了新的路由，但中间件没有生效。
检查路由和中间件的注册顺序。

原则三：引用 Terminal 输出做调试

遇到编译错误或运行时报错，不要复制粘贴。直接 @Terminal：

@Terminal 这个错误是什么意思？怎么修复？

AI 会读取终端面板最近一次命令的输出内容，直接分析。

原则四：把 @ 当成”上下文预算”管理

AI 的上下文窗口是有限的。你 @ 的文件越多，AI 的”注意力”就越分散。一个经验法则是：

• 单文件问题：@ 那个文件就够了
• 跨文件问题：@ 核心的 2-3 个文件
• 项目级问题：先让 AI 了解项目结构（@src/），再让它深入个别文件

03 代码解释：Chat 最被低估的能力

很多开发者把 Chat 当成”改代码”的工具，但 Chat 最擅长的事情其实是代码解释——这也是学习新代码库最有效的方式。

四种代码解释场景

场景一：逐行解释

选中一段代码，按 Cmd+K 问”逐行解释这段代码”：

选中代码 → Cmd+K → "请逐行解释这段代码做了什么，假设我是 Python 初学者"

AI 会逐行输出注释，解释每一行的作用和背后的原理。这是理解不熟悉的代码库最直接的方法。

场景二：提炼高层逻辑

如果代码很长，不要逐行解释，而是让 AI 给出抽象总结：

@src/core/engine.ts 这个文件的核心逻辑是什么？
它的输入输出是什么？不需要逐行解释，给我一个高层架构 view。

场景三：图解数据结构

@src/utils/tree.ts 这段代码构建了一个什么数据结构？
画 ASCII 图帮我理解节点的父子关系。

AI 会输出类似这样的 ASCII 图：

       Root
     /      \
   Node1   Node2
   /   \       \
Child  Child   Child

场景四：对比两段代码

如果你想理解重构前后的区别：

@utils/old-version.ts 和 @utils/new-version.ts
这两段代码有什么区别？新版本做了哪些改进？
有什么潜在的 Breaking Changes 吗？

代码解释的 Prompt 技巧

04 用 Chat 做代码审查

Chat 模式可以当轻量级 Code Review 工具用。虽然不如专门的 Code Review 工具（如 GitHub PR Review）系统，但在日常开发中极其高效。

审查别人的代码

当你接手一段别人写的代码，或者 review 同事的 PR 时，把相关文件拖给 Chat：

@src/modules/payment.ts 这是同事刚提交的支付模块代码。
请帮我做 Code Review，关注：
1. 有没有安全漏洞
2. 有没有明显的逻辑错误
3. 代码风格是否符合最佳实践
4. 有没有可以简化的地方

AI 会从多个维度给出反馈。你可以追问具体的点：

你说的第三条"未捕获的异常"，能举一个具体的例子吗？
应该怎么修？写一段示例代码给我看。

审查 AI 生成的代码

这是最值钱的使用场景——Builder 或 SOLO 模式生成的代码，一定要用 Chat 复审一遍。

工作流程：

Builder/SOLO 生成代码
    ↓
切换回 Chat 模式
    ↓
@ 审查生成的文件
    ↓
"帮我 review 这个文件，检查有没有错误、漏洞、性能问题"
    ↓
根据 Chat 的反馈决定：接受、修改、或回滚

Chat Code Review 的 Checklist

每当你让 Chat 审查代码时，可以要求它按以下清单检查：

请按以下维度审查代码：

完整性问题：
- 文件是否完整？有没有缺少的函数或方法？
- 有没有未实现的 TODO？

逻辑正确：
- 边界条件是否处理了？
- 异常处理是否完善？

安全性：
- 有没有硬编码的密钥或 Token？
- 用户输入是否被消毒？
- 有没有 SQL 注入或路径遍历风险？

性能：
- 有没有不必要的循环或重复计算？
- 数据库查询有没有 N+1 问题？

代码风格：
- 命名是否一致？
- 有没有死代码或注释掉的代码？

注意：Chat 做的 Code Review 不能替代人工 Review。AI 可能会漏掉业务逻辑层面的问题，也可能会产生”幻觉式审查”——指出并不存在的 Bug。把 Chat 的 Review 当成辅助检查，不要盲目信任。

05 Apply 按钮工作流

Chat 模式有一个和其他模式最本质的区别：AI 不会主动改你的文件。AI 给出代码建议，你需要手动点 Apply 按钮才能把改动写入文件。

这个设计不是缺陷，而是特性——它给了你完整的控制权。

Apply 工作流的三个步骤

第一步：AI 生成建议
     ↓
AI 在对话气泡中显示代码 diff（高亮新增、删除的行）
     ↓
第二步：你审查 diff
     ↓
检查：这段代码真的是你想要的吗？
     有没有改多余的东西？
     有没有漏掉必要的逻辑？
     ↓
第三步：你决定
     ↓
┌─── Accept ───┐          ┌─── Reject ───┐
│ 点 Apply 按钮  │          │ 按 Esc 或    │
│ 改动写入文件   │          │ 忽略气泡     │
│ Cmd+Z 可撤销  │          │ 什么都不变   │
└───────────────┘          └──────────────┘

Apply 的进阶用法

部分应用：AI 改动了 3 处代码，但你只想接受其中 1 处？

目前的 Apply 是一次性全接受的。但你可以：

1. 先在对话中告诉 AI “只改第 2 个函数，别的保持原样”
2. 或者手动复制你想要的代码段，粘贴进文件

拒绝后的回滚：如果 Apply 后发现不对，Cmd+Z（撤销）就是你的回滚按钮。Apply 本质上就是一次文件写入操作，标准的编辑器撤销可以逆转它。

为什么 Apply 机制重要

理解 Apply 的设计意图，有助于你更好地使用 Chat：

心智模型：Apply 按钮就像安全阀——它确保 AI 的建议在变成现实之前，经过了你的眼睛。这是 Chat 模式最适合初学者和敏感代码的根本原因。

06 Chat vs Builder vs SOLO：决策框架

很多初学者困惑的一个问题是：我该用哪个模式？ 这里提供一个实用的决策框架。

一分钟决策树

你的目标是？
    │
    ├── 问问题 / 理解代码 / 学东西
    │   └── → Chat 模式（侧边栏或 Inline）
    │
    ├── 让 AI 动手改代码
    │   │
    │   ├── 只是改一小段（某几行、某个函数）
    │   │   └── → Inline Chat（Cmd+K）
    │   │
    │   ├── 需要改多个文件，但你知道怎么改
    │   │   └── → 侧边栏 Chat（逐文件讨论 + Apply）
    │   │
    │   ├── 从零建一个独立的新项目
    │   │   └── → Builder 模式
    │   │
    │   └── 在现有项目上加复杂功能 / 修 Bug
    │       └── → SOLO 模式
    │
    └── 不确定？先 Chat 讨论方案
        └── → 聊清楚了再切 Builder/SOLO

模式对比速查表

典型场景的模式选择

场景一：你在学一个开源项目

→ Chat 模式
为什么？你需要理解代码，不是改代码。逐行解释、架构分析、API 文档生成
——全是 Chat 的强项。

场景二：老板说”加一个搜索功能”

→ 先 Chat 讨论方案 → 切 SOLO 实现
为什么？先用 Chat 对齐需求和技术方案，
然后让 SOLO 去干苦力活。你 review 结果。

场景三：写了一个函数，总觉得可以更优雅

→ Inline Chat（Cmd+K）
选中函数 → 按 Cmd+K → "帮我重构这个函数，
让它更可读，遵循函数式编程风格"

场景四：想做一个”番茄钟”网页

→ Builder 模式
"用 React + Tailwind CSS 做一个番茄钟，
有 25 分钟计时和 5 分钟休息"
Builder 会创建完整项目并启动预览给你看。

场景五：跑完测试报了一个诡异的错

→ Chat 模式 + @Terminal
"@Terminal 这个测试报错了，为什么？
是代码问题还是测试代码的问题？"

07 对话历史与会话管理

Chat 模式支持会话历史记录，但它的机制有些细节你需要了解。

会话是如何组织的

每次你在侧边栏 Chat 中发出的消息，都会被记录在历史列表中。历史列表按时间排列，每条记录显示：

• 第一条消息的摘要
• 时间戳
• 如果包含代码修改，会标记是否有 Apply

历史管理操作

历史会话的坑

坑一：历史恢复 ≠ 上下文恢复

点开一个历史会话，AI 会显示之前的对话内容，但 AI 的实际上下文状态可能和当时不同。因为：

• 文件内容可能变了
• 打开的编辑器文件不同了
• 终端输出不同了

所以恢复历史会话后，最好重新 @ 相关文件，确保 AI 看到的是当前版本。

坑二：长对话会变”笨”

一个 Chat 会话用到 30-40 轮之后，AI 会开始”健忘”——它记得对话开头的内容，但细节越来越模糊。这是上下文窗口撑满的正常现象。

解决方法：

• 主动开启新会话：感觉对话变慢了、AI 开始答非所问，就开一个新的会话
• 复杂话题拆成多个会话：把”讨论方案”和”执行修改”分成两个会话
• 关键信息重新 @：即使在同一会话中，重要的上下文也要定期重新引用

会话管理的黄金法则

一个会话 = 一个任务
不要在一个会话里讨论三个不相关的事情。
任务完成了 → 新建会话。

08 实用 Prompt 示例

以下是一些经过验证的 Chat Prompt，按场景分类。

代码理解

@src/components/Table.tsx
这个组件接受哪些 props？它的内部状态管理逻辑是怎样的？
用列表形式列出它的核心渲染路径。

@src/store/userStore.ts
这段代码用了什么状态管理方案？解释 create、set、get 的职责。
画一个简单的数据流图（可以用 ASCII）。

调试

@src/api/fetchData.ts @Terminal
接口返回了 500 错误。检查这个请求的完整链路：
参数传递 → API 调用 → 错误处理 → 返回。
每一步可能出什么问题？

@src/hooks/useAuth.ts
我调用了 login() 但之后 user 对象还是 null。
在这个文件里，login 函数执行后 state 是怎么更新的？
是不是异步更新的问题？

重构

@src/utils/formatDate.ts
这个文件里的日期格式化逻辑散布在 3 个函数里。
帮我重构：把公共逻辑提取出来，减少重复代码。
生成重构后的完整文件给我看。

代码 Review

以下是 @src/services/paymentService.ts 的 Code Review 结果。
请重点关注：
1. try-catch 是否覆盖了所有可能的异常
2. 有没有泄漏敏感信息（如 API Key、用户数据）
3. 事务逻辑是否正确——如果中间步骤失败，数据会不一致吗？

写作辅助（很多人忽略的用法）

Chat 不只写代码——它还能帮你写文档:

@README.md
帮我完善这份 README，加上：
1. 项目简介（2-3 句话）
2. 安装步骤
3. 环境变量说明
4. 常用命令
保持简洁，不要过度修饰。

09 小结

下一篇：06 Builder 模式 —— Builder 模式的完整指南：从一句话需求到可运行项目。