FDE-Wiki

主题

#需求工程#Prompt工程#知识管理#医疗

本章一句话:剥开 FDE 的各种花哨描述,它的方法论内核其实就四件事——先发现真问题(Discovery-first)、从结果倒推系统(Working Backwards)、防止系统上线即衰退(防 capability atrophy)、把"上下文工程"做成交付本身(FDCE)。

6.1 方法论的四个内核原则 ​

FDE 之所以有效,不是因为某个炫酷的技术,而是因为它坚持了四个反直觉的方法论原则。这四个原则,在传统软件交付里往往被忽视,却正是 AI 项目成败的分水岭:

  1. Discovery-first(发现优先):在动手做之前,把大部分精力花在"发现真问题"上,而不是"赶紧开发";
  2. Working Backwards(倒推):从客户想要的最终结果出发,倒推该建什么样的系统,而不是从"我们有什么技术"出发正推;
  3. 防 capability atrophy(防能力衰退):不仅把系统搭起来,更要保证它持续产生价值,而不是上线即巅峰;
  4. Forward-Deployed Context Engineering / FDCE(前沿部署上下文工程):把"理解客户上下文"本身工程化,作为交付的核心。

下面逐一拆解。

6.2 Discovery-first:先发现,再动手 ​

Discovery-first 是 FDE 方法论的第一原则:在客户环境里,最大的风险不是"做不出来",而是"做错了东西"。

LinkedIn 上 Natarajan 的文章《When Forward-Deployed Engineering Works for Enterprise AI》给出了一个精准判断:"当问题是'发现(discovery)'而不是'铺开(rollout)'时,前沿部署才创造杠杆。" 这句话的意思是:FDE 的价值,在"问题还没被发现"的场景里最大;一旦问题已经被清楚定义、只需要执行,FDE 的杠杆反而下降(那种场景更适合传统工程团队)。

为什么 Discovery-first 反直觉? 传统工程思维是"需求明确→赶紧开发→按时交付",追求的是执行效率。但 FDE 面对的现实是:客户嘴上说的需求,往往不是真正的需求。一个客户说"我要一个大模型客服",真问题可能是"我的客服离职率高、培训成本高";一个客户说"我要做 AI 质检",真问题可能是"我的良品率数据不准、根本不知道哪里出了问题"。如果 FDE 不做 discovery,直接照客户说的做,大概率做出来的东西客户不用。

Discovery-first 怎么做?

  • 浸泡:在客户现场待足够长(天/周级),观察真实业务流,而不是听汇报;
  • 多层级访谈:从 CXO 到一线操作员都要聊,因为不同层级看到的问题不同;
  • 看真实数据:翻客户的真实数据(不是 demo 数据),从数据里发现矛盾和机会;
  • 快速验证假设:用最小原型(甚至 Excel、白板)验证"我以为的痛点是不是真痛点";
  • 价值排序:把发现的痛点按"可解决性 × 价值"排序,选最高杠杆的先做。

Discovery-first 的产出:不是一份需求文档,而是一份"问题—价值映射表"——哪些是真问题、值多少钱、能不能用 AI 解、优先级如何。这份表,是后续所有工作的地基。

Discovery-first 的成本 Discovery-first 看起来"慢"(花几周只调研不开发),但它省下了后面几个月"做错重做"的成本。这是典型的"慢即是快"——前期投入 discovery,避免后期返工。

6.3 Working Backwards:从客户结果倒推系统 ​

Working Backwards(倒推)是 FDE 的第二个核心原则:先想清楚客户要的最终结果是什么,再倒推该建什么系统。

这个思想源于 Amazon 的 Working Backwards 方法(先写产品发布稿/FAQ,再开发),FDE 把它用在了客户交付上。

传统正推 vs FDE 倒推

  • 传统正推:我们有一个大模型/平台(技术)→ 看看能解决客户什么问题(找场景)→ 做个系统(开发)。这种思路容易做出"技术很炫但没用"的东西;
  • FDE 倒推:客户要的结果是"良品率提升 3 个点"(结果)→ 要达到这个结果,需要怎样的质检流程(流程)→ 这个流程需要怎样的 AI 能力(能力)→ 用什么模型/平台实现(技术)。这种思路确保每一步都对准最终价值。

倒推的落地工具:结果定义卡 FDE 在项目启动时,会和客户共同填写一张"结果定义卡":

  • 业务结果:具体到数字(如"派单准确率从 72% 提升到 90%");
  • 衡量方式:怎么算"准确率",数据从哪来,谁说了算;
  • 时间窗口:多久之内达到;
  • 当前基线:现在是多少,差距多大;
  • 价值换算:达到这个结果值多少钱(省成本/增收入/避风险)。

这张卡一旦定下,整个项目就有了"北极星"——所有技术决策都要回答"这有助于达到结果卡吗?"。这避免了项目跑着跑着偏离价值。

倒推的威力:它把"AI 项目"从"技术项目"重新定义为"业务项目"。客户买的不是模型,是结果卡上那个数字。FDE 对这个数字负责,而不是对模型精度负责。

6.4 防 capability atrophy:让系统持续产生价值 ​

防 capability atrophy(防能力衰退)是 FDE 区别于"一锤子买卖"交付的关键原则。

什么是 capability atrophy? Capability atrophy 指的是 AI/数据系统上线后,价值随时间逐渐衰退的现象。原因包括:

  • 数据漂移:业务变了,数据分布变了,模型不准了;
  • 管道断裂:上游系统升级,数据管道没人维护,断了;
  • 业务变化:客户业务流程调整,系统不匹配了;
  • 人员流失:懂系统的客户员工离职,没人会用/维护;
  • 遗忘:系统跑着跑着,大家忘了它为什么这么设计,不敢动。

结果是:系统上线时很惊艳,半年后变成"僵尸系统",无人使用、无人维护、价值归零。这是企业 AI 项目最隐蔽的失败模式——不是轰轰烈烈地失败,而是慢慢地死去。

FDE 怎么防 atrophy?FDE 的防衰退机制包括:

  1. 持续驻场/定期回访:不是交付完就走,而是持续关注系统运行;
  2. 监控与告警:建立数据质量、模型性能、业务指标的监控,异常早发现;
  3. 能力转移:把系统知识转移给客户团队(文档 + 培训 + 共建),避免单点依赖;
  4. 定期 review:和客户定期回顾"系统还在产生价值吗",及时调整;
  5. 可演进架构:系统设计时预留演进空间,业务变化时能快速适配。

Palantir 的 JD(Acrisure 等)明确把"preventing capability atrophy"列为 FDE 的核心职责——对解决方案的产品化负责,防止部署后价值衰退。

防 atrophy 的商业意义:它把 FDE 从"项目制交付"推向"长期服务",为客户创造持续价值,也为 FDE 所在公司创造持续营收。这是 FDE 商业模式可持续的根基(见第 21 章)。

6.5 FDCE:Forward-Deployed Context Engineering(2026 新提法) ​

FDCE 是 2026 年出现的一个新提法,代表 FDE 方法论在大模型时代的进化方向。

2026 年 4 月,Healthcare IT Today 在《From Pilots to Production》一文中提出 Forward-Deployed Context Engineering(FDCE) 的概念:它把"Service as a Software(服务即软件)"延伸为一种交付模式——工程师直接在客户的运营环境内构建 AI 系统,而不是在隔离的环境里开发。FDCE 的核心,是把"理解并工程化客户上下文"本身,当作交付的核心产物。

为什么"上下文"成了核心? 在大模型时代,模型本身越来越通用、越来越强,真正决定 AI 系统好坏的,不再是"模型多聪明",而是"喂给模型的上下文多准确、多完整"。一个通用的 GPT,加上精准的客户业务上下文(数据、规则、历史、约束),就能变成专家级助手;反之,最强的模型加上错误的上下文,也会输出垃圾。

这就是 Context Engineering(上下文工程)兴起的背景——它接棒 Prompt Engineering,成为 2026 年 LLM 应用的核心能力。而 FDCE 把它和"前沿部署"结合:FDE 的工作,很大一部分是把客户的海量、混沌的上下文,工程化成模型可用的形态。

FDCE 在医疗的典型应用 以医疗为例(Healthcare IT Today 的场景):

  • 模型是通用的;
  • 上下文是:这家医院的具体病种分布、病历模板、质控规则、DRG 分组逻辑、医生的工作习惯、合规边界;
  • FDE 的工作,是把这些上下文"工程化"进 AI 系统,让一个通用模型变成"这家医院的病历质控专家"。

FDCE 的本质:它把 FDE 的工作重心,从"写业务逻辑代码"转移到"构建高质量的上下文管道"。代码量可能更少,但对客户业务的理解要更深。这是 FDE 在大模型时代的"技能升级方向"。

6.6 方法论 vs 瀑布 vs 敏捷的差异 ​

FDE 方法论和传统软件开发方法论(瀑布、敏捷)是什么关系?用一个表说清:

维度瀑布敏捷FDE 方法论
起点完整需求待挖掘的产品需求待发现的客户真问题
节奏阶段式(需求→设计→开发→测试)迭代式(冲刺)发现-搭建-验证循环(在现场)
环境公司内部公司内部客户现场
对谁负责规格说明书产品 backlog客户业务结果
反馈来源测试用例内部用户/早期用户客户真实业务
失败模式需求变更范围蔓延做错问题/value atrophy

FDE 方法论不是推翻敏捷,而是把敏捷的"迭代"思想,搬到客户现场,用真实业务结果作为反馈。它本质上是"在现场、对结果、快速循环的敏捷"。值得注意的是,FDE 方法论和设计思维(Design Thinking)也有交集——都强调同理心、原型、迭代——但 FDE 更强调"工程化交付 + 对结果负责",而不只是"想清楚"。

6.7 方法论的落地工具 ​

这套方法论不是空洞的口号,它有一套落地工具支撑(详见第二篇后续章节和第三篇行业落地):

  • Discovery 工具:客户访谈模板、问题—价值映射表、北极星指标卡;
  • 倒推工具:结果定义卡、ROI 测算模型、价值流图;
  • 防 atrophy 工具:监控看板、数据质量告警、知识转移清单、定期 review 议程;
  • FDCE 工具:上下文管道(RAG、知识图谱、规则引擎)、上下文版本管理、上下文质量评估。

本书第 7 章(CDEF 四阶段)会把这套方法论,组织成一个可执行的四阶段流程(Context→Design→Engineer→Feedback),让 FDE 在真实项目里有章可循。

本章小结 ​

  • FDE 方法论有四个内核:Discovery-first、Working Backwards、防 capability atrophy、FDCE;
  • Discovery-first:最大风险是做错东西,前期投入发现真问题,慢即是快;
  • Working Backwards:从客户结果倒推系统,用"结果定义卡"对齐北极星;
  • 防 capability atrophy:系统上线即衰退是隐蔽失败,FDE 靠持续驻场、监控、能力转移、可演进架构防范;
  • FDCE(2026 新提法):大模型时代,FDE 工作重心从写代码转向工程化客户上下文;
  • FDE 方法论 = 在现场、对结果、快速循环的敏捷,介于设计思维与工程交付之间;
  • 方法论有配套工具(发现/倒推/防衰退/上下文工程),第 7 章 CDEF 将其流程化。

本章来源:LinkedIn《When Forward-Deployed Engineering Works for Enterprise AI》(Natarajan)、Healthcare IT Today《From Pilots to Production: Context-Driven AI》(2026.04, FDCE)、Amazon Working Backwards 方法论、Palantir/Acrisure JD(capability atrophy)、Resolve.ai《Why Enterprise AI Needs FDEs》、Stermedia《Forward Deployed Engineering》、本书第 5、7 章。

本站由原始 Markdown 调研报告自动构建 · 原文未改动

FDE 调研报告 (2026)