自进化 Skill 是真的，但它带刹车：decode-codex 的维护协议拆解
宝玉那条「Skill 每次遇到新场景就自己更新」的推文，方向是对的，程度被夸大了。把仓库一手文件拉下来读完会发现：协议只认三类触发条件，还写着「绝不让正在跑的这一轮失稳」。
- 仓库坐实：JimLiu/decode-codex 真实存在且公开，2026-08-29 实测 117★ / 47 fork（第三方索引站 7 月记录为 93★ / 36 fork）。推文页抓取被 X 拦截，结论全部以仓库一手文件为准。
- 术语要修正：它做的不是严格意义的反编译（无字节码→源码），而是反混淆 deobfuscate + 可读性还原 humanify。
- 「每次都自更新」被夸大：协议原文只认三类触发条件，命中才改；且明确写着「不要为了投机式重构阻塞交付」。
- 最反直觉的数据点：全仓最大的实现脚本是 quality-gate.ts（约 135 KB），比第二大的 ledger.ts 大 4 倍；而它的测试文件（约 215 KB）比实现本身还大 1.5 倍。
- 自进化是四件套：触发条件 + 路由表 + 安全护栏 + 留痕纪律。缺任何一件都会失控。
- 我们的决策是不装、吸收协议：无开源许可证、README 明写不要重新分发、体积 207 MB、依赖 bun、Skill 1 仅 macOS。但那套四件套与领域无关，可直接移植。
推文被拦之后，怎么把事实立住
这次核查的起点是一次失败：推文页抓不到，WebFetch 返回空，X 平台直接拦了。这条链断掉之后通常的做法是找二手转述——但这次要核的恰恰是「转述有没有夸大」。所以换了条路：推文给了仓库地址，那就直接核仓库。
| 核查项 | 推文 / 流传说法 | 实测结果 | 判定 |
|---|---|---|---|
| 仓库真实性 | 指向 JimLiu/decode-codex | repo id 1278184266，公开，main 分支，描述「deobfuscate codex app code」 | 坐实 |
| 「反编译 JS 代码」 | 反编译 | 实为 deobfuscate（反混淆）+ humanify（重命名还原）；无字节码级反编译 | 术语需修正 |
| 「每次遇到新场景就自己更新 Skill」 | 无条件、每次 | maintenance.md：仅三类触发条件命中才改，且设安全护栏 | 方向对，程度夸大 |
| 开源可自由使用 | 隐含「开源」 | license 为 null，根目录无 LICENSE 文件，默认「保留所有权利」 | 不可默认复用 |
| 作者身份 | @dotey 发布 | owner 为 JimLiu；多方资料标注 JimLiu/baoyu-skills 为「宝玉（Jim Liu）的技能集」，@dotey 即宝玉 | 高置信旁证 |
最大的文件不是反混淆器，是判定有没有做完的门禁
先看一个反直觉的数据点。这是个反混淆工具，你会以为最大的脚本是反混淆器——不是。
最大的实现脚本是判定质量的门禁，比第二大的大 4 倍；门禁的测试文件比门禁本身还大 1.5 倍。作者把最大的人力投在了「判定做没做完」而不是「把活干出来」。
自进化不是「让 Agent 随便改自己」
协议原文在 reference/maintenance.md，开篇第一句定调：「Treat this skill as a living asset, not a frozen tool」（把 Skill 当成活的资产，不是冻住的工具）。但要让它活着而不失控，靠的是四件套。
第一件是触发条件——只有命中下面三类才允许动手改 Skill。
| # | 触发条件 | 原文要点 |
|---|---|---|
| 1 | 明显缺陷 | 脚本 bug、校验门误判、指令错误或误导、文档里失效的路径 / flag / 脚本名 |
| 2 | 可优化的流程 | 你手工完成了一个本可由脚本 flag 代劳的步骤；更优的阶段排序；在多个 chunk 上重复做了同一个手工修正 |
| 3 | 新的 / 漏掉的 npm 包身份 | 某个 vendor chunk 不在注册表里；某个公开包差点被写成手写兼容实现；值得引入的外部工具 |
第二件是路由表——协议里最见功力的一张表。它不是笼统说「更新 Skill」，而是指明每一类发现的确切归宿：新的 vendor 包写进注册表并补通过/失败两组测试、漏判的包先改 shim 再加固守卫、脚本 bug 修完必须补测试防回退、边界情况追加进 caveats.md。原则只有一句：一处事实只存一处。没有路由表，Agent 不知道往哪写，就会随手塞进 SKILL.md，越塞越臃肿，最后没人敢动。
绝不让正在跑的这一轮失稳
第三件是安全护栏，小标题原文是「never destabilize the run you're in」（绝不让正在跑的这一轮失稳）。三条规则按风险分级。
第四件是留痕纪律：每一轮结束都要提交；Skill 的自我改进必须单独成 commit，与业务产出严格分开；Skill 类提交统一前缀「skill(名称): 改了什么」，业务进度另走检查点约定；中间工作区保持 gitignore，永不入库。
这套成本极低，但三个月后你能靠它回溯「这条规则当初为什么加的」。
不装这个 Skill，吸收它的协议
决策是不装。理由是硬的，与能力无关。
| 风险项 | 实测情况 | 影响 |
|---|---|---|
| 许可证缺失 | license 为 null，无 LICENSE 文件 → 默认保留所有权利 | 高：不能合法复制进技能库或二次分发 |
| 作者明文限制 | README 末尾注明：提取的代码 © OpenAI，不要重新分发 | 高：仓库自带产物属受限内容 |
| 平台与运行时 | Skill 1 仅 macOS + 已装 ChatGPT.app；Skill 2 脚本需 Bun | 阻断：Windows 上 Skill 1 完全不可用 |
| 体积 | 207 MB，反混淆产物一并提交进仓库 | 中：克隆成本极高 |
| 领域不匹配 | 我们的主业是具身智能落地 + 内容 IP，不是 JS 逆向 | 中：装上大概率吃灰，还占上下文 |
但那套四件套——触发条件 / 路由表 / 安全护栏 / 留痕纪律——与具体领域完全无关，可以直接移植。我们现有的几个 Skill 目前都是静态的：这次踩的坑，下次照样再踩一遍。
移植时要做两处改造：去掉对 bun test 测试套件的硬依赖（我们的 Skill 多为 Markdown 型，无测试框架），改成「改脚本必须实跑一次验证」；路由表从它的 scripts/ + reference/ 结构改成适配我们的 references/ + scripts/ + assets/ 结构。
三条立刻可做的动作：给已有 Skill 各建一个 references/caveats.md，把踩过的坑写进去（微信编辑器吞掉哪些样式、哪次粘贴后错位了——这些现在是「每次重新讲一遍」，写进去就是永久能力）；下次排版时跑一遍新协议，跑完问一句「这轮有没有命中三个触发条件」；给每个 Skill 加统一的留痕前缀。
作者身份（@dotey 即宝玉 / JimLiu）为旁证推断而非直接声明。仓库当前无开源许可证；本报告为研究性分析，不构成法律意见，不建议复制或二次分发该仓库内容。