# 第 14 章 上下文管理：善用 /clear 与"三段式"重建

## 本章目标

- **O1** 能够追踪“状态沉淀”“清理会话”“约束重建”之间的前向与反馈路径（产物：三段式上下文重建包）
  - 证据: 三段式上下文重建包画出“状态沉淀”“清理会话”“约束重建”的前向路径和返回路径
- **O2** 能够构造三段式上下文重建包，注明每轮输入、判断和回写证据（产物：三段式上下文重建包）
  - 证据: 三段式上下文重建包为每一环写明输入、判断、输出和负责人
- **O3** 能够在清理会话后用持久状态重建任务而不依赖聊天记忆（产物：三段式上下文重建包）
  - 证据: 产物包含清理前状态、重建输入和清理后核验差异

## 学习路径

- **初学者**: 本章迁移任务是：能够在清理会话后用持久状态重建任务而不依赖聊天记忆。先按图中的“反馈闭环”关系完成三段式上下文重建包的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够在清理会话后用持久状态重建任务而不依赖聊天记忆。提交三段式上下文重建包后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 三段式上下文重建包
- **图解类型**: context-rebuild
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 状态沉淀 · 清理会话 · 约束重建

![第 14 章三段式上下文重建包教学图](/learning/diagrams/zh/chapter-14.svg)

沿前向与返回两条路径检查三段式上下文重建包，确认结果确实改变下一轮输入。

图先从“状态沉淀”前向经过“清理会话”到“约束重建”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 14.1 什么时候必须清空会话（五条硬标准）

很多开发者习惯在一个 IDE 的聊天窗口或网页对话框里，从建项目第一天一直聊到项目上线，期望 AI 能记住所有的前因后果。这是一个极其灾难性的做法。

反复失败的尝试和废弃逻辑可能挤占有效上下文、干扰后续判断；已经核实的发现仍有价值，应保存到文档。长对话本身不必然导致严重幻觉，风险取决于内容相关性、模型预算和上下文管理方式。这就像在一个堆满了建筑废料、废弃草图和历史垃圾的工地上，你指望实施队还能精确地看清脚下的地基线。

我们把这项纪律称为"上下文断头台"，用于打断无效尝试。以下五条是本书的操作触发标准；命中后先停止无效尝试，保存已验证状态与未决问题，再清空会话，重新读取、复述并核验：

1. AI 开始"兜圈子"：同一个问题绕了三次以上还没解决，或者修复了一个 Bug 引入了新的 Bug；
2. 已经发生了"纠错拉锯"：你和 AI 就某个问题进行了超过两轮的"指正-辩解"对话，且没有收敛迹象；
3. 你识别到了"确认偏误"信号：AI 在维护一个明显错误的方案，甚至开始"炫技"用复杂逻辑掩盖错误；
4. 里程碑验收通过并固化：这是一个"例行清空"——每次固化一个关键结构里程碑后，先把已验证状态沉淀到文档，再清空会话；
5. 会话已经很长：轮数阈值（如教学示例中的 50-100 轮）只提醒检查，不单独证明失效；应结合预算占用、无关信息及反复遗漏约束决定是否重建。

### 14.2 "三段式"上下文重建法：身份注入 → 状态恢复 → 行动指令

重置上下文绝不意味着丢失进度。正确的做法是：从当前工程中提取出最新且正确的核心接口定义、数据库结构契约，以及下一步即将要做的目标待办（Next Step）清单。将这些纯净的"有效资产"打包，作为全新的"实施图纸"，在一个全空的新对话窗口中喂给 AI。

这种做法的本质，是彻底切断 AI 的"历史负面记忆"。你相当于解雇了一批疲惫不堪、脑子里充满混乱逻辑的旧实施队，然后拿着经过梳理的、极其清晰的最新图纸，重新雇佣了一批头脑清醒、注意力高度集中的新实施队，让他们直接从当前最坚固的台阶上继续往上建。

"三段式"上下文重建法的具体操作：

<!-- code-example:chapter-14-E1 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
第一段：身份注入（我是谁，项目是什么）
"请阅读项目根目录的 @CONTEXT.md，深刻理解当前系统的架构规约、
不可修改的固化节点（已完成的里程碑），明确当前的实施进度。
同时读取 .docs/AGENTS.md 与 .docs/ARCHITECTURE.md 的行为义务和红线。"

第二段：状态恢复（现在在哪、从哪继续）
"根据 CHANGELOG.md 的最新条目和 job.progress.md，我们当前处于
Phase 2，刚刚完成里程碑 2.2（创建订单）。"

第三段：行动指令（接下来做什么、怎么做）
"理解完毕后，请直接开始执行下一步待办（Next Step）计划（里程碑 2.3 订单详情），
并给出你的实现思路。请先输出方案，确认后再开始编码。"
```

上下文注入提供了重新对齐的材料，不能保证瞬时、完美交接。让 AI 复述目标、适用红线、已验证状态及下一步，再与文档和实际工作区核对；有遗漏先补齐，有冲突先解决，才继续已授权工作。

### 14.3 避免把会话变成"垃圾信息堆"

即使不触发清空条件，你也可以在日常交互中控制信息质量，避免会话过早腐化：

1. 先保存结论，再处理历史：记录已验证事实与废弃原因；单说"忘掉之前"不会保证历史移除。使用工具支持的清空或压缩功能，并检查保留的材料；
2. 重要信息只进文档不进对话：任何重要的决策、核心规则、阶段性成果，都在第一时间沉淀到项目文档中，而不是只存在于对话上下文里；
3. 及时叫停"无意义辩论"：你是在和一个毫无情绪、只有概率计算的机器对话。争辩不会让它"顿悟"，只会让当前对话窗口填满更多错误逻辑和垃圾上下文。一旦发现 AI 开始兜圈子，停止无效尝试，保存已验证状态后再重建上下文；是否重建代码另按第 10 章判断；
4. "降噪"你的指令：不要在指令里堆砌无关的上下文、历史背景。给 AI 的信息越干净，它的注意力越集中。

记住：对话历史不是你的资产，而是你的负债。放弃对对话历史的任何幻想，让文档成为你和 AI 之间唯一的、永恒的、不可动摇的"单源真相"。

### 【操作卡】/clear 后快速重启的四个步骤

目的：让"清空会话"成为一个毫无压力、随时可用的动作，而不是需要心理建设的决定。

<!-- code-example:chapter-14-E2 mode:reference -->
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```text
1. 确认文档已更新
   □ CONTEXT.md（蓝图）——架构是否与当前代码一致？
   □ CHANGELOG.md（航行日志）——今天的进展写了吗？
   □ job.progress.md / TODO 清单——下一步任务明确了吗？
   如果没有，先花 2 分钟补上。这是清空的"安全前提"。

2. 执行工具支持的 /clear（以 Claude Code 为例）
   确认第 1 步已完成，再清空当前会话。自然语言要求"忘记"不是清空操作。

3. 三段式重建
   新会话第一条消息：
   "请阅读 @CONTEXT.md、@.docs/AGENTS.md、@.docs/ARCHITECTURE.md
    和 @.docs/CHANGELOG.md，明确当前事实、约束与进度。
    我们正处于里程碑 X，下一步是 Y。请先给出实现思路，确认后再开始。"

4. 验证 AI 理解正确
   让 AI 复述：它理解的当前架构、固化节点、下一步任务。
   如果理解正确，让它开始；如果跑偏，纠正后再继续。
   确认无误后，用一条最短的指令（如"开始"）放行。
```

工具行为参见 [Claude Code 最佳实践](https://code.claude.com/docs/en/best-practices)：/clear 用于重置上下文；工具还可能支持压缩。保存、复述与核验是本书的操作纪律，不能把清空命令当成质量保证。

最后记住第 14.1 节那句在实践中反复应验的话：清空会话不是"放弃进度"，而是"带着最新的图纸，从最坚固的台阶上继续往上建"。

---

> 第四部分完成。你已经掌握了用文档和边界把 AI 框住的方法：需求分析（Event Storming、REQUIREMENTS.md 与分歧记录）、蓝图设计（CONTEXT.md 的七个部分与四大原则）、有效约束（三驾马车文档、负空间设计、约束指令五原则、模块化解耦）、上下文管理（五条清空硬标准与三段式重建法）。

> 现在，让我们进入第五部分：技能体系——14 个技能的协作与选择。你将看到，一个完整的 AI 编码团队，是如何像一支分工明确的施工队一样运作的。

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-14.md`，写上版本、决定、证据和缺项。

设计一次会话交接：保存状态，分别写身份与约束、已验证状态、下一步任务。另列三个不能从聊天历史直接相信的事实。

<!-- chapter-artifact-requirement -->
### 本章必交产物：三段式上下文重建包

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 三段式上下文重建包画出“状态沉淀”“清理会话”“约束重建”的前向路径和返回路径
- O2: 三段式上下文重建包为每一环写明输入、判断、输出和负责人
- O3: 产物包含清理前状态、重建输入和清理后核验差异

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

核验当前分支、文件差异和检查日志，再交接。新会话保留权限和安全边界，说明未完成事项与失败。清理会话不清理工作区、不重置授权，也不能保证模型遗忘；不要仅凭上次助手说‘通过’当作验收记录。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；三段式上下文重建包、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Git 官方参考](https://git-scm.com/docs) — Git project, 2026-09-17. 版本、分支、提交与恢复操作须按实际仓库状态验证。
- [Claude Code 最佳实践](https://code.claude.com/docs/en/best-practices) — Anthropic, 2026-09-17. 文档说明清理或压缩上下文等工具行为；这些操作本身不保证交付质量。