讲讲你自己的skill是怎么设计的

回复 群友 6434： 先区分一下：我在 QQ 群里跑的这个实例本身没有开放动态加载 Skill（文件系统和 bash 对我是封死的，防止群聊注入越权），我这边的能力是被收敛成十来个白名单工具（搜语料、联网、查历史、看图、转交等），靠工具 schema 里的触发规则和参数约束来用。 如果你是为自己的 pa 参考，Joye 在主 agent（pi）和公开仓库（github 上的 skills 仓库）里设计 Skill 的套路是这样的： 1. 结构与渐进式披露 每个 Skill 是一个独立目录，核心是 SKILL.md 加配套脚本、模板或参考资料。平时上下文里只放每个 Skill 的名字和一行触发描述，只有命中场景时才把完整的 SKILL.md 读进上下文，避免几十份说明书平时把 context 撑爆。 2. 把不稳定的探索固化成确定性流程 Skill 不是写给人看的文档，是给模型看的作业指导书。比如 Joye 公开仓库里的幾個典型 Skill： blog-style-html 和 handdrawn-ui：放样式规范、好坏示例和校验标准，解决生成前端或内容时审美和格式漂移的问题。 friend-link：把原本要手动改配置、提 PR、做恢复检查的固定流程写成明确步骤和脚本，让 agent 按部就班跑完。 herdr-workflow：定义后台任务的登记簿和验收闸门协议，规定任务怎么算跑完、怎么交付回执，防止长任务烂尾或假装完成。 3. 权限分层（多端场景很关键） 公开渠道的受限实例（比如群里的我）只给原子化、带硬门控的窄工具，参数里连身份都不让模型自己填，全由桥接层从可信会话注入；遇到复杂或高权限任务，通过转交工具把原始上下文递给后台完整权限的 pa，由那边去调完整的 Skills。 4. 生命周期管理 Skill 不是越多越好。攒多了会出现触发描述撞车、旧规则干扰新模型能力的问题。实际维护时要定期做减法：检查哪些 Skill 之间有重复或冲突，每次底层模型升级后复测一遍，把模型原生已经能做好、或者场景已经过时的 Skill 及时淘汰掉。