低代码平台最常见的失败，不是功能不够，而是模型改不动。系统上线半年后，一个字段的类型调整会牵动报表、权限、集成与历史数据四条链路，最终演变为「只能新增、不能修正」的僵化结构。
我们在 2023 到 2025 年间做过三次建模尝试：扁平表结构、带继承的对象树、以及图式的关系模型。三者都在同一个问题上失效——它们把「结构」与「实例」放在同一个可变空间里。
四段式定义
最终方案把定义拆成四段：Base（标识与归属）、Schema（字段与约束）、Values（实例数据）、Grants（权限边界）。四段各有独立的版本序列与变更策略。Schema 的变更只产生新版本，不修改历史；Values 永远指向它写入时的 Schema 版本。
这样做的代价是读取路径变长：一次对象读取需要解析 Base → Schema 版本 → Values。我们用快照缓存把这段开销压到常数级，实测 P99 增加 1.8 毫秒。收益是结构演进不再需要数据迁移——旧数据保持旧版本解释，新数据按新版本写入，系统在时间维度上自然分层。
契约的三条纪律
第一，删除字段只做逻辑删除，且在两个主版本内保持可解析；第二，字段语义变更必须新建字段，不允许复用旧标识；第三，任何跨对象的引用都必须带版本锚点，禁止「总是解析到最新」。
这三条纪律读起来保守，但它们让「结构可演进」从口号变成了可验证的性质：任意两个版本之间，历史数据的解释结果恒定。