Claude Code 上下文管理实战：正确使用 /context、/compact、CLAUDE.md 与 Obsidian

Claude Code 的很多失败，不是模型不够强，而是会话里塞了太多旧信息。文件内容、搜索结果、长日志、过去的讨论都会占用上下文。

上下文管理就是决定：现在必须让 Claude 知道什么，什么应该写进 CLAUDE.md，什么应该压缩，什么应该留在 Obsidian 或文档里。

本文用实际流程解释 /context、/compact、/clear、/memory 的分工，并给出适合团队和内容生产的操作模板。

把上下文窗口当作工作桌面

上下文窗口可以理解为 Claude Code 当前的工作桌面。会话历史、读取过的文件、工具输出、CLAUDE.md、Auto memory、rules 和 skills 都会放在桌面上。桌面越乱，关键约束越容易被淹没。

进入窗口的内容	变重原因	对策
Conversation	长对话与跑题	按任务切分
Files	整读大文件	先搜索再限定范围
Tool output	长日志和失败重试	总结后保存
Memory	过长的 CLAUDE.md	拆到 rules 或 docs

区分使用 /context、/compact、/clear、/memory

/context 用来看当前窗口被什么占用。/compact 用摘要压缩当前会话并继续。/clear 适合任务真正结束后重新开始。/memory 用来查看 CLAUDE.md、rules 和 Auto memory 是否被加载。

/context all
/compact focus on files changed, failing tests, and next command
/clear
/memory

开始前先决定上下文预算

开始任务前，最好一次性说明目标、范围、排除范围、完成标准、验证命令。不要让 Claude 先读取整个仓库；先用搜索缩小范围，再读关键文件。

# narrow discovery before asking Claude to read files
rg -n "getUserById|User not found|auth middleware" src tests
git diff --stat
npm test -- --runInBand

长任务可复制运行手册

下面的运行手册适合重构、安全修复、长文章和转化率实验。它把会话压小，并让下一轮工作可以从验证结果继续。

## Task brief
- Objective:
- In scope:
- Out of scope:
- Files likely involved:
- Done when:
- Verification commands:

## Handoff receipt
- Changed files:
- Commands run:
- Result:
- Remaining risk:
- Next best action:

compact 后会保留什么

/compact 后，项目根目录 CLAUDE.md 和 Auto memory 会重新注入；子目录 CLAUDE.md 和 path-scoped rules 需要重新读取匹配文件才会回来。只写在聊天里的重要指令最容易丢失。

# CLAUDE.md

## Compact Instructions
- Keep the current business objective and monetization hypothesis.
- Keep changed files, verification commands, deploy state, and blockers.
- Drop raw logs unless a line explains the root cause.
- If article work is in progress, preserve slug, locale list, and quality gaps.

三个场景：开发、内容、转化

1. 大型重构时，把广泛调研交给 subagent 或独立会话，主会话只保留决策摘要和待改文件。
2. 内容生产时，把素材和搜索笔记放 Obsidian，把编辑规则放 CLAUDE.md，把最终 MDX 放仓库。
3. 转化优化时，把指标、假设、修改、验证结果写成短 ticket，而不是拖着一周聊天记录继续。

常见失败与避免方法

1. 失败例1：以为 /compact 会保留全部细节。它保留的是摘要，长期约束应写进 CLAUDE.md 或交接文件。
2. 失败例2：先做大量探索再实现。应该把探索结果压成短文档，再用干净上下文实现。
3. 失败例3：把 Auto memory 当团队文档。它主要是本机记忆，团队规则要提交到仓库。

Obsidian 的分工

把流程放进日常工作

每天开始前先看 /context，确认窗口没有被昨天的日志和搜索结果占满。然后用一句话写清目标，再写清最后要执行的验证命令。这个小动作可以避免会话一路发散。

如果需要大量调研，先把调研结果压缩成短交接文件，再开始实现。实现时只读取交接文件和目标代码，不要把所有候选方案都留在同一个会话里。

内容运营也一样。关键词、读者痛点、内部链接候选可以放在 Obsidian；真正写 MDX 时只传 slug、读者画像、必需链接和质量检查。

如果任务已经结束，就不要让旧上下文继续陪跑。该 /clear 的时候清掉，该写交接文件的时候写文件。把上下文当作预算来管理，Claude Code 的输出会更稳定。

尤其在内容运营中，不要把分析、写作、部署、商业化判断全部放进同一个会话。把它们拆开，结论会更清楚。

这套方法要和CLAUDE.md 最佳实践、Token 优化指南、提示词设计指南一起看。知识库用户还可以读Claude Code 与 Obsidian 集成，团队导入可从培训与咨询页面咨询。

位置	适合的信息
CLAUDE.md	每次都需要的短规则
Obsidian	长研究、假设、选题
MDX / docs	公开正文、规格、交接
Auto memory	本机偏好与反复学习

本文确认过的内容

这次更新检查了官方 context window、commands、memory 文档，把旧的 /cost 中心说明改为 /usage、/context、/compact、/memory 分层使用。 Official references: context window, commands, memory, and common workflows.