第 1 周：锁定目标岗位与双层对话基线

直接答案： FDE 的第一周不是学习一串 AI 工具，而是确定你准备解决哪类客户问题，并建立一条能力基线：你既要能和业务决策者讨论战略结果、优先级与风险，也要能和一线员工还原真实工作、例外和系统限制。两边都能听懂，还不够；你必须把两边的说法转成可以继续验证的证据。

为什么 FDE 必须能在两个高度工作

同一个项目，在不同角色口中会变成不同问题：

对话对象	他们常用的语言	FDE 要追问什么	这一层不能单独决定什么
业务决策者	增长、成本、续约、风险、战略优先级	为什么现在做？哪项结果必须改变？与什么竞争资源？谁决定继续或停止？	不能只凭战略愿望判断一线真正卡在哪里
一线员工	工单、表格、复制粘贴、审批、返工、临时绕路	最近一次是怎样完成的？用了哪些系统？哪里会失败？错了以后谁处理？	不能只凭局部痛点判断项目值得投入多少资源
FDE	假设、证据、范围、约束和下一步验证	两边的说法在哪里一致、矛盾或缺证？最便宜的验证是什么？	不能替任何一方脑补结论

老板说“用 AI 降低客服成本”，这是一项战略意图，还不是事实。一线客服说“系统很难用”，这是一个问题信号，也还不是可开发需求。FDE 要把两句话连接成一条待验证链：

战略意图
  ↓ 需要业务数据验证
业务结果与指标
  ↓ 需要流程证据验证
一线任务与失败点
  ↓ 以后才进入技术方案
系统、数据与工程约束

这条链是本课程的主轴。第 1 周只判断目标岗位是否要求你完成这项工作，以及你目前有什么证据；第 2–4 周才真正开始客户发现。

先看完成品：一张合格的目标岗位卡

下面是教学模拟完成品。它展示的是写法，不代表“企业 AI FDE”是唯一正确方向。

# 目标岗位卡：B2B 企业 AI FDE（教学示例）

- 目标客户：有复杂知识、权限和审批流程的 B2B 企业团队
- 目标问题：把尚未定义清楚的工作流问题转成可部署的软件或 AI 系统
- 主要对话对象：业务负责人、一线用户、客户 IT / 安全、客户工程团队
- 商业责任：发现高价值问题，解释投入、风险、优先级和采用条件
- 一线责任：观察当前流程、绕路和异常，不把功能请求直接当事实
- 工程责任：亲手完成集成、测试、部署和故障处理
- 结果责任：上线后继续观察采用与失败，把重复模式反馈给产品
- 当前证据：有 API 与部署项目；没有用户访谈记录，也没有业务指标决策记录
- 最关键缺口：客户发现与跨角色沟通，而不是再学一个 Agent 框架
- 选择节奏：24 周标准路线，每周 10 小时

一个合格的岗位卡会改变你的学习顺序。示例中的学习者即使会写代码，也不应该把第一个月继续全部花在模型调用上。

第一步：收集 5–10 个目标岗位

不要在招聘聚合页只搜索职位名称。不同公司可能使用 FDE、FDSE、Forward Deployed AI Engineer、Deployment Strategist 或相近名称。先从官方职位页收集样本，再读实际职责。

至少覆盖两种公司或业务环境。可以从本教程的来源矩阵开始，但需要重新确认链接仍然有效。

把每个岗位放进同一张表：

# 岗位要求矩阵

| 公司 / 职位 | 官方 URL / 访问日期 | 谁是客户 | 商业与战略责任 | 一线流程责任 | 亲手工程责任 | 上线后责任 | 待确认 |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |

怎样提取，而不是照抄

对每条职责先圈出动词，再问它产生什么证据：

职责信号	不够具体的摘抄	可训练的能力	未来证据
与客户识别机会	“与客户合作”	追问业务优先级、当前流程和决定条件	访谈记录、问题合同、决策纪要
构建生产应用	“熟悉 Python”	把一个受约束流程做成可运行系统	代码、测试、部署与故障记录
推动采用	“沟通能力强”	让不同角色理解改变、限制和责任	试点反馈、培训与交接记录
反馈产品	“有产品意识”	区分客户特例和可复用模式	Field note、产品建议与取舍依据

第二步：给岗位加上“双层对话”标记

阅读每个职位时，分别寻找以下信号：

向上对话：能否讨论商业和战略

识别或优先排序客户机会；
定义成功结果，而不是只接收功能清单；
讨论预算、时间、风险、采购或组织约束；
与负责人决定继续、缩小、推迟还是停止；
把一次客户交付沉淀成产品方向或可复用能力。

向下对话：能否进入真实工作

直接访谈或观察最终用户；
理解数据怎样产生、在系统间怎样移动；
记录手工交接、异常、返工和临时绕路；
处理权限、旧系统和现场限制；
上线后观察是否有人使用，以及工作是否真的改变。

如果一个职位只写“与高管建立关系”，却没有用户流程或亲手交付，它可能更接近销售、咨询或战略岗位。如果只要求执行已经确定的技术任务，它可能更接近产品工程。先标记证据，不急着给职位贴标签。

第三步：做一次双层对话诊断

这不是正式客户访谈，只是用同一个模拟场景检查你的默认反应。

场景

虚构公司“北辰协作”的业务负责人说：

“客服成本一直在涨。我们必须在这个季度上 AI，最好自动回答大部分工单。”

一线客服说：

“现在的系统太难用了，每个问题都要到处找资料。”

所有公司、人物和数据均为教学模拟。本周没有更多证据。

我已经保存基线，查看参考回应

面对老板：先判断战略，不要急着展示技术

不合格回应：

“可以，我们用 RAG 加 Agent，接入知识库后就能自动回复。”

问题在于，这句话把“AI”“自动回复”和“降低成本”直接连在一起，跳过了当前成本、战略优先级和风险边界。

更好的第一轮回应：

“我先不假设自动回复是正确方案。这个季度最需要改变的是单位服务成本、响应时间、续约风险，还是团队容量？目前用什么口径判断它？如果速度提高但错误回复增加，哪条风险不能接受？最后，谁会根据哪些证据决定扩大投入？”

用下面五问检查自己有没有进入商业层：

结果： 哪项业务结果必须改变？
为什么现在： 触发事件和机会成本是什么？
基线： 当前值、时间窗和数据来源是什么？
取舍： 什么结果不能为了速度或成本被牺牲？
决定： 谁在什么时间根据什么证据做下一次决定？

这“五问”是本教程的教学工具，不是行业官方框架。第一轮只需要把答案标成已知、待核验或未知，不要用漂亮数字填满空格。

面对一线员工：追最近一次真实工作，不要让对方设计产品

不合格回应：

“如果我们做一个更智能的搜索和自动回复功能，你会用吗？”

它既诱导了答案，也只会得到愿望。更好的回应是：

“请打开最近一张需要查政策的工单，从收到它开始带我走一遍。你先看哪里？切换了哪些系统？什么时候会停下来问同事？怎样判断找到的是当前版本？如果找错了，谁最先发现？”

一线对话至少要找到：

一个最近发生的具体任务；
实际使用的系统和资料，而不是规定中的流程；
一条正常路径和一个例外；
现有绕路，以及它为什么存在；
错误的发现方式、影响和处理人；
仍需日志或观察验证的说法。

把两边放进同一张“翻译板”

此时还没有访谈证据，合格记录应该保留未知项：

老板的表达	一线的表达	当前状态	不能直接得出的结论	下一步证据
客服成本在涨	每个问题要到处找资料	两项均为未核验陈述	找资料就是成本上涨的主要原因	成本构成、工单日志、流程观察
本季度必须上 AI	当前系统难用	AI 是预设方案；“难用”过于宽泛	Agent 是最佳方案	最近任务、替代方案、技术与采购限制
希望自动回答大部分工单	尚未说明哪些任务适合自动化	风险和任务分布未知	自动发送能安全降低成本	工单分类、错误影响、审批与权限规则

你的任务不是在这张表上选边，而是指出哪一条连接最需要验证。

第四步：只用证据评估自己

回到六维能力矩阵，重点检查三个维度：

能力	0 分信号	1 分可接受证据	更高等级以后需要什么
客户发现与产品判断	只看过文章，没留下访谈或问题产物	完成模拟对话、能区分事实和假设	真实访谈、流程证据与范围决定
沟通与影响力	自评“沟通不错”	能把同一问题分别讲给老板和一线员工	真实决策纪要、异议处理与跨角色反馈
软件与数据工程	只会运行 Demo	有可查看的小型服务、测试与数据处理	后续课程中的部署、权限、观测与恢复

不要因为本周做了一次模拟对话就给自己打 2 或 3 分。它最多证明你在引导下完成了一次练习。

将差距写成可观察动作：

差：提升商业思维。
好：第 2–4 周完成 3–5 次跨层访谈，用证据链连接一个战略目标和一个一线流程，并让第三方指出其中的假设。

第五步：完成本周六份文件

建议建立以下目录：

fde-course/
└─ week-01/
   ├─ target-role-card.md
   ├─ job-requirement-matrix.md
   ├─ stakeholder-altitude-matrix.md
   ├─ dual-conversation-baseline.md
   ├─ skills-gap.md
   └─ learning-contract.md

`target-role-card.md`

# 我的目标 FDE 岗位

- 目标行业 / 场景：
- 目标客户与最终用户：
- 主要商业问题：
- 需要对话的决策者：
- 需要观察的一线角色：
- 必须亲手交付的工程范围：
- 上线后需要承担的结果：
- 来自职位样本的证据：
- 仍需在面试中确认的问题：

`skills-gap.md`

直接使用能力矩阵中的 0–3 级标准。每个分数必须附证据；没有证据就记为 0。

两份双层对话基线

在 stakeholder-altitude-matrix.md 中，把每个目标岗位的业务发起人、实际用户、证据所有者和工程责任放在同一张表。dual-conversation-baseline.md 必须同时保留你对老板和一线员工的原始第一反应；看完参考示例后另起一节，标出哪些问题在追业务决定、哪些在追真实任务、哪些已经偷跑到技术方案。不要覆盖原稿，课程后续需要用它比较你的进步。

# 跨层利益相关者矩阵

| 目标岗位 | 业务发起人及其决定 | 一线用户及其任务 | 数据 / 风险证据所有者 | FDE 必须亲手承担的工程责任 | 职位证据或待确认 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

`learning-contract.md`

# 24 周标准路线学习合同（20–28 周弹性）

- 我选择的节奏：20 / 24 / 28 周
- 每周可稳定投入：
- 我选择这个节奏的证据：
- 毕业时要完成的 20 分钟演示：
- 最需要补齐的三个缺口：
- 第 2–4 周能够接触的访谈对象或模拟替代：
- 我不会伪造的证据：真实客户、生产结果、ROI、招聘保证

节奏选择必须遵守24 周标准路线的前置条件；20 周只是满足条件后的加速节奏，28 周用于补强。时间紧不等于自动适合 20 周。

五天安排

学习日	建议时间	当天动作	离开前必须有的结果
第 1 天	2 小时	收集并初读 5–10 个官方岗位	有 URL、访问日期和目标客户
第 2 天	2 小时	完成岗位要求矩阵与双层对话标记	能指出重复信号和信息缺口
第 3 天	2 小时	完成老板与一线对话诊断，保存原始第一反应	有翻译板和对话基线，不把陈述写成事实
第 4 天	2 小时	选择目标岗位，按证据完成能力差距表	三个缺口都能追溯到岗位
第 5 天	1–2 小时	选择节奏、写学习合同并做 90 秒讲解	第三方听完能复述你的选择依据

验收与失败修复

本周通过需要同时满足：

至少分析 5 个仍可访问的官方岗位，且不只来自一家公司；
每项高优先级能力都能指向岗位职责或最终 Capstone 证据；
目标岗位卡同时写明决策者、一线用户和工程责任；
完成跨层利益相关者矩阵，并保留未经润色的对话基线；
所有自评分数都有证据链接或清楚的“无证据”；
能在 90 秒内解释为什么选择这个方向和节奏；
能指出双层对话翻译板中至少三项待验证假设。

常见失败	诊断信号	修复动作
岗位表变成技术名词收藏	只有 Python、RAG、云平台，没有客户与结果	回到职责动词，补“服务谁、改变什么、谁负责采用”
把老板的话当商业事实	写了 ROI 或增长目标，却没有口径和来源	降级为假设，增加数据来源、负责人和验证日期
把一线抱怨当功能需求	“系统难用”直接变成“做聊天机器人”	改为最近任务、实际步骤、例外和错误影响
为了选 20 周高估自己	用“学过”代替生产与用户证据	按 0–3 量表降级，选择能稳定完成的节奏
目标岗位过于宽泛	同时想做售前、算法、平台、产品与交付	固定一个行业、客户类型和主要工作形态

独立迁移练习

把场景从“客服”改成“供应链缺货处理”。不要设计系统，只写：

你会向业务负责人提出的五个商业问题；
你会请仓库或采购员工演示的一个最近任务；
老板与一线说法之间可能出现的三个证据缺口；
哪些能力缺口会阻止你在这个行业成为合格 FDE。

如果你的回答只是把“客服”替换成“供应链”，却没有改变决策者、业务结果、流程和错误代价，说明你仍在复制模板。

下一步

第 1 周只证明你选对了训练方向。下一步进入第 2 周：在战略目标与一线事实之间做第一次 Discovery，开始获取第一批证据。最终 Discovery Brief 要到第 2–4 周阶段结束时才完成。

来源与事实边界

Palantir — Forward Deployed Software Engineer：客户协作、问题分解、软件与数据交付职责。
OpenAI — Forward Deployed Engineer：Discovery、技术范围、构建、上线与采用职责。
Anthropic — Forward Deployed Engineer：客户发现、生产应用、企业部署与持续交付职责。
Ramp — Forward Deployed Engineering：持续范围判断、用户接触与客户结果的团队实践。该文同时具有公司招聘与文化传播目的。

核验日期：2026-08-19。 “双层对话”“五问”和翻译板是本教程综合公开岗位与实践设计的教学工具，不是上述公司的官方框架。北辰协作、人物、对话和数据均为合成材料。