元数据驱动开发

在实践中

这个想法并不新，装作它很新是最快被误读的方式。企业级平台从 2000 年代中期就开始用「声明而非代码」来描述应用，今天这套词汇正是从那条脉络来的：用对象而不是表，用权限集而不是鉴权中间件，用流程而不是定时脚本。那一代人立住的东西值得保留——在定义里加一个字段，API、列表视图、详情表单、导出和权限模型会同时出现它，因为这些都是从同一条声明推导出来的，而不是靠人手工保持一致。

真正变了的，是谁在写这份声明。当声明由人在可视化控制台里点出来时，收益是速度和一致性，格式本身可以是一种没人直接阅读的私有 XML 方言。当声明由 AI Agent 编写时，格式本身就变成了决定产出可不可信的约束：一个完整业务应用用元数据表达是几千行而不是几十万行，Agent 可以在一个上下文窗口里装下整个系统，而不是对着一个看不到边界的代码库抽样阅读；而审阅这次改动的人读到的是一份声明的 diff——哪个字段动了、哪条权限变了、哪一步现在需要审批——而不是去审计生成出来的控制器、模板、迁移脚本和测试。

这个词一旦裸着说出来，就会塌回低代码的那种读法，并且直接输掉论证，所以差别值得说清楚。拖拽式搭建器优化的是「不想写代码的人」；这里说的元数据驱动开发优化的是「不是我写的、但要我签字的审阅者」。这两件事会长出不同的格式。前者可以把定义藏在界面背后，因为界面就是入口。后者不行：定义必须是一份可读、进版本库、能 diff 的文件——因为 diff 就是审阅面，而写它的是 Agent，不是一张表单。

它并不适合所有工作，说明这一点不是自谦。本质是算法的问题——定价优化、路径规划、解析器——不会因为被「声明」出来就变小或变安全；它们该被写成代码，然后由定义去调用。这套方法诚实的失败形态是表达力天花板：当声明面表达不了某个需求时，团队就会去找逃生舱口，而逃生舱口的代码一多，系统就退回原点——逻辑落在了运行时管不到、审阅者也看不见的地方。