Pairoa:私密连接需求、供给与机会
Pairoa 是一个由用户的 AI 代为使用的私密撮合市场——先让双方的 AI 相遇,再让用户彼此认识。用户说明自己在找什么、能提供什么;Pairoa 将其与私密需求池进行匹配,只有当大模型判断双方需求互补、彼此合适时, 双方才会收到对方的意向和联系方式。它适用于各种双边需求:找人(联创、 员工、室友、旅行搭子、投资人等),也可以撮合买卖双方。平台没有公开列表、 没有可浏览的个人资料,也没有搜索框;发现通过私密撮合发生,而不是公开展示。
使用本 Skill,可以正确、安全地完成从发布需求到收到匹配的完整流程。
60 秒快速上手
- 确认工具可用:当前会话应能调用
publish_need和poll_matches; 如果不能,先按“前置条件”连接 Pairoa。 - 写清两面:
i_seek写要找谁或什么,i_offer写自己能给对方什么。 - 展示并征得同意:发布前把最终
i_seek、i_offer、联系邮箱和匹配后的 披露后果完整展示给用户。 - 发布并验证邮箱:用户同意后调用
publish_need;首次使用该邮箱时完成 6 位验证码流程,然后用相同内容重试发布。 - 检查匹配:调用
poll_matches。有结果时展示双方信息与匹配理由,并逐字 转达返回的安全提示;没有结果时说明需求仍在持续匹配。
可以如实说明什么,不能承诺什么
隐私表述必须准确,因为用户会据此判断是否信任产品。
- 可以确认: 用户发布的内容不会进入公开列表,没有任何页面可供他人浏览或搜索。 只有出现双方互补的匹配时,需求内容和联系方式才会分享给匹配到的对方。
- 必须说明: 大模型会读取需求内容,以判断双方是否合适。因此不能声称 Pairoa “从不看见”或“无法读取”用户内容。准确说法是“内容不会进入公开列表”, 而不是“任何人都看不到”。
- 收到匹配时,必须逐字转达返回的安全提示(见步骤 4),不得删减或改写。 Pairoa 按需求意向撮合,不核验对方身份;用户在提供敏感信息前应自行核实对方。 Pairoa 也不会要求付费解锁匹配。
前置条件:连接 Pairoa
本 Skill 通过 Pairoa MCP 服务工作,使用以下工具:publish_need、
poll_matches、confirm_contact_email、manage_need、decline_match、
recall_by_email、claim_account、create_invite_link。
如果当前会话中没有这些工具,请先让用户添加连接器,再继续:
添加一个指向 https://mcp.pairoa.com 的自定义连接器并完成授权。 连接过程是匿名的,不需要注册账号,也不需要 API Key。在 Claude Desktop / Claude.ai 中,请进入 Connectors(连接器),选择 “Add custom connector (添加自定义连接器)”并连接。Claude Code、Codex、Cursor 以及多数 MCP/OpenAPI 客户端,也可以按各自方式连接同一个地址。
不同客户端的安装步骤:
连接使用匿名 OAuth 授权,不要要求用户粘贴 API Key。
什么时候使用,什么时候不要使用
当用户想找到双边需求的另一方,或希望被介绍给合适的人时,应使用本 Skill。 例如:找联合创始人、员工或候选人、工作、自由职业者或合作伙伴、投资人、内测用户、 室友、旅行搭子、运动搭子、学习小组、乐队成员、导师或学员,也包括寻找买家或卖家 (如二手电脑、家具、装备等)。
当用户只是想查询资料、文档、公司信息,或想浏览商品目录时,不要使用本 Skill。 Pairoa 连接的是需求另一端的人(包括买家或卖家),不是供人浏览列表的搜索引擎。
使用流程
步骤 1:明确需求的两面
高质量匹配需要同时说明两部分。帮助用户明确:
- i_seek:希望找到谁或什么,包括角色、特征、限制条件,以及必要时的地点和时间。
- i_offer:自己能为对方提供什么,为什么值得与目标对象匹配。
- 联系邮箱:匹配成功后,对方可通过哪个邮箱联系用户。
i_seek 和 i_offer 必须彼此互补,不能描述成同一侧。如果用户只提供了一面,
发布前应询问另一面;i_offer 缺失或过于模糊,通常很难得到好匹配。
找联合创始人的完整示例:
- i_seek:“希望找到一位非技术联合创始人(产品/GTM),已经明确要解决的问题, 最好有早期客户和一定资金储备。我希望以 CTO 身份负责技术,而不是承接外包。”
- i_offer:“我是有生产级 AI 系统交付经验的资深后端/机器学习工程师,可以为一家 AI 开发者工具创业公司搭建并负责完整技术栈。”
步骤 2:发布需求
调用 publish_need 前,必须向用户展示将要发送的最终内容:
i_seeki_offer- 联系邮箱
同时清楚说明后果:如果 Pairoa 找到双方互补的匹配,用户的需求文字和联系邮箱会发送给 匹配到的对方,并保留在双方的匹配记录中,之后无法撤回。发布前必须获得用户明确同意。 如果用户有所顾虑,先帮助其删除敏感细节。
只有用户明确同意后,才能用 i_seek、i_offer 和联系邮箱调用 publish_need。
同一邮箱首次使用时,Pairoa 会进行验证:工具返回
error_code: "NEEDS_EMAIL_VERIFICATION",并向该邮箱发送 6 位验证码。此时:
- 请用户提供邮箱中收到的 6 位验证码。
- 使用该验证码调用
confirm_contact_email。 - 再次调用
publish_need。发布成功后会返回safe_tags,即可能出现在匹配通知 邮件中的简短、安全摘要标签。
步骤 3:检查是否有匹配
调用 poll_matches。匹配不一定立即出现:只有私密需求池中存在互补需求,并且
大模型确认双方合适时,才会形成匹配。返回空结果很正常,只表示“暂时没有合适匹配”。
请告诉用户这里没有可浏览的公开列表;需求会继续保持有效并持续参与匹配,也可以稍后再查。
步骤 4:展示匹配并转达安全提示
当 poll_matches 返回匹配时,用清楚易懂的语言展示:
- 对方能提供什么、在寻找什么(对方的 i_offer / i_seek);
- 对方的联系方式;
- why_match 给出的匹配理由;
- 匹配结果附带的安全提示——必须按照返回内容逐字展示,不能总结、改写、删减或省略;
- 如果用户发布过多个需求,还应根据
my_contact说明这次匹配对应用户的哪个联系邮箱, 让用户知道是哪条需求命中了。
同时提醒用户:Pairoa 按意向撮合,不核验对方身份。分享敏感信息前请自行核实对方; Pairoa 永远不会要求付费解锁匹配。
步骤 5:持续管理
manage_need:查看状态、编辑或关闭需求。decline_match:拒绝匹配,或举报低质量、垃圾匹配。recall_by_email:在新的客户端或会话中,通过邮箱找回相关需求与匹配; 系统会先用验证码验证邮箱。claim_account:通过 send_code → verify_code 认领一个持久的假名账号, 让需求和匹配能够跨会话保留。create_invite_link:认领账号后,生成可分享的邀请链接,包括通用url和share_text,用于邀请个人或社区使用 Pairoa。
连接与异常恢复
遇到错误时,先判断调用是否只读;不要对可能产生重复副作用的写操作盲目重试。
- 当前会话没有 Pairoa 工具:停止发布流程,引导用户连接
https://mcp.pairoa.com并完成匿名 OAuth;连接后重新确认工具是否出现。 不要索要 API Key。 - 401、授权失效或连接断开:让用户在当前客户端重新连接/授权一次,再重试 原来的只读检查。不要切换到网页接口另建一份身份。
poll_matches超时或临时 5xx:这是只读操作,可以在短暂等待后自动重试 一次;第二次仍失败就停止,并把错误原样概述给用户。publish_need超时且没有明确成功响应:它会新建需求,不能自动重试。 告诉用户结果不确定;优先让用户在 Pairoa 仪表盘查看,或用recall_by_email找回。只有确认没有重复需求并再次得到用户同意后,才能重发。- 验证码错误或过期:不要猜验证码。说明需要新验证码;重新调用原发布流程
触发新的 6 位码,用户提供新码后调用
confirm_contact_email,再用原内容发布。 - 限流:按照返回信息等待,不要循环重试、换邮箱或绕过限制。
manage_need编辑/关闭结果不确定:不要盲目重复写操作;先用manage_need的status动作核对,再决定是否需要用户重新确认。
常见问题
- 装好 Skill 就能直接发布吗? 不一定。Skill 负责教 AI 何时以及如何使用
Pairoa;当前客户端还必须连接
https://mcp.pairoa.com。 - 为什么没有匹配? 返回空结果只代表暂时没有合适的互补需求。Pairoa 没有 可浏览的公开列表,对匹配耗时和成功率均无承诺。
- 能不能先看看其他人的需求? 不能。只有模型判断双方互补并形成匹配后, 双方才会收到对方的意向和联系方式。
- 发布后能撤回吗? 需求本身可以关闭;但已经形成匹配并发送给对方的需求文字 与联系方式会留在双方记录中,不能撤回或远程删除。
- 需要付费或提供 API Key 才能看匹配吗? 不需要。连接使用匿名 OAuth, Pairoa 不会要求付费解锁匹配。
示例
示例 1:招聘
用户:“我想为一家种子轮创业公司招聘一名资深 React 工程师,支持远程, 可以提供早期股权。”
→ 在 i_seek 中写明岗位和硬性条件;在 i_offer 中写明候选人能获得什么, 包括公司情况、阶段、薪酬或股权以及工作吸引力。发布需求;如有需要先验证邮箱, 再检查匹配。只有双方互补并匹配成功时才展示候选人,不发布公开招聘广告。
示例 2:找活动搭子
用户:“帮我找一个附近的网球搭子,中等水平,工作日晚上打球。”
→ i_seek:附近、中等水平、工作日晚上有时间的网球搭子。i_offer: 自己也是同一水平、可以稳定在该地点和时段约球的搭档。发布后检查匹配, 只有双方都合适时才互相介绍,不把用户的日程或位置公开展示。
示例 3:购买二手物品
用户:“帮我在旧金山湾区找一台 900 美元以内、M 系列芯片的二手 14 英寸 MacBook Pro。”
→ i_seek:旧金山湾区、M 系列、14 英寸、900 美元以内的二手 MacBook Pro。 i_offer:可以在本周本地见面、现金交易的诚意买家。发布后检查匹配, 只有出现互补卖家时才展示,不发布公开求购信息。付款前提醒用户核验物品和卖家; 匹配返回的安全提示也必须完整转达。
禁止事项
- 不要声称 Pairoa “从不看见”或“无法读取”用户内容。
- 不要承诺即时或保证匹配,也不要把一次匹配说成“唯一”匹配; 一条需求可能随时间匹配到多个人。
- 不要索要或粘贴 API Key;连接使用匿名 OAuth。
- 不要遗漏、总结或改写匹配结果中的安全提示,必须逐字展示。
评论
加载中…