用户自撰技能

在设计它之前，先把你要交付的东西叫清楚。

一套被保存下来的指令，有四项「聊天框里的提示词」所没有的性质，而其中每一项都是一项工程义务，不是一点体面。

• 它是持久的，所以它活得比作者的上下文更久。写下「货币一律按英镑格式，并默认是曼彻斯特办公室」的那位用户知道为什么。九个月后继承它的那位同事不知道，模型也不知道。
• 它有名字，所以名字会撞车。同一作用域里两个都叫 summary 的技能，是一个路由缺陷，不是用户的错。如果调用靠斜杠命令，那么命名空间现在就是你产品界面的一部分了。
• 它可组合，所以冲突是常态。把一个品牌口吻技能和一个法务审查技能叠起来，产出的是一段两位作者都没读过的提示词。谷歌的 Skills 明确支持叠加，正是出于这个原因——这意味着「优先级」已经是一项上线了的行为，无论你是否设计过它。
• 它是可执行的文本，所以它是一项能力。一个让智能体去调用工具、抓取 URL 或往某个系统写入的技能，与代码无从区分，而它是经由一个没有任何审查步骤的文本域进来的。这与智能体技能是同一个论点，只是高了一个海拔。

请注意这张清单上没有的那一项：质量。用户会写出糟糕的指令，而这没关系——一个糟糕的技能产出一个糟糕的答案，用户随即把它改掉，这是一个健康的循环。上面那四项才是会无声失败、且代价由别人承担的那些。

调用方式才是那项产品决定，而「显式」胜过「聪明」。

一个被保存的技能进入对话有两条路，而它们朝相反的方向失败。显式调用——用户键入 /brand-voice——是确定的、可调试的、可读的：用户知道加载了什么，而你也知道，就在链路里。隐式选择——由模型读描述、自行判断哪些技能相关——奏效时像魔法，不奏效时无从解释，因为那种失败是一次检索未命中，而检索未命中从构造上就是看不见的。

谷歌上的是显式：技能从提示栏里的一个斜杠触发。对用户自撰的内容来说，这是正确的默认，而理由不是延迟或成本。而是：隐式选择让描述成了那个承重字段，而用户不会为一个检索器写描述——他们是为自己写名字。「周一那个」是一个完全好用的名字，也是一把毫无用处的检索键。那套让隐式技能选择在工程师自撰技能上行得通的机制（那里的描述是当作索引写的），一旦作者是在为自己的记忆做优化，就会垮掉。

# Invocation models, and what each one costs you

EXPLICIT   /skill-name typed by the user
  + deterministic, appears in the trace verbatim
  + a wrong result is debuggable by the user
  - discovery problem: unused skills stay unused
  - no help on the turn where the user forgot

IMPLICIT   model picks from skill descriptions
  + works on the turn the user did not think about it
  - failure mode is a silent retrieval miss
  - description quality is the ceiling, and users
    do not write descriptions for retrievers

HYBRID     explicit invocation + a suggestion chip
  + keeps determinism, fixes discovery
  + the suggestion is a visible, declinable act
  - one more surface to design

这件事应该落在混合方案上。触发继续用显式，而「发现」靠一条可见的建议来解决——「你有一个技能适合这个：周报」——由用户接受或忽略。这条建议很便宜、它顺手教会了用户这个功能，而关键在于它把决定留在了用户看得见的地方，而这正是渐进披露的全部论点。

在用户替你发现之前，先把优先级定下来。

叠加是用户会要求的那个功能，也是会生出工单的那个。两个技能同时加载，一个说「回复控制在 150 词以内」，一个说「一定要带一个实作例子」——而模型靠「谁恰好在上下文里更靠后」来裁决，而这是一个你并不打算当成产品规则暴露出去的实现细节。

你需要一套写明的优先级次序，而且它必须在界面里可见，而不是记在帮助中心里。一个可用的默认，从强到弱：系统与安全策略，然后是组织发布的技能，然后是本轮里最近一次被调用的技能，然后是更早的技能按调用顺序，最后是用户的常设偏好。次序本身不如「它被写下来并被渲染出来」这件事要紧——至于为什么只有分层方案才能在多作者的接触中存活，见指令层级。

然后为你解决不了的那类冲突做设计。当两个已加载的技能在一个实质点上互相矛盾时，正确的行为几乎从来不是无声裁决。而是把它说出来：「周报」要求 150 词以内，而「可交付客户」要求带一个实作例子——我保留了例子，稍微超了一点。这句话花十五个令牌，却避免了用户对一个他马上要依赖的系统形成错误心智模型，而这正是透明度与可解释性的内核。

作用域与分享：一个技能跨出账号的那一刻，它就需要一道审查。

个人技能是一项偏好，不需要治理。有意思的问题从第二个作用域开始，而值得建的只有三个。

• 个人。只对一个用户可见，无审查、无批准。把它当成一次保存的搜索来对待。唯一的义务是导出——离职的用户应当能把自己的技能带走，被删除的用户应当把它们一并带走。
• 按链接或复制分享。供应链就是在这里出现的。一个从同事那儿粘过来的技能，携带着接收方没读过的指令，而它是用接收方的工具与权限执行的。在首次使用前每次都展示全文，并且绝不从链接自动安装。这里相关的威胁不是恶意，而是继承：一个为只读权限者写的技能，到了一个能写的人手里，行为就不一样了。
• 组织发布。需要归属人、一道评审、一份变更历史和一条吊销路径——也就是与任何其他内部工具相同的生命周期。向同事发布是一项特权，不是一个分享动作；而真正要紧的那道控制是：管理员能看到完整清单并能移除某一条。这与智能体清册与登记的登记义务相同，只是把对象从服务换成了文本。

有一条规则覆盖了大部分风险，而且容易陈述：一个技能可以要求智能体去做调用它的那位用户本来就能做的任何事，仅此而已。这听着显而易见，而它被例行违反——因为技能常常被渲染进提示词中一个特权位置，在用户自己那一轮之上；而在多数外壳里，那个位置给它买到了比用户文本更高的权重。如果一个技能的文本比它的作者更有权威，那你就从一个文本域里造出了一条权限提升路径。请在结构上、在承载它们的那条消息里，把用户自撰技能渲染为用户权限。

你会欠一次迁移。谷歌这次就是那个范本。

指令格式会被替换，而那次替换是一场带截止日期的用户数据迁移，不是一则弃用通告。谷歌 2026 年 10 月从 Gems 切到 Skills，是值得研究的那个标本，因为它把难的那几处做对了，而那些日期恰好告诉你难处在哪里。

# Gems -> Skills, as announced (Oct 2026)

mechanism        existing Gems auto-migrated to Skills
invocation       "/" + name in the prompt bar
composition      multiple skills stack in one turn
authoring        create from an existing conversation

# Access to the old format ends

personal accounts                     November 2026
Workspace business / enterprise / NFP   March 2027
education accounts                       June 2027

# What the staggering tells you

consumer     ~1 month   -> individuals re-learn quickly
business     ~5 months  -> someone has to re-test workflows
education    ~8 months  -> curricula are annual, not quarterly

有三件事值得照抄。自动迁移而不是去问——一场需要每个用户动手的迁移，就是一场会把大多数内容搁在岸上的迁移。按「重新测试有多贵」来错开，而不是按人群有多大；商业与教育的窗口更长，是因为别人的流程依赖那份输出。以及允许从既有材料里撰写新格式：从用户本来就有过的一段对话里生成一个技能，是可能存在的最便宜的撰写路径，这也正是「迁到新格式」不必成为一个单独项目的原因。

而该补上的那一样——公开公告并没有承诺——是一份保真度报告。一次无声丢字段的自动迁移（某个 Gem 的附件、一项没有对应物的语气设置），会产出一个看着没问题、行为却不同的技能，而用户会把这次回退归因于模型。请在迁移时一次性告诉每位用户：什么被搬过来了、什么换了形态、什么没能带过来。然后让旧材料在截止日之后仍可阅读、即便已不可运行，理由见模型弃用与迁移。

只上三个数字的仪表，就三个。

技能能生出一大堆可测的东西，而其中几乎全是虚荣指标。有三个数字能告诉你这个功能是否在起作用，而每一个都挂着一项具体的决定。

• 复用深度：每个技能的调用次数，看分布而不是均值。健康的形状是少数几个技能各被调用很多次。一条「恰好只用过一次」的长尾，意味着用户在撰写而不是在提示——这个功能是在加一个步骤而不是减一个；而解法通常是：创建入口相对于调用入口过于显眼。
• 调用后的改写率。技能触发之后，用户立刻重写或重问的频率。这是你的质量信号，而且远胜于一个点赞按钮，因为它是不请自来的，而且精确指向刚跑过的那个技能。高于同期基线的技能，就是文本有问题的技能，而你能告诉它的作者。
• 每个被分享技能的跨账号安装数。这是那个供应链数字。一个技能扩散到几百个账号，就是一项未受管理的内部标准；而正确的反应是给它的作者提供一条「正式发布」的路径，而不是等某位管理员哪天发现它。

不要测的是：技能创建总数。功能好用时它会涨，功能把人搞糊涂时它也会涨，所以它什么都回答不了。另外，别在没有反事实的情况下把质量变化归因给技能——一位写了六个技能之后答案变差的用户，可能是写了六个糟糕的技能，也可能是撞上了一个被这些叠加指令吃掉的上下文预算。把每一轮组装后的提示词长度记下来，你就分得出区别。