从一句需求到数据模型，AI 项目生成中间发生了什么

聊天只是入口

用户通常会用自然语言表达：

我想做一个客户线索管理后台，销售能记录跟进，主管能看统计。

这句话对人来说能懂，但对项目生成来说还不够。系统需要继续拆出角色、页面、流程和数据对象。

结构化需求是什么

一个适合生成项目的需求，通常包含：

• description：项目描述

• features：功能列表

• pages：页面清单

• userRoles：用户角色

• coreFlows：核心流程

• technicalRequirements：技术要求

• constraints：约束条件

• externalApiRequirements：外部接口需求

这些内容能让前端、后端和数据库围绕同一个目标生成。

数据模型是项目的骨架

以客户线索管理为例，可能需要：

• 用户

• 角色

• 客户线索

• 客户标签

• 跟进记录

• 回访提醒

• 合同

• 统计快照

如果数据模型缺了“跟进记录”，页面上即使有跟进按钮，也没有地方保存历史。很多项目不好用，就是因为前期没有把数据对象设计清楚。

技术栈影响模型表达

不同技术栈会用不同方式表达数据结构：

• Prisma schema

• SQL 建表语句

• JPA 实体

• MyBatis 映射

• Django ORM

• SQLAlchemy 模型

形式不同，但目标一样：让业务对象能被后端接口和前端页面共同使用。

需求到数据模型的转换示例

原始需求：

做一个课程报名系统，学生可以报名课程，老师可以查看报名名单，管理员可以维护课程。

可以先提取角色：

• 学生

• 老师

• 管理员

再提取业务对象：

• 用户

• 课程

• 报名记录

• 课程分类

• 上课时间

• 通知公告

然后确定关系：

• 一个学生可以报名多个课程。

• 一个课程可以有多个报名记录。

• 一个老师可以负责多个课程。

• 管理员可以维护课程分类。

最后再落到页面：

• 学生课程列表

• 学生我的报名

• 老师报名名单

• 管理员课程管理

• 管理员分类管理

这就是从一句需求到项目结构的过程。

不要跳过状态字段

很多业务对象都需要状态字段。比如：

• 报名记录：待确认、已通过、已取消。

• 订单：待处理、已完成、已关闭。

• 工单：待分配、处理中、已完成、已评价。

• 商品：待审核、已上架、已下架、已拒绝。

状态字段决定流程能不能走通。没有状态，系统往往只能做静态 CRUD。

数据模型也要考虑页面查询

字段设计不是只为了存数据，还要支持页面查询。例如客户线索列表如果要按来源、标签、跟进人、状态、时间筛选，这些字段就必须在模型里存在。

生成前可以问自己：

• 列表页要按什么搜索？

• 管理员要按什么筛选？

• 统计页要按什么分组？

• 哪些字段需要排序？

• 哪些字段只做展示，不参与查询？

这些问题能让模型更贴近真实使用。

复杂关系先简化

初版项目不一定要设计特别复杂的关系。比如权限系统可以先做角色级权限，不必一开始就做到按钮级、字段级、数据范围级。外包或毕设项目都应该先保证核心流程可运行，再逐步增强模型。

数据模型反过来检查需求

当你列出数据模型后，可以反过来检查需求是否合理：

• 每个页面有没有对应数据来源？

• 每个表有没有被页面或流程使用？

• 每个状态有没有触发它变化的操作？

• 每个角色有没有自己的数据范围？

• 每个统计指标有没有可计算字段？

如果某张表没有任何页面使用，可能是过度设计。如果某个页面没有数据来源，可能是需求漏了模型。

让字段服务业务语言

字段命名不只是技术问题，也影响理解。比如客户管理里，与其写一堆含糊字段，不如明确：

• source：客户来源

• ownerId：负责人

• nextFollowUpAt：下次回访时间

• dealAmount：成交金额

• status：跟进状态

这些字段一看就能对应业务动作。论文、文档和客户沟通也会更顺。

数据模型不是越复杂越好

很多新手喜欢一开始设计几十张表。实际上，如果你无法说明每张表服务哪个流程，它就可能是负担。AI 生成也一样，模型越复杂，页面、接口和测试都越复杂。

初版先保证核心对象和关系清楚，再通过继续修改增加扩展对象，是更稳的做法。

小结

AI 项目生成的关键不是“聊天直接变代码”，而是“聊天变结构化需求，结构化需求变数据模型，数据模型再驱动页面和接口”。理解这一点，你会更容易写出高质量需求。