用 WorkBuddy 梳理复杂系统数据关系：样本、宠物、检测项目、试剂和报告怎么连起来

关于我：

我是连续创业者峰哥，长期关注 AI Agent 与高效办公。

希望我的文字，能帮助更多普通职场人从“会用 AI”走向“会管理 AI”，把重复工作交给数字员工，把时间留给真正重要的事。

今天继续聊一个真实项目里特别容易被低估的问题：

复杂业务系统的数据关系，到底应该怎么梳理？

我最近整理的宠物医院检验系统里，有一组对象非常关键：

宠物主人。

宠物。

样本。

检测项目。

试剂。

检测结果。

报告。

这些词单独看都不难。

但真正做系统时，难点不是知道它们叫什么，而是知道它们怎么连起来。

一个宠物主人可以有几只宠物？

一只宠物可以有多少次样本？

一个样本可以做几个检测项目？

一个检测项目和试剂是什么关系？

设备返回的检测结果落在哪个对象上？

报告到底是围绕样本生成，还是围绕检测任务生成？

这些问题如果不先理清楚，系统后面很容易变成：

页面能点。

数据能录。

但结果对不上。

报告生成不了。

异常也查不清。

所以这篇文章想讲一个很具体的方法：

用 WorkBuddy 先把复杂系统里的业务对象和数据关系梳理出来，再进入表结构、接口和页面设计。

复杂系统最怕的不是表多，而是关系乱

很多人看到复杂系统，第一反应是：

表好多。

字段好多。

页面好多。

接口好多。

但真实项目里，表多不一定可怕。

真正可怕的是关系乱。

比如宠物医院检验系统里，如果你没有先搞清楚“宠物主人”和“宠物”的关系，就可能把主人信息重复写到每一次样本里。

如果你没有搞清楚“样本”和“检测项目”的关系，就可能不知道一个样本到底能不能对应多个检测项目。

如果你没有搞清楚“检测项目”和“试剂”的关系，就可能后面做试剂配置时到处补字段。

如果你没有搞清楚“检测结果”和“报告”的关系，就可能报告生成逻辑越写越乱。

这类问题一开始不明显。

因为页面看起来能用。

列表能查。

表单能保存。

数据也能入库。

但一到真实流程，问题就出来了。

样本重复。

项目漏选。

结果找不到对应报告。

报告里引用了错误的宠物信息。

设备上传的数据不知道该落在哪条记录上。

所以复杂系统的第一轮设计，不应该只问：

我要建哪些表？

而应该先问：

这个系统里有哪些核心业务对象？ 它们之间是什么关系？ 每个对象在流程中什么时候创建、什么时候变化、什么时候被引用？

这才是数据关系梳理的起点。

先把对象列出来，不急着画数据库表

我会先让 WorkBuddy 做一件很朴素的事：

把系统里的核心业务对象列出来。

不是字段。

不是表。

不是页面。

而是业务对象。

在宠物医院检验系统里，第一批核心对象大概是这些：

• 宠物主人；
• 宠物；
• 样本；
• 检测项目；
• 检测任务；
• 试剂；
• 设备；
• 检测结果；
• 报告模板；
• 检测报告；
• 机构；
• 用户。

这一步看起来简单，但非常重要。

因为一旦你用“对象”而不是“表”来思考，系统就会从技术视角回到业务视角。

比如“宠物主人”不是一张表。

它代表的是谁为宠物负责、谁能接收报告、谁和医院发生业务关系。

“样本”也不是一张表。

它代表的是一次检测流程里的核心载体。

“报告”也不是一个 PDF 文件。

它代表的是检测结果经过整理后交付给医生或客户的业务结果。

所以第一步不是立刻问表怎么建。

而是问：

这个对象在真实业务中代表什么？

谁创建它？

它关联谁？

它什么时候变化？

它最终服务于什么结果？

再画关系，不要让对象孤立存在

对象列出来以后，下一步是画关系。

这一步最容易暴露系统设计问题。

比如宠物医院检验系统里，至少要回答这些关系：

一个宠物主人，可以关联多只宠物。

一只宠物，可以产生多次样本。

一个样本，可以关联一个或多个检测项目。

一个检测项目，可能对应一种或多种试剂配置。

一个样本或检测任务，可以产生多条检测结果。

一份报告，需要引用样本、宠物、主人、检测结果和报告模板。

一个机构，需要隔离自己的样本、设备、用户和报告。

这些关系如果不说清楚，后面写代码时会不断遇到选择题。

报告表里要不要存宠物名字？

样本表里要不要存主人电话？

检测结果是挂在样本下面，还是挂在任务下面？

试剂配置是挂检测项目，还是挂设备型号？

机构权限是每张业务表都带机构 ID，还是通过用户上下文过滤？

这些选择不是纯技术问题。

它们背后都是业务关系问题。

WorkBuddy 在这里能做的事，是帮我们把“散落在代码和表里的线索”整理出来。

比如让它读：

• 数据库脚本；
• 实体类；
• Mapper XML；
• 前端 API；
• 页面字段；
• 菜单模块；
• 字典配置。

然后输出：

• 业务对象清单；
• 对象之间的关系；
• 一对一、一对多、多对多关系；
• 哪些关系已经能从代码确认；
• 哪些关系只是根据命名推测；
• 哪些问题必须找业务确认。

这里最关键的不是让 AI 给一个“看起来很完整”的结论。

而是让它明确标注：

哪些是确定的。

哪些是推测的。

哪些是待确认的。

这一步做好，后面就不会把猜测当事实。

数据关系要服务于业务流程

很多系统设计会犯一个错误：

对象关系画得很漂亮，但和业务流程脱节。

比如你把宠物、主人、样本、项目、结果、报告都画出来了。

但没有回答：

这些对象在流程里什么时候出现？

它们是谁创建的？

它们怎么进入下一步？

它们的状态怎么变化？

那这张图仍然不够用。

宠物医院检验系统里，数据关系必须服务于这条流程：

宠物到院 - 登记主人和宠物 - 创建样本 - 选择检测项目 - 关联试剂和设备 - 产生检测数据 - 确认检测结果 - 生成报告 - 查看报告

也就是说，对象关系不是静态的。

它要进入流程。

比如“宠物主人”和“宠物”通常在登记阶段创建。

“样本”在采样阶段创建。

“检测项目”在开单或样本处理阶段确定。

“试剂”和“设备”在检测执行阶段发挥作用。

“检测结果”在设备上传或人工录入后产生。

“报告”在结果确认后生成。

如果你能把对象关系放回流程里看，很多设计问题会自然浮出来。

比如：

样本创建时，是否必须已经选择检测项目？

设备数据回来时，系统靠什么找到样本？

报告生成时，如果宠物信息后来被修改，报告要不要跟着变？

检测结果确认后，还能不能重新生成报告？

一个机构的用户能不能看到其他机构的报告？

这些都不是单个表能回答的问题。

它们必须放在业务流程里看。

重点不是“少存字段”，而是不要把事实存乱

很多人在设计数据表时，会纠结一个问题：

字段要不要冗余？

比如报告里要不要存宠物名字？

样本里要不要存主人电话？

检测结果里要不要存检测项目名称？

这个问题没有绝对答案。

真实项目里，有些字段可以冗余。

尤其是报告这种交付物，有时需要保存生成时的快照。

因为报告一旦交付给客户，就不能因为后面修改了宠物信息，导致历史报告内容变了。

但冗余字段有一个前提：

你必须知道它是“快照”，还是“主数据”。

如果是主数据，就应该有明确来源。

如果是快照，就应该知道它是在什么时候复制过来的。

如果这件事没讲清楚，系统就会出现很多版本不一致的问题。

比如：

宠物表里的名字是“豆豆”。

样本表里也是“豆豆”。

报告表里还是“豆豆”。

后来客户把宠物名字改成“豆豆豆”。

那历史报告要不要变？

正在检测中的样本要不要变？

新报告要不要用新名字？

这些问题看起来小，真实项目里很容易出问题。

所以数据关系梳理时，不只是看对象怎么连。

还要看：

谁是事实来源？

谁只是引用？

谁是快照？

谁可以变？

谁一旦生成就不能随便变？

这才是复杂系统里真正重要的数据判断。

我会让 WorkBuddy 输出一份“对象关系说明书”

如果让我用 WorkBuddy 来做这一步，我不会直接让它生成数据库设计。

我会先让它输出一份“对象关系说明书”。

大概任务说明书可以这样写：

任务背景： 我正在梳理一个宠物医院检验系统。 现在不要修改代码，也不要生成数据库脚本。 请先帮助我整理业务对象和数据关系。 输入材料： 请阅读项目中的数据库脚本、实体类、Mapper、前端 API、页面字段和检测相关模块。 输出要求： 生成一份《宠物医院检验系统对象关系说明书.md》。 报告包括： 1. 核心业务对象清单； 2. 每个对象的业务含义； 3. 对象之间的一对一、一对多、多对多关系； 4. 对象在主业务流程中的创建、变更、引用时机； 5. 哪些字段像主数据，哪些字段像快照； 6. 哪些关系可以从代码确认； 7. 哪些关系只是根据命名推测； 8. 哪些问题必须人工确认。 质量标准： 不要把推测写成确定结论。 不要只输出表名，要解释业务含义。 如果存在多种可能设计，请列出差异和影响。 执行边界： 不要修改任何代码。 不要改数据库脚本。 不要生成新表。 只输出分析文档。

这个任务的价值，在于它先帮你建立“业务对象地图”。

有了这张地图，再去看表结构、接口、页面，就会清楚很多。

你会知道：

哪些字段是核心事实。

哪些字段只是展示。

哪些关系必须稳定。

哪些地方需要人工确认。

哪些模块不能随便改。

这比一上来让 AI “帮我设计数据库”可靠得多。

数据关系梳理至少看五层

我建议复杂系统做数据关系梳理时，至少看五层。

第一层：业务对象

也就是系统里有哪些核心对象。

宠物主人、宠物、样本、检测项目、试剂、设备、结果、报告、机构。

这一层解决的是：

系统到底在管理什么？

第二层：对象关系

也就是对象之间怎么连接。

主人和宠物是一对多。

宠物和样本是一对多。

样本和检测项目可能是一对多或多对多。

报告会引用样本、宠物、检测结果和模板。

这一层解决的是：

数据之间怎么连？

第三层：流程状态

对象不是静态的。

样本有状态。

检测任务有状态。

检测结果有状态。

报告也有状态。

这一层解决的是：

数据在流程里怎么变化？

第四层：事实来源

哪些信息是主数据？

哪些信息是引用？

哪些信息是生成报告时的快照？

哪些信息可以修改？

哪些信息生成后不应该随便变？

这一层解决的是：

系统里哪些数据说了算？

第五层：权限边界

在宠物医院检验系统里，机构非常重要。

不同医院、不同检测机构、不同角色，能看到的数据不一样。

如果数据关系没有考虑机构和权限，系统越做越危险。

这一层解决的是：

谁能看见、谁能修改、谁能生成报告？

这五层看完，复杂系统的数据关系才算有了基本轮廓。

今天就能试的任务

如果你手上也有一个业务系统，可以让 WorkBuddy 先做这件事。

请不要先设计数据库，也不要修改代码。 请帮我梳理这个系统的业务对象和数据关系。 请输出一份对象关系说明书，包括： 1. 核心业务对象有哪些； 2. 每个对象的业务含义是什么； 3. 对象之间是什么关系； 4. 每个对象在主流程中什么时候创建、变更、引用； 5. 哪些字段像主数据，哪些字段像快照； 6. 哪些数据关系可以从现有代码确认； 7. 哪些只是根据命名推测； 8. 哪些必须找业务人员确认。 请明确区分： - 已确认； - 推测； - 待确认。

这个任务做完，你会得到一份很有价值的项目地图。

它不一定马上让你多写一个功能。

但它能帮你少走很多弯路。

尤其是在复杂业务系统里，少一次关系设计错误，可能就少一轮大返工。

写在最后

复杂系统的数据关系，不是数据库设计师一个人的事。

它本质上是业务理解。

宠物主人、宠物、样本、检测项目、试剂、设备、检测结果和报告，这些对象不是一堆表名。

它们共同构成了一条真实业务链路。

如果这条链路没理清楚，系统很容易变成一堆能点开的页面。

如果这条链路理清楚了，页面、接口、数据库、报告、设备对接，才会有明确的方向。

WorkBuddy 在这里最有价值的地方，不是马上帮你生成表结构。

而是先帮你读项目、找对象、画关系、标记不确定问题，让你从一堆代码和表里看见业务结构。

当你开始这样使用 AI，AI 就不只是代码生成器。

它会变成你的业务分析助手、系统梳理助手和交付前的检查助手。

如果你也在做医疗、宠物医院、检测机构、设备对接、报告系统、内部管理系统这类项目，欢迎关注我。

我会持续分享如何用 WorkBuddy 把真实业务系统更快、更稳地交付出来。

如果你有类似系统要开发、改造，或者想把 AI 工作流引入自己的项目团队，也可以联系我聊聊。

共勉。

—— END ——