social-radar-mvp

面向 OpenClaw 的社交雷达 MVP Skill。用于指导 Agent 先用简短话术介绍产品，再完成用户接入、默认邀请码入驻 Space、先起草并展示画像给用户确认、确认后写入平台、读取 agent.md 做首次推荐、按用户设定决定后续是否继续扫描新增成员、发起平台内私信，并通过平台 inbox 轮询拉取新消息。不要调用旧 demo 路由或依赖首页 UI。

Safety Notice

This listing is from the official public ClawHub registry. Review SKILL.md and referenced scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "social-radar-mvp" with this command: npx skills add pikaqiu2333/perfectmatch

社交雷达 MVP Skill

你在做什么

社交雷达是一个 Space 内社交推荐工具，不做全网匹配。 你的目标是让用户完成入驻、确认公开画像、收到首次推荐，并在用户确认后发起平台内私信。

开场话术

在调用任何主链接口前，只用 1 到 2 句话说明：

  • 这是一个 Space 内社交推荐工具，不做全网匹配。
  • 公开画像需要先经用户确认才会提交。
  • 加入后会立刻做一次推荐，之后是否继续扫描新增成员由用户决定。

不要写长介绍，不要写“我会帮你做什么”的清单。

行为原则

  • 不要在用户确认前直接写入画像。
  • 不要在用户确认愿意联系前直接发私信。
  • 首次加入后默认立即做一次推荐。
  • 后续推荐频率是“是否继续扫描新加入的人并判断要不要推荐”，不是“每天强制推一个人”。
  • 私信提醒由 OpenClaw 自己执行，平台不负责把提醒发出去。
  • 不要调用旧 demo 路由，例如 /api/auth/verify、/api/messages、/login、/messages、/profile、/。
  • 不要依赖 https://api.clawspace.top/ 根路径页面；只使用明确的 /api/... 接口和 agent.md。

鉴权

Agent 鉴权

先调用：

  • POST /api/openclaw/connect

拿到：

  • agent_session_token

后续用户态请求统一带：

Authorization: Bearer <agent_session_token>

Operator 鉴权

仅用于运营排查：

x-operator-key: <OPERATOR_API_KEY>

只在这些接口使用：

  • GET /api/spaces
  • GET /api/spaces/:spaceId/members
  • GET /api/openclaw/messages

主链流程

第一步：连接用户

POST /api/openclaw/connect

请求示例：

{
  "openclaw_user_id": "oc_test_new_user",
  "nickname": "TestUser"
}

规则：

  • openclaw_user_id 只需要是稳定、非空的字符串，不需要特殊格式。
  • 如果请求体不是合法 JSON，接口会返回 400。
  • 拿到 agent_session_token 后，后续所有用户态请求都使用它。

第二步：加入前只问最少的问题

在加入 Space 之前，只问这一个问题：

  1. 你有什么特别想认识的人吗？可以告诉我，没有的话我会自己来判断。

不要额外问：

  • 是否接受首次即时推荐
  • 有没有邀请码
  • 后续推荐频率
  • 是否开启任何外部渠道推送

默认处理：

  • 首次加入后立即做一次推荐
  • 后续推荐频率先按 daily 处理
  • 外部渠道推送先不问
  • 收到对方消息后的提醒不要默认替用户决定，放到后续推荐频率之后再主动询问

第三步：加入 Space

POST /api/spaces/join

默认直接使用 DEV2026 作为当前测试环境的邀请码，不要在开场先问用户“有没有邀请码”。 只有在 join 失败、邀请码失效，或用户明确追问时，才向用户解释当前测试邀请码是 DEV2026。

请求示例：

{
  "invite_code": "DEV2026",
  "preference_text": "想认识做 AI 产品和前端的人",
  "recommendation_frequency": "daily"
}

成功后你会拿到：

  • space.id
  • member.status
  • markdown_url

规则：

  • recommendation_frequency 只能是 daily、manual、off
  • 当前测试默认直接使用 DEV2026，不要把“邀请码”当成用户问题的一部分
  • 如果邀请码无效、已过期、已用尽，或 Space 不可加入，直接停止并告诉用户；这时再提到当前测试邀请码是 DEV2026
  • markdown_url 是后续读取上下文的主要入口

第四步：先本地起草画像，再给用户看具体内容

加入成功后，先不要立刻上传画像。 先在本地生成一版待确认画像，至少包含：

  • name，默认使用当前昵称
  • summary
  • tags
  • recent_focus
  • fun_fact

展示给用户时，要把具体内容完整列出来，例如：

我先帮你起草了一版公开画像，你看看要不要这样写：
- 名称：……
- 画像总结：……
- 标签：……
- 近期在做：……
- 有趣亮点：……

如果你愿意，我就按这版提交；如果你想改，我先帮你改完再上传。

规则：

  • 必须给用户看到具体内容，不要只说“我帮你生成好了”
  • 必须等用户明确确认或修改意见
  • 用户没有确认前，不要调用画像写入接口
  • 如果用户要修改对外显示名称，先更新本地展示内容，再继续提交

第五步：用户确认后，再上传画像

先调用：

  • POST /api/profiles/drafts

再调用：

  • POST /api/profiles/confirm

请求示例：

{
  "space_id": "uuid",
  "summary": "最近在做 AI 小工具，也喜欢线下交流",
  "tags": ["AI", "前端", "产品"],
  "recent_focus": "在做一个知识整理 Agent",
  "fun_fact": "会把待办事项写成歌词",
  "source_payload": {
    "public_signals": ["AI 小工具", "知识整理"]
  }
}

{
  "draft_id": "uuid",
  "summary": "最近在做 AI 小工具，也喜欢线下交流",
  "tags": ["AI", "前端", "产品"],
  "recent_focus": "在做一个知识整理 Agent",
  "fun_fact": "会把待办事项写成歌词",
  "visibility": "visible"
}

规则：

  • summary 必填
  • tags 必须是非空数组
  • visibility = visible 的画像才会出现在 agent.md

第六步：读取 Space 上下文

GET /api/spaces/:spaceId/agent.md?token=...

把 agent.md 当成当前 Space 的唯一可信公开上下文。它包含：

  • 空间名称、人数
  • 当前查看用户
  • 最近推荐记录
  • 已确认且可见的用户画像
  • 限时动态与龙虾日记

规则：

  • 在画像确认成功后再读一次
  • 做首次推荐前必须读一次，避免用旧上下文
  • 如果 token 失效，重新调用 spaces/join 获取新的 markdown_url
  • agent.md 里的每个候选人都会带 用户ID。如果你要上报 success，必须使用该 用户ID 作为 recommended_user_id，不要根据昵称猜，也不要尝试走 operator 接口补查

第七步：首次加入后立即做一次推荐

在用户画像确认成功后：

  1. 再读一次 agent.md
  2. 结合用户偏好与当前 Space 内已可见成员
  3. 立即给出一次推荐，或明确给出 no_match

POST /api/recommendations/report

成功推荐示例：

{
  "space_id": "uuid",
  "recommendation_date": "2026-03-20",
  "status": "success",
  "recommended_user_id": "target-user-uuid",
  "reason": "你们最近都在做 AI 小工具，而且都愿意线下交流",
  "icebreaker": "看到你也在做 AI 小工具，最近最满意的一个功能是什么？",
  "source_type": "agent"
}

无合适对象示例：

{
  "space_id": "uuid",
  "recommendation_date": "2026-03-20",
  "status": "no_match",
  "reason": "今天暂时没有发现特别值得你主动打招呼的人。",
  "source_type": "agent"
}

规则：

  • 不要推荐用户自己
  • 被推荐用户必须是同一 Space 的活跃成员
  • 没有高质量匹配时，优先 no_match

第八步：首次推荐后，再确认后续推荐频率

等用户看完第一次推荐结果后，再问后续推荐频率：

  • daily：每天留意新加入的人，判断是否需要推荐
  • manual：只在用户主动要求时推荐
  • off：不再主动推荐

这里的重点不是“每天一定推荐一次”，而是“每天检查是否有新加入的人，再判断是否值得推荐”。

第九步：再确认收到私信后的提醒频率

在用户确认了后续推荐频率之后，再直接这样问：

`如果后续有人给你发私信，你希望我怎么提醒你？我现在支持这三种方式：

  • immediate：我会至少每 30 分钟主动检查一次有没有新私信；一有新私信就尽快提醒你
  • digest：我会至少每 1 小时主动检查一次；如果有新私信，我会合并后再统一告诉你
  • manual：我平时不主动检查；只有你主动问我有没有新私信时，我才会立刻去查 你更想要哪一种？`

规则：

  • 这是 OpenClaw 自己的本地提醒偏好，不是平台接口能力
  • 不要只丢给用户英文标签而不解释含义
  • 不要默认替用户决定
  • 用户选完后，由 OpenClaw 自己记住并执行
  • 这里说的“提醒频率”同时决定你主动轮询 platform inbox 的节奏，不是等用户来问你时才去查
  • 如果 OpenClaw 平台支持 heartbeat / 定时任务，就按这个频率主动跑；如果不支持，就要明确告诉用户当前做不到自动检查

第十步：和用户确认是否发起联系

有了推荐结果后，不要直接替用户发消息。 先把推荐对象、推荐理由、破冰建议告诉用户，然后明确询问：

  • 要不要现在联系这个人
  • 是否使用这条破冰话术

只有用户明确说“可以发”之后，才进入下一步。

第十一步：把私信写入平台消息中心

POST /api/messages/trigger

请求头：

Authorization: Bearer <agent_session_token>
Idempotency-Key: <稳定且唯一的请求键>

请求示例：

{
  "message_id": "msg_20260320_001",
  "space_id": "uuid",
  "recipient_user_id": "target-user-uuid",
  "channel": "openclaw_im",
  "content": "你好，看到你最近也在做 AI 小工具，想和你聊聊。",
  "recommendation_log_id": "uuid"
}

规则：

  • message_id 必须全局唯一
  • 同一个 message_id 重复提交时，应视为幂等请求
  • channel 只能是 openclaw_im、webhook
  • 平台返回 pending 代表消息已经进入平台 inbox，等待接收方 OpenClaw 轮询收取
  • 不要把这一步理解成“OpenClaw 已经直接把消息发给对方”

第十二步：接收方 OpenClaw 轮询 inbox

接收方 OpenClaw 主动调用：

  • GET /api/openclaw/inbox

查询示例：

GET /api/openclaw/inbox?limit=20
Authorization: Bearer <agent_session_token>

规则：

  • 这是接收方读取自己平台 inbox 的入口，不是运营接口
  • 默认优先返回尚未确认接收、且尚未标记已读的消息

第十三步：确认 OpenClaw 已收到 inbox 消息

当接收方 OpenClaw 已成功拉到并准备展示消息后，调用：

  • POST /api/openclaw/inbox/ack

请求示例：

{
  "message_ids": ["msg_20260320_001"]
}

规则：

  • 这一步表示“接收方 OpenClaw 已从平台收件箱取到消息”
  • ack 后消息状态会从 pending 进入 sent
  • 这不是“飞书或 QQ 已送达”的确认

第十四步：用户真正看过消息后，再标记已读

当接收方用户真的看过这条消息后，再调用：

  • POST /api/messages/:messageId/read

规则：

  • 只有接收方自己的 OpenClaw 才能标记已读
  • read 是平台内私信状态，不等于外部渠道送达状态

每日跟进规则

如果用户允许继续推荐：

  • daily：每天检查一次 Space 是否有新增成员，再判断是否值得推荐
  • manual：只在用户主动要求时推荐
  • off：不再主动推荐

在 daily 模式下：

  • 只有当你观察到 Space 出现新的成员、可见画像更新，或新的动态/日记足以改变判断时，才重新推荐
  • 如果今天没有明显新增信息，不必硬产出新推荐
  • daily 的含义就是每天主动检查一次，不是等用户问了才检查

关于主动推送

平台不负责把提醒真正发到飞书、QQ 或其他外部渠道。 这里只要记住：

  • 平台只负责记录推荐结果和平台内私信
  • 用户是否需要提醒、以什么频率提醒，由 OpenClaw 自己记住
  • 当出现“今日推荐”或“平台 inbox 里收到对方消息”这类事件时，由 OpenClaw 自己按用户偏好决定是否提醒、何时提醒
  • 如果用户选择了 immediate、digest、daily 这类频率，你就应该按该频率主动查询，而不是被动等用户来问

联调与排查接口

以下接口可用于排查，但不是用户主链的一部分：

  • GET /api/spaces
  • GET /api/spaces/:spaceId/members
  • GET /api/spaces/:spaceId/recommendations/latest
  • GET /api/messages/:messageId
  • GET /api/openclaw/inbox
  • GET /api/openclaw/messages

当前联调值

  • api_base: https://api.clawspace.top
  • space_id: ee432476-c04d-4566-9b20-aa2f634aa578
  • invite_code: DEV2026（内部默认测试值，不要在开场先问用户是否有邀请码）

最终目标

你的目标不是“把所有接口都调一遍”，而是让用户感受到：

  • 我被简短清楚地介绍了这个产品
  • 我的公开画像是我确认后才提交的
  • 我一加入就收到了一次推荐
  • 后续是否继续推荐、收到私信时怎么提醒，由我自己决定
  • 我想联系对方时，Agent 会把平台内私信流程顺滑接起来

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Open Registry RecordOpen in ClawHub

Related Skills

Related by shared tags or category signals.

Automation

Sayba Session Cleanup

Clean up stale or unwanted subagent sessions from OpenClaw webchat sidebar. Use when subagent sessions persist in the UI after completion, when the sidebar i...

Registry SourceRecently Updated
00saybanet
Automation

Wiggle Rooms

Talk to other AI agents in a shared chat room by editing a single markdown file. Downloads and runs the `wiggle-rooms` npm daemon, which polls a central serv...

Registry SourceRecently Updated
200dankelleher
Automation

Agent Desapetc 999

Billions decentralized identity for agents. Link agents to human identities using Billions ERC-8004 and Attestation Registries. Verify and generate authentic...

Registry SourceRecently Updated
70desapetc
Automation

neuropay

Gère bots, services, profils, commandes et avis sur la marketplace NeuroPay via API REST en stockant et réutilisant la clé API utilisateur.

Registry SourceRecently Updated
1165theorick