用对话的方式写代码：Modelith 让 Domain Model 活起来

说实话，很多项目一开始都是奔着好好干去的。有人兴致勃勃地在白板上画出 Domain Model，大家点头表示认可，然后……然后它就默默死在某个没人更新的文档里，等着被遗忘。

问题不在于 Domain Model 这个概念本身。问题在于，传统的 Domain Model 通常是：

• 写完一次就不再碰
• 和代码分开维护
• 只有特定工具才能看
• 很难自动校验

Modelith 换了个思路。它不把 Domain Model 当成「交付物」，写完就归档。它把 Domain Model 当成活的产物——跟代码放一起，用对话来写，靠 CI 自动校验。

到底啥是 Domain Model？

先统一一下认识。Domain Model 就是你系统的「概念地图」——有哪些核心实体（名词），实体之间什么关系，有什么业务规则。不是数据库表结构，也不是 API 文档。就是用大白话说清楚「你这系统到底是干嘛的」。

可以把它想象成团队共享的词汇表。大家看同一份模型，开会的时候说的都是同一个意思。新人来了也能快速上手，不用在那扒拉一堆老代码搞考古。

Modelith 的工作流：描述、草拟、校验、生成

重点来了。用 Modelith，你不用直接写 YAML，也不用惦记 YAML 语法。你就用自己的话跟 AI 助手（一个 Claude Code 插件）描述你的领域概念，它帮你把 YAML 草稿写出来。

大概是这样：

1. 描述 — 用大白话聊你的领域。「我们有客户，客户可以下单，订单里包含多个商品，但一个客户同时最多只能有 3 个进行中的订单。」

2. 生成 — Claude Code 插件把你的描述转成 modelith.yaml，边写边校验。

3. 校验 — 跑一下 modelith lint，检查完整性、一致性。这个可以直接当 CI 门禁用。

4. 生成文档 — 跑一下 modelith render，输出带 Mermaid 图的 Markdown。跟 YAML 一起提交到仓库。

生成的 Markdown 不用装任何工具就能看。YAML 是机器可读的源文件。CI 负责确保两者不会脱节——就像代码生成检查一样，只不过检查的是你的 Domain Model。

这样做为啥有效？

大白话降低了门槛

不是团队里每个人都看得懂 JSON Schema 或者 UML 图。但人人都能读懂大白话。Modelith 把大白话当成入口，Domain Model 就变得民主化了。产品经理可以参与，QA 可以 review，初级开发也能看懂整体架构。

AI 干了那些繁琐的活

手写 YAML 既容易出错又无聊。把「描述」翻译成「合规 YAML」这事儿交给 AI，你省心，精度还有保障。

CI 校验防止脱节

这是给团队用的杀手锏。Domain Model 成了开发流程里的一等公民。每个改 Domain 的 PR 都会自动校验。有人改了 YAML 但忘了重新生成文档？CI 直接拦住。

模型和代码待在一起

Domain Model 跟代码放在同一个仓库里，它就一直是新鲜的。会在 PR 里被 review，需求变了会顺手更新。不会变成某个不知道密码的文档系统里的陈年旧账。

怎么上手？

Modelith 设计得很友好。你不需要一开始就搞懂整个 schema，从小处着手就行：

• 装上 Claude Code 插件
• 用大白话描述几个核心概念
• 让 AI 生成 YAML
• 跑 modelith lint 看看缺了什么
• 迭代改进

项目里有一些实战例子（停车场那个例子挺适合入门），手把手教你从零搭一个真实的模型。

更大的图景

Modelith 反映了一个更宏观的趋势：AI 辅助开发正在用自然语言当交互层，底下保留机器可读的产物。你写你想说的，工具保证一致性和校验。

对于做复杂系统的团队来说——尤其是那些领域词汇至关重要的场景（金融、医疗、物流、一切规则一堆的系统）——这个思路可能挺颠覆的。一份大家共享的、经过校验的、活着的 Domain Model，意味着更少的误解、更快的上手、更合理的系统设计。

工具还在进化，但核心思路很扎实。你的 Domain Model 不应该是项目启动时随便写写的附件，也不应该是被遗忘的老古董。它应该是跟代码一起成长的活文档，用对话来写，靠 CI 来校验。

如果你也苦于 Domain Model 在项目里总是沦为摆设，Modelith 值得试试。有时候最好的工具不是功能最强大的那个，而是让「做对的事」变成「最容易的事」的那个。

想上手？去 modelith.sh 看看。