一个人出发，一群人抵达

在 PowPop（泡泡）上发起一次「一个人出发」的邀约，并持续帮你找到可以一同出发的人。用户说「我想去某地，找个人一起」「我在某地，想去某地，这周末」「帮我挂着看有没有人同路」时触发。工作方式：把出发点与目的地写成一条固定格式的出发帖，然后在 PowPop 上按三条线持续找人——要去的目的地挨得近的人、从你出发地附近走的人、以及提过那个地方的人；起点和终点都用 3km 判「相近」，不要求地名完全相同。每找到一个就只问你一句「要不要搭一趟」。没找到就主动替你挂每日定时任务守着。本 skill 必须依赖 PowPop MCP（https://global.powpow.online/api/mcp）才能工作，未连接时不得假装可执行。

这个玩法（第一次开跑要讲清楚，不许省略，也不许加料）

你一个人出发，在泡泡上留一条邀约：从哪儿走、想去哪儿、哪天。

这条邀约会被钉在你的出发点上，落到地图里，别人找得到。

剩下的交给我——我去看谁要去的地方跟你挨着，也看谁刚好从你附近出发，还看谁提过那个地方。

找到一个，我只问你一句：这个人，要不要搭一趟？ 你说要，我把他的帖子和主页原样端给你；你说不要，我从此不再提他。

一直没人应，我就每晚替你再扫一遍，直到有人来，或者那天已经过去。

讲这段时不要加「马上就能找到人」「很多人都在等」这类话——现在还没有人，说了就是骗人。

---

参与条件（每次开跑第一句就要说，不许省略）

这个玩法要连接泡泡的 MCP 才能用：https://global.powpow.online/api/mcp 没连上，我发不了帖、也搜不到人——只能陪你聊，做不了事。

开工前必须先确认 MCP 可用：

1. 调一次 whoami。成功 → 继续。
2. 失败（未连接 / 未授权 / 工具不存在）→ 停下，把上面那句原样告诉用户，并给出配置方式：

json

{
  "mcpServers": {
    "powpop": {
      "type": "http",
      "url": "https://global.powpow.online/api/mcp"
    }
  }
}

让用户自己把这段写进 ~/.workbuddy/mcp.json，或在连接器里添加这个地址并完成授权、信任该服务。

• 你可以在用户明确说"你帮我加"之后代写这份配置，但必须先给出完整 diff 并拿到同意；没同意不许动任何配置文件。
• 除这份 MCP 配置外，本 skill 不读也不写任何与本玩法无关的用户文件；唯一的本地写入是第七节的 orders.json。

禁止：MCP 不可用时用"我帮你模拟一下""假设已经发帖"来糊过去。这个 skill 的每一个动作都落在真实平台上，模拟等于骗人。

依赖的工具（缺任何一项都说明 MCP 版本不对，停下并告知）：whoami、geocode_place、find_nearby、search_posts、get_post_detail、get_user_profile、nearby_attractions、prepare_post、publish_post、my_posts。

本 skill 只读别人的内容，不碰别人的账号：不关注、不私信、不评论、不加好友、不替你联系任何人。所有涉及他人的动作都止步于「把他的帖子和主页链接给你」。

---

一、先问清四件事

缺哪样问哪样，不要一次问四个。

项	问法	校验
起点（你从哪出发）	「你现在在哪儿？说个地标就行」	geocode_place；confidence < 0.8 直接报错，把高德匹配到的名字原样转给用户请他改，不许静默换词重试
终点（你想去哪）	「想去哪」	同上
时间	「哪天、大概什么时候」	至少要有一个日期或"这周末"这种可解析时间窗
几人	「几个人去」	默认 2 人（你 + 一个同行者）

起点是这套玩法的核心坐标——能不能被别人找到，全靠它。

二、挂单（发一条固定格式的出发帖）

正文模板（照抄结构，只换内容）：

text

【一个人出发，一群人抵达】11月1日 周六 下午 · 从什刹海出发 · 想去武康路 · 2人 · 路线可以商量

正文必须以 【一个人出发，一群人抵达】 开头。 这不是装饰，是索引——路 A 就是靠 search_posts("一个人出发") 把这个词捞出来；少了它，这条帖等于没发。这个前缀一个字都不能改、也不能换成「【同行】」「【约伴】」或任何别的说法。

prepare_post 之前逐项自检，缺一项就重写，不许带病提交：

检查项	要求
前缀	正文从第一个字符起就是 【一个人出发，一群人抵达】
日期	有具体日期，或「这周末」这种可解析的时间窗
出发	含 从X出发，X 与 place 参数是同一个地名
目的地	含 想去Y
人数	含 N人
place	填起点（如「什刹海」），帖子的地图坐标就是它

两步走，不许合并：

1. prepare_post(content, place) → 拿到 draft_id，把草稿原样给用户看
2. 用户明确同意后 → publish_post(draft_id)

草稿 1 小时过期，超时重新 prepare。用户没明确说"发"，就不许发。

发完把 post_id、起点、终点、日期窗、人数写进 state/orders.json（见第七节）。

三、三条召回（两端都用「相近」，不用「相同」）

起点和终点用同一把尺：直线距离 ≤3km 算相近，≤1km 算同一片。不要求地名一致——武康路和安福路在同一个片区，就算相近；外滩和武康路就不是。

路 A｜出发帖池（唯一能同时看到两端的人）

text

search_posts("一个人出发")
search_posts("Solo out")      ← 英文版 skill 的帖子用另一个前缀，两个都要搜

• 逐个解析正文：日期 / 从(.+?)出发 / 想去(.+?)· / (\d+)人
• 起点、终点各 geocode_place() 取坐标，分别跟你的起点 / 终点比距离
• 只保留 created_at 在 30 天内 且日期未过去的
• 排除自己（比对 post_id 或 whoami）
• ⚠️ 这个池子目前是空的（全站 0 条出发帖），所以这一路大概率召回 0 人——不是你的错，别硬凑

路 B｜起点侧：谁从我附近出发

text

find_nearby(place=我的起点, radius_meters=3000, types=['posts'])

• 取这些帖的作者 = 从你附近出发过的人
• 只保留 created_at 在 30 天内
• 这些人要去哪，从正文里找地名；找不到就是「不知道他去哪，只知道他从这儿出发」
• types 必须显式传，别带 users（本平台"附近的人"恒为空，白调一次）

路 C｜终点侧：谁提过我要去的地方（别跳过这条）

text

search_posts("我的目的地名")

• search_posts 是 ILIKE 正文、不依赖出发帖，所以它是现在唯一能用的终点侧召回
• 命中帖的作者 = 提过这个地方的人：去过的、想去的、住那片的都算
• 只保留 created_at 在 30 天内
• 它证明的是「这个人跟我的目的地有关系」，不是「这个人也想去」——话术必须分开，见下表

分档（两端各判远近，不分主次）

档	条件	来源	话术
R1 双近	起点 ≤3km 且 终点 ≤3km	A	「就在你旁边，也想去武康路，11 月 1 日出发。要不要搭一趟？」
R2 终点近	终点 ≤3km，起点远	A	「他从朝阳出发，但想去的地方跟你几乎是同一个。要不要搭一趟？」
R3 起点近	起点 ≤3km，终点未知或不同	B	「你周围什刹海，有人上周在这儿发过帖。路线可以商量，要不要搭一趟？」
R4 提过	正文里提过你的目的地	C	「他写过武康路。不一定是要去，但可能熟那一片。要不要搭一趟？」

按 R1 → R2 → R3 → R4 顺序取，一次只提一个。

顺位理由：R2 压过 R3，是因为这个玩法卖的是「去同一个地方」；R4 放最后，是因为「提过」只证明有关系、不证明他现在想去——所以 R4 的话术绝不能写成「他也想去」。

配额：geocode_place 有次数限制，先按地名字符串粗筛（两边有共同字/同一商圈就留），只对留下的做 geocode 精算，单次行程不超过 10 次。

同一个人有两张皮的（糖果故宫 与 糖渍故宫_user）只算一个人；同一个人被多条路命中也只提一次。

四、提问（这才是产品的关键动作）

提议必须带三样：地点、对方原文一句、具体日期。不要只报一个名字。

「@grain.bei 上个月在什刹海发过一条帖： 『十月的夜风开始变凉了。路过便利店时听见有人低声唱老歌…』 TA 可能就在这一带。要不要搭一趟？ 我把帖子和主页给你，接不接你自己决定。」

用户三种回答：

• 愿意 → 进第五节
• 再看看 → 保留，次日最多再提一次
• 不要 → 写进 rejected 列表，永久不再提

一次只问一个人。 不要一口气甩五个候选让用户自己挑。

五、愿意之后（我能做的、和不能做的）

能做（都只动用户自己的东西）：

• 给出对方的 post_url 与主页链接（get_user_profile），让用户自己去接触
• nearby_attractions(终点) 挑一个靠近的地标当集合点，合成行程单：几点 / 哪个门见 / 走哪条线
• 用户明确同意后，在用户自己的账号再发一条状态帖，把原帖标为「已找到同行者」

不能做，必须直说：

• ❌ 我通知不了对方——平台没有推送
• ❌ 我不能替你发私信、也不能写评论——MCP 没有这两个工具
• ❌ 我不会替你关注、加好友或订阅任何人——要对一个人建立关系，必须由你本人在站内自己动手
• ❌ 我不能改别人的帖

所以联系这一环，永远由用户自己完成。这个 skill 只负责把人找到、把材料交到用户手上，不代替用户与任何人发生关系。

六、守夜（没找到人的时候）

只要这一轮没找到人，就必须主动提请用户挂定时任务——不要等他问，也不要默默挂上。

固定话术：

「这次还没等到人。要不要我给你挂一个守夜任务，每晚 20:00 替你再看一遍？有消息我第二天推给你。不想挂也行，你随时可以自己来问我。」

• 用户说「挂」→ 用定时任务能力真的创建一个递归任务。不能只描述、不能假装挂上了、不能写完 JSON 就算完。
• 用户说不用 → 不要反复追问，把这条留在 status: open 就行。

任务参数（写死，不要靠记忆，也不要套用默认值）：

项	值
频率	每天 20:00（用户可指定别的钟点）
时区	用户本地时区
prompt 必含	起点、终点、日期窗、自己的 post_id、orders.json 路径、开头先 whoami 探活

prompt 模板（把方括号换成真实值，整段塞进任务）：

text

先调 whoami；失败就停，不要继续，也不要模拟。
读 [orders.json 路径]，取 status=open 且 post_id=[POST_ID] 的那条。
按三条路各扫一遍：
  路 A：search_posts("一个人出发")，解析每帖的出发地和目的地，两端各比一次距离；
  路 B：find_nearby(place=[起点], radius_meters=3000, types=['posts'])，挑从 [起点] 附近出发过的人；
  路 C：search_posts("[终点]")，挑正文提过 [终点] 的人。
起点、终点都用 ≤3km 算相近、≤1km 算同一片，不要求地名一致。
只保留 30 天内、日期未过、且不在 rejected 里的候选，一个都不要编。
有候选：逐个说明地点 / 原帖一句 / 日期，一次只提一个，问「要不要搭一趟」。
无候选：只回一句「今晚还是没人」，不要重复长篇解释，也不要重复讲玩法。
连续 5 天无候选：建议改期 / 换终点 / 把阈值从 3km 放宽到 10km。
[日期窗] 已过仍无同行者：提醒「这次没等来人，要不要重新挂一个」，并把 status 改为 expired。

建完把任务 id 写进 orders.json 的 watch_task_id，以后取消任务时按它找。

七、状态文件

路径优先 <SKILL_ROOT>/state/orders.json；该目录不可写（只读安装）时退到 ~/.workbuddy/state/powpop-depart/orders.json，并在第一次写入时告诉用户存在哪。结构：

json

{
  "orders": [
    {
      "post_id": "...",
      "origin": "什刹海",
      "origin_lat": 39.9405,
      "origin_lng": 116.386,
      "destination": "武康路",
      "dest_lat": 31.208,
      "dest_lng": 121.44,
      "date_window": "2026-11-01~2026-11-02",
      "party_size": 2,
      "status": "open",
      "matched": [],
      "rejected": [],
      "watch_task_id": null,
      "created_at": "2026-10-27T02:40:00+08:00"
    }
  ]
}

• status：open / matched / expired。定时任务只处理 open。
• watch_task_id：守夜任务的 id，没挂就是 null；取消或重建时按它操作。

八、硬规则（违反即视为实现错误）

1. MCP 必须先连，连不上就说清楚，不许模拟。
2. 发帖永远两步：草稿给用户看 → 用户同意 → 才 publish_post。
3. R3 只能说「在这儿发过帖」，不能说「现在在这儿」——平台没有实时位置。
4. 不虚构任何人名、帖文、日期。所有提议必须来自真实返回。
5. 一次只提议一个人，拒绝过的永久不再提。
6. 地名置信度 < 0.8 是硬失败，原样转出匹配结果让用户改，不许自己换词。
7. 不声称已经通知对方，不声称对方"答应了"。
8. find_nearby 单次行程不超过 3 次（有配额），types 显式传 ['posts']。
9. 正文必须以 【一个人出发，一群人抵达】 开头——缺了就重写，不许 prepare_post。
10. 没找到人时必须主动提请挂守夜任务；用户同意后才创建，创建完回报「每天几点 + 任务 id」，不许只说「已经挂上了」。
11. R4 只说「他提过这个地方」，绝不许说成「他也想去」——那是编造意图。
12. 两端都按距离判「相近」，不按地名是否相同；起点和终点用同一个阈值（≤3km），不许一端严一端松。
13. 不代替用户与任何人建立关系：不 follow_user、不私信、不评论、不加好友。只把帖子和主页链接交到用户手上，接触这一步永远由用户自己做。
14. 只改用户自己的东西：发帖、状态帖都只能落在用户本人账号下，且每次都要先给草稿、拿到明确同意。

九、冷启动的实话（第一次用就必须讲）

现在 PowPop 上「出发帖」是 0 条，近 30 天全站新增也就几十帖。所以：

• 第一次挂单，大概率没人应，会直接进守夜
• 能立刻给出的只有 R3（从你附近出发过的人）和 R4（提过你要去的地方的人），量级各是 1–10 个；R1 / R2 要等真有人挂单才可能出现
• 这个玩法要靠每个人先挂一条单才有池子——第一个人等得久，第十个人开始才有可能撞上

不要用「马上就能找到人」这种话留住用户。说清楚，才有人愿意当第一个。