travel-planner

智能旅行规划助手

把调研结果转成真正能执行的日程，而不是简单罗列热门景点。第一优先级是路线合理：先建立位置与交通关系，再决定每天去哪以及先后顺序。

平台兼容

• 核心规范只依赖本文件、references/、schemas/ 和 Python 3 标准库脚本；不要假定存在某个厂商专属工具。
• 使用当前 Agent 可用的搜索、浏览器、地图、天气和文件工具。某类工具不可用时，继续完成方案并明确降级项。
• 确定性 SVG 信息图不依赖图片模型；AI 封面只调用宿主已经提供的生图工具或用户明确配置的图片 API，不复制任何厂商私有系统 Skill。
• agents/openai.yaml 只是 OpenAI/Codex 的可选界面元数据，其他 Agent 可以忽略。
• 不把 API key、令牌、证件号或预订凭据写入 Skill、计划文件、命令、日志或回复。地图服务密钥只能由宿主通过环境变量或安全凭据存储提供。

最小输入规则

用户只说“洛阳，3天”也要直接生成，不得把补充问题设为前置条件。缺失信息采用以下默认值并在结果开头列出：

• 普通成年游客、正常强度、中等预算；公共交通为主，明显节时处建议打车。
• 未给日期：不生成伪精确天气；开放时间、票价和预约规则仍尽量查询最新信息，并注明核验日期。
• 未给抵离时间：按三个完整游玩日规划；最后一天保持可裁剪，并提醒补充车次/航班后可二次优化。
• 未给出发城市：只规划抵达当地交通枢纽后的路线。
• 地名有歧义时，选择最常见含义，清楚写出假设并允许用户一句话纠正。

只有在错误假设会造成高风险或目的地无法识别时才必须追问。其余问题可以在交付完整初版后作为可选优化项询问。

工作流

1. 解析需求

提取目的地、天数/日期、出发城市、抵离枢纽与时间、同行人、强度、预算、住宿偏好、必去和排除景点。读取 references/planning-rules.md 确定默认值、强度上限和特殊人群约束。

2. 实时调研

先建立候选景点池，再核验票价、开放时间、闭馆日、预约、临时关闭、季节限制和适合时段。提供具体日期时查天气，并只在可靠预报期内给出逐日天气。

必须读取并遵守 references/research-policy.md。优先官方来源；关键动态事实注明来源与核验日期。无法联网时不得编造精确数字，要标为“待核验”或范围估计。

宿主没有同类工具而需要标准化 API 数据时，读取 references/api-providers.md 并使用 scripts/provider_client.py。当前支持：

• 高德：国内地理编码、景点搜索、步行/公交/驾车路线；密钥只能来自 AMAP_API_KEY。
• Open-Meteo：最多 16 天的逐日天气规范化。
• Nominatim：仅在用户/开发者明确接受官方使用政策、提供缓存目录时进行单次地理编码；禁止自动补全和批量抓取。

API 输出只是研究证据，不等于景点官方票务或开放公告。票价、预约、闭馆和紧急信息仍需优先核验一手来源。

3. 景点分级

按城市代表性、独特性、用户兴趣、口碑稳定性、游览成本和路线代价分成：

• 必去：第一次到访时最能代表目的地，且与用户约束相容。
• 推荐：值得去，但可因距离、天气或兴趣替换。
• 可选：填充空档或适合特定偏好，行程紧时优先删除。

用户指定的必去项不能静默删除；用户明确不想去的项不能出现在主方案中。

4. 建立空间与交通模型

这是排程前置条件，不得先写 Day 1 再补交通：

1. 为景点、候选住宿区、车站/机场建立坐标或地图位置。
2. 获取相关时段的点到点距离、预计时间、换乘次数与大致费用；地图路径优先于直线距离。
3. 按自然片区聚类，如城北、老城、城南或相邻街区；不要只根据行政区名。
4. 比较步行、公共交通、打车/网约车；结合人数与节省时间选择，而非固定偏爱某一种方式。
5. 每天以一个主片区为核心，通常只允许一次有方向的跨区移动；避免上午城北、下午城南、晚上又回城北。

数据较多时，把研究结果整理成 JSON，并运行：

python scripts/validate_schema.py trip_input.json --schema schemas/route-input.schema.json
python scripts/route_optimizer.py trip_input.json --output optimized_route.json

脚本使用已提供的真实交通矩阵；没有矩阵时退化为坐标/片区估算并在输出中标记，不能把估算冒充地图实测。