智慧医疗产品正陷入同质化内卷的困境，从呼叫系统到大屏显示的所谓升级，却难掩'伪智慧'的本质。本文以智慧病房为例，犀利指出医疗ToB领域面临的两大痛点：地域政策壁垒与临床理解缺失，并提出AI时代医疗产品经理需要'双轨制'能力——既要保持技术敏感度快速试错，又要坚守医疗本质沉淀验证。

昨天深夜，我盯着手头正在规划的智慧病房产品方案发呆。

产品从床旁交互到走廊显示屏，再到护士站看板，硬件换了三茬，底层从安卓跑到鸿蒙，可回头一看，我们做的不过是把“叮咚”响的呼叫器，变成了能显示患者姓名、护理等级的大屏幕。这算智慧吗？我觉得心虚。

从临床一线转行做医疗产品经理第五年了。从一笔笔画原型、一字字码PRD的“小学生”，到现在带着产品线往前跑，我越来越强烈地感受到一个矛盾：

我们正试图用一套“旧思想”，去走一条“新道路”。

老套路为何在医疗ToB领域失灵了？

刚入行时，前辈告诉我，产品经理要经历一套完整训练：从问题发现、市场调研、需求分析、需求设计到测试验收、上市发布，必须有一个完整的周期。这套方法论在互联网行业跑得很顺，可一到医疗ToB领域，就处处水土不服。

为什么呢？我自己的体会有两点：

第一，医疗产品的“政策属性”和“地域性”太强。

比如一个智慧病房产品，在浙江能跑通的模式，到了云南可能连标书都过不了。各地卫健委的要求、医保支付的细则、医院等级评审的标准，这些“非技术因素”往往直接决定了产品生死。我们花大量时间打磨的功能，可能因为某个省份的“白名单制度”直接被挡在门外。

第二，行业陷入“伪智慧”的同质化内卷。

以智慧病房为例，所谓“智慧”，目前不过是把传统呼叫系统做了“显示升级”——从床旁到走廊到护士站，信息在不同屏幕上流转，本质上还是信息的展示。鸿蒙加持后，底层代码换了，但“万物互联”的智慧在哪里？设备连上了，数据打通了，可决策支持呢？临床预警呢？医护工作流的实质性提效呢？

更深层的问题在于，我们很多医疗产品经理（包括我自己）对临床、对业务缺乏足够深的敬畏和理解。不是不想懂，是慢不下来。产品急着上、急着卖、急着拿回款，谁给你时间去蹲点临床、去观察护士一个夜班要起身多少次？

我们大多从未经历过系统化的临床素养培训。这就导致一个尴尬局面：用互联网的“快”，去做医疗的“重”，结果两边不靠。

AI时代，我看见了一套不一样的“工作流”

最近在微博上看到一段话，讲AI时代PM的工作流变了，我读完心里咯噔一下。

原文大意是：

以前做产品，默认底层技术是稳定的。但现在AI模型更新换代太快，老套路不管用了。新的模式是：规划要“短平快”，与其搞长周期路线图，不如多跑几个小实验；少写文档，多搞Demo和评测——现在用工具手搓一个能跑的原型门槛极低；每次新模型出来，就把以前因为能力不够搁置的旧想法翻出来重新试；系统越简单越好，复杂了bug就成倍增加。

我盯着这段话想了很久。

如果把这套逻辑直接搬到医疗ToB领域，能行吗？肯定不行。医疗有合规底线、有临床验证门槛、有患者安全红线。但反过来想，如果完全拒绝这套逻辑，我们会不会正在被“旧思想的惯性”拖死？

我们在智慧病房产品里，还在按部就班地写几百页的PRD、做完美无缺的原型图、规划长达一年的产品路线图。可技术底层在变，临床场景在变，政策环境在变。等到我们文档写完、评审通过、开发上线，可能AI又往前跑了三代，客户的需求又变了。

三、医疗ToB产品经理，需要建立“双轨制”能力

我的思考是：AI时代的医疗ToB产品经理，不能再固守单一方法论了。我们需要建立一种“双轨制”能力——用AI的“快”去试错和探索，用医疗的“慢”去沉淀和验证。

具体来说，可能是这样：

第一，把“小实验”纳入产品规划的正规军。

以前我们做规划，喜欢画大图、讲大故事。现在能不能换个思路：每个季度，强制留出20%的资源，去做几个“不计入KPI”的小实验？比如用AI能力快速搭一个临床辅助决策的Demo，拿到护士站去让护士用两天，看她们的真实反应。行就继续投，不行就果断砍。不要等到大版本上线才去验证。

第二，从“文档驱动”转向“原型驱动”。

我并不是说PRD不重要。但在AI时代，一段能跑的代码、一个可交互的Demo，比几十页的文档更能让开发、测试、甚至临床客户理解你的意图。尤其对于医疗产品，很多场景的痛点是无法用文字说清的。护士长跟你说“这个交互不好用”，你写进文档里，开发还是不知道改什么。但你给她一个可操作的原型，她点两下就能告诉你哪里不对。

第三，建立“技术敏感度”，而不是“技术依赖”。

每次大模型更新，我都会去翻一翻以前因为“技术做不到”而搁置的需求清单。这不是追热点，而是重新审视哪些临床场景可以被重新激活。比如以前想做护理记录的语义化分析，因为NLP能力不够放弃了。现在能不能再试试？以前想做用药提醒的个性化推送，因为规则太复杂搁置了。现在有没有新的可能性？

第四，用“极简架构”对抗医疗系统的复杂性。

做医疗产品的人都知道，医院的系统复杂得让人绝望。HIS、LIS、PACS、EMR……每多对接一个系统，出问题的概率就翻倍。做智能体或AI能力的时候，我越来越倾向于：找到那个最简单、能跑通的法子，先跑起来，再迭代。 不要一上来就想着“大而全”的中台方案，那种东西在医疗领域往往落地即失败。

最后

从临床一线走到产品岗位，五年来我最大的体会是：医疗产品经理这个角色，最怕的不是不懂技术，而是失去了对临床的感知力，同时又固守着一套过时的方法论。

AI时代，技术迭代的速度远远超过我们写文档的速度。如果我们还在用“旧思想”走新道路，那就真的是“拿着旧地图，找不到新大陆”了。

我并不觉得自己找到了答案。这篇文章更多是把自己最近的困惑和思考整理出来，希望能和同在这个赛道上的朋友们一起碰撞。

医疗ToB这条路本来就难走。但也许，正是因为它难，才更需要我们这些既懂临床、又做产品的人，去找到那条真正能走通的路。

共勉。