第二十三章　还没动身：他已经研究过学校了

他此刻想要的东西非常具体：这四年住什么样的房子、和谁住、教我的老师是谁、我该准备多少钱、九月几号必须到。

他已经知道的东西比学校给他的还多。学校哪个门通向教学楼、哪几间宿舍被吐槽过、食堂哪个窗口排队短、大一大二能不能进实验室——这些他在决定填不填这张志愿表之前就已经刷过一遍。他不是空着脑袋等学校告诉他，他是带着一堆来源不定、真假混杂的结论来的。

所以这一段旅程里，学校面对的第一件事不是"通知他"，而是在他已经形成的认知里挤进一条准确的信息。学校不是信息的第一来源，最多是第三、第四来源；想被采信，就要拿出平台给不了的确凿数据。

确凿数据只有三类：与他本人绑定的、有具体名字的、有时间地点的。

23.1 用他看得下去的形态，把官方信息重做一遍

同一份"宿舍管理规定"，印在录取通知书背面的小字里没人读，做成一段两分钟的短视频他就看完了。内容没变，形态变了，到达率就变了。

系统里承载官方信息的形态有三种：公告与新闻（学校发布的正式消息，带标题、正文与图片）、新生须知类的提示（分条目呈现，读没读系统知道）、新生学习类任务（每一项可以挂视频、文档或外部链接，学生点开看完才算完成）。

这三种形态覆盖了"学校在入学前想让他知道的事"的绝大部分。真正决定效果的不在系统，在学校愿不愿意按他看得下去的方式做一次：一份 4000 字的须知，切成 8 条、每条配一张图，和原样贴上去，是两个完全不同的到达率。

有一处边界要提前说清，以免被当成卖点：这类任务记录的是"看没看完"，不是"看了多久"。 系统按完成条数计进度，没有学习时长与过程性统计。它适合用来确认"该知道的知道了"，不适合用来证明"学够了"——后者是教学系统的事，不该在迎新的入口里假装具备。

23.2 报到前就看到班级与辅导员的电话

这是入学前最有价值的一屏，也是最容易被忽略的一屏。

学生在移动端打开自己的资料页，看到的东西包括：学院、班级、联系电话，以及班主任与辅导员的姓名和电话——手机号后面还会并列显示"采集到的新号"，两处不一样时一眼就能看出名册里的号码需要更新。

这些信息在名册导入的那一刻就已经存在，只是过去要到报到当天才第一次被他知道。把它们提前到八月，效果不是"方便"，是把求助通道提前打通了：一个家里凑不齐学费的学生，在还没出发的时候就知道该打给谁，和他在宿舍楼下拦住一个不认识的老师，是两种完全不同的处理结果。

同一条记录也替学校省了最耗人的一件事——"我在哪个班、我归谁管"这类问题，本来占据了报到前一天咨询量的很大一块。它在系统里可查之后，电话就不会响。

23.3 宿舍：用官方信息盖过野生攻略，靠的是确定而不是漂亮

宿舍是入学前议论最凶的地方，也是学校最被动的一处——学生在平台上看到的宿舍内容，多数是学校没打算说的部分。

学校能拿出来的凭据不是图片有多新，而是只有它答得出来的那几问：哪一栋、哪一层、哪一间、几人间、性别配置对不对、什么时候能自己挑。这些答案系统里全有，而且从选宿开放那一刻起就是确定的。

要说清当前的样子：宿舍图片目前在楼栋这一级维护，学生在选宿页面能看到自己那栋楼的照片；房间内部的实拍、朝向、家具配置这些真正被追问的细节，尚未做成面向学生的成套内容——数据与展示位都在，素材需要学校自己拍、自己填，这块按批次补齐。

这也是学校唯一一处"要花人力才能把主动权拿回来"的地方。 系统能提供的是入口和形态，替学校说话的内容必须学校自己准备。攻略能告诉他楼新不新，只有学校能告诉他哪张床是他的。

23.4 让他自己挑两样东西：一张电话卡，一张床

报到之前，系统里有两处是明确交给他做决定的：选一个手机号，选一张床位。

选号这件事很能说明"提前办"的价值。学校与运营商有入学套餐的合作，过去的话术是"到校后在某某点办理"，结果是人挤人、当场决定、办完就后悔。系统里的做法是三步：在电信、移动、联通之间筛，挑中一到两个号码，填收件人与地址，卡寄到手，到校那天不用再排队。

这一项的边界也要说白：号码资源、套餐内容、资费与合约，全部由学校与运营商之间的协议决定，系统只负责选择与登记。 所以判断这类环节好坏的标准不在系统，在学校有没有把它做成自愿——任何"默认勾选""不选不让报到"的形态，都会把一件省事的便利变成一次投诉。系统能配合的是把它做成一项可选任务，而不是一个前置条件。

选床位这件事第十章讲过它的技术侧面（不超卖、并发保护、开学季生产验证）。放在旅程里看，它的意义完全不同：

它是学生在报到之前唯一一次"影响很大、并且立刻看到结果"的经历。

一个学生填完志愿到收到通知书之间，学校给他的全是等待；选宿开放那一刻，他第一次被允许做一个决定，并且马上知道自己抢到了还是没抢到。这一天他对这家系统的好感，取决于两件事：抢不到时是否讲得清楚为什么，抢到时能否立刻看到自己的楼栋房间。 前者靠规则公开，后者靠数据准确。

还有一层被低估的价值：选宿时间是全季最集中的一次流量。 数千人同一分钟点进去，这个环节是所有并发保护的真实考场——不是因为设计上喜欢复杂，是因为这一屏崩了，学生对整个系统的第一印象就崩了。这一点我们做过开学季的实际验证，也是这套系统最不该出问题的一处。

23.5 官方群与身份校验：治理假群靠的是可验证，不是靠声明

冒充学长的收费群、"学费先转我"的骗局，每年都有学校中招。学校的第一反应通常是发声明："我校未建任何新生群。"

声明没有用，因为骗子不需要授权。 有效的做法是反过来：给出一个可被验证的官方身份，让学生拿它去比对。

系统在这一环能提供的是身份底座，不是群本身：每一个新生有唯一账号与可出示的二维码（内容就是学号，工作人员扫码即可确认"这确实是本校今年的一位新生"）；账号身份类型里包含家长，走读申请这类需要家庭决定的事项可以落到具体的人身上；志愿者与工作人员各有自己的权限码，谁替他办了事都会留下记录。

群在第三方平台上，那是学校要做的组织安排：谁建、几个人管、进群先核对什么。 系统能做的是让"我是这个学校今年的新生/老师/志愿者"这句话随时能被核对。同时有两条纪律必须写进学校的群规，而它们和系统无关：任何收费都不在群里发生（缴费一律走系统内的正规通道，这条在第二十六章会具体讲），任何人的名字都不能只以"学长"身份出现而不留可追溯的归属。

23.6 学长答疑：把高频问题沉淀成资产，而不靠热心同学

往年被问得最多的问题，通常是同一批：能不能带电磁锅、转专业难不难、军训多久、贷款什么时候到账。它们的共同点是：去年答过，今年又要重答一遍；而回答的人往往不是最清楚的人。

第二十一章讲过沉淀，落到学生这一端，它长这样：把高频问题变成一组可检索的、带采纳标记的官方回答。谁问的、谁答的、答得被不被认可，都应该有位置，而不是存在某个热心同学的微信记录里。

现状要准确：问答的后台与数据接口已经建好，问答内容支持浏览量与"已采纳"标记；移动端的学生界面目前还没有接上它。 也就是说，这一块是"数据与接口已备，呈现按批次补齐"的状态。内容整理这件事本来也不该厂商代劳——一所学校真正被问什么，只有它自己知道。

至于"让学长来答"，这是组织设计不是软件功能。系统能配合的是：给答疑的人一个可辨识的身份、给被采纳的答案一个记号、把没人答的问题留成待办。榜样这件事没法开发，只能被安排。

23.7 平台上的学校与真实的学校：差距要在入学前弥合

录取那几天，学校的形象被两样东西决定：官方网页，和平台上素不相识的人说的话。前者通常被认真维护，后者通常被夸大。

一个学生入学后的满意度，很大程度取决于真实体验与他带来的预期之间的差，而不是体验本身。 这个差只能在他来之前弥合，因为来之后他已经用脚投票了。弥合的办法也不是把官方网页做漂亮，而是把三件事提前讲明白：

他住哪儿——楼栋、房间、几人间、什么时候可以自己选；谁管他——学院、班级、班主任与辅导员的联系方式；他要做什么、什么时候必须做完——任务清单带起止时间，到点没办完会怎样，规则写在脸上而不是靠人去催。

这三件全部是系统里现成的数据，把它们提前释放给学生，几乎不需要额外开发——需要的是学校愿意在他还没来的时候，就按一个"未来学生"的身份给他开一屏。

反过来说，这也是最省事的一次口碑投入：报到之后再补救，成本是投诉、约谈和一次全校范围的解释。