管理个人人脉的 AI 智能体

问题

有用的信息会出现在普通的谈话中：某人正在做什么、需要什么、能提供什么。随着我认识的人越来越多，我渐渐记不清这些信息了。

通讯录应用保存的是姓名和电话号码。它们回答不了“谁能帮上这个忙？”或“我们上次聊了什么？”这样的问题。

发展历程

第一个版本诞生于 2026 年 8 月，里面有用于录入人员、需求和技能的表单。AI 会把一条笔记整理成一份修改建议，经我审核后才会保存任何内容。

我在这款应用真实的数据结构（schema）上测试了多个 AI 模型。有一个模型在生成结构化回答时屡屡超时，所以我换了另一个模型。2026 年 9 月，我把所有 AI 调用都迁移到了 Claude，并经由我的私有网关发出。

每一类新请求都需要各自的提示词、schema、解析器和界面。所以在 9 月中旬，我把助手重建成一个会使用工具的智能体。现在，一个聊天会话就能处理笔记、提问和更正。

一条消息的处理流程

1. 消息 我输入或口述一条关于某次谈话的笔记，或者提一个问题。
2. Claude 规划 Claude 在我的网关上决定下一步调用哪个工具。一开始，它手上没有任何已保存的记录。
3. 网关检查 网关按照对应的 JSON Schema 检查每次工具调用，然后把它发送到手机。
4. 手机运行工具 应用再次检查这次调用，在手机的数据库上运行它，只把结果发回去。联系方式从不离开手机。
5. 带 Undo 的回复 回复会列出每一项更改，点一下 Undo 就能全部撤销。删除与合并要等我点按后才执行。

• 隐私数据库留在手机上，备份会先加密
• 语音只要条件允许，语音都在手机上识别
• 反馈任何回答都可以用固定的标签来报告问题

截图来自一部存有虚构人物的测试手机。

• 一条关于新认识的人的笔记：回复列出每项已保存的更改，并附有一个 Undo 按钮
• 一个找不到合适人选的问题：回答如实说明这一点，并解释原因
• Needs 标签页：人脉中的人正在寻找什么

设计决策

• 规则由手机执行。每次工具调用都要经过两次检查：先由网关按照它的 schema 检查，再由应用检查。应用会确认记录存在、文本不过长、没有重复，并且没有日期落在未来。被拒绝的调用不会保存任何内容，模型会收到一条它能读懂并据此修正的错误信息。
• 灵活，但可撤销。起初，AI 的每项更改都要等我审核。后来我转而选择了灵活性：现在，新增和编辑会立即保存。每条回复都会保留每一行更改前后的副本，所以点一下就能撤销整条回复。如果我在那之后又编辑过这一行，Undo 就会拒绝撤销。
• 删除一律等待确认。删除一个人、一条笔记或一条记录，或者合并两个人，都只在我点按对应的卡片后才会执行。
• 已保存的文本是数据，不是指令。提示词要求模型把已保存的笔记和之前的消息当作数据，绝不当作指令。
• 回答以已保存的记录为依据。当证据陈旧或不足时，助手必须说明。它绝不能仅仅因为一条旧笔记提到某项技能，就暗示某人愿意帮忙。
• 从设计上保护隐私。这款应用没有账户、没有数据分析，也不导入通讯录。备份会先在手机上加密，再发送到一个私有 GitHub 仓库；如果目标是公开仓库，应用会拒绝备份。

发现并修复错误

每个回答都有一个 Report a problem 按钮，报告时可以选择固定的标签，例如找错了人、漏掉了内容或记录类型错误。一份报告会保存消息、回答、已保存的内容，以及按顺序排列的每一次工具调用，但不包含联系方式。

报告随加密备份一起传输。在我的电脑上，一个脚本只解密这些报告。我修复问题所在，再在一部存有虚构人物的测试手机上检验修复效果。

例如，报告显示学习和志愿活动被保存成了工作经历。一条测试笔记曾生成四条工作经历。修复之后，它只生成一条工作经历，其余内容归入了教育经历和背景信息。

我也会衡量速度。我让一次工具调用就能同时保存一条笔记及其相关信息，于是一次涉及两个人的更新从约 23 秒缩短到了约 12 秒。

• Report a problem：固定的标签让问题易于统计和归类

状态

我用这款应用管理自己的人脉，它会通过已签名的 GitHub Releases 自动更新。代码、README 和隐私说明都已在 GitHub 上公开。

截图来自一部存有虚构人物的测试手机。本页面没有出现任何真实的联系人。