上周有个朋友跟我抱怨：他用 Claude Code 写了一整天代码，Agent 突然发了疯，一口气改了 50 个文件，方向全是错的，最后只能整个回滚。我问他：你的 SOUL.md 写了吗？他愣了一下——什么是 SOUL.md？

今天就来拆这条视频，作者「全栈观察员」的「Everything Claude Code 探究」系列第一集。被拆的对象是一个在 GitHub 上拿了 15 万 Star、178 个贡献者、覆盖 12 种编程语言生态的项目：Everything Claude Code。有人叫它「Claude Code 最强配置包」，有人叫它「AI 编程作弊神器」，还有人说它「不过是一堆 Markdown 文件」。

这三种说法都没说到点子上。真正值得记下来的，不是这个仓库里有多少文件，而是它用 10 个月真实生产换来的那套**「怎么让 AI 代理别再翻车」的工程方法论**。这篇就把它掰开揉碎。

一句话定性

Everything Claude Code 不是「一堆配置」，而是一套把只会聊天的 AI 改造成可靠编程搭档的工程治理体系。它的核心是根目录一个只有 5 句话的 SOUL.md（设计原则），外加一个四层架构（Rules / Skills / Agents / Hooks）去把这 5 句话落地。Star 数不是营销刷的，是 10 个月每天踩坑迭代换来的——所以它值钱的不是文件本身，是每条规则背后的那次翻车。

它解决的到底是什么问题：AI 代理的「可靠性」

先看清这个项目为什么会存在。

作者叫 Affaan Mustafa。2025 年 9 月，他和搭档在 Anthropic 办的一个周末黑客松上，用 Claude Code 在 48 小时里从零搭出了 zenith.chat，拿了冠军。但拿完冠军他没停，又用了整整 10 个月，每天用 Claude Code 写真正的产品代码、每天踩坑优化——最后沉淀出 182 个 Skills、近 50 个 Agents、68 个 Commands，一点点开源出来，攒到 15 万 Star。

它解决的，是所有 AI 编程用户都会撞上的同一个核心问题：怎么让 AI 代理真正可靠地帮你干活。

打个比方。大多数人用 Claude Code，就是打开终端跟它聊天：想到什么 prompt 就写什么，想到什么配置就加什么。这就像装修房子——你是随便买家具往里塞，还是先画设计图、分区规划、再动工？大多数人是前者。结果就是：上下文窗口爆了、Agent 开始胡言乱语、token 账单上天。

Everything Claude Code 的做法是后者：先有设计图，再动工。这张「设计图」就是 SOUL.md 加四层架构。

SOUL.md 五条原则：每一条都是真实翻车换来的

项目根目录有个文件叫 SOUL.md，里面只有 5 句话。但每句话背后，都是 10 个月的踩坑血泪。

第一条 · Plan Before Execute（先规划，再动手）。 就是开头那个朋友的遭遇：Agent 一次改了 50 个文件、方向全错、只能回滚——根因是没先规划。这条原则要求：复杂改动必须先拆成明确的阶段，一步步推进，而不是让 Agent「一把梭」。这也是为什么这个项目里有专门的 /plan 流程——先出方案，再写代码。

第二条 · Agent-First（让专业的人做专业的事）。 不是让一个「万能主线 Agent」干所有活，而是把工作路由给专业代理。就像一家公司不能让 CEO 既做销售、又写代码、又管财务。视频里举的反例很扎心：让主 Agent 一把梭，结果它一边写代码、一边改需求文档，自己跟自己打架。正确做法是分工——规划任务有 planner，审查代码有 code-reviewer，查安全漏洞有 security-reviewer，每个代理只做一件事。

第三条 · Test-Driven（先写测试，再信代码）。 AI 给你写了个登录功能，界面漂亮、逻辑自洽，你一测——密码居然是明文存储的。这条原则要求：所有改动必须先过测试，不测试就不让提交。 这不是教条，是无数次翻车换来的铁律。它把「AI 写的代码默认不可信」这个前提，固化进了流程。

第四条 · Immutability（不要原地修改，用新状态替换旧的）。 就像 Git——每次提交都是一个新快照，而不是覆盖旧文件。视频给的反例：两个 Agent 同时改同一个配置文件，A 刚写完、B 就覆盖了，结果 debug 到凌晨 3 点。这就是「原地修改」的代价。用「新状态替换」而非「就地改」，多 Agent 协作才不会互相踩脚。

第五条 · Security-First（安全是底线，不是选项）。 验证输入、保护密钥、默认安全配置。听起来简单，但视频预告了后面专门讲安全的一集里，会出现 CVE 级别的真实安全事故——足以让你后背发凉。这条的意思是：安全不是「有空再加」的功能，而是写第一行代码前就该立的规矩。

把这 5 条连起来看，它其实在回答一个问题：当你不再盯着 AI 的每一步、把活交给它时，靠什么保证它不闯祸？ 答案是：靠先规划、靠分工、靠测试关、靠不可变、靠安全底线——把人类工程团队几十年攒下的纪律，搬给 AI。

四层架构：宪法 / 法律 / 执法者 / 监控

5 条原则是「精神」，那它们怎么落地？项目用了一套四层架构来承载，这是全片信息密度最高的部分。

第一层 · Rules（全局约束）。 放在 rules/ 目录，是整个系统的安全底线。Python 项目有 Python 的规矩，TypeScript 项目有 TypeScript 的规矩——什么必须做、什么绝对不能做，写得清清楚楚。比如「永远不要在输出里包含 API Key」「永远不要提交没测试的代码」。这一层定的是「红线」。

第二层 · Skills（可复用的工作流）。 放在 skills/ 目录，182 个 Skill，每一个都是一个可插拔的领域专家。想做代码审查，有 code-review 这个 skill；想做 TDD 开发，有 TDD 这个 skill。关键是：它们不只是简单的命令，而是包含了上下文、参考资料、执行流程的完整工作包。这是这个项目最核心的创新之一——下一集视频会专门拆。

第三层 · Agents（专业代理）。 放在 agents/ 目录，近 50 个 Agent，每个有自己的专长、允许使用的工具、推荐的模型。注意这里有个精细设计：用 Opus 做架构设计、用 Sonnet 写日常代码、用 Haiku 搜文档——这不是随便分配的，而是根据任务复杂度和成本精心设计的「成本路由」策略。贵模型干重活、便宜模型干杂活，省钱和质量两头都顾到。

第四层 · Hooks（自动化质量保障）。 每次编辑完一个 TypeScript 文件，自动格式化；每次 Claude Code 停下来，自动检查有没有残留的 console.log。你不用时刻盯着 Agent——系统自己就能管好自己。这一层是「无人值守的质检员」。

视频给了一个特别好记的类比，直接抄下来：

Rules 是宪法，Skills 是法律条文，Agents 是执法者，Hooks 是自动监控系统。

四层不是各自为站，而是环环相扣：宪法定大原则，法律给出可执行的细则，执法者去具体落地，监控系统兜底纠偏。它们一起，把一个本来「只会聊天」的 AI，变成了一个有治理结构的工程组织。

而且这套体系不绑死 Claude Code——它同时支持 Cursor、Codex、Gemini CLI 等多个平台。一套配置，多平台通用。

哪些能直接抄进你自己的项目

这条视频拆的是别人的仓库，但里面至少有四个东西，今天就能搬进你自己的工作流：

  1. 给项目立一个 SOUL.md。 哪怕你不用这个仓库，也可以在自己项目根目录写 5 句话的「最高原则」，让每次 AI 协作都先读它。先规划、先测试、别原地改、护好密钥——这四条对任何项目都成立。

  2. 复杂任务先 /plan 再写。 别再让 Agent 一把梭。养成「先要方案、确认了再动工」的习惯，是把回滚率打下来最便宜的一招。

  3. 按成本路由模型。 架构设计这种烧脑的活给最强模型，搜文档、跑格式化这种杂活给便宜模型。这套「贵的干重活、便宜的干杂活」的分配，能在不掉质量的前提下大幅省钱。

  4. 把质检交给 Hooks。 「提交前必须过测试」「输出不许带密钥」「停下来自动清 console.log」——这些规则与其靠你记得，不如固化成自动钩子，让系统自己执行。

一句话：别把 AI 当一个聊天框，把它当一个需要治理的团队。

该清醒的地方

方法论很漂亮，但有几点得自己掂量：

  • 15 万 Star ≠ 适合你。 这套体系是为「每天用 Claude Code 写产品代码」的重度用户打磨的。如果你只是偶尔让 AI 帮写个脚本，全盘搬 182 个 Skill、50 个 Agent 反而是负担。先抄原则（SOUL.md 五条），再按需取架构。

  • 配置本身也是要维护的成本。 四层架构意味着四层都要跟着项目演进去更新。规则写死了不改，时间长了会和实际脱节、甚至挡路。它降低的是「AI 乱来」的风险，换来的是「维护配置」的工作量——这笔账要自己算。

  • 它治的是「流程」，不是「能力」。 这套东西能让 AI 少翻车、协作更有序，但它不会让一个弱模型变强。底层模型不行，再好的治理也只是把错误管理得更整齐。

  • 第一集是「总览」，落地细节在后面。 这集讲的是骨架（5 原则 + 4 层），Skills 怎么写、Agents 怎么配、Hooks 怎么挂这些真正动手的部分，是后面 6 集的内容。看完别以为就会用了——骨架清楚了，肉还得自己长。

适用 vs 短板

场景合不合适
每天用 AI 写产品代码的重度用户✅ 正中下怀，这套治理就是为你设计的
想给团队/项目立 AI 协作规范✅ 直接抄 SOUL.md 五原则 + 四层骨架
多 Agent 并行、容易互相踩脚✅ Immutability + Agent-First 专治这个
偶尔让 AI 写写脚本的轻度用户⚠️ 全盘搬太重，抄原则即可，别上全架构
指望它把弱模型变强❌ 它治流程不治能力，模型不行白搭
不想维护任何配置、只想开箱即用❌ 四层架构本身就是持续维护成本

写在最后

这条视频拆的「Everything Claude Code」，最容易被误读成一个「配置包」——好像 clone 下来就有了超能力。但它真正的价值，是把一句朴素的话讲透了：

当你开始信任 AI、把活交给它时，决定成败的不是模型多聪明，而是你有没有给它一套「不准乱来」的工程纪律。

先规划再动手、专业的人做专业的事、先测试再信代码、别原地改、安全是底线——这五条，把它写进你项目的 SOUL.md，比 clone 任何仓库都管用。模型会越来越强，但「怎么让强模型可靠地干活」这道题，永远得靠工程纪律来答。

握着这套纪律，你才是那个指挥 AI 的人，而不是给它擦屁股的人。