技能演化：brain 的技能怎么随你一起长

你用 brain 久了，会发现有些事反复做：把一本书镜像成你的版本、追踪某个想法的演变、给 schema 加新类型。gbrain 把这些「反复做的事」做成技能（skills），而且它们的设计让 brain 能随你的使用自我进化。这一课讲 gbrain 的技能到底怎么长出来、怎么不退化。

一、技能是什么：可复制的 markdown 程序

gbrain 的技能是放在 skills/ 下的 markdown 文件，每个是一段带指令的程序。它和「写进核心代码」相反——技能是散在 markdown 里的、可以被 agent 读一次就照做的操作手册¹。好处是：你能直接 copy-paste 一个技能到自己的仓库，不用懂 gbrain 内部。这正是它「胖技能瘦壳（fat skills, thin shell）」哲学的体现——核心保持精简，能力长在技能里¹。

对使用者最实在的意义：想要个新能力，先看社区有没有现成技能，复制过来就能用，而不是等核心更新。

二、RESOLVER：意图到技能的路由表

几十个技能，agent 怎么知道「用户这句『追踪这个想法的来龙去脉』该调哪个」？gbrain 用一个 RESOLVER.md 路由表——里面是一张「用户意图 → 技能路径」的表，agent 读一次就全知道²。比如「how has my thinking about X 演变」/「show reversals in my thinking」映射到 idea-lineage 技能；「evolve my schema」/「add a type」映射到 schema-author 技能。

这个表是可进化的：你加了新技能，就在表里加一行。路由逻辑不焊在代码里，而在可读的 markdown 里。你造自己的工具时，这种「意图路由用一张表维护」比写一堆 if-else 好维护得多。

三、skill-brain-first：技能必须讲清它怎么用 brain

gbrain 有个 doctor 检查（doctor 是个本地自检命令，像体检）叫 skill_brain_first：它要求每个技能在文档里明确声明「我怎么调用 brain」——要么写一句 > **Convention:** ... brain-first ... 调用约定（compliant），要么在 frontmatter 标 brain_first: exempt 明确退出（exempt）³。没声明的一律被标记，逼作者讲清立场。

为什么要这个？因为技能如果不说清「它读/写哪个 brain 操作」，使用者（和 agent）就不知道它会不会乱动你的知识库。gbrain 把「技能与 brain 的边界契约」做成可机器检查的健康项，而不是靠人记——这是它治理「一大堆散落 markdown 技能」不乱套的关键。

四、schema-author：让 schema 随使用自我进化

最体现「演化」的技能是 schema-author：它的 RESOLVER 入口含 evolve my schema、add a type、backfill page types、propose new types from my corpus——意思是，当你发现 brain 里出现了没归类的新内容，这个技能能从你的语料里提议新类型、回填旧页、扩展 schema⁴。也就是说，brain 的分类体系不是一次定死的，而是用着用着、被技能推着长。

五、一个建筑师记下的

gbrain 的技能系统是它最值得抄的架构之一：能力长在可读的 markdown 里（可复制、可路由、可体检），核心保持瘦。它用 RESOLVER 表做意图路由、用 doctor 健康检查强制技能声明边界、用 schema-author 让数据结构自我演化。你造工具时，别把所有逻辑塞进核心，把「能长出来的部分」外置成可检查的程序。

六、这一课带走的

• 技能是 skills/ 下的 markdown 程序，可复制，能力外置（胖技能瘦壳）。
• RESOLVER.md 是意图→技能的路由表，加技能=加一行，路由不焊死在代码。
• skill-brain-first 强制每个技能声明怎么用 brain，由 doctor 机器检查，防技能乱动知识库。
• schema-author 技能能从你的语料提议新类型、回填旧页，让 schema 自我进化。

练习题

参考出处