---
name: tri-travel
slug: tri-travel
version: 1.1.0
displayName: 旅游攻略
description: 旅游攻略下游执行 skill。读取 tri-intent 快照 §三，处理 I13 规划拆解 · travel 子类意图。先分流两条路径——已指名具体景点走路径 S（grill 逐项拷问 → 二次确认 → 1 份全生命周期可执行方案，含行前/逐日/预算/应急/返程），目的地待定走路径 D（需求挖掘 → 3-5 差异化方案 → 小时级规划）；全程结合外网景区实时信息（开放/闭园/限流/门票/天气/人流/交通），参考头部创作者经验策略（references/creator-strategies.md）。当 tri-intent 快照下游路由建议指向本 skill 时激活。支持独立安装，含上游依赖检测三态逻辑（标准模式/引导安装/降级模式）。
summary: 双路径旅游规划——路径 S 针对已锁定景点：逐项拷问（人数构成/交通/时长/预算/出发返程/住宿/饮食）收敛真实需求，二次确认（区分已明确项与假设项）后直出 1 份全生命周期方案；路径 D 针对目的地待定：自适应追问上限3轮 → 3-5 差异化方案 → 小时级规划；两路径均结合外网景区实时信息并对结论附置信标注。
tags: [travel, itinerary, trip-planning, tourism, scene-data, planning]
license: MIT
---

# 旅游攻略（下游路由 · I13/travel）

> 本 skill 是 tri-intent 的下游执行 skill，依据快照 `snapshot.md` §三 结构化结论直接执行，不再重新识别意图。
> 用户心智：帮我把一次出行规划成"可落地"的攻略——目的地定了就把他要的逐项问清、给一份从头到尾能照着走的方案；目的地没定就给我几个方案挑。

## 强制执行契约（Execution Contract · 最高优先级）

0. **版本检查前置硬门（第零步）**：MUST 先通过 §版本检查与更新机制（运行 `scripts/check_update.py`，按 `references/version-check-spec.md` 四态判定处置；非最新版自动升级，升级通道不可用则降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入后续步骤。本条目优先级高于所有其他强制前置条目。

1. **教训文件读写闭环（进化契约核心机制 · 用户硬要求）**：版本检查第零步完成后、核心执行前，MUST 优先读取 `.tribro/travel/lessons.md`（历史执行沉淀经验教训；目录或文件不存在则静默跳过，NEVER 报错、NEVER 中断、NEVER 追问）；每次执行结束后 MUST 追加本次经验教训入该文件（可操作规避动作，空泛禁写），见 §进化契约。
2. **强制前置**：收到 tri-intent 快照且 `下游路由建议` 指向本 skill，MUST 先读取快照 §三，校验 `intent.L2_核心意图` = I13 且 `L3_子意图` = travel（或 travel 相关语义），NEVER 跳过校验直接规划。若 L2 越界 → 停止并回退 tri-intent 重新路由。独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。
3. **路径判定前置（两路径分派 · 最高优先于阶段执行）**：进入阶段执行前，MUST 先判定本次走**路径 S（具体目的地锁定）**还是**路径 D（目的地待定/多方案）**，判定结果与依据 MUST 在自检句中声明。判定后本路径契约全程生效，MUST NOT 中途换轨。

| 路径 | 触发条件 | 阶段序列 | 方案数量 |
|---|---|---|---|
| **S · 具体目的地锁定** | 用户请求已指名**具体景点**（如「去大理」「游黄山」）——目的地不再是变量 | ①grill 拷问 → ②二次确认 → ③全生命周期方案 | **1 份主方案**（差异大时补条件备选） |
| **D · 目的地待定/多方案** | 目的地未定、待推荐，或用户明确要多个方案对比 | ①需求挖掘 → ②方案生成 → ③小时级规划 | 3–5 个差异化方案 |

- 路径 S 判定要点：目的地**已明确**即命中，即使其余维度（人数/预算/日期等）全缺——缺什么拷问什么，不因维度缺失而退回路径 D。
- 路径 D 判定要点：目的地为「你推荐」「没想好」等变量，或用户要「几个方案对比」时命中。
- 两路径共享：第零步版本门、教训文件闭环、实时信息支撑（第 10 条）、置信标注（第 11 条）、自检（第 12 条）、进化契约。

4. **路径 S · grill 拷问（逐项收敛）**：用户请求指向具体景点时，MUST 按 `references/destination-grill.md` 的拷问清单**逐项**收敛信息，覆盖：目的地/途经地与中转地（可选）/出行人数及构成（成人·儿童·老人）/交通工具（自驾·公共交通·包车·租车）/游玩时长（总天数与每日节奏偏好）/游玩预算（总额与分配方式）/出发与返程时间/住宿偏好/饮食禁忌与兴趣偏好/其它补充要求。
   - **每次提问聚焦少量关键项**（建议 1 轮 2–4 项，按信息缺口优先级排序），NEVER 一次性抛出全部条目。
   - 用户已明确项 MUST 跳过不重复问；拷问轮次上限 ≤4 轮（路径 S 独立于路径 D 的 ≤3 轮约束），NEVER 无限追问。
   - 信息已充分时 MUST 跳过拷问直接整合二次确认。
5. **路径 S · 二次确认门**：拷问结束后，MUST 将信息整合为**结构化真实需求描述**（含缺失项的**默认假设说明**）交用户确认或修正；用户未确认 NEVER 进入方案生成。确认卡 MUST 显式区分「用户已明确项」与「假设项」两类。
6. **路径 S · 全生命周期方案**：确认后 MUST 输出一份覆盖**旅游全生命周期**的可落地执行方案，含：行前准备（证件/装备/预订/天气提示）→ 行程逐日安排（时间轴·景点·餐饮·住宿·交通衔接与耗时）→ 预算明细表 → 应急预案与备选方案 → 返程收尾事项。输出 MUST 分层级标题呈现，关键内容 MUST 以表格或清单呈现，便于审计、核对与打印；信息不全或需求模糊处 MUST 显式标注**假设**与**待确认项**。
   - **主方案 + 条件备选**：默认产出 1 份完整主方案；仅当预算档、时长或同行人构成存在显著差异且会影响可行性时，MUST 补 2–3 个**精简备选**（每备选只给差异点：变动项 + 影响 + 取舍），NEVER 以备选替代主方案。
7. **需求确认前置（路径 D · 用户硬要求）**：进入方案生成前，MUST 先输出《整理后的旅游诉求确认卡》供用户确认；用户未确认 NEVER 进入下一阶段。追问轮次按用户输入详尽度**自适应**：输入已充分覆盖必要维度时，MUST 跳过追问（或大幅减少轮次）直接整合确认卡；仅当关键维度缺失/模糊时才追问，上限 MUST ≤3 轮，NEVER 无限追问耗尽用户耐心。
8. **方案多元性（路径 D）**：MUST 产出 3–5 个差异化方案，维度组合至少覆盖预算/日期/地点/交通/人数/关系/旅游目标，NEVER 只给单一方案或同质化换皮方案。
9. **小时级粒度（两路径共同 · 用户硬要求）**：选定/确认方案后，MUST 以小时为粒度输出行程关键节点表 + 每个关键节点的备选应急规划，NEVER 只给"哪天去哪个景点"的粗粒度概述。
10. **实时信息支撑**：涉及景区开放/闭园/限流/预约/门票/天气/人流/交通可达性的结论，MUST 经外网搜索获取实时信息，NEVER 凭过时记忆编造"当前情况"。路径 S 的行前准备与逐日安排 MUST 至少覆盖「景区开放状态 + 天气 + 门票/预约」三类实时信息。
11. **结论置信标注（用户硬要求）**：本 skill 产出的每一个结论性表达/判断/建议（如"某景区当前开放"“某方案总预算约 X 元”）MUST 附三要素：① 置信度（高/中/低）；② 依据类型六选一（事实 known / 计算 computed / 推断 inferred / 常识 common / 框架 iframe / 猜测 guess）；③ 可访问可验证的事实源 URL（存在时必附；无外部来源附本地证据锚或标注「无外部来源」）。依据为 猜测 guess 的结论 MUST 标低置信度并提示需人工验证。
12. **自检**：作答前用一句话声明「本次意图=I13/travel，已读取快照=<是/否>，路径=<S 具体目的地锁定/D 目的地待定>，当前阶段=<grill拷问/二次确认/全生命周期方案 ‖ 需求挖掘/方案生成/小时级规划>，拷问轮次=<N/上限4|已充分跳过 ‖ N/上限3>，已读教训=<N 条/无文件>，版本检查=<已通过/离线降级/通道降级/升级降级>，路由=<快照/降级>」，若与上述规则冲突则停止并纠正。

## 触发时机

| 触发分支 | 典型信号 | 路径/阶段调整 |
|---|---|---|
| 快照路由 | tri-intent 快照 `下游路由建议` 指向本 skill 且 `L2` = I13、`L3` = travel | 按目的地是否锁定分流路径 S/D |
| 具体目的地触发 | 「帮我去大理玩」「黄山怎么安排」——已指名景点 | **路径 S**：grill 拷问 → 二次确认 → 全生命周期方案 |
| 目的地待定触发 | 「暑假想出去玩」「帮我推荐几个地方」 | **路径 D**：需求挖掘 → 3–5 方案 → 小时级 |
| 直接触发 | 「帮我做旅游攻略/规划一次出行/设计行程」 | 降级模式，自构造输入后再分流 |
| 补全触发 | 已选定/确认方案后追问「细化一下行程/排个时间表」 | 进入小时级规划 |

**不由本 skill 处理**（命中以下信号 MUST 指向对应 skill，NEVER 在本工作流内代办）：

| 信号 | 归属 |
|---|---|
| 「帮我选哪个方案更好」——单一收敛决策 | tri-ask（I04 决策辅助） |
| 「写一篇 XX 旅游攻略文章/种草文」——产出内容 | tri-content / tri-article（I06） |
| 「发散一下去哪玩/给我一堆目的地点子」——纯发散 | tri-bs（I16 头脑风暴） |
| 「查某地天气/门票多少钱」——纯信息查询 | tri-ask（I01 信息查询） |

## 上游依赖检测（独立使用时）

> 本 skill 可独立安装。激活时 MUST 检测外部 tri-intent skill 是否可用，据检测结果选择执行模式：

| 模式 | 触发条件 | 行为 |
|---|---|---|
| **A · 快照模式** | 按 tri-intent §快照定位契约 定位到**可用快照**（`.tribro/LATEST.md` 指针 → 会话内最新 → 全局最新且 ≤30 分钟）且 `下游路由建议` 指向本 skill | 读取快照 §三，按工作流推进（标准模式） |
| **A0 · 待识别** | 有 `tri-intent/` 但无可用快照（或快照已过期/损坏） | MUST 提示用户「本次请求尚未经意图识别」，引导先经 tri-intent 产出快照；NEVER 按空上下文静默执行 |
| **B · 引导安装** | 以上均不满足（无 tri-intent） | MUST 向用户提示依赖并引导安装 |
| **C · 降级模式** | 用户明确拒绝安装，或用户直接触发本 skill 且无可用快照 | 从用户请求自构造等价输入（意图判定 I13/L3=travel + 任务要点 + 交付预期 + 候选目的地），声明降级模式后按工作流推进 |

**模式 B 提示语**：
> 本 skill 依赖 tri-intent 进行意图识别与输入校验。当前未检测到 tri-intent。
> 请安装：`skillhub install tri-intent --dir <目标目录>`
> 安装后重新发起请求，即可获得完整的意图识别→澄清→执行工作流。

**模式 C 降级声明**：
> 当前为降级模式，意图识别精度低于完整工作流；本 skill 将直接从用户原始请求自构造输入，产出攻略仍需用户人工复核诉求覆盖度。

## 输入契约

读取 `.tribro/snapshots/<命名>.md` 的 §三 结构化结论区（快照模式），或自构造等价输入（降级模式）：

| 字段 | 用途 |
|---|---|
| `intent.L2_核心意图` | 必须为 I13，且 `L3_子意图` = travel（或 travel 相关语义），否则不应激活本 skill |
| `dimensions.D1_任务领域` | 决定规划的专业域（境内游/周边游/主题游等） |
| `dimensions.D2_输入形态` | 一句诉求 / 一段描述 / 多要素条目 |
| `任务要点` | 目的地意向/出发地/日期/时长/预算/人数等已知要素与硬约束 |
| `交付预期` | 用户期望的攻略产物（3-5 方案 / 小时级行程 / 含应急） |
| `下游 slug` | 本 skill 目录名 `tri-travel` |

> 若快照 `澄清门状态` = 待澄清，MUST 先经本 skill 阶段①需求挖掘完成澄清后再推进，NEVER 跳过澄清直接出方案。当输入已充分覆盖必要维度时，澄清可缩减为直接整合确认卡（不再逐项追问）。

> **模式 C 降级模式输入**：从用户原始请求自构造等价输入——意图判定（默认 I13/L3=travel）+ 任务要点（从请求提取目的地/日期/预算/人数等）+ 交付预期（3-5 方案 + 小时级行程）+ 候选目的地，声明降级模式后按工作流推进。

## 职责边界

- **本 skill 负责**：经「需求挖掘 → 方案生成 → 小时级规划」三阶段，结合外网景区实时信息，产出可落地的旅游方案与小时级行程。
- **不负责**：意图识别（由 tri-intent）、收敛决策「选哪个方案」（由 tri-ask 的 I04）、发散目的地点子（由 tri-bs 的 I16）、把攻略写成文章/种草文（由 tri-content / tri-article）、纯信息查询（由 tri-ask 的 I01）。
- **关键边界**：本 skill 只做「规划与安排」，不替用户做「价值观/偏好最终取舍」——方案是否采纳由用户拍板。
- **不触发场景（Not-Trigger）**：不接手「收敛决策 / 单方案选取」（转 tri-ask I04）；不接手「发散目的地清单」（转 tri-bs I16）；不接手「攻略成文成稿」（转 tri-content/tri-article）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）。

## 旅游攻略方法论（核心能力 · 可扩展）

> 方法论是本 skill 的差异化能力：**双路径流水线 + 实时信息支撑 + 结论置信标注**。目的地未定时，需求挖掘把「模糊愿望」变成「可确认诉求」，方案生成把「诉求」变成「可比较选项」；目的地已锁定时，grill 拷问把「一句话出行念头」收敛成「结构化真实需求」，直接产出「一份可执行的全生命周期方案」。两条路径最终都收敛到「小时级可执行时刻表」。

### 核心理念

> **先想清楚（需求）→ 再选得对/一次做对（方案）→ 排得细（小时级）。** 一切结论以实时信息为据、以置信标注为凭，不靠记忆编造当前情况。

### 一、双路径流水线（先分流，再执行）

| 路径 | 触发 | 阶段序列 | 方案数量 | 参考 |
|---|---|---|---|---|
| **S · 目的地锁定** | 已指名具体景点 | ①grill 拷问（≤4轮，每轮2–4项）→ ②二次确认 → ③全生命周期方案 | **1 主方案** + 条件备选 | `references/destination-grill.md` |
| **D · 目的地待定** | 目的地为变量/要多方案对比 | ①需求挖掘（≤3轮自适应）→ ②方案生成 → ③小时级规划 | **3–5 个**差异化方案 | `references/travel-requirements-clarify.md` + `itinerary-planning.md` |

**路径分流判据**：目的地是否明确——「去大理」= 路径 S（其余维度缺失不影响判定，缺什么拷问什么）；「你推荐个地方」= 路径 D。

### 二、实时信息支撑（场景数据）

涉及景区开放/闭园/限流/预约/门票/天气/人流/交通可达性的结论，MUST 经外网搜索获取实时信息。搜索指令集与信息源见 `references/scene-data-sources.md`（grep 模式：信息源/搜索指令/字段核对）。检索结论依 §强制执行契约第 11 条附置信标注与来源。

### 三、扩展点

| 扩展点 | 零改动扩展方式 |
|---|---|
| 新增需求维度 | 在 `references/travel-requirements-clarify.md` 维度表追加一行 |
| 新增拷问项 | 在 `references/destination-grill.md` 拷问清单追加一行（标 P0/P1/P2 + 缺省假设） |
| 新增全生命周期环节 | 在 `references/destination-grill.md` 方案骨架追加一节 |
| 新增方案组合策略 | 在 `references/itinerary-planning.md` 组合策略追加一条 |
| 新增信息源 | 在 `references/scene-data-sources.md` 信息源表追加一行 |
| 新增应急类型 | 在 `references/itinerary-planning.md` 应急模板追加一条 |
| 新增创作者经验规则 | 在 `references/creator-strategies.md` 规则表追加一条（含类型代号与置信标注） |

## 处理流程

> 执行顺序固定：§版本检查与更新机制（第零步）→ 教训文件读取 → 上游依赖检测 → 读取快照 §三 / 降级输入 → **路径判定（S/D）** → 按路径执行。版本检查未通过前 NEVER 进入以下任一执行步骤。

### 步骤 0 · 路径判定（分流闸门）

1. 判定目的地是否**已锁定**：用户请求已指名具体景点 → **路径 S**；目的地为变量或用户要多方案对比 → **路径 D**。
2. 路径 S 下，其余维度（人数/预算/日期等）缺失**不影响**路径判定——缺什么拷问什么，NEVER 因维度缺失退回路径 D。
3. 判定结果与依据 MUST 写入自检句；判定后本路径契约全程生效，MUST NOT 中途换轨（除非用户显式改变目的地诉求）。

---

## 路径 S · 具体目的地锁定（grill → 确认 → 全生命周期）

### S1 · grill 拷问（逐项收敛 · 上限4轮）

1. 读取输入，锁定目的地；按 `references/destination-grill.md` 拷问清单评估缺口，按 P0>P1>P2 排序。
2. 每轮 MUST 只聚焦 **2–4 个**最关键项；已明确项 MUST 跳过不重复问；NEVER 一次性抛出全部条目。
3. 轮次上限 MUST ≤4 轮；输入已充分时 MUST 跳过拷问直接整合 S2。
4. 用户回答后更新缺口表，进入下一轮或收敛。

### S2 · 二次确认（需求确认门）

1. 输出**结构化真实需求描述**（模板见 `references/destination-grill.md` §二），MUST 显式区分两类：
   - **用户已明确项**（逐项列出）
   - **假设项**（缺失项的默认值 + 影响 + 待确认标记）
2. 附**实时信息快照**（景区开放状态 / 未来 2–3 天天气 / 门票与预约要求），按第 11 条附置信标注与来源。
3. 声明自检句（含当前阶段=二次确认、拷问轮次），交用户确认或修正；**未确认 NEVER 进入 S3**。

### S3 · 全生命周期方案（1 份主方案 + 条件备选）

1. 输出 **1 份完整主方案**，MUST 分层级标题 + 表格/清单，覆盖全生命周期（骨架见 `references/destination-grill.md` §三）：
   - **行前准备**：证件 / 装备 / 预订（含截止时间与状态）/ 天气提示
   - **行程逐日安排**：时间轴（时间·节点·活动）、景点、餐饮、住宿、交通衔接与耗时、动线合理性（不走回头路）
   - **预算明细表**：分项 + 15–20% 应急金
   - **应急预案**：逐节点 Plan B + 高风险节点撤离路径
   - **返程收尾事项**：退房/行李/交通衔接/费用结算
2. **条件备选**：仅当预算档、时长或同行人构成差异显著影响可行性时，补 2–3 个精简备选（只给变动项 + 影响 + 取舍）；NEVER 以备选替代主方案。
3. **假设与待确认项汇总**：集中列出方案中新引入的假设与待确认项，标注影响与优先级。
4. 实时信息与结论 MUST 附置信标注（依第 10/11 条）；涉景区现状至少覆盖「开放状态 + 天气 + 门票/预约」三类。
5. 结尾声明自检句（当前阶段=全生命周期方案）。

---

## 路径 D · 目的地待定/多方案（三阶段 · 原契约）

### 阶段① 需求挖掘（自适应追问 · 上限3轮）

1. 读取输入，提取已知诉求要素（目的地/日期/时长/预算/人数/关系/出发地等）。
2. 对照 `references/travel-requirements-clarify.md` 的维度表，识别缺失/模糊的关键维度。若识别结果为「无缺失/模糊关键维度」（即用户已详细描述必要信息），MUST 跳过追问，直接进入步骤 4 整合确认卡。
3. 仅当存在关键缺口时，每轮追问聚焦 1–3 个最关键缺口；追问轮次按缺口数量自适应，上限 MUST ≤3 轮；用户已明确的不重复追问。
4. 整合为《旅游诉求确认卡》：明面需求（用户明说的）+ 潜在诉求（由关系/画像推断的节奏、动线、风险偏好）。
5. 声明自检句（含当前阶段=需求挖掘、澄清轮次），输出确认卡供用户确认；未确认不回环。

### 阶段② 方案生成（3–5 个）

1. 依据确认卡，按 `references/itinerary-planning.md` 的组合策略与 `references/creator-strategies.md` 的差异化轴（季节窗口/文化主题/风险等级/时间盒/情感价值层），从预算/日期/时间/地点/交通/人数/关系/旅游目标等维度组合出 3–5 个差异化方案。
2. 每个方案 MUST 含：标题 + 一句话说明 + 预算区间 + 亮点 + 适合人群 + 风险点 + 建议出行时长。
3. 跨方案 MUST 有差异性（非同质化换皮）；方案涉及景区当前情况（开放/限流/票价）时附实时信息与置信标注。
4. 输出方案对比集，请用户选定；用户未选定不回环。

### 阶段③ 小时级规划（选定方案后）

1. 依据选定方案，按 `references/itinerary-planning.md` 的行程模板与 `references/creator-strategies.md` 的时间轴设计参考（讲解配比/制高点动线/黄金时段/反人流/补给预警），以小时为粒度输出关键节点表：
   - 交通接驳（出发/到达/中转/接驳耗时）
   - 景点游览（进园/游览时长/离园）
   - 餐饮/休息/夜景节点
   - 动线合理性（不走回头路）
2. 每个关键节点 MUST 附**备选应急规划**（若 A 不成则走 B：天气突发/限流/预约失败/临时闭园等）。
3. 预算细项列表（大交通/当地交通/住宿/门票/餐饮/购物 + 15–20% 应急金）。
4. 风险提示（证件/保险/海拔/健康/人流高峰安全/当地习俗），涉及实时信息时附置信标注与来源。
5. 行前准备清单（证件/健康/保险/执照装备/通讯/紧急联系/体能/合规分层；跨境、高风险或长途行程 MUST 按 `references/creator-strategies.md` §四.4 输出）。

### 交付

**路径 S（全生命周期）**：输出 1 份完整方案（行前准备 → 逐日行程时间轴 → 预算明细 → 应急预案 → 返程收尾 + 假设/待确认汇总），结构清晰、分层标题、关键内容表格化，便于审计核对打印。

**路径 D（多方案）**：输出诉求确认卡回放 + 3–5 方案对比 + 选定方案小时级时间轴 + 备选应急表 + 预算明细 + 风险提示。

**共同收尾**：
1. 明确声明「本 skill 只负责规划；若需在多个方案间收敛决策，请触发 tri-ask 的 I04 决策辅助」。
2. 若用户后续细化追问 → 由 tri-meta 接住追加细化信号，重路由回本 skill（路径 S 回 S3 细化，路径 D 回阶段③）。

## 交付产物机制

### 一、文件命名规范

- 本 skill 为轻量规划型：攻略主体在对话内即时交付（行程时间轴/方案对比表/应急表），默认**不落盘**。
- 若用户明确要求保存攻略 → 按用户指定路径落盘（非 .tribro/），文件名建议 `旅游攻略_<目的地>_<日期>.md`。
- 经验教训文件：`.tribro/travel/lessons.md`（进化契约载体，见 §进化契约）。

### 二、产物清单

| 产物 | 内容 | 路径/阶段 |
|---|---|---|
| 结构化真实需求描述 | 用户已明确项 + 假设项（含影响与待确认标记）+ 实时信息快照 | S2 二次确认 |
| 全生命周期方案 | 行前准备 + 逐日时间轴 + 预算明细 + 应急预案 + 返程收尾 + 假设汇总 | S3 主方案 |
| 条件备选 | 变动项 + 影响 + 取舍（仅差异显著时） | S3 备选 |
| 旅游诉求确认卡 | 明面需求 + 潜在诉求（维度补齐表） | D 阶段① |
| 方案对比集 | 3–5 方案（标题/预算/亮点/人群/风险） | D 阶段② |
| 小时级时间轴 | 逐日逐时关键节点表 | D 阶段③ |
| 备选应急表 | 每节点的 Plan B | 两路径共用 |
| 预算明细 | 分项 + 应急金 | 两路径共用 |
| 风险提示 | 证件/保险/健康/安全 | D 阶段③ |

### 三、呈现格式

- 方案对比、预算明细、时间轴用表格；应急用「节点 → Plan B」映射。
- 路径 S 方案 MUST 分层级标题（`##` 分节 + `###` 子项），关键内容 MUST 以表格或清单呈现，便于用户审计、核对与打印。
- 若用户偏好可视化，可提供时间轴/地图动线示意（可选，非强制）。

## 质量标准

> 每条标准都可被独立验证。交付前逐行核对，任一不达标则回到对应阶段。

| 维度 | 标准 | 验证方式 |
|---|---|---|
| 路径判定 | 已指名景点走 S、目的地为变量走 D，判定写入自检句 | 分流闸门核对 |
| 阶段顺序 | 路径 S：需求未确认不出方案；路径 D：需求未确认不出方案、方案未选定不排小时行程 | 流程节点核对 |
| 拷问投递 | 路径 S 每轮 2–4 项、≤4 轮；路径 D ≤3 轮且自适应（输入充分可跳过） | 轮次计数 + 单轮项数核对 |
| 方案数量 | 路径 S = 1 主方案（+条件备选）；路径 D = 3–5 个且有差异性 | 计数 + 跨方案差异核对 |
| 确认卡分类 | 路径 S 二次确认 MUST 区分「用户已明确」与「假设项」 | 确认卡分节核对 |
| 生命周期完整 | 路径 S 覆盖行前/逐日/预算/应急/返程五段 | 方案骨架逐节核对 |
| 假设标注 | 信息不全或需求模糊处 MUST 标「假设」与「待确认项」 | 假设汇总表核对 |
| 小时粒度 | 关键节点精确到小时，含接驳/游览/餐饮 | 时间轴字段核对 |
| 应急覆盖 | 每个关键节点有备选应急 | 应急表逐节点核对 |
| 实时信息 | 景区现状结论附来源与置信标注；路径 S 至少覆盖开放+天气+门票三类 | 置信标注 + URL 核对 |
| 预算完整 | 分项 + 15–20% 应急金 | 明细核对 |
| 结论置信 | 每个结论性表达附置信度/依据/来源 | 逐条核对 |
| 教训闭环 | 结束写入 `.tribro/travel/lessons.md` | 文件追加检查 |

## 落盘规则

> 本 skill 的链路落盘遵循家族约定 `.tribro/<短名>/`（本 skill 短名 `travel`）。

- 快照由 tri-intent 已落盘于 `.tribro/snapshots/`（本 skill 只读，不重复产出）。
- **经验教训文件**：`.tribro/travel/lessons.md`（进化契约载体，启动读取 + 结束追加；目录或文件不存在静默跳过）。
- 攻略主体默认不落盘（即时对话回应）；用户要求保存时按用户指定路径落盘（非 .tribro/）。
- 本 skill 的发布物为自身目录（`tri-travel/`），随包分发。
- NEVER 生成 `LICENSE` 或 `.gitignore`——许可证仅由 frontmatter `license: MIT` 声明。

## 版本检查与更新机制（强制技术约束 · 硬红线）

> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的**第零步**，先于核心执行阶段。
> **细则唯一真源**：`references/version-check-spec.md`（本 skill 自包含副本，不依赖任何外部 skill）。**可执行实现**：`scripts/check_update.py`。
> **铁律**：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析其 JSON 输出 + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。

**执行方式（MUST）**

1. 任一执行入口启动后、核心执行前，运行脚本并取 JSON：`python scripts/check_update.py --slug tri-travel --json`（节流 24h；`--force` 强制重查；`--dry-run` 只判定不真升级；脚本自动定位 skill 目录，`--slug` 显式指定自身 slug）。
2. 解析 JSON 的 `state` 字段，按态处置：`A`/`B`/`C`/`D` → 一律放行进入后续阶段，据 `warnings`/`notes`/`actions` 标注对应口径；`BLOCK` → 绝对禁止执行，按 `block_code` 输出结构化恢复指引。
3. 退出码语义：`<20` 放行，`>=20` 阻断。脚本自身异常时兜底降级放行，NEVER 因版本门自身故障阻断 skill 启动。

**执行细则**：四态判定、升级流程、版本比较算法、节流缓存、阻断条件等完整细则见 `references/version-check-spec.md`（自包含副本）；本章节 NEVER 内联上述细则。

## 知识装配顺序（约束 25 · references ≥3）

> 本 skill 含 `references/` 6 个文件，装配顺序与覆盖优先级如下：

| 层 | 文件 | 装配条件 | grep 模式 |
|---|---|---|---|
| 常驻层 | `references/version-check-spec.md` | 每次启动第零步 | 版本/四态/节流 |
| 常驻层 | `references/destination-grill.md` | **路径 S 全程**（拷问清单/二次确认/全生命周期骨架） | 拷问/二次确认/全生命周期/行前/返程/假设 |
| 常驻层 | `references/travel-requirements-clarify.md` | 路径 D 阶段① | 维度/追问/确认卡 |
| 角色层 | `references/itinerary-planning.md` | 路径 D 阶段②③；路径 S 的时间轴/应急/预算模板 | 组合/时间轴/应急/预算 |
| 常驻层 | `references/scene-data-sources.md` | 涉及实时景区信息时 | 信息源/搜索指令 |
| 角色层 | `references/creator-strategies.md` | 进入路径 D 阶段②③，需差异化轴/时间轴/行前清单参考时 | 创作者/季节窗口/文化主题/风险等级/反人流/行前清单 |

- **去重**：同名文件只加载一次，优先级 常驻层 > 角色层（按需装载，不重复注入）。
- **覆盖**：外部目录出现同名 `references/*.md` 时，以本 skill 内嵌版本为准（本包优先）。

## 完成判据（约束 24 · 外化）

> 「何时算完成」外化为可机械校验的判据，NEVER 依赖模型自述「已完成」。

| 判据 | 可校验信号 |
|---|---|
| 路径判定完成 | 自检句声明路径 = S 或 D 及依据 |
| 路径 S · S1 完成 | 拷问收敛（≤4 轮，每轮 2–4 项）或已充分跳过 |
| 路径 S · S2 完成 | 输出结构化真实需求描述（已明确项 + 假设项 + 实时快照）且用户已确认 |
| 路径 S · S3 完成 | 输出 1 份全生命周期方案（行前/逐日/预算/应急/返程 + 假设汇总），条件备选按需 |
| 路径 D · 阶段①完成 | 输出诉求确认卡且用户已确认 |
| 路径 D · 阶段②完成 | 输出 3–5 个差异化方案且用户已选定 |
| 路径 D · 阶段③完成 | 输出小时级时间轴 + 每节点应急 + 预算明细 + 风险提示 |
| 交付完成 | 对应路径产物齐备 + 结束教训已写入 `.tribro/travel/lessons.md`（或写入失败已提示） |

- **停车态 vs 结束态**：等待用户确认需求/选定方案时，状态为**停车**（等待用户输入），非结束；对应路径产物齐备 + 教训写入完成方为**结束**。

## 进化契约（约束 23 · 自进化）

> 本 skill 通过「经验教训文件读写闭环」接收反馈、沉淀经验、自我修订。

1. **反馈接收点**：用户对本 skill 产出的攻略不满意/纠错时，将改进建议记入本次执行教训；也欢迎将建议提交至 skill 维护者。
2. **经验沉淀位**：每次执行结束追加写入 `.tribro/travel/lessons.md`（含日期、场景、问题/经验、可操作规避动作；空泛内容禁写；无新增教训写「无新增」占位留痕）。
3. **自我修订触发条件**：同一类教训重复 ≥3 次时，可修订本 skill 的描述/维度表/模板以规避。
4. **启动读取**：版本检查第零步完成后、核心执行前，MUST 读取 `.tribro/travel/lessons.md`；目录或文件不存在则静默跳过（NEVER 报错/中断/追问）。
5. **写入失败处置**：写入失败 MUST 提示用户但不阻断交付；完成判据须含教训写入（或失败提示）项。

## 目录结构

```
tri-travel/
├── SKILL.md                       # 主入口：双路径流水线 + 实时信息支撑 + 置信标注 + 版本门 + 进化契约
├── README.md                      # skill 简介与使用说明
├── CHANGELOG.md                   # 版本变更历史（Keep a Changelog + SemVer）
├── _meta.json                     # 发布元数据（slug / version / ownerId / publishedAt）
├── scripts/
│   └── check_update.py            # 版本检查与强制自动更新脚本（四态判定）
├── references/
│   ├── version-check-spec.md      # 版本检查与更新规范（自包含副本，内部唯一事实源）
│   ├── destination-grill.md       # 路径 S：拷问清单 + 二次确认模板 + 全生命周期方案骨架
│   ├── travel-requirements-clarify.md  # 路径 D 需求挖掘维度表 + 追问模板 + 诉求确认卡模板
│   ├── itinerary-planning.md      # 组合策略 + 小时级时间轴模板 + 应急模板 + 预算明细
│   ├── scene-data-sources.md      # 景区实时信息源 + 搜索指令集 + 字段核对
│   └── creator-strategies.md      # 头部创作者经验集成参考（路径 D 阶段②③ 规则表）
└── tests/
    └── tri-travel-full-testcases.md   # 全场景全能力测试用例
```