班车与班组排班

挑战

保洁班组、班车车队、快递路线，这些小型服务运营商的第二天排班，往往靠一个微信群加一张打印出来的表格在运转。班次一改，调度员往群里发条消息，谁翻得够远谁才知道。谁接了哪一班没有任何记录，到了周末，工时全凭回忆拼凑。

这些班组都是双语的，而且多以中文为主。市面上卖给这个市场的排班工具却清一色英文优先，默认用户坐在办公桌前、连着稳定的 Wi-Fi。可停车场里的司机、地下服务通道里的保洁，偏偏在排班最要紧的那一刻没有信号。缺的不是功能，是语言和网络。

我们做了什么

这是观白工作室自己的产品，仍在开发中。没有客户委托，也还没有对外上线。我们做它，是因为官网背后那套共享后端需要第二个真正不同的客户端来验证：它得是移动端，得扛得住离线，得和浏览器完全不是一回事。

React Native 跑在 Expo 上，一套代码同时交付 iOS 和 Android。它对接的是与官网相同的 FastAPI 服务和同一个 PostgreSQL 数据库：同一套会话鉴权，同一个健康检查，同一条部署链路。没有第二套后端，也没有重复的用户模型。

• 任务列表先由本地存储渲染，信号恢复后再与服务端对账。打开今天的活儿，永远不用等网络。
• 换班一键发起、一键接受，接受的动作会实实在在写入一条记录。交接不再是一条可能被刷过去的聊天消息。
• 管理端可以看到今天、明天，以及每一个还没人接的空班。
• 中英文装在同一个构建里，从第一屏就都在。语言是数据上的一个字段，而不是收尾时再补一遍的翻译工序。

结果

开发仍在进行，所以这里的数字是约束这次开发的目标，而不是我们宣称的成果。

四个接口原封不动地从官网 API 沿用过来。两个平台出自同一套代码。任务列表在零网络请求的前提下打开——这是一条塑造本地数据层的硬约束，而不是事后加上去的功能。

真正有价值的产出在架构层面。让一个移动端去对接同一份接口契约，逼着这份契约不再默认对面是浏览器。我们接下来承接的任何 app 项目，起点都会是一套已经服务过两类差异极大的调用方的 API。