起步：从Excel地狱到自建系统
兄弟们，今天来聊聊我那个被老婆戏称为“都市美艳后宫”的私人CRM项目，就是一套帮我管理日常社交关系的土办法。为啥要搞这个？还不是被逼的。以前我就是个表格党，所有人的联系方式、最近一次聊天记录、甚至哪个周末约过饭，全靠Excel手动维护。一旦数据量上去了，那玩意儿就是个灾难，我每次打开表格都头皮发麻，一不小心就搞错了一行，该回复的没回复，该保持联系的断了线。
去年年中，我彻底崩溃了。我翻找了一个小时，才发现一个重要约会的时间被我写到了前年的单元格里。那天晚上我气得把电脑砸了的心都有，躺在床上琢磨：既然公司里有各种客户关系管理系统，我自己的关系网为啥就不能搞一个？说干就干，我决定自己动手，搞一套专属的“后宫日志”。
V1.0：用Python和SQLite粗暴实现
既然要搞，就得用最快的方式跑起来。我手边正好有个空闲的树莓派吃灰，二话不说，我刷了系统，装了Python。数据库我选了最简单的SQLite，为因为它不需要复杂的配置，一个文件就能搞定，图的就是一个省事儿。
我的第一步是定义核心数据结构。一开始我把事情想得太简单了，只设置了三个字段：姓名、联系方式、上次互动时间。结果跑了没两天我就发现这不行，系统没法告诉我“这个人重不重要”，也没法区分是微信互动还是见面互动。我得加料。
我立马重构了数据模型，手动砸进去了几个关键指标：
- 亲密度指数 (Affinity Score): 1-100分，手动调整，作为优先级。
- 互动类型 (Interaction Type): 列表选择，比如‘面谈’、‘电话’、‘文字’，分值不同。
- 警报周期 (Alert Cycle): 定义多久不联系就会被系统标记。
我用Flask写了一个极其简陋的后端API，前端？压根就没有！我直接用Postman和命令行硬着头皮操作，增删改查全靠代码跑。那界面，简直丑到亲妈不认，但功能跑起来了，能记录了，我就踏实了。
卡点：从数据同步到提醒机制
V1.0最大的问题是数据输入太费劲了，我得手动把聊天记录整理成JSON格式再塞进去。我发现，我建立这个系统的目的，是为了省时间，结果却花了更多时间在维护数据上。
这个问题让我停滞了整整一个月。后来我琢磨，既然我主要是微信交流，能不能搞个接口来抓取微信数据？别误会，我没傻到去爬微信官方的接口，那等着被封号。我采用了一个旁门左道的方法，借助了一个开源的本地微信机器人框架。我花了两周时间，对着文档瞎折腾，终于让它实现了基础功能：自动解析新的聊天记录，并根据关键词自动更新“上次互动时间”和“互动类型”。
但更让我头疼的是提醒机制。我需要系统在某个“后宫成员”的亲密度指数低于特定阈值时，自动发邮件提醒我。我一开始用Python自带的sched模块，结果经常因为系统休眠而漏跑任务。后来我决定升级，咬牙把SQLite迁移到了PostgreSQL，并利用Linux系统的Cron Job来定时触发后端脚本，这才保证了任务的稳定性。
这个Cron Job的配置我调了一整夜，老是报错，不是权限不对就是路径写错，我发现只是因为我没给Python脚本加上执行权限，简直是低级错误。但搞定了之后，系统终于能按照我的需求实时跑起来了：每天早上七点半，我的邮箱里都会收到一份“今日需互动清单”。
最终形态与经验总结
到我的“都市美艳后宫更新日志”已经运行了八个月，版本号迭代到了V2.4。虽然前端界面依然是简陋的Vue+ElementUI，但至少看起来像个正经应用了。
我最大的体会是：
- 不要怕推倒重来：一开始用SQLite是错的，但正是因为我用了错的东西，才让我彻底理解了什么是数据一致性，以及为啥要用更专业的数据库。
- 自动化是解放双手的前提：如果数据输入还要手动操作，这个项目早就死了。我花在自动化抓取和处理上的时间，是绝对值得的投资。
- 稳定性高于一切：我的目标是确保我不会错过任何重要的沟通，所以宁愿多花时间在Cron Job和异常捕获上，也不能让提醒机制出岔子。
说真的，这套系统帮我理清了社交的优先级，让我不再被动，而是主动去维护人际关系。虽然名字听起来有点不正经，但这确实是我近一年来，最有成就感的一个实践项目。
我打算给它加上一个移动端界面，让我在外面也能随时查阅和更新状态。这又是一个大坑，不过我已经准备好继续往下跳了。