用 WorkBuddy 做复杂业务系统，第一步不是写代码，而是把业务流程讲清楚

用户1064498

发布于 2026-07-14 15:47:06

1430

关于我：

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

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

一个真实项目里很容易被低估的问题：

复杂业务系统，第一步到底应该做什么？

我最近在整理一个宠物医院检验系统。

它不是为了演示 AI 能力临时做出来的 Demo，而是一个真实业务系统。

里面有宠物主人、宠物、样本、检测项目、试剂、设备、检测数据、报告模板、报告生成、机构权限，还有 LIS、HL7、TCP 这类设备对接问题。

很多人看到这样的项目，第一反应是：

先看代码。

先跑起来。

先找页面。

先看看数据库表。

这些动作都没错。

但如果从真实交付的角度看，它们都不是第一步。

第一步应该是：

先把业务流程讲清楚。

因为复杂业务系统最怕的，不是代码写得慢。

而是你写了很多代码，最后发现流程没闭环。

为什么不能一上来就写代码？

真实项目里，客户给你的需求经常是这样的：

我们想做一个宠物医院检验系统。 能录样本。 能看检测结果。 能生成报告。 后面最好还能接设备。

这句话听起来很清楚。

但对开发来说，它还不能直接变成代码。

因为这里面至少藏着一串问题：

样本是谁创建的？

宠物主人和宠物信息什么时候录入？

检测项目是医生选择，还是系统根据样本自动匹配？

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

检测结果是人工录入，还是设备自动上传？

报告是每个样本一份，还是多个检测结果合成一份？

报告生成后，谁能查看？

机构之间的数据是否隔离？

设备异常时，谁来处理？

这些问题如果没有想清楚，直接写页面就会很危险。

因为你很可能会先做出一堆看起来完整的功能：

宠物管理；
样本管理；
检测项目管理；
设备管理；
报告管理；
用户权限；
数据看板。

但真正跑业务的时候，才发现：

样本和检测任务没接上。

检测结果和报告没接上。

报告和客户查看没接上。

设备数据和系统字段没接上。

页面都有了，但业务走不通。

这就是复杂业务系统最常见的问题：

功能点很多，业务流程却没有闭环。

宠物医院检验系统的核心，不是页面，而是一条业务链路

如果只从后台系统角度看，这个项目可以拆出很多页面。

但如果从业务角度看，它其实围绕一条主链路展开：

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

这条链路才是系统的主干。

页面只是这条链路上的操作入口。

数据库表只是这条链路上的数据承载。

接口只是这条链路上的连接方式。

设备只是这条链路上的数据来源之一。

如果主链路没有梳理清楚，后面的技术设计都会变形。

比如样本模块。

表面看，它只是一个样本列表。

但业务上要回答：

这个样本属于哪只宠物？

属于哪个主人？

来自哪个机构？

要做哪些检测项目？

当前检测状态是什么？

有没有设备返回结果？

是否已经生成报告？

报告是否可查看、可下载、可重新生成？

再比如报告模块。

表面看，它只是一个报告列表和预览按钮。

但业务上要回答：

报告依据哪些检测结果生成？

报告模板由谁配置？

异常值如何展示？

报告生成失败怎么办？

报告是否允许覆盖？

客户看到的是 PDF，还是在线页面？

这些问题都不是单纯写代码能解决的。

它们需要先被讲清楚。

WorkBuddy 在这一步能帮什么？

这时候 WorkBuddy 的作用，不是直接替你写 Controller、Service、页面和 SQL。

更好的做法是：

先让它当“业务流程整理员”。

我会让 WorkBuddy 先做三件事。

第一，读项目现有材料。

比如目录结构、数据库脚本、前端页面、后端接口、业务模块命名。

它不需要立刻修改任何文件。

先读。

先看。

先把系统里出现过的业务对象列出来。

第二，整理业务对象之间的关系。

比如：

宠物主人和宠物是什么关系？

宠物和样本是什么关系？

样本和检测任务是什么关系？

检测任务和检测数据是什么关系？

检测数据和报告是什么关系？

报告模板和报告结果是什么关系？

设备数据进入系统后，落在哪个环节？

第三，反推一条完整业务流程。

也就是从“宠物到院”开始，一直到“报告交付”结束。

把每一步的输入、操作、输出、状态、异常都写出来。

这一步如果整理得好，后面开发会轻很多。

因为你不是在一堆文件里乱找，而是在围绕一条业务流程推进。

我会让 WorkBuddy 输出什么？

如果是我来做这个项目的第一轮梳理，我不会先让 WorkBuddy 写代码。

我会给它一个任务说明书。

大概这样写：

任务背景： 我正在梳理一个宠物医院检验系统，这是一个真实业务项目。 现在不要修改代码，也不要生成新功能。 请先帮助我理解业务流程。 输入材料： 请阅读项目目录、数据库脚本、前端页面、后端接口和检测相关模块。 输出要求： 生成一份《宠物医院检验系统业务流程梳理.md》。 报告包括： 1. 核心业务对象清单； 2. 业务对象之间的关系； 3. 从宠物到院到报告交付的主流程； 4. 每一步的输入、操作、输出； 5. 每一步可能涉及的页面、接口、数据库表； 6. 当前看起来不清楚、需要业务确认的问题。 质量标准： 不要编造项目里没有的模块。 如果只能从命名推测，请标注“推测”。 如果需要人工确认，请列入“待确认问题”。 执行边界： 不要修改任何源代码。 不要改数据库脚本。 不要生成新页面。 只输出分析文档。

这个任务看起来不像开发任务。

但它非常重要。

因为它是在帮我们完成真实项目的第一步：

从代码视角，切换到业务视角。

业务流程至少要讲清楚五件事

我建议复杂业务系统第一轮梳理，至少讲清楚五件事。

第一，谁发起流程？

宠物医院检验系统里，流程可能由前台、医生、检验人员、设备或管理员发起。

不同发起人，决定系统入口不同。

如果是前台发起，重点是登记信息和创建样本。

如果是医生发起，重点是选择检测项目和查看报告。

如果是检验人员发起，重点是样本处理和结果确认。

如果是设备发起，重点是数据接收、解析和映射。

所以第一步不是问“有哪些页面”，而是问：

谁在什么场景下开始这件事？

第二，流程里流转的核心对象是什么？

在这个项目里，最核心的对象不是“页面”。

而是：

宠物主人；
宠物；
样本；
检测项目；
检测任务；
检测结果；
报告；
设备；
机构。

业务流程其实就是这些对象的状态变化。

样本从“已创建”到“待检测”。

检测任务从“待执行”到“已完成”。

检测结果从“待确认”到“已确认”。

报告从“未生成”到“已生成”。

如果你没有把对象和状态理清楚，页面之间就很难连接。

第三，每一步输入什么，输出什么？

复杂系统最怕“只有操作，没有结果”。

比如“创建样本”这一步。

输入是什么？

可能是宠物信息、主人信息、样本类型、检测项目、采样时间、机构信息。

输出是什么？

可能是样本编号、样本状态、检测任务、条码、待检测记录。

再比如“生成报告”这一步。

输入是什么？

可能是样本信息、检测结果、报告模板、机构信息、参考范围。

输出是什么？

可能是报告记录、PDF 文件、预览链接、下载地址、生成日志。

每一步都要说清楚输入和输出。

否则接口、表结构和页面都会各写各的。

第四，异常怎么处理？

真实项目不是只跑顺流程。

更麻烦的是异常流程。

比如：

样本编号重复怎么办？

设备传回来的样本号匹配不上怎么办？

检测结果缺字段怎么办？

报告生成失败怎么办？

报告模板被删除怎么办？

机构权限不一致怎么办？

数据已经生成报告后还能不能修改？

这些问题不提前问，后面就会变成线上问题。

WorkBuddy 可以帮忙列一份异常清单。

但最终哪些异常必须处理，哪些可以先人工兜底，仍然需要人判断。

这也是我一直强调的：

AI 可以帮你整理问题，但不能替你承担业务责任。

第五，流程在哪里闭环？

一个系统有没有价值，要看它在哪里闭环。

宠物医院检验系统的闭环，不是“页面都做完了”。

而是：

样本能进来。

检测能完成。

结果能确认。

报告能生成。

医生或客户能看懂。

异常能追踪。

管理员能维护。

这个闭环跑通，客户才会觉得系统有用。

否则功能再多，也只是功能清单。

今天就能试的任务

如果你手上有一个正在做、准备做，或者已经做了一半的系统项目，可以让 WorkBuddy 先做这个任务。

请先不要写代码。 请帮我把这个项目的业务流程讲清楚。 请输出一份业务流程梳理文档，包括： 1. 这个系统服务谁； 2. 谁发起核心流程； 3. 核心业务对象有哪些； 4. 这些对象之间是什么关系； 5. 主流程从哪里开始，到哪里结束； 6. 每一步的输入、操作、输出是什么； 7. 每一步可能涉及哪些页面、接口和数据库表； 8. 有哪些异常流程需要提前考虑； 9. 哪些问题需要业务人员确认。 请明确标注： - 已经能从项目材料确认的内容； - 只能根据命名推测的内容； - 必须人工确认的内容。