一页路书·旅游攻略搭子

> 原名 travel-planner，因市场名重复，于 v1.5.0 改名为「一页路书」（slug travel-onepage-lushu）；v1.6.1 名称追加品类词「旅游攻略搭子」以提升市场搜索命中率。功能完全等价。

Overview

生成个性化旅游攻略：收集用户需求 → 联网搜索实时信息 → 按行程编排原则组织内容 → 产出 Word 文档（.docx，可分享、可打印、手机可看）。

两个入口：
- 有明确目的地 → 跳过 Step 0，从 Step 1 开始
- 没想好去哪 → 先走 Step 0 推荐模式，出候选地让用户选，选定后再进 Step 1

Workflow

Step 0: 推荐模式（用户没有明确目的地时）

触发条件（满足任一即进入本步骤，不要反问"你想去哪"）：

• 用户没说目的地，只给了出发地/天数（如"郑州出发周末两天去哪玩"）
• 明确表达没想好："不知道去哪""有啥推荐""随便去个地方""你帮我选"

输入：出发地（必问，没有就问一次）+ 天数 + 出行日期；人群/预算/交通方式/偏好直接取偏好档案或默认值，不额外追问。

候选筛选（硬约束，逐条过滤，不满足直接淘汰）：

输出格式（3 个候选的对比表 + 明确站队）：

表格后必须给一句明确倾向："我更推荐 X，因为…"——不给并列的模糊答案，用户要的是有人替他做决定。

衔接：用户选定一个 → 目的地确定，进入 Step 1，不再追问目的地。用户三个都不满意 → 问清是哪条不满足（太远/太贵/不感兴趣），重跑一轮。

搜索：按 references/search-strategy.md 第 0 轮执行。车程与当季适宜性必须联网核实，禁止凭训练记忆估算车程。

兜底：搜索结果撑不起 3 个候选时，只给有把握的 1-2 个，并说明为什么其他的没推（如"更远的 XX 要 4h 车程，两天会全在路上"），不凑数。

Step 1: 收集需求

确认以下要素（用户消息中缺失的主动追问，一次问完，不要逐条挤牙膏）：

输入容错：用户消息中的错别字/简称/方言词（如"装造"=妆造、"环球影城"=北京环球度假区），按上下文推断后在回复中明确说出你的理解（"我按汉服妆造安排"），推断无把握时追问一句，不要静默猜。

偏好档案：收集需求前先读 ~/.workbuddy/travel-profile.md（注意：档案在 skill 目录外，禁止存进本 skill 目录——打包会泄漏用户隐私）：

• 档案存在 → 解析后作为个性化基线，Step 3 编排时按 references/profile-schema.md 的映射应用（节奏/作息/吃/体力/住宿/雷区六维度）
• 档案不存在 → 在本轮需求收集中顺带收集偏好（压缩成 2-3 句自然问话，别搞长问卷），首次生成后把档案写入 ~/.workbuddy/travel-profile.md
• 合并优先级：单次对话明确说的 > 偏好档案 > skill 默认值；用户说"以后都XX"这类长期表达时更新档案，一次性表达只影响当次
• 用户不想答 → 跳过该维度按默认走，不追问第二遍

Step 2: 联网搜索实时信息

按 references/search-strategy.md 中的搜索模板执行多轮搜索（走 Step 0 推荐模式的先执行第 0 轮）。核心原则：

• 门票价格、开放时间、是否需要预约——必须搜索，不可凭记忆写；顺带核实退改政策（能否退、多久前退、有效期/可否多次入园），写入景点 facts 和必办清单
• 近期闭馆维修、政策变化、季节性活动——搜索确认
• 交通：自驾查停车场/限行/路况；公共交通查机场车站到市区方式
• 自驾行程必须查路线与费用：每段高速的走法（高速名称+编号）、里程、耗时、过路费（搜"XX到XX 高速费/过路费"，多来源取区间，小客车口径）；费用必须联网核实，禁止凭记忆估算
• 搜索结果互相矛盾时，以官方渠道（景区公众号/官网）为准，并在攻略中标注"以官方为准"
• 票价信源分级（v1.8.0 新增，防游记污染）：可信信源 = OTA 售票列表页（携程/同程的票务信息区、价格+适用人群结构化展示）+ 官方渠道（官网/景区公众号/政务新闻中的"门票价格X元"表述）；游记/种草笔记（trip moments、小红书转述、"XX最新官方票务干货"标题的 UGC）一律不算信源——"线上提前购XX元"这类促销价常来自过时笔记且互相转载。多平台核实必须是不同类型信源（如 OTA × 百科/政务），不是多篇游记互证。促销价最多以"OTA 线上预订约 ¥X"括注形式出现，主价格写门市价

Step 3: 行程编排原则

• 必玩优先：用户点名的必玩点位是硬约束，先排入行程（地理聚类决定放哪天），再补推荐点位；必玩点位间距离过远/时间不够时，主动给出取舍方案（如"A+B 玩得从容，A+B+C 会赶"，让用户选）
• 地理聚类：同一天的点位必须在地理上相近，避免跨城/跨区往返
• 每日节奏：每天 2-4 个主要点位，上午/下午/晚上三段式，午餐安排在动线上顺路的餐厅——按偏好档案调整：特种兵 4-5 个/慢节奏 1-2 个；作息决定每日首个出发时间（早起型 06:30-07:30，自然醒 09:00 后）；体力弱则点位间安排观光车/缆车并插入歇脚点
• 动线方向：按"由远及近"或"由近及远"单向推进，不走回头路
• 时间预算：每个点位标注建议游玩时长；点位间标注交通方式和预计耗时（自驾含停车，公交含步行）
• 缓冲：首日只排半天（到达安顿），末日只排上午（返程预留）；每天留 1 小时弹性
• 张弛结合：高强度日（爬山/暴走）后接休闲日；亲子行程每日不超过 2 个点位
• 美食住宿：每晚住宿推荐 1-2 个区域（说明理由：近动线/美食多/性价比）；每餐 1-2 个具体店名 + 招牌菜 + 人均，来自搜索结果而非编造——按偏好档案筛选：忌口/辣度过滤餐厅，排队超时上限内才推荐网红店，住宿按"位置/品质/性价比"权重排序；雷区清单直接剔除（宁可少排，不可推荐用户明确排除的内容）
• 拍照机位：在对应点位下以小标签形式给出，标注最佳时段（如"日落前1小时"）
• 自驾费用表：自驾行程必须包含"自驾路线与高速费用"区块——逐段列出走法（市区道路→高速名称+编号→下高速口）、里程/耗时、过路费，末尾给全程合计（总里程、总高速费、油费估算）；附加油点与限速/错峰提示。封面 meta 中同步标注总里程与高速费。公共交通行程删除该区块。返程路线优先选不回头、不穿市区的方案

Step 4: 生成 Word 攻略文档（.docx）

1. 先写文档结构 HTML 中间稿：在输出目录（如 output/travel-onepage-<目的地>/）生成 guide-doc.html——注意这是转换中间产物，不是网页，禁止使用网页式布局（flex/渐变封面/时间轴伪元素/卡片阴影），必须用 Word 友好结构：<h1> 主标题 → <h2> 区块标题（一、天气与穿衣 / 二、行程安排 / 三、自驾路线与高速费用 / 四、美食清单 / 五、住宿建议 / 六、人均预算明细 / 七、出发前必办清单 / 八、实用贴士；公共交通行程删除自驾区块）→ 每日行程用表格（时间 | 安排 | 要点 三列，要点列放费用/时长/预约提示）→ 预算/费用/美食用表格 → 清单用 <ul> → 重点提示用 <div data-component="callout">
2. 填充规则：
   - 所有占位符必须替换，不留模板痕迹
   - 门票/开放时间标注数据来源和查询日期（如"2026-08 查询，以官方为准"）
   - 有偏好档案时，在文档开头信息区注明定制依据（如"节奏：均衡 · 早起出发"）
3. 转换为 docx：用 html-to-docx skill 的 CLI。优先跑托管脚本准备环境：
   bash <tencent-docx plugin>/scripts/wb/local/setup-html-to-docx.sh
   该脚本在 Windows 上可能因 safe-delete 拦截反复重建失败——此时手动执行下面三步（路径全部用当前用户目录展开，禁止照抄任何具体用户名）：
   ```
   # ① 探测 uv（通常在 ~/.local/bin/uv，也可能已在 PATH）
   which uv 2>/dev/null || where uv 2>/dev/null || ls ~/.local/bin/uv*

# ② 建 venv 并装依赖（Windows 上 uv 必须传 Windows 风格 C:/... 路径，
# Git Bash 的 /c/... 会被错误映射成 <当前盘>:\c...）
uv venv --python 3.12 ~/.venv-html-to-docx
uv pip install --python <venv>/Scripts/python.exe \
-r <tencent-docx>/skills/html-to-docx/scripts/requirements.txt

# ③ 转换
cd <tencent-docx>/skills/html-to-docx/scripts
<venv>/Scripts/python.exe -m html_to_docx convert guide-doc.html -o <目的地>N日游攻略.docx
`` venv 内 python 路径：Windows 为~/.venv-html-to-docx/Scripts/python.exe，macOS/Linux 为~/.venv-html-to-docx/bin/python。 兜底：环境准备失败时不阻断——交付guide-doc.html并说明"本机缺少 docx 转换环境，可浏览器打开该中间稿后另存为 docx"。 4. 转换后验证：用 python-docx 读取生成文件，确认表格数、关键价格数字无残留错误 5. 用户主动要 Markdown 时才另出对应版本（基于assets/itinerary-template.md`）

Step 5: 交付

用 present_files 展示生成的 .docx 文件。回复中简要说明：行程骨架（D1-D N 各自主题）、亮点设计、以及哪些信息建议出发前二次确认。

Step 6: 行程微调（用户对已交付攻略提出修改时）

用户反馈"太赶了""换个住宿""D2 不想去 XX 了"等，按以下原则调整，不推倒重来：

• 节奏类（太赶/太松）：保住地理聚类骨架，点位做减法优先于挪动——删当日最不必要或评分最低的点位，把省下的时间摊给剩余点位和用餐；反向"太松"则从点位池补 1 个同区域点位或加休闲时段（咖啡馆/ SPA）
• 换点位类：新点位先核实时效信息（门票/预约/开放时间）再排入；若与当日聚类冲突，挪到地理上最近的一天，而不是硬塞
• 换住宿类：住宿位置变了，重排的是"首日到达动线"和"末日出发动线"，中间日行程通常不动；同步更新自驾费用表和预算明细
• 加减天数类：加天数从"取舍方案里被砍的点位"和搜索时发现但没排入的季节性活动里补；减天数按"必玩优先"倒序砍推荐点位，必玩点位不能砍，时间不够就提示换更近的目的地
• 每次微调后，受影响的区块（行程/费用表/预算/必办清单）都要同步更新，不能只改一处留下前后矛盾；交付时说明改了什么
• 微调中用户的长期性表达（"以后都晚点出发""我其实不吃辣"）→ 同步更新 ~/.workbuddy/travel-profile.md 对应维度并告知"已记入偏好档案"；一次性表达只改本次攻略

Resources

references/

• search-strategy.md - 联网搜索的查询模板、信息校验规则、避坑信息收集清单
• profile-schema.md - 用户偏好档案规范：六维度定义、收集话术、存储位置（skill 目录外）、合并优先级、编排映射

assets/

• itinerary-template.md - Markdown 文档版模板，用户主动要 Markdown 时使用
• icon.png - 市场列表展示图标
• example/preview.png - 产出内容效果示例

根目录

• CHANGELOG.md - 版本更新记录，每次修改 skill 时追加

版本管理与更新提醒

生成产出时：

• 每次生成的攻略文档末行标注当前 skill 版本与查询年月：一页路书·旅游攻略搭子 v{{版本}} · 信息查询于 {{年月}}——版本号以 manifest.yaml 的 version 为准，方便追溯是哪个版本生成的

修改 skill 时：

• 任何对 SKILL.md / 模板 / 搜索策略的实质修改，必须：① manifest.yaml 的 version 递增（小改动 +0.0.1，新增功能 +0.1.0，结构调整 +1.0.0）；② CHANGELOG.md 顶部追加该版本记录（版本号 + 日期 + 改动点）
• 改完同步重新打包 zip（skillhub 发布版用户依赖 zip 更新）

提醒用户更新（满足任一即提醒，一次对话最多提醒一次，不反复刷屏）：

• 用户提到"装的是之前下的 zip / 别人发的版本"，且当前会话发现其行为与 CHANGELOG 最新版不符时，提醒："你手上的可能是旧版，最新版本 v{{版本}}，改动见 CHANGELOG，可到 skillhub 重新下载"
• 用户反馈的 bug / 缺失功能（如"怎么没有预算表"）恰好是新版已修复/新增的，说明是版本过旧导致，指引用户更新而非当 bug 处理