01 导读：FDE 为什么是当下最值得关注的新岗位
大家好，我是曹犟，神策数据的联合创始人与 CTO。在 TO B 软件这个行业，我做了十一年的研发与交付管理，更早之前，在百度做了七年大数据研发。最近一年，我自己也带着一个三人小团队，用 FDE 的方式驻场服务客户，同时在极客时间开设了《FDE 业务落地实战》专栏，讨论怎么在中国把 AI 真正交付出去。
开营前，先完成这四件事
它主要解决四个问题：先理解 FDE 是什么，遇到常用术语时不被卡住，知道自己目前的能力起点，同时把 W1 需要的本地环境准备好。
第一件事：读完四篇基础材料
“FDE 基础认知”一共四篇，是为对 FDE 这个方向感兴趣的朋友准备的公开材料，内容改编自我的专栏和我自己公众号上已发表的相关文章。四篇的顺序，就是我建议的阅读顺序：
- 什么是 FDE：先把这个最基础、也最容易被误解的概念说清楚，包括它的出身，以及怎么分辨真假 FDE。
- 为什么是现在：把工程师派到客户现场并不新鲜，为什么偏偏这两年 FDE 的价值明显提高了？
- 中国机会与争议：FDE 在国内会不会水土不服？六个现实问题都有依据，但 AI 也带来了新的解决条件。
- 就业市场与岗位画像：FDE 需要什么能力，面试考什么，谁适合做，以及什么时候不建议做。
这四篇能帮你建立对 FDE 的基本认知。至于怎么进场摸清客户的真问题、怎么把 demo 变成生产系统、怎么把现场经验沉淀回产品，这些实战层面的内容，我在专栏和训练营里会一步一步展开。
上述文章内容所有观点只代表我个人的看法，有错漏之处不可避免，还请大家谅解。读完之后，至少需要能够回答下面四个问题：
- FDE 和售前、咨询、外包、驻场实施有什么区别？
- 为什么 AI 能力越来越强之后，企业反而更需要 FDE？
- FDE 在中国落地时，会遇到哪些特有的机会和约束？
- 如果考虑从事 FDE，应该怎样判断岗位，也应该怎样判断自己？
阅读时抓住一条主线
进入客户现场只是 FDE 工作的起点，交付一个可以运行的系统也还不是终点。一个完整的 FDE 闭环还需要做到两件事：对可以衡量的业务结果负责，把现场得到的认知沉淀回产品，让第二个、第三个客户更容易被服务。
后面的 12 周沙盘，会把这条主线拆成一组连续任务。你会代表一家已经拥有标准 Agent 产品的厂商，从一封说不清楚的立项邮件开始，逐步完成需求澄清、数据治理、本体建模、客户化开发、系统集成、生产上线、效果归因、验收复盘和资产沉淀。这个过程既要把标准产品适配进青禾优选，也要判断哪些现场问题应该留在客户层，哪些值得沉淀回产品。预习阶段先把完整链路看清楚，开营后再逐周把每一段做出来。
读完后记录四句话
不需要写长篇读后感，只要用自己的话补完下面四句话：
- 我理解的 FDE 是：________________________________
- FDE 和我最熟悉的相近岗位，最大的区别是：________________________________
- 我认为 FDE 在中国落地最现实的机会或约束是：________________________________
- 如果让我进入一个客户现场，我目前最需要补的能力是：________________________________
这四句话不提交，也不评分。W12 回看时，可以用它们检查自己对 FDE 的理解是否发生了变化。
第二件事：浏览术语表
《FDE 核心术语表》收录了课程里会反复出现的 2B 交付、数据与 AI 工程术语。术语表不需要背诵，开营前先浏览一遍，后面遇到不熟悉的词再回来查即可。
每个术语分成两层：第一层是相对正式的定义，第二层是它在这门课里的具体含义。两层都要看，因为很多术语在字面上不难，真正进入客户项目以后，边界却很容易混淆。
第三件事：完成第一次能力自评
打开《FDE 能力自评》，完成开营前评分，并为每一项写下一条具体证据。这里没有标准答案，也不用于证明自己已经达到某个岗位级别。它只记录现在的起点。
W12 结营时，我们使用同一份问题再评一次。前后两次分数本身并不重要，真正需要对照的是：过去只能凭感觉回答的问题，12 周以后是否已经有项目产出、代码、文档或客户沟通记录作为证据。
第四件事：准备本地环境
按照《环境准备指引》完成基础检查。训练营允许使用自己熟悉的后端语言和技术栈，但官方参考路径使用 Python；W1 就会提供独立的本地标签 Mock 服务，官方产品和配套工具需要 Python 运行时。
开营前不强制提前学习提示词工程、模型微调、向量数据库或某一种 Agent 框架。需要准备的是更基础的东西：一门后端语言、基本 SQL、大模型 API 调用、本地数据库与开发环境。
课程方会提供可运行的标准会员运营 Agent、SQLite、干净样例数据和通过 HTTP 调用的样例标签系统。默认路线是在这套产品上完成青禾优选的客户交付；也允许学员自行开发等价产品，使用相同的数据、API 和验收契约。两条路线都需要完成数据处理、业务语义、系统集成、权限、评估、生产扩展，以及针对实际模型和客户业态的 Agent 效果调优。
完成预习的判断标准
已按顺序读完四篇基础材料
知道在哪里查询课程术语
已填写开营前能力评分，并为问题的评分留下证据
已完成本地环境的基础检查
已妥善保存大模型 API 密钥，没有把密钥写入代码或提交到代码仓库
完成这五项，就可以进入 W1。W1 会领取、安装并运行标准 Agent 产品底座和客户交付仓库，通过官方 checker 完成数据库、模型 API、工具注册接口和课程工具的环境自检，并对照产品能力矩阵形成首版 fit-gap 清单。此后每周都在同一个客户交付仓库里继续施工，按统一的产出物契约留下代码、文档和验收证据。
02 认识 FDE
一个嵌入客户现场的产品探索者
FDE 的全称是 Forward Deployed Engineer，一般翻译成前沿部署工程师，或者前置部署工程师。很多人第一次听到这个词，第一反应是：这不就是驻场开发、外包换了个英文名吗？这个质疑很普遍，也不是完全没道理。市面上一大半使用 FDE 名称的岗位，确实就是售前或者实施换了个名字，这一点我完全承认。
但情况也没有这么糟。2026 年 5 月，Anthropic 先宣布与多家机构成立一家企业 AI 服务公司；一周后，OpenAI 也成立了企业部署公司，并收购 Tomoro，一次获得约 150 名 FDE 和部署专家。如果 FDE 只是一个换名营销词，这些技术和工程能力都很强的 AI 公司，为什么还要为它单独成立公司、投入大量资源招聘？所以实际情况多半在两个极端之间：既有大量只是改名包装的岗位，也有真正有价值的工作。这一篇，我们先把有价值的部分说清楚，最后再给出一套判断标准。
先给一个定义
所谓 FDE，其实就是一个嵌入客户现场、主动交付有价值结果的产品探索者。
这句话里有三个关键词，值得一个个讨论。
第一个词，是嵌入客户现场。FDE 不是坐在公司总部等着需求文档，而是实际进入客户的办公室和业务流程。他要观察客户每天怎么工作，找到客户没有明确说出、但实际阻碍工作的问题。
第二个词，是主动交付有价值的结果。这里有两个关键，一个是“主动”，一个是“结果”。说主动，是因为 FDE 会自己判断客户真正的问题是什么、值不值得做，而不是被动地等客户提出需求，再照单处理。说结果，是因为 FDE 最后要对客户业务中一项可以衡量的改善负责，只交付工时和代码，并不算完成工作。
第三个词，也是最重要的一个，是产品探索者。这是 FDE 区别于其他角色的核心。FDE 到客户现场，表面上是在解决这一个客户的问题，但本质上，也是在为产品探索方向：这一个客户暴露出来的问题，以及从客户身上得到的业务认知，最后要变成产品里的新能力。
你可能觉得这个定义还是有点抽象。我们来看一下 FDE 真实的一周大概是什么样子。周一，他带着电脑来到客户的办公室，找一个工位连续工作一周，而不只是开完会就离开。他会跟着客户的业务人员，观察他们具体怎么处理一单生意，怎么在多个系统之间搬运数据，以及流程中的哪些环节问题最多。白天，他在客户现场了解情况、与相关人员沟通、用 AI 编写小工具解决具体问题；到了晚上，则要把白天得到的认知写进产品设计文档，甚至直接变成产品新版本的代码。完成一个客户的项目后，他得到的不只是这一个客户的交付结果，还有一批能够带回产品团队的真实认知。
定义里最重要的那个词，还值得再展开一下。“探索者”和“交付者”是有本质区别的：交付者的任务，是把一个已经定义好的东西，正确地做出来、装上去；而探索者的任务，则是在一个还没有标准答案的地方，找出到底该做什么、做出来的东西应该是什么形态。一个在已知的边界里落地，一个在未知里开路。还有一点容易被忽略：FDE 是真的要写生产代码的。他不是做几张 PPT、搭一个一次性的 demo 就完成工作，而是要把能力真正做进客户的生产系统里，让它稳定运行、扛得住真实的业务。说到底，探索的结果，必须是一个能真正落地、能用起来的东西。
这个角色最早来自 Palantir
要真正理解 FDE，可以先看最早设立这个角色的 Palantir。Palantir 成立于 2003 年，最早为美国的情报和政府部门提供数据分析服务，后来把这套能力带进了企业市场。到今天，它已经是一家很受资本市场关注的上市公司，而它留给整个行业最重要的东西，可能不是某一个产品，而是 FDE 这个角色，以及围绕 FDE 形成的一整套工作方式。
Palantir 早期的产品拿去见客户，效果并不好，客户觉得产品太重、太难用、太粗糙，无法真正落地。如果是一般的公司，可能会回去继续修改产品和文档。但 Palantir 选择了一种当时看起来投入很高的做法：直接派工程师进入客户现场，一边帮助客户解决最难的问题，一边根据现场反馈改进产品。这批被派到客户现场的工程师，就是最早的一批 FDE，在 Palantir 内部叫作 Delta，这个代号来自他们早期用北约字母表给团队起名的习惯。
Palantir 用一组对照，把 Delta 和后方普通开发工程师的区别讲得很清楚。普通的开发工程师，在 Palantir 内部叫 Dev，他的模式是“一种能力，服务多个客户”，比如我写好一个功能，所有客户都能用。而 Delta，也就是 FDE，采用的则是“一个客户，多种能力”的模式，也就是围绕这一个客户，把问题从头到尾解决，需要什么能力就使用什么能力。
说到底，FDE 要解决的是通用产品与客户具体环境之间的差异。一边是产品团队做出来的通用平台，它抽象、规范、强调复用；另一边是客户的具体环境，其中有历史遗留问题、特殊流程，还有很难明确描述的工作惯例。FDE 在两者之间承担翻译工作：把客户现场的问题，翻译成产品中对应的需求；再把产品能力，转化成客户能够感受到的业务结果。
关键是认知回流，不是驻场本身
只有一个长期在现场工作的前线工程师，其实还不够。因为如果只是在客户那里解决问题，成果和认知就会停留在这一个客户的项目中，那和一家普通的外包公司没有本质区别。所以在前线交付的同时，还必须有一条通道，把在单个客户身上验证出来的认知整理出来、沉淀进产品，变成所有客户都能使用的能力。
判断真假 FDE 的核心，就是这一条：在客户现场得到的认知，到底有没有回流到产品里。
Palantir 有一个很完整的案例。从 2015 年起，它向飞机制造商空客的工厂派驻 FDE，长期在现场工作。这些工程师一开始做的是很具体的工作：把空客分散在多个系统里的数据整合起来，做成统一的界面，帮助工厂进行规划和故障排查，逐步解决了二十多个问题。更关键的是后半段：Palantir 把在空客这一个客户身上验证出来的能力，沉淀成了一个叫 Skywise 的平台，随后又将它提供给整个航空业。这就是一条完整的链路：在单个客户身上探索，再把成果变成所有客户都能使用的产品。
前 OpenAI 首席研究官 Bob McGrew 有一句话，把 FDE 的策略总结得非常准确：把那些不可规模化的事，规模化地做。一个一个地深入客户现场，这件事本身很难规模化，短期看效率也不高。但正因为每一次进入现场，都在为产品带回真实的认知，这些投入最后才能沉淀成可以规模化的产品能力。
FDE 和咨询、外包、实施、售前的区别
落到具体岗位上，FDE 最容易和四个角色混淆。把这四组区别讲清楚，后面的判断标准就有了依据。
先说咨询。咨询交付的是一份诊断报告、一套方案、几条建议，顾问通常很聪明，分析也到位，但项目一结束，这些知识往往就停留在报告里、停留在顾问自己的经验里，下一个客户来，很多分析还要从头做一遍。而 FDE 交付的，是一个能在客户生产环境里真正跑起来的系统，是可衡量的业务结果，更关键的是，现场得到的经验要能沉淀回自己的产品。咨询公司做一百个项目，是一百次独立的智力劳动；FDE 模式做一百个项目，理想状态是让同一个产品被打磨一百遍，产品越做越强，项目却越做越轻。
再说外包。外包的经济模型是按人天结算：需求方给一份 spec，外包团队照着实现、交付、验收、结账。外包通常不需要自己定义问题，项目交付之后，也不负责把经验沉淀进产品。而 FDE 到现场，最重要的是把真问题挖出来，自己定义要做什么，自己写产品里还不存在的生产代码。检验的方法也很朴素：每做完一个客户，下一次是否更容易？如果第一次部署要十个人干三个月，第二次还是十个人三个月，那就不是产品公司，而是外包公司。
第三组是驻场实施。这一组最容易混淆，因为两个岗位都要驻场。实施做的，是把一个已经成型的产品，在客户那里装好、配好、接好、培训好，产品的能力边界是确定的，实施在这个边界之内让它落地，所以实施是产品的下游。而 FDE 则是产品的上游：他往往出现在产品能力还不够、甚至产品形态还没定型的阶段，去现场搞清楚客户的问题到底是什么、产品应该做成什么样，构建的是产品里此刻还不存在的能力。
最后是售前和解决方案架构师。这一组用考核指标就能分清。售前的核心使命是促成签单，考核指标是销售额，薪资里通常带着销售提成；FDE 的考核指标，则是交付可衡量的业务结果。这两个目标在关键时刻是会冲突的：一个场景客户很想买单，售前自然倾向于把它讲成能落地、效果好；而真正的 FDE 到现场可能会发现，这个场景的数据条件根本不具备，该做的是叫停，而不是硬上。
到了 AI 时代，还要专门补一种新情况：基于 AI 的定制开发。现在 AI 编码能力很强，一个工程师带着 AI 工具进到客户现场，几天就能搭出一套定制系统，运行得还不错，客户也满意。他会很自然地觉得，我进了现场、写了生产代码、交付了结果，这不就是 FDE 吗？我的判断是：还不是。它依然是给单个客户写定制代码，只不过写得更快了。AI 改变的是交付的效率，没有改变交付的性质。而且这里有一个反直觉的地方：AI 让单次交付变得又快又省力，反而容易让人停在“快”里，反正下一个客户来，用 AI 再做一遍就行，何必费力沉淀进产品？结果就是陷进“很高效的高级外包”，却还以为自己在做 FDE。所以越是在 AI 时代，“认知能不能回流到产品”这条标准，反而越重要。
怎么分辨真假 FDE
回到开头那个质疑。把上面四组区别，再加上认知回流这条主线，浓缩一下，就是五条判断标准，可以用来考察一个 FDE 岗位，或者一支自称采用 FDE 模式的团队。
**第一，看薪资结构。**里面有没有销售提成？如果有，它更可能是改名后的售前岗位。
**第二，看沉淀。**客户现场得到的经验，能不能反哺产品？如果不能，每个项目都从零开始，那本质上仍然是外包。
**第三，看复利。**第二个客户是不是比第一个更容易？如果每个项目的投入永远一样重，项目之间没有任何复用，那就是咨询公司。
**第四，看代码。**构建的是产品里还不具备的新能力，还是只在做配置和集成？配置和集成本身也是 FDE 的必要工作，但如果工作到此为止，没有继续定义问题、构建新能力，那更接近实施。
**第五，看对什么负责。**对签单负责的，是售前；对工时和人天负责的，是外包；对“产品跑起来”负责的，是实施；对可衡量的业务结果负责、还要把经验沉淀回产品的，才是 FDE。
在这五条里，我个人最看重第二条和第三条。因为薪资、代码这些还可能通过岗位描述包装，但“产品”和“复利”很难仅靠包装形成。一家公司是否真的在做 FDE，可以观察它做到第三个、第五个客户的时候，项目是越来越轻，还是越来越重，答案就会比较明显。
最后还要补充客户这一侧的判断。上面五条，全部是站在乙方看团队、看岗位，但对客户来说，与外包和 FDE 合作，需要付出的东西也完全不同。外包进场，客户给一份需求文档，按文档验收即可，自己的工作方式无须改变；FDE 进场，客户要允许 FDE 参加业务会议，提供真实的数据和权限，还要安排懂业务的人共同工作。简单来说，外包客户不用改变自己，FDE 的客户则需要做出改变。从这个角度看，FDE 模式能不能成立，本质上是一场双向筛选：一头筛选人和团队，一头筛选客户。
对于个人来说，这一篇有一个很实际的用处。如果你想入行，应该寻找要求你把经验沉淀回产品的团队，而不是主要依靠出售人天获得收入的团队。前者会让你的经验不断积累，后者则容易让你长期停留在重复的人力交付中。
最后，还是回到这一篇最核心的判断：进入客户现场只是起点，交付业务结果也不是终点。只有把现场得到的认知带回产品，让第二个、第三个客户更容易被服务，FDE 才形成了完整的闭环。后面三篇讨论为什么是现在、中国有没有机会，以及个人怎么选择，都会沿着这条主线继续展开。
03 FDE 为什么这么火？
上一篇我们讲了 FDE 是什么。这一篇回答第二个问题：为什么偏偏是现在？
把工程师派到客户现场这件事，一点都不新鲜。驻场、实施、乙方外包，中国 ToB 行业干了几十年了；从 Palantir 提出 FDE 这个概念，也快 20 年了。可为什么单单是这两年，FDE 突然成了硅谷最抢手的岗位，并且在国内热度也越来越高？
我觉得，这跟生成式 AI 带来的技术变化有直接关系。这一轮 AI 发展，其实同时产生了两个重要影响。一方面，它带来了一个规模大、时间紧迫的新需求市场：AI 能力越强，落地难度就越突出，企业也越急于找到合适的人，把 AI 变成可以衡量的业务结果。另一方面，它同时为这些需求带来了一个新的解决条件：AI 降低了做产品、改代码的门槛，让“一个人从头贯通整个产品链条”这件过去很难实现的事，第一次变得可行。需求快速增长，个人能力的边界也明显扩大，而且这两件事来源于同一场技术变化，在同一个时刻发生。这才是“为什么偏偏是现在”的完整答案。
下面我们顺着这两条主线往下走。
先看一个数字：95% 的失败
麻省理工有一个叫 NANDA 的研究项目，2025 年出了一份报告，叫《The GenAI Divide》。里面有一个数字当时被到处引用：企业在生成式 AI 上，前前后后投进去了三四百亿美元，可其中大约 95% 的组织，没有产生可以衡量的财务回报。真正跑出可衡量业务价值的企业，只有 5% 左右。
当然，这个数字后来是有争议的，有人指出这份报告样本不算大、方法也不够严谨，不应该被当成精确的科学结论。但即便把这个数字打个折，它指出的方向还是很清楚的：绝大多数企业，花了钱、买了模型、认真尝试了，最后却没能让 AI 真正落地。无独有偶，IDC 的一份调研说，企业启动的 AI 概念验证项目里，大约 88% 从来没能真正进入生产。
这种失败的例子，你可能自己也见过。一家企业，老板对 AI 充满期待，启动了一个 AI 项目，demo 效果很好，预算也给到位。可真正开始使用时，问题一个接一个出现：数据接不进来，权限不符合合规要求，业务人员觉得不好用，宁愿回到原来的工作方式。几个月过去，参与者的热情逐渐消失，项目也没有了后续进展。
这就带来了一个问题：模型能力明明在明显提高，为什么 AI 项目反而大面积失败？
失败的，不是模型
答案可能很简单：这些项目失败的原因，恰恰不在模型能力。
那份 MIT 的报告在分析失败原因时特别强调，企业的 AI 项目做不成功，通常不是因为模型不够聪明，不是因为数据不够，也不是因为招不到人。真正的原因，是那些工具“不学习、不留存反馈、不融入现有的工作流”。简单来说，就是 AI 没能真正进入企业的业务流程。演示阶段效果很好，一旦放进真实的工作流程，就无法适应具体环境。
这背后可能还有一个更深的变化。一家叫 Faros AI 的公司，分析了一万多名开发者、一千多个团队之后发现：当 AI 让写代码这件事变得飞快之后，研发的瓶颈并没有消失，而是往下游移动了，移到了评审、测试、发布、集成这些环节上。那些重度使用 AI 的团队，代码合并的量涨了接近一倍，可与此同时，花在代码评审上的时间也涨了差不多九成。也就是说，代码是写得快了，可把代码变成一个能在企业里稳定运行、真正被用起来的系统，中间还有很多环节，AI 目前帮不上太多忙。
所以这里出现了一个明显的错位：AI 把“写代码”的成本压下来了，但“AI 落地”的难度并没有下降，反而随着 AI 的广泛应用变得更加突出。从这个角度看，决定一个 AI 项目能否成功的，已经不只是工程和编码本身，更包括应用能不能真正进入业务流程。写代码不再是瓶颈，交付才是。
那份报告其实还回答了另外半个问题：成功的 5%，到底做对了什么？这些企业几乎都要求供应商做到流程级的定制，按真实的业务结果来验收，还把对方当成一个长期的服务伙伴，而不是只完成一次软件销售。把这几条放在一起看会发现，这些做法与 FDE 的工作方式高度相似，只不过相关企业不一定使用这个名字。
报告里还有一个数字，能进一步验证这个判断：由外部专业团队深度交付的 AI 项目，最后能真正部署起来的比例，大概是企业自己从头自建的两倍，背后的关键，是有没有人“把技术翻译成业务结果”。这个结果其实有点反直觉。论懂自家业务，内部团队肯定比外人更懂，照理说应该是内部团队更在行才对，怎么反倒是外部团队效果更好？原因就在于，交付能不能成，拼的不只是懂不懂业务，更是有没有一个角色，从头到尾盯着“把技术变成业务结果”这一件事：嵌进业务现场，按真实的业务结果验收，把产品一点点打磨到业务愿意用。连最懂业务的一方，少了这个专门盯交付的角色，照样难以落地。这更说明，交付本身，就是决定成败的关键环节。
换一个历史的角度来看
讲到这里，我们可以换一个历史角度来分析。当然，这只是我个人很喜欢的一个分析框架，不是严格的历史考证，很多细节不必作为精确结论。
这个框架，就是我们在政治课上都学过的一句话：生产力决定生产关系。每当生产力发生一次大的跃迁，原有的人际协作、分工和组织方式，往往就无法完全匹配，于是组织需要重新探索新的协作方式，这个过程中，也自然会出现一批新的岗位。蒸汽机带来了工厂制和产业工人；电气化和流水线带来了科学管理，以及工业工程师、质量检验员这批新角色；PC 和互联网普及之后，出现的则是软件工程师和产品经理，这些我们今天已经习以为常的岗位。
现在，轮到 AI 了。AI 带来了新一轮生产力提升，而且变化速度很快。按刚才那个规律，原有的生产关系会经历一段无法完全匹配的适应期。今天大多数企业使用 AI 的方式，要么是购买一套标准的 Agent 产品，要么是自己组建团队从头开发，要么是找乙方做定制外包。这几种方式本质上仍然来自上一个时代：购买标准产品，等于默认所有企业的问题都一样，可 AI 落地最难的，恰恰是每家企业各不相同的具体现实；自己从头开发，多数企业既没有足够的工程能力，也负担不起一支长期投入的研发队伍；找乙方定制外包，乙方完成交付后离开，经验无法沉淀，下一个需求又要从头开始。它们都或多或少无法匹配 AI 带来的新生产力，导致的结果之一，就是前面提到的较高失败率。
而 FDE，在我看来，就是企业正在探索的、属于 AI 时代的一种新生产关系。它想回答的是一个新问题：当 AI 能力这么强、落地又这么难的时候，一家企业到底该用什么样的方式，把新生产力组织起来、交付出去、转化成可以衡量的业务结果？
而这一次，一个人可以贯通更多环节
需求侧讲完了，再说供给这一侧的变化。
过去，让一个人承担从需求到落地的整个链条并不现实。从摸清客户现场的真实需求，到把它做成能复用的产品能力，中间要经过好几个角色、好几个月，有可能产品还没做完，客户的业务已经变了。而今天，AI 降低了做产品、改代码的门槛之后，很多环节可以由一个嵌入客户现场的人独立完成：把现场认知带回来，形成解决方案，甚至直接改进产品功能。“把技术翻译成业务结果”这个链条，第一次有机会由同一个人从头贯穿到尾。
现在已经能够看到一些成功样本。Anthropic 有一支叫 Applied AI 的团队，承担的就是 forward deployed 类型的工作。Anthropic 公布的客户案例中，Lyft 的 AI 支持助手让客服问题的解决时间下降了 87% 以上，ServiceNow 的销售准备时间则缩短了 95%。与此同时，Applied AI 团队也分享过一套有代表性的交付节奏：先用一周完成十几场用户访谈、进入业务流程，第二周设计评估，随后几周构建系统、灰度上线，之后再持续与客户一起使用、复盘和迭代。这里需要区分，前两个数字是客户项目的公开结果，后面这套节奏是团队对工作方式的总结，两者可以相互印证，但不能直接画上等号。
到这里，“为什么是现在”的两个方面就形成了闭环：需求侧，交付成了关键环节；供给侧，AI 让一个人第一次有能力贯通整个链条。两边的改变发生在同一个时刻，FDE 才在这个时间点受到广泛关注。放回第一篇的主线来看，进入现场是起点，业务结果是验收，认知回流和产品复利则决定了这套方式能不能规模化。AI 同时降低了贯通这四个环节的成本，提高了迭代速度，FDE 的价值也因此更加明显。
对我们这些有技术背景的人来说，这里面的机会值得认真关注。当会写代码不再是你的主要壁垒，能把 AI 落到真实业务中、交付出结果，就成了更有价值的能力。这个领域需要的能力也不一样：即使是模型能力最强的几家公司，也必须依靠专人逐个进入客户现场。AI 时代更有价值的人，可能不是最会写代码的，也不是最懂模型的，而是那些能站在技术和业务的交叉点上，把两边连接起来的人。这个领域目前仍处于早期阶段。
所以，为什么是现在？因为生产力已经发生变化，而与之配套的新生产关系还没有定型。谁能更早形成可行的实践，谁就更有可能获得先发优势。
04 FDE 的中国机遇与争议
前两篇讲的主要是硅谷的故事。但只要在中文互联网上搜索 FDE，很快就会看到一句流传很广的调侃：中国软件公司 80% 已经是 FDE 了。驻场、外包、ISV、行业解决方案商，国内已经做了十几年，只是换一个英文名字，就能算成新事物吗？
这句话的讽刺意味很重，而且有现实依据。过去十几年，中国 ToB 行业确实有大量依靠人力补足差距的工作：工程师进入客户现场，逐项解决具体问题，完成后再离开。但这些经验始终无法沉淀，第二个客户来了，还是要从零开始。所以这套模式最后大多变成了成本中心和外包业务，利润越来越薄，需要投入的人也越来越多。
那么，FDE 在中国到底是新的机会，还是原有模式换了一个名字？这一篇，我结合自己在神策这十一年的亲身经历，讨论这个问题。
神策这十一年：交付组织是被客户定义出来的
神策是 2015 年成立的，最早服务的客户基本都是互联网公司。那个阶段，我们没有专门的交付团队，整个公司只有一个运维负责远程安装部署，加上一两个售后在 IM 里答疑。产品是标准的，客户自己就能用起来，整个交付非常轻。我们曾以为，这就是 ToB 生意本来应该有的样子。
变化是从服务银行这类大客户开始的。银行项目的复杂度明显更高，标准产品加远程支持无法满足交付要求，于是我们成立了专门的交付团队，做项目制交付。再往后，有的客户明确要求驻场，于是有了长期驻场团队；有的客户需要定制，于是又组建了专门的定制开发团队。到了第四个阶段，为了突破客户 IT 预算的上限，我们开始和部分客户尝试按效果对赌，出现了陪跑类的项目：验收条件不再是“把系统装好”，也不再是“把项目做完”，而是客户的业务真正取得了效果。
回头看这十一年，交付的验收标准，其实发生了三级跃迁：**装好系统，做完项目，跑出效果。**每跃迁一次，交付就更难一级，组织就更重一层。这也是为什么我常说，交付组织不是设计出来的，是被客户需求定义出来的。
接下来的问题是：为什么中国乙方的交付组织会逐步发展成这个样子？
根本原因是风险与责任的错配
要回答这个问题，需要先看清中国 ToB 行业的几个基本特征。我把它们归纳为六个：关系销售、定制开发、价格低廉、拖欠尾款、私有部署、现场服务。生意往往依靠关系获得；签约之后会出现大量定制需求；项目预算却比较低；完成之后，尾款可能还会拖欠很久；系统必须部署在客户自己的机房里；无论是否出现问题，乙方都可能需要随时到现场提供服务。
一句话概括这些现象：甲方希望获得高度定制的服务，但预算往往只够购买标准化产品。
当然，我不是在单纯批评甲方。这个现象背后，本质上有两个原因。第一条，是风险与责任的错配。传统交付里，乙方卖的是工具，甲方要的是结果。仅仅装好系统，价值难以衡量，效果不好时责任也无法界定，风险几乎都由甲方承担。对甲方来说，只能使用现有的手段降低风险：压价、要求定制、要求私有部署、拖延支付尾款。重新看一遍这六个特征就会发现，其中大多数，本质上都是甲方在风险错配之下的理性反应。第二条，是乙方的产品抽象能力无法满足不同甲方的特异性需求。开头说的那个老问题，根源就在这里：人力补了十几年的 gap，经验就是沉淀不进产品。
这背后其实还有一个更基础的问题。传统 ToB 软件成立有一个前提：卖的从来不只是软件，而是一套被固化进软件里的标准管理流程。这套逻辑在西方能够成立，是因为那里的管理流程本身比较标准、稳定，经过了几百年的逐步发展。而中国把三次工业革命压缩到几十年里走了一遍，在标准化管理流程这件事上，我们还有很多欠账。很多中国企业的流程不是事先设计出来的，而是在业务发展中逐步形成的，因人而异，更因老板而异，而且随时在变。于是出现了一个明显的错位：**标准的软件，遇到了不标准的流程。**软件能够安装，实际使用时却处处不匹配。前面所说的定制、驻场、拖欠尾款，很多都是这个错位带来的结果。
那么，解决办法是什么？如果流程本身无法标准化，就不能再期待一套标准软件适配所有客户。可以派既懂业务又懂技术的人进入现场，按照客户真实的、即使并不标准的流程，逐个场景交付 AI，让软件适配流程，而不是要求流程适配软件。这恰恰是 FDE 模式的思路。
六个现实问题：这些质疑都有依据
当然，FDE 模式想在中国落地，还要面对一系列现实问题。2025 年底我写过一篇文章，专门讨论 FDE 在国内会不会水土不服，我把行业里的质疑归纳成六条。
- **第一个是利润问题。**Palantir 的 FDE 新人总薪酬在 20 万到 25 万美元，资深的能到 30 万到 45 万美元，折算到国内就是百万级的年薪，而国内项目的客单价和利润率难以支撑这个水平。
- **第二个是人才问题。**优秀的人才不愿意驻场，因为工作辛苦、压力大，而且很多甲方对乙方驻场人员也谈不上尊重。
- **第三个是晋升问题。**传统 ToB 公司里，驻场工作做得好就会被调回总部担任管理者，最有经验的人反而离开了一线。
- **第四个是抽象能力问题。**Palantir 有本体论这样的方法论和平台，能把现场经验沉淀成可复用的产品能力，国内很多公司缺少这种能力，容易变成一次性定制开发。
- **第五个是组织问题。**FDE 需要得到充分授权，在客户现场快速决策，而国内公司普遍管控严格、审批流程较长。
- **第六个是市场问题。**国内 ToB 市场低价竞争很普遍，客户容易被“看起来差不多但便宜很多”的方案吸引。
这六个问题是不是真的？我必须承认，都是真的，而且都很严重。我自己早期就遇到过其中的问题：客户希望我们派人驻场，我们很快发现，如果每个客户都派人，成本会高到无法规模化。坦白讲，如果放在过去，可能的确没有哪家公司能够真正解决全部六个问题，包括神策自己。
但我个人的判断是，不能一概而论。这些质疑基本都来自传统 ToB 软件时代的经验，AI 的出现的确改变了其中一部分条件，但它不会自动解决全部六个问题。抽象能力和利润问题，受到 AI 的直接影响；人才、晋升、组织和市场问题，仍然需要公司与客户共同调整。
AI 带来的变量
AI 直接带来的变量有两个，本质上都指向同一件事：生产力这一侧，变了。
**第一个变量，AI 降低了“沉淀”的成本。**借助 Agent 和知识库，FDE 在现场积累的行业 know-how、客户的真实流程和遇到的问题，有可能被低成本地抽取、整理和结构化，变成可复用的产品资产。第一篇讲过，现场经验如果不能回流到产品，深度交付最后还是会退化成定制开发。AI 没有替公司完成这件事，但让认知回流更容易发生了。
**第二个变量，AI 改变了部分项目的价值计算方式。**其一，AI 项目的交付比传统软件更难，每家企业的流程、数据、场景都不一样，标准 SaaS 很难全面适配，而 FDE 模式适合处理这种差异。其二，AI 交付的价值除了体现为流程效率提升，还可能直接对应可以核算的人力成本节省。一个客服 Agent 如果真能替代 10 个人工客服，它的价值就是每年节省的人力成本，这个价值可能高于原本受 IT 预算限制的软件采购预算。在金融风控、能源调度、智能制造这些领域，一个真正有效的 AI 系统，也可能带来更高的业务价值。如果按效果付费，而不是按功能买断，客单价就有可能支撑高薪的交付团队。同时，AI 放大了优秀个体的产出，一名高素质 FDE 有可能承担过去需要多人完成的部分工作，薪资虽然高，单位产出的成本反而可能下降。这样一来，FDE 在利润上就有了成立的条件。
AI 直接改变的主要是抽象能力和利润条件，剩下的问题仍然要靠组织设计解决。人才问题和晋升问题，本质上都与成长空间有关。优秀工程师不愿意驻场，往往不是排斥驻场这种形式，而是传统驻场工作缺少成长空间。假如把 FDE 定位成深入业务一线的产品探索者，给予充分的自主权；同时重新设计晋升路径，资深 FDE 工作做得好，不再调回总部，而是带队服务更难的客户，甚至进行内部创业、孵化新的产品线，这个岗位的吸引力就会完全不同。Palantir 的很多 FDE 后来成了创业者，这本身就有很强的吸引力。
组织问题和市场问题同样不是 AI 自动解决的。组织文化是战略选择的结果，真要把 FDE 当核心战略，授权方式和协作机制就需要随之调整，而不是把它放在边缘业务里试水。市场则取决于客户是否认可这种合作方式，愿不愿意为真正解决问题的深度服务付费。也就是说，AI 提供了新的条件，组织和市场决定这些条件能不能转化成结果。
这不只是推演，国内已经有公司的财务数据可以提供一个侧面参考。智谱 2025 年底递表港交所，招股书里披露：2024 年总收入 3.124 亿元，整体毛利率 56.3%，其中本地化部署业务，也就是面向政企客户的深度交付，占了收入的 84.5%。一家基础模型公司，收入的主要部分不是 API 订阅，而是面向大型政企客户的本地化部署。需要说明的是，84.5% 是收入结构，56.3% 是公司整体毛利率，这两个数字不能直接推出本地化部署业务本身的毛利率，也不能证明这些项目采用了本文严格定义的 FDE 模式。它能够说明的是，**深度交付可以成为模型公司的主要收入来源；**至于这类交付能不能形成认知回流和产品复利，还需要继续观察。
再看岗位这一侧。MiniMax、月之暗面、智谱这些公司，这两年都在招聘“AI 售前解决方案”“前置部署”一类岗位；Dify 早在 2025 年初，就公开发布过名称明确写着 Forward Deployed Engineer 的职位；到了 2026 年，腾讯云也发布了“前线部署工程师”的岗位，字节、阿里云都有类似的招聘。有人根据招聘平台上的岗位职责做过粗略整理：只调用 API 的工作大概占三成，剩下七成，是把模型部署到客户现场，完成鉴权、对接数据中台、进行合规备案。这个比例没有完整的统计口径，不能直接用来比较中国和硅谷的 FDE 谁承担得更多，但它至少说明，在国内的相关岗位中，部署、集成和合规占了很大比重。这些工作是 FDE 的必要组成部分，但只有继续形成新的产品能力、对业务结果负责，才符合第一篇的完整定义。
另一半答案，在甲方
前面讲的都是乙方和从业者这一侧。但 FDE 模式能否在国内走通，还有一半的答案在甲方：甲方能否转变思路。这也正是第一篇最后所说的双向筛选。具体来说，甲方需要回答三个问题。
- **第一，愿不愿意为“结果”付费，而不仅仅是为“功能”付费？**如果还是按照传统的买断模式，要求乙方提供一个交钥匙的系统，FDE 模式就很难运作。因为它的核心是产品探索，需要在实践中不断迭代，这个过程很难在签合同时就完全定义清楚。
- **第二，愿不愿意为优秀的人才付费？**FDE 的薪资水平高于普通工程师，反映在合同价格上，就是客单价会比较高。如果甲方还是希望以最低的价格买到“差不多”的服务，就很难吸引到优秀的乙方和优秀的 FDE。
- **第三，愿不愿意为过程买单？**FDE 进场的头几周，产出可能只是“把你们的业务学明白了”。这段时间的价值，客户是否认可，某种意义上决定了这个模式能不能开始。
从我的经验来看，的确有部分甲方正在转变思路，尤其是在金融、制造、零售这些对 AI 有迫切需求的行业，他们开始意识到，AI 项目的成功不是买一个软件就能解决的。但这个转变还需要时间。也正因为如此，筛选愿意这样合作的甲方，不是傲慢，本质上是对双方负责：无法接纳 FDE 做事方式的客户，用传统的模式去服务，反而更好。这里面没有对错之分，只有匹配与否。
市场仍处于早期阶段
有一点你可能注意到了：讲美国，我可以引用具体的薪资范围；讲中国，我只能提供招股书和招聘 JD。到今天为止，国内没有公开的 FDE 岗位数量统计和薪资中位数。这个空白本身不能证明这里一定存在机会，它只能说明，国内对 FDE 的岗位定义和市场统计还没有成熟。是否真的有机会，仍然要看企业有没有真实需求，深度交付能不能跑出业务结果，以及这些结果能不能进一步沉淀成产品能力。
当然，这个判断也不能说得太满。今天中国的 AI 落地，正处在需求旺盛、但远未成熟的阶段。某种意义上，这就是早期市场应有的状态：等一切都成熟之后，早期机会也就不再存在了。
如果你在国内做交付、实施、售前，这一篇想说明一件事：你遇到的那些问题，很多是行业的结构性问题，并不全是个人的问题，而这个结构正在发生变化。但判断 FDE 是不是新的机会，最终仍然要回到同一条主线：能不能进入真实现场，交付可以衡量的业务结果，再把认知带回产品，让后面的客户更容易被服务。少了认知回流和产品复利，新的名称最后仍然可能回到传统定制和驻场。
05 FDE 就业市场与岗位全景
FDE 需要什么能力，谁适合做
前三篇讲清楚了 FDE 是什么、为什么是现在、在中国有没有机会。最后这一篇，我们把视角落到个人：这个岗位的就业市场现状如何，一个合格的 FDE 需要什么能力，谁适合走这条路，以及在什么情况下不建议选择它。
先看行情：一年涨了 7 倍的岗位
先看美国市场。虎嗅援引过招聘平台 Indeed 的统计：FDE 相关岗位从 2025 年 4 月的 643 个，涨到了 2026 年 4 月的 5330 个，一年涨了 7 倍。薪酬上，披露薪资区间的岗位里，中位底薪约 17.4 万美元，七成给股权。具体到 Palantir，新人总薪酬约为 20 万到 25 万美元，资深 FDE 则能达到 30 万到 45 万美元。从网上一些公开数据看，FDE 比同公司同级的平台工程师薪酬要高 25% 到 40%。
公司为什么愿意支付这个溢价？因为资深 FDE 离职时，带走的是客户关系、在途部署和难以替代的机构知识，这三项的重置成本远高于薪酬差额。这些数字不能直接变成谈薪公式，但它们可以帮你判断一家公司是否真正理解 FDE：如果岗位要求你同时承担客户关系、生产交付和结果责任，薪酬却仍然按照普通实施或者售前岗位定价，就需要谨慎了。
国内市场目前还缺少可靠的整体数据，但招聘信号已经比较具体：MiniMax、月之暗面、智谱、腾讯云、字节、阿里云都发布了相关岗位。从我身边的变化看，最近有越来越多的企业来问我怎么组建 FDE 团队，也有资深的大厂研发管理者来问 FDE Leader 岗位的面试该怎么准备。虽然这只是我个人接触到的样本，但至少说明，国内的 FDE 正在从概念讨论走向实际的团队组建和人才流动。
岗位画像：资深工程师中大约八分之一符合要求
那么，这个岗位到底需要什么能力？专门研究 FDE 的 Sho Shimoda，把这个角色的典型画像概括为：**一个能写生产级代码，同时能够主持好客户会议的工程师。**前半句是技术基础，后半句是软实力，两者都不能缺少。他还给过一个估计：具备这种复合能力的人，在资深工程师里大约只有八分之一。
八分之一听起来门槛很高，但这种稀缺恰恰是薪酬溢价的来源，而且这个画像里的每一项能力都可以训练。展开来说，我在专栏里用三个切面来描述 FDE 的能力模型：一纵、一横、一软。训练营为了让开营自评和结营复评更具体，又把语义对齐与本体建模单独列出来，形成「一纵、一横、一软、一建模」四个评估维度。它们不是四个相互独立的方向，而是观察同一个角色的不同角度。
第一个切面是“一纵”，指的是技术深度，包括四个方向：生产级编程、数据工程、云与基础设施、安全合规。为什么四项都要求资深水平？因为 FDE 要在客户的系统里，使用客户的数据，并在客户安全策略的约束下编写生产代码。同样一个功能，在自己熟悉的公司环境里上线，和在客户的陌生环境里上线，难度有明显差异。评估自己的时候，可以分别为四个方向打分，不要看平均分，而要看最低分，因为交付能力的下限通常由最弱的那个方向决定。
**第二个切面是“一横”，指的是能力广度。**对 FDE 来说，这一横覆盖五个能力簇：软件工程、AI 与机器学习、集成、交付、沟通。其中纯技术只占两个半，因为集成只有一半是技术，另一半是理解客户流程、协调现有系统和相关团队。而剩下的部分，正是 FDE 和普通资深工程师拉开差距的地方。有位资深 FDE 在受访时说，这个岗位不负责产品的某一个具体功能模块，而是要对整个产品有大约 70% 的全面了解。FDE 不一定要在某个模块上做到全公司最深，但当客户问到整个链路上的任何一段时，都需要能够理解并清晰地说明，而且在必要时能够进行修改。
**第三个切面是“一软”，也就是现场软实力，**这是大部分典型程序员需要补足的部分：进入一个陌生行业，能不能耐心把工作流画清楚，直到理解客户的业务术语；面对比自己年轻、但更懂业务的一线人员，能不能先放下预设答案，耐心向他们请教；听到客户说“帮我做一个功能”，能不能继续追问，把这句话翻译成一个可以衡量的业务结果。如果不能向非技术决策者解释清楚 AI 能做什么、不能做什么，项目就很难真正部署。
**第四个评估维度是“一建模”，**也就是 AI 时代 FDE 特有的语义对齐与本体建模能力，这是 Palantir 提出并发扬光大的方法。它横跨数据工程、系统集成和业务理解，单独列出来，是因为训练营需要分别检查业务本体、实体解析和指标语义能不能真正落进系统。简单来说，就是进入一个客户现场，能不能把这家客户的业务名词和动词建成模型，比如零售行业的会员、商品、订单、门店，以及它们之间的关系；能不能把不同系统里口径不一致的指标，定义成可以追溯的语义层。Palantir 的实践反复证明，没有客户专属本体的大模型应用，在企业里很难长期运行，而建本体是工程工作，不是写几条 prompt 就能完成的。它可能是最能把 FDE 和普通工程师区分开的一项技术能力。
把四个评估维度放在一起，会得到一个有点反直觉的结论：FDE 可以有面向新人的岗位，但没有真正意义上的入门级职责。OpenAI 公开的 FDE 岗位，要求至少 5 年工程或技术部署经验；Anthropic 的要求也类似，需要至少 4 年技术和客户工作经验。Palantir 会公开招聘应届毕业生，但也明确说明，即使是应届生，入职第一天也要面对真实客户、承担真实责任。也就是说，公司可以招聘新人，但职责本身并不会因此降低要求。
面试考什么：四轮结构
这套能力模型，映射到招聘上，Shimoda 给过一个四轮面试结构。它的意义，是把 FDE 的复合能力拆开验证：前两轮看候选人能不能把系统设计出来，并写成可以上线的代码；第三轮看能不能把模糊的业务问题拆清楚；第四轮则看能不能在真实的客户压力下沟通和推进。任何一轮单独拿出来，都不足以判断一个人是否适合做 FDE，四轮合在一起，才基本对应前面的四个评估维度。
**第一轮，编码。**FDE 面试的编码，考的是生产级开发能力，而不是算法谜题：可能是给一段真实风格的代码做重构，或者完成一个系统集成的小任务。准备这一轮，与其刷算法题，不如挑一段自己最近写过的代码，向同事讲清楚设计选择、错误处理和边界条件，直到对方能够复述出来。
**第二轮，系统设计。**题目通常会跨云、跨技术栈，甚至故意涉及候选人不熟悉的领域，考察能不能从第一性原理搭建架构。把自己参与过的系统的架构取舍讲清楚，比背十个架构设计模板有用。
**第三轮，问题分解。**比如“某零售客户想用 AI 提升复购，你怎么开始”，考察能不能自己把模糊问题结构化：先澄清目标和口径，复购按谁的定义算、现在的基线是多少；再拆出场景清单；然后排优先级；最后说清第一步做什么、怎么验证。面试官要的不是标准答案，而是“先定义问题再拆解”这套动作是不是你的本能。
**第四轮，客户模拟。**现场有人扮演一位怀疑型的客户干系人，专门提出尖锐问题。这一轮最能检验候选人能不能真正面对客户：面对质疑，不要急着说服，而要先理解对方的情绪，再问出他真正在意的问题。我自己的经验是，先理解情绪再讨论问题，比听起来要难得多。
🐵 还有一个细节值得留意：很多时候，四轮的结果不是打分取平均，而是把四个信号放在一起做定性判断，一轮特别差很难被其他轮救回来，特别是第四轮。当然，这套结构只是一种参考，国内企业对如何招聘 FDE 仍在摸索，未必会完整按照它来考察。
看 JD 的三个观察点
国内使用 FDE 名称的岗位越来越多，怎么判断一个岗位是否符合这个角色的要求？可以重点观察三点。
**第一，是否要求编写生产代码。**美国 FDE 招聘中有相当大比例明确要求这一点。
**第二，出差比例是否较高。**FDE 通常有一半以上时间在客户侧。
**第三，是否背销售任务或者包含销售提成。**在美国 FDE 岗位的统计中，背销售任务的比例为 0，而有销售提成的岗位更接近售前。
满足这三点之后，还要回到第一篇最硬的两条标准：现场认知能不能沉淀回产品，第二个客户是不是比第一个更容易。生产交付和结果责任决定一个项目能不能做成，认知回流和产品复利则决定这份工作是不是真正的 FDE。
谁适合做：起点不同，需要补足的能力不同
硅谷曾经有一个调查，观察到两类转化率最高的 FDE 来源：**一类是前创业者，**他们做过自己的产品，已经承担过与 FDE 相似的工作，弱点是缺乏组织纪律；**另一类是有工程背景的前咨询顾问，**已经具备相应的软实力，弱点是对编写生产代码比较生疏。这两类人的转化率，都显著高于直接从大厂招聘资深研发工程师。
为什么资深大厂工程师的转化率反而不高？有前 Palantir 的 FDE 招聘负责人给过一个解释：这些人往往带着一套成熟的标准做法，进入客户现场之后容易过于依赖既有经验。这个观察，我个人只同意一部分。真正影响转型的不是资历本身，而是资历带来的姿态。我自己现在就带着一个三人小团队，用 FDE 的方式驻场服务做海外营销的客户。我们三个四十多岁的人，要在现场向二十多岁的投手学习，从最基础的工作做起。资历越深，越需要提醒自己，不要把过去验证过的做法直接套到新客户身上。愿意重新学习的资深工程师，技术广度和判断力是年轻人短期内很难补齐的；但如果不愿意放下已有经验和身份，资历就只能成为负担。
对照不同的起点，路线可以这样安排：实施、售前出身的人，已经具备客户沟通和项目经验，需要补足生产代码能力和沉淀意识；研发工程师出身的人，已经具备技术基础，需要补足软实力，然后争取面对客户的机会，哪怕先从参加客户拜访开始；做过技术类产品、还能亲手做原型的创业者和产品经理，更接近 FDE 的画像，需要补足的是生产化能力。至于完全没有技术背景的人，也可以先走一条进入 FDE 相邻岗位、逐步补能力的路线。AI 已经把动手做原型的门槛降了下来，业务理解的重要性则在上升；但原型不等于生产系统，四个技术方向的门槛还在。更现实的做法是，先用 AI 补上原型能力，进到一个离交付较近的岗位，再在真实项目里补生产能力。在达到生产级工程要求之前，这仍然是通往 FDE 的准备阶段，而不是已经成为 FDE。
还有一个问题，是我在留言区和直播里被问得最多的：我在甲方做 IT、数字化或者业务，FDE 跟我有关系吗？我的判断是，甲方人员虽然不一定从事狭义的 FDE 岗位，但完全可以采用 FDE 的工作方法：进入现场找到真实问题，把模糊需求翻译成可以衡量的业务结果，亲手把方案接入真实工作流，再把得到的认知沉淀下来。甲方内部真正的机会，在于解决 IT 系统和业务之间长期存在的问题。所以，更稳妥的做法，不是为了一个自己还没有真正做过的热门岗位先辞职，而是先在权限范围内选择一个真实的小场景，把这套工作完整做一遍。结果既能验证自己是否适合，也会成为争取资源或者寻找新机会的证据。
高薪的另一面：先想清楚再进场
最后，把这个岗位的另一面也说清楚。英文互联网上流传着一种说法：FDE 拿着 40 万美元年薪，却做着全硅谷最辛苦的出差工作。这句话的原始出处已经找不到了，但它的确反映了这个岗位的一部分现实：高薪和高强度，就是一体两面。长期在客户现场、频繁出差、多任务并行，再加上大量与人沟通，这就是这份工作的日常。
我的理解是，这份工作本质上是用高强度换取高密度，而且是三种密度：
- 认知密度，在客户现场能集中接触大量真实业务问题；
- 关系密度，FDE 经常和客户的高管、业务骨干、IT 团队沟通，这种关系网络很难只靠在总部办公室工作来积累；
- 机会密度，这个岗位能通往的职业方向相对更多，继续做资深个人贡献者、转产品负责人、带 FDE 团队，甚至自己创业，都是已经有人走过的路径。
用高强度换取高密度是否值得，因人而异。决定从事这份工作之前，可以先问自己三个问题：
- 能否接受长期出差和在客户现场工作，每周三到四天在客户现场不是前三个月的新鲜体验，而可能是长期常态；
- 能否承受不确定性和复杂的组织关系，需求模糊、口径反复，是 FDE 日常工作的一部分；
- 长期与人沟通之后，是更有精力，还是已经影响生活？
如果是最后这种情况，平台侧工程岗位同样有很好的职业路径，不必勉强转型。
这里不是要劝退，而是希望你在充分了解之后做决定，不要只凭热情，也不要因为岗位热度而盲目转型。正式进入这个岗位之前，需要充分评估客户和项目，也应该同样认真地评估自己的职业发展。对个人来说，进入现场决定了你能接触什么问题，业务结果决定了工作是否有效，认知回流决定了你能留下什么，而产品复利则决定了这些经验会不会不断增加价值。这也是这四篇一直沿用的判断主线。
06 FDE 核心术语表
这份术语表不需要背诵。开营前先浏览一遍，课程中遇到不熟悉的词，再回来查即可。
每个术语分成两层。「正式定义」尽量说明它通常指什么；「这门课里的理解」则说明它为什么会出现在 FDE 项目里。两层并不互相替代，前者帮助我们使用同一种语言，后者帮助我们把术语落到具体工作中。
这份表只收录训练营中反复使用、容易误解，或者会直接影响作业与客户沟通的术语。案例公司、产品名称和普通开发工具不在这里逐一解释。
FDE 与 To B 交付
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| FDE | Forward Deployed Engineer，本课程统一称为前沿部署工程师。FDE 嵌入客户环境，用工程能力解决真实问题并交付可衡量的结果。 | 进入现场只是起点。真正完整的闭环，还包括把现场认知沉淀回产品，让后续客户更容易被服务。 |
| Delta / Dev | Palantir 对两类工程角色的称呼。Delta 围绕一个客户调动多种能力，Dev 用一种能力服务多个客户。 | 这组对照用于说明 FDE 与普通产品研发的工作重心不同。术语表保留训练营会使用的 Delta / Dev，不扩展其他内部角色称呼。 |
| To B / B To B | Business to Business，企业向其他企业提供产品或服务的业务模式。 | 企业项目不仅有使用者，还有决策者、评估者、采购、IT、安全等多方角色。技术正确，不代表项目就能推进。 |
| 甲方 / 乙方 | 企业项目中，甲方通常指采购或使用产品与服务的客户，乙方通常指提供产品、方案或交付服务的供应商。 | 甲乙方只是合同关系中的位置，不代表谁更专业。FDE 需要同时理解客户目标和供应商边界。 |
| 售前 / SA / 实施 | 售前帮助销售识别需求并推动签约；解决方案架构师（Solution Architect，SA）负责方案与架构设计；实施负责把已经约定的产品或方案部署到客户环境。 | 三类角色都可能与 FDE 协作，也可能在实际岗位中重叠。FDE 的区别在于还要进入现场编写生产代码，并对业务结果与产品认知回流负责。 |
| 干系人 | 能影响项目、受到项目影响，或掌握项目所需资源与信息的个人或群体。 | 不能只访谈职位最高的人。需要判断谁有业务目标、谁掌握数据、谁承担风险、谁拥有否决权。 |
| POC | Proof of Concept，概念验证，用较小范围验证某个技术或方案是否可行。 | POC 只回答“这条路是否可能走通”，不能直接证明系统已经达到生产要求，更不能代替业务效果验收。 |
| 试点 | 在受控的用户、数据、时间或业务范围内运行一套接近正式使用的方案。 | POC 主要验证技术可行性，试点则进一步验证系统进入真实工作流后是否有效、稳定，组织是否愿意采用。 |
| MVP | Minimum Viable Product，最小可行产品，用最小范围验证核心价值假设。 | MVP 要形成一个能够进入真实工作流、产生证据并支持下一轮判断的最小闭环，不能只把 demo 的功能删减一遍。 |
| SOW | Statement of Work，工作说明书，用来约定项目范围、交付物、双方责任、时间计划和验收方式。 | SOW 要提前说清楚“做什么、做到什么程度、用什么证据验收、哪些事情不在范围内”，避免双方到了验收阶段再解释边界。 |
| 里程碑与里程碑付款 | 里程碑是项目中可以确认的阶段性成果；里程碑付款是达到约定成果并完成确认后触发的付款安排。 | 里程碑不能只写日期，还需要绑定交付物、通过条件和确认人，否则付款节点仍然会产生争议。 |
| SOP | Standard Operating Procedure，标准作业程序，用来规定一项重复工作按照什么步骤完成。 | FDE 需要先理解客户真实 SOP，再判断哪些环节应该保留、改变或交给 AI，不能只把现有流程原样自动化。 |
| 人天 | 以一个人工作一天作为工作量或报价单位。 | 人天适合估算投入，但不能直接代表客户价值。FDE 如果只靠增加人天获得收入，很容易失去沉淀产品能力的动力。 |
| 变更单 / 需求蔓延 | 变更单是对原范围、成本、排期或验收标准作出的正式修改；需求蔓延是新增要求不断进入项目，却没有同步调整这些约束。 | 客户提出新要求并不等于团队必须免费完成。需要先判断它属于原范围内澄清，还是需要重新确认的项目变更。 |
| SLA | Service Level Agreement，服务级别协议，用来约定可用性、响应时间、恢复时间等服务标准。 | SLA 管的是服务质量，不直接等于业务结果。模型供应商或外部系统达不到 SLA，也会成为 FDE 项目的供应商风险。 |
| 验收 | 依据事先约定的范围、指标和证据，判断交付是否达到要求。 | 训练营里的验收同时看技术结果和交付结果：系统是否正确运行，客户是否基于证据确认项目价值。 |
| 回款 / 应收账款 | 回款是客户按照合同支付款项；应收账款是已经形成收款权利、但尚未收到的款项。 | 项目完成技术工作并不代表已经回款。范围、验收证据和付款条件没有提前对齐，都会让应收账款长期挂账。 |
| 客户成功 / CSM | 客户成功是帮助客户持续获得预期价值的一组工作与职责；CSM 是 Customer Success Manager，客户成功经理。 | FDE 会与客户成功团队协作，也会关注长期业务结果，但 FDE 不等同于客户成功岗位，更不以续约本身代替价值判断。 |
| 续约 / 增购 / NRR | 续约是客户继续购买原服务，增购是扩大产品、席位或服务范围。NRR 是 Net Revenue Retention，净收入留存率，用来衡量同一批客户在流失、降购和增购之后保留下来的收入。 | 这些指标反映客户经营结果，但不能代替对单个 FDE 项目的业务价值判断。 |
| SaaS / 私有化 / 混合部署 | SaaS 由供应商统一托管并通过网络提供；私有化部署运行在客户控制的环境中；混合部署把两种方式组合使用。 | 部署形态会改变数据边界、升级方式、运维责任和模型选择。不能只把它看成安装位置不同。 |
项目定义与交付方法
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| 北极星指标 | 能够集中反映一项业务是否持续创造核心价值的关键指标。 | 课程要求它同时满足三个条件：与商业价值强相关、客户能够通过自身行动影响、能够被继续拆解和归因。选场景、做验收和谈结果付费，要尽量使用同一把尺子。 |
| 基线 | 在方案实施前，用统一口径记录的比较起点。 | 只写“上线前的数据”还不够，需要固定对象、时间窗、计算方法和数据来源，后续才能判断变化是否真实发生。 |
| Demo-driven / demo 内循环 | 用可以运行的系统持续获得真实反馈，并据此迭代产品和方案的开发方式。 | demo 不是每周汇报。它要端到端跑通一条窄链路，把客户的模糊意见变成具体工单、责任人和下一步行动。 |
| MVA | Minimum Viable Architecture，最小可行架构，用最少工程投入验证架构中的关键风险。 | MVP 主要验证价值，MVA 先验证“承重柱”：真实数据和长尾问题、数据与工具能否接通，以及真实规模下的延迟、并发、成本和失败兜底。 |
| gap | 现有产品或方案能力与客户真实需求之间的差距。 | 先判断 gap 是通用还是客户特有、阻塞还是增强，再决定做进平台、放进隔离层、进入产品需求池，还是明确延后。 |
| 负债区 / 隔离区 / 资产区 | 对客户项目代码按长期复用和维护方式划分的三个区域。负债区把特殊逻辑写死在客户实例；隔离区把特殊逻辑放入统一代码库并通过开关或配置隔离；资产区把需求抽象成通用平台能力。 | 代码写在哪里，决定它最终是长期负债还是可复用资产。既不要把特殊逻辑留在客户实例里，也不要把伪装成通用需求的特殊逻辑硬塞进平台。 |
| 内环 / 外环 | 内环围绕单个客户发现问题、构建方案并交付结果；外环把多个现场的共性认知沉淀为可复用的产品、工具和方法。 | 内环保证这次项目做成，外环降低下一个项目的边际成本。只做内环，团队容易陷入持续定制；只有外环，没有现场证据，也容易闭门造车。 |
| 平台提交 / 前后方握手 | 平台提交是把现场学习结构化地转交给产品或平台团队，形成有负责人、有评审节奏的路线图条目；前后方握手是双方共同管理这些提交的固定协作机制。 | 一份有效的平台提交要写清现象、根因、建议和受益面，不能只转发客户原话。AI 可以缩短交接链路，但不能省掉产品化决策。 |
| 第二客户时间 / 单位经济 / 平台提交率 / 产品化速度 | 第二客户时间衡量同类模式第二次交付比第一次快多少。单位经济观察单次交付的收入与成本结构。平台提交率衡量现场学习进入正式产品路线图的比例。产品化速度衡量共性需求转成可复用能力的速度。 | 这组指标用来检查外环是否真的转动。项目数量增加，不代表产生了复利；下一次交付更快、更轻，现场学习持续进入平台，才说明沉淀正在发生。 |
| 私有知识 | 在具体项目中形成、与客户环境和决策过程密切相关，尚未公开或结构化的知识。 | 被否决的方案、客户的真实约束和现场判断都可能成为私有知识。FDE 要先处理保密边界，再把可复用部分沉淀为评估集、模板、规则或产品能力。 |
| 服务陷阱 | 服务收入增长依赖人员和定制工作近似同比增长，单个项目经验又难以复用的经营状态。 | FDE 不是拒绝服务，而是通过外环沉淀，避免团队只能靠增加人天服务更多客户。 |
| 双向筛选 | FDE 模式需要同时判断团队是否适合深入现场，也判断客户是否具备支持这种工作方式的组织条件。 | 不能只问“我们能不能做”。还要检查客户是否有关键负责人、数据与权限、及时反馈，以及是否愿意为探索阶段投入资源。 |
| 一纵、一横、一软 | 一纵指在某个技术或业务方向上的深度，一横指跨技术、产品与业务的广度，一软指现场沟通、推动和判断能力。 | 这是课程用来理解 FDE 能力结构的简化模型。AI 时代还需要补上一项：把业务世界建模为人和系统都能使用的 Ontology。 |
业务语义与数据
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| Ontology | 对一个领域中的实体、属性、关系、动作和约束进行明确表达的形式化模型，中文通常译为本体。 | 把客户业务里的名词和动词建成一套人和系统都能理解、能够继续落进数据与程序的业务模型。 |
| Object / Link / Action | Object 表示业务对象，Link 表示对象之间的关系，Action 表示可以对对象执行的业务动作。 | 这三个基本元素把“会员与订单是什么、它们如何关联、系统允许做什么”放进同一套业务模型，让 Agent 不只会回答，还能在明确边界内行动。 |
| 业务实体 | 业务世界中需要被识别、记录和处理的对象，例如会员、订单、门店和优惠券。 | 先把对象及其关系说清楚，后面才能统一数据、定义指标，并让 Agent 在正确的业务边界里行动。 |
| 实体解析 | 判断多条记录是否代表同一个现实对象，并进行关联、合并或区分的过程。 | 新旧系统中的两个会员 ID 可能属于同一个人。实体解析要给出可以复现的匹配规则，而不是凭经验手工合并。 |
| 主数据 | 在多个系统之间作为核心业务对象权威记录的数据，例如统一的客户、商品或组织信息。 | 主数据不是把所有字段堆进一张大表，而是先确定权威来源、唯一标识、冲突处理和更新责任。 |
| 数据口径 | 对一个字段或指标的业务含义、计算范围和使用边界作出的明确约定。 | “会员数”“复购率”都不能只写一个名称，需要继续说明分子、分母、时间窗、去重方式和剔除规则。 |
| 语义层 | 位于底层数据和上层应用之间，对业务概念、指标、维度及其关系进行统一定义的一层。 | 语义层让报表、程序和 Agent 使用同一套业务含义，避免每个系统各自猜测“复购率”或“活跃会员”是什么意思。 |
| 数据血缘 | 描述数据从哪里来、经过哪些处理、最后被哪些结果使用的关系。 | 当客户质疑一个数字时，需要能够从结论追溯到计算逻辑、源表和原始字段，而不是只给出最终结果。 |
| 数据脱敏 | 通过掩码、替换、泛化等方式降低数据中的身份识别或敏感信息暴露，同时保留必要的使用价值。 | 脱敏后还要验证权限边界和模型效果，不能因为数据“看起来不像真的”，就默认它已经安全或仍然可用。 |
| 遗留系统 | 已经长期运行、难以直接替换，但仍承载关键数据、接口或流程的旧系统。 | 接入遗留系统不是顺手配一个接口。文档过时、数据不一致、网络隔离和迁移回退，都要作为正式项目工作管理。 |
| MCP | Model Context Protocol，一种让 AI 应用以较统一的方式连接外部数据源和工具的协议。 | 在课程沙盘里，MCP 是 Agent 与业务能力之间的一层适配。真正进入客户环境时，还要补齐鉴权、权限、数据边界、日志和失败处理。 |
AI 工程与生产治理
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| LLM API | 通过程序接口调用大语言模型能力的方式。 | 入营前只要求能够完成一次基本调用。课程重点不在背模型接口，而在把模型能力接入可验证、可治理的生产链路。 |
| Agent | 能够基于目标和上下文进行判断，并调用工具或执行动作的 AI 系统。 | W1 在标准样例上验证、W5 在青禾客户场景验收一条完整行为链：接收自然语言业务目标，结合上下文、本体和指标语义判断下一步，在许可范围内选择工具，再根据工具结果给出可以追溯的结论、理由或证据。Agent 不只是能够对话，也不是按照写死流程调用接口。 |
| 工具调用 | 模型按照约定的接口请求外部程序执行查询或动作。 | 查询会员和给会员发券是两类风险完全不同的工具调用。会调接口只是第一步，还需要处理鉴权、白名单、确认、幂等和失败。 |
| Workflow | 按照预先定义的步骤、条件和分支执行任务的工作流。 | 确定性强的环节不必全部交给模型判断。固定工作流可以成为 Agent 的工具或护栏，但不能替代 Agent 对业务目标的理解、判断和工具选择。 |
| RAG | Retrieval-Augmented Generation，检索增强生成，在模型生成答案前，从外部知识源检索相关内容并加入上下文。 | RAG 是一种常见实现方式，不是所有企业 AI 问题的默认答案。课程不会把向量库选型和 RAG 基础作为主线。 |
| 评估驱动开发 | 在实现和迭代系统的同时，先定义什么叫“好”，并用可重复的评估持续约束每次修改。 | 评估不是开发完成后的最后一道验收。模型、提示词、数据或架构一变，都要重新跑评估，发现退化就不能直接发布。 |
| 评估集 | 用一组有代表性的输入、预期结果和判定标准，衡量系统表现的数据集合。 | 评估集相当于 AI 系统的测试样本，需要覆盖正常情况、异常情况和安全对抗情况，并随着真实问题持续补充。 |
| 黄金集 / 异常场景集 / 安全对抗集 | 黄金集覆盖核心业务及其预期结果；异常场景集覆盖长尾、缺失和失败情况；安全对抗集覆盖越权、注入和其他攻击性输入。 | 三类集合分别守住效果、韧性和安全。安全失败不能被其他样本的平均分掩盖，必要时应直接阻断发布。 |
| 评测 Harness / Eval Harness | 能够重复运行评估集、调用被测系统、计算结果并记录版本差异的评测执行框架。 | 评估集是“拿什么测”，Harness 是“怎样反复测”。只有两者结合，修改模型、提示词或架构之后，才能知道系统是进步还是退化。 |
| Agent Harness | 围绕模型组织上下文、工具执行、任务状态、恢复和约束的运行机制。 | FDE 可以调整上下文组织、工具结果和执行策略，并用评估证明变化；不要求重新开发通用框架。 |
| Agent 效果调优 | 为实际模型、客户业态和业务目标改进 Agent 行为的工程工作。 | 从 W1 模型基线开始，持续做失败归因、实际修改、前后对照、保留集验证与回归，和数据清洗、系统集成、安全、评估并列。 |
| 棘轮原则 | 一项能力达到新的可靠水平后，就把这个水平设为后续版本不能跌破的下限。 | 真实故障和客户反馈要补回评估集。修复过的问题再次出现，属于明确的回归。 |
| 护栏 | 对输入、输出和系统动作设置约束、检测与拦截机制，以降低越权、注入、错误内容和高风险操作造成的影响。 | 护栏不能保证系统永远不犯错。输入侧要防注入与越界，输出侧要做事实核验与风险拦截，动作侧还要限制权限并保留人工确认。 |
| 最小权限 / 动作白名单 | 最小权限要求主体只拥有完成任务所必需的权限；动作白名单只允许执行事先明确批准的操作。 | Agent 能读取数据，不代表它应该修改数据。权限要按数据、工具、动作和环境拆开，并为高风险动作设置更严格的确认条件。 |
| 审计日志 | 为追溯、复核与问责而保留的系统访问、决策和操作记录。 | 至少要能回答谁在什么时间触发了什么请求，系统依据什么作出判断，调用了什么工具，改动前后是什么状态，以及能否撤销。 |
| 可观测性 | 通过日志、指标和调用轨迹了解系统内部状态，并定位问题的能力。 | AI 系统出错时，不能只看到最终一句错误答案，还需要知道使用了什么上下文、调用了哪个工具、在哪一步开始偏离。 |
| Trace | 一次请求在多个模型、程序和工具之间流转时形成的完整调用轨迹。 | Trace 要能回答谁在什么时间、用什么输入、调用了什么能力、得到什么结果，为调试、审计和责任判断提供证据。 |
| HITL | Human in the Loop，人参与系统的关键判断或执行环节。 | 风险越高的动作，越不能让 Agent 自动完成。是否需要人工确认，要根据错误成本、权限范围和可逆性分层设计。 |
| 幂等 | 同一个请求重复执行一次或多次，产生的最终业务效果与执行一次相同。 | 网络重试不能导致一张优惠券被发放多次。涉及外部动作时，幂等是 Agent 能否进入生产环境的基本要求。 |
| 生产就绪六维度 | 课程用来判断 AI 系统能否进入生产环境的六项检查：评估过线、真实规模下的性能与成本、安全与权限、全链路留痕与决策可追溯、应急与回滚预案、运营与交接流程。 | 上生产需要逐项拿出证据，不能只在某个时刻按下开关。六项中任何一项缺失，都可能让一个好用的 demo 无法成为企业可用的系统。 |
| 硬化阶段 | demo 通过后、正式上线前，对系统进行边界处理、监控、压测、降级和回滚加固的阶段。 | 这段工作不增加显眼的新功能，却决定系统遇到真实规模和异常情况时能不能扛住，因此不能为了赶上线而省略。 |
| 模型网关 | 对多个模型服务提供统一接入、路由、鉴权、配额、日志和策略控制的基础设施。 | 它帮助项目管理模型切换、供应商风险和使用成本，但网关本身不能代替应用层的权限、评估和安全设计。 |
| 成本工程 | 把系统成本当作可观测、可预算和可优化的工程指标，持续管理其构成与变化。 | AI 项目需要核算真实规模下的 token、模型调用、检索、存储和人工复核成本，再通过模型分层、缓存、路由和流程设计优化，而不是上线后才看账单。 |
| 灰度发布 | 先让一小部分用户、流量或场景使用新版本，观察结果后再逐步扩大范围。 | AI 系统的不确定性较高，不能从 demo 直接全量上线。灰度需要同时定义观察指标、停止条件和扩大范围的依据。 |
| 回滚 | 新版本出现问题时，将系统恢复到之前稳定状态的机制。 | 回滚不能只写在方案里，需要提前准备版本、数据和操作路径，并验证出现异常时是否真的能够恢复。 |
效果衡量与商业结果
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| ROI | Return on Investment，投资回报率，常用收益减去成本后再除以成本来衡量投入产出。 | 公式只是起点。项目还要约定收益和成本各包含什么、使用哪个时间窗、数据来自哪里，以及哪些变化可以归因于本次交付。 |
| GMV | Gross Merchandise Value，商品交易总额，表示一定时间内成交商品的总金额。 | GMV 不等同于收入或利润。用它衡量项目时，还要说明退款、取消、口径周期以及系统实际影响的是交易额中的哪一部分。 |
| 归因分析 | 判断一个结果的变化由哪些因素造成，以及各因素贡献多少的分析过程。 | 业务指标上涨，不等于全是系统的功劳。要区分系统作用、客户配合、外部变化和随机波动，并提前约定双方认可的归因方法。 |
| 对照组 / 差分分析 | 对照组是不接受某项干预、用于比较的群体；差分分析通过比较干预组与对照组在干预前后的变化，减少共同趋势带来的误判。 | 这是一种常用的效果验证办法，但前提是两组具有可比性，干预边界清楚，期间没有被其他重大变化污染。 |
| OLA | Outcome-Level Agreement，本课程所说的结果级协议，用书面方式约定交付结果、衡量方法、衡量责任和审核节奏。 | OLA 不是通行的行业标准缩写，而是课程用来把结果责任落到合同和协作过程中的工具。它既要写供应商承诺，也要写客户需要提供的数据、权限、反馈和流程配合。 |
| RaaS | Result as a Service，按结果付费的服务模式。 | 它不是一句“没效果就不付费”。要先用基线、归因和 OLA 说清楚结果怎么计算、双方各承担什么责任，以及基础费用与结果分成如何组合。 |
训练营工程与教学工具
| 术语 | 正式定义 | 这门课里的理解 |
|---|---|---|
| Starter Repo | 课程提供的标准 Agent 产品底座、客户交付仓库和配套工具。 | 它不是一个等待学员从头填满的空项目。12 周都在同一个客户交付仓库上持续演进，标准产品底座默认不直接修改，客户化代码、连接器、评估和产品补丁需要保持清楚的责任边界。 |
| 标准 Agent 产品底座 | 具备明确业务能力、执行机制和扩展接口的可运行 Agent 产品。 | W1 已能在独立样例上澄清条件、筛选会员、比较消费、给出建议和证据，并通过独立标签 API 演示受控动作。青禾的数据、语义和系统需要学员后续适配。 |
| 客户交付扩展层 | 围绕具体客户的数据、业务语义、系统接口和生产约束进行开发的工程层。 | 这是学员主要写代码的区域，包括数据适配、本体与指标语义、Agent 业务工具、连接器、权限、评估和上线配置。客户专属逻辑不能直接写进标准产品核心。 |
| 产品扩展或补丁 | 标准产品现有扩展点无法承接客户需求时，对产品通用能力作出的补充。 | 先证明问题不能只在客户层解决，再说明它会影响哪些客户、是否值得回到产品主线。不能为了展示开发量而重复实现底座已有能力，也不能为了满足作业要求强行修改产品核心。 |
| Delivery Manifest / 交付清单 | 记录本周新增代码、所属责任层、依赖版本和测试证据的结构化清单。 | 不同技术栈可以采用不同的内部目录，但需要通过交付清单说明哪些属于标准产品、客户化开发、连接器、评估或产品改进。 |
| 产出物契约 | 对文件位置、字段、类型、统计口径和跨周引用方式作出的明确约定。 | 课程不按框架或代码目录判分，而是检查交付结果是否符合契约，因此不同技术栈可以完成同一项作业。 |
| Checker | 对可确定验证的产出物进行自动检查的工具。 | Checker 检查格式、字段、关键结果、权限用例和回滚结果等内容；架构取舍和沟通判断仍由助教与答辩评估。 |
| Checkpoint | 在一个阶段结束后提供的标准中间状态或参考产出物。 | 某一周掉队时，可以从 checkpoint 继续后面的项目。它不会覆盖个人实现，也不会提前透露未来剧情。 |
| Mock 服务 | 按照固定接口模拟真实外部系统行为的服务。 | W1 提供有状态的样例标签 Mock，W8 提供青禾发券、标签 Mock API，均通过真实 HTTP 调用。它只覆盖课程任务需要的最小能力，不是完整 CRM 或营销平台。 |
| Rubric | 对作品从哪些维度、按照什么标准进行评价的评分规则。 | Rubric 负责判断架构、沟通和交付质量；能够完全确定的格式与结果交给 Checker。学员提交前可以据此自查，而不是等答辩时才知道标准。 |
| 技术门槛 / 交付门槛 | 技术门槛判断系统能否正确、安全、稳定地工作；交付门槛判断需求、证据、沟通、验收和责任边界是否成立。 | 两道门槛不能互相抵消。W1 标准样例与 W5 客户任务中，Agent 的理解、判断、工具选择和结果解释也属于技术门槛。代码写得再好，如果只有固定 SQL、固定规则、固定流程或按钮直连 API，仍然不能通过 Agent 相关门槛；同样，如果没有客户认可的价值证据，也不算完成一次 FDE 交付。 |
| 三档尺度 | 课程对同一能力设置的三个递进层级：在演示环境中跑通、达到生产可用要求、能够迁移到陌生客户环境。 | 第一档看“能不能跑”，第二档补错误处理、监控与回滚，第三档看面对新数据、新系统和新干系人时能否重新完成闭环。 |
| AI 模拟客户系统 | 按角色、信息边界和事件规则模拟客户反馈与项目变化的训练系统。 | 它是课程方提供的客户 Agent，不是学员要交付的业务 Agent，也不负责给代码判分。角色只透露自己应当知道的信息，关键剧情由确定性规则控制，用来训练访谈、澄清和项目判断。 |
使用时的一个提醒
术语的目的，是让我们更准确地讨论问题，而不是让一个普通问题听起来更复杂。如果一个术语无法帮助我们说明对象、规则、证据或责任边界，就应该回到具体业务场景，来得到更充分的理解。
07 FDE 能力自评：你准备好了吗？
这份自评表记录的是个人起点，不是考试，也不对应所谓“初级、中级、高级 FDE”的行业职级。目前行业里没有一套统一的 FDE 分级标准，训练营也不会用一次自评，证明一个人已经能够独立承担真实客户项目。
训练营用四个维度观察 FDE 的能力：一纵看技术深度，一横看能力广度，一软看现场软实力，一建模看能不能把客户业务变成可执行、可验证的系统模型。四个维度之间会有交叉，但各自回答的问题不同，因此需要分别评估。
开营前填写一次，W12 结营时使用同一份问题再填写一次。两次评分都需要留下证据，不能只写一个凭感觉得到的数字。
评分说明
| 分数 | 判断标准 |
|---|---|
| 1 分 | 还不了解这项能力，也没有相关经历 |
| 2 分 | 理解基本概念，在他人带领下参与过 |
| 3 分 | 能在熟悉的项目和明确要求下独立完成 |
| 4 分 | 能在信息不完整、角色较多或约束较复杂的情况下完成，并解释自己的判断 |
| 5 分 | 在多个真实项目中反复完成过，能够沉淀方法、帮助他人，并为结果负责 |
对“一纵”中的技术能力，还可以用三档尺度辅助判断：
- 3 分通常对应能够在熟悉或演示环境中独立跑通；
- 4 分需要达到生产要求，补齐错误处理、监控和回滚；
- 5 分则需要在多个真实项目中，面对陌生客户环境承担最终技术责任。
完成一次训练营沙盘，可以为 3 分或 4 分提供证据，但不能单独证明一个人已经达到 5 分。
评分时不建议计算平均分。FDE 的能力涉及完整交付链路，最弱的一项往往比平均分更能说明当前风险。
一纵：技术深度
生产级编程
面对一项需要进入真实业务流程的功能，我能不能完成主要逻辑，并同时处理测试、错误、状态、日志、监控、灰度和回滚，让系统能够持续运行，而不只是跑通一次 demo？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
数据工程
面对来自多套系统的真实数据，我能不能发现质量问题，处理清洗、关联、实体合并、口径对账和数据血缘，并说明最终结果为什么可信？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
云与基础设施
面对云上、客户机房或混合部署环境，我能不能处理网络、身份、密钥、依赖、资源和发布问题，并在外部服务不可用时给出可以执行的降级方案？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
安全合规
面对客户数据和 Agent 动作，我能不能划清数据边界，设计脱敏、最小权限、动作白名单、审计留痕和人工检查点，并说清楚发生异常时由谁处理、如何停止和恢复？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
一横：能力广度
理解完整链路
面对一个客户需求，我能不能理解它从业务目标、数据、AI 模型、工程实现、系统集成，到上线、运营、验收和产品反哺的完整链路，并说清楚每个环节承担什么职责、彼此如何衔接？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
跨领域定位与取舍
完整链路中的任何一段出了问题，我能不能判断它主要属于软件工程、AI、数据、集成还是交付问题，找到正确的处理路径，并解释不同方案在效果、成本、风险和进度上的取舍？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
完成交付闭环并形成沉淀
我能不能把需求、SOW、里程碑、变更、验收、运营和交接串成一条完整链路，并在项目结束后判断哪些现场经验应该保留为客户专属知识，哪些可以沉淀为评估集、模板、规则或产品能力？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
一软：现场软实力
进入陌生行业
进入一个不熟悉的行业，我能不能耐心把工作流梳理清楚，直到理解客户的业务术语、关键角色和真实约束？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
放下预设答案
面对比自己年轻、职位不高，但更懂一线业务的人，我能不能先放下已有经验和预设答案，认真向对方学习？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
识别真实取舍
看到一个“看起来不合理”的流程或做法，我能不能分清它是真问题，还是客户根据业务条件作出的有意取舍，并用事实验证自己的判断？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
把功能翻译成业务结果
听到客户说“帮我做一个功能”，我能不能继续追问，把这句话翻译成一个有明确基线、目标、时间范围、归因口径、双方责任和验收证据的业务结果？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
管理干系人与推进决策
面对决策者、使用者、技术负责人和怀疑者，我能不能理解每个人真正关心的问题，用对方能够理解的方式说明技术边界，并通过访谈、会议、汇报和变更协商，推动形成明确决定？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
一建模：语义对齐与本体建模
业务本体建模
进入一个客户环境，我能不能识别核心业务对象、对象之间的关系，以及系统允许执行的动作，并把它们表达成一套人和系统都能理解的 Object、Link、Action 模型？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
实体解析与主数据
面对新旧系统中的重复、冲突和缺失记录，我能不能判断哪些记录代表同一个现实对象，制定可以复现的匹配与合并规则，并明确唯一标识、权威来源和冲突处理责任？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
指标语义与执行边界
面对口径相互冲突的字段、报表和业务规则，我能不能把指标公式、时间范围、数据来源、追溯路径、权限和可执行动作定义清楚，并把这些定义落成可以查询、测试和复用的系统能力？
- 开营前评分：____ 分
- 开营前证据：________________________________________________
- 结营评分：____ 分
- 结营证据：________________________________________________
第一次自评后的行动
一纵中，我目前最弱的一项是：________________________________
我给这项判断提供的证据是：________________________________
一横、一软、一建模中，我目前最弱的一项是：________________________________
我给这项判断提供的证据是：________________________________
未来 12 周，我希望分别用哪两项具体产出来验证进步：
- 技术产出：________________________________________________
- 交付或建模产出：________________________________________________
这里的“具体产出”，可以是一段通过测试并带有监控和回滚的代码、一份数据诊断报告、一份可以查询的本体与指标定义、一张干系人地图、一份 SOW、一段客户访谈记录，或者一次能够经受质询的项目答辩。只写“提升沟通能力”或者“加强技术学习”，到结营时很难判断到底有没有发生变化。
W12 结营复评汇总
| 能力维度 | 开营时最低分 | 结营时最低分 | 最有说服力的新证据 | 仍然需要补足的部分 |
|---|---|---|---|---|
| 一纵：技术深度 | ||||
| 一横：能力广度 | ||||
| 一软：现场软实力 | ||||
| 一建模：语义对齐与本体建模 |
复评时主要看证据发生了什么变化，不把分数上涨本身当作结论。训练营能够提供一次连续沙盘、15 项自评所对应的作业证据和一次客户委员会答辩，但真实客户环境中的最终责任，仍然需要在后续项目中继续验证。
08 开营前必看：环境准备指引
环境准备指引
训练营需要一套可以持续维护 12 周的本地客户交付工程。W1 会先运行标准会员运营 Agent，验证自己选择的模型，再判断它与青禾优选需求之间的差距。后续每周在同一个仓库中增加客户能力，留下代码、文档和运行证据。
W1 课程方提供什么
课程方提供完整源码和安装说明。标准产品在独立的虚构样例上，已经可以处理这样的请求：
找出近期消费下降的老会员，比较前后两个时段的消费情况，给出召回建议，并说明依据。缺少时间范围时，先向用户澄清。
W1 的产品包包括：
| 组成 | 可以做什么 |
|---|---|
| 标准会员运营 Agent | 理解自然语言目标，澄清必要条件，选择业务工具，根据结果继续分析，给出建议、依据和限制 |
| SQLite 与干净样例数据 | 导入会员、订单、门店和数据覆盖范围；按固定业务参考日期，筛选人群并比较两个时段 |
| 样例标签系统 | 在本地独立运行的有状态 Mock 服务，提供真实 HTTP API，可以查询、添加和撤销标签，并核对实际状态 |
| 动作示例与连接器 | 形成草案，经用户明确确认后调用标签 API；记录任务状态，识别重复请求，处理失败和查询结果 |
| 基础评估与运行记录 | 运行样例评估，查看模型与工具的调用轨迹，记录模型、数据、提示词和配置版本 |
| 配套工具 | 产品能力矩阵、接口与数据文档、环境自检、作业契约和 checker |
分析任务默认只读。标签动作放在独立的样例演示中，确认权限由程序检查，用户修改对象或参数后需要重新确认。W1 的标签系统只模拟教学需要的业务能力；它是通过 HTTP 调用的独立系统，不是让 Agent 直接修改分析数据库中的动作表。
样例公司、数据和口径独立于青禾优选。后续课程按周发放青禾材料：学员清洗和适配客户数据，导入独立的青禾 SQLite 数据库，再扩展业务工具、客户策略和连接器。原始文件需要保留，导入过程需要可重复执行。
官方技术路径与自主选择
官方产品使用 Python 和 LangGraph。LangGraph 组织模型调用、工具执行及任务状态；确定性代码负责数据计算、权限、确认和外部动作约束。分析数据库采用 SQLite，随 Python 提供，不需要另外部署数据库服务器。
评估默认采用 Promptfoo，可观测采用 OpenTelemetry 和 Langfuse。W1 先提供可本地运行的基础评估和轨迹；W7 扩展客户评估集，W9 接入课程方提供的观测环境。开营前不需要自己部署评测或监控平台，也不要求 Docker。
学员可以选择两条实现路线：
- 复用官方标准产品。在客户层、业务工具和连接器中扩展；可以通过接口使用自己熟悉的后端语言。只有证明确有通用能力缺口时，才修改产品核心。
- 自行开发等价产品。可以选择自己的语言、Agent 框架、内部目录和数据库。课程方通过提供的数据、业务 API、运行行为和标准产出物验收。自建路线仍需完成相同的青禾客户任务和调优证据，底座开发是额外投入。
课程不按框架品牌判分。两条路线都需要真实模型根据目标选择工具，读取工具结果并完成任务。固定 SQL 和规则可以作为工具的实现，但不能用固定输入输出或按钮直连 API 替代 Agent 行为。
入营前准备这六项基础
| 基础 | 开营前完成标准 |
|---|---|
| 后端语言 | 能用一门语言读取文件、处理 JSON、编写简单程序 |
| SQL | 能使用 SELECT、WHERE、JOIN、GROUP BY 完成查询与聚合 |
| HTTP API | 能发出请求，读取正常响应，并处理鉴权失败、超时等错误 |
| 大模型 API | 已用代码成功调用自己选择的模型，知道如何配置端点、模型名和密钥 |
| 本地环境 | 能运行 Python、安装项目依赖、查看日志并连接 SQLite |
| Git | 能获取和维护仓库，保存修改，查看差异；不会把密钥提交到仓库 |
**官方路径需要 Python 3.11 或更新版本，**推荐使用发布包实际验证的版本。精确版本、安装命令和平台验证记录以正式包 README 为准。使用其他语言的学员，也需要能启动课程方的 Python 配套服务，再通过 HTTP 接入。
模型由学员自行选择。教师会使用神策提供的 deepseek-v4-pro 验证官方产品；这不能替代学员对自己模型的验证。教师密钥不随课程包发放。不同模型的工具调用格式、上下文处理和行为可能不同，W1 要先区分接口兼容问题和任务效果问题。
密钥通过环境变量或明确指定的本地配置管理，不写进代码、作业、日志或公开截图。不要在预习阶段猜测包内命令、创建同名空工程，领取正式版本后按其 README 安装。
客户交付工程怎样组织
官方仓库按工程责任划分：
platform/ 标准产品与通用执行机制
customer/ 客户语义、指标、策略、提示词和行业配置
connectors/ 数据及业务系统适配
product/ 标准能力、样例定义及产品配置
sample_data/ 独立的干净样例与导入说明
evals/ 评估集、版本基线和调优对照
patches/ 有证据支持的产品通用能力补丁
tests/ 自动验证
artifacts/wNN/ 按周提交的结构化证据
docs/wNN/ 按周提交的交付说明
tools/ 启动、自检、验收等辅助入口
这是官方路径的责任划分。自主实现可以采用不同结构，但提交文件的位置、字段、稳定 ID、数据口径和接口行为必须符合当周任务书，才能由同一套验收工具检查。
W1 要完成哪些验证
W1 的重点是运行并理解已有产品、建立实际模型基线和首版适配判断。复用官方产品的学员本周不开发青禾业务功能；自建路线需要另外完成等价标准能力。
领取正式包后，依次完成：
- 安装并启动产品、SQLite 和独立标签 Mock，导入干净样例。
- 接入自己的真实模型，跑通一次包含工具调用与结果回填的业务任务。
- 验证缺少时间范围时先澄清；数据未覆盖时说明限制，不能把未知当成零。
- 查看两个时段的工具计算、证据和建议，识别模型说明与程序计算的边界。
- 演示标签草案、明确确认、HTTP 执行和状态查询；检查重复请求、拒绝与支持撤销的情况。
- 运行基础评估，保存失败样本及调用轨迹，区分模型协议、数据、工具和行为问题。
- 生成环境检查与运行证据，用 checker 检查，再根据产品能力矩阵完成 fit-gap。
固定输出的教学回放只用于理解机制，不能作为真实模型已验证的证据。artifacts/w01/environment_check.json 和 artifacts/w01/product_fit_gap.json 等交付物的完整字段，以正式包内契约和 W1 任务书为准，不手工把失败改成通过。
后续 12 周怎样继续开发
标准产品提供一个可运行的起点。青禾的口径、数据质量、系统接口、权限和业务目标仍需要逐项处理。
W2、W3 加载客户语义并实现指标；W4、W5 清洗导入客户数据、合并身份、扩展业务工具，完成青禾建议型 Agent。W6 加入客户权限和脱敏；W7 用客户评估集系统调优；W8 对接课程提供的青禾发券、标签 API；W9 完成审计、观测、成本和发布控制；W10 分析统一发放的模拟试点效果数据；W11 抽取可复用资产；W12 完整验收。
Agent 效果调优是 FDE 的持续开发任务。面对自己选择的模型和客户业态，学员需要调整提示词、上下文、工具设计及 Agent 执行策略，记录修改前后的效果，并解释取舍。评估框架负责测量，Agent Harness 指围绕模型的执行机制，两者需要区分。调优不能靠降低权限要求或修改指标口径来获得更高分。
W8 必须通过真实 HTTP 请求集成所提供的业务 API，不设置“直接写动作表”的替代验收路径。它使用教学 Mock，不代表连接了真实商业客户的生产系统。不可逆业务效果不能宣称可以通用回滚。
现在不需要提前学习什么
开营前不要求模型训练或算法基础，不要求先学完提示词工程、LangGraph、向量数据库，也不要求部署评估和观测平台。相关机制会在当周课程中结合沙盘任务讲解。
出现环境问题时留下什么
向助教提供操作系统、运行时版本、产品版本、执行命令、已经尝试的处理方式，以及遮挡密钥后的错误信息。只写“运行不了”，无法区分安装、网络、模型协议和产品行为问题。
完成基础检查后，等待正式包，按 README 执行安装、自检、模型验证和作业验收。正式包的版本与验证记录是运行要求的事实源。