需求驱动旅游规划器

解决什么问题

做一份旅游攻略时，多数人得到的是一段纯文字建议：没有地图、没有路线时序、没有餐饮穿插，景点之间的车程全靠想象。把攻略变成一份可交互的 HTML 并不难，难的是让文件里的每个点都来自真实调研，路线密度和用户体力匹配，室内外安排和天气对齐。这个技能要解决的正是「从零生成一份结构完整、数据可信、可在地图上拖拽编辑的行程文件」，而不是替你做一次搜索。

核心能力与关键步骤

整个流程固化为四步，每一步都有可校验的产物：

• 需求对齐（强制全问）：先收集出发地/目的地、交通方式、时间、节奏强度、饮食偏好、住宿偏好、游玩兴趣、预算、每日游玩时长、景点/距离接受度、天气、强约束共 12 个维度，产出《诉求清单》作为后续所有步骤的对照基线。未指定的维度显式标注默认值，不允许跳过。
• 调研入候选库：按维度从高德扫街榜、大众点评、小红书、携程等来源取真实 POI，沉淀为 pool_data.json，每个点带经纬度、停留时长、人均花费、「怎么玩/怎么吃」提示和 ImageGen 生成的缩略图。
• 生成默认路线：按节奏轴决定每日站点数——休闲 3~4 个、特种兵 5~6 个，且无论哪种节奏都穿插 2~3 餐；用 scripts/compute_matrix.py 的腾讯自驾 API 计算时长矩阵，确保不绕路、不超时；雨天/高温提高室内点权重。
• 模板渲染：scripts/build_interactive.py 读取 pool_data.json 与 matrix.json，输出单文件 planner.html：腾讯地图编号标点、当日路线折线、候选库分类筛选、悬浮攻略 toast。

适用边界与注意点

• 主要面向国内城市，调研依赖公开榜单和搜索结果，坐标必须先地理编码核实——榜单/笔记里拿到的店坐标常偏移数公里。
• 腾讯 LBS 地图和自驾 API 都需要 key，草稿里的临时 key 会过期，生产使用需自行配置。
• 地图组件拒绝从 file:// 加载，交付前必须走本地 HTTP 自测，确认零 console error 再交付。
• assets/sample_pool.json 是杭州示例，只作字段骨架，严禁当作其他城市的成品数据；候选点与路线密度必须来自目标城市实时调研。