# 本章小结

## 1.6.1 角色边界决定交付质量

本章讨论了 FDE 的出现背景、现场嵌入方式、相邻角色分工和价值闭环。FDE 的核心不是“到客户现场写代码”这么简单，而是在复杂组织环境中把问题发现、工程交付、生产运行、指标验证和产品反哺连成闭环。Palantir 将 FDE [视为一种产品开发范式](https://www.palantir.com/docs/foundry/architecture-center/platforms/)；OpenAI 与 Anthropic 的公开材料也显示，AI 公司正在通过 FDE/类似职位[推动前沿模型进入生产场景](https://openai.com/business/the-openai-deployment-company)。这些公开资料共同说明，FDE 的价值来自现场学习速度、工程闭环能力和可复用沉淀能力。

FDE 不是售前工程师、解决方案架构师、专业服务、SRE、平台工程师或客户成功的替代品。它更像一个高密度接口，把相邻角色的输入整合成可运行系统，并把现场信号转回产品和平台。若没有清晰边界，FDE 很容易退化成无边界救火、临时脚本堆积或高成本定制；若边界清晰，它可以成为企业 AI 和复杂软件落地中最关键的反馈通道。

| 本章问题      | 关键结论                                 |
| --------- | ------------------------------------ |
| FDE 为何出现  | 企业软件价值从功能交付转向生产化结果，传统角色之间存在现场闭环缺口    |
| 如何现场嵌入    | 进入真实工作流，处理数据、权限、流程、运行和采用约束           |
| 如何与相邻角色分工 | 不替代相邻角色，而是在高不确定性交付阶段承担整合责任           |
| 如何判断成功    | 同时衡量业务结果、工程质量、用户采用和复用沉淀              |
| 如何识别反模式   | 警惕驻场化、定制陷阱、影子 SRE、PPT 顾问化和演示模型化等退化形态 |

## 1.6.2 进入下一章

下一章将进入 FDE 的第一项基本功：现场问题发现。角色边界回答“谁负责什么”，问题发现回答“什么问题值得做”。在真实项目中，错误的问题定义会让后续架构、数据、AI、交付和运维全部失焦。因此，FDE 必须先学会在客户现场建立事实、识别约束、形成领域语言，并把模糊诉求切成可验证的工程问题。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/forward_deployed_engineering_guide/di-yi-bu-fen-ru-men-pian-li-jie-fde/01_role/summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.