数据模型先行

实体和关系定错了，界面怎么改都别扭。

实体和关系定错了，界面怎么改都别扭。界面改一次是几分钟，数据模型改一次是把已有数据也一起迁走。这是整条链路上返工最贵的一环。

你会遇到的现象：

• 某个信息在两个页面显示得不一致，因为它存了两份
• 想加个筛选，发现这个字段当初是拼在一个文本里的
• 界面怎么调都别扭，改了半天发现是数据关系不对

让 AI 直接做页面，它会顺着界面推数据：页面上要显示客户名，那就在项目表里加一个客户名字段。单页看没问题，等到有第二个页面也要用客户信息，数据就开始分叉。所以数据模型要你自己先定，而不是交给 AI 顺手填。

怎么定

先列一份内容清单和场景描述，然后按四步走：

第三步是关键。多对多的关系需要一张中间表，比如一个项目对多个客户、一个客户对多个项目，就得有第三张表记录「哪个项目对哪个客户」。这件事定得越晚，改起来越麻烦，因为牵动的是已经落库的数据。er-wiki

一对一最简单，通常用外键就能表达；一对多要把「多」的那一端放进子表；多对多才需要中间表。判断关系时从业务出发，而不是从界面出发——界面上一个输入框对应的数据，底层可能是两张表的关系。

判断标准就是第二步那句「能被单独增删改」。客户能独立添加、修改、删除，它就该是实体，而不是项目表里的一个字段。顺着界面推数据，就是在这一步犯错：页面要显示客户名，于是客户名变成项目表的一个字段；等到第二个页面也要用客户名，就只能再存一份。先抽出「客户」实体，项目表只存客户 ID，两个页面引用同一处，改一处处处生效。

定错了的信号

• **同一个东西存了多份。**改一处要同步改几处，迟早会漏。这是最典型的信号。
• **字段里塞了结构化的内容。**把「张明 138xxxx」存进一个字符串，等要按电话搜索时就得重新拆。
• **某个表有一堆用不上的空字段。**说明当初把两类不同的东西硬塞进了一张表。
• **删一条数据会牵连出一堆问题。**关系没定清楚，删了客户之后项目变成孤儿。

软删除在这里值得单独说一句：给表加一个删除标记，而不是真的删掉。用户误删能恢复，关联数据也不会突然断掉。它成本低，却能把「删除」从事故变成日常操作。

给 AI 的话

把这段写进项目文档，每次让 AI 定数据结构前都带上它：

基于下面这份内容清单和使用场景，先设计数据模型，不要写界面。

内容清单：[粘贴清单]
场景：[谁、在什么时候、做什么]

请输出：
1. 实体列表。每个实体的字段、类型、是否必填、默认值。
2. 实体之间的关系，标明一对一、一对多还是多对多。
   多对多请明确指出需要中间表。
3. 逐条检查有没有重复存储：同一个信息是否出现在多个实体里。
   有的话说明为什么，或者建议怎么抽出来。
4. 列出你不确定的地方，比如某个字段该属于哪个实体、
   某个关系的多少端。逐条问我，不要自己决定。
5. 哪些字段将来可能需要被搜索或筛选，据此说明为什么
   不能把它们塞进一个大文本字段里。

另外：所有实体都加 created_at 和软删除标记。
我确认之后再写代码。

第五条是提前防坑。AI 为了让界面好写，很容易把几个信息拼成一个字段，等你要做筛选时才发现拆不开。让它在动手前自己论证一遍，比写完之后返工便宜得多。