旅行行程页面
将每日旅游计划转化为单个 HTML 文件：每个日期的粘性标签、一个倒计时横幅、时间线风格的活动卡片（带标签：免费/需预订/价格/交通/适合独行/推荐）、一个准备清单以及一个必备信息面板。无需构建步骤，无依赖——一份文件即可，手机也能用，易于在任何地方重新部署（Vercel、Netlify、GitHub Pages，或直接在本地打开）。
从 assets/template.html 开始。不要从头构建——该模板已经包含了经过测试的 JavaScript，用于处理最棘手的两个部分（导航自动滚动和下面的倒计时/日期逻辑），重新实现它们往往会重新引入已经修复的 bug。
工作流程
1. 收集所需信息（如果对话中尚未提供，请询问）
- 旅行者是谁，主办方是谁（如果有的话）——名字即可
- 目的地和日期范围
- 确切的到达和离开日期+时间，以及它们所基于的时区。 这是最常见的错误来源——在硬编码任何内容之前，请先查看下面的陷阱。
- 每日计划（如果已经讨论过）——从对话中提取，而不是重新询问
- 任何将出现在页面上的住所、私人地址或集合点
- 主题偏好（见下方主题部分）——如果用户不关心，默认使用
kawaii-pink，它经过最充分的测试
不要因为缺少每个细节而停滞不前。对于缺失的信息，使用占位符（[待填写]）起草，并在回复中明确标记出来，而不是因为一个未知项而阻止整个页面生成。
2. 隐私检查——在写入任何地址之前执行此操作
如果旅行者住在酒店、Airbnb 或其他著名住宿场所，则可以明确写出房产名称和社区——它已经是公开的商业信息，而且命名确实有用（对于拼车司机、对于前来会面的朋友）。只需省略房间/单元号。
如果旅行者住在某人的私人住宅（朋友或家人的住所），则绝不要将字面地址、确切建筑名称或精确的住宅社区写入文件——即使您已通过聊天直接从用户那里获得这些信息，如果页面可能被截图、分享、托管在可猜测的 URL 上或变为公开。
对于私人住宅情况，效果良好的模式：将具体位置替换为类似 "我发给你的地址" 或 "我们老地方" 的内容——对于真正需要该信息的人来说，这读起来像是一个自然的内部笑话，并且对外部读者不透露任何信息。保留交通线路名称和大致区域（"X 线上的一个车站"），因为这确实有用，且本身不具有识别性。
请一致地应用此规则：如果一个具体地名出现在多个位置（例如，在"必备信息"卡片和路线描述中（如"乘坐火车到 X"）都提到了住宅社区），则以相同的方式对所有此类信息进行脱敏处理。一个被编辑的卡片旁边有三个随意提及真实名称的地方，这会让脱敏失去意义。
3. 选择主题
该模板附带两个完整的主题，通过一个属性切换：
<html data-theme="kawaii-pink"> <!-- 或 -->
<html data-theme="neutral-modern">
所有其他内容——字体、颜色、装饰性页眉形状——都自动跟随这一个值；您无需触及 CSS 的其他部分即可切换。要添加第三个主题，请复制文件顶部附近的 [data-theme="..."] CSS 块之一，重命名它，并调整变量——请参见 examples/demo-lisbon-trip.html 获取一个完整示例（一个以此方式构建的自定义 lisbon-tile 主题，使用蓝色瓷砖 + 赤陶色，而不是两个默认主题）。
页眉已包含一个带有柔和圆点纹理的渐变背景、一个向下延伸至页面其余部分的波浪形分隔线、一个统计数据"芯片"行，以及一个可选装饰性角落装饰（.corner-orb）和小图标（如用于 kawaii-pink 的 .bow），每个主题可以启用或关闭——您无需重新构建任何这些内容，只需填入芯片文本，并为新主题切换显示哪些装饰元素（请参见 CSS 顶部附近，.bow/.tile-ornament/.corner-orb 如何按 data-theme 进行作用域限定）。
4. 构建每日卡片
每一天是一个 <section class="day">，带有 data-date（ISO 格式，由导航构建脚本使用）和 data-title（显示在标签中的简短标签）。内部，是一个带有彩色徽章的页眉，然后是一个由 .item 块组成的 .timeline：一个时间、一个加粗的标题、一到两个句子，以及可选的标签。
开箱即用的可用标签：free（免费）、book（需提前预订）、price（在标签文本中显示实际费用，例如 "¥500" 或 "$12"——货币因旅程而异）、transit（值得指出的交通指令）、solo（适合独自完成/适合独行的时间段）、highlight（一个通用强调标签，用于旅程的个性化亮点——可以是粉丝圈、内部笑话、"不容错过"的标志）。如果旅程需要这些未涵盖的类别，请以相同方式添加新的标签类。
每个项目保持描述文本为一到两个句子——这是一个便于手机上快速浏览的参考，不是一篇博客文章。
5. 连接倒计时——在设置日期之前阅读此内容
在文件底部附近：
var arrive = new Date('2026-07-18T15:05:00+09:00');
var depart = new Date('2026-07-25T18:00:00+09:00');
页眉会在旅程开始前显示一个实时的、不断跳动的天/时/分/秒倒计时，然后在旅程期间自动切换到"第 N 天"，在旅程结束后显示"旅程完成"——这由每秒运行一次的 tick() 函数处理，您无需构建这一部分。
需要主动检查的常见错误： 预订确认中的出发日期是指旅行者离开出发城市的日期，而非他们抵达的日期。在长途或夜间航班上，当地到达时间通常几乎是目的地的下一个日历日——行程单会通过在到达时间旁边添加一个小的"+1 天"标记来提示，这很容易被忽略。在硬编码到达时间戳之前，请明确确认：出发日期 + 航班时长，对照目的地时区偏移检查，实际落地日期是否与您即将写下的日期相符。如果搞错了这一点，整个倒计时（以及日导航的"今日"高亮）都会偏差一天，通常只有在某人在机场等待一架尚未降落的航班时才会发现。
同时请仔细检查 ISO 字符串中的 UTC 偏移量是否与目的地的时区匹配，而不是旅行者家乡的时区。
6. 粘性日期导航
这会根据存在的任何 .day 部分自动构建——您无需手动编写。有两个值得了解的行为，都已实现：
- 活动标签由滚动位置确定，并在用户滚动时高亮显示
- 标签条会自动水平滚动自身以保持活动标签可见。如果没有这个功能，滚动到第 6 或第 7 天的用户会发现相应的标签已经滚离了导航栏的可见边缘，必须手动滚动它——这是早期版本中的一个真实 bug，修复方法是
syncActive()中的scrollTo块。在自定义时不要删除它。
7. 填写清单和必备信息面板
- 清单（
#checklist）：预订和准备任务，每个都是一个复选框。在界面文案中注明复选框会在重新加载时重置（没有后端）——不要让用户认为它是持久的。 - 必备信息：他们住的地方（见上方关于酒店与私人住宅措辞的隐私检查）、如果分散时的集合点、目的地国家的紧急联系电话（不要默认为一个国家的号码）、天气/冷热应对计划、现金/支付规范，以及任何在出现小混乱（如火车延误、手机没电）时真正有用的其他信息。此面板应保持简短——五到六个卡片，而不是一本完整的指南。
8. 在交付之前，请检查
- 到达/离开日期和时区是否正确（重新阅读步骤 5）
- 文件中没有任何字面家庭地址或精确的私人位置信息，包括路线描述内，而不仅仅是必备信息卡片
- 主题属性与用户要求的一致
- 如果您修改了脚本，导航自动滚动仍然有效
- 复选框在被选中时明显会划掉其标签
- 保存到输出/可交付位置，并将文件呈现给用户（使用此环境中可用的任何文件交付工具；如果没有，则直接告知用户文件路径）
9. 准备好持续编辑
旅行计划不断变化——航班延误、天气恶劣、餐厅已订满、交换日期。当用户带着更改回来时，通过有针对性的替换编辑特定部分，而不是重新生成整个文件；用户可能已经修改了其他地方的副本，完全重写会悄悄丢弃这些修改。重新部署（如果已托管）只需重新上传同一个文件——如果用户提到了 Vercel 或 Netlify 等主机，请在编辑后提醒用户执行此操作，因为在这里所做的更改不会自动推送。
此技能中的文件
assets/template.html— 起始点。复制它，然后按照上述步骤操作。