附录
从 Palantir 到 OpenAI，系统梳理 FDE 的本质、核心模型、组织定位、落地路径、交付机制、中国语境适配以及人才画像。
附录
A. FDE 人才画像速查卡
五维硬指标
| 维度 | 核心要求 | 具体表现 |
|---|---|---|
| 业务逻辑理解 + 系统设计能力 | 知道业务怎么运转，能把它变成系统 | 看懂报销流程为什么设计五个审批节点；判断哪些环节可以自动化、哪些必须保留人工 |
| 组织洞察与协调能力 | 识别部门墙、政治问题、被隐瞒的低效流程，并且能处理 | 能观察到"这个流程一直在用但没人觉得有问题"；找到谁能拍板、谁的利益需要照顾 |
| 结果驱动的执行力 | "我一定要把这个事情做成"的驱动力 | 遇到阻力想办法绕过去或推过去，碰到技术问题自己解决 |
| 平台反哺意识 | 判断眼前的问题其他客户也可能遇到，推动沉淀 | 在解决一个客户问题时主动思考"这个模式能复用吗" |
| 行业前沿意识 | 主动让自己站在业务和技术的前沿 | 持续关注新工具、新方法、新的行业趋势 |
三阶段面试红线
| 阶段 | 测什么 | 否决红线 |
|---|---|---|
| 战壕测试 | 业务管理和客户管理能力 | 流露出对完美 PRD 的依赖，或一味顺从客户、不敢直言技术赤字 |
| 开放式情境评估 | 可直接落地的咨询能力 | 只给出宽泛的架构图，无法现场写出伪代码或数据清洗逻辑 |
| 教导型技术分享 | 外循环能力（抽象和沉淀） | 展示的项目都是流水线式的固定任务，缺乏独立破局经历和经验提炼 |
B. 最小可行 Pod 组建模板
角色配置
| 角色 | 人数 | 来源 | 核心职责 |
|---|---|---|---|
| 业务侧成员 | 1-2 人 | 从业务部门拉出 | 理解业务需求、做 Demo、验证方案、持续使用和反馈 |
| 技术侧成员 | 1-2 人 | 从产研部门拉出 | 把 Demo 变成可运行的系统、和现有系统对接、沉淀可复用模式 |
时间线
| 节点 | 时间 | 里程碑 |
|---|---|---|
| Day 1 | 进入项目 | 到业务人员工位旁坐下来，跟着走一遍完整流程 |
| Day 1-3 | 交付第一个原型 | 极简但能跑，解决一个真实痛点 |
| Day 14 | 首次集成完成 | 技术侧完成第一次和业务系统的集成 |
| Day 30 | 核心功能可用 | 主要功能已可日常使用 |
| Day 90 | 生产上线 | 完整系统部署到真实环境 |
| Day 120 | 技术侧撤出 | 技术侧 FDE 回到产研团队，带走前线经验和可复用模式 |
配套规则
- 业务侧必须有对接人，否则项目不启动
- 每个项目至少产出一个核心产品改进
- 首次集成不超过 14 天，做不到就终止
- 生产上线不超过 90 天，做不到就终止
- 业务侧的人必须学会使用 AI 编程工具
C. 平台 Handoff 12 条 Checklist
技术侧 FDE 撤出项目时，必须完成以下 12 项知识转移：
项目上下文
- 业务问题描述。 解决了什么业务问题？为什么值得解决？原来的方式是什么样的？
- 业务流程文档。 当前工作流的流程图，标注关键节点、瓶颈、人工干预点。
- 用户使用情况。 谁在用、用哪些功能、哪些功能没用起来、反馈是什么。
技术交付物
- 技术架构说明。 系统的整体架构、数据流、各模块的职责和依赖关系。
- 代码和配置清单。 关键代码/配置的位置、说明、已知的技术债。
- 数据集成映射。 数据源的映射关系、集成方式、数据质量问题和临时补丁。
- 安全和合规。 数据分级、权限模型、是否通过安全审查、合规要求清单。
沉淀和延续
- 已知问题清单。 当前未解决的问题、临时方案、风险等级。
- 闪光点上报。 项目中发现的可复用模式——已上报的标注状态，未上报的附描述。
- 核心产品改进建议。 至少一个建议进入标准产品路线图的功能或能力，附理由。
- 运维文档。 部署方式、监控指标、故障排查指南、应急预案。
- 业务侧自主能力评估。 业务人员当前能否独立使用和维护？哪些环节仍需技术支持？
D. 参考案例
Palantir：FDE 的起源
Palantir 是 FDE 模式的创始者。2005 年，为了解决 CIA、NSA 等政府机构的数据集成问题，Palantir 摒弃了传统的软件销售模式，直接派遣具备安全资质的工程师长期驻扎在客户现场。
核心做法：
- 工程师直接嵌入到 Fort Bragg、Langley 等军事基地，最长的部署能到一年
- 先建模客户的业务实体（Ontology），再做应用
- Ship on Day One：每个项目的第一天就交付可用的东西
- 现场团队拥有高度自主权，总部信任前线决策
关键结果：FDE 在现场为不同客户构建的解决方案，被持续抽象为平台通用能力，最终形成了 Palantir 的核心产品（Gotham、Foundry）。2024 年 Palantir 收入 $2.87B，公开市场回报 640%。
对企业的启示：FDE 模式要成立，必须同时设计"现场交付"和"把现场学习反哺平台"两条线。Palantir 的成功不是因为驻场本身，是因为驻场产生的经验变成了产品。
OpenAI：从呼叫中心到 Realtime API
OpenAI 的 FDE 在为某呼叫中心开发 AI 语音助理集成时，构建了一套实时评估框架来捕捉语音延迟和吞吐波动。这套框架是前线为了解决具体问题临时做的，但 FDE 意识到这个评估逻辑对所有语音场景都有用。
闪光点被即时上报。最终，这套前线评估框架重塑了 OpenAI 官方 Realtime API 的底层机制，同时促成了 Agent SDK 的定型。一个为单个客户做的临时工具，变成了平台的核心能力。
2026 年，OpenAI 进一步推出了 Deployment Company，补充约 150 名 FDE 和部署专家，初始资本超过 40 亿美元。FDE 从"少数高端项目的交付资源"升级为"企业 AI 规模化部署的正式产业能力层"。
对企业的启示：前线发现的价值取决于两件事——FDE 有没有抽象意识，以及组织有没有接收和标准化的机制。两个条件缺一个，前线的发现就永远留在前线。
Morgan Stanley 与 OpenAI：eval-driven 的采用飞轮
Morgan Stanley 的财富管理团队与 OpenAI 合作，用 FDE 模式部署 AI 工具。核心做法是先建立评测框架（eval framework），再从试点扩展到公司级使用。
关键结果：
- 财富管理顾问团队使用率超过 98%
- 文档可访问率从 20% 提升到 80%
- 信息跟进速度从"数天"压缩到"数小时"
对企业的启示：FDE 成功的关键不是快速写代码，是现场发现、评测治理、渐进式扩展、组织采用四件事同时成立。做出来只是第一步，让人用起来才是终点。