粘一段 JSON —— 接口返回、schema、文档样例 —— 拿一张 ER 图或类图。
从这段 JSON API 响应画一个 ER 图,把嵌套对象当作相关实体:{ "order": { "id": 123, "customer": { "id": 9, "email": "[email protected]" }, "items": [ { "productId": 55, "name": "Widget", "quantity": 2, "unitPrice": 9.99 } ], "total": 19.98 } }
Try it →从这段 JSON Schema 画一个 ER 图:{ "User": { "id": "integer", "email": "string", "posts": { "type": "array", "items": { "$ref": "Post" } } }, "Post": { "id": "integer", "title": "string", "authorId": "integer", "comments": { "type": "array", "items": { "$ref": "Comment" } } }, "Comment": { "id": "integer", "body": "string", "postId": "integer" } }
Try it →从这份 MongoDB 文档画一个 ER 图,把内嵌子文档当作从属实体,把 ObjectId 字段当作外键引用:{ "_id": "...", "customerId": "...", "shippingAddress": { "street": "...", "city": "..." }, "lineItems": [ { "sku": "...", "qty": 2 } ], "status": "paid" }
Try it →从这段 OpenAPI 组件 schema 画一个 UML 类图:UserDTO { id: integer, email: string, roles: string[] },CreateUserRequest { email: string, password: string },UserResponse 继承 UserDTO 并加 createdAt: string。标出继承和组合关系。
Try it →一个嵌套很深的接口返回,原始 JSON 放在文档里没法读。粘进来,拿生成的 ER 图替掉它。
MongoDB 这类文档数据库不强制结构,粘几份真实文档、把隐含的结构画出来,往往是记录「实际存了什么」的唯一办法。
bug 报告里附着一个巨大的 JSON,画成实体图比一层层数缩进容易理清。
先把打算返回的结构写成 JSON,画出来,后端一行代码没写就能拿到关于数据模型的反馈。
前后端要就一个返回结构达成一致的时候,一张图比在群里贴几条示例消息更像个契约。
JSON 一层两层还好读,嵌到第五层数组套对象就开始痛苦了,这时候画图有用。把原始 JSON 粘进来 —— 接口返回、JSON Schema、文档数据库的样例、OpenAPI 的组件定义 —— 拿回一张图:结构偏关系型(实体之间有隐含的外键)就画 ER 图,更像带类型的对象模型(DTO、带继承的请求和返回结构)就画类图。
它推断关系的方式跟一个有经验的后端读 JSON 差不多:嵌套对象按上下文变成内嵌实体或者外键关系,对象数组变成一对多,看着像 ID 引用的字段(userId、authorId、Mongo 的 ObjectId)即使没有显式声明也当外键处理。输入是带 $ref 的 JSON Schema 的话,这些引用直接照用,不用猜。
这是一种解读,不是 schema 校验器。真正有歧义的 JSON —— 一个嵌套对象到底是内嵌数据还是规范化之后的引用,两种设计都说得通 —— 它给一个合理的判断。你在拿这张图当正式的表结构设计文档之前,先核对一下它标的是一对多还是一对一。它最擅长的是一步把「两百行看不懂的 JSON」变成「数据长这样」。
对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。
教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。