04 FDE 的交付闭环和作品集标准
章节目标
建立 FDE 的交付闭环意识，并理解一个合格 FDE 作品集应该证明什么。
开篇案例：为什么作品集不能只放 Demo 截图
很多转型 FDE 的同学会把作品集做成“我搭了一个 RAG 助手”“我做了一个 Agent Demo”。截图看起来很完整，但面试官或客户真正关心的问题是：这个场景来自哪里？谁会用？现在流程怎么做？系统错了谁复核？效果怎么评估？上线后谁维护？
如果这些问题回答不上来，作品集只是 AI 应用展示，不是 FDE 交付证据。FDE 的作品集要证明的不是“我会调用模型”，而是“我能把一个不确定的业务问题，推进到可验证、可运营、可复盘的闭环”。
交付闭环
FDE 的工作不是“做一个功能”，而是完成一条闭环：
flowchart TD
discoverNode[发现问题] --> scopeNode[技术定界]
scopeNode --> prototypeNode[原型验证]
prototypeNode --> deployNode[部署上线]
deployNode --> productizeNode[产品化沉淀]
productizeNode --> feedbackNode[反馈迭代]
feedbackNode --> discoverNode
对应动作可记为：发现 → 原型 → 部署 → 产品化 → 反馈。原型阶段验证假设，部署阶段进入真实权限与数据，产品化阶段沉淀模板、Skill 和组件，反馈阶段驱动下一轮 discovery。
Pod 协作模式
海外大型部署项目常见 FDE + Deployment Strategist / Lead + 行业专家 的三人 Pod：
| 角色 | 负责什么 |
|---|---|
| FDE | 现场 discovery、架构、集成、评估与 rollout |
| Deployment Strategist / Lead | 价值路径、组织变革、adoption 与升级机制 |
| 行业专家 | 流程口径、Ground Truth、合规与业务验收 |
Salesforce、OpenAI DeployCo 等公开招聘均体现“工程 + 策略 + 业务”组合，而非单人英雄式交付。
生产采用与可复用资产 KPI
交付闭环的验收不只看模型指标，还要看：
| KPI 类型 | 示例 |
|---|---|
| 生产采用率 | 周活用户、任务完成占比、人工替代步骤数 |
| 可复用资产 | 场景卡、Prompt、Golden Dataset、工具 Schema、上线门禁模板 |
| 业务影响 | 节省人时、错误率下降、周期缩短、风险事件减少 |
FDE 要把客户现场经验写成可复用资产，而不是留在个人笔记里。
每一环的产物
| 环节 | 关键问题 | 交付物 |
|---|---|---|
| 发现问题 | 哪个流程值得做 | 访谈记录、流程图、痛点清单 |
| 技术定界 | 做什么、不做什么 | 场景卡、范围假设、风险边界 |
| 设计方案 | 用什么架构 | PoC 架构图、工具清单、权限方案 |
| 实现系统 | 如何跑通链路 | 最小 Demo、代码、日志和任务状态 |
| 评估效果 | 如何证明有效 | Golden Dataset、指标、失败样本 |
| 上线运营 | 如何稳定使用 | 上线门禁、培训、回滚和反馈机制 |
| 反馈产品 | 如何复用经验 | 产品需求、模板、组件和复盘文档 |
DIVE 问题解决框架
FDE 可用 DIVE 串联咨询式拆解与工程交付：
| 步骤 | 英文 | 关键动作 |
|---|---|---|
| D | Diagnose | 用访谈、流程图、问题树诊断真实瓶颈 |
| I | Identify | 识别高价值场景、数据条件与成功指标 |
| V | Validate | 用 PoC、Golden Dataset 和周度 Demo 验证假设 |
| E | Embed | 嵌入业务流程、权限、培训和运营机制 |
DIVE 将“发现问题”到“反馈产品”的闭环写成可执行方法。
三层 PoC 路径
| 层级 | 方式 | 适合阶段 |
|---|---|---|
| L1 平台 Demo | Dify、Coze、FastGPT 等开箱即用 | 验证价值、周度 Demo |
| L2 Vibe Coding | 快速脚本 + 轻量前后端 | 定制逻辑、评估原型 |
| L3 工程化脚手架 | LangGraph、网关、CI、回归门禁 | Beta / 生产 |
升级条件：有稳定样本、明确权限、可观测、业务方愿意试用。
周度 Demo 节奏
- Kickoff 对齐目标、范围、验收和风险。
- 每周 Demo 展示可运行增量，而非 PPT 进度。
- 同步记录失败样本和变更池，避免范围无声膨胀。
一次交付的节奏样例
下面是一条 4 周 PoC 节奏，可作为作品集或客户提案的时间线：
| 周期 | 关键动作 | 关键产物 |
|---|---|---|
| 第 1 周 | 访谈、影子跟随、场景卡 | 流程图、痛点清单、PoC 范围 |
| 第 2 周 | 样例数据、架构选择、最小链路 | Demo v0、工具清单、权限假设 |
| 第 3 周 | Golden Dataset、失败样本、周度 Demo | 评估报告、变更池、风险清单 |
| 第 4 周 | 试用、复盘、上线门禁 | 验收指标、30 天计划、作品集摘要 |
这个节奏的重点不是“4 周一定上线”，而是让项目每周都有可检查的增量，避免团队在讨论、调研和临时需求中失焦。
作品集标准
FDE 作品集不是 API 调用截图，也不是单页 Demo。它应该证明：
- 你理解一个真实业务流程。
- 你能把模糊需求拆成可交付范围。
- 你能设计系统架构和权限边界。
- 你能实现最小可运行链路。
- 你能设计评估样本和验收指标。
- 你能解释上线风险、回滚和运营方式。
作品集结构
建议每个作品集项目包含：
- 一句话场景。
- 当前流程和痛点。
- AI 介入点。
- 技术架构图。
- 数据和工具清单。
- 权限和合规边界。
- 评估指标。
- Demo 截图或脚本。
- 失败样本和复盘。
- 下一步上线计划。
实操任务
选择一个场景，为它写一页作品集摘要。
交付物
- FDE 交付闭环图。
- 作品集项目大纲。
- 一个可继续扩展的 PoC brief。
常见误区
- 只展示模型输出，不展示业务流程。
- 只展示技术栈，不展示验收指标。
- 只展示成功样本，不展示失败样本。
- 只做一次性 Demo，不说明上线运营。
检查清单
- 作品集是否能让客户相信你能交付？
- 是否有可验证指标？
- 是否有数据、工具、权限和风险说明？
- 是否能体现产品反哺和复用价值？