基于时序模型与多维特征融合的 GPU 集群容量预测：从规则估算到 AI 决策
2026/7/16 18:56:45
本文是《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目录名用于标识 Skill；SKILL.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.md； - YAML 头是否位于文件最上方，并由
---包围； 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 划分不同专家的职责。