旅行行程规划（Travel Planner）

硬性质量红线（MANDATORY，违反任何一条不得交付）

导航零缺失：每两个相邻地点之间（酒店→景点→餐馆→下一景点→…→酒店）都必须有距离、出行方式、预计耗时、百度地图导航链接，一段都不能少。
景点照片零缺失：每个景点一张本地照片文件，一个都不能少，是硬约束。
封面与横幅图可降级：封面图和每日横幅图优先生成，但如果生成失败（重试后仍失败），可以用 CSS 渐变 + 文字标题的方式降级代替，不阻塞交付。
门票零缺失：每个景区都有门票信息——确切价格、或「免费」、或「需人工核实」三选一，禁止留空，禁止编造价格。
餐馆预算硬约束：所有推荐餐馆（含备选店）人均价格 ≤ 人均预算上限，超了必须换店，不得例外。
图片必须预生成本地文件：HTML 中用相对路径引用 images/ 下的本地文件，禁止引用任何在线图床 / 临时 URL。
Step 6.5 预组装校验必须全部通过才能进入 HTML 组装；未通过最多修复 2 轮，仍不通过时在交付说明中逐项列明缺失。

运行模式

开始前判定模式，默认 模式 A（AI 全自动，推荐），工具不可用时降级到 模式 B（本地脚本离线 fallback）：

| 模式 | 触发条件 | 信息来源 | 图片来源 | |------|---------|---------|---------| | A：AI 全自动 | WebSearch 和图片生成工具可用 | 实时网络搜索（Step 2/3/5 的搜索模板照常执行） | AI 实景照片生成（Step 4b/6） | | B：本地脚本离线 | 无网络 / 搜索或图片工具不可用 | 模型内置知识，所有无法核实的数据标注「需人工核实」 | CSS 渐变占位卡片 + 景点文字介绍，或用户提供的本地照片；交付时必须显式声明占位项 |

模式 B 下，距离/耗时估算改用 python travel-planner.py map itinerary.json --estimate-only（haversine × 1.3 道路弯曲系数），校验照常执行 Step 6.5。

超时与重试策略（全局规则，实测教训，必须遵守）

图片生成与网络搜索是本工作流最易超时的环节，以下规则防止流程卡死：

工具超时特征（实测）：

图片/媒体等待工具（media_task 类）单次调用超过 5 分钟（300s）会触发 MCP 空闲超时中断——长等待不可靠，禁止依赖
图片生成服务并发上限约 3-5 个任务，超发直接被拒（rejected）
单个图片任务可能「task execution timeout」失败（可重试）

等待策略（核心）：

短等待轮询代替长阻塞：等待图片任务时，每次等待设置 max_wait_seconds ≤ 120；超时/中断后立即重试同一次调用——中断 ≠ 任务失败，任务通常仍在跑或已完成，重试往往直接拿到结果
先 status 再 wait：遇到「interrupted / terminated / 空闲超时」类错误时，先查一次状态；若显示 completed，再 wait 一次即可取回文件
拿到文件立即归位：每取回一张图立即移动重命名到 images/，避免结束时批量整理出错
等待穿插干活：等待批次期间可并行处理其他步骤的数据工作（如 Step 5 餐馆信息整理、导航链接生成），不要空等

图片批次策略（按优先级）：

第一优先级（景点图，硬约束）：景点图必须全部生成成功，一张都不能少。每批 ≤3 个，发一批 → 等完一批 → 再发下一批，禁止一次性发起全部
被拒（concurrency limit）：该批任务直接失败，缩小批次重发（从 3 降到 2 再降到 1），不要原样重试
单张景点图失败：最多重试 3 次（换提示词角度重试，如远景→近景、白天→黄昏），确保景点图零缺失
第二优先级（封面/横幅，可降级）：景点图全部成功后再生成封面和日横幅图。若失败，重试 1 次仍不成功则降级为 CSS 渐变 + 文字标题，不阻塞交付
封面和横幅可与景点图的最后一批合并发起，节省时间

搜索批次策略：

Step 2/3 的并行搜索按 每批 ≤4 路分批发送，批间无需等待（搜索无并发限制，但大批量易整体超时）
单路搜索超时：换更简短的关键词重试一次，仍失败则该项标「需人工核实」跳过

输入参数

| 参数 | 必填 | 默认值 | 说明 | |------|------|--------|------| | origin 出发地 | 是 | 无，必问 | 自驾模式下决定路线起点和油费里程 | | destination 目的地 | 是 | 无，必问 | | | days 天数 | 是 | 无，必问 | | | budget 总预算 | 是 | 无，必问 | 只给总额时按住宿 35% / 餐饮 30% / 门票 25% / 交通 10% 拆分（餐饮部分以 dining_budget 为准，若用户提供则覆盖） | | dining_budget 餐饮预算 | 是（Step 1 必问） | 无 | 必须确认口径，仅三种：每餐预算（如「每餐 100」）/ 每日预算（如「每天 300」）/ 全程总额（如「吃饭一共 2000」），口径直接决定 Step 5 人均上限公式 | | travelers 出行人数 | 是（Step 1 必问） | 无 | 影响人均上限计算、门票/住宿费用 | | preferences 偏好 | 是（Step 1 必问） | 无 | 如：自然风光 / 人文历史 / 美食 / 亲子 / 小众，影响景点筛选 | | travel_dates 出行日期 | 否 | 相对日期「Day N」 | 影响天气、节假日、淡旺季门票 | | travel_mode 出行方式 | 否 | 公共交通 | self-drive（自驾）或 transit（公共交通） | | daily_drive_limit 每日驾驶上限 | 否（自驾模式 Step 1 建议确认） | 4 小时或 350km | 自驾模式专用，决定是否插入中途停留城市 |

工作流总览

复制此清单跟踪进度：

任务进度：
- [ ] Step 1   确认参数 → travel_brief
- [ ] Step 2   目的地调研（并行搜索）→ candidates.json
- [ ] Step 3   门票查询 → candidates.json 补全 ticket 字段
- [ ] Step 4   行程规划 → itinerary.json 时间轴 + 路段骨架
- [ ] Step 4b  景点图片生成 → images/{id}.png
- [ ] Step 5   餐馆推荐 → itinerary.json 补全餐饮节点
- [ ] Step 6   封面与日横幅图生成 → images/cover.png, images/day{n}-banner.png
- [ ] Step 6.5 预组装校验（闸门，必须全过）
- [ ] Step 7   HTML 组装 → {目的地}{天数}日游攻略.html
- [ ] Step 8   输出交付

所有中间数据统一写入 itinerary.json（Schema 见 README.md 与 travel-planner.py 文档字符串，可用 python travel-planner.py init mytrip/ 生成模板骨架），各步骤围绕这一个文件流转。

Step 1：确认参数

输入：用户自然语言描述
输出：travel_brief——上表全部参数 + 参数口径说明（预算拆分、餐饮预算口径、日期口径）
做法：
1. 先从用户描述中提取所有能提取的参数。
2. 以下三项即使用户没提也必须主动询问：dining_budget（餐饮预算）、travelers（人数）、preferences（偏好）。
3. 其余缺失的必填项（出发地、目的地、天数、总预算）一并询问；禁止假设出发地、目的地、天数。
4. 用 AskUserQuestion 一次性问完所有缺失项，不要拆成多轮打断用户。
5. 选填项采用默认值时，在攻略开头的参数摘要中显式声明（如「未指定日期，按 Day 1-N 相对日期编排」）。
预检（参数齐备后必须执行，发现的问题与缺失项合并进同一次 AskUserQuestion）：
- 往返可行性预检（自驾模式硬规则）：估算总往返里程（去程 + 返程）；若 总往返里程 > 天数 × daily_drive_limit 里程，判定不可行，禁止自行放宽上限，必须把以下选项交给用户：① 提高长途日驾驶上限（如 700km/7h，注明需轮流驾驶）；② 减少途经停留城市；③ 压缩游玩天数。公共交通模式跳过。
- 节假日影响预检：日期确定后必须核对是否跨法定节假日（春节/国庆/中秋等连休）。跨节假日时在攻略开头声明三项影响：住宿价格上浮（影响区间内预估上浮 50-100%）、热门景区预约收紧（列出需提前抢票的核心景区）、高速免费窗口（免费时段内的自驾过路费计 ¥0，需按当年官方公告核实并标注「以公告为准」）。
注意事项：
- 自驾模式要确认 daily_drive_limit 和车辆油耗（默认 8L/100km）、油品（默认 92#）；若预检触发放宽，放宽后的上限记录到 travel_brief.daily_drive_note。
- travel_dates 明确后记录星期，用于校验博物馆闭馆日（多数博物馆周一闭馆）。
- dining_budget 必须确认口径（每餐 / 每日 / 全程总额三选一），这直接决定 Step 5 的人均上限。

Step 2：目的地调研

输入：travel_brief
输出：candidates.json——候选景点（名称 / GCJ-02 坐标 / 建议游玩时长 / 开放时间 / 类型 / 评分）、住宿商圈建议、市内交通概况、城际交通方案、天气与穿衣建议
做法：按维度搜索，每批 ≤4 路并行发送（批量规则见「超时与重试策略」），批次间不空等：

| 维度 | 搜索关键词模板 | 产出 | |------|---------------|------| | 经典景点 | {目的地}必去景点排行、{目的地}{天数}日游经典路线 | 核心景点清单 | | 偏好景点 | {目的地} {偏好} 景点推荐（如 {目的地} 亲子景点） | 个性化补充 | | 小众备选 | {目的地}小众景点本地人推荐 | 拥挤时的替补 | | 特色美食 | {目的地}必吃美食清单、{目的地}本地人推荐餐馆 | 餐饮候选池 | | 住宿商圈 | {目的地}住哪个区域方便交通景点 | 住宿定位（选交通枢纽、居中于景点聚类的商圈） | | 市内交通 | {目的地}地铁线路图、{目的地}公交地铁支付方式 | 出行方式依据 | | 城际交通 | transit：{出发地}到{目的地}高铁时刻票价；self-drive：{出发地}到{目的地}自驾路线高速距离 | 首末日时间占排、自驾总里程 | | 天气 | {目的地}{月份}天气穿衣 | 贴士板块 + 图片生成的天气描述 | | 节假日活动 | {目的地}{月份}活动展演限流 | 避坑（景区限流、涨价） |

注意事项：
- 候选景点数量 ≥ 每日 3 个 × 天数 + 20% 余量，给 Step 4 挑选空间。
- 坐标必须 GCJ-02（高德坐标系），从搜索结果或高德坐标拾取器获取；无坐标的景点不得进入编排。
- 每个景点记录建议游玩时长和开放时间，这是 Step 4 排时间轴的依据。
- 首访用户优先必去地标；用户偏好决定次级筛选权重。

Step 3：门票查询

输入：candidates.json 中每个候选景点
输出：每个景点的 ticket 字段，逐项查询以下六要素：

| 要素 | 字段 | 查不到时 | |------|------|---------| | 全票价格 | price | 填 null + price_note 给参考区间（标注「参考区间」） | | 优惠政策 | concessions | 学生/老人/儿童半价等，可省略 | | 是否需预约 | reservation_required | 不得省略，必须查 | | 预约渠道 | booking | 官方公众号名称 / 官网 / 携程 / 美团 | | 提前放票规则 | advance_days | 热门景区放票时间和提前天数 | | 当天能否现场买 | walkup_available | 「仅预约制」景区此项决定行程成败 |

搜索关键词模板：
- 价格：{景点名}门票价格多少钱
- 预约：{景点名}预约官方公众号怎么约
- 放票：{景点名}提前几天放票预约攻略
- 现场票：{景点名}当天能现场买票吗不预约能进吗
注意事项：
- 硬性规则：查不到确切价格时填「需人工核实」，禁止编造价格数字。
- 热门景点（故宫、陕历博、国博等）的「是否必须预约」是行程成败关键，必须查到明确结论。
- 门票总费用 × travelers 汇入预算表；与总预算冲突时反馈并建议调整（换免费景点 / 淡季出行）。

Step 4：行程规划

输入：candidates.json（含坐标、时长、开放时间、门票）
输出：itinerary.json 的 days 数组——逐日时间轴条目（start/end，30 分钟粒度）+ 每日 segments 路段骨架
排布原则：
1. 就近聚类：按坐标把景点聚类分天（k = 有效游玩天数），同一天内按最近邻排序，严禁跨城折返。
2. 时间轴骨架：早餐 07:30-08:30 → 09:00 出发 → 上午景点（建议时长 + 30 分钟缓冲）→ 午餐 12:00-13:30 → 下午景点 → 晚餐 18:00-19:30 → 可选夜景 → 回酒店。
3. 每天景点 2-4 个、总游玩 ≤8 小时；第一天和最后一天预留城际交通时间。
4. 开放时间校验：闭馆日景点必须避开；夜间项目排在晚餐后。
自驾模式额外规则：
1. 每日驾驶时长 ≤ daily_drive_limit（默认 4 小时 / 350km），超限必须拆分。
2. 中途停留城市：单段驾驶超过上限时，在出发地与目的地之间搜索并插入中途停留城市（{出发地}到{目的地}中途城市住宿），安排 1 晚或长午休，并把该城市 1-2 个顺路景点编入行程。
3. 每 2 小时标注一次服务区休息建议。
4. 油费 = 总里程 × 油耗(L/100km) ÷ 100 × 当地油价（搜索当地当日 92# 油价；查不到用 ¥8.0/L 并标注「参考值」）。
5. 过路费 ≈ 高速段里程 × ¥0.45/km（尽量搜索实际路段费率，否则标注「参考值」）。
6. 生成路线总览地图：python travel-planner.py map itinerary.json --origin-lat {lat} --origin-lng {lng} --output route_map.html（Leaflet + 高德瓦片，按天分色折线）。局限：该脚本按「同城多景点」收集停留点，跨城单程/多城串联结构下城际长腿不会被画出，此时改由 AI 依据 segments 数据手工构建跨城路线图（参考坐标与配色规范同上）。
注意事项：时间轴条目之间的移动时间必须与 segments 的 duration_min 一致；segments 数量 = 当日地点序列的相邻对数（含回到酒店）。服务区停留不作为独立地点：长途段中途的服务区休息记入该 segment 的 note 字段（如「中途服务区休息 ×2」），不拆分路段、不生成导航链接。

Step 4b：景点图片生成

输入：编排完成后的每日景点列表
输出：images/ 目录下每个景点一张照片
规格：
- 格式：PNG，比例 4:3 或 1:1（卡片展示用）
- 命名：images/{id}.png，id 为景点拼音或英文 slug（如 wuhouci.png、kuanzhai.png），与 itinerary.json 的 attractions[].id 严格一致
- 提示词模板：{景点名称}，{城市}，真实摄影风格，{Step 2 查到的当季天气/时段}，广角构图，游客视角，高清细节——追求实景感，避免艺术渲染感
为什么必须预生成本地文件而不是用在线 URL：
1. 在线生成服务的 URL 通常有时效（数小时到数天就失效），攻略是长期保存的文档；
2. 多数图床有防盗链，HTML 离线打开或换设备打开时图片全部裂掉；
3. 本地文件才能被 Step 6.5 程序化校验覆盖率（在线 URL 无法验证内容是否可用）；
4. 用户可整体拷贝 HTML + images/ 目录离线携带出行。
注意事项：
- 景点图是硬约束，必须全部成功，一张失败都不能进入下一步。
- 分批发起：每批 ≤3 个，发一批 → 等完一批 → 再发下一批；禁止一次性发起全部任务（详细规则见「超时与重试策略」）。
- 短等待轮询：每次等待 ≤120 秒，被中断后立即重试同一任务（中断 ≠ 失败）；先 status 查状态再决定是否重试。
- 取回即归位：每张图拿到后立刻移动重命名到 images/。
- 等待穿插干活：等待期间推进 Step 5 餐馆数据 / 导航链接等不依赖图片的工作。
- 失败重试策略：单张景点图失败后最多重试 3 次，每次换提示词角度（如换时段、换视角、换天气描述），确保零缺失。

Step 5：餐馆推荐

输入：itinerary.json（每日地理位置与时段）、dining_budget、travelers
输出：每个午餐/晚餐节点：主推荐餐馆 + 至少 1 家备选店
预算筛选规则（硬约束）：
1. 人均上限按 dining_budget 口径三选一换算：
  - 每餐口径（如「每餐预算 100」）：人均上限 = dining_budget ÷ travelers
  - 每日口径（如「每天 300」）：人均上限 = dining_budget ÷ travelers ÷ 2（午晚两个正餐）
  - 全程总额口径（如「吃饭一共 2000」）：人均上限 = dining_budget ÷ travelers ÷ 天数 ÷ 2
2. 主推和备选店的人均都必须 ≤ 人均上限，超标直接淘汰换店，不做例外。
3. 软规则（预算余量）：主推餐馆人均建议 ≤ 人均上限 × 0.9，为实际点单浮动留余量；恰好等于上限（触顶）时允许通过，但须在 HTML 餐馆卡片加「紧预算」角标提醒点单控制。
4. 早餐默认酒店或酒店周边，不占推荐名额。
主推荐要求：店名（真实存在）、地址、人均价格、招牌菜 2-4 道、距上一地点的距离与导航链接。
备选店要求：必须是与主推不同的店（不同店名/分店），同样具备店名 + 地址 + 人均 + 招牌菜 + 距离导航，作为排队/闭店时的替补。
注意事项：
- 就近原则：餐馆选在当天最后一个景点或酒店 1-3km 内，禁止专门跑远吃饭。
- 优先当地特色菜系（如成都行程火锅 + 川菜 + 苍蝇馆子各安排），避免连锁快餐。
- 禁止虚构米其林/黑珍珠等评级；模式 B（无网络）下所有餐馆标注「信息基于模型知识，出发前请核实营业状态」。
- 服务区简餐：长途驾驶日（单程驾驶 >4 小时）午餐可在高速服务区简餐解决，此时午餐节点标注「服务区简餐（预估人均）」即可，不要求主推 + 备选双店结构，也不生成导航链接。

Step 6：封面和日横幅图生成

输入：目的地主题、每日主题（当天核心景点/风貌）
输出：
- images/cover.png：封面图，16:9（1792×1024），提示词：{目的地}标志性景观全景，真实摄影风格，黄金时刻光线，旅行杂志封面构图，高清
- images/day{n}-banner.png：每日横幅，16:9 或 21:9，提示词：{当天核心景点/城市风貌}，{城市}，真实摄影风格，{当日时段氛围}，横向全景构图（Day 1 若是赶路日可用出发地→目的地沿途主题）
注意事项：封面和横幅是攻略第一观感的决定因素，生成后须人工目检有无明显 AI 失真（畸形文字招牌、不合理透视），失真则重生成；所有图片同样必须落盘为本地文件。封面和横幅是第二优先级——必须在景点图全部生成成功后再生成（可与最后一批景点图合并发起节省时间）；若生成失败且重试 1 次仍不成功，降级为 CSS 渐变 + 文字标题，不阻塞交付，在交付说明中注明即可。

Step 6.5：预组装校验（闸门，全部通过才能进入 Step 7）

输入：itinerary.json、images/ 目录
做法：先运行自动化脚本 python travel-planner.py validate itinerary.json，再逐项人工复核：

| 检查项 | 检查方法 | 通过标准 | |--------|---------|---------| | 景点照片覆盖率 | 脚本自动：逐景点比对 images/{id}.png 文件存在性 | 景点数 = 图片数，0 缺失（硬约束） | | 封面与横幅图 | 脚本检查 cover.png 与全部 day{1..N}-banner.png（N=天数） | 建议齐全；缺失时为 WARNING 级，HTML 中用 CSS 渐变降级，不阻塞交付 | | 导航链接覆盖率 | 遍历每天 segments，检查每段的 nav_url 格式合法（百度地图 direction 接口 + origin/destination/coord_type=gcj02 参数齐全）；段数 = 当日相邻地点对数 | 0 缺失、0 格式错误 | | 门票信息 | 遍历 attractions[]，price / price_note（免费或需人工核实）至少一项非空 | 0 缺失 | | 餐馆预算 | 遍历全部 restaurant 与 backup，avg_price ≤ 人均上限；主推与备选店名不同 | 0 超标，0 缺备选 | | 时间轴完整性 | 检查无重叠、无负时长、每日首尾衔接酒店、开放时间不冲突 | 全部通过 |

注意事项：不通过 → 修复后重跑，最多 2 轮；仍不通过可继续交付，但必须在交付说明中逐项列明缺失（红线 6）。

Step 7：HTML 组装

输入：itinerary.json（全部字段已补全）、images/、route_map.html（自驾）
输出：{目的地}{天数}日游攻略.html，与 images/ 同目录交付，图片用相对路径 images/xxx.png 引用

页面九大板块（按序，完整模板见 README.md）：

封面 Hero：cover.png 全宽背景 + 目的地大标题 + 参数摘要（天数 / 人数 / 出行方式 / 日期 / 总预算）
行程速览：每日一览表（Day / 上午 / 下午 / 晚间 / 住宿地）
逐日行程：每日以 day{n}-banner.png 横幅开头，下接时间轴卡片——景点卡片（图片 + 门票/预约徽章 + 时长 + 「导航 →」按钮）+ 路段条（A →(方式耗时距离导航)→ B）+ 餐馆卡片（店名/地址/人均/招牌菜 + 备选店折叠区）
餐饮汇总：全部餐馆清单表（日次 / 餐次 / 店名 / 人均 / 招牌菜 / 是否备选）
门票与预约汇总：每景区的价格、预约渠道、提前天数、当天可否现场买，附预约操作顺序建议
交通与导航汇总：全部路段导航链接列表；自驾模式含路线总览地图（内嵌 route_map.html 内容）+ 油费/过路费卡片
预算明细表：交通 / 住宿 / 餐饮 / 门票 / 油费过路费（自驾）各小计 + 总计，与用户总预算对比条
实用贴士：天气穿衣（Step 2 查到的结果）、交通卡/支付方式、打包清单、避坑提示
核实清单与免责声明：所有「需人工核实」项汇总列表 + AI 图片说明

CSS 变量配色方案（写入 :root，全部颜色只用变量）：

:root {
  --primary: #1a73e8;   /* 主色：导航按钮、链接 */
  --accent: #e8710a;    /* 强调色：预算对比、重要徽章 */
  --bg: #f6f7f9;        /* 页面背景 */
  --card: #ffffff;      /* 卡片背景 */
  --text: #1f2329;      /* 正文 */
  --muted: #86909c;     /* 次要文字 */
  --warn: #b45309;      /* 「需人工核实」角标（黄底褐字） */
  --line: #e5e6eb;      /* 分隔线、时间轴竖线 */
  --day-1: #e6194b; --day-2: #3cb44b; --day-3: #4363d8; --day-4: #f58231; /* 每日主题色，循环扩展 */
}

图片 onerror fallback 规则：每张图片都挂 onerror，加载失败时降级为渐变占位卡片并显示景点名，禁止留裂图：

<div class="img-wrap">
  <img src="images/wuhouci.png" alt="武侯祠"
       onerror="this.closest('.img-wrap').classList.add('img-fallback'); this.remove();">
  <span class="img-name">武侯祠</span>
</div>
<style>
.img-fallback { background: linear-gradient(135deg, var(--day-1), var(--primary)); }
.img-fallback .img-name { color: #fff; font-size: 1.4em; font-weight: 700; }
</style>

百度地图导航链接格式（坐标 GCJ-02）：

https://api.map.baidu.com/direction?origin={from_lat},{from_lng}&destination={to_lat},{to_lng}&mode={mode}&coord_type=gcj02&output=html&src=webapp

mode 映射：驾车 driving、公交/地铁 transit（加 &region={城市名}，中文需 percent-encode）、骑行 riding、步行 walking；打车场景用 driving。
餐馆等无坐标地点可用百度搜索链接：https://map.baidu.com/search?query={店名 percent-encode}&city={城市}。
移动端优先：max-width 720px 居中，导航按钮高对比实色、点按区 ≥44px。

注意事项：Leaflet 从 CDN 引入；除 CDN 脚本外无任何本地依赖；「需人工核实」数据统一黄色 ⚠ 角标并在板块 9 汇总；过路费须先判断高速免费窗口——行程若跨法定节假日免费时段（以 Step 1 预检结论为准），免费时段内的自驾过路费计 ¥0，并在预算表中分段列示（如「去程 ¥940 + 返程 ¥0（免费时段）」）。

Step 8：输出交付

输入：全部产物
输出（交付给用户三样东西）：
1. {目的地}{天数}日游攻略.html——最终攻略（与 images/ 目录成对使用，缺一不可）
2. images/ 目录——全部本地图片（景点图 + 封面 + 日横幅）
3. itinerary.json——结构化行程数据，供用户二次修改或重新生成
交付动作：用文件卡片展示 HTML（附 images 目录说明），摘要控制在 3 句以内：行程亮点、总预算 vs 用户预算、需人工核实项数量。
必须附带的提示：「价格、预约规则和营业信息以查询时点为准，出发前请按攻略末尾核实清单复核；图片为 AI 生成示意图，实际景色以现场为准。」

参考文件

README.md：使用说明、itinerary.json Schema、HTML 结构、导航链接格式、武汉→威海完整示例
travel-planner.py：本地 CLI（init 生成模板 / validate 质量校验 / map 路线地图与距离估算，模式 B 依赖）