我现在对宠物行业AI+SaaS架构的几个判断.md 17 KB
title: 我做完宠物行业 AI + SaaS 第一版后，对这套架构的几个判断 author: Gamehu date: 2026-03-23 18:18:00 tags:
- AI
- SaaS
- 架构设计
- 宠物医疗 categories:
- AI ---
引言
先说明一下，我不是专业架构师。
之前在上一家公司，我更多做的是一些模块和组件级别的设计，真正意义上从 0 到 1 去设计一整套 AI + SaaS 系统，这次算是第一次，而且第一版已经上线了。
所以这篇不是站在一个“很懂架构的人”视角来讲方法论，更像是我做完第一版以后，老老实实回头看一遍：这套架构到底哪里想对了，哪里其实一开始很容易想偏，后面又该往哪个方向继续长。
场景并不抽象，就是很实际的那种：
- 1个或者N个宠物医院
- 后续希望还能继续扩
最开始我脑子里也闪过很多“终局形态”的东西，比如实时音频、拾音器、边缘盒子、流式 ASR、自动生成病历之类。但越往后想，我越觉得这事不能按“终局幻想”来起手。
因为我现在做的不是写一份 PPT，也不是做一个看起来很唬人的全景图，而是在想：如果这套软件第一次真的要从 0 到 1 落地，我当前这版架构最该优先解决什么，最不该一开始就做什么。
所以这篇我不想从科普角度写，也不想从“终局方案”往回倒推，我就想站在“第一版已经做完并且上线了”这个节点上，回头复盘一下我对这套架构的几个真实判断，以及我对下一阶段的打算。
另外还有两个底层想法，第一版做完以后我也越来越确认。
一个是，架构这事基本不可能一开始就设计到终局。真要硬往“一步到位”去做，很多时候不是做重了，就是做偏了。
但反过来也不能只盯着眼前这点需求，完全不看后面，不然技术债很容易越滚越大。
所以我现在更认可的状态是：别做超前设计，但也别把明天大概率会出问题的坑，当成今天看不见。
另一个是，架构不能脱离业务自己玩。
对我来说，架构不是先设计一套很漂亮的东西，再让业务来适配它，而是业务走到哪一步，架构就支撑到哪一步，同时再比当前业务多想半步。
这样做的好处也很现实：
- 成本可控
- 业务更容易买单
- 系统后面也还能继续长
一、第一个判断：这玩意儿本质上还是 SaaS，AI 只是把架构重点改了
第一版做完以后，我反而更不认同一种说法，就是只要系统里带 AI，它就好像跟传统 SaaS 完全不是一类东西了。
在我看来，不是。
这套系统的底子，依然是一个标准的行业 SaaS。
如果不用那些太虚的词，只说我自己现在真正在想的东西，这套系统至少得先把这些基础问题想清楚：
- 集团、中心医院、诊所之间怎么分层
- 一个集团下面多门店怎么表达
- 总部、店长、医生、护士分别能看什么、做什么
- 宠物、主人、就诊、病历、经营数据这些核心对象怎么设计
- 门店在用的能力和总部在用的能力怎么拆
- 哪些数据共享，哪些数据隔离
- AI 和后面的第三方能力从哪里接进来
这些东西一个都跑不掉。
如果这些没打稳，AI 做得再花也没意义。因为用户最终买单的，还是一个能跑业务、能沉淀数据、能让总部和门店都用起来的系统。
而且这里还有一个我现在越来越重视的点：软件架构不能脱离业务目标单独存在。
我做这套产品，不是为了做一个“功能很多的宠物行业工具箱”，而是希望软件能真正深入到客户的经营和日常管理里，最终达到两个目标：
- 提升一线执行效率
- 辅助总部和门店做经营决策
如果离开这两个目标去谈架构，很多设计最后都会变成自嗨。
而且第一版做完以后，我对“架构要跟业务一起迭代”这件事更有感觉了。
不是说业务提什么，技术就机械配合什么。
而是当前业务最需要什么，架构就先把这块支撑稳；等业务往前走了，架构再跟着长。
这样做最现实的好处就是，不容易一开始把系统做得过重，同时也不至于后面业务一变，系统马上顶不住。
但 AI 的加入，确实把架构重点改了。
传统 SaaS 更多是在处理确定性流程。
比如录入、查询、审批、结算、统计，这些本质上都是规则系统。
而 AI + SaaS 不一样的点在于，它把一个“不完全确定”的处理环节塞进了原本确定的业务链路里。
第一版做下来，我还是觉得这就是两者最大的区别。
不是多了一个模型服务，也不是页面上多了一个 AI 按钮，而是：
原来的系统主要在处理规则，现在我要开始处理概率。
这件事一旦成立，很多设计思路都会跟传统 SaaS 不一样。
二、第二个判断：AI + SaaS 和传统 SaaS 的区别，重点不在技术名词，在系统责任边界
我现在看这个问题，最核心的差异其实在责任边界。
传统 SaaS 的责任边界相对清楚：
- 前端负责采集输入
- 后端按规则处理
- 数据库存业务真相
- 报表系统做统计分析
只要规则是对的，系统结果通常就是可预期的。
但 AI + SaaS 不一样。
因为 AI 的结果很多时候不是“错或者对”这么简单，它经常是：
- 大方向对了，但细节不够稳
- 能生成，但格式不稳定
- 能抽取，但字段偶尔偏
- 没报错，但不好直接入库
所以我在做这类架构设计时，脑子里会比传统 SaaS 多一层问题：
- AI 结果是不是业务真相？
- 什么时候只能当草稿？
- 谁来确认？
- 错了以后怎么回退？
- 怎么看它到底好不好用？
这几个问题如果不单独设计，AI 最后就很容易变成系统里一个“看起来高级，但责任全是人工兜底”的模块。
再往业务上说得直白一点。
传统 SaaS 在大多数时候更像一个被动工具：
- 你录，我存
- 你查，我返
- 你点，我算
它的核心价值当然也很大，但更多是把业务流程线上化、结构化、可追溯化。
而 AI + SaaS 不一样的地方在于，它开始有机会从“被动响应”走向“主动参与”：
- 主动给出病历草稿
- 主动提炼摘要
- 主动发现异常点
- 主动给经营分析做提示
- 在规则允许的情况下，直接参与完成某个动作
第一版做完以后，我更确定这是一条很重要的分界线：
传统 SaaS 更像工具，AI + SaaS 更像会参与业务的助手。
它不只是把信息存起来，而是开始参与反馈、辅助决策，甚至在某些边界清晰的场景里直接把事情做完。
但这个前提一定是责任边界清楚，而不是把所有风险都重新甩回给人。
所以我现在回头看，第一版里最正确的一条原则就是：
AI 先做增强，不直接做裁决；先做草稿，不直接做真相。
这也是我现在跟传统 SaaS 设计思路分叉最明显的地方。
三、第三个判断：第一次从 0 到 1 做这个产品，第一版最重要的不是实时，而是业务闭环
如果按传统软件思维，很容易觉得“架构高级”意味着实时、自动化、全链路采集。
但第一版做完以后，我反而更确认，第一次从 0 到 1 做这个产品，最重要的不是实时，而是闭环。
也就是说，我先要证明的是：
- 医生到底愿不愿意用 AI 结果
- AI 生成的病历草稿到底有没有实际价值
- 摘要、结构化抽取、辅助录入，这几个点哪个最值得先做
- 整个交互链路能不能跑通
- AI 的结果有没有真的进入经营与日常管理，而不是停留在“看起来挺聪明”
这些事情没跑通之前，我不太愿意一开始就把问题抬到“实时音频 + 设备采集 + 边缘节点”那个复杂度。
因为那样一来，系统的验证变量一下子就太多了。
我到时候都很难判断：
- 是 AI 本身没价值
- 还是采集方式不稳定
- 还是现场网络问题
- 还是硬件运维太重
- 还是门店根本不愿意配合
这种情况下，架构不是在帮我缩小问题，而是在帮我放大噪音。
现在回头看，我当时这个思路是对的：
第一版先做最小业务闭环，先证明 AI 在软件链路和管理链路里能成立，再考虑它在硬件链路里值不值得做深。
四、第四个判断：第一版不上拾音器，也不上边缘盒子，这个取舍我现在依然认
第一版做完以后，我依然觉得这个取舍是对的。
不是说以后一定不做，而是第一版确实不该这么起手。
说到底，这也是“架构逐步演进”这件事在我这个项目里的一个具体体现。
如果我一开始就按终局形态去堆，很可能会显得我想得很多，但真正落到第一版，成本不一定扛得住，业务也未必真买单。
但如果我只顾着先上线，完全不看后面，那等门店一多、数据一上来、链路一拉长，系统也会很快露出问题。
所以这里最难的其实不是选“重”还是“轻”，而是拿捏这个度。
原因很现实。
1. 这不是当前最核心的验证点
我第一版最想验证的，就是 AI 在病历生成、摘要提炼、结构化录入这些环节到底能不能形成价值。
而拾音器和边缘盒子，解决的是更后面的工程化问题：
- 自动采集
- 弱网缓存
- 实时流处理
- 多门店部署一致性
- 硬件和云端协同
这些当然重要，但它们不是当前第一性问题。
2. 一上硬件，复杂度会成倍上升
一旦加上硬件，我要额外处理的事情太多了：
- 设备安装
- 门店网络环境
- 音频质量
- 远程运维
- 故障排查
- 升级策略
而这些问题跟“AI 到底有没有产品价值”并不是一回事。
如果第一版就把它们全绑在一起，我很可能会把项目节奏拖慢。
3. 边缘盒子更像后续规模化阶段的优化件，不像我当前第一版的必需件
现在回头看，我对边缘盒子的判断还是没变：它更像是当业务跑起来以后，为了解决稳定性、缓存、补传、弱网和成本问题，才逐步变得必要的组件。
也就是说，它更偏工程放大器，而不是第一版价值验证器。
所以至少在第一版阶段，我没把它当默认配置。
五、第五个判断：第一版更应该先长成一个“带 AI 助手能力的 SaaS”，而不是“AI IoT 系统”
这是我第一版做完以后非常清晰的一个分界线。
如果按我现在回头看的思路，第一版更像一个带 AI 助手能力的 SaaS，而不是一个带重硬件形态的 AI 系统。
我第一版其实就是更倾向先用现有的软件入口去做输入：
- 医生手工录入问诊信息
- 医生或前台上传录音文件
- 问诊后补一段文字摘要
- 结合既有病历和检查结果补上下文
然后 AI 先做这几件事：
- 生成病历草稿
- 生成问诊摘要
- 抽结构化字段
这里我最看重的，不是“炫”，而是架构能不能形成一个清晰闭环：
业务输入
-> AI任务创建
-> 上下文装配
-> 模型处理
-> 结果生成
-> 医生确认
-> 回写正式业务数据
只要这个闭环能稳定跑通，这个 0 到 1 的第一版就能积累很多非常关键的东西：
- 什么输入最有效
- 什么场景采纳率高
- 医生改动最多的是哪部分
- 结构化抽取最容易错在哪
- 单次任务的成本大概多少
而第一版上线以后，我也确实开始更清楚地看到了一个更重要的经营问题：
- 这套系统到底是在帮客户“省时间”
- 还是在帮客户“提质量”
- 还是已经开始帮客户“做判断”
这些数据，在我看来比第一天就把拾音器装进诊室更有价值。
六、第六个判断：这套架构和传统 SaaS 的真正区别，是要单独设计 AI 任务层，后面再看要不要长出辅助经营判断的能力
如果这事只是传统 SaaS，我的主线大概就是：
前端 -> API -> 业务服务 -> 数据库
但现在因为有 AI，这个链路在我脑子里已经不是这么简单了。
我在第一版里专门抽了一层出来，承接 AI 相关逻辑。
也就是我这里说的 AI 任务层。
这一层至少要管这些事情：
- 什么时候创建 AI 任务
- 任务吃哪些上下文
- 调哪个模型
- 模型返回后怎么校验
- 结果是进入草稿态还是直接丢弃
- 有没有失败重试
- 怎么记录状态
说白了，这一层不是简单转发一下请求，而是把业务上下文、模型能力、状态流转、校验逻辑和人工确认流程串起来。
这层如果不抽出来，AI 逻辑最后就会散在各个业务模块里。
到时候最麻烦的不是代码丑，而是：
- 你根本说不清 AI 到底在哪儿影响了业务
- 你很难统一做评测
- 你没法统计成本
- 你也没法稳定优化效果
所以第一版做完以后，我更明确了一件事，AI + SaaS 和传统 SaaS 的关键架构差异之一，就是：
传统 SaaS 的主干是业务服务层，AI + SaaS 需要在业务服务层之外，再长出一层 AI 任务层。
这层不是附属物，是骨架的一部分。
而且我现在已经能感觉到，到了下一阶段，光有任务层可能还不够，后面很可能还会自然长出一块专门做经营分析、异常提醒、辅助判断的能力。
因为一旦系统开始服务经营和管理，它就不能只停留在“帮你生成一段文字”，而要开始回答这些问题：
- 这家门店最近的复诊率有没有异常
- 哪类服务项目转化更差
- 哪个医生的病历质量波动比较大
- 哪些经营动作值得提醒
到那个阶段，AI 的价值就不再只是内容生成，而是开始进入经营反馈和辅助决策。
七、第七个判断：第一版里，AI 结果不能直接等于业务真相，但下一阶段它可以逐步参与执行
这一点我现在回头看，基本还是不会妥协。
因为只要 AI 结果直接落正式数据，系统就会立刻变得很危险。
尤其在这种医疗相关场景里，我现在还是更倾向于把 AI 结果定义为：
- 草稿
- 建议
- 候选结果
- 辅助结构化信息
而不是最终记录。
所以第一版里，我实际更愿意让系统变成下面这种关系：
flowchart TD
A["SaaS业务输入"] --> B["AI任务层"]
B --> C["模型处理层"]
C --> D["草稿结果层"]
D --> E["医生确认/修订"]
E --> F["正式业务数据"]
这里面最重要的，不是图画得多复杂，而是责任边界很清楚：
- AI 负责产出建议
- 医生负责确认
- 业务系统负责保存真相
这个边界不清，后面系统只会越来越难收。
但另一方面，我也不认为 AI 永远只该停留在“建议层”。
我现在对下一阶段的看法是：
- 在高风险场景里，AI 先当建议者
- 在低风险、规则清晰、可审计的场景里，AI 后面是可以逐步参与执行的
比如一些经营类、运营类、流程类动作，未来完全可能从：
辅助生成 -> 辅助判断 -> 人工确认 -> 自动执行
一路往下演进。
这也是我觉得 AI + SaaS 和传统 SaaS 最终会拉开差距的地方。
传统 SaaS 更多还是一个承载流程的系统。
AI + SaaS 如果做得足够深，是有机会从“把流程记下来”走向“参与把事情做下去”的。
最后
写到这里，我其实更确定了自己做完第一版、并且产品已经上线以后，对这套架构的几个核心判断：
- 这套系统的底子依然是 SaaS，不是先上 AI 再补业务
- 软件架构不能脱离业务目标，我的目标不是做工具，而是深入客户经营和日常管理
- AI + SaaS 和传统 SaaS 的区别，核心在于我要处理一个“概率性能力”进入业务链路后的责任边界
- 第一版最重要的是业务闭环，不是实时
- 第一版不上拾音器，也不上边缘盒子，这个取舍我现在依然认
- 第一版更像一个带 AI 助手能力的 SaaS，而不是 AI IoT 系统
- 架构上必须单独抽出 AI 任务层，下一阶段再看要不要单独做经营分析和辅助判断这块能力
- AI 结果先当草稿，不直接当业务真相，但下一阶段可以逐步参与一些低风险动作
后面随着门店变多、采集量变大、实时性要求变强，拾音器、边缘节点这些东西大概率都会重新进入架构讨论。
但那应该发生在“软件闭环已经成立”之后，而不是之前。
至少以我当前这版软件设计来看，我更愿意先把这件事做对，再把它做重。