前面三章，我们已经把三件关键的事讲清楚了：
- Claude Code 的问题很多时候不是模型不够强，而是工作环境不稳定
- Agent、Prompt、Harness 不是一回事
- Claude Code 最小内核其实就是
Loop + Tools + Context
如果你现在停下来，其实已经比很多“会用 Claude Code 的人”多理解了一层。
但还不够。
因为你接下来一定会遇到一个新的困惑：
“好，我大概知道 Claude Code 为什么能动起来了。
但真正一套能长期工作的系统，到底还需要哪些层？”
这个问题非常关键。
因为现实里，绝大多数人真正卡住的地方，并不是：
- 不知道 loop 是什么
- 不知道 tool use 是什么
而是：
- 不知道什么时候该写
CLAUDE.md - 不知道 rules、skills、commands、hooks 到底怎么分
- 不知道 memory 和 context 是什么关系
- 不知道 verify 应该算流程、规则还是命令
- 不知道 MCP、subagent、worktree 这些东西到底在系统里属于哪一层
于是很多人的 Claude Code 配置会越长越乱。
像极了项目做久之后的老后台：
- 什么都堆在一起
- 什么都像重点
- 什么都能讲出理由
- 但真的出问题时，根本不知道该改哪一层
所以这一章的目标很简单：
我们要把 Claude Code 工作系统摊平成一张地图。
不是功能列表，不是参数大全，不是“你也可以这样试试”的经验贴。
而是一张足够清楚的系统图，让你知道：
- 每一层在负责什么
- 每一层解决什么问题
- 哪一层和哪一层容易混
- 你现在最缺的可能是哪一层
这张图一旦立住，后面整本书就会非常顺。
读完这一章，你应该能立刻做三件事：
- 说清 Claude Code 工作系统至少由哪几层组成
- 判断你现在最缺的是目标、规则、流程、状态、协作还是验证层
- 不再把所有问题都压回 prompt，而是知道该在哪一层补系统
一、你真正要搭的，不是一个“更会聊天的 Claude Code”，而是一套工作系统
这是我现在特别坚持的一个表述。
因为“更会聊天”这个目标太弱了。
你把 prompt 写得再漂亮，它最多也只是：
- 更懂你这一轮在说什么
- 更容易在当前任务里表现得像样一点
但它仍然不等于：
- 长任务更稳
- 复杂任务更可控
- 并行任务不撞车
- 会话可以恢复
- 验证不容易漏
- 团队可以共享
这些事情，靠聊天技巧是撑不住的。
所以如果我们今天要从零搭一套 Claude Code 工作系统，真正要搭的不是“一个大 prompt”，而是至少下面这些层：
1. 任务目标层
2. 核心运行层
3. 规则约束层
4. 方法与工作流层
5. 自动化治理层
6. 记忆与状态层
7. 协作与并行层
8. 外部能力接入层
9. 验证与演化层
先别急着觉得多。
这 9 层并不是要你一次性全搭完。
它们更像一个成熟系统最后会逐渐长出来的器官。
但如果你脑子里没有这张全景图，后面很容易出现一种常见现象：
明明你已经很努力在补系统了，但总是补错位置。
比如：
- 本来缺的是验证闭环，你却在堆 skill
- 本来缺的是长期规则，你却继续改 prompt
- 本来缺的是会话恢复，你却再加一个更强模型
- 本来缺的是工作区隔离，你却继续多开几个会话硬并行
所以系统图的意义不是“知道得更多”，而是：
知道问题该落在哪一层解决。
二、第一层：目标层，决定这次到底在干什么
很多人会觉得“目标”不算一层，因为这不是配置，不是脚本，也不是机制。
但我现在越来越觉得，目标层反而是最先要独立出来的一层。
因为 Claude Code 最常见的偏航，不是技术问题，而是目标问题。
比如：
- 本来是局部 bugfix，结果变成重构
- 本来是接口补丁，结果开始讨论架构统一
- 本来是“先调研”，结果中途就开始改代码
这说明什么？
说明系统没有明确区分：
- 这次任务是什么
- 这次任务不是什么
- 哪些属于本轮边界
所以一个稳定工作系统，首先需要一个目标层，负责定义：
- 任务目标
- 本轮范围
- 完成标准
- 是否要先计划
- 是否进入实现
这也是为什么后面 /plan 会是一个关键入口。
因为它做的不是“让系统更礼貌”，而是：
在系统正式动手前，先把目标层固定下来。
没有目标层，后面所有层都会漂。
三、第二层：核心运行层，系统到底怎么动
这一层我们上一章已经讲过了，就是：
LoopToolsContext
这层决定的是：
- Claude Code 能不能持续运行
- 能不能动手
- 会不会基于当前状态继续判断
这一层像发动机。
如果用公司做类比：
- Loop 是工作节奏
- Tools 是手和脚
- Context 是工作台上的当前资料和状态
这层的特点是：
- 它足够小
- 但它是一切的基础
- 后面所有高级能力，本质上都在它外面加东西
所以这一层的最佳实践不是“加更多功能”，而是：
尽量保持核心运行层简单、清晰、稳定。
不要把太多高阶逻辑直接焊死在 loop 里。
因为一旦 loop 本身变复杂，后面每一层都会更难调试。
四、第三层：规则约束层，决定哪些线不能越
这是很多人最容易低估的一层。
因为规则看上去不像“能力”，更像“限制”。
但一个系统越强，规则层越重要。
为什么？
因为 Claude Code 最大的风险，不是“不动”，而是：
它会动，而且很愿意动。
一旦没有规则层，你很快就会看到：
- 为了让 build 通过，顺手改配置
- 为了省事，跳过验证
- 为了让 diff 漂亮，改动范围扩大
- 为了看起来完整，补了一堆本轮没要求的东西
所以规则层真正负责的是：
- 定义边界
- 压住冲动
- 建立底线
这层最典型的载体包括：
CLAUDE.md中的长期约束rules/目录- permissions / sandbox 策略
它回答的是一句很关键的话：
无论这次任务是什么，有哪些事就是不能乱来。
如果这层没有立住，后面技能再多、命令再花、模型再强，系统都迟早会翻车。
五、第四层：方法与工作流层，决定“应该按什么套路干”
这一层很容易和规则层混。
但两者其实差别非常大。
规则层解决的是：
什么不能越线？
工作流层解决的是：
这类任务通常该怎么做？
比如：
- 新功能：先 plan，再 TDD，再 verify
- bugfix：先复现，再写失败测试，再最小修复，再回归
- code review：先找 correctness，再看可维护性，再看安全
- 调研：先搜索现有方案，再决定自研还是接入
这些都不是“硬约束”，但它们决定了系统做事有没有套路。
这一层在 Claude Code 里最典型的承载方式就是：
skillscommands
两者再细分一下：
1. Skills
偏“方法论包”。
适合放：
- TDD workflow
- review checklist
- strategic compact
- search-first
- security review
2. Commands
偏“高频入口”。
适合放：
/plan/tdd/verify/review
所以这一层真正要解决的问题是：
怎么把零散经验变成可重复调用的工作流。
没有这一层，Claude Code 每次都得临场发挥。
有了这一层，它开始像一个“知道公司里事情通常怎么做”的同事。
六、第五层：自动化治理层，决定哪些动作不该靠记忆
这层在成熟系统里非常关键，但很多人真正开始搭工作系统之前不会意识到它的重要性。
因为大多数人默认会觉得：
- 这些事我记得住
- 或者模型会记得
后来你就会发现，这和“我以后会记得每次发版前都仔细检查”差不多。
也就是说：
理论上会记得，实际上迟早会漏。
所以自动化治理层的职责是：
- 把高频机械动作自动化
- 把容易漏的事情变成系统行为
- 在正确时间给提醒或拦截
这一层最典型的载体就是：
hooks
它解决的不是“系统会不会更聪明”，而是：
系统会不会更稳定。
典型场景：
- 编辑后自动格式化
- TypeScript 文件后自动 typecheck
- console.log 检查
- 长命令提醒后台化
- compact 前保存状态
- 会话结束时做总结或审计
你会发现，这些事情都不性感。
但也正因为它们不性感，大家最容易拖到最后不做。
而一套系统真正的稳定性，偏偏就是这些不性感的东西堆出来的。
七、第六层：记忆与状态层，决定系统能不能跨时间工作
如果 Claude Code 只工作 20 分钟，这一层问题还没那么明显。
但只要你开始处理：
- 长任务
- 多阶段任务
- 跨天任务
- 多会话协作
你就会很快发现：
系统最痛苦的问题之一，就是状态在不断蒸发。
比如：
- 昨天已经确认过的根因，今天又重新确认
- 上一轮已经讨论过的风险，这一轮又重复铺开
- compact 后，某个关键决策细节没了
- 新会话开始时，系统只知道“继续”，却不知道“从哪继续”
所以这一层需要解决：
- 当前状态怎么落盘
- compact 前怎么保存
- 新会话怎么恢复
- 哪些记忆是长期的，哪些只是本轮的
这一层的典型载体包括：
- session summary
- memory files
- project memory
- auto memory
它真正回答的是：
Claude Code 怎么不至于每次重新投胎。
八、第七层：协作与并行层，决定系统能不能从单兵扩展成团队
到了这里，系统已经不只是“一个会话怎么跑”了。
你会开始遇到更复杂的问题：
- 某些分析能不能分出去？
- 长命令能不能后台执行？
- 多个任务能不能并行做？
- 多个会话同时改代码怎么不撞？
这层其实至少包含三类东西：
1. 认知并行
比如 subagent。
把“思考和探索”分出去，减轻主上下文负担。
2. 执行并行
比如 background task。
把“等待”分出去，让主流程继续推进。
3. 工作区并行
比如 worktree、多会话、多任务隔离。
把“工位”分出去，避免文件级冲突。
这层真正重要的点在于：
并行不是多开几个会话，而是让不同工作流在边界清晰的前提下同时推进。
所以这层一旦缺失，就会出现：
- 多开会话但互相污染
- 多 agent 很忙但没有协作
- 所有 worker 都在干活，但最后根本合不上
九、第八层：外部能力接入层，决定系统怎么接世界
这层最典型的代表就是：
MCP
但不要把它理解成“越多越高级”。
它真正解决的问题是：
Claude Code 如何用标准化方式接外部能力。
例如：
- 浏览器
- 数据库
- 文档
- 搜索
- 平台 API
这层的重要性在于：
- 没有它，Claude Code 很难高质量接真实外部系统
- 但一旦接太多，它又会开始吃 context 和治理成本
所以这一层的关键词不是“接更多”，而是：
接入 + 治理
这一层如果没设计好，最容易出现的不是“能力不足”，而是：
- 配置太重
- MCP 太多
- 上下文被 schema 撑爆
- 不健康 server 反复拖慢流程
十、第九层：验证与演化层，决定这套系统能不能长期可信
最后这一层，我觉得是很多人真正开始做工作系统后才会意识到的重要问题。
一开始大家都关注：
- 怎么写
- 怎么配
- 怎么跑
但系统一旦开始长期使用，真正的问题会变成：
- 这套东西是不是越来越稳？
- 它有没有在漂？
- 哪些规则过时了？
- 哪些 skill 没人用了？
- 哪些 hook 已经成了噪声？
- 这套系统本身有没有被测试？
所以这一层负责的事情是：
- verify 流程
- quality gate
- review
- security review
- harness 自身的校验
- 持续学习与演化
你可以把它理解成：
系统的质检层 + 维护层。
没有这一层，你搭出来的东西就很像一个前期很惊艳、后期越来越混乱的内部工具。
有了这一层，它才开始像一个能长期运营的系统。
十一、现在把它们放回同一张图里
到这里，我们终于可以把整套 Claude Code 工作系统收束成一张图。
目标层
- 这次到底做什么，不做什么
核心运行层
- Loop
- Tools
- Context
规则约束层
- CLAUDE.md
- Rules
- Permissions / Sandbox
方法与工作流层
- Skills
- Commands
- Plan / TDD / Review / Verify
自动化治理层
- Hooks
- 生命周期自动化
记忆与状态层
- Session Summary
- Memory
- Compact 前后状态保存
协作与并行层
- Subagent
- Background Task
- Task System
- Worktree
外部能力接入层
- MCP
验证与演化层
- Verify
- Quality Gate
- Review
- Harness 自测与演化
你现在应该能看出来了：
这本书后面的每一章，其实都只是把这张图里的某一层展开。
也就是说，我们从这一章开始，终于不再是在讨论一个“工具怎么更会用”，而是在讨论：
一套工作系统应该有哪些器官。
十二、本章交付：Claude Code 工作系统全景图
这一章的交付物，就是这张工作系统全景图。
以后你每次感觉系统越来越乱时，都可以用它问自己：
- 我现在出的问题，到底属于哪一层？
- 我是不是在错误层上修问题？
- 我缺的是规则、技能、记忆、并行，还是验证？
如果你能养成这个判断习惯，后面很多“盲目加配置”的冲动都会自然减少。
十三、本章小结
这一章最重要的作用，不是增加知识点，而是把系统摊平。
我们得到的最关键结论是：
Claude Code 工作系统不是一份 prompt，也不是几个命令的合集，而是一套分层结构。
这套分层里：
- loop 只是发动机
- tools 只是手脚
- context 只是工作内存
真正让系统长期稳定工作的，是外面那一层层器官：
- 规则
- 技能
- 命令
- hooks
- 记忆
- 并行机制
- MCP
- 验证闭环
这张图一旦立住，后面的实战就好写了。
因为接下来我们终于可以从“看懂系统”进入“开始动手搭系统”。
下一章，我们正式开始干第一件最实际的事：
从零搭建自己的 Claude Code 工作台。
