前言
上周师妹去面腾讯微信读书的大模型开发岗,三面被问了一道场景题:
👔 如果用 Claude Code 来辅助写一本书,内容很长,容易超过上下文长度,你怎么处理?
师妹想了想,说"用 /compact 压缩上下文呗"。面试官点了点头:"可以是可以,但还有更好的手段。"
然后面试官自己展开讲了大概五分钟。师妹事后跟我复盘,说当时脑子里就只有这一个点,根本没想过写书这个场景本身的特殊性在哪儿。
读完这篇文章,你能搞明白:
- 为什么"/compact"不能说错但不够------应急手段不是主策略
- 正确思路:不是塞进上下文,是按需检索------换个架构思维
- 五步落地架构------项目圣经/分章文件/摘要沉淀/按章开会话/subagent 全局检查
- /compact 在体系里的正确位置------应急补救不是日常依赖
- 长内容管理的工程意识------工具用得好不好差在工程意识
- 面试话术三层模板------60 分答法和 90 分答法的差距在哪
不管你是用 Claude Code 做长项目的开发者,还是需要在面试里讲清上下文管理的候选人,这道题都值得提前想清楚。开拆!
一、/compact 为什么"不能说错"但不够
/compact 是 Claude Code 的内置命令,作用是把当前会话的历史上下文压缩成摘要,释放 token 空间,让对话继续进行。
这个操作确实有用,属于"上下文快撑满了,先压一压"的应急手段。
但问题是------写书不是一次对话能搞定的。一本书十几万字、几十个章节,人物、设定、伏笔、文风都要前后一致。如果策略只有"上下文满了就压缩",那压缩之后 Claude 对前面章节的记忆就变模糊了,写到后面越来越容易出现前后矛盾、人物性格漂移、设定遗忘。
/compact 解决的是"放不下"的问题,但没有解决"怎么用得好"的问题。
二、正确思路：不是塞进上下文，是按需检索
写书场景的核心矛盾:书的总量远超单次上下文,但写每一章时又需要"记住"全书的设定和前文逻辑。
解法不是硬撑,而是换个架构思维------把长内容拆成文件,把"记忆"换成"按需检索"。
这不是什么高深的技术,就是软件工程里最基本的"关注点分离":全书设定放一个文件,每章内容放独立文件,每章写完生成摘要,写下一章时只带"当前需要的最小信息集"。
接下来五步是落地做法。
三、第一步：建立"项目圣经"
在项目根目录建一个 bible.md,把以下内容写进去:
- 全书大纲(章节标题 + 一句话简介)
- 核心人物设定(性格、背景、关系)
- 世界观规则、专有名词表
- 文风要求(人称、语气、禁用词)
这份文档要刻意保持精简,几百到一两千字就行,目标是每次开始写作时都能完整带进上下文,不占太多空间。
同时在项目根目录放一个 CLAUDE.md。这是 Claude Code 的特殊文件------每次启动会话时自动读取,相当于给 Claude 的"永久说明书",不需要每次重新交代规则。
工程判断:bible.md 是"全局常量",CLAUDE.md 是"运行配置"。前者管内容一致性,后者管工具行为规范。两者分工不同,不要混在一个文件里。
四、第二步：每章一个文件 + 摘要沉淀
结构上,每个章节单独存一个 Markdown 文件:
scss
book/
├── CLAUDE.md ← 自动加载的写作规范
├── bible.md ← 项目圣经(大纲+设定)
├── chapters/
│ ├── 01-开篇.md
│ ├── 02-转折.md
│ └── ...
└── summaries/
├── 01.md ← 第一章摘要(200字以内)
├── 02.md
└── ...
关键操作:每写完一章,让 Claude 生成一份 200 字以内的章节摘要,存到 summaries/ 目录。
写下一章时,不把前面所有章节全文丢进上下文,而是只给:
bible.md(全书设定)- 前一章的摘要(不是全文)
- 本章大纲
这样无论书写到第几章,每次带进上下文的内容都是可控的。
五、第三步：按章开新会话，用完就清
很多人习惯在一个会话里一直写,越积越长。但写书场景更好的做法是:写完一章,就开新会话。
用 /clear 清空历史,或者直接开一个新 session。每次只带入"当前章节需要的最小信息集",保持上下文干净。
这不算浪费,而是在主动管质量------上下文拖得越长,后面越容易跑偏:注意力涣散、前后对不上、设定打架。
工程判断:按章开新会话的本质是"控制上下文污染"。一个会话里打磨同一章的多个版本是合理的(需要上下文连续性);但跨章写作必须开新会话(避免前章的修改痕迹干扰当前章的创作)。
六、第四步：全局检查交给子代理
"检查全书人物设定是否前后矛盾""统一术语""检查某个伏笔是否有收尾"------这类需要扫全书的工作,不要放进日常写作对话里。
Claude Code 自带 subagent(子代理)能力,能派一个独立的 agent 去逐章扫描所有文件,分析完只把结论交回来,全书正文不会灌进你的主会话上下文。
也可以写成自定义斜杠命令,一条指令触发一次全书扫描。
工程判断:subagent 的价值不只是"省上下文",更重要的是"职责隔离"。写作 Agent 专注创作,审查 Agent 专注查错,两者不混在一个会话里,各自带上不同视角的上下文。这和软件开发里"写代码的人不 Review 自己的代码"是同一个道理。
七、第五步：/compact 在体系里的位置
回头再看 /compact------在这套架构里它并非没有用武之地,只不过角色从"主力"降成了"救急"。
当你在某一章里来回修改、对话记录越堆越长,又舍不得 /clear 把当前进度清掉,这时拿 /compact 把历史压一压,是说得过去的做法。
但如果项目结构做好了(bible.md + 分章文件 + 摘要沉淀),大多数时候根本不需要等到"快满了"才处理------因为每章本来就是轻装上阵的。
/compact 是创可贴,不是架构。 项目结构才是架构。
八、从架构师视角看长内容管理的几个工程取舍
从架构师视角看几个长内容管理的工程取舍。
取舍一:摘要 vs 全文的粒度------200字够不够。 200 字摘要可能丢细节(某个伏笔的铺垫),但 500 字又占上下文。工程上建议:摘要分两层------200 字的"剧情摘要"(写下一章时用)+ 500 字的"细节摘要"(全局检查时用)。按需取用,不一次性全带。
取舍二:bible.md 的更新频率------实时 vs 定期。 写作过程中可能出现"灵光一现"的新设定,实时更新 bible.md 会打断创作流;定期更新(每写完一章)可能遗漏临时加的设定。工程上建议:写作时在章节文件里标记"新设定 TODO",写完一章后统一把 TODO 项合并进 bible.md。
取舍三:subagent vs 手动检查------自动化到什么程度。 subagent 自动扫全书很方便,但"文学性"检查(人物性格是否自然、文风是否统一)很难自动化。工程上:事实性检查(术语一致性/伏笔收尾)用 subagent,文学性检查靠人读。不要指望 subagent 替代编辑。
取舍四:CLAUDE.md 的内容------写多少规范。 CLAUDE.md 太短不够指导,太长又占上下文。工程上建议:CLAUDE.md 只写"硬约束"(禁用词/人称/格式要求),不写"软建议"(文风偏好/叙事节奏)。硬约束靠规则执行,软建议靠示例引导(Few-shot)。
取舍五:多作者协作时的 bible.md 冲突。 如果多人用 Claude Code 协作写书,bible.md 的版本冲突是必然的。工程上:bible.md 用 Git 管理,每次修改走 PR Review;章节文件按作者分目录,减少交叉冲突。
取舍六:从"写书"到"写代码"的迁移。 这套五步架构不只适用于写书,任何"长周期大体量内容"场景都适用------写大型技术文档、维护多模块代码库、做持续迭代的 Prompt 工程。核心思路一样:把"对话记忆"换成"文件检索",把"一次性塞进上下文"换成"按需加载"。
九、面试话术：考官想听的是什么
回到面试场景。这道题考的不是"你知不知道 /compact",而是"你有没有把写书当成工程问题来思考"。
常见错误回答一:"用 /compact 压缩"。 这是师妹的回答------不能说错但不够。面试官想听的是"更好的手段"。
常见错误回答二:"把内容分段写"。 方向对但太笼统。面试官会追问"怎么分段""分段后怎么保持一致性"。
高分答题模板:三层结构。
第一层(抛本质):"上下文超限只是表象,背后是'如何管理长周期大体量内容'的架构问题。/compact 解决'放不下'但不解决'用得好'。"
第二层(讲五步架构):"我会搭一套五步架构:第一步建项目圣经(bible.md)管全书设定;第二步每章一个文件+200字摘要;第三步按章开新会话控制上下文污染;第四步全局检查用 subagent 扫全书只回结论;第五步 /compact 作为应急补救不作为主策略。"
第三层(升华):"核心思路是把'对话记忆'换成'文件检索',把'一次性塞进上下文'换成'按需加载'。这不只适用于写书,任何长周期大体量内容场景都适用。"
60 分 vs 90 分对比:
| 追问点 | 60 分回答 | 90 分回答 |
|---|---|---|
| "压缩后前后矛盾怎么办?" | "再检查一遍" | "不靠压缩靠架构:bible.md 管设定+每章摘要,写新章只带 bible+前章摘要+本章大纲,不靠对话记忆" |
| "bible.md 写多少?" | "越多越好" | "几百到一两千字,每次完整带进上下文;只写硬约束(设定/大纲/文风),不写软建议" |
| "全书检查怎么做?" | "通读一遍" | "subagent 扫所有章节文件只回结论,不堆进主线上下文;事实性检查自动化,文学性检查靠人" |
| "/compact 什么时候用?" | "满了就用" | "单章反复打磨不想 /clear 时用;项目结构做好了大多数时候不需要;/compact 是创可贴不是架构" |
加分项提示: 如果你能主动提到"这套架构不只适用于写书,写大型技术文档/维护多模块代码库/做持续迭代的 Prompt 工程都能套用",面试官会认为你有架构迁移能力。
总结
回到开头那道面试题。"Claude Code 写书超过上下文长度怎么办"------这道题考的是工程意识,不是工具熟练度。
- /compact 是应急不是架构:解决"放不下"但不解决"用得好"。
- 正确思路:文件检索替代对话记忆:把长内容拆成文件,按需加载。
- 五步架构:项目圣经(bible.md)→ 分章文件+摘要 → 按章开会话 → subagent 全局检查 → /compact 应急补救。
- bible.md 管全局常量,CLAUDE.md 管运行配置:两者分工不同。
- subagent 的价值是职责隔离:写作 Agent 专注创作,审查 Agent 专注查错。
- 面试话术三层结构:抛本质(架构问题)→ 讲五步 → 升华(不只适用于写书)。
大模型工具用得好不好,很多时候差在有没有工程意识,而不是会不会用命令。 答 /compact 说明你知道工具;能说出"项目圣经 + 分章文件 + 摘要沉淀 + 按需检索",才说明你真的想过怎么用 Claude Code 做事。
你用 Claude Code 做长项目时是怎么管理上下文的?踩过"上下文满了就压缩"的坑吗?欢迎评论区交流。