用Obsidian搭建运营销售工作台：客户管理与自动化查询实战
做运营和销售的人，大多有一个共同的痛：客户的联系方式散落在微信聊天记录里，报价单躺在邮箱附件里，跟进状态记在 Excel 里还不一定更新，复盘的时候只能凭记忆拼凑。我搭建了一个基于 Obsidian 的工作台，把客户档案、跟进记录、日常话术和知识库全部收到一个本地 Markdown 仓库里，运营和销售同事用了以后，最大的变化不是“换了个工具”，而是不用再到处翻信息了。
Obsidian 不是又一个网盘笔记。它看起来像一个本地笔记软件，实际上是一个以 Markdown 文件为底层格式的个人数据库。通过属性、模板和查询，你能把零散记录变成一张自动更新的工作台。这篇文章会从 0 搭建一套适合运营销售团队的 Obsidian 工作台，包含目录结构、模板设计、自动化查询、多端同步与备份，以及实际使用过程中最容易踩的坑。读完后，你可以直接照着这套思路复制出自己的版本。
很多人搜“工作台”是想找企业微信里的应用工作台，那是另一回事。本文讨论的是把 Obsidian 当作知识工作台，把客户、任务、知识统一管理起来。它不一定适合所有团队，但如果你每天要和大量信息打交道，并且不想被工具绑定，这个思路值得花一个下午试一次。
1. 这篇文章真正要解决的问题
先聊一个朴素的场景。
今天你加了三个潜在客户微信，把聊天记录留在手机里；下午给一个老客户发了报价单，文件存在电脑下载目录；晚上要写日报，发现已经想不起上午到底给哪个客户打过电话。如果团队有两三个人，每个人手里还有自己版本的客户表，那这个混乱会被放大好几倍。
这不是某一款软件能单独解决的，核心问题是：业务信息没有放在一个统一、可检索、可结构化的地方。Excel 能存，但维护成本高、协作容易乱；CRM 系统能管，但配置门槛高，小团队不一定用得起；网盘笔记能记，但大多把内容封在私有格式里，换工具就迁移困难。
Obsidian 适合这个场景，原因有三个：
- 本地优先。数据以纯文本 Markdown 文件存在你的电脑里，没有平台绑定。
- 结构化能力强。通过 frontmatter 属性，可以让每条客户记录拥有统一的字段，比如跟进状态、下次跟进时间、客户来源。
- 查询自动化。配合社区插件，能按字段自动汇总，形成“今天要跟进谁”“哪个阶段的客户最多”这类视图。
这篇文章要说明白两件事：第一，怎么设计一个能长期使用的工作台；第二，怎么避免把工作台搭完却没人用的坑。整篇文章围绕运营和销售的真实使用场景展开，你可以只搭给自己一个人用，也可以复制给团队。
2. Obsidian 工作台的核心概念与设计原理
2.1 Vault 概念
Obsidian 里最基础的单位叫 Vault（仓库）。一个 Vault 对应一个本地文件夹，里面所有 Markdown 文件和附件都属于这个知识库。创建 Obsidian 工作台，本质上就是设计好这个文件夹里的内容结构。
对运营销售来说，Vault 可以简单理解为“你所有的业务信息都在这里”。客户资料、跟进记录、日报周报、产品知识、竞品信息，都能以 Markdown 文件的形式存放。因为没有数据库锁定的问题，你可以随时用任意编辑器打开这些文件。
2.2 Markdown 与属性
Markdown 是纯文本标记语言，标题用#，列表用-，加粗用**，不需要花哨的排版能力。Obsidian 支持 Markdown 标准语法，同时支持 frontmatter 属性，也就是在文件开头用 YAML 格式定义结构化字段。
--- 客户名称: 某公司 所属行业: 电商 联系人: 王经理 跟进状态: 已报价 下次跟进: 2025-06-10 ---这些属性会被 Obsidian 索引，也能被 Dataview 这类插件查询。这是工作台能“自动汇总”的关键基础。以前你在 Excel 里维护状态，现在状态就写在每张客户卡片的顶部。
2.3 双链与知识网络
Obsidian 支持双向链接，可以用[[ ]]把两条记录关联起来。运营销售场景不一定需要复杂的双链，但有一个场景很实用：在客户档案里用[[跟进记录/2025-06-05-王经理电话]]指向对应的跟进记录，这样看客户档案时，能顺着链接看到完整沟通过程。
真正理解 Obsidian 做工作台的优势，可以看下面这个对比。
| 对比维度 | Obsidian 工作台 | Excel 管理 | 传统 CRM 系统 |
|---|---|---|---|
| 数据格式 | 纯文本 Markdown | 私有格式 | 私有数据库 |
| 结构化能力 | 属性 + 查询 | 强，但依赖手动维护 | 强，但配置复杂 |
| 离线可用 | 是 | 是 | 不一定 |
| 批量导入 | 通过 CSV 或脚本 | 原生支持 | 不一定支持 |
| 二次开发 | 插件生态丰富 | 受限 | 受限 |
| 团队协作 | 需额外配置同步 | 一般 | 原生支持 |
结论很明确：Obsidian 工作台最适合“信息分散、团队规模不大、希望低成本沉淀业务知识”的场景。它不是要替换成熟 CRM，而是帮你把散落的信息先集中起来，跑通业务流程后再决定要不要上更重的系统。
2.4 工作台的本质
Obsidian 工作台不是把笔记做得更漂亮，而是用“文件夹 + 属性 + 模板 + 查询”四件套，把业务信息变成可检索、可筛选、可复盘的系统。一旦理解这个本质，你就不会纠结于用什么主题、装什么花哨插件，而是把精力放在数据结构和记录习惯上。
3. 环境准备与前置条件
3.1 下载与安装
Obsidian 支持 Windows、macOS、Linux、iOS 和 Android。官方提供安装包，建议从官网下载，避免从第三方站点获取来历不明的安装包。
这里有一个常见痛点：Obsidian 安装包下载速度慢。如果你的网络出口不稳定，可以尝试以下方式：
- 换个网络环境，比如从移动网络切换到家宽；
- 错峰下载，避开晚高峰；
- 确认下载链接来自官网，不要在不明镜像站下载；
- 如果长期下载缓慢，先检查整体网络，再考虑其他渠道。
如果你的电脑还是 Windows 7 的 64 位系统，需要特别注意：新版本 Obsidian 对操作系统版本有要求。建议先到官网确认当前版本支持哪些系统，如果官方已经放弃 Win7，更稳妥的方案是升级系统，或者在其他设备上使用，不要下载来历不明的“兼容版”。
3.2 创建 Vault
安装完成后，第一次启动会要求创建 Vault。选择“创建新仓库”，输入名称，比如运营销售工作台，选一个本地目录。这个目录下的所有 Markdown 文件都会成为知识库的一部分。
创建完成后，Obsidian 会在该目录下生成.obsidian文件夹，用来存放配置。这个文件夹里的主题、插件配置都是本地的，你可以随时用 Git 或同步工具备份。
3.3 基础设置
进入“设置 - 外观”，可以调整主题和字体。中文字体我一般设置为Microsoft YaHei或PingFang SC。如果你更喜欢自定义字体，可以写 CSS 片段，后面会给出示例。
进入“设置 - 编辑器”，打开“代码折叠”，这样长文档里的大段代码和标题可以折叠，浏览页面更清爽。Obsidian 新版本默认使用“实时预览”编辑模式，也就是所见即所得。以前很多人问“能不能编辑模式同时看到源码和渲染结果”，其实有两个思路：
- 使用实时预览模式，编辑时直接渲染效果；
- 打开两个窗格，一个窗格用源码模式，另一个窗格用阅读模式，左右对照。
3.4 插件安装安全提醒
Obsidian 的插件生态非常丰富，但第三方插件来自社区，数量多、质量参差不齐。安装插件前先查看下载量、更新时间、作者维护情况，不要安装来源不明的插件。涉及客户信息的 Vault 尤其要谨慎，有些插件会把笔记内容发送到第三方 AI 服务，如果里面有客户联系方式，这就是一个明显的隐私风险。
4. 工作台目录结构与核心数据模型
4.1 目录结构设计
目录就是工作台的地基。运营销售工作台建议按照“收纳 + 流程 + 知识”的思路划分。下面是通用结构，你完全可以按自己的业务调整。
MyWorkbench/ ├── 00 Inbox/ # 临时收集，不分类 ├── 01 客户管理/ │ ├── A-潜在客户/ │ ├── B-已报价/ │ └── C-已成交/ ├── 02 跟进记录/ # 每次沟通一条记录 ├── 03 运营内容/ │ ├── 公众号文章/ │ ├── 朋友圈文案/ │ └── 活动方案/ ├── 04 产品知识/ ├── 05 日报周报/ ├── 06 复盘资料/ ├── 90 模板/ └── 95 附件/ └── images/为什么用数字前缀？因为 Obsidian 默认按字母排序，00在最前面，99在最后。这样核心高频目录排前面，模板和附件靠后，文件面板不会乱。
4.2 核心数据模型
运营销售场景的数据模型其实很简单，就是一张业务表加若干关联记录。用表格描述如下。
| 数据对象 | 文件位置 | 关键属性 | 说明 |
|---|---|---|---|
| 客户档案 | 01 客户管理/ | 客户名称、行业、跟进状态、下次跟进 | 一个客户一个文件 |
| 跟进记录 | 02 跟进记录/ | 客户名称、跟进日期、下一步动作 | 一次沟通一条记录 |
| 日报周报 | 05 日报周报/ | 日期、本周重点、风险 | 按周期记录 |
| 运营素材 | 03 运营内容/ | 类型、发布平台、状态 | 文章物料复用 |
客户档案是工作台的核心。每条客户记录必须拥有统一的属性字段，这样 Dataview 才能按字段查询。属性值尽量用枚举，不要自由发挥。比如“跟进状态”固定用：待跟进、已联系、已报价、试用中、已成交、已流失。否则状态字段就会变成“要跟”“联系了”“报过价”多种写法，查询结果就没法看了。
4.3 文件命名规范
客户档案建议按“客户名称”命名，例如某电商公司.md。跟进记录建议按“日期-客户-事项”命名，例如2025-06-10-某电商公司-电话沟通.md。这样在文件列表里按时间排序时，自然形成时间线。
命名规范看起来不起眼，却是工作台长期可用性的关键。没有规范，半年后文件会膨胀到无法管理。
5. 模板系统与日常记录流
5.1 模板插件的选择
Obsidian 核心插件里有一个“模板”功能，可以插入固定模板文本。功能更强大的是社区插件 Templater，支持变量、日期、复杂逻辑。如果你只需要简单模板，原生的“模板”插件足够；如果想做更自动化的工作流，用 Templater。
本文以 Templater 为例，因为它的变量语法更适合运营销售场景。具体版本语法可能有差异，以你安装的插件说明为准。
5.2 客户档案模板
在90 模板目录下新建客户档案.md。
--- 客户名称: 所属行业: 联系人: 联系电话: 微信: 客户来源: 跟进状态: 待跟进 下次跟进: 创建时间: {{date:YYYY-MM-DD}} 标签: ["客户"] --- ## 背景信息 ## 业务需求 ## 沟通记录 - {{date:YYYY-MM-DD}}：创建客户档案，待首次联系。这个模板的关键在于 frontmatter 属性。以后每来一个客户，复制模板并填写真实信息，这条客户记录就成了数据模型里的一个节点。Dataview 能读到这些属性，于是所有客户列表、统计视图都能自动生成。
5.3 跟进记录模板
在90 模板目录下新建跟进记录.md。
--- 客户名称: 跟进日期: {{date:YYYY-MM-DD}} 跟进方式: 微信/电话/面谈 本次结果: 下一步动作: 下次跟进时间: --- ## 本次沟通内容 ## 客户反馈 ## 风险与注意事项跟进记录不要写太长，关键是“本次结果”和“下一步动作”。一个成熟的销售习惯是：挂完电话立即花两分钟把这四条写完。如果拖到晚上，99% 的记录都会丢失。
5.4 日报模板
在90 模板目录下新建日报.md。
--- 日期: {{date:YYYY-MM-DD}} 状态: 进行中 --- ## 今日成果 ## 遇到的问题 ## 明日计划说句实在话，日报如果没有和业务数据挂钩，很容易变成形式主义。日报里最重要的不是“我今天做了什么”，而是“今天推进了哪些客户、出现了什么问题”。模板里留这三个部分就够，不需要复杂格式。
5.5 日常记录流完整闭环
搭好模板后，日常操作形成固定闭环：
- 在手机或电脑上收到客户咨询，先丢进
00 Inbox，或者直接新建客户档案； - 首次沟通后，在客户档案里补全信息，记录“沟通记录”；
- 每次电话或微信沟通，用跟进记录模板新建一条记录，并把链接放进客户档案；
- 下班前打开 Dataview 视图，看一眼明天要跟进的客户；全写完了，再写日报。
整个过程不超过十分钟。但坚持一个月后，你手上会积累一份比任何表格都完整的客户时间线。
6. 自动化查询与效果验证
6.1 Dataview 插件的作用
Dataview 是 Obsidian 最核心的社区插件之一。它能读取 Markdown 文件的 frontmatter 属性，并用类似查询的语言生成动态列表、表格和任务清单。没有 Dataview，工作台只是“一堆 Markdown 文件”；有了 Dataview，工作台才真正变成“数据库”。
安装后在任意笔记里添加代码块：
TABLE 所属行业, 跟进状态, 联系人, 下次跟进 FROM "01 客户管理" WHERE 下次跟进 != null AND 跟进状态 != "已成交" SORT 下次跟进 ASC上述查询的逻辑是：从01 客户管理文件夹中，找出“还没有成交”且“设置了下次跟进时间”的客户，按下次跟进日期从近到远排序。运行后你会得到一张动态表格，每天打开工作台，第一个看到的就是今天该联系谁。
6.2 按销售阶段统计客户
如果你关心的是漏斗，可以统计每个阶段有多少客户。
TABLE length(rows) AS 客户数量 FROM "01 客户管理" WHERE 客户名称 != null GROUP BY 跟进状态 SORT 客户数量 DESC这个查询按“跟进状态”分组，汇总每个状态下有多少客户。运营和销售开周会时，这个视图可以直接投屏。
6.3 本周到期跟进查询
较新的 Obsidian 版本支持日期比较。可以用一段类似 SQL 的条件，筛选出“下次跟进在本周内”的客户。
TABLE 客户名称, 联系人, 下次跟进 FROM "01 客户管理" WHERE 下次跟进 != null AND date(下次跟进) >= date(today) AND date(下次跟进) <= date(today) + dur(7 days) SORT 下次跟进 ASC如果你安装的 Obsidian 版本不支持dur()函数，可以退一步用手动筛选：先按“下次跟进”升序排列，然后人工看本周日期。Dataview 语法版本不同会有差异，使用前先看一眼插件文档。
6.4 看板视图
除了表格，还可以用社区看板插件实现类似 Trello 的卡片视图。原理依然基于“跟进状态”字段：不同状态的客户显示在不同列里，拖动卡片改变状态，实际上是在修改文件属性。
看板适合销售阶段较多的团队，但不要一上来就用它替代表格。我的建议是先用 Dataview 表格跑一个月，确认客户阶段字段稳定后再上卡片视图。
6.5 效果验证：如何判断工作台搭建成功
判断标准很简单：打开工作台，10 秒内回答下面三个问题。
- 今天要跟进哪些客户？
- 每个客户在什么阶段？
- 最近一周的沟通记录有没有断档？
如果三个问题都能回答，工作台的第一步就成功了。如果查询结果空白，先检查属性值是否一致，比如“跟进状态”有的写“待跟进”有的写“待联系”，查询条件对不上，结果自然为空。
实际效果参考：团队使用两周后，最常见的反馈是“不用再去微信里翻聊天记录了”。这一步已经比 Excel 管理信息前进了一大截。
7. 多端同步与远程备份
7.1 为什么要做备份
Obsidian 的数据存在本地，这是优点也是风险。如果电脑硬盘损坏、误删文件，而没有备份，整个知识库就没了。运营销售工作台里的客户信息一旦丢失，后果比丢失一篇笔记严重得多。
所以备份不是可选功能，而是搭建工作台的必要环节。
7.2 同步方案对比
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Obsidian 官方同步 | 电脑 + 手机多端 | 端到端加密、配置简单 | 付费订阅 |
| NAS + SMB/WebDAV | 有自建存储 | 容量可控、数据在自己手里 | 需要一定网络知识 |
| Syncthing | 多设备点对点 | 免费、开源 | 配置门槛稍高 |
| Git 仓库 | 技术型用户 | 版本可追溯 | 不擅长命令行的团队难上手 |
| U 盘手动备份 | 单人临时用 | 零成本 | 容易忘记 |
最稳妥的组合是：日常多端同步用官方同步或 Syncthing，定时备份到 NAS 或移动硬盘。不要把两种同步方案同时跑在一个文件夹里，容易出现文件冲突。
7.3 NAS 远程备份通用思路
如果你家里或办公室有 NAS，最简单的方式是把 Vault 定时备份到 NAS 共享目录。下面是一个备份脚本示例，适合 Linux 或 macOS 环境，Windows 可以用计划任务配合压缩命令实现类似效果。
#!/usr/bin/env bash # 文件路径：scripts/backup_obsidian.sh set -euo pipefail VAULT_DIR="$HOME/Documents/MyWorkbench" BACKUP_BASE="/Volumes/nas-backup/obsidian" TIMESTAMP=$(date +%Y%m%d-%H%M%S) BACKUP_DIR="$BACKUP_BASE/$TIMESTAMP" mkdir -p "$BACKUP_DIR" tar --exclude="$VAULT_DIR/.obsidian/workspace*" \ --exclude="$VAULT_DIR/.trash" \ -czf "$BACKUP_DIR/myworkbench.tar.gz" -C "$VAULT_DIR" . echo "备份完成：$BACKUP_DIR/myworkbench.tar.gz"脚本做的事很直接：创建一个带时间戳的备份目录，用 tar 压缩整个 Vault，排除工作区状态和回收站。你可以用 crontab 设置每天凌晨执行。
7.4 同步冲突注意事项
多端同时编辑同一篇笔记，会产生冲突文件。Obsidian 官方同步会对冲突进行标记，Syncthing 也会生成冲突副本。尽量减少“同一文件在两个设备上同时编辑”的情况，手机端快速记录，电脑端整理复盘，这是最不容易冲突的节奏。
8. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Obsidian 安装包下载很慢 | 网络出口不稳定或高峰时段 | 检查整体网络，换时段再试 | 从官网获取安装包，换一个网络环境重试 |
| Windows 7 打不开新版本 | 新版本不支持旧操作系统 | 查看官网系统和版本要求 | 升级操作系统，或在其他设备使用 |
| Dataview 查询无结果 | 属性名不一致或文件路径错误 | 检查 frontmatter 字段，确认文件夹路径 | 统一属性枚举值，用英文路径避免特殊符号 |
| 图片附件找不到 | 附件被存放在 Vault 外，或路径被移动 | 检查附件默认路径设置 | 设置附件默认位置到 Vault 内的95 附件/images |
| 编辑时看不到渲染效果 | 明明想同时看源码和渲染 | 检查编辑器模式设置 | 用实时预览模式，或开双窗格窗口对照 |
| 代码折叠失效 | 主题或插件覆盖了编辑器样式 | 查看主题设置，关闭冲突插件 | 在设置-编辑器里重新开启代码折叠 |
| 同步后文件冲突 | 多设备同时编辑同一文件 | 查看冲突副本文件 | 避免同时编辑，整理冲突文件后删掉多余副本 |
| 打开 Vault 越来越卡 | Markdown 文件太多且启用了大量插件 | 检查插件数量，看是否存在超大文件 | 按需关闭插件，用模板控制单文件体积 |
这里真正容易踩坑的是第三条。字段名大小写、中英文空格不一致，都会让 Dataview 查不到数据。我见过团队用了一个月工作台，最后发现查询结果为空，原因就是有人手动改了某条记录的属性名。解决办法只有一个：属性字段全部用模板生成，不手工敲。
9. 最佳实践与团队落地建议
把 Obsidian 工作台架子搭起来不难，难的是长期维护。下面是几条我从实际使用里总结的建议。
9.1 先统一属性，再谈自动化
自动化查询依赖属性，属性不统一，自动化就是空谈。团队使用前，先把字段定义写进模板和团队约定文档。新成员加入，先教他“不要在模板外新建字段”，从源头上减少数据混乱。
9.2 插件按需安装，不要一开始堆功能
新手最容易被“插件推荐”类文章吸引，装了几十个插件，结果打开 Vault 卡顿，功能反而不会用。起步阶段只装 Templater 和 Dataview，跑通流程后再按需增加。一个稳定的工作台远胜一个功能花哨但没人维护的工作台。
9.3 敏感信息与安全边界
客户档案里有姓名、手机号、微信等个人信息。如果使用第三方 AI 插件总结客户记录，务必确认数据不会被上传到外部模型。本地 Vault 本身没有加密能力，如果公司对信息安全有要求，需要考虑系统盘加密或文件加密方案。定期备份时，备份文件也要有相应保护。
9.4 团队落地节奏
小团队落地不要追求一步到位。更稳的节奏是：先在某一个人那里把工作台跑两周，验证目录设计、模板和查询是否满足真实业务；然后拉一个小群试点，收集反馈；最后再统一推广。如果你一上来就要求销售把所有历史客户录进去，大概率会遭到抵制。更现实的做法是：从今天的新客户开始记录，历史客户按重要程度逐步补录。
9.5 后期值得扩展的方向
工作台稳定运行后，可以进一步扩展：
- 内容型团队可以用 Zotero 管理参考文献，再导入 Obsidian 做主题卡片；
- 会议纪要可以结合录音转文字工具，导出文本后再整理进知识库；
- 想长期做数据积累的，可以尝试把 Vault 接入 Git，把版本历史留下来；
- 对一些重复性操作，比如批量建立客户档案，可以写脚本或使用 QuickAdd 类插件提升效率；
- 如果你关注 AI 知识库方向，可以把 Obsidian 作为数据底座，配合向量化工具对内部知识做问答。
这些都是后话。眼前最重要的事情不是继续研究工具，而是先跑通一个最小记录流程。
搭建 Obsidian 工作台这件事，真正改变的不是笔记形式，而是工作习惯。它的价值在于：当你打开一个本地文件夹，能够快速回答“这个客户现在在哪一步、下次什么时候跟、此前沟通过什么”，并由此沉淀出团队自己的客户知识。明天你可以先做一件事：新建一个 Vault，创建客户管理、跟进记录、日报三个文件夹，把最近一周的客户信息录进去，跑通一次“建档-跟进-查询”的流程，再决定要不要继续加插件。