HarmonyOS NEXT 有一个对存量应用致命的特性：不再兼容安卓——APK 装不上了，所有车间 App 都面临”重写或退出”的选择题。上一篇的 X5 壳是我们的安卓答案，这一篇是从零开始的鸿蒙答案：一个新的 ArkTS 工程，把同一个车间 App 在 NEXT 上重新长出来。
这篇的视角和前几篇不同：它是一次从 0 到 1 的完整记录——不是我接手的老系统，而是我从空目录开始建的项目。从 0 到 1 的文章最怕写成教程复读（”新建工程、写个 Hello World”），我尽量写教程不会告诉你的部分：一个 Android 老兵的世界观转换清单、五个真实的坑和各自的解法、以及从 0 开始时那些”试了又推翻”的方案痕迹——它们比最终代码更能反映工程判断。
车间 App 的第一代形态不是原生开发，而是一个”壳”：原生 Android 工程里放一个加强版 WebView，加载 MES 的 H5 页面——业务全部在 Web，壳只负责把网页够不到的原生能力（扫码、推送、PDF、拨号）以桥接口的形式递进去。这个形态常被诟病”不就是套壳吗”，但维护过它的人知道：**壳的难点不在写，在”老”**——一个 minSdk 19 时代的壳，要在 targetSdk 34 的新规下继续活着，每一轮安卓版本升级都是一场适配战役。
本篇拆这套 X5 WebView 壳（交付篇工控终端的手机版兄弟）：JSBridge 的设计、扫码的双通道降级、推送如何路由回页面、Cookie 会话的同步，以及老壳适配新系统的踩坑实录。下一篇的鸿蒙移植版会和它形成直接对照——同一套 Web、同一个桥接口约定，换一个操作系统重新长出来。
电子看板是 MES 的脸面——客户老板参观工厂时看的就是那几块大屏。但对开发团队它是个出了名难伺候的东西：每个客户要的图表不一样、每块屏挂的位置不一样、大屏浏览器没有登录态、数据量还随工厂规模线性涨。处理不好，看板就变成”十七个复制粘贴的 Controller”——本文的主角恰好就是这么开始的，所以它后来的每一步收敛都有讲头。
本篇是交付线的收尾，拆这套系统的看板体系：可配置布局怎么把 Controller 数量封顶、日预聚合表怎么扛住几十块大屏的轮询、用 MAC 地址当凭证的”无人大屏”鉴权及其代价，和 three.js 的 3D 车间监控值不值。看板不大，但它是”多租户 + 多端 + 高频轮询 + 免登录”四个难题的交集，麻雀虽小。
先纠正一个容易想当然的答案。多工序排产不是”放弃求解器、改用 CPM 算最优解”——CPM 关键路径在这台引擎里根本不排程，它只负责三件算术：算每张单的总工时、找出关键工序链、给出非关键工序的浮动时间窗。真正排程的是一套确定性贪心规则：最小松弛排序、优先级选工位、资源时间轴插空。求解器的能力被”规则定排程、CPM 供依据”整体替代了。为什么这个组合敢替代求解器？本篇拆到底。
“你们的老系统接 AI 了吗？怎么接的？”——2023 年之后，这题出现的频率逐年攀升，而且它有个隐蔽的陷阱：多数人答的是”接了大模型 API”，而面试官想听的是架构。老系统接 AI 的真正难点不在调模型，在三个工程问题：老用户的身份怎么安全地带进一个外部 AI 平台？老系统的数据怎么受控地开放给智能体查询？多租户客户的 API Key 怎么管？
本篇拆这套 SaaS MES 的 AI 智能体组件——一个跑在 2023 年前技术栈（交付篇的云主线）上的独立服务。它的全部设计可以压缩成三条红线：零 DDL（不动老库表结构）、零重启（配置与数据域热生效）、API Key 不下发浏览器。读下来的你会看到，这三条红线把”接 AI”从一个模型调用问题，变成了一个精细的边界设计问题。
“你们 MES 怎么和 ERP 集成的？”——制造系统面试的必答题。它看着是个集成问题，实际考的是两层东西：接口形态的判断（对方给什么，HTTP 开放接口、WebAPI、还是只能连数据库？）和增量同步的工程（数据怎么不丢、不重、可恢复）。前者是应变，后者是内功——而绝大多数候选人只会答”写了个定时任务同步数据”。
这一篇拆同一个平台上真实跑过的四种 ERP 适配层：用友 U8 的边缘同步引擎（脚本热改，主菜）、金蝶 K3Cloud 的表单级 WebAPI、SAP Business One 的直连数据库、以及新旧 MES 并行期的同步中间件。上一篇交付篇讲的是交付形态，本篇讲的是每种形态里都绕不开的那根刺——增量同步的同一道命门：水位线怎么设计，失败怎么办。
“你们的项目是私有化部署还是 SaaS？””同一套代码服务多个客户，分支怎么管理？”——做产品化系统的团队面试必收这两问。它们和”讲讲你的项目”不同：考的不是某个技术点，而是你对”一套代码如何变成多种生意”的理解——这是工程师视角和产品视角的分界线，答好了非常加分。
系列从本篇进入第三章·多客户交付线。前十一章把一个制造执行系统的业务、机制、数据拆了个遍（全景篇开的头），本篇拉高一层：这套底座实际交付出了三种形态——大客户私有化分支、SaaS 云主线、车间工控终端——每一种都对应一类客户和一种交付成本。本篇讲三种形态各自怎么落地、成本压在哪、以及面试里最常被追问的”分支管理”和”形态选择”。
“你在实际项目里用过什么算法？”——这题是业务开发面试的分水岭。背过动态规划的人很多，在真实生产系统里跑过约束求解器的人很少。这个系列的主线机制到此收官，最后一块硬骨头给排产（APS）：用 OptaPlanner 给注塑车间排产——几十张工单、十几台机台、几十副模具，算出一版”哪台机、哪副模、几点到几点”的预排方案，画成甘特图给排产员确认。
本篇讲四件事：排产问题的本质（一个活的 Job-Shop 调度问题）、链式建模怎么把车间现实翻译成求解器语言、三层打分与可配置权重的工程化、以及比算法本身更有面试价值的部分——为什么算出来的方案不敢直接下发，”辅助排产”的人机协同怎么设计。约束求解的教科书到处都有，车间里求解器怎么和人工编辑、在制保护、沙箱回滚共处，才是做过的人才讲得出的东西。
面试聊到物联网数据接入，常见问法是”几千台设备高频上报，怎么扛？”——但制造业 IoT 的真正难点不在量，在乱：每家设备商一套报文格式（协议碎片化），设备本身不讲武德（不发心跳、时钟乱跳、计数器回绕、65535 当真实值上报）。量的问题有一百种通用解法，乱的问题只有一种解法——在接入层之后、业务层之前，放一个又宽又厚的清洗与状态层。
本篇拆这套 MES 的 IoT 接入体系。上一篇任务篇里”设备模次聚合产量”的钩子在这篇收口——不过那笔账（两段式自动报工）已在状态机篇讲过，本篇讲的是它上游的接入侧：多协议怎么收、碎片化报文怎么翻译成标准参数、设备在不讲武德的世界里怎么维持一个可信的状态机，以及一份物联网系统特有的欠账清单。