真实项目复盘：我如何用 WorkBuddy 提效一个宠物医院检验系统

用户1064498

发布于 2026-07-14 15:48:35

420

关于我：

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

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

前几天一直在讲 WorkBuddy 的基础方法。

比如怎么搭工作区。

怎么把一句需求变成任务说明书。

怎么用 W-O-R-K 四步法，把一件模糊工作交给 AI Agent 去执行。

这些方法很重要，但如果一直停留在方法本身，读者很容易有一个疑问：

这些东西，到底能不能用在真实项目里？

所以从这篇开始，我想换一种写法。

不只讲工具。

不只讲提示词。

也不只讲一个好看的 Demo。

我想拿一个真实项目来复盘：

一个宠物医院检验系统，哪些地方可以用 WorkBuddy 提效？

这篇文章是这个真实项目系列的开篇。

我会先讲项目背景、系统复杂度、WorkBuddy 可以参与的环节，以及为什么这类文章更容易带来真实客户信任。

先说结论：真实项目最能检验 AI Agent 的价值

如果只是写一个 Demo，AI 很容易显得很厉害。

让它生成一个页面。

让它写一段代码。

让它总结一篇文章。

让它做一个表格分析。

这些都能演示能力。

但真实项目不一样。

真实项目里，需求不是一次说清楚的。

代码不是从零开始的。

字段不是随便起名的。

页面不是孤立存在的。

接口要和数据库对齐。

报告要能生成。

设备要能对接。

客户最后还要能真的用起来。

所以，真实项目最能检验 WorkBuddy 的价值。

它不是问：

AI 能不能写一段代码？

而是问：

AI 能不能帮助开发者更快理解业务、更快梳理系统、更快推进交付？

这两个问题完全不同。

前者是工具能力。

后者是交付能力。

这个项目不是普通后台，而是检验检测系统

这次复盘的项目，是一个宠物医院相关的检验系统。

它不是简单的“用户管理 + 菜单管理 + 增删改查”。

从业务上看，它围绕一个完整的检测流程展开：

宠物到院。

登记主人和宠物信息。

采集样本。

选择检测项目。

关联试剂和设备。

获取检测结果。

生成报告。

医生或客户查看报告。

如果只用一句话讲，很简单：

帮宠物医院管理检验检测流程。

但一旦拆到系统里，就会变成很多对象：

宠物主人；
宠物信息；
样本信息；
检测项目；
检测试剂；
检测设备；
检测数据；
报告模板；
检测报告；
医院或检测机构；
用户、角色和权限。

再继续往深处走，还会遇到更复杂的部分：

LIS 对接；
HL7 消息；
TCP 通信；
生化、荧光、核酸等不同检测类型；
设备返回结果和系统内部字段映射；
报告 PDF 生成；
异常日志和排查链路。

这类项目有一个特点：

表面像后台，核心是业务流程。

如果开发者只把它当普通后台做，很容易做出一堆页面。

但页面之间没有闭环。

样本导入了，检测数据没关联上。

检测结果有了，报告生成不了。

设备接进来了，异常查不到。

客户看到的是功能很多，但真正交付的时候还是卡住。

这就是为什么真实项目特别适合讲 WorkBuddy。

因为 WorkBuddy 真正有价值的地方，不是替你敲几个字段，而是帮你从业务、数据、页面、接口、设备、报告这些层面，把项目串起来。

第一类提效：快速理解业务，不从零开始猜

真实项目里，最费时间的第一步，往往不是写代码。

而是理解业务。

比如在这个项目里，“样本”“检测项目”“试剂”“报告”“设备”这些词，开发者都认识。

但它们在系统里到底怎么关联，不能靠猜。

一个样本是不是只能对应一个项目？

一个检测项目是不是对应多个检测指标？

试剂配置影响的是项目、设备，还是报告展示？

报告是手动生成，还是根据检测数据自动生成？

设备上传的数据，能不能直接入库？

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

这些问题不先问清楚，后面代码写得越快，返工越多。

过去做这类项目，我通常要自己反复翻：

数据库脚本；
后端实体类；
Mapper 和 SQL；
前端页面；
接口请求；
菜单配置；
字典配置。

现在我会让 WorkBuddy 先做一件事：

把项目地图整理出来。

让它根据已有目录、数据库脚本、前后端代码，先梳理出：

系统里有哪些业务对象；
每个对象大概对应哪些表；
前端有哪些页面；
后端有哪些接口；
哪些模块属于检测业务；
哪些模块属于系统管理；
哪些模块属于设备或 LIS 对接。

这一步不会直接产生最终功能。

但它会帮开发者快速进入项目。

你不再是站在一堆文件面前猜，而是先有了一张地图。

这对真实项目非常关键。

因为越是业务复杂的系统，越不能只靠“我大概记得”来开发。

第二类提效：把需求拆成模块，而不是直接写页面

客户经常不会说：

请帮我设计样本管理、检测任务、报告模板、设备接入、机构权限这些模块。

客户更可能说：

我们想做一个宠物医院检测系统，能录样本、看结果、出报告，最好还能接设备。

这句话听起来清楚，其实里面藏了很多系统设计问题。

如果直接开写，很容易变成哪里缺页面就补哪里。

今天补样本。

明天补报告。

后天补设备。

最后发现流程接不上。

WorkBuddy 在这里可以帮我做第二类提效：

把一句业务需求，拆成模块和边界。

比如这个项目至少可以拆成几条主线：

第一条，基础资料线。

机构、用户、宠物主人、宠物信息、检测项目、试剂、设备。

第二条，检测流程线。

样本创建、样本导入、任务生成、检测数据接收、结果确认。

第三条，报告交付线。

报告模板、报告生成、报告预览、报告下载、报告归档。

第四条，设备对接线。

LIS、HL7、TCP、消息解析、设备状态、异常日志。

第五条，运营管理线。

数据看板、机构权限、用户角色、配置管理。

这张模块图一旦出来，开发效率会明显提高。

因为你知道每次改动属于哪条线。

也知道它会影响哪些上下游。

这比“看到一个页面就改一个页面”可靠得多。

第三类提效：前后端联动，不让字段和接口各写各的

很多后台项目最容易浪费时间的地方，是前后端来回对字段。

前端页面叫 sampleNo。

后端实体叫 sampleCode。

数据库字段又叫 sample_barcode。

页面展示叫“样本编号”。

业务人员口头说的是“条码”。

如果项目小，还能靠人记。

项目一复杂，就很容易出错。

WorkBuddy 在这里可以做的事情很实际：

根据数据库字段，反查前端页面展示；
根据接口返回，检查表格列和表单字段；
根据业务文案，统一中文标签；
根据已有代码风格，补齐新增页面；
根据报错信息，定位字段不一致；
根据菜单权限，检查按钮权限配置。

这类工作不一定很难，但非常耗时间。

而且很容易被打断。

真实项目里，开发者的注意力应该更多放在业务规则和交付闭环上。

字段核对、路径查找、接口追踪、重复样板代码这些工作，正适合交给 WorkBuddy 先做一轮。

这里要强调一点：

我不是让 WorkBuddy 一次性生成整个系统。

真实项目也不应该这样做。

更好的方式是：

让 WorkBuddy 先读现有代码，再按项目原来的方式补功能。

比如我要改报告模块，就先让它看已有报告页面、报告接口、报告模板、报告生成逻辑。

然后再让它按照原有结构补能力。

这样生成的代码更容易融入项目，而不是像一个外接的 Demo。

第四类提效：设备和 LIS 对接，降低理解协议的成本

这个项目里最有含金量的部分，是设备和 LIS 对接。

普通后台页面，很多开发者都能做。

但设备对接不一样。

它会涉及：

TCP 连接；
HL7 消息；
MLLP 封包；
设备会话；
消息确认；
样本编号映射；
检测指标映射；
异常日志；
不同设备型号的差异。

这类代码不一定每天都写。

一旦接手，第一反应通常是：

先读半天。

再跑样例。

再查协议。

再看日志。

再一点点定位数据到底在哪个环节丢了。

WorkBuddy 在这里不是替你“自动接设备”。

这件事仍然需要开发者理解协议、验证设备、和现场环境对齐。

但它可以显著降低前期理解成本。

我会让它帮我做这些事：

解释一条 HL7 消息从接收到解析的流程；
画出 TCP Server 到业务入库的调用链；
根据样例消息整理字段映射表；
识别哪些异常应该记录设备编号、样本号、消息类型；
根据已有代码补测试脚本；
把协议层、映射层、业务层拆开解释。

这是实际交付里会遇到的硬问题。

第五类提效：从功能完成，到交付闭环

真实项目里，最容易被低估的一件事是：

功能完成，不等于项目可交付。

样本页面能新增，不代表检测流程可用。

报告页面能打开，不代表报告内容可信。

设备能连上，不代表数据能稳定入库。

数据能入库，不代表客户知道问题出在哪里。

所以我会让 WorkBuddy 帮我从“交付闭环”的角度检查系统。

比如一条完整流程应该能回答：

样本从哪里来？

检测任务如何产生？

设备数据如何进入系统？

结果如何确认？

报告如何生成？

报告能否预览和下载？

异常时谁能看到？

管理员如何排查？

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

这类检查，单靠开发时的感觉很容易漏。

但让 WorkBuddy 根据项目结构和业务流程做一轮清单式检查，就能提前发现很多交付风险。

这也是我越来越重视 WorkBuddy 的原因。

它不仅能提高开发速度。

更重要的是，它能提醒我：

现在做的功能，到底有没有服务于最终交付？

真实项目里的真实问题。

比如：

复杂业务怎么拆；
旧项目怎么读；
前后端怎么联动；
设备协议怎么理解；
报告系统怎么设计；
AI 怎么进入交付流程；
怎么把一次项目经验沉淀成方法。

今天就能试的任务

如果你手上也有一个真实项目，可以先不用急着让 WorkBuddy 写代码。

先让它帮你做一件事：

请阅读这个项目的目录结构、数据库脚本、前后端代码入口。 请帮我整理一份项目地图： 1. 这个项目有哪些核心业务模块？ 2. 每个模块对应哪些前端页面？ 3. 每个模块对应哪些后端接口和服务？ 4. 哪些数据库表属于核心业务？ 5. 哪些模块之间存在上下游关系？ 6. 如果我要继续开发，最应该先理解哪三条业务流程？ 请不要修改代码，只输出分析结果。

这个任务很小。

但它很有价值。

因为真实项目提效的第一步，不是立刻让 AI 写代码。

而是先让 AI 帮你看清项目。