最近，我产生了一个想法：写一门面向普通用户的 WorkBuddy 入门课程。
这个念头来自大学同学群里的讨论。
几位同学试用 WorkBuddy 后，都给出了相似的评价：功能看起来很多，但真正用到工作中时，总觉得不顺手，觉得无法满足自己的需求。
继续聊下去后，我发现，“WorkBuddy 不好用”并不是一个简单的产品结论。它背后至少有两方面原因，一方面是 WorkBuddy 自身的设计和呈现方式容易让新用户迷失；另一方面，则是很多人仍然在用传统软件的使用习惯理解它。
WorkBuddy 本质上既不是一个功能集合的传统软件，也不是像最初的AI工具，仅见只能通过聊天指挥大模型完成任务。
重要 它已经是一个能够调用本地工具、处理文件，并通过 Skill 扩展能力的 AI Agent。
理解这一点，是用好 WorkBuddy 的第一步。
一、为什么 WorkBuddy 容易让新用户无所适从
腾讯推出 WorkBuddy 后，快速接入了大量专家、Skill、连接器和既有服务。
这些能力构成了 WorkBuddy 的扩展生态，但也带来了一个明显问题：入口很多，概念很多，新用户不知道应该从哪里开始。
尤其是没有使用过类似 Agent 工具的用户，第一次打开 WorkBuddy 时，很容易觉得自己面对的不是一个工具，而是一整套需要从头学习的复杂系统。
在这种情况下，新用户通常会走向两个极端。
第一类用户会立刻进入 Skill 市场，在“专家、技能、连接器”中搜索关键词，希望找到一个能够直接满足需求的现成 Skill。
看到介绍相近的，就安装、试用。如果发现不合适，就继续搜索和安装。经过几轮尝试后，如果始终找不到完全匹配的 Skill，他们很容易得出结论：
WorkBuddy 看起来功能很多，但没有一个真正适合我。
第二类用户则认为，既然这是一个复杂工具，就必须先把所有功能学明白。
于是，他们开始逐项阅读文档，研究每一个菜单、按钮和概念，在网络上学习一整个系列的WorkBuddy教学视频。在读完全部教程之前，他们不敢真正开始使用，总觉得自己还没有准备好。
这两种做法看似不同，本质上却有同一个问题，都把 WorkBuddy 当成了一个功能已经固定的传统软件。
二、传统软件的使用方式，为什么不适合 WorkBuddy
使用传统软件时，我们通常会先寻找功能入口。
想要修图，就找修图功能。想要导出表格，就找导出按钮。想要批量处理文件，就寻找对应的插件。
但 WorkBuddy 不只是一个等待用户点击功能的应用程序，它还是一个 AI Agent。WorkBuddy 可以根据用户的目标调用工具、执行代码，并把一套重复出现的工作流程封装成 Skill。
因此，在 WorkBuddy 中，更合适的起点不是，
市场里有没有一个正好符合我需求的 Skill？
而是，
我现在要完成什么任务？这个任务可以怎样拆解、验证和重复执行？
两种提问方式看起来差别不大，得到的结果却可能完全不同。
另一个常见误区，是把过去使用聊天式 AI 的经验直接应用到文件处理和自动化任务中。
普通问答操作，允许答案存在一定程度的模糊。即使回答中有个别遗漏，用户通常仍然可以从中获得信息，甚至通过多次提问来弥补。但在表格转换、批量改名、数据清洗或调用 API 等工作任务中，只要某一步的处理逻辑发生偏差，就可能影响全部结果。
因此，不能只对 WorkBuddy 说一句“帮我处理一下”，然后期待它一次性给出完全正确的最终结果。
更可靠的方式是：
- 先和WorkBuddy对话，说明任务需求，让它判断是否已经完全理解了你的需求。
- 让它说明准备如何处理，最好是通过代码编程的方式实现具体操作，而不是通过简单的文字描述。
- 使用少量样本验证结果，确认处理逻辑是否正确。
- 确认输入、输出和异常处理规则，确保处理结果符合预期。
- 验证通过后，再扩大处理范围，直到满足所有需求。
- 对需要反复执行的流程，最后再创建 Skill，以便下次直接调用。
以上所有步骤，你都不需要向 WorkBuddy 展示任何代码，只需要通过自然语言和它对话。
三、新用户应该怎样开始使用 WorkBuddy
对于刚开始使用 WorkBuddy 的用户，我的建议是：不要一上来就安装大量 Skill。
系统默认提供的基本功能和Skill，已经足够用来了解 WorkBuddy 的基本工作方式，也足以完成很多日常任务。
更合适的入门顺序，可以分成三个阶段。
第一步：选择一个真实而具体的小任务
不要从“帮我提高工作效率”这种宽泛目标开始。
选择一个你确实需要完成，而且结果容易检查的任务，例如：
- 整理一份表格；
- 从一批文档中提取固定字段；
- 调用已有 API 生成一张图片；
- 按照统一规则转换几份文件；
- 根据固定模板生成周报。
任务越具体，WorkBuddy 越容易理解你的目标，你也越容易判断结果是否正确。
第二步：先用对话跑通完整流程
第一次执行时，不要急着创建 Skill。
先通过对话把需求说清楚，包括：
- 输入内容是什么；
- 处理步骤是什么；
- 输出结果放在哪里；
- 哪些规则不能改变；
- 出现异常时应该怎样处理；
- 什么样的结果才算成功。
如果任务需要运行 Python 代码，可以先让 WorkBuddy 检查当前环境：
请检查当前环境是否已经有可供 WorkBuddy 调用的 Python。
如果没有，请说明准备采用的安装方式、安装位置以及需要的权限。
完成后请运行一个最小测试，确认 Python 可以正常执行。
不要默认同意所有权限申请。涉及系统目录、环境变量或软件安装时，应先确认这些权限是否确实是当前操作所必需的。
第三步：把验证过的流程固化为 Skill
只有在任务已经通过验证，并且以后还会重复使用时，才有必要创建 Skill。
举个例子，假设你有一个可以调用 gpt-image-2 模型生成图片的 API，你可以这样描述需求：
请为我创建一个名为“create-image”的 Skill。
这个 Skill 通过 Python 调用我的图片生成 API，并使用
gpt-image-2 模型生成图片。
创建前，请先和我确认以下信息：
1. API 的请求地址和参数格式；
2. API 密钥的安全配置方式，不要把密钥直接写入代码；
3. 支持的图片尺寸；
4. 图片的默认保存目录；
5. 文件命名规则；
6. 请求失败时的重试和报错方式。
创建完成后，请使用一个最小示例进行测试。
在这个过程中，WorkBuddy 可能会继续询问图片尺寸、输出目录、文件名格式等信息。确认这些细节后，它就可以把整套流程固化到 Skill 中。
Skill 创建完成后，可以新建一个任务，在输入框中输入 /，从列表中选择 create-image，再填写图片生成提示词。
四、需求变化时，不必推翻原来的 Skill
假设最初的 create-image 只支持文字生成图片，后来你又希望它支持上传多张参考图，并根据参考图生成新图片。
这时，不一定要直接修改原来的 Skill。为了避免影响已经稳定运行的工作流程，可以在保留原有配置的基础上创建一个新 Skill：
请保留“create-image”现有的配置和行为，不要修改原 Skill。
在此基础上创建一个名为“create-image-edit”的新 Skill。
新 Skill 需要支持上传多张参考图，并将这些图片作为请求参数，
调用 gpt-image-2 模型生成新图片。
请先确认 API 是否支持多图输入、图片格式和大小限制，
再完成实现和测试。
这样做的好处是，原来的文生图流程可以继续稳定使用，新增的图生图能力则由另一个 Skill 独立承担。
结语
WorkBuddy 的价值，并不在于 Skill 市场里有多少现成功能，而在于它能否逐步适配你的真实工作流程。
对于新用户来说，最重要的不是先学完所有功能，也不是先安装一堆 Skill，而是掌握三个原则：
- 从一个具体、容易验证的小任务开始；
- 先通过对话跑通并验证流程；
- 只有当流程需要重复执行时，才把它固化为 Skill。
不要先问“WorkBuddy 有什么功能”。
先问自己：
我现在最希望它替我完成哪一项具体工作？
这个问题，才是使用 WorkBuddy 的真正起点。