LUOYU INSIGHTS · FDE 与交付
FDE 是什么？企业为什么需要前线交付，而不只是一个 AI 演示
从业务负责人的角度理解 FDE：它如何连接需求、工程与实际使用，与驻场开发有什么区别，企业如何判断自己是否需要这种交付方式。
FDE（Forward Deployed Engineering）可以理解为一种接近客户实际业务、由问题驱动软件构建的工作方式。重点是让理解问题、开发应用、收集反馈和改进成果形成连续过程。对企业来说，值得购买的是解决问题的能力，而不是一个岗位缩写。
FDE 要解决什么断层
企业提出“需要一个 AI 助手”，可能实际面对三种问题：资料找不到、审批规则不清楚，或者系统之间需要重复录入。如果不区分这些问题，团队容易先做出聊天界面，再发现它无法进入日常工作。
前线交付要求实施人员接触真实使用者、代表性任务和异常情形。需求不是只靠启动会议确认，而是在构建和使用中持续验证。现场发现的问题，应进入工程改进和交付复盘，让下一次实施建立在已有经验之上。
珞瑜的判断是：这种方式的关键资产包括可复用的软件基础、清晰的责任以及质量评审。仅把人员安排到客户办公室，并不会自动产生这些能力。
前线交付需要理解什么
| 需要理解的内容 | 在项目中表现为什么 |
|---|---|
| 业务任务 | 谁使用结果，完成什么决策，错误有什么后果 |
| 数据与规则 | 哪份资料有效，字段是什么意思，谁能修改规则 |
| 工程实现 | 如何接入系统、处理失败、控制权限和成本 |
| 用户采用 | 新流程是否省事，谁培训，出现问题找谁 |
这些能力未必集中在一个人身上。更现实的组织方式是由客户业务负责人、领域顾问、工程人员和项目负责人共同承担。客户仍需指定能够确认优先级、协调资料和参与验收的人。
用工业品询盘场景说明
以下为假设场景：销售需要翻阅产品手册，回复型号、规格和使用条件。普通演示可以上传几份文件，生成一段流畅答复。前线交付则要继续追问：是否选错型号，手册是否过期，哪些资料属于内部价格，回复能否未经审核直接发送？
合适的首期范围可以是：限定一个产品线，返回带出处的答复草稿，由销售审核。系统遇到缺少依据的规格时提示不确定，不自行承诺价格、交期或适配结论。测试包含正常问题、模糊型号、旧版本和无答案问题。
这个范围比“全公司智能销售平台”小，但更容易明确责任、获得反馈，并判断是否值得继续。后续扩展自动报价时，应重新设计价格规则、审批权限和异常处理，而不是直接打开自动发送开关。
什么企业适合这种交付方式
如果问题已标准化，现成软件可以满足，采购与配置可能更合适。如果业务流程尚需梳理，数据和规则需要反复确认，应用必须与一线工作共同演进，前线交付更值得考虑。
启动前回答五个问题：
- 能否指定业务负责人和实际使用者？
- 能否提供获准使用、具有代表性的任务与资料？
- 能否说清目前耗时、错误或返工在哪里？
- 能否先限定一个工作流程，而非同时改造全公司？
- 是否愿意参与测试，并根据证据调整最初设想？
条件不足时，第一步是诊断和准备，不是立即扩大开发团队。
如何评价交付是否成功
不要只看模型答对几个问题。还要看使用者是否采用、任务是否更快、审核返工是否减少、成本是否可控，以及客户能否维护成果。这些要求应在项目开始时进入目标和验收计划。
验收要区分原型、受控试点与生产系统。演示证明了某条路径可以运行，不意味着满足稳定运行、权限隔离和异常处理要求。可继续阅读从 AI 原型到生产部署。
企业常问的问题
FDE 必须长期驻场吗？不必一概而论。现场观察、远程协作和阶段性工作坊都可以采用，关键是接触真实问题并及时验证。
FDE 能替代业务负责人吗？不能。外部团队可以协助分析构建，业务优先级与验收仍需客户参与。
是否必须购买 Palantir？本文讨论公开实践所启发的交付思想，珞瑜的实施建议不绑定该平台，也不代表与其合作。