1. 为什么我会专门飞一趟长沙FDE的“价值”问题正在被重新定义长沙同盟这场企业级AI落地圆桌主题叫“基于价值驱动的FDE实践”。说实话看到这个标题的第一眼我就决定要飞过去。原因很简单“价值驱动”这四个字恰好打在我这段时间的痛点上。先交代一下背景。我自己过去大半年一直在做企业级AI落地的咨询和交付工作接触了大量真实客户。坦白讲2025年初的AI项目和2023年、2024年已经完全不是一回事了。两年前大家关心的是“大模型能做什么”现在大家关心的是“大模型到底怎么才能在企业里真正跑起来、产生看得见的业务收益”。这种转变带来一个很直接的结果市场对FDEFeature Driven Engineering特性驱动工程这个角色的需求暴涨。你会发现招聘网站上冒出大量“FDE工程师”的岗位报价也从最初的两三万一路涨到令人咋舌的程度。但问题在于大多数企业对FDE的认知是模糊的很多人以为“FDE就是写提示词的人”“FDE就是会调大模型API的人”。这种认知偏差直接导致大量FDE项目陷入“做了很多功能但业务方不买账”的尴尬境地。我带着两个问题进了会场。第一FDE的工作方法到底怎么才能从“交付功能”转向“交付价值”第二企业在评估FDE工作成效时除了模型准确率、响应速度这些技术指标还能看什么因为我自己私下遇到过好几次这样的场面模型效果明明跑得很好线上准确率也达标了但业务部门用了一个礼拜就弃用了。问题出在哪里在圆桌上找答案。1.1 FDE到底是个什么角色在深入聊圆桌内容之前我得先把FDE这个角色说清楚因为后面所有的讨论都建立在这个共识之上。FDE从字面上理解是“特性驱动工程”但在企业AI落地语境里它更像是一个复合型角色既懂业务场景又懂AI技术边界能够把模糊的业务需求拆解成可执行、可验证、可持续迭代的AI任务。你可以把它理解成“AI时代的翻译官项目经理测试工程师”三重身份的结合体。我见过不少团队模型是科学家的活开发是工程师的活业务分析是产品经理的活最后大家各干各的谁都不对最终价值负责。FDE要做的恰恰是把这条断裂的链路重新接上。它不是某一个具体岗位的名称更准确地说它是一种工作方法以“最终业务价值”为牵引反向推导需要什么样的数据、什么样的模型、什么样的流程改造、什么样的评估体系。这个界定在圆桌开场不久就得到了印证。主持人让每位参会者用一句话介绍自己为什么来一圈下来超过半数的人都在讲“之前做模型项目做得很憋屈功能做完了价值没落地”。可见这已经是行业通病不是某一家企业独有的困境。1.2 我带着两个问题进会场会场设在长沙一个园区里不大圆桌形式大概二十多个人。参会者里有做制造业数字化的技术负责人有零售企业的AI中台负责人有给金融机构做知识库服务的创业团队也有几个和我一样做咨询和交付的自由顾问。整体氛围很务实没有人聊宏大叙事基本都在聊具体的坑。我当时在便签上写了两个问题放在桌面上第一个问题当业务方说“我要一个AI助手”的时候FDE应该怎么把这个需求翻译成真正可落地的任务清单因为“AI助手”这四个字实在太含糊了它可能是一个客服机器人可能是一个内部知识库问答可能是一个数据分析入口也可能只是一个样子货。大多数项目从一开始就没想清楚所以做着做着就变形了。第二个问题价值驱动落到日常开发动作上到底有几个可执行的原则我一直觉得“价值驱动”这个词太容易被喊成口号。谁都知道要做有价值的东西但怎么在每一个技术决策里体现“价值优先”是需要具体方法的。比如提示词写得好不好要不要为了多2%的准确率多花三倍算力预算这些决策单看技术指标是永远算不清楚的。这两个问题在之后的几个小时里都有了答案有些答案甚至来自于我完全没想到的角度。2. 圆桌聊出的第一波共识FDE不是写提示词的人而是组织人机协作的人圆桌讨论到第二环节的时候有位做制造业信息化的老哥说了一段话我记性很深。他说“我们客户上了大模型之后第一件事是搞了个内部Chat让大家有问题就问。结果用了三个月活跃度越来越低。后来我们复盘发现员工不是不想用是问了问题之后还得自己拿着答案去系统里操作。AI只给了建议没帮着把事情办了。这就很尴尬。”这段话引起了现场很多人的点头。顺着这个点往下聊大家逐渐达成一个共识FDE的核心工作不在于把提示词调到多完美不在于把模型性能压榨到多极致而在于设计“人和AI之间到底怎么分工、怎么配合、怎么形成闭环”。也就是说FDE实质上是在做“人机协作的组织设计”和“任务流重构”的工作。这个视角的转变很有冲击力。如果你把FDE理解成“写提示词的人”那你的产出就是一串串指令文本如果你把FDE理解成“设计人机协作流程的人”那你的产出就是一套完整的业务流程改造方案提示词只是其中最小的一个环节。2.1 一个被反复提起的判断工具再强流程不跟着改落地就是PPT现场有位做零售的嘉宾分享了一个特别典型的失败案例他们给门店店长做了一个AI经营助手大模型基于门店的销售数据、库存数据、天气数据能自动生成经营建议。模型效果相当不错建议的质量也很高。但上线之后店长们基本不用。原因很简单店长每天的工作流是固定的早上看一遍系统报表中午处理补货晚上对账。这个AI助手是一个额外的独立应用店长需要额外打开一个页面额外输入自己的门店编号额外读一段建议然后再自己去ERP系统里操作。每一步都增加了工作量没有嵌入到原有工作流里面去。这个案例特别说明问题。大多数AI项目失败不是死在模型效果上而是死在流程改造上。FDE要做的不是“在现有流程旁边加一个AI功能”而是重新审视整条业务流程找到哪些环节可以交给AI做、哪些环节仍然需要人来决策、AI的产出如何无缝衔接进下一个动作。所以当时圆桌上有人总结了一句话AI落地的难度不在于技术有多深而在于你要动的是别人已经跑了十几年的流程。这句话听着朴素但做项目的人应该都能感受到分量。每一个流程改动背后都是习惯的改变、KPI的调整、权责的重新划分。FDE如果只盯着技术必死无疑。2.2 从Chat到Agent企业真正愿意买单的是“任务闭环”顺着“流程改造”这个点往下聊话题自然转向了Agent。2025年AI圈最热的概念之一就是AI Agent热搜榜上“AI agent”“AI Agent verilog代码”这些词也持续走高。但在企业场景里Agent到底意味着什么圆桌上大家的共识是Agent不是简单的“多轮对话”而是“从回答问题到执行任务”的跨越。举个例子。传统Chat应用是“用户问-模型答-用户自己动手干活”的模式。Agent的工作方式是“用户提目标-Agent拆解任务-调用工具或系统执行-返回结果并汇报”。后者才是企业真正愿意付费的形态。因为企业买AI买的不是“知道答案”买的是“事情被办妥”。制造业案例在那个环节被反复提及。同样是“查某个工单的进度”Chat应用会给出一段文字说明但Agent可以直接调用工单系统API、查询数据库、生成进度摘要、下一步自动发送给相关负责人。这个差距对于使用者来说是本质性的。但Agent也带来了新的问题。责任边界怎么划权限怎么管错误怎么追溯一位做金融服务的参会者直接说“我们不敢让Agent直接操作核心系统万一它理解错了指令修改了不该改的数据谁负责”这个问题在场内引发了激烈讨论最终大家认同的方向是在企业场景里Agent必须分层分级。低风险操作可以全自动高风险操作必须人审FDE要和业务方一起制定“自动化边界矩阵”。这个矩阵才是价值驱动从口号落地的第一个工具。2.3 FDE应该在哪一个环节介入需求分析而不是技术实现聊完Agent话题又回到了“FDE什么时候介入项目最合适”。这里基本没有争议所有人的答案都一致越早越好最好从需求分析阶段就介入而不是等技术方案定了再过来优化提示词。我当时提了个问题为什么很多企业习惯在项目后期才找FDE大家分析之后给出了几个原因。一是企业对FDE的认知还停留在“提示词工程师”这个层面觉得前期用不到二是很多企业内部的业务分析师并不了解AI的能力边界提需求的时候只会说“我要一个智能XX”完全没有想过数据从哪来、准确率怎么算、失败怎么办三是项目预算和考核机制的问题业务方和IT方的目标不一致中间缺一个能对最终价值负责的人。这个讨论对我触动很大。FDE如果站在需求分析阶段的入口他能做的是把“业务目标”翻译成“AI可执行的任务”同时把“任务实现的约束条件”翻译回“业务的取舍理由”。这是个双向翻译的过程也是FDE价值最大的地方。如果项目都快做完了才让FDE介入那充其量只能做点局部优化已经很难扭转整条交付链条的方向了。功能做不完可以砍但方向错了做出来的东西再好也是白费。价值驱动第一步就是在需求阶段把路走对。3. 三个现场案例把“价值驱动FDE”从口号拉回地面说实话圆桌前半程聊的东西虽然方向正确但还是偏理念。真正让我觉得这一趟没白飞的是后半程大家分享的具体案例。这些案例里的每一个细节都印证了一件事价值驱动不是一种态度而是一套具体的做事方法。我挑三个印象最深的写下来。3.1 制造业案例从内部问答到生产计划更新闭环第一个案例来自一家做离散制造企业的数字化服务商。他们客户上了大模型系统第一版做的是企业内部知识问答涵盖设备操作手册、工艺文档、质量管理规范等。上线后效果还可以工人查文档方便了但整体价值感不强——它解决的只是“查资料难”的问题而这些资料之前其实也存在于OA系统里只是入口不够智能而已。FDE介入后做的第一件事不是优化问答而是和车间主管蹲了两天把生产计划调整这条流程完整走了一遍。最后发现车间调度员每天花在“确认可替代设备状态”上的时间特别长。传统做法是调度员根据经验打电话问各个班组长“明天哪台设备能空出来”有时候还得到现场去看。FDE把这个问题拆成了三个子任务读取设备台账获取实时状态、结合生产排程判断可替代设备、生成一份带置信度的建议清单给调度员确认。整个流程从“不确定性的人工询问”变成了“有依据的即时推荐”调度员只需要在界面上点击确认或修改。这个案例最启发的点在于它从头到尾没有换更牛的模型也没有堆更复杂的提示词。真正的变化是把一个模糊的业务痛点拆成了具体的技术任务并且嵌入了原有的工作流。调度员不需要额外打开什么AI平台所有的信息直接呈现在他日常用的排程系统界面里。这就是价值驱动的具体表现不追求AI做多么惊艳的事而是让AI把业务链条里最耗时的中间环节填平。3.2 中小企业案例没有历史数据智能客服照样可以从0起步第二个案例是一家做企业服务SaaS的公司客户是几家完全没做过任何客服数字化的中小企业。这些企业的共同特点是没有历史客服工单、没有整理过FAQ、甚至连标准的话术模板都没有。绝大多数AI公司遇到这种情况都会摇头因为大模型知识库再怎么强也得有“知识”可以喂。接这个项目的FDE用的是另一套打法。她做的第一步不是找数据而是拉着客服主管做了三天的“知识蒸馏”。每天把客服接待客户的原始记录微信聊天记录、电话录音转写文本拿出来一条一条过把高频问题、标准答案、分类维度全部人工梳理出来。然后在这个基础上构建了第一版知识库语料大概两百多条种子数据。接着她用“规则检索大模型生成”的混合方案先用规则匹配识别用户意图匹配不上再走向量检索检索不到再交给大模型生成兜底回答。三个层级逐级递进并且每一层都设置了转人工的触发机制。这个案例让我意识到很多FDE项目卡在“没有数据”这一步就停住了但真正的问题是“没有采集数据的机制”。FDE要做的不仅是技术实现还包括帮企业建立数据沉淀的闭环每一次客服会话结束后系统自动标记哪些是落库的语料、哪些是需要人工补充的空白点。没有历史数据不可怕可怕的是上线三个月之后还是没有数据。3.3 RAG落地中的术语注入被很多人忽略的领域知识问题第三个案例是圆桌间歇时有人私下聊起来的但我觉得特别有价值因为它戳中了很多RAG项目的通病——术语不识别。那位朋友做的是给一家机械制造企业搭建内部技术文档问答系统。文档都是技术图纸说明、工艺规范、故障排查手册。他们把文档切分之后做向量化然后接了大模型做生成回答。测试的时候发现专业术语和缩写经常被模型理解错。比如某个型号代码“HP-300A”在文档里既可能指“液压泵型号”也可能指“热处理工艺参数”。还有一个更头疼的问题同一台设备不同车间的人叫法不一样有人叫正式型号有人叫外号。搜索结果自然是一塌糊涂。FDE的解决方案是构建了一个领域术语注入层。具体做法是先和企业的工艺工程师、维修工程师开了四次梳理会把高频术语、同义词、简称、别称全部整理成一张术语表。然后在文档切分阶段做术语感知切分确保关键术语和它的上下文不会被分到不同切片里。在检索阶段先把用户query做术语映射比如“三号机台”自动关联到正式设备编号再去做向量检索。这一套做完系统的检索准确率提升非常明显。这个案例给我的触动在于很多人做RAG的时候脑子里想的是怎么调整Embedding模型、怎么优化向量数据库参数却忽略了最基础的东西——你的用户称呼一件事物的方式和你的文档里记录的方式可能完全不一样。这个gap只有懂行业、懂业务的FDE才能填上。这恰恰又一次验证了FDE的核心是领域知识的工程化而不是纯粹的技术工程化。4. 现场一致认同又反复踩坑的五个工程能力清单案例聊完之后主持人让大家做了一个小的“踩坑投票”环节。每个人把自己过去半年在AI项目里最痛的坑写在一张便签上最后归类统计排在前几名的坑出奇地一致。我把它们整理成了一份“企业AI落地工程能力清单”可以说是这场圆桌最有实操价值的部分。这里我不准备做任何修饰直接按现场总结出来的内容写。这些条目的共同特征是做的时候不起眼忽略了就要返工。4.1 需求拆解能力把业务问题翻译成可验证的AI任务这是被提到最多的一种能力几乎每个人都认为它是项目成败的关键。业务方说“我想提高客户满意度”这不算需求说“我希望客服响应时间从5分钟缩短到1分钟”这算初步需求但还不够。FDE要做的是继续往下拆响应时间分解成哪些环节其中哪些环节是AI可以介入的介入之后怎么衡量缩短了多少衡量数据从哪里来如果目标没达成是回退还是兜底这个拆解过程本质上是在构建一个“可验证的任务树”。树的每一层都是可测量、可回溯的。不夸张地说我见过很多AI项目跌跌撞撞做了几个月最后发现大家连“成功的定义”都没有对齐过。这种项目从一开始就应该被FDE叫停。4.2 评估与回归体系没有评估集调提示词就是开盲盒第二个高频踩坑点是评估体系缺失。很多团队做AI应用上线之后靠人工抽查来判断效果没有标准化的评估集没有回归测试流程。结果就是每次调一条提示词或者换一次模型版本整个系统的行为就变了。有些好的变化有些坏的变化但因为缺少自动化回归根本发现不了。现场一位做零售AI的负责人分享了他的做法他们在每次迭代之前会维护一份大概两千条左右的高质量评估集覆盖各种典型问法、边缘情况、敏感话题。每次模型或提示词变更都会先在这份评估集上跑一遍。准确率掉了说明可能有回归问题准确率提升了也要人工复查几十条确认提升是真实的而非过拟合评估集。这套体系看着笨重但是它能保证项目在快速迭代的过程中始终“不往后退”。我个人的体会是评估集的建设不需要一步到位可以从五十条、一百条开始随着项目推进不断补充。关键是要有“版本管理”的意识。提示词也是代码评估集也是资产都应该纳入变更管理流程。4.3 可观测性与链路追踪AI应用上线只是开始第三个坑是上线之后的可观测性。大多数团队把精力都花在开发和上线前的测试上上线之后就靠用户反馈来发现问题。但AI应用不同于传统软件它的输出是概率性的同一个问题可能今天回答得很好明天换一个提问角度就答偏了。没有链路的追踪出了问题你根本不知道是Prompt的问题、检索的问题、模型的问题还是数据源的问题。比较好的实践是做一个“AI网关层”在网关层统一记录日志包括每一次请求的原始输入、检索命中的文档片段、模型输出内容、Token消耗量、响应时间。出现问题时可以像查传统应用日志一样回溯整条链路。同时利用这些日志持续构建“失败样本库”每周挑出典型的失败案例反哺到评估集里去。这个闭环一旦转起来AI应用的质量就会以肉眼可见的速度稳定提升。遗憾的是很多企业没有这个意识上线之后模型效果稍微有点波动就开始从Prompt层面“盲调”反复试了一两周最后还是不知道根因在哪。这不是能力问题是工程基础设施没跟上。4.4 成本与性能的早期规划大模型的每一分钱都要花得明白成本问题被放在第四位但并不意味着它不重要。实际上很多项目就是在成本上栽了跟头。大模型的API调用费用、向量数据库的存储费用、GPU算力的部署费用每一项都是持续的成本流。如果不在架构阶段做规划等到业务量上来了才发现成本失控那个痛苦谁经历谁知道。现场有位做SaaS产品的朋友算了一笔账客户调用量从内测期的每天几百次涨到正式上线后的每天几万次如果没有做缓存、没有做模型分级费用直接翻了将近二十倍。后来他们调整了策略简单的查询走小模型复杂度高的推理才调用大模型高频问题做结果缓存为不同等级的用户配置不同的模型档位。这一套组合拳下来成本降了70%以上用户体验几乎没有下降。FDE在做方案设计的时候就应该把成本模型放进去而不是等项目跑起来之后再去救火。这不是算账的问题这是架构设计的问题。4.5 人机协同与异常处理设计AI不能背锅但也不能甩锅最后一个被高频提及的坑是人机协同的设计。很多AI项目只设计了一段“模型正常工作时”的路径一旦模型回答不稳、用户反复追问、或者遇到知识库覆盖不到的冷门问题整个链路就断了。更可怕的是有的系统直接把模型输出的原话当作最终答复返回给用户连基本的免责声明和不确定性提示都没有。人机协同需要设计的内容包括什么时候AI应该主动承认“我不知道”并转人工什么时候应该给出多个候选答案让用户选择异常处理的触发条件怎么设定转人工之后的信息要不要自动携带给人工客服这些都应该是FDE在方案设计阶段就明确的而不是上线之后出了事故再补。现场有位做了十几年客服系统的老前辈说了一句话很精辟“AI做客服不是要取代人工而是把人工从重复劳动里解放出来让人工专注于高价值的沟通。但如果转人工的机制没设计好那AI就是给人添乱的。”这句话放在任何AI应用场景里都成立。5. 回到日常工作后我尝试做的三个调整圆桌散场之后我在长沙多待了一天。倒不是为了逛景点而是想趁热把当天聊的内容沉淀一下。回酒店的路上我翻了翻笔记本发现自己写满了整整六页。但真正值钱的东西不是那些金句和案例而是它让我第二天开始就想改变自己手头项目的一些做法。这里说三个我已经在执行的调整。5.1 调整一先谈价值指标再谈技术选型我手上正好有一个做企业内部知识库的咨询项目客户一开始提的需求是“接入大模型做智能问答”。如果放在以前我可能第一反应是讨论用哪个模型、怎么做RAG、用哪家向量数据库。但这次从长沙回去之后我做的第一件事是约了业务方的负责人花了一整个下午聊“你希望这个系统上线之后哪些数据发生变化”。后来我们把价值指标拆成了三个员工查找技术文档的平均耗时从15分钟降到3分钟以内技术问题首次解决率提升到80%每月人工解答重复问题的数量减少40%。这三个指标一旦定下来后面所有技术决策都有了判断标准。比如要不要做Agent自动执行操作先看一眼指标发现和三个指标没有强关联那就先放着不做。模型选贵的还是便宜的按回答准确率的要求以及可能要承载的并发量用中档模型配上好的检索就能满足要求完全没必要一上来就上旗舰大模型。这就是“价值驱动”落到实处的感觉每一个技术选型背后都有业务逻辑支撑而不是“因为新所以选”。5.2 调整二用最小任务闭环替代Demo式汇报第二个调整是我给自己定了一条新的项目里程碑规则不再单独汇报“AI功能Demo”而是只汇报“跑通一个任务闭环”。什么叫任务闭环就是用户提出一个具体的业务诉求系统能够端到端地完成整个处理链路并把结果交给用户或下游系统。哪怕这个闭环涉及的场景很小哪怕它解决的只是一个极细分的痛点只要它是闭环的就比一个花里胡哨的“万能对话机器人”更有价值。还是拿知识库项目举例。我先选了“设备故障排查”这一个场景做闭环。操作工在系统里输入设备代码和故障现象系统自动调取设备手册的对应章节结合历史维修记录里同类故障的解决方案生成一个排查步骤清单并且在最后附带“如果上述方案无效请点击下方按钮转接维修工程师”的入口。这个流程做通之后客户直观感受到了AI的实用价值后面的推进就顺畅多了。“最小任务闭环”的思路其实是从软件行业的Minimum Viable Product最小可行产品延伸出来的但放到AI项目里它比单纯的MVP更精确。因为AI项目的核心不确定不只是“产品形态”还有“技术链路能不能跑通”“效果是否稳定”。“闭环”这两个字把最关键的验证点都包含进去了。5.3 调整三建立轻量级回归集从100条测试用例开始第三个调整是关于质量保障的。我以前做项目评估基本靠“感觉”。模型改了提示词之后手工问几个问题觉得回答还行就放过去了。这次圆桌给了我一个教训没有评估集的AI项目就像没有测试用例的软件工程迟早要出大问题。我现在每个项目启动的第三周就会和团队一起从业务方收集一百条左右的典型问题和期望答案整理成第一版回归测试集。不追求数量多但每一条都必须有明确的对错判断标准。然后每次迭代不管是改提示词、换模型还是调检索参数都先跑一遍回归集把通过率记录下来。这个过程刚开始会有点枯燥尤其是手动标注一百条答案确实费时间。但坚持几轮之后你会发现它带来的收益远大于投入。因为模型迭代最大的风险就是“修好一个问题露出三个新问题”回归集能让你在最短时间内看到全貌不至于顾此失彼。到目前为止这个做法已经帮我在一个项目上避免了一次明显的质量回退。当时为了提升回答的“自然度”我调整了系统提示词里的语气设定手工试了几十条觉得效果不错。但回归集一跑发现部分涉及安全规范类的问题回答变得过于口语化严重度陡然上升。发现问题后我立刻回退了那版改动。这个过程让我彻底相信了轻量级回归集的价值。按我现在的习惯一百条起步后续每两周往里补一点半年之后自然就长成一个像样的大规模评估基座了。圆桌讨论里有一句话我到现在还记得大意是AI工程做久了会发现最稀缺的不是模型能力而是那些愿意对最终价值负责的人。FDE这个名字终有一天可能会被其他词取代但“把技术翻译成业务、把业务拆解成任务、把任务闭环到底”这套方法论会在企业级AI落地这条路上一直发挥价值。我把这次长沙圆桌的复盘整理出来也是想给同样在这条路上探索的人一些参考。方向对不怕路远关键是第一步迈得准。