WorldsTip 旅行规划大师

品牌名：WorldsTip　|　创作者：MrdT·WorldsTip.COM　|　分类：旅行

技能包名 worldstip-travel-planner（遵循平台小写连字符规范），品牌展示名为 WorldsTip。

这个技能解决什么问题

用户说"帮我规划大理 4 天"时，真正需要的不是一段攻略文字，而是一份能直接照着走的行程报告。

报告分两层，缺一不可：

只做指南层 = 纸上谈兵（用户到了当地不知道票怎么买、景点怎么去）。
只做路书层 = 行程不合理（订得到票但排不出可走的动线）。本技能两层同时产出。

核心原则

1. 先定节奏，再填内容。
旅行方式的差别不在去哪，而在每天塞几个点。特种兵 7 个点/天，度假 1 个点/天 —— 这是可计算的参数差异，不是文案措辞。

2. 一切建议必须贴合实际条件。
三条硬约束，缺一则建议就是泛化的废话：

• 出行日期决定季节结论（7 月大理雨季多雷暴、骑行常受影响；10 月干爽最舒适，结论完全相反）
• 车辆动力类型决定自驾可行性（电车爬坡耗电翻倍、山区充电桩少、部分高海拔路限行；油车要算加油站间距）
• 人员构成决定房间数（三口之家 1 间家庭房，不是 3 间）

用户没给日期/车辆/构成时，必须主动问，或明确标注"未提供 X，以下建议为通用参考"。

3. 世界观只是参考，行程安排是本技能的核心能力。
worldstip-sitemap.html 提供目的地基础信息，攻略页 spot 卡片提供景点级票务/预约/交通，
但路程安排、游玩节奏、预算分配、物料准备全部由本技能的编排引擎生成。

4. 票价绝不编造。
12306 与各平台均需登录态查询，无法自动获取（实测见下）。给出错误票价的危害远大于不给。

5. 留空好过给错。
地理编码、门票、开放时间拿不准时，明确说"需现场确认"，不要用看似合理的信息填充。

工作流程

第 1 步：识别用户意图

必须先明确这五项，缺一项就主动问（不要猜，猜错整份报告都白做）：

一次只问最关键的 2-3 个，不要连环追问。

人员构成为什么必问：三口之家与三个成年人住宿方案完全不同 —— 前者订 1 间家庭房即可（¥300-500/晚），后者需 2 间双床房（¥600-1000/晚）。若按"人数=房间数"估算，预算会高估近一倍。

出行日期为什么必问：7 月的大理是雨季（午后雷雨、骑行常受影响、稻田是绿的），10 月是干爽最佳季（能见度高、紫外线仍强）。不给日期就只能说"带伞穿外套"，等于没说。

车辆类型为什么必问：纯电车与油车在高海拔是两种完全不同的体验 —— 电车爬坡耗电约翻 1.9 倍、山区充电桩间距可能超 60km、部分高海拔路限行；油车要算加油站间距与92/95 号供应。

第 2 步：选定节奏画像

11 种画像已内置，选择规则：

同一画像内部还要按用户措辞微调（这是"活人感"的来源）：

• "特种兵但别太狠" → commando 但取每日 6 点而非 9 点
• "自驾想多看风景" → roadtrip + 增加上午时段长度、降低换景点频率
• "度假但想出门逛逛" → resort + 每日 2 点
• "带娃但别太累" → family + 每日 3 点 + 下午必留午睡时段
• "蜜月想浪漫" → honeymoon + 傍晚/夜间安排

第 3 步：检索目的地基础信息

# 关键词搜索（支持名称/拼音/简介）
python scripts/search_dest.py 大理

# 按区域
python scripts/search_dest.py --region 西南 --limit 20

# 按主题（草原 沙漠 雪山 海岛 古城 美食 亲子 徒步 摄影 避暑 温泉 边境）
python scripts/search_dest.py --theme 骑行

# 按建议天数
python scripts/search_dest.py --days-max 3

# 无目标时给方向
python scripts/search_dest.py --stats

第 4 步：生成行程骨架

python scripts/build_itinerary.py \
  --from 杭州 --to 大理 --days 4 --people 3 --composition "一家三口" \
  --style cycling --lodging 舒适 --food 舒适 --season 秋 \
  --json > plan.json

输出内容：逐日三段式动线（上午/下午/晚上）、每段景点数与停留时长、每日备注、骑行/自驾/徒步/摩旅的当日里程、住宿房间分配、预算分配、按画像生成的物料清单。

参数说明：

• --people 总人数；--composition 人员构成（影响房间数，务必传）
• --style 画像 key；不指定时用 --hint 传用户原话自动推断
• --lodging 青旅/经济/舒适/高档/奢华
• --food 经济/舒适/高档/奢华
• --season 春/夏/秋/冬，影响季节性装备

第 4.5 步：住宿合理性检查（已自动完成）

build_itinerary.py 内置 stay_plan()，按人员构成自动算房间数与床型。这不是可选步骤，是预算合理性的基础。

预算口径：住宿 = 房间单价 × 房间数 × 晚数，不按人数乘。三口之家 4 天舒适档约 ¥900 住宿；若按 3 人算会虚报成¥2700。

输出中必须包含（脚本已生成，直接渲染进报告）：

• 房间数与建议房型
• 分配理由（如"三口订 1 间家庭房比 2 间标准房更宽敞，且便于照看孩子"）
• 预订提示（是否提供儿童床/加床、是否免费、热门景区需提前 2-3 周）

第 4.8 步：户外天气可行性预检（户外画像必做）

骑行、徒步、摩旅、自驾在推荐行程之前必须先跑这个，不能凭印象推荐。

python scripts/check_weather.py --to 大理 --style cycling --days 3
python scripts/check_weather.py --to 大理 丽江 --style moto --days 4# 沿线多城一起查
python scripts/check_weather.py --to 稻城亚丁 --style hiking --days 3
python scripts/check_weather.py --to 大理 --style cycling --json > weather.json

判定基于 Open-Meteo 官方 WMO 天气代码 + 温度/风速阈值，输出四档：

各画像阈值不同（越户外越严格）：

若用户坚持在恶劣天气出行，必须明确告知风险边界：降雨山路不徒步（落石/滑坡/雷击）；骑行减速避开积水；雷电不在海边湖边山脊停留；低温+雨注意失温；摩旅遇大雨积水不要硬通过。

第 4.9 步：景点票务提取（路书层的核心）

这一步决定报告是"指南"还是"路书"。 目的地简介无法回答"票怎么买、要不要预约、怎么去"，必须提取景点级信息。

# 单个目的地试跑
python scripts/extract_poi.py dali

# 批量提取并写入 references/poi.json
python scripts/extract_poi.py dali lijiang chengdu beijing sanya \
  zhangjiajie huangshan xichang --save

提取字段（来自攻略页 spot 卡片）：景点名、标签、描述、门票线索、预约线索、数据来源。

两种页面结构都要支持（实测踩过）：

• <div class="spot"> / <article class="spot"> —— 卡片型（大理/三亚/张家界/黄山/西昌）
• h2 直接作景点名 —— 列表型（丽江/成都/北京/杭州），脚本自动走extract_fallback()

标签名不固定、顺序也不固定（有的 sptag 在 h3 前有的在后），故用通配 + 全块搜索。

提取到的信息实例（这就是路书该有的颗粒度）：

• 丽江玉龙雪山：门票 100 + 环保车 20（必选），冰川公园大索道 120 元，旺季需提前实名抢票，官方小程序 20:00 放票
• 丽江古城维护费 50 元/人（缴纳后 365 天内有效）
• 束河古镇 40 元，白沙古镇免费（白沙壁画 30）
• 大理洱海生态廊道：130km，全天免费，禁机动车驶入，自行车 20-30/天、电动 60-80
• 大理双廊玉几岛太阳宫参观需提前预约，日落最佳时段 18:30-19:00
• 黄山：门票+索道分段计价，具体以景区当日公示为准

未提取到时的处理：如实说明并引导 python scripts/extract_poi.py <slug> --save 补充，或联网查官方渠道。不要凭记忆编造门票价格。

第 4.95 步：季节与车辆规划（建议必须可执行）

python scripts/plan_context.py --to 大理 --date 2026-07-15
python scripts/plan_context.py --to 丽江 --date 2026-10-01 --car ev --drive 380 --json > context.json

季节按四类地区分别判断（不是全国一套）：

注意区分：TRUE_PLATEAU 名单只收"整城高海拔"（拉萨、香格里拉、稻城亚丁等）。
大理丽江城区属southwest，只有苍山/玉龙雪山等景区才是高海拔 —— 不要一刀切按高原处理。

车辆动力类型的差异（实测数据）：

脚本会输出每种车的短板清单与路线补能策略（如电车"充电桩间距 >60km 一律先充再走"、油车"上坡用低挡位控速不要高挡硬顶"）。

节假日高峰自动识别：元旦/五一/国庆前后 → 提示住宿机票上浮 50-200%、需提前 3-7 天抢票；7-8 月上旬 → 暑期高峰提示。

第 5 步：联网调研（关键，不能跳过）

这一步是"事无巨细"的来源。按需搜索，每次一个维度，把结果整理成 research.json。

搜索维度与关键词模板：

research.json 结构：

{
  "transport": [
    {"title": "标题", "text": "正文", "kind": "warn"}
  ],
  "spots": [], "food": [], "humanity": [], "shops": [],
  "stay": [], "gear": [], "safety": [], "pitfalls": []
}

kind 字段：warn 渲染为红色警示框（必须留意的坑），tip 渲染为绿色贴士框（省时省钱技巧），省略则为普通段落。

调研质量要求（实测验证过）：

• ✅ 搜到的细节远超预期：电动车续航虚标金额、生态廊道禁行规则、亲子酒店具体房型与价位、餐厅名称与营业时间、低价团套路
• ❌ 搜索结果会有过时或错误信息（2024 年的票价、已关闭的店），交叉验证：价格类信息至少看 2 个来源
• 每条信息都要能落到"可执行"层面，不能写"注意安全"这种空话

第 6 步：叠加实时数据

# 天气（含体感、湿度、风速、降水概率）
python scripts/fetch_weather.py 大理 --days 4

# 铁路车站码与车次（无票价）
python scripts/fetch_transit.py --stations 杭州 大理
python scripts/fetch_transit.py G71 --date 20261010

# 多目的地距离、方位、顺序（避免折返）
python scripts/plan_route.py 杭州 大理 丽江 昆明

第 7 步：生成 HTML 报告

python scripts/render_report.py \
  --plan plan.json --research research.json \
  --weather weather.json --poi references/poi.json --context context.json \
  --out 旅行报告.html

参数：

• --plan 必需
• --research 调研素材
• --weather 天气预检结果（户外画像必传）
• --poi 景点库（提供门票/预约/来源，路书层核心）
• --context 季节与车辆规划（提供日期适配与动力类型建议）

产出特点：单文件、内联 CSS/JS、无外部依赖、响应式、已内置打印样式（用户可直接 Ctrl+P 另存为 PDF）。

紧凑排版：整体字号 13.5px、section 内边距 15px 17px、卡片间距 8-11px，行高 1.58。
一屏能看到更多信息，PDF 页数也相应减少。打印时进一步压缩至 11.5px 并隐藏导航。

目录导航：报告顶部有 sticky 目录条，列出全部板块（自动编号 01/02/03…），点击跳转。
滚动时自动高亮当前板块，右下角显示阅读进度百分比，末尾附「↑ 顶部」快捷返回。
打印时目录自动隐藏（@media print 中 .toc{display:none}），避免浪费纸面。

板块通过 sec_open(id, 图标, 标题) 注册，编号按注册顺序自动分配 —— 新增板块时无需手动改编号与目录。

报告共 8 大板块，指南层与路书层各占一半：

主题色随画像自动变化：特种兵红、度假蓝、蜜月粉、骑行绿、摩旅紫、徒步棕等。

天气预检板块的视觉分级：ok 绿框 / caution 黄框 / indoor_rewrite 蓝框 / not_recommended 红框，每档都带「怎么办」行动指引。

第 8 步：交付时的说明

生成报告后，向用户说明：

1. 报告可直接打开查看，打印为 PDF 用 Ctrl+P
2. 票价需自行核实（给出查询路径）
3. 天气、开放时间为生成时状态
4. 如需调整（增减天数、改节奏、换住宿区域），可具体说明重新生成

实时数据源实测结论

不要凭直觉改写这一节，都是实测结果：

攻略页解析要点

每个目的地攻略页板块名完全不同，不要套固定模板。实测：

必须先看板块清单：

python scripts/fetch_guide.py 大理 --sections   # 只列板块名
python scripts/fetch_guide.py 成都 --grep 避坑    # 只取指定板块

站点特性：

• 不存在的 slug 返回首页 200而非 404，必须校验 canonical（/map/<slug>/，不带 index.html`）
• 页面含深色模式 CSS，勿当内容提取
• 底部有「N / M」页码，脚本已剔除

坐标可靠性（重要）

天气查询必须有经纬度，而 234 个目的地的攻略页均不含坐标，需离线预置。免费地理编码对中文地名极不可靠：

enrich_coords.py 的四重防护：① country_code==CN；② 省份须落在该目的地所属区域辖省内；③ 名称须相符（允许"大理"↔"大理市"后缀差异）；④ feature_code 加权 + 人口排序，排除"低行政等级且无人口数据"。

地名加后缀变体重试（市/县/自治州）是命中率提升的关键。

实测准确率：正确 9 / 错误 0 / 未匹配 5。零错误是核心指标。

维护命令：

python scripts/enrich_coords.py --workers 4   # 并发不要超4，6 会触发限流
python scripts/verify_coords.py               # 反查自检
python scripts/verify_coords.py --fix# 清除可疑坐标后重抓

资源清单

数据（references/）

• destinations.json — 234 个目的地全量数据（含预置坐标，坐标覆盖约 53%）
• poi.json — 景点级票务与预约信息（由 extract_poi.py 生成，可增量扩充）
• station_codes.json — 12306 车站电报码表（首次运行自动生成）

脚本（scripts/）

示例（examples/）

examples/ 内是两份完整报告，可作为生成质量的参考基准：

参考它们可以确认：房间数与床型该给到什么颗粒度、warn/tip 怎么标、
天气四档该怎么回应、报告该达到什么详细程度。

质量准则

• 先给结论：推荐、节奏、预算先说清楚，再展开细节
• 两层缺一不可：只有指南层是纸上谈兵（不知道票怎么买），只有路书层排不出动线
• 建议必须可执行：不写"注意安全""带雨伞"，要写"7 月午后雷雨多，户外活动放上午，骑行改室内"
• 住宿按房间数算，不按人数算：三口之家 1 间家庭房，不是 3 间
• 户外行程先查天气再推荐：天气不达标必须给替代方案，不能硬推
• 季节结论必须绑定实际日期：7 月大理与 10 月大理结论相反，不给日期就说"未提供日期，以下为通用参考"
• 自驾必须区分动力类型：电车与油车在高海拔是两种体验，不问清车型就没法给路线建议
• 门票与预约要给来源：引用攻略页数据时保留 source 字段，让用户知道可信度
• 区分事实与推断：summary与网页内容是事实；天数推断属推断，须标明
• 实时数据必须现查：天气用脚本实跑，不凭记忆报气温
• 票价绝不编造：无法获取就明说并给查询路径
• 门票价格会变：引用时加「以景区当日公示为准」
• 优先推荐冷门替代：用户想去热门城市且预算/体验有要求时，主动提同区域小众目的地
• 不做无依据的组合：多目的地行程须说明地理相邻性，不把相距两千公里的城市硬凑一线
• 未收录目的地如实告知：查不到就说查不到，转联网搜索或手动坐标，不编造景点与交通

发布到千问技能市场

本技能同时兼容千问平台（Qoder / Claude Code等 Agent）与本地 WorkBuddy。

发布流程：登录 → 设置技能市场个人名称（首次）→ 完成实名认证 → 上传 ZIP 预检（校验 frontmatter）→ 填写资料 → 提交审核 → 约 2 分钟出结果。

发布资料字段：

审核链路：安全检测 → 人工审核 → 发布上线。

• 安全检测结果分「通过 / 提醒 / 可疑 / 危险」；「提醒/可疑」进入待处置，需手动选择「继续审核」或「修改后重新提交」；「危险」必须修改
• 状态共四种：待处置（红）/ 审核中（紫）/ 已上线（绿）/ 已下线（灰）
• 被驳回或发现安全问题 → 修改后重新提交即可

版本管理：

• 发布新版时 SKILL.md 中的 name 必须与当前 Skill 一致，英文标识与名称沿用不可改
• 挂载到智能体时需指定版本号，上传新版不会自动升级已挂载的智能体，须到智能体配置里改版本

容易被驳回的风险点（本技能已规避）：

• 硬编码 API key 或凭证 —— 本技能全部数据源免key
• 要求用户上传敏感信息 —— 只问行程偏好，不问身份证/银行卡
• 诱导性话术、绝对化承诺（如"保证不出事"）—— 天气与安全均给出条件化表述
• 引用未授权的第三方内容 —— 数据源为公开接口与用户反馈，已注明出处

目录与数据维护

目的地库快照自 2026-10-04 的 sitemap（https://worldstip.com/worldstip-sitemap.html）。更新方式：

curl -sL "https://worldstip.com/worldstip-sitemap.html" -o sitemap.html

数据位于页内 const DATA = {...}; 与 const META = {...}; 两个 JS 字面量（注意是 JS 对象语法，key 无引号，需先转成合法 JSON）。字段：n=名称、u=URL、d=简介、dy=建议天数、py=拼音首字母；META 存区域全称与配色。

重建 JSON 后必须重跑坐标补全，否则天气功能失效。