深圳的客户第一次在现场问「你们驻场怎么报价」，往往已经试过一轮远程交付：需求文档写完了，系统也上线了，业务侧的采纳率还是上不去。Forward Deployed Engineer（FDE，前线部署工程师）就是为这一段空档长出来的角色。
这篇不谈行业均价，只拆账本结构：人天单价怎么被驻场系数放大，按月计费与里程碑计费各自把风险放在谁身上，以及哪些活根本不该用驻场小队来做。
FDE 不是人力补充，而是把需求发现搬到客户现场
FDE 起源于 Palantir 的嵌入式交付方式。它的职责不是把需求文档里的条目实现完，而是在客户现场把模糊的业务诉求翻译成可运行的规则、数据结构和系统行为，再把结果带回产品沉淀。
2026 年国内对这一岗位的讨论，重心已经从「要不要派人常驻客户现场」转成「现场那几个人到底对什么负责」。据一份对 FDE 在招岗位的分析，FDE 招聘量在 2026 年初同比增长超过 1,000%，在招岗位里出现最多的技能已不只是 Python 与 SQL，而是客户需求发现、问题拆解与 AI 产品判断。
技能重心的位移说明这个角色在往业务侧靠。国内一家数据平台厂商在复盘里把标准写得更直接：「FDE的考核终点不是系统上线，而是业务效果是否达成。」（《2026企业AI落地指南：FDE真实实践》）
与传统驻场开发的差别在交付终点。驻场开发交付的是功能清单，验收看文档条目是否实现；FDE 交付的是业务侧真的用起来，验收看现场跑出来的日志、业务动作和异常处理记录。
与项目外包的差别在计价起点。外包先定范围再定价，范围一变就走变更；FDE 先定现场密度与周期，范围在现场滚动收敛。这两件事在合同里不是同一种写法，报价也不能照抄外包模板。
还有一层容易被忽略：FDE 的产物里有一半不是代码，而是对业务规则的显式表达——哪些单据可以自动通过、哪些必须人工复核、模型判断错了由谁兜底。这部分如果不在合同里约定归属和交接方式，退场后客户留下的会是一套没人敢改的系统。
三种人力模式怎么选：驻场小队、固定范围外包、自研招聘
把需求不确定性、数据敏感度、上线时间这三件事摊在同一张表上，选择会清楚很多。表里的「占优 / 吃亏」说的是在该维度上谁更少返工，不是绝对优劣。
| 维度 | 驻场小队（FDE） | 固定范围项目外包 | 自研招聘 |
|---|---|---|---|
| 需求不确定性高 | 占优：现场问、当天改 | 吃亏：每次变更都走计价 | 持平：方法对，但先要招到人 |
| 数据敏感度高（不出内网） | 占优：可签驻场保密，就地调试 | 看部署形态，私有化才成立 | 占优：人在内部，天然合规 |
| 上线时间紧 | 占优：人到现场就开工 | 占优：合同一签就排期 | 吃亏：招聘周期压不下来 |
| 需要能力沉淀 | 占优：有知识转移与退场条款 | 吃亏：交付即离场 | 占优：能力留在自己团队 |
| 成本可预测性 | 吃亏：人天随现场情况浮动 | 占优：总价固定 | 占优：可做年度预算 |
读表的方法很简单：三个维度里有两个落在「吃亏」，这个模式基本不用再谈。三项全占优的模式不存在，所以真实项目常常是混合形态——接口清晰的后台模块走固定范围外包，规则还在变的业务链路用驻场小队顶上去。
如果你还在三条路线之间摇摆，可以先看自研、外包、驻场三条路线的成本与周期对比，再回到本文往下看 FDE 这一种形态的计价。
自研招聘的问题通常不在能力，而在时间。一个既能读懂业务又能判断模型行为的人，在深圳并不好招，等团队到位再验证需求，窗口期往往已经过去。反过来，如果客户已有这样的团队，只是缺一套把需求变成规则的方法，那该买的是短期工作坊，不是驻场人天。
驻场小队的报价结构：人天、驻场系数、现场成本与退场
一张能被逐项核对的驻场报价单，通常由四块拼起来，缺一块都会在后面扯皮。
- 有效人天与角色单价。按角色分档（现场负责人、后端、前端或数据、算法应用），每档一个单价，再乘驻场系数。
- 驻场系数。同一个人在现场一天，能连续写代码的时间会被打断成几段：进场审批、工位与账号、客户会议、环境受限。系数就是为这部分损耗定价。
- 现场支持成本。差旅住宿、跨城往返、非工作时段配合上线的时间，以及客户临时加派现场人力的部分。必须写清是包干还是实报实销。
- 知识转移与退场。文档、配置、模型版本、运维手册的交接责任，以及并行支持的窗口长度。
驻场系数是整张报价里最容易被含糊过去的一项。我们的做法是把「现场人天」与「远程人天」分列、单价不同，让客户一眼看到多派一个人到现场，钱究竟花在哪里。
需要提醒的是，站内另一篇讲 FDE 驻场工程师怎么用的文章侧重点不同：那篇比的是驻场与远程交付的成本差，本文算的是一张驻场报价单怎么搭起来、条款怎么落。
按月计费与按里程碑计费的差别，本质是把「范围不确定」的风险放在谁身上。
| 计费方式 | 适合什么现场 | 范围变化的风险落在 | 合同要写清 |
|---|---|---|---|
| 按人天计费 | 需求还在现场收敛、需要高频演示 | 客户（多用多付） | 人天上限、驻场系数、现场与远程单价分列 |
| 按里程碑计费 | 关键节点可演示、业务方能当场验收 | 供方（做不完自己承担） | 里程碑定义、演示不通过的返工边界 |
| 人天加里程碑混合 | 多数 FDE 项目的真实形态 | 双方按节点分担 | 人天上限触发后如何重新议价 |
退场条款值得单独拿出来讲，它是驻场项目最常见的纠纷点。至少要写清这几件事：
- 环境与账号如何移交，移交当天的验收人是谁；
- 配置、提示词与模型版本放在谁的仓库，版本号如何对齐；
- 运维手册与故障处置流程由谁写、谁签字；
- 退场前留多长的并行支持窗口，退场后的问题走什么响应通道。
这些条款不是法律套话，它们直接决定报价。愿意把退场写清楚的团队，报价通常高于只报人天的团队，因为交接本身要占人天。
如果你正在算这笔账，把现场约束先发过来——进场审批条件、数据能不能出内网、希望多久看到第一个可演示的增量。直接联系我们核一遍范围与驻场密度，或者先看已公开的案例页面判断形态是否接近。
什么时候不该用 FDE：范围清晰的模块与纯值守
驻场小队不是「更高级所以更贵」的方案，它在四类活上是明显亏的。
- 范围清晰、接口已定义的功能模块。这类活比的是实现质量与工期，固定范围外包更便宜，也更容易验收。
- 纯运维与值守。值班看的是响应时长和覆盖时段，买远程运维合同比派工程师坐在客户办公室便宜得多。
- 成熟产品的部署与培训。标准实施加培训就够，不需要有人在现场重做需求发现。
- 客户技术团队很强、只缺方法。这种情况买短期工作坊与代码评审，比买整月驻场更有效。
判断标准可以收成一句：如果「做什么」已经清楚、只是「谁来做」的问题，FDE 就是过度配置；只有当「做什么」本身要在现场被问出来，驻场才值这个钱。
从我们自己的案例页面记录看，需求最容易被现场重新定义的行业相对集中：截至本次查询，当前可公开访问的案例页面里，零售商业与智能制造的条目数排在前两位，医疗健康紧随其后。这里必须说清口径——这些只是案例页面的数据库计数，既不代表客户授权，也不能当作经过第三方核验的交付成效；但它至少指向一个规律：业务规则散落在多个部门、流程变体多的行业，更依赖现场把规则问清楚。
深圳与大湾区的现场约束：进场审批、数据不出内网、双周演示
优码云在深圳，客户现场集中在大湾区。下面这三类约束几乎每个驻场项目都会撞上，它们也直接进了报价。
- 进场审批。园区访客名单、工位、网络账号、开发机权限都要提前报，临时加人通常要等下一轮审批。这就是驻场系数里那部分损耗的真实来源。
- 数据不出内网。客户要求模型与数据都留在内网时，调试只能在现场环境做，离线镜像、代理转发、日志脱敏都要提前准备。远程能干的活变少，现场人天自然变多。
- 双周演示节奏。每两周给业务方看一次能点的东西，是让需求在滚动中收敛的前提。演示节点也适合当里程碑计费的验收点，比按文档签字更贴近真实进展。
同样的约束放到广州、东莞、惠州的项目上，还要叠加往返通勤，跨城驻场的人天和深圳本地并不是一回事。关于本地交付的具体形态，我们在深圳软件开发专题里写得更多。
如果是第一次在深圳找交付方，报价构成拆解与合作避坑清单那篇更适合当筛选用的对照表，本文则聚焦在驻场人天这一种计价方式上。
常见问题
FDE 驻场工程师报价一般按人天还是按项目？
多数驻场项目报的是「人天单价 × 现场密度 × 周期」，但合同上会同时挂里程碑。纯人天对客户没有上限感，纯项目制又要求范围先定死，而 FDE 的前提恰恰是范围在现场收敛。折中做法是设一个人天上限，超过部分需书面同意。
驻场系数该不该写进合同？
应该。系数不写清，现场一遇到会议、审批、环境问题，双方就会为「这半天算不算工作量」反复拉扯。把系数和现场密度写进合同附件，比事后解释便宜。
三到五人的驻场小队，最短要驻多久才有意义？
取决于需求要跑几轮演示才能收敛，而不是固定周数。经验上，能跑完两轮双周演示、并完成一次退场交接的周期才算有意义；短于这个长度的驻场，大多只是把外包的活搬到客户办公室做。
FDE 和驻场外包只是叫法不同吗？
不是。驻场外包卖的是人力，客户给什么做什么；FDE 卖的是在现场把问题定义清楚并跑通结果的能力，退场时要留下可交接的规则与文档。
数据不能出内网还能做 FDE 吗？
可以，这恰恰是驻场最典型的场景之一。代价是远程可做的工作变少、报价里现场人天比例更高，同时要在合同里约定代码与模型版本的出入方式。