| name | travel-answer-format |
| description | 旅游规划最终输出范式。Use when producing the final answer for a travel itinerary, POI recommendation, city route, day plan, or scenic spot plan; format each stop with a title, distance, recommended transit, maximum wait when available, travel duration, reason to visit, and a brief introduction. |
旅游规划最终输出范式
目标
本 Skill 用于旅行规划的最终回答阶段。它把已经验证过的地点、距离、路线和攻略信号整理成稳定、可执行、便于用户照着走的格式。
只有在需求澄清完成、关键地点已通过地图工具验证后，才使用本格式输出最终方案。不要为了满足格式而编造公交线路、等待时间、距离、开放状态或评价。
总体结构
answer 字段内使用 Markdown 文本，建议结构如下：
# [目的地][时间]旅行方案
## 规划假设
- 出发/住宿：...
- 时间：...
- 交通：...
- 节奏：...
## 路线总览
上午/下午/晚上按顺序写 2-4 个主停留点，并说明为什么这样顺路。
## 第 1 天：[路线主题]
### [地点名]
距[起点/上一站]约[X]km。推荐[交通方式/线路]，从[上车点]到[下车点]；若需步行接驳，写清步行距离或时间。
- 最多等待：约[X]分钟。若地图工具未返回候车/发车间隔，写“高德未返回最多等待时间，以当日实时班次为准”。
- 路程时间：约[X]分钟；其中车程/步行/换乘分别说明，信息不足时标注“估算”或“待实时确认”。
- 为什么推荐：结合用户偏好、路线顺路性和攻略素材信号说明，不只写“很热门”。
- 简单介绍：用 1-2 句介绍这个地方是什么、适合看什么或体验什么。
- 注意事项：人流、天气、体力、营业或替代点；没有就省略。
每个地点块必须包含的信息
每个主停留点都用 ### 地点名 作为小标题。正文必须尽量包含：
距离：距起点、住宿地或上一站多远。推荐交通：公交、地铁、步行、骑行、打车或自驾；有线路号时写线路号，没有验证到线路号时不要编造。最多等待：仅当地图工具、公交班次或明确资料返回时写具体数值；否则如实写无法确认。路程时间：总耗时、车程、步行接驳、换乘数或驾车时间。为什么推荐：说明它匹配用户偏好、顺路逻辑、慢游价值或攻略素材信号。简单介绍：简短介绍地点本身，让用户知道去看什么。
用户示例对应的理想形态：
### 梅花园
距住宿地约 5km。推荐乘坐 666 路公交，从 A 站到 B 站，下车后步行约 300m 到达。
- 最多等待：约 12 分钟。
- 路程时间：全程约 35 分钟，其中公交约 25 分钟，步行接驳约 8 分钟。
- 为什么推荐：它和下午的街区路线顺路，花期/园林体验也符合你想要的轻松散步节奏。
- 简单介绍：梅花园以梅花观赏和园林步道为主，适合慢慢走、拍照和安排半小时到一小时的停留。
事实与建议标注
最终回答必须区分两类信息：
高德已确认：地点名称、地址/区县、坐标、距离、路线、交通耗时、周边 POI。攻略/主观信号：为什么值得去、避坑、人流感受、适合人群、本地体验。
推荐写法：
高德已确认：梅花园距住宿地约 5km，公交路线可达。
攻略/主观信号：这里更适合慢节奏散步，不适合赶时间打卡。
如果某项没有被工具确认，必须写：
- “待实时确认”
- “按当前信息估算”
- “高德未返回该字段”
- “需要补充住宿地后重新优化”
不要使用“应该”“大概有某公交”“一般等几分钟”来伪装事实。
多日行程格式
多日行程按天输出，每天一个主题：
## 第 1 天：老城慢行
### 地点 A
...
### 地点 B
...
## 第 2 天：自然和博物馆
### 地点 C
...
每天最后补充：
这一天为什么顺：说明地理聚类、少换乘、少折返。附近备选：雨天、太累、人多时可替换的 1-2 个地点。出发前确认：只列真正需要用户临行确认的信息，例如开放时间、实时公交、预约。
风格要求
- 直接给用户可执行建议，不写产品说明或内部流程。
- 不堆表格；除非用户明确要求表格，否则用小标题和短段落。
- 每个地点介绍控制在 4-6 行左右，避免写成百科。
- 优先讲“为什么适合这个用户”和“怎么去最省心”。
- 如果路线验证和攻略热度冲突，路线可行性优先。
- 如果信息不足以达到该格式，回到需求澄清，不要输出半真半假的最终方案。
