ARTICLE · 1013199
传统医疗软件公司转型AI,研发开始提防产品:AI时代的新型协作困局
点击上方蓝字，关注李歌然，一起共探医疗AI
引言:
很多医疗软件公司都处在一个最拧巴的阶段：一半传统软件项目在维稳交付，一半AI产品在摸索转型。团队、流程、岗位权责都还停留在传统软件开发时代，但工具、生产方式、交付逻辑已经彻底AI化。也正是这种新旧交替的过渡期，诞生了一个非常微妙、却普遍被忽视的职场现象：研发开始刻意提防产品经理。这种提防，不再是早年“需求来回改、PRD写不清”的老矛盾。真正的导火索，是WorkBuddy、DeepSeek Harness这类AI智能体工具的普及。现在的研发，不再单纯靠人力敲代码、查bug、做重构。他们可以借助Agent工具自主完成仓库分析、批量代码改造、自动调试、文档生成、任务拆解，甚至独立跑通小型功能闭环。工具抹平了大量技术门槛，彻底模糊了“产品该做的事”和“研发能做的事”的边界。于是在转型中的医疗软件团队里，默契被彻底打破：研发越来越习惯私下用AI工具闭环工作、刻意屏蔽产品，沟通留一半、进度藏一半、技术细节瞒一半，对产品的介入极度敏感、处处提防。这不是私人恩怨，而是传统团队AI转型期，岗位价值重分配带来的必然博弈。
01
提防的原因
1. 怕被替代
传统医疗软件时代，产品不懂底层代码、不懂架构逻辑，即便想插手开发也无从下手，研发的技术壁垒是天然的“护城河”。
但现在不一样了：AI工具把技术门槛降到了“看懂即会用”的程度。
只要产品经理愿意花时间，借助Agent工具就能看懂代码结构、梳理开发逻辑、判断功能可行性、甚至生成基础代码初稿。
尤其现在很多医疗AI产品本身就懂临床业务、懂场景痛点，一旦叠加AI工具能力，很容易直接介入开发环节。
对于还处在传统转型心态的研发来说，这是最直观的危机：原本只有自己能做的技术落地工作，现在产品靠工具也能做。
他们心里会本能产生焦虑：以后简单开发、需求拆解、文档梳理的工作，都会被AI+产品替代；自己的核心价值被稀释，话语权被削弱，甚至沦为单纯的“修bug工人”。
所以他们选择提防、封闭、私用工具不公开。
本质是通过信息差守住技术壁垒，保住自己在团队里的不可替代性。
2. 怕背锅
处在转型期的医疗软件公司，最大的问题是制度滞后于工具。
团队一边跑传统软件的老流程：PRD评审、需求排期、迭代复盘、责任到人；一边用AI新工具：自动化开发、智能任务拆解、工具辅助落地。
但公司没有明确规定：AI产出的代码、工具生成的方案、自动迭代的功能，出错谁负责？
传统模式下，需求错了是产品的锅，实现错了是研发的锅，权责清晰。
但现在研发用DeepSeek Harness重构代码、用WorkBuddy梳理需求，一旦出现医疗软件逻辑漏洞、数据合规问题、功能bug，追责会变得极其模糊：到底是产品需求不合理，是研发工具使用不当，还是AI生成内容本身有缺陷？
转型团队最不缺的就是推诿和背锅博弈。
工具是研发用的，但需求来源于产品，边界一旦模糊，最后背锅的一定是执行落地的研发。
为了规避无妄风险，最好的办法就是提防产品、减少产品介入、不公开工具使用细节、不共享AI落地过程，尽量让自己的工作链路“独立闭环”，划清权责界限。
3. 怕产品“拿着AI能力向上抢功”
传统软件业务增长见顶，公司所有资源、注意力、考核重心，全部向AI新业务倾斜。
对于团队所有人来说，AI项目的成果，就是职场晋升、绩效评级的核心筹码。
在AI工具的加持下，项目落地难度大幅降低，很多原本需要研发攻坚的工作，现在工具可以快速完成。
这就让研发产生了强烈的不安全感：如果产品经理学会用Agent工具介入开发、参与落地，最后项目成功上线、数据达标，产品很容易把“AI工具落地、效率提升、功能迭代”的功劳全部归到自己的需求设计和方案规划上。
而研发只会被定义为“工具执行者”，辛苦落地的工作被弱化、价值被隐形。
这种转型期的资源争夺、功劳焦虑，是研发提防产品的核心隐性原因。
他们宁愿自己悄悄用工具高效落地、低调迭代，也不愿和产品协同共享，生怕产品借AI工具的风口，稀释自己的技术价值、抢占项目功劳。
02
提防的后果
很多产品经理会觉得困惑：研发自己用AI工具提效、闭环工作，不打扰、不拉扯，难道不是好事？
实则不然，研发对产品的提防与封闭，是传统团队AI转型最大的内耗，尤其在容错率极低的医疗软件赛道。
医疗AI产品的核心是临床合规、场景适配、安全可控，绝对不是单纯的代码堆砌和功能实现。
研发私用AI工具、独立闭环开发，最大的问题是：AI生成的逻辑容易脱离临床真实场景、忽略医疗合规红线、适配不了医院复杂的落地环境。
DeepSeek Harness可以优化代码结构，但判断不了医疗流程是否合规；WorkBuddy可以快速拆解任务，但识别不出临床场景的隐性痛点。
当研发刻意提防、屏蔽产品的业务介入，就会出现典型的“AI自嗨式开发”：
技术上流畅高效、迭代速度极快，但落地到医院临床、对接传统软件业务时，全部水土不服，要么不符合诊疗流程，要么存在合规漏洞，要么无法和原有系统兼容。
最终结果就是：迭代越快，返工越多；工具越高效，浪费越严重。
转型团队的AI迭代，陷入“技术自闭环、业务不落地”的死循环。
03
可能的化解办法
要打破这种对立，我觉得不用讨好研发，强势夺权也可能费心费力，不适合非中层的产品经理，每个公司的情况不一样，以下是比较理想的做法，供参考：
1. 主动划清边界
作为医疗AI产品，你的AI工具使用场景，永远聚焦业务端：用AI梳理临床需求、核对合规条款、拆解场景痛点、复盘落地问题、优化产品流程。
而技术端的AI使用，包括代码重构、模型调试、仓库优化、测试落地，全权交给研发负责。
明确传递协作原则：我不抢你的技术活，你别忽视我的业务底线。
产品不借助AI跨界干预技术实现，研发不借助AI闭门脱离业务场景，双向守界，才能消解研发的替代焦虑。
2. 公开工具协作逻辑
转型团队的很多矛盾，都源于“信息不透明”。
研发偷偷用工具、藏进度，本质是怕信息公开后，价值被产品收割。
产品可以主动牵头，统一团队AI工具使用规范：明确AI产出内容的归属、责任划分、功劳分配。
比如规定：AI辅助的业务方案、场景梳理归产品负责，AI辅助的代码开发、技术落地归研发负责，权责清晰、功劳分明。
当你主动把规则摆在台面上，不再模糊争抢、不再隐性博弈，研发的提防心理会自然消解。他们会明白：开放协作，比闭门防备更能保住自身价值。
3. 产品定位转型
医疗软件转型AI，最大的风险是AI工具快速迭代带来的合规风险、场景风险、兼容性风险。
研发借助AI工具高效开发，很容易忽略医疗行业的特殊性：临床流程的严谨性、数据安全的合规性、新旧系统的兼容性、医患使用的安全性。
产品经理的核心价值，就是守住这最后一道防线。
PM需要将复杂的医疗业务逻辑、临床路径和合规要求，转化为AI Agent能够理解的上下文和验收标准。
例如，当研发使用Workbuddy搭建一个“智能随访Agent”时，PM的价值不在于规定界面的颜色，而在于定义：Agent在什么情况下算成功？遇到患者情绪崩溃时，Agent的回复底线在哪里？哪些医学名词绝对不能被AI篡改？通过训练Agent理解业务，审核Agent的输出是否符合临床逻辑，PM将自身的经验转化为不可替代的“业务导师”角色。
当PM能够用Agent听得懂的语言去定义规则时，研发的“提防”就会转变为对PM专业判断的依赖。
主动帮研发筛查AI落地的业务风险、校验工具产出内容的场景适配性、衔接传统软件老业务与AI新功能，帮研发规避背锅风险、减少返工成本。
当你从“只会提需求的旁观者”，变成帮研发规避风险、承接业务压力、兜底落地结果的合作者，提防就会变成信任，对立就会变成共赢。
04
写在最后
传统医疗软件团队的AI转型，注定是一场阵痛的重构。
随着AI的发展（未来也只会越来越强），确实打破了沿用多年的岗位分工，让产品与研发的能力边界变得模糊，催生了提防、猜忌、对立的职场矛盾。
但我们必须看清：AI可以抹平技术操作门槛，但永远替代不了产品的业务判断力、场景洞察力、合规把控力，以及在业务、技术、临床多方之间做权衡的能力。
转型期的摩擦与提防，很多时候不是针对我们个人，而是新旧生产方式碰撞带来的集体焦虑。
不必因为研发的防备就陷入自我否定，也不必急于去证明自己。
不必对抗边界的模糊，不用纠结一时的人际内耗。
对于我们医疗AI产品经理而言，当下的核心课题，不是学会用AI抢研发的工作，而是在模糊的工具时代，守住自己的核心价值、理清新的协作秩序、化解团队转型焦虑。
让我们一起跳出内耗，成为AI时代不可替代的复合型产品人才。
END
作者想说
你好，我是李歌然，一个临床专业出身的医疗AI产品经理。
做这一行越久，越觉得医疗的“慢”和AI的“快”需要理性的平衡。
在这里，我不追热点、不制造焦虑，只记录我的一线观察、产品思考、落地复盘、行业变化。
如果你也关注医疗AI的进程，关心技术如何切实赋能医生与患者，欢迎关注我。
让我们抛开噱头，用临床的理性和产品的逻辑，一起见证这个行业的真实变迁与成长。
点击下方名片，关注【李歌然】