仓库在这里：Refinex-Space/Refinex-Code。为了避免和官方 Claude Code 直接重名，我把它改成了 Refinex-Code。题材多少带一点刺激成分，我真不敢保证它会永远稳稳地挂在那里，所以如果你对这件事感兴趣，建议先 fork，再顺手点个 star，当作留个备份，也算表示支持。
我最近做了一件很符合程序员直觉、但听上去又有点离谱的事：
我把一场看起来很像打包失误导致的 Claude Code 源码外流，继续做成了一个能本地运行、能继续折腾、还能接入 Codex 的个人版本。当然，这样的案例网上已经很多了，并不是个例。
事情的起点并不复杂。
Anthropic 发布的 @anthropic-ai/claude-code npm 包里，带出了足够多的 source map。只要你愿意花点时间去拼，它就不再只是“能看到几个调试符号”，而是能逐步还原出一整个相当臃肿的 TypeScript 工程。
说得再直白一点：这本来也就是一次打包事故，网上已经闹得沸沸扬扬，估计国产大模型又将迎来一大波升级。
而且还是那种非常现代软件工业风格的事故：不是哪位工程师写错了算法，不是模型推理出了 bug，而是发布流程把本来不该带出去的工程细节，一起塞进了发给全世界的产物里。
世界果然是一个巨大的草台班子。
事情比 “看了几眼源码” 大得多
我最开始其实也以为，这件事最多就是 “能翻一翻源码，看看藏了什么彩蛋”。
结果一落地到本地工程，规模马上就把我教育了一遍。
我现在手里的这份 Refinex-Code，本地快照里大概是这个体量：
| 指标 | 本地快照 |
|---|---|
src/ 文件数 | 2062 |
src/commands/ 一级命令目录 | 88 |
src/services/ 文件数 | 151 |
src/tools/ 文件数 | 199 |
src/bridge/ 文件数 | 33 |
这已经完全不是 “扒到一点内部实现” 的级别了。
它更像是：一个商业 AI CLI 团队自己内部正在维护的大仓，阴差阳错地把骨架、器官和一部分神经系统一起暴露了出来。
更妙的是，这个项目现在虽然已经被我改名成了 Refinex-Code，但你打开 package.json，仍然会看到它还保留着上游包名：
{
"name": "@anthropic-ai/claude-code"
}这就是我说它带着很强事故现场感的原因。
- 我把外壳换成了自己的名字，单纯是为了避免 Claude Code 的命名会导致这个仓库很快被 Ban 掉
- 我把启动命令也整理成了
rcode，避免和你本地实际安装的claude冲突 - 但内部很多地方依然在提醒你，这东西本来是谁
我其实很喜欢这种不那么体面的真实感。它比任何 “逆向工程传奇” 都更像现实世界。
我在源码里看到的，不是一个简单 CLI，而是一整套被折叠起来的 Agent 平台
真正让我兴奋的，不是 “我终于能看到源码了”，而是 “我终于能比较完整地看到 Claude Code 到底想做成什么”。
如果只看 public surface，很多人会以为 Claude Code 主要就是一个终端里的编码助手。
但源码不是这么说的。
源码给我的感觉更像：一个被编译期开关、用户类型和远程 feature gate 多层折叠过的 agent runtime。
我在里面看到的能力面，远比一个 “终端对话壳” 野心得多。
Buddy：他们真的在 CLI 里藏了一只电子宠物
这是我最先笑出来的一块。
我在源码里看到了一个完整的 Buddy 宠物系统。不是随便写个彩蛋文案，而是正儿八经的一整套：
18个物种- 稀有度系统
1%闪光概率- 基于用户 ID 的确定性生成
- ASCII 动画
- 抚摸、静音、查看卡片这些交互命令
也就是说，在一个严肃的 AI 编码 CLI 里，内部团队真的塞了一只拓麻歌子。
这种感觉很有意思。
一方面你会觉得，“这帮人也太会给自己加戏了”。
另一方面你又会意识到，只有在一个已经很成熟、很重、很内部化的产品里，团队才会有余力往里面塞这种看起来不那么功利、但非常像真实团队文化产物的东西。
Kairos：它想做的不是一轮对话，而是 “永不关机的 Claude”
如果说 Buddy 更像文化侧面，那 Kairos 就是非常明确的产品方向。
我在 Kairos 这一块看到的不是 “小功能”，而是一整套持久助手思路：
- 关闭终端后继续运行
- 会话恢复
- 定时任务
- 每日日志
- Dream 记忆整合
- Proactive 主动模式
这已经不是 “把聊天窗口搬到终端里”了。
它更像是在试图把 Claude 变成一个持续运行的、带调度和记忆能力的个人后台助手。
说白了，Claude Code 的内部想象，显然不只是 “问一句答一句”，而是 “我能不能让它像一个长期驻留的 agent 那样工作”。
Ultraplan：把难题扔去云端研究半小时
Ultraplan 这块我一开始看得挺乐。
因为它几乎就是把 “这个问题太难了，先丢给更强的远程会话自己想一会儿” 做成了产品模式。
从我看到的实现线索来看，它大概是这样一条链路：
- 本地 CLI 发起
ultraplan - 远程 CCR 会话开始独立研究
- 最长可跑十到三十分钟
- 用户可以在浏览器里看、改、批准
- 最后再把结果传回本地执行
这东西很能说明问题。
说明内部团队想的不是 “如何把单轮代码补全做得更好”，而是如何把困难任务拆成多阶段、多地点、多会话的 agent 工作流。
Coordinator：多 Agent 编排已经不是概念图了
我一直对 “多 Agent” 宣传稿天然保持警惕，因为很多产品说自己多 Agent，本质只是套娃开几个对话框。
但 Coordinator 这块不太一样。
我在这里看到的是一套比较完整的角色分离：
- Coordinator 负责理解目标、拆任务、综合结果
- Worker 负责实际执行
- 结果通过结构化消息回流
- 同时还有 continue / spawn 的明确判断逻辑
它甚至明确规定了 Coordinator 不直接操作代码，只负责组织与综合。这种设计非常像一个真正运行中的编排器，而不是给 PRD 画的流程图。
Hidden commands、CLI 参数、Bridge：真正的能力面远比公开界面大
除了这些 “名字一听就很内部” 的模块，我还看到了一大堆没公开讲透的命令和参数。
包括但不限于：
/assistant/bridge/ultraplan/fork--remote--teleport--sdk-url- 一堆
hideHelp()藏起来的 CLI 参数
Bridge 这块更夸张。我本地统计下来，src/bridge/ 一共有 33 个文件，里面做的不是随便糊一个远程入口，而是一整套远程控制链路：
- 网页端驱动本地 CLI
- 远程审批
- 会话分发模式
- JWT 刷新
- 重连和恢复
- 双向消息桥接
到这一步我基本就确认了：对外公开的 Claude Code，只是内部大系统的一层相对保守的展开面。
真正让我确定 “事情没那么简单” 的，是它的三层门控
如果只是看见很多目录，你最多会说一句 “代码量挺大”。
但真正把这份源码和普通大仓区分开的，是它的门控方式。
我一路看下来，能很清楚地感觉到 Claude Code 至少有三层 gate：
| 层级 | 我看到的典型信号 | 结果 |
|---|---|---|
| 编译期 | feature('BUDDY')、feature('KAIROS')、feature('BRIDGE_MODE') | 某些功能在外部构建里可能直接被裁掉 |
| 运行期 | USER_TYPE === 'ant' | 内部员工和外部用户看到的世界不一样 |
| 远程配置 | GrowthBook + tengu_* flags | 就算代码在，能力也可能按账号动态关闭 |
这件事非常关键。
因为它解释了为什么很多功能 “明明在源码里”，但普通用户就是感知不到。
不是你没找到入口，而是产品本来就是被这样折叠出来的。
所以从研究价值看，这次 source map 外流最有意思的地方，不只是 “我看到了哪些隐藏功能”，而是我终于能比较完整地看到，一个成熟 AI CLI 是怎么把完整能力面裁剪成 public product 的。
我没有满足于围观，我直接把它做成了自己的版本
如果故事只停在 “我看到了好多内部能力”，那也就止步于技术八卦了。
但我对这种事情一向比较贪心。
既然源码都已经在我手上了，那我更感兴趣的问题就是：
我能不能把它变成一个我自己真能用、还能继续魔改的东西？
所以我后面干的第一件事，不是继续扒更多隐藏彩蛋，而是先把项目真正跑起来。
现在这份 Refinex-Code 的最小启动路径很直接：
bun install
bun run version
bun run dev我这里会先跑 bun run version 做最小可用性检查。至于版本号本身，我后来已经按自己的整理节奏主动改过，不再拿它当 “事故现场证据”。
这一点对我依然很重要。
因为很多 “逆向还原工程” 最后都停在静态阅读层，项目像一个标本；而我更想要的是一份活着的工程。
既然都做个人版本了，我顺手把外观和名字也一起改了
既然我没有打算假装这是 “官方镜像”，那我就没必要让它继续顶着官方名字四处晃。
所以我做的第一层整理很直接：
- 仓库名改成
Refinex-Code - 欢迎文案改成
Welcome to Refinex Code - 启动入口整理成
rcode - 启动页和 onboarding layout 也按自己的版本修了一遍
我甚至顺手给它放了一个自己的小幽灵形象 Clawd。
它现在大概长这样：
$ bun run ./src/dev-entry.ts
╭─── Refinex Code v999.0.0-restored ───────────────────────────────────────────────────────────────────────────────────────────╮
│ │ Tips for getting started │
│ Welcome back! │ Run /init to create an AGENTS.md file with instructions for Refinex Code │
│ │ ──────────────────────────────────────────────────────────────────────── │
│ ▄▄▄▄▄▄▄▄▄ │ Recent activity │
│ ▗ ▖ │ No recent activity │
│ ▐ ◕ ◕ ▌ │ │
│ ▐ ᵕ ▌ │ │
│ ▗ ▖ │ │
│ ▝▄▀▄▀▄▀▄▀▄▘ │ │
│ │ │
│ │ │
│ GPT-5.4 with xhigh effort · API Usage Billing │ │
│ ~/xxx/Refinex-Code │ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[GPT-5.4] ░░░░░░░░░░ 0% | 📂 ~/xxx/Refinex-Code | 🅥 INSERT ◉ xhigh · /effort
-- INSERT -- ⏵⏵ bypass permissions on (shift+tab to cycle)原因很简单：
我不想维护一个 “明明已经是个人研究版，却还努力伪装成官方原样” 的项目。这样既不诚实，也没什么意思。
把它做成一个有明确身份、明确边界的研究版本，反而更自然。
然后我开始做真正有用的改造：把 Codex 和 GPT-5 接进来
这部分是我后面最下功夫的一段。
因为我很早就判断出一件事：如果我只是把某个 ANTHROPIC_BASE_URL 指到别的地方，然后宣布 “好了现在支持 GPT-5 了”，那这件事从工程上就是假的。
真正的问题在于，Claude Code 这套运行时深度绑定了 Anthropic Messages 的语义，而 OpenAI / Codex 这一边，官方支持的是 Responses API。
所以正确的方向只有一个：老老实实抽 adapter，老老实实接 openai-responses，不要搞自欺欺人的 base URL 幻术。
我后面把这件事拆成了几个连续阶段去做：
| 阶段 | 我做了什么 |
|---|---|
| 研究阶段 | 先确认 Codex provider 不该走 Anthropic 兼容 hack，而应该走 Responses 适配 |
| 基础层 | 加入用户级 provider registry、auth store、modelProvider 配置 |
| 适配层 | 先把原 Anthropic 请求路径抽到 provider adapter 后面 |
| 运行层 | 落第一版 openai-responses adapter |
| 体验层 | 把 model picker、reasoning effort、verbosity 都改成 provider-aware |
最后落到用户侧的结果，就是现在这套仓库已经不是 “理论上可以碰一碰 GPT-5”，而是真的能在这层 Claude Code 壳子里比较顺手地把 Codex / GPT-5 用起来了。
我现在是怎么配 Codex provider 的
我没有让这件事停在 “请你自己打开配置文件手写 JSON”。
现在仓库里已经有了 /provider 这套管理流，你可以直接：
/provider
/provider status
/provider anthropic
/provider codex交互式向导会帮你配这些东西：
- Base URL
- API Key
- 默认模型
- Context window
- Auto-compact 阈值
- Verbosity
- Reasoning effort
交互过程算是比较符合我的个人口味的，如果你不满意可以接着改：
❯ /provider
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Manage Provider
Current provider: codex (OpenAI Responses)
Current model: gpt-5.4
Provider auth: configured
Context window: 1050000
Auto-compact trigger: 700000
Providers file: /xxx/.claude/providers.json
Auth file: /xxx/.claude/auth.json
User settings: /xxx/.claude/settings.json
❯ 1. Switch to Anthropic Use the built-in Anthropic provider and clear OpenAI-only settings.
2. Switch to Codex Use codex with gpt-5.4.
3. Edit Codex settings Update base URL, API key, default model, context window, auto-compact threshold, verbosity, and effort.
Enter to select. Esc to cancel.你可以保持 Anthropic 也可以选择切换到 Switch to Codex 或者 Edit Codex settings，它会引导你一步步配置完成：
Step 1 of 7 · Base URL
Configure Codex
Base URL for the OpenAI Responses-compatible provider. File target: /Users/refinex/.claude/providers.json
https://xxxxxx/v1
Enter to continue. Esc to go back.输入完你的 Codex 的 BaseUrl 回车进一步填写你的 API Key：
Step 2 of 7 · API Key
Configure Codex
API key for codex. Leave blank and press Enter to keep the existing credential in /Users/refinex/.claude/auth.json.
sk-...
Enter to continue. Esc to go back.然后是默认模型，我这里直接上 GPT-5.4 了：
Step 3 of 7 · Default Model
Configure Codex
Default model to activate immediately after switching providers.
gpt-5.4
Enter to continue. Esc to go back.回车进入上下文窗口的设置，这里的值是从 Codex CLI 仓库源码中扒来的，会根据你选择的模型自动计算出实际的推荐上下文窗口。当然，GPT-5.4 是支持 1M 的上下文窗口的，前提是你的中转不是水货。
这里我直接上了最大上下文，也就是 1050000：
Step 4 of 7 · Context Window
Configure Codex
Optional context window override in tokens. Leave blank to use the Codex-compatible default for gpt-5.4 (1050000).
1050000
Enter to continue. Esc to go back. Next: Auto-compact trigger (default 945,000)下一个配置项是自动压缩触发阈值（token 数），是一个任意正整数（应 < model_context_window）它同样会自动算出，当然你可以根据最佳实践选择。默认值约为上下文窗口的 50%（~525k），由于我开启了 1M 上下文，这里设置了 700000（~67% 窗口 — 最佳临界点），因为 900k（86%）经实测会导致 xhigh 推理余量不足 + 长上下文幻觉加深。
Step 5 of 7 · Auto-Compact Trigger
Configure Codex
Optional auto-compact trigger in tokens. Leave blank to use the Codex-compatible default (945,000). Runtime will clamp values above 90% of the configured context window.
700000
Enter to continue. Esc to go back. Next: Verbosity然后就是配置下 Default verbosity，直接 hight 就完事了：
Step 6 of 7 · Verbosity
Default verbosity for GPT-5 Responses. File target: /Users/refinex/.claude/settings.json
1. Low More concise output.
2. Medium Balanced detail.
❯ 3. High ✔ More verbose output.
Enter to select. Esc to go back.最后一个配置项是默认推理努力，看你个人 high 或者 xhigh 都可以，我这里是 xhigh:
Step 7 of 7 · Effort
Default reasoning effort for gpt-5.4. Unsupported values are removed automatically for known models.
1. minimal
2. low
3. medium
4. high
❯ 5. xhigh ✔
Enter to select. Esc to go back.至此，引导配置完毕，选择 Save and activate Codex 即可：
Review Codex Configuration
Provider ID: codex
Driver: OpenAI Responses
Base URL: https://xxxxxx/v1
API key: keep existing stored credential
Default model: gpt-5.4
Context window: 1050000
Auto-compact trigger: 700000
Verbosity: high
Effort: xhigh
providers.json: /xxx/.claude/providers.json
auth.json: /xxx/.claude/auth.json
settings.json: /xxx/.claude/settings.json
❯ 1. Save and activate Codex Create or update user-scoped provider files and switch the active model immediately.
2. Back Return to the previous step.
Enter to confirm. Esc to return to the menu.最终会落到三层用户级文件：
~/.claude/providers.json~/.claude/auth.json~/.claude/settings.json
一个最小可用的 providers.json 大概是这样：
{
"defaultProvider": "codex",
"providers": {
"codex": {
"driver": "openai-responses",
"baseUrl": "https://api.openai.com/v1",
"defaultModel": "gpt-5.4",
"defaultReasoningEffort": "medium",
"defaultVerbosity": "medium"
}
}
}然后运行时会走真正的 openai-responses adapter，而不是继续强行套 Anthropic wire format。
这也是我最看重的一点：不是 “看起来支持了”，而是接法本身是对的。
最后，发个消息实战一下：
% bun run dev
$ bun run ./src/dev-entry.ts
╭─── Refinex Code v999.0.0-restored ───────────────────────────────────────────────────────────────────────────────────────────╮
│ │ Tips for getting started │
│ Welcome back! │ Run /init to create an AGENTS.md file with instructions for Refinex Code │
│ │ ──────────────────────────────────────────────────────────────────────── │
│ ▄▄▄▄▄▄▄▄▄ │ Recent activity │
│ ▗ ▖ │ No recent activity │
│ ▐ ◕ ◕ ▌ │ │
│ ▐ ᵕ ▌ │ │
│ ▗ ▖ │ │
│ ▝▄▀▄▀▄▀▄▀▄▘ │ │
│ │ │
│ │ │
│ GPT-5.4 with xhigh effort · API Usage Billing │ │
│ ~/xxx/Refinex-Code │ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
❯ /provider
⎿ Configured and activated Codex with gpt-5.4.
❯ 你好，介绍一下你自己，出自哪家模型提供商。
Read 5 files (ctrl+o to expand)
⏺ 你好，我是你当前这个编码会话里的 AI 助手，运行在 Codex / GPT-5.4 模型上。
模型提供商是 OpenAI。
如果你问“出自哪家模型提供商”，答案就是：OpenAI 提供的 GPT-5.4。
我现在主要能帮你做这些事：
- 读代码、改代码、排查 bug
- 解释项目结构和实现逻辑
- 写脚本、补测试、跑命令
- 查文档、对比方案、做实现计划
如果你愿意，我也可以顺手根据这个仓库的上下文，简单介绍一下我在这个项目里会怎么协作。
✻ Churned for 47s
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[GPT-5.4] ░░░░░░░░░░ 3% | 📂 /xxx/Refinex-Code | 🅥 INSERT
-- INSERT -- ⏵⏵ bypass permissions on (shift+tab to cycle)鼓掌 👏！
我顺手把 AGENTS.md、Skills 和 Codex 这套工作流也理顺了
当我真的开始用 Codex 去改这个项目时，很快就发现一个现实：
模型能力本身不是最大的瓶颈，仓库有没有一套适合 agent 长期工作的控制面，才是。
所以我后面做的改造，并不只有 provider。
我把共享指令标准拉到了 AGENTS.md
这一步其实很重要。
因为如果一个项目一边想兼容 Claude 风格工作流，一边又想接入 Codex，结果共享说明文件还死守 CLAUDE.md，最后你会得到两套互相打架的习惯。
所以我把共享标准往 AGENTS.md 统一：
- runtime loader 认
AGENTS.md /init生成逻辑也往AGENTS.md对齐- 但 legacy
CLAUDE.md仍然保留兼容
这样这个仓库才更像一个 provider-neutral 的 agent 项目，而不是 Anthropic 专用壳子硬套其他模型。
我也把 ~/.agents/skills 做成了一等公民
这一步是为了让整个技能体系更顺。
之前很多技能发现逻辑天然偏向 ~/.claude/skills。但既然我已经在往 Codex 和更通用的 agent 工作流靠，那 ~/.agents/skills 本来就应该被认真对待。
所以我把用户级技能发现、watch、权限收缩和 UI 提示一起补齐了。现在它同时支持：
~/.agents/skills~/.claude/skills
这一步看起来像小修，但体验上差很多。因为它决定了这个仓库到底是在 “兼容技能”，还是在 “真正把技能当成工作流的一部分”。
后来我发现，越改越像是在落地 Harness Engineering
我一开始并没有抱着 “今天一定要把它做成 Harness 仓库” 的目标去改。
但事情改到后面，方向几乎是自然出现的。
因为只要你真的开始让 Codex、Claude、skills 和 provider 共存在一个大仓里，你就会很快发现：
- 需要统一的任务入口
- 需要统一的知识路由
- 需要结构化的 exec plan
- 需要机械检查
- 需要把 “怎么让 agent 正确工作” 从聊天记录里搬到仓库工件里
这其实就是 OpenAI 在 Harness engineering: leveraging Codex in an agent-first world 里讲的核心问题。
所以我后面顺势把这套控制面也落了进来：
AGENTS.mddocs/README.mddocs/PLANS.mddocs/generated/harness-manifest.mdscripts/check_harness.pydocs/exec-plans/completed/
这些东西堆在一起，意义不是 “文档更多了”，而是这个仓库开始对 agent 更友好了。
如果你想继续看这部分方法论，而不是只看这篇源码故事，我建议直接跳这篇：
《Harness Engineering：Agent First 时代的软件工程控制面》
那篇讲的是 “为什么最后会自然走到 Harness”，这篇更偏 “我是怎么从一次源码事故一路折腾到这里的”。
不发 npm，我还是把全局使用这件事解决了
研究版项目最容易掉进的一个坑，是一边不想正式发布，一边又搞得自己很难日常使用。
我不想这样。
所以我最后给它整理了一条很克制、但很好用的全局方案：
cd /path/to/Refinex-Code
bun install
bun link
which rcode
rcode --version现在我统一只保留 rcode 这一个入口，不再继续维护旧 alias。
而且这个入口会保留你当前终端所在目录，所以你可以直接在任何项目下启动：
cd /path/to/your-project
rcode不会莫名其妙把工作目录切回 Refinex-Code 仓库本身。
对我来说，这就是研究版 CLI 最舒服的状态：
- 不需要 npm 发布
- 不需要假装自己已经产品化
- 但可以真正常用
如果你想继续魔改这个项目，我还准备了另一套工具
如果你读到这里，八成已经不是单纯来看热闹了，而是真的想继续折腾这份仓库。
那我建议你顺手去 star 另一个仓库：Refinex-Skills。
我在里面放了四个比较实用的 skill，它们不是 “技能大全”，而是专门为了这种 agent-first、需要持续魔改的大仓准备的四把顺手工具：
| Skill | 适合干什么 |
|---|---|
harness-bootstrap | 给一个仓库补齐最基本的 Harness 控制面 |
harness-feat | 用执行计划和验证切片推进新功能 |
harness-fix | 用同样的方法修 bug、做回归定位 |
harness-garden | 给已经有点长歪的控制面做巡检、修枝和纠偏 |
我喜欢这四个 skill 的原因很简单：它们都不追求 “帮你多生成几百行代码”，而是更关心怎么让仓库继续适合 agent 工作。
这点对 Refinex-Code 这种项目尤其重要。因为这种仓库最怕的不是 “今天没做完”，而是 “越改越乱，最后谁都不敢再让 agent 接手”。
所以如果你打算在这份源码上继续二开，我反而建议先把那四个 skill 看明白，再动大手术。
最后
这篇文章我其实是带着一点幸灾乐祸开始写的。
毕竟 “商业 AI CLI 因为 source map 打包翻车，被人一点点拼回来了”，这种剧情天然就很有戏。
但真正做下来之后，我反而越来越觉得，这件事最有意思的地方不在于嘲笑谁翻车，而在于：
一次很像事故的源码外流，最后居然真的能长成一个新的个人版本，一个新的研究底座，甚至一个新的实验分支。
这比单纯围观有意思多了。
如果你也想继续折腾：
- 先去 fork Refinex-Code
- 再去 star Refinex-Skills
- 然后我们一起看看，这个巨大的草台班子，最后还能长出多少奇怪又好玩的东西