火力打卡

解决的具体问题

活动运营里主要有三个反复踩坑的地方。第一是数据碎片化：本地活动散落在社群、公众号、票务平台里，通用搜索抓回来的字段经常缺失或脏乱，光是清洗就要耗费大量精力。第二是缺乏标准发布通道：很多工具只支持纯文本描述，无法承载时间、坐标、封面图、付费定价这些活动领域常见的结构化字段，每次发布都需要拼凑临时脚本。第三是对话式创建难以落地：Agent 通过自然语言接口创建活动听起来很顺，但如果没有严格的字段校验和清晰错误信号，很容易在缺图、坐标串位、时间戳格式错乱等问题上反复重试。

这个技能就是围绕这三件事设计的。它基于 MCP 后端 https://mcp.fore.vip，把活动搜索、详情、创建、行程查询拆成四个独立的工具，所有时间、坐标、付费规则都在后端统一约束，让 Agent 无需临时拼凑解析代码。

技能如何工作

工具清单

四个 MCP 端点各司其职，头部的 Tool 字段就是 Agent 可调用的名字。

• search_activities → POST /act/search，无鉴权。距离 / 热度双模式搜索。
• get_activity_detail → POST /act/detail，无鉴权。返回详情，每次调用 view_count 自增。
• create_activity → POST /act/create，需 X-API-Key。支持 fee 字段（单位：分）。
• list_activity_schedules → POST /act/schedules，无鉴权。按 activity_id 拉取行程列表。

字段级契约（inputSchema / outputSchema / 错误码）统一存放在 references/mcp.json，需要精确字段定义时直接读，不要凭记忆硬编码。

模式一：单活动创建

用户说“帮我创建一个活动”时，Agent 进入多轮收集 → 单次调用模式，严格按顺序补齐，不可跳步：

1. API Key — 第一件事就开口问。Agent 不保存不记录，每一轮创建都重新问一遍；如果返回 403 立即中止。
2. 封面图片 — 用户发图就用图链，发 URL 就用链接。没有图时明确拒绝，不能走过场。
3. 活动主题 — ≤500 字，同时确认标签（最多 10 个）。
4. 地址 — ≤128 字。
5. 经纬坐标 — Agent 自动触发 web_search 解析地址，展示给用户确认。GeoJSON 标准 [lng, lat]，经度在前。
6. 开始 / 结束时间 — 自然语言转 Unix 毫秒时间戳（13 位），不确定结束时间就设 null。

收集完毕输出总结请用户确认，只调用一次 create_activity。成功路径展示主题、链接、封面、地图数据和时间范围；失败路径也清晰：403 提示 Key 无效，-1 告知哪个字段有问题，-3 提示封面下载失败换一张。

模式二：批量创建

用户要求批量搜索并发布时走循环流程：确认 Key → 通过 web_search 分三个维度搜集未来活动候选（至少 3 个，严禁编造）→ 逐条抓封面图并解析坐标 → 顺序调用 create_activity（上一条返回后再调下一条），每条完成后汇报进度，最后输出汇总。

适用边界与注意点

• 时间戳格式：start_time / end_time 是 13 位 Unix 毫秒，不是秒，写成 10 位会静默错位。
• 坐标顺序：GeoJSON 的 [lng, lat] 与常见的 [lat, lng] 相反，解析坐标环节如果不确认很容易抓错。
• 鉴权策略：X-API-Key 每一轮都要重新索取，绝不缓存、不持久化、不跨会话复用。
• 详情副作用：get_activity_detail 一调就自增计数。如果要频繁刷新详情，建议客户端缓存，避免一晚涨几千次浏览。
• 付费规则：fee 单位是分，100 = 1 元。缺省或传 0 就是免费；传非 0 值时后端自动置 pay_required=true 拉起支付。负数或非法值会被忽略并回退为 0。
• 行程不联表 guest：list_activity_schedules 返回的 guest_id 就是用户 ID，不带昵称和头像，前端展示需自行查 user 表。
• 分页上限：pageSize 默认 10，超过 50 会被截断。
• 空行程不是错误：新活动返回 list=[]、total:0 是正常情况，如实提示“暂无行程”即可。
• 字段契约：写错误处理之前先读 references/mcp.json，尤其是 fee、坐标与时间戳这几个高风险字段。