想去富士山骑车，于是我做了一个帮助自己规划行程的工具

我很想去富士山骑车。

有了这个念头，也就想知道路况如何、路线有哪些地方需要注意。地图上的一条线，到了现场会是怎样的道路？一天的行程走下来，爬坡集中在哪里，休息和接驳又该怎么安排？

我把这些问题带进准备过程，做了一个富士山骑行行程网页。后来又做了 Field Brief（户外行程准备工具），希望能帮助一起去的人，以及未来也想去的人。

制作期间，我也碰到好几次语言模型更新。这个行程工具，成了我感受模型能力变化的一个具体项目。

先让人看懂这趟旅程

行程表可以交代每天去哪里，但光看地名和时间，仍需要自己把整趟旅程拼起来。对不熟悉当地的人来说，一个地名与下一个地名之间，还隔着距离、地形，以及对体力的想象。

所以，这个网页把三天骑行路线放进动态地图，让人切换日期、播放路线，再对照里程与高度剖面。画面也显示下一站和富士山的方向。这些信息放在一起，可以帮助用户在出发前先理解一天的移动。

我希望同行的人能指着同一张图，讨论某一段上坡或休息的位置，用它作为理解行程的共同参照。也希望大家看完之后，能指出自己不理解、或想再确认的地方。这是我想通过界面帮上忙的事。

动态图适合交代旅程的整体关系，细节则交给旁边的行程表与说明。阅读的人可以先看路线，再往下找自己需要的资料，不必一开始就读完所有内容。

如果问我，制作过程中哪一次修改最关键，我很难挑出单独一次。

比较强烈的感受是，模型演化的速度很快，而且在制作网页的过程里，我能直接感受到。

特别是在更新路线动画、加入开场音乐的时候，我发现整个协作过程十分流畅。甚至请模型帮我找 GPX 路线数据，也很顺。模型能力的变化，就这样出现在一项项实际的工作里。

我在网站另外整理了模型前沿即时仪表盘，从任务用途与成本等角度观察模型选择。有兴趣了解不同模型适合哪些工作，也可以从那里开始看。

行程工具做得越完整，阅读的人越可能直接相信画面上的内容。对一个准备带到户外使用的工具，这是设计时必须处理的问题。

路线画得出来，仍需要确认现场能否通行；高度剖面能帮助理解地形，数值的来源与估算方式也需要交代。当一个数字影响到体力分配或时间安排，用户应该知道它能支持什么程度的判断。

目前的富士骑行页面保留候选路线标注、改版记录，以及仍待日方确认的项目。高程也注明来自地形模型估算。这些说明与动态地图放在同一个页面，让人看行程时，也看得到它的限制。

我希望工具能帮忙把问题整理得更清楚。哪些可以先从资料理解，哪些必须问当地协助的人，哪些到了现场还得重新判断，都有各自的位置。模型能力提升之后，这些确认工作仍然需要有人负责。

富士骑行网页对应的是这一趟旅行。我也希望，之后想去的人能从中得到帮助。因此，我另外设计了 Field Brief（户外行程准备工具）。

当用户换成另一个人，工具就需要留出填入不同需求的空间。目的地可能不同，日期会改变，有人已经拿到路线文件，有人还在想自己要怎么走。

Field Brief 的公开界面把流程分成填行程、选地点与日期、查天气与确认，再下载简报。不需要登录，没有 GPX 路线文件也能先开始。它试着把路线、天气与待确认事项，整理成一份可以带走的行前资料。

没有 GPX，也许只是行程还在准备中。让人先填行程、选地点与日期，再处理天气与待确认事项，就不必在第一步备齐所有资料。这比较接近我希望工具陪伴用户的方式。

简报也需要保留数据来源与适用日期。特别是天气，看到示例与查到自己出发日期的预报，是不同阶段的事情。Field Brief 的示例会标注演示快照，用户准备自己的行程时，仍要重新查询与确认。

Field Brief 从填行程、选地点与日期、查天气与确认，到下载简报的四步流程。

写下这篇时，这趟富士山骑行还没开始。工具能否在实际行程中帮上忙，还要由实际使用来检验。

换成其他地方、其他路线之后，哪些设计仍然好用，哪些需要调整，也需要不同的人带着自己的需求来试。

如果你也有一趟正在准备的旅行，可以先看看富士骑行的动态路线，再把自己的行程带进 Field Brief。不用等到所有事情都确定，先从你最想知道的那个问题开始。