自研框架有一个很少被提起的隐性成本：它会让 IDE 失明。框架用字符串约定连接世界——Feign 接口里的 URL 和 Controller 方法之间、页面里的多语言 key 和资源文件之间、Mapper 接口和 XML 之间——约定对框架是优雅，对 IDE 是普通字符串：Ctrl+点击无效、改名不联动、引用查找失明。团队每天为这些断链付的时间税，累积起来是天文数字，但因为它是一次一分钟，从来没人立项去修。
我修了：给自研框架写了一个 IDEA 插件，把这些断链全部接通——框架篇讲过的那套”约定优于配置”，在这里补上了它的 IDE 侧半环。本篇讲断链清单怎么盘点、PSI（IDEA 的代码模型）怎么用、两个最有含金量的实现（多语言 key 折叠成中文、URL 引用导航），以及四十四个版本迭代的插件是怎么发布和维护的。工具链线的第一篇（PowerShell 引擎）管进程，这一篇管开发者的编辑器。
微服务架构的本地开发成本，是一笔经常被架构文章漏记的账：二十来个服务，每天早上要按依赖顺序起一遍，起完逐个看日志确认活着，下班可能还要停——每人每天十五分钟，一个团队一年就是几百小时，而且每次新同事入职都要背一遍”哪个先起、哪个要加什么参数”。
本篇拆我自己写的解法：一份 PowerShell 引擎（单文件一千八百多行），一条命令管四个同架构项目的全部微服务——按模块起停、健康检查、状态总览、日志追踪，再配一个 Java Agent 给自研框架做模型热重载。这一篇不讲微服务架构，讲的是工程效能的账怎么算、零配置怎么实现、以及 Windows 上跑 Java 开发环境的一整面坑墙。它和已发布的 Java Agent 模型热重载是姊妹篇——那篇讲 Agent 的类加载原理，这篇讲引擎本体的设计。
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 云主线、车间工控终端——每一种都对应一类客户和一种交付成本。本篇讲三种形态各自怎么落地、成本压在哪、以及面试里最常被追问的”分支管理”和”形态选择”。