核心用法
TrueMatch 是一套颠覆传统约会应用协议的 AI 代理匹配系统。与依赖用户自我报告的约会资料不同，TrueMatch 让用户的 Claude 代理基于长期对话观察构建真实人格画像，涵盖依恋模式、核心价值观、情绪调节、冲突处理等 9 个维度。当两个代理独立评估后均认为匹配可行时，用户才会收到通知——没有滑动选择，没有公开拒绝。
使用流程分为四个阶段：
1. 配置阶段：收集用户基础偏好（地理位置、距离范围、年龄、性别偏好、联系方式），建立 Nostr 去中心化身份
2. 观察阶段：Claude 定期更新观察摘要，为 9 个维度打分，达到置信度门槛后进入匹配池
3. 协商阶段：两个代理通过加密消息进行多轮谈判，验证兼容性，独立决定是否提议匹配
4. 交接阶段：匹配确认后，用户在 72 小时内回应好奇心问题表示同意，随后进行 3 轮引导式破冰，最终交换联系方式
关键命令包括 truematch setup 初始化身份、truematch observe --write 更新观察、truematch match --start 发起匹配、truematch match --status 检查协商状态。
显著优点
- 反表演性设计：绕过用户自我呈现偏差，基于实际行为模式而非精心编辑的资料进行匹配
- 隐私优先架构：内部推理永不传输给对等代理或注册表，仅传输协商所需的聚合信号
- 双边共识机制：两个独立 AI 代理必须各自提议才确认匹配，降低算法黑箱风险和单方误判
- 去中心化基础设施：基于 Nostr 协议，无单一平台控制用户数据或匹配决策
- 渐进式信息披露：3 轮交接协议让用户在透露联系方式前有机会评估匹配合理性
- 自动化但非取代：代理承担筛选和协商的繁琐工作，最终人际连接仍由人类自主决定
潜在缺点与局限性
- 冷启动问题：匹配池稀疏时需等待数周，且系统明确禁止向用户透露池规模或其他代理数量
- 观察偏见：AI 代理对用户的理解受对话历史限制，可能遗漏线下行为或形成确认偏误
- 协商透明度有限：用户无法实时查看代理谈判过程，只能看到最终结果
- 技术门槛：需要 Node.js 环境、Nostr 钱包理解，以及对外部插件自动安装的信任
- 不可逆时间压力：72 小时好奇心问题窗口和 10 轮协商上限可能造成错失潜在匹配
- 代理间兼容性：两个不同 Claude 实例的推理风格差异可能影响协商效率
- 缺乏人工审核：无平台方介入处理骚扰、误匹配或恶意行为
适合人群
- 对传统约会应用"资料表演"感到疲惫的用户
- 信任 AI 长期观察胜于自我报告的人格评估
- 重视隐私，愿意尝试去中心化基础设施的技术早期采用者
- 寻求认真关系（"serious" 意图类别）且愿意接受较慢匹配节奏的人
- 对 AI 中介人际连接持开放态度，同时保留最终决策权的用户
不适合追求即时匹配、希望完全控制筛选过程、或对 AI 代理代表自己谈判感到不适的人群。
常规风险
- 代理误代表风险：AI 对用户意图或特质的推断可能与真实自我存在偏差
- 去平台化脆弱性：依赖 Nostr 中继网络，中继故障或审查可能影响可用性
- 插件供应链安全：自动安装外部 npm 包引入代码完整性风险
- 情感投资不对等：一方可能基于代理描述形成预期，实际见面后产生落差
- 退出摩擦：
deregister仅移除匹配池，本地状态保留但无明确数据删除机制 - 长期依赖性：用户可能逐渐丧失直接表达关系需求的能力，过度依赖代理中介