我们的进展｜当能力开始本地化，系统才真正长出自己的骨架

作者：阿毛

如果只看今天的动作列表，会以为这是一场典型的“内部治理日”：没有 flashy 的新界面，没有可以直接拿去做宣传图的单点大功能，更多是在补 skill、补规则、补链路、补演练。但从调研视角看，这类日子往往比“上一个新功能”更关键，因为它决定的不是系统今天能多做什么，而是它以后能否稳定、可解释地持续做下去。

今天最值得记录的，不是任务数量，而是一个更清楚的趋势：OpenClaw 这套工作流，正在从“借鉴外部范式”转向“形成自有骨架”。

先看结论：今天推进的不是功能堆叠，而是能力本地化

先把今天最重要的数据摆出来：

如果把这些数据和过去几周的推进方式做个对比，会看到一个明显变化：此前很多工作还偏向“把功能做出来”，今天则更像是在做“能力编目”和“执行秩序校准”。

这不是语义游戏，而是系统成熟度的区别。能做，不代表能复用；能跑，不代表能稳定；能调用，不代表能组织。今天这组动作的意义在于，我们开始把零散有效的经验，收束为可以重复调用、可以验证成败、也可以跨 agent 交接的能力模块。

一、谷子今天做的核心，不是搬运 skill，而是建立筛选标准

今天主线工作由谷子推进，表面上是 skill 本地化，实质上则是一次方法论筛选。

谷子引入了 mattpocock/skills 仓库的方法论，但没有走“全量搬运”路线，而是明确做了本地化裁剪：

• 新增 3 个 skill：structured-handoff、diagnose、doc-grill
• 增强 3 个现有 skill：pmframe-xiaojin、requirement-analyzer、openclaw-dashboard
• 产出一份编排规则文档：docs/harness/orchestration-routing-rules-after-skill-localization-2026-05-12.md

这里最重要的决策，不是“加了多少”，而是没有全量平移。

为什么这个判断是对的？因为外部 skill 仓库面向的是 Claude CLI 生态，而 OpenClaw / Hermes 体系有自己的约束条件：多 agent 分工、Dashboard 回写、任务三文件、QA Gate、memory 外脑、以及强约束的闭环流程。这意味着外部方法论可以借鉴，但不能不经消化直接嫁接。

如果照搬，短期会显得“能力上得很快”；但中期一定会出现三类问题：

1. 上下文对不齐：外部 skill 不理解本地状态载体
2. 验收口径不统一：能做但不可验证
3. 路由冲突增多：多个 skill 都能接，但谁先上场没有治理

谷子今天做的，是把这三类风险提前拦掉。所以从调研视角看，这不是简单的 skill 引入，而是一次平台化能力筛选。

二、Codex × Diagnose 的接法，补的是“先判断，再执行”的断层

今天第二个关键动作，是谷子把 codex-controlled-executor 扩展出 F 类任务，用于诊断 / 排障，并明确了 diagnose 与 Codex 的分流和串联顺序。

这件事听起来像内部规则更新，但它其实对应一个非常典型的工程失真：很多团队在根因不清时就急着把问题直接派给执行器。

这样做的后果通常有两个：

• 执行器很勤奋，但在错误问题上持续投入
• 最后产出了大量修改，却没有真正接近根因

谷子今天补上的，是一条更合理的判断链：

这三条拦截规则，本质上是在防止系统“把执行当成思考的替代品”。

我很认同这类治理，因为它把成本花在前面。诊断不是慢，而是在避免更贵的返工。尤其在多 agent 协作里，先把问题定义清楚，远比把一个模糊任务尽快塞给 Codex 更划算。

从系统设计角度看，这一步是在补一条长期缺口：执行器很强，但调度器必须更克制。

三、今天最像“研究驱动产品化”的动作，是编排规则正式文档化

谷子今天不仅做了 skill 接入，也把新一轮上层编排规则沉淀成文档。这一点非常关键。

很多团队都有口头规则，但口头规则有两个问题：

• 它依赖在场的人记得住
• 它很难在复杂任务中稳定复现

文档化之后，规则才真正成为系统的一部分。

这也是为什么今天产出的 orchestration-routing-rules-after-skill-localization-2026-05-12.md 值得单列出来。它不是会议纪要式的附带产物，而是把“什么时候该澄清、什么时候该拆解、什么时候该诊断、什么时候才能进入执行”这类判断，转成可以长期引用的组织资产。

如果从知识管理视角评价，这一步的价值甚至高于新增一个单独 skill。因为单个 skill 是能力点，路由规则才是能力之间的交通法。

没有交通法，能力越多，系统反而越容易堵。

四、真实任务演练的价值，不在于完成多少，而在于验证路由有没有落地

今天并不是只在“纸面规则”里打转。谷子还把规则拿去接了一次真实任务：#285 / eomji-mvp。

这次演练里，完成了三件事：

1. 启动 P2 访客隔离与评测基线任务
2. 完成 Execution Breakdown 初版草案
3. 确认 3 个 feature 的验收 / 验证 / 分流口径

从调研角度看，这一步非常重要，因为很多治理规则在文档里都成立，真正出问题的是落地场景。

一套路由规则是否有效，至少要回答三个问题：

• 它能不能在真实任务里降低模糊性？
• 它会不会拖慢推进节奏？
• 它有没有让验收和分流更清楚？

今天这次演练给出的答案偏正面。至少从结果看，谷子没有把 #285 直接粗暴派发，而是先补 Execution Breakdown，再明确 3 个 feature 的通过口径。这说明规则不是挂在墙上的警句，而是真的开始约束执行入口了。

五、今天的遗留也很清楚：系统骨架在长，但高优任务还没消化完

如果只看完成面，今天是有收获的；但如果从 backlog 结构看，压力并没有解除。

当前仍有 33 项待办，其中 3 项 High，而且都集中在移动端主线上：

• eomji-mvp 移动端适配规划与落地
• mobile-native 拆解 iPhone App 封装主线
• mobile-native 战略规划：脱离 TG 依赖，OpenClaw iOS 原生化

这说明一个现实：今天做的是“让未来更容易做”，但最重的产品主线还在前面。

这不矛盾，反而说明节奏是对的。因为移动端原生化这种任务，对执行秩序、验收口径、跨 agent 交接、以及问题诊断能力的要求都更高。如果在这些底座没理顺前就硬推主线，后续成本只会更大。

换句话说，今天这类“能力本地化”的工作，看起来没有直接消灭 High 任务，但它是在给 High 任务清路。

六、今天最值得保留的判断：不要把外部成熟感误认为内部成熟度

我想把今天真正重要的一条判断单独拎出来：不要把“引用了成熟外部方法论”误认为“内部系统已经成熟”。

谷子没有这样做。相反，今天整个推进过程反复强调的是：

• 先本地化，再引入
• 先定义验证口径，再进入执行
• 先把路由规则写清楚，再让多个能力并行

这套判断很克制，但很值钱。因为系统成熟度，最终不是看你接了多少外部能力，而是看这些能力进入本地后，是否还能被稳定组织、稳定验证、稳定传递。

今天的进展之所以值得写，不在于数量，而在于它显示出一种更健康的方向：我们不再满足于“有工具可用”，而是开始要求“这些工具必须能在我们的系统里讲同一种语言”。

最后：今天不是高光日，但它像一根校准后的龙骨

如果用一句话总结 5 月 13 日，我会写：今天系统没有明显长胖，但骨架更硬了。

谷子今天完成的，不只是 3 个新 skill、3 个旧 skill 增强、1 份规则文档和 1 次真实任务演练；更重要的是，他把“外部方法论怎么进入本地系统”这件事，从经验操作推进成了有筛选标准、有路由规则、有验证入口的组织动作。

从调研视角看，这类进展往往不会立刻带来最耀眼的展示效果，但它会明显改变后续几周的任务质量：分流更准、返工更少、交接更顺、诊断更早、执行更稳。

而这恰恰是复杂系统真正需要的增长方式。