宠物行业 AI + SaaS 第一版上线后，我对这套架构的几点复盘

AI 架构

引言

先说明一下，我不是专业架构师。

之前在上一家公司，我更多做的是一些模块和组件级别的设计。真正意义上从 0 到 1 去设计一整套 AI + SaaS 系统，这次算是第一次，而且第一版已经上线了。

所以这篇不是想讲什么大方法论，也不是想摆什么架构姿势。我就是想趁第一版刚做完、产品也刚上线这个节点，老老实实回头看一遍：这套架构到底哪里想对了，哪里其实一开始很容易想偏，后面又该往哪个方向继续长。

场景并不抽象，就是很实际的那种：

• 单机构起步，但架构上要预留多机构扩展能力
• 后续希望还能继续扩

最开始我脑子里也闪过很多“终局形态”的东西，比如实时音频、拾音器、边缘盒子、流式 ASR之类。但第一版真的做下来以后，我反而更确定，这事不能按“终局幻想”来起手。

因为我做的不是写一份 PPT，也不是画一个看起来很唬人的全景图，而是在想：第一次真把产品做出来并上线时，这版架构最该优先解决什么，最不该一开始就做什么。

所以这篇我不想从科普角度写，也不想从“终局方案”往回倒推，我就想站在“第一版已经做完并且上线了”这个节点上，回头复盘一下我对这套架构的几个真实判断，以及我对下一阶段的打算。

另外还有两个底层想法，第一版做完以后我也越来越确认。

一个是，架构这事基本不可能一开始就设计到终局。真要硬往“一步到位”去做，很多时候不是做重了，就是做偏了。
但反过来也不能只盯着眼前这点需求，完全不看后面，不然技术债很容易越滚越大。

所以我现在更认可的状态是：别做过度/超前设计，但也别把明天大概率会出问题的坑，当成今天看不见。别把技术债留得过多过重

另一个是，架构不能脱离业务自己玩。
对我来说，架构不是先设计一套很漂亮的东西，再让业务来适配它，而是业务走到哪一步，架构就支撑到哪一步，同时再比当前业务多想半步。

这样做的好处也很现实：

• 成本可控
• 业务更容易买单
• 系统后面也还能继续长

---

一、第一个判断：这玩意儿本质上还是 SaaS，AI 只是把架构重点改了

第一版做完以后，我反而更不认同一种说法，就是只要系统里带 AI，它就好像跟传统 SaaS 完全不是一类东西了。

在我看来，不是。

这套系统的底子，依然是一个标准的行业 SaaS。

如果不用那些太虚的词，只说我自己现在真正在想的东西，这套系统至少得先把这些基础问题想清楚：

• 多租户怎么做，集团、中心医院、诊所之间怎么分层
• 一个集团下面多门店怎么表达
• 权限模型怎么设计，总部、店长、医生、护士分别能看什么、做什么
• 宠物、主人、就诊、病历、经营数据这些核心对象怎么设计
• 门店在用的能力和总部在用的能力怎么拆，也就是服务边界怎么划
• 哪些数据共享，哪些数据隔离
• AI 和后面的第三方能力从哪里接进来

这些东西一个都跑不掉。

如果这些没打稳，AI 做得再花也没意义。因为用户最终买单的，还是一个能跑业务、能沉淀数据、能让总部和门店都用起来的系统。

而且这里还有一个我现在越来越重视的点：软件架构不能脱离业务目标单独存在。

我们做这套产品，不是为了做一个“功能很多的宠物行业工具箱”，而是希望软件能真正深入到客户的经营和日常管理里，最终达到两个目标：

1. 提升一线执行效率
2. 辅助决策

如果离开这两个目标去谈架构，很多设计最后都会变成自嗨。

而且第一版做完以后，我对“架构要跟业务一起迭代”这件事更有感觉了。

不是说业务提什么，技术就机械配合什么。
而是当前业务最需要什么，架构就先把这块支撑稳；等业务往前走了，架构再跟着长。

这样做最现实的好处就是，不容易一开始把系统做得过重，同时也不至于后面业务一变，系统马上顶不住。

但 AI 的加入，确实把架构重点改了。

传统 SaaS 更多是在处理确定性流程。
比如录入、查询、审批、结算、统计，这些本质上都是规则系统。

而 AI + SaaS 不一样的点在于，它把一个“结果不那么稳定”的处理环节塞进了原本稳定的业务链路里。

第一版做下来，我还是觉得这就是两者最大的区别。

不是多了一个模型服务，也不是页面上多了一个 AI 按钮，而是：

原来的系统主要是在执行确定规则，现在我要开始想办法把“不那么稳定的结果”稳稳地放进业务流程里。

这件事一旦成立，很多设计思路都会跟传统 SaaS 不一样。

---

二、第二个判断：AI + SaaS 和传统 SaaS 的区别，重点不在技术名词，在系统责任边界

我现在看这个问题，最核心的差异其实在责任边界。

传统 SaaS 的责任边界相对清楚：

• 前端负责采集输入
• 后端按规则处理
• 数据库存业务真相
• 报表系统做统计分析

只要规则是对的，系统结果通常就是可预期的。

但 AI + SaaS 不一样。

因为 AI 的结果很多时候不是“错或者对”这么简单，它经常是：

• 大方向对了，但细节不够稳
• 能生成，但格式不稳定
• 能抽取，但字段偶尔偏
• 没报错，但不好直接入库

所以我在做这类架构设计时，脑子里会比传统 SaaS 多一层问题：

1. AI 结果是不是业务真相？
2. 什么时候只能当草稿？
3. 谁来确认？
4. 错了以后怎么回退？
5. 怎么看它到底好不好用？

这几个问题如果不单独设计，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 先做这几件事：

1. 生成病历草稿
2. 生成问诊摘要
3. 抽结构化字段

这里我最看重的，不是“炫”，而是架构能不能形成一个清晰闭环：

业务输入
  -> AI任务创建
  -> 上下文装配
  -> 模型处理
  -> 结果生成
  -> 医生确认
  -> 回写正式业务数据

只要这个闭环能稳定跑通，这个 0 到 1 的第一版就能积累很多非常关键的东西：

• 什么输入最有效
• 什么场景采纳率高
• 医生改动最多的是哪部分
• 结构化抽取最容易错在哪
• 单次任务的成本大概多少

而第一版上线以后，我也确实开始更清楚地看到了一个更重要的经营问题：

• 这套系统到底是在帮客户“省时间”
• 还是在帮客户“提质量”
• 还是已经开始帮客户“做判断”

这些数据，在我看来比第一天就把拾音器装进诊室更有价值。

---

六、第六个判断：这套架构和传统 SaaS 的真正区别，是要单独设计 AI 任务层，后面再看要不要长出辅助经营判断的能力

如果这事只是传统 SaaS，我的主线大概就是：

前端 -> API -> 业务服务 -> 数据库

但现在因为有 AI，这个链路在我脑子里已经不是这么简单了。

我在第一版里专门抽了一层出来，承接 AI 相关逻辑。

也就是我这里说的 AI 任务层。

这一层至少要管这些事情：

• 什么时候创建 AI 任务
• 任务吃哪些上下文
• 调哪个模型
• 模型返回后怎么校验
• 结果是进入草稿态还是直接丢弃
• 有没有失败重试
• 怎么记录状态

说白了，这一层不是简单转发一下请求，而是把业务上下文、模型能力、状态流转、校验逻辑和人工确认流程串起来。

这层如果不抽出来，AI 逻辑最后就会散在各个业务模块里。

到时候最麻烦的不是代码丑，而是：

• 你根本说不清 AI 到底在哪儿影响了业务
• 你很难统一做评测
• 你没法统计成本
• 你也没法稳定优化效果

所以第一版做完以后，我更明确了一件事，AI + SaaS 和传统 SaaS 的关键架构差异之一，就是：

传统 SaaS 的主干是业务服务层，AI + SaaS 需要在业务服务层之外，再长出一层 AI 任务层。

这层不是附属物，是骨架的一部分。

而且从上线后的视角看，这层不只是为了“把流程串起来”，它本质上还承担了稳定性和兜底职责。

至少在我现在的理解里，这一层后面一定要逐步补齐这些能力：

• 用状态机管理任务流转，而不是靠 if else 到处补
• 幂等处理，避免重复提交、重复执行
• 失败重试，但不能无限重试
• 超时控制，避免模型调用把主链路拖死
• 降级策略，模型不稳定时至少不能把核心业务流程卡住
• 可观测性，要能看到任务卡在哪一步、失败在哪一步

说白了，AI 任务层不只是“调一次模型”，它后面其实是一个带容错和兜底能力的处理链路。

而且我现在已经能感觉到，到了下一阶段，光有任务层可能还不够，后面很可能还会自然长出一块专门做经营分析、异常提醒、辅助判断的能力。

因为一旦系统开始服务经营和管理，它就不能只停留在“帮你生成一段文字”，而要开始回答这些问题：

• 这家门店最近的复诊率有没有异常
• 哪类服务项目转化更差
• 哪个医生的病历质量波动比较大
• 哪些经营动作值得提醒

到那个阶段，AI 的价值就不再只是内容生成，而是开始进入经营反馈和辅助决策。

---

七、第七个判断：第一版里，AI 结果不能直接等于业务真相，但下一阶段它可以逐步参与执行

这一点我现在回头看，基本还是不会妥协。

因为只要 AI 结果直接落正式数据，系统就会立刻变得很危险。

尤其在这种医疗相关场景里，我现在还是更倾向于把 AI 结果定义为：

• 草稿
• 建议
• 候选结果
• 辅助结构化信息

而不是最终记录。

所以第一版里，我实际更愿意让系统变成下面这种关系：

flowchart TD
    A["SaaS业务输入"] --> B["AI任务层"]
    B --> C["模型处理层"]
    C --> D["草稿结果层"]
    D --> E["医生确认/修订"]
    E --> F["正式业务数据"]

这里面最重要的，不是图画得多复杂，而是责任边界很清楚：

• AI 负责产出建议
• 医生负责确认
• 业务系统负责保存真相

这个边界不清，后面系统只会越来越难收。

而且上线以后我更确定一点：任何模型调用失败、结构化失败、结果不稳定，都不应该阻断核心业务流程。

也就是说，AI 这条链路可以失败，可以降级，可以回退到人工处理，但不能把主业务链路一起拖死。

这个在我看来其实也是架构设计里很现实的一部分，不能只想着“AI 成功时多聪明”，还得提前想好“它失败时系统怎么活”。

但另一方面，我也不认为 AI 永远只该停留在“建议层”。

我现在对下一阶段的看法是：

• 在高风险场景里，AI 先当建议者
• 在低风险、规则清晰、可审计的场景里，AI 后面是可以逐步参与执行的

比如一些经营类、运营类、流程类动作，未来完全可能从：

辅助生成 -> 辅助判断 -> 人工确认 -> 自动执行

一路往下演进。

这也是我觉得 AI + SaaS 和传统 SaaS 最终会拉开差距的地方。

传统 SaaS 更多还是一个承载流程的系统。
AI + SaaS 如果做得足够深，是有机会从“把流程记下来”走向“参与把事情做下去”的。

---

最后

写到这里，我其实更确定了自己做完第一版、并且产品已经上线以后，对这套架构的几个核心判断：

1. 这套系统的底子依然是 SaaS，不是先上 AI 再补业务
2. 软件架构不能脱离业务目标，我的目标不是做工具，而是深入客户经营和日常管理
3. AI + SaaS 和传统 SaaS 的区别，核心在于我要处理一个“结果不那么稳定的能力”进入业务链路后的责任边界
4. 第一版最重要的是业务闭环，不是实时
5. 第一版不上拾音器，也不上边缘盒子，这个取舍我现在依然认
6. 第一版更像一个带 AI 助手能力的 SaaS，而不是 AI IoT 系统
7. 架构上必须单独抽出 AI 任务层，下一阶段再看要不要单独做经营分析和辅助判断这块能力
8. AI 结果先当草稿，不直接当业务真相，但下一阶段可以逐步参与一些低风险动作

后面随着门店变多、采集量变大、实时性要求变强，拾音器、边缘节点这些东西大概率都会重新进入架构讨论。

但那应该发生在“软件闭环已经成立”之后，而不是之前。

至少以我当前这版软件设计来看，我更愿意先把这件事做对，再把它做重。