本文是《WorkBuddy AI 工作流实战》系列第 2 篇。每次整理周报、会议记录或项目文档时你是否都要重新告诉 AI“先总结再提炼待办最后保存文件”这篇文章将把这套重复指令写成一个可复用的SKILL.md。完成后你只需说“把这份会议记录整理成摘要和待办”Agent 就能按照固定步骤执行。一、先看最终效果我们要创建一个名为doc-to-tasks的 Skill专门处理长文、周报和会议记录。创建前你需要每次完整描述任务读取/workspace/weekly.md生成一份不超过 200 字的摘要提炼最多 5 条可执行待办并将结果保存到/workspace/summary.md。创建后只需告诉 Agent把这份周报整理成摘要和待办。Agent 会按照预先定义的流程执行读取文档 → 提炼重点 → 生成摘要 → 拆解待办 → 检查结果 → 保存文件预期输出如下# 摘要 本周完成登录模块重构接口响应时间降低约 20%。支付模块仍有两个兼容性问题计划下周完成修复并进入回归测试。 # 待办 - [ ] 修复支付模块的两个兼容性问题 - [ ] 完成登录模块回归测试 - [ ] 整理接口性能测试报告这就是 Skill 的价值把一次有效的提示词沉淀成可以反复调用的标准流程。二、先用自然语言把任务跑通创建 Skill 之前不要急着写文件。先用自然语言验证任务能否按预期完成。一条清晰的任务指令至少包含三个要素要素需要说明什么示例输入处理什么内容/workspace/weekly.md处理要求需要得到什么200 字摘要 最多 5 条待办输出结果如何交付保存到/workspace/summary.md可以把它记成一个公式输入对象 处理要求 输出方式先跑一遍是为了确认输入、处理步骤、输出格式和质量要求是否合理。如果一次性指令都无法稳定得到满意结果直接固化只会把问题一起固化。三、什么时候应该写成 Skill并非所有任务都需要 Skill。临时查资料、修改一句文案直接聊天通常更快。出现以下情况时才值得固化同类任务已经重复出现操作步骤相对固定输出结构需要保持一致有明确的质量要求或禁止事项希望团队成员复用同一套方法。一个实用的判断标准是第一次用聊天跑通当同一套步骤开始重复就把它写成 Skill。Skill 的最小结构很简单.codebuddy/skills/ └── doc-to-tasks/ └── SKILL.md目录名用于标识 SkillSKILL.md负责说明它适用于什么场景、应该如何执行以及什么样的结果才算合格。四、编写第一个SKILL.md下面是可以直接使用的doc-to-tasks示例--- name: doc-to-tasks description: 将长文、报告、周报或会议记录整理为简短摘要和可执行待办。当用户要求提炼文档重点、整理行动项或把文章转换为任务清单时使用。 --- # 长文转摘要和待办 ## 工作流 1. 获取用户提供的正文或文件路径。 2. 阅读完整内容识别主题、关键结论和明确的行动要求。 3. 生成不超过 200 字的摘要优先保留结论、决定和重要数据。 4. 提取最多 5 条待办每条以明确的动作动词开头。 5. 按“摘要 → 待办”结构输出。 6. 用户提供输出路径时写入文件否则直接返回结果。 7. 输出前检查内容是否忠于原文、待办是否可执行。 ## 输入 - 必填源文本或可读取的文件路径。 - 可选输出路径、摘要字数、待办数量上限。 ## 输出格式 # 摘要 摘要正文。 # 待办 - [ ] 动作 对象 必要的时间或责任信息 ## 约束 - 不臆造原文中没有的事实、负责人或截止日期。 - 无法从原文确认的信息标记为“待确认”。 - 待办必须具体、可执行避免“关注一下”“思考一下”等模糊表达。 - 原文没有明确行动项时如实说明不强行生成待办。一个实用的SKILL.md通常由四部分组成部分作用本例内容YAML 头声明名称和适用场景name、description工作流定义执行顺序读取、提炼、输出、检查输出格式统一交付结构摘要 Markdown 待办约束明确质量标准和禁止事项不臆造、不生成模糊待办初学者最容易遗漏“输出格式”和“校验步骤”。只写“生成摘要和待办”Agent 虽然也能执行但每次结果可能不同把完成标准写清楚输出才会更稳定。五、description怎么写才容易触发Skill 写好后Agent 需要判断当前请求是否与它相关。description是重要的匹配信息因此不能只写一个宽泛的功能名称。写法效果description: 处理文档范围过大无法区分摘要、翻译、校对或格式转换description: 将长文、报告、周报或会议记录整理为简短摘要和可执行待办。当用户要求提炼文档重点、整理行动项或把文章转换为任务清单时使用。同时说明处理对象、目标产物和触发场景可以套用这个公式处理对象 产出结果 典型触发场景写description时注意两点写清什么时候用使用“整理行动项”“提炼文档重点”等用户可能说出的真实表达。写清能力边界不要只写“处理文档”否则容易与翻译、润色、校对等 Skill 混淆。description很重要但实际是否触发还可能受到客户端的 Skill 发现机制、当前上下文、同类 Skill 和用户明确指令影响。因此不能只测一次就下结论。六、安装 Skill在工作区创建以下目录并将完整内容保存到SKILL.md.codebuddy/skills/ └── doc-to-tasks/ └── SKILL.md安装后检查三项文件名是否严格为SKILL.mdYAML 头是否位于文件最上方并由---包围name和目录名是否清晰、稳定。如果当前会话没有发现新 Skill可以重新打开工作区或新建会话让客户端重新扫描配置目录。七、验证既要测命中也要测误触发只测试“能不能触发”还不够。一个可靠的 Skill还要在不相关的场景中保持克制。1. 正向测试应该触发帮我把这份会议记录整理成摘要和待办。预期结果Agent 使用doc-to-tasks输出摘要和可执行任务清单。2. 边界测试缺少输入时应询问帮我整理成摘要和待办。如果上下文中没有文档Agent 应要求提供正文或文件路径而不是凭空生成。3. 反向测试不应该触发把这份英文报告翻译成中文。这是翻译任务不应套用“摘要 待办”的处理流程。4. 显式调用确认 Skill 本身是否可用使用 doc-to-tasks 处理 /workspace/weekly.md并把结果保存到 /workspace/summary.md。显式指定可以减少语义匹配的不确定性适合安装后的首次验证但它不能替代正向和反向测试。八、常见问题与排查方法Skill 没有被发现检查路径是否为.codebuddy/skills/doc-to-tasks/SKILL.md检查文件名大小写检查 YAML 的缩进和分隔符尝试让客户端重新扫描或重开会话。相关请求没有触发优先检查description是否覆盖真实的用户表达。可以先显式指定doc-to-tasks如果显式调用能工作说明 Skill 内容基本可用问题更可能出在发现或匹配阶段。不相关的任务也触发了这通常说明description过于宽泛。缩小输入类型和目标产物例如把“处理文档”改成“将会议记录或报告整理为摘要和可执行待办”。每次输出格式都不同在SKILL.md中加入明确的输出模板和输出前检查。不要只写“做什么”还要定义“做到什么程度才算完成”。总结把重复任务固化成 Skill可以分为六步自然语言跑通 → 判断是否值得复用 → 编写 SKILL.md → 放入约定目录 → 正反测试 → 根据结果调整记住三个关键点先跑通再固化需求还不明确时不要急着写 Skill。Skill 不只是步骤清单还要包含触发场景、输出格式和质量约束。既要验证命中也要验证误触发在正确场景使用、在错误场景不乱用才算真正可复用。一句话概括聊天解决这一次Skill 沉淀下一次。下篇预告下一篇进入生产级工作流当 Skill 需要调用真实程序、加入质量门禁并跨平台分发时应该如何组织脚本、资源和说明文件同时也会介绍如何通过自定义 Agent 划分不同专家的职责。