「一人公司扶持计划」开放投稿之后，我们收到了一份让人愣了一下的方案。不是小程序。
是一份长长的 md 文档——心脑血管疾病智能协作管理平台。要服务 24 家卫生院，11 家正在试点。9000 多份居民档案在跑。
我们以前看到的用 AI + CloudBase 做出来的东西，大多是小程序：编织、电商、旅游、游戏——都很好，但都是一听就能想象出来的「爱好项目」。
这一次是一个真正的医疗行业信息化系统——以前那种要走招投标、要过三级等保、要一整个团队撸大半年的 B 端项目。
写它的人叫沐泽。16 年医疗信息化产品经理，自己开了一家「一人公司」。整个系统，是他一个人用 CloudBase + CodeBuddy 做出来的。
我们约了他一次访谈。聊完之后，脑子里一直转一句话——
原来 CodeBuddy + CloudBase，还能这么用。
一、「我能做到 90 分的东西，常常只能做到 60 分」
沐泽今年 38 岁。HIS、电子病历、家庭医生签约、在线挂号、慢病管理、公共卫生——医院信息化这一行的主流产品，他几乎挨个做了一遍。2021 年他认准一个方向：专门做公共卫生和健康管理。
做产品经理做到后面，他越来越憋闷。因为很多项目的问题根本不是技术问题。
合同是销售和售前跑下来的，技术评估和需求管理几乎空白。项目经理接到手时合同已经签了，需求是模糊的。项目交付的目标，是「符 合合同」，不是「用户真的用起来」。最后做出来的系统，基层医生根本不会打开。
他自己脑子里有更好的数据模型、更合理的扩展结构、更灵活的底层设计。但落地的时候层层打折。
「我能做到 90 分的东西，常常只能做到 60 分。」
其实不止医疗行业。任何一个在传统软件公司待过超过 5 年的产品老兵，大概率都对这种感觉有共鸣：你脑子里想的那件事，和你最后能交付出去的那件事，差着 30 分。
这 30 分不是能力问题，是系统性损耗。
2024 年夏天，沐泽辞职了。他手里攥着两样东西：一套在脑子里反复推演了好几年的多级机构协同机制下的慢病管理方案，和前公司认可他的几个客户。他开了家一人公司，打算把那 30 分补回来。
二、一个想了很多年的东西，一直跑在他脑子里
你让一个同时要填 8 种表格的村医，怎么把慢病管理这件事做好？
沐泽脑子里那个东西，要解决的就是这件事。但他不打算做「慢病管理平台」，他要做的是一套可以通过动态配置，扩展到任何健康管理场景的底层框架：
- 表单结构，动态配置
- 校验规则，可视化配置
- 指标口径、随访流程、提醒规则，全部引擎化
- 来一个新业务，不需要从零开发一套，只要维护一些数据进去就能跑起来
用他的原话：「我不做某一类病，我做的 是能长出所有病的土壤。」
这套方案，他在脑子里推演了好几年。但它一直跑在脑子里。因为在过去的世界里，让它跑到世界上，中间要过五关：一支全栈团队、一套服务器集群、一份外包合同、一年起步的排期、一次又一次「用户体验 vs 实现成本」的妥协。
他是个产品经理。他有想法，没有那个把想法做出来的「施工队」。
三、从「做个 demo」，到「不小心做成了真产品」
2025 年 11 月，沐泽拿到了一份心脑血管平台的合同。原计划外包给一个三四人的小团队。
他把 PRD、原型、业务逻辑整理好，交付给外包方。结果外包那边同时接了好几个项目，他的优先级被排在最后。谈了一个多月，几乎没有实质进展。他一边等，一边急。合同是他签的，交付日期压在他头上。
然后他做了一件事——他开始自己动手做 demo。不是为了自己写代码，是想用一个能跑起来的原型代替文档，跟外包沟通时少走弯路。
也就是这段时间，他在 B 站刷到一个视频。有人在演示用 AI 写代码，做了个完整的小项目。那是 2025 年底，MCP 刚开始普及，AI 编程工具开始真正可用。
他半信半疑地装了一个 CodeBuddy，开始试。第一次跑起来的时候，他愣住了：
「我发现我不需要那支外包团队了。」
然后——他退掉了外包方案。
从 2025 年 12 月到 2026 年 4 月，他一个人，把这套系统从零做到了上线。2026 年 4 月 2 日，系统正式交付客户。11 家卫生室和 1 家卫生院做试点，9000 多份居民档案。从他在 B 站刷到第一个视频开始算——四个多月。
四、为什么选 CloudBase：像家里通了自来水
聊到技术选型，我以为他会给出一堆对比。毕竟 16 年老兵，对比过三家云、五种后端方案、七种部署流程，本来是起步配置。
结果他给出的答案，简单到不行：Serverless，就是答案。
而 CloudBase 的 Serverless 架构，和他当年做项目时反复推演的微服务理念几乎是无缝吻合——每个云函数就是一个服务，业务天然模块化。
更关键的一点——他要做的不只是一个 Web 端，还要有给居民用的 C 端小程序。如果他选别家的 Serverless，得自己再搭一遍微信小程序的基础设施、对接一遍鉴权、处理一遍数据打通。一个人扛这些，头大。
「你不需要打井。你只需要拧开龙头。」
对沐泽这样一个「脑子里早就有房子图纸」的产品经理来说，他缺的从来不是施工图——他缺的是一片已经通了水电、通了煤气、通了网络的土地。CloudBase 就是那片土地。
五、他跟 AI 的分工：我出架构，AI 写代码
如果说 CloudBase 是土地和管道，那 AI 就是沐泽的施工队。
而他这个「一人公司」的老板——手里同时握着 PRD、架构图、排期表、验收标准。访谈里他这段话，是整场访谈里最值钱的一段：
「我出架构，AI 写代码。我负责把业务想清楚，AI 负责把它原样落地。它不会嫌需求烦，不会说实现成本太高要不要简化，不会半年后带着一身妥协走人。」
这段话说清楚了一件事——AI 编程最大的红利，不是让不懂业务的人去写代码，是让懂业务的人不再被「不会写代码」困住。
于是，AI 把那 30 分，找回来了。
六、但也踩了好几个坑
不过这一路并不都是爽文。沐泽没藏着，他坦白——前期那段时间，几乎是「代码地狱」。
坑主要是：AI 早期写出来的代码结构混乱、改一处崩三处；上下文丢失后 AI 开始「自由发挥」，偏离他定的架构；数据库 schema 反复变动导致数据迁移麻烦。
他的解法，每一个做 B 端产品的人都该看一下：把架构设计文档化，喂给 AI；拆小任务，一次只改一个模块；关键数据结构先定死，再让 AI 动手。
七、4 个月后，140 家单位在用
2026 年 4 月 2 日，系统正式上线。第一批试点的 11 家卫生院——乡镇卫生院、社区卫生服务中心、村卫生室——开始把工作从纸质表单迁到这套平台上。
上线前，沐泽带着 Beta 版去客户现场演示。演示到一半，客户当场拍板，安排下面的人对接，要求尽快上线使用。
「非常符合他们的预期。」
上线一周多，他已经发布了两个小版本。每一版都来自基层医生的真实反馈——有人说某个流程太绕，有人要求加一个字段，有人提了他当初没想到的场景。
截止目前该项目最新的消息是：5 月 8 号试点通过，正在全县推广，现在县疾控中心 + 卫生院 + 卫生室一共 140 家单位在应用。沐泽已经开始小程序端的开发，5 月 18 日刚用 beta 版给客户做了演示，预计 6 月上旬上线小程序 1.0。
这套系统的规模，按他自己作为老产品经理的估算——如果用传统开发模式，至少需要半年，一支三到四人的团队。
而他实际用的资源是：**一个人，一台笔记本，四个月。**加上 CloudBase 的资源费，和 CodeBuddy 的 token 费用。就这样。
八、「大厂和小公司之间的时差，被拉平了」
访谈到后面，沐泽讲了一段话。这段话如果这篇文章你只看一段，就看这一段：
「大厂和小公司之间的时差，被拉平了。过去大厂有一整个团队，小公司没有。现在我有 AI + CloudBase，我能做出来的东西，跟大厂一个团队做出来的，差距没有以前那么大了。」
这句话如果从一个刚入行两三年的独立开发者嘴里说出来，会觉得是年轻人的豪言。但它是从一个做了 16 年 B 端、亲眼见过一个又一个「建了不用」的项目的老兵嘴里说出来的——它的重量完全不一样。
他接着说：「现在做 B 端的门槛，从『你能不能组起一支团队』，变成『你懂不懂用户真正要什么』。团队会消失，但懂用户这件事，不会。」
九、尾声｜他只是走在前面的那一个
访谈快结束的时候，我们问他：「做了 16 年医疗信息化，到这个项目为止，你最深的感受是什么？」
他想了一会，说：「原来我脑子里那些东西，是真的能被人用起来的。」
这句话听起来很轻。但它需要三个条件同时成立，才能被说出来——
- 一个懂行业、懂业务、脑子里有「应该长这样」的产品经理；
- 一套把基建全部打包好、让他不用操心服务器和运维的云平台；
- 一个能把他脑子里的架构原样翻译成代码的 AI。
过去这三个条件缺任何一个，故事都讲不下去。现在，三者同时到位。
我们之前写过老末——51 岁，零代码基础，3 天做出一个编织小程序。她证明了：门槛塌了，普通人也能造东西。
今天的主角沐泽，是 16 年医疗信息化老兵。他证明了：行业老兵积累的经验，可以被 AI 重新激活。
下一个可能是谁？可能是一个做了 10 年供应链的产品经理，做一套专治某个垂直行 业的 ERP；可能是一个乡镇兽医，做一个帮同行管理牲畜健康档案的系统；可能是一个社区网格员，做一个让老年人更容易使用的服务预约工具。
只要他在自己的领域里泡得足够深，知道「用户真正需要什么」。
