travel-itinerary

旅行行程

概述

将旅行确认信息、预订邮件、票据、会议记录、餐厅预订信息和临时旅行详情整理为结构化、可导出的内部商务旅行行程。

思维模型：

Trip
└── Day
    ├── Stay / overnight base
    ├── Node 1
    ├── Link / route to next node
    ├── Node 2
    ├── Link / route to next node
    └── Node 3

• 行程 — 整体背景：同行人员、目的地、日期范围、出行目的、隐私偏好。
• 日程 — 日期、过夜住宿、当日备注、按时间排序的节点。
• 节点 — 航班、火车、酒店入住、会议、兴趣点、餐厅、接送、活动、需购票的景点、空闲时段、行政提醒或自由格式备注。节点带有 visibility，因此内部版、团队共享版、私人版和差旅行政版导出内容可以安全地有所不同。

事实来源是规范 YAML（参见 templates/itinerary-schema.yaml）。Markdown 是默认渲染格式，也可选择 .ics、PDF、DOCX、Google Doc 和适用于聊天的版本。

适用场景

用户希望执行以下操作时，请使用此技能：

• 根据转发或粘贴的邮件创建商务旅行行程。
• 整理航班、酒店、火车、餐厅、票据、会议和景点。
• 将零散的预订确认信息转换为清晰的逐日安排。
• 创建团队共享版或高管版行程。
• 分享前隐藏敏感详情。
• 在行程地点之间添加行程时间或地图链接。
• 导出为 Markdown、PDF、DOCX、Google Doc、聊天消息或日历 .ics。
• 根据新的确认信息或变更更新现有行程。

不要将此技能用作完整的差旅管理后端。如果任务需要自动监控收件箱、持久化的多行程数据库、实时航班状态、多用户编辑或 Web 应用分享，请建议在此技能之外使用其他工具。

此技能用于整理和呈现用户提供或通过工具检索的旅行信息。除非当前任务中已通过可用的实时工具核实，否则不要声称航班状态、当前价格、场所开放时间、路线时长、票务可用情况或预订可用情况是实时信息。

参考文件

此技能按渐进式披露拆分。需要深入了解某个主题时，请阅读相应参考文件：

• templates/itinerary-schema.yaml — 规范 YAML 结构，即事实来源。
• references/node-types.md — 各节点类型的完整字段表，包括航班和火车专属字段以及状态生命周期。
• references/exports.md — Markdown／聊天／高管／行政模板、.ics 规范和文件命名约定。
• references/privacy.md — 敏感字段、信息删减模式和各版本的内容包含矩阵。
• references/routing.md — 坐标层级、Nominatim／OSM 地理编码、地图 URL 模式和默认路线规则。
• examples/tokyo-trip.md — 端到端完整示例：源邮件 → YAML → 全部四种导出版本 → .ics。
• scripts/itinerary_utils.py — 用于确定性杂务的轻量级标准库辅助工具：Google Maps 路线 URL、iCalendar 转义与折行，以及 .ics 合理性检查。使用 python3 运行。

核心工作流

1. 收集输入。 转发的邮件、PDF 确认单、屏幕截图、手动记录，以及需要更新的现有行程。
2. 提取结构化事实。 供应商、预订参考编号、旅客、日期／时间／时区、起点／终点、地址、入住／退房规则、取消说明、票务条件、联系方式、费用。
3. 将每项归类为一个节点。 使用 references/node-types.md 中的类型枚举。
4. 按行程和日期结构分组。 推断大致目的地和日期范围。将每个节点分配到正确的当地日期。通过 overnight_stay 将酒店信息放到相关住宿日期。按时间顺序排列有具体时间的节点。将没有具体时间的节点放在单独的“待安排／备注”部分。
5. 有选择地对地点进行地理编码。 默认对路线关键和分享关键的地点进行地理编码：酒店、机场／车站、会面地点、预订的餐厅以及已预订的接送服务。仅在用户要求地图信息丰富／路线信息丰富的行程时，才对可选的兴趣点或所有有地点信息的节点进行地理编码。绝不虚构坐标——请参阅 references/routing.md。
6. 按顺序连接节点。 仅为高价值行程连接添加路线链接（机场 ↔ 酒店、酒店 ↔ 客户办公室、会议 ↔ 重要晚餐、城际接送）。除非用户提出要求，否则不要为每段短途步行都规划路线。
7. 标记不确定信息。 缺失的航站楼、地址、时区、乘客姓名、确认编号、入住时间或日期。冲突、重复、含糊不清的酒店住宿日期、含糊不清的旅客分配。将这些信息放入“待确认问题／缺失详情”。
8. 生成不同的导出版本。 按需生成内部完整版、团队分享版、高管摘要版、差旅管理版、聊天版、.ics。请参阅 references/exports.md 和 references/privacy.md。

输出位置

将最终交付文件保存到用户选择的文件夹或约定的工作区。工作草稿和中间 YAML 可以放在临时目录中。使用 references/exports.md 中的命名约定。

展示文件时，使用环境支持的交付方式：

• 聊天／消息环境：使用平台的文件附件功能直接发送本地文件。
• CLI／桌面环境：提供绝对文件路径或受支持的本地文件链接。
• 云文档导出（Google Docs / Drive 等）：提供经过验证的分享 URL。

时间和时区约定

• YAML 中所有 starts_at / ends_at / due_at 的值都必须是带明确时区偏移量的 ISO 8601 格式，例如 2026-06-12T08:10:00+09:00。
• 对于跨时区的航班和火车，starts_at 的偏移量是出发地当地偏移量，ends_at 的偏移量是到达地当地偏移量。当 IANA 名称不同时，或生成 .ics 时，也要填写 timezone_start 和 timezone_end。
• 每天都带有一个 local_timezone（IANA 名称）。它会覆盖当天的 trip.timezone_default——行程在途中跨越时区边界时需要此设置。
• 渲染后的 Markdown 使用24 小时制 HH:MM，时区为所在日期的当地时区，并在日期标题中显示时区（例如 ## Day 1 — Friday, 12 Jun 2026 (Asia/Tokyo)）。
• 对于过夜或红眼行程，在 Markdown 中将节点放在出发日期，并在次日添加到达时间管理备注。

状态生命周期（简述）

每个节点的 status 都是 confirmed | tentative | cancelled | unknown 之一。根据确认单创建的项目默认设为 confirmed。对于暂时保留或“可能”参加的项目，使用 tentative。绝不删除已取消的节点——将其设为 status: cancelled 并保留以供审计；渲染时会在分享版本中隐藏这些节点，并在内部版本中将其标为删除线。完整的渲染规则和变更处理方式：请参阅 references/node-types.md。

OCR 和来源质量

从屏幕截图或扫描版 PDF 中提取信息时：

• 将 source_item.ocr_quality 设为 high、medium、low 或 unreadable。
• 将不确定的字段列入 source_item.ocr_uncertain_fields。
• 对于不确定的字段，将字段留空并添加到“待确认问题”， 或为所见内容加上 ? 前缀并引用（"?ABC12?"）。切勿在不说明的情况下 规范化。
• 如果来源的状态为 unreadable，不要据此生成节点；请用户重新发送或转录内容。

隐私和导出版本

始终区分内部完整版本和可分享版本。 敏感字段（付款信息、护照信息、会员信息、预订 PIN 码、个人 联系人）应按矩阵中的规定进行脱敏或省略，详见 references/privacy.md。 **默认规则：**如果用户未指定受众，只要求“行程”，则默认提供内部完整版本，并在生成团队分享版本前询问。切勿默认提供团队分享版本——意外向外过度分享的风险高于意外向自己过度披露。

路线和地图链接

如果有可用的地理编码/地图工具，请使用（Nominatim/OSM 或地图 MCP）。如果没有 可用的地图工具，则将坐标留空，并在地图链接中使用易读地址或代码。

• 默认对路线关键和分享关键地点进行地理编码：酒店、 机场/车站、会议地点、预订的餐厅和已预订的接送服务。
• 只有在用户要求生成包含丰富地图信息或路线信息的行程时，才对可选 POI 或所有已定位节点进行地理编码。
• 有坐标时，使用坐标构建 Maps URL；否则使用经过 URL 编码的地址或 IATA 代码。切勿编造坐标。
• 默认仅为高价值的行程衔接规划路线（参见工作流步骤 6）。
• 始终在坐标旁保留易读地址，以确保 Markdown 内容清晰易读。

完整规则：references/routing.md。

澄清政策

只有当歧义会实质性影响行程时才提问。

以下情况需要提问：

• 两项预订时间冲突。
• 旅客分配不明确（例如，只有一张机票却有两名旅客，且只列出一名乘客）。
• 酒店预订对应的住宿日期或旅客不明确。
• 会议未说明旅行团中由谁出席，或他们将与谁会面（这是两个独立字段，不是通用的 participants 字段）。
• 时间缺少时区，且可能影响行程顺序。
• 用户要求分享，但隐私级别不明确。
• 地理编码工具返回多个可信匹配结果，且无法明确选出一个。
• 来源的 ocr_quality 为 unreadable。

以下情况无需提问：

• 存在合理的默认选项，且可在“待确认问题”中标记不确定之处。
• 缺失的细节并不重要。
• 用户明确要求快速起草。

常见陷阱

1. 过早把内容做成完整应用。 对于内部使用，Markdown + 文件 + 可选的 Google Doc/PDF/.ics 导出就足够了。
2. 混合私人信息和可分享信息。 为他人导出时，始终分别生成内部版和团队分享版。
3. 为每个节点都添加过多路线。 除非另有要求，否则只为重要的转换添加路线。
4. 忽略时区。 跨境旅行必须保留两端的当地时间和时差。
5. 将酒店住宿视为单个入住节点。 对于住宿涵盖的每一晚，还要通过对应日期的 overnight_stay 指向该住宿；不要每晚都创建一个住宿节点。
6. 重复添加更新后的确认信息。 新邮件可能是变更通知；追加前应比较服务提供方、参考编号、日期/时间和地点。将旧节点标记为 cancelled，并添加指向新节点的私人备注。
7. 强行把没有指定时间的兴趣点排进日程。 除非用户提供了时间，否则应将它们放在可选/未安排的部分。
8. 夸大路线准确性。 如果时长未经工具核验，请省略，或标注为估算值。
9. 编造坐标。 纬度/经度必须来自地理编码器。凭记忆填写坐标还不如不填。
10. 只在会议中填写通用的 participants，却漏掉拆分字段。 对于会议节点，始终填写 attending_from_travel_party 和 meeting_with。
11. 把静态来源中的信息说成实时事实。 除非当前任务中有实时工具核验，否则不要将路线时长、场馆营业时间、可用性、价格或航班状态表述为当前信息。

核验清单

最终输出前，请检查：

• 已填写行程标题、日期范围、目的地和旅行团成员；若未知，则已明确标注。
• 每一天都有正确的日期、local_timezone，以及相关的正确过夜住宿信息。
• 每一天的节点均按时间顺序排列。
• 航班/火车时间保留两端的当地时间和时区。
• 酒店入住/退房日期与通过 overnight_stay 标示的住宿晚数相符。
• 如有 lat/lon，它们来自地理编码器；没有编造坐标。
• 对重要地点和重要行程转换，已提供地址和 Maps 链接。
• 任何关于实时状态、可用性、路线时长、营业时间或价格的说法，均已通过工具核验，或明确标注为来源提供/当前未经核验。
• 根据 references/privacy.md，已在团队分享版、高管版和聊天导出版中隐去或省略敏感信息。
• 已保留取消的节点并将其标记为 status: cancelled，而非删除。
• 会议节点仅使用 attending_from_travel_party 和 meeting_with——会议的 participants 为空。
• 已列出未解决的问题，没有将其隐藏。
• 输出文件已写入用户指定的文件夹，并确认可读（对于 .ics，BEGIN/END 块配对完整）。