尧图网站建设 
最近看到一道很有意思的辩论赛辩题西南政法大学 VS 中国农业大学辩题是“在高度流动的社会里该/不该坚持追求与他人的深度关系”。作为技术人我第一反应不是站队而是想到一个问题如果“深度关系”是一条连接我们是否能像设计高可用系统一样为它设计心跳、超时和重试机制这个类比并不牵强。高度流动的社会里换城市、换公司、换圈子的频率越来越高成年人维护一段深度关系的时间窗口越来越碎片化。很多人不是不想坚持而是“想联系的时候已经忘了”或者“还记得联系方式却不知道如何开口”。这本质上不是态度问题而是关系维护的工程问题。所以本文想做的事很具体从辩题出发把深度关系拆成数据模型和行为模型用 Python 写一个本地关系维护助手跑通“记录联系人—记录互动—计算关系温度—自动提醒”的完整链路。读完你可以直接用它来管理自己的重要关系也可以把同样的思路迁移到用户留存、客户运营甚至社区健康度分析中。1. 这篇文章真正要解决的问题辩论赛讨论“该不该坚持”但真实世界里很多人卡在更前一步不是没有意愿而是不知道从哪一刻开始“维护关系”这个动作已经断了。高度流动的社会把社交关系切得很碎。一个人在北上广深工作三年回到二线城市原来每周见面的同事一年能聚一次就算不错。微信好友列表越来越长但能聊到“深度”的反而越来越少。按理说通讯工具越发达联系应该越容易但现实是注意力被算法切成了无数个十五秒深度互动被无限稀释。这里真正的问题不是“深度关系有没有价值”而是“深度关系的维护成本太高高到很多人默认放弃”。传统方式下维护关系靠的是记忆、习惯、环境促成。你和一个同学关系好是因为你们每天在同一个教室上课在同一家公司加班。环境一旦消失关系就变成“需要额外努力才能维持”的状态。而人的意志力是最不可靠的资源一旦忙起来第一件被砍掉的事就是“非紧急的社交”。技术能解决的是把维护成本降下来。我们可以把一段关系数字化记录上一次互动是什么时候互动质量如何重要度有多高然后让系统在关系“接近失温”时主动提醒你。这样坚持不再靠“记得”而是靠“系统兜底”。本文要做的就是搭建这样一个最小可用的关系温度监测系统。这个工具适合几类人第一开发者想用代码解决个人社交管理问题第二做用户运营、客户成功、CRM 的人想从“关系数据”角度理解留存和活跃第三单纯对这个辩题感兴趣想看看技术视角能给出什么答案的人。2. 深度关系维护的本质一段需要保活的长连接如果把深度关系类比成网络连接很多工程概念可以直接迁移过来。一段稳定的 TCP 长连接不能建立之后就不管它需要心跳包来告诉对端“我还活着”。如果长时间没有心跳连接会被中间设备回收对端也会超时断开。重建连接可以但重建成本远比维持高要重新握手、重新协商、重新同步状态。人际中的深度关系差不多也是这样。我们可以把关系拆成几个要素节点人。每个联系人是一个节点。链路互动记录。一次聊天、一次线下见面、一次共同完成项目都是一次有效数据传输。信号质量互动深度。闲聊和深夜长谈的意义完全不同。心跳联系频率。稳定的低频联系比偶尔一次高强度联系更能维持连接状态。超时遗忘阈值。超过一定时间不联系关系就会降温最终失效。一个好的关系维护系统要做的事情就是四件记录节点、记录链路、计算关系温度、在超时之前提醒心跳。这里还要提出一个关键判断深度关系不要求高频联系但必须保持可见的反馈和持续的记忆锚点。为什么老同学多年未见还能聊起来因为你们共享了很多“共同经历”这些经历就像持久化存储里的索引只要索引还在重新同步的成本就低。而技术能负责把索引建好把“上次说到某本书、某个项目、某次旅行”这样的上下文存下来。真正的情绪价值仍然需要人来提供。所以我们不是在写一个“自动社交机器人”而是在写一个“关系的运维监控系统”。它不替你聊天不假装热情它只是在关系即将失温时敲一下命令行提醒你这个人的温度降下来了。3. 数据建模与初始化准备要让系统可运行第一步是把关系数据模型设计好。这里不需要复杂的关系型数据库SQLite 足够。它的优点是单文件、零部署、容易备份适合个人工具。核心表有两张person表存联系人节点interaction表存互动链路。先看建表语句。-- schema.sql PRAGMA foreign_keys ON; CREATE TABLE IF NOT EXISTS person ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, group_name TEXT DEFAULT 未分组, importance INTEGER DEFAULT 3 CHECK(importance BETWEEN 1 AND 5), created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS interaction ( id INTEGER PRIMARY KEY AUTOINCREMENT, person_id INTEGER NOT NULL REFERENCES person(id) ON DELETE CASCADE, interact_time TEXT NOT NULL DEFAULT (datetime(now, localtime)), interact_type TEXT NOT NULL, depth_score INTEGER DEFAULT 1 CHECK(depth_score BETWEEN 1 AND 5), note TEXT );person表中的importance字段表示这个人在你生命中的重要度范围从 1 到 5。为什么不直接用“亲密度”这样一个总指标因为亲密度是结果重要度是输入。你和一个重要客户可能关系并不亲密但他对你的事业影响很大这类人不能因为“不亲密”就被忽略。把重要度和互动深度分开后续计算关系温度时才有更合理的权重。interaction表记录每一次互动。interact_type用于标记互动方式depth_score表示这次互动的深度。一次简单的微信问候可能是 1 分一次两小时的语音通话可能是 3 分一次共同旅行或深夜长谈可能是 5 分。之所以记录互动类型和深度是因为“见面聊了十分钟”和“连续聊了两小时”对关系的影响完全不同。环境准备非常简单。项目只需要 Python 3不需要第三方依赖。目录结构建议这样relationship-agent/ ├── relationship_agent.py ├── schema.sql └── relationships.db # 运行时自动生成初始化命令cd relationship-agent python3 relationship_agent.py init如果你的环境同时有多个 Python 版本建议创建虚拟环境python3 -m venv venv source venv/bin/activate python relationship_agent.py init这个工具不依赖第三方库使用 Python 标准库里的sqlite3、argparse、datetime、json、math就足够。版本方面只要 Python 3.8 以上都能正常运行。如果你已经在用 3.10 或 3.11没有任何兼容问题。4. 核心代码实现关系温度计算与提醒逻辑前面的数据模型只是存储层真正有意思的是“关系温度”计算。关系温度的设计思想很简单一段关系的健康度取决于三个因素——重要度、互动深度、距离上次互动的时间。重要度越高基准温度越高互动越深温度恢复得越快时间过得越久温度指数衰减。为什么用指数衰减而不是线性衰减因为人对关系的遗忘不是匀速的。三天不联系和三十天不联系的差别远大于三个月不联系和六个月不联系的差别。指数衰减更贴近“最初遗忘最快后期逐渐平缓”的规律。下面给出完整的relationship_agent.py。代码量不大但把主流程都覆盖了。#!/usr/bin/env python3 # relationship_agent.py import argparse import datetime import json import math import os import sqlite3 import sys DB_PATH os.path.join(os.path.dirname(os.path.abspath(__file__)), relationships.db) SCHEMA_SQL PRAGMA foreign_keys ON; CREATE TABLE IF NOT EXISTS person ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, group_name TEXT DEFAULT 未分组, importance INTEGER DEFAULT 3 CHECK(importance BETWEEN 1 AND 5), created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS interaction ( id INTEGER PRIMARY KEY AUTOINCREMENT, person_id INTEGER NOT NULL REFERENCES person(id) ON DELETE CASCADE, interact_time TEXT NOT NULL DEFAULT (datetime(now, localtime)), interact_type TEXT NOT NULL, depth_score INTEGER DEFAULT 1 CHECK(depth_score BETWEEN 1 AND 5), note TEXT ); INTERACT_TYPES [闲聊, 语音通话, 视频, 线下见面, 礼物, 帮助, 共事, 共同活动] def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def init_db(forceFalse): if force and os.path.exists(DB_PATH): os.remove(DB_PATH) conn get_conn() conn.executescript(SCHEMA_SQL) conn.commit() conn.close() print(数据库初始化完成) def add_person(name, group_name, importance): conn get_conn() try: conn.execute( INSERT INTO person (name, group_name, importance) VALUES (?, ?, ?), (name, group_name, importance), ) conn.commit() print(f已添加联系人{name}) except sqlite3.IntegrityError: print(f联系人已存在{name}, filesys.stderr) sys.exit(1) finally: conn.close() def log_interaction(name, interact_type, depth_score, note): conn get_conn() cur conn.cursor() cur.execute(SELECT id, name FROM person WHERE name ?, (name,)) row cur.fetchone() if row is None: print(f联系人不存在{name}请先添加, filesys.stderr) sys.exit(1) person_id row[id] conn.execute( INSERT INTO interaction (person_id, interact_type, depth_score, note) VALUES (?, ?, ?, ?), (person_id, interact_type, depth_score, note), ) conn.commit() print(f已记录与 {name} 的互动{interact_type}深度 {depth_score}) conn.close() def format_status(row): last_time row[last_time] or 从未互动 return { name: row[name], group: row[group_name], importance: row[importance], last_time: last_time, total_interactions: row[total_interactions], temperature: round(calculate_temperature(row), 2), } def calculate_temperature(row, decay_factor0.01): if row[last_time] is None: days 3650 else: last_dt datetime.datetime.strptime(row[last_time], %Y-%m-%d %H:%M:%S) days max((datetime.datetime.now() - last_dt).days, 0) return row[importance] * math.exp(-decay_factor * days) def get_person_status(name): conn get_conn() cur conn.cursor() cur.execute( SELECT p.id, p.name, p.group_name, p.importance, MAX(i.interact_time) AS last_time, COUNT(i.id) AS total_interactions FROM person p LEFT JOIN interaction i ON p.id i.person_id WHERE p.name ? GROUP BY p.id , (name,), ) row cur.fetchone() conn.close() if row is None: print(f联系人不存在{name}, filesys.stderr) sys.exit(1) return format_status(row) def list_stale(threshold_days30): conn get_conn() cur conn.cursor() cur.execute( SELECT p.id, p.name, p.group_name, p.importance, MAX(i.interact_time) AS last_time, COUNT(i.id) AS total_interactions FROM person p LEFT JOIN interaction i ON p.id i.person_id GROUP BY p.id ) rows cur.fetchall() conn.close() now datetime.datetime.now() stale [] for row in rows: if row[last_time] is None: days threshold_days 1 else: last_dt datetime.datetime.strptime(row[last_time], %Y-%m-%d %H:%M:%S) days (now - last_dt).days if days threshold_days: stale.append(format_status(row)) return stale def main(): parser argparse.ArgumentParser(description关系维护助手) sub parser.add_subparsers(destcommand) init_parser sub.add_parser(init, help初始化数据库) init_parser.add_argument(--force, actionstore_true, help强制重建数据库) add_parser sub.add_parser(add, help添加联系人) add_parser.add_argument(--name, requiredTrue) add_parser.add_argument(--group, default未分组) add_parser.add_argument(--importance, typeint, default3, choicesrange(1, 6)) interact_parser sub.add_parser(interact, help记录互动) interact_parser.add_argument(--person, requiredTrue) interact_parser.add_argument(--type, requiredTrue, choicesINTERACT_TYPES) interact_parser.add_argument(--depth, typeint, default2, choicesrange(1, 6)) interact_parser.add_argument(--note, default) status_parser sub.add_parser(status, help查看联系人状态) status_parser.add_argument(--name, requiredTrue) stale_parser sub.add_parser(stale, help查看需要维护的联系人) stale_parser.add_argument(--threshold-days, typeint, default30) args parser.parse_args() if args.command init: init_db(forceargs.force) elif args.command add: add_person(args.name, args.group, args.importance) elif args.command interact: log_interaction(args.person, args.type, args.depth, args.note) elif args.command status: print(json.dumps(get_person_status(args.name), ensure_asciiFalse, indent2)) elif args.command stale: stale list_stale(args.threshold_days) if not stale: print(当前没有需要维护的联系人关系网络很健康) else: print(f超过 {args.threshold_days} 天未联系建议主动维护) for item in stale: print( f- {item[name]}{item[group]}重要度 {item[importance]} f上次互动 {item[last_time]}温度 {item[temperature]} ) else: parser.print_help() if __name__ __main__: main()代码逻辑可以拆成四部分来看。第一部分是数据库操作。init_db负责初始化表结构add_person和log_interaction负责写入数据。这里用UNIQUE约束保证联系人名字不重复用CHECK约束限制重要度和互动深度在合法范围内。第二部分是状态查询。get_person_status通过LEFT JOIN把联系人和互动记录关联起来用MAX(i.interact_time)取最近一次互动时间用COUNT(i.id)统计互动次数。第三部分是关系温度计算。calculate_temperature使用指数衰减模型温度等于重要度乘以exp(-0.01 * 距今天数)。这个公式不是唯一答案但它足够直观。你可以调高衰减系数让系统更敏感也可以调低让关系更“耐放”。第四部分是过期检测。list_stale扫描所有联系人只要最近一次互动距离今天超过阈值就加入提醒列表。阈值默认 30 天你可以根据自己的社交节奏调整。有些人一个月联系一次正好有些关系可能三个月不联系也不冷这也说明“分类设置阈值”是有必要的。5. 自动化运行用 Cron 把提醒交给机器命令行工具只能在你主动运行的时候工作。要真正发挥价值需要把它挂到系统定时任务里让机器每天帮你检查一遍关系温度。Linux 或 macOS 上最简单的方案是 Cron。下面的配置表示每天早晨 8 点运行一次检查并把输出写入日志# crontab -e 0 8 * * * cd /path/to/relationship-agent /usr/bin/python3 relationship_agent.py stale --threshold-days 30 stale.log 21这里有几个容易踩坑的点。第一Cron 的环境变量和登录 shell 不同python3不一定在默认 PATH 里。最稳妥的方式是使用 Python 解释器的绝对路径。你可以通过which python3查到路径比如/usr/bin/python3或/usr/local/bin/python3。第二脚本中使用了相对路径relationships.db它相对于脚本文件所在目录而不是当前工作目录。所以 cron 命令里先用cd /path/to/relationship-agent切到项目目录再运行脚本。如果不切换可能找不到数据库文件或者在一个意外目录创建新的空数据库。第三建议把输出重定向到日志文件。 stale.log 21会把标准输出和错误输出都追加到日志里。这样如果脚本异常你能第一时间看到报错信息。如果你使用 systemd 而不是 cron也可以写一个 service 和 timer。但从简单角度出发个人工具用 cron 已经足够。自动化之后这个系统的使用闭环就完整了你有空时手动记录一次互动系统每天自动扫描关系温度某段关系超过阈值时你会在日志里看到提醒然后决定要不要去主动联系。6. 运行结果与效果验证下面从零开始演示一遍。先初始化数据库添加一个联系人记录一次互动然后查看状态和过期提醒。python relationship_agent.py init python relationship_agent.py add --name 张三 --group 大学同学 --importance 5 python relationship_agent.py interact --person 张三 --type 语音通话 --depth 4 python relationship_agent.py status --name 张三预期输出类似数据库初始化完成 已添加联系人张三 已记录与 张三 的互动语音通话深度 4 { name: 张三, group: 大学同学, importance: 5, last_time: 实际运行当天的时间, total_interactions: 1, temperature: 4.95 }刚记录完互动时temperature接近重要度的最大值 5。随着时间推移温度会逐渐下降。接着测试过期提醒。假设你把阈值设为 30 天并模拟一个很久没联系的联系人python relationship_agent.py add --name 李四 --group 前同事 --importance 2 python relationship_agent.py stale --threshold-days 30因为李四从未有过互动记录stale命令会把它识别为超期关系输出类似超过 30 天未联系建议主动维护 - 李四前同事重要度 2上次互动 从未互动温度 0.0看到这样的输出说明系统工作正常。如果运行失败第一步先检查有没有执行过init。很多人拿代码直接跑add但数据库表还不存在会报no such table: person。解决方法是先运行初始化命令。第二步检查数据库文件位置。确认relationships.db在脚本同目录下并且有读写权限。如果之前不小心在别的目录运行过脚本可能已经生成了空数据库需要删除或重新初始化。第三步检查 Python 版本。如果代码中使用了f-string或较新的标准库特性Python 3.6 以下版本可能不支持。建议至少使用 Python 3.8。7. 常见问题与排查思路这个工具虽然简单但实际使用中还是会遇到一些常见问题。整理成表格方便对照。问题现象可能原因排查方式解决方案运行 add 提示 no such table: person没有先执行 init查看当前目录是否有 relationships.db先运行python relationship_agent.py init添加联系人提示“联系人已存在”name 字段有 UNIQUE 约束执行status --name查看是否存在不要重复添加直接记录互动温度一直不变互动时间读取失败或格式不匹配用status查看 last_time确认 SQLite 存储的时间格式为%Y-%m-%d %H:%M:%Sstale 列表长期为空阈值设置过大或所有人最近都有互动查看日志和最近互动时间适当降低--threshold-dayscron 运行后没有日志cron 工作目录错误或路径不对手动执行 cron 里的命令看是否报错使用绝对路径并先cd到项目目录提醒时间与本地时区不一致服务器 TZ 环境变量未设置在脚本中打印当前时间在 crontab 中设置TZAsia/Shanghai误删数据库后数据全部丢失没有备份检查日志和备份目录使用 SQLite 文件备份定期复制还有一个容易被忽略的问题depth_score是主观打分不同人对于“深度”的标准不同。为了避免标准漂移建议在项目 README 里写清楚1 分是轻度问候3 分是深入聊天5 分是有实质性共同经历。这样每次记录时参考同一个标准数据才有一致性。8. 最佳实践与工程建议如果你的目标不只是玩一下而是长期用它维护真实关系可以关注下面这些工程化建议。第一隐私保护优先。这个工具存储的是你的社交关系数据属于高度敏感信息。不要把数据库文件放到云盘同步更不要传到公开代码仓库。建议只在本地运行必要时使用 SQLCipher 这类加密 SQLite 方案或者把数据保存在受密码保护的本机目录。第二定期备份。SQLite 是单文件数据库备份很简单直接复制relationships.db文件即可。但要注意如果数据库正在写入时直接复制文件可能产生不一致备份。更稳妥的方式是用 SQLite 的在线备份命令 用Python打造关系温度监测系统：像维护高可用连接一样维护深度关系
最近看到一道很有意思的辩论赛辩题西南政法大学 VS 中国农业大学辩题是“在高度流动的社会里该/不该坚持追求与他人的深度关系”。作为技术人我第一反应不是站队而是想到一个问题如果“深度关系”是一条连接我们是否能像设计高可用系统一样为它设计心跳、超时和重试机制这个类比并不牵强。高度流动的社会里换城市、换公司、换圈子的频率越来越高成年人维护一段深度关系的时间窗口越来越碎片化。很多人不是不想坚持而是“想联系的时候已经忘了”或者“还记得联系方式却不知道如何开口”。这本质上不是态度问题而是关系维护的工程问题。所以本文想做的事很具体从辩题出发把深度关系拆成数据模型和行为模型用 Python 写一个本地关系维护助手跑通“记录联系人—记录互动—计算关系温度—自动提醒”的完整链路。读完你可以直接用它来管理自己的重要关系也可以把同样的思路迁移到用户留存、客户运营甚至社区健康度分析中。1. 这篇文章真正要解决的问题辩论赛讨论“该不该坚持”但真实世界里很多人卡在更前一步不是没有意愿而是不知道从哪一刻开始“维护关系”这个动作已经断了。高度流动的社会把社交关系切得很碎。一个人在北上广深工作三年回到二线城市原来每周见面的同事一年能聚一次就算不错。微信好友列表越来越长但能聊到“深度”的反而越来越少。按理说通讯工具越发达联系应该越容易但现实是注意力被算法切成了无数个十五秒深度互动被无限稀释。这里真正的问题不是“深度关系有没有价值”而是“深度关系的维护成本太高高到很多人默认放弃”。传统方式下维护关系靠的是记忆、习惯、环境促成。你和一个同学关系好是因为你们每天在同一个教室上课在同一家公司加班。环境一旦消失关系就变成“需要额外努力才能维持”的状态。而人的意志力是最不可靠的资源一旦忙起来第一件被砍掉的事就是“非紧急的社交”。技术能解决的是把维护成本降下来。我们可以把一段关系数字化记录上一次互动是什么时候互动质量如何重要度有多高然后让系统在关系“接近失温”时主动提醒你。这样坚持不再靠“记得”而是靠“系统兜底”。本文要做的就是搭建这样一个最小可用的关系温度监测系统。这个工具适合几类人第一开发者想用代码解决个人社交管理问题第二做用户运营、客户成功、CRM 的人想从“关系数据”角度理解留存和活跃第三单纯对这个辩题感兴趣想看看技术视角能给出什么答案的人。2. 深度关系维护的本质一段需要保活的长连接如果把深度关系类比成网络连接很多工程概念可以直接迁移过来。一段稳定的 TCP 长连接不能建立之后就不管它需要心跳包来告诉对端“我还活着”。如果长时间没有心跳连接会被中间设备回收对端也会超时断开。重建连接可以但重建成本远比维持高要重新握手、重新协商、重新同步状态。人际中的深度关系差不多也是这样。我们可以把关系拆成几个要素节点人。每个联系人是一个节点。链路互动记录。一次聊天、一次线下见面、一次共同完成项目都是一次有效数据传输。信号质量互动深度。闲聊和深夜长谈的意义完全不同。心跳联系频率。稳定的低频联系比偶尔一次高强度联系更能维持连接状态。超时遗忘阈值。超过一定时间不联系关系就会降温最终失效。一个好的关系维护系统要做的事情就是四件记录节点、记录链路、计算关系温度、在超时之前提醒心跳。这里还要提出一个关键判断深度关系不要求高频联系但必须保持可见的反馈和持续的记忆锚点。为什么老同学多年未见还能聊起来因为你们共享了很多“共同经历”这些经历就像持久化存储里的索引只要索引还在重新同步的成本就低。而技术能负责把索引建好把“上次说到某本书、某个项目、某次旅行”这样的上下文存下来。真正的情绪价值仍然需要人来提供。所以我们不是在写一个“自动社交机器人”而是在写一个“关系的运维监控系统”。它不替你聊天不假装热情它只是在关系即将失温时敲一下命令行提醒你这个人的温度降下来了。3. 数据建模与初始化准备要让系统可运行第一步是把关系数据模型设计好。这里不需要复杂的关系型数据库SQLite 足够。它的优点是单文件、零部署、容易备份适合个人工具。核心表有两张person表存联系人节点interaction表存互动链路。先看建表语句。-- schema.sql PRAGMA foreign_keys ON; CREATE TABLE IF NOT EXISTS person ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, group_name TEXT DEFAULT 未分组, importance INTEGER DEFAULT 3 CHECK(importance BETWEEN 1 AND 5), created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS interaction ( id INTEGER PRIMARY KEY AUTOINCREMENT, person_id INTEGER NOT NULL REFERENCES person(id) ON DELETE CASCADE, interact_time TEXT NOT NULL DEFAULT (datetime(now, localtime)), interact_type TEXT NOT NULL, depth_score INTEGER DEFAULT 1 CHECK(depth_score BETWEEN 1 AND 5), note TEXT );person表中的importance字段表示这个人在你生命中的重要度范围从 1 到 5。为什么不直接用“亲密度”这样一个总指标因为亲密度是结果重要度是输入。你和一个重要客户可能关系并不亲密但他对你的事业影响很大这类人不能因为“不亲密”就被忽略。把重要度和互动深度分开后续计算关系温度时才有更合理的权重。interaction表记录每一次互动。interact_type用于标记互动方式depth_score表示这次互动的深度。一次简单的微信问候可能是 1 分一次两小时的语音通话可能是 3 分一次共同旅行或深夜长谈可能是 5 分。之所以记录互动类型和深度是因为“见面聊了十分钟”和“连续聊了两小时”对关系的影响完全不同。环境准备非常简单。项目只需要 Python 3不需要第三方依赖。目录结构建议这样relationship-agent/ ├── relationship_agent.py ├── schema.sql └── relationships.db # 运行时自动生成初始化命令cd relationship-agent python3 relationship_agent.py init如果你的环境同时有多个 Python 版本建议创建虚拟环境python3 -m venv venv source venv/bin/activate python relationship_agent.py init这个工具不依赖第三方库使用 Python 标准库里的sqlite3、argparse、datetime、json、math就足够。版本方面只要 Python 3.8 以上都能正常运行。如果你已经在用 3.10 或 3.11没有任何兼容问题。4. 核心代码实现关系温度计算与提醒逻辑前面的数据模型只是存储层真正有意思的是“关系温度”计算。关系温度的设计思想很简单一段关系的健康度取决于三个因素——重要度、互动深度、距离上次互动的时间。重要度越高基准温度越高互动越深温度恢复得越快时间过得越久温度指数衰减。为什么用指数衰减而不是线性衰减因为人对关系的遗忘不是匀速的。三天不联系和三十天不联系的差别远大于三个月不联系和六个月不联系的差别。指数衰减更贴近“最初遗忘最快后期逐渐平缓”的规律。下面给出完整的relationship_agent.py。代码量不大但把主流程都覆盖了。#!/usr/bin/env python3 # relationship_agent.py import argparse import datetime import json import math import os import sqlite3 import sys DB_PATH os.path.join(os.path.dirname(os.path.abspath(__file__)), relationships.db) SCHEMA_SQL PRAGMA foreign_keys ON; CREATE TABLE IF NOT EXISTS person ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, group_name TEXT DEFAULT 未分组, importance INTEGER DEFAULT 3 CHECK(importance BETWEEN 1 AND 5), created_at TEXT NOT NULL DEFAULT (datetime(now, localtime)) ); CREATE TABLE IF NOT EXISTS interaction ( id INTEGER PRIMARY KEY AUTOINCREMENT, person_id INTEGER NOT NULL REFERENCES person(id) ON DELETE CASCADE, interact_time TEXT NOT NULL DEFAULT (datetime(now, localtime)), interact_type TEXT NOT NULL, depth_score INTEGER DEFAULT 1 CHECK(depth_score BETWEEN 1 AND 5), note TEXT ); INTERACT_TYPES [闲聊, 语音通话, 视频, 线下见面, 礼物, 帮助, 共事, 共同活动] def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def init_db(forceFalse): if force and os.path.exists(DB_PATH): os.remove(DB_PATH) conn get_conn() conn.executescript(SCHEMA_SQL) conn.commit() conn.close() print(数据库初始化完成) def add_person(name, group_name, importance): conn get_conn() try: conn.execute( INSERT INTO person (name, group_name, importance) VALUES (?, ?, ?), (name, group_name, importance), ) conn.commit() print(f已添加联系人{name}) except sqlite3.IntegrityError: print(f联系人已存在{name}, filesys.stderr) sys.exit(1) finally: conn.close() def log_interaction(name, interact_type, depth_score, note): conn get_conn() cur conn.cursor() cur.execute(SELECT id, name FROM person WHERE name ?, (name,)) row cur.fetchone() if row is None: print(f联系人不存在{name}请先添加, filesys.stderr) sys.exit(1) person_id row[id] conn.execute( INSERT INTO interaction (person_id, interact_type, depth_score, note) VALUES (?, ?, ?, ?), (person_id, interact_type, depth_score, note), ) conn.commit() print(f已记录与 {name} 的互动{interact_type}深度 {depth_score}) conn.close() def format_status(row): last_time row[last_time] or 从未互动 return { name: row[name], group: row[group_name], importance: row[importance], last_time: last_time, total_interactions: row[total_interactions], temperature: round(calculate_temperature(row), 2), } def calculate_temperature(row, decay_factor0.01): if row[last_time] is None: days 3650 else: last_dt datetime.datetime.strptime(row[last_time], %Y-%m-%d %H:%M:%S) days max((datetime.datetime.now() - last_dt).days, 0) return row[importance] * math.exp(-decay_factor * days) def get_person_status(name): conn get_conn() cur conn.cursor() cur.execute( SELECT p.id, p.name, p.group_name, p.importance, MAX(i.interact_time) AS last_time, COUNT(i.id) AS total_interactions FROM person p LEFT JOIN interaction i ON p.id i.person_id WHERE p.name ? GROUP BY p.id , (name,), ) row cur.fetchone() conn.close() if row is None: print(f联系人不存在{name}, filesys.stderr) sys.exit(1) return format_status(row) def list_stale(threshold_days30): conn get_conn() cur conn.cursor() cur.execute( SELECT p.id, p.name, p.group_name, p.importance, MAX(i.interact_time) AS last_time, COUNT(i.id) AS total_interactions FROM person p LEFT JOIN interaction i ON p.id i.person_id GROUP BY p.id ) rows cur.fetchall() conn.close() now datetime.datetime.now() stale [] for row in rows: if row[last_time] is None: days threshold_days 1 else: last_dt datetime.datetime.strptime(row[last_time], %Y-%m-%d %H:%M:%S) days (now - last_dt).days if days threshold_days: stale.append(format_status(row)) return stale def main(): parser argparse.ArgumentParser(description关系维护助手) sub parser.add_subparsers(destcommand) init_parser sub.add_parser(init, help初始化数据库) init_parser.add_argument(--force, actionstore_true, help强制重建数据库) add_parser sub.add_parser(add, help添加联系人) add_parser.add_argument(--name, requiredTrue) add_parser.add_argument(--group, default未分组) add_parser.add_argument(--importance, typeint, default3, choicesrange(1, 6)) interact_parser sub.add_parser(interact, help记录互动) interact_parser.add_argument(--person, requiredTrue) interact_parser.add_argument(--type, requiredTrue, choicesINTERACT_TYPES) interact_parser.add_argument(--depth, typeint, default2, choicesrange(1, 6)) interact_parser.add_argument(--note, default) status_parser sub.add_parser(status, help查看联系人状态) status_parser.add_argument(--name, requiredTrue) stale_parser sub.add_parser(stale, help查看需要维护的联系人) stale_parser.add_argument(--threshold-days, typeint, default30) args parser.parse_args() if args.command init: init_db(forceargs.force) elif args.command add: add_person(args.name, args.group, args.importance) elif args.command interact: log_interaction(args.person, args.type, args.depth, args.note) elif args.command status: print(json.dumps(get_person_status(args.name), ensure_asciiFalse, indent2)) elif args.command stale: stale list_stale(args.threshold_days) if not stale: print(当前没有需要维护的联系人关系网络很健康) else: print(f超过 {args.threshold_days} 天未联系建议主动维护) for item in stale: print( f- {item[name]}{item[group]}重要度 {item[importance]} f上次互动 {item[last_time]}温度 {item[temperature]} ) else: parser.print_help() if __name__ __main__: main()代码逻辑可以拆成四部分来看。第一部分是数据库操作。init_db负责初始化表结构add_person和log_interaction负责写入数据。这里用UNIQUE约束保证联系人名字不重复用CHECK约束限制重要度和互动深度在合法范围内。第二部分是状态查询。get_person_status通过LEFT JOIN把联系人和互动记录关联起来用MAX(i.interact_time)取最近一次互动时间用COUNT(i.id)统计互动次数。第三部分是关系温度计算。calculate_temperature使用指数衰减模型温度等于重要度乘以exp(-0.01 * 距今天数)。这个公式不是唯一答案但它足够直观。你可以调高衰减系数让系统更敏感也可以调低让关系更“耐放”。第四部分是过期检测。list_stale扫描所有联系人只要最近一次互动距离今天超过阈值就加入提醒列表。阈值默认 30 天你可以根据自己的社交节奏调整。有些人一个月联系一次正好有些关系可能三个月不联系也不冷这也说明“分类设置阈值”是有必要的。5. 自动化运行用 Cron 把提醒交给机器命令行工具只能在你主动运行的时候工作。要真正发挥价值需要把它挂到系统定时任务里让机器每天帮你检查一遍关系温度。Linux 或 macOS 上最简单的方案是 Cron。下面的配置表示每天早晨 8 点运行一次检查并把输出写入日志# crontab -e 0 8 * * * cd /path/to/relationship-agent /usr/bin/python3 relationship_agent.py stale --threshold-days 30 stale.log 21这里有几个容易踩坑的点。第一Cron 的环境变量和登录 shell 不同python3不一定在默认 PATH 里。最稳妥的方式是使用 Python 解释器的绝对路径。你可以通过which python3查到路径比如/usr/bin/python3或/usr/local/bin/python3。第二脚本中使用了相对路径relationships.db它相对于脚本文件所在目录而不是当前工作目录。所以 cron 命令里先用cd /path/to/relationship-agent切到项目目录再运行脚本。如果不切换可能找不到数据库文件或者在一个意外目录创建新的空数据库。第三建议把输出重定向到日志文件。 stale.log 21会把标准输出和错误输出都追加到日志里。这样如果脚本异常你能第一时间看到报错信息。如果你使用 systemd 而不是 cron也可以写一个 service 和 timer。但从简单角度出发个人工具用 cron 已经足够。自动化之后这个系统的使用闭环就完整了你有空时手动记录一次互动系统每天自动扫描关系温度某段关系超过阈值时你会在日志里看到提醒然后决定要不要去主动联系。6. 运行结果与效果验证下面从零开始演示一遍。先初始化数据库添加一个联系人记录一次互动然后查看状态和过期提醒。python relationship_agent.py init python relationship_agent.py add --name 张三 --group 大学同学 --importance 5 python relationship_agent.py interact --person 张三 --type 语音通话 --depth 4 python relationship_agent.py status --name 张三预期输出类似数据库初始化完成 已添加联系人张三 已记录与 张三 的互动语音通话深度 4 { name: 张三, group: 大学同学, importance: 5, last_time: 实际运行当天的时间, total_interactions: 1, temperature: 4.95 }刚记录完互动时temperature接近重要度的最大值 5。随着时间推移温度会逐渐下降。接着测试过期提醒。假设你把阈值设为 30 天并模拟一个很久没联系的联系人python relationship_agent.py add --name 李四 --group 前同事 --importance 2 python relationship_agent.py stale --threshold-days 30因为李四从未有过互动记录stale命令会把它识别为超期关系输出类似超过 30 天未联系建议主动维护 - 李四前同事重要度 2上次互动 从未互动温度 0.0看到这样的输出说明系统工作正常。如果运行失败第一步先检查有没有执行过init。很多人拿代码直接跑add但数据库表还不存在会报no such table: person。解决方法是先运行初始化命令。第二步检查数据库文件位置。确认relationships.db在脚本同目录下并且有读写权限。如果之前不小心在别的目录运行过脚本可能已经生成了空数据库需要删除或重新初始化。第三步检查 Python 版本。如果代码中使用了f-string或较新的标准库特性Python 3.6 以下版本可能不支持。建议至少使用 Python 3.8。7. 常见问题与排查思路这个工具虽然简单但实际使用中还是会遇到一些常见问题。整理成表格方便对照。问题现象可能原因排查方式解决方案运行 add 提示 no such table: person没有先执行 init查看当前目录是否有 relationships.db先运行python relationship_agent.py init添加联系人提示“联系人已存在”name 字段有 UNIQUE 约束执行status --name查看是否存在不要重复添加直接记录互动温度一直不变互动时间读取失败或格式不匹配用status查看 last_time确认 SQLite 存储的时间格式为%Y-%m-%d %H:%M:%Sstale 列表长期为空阈值设置过大或所有人最近都有互动查看日志和最近互动时间适当降低--threshold-dayscron 运行后没有日志cron 工作目录错误或路径不对手动执行 cron 里的命令看是否报错使用绝对路径并先cd到项目目录提醒时间与本地时区不一致服务器 TZ 环境变量未设置在脚本中打印当前时间在 crontab 中设置TZAsia/Shanghai误删数据库后数据全部丢失没有备份检查日志和备份目录使用 SQLite 文件备份定期复制还有一个容易被忽略的问题depth_score是主观打分不同人对于“深度”的标准不同。为了避免标准漂移建议在项目 README 里写清楚1 分是轻度问候3 分是深入聊天5 分是有实质性共同经历。这样每次记录时参考同一个标准数据才有一致性。8. 最佳实践与工程建议如果你的目标不只是玩一下而是长期用它维护真实关系可以关注下面这些工程化建议。第一隐私保护优先。这个工具存储的是你的社交关系数据属于高度敏感信息。不要把数据库文件放到云盘同步更不要传到公开代码仓库。建议只在本地运行必要时使用 SQLCipher 这类加密 SQLite 方案或者把数据保存在受密码保护的本机目录。第二定期备份。SQLite 是单文件数据库备份很简单直接复制relationships.db文件即可。但要注意如果数据库正在写入时直接复制文件可能产生不一致备份。更稳妥的方式是用 SQLite 的在线备份命令