FDE-Wiki

主题

#项目交付#需求工程#评估测试#可观测性#工具箱

本章一句话:把第 6 章的方法论内核,落成一个可执行的"四阶段流程"——Context 勘探 → Design 设计 → Engineer 工程 → Feedback 反馈,这是 FDE 在真实项目里"照着走"的操作手册。

7.1 CDEF 是什么 ​

CDEF 是对 FDE 工作流程的一种结构化归纳,把"前沿部署"拆成四个首尾相接、又循环往复的阶段:

  • C — Context(勘探):钻进客户,挖出真问题、定义价值、对齐结果;
  • D — Design(设计):在真实约束下,设计可落地的方案与技术选型;
  • E — Engineer(工程):搭建最小可用系统,加固、服务化、部署;
  • F — Feedback(反馈):评估闭环、数据回流、持续优化、防能力衰退。

注意是 "Engineer" 和 "Feedback",不是 "Execute" / "Follow-up"——这两个词的选用是有讲究的:Engineer 强调"工程化"(不只是执行,而是用工程方法做扎实),Feedback 强调"闭环"(不只是跟进,而是把反馈回流成改进)。

CDEF 的定位:它不是某一家公司的专有方法论,而是对全球 FDE 实践(Palantir 的 forward deployment、Amazon 的 working backwards、敏捷/设计思维的现场化)的综合提炼。不同公司叫法不同(IBM 的 FDU、Anthropic 的 Applied AI 流程),但内核都逃不出这四个阶段。

7.2 Context 勘探阶段:挖真问题、定北极星 ​

Context 阶段对应第 6 章的 Discovery-first,是整个项目的地基。

Context 阶段的目标

  • 搞清楚客户真正的痛点(往往和客户自己说的不同);
  • 判断哪些痛点能用 AI 解、哪些不能(诚实,不硬塞 AI);
  • 量化每个痛点的价值(值多少钱);
  • 对齐北极星指标(用结果定义卡,见 6.3);
  • 建立客户信任(这是后续一切的前提)。

Context 阶段的关键动作

  1. 48 小时行业勘探:快速建立对该行业/客户的基础认知(行业格局、监管、典型流程、关键指标);
  2. 现场浸泡与多层级访谈:从 CXO 到一线,观察真实业务;
  3. 数据体检:看客户的真实数据质量、分布、可得性;
  4. 问题—价值映射:把痛点按"可解 × 价值"排序;
  5. 北极星对齐:和客户拍板"这个项目要达成什么具体结果"。

Context 阶段的产出

  • 一份《勘探报告》(行业认知 + 客户画像 + 痛点清单);
  • 一张《结果定义卡》(北极星指标 + 衡量方式 + 时间窗 + 价值);
  • 一份《可行性判断》(哪些能做、哪些不能做、为什么)。

Context 阶段的常见坑

  • 客户说什么就信什么(不做交叉验证);
  • 只和 CXO 聊,忽略一线(一线才知道真问题);
  • 过早承诺(还没勘探完就拍胸脯);
  • 把所有问题都往 AI 上套(有些问题用规则/流程改造更合适)。

7.3 Design 设计阶段:约束下方案选型 ​

Design 阶段把 Context 挖出的问题,变成一个在真实约束下可行的方案。

Design 阶段的目标

  • 在客户的真实约束(算力、网络、合规、预算、人员能力)下,设计可行方案;
  • 做关键技术选型(模型、RAG、Agent、部署形态);
  • 明确**最小可行交付(MVD)**的范围(先做什么、后做什么);
  • 对齐客户预期(时间、成本、效果)。

Design 阶段的关键动作

  1. 约束清单:列出所有硬约束(信创、等保、数据不出域、算力上限、预算);
  2. 方案候选与选型:针对北极星,设计 2—3 个候选方案,用决策矩阵选最优;
  3. 技术选型:模型(开源/闭源/国产)、RAG(向量库/知识图谱)、Agent(框架/编排)、部署(云/私有/边缘);
  4. MVD 定义:圈定第一阶段最小可交付范围,确保快速验证;
  5. 风险与回退:识别关键风险,准备回退方案。

Design 阶段的核心矛盾:理想 vs 约束 Design 阶段最考验 FDE 的,是在理想方案和真实约束之间做权衡。理论上,一个超大参数的闭源模型 + 全套 Agent 编排效果最好;但客户可能要求私有化、国产芯片、离线部署。FDE 要在约束下找到"足够好且能落地"的方案,而不是追求理论最优。

Design 的产出:一份《方案设计书》(架构图 + 技术选型 + MVD 范围 + 风险清单 + 资源/时间估算),经客户确认后进入 Engineer。

7.4 Engineer 工程阶段:最小系统、加固、部署 ​

Engineer 阶段把方案变成跑通的系统。

Engineer 阶段的目标

  • 搭建 MVD 并快速跑通(验证可行性);
  • 加固(从 demo 到生产级:稳定、安全、可观测);
  • 服务化(嵌进客户业务系统,给一线用);
  • 部署上线(灰度,逐步放量)。

Engineer 阶段的关键动作

  1. 搭骨架:数据接入 + 模型推理 + 业务逻辑的最小闭环;
  2. 快速跑通:在真实(或接近真实)数据上验证"能不能跑、效果如何";
  3. 加固:异常处理、并发、安全、审计、监控;
  4. 服务化:API/界面集成,嵌进客户工作流;
  5. 灰度部署:从小范围试点到全量,逐步放量、逐步验证。

Engineer 阶段的技术栈(详见第 9 章)

  • LLM 服务化(vLLM、TGI、TensorRT-LLM);
  • RAG 栈(向量库 + 嵌入 + 检索);
  • Agent 框架(LangGraph、CrewAI、OpenAI Agents SDK);
  • 数据管道(ETL、特征、增量同步);
  • 可观测(日志、追踪、监控、告警)。

Engineer 阶段的常见坑

  • 过度工程(一开始就追求完美架构,拖慢验证);
  • 欠工程(demo 跑通就上线,生产环境崩);
  • 忽略数据质量(垃圾进垃圾出);
  • 不做监控(上线后两眼一抹黑)。

7.5 Feedback 反馈阶段:评估闭环、防衰退 ​

Feedback 阶段是 CDEF 的"闭环"环节,也是防 capability atrophy 的关键。

Feedback 阶段的目标

  • 建立评估闭环(系统效果如何,数据说话);
  • 数据回流(把使用数据、反馈回流,持续优化);
  • 持续优化(模型迭代、规则调整、流程改进);
  • 防能力衰退(监控、回访、能力转移);
  • 沉淀资产(把经验沉淀成可复用的组件/案例)。

Feedback 阶段的关键动作

  1. 效果评估:对照北极星指标,量化系统贡献(良品率提升了多少、准确率多少);
  2. 数据回流:采集用户反馈、bad case、业务结果数据;
  3. 迭代优化:基于反馈调模型、改 prompt、修规则;
  4. 监控告警:数据漂移、模型性能、业务指标的实时监控;
  5. 能力转移:文档 + 培训 + 共建,把系统交给客户团队;
  6. 资产沉淀:把可复用的组件、案例、方法论回灌知识库。

Feedback 阶段的价值 Feedback 不是"项目结束的收尾",而是"下一轮价值的起点"。一个健康的 FDE 项目,Feedback 阶段的产出会直接反哺 Context(发现新问题)、Design(优化方案)、Engineer(改进系统),形成持续增值的飞轮。

7.6 四阶段的非线性、循环特性 ​

CDEF 不是瀑布式的单向流程,而是循环的、非线性的。

这是理解 CDEF 的关键。很多团队把 CDEF 当成瀑布(做完 Context 再做 Design,做完 Design 再做 Engineer……),这就退化成了传统交付。真正的 CDEF 是:

  • Context 和 Design 交织:勘探中发现新约束,立刻反馈到方案设计;
  • Design 和 Engineer 交织:设计时发现技术不可行,立刻调整方案;
  • Engineer 和 Feedback 交织:搭系统的同时就埋监控、收反馈;
  • Feedback 回流 Context:反馈中发现新问题/新机会,开启新一轮 Context。

一句话:CDEF 是一个螺旋上升的循环,而不是一条直线。FDE 在四个阶段间频繁切换,而不是按部就班走完。

7.7 阶段门(gate)与回溯 ​

为了保证循环不失控,CDEF 引入"阶段门(gate)"机制:每个阶段结束,有一个明确的"过关标准",达标才进入下一阶段(或正式立项下一阶段资源)。

典型的阶段门标准

  • Context→Design 门:北极星指标已对齐、可行性已确认、客户高层认可;
  • Design→Engineer 门:方案设计书已确认、MVD 范围已圈定、资源已到位;
  • Engineer→Feedback 门:MVD 已跑通、加固完成、灰度上线;
  • Feedback→(新一轮 Context)门:效果已量化、新机会已识别。

回溯机制 阶段门不是"只能前进"。如果某个阶段发现上一阶段的假设错了(比如 Design 时发现 Context 的痛点判断有误),CDEF 允许回溯——回到上一阶段重新做。这种"允许回溯"的设计,让 CDEF 既结构化又灵活。

7.8 2026 演进:Agent、FDCE、评估驱动 ​

CDEF 在 2026 年有三个重要演进方向:

演进一:Agent 嵌入每个阶段 2026 年,Agent 不再只是 Engineer 阶段的产物,而是嵌入 CDEF 全流程:

  • Context:Agent 辅助行业勘探、自动整理访谈纪要;
  • Design:Agent 辅助方案候选生成、技术选型对比;
  • Engineer:Agent 承担标准化开发、测试、部署;
  • Feedback:Agent 7×24 监控、自动归因 bad case。

演进二:FDCE 贯穿第 6 章的 FDCE(上下文工程)贯穿 CDEF——Context 阶段采集上下文,Design 阶段设计上下文管道,Engineer 阶段实现上下文管道,Feedback 阶段优化上下文质量。

演进三:评估驱动(Eval-Driven) 受 LLM 应用"评估驱动开发"思潮影响,2026 年的 CDEF 把"评估(eval)"前移:不再等到 Feedback 才评估,而是在 Design 就定义评估集,在 Engineer 就持续评估。这让"效果好坏"全程可控,而不是上线才知道。

7.9 CDEF 与 Echo-Delta 编队的映射 ​

CDEF 四阶段和 Echo-Delta 编队如何配合?

阶段主导角色支持角色
ContextEcho(挖问题)Delta(技术可行性判断)
DesignEcho + Delta 共同Dev(平台能力咨询)
EngineerDelta(搭系统)Echo(需求澄清)、Agent(辅助)
FeedbackEcho + Delta 共同Dev(平台改进)、客户团队(运营)

可见,Echo 主导 Context,Delta 主导 Engineer,Design 和 Feedback 是两人共同负责。这种映射,让"谁在什么时候主导"清晰可执行。

本章小结 ​

  • CDEF(Context-Design-Engineer-Feedback)是把 FDE 方法论流程化的四阶段操作手册;
  • Context 挖真问题、定北极星;Design 在约束下选型、定 MVD;Engineer 搭最小系统、加固、灰度部署;Feedback 评估闭环、防衰退、沉淀资产;
  • CDEF 是非线性、循环的螺旋,不是瀑布;配阶段门和回溯机制保证既结构化又灵活;
  • 2026 演进:Agent 嵌入全流程、FDCE 贯穿、评估前移(eval-driven);
  • CDEF 与 Echo-Delta 映射:Echo 主导 Context,Delta 主导 Engineer,Design/Feedback 共同负责;
  • CDEF 是全球 FDE 实践的综合提炼,不同公司叫法不同但内核一致。

本章来源:本书第 5、6 章方法论内核、IBM FDU 结构化交付、Anthropic Applied AI 流程、Amazon Working Backwards、O'Reilly《AI Agents Stack 2026》、CDEF 方法论文档(业界综合)、第三篇各行业落地的 CDEF 实践。

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

FDE 调研报告 (2026)