Chat 模式（对话模式）

什么是 Chat 模式

Chat 模式是最低门槛的 AI 编程协作方式。开发者通过自然语言对话与 AI 交流，获取代码建议、问题解答、调试帮助等。它不需要复杂的配置，打开就能用。

核心特点：

• 低门槛 — 对话即可，无需学习新工具
• 高灵活 — 不限于代码生成，任何技术问题都能问
• 即时反馈 — 快速获得答案，适合探索性工作
• 上下文感知 — 现代工具支持引用文件、选中代码作为上下文

典型使用场景

1. 代码解释

请解释这段代码的作用：
[粘贴代码]

2. Bug 调试

这段代码运行报错：
TypeError: Cannot read property 'map' of undefined

相关代码：
[粘贴代码]

可能是什么原因？

3. 技术选型

我在做一个实时聊天应用，需要选择消息队列。
候选方案：RabbitMQ、Kafka、Redis Pub/Sub
用户量预计 10 万，消息延迟要求 < 100ms
推荐哪个？为什么？

4. 代码审查

请审查以下代码，重点关注：
1. 安全漏洞
2. 性能问题
3. 代码规范

[粘贴代码]

5. 学习新概念

用通俗的语言解释 React 的 Fiber 架构，
并对比它和 Vue 3 响应式系统的设计差异

各工具的 Chat 入口

上下文管理技巧

上下文管理是区分高效使用者和低效使用者的关键能力。AI 的回答质量直接取决于你提供的上下文质量。

提供充足上下文

❌ "这段代码有问题"

✅ "这个 Vue 3 组件在 onMounted 中调用 API，但返回的数据是 undefined。
    组件代码如下：[代码]，API 服务端返回格式：[示例]"

明确期望输出

❌ "帮我优化这段代码"

✅ "请优化这段代码的性能，重点关注：
    1. 减少不必要的重新渲染
    2. 使用 useMemo/useCallback 缓存
    保持代码风格不变"

分步提问

复杂问题拆成多个小问题，逐步深入：

Step 1: 这个设计模式的优缺点是什么？
Step 2: 如果用在我的场景中，需要做哪些调整？
Step 3: 请给出具体的实现代码

上下文窗口管理

AI 的上下文窗口是有限的。当对话过长时，早期的内容会被"遗忘"。

• 对话超过 20 轮：考虑开新会话，把关键结论带过去
• 引用大文件：只粘贴相关片段，不要贴整个文件
• 多任务混合：一个会话只处理一个主题，避免上下文污染

追问和确认

AI: "建议使用 Redis 缓存"
你: "为什么选 Redis 而不是 Memcached？在我们的场景中 Redis 的持久化策略怎么选？"

会话生命周期管理

何时开新会话

• 切换了完全不同的任务（从"修 Bug"转到"设计数据库"）
• 对话超过 20 轮，AI 开始"忘记"之前的内容
• AI 的回答质量明显下降
• 上一个任务已完成，开始新任务

何时复用旧会话

• 正在迭代同一个功能（AI 已有上下文）
• 需要引用之前的讨论结果
• 任务还没有完成

最佳实践

• 一个会话一个主题：不要在一个会话里又改 Bug 又写新功能
• 重要结论写入文件：不要依赖 AI 的"记忆"，把结论写入代码注释或文档
• 定期清理：关闭不再需要的会话，减少干扰

Chat 模式的局限

• ❌ 不适合大范围代码生成：多文件修改应该用 Composer/Agent 模式
• ❌ 上下文有限：对话太长可能丢失早期上下文
• ❌ 无状态：关闭对话后上下文丢失（部分工具支持历史记录）
• ❌ 无法直接执行：Chat 只给建议，不自动修改代码

与其他模式的关系

Chat 模式（咨询、探索）
    ↓ 需求明确后
Plan 模式（规划、确认）
    ↓ 计划确认后
Agent/Composer 模式（执行、生成）
    ↓ 代码生成后
Chat 模式（审查、调试）

Chat 模式是整个 AI 编程工作流的起点和终点——从对话开始理解需求，到对话结束审查结果。

常见问题