Awesome Study Agent

Appearance

2026-02-03
1662
6m

为什么需要上下文管理 ​

核心观点：让 AI 理解你的项目，才能给出有用的建议

从一个实际问题说起 ​

场景：让 AI 帮你写代码 ​

假设你在做一个外卖订餐系统，你需要添加一个"优惠券"功能。

情况 A：没有上下文管理

你：帮我写一个优惠券功能

AI：好的！优惠券功能包含以下部分：
1. 优惠券创建
2. 优惠券发放
3. 优惠券核销
4. 优惠券统计

以下是代码实现...
（给了一套通用的优惠券代码）

问题：

  • ❌ 代码风格和你的项目不一样
  • ❌ 用了你项目里没有的库
  • ❌ 没有考虑你项目的业务规则
  • ❌ 你需要花大量时间修改

情况 B：有上下文管理

你：帮我写一个优惠券功能

AI：我先看一下你的项目 Wiki...

（AI 读取了项目文档）

AI：明白了！根据你的项目 Wiki：
- 你用的是 Nest.js + TypeORM
- 代码风格参考 `src/modules/order` 模块
- 业务规则：满减券、折扣券、新人券三种
- 数据库表名用下划线命名

我给你写一套符合你项目规范的代码：
（给出了完全符合项目风格的代码）

好处：

  • ✅ 代码可以直接用
  • ✅ 风格统一
  • ✅ 符合业务规则
  • ✅ 节省大量时间

什么是上下文？ ​

上下文（Context） = 让 AI 理解你项目所需的所有背景信息

技术上下文 ​

  • 技术栈：语言、框架、数据库
  • 项目结构：代码目录怎么组织
  • 代码规范：命名风格、注释要求
  • 开发环境：用什么工具、如何运行

业务上下文 ​

  • 产品定位：做什么的、目标用户
  • 业务规则：有哪些约束条件
  • 数据模型：核心实体和关系
  • 工作流程：业务流程是怎样的

历史上下文 ​

  • 之前的技术决策
  • 为什么选择这个方案
  • 遇到过什么问题
  • 如何解决的

为什么需要专门管理上下文？ ​

问题 1：AI 的记忆有限 ​

现状：

  • 大多数 AI 模型的上下文窗口有限（几十万 token）
  • 每次新对话，AI 都"忘记"之前的内容
  • 即使是同一个对话，太长之后 AI 也会"忘记"前面的内容

解决：

  • 把重要的上下文写在文档里
  • AI 需要时随时查阅
  • 不占用对话的 token

问题 2：重复解释浪费时间 ​

没有文档时：

第 1 天问 AI：
"我的项目用的是 Nest.js，数据库是 PostgreSQL..."

第 2 天问 AI：
"我的项目用的是 Nest.js，数据库是 PostgreSQL..."

第 3 天问 AI：
"我的项目用的是 Nest.js，数据库是 PostgreSQL..."

有文档后：

在 Wiki 里写一次

每次问 AI：
"参考项目 Wiki 的技术栈章节"

问题 3：团队协作不一致 ​

没有统一上下文：

  • 开发者 A 问 AI：得到方案 X
  • 开发者 B 问 AI：得到方案 Y
  • 两人写出来的代码风格不一样
  • 后期维护成本高

有统一上下文：

  • 所有人都基于项目 Wiki 问 AI
  • AI 给出的建议保持一致
  • 代码风格统一
  • 团队协作更顺畅

问题 4：项目交接困难 ​

没有文档：

  • 开发者离职后
  • 新人完全看不懂代码
  • AI 也不了解项目背景
  • 接手成本极高

有文档：

  • 项目 Wiki 记录了所有重要信息
  • 新人通过 Wiki + AI 快速上手
  • 大大降低交接成本

上下文管理的层次 ​

层次 1：无管理（不推荐） ​

特点：

  • 没有任何文档
  • 每次都口头/临时解释

适合：

  • 极小的个人项目
  • 一次性脚本

问题：

  • 无法复用
  • 难以维护
  • AI 帮忙效率低

层次 2：简单文档（入门） ​

特点：

  • 有一个 README.md
  • 记录基本信息

适合：

  • 小型个人项目
  • 学习项目

示例：

markdown
# 我的项目

## 技术栈
- React + TypeScript
- Tailwind CSS

## 运行
npm install
npm run dev

层次 3：结构化 Wiki（推荐） ​

特点：

  • 完整的文档系统
  • 按主题组织
  • 可搜索、可导航

适合：

  • 中大型项目
  • 团队协作
  • 这是本模块重点推荐的方式

工具：

  • VitePress
  • GitBook
  • Notion
  • Confluence
  • Docusaurus

层次 4：自动化集成（高级） ​

特点：

  • 文档和代码同步更新
  • AI 可以自动读取
  • 集成到开发流程

适合：

  • 大型企业项目
  • 需要 AI 深度参与的项目

示例：

  • 代码生成文档
  • CI/CD 自动更新文档
  • RAG 系统集成

实际对比：有/无上下文管理 ​

场景：让 AI 帮忙排查 Bug ​

无上下文管理：

你：用户登录后看不到订单列表，帮我看看

AI：请提供以下信息：
1. 你用的什么技术栈？
2. 订单列表的数据从哪来？
3. 控制台有什么报错？
4. 用户登录后拿到的 token 是什么？

你：React + Node.js，从后端 API 拿数据...（解释半天）

有上下文管理：

你：用户登录后看不到订单列表，帮我看看

AI：我看了你的项目 Wiki：
- 订单列表在 `src/pages/Orders.tsx`
- API 调用用 `useOrders` hook
- 认证用 JWT 存在 localStorage

可能的问题：
1. localStorage 的 token 格式不对（你用的是 `Bearer ${token}`）
2. `useOrders` hook 的错误处理可能吞掉了错误
3. 检查浏览器开发者工具的 Network 面板，看 API 返回了什么

你要我具体看哪一块代码？

对比：

  • 无上下文：问 10 句话，AI 还不知道从哪开始
  • 有上下文：AI 直接给出 3 个可能的原因

什么时候特别需要上下文管理？ ​

✅ 强烈推荐 ​

  1. 多人协作项目

    • 保持所有人理解一致

  2. 长期维护的项目

    • 新人快速上手
    • 防止知识流失

  3. 频繁让 AI 帮忙的项目

    • 节省重复解释的时间
    • 提高 AI 建议质量

  4. 复杂业务逻辑

    • 记录业务规则
    • 说明决策原因

  5. 需要 AI 写大量代码

    • 代码风格统一
    • 符合项目规范

⚠️ 可以不做 ​

  1. 一次性脚本

    • 写完就用，不会维护

  2. 极简单的学习项目

    • 练手代码，没有实际业务

  3. 个人小工具

    • 一个人用，逻辑简单

下一步 ​

现在你已经理解了为什么需要上下文管理。

接下来，我们将学习如何用 Wiki 系统来管理上下文，并详细拆解"拉了么"项目的实践案例。

← 返回模块目录 | 继续学习：Wiki 系统最佳实践 →

最近更新

基于 Apache 2.0 许可发布

Copyright © 2026-present Awesome Study Agent