# Travel Planner Pro

> 用于生成中文旅行攻略、自由行路线、城市多日游、周末短途、自驾路书、亲子/老人/情侣/独旅/商务/穷游/轻奢/无障碍/中转短停规划。当用户需要目的地玩法、分日行程、住宿交通、美食、预算预订、天气策略、官方预约入口、近期活动或飞书旅行文档时使用。不用于代替官方签证、交通、天气或票务最终确认。

- Skill: `ahang1598/travel-planner-pro` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add ahang1598/travel-planner-pro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/travel-planner-pro/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/travel-planner-pro

---


# Travel Planner Pro

## 概述

把用户模糊或明确的旅行想法，转成可执行、可核验、可交付的中文飞书旅行攻略，并**默认直接创建飞书/Lark 文档**。优先解决真实出行决策：值不值得去、怎么取舍、住哪里最顺、每天怎么玩、怎么移动、吃什么、花多少钱、哪些事项必须预订或复查。天气、堵车、排队、疲劳、预约失败等只作为辅助兜底，不要抢走攻略主线。

## 默认交付契约（唯一出处，详细规则见 `references/feishu-workflow.md`）

- 用户已选本技能时，默认主交付物是**真实创建的飞书/Lark 旅行文档**，最终回复只给标题 + URL + 出发前复查项，**不粘贴正文**。
- 默认用 XML 富文本创建；用户明确要 Markdown/Word/HTML/PDF 或飞书工具不可用时才切换。
- 即使用户只说“写一个旅游攻略/南京怎么玩/端午去呼和浩特”，也默认创建飞书文档；只有明确说“只要文字/Markdown/不要创建文档”时不创建。
- 信息不全也先创建文档，最多 3 个澄清问题放文末“仍需确认”，不要在开头堆“默认假设”。
- **正文只写旅行内容。** lark-cli 版本、auth/skills 子命令、认证、权限、scope、token、fallback、替代方案等执行状态**只能出现在最终回复的失败说明里**，绝不写进正文。
- **正文禁止出现 HTML 表单或裸代码。** 复选清单只能用飞书 XML `<checkbox done="false">事项</checkbox>`；Markdown/降级稿才用 `- [ ] 事项`。绝对不要写 `<input type="checkbox" />`、`<button>`、`<select>`、`<textarea>`、`<label>`、`<form>`，也不要把这些标签转义成 `&lt;input...&gt;` 后放进正文。
- **XML 只用白名单组件。** 允许：`title/h1/h2/h3/p/b/i/br/callout/grid/column/table/thead/tbody/tr/th/td/checkbox/bookmark/blockquote/hr`。不要自造 `<card>`、`<food-card>`、`<route-card>`、`<section>`、`<timeline>`、`<badge>`、`<tag>`、`<panel>`、`<tabs>` 等标签；飞书可能原样显示。所谓“路线卡/美食卡/预算卡”必须用 `callout + grid + table` 组合实现。
- 只有飞书工具不可用/认证失败/权限不足/命令失败时才降级（同结构 Markdown + visuals/ + 复查清单），必须说明“未创建飞书在线文档”，不要假装已创建。
- 文末不加“来源/信息来源/参考资料”等来源章节，也不加“关于本攻略/由某 skill 生成/欢迎分享/祝旅途愉快”。必要来源、官方入口、地图入口放对应事实或 bookmark 附近。

## 不可跳过的 8 步流程

弱模型按编号执行，**不要跳步**。第 7 步是硬门控。

**1. 确定任务边界 + 提取约束** — 默认按飞书旅行文档推进，只有用户明确指定其他格式才切换。提取：出发地/目的地或候选区域 / 具体日期/月份/天数/是否节假日 / 同行人（人数/年龄/老人儿童/行动能力）/ 预算 / 交通偏好 / 兴趣 / 住宿偏好 / 忌口证件国籍签证状态/必须去或避开。常见不完整提问先合理推断并继续：“端午节/国庆/五一/春节”用对应假期窗口并查当前年份绝对日期写明；“去南京怎么玩”默认第一次去、2–3 天、适中节奏、公共交通为主。能合理推断就继续，不要频繁追问。

**2. 场景路由** — 用下方路由表选 1 条主线，决定读哪 1–2 个 reference（**不要默认读全部**）。

**3. 做场景指纹 + 定标题** — 内部定 6 件事（真实目的/专属词/第一屏先答什么/本文像哪种材料/主角配角模块/版式功能），不写进正文。然后用标题公式生成 `<title>`，含目的地+天数/日期+同行人/预算/主题，形态词从{路线、路书、地图、雷达、日历、清单、时间账、决策表、手册、玩法}选 1。**禁止默认 `XX旅游攻略/XX旅行计划`。** 公式见 `scenario-and-richness.md §2`。

**4. 核验当前信息** — 只要用户给了具体目的地/日期/节假日/景点/交通/签证/预算/住宿餐饮推荐，就核验当前信息：签证入境、天气、官方开放时间、预约/购票窗口、交通班次、路线中断、安全提醒、汇率、动态价格。规则见 `references/source-and-validation.md`。把来源放对应事实附近，用 `实查/参考/估算` 标注，动态价格提醒锁价前会变。**联网核验不是装饰。**

**5. 构建路线 + 生成 XML 内容** — 先过“清晰路书骨架”门控，再做富文本结构。执行可行性门控（见 `references/planning-standards.md`）：每天围绕 1 个主区域；休闲每天 2–3 个点位（亲子/老人/倒时差/高温更少）；到达返程日轻量；每 3–4 天半天缓冲；每段交通写明方式/耗时/费用/衔接风险；只在关键风险处给轻量备选，不把雨天/堵车/疲劳/预约失败写成每个 Day 的主内容；每天有清楚主线、时段安排、交通步行、用餐落点和可删减项；先推荐住宿区域再推荐具体酒店。用 `feishu-workflow.md §6` 的表格 schema 和 `§4` 的 XML 骨架填内容，但忽略其中所有图片/插图要求。内容用 `references/ideal-travel-guide.md` 校准理想态。每个 Day 的主体必须是“怎么玩”，辅助兜底通常 1–2 句或 1 个紧凑表格即可。**XML 正文只写正常旅行内容，不写 `<img href>`、不写 `<!-- 插图位置 -->`，也不写图片锚点、caption、source 等内部字段**。

生成正文时先做组件白名单检查：所有富文本效果只能落到 `callout/grid/table/checkbox/bookmark/blockquote/hr` 上。不要为了“卡片感”写 `<card title="...">...</card>`；应写成 `<callout>` 或 `<grid><column><callout>...</callout></column></grid>`。

**6. 写 .xml + 内容深度自检（硬门控）** — XML 写到 `outputs/[目的地]-[yyyy-mm]/[目的地]-[天数]天飞书导入稿.xml`，用 `--content @file.xml`。创建文档前必须自检：路线是否顺路、信息是否当前、每天是否有主线和撤退点、吃住行预算预约是否闭环、特殊人群和天气风险是否处理、模块是否充盈。若任何主要 H2 只有一句话或一张薄表，必须展开或合并。**不创建 image-plan.tsv，不下载图片，不搜图，不生图，不跑图片脚本。**

**7. 创建飞书文档** — 建文档（XML 里只有正常正文，不带图、不带图片注释）：
```bash
lark-cli docs +create --api-version v2 --as user --doc-format xml --content @outputs/[目的地]-[yyyy-mm]/[目的地]-[天数]天飞书导入稿.xml
```
拿到真实 URL。然后验证文档结构：
```bash
lark-cli docs +fetch --api-version v2 --doc "<URL>" --scope outline
```
确认 outline 清晰、标题层级正确、主要模块完整；如能回读正文，检查没有 XML 标签/内部字段泄露。若创建失败：不要把错误写进文档；在聊天回复说"本次未能创建飞书文档，原因：___，可重试：___"，给本地 .xml 路径。

**8. 交付前自评 + 最终回复** — 最终回复前先做"交付前自评"（见下方"交付前自评"小节，三类检查：文档结构/事实逻辑/内容丰富度），发现问题改了再交付。然后只回：文档标题 + 飞书 URL + 出发前复查项。**不粘贴正文。**

## 场景路由表

| 用户核心场景 | 主线 | 第一屏先答 | 必读 reference（最多 2 个，额外于必读） |
|---|---|---|---|
| “X 旅游攻略/X 怎么玩/X 几天怎么玩” | 完整规划 | 推荐天数、最顺路线、适合人群、最大风险 | `planning-standards.md` + `ideal-travel-guide.md` |
| 只问“去哪玩/某地值不值” | 目的地对比 | 推荐哪个、淘汰理由、下一步 | `destination-selection.md` |
| 美食/吃什么/夜市/小吃路线 | 美食主题 | 吃什么、住哪里最顺路、按什么街区时段吃 | `scenario-and-richness.md §6④` + `planning-standards.md` |
| 周末/下周末/近期活动/city walk | 周末城市短途 | 这周末最值得做什么、活动绝对日期、票务风险 | `competitive-upgrade.md §一` + `source-and-validation.md`（周末活动核验） |
| 亲子/老人/行动不便/带娃 | 舒适低风险 | 步行强度、午休、厕所电梯、室内备选 | `planning-standards.md`（特殊约束） + `scenario-and-richness.md` |
| 自驾/环线/公路旅行 | 自驾路书 | 每天驾驶强度、补给停车、撤退方案 | `planning-standards.md`（自驾标准） + `competitive-upgrade.md §四` |
| 出境/日本/欧洲/东南亚 | 出境自由行 | 签证入境、支付通信、城市交通 | `planning-standards.md`（出境约束） + `source-and-validation.md` |
| 中转/转机/半日 | 短停风险 | 是否建议进城、保守/进取路线、最晚撤退时间 | `planning-standards.md`（中转短停） |
| 穷游/省钱/机酒预算/积分里程 | 预算优化 | 总成本、现金/优惠/积分取舍、预订路径 | `competitive-upgrade.md §二/三` + `source-and-validation.md` |
| 已有行程要优化 | 行程审查 | 哪些保留、哪些删改、为什么不可行 | `planning-standards.md`（可行性门控） |
| 酒店/交通/美食/预算单项 | 聚焦单模块 | 该模块的直接答案 | `planning-standards.md` 对应小节 |
| Word/HTML/PDF/路书 | 文件交付 | 按指定格式生成 | `deliverables.md` |

**所有场景都默认读** `references/ideal-travel-guide.md`（校准理想态）和 `references/feishu-workflow.md`（飞书交付契约）和 `references/scenario-and-richness.md`（标题/首屏/H2/内容丰富度）。上表“必读”是在此基础上**额外**读的场景文件，最多 2 个。

## 清晰路书骨架（不是固定目录）

完整攻略先清晰，再好看。下面是信息骨架，不是固定标题或固定顺序；按用户场景重组，但创建文档前必须能在正文里找到这些能力：

- **一句话怎么玩**：第一屏要让用户知道最顺主线、住哪里更省事、最大风险是什么；不要先堆封面图、默认假设或百科介绍。
- **天气/季节策略**：有具体日期且在可预报范围内时查天气预报，写气温、降雨/高温/低温/风等对行程的影响；日期较远或未给日期时写月份/季节气候、雨季/台风/雪季/高温/花期等风险，并放入出发前 48 小时复查。
- **路线总览**：用户能扫出每天住哪里、玩哪个区域、为什么这个顺序、当天最容易出问题的点。
- **每天怎么玩**：不是景点清单。每个 Day 要有时段顺序、交通/步行、用餐落点、预约/排队提醒和可删减项；雨天、堵车、太累、预约失败等只在当日确有风险时轻量写 1–2 条，不要每一天都展开成大模块。
- **预订入口与链接**：核心景点/演出/博物馆/酒店/跨城交通/签证入境/热门餐厅或排队平台必须就近给可执行入口。只有确认 URL 真实可打开时才写 `<bookmark>`；不能用空链接、假链接、`example.com` 或猜测出来的店铺 URL。不确定 exact URL 时，不写 bookmark，改写成“在官方小程序/公众号/地图 App/美团/大众点评搜索：城市 + 名称”的复查动作。
- **美食链接**：美食部分可以给美团、大众点评、地图 App 或餐厅官方入口；具体店铺链接必须来自真实可打开页面。无法确认单店 URL 时，可以给美团/大众点评/地图的真实首页或搜索入口 bookmark，并在正文写清搜索词，不要伪造单店链接。
- **版式服务路线**：grid、callout、table、checkbox、bookmark 只服务认路、点单、预算、预订、天气和风险，不随机堆彩色块。一个主要 H2 附近最多连续 2 个同类组件；不要三张表/三个 callout 连续堆叠而没有解释。
- **模块节奏**：主要模块尽量形成“取舍解释 → 执行动作/表格 → 变化处理”的阅读节奏；若某模块只有一句话，合并或展开，不要留薄章节。

## 必填富 block 与内容深度清单（完整攻略）

完整飞书攻略不需要图片，但必须同时满足“内容深”和“结构清”两条底线：

**内容深度底线**：

- 每个完整攻略必须覆盖路线逻辑、每天怎么玩、住宿区域、交通衔接、美食点单、预算预订、天气季节、风险备选、出发前复查。
- 每个 Day 至少包含：今日主线、时段安排、交通/步行、用餐落点、预约/排队提醒和可删减项。辅助兜底只在关键风险处出现，不做固定大章节。
- 主题题要把主角模块展开：美食主题要解释吃什么、为什么吃、去哪吃、怎么顺路吃；老人/亲子要写步行强度、午休、厕所电梯、室内备选；预算题要写钱花在哪、哪里能省、哪里不能省。
- 不允许 H2 下面只有一句话或一张薄表。薄模块要么展开为“取舍解释 + 执行动作 + 现场调整”，要么合并到相邻模块。

**富文本结构底线**：

- ≥3 个语义色彩 callout（蓝/绿/黄/灰，不同含义不同色）。
- ≥1 个 grid/分栏，用于住宿取舍、路线备选、预算分档、老人/亲子节奏对比等。
- ≥2 个 table，用于分日路线、预算、交通、餐食、预订窗口、风险备选等。
- ≥1 组 `<checkbox done="false">...</checkbox>`，用于出发前复查或当天执行清单。
- ≥1 个 bookmark（真实可打开 URL，非 example.com/空链接/猜测链接）或 blockquote，用于官方预约、交通/地图/票务入口或重要提醒。
- ≥2 个场景卡片（路线决策卡、Day 主线撤退卡、住宿取舍卡、美食点单卡、预算预订卡、风险补救卡、Q&A 卡）。
- 富 block ≥5 类；主要 H2 附近至少 1 个非纯文本组件；H2 泛标题 ≤2 个；≥60% H2 含目的地/天数/街区/人群/预算/活动等场景词。

**严禁图片流程**：

- 不搜图、不生图、不下载图片、不创建 `image-plan.tsv`、不运行图片脚本、不调用 `+media-insert`。
- 正文不写 `<img>`、图片锚点、caption、source、图片失败说明或任何内部媒体字段。

## 无图片版丰富度协议

没有图片时，要用信息密度和飞书结构弥补，而不是让文档变成纯列表：

1. **用路线卡替代风景图**：把“为什么这样走、当天主线、删减项、撤退点”做成 callout 或 grid。
2. **用点单卡替代美食图**：每道重点菜写口味、适合时段、推荐街区、点单避坑、排队替代。
3. **用住宿取舍表替代酒店图**：写区域、适合人群、通勤优势、夜间安全、价格带和不适合谁。
4. **用预算表替代价格截图**：写实查/参考/估算、现金支出、可省项、不可省项、预订窗口和退改风险。
5. **用轻量补救卡承接风险**：天气差、排队长、体力不足、预约失败、交通延误只写对主线有影响的处理动作，通常合并为 1 个紧凑 callout 或表格，不要喧宾夺主。
6. **用 Q&A 替代长尾说明**：把用户最可能问的“住哪、吃哪、删哪、下雨怎么办、老人孩子累不累”集中答清。

## 内部判断顺序（驱动内容质量，不写进正文）

生成前先在内部完成，不要固定写成章节：

- 用户真实需求：省心/拍照/吃美食/亲子轻松/老人舒适/情侣氛围/文化深度/户外挑战/自驾风景/穷游性价比/只想知道值不值得去。
- 行程边界：出发地/日期/天数/同行人/预算/交通/住宿偏好/签证证件/体力/忌口。
- 季节与时效：天气/节假日/花期雪季雨季台风高温/闭馆日/预约窗口/当前价格/交通状态。
- 目的地结构：核心城区景区/交通枢纽/住宿区域/餐饮集中区/夜间活动区/容易踩坑的远距离点位。
- 路线骨架：按区域聚类，先确定住哪里，再排每天主线和备选。
- 旅行者体验：每天步行量/换乘次数/排队时间/午休/亲子老人厕所电梯/行李寄存/夜间安全。
- 决策密度：哪些必须具体到店/站/票，哪些只推荐区域。
- 复查动作：出发前 30 天/7 天/48 小时/当天分别确认什么。

**不要暴露内部身份、工具名、开源参考、生成流程或方法论。** 直接给结论和取舍。

## 执行原则（要点）

- 默认中文输出。
- 先给有立场的方案，再解释关键取舍。避免百科式堆资料。
- 先做旅行决策，再写旅行文案：好攻略 = 路线取舍 + 时间交通 + 预算预订 + 备选风险 + 图文路书。
- 对近期周末/一个月内城市短途，必须补“近期活动层”（展览/演出/集市/球赛/博物馆特展/限时优惠/热门街区/city walk/地铁可达性），活动日期必须是未来或覆盖出行窗口，不要把过期新闻当推荐。
- 对真实旅行计划，必须核验当前信息，不能凭印象编造开放时间、票价、班次、签证规则、酒店餐厅状态或天气。
- 每日路线按地理聚类、体力消耗、营业时间、交通缓冲编排，不要把景点自由堆叠成不可执行清单。
- 价格用区间和可靠度标注（`实查`/`参考`/`估算`），动态价格提醒出行前确认。
- 涉及机票/酒店/门票/演出/积分里程时，给“预订路径”和“成本矩阵”（现金价/积分或优惠价/总现金支出/便利度/风险/取消政策），不只给低价结论。
- 明确指出风险和避坑：关闭日、预约窗口、季节陷阱、天气影响、交通衔接、节假日拥挤、无障碍限制、海拔/高温/台风等。
- 文档架构按场景变化，不要都套同一个目录。标题/首屏/H2 规则见 `scenario-and-richness.md`。
- 不把本地档案、旧行程或用户画像带入回答，除非用户明确提供。
- 不要在攻略正文或文末暴露 skill 名称、生成方式、内部方法论或“由某工具生成”。

## references 索引

| 文件 | 何时读 |
|---|---|
| `feishu-workflow.md` | **必读**。飞书交付契约、创建流程、内容/版式平衡、表格 schema、组件建议、降级、交付检查。忽略其中所有图片/插图要求 |
| `ideal-travel-guide.md` | **必读**。理想攻略标准、5 个核心问题、内部判断顺序、内容主线、场景化架构、质量门槛 |
| `scenario-and-richness.md` | **必读**。场景指纹、标题公式、首屏决定顺序、H2 规则、反模板自检、8 类内容丰富度、版式层次 |
| `planning-standards.md` | 构建路线时。可行性门控、路线构建流程、每日节奏、地理逻辑、交通/住宿/餐饮/预算标准、预订时间线、成本矩阵、特殊约束（出境/高海拔/天气/无障碍/中转） |
| `source-and-validation.md` | 依赖当前事实时。信息源优先级、必核验项目、可靠度标签、信息冲突、引用习惯、搜索模式、周末活动核验、多来源 fallback |
| `competitive-upgrade.md` | 周末城市调研/机酒预算/积分里程/穷游/地图点位时。周末短途调研、成本矩阵、预订路径、酒店比较、地图 POI、隐藏亮点、搜索 fallback |
| `destination-selection.md` | 用户不知道去哪、只给大区域/季节/天数/画像时。候选发现、筛选维度、对比输出 |
| `deliverables.md` | Word/HTML/PDF/Markdown/tripData 或降级交付时。交付物选择、文件组织、各格式要求 |
| `open-source-capabilities.md` | 需要借鉴开源旅行技能能力时。能力地图、触发条件、工具优先级、输出增强清单 |
| `anti-template-composition.md` | 发现输出结构模板化、标题/章节雷同、需要反模板构图时。动态目录、首屏入口和模块组合规则 |
| `experience-richness.md` | 内容偏薄、缺少取舍说明/现场调整/体验细节时。补充执行体验、场景 Q&A 和可删减项 |
| `feishu-document.md` | 需要更细的飞书文档排版、文档结构和富文本平衡规则时。忽略其中所有图片要求 |
| `lark-workflow.md` | 需要直接执行 lark-cli 创建/更新流程时。不要执行插图流程 |
| `output-templates.md` | 需要套用或改写 XML/Markdown/飞书组件模板时 |

## 质量检查

最终回复前，完成手动质量门控，且：

- 方案真的回应用户约束，不是泛泛游客画像？
- 时效性事实已核验并披露不确定性？周末/近期短途锁定了绝对日期并核验活动举办日期？
- 每天路线在交通时间和体力上真实可行？酒店/美食/交通和当天路线地理位置匹配？
- 预算内部一致并贴近用户范围？预订建议有路径（哪里订/何时订/先确认什么/失败替代）？
- 达到无图片版富文本底线（≥3 callout/≥1 grid/≥2 table/≥1 checkbox/≥1 bookmark/≥3 语义色/≥2 场景卡）？
- 内容是否足够深：每天主线、交通、用餐、预约、预算和可删减项都写清了吗？辅助兜底是否克制，没有压过主体攻略？没有 example.com、空链接或猜测 URL？
- 文末没有来源章节和自我披露/营销尾巴？
- 每个 Day 有今日主线、时段安排、用餐落点和可删减项？雨天/排队/疲劳/预约失败是否只在必要处轻量出现？
- 标题和 H2 场景化，H2 泛标题 ≤2 个？每个主要模块有解释+执行+调整中至少两类？
- 正文没有 lark-cli 版本/auth/权限/fallback 等内部状态？
- 最终回复只有标题 + URL + 出发前复查项，没有粘贴正文？

## 交付前自评（三类检查，不可跳过）

质量脚本只查结构，查不了事实合理性。最终回复前必须自己过一遍下面三类，发现问题就改了再交付。

### 1. 文档结构自评

- **无图片流程**：正文和本地输出里不能出现 `image-plan.tsv`、`media-insert`、`image_gen`、`生成图`、`搜图`、图片锚点、caption/source 等内部媒体字段。
- **富文本密度**：是否有足够的 callout、grid、table、checkbox、bookmark、blockquote、hr？有没有连续大段纯文本或连续三张薄表？
- **场景卡是否有效**：路线决策卡、Day 主线卡、住宿取舍卡、美食点单卡、预算预订卡是否真的帮助执行？风险补救卡是否克制、只做辅助？
- **信息层次**：第一屏是否先给最顺路线、住哪里、最大风险？H2 是否有目的地/街区/人群/预算/活动等场景词？

### 1.5 XML 字段泄露自检

- **XML 标签/注释泄露**：用 `lark-cli docs +fetch` 拉回文档内容，检查正文里有没有 XML 标签（`<callout>`/`<grid>`/`<table>` 等裸标签）、`<!-- 插图位置 -->` 注释、`caption="..."`/`anchor="..."`/`source="..."` 这类**给工具/脚本看的内部字段**泄露到用户可见正文。有 → 删掉，只留正常攻略文字和飞书组件渲染结果。
- **HTML 表单泄露**：正文里不能出现 `<input type="checkbox" />`、`&lt;input type="checkbox"...&gt;` 或其他 HTML 表单标签。飞书 XML 复选框写 `<checkbox done="false">事项</checkbox>`；如果是 Markdown 降级稿才写 `- [ ] 事项`。
- **工具状态泄露**：正文有没有 `lark-cli`/`auth`/`scope`/`token`/`+create` 这类命令/工具名？（只能出现在最终回复的失败说明里，不能进正文。）

### 2. 事实逻辑自评（真实性，旅游红线）

逐条对照，踩中任一就改：

- **一天景点过多**：有没有一天安排 5 个以上主要景点？休闲每天 2–3 个，亲子/老人/倒时差更少；一天 10 个景点不行。
- **跨区乱跳**：有没有一天跨多个主区域、来回折返？每天应围绕 1 个主区域。
- **开放时间/闭馆**：景点开放时间、闭馆日、停止入场、预约窗口有没有核验当前信息？有没有把周一闭馆的博物馆排进周一？
- **交通不现实**：交通时间有没有 buffer（安检/换乘/最后一公里）？跨城/转场有没有留足时间？末班车/末班船查了吗？
- **到达/返程日**：到达日和返程日是不是轻量安排？有没有到达当天排满景点？
- **预算不一致**：分日行程里安排了包车/热门门票/酒店升级，预算表有没有体现？预算表写节省型，路线是不是给了公共交通替代？
- **预订路径真实**：预订建议（哪里订/何时订/退改）是不是具体可执行？bookmark 是否真实可打开？有没有空链接、假链接、猜测链接或“某平台”这种含糊说法？
- **过期活动**：近期活动/展览/演出是不是按举办日期核验的？有没有把过期活动当推荐？
- **天气/季节风险**：雨季/台风/雪季/高温/高海拔有没有提醒和备选？
- **特殊人群**：亲子/老人/行动不便有没有少台阶、午休、厕所电梯、室内备选？

### 3. 内容丰富度自评（切实可行，不为丰富而丰富）

- **看得懂、做得到**：每天给的是具体可执行内容（时段+点位+交通+用餐+预约+备选），还是空话（"感受城市魅力""随便逛逛"）？
- **有没有为丰富而丰富**：有没有和用户目标无关的模块凑数？删掉。用户问美食，就别大篇幅写不相关景点。
- **逻辑清不清楚**：用户能顺着"为什么这么走 → 怎么走 → 现场怎么改"读下来吗？有没有跳跃、前后矛盾（前面说住 A 区后面交通按 B 区算）？
- **薄模块**：有没有 H2 下面只有一句话或一张薄表？展开或合并。
- **取舍理由**：为什么住这个区、为什么删某个景点、为什么这么排，有没有说清？还是只列结论？
- **每天主线和辅助兜底**：每天有今日主线、时段安排、用餐落点和可删减项吗？雨天/堵车/疲劳/排队备选是否只在关键风险处轻量出现？
- **第一屏是否解决痛点**：用户最关心的问题（值不值得去/住哪/怎么走）第一屏答了吗，还是要翻到很后面？