TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
12306 MCP 開源工具實測：把中國鐵路餘票查詢接進 AI 助手
開源的 12306 MCP 伺服器把中國大陸鐵路的餘票、票價、停靠站與轉乘查詢包成 AI 助手能直接呼叫的工具，實測從台灣直連 2.26 秒查得北京到上海 54 班列車與各席別票價。它只查詢、不訂票，自架前要看清非官方邊界與新舊映像檔差異。
用 AI 摘要這篇文章：
「北京到上海，9 月 10 號」這個查詢，2026 年 9 月我在本機用 MCP 協定打給一個自架的開源服務，2.26 秒後資料回來：54 班列車。G547 六點十八分從北京南發車、十二點十一分到上海虹橋，商務座剩 2 張，一等座、二等座都有票；緊接在後的 G1 全程四小時五十四分，快了將近一個小時。連 G547 二等座 795 元人民幣的票價都一起帶回來，資料來自 12306 官方查詢端點的即時回應。
結論先講：常到中國大陸出差旅遊、或想在自己應用裡加火車查詢的人，這個叫 mcp-server-12306 的開源專案值得裝。它把 12306 官方網頁在用的公開查詢介面包成 MCP 工具，Claude Desktop、Cursor 這類支援 MCP 的 AI 用戶端接上就能查餘票、票價、停靠站與轉乘方案，過程不用登入帳號。但它只查詢、不訂票，走的是非官方包裝路線，授權文字還自相矛盾，這些邊界後面集中攤開。專案採 MIT 授權、有 378 顆星，2026 年 8 月下旬仍在更新。
實際打一輪：餘票、票價、車站搜尋回的都是真資料
整輪測試在 macOS 上進行：複製倉庫、用 uv 安裝依賴、啟動服務，健康檢查端點回報載入了 3,384 個車站；接著照 MCP 標準流程完成握手，逐個呼叫工具。網路是台灣一般的家用環境，全程直連，沒有掛代理。這點值得記下來：我這一輪從台灣的網路直連是通的，不必先想翻牆問題。
餘票查詢回來的第一手資料長這樣：日期 2026-09-10、北京到上海共 54 班可搭，每班自帶出發抵達時刻、全程時間與各席別票況，清晨時段的五班如下：
| 車次 | 出發→抵達 | 全程 | 商務座 | 一等座 | 二等座 |
|---|---|---|---|---|---|
| G547 | 北京南 06:18 → 上海虹橋 12:11 | 5 小時 53 分 | 剩 2 張 | 有票 | 有票 |
| G1 | 北京南 06:30 → 上海虹橋 11:24 | 4 小時 54 分 | 售完 | 有票 | 有票 |
| G3 | 北京南 06:52 → 上海 11:33 | 4 小時 41 分 | 售完 | 有票 | 有票 |
| G565 | 北京南 07:07 → 上海虹橋 13:12 | 6 小時 5 分 | 剩 3 張 | 有票 | 有票 |
| G549 | 北京南 07:13 → 上海虹橋 13:03 | 5 小時 50 分 | 剩 2 張 | 有票 | 有票 |
這種粒度正是接 AI 助手需要的素材：模型拿到 54 班的時刻與票況，才答得了「不想太早出發、但要趕下午兩點的會，哪班最穩」這種帶條件的問題，而不只是把你導去官網再自己濾一次。對寫腳本的人，同樣的資料可以直接進排程或通知系統。
車站搜尋給的驚喜是輸入門檻低。輸入 shanghai，回上海、上海南、上海虹橋等五個站，每站附電報碼與拼音縮寫；查票時直接打中文站名也行，「北京」「上海」這種口語輸入，服務自己換算成車站代碼，不必先記 VNP、SHH 這些三字碼。3,384 個車站的對照表直接包在程式裡，站名換算離線就能做，倉庫另附更新腳本，2026 年 8 月還有兩筆車站資料的更新記錄，這種資料檔會陳舊的專案，看維護紀錄比看星數準。七個工具的分工如下：
| 工具 | 查什麼 | 本次實測 |
|---|---|---|
| query-tickets | 餘票、車次、時刻與各席別剩票 | 有 |
| query-ticket-price | 各車次各席別即時票價 | 有 |
| search-stations | 車站模糊搜尋（中文、全拼、簡拼、三字碼） | 有 |
| query-transfer | 一次轉乘方案與等候時間 | 未測 |
| get-train-route-stations | 指定列車全部停靠站與到發時刻 | 未測 |
| get-train-no-by-train-code | 車次號換官方唯一編號，查停靠站的前置步驟 | 未測 |
| get-current-time | 指定時區的當下時間 | 有 |
寫腳本的人要注意一件事：回傳的站名與票況字串是簡體原文，例如站名與「有票」「無票」的標示都維持 12306 原始寫法。接 AI 助手時模型通常會自動轉成繁體再回給你，但要把回應寫死解析進自己系統，就得先處理這層字元差異。
同樣把查詢鏈補齊的還有轉乘與停靠站兩個工具：直達班次售完或時刻不接時，轉乘查詢能拉出一次中轉的組合與等候時間；停靠站查詢則給出列車沿途每一站的到發時刻，判斷「這班到底有沒有停我要下車的站」不用再猜。這兩個我這輪沒有實測，說明文件對參數與回應格式都有單獨文件，接之前先照著文件打一輪最穩。
「明早出發」誰在算：工具只給時鐘，日期是模型的事
README 把時間工具包裝成支援相對日期計算，一些介紹文更直接寫成「說明早就能查明早」。打開原始碼看，這個工具只做一件事：回當下時間。我指定台北時區，它回 2026-09-05 17:28:21，程式裡不存在任何「明早」「後天」的字串解析。
行銷文字不算騙你，因為相對日期本來就是 AI 用戶端擅長的推理：模型拿到可靠的「今天幾號」，就不會把明早算成昨天。查票又偏偏是日期錯一天就全盤皆錯的應用，模型憑訓練資料猜日期、把週五當成週六的情境，只要發生一次就足夠讓人對整條流程失去信任，這座鐘的存在就是在補這個洞。對使用者的實際意義有兩條：別期待工具內建日期魔法，也別因為輸入「明早」沒有特殊反應就以為它壞了，要驗證就問它今天幾號。另外預設時區是上海，跨時區的排程應用記得明確指定時區，服務收哪個時區字串就回哪個，打錯時區名則靜默回落上海時區。
為什麼不用登入就能查：它只打五個公開端點
從查詢結果往回推它的運作：核心程式裡的端點表只列了五個 kyfw.12306.cn 網址，涵蓋餘票、票價、轉乘、停靠站查詢，加上一個初始化頁面。全部是 12306 網頁版自己在用的公開介面，不需要帳號，不碰訂票，也不經手任何個人資料。每次查詢前先打初始化頁面取得 session cookie，網路失敗自動重試三次，業務錯誤與網路錯誤分開處理，重試間隔一秒。
回應快的原因也在此：餘票查詢回來的是管線符號分隔的長字串，程式按欄位位置切出車次、時刻與各席別剩票，沒有瀏覽器、沒有頁面渲染，一道 HTTP 往返就是全部工作。這條路其實有前例可循，先前介紹過的 同花順金融資料 API 就是同一個模式：把中國大陸的官方資料來源包裝成 AI Agent 能直接呼叫的介面，省掉每個人自己逆向端點的功夫。
兩個值得知道的底層細節。請求標頭會把自己偽裝成 Chrome 瀏覽器，因為 12306 的介面本來就是設計給網頁用的；HTTP 客戶端則停用了 TLS 憑證驗證，對 12306 端點的憑證鏈不做檢查。前者是這類工具的常態做法，後者在內網自用無妨，但要把服務開到對外網路之前，值得先弄清楚自己接了什麼。
只查詢、不訂票，這條界線作者自己寫明了
倉庫裡不存在訂票、付款或搶票的程式碼，七個工具全是查詢與輔助。實際用法是查到合適班次後，回 12306 官方 App 或官網完成下單，AI 幫你縮小範圍，交易留在官方管道。README 的免責聲明也比多數同類專案直白，作者明講：僅供學習研究與技術交流、嚴禁商業用途，帳號封禁與資料異常等後果由使用者自負。
授權有個矛盾要點破：倉庫附的 LICENSE 檔是標準 MIT，而 MIT 本身允許商用；免責聲明卻寫嚴禁商業用途。兩份文件都出自作者，發生爭議時以哪份為準有解釋空間。個人使用、公司內部工具看不出障礙，真要做成對外收費的服務，建議先找作者確認，別賭。
非官方包裝的宿命也要認：官方端點一改版，它就會失效。2026 年 7 月就有一個修正轉乘查詢網址的 commit，這種維護會持續發生。把它當「隨時可能需要更新」的依賴來用，心態會健康很多。查詢頻率也自己節制，作者點名封禁風險不是空話，行程查詢、日期提醒這類低頻用法才是它被設計出來的樣子。
資料即時性順帶說清楚：餘票與票價都是查詢當下從官方端點拿的回應，服務本身不快取、不儲存票務資料，每次查詢都是一趟往返。實務上這代表兩件事：即時性跟你自己開官網查相同；尖峰時段 12306 端點變慢時它也會跟著變慢，重試三次仍失敗就回明確的錯誤訊息，不會拿舊資料充數。
映像檔有新舊兩個名字，別照舊教學拉到停更版
網路上的部署教學有個會默默咬人的坑：部分文章寫的 Docker 映像檔名稱是 drfccv/12306-mcp-server，這個名字在 Docker Hub 上已經封存（archived），照抄指令拉到的是停更的舊版；現行映像檔叫 drfccv/mcp-server-12306，2026 年 8 月下旬還在更新，複製倉庫的 git clone 網址同理。兩個名字只差在單字順序，拉錯不會報錯，只會安靜地跑舊版，是最難察覺的那種問題。對照著讀的人請認明 mcp-server-12306 這個順序。
同一批教學還會告訴你它是用 FastAPI 寫的高效能服務。曾經是：2026 年 8 月 7 日的重構把 FastAPI 整個拿掉了，HTTP 層改用 MCP SDK 自帶的傳輸實作，依賴清單縮到四個函式庫（不含 MCP SDK 本身）。功能沒有縮水，但你照著原始碼找 FastAPI 的路由會找不到，網路文章裡那些框架效能的描述也已經過時。這些行為以我實測的 0.5.0.post20260822 版為準。
桌面 AI 一行指令就接上，對外服務開一個埠
接法有兩種。桌面 AI 用戶端走 stdio 模式最省事：執行 uvx mcp-server-12306，在 Claude Desktop 或 Cursor 的 MCP 設定裡加一個 12306 項目指向它，完成。要把查詢能力開給自己的應用或團隊，改跑 HTTP 模式：mcp-12306 指令起一個 8000 埠的服務，/mcp 是協定入口，/health 回車站載入數與連線數，/schema/tools 直接列出七個工具的參數規格，接腳本的人拿這個端點當現成文件用。Docker 一行也能跑，記得用上一段說的現行映像檔名。
兩種模式怎麼選，看你把查詢能力用在哪。只給自己電腦上的 AI 助手用，stdio 就夠，它不佔埠、不對外暴露；要讓多個應用、隊友或外部機器呼叫，才值得開 HTTP 模式，並記得把監聽位址從預設的全部介面改成內網位址。健康檢查端點會回報已載入車站數與活躍連線數，掛在監控裡可以第一時間發現服務掛了或車站資料沒載入。
我這輪測試走的是原始碼路線：複製倉庫、uv sync、啟動腳本，一分鐘內服務就緒，PyPI 上也有同名套件，uvx 走的就是它；Docker Hub 上的現行映像檔累積三千多次拉取，對這類小眾自架工具來說是有人真的在用的量級。這種把單一能力開成自架端點的做法，跟先前介紹過的 OCR Server 把文字辨識開成區網 API 是同一個思路：查詢能力收進自己的基礎設施，用量與可用性自己掌握。
誰該裝：一句話查票值得，要下單的回官方 App
收斂成決策。該裝的人：常在中國大陸移動、行程常臨時調整，希望在 AI 助手裡用一句話完成「明天下午北京到杭州還有二等座的班次」這類查詢；或者在開發聊天機器人、旅遊應用，想省掉自己逆向 12306 端點功夫的開發者。成功的樣子很具體：AI 回報的班次、時刻與票價，拿到 12306 官網對照都一致，像實測裡 795 元的二等座票價那樣。
不該期待的三件事：訂票或搶票，倉庫裡沒有這個功能，下單回 12306 官方 App；台灣車站，3,384 個車站全在中國國鐵路網內（香港只有西九龍一站），台灣在地交通查詢要找 MetroMan 這類收錄台灣與港澳地鐵的工具；企業級的大量查詢，先自己評估節流與條款風險再說。查詢交給它，交易留在官方，界線畫清楚反而好用。
