Skip to main content
工具决定专家能做什么，技能决定它做得好不好。 技能是一份告诉专家「这类活该怎么干」的结构化文档，通常还附带可执行脚本、模板和参考资料。同一个模型、同一套工具，配不同的技能会产出完全不同质量的结果——差别就在于有没有人把方法写下来。

​
技能长什么样

技能的入口是一份 SKILL.md，头部有 YAML frontmatter：
description 尤其关键：它是专家决定要不要激活这个技能的唯一依据。写「用于分析」不如写「用户要求对比多个产品时」——后者给出了触发条件。 技能目录里还可以放：
脚本是黑盒：专家被明确要求不去读脚本源码，只调用它、看输出。这让技能作者可以把复杂逻辑封装进脚本，而不用担心它被模型「读一遍然后自己重写一个错的」。

​
渐进披露：为什么不是全部塞进上下文

平台内置约 57 个技能。如果全文注入，上下文预算在第一轮就没了。 实际流程分三步：
1

discover：只看名字和描述

专家拿到的是一行行 - **限定名** [标签]: 描述，成本极低。可以按标签过滤。
2

activate：读全文

确定要用哪个之后才载入完整 SKILL.md，以及 frontmatter 里声明为自动加载的参考文件。
3

execute：跑脚本或读参考

按需调用技能目录里的脚本与参考文档。
这条链路的意义：你不需要为「专家知道有这个技能」付全文的钱，只在真正用到时付。

​
三路归属

一次对话可用的技能是三个来源的并集，互不覆盖： 同名不冲突：builtin/pptx、user/pptx、expert/pptx 可以同时存在。专家看到的是限定名，激活时必须写全——裸名在多路同名时会被拒绝解析，而不是猜一个。 写入口按归属严格分离：
自由对话里让专家「把这个方法存成技能」会失败。 技能创建工具需要专家上下文，无专家的自由对话、IM 渠道都拿不到——此时它会引导你去界面里手动存进全局库。这不是 bug，是归属约束：没有专家，这条技能不知道该属于谁。

​
技能与插件的分工

这是最容易混淆的一对概念： 很多内置插件是成对出现的：插件带工具，技能带方法。比如 PDF 插件同时携带 builtin/pdf（处理）与 builtin/kami（排版创作）两个技能。

​
上下文成本

每个激活的技能都要占上下文。三条经验：
  1. 全局库别当收藏夹。 装 30 个技能，每轮 discover 都要列 30 行描述。只留真正常用的。
  2. 技能正文越长，激活成本越高。 进化系统专门有一个维度盯着技能字数（由代码计算而非模型自评），就是为了防止「越进化越臃肿」。
  3. 参考文档按需读，不要全设自动加载。 自动加载的参考在激活瞬间全量进上下文。

​
创作者视角

对创作者来说，专家专属技能是核心差异化资产——同样的模型和工具人人都有，方法是你的。 写技能的三条实操建议：
  • 描述写触发条件，不写功能罗列。 专家靠描述判断要不要激活。
  • 约束比步骤更值钱。 「不要做什么」通常比「怎么做」更能提升下限。
  • 把确定性的部分下沉到脚本。 能用代码保证的事（格式转换、坐标计算、校验），不要指望模型每次都想对。
进化系统会基于真实运行数据给出技能改进建议，双棘轮保证接受的改进必须质量不降且效率提升——详见自进化。

​
失败与对策

​
继续阅读

技能目录

全部内置技能一览

插件

工具层：专家能做什么

自进化

技能怎么被自动改进

配置你的专家

创作者侧的技能管理