从Prompt到Skill：AI工作台中可复用技能的创建与优化指南

在 AI 助手的使用过程中，很多人会遇到同一个尴尬：同样格式的日报、周报、代码审查、会议纪要，每次都要重新写一遍 Prompt。内容一次比一次长，规则一次比一次多，结果还是经常出现“AI 忘记了刚才的约定”的情况。WorkBuddy 这类 AI 工作台工具中的 Skill 机制，其实就是用来解决这个问题的。它可以把一段固定的指令、一套执行流程、一组输入输出规则打包成可复用的技能，遇到同类任务时直接触发，不需要反复调教。

这篇文章不打算做空洞的功能科普，而是围绕 WorkBuddy 的 Skill 全流程展开：怎么找、怎么装、怎么从零创建、怎么在实际工作中用起来，以及如何根据结果持续优化。无论你是第一次听说 Skill 这个概念，还是已经试过几个 Skill 但效果不稳定，这篇文章都值得读完。全程不依赖特定版本，重点讲清楚实现思路和踩坑点，你拿到自己的 WorkBuddy 环境里也能照着操作。

1. 背景：为什么需要 Skill 机制

1.1 从“每次重新交代”到“一次沉淀，反复使用”

过去用 AI 写材料，我们的习惯是“对话式临时指挥”。比如让 AI 帮你写一封项目周报，你需要告诉它：项目背景是什么、本周做了哪些模块、数据指标在哪里、周报格式是什么、语气要正式但不能太僵硬、不要出现口语化表达……这些问题在第一次调用时可以说清楚，但第二次、第三次依然要重复输入。如果换一个人来操作，还得重新理解你的表达习惯。

Skill 解决的正是这种“重复造轮子”的问题。它把任务执行需要的完整上下文固定下来，包括：

• 角色的定位，比如“资深前端工程师”或“项目周报助理”。
• 执行的步骤，比如先读取输入数据，再生成初稿，最后做格式校验。
• 输出的规范，比如必须使用 Markdown 表格、必须控制在 300 字以内。
• 典型的示例，帮助 AI 理解正确结果长什么样。

一旦封装完成，用户只需要输入一句触发词，或点击某个 Skill 图标，WorkBuddy 就会自动加载这套规则，按既定流程执行。对于花在“重复解释规则”上的时间，这是比较彻底的改进方式。

1.2 Skill 与 Prompt、插件、Agent 的区别

很多初学者会把 Skill、Prompt、插件、Agent 混为一谈。它们确实有交集，但在 WorkBuddy 的体系里需要区分开：

Skill 可以理解为“指令的工程化封装”。它不是简单地存一段文本，而是可能包含多个文件：指令文件、示例文件、参数定义文件，甚至绑定特定的插件能力。普通 Prompt 适合临时任务，而 Skill 适合高频、稳定、流程明确的任务。

1.3 你可能已经在用 Skill，只是没意识到

如果你用过一些 AI 平台的“自定义指令”“角色预设”“提示词模板”功能，其实你已经接触到了 Skill 的雏形。WorkBuddy 把它做得更完整的地方在于：Skill 不仅仅是一段文本，它还支持结构化的配置、版本更新和复用管理。

用一句话概括：Skill 是 AI 助手的“可安装技能包”。它让 AI 从“一个什么都会一点的通才”，变成“针对你的工作流能够稳定输出的专才”。

2. 环境准备与前置概念

2.1 你需要准备什么

开始之前，建议先明确你的使用范围。Skill 的创建、安装和优化，通常在图形界面中完成，但也可能需要接触本地文件。不同系统环境下的操作会有些差异，但核心流程是相通的。

你可以先准备：

• 一个能正常工作的 WorkBuddy 账号，并且已经安装并登录客户端。
• 一个用于测试的目录或项目，方便验证 Skill 的文件读写、输出路径等能力。
• 一份高频业务任务的记录，后面创建 Skill 时会直接用到。
• 如果使用 Git 导入 Skill，需要提前配置好 Git 环境，不过大部分场景并不强制。

2.2 版本差异的应对策略

不同版本的 WorkBuddy，Skill 管理入口名称可能不一样，有的叫“技能市场”，有的叫“Skill 管理”，有的在设置中提供“导入技能包”。为了避免教程过时，本文不会死记某一个按钮路径，而是描述核心逻辑。

你可以通过两个方式快速定位功能入口：

1. 在应用顶部搜索栏输入skill或技能，查看弹出的管理入口。
2. 在设置或插件中心中查找“技能”分类。

2.3 Skill 的典型文件结构

虽然 Skill 有两种形态：在线市场和本地导入，但一个 Skill 的内部结构通常是有规律的。以常见的本地 Skill 为例，它可能包含：

my-skill/ ├── skill.yaml # 技能元信息：名称、描述、触发词、版本 ├── instruction.md # 核心指令：角色、步骤、约束、输出格式 ├── examples/ │ ├── input-example.json # 输入示例 │ └── output-example.md # 期望输出示例 └── assets/ # 可选：辅助文件、模板、图片等

注意：具体文件格式和字段名会因为 WorkBuddy 版本升级而变化，但“元信息 + 指令 + 示例”的思路基本不变。你创建时如果工具提供了可视化表单，可以先填写表单，再在生成的模板基础上修改。

2.4 为什么要先做输入输出设计

创建 Skill 之前，最重要的一步不是写指令，而是想清楚“输入是什么，输出是什么”。很多人的 Skill 效果不好，就是因为这一步没有想清楚。

例如你要做一个“代码评审 Skill”，就要先明确：

• 输入是代码片段，还是 Git 变更的 diff 文件？
• 输出是一段总结，还是按严重级别分类的问题清单？
• 是否需要在代码中标出具体行号？
• 每次评审后是否需要生成一份 Markdown 报告？

如果没有先定义这些，AI 每次执行都可能给出不同格式的答案，使用体验就会变得很不稳定。后面我会用一个具体案例完整演示这个设计过程。

3. 查找 Skill：去哪里找，怎么筛选

3.1 Skill 的主要来源

WorkBuddy 的 Skill 通常来自以下几个渠道：

• 官方 Skill 市场：内置在客户端中的应用商店，由官方或合作团队维护，安全性相对较高，更新也比较主动。
• 社区分享：技术社区、开源平台、博客中经常有人分享自己封装好的 Skill，会附带安装包下载地址或 GitHub 仓库地址。
• 团队内部仓库：企业部署时，管理员可能维护了团队共享的 Skill 仓库，供团队成员直接安装使用。
• 自己创建的本地目录：本地编写好 Skill 配置后，直接通过“导入目录”加载到 WorkBuddy。

如果你的版本支持在线搜索，可以在 Skill 管理面板中直接搜索关键词，例如“周报”“代码评审”“SQL 优化”“会议纪要”。

3.2 搜索关键词怎么选

搜索 Skill 时，不要只搜“日报”“周报”这种宽泛词，而是尽量精确。比如：

• 搜索“前端周报生成”，比搜索“周报”更能找到贴合场景的技能包。
• 搜索“SQL 慢查询分析”，比搜索“SQL”更有针对性。
• 搜索“Python 代码审查”，可以组合语言和任务两个维度。

AI 技能市场的检索能力通常依赖 Skill 的名称、描述和标签字段，描述写得好不好直接影响搜索结果。如果你搜索不到理想的 Skill，可以换用英文关键词再试一次，很多优质技能包会使用英文描述。

3.3 筛选 Skill 的几个判断标准

安装一个 Skill 前，建议先做下面的信息检查：

1. 看描述与触发词：它能处理什么输入，用户需要用什么词来唤醒它。
2. 看示例输出：如果作者提供了示例结果，可以直观判断效果是否符合预期。
3. 看版本和维护时间：长期未更新的 Skill 可能已经不适合当前版本。
4. 看用户评分或讨论：社区反馈是否提到安装后无法使用、输出不稳定等问题。
5. 看权限要求：有些 Skill 会请求读取文件、修改文档或调用网络接口，这时候要留意是否在你的授权范围内。

不要因为一个 Skill 下载量高就直接安装。下载量只能说明关注度高，不能说明结果质量一定好。

3.4 重点关注 Skill 的权限说明

权限问题是最容易忽略的坑。一个 Skill 可能只是被设计用来分析文本，却请求了“读取任意文件”的权限，这在企业工作台中是不太合理的。安装前，如果弹出了权限确认面板，可以逐条核对：

• 为什么需要读取某个目录？
• 会不会向外发送数据？
• 它需要修改的配置文件属于哪个项目？
• 如果停用该 Skill，是否会留下残留任务或自动任务？

如果在安装或创建 Skill 时遇到“创建视图权限不足”之类的报错，不要急着怀疑功能问题。先检查你当前登录账号是不是管理员，再看看工作区目录是否允许写入，最后确认企业策略是否关闭了自定义 Skill 功能。大部分权限类报错都属于这三个原因，这个排查顺序可以覆盖绝大多数情况。

4. 安装 Skill：从导入到启用

4.1 安装 Skill 的一般流程

下面是一个通用的 Skill 安装流程，具体按钮名称可能不同，但逻辑一致：

1. 打开 WorkBuddy，进入“Skill 管理”或“技能中心”。
2. 在搜索框输入技能名称，或者点击“导入 Skill”。
3. 如果是从本地导入，选择包含skill.yaml或技能配置文件的目录或压缩包。
4. 确认 Skill 的元信息、权限要求，点击安装。
5. 在 Skill 列表中查看安装结果。
6. 开启 Skill 开关，选中目标会话或项目，完成绑定。

安装完成后，WorkBuddy 一般会在对话输入框中通过“触发词”识别你是否需要调用某个 Skill。有的版本还支持手动选中 Skill 后再发起对话，两种方式都可以。

4.2 导入 Skill 时容易出现的三个坑

第一个坑：目录结构不对。如果你手动解压技能包，一定要保留原始目录结构。有些技能包把配置和示例放在多级子目录中，一旦你把其中某个文件单独复制到别的地方，导入时就会提示找不到核心配置文件。

第二个坑：版本不兼容。不同版本的 WorkBuddy 对 Skill 配置文件的字段要求可能不同。老的 Skill 用了过时的字段名，新版本可能不识别。遇到这种情况，可以根据报错信息修改字段名，或重新下载适配当前版本的技能包。

第三个坑：权限没有开启。有些 Skill 安装成功后，在“已安装列表”里默认处于禁用状态。如果你看不到它生效，需要先确认开关是否打开，而不是反复卸载重装。

4.3 安装后如何验证

安装成功不等于正常工作。每次安装完新 Skill，建议用一个小样本做冒烟测试：

1. 在对话框中输入它的触发词。
2. 提供一个最简单的测试输入。
3. 观察 AI 是否加载了 Skill，而不是用普通对话模式回答。
4. 检查输出是否符合 Skill 定义的结构。

如果输出结构里出现了并不属于你期望格式的字段，可以重新检查该 Skill 的指令说明，看看是否有额外的推理步骤。很多看似“回答跑偏”的情况，其实是因为 Skill 本身的指令和你的任务目标不一致。

5. 创建 Skill：从 0 到 1 的完整案例

5.1 选定第一个 Skill：项目周报生成器

纸上谈兵没有意义，下面用一个最常见也最容易上手的案例来演示整个创建过程：项目周报生成器。

这个 Skill 的目标是：用户输入本周完成事项和遇到的问题，AI 自动生成一份结构化周报，包含本周进展、下周计划、风险与求助、数据表现四个模块。

先来做输入输出设计：

• 输入：用户用自然语言描述的工作内容，可能是一条一条的列表，也可能是一段碎片化文字。
• 输出：标准化 Markdown 周报，固定四个模块，每个模块有对应内容的展开。
• 附加规则：不能编造未提到的事项；遇到模糊描述时，必须用“待补充”标注，不能直接猜测。

5.2 创建 Skill 结构

在 WorkBuddy 中，你可以选择用表单创建，也可以直接用目录结构创建。下面给出一个参考的本地目录结构：

weekly-report-skill/ ├── skill.yaml ├── instruction.md ├── examples/ │ ├── input-example.txt │ └── output-example.md └── README.md

如果可视化表单已经自动生成了模板，你可以直接在生成的目录基础上修改，不需要从零建文件。

5.3 编写元信息文件

skill.yaml负责描述这个技能的基本信息。参考结构如下：

name: weekly-report-generator display_name: 项目周报生成器 version: 1.0.0 description: 根据用户提供的工作内容生成结构化项目周报，适用于每周五快速产出周报初稿。 trigger_keywords: - 生成周报 - 写周报 - 周报助手 author: your-name permissions: - read: current-context - write: none

需要说明的是，不同版本对字段名有不同要求，trigger_keywords可能写作triggers或keywords。你以本地的模板为准，上面的文件只演示逻辑。

5.4 编写核心指令文件

核心指令是 Skill 的灵魂。这里给出一份可以直接参考的instruction.md：

你是项目周报生成助手，你的任务是把用户提供的碎散工作内容整理成结构化周报。 必须严格遵守下面的执行流程，不得自行添加未提及的信息。 # 执行步骤 1. 读取用户输入，提取其中的工作事项。 2. 将工作事项分类到四个模块： - 本周进展：已经完成的事项。 - 下周计划：计划要做但尚未完成的事项。 - 风险与求助：可能阻塞项目的问题。 - 数据表现：涉及量化指标的内容，如接口耗时、转化率、Bug 数量等。 3. 如果输入中没有对应模块的信息，在对应位置写“待补充”，不要编造。 4. 输出前检查是否出现“未在输入中出现的事项”。 # 输出格式 使用 Markdown 输出，结构如下： ## 本周进展 - 事项一 - 事项二 ## 下周计划 - 计划一 ## 风险与求助 - 待补充 ## 数据表现 - 待补充

这段指令有两个关键设计：

• 执行步骤固定，AI 不需要现场发挥流程。
• 明确规定了“没有信息就写待补充”，防止幻觉。

5.5 添加示例数据

指令写得再清楚，也不如一个示例直观。Skill 可以附带一对输入和输出示例，用来约束 AI 最终输出的形态。

输入示例input-example.txt：

本周完成了用户登录模块的重构，登录接口平均耗时从 800ms 降到 350ms。修复了两个线上 Bug。下周准备开始做支付模块的联调。目前测试环境的数据库连接经常超时，可能影响联调进度。

输出示例output-example.md：

## 本周进展 - 完成用户登录模块的重构。 - 登录接口平均耗时从 800ms 降至 350ms。 - 修复两个线上 Bug。 ## 下周计划 - 开始支付模块的联调。 ## 风险与求助 - 测试环境数据库连接频繁超时，可能影响联调进度。 ## 数据表现 - 登录接口耗时：800ms -> 350ms。

把示例放进examples目录后，AI 在面对同类任务时就有了模仿对象，输出的稳定度会显著提高。

5.6 保存并加载 Skill

完成上面的文件后，回到 WorkBuddy 的“Skill 管理”界面，选择“导入本地目录”，指定weekly-report-skill文件夹。导入成功后，在 Skill 列表中启用它。

此时可以立即实测：

触发词：生成周报 输入：本周把订单列表页的接口缓存加上了，QPS 提升到 2000。下周计划和前端一起优化首屏加载速度。目前线上有一个偶发 500 错误还没定位到原因。

如果 Skill 生效，你会得到一份结构清晰、没有额外编造内容的周报。

6. 使用 Skill：触发、参数传递与结果控制

6.1 三种常见触发方式

WorkBuddy 中 Skill 的触发方式大致有这三种：

1. 自然语言触发：在对话中输入触发词，AI 自动识别并加载对应 Skill。
2. 手动选择触发：在对话窗口或工具面板中选定某个 Skill，再开始本轮对话。
3. 流程触发：在自动化流程或快捷指令中设置一个入口，比如点击一个快捷键直接启动某个 Skill。

自然语言触发最方便，但要求触发词选得准。触发词太多容易误触发，太少则不好唤醒。建议一个 Skill 配置 2 到 5 个触发词，并且把“动作词 + 对象词”作为首选，比如“生成周报”“撰写会议纪要”。

6.2 参数传递：如何把当前内容传给 Skill

有的 Skill 需要接收外部数据，比如当前选中的代码、当前打开的文档、用户输入的附件。

在使用时，你可以在对话中直接粘贴内容，也可以在支持“上下文引用”的版本中，选中一段代码或文档，再调用 Skill。举例说明：

请对下面这段代码运行“Code Review” Skill： def get_user(user_id): return db.query("select * from user where id = " + user_id)

这里把代码文本放进了对话，Skill 会按自己的规则分析代码质量。如果后续想对同一段代码做多次评审，可以把代码保存成文件，再调整 Skill 接收文件路径，避免重复粘贴。

6.3 使用 Skill 过程中的结果控制

使用 Skill 不等于完全放弃控制。当 AI 的输出不符合要求时，你可以基于 Skill 的结果继续对话：

• “把第二点展开成更具体的操作步骤。”
• “本周进展部分的描述不要使用感叹号。”
• “请补充一个表格统计本周 Bug 数量。”

这些指令都是临时修正，不会破坏 Skill 本身。只有当你发现每次运行都需要同样修正时，才应该去改 Skill 的指令文件，而不是每次都手动纠偏。把临时修正和永久修正分开，是优化 Skill 的关键习惯。

6.4 多 Skill 协同注意点

复杂的任务可能需要同时使用多个 Skill。比如先用一个“测试数据生成”Skill 刷出测试数据，再用一个“接口自动化测试”Skill 调用测试用例。

在 WorkBuddy 中，多 Skill 协同的常见问题是：后面的 Skill 可能没有拿到前面 Skill 的输出。解决方法是，在关键节点手动复制上一阶段的输出，传给下一个 Skill，或者使用支持上下文传递的自动化流程。不要把多个 Skill 的全部逻辑堆在同一个会话里不做边界控制，那样不仅排查困难，而且容易互相干扰。

7. 优化 Skill：从“能用”到“稳定好用”

7.1 建立效果评估维度

优化 Skill 之前，先明确什么叫“效果好”。不要把“AI 觉得它完成了”当作效果达标。可以从四个维度衡量：

• 完整性：输入中的关键信息是否都被覆盖。
• 准确性：是否出现了虚构内容。
• 格式符合度：输出结构是否和定义一致。
• 稳定性：连续运行 10 次，效果波动有多大。

建议每次创建完 Skill 后，准备一组固定的测试输入，把输出结果存档。迭代 Skill 时，用同一组测试输入跑一遍，对比优化前后的差异。

7.2 优化前 vs 优化后的对比

很多 Skill 第一次能运行，但效果不稳定。下面是一个典型对比：

大多数效果差的 Skill，问题都出在前面两行：指令太模糊，输入边界不清。

7.3 针对失败输出的具体优化路径

如果 Skill 经常出现以下现象，可以按对应策略优化：

现象一：回答内容太泛。原因通常是没有足够具体的步骤要求。优化方式是增加“执行步骤”，把任务拆成一个一个动作，让 AI 按动作顺序执行。

现象二：格式不统一。优化方式是在指令中直接写死 Markdown 结构，并提供示例。注意示例与真实任务越接近，效果越好，但不要让示例限制住输入变化。

现象三：编造不存在的细节。优化方式是增加约束句，例如“不得出现输入信息中不存在的事项”“如果缺少信息，必须询问用户而不是自行补充”。

现象四：一次处理太多信息导致遗漏。优化方式是拆分 Skill，让一个 Skill 只处理一个子任务，或者增加“先分类，再逐条处理，最后汇总”的步骤。

7.4 版本管理：给 Skill 留一条退路

Skill 改着改着可能越改越差，这是很常见的情况。为了防止无法回退，建议在每次修改前都做一个小版本号递增：

weekly-report-generator: v1.0.0 weekly-report-generator: v1.1.0 weekly-report-generator: v1.2.0

WorkBuddy 如果是基于本地目录管理 Skill，可以直接复制一份目录保存在备份文件夹中。这样即使新版本不稳定，也能秒回退到上一版。不要嫌麻烦，这比在对话里不断纠正 AI 省时得多。

7.5 让优化形成闭环

把每一次实际使用中出现的失败记录收集起来，定期回头修改 Skill。建议每周留出 20 到 30 分钟，进行一次“Skill 维护”：

1. 收集本周运行失败的案例。
2. 找出重复出现的错误类型。
3. 修改 instruction 或 examples。
4. 用历史数据做回归测试。
5. 发布新版本。

优化不是一次性工作，而是伴随使用持续进行的过程。真正好用的 Skill 不是一次写出来的，而是迭代出来的。

8. 常见问题与排查思路

8.1 安装与导入问题

8.2 使用中的效果问题

8.3 混合使用 WorkBuddy 与 CodeBuddy 时的困惑

不少人同时使用 WorkBuddy 和 CodeBuddy，看到两边都有 Skill 相关入口时会困惑：这两个地方的 Skill 通用吗？

从设计定位来看，不同工具的 Skill 机制会绑定各自的运行环境，通常不会完全通用。CodeBuddy 更偏向代码生成与 IDE 内辅助，WorkBuddy 偏重通用工作台和业务流程。一个偏向“写代码”，一个偏向“跑流程”。如果你在两个产品中都使用 Skill，建议分别维护每套环境下的版本，不要在本地直接复制文件导入另一个工具，除非你确认格式兼容。

9. 最佳实践与工程建议

9.1 命名与目录规范

Skill 的命名决定了搜索和触发体验。建议遵循“动作 + 对象”的规则：

• generate-weekly-report
• review-python-code
• extract-meeting-minutes

避免使用含义模糊的词，比如test、do it、ai helper。目录名和显示名称保持大小写统一，方便排错时定位文件。

9.2 指令文本的编写规范

一个高质量的 Skill 指令，通常具备以下特征：

• 用“你是……”确定角色。
• 用“工作目标是……”明确最终产出。
• 用“执行步骤”限制过程。
• 用“输出格式”固定结构。
• 用“禁止行为”控制边界。
• 用“示例”提供参考。

指令文本不要太长。如果超过 1000 字，说明你试图在一个 Skill 里塞太多任务，建议拆分。

9.3 权限与安全边界

Skill 不是越强大越好，权限范围应该遵循最小化原则：

• 不需要读取文件就不要申请文件读取权限。
• 不需要联网就不要开启网络权限。
• 不要在指令中写入敏感凭据或内部地址，除非有严格的权限控制。
• 涉及生产环境或重要数据操作时，先在小范围测试环境验证。

企业内部如果允许创建自定义 Skill，建议建立审核集。团队成员的 Skill 可以先在个人空间验证，再共享到团队仓库，避免一个没测试过的 Skill 被所有人安装后产生问题。

9.4 测试集与回归验证

每个 Skill 维护一套固定的测试用例是投入产出比很高的投资。以“项目周报生成器”为例，可以准备 3 组不同风格的输入：

1. 带有清晰结构的工作列表。
2. 包含大量无关信息的碎片文本。
3. 内容很少、数据缺失的输入。

每次修改 Skill 后，用这三组输入分别跑一遍，观察输出是否依然稳定。这样能有效防止“上一版没问题，改了一处反而变差”的情况。

9.5 文档与分享

一个人会用的 Skill 很有限，如果团队中大家各自写各自，就会重复造轮子。给每个 Skill 写一个简短的 README，说明它能处理什么、不能处理什么、使用触发词、输入要求、输出特点，这样其他人可以直接看懂并使用。

同时，定期整理一个团队 Skill 清单，标注哪些已过时、哪些可以合并，避免仓库里堆满无用技能包。

10. 最后说点实践上的建议

Skill 这个概念本身不复杂，难的是把日常任务抽象成一套可复用、可维护的流程。如果你之前从没创建过 Skill，今天可以只做一件事：从你每周必做的重复任务里挑一个，比如周报、会议纪要、日报总结，按照上面的方法做成一个 Skill。不要追求包罗万象，先解决一个最简单、最高频的任务。

第一次创建时，不要急着把所有规则都写全。先把一个能跑起来的版本跑通，再根据实际输出慢慢加约束。AI 技能优化和写代码很相似，第一版允许粗糙，但必须有测试输入和版本记录。

如果你已经使用过 WorkBuddy 的 Skill，也可以回头检查一下现有的技能包：指令是否足够具体？有没有示例？权限是否过大？触发词是否能准确唤醒？在自己的日常任务里把这些细节补齐，会比到处找新 Skill 更有效率。

Skill 的真正价值不是“装了一个就能用”，而是通过反复迭代，让 AI 在你熟悉的场景里输出越来越稳定。希望这篇教程能帮你少走一些弯路，把重复劳动尽早交出去。