workbuddy 的 skill 必须将符合规范的 skill.md（含 name、description、examples 三字段）置于指定路径，修改后需执行 /reload skills 才生效；skills 与 plugins 分离管理，前者定义任务范式，后者提供运行时能力。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

WorkBuddy 的 skill 文件怎么装才生效

WorkBuddy 的技能不是“安装即用”，它依赖一个叫 SKILL.md 的结构化说明书文件。你丢进去一个 ZIP 或随便一个 Markdown，大概率不会被识别——系统只认符合规范的 SKILL.md 格式，且必须放在正确路径下。

常见错误现象包括：技能列表里看不到新条目、AI 明明被提示“用 pptx 技能”，却仍按默认逻辑生成乱码 PPT、执行时提示 skill not found。

• 路径必须是 ~/.workbuddy/skills/{skill-name}/SKILL.md（macOS/Linux）或 %APPDATA%\WorkBuddy\skills\{skill-name}\SKILL.md（Windows）
• SKILL.md 里必须包含 name、description、examples 三个顶层字段，缺一不可
• 不支持嵌套子目录；skills/foo/bar/SKILL.md 不会被扫描
• 修改后需手动触发重载：在 WorkBuddy 中输入 /reload skills，不能靠重启应用自动刷新

为什么 skills 和 plugins 在 WorkBuddy 里要分开管理

因为它们解决的是两类完全不同的问题：skills 改变 AI “怎么想”，plugins 决定 AI “能做什么”。混用会导致权限越界或行为不可控。

比如你装了 xlsx skill，AI 就知道 Excel 表格该用 openpyxl 而不是 pandas.read_excel 解析，也明白合并单元格要先取消合并再写入；但如果没有 filesystem plugin，它连打开本地 data.xlsx 这个动作都做不到——技能不提供 IO 能力。

WorkBuddy Visio — Visio 兼容架构图生成器

使用 draw.io（.drawio 格式）和 SVG 生成兼容 Microsoft Visio 的架构图。当用户需要以下任一场景时触发： - 用于 Visio 或技术文档的架构/系统/网络图 - 带连接标注的分层控制系统图 - 将 draw.io XML 转换为稳定、可嵌入的 SVG - 修复 Visio 或 draw.io 无法打开的故障排查类图表 - 任何需专业级布局且文本可编辑的图表

下载

• skills 是纯知识层注入，无运行时权限，不访问文件/网络/API
• plugins 必须显式授权（如勾选“允许访问桌面文件夹”），且每次调用前会走安全审计
• WorkBuddy 启动时只加载已启用的 plugins，但所有 skills 都常驻内存，供意图识别实时匹配
• 第三方技能（比如从 ClawHub 下载的）若含插件调用声明，必须单独安装对应 plugin 才能跑通

和 Cursor/Trae 的插件机制比，WorkBuddy 的 skill 有什么实际差异

Cursor 和 Trae 的“插件”本质是工具调用封装（比如 web_search、github_api），侧重外部能力接入；而 WorkBuddy 的 skill 是任务执行范式定义，更接近领域专家手册。

这导致一个关键区别：同样处理 PDF，Trae 插件可能只暴露 pdf_extract_text() 函数，你要自己拼逻辑；WorkBuddy 的 pdf skill 则内置了“先判断是否扫描件→是则 OCR→否则直接提取→过滤页眉页脚→按语义分段”的完整 SOP，你只要说“把这份合同的关键条款摘出来”，它就走完整条链路。

• Cursor/Trae 插件返回原始数据，后续处理靠 LLM 自行推理；WorkBuddy skill 直接输出结构化结果（如 JSON 列表、带样式的 PPTX 文件）
• Trae 插件可跨模型复用，但需要适配 MCP 协议；WorkBuddy skill 绑定本地模型上下文长度与 token 窗口，换模型可能需微调 SKILL.md 中的 max_context 参数
• WorkBuddy 的 skill 支持 fallback 流程定义（例如 OCR 失败时自动降级为全文截图+文字描述），这是插件机制本身不提供的能力

导入失败时最该先查哪三件事

别急着删重装，90% 的导入失败卡在基础校验环节。先确认这三项，能省下大量调试时间。

• 检查 SKILL.md 文件编码是否为 UTF-8 无 BOM（用 VS Code 右下角确认，Notepad++ 易出错）
• 确认 name 字段值不含空格或特殊字符（如 name: "pptx-generator" ✅，name: "PPTX 生成器" ❌）
• 运行 workbuddy --validate-skill /path/to/skill（命令行模式下），它会直接输出缺失字段或 YAML 语法错误位置

真正容易被忽略的是：WorkBuddy 对 skill 名称大小写敏感，且不允许两个 skill 共享同一 name——即使路径不同，后加载的会静默覆盖前一个。