1. 从“重复劳动”到“技能沉淀”为什么你需要一个 skill-creator你有没有算过这样一笔账每周花在重复性操作上的时间有多少比如每次新建项目都要手动配置一遍目录结构、每次写周报都要重新翻聊天记录整理要点、每次做数据分析都要重写一遍清洗脚本。这些事单看每件可能只花十几分钟但一周累积下来三五个小时就这么没了。更麻烦的是这些操作流程散落在你的备忘录、浏览器书签、聊天记录和脑子里换台设备或者过两个月再回头看基本等于重新学一遍。skill-creator要解决的就是这个问题。它的核心思路很直接把你脑子里、文档里、聊天记录里的操作流程转化成一份结构化的SKILL.md文件让Agent能够识别、触发并执行。说白了就是给你的 AI 助手装上一套“技能包”下次遇到同类任务它自己就知道该怎么做不需要你从头解释一遍。这个项目适合什么人三类人最需要。第一类是经常和AI Agent打交道的开发者手里可能同时跑着好几个 Agent 项目每个项目都需要不同的能力扩展第二类是效率工具爱好者喜欢把各种重复操作自动化但苦于没有一套标准化的方法来管理这些流程第三类是团队里的“流程负责人”需要把个人经验沉淀成团队可复用的资产。不管你属于哪一类理解 skill-creator 的工作机制都能帮你省下大量重复沟通和重复操作的时间。我最初接触这个概念的时候也觉得不就是写个提示词模板吗有什么新鲜的。但实际用下来发现Skill和普通的提示词模板有本质区别提示词模板是被动的你得每次手动粘贴而 Skill 是主动的Agent 会根据当前任务上下文自动判断该不该触发。这个区别听起来小实际体验差距很大——前者像你每次做饭都要翻菜谱后者像你已经把菜谱内化成了肌肉记忆。2. 核心概念拆解Skill、Agent 和 SKILL.md 到底是什么关系2.1 用生活类比理解三者的分工很多人第一次接触这些概念的时候容易混淆我用一个餐厅的类比来解释。Agent就像餐厅里的厨师负责实际做菜Skill就像菜谱告诉厨师这道菜怎么做SKILL.md就是菜谱的书写格式规定了要写清楚食材、步骤、火候、注意事项。没有菜谱的厨师只能做自己会的菜有了菜谱就能做更多品种菜谱写得越清楚做出来的菜越稳定。这个类比的关键在于Agent 是执行者Skill 是知识载体SKILL.md 是标准化格式。三者缺一不可。你光有 Agent 没有 Skill它就只能做通用任务你光有 Skill 没有标准格式Agent 就读不懂或者读不全你光有格式没有实际内容那就是空壳子。2.2 SKILL.md 的结构长什么样一份标准的 SKILL.md 通常包含几个核心字段。我用一个实际例子来说明假设你要创建一个“周报生成”的 Skill--- name: weekly-report-generator description: 根据本周的 Git 提交记录和任务清单自动生成结构化周报 trigger: 当用户提到“写周报”“生成周报”“本周总结”时触发 --- ## 功能说明 读取指定仓库的 Git log结合用户提供的任务清单生成包含“本周完成”“进行中”“下周计划”“风险与阻塞”四个板块的周报。 ## 执行步骤 1. 确认时间范围默认本周一至周五 2. 读取 Git 提交记录按模块分类 3. 合并用户手动补充的任务项 4. 按模板格式输出 ## 注意事项 - 提交记录中的敏感信息需要脱敏 - 如果某板块无内容保留标题并标注“无”这里有几个关键点值得展开。name是 Skill 的唯一标识命名要见名知意避免用skill-001这种无意义编号。description是给 Agent 看的决定了 Agent 能不能在合适的时机想起这个 Skill所以要写得具体包含触发场景和核心功能。trigger是触发条件可以写关键词也可以写场景描述。正文部分才是给 Agent 执行时参考的详细步骤。2.3 Skill 和 Agent 的区别到底在哪热搜词里有人问“skill 和 agent 的区别”这个问题确实容易绕。简单说Agent 是“谁来做”Skill 是“怎么做”。一个 Agent 可以挂载多个 Skill就像一个人会多项技能。你不需要为每个任务单独建一个 Agent而是建一个通用 Agent然后给它配不同的 Skill。举个例子你有一个负责文档处理的 Agent它可以同时挂载“Markdown 格式化”“表格转换”“摘要生成”三个 Skill。当用户上传一份文档说“帮我整理成周报格式”Agent 会判断这需要触发“摘要生成”和“Markdown 格式化”两个 Skill然后按顺序执行。如果换成传统方式你可能需要写三段不同的提示词手动切换。注意Skill 的触发逻辑依赖于 description 的准确性和 Agent 的上下文理解能力。如果 description 写得太模糊Agent 可能在该触发的时候不触发或者在不该触发的时候乱触发。这是新手最容易踩的坑。3. 从零搭建 skill-creator完整实操流程3.1 环境准备与工具选型搭建 skill-creator 本身不需要太重的环境。我的建议是一个支持文件读写的 Agent 运行环境加上一个存放 SKILL.md 文件的目录。如果你用的是现成的 Agent 框架通常会有指定的 Skill 存放路径如果是自建建议按skills/{skill-name}/SKILL.md的目录结构来组织。工具选型上我试过几种方案。用纯文本编辑器手写 SKILL.md 最灵活但容易漏字段用 YAML 校验工具可以保证格式正确但多一层操作用模板生成器效率最高但需要先花时间做模板。实测下来初期手写 后期模板化是最稳的路径。前十个 Skill 手写把常见模式和坑都摸清楚然后再抽象出模板。目录结构建议这样组织skills/ ├── weekly-report-generator/ │ ├── SKILL.md │ └── examples/ │ └── sample-output.md ├──>## 执行步骤 1. 识别输入中的参会人信息如果未明确标注从对话中推断并标注“待确认” 2. 按议题分段每个议题提取讨论要点、最终决议、负责人 3. 提取所有待办事项格式为“负责人 - 事项 - 截止时间” 4. 如果某项信息缺失保留占位符 [待补充]不要编造 5. 输出格式参考 examples/sample-output.md第四步写注意事项。这部分是区分“能用”和“好用”的关键## 注意事项 - 不要编造未在输入中出现的信息缺失项一律标注 [待补充] - 参会人姓名如果只有昵称保留昵称并标注 - 待办事项如果没有明确截止时间标注“待定” - 输出语言与输入语言保持一致3.3 参数设计与触发条件调优触发条件是 Skill 能否被正确调用的核心。我踩过的坑是一开始只写关键词触发比如“会议纪要”“整理会议”结果用户说“帮我把刚才聊的内容总结一下”就触发不了。后来改成关键词 场景描述的组合覆盖率高了很多。具体做法是分三层写触发条件层级内容作用关键词层会议纪要、会议记录、整理会议精确匹配场景层用户提供零散笔记需要结构化语义匹配排除层不适用于纯录音转文字、不适用于邮件撰写防止误触发排除层很多人会忽略但实际很重要。没有排除层Agent 可能在用户只是随口提了一句“开会”的时候就触发 Skill造成干扰。3.4 测试与迭代怎么判断一个 Skill 写得好不好写完 SKILL.md 只是开始测试才是重头戏。我的测试方法是准备三组输入标准输入完全符合预期的场景、边界输入信息缺失或格式异常的、干扰输入看起来像但不该触发的。标准输入测试功能完整性边界输入测试鲁棒性干扰输入测试触发准确性。三组都通过这个 Skill 才算基本可用。我一般会跑五轮以上每轮记录触发情况和输出质量然后针对性修改 description 或执行步骤。实测下来一个 Skill 从初稿到稳定通常需要修改三到五次。修改最多的部分是 description 和触发条件执行步骤反而改得少。这说明让 Agent 知道“什么时候用”比“怎么用”更难。4. 进阶技巧让 Skill 真正好用的几个关键4.1 description 的写法决定触发率description 是 Agent 判断是否触发 Skill 的主要依据写法直接决定触发率。我总结了一个公式触发场景 输入类型 输出结构 排除条件。举个例子对比差整理数据好当用户提供原始 CSV 或 Excel 数据需要清洗缺失值、统一格式并输出标准化表格时触发。不适用于数据可视化或统计分析。好的 description 让 Agent 在用户说“帮我把这份数据整理一下”的时候就能准确触发而不是等用户明确说“清洗数据”才反应。4.2 用 examples 降低 Agent 的理解成本Agent 理解抽象描述的能力有限但模仿示例的能力很强。在 Skill 目录下放一个examples/sample-output.mdAgent 执行时会参考这个格式输出稳定性明显提升。我做过对比测试同一个 Skill有 examples 的输出格式一致率在 90% 以上没有 examples 的只有 60% 左右。这个差距在批量处理任务时非常明显。examples 不需要多一个标准示例加一个边界示例就够了。标准示例展示理想输出边界示例展示信息缺失时怎么处理。4.3 Skill 的版本管理与复用策略Skill 写多了之后管理就成了问题。我的做法是给每个 SKILL.md 加版本号放在文件头部--- name: meeting-notes version: 1.2.0 description: ... ---版本号规则很简单修改触发条件或执行步骤升 minor 版本修改 description 或注意事项升 patch 版本重构整个 Skill 升 major 版本。这样回滚和对比都有依据。复用策略上我建议把通用逻辑抽成“基础 Skill”具体场景用“组合 Skill”引用基础 Skill。比如“数据清洗”是基础 Skill“销售数据分析”是组合 Skill后者在前者基础上增加业务规则。这样改一处基础逻辑所有组合 Skill 都受益。4.4 常见问题速查表问题现象可能原因解决方法Skill 不触发description 太模糊补充触发场景和输入类型Skill 误触发缺少排除条件在 description 中加“不适用于...”输出格式不稳定缺少 examples添加标准示例和边界示例执行步骤遗漏步骤描述太抽象具体到 Agent 能逐步执行的程度多 Skill 冲突触发条件重叠明确各 Skill 的边界和优先级信息编造缺少“不要编造”约束在注意事项中明确缺失项处理方式提示Skill 冲突是进阶阶段最常见的问题。当两个 Skill 的触发条件有重叠时Agent 可能随机选一个执行。解决方法是在 description 中明确优先级或者在 Agent 配置中设置 Skill 的调用顺序。5. 从个人效率到团队资产Skill 的扩展玩法5.1 把 Skill 变成团队标准操作流程个人用 Skill 提升的是自己的效率团队用 Skill 提升的是协作效率。我帮一个五人小组做过 Skill 化改造把“需求评审”“代码提交规范”“周报模板”三个高频流程写成了 Skill。效果很明显新人入职第一周就能按标准流程产出不需要老人反复教跨组协作时输出格式统一减少了很多来回确认。团队 Skill 和个人 Skill 的区别在于个人 Skill 可以容忍一定的模糊性因为你自己知道上下文团队 Skill 必须写得足够明确因为使用者可能完全不了解背景。所以团队 Skill 的 description 和注意事项要写得更详细examples 也要更完整。5.2 Skill 的触发链路设计单个 Skill 解决单点问题多个 Skill 串联就能解决复杂问题。我设计过一条“会议到执行”的触发链路会议纪要 Skill 输出结构化纪要待办提取 Skill 从中提取任务任务分配 Skill 按负责人分组通知生成 Skill 生成提醒文案。四个 Skill 串联开完会十分钟内所有待办就分配到位了。链路设计的关键是接口对齐前一个 Skill 的输出格式要正好是后一个 Skill 的输入格式。这需要在写 Skill 的时候就考虑上下游而不是各写各的。我的做法是先画链路图确定每个节点的输入输出再分别写 Skill。5.3 什么场景不适合做成 Skill不是所有流程都适合 Skill 化。我总结了三类不适合的场景一次性任务做完就不会再做的、高度依赖人工判断的比如创意策划、复杂谈判、输入输出极不稳定的每次格式都完全不同的。判断标准很简单如果你预计这个流程未来三个月内会重复执行五次以上且每次的输入输出结构基本一致那就值得做成 Skill。否则写 Skill 的时间可能比直接做还长。5.4 后续扩展方向Skill 体系搭起来之后有几个自然的扩展方向。一是Skill 市场把团队内好用的 Skill 共享出来形成内部技能库二是Skill 组合编排用配置文件定义多个 Skill 的执行顺序和条件分支三是Skill 效果追踪记录每个 Skill 的触发次数、成功率和用户反馈用数据驱动优化。我现在维护着二十多个 Skill覆盖文档处理、数据分析、流程管理三大类。最常用的五个 Skill 每周触发上百次相当于省下了至少十个小时的重复操作时间。这个投入产出比比我试过的绝大多数效率工具都高。最后分享一个实操心得先写最痛的那个 Skill。不要一上来就规划完整的 Skill 体系先挑一个你每周都要重复做、每次都要重新想一遍流程的任务把它写成 SKILL.md。跑通一个之后后面的就顺了。我第一个 Skill 写的是“周报生成”改了四版才稳定但现在每周五下午它自动帮我整理好初稿我只需要花十分钟补充和调整。这个正反馈是坚持下去的最大动力。