oebb-scotty（奥地利铁路规划API）Skill 是什么？

奥地利铁路规划API（ÖBBScotty）Skill：一句话查清奥地利火车行程、站台与延误

核心结论速览

• 一句话定位：这是一个把奥地利联邦铁路（ÖBB）官方 HAFAS 行程引擎接入 AI 的技能，让 AI 直接帮你查车次、查站台、查换乘、查中断，而不用你手动点网页。
• 四种核心能力：车站搜索（LocMatch）、行程规划（TripSearch）、车站时刻表（StationBoard）、服务警报（HimSearch），覆盖 ÖBB 列车、S-Bahn、区域列车及邻国连接。
• 返回结构化数据：所有结果是 JSON，包含计划时间、实时时间、站台、换乘次数、列车名与方向，便于二次加工、写进程序或直接汇总成人话。
• 上手门槛中等：不需要申请商业地图 API 密钥，但需要理解固定的请求头、lid 位置 ID 与 prodX 产品索引这几个关键概念。
• 最适合谁：做差旅系统 / 行程助手的开发者，以及经常跑奥地利、需要精确到站台与实时延误的出行用户。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息

项目	内容
技能中文名	奥地利铁路规划API（ÖBBScotty）Skill
技能英文名	oebb-scotty
技能 ID	13673

它解决什么问题

奥地利铁路的实时信息分散在 ÖBB 官方 Scotty 网页与 App 里：想查「维也纳中央车站到萨尔茨堡中央车站明天早上 8 点之后有哪些直达车、在第几站台、有没有晚点」，通常要在网页里反复点选、翻页、抄写。而这个技能把背后的 HAFAS mgate 接口封装成 AI 可调用的能力：你只要用自然语言提问，AI 负责组织请求、解析结果、汇总成一段中文行程建议。对开发者而言，它省掉了「找接口、猜参数、处理嵌套 JSON」的前期摸索。

一键安装的思路与步骤

1. 确认安装前提：你的 AI 客户端 / Agent 环境需要支持「技能（Skill）」机制，并且允许发起对外的 HTTPS 请求（本技能访问的是 https://fahrplan.oebb.at/bin/mgate.exe）。离线环境、纯本地模型且无联网能力的场景不适用。
2. 找到技能入口：在所用平台的技能市场或技能管理面板中，使用技能 ID 13673，或用英文名 oebb-scotty、中文名「奥地利铁路规划API（ÖBBScotty）」进行检索。具体安装命令、按钮名称与面板路径以官方说明为准，不同客户端存在差异。
3. 一键添加并启用：安装后确认该技能处于「已启用」状态。若平台支持权限控制，请授予其网络访问权限。
4. 验证是否生效：直接用自然语言提问测试，例如「帮我查一下维也纳中央车站（Wien Hbf）到萨尔茨堡中央车站（Salzburg Hbf）明天 08:00 之后的前 5 班车」。如果 AI 返回了车次名、出发到达时间、站台与换乘次数，说明技能已正常接管请求。
5. 失效排查：若 AI 只是泛泛而谈而没有具体车次，通常是技能未被调用（检查是否启用）、网络被拦截，或提问中缺少城市/时间等关键要素。

2. 该技能的主要功能和特点

• 车站/地点搜索（LocMatch）：按名称模糊匹配车站、地址、兴趣点，返回 lid（行程 ID 字符串）、extId（外部车站 ID）、坐标与产品类别位掩码。支持 maxLoc 限制返回条数，类型可选 S（车站）、A（地址）、P（兴趣点）。
• 行程规划（TripSearch）：在两个位置之间搜索连接，支持向前（outFrwd: true）或向后搜索、指定出发日期（YYYYMMDD）与时间（HHMMSS）、指定返回连接数（numF）、是否返回中途站（getPasslist）。
• 车站时刻表（StationBoard）：查询某车站的出发（DEP）或到达（ARR）列表，可指定时间起点与最大车次数（maxJny），返回列车名、方向与站台。
• 服务警报（HimSearch）：获取当前的中断、施工、座位减少等服务信息，返回标题、正文、起止日期与优先级。
• 细到「产品类别」的过滤能力：通过 jnyFltrL 的位掩码组合（1=ICE/RJX 高速、2=IC/EC、4=NJ 夜间、8=D/EN、16=REX/R 区域特快、32=S-Bahn、64=巴士、128=轮渡、256=U-Bahn、512=电车），可以只查直达高速列车，也可以把市内公交、电车一起算进来；填 1023 等于全选。
• 实时信息字段：响应中除计划时间 dTimeS / aTimeS 外，还提供实时时间 dTimeR / aTimeR（可用时返回），可据此判断是否晚点。
• 结构化程度高：结果包含换乘次数 chg、总时长 dur、出发/到达站台 dPltfS.txt / aPltfS.txt，直接用 jq 就能裁出简洁摘要。

和普通工具比强在哪：普通地图 App 面向人手点，返回的是渲染好的页面；本技能返回的是可编程的原始结构，能精确控制「车型过滤、时间窗、返回数量、是否含中途站」，也便于程序化地并入差旅审批、行程卡片、车站大屏等自有流程。

3. 如何使用该技能？

步骤 1：记住固定的请求骨架

所有请求都是向 https://fahrplan.oebb.at/bin/mgate.exe 发 POST JSON，且必须带上固定的公共头（id、ver、lang、auth、client、formatted），再在 svcReqL 里写具体方法。公共头中的 lang 决定返回文本语言，deu 为德语。

步骤 2：先查车站，拿到 lid

curl -s -X POST "https://fahrplan.oebb.at/bin/mgate.exe" \
  -H "Content-Type: application/json" \
  -d '{
    "id":"1","ver":"1.67","lang":"deu",
    "auth":{"type":"AID","aid":"OWDL4fE4ixNiPBBm"},
    "client":{"id":"OEBB","type":"WEB","name":"webapp","l":"vs_webapp"},
    "formatted":false,
    "svcReqL":[{
      "req":{"input":{"field":"S","loc":{"name":"Wien Hbf","type":"ALL"},"maxLoc":10}},
      "meth":"LocMatch"
    }]
  }'

返回结果中重点是 lid（如 A=1@O=Wien Hbf (U)@X=16377950@Y=48184986@U=181@L=1290401@）和 extId（如 1290401）。下一步行程查询就用这个 lid。

步骤 3：规划行程

"svcReqL":[{
  "req":{
    "depLocL":[{"lid":"A=1@O=Wien Hbf@L=8103000@","type":"S"}],
    "arrLocL":[{"lid":"A=1@O=Salzburg Hbf@L=8100002@","type":"S"}],
    "jnyFltrL":[{"type":"PROD","mode":"INC","value":"1023"}],
    "getPasslist":true,
    "outDate":"20260109",
    "outTime":"080000",
    "outFrwd":true,
    "numF":5
  },
  "meth":"TripSearch"
}]

outDate 必须是 YYYYMMDD，outTime 必须是 HHMMSS（8 点写作 080000），这是最常见的报错来源。

步骤 4：用 jq 把冗长响应压成一张表

原始响应嵌套很深，可用技能文档提供的 jq 过滤器裁剪：

... | jq '
  .svcResL[0].res as $r | $r.common.prodL as $prods |
  [$r.outConL[] | {
    dep: .dep.dTimeS, arr: .arr.aTimeS,
    depPlatform: .dep.dPltfS.txt, arrPlatform: .arr.aPltfS.txt,
    dur: .dur, chg: .chg,
    legs: [.secL[] | select(.type == "JNY") | {
      train: $prods[.jny.prodX].name, dir: .jny.dirTxt,
      dep: .dep.dTimeS, arr: .arr.aTimeS
    }]
  }]'

输出形如「S 7 / 方向 Flughafen Wien Bahnhof / 21:39 发 / 22:11 到 / 全程 32 分钟 / 0 次换乘」的简洁摘要。

步骤 5：查车站出发到达

把 type 设为 DEP 或 ARR，配合 stbLoc、date、time、maxJny，即可得到类似「RJX 662，方向 Salzburg Hbf，08:00，8A-B 站台」的结果，适合做车站大屏或接驳提醒。

步骤 6：查中断与警报

HimSearch 用 himFltrL（如产品过滤 255）加 maxNum，返回带 head（标题）、text（详情）、sDate / eDate（起止日期）的警报列表。

步骤 7：处理错误

检查响应中的 err 字段：OK 表示成功，PARSE 表示请求格式无效，NO_MATCH 表示未找到结果，具体原因看 errTxt。

省事的小抄：常用车站 extId 可直接复用——Wien Hbf 8103000、Wien Meidling 8100514、Wien Westbahnhof 8101003、Salzburg Hbf 8100002、Linz Hbf 8100013、Graz Hbf 8100173、Innsbruck Hbf 8100108、Klagenfurt Hbf 8100085、St. Pölten Hbf 8100008、Wr. Neustadt Hbf 8100516。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
奥地利铁路规划API（ÖBBScotty）Skill	面向 AI Agent 的奥地利铁路数据接口封装	车站搜索、行程规划、车站时刻表、服务警报，支持车型位掩码过滤与实时时间	需支持 Skill 的 AI 环境并允许联网；需理解固定请求头与 lid / prodX 概念，约半天可上手	差旅助手、行程卡片、车站信息展示、开发调试	优势：数据结构化、过滤粒度细、无需自建商业密钥；不足：参数格式严格，返回文本多为德语，需自行转换
ÖBB 官方 Scotty 网页 / App	面向普通乘客的官方查询工具	行程查询、实时延误、站台、票务跳转	零门槛，打开即用	个人出行随手查	优势：官方权威、有购票闭环；不足：无法批量调用、结果不利于程序化处理，不适合集成进自有系统
通用地图类公共交通查询	面向大众的多模式路线规划	火车+公交+步行混合路径、地图可视化	门槛低，多数需申请 API 密钥或有调用配额限制	门到门导航、跨交通方式换乘	优势：覆盖广、可视化好；不足：对奥地利区域列车、S-Bahn 的产品级过滤与站台细节不如本地铁路接口精细
自建爬虫 / 手工整理	团队内部自研方案	抓取网页、人工抄录	开发与维护成本高，页面改版即失效	一次性数据采集	优势：完全可控；不足：稳定性差、不实时、易触发反爬，长期维护成本高

选择建议：如果只是个人偶尔坐一次奥地利火车，官方 App 最省事；如果要把铁路信息嵌进产品、或让 AI 自动化处理行程，本技能是更合适的中间层。

5. 该技能的典型应用场景与实际体验情况

场景一：跨境出差人员的行程编排 角色是常跑中东欧的商务人士，痛点是「维也纳落地后要接萨尔茨堡的会，还得留出换乘与站台找路的时间」。使用方式是直接问 AI：「明天 8 点后维也纳中央车站到萨尔茨堡中央车站的直达车，要有站台和到达时间」。实际体验：一次提问即可拿到多条连接的时间、站台、时长与换乘次数，比在网页逐条点开快得多；注意 lang=deu 时方向名是德语站名，习惯后反而更准。

场景二：差旅系统或行程助手的开发集成 角色是后端或 Agent 开发者，痛点是「不想为了查奥地利火车去接一套重型商业出行 API」。使用方式是先 LocMatch 标准化站点，再 TripSearch 拿连接，最后用 jq 或代码裁剪成自定义结构。实际体验：接口响应稳定、字段清晰，最容易踩的坑是列车名要经 common.prodL[prodX].name 解析——prodX 只是数组下标，直接当车次名会得到「0」这种无意义值。

场景三：车站接驳与通勤信息展示 角色是本地通勤者或接站人员，痛点是「到站后不知道下一班 S-Bahn 在几号站台」。使用方式是 StationBoard 指定车站、时间与 type: DEP，取 maxJny 条出发信息。实际体验：站台字段 dPltfS.txt 会给出类似「8A-B」「3A-B」的分段站台标识，比自己找更精确；注意日期时间格式必须补零对齐。

场景四：行程前的风险预判 角色是需要赶会议或转机的人，痛点是临时施工、座位减少导致计划被打乱。使用方式是 HimSearch 拉取当前警报，重点看 head 与 text、以及 sDate / eDate 覆盖的日期范围。实际体验：警报是自由文本（德语为主），需要 AI 帮忙翻译归纳；它提供的是「知情」，不替代现场广播与官方公告。

整体上手感受：难度属于「中等偏易」——请求骨架固定，理解 lid、位掩码、prodX 三个概念后就顺畅；效果上结构化程度高、字段覆盖全；主要注意事项是时间格式严格、车次名需索引解析、返回文本语言取决于 lang。

6. 该技能能为用户带来的价值

• 把「点网页」变成「说一句话」：原本需要在官网反复筛选、翻页、抄写的查询，现在用自然语言描述即可完成，单次行程调研从数分钟压缩到几秒。
• 降低集成门槛：无需自建爬虫、无需维护页面解析规则，也不必先接入一套重型商业出行平台，用一个技能 ID 就能把奥地利铁路数据引入自有流程。
• 提升信息精度：站台号、换乘次数、实时时间、车型过滤这些「颗粒度」信息，直接决定赶车与接驳是否顺利，而通用路线工具往往只给到车次层级。
• 可量化的收益方向：批量查询不再受人工翻页速度限制；行程助手能把「查车次—算时长—写进行程卡」串成自动流程；运维侧省去了爬虫随网页改版而失效的反复修复成本。
• 长期价值：接口基于稳定的 HAFAS mgate 体系，字段命名与结构一致，一旦接入即可长期复用；配合 AI 的自然语言能力，团队成员不必记住参数细节也能自助查询。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ 在支持 Skill 机制的 AI 客户端中，用技能 ID 13673 或英文名 oebb-scotty 检索并一键添加、启用即可，安装命令与面板入口以官方说明为准。技能本身调用的是 ÖBB 公开的行程查询接口，是否需要额外付费请以你所使用平台的官方说明为准。

Q2：我只想查「维也纳到萨尔茨堡明天早上的火车」，需要懂 JSON 吗？ 不需要。技能装好后，直接用自然语言向 AI 提问即可，AI 会代你构造请求。只有当你打算自己写脚本批量查询时，才需要理解 svcReqL、lid 这些结构。

Q3：为什么查到的车次名显示成数字？ 这是最常见的坑。旅程段里的 prodX 只是 common.prodL[] 数组的下标，不是车次名，必须先取 common.prodL[prodX].name 才能得到「RJX 662」「S 7」这类真实车次。

Q4：返回结果全是德语，能改成中文吗？ 请求头里的 lang 决定返回语言，技能文档示例使用 deu（德语），所以站名、方向、警报正文多为德语。实际使用中可以让 AI 在汇总阶段翻译成中文；奥地利车站的德语原名反而更利于与现场标识核对。

Q5：它和官方 App、通用地图工具怎么选？ 个人偶尔出行、需要直接买票，用官方 App 最省事；需要门到门多交通方式导航，用通用地图工具；而需要把奥地利铁路数据嵌进自己的产品、或让 AI 自动批量处理行程，本技能更合适——它能精确控制车型过滤、时间窗与返回数量，并给出结构化字段。