从 CC-OS 到 CC-GEB：我如何用一张截图重构了整个 AI 编程配置体系

一个 Claude Code 配置体系的进化史——从 120 行全局宪法到 20 行极简配置，从全有或全无到三档渐进，从重型方法论到一个 Skill 命令。

故事的起点：一张方法论截图

事情是这样开始的。

我在某个地方看到一套"AI Coding 方法论"的截图——一张 workflow 架构图，描述了 AI 接手项目时应该先做什么、后做什么。它的核心思想很简单：

AI 接手一个新项目时，不应该先写业务代码，而是先建立治理结构、信息结构和决策路径。

这个方法论把项目工作分成六层：

01-rule       元规则：workflow 怎么运行
02-session    记忆沉淀：协作历史、惊讶度、决策变化点
03-design     版本设计：目标、路线图、架构
04-testing    验证闭环：测试用例、失败证据
05-execution  约束执行：代码实现、落地计划
06-knowledge  知识库：稳定结论、技术背景

最有意思的是它的闭环设计：execution 不是终点。代码写完后，执行结果要回写到 session（记录过程）、testing（回写证据）、knowledge（沉淀结论）、rule（更新治理规则）。

我看完第一反应是：这不就是我一直在用的 CC-OS 缺失的那一半吗？

CC-OS 的前世：一个越写越重的全局宪法

先说背景。CC-OS（Claude Code 工程操作系统）是我之前搭建的 Claude Code 配置体系。它的核心是一套"分形文档协议"——受 GEB（Gödel, Escher, Bach）启发的三层文档同步机制：

L1  项目 CLAUDE.md    ← 项目宪法
L2  模块 CLAUDE.md    ← 局部地图
L3  文件头部注释       ← 代码契约

每次改代码，必须同步更新对应层级的文档。代码是机器相，文档是语义相，两者必须同构。我甚至写了一个叫 GEB Loop 的强制回环：

代码变更 → L3 头部一致？ → L2 清单更新？ → L1 目录更新？

理念很优雅。问题是，我把太多东西塞进了全局配置。

当时的 ~/.claude/CLAUDE.md 有 120 行，包含：系统宪法、全局法则、目录地图、config 清单、workflow 步骤、边界声明、公理箴言。每次我启动 Claude Code——哪怕只是问一句"这个 API 怎么用"——这 120 行全部加载到 context 里。

更夸张的是配套文件。DOC_PROTOCOL.md 有 177 行，其中 60% 是布道词（"我是分形的守护者""代码在审判我"）。PHILOSOPHY.md 有 92 行。6 个 rules 文件共 270 行。5 个 templates 共 371 行。11 个 scripts 共 1282 行。

总计：全局每个 session 加载约 510 行方法论。

而这 510 行里，有多少是 Claude 本来就会做的？

第一刀：砍掉 Claude 已经会做的

我决定逐行审判：这条规则是否真的改变了 Claude 的行为？

结果触目惊心。

rules/security.md 全部 29 行——"No hardcoded secrets""Parameterized queries""CSRF protection"——Claude 的系统 prompt 已经包含 OWASP Top 10 防护，这些不是规则，是常识。删。

rules/coding-style.md 的 Error Handling 和 Input Validation——Claude 默认就会做。Code Quality Checklist 里"Functions are small""No deep nesting"——这是 Claude 的基础编码能力。只保留两条 Claude 不会默认做的：Immutability（强制不可变） 和 文件 800 行上限。48 行 → 16 行。

templates/claude.md 里的 Working Rules——"Clarification First""Ask-User-Questions""Plan Before Execute"——这三条是 Claude 的默认行为。还有 60 行的 Agent Team Recipe 塞在项目模板里。项目 CLAUDE.md 应该是项目事实声明，不是流程手册。152 行 → 39 行。

DOC_PROTOCOL.md 删掉布道词，只留操作规程。177 行 → 80 行。

第一刀砍完：1030 行 → 401 行，降 61%。

但这还不够。

第二刀：发现"愿景伪装成配置"

审查过程中我发现了一个更隐蔽的问题：有些配置看起来像功能，但实际上不会被执行。

MCP Profiles。 CC-OS 定义了 4 个 MCP Profile（minimal/web-research/e2e/security），用户可以在 CLAUDE.md 里写 <mcp-profile>minimal</mcp-profile>。问题是：Claude Code 根本不支持这个功能。写了也不会自动启用/禁用任何 MCP。这整个文件是一个愿景文档伪装成配置。

Auto-Context Loading。 模板里写着"System will automatically check these files based on <config>"——但 Claude Code 不会自动加载 STACK.md/SKILLS.md。这需要手动 include 或写 hook。标注"auto"是误导。

<abstract>/<overview> Auto-generated。 模板里有"Updated by CC-Kit summary-worker"占位符，但 summary-worker 从来不会自动填充这些字段。

删掉这些幽灵功能后，才开始真正的重构。

第三刀：与 AI Coding 方法论的融合

回到开头那张截图。分析完两套体系，我发现它们处于正交的两个维度：

	CC-OS	AI Coding 方法论
管什么	空间结构（文档怎么组织同步）	时间流程（工作怎么推进路由）
法则	Map = Terrain	回写闭环
触发	每次代码变更后	每次阶段切换时

CC-OS 管的是"文档该长什么样"，方法论管的是"AI 该先做什么、后做什么"。

更关键的是，CC-OS 有三个空白区恰好被方法论补上：

Session 记录——CC-OS 没有项目级的协作历史。方法论的 02-session 记录每轮对话的时间线和惊讶度。
Testing 作为一等层——CC-OS 的测试只是 START.md 里的一个场景。方法论把验证闭环提升为独立的治理层。
Knowledge 沉淀——CC-OS 的文档是"代码的镜像"，但没有独立的"稳定知识"存储。

融合方案：workflow-bootstrap 成为新模板，六层目录作为可选的项目结构，两套回环并行——代码变更触发 GEB Loop，阶段切换触发 workflow 回写。

第四刀：根本问题——CC-OS 不分场景

融合之后我退后一步看全局，发现了一个更根本的问题。

我问自己：用户和 Claude Code 交互的真实场景分布是什么？

闲聊/问答            30%    → 完全不需要方法论
小脚本（<5 文件）    25%    → 不需要分形文档
修 bug               20%    → 部分有用
中型项目             15%    → 有用
大型产品             10%    → 非常有用

CC-OS 的 rules/ 是全局的。~/.claude/rules/ 下的每个文件在每个 session 都会加载——包括你问"React Server Components 是什么"的时候。

90% 的场景在承担 100% 的 context 开销。

这才是真正的问题。不是内容不好，是不分场景。全局配置是 0 或 100，缺少 30 和 60。

解法：三档渐进 + 一个 Skill

重构的核心设计：

全局层（每个 session 都加载，必须极简）
  └── ~20 行：语言偏好 + 调试纪律
  └── ~47 行 rules：coding-style + git + performance

项目层（/cc-geb init 按需生成，三档可选）
  ├── 轻量：只有项目描述 → 开源项目、小脚本
  ├── 标准：+ GEB 文档同步 → 中型项目
  └── 完整：+ workflow 六层 + 回写闭环 → 大型产品

DOC_PROTOCOL 和 PHILOSOPHY 从全局层下沉到项目模板。你选"标准"才会有 GEB Loop，选"轻量"就是个干净的项目描述。

整个体系的用户入口收敛为一个 Skill：

/cc-geb              自动检测项目状态，推荐动作
/cc-geb init         初始化（轻量/标准/完整）
/cc-geb check        文档巡检
/cc-geb upgrade      升级配置级别

为什么是 Skill 而不是终端脚本？因为 Skill 运行在 Claude Code 里——Claude 能读懂 package.json、扫描目录结构、用 AI 智能填充项目描述。一个终端脚本只能做模板替换。

最难的设计决策：已有项目怎么办

大部分用户不是从零开始。他们拿到一个开源项目，或者接手一个历史仓库。而且现在很多项目已经有自己的 CLAUDE.md。

核心原则：只做加法，不做改法。

cd 到一个项目 → 检测 CLAUDE.md

(A) 没有 CLAUDE.md → 建议 /cc-geb init
(B) 有 CLAUDE.md，非 CC-GEB 的 → 不动它，只提供补充件
(C) 有 CC-GEB 的 CLAUDE.md → 完整行为

场景 B 是关键。如果 CC-GEB 试图改写别人的 CLAUDE.md，用户会直接卸载。所以 /cc-geb init 检测到已有配置时，只会问"要不要补充一个 STACK.md？"或"要不要生成 workflow/ 目录？"——绝不碰已有文件。

GEB Loop 的适用范围也做了限定：只对 Claude 本次修改的文件生效，不追溯改造已有代码。 这样你 clone 一个 5000 文件的开源项目，Claude 不会试图给每个文件加 L3 header——只有 Claude 自己新建或修改的文件才需要遵守文档同步协议。

命名的进化

最后说说名字。

CC-OS（Claude Code 工程操作系统）→ CC-Kit（Claude Code 配置工具包）→ CC-GEB。

CC-OS 太重了，"操作系统"给人感觉要接管一切。CC-Kit 精确但无聊。CC-GEB 保留了核心理念的致敬——GEB 是 Gödel, Escher, Bach 的缩写，分形文档协议的灵感来源。

Skill 命名也经历了迭代。最初是两个独立的 Skill（/cc-init + /doc-gardening），后来合并为一个 /cc-geb，三个子命令。用户只需要记住一个词。

无参数的 /cc-geb 会自动检测项目状态并推荐动作——新用户不需要知道该 init 还是 check，Skill 自己判断。

最终形态：数字说话

                v1 CC-OS      v3 CC-GEB      变化
全局加载量       ~510 行       ~67 行        -87%
配置文件数       15 个         8 个核心      -47%
脚本数量         11 个         2 个          -82%
Skills           1 个          1 个          不变（但功能更多）
模板             5 个          5 个          不变（但用途更明确）

用户需要记住的命令：/cc-geb

三个场景的用户体验：

场景	全局加载	用户动作	感受
闲聊	67 行（语言偏好 + 编码风格）	无	无感知
已有项目	67 行 + 项目自有 CLAUDE.md	可选 /cc-geb	不入侵
新大型项目	67 行	/cc-geb init → 完整	全套方法论

复盘：三个教训

1. 好的配置体系是"你感觉不到它在"的体系。

CC-OS 最大的问题不是缺什么，而是太"在场"。Claude 在调试一个简单 bug 时主动提起分形文档和 GEB Loop，这很违和。全局配置应该像空气——需要的时候才注意到它。

2. 永远不要把 Claude 已经会做的事再声明一遍。

每多一行冗余规则，就多占一份 context，而且产生"规则之间谁优先"的歧义。好的 CLAUDE.md 应该只写覆写默认行为的条目。如果你发现自己在写"handle errors explicitly"——停下来，这是 Claude 的默认行为。

3. 操作手册应该像 RFC，不是经文。

"我是分形的守护者""代码在审判我"在第一次读到时很有感染力，但作为每个 session 都加载的 context，它只是噪音。留下操作规程，删掉布道词。感染力留给 README 和博客文章。

尾声

从一张截图开始，到完整重构结束。CC-GEB 现在是一个你可以 git clone → ./install.sh → 进任何项目 /cc-geb 就能用的东西。

它不再试图做一个"操作系统"。它只是一个配置工具包，核心承诺很简单：

闲聊不碍事，小项目轻量，大项目完整。

仓库地址：github.com/felix5127/CC-GEB

架构即认知，文档即记忆。但好的记忆系统不是把所有事都记住——是知道什么时候该记住，什么时候该忘掉。