岗位使命：对“最后一公里”负责
FDE的使命，是在客户的真实约束下，让技术能力成为可被使用、可被衡量、可持续改进的业务能力。
这包含两个方向：向外部署，把模型、平台和工程方法带进客户环境；向内反馈，把一线发现的共性需求、失败模式与行业语义带回产品团队。
不是“交付了多少功能”，而是“关键用户是否在真实流程中持续使用，以及组织因此获得了什么可验证的改变”。
六类核心职责
业务发现与问题定义
观察流程、访谈关键角色、分析基线，区分表层需求与真正约束，选择价值与可行性兼具的切入点。
方案与价值设计
定义人机分工、系统边界、业务指标与验收方式，避免只围绕模型功能设计解决方案。
原型与生产工程
快速构建原型，并完成数据处理、应用开发、API集成、权限控制、可观测性与上线工作。
评测与可靠性
与领域专家共同建立黄金样本、失败分类和质量阈值，持续验证系统在常见及高风险场景中的表现。
现场采用与迭代
培训用户、收集反馈、分析使用行为，推动流程和角色调整，让技术真正进入日常工作。
资产沉淀与产品反馈
把连接器、数据模型、评测工具和行业组件标准化，将一次性交付转化为可复用能力。
T型能力模型：一专、多能、会协同
FDE并非要求每个人在所有维度都达到专家水平。更可行的是：在软件工程上具备扎实纵深，同时在业务、数据、AI与沟通上能够独立推进工作。
| 能力维度 | 需要做到什么 | 可观察证据 |
|---|---|---|
| 软件工程（纵深） | 全栈开发、系统集成、API、云与部署、代码质量 | 能独立把原型演进为可维护的生产系统 |
| 数据与AI | 数据建模、RAG/Agent、提示与上下文、评测 | 能定位失败来自数据、检索、模型还是流程 |
| 业务理解 | 流程分析、领域语言、价值树、约束识别 | 能与一线及高管分别讨论细节和价值 |
| 产品与交互 | 场景优先级、原型、人机分工、用户反馈 | 能做减法，不把能力清单当产品方案 |
| 沟通与推动 | 访谈、共创、演示、冲突处理、期望管理 | 能让不同角色对目标、边界和进度形成共识 |
| 责任与判断 | 安全意识、风险升级、不确定性表达、复盘 | 知道何时自动化、何时人工复核、何时不做 |
客户侧同样需要“领域FDE”
成功的FDE项目不是供应商单方面输出。客户内部的领域专家、数据负责人、IT与业务Owner，需要共同提供上下文、决策和采用推动。领域专家不必变成程序员，但应参与样本标注、失败分析和流程重构。
与相邻岗位如何协同？
FDE更偏向
- 特定客户的具体业务结果
- 不确定场景的快速探索
- 端到端打通生产工作流
- 高频、直接的最终用户反馈
- 将现场共性问题带回产品
平台产品 / 研发更偏向
- 多客户通用的产品能力
- 稳定性、扩展性与架构一致性
- 长期路线图和平台维护
- 抽象跨场景的共同需求
- 控制定制分叉与技术债
售前帮助判断“是否值得做、能否成交”；FDE帮助实现“如何真正运转”；客户成功帮助推动“如何持续使用与扩展”；咨询帮助回答“组织与流程为何改变”。小型团队中这些职责可能重叠，但责任结果仍应被区分。
90天交付闭环
发现：建立事实与基线
完成现场观察、利益相关者访谈、数据盘点和价值假设。输出场景优先级、当前基线、风险清单与试点章程。
共创：让真实用户尽早使用
以真实数据构建最小可行工作流，与领域专家共同评测。输出可运行原型、初始黄金集和范围调整决策。
部署：从“能用”走向“可信”
完成集成、权限、质量门槛、人工复核、日志监测与用户培训。小流量上线，按失败类型持续迭代。
沉淀：验证价值，决定扩展
对照基线评估业务结果，区分一次性内容与可复用资产。决定扩大、调整或停止，并明确后续Owner。
需要完整的阶段产出、质量门禁、角色分工和停止规则，请进入FDE交付方法论。
高合规、复杂集成场景可能需要更长周期。关键不是赶日期，而是尽早获得真实反馈，并在每个阶段设置继续或停止的决策点。
如何衡量一个FDE是否做得好？
| 层次 | 指标示例 | 避免的误区 |
|---|---|---|
| 业务结果 | 处理周期、单位成本、转化率、差错率、风险暴露 | 把全部业务变化都归因于AI |
| 用户采用 | 目标用户渗透、周活跃、任务完成、持续使用率 | 只看培训人数和演示次数 |
| 系统质量 | 任务成功率、人工改判、延迟、故障与回退次数 | 只展示少量精心挑选的好样本 |
| 交付效率 | 首次上线周期、迭代周期、阻塞关闭时间 | 为追求速度跳过安全与权限 |
| 能力复用 | 通用组件占比、下一次部署提速、平台需求吸收 | 把复制代码数量当成产品化 |
谁适合成为FDE？
通常会比较匹配
- 喜欢模糊问题，不等待完美需求
- 既能写代码，也愿意观察真实工作
- 对质量与结果有强烈主人翁意识
- 能坦诚表达不确定性和坏消息
- 愿意把个人经验沉淀为团队资产
需要认真评估
- 只喜欢独立研究，不喜欢高频协作
- 只追求技术新颖，不关心采用结果
- 无法接受非标准环境与迭代反复
- 倾向把所有需求都做成一次性定制
- 不愿处理权限、文档、培训等“非模型”工作