Travel Planner

Travel Planner

生成结构化、可操作、对客户可交付的旅行方案。输出可为中文 HTML/PDF 路书，并保留可编辑的 tripData.json。Cursor / Agent：路书 v2 硬性交付禁令与一键命令见 AGENTS.md；完整策划、数据源与配图约定见 skill.md（本文）。

商用模式定位

本 skill 默认按「可销售交付」标准执行：

• 输入多形态统一解析：文本 / 截图 / 文档（含图）
• 输出双层资产：tripData.json（可复用） + HTML/PDF（可直接交付客户）
• 数据标注诚实：实时报价 / 参考价 / 待确认，避免误导成交
• roadbook-v2：产出客户版路书 HTML 时 默认跑完整交付流水线（scripts/deliver_roadbook_v2.py 默认 strict：每日小红书正文 enrich_daily_descriptions_from_xhs → fill_xhs_images --require-remote-urls + validate --require-remote-urls，含 search_feeds 预检；或 npm run roadbook:deliver，建议 --hotel-force），禁止询问用户是否交付、是否补图、是否校验；交付禁令速查见 AGENTS.md，脚本与配图细则见本文路书 / 小红书相关章节。用户 明示「草稿 / 内部预览 / 离线」时可 deliver --allow-local-placeholders（跳过每日正文 enrich 与 strict 配图）或仅 generate.py，并在回复中标明 非交付稿。

行程详解文档 · Agent 角色提示词（Markdown）

> 何时使用：用户需要「行程亮点 + 按日玩法详解」的独立 Markdown；或作为撰写 / 校对 roadbook highlights、daily 正文前的结构化底稿。落入 tripData.json / 报价单 时，须与成团范围与费用口径一致；不得编造未包含项目或精确票价、班次。

角色定位

你是资深定制旅行顾问兼行程编辑：具备国内外目的地实务经验，擅长把零散计划整理成逻辑清晰、可执行、有体验感的旅行详解。你能提炼行程核心价值，并用松弛、好读、有度假感的中文写出吸引人但不夸大的每日导读（慢节奏、留白、烟火气与山野感等须贴合当日真实节点；避免小红书腔、标题党与胡编景点）。交付流水线 LLM 润色全文见 scripts/enrich_daily_descriptions_from_xhs.py 内 `DAILY_DESCRIPTION_LLM_*` 提示词。

核心任务

接收用户提供的行程计划（及可选参考资料），完成专业梳理与有限度补强，输出结构固定、篇幅受控的 Markdown 文档。

输入说明

| 类型 | 说明 | |------|------| | 主输入 | 行程骨架：天数、目的地或节点、交通方式、大致节奏等 | | 辅输入 | 景点介绍、酒店、美食、交通攻略等（用户或检索摘要） | | 资料不足 | 可基于公开知识与合理动线补充骨架；推断处用「若…可…」「常见做法是…」等措辞区分于客户已确认事项。票价、开放时间、闭馆规则以用户资料或检索为准；不确定须标注 待确认 |

输出要求（Markdown 正文）

# 行程亮点

• 维度：至少覆盖 游玩体验、住宿特色、美食亮点；可按行程特点增设 交通便利、文化体验、性价比与行程留白 等中的 1–2 项（不必条条俱全）。
• 提炼：整段行程的高度概括，突出最具辨识度、最打动人的部分，不要求每天都有。
• 形式：3–5 条无序列表；每条 1–2 句话；本节合计 约 200–300 字（中文）。
• 禁忌：不写空洞口号；不写与报价矛盾的「全含」「赠送」等表述。

# 每日行程详述

• 二级标题：## Day n：主题简述（示例：## Day 1：抵达 XX，老城慢行）。
• 内容：紧扣当日节点，从 核心看点、值得体验、动线建议、停留时长量级、实用贴士 中择 3–5 个重点撰写；语气偏 松弛度假、好玩吸引人、节奏舒服不赶路（画面感词与「适合慢慢逛/留出自由时间」等仅在与行程一致时使用）；不得新增素材外的景点或承诺。
• 篇幅：每日不超过约 300 字（中文）。
• 形式：以无序列表为主；关键信息 加粗（如 预约、省力走法、闭馆日）。

质量标准

| 维度 | 要求 | |------|------| | 准确性 | 与用户输入及可靠参考资料一致；勿捏造精确时刻表、票价、房态 | | 实用性 | 建议具体可执行，能指导客人安排当日节奏 | | 逻辑性 | 动线与时段衔接合理，避免明显赶路冲突 | | 丰富性 | 在可靠前提下适度补充增量信息，提升体验感 | | 可读性 | 分层清晰、句式利落，便于客户扫读 |

格式与排版（强制）

• 全文使用 Markdown。
• 必须包含且仅使用下列一级标题文案：# 行程亮点、# 每日行程详述。
• 每日使用二级标题 ## Day n：……。
• 正文以 无序列表 为主；重要短语使用 加粗。

特别说明

• 用户计划过于简略时：按合理旅行逻辑补全，并明确哪些是推断建议而非客户承诺。
• 参考资料优先：用户提供的材料及有针对性的检索结论优先于泛泛常识。
• 商用对齐：用车、门票、餐食是否包含等，以合同 / 报价为准；勿擅自改写口径。

统一输入 Intake 规范（商用强制）

当用户提供行程资料时，先按以下优先级提取为文本，再进入后续流程：

1. 纯文本（聊天内容 / txt / md）：直接解析
2. 截图 / 图片：先 OCR 提取关键字段，再人工补齐不确定信息
3. 文档（docx/pdf，可能含图）：先抽取文本主干，再提取图片主题作为搜图关键词

最低必需字段（缺失则追问）：

• 日程骨架：D1...Dn
• 每日路线或核心节点
• 费用说明（至少要有包含项和成人价；儿童价可选）

推荐使用自动化脚本落地简版输入：

python scripts/roadbook_intake.py --input  --output-dir 

工具可用性说明

本 skill 涉及的外部数据工具均为 CLI 命令，需通过 Bash 工具调用，而非 MCP 工具或 Skill：

| 工具 | 类型 | 调用方式 | 用途 | |------|------|---------|------| | flyai | npm CLI | Bash: flyai search-flight ... | 机票、酒店、景点门票实时数据（飞猪） | | TikHub API | REST（.env 中 TIKHUB_API_KEY） | python3 scripts/tikhub_xhs_search.py -k "关键词" | 小红书笔记搜索、配图、正文 | | mcp__grok-search__web_search | MCP 工具 | 直接调用 | 通用网络搜索（降级方案） |

Agent 委派规则：当使用 Agent 工具并行搜索时，subagent prompt 中必须明确指示通过 Bash 调用 flyai CLI 与 scripts/tikhub_xhs_search.py，而非仅依赖 mcp__grok-search__web_search。示例 prompt 片段：

Use Bash to run these CLI commands for real-time data:
- flyai search-flight --origin "成都" --destination "昆明" --dep-date 2026-04-02
- flyai search-hotels --dest-name "弥勒" --check-in-date 2026-04-03 --check-out-date 2026-04-05
- python3 scripts/tikhub_xhs_search.py -k "弥勒 带娃 亲子游" --limit 5 --pretty
Fall back to mcp__grok-search__web_search only when CLI tools fail or return no results.

第一步：收集旅行要素

在开始研究之前，先确认以下信息（已知的跳过，缺失的向用户询问）：

| 要素 | 说明 | 必需 | |------|------|------| | 出发地 | 从哪里出发（决定交通方案和可达性筛选） | 是 | | 出行日期 | 具体日期或月份 | 是 | | 天数 | 行程总天数 | 是 | | 人员构成 | 谁去、有无老人小孩（含年龄） | 是 | | 目的地 | 城市/地区，可以为空（进入推荐流程） | 否 | | 预算范围 | 总预算或每日预算 | 否 | | 偏好 | 饮食禁忌、兴趣方向、小众/热门、体力水平 | 否 |

第二步：目的地推荐（如目的地未知）

当用户不确定去哪里时，先做目的地筛选，再做行程规划。

关键依赖：目的地推荐分为多个阶段，Phase A 的结果是后续阶段的输入，严禁跳过：

• Phase A（可并行）：候选发现 + 季节检查 + 人群适配 → 输出候选短名单
• Phase B（依赖 Phase A）：仅对短名单中的候选地搜索交通 → 输出可行性排名
• Phase B2（依赖 Phase A，与 Phase B 可并行）：获取候选地出行日期的天气预报 → 降雨天数统计
• Phase C（依赖 Phase B + B2）：综合对比（含天气） → 呈现给用户决策

Phase A：候选目的地发现与初筛

Phase A 内部的三个子步骤可通过 Agent 按区域并行执行（如同时搜索"广西候选"和"云南候选"），每个 Agent 负责一个区域的完整初筛（发现 + 季节 + 人群适配）。

A1. 候选目的地发现

当用户给出的是区域范围（如"广西"、"云南"、"东南亚"）而非具体城市时，必须先通过搜索获取候选目的地列表，严禁仅凭一般知识预设。

搜索策略（每个区域 Agent 内部执行以下搜索）：

1. FlyAI 极速搜索 — 从真实旅行产品反推目的地：

flyai fliggy-fast-search --query "[区域] [天数]天 自由行"
flyai fliggy-fast-search --query "[区域] [月份] [特殊人群]游 攻略"
flyai fliggy-fast-search --query "[出发地]出发 [区域] [天数]日游"

返回的产品列表天然反映了哪些目的地有成熟旅游基础设施和可预订产品。从产品标题中提取目的地城市/地区。

1. 小红书获取真实用户验证的目的地（优先 TikHub）：

python3 scripts/tikhub_xhs_search.py -k "[区域] [月份] 旅游 推荐" --limit 8 --fetch-detail
python3 scripts/tikhub_xhs_search.py -k "[出发地]出发 [区域] [特殊人群]游" --limit 8

如 TikHub 不可用，降级用 mcp__grok-search__web_search 搜索 site:xiaohongshu.com [区域] [月份] 旅游 推荐。

1. mcp__grok-search__web_search 获取攻略型推荐：

搜索示例：
- "[区域] [月份] 旅游推荐 目的地 [年份]"
- "[区域] [特殊人群] 旅游 去哪里好"
- "[出发地]出发 [区域] [天数]天 推荐"

A2. 季节性陷阱检查（与 A1 同一 Agent 内执行）

每个候选目的地必须检查：核心吸引物在出行时段是否处于最佳状态。

常见陷阱：

• 瀑布/水景 → 检查是否枯水期（如德天瀑布4月枯水，7-11月最佳）
• 花海/红叶 → 检查花期/叶期是否匹配
• 海滩 → 检查是否台风季/禁渔期
• 雪景/滑雪 → 检查是否已化雪

A3. 特殊人群适配评估（与 A1 同一 Agent 内执行）

如有婴幼儿（0-3岁），必须评估：

• 推车友好度：景区路面是否平整可推车，是否有台阶/石板路/湿滑路段
• 母婴设施：当地超市是否有奶粉/尿不湿，酒店是否提供婴儿床
• 医疗距离：距最近有儿科的医院多远
• 安全风险：是否有深水区/陡崖/湿滑台阶等
• 节奏适配：是否适合慢节奏、是否有午休条件

如有老人，额外评估：海拔高反风险、无障碍设施、医疗可及性。

Phase A 输出：每个区域 Agent 返回候选城市/地区列表（通常 3-5 个），附带季节评估和人群适配结论。汇总后形成候选短名单（跨区域去重，淘汰季节陷阱严重的）。

---

Phase B：交通可行性筛选（依赖 Phase A 结果）

仅对 Phase A 输出的候选短名单搜索交通，不预设目的地。

交通耗时决定目的地是否可行。从出发地到候选目的地的单程时间直接决定有效游玩天数。

判断标准：

• 单程 ≤ 4h → 理想，不浪费游玩时间
• 单程 4-6h → 可接受，需占用半天
• 单程 6-8h → 勉强，带婴幼儿/老人需谨慎
• 单程 > 8h → 除非行程 ≥ 7天，否则不推荐

搜索方法：查12306高铁时刻、航班直飞情况、自驾距离。用 Agent 并行搜索短名单中多个候选地的交通。

---

Phase B2：出行日期天气预报（依赖 Phase A 结果，与 Phase B 可并行）

当出行日期在15天预报范围内时，必须在 Phase C 对比决策之前获取所有候选目的地的逐日天气预报。 降雨情况直接影响户外游玩体验，尤其对带婴幼儿/老人的行程影响极大，是目的地选择的关键决策因素。

触发条件：出发日期距今 ≤ 15天 → 强制执行；> 15天 → 跳过，在第三步再查。

执行方法：对 Phase A 短名单中的所有候选目的地，并行搜索各地出行日期段的天气预报。

数据源优先级：

1. 中国天气网 (weather.com.cn) 15天预报 — mcp__grok-search__web_search 搜索 [目的地] 15天天气预报 site:weather.com.cn
2. 和风天气 (qweather.com) — 搜索获取页面URL后 mcp__grok-search__web_fetch 抓取
3. AccuWeather — 英文备选

必须提取的信息（出行日期内每日）：

• 天气状况（晴/多云/阴/雨）
• 最高/最低气温
• 是否有降雨

输出格式：各候选目的地的逐日天气对比表 + 降雨天数统计。

淘汰规则：

• 出行日期内 ≥ 50% 天数降雨 → 标记为"天气风险高"，在 Phase C 中降权
• 带婴幼儿/老人时，连续降雨 ≥ 3天 → 建议优先排除

---

Phase C：多目的地对比决策

将候选目的地按以下维度做横向对比表格呈现给用户：

| 维度 | 权重 | |------|------| | 交通可达性 | 最高 | | 出行日期天气（降雨） | 最高 | | 特殊人群适配 | 高 | | 季节时令匹配 | 高 | | 小众/人流量 | 中 | | 景点丰富度 | 中 | | 费用水平 | 低 |

天气对比必须包含：各目的地出行日期内的降雨天数、逐日天气摘要、气温范围。如 Phase B2 已获取预报数据，直接引用；否则标注"超出预报范围，仅参考气候均值"。

给出明确的排名和推荐理由，让用户做最终决策。

第三步：多维信息采集

目的地确定后进入深度采集。使用 Agent 并行搜索提高效率。

维度 1：精确天气预报（前置，影响穿衣和行程安排）

如 Phase B2 已获取天气预报，直接复用数据，补充穿衣建议即可，无需重复搜索。

若 Phase B2 未执行（目的地已确定或出行日期当时超出15天范围），则必须从权威天气数据源获取逐日预报，不能仅靠搜索引擎的笼统描述。

数据源优先级：

1. 中国天气网 (weather.com.cn) 15天预报 — 通过 mcp__grok-search__web_search 搜索 [目的地] 15天天气预报 site:weather.com.cn
2. 和风天气 (qweather.com) 30天预报 — 搜索获取页面URL后 mcp__grok-search__web_fetch 抓取
3. wttr.in API — 直接 curl "https://wttr.in/[城市]?format=j1" 获取3天JSON预报（适合近期出行）
4. AccuWeather — 英文备选

必须输出的天气信息（逐日）：

• 日期、天气状况（晴/多云/阴/雨）
• 最高/最低气温
• 降水概率或是否下雨
• 穿衣建议

维度 2：交通方案 + 衔接验证（关键！）

搜索大交通方案后，必须验证关键衔接点的可行性。

机票搜索优先使用 FlyAI（飞猪实时数据，含价格+航班号+可预订链接）：

flyai search-flight --origin "[出发地]" --destination "[目的地]" --dep-date YYYY-MM-DD --sort-type 3
# 往返加 --back-date，直飞加 --journey-type 1，限价加 --max-price

FlyAI 返回的 adultPrice、航班号、时刻为实时数据，可直接用于行程编排和预算。

高铁/市内交通仍用 mcp__grok-search__web_search：

搜索示例：
- "[出发地]到[目的地] 高铁 时刻表 [年份]"
- "[目的地] 市内交通 地铁/公交/打车/包车"

衔接验证清单（涉及转机/转高铁的行程必做）：

对每个"A交通→B交通"的转换节点，必须搜索并确认：

1. A的到达时间 和 B的末班时间 — 确保来得及
2. A→B的转场方式和耗时 — 如"机场→火车站"需确认距离、打车/地铁/大巴耗时
3. 缓冲时间是否充足 — 飞机落地后取行李+转场，至少预留1.5小时缓冲

衔接验证搜索示例：
- "[机场]到[火车站] 怎么去 多久 打车 地铁"
- "[火车站]到[目的地] 末班车 最晚几点"
- "[机场] 空港快线 [火车站] 时刻表 末班"

如果衔接不可行（如末班车赶不上），必须调整方案：

• 方案A：改更早的航班
• 方案B：到达城市住一晚，次日再转
• 方案C：机场直接包车/租车到目的地（跳过火车）

在行程中明确标注衔接风险，如"末班高铁约21:00，建议选17:00前落地的航班"。

维度 3：景点与活动（含门票价格）

景点门票优先使用 FlyAI（含门票价格、收费状态、可预订链接）：

flyai search-poi --city-name "[目的地]" --category "历史古迹"
# 可选：--keyword "景点名"、--poi-level 5（5A景区）

FlyAI 返回 ticketInfo.price 和 freePoiStatus（免费/收费），可直接用于预算。

攻略和小众推荐仍用 mcp__grok-search__web_search 补充：

搜索示例：
- "[目的地] 必去景点 推荐 攻略 [年份]"
- "[目的地] 亲子/家庭 玩法 推荐"（如有老人小孩）
- "[目的地] 小众景点 本地人推荐"

景点/美食/玩法图片采集优先级（强制）

所有景点、美食、玩法等非酒店图片（含 activities[].imageUrl、activities[].imageUrls、meal.imageUrl）必须按下列顺序采集，前序可用即停：

| 优先级 | 来源 | 调用方式 | 说明 | |---|---|---|---| | 1️⃣ 首选 | 小红书（TikHub） | search_notes → get_note_info 累计取图；交付默认每槽 4 张备选 URL（可用 --min-images/--max-images 或 ROADBOOK_V2_IMAGE_ALTERNATES* 配置） | 真实用户实拍，最贴近现场；具体流程详见下文"维度 6" | | 2️⃣ 其次 | 通用图库 | generate.py --auto-images --image-registry ... 内置图库检索，或平台可用的通用图库 API | 仅在小红书无结果或不可用时使用 | | 3️⃣ 再降级 | 兜底图源 | generate.py 内置 fallback | 保证版式不空，但相关性低于前两级 | | 4️⃣ 最后 | 人工素材 | image_registry.sources.manual | 仅当前三层失败时启用 |

严禁把人工非酒店素材提前到兜底之前，除非用户明确要求。

维度 4：美食与餐饮

搜索示例：
- "[目的地] 必吃美食 餐厅推荐 人均"
- "[目的地] 当地人推荐 小吃 美食攻略"

维度 5：住宿方案（数据源强约束）

酒店文字与结构化信息（酒店列表、介绍、房型、设施、评分；报价类字段单独见下）须严格按顺序获取，前序有可用结果即优先采用，仅在前序无法满足时再进入下一步：

1. 携程（第一顺位：核对酒店全称、介绍、房型与设施）
2. 飞猪（第二顺位：flyai search-hotels 及返回字段，用于报价、链接近实时对齐）
3. 通用搜索（第三顺位：mcp__grok-search__web_search 等；仅作补充，须在文案或数据旁标注「参考/待核验」，不得绕过前两步直接当主来源）

小红书、未标注来源的泛网页不得作为酒店主信息来源（实拍图可作为图片补充，见下文图片来源表）。

第一顺位：携程（优先官方页或明确 site:ctrip.com 结果）：

mcp__grok-search__web_search query="site:ctrip.com [酒店全称] 房型 设施"
mcp__grok-search__web_search query="site:ctrip.com [目的地] 酒店 [入住日期]"

第二顺位：飞猪（FlyAI）（指定入住离店日的列表与报价，用于与携程信息交叉核对）：

flyai search-hotels --dest-name "[目的地]" --check-in-date YYYY-MM-DD --check-out-date YYYY-MM-DD
# 可选：--poi-name "景点名"（按周边筛选）、--hotel-stars "4,5"、--max-price 800、--sort price_asc

FlyAI 返回 price（指定日期报价）、score、review、detailUrl（预订链接）等；使用时仍应先已有携程侧酒店身份与房型描述，再用飞猪对齐日期与价格。

第三顺位：通用搜索（携程、飞猪均无该酒店有效条目时再启用）：

mcp__grok-search__web_search query="[酒店全称] 官方 房型 含早"

酒店信息采集顺序（信息与报价汇总）：携程 → 飞猪 → 搜索 → 人工。若四步均无效，须明确标注「酒店数据缺失」，不得用小道消息凑数。

预算中住宿价格处理：在已按 携程 → 飞猪 核对前提下，FlyAI 传入具体日期的报价可标注为「实查」；仅凭第三步通用搜索或未传日期的检索结果，标注为「参考价」。

roadbook-v2：住宿「简介」交付标准化（与维度 5 顺序一致）：

• 原则：携程侧先核对酒店全称、房型与设施（人工或 site:ctrip.com）；飞猪侧用固定脚本拉取长简介并写入 feature / subtype: 住宿 / items[].description，保证每次字数下限与命令参数一致，避免口头约定漂移。
• 前置：每条住宿卡片的 description 须保留 备选酒店：…… 或 【拟定酒店】…… 清单（以便解析首选店名）；items[].title 为飞猪检索用地名（如 「西江」 对应脚本内 雷山 别名，无需手改）。
• 强制命令（交付时勿省略日期与 min-chars）：

``bash cd "[skills-travel-planner 仓库根]" python3 scripts/enrich_hotel_intro_from_flyai.py "[路书目录]/tripData.json" \ --check-in YYYY-MM-DD \ --check-out YYYY-MM-DD \ --min-chars 200 ``

• --check-in / --check-out：必须与该路书客户首晚入住/离店日一致（与报价核对用同一窗口）；勿依赖 meta.generationDate 隐式默认作为交付凭据。
• --min-chars：交付默认 200（与校验脚本思路一致：可再调高，但勿低于 200）。
• 依赖：本机已安装 flyai（npm i -g @fly-ai/flyai-cli）。脚本第二顺位对齐飞猪列表字段，不能替代携程核对；成稿可在浏览器编辑或手工合并携程表述。
• 已生成长简介且仍带清单的条目默认跳过；需按新日期重拉时加 --force。
• 与生成顺序：一键 deliver_roadbook_v2.py 会先跑 enrich_daily_descriptions_from_xhs，再执行本脚本，随后 小红书预检 + 按槽搜图 → validate → generate.py（禁令与命令模板见 AGENTS.md）。若分拆手工执行，建议在 fill_xhs_images 之前先写完住宿简介与每日正文。

维度 6：小红书/社区真实反馈（关键增量信息）

小红书上的真实用户帖子能提供搜索引擎找不到的细节（如推车是否真的好推、具体哪家店踩雷）。

通过 TikHub API 访问小红书（仓库根 .env 配置 TIKHUB_API_KEY，在 https://user.tikhub.io 申请）：

cd "[skill_assets_dir]/.."
# 写入 .env：export TIKHUB_API_KEY="你的密钥"
python3 scripts/tikhub_xhs_search.py -k "目的地 攻略" --limit 5 --fetch-detail --pretty

说明：

• 配图 / 每日正文 / deliver 流水线已统一走 TikHub（fill_xhs_images.py、enrich_daily_descriptions_from_xhs.py），不再使用 mcporter / 本地 xiaohongshu-mcp。
• 节流：环境变量 ROADBOOK_FILL_XHS_COOLDOWN_MS（每次 TikHub 请求后停顿）、ROADBOOK_FILL_XHS_SLOT_GAP_MS（每槽之间）、ROADBOOK_FILL_XHS_MAX_DETAIL_FEEDS；或 fill_xhs_images.py 的 --xhs-cooldown-ms / --xhs-slot-gap-ms / --xhs-max-detail-feeds。降重复：默认单笔记最多 5 张、每关键词轮询最多 2 张；可选 pHash 去重见 --visual-dedupe。
• 并发取图（默认开启）：--xhs-concurrency / ROADBOOK_FILL_XHS_CONCURRENCY（默认 4 线程）。tikhub_xhs_client 用模块级 keep-alive httpx.Client，xhs-note-cache 已加 threading.Lock。第一轮 worker 间用初始全书指纹快照做 slot_exclude；主线程按 idx 顺序合并并做前向去重；不足槽串行补一轮，使用最新累积指纹集。--visual-dedupe 与并发互斥（SQLite phash 缓存非多线程安全），打开时自动回退 concurrency=1。
• roadbook-v2 每槽备选图数量（交付默认 4 张 URL，一人一键、全员同参数；可调）：
• 首选：在仓库根 不经用户确认 执行 scripts/deliver_roadbook_v2.py（含 --check-in / --check-out，默认建议 --hotel-force），一次性完成 每日小红书正文、亮点/费用/服务 LLM 润色（enrich_roadbook_copy_from_llm）、住宿简介、小红书补图、校验 + generate.py（参数与顺序见 scripts/deliver_roadbook_v2.py 或 AGENTS.md）。禁止问用户要不要跑交付。
• 分拆执行时（仅在一键脚本不可用时）：

``bash python3 scripts/fill_xhs_images.py "[路书目录]/tripData.json" \ --min-images 4 --max-images 4 --require-remote-urls python3 scripts/validate_roadbook_image_alternates.py "[路书目录]/tripData.json" --require-remote-urls ` 第二行须退出码 0。默认每槽 **4** 张备选；团队可用环境变量 **ROADBOOKV2IMAGEALTERNATES**（或 MIN / MAX）或 deliver **--min-images / --max-images** 统一改口径。**交付路径禁止** fillxhsimages.py --skip-existing（仅本地提速可用）。草稿可去掉两行中的 --require-remote-urls 或改用 deliver --allow-local-placeholders。仅 relinklocalroadbookimages.py 不会补足多张远端备选。详情见 **AGENTS.md`**。

配图检索词（已内置）：fill_xhs_images.py 调用 scripts/xhs_search_keyword_rules.py——封面/大标题背景偏向 目的地 + 风景或建筑 + 大气，并带 分桶（航拍/实拍/夜景等）；daily 槽位以 当日 theme 为主干轮换后缀，并带 实拍/游客/航拍/栈道 等桶词；住宿配图偏向 酒店名 + 实拍/房型大堂/体验。交通（subtype: 交通 的用车图 + 章节背景）固定仅走飞猪 flyai keyword-search（网络 picUrl），不走小红书；见 image_fallback_chain.flyai_transport_* / refill_transport_images_from_flyai.py。

每日 description 与住宿：交付前 daily.data.description 建议 120–280 字；deliver 默认先跑 scripts/enrich_daily_descriptions_from_xhs.py --force（每次润色；自动识别 [话题]/emoji/机位清单等劣质拼接并重写；配置 OPENAI_API_KEY 或 DEEPSEEK_API_KEY（可写在仓库根 .env，由 scripts/repo_dotenv.py 在 deliver / enrich_daily 启动时加载）时经 OpenAI 兼容 Chat Completions 统一顾问文风，否则以 overview + 飞猪/维基洁净句 合成；DeepSeek 专用变量与示例见 docs/deepseek-llm-setup.md；亦可用 OPENAI_BASE_URL + OPENAI_MODEL 指向 DeepSeek；--daily-no-llm 禁用 LLM；--no-daily-force 保留已有长文案；--skip-daily-enrich 跳过）。住宿长简介用 enrich_hotel_intro_from_flyai.py --min-chars 200（含舒适度、房型位置核对）。每日 Markdown 底稿规范见本文 「行程详解文档 · Agent 角色提示词」 章节。

1. 搜索帖子 — TikHub CLI 或交付流水线自动执行：

python3 scripts/tikhub_xhs_search.py -k "[目的地] 亲子游 带娃" --limit 10 --fetch-detail -o sources/xhs-亲子.json --pretty
python3 scripts/tikhub_xhs_search.py -k "[具体景点名] 实拍 打卡" --limit 5 --fetch-detail

对每个行程中的主要景点（3-5个核心景点），建议单独搜索一次以获取针对性的实拍图片。

1. 获取详情 — --fetch-detail 或对单条 note_id 再调 get_note_info（流水线内自动完成）。

1. 提取关键信息：真实行程、避雷指南、酒店餐厅推荐、带娃tips

1. 提取笔记图片 — 从 JSON 的 image_urls 字段或 fill_xhs_images 写入 tripData：

• 优先选取点赞/收藏量最高的 3-5 篇笔记中的图片
• 每个图片槽累计保留约定数量的高质量备选 URL（默认 4，封面图优先，不足时继续补源）
• 图片 URL 通常在返回数据的 imageList 或 images 字段中
• 将图片与对应景点/活动匹配：根据笔记搜索关键词（如"XX景点"）对应到 tripData 中相应的 activity
• 直接写入 `act

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: huanyuzhilv
• Source: huanyuzhilv/skills-travel-planner
• License: MIT
• Homepage: https://huanyuzhilv.github.io/skills-travel-planner/

Install and usage instructions live in the source repository linked above.