CRM

核心用法

本技能指导用户从零构建个人CRM系统，核心哲学是"从文件开始，按需演进"。首先通过对话明确用户追踪场景（客户/投资人/求职联系人）和技术舒适度，在~/crm/目录下创建单一数据源。初始仅用一个contacts.json文件，包含最简字段：id(UUID)、name、email、company、phone、notes、tags、created、updated。当用户需要查询"上次联系X是什么时候"时，再创建独立的interactions.json；出现多联系人同公司场景时，分离出companies.json；提及销售漏斗概念时，添加deals.json。

显著优点

1. 渐进复杂度：拒绝过早引入Web应用、数据库、认证、移动端等工程负担，用时间验证真实需求
2. 技术适配：根据用户技术水平推荐CSV/JSON/SQLite不同层级方案
3. 数据可迁移性：UUID主键、扁平结构、时间戳字段确保数据无损演进
4. 实用辅助：提供命令行快速添加、跨文件搜索、备份脚本等降低摩擦的工具
5. 多设备同步：优先推荐云文件夹（Dropbox/iCloud）而非自建同步方案

潜在缺点与局限

• 手动维护成本：无自动化邮件/日历抓取，依赖用户主动记录
• 无协作能力：单用户本地设计，多人场景需后续迁移
• 查询能力有限：文件阶段依赖grep/jq，复杂分析需SQLite升级
• 移动端缺失：早期刻意排除，外出场景需配合云文件App使用

适合人群

• 自由职业者、独立顾问、小型工作室主理人管理客户关系
• 求职者系统性跟踪投递进度和网络联系
• 投资人/创始人管理deal flow和投资人关系
• 技术背景用户偏好数据自主可控，反感SaaS订阅和厂商锁定

常规风险

• 数据丢失：强调备份脚本和云同步，但用户可能忽略执行
• 重复录入：需依赖辅助脚本检查重复邮箱
• 迁移摩擦：文件到SQLite的转换虽提供脚本，仍需用户操作配合
• 使用半途而废：初期手动维护门槛可能导致放弃，设计意图正是用低门槛文件阶段筛选真正需求

核心用法

本Skill是一套渐进式个人CRM构建方法论，而非现成工具。它引导用户从最简单的文件系统开始，逐步演化到适合自身需求的客户管理方案：

启动阶段（Week 1）：创建~/crm/目录，用单个contacts.json或CSV文件记录联系人（id、name、email、company、phone、notes、tags、created、updated），强制使用UUID和tags数组保证灵活性。

演进触发器：当用户频繁询问"上次何时联系X"时，提示创建独立的interactions.json文件，通过contact_id关联记录沟通历史；当同一公司出现多个联系人时，分离出companies.json实现多对多关系；当提及"pipeline""deal value"等词汇时，再引入deals.json跟踪商机。

迁移时机：联系人超过100条、需要复杂查询或多用户并发访问时，提供SQLite迁移脚本，而非强制手动重建。

显著优点

• 反过早工程化：明确反对第一周就建议Web应用、邮件/日历集成、认证系统或移动App，大幅降低 abandonment rate
• 数据模型验证优先：用文件摩擦测试用户真实使用习惯，避免为假设需求写代码
• Unix哲学贯彻：提供命令行快速添加、jq/grep搜索、定时备份等实用脚本，而非捆绑复杂界面
• Schema设计成熟：UUID主键、多对多关系、时间戳审计字段、tags替代硬分类，均为生产级实践

潜在局限

• 技术门槛：需要用户具备JSON/CSV编辑、命令行操作、jq查询等基础能力
• 无可视化界面：纯文件阶段对非技术用户不够友好
• 同步方案朴素：仅建议网盘或Git，无实时协作或冲突解决机制
• 依赖自觉执行：无强制校验，数据完整性全靠用户养成备份、查重等习惯

适合人群

独立顾问、自由职业者、投资人、求职者等需要轻度但持续管理人脉关系的技术型用户；以及希望理解CRM核心数据模型、再决定是否购买商业SaaS的决策者。

常规风险

• 数据丢失风险：文件阶段无自动备份，用户需自行执行提供的zip备份脚本
• 隐私合规责任：Skill本身不收集数据，但用户存储的联系人信息需自行符合GDPR等法规
• 演进断档风险：若用户跳过阶段直接复杂化，可能陷入半吊子架构