Obsidian + Workbuddy 搭建第二商业大脑：AI 工作流与知识库双链联动实战

Workbuddy 和 Obsidian 放到同一个工作流里之后，我最大的感受不是“效率翻倍”，而是“终于不用来回搬运内容了”。

如果你也在搭自己的知识库，大概率已经被 Obsidian 的双链和插件体系吸引过；如果你也天天要用 AI 办公，那 Workbuddy 这类智能工作台估计也没少试。但问题往往出在这里：AI 聊天记录不会自动变成你的知识库，Obsidian 也不会主动替你干活。把这两者打通，“第二商业大脑”才真正成立——它负责记忆你的客户、项目、业务流程，它负责检索信息、生成方案、执行自动化。

这篇文章就是我实际操作中摸索出来的完整方案。我会从最底层的设计思路讲起，然后一步步告诉你 Obsidian 怎么搭、Workbuddy 怎么接、Dataview 怎么写、连接器怎么做，最后会把我踩过的坑也一起交代。适合正在做知识库但不知道怎么和 AI 工作流结合的人，也适合手里已有的商业资料、客户记录、项目进度不知道往哪放的人。看完之后，你应该能搭出一个属于自己的最小可用版本，而不是收藏完就吃灰。

1. 第二商业大脑到底是干什么的——先想清楚再动手

很多人一听到“第二大脑”就开始疯狂收集笔记、做双链、装一堆插件，结果系统越建越复杂，真正要用的时候却找不到东西。我建议你先别碰工具，先把“第二商业大脑”到底该干什么这件事想清楚。

1.1 它不是知识库，也不是聊天助手

如果只把 Obsidian 当成“能双向链接的笔记软件”，那你存再多内容它也只是一个高级网盘；如果只把 Workbuddy 当成“能聊天的 AI”，那它每次对话结束记忆基本就归零。

第二商业大脑应该是这两者的结合：既要能长期存储和沉淀商业信息，又要能根据这些信息执行推理和行动。一句话概括就是——快思考归 Workbuddy，慢思考归 Obsidian。

Obsidian 负责“慢”的那一端：把客户信息、项目复盘、行业资料、SOP 流程稳稳地落成本地文件，用双链建立关系，用 Dataview 做动态汇总。Workbuddy 负责“快”的那一端：根据 Obsidian 里的内容快速生成周报、提炼要点、起草方案，甚至通过连接器调用外部系统，把思考结果转化为下一步行动。

这两者不是替代关系。Obsidian 解决不了“自动写方案”的问题，Workbuddy 也解决不了“长期记忆持久化”的问题。拼在一起，才算是商业大脑。

1.2 为什么非得是 Workbuddy + Obsidian

这套组合的优势在于：两端都非常“开放”。

Obsidian 的底层就是本地 Markdown 文件，没有绑定任何云服务，文件在哪、你想怎么处理它，完全由你控制。这意味着 Workbuddy 可以直接读写这些文件，或者通过本地 API 访问它们，而不需要像传统笔记软件那样去折腾繁琐的导入导出。

Workbuddy 这类智能工作台的强项则在于它不只是“聊天窗口”。它有自己的技能模块（官方和社区通常叫 skill），可以把常用工作流固化成指令；它也支持通过连接器或 API 调用外部工具，让 AI 不只是给建议，而是真正把活干了。

我把它俩的职责拆成一张表，方便你理解分工：

要注意，我不是让你把所有商业信息都往这套系统里塞。第二大脑的目的是帮你在需要的时候调用信息，不是让你当数字仓鼠。建之前，建议你先列出自己最高频的 3 类业务场景，比如“客户跟进”“项目复盘”“内容输出”，围绕这些场景设计系统，而不是按“知识的学科分类”去设计。

1.3 设计前最重要的一个心态：避免过度设计

我在 Obsidian 中文社区里见过非常多人，一开始就研究各种主题、CSS 片段、自动化脚本，甚至为了一个 Dataview 查询折腾一个晚上。这其实是把“搭建系统”本身当成了主业，反而忽略了最重要的东西：这个系统到底帮你促成了哪笔生意、做了哪个决策、节省了多少时间。

所以我的建议是第一次只做“最小闭环”：能存、能查、能被 Workbuddy 读到，就够了。后续用着不舒服再加。后面所有内容我都按这个思路来展开，你不需要三天搭完，最好一个下午就跑通。

2. 前期准备：Obsidian 和 Workbuddy 的环境搭建

这个环节最容易把人劝退，因为 Obsidian 下载和插件安装对国内用户来说经常不顺利。我这里多说几句实操层面的东西。

2.1 Obsidian 下载慢怎么处理

先说一个很多人卡住的问题：“Obsidian 下载太慢了”。其实 Obsidian 官方包体积不算大，几十兆而已，慢主要是因为它默认下载源在境外，国内直连经常不稳定。

我实测下来比较有效的做法有这几个：

• 不要只盯着官网下载按钮，试试 Obsidian 中文社区的镜像下载帖，很多热心用户会定期同步安装包。
• 用带多线程的下载工具（比如 IDM、迅雷）去抓官网直链，速度通常能提升不少。
• 如果公司内网有软件分发平台，有时候能直接找到 Obsidian 安装包。
• macOS 用户如果装了 Homebrew，也可以试试brew install --cask obsidian，走的是 GitHub 资源，某些网络环境下会更稳。

下载之前要注意：Obsidian 个人使用免费，不存在“需要破解”的说法。网上那种所谓“破解版/加速版”安装包反而可能篡改内容，完全没必要去碰。

安装完之后，第一次启动会让你选择“创建新库”还是“打开已有文件夹”。我强烈建议你就把 Obsidian 库建在一个你自己能找到的、有备份习惯的目录下，不要藏在系统默认路径里，因为后面 Workbuddy 要读这个文件夹，路径越短越清晰越好。

2.2 Workbuddy 安装与本地部署的取舍

Workbuddy 这块我要先说明一下：不同发行渠道出来的版本，界面和功能细节会有差异。如果你是从官方应用商店或网站下载的，通常有云端账号版和本地部署版两种形态。云端版开箱即用，本地部署版适合数据敏感场景。

个人用户我建议先用云端版跑通流程。为什么？因为本地部署虽然听起来很“极客”，但你需要自己准备大模型 API Key、处理 Docker 运行环境、维护模型调用成本，这一套下来已经把精力耗掉了大半，而你要解决的问题其实是“如何用 AI 处理商业资料”，不是“如何运维一套本地模型”。

本地部署真正有意义的场景是：你的客户资料、财务数据属于敏感信息，不允许上传到第三方云端；或者你所在的公司有数据合规要求，要求所有内容必须留在内网。这种情况下你再考虑用 Docker 起一套 Workbuddy，并把大模型切换成内网可访问的私有化服务。冷启动成本不低，业务价值需要你自己评估。

顺带解决一个很多人搜过的疑问：Workbuddy 和 CodeBuddy 到底啥区别？我个人的理解是，CodeBuddy 这类产品更偏“代码智能体”，围绕写代码、改 Bug、代码评审展开；而 Workbuddy 更偏“办公/业务智能体”，围绕文档、客户、项目、流程自动化展开。所以如果你只是写业务代码，用哪个顺手就用哪个；如果你的目标是搭商业大脑、让 AI 帮你处理 Obsidian 里的业务资料，那 Workbuddy 的路径是更匹配的。

2.3 让 Workbuddy 能“看到” Obsidian

这是整套方案里最关键的一步。Workbuddy 默认不知道你 Obsidian 库存了什么，你必须给它一个访问入口。我在实际项目里试过三种方式，各有适用场景：

方式一：Workbuddy 本地部署，直接读写 Obsidian 库文件夹如果你把 Workbuddy 部署在本机，那它天然能访问本地文件系统。你可以把 Obsidian 库路径配置给它，让它直接创建.md文件、修改已有笔记。优点是最直接，缺点是只能适用于本机，而且如果 Obsidian 正在运行、两边同时改同一个文件，有概率产生冲突。

方式二：Obsidian Local REST API 插件Obsidian 有个社区插件叫 Local REST API，装好之后会在本地起一个 HTTP 服务，允许外部程序通过 API 读取、搜索、创建笔记。Workbuddy 通过这个接口就能操作 Obsidian。这个方案的好处是 Obsidian 正在运行时也可以实时读写，不用碰文件底层，而且你可以在 Workbuddy 侧配置认证，避免任何程序都能访问你的库。

方式三：Workbuddy 生成内容 + 手动/脚本落盘最朴素的方式：先让 Workbuddy 生成好 Markdown，再复制粘贴进 Obsidian，或者用自动化脚本保存到库目录。这种方式不适合大批量，但作为新手上手探索 Workbuddy 能力边界是完全够用的。

我个人的建议是：直接上方式二。理由很实际——Local REST API 的生态比较成熟，配置一次之后，Workbuddy 每次读写都会以“当前正在运行的 Obsidian”为准，不会出现文件没刷新的问题。后面我会说具体怎么配。

2.4 最小验证：让 Workbuddy 在 Obsidian 里新建一条笔记

环境搭完之后，别急着搞复杂业务，先做一个最小验证：

1. 在 Obsidian 里安装并开启 Local REST API 插件。
2. 在插件设置里记下 API Key。
3. 在 Workbuddy 的自定义连接器或技能配置中，新增一个 HTTP 请求，地址填https://127.0.0.1:27124/commands/append，请求头带上 API Key。
4. 给 Workbuddy 下一条非常简单的人类指令：“请在 Obsidian 的 00 Inbox 目录下新建一条笔记，标题为测试，内容为‘连接成功’。”

如果 Workbuddy 能正确执行、Obsidian 里出现了这条笔记，那么恭喜你，基础设施已经通了。剩下的事就是在这个通道上不断叠加场景。

3. Obsidian 知识库底层怎么搭：先让信息能“长”出来

现在到了搭知识库结构的部分。这一章解决一个问题：为什么你的 Obsidian 库用了很久还是像一锅粥，以及怎么从一开始就避免这种混乱。

3.1 目录结构别按“学科”分，按“业务流”分

很多 Obsidian 教程会教你把笔记分成“工作”“学习”“生活”“灵感”这种大类。如果你要搭的是第二商业大脑，这个分类法其实不好用——因为商业场景是围绕“客户”“项目”“产出”流转的，不是围绕“科目”流转的。

我自己的库结构是下面这样的，你可以照抄再改成自己业务的名字：

Obsidian 根目录/ ├── 00 Inbox/ # 所有待处理、未消化的内容 ├── 10 Clients/ # 客户档案目录，每个客户一个子目录 │ ├── 客户A/ │ ├── 客户B/ ├── 20 Projects/ # 项目目录，每个项目一个子目录 ├── 30 Knowledge/ # 通用知识库：方法论、行业研究、课程笔记 ├── 40 SOP/ # 可复用的业务流程、标准操作步骤 ├── 50 Templates/ # 所有笔记模板 ├── 90 Archive/ # 已完成项目、已结束客户，备份归档 └── 00 个人仪表盘.md # Dataview 汇总页

这套结构的关键是“数字前缀排序 + 业务对象隔离”。数字前缀帮你稳定排序，业务对象隔离让你知道一条笔记该放哪里，不用纠结。

Inbox 目录很重要。任何临时看到的内容，先丢进去，不急着分类。每周五我固定花半小时清理 Inbox：有保留价值的，移到对应客户、项目或知识库；没有价值的直接删。这一步能防止你陷入边收集边整理的状态。

3.2 每条笔记都要有“属性”，而不是只有正文

纯文字笔记很难被机器处理。Workbuddy 要想自动化操作你的 Obsidian，最好能读懂结构。所以从第一天起，你应该给关键笔记加上 YAML Frontmatter（笔记开头用---包裹的属性块）。比如客户笔记：

--- type: client customerid: C001 company: 某某科技 owner: 我 stage: 商务洽谈 followupdate: 2025-06-20 tags: - 重点客户 - 需要决策 ---

Dataview 插件就是靠这些属性来筛选、排序、生成动态列表的。你手动写一次属性，后面建仪表盘时就不用到处翻笔记了。

我见过很多新手因为“写属性太麻烦”而跳过这一步，结果三个月之后库里的东西就再也捞不出来了。解决办法很简单：用模板自动生成属性，而不是每次手敲。

3.3 Dataview：把笔记变成一张“会生长”的表格

Dataview 是 Obsidian 生态里最值得学的插件之一，它把 Obsidian 变成轻量数据库。你不需要精通代码，背几个查询就够用了。

假设你给客户笔记都加了上面那段属性，那你可以新建一个“客户仪表盘”笔记，写这样一段查询：

TABLE company, owner, stage, followupdate FROM "10 Clients" WHERE type = "client" SORT followupdate ASC

这会自动列出所有客户笔记，按下次跟进日期排序。每次你只要维护好客户笔记的属性，这个仪表盘会自动更新。

再比如，我想看所有“本周需要跟进”的客户：

TASK FROM "10 Clients" WHERE !completed

Dataview 还有几种查询方式，比如LIST、TABLE、TASK。你不需要全背，先记住TABLE ... FROM ... WHERE ... SORT ...这个语法就够了，其他用到再查。

3.4 双链、标签到底怎么用才不混乱

Obsidian 最出名的就是双链。但你不需要给每篇笔记都手工加链接。我自己的原则是：

• 双链表达“强关系”：客户和项目有关联，那么客户页里链到项目页；方法论笔记和具体案例有关联，双向链接起来。这种关系一旦建立，将来你顺着链接就能走完整个业务上下文。
• 标签表达“横切维度”：比如#需要决策、#待回复、#风险，这些不代表某个对象，而代表某种状态。标签一多就容易乱，所以我只保留几个“动作类”标签，不确定的宁可不打。
• 文件名表达“是什么”：数据库检索靠文件名和属性，命名规则保持稳定比啥都重要。我常用的格式是YYYY-MM-DD 主题或公司名-主题。

打个比方：双链是蜘蛛网，标签是便利贴。蜘蛛网用来找路，便利贴用来提醒状态，如果把每个挂钩、每根线都贴满便利贴，整个库就变成垃圾堆了。

3.5 模板和日常记录流程：把写笔记的成本压到最低

就算结构再好，如果写一条笔记要手动敲 10 分钟模板，你还是会放弃。所以 Obsidian 一定要配 Templater 插件。

简单做法是：在50 Templates/目录里新建“客户档案模板”“会议纪要模板”“项目复盘模板”，然后在 Templater 设置里给常用模板绑定快捷键或者命令面板提示。点一下，自动生成带日期、带属性的笔记骨架，你只需要往里面填内容。

我自己经常用的会议记录模板简化后是这样的：

--- type: meeting project: date: {{date:YYYY-MM-DD}} attendees: - tags: - 会议纪要 --- ## 背景 ## 讨论纪要 ## 结论与决策 ## 下一步行动 - [ ]

会议开完花三分钟把几个板块填掉，这条会议记录就成为项目上下文的一部分，以后 Workbuddy 读起来也能快速理解。

4. Workbuddy 实操：真正“用”起来而不是“聊”起来

环境通了，知识库也有了雏形，接下来就是 Workbuddy 开始干活的部分。这里我建议你把 Workbuddy 当成一个“能读你库、能写你库、能调用外部工具的实习生”，而不是一个搜索引擎。

4.1 让它读 Obsidian 时，指令要分三段

我刚开始用 Workbuddy 时，语气都是“帮我总结一下项目A”，结果它经常答得泛泛而谈，原因就是它没有指定信息源。后来我把指令改成三段式，效果立刻好了很多：

1. 指定来源：从哪里读。比如“读取20 Projects/项目A/目录下的所有会议纪要”。
2. 明确任务：要它做什么。比如“提炼出当前阻塞点，并按优先级排序”。
3. 指定输出：结果写到哪里、用什么格式。比如“用 Markdown 格式输出，保存到20 Projects/项目A/周报/2025-06-15-周报.md”。

你可以看到，本质上就是你给一个刚来的实习生分配任务的逻辑。你不说清楚资料在哪、你要什么产出，他就只能自由发挥，结果通常没法直接用。

实际对话可以这样说：

请先读取 Obsidian 库中20 Projects/项目A目录下最近 7 天的会议笔记和进展笔记。我需要你输出一份《项目A进展摘要》，内容包括：当前完成了什么、还有什么阻塞、下一步最应该做什么。最后把这份摘要保存为一个 Markdown 文件，放到20 Projects/项目A/下，文件名以当天日期开头。

Workbuddy 配合本地 API 可以把笔记读进来、生成内容、再通过 Local REST API 写回去。你会发现它产出的内容比直接空聊更有针对性，因为有“库内上下文”支持。

4.2 一个完整的示例：把客户访谈记录变成行动清单

光说抽象逻辑还不够，我给你演示一个我已经跑通的完整例子。

第一步，我在 Obsidian 的00 Inbox/放了一条从电话里整理出来的客户访谈笔记，里面是杂乱的顾客原话，比如“我们现在的采购审批很慢”“团队用的工具太多，信息经常对不上”这类内容。

第二步，我给 Workbuddy 下指令：

读取 Obsidian 库中00 Inbox/2025-06-10-客户X访谈记录.md。请完成三件事：

1. 把客户原始表达整理成 3 个核心痛点。
2. 每个痛点对应我们产品里的一条解决方案。
3. 最后输出一份《客户X访谈洞察》，保存到10 Clients/客户X/下，并在原访谈记录的“相关笔记”字段里加一个双链。

注意我特意让 Workbuddy 在输出里加上“在原记录加双链”，这样就保证了一条笔记不会孤立存在——访谈记录能找到洞察，洞察也能回溯到访谈。

第三步，Workbuddy 按指令跑完后，我再让它梳理下一步行动：

根据刚才生成的洞察，把最应该推进的 3 个动作生成一个 TODO 列表，追加到客户X笔记中，并按优先级排序。

做完这一步之后，Obsidian 就同时有了访谈原始素材、洞察分析、行动清单。Dataview 页面也会自动把客户 X 的下一步跟进时间标出来。整个过程不是让 AI 写一篇漂亮的文章给你看，而是把分析和行动直接变成知识库的一部分。

4.3 Skill 是把你的工作方法固化下来

Workbuddy 这类工具一般都有“技能”机制，你可以在里面预设 Prompt 和步骤，以后一键调用。

我用得最多的是一个叫“客户建档”的自定义技能。它的逻辑是：

1. 读取用户提供的访谈原始记录；
2. 提取客户公司、规模、需求、预算信号、决策链；
3. 按10 Clients/客户名/的目录结构生成初始档案；
4. 在档案中补上“待验证问题”清单。

设定好这个 Skill 之后，以后任何新客户访谈，我只需要把原文丢给它，剩下的事它全自动完成。最开始的设定可能不太准，我会在跑了几次之后不断修正提示词，慢慢就稳定了。

Skill 的威力就在于你的商业方法不再是“只可意会”的经验，而是变成一套可以被 AI 反复执行的流程。将来你招到新人，也可以直接把技能包共享给他，培训成本瞬间降下来。

4.4 API 接入和接口自动化：让 Workbuddy 不只是写笔记

再进一步，Workbuddy 可以通过连接器访问外部接口。我身边有不少人问“怎么用来做接口自动化”，其实思路并不复杂。

比如，你的客户在你们小程序的反馈表单里留了一条投诉，系统会自动把它推送到 Workbuddy 的连接器（通过 Webhook）。Workbuddy 收到后会做这几件事：

1. 解析用户留言，提取客户ID和问题类型；
2. 调用你 CRM 的查询接口，拉出该客户的订单和历史工单；
3. 把这些信息整理成一条结构化摘要，写入 Obsidian 对应客户笔记；
4. 最后生成一条待办：需要人工跟进或自动回复。

这里的核心是 Workbuddy 充当“编排器”：它负责决定先调哪个接口、怎么解析返回、把结果放哪里。Obsidian 则作为最终的业务脑图，保留所有沉淀内容。

做接口自动化有一个忠告：不要第一天就指望全自动。先让整个流程有一个人工确认节点，比如 AI 生成内容后先发给你审核，你确认没问题后再让它写入 Obsidian。跑稳一两周，确认不会写乱库，再逐步放开权限。

5. 从单点到流程：把它们拼成真正的商业闭环

基础知识都通了之后，这一章我带你串一个完整业务流，你就能看到 Workbuddy 和 Obsidian 是怎么协同的。

5.1 一个新客户从线索到成交的完整路径

假设你刚接触一个新客户，整个流程可以这样走：

1. 第一天：你把和客户沟通的录音转文字，丢到00 Inbox/，Workbuddy 自动执行“客户建档”技能，生成客户初始档案，里面包括公司背景、关键联系人、初步需求和几个待验证问题。
2. 第一次拜访/线上会：你打开 Obsidian 客户目录，用会议纪要模板记录关键信息。会后 Workbuddy 读这份纪要，生成“下一步行动清单”和“风险点”，更新客户档案里的followupdate属性。
3. 中间推进：Dataview 仪表盘显示下周一需要跟进客户A，你让 Workbuddy 从客户档案里提取最近一次沟通要点，起草一份跟进邮件初稿。
4. 项目启动后：客户转成项目，你在20 Projects/下面新建项目目录，并把客户档案中的背景信息链接过去。

你会发现，每个动作之间，两个工具都在接力。Obsidian 负责让信息在场，Workbuddy 负责让信息流到下一个环节。

5.2 周报不用再手动粘贴

几乎所有知识工作者都逃不开周报。过去我总是周五下午翻聊天记录、翻邮件、翻笔记，拼拼凑凑花一个小时。现在我把这件事压缩到了十分钟。

方法是这样的：在 Obsidian 的每个项目笔记里，平时我随手记“本周进展”“遇到的问题”“下一步计划”。周五的时候，我让 Workbuddy 执行一条指令：

读取20 Projects/下所有内容中本周新增或修改的笔记，汇总每个项目的进展。请按以下结构生成周报：本周完成、下周计划、风险与卡点、需要的支持。结果写到30 Knowledge/周报/2025-W25.md。

Workbuddy 可以用文件修改时间或者 Dataview 查询结果来筛选本周的笔记，然后按结构生成初稿。我拿到初稿后，只需要人工检查一下描述是否准确，再花五分钟润色即可。周报这件事从“回忆”变成了“审核”。

5.3 用 Excalidraw 画图和来回“对齐”

如果团队讨论复杂度比较高，光靠文字是不够的。Obsidian 里有一个 Excalidraw 插件，我经常把它拿来画业务流程、客户旅程和系统架构草图。

在 Excalidraw 里有两件事要注意：一是元件对齐，画布上选中多个元件后，可以使用右侧对齐工具一键对齐；连接元件时要从元件边缘的锚点拖出箭头，不要从空白处开始画线，否则后续挪动元件位置线就会乱掉。

画好的图可以直接嵌入 Markdown 笔记。Workbuddy 在读取笔记时，虽不能直接“看懂”图片内容，但如果你在下方配一小段文字描述这张图的逻辑，它就能基于文字去做分析和建议。所以我的习惯是：图负责让人看懂，文字负责让 AI 看懂，两边都别缺。

5.4 用主题和 CSS 提高使用体验，但别上瘾

Obsidian 默认界面比较朴素，很多人第一步就想去折腾主题。我不反对美化，但一定要控制时间。

真正值得做的是：把常用字体调好、暗色模式按自己眼睛舒服设置、写少量 CSS 片段让 Dataview 表格更好读。Obsidian 官方主题库里有很多成熟主题，你挑一个顺眼的装上就行，不要在 CSS 上死磕几天。

在 Obsidian 的设置里，外观 → CSS 代码片段，可以放一些微调样式。比如让 Dataview 表格的行距更宽松，或者让标签在页面上不那么显眼。这些小改动是“用后才知道需求”的，没必要提前设计。

6. 常见问题与排查实录：那些我踩过的坑

不管方案设计得多好，实操时一定会遇到问题。我把自己的踩坑经历整理成一份速查表，你遇到类似情况时可以直接对号入座。

6.1 Obsidian 下载慢、插件商店打不开

Obsidian 插件市场因为资源在境外，国内网络经常连不上或者非常慢。这不是 Obsidian 本身的问题，但确实很影响体验。

解决方案可以分两层：

• 外层：找一个稳定的网络环境再更新，或者耐心多试几次。如果你公司有内部软件源，也可以看看运维有没有同步常用插件。
• 插件本身：可以在 GitHub 上找到对应插件仓库的 release 页面，手动下载压缩包，解压后放到 Obsidian 库的.obsidian/plugins/插件名/目录下，重启 Obsidian 再在“已安装插件”里启用。

手动安装插件时要注意：解压后的目录里必须包含manifest.json和main.js，缺少任何一个都没法启用。因为 Obsidian 是通过这两个文件来识别插件的。

6.2 Workbuddy 本地部署起不来

如果你选择了本地部署模式，最常见的坑有这几个：

• 端口被占用：启动时日志里如果报port already in use，把默认端口换掉再启动。
• 大模型 API Key 过期或没配：Workbuddy 本地版本身不产生智力，它需要接一个大模型后端。很多人以为装完就能用，结果忘了配置模型接口的 API Key。
• Docker 内存不足：Workbuddy 跑本地模型或依赖服务时非常吃内存。如果容器启动后意外退出，先看docker logs，很多时候是内存溢出了。

你如果要本地部署，一定要有耐心看日志。日志是大多数问题最好用的定位方式。

6.3 Workbuddy 读不到 Obsidian 的文件内容

这个问题的原因通常有三个：

1. 路径不对：你在指令里写的路径是“相对路径”，但 Workbuddy 并不知道你 Obsidian 库的根目录是哪，所以要在连接配置里明确设置 Obsidian 库根路径。
2. API Key 过期或被改：Local REST API 插件更新后 Key 可能变，去插件设置里复制新的 Key 替换配置。
3. 权限不足：某些 Workbuddy 本地部署跑在 Docker 容器里，容器默认读不到宿主机上 Obsidian 文件。需要把 Obsidian 库目录挂载到容器内。

检查顺序建议是：先看 Workbuddy 能否直接访问该文件路径，再看 API 接口返回了什么状态码，最后再去查插件日志。

6.4 Dataview 查询结果为空

Dataview 明明写了查询语句，结果却一片空白，这个问题我刚开始也遇到过。多数情况下是下面几个原因：

• 属性没顶格写：YAML Frontmatter 必须从文件第一行开始，前面不能有空行或注释。
• 字段名大小写不匹配：Dataview 对字段名是敏感的，比如你属性里写的是followupdate，查询里就得用followupdate，不要写成followUpDate。
• 路径写错：FROM "10 Clients"里的路径必须是库内的真实目录，注意区分全角/半角引号。
• 插件没启用：Dataview 要保证在“已安装插件”里是启用状态，配置了但没启用，页面只会显示原样文本。

一个快速排查方法：在笔记页面里打开开发者控制台，看有没有红色报错。Dataview 的错误提示一般会直接告诉你哪里写错了。

6.5 数据安全与同步冲突

Obsidian 库是本地文件，这一点的好处是隐私可控，但它也意味着你必须有备份意识。

我的建议是：Obsidian 库至少放在一个有同步能力的目录里。如果你用的是 iCloud、坚果云这种同步盘，注意不要在多个设备上同时编辑同一条笔记，容易产生冲突副本。Workbuddy 在写入文件时，如果正好和 Obsidian 正在进行的编辑撞上，也可能产生冲突文件。

对于特别重要的客户资料，我会额外用 Git 仓库做版本管理。每个周五提交一次，万一哪次操作把库改乱了，还能回滚到上一个稳定版本。

至于商业敏感数据的脱敏，如果知识库里会写入客户财务、身份证号等信息，建议把这些字段单独放，不要和常规业务笔记混在同一个目录里。做得更细一点，可以给敏感目录加密，Workbuddy 涉及这些内容时也尽量只给暂时的只读权限，不给全库的写权限。

6.6 库越用越乱怎么办

最后这点其实不是技术问题，而是持续维护问题。我的习惯是每周五花固定的半小时做“大脑整理”：清理 Inbox、合并重复笔记、更新客户和项目的跟进日期、顺手删掉三个月没打开过一次、也没有价值的旧笔记。

很多人舍不得删东西，但第二商业大脑保留的是“能被调用的结构”，不是“堆在仓库里的废纸”。如果一条笔记没有被任何链接指向、没有打上任何状态标签、半年内也没有被 Workbuddy 读到过，那你留着它大概率也不会再用。归档到90 Archive/总比让它干扰商业主流程要好。

7. 最后给你几条实操建议

这套系统我从零搭到现在，已经跑了好几个月。如果你现在要动手建自己那套，有几条硬建议希望你知道。

第一，先跑通最小的链路再美化。不要花一周时间研究主题、CSS、脚本库。第一版只要能做到“Obsidian 能存、Workbuddy 能读、Dataview 能汇总”就够了，这条链路跑通之后，你才知道下一步哪里最需要优化。

第二，所有工作流设计的终点都是“行动”。一条笔记、一份报告、一段分析，如果最终没有变成某个人要做的下一步动作，它就只是库存。所以在给 Workbuddy 写指令时，永远要求它产出行动项，哪怕只是“暂无行动，下月复查”。这个习惯能让你的知识库保持活性。

第三，敢于让 AI 写乱一点，也要敢于清理。Workbuddy 自动写入的内容不一定完美，可能有时候路径不对、属性格式不标准。你别因为这个就退回手工模式，而是把它当作训练实习生，写错就纠正，纠正几次后它会在你的技能包里越来越准。

我个人最享受的变化是：以前所有客户和项目信息都散落在微信聊天、邮件、Excel 和我的大脑里，每切换一次场景就要重新回忆一遍。现在打开 Obsidian，我看一眼 Dataview 仪表盘就知道这周该跟谁、哪个项目有风险；打开 Workbuddy，我只需要说一句话，它就能把相关上下文调出来，然后替我起草初稿、整理行动。这种感觉就像多了一个永远记得住上下文、又愿意主动干活的商业搭档。

你在搭的时候如果卡在某一步，尤其是 Workbuddy 读写 Obsidian 不通的问题，建议优先检查两者之间的连接配置，而不是先怀疑方案本身。把最小闭环跑起来，后面的事都会顺很多。