FDE 交付实战营

第一章进场判断

1.2 甲方乙方生态与企业采购流程

承前：上一节我们定义了 FDE——对结果负责的前线工程师。但工程师不是在真空中工作的：你背后站着售前、解决方案、实施、CSM 一整条乙方队伍；你对面坐着甲方的一整套立项、审批、采购流程。很多 FDE 新人栽跟头，不是技术不行，而是搞不清"谁在什么立场上想要什么"——比如把售前的承诺当成产品的能力，把 CSM 的客情当成自己的客情。这一节把整张生态地图摊开，让你知道自己在棋盘上的位置。

1.2.1 一张 To B 生态图：钱、人、货怎么流动

先看图，再解释。这是一家标准 Agent 产品厂商（也就是你的东家）和青禾优选之间的完整生态：

              甲方：青禾优选（企业客户）
  ┌────────────────────────────────────────────┐
  │  增长副总裁 ──► 数字化总监 ──► IT负责人      │
  │      │            （W7才空降）    │          │
  │      │      ┌───────────────┐    │          │
  │      └─────►│   采购/法务/财务  │◄───┘          │
  │             └───────────────┘               │
  └───────────────────┬────────────────────────┘
                      │ 合同、预算、验收
   ┌──────────────────▼────────────────────────┐
   │  乙方：Agent 产品厂商（你所在的公司）        │
   │                                            │
   │  销售(Sales) ─► 售前(SE) ─► 解决方案(SA)    │
   │                    │                       │
   │             ┌──────▼──────┐                │
   │             │  FDE（你）    │◄── 产品团队     │
   │             └──────┬──────┘                │
   │                    │                       │
   │               CSM（客户成功）               │
   └────────────────────────────────────────────┘

钱的流向：甲方预算 → 合同 → 乙方。人的流向：销售最先接触甲方，售前做技术验证，解决方案出方案，FDE 进场交付，交付完成后 CSM 接手维护。注意 FDE 在链条里的位置——前有售前的承诺，后有 CSM 的长期客情，你夹在中间，是唯一真正在客户环境里写代码的人。

1.2.2 每个角色的立场：一句话记住他们

To B 谈判桌上没有"坏人"，只有立场。用一句话概括每个角色：

销售（Sales）：立场是"赢单"。一切为了签合同，倾向于把话说满。他不是骗你，是激励机制如此。他的承诺会成为你的工作量。
售前工程师（SE）：立场是"证明可行"。做 POC、跑 demo。他在干净环境里演示，你要在脏环境里兑现——demo 和生产之间落差越大，你越苦。
解决方案架构师（SA）：立场是"方案合理"。写方案文档、画架构图。方案是纸面的完美，落地时每一处"理想假设"都由你验证或推翻。
FDE（你）：立场是"交付结果"。唯一对业务指标负责的角色。你要向上管理（售前承诺了什么）、向下铺垫（CSM 接手时留什么）。
CSM（客户成功经理）：立场是"续约"。项目验收后接手，关心使用率、满意度、增购。他接手时的体验，一半是你决定的。
产品团队：立场是"标准化"。你的定制需求是他们的 roadmap 负担；但你带回的客户洞察，是他们最珍贵的输入。FDE 和产品团队的关系，本质是"前线情报换标准能力"的交换。
交付/项目经理（PM）：立场是"按计划推进"。排期、里程碑、资源协调是他的地盘。FDE 和 PM 经常抢方向盘：PM 要按计划交付，FDE 要按效果调整方向。成熟的做法是约定变更机制——谁可以触发范围调整、多长时间内必须响应——而不是每次都临场掰腕子。

给新人一个自检问题：你现在能画出自己最近一个项目（或者沙盘项目）的这张角色图吗？每个名字旁边能不能写出一句话立场？写不出来的角色，就是你还没建立沟通线的人——那就是你的风险敞口。

甲方那边同样各怀心思（沙盘设定）：增长副总裁要业绩背书，所以"尽快看到效果"；IT 负责人怕背锅，所以关心安全和集成成本；财务经理控预算，所以关心 ROI 算得不算得出来。第 1.3 节的客户四问，问的正是这些立场背后的信息。

1.2.3 企业是怎么立项采购的：从想法到合同

个人买软件看心情，企业买软件走流程。一家青禾优选规模的企业，一个 AI 项目从想法到合同，典型路径长这样：

企业采购流程（典型）

业务痛点 ─► 立项申请 ─► 预算审批 ─► 供应商筛选
              │                        │
              ▼                        ▼
        决策人签字              POC/试点（1-3个月）
                                       │
                                       ▼
                            商务谈判 ─► 合同 ─► 正式项目
                                       │
                                       ▼
                            验收 ─► 续约/扩产（CSM 接管）

分三个关键阶段说：

第一阶段：立项。 有人（比如增长副总裁）提出想法，内部论证"为什么做"。论证通过后申请预算。立项阶段的产出往往就是一封邮件、一份内部汇报——也就是你在 1.1 节收到的那封信。注意：立项邮件的模糊不是客户不专业，而是立项阶段的正常状态。 客户自己也没想清楚，所以才需要你。

第二阶段：供应商筛选与 POC。 客户会找 2-3 家厂商比较，通常要求先做 POC（Proof of Concept，概念验证）——用一小块真实数据、一个窄场景，验证"技术上行不行"。POC 通过后进入试点（Pilot）：范围稍大，往往开始碰真实业务流程。POC 和试点的区别：POC 证明"能做"，试点证明"做了有用"。

第三阶段：商务与正式项目。 谈价格、SLA、验收标准，签合同，进入正式交付。这里最容易出事的是验收标准——如果合同里写的是"交付一个智能运营助手系统"而不是"复购率提升 X"，你的结果责任就变成了交付责任，前者宽后者严，天壤之别。这是 1.3 节立项四问的延伸话题。

一张表区分三个概念：

阶段	时长	范围	回答的问题	谁拍板
POC	2-6 周	单场景、脱敏或抽样数据	技术上可行吗	技术负责人
试点	1-3 个月	单部门/单门店真实运行	业务上有用吗	业务负责人
正式项目	6-12 个月+	全量部署、进生产	值得规模化吗	决策人 + 采购

1.2.4 你在流程里的位置：进场时该问"我们走到哪一步了"

拿到青禾优选那封邮件后，FDE 的第一个问题不是"需求是什么"，而是"这个项目在采购流程的哪个位置"。位置决定打法：

如果还在立项阶段（连预算都没有）：你的任务是帮客户把立项论证做扎实——客户四问（下节）就是帮他们回答的。此时谈方案为时过早。
如果已经走到 POC：你的任务是设计一个"小而硬"的验证——场景窄、指标明确、周期短。注意 POC 的数据条件（脱敏/抽样）和生产的差距，别让 POC 的成绩单变成生产的墓志铭。
如果直接要正式项目：警惕。跳过 POC 直接上正式项目，要么客户极度信任你，要么客户根本没想清楚。后者概率更大，此时立项四问一个都不能省。

沙盘里，青禾优选的增长副总裁说"产品成熟的话应该开箱即用，希望尽快看到效果"——这句话透露的信息是：客户对流程的认知还在"买软件"时代，可能根本没规划 POC 和试点。你的判断要包含一条：帮客户把流程补对，比顺着客户跳流程干，成功率高得多。 跳过验证直接大干快上，是 AI 项目失败清单上的头几名。

1.2.5 新人最常踩的三个生态坑

讲完角色和流程，给你三个 FDE 新人真实高频的坑，每个坑都对应生态认知的缺失。

坑一：把售前的承诺当成产品的能力。 售前在 demo 里承诺"可以自动分析会员数据生成运营建议"，签约后你进场才发现：产品的接口能取到数据，但"自动分析"需要你们在客户环境里从头搭建提示词链路和评估标准。此时如果你对着客户说"售前乱承诺"，客户只会觉得整个公司不可信。正确姿势是：进场第一天就和售前做一次"承诺清单交接"，把每条承诺分到"产品现有能力 / 需定制交付 / 需二次澄清"三个桶里，带着这张清单去开启动会。对外一个声音，对内分清责任——这是生态里活下来的第一课。

坑二：绕过 IT 直连业务。 业务方（增长副总裁）热情、直接、有预算，看起来是最高效的路径；IT 负责人谨慎、繁琐、流程慢。很多 FDE 情不自禁地绕开 IT 和业务直接热火朝天地干。然后数据接口申请卡在 IT 那里三周没人理，安全评审突然插进来一个"数据出域"的质疑，项目原地熄火。记住 1.2.2 的立场分析：IT 怕背锅，你绕过他，等于亲手把他推向对立面。沙盘设定里青禾优选的数据坑（双轨会员 ID）恰恰只有 IT 能帮你定位，W2 进场诊断你会用到这个伏笔。

坑三：把"客情好"当成"项目稳"。 客户里有人天天请你喝咖啡、夸你的 demo，不代表项目安全。要盯的是生态里的结构性力量：决策人的优先级、预算的周期、干系人的变动。沙盘里 W7 数字化总监空降接管就是结构性变动——发起人对你的信任再深，也挡不住新领导的重新审视。应对方法在 1.3 节埋了：把判断和共识落成书面文档，让项目共识不依赖任何单一的人际关系存活。

1.2.6 真实世界的参照：结果导向的商业模式在成型

沙盘之外，看看真实世界在发生什么——这能帮你理解"生态"不是静态的，而是正在向"结果导向"演化。

最典型的信号来自 2026 年 5 月：OpenAI 宣布成立 OpenAI Deployment Company（部署公司），初始投资超 40 亿美元，由 TPG 领投，Advent、Bain Capital、Brookfield 联合领投，共 19 家投资机构、咨询公司和系统集成商参与——注意这个组合：资本 + 咨询 + 集成商，正是把"FDE 进场交付"变成一种规模化商业模式的完整生态拼图。同一时间 OpenAI 收购了英国 AI 咨询公司 Tomoro，一次性带入约 150 名前向部署工程师和部署专家。这个案例的完整拆解放在 1.4 节。

国内也有对应趋势：传统软件时代的"卖许可证 + 人天实施"模式，正在被 OLA（Outcome-Linked Agreement，结果挂钩协议）、SLA（服务级别协议）、RaaS（Results-as-a-Service，按效果付费）等模式挑战。比如神策数据在与电商客户的合作中探索按 GMV 增长分成的 RaaS 模式——据其公开传播的内容，需要先清晰界定"哪些增长来自 Agent 的运营动作、哪些来自客户自主决策、哪些来自外部因素"，这本质上就是把"对结果负责"写进合同。这种模式对 FDE 的要求只会更高：你不仅要交付系统，还要能证明系统的业务贡献。

这给本章开篇的判断题加了一个砝码：进场判断做得越好，后面的结果承诺才越敢签。 判断，是整个生态链条走向"结果导向"的第一道闸门。

1.2.7 要点总结

To B 生态链条：销售 → 售前 → 解决方案 → FDE → CSM；FDE 是唯一在客户环境写代码、对业务结果负责的角色。
每个角色立场不同：销售要赢单、售前要证明可行、CSM 要续约、产品要标准化——没有坏人，只有立场。
企业采购三阶段：POC 证明"能做"，试点证明"有用"，正式项目才是规模化；跳过验证直接大干是失败高发路径。
进场第一个问题不是"需求是什么"，而是"项目走到采购流程哪一步了"——位置决定打法。
生态正在向结果导向演化：OpenAI 40 亿美元部署公司、国内 RaaS 按效果付费，都在把"对结果负责"变成商业模式。

参考资料

OpenAI launches the OpenAI Deployment Company — 官方公告：TPG 领投、19 家机构参与、收购 Tomoro，"资本+咨询+集成"生态拼图的一手来源。
Klarna AI assistant handles two-thirds of customer service chats in its first month — Klarna 官方新闻稿：AI 客服首月 230 万次对话、承担三分之二客服会话，企业级 AI 结果导向的标杆案例。
从卖工具到卖效果：RaaS如何重塑To B市场格局？ — 知乎 — RaaS（按效果付费）模式与结果归因的分析文章。
Agentic AI的"基建时刻"——从SaaS到RaaS — 界面新闻 — 从 SaaS 到 RaaS 的商业模式演进报道。
Escaping the Cargo Cult — Palantir Blog — Palantir 对交付文化与 FDE 模式的官方阐述。

第一章 进场判断 ​

1.2 甲方乙方生态与企业采购流程 ​

1.2.1 一张 To B 生态图：钱、人、货怎么流动 ​

1.2.2 每个角色的立场：一句话记住他们 ​

1.2.3 企业是怎么立项采购的：从想法到合同 ​

1.2.4 你在流程里的位置：进场时该问"我们走到哪一步了" ​

1.2.5 新人最常踩的三个生态坑 ​

1.2.6 真实世界的参照：结果导向的商业模式在成型 ​

1.2.7 要点总结 ​

参考资料 ​