纯文本CRM：用YAML+Markdown构建极简客户关系管理系统

1. 项目概述：当CRM回归“纯文本”的本质

最近在开源社区里，一个名为anthroos/plaintext-crm的项目引起了我的注意。乍一看这个标题，可能会觉得有些“复古”甚至“简陋”——在如今这个SaaS化、云端化、AI智能化的时代，一个基于纯文本的客户关系管理工具，听起来就像是回到了用记事本和Excel管理客户的年代。但恰恰是这种回归本质的思路，让我这个在销售和客户管理领域摸爬滚打了十几年的人，产生了强烈的共鸣。

这个项目的核心，就是摒弃了传统CRM（客户关系管理）软件中那些繁复的界面、臃肿的功能和强制性的流程，将客户信息、沟通记录、交易状态等一切核心数据，都存储在一个结构化的纯文本文件中。你可以用任何你喜欢的文本编辑器（比如VSCode、Sublime Text，甚至是系统自带的记事本）来打开、编辑和管理它。它的数据格式通常是Markdown、YAML、JSON或者是一种自定义的、人类可读的文本结构。anthroos/plaintext-crm不是一个需要安装的软件，它更像是一套方法论、一个数据规范，以及一系列围绕这个纯文本文件工作的自动化脚本工具集。

那么，它解决了什么问题？首先，是数据主权。你的所有客户数据完全掌握在自己手中，就是一个（或几个）文本文件，你可以用Git进行版本控制，放在任何你信任的云存储或本地硬盘，无需担心服务商倒闭、订阅涨价或数据被锁定。其次，是极致的灵活性与可定制性。没有固定的字段限制，你可以根据你的业务需要，随时添加“行业痛点”、“决策链图谱”或“咖啡口味偏好”这样的自定义字段。最后，是无与伦比的流畅度。对于追求效率的极客、独立开发者、自由职业者或小团队来说，在终端里用命令行工具快速查询、更新客户状态，或者用脚本批量处理客户标签，这种效率是点击图形界面无法比拟的。

它适合谁？我认为它非常适合以下几类人：1）独立顾问与自由职业者，客户数量在几十到上百个，需要轻量但深度的管理；2）早期创业团队或小公司，业务模式还在快速迭代，需要一个能跟得上变化的客户管理方案，而不是被软件功能限制；3）技术背景的销售或客户成功人员，享受用代码和自动化工具提升工作效率的乐趣；4）任何对现有CRM感到“笨重”和“束缚”的人，想要一个完全受自己控制的管理系统。

接下来，我将深入拆解plaintext-crm的设计哲学、实现细节，并分享如何从零开始搭建一套适合自己的纯文本CRM工作流。你会发现，这远不止是一个“文本文件”，而是一套重塑你客户管理思维的效率系统。

2. 核心设计哲学：为什么是纯文本？

在深入技术细节之前，我们必须先理解plaintext-crm乃至整个“纯文本运动”（Plain Text Movement）背后的核心哲学。这不仅仅是技术选型，更是一种关于数据、工具和个人工作流的理念。

2.1 数据持久化与未来可读性

现代软件最大的陷阱之一就是“数据锁定”。你的客户数据被存放在一个专有的二进制数据库里，只有特定的软件才能正确读取。五年、十年后，这家公司还在吗？这个软件版本还支持旧数据吗？纯文本（尤其是Markdown、YAML、JSON这类结构化或半结构化文本）是人类和机器都可读的。即便plaintext-crm这个项目本身不再维护，你的数据文件依然清晰可见。一个简单的cat customer.md命令，就能让你看到客户的所有信息。这种数据的永恒性和可移植性，是任何封闭系统都无法给予的安全感。

2.2 工具的无边界性与工作流集成

当你使用Salesforce或HubSpot时，你被限制在它们的生态内。想要一个自定义报表？可能需要复杂的配置或额外的费用。想要把客户数据和你内部的工单系统关联？需要昂贵的API集成。而纯文本文件是“无主之地”。你可以用grep,awk,sed在终端里进行闪电般的搜索和过滤。你可以用Python写一个脚本，定时从邮箱爬取邮件，自动更新到客户的联系记录里。你可以用pandoc将客户档案转换成PDF发给同事。你的文本编辑器（如VSCode）的所有插件——代码片段、语法高亮、Lint检查——都能为管理客户数据服务。你的CRM工具链变成了整个Unix哲学下的工具集合，创造力不受限制。

2.3 极简主义与注意力管理

传统的CRM往往充斥着提醒、通知、仪表盘和没完没了的必填字段。它们的设计初衷是管理销售团队，而非辅助个人思考。过多的功能反而成了认知负担。plaintext-crm强迫你回归本质：客户是谁？你们之间发生了什么？下一步该做什么？所有信息扁平地呈现在文本中，没有弹窗干扰。你可以用最纯粹的写作方式来记录与客户的每一次深度交流，这本身就是一个梳理思路、加深理解的过程。这种极简，是为了将注意力完全聚焦在客户本身，而非工具的操作上。

2.4 版本控制的天然盟友

Git 不仅是程序员的专利。将你的CRM文本文件放入Git仓库，意味着每一次客户状态的变更都有完整的历史记录。你可以清晰地看到：“这个客户的预算是何时从‘10-20万’修改为‘20-30万’的？”，“那段关键的产品需求描述是哪个同事在什么时候补充的？”。通过git diff，合作变得透明且可追溯。分支功能甚至可以让你模拟不同的销售策略或客户跟进方案，而不会污染主数据。这种基于版本控制的协作模式，对于小团队来说，既轻量又强大。

3. 数据结构与格式选型解析

确定了纯文本的路线，下一个关键决策是：用什么格式来组织数据？anthroos/plaintext-crm项目通常会提供一种参考结构，但理解其优劣才能做出适合自己的选择。

3.1 主流格式对比：Markdown, YAML, JSON, TOML

1. Markdown（.md文件）：

   • 优点：可读性极佳。可以用标题（#）划分结构，列表记录交互，代码块存放结构化数据（如JSON），自由文本区域记录沟通详情。非常适合“文档型”客户档案，即一段描述性文字夹杂结构化数据。
   • 缺点：机器解析稍复杂，需要定制解析器来提取结构化信息。
   • 适用场景：客户档案需要大量自由文本记录（如会议纪要、需求分析），且人类阅读优先级高于自动化处理。

2. YAML（.yml/.yaml文件）：

   • 优点：在人类可读和机器可读之间取得了绝佳平衡。层次结构清晰，支持注释，数据类型丰富。非常适合配置化和数据驱动。
   • 缺点：缩进敏感，格式错误会导致解析失败。对于非常复杂的嵌套结构，可读性会下降。
   • 适用场景：客户属性高度结构化，需要被其他脚本频繁读取和修改。是plaintext-crm类项目最常用的格式之一。

3. JSON（.json文件）：

   • 优点：机器解析的绝对标准，几乎所有编程语言都原生支持。结构明确，无歧义。
   • 缺点：对人类不友好，不允许注释，冗余的括号和引号影响阅读。不适合直接人工编辑。
   • 适用场景：数据完全由脚本自动化生成和维护，或作为不同工具间交换数据的中间格式。

4. TOML（.toml文件）：

   • 优点：语法比YAML更简单直观，旨在成为一个“最小化的配置文件格式”。对于扁平化的配置，可读性很高。
   • 缺点：社区生态和工具支持相对YAML/JSON较弱。复杂结构的表达力不如YAML。
   • 适用场景：偏好极简配置语法，且数据结构相对简单的场景。

实操心得：我个人的组合方案是“YAML + Markdown”。用一个customers.yml文件作为索引和核心数据库，存放所有客户的关键结构化信息（ID、名称、状态、标签、最后联系时间等）。然后，为每个客户创建一个clients/{customer_id}.md的Markdown文件，用于记录详细的沟通日志、会议纪要和文件附件链接。这样既保证了机器处理的效率，又保留了人类书写的灵活性。

3.2 一个典型的客户数据模型设计

假设我们采用YAML作为主格式，一个客户条目可能长这样：

- id: C001 name: "Acme科技有限公司" status: "active" # active, prospect, inactive, lost priority: "A" # A (高), B (中), C (低) tags: - "SaaS" - "华东区" - "技术驱动型" contacts: - name: "张三" title: "技术总监" email: "zhangsan@acme.com" phone: "13800138000" wechat: "zhangsan_tech" notes: "关键决策人，关注技术架构的稳定性" source: "行业展会2023" value_est: 200000 # 预估年价值，单位元 next_action: date: "2024-10-27" desc: "发送POC部署方案" created_at: "2023-11-15" updated_at: "2024-10-20"

字段设计解析：

• id: 内部唯一标识，便于脚本引用和文件关联。
• status和priority: 这是驱动销售流程的核心字段。我通常定义4-5个状态（如：潜在客户、初步接触、需求确认、方案谈判、已成交/已丢失），以及3个优先级。通过脚本可以快速过滤出“高优先级的、处于需求确认阶段的客户”。
• tags: 多维分类的神器。可以按行业、地区、产品兴趣、客户规模等打标签，实现灵活的客户分组。
• contacts: 使用列表存储多个联系人，避免信息扁平化。notes字段记录针对该联系人的个性化信息，这在后续沟通前快速回顾时非常有用。
• next_action:最重要的字段之一。CRM的核心是推动销售向前，这个字段明确了下一步做什么、何时做。我习惯每天早上的第一件事就是运行脚本，列出所有next_action日期是今天或已过期的客户。

3.3 文件组织架构

一个清晰的文件结构是维持系统可持续性的关键。我推荐的目录结构如下：

plaintext_crm/ ├── data/ │ ├── customers.yml # 核心客户数据库 (YAML) │ └── contacts.yml # (可选) 独立联系人库，用于去重和关联 ├── clients/ # 客户专属目录 │ ├── C001_Acme科技/ │ │ ├── index.md # 客户主文档，详细背景、需求 │ │ ├── meeting_20241020.md │ │ ├── proposal_v1.pdf │ │ └── emails/ # 存放重要邮件归档或摘要 │ └── C002_... ├── templates/ # 模板文件 │ ├── new_customer.yml # 新建客户YAML模板 │ └── meeting_note.md # 会议记录Markdown模板 ├── scripts/ # 自动化脚本 │ ├── add_customer.py │ ├── query.py │ └── report_weekly.sh └── README.md # 系统使用说明

这种结构将“数据”（结构化、用于查询）和“文档”（非结构化、用于记录）分离，同时通过id和目录名建立关联，既整洁又实用。

4. 核心工具链与自动化脚本实现

纯文本的强大，一半在于格式，另一半在于围绕它的自动化工具。anthroos/plaintext-crm的精髓正是通过一系列轻量脚本，将静态文本变成动态的、可交互的系统。

4.1 基础查询与过滤：命令行是主界面

对于日常的客户查找和状态浏览，我们完全不需要打开文件。使用yq(处理YAML的命令行工具) 和jq(处理JSON的工具) 可以完成大部分工作。

示例1：查找所有“高优先级”的“活跃”客户

# 假设使用yq yq eval '.[] | select(.status == "active" and .priority == "A") | .name' data/customers.yml # 输出类似： # Acme科技有限公司 # Beta创新工场

示例2：列出所有今天需要跟进的下一个行动

TODAY=$(date +%Y-%m-%d) yq eval --output-format=json data/customers.yml | \ jq -r --arg today "$TODAY" '.[] | select(.next_action.date <= $today) | "\(.name): \(.next_action.desc)"'

你可以将这些命令封装成简单的Shell脚本（如./scripts/today.sh），甚至设置为终端别名（alias crm-today="..."），实现秒级查询。

4.2 使用Python/Go编写管理脚本

对于更复杂的操作，如添加客户、更新状态、生成报表，就需要编写一些小脚本。Python因其强大的库支持（如pyyaml,rich）是绝佳选择。

一个添加新客户的Python脚本示例 (scripts/add_customer.py)：

#!/usr/bin/env python3 import yaml import sys from datetime import datetime from pathlib import Path def load_customers(filepath): with open(filepath, 'r', encoding='utf-8') as f: return yaml.safe_load(f) or [] def save_customers(filepath, data): with open(filepath, 'w', encoding='utf-8') as f: yaml.dump(data, f, allow_unicode=True, sort_keys=False) def generate_id(existing_customers): # 简单ID生成逻辑：C+三位序号 ids = [c['id'] for c in existing_customers if c['id'].startswith('C')] if not ids: return 'C001' max_num = max(int(id[1:]) for id in ids) return f'C{max_num + 1:03d}' def main(): data_file = Path('data/customers.yml') customers = load_customers(data_file) print("添加新客户") name = input("客户公司名称: ").strip() source = input("来源（如：转介绍/线上搜索/展会）: ").strip() new_customer = { 'id': generate_id(customers), 'name': name, 'status': 'prospect', 'priority': 'B', # 默认中等优先级 'tags': [], 'contacts': [], 'source': source, 'value_est': 0, 'next_action': {'date': '', 'desc': ''}, 'created_at': datetime.now().strftime('%Y-%m-%d'), 'updated_at': datetime.now().strftime('%Y-%m-%d') } customers.append(new_customer) save_customers(data_file, customers) # 创建对应的客户文档目录 client_dir = Path(f"clients/{new_customer['id']}_{name.replace(' ', '_')}") client_dir.mkdir(parents=True, exist_ok=True) (client_dir / 'index.md').write_text(f"# {name}\n\n## 客户背景\n\n## 需求记录\n\n", encoding='utf-8') print(f"✅ 客户 '{name}' 已添加，ID: {new_customer['id']}") print(f"📁 文档目录已创建: {client_dir}") if __name__ == '__main__': main()

这个脚本完成了从交互式输入、ID自动生成、数据写入到目录创建的全流程，将繁琐的手动操作简化为一条命令python scripts/add_customer.py。

4.3 与外部系统的集成：邮件与日历

纯文本CRM可以成为你工作流的中心枢纽。通过脚本，可以连接其他工具。

• 邮件集成：使用像imap-tools这样的Python库，可以定期扫描指定邮箱（如“销售跟进”标签的邮件），提取发件人、主题和内容，自动追加到对应客户的Markdown日志文件中，并更新“最后联系时间”。
• 日历集成：在客户YAML中记录会议时间。可以写一个脚本，读取next_action或特定的会议字段，生成ics日历文件，或通过日历API（如Google Calendar API）自动创建事件。反过来，也可以从日历中读取已安排的会议，会后自动生成一个会议记录模板文件。

注意事项：自动化集成涉及账号授权和API密钥，务必妥善保管。建议将密钥存储在环境变量或安全的配置文件中，不要硬编码在脚本里。对于初级用户，可以先从手动复制粘贴开始，逐步构建自动化流程。

4.4 可视化与报表生成

虽然我们追求极简，但必要的可视化有助于宏观把握。我们可以用脚本将YAML数据转化为图表。

• 使用Pandas + Matplotlib：用Python的Pandas库读取YAML数据，可以轻松计算销售漏斗各阶段的客户数量、平均成交周期、客户来源分布等，并用Matplotlib生成简单的柱状图或漏斗图。
• 生成周报/月报：编写一个脚本，汇总本周/本月新增客户、已成交客户、重点跟进客户列表及其下一步行动，输出为一个格式清晰的Markdown报告，自动发送到你的笔记软件或团队聊天工具。

# 一个简单的销售漏斗统计示例 import yaml, pandas as pd, matplotlib.pyplot as plt with open('data/customers.yml') as f: data = yaml.safe_load(f) df = pd.DataFrame(data) funnel = df['status'].value_counts().reindex(['prospect', 'contacted', 'proposal', 'negotiation', 'closed_won']) funnel.plot(kind='bar', title='销售漏斗') plt.tight_layout() plt.savefig('sales_funnel.png')

5. 实战工作流构建：从零到一的管理体系

理解了组件，现在让我们把它们串联起来，构建一个完整的、可运行的纯文本CRM日常使用流程。我将以一个独立软件开发者“小李”的视角，演示他如何用这套系统管理他的潜在客户。

5.1 初始化与首次配置

小李在GitHub上找到了anthroos/plaintext-crm的示例，但他决定根据自己的需求从头搭建。

1. 创建项目目录：mkdir my_crm && cd my_crm
2. 初始化数据结构：他创建了data/customers.yml，并放入一个空列表[]。创建了clients/、templates/、scripts/目录。
3. 定义模板：在templates/new_customer.yml中，他写下了自己需要的客户字段模板（如前文YAML示例）。在templates/meeting_note.md中，他创建了会议记录模板，包含日期、参会人、讨论要点、行动项等。
4. 编写第一个脚本：他将前面提到的add_customer.py脚本放入scripts/，并赋予执行权限 (chmod +x scripts/*.py)。为了方便，他在~/.bashrc中设置了别名：alias crm-add="python3 /path/to/my_crm/scripts/add_customer.py"。

5.2 日常操作流程

场景一：捕获一个新线索小李在技术社区看到一个潜在用户提问，他回复后，决定将其纳入CRM系统。

1. 终端输入crm-add。
2. 根据提示输入公司名“星辰网络”，来源“技术论坛”。
3. 脚本自动生成IDC001，并在clients/C001_星辰网络/下创建了index.md。
4. 小李立刻打开这个index.md文件（他用VSCode，并设置了项目绑定），在“客户背景”里快速记下了社区链接和初步需求。

场景二：跟进与记录几天后，小李与“星辰网络”的技术负责人进行了第一次线上会议。

1. 会议结束后，小李在clients/C001_星辰网络/目录下，基于模板快速创建会议记录：cp ../templates/meeting_note.md meeting_20241025.md。
2. 他用十分钟填充了会议要点和双方同意的下一步行动。
3. 然后，他运行一个自己写的更新脚本update_next_action.py，输入客户IDC001，将下一步行动“提供API接入文档”和日期“2024-10-28”更新到data/customers.yml中对应的客户条目下。

场景三：每日检视与计划每天早晨，小李启动终端，运行scripts/daily_review.sh。这个脚本会：

1. 列出所有“今天需跟进”的客户（next_action.date == today）。
2. 列出所有“高优先级”且“状态为初步接触”的客户，提醒他主动推进。
3. 显示过去7天没有更新的“活跃”客户，提示他是否需要重新联系。 基于这个列表，小李清晰地安排了自己一天的工作重点。

场景四：周期复盘与报表每周五下午，小李运行scripts/generate_weekly_report.py。脚本会：

1. 统计本周新增线索、推进到新阶段的客户数。
2. 生成一个简单的文本报表，并绘制销售漏斗图。
3. 将报表和图片追加到他的周记笔记中。这让他对业务进展一目了然。

5.3 高级工作流：自动化信息同步

随着客户增多，小李希望减少手动同步。他写了一个脚本sync_email_to_log.py，配置为每天凌晨运行。

1. 脚本连接到他的工作邮箱，搜索来自客户域名（他从customers.yml中读取所有联系人邮箱域名）的邮件。
2. 对于每一封邮件，通过发件人邮箱匹配到具体客户。
3. 将邮件的日期、主题和核心内容摘要，以统一格式追加到该客户目录下的communication_log.md文件中。
4. 同时更新该客户在customers.yml中的updated_at时间戳。 这样，他的客户沟通记录就在后台自动累积，无需手动复制粘贴。

6. 常见问题、挑战与应对策略

从图形化软件切换到纯文本系统，必然会遇到一些挑战。以下是我在实践中遇到的一些典型问题及解决方案。

6.1 数据一致性与完整性维护

问题：手动编辑YAML文件时，可能打错缩进、写错字段名（如value_est写成value_estimate），导致解析失败。策略：

1. 使用Schema验证：为你的customers.yml定义一个JSON Schema或使用Python的Pydantic库。在脚本读取数据后或写入数据前进行验证，确保数据结构符合预期。
2. 提供编辑脚本而非直接编辑：尽量通过add_customer.py,update_field.py这样的脚本修改数据，减少直接编辑原始YAML文件的机会。脚本内部可以包含基本的校验逻辑。
3. 利用编辑器的力量：在VSCode中安装YAML插件，它能提供语法高亮、缩进提示和错误检查，极大降低出错概率。

6.2 团队协作与冲突解决

问题：多人同时编辑customers.yml文件，如何避免冲突？策略：

1. Git是核心：必须将整个CRM目录置于Git版本控制之下。这是解决协作问题的基石。
2. 明确分工与文件粒度：如果团队规模稍大，可以考虑按客户负责人或区域拆分主数据文件（如customers_sales_A.yml,customers_sales_B.yml），最后用一个汇总脚本合并查询。这样能减少文件冲突的概率。
3. 定义清晰的合并流程：在团队内建立规范，修改数据前先pull，修改后及时commit & push。遇到冲突时，基于Git的diff工具进行合并。对于关键字段（如status,value_est）的修改，可以在提交信息中说明原因。
4. 考虑只读共享视图：对于只需要查看客户状态的成员（如管理层），可以定期运行脚本，将数据生成一个静态HTML报告或只读的Web页面，而不是直接访问Git仓库。

6.3 搜索与查询效率

问题：当客户数量达到数百甚至上千时，简单的grep或线性搜索脚本可能会变慢。策略：

1. 索引化查询：不要每次都解析整个YAML文件。可以写一个脚本，在数据更新时，同时更新一个专门的“索引文件”（例如一个SQLite数据库或更简单的JSON索引），里面只存放用于快速搜索的字段（如ID、名称、标签、状态）。查询时先查索引，再定位到具体数据。
2. 使用专业工具：对于高级全文搜索（如在所有Markdown会议记录中搜索关键词），可以引入像ripgrep(rg) 这样的高性能命令行搜索工具，它比grep快得多，功能也更强大。
3. 定期归档：将已关闭（成交或丢失）超过一年的客户数据移入archive/目录，减少活跃数据量，提升查询速度。

6.4 移动端访问不便

问题：在手机上无法方便地查看或更新客户信息。策略：

1. 终端模拟器：在手机安装Termux（Android）或iSH（iOS）等终端模拟器App，配合Git和Vim/NeoVim，可以实现完整的命令行操作。这适合硬核用户。
2. 同步与只读查看：将CRM目录放在云同步盘（如iCloud Drive, Dropbox, Syncthing）中。在手机端使用支持Markdown/YAML的文本编辑器（如iOS的iA Writer, Android的Markor）查看文件。更新操作仍建议在电脑端完成，或通过简单的表单提交到后端脚本处理。
3. 搭建简易Web界面（进阶）：使用Python的Flask或FastAPI框架，写一个简单的Web应用，读取YAML数据并提供查询和表单修改功能。部署在本地网络或安全的VPS上，即可通过手机浏览器访问。这平衡了便利性和控制力。

6.5 心态转变与习惯养成

问题：从“点击即所得”的软件切换到“需要动手”的文本系统，初期会有不适应和惰性。策略：

1. 从小处着手：不要一开始就试图管理所有客户。先挑选5-10个最重要的客户，用这套系统管理起来。感受到查询和记录的便捷后，再逐步迁移。
2. 投资自动化：初期花时间编写或配置好那几个核心脚本（添加、查询、更新下一步行动）。一旦这些常用操作变得极其简单（一个命令搞定），使用阻力就会大大降低。
3. 接受不完美：你的系统可以随时迭代。今天觉得标签不够用，明天就在YAML里加个tags字段。今天觉得需要记录客户生日，明天就加上。这种“系统随着业务成长”的体验，本身就是一种乐趣和动力。

纯文本CRM不是一个现成的、完美的产品，它是一个需要你亲手参与塑造的“系统”。它给你的回报，是彻底的数据自由、无限的定制空间和与你的思维高度契合的工作流。它要求你从工具的被动使用者，转变为工作流的主动设计者。这个过程本身，就是对“如何更有效地管理客户关系”这一命题最深刻的思考和实践。