- 九项行程字段汇总成接站依据表，按站点和两小时一档
- 预计到达与已接到差值大的时段，就是要加车的地方
- 扫码接站前端提示加后端写入校验，两层防重复
- 志愿者须老师认证才上岗，联系方式默认不公开
- 接站点地图用天地图公共服务，不自建三维校园
他此刻需要的不是服务，是别出事。
火车晚点两小时、行李太多、陪同的爸妈没进得了校门、出站口有八所学校在举牌子——这一段是全旅程里唯一一件学校完全不在场、却要被家长全程评价的事。 他在平台上已经知道的，是"报到那天学校有人接"，以及一条更管用的提醒："任何主动招呼你上车的车，都不是学校的车。"
接站是报到日唯一完全暴露在家长眼前的环节。排得顺，家长对这四年的放心程度会高一档；排得乱，后面所有环节的好感都要打折。 而它同时也是系统判断力的第一次现场检验：能不能在一个混乱的现场，把"该接的人接到、不该重复的别重复"这两件小事做稳。
27.1 九个字段，换一张接站依据表
接站的准确度高不高，取决于前面那一步：他有没有把行程填对。
系统里每个学生可以填这些东西：出行方式、出发时间、到站时刻、车次、出发区域、到达哪个站、需不需要接站、有几个人陪同，还有车牌（自驾的情形）。这九项里真正有价值的是"到站时刻"和"是否需要接站"这两项的组合——把它们按站点、按两小时一档汇总，就得到那张接站依据表：今天几点、哪个站、大概多少人。
系统里同时并列两个数：预计到达和已经接到。这两个数放在一起才有意义——差值大的时段，就是要加车的地方。
有一条边界必须自己讲：到站时刻是他填报的值，改签与晚点不会自动校正。系统里有一个"是否正点到达"的标记，靠人工勾选。所以这张表的正确用法是"按它排班，留出机动"，而不是把它当成承诺——第十九章那句"分布可算、预测在建"，在接站这一环上就是最实在的样子。
27.2 扫码接站：防重复这件事做了两层
一个人在同一个站被两所学院的志愿者各自接一次，是一件既混乱又可能出事的事——他可能因此上了不该上的车。
系统在这一处的处理是两层：前端扫到人先查一遍已有记录，命中就当场提示"已接站成功，请勿重复操作"；后端在写入前再判一次同样的条件。两层不是冗余——现场网络慢、志愿者手快、两个人同时扫同一码，只靠前端提示拦不住。
这条防重复的依据是一张帮助记录表，里面记的是：被接的新生、接的人、批次、扫描时间、接待类型，还有具体是接到哪一趟车上。这张表是接站环节最有价值的副产品：它既是一份实时的"接到了多少人"的数据源，也是事后能回答"这个人几点被谁接走"的唯一凭据。
在把学生交给一辆车之前，"是谁接走的、什么时候"这句话必须有记录可查。 这是接站环节真正的安全价值所在——不是效率高，而是出事时说得清。
权限上，接站这一条线只有三个权限码：看接站组合数据的、做扫码登记的、以及原有的出行数据管理权限。三个够用——接站不是一个需要复杂角色分工的场景，权限码开多了只会让学校在现场找不到该给谁。
27.3 志愿者：先被老师认证，才能被系统承认
接站与校园接待的主力是学生志愿者。这一处有两个很容易被忽略的设计。
第一个是认证。 志愿者不是自己报名就上岗：账号有认证时间字段，必须由一位老师确认之后才算数，认证人是谁也记下来。校园接待与接站这两类岗位都走这道手续。这一条在现场的意义非常直接——举着学校牌子的那个人，得是学校认过的人。 假学长的骗局就发生在校门口几百米的距离内，这道手续是系统能给学校的最便宜的防弹衣。
第二个是分寸。 志愿者的联系方式（手机、微信、其他社交号）是否公开，是一个独立开关。默认不公开是对的：一名志愿者在报到日之后就该回到普通学生的位置，他的号码不应该永久出现在一张能被人下载走的名单里。
岗位组织这一层的现状要说准：系统里有"迎新工作"这一类对象，带起止时间与状态，并且可以登记主负责部门；也有按岗位记的工作日志。但志愿者与学生之间的"一对一结对"不是提前排好的名单，而是扫码那一刻建立的关联记录。这意味着两件事：现场灵活性高（谁在谁接，不用等名单），事后统计"每人接了几人、哪个学院出人最多"是可行的；而事前指定"这个学生的专属志愿者是谁"不在当前版本的能力范围内——有学校确实需要这种形态，它要的是在岗位与人之间再加一层排班与分配。
27.4 找得到接站点，比派多少车更要紧
多数报到日的抱怨不是"没人接"，是**"找不到接我的人在哪"**。一个出站口有八所学校举牌，一个新生拖着两个箱子，这种混乱不需要算法解决，需要一张图。
系统里有一张面向学生的接站点地图页，把所有接站点的位置标出来让他照着走。这里有一个刻意的技术选择：地图用国家地理信息公共服务平台（天地图）的公开服务，不自建三维校园，也不采购商业地图。 迎新的场景只需要"在哪个门、怎么走"这一层，公共服务够用；而自建一套三维校园的投入，会全部花在给领导看的那一眼上，对学生的实际帮助接近于零。这一取舍和第十章"校园地点库与全景外链互补、不自建三维"是同一条判断。
同一份地点数据也服务另一个场景：工作人员手里的"预计 vs 已接"数字与这些点位对应。数据和地图是同一套，不用有人拿一张纸质表站在路口。
27.5 天气与预案：系统能配合的是"换得快"
报到日最大的变量是天气。一场雨能把整个接站与户外排队方案掀翻。
预案这件事本身是学校的组织能力，系统不能替它想。 系统能配合的是让改动的成本足够低：任务的时间窗可以调、地点可以改、站内通知当天就能发出去并且看得到谁读了、需要接站的人可以按站点与时段重新拉一张表。预案写得好不好，取决于"改一次要多久"。 如果一次临时改场地需要改七八个地方、通知三个部门、重印一批材料，那份预案在抽屉里；如果只需要在系统里改几处配置、发一条消息，预案才真的可用。
还有一处细节值得提前处理：家长。 系统里能填"陪同人数"，这个数字决定了接站点要不要留家长通道、报到现场要不要有等待区。至于家长服务信息（停车、路线、能否进校、有没有休息处），这些是学校自己在须知里写清的内容——系统能做的是让这条须知在他出发前出现在待办里、并且留下他读没读的痕，而不是替学校解释内容本身。
27.6 这一段怎么判断好坏
"报到当天早上七点，你能不能给我一张纸：今天哪个站、几点、预计多少人、需要几路车。"——这一问筛的是行程数据有没有真的进了统计。多数产品的行程数据只是存在报名表里，从未按站点与时间档汇总过。
"接过的学生再被扫一次会怎样？"——如果答案是"会有提示"，再追一句："这个提示是界面自己判断的，还是后台也判了一次？" 只在界面拦的，网络一慢就漏。
"志愿者上岗需要谁确认，系统里留下了什么？" ——这一问比想象中管用，因为它能筛出那些把志愿者当"注册用户"处理的做法。
"临时改场地，改一处要动几个地方？" ——这一问问的不是软件，是这所学校过去两年有没有真的用系统跑过一次突发。
路这一段，学校能给的最好东西不是热情，是确定性：他出站的时候知道往哪走、上车的时候知道是被学校认过的人接走的、家里人的手机号不会在名单上流传。