我用 fcontext 解决了 AI IDE 最烦的一个问题：开新会话就失忆
我现在几乎每天都在 AI IDE 里写代码。
Copilot、Cursor、Claude Code 这些工具，确实已经把“写第一版代码”的速度拉上去了。
但只要你连续用几天，就会撞上一个很烦的问题：
开一个新会话，AI 又失忆了。
昨天你们还在讨论 Kafka 分区、异常补偿、模块边界，今天它第一句话又变成：
你现在在做什么项目？
如果你只是在写一个 200 行 demo，这个问题不大。
但只要项目稍微复杂一点，这件事就会非常消耗人。
你要重新解释项目背景、重新复述昨天的决策、重新告诉它哪些坑已经踩过。更麻烦的是，上午你用 Copilot，下午换到 Claude，这套上下文还得再讲一遍。
我被这件事折腾了一段时间之后，做了一个本地工具：fcontext。
它不解决“模型聪不聪明”，它解决的是另一个更基础的问题：怎么让 AI 在不同会话、不同 Agent 之间持续拿到同一份项目上下文。
这篇文章不讲概念，直接讲我怎么用它解决这个问题。
先说结论：问题不在模型，在上下文交付方式
很多人一遇到 AI 失忆，第一反应是：
- 是不是上下文窗口不够大？
- 是不是模型太笨？
- 是不是提示词还不够完整？
我后来发现，很多时候都不是。
根因更像是这样：
- AI 会话默认是短期的
- 项目知识默认散落在代码、文档、聊天记录里
- 不同 Agent 之间默认不共享这些知识
也就是说，真正缺的不是某一句神奇 Prompt，而是一层可持续、可落盘、可复用的上下文管理机制。
如果把 AI IDE 看成一个新来的工程师，那你现在的工作流基本等于：
- 每天早上都给他重新做一遍入职培训
- 每换一个人，就再培训一遍
- 昨天的设计结论不做记录，全靠今天口述重建
这套方式当然会崩。
fcontext 做的事情，其实很简单
它的核心思路不是把记忆塞进模型里，而是把上下文落到项目里。
安装之后，项目目录下会多一个 .fcontext/：
.fcontext/
_README.md # 项目摘要，AI 每次开聊先读它
_workspace.map # 项目结构映射
_topics/ # 对话中沉淀出的关键结论
_requirements/ # 需求、任务、演化关系
_cache/ # PDF / DOCX / XLSX 转成的 Markdown 缓存
你可以把它理解成一层给 AI 用的“项目知识面板”。
工作方式大概是这样：
flowchart LR
A[代码库 / 文档 / 对话] --> B[.fcontext 结构化上下文]
B --> C[Copilot]
B --> D[Cursor]
B --> E[Claude Code]
C --> F[新会话继续干活]
D --> F
E --> F
这里最关键的一点是：
不同 Agent 读的是同一份上下文，而不是你每次手动重讲一遍。
30 秒上手：就 3 行命令
先安装：
pip install fcontext
fcontext init
fcontext enable copilot
如果你主要用的是 Cursor 或 Claude Code，把最后一行换掉就行：
fcontext enable cursor
# 或
fcontext enable claude
这 3 行命令分别做了 3 件事：
pip install fcontext安装工具。fcontext init在项目里初始化.fcontext/目录。fcontext enable <agent>告诉对应的 AI Agent：每次进入项目，先读哪份上下文、怎么维护它。
这套东西是本地优先的：
- 不需要 API Key
- 不要求联网
- 不需要把项目知识传到云端
如果你比较在意隐私或者团队代码安全，这一点很重要。
我是怎么验证它有没有用的
我没有做很复杂的 benchmark，就用最朴素的方式：
连续用 7 天，记录自己少解释了多少次。
我当时在做一个数据管道，和 AI 讨论过这些东西：
- Kafka + ClickHouse 的组合
- 为什么不用 Elasticsearch
- 分区策略怎么选
- 消费者 offset 提交的边界
以前我的习惯是，讨论完之后自己再手写一份备忘录。因为如果不记，第二天基本就得重讲。
这次我故意没记，直接让 fcontext 接管。
第二天我开新会话时，AI 已经能接上昨天的讨论，知道我们为什么选这个方案、下一步要继续什么。
第三天我把 Agent 从 Copilot 切到 Claude Code，它也能直接接上同一套上下文。
对我来说，这个体验变化不是“它回答更华丽了”，而是：
讨论不再每天从第 0 分钟开始。
一个最直观的收益：切 Agent 不用重新做口供
以前最崩的一幕是这样的：
上午用 Copilot 讨论了两个小时，下午它没定位出来一个 Bug，我想换 Claude Code 试试。
结果我还没开始排查问题，就得先重新讲一遍：
- 项目是干什么的
- 昨天为什么选这个架构
- 哪个模块已经改过
- 现在卡在哪个边界条件上
这就很像你在公司里换了个同事接手，第一件事不是解决问题，而是先做知识迁移。
用了 fcontext 之后，流程变成：
fcontext enable claude
然后直接问：
帮我看看消费者 offset 提交的问题，按昨天 Kafka + ClickHouse 的方案继续分析。
重点不在这句话本身。
重点在于，Claude 读到的是和 Copilot 同一份项目上下文。
这时候你的切换成本，不再是“重新建模”，而只是“换个视角继续解题”。
我记录下来的时间账
下面这张表，是我那几天最直接的感受整理：
| 场景 | 以前花的时间 | 用 fcontext 之后 |
|---|---|---|
| 新会话解释项目背景 | 3-5 分钟 | 0 |
| 换 Agent 重新介绍上下文 | 8-10 分钟 | 0 |
| 找昨天讨论过的结论 | 2-3 分钟 | 0 |
| 把文档内容口述给 AI | 5 分钟 | index 后接近 0 |
平均下来，每天大概能省出 12 分钟。
12 分钟听起来不夸张，但这不是全部价值。
真正有意义的是两件事：
- AI 回答更稳定了
- 你不再抗拒开新会话和切换 Agent
以前你会觉得“好不容易聊热了，别换，不然又要重来”。
现在你更敢在复杂问题上切模型、切工具、切讨论入口，因为上下文已经被交付出去了。
这类工具最容易踩的 4 个坑
这里把我自己踩过的坑也一起写了，避免你上手时浪费时间。
1. 初始化完，不代表上下文已经完整
fcontext init 只是把目录结构建出来。
第一次用的时候，最好明确告诉 AI：
先读一下
.fcontext/_README.md，补充当前项目的关键信息。
后面它才会持续维护这份摘要。
2. _topics/ 不要手改
_topics/ 更像是 AI 的结构化工作笔记。
你可以读，但不建议自己直接改。因为一旦你手工改乱了，AI 可能会基于一份前后不一致的记录继续推理。
更稳的做法是：在对话里补充信息，让 AI 自己更新。
3. 项目里有二进制文档时，先跑 index
如果你的项目里有这些材料：
- PRD PDF
- API Word 文档
- Excel 规格表
AI 默认是吃不到这些内容的。
这时候先跑：
fcontext index docs/
它会把二进制文件转成 Markdown，放进 _cache/。这样后面 AI 才能把这些资料纳入上下文。
4. 团队协作时，记得把 .fcontext/ 一起提交
如果你只在本地用，那这套上下文只对你自己有效。
但如果你希望团队共享，就要把 .fcontext/ 纳入版本控制：
git add .fcontext/
git commit -m "chore: persist project context for AI agents"
这样其他人拉代码之后，他们的 AI 也能直接读到同一套上下文。
它适合什么场景，不适合什么场景
我觉得它最适合 3 类情况：
- 你经常在同一个项目里连续几天和 AI 协作
- 你会在 Copilot、Cursor、Claude Code 之间切换
- 你做的是中等以上复杂度项目，不想每天重复讲架构
如果你只是偶尔让 AI 帮你写几个独立函数，或者一直只在一个短会话里做一次性任务，那它的价值不会这么明显。
所以这类工具本质上不是“万能提效插件”，而更像是：
把 AI 从一次性聊天工具，往长期协作工程师的方向推了一步。
最后：今天就能自己试一遍
还是这 3 行：
pip install fcontext
fcontext init
fcontext enable copilot
然后做一个最简单的实验：
- 今天在项目里和 AI 讨论一个具体问题
- 明天重新开一个新会话
- 看它还能不能接上昨天的结论
如果你还会跨 Agent 切换，再加一步：
fcontext enable claude
然后直接把昨天的问题丢给另一个 Agent，看看它是不是还需要你从头解释。
如果这一步成立，你就会非常直观地感受到一件事：
决定 AI 协作体验上限的，不只是模型能力，还有上下文能不能被持续交付。
GitHub：github.com/lijma/agent-skill-fcontext
如果你想看第二篇，我下一篇会继续写：
怎么让新同事的 AI 第一天就读懂项目，而不是再来一遍口述架构。
