惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
小众软件
小众软件
The Cloudflare Blog
博客园 - 【当耐特】
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Visual Studio Blog
量子位
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
美团技术团队
S
SegmentFault 最新的问题
宝玉的分享
宝玉的分享
博客园 - 叶小钗
月光博客
月光博客
Apple Machine Learning Research
Apple Machine Learning Research
T
Tailwind CSS Blog
博客园 - 聂微东
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
J
Java Code Geeks
Y
Y Combinator Blog
D
Docker
Microsoft Azure Blog
Microsoft Azure Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
医疗AI中的交互体验
来都来了 · 2026-04-06 · via 人人都是产品经理

当AI遇上医疗诊断,如何平衡效率与责任成为关键挑战。一位产品经理回顾了自己设计的医疗AI辅助系统,通过‘人造摩擦力’与数据可视化方案,巧妙解决了黑盒信任与权责划分问题。这个案例揭示了优秀交互设计的本质:不是追求炫技,而是构建多方共赢的服务闭环。

最近沉溺于工作无法自拔,工作内容逐渐偏向更底层与数据、安全、上链相关,好久没有动过我的脑子做设计相关的事情了,前两天面试的时候面试官提到了一个问题,关于我之前做的交互体验中我自己认为我做的比较优秀的交互有什么我是如何思考的?

很可惜在我面试之前我没有想过这个问题,所以可想而知这个问题我回答的非常的差劲,我是一个秩序性很强的人,所以对于这种好坏的问题我很需要明确的参考系,我才能确定什么样的设计是好的设计,直到过了两天我的医生朋友跟我吐槽他们的软件,我突然发现了一个问题,我有做过一个很不错的交互设计,且在我完成他的时候我的思考不是做一个优秀的设计而是做一个优质的服务流程。

简单聊一下这个交互是什么样子的,这个需求的是“我们用公司的AI让AI来生成诊断报告这样医生就不用全部数据都看了”,其实我现在的思考中也不知道还有什么其他的方式来设计这个业务线,我当时和现在想到的唯一解法就是我的这套交互逻辑,说下我的整体思考和功能的一些明确的限制。

功能限制

首先AI无法提供医疗级别的诊断信息,诊断是医生的事情,所以任何生成诊断性质的报告都需要医生签字,如果没有这种诊断对于企业来说是很灾难的打击,你无法判断提供的诊断是否正确,责任会蔓延,任何一个错误的诊断信息都可能会导致患者的风险甚至死亡

AI本身是一个黑盒,这个黑盒不可见,在一个不可见的状态下如何能确定Ai提供的处理结果是有价值的呢?

如果不用Ai来做让医生自己处理,庞大的数据量会拖垮医生他们无法完成其他的事情全部的时间被拖在处理这些数据上,医生的价值变得局限,软件功能的价值就消失了

所有给出的诊断信息在医学上是一定要有指南和已有的被验证的临床试验做背书的,如果这些都没有的话那也意味着你的诊断是不合规的

整体思考

基于以上的种种限制问题,我得到了一个非常明确的结论,这个功能的核心其实不是生成诊断报告而是让AI为医生减负,这种减负不能是无脑的确认的生成打印,这种高度流水化的减负,而应该是保证各个节点的主力都有对应的思考,在生成报告这个环节需要医生思考,在辅助提供建议和数据处理的环节AI要提供思考,但是到此AI是黑盒的问题依旧没有解决,AI给出了他认为的诊断建议,但是医生是不清楚这个诊断建议AI是如何判断的,我们需要在这个环节加入一些东西让AI的诊断建议有根有据,权责划分问题,这份用户直接读到的报告,究竟应该是AI给出还是医生给出,这个我思考了很久我觉得尊重医学和医疗本身我们应该让专业的人来完成如此专业的事情,他只能是医生给出,因为简单的一句本报告由AI生成是无法提升企业的公信力的,并且我们本身也有医生完成这个专业的事情没必要承担如此巨大的企业风险。

解决方式

之所以会想到这个功能设计确实很好,是因为我在跟我的医生朋友聊天的时候发现他们有很多报告的内容在他们的系统中是模版化的,医生确实就是点几下就好了,但是回过头来这个点几下的报告会成为他们沟通的阻碍,存在巨大的信息空白,医生有时候事情太多也不记得这中间他在判断的时候做了什么思考。

但在当时我设计这个交互时的想法是,既然我不希望医生完全不思考那我需要十分明确各个节点上的主要角色完成的内容是什么,针对AI,AI作为我公司的核心,他在处理大量的心电数据上有着十分卓越的能力,我们的训练数据的质量十分的高,已有数据集中的数据来源明确的疾病人群,通过造影得到的明确的病变位置,所以这个AI的精度其实是很达标的,在这个业务线上主要就负责处理大量的数据并对数据进行标注,提供建议辅助医生,医生看AI提供的这些信息最终得出一个诊断结果,帮助医生完成这个报告的输出。最终用户拿到医生提供的报告并根据医生的建议看是否需要医院进行进一步的影像检查。

两个功能完成需求

AI辅诊/散点图配置

将患者数据导入软件之后AI会提供全部数据的预览针对问题数据进行标注,整合标注的数据将AI的诊断建议与AI标注的的数据片段一并提供给医生(解决黑盒问题),医生可以快速的浏览不同标注的数据判断标注是否正确,通过散点图的图形判断异常数据的位置,偏离中轴线的数据需要着重查看,在中轴线上的数据可以整体浏览,并对AI提供的建议进行选择,医生可以快速的完成这数据的浏览和报告的生成

人造摩擦力

如果医生今天状态不好或者说他在使用的过程中对Ai的信任程度大大提升选择不看直接采纳怎么办?我做了一个限制,在生成报告的时候医生需要手动选择展现给病人的数据作为你提供的诊断依据,在生成报告的时候医生是需要一定的思考的这一段的异常数据是否能佐证我对这位患者的诊断,这种摩擦力可以让医生又好用的工具但不会完全依赖工具

回到开头,我觉得这个问题是一个很不错的问题,他让我重新思考我的工作内容中做过的事情,原来会有这些关注点可以去考虑,我在这种角度上对我之前的工作做了很多的复盘,当然我现在还是会认为这是一个基本的交互解法,并没有觉得这个解法有多惊艳,不过回想一下这个解法确实在多个角色多个角度为不同的人提供了不同的边界保障和便利,确实可以算作一个不错的交互并且提供了一个不错的服务,保证了多方的便利和利益。

本文由 @来都来了 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务