我把养了半年的 Claude Code 配置开源了
刚刚把整套 ~/.claude 推到了一个公开的 GitHub 仓库。
凌晨三点，sync 脚本第一次跑的时候直接 audit failed 了。
我盯着那行红字看了好一会儿。
被抓出来的不是什么 OpenAI key、不是什么 GitHub token。是 Python __pycache__ 里某个 .pyc 文件，编译过的字节码里把 /Users/xingfanxia/ 这条路径硬编进去了。脚本一波 grep 把它薅出来，拒绝继续 push。
我当时就乐了。
这种感觉怎么形容呢，像养的狗第一次自己学会拒绝陌生人摸它脑袋。这套审计逻辑是我自己写的，但它在实际跑的时候挡住我犯傻的样子，让我有种很奇妙的踏实感。
那个仓库现在躺在 github.com/xingfanxia/ax-claude-config-public，里面 325 个文件，有 50+ 个我自己写的 skill、50+ 个 subagent 定义、40+ 个 slash command、十几个自动化 hook、一套 engineering rules、一份全局 CLAUDE.md。
这玩意是我用 Claude Code 用了大概 6 个月的全部产出。今天打算认真聊聊为什么把它放出来，里面到底是啥，还有那套我自己摸索出来的工作流哲学。
先说什么是 ~/.claude。
如果你用过 Claude Code（Anthropic 那个 CLI 终端工具），你应该知道它的配置目录就叫这个。一开始它就是个空文件夹，你装个插件、写个 skill、改个 settings.json，慢慢往里塞东西。
很多人用了一辈子可能就是改个 settings.json 完事，连 skill 是啥都不知道。
我属于另一种情况。
6 个月前我也是从空目录开始的。然后一个 skill 一个 skill 地往里加。
卡兹克风格写公众号那个 skill，目标是把 AI 写出来的稿子从「AI 味」拉回到「活人感」，跑四层自检（硬性规则、风格匹配、内容质量、活人感终审）。huashu-design 那个 skill 是用 HTML 做高保真原型加幻灯片加动画，内部封装了 5 流派 20 种设计哲学（Pentagram 的信息建筑、Field.io 的运动诗学、原研哉的东方极简等等），还附一份反 AI slop 清单专治紫粉渐变。banxian-skill 是三合一东方占卜，让 Claude 智能选起卦法、用 Python 引擎出真实卦象、按 panpanmao 半仙的知识库做赛博半仙化解读。
每个 skill 都是某一天某个具体需求长出来的。
不是规划出来的，是长出来的。
为什么要开源？
坦率的讲，不是为了流量。我没指望这个仓库帮我涨粉。
真实的理由有三个。
第一个是我朋友和同事看到我用 Claude 干一些奇怪的事情会问「那是啥」。比如我跟人开会的时候，电脑上跑了一个 banxian-skill 的会话，旁边人瞥了一眼问你这是在算卦吗？我说对啊。他说这怎么搞的？我说就一个 skill。然后我就得花 20 分钟解释。
到第三个人来问的时候我就想，干脆放个仓库丢链接给他们好了。
第二个理由更内向一点。我自己也想知道哪些 skill 我是真的在用，哪些纯粹是写完之后就忘了的。把它们集中放在一个仓库里，我自己也得过一遍 INDEX.md，看看哪些已经是僵尸 skill 该清理了。这个过程本身就是一次复盘。
第三个理由是我想看看别人会怎么看。这套配置长得肯定不是最优解，肯定有一堆我没意识到的傻逼之处。开源出来等着被骂，是我让它进化的一种方式。
里面有啥？
我尽量不流水账，挑几个有代表性的聊。
skills/ 这个目录大概可以分四类。
第一类是写作类。khazix-writer 是卡兹克风格公众号长文，wandian-writer 是晚点 LatePost 风格的行业深度长文，wechat-article-writer 是企业官号通用文案，narrative-research 是从零搞懂一个东西用的横纵分析法研究 skill。每一个都是为了解决一种具体的写作痛点单独捏出来的。
第二类是设计类。huashu-design 是用 HTML 做高保真原型加幻灯片加动画加设计变体探索，frontend-design 是真实代码库里的产品级 UI，design-md 是从 66 个品牌的设计系统里挑一个直接用，design-consultation 是从零搭建一套设计系统。这一类我用得最少但每次用都救命。
第三类是工程类。big-task 是工程任务路由器，按风险而不是按文件数判断走多重的流程。audit-fix-loop 是审计修复循环，codebase-sweep 是全仓库审计，plan-design-review 是计划完整性 review，pr-fix-loop 是自动响应 PR review 评论直到全绿。这一类是我每天都在用的。
第四类是奇怪的。banxian-skill 占卜半仙、pet-forge 生成桌面宠物动画、jewelry-marketing 珠宝商家营销素材生成器、photoshoot 网红照生成、notion-infographic 信息图组图生成。这些都是我或者朋友的具体需求出发硬攒的。
奇怪 skill 才是这套配置的灵魂。工程类的东西网上随便找都有，但「我朋友卖珠宝想要一套小红书素材」这种需求催生出来的东西，是只有我会写的。
光有 skill 不够，还得有 subagent 和 slash command。
skill 是「文档」，它告诉 Claude 怎么做某件事。subagent 是「干活的」，它接收一个具体任务用一段隔离的 context 跑掉。slash command 是「触发器」，你打 /big-task 它就会自动调起整套工作流。
举个例子。
我让 Claude 「实现一个新的 API 端点」，它会自动 trigger big-task skill，判断这是 tier 3 或 tier 4 任务，走 GSD 的 discuss → plan → execute 三个 phase。plan 完成后 spawn 一个 gsd-plan-checker subagent 做 goal-backward 验证。execute 阶段如果有并行的子任务，spawn 多个 gsd-executor subagent。完成后 spawn 一个 code-reviewer subagent 做代码审查。如果是涉及用户输入或者 secret 的代码，再 spawn 一个 security-reviewer subagent。全部 OK 之后 trigger neat-freak skill 把文档、记忆、CLAUDE.md 同步一遍。然后 spawn 一个 doc-updater subagent 更新 codemap。
整套流程我一句话不说，它自己跑。
这个事情往回退五年看，我会觉得是科幻。
接下来聊那套工作流哲学，这是这篇文章想真正传达的东西。
我自己摸出来六条核心原则，缩写叫 SIMPLED。
S（Surgical）外科手术式，别动任务之外的逻辑。
I（Investigate first）先调研，读源代码再回答，先讲根因再讲修复。
M（Maintainability）可维护，文件小、结构清晰、模块化。
P（Purpose-driven）目的驱动，质疑假设，从第一性原理出发，先写测试。
L（Lean）精简，三行相似的代码，比一个早产的抽象更好。
E（Extreme ownership）极致负责，pre-existing 的 lint 错误和 flaky test 现在是你的问题。别让代码库比你接手时更糟。
D（Delegate for parallelism, not context protection）为并行而委派，不是为了保护 context。1M context 装得下噪音。spawn subagent 是为了真正的并行或模型专精（haiku 做 lookup），不是为了「保护」context。
这六条不是凭空想的，是我每次踩坑之后回头补的。
比如那个 D。早期我特别爱 spawn subagent，理由是「主 context 太满了我想保护它」。结果发现 subagent 一去不复返，主 context 拿到的报告又是一个二手的、过滤过的版本，反而失真。后来我搞明白了，主 context 现在 1M tokens 装得下整个会话的噪音。spawn subagent 应该有更好的理由，要么真的有几个独立任务可以并行（多文件改动），要么需要换一个更便宜的模型做特定任务（haiku 做 lookup）。
「保护 context」不是理由。
big-task 路由是另一个很有意思的东西。
最早我会问 Claude「这个任务大概什么 scope」，它给的答案永远是看文件数，1-2 个文件是小任务，10+ 个文件是大任务。
后来我发现这个判断标准不对。
判断 scope 应该看风险，不是看体积。
一个 schema migration 即使只改一个文件也是 tier 4（高风险，需要走完整 GSD 流程）。一个 typo 修复即使涉及 50 个文件也是 tier 1（直接改）。一个 concurrency 改动即使只动一个函数也是 tier 4（涉及 atomicity，必须有 design phase）。
big-task skill 现在用一套 risk-based 的判断逻辑。Schema 或 migration 走 tier 3-4。Concurrency 或 atomicity 走 tier 4。Auth、secret、payment 相关的走 tier 4。新增 endpoint 或 component 走 tier 3。修复 bug 是 tier 1-2。改 typo 是 tier 1。
这个表格是我把过去半年里所有翻车的事情捋了一遍之后总结出来的。
每一行背后都有一个具体的事故。
GSD 是 Get Shit Done 的缩写，是另一个独立的 plugin。我用了大半年，把它的 phase 流程适配到我自己的工作流里。
核心是 discuss → plan → execute 三个 phase。
discuss phase 是把灰色地带摊开。比如「这个 endpoint 是用 GET 还是 POST」、「数据存 cache 还是 DB」这种决定，不在 plan 里写而在 discuss 里搞清楚。Plan 写出来之后所有决定都已经定了，不应该有「TBD」。
plan phase 是写出可以执行的步骤。每一步都得有具体的文件路径、具体的代码片段、具体的命令。不能写「实现 X」，得写「在 file.py:42 行加这段代码」。
execute phase 是真的去做。每一步做完 commit。失败了不堆 fix，而是回到 discuss 重新搞清楚 hypothesis。
这个流程的关键不是流程本身，是它强迫我把决定提前。我以前的失败模式是「先动手再说」，写到一半发现一个根本性的问题，前面 80% 的工作直接作废。GSD 把那个根本性问题逼到了 discuss phase，让我在动键盘之前先把它解决掉。
neat-freak 是我加的 hook，它在每次会话结束的时候自动 trigger。
具体做的事情是把这次会话里的代码改动跟 CLAUDE.md、README.md、docs/ 这些文档对一遍。如果有 drift（比如代码里加了一个新的环境变量但 README 没更），neat-freak skill 会把它修复掉。memory 也一样会同步。
这个 skill 的存在背后是我对「文档腐烂」的恐惧。
代码会被维护，文档不会。但 AI 时代有点不一样了，因为 agent 读 CLAUDE.md 来理解项目，CLAUDE.md 不准代表 agent 在错误的前提下工作。所以文档的准确性突然变得很重要。
neat-freak 是我让文档自己保持准确的方式。
接下来这个有点意思。
三遍自我批判，是今天才加进规则里的。
起因是我让 Claude 写一个公开仓库的 design spec，它写得挺好。我看了一遍说 ok 上吧。Claude 啪啪啪写完 plan 准备进 execute phase。我突然意识到 plan 里有一些挺明显的问题。
我说你刚才有过一遍 self-review 啊，怎么没发现？
Claude 说我做了 self-review 通过了。
然后我让它再 critique 一遍，啪啪啪一堆 P0 issue 出来了。
我说所以你做的那个 self-review 是单 pass 的，单 pass 是糊弄。
然后我让它做 3-pass critique。Pass 1 架构和正确性。Pass 2 安全性和完整性。Pass 3 流程和人因。每一个 pass 用不同的视角看，产出 P0、P1、P2 findings。
啪一下又一堆问题出来了。其中包括 URL token swap 是 over-engineered（empirically 0 occurrences）、audit grep 没集成 gitleaks（少一道防线）、sync direction 没声明（public 是 read-only mirror 还是双向同步没说清）。
这些问题在第一遍 self-review 里全都没出来。
我就把这条加进了全局规则。「永远 3-pass critique，永远先 empirically grep 再下判断。」
才加的规则，时间还短，但已经在这次 session 里救了我一次。
「AX 不 review」是另一条。
这个原则是我写在 memory 里的，agent 启动时会自动读到。「AX 不 review 代码、也不 review 长篇 artifact（plan、spec、design、roadmap）。agent 自己跑 multipass。AX 只 review 极简的 sign-off 摘要或者 critical decision。」
为什么？
因为我读不动 1000 行的 PLAN.md。
我以前会试着读，发现读到一半就懵了。然后就糊弄过去说「ok 上」。Agent 把这种糊弄当成 approval，结果搞出一堆问题。
后来我想清楚了，既然我事实上不会认真读，不如承认这个事实，让 agent 自己跑严格的 multipass review。我只看最后一页 10 行的 sign-off summary，目标、范围、风险、验收标准。这 10 行我会认真看。
这个改变让 agent 的工作质量上了一个台阶。它知道我不会兜底，于是 self-review 反而变得严格了。
回到主线，聊聊那个 sync-public 基础设施。
整套同步基础设施是一个 Bash 脚本加三个 Python 脚本。sync-public.sh 是主调度器，preflight、copy、sanitize、prune、audit 五个阶段串起来。sanitize.py 按规则文件做正则替换。build-settings-template.py 把私有 settings.json 转成公开 template。build-index.py 自动生成 INDEX.md。
加起来大概 600 行代码。23 个 pytest 单元测试。
最关键的是双层审计。
Tier 1 是身份词 grep，逐个搜 xingfanxia、computelabs、x@computelabs、/Users/xingfanxia。任何一个有命中就 exit 1。
Tier 2 是 gitleaks，这是 GitGuardian 的同款工具，扫所有常见的 secret pattern。GitHub token（ghp_、github_pat_）、OpenAI key（sk-）、Anthropic key（sk-ant-）、AWS access key（AKIA）、Slack token（xoxb-、xoxp-）、Telegram bot token、Stripe key 等等。
整套审计是 fail-closed 的。任何一个 finding 脚本就 exit 1，拒绝把内容推到公开 remote。
今天 bootstrap 第一次跑的时候，这套审计实际抓出了几个我没注意到的 leak。
第一个是 gws-gmail-forward skill 里硬编了我的个人 Gmail handle（xingfanxia_at_gmail_com 当目录名）。这个 skill 是我自己用来转发 Gmail 的，里面的账号配置我从来没想过要分享。
第二个是 omni-search 和 omni-doc 这两个 skill 引用了我们公司内部的 API endpoint（omni.computelabs.ai）。这俩 skill 在没有内部访问权限的人手里完全跑不起来。
第三个是 Python __pycache__/*.pyc 文件。.pyc 是编译过的字节码，里面把 /Users/xingfanxia/... 路径硬编进去了。我自己肉眼 grep 看不见，但工具看得见。
针对前两个问题，最简单的解决方案是把这些 skill 加进 denylist，它们是我个人基础设施，不适合开源出去。第三个问题是把 **/__pycache__/ 和 **/*.pyc 加进 denylist。
整个 bootstrap 跑完之后，audit 出 4 个 PASS，gitleaks 0 finding，325 个文件干净地推到了 GitHub。
这套 fail-closed 的审计，是我对 AI 时代「自动化」最大的信仰投票。
最后说说这套配置是给谁的，不是给谁的。
是给自己想攒一套 Claude Code 配置但不知道从哪开始的人。这个仓库是一个能跑起来的真实参考，可以 fork、可以 copy、可以嘲笑。
是给想看看「重度使用 Claude Code 是什么样」的开发者。这是我每天主力工具产出的真实样本。
是给研究 AI 工具的人。skill 加 subagent 加 hook 这一套抽象目前还没有标准化，你可以从这个仓库里看到一种活下来的样本。
不是给直接 clone 完就指望 work 的人。仓库 README 第一段就写了 portfolio 加 reference, not turnkey install。很多 skill 依赖外部 API key（OpenAI、Anthropic、Gemini、Notion、Linear）、依赖具体 MCP server（claude-in-chrome、context7）、依赖特定 plugin 安装（superpowers、vercel、supabase）。clone 完一堆 skill 是断的，需要你自己去配。
不是给想找一套「最佳实践」的人。这套配置是我个人趣味的产物，里面有大量我个人怪癖（中文长文写作、占卜、桌宠、珠宝营销）跟你的工作流可能完全不沾边。
不是给想找一个 Claude Code 教程的人。这不是教程，是参考。
以上。
写到这里我突然想到一个事。
很多年前我刚开始认真折腾命令行的时候，有人问我「你为什么花这么多时间配 vim、zsh、tmux？这些都是一次性投入」。
那时候我没什么很好的回答。
现在回头看，那些投入的复利在我现在的工作里到处可见。我打字快、我 grep 准、我能用 ssh 在任何一台 server 上无缝工作。
~/.claude 之于 AI 时代，大概就像 /.vim、/.zshrc 之于命令行时代。
它是一个会被持续维护、持续优化、持续传承的「个人工作环境」。它不是工具，它是工具的形状。
当 AI 工具的门槛降到地板（任何人都能 prompt 一句话写代码），差异化就在「你怎么配置这个工具」上。同一个 Claude Code，配置不同，产出的东西是天壤之别。
我自己都没意识到这件事的分量，直到今天把整套 ~/.claude 推到公开仓库的瞬间。
打开 GitHub 看那个 INDEX.md，里面 50+ 个 skill、50+ 个 agent、40+ 个 command 整整齐齐摆在那里。
不是 50 个孤立工具。是一个数字工坊。
我花了 6 个月在它身上，它现在反过来帮我把 6 个月的工作量，压缩成一两小时。
仓库地址，github.com/xingfanxia/ax-claude-config-public。
欢迎 fork、欢迎吐槽、欢迎告诉我哪里写得很傻逼。
这套东西远没到完美的状态，但它已经活下来了。
下一步是让它进化。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。
/ 作者，AX