3.5.5 知道何时开始新对话
经过本节学习，你将掌握
- 识别「该开新对话」的三个信号
- 理解为什么「清新开始」有时比「继续修补」更高效
- 学会「搬家」：把关键信息从旧对话带到新对话
- 获得一个可复制的新对话启动模板
旧对话太长会怎样？
在 3.5.4 中，我们讲了上下文窗口的概念。当对话太长时，早期内容会被挤出窗口，导致 AI「失忆」。
但问题不止于此。即使内容没被挤出，太长的对话也会降低 AI 的表现：
| 问题 | 原因 |
|---|---|
| 回复变慢 | 需要处理更多历史信息 |
| 容易遗漏指令 | 关键信息淹没在大量对话中 |
| 更容易出错 | 历史中的矛盾信息会干扰判断 |
| 难以调试 | 你也很难回溯问题出在哪一轮 |
有时候，开一个新对话比在旧对话里继续挣扎更有效。
三个「该开新对话」的信号
信号一：对话超过 20 轮
这是一个经验值。当对话轮次超过 20 轮（你发一条、AI 回一条算一轮），就应该考虑开新对话了。
为什么是 20 轮？
- 每轮对话平均 500-1000 tokens
- 20 轮 ≈ 10K-20K tokens
- 已经占用了相当比例的上下文窗口例外情况：如果你用的是大上下文窗口模型（如 Claude 200K），可以适当放宽到 30-40 轮。
信号二：AI 开始「忘记」早期约定
当你发现以下情况时，说明上下文管理已经失效：
❌ 你第 1 轮说用 TypeScript，AI 第 18 轮给你 JavaScript
❌ 你第 3 轮说不要用 any，AI 第 15 轮代码里全是 any
❌ 你问"按照之前的格式"，AI 问你"什么格式？"判断方法：如果你发现自己需要反复重申同一个约定（超过 3 次），就该开新对话了。
信号三：话题发生根本转变
当你从一个任务转向另一个完全不同的任务时，旧对话的历史反而会干扰。
旧话题：实现用户登录功能
新话题：设计数据库表结构
两个话题关系不大，旧对话中的登录代码会占用上下文空间，
却对设计数据库没有帮助。经验法则：如果新任务和之前的对话内容没有直接关联，开新对话。
三个信号的速查表
| 信号 | 判断标准 | 行动 |
|---|---|---|
| 轮次过多 | 超过 20 轮 | 考虑开新对话 |
| AI 失忆 | 反复重申约定超过 3 次 | 立即开新对话 |
| 话题转变 | 新任务与历史无关 | 开新对话 |
如何「搬家」：把关键信息带到新对话
开新对话不意味着从零开始。你需要把关键信息「搬」到新对话中。
第一步：从旧对话中提取关键信息
在旧对话结束前，让 AI 帮你总结：
markdown
请总结我们这次对话的关键信息，包括：
1. 项目的技术栈和约定
2. 已完成的功能列表
3. 当前的代码结构
4. 遗留的问题或待办事项
请用简洁的 Markdown 格式输出，方便我复制到新对话中。第二步：保存总结
把 AI 的总结保存下来。可以：
- 复制到一个文本文件
- 保存到项目的 README 或 NOTES.md
- 直接记在脑子里（如果内容不多）
第三步：在新对话中重建上下文
用提取的信息开始新对话：
markdown
我要继续开发一个待办清单项目。以下是项目背景：
**技术栈**：
- React 18 + TypeScript
- Tailwind CSS
- Zustand 状态管理
**已完成功能**：
1. 添加任务（带空输入验证）
2. 删除任务（带确认提示）
3. 任务列表展示
**代码结构**：
- src/components/AddTaskForm.tsx
- src/components/TaskList.tsx
- src/components/TaskItem.tsx
- src/store/taskStore.ts
**当前任务**：
实现任务编辑功能——点击任务可以修改标题
请基于以上背景，帮我实现任务编辑功能。可复制模板：新对话启动 Prompt
通用模板
markdown
我要继续开发 [项目名称]。以下是项目背景：
## 技术栈
- [技术1]
- [技术2]
- [技术3]
## 编码约定
- [约定1]
- [约定2]
- [约定3]
## 已完成功能
1. [功能1]
2. [功能2]
3. [功能3]
## 代码结构
- [目录/文件1]：[用途]
- [目录/文件2]：[用途]
## 本次任务
[详细描述你要做的事情]
请基于以上背景开始。简化模板（适用于简单项目）
markdown
继续开发 [项目名称]，技术栈：[技术栈]。
已完成：[简要列举]
现在要做：[本次任务]
注意事项：
1. [约定1]
2. [约定2]带代码上下文的模板
markdown
我要继续开发一个功能。以下是相关的现有代码：
**现有组件**（TaskList.tsx）：
```tsx
// 这里粘贴相关代码片段现在需要： [描述你需要 AI 做的事情]
请注意：
- 保持和现有代码风格一致
- [其他约定]
## 什么时候不需要开新对话？
有时候旧对话还是更好的选择：
| 情况 | 建议 | 原因 |
|-----|------|------|
| 对话还在 10 轮以内 | 继续旧对话 | 历史信息仍然有价值 |
| 正在调试一个 bug | 继续旧对话 | 错误上下文很重要 |
| 功能实现到一半 | 继续旧对话 | 避免重新解释 |
| 需要引用之前的代码 | 继续旧对话 | 代码在历史中可直接引用 |
**核心原则**：如果旧对话的历史对当前任务仍然有帮助，继续用；如果已经变成负担，果断开新的。
## 「清新开始」的心理优势
除了技术原因，开新对话还有心理上的好处：旧对话： "之前改了这么多轮还没改好，是不是我的问题..."
新对话： "这是一个全新的开始，这次一定可以"
有时候，一个干净的起点能帮助你更清晰地思考问题。
## 实战技巧：对话命名
很多 AI 工具支持给对话命名。善用这个功能：❌ 默认命名："New Chat"、"Untitled" ✅ 有意义的命名："待办清单-添加功能"、"待办清单-删除功能"
好的命名能帮你：
- 快速找到历史对话
- 知道每个对话在做什么
- 决定是继续旧对话还是开新对话
## 本节要点
✓ **三个信号**：超过 20 轮、AI 反复失忆、话题根本转变
✓ **清新开始的价值**：有时比继续修补更高效
✓ **搬家流程**：让 AI 总结 → 保存 → 新对话中重建上下文
✓ **启动模板**：用结构化的 Prompt 开始新对话，快速重建上下文
✓ **对话命名**：给对话起有意义的名字，便于管理
## 本章总结
恭喜你完成了 3.5 节「迭代对话的艺术」的学习。
回顾一下你学到了什么：
| 小节 | 核心收获 |
|-----|---------|
| 3.5.1 | 一次搞定是幻觉，迭代是常态 |
| 3.5.2 | 三阶段模型：看方向 → 改问题 → 磨细节 |
| 3.5.3 | SBI 反馈框架，让 AI 精准理解你的修改需求 |
| 3.5.4 | 四个上下文管理技巧 + 工具级配置 |
| 3.5.5 | 知道何时「搬家」，如何「搬家」 |
**一句话总结**：迭代不是失败，而是通往成功的必经之路。
下一节（3.6），我们将学习当 AI「不听话」时——输出错误、产生幻觉、代码有 bug——如何诊断问题并修正。