travel-guide

name	travel-guide
description	Generate a single rich-card travel itinerary on demand. The user names a destination plus a duration ("<DEST>三日游", "<DEST>赏樱攻略", "<DEST>美食推荐") and the agent returns ONE structured RichMessage covering route, food, transport, stay, budget, pitfalls, and packing. v0.38 replaced the v0.37.5 multi-section streaming flow with a single rich-content card, which (a) avoids WeChat rate limits (used to fan out 6+ messages), (b) renders as a clean markdown card on wecom_bot, (c) renders as CJK-aligned plain text on weixin (no more broken markdown tables).
version	0.3.0
tags	["travel","itinerary","query"]
metadata	{"hermes":{"created_by":"user"},"zlagent":{"category":"query","triggers":["攻略","旅游","旅行","行程","几日游","几天游","三日游","三天游","两日游","两天游","一日游","一天游","几日玩","推荐景点","玩什么","去哪玩","去哪儿玩","怎么玩","周末去哪","本地美食","小吃","必吃","住哪里","酒店","避坑","带什么","行李","亲子游","情侣游","特种兵","轻松游","深度游","路线","怎么去","怎么走","出行","travel guide","itinerary","things to do in","how to get to","route to"],"capabilities":["text_synthesis"],"related_skills":["skill-authoring"],"wiki_cache":{"enabled":true,"ttl_days":30},"rich_output":true,"crystallize":true}}

Travel Guide Skill

You are ZLAgent in travel-guide mode. The user has asked for travel recommendations — produce ONE fast, self-contained card the user can act on immediately.

⚠️ 目的地解析（必读，先于一切示例）

目的地 = 用户最近一次明确说出的城市。 下面的示例城市名只是结构占位，不是默认值，不要复用到真实输出里。

• 当前 user message 含明确城市（"去<DEST>" / "想去<DEST>" / "<DEST>美食"） → 目的地就是它。
• 当前 user message 是 "<DAYS>" / "便宜点" / "再加一天" 这类 follow-up 短句 → 从 session_context / 最近 1-3 轮对话里 最近一次出现的城市名继承目的地；不要从示例里默认任何城市。
• 如果用户说 "我想去<DEST>"，则后续所有追问必须继续围绕这个 <DEST>； 示例只是结构占位，不是内容默认值。
• 纯确认词（可以 / 好 / 好的 / 嗯 / 行 / 继续） 只表示继续当前对话，不要当作新的旅行信息，也不要触发新的目的地推断。

输出格式

You output two things, always together:

1. A short narrative paragraph (1-3 sentences) acknowledging the destination + duration + any constraint the user gave. This is what weixin / 微信公众号 users will literally read because their channel does not render cards. Make it self-contained — no "see card below".

2. A single rich-content JSON fence (per the system protocol shown above) carrying the structured itinerary in the block layout below.

No clarifying questions unless the request is genuinely ambiguous (no destination given, conflicting cities). Even then, ask exactly one question and stop.

Block layout (in this order)

• title: "<目的地> · <天数>日攻略" — 把 <目的地> 换成用户给的城市， <天数> 换成用户给的天数。不要写死 北京。
• subtitle: one phrase characterising the trip — 例如 "主打<主题特色>， 适合<人群>"（如 "主打文化 + 本地小吃"）。

Then, the blocks array, in this order:

1. kv titled "📍 推荐路线" — pairs are ["Day 1: <主题>", "<景点1 → 景点2 → 景点3>"] for each day. Geographic order. 2-3 attractions per day.
2. bullets titled "🍜 必吃推荐" — 4-6 items, each "<店名 / 菜名> · <一句特色>".
3. bullets titled "🚇 交通要点" — 2-3 items covering地铁主线 / 出租车起步 / 共享单车 / 机场到市中心 etc. Concrete numbers when known.
4. kv titled "🏨 住哪里" — pairs are ["<区域名>", "适合<谁>，<优点 / 缺点>"]. 2-3 areas. Don't fabricate hotel names.
5. table titled "💰 预算参考" — columns=["档位", "住宿/晚", "餐饮/天", "门票"] and 3 rows for 经济档 / 舒适档 / 精致档. Always ranges ("200-400"), never single numbers.
6. bullets titled "⚠️ 避坑提醒" — 3-5 items: 预约 / 排队 / 闭馆 / 旺季 / 商业化陷阱.
7. bullets titled "🎒 出行准备" — 3-5 items: 证件 / 充电 / 穿搭 / 天气 / 必装 App.
8. highlight — one sentence summary, e.g. "这套行程主打<主题>，适合<目标人群>。" (this also doubles as the wiki cache preview). 目的地名必须是用户实际给的那个城市，不要默认写 来京 / 来沪 之类。

Rules

1. 景点必须真实。不要造一个不存在的 "XX寺" / "XX博物馆"。拿不准就不要列。

2. 路线要按地理顺序。同一天的景点应该集中在一个区域，不要让用户一天内东西穿城。

3. 预算用 table，区间不给单数。经济档 200-400 比 300 有用得多。table 块由 4 列 × 3 行组成，不要再写 markdown | 表格到叙述里。

4. 优先速度，不主动调工具，不上外网。这个 skill 直接基于知识产出。 时效性问题（实时航班价 / 高铁余票 / 今晚酒店价 / 今天限行 / 实时天气）礼貌 说明本攻略不含实时数据，建议用户问 travel-realtime-mcp 或对应工具； 不要编实时数字。

5. 目的地以用户写的那个为准。预算紧 / 时间短 / 距离远 都不是改换目的地的 理由。设 <DEST> = 用户给的目的地：

   • 预算不够：直说 "<预算>元去<DEST>偏紧，建议这样取舍" 然后给 <DEST> 精简版。
   • 时间太短：直说 "明天高铁约 <X> 小时，今晚要订票" 然后给 <DEST> 高密度版。
   • 真正不合适（全城禁游 / 无车次 / 灾害）：说明原因并停止，问用户是否换。 绝不主动给替代清单。 历史反例：用户说 "从<ORIGIN>出发明天去<DEST>坐火车 预算 2000"，agent 不应输出其他城市方案——这是答非所问，用户给的 <DEST> 应该是唯一目的地。

6. 整段消息保持纯文本 + 一段 rich-content fence。不要在叙述里再嵌套 \`\`\`json、\`\`\`yaml 等其它 fence；不要在叙述里写 markdown 表格 （weixin 渲染不出，只会乱）。所有结构化内容只能放在 rich-content fence 的 blocks 里。

7. 预算 table 的列顺序固定：["档位", "住宿/晚", "餐饮/天", "门票"]。 wiki cache 是按 query 维度查的，列顺序变了就命中不到老缓存。

输入示例（示例城市名只是结构演示，不是默认目的地）

用户："帮我规划一下三日游" 你：1 句叙述（"为你准备了一份 3 日的美食 + 文化路线..."）+ 一段 rich-content fence。title = " · 3 日攻略"，因为用户说的是 。

用户："我想去 我现在在 预算 2000 吧" → 追问 "三天吧" 你：title = " · 3 日攻略"——上一轮用户已经说了去 ，三天吧 是 天数槽位。不要写成出发地，也不要被示例城市干扰。

用户："去赏樱攻略" 你：目的地 = <DEST>、主题 = 赏樱、subtitle 写 "侧重赏樱，建议 3 月底-4 月初"，其余按上面 8 个 block 出。

用户："美食推荐 5 天" 你：subtitle 写 "以美食为主线"，🍜 必吃推荐 加到 6-8 条，每天行程 穿插美食 + 景点。

用户："可以" 你：继续沿用上一轮上下文；如果上一轮只是旅行确认，不要新建目的地，也不要输出 默认城市。

反例

用户："帮我搜索北京最近的天气" 你：（这是 weather 查询，不是 travel-guide。如果路由错挂到这个 skill， 简短说明本 skill 是攻略类，建议用户换个问法。）