1. 为什么我要认真聊聊 WorkBuddy 这个 AI 工作台
第一次接触 WorkBuddy 是在一个做企业数字化的朋友那里。他当时丢给我一句话：“你把它当成一个能自己动手干活的 AI 同事，而不是一个只会聊天的机器人。”这句话基本概括了 WorkBuddy 的定位——腾讯推出的 AI 工作台，核心能力是把大模型、工具调用、技能插件（Skill）和任务编排整合到一个可配置的工作环境里，让 AI 从“回答问题”进化到“完成任务”。
如果你正在找 AI Agent 的落地入口，或者想搞清楚 models.json、Skill、工作台规则这些概念到底怎么用，这篇内容就是为你准备的。我会从安装部署讲到 Skill 编写，再到实际使用中踩过的坑，尽量把每个环节的“为什么”和“怎么做”都讲清楚。不管你是刚听说 WorkBuddy 的新手，还是已经在折腾 AI Agent 中台的开发者，都能从里面找到能直接抄作业的部分。
需要先说明一点：WorkBuddy 和 CodeBuddy 经常被放在一起比较。简单区分，CodeBuddy 更偏向编码场景的智能辅助，而 WorkBuddy 的野心更大，它想做一个通用的 AI 工作台，能接入不同的模型、挂载不同的 Skill、处理不同类型的任务。你可以理解为 CodeBuddy 是专科医生，WorkBuddy 是全科诊所加手术室。这个定位差异决定了后面很多配置思路的不同。
2. 安装部署：从零把 WorkBuddy 跑起来
2.1 安装前的环境确认与准备工作
装 WorkBuddy 之前，有几件事必须先确认，不然装到一半卡住会非常难受。首先是操作系统，WorkBuddy 目前对 Windows 和 macOS 的支持比较成熟，Linux 环境下也能跑，但部分图形化配置界面可能缺失，需要走命令行配置。如果你打算在 Linux 上部署，建议先确认发行版和内核版本，Ubuntu 20.04 以上、CentOS 7 以上基本没问题。
其次是磁盘空间。WorkBuddy 本体加上模型缓存、Skill 依赖、日志文件，起步建议预留 20GB 以上。这里有个很多人忽略的点：系统缓存目录默认在 C 盘（Windows）或用户主目录（macOS/Linux），随着使用时间增长，缓存可能膨胀到几个 GB。如果你 C 盘空间紧张，最好在安装前就规划好缓存目录的位置。Windows 下可以通过修改配置文件或设置环境变量把缓存指向 D 盘，具体做法后面会讲。
网络环境方面，WorkBuddy 需要访问模型服务接口，所以安装过程中要保持网络通畅。如果你所在的环境有代理要求，需要提前配置好系统级代理，而不是只在浏览器里设置。这一点经常被忽略，导致安装脚本下载依赖时超时。
最后是账号准备。WorkBuddy 需要登录才能使用完整功能，建议提前注册好账号并完成实名认证（如果平台要求）。国际版和国内版在账号体系上可能有差异，选择哪个版本取决于你的使用场景和网络条件。
2.2 各平台安装步骤详解
Windows 下的安装相对直接。从官方渠道下载安装包后，双击运行，安装向导会引导你选择安装路径。这里建议不要装在默认的 Program Files 目录下，因为后续 Skill 开发和调试可能需要频繁读写安装目录，权限问题会很烦人。选一个你完全控制的目录，比如D:\WorkBuddy。
安装完成后首次启动，WorkBuddy 会引导你进行初始配置，包括登录账号、选择默认模型、设置工作目录。工作目录这个选项很重要，它决定了 WorkBuddy 默认在哪里读写文件。建议单独建一个目录，比如D:\WorkBuddyWorkspace，不要直接用桌面或文档目录，避免文件混乱。
macOS 下可以通过下载 dmg 镜像安装，也可以走 Homebrew。如果你习惯命令行，Homebrew 方式更干净：
brew install --cask workbuddy安装后首次运行可能需要在“系统设置-隐私与安全性”里允许来自开发者的应用。这个步骤 macOS 用户应该很熟悉了，不再赘述。
Linux 下的安装稍微复杂一些。官方可能提供 AppImage 或 deb/rpm 包，也可能只提供命令行工具。如果是命令行方式，通常是这样：
# 以 deb 包为例 sudo dpkg -i workbuddy_xxx.deb sudo apt-get install -f # 修复依赖安装完成后，通过workbuddy --version确认安装成功。如果提示命令找不到，检查 PATH 环境变量是否包含了安装目录。
2.3 首次启动配置与缓存目录迁移
首次启动后，WorkBuddy 会生成一个默认配置文件，通常叫models.json，放在用户配置目录下。这个文件是 WorkBuddy 的核心配置之一，定义了你可以使用哪些模型、每个模型的接口地址和参数。默认情况下它可能只包含官方推荐的几个模型，你可以根据需要添加自定义模型。
关于缓存目录迁移，这是问得最多的问题之一。Windows 下，WorkBuddy 的缓存默认在C:\Users\你的用户名\.workbuddy\cache。要改到 D 盘，有两种方式。第一种是修改配置文件，在models.json同级目录下找到config.json或类似文件，添加或修改cacheDir字段：
{ "cacheDir": "D:\\WorkBuddyCache" }第二种是设置环境变量。在系统环境变量里添加WORKBUDDY_CACHE_DIR，值为D:\WorkBuddyCache。两种方式选一种即可，改完后重启 WorkBuddy 生效。实测下来，环境变量方式的优先级更高，如果你两种都设了，以环境变量为准。
注意：迁移缓存目录前，先把原有缓存目录里的内容手动复制到新位置，否则已下载的模型和 Skill 依赖需要重新下载。
macOS 和 Linux 下同理，缓存目录默认在~/.workbuddy/cache，可以通过配置文件或环境变量修改。Linux 下如果 WorkBuddy 是以服务方式运行的，记得修改服务文件里的环境变量配置。
3. 核心配置解析：models.json 与工作台规则
3.1 models.json 的结构与模型接入方法
models.json是 WorkBuddy 的模型配置文件，理解它的结构是用好 WorkBuddy 的基础。一个典型的models.json长这样：
{ "models": [ { "name": "default-chat", "provider": "tencent", "model": "hunyuan-pro", "apiKey": "your-api-key", "baseUrl": "https://api.example.com/v1", "maxTokens": 4096, "temperature": 0.7 }, { "name": "reasoning", "provider": "custom", "model": "deepseek-reasoner", "apiKey": "your-api-key", "baseUrl": "https://api.example.com/v1", "maxTokens": 8192, "temperature": 0.3 } ], "defaultModel": "default-chat" }几个关键字段需要解释。name是你给这个模型配置起的别名，在 WorkBuddy 界面里选择模型时看到的就是这个名字。provider标识模型来源，官方支持的 provider 可以直接填，自定义的填custom。model是模型的实际标识符，必须和接口文档里的一致。apiKey和baseUrl是接口认证和地址，这个不用多说。
maxTokens和temperature是两个影响输出质量的关键参数。maxTokens控制单次回复的最大长度，设太小会导致长回答被截断，设太大又可能浪费额度。一般对话场景 4096 够用，需要生成长文档或代码时调到 8192 甚至更高。temperature控制输出的随机性，0 到 1 之间，越低越确定、越高越有创造性。写代码、做数学题建议 0.2 到 0.3，创意写作可以到 0.7 到 0.9。
实操心得：如果你有多个模型配置，建议按用途命名，比如
chat-fast、chat-quality、code-gen、reasoning，而不是用model1、model2这种无意义的名字。用一段时间后你会感谢自己当初的命名习惯。
3.2 给 WorkBuddy 定规则：让后续任务自动生效
WorkBuddy 有一个很实用的功能，就是可以给它设定全局规则，设定一次后对所有后续任务生效。这个功能在团队协作场景下特别有用，比如统一输出格式、统一代码风格、统一回复语言。
规则的定义通常在配置文件的rules字段里，或者通过工作台界面的“规则设置”入口添加。规则本质上是一段系统提示词，会在每次任务开始时自动注入。比如你可以定这样几条规则：
- 所有代码输出使用 Python 3.10 兼容语法
- 回复中涉及数据时，优先用表格呈现
- 不确定的信息必须标注“待确认”，不得编造
- 文件操作前先输出操作计划，确认后再执行
这些规则看起来简单，但能极大提升输出的一致性和可用性。我自己的习惯是给每个项目单独建一套规则，项目开始时把规则文件加载进去，避免每次都要重复交代背景。
注意：规则不是越多越好。规则太多会占用上下文窗口，还可能互相冲突。建议单个项目的规则控制在 5 到 8 条，每条尽量具体、可执行，避免“回答要好”这种模糊表述。
3.3 工作目录与文件权限的配置要点
WorkBuddy 的工作目录决定了它能访问哪些文件。默认情况下，它只能访问你指定的工作目录及其子目录，这是出于安全考虑。如果你需要它访问其他位置的文件，需要在配置里显式添加路径。
文件权限方面，WorkBuddy 执行文件操作（读、写、删除）时，会受操作系统权限限制。在 Windows 下，如果你以普通用户身份运行 WorkBuddy，它就无法写入需要管理员权限的目录。在 Linux 下同理，如果 WorkBuddy 以非 root 用户运行，就无法访问 root 拥有的文件。
这里有个容易踩的坑：不要把工作目录设在系统目录或程序安装目录下。一方面权限可能不够，另一方面 WorkBuddy 生成的文件会和系统文件混在一起，后期清理很麻烦。单独建一个工作区，按项目分子目录，是最稳妥的做法。
4. Skill 机制深度拆解：从理解到编写
4.1 Skill 到底是什么：概念与运行原理
Skill 是 WorkBuddy 最核心的扩展机制。你可以把它理解成给 AI 装的“技能包”——每个 Skill 定义了一类特定任务的处理逻辑，包括触发条件、执行步骤、依赖工具和输出格式。当用户的请求匹配到某个 Skill 的触发条件时，WorkBuddy 会加载对应的 Skill，按照里面定义的流程来执行任务。
从技术角度看，一个 Skill 通常包含几个部分：元数据（名称、描述、版本、作者）、触发规则（什么情况下激活这个 Skill）、执行逻辑（具体做什么、怎么做）、依赖声明（需要哪些工具或模型）。执行逻辑可以用自然语言描述，也可以包含脚本代码。WorkBuddy 会根据 Skill 的定义，决定是直接让模型处理，还是调用外部工具或脚本。
Skill 和传统的“插件”有什么区别？插件通常是固定功能的黑盒，你只能用，不能改。Skill 更像是一份“操作手册”，AI 读了之后按手册执行。这意味着 Skill 的灵活性更高，你可以针对自己的业务场景定制，也可以组合多个 Skill 完成复杂任务。
4.2 一个 Skill 的完整结构拆解
以一个“数学建模 Skill”为例，拆解一下 Skill 的典型结构。这个 Skill 的目标是：当用户提出数学建模相关问题时，自动完成问题分析、模型选择、求解和结果解释。
元数据部分：
name: math-modeling description: 数学建模任务处理，包括问题分析、模型选择、求解和结果解释 version: 1.0.0 author: your-name tags: [math, modeling, optimization]触发规则部分，定义什么情况下激活这个 Skill：
triggers: - keywords: ["数学建模", "优化问题", "线性规划", "微分方程"] - patterns: ["求解.*模型", "建立.*方程"]执行逻辑部分，这是 Skill 的核心：
steps: - name: 问题分析 action: analyze prompt: | 分析以下问题的类型、已知条件、目标函数和约束条件。 问题描述：{{user_input}} - name: 模型选择 action: select_model options: [线性规划, 非线性规划, 微分方程, 统计回归] - name: 求解 action: solve tool: python script: | # 根据选择的模型类型调用相应的求解库 ... - name: 结果解释 action: explain prompt: | 用通俗语言解释求解结果的实际含义。依赖声明部分：
dependencies: - python>=3.8 - numpy - scipy - sympy这个结构看起来简单，但实际编写时有很多细节要注意。比如触发规则不能太宽泛，否则会误触发；也不能太窄，否则该触发时不触发。执行步骤的 prompt 要足够具体，给模型明确的指令，而不是模糊的期望。
4.3 从零编写你的第一个 Skill
写第一个 Skill 时，建议从最简单的场景开始，比如“格式化输出”或“文件重命名”。不要一上来就写复杂的多步骤 Skill，容易调试到崩溃。
第一步是确定 Skill 的边界。问自己三个问题：这个 Skill 解决什么问题？什么情况下应该触发？什么情况下不应该触发？把答案写下来，这就是 Skill 的元数据和触发规则。
第二步是拆解执行步骤。把任务分解成若干个子步骤，每个步骤明确输入、输出和使用的工具。步骤不要太多，一般 3 到 7 步比较合适。步骤太多会导致执行时间长、出错概率高。
第三步是编写 prompt 和脚本。prompt 要具体，包含足够的上下文和约束。脚本要健壮，处理异常情况。比如文件操作脚本要检查文件是否存在、是否有权限、操作是否成功。
第四步是测试和迭代。用几个典型输入测试 Skill，观察输出是否符合预期。不符合预期时，先判断是触发规则的问题还是执行逻辑的问题，然后针对性调整。
实操心得：Skill 开发过程中，建议把每次修改和对应的测试结果记录下来。Skill 的调试往往不是一次成功的，有个修改日志能帮你快速定位是哪次改动引入了问题。
4.4 Skill 推荐与组合使用思路
WorkBuddy 社区里已经有不少现成的 Skill 可以直接用。常见的推荐包括：代码审查 Skill、文档生成 Skill、数据分析 Skill、网页生成 Skill、视频处理 Skill 等。这些 Skill 覆盖了日常工作中大部分重复性任务。
组合使用是 Skill 机制真正强大的地方。比如你可以把“数据分析 Skill”和“图表生成 Skill”组合起来，先分析数据再自动生成可视化图表。或者把“文档生成 Skill”和“翻译 Skill”组合，先生成中文文档再翻译成英文。
组合的方式有两种。一种是串行组合，前一个 Skill 的输出作为后一个 Skill 的输入。另一种是并行组合，多个 Skill 同时处理同一个输入，最后汇总结果。WorkBuddy 的任务编排功能支持这两种模式，具体用哪种取决于任务的性质。
注意：组合 Skill 时要注意上下文长度。每个 Skill 的执行都会消耗上下文窗口，组合太多可能导致超出模型限制。建议单个任务链控制在 3 个 Skill 以内。
5. 实操全流程：用 WorkBuddy 完成一个真实任务
5.1 任务定义与 Skill 选择
假设我们要用 WorkBuddy 完成一个真实任务：分析一份销售数据 CSV 文件，生成分析报告，并制作一个简单的展示网页。这个任务涉及数据处理、文档生成和网页生成三个环节。
首先明确任务输入和输出。输入是一个 CSV 文件，包含日期、产品、销量、销售额等字段。输出是一份 Markdown 格式的分析报告和一个 HTML 展示页面。
然后选择 Skill。数据处理环节用“数据分析 Skill”，文档生成环节用“文档生成 Skill”，网页生成环节用“网页生成 Skill”。如果社区里没有完全匹配的 Skill，可以基于现有 Skill 修改，或者自己写一个。
5.2 配置与执行过程记录
配置阶段，先把 CSV 文件放到工作目录下，然后在 WorkBuddy 里新建任务，选择数据分析 Skill，指定输入文件路径。Skill 会自动读取 CSV，进行数据清洗和统计分析。
执行过程中，WorkBuddy 会输出每一步的操作日志。比如“正在读取文件 sales_data.csv”、“检测到 5 列 1200 行数据”、“正在计算各产品销量汇总”、“正在生成趋势分析”。这些日志对于排查问题很有帮助，如果某一步卡住了，能快速定位。
数据分析完成后，切换到文档生成 Skill，把分析结果作为输入，生成 Markdown 报告。报告结构可以预先在 Skill 里定义好，比如包含“数据概览”、“趋势分析”、“产品对比”、“结论建议”几个部分。
最后用网页生成 Skill 把报告转成 HTML 页面。这里可以指定页面模板和样式，让输出更美观。生成的 HTML 文件会保存在工作目录下，直接用浏览器打开就能看。
5.3 参数调优与效果验证
执行完成后，需要验证结果是否符合预期。检查几个方面：数据统计是否准确、报告结构是否完整、网页显示是否正常。如果发现问题，回到对应的 Skill 调整参数。
比如数据分析结果偏差较大，可能是数据清洗规则太激进，把有效数据也过滤掉了。这时候需要调整清洗阈值。报告结构不完整，可能是文档生成 Skill 的模板定义有问题，需要补充缺失的章节。网页显示异常，可能是 HTML 模板的 CSS 有问题，需要检查样式定义。
参数调优是个迭代过程，不要期望一次就完美。我的习惯是先跑通流程，再逐步优化每个环节的输出质量。先保证能用，再追求好用。
5.4 成果导出与后续复用
任务完成后，WorkBuddy 会把所有生成的文件保存在工作目录下。你可以直接使用这些文件，也可以把它们作为模板，下次处理类似任务时直接复用。
复用的方式有几种。如果任务流程固定，可以把整个流程保存为一个“任务模板”，下次一键执行。如果只是部分环节可复用，可以把对应的 Skill 配置导出，在新任务里导入。如果输出格式固定，可以把生成的文档或网页作为模板，替换数据后重新生成。
实操心得：建议给每个完成的任务建一个归档目录，把输入文件、Skill 配置、输出结果和操作日志都放进去。过一段时间回头看，这些归档就是最好的学习材料。
6. 常见问题与避坑指南
6.1 安装与启动阶段的典型问题
安装阶段最常见的问题是网络超时。WorkBuddy 安装时需要下载依赖，如果网络不稳定，很容易卡在某个下载步骤。解决办法是配置好系统代理，或者手动下载依赖包放到指定目录。如果安装脚本支持离线安装，优先用离线包。
启动阶段常见的问题是端口占用。WorkBuddy 启动时会占用一个本地端口用于内部通信，如果这个端口被其他程序占用了，启动会失败。解决办法是修改 WorkBuddy 的端口配置，或者关掉占用端口的程序。Windows 下可以用netstat -ano | findstr 端口号查看端口占用情况。
还有一个问题是权限不足。特别是在 Linux 下，如果 WorkBuddy 需要访问某些系统资源但没有权限，启动会报错。解决办法是用合适的用户身份运行，或者调整文件权限。不建议直接用 root 运行，安全风险太大。
6.2 Skill 加载失败的排查思路
Skill 加载失败的原因有很多，排查时按以下顺序检查。先看 Skill 文件格式是否正确，YAML 或 JSON 格式对缩进和符号很敏感，一个多余的逗号就可能导致解析失败。再看依赖是否满足，Skill 声明的依赖如果没有安装，加载会失败。然后看触发规则是否有语法错误，正则表达式写错了也会导致加载失败。
如果以上都没问题，看日志。WorkBuddy 的日志文件里会记录 Skill 加载的详细过程，包括失败原因。日志通常在logs目录下，按日期分文件。找到对应时间点的日志，搜索 Skill 名称，就能看到具体错误信息。
还有一种情况是 Skill 加载成功但不触发。这通常是触发规则的问题，可能是关键词不匹配，也可能是优先级被其他 Skill 抢占了。解决办法是调整触发规则，或者调整 Skill 的优先级设置。
6.3 模型调用异常与缓存问题处理
模型调用异常的表现包括：请求超时、返回错误码、返回内容为空、返回内容乱码。超时通常是网络问题或模型服务负载高，可以重试或换模型。错误码需要查接口文档，不同错误码含义不同。返回内容为空可能是 prompt 有问题，模型不知道该怎么回答。乱码通常是编码问题，检查请求和响应的编码设置。
缓存问题主要表现为：缓存目录膨胀、缓存文件损坏、缓存命中率低。缓存目录膨胀的解决办法是定期清理，或者设置缓存上限。缓存文件损坏会导致读取失败，解决办法是删除损坏的缓存文件，让 WorkBuddy 重新生成。缓存命中率低可能是缓存策略配置不合理，需要调整缓存键的生成规则。
注意：清理缓存前先确认没有正在运行的任务，否则可能导致任务失败。建议在 WorkBuddy 空闲时清理缓存。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 安装卡在下载依赖 | 网络不稳定 | 查看安装日志 | 配置代理或离线安装 |
| 启动失败提示端口占用 | 端口被占用 | netstat 查端口 | 改端口或关占用程序 |
| Skill 加载失败 | 格式错误/依赖缺失 | 查看 Skill 日志 | 修正格式或安装依赖 |
| Skill 不触发 | 触发规则不匹配 | 检查关键词和正则 | 调整触发规则 |
| 模型调用超时 | 网络或服务负载 | 重试或换模型 | 检查网络、切换模型 |
| 缓存目录膨胀 | 缓存未清理 | 查看目录大小 | 清理缓存或设上限 |
| 输出内容截断 | maxTokens 太小 | 检查模型配置 | 调大 maxTokens |
| 输出内容随机性高 | temperature 太高 | 检查模型配置 | 调低 temperature |
7. 进阶玩法：把 WorkBuddy 用出花来
7.1 多 Skill 协作完成复杂任务
单个 Skill 能做的事有限，多个 Skill 协作才能完成复杂任务。比如做一个“竞品分析”任务，可以拆解成：数据采集 Skill 抓取竞品信息、数据分析 Skill 做对比分析、文档生成 Skill 写分析报告、图表生成 Skill 做可视化。四个 Skill 串行执行，前一个的输出作为后一个的输入。
多 Skill 协作的关键是定义好接口。每个 Skill 的输入输出格式要统一，比如都用 JSON 格式传递数据。这样 Skill 之间才能无缝衔接。如果格式不统一，中间需要加转换步骤，会增加出错概率。
另一个关键是错误处理。如果中间某个 Skill 执行失败，整个任务链会中断。解决办法是在 Skill 里定义失败重试和降级策略。比如数据采集失败时，用缓存数据代替；分析失败时，输出原始数据让用户手动处理。
7.2 自定义 Skill 的开发与调试技巧
开发自定义 Skill 时，有几个技巧能提高效率。第一是先用自然语言把 Skill 的逻辑写清楚，确认逻辑没问题后再转成 Skill 格式。第二是分步调试，先测试触发规则，再测试单个步骤，最后测试完整流程。第三是保留调试日志，每次执行都记录输入输出，方便对比。
调试 Skill 时，可以用 WorkBuddy 的“单步执行”功能，一步一步走，观察每一步的输出。如果某一步输出不符合预期，就针对那一步调整。不要一次改多个地方，否则出了问题不知道是哪个改动导致的。
Skill 开发完成后，建议写一份使用说明，包括适用场景、输入要求、输出格式、注意事项。这份说明不仅方便自己以后回顾，也方便分享给团队成员使用。
7.3 团队协作场景下的 WorkBuddy 配置
团队使用 WorkBuddy 时，配置管理是个挑战。每个人的模型配置、Skill 配置、规则配置可能都不一样，需要统一管理。解决办法是建一个共享配置仓库，把通用的配置放在里面，个人配置放在本地。WorkBuddy 启动时先加载共享配置，再加载个人配置，个人配置覆盖共享配置。
Skill 共享也是类似思路。团队共用的 Skill 放在共享目录，个人开发的 Skill 放在个人目录。WorkBuddy 加载时合并两个目录的 Skill，同名 Skill 以个人目录为准。这样既能共享通用能力，又能保留个人定制。
权限管理方面，团队场景下需要控制谁能修改共享配置和 Skill。建议用版本控制工具管理共享配置，每次修改都走审核流程。这样能避免误改导致的问题，也能追溯修改历史。
7.4 性能优化与资源占用控制
WorkBuddy 运行时会占用 CPU、内存和磁盘。长时间运行后，资源占用可能越来越高。优化方法包括：定期重启 WorkBuddy 释放内存、限制并发任务数、调整缓存策略、关闭不用的 Skill。
并发任务数是影响性能的关键因素。同时跑太多任务会导致资源竞争，每个任务都变慢。建议根据机器配置设置合理的并发上限，一般 2 到 4 个比较合适。如果任务之间有依赖关系，用串行执行而不是并行。
缓存策略方面，可以设置缓存过期时间和最大容量。过期时间到了自动清理旧缓存，容量到了自动淘汰最久未使用的缓存。这样能控制磁盘占用，同时保证常用数据还在缓存里。
实操心得：如果你的机器配置一般，建议把模型推理放在远程服务上，本地只跑 WorkBuddy 的任务编排和 Skill 执行。这样能大幅降低本地资源占用，代价是依赖网络。
8. 我个人的一些使用体会
用 WorkBuddy 这段时间，最大的感受是它把 AI Agent 的门槛降低了很多。以前要自己搭 Agent 框架、写工具调用逻辑、处理上下文管理，现在这些 WorkBuddy 都帮你做了，你只需要关注业务逻辑和 Skill 编写。这对于想快速验证 AI Agent 想法的人来说，省了大量前期工作。
另一个体会是 Skill 的质量决定了 WorkBuddy 的上限。WorkBuddy 本身只是个壳，真正干活的是 Skill。花时间打磨几个高质量的 Skill，比装一堆用不上的 Skill 有价值得多。我自己的做法是，常用的 Skill 反复迭代，不常用的直接删掉，保持 Skill 库精简。
最后分享一个小技巧：给 WorkBuddy 定规则时，把“不确定的信息必须标注待确认”这条加上。AI 有时候会自信地编造信息，加上这条规则后，它会主动标注哪些是推测、哪些是确定的。这个习惯能帮你避免很多因为 AI 幻觉导致的错误决策。
