产品化交付 vs 驻场交付：FDE 团队的路线之争

这篇解决的是交付团队负责人最现实的路线选择：预算与人手有限，到底往产品化还是驻场投入。

最值得拿走的是八个维度的对照表和它的读法：两条路线不是优劣关系，而是把成本压在不同科目——产品化压在前期研发，驻场压在边际人力；选错路线的典型表现就是成本科目与收入结构错配。最容易被误用的结论是「产品化更高级」，本文明确反对这个线性叙事。

增量在于把争论拆成商业、产品、身份三个被混淆的层面，指出多数分歧其实出在身份认同而非事实判断；并把二选一改写为排序问题：驻场回答产品该做什么，产品化回答怎么便宜地重复，回流机制是循环的心脏，顺序错了两头亏损。

读完建议做一件事：对照八个维度给团队现状打分，写出一页纸的路线倾向判断，并放进半年度复盘。

—— FDEChina编辑部 · 架构师视角

任何一个做大模型交付的团队，做大到某个规模后都会爆发同一场争论。一派说：交付不能永远靠人堆，要把每个项目里重复的部分抽出来做成产品，标准化、可复制、边际成本递减——这是产品化路线。另一派说：大模型落地的高度定制性决定了产品永远覆盖不了最后一公里，客户要的是能进会议室、能读真实数据、能对结果负责的人——这是驻场路线。两边都有成功的行业证据：一边是各家把平台能力打包出售的公司，另一边是 OpenAI 以数十亿美元级投入组建独立交付组织、把驻场做成本质业务的公开动作（站内 OpenAI DeployCo 复盘 有逐条溯源）。本文不做站队，先把两条路线在八个维度上摊开对照，再分析为什么争论长期无解——因为多数团队真正需要的是混合形态而不是二选一——最后给「怎么选」的判断框架。读之前先给一个立场：这不是两条路线谁更高级的问题，而是把成本压在哪个科目、把知识沉淀在哪个位置的问题。

先定义清楚：两条路线到底在争什么

产品化交付指：把目标客户群的同构需求抽象成标准能力，以平台、工具或解决方案包的形态交付，实施环节尽量模板化，实施人员按手册操作。它的理想形态是「实施即配置」——卖十家与卖一家的区别主要是部署次数。驻场交付指：把资深工程师派进客户现场，深入业务流程与数据，现场定制开发生产可用系统，交付物随客户组织与数据环境而变。它的理想形态是 Palantir 式的深度嵌入——工程师与客户业务直到生产验证全程绑定，站内 Palantir FDE 模式拆解 还原过完整链条。两条路线争夺的资源是同一批：最贵的资深工程师、最稀缺的客户信任、以及有限的交付排期。争论的实质是同一个商业问题的两种答案：同一个客户价值，由产品承载还是由人承载？

八个维度的对照

先给总表，再挑关键维度展开。表中每一条都是结构性差异而非程度差异——程度差异可以靠管理弥补，结构差异只能靠路线选择解决。

成本与规模化：账算在哪个科目

成本结构是两条路线最硬的分野。产品化把成本前置：为了覆盖一类客户，先投入一轮研发抽象出标准能力，之后每新增一个客户的实施成本主要是配置与培训，毛利随客户数上升。驻场把成本摊在全程：每个客户从头到尾消耗工程师时间，收入上限约等于人数乘以人效，这是它被诟病「不可规模化」的原因。但硬账还有另一半：产品化的前置投入只有在需求判断正确时才成立——抽象错方向的研发投入是纯损耗，而大模型场景的需求变化快、成熟度低，押错概率不低；驻场虽然边际成本高，却几乎没有前置赌注，每个项目的成本对应一个真实合同。这笔账的完整读法在站内 FDE 商业模式分析 里有展开：判断指标不是毛利率本身，而是「服务成本换回了什么」——如果驻场换回了产品路线图、数据资产与续约扩张，高人力成本就是投资；如果只换回了项目回款，它就是沉没在人力上的成本。

还有一个常被忽略的账目：交付周期的机会成本。产品化首单慢，是因为抽象本身需要两三个客户样本才能收敛；驻场首单快，但每一个后续客户都在消耗同一批人的时间。换句话说，产品化的慢是一次性的，驻场的慢是每次都发生的。判断团队处在哪个阶段，有个简单的读数：如果你交付十个客户的方案里，八成的实现代码完全一致，产品化的前置投入早就该启动了；如果每家客户的方案从第二天起就分道扬镳，抽象的回报率还远未到拐点。

知识沉淀与风险：资产长在哪里

知识沉淀位置决定了两条路线的长期资产曲线。产品化的知识沉淀在产品里：每个项目的实施经验变成模板、配置项、自动化脚本，资产随版本累积，不随人员流动流失。驻场的知识默认沉淀在人身上：客户口径、环境细节、踩坑经验长在工程师脑子里——这正是驻场深度与灵活性的来源，也是它最大的资产负债表外负债。站内 FDE 交付反模式 里「英雄式交付」与「外包滑坡」两条，本质上都是知识沉淀错位：前者是知识没离开人，后者是知识没回到产品。风险结构同理：产品化的核心风险是方向性赌注（抽象错需求），驻场的核心风险是结构性依赖（关键人流失即项目危机）与规模化天花板。两种风险都真实，没有免费的路线——选路线本质上是选你更擅长管理哪种风险。

客户关系维度的差异也值得单独说清。驻场天然建立信任：客户见过你凌晨排障，见过你为一条业务口径据理力争，这种关系换来的不只是溢价，更是需求输入的优先级——客户愿意把还没写进招标书的真实痛点先告诉你。产品化的客户关系更标准，也更容易被替换：当你的产品只是采购清单上的一行，竞争对手的报价单随时可以出现在下一行。两条路线在关系上的最优解其实一致：用产品建立覆盖，用人的深度建立不可替代性。

路线之争为什么长期无解：三个被混淆的层面

回到开头那场永远吵不完的会，它无解的原因是把三个不同层面的问题混在了一起吵。第一层是商业问题：收入结构应该按复制设计还是按人力设计——这取决于客户结构，后面四个判断问题回答的就是这一层。第二层是产品问题：哪些能力该固化进产品、哪些该留给现场——这是抽象边界问题，答案随模型能力移动，去年必须现场定制的功能今年可能已经标准化，所以这一层的正确答案每季度都会变。第三层是身份问题：团队自认是产品公司还是服务公司——这层最吵，因为它不关于事实而关于认同：工程师不想做实施，销售不想卖还没成型的产品，管理层不想承认毛利结构。把三层拆开会发现，多数团队的分歧其实只在第三层；而第三层从来不是靠争论解决的，是靠把账算清楚、把回流机制建起来之后自然消解的。分不清层次，路线之争就会从战略讨论退化成部门立场之争——那才是真正消耗团队的东西。

混合路线：不是二选一，而是排序问题

现实里活得好的交付团队几乎都是混合形态，但混合不是和稀泥，而是有明确顺序的循环：用驻场回答产品该做什么，用产品化回答怎么便宜地重复。顺序反过来就两头亏损——不做驻场直接产品化，抽象没有现场输入，产品与真实需求脱节，这是大模型产品最常见的死法之一；只做驻场不沉淀产品，团队十年后还是按人头卖时间，站内 FDE 岗位演化分析 描述的 2023 至 2026 年岗位形态变化，底层动力正是头部公司把驻场经验持续回灌平台的过程。组织形态上，混合路线要求两类角色互相理解：驻场工程师要为产品沉淀负责——把客户需求翻译成带场景的产品输入；产品团队要为驻场解耦负责——把驻场的高频定制需求变成配置项与扩展点。站内 FDE 组织设计的四种模式 对比了按客户线、按产品线与按能力线几种切法的利弊，混合路线通常落在「交付按客户切、能力按平台切」的双轨结构上。国内私有化语境还多一层约束：客户环境隔离导致产品迭代难以直接吃到现场数据，混合形态更多靠人做搬运——驻场工程师带回的组件与评测集，因此回流机制的组织化在国内比海外更关键。

怎么选：四个判断问题

落到决策，按顺序回答四个问题。第一问：客户需求是同构还是异构？把目标客户的场景拆开看——如果八成需求可以用同一套能力覆盖，产品化优先；如果每家的核心痛点都不一样且深嵌其业务流程，驻场优先。第二问：数据敏感度与部署形态是什么？客户要求数据不出内网、私有化部署时，产品化的「云端复制」逻辑受限，驻场与私有化产品组合的权重大（国内企业级市场的现实分布见站内 国内私有化交付样本）。第三问：团队的能力密度在哪一侧？有强产品工程能力而缺行业资深人士，硬做驻场会做成低价外包；有行业资深人士而产品化能力弱，硬做产品化会抽错象。能力现状比能力愿景更该作为决策依据。第四问：商业目标是收入规模还是能力建立？要短期收入与市场渗透，驻场见效快；要长期估值与资产质量，产品化与驻场回流的组合才是终局——判断 ROI 的框架见站内 FDE ROI 框架。四个问题的答案组合指向路线权重，而不是非黑即白的结论。

另加一条时间维度的提醒：路线选择不是一次性投票。客户结构会变——从标杆门户客户走向中长尾时，产品化权重就该上升；模型能力会变——标准化的边界随模型推理与智能体能力外移持续移动。把路线评审放进半年度的经营复盘，比一次性宣布「我们是一家产品公司」或「我们是一家交付公司」更诚实，也更抗周期。

小结

把整篇收成三句话。第一，产品化与驻场的差异是结构性的：成本科目、知识位置、风险形态都不同，靠管理技巧弥补不了路线错配。第二，争论长期无解的原因是把它当成了二选一，而健康形态是循环：驻场供给认知，产品化承载复制，回流机制是循环的心脏——回流断了，两边各自退化成反模式。第三，怎么选取决于客户结构、数据敏感度、团队能力密度与商业目标四个变量的组合，而且应该每半年重估一次——大模型行业的需求分布变化太快，去年的正确答案可能正是今年的路径依赖。如果你所在团队还没做过这个判断，站内 你的公司需要 FDE 吗 和 自建还是采购交付能力 是两篇合适的下一步阅读：前者回答要不要建，后者回答建到什么程度，本篇回答建成什么形状。