FDE,即 Forward Deployed Engineer,前线部署工程师。它深入客户真实业务现场,把AI能力转化为可运行、可验证、可审计的业务结果,并把一线经验沉淀为可跨项目复用的行业资产。
对于医疗、医药和医疗器械行业来说,AI真正落地不能只是“业务工作+AI”,而应该逐渐转变为AI Native。所谓AI Native,可以理解为:如果AI能力一开始就已经存在,那么这项业务原本应该怎么设计?
过去,我们往往是在原有业务流程上增加一个AI环节。比如研发实验结果出来之后,让AI辅助分析,工程师再在此基础上形成实验报告,接着完成质量体系记录,提交领导批示,然后设计下一步实验。这种模式本质上还是原来的工作流程,只是在其中增加了一个AI工具。
AI Native则不同
假设一次研发实验结束后,实验员、研发工程师、分管领导和AI共同进入一个线上会议空间。实验员和工程师分别表达实验过程中遇到的问题、观察到的现象以及个人观点;分管领导进行补充,并结合整体项目情况讨论后续研发路线;AI则实时调用企业知识库和历史实验资料,对讨论内容进行查漏补缺。讨论结束后,AI自动总结会议,形成实验记录和实验报告;根据当天完成的工作同步形成质量体系记录;再根据会议讨论结果整理出下一轮实验计划。
这样一来,AI不再是在实验结束之后才被调用的一个辅助工具,而是真正进入到日常研发的工作、分析、决策和执行路径中。在需要的时候,AI还可以随时调用历史上的每一份数据文件、实验记录和相关资料。
FDE的核心工作之一,就是把客户原本以自然语言表达的需求,转化为工程化、结构化、AI能够理解和执行的任务。
例如客户说:“我们的研发记录太乱,很多实验经验没有沉淀下来。”
FDE需要继续拆解:实验数据在哪里?实验过程如何记录?哪些内容需要形成实验报告?哪些内容属于质量体系要求?谁负责审核?历史数据如何调用?下一轮实验如何形成?
最终再把这些内容转化为AI能够执行的工作流。因此,FDE并不只是部署模型,而是在重新设计企业原来的业务流程,使AI真正进入业务运行体系。
国内企业实施FDE的现实条件
国内多数企业的数据底层仍然缺乏标准化治理。从这个角度看,业务越成熟、流程越稳定的企业,FDE反而越容易实现。中大型公司通常拥有比较稳定的研发流程、生产流程、组织架构和质量体系,因此具备更好的AI落地基础。但另一方面,大企业同样存在“船大难掉头”的问题。AI Native并不是在现有体系旁边增加一个新工具,而可能要求对原有组织框架、工作流程甚至质量体系进行重新设计。员工是否愿意改变原来的工作习惯,同样会成为实施过程中的重要阻碍因素。因此,更现实的方法可能不是一次性改造整个企业,可能是按照模块分步完成AI本地化。先从研发、质量、注册或者生产中的某一个具体模块开始,把一个场景真正跑通,再逐渐向其他场景扩展。通过这种方式形成“星火燎原”,最终逐步孵化出面向医药行业或者企业自身的模型、知识库和工作流,并让前面项目形成的经验持续复用,产生经验的复利效应。
站在小微企业的角度,这同样是一个机会。大企业虽然流程成熟,但组织调整成本高;小企业虽然基础相对薄弱,但决策链条短、调整速度快。一旦行业中出现比较成熟的AI解决方案,小微企业可以快速套用成熟方案,以较低成本建立研发、质量和管理能力,从而缩小与大型企业之间的差距。
法规既是阻力,也可能成为医疗FDE的优势
医疗行业AI落地绕不开法规。AI进入研发、生产和质量体系之后,新的工作形式如何适应现有法规要求,是摆在行业前面的一个重要问题。例如AI参与实验记录、质量记录和研发决策之后,现有质量体系如何认可这种形式,审评和监管又如何对这些过程进行检查,都需要新的规则和方式。但从另外一个角度看,AI也可能改变未来的监管模式。如果企业能够向审评或者监管部门提供标准化接口,在符合权限和数据安全要求的情况下,监管人员就可以更加直接地查看企业质量体系实际运行情况。原来更多依赖最终资料审核和飞行检查的方式,未来可能逐渐增加持续化的数字监管。监管工作的效率和灵活性也会随之提高。
而且,医疗行业本身执行严格的法规和质量管理体系,这反而天然为FDE提供了一定程度的标准化基础。因此理论上,一家企业的某一类FDE模式真正跑通以后,其中很多经验可以快速复制到更多同类型企业。
医疗行业更适合部分场景的私有化模型
基于医疗行业的数据安全、商业机密和监管特点,部分FDE场景可能更加适合部署本地化的私有模型。不同于面向所有领域的通用大语言模型,这类模型主要围绕医疗行业资料或者企业自身数据库、知识库和历史业务数据建立能力。随着企业内部人员不断使用和反馈,模型也可以逐渐更加适应企业自身的工作方式和行业需求。对于医疗行业来说,模型不一定需要什么都知道,更重要的是:懂这个行业,也懂这家企业。这种模式既有利于企业经验持续沉淀,在数据安全和监管上也更加容易建立边界。
从质量体系切入可能是一个重要场景
医疗行业中还存在一个比较典型的问题:很多企业把质量体系更多当成拿证需要完成的纸面工作,而不是贯穿研发和生产全过程的风险管理工具。某种程度上,这就类似于财务中的“阴阳账本”。企业真正运行的是一套流程,而为了质量体系和监管检查又形成另外一套记录。结果是监管端很难及时看到企业实际运行中出现的问题,企业内部也容易出现重生产、轻质量的情况。最终企业投入了大量人力维护质量体系,却未必真正提高了质量管理效率。FDE可以尝试解决的,就是把这种自然形成、依赖人工经验的业务过程,转化为标准化、AI能够理解并执行的任务。例如研发实验结束以后,AI不是等工程师重新整理一次资料,再补录质量体系,而是在研发工作发生的同时完成对应的质量记录。这样,研发、生产和质量就不再是彼此分开的几套体系,而是同一个业务过程中的不同记录和控制节点。这也可能是AI真正帮助医疗企业提高质量管理效率的一个重要方向。AI落地是医疗行业提高运营效率的重要手段之一。
而FDE的工作,不只是帮助企业部署一个模型或者开发一个Agent。
它更重要的作用,是从医药行业真实工作的底层出发,把企业原本依赖自然语言、个人经验和人工协作完成的工作,转化为AI能够理解、能够执行、能够记录和能够审计的任务。让AI真正进入研发、生产、质量和管理的日常工作路径。最终达到:提高工作效率,加强质量监管,降低生产风险,为研发减负提效。而当一家企业中跑通的经验能够不断沉淀,并复制到更多同类企业时,FDE带来的价值也就不再只是一次项目交付,而开始形成整个行业的经验复利。
以我所在的体外诊断IVD行业看,待市场出清后潜在的客户全国大约有200-500家,
以IVD为例做一个医疗、医药与医疗器械行业FDE全流程操作手册
适用:医院 / 企业 / 医疗器械企业 / AI 平台与解决方案团队
使用原则:高风险业务坚持 Human-in-the-loop,所有关键输出可追溯、可审核、可回滚。

01适用范围与基本原则
本手册适用于医院、医药研发与临床运营、IVD 和医疗器械企业的 AI 落地项目。优先覆盖“知识密集、流程清晰、人工成本高、可以人工复核”的场景,再逐步进入高风险决策支持。

风险分层

02FDE 组织架构与职责

03全流程总览与 Stage Gate

成熟项目的方向是:FDE 人工驻场减少、配置比例提高、客户自助增加;若第 10 个同类客户仍需从零做一遍,说明模式仍是项目制。
04 STAGE 0项目准入
在投入 FDE 前,先判断业务价值、AI 可行性、风险和跨客户复用潜力。

4.1 五维准入评估

4.2 No-Go 条件
• 无法明确业务责任人和最终验收人。
• 没有合法可用的数据或无法建立安全测试环境。
• 输出不可验证,却计划让 AI 自动做高风险决策。
• 客户只购买人天定制,且不存在跨项目复用空间。
• 需求边界持续漂移,无法形成首个可测量闭环。
05 STAGE 1客户发现与流程映射
进入现场理解“实际怎么做”,而不是只听“客户想要什么功能”。
5.1 访谈对象

5.2 Shadowing:必须画出真实流程
示例:IVD 研发场景可从“实验设计 → 实验执行 → 仪器数据导出 → Excel 整理 → 统计分析 → 异常判断 → 实验总结 → 下一轮实验设计”逐步观察。FDE 要找的不是单个功能,而是可被 AI 重构的工作流。

06 STAGE 2场景定义与 Baseline
选择范围小、价值高、可量化的首个场景,并记录“人现在做得怎么样”。
6.1 首场景选择

6.2 Baseline

没有 Baseline 就无法证明 AI 的商业价值,也无法判断“看起来好用”是否真的优于原流程。
07 STAGE 3Demo / PoC
用真实或近真实输入快速跑通核心链路,提前暴露数据、模型和流程风险。
7.1 Demo 设计原则
• 两周左右形成可运行版本,不以 PPT 作为 PoC 终点。
• 先覆盖 60%–70% 高频核心路径,明确剩余长尾和已知缺口。
• 输出必须可被领域专家核验。
• 尽早使用真实字段、真实文档格式和接近真实的系统接口。
• Demo 结束时要能回答:业务指标有改善空间吗?客户愿意继续验证吗?
7.2 IVD Demo 示例

08 STAGE 4真实数据验证与 Golden Dataset
把 Demo 从“能跑”推进到“知道何时会错、错了怎么办”。
8.1 Human-in-the-loop 验证记录

8.2 Golden Dataset 构成
• 高频正常案例:覆盖日常主路径。
• 典型异常案例:覆盖过去真实发生的问题。
• 边界案例:最容易误判、信息不足、术语歧义。
• 红线案例:用于验证 AI 是否会越权给出诊断、治疗、放行等最终决定。
• 回归测试:任何版本升级后必须重复执行。
09 STAGE 5生产化与上线验收
把模型能力部署成可持续运行的业务系统,而非停留在 Demo。
9.1 生产化最低能力

9.2 上线验收四类指标

高风险场景上线 Gate 必须包含专业、RA/QA/隐私或等效治理角色的明确批准。
10 STAGE 6行业反馈与 Echo 评审
把客户特有发现抽象成可复用行业能力,形成真正的前线学习闭环。
10.1 Delta 行业能力反馈单

10.2 Echo 评审分级

Echo 应按固定节奏批量评审和发布版本,避免“每来一条反馈就改基线”。版本必须附变更日志、影响范围、回归测试结果和 Delta 使用指南。
11 STAGE 7规模化复制与客户自助
让同类项目从“开发为主”逐步转向“配置为主”,并把简单工作交给客户或生态伙伴。
11.1 成熟度方向

11.2 客户自助化目标
• 客户可自行配置简单 Workflow、规则和知识库。
• 客户 IT 可进行常规账号、权限、监控和简单 Connector 配置。
• 生态伙伴可以基于行业基线独立服务中长尾客户。
• FDE 仅进入新场景、复杂集成、高风险决策支持和行业版本扩展。
12风险、数据与合规控制
12.1 数据隔离模型

对客户的标准解释:我们带走的是“行业怎么理解问题”的抽象方法,不是您的患者数据、订单数据、配方、业务参数或客户名单。
12.2 强制人工升级条件
• 涉及最终诊断或治疗决策。
• 涉及质量放行、CAPA 关闭、正式注册提交。
• AI 无法给出依据或来源冲突。
• 输入数据质量异常、权限不确定或信息不足。
• 模型输出与企业规则、法规或专业判断冲突。
• 出现重复严重错误或超出已验证边界。

夜雨聆风