marco-polo

name	marco-polo
display_name	马可波罗
description	Structured Chinese trip-planning workflow for multi-step travel planning. Use when Codex needs to plan a trip end to end in Chinese, collect trip constraints, compare transport and lodging areas, build attraction and food candidate files, verify current opening/ticket/booking information, geocode points with Amap, design daily routes, maintain budget/state files, update plans after user changes, or generate a final Amap HTML itinerary. Also trigger when the user mentions 马可波罗, Marco Polo, travel workflow, 旅游规划, 行程规划, or 旅行手册.

马可波罗：旅游规划工作流

原则

按阶段推进，不要跳步。阻塞信息不足时先问；用户没有确认上一阶段前，不生成下一阶段的详细成果。

把判断和证据分开保存。小红书适合发现热门经验和避坑，不要盲信；时效信息、价格、营业时间、预约、交通班次必须用可核验来源确认。

生成任何决策文件后，必须在对话里汇报摘要、推荐结论和需要用户选择的点。不要只让用户自己打开文件翻。

除非任务很大或用户明确要求，多路线检索不需要 subagent；用分开的文件/小节记录“两路来源”，最后综合即可。

依赖技能

本技能是总控流程，会按阶段调用其他技能。调用前读取对应技能说明，遵守其登录、权限、文件和输出约束。

• $flyai：查大交通、酒店候选、门票/旅行产品价格。用于实时票价、班次、酒店榜单和预订链接；最终价格以跳转页为准。
• $xiaohongshu-skills：查住宿区域、旅游攻略、景点红黑榜、美食攻略。只作为经验来源和趋势参考；需要登录态，且不要把小红书内容当权威事实。
• $amap-lbs-skill：查 POI、坐标、周边和路线。用于生成 景点坐标.csv、消歧同名地点、补充市内交通。
• $amap-jsapi-skill：生成最终地图 HTML。用于高德地图页面、点位、路线、弹窗和移动端交互。
• Web 搜索/官方来源：核验门票、开放时间、预约、闭馆日、天气、签证/入境、安全和交通时刻等时效信息。

文件夹

为每个行程维护一个目录，默认：

travel_plan/<目的地或行程名>/
├── 行程需求.json
├── 行程状态.md
├── 费用跟踪.csv
├── 大交通方案.md
├── 住宿区域候选.md
├── 候选景点清单.csv
├── 景点详情清单.csv
├── 景点坐标.csv
├── 景点图片.csv
├── 每日行程.md
├── 市内交通方案.md
├── 美食推荐.md
├── 信息来源.md
├── map.html
├── city-impression.html
├── food.html
└── index.html

用户提交更新时，先读 行程需求.json 和 行程状态.md，同步更新受影响文件，不要只在回复里口头修改。

1. 收集最小信息

先解析用户自然语言，缺失阻塞信息时提问。不要要求用户填 JSON。

硬阻塞信息：

• 出发地
• 返程地
• 旅游城市，可以多个
• 时间框架：出发日/返程日最好；若只有“6天5晚”，必须澄清实际出行日期和每城停留，因为路上过夜可能让总行程变成 7-8 天
• 人数和成员特征：成人/儿童/老人/行动限制

软信息尽量早问，但不可无限等待：

• 预算范围和口径：默认按人均预算管理，询问是否含大交通和住宿
• 偏好：人文、自然、美食、亲子、轻松、特种兵、拍照、购物、夜生活
• 住宿偏好：预算、连住/换住、是否接受离景点远但交通方便
• 禁忌和刚性安排：不去地点、必须去地点、会议/探亲/演出等固定时间

满足硬阻塞信息后，写入 行程需求.json 和 行程状态.md。行程状态.md 用中文列出已确认、当前假设、待确认问题。

2. 大交通决策

先问用户：机票/火车票是否已定，还是需要 agent 帮忙决策。

覆盖三类大交通：

• 出发地 -> 第一个旅游城市
• 旅游城市之间
• 最后一个旅游城市 -> 返程地

前置条件：相关城市和对应日期必须清楚。若某段日期不清楚，先让用户确认城市顺序和每城停留。

需要 agent 决策时，使用 $flyai 查询机票/火车票。灵活考虑：

• 小城市可比较周边大城市机场/高铁站加地面通勤
• 直达、转机/中转、前一晚出发、最后一天返程的时间成本
• 票价不是唯一指标，还要比较到达时间、总时长、换乘风险、是否影响游玩

与用户确认后写 大交通方案.md，并初始化 费用跟踪.csv。费用默认按人均口径维护：机票/门票等单人票价按 1 人份记录；酒店、包车等共享费用按实际分摊人数均分。不要把多人总价作为主预算，除非用户明确要求另做总额估算。

费用文件至少包含：

类别,项目,费用口径,原始总价,分摊人数,人均金额,数量,人均小计,是否已定,备注

费用文件末尾必须保留总计行：

• 类别=总计，项目=已定人均总计/预估人均总计/全部人均总计
• 人均小计 填对应汇总金额
• 如果人数明确，在备注里写全员总额，例如 2人合计 3600

3. 住宿区域

只推荐区域，不推荐具体酒店，除非用户进入“酒店住宿”扩展功能。

每个住宿城市走两路：

• 常规路线：结合地图、交通枢纽、景点分布、商业区、安全和预算判断
• 小红书路线：用 $xiaohongshu-skills 搜“<城市>住宿”“<城市>住哪里方便”“<城市>旅游住宿”，提炼常见区域和避坑

输出 住宿区域候选.md：每城不超过 3 个区域，给 10 分制排序，说明适合人群、优势、短板、交通、价格倾向。让用户确认住宿区域后再做每日动线。

4. 景点候选池

确认城市和大致住宿区域后，建立景点清单。每城不要超过 30 个候选。

两路收集：

• 常规路线：搜索/知识库整理经典景点、博物馆、街区、自然景观、体验和可替代项
• 小红书路线：用 $xiaohongshu-skills 搜“<城市>旅游攻略”“<城市>n天旅游攻略”“<城市>必去景点”“<城市>景点红黑榜”。挑 5-10 篇相关笔记细看，记录共识和疑似误导点

写 候选景点清单.csv，字段建议：

城市,名称,类型,优先级,推荐分,推荐原因,小红书证据,风险或争议,用户选择

优先级用 P0/P1/P2/P3：

• P0：强烈建议保留或用户必去
• P1：高价值，优先安排
• P2：有时间再加
• P3：备选/雨天/替代

生成文件后，必须在回复中汇报候选清单摘要，而不是只给文件路径。摘要至少包括：每城 P0/P1/P2/P3 数量、每城最推荐的 P0/P1 项、明显争议或避坑项、建议用户保留/删除的决策点。

把清单交给用户筛选。用户未筛选前，不进入详细日程。

5. 景点详情

用户筛选后，核验并丰富入选景点。直接搜索官方/权威/近期来源，不依赖小红书。

写 景点详情清单.csv，至少包含：

城市,景点名称,别名,类型,门票,预约要求,提前几天,开放时间,闭馆时间,建议游玩时段,建议停留时长,备注,核验来源,核验日期

类型可用：景点、博物馆、历史、自然、街区、夜景、美食、购物、亲子、演出、交通节点。

6. 坐标与图片

使用 $amap-lbs-skill 查询入选景点 POI，必要时用城市限定和 POI 详情结果消歧。若后续可能生成展示页/分享页，同一次查询应使用高德 v3 place/text + extensions=all，从同一个 POI 响应里同时取 location 和 photos.url，不要 HTML 阶段重新搜图。

写 景点坐标.csv：

城市,名称,高德POI名称,经度,纬度,地址,类型,置信度,备注

写 景点图片.csv：

城市,景点名称,高德POI名称,图片URL,图片标题,图片来源,匹配级别,是否采用,备注,查询日期

坐标格式必须是“经度,纬度”。图片 URL 统一转 HTTPS。匹配级别用：真实地点图、片区真实图、待补图。低置信度或同名地点多的点要标注并请用户确认。

7. 每日行程

基于住宿区域、景点坐标、开放时间、建议时段、停留时长和体力负担规划。

规则：

• 遵守几天几夜和真实到达/离开时间，不把交通日当完整游玩日
• 按地理聚类安排，避免同日东奔西跑
• 夜景、美食街、夜市放到傍晚/晚上；博物馆和需预约地点避开闭馆日
• 若用户晚上返程或晚上动身去其他城市，当天晚上不要安排景点/夜市/演出；优先与其他“晚上空闲”的日期互换夜间项目
• 可从远到近或从近到远，但要解释理由
• 每天留弹性时间，标注可删项和雨天替代

先给用户“每日路线草案 + 规划理由”，交互确认后写 每日行程.md。

8. 市内交通

每日行程确认后，可生成 市内交通方案.md。按每日相邻点逐段处理，不查骑行方案。

先用 景点坐标.csv 计算相邻点直线距离，作为是否查询打车/公共交通的门槛；步行距离和时间优先使用 $amap-lbs-skill 的 walking 路线结果，不要用直线距离倒推替代：

• 直线距离小于等于 800 米：默认步行，查询 walking 路线校正道路距离和时间；若是景区内部或湖边/街区，备注“现场路径可能更绕”
• 直线距离 800-1500 米：默认步行，查询 walking 路线校正；若当天体力压力大、天气热、赶预约或带行李，再查打车/公共交通
• 直线距离大于 1500 米：查询 walking、驾车和公交/地铁路线；步行通常作为“不推荐但可参考”的对照

市内交通方案.md 面向人读，不要输出宽表；按日期分组，再按相邻路段用小标题和短 bullet 写。每段至少包含：

日期,起点,终点,直线距离,高德步行路线,打车/驾车距离/时间,打车费用估算,公共交通方案,公共交通时间,公共交通费用,推荐方式,推荐理由,是否需用户确认

费用规则：

• 步行费用写 0 元
• 公共交通费用优先用路线接口返回；无返回时按南京地铁/公交常见票价估算并标注“估算”
• 打车费用优先用接口返回的出租车费用字段；无返回时按距离粗估并标注“估算”

模型必须给出默认推荐，不要把每一段都交给用户选择。只有以下情况才列为“需用户确认”：

• 打车和公共交通时间差小于 10 分钟但费用差明显
• 步行超过 20 分钟但路线体验较好，例如湖边、街区、景区内部
• 涉及行李、赶火车、赶预约、雨天或高温
• 高德路线结果与人工地理判断冲突，例如景区内部车辆不可达

生成后在回复里只汇报推荐结论和需要用户确认的少数分歧段；用户确认后再把最终选择写回 市内交通方案.md，并可同步到 map.html 弹窗说明。

9. 美食

行程主体确认后再做美食。两路收集：

• 常规搜索：本地菜系、代表菜、老字号、商圈餐饮、营业时间
• 小红书：搜“<城市>美食攻略”“<城市>必吃”“<城市>旅游攻略”，复用前面旅游攻略里的美食线索

写 美食推荐.md，分两类：

• 菜名/小吃/饮品清单：适合用户知道“吃什么”
• 店铺清单：适合按行程插入，记录区域、人均、营业时间、排队风险、是否需要预约

10. 最终 HTML 手册

用户要求“定稿”“地图”“分享版”“手机查看”或“HTML”时，先询问交付版本，不要默认直接做全量页面：

• 简约版（推荐默认）：只生成 map.html + config.local.js
• 详细版：生成 index.html + map.html + city-impression.html + food.html + config.local.js

不要在路线未确认前生成最终 HTML；可以先做草稿预览，但要标明未定稿。若用户已经明确要求“页面切换”“旅行手册”“城市印象”“美食页”或更强展示感，可视为选择详细版。

简约版使用本 skill 的 assets/amap-html-template/ 作为起点，复制到当前行程目录并生成：

• map.html：完整地图页面和行程数据
• config.local.js：本地高德 JSAPI Key 配置

详细版保持页面分离，避免地图 JS 与展示页 CSS/JS 混杂：

• index.html：统一入口，用 tabs/iframe 在独立页面间切换
• city-impression.html：景点图片 + 简介展示页，读取 景点图片.csv
• food.html：美食图片 + 路线吃法展示页，读取 美食推荐.md，图片优先用高德 v3 POI photos.url
• map.html：完整地图页面和行程数据
• config.local.js：本地高德 JSAPI Key 配置

生成前读取：

• 行程需求.json
• 每日行程.md
• 景点坐标.csv
• 景点图片.csv（如生成图片展示页）
• 景点详情清单.csv
• 美食推荐.md（如需展示餐饮点）

实现要求：

• 使用 $amap-jsapi-skill 或现有高德 JSAPI Key
• 输出到当前行程目录，不写到全局 amap-jsapi/，除非用户明确要求做独立 JSAPI 示例
• 默认交付纯静态 HTML/CSS/JS 文件，不引入后端服务；本地 HTTP 端口仅用于预览或浏览器验收，不能描述成使用页面的必要条件
• map.html、city-impression.html、food.html 各自独立；index.html 只负责切换和入口
• map.html 默认使用正面朝北视角，避免明显倾斜；高德地图初始化优先设置 pitch: 0、rotation: 0，除非用户明确要求 3D/俯视效果
• 按天分组展示点位和路线，不同日期使用不同颜色
• 点位弹窗包含：名称、类型、建议停留、开放时间/预约提示、当日顺序、备注
• 页面侧边栏或底部列表展示每日行程摘要，点击列表项能定位到地图点
• 支持住宿区域或酒店点位作为每天起终点；未定具体酒店时用住宿区域中心点或明确标注“区域参考点”
• 美食点与景点点视觉区分，避免混在同一类 marker 中
• city-impression.html 的景点展示尽量覆盖每日行程里实际会去的景点；若某景点缺少真实图片，应标注 待补图 或用同片区真实图替代，不要随意省略核心景点
• food.html 中小吃、饮品、菜名和店铺都要尽量带图；店名型优先用门店 POI 图，泛食物名检索时加城市和片区，例如“南京 鸭血粉丝汤 科巷”
• 美食页配图要校验对应关系，避免同名店、异地菜品或泛化网图误配；无法确认时标注匹配级别，不伪装成真实店图/实物图
• 对低置信度坐标、需预约、闭馆风险、交通日限制做醒目标注
• 移动端可读：地图、日程列表、弹窗不要互相遮挡
• map.html中景点坐标旁边应该有名字注释，不要等到用户点击才知道名字，但是注释不是一直存在，当比例尺小于一定大小（例如1.5公里）才显示；

验收：

• 打开 map.html 检查地图非空、点位位置合理、每日颜色/顺序正确，且默认视角为正面朝北、无明显倾斜
• 若生成 index.html，检查三页切换可用，并保留各独立页面直接打开能力
• 若生成城市印象页，检查展示点是否覆盖每日行程核心景点，抽查远程图片 URL 可加载，且详情中标注对应 POI 或匹配级别
• 若生成美食页，抽查小吃/饮品/店铺图片 URL 可加载，并检查图片与菜品或门店是否对应
• 抽查 3-5 个点位弹窗，确认信息来自最新文件
• 若使用本地 dev server 或浏览器预览，按环境规则启动并告知 URL，同时说明这是临时预览服务，用户可在查看后关闭

11. 扩展功能

酒店住宿：用户确认大区域后，用 $flyai 查酒店候选。不要提前推荐具体酒店。

市内交通：按第 8 阶段生成 市内交通方案.md；不要查询骑行方案。

完成检查

最终交付前检查：

• 每天地点是否顺路，交通时间是否现实
• 晚间返程/跨城移动日是否已清空夜间景点，并把可交换夜间项目挪到其他空闲晚上
• 预约、闭馆、门票、天气、节假日人流是否影响可行性
• 费用是否同步进 费用跟踪.csv
• 用户更新是否已写回对应文件
• 信息来源.md 是否记录关键核验来源和日期