travel-guide

旅行指南

制作一份受委托定制的旅行档案，而不是一份泛泛的景点清单。完成后的指南应回答：为什么是这个地方，为什么适合这些旅行者，又为什么是现在？ 它应为探索留出空间，同时让人感到这趟旅行经过了周全考虑。

适用场景

旅行者有以下一项或多项需求时，使用此技能：

• 个性化行程或旅行简报；
• 设计精美的旅行 PDF 或可打印的旅行指南；
• 根据允许使用的偏好、限制条件或同行者情况提供建议；
• 为同行者制作可分享、自适应的网页；
• 为同一份旅行计划制作私密且经过信息脱敏的版本。

不适用场景

• 预订、购票、更改预约或处理付款。
• 需要权威专业人士或政府来源提供依据的签证、移民、医疗、安全或法律决策。
• 没有明确旅行者或行程时，撰写泛泛的目的地概览。
• 从现有文档中提取文字。应将此类需求交给 anydoc；它可以读取文档，但不能撰写或验证文档。

按需查阅

只阅读满足需求所必需的参考资料：

需求	阅读
个人背景、同意、针对性提问或团体取舍	references/intake-and-personalization.md
当前营业地点、营业时间、价格、预约、交通或来源质量	references/research-and-evidence.md
行程主旨、核心地点选择、每日结构或编辑风格	references/editorial-structure.md
私密版／可分享版或信息删减	references/privacy-and-sharing.md
HTML、PDF、打印 CSS、渲染或视觉质检	references/pdf-rendering.md

使用 templates/trip-brief.json 作为结构化的唯一事实来源。在录入 JSON 前起草内容时，使用 templates/dossier-outline.md。

工作流

根据需求调整流程。对于范围较窄的问题——一个街区、一家餐厅、一段接驳或一条实用信息——可以直接简短作答并附上来源。只有在旅行者需要指南、PDF、同行者网页或多日计划时，才运行完整的旅行档案流程。档案格式是一种交付形式，并非每个旅行问题都要自动采用。

1. 明确行程约定

收集或确认以下信息：

• 目的地或路线；
• 抵达和离开日期，或至少确认计划出行的季节；
• 行程时长和大致节奏；
• 同行者，以及他们在需求方面是否存在实际差异；
• 相关的预算范围和货币；
• 行动能力、饮食、感官、语言或预订方面的限制；
• 所需输出：私密 PDF、可分享 PDF、同行者网页，或三者兼有；
• 目标受众：旅行者、旅行团成员或更广泛的分享对象。默认按私密处理；如果受众不明确，应询问输出面向谁。

如果缺失的信息会影响建议，就提出有针对性的问题。不要进行冗长的问卷调查。关于提问数量限制和个性化边界，请查阅接待信息参考资料。

2. 明确处理个人背景

如果宿主可以检索用户偏好或历史记录，只能使用与本次行程相关且获准用于此目的的背景信息。在内部将每条个人信息归类为 known、relevant memory、hypothesis、ask first 或 do not use。切勿将原始私人备注直接复制到指南中。如果个性化处理可能让人感到意外，应简要说明相关依据或征求许可。

3. 研究当前事实

只研究指南所需的信息。优先使用场馆、运营方、交通、政府、旅游局和预订平台的官方来源。在来源台账中记录 URL 和检索日期。区分：

• 已核实的当前事实；
• 关于适配度的编辑判断；
• 估算和假设；
• 仍未知的事实。

不要把搜索摘要、过时记忆或无来源的价格说成当前事实。提出交通或费用相关说法前，先阅读研究参考资料。

4. 建立编辑模型

用一到两句话概述行程主旨。选择少量核心体验，而不是把所有选项都排个名次。每个核心体验都必须说明它为何适合这些旅行者、何时最合适、费用或所需条件，以及可能导致体验失败的因素。

每天围绕以下内容安排：

1. 一个核心体验；
2. 一顿饭、一杯饮品或一种本地生活风情；
3. 一段步行、一处街区或一次日常生活体验；
4. 一处休息或恢复精力的空间；
5. 一个天气、体力或闭园情况下的备选方案。

如果知名选项不太适合，请添加简短的“可以跳过”部分。起草行程档案前，先阅读编辑参考资料。

5. 生成交付文件

为本次行程创建一个专用工作文件夹（例如在 macOS/Linux 上使用 $(mktemp -d)，或在系统临时目录下创建一个命名文件夹），并将行程模型、渲染后的 HTML、已清理版本和 PDF 保存在其中。切勿将输出写入技能目录或用户主目录的根目录。以下示例使用 $WORK 表示该文件夹。

将内容与版式分开。先验证内容模型：

python3 scripts/validate-trip-brief.py "$WORK/trip-brief.json" --strict --json

渲染适合打印的 HTML 行程档案：

python3 scripts/render-travel-guide.py "$WORK/trip-brief.json" \
  --mode dossier --output "$WORK/travel-dossier.html" --json

如需制作响应式配套页面，请使用相同的模型：

python3 scripts/render-travel-guide.py "$WORK/trip-brief.json" \
  --mode companion --output "$WORK/index.html" --json

渲染器会尽可能嵌入随附的 CSS 和本地图片素材。使用支持打印的浏览器或仓库的 documents 技能，将行程档案 HTML 转换为 PDF。只有经过结构检查和视觉检查，PDF 才算完成。具体验收标准请阅读 PDF 参考资料。

6. 按需制作可分享版本

以私有模型作为事实来源。创建已清理的副本，不要在已完成的 PDF 上覆盖修改：

python3 scripts/sanitize-trip-brief.py "$WORK/trip-brief.json" \
  --profile shareable --output "$WORK/trip-brief-shareable.json" --json

单独渲染并验证已清理的模型。不要假设可分享版本可以公开精确日期、住宿信息、同行者、地址、预订编号、联系方式或私人备注。

行程档案必备章节

根据行程长度调整内容，但要保留以下信息层级：

1. 封面：目的地、行程主题、时长／路线和图片来源；
2. 行程简介：说明这趟行程为何适合这些旅行者；
3. 核心体验：可信度高的体验，以及适配度和行程信息；
4. 每日安排：核心体验、生活风情、休息和备选方案；
5. 特别之处：具体而非泛泛的搜索结果式安排；
6. 实用提示：交通、预订、礼仪、费用和注意事项；
7. 可以跳过：有吸引力但不适合的选项（如有）；
8. 来源与时效性：链接、检索日期和未解决的不确定因素。

默认视觉风格为深色摄影封面，配以路线行程线、暖金色眉题、白色标题和克制的红色点缀；内容页留白充足，并使用浅色背景；章节编号以淡化效果呈现；简介后紧接按颜色区分的每日行程条；配有节奏和预算指示条、紧凑卡片、核心体验图片统一采用暖色调处理、易读的表格，以及每个章节底部的页脚。若有相关内容，页脚应包含源自内容的实地提示（失败情形、备选方案、需重新核实的事项或跳过理由）、下一章节提示和淡化的路线标记。确保对比度充足，文字可选中。装饰不得掩盖不确定性或实用注意事项。页脚仅用于提供信息，绝不是日程安排：它用一行文字重复模型中的内容，不得凭空添加新计划。

退出标准

当所有请求的产物都已生成，并且满足以下条件时，即可停止：

• 行程模型通过随附的验证器；
• 当前声明附有来源 URL 和检索日期，或已标注为不确定；
• 如果有此要求，PDF 已通过结构和视觉 QA；
• 如果有此要求，配套页面已在窄屏和宽屏下完成检查；
• 私密输出与可分享输出已明确区分；
• 交付内容注明了来源模型、渲染器、验证结果和已知限制。