做数字化运维 MVP 时，我最早感受到的不是页面设计压力，而是 API 边界压力。

因为这个系统不只有 Web 管理端，还要给 UE 客户端提供数据。设备信息、站点布置、全景照片、维护记录、空间位置，这些内容在后台里要能维护，在客户端里要能被正确呈现。

客户端需要的是稳定数据

UE 客户端和 Web 页面不一样。它更关注场景、设备、空间位置和交互状态。

如果后端 API 只是后台表格的直接映射，客户端会很难用。客户端需要的是更稳定、更接近场景的数据结构：某个站点有哪些区域，某个区域有哪些设备，设备对应哪些资料和维护记录，哪些全景照片能进入。

所以我会先想客户端怎么消费数据，再回头看后台怎么管理这些数据。

管理端负责把数据整理好

Web 管理端的价值，不只是让人录入。

它要帮助维护设备信息、组织站点结构、上传全景照片、管理维护记录，并保证这些数据最终能被客户端正确读取。管理端如果只追求页面简单，后面客户端就会承担太多脏数据和临时判断。

我更愿意让管理端承担整理责任，让 API 输出尽量清楚。

MVP 不代表边界可以随便

MVP 经常被理解成“先做能用”，这没有问题。但能用不等于边界可以随便。

数字化运维这种项目里，早期 API 一旦被客户端接入，后面改字段、改结构、改含义都会有成本。即使第一版很小，也要尽量把核心对象稳定下来。

设备、站点、区域、照片、记录这些概念如果一开始混在一起，后面越做越难拆。

工业场景更依赖上下文

工业和运维场景里的数据，离不开上下文。

一条设备记录如果不知道它在哪个站点、哪个区域、关联什么全景、有哪些维护记录，就很难在客户端里产生价值。后台看起来只是几张表，客户端看到的是一个空间化场景。

这也是我做这类系统时会更早考虑 API 的原因。API 不是把数据库暴露出去，而是把后台整理过的业务上下文交给客户端。

小系统也要给后续留路

这个 MVP 给我的经验是：跨端系统即使很小，也要尽早明确边界。

Web 管理端负责维护数据，API 负责输出稳定上下文，UE 客户端负责呈现场景和交互。只要这个边界清楚，第一版可以很轻；边界不清楚，第一版再快，后面也会很快开始返工。