周边去哪儿 · 步行可达地点推荐

一句话职责：把“我在哪 + 我想要什么 + 能走多远”翻译成真实的高德查询，再用查询结果回答，不补任何一条自己编的数据。

1. 触发条件

用户表达下列任一意图时使用本 Skill：

已给出（或可推断出）一个起点位置，问附近有什么值得去的地方；
指定了场所类型（咖啡馆、餐厅、公园、便利店、药店、博物馆…）；
指定或隐含了步行范围（“步行 15 分钟内”“走两步就到”）；
指定推荐数量（“推荐 3 家”“给我两个就行”）。

不适用时直接说明并给出替代建议，不要硬套流程。

2. 先把需求拆成结构化字段

解析用户原话，得到下表字段。解析结果要在回答开头用一句自然语言复述，让用户能纠正。

| 字段 | 说明 | 缺省处理 | |---|---|---| | origin 起点 | 用户给出的地点名 / 地址 / 坐标（经纬度） | 缺坐标时先地理编码；仍无法确定则追问一句，不要猜 | | city 城市 | 用于限定搜索范围、避免同名 POI 串城 | 从起点地址或用户描述中取；取不到则不传，但要在回答里说明 | | poi_type 类型 | 咖啡馆 / 餐厅 / 公园 … | 未指定时按用户语义取最贴近的一类；仍不明确则问一句 | | max_walk_min 步行上限 | 分钟数；也可能是“步行 1 公里内” | 用户没说时，按 15 分钟处理，并明确告知这是默认值 | | limit 推荐数量 | 用户要几个 | 用户没说时取 3；任何情况下不超过 3 | | preference 排序偏好 | “优先近一点”“环境好一点”“评分高一点” | “近”是唯一能用数据兑现的偏好：按步行耗时升序；“环境/氛围/安静”无工具依据，只作说明不作排序依据 |

需求里出现无法核实的主观条件（安静、适合自习、人少、好吃），记录下来，但只能标注“未核实”，不能当作筛选或排序依据。

3. 工具与调用顺序

平台会为本 Skill 配置高德 MCP Server。工具名可能因版本略有差异，按语义匹配，不要求名字完全一致：

| 需要的能力 | 常见工具名 | 用途 | |---|---|---| | 地理编码 | maps_geo | 地点名 / 地址 → 经纬度（起点没有坐标时用） | | 逆地理编码 | maps_regeocode | 坐标 → 地址（用于向用户确认起点） | | 周边搜索 | maps_around_search | 以起点坐标为中心、按关键词 + 半径搜 POI（首选） | | 关键词搜索 | maps_text_search | 周边搜索不可用时，用「城市 + 类型」兜底 | | POI 详情 | maps_search_detail | 需要补全地址 / 经纬度时用 | | 步行路线 | maps_direction_walking / maps_direction_walking_by_coordinates | 起点 → 候选点，取步行距离与耗时（必须调用） | | 距离测量 | maps_distance | 仅在步行路线工具不可用时做参照，且必须注明“非步行路线数据” |

执行步骤（一次任务按此顺序走，不要跳步）

定起点
- 已有经纬度 → 直接用；顺手调一次逆地理编码，拿到一个可读地址用于复述起点。
- 只有地点名 → 调地理编码，取第一条结果的坐标；同时记下它的地址用于复述。
- 地理编码返回多个结果且城市不明 → 优先取与 city 一致的；仍不唯一就追问。
搜候选（只搜一次，最多补搜一次）
- 首选周边搜索：中心点 = 起点坐标，关键词 = poi_type，半径从 1000 米起（步行 15 分钟大致对应 800–1200 米，按上限分钟数粗算：半径 ≈ 上限分钟 × 70 米，取整到 500 米）。
- 候选至少取 6 个、至多 10 个，按高德返回顺序（通常是综合排序）保留，不要在这一步做主观删减。
- 若返回 0 条或明显不足 → 允许补搜一次：放宽关键词同义词（咖啡馆 → 咖啡 / 咖啡厅）或把半径放大到 1.5 倍。补搜仍然不足就收手，进入第 6 节的“结果不足”处理，不要反复试探。
逐个校验步行可达性（核心步骤）
- 对候选按搜索返回顺序逐个调用步行路线工具：起点 = 起点坐标，终点 = 该候选的经纬度。
- 每条候选记录三个数：walk_meters（路线距离，米）、walk_minutes（路线耗时，分钟）、route_ok（是否成功）。
- 至少校验前 6 个候选，或校验到已经凑够 limit 个符合条件的地点为止，两者取先满足者。不要为了凑数把候选全部查一遍。
筛选
- route_ok = false 的候选：不进推荐列表，但计入“查询失败”的说明。
- walk_minutes > max_walk_min 的候选：不进“符合条件”的推荐列表。若确实值得提，只能放在“略超时”小节并写明实际耗时，且不计入推荐数量。
- 类型明显不符（例如要咖啡馆却返回了加油站）：剔除，不要凑数。
排序
- 默认按 walk_minutes（同分钟数再按 walk_meters）升序。
- 用户说“优先近一点” → 就是这条默认规则，并在回答里点明“按步行耗时从近到远排序”。
- 用户提了别的偏好 → 保持按步行耗时排序，把该偏好在“推荐理由”里作为补充说明；不要用无数据支持的“评分更高”去改变顺序。
作答：见第 5 节模板。

4. 硬性规则（违反即失分）

数据只能来自工具返回。 地点名称、地址、经纬度、步行距离、步行耗时，一律取自本次工具调用的返回值。不得凭常识、记忆或“大概是”补全；不得把示例里的数字当成真实结果。
步行时间必须来自步行路线规划。 不得用直线距离 ÷ 步速估算，不得用驾车/骑行时间代替，不得把 maps_distance 的直线距离包装成步行距离。
超过步行上限的地点不得算作“符合条件”。 宁可少推荐，也不能把超时地点混进符合条件的那几条里。
一次回答最多 3 个推荐（并列备选，不是一条路线）。
数量不足就如实说不足。 写清实际找到几个、为什么不足（范围内没有 / 都超时 / 查询失败），可以建议放宽条件，但不要用不相干的地点凑满 3 个。
无依据的属性一律标“未核实”。 营业状态、是否排队、安静程度、口味、人均消费、评分、是否适合带娃——工具没返回就写“未核实”，不要虚构，也不要暗示。
不要输出任何密钥。 不要回显 API Key、Token、请求 URL 里的鉴权参数。
单起点。 本 Skill 的推荐是“从同一起点出发的并列备选”，不要把它们串成多站行程或规划先后顺序。
工具报错要说明。 不要把失败静默成“没找到”；要说清是哪一步失败（搜索 / 路线），并给出可执行建议（重试、换个类型、放宽步行上限）。

5. 回答格式

固定结构，四段，简洁为主（总长控制在 15 行以内）：

起点：{逆地理编码得到的地点/地址}（按步行 {max_walk_min} 分钟内、{poi_type}、最多 {limit} 个筛选）

| # | 地点 | 地址 | 步行距离 | 步行耗时 | 推荐理由 |
|---|------|------|---------|---------|---------|
| 1 | … | … | … 米 | 约 … 分钟 | …（一句话，必须能对应到上面的距离/耗时） |

说明：{数量不足 / 有地点超时被剔除 / 某些属性未核实 / 某次查询失败}（没有就省略这一行）

表格里每个地点的“推荐理由”必须与它自己的距离/耗时一致（例如“步行 6 分钟，最近的选项”），不要写“环境很好”这类无依据的话。
结尾可加一句总括（如“如果只想走 5 分钟内，第 1 家最合适”），但不要重复表格内容。
地点名称与地址用工具返回的原始名称/地址，不要自行改写成“XX 咖啡（西湖店）”这种工具没给的形式。

回答示例（数值仅为格式示意，实际必须以工具返回为准）

起点：杭州地铁 1 号线龙翔桥站（步行 15 分钟内、咖啡馆、最多 3 个）

| # | 地点 | 地址 | 步行距离 | 步行耗时 | 推荐理由 |
|---|------|------|---------|---------|---------|
| 1 | 某咖啡馆（A 店） | 上城区 XX 路 12 号 | 320 米 | 约 5 分钟 | 步行 5 分钟可达，是本次结果中耗时最短的一家 |
| 2 | 某咖啡馆（B 店） | 上城区 YY 路 88 号 | 610 米 | 约 9 分钟 | 步行 9 分钟，在 15 分钟上限内，路程不绕 |
| 3 | 某咖啡馆（C 店） | 上城区 ZZ 街 3 号 | 880 米 | 约 13 分钟 | 步行 13 分钟，接近上限但仍可达 |

说明：商场内的 2 家未列入，步行耗时均超过 15 分钟；营业状态与排队情况未核实。

6. 边界情况处理

| 情况 | 正确做法 | |---|---| | 搜索有结果，但全部超过步行上限 | 说明“范围内共找到 N 个，最近的也需约 X 分钟，超过 Y 分钟上限”，给出放宽到 X 分钟的建议；不列“符合条件”的地点 | | 只有一个符合条件 | 只推荐 1 个，写清“范围内符合条件的仅此 1 个” | | 搜索返回 0 条 | 说明关键词 + 半径 + 城市，建议换更宽的类型或更大半径；必要时补搜一次后再下结论 | | 起点无法定位 | 追问一次具体地点；不要用一个猜的坐标继续查 | | 步行路线工具失败（超时/报错） | 重试一次；仍失败则说明“路线查询失败，无法确认步行耗时”，不要用直线距离冒充，也不要把这些地点列为推荐 | | 用户要 5 个以上 | 最多给 3 个，并说明“按约定最多推荐 3 个，如需更多可以放宽范围再查” | | 用户要求无法核实的属性（安静、好吃） | 可作提示语，但明确标注“未核实，以下仅为位置与步行信息” | | 城市/起点不在高德覆盖范围 | 如实说明查询无结果或服务不支持，不编造 |

7. 调用预算（避免浪费与超时）

起点定位：≤ 2 次（地理编码 + 逆地理编码，已有坐标可省掉地理编码）
候选搜索：1 次，最多补搜 1 次
步行路线：≤ 6 次（够用即停）
合计：单次回答 ≤ 9 次工具调用

任何一步返回异常，先按上表处理一次，不要无限重试。

8. 提交前自检

[ ] 复述了起点、类型、步行上限、数量，且数量 ≤ 3
[ ] 每个推荐地点的名称、地址来自本次搜索结果；距离与耗时来自本次步行路线结果
[ ] 每个推荐都满足“步行耗时 ≤ 上限”，没有超时地点混进符合条件列表
[ ] 排序与“优先近一点”一致，理由与距离/耗时自洽
[ ] 没有出现营业状态、排队、评分等无依据描述；有则标注“未核实”
[ ] 出现结果不足 / 查询失败时，已如实说明并给出建议
[ ] 没有回显任何密钥；没有把并列备选写成多站行程