FDE 交付实战营

Appearance

第三章 需求定义与 SOW ​

3.5 案例：半导体制造商与场景选择 ​

承前：前三节我们讲了需求定义的方法论——北极星、优先级表、SOW、口径。这一节换一个视角：看真实世界里，顶级 AI 公司的 FDE 团队是怎么做"场景选择"这件事的。主角是 OpenAI 与一家半导体制造商的故事：工程师每年花掉近一半的时间排查数百万次硬件测试失败，这个痛点是怎么被识别出来、又被怎么转成一个交付场景的。顺着这个案例，你会看到本章所有方法论的实战版本。

3.5.1 背景：OpenAI 把 FDE 模式推到了公司层面 ​

2026 年 5 月，OpenAI 宣布成立 OpenAI Deployment Company（部署公司），并收购英国的 Applied AI 咨询公司 Tomoro，为这家新实体带来约 150 名有经验的 Forward Deployed Engineers 和部署专家。新公司由 OpenAI 控股，获得超过 40 亿美元初始投资，合作方包括 TPG、Advent、Bain Capital、Brookfield 等投资机构和麦肯锡、凯捷、Bain & Company 等咨询与系统集成伙伴。

为什么一家模型公司要成立一家"部署公司"？OpenAI 在公告里给出的观察是：超过一百万家企业采用了 OpenAI 的产品与 API 之后，一个模式越来越清晰——企业 AI 的下一阶段，取决于企业能否把这项技术部署进真实工作流，以及厂商生态能否帮他们做到。模型越来越强，瓶颈移到了"接线"这一侧。

公告还描述了典型的交付流程，和我们前三节讲的结构惊人地一致：

聚焦的诊断（focused diagnostic）
   →  与客户管理层和运营团队共同选出少量优先工作流
   →  FDE 进入组织内部设计、构建、测试、部署生产系统
   →  把模型连接到客户的数据、工具、控制与业务流程

第一步"聚焦的诊断"对应我们的进场诊断（第 2 章），第二步"选出少量优先工作流"就是用例优先级表（3.2 节）。这个流程不是 OpenAI 发明的——Palantir 用 Forward Deployed Engineer 模式做了快二十年，把工程师嵌入客户环境直接构建生产系统——但 OpenAI 把它抬到了集团战略的层级，说明一件事：需求定义和场景选择的能力，已经是 AI 行业公认的交付瓶颈。

3.5.2 半导体制造商的痛点：近半工程时间耗在"找茬"上 ​

按照课程大纲转述的案例设定：OpenAI 服务过一家半导体制造商，其工程师每年要花费数千小时、接近一半的工程时间去排查数百万次硬件测试的失败，定位每一颗芯片测试失败的原因，是工程师最耗时、最重复的日常。

要理解这个痛点的量级，需要一点行业背景。芯片行业的规律是：验证与测试环节占据整个开发周期的大头——行业分析（如 SemiAnalysis 的 EDA 系列报告）指出，验证环节可占芯片项目总投入的 60-70%，而设计复杂度大约每年增长 50%，设计生产力每年只提升约 20%，这个剪刀差意味着每一代芯片都需要指数级增加的验证工程量。与此同时，芯片制造出来之后，每一颗都要经过大量硬件测试，任何一颗测试失败，都需要工程师在测试日志、工艺参数、设备状态之间来回交叉排查，找出根因——可能是某台设备的漂移，可能是某个工艺窗口的偏移，也可能是设计边角 case。

这是一个教科书级的"AI 可解场景"：数据量大（数百万次测试产生海量日志）、模式有重复性（失败根因在很多维度上可聚类）、专家时间昂贵（资深工程师的小时成本极高）、且根因分析本质上是"在多源数据中做关联推理"——恰好是 Agent 加检索分析的长项。

3.5.3 场景选择的三个判断 ​

这家制造商的场景之所以被选中，不是因为"痛点喊得响"，而是它同时通过了三道筛子——和我们 3.2 节的四维评分完全对应：

第一道：业务价值的杠杆够大。 "近半工程时间耗在排查上"意味着哪怕只自动化 20% 的排查工作，释放的都是资深工程师的产能——这不是省客服外包的钱，是省芯片工程师的钱，人天单价差一个数量级。对北极星式的衡量，可以落到"平均根因定位时长"和"工程师人均处理的失败案例数"这类可测指标上。

第二道：数据可行性相对好。 测试日志、工艺参数、设备状态在半导体厂里本来就强制记录（质量体系要求），数据"存在且结构化程度较高"。注意不是"干净"——测试设备的日志格式五花八门是常态——但至少不需要先造数据。相比之下，很多企业的痛点数据根本不存在，那种场景再疼也要延后。

第三道：风险可控。 失败根因分析是"辅助决策"场景：Agent 给出根因假设和证据链，工程师确认后决定处置。人是最终把关者，Agent 错了会被抓住，不会直接造成产线事故。这比"让 Agent 直接决定关停设备"的风险档位低得多。

把这三道筛子翻译成我们课程的语言：价值 5 分、可行性 3-4 分、成本 3 分、风险 2 分——一个标准的"做"档用例。

3.5.4 这个案例教给 FDE 的三件事 ​

第一件事：真实的痛点自带故事，不需要包装。 "每年数千小时、近半工程时间"这种表述之所以有力，是因为它是客户自己算出来的账。FDE 在诊断阶段最重要的工作之一，就是帮客户把痛点量化成他们自己的账——你替他编的账，签字时他不会认。

第二件事：场景选择要选"数据已在流动"的地方。 半导体的测试数据因质量体系而天然存在；米兰零售商案例（下一章）里，WMS/TMS 的时间戳也因运营需要天然存在。反例是那些"疼在数据缺失"的场景——先补数据采集，再来谈 Agent。判断一个场景时，先问：这里的数据今天流向哪里？有没有人在看？没人看的数据，Agent 也变不出来。

第三件事：OpenAI 自己都承认瓶颈在部署侧。 一家拥有顶级模型的公司，宁可花 40 亿美元成立一家专门做部署的公司——这件事本身就是对本课程主题的最大背书。模型在云端，价值在现场；把两者接起来的那群人，就是 FDE。你在第 1 章读到的"FDE 是交付瓶颈的解药"，在这里有了产业级证据。

3.5.5 回到青禾：用同样的筛子再过一遍 ​

把半导体案例的三道筛子拿回沙盘，检验我们第 2 节选出的"沉睡会员召回"用例：

  • 价值杠杆：召回直接作用于 90 天复购率（北极星），且沉睡会员基数大（诊断结论：按 90 天口径约 25 万沉睡会员），杠杆充分。
  • 数据可行性：订单和触达数据存在，但双轨 ID、标签乱用（数据坑）拉低了可行性到 3 分——所以 W4 的数据诊断是前置里程碑，而不是可选项。
  • 风险：错误召回的代价是打扰会员，有退订率护栏指标兜底，风险 2 分。

结论一致：做。好的方法论在不同行业里会给出同样的判断结构——这就是方法的价值：它让半导体厂和连锁超市共用同一张决策底牌。

3.5.6 半导体的对照面：AI 芯片验证的产业趋势 ​

把镜头拉远一点，这家半导体制造商的案例不是孤例，而是整个行业趋势的一个切片。近两年公开报道里，芯片公司与 AI 的"验证之战"打得火热：

  • 据韩媒报道（2026 年 8 月），三星电子的开发者使用 Claude 辅助客户定制 SoC 的验证工作，把一个原本超过一个月的验证流程压缩到两天——该数字未经独立基准复核，但方向与半导体案例一致：验证环节是 AI 提效最大的切口；
  • 芯片设计自动化巨头 Synopsys 在 DAC 2026 发布了与 NVIDIA 合作的全自动芯片验证工作流，据称将数周的人工设计验证压缩到数小时量级；
  • SemiAnalysis 的分析指出，验证工程师是芯片行业增长最快、也最难招满的岗位——人招不满，AI 来补，这是结构性需求而非风口。

这些信息对 FDE 的价值不是"哇 AI 好强"，而是校准场景选择的行业敏感度：当某个行业的某个环节（芯片验证、物流归因、会员运营）出现"专家时间被重复性排查吞噬 + 数据因质量体系天然存在 + 产业报道持续确认人手缺口"三个信号时，那里的客户大概率已经在找你，或者马上会找你。FDE 读行业新闻的正确姿势，是把新闻翻译成这三问。

回到本章主线：需求定义阶段的产出是一份签了字的 SOW 和一页钉死的口径公式。但纸面上的口径和真实数据之间隔着多远？三个部门三个会员数的病，诊断脚本能不能治？下一章我们进入 W4 的数据现场——那里埋着青禾沙盘的全部地雷，也埋着这一课最扎实的动手练习。

3.5.7 要点总结 ​

  • OpenAI 于 2026 年 5 月成立 OpenAI Deployment Company 并收购 Tomoro（约 150 名 FDE），初始投资超 40 亿美元——产业级证据：AI 交付的瓶颈在部署侧，需求定义与场景选择是核心能力。
  • 半导体制造商案例（据课程大纲转述）的痛点：工程师每年近半工程时间排查数百万次硬件测试失败；价值在于释放资深工程师产能，可行性在于测试数据因质量体系天然存在。
  • 场景选择三道筛：价值杠杆（省的是贵的人的时间）、数据可行性（数据已在流动）、风险可控（人把关的辅助决策场景）。
  • 痛点要量化成客户自己的账；替客户编的账，签字时他不会认。
  • 同一套筛子在半导体厂和连锁超市上通用——方法论的标志，是跨行业的可复用判断结构。

参考资料 ​

（注：半导体制造商案例中"每年数千小时、近半工程时间排查数百万次硬件测试失败"的表述源自课程大纲转述，未检索到公开独立报道；OpenAI Deployment Company 的成立、收购与投资数据以官方公告为准。）