前言¶

給 Agent 寫旅遊行程，常見做法是把需求丟進一個通用對話裏，讓它輸出一段文本，再手工粘到文檔裏。結果往往是：路線順序隨手排，景點和餐廳的來源說不清，住宿看不出是哪家平臺在賣，打車距離更是沒算過。

下面介紹的旅遊規劃器（基於需求驅動）是一個面向國內目的地的多日行程生成 Skill，座標 @user_e0c9a7b3/travel-itinerary-planner-jyj，走的是需求調研與多源比價的路子：先收集訴求，再按維度去找候選，最後渲染成一個能直接打開的單文件 HTML。

這是什麼¶

一句話定位：把「出發地 / 交通 / 時間 / 飲食 / 住宿 / 遊玩偏好 / 預算」這些口語化訴求，編譯成一份帶地圖標點、自駕時長矩陣和懸浮攻略卡的可交付行程頁面。

• 出品方：user_e0c9a7b3
• 來源：community
• 分類：life-service
• 版本：1.0.0
• 官方地址：https://api.skillhub.cn/user_e0c9a7b3/travel-itinerary-planner-jyj
• SkillHub 頁面：https://www.skillhub.cn/skills/user_e0c9a7b3/travel-itinerary-planner-jyj

它解決的不是「生成一段像話的文案」，而是把調研結果落到一個可交付的載體上，並且讓編號、時長、比價這些信息固定在頁面結構裏，不隨模型發揮而漂移。

核心功能¶

按官方簡介，能力分四步。

1、訴求收集。固定七個維度：出發地、交通方式、時間、飲食偏好、住宿偏好、遊玩偏好、預算。這些字段被當作生成路線的約束條件，而不是事後補充說明。

2、分維度調研候選庫。不同維度走不同來源，避免全部依賴同一個檢索入口：

美食：高德掃街榜
景點：小紅書
住宿：攜程 / 去哪兒 / 同程 比價

這樣做的實際價值是住宿項能看到跨平臺價差，而不是隻拿到某個平臺的搜索結果。

3、路線生成。在候選集上產出默認路線，即一份多日行程的骨架，用戶再基於它做調整。

4、單文件 HTML 渲染。產出物包含三類結構：

騰訊地圖編號標點
自駕時長矩陣
懸浮攻略卡

編號標點用於按順序對照地圖，自駕時長矩陣用來說明各段之間的車程是否合理，懸浮攻略卡承載單個點位的詳細攻略。三者都寫在單個 HTML 文件裏，沒有外部依賴，收到文件即可打開。

按官方定位，調用時機是：當用戶要制定多日旅遊行程 / 旅遊攻略（尤其國內目的地）時。

安裝與啓用¶

已在 SkillHub 頁面提供，座標即包名：

@user_e0c9a7b3/travel-itinerary-planner-jyj

獲取入口放在官方地址中：

https://api.skillhub.cn/user_e0c9a7b3/travel-itinerary-planner-jyj

頁面入口：

https://www.skillhub.cn/skills/user_e0c9a7b3/travel-itinerary-planner-jyj

頁面標註 requires_api_key=true，說明啓用前需要配置 API Key。具體配置字段名與位置在已抓取資料中沒有給出，啓用前以官方頁面爲準，不要照抄下面的佔位寫法：

# 示例寫法，字段名未覈實，僅示意
api_key=<你的 key>

關於 Cursor、Codex CLI、Claude Code 的差異，已抓取資料未提到任何工具專屬說明，這裏不區分。該 Skill 基於通用 SKILL.md 格式，通常按各自工具的 Skill 目錄或插件機制接入，具體路徑以所使用工具的文檔爲準。

典型用法¶

官方簡介描述的流程是需求驅動，沒有給出具體城市或參數格式的例子。下面按這七步展開，每一維都對應官方列出的訴求字段，實際值由用戶給出：

1. 出發地
2. 交通
3. 時間
4. 飲食
5. 住宿
6. 遊玩偏好
7. 預算

操作順序建議：

1、一次把七個維度給齊。信息不全時生成的路線缺少約束，住宿比價也難落到具體價位。

2、確認候選集。按美食、景點、住宿三個維度分別拿到結果後再進入路線生成，不要跳過這步直接要終稿——跳過的話住宿比價就沒意義了。

3、拿到單文件 HTML。檢查三類結構是否齊全：編號標點能否對應騰訊地圖、自駕時長矩陣是否覆蓋相鄰點位、懸浮攻略卡是否每點一份。

4、在默認路線上做調整。路線是默認值，按當天體力與營業時間調整順序是常見操作。

調用時機按官方說法執行：用戶要制定多日旅遊行程 / 旅遊攻略（尤其國內目的地）時調用。需要說明，具體的對話輪次、參數名與返回格式在已抓取資料中沒有記錄，接入前需自行確認。

適用場景與注意¶

適合的場景：國內目的地、多日行程、需要可交付文件而非聊天記錄的用戶。對「幫我想三個北京的景點」這類輕量提問，這套流程偏重。

需要注意的點：

1、候選庫本身有平臺屬性。美食依賴高德掃街榜，景點依賴小紅書，意味着結果帶有這些平臺的排行與內容生態特徵，偏網紅或偏商業化都可能發生。

2、住宿比價只覆蓋攜程、去哪兒、同程，不含飛豬、美團等渠道，不能完全當作全網最低價。

3、自駕時長矩陣只覆蓋自駕，如果用戶全程地鐵，需要人工換算或另行確認。

4、數據口徑要看清。當前公開數據是評分 100000、下載 919、安裝 0。評分不是傳統的 5 分制，更像平臺內部的統計口徑，不宜直接當作質量背書；安裝數爲 0，說明社區調用量還很低，踩坑反饋少，結論要自己跑一遍再下。

結尾¶

這個 Skill 的價值不在生成文案，而在把需求調研、多源比價和可交付頁面串成一條固定流程：訴求驅動候選集，候選集驅動路線，路線渲染成 HTML。對國內多日行程這種信息密度高、交付格式明確的場景，算是把重複勞動交給了 Agent。

官方地址：https://api.skillhub.cn/user_e0c9a7b3/travel-itinerary-planner-jyj