织信开发日志 13：从项目管理系统看低代码里的数据模型设计

前两篇我用 AI 智能体生成了一个项目管理系统。

这一篇继续拆它的数据模型。

低代码平台最容易被低估的地方，不是表单怎么画，而是业务对象怎么拆、对象之间怎么关联。

模型一旦错了，页面、权限、流程、自动化、统计都会跟着别扭。

AI 先拆出了 5 张表

这个项目管理系统里，AI 生成了 5 张核心表：

• 项目表；
• 任务表；
• 里程碑表；
• 工时记录表；
• 项目风险表。

这个拆法是对的。

项目是主对象，任务、里程碑、工时、风险都是围绕项目产生的业务记录。

如果把这些内容都塞进一张项目表，短期看起来简单，后面一定会乱。

因为一个项目会有多条任务、多条风险、多条工时记录。

一张表很难同时表达“一个项目”和“项目下面的多条明细”。

先确定主对象

设计数据模型时，我会先问：这套系统的主对象是什么？

在项目管理系统里，主对象就是项目。

所以项目表必须先把项目本身描述清楚：

• 项目编号；
• 项目名称；
• 项目状态；
• 项目经理；
• 项目优先级；
• 开始日期；
• 计划截止日期；
• 实际完成日期；
• 项目进度；
• 项目描述。

这些字段不是为了让表单看起来完整。

项目编号用于识别，项目状态用于流转，项目经理用于责任归属，截止日期用于延期判断，项目进度用于统计。

字段一旦进入模型，就会成为后面页面、筛选、统计和自动化的依据。

明细对象要独立成表

任务不能只是项目表里的几个字段。

真实项目会拆成需求、设计、开发、测试、上线，每个任务都有自己的负责人、状态、优先级和截止时间。

所以任务必须独立成表。

任务表独立以后，项目和任务之间就是一对多关系：

• 一个项目有多条任务；
• 一条任务归属一个项目；
• 项目可以下钻查看任务；
• 项目进度可以由任务完成情况汇总；
• “我的任务”也可以从任务表里筛出来。

里程碑也一样。

它不是任务的别名。

任务关注“要做什么”，里程碑关注“阶段是否达成”。

把任务和里程碑分开，项目总览才能同时回答两个问题：现在还有哪些事没做完，项目已经走到哪个阶段。

工时是流水数据

工时记录不能塞进任务表。

一个任务可能会被多人、多天、多次填写工时。

所以工时天然是流水型数据，应该独立成表。

一条工时记录至少要知道：

• 属于哪个项目；
• 属于哪个任务；
• 谁填写；
• 哪一天填写；
• 投入多少小时；
• 做了什么内容。

现在工时统计页面是空的，原因很直接：还没有工时记录。

这不是页面坏了。

它说明看板不是画出来的，统计是从数据模型里长出来的。

如果工时没有独立成表，后面就很难按项目、任务、人员、日期去统计。

风险也要结构化

风险不是项目备注。

风险应该有自己的状态、等级、负责人和关闭过程。

一条风险记录至少要包含：

• 风险标题；
• 风险等级；
• 风险状态；
• 风险负责人；
• 应对措施；
• 发现日期；
• 关闭日期。

风险独立成表以后，项目总览才能统计未关闭风险、高风险数量、风险等级分布。

如果风险只是项目表里的一个文本字段，最多只能写一句备注。

它无法分配、跟踪、关闭，也很难进入统计。

关系字段决定系统能不能长大

低代码平台里，关系字段不是装饰。

项目和任务是一对多。

项目和里程碑是一对多。

项目和风险是一对多。

任务和工时也是一对多。

工时还要能回到项目上。

这些关系建清楚以后，AI 才能继续理解应用。

用户说“把项目进度改成由任务完成率自动计算”，AI 才知道要查任务表。

用户说“统计每个成员本周投入工时”，AI 才知道要从工时记录按人员和日期汇总。

用户说“找出延期项目”，AI 才能同时看项目截止日期和任务完成情况。

所以数据模型不是静态配置。

它是 AI 后续理解应用的地图。

我的判断

AI 很适合生成第一版数据模型。

它能快速把“项目管理系统”拆成项目、任务、里程碑、工时、风险这些对象。

但人仍然要判断：

• 哪个对象是主表；
• 哪些对象要独立成表；
• 哪些字段会参与统计；
• 哪些关系是一对多；
• 哪些数据会进入流程和自动化。

AI 可以继续执行配置，但业务边界要人来确认。

低代码平台的数据模型设计，不能只看表单。

表单只是入口。

真正决定系统质量的是对象拆分、字段语义和关系结构。

这个问题想清楚，低代码才不是“拖表单”。

它才真正开始变成企业数字化系统。