人脉脉动：基于SQLite与FastAPI的职场人脉管理工具设计与实现

做社交关系维护这件事，我以前一直靠通讯录和日历提醒硬撑。通讯录里存了上千个联系人，真正一年下来有过深度沟通的不到十分之一。日历提醒也是想起来就设一个，想不起来就算了，最后微信聊天记录里的“最近怎么样”都变成了群发模板。后来我实在忍不了，决定自己动手做一个叫“人脉脉动”的轻量职场人脉管理工具。

先说清楚这个工具要解决什么问题：录入姓名、行业、职位、联系方式这类静态信息只是地基，核心价值是把“人际维护”从靠自觉变成靠系统——你设置每个联系人的沟通提醒周期，比如重要客户每两周聊一次，普通同行每季度同步一次，工具会主动把你该联系的这个人推到面前，提醒你为什么联系、上次聊到哪了、这次可以聊什么。下面我会把这个项目的需求拆解、方案设计、核心实现和踩坑记录完整写出来。

1. 项目核心需求拆解与整体设计思路

1.1 从痛点到需求：人脉管理到底需要什么

动笔写第一行代码之前，我先是把自己过去五年维护人脉的失败过程复盘了一遍，整理出真正卡住我的三个问题。

第一是记录维度缺失。通讯录里存了电话和邮箱，但行业、最近一次沟通日期、对方的关注点、上次聊过的合作意向，这些关键信息全在本能和脑子里。半年之后想回访一个猎头，我完全想不起来上次是什么时候联系的、聊过什么，更不敢贸然发消息。

第二是提醒机制反人类。传统日历提醒是“单点闹钟”，今天提醒你联系张三，你忙起来错过了就没了，系统不会根据你的反馈做任何调整。健康的人脉维护更像种地——浇水有周期，错过一次要能顺延、能补种，这需要系统理解人脉的维护节奏。

第三是沟通记录难以回溯。即使你记得上次聊过“对方团队在扩招”，但当你们一周后真的聊起来，你很难在对话前快速调出上下文。人脉运营本质上就是信息管理，上下文断裂等于前功尽弃。

这个工具的核心需求因此确定为四层：静态档案层（姓名、行业、职位、联系方式）、沟通节奏层（上次沟通时间、提醒周期）、提醒触达层（推送提醒）、沟通沉淀层（沟通内容记录）。这四层刚好对应一个闭环：录入信息驱动提醒计划，提醒触达促进实际沟通，沟通结果回写到档案更新上下文。

1.2 产品功能地图：MVP版本的边界控制

个人用工具最容易犯的错误是贪多求全。我见过有人给自己做人脉管理软件，功能表里塞了CRM分析、生日祝福自动发送、社交平台聚合，最后项目烂尾，连联系人都没录几个。

所以我在MVP版本设了三个克制原则：单机优先、数据本地、流程闭环。登录、云同步、多人协作全部砍掉，只保留一个使用者能独立跑完核心循环的功能集合。

具体功能列表如下：

• 人脉档案：姓名、行业、职位、联系方式、所在地、备注
• 沟通记录：每次沟通的时间、渠道、话题、结论、下一步行动
• 提醒周期：按联系人设置N天/周/月的沟通周期
• 提醒推送：到期联系人自动进入“待联系清单”，并触发桌面/邮件提醒
• 人脉筛洗：按行业、职位、最近联系时间筛选，快速定位僵死人脉

这套功能已经足够构建一个真实可用的“人脉运营中台”，而不只是另一个联系人数据库。我做产品规划时给自己定的验收标准是：一个零基础的普通上班族，第一次使用后能在五分钟内录入一个人脉、设置好提醒周期、并看到下次联系时间被系统自动算出来。

1.3 技术方案选型：为什么选这套组合

作为个人项目，技术选型的核心逻辑是“一个人能在可接受的维护成本下做完、并长期使用”。我没有选择去开发APP，也没有上重量级后端框架，而是采用了本地优先+轻量服务的架构组合。

数据层选了SQLite，因为它是零配置文件、单文件存储的嵌入式数据库，适合个人工具的数据量级。一万个联系人加上二十万条沟通记录，对SQLite来说游刃有余，而且整个数据库就是一个文件，备份只需要拷贝走。对这个项目来说，数据安全的最大威胁不是数据库性能，而是我自己换电脑的时候忘了备份，所以无服务器的本地文件反而是最轻的保险。

应用层选了Python + FastAPI，配合简单的Web页面。原因有三：FastAPI写CRUD接口成本极低；Python生态里有现成的提醒推送方案；Web界面可以在手机浏览器里直接打开，天然适配移动办公场景。

为了减少通知机制对第三方平台的依赖，提醒方面我选了两条腿走路：长期运行的服务可以用桌面通知和邮件；个人非持久运行时，可以用一个简单的“待联系清单”页面作为人工拉取式提醒。这两套机制互补，能覆盖我“开着电脑开发”“只打开浏览器”这两种日常状态。

2. 数据库设计与核心模型详解

2.1 核心模型：联系人档案表

人脉数据库的设计决定了整个工具的上限。如果表结构设计得不够灵活，后面加字段就是噩梦。

contacts表我按“档案”和“状态”两类字段分开设计。档案字段是静态的：姓名、性别、行业、职位、联系方式、公司、地址、来源、备注。状态字段是动态的：重要等级、下次联系时间、联系频率、当前沟通状态。

这里最需要设计心机的是重要等级和联系频率的映射关系。我没有让用户直接输入“每15天联系一次”这种数字，而是让用户先选等级（重要/一般/弱连接），系统再给出默认周期。为什么这么做？因为大多数人对“我该多久联系这个人一次”是没有直觉的，但对“这个人对我重不重要”有天然判断。系统把模糊判断翻译成明确数字，再由用户微调，这个交互顺序能大幅降低录入摩擦。

具体映射表如下：

这套默认值其实暗合了著名的“邓巴数”理论——人类能维护的稳定社交关系大约有150人，其中核心圈层更少。对个人工具来说，90天以上的提醒周期基本等于“有点像僵尸联系人”，超过270天就可以直接标记为休眠状态。

2.2 沟通记录与提醒任务表

第二条核心表是communications，负责沉淀每次沟通的内容。字段除了基本的时间、渠道、摘要，我特意设计了三个结构性字段：话题标签、对方关注点、下一步承诺。

话题标签是为了后续的筛选分析，比如你可以一键拉出所有聊过“跳槽”话题的人；对方关注点是自动生成回访话术的原料；下一步承诺是最容易被忽略但最该记录的东西——你上次答应给人家发一份资料，这是下次破冰的最好切口。

第三条表是reminders，用于管理提醒任务的调度状态。这张表不直接存储“下次联系时间”，而是存储“计算下次时间所需的规则”——周期天数、是否启用、提醒渠道（桌面/邮件/应用内）。通过一个视图或查询语句，动态计算出联系人是否到期。这比固化一个字段灵活得多，因为用户可以随时修改周期，第二天系统就能按照新周期重新计算。

这里要特别说明一下为什么用规则计算而不是直接写死时间。我最初的原型就是直接存next_contact_date的，后来发现只要用户改一次周期，这个时间就要手动重算，非常坑。改成规则驱动之后，界面上的“下次联系日期”永远是实时算出来的派生值，绝不会出现数据不一致。

2.3 人脉重要度评分的动态计算公式

人脉管理工具最容易被做成“通讯录+闹钟”，但真正好用的工具应该有能力回答“谁值得你花时间”。我在项目里实现了一个人脉价值评分模型，作为排序和筛选的底层依据。

评分模型分三个维度：连接价值（基于重要等级和互惠潜力）、活跃价值（基于最近沟通时间的衰减程度）、成长价值（基于行业发展趋势和职级的变化潜力）。MVP版本用了简化公式：

score = 重要等级权重 × 0.5 + 活跃度 × 0.3 + 成长潜力 × 0.2

活跃度计算采用e指数衰减模型：沟通距离今天越远，活跃度越低。以30天为半衰期，公式为exp(-天数/30)，这个数学模型用来模拟“人脉关系的自然冷却曲线”非常合适。

举个例子：一个重要等级为满分的联系人，已经80天没联系了，他的活跃度只有初始的大约三分之一，综合评分就会掉下去。系统每天自动重算所有人的评分，评分排名变化超过五位的人，会出现在首页的“人脉波动”区域，告诉你“谁在快速贬值，需要抢救”。这套动态评分机制的好处是把人脉管理从“被动响应提醒”变成“主动感知关系价值变化”。

3. 前端交互与界面设计要点

3.1 个人工具的界面哲学：减少维护成本

个人工具最容易失败的地方不是技术，而是界面设计过于复杂导致用户不想打开。这个项目界面设计上有几条我自己总结的原则。

第一是默认勿扰。打开首页，不显示任何表单填写入口，直接显示三块内容：今日应联系清单、即将到期清单、人脉价值波动榜。如果你是刚打开工具，系统先给你“下一步该干嘛”的答案，而不是让你思考“我该点什么”。

第二是三步录入。新增一个人脉，界面只分三步：基本信息（姓名和联系方式）→ 职业画像（行业和职位）→ 维护规则（重要等级和提醒渠道）。每个步骤只显示三到五个字段，绝不让用户面对一张十几个字段的长表单。

第三是回溯优先。在联系人详情页，沟通历史时间线占据浏览量最大的上半屏，静态档案信息收起到折叠面板。因为每次打开联系人详情页，核心诉求都是“上次聊了什么”，而不是“他的职位是什么”。这个界面权重分配的决策，跟传统通讯录正好相反。

3.2 关键交互解析：沟通记录的时间线输入

记录沟通内容是最容易被用户“偷懒跳过”的功能，所以交互设计必须把它变成极低成本的操作。我设计了“快速记录”浮动按钮，点开之后只有一个输入框和一个保存按钮，同时支持语音转文字——手机上用输入法自带语音即可，不需要额外能力。

但要让沟通记录真正产生复利价值，光有快速记录还不够。我在快速记录的界面里加了一个“自动带出上次沟通摘要”的功能。当你从“今日应联系”清单里点进某个联系人准备联系时，系统自动把最近三条沟通记录置顶显示，并且预填一个“延续上次话题”的草稿，比如“上次聊到你在考虑换工作方向，最近有什么进展吗”。这个设计思路是：不要让用户从空白开始写沟通记录，而是让用户基于上下文做增量更新，这样记录习惯才能真正坚持下来。

3.3 针对手机浏览器的响应式适配

这个工具我没有做成手机APP，而是Web页面适配手机浏览器。好处是不用应用商店审核，浏览器打开就能用，坏处是需要处理好响应式布局的几个坑。

最大的坑是移动端浏览器的“添加到主屏幕”模式。我在页面里设置了apple-mobile-web-app-capable和对应的meta标签，让页面在安卓和iOS上都能以全屏WebApp的模式运行。其次是安全区的处理，底部导航栏必须适配iPhone的刘海屏和底部横条，padding-bottom直接用env(safe-area-inset-bottom)。

表单输入方面，移动端键盘弹出会遮挡输入框，我在FastAPI返回的HTML模板中加了监听visualViewport.resize事件的JavaScript，在键盘弹起时自动把当前聚焦的输入框滚动到可视区域中间。这些细节如果不处理，手机上的体验就永远像“网页套壳”，不像“工具”。

在实战过程中我实测发现，手机浏览器的表单自动填充行为会干扰数据录入，尤其邮箱和公司名经常被浏览器自动补成无关值。最终我选择把表单的autocomplete全部设为off，虽然稍微牺牲了重复录入的效率，但换来了数据准确，对个人工具来说数据准确永远优先于输入效率。

4. 提醒机制的三种方案与最终实现

4.1 提醒的核心问题：怎么让提醒真正有效

做提醒功能最大的难点不是“怎么推送一条消息”，而是“怎么让用户把消息当成行动指令”。微信上每天能收到几十条通知，如果这个工具的消息通知跟购物App长得一样，用户就会习惯性忽略。

我的设计原则是把通知从“打扰”转变成“可执行的待办”。提醒消息必须包含三个要素：联系谁、为什么联系（上次沟通摘要）、建议动作（发消息/打电话/约见面）。比如推送给用户的消息不是空洞的“该联系张经理了”，而是“张经理（核心客户）已48天未沟通，建议今天上午致电，上次聊到预算审批流程，可询问审批进展”。有了上下文和行动建议，提醒的本质就从“闹钟”变成了“助理”。

4.2 方案一：应用内待联系清单

最基础也最重要的提醒机制是应用内的“今日待联系”面板。每天第一次打开页面，系统自动执行一次到期计算，把所有上次沟通时间 + 周期 < 今天的联系人拉出来，按重要等级排序。

这个方案的技术实现极其简单，一条SQL就能搞定：

SELECT c.id, c.name, c.importance, c.job_title, MAX(cm.comm_date) as last_contact, julianday('now') - julianday(MAX(cm.comm_date)) as days_since FROM contacts c LEFT JOIN communications cm ON c.id = cm.contact_id WHERE c.reminder_enabled = 1 GROUP BY c.id HAVING (julianday('now') - julianday(MAX(cm.comm_date))) >= c.reminder_days OR MAX(cm.comm_date) IS NULL ORDER BY c.importance DESC;

这条SQL值得拆开讲。LEFT JOIN保证没有沟通记录的新人脉也会被捞出来，因为他们恰恰是“最该被激活”的。HAVING里的条件处理的是“有记录但超期”和“完全没记录”两类情况。ORDER BY c.importance DESC确保重要的联系人在清单顶部，而不是沉浸在一堆弱连接里。

另外我在这条查询里特意区分了“待行动”和“待跟进”两个状态。待行动是已经超期的联系人，对它们的处理建议是立即联系；待跟进是今天即将到期、还没超期的联系人，它们的作用是提醒你别等到过期才行动，而是提前规划。这个区分能在潜意识层面培养用户提前安排沟通的习惯，而不是永远在补救式联系。

4.3 方案二：桌面通知与系统级提醒

如果服务处于前台运行状态，浏览器桌面通知是最自然的推送方案。实现上我用Notification API，通过FastAPI提供的一个接口返回当前所有超期联系人，前端每次拿到结果后调用系统通知。

实际开发里有个容易踩的坑：桌面通知在Mac上如果不设置tag属性，同一标题的多次通知会堆叠成单独条目，用户关掉一个还得再关一个，体验很差。解决办法是给每次通知设置tag为contact_remind，新通知会自动替换同tag的旧通知，轮播效果非常理想。

浏览器通知之外，我还接了邮件提醒作为补充。为什么不只用浏览器通知？因为个人电脑不一定总开着浏览器。FastAPI配合SMTP_SSL发邮件，每天定时跑一个任务，把当天待联系清单汇总成一份“每日人脉维护简报”。邮件模板用纯文本，因为我测试下来，富文本HTML邮件在部分企业邮箱里会被拦截或折叠，纯文本反倒在手机上看起来最清爽。

4.4 方案三：反向量化——通过统计倒逼主动维护

技术手段之外，我还实现了一个“反向量化”机制：每周给用户出一份“人脉维护周报”。周报内容包含三块：这周实际沟通了多少人、有多少提醒被忽略/延后、分行业统计的沟通覆盖度。

这个机制不直接推送通知，而是通过“数据事实”刺激用户反思。比如周报显示，“你上周有12个联系人到期，实际沟通了4个，其中核心客户2人中有1人已超过60天未联系”，这种赤裸裸的数字比任何提醒都有力。

说实话，一开始我也觉得这种统计可能没什么用，但实际用下来发现它恰恰是最容易被忽略但长期价值最高的功能。周报相当于项目的“仪表盘”，驱动人脉维护从被动变主动。用户看到周报才会意识到，“原来我并不是没时间，只是没有把时间花在对的人身上”。

5. 实操过程与代码实现解析

5.1 FastAPI后端与SQLite数据层的完整骨架

整个项目后端使用FastAPI构建，核心模块分为路由层、服务层、数据层三层。

路由层的职责只做HTTP协议的收发包，不直接写SQL。服务层承载业务规则，比如联系人到期计算、人脉评分更新。数据层是SQLite操作的工具模块，封装了数据库连接和基础CRUD。

完整的项目结构如下：

project/ ├── main.py # FastAPI入口，路由注册 ├── models.py # Pydantic模型（请求/响应） ├── services/ │ ├── reminder.py # 到期计算、评分计算 │ └── report.py # 周报生成 ├── data/ │ └── crm.db # SQLite数据库文件 ├── static/ │ ├── js/ # 页面逻辑 │ └── css/ # 样式 └── templates/ └── index.html # 单页应用入口

这个结构不要觉得简单，个人项目最忌讳过度分层。你写三五十个工具类文件去管理一个千人联系人库，最后花在“找代码”上的时间比“写代码”还多。分层的唯一目的就是让人能快速定位修改，不是为了显得专业。

5.2 人脉到期计算的核心服务实现

到期计算是服务的核心，内部逻辑不要一次性全算，而是分两步：先把“所有需要被纳入检查范围的人脉”取出来，再对每个人脉计算“最后沟通日期”和“下次应沟通日期”。

这里需要注意一个性能细节：如果你对每一个联系人单独发一条SQL去查最近的沟通时间，一万个联系人就会产生一万次查询，虽然单次很快，但累积起来就会让首页打开变慢。我的做法是用一条带窗口函数的查询一次性把所有联系人的最近沟通时间都取出来，这个方案在原型的测试数据下从大约3000毫秒优化到了120毫秒：

def get_overdue_contacts(db_path): conn = sqlite3.connect(db_path) conn.row_factory = sqlite3.Row query = """ WITH last_comm AS ( SELECT contact_id, MAX(comm_date) as last_date FROM communications GROUP BY contact_id ) SELECT c.*, COALESCE(lc.last_date, '1970-01-01') as last_contact, julianday('now') - julianday(COALESCE(lc.last_date, '1970-01-01')) as days_since FROM contacts c LEFT JOIN last_comm lc ON c.id = lc.contact_id WHERE c.reminder_enabled = 1 """ cursor = conn.execute(query) rows = cursor.fetchall() overdue = [] for row in rows: days_since = row['days_since'] if days_since >= row['reminder_days']: overdue.append({ 'id': row['id'], 'name': row['name'], 'industry': row['industry'], 'position': row['position'], 'days_since': int(days_since), 'overdue_days': int(days_since - row['reminder_days']) }) conn.close() return sorted(overdue, key=lambda x: -x['overdue_days'])

这段代码有几个值得注意的细节。处理“从未联系过的联系人”时，COALESCE把最后沟通时间设为Unix纪元，这样他们一定是超期状态。排序用的是overdue_days而不是days_since，因为一个30天周期的人超了2天和一个90天周期的人超了2天，紧急程度是相同的，都应该按超期程度排，不能因为周期长就不管。

5.3 沟通记录与联系人更新的联动逻辑

“记录沟通”不能只往communications表里插一条数据就完事，必须同时触发几个联动操作：更新该联系人的人脉评分、重算下次提醒日期、刷新行业热力数据。

这个联动我用服务层的事件函数实现，而不是靠程序员在每次调用处手工写三遍。核心就是插入沟通记录后，自动调用更新函数：

@app.post("/api/contacts/{contact_id}/communications") def add_communication(contact_id: int, payload: CommIn): # 1. 插入沟通记录 insert_comm(contact_id, payload) # 2. 更新联系人最近联系状态（可选：清空“下次联系时间”让系统重算） touch_contact(contact_id) # 3. 更新人脉价值评分 update_score(contact_id) # 4. 如果存在待办的延伸任务，把它标记完成 resolve_pending_tasks(contact_id, payload) return {"status": "ok", "next_contact_days": get_next_contact_days(contact_id)}

这里的resolve_pending_tasks是一个很实用的功能——记录沟通内容时，允许用户在文本里用#action:发送资料、#action:约咖啡这样的语法标记下一步动作。系统解析出来后自动创建成待办事项，放在该联系人的详情页。下次你打开这个联系人时，会直接看到“上次遗留的一项待办”，不会出现“我记得我当时说要做什么来着”的尴尬。

5.4 导入导出与数据迁移的实践

个人工具最怕的是数据锁死。我一开始就实现了通用的CSV导入导出，这不仅是为了方便初始录入，更是为了让用户随时能“逃离”这个工具——这个心理安全感其实很重要，当用户知道数据是被尊重的、能带走的，反而会更放心地用下去。

CSV导出实现很简单，查询所有联系人及其最近沟通记录，拼成行写入文件。但CSV导入有个隐藏坑：中文编码。Windows上Excel保存的CSV默认是GBK编码，如果在Python里直接按UTF-8读，第一行所有中文都会乱码。我的处理方式是先读二进制内容，用chardet检测编码，再按检测结果解码，或者让用户明确选择编码格式：

def read_csv_auto(file_bytes): encodings = ['utf-8-sig', 'gbk', 'gb18030', 'utf-8', 'big5'] for enc in encodings: try: text = file_bytes.decode(enc) return text except UnicodeDecodeError: continue raise ValueError("无法识别CSV编码，请转换后重试")

顺带说一句，utf-8-sig这个编码很重要，因为UTF-8文件开头可能带BOM头，直接用普通utf-8解码后，第一行第一个字会带一个不可见字符，用utf-8-sig会自动忽略这个BOM。这个小细节我在第一次导入时踩过，现在每次处理用户上传文件都默认尝试它。

6. 常见错误、坑点与解决方案速查

6.1 提醒时间算错：时区与日期边界问题

提醒逻辑最容易出错的地方不在业务规则，而在日期处理。比如“上次沟通时间”和“今天”的差值，如果按自然日算，有一个“今天是否计算”的边界问题。一个周期为30天的联系人，如果上次沟通是5月1日，今天是5月31日，那“相隔30天还是29天”？取决于你定义的到期日是5月31日当天还是6月1日零点。

我最终采用的规则是：今天 - 上次沟通日期 >= 周期天数时触发，即5月31日时，相隔30天，触发提醒。这样用户理解的“每30天联系一次”就是每隔30个自然日出现一次提醒，不多不少。

另一个坑是SQLite的julianday('now')返回的是UTC时间，跟北京时间相差8小时。如果用户在北京时间5月31日晚上11点操作，系统按UTC计算还是5月31日，没问题；但到了北京时间6月1日早上7点，UTC时间还是5月31日，此时julianday('now') - julianday(last_date)会被算少一天。解决方式是让数据库连接设置本地时区，或者统一用程序代码传入“本地日期字符串”，不让数据库自己取时间。我在项目里选择了后者，所有日期都由Python的datetime.now().date()计算后作为字符串传给SQLite，彻底避开数据库时区的坑。

6.2 浏览器通知失效：权限申请与触发时机

桌面通知的权限很傲娇。用户在页面加载时如果还没跟页面产生任何交互，浏览器会直接屏蔽权限申请弹窗。所以申请通知权限的代码不能放在window.onload，而要放在用户第一次点击“开启提醒”按钮的时候。这是一个很典型的浏览器交互规则，踩过一次之后就理解了。

权限拿下来之后还有第二个坑：Service Worker的环境下，通知要能正常显示，必须在注册时保住notification的默认图标。做WebApp推送时如果省略了这个图标，部分浏览器的通知会变成空白图标，看起来非常像系统bug。

实际上，如果你用桌面版Chrome测试通知时，new Notification()在主线程调用会失效，但在原生JS里不带Service Worker直接调用是正常的。所以我的实现里用了兜底——先检测window.Notification是否存在，再询问权限，最后构造通知内容。这套兼容写法能覆盖绝大多数现代浏览器的使用情况。

6.3 数据录入效率低：自动补全与批量录入

录入人脉最烦的其实不是表单字段多，而是完全相同的“公司名”和“行业名”反复输入。比如你认识同一家公司的五个人，公司名要输五遍；行业分类每次都得打字。我在前端加了两个实用组件。

第一个是公司自动补全。输入公司名时调用一个本地接口，从已有联系人数据里模糊匹配以前输入过的公司名，展示下拉候选，点选即填。这相当于给数据录入加了一个“记忆层”，录得越多，后续录入越快。

第二个是批量导入体验优化。前面说的CSV导入接口不算完，前端还要支持一个简单的“粘贴录入”功能——用户从Excel或通讯录里复制三列数据（姓名、公司、职位），粘贴到多行文本框里，系统按行解析并批量创建联系人。这个功能对于第一次把手机通讯录里的几百号人倒入工具至关重要，否则光是手工录入这一步就能劝退90%的用户。

6.4 长期使用下的数据膨胀与归档策略

人脉管理工具用久了以后，数据会缓慢膨胀——沟通记录上万条、联系人上千个、提醒历史数千条。不处理这个问题，功能就会慢慢变得卡顿且信息冗余。

我在服务层设了“年度归档”机制：把上一年的沟通记录、提醒记录标记为archived，默认查询时不显示，只在“历史回顾”页面可以看到。这能显著减少日常页面查询的负担，同时维持数据完整性。

另一个关键策略是休眠联系人识别。系统支持设置一个阈值，比如“超过270天未沟通且重要等级为一般”，自动把联系人标记为“休眠”，从日常活跃清单里移除。这不是删除，而是让系统集中在“真正值得维护”的人脉上，不要被那些三年没联系的老同学的礼貌性寒暄稀释注意力。

7. 这个项目给我的真实启发与后续扩展方向

7.1 真做完之后，我学到的三件事

第一，人脉管理的本质不是“提醒联系人”，而是“管理注意力”。你每天能对外输出的关怀和精力是有限的，与其每周给二十个人发一模一样的模板消息，不如这个月认真维护好那五个核心联系人。工具的提醒价值不在于通知的数量，而在于帮你把有限的注意力投放到正确的位置上。

第二，个人工具最重要的是“愿意用”。我见过太多精心设计的个人管理系统死在“今天懒得记”上。所以这个项目的每一个交互都围绕“降低维护成本”展开——快速输入、自动补全、上下文预填、语音输入。你看一个功能要不要做，不看它多炫，就看用户使用它的摩擦成本有多大。

第三，动态评分模型比静态标签有用得多。静态标签“重要客户”永远在那里，它不会变。但动态评分会随着沟通时间衰减，让你直观看到“再重要的人，三个月不联系也会生疏”。这个“生疏感”一旦被量化，会非常直接地推动行为改变——我因为这个评分模型，重新激活了至少五个曾经很重要的联系人。

7.2 后续可做的扩展：从个人工具到轻量协作

这个项目目前定位在个人本地使用，但它的架构可以平滑扩展。如果以后想做成团队版或轻量协作工具，技术栈完全可以复用，需要改的是数据层和权限层：把SQLite换成PostgreSQL，联系人拆成公共客户和私人联系人，增加标签体系和团队成员指派，提醒通知从桌面/邮件扩展到企业微信/钉钉的webhook机器人。

还有一个我非常想实现但还没做的是“沟通策略建议”。基于沟通记录里提取的关键词，比如“跳槽”“融资”“读MBA”，给用户生成个性化的再次沟通建议。这部分需要自然语言处理能力，个人项目做起来成本有点高，但如果你的沟通记录累积到一千条以上，纯靠人脑从中挖掘洞察已经很困难了，值得用技术手段辅助。这也是我个人认为以数据驱动人脉维护的未来方向。

说实话，写到这儿我觉得这个项目最大的价值不在于它的代码量，而在于它把“维护人脉”这件看起来靠情商的事，变成了一套可以被记录、被提醒、被复盘的系统工程。人际关系当然需要真诚，不能全靠工具管理，但工具可以帮你记住那些因为忙而忘记的真诚时刻。愿你和我一样，从这套系统里重新认识自己到底有多少值得维护的人脉。