前言¶

给 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