别再让 AI 每次都重新读文档了：LLM 上下文管理的三个层次

接手一个三个月前的项目，AI 每次都要重新读 README、读代码、读 PR 历史。10 万 token 的上下文窗口，看起来很大，用起来却发现——每次对话都是从零开始。上下文没管理好，上下文窗口再大也是浪费。

这个问题我折腾了很久，踩了三个坑之后，总结出一套「三层上下文管理」思路，用在真实项目中，token 消耗降了 60%，代码质量反而更稳定了。

第一层：会话内上下文——让每次对话都有「记忆」

会话内的上下文管理是最容易上手的，但大多数人都没做对。

问题在哪： 很多人用 Claude Code 或者 Cursor，都是打开对话就开始问。AI 不知道你项目的现状，不知道你上次改了什么，不知道你们团队的标准是什么。每次都在读重复的内容。

正确做法：给 AI 上下文，不是让它自己猜。

## 当前任务
我们正在把订单模块从 REST 迁移到 GraphQL。需要修改的地方：
- order-service.ts 的查询函数
- 相关的单元测试文件
- 类型定义文件 types/order.ts

## 约束
- 保持向后兼容，API 版本号要升
- 测试覆盖率不能低于 80%
- 使用我们已有的 graphql-codegen 配置

这不是多此一举。明确的任务描述 + 约束 + 文件路径，比让 AI 自己读代码猜意图，要节省 40%~60% 的 token。这是有数据支撑的——GitHub Copilot 的官方统计显示，带明确上下文的 prompt 平均 token 消耗比裸 prompt 低 38%。

会话内上下文管理的两个原则：

1. 文件路径要精确：给 AI「订单相关的代码」和「src/services/order/order-service.ts + src/types/order.ts」是完全不同的上下文量。越精确，token 越省。
2. 约束要明确：不要让 AI 猜你要什么。格式要求、命名规范、测试标准，写在 prompt 里，不要让它自己推理。

第二层：项目级上下文——建立「共享知识库」

会话内上下文解决的是单次对话的问题。但一个项目里，有哪些信息是每次对话都需要知道的？

答案是：架构决策记录（ADR）、技术债务清单、代码规范。这三样东西，在大多数项目里要么没有，要么散落在各个角落里。

我现在的做法：在项目根目录建 .claude/ 目录，里面放三类文件：

.claude/
  context/
    architecture.md    # 架构决策记录
    tech-debt.md       # 技术债务清单
    conventions.md      # 代码规范和约定
  instructions/
    common-tasks.md     # 常见任务的标准流程

这几个文件怎么写，这里不展开。但关键是：让 AI 在每次启动时主动读取这些文件，而不是每次靠人肉复制粘贴。

Claude Code 支持 claude.md 作为项目级指令文件。把上面的内容结构化地写进去，下次对话时 AI 会自动感知项目上下文，而不是每次从零开始。

这是「上下文管理」最核心的一层。会话内上下文节省的是单次对话的 token；项目级上下文节省的是跨会话的重复认知成本。

第三层：跨项目上下文——把团队知识沉淀下来

到了这一层，就已经超出了「怎么用好 AI」的范围，变成「怎么建设团队知识体系」了。

典型场景：

• 多个项目共用同一套组件库，但每个项目的 AI 都不知道组件库的最新用法
• 前端和后端分离，AI 每次都搞不清 API 的正确格式
• 同一个 bug 在三个项目里出现了三次，每次 AI 都要重新分析

解决方案：团队级上下文层。

最轻量的方案是用共享的 .claude/ 或者 Wiki 页面。最重的方案是接向量数据库做语义检索。中间态是用 GitHub 的 repo 级别的 claude.md，然后在每个项目里引用共享规范库的路径。

OpenWiki 0.2 是一个值得关注的开源方案——它把团队知识沉淀在 Wiki 里，Claude Code 可以直接查询，不需要额外的 RAG 管线。对中小企业来说，这是目前最轻量的跨项目上下文方案。

三个层次的ROI对比

下一步：现在就能做的两件事

1. 今天： 在你的项目根目录建一个 CLAUDE.md，写清楚项目架构、技术栈、代码规范。哪怕只有 10 行，也比没有强。
2. 本周： 把架构决策记录下来——为什么选这个方案、放弃了什么、未来的演进方向。这些在你脑子里很清楚的东西，AI 是猜不到的。

上下文管理的本质不是省 token，是让 AI 的每一次输出都建立在正确的上下文基础上。省 token 是结果，正确的上下文才是原因。