这是「Claude Code Skills 完全指南」系列的第七篇。建议先阅读前六篇再继续。
写在前面
前六篇构建了一条从单 Skill 到多 Skill 编排的完整技术链路。你现在知道怎么设计 Skill、怎么让它触发、怎么组织内容、怎么管理上下文、怎么把多个 Skill 编排成工作流。
但有一个你每天都在经历、却可能从未认真对待的问题：
昨天的 Claude，不记得前天的你。
你是否经历过花费数小时调试一个棘手的数据库迁移，与 Claude Code 来回交流了数十条消息，终于厘清了复杂的 schema 演化过程？然后你关闭终端，休息片刻后重新开启一个新会话——Claude 对你们之前的“并肩作战”一无所知。你编写的 CLAUDE.md 文件可能过于笼统，而 Git 提交记录里也丢失了关键的“为什么”。
每隔几天，当你启动一个新的 Claude Code 会话时，不得不重新解释你的项目：架构、决策、遵循的模式、踩过的坑。Claude Code 在单个会话内非常强大，但在会话之间，它却像“失忆”了一般。
这个问题的表层是“记忆”，但本质是知识管理。前六篇教你如何在 Claude 的“脑子”里“装”东西（Skills）。本篇则要探讨如何让装进去的东西持久化、结构化、可增长——让每一次使用都让系统变得更聪明。
一、Claude Code 的记忆架构：两个系统，三个层级
1.1 两个互补的记忆系统
Claude Code 拥有两个互补的记忆系统。每次会话都从一个全新的上下文窗口开始。而两种机制负责将知识传递到会话之间：CLAUDE.md 文件（由你编写的持久化指令）和 Auto memory（Claude 基于你的纠正和偏好自动记录的笔记）。两者都会在每次对话开始时加载。
需要明确的是，Claude 将它们视为上下文参考，而不是强制性的配置。你的指令越具体、越简洁，Claude 就越能一致地遵循它们。
1.2 三个记忆层级
三个记忆层级共存——项目级、用户级和自动记忆——它们采用自上而下的冲突解决机制。
让我们通过一张完整的层级图来理解：
┌──────────────────────────────────────────────────────────┐
│ 第 1 层：用户级（~/.claude/CLAUDE.md） │
│ · 你所有项目都适用的全局偏好 │
│ · 个人工作风格、语言偏好、通用工具配置 │
│ · 示例：“回复使用中文” / “优先使用 pnpm” │
└──────────────────────────────────────────────────────────┘
↓ 加载到每个项目
┌──────────────────────────────────────────────────────────┐
│ 第 2 层：项目级（./CLAUDE.md + 目录级 CLAUDE.md） │
│ · 项目特定的架构、约定、工作流 │
│ · 提交到 git，团队共享 │
│ · 目录级覆盖：src/auth/CLAUDE.md、src/api/CLAUDE.md │
└──────────────────────────────────────────────────────────┘
↓ 仅在该目录中工作时加载
┌──────────────────────────────────────────────────────────┐
│ 第 3 层：自动记忆（~/.claude/projects/<project>/memory/） │
│ · Claude 自己记的笔记——构建命令、调试洞察、架构决策 │
│ · 纯 Markdown，可阅读、编辑、删除 │
│ · 机器本地化，不提交到 git │
└──────────────────────────────────────────────────────────┘
当指令发生冲突时，项目级的 CLAUDE.md 优先于用户级文件。自动记忆则作为补充，永远不会覆盖前两者。
1.3 自动记忆：Claude 自己的笔记本
自动记忆让 Claude 能够在会话之间积累知识，而无需你手动编写任何内容。Claude 会在工作时为自己保存笔记，例如：构建命令、调试洞察、架构笔记、代码风格偏好和工作流习惯。Claude 并非每个会话都会保存内容，它会根据信息是否在未来的对话中有用来判断其价值。
自动记忆功能于 2026 年 2 月 26 日随 v2.1.59 版本发布。它的作用范围是按项目的——每个 Git 仓库拥有一个独立的记忆目录（如果你在 Git 仓库外工作，则按当前工作目录划分）。
记忆目录包含一个 MEMORY.md 入口文件和可选的主题文件。MEMORY.md 充当记忆目录的索引。Claude 在会话中读写该目录中的文件，并使用 MEMORY.md 来追踪内容的存储位置。
~/.claude/projects/<project>/memory/
├── MEMORY.md # 简洁索引，每次会话都加载
├── debugging.md # 调试模式的详细笔记
├── api-conventions.md # API 设计决策
└── ... # Claude 创建的其他主题文件
自动记忆文件是纯 Markdown 格式，你可以随时进行编辑或删除。在会话中运行 /memory 命令可以浏览和打开这些记忆文件，这对于你的日常 技术文档 维护工作很有帮助。
二、为什么 90% 的人没有用好记忆系统？
好消息是：Claude Code 实际上内置了一个强大的多层记忆系统。但坏消息是，大多数开发者可能只使用了它 10% 的功能。
在 2026 年，记忆系统仍然是 Claude Code 中最未被充分利用的生产力杠杆之一。数据显示，仅有 35% 的用户配置了结构化的 CLAUDE.md，尽管这项投资的回报是即时的。
为什么会这样？因为多数人犯了一个共同的错误。
很多人得出了一个看似合理但错误的结论。他们会想：“如果这（CLAUDE.md）只是被注入的文本，那我应该描述所有东西：每个偏好、每个边界情况、每种可能的交互。”
这引出了知识管理的一个核心悖论：你希望 Claude 知道一切，但你给它的信息越多，它遵循每一条具体指令的概率就越低。
一个高效的 CLAUDE.md 文件遵循着精确的原则。数据表明，200 行以内的文件能实现超过 92% 的规则应用率，而超过 400 行的文件则只有 71%。
一个长达 500 行的 CLAUDE.md 会淹没那些真正关键的指令。Claude Code 会以最大注意力处理前 200 行内容。超过这个数字，内容的权重就会下降。因此，应该将臃肿的内容拆分为模块化的规则文件。
一个实践中的例子：在一个 50，000 行的 TypeScript 项目中，一份 80 行的 CLAUDE.md 文件将需要手动纠正的情况减少了 40%。
三、记忆的分层策略：什么放在哪里？
3.1 决策框架
一个简单的决策原则是：如果你希望 Claude 在 6 个月后还记得某件事，就把它写进 CLAUDE.md。如果这条信息下周就可能改变，那就通过实时提示来提供。
对于那些只在特定情况下才需要的领域知识或工作流，使用 Skills。Claude 可以按需加载它们，而不会让每次对话的开销变得臃肿。
将 CLAUDE.md 留给那些持久的、跨领域的、非敏感的指令——其他所有内容都有更合适的存放位置。
让我们通过一张决策表来统一这些原则：
这条知识的特征是什么？ 放在哪里？
──────────────────────────────────────────────────────────
每次会话都需要 + 6 个月不变 → CLAUDE.md
每次会话都需要 + 可能经常变 → 对话中提供，不写入文件
某些任务才需要 + 是工作流/标准 → Skill（.claude/skills/）
某些任务才需要 + 是参考知识 → Skill 的 references/ 目录
偶尔需要 + 高度动态 → Auto memory（Claude 自行管理）
特定目录才需要 → 目录级 CLAUDE.md
一次性信息 → 直接在对话中说，不持久化
──────────────────────────────────────────────────────────
3.2 一个真实案例：从 189 行到 63 行
一位开发者将自己的 ~/.claude/CLAUDE.md 从臃肿的 189 行精简到了核心的 63 行。他是怎么做的？他将原来塞进 CLAUDE.md 中的七个工具和领域知识文件移到了 ~/.claude/memory/ 目录下。又将三个新文件放入了当前正在工作的项目记忆目录中，用于存储特定的项目知识。此外，还添加了一个指向某个产品的指针条目。
最重要的是，他设置了一个自动初始化指令，确保每个新项目从一开始就遵循这个清晰的结构。
于是，那个曾经每次会话都强制加载 155 行密集参考内容的臃肿文件，现在变成了只有 63 行——它只是指向那些在需要时才被加载的模块文件。这看似是微小的改变，却能带来复合增长的效应。
这就是知识管理的核心操作模式：从“把所有东西都塞进 CLAUDE.md”转变为“分层按需加载”。
四、构建可复利增长的知识系统
4.1 复合效应的原理
将 CLAUDE.md 提交到 Git 仓库，这样你的团队成员也可以贡献和共享。这个文件的价值会随着时间的推移而复合增长。
试想这样一个场景：当你输入 /project ilp-website 启动项目时，Claude 会加载上次会话的项目状态、它学到的关于 WordPress 发布的“怪癖”、上周制定的 SEO 决策，以及昨日每日日志中记录的未完成任务。整个过程大约只需四秒。当它犯了一个错误，这个错误就会变成永久的教训。下次会话时，它不会再犯。当你说“flush”（结束）时，它会捕获你们完成的所有工作、每个决策、每条未结线索，并写入三个不同的位置，然后你才安心关闭终端。当你明天或下周回来时，所有的上下文都在那里。
这就是复合效应：每一次会话不仅完成了工作，还让系统学到了新东西。下一次会话从一个更高的知识基线开始。
4.2 三级知识架构
并非所有记忆都是平等的。有些上下文是每次会话都必需的，有些只是偶尔需要。把所有东西都塞进 CLAUDE.md 会浪费宝贵的上下文窗口。而把所有东西都放进数据库，则意味着 Claude 必须主动搜索最基础的知识。
- 第一层：CLAUDE.md（约150行） —— 一份紧凑的“简报文档”，可以自动生成和更新。它包含了按置信度和访问频率排名的、最重要的项目知识。Claude 在启动时会自动读取，无需任何提示。
但有时第一层是不够的。Claude 可能需要回忆起三周前的一个特定 API 设计决策，或者数据库 Schema 选择背后的理由。这就是第二层的用武之地——按需搜索的深层记忆。
第 1 层：始终加载（< 200 行）
┌─────────────────────────────────────┐
│ CLAUDE.md │
│ · 项目架构和技术栈 │
│ · 核心约定和规范 │
│ · 构建/测试命令 │
│ · 最重要的 3-5 条规则 │
│ · 面包屑指向第 2 层 │
└─────────────────────────────────────┘
↓ 按需加载
第 2 层：引用文件 + Skills
┌─────────────────────────────────────┐
│ .claude/rules/ │
│ .claude/skills/ │
│ Auto memory topic files │
│ · 详细的编码规范 │
│ · 特定模块的知识 │
│ · 工作流模板 │
└─────────────────────────────────────┘
↓ 深度搜索
第 3 层：外部记忆（可选）
┌─────────────────────────────────────┐
│ MCP 记忆服务器 │
│ Daily logs │
│ 决策记录归档 │
│ · 三周前的 API 设计决策 │
│ · 历史调试记录 │
│ · 全文搜索 │
└─────────────────────────────────────┘
4.3 面包屑技巧：连接层级之间的桥梁
面包屑技巧——在 CLAUDE.md 的末尾放置诸如“详情见 MCP memory，标签 [josui， persona]”这样的指引。这些面包屑告诉模型，更丰富的上下文存在于记忆中，并指明了查找位置。即使模型跳过了“会话开始时搜索记忆”的显式指令，它也常常会在对话需要更深层上下文时，遵循这些嵌入的引用。静态文本种下了“记忆存在且可搜索”的种子，模型便会据此行动。
这是一个极其实用的模式：第一层不需要包含所有答案，但它必须包含“答案在哪里找”的线索。
# CLAUDE.md（项目级）
## Architecture
- pnpm monorepo with 3 packages: api, web, shared
- Database: PostgreSQL 16 via Prisma 5.x
## Conventions
- See .claude/rules/code-style.md for detailed conventions
- See .claude/skills/api-conventions/ for REST API standards
## Memory References
- Authentication patterns → auto memory: api-conventions.md
- Debugging history → auto memory: debugging.md
- Past decisions → daily logs in ~/llm-data/daily-log/
五、CLAUDE.md 的工程化管理
5.1 像管理代码一样管理 CLAUDE.md
把 CLAUDE.md 当作代码来对待：当问题出现时审查它，定期修剪它，并通过观察 Claude 的实际行为是否真的发生改变来测试你的修改。
这不是比喻，而是字面意义上的要求。CLAUDE.md 应该：
- 有版本控制：提交到 Git，团队可以通过 PR 进行审查。
- 有测试：观察 Claude 是否遵循了规则，如果没有，就修改规则或精简文件。
- 有重构：定期将过长的内容拆分到
rules/ 或 skills/ 目录中。
保持简洁。对于文件中的每一行，问自己：“删除它会导致 Claude 犯错吗？”如果答案是否定的，那就删掉它。一个臃肿的 CLAUDE.md 文件可能导致 Claude 忽略你真正重要的指令！如果 Claude 在明明有规则的情况下，还是一直做出你不希望的行为，很可能是因为文件太长了，关键规则被淹没了。
5.2 CLAUDE.md 的最佳模板
使用清晰的 Markdown 标题将文件组织成明确的区块。Claude Code 按顺序读取文件，并对文件前面的行赋予更多权重。
基于这个原则，CLAUDE.md 应该按照优先级从高到低来组织：
# [项目名]
## Critical Rules (最重要的放最前面)
- NEVER commit directly to main
- ALWAYS run tests before creating PR
- Use TypeScript strict mode
## Architecture
- pnpm monorepo: api/, web/, shared/
- Database: PostgreSQL 16 via Prisma 5.x
- Auth: JWT + refresh tokens
## Commands
- Build: pnpm build
- Test: pnpm test
- Lint: pnpm lint
## Conventions
- See .claude/rules/ for detailed style guides
- See .claude/skills/ for workflow patterns
## Compression Guidance
When compacting, always preserve:
- The complete list of modified files
- All test commands and their results
- Current task status and next steps
CLAUDE.md 的内容在会话压缩后依然完全存在。执行 /compact 命令后，Claude 会从磁盘重新读取你的 CLAUDE.md 文件并将其重新注入到会话中。如果某个指令在压缩后消失了，说明它只是在本次对话中口头提及，并未写入 CLAUDE.md。想要让它跨会话持久化，就必须将其加入到 CLAUDE.md 中。
5.3 模块化规则系统
当 CLAUDE.md 接近 200 行时，就是时候考虑拆分了。
文件超过 200 行会消耗更多上下文，可能降低指令遵循率。将详细内容移到用 @path 导入引用的独立文件中，或者将指令拆分到 .claude/rules/ 目录下的文件中。
.claude/
├── rules/
│ ├── code-style.md # TypeScript 编码风格（条件加载）
│ ├── testing.md # 测试规范（条件加载）
│ ├── git-workflow.md # Git 工作流（条件加载）
│ └── security.md # 安全规则（条件加载）
├── skills/
│ ├── api-conventions/ # API 规范 Skill
│ └── code-review/ # 代码审查 Skill
└── settings.json # Hooks 配置
当不同层级的规则发生矛盾时，Claude Code 会应用最具体的规则。例如，一个位于 .claude/rules/testing.md 中强制要求使用 Jest 的规则，会覆盖根目录 CLAUDE.md 中提到的 Vitest。这种特异性逻辑能够覆盖 95% 的规则冲突情况。
六、自动记忆的管理策略
6.1 让 Claude 自己学习
自动记忆让 Claude 能够在会话之间积累知识，无需你手动编写。Claude 在工作时会为自己保存笔记：构建命令、调试洞察、架构笔记、代码风格偏好和工作流习惯。Claude 不会每个会话都保存内容，它会根据信息对未来对话是否有用来决定其价值。
当你要求 Claude 记住某件事时，例如“总是用 pnpm，不要用 npm”或“记住 API 测试需要本地 Redis 实例”，Claude 会将其保存到自动记忆中。如果你想把一条指令正式添加到 CLAUDE.md 中，可以直接告诉 Claude“把这个加到 CLAUDE.md”，或者通过 /memory 命令自行编辑。
6.2 定期维护自动记忆
定期检查 MEMORY.md 的内容——删除那些已经过时的观察记录。避免与 CLAUDE.md 内容重复——如果某条规则已经稳定下来，应该将其迁移到 CLAUDE.md 中。MEMORY.md 是 Claude Code 的“自我喂养”记忆——你需要定期检查它，并将稳定的观察“升级”到 CLAUDE.md。
这是一个被大多数人忽略的重要维护任务。自动记忆会随着时间的推移而膨胀——Claude 保存的笔记越来越多，其中一些可能已经过时或与 CLAUDE.md 中的内容重复。
维护流程（建议每两周执行一次）：
1. 运行 /memory 查看所有记忆文件
2. 对每一条记忆问：
□ 这还准确吗？（过时的 → 删除）
□ 这已经在 CLAUDE.md 中了吗？（重复 → 删除）
□ 这够稳定应该“升级”到 CLAUDE.md 吗？（是 → 移动）
□ 这只对我有用还是对团队也有用？（团队 → 项目 CLAUDE.md）
3. 将清理后的变更提交
6.3 知识“毕业”路径
知识在这个系统中有一个自然的生命周期：
对话中的临时提供 → Auto memory 记录 → CLAUDE.md 规则 → Skill 标准化
例如：
第 1 天：你告诉 Claude “用 Zod 做验证”
第 3 天：Claude 自动记忆了这个偏好
第 7 天：你确认这是稳定规则，移到 CLAUDE.md
第 14 天：你基于这个规则构建了一个完整的 validation Skill
每一次“毕业”都让知识变得更结构化、更可复用、更不容易丢失。这正是知识实现复合增长的底层机制，也是高效 学习打卡 与知识沉淀的体现。
七、会话连续性：跨会话不丢失上下文
7.1 Session Memory：后台自动运行
Session Memory 是 Claude Code 用于跨会话记住你做了什么的自动后台系统。与需要你手动编写和维护的 CLAUDE.md 不同，Session Memory 无需你任何输入就能自动运行。它会观察你的对话，提取重要部分，并将结构化的摘要保存到磁盘。
你可能会在会话开始时看到“Recalled X memories”的提示——这表示 Claude 加载了此项目中先前会话的摘要。而“Wrote X memories”则会在会话期间周期性出现——表示 Claude 刚刚保存了当前工作的快照。这两条消息都包含 (ctrl+o to expand)，方便你检查被召回或写入的具体内容。
当你开始一个新会话时，Claude 会将相关的过去会话摘要注入其上下文。这些摘要会带有一个注释：“来自可能与当前任务无关的过去会话。” Claude 将它们作为背景知识使用，而不是活跃指令。这意味着 Claude 不会盲目遵循三周前的决策，而是将过去的会话视为参考材料，为你提供上下文的连续性，同时避免了硬编码指令带来的僵化。
7.2 结构化交接：/flush 模式
当自动记忆不够用时——例如你需要精确控制保留什么内容——你就需要一个手动的“交接”仪式。
- 每日日志：一个文件记录一天的内容。每次执行
/flush 时，会追加一个带时间戳的条目，记录做了什么、做了什么决策、未结线索和学到的教训。
- 项目状态：每个项目的状态部分要小到加载它不会消耗过多上下文窗口，但又详细到能让 Claude 精确地从上次中断的地方继续工作。
你可以构建一个简单的 /flush Skill 来实现这个仪式：
---
name: flush
description: >
Save current session state. Use when user says "flush",
"save state", "wrap up", or "end of day".
disable-model-invocation: true
---
## End-of-Session Flush
1. Summarize what was accomplished this session
2. List all files modified
3. Note any decisions made and their rationale
4. Record open questions or unfinished work
5. Write everything to daily log file:
~/llm-data/daily-log/YYYY-MM-DD.md (append)
6. Update project's MEMORY.md with new learnings
Memory Tool 使 Claude 能够通过记忆文件目录跨对话存储和检索信息。Claude 可以创建、读取、更新和删除跨会话持久化的文件，从而使其能够随时间构建知识，而不必将所有内容都保持在上下文窗口中。这是实现即时上下文检索的关键：智能体（Agent）不是预先加载所有相关信息，而是将学到的东西存入记忆，并按需取回。这对于那些加载所有内容会压垮上下文窗口的长期运行工作流至关重要。
对于跨越多个 Agent 会话的长期项目，记忆文件需要被刻意地引导，而不是随着工作进展临时写入。这种模式将记忆转变为结构化的恢复机制，使每个新会话都能精确地从上一个会话中断的地方继续。
- 初始化会话：在开始任何实质性工作之前，第一个会话负责设置记忆“工件”。这包括一个进度日志（追踪做了什么和下一步是什么）、一个功能清单（定义工作范围），以及对项目所需的任何启动脚本的引用。
- 会话结束更新：在会话结束前，更新进度日志，记录完成了什么和剩余什么。这确保了下一个会话有一个准确的起点。
- 聚焦功能：一次只处理一个功能。只有在端到端验证确认功能可用后，才将其标记为完成——而不仅仅是代码写完。这确保了进度日志的可信度，并防止范围蔓延跨会话复合。
八、完整的知识管理目录结构
综合上述所有内容，以下是我推荐的项目级知识管理结构：
project-root/
│
├── CLAUDE.md # 🧠 第 1 层：核心记忆（< 200 行）
│ ├── Critical Rules # 最重要的规则放最前
│ ├── Architecture # 技术栈和架构
│ ├── Commands # 构建/测试/部署命令
│ ├── Conventions (引用) # 指向 rules/ 和 skills/
│ └── Compression Guidance # 压缩时保留什么
│
├── .claude/
│ ├── rules/ # 📏 模块化规则（条件加载）
│ │ ├── code-style.md
│ │ ├── testing.md
│ │ ├── git-workflow.md
│ │ └── security.md
│ │
│ ├── skills/ # 🛠️ 按需加载的 Skills
│ │ ├── api-conventions/
│ │ ├── code-review/
│ │ ├── flush/ # 会话结束交接
│ │ └── retrospective/ # 复盘提取
│ │
│ ├── agents/ # 🤖 子代理定义
│ │ ├── researcher.md
│ │ └── code-reviewer.md
│ │
│ └── settings.json # ⚙️ Hooks 配置
│
├── src/
│ ├── auth/
│ │ └── CLAUDE.md # 📂 目录级上下文（认证模块）
│ ├── api/
│ │ └── CLAUDE.md # 📂 目录级上下文（API 层）
│ └── frontend/
│ └── CLAUDE.md # 📂 目录级上下文（前端）
│
└── docs/
├── SPEC.md # 📋 规格文档（规划会话的输出）
├── decisions/ # 📝 架构决策记录
│ ├── 001-auth-approach.md
│ └── 002-database-choice.md
└── knowledge/ # 📚 深层技术知识
├── prisma-patterns.md
└── oauth-quirks.md
这个结构体现了三个核心原则：
- 分层按需加载：CLAUDE.md 精简核心 → rules/ 条件加载 → skills/ 按需触发 → references/ 深度引用
- 知识毕业路径：对话 → auto memory → CLAUDE.md → Skill
- 面包屑连接：每一层都包含指向下一层的引用
九、知识的三大生命周期操作
9.1 捕获：从工作中提取知识
在工作时，你自然会提供上下文、解释偏好和分享程序性知识。你需要留意那些你反复提供的信息。识别可复用的模式：在完成任务后，识别出哪些上下文对未来类似任务有用。例如：如果你完成了一次 BigQuery 数据分析，你可能提供了表名、字段定义、过滤规则（如“总是排除测试账户”）和常见查询模式。
你可以让 Claude 帮你创建 Skill：“创建一个 Skill，捕获我们刚才使用的这个 BigQuery 分析模式。包含表 schema、命名约定和关于过滤测试账户的规则。” Claude 模型原生理解 Skill 的格式和结构。你不需要特殊的系统提示来让它帮忙创建 Skills。只需直接要求 Claude 创建一个 Skill，它就会生成具有正确结构和内容的 SKILL.md 文件。
一个 /learn Skill 已经实现了版本控制的知识积累模式：每个“发现”被保存为一个独立的 SKILL.md 文件，其中包含问题、解决方案和验证步骤——这有时被称为“结构化知识库”模式。
9.2 维护：保持知识健康
Skills 是活文档，需要基于反馈进行迭代。
维护工作有三个维度：
- 准确性：知识还正确吗？模型更新后，某些规则是否过时了？
- 相关性：这条知识还有人用吗？如果一个 Skill 两周都没被触发，可能就该考虑卸载了。
- 一致性：不同层级之间的知识有没有矛盾？例如，CLAUDE.md 说用 Jest，而 rules/testing.md 却说用 Vitest——这会造成混乱。
据统计，70% 的 Agent 行为问题都源于三个记忆系统配置错误。例如，在 CLAUDE.md 中写“使用箭头函数”，同时在 .claude/rules/code-style.md 中写“使用函数声明”，这会造成直接的规则冲突。
9.3 退役：知道什么时候该删除
知识库不是只增不减的。过时的知识比没有知识更危险——它是第五篇中讨论的“上下文污染”的一种形式。
退役信号：
- 基础模型已经内化了这个能力（该 Skill 的 A/B 测试结果不再优于基线表现）。
- 技术栈已经改变（例如，你不再使用 Prisma 了，但
prisma-patterns 还躺在 knowledge/ 目录里）。
- 规则自相矛盾（两条规则在不同位置阐述了互相冲突的内容）。
十、常见误区
误区 1：「把所有东西都放进 CLAUDE.md」
一个结构不良、内容臃肿的 CLAUDE.md 比完全没有 CLAUDE.md 更糟糕。
一个过于冗长的 CLAUDE.md 会降低性能。一个 500 行的文件大约消耗 3，800 个 token，占用了上下文窗口约 3% 的预算。这部分预算的占用，直接减少了 Claude Code 可用于分析源代码的空间。
误区 2：「让 Auto Memory 自己管就好」
记忆召回并不可靠，因为它完全取决于 Claude 自身是否决定去搜索。Claude 必须自己意识到需要某条记忆，才会调用搜索等工具来触发检索。如果它没意识到，相关内容就不会出现。而且每个记忆层级都需要自己显式的工具调用，所以如果 Claude 没想到要查，就没有后备方案。
因此，Auto Memory 是一个有用的补充，但绝不能替代你主动进行的知识结构化工作。
误区 3：「记忆系统搭好就不用管了」
对大多数项目来说，本文介绍的方法大约能获得 80% 你想要的连续性。剩下的 20% 是你真正无法重建的东西：例如你们当时正在发展的细微方向、Claude 详细列出的三个替代方案中你说“让我想想”的那些部分。这部分丢失你得学会接受。你无法在一个按会话设计的工具中拥有完美记忆。你能做的是在需要时，能够更快地恢复。
这是一条重要的现实主义原则：追求 80% 的连续性，接受 20% 的损失。 把精力放在让那 80% 尽可能高效上，而不是徒劳地追求完美记忆。
误区 4：「CLAUDE.md 和 Skill 是一回事」
CLAUDE.md、Auto Memory 和 Skill 三者的定位完全不同：
|
CLAUDE.md |
Auto Memory |
Skill |
| 谁写 |
你 |
Claude |
你（或 Claude 帮你） |
| 何时加载 |
每次会话 |
每次会话 |
按需 |
| 什么内容 |
规则和约定 |
观察和偏好 |
工作流和知识 |
| 是否共享 |
提交 git |
本地 |
提交 git |
| 何时更新 |
规则变化时 |
自动 |
工作流变化时 |
十一、你今天就应该做的 3 件事
✅ 行动 1：审计你的 CLAUDE.md
打开你当前项目的 CLAUDE.md 文件，数一下它有多少行。
如果超过 200 行——那么你正以大约 71% 的规则应用率在运行，而不是理想的 92%。
请执行以下操作：
- 对每一行问：“删除它会导致 Claude 犯错吗？”如果不会，就删掉。
- 将详细的编码规范移到
.claude/rules/ 目录下。
- 将领域知识移到
.claude/skills/ 目录的 references/ 子目录中。
- 确保最重要的规则位于文件的最前面。
✅ 行动 2：检查你的 Auto Memory
运行 /memory 命令，查看 Claude 已经为你保存了什么。你可能会对已经存在的内容感到惊讶。
在执行任何操作之前，先检查 Claude Code 已经在 ~/.claude/projects/ 目录中构建了什么——你可能会惊讶于已经存在的记忆文件夹中已经有了不少内容。
然后：
- 删除过时的观察记录。
- 将已经稳定的规则“毕业”到 CLAUDE.md 中。
- 确认没有互相矛盾的信息。
✅ 行动 3：创建你的第一个 /flush Skill
使用本文第七节提供的模板，创建一个 flush Skill。从今天开始，每次结束工作前都运行一次 /flush。
两周后，再回过头来看你的 daily log 文件——你会发现一个自然增长的项目知识库，每一天的内容都比前一天更丰富、更有价值。
本文的知识框架总结
知识管理系统
│
├── Claude Code 的记忆架构
│ ├── CLAUDE.md（你写的持久指令）
│ ├── Auto Memory（Claude 自己的笔记）
│ ├── Session Memory（后台自动摘要）
│ └── 三个层级：用户级 > 项目级 > 自动记忆
│
├── 分层策略：什么放在哪里
│ ├── 第 1 层：CLAUDE.md（< 200 行，始终加载）
│ ├── 第 2 层：rules/ + skills/ + topic files（按需加载）
│ └── 第 3 层：MCP 记忆 / daily logs（深度搜索）
│ └── 面包屑连接各层级
│
├── CLAUDE.md 工程化管理
│ ├── 200 行 → 92% 应用率 / 400 行 → 71%
│ ├── 前面的行获得更多权重
│ ├── 像管理代码一样管理（版本控制 + 测试 + 重构）
│ └── 模块化拆分到 rules/ 目录
│
├── 复合增长机制
│ ├── 知识毕业路径：对话 → auto memory → CLAUDE.md → Skill
│ ├── 每次会话 = 完成工作 + 学到新东西
│ └── 系统从更高基线开始下一次会话
│
├── 三大生命周期操作
│ ├── 捕获：从工作中提取知识（/learn、/flush）
│ ├── 维护：准确性 + 相关性 + 一致性
│ └── 退役：过时知识比没有知识更危险
│
└── 核心原则
├── 追求 80% 连续性，接受 20% 损失
├── 分层按需加载 > 全塞进 CLAUDE.md
├── CLAUDE.md 的价值随时间复合增长
└── 小事情，复合增长
下一篇预告
到目前为止，我们讨论了 Skills、MCP、Hooks、子代理、Agent Teams、CLAUDE.md、Auto Memory——Claude Code 提供了琳琅满目的工具。
那么，下一个问题自然浮现：面对一个具体的任务，我到底该用哪个？
第 8 篇将构建一个完整的决策框架——Workflow vs Agent vs Skill，什么时候该用什么？什么时候原生 Claude Code 就足够了？什么时候复杂的编排反而有害？我们将从成本、可靠性和维护负担三个维度，来量化每种选择的权衡。
本文是「Claude Code Skills 完全指南」系列的第 7 篇，共 10 篇。全系列内容专注于探讨如何系统化地构建和管理 AI 编程助手的能力，这种对于工具链的深度思考和实践，与 云栈社区 所倡导的开发者共建共享、追求技术复利的理念不谋而合。
发表于 3 小时前
|
查看: 2|
回复: 0
