从凌晨灵感到发布：一个 AI 可读的人脉图谱 Skill 开发全记录

背景

凌晨，突然意识到一个问题：认识的所有 OI 圈朋友、初中高中同学，他们的信息全散落在各个软件里。大部分人不记得手机号或者没有加 QQ 微信，甚至不知道真名。社交软件的备注只能写几个字，塞不下这个人和我关系多好，在什么关键时刻能帮我什么。

更关键的是，AI 读不到这些信息。当对话中提到「ICPC 打星」时，它不会自动想起某位教练可以帮我争取的名额；提到「北京面基」时，它不知道我有三个朋友在北京。

我需要一个 AI 可读的通讯录。不是存电话号的那种——是存「关系网络」的那种。

开发过程

1. 数据模型设计

让 AI 完成了数据模型设计，核心字段围绕一个目的：让 AI 认识我的朋友，并在有实际需求的时候想到对应的人或许可以帮忙。

nickname: ""       # 怎么称呼（主键）
platforms:         # QQ / 微信 / B站 / 洛谷 / CF
identity: ""       # 学校 / 年级 / 专业 / 角色
context: ""        # 怎么认识的
strength: ""       # 关系强度
help_areas: []     # 可帮事项（AI 联想核心）
trigger_tags: []   # 触发标签（wiki-link 格式）
notes: ""          # 关系边界、注意事项

和传统通讯录的区别：传统通讯录只存「姓名 + 电话」，这里每个联系人是一份结构化的社交画像，标签是机器可解析的触发词。

2. 独立 Obsidian Vault 架构

决定把 vault 放在独立目录，与博客完全隔离。原因很实际：联系人数据含平台 ID、个人背景等敏感信息，混在博客里万一误发出去就麻烦了。

目录结构经过两次迭代：

~/people/
├── README.md          # 使用约定与设计决策
├── INDEX.md           # AI 优先读的速查索引
├── .trash/            # 安全归档（不用 rm）
├── contacts/          # 每人一个 .md
├── templates/
│   └── contact.md
└── tags/
    ├── school/        # 学校标签
    ├── field/         # 专业方向标签
    └── city/          # 城市标签

INDEX.md 是 AI 的入口——里面有联系人总览表 + 三层标签导航表，AI 匹配时先查这里。

3. 联系人批量录入

逐条从聊天记录中提取信息，一口气录入了一批联系人，覆盖竞赛圈前辈、学弟、同学、老师等多个圈层。

录入过程中有一个原则被明确下来：主要录入「关系不深但潜在高价值」的人。很熟的人都在脑袋里，知识库的核心价值是 AI 帮你记住那些半熟人。对于关系边界明确的人，备注里直接写「只能问简单问题，不能欠人情」。

4. 标签体系的三次重构

这是整个构建过程中迭代最多次的部分。

第一版：组合标签。 把学校和专业方向拼在一起，如「A 大学数学」「B 大学计算机」。建完后跑 Obsidian 图谱，发现标签之间全连成了大杂烩——两个标签因为共享一个联系人就被强制关联，两个数学专业的朋友反而没有共同标签，图谱毫无结构美感。

第二版：两层原子化。 拆成 tags/school/ 和 tags/field/，不要组合。旧文件移入 .trash/。

第三版：加城市层。 另开 tags/city/。最终三层体系：

层	目录	边规则
学校	tags/school/	学校 ↔ 城市（双向结构边）
方向	tags/field/	同体系可连（如 OI ↔ ICPC）
城市	tags/city/	同区域相邻城市可连

图谱净化是关键一步。 两个标签仅因共享联系人而相关的边是「无用边」，应该删除。比如「兰州大学」和「大学生数学竞赛 CMC」不该直接连——走刘适禛作为桥梁才对。脚本跑完后删了大量冗余边，最终结构边只保留学校↔城市、同体系方向、相邻城市，图谱从一团乱麻变成了清晰的层级结构。

5. 图谱审计脚本（audit_graph.py）

写了一个 Python 脚本来做自动化审计，因为手动检查数百条 wiki-link 太容易出错，让 Agent 查也是这样。

脚本做了五件事：

Wiki-link 解析：正则匹配 [[目标|别名]]、[[目标#锚点]] 等四种格式
断链检测：所有 [[...]] 目标是否都有对应文件
孤立节点发现：没有标签的联系人 / 没有联系人的标签
冗余边识别：标签对仅通过联系人相连的，标记为冗余候选
圈层分析：每个联系人输出 学校层 + 方向层 + 城市层 的综合画像

6. 从个人工具到可发布的 Skill

录完联系人后，回头看这个过程——从零建 vault、设计标签体系、图谱净化、写审计脚本——是一套完整的、可复用的方法论。于是做了三件事：

脱敏：把所有个人标识替换为通用占位符，只留结构和流程。

打包为 Skill：核心方法论文档（SKILL.md）+ 两个模板资产（联系人模板、索引模板）+ 虚构人物的完整 onboarding 示例 + 审计脚本。通过官方打包脚本验证。

安全审计发布：推送 GitHub 后，用安全审查工具做了完整审计。结论 Benign——无远程下载、无自动执行、无凭证泄露。顺便试用了一下 WorkBuddy 的智能体邮箱功能，直接把打包好的 zip 作为附件发给了一个初中同学——从打包到发送全程不用离开对话界面，比手动开网页邮箱快多了。

已发布到 SkillHub 市场：relationship-graph

7. 最终 Skill 结构

relationship-graph/
├── CLAUDE.md                      # Claude Code 工作指南
├── README.md                      # 快速开始
├── SKILL.md                       # 核心方法论（设计原则+数据模型+工作流+审计）
├── assets/
│   ├── contact-template.md        # 联系人录入模板
│   ├── INDEX-template.md          # 索引导航骨架
│   └── onboarding-example.md      # 虚构人物完整 walkthrough
└── scripts/
    └── audit_graph.py             # 图谱完整性审计脚本

关键决策

独立 vault，不混博客：联系人含敏感信息，隔离是底线
半熟人优先录入：很熟的人在脑子里，AI 帮我们记住的是「目前关系不深但潜在高价值」的人
三层原子标签 + 联系人桥接：标签不搞组合，不同圈层的连接通过联系人节点自然形成
图谱净化：人是桥，标签不过度互联：删除仅共享联系人而存在的标签边，让图谱从大杂烩变成有结构的网络
冲突先问，不猜：疑似重复、信息矛盾时不自动合并/覆写，先展示给用户确认
审计脚本不是摆设：数百条 wiki-link 的手动审计不可靠，一个脚本跑完比肉眼准

下一步

收集实际使用反馈：标签粒度够不够？INDEX 表在大规模时怎么维护？
规模边界分析：一百个联系人时 INDEX.md 还读得动吗？需要上数据库吗？

资源链接

如果你也想建立自己的关系图谱，可以直接在SkillHub安装这个Skill，按模板录入即可。当然，这个项目在数据组织等方面还存在很多可以改进的地方，欢迎开发者朋友在 GitHub 进行贡献。

GitHub：github.com/ttzc/relationship-graph
SkillHub：skillhub.cn/skills/user_e267c873/relationship-graph