AI医疗产品的合规红线与资源边界如何平衡？本文通过一个诊后纪要生成器的实战案例，深度拆解当范围、进度、资源三条边同时锁死时的突围策略。从法务合规的硬约束到AI准确率的软瓶颈，作者揭示了如何用『降级阶梯』实现有计划的战略收缩，以及为什么『会认输』比硬撑更能挽救项目。
立项那一周，我被两堵墙夹在中间。
一堵是法务的。
我做的是一个 AI 诊后纪要生成器，给陪诊师和健康管理师用。患者看完病，那一堆乱七八糟的素材——化验单照片、医生口头叮嘱的录音、陪诊师手机里记的几行字，一次性丢进去，AI 整理成一份结构清楚的纪要。
这东西我拆成两层：分析层和建议层。分析层负责把来源材料里已有的信息抽出来、归类、标好出处，这层我们做出来了，跑通了。我真正想做的是建议层，AI 不光整理，还能像个健康助手那样给患者出建议：复诊注意什么、饮食怎么调、这个指标高了意味着什么。我一直觉得，这才是产品的灵魂。
法务一句话把我摁住了：AI 生成健康建议，不合规。我试着争辩，可两个理由都把我堵死了。一个是资质：给患者出健康建议本质上是医疗行为，得有执业医师资格证，模型再聪明也没这张证。另一个更要命，是担责。患者照着 AI 做，万一出事，谁负责？产品经理？算法？还是公司？这条责任链是断的，找不到那个能签字的人。
我脑子宕机了。是啊——谁来负这个责任呢？
争来争去，我还是得认：建议层，这个我最想做的东西，得砍。
第二堵墙是排期。
把建议层砍掉之后，剩下能做的功能按优先级排了一遍，结合组里所有人的时间和当下的资源，我算出一个让人心里发凉的数：就算每个需求都用最理想的方式实现，到上线那天，也做不完。
不是“差不多能赶上”，是“再顺也赶不上”。而这些是 P0、P1，不做产品根本没法用。
两堵墙，撞在同一周。这篇就讲，我怎么从这个“必死局”里把项目捞回来。先撂结论：我没加班，也没加人。说出来甚至有点怂——我提前想好了，这仗万一打不赢，该按什么顺序认输。
人一慌就爱瞎使劲。我强迫自己先停下来，回到那张最老的图，项目管理的铁三角：范围、进度、成本三条边，拉动任何一条，另外两条就得跟着动，否则牺牲的是正中间的质量。又要马儿跑又要马儿不吃草，这图里不存在。
我一开始还犯过个常见错：把“风险”当成铁三角的第四条腿。后来才想明白，风险不是一条边。范围、进度、成本是你主动权衡的约束；风险是从外面威胁这三者的不确定性，比如需求变更、人跑了、技术踩坑。它不在腿上，在整个结构外面。（现在 PMBOK 把三重约束扩成了六大约束，多了质量、资源、风险，但思想一样：一堆互相竞争的约束，牵一发动全身。）
把我的项目往图上一套，卡在哪一目了然：范围被法务钉死，进度被上线日钉死，资源就 5 个人、还都 50% 投入、满打满算 2.5 个人。三条边，全锁死。
这事我前前后后想了挺久，才算想明白一件事，也是这篇我最想分享的：当范围、进度、资源同时锁死，项目在数学上就是不成立的。这种局面下，“再努力一点就能做到”是幻觉。你只剩两个结局，要么有意识地松掉一个约束，要么不知不觉牺牲质量、或者到点砸掉交付日。
产品经理最该干的，不是默默扛着硬上。你得把这个“不可能”摆上台面，逼出一个有意识的取舍。
而我能在排期阶段就算出来，其实是好事。最怕的是上线那天才发现做不完。
回头看，法务那一刀虽疼，却帮我把范围想透了。被砍前我脑子里的范围是贪心的、模糊的；被砍后边界反而清晰：建议层是越界，移到 V2；分析层只搬运来源里已有的信息、一个字不新增，是安全区。于是 V1 收缩成一个“内部辅助工具”，AI 出待审核稿，人工复核，不直接交付患者。
这就是一次范围的“再切分”：不硬扛着全做，主动松掉范围这条边。但怎么切有讲究，我想明白两件事。
这里有个特实用的概念，叫 happy path：一切正常、不出错时，功能从头跑到尾那条最顺的主路径。功能真正费工的地方，常常不是 happy path，而是外面那圈“出错了怎么办”。所以赶期有个很狠的打法：第一版只做 happy path，先让“一切正常时能用”落地，异常兜底、边界、打磨全往后挪。
能用，先于好用。
判断一块该留核心还是后置，我常问三句：去掉它，主流程还能不能端到端跑通？能不能先用人工兜底？它是“能用”还是“好用”？
最典型的是音频输入。医生口头叮嘱要走语音转写，这条线技术上最不确定（识别医学术语容易错），合规风险也最大（原始录音带着隐私上云）。但它有个天然兜底：陪诊师本来就在现场听录音，大不了人工听一遍打出来。所以音频自动转写，对我来说就是个能随时降级、又不太伤可用性的功能。
唯一不能拆、不能降的，是那条红线：不编造、不新增来源外内容、AI 标识必须留、关键医疗字段标红了非医生不能跳过。这是合规的地板，砍什么都不能砍它。
范围理清，下个问题是节奏。我第一反应是瀑布：想清楚再一口气做完，听着稳。但瀑布在 AI 产品这儿，有个致命的水土不服。
瀑布假设需求能前期想清、效果能前期设计出来。传统软件确实如此，一个功能能不能实现基本是确定的，无非工作量大小。AI 不一样：AI 功能“能不能达到可用效果”本身就是未知数。我的纪要准确率能不能到 75%？口头建议抽得准不准？这些都是试出来的，不是设计出来的。你不真训一遍、调一遍、测一遍，没人敢拍胸脯。
所以 AI 产品天然该敏捷，该小步快跑。
但纯敏捷也有坑。我把所有工作分成了两类。
研究型：准确率能不能达标、语音转写选哪家、置信度算法怎么调，连“能不能成”都不知道。这类千万别塞进承诺式排期，你没法承诺“第三版准确率一定到 90%”。它该用时间盒，给两周，到点开个 go/no-go，行就继续，不行就换方案。
工程型：任务卡、上传、标红交互、PDF、权限、归档。这些活儿心里有谱、有明确验收标准，就是标准的敏捷开发，正常估点、正常排期。
很多 AI 团队的痛苦，就来自把研究当工程排：逼算法工程师承诺一个研究突破在第几周完成，然后看着它一延再延。我让两条轨并行：工程轨先搭一个能插拔模型的骨架，研究轨在骨架上反复试模型、调 prompt，两条轨在几个 go/no-go 闸门上同步。这套叫双轨敏捷，但名字不重要，重要的是分清楚：哪些事能承诺，哪些只能给个时间盒去试。
终于到那一周我真正做的、也最值钱的一件事。
面对一个数学上做不完的项目，多数人的本能是想办法做到：加班，加人，打鸡血。我偏偏反着来——提前想好，万一到点真做不完，该按什么顺序，有计划地认输。我管它叫“降级阶梯”。
为什么需要它？我把关键路径捋了一遍，真正决定生死的是 AI 准确率这条研究型的线，而它特别脆：调优窗口只有三周左右，还加不了人（调 prompt 没法五个人并行）；给模型打分的评测集本身也在关键路径上，还得占医生时间标注；2.5 个人的投入，少谁半天产能就掉一块，全程没缓冲。准确率达不达标，到节点才见分晓，而我几乎没有回旋的余地。
那与其到时候手忙脚乱地乱砍，不如现在就排好该砍的顺序，从最不疼的砍起，红线压在最底下，一格都不能碰：
你看这张表会发现个规律：前面好几档，本质上是同一件事，收范围，把准确率喂饱。
这是 AI 产品和传统软件最不一样的地方。传统软件想达标，是加功能、修 bug；AI 产品想让准确率达标，很多时候反而是做减法。模型在全部 9 个模块、全部科室上只能做到 70%，你把范围缩到 4 个模块、3 个科室、两种输入，它就能干到 80%。你没把准确率整体调低，只是把摊子收小，让它在小范围里够得着。
还有个细节：砍之前先诊断。别一刀切，先看是哪个模块、哪个科室、哪种素材在拖均值，再精准砍那几片。评测集本来就分了维度，正好告诉我从哪下刀。
但整张表里最重要的一句是：这张降级阶梯，得在立项前就和老板、法务一起敲定。不是等节点真出事了再现场恐慌谈判，而是提前把“如果到 X 时准确率只有 Y、就执行第几档”白纸黑字定下来。到点了，执行一个早就商量好的预案，而不是现场制造一个措手不及的意外。
（同一个逻辑，那一周我还顺手做了三件事：给排期硬加了一段时间缓冲，把最不确定的语音和 OCR 验证提到最前面，把评测集和医生标注单拎成一条有预算的轨。都是为了让风险早点见光，留好退路。）
现在回看法务那一刀，说实话，我从一开始的不服，慢慢变成了感谢。它砍掉的是我最想做的建议层，却逼我在最早就把两件事想清楚了：这个产品的边界在哪，出了事责任算谁的。一个连“谁来担责”都没想明白的 AI 医疗产品，就算硬做出来，也是个定时炸弹。
这趟下来我最想说的就一句：面对一个做不完的项目，会“有顺序地认输”，比硬撑着更值钱。把“到点上一个收窄版”变成立项第一周就拍好的预案，别让它成了上线前一周的事故。
最后留个问题给你：你有没有遇到过那种排期排完、心里咯噔一下就知道做不完的项目？后来你是怎么破的，砍范围、推期，还是硬扛过去了？评论区聊聊。
本文由 @Niney 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。