说明：以下按最新版 hci_final_presentation.pdf 的 25
页编写。讲稿围绕 slides 中新增的 HCI
原则展开，删除旧版用户调研结论页对应内容，改为与当前 PDF
的周边推荐、无障碍、路线偏好和票价比较页面一致。
各位老师、同学好，我们小组汇报的题目是《港铁票价优化器与综合交通交互系统》。这个项目是《人机交互导论》的课程大作业，面向香港公共交通用户，目标不是只做一个路线查询工具，而是把路线、票价、换乘、无障碍设施和站点周边信息放到同一个出行决策界面里。
我们的组员分工也列在这一页。项目已经开源在 GitHub，仓库是
Tanghui-Li/MTR-fare-optimizer；在线版本部署在
mtr-optimizer.shgao.top。老师和同学可以通过右侧二维码课后访问。
我们从一个具体问题开始：从罗湖到屯门，成人八达通常规票价是 59.2 港币；如果在东铁线粉岭站出闸再入闸，系统算出的总价是 51.5 港币，可以节省 7.7 港币。
这个结果不能靠一句经验规则直接判断。它需要查询港铁票价矩阵，枚举可能的中间出入闸站，再比较不同组合的总价。很多地图软件会优先给时间最短、少换乘或少步行的路线，但很少把“港铁票价最低”作为主要目标。
所以我们的系统同时回答三件事：怎么走，多少钱，为什么这样走。后面四个部分分别是项目背景与路由算法、界面设计和移动端适配、站点周边推荐，以及无障碍和用户偏好。这里对应以用户为中心设计：先从真实任务出发，再组织系统的信息架构和交互流程。
香港交通网络很复杂，直观路线的票价不一定最低。对用户来说，真正关心的不是算法内部怎么枚举，而是这趟行程花多少钱、应该怎么走、在哪里换乘，以及是否要额外出入闸。
这页新增强调了一个 HCI 视角：系统把票价查询、断点枚举和总价比较外化到界面上，降低用户在脑内试算的负担。也就是说，系统承担复杂计算，用户只需要理解真实站点、真实票价和真实出入闸动作。
数据方面，除了地图上的线路走向几何校正，站点、票价、设施和实时交通数据都基于香港政府开放资料 data.gov.hk。这里对应分布式认知和概念模型：系统用真实交通概念对齐用户直觉，让“为什么要在粉岭出闸”变成可解释、可执行的决策。
我们的输入数据包括港铁线路与站点 CSV、成人八达通和成人单程票票价矩阵、机场快线、轻铁、港铁巴士、车站无障碍设施和实时交通接口。
算法层面，我们把这些数据统一建模成交通图。图里的节点可以是车站、轻铁站、巴士站或换乘点；边可以表示乘车、换乘、出闸再入闸和接驳关系；边的权重不只包含票价，也可以包含时间、换乘和操作复杂度。
整体流程是：开放数据进入清洗和归一化，构建统一交通图，做路径搜索，最后把结果交给可解释界面展示。这里对应系统状态可见性：用户不需要看到所有数据表，但系统应该让数据来源、建模过程和输出规则有迹可循。
最低票价路线超过了简单最短路。系统输入是起点、终点和票种；然后按票种选择对应票价矩阵，在交通图上同时计算普通路线和分段票价优化路线。
输出不只是一个总金额，而是总票价、分段路线、站点序列、线路标签和出入闸说明。原因是票价优化可能要求用户在某些站出闸再入闸。如果只显示一个便宜金额，用户不知道应该在哪一步执行，也无法判断这条路线是否可信。
所以我们用分段卡片把“算法结果”转化为“用户能照做、能核对的步骤”。这里对应识别优于回忆和分布式认知：站点序列、出入闸动作和价格比较都放在界面上，用户不用记忆港铁隐藏票价规则。
这里回到开头的例子。查询罗湖到屯门，票种是成人八达通。常规路线票价是 59.2 港币。如果在粉岭站出闸再入闸，票价被拆成两段：罗湖到粉岭 26.5 港币，粉岭到屯门 25.0 港币，总价 51.5 港币，节省 7.7 港币。
这个例子说明，用户直觉里的“直达更合理”并不一定符合真实票价矩阵。港铁票价受区间、过境站和换乘组合影响，“在哪一站出闸再入闸更便宜”很难用一条简单规则概括。
因此系统必须解释断点、分段和总价。这里对应概念模型：我们不是让用户相信一个黑箱推荐，而是把真实票价模型转化成用户能理解的路线解释。
大家好，我是高胜寒，学号 2351837。我负责的是界面设计与交互落地，包括桌面端整体界面、移动端适配、路线结果表达、地图线路显示、站点选择体验、图层控制、多语言和整体可用性。
我的设计目标可以概括成三点。第一是看得懂：票价差异、站点序列、线路颜色和地图位置要互相印证。第二是用得顺：桌面端和移动端都要能完成起终点选择、路线规划和结果查看。第三是信得过：系统不能只给一个黑箱金额，而要解释为什么推荐这条路线。
这一部分对应诺曼的执行-评估循环。用户先形成“我要从哪里到哪里、想省多少钱”的目标，再通过表单、地图和图层执行操作，最后通过票价比较、路线卡片和地图高亮理解反馈，并决定是否修改偏好或重新规划。
桌面端采用左侧规划面板加右侧地图的结构。左侧承载票种、起点、终点、规划状态和路线结果；右侧展示真实地图、线路、站点、轻铁、巴士站和实时巴士。
交通路线不是纯表单任务。用户选完起点终点以后，还要判断路线在地图上的位置、经过哪些区域、换乘点是否合理。如果表单和地图分开，用户需要在输入结果和空间位置之间来回切换，认知负担会更高。
所以我把路线规划和地图放在同一个任务空间里。还有一个细节是状态区分：用户修改起点或终点后，界面会提示需要重新规划，避免把旧路线误认为新结果。这里对应格式塔接近性和主体-背景原则：规划控件成组，当前路线高亮成为复杂底图里的视觉主体。
路线结果页的目标是让用户敢按照系统推荐走。省钱路线往往不符合直觉，如果只说“推荐票价更低”，用户可能不敢相信。
因此界面同时展示最低票价、常规票价、节省金额和出入闸次数。算法结果被拆成分段卡片，每段说明线路、站点序列、直达或换乘关系，以及哪里需要出闸再入闸。地图上同步高亮起点、终点和关键断点，让用户能把文字步骤对应到真实位置。
这体现识别优于回忆：用户不需要记住复杂票价规则，也不用自己推理中间断点。界面直接列出站点序列和操作提示，把算法结果转化成可执行说明。
移动端不是简单压缩桌面端布局，而是按真实出行场景重新排序任务优先级。手机上用户经常一边走一边看屏幕，地图和方向感比完整表单更重要。
所以移动端首屏保留地图，把路线规划放到底部面板中。面板支持展开、收起和拖拽；用户想看地图时可以收起，想改路线时再拉起来。
在 390px、360px 等窄屏宽度下，我也调整了控件间距、按钮尺寸和面板高度，避免按钮、图层、语言切换和表单互相遮挡。这里对应 Fitts 定律和用户控制：高频控件放在容易触达的位置，同时允许用户决定当前优先看地图还是操作表单。
站点选择是路线规划第一步。香港站点数量很多，如果只能从完整列表滚动查找，输入成本会很高，也容易选错。
所以界面把起点和终点分区展示，减少方向混淆；站点选择支持按线路筛选，用户可以先选择港岛线、东铁线、机场快线等线路，再在较短列表里找具体车站。同时提供交换起终点、清除路线、重新规划等快速修正入口。
状态反馈方面，起终点没有选完整时，规划按钮不可用；已有路线后继续修改输入时，系统提示“尚未应用”的状态差异；同站查询、无结果和需要更新路线也用独立提示卡表达。这里对应 Hick 定律、错误预防和状态可见性：减少选择数量，在提交前暴露缺失输入，在修改后提示结果是否仍然有效。
地图信息量很大，如果把轻铁站、巴士站、实时巴士、周边探索和无障碍信息全部堆在一起，用户会被无关元素干扰。
所以地图提供图层开关。用户只想看港铁线路时，可以关闭巴士相关图层；想看接驳交通时，再打开巴士站和实时巴士。默认保留核心交通信息，更多信息通过图层渐进打开。当前路线更醒目，无关站点和线路降低视觉干扰。
包容性方面，无障碍筛选入口常驻顶部，服务需要电梯、轮椅通道等设施的用户；界面也支持繁体中文、英文和简体中文，覆盖导航、路线规划、路线结果和地图状态。这里对应渐进式披露、一致性和包容性设计：不同用户可以按自己的任务、语言和设施需求调整界面。
大家好，我是郎若谷，学号 2351871。我负责的是周边旅游推荐部分，也就是把站点周边景点与美食推荐纳入整个出行体验。
前面两个部分主要回答“怎么去”和“多少钱”。我的部分继续回答到站之后的问题：走出闸机之后，附近有什么可以吃、可以逛，哪些地方值得停留，以及怎么把这些地点串成实际步行安排。
选好路线和票价之后，用户还会关心附近有什么值得停留、哪些地方离车站近、能不能顺路走过去。这个模块的目标是让陌生站点周边的信息更好浏览、更容易筛选，也更方便落到实际步行安排上。
当前数据覆盖约 96 个车站、2500 多个兴趣点和 2100 多张本地图片。交互闭环是：浏览地点信息，按偏好筛选，在地图上确认位置，再组织步行顺序。
这里对应场景化设计。一个出行系统不应该只覆盖单个查询动作，而应该尽量覆盖完整旅程，让路线规划自然延伸到到站后的活动。
为了让推荐真实、可缓存、可溯源，我们做了一套离线数据管线。主要数据来源包括 OpenStreetMap 里的餐饮和景点位置，Wikidata 和 Wikimedia 里的图片、简介和授权信息，以及 Apify 抓取到的评分、评论数和价位等补充信号。
这些数据在构建阶段生成本地 pois.json
和图片资源。前端运行时不依赖外部地图接口，只做快速检索和展示，所以页面响应更稳定，也减少网络和配额问题。
这页的 HCI 重点是效率与可信度。效率体现在内容加载更快，可信度体现在每条推荐尽量能追溯来源，而不是只给一个没有出处的推荐列表。
周边信息如果一次性全部展开，会让用户很难扫读。所以卡片首层只放判断地点所需的核心线索：缩略图、名称、类型、距离、步行时间、评分、价位和来源。
用户点开卡片后，再看到大图、简介、营业时间、定位、电话、官网，以及收藏或加入逛吃路线等操作。这样既保持列表密度，也保留足够细节。
这里对应渐进式披露和识别优于记忆：先把做决定所需的线索放出来，更多细节留给用户按需查看。用户不需要记住站点周边有哪些地点，而是通过照片、距离、评分和标签直接识别。
一个站点周边可能有很多地点，如果全部展示，用户会出现选择过载。因此面板提供类别、排序、半径、菜系、收藏和随机推荐等工具。
用户可以先选全部、美食或景点，再按推荐、距离或评分排序；也可以调整半径和菜系，把候选范围缩小到少量可比较对象。如果筛选后没有结果，界面会给出“扩大半径”的直接出口，而不是让用户停在空页面。
这里对应用户控制和错误恢复。筛选条件由用户掌握，系统不替用户强行决定；当结果为空时，也提供明确的恢复路径，让探索可以继续。
列表和地图是双向联动的。用户点击 POI 卡片，地图会定位并高亮地点；点击地图上的标记，列表也可以回到对应卡片。半径圈、类别颜色和标记共同说明可达范围。
当用户收藏多个地点后，系统用编号点和虚线串起推荐顺序，并估算总步行时长。这样周边推荐不只是“有哪些地方”，而是进一步变成“可以怎么逛”。
这里对应系统状态可见性和空间映射：地点、范围、顺序和步行成本都保留在同一张地图里，用户不用在列表、地图和自己的记忆之间反复切换。
这一页总结周边推荐背后的设计依据。信息组织上，首层优先展示图片、名称、距离和评分等扫读线索；卡片边框、留白和标签让每个地点保持清楚边界；分类、排序和半径把大量 POI 缩小到用户真正愿意比较的范围。
状态与控制上，当前站点、地点数量、排序方式和半径持续可见；推荐、收藏、加入路线和扩大范围都由用户确认。
对应的 HCI 原则是渐进式披露、格式塔原则和 Hick 定律。我们的目标是降低认知负荷，把周边信息整理成能筛选、能比较、能出发的选择。
大家好，我是樊祺，学号 2350262。我负责的是用户关怀部分，包括无障碍设施信息、无障碍友好路线偏好、智能推荐解释与票价比较。
这部分关注的是用户差异。同一套交通系统需要考虑老人、轮椅用户、携带大件行李的游客，也需要考虑对换乘复杂度、出闸次数和节省金额敏感的普通乘客。
这里对应通用设计和包容性设计：我们希望把不同能力和不同偏好的用户放入同一套路线上下文里，而不是把无障碍需求当作附加功能。
无障碍功能第一层是地图上的无障碍高亮。截图中顶部提供“无障碍高亮”开关，并显示当前筛选条件数量。弹层会说明“只高亮地图上的车站，不会改变线路计算”，避免用户误解这个开关的作用范围。
当前条件下，系统列出 29 个符合条件的车站。用户可以先判断哪些车站具备自己需要的设施，再决定是否采用相关路线。
这里对应系统状态可见性和错误预防：筛选状态、结果数量和作用范围直接显示，用户不会误以为路线已经被强制改写。
第二层是车站设施详情。截图中的荃湾站弹窗把无障碍设施和出入口设施分组展示。
行动不便相关设施包括闸机、踏板、多用途空间等；视觉受损相关设施包括触觉图、障碍物改装和引导径等。设施逐项用勾选标记呈现，便于用户快速确认这个车站是否适合自己使用。
这里对应 WCAG 的可感知原则和识别优于回忆。无障碍信息不能藏在数据表里，也不应让用户记住每个站的条件；它应该变成可读、可检查、可比较的界面信息。
最低票价不一定等于最佳路线。有些方案可能便宜一点，但需要多次出闸、绕路或换乘，这对老人、行李较多的游客或行动不便用户来说未必合适。
所以界面把“麻烦程度”显式交给用户控制。截图里有智能路线偏好，可以选择最低票价、均衡或更快；无障碍策略可以选择关闭、优先或必须；还可以限制最多出闸次数，并设置至少节省多少钱才值得采用复杂路线。
这里对应用户控制与自由、错误预防。目标和约束由用户设定，系统再推荐路线，避免把理论上便宜但实际很麻烦的方案强推给用户。
最后是票价比较和推荐解释。截图中“你省下了 HK$47.0”直接说明收益；最低票价、推荐票价和一般票价分开展示；出入闸次数、预计耗时和价格放在同一组卡片里。
路线卡也提示用户“请按路线卡在标示车站出闸再入闸”。也就是说，推荐不是只给一个结论，而是把金额、次数、时间和操作点一起列出来，让用户判断这条推荐是否值得执行。
这里对应可解释反馈和识别优于回忆：用户可以直接核对金额、出闸次数和操作位置，而不用自己记住或推算票价规则。
以上就是我们的《港铁票价优化器与综合交通交互系统》。这个项目尝试把港铁票价优化、可解释路线、地图交互、站点周边推荐和无障碍信息整合成一个完整的出行辅助系统。
从 HCI
的角度看，我们做的不只是把数据展示出来，而是把复杂规则转化为用户能理解、能验证、能执行的界面。项目已经部署在
mtr-optimizer.shgao.top，GitHub 仓库是
Tanghui-Li/MTR-fare-optimizer。欢迎老师和同学课后访问体验。
我们的汇报到这里结束，谢谢大家。