Map Route Reader
产品定位
把“地图路线查询”变成更像结果型产品的 skill:不是只说个大概时间,而是尽量把真实路线读出来,整理成用户可以立刻参考的出行方案。
一句话卖点
直接读取高德 / 百度地图上的真实路线结果,优先返回用户能照着走的公交、地铁、打车或步行方案。
为什么更有下载欲望
很多同类路线能力看起来很强,但实际要:
- - 配 API
- 补配置
- 自己拼接流程
- 最后还不一定能直接给出可走路线
这个 skill 主打的是:
- - 尽量直接可用
- 优先读真实地图结果
- 优先给可执行路线,不给空泛判断
- 用户问哪条线更好时,会真的把两条路线拉出来做对比
- 重点不是给模糊估计,而是给可直接拿去用的路线参考
你装它,想得到的是什么
- - 少一点“大概多久”的废话
- 多一点“从哪上车、哪换乘、哪下车”的真实结果
- 问打车 / 地铁 / 公交哪个更省事时,得到能直接参考的答案
Use this skill when the user asks for:
- - how to get from A to B
- public transit routes
- driving time
- walking time
- which station to transfer at
- whether taxi is faster
- whether a specific alternate route/line would be better
- route comparisons such as “走 14 号线会不会更好”
Goal
Return a route the user can actually follow.
Do not stop at vague estimates when a real route can be extracted.
Priority:
- 1. exact route from a real map result
- if the user proposes an alternate route/line, extract that route too and compare side by side
- if exact route cannot be extracted, explain precisely where extraction failed and switch to the user-browser map tab via Browser Relay
- only as a temporary fallback, give a clearly-labeled estimate
Preferred workflow
0) For Amap, prefer uriapi route pages with lnglat when coordinates are available
If you can get origin/destination coordinates, prefer opening a direct Amap route URL like:
INLINECODE2
Why:
- - this bypasses wrong default city context
- the route card often renders directly in page text
- total duration / walking distance / fare / line names can often be extracted from INLINECODE3
1) Try normal read first
- - Use browser on public map pages first.
- Prefer Amap or Baidu Maps for China routes.
- Try direct route pages with origin/destination query params.
- If the page exposes the full route card, extract:
- total time
- total walking time if visible
- number of transfers
- station names / line names
- final arrival station or walking segment
1.5) On Amap route pages, extract hidden detail siblings
After the recommended route card renders, the full step-by-step transit detail may exist in the hidden sibling node right after the current
.planTitle (for example an
ol.p_route).
Do not stop at total duration. Read that hidden detail block and extract:
- - walking segment distance and minutes
- line name and direction
- boarding station and exit/gate info
- number of stops
- transfer station
- alighting station and exit number
- final walking segment to destination
- approximate duration of each transit segment when the page exposes enough information to infer it
2) If the map page needs interaction
If the site asks to confirm the start/end place, or the route card is hidden behind dynamic UI:
- - keep using browser
- interact to confirm the correct start/end point
- prefer the first recommended public transit route unless the user asked for fastest/least walking/least transfers
3) For China map sites, prefer the user's real map tab when city context matters
For Amap/Baidu route pages, the isolated browser may resolve the wrong city or fail to expand the route card.
If the page shows the wrong city, cannot resolve start/end places, or keeps asking to choose the correct place, switch early to the user's map tab via Browser Relay and read the live route result there.
4) If normal browser still cannot read the real route
Switch to the user’s browser tab via Browser Relay.
- - Ask the user to open the target map route page in Chrome.
- Ask them to click Browser Relay on the exact map tab.
- Then read the real route card from that tab.
Comparison rule
If the user asks whether a specific route/line would be better, for example:
- - “走 14 号线会不会更好”
- “打车会不会更方便”
- “xx 这么走是不是更好”
then you must:
- 1. keep the current recommended route
- extract the user-specified route too
- present a side-by-side comparison
Do not guess. Do not answer from intuition alone.
Do not say “应该不会” or “大概率更慢” unless the alternate route has been pulled out and compared.
Output format
For a single route, return in this structure:
- - 起点:...
- 终点:...
- 方式:公交 / 地铁 / 打车 / 步行
- 预计总时长:...
- 推荐路线:...
- 换乘:...
- 每段步骤:...
- 下车后:...
- 备注:如有不确定,明确写出来
If route detail is available, include:
- - 上车站
- 下车站
- 换乘站
- 出口
- 每段步行距离与时间
- 每段乘车站数
- 每段乘车大约多久
For a route comparison, return side-by-side:
- - 方案 A
- 方案 B
- 总时长
- 步行距离
- 换乘次数
- 线路结构
- 哪个更快 / 哪个更省事 / 哪个更少走路
Rules
- - Do not stop at “I’ll check” or “probably around ...” unless exact extraction has genuinely failed.
- If exact extraction failed, say which step failed.
- For map queries, a user-visible answer should try to be route-usable.
- If the user corrected the place name, restart from the corrected place immediately.
- If the user corrected the place name, never reuse the old route result as if it applied to the corrected place.
- For comparison questions, do not brain-fill the alternate route. Pull it out, then compare.
地图路线读取器
产品定位
将“地图路线查询”转变为更像结果型产品的技能:不只是给出大概时间,而是尽量读取真实路线,整理成用户可以立即参考的出行方案。
一句话卖点
直接读取高德/百度地图上的真实路线结果,优先返回用户能照着走的公交、地铁、打车或步行方案。
为什么更有下载欲望
很多同类路线能力看起来很强,但实际需要:
- - 配置 API
- 补充配置
- 自行拼接流程
- 最后还不一定能直接给出可走路线
这个技能主打的是:
- - 尽量直接可用
- 优先读取真实地图结果
- 优先给出可执行路线,不提供空泛判断
- 用户询问哪条线路更好时,会真正拉出两条路线进行对比
- 重点不是给出模糊估算,而是提供可直接使用的路线参考
你安装它,想得到的是什么
- - 少一些“大概多久”的废话
- 多一些“从哪上车、哪换乘、哪下车”的真实结果
- 询问打车/地铁/公交哪个更省事时,得到可直接参考的答案
当用户询问以下问题时使用此技能:
- - 如何从 A 到 B
- 公共交通路线
- 驾车时间
- 步行时间
- 在哪个站换乘
- 打车是否更快
- 某条特定备选路线/线路是否更好
- 路线对比,例如“走 14 号线会不会更好”
目标
返回用户可以实际遵循的路线。
当可以提取真实路线时,不要停留在模糊估算上。
优先级:
- 1. 来自真实地图结果的精确路线
- 如果用户提出备选路线/线路,也提取该路线并进行并排对比
- 如果无法提取精确路线,准确说明提取失败的位置,并通过浏览器中继切换到用户浏览器地图标签页
- 仅作为临时备选方案,给出明确标注的估算结果
首选工作流程
0) 对于高德地图,当有坐标时优先使用带 lnglat 的 uriapi 路线页面
如果你能获取起点/终点坐标,优先打开高德地图直接路线 URL,例如:
https://ditu.amap.com/dir?type=bus&policy=2&from[lnglat]=
&from[name]=...&to[lnglat]=&to[name]=...&src=uriapi&innersrc=uriapi&dateTime=now
原因:
- - 这可以绕过错误的默认城市上下文
- 路线卡片通常直接渲染在页面文本中
- 总时长/步行距离/票价/线路名称通常可以从 document.body.innerText 中提取
1) 先尝试正常读取
- - 首先在公共地图页面上使用浏览器。
- 中国路线优先使用高德地图或百度地图。
- 尝试使用带起点/终点查询参数的直接路线页面。
- 如果页面显示了完整路线卡片,提取:
- 总时间
- 总步行时间(如果可见)
- 换乘次数
- 站名/线路名称
- 最终到达站或步行段
1.5) 在高德地图路线页面上,提取隐藏的详细信息兄弟节点
在推荐路线卡片渲染后,完整的逐步换乘详情可能存在于当前 .planTitle 之后的隐藏兄弟节点中(例如 ol.p_route)。
不要只停留在总时长上。读取该隐藏详情块并提取:
- - 步行段距离和分钟数
- 线路名称和方向
- 上车车站和出口/闸口信息
- 站数
- 换乘车站
- 下车车站和出口编号
- 最终步行段到目的地
- 当页面提供足够信息可推断时,每段换乘的大致时长
2) 如果地图页面需要交互
如果网站要求确认起点/终点位置,或路线卡片隐藏在动态 UI 后面:
- - 继续使用浏览器
- 进行交互以确认正确的起点/终点
- 除非用户要求最快/步行最少/换乘最少,否则优先选择第一条推荐的公共交通路线
3) 对于中国地图网站,当城市上下文重要时,优先使用用户的真实地图标签页
对于高德/百度路线页面,隔离的浏览器可能解析到错误的城市或无法展开路线卡片。
如果页面显示错误城市、无法解析起点/终点位置,或一直要求选择正确位置,则尽早通过浏览器中继切换到用户的地图标签页,并读取那里的实时路线结果。
4) 如果正常浏览器仍然无法读取真实路线
通过浏览器中继切换到用户的浏览器标签页。
- - 要求用户在 Chrome 中打开目标地图路线页面。
- 要求他们在确切的地图标签页上点击浏览器中继。
- 然后从该标签页读取真实路线卡片。
对比规则
如果用户询问某条特定路线/线路是否更好,例如:
- - “走 14 号线会不会更好”
- “打车会不会更方便”
- “xx 这么走是不是更好”
那么你必须:
- 1. 保留当前推荐的路线
- 同时提取用户指定的路线
- 提供并排对比
不要猜测。不要仅凭直觉回答。
不要说“应该不会”或“大概率更慢”,除非备选路线已被拉取并进行对比。
输出格式
对于单条路线,按以下结构返回:
- - 起点:...
- 终点:...
- 方式:公交/地铁/打车/步行
- 预计总时长:...
- 推荐路线:...
- 换乘:...
- 每段步骤:...
- 下车后:...
- 备注:如有不确定,明确写出来
如果路线详情可用,包括:
- - 上车站
- 下车站
- 换乘站
- 出口
- 每段步行距离与时间
- 每段乘车站数
- 每段乘车大约多久
对于路线对比,并排返回:
- - 方案 A
- 方案 B
- 总时长
- 步行距离
- 换乘次数
- 线路结构
- 哪个更快/哪个更省事/哪个更少走路
规则
- - 除非精确提取确实失败,否则不要停留在“我查一下”或“大概在……”上。
- 如果精确提取失败,说明哪一步失败。
- 对于地图查询,用户可见的答案应尽量做到路线可用。
- 如果用户更正了地名,立即从更正后的地点重新开始。
- 如果用户更正了地名,切勿将旧的路线结果当作适用于更正后的地点。
- 对于对比问题,不要脑补备选路线。拉取出来,然后进行对比。