Fable 5上下文系统：记忆文件夹、指令文件与个人工作台搭建指南

循环、Skill 和视觉能力都很有用，但它们还缺一个基础：上下文。

如果每次开始任务，Fable 5 都不知道你是谁、项目现在进行到哪里、过去为什么做出某个决定，它就只能从当前对话猜。猜得越多，长任务越容易跑偏。

最简单的解决方案，不是马上搭建复杂知识库，而是在本地建立一个能被 Agent 读取的上下文文件夹。

一、上下文不等于聊天记录

聊天记录通常是按时间排列的，里面有大量闲聊、临时想法、重复讨论和已经失效的决定。它可以作为参考，但不适合直接当作长期工作说明。

上下文文件应该回答几个稳定问题：

• 这个项目是做什么的？
• 当前最重要的目标是什么？
• 哪些事情已经决定，不能随便推翻？
• 哪些规则和偏好需要长期遵守？
• 当前有哪些未解决问题？
• 相关资料和文件在哪里？

这就是把“过去发生过什么”整理成“现在工作需要知道什么”。

二、先建一个最小文件夹

可以从一个简单的目录开始：

claude-context/
├── claude-memory.md
├── claude-instructions.md
├── business-map.md
├── decisions.md
├── current-priorities.md
├── sops/
│   ├── writing.md
│   └── research.md
└── projects/
    └── current-project.md

文件名可以自定义，关键是职责清楚。

business-map.md

写清楚业务、角色、产品、用户和当前重点。它不是商业计划书，而是一张帮助 Agent 快速进入状态的地图。

decisions.md

记录已经做过的重要决定，以及决定的原因。以后 Agent 提出新方案时，先对照这份记录，避免每次都重新讨论。

current-priorities.md

只放当前阶段的重点、阻塞和下一步。项目变化后及时更新，过期内容不要一直留在首页上下文里。

sops/

放重复工作的标准流程，例如文章写作、资料研究、发布检查和客户反馈整理。

projects/

每个项目建立一页纸说明，记录目标、状态、入口文件、相关资料、风险和最近一次变更。

三、记忆文件应该怎么写

可以建立一个 claude-memory.md，记录关于你和项目的长期信息：

# 长期记忆

## 我的工作方式
- 默认使用 Markdown 输出。
- 做新建议前先参考过去的决策。
- 对不确定的事实明确标注，不要猜测。

## 当前业务
- 目标用户：个人创作者和小团队。
- 当前重点：把内容生产流程整理成可复用系统。

## 已确认偏好
- 先给结论，再给步骤。
- 技术教程要包含前置条件、验证方式和失败排查。
- 不使用没有来源的绝对化结论。

## 待确认事项
- 当前部署平台的生产配额。
- 图片上传的备份策略。

关键是把长期有效的信息和临时信息分开。今天临时决定的一个标题，不应该永久写进记忆；反复出现的写作偏好和已经确认的业务方向，才值得沉淀。

四、指令文件解决“它应该怎样工作”

记忆文件回答“背景是什么”，指令文件回答“工作方式是什么”。可以建立一个 claude-instructions.md：

开始新任务前，先阅读当前项目相关的上下文文件。
如果输入不完整，先指出缺失信息，不要自行编造。
做新建议之前，先参考过去的决策。
涉及重要背景变化时，更新 claude-memory.md，但不要记录密码、私钥、Cookie 或完整令牌。
修改文件前先说明计划；涉及删除、授权、付费、数据库和公网发布时暂停确认。
所有输出默认使用 Markdown。
最终汇报必须包含完成项、未完成项、验证结果和剩余风险。

这份文件不需要写得很长。规则越多，互相冲突的可能性越高。先写最重要的五到十条，实际使用中再补充。

五、让记忆真正更新，而不是只读不写

可以给 Agent 一条明确规则：

每次我提供了关于业务、项目状态或长期偏好的重要新信息时：
1. 先判断它是否值得长期保存；
2. 如果值得，更新对应的上下文文件；
3. 告诉我更新了哪个文件和哪一条内容；
4. 如果只是临时信息，不要写入长期记忆。

这里必须保留人工复核。模型可能把一句临时想法误判成长期规则，也可能把一个敏感信息写进文件。让它更新以后，抽查一次差异：

git diff -- claude-memory.md claude-instructions.md

如果上下文文件不在 Git 仓库里，也应该用其他方式保留版本记录。长期记忆最怕的不是少记一条，而是悄悄被改了却没人知道。

六、上下文要分层，不要把所有资料都塞进去

建议分成三层：

稳定层

长期不怎么变化的业务地图、写作偏好、固定术语和安全规则。

项目层

当前项目的目标、状态、技术结构、相关文件和已知风险。

任务层

这一次要完成的目标、输入、输出、验收标准和截止时间。

每次工作优先加载稳定层和当前项目层，再加入任务层。不要把整个硬盘、全部历史聊天和所有资料一次性塞给 Agent。上下文越杂，它越难判断哪些信息与当前任务相关。

可以在任务文件里明确写：

本次任务只参考：
- current-priorities.md
- projects/blog.md
- sops/writing.md

其他历史资料除非必要，不要主动读取。

这既节省上下文，也减少过期信息干扰。

七、把上下文文件夹升级成个人工作台

如果你准备长期使用，可以继续扩展目录：

my-ai-workspace/
├── context/
│   ├── business-map.md
│   ├── decisions.md
│   └── current-priorities.md
├── skills/
│   ├── writing/
│   ├── research/
│   └── review/
├── tasks/
│   ├── inbox/
│   ├── active/
│   └── done/
├── outputs/
│   ├── drafts/
│   └── final/
└── CLAUDE.md

这里的分层很重要：

• context 放背景；
• skills 放方法；
• tasks 放正在处理的任务；
• outputs 放交付结果；
• CLAUDE.md 放总规则。

这样每次任务结束后，你可以把输入、过程和结果归档下来。下一次遇到类似问题，Fable 5 不需要从零猜测，可以参考过去真正有效的案例。

八、如何接入 Claude Code

不同版本和入口对上下文文件的发现方式可能不同。常见做法包括把工作目录指向上下文文件夹、使用工具提供的添加目录功能，或在项目的 CLAUDE.md 中引用相关文件。

例如可以在项目规则里写：

开始任务前，阅读 ../claude-context/claude-instructions.md。
根据任务需要读取 business-map.md、decisions.md 和 current-priorities.md。
不要默认读取整个目录；先判断哪些文件与当前任务相关。

/add 等命令是否可用、路径如何填写，应以当前 Claude Code 的 /help 和官方文档为准。不要因为别人使用某个命令成功，就假设你的版本也支持完全相同的语法。

九、第一天怎么开始

不要第一天就搭一个复杂知识库。先做三件事：

1. 建立 claude-memory.md，只写最重要的长期背景。
2. 建立 claude-instructions.md，写五到十条工作规则。
3. 让 Agent 处理一个真实的小任务，并观察它是否正确读取和更新文件。

任务可以是整理 20 篇会议记录、检查一个项目结构、写一份文章大纲，或者生成一个部署验收清单。

完成后复盘三个问题：哪些上下文真的被用到了？哪些信息过期或重复？哪些规则需要改写成更明确的句子？

记忆文件的三个卫生问题

上下文系统搭起来以后，最容易被忽略的是维护。文件夹越大，不一定越有用；过期、重复和相互矛盾的信息会让 Agent 更难判断当前情况。

1. 过期信息

“当前正在做什么”变化很快，不应该和长期业务背景放在同一个文件里。每周或每次项目阶段变化后，清理 current-priorities.md，把已经完成的内容移到项目记录或归档目录。

2. 重复信息

同一条规则同时出现在 CLAUDE.md、Skill 和记忆文件中，后面修改一处却忘记其他地方，容易出现冲突。长期规则只保留一个权威位置，其他文件只引用它。

3. 相互矛盾

如果过去的决策已经改变，不要直接删除旧内容。可以写清楚：旧决定是什么、什么时候被什么新决定替代、原因是什么。这样 Agent 既不会继续执行旧规则，也能理解新规则的来源。

建立一份上下文索引

当文件超过十个时，建议增加一个 INDEX.md：

# 上下文索引

## 每次任务都读
- claude-instructions.md：总工作规则
- current-priorities.md：当前目标和阻塞

## 做业务分析时读
- business-map.md
- decisions.md

## 做文章时读
- sops/writing.md
- projects/content.md

## 已归档
- archive/2026-Q1/

索引的作用是告诉 Agent“先读什么、什么时候读什么”，而不是把整个目录一次性加载。每份文件最好在开头写一句用途说明和最近更新时间，减少误读。

把任务和上下文分开

上下文文件解决长期背景，任务文件解决一次工作。可以为每个任务建立一份短文件：

# 任务：整理本周文章选题

目标：从用户反馈中选出 5 个可写选题。
输入：feedback/2026-07-29.md
参考：context/business-map.md、sops/writing.md
输出：outputs/drafts/weekly-topics.md
验收：每个选题包含问题、读者、证据和文章角度。
限制：不编造用户反馈，不删除原始文件。
状态：进行中

任务结束后，把状态改成已完成，记录最终文件和未解决问题，再将任务移入 done/。这样下一次复盘时，能知道当时为什么这样做，而不是只有一份没有上下文的最终文件。

定期记忆整理的提示词

可以每周让 Agent 做一次只读审查：

请检查当前上下文目录，不要直接修改文件。

请找出：
1. 过期的当前目标；
2. 重复出现的规则；
3. 相互矛盾的决定；
4. 没有来源或没有日期的重要事实；
5. 可能包含敏感信息的文件。

输出清单，说明每项建议保留、更新、合并还是归档。
除非我确认，不要删除和覆盖任何内容。

审查通过后，再让它执行最小修改。不要让自动记忆系统无限制地自我改写，否则你很快会失去对上下文内容的控制。

上下文文件也要保护

本地文件夹不代表天然安全。里面可能包含客户信息、商业计划、未发布内容、服务器地址和内部决策。至少要做到：

• 不把密码、私钥、Cookie 和完整令牌写入 Markdown；
• 不把包含敏感信息的目录公开同步；
• 备份前检查同步服务和访问权限；
• 删除敏感文件前确认是否还有合规保留要求；
• 需要共享时只导出任务所需的最小上下文。

如果使用 Git 管理上下文，先检查 .gitignore，避免把密钥文件、临时导出和用户数据提交进去。版本控制的目标是追踪规则变化，不是保存所有原始数据。

一个日常工作节奏

每天开始

读取总规则、当前重点和今天的任务文件。确认项目状态是否发生变化。

执行过程中

只加载与当前任务相关的 Skill 和资料。遇到重要新决定，先记录到任务文件，不急着写进长期记忆。

任务结束

保存最终产物、验证结果和未解决问题。确认是否需要更新 Skill 或决策记录。

每周复盘

清理过期目标、合并重复规则、归档完成任务，检查记忆文件是否仍然准确。

这套节奏的重点是让上下文保持“少而准”。真正有用的记忆，不是文件最多，而是每个文件都能在需要时减少一次解释。

从个人工作台迁移到团队

当团队开始共享这套工作台时，要进一步区分公开规则和个人信息。业务术语、交付格式、代码规范和验收清单可以共享；个人偏好、客户隐私和内部权限不应该直接放入公共目录。

团队共享的 Skill 还需要负责人、版本号、样例和变更记录。否则一个人修改规则，其他人可能继续使用旧版本，最后同一个任务得到两套完全不同的结果。

可以在 Skill 或规则文件开头写：

维护人：内容团队
版本：1.3
适用范围：开发者社区文章
最近验证：2026-07-29
变更方式：修改后必须使用三份样例重新检查

结论

上下文系统的作用，不是让模型“记住一切”，而是让它每次开始工作时都能获得正确、相关、可验证的背景。

记忆文件保存长期信息，指令文件约束工作方式，Skill 保存可复用方法，任务文件描述当前目标。把这几类内容分开，Fable 5 才不容易在长任务里丢失方向。

这套系统最大的好处是可迁移。它存在本地文件里，不锁在某一次聊天或某一个工具的隐形记忆中。换模型、换入口、换项目时，只要重新接入这些文件，过去沉淀的方法仍然可以继续使用。

参考资料

• Claude Code Memory 官方文档，用于核对项目规则文件和上下文管理方式。
• Claude Code 官方文档，用于核对当前 CLI 的目录和工作区行为。