把需求转成数据模型
实体、关系、状态机，以及将来一定会改的字段
把这个需求转成数据模型，先不写代码。输出：1）实体清单，每个实体一句话说明它代表现实中的什么；2）实体间关系与基数，指出哪些是多对多、需要中间表；3）核心对象的状态机（状态、触发条件、不可逆的转换）；4）哪些字段现在看着够用、但半年内大概率要改（价格、权限、多语言、软删除）；5）三处需求里没写清楚、必须先问产品的地方。 [粘贴需求]
使用建议
第 5 条那几个问题直接拿去问产品，比自己猜着建模省事得多。
适合什么场景
- 需求评审刚通过，要在排期前估出表结构和改动范围。
- 要判断这个功能是「加字段」还是「加实体」，避免上线两个月后拆表。
不适合的场景
- 需求还停在「大概做个会员体系」：先问清角色和流程，现在建的模型都是空的。
- 只是一次性报表或导出：临时表或视图就够，不必建长期模型。
示例
输入
需求：用户可以预约线下门店的服务。一个预约包含 1–3 个服务项目，可指定技师。 提前 24 小时可免费取消，之后取消扣 30%。 门店可临时停业，停业期间已有预约要自动取消并退款。
你会得到
给出 user、store、service_item、technician、booking、booking_item、payment/refund 七个实体；指出 booking 与 service_item 是多对多、需要 booking_item 中间表并保存价格快照与技师；把 24 小时取消边界和退款比例写成待定→已确认→已完成/用户取消/门店取消的状态转换条件，并标出取消不可逆。最后列出会变的字段：价格（快照）、取消政策（按门店/活动变）、时区。
常见误用
- 只贴一句需求就让它出 DDL：它会补全你没说的规则，且不标注哪些是假设。
- 把字段清单直接当最终 schema，跳过「谁写入、谁读、谁会改」的确认。
可以这样改
- 加「把每条假设单独列出来，我去和产品确认」，输出从模型变成待确认清单。
- 加「如果半年后要支持连锁多门店和跨店技师」，能提前暴露实体边界问题。