成为 FDE

直接答案： FDE = Forward Deployed Engineer（前线部署工程师/前沿部署工程师），本文不指全盘加密。成为 FDE，要把客户模糊问题交付成可上线、可验证的系统，并用项目证据证明过程。

如果你还不清楚岗位边界，先读《FDE 是什么》，再回到这条学习主线。

课程方向已经固定

整条课程以 24 周为标准路线，并提供 20 周加速和 28 周稳健节奏；三种节奏都遵守同一条证据链：老板的战略目标 → 要支持的业务决定 → 一线员工的真实任务与异常 → 数据和系统约束 → 工程交付 → 采用、运营与交接。只会谈商业、只会访谈或只会写系统，都不算完成本课程定义的 FDE 训练。

学习目标

完成这套教程后，你应该能够：

1. 用自己的话解释 FDE 的职责、工作闭环，以及它与普通软件工程、解决方案和售前岗位的重叠与区别。
2. 对照真实岗位要求评估能力差距，而不是照抄一份脱离目标岗位的“技能清单”。
3. 面向业务决策者解释战略优先级、价值机制与风险，同时从一线员工的真实任务中取得证据。
4. 从客户发现开始，完成一个包含需求、实现、评测、部署、观测和交接的端到端项目。
5. 把代码、设计决策、业务指标和复盘组织成招聘方或潜在客户可以核验的作品集证据。

先统一一个定义

FDE = Forward Deployed Engineer，中文常译为“前线部署工程师”或“前沿部署工程师”。 本教程同时保留两种常见译法，英文缩写统一使用 FDE。

FDE 不是全球统一认证的工种。不同公司还会使用 Forward Deployed Software Engineer（FDSE）、Forward Deployed AI Engineer 等相近名称。综合 Palantir、OpenAI 和 Anthropic 的一手岗位页面，本教程把它概括为：

FDE 深入真实客户场景，把尚未完全定义的问题转化为可上线的软件或 AI 系统，并对技术落地、业务采用和反馈闭环承担较强责任。

这是一份基于岗位样本的工作定义，不代表所有公司的官方统一口径。申请前仍要逐条阅读目标公司的最新职位描述。

这套教程适合谁

你适合从这里开始，如果你：

• 能用 Python、TypeScript、Java 等至少一种语言完成基础程序；
• 知道 Git、HTTP API、数据库的基本概念，但还没有 FDE 经历；
• 想从“会做功能”提升到“能发现问题、交付结果并推动采用”；
• 希望用公开项目证明能力，而不是只在简历里罗列工具名。

如果你还不能独立调用 API、读写数据库或使用 Git，先补软件工程基础会更高效。FDE 通常不是绕过工程基础的捷径。

学习方式：每一章都留下证据

本教程使用同一个学习闭环：

步骤	你要回答的问题	留下的证据
读岗位	公司真正要解决什么问题？	岗位简报与来源链接
找差距	我缺的是知识、实践，还是生产经验？	能力矩阵与差距排序
做项目	我能否从模糊需求走到可用系统？	代码、决策记录、测试与演示
证结果	系统是否正确、安全、稳定且有人采用？	Eval、指标、日志与用户反馈
讲清楚	我为何这样取舍，下一步会改什么？	案例叙事、复盘与面试材料

建议按以下顺序开始：

1. 阅读《FDE 是什么》，建立岗位简报。
2. 完成《FDE 能力矩阵》，只给有证据的能力打分。
3. 进入学习路线，用目标岗位决定训练顺序。
4. 从第 1 周岗位与双层对话基线开始，按公开教程索引完成全部 24 周；每个阶段必须通过证据门槛，不能只按日期翻页。

可验证产出

完成入门部分后，请创建一个 fde-readiness/ 目录，至少包含：

fde-readiness/
├─ fde-role-brief.md   # 目标岗位、职责证据与岗位边界
├─ fde-skill-gap.md    # 有证据链接的能力自评
└─ next-30-days.md     # 未来 30 天的三个可验收动作

验收标准：

• 每项岗位判断都能追溯到至少一个一手职位页面；
• 每项能力分数都有代码、文档、演示或真实经历作为证据，没有证据就记为 0；
• 三个近期动作都写明截止日期和产物，不使用“继续学习”“熟悉一下”这类无法验收的表述；
• 读者仅查看这三个文件，就能说明你为何选择 FDE、当前在哪一层、下一步准备补什么。

如果你想先看这些能力如何进入真实交付场景，可以查看作者主站的真实 AI 落地案例。案例用于展示方法如何落地，不替代本教程中的动手练习。

你的团队正在解决类似的业务问题吗？

这套教程也可以帮助业务负责人和技术负责人核对项目方案。先选一个最接近的问题，查看对应的判断方法：

当前卡点	可以先用的教程方法
想做 AI，但还没有确定先改哪一步工作	把业务目标和一线任务写成可决策的需求范围
企业知识库能回答，却不知道答案是否可信、是否越权	检查回答来源、拒答与评测结果
希望连接现有系统，又担心自动操作出错	核对预览、人工审批、重复请求和执行结果
演示已经做好，但上线和后续维护没人接得住	用非作者接手验证部署、故障处理与回滚

需要项目合作时，可以查看风雨的项目经验，或通过邮箱、微信沟通你的业务场景。主站公开介绍了企业知识库、业务系统接入、工作流自动化与生产交付方向。

开始沟通只需描述四件事：谁在做什么工作、目前卡在哪一步、已有些什么系统、希望改变什么结果。例如：“运营每天跨 ERP 和库存系统核对订单，异常仍靠群里追问；希望先理清一个异常处理流程，并判断适合怎样接入现有系统。”这是沟通示例，不是已交付客户案例。暂时不需要准备技术方案；合作范围、排期和费用在具体需求澄清后确认。

常见误区

• 把教程当成入职保证。 岗位要求会因公司、行业、地区和级别变化；教程只能帮助你形成能力与证据。
• 收集资料等于学习。 收藏十份路线图，不如交付一个有用户、有约束、有复盘的项目。
• 工具越多越像 FDE。 招聘方更关心你如何选择工具、处理约束并交付结果。
• “面向客户”意味着少写代码。 一手岗位样本同时强调客户协作与亲手构建；两者通常缺一不可。
• GitHub Star 等于商业转化。 Star 是传播信号，不是交付能力或客户价值的充分证据。

权威来源

以下一手职位页面用于提炼本教程的岗位共性。招聘页面可能随岗位状态调整或下线：

• Palantir — Forward Deployed Software Engineer
• Palantir — Forward Deployed AI Engineer
• OpenAI — Forward Deployed Engineer
• Anthropic — Forward Deployed Engineer

核验日期：2026-08-19。 文中的岗位定义与能力模型是对上述来源的原创归纳，不是任何一家公司的官方课程或录用标准。