WorkBuddy 从零到落地：本地模型、Skill 与定时任务配置实战

最近在折腾 WorkBuddy 的时候我第一反应是“这不又是一个套壳聊天窗口”。真正花了两周把本地模型、Skill、连接器和定时任务串起来之后我才发现它值钱的地方不在于对话框而在于把散落的 AI 能力拼成一张可编排的“工作效率网”。网上关于 WorkBuddy 的教程大多停留在“怎么下载、怎么提问、怎么换模型”真正讲清楚 AI 代理助手加本地模型怎么配、Skill 怎么写、连接器怎么同步、定时任务怎么落地的内容很少。这篇文章就从零开始整理一套 WorkBuddy 从安装到落地实操的完整路径新手可以跟着一步步搭已经上手的开发者也可以直接跳到核心配置和排查清单部分。1. WorkBuddy 是什么解决什么问题1.1 先从工作中的“AI 碎片化”说起过去一年很多人电脑里同时装了四五款 AI 工具写文档用一个画图用一个处理表格用一个编程助手又用一个。工具之间互相不打通上下文也无法共享每次换工具都要重新把背景资料粘贴一遍真正消耗时间的不是 AI 能力不够强而是“搬运上下文”的过程太繁琐。这种情况在团队协作里更明显。同一个项目资料分散在钉钉文档、本地 Markdown、多维表格、企业网盘里AI 虽然能回答问题但回答不了“基于最新数据做一份周报”这种需要跨系统读取数据的任务。痛点不在于某一个模型不够聪明而在于 AI 没有“手脚”无法主动去连接和读写外部系统。1.2 WorkBuddy 的定位效率智能体工作台WorkBuddy 可以理解成一个“AI 代理助手 本地模型 工作流编排”的效率智能体工作台。它不只是提供一个对话框而是把下面几类能力整合在一起能力模块作用解决什么问题模型接入层接入在线大模型或本地推理服务统一对话与任务处理入口Skill技能定义 AI 的角色、指令、输出格式让 AI 按岗位职责工作而不是每次重新描述连接器Connector打通外部系统如钉钉、多维表、Obsidian 等让 AI 能读取和写入业务数据工作流把模型、技能、连接器串成自动化任务减少重复性人工操作定时任务按计划触发指定流程实现日报、周报、数据同步等自动化通俗一点说如果普通聊天工具是“随叫随到的实习生”那么 WorkBuddy 更像“一个可以被培养成正式员工的协作对象”你给它配置好岗位职责Skill给它开通系统权限连接器再把固定动作固化成流程工作流它就能在后台持续干活。1.3 WorkBuddy 与 CodeBuddy 的关系很多人在搜索时会同时看到 WorkBuddy 和 CodeBuddy容易混淆。简单区分一下CodeBuddy 更偏向“代码开发助手”围绕代码生成、代码解释、单元测试、Debug 等编程场景。WorkBuddy 更偏向“办公效率与业务工作台”围绕文档处理、数据整理、定时同步、自动化流程等日常业务场景。它们属于同一个生态体系下的不同方向产品底层可能共享一部分模型调度和 Agent 能力但使用场景和受众不同。选型时不需要纠结“哪个更好”只看你当下要做的是“写代码”还是“跑业务”。本文主要围绕 WorkBuddy 展开。1.4 适合哪些人使用经常写日报、周报需要从多个数据源汇总信息的职场人。需要把 AI 接入本地文档库、知识库、多维表格的团队协作人员。希望在本地服务器部署模型数据不出内网的企业用户。对自动化流程感兴趣想让 AI 定时执行任务的效率爱好者。刚接触 WorkBuddy想系统了解概念、安装、配置、排错的新手。2. 环境准备与安装部署2.1 运行环境说明WorkBuddy 的发行版本比较多Windows、Linux、macOS 都有对应安装包甚至有面向国产操作系统的适配版本。不同版本在界面和功能名称上会有差异但核心思路一致。建议安装前先确认下面几项检查项建议操作系统Windows 10/11、主流 Linux 发行版、macOS系统架构优先 x86_64ARM 架构先确认是否有对应安装包网络环境需要能访问 WorkBuddy 服务端或本地模型推理服务模型服务如果没有在线模型 Key需要准备本地模型推理服务磁盘空间预留足够空间本地模型通常需要数 GB 到数十 GB依赖软件某些 Linux 版本需要安装基础图形库或运行时组件有一个容易被忽略的点如果你打算在服务器上使用无界面模式需要确认目标版本是否提供命令行或服务端部署方式。WorkBuddy 的 Linux 版本在服务器场景下可以通过命令行启动但部分功能依赖图形界面建议先在桌面环境完成基础配置再迁移到服务器。2.2 下载与安装安装包建议从官方渠道获取。不要从不明来源下载所谓“破解版”“绿色版”因为你无法保证安装包是否被植入恶意代码而且这类工具通常需要连接模型服务和业务系统安全风险会成倍放大。Windows 安装大致流程下载对应系统架构的安装程序。双击运行按提示完成安装。如果系统提示“未知发布者”先校验文件哈希并确认来源可靠。首次启动时在系统设置中确认防火墙没有拦截 WorkBuddy 的正常通信。Linux 安装需要根据发行版选择安装包类型。如果你是 Debian/Ubuntu 系常见的安装方式类似# 示例命令具体包名以实际发布版本为准 sudo dpkg -i workbuddy_x.x.x_amd64.deb # 如果提示依赖缺失先执行 sudo apt-get install -f如果是免安装的压缩包解压后进入目录直接运行主程序tar -zxvf workbuddy-linux-x64.tar.gz cd workbuddy-linux-x64 chmod x workbuddy ./workbuddy麒麟版本的系统通常走类似的软件包安装流程个别环境可能需要配置软件源或安装内核兼容组件按官方文档说明操作即可。2.3 首次启动与登录第一次启动 WorkBuddy 时一般需要完成账号登录和初始化配置。登录后建议先做三件事修改默认配置确认模型接口是否可用。创建自己的第一个工作空间明确这个空间主要存放哪类任务。检查设置页面里的目录和缓存路径避免后续数据都堆积在系统盘。有用户反馈过“WorkBuddy 目录前面有个.”的现象这通常是因为配置目录被命名成了以点开头的隐藏目录比如.workbuddy。这类目录在文件管理器中默认不可见扫描或同步时容易忽略排查问题时可以先开启隐藏文件显示选项。2.4 版本选择建议版本信息变化比较快不建议死记某个版本号。策略是“优先选择稳定版”在官网或更新日志中查看当前稳定版然后根据功能需求决定是否升级。如果项目已经跑了一段时间升级前先备份配置目录和 Skill 目录。 WorkBuddy 的升级一般不会清空用户数据但跨大版本升级时配置字段可能变化保守做法是先看更新说明再看配置文件是否有兼容性调整。3. 核心概念与配置拆解3.1 模型接入在线模型与本地模型WorkBuddy 本身不直接包含大模型推理能力它更像是一个模型调度和任务编排框架。所以使用前需要先接入模型服务通常有两条路线。第一条路线是接入在线模型 API。需要在模型服务商处获取 API Key然后在 WorkBuddy 的模型配置中填写接口地址、模型名称和密钥。大多数兼容 OpenAI 协议的服务都可以通过这种方式接入配置项大致如下# 模型配置示例字段名以实际版本为准 model.provideropenai-compatible model.base_urlhttps://api.example.com/v1 model.api_keysk-xxxxx model.nameqwen-plus第二条路线是接入本地模型。如果你的数据敏感或者公司要求数据不能出内网可以把模型部署在内网服务器上再通过 OpenAI 兼容协议让 WorkBuddy 调用。以常见的推理框架部署千问系列模型为例思路如下在内网服务器启动一个 OpenAI 兼容的服务。确认 WorkBuddy 所在机器能访问该服务地址。在 WorkBuddy 模型配置中把 base_url 指向内网地址例如http://192.168.1.10:8000/v1。输入模型名称密钥可以留空或使用框架默认的占位符。注意本地部署大模型对显存和内存要求较高7B 量级的模型通常需要至少 16GB 内存或 8GB 以上显存才能流畅运行模型量化版本会低一些。如果你在办公电脑上跑建议先用小参数模型验证效果再决定是否升级硬件或使用更大模型。有用户问“千问 3.8 本地部署到 WorkBuddy 效果怎么样”这类模型规模较小适合验证流程但复杂任务的处理能力与大模型有一定差距不要期待本地小模型在所有场景都达到在线大模型的效果。3.2 Skill给 AI 定义“岗位说明书”Skill 是 WorkBuddy 里最重要的自定义能力。它本质上是一份结构化的指令文件告诉 AI“你是什么角色、要做什么、按什么格式输出、有哪些注意事项”。很多新手不理解为什么要单独写 Skill直接在对话框里说清楚不就行了区别在于对话框里的指令是一次性的每次新对话都要重新说一遍Skill 是持久化的只要被触发AI 就会自动带入对应的角色设定和输出规范。对于高频场景比如写周报、总结会议纪要、整理待办事项效果提升非常明显。一个 Skill 通常包含以下几个部分组成部分作用示例角色定义让 AI 明确自己扮演的角色你是一个资深的项目助理任务描述说明需要完成什么任务根据会议记录生成行动项列表输入参数定义任务所需的变量会议记录文本输出格式规定结果如何呈现使用 Markdown 表格约束条件限制 AI 的行为边界不要编造不存在的结论以“会议纪要与行动项提取”为例Skill 的核心内容大致如下# 角色 你是一名专业的会议纪要整理助手擅长从冗长的会议记录中提取关键信息。 # 任务 根据用户提供的会议记录输出三个部分 1. 会议结论 2. 待办事项 3. 风险提醒 # 输入参数 - meeting_notes原始会议记录文本 # 输出格式 使用 Markdown 格式待办事项必须包含负责人和截止时间。 # 约束 - 不要修改原始记录中的事实性内容。 - 如果信息不完整必须在“风险提醒”中标注缺失信息。实际使用时不同版本的 WorkBuddy 对 Skill 文件的格式要求可能不同。建议先查看软件内的“技能市场”或“Skill 模板”基于官方模板改参数而不是凭空写一份完全自定义的文件这样可以避免语法不兼容问题。3.3 连接器打通外部系统连接器是 WorkBuddy 从“会聊天”走向“能干活”的关键。通过连接器AI 可以读取多维表格、同步文档、发送消息、更新任务状态等。配置连接器的过程核心是授权和权限控制。以对接“钉钉多维表”定期同步为例基本流程如下在目标系统后台创建应用获取 API 凭证。确认需要访问的数据范围尽量只授权最小权限。在 WorkBuddy 中新建连接器填写 API 地址和凭证。测试连接确认能正常读取数据。创建定时任务让 WorkBuddy 按周期同步数据。这里需要特别提醒连接器涉及业务系统数据务必遵循“最小权限原则”。如果只需要读取数据就不要授予删除或写入权限。生产环境的同步任务建议先在测试环境中验证连接器的读写范围确认无误后再切换到真实业务数据。3.4 工作流把能力串起来单个 Skill 解决单点问题连接器解决数据通道问题工作流则负责把多个步骤编排成一个完整任务。比如“每天早上 9 点读取多维表中的项目进度调用模型生成项目日报推送到群机器人”这个任务就可以拆成三步定时触发。连接器读取数据。模型基于数据生成日报。工作流的价值在于“无人工干预”。只要配置完成AI 会按照预定节奏执行任务。第一次配置工作流时建议先手动执行一次确认每一步输出都符合预期再开启自动触发。否则定时任务一旦跑起来错误结果会持续产生。4. 完整实战搭建一个晨间工作台4.1 需求分析接下来用一个实战案例把前面的概念串起来。假设你是项目组成员每天早上的固定动作是打开本地任务文件、查看待办、把当日优先级最高的三件事整理成晨间计划输出到指定文档。这个操作重复性高、内容机械非常适合交给 WorkBuddy 自动化。需求拆解如下编号需求技术实现1读取本地任务文件文件读取能力或连接器2让 AI 分析任务优先级Skill 指令3生成晨间计划文档输出到指定目录4每天定时执行计划任务这个案例不依赖复杂的外部系统本地文件即可完成闭环很适合新手第一次跑通“Skill 自动化”流程。4.2 项目结构在本地创建一个工作目录结构如下workbuddy-morning/ ├── data/ │ ├── tasks.md # 原始任务清单 │ └── output/ # 生成的晨间计划输出目录 ├── skills/ │ └── morning-plan.md # 晨间计划 Skill └── scripts/ ├── generate_plan.py # 生成计划的辅助脚本 └── run_task.sh # 定时任务入口脚本tasks.md是每天手工维护的任务清单格式可以自由约定。这里用最简单的列表格式- [ ] 完成项目周报初稿 - [ ] 确认下周迭代排期 - [ ] 修复登录页样式问题 - [ ] 阅读竞品分析文档 - [ ] 整理客户反馈汇总表4.3 编写晨间计划 Skill在skills/morning-plan.md中定义晨间计划 Skill# 角色 你是一名高效的项目晨间规划助手帮助用户从任务清单中提炼当日重点工作。 # 任务 读取用户提供的任务清单按如下要求输出晨间计划 1. 分析每个任务的紧急程度和重要性。 2. 选出最重要的三件事说明理由。 3. 为每件事给出建议执行时间段。 4. 将完整结果写入指定输出文件。 # 输入参数 - task_list任务清单文本 - output_path输出文件路径 # 输出格式 按照以下 Markdown 模板输出 ## 今日重点 1. [第一优先级任务]理由 建议时间段 2. [第二优先级任务]理由 建议时间段 3. [第三优先级任务]理由 建议时间段 ## 其他事项 - 事项一 - 事项二 ## 执行建议 - 建议上午优先处理需要深度专注的任务 - 建议下午处理沟通协作类任务Skill 文件本质上是给模型看的“行为准则”里面的内容越明确输出越稳定。很多人写的 Skill 太宽泛比如“帮我整理任务”效果自然一般。你需要告诉 AI 它是什么角色、输入是什么、输出长什么样、有哪些边界。4.4 编写辅助脚本为了让 Skill 能真正触发并读取文件、输出结果可以准备一个简单的 Python 脚本负责读取任务文件、调用模型接口、写入结果。# 文件路径workbuddy-morning/scripts/generate_plan.py import sys from pathlib import Path def read_task_file(task_path: str) - str: 读取任务清单文件 path Path(task_path) if not path.exists(): print(f[ERROR] 任务文件不存在: {task_path}) sys.exit(1) return path.read_text(encodingutf-8) def build_prompt(skill_content: str, task_content: str) - str: 将 Skill 内容与任务内容组合成完整提示词 return f{skill_content}\n\n任务清单\n{task_content}\n/任务清单 def save_output(content: str, output_path: str) - None: 保存模型输出到指定文件 path Path(output_path) path.parent.mkdir(parentsTrue, exist_okTrue) path.write_text(content, encodingutf-8) print(f[INFO] 晨间计划已生成: {path}) if __name__ __main__: # 使用方法: python generate_plan.py skill_path task_path output_path if len(sys.argv) ! 4: print(Usage: python generate_plan.py skill task output) sys.exit(1) skill_file sys.argv[1] task_file sys.argv[2] output_file sys.argv[3] skill_content Path(skill_file).read_text(encodingutf-8) task_content read_task_file(task_file) prompt build_prompt(skill_content, task_content) print( * 40) print([INFO] 以下内容将发送给模型) print( * 40) print(prompt) print( * 40) # 注意这里只演示了提示词组合方式。 # 实际使用时需要调用 WorkBuddy 的 API 或命令行接口 # 将 prompt 发送给模型并接收返回结果。 # 不同版本的调用方式不同请根据官方文档调整。 result 此处替换为模型返回的晨间计划内容。 save_output(result, output_file)这个脚本的重点是演示“Skill 任务清单 - 提示词 - 输出文件”这条链路。实际项目中你需要把“调用模型接口”的部分替换为 WorkBuddy 提供的调用方式。如果你使用的是命令行版本的 WorkBuddy可能已经有对应的 CLI 参数可以直接传 prompt 文件路径。4.5 创建定时任务整个流程跑通后可以创建定时任务实现每天自动执行。Linux / macOS 使用 crontab 示例# 每天 09:00 执行晨间计划生成任务 0 9 * * * cd /path/to/workbuddy-morning bash scripts/run_task.shrun_task.sh内容如下#!/bin/bash # 文件路径workbuddy-morning/scripts/run_task.sh set -e cd $(dirname $0)/.. # 生成带日期的输出文件名 DATE$(date %Y-%m-%d) OUTPUT_FILEdata/output/morning-plan-${DATE}.md # 调用 Python 脚本生成提示词并调用 WorkBuddy 完成输出 python3 scripts/generate_plan.py \ skills/morning-plan.md \ data/tasks.md \ ${OUTPUT_FILE} echo [INFO] 定时任务执行完成${OUTPUT_FILE}Windows 环境下可以使用“任务计划程序”来创建每天定时运行的脚本核心逻辑一致只是触发方式不同。4.6 运行与验证手动运行流程验证cd workbuddy-morning python3 scripts/generate_plan.py skills/morning-plan.md data/tasks.md data/output/morning-plan-test.md预期结果分两部分。第一部分是在终端看到组合好的提示词内容确认 Skill 和任务清单是否正确拼接第二部分是检查data/output/morning-plan-test.md是否生成内容是否为符合模板要求的晨间计划。第一次运行时不要急着接模型先把文件读取、路径、输出保存这些本地逻辑跑通。本地链路稳定后再接入模型调用。这是自动化项目最稳妥的上手顺序。4.7 结果说明这个案例看似简单实际上覆盖了 WorkBuddy 落地的三个关键点Skill 的编写思路通过结构化指令约束模型行为。文件输入输出让 AI 能读本地任务、写本地结果。定时触发的工程化让整个流程无人值守。如果这个案例能跑通接下来就可以把“本地任务文件”换成“钉钉多维表”把“输出 Markdown”换成“推送到群机器人”逐步扩展成更复杂的业务自动化流程。5. 常见问题与排查思路5.1 高频问题速查表问题现象常见原因解决思路启动后提示网络连接失败 3002网络不通或服务端地址填错检查网络、域名解析、代理设置模型一直不回复模型接口配置错误或模型名称不匹配先用官方测试工具验证模型接口连接器列表里找不到某个连接器版本不支持或企业版功能差异核对版本和功能矩阵Skill 生效但输出不稳定指令描述太模糊细化角色、输入、输出和约束定时任务没执行路径不对或权限不足检查日志、脚本路径、执行权限目录名称前面带点导致找不到隐藏目录未被扫描开启隐藏文件显示或重命名为普通目录本地模型响应慢显存不足或量化等级低换小模型或升级硬件Linux 下无法启动缺少图形库或运行组件查看启动日志并安装依赖5.2 网络连接失败 3002这是被问得最多的一个问题。报错 3002 通常不是 WorkBuddy 本身的 Bug而是网络链路问题。排查顺序如下检查 WorkBuddy 所在机器能否正常访问外网或内网服务。确认模型服务地址是否填写正确特别是http/https协议和端口。查看系统代理设置。开发机经常开了代理导致本地服务访问也被转发。检查防火墙是否拦截了 WorkBuddy 进程的对外通信。查看 WorkBuddy 的日志文件定位具体是哪个请求失败。如果你不需要访问外网服务可以尝试关闭系统代理后再启动 WorkBuddy很多 3002 报错其实是代理把本地请求“劫持”了。5.3 模型接入后没有预期效果模型接入成功但回答效果不好先不要急着换模型按下面顺序优化确认 WorkBuddy 实际调用的模型名称和你在配置里写的是否一致。检查是否启用了 Skill如果没有触发 SkillAI 只会按默认聊天模式回复。检查提示词是否提供了足够上下文。同样的模型给“请总结”和给“你是周报助手以下是本周数据请按三部分输出周报”效果差距很大。确认上下文长度限制。传入的资料过多时模型可能截断早期内容导致回答缺失。5.4 连接器数据不同步如果配置了“钉钉多维表定期同步”但没有生效重点检查三处凭证是否过期。很多平台的 API Token 有有效期过期后需要重新授权。权限范围是否正确。如果应用没有申请对应数据表的读取权限接口会返回 403 或权限错误。定时周期是否合理。频繁调用可能导致接口限流建议按平台配额设置同步间隔。5.5 排查清单遇到问题时按照以下清单逐项检查比盲目重装更高效[ ] 查看 WorkBuddy 运行日志定位第一次异常报错的时间点。[ ] 确认配置文件路径、文件名、字段值没有拼写错误。[ ] 用测试脚本单独验证模型接口是否可以正常返回。[ ] 检查磁盘空间和系统资源占用。[ ] 备份配置目录尝试恢复默认配置。[ ] 在官方论坛或文档中搜索相同报错码。[ ] 确认版本是否为最新稳定版必要时升级后再测试。6. 最佳实践与工程建议6.1 先在最小场景上跑通闭环这是给新手最重要的一条建议。不要一开始就试图配置一个“全自动企业级工作流”而是应该从“读一个文件、调用一次模型、输出一个结果”这种最小闭环开始。最小闭环跑通后你才能区分问题是出在模型、连接器、网络还是 Skill 配置上。很多人的项目死在“配置到一半不知道哪一步错了”就是因为一开始就把范围铺得太大。6.2 Skill 设计遵循“角色 任务 输入 输出 约束”写 Skill 时不要只写“帮我做 XX”而是按照五段式结构组织内容角色让 AI 明确身份。任务说清楚要做什么。输入定义好变量位置。输出规定输出格式。约束说明不能做什么。一份好的 Skill能让同一个模型在不同场景下表现稳定。一份差的 Skill即使底层是强模型输出依然会飘。6.3 连接器权限遵循最小化原则凡是涉及外部系统的连接器都要像一个严格的权限管理员一样审查授权范围。如果只需要读取数据就不要开写入权限如果只需要读取某个表就不要授予整个空间的权限。生产环境建议使用独立的应用凭证而不是个人账号的 Token。万一凭证泄露影响范围可以控制在该应用权限范围内。6.4 配置与数据定期备份WorkBuddy 的配置目录、Skill 文件、连接器配置、工作流定义都需要纳入备份体系。建议做法将 Skill 文件放入 Git 仓库记录每次修改历史。将配置文件导出并保存到独立目录。定时任务执行前自动备份目标数据文件。升级版本前手动备份完整配置目录。备份成本很低但能避免配置丢失后的重复劳动。6.5 定时任务要关注幂等性定时任务每天反复执行如果任务不是“幂等”的就可能产生重复数据。简单解释幂等就是“同一个任务执行一次和执行一百次效果相同”。比如生成日报时如果每次执行都追加一条记录第二次执行就会产出重复内容如果每次执行都覆盖同一个文件或按日期生成独立文件就不会造成重复。在设计 WorkBuddy 的定时任务时尽量让每次执行的结果可覆盖或可追溯。推荐按日期生成独立输出文件同时在日志中记录每次执行的时间、输入、输出路径和状态。6.6 从日常高频重复场景切入落地如果你不知道从哪个场景开始用 WorkBuddy就从你每周重复三次以上的工作中找。整理周报、同步表格、汇总文档、写例会纪要这些任务看起来简单但跨系统数据搬运的时间成本很高。把这些高频小任务自动化比做一次性的复杂流程更能体现 WorkBuddy 的价值。6.7 注意企业环境的安全合规要求在给企业部署 WorkBuddy 时提前确认数据是否可以发送到外部模型服务。如果公司对数据出境有严格要求需要采用本地模型部署方案确保业务数据始终在内网环境处理。同时不要将业务系统的密钥硬编码在 Skill 或脚本中建议通过环境变量或密钥管理模块读取敏感信息。# 示例通过环境变量注入 API Key避免明文写死在配置文件中 export WORKBUDDY_MODEL_API_KEYsk-xxxx export WORKBUDDY_CONNECTOR_TOKENtoken-xxxx6.8 关注官方更新与社区方案WorkBuddy 的功能迭代速度很快连接器种类、Skill 模板、模型接入方式都可能变化。建议不定期查看官方更新日志同时关注社区中用户分享的实战案例。别人已经踩过的坑可以直接避开。特别是新版本增加连接器或 Skill 协议调整时旧配置可能无法直接复用升级前务必阅读官方迁移指南。7. 最后想说的话WorkBuddy 这类效率智能体工作台真正的上手门槛不在“会不会用对话框”而在于“能不能把工作流拆解成模型、技能、连接器、定时任务四个模块”再逐一把它们拼起来。文章里的晨间工作台案例虽然简单但它代表了一条完整的落地路径先定义输出目标再设计 Skill 约束模型行为然后用脚本打通输入输出最后用定时任务固化执行频率。照着这个路径复刻一遍你对 WorkBuddy 的理解会比单纯看十篇介绍文章都深。下一步你可以继续尝试的方向接入本地千问模型验证内网推理效果、把钉钉多维表接入连接器实现业务数据同步、用 WorkBuddy 做 UI 自动化测试任务、或者把 Obsidian 笔记库变成 AI 的知识库来源。这些都是很好的实战选题等有机会我再逐个展开写一写。如果你在配置 WorkBuddy 时遇到问题欢迎在评论区留言也可以先收藏这篇文章当作排错手册。希望这篇教程能帮你少走一些弯路把一个真正能落地的 WorkBuddy 工作台搭起来。