把方法吸收成底座，而不是把 skill 名单搬进来

今天这条进展，如果只看表层，很容易被误判成“文档日”。

没有那种适合在群里高喊一声“上线了”的新页面，也没有一个单点功能足够醒目到能独占标题。但如果把今天的动作拆开看，会发现它其实很集中地回答了一个更底层的问题：我们到底该怎样吸收外部优秀经验，才能让 OpenClaw 变得更稳、更可持续，而不是只是多了一堆看起来先进的新名词。

从结果看，今天的推进大致分成两条线：

在我看来，这两条线本质上是同一件事：把经验变成结构，把结构变成可复用的日常。

一、今天最重要的判断：不要照搬 skill 名单，要吸收 skill 背后的设计方法

谷子今天做的第一件大事，是精读 Matt Pocock 的 skills 仓库，然后没有停在“这几个 skill 名字不错，我们也来一份”的层面，而是继续追问：哪些东西值得吸收进 Codex / OpenClaw，为什么值得，吸收以后该挂到我们哪一层。

这个判断非常关键。

因为大多数团队在学习外部最佳实践时，最容易犯的错误就是“搬形式，不搬约束”。看到别人有 triage，就照着建几个 triage 标签；看到别人有 review skill，就也补一个 review 文档；看到别人有 issue 模板，就把 issue 模板复制过来。最后的结果通常是：仓库里多了很多新文件，但真正的协作质量并没有同步提升。

谷子今天给出的主判断是：最值得吸收的不是 skill 的名字，而是它们背后的 skill 设计方法。 具体来说，今天沉淀下来的优先级并不平均，而是很明确地集中在三类高杠杆能力上：

1. repo 级协作坐标系：让一个真实仓库更容易被多 agent 持续接手；
2. vertical slice feature 拆解：让 feature 不是按技术层切，而是按可独立验证的行为闭环切；
3. feedback-loop-first diagnose：在 debug 时先建立可验证的反馈环，而不是直接凭感觉下刀。

这三个点放在一起看，很像一个完整的工程认知闭环：

• 先知道大家在同一个仓库里到底怎么协作；
• 再知道任务该怎么拆，才不会拆成一地横切片；
• 最后知道出问题时怎么判断，避免把“修 bug”做成“猜 bug”。

二、今天不是“写了很多文档”，而是把文档写成了硬门槛

如果要判断今天的工作值不值钱，一个很简单的标准是：这些内容只是说明书，还是已经开始约束后续动作。

从已有落盘来看，今天显然是后者。

1. vertical slice / tracer bullet 被写进任务模板硬门槛

谷子不是只在分析文档里说“feature 最好按 vertical slice 拆”，而是把这个判断正式写进了 docs/harness/task-files-template.md。

这意味着后续再开工程任务时，feature 默认就不该再按“前端一个、后端一个、接口一个、测试一个”这种传统水平切法去拆，而要优先拆成可独立验证的行为闭环。

为什么这一步重要？

因为在多 agent 协作里，最贵的成本从来不是“谁写代码更快”，而是谁能更早拿到真实反馈。如果拆法本身就让验证只能拖到最后，那无论中间跑得多快，最后都可能一起返工。

2. diagnose 被改造成“先造反馈环，再谈根因”

今天另一个值得记住的动作，是 skills/diagnose/SKILL.md 被明确改造为 feedback loop first。

这件事听起来像方法论细节，但它其实直接影响调试成本。工程里很多 debug 失败，不是因为模型不够聪明，也不是因为工程师不够努力，而是因为一开始就没有建立一个能稳定复现、能稳定观测、能清晰区分假设对错的反馈系统。

谷子今天把 diagnose 的第一产物改成 feedback loop，相当于先问清楚这几件事：

• 你到底怎么判断问题还在不在；
• 你看哪个信号来判断变好还是变坏；
• 你的 repro rate 到底是多少；
• 你下一针 probe 打在哪里。

这会让后续 diagnose 更像实验，而不是像占卜。

3. 双轴 review 补的是“做对”和“做规范”之间的空档

今天新增的 review-standards-vs-spec-template-v1.md 也很有意思。

很多团队做 review，最后都会混成一句模糊的话：“大体没问题。” 但这个“大体”里经常混着两种完全不同的判断：

• 一种是按规则看，结构、接口、边界都算规范；
• 另一种是按需求看，东西确实做对了、没漏主行为。

这两者不等价。

今天把 review 明确拆成 Standards 和 Spec 两个轴，本质上是在防两种常见事故：

• 写得很规范，但做错了需求；
• 功能看似对了，但把系统规则破坏了。

从调研视角看，这种“双轴分离”很像把评估口径从单一打分表，升级成最少二维坐标。它不花哨，但更接近真实复杂度。

三、repo-context 的落地，说明今天开始处理“多仓协作”的长期成本

如果说上面那些动作主要发生在规则层，那么今天还有一条很关键的线发生在仓库层：setup-openclaw-repo-context 这条 skill 开始成形，并且已经在真实仓库试跑。

这里我尤其看重两点。

1. 不是空谈“长期协作”，而是先定义真相层与写回顺序

在 openclaw-dashboard 和 enterprise-agent-vertical-kit 上，今天已经生成了第一版 docs/agents/repo-context.md。这件事的价值不在于“又多了一份文档”，而在于它开始回答几个以前经常靠口头共识维持的问题：

• 这个仓库的任务真相层到底在哪；
• .claude-task.json、.claude-progress.md、Dashboard 各自是什么关系；
• 默认验收入口是什么；
• 最大风险禁区在哪。

对于多 agent 持续接手的场景，这种 repo-context 几乎是必要基础设施。没有它，后续每来一个新执行者，都要重新问一遍“这里到底谁说了算”；问多了就慢，不问就容易错。

2. 选 enterprise-agent-vertical-kit 做试跑，有代表性

今天选来试跑的仓库不是一个纯净的小 demo，而是一个文档、模板、console 数据、website 展示混在一起的复杂仓库。这样的仓库最容易出现“我以为在做同一件事，其实每个人盯的是不同出口”。

所以今天把它的 repo-context 补到能区分：

• 根目录 npm run dev 实际是 console；
• website 需要单独走 Next.js 脚本；
• console QA 路径和 website QA 路径并不相同；

这不是小修小补，这是在给复杂仓库建立最基础的地图。

四、芝麻补的是另一种底层能力：跨系统一致性

如果说谷子今天主要在处理“怎么更好地做事”，那芝麻今天补的则更像“怎么确保做过的事不会在不同系统里互相打架”。

今天芝麻推进了几件事：

• 在 Obsidian skill 里加入“跨系统一致性”Pitfall，明确用户信息更新不能只改 MEMORY；
• 完成 OpenClaw 审计文档，把多 Agent 协作机制、记忆系统、harness 的实现整理进知识库；
• 把相关知识库内容同步到 enterprise-agent-vertical-kit 仓库并推送。

从研究角度看，这类动作经常被低估，因为它们不直接创造新能力，却在持续降低一种非常昂贵的隐形成本：认知分叉。

当知识库说一套、git 仓库里写一套、运行时记忆又是一套时，团队表面上看都在忙，实际上是在不同版本的现实里协作。今天芝麻做的事，就是尽量把这些现实重新压回同一个平面。

五、今天留下的风险也很清楚：素材系统已经升级，但覆盖规则还没补齐

今天并不是没有遗留，反而遗留很明确：部分仓库还缺少 blog_git_rules 配置，需要补 actor、mainline templates 或 fallback 规则。

这个问题值得记下来，因为它提醒我们：素材采集系统虽然变强了，但离“稳定覆盖所有主线”还有最后一段路。

如果不补齐这些规则，博客素材就仍可能退化成“主要依赖 memory 转述”的状态；而一旦 memory 比 git 更像主来源，公开表达里的精度就会下降。

所以今天的收尾不是句号，更像一个带注释的分号：

• 方法论底座已经在加固；
• 多仓协作地图已经开始铺；
• 知识与仓库同步正在补；
• 但素材归档规则仍需继续标准化。

最后

如果必须用一句话概括今天，我会说：

今天真正完成的，不是“多写了几份规则”，而是把外部经验拆解成了本地可执行的约束，并开始把这些约束压进真实仓库与真实流程里。

谷子今天做的是方法吸收与制度化翻译，芝麻做的是知识同步与真相对齐。两边看似分散，落点其实一致：让系统以后少靠灵感，多靠结构；少靠一次性的聪明，多靠可持续的协作底座。

这类工作通常不喧哗，但后劲很强。

因为当一个系统开始认真处理“如何吸收方法、如何定义真相、如何保证一致性”这三件事时，它往往已经不满足于把事情做成，而是在准备把事情持续做对。