megumi-ben/marco-polo.skill/marco-polo-skill

马可波罗：单城市旅行规划

让用户知道为什么住这里、为什么去这些地方、为什么这样走，并拿到能照着执行的行程。保留实际使用中积累的约束，把流程和文件理清楚，避免为了完整而增加无用工作。

范围与执行原则

• 默认一次规划一个城市，以一个住宿基地为主，可包含近郊一日游。多城市请求先明确本轮范围或分城处理，保留已定城际交通边界；不要遗漏城市后声称整趟旅行已完成。
• 接受自然语言，不要求用户填 JSON。继续或修改时先读已有行程数据和状态；已给出的信息不重复问，已买好的交通不重新比较。
• 五阶段：①需求与可选大交通 → ②住宿、③景点可并行研究 → ④路线规划、美食研究、城市名片素材三线并行 → ⑤分别制作页面，统一入口交付。路线分支保留资料与预约前置、高德空间排程和真实交通校验；并行指工作之间无需串行等待，不要求使用 subagent。
• 住宿和入选景点未确认前，不生成详细每日路线；路线未确认前，不交付定稿地图。用户明确授权代选时，记录采用的选择即可，不逐项重复询问。必要假设和未核验项要可见。
• 美食与城市名片独立于每日路线：资料就绪即可制作各自页面，无需等待路线确认，也不要求用户逐店确认。默认交付三个独立页面与统一入口；用户明确只需部分成果时遵从其范围。
• 每次产出决策文件，都在对话中给出摘要、默认推荐、理由和少量待决策项，不能只让用户翻文件。
• 收到用户选择或修改后，先记录到数据与状态，再开展后续查询；每个分支完成即保存成果，不等其他分支或网页全部完成才落盘。
• 小红书用于经验与口碑，官方来源用于开放、票务、预约等事实。商业查询价格记录查询时间与适用日期，估算明确标注；查不到不能当作免费、无需预约或已经核验。

工具与文件

按需读取依赖技能，查到结果后继续本阶段，不把一次检索完成当作整趟规划结束：

依赖的下载与安装见 在线安装说明，只在配置环境时阅读；本包不附带依赖源码或小红书操作指南。

所需能力不可用时说明缺口，继续不依赖它的工作。没有取得小红书内容不能声称已做双源研究；没有可靠坐标或路段数据不能声称路线已经验证。

首次写入或接续旧行程时读 输出规范。成果放在 travel_plan/<城市-行程标识>/，按阶段创建，不先造空文件。结构化事实保存在 行程数据.json，金额由 费用跟踪.csv 维护，可读文档和各页面使用这些数据。

① 收集需求与可选大交通

输入： 用户描述、已有文件和预订。

1. 提取城市、日期或天数、人数及成员限制、预算口径、偏好与强度、必去/不去、已有住宿和固定活动；记录已知饮食忌口、必吃项目与餐厅预约，缺少一般口味偏好不阻塞研究。预算默认人均，说明是否包含大交通与住宿；预算、兴趣暂缺不阻塞城市研究，用户明确的预算上限和限制必须遵守。
2. 区分出发日、实际到达、住宿晚数和离开时间，不能把路上过夜算成目的地游玩。只有天数时可以先研究；详细排程前补齐日期和时间边界，或明确以用户接受的假设做草案。
3. 确认大交通是已购买、需辅助规划还是自行安排。需要比较才补问出发地、返程地并调用 FlyAI；比较门到门耗时、价格、换乘、第一天/最后一天可用时间，必要时比较周边机场或高铁枢纽。跳过规划仍记录到离时间和站点。
4. 初始化需求、状态与费用。接受推荐不代表实际购票或预订。

输出： 行程数据.json、行程状态.md、费用跟踪.csv；需要交通比较时生成 大交通方案.md。

交接： 城市和基本时间范围清楚，可开始②③；只补问影响当前工作的缺失信息。

② 推荐住宿区域

输入： 需求、预算、交通节点；可参考③的粗略景点分布，无需等待用户选完景点。

• 网络与小红书两路研究，推荐 1—3 个区域。按交通、主要景点分布、餐饮、安静程度、预算和同行者需求给 10 分制推荐分，并解释优缺点与适用条件。
• 默认只选区域，不提前展开酒店榜单；用户要求具体酒店时再用 FlyAI，已有酒店则直接记录真实住宿。
• 景点筛选后复核住宿是否匹配，明显不匹配时给出取舍，不擅自更换已订酒店。

输出： 住宿区域候选.md；把选中的区域或酒店写回数据和状态，区分区域参考点与真实酒店。

交接： 用户选择已明确。②③可一起汇报，也可分别确认。

③ 推荐并筛选景点

输入： 城市、时间、偏好、预算和刚性要求；住宿位置只作参考，不据此漏掉值得去的远处项目。

• 常规搜索与小红书共同收集景点、街区、美食区域和体验，复用已有攻略。以细读 5—10 篇相关笔记为目标，识别过时、重复与争议信息；取得不足时说明原因，不伪造共识。
• 先扩展候选，再由用户筛选收敛。 “每天 2—4 个”等强度要求约束最终排程，不是初始候选数量。按城市供给与用户偏好覆盖不同类型、片区和有意义的替代项，留出实质性的比较空间；通常多于最终入选数量，不提前裁成刚好可排满的组合。最多 30 个，不凑数；合适选择有限时说明。
• 每个候选给出类型、片区、推荐理由、优先级、停留时长、适合时段、基础门票/预约信息和明显限制。
• 候选阶段先查会改变选择的信息：是否收费、预约难度、已知闭馆或停业等。紧迫放票事项立即提醒，不等全部筛选结束；其余详细核验集中在入选后。
• ②③研究时顺手保存美食线索、景点简介与图片来源，供④复用；候选阶段不必为全部地点补齐照片，用户入选后再深入整理。
• P0 强烈推荐、P1 推荐、P2 有时间再去、P3 替代备选；不必每级都有。模型推荐与用户选择分开，用户必去另记。对话中按类型或优先级呈现候选概览，突出最推荐项目、差异和争议；重点推荐不能代替其余候选的展示，方便用户比较后取舍。

输出： 景点清单.md，持续记录候选、用户选中、备选和排除项。确认后在顶部汇总最终名单，不另复制一份已选清单。

交接： 入选集合明确；可立即开展④A，正式排程仍需住宿明确。

④ 路线规划、美食研究与城市名片并行

输入： 入选与备选地点、需求、已有预约及②③研究结果；B/C 正式排程还需住宿选择和明确的时间边界。

以下 A→B→C 是路线主线；D 美食与 E 城市名片素材可独立推进，不等待每日分配或路线确认。路线确认只约束地图制作；各内容分支完成即可进入⑤制作对应页面。

A. 入选资料与预约前置

• 用官方或可靠来源核验入选项目在出行日期的门票、开放、闭馆、停止入场、预约规则；分别记录建议游玩时段和停留时长，补充到 景点清单.md。
• 有预约事项就先生成 景点预约.md，按需要行动的时间排序。预约规则和放票窗口先查；目标日期、时段与路线联合确定；已经成功预约的时段作为固定约束。无需等住宿确认才研究预约。
• 未放票允许做带前提的草案，预约失败要提供换日、换时段或替代项目。用户采用路线不代表已约成功；规划不自动执行下单或预约。

B. 高德空间规划：每日路线的必要前提

1. 先查位置。 用高德 LBS 获取住宿、入选地点、必要车站与用户固定活动地点的 POI、地址、经纬度和匹配结果。核对同名点、大型景区入口及同一景区内部点；不盲信导入的 KMZ 或名称推断位置。记录坐标系和“经度、纬度”顺序，不混用不同坐标来源。
2. 再理解分布。 依据坐标识别片区和远近关系，考虑河流、道路、围墙与入口绕行。按地理簇分天，并结合预约、闭馆和适合时段调整；不能只按热度排名或机械最近邻排路线。
3. 形成日程草案。 通常从住宿出发并返回；抵达、离开日使用实际交通节点，加入行李与进出站时间。到达日下午可合理利用；离开日倒推交通与候车余量，不能安排赶不上的夜游，可与其他空闲夜晚互换。
4. 用实际交通校正顺序。 为草案中的相邻地点查询适用路线，必要时比较不同顺序。直线距离仅作初筛，不能代替道路距离和耗时；费用无可靠结果时使用当地依据估算并注明。记录查询时间，未来日期不把当前交通结果说成当日保证。

沿用以下查询起点，并根据道路、体力、行李和天气调整：

• 不超过 800 米：优先查 walking，校正步行道路距离与时间。
• 800—1500 米：先查 walking；绕行、疲劳、天气或赶预约时补查打车/公共交通。
• 超过 1500 米：比较步行、驾车与公共交通；接口不适用或步行明显无意义时说明，不机械凑齐结果。
• 不查询骑行。累计步行和景区内部步行也计入体力；无法取得可靠路线时标注未核验，不拿直线距离伪装已验证交通。

C. 把路线排成能执行的一天

• 景点、交通、用餐、休息一起计时；保留排队、取行李和赶车余量。普通用餐保留时间、区域与预算，不等待具体餐厅推荐、不将候选店铺自动排入行程。用户选中的美食街和夜市仍按景点排程；明确必吃或已预约餐厅作为固定需求处理，不能因美食分支独立而漏掉。
• 模型给出默认交通推荐。仅把明显取舍交给用户：例如耗时差小而费用差大、较长步行但体验好、行李/赶预约/高温等特殊限制，或地图结果与现场可达性冲突。
• 检查开放与预约冲突、首尾日边界、总耗时、累计体力、预算及备选是否可用。同一门票、联票或景区内部点不能重复计费、重复计算整段游览时间。
• 入选项目必须有安排或明确解释。放不下时说明冲突和少量取舍，不悄悄删掉用户必去项目，也不靠不合理压缩停留时长凑数。

路线输出： 每日行程.md，包含按天路线、安排理由、相邻交通、用餐时段与区域、休息、当天预约摘要、替代项、费用与检查结果；更新数据、预约和费用文件。按天/路段写短段落，避免超宽表；复杂交通比较才另建专题文件。

路线交接： 用户确认路线；待预约、暂定和未核验项明确保留。关键位置或交通不足、存在未解决硬冲突时，保持草案，不声称可执行性已验证。核心条件变化回到相关阶段，普通路段调整在本阶段完成。

D. 独立美食攻略

• 复用②③线索，继续用网络与小红书搜索本地菜、小吃、饮品和具体店家，读取相关笔记正文，区分亲历体验、推广、争议与过时信息。没有取得小红书内容时明确研究缺口，继续可用来源，不伪造口碑。
• 分清“吃什么”和“去哪吃”：菜品给推荐理由、口味与忌口提示；店家给招牌、具体分店、区域、地址、人均依据、营业时间、排队/预约情况与替代选择。用高德核对门店与位置，动态信息保留来源和查询时间，查不到标待核验。
• 按区域或类型组织，让用户自行选择；不绑定具体日期，不要求先确认路线，不把店家自动加进日程或地图。只记录候选参考价，不将全部推荐店铺入账；路线中的餐饮预算仍正常维护。

输出与交接： 美食推荐.md，结构化事实与来源写回共享数据；资料就绪即可制作 food.html。无需逐店确认；仅在必吃或已有预约影响行程时同步路线约束。

E. 城市名片素材

• 简述城市特色，围绕已入选景点整理看点、游玩提示与对应图片；复用③及 A 的资料，不重做候选筛选，不另建重复的城市介绍、坐标或图片清单。备选若展示必须与入选项区分。
• 查 POI 时尽量同次取得坐标与照片（适用时使用 v3 place/text 的 extensions=all）。保存来源、匹配级别与可用 HTTPS 链接；片区图与菜品/门店图说明对应关系，缺图待补，不用相似地点或菜品冒充，不阻塞路线。

输出与交接： 补充 景点清单.md 和共享数据中的城市简介、景点看点与图片记录；无需每日顺序，资料就绪即可制作 city-impression.html。

⑤ 分别制作页面，统一入口交付

输入： 各分支已整理的资料；地图额外要求已确认的日程、地点与交通数据，以及最新预约和费用。此阶段按分支进入，不设全体等待路线确认的门槛。

• 默认交付 map.html、food.html、city-impression.html 与 index.html；用户已明确只需部分成果时按其范围，不重复问版本。三页独立可打开，美食与城市名片不依赖地图 SDK 或密钥才能阅读。
• map.html 使用高德 JSAPI 展示已确认路线，保留用餐时段，暂不加入美食攻略的具体餐厅点位；用户选中的美食街、夜市仍是路线景点。已有餐厅预约或明确必吃地点按实际约束保留，不能擅自删除。
• food.html 展示区域/类型分组的菜品与店家卡片、选择理由、实用信息、来源与匹配图片，不强行按天分配；city-impression.html 展示城市特色与入选景点图文，不依赖每日游览顺序。缺图给清晰占位或文字卡，不伪造图片。
• 共用当前数据与稳定地点编号，不在做页面时重排路线或重复研究。输出放在本行程目录，默认纯静态、不新增后端；在线地图依赖网络和有效配置。临时预览服务需说明用途及关闭方式，实际运行限制如实告知。
• assets/amap-html-template/ 提供不含具体行程和凭据的地图骨架。仅在本次行程目录使用它，按已确认数据填入标题、日期、点位、路段和说明；空骨架不算完成的地图。美食、城市名片与入口依据本次资料分别生成。
• 地图默认 pitch: 0、rotation: 0，正面朝北。按天分色、显示顺序和方向箭头；合适缩放级别显示地名（旧版约 1.5 公里比例尺仅作体验参考），避免遮挡。住宿、交通节点与景点有区别；列表可定位，手机可读。
• 点位详情展示当天时间、停留、开放/预约、交通和备注。区分点位顺序示意与真实道路路线；真实酒店替代住宿参考点，但附近街区仍保留为独立地点。
• index.html 的导航与样式骨架可和子页同时制作；各页分别验收后接入，完成切换、独立打开/返回与手机检查再交付入口。入口只负责组织页面，不复制维护一份日程；分支尚未完成时准确说明状态，不把空页或失败的地图称为完整手册。

验收： 浏览器检查地图非空、位置和顺序合理、默认朝向、方向箭头、缩放标签、日期筛选及列表定位；抽查 3—5 个点位与最新日程一致，检查手机遮挡。分别打开美食与城市名片检查内容、核心景点覆盖、图片对应与加载，再检查入口切换与公共信息一致。无法加载就报告对应页面未完成，不能仅以文件已生成作为成功。

继续与修改

读取已有数据、状态及本次相关资料 → 记录变化 → 补查受影响信息 → 重算相关日期/路段/费用 → 同步受影响文档与页面 → 汇报变化和待办。只换游览顺序不重做独立美食与城市介绍；变更入选景点、门店或事实时更新对应内容，维持共享信息一致。

只调整受影响部分，保留已发生记录和不受影响的决定；更换酒店同时检查每天首尾交通和费用，不能覆盖街区景点。已订安排若需要改变先说明代价，不把新草案当成已改签或已取消。出发前按需复核易变信息；未受托设置提醒时，不声称会自动监控或代办。