旅行路书规划器 / Travel Roadbook Planner V1.1
这是旅游行程规划技能，不是应用开发任务。使用本技能时，直接完成需求分析、信息核验、行程构建和路书输出，不创建独立应用。
核心目标
围绕“真实可执行、交通闭环、住宿合理、节奏符合人员情况、信息可核验”构建行程。先确定路线骨架、住宿骨架和交通骨架，再安排每天的具体活动；不要套用每天固定两项景点的模板。
必须收集的输入
先识别用户已提供的信息，只追问会改变规划结果的缺失项：
- 目的地、出发地、出发和返程日期、抵达及返程时间；
- 旅行人员：成人、儿童、老人数量；儿童和老人必须确认年龄，老人或行动受限人员必须确认行动能力；
- 预算级别：经济型、舒适型、高端型或奢华型；
- 行程节奏：轻松、平衡或紧凑；旅行风格：观光、深度、度假、亲子、美食、购物或综合；
- 当地交通：混合、包车/专车、公共交通、租车自驾或出租车/网约车；
- 是否离岛、离岛名称、是否跨城市或跨区域；
- 兴趣、海上活动和限制条件，例如先紧凑后舒适、先城市后海边、减少换宿、避免长距离驾驶；
- 是否已有航班、酒店、租车、船票或活动订单。仅读取用户主动提供的本地文件，不访问邮箱。
如果存在儿童或老人但年龄、行动能力缺失，先暂停正式规划并询问；不要默认为标准行动能力。演示行程可以明确写出假设。
规划顺序
- 解析中文、英文、日文或韩文输入，统一为结构化参数。
- 将自然语言约束转为明确规则，例如“先城市后海边”转为
city_before_beach，“尽量少换酒店”转为minimize_hotel_changes。 - 确定进出交通、城市顺序、跨区或离岛节点、各城市停留天数和换宿日。
- 为每个城市选择一个主住宿区域，并将主要游玩区域尽量安排在同一区域。舒适型、度假型和亲子型默认优先连住，减少只住一晚和频繁换宿；特种兵打卡式行程除外。
- 为每天标注日期属性：抵达日、换宿日、普通游玩日、活动日、购物日或返程日。
- 按起床、早餐、出发、交通、活动、午餐、休息、晚餐、返回住宿和休息的时间容量排程。标准行动能力的成人带 8 岁儿童时，完整游玩日通常应有至少三个有意义的时间段；只有用户明确选择度假休息日时才降低密度。
- 平衡城市景观、自然景观、亲子活动、休闲娱乐、海边/森林、美食和购物，避免连续多日体验层次单一。
- 对航班、铁路、道路、轮渡、景区开放、预约、天气、海况、接送和儿童适宜性进行联网核验；无法核验时明确标注“待确认”或“规划参考”。
交通规则
- 用户明确选择
self_drive时，城市间和当地交通主方案必须是租车自驾；不要再把“混合交通”作为主方案。可在单独的“备选方案”中提示铁路、航班或包车，仅在天气、道路、车辆或时间存在明显风险时提供。 - 用户明确选择
private_car、public_transport或其他交通方式时，按用户选择构建主方案；不要用泛化的混合交通替代。 - 进出交通必须写明出发地、机场/车站/码头、接送、取还车、行李和时间缓冲。
- 换宿日必须包含整理行李、早餐、退房、前往交通节点或取车、城际移动、途中休息、抵达、寄存或入住和晚间休息。自驾换宿日可以安排顺路停靠，但不能牺牲安全和入住衔接。
- 离岛日必须写明预约、一日游或船务产品、酒店接送、码头集合、登船、船型、浮潜/潜水等活动、儿童或老人限制、返程接送、取消政策和天气海况风险。
- 不声称实时票价、库存、精确航班时刻、船班、开放时间或海况，除非联网来源明确返回这些事实。
中文与中英文对照规则
默认使用中文构建和解释行程。仅对以下专名使用“中文 / English”并行：城市、景点、场所、地址、机场、铁路、航班、轮渡和其他交通实体。行程说明、风险提示、预约说明、住宿建议、交通建议和参数标签全部使用中文；不要出现无意义的半中半英。
所有源文件、JSON、Markdown 和 HTML 使用 UTF-8。生成 HTML 时必须转义用户输入和联网来源。不要使用外部 Google Fonts 或外部 JavaScript，保证中国网络环境和离线打开能力。
联网与中国用户环境
使用 scripts/research_fetcher.py 搜索和记录当前信息，优先官方机场、航空公司、铁路、轮渡、景区、旅游局和住宿页面；使用百度或 Bing 作为发现入口。搜索摘要只是线索，不是确认事实。
地点数据使用 scripts/places_fetcher.py：自动优先高德（AMAP_API_KEY）或百度地图（BAIDU_MAP_AK），否则使用 OpenStreetMap 或内置离线数据。天气使用和风天气（QWEATHER_KEY）或 Open-Meteo，失败时使用明确标注的气候参考。
不访问 Gmail、Google、邮箱、通讯录或私人消息。订单只通过 scripts/booking_importer.py 读取用户主动提供的本地 JSON、EML、MSG、HTML、TXT 或 PDF 文件。不要把 API Key、密码、OAuth Token 或私人邮件内容写入输出。
输出方式
使用 scripts/generate_itinerary.py 生成：
.html：自包含、可打印的可视化行程；.md：便于编辑和分享的行程文本；.json：结构化行程、住宿、交通、人员和研究来源；.pdf：中文优先的路书，固定包含三部分：详细行程、行前准备清单、需要预约清单。
PDF 需要 ReportLab 和本机中文 TrueType 字体。生成 PDF 后必须使用 Poppler 渲染页面检查字体、截断、重叠、分页、页脚和章节标题；没有通过渲染检查时不得交付。
常用命令
python scripts/research_fetcher.py \
--query "郑州 海口 航班 2026年11月" \
--query "海南东海岸自驾 海口 文昌 万宁 三亚 路线" \
--provider baidu \
--output research.json
python scripts/generate_itinerary.py \
--destination "海口,文昌,万宁,三亚" \
--start-date 2026-11-02 \
--end-date 2026-11-09 \
--departure-city 郑州 \
--traveler-profile '[{"type":"adult","count":2,"mobility":"standard"}]' \
--pace balanced \
--comfort-level comfort \
--travel-style balanced \
--local-transport self_drive \
--island-policy optional \
--sequence-constraints city_before_beach,minimize_hotel_changes \
--weather weather.json \
--places places.json \
--research research.json \
--language zh \
--output hainan-roadbook.pdf
交付前检查
- 每天有明确城市、日期属性、活动或交通衔接；不使用笼统“自由活动”代替规划；
- 人员画像、出发地、预算、节奏、舒适度、旅行风格、当地交通、离岛策略和约束均可追溯；
- 每个城市有主住宿区域、连住天数和换宿次数；游玩区域与住宿区域尽量一致；
- 进出交通、城际交通、当地交通和离岛接送完整；用户指定交通方式为主方案；
- 中文主体没有无意义中英混杂，中文和英文专名均能正常解码；
- 联网来源有 URL、核验时间、状态和置信度；待确认事项不会被写成确定事实；
- PDF 恰好包含“详细行程”“行前准备清单”“需要预约清单”三个可见章节，并完成渲染检查；
- 运行 Python 语法检查、代表性单目的地/多目的地/跨区域测试，确认没有跨城市景点泄漏、返程日重复活动或换宿日缺少行李节点。
资源索引
scripts/generate_itinerary.py：约束驱动的行程和路书生成器；scripts/places_fetcher.py：高德、百度、OSM 和离线地点数据；scripts/weather_fetcher.py：和风天气、Open-Meteo 和气候参考；scripts/research_fetcher.py：百度/Bing 发现、官方 URL 核验和来源记录；scripts/booking_importer.py：本地订单文件导入；assets/itinerary_template.html：UTF-8、自包含、可打印 HTML 模板；references/destination_templates.md：目的地规划参考；references/providers.md：提供商和凭证配置；references/travel_tips.md：行前准备、安全和通用旅行建议。
除非联网来源明确确认，不要把内置参考、搜索摘要、离线数据或预测范围外天气表述为实时事实。
