我把所有 Claude Code 配置文件开源了
半年前我在项目根目录放了第一个 CLAUDE.md。
当时只是想：每次跟 AI 解释"这个项目是干嘛的"太烦了。写个文档，它自己读。就几十行，列了技术栈、目录结构、几个编码约定。
后来这东西慢慢长大了。
CLAUDE.md 怎么从简介长成操作手册
一开始是 README 的加强版。后来发现可以让它包含代码风格、测试命令、Git 规范——AI 读完后写的代码明显更贴近项目风格。再后来加了常见任务的标准流程：怎么新建 API 端点，怎么写数据库迁移，怎么处理错误。
CLAUDE.md 从一个"告诉 AI 这是什么"的文档，变成了"告诉 AI 怎么干活"的操作手册。
但它真正值钱的地方，不是 AI 代码质量提升。是有一次用一个新模型，打开项目，它自己读 CLAUDE.md，第一句话就是："我了解了，这是一个 Nobelium 博客，你用特定方式组织 posts，生成 metadata 要跑 build-posts-index。开始前需要跑 npm test 对吗？"
换任何人类接手我的项目，也需要这一轮对齐。CLAUDE.md 把对齐成本压到了几行文字里。
Skills：把模糊需求拆成精确步骤
Skills 是 CLAUDE.md 的自然延伸。
比如"写一篇博客"是个模糊需求。但在我的环境里，它被拆成精确步骤：选 series 目录、写 frontmatter、加图片引用、跑 build-posts-index、跑 npm test、跑 npm run build 验证。
每个 skill 是一个完整的执行手册：输入什么、产出什么、校验什么、失败怎么处理。
Skills 最实用的一点：新人 onboarding。 之前有新同事加入，需要口头讲一遍"怎么改这个项目"。现在给个 skill 链接，AI 带着走。不是取代文档——是让文档活起来。
MCP 是外部感官，组合起来才算完整
CLAUDE.md 给 AI 项目上下文。Skills 给操作流程。MCP（Model Context Protocol）给外部能力。
当前配置文件里接了十几个 MCP 服务：GitHub（读 PR、Issues）、文件系统（读写本地文件）、Tavily（网页搜索）、Playwright（浏览器测试）……
每个 MCP 服务像一个感官。给 AI 装了眼睛（浏览器）、手（文件系统）、耳朵（GitHub notifications）。
但真正有意思的不是单个工具。是组合。
让 AI "查一下本周的 issues，对于有明确解决方案的，切分支、写代码、跑测试、提 PR"。这句话以前要自己做（或根本没时间做），现在 AI 走完全流程——因为在 CLAUDE.md 里有项目上下文，Skills 定义了操作流程，MCP 提供了执行工具。
开源的考量
决定开源这个配置库时，想了很久。
一方面，这是非常个人的东西——编码习惯、项目结构偏好、甚至一些吐槽都在里面。另一方面，很多人想用 Claude Code 但不知道怎么下手。官方文档讲功能，不讲怎么让 AI"理解你的项目"。
最后决定：去掉敏感信息，留下框架和方法论。
开源仓库里有：全局 CLAUDE.md 模板、Skills 目录结构、MCP 配置、几个示例项目级 CLAUDE.md。重点是"怎么做的思路"，不是"我的特定配置"。
收到的反馈比预期的多。有人说"原来 CLAUDE.md 可以这样写"，有人说"Skills 思路让我重新想了一遍自己的工作流"。
AI 编码不只是会写 prompt。真正的壁垒是让 AI 理解你的上下文——项目、约定、偏好。
CLAUDE.md 写了什么
核心信息密度最重要。AI 会反复读这个文件，每多一行 token 都有成本。
按优先级组织：项目概述 4-5 行，技术栈，编码约定，验证流程，常见任务。不写能查到的，不写会变的信息。像给新同事做 onboarding 的 5 分钟版本——给方向和规则，不给百科全书。
验证流程是反复踩坑后加的。"写完代码要跑什么验证"——以前经常忘，写进 CLAUDE.md 以后 AI 每次都会提醒。小细节，省很多回滚。
下一步
这套东西还在快速演化。Skills 的粒度在调——太粗执行不稳定，太细维护成本高。MCP 的选择也在收敛。开源以来收到了一些很棒的 PR 和讨论。