高德周边探索

用高德地图 MCP 把一句需求变成可核验的周边推荐：查真实地点、查真实步行路线、筛出步行可达的备选、用数据说话。

本 Skill 只读取高德公开地理数据，不承诺实时排队、营业状态或口碑评价。API Key 与工具配置由运行环境提供，本文件不包含任何密钥。

适用范围

用于：周边地点推荐（咖啡馆、餐厅、公园、药店、书店等）、从给定起点出发的步行可达性判断、为"步行不超过 N 分钟"这类硬性约束筛选地点。

不用于：多站行程编排与串站路线、驾车/公交/骑行导航、天气与路况、店铺口碑打分。同一批推荐是从同一起点出发的独立备选，用户挑一个即可，不要拼成一条多站行程。

工具映射

不同高德 MCP 实现的工具名不一致。先读本次会话暴露的工具清单，按下面的"能力"列和工具描述匹配实际工具，再调用。表中给出的是高德官方 MCP Server（@amap/amap-maps-mcp-server）的工具名，其他实现可能是别名。客户端常常给工具名加服务器前缀（如 amap-maps:maps_around_search、amap__maps_around_search），用清单里显示的完整名字。

| 能力 | 官方工具名 | 其他实现中可能出现的别名（仅供匹配参考，一律以本次会话的工具清单为准） | 关键参数 | 关键返回 | | --- | --- | --- | --- | --- | | 地名转坐标 | maps_geo | geocode、amap_geocode | address 必填，city 可选 | return[0].location | | 周边地点搜索 | maps_around_search | maps_place_around、poi_around、search_around | location 必填（"经度,纬度"），keywords 类型词，radius 米 | pois[]：id/name/address/typecode；部分实现另带 location | | 关键词地点搜索 | maps_text_search | maps_place_text、poi_search | keywords 必填，city 可选，citylimit 可选（true 限定在 city 内） | pois[]，字段同上 | | 地点详情 | maps_search_detail | place_detail、poi_detail | id 必填 | name、location、address、business_area、city、type、alias，以及评分、人均、营业时间等详情字段 | | 步行路径规划 | maps_direction_walking | maps_walking、direction_walking、maps_direction_walking_by_coordinates、plan_trip（mode=walking） | origin、destination 均为"经度,纬度" | route.paths[0].distance（米）、.duration（秒）、steps[] | | 距离测量（可选粗筛） | maps_distance | distance | origins 多坐标、destination、type（1 驾车 / 0 直线 / 3 步行） | results[].distance（米）、.duration（秒） |

三点容易踩空的实现细节：

官方 maps_around_search 与 maps_text_search 的返回里，POI 只有 id、name、address、typecode，既没有坐标，也没有离中心点的距离。步行路线规划必须用坐标，所以官方实现下每个候选都要再查一次 maps_search_detail 才能拿到坐标。不要凭名称估算位置。
官方 maps_text_search 虽然声明了 types 参数，但服务端并没有把它透传给高德，不要依赖 types 做类型过滤。类型是否匹配，一律靠返回的 typecode 和详情里的中文 type 自行判断。
距离测量的多坐标分隔符以工具自己的参数描述为准，不同封装写法不一致。

执行流程

1. 解析需求

从用户原话里取五件事，缺的就用默认值，不要反复追问：

| 项 | 取值 | 缺省 | | --- | --- | --- | | 地点类型 | 咖啡馆、餐厅、公园…转成高德可搜的关键词（如"咖啡馆"） | 必须有；能合理推断就按最贴近的类型做并在说明里写明假设，实在无法推断才追问一次 | | 城市 | "杭州""武林"等 | 用户已给坐标时不用于搜索，仅用于兜底 | | 起点 | 坐标或地名 | 必须有；缺失且无法推断时追问一次 | | 步行时间上限 | 分钟数 | 未提则不设硬性上限，但仍在结果里给出耗时 | | 推荐数量 | 用户给的条数 | 3，且不超过 3 |

排序偏好也要记下来。用户说"优先近一点"就按步行耗时升序；说"安静""人少""适合办公"这类无法用工具核实的偏好，不要用来排序，写进说明并标注"未核实"。

2. 起点坐标化

评测通常直接给起点坐标，此时原样使用，不要再做地理编码。若给的是地名或地址，用 maps_geo 换成坐标，取 return[0].location。

坐标格式一律是"经度,纬度"，经度在前。起点坐标来自未说明的 GPS 原始坐标时，在说明里提一句坐标系可能有几百米偏移；高德自身数据与高德返回的坐标可直接使用。

3. 圈定候选

调用 maps_around_search，keywords 填地点类型词，location 填起点坐标，radius 填搜索半径。

半径估算：T 分钟的步行预算按经验步速约 1.25 米/秒（高德未公布固定步速常量，这里只是选召回半径的粗估）折算成约 75T 米的步行路程，考虑到实际路径比直线长，直线半径取 T × 60 米并向上取整到 100 米；10 分钟约 600 米，15 分钟约 900 米，20 分钟约 1200 米。这个换算只是选召回范围的粗估，不是给用户报的距离。半径只影响召回范围，不影响最终报出的距离和时间，所以宁可取到候选后再由路线结果淘汰，也不要用半径直接当步行距离。半径一般取到 3000 米即可；当步行预算对应的半径超过 3000 米时（例如 T ≥ 50 分钟）放宽到 5000 米，避免大时间预算被 3000 米硬上限系统性漏掉。

4. 取候选坐标

从第 3 步返回的同一批结果里取最多 8 个候选做核验，攒够 3 条满足条件的推荐就停。周边搜索的返回顺序由高德服务端决定，可能是按距离也可能是按综合权重，顺序不代表远近，所以要把这一批整体看过，不要只盯着前几条。坐标来源：POI 自带 location 就直接用；官方实现下 POI 一律没有 location，就对每个候选调 maps_search_detail，从 location 取坐标。

typecode 是 6 位分类码（前 2 位为大类），本文件不提供对照表，所以判类型以 maps_search_detail 返回的中文 type 为准，例如"餐饮服务;咖啡厅"。不要凭 typecode 猜类别。候选点里混进了别的类型（例如搜咖啡馆返回了便利店）就剔除，并在说明里写清剔除了几条。

5. 步行路线核验

对每个候选调 maps_direction_walking，origin 为起点坐标，destination 为候选坐标。取 route.paths[0].distance（米）与 route.paths[0].duration（秒）。多个候选的路线查询可以并行发起。

若返回里 route.paths 为空或缺少 distance/duration，说明这个候选没查到步行路线：不要报 0，也不要自行估算，如实写"该地点未查到步行路线"并把它从候选里剔除。

步行时间与距离一律以这里的返回为准。直线距离不能替代步行距离，maps_distance 的 type=0 更是不能拿来当步行耗时。

6. 筛选与排序

硬性约束：有步行时间上限时，duration ≤ 上限分钟数 × 60 才算符合。超出上限的候选不作为推荐列出，必要时说明"另有若干候选超过 X 分钟，未列入"。
排序：用户说"优先近一点"或没给偏好时，按 duration 升序，耗时相同再按 distance 升序。
取前 N 条，N 取用户要求的条数与 3 的较小值。

候选不足时，先放宽半径再搜一次（按第 3 步的半径规则），或用 maps_text_search 在同城市补同类型候选；补进来的候选同样要走完路线核验才可推荐。补搜后仍不足，就按实际条数输出并说明原因。

7. 生成回答

按下面格式输出，用表格。

为你找到 N 个步行可达的<地点类型>（按<实际排序依据>）：

| # | 名称 | 地址 | 步行距离 | 步行耗时 | 推荐理由 |
| --- | --- | --- | --- | --- | --- |
| 1 | <名称> | <地址> | 约 <距离> 米 | 约 <耗时> 分钟 | <一句话理由> |
| 2 | <名称> | <地址> | 约 <距离> 米 | 约 <耗时> 分钟 | <一句话理由> |
| 3 | <名称> | <地址> | 约 <距离> 米 | 约 <耗时> 分钟 | <一句话理由> |

说明：距离与耗时来自高德步行路径规划结果，为估算值。<补充说明>

排序依据要和第 6 步一致：默认按步行耗时由近到远，用户给了别的偏好就写那个偏好，并让理由呼应同一条路线数据。

写这份回答时：

距离与耗时取自路线查询返回值。耗时按秒换算成分钟，保留一位小数并附上原始秒数（例如"约 5.8 分钟（348 秒）"）；距离 1000 米以上同时给出米（例如"约 1.2 公里（1234 米）"）。带上原始数值，评审才能逐项对上工具返回。统一带"约"字，因为是估算。
推荐理由一句话，只写有数据依据的内容：步行耗时、步行距离、POI 类型、地址所在商圈，以及详情查询明确返回的字段。举例"步行 6 分钟可达，位于城西商圈，POI 类型为咖啡厅"。详情查询返回了评分、人均、营业时间时优先用它们写理由，这是最有依据的加分项；没有这些字段就不要写"环境安静""人少""生意好"。
补充说明按情况写：结果不足时说明实际找到几条、为什么不足、可以怎样放宽；信息缺失时，只把用户确实问到的维度列为"未核实"（用户提到安静、排队、是否营业才列这些，用户没问的不必罗列）；工具调用失败时如实写明哪一步失败。
详情查询确实返回了评分、人均、营业时间这类字段时，可以写"POI 详情显示评分 4.6、人均 58 元、营业时间 09:00-22:00"这类有出处的信息，但不要说"现在正在营业"，除非有工具明确返回当前状态。
用户要的条数超过 3 家时，在说明里写明本次最多给出 3 家。
保持简洁。用户要的是能做出选择的清单，不是地图报告。

评测场景与对应处理

| 场景 | 该做什么 | | --- | --- | | 普通推荐 | 周边搜到候选后逐个核验步行路线，给出最多 3 条真实地点，类型与需求相符 | | 时间限制 | 只把 duration 在上限内的候选列为符合条件；超限的单独说明，不混进推荐表 | | 偏好排序 | "优先近一点"就让顺序与耗时升序一致，理由也呼应同一条路线数据 | | 结果不足 | 如实说只找到 N 个、说明原因、给出放宽建议；不为了凑数把超限地点塞进推荐 | | 查询异常 | 工具报错就如实报哪一步失败；重试一次仍失败则说明未核实的部分，不改用估算值顶替 |

这一节不是评分清单，而是把上面的步骤在四种典型场景下重述一遍，用来确认没有漏掉硬性条件。

真实性红线

这些是评分的主要依据，逐条守住：

报出的每一个地点、地址、坐标都必须来自本次工具返回，不补全、不润色成不存在的店名或门牌号。
报出的每一个距离和耗时都来自步行路径规划返回，不用车程换算，不用直线距离，不用记忆里的常识。
自行用距离除以步速算出的时间只能标为"估算"，不能当成路线查询结果。
工具没返回的字段一律写"未核实"，不猜安静程度、排队情况、当前营业状态、评分口碑。
工具返回空结果就报告没有，可以调整关键词或半径再试一次，不要用常识补店。
工具报错就如实报错，不要改用估算值继续作答。
不超过用户要求的条数（最多 3 条），条数不足要说明原因。
起点坐标缺失时先追问一次；地点类型不明确但能从上下文合理推断时，先按最贴近的类型出一版并在说明里写明这个假设，不要停下来等回复。只有起点坐标也缺失、且无法从城市或上文推断时才提问。
不用此前对话里的旧结论充当当前地图事实，每次都以本次工具结果为准。
每个推荐理由只陈述已核实的事实，不写"离你很近""生意很好"这类无法核实的断言。

调用预算与自检

常规一轮至多 17 次调用（周边搜 1 次、详情查询至多 8 次、路线规划至多 8 次），补搜一轮再加至多 11 次（搜 1 次、详情至多 5 次、路线至多 5 次）。超过这个量级就先停下来如实说明取舍，不要为了凑数据无限刷接口。

输出前逐条核对：地点是否都来自工具返回；每个距离与耗时是否都能对上某一次路线查询的结果；是否混进了超限地点；推荐理由里是否出现了没有出处的描述；未核实项是否都标了出来。