workbuddy 的核心是“能动手的本地ai同事”，强调所有敏感操作在授权本机沙箱内执行，不上传原始数据；自动化基于任务驱动闭环，智能化体现为分层模型路由与技能协同。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 的核心理念不是“更聪明的聊天框”，而是“能动手的本地AI同事”。它把「本地化」当作前提，把「自动化」当作路径，把「智能化」当作调度能力——三者缺一不可，但最容易被误读的是第一点：本地化 ≠ 仅在本地运行，而是指**所有敏感操作、文件读写、软件调用都发生在你授权的本机沙箱内**，不上传原始数据，不绕过系统权限。
为什么必须强调本地化执行？
很多用户第一次用 WorkBuddy 时，默认它和网页版AI一样“发指令→云端处理→返回结果”。实际不是：WorkBuddy 在 Windows/macOS 上启动的是一个真实进程，它通过系统级 API 调用 Excel、PowerPoint、Chrome 等本地应用，直接打开、编辑、保存你指定路径下的文件。这意味着：
- 你给它的
C:\data\sales_q1.xlsx不会离开你的硬盘； - 它生成的 PPT 是调用本地 Office COM 接口插入图表，不是用 Canvas 渲染假图；
- 当它说“已将报告发到企业微信”，本质是调用你电脑上已登录的
wecom.exe进程完成发送，而非走网页 API。
这种设计带来两个硬约束：一是必须安装完整版 Office（WPS 不完全兼容 COM）；二是 macOS 用户需手动开启“辅助功能”权限，否则无法操作 Finder 或 Pages。
WorkBuddy 自动化不是定时脚本，而是任务驱动闭环
它的自动化不依赖 cron 或 launchd，而是基于「自然语言任务解析 → 技能匹配 → 步骤编排 → 执行反馈」的实时闭环。例如指令“每周一早9点抓取行业新闻并存为PDF发我邮箱”，WorkBuddy 会：
- 自动识别时间触发条件，注册到本地任务调度器（Windows 用 Task Scheduler，macOS 用 launchd）；
- 调用内置
browser_automation技能包启动无头 Chrome； - 用
pdfkit（需 Node.js 环境）将页面转为 PDF，而非截图； - 调用系统默认邮件客户端（如 Outlook 或 Mail.app），不走 SMTP 配置。
关键点在于：整个链路中每个环节都可被单独调试。比如某次失败，直接看 .workbuddy/logs/2026-04-11.md 就能定位是浏览器超时，还是 PDF 生成时字体缺失——而不是面对一个黑盒“任务失败”提示干瞪眼。
智能化体现在模型路由与技能协同，而非单一大模型能力
很多人以为换用更强的大模型就能提升 WorkBuddy 表现，其实不然。它的智能是分层的：
- 意图识别层：用
Hunyuan快速判断“整理销售数据”是否含清洗、去重、分组等子动作； - 工具选择层：根据文件后缀和操作目标，决定调用
xlsx技能还是csv_parser技能； - 执行校验层：用
DeepSeek对生成的图表标题做逻辑一致性检查（比如柱状图最大值是否真对应表格中最大数值）。
这就是为什么设置里要手动切换模型——不是为了“更好写文案”，而是让不同环节各司其职。若强行让 Kimi 处理 Excel 公式推导，反而容易出错。
最常被忽略的一点是：所有本地操作都依赖 .workbuddy/config.json 中的 workspace_root 配置。如果这个路径指向了 OneDrive 同步目录或 iCloud Drive，某些文件锁或延迟同步会导致任务静默失败。务必确认该路径是纯本地 NTFS/HFS+ 分区，且有完整读写权限。
