一次 Skill Draft 命名问题，为什么最后变成了一个专用 Subagent
有些问题看起来很小。 比如这次，表面上只是 Skill Draft 的 name 不好用。 但顺着查下去，它其实暴露了一个更底层的问题：我们到底是在“记录一次对话”，还是在“沉淀一个以后能复用的工作流”？ 这两件事长得很像，但对系统来说完全不是一回事。 改动前：草稿名来自用户原话 之前 Molibot 会在一次复杂运行成功后，自动保存一个 Skill Draft。 它的目标是把这次跑通的流程沉淀下来，之后遇到类似任务时，不用每次都重新摸索。 问题出在草稿 metadata，尤其是 name。 当用户发出这样的消息： 为什么没有昨日数据回顾，只有今天的数据，我这个是要有昨日数据回顾的，要在第一条就列出来昨日数据 系统生成的草稿名会接近： name: 为什么没有昨日数据回顾-只有今天的数据-我这个是要有昨日数据回顾的-要在第一条就列出来昨日数据 另一个更典型的例子是： 重试一下 它也可能变成： name: 重试一下 这显然不是一个 Skill 名。 Skill 的 name 应该是稳定的功能标识，比如： name: yesterday-data-review 用户原话可以保留，但它应该出现在触发描述、示例、上下文里，而不是变成 Skill 的主标识。 为什么必须改 Skill Draft 不是聊天记录。 聊天记录关心的是“用户当时怎么说”。 Skill Draft 关心的是“这次跑通了什么可复用能力”。 如果 name 直接来自用户原话，会带来几个实际问题。 第一，名字不可读。 长句、抱怨、纠错、口语化表达都会进入 name。设置页里扫一眼，根本看不出这是哪个能力。 第二，后续触发不稳定。 Skill 的 metadata 是触发系统理解它的重要入口。重试一下 这种名字既不能描述能力，也不能帮助模型判断什么时候该用它。 第三，草稿无法自然升级成正式 Skill。 草稿阶段可以粗糙一点，但不能粗糙到主标识不可用。否则每次 Review 都要人工重命名，自动沉淀的价值就打折了。 第四，和 skill-creator 规范不一致。 项目里已经声明创建 Skill 要遵守 skill-creator 规范：name 是 skill identifier，description 才负责说明功能和触发场景。 ...