本期要点
功能做出来、模型能回答后，真实的交付现场依然剩下三层工作：必须沉淀进核心产品的通用处理能力、用插件和配置承接的客户适配逻辑，以及必须由业务人员当面确认的业务含义与边界。在 AI 落地中，不仅要厘清规则，更要在真实场景检验系统是否按规则行动；而完整的 FDE 模式需要同时满足高客单价、共同探索心态与平台纪律，多数团队应当理解现场深度，而非盲目照搬驻场。
记录采齐了，却对不上人
当年我们做企业软件，有一项核心任务：采集一个人在企业内部几个不同应用之间的操作记录。按理说，底层记录抓齐了，任务就算完成了。其实没有。记录拿到了，却对不上这一串操作到底是谁干的。有的页面上混着好几个系统的账号标识；有的系统一发生跳转，人的标识跟着就变了，甚至直接缺失；还有的从同一个入口点进去，背后是好几个互相调用的应用。
这件事，我们光坐在办公室里是定不下来的。只有研发人员坐到现场，亲眼看着业务人员怎么在系统之间切换，才能定下来到底用哪些信息，把操作和人准确地关联起来。
功能做出来了，模型也能回答了，到了客户的真实业务里，为什么还需要懂工程的人？这篇文章用这一个案例，把功能做出来之后剩下的那段工作拆开：现场在解决什么，解决完之后哪些该沉淀进产品，哪些每到一家新客户仍要当面确认。
这件事有个名字
这类工作，在硅谷和企业软件领域有一个名字，叫 FDE（Forward Deployed Engineer，前线部署工程师）。简单来说，就是把懂工程、能写代码的人直接派到客户现场，在真实的业务环境里解决最后一公里的落地问题。
当年我们这么理解、这么做的时候，并不知道这个词。直到后来我读到两位 Palantir 前员工写的文章，看到他们系统化描述的这套工作机制，再回头对照我们当年的实际做法，才发现核心逻辑是高度一致的。
先记住一个后面要用到的区别：理解现场是在做什么，和要不要采用完整的 FDE 模式，是两件事。文章最后一节回答后者。
现场在解决什么：两种完全不同的现场工作
这件事光坐在办公室里定不下来，在需求文档里也写不清楚。一线业务人员实际是怎么操作的，往往属于很难直接写进文档的现场隐性知识。业务人员对自己的日常工作太熟悉了，很多跨系统的切换细节，在他们看来是理所当然的事情，根本不会主动写进最初的需求清单。坐在后方的办公室里，你拿到的往往只是一份高度抽象、丢掉了跨系统切换细节的流程描述。只有研发人员坐到现场，亲眼观察他们面对屏幕时的实际操作，才能做出准确的工程判断，把那些没写出来的现场背景补齐。
Palantir 的前工程师 Nabeel Qureshi 写过一篇文章，里面引用了经济学家 Tyler Cowen 的一句话：“上下文才是真正稀缺的东西（Context is that which is scarce）。”他说，传统的企业软件交付往往只依赖一份列着抽象条目的需求清单，但在真实的业务环境里，最有价值、也最难获取的，恰恰是现场那些写不进文档的真实背景和细节。
更棘手的是另一种情况：客户内部一线做事的人和管理层，对业务流程、目标甚至规则的认识，本身可能就是不一致的。
这时候，现场根本不存在一份现成、统一但只是没写下来的答案等着你去发现。比如一线操作人员最在意的是某个操作步骤会不会增加日常负担，而管理层关注的则是合规要求和审批节点；双方对同一个业务变动该怎么处理，各自有一套理解。工程师坐在现场，理解了现有的操作之后，还需要协助相关人员把各自的目标、约束和分歧摊开理清楚，由他们坐在一起把规矩定下来。
这两种现场工作的性质截然不同：
一种是观察已有做法，把没写进文档的隐性知识找出来；
另一种是协助各方把分歧摆清楚，商量出尚未统一的业务规则。
这两种情况在交付现场非常普遍。尤其是第二种情况的存在，决定了光靠收集现成文档、做几轮调研访谈，甚至在今天靠做一套知识库检索，都远远不够。这些分歧需要懂工程的人和相关的业务人员坐在一起沟通、核对，直到规则明确下来。
留下什么：三层划分与承接方式
既然每家客户的系统环境不同，内部的规则和认识也千差万别，那是不是每进一家新客户，研发团队都要从头去现场看一遍、重写一遍代码？
当然不是。如果每到一家新客户都要从头重做一遍，说明共性能力根本没有沉淀下来，也就谈不上真正的产品化。
当年我们已经有了核心产品。随着找上门来的同类客户越来越多，我们在架构层面，主动把这些在现场解决问题的能力往通用化的方向拆解：
前面提到的账号提取、跨应用操作关联、数据补全，逐步被我们提炼成了核心产品的标准化通用模块；而针对不同客户现场的特殊标识、个性化跳转逻辑，我们就设计了专门的插件机制和配置项，用插件和配置来承接差异。
当时去现场解决具体问题的是这批研发，回到后方把共性能力提炼进核心产品的，还是同一批人。Nabeel 曾描述过 Palantir 的组织架构：他们分成了前线 FDE 和后方核心产品两类工程师；而我们当年是由同一个研发团队承担了这两种职责。组织分工虽然不同，但背后的做事逻辑是一样的：先到客户现场解决问题，再把其他客户也能用到的解决办法提炼成产品功能，后面的项目就能直接复用。
那既然共性能力已经做进产品了，现场是不是就完全不需要研发人员了？
依然需要。后来我们的通用引擎，已经能够把底层复杂的技术字段和系统代码，直接解析成业务人员能看懂的业务概念了。但是，在这些业务数据里，到底哪些变动算正常的业务流程，哪些变动代表值得关注的异常？这必须结合现场的具体业务来判断。通用引擎能完成技术层面的解析，但具体哪一种变动需要告警，依然需要结合客户的业务场景，跟现场业务人员逐条核对规则，确认清楚后才能投入使用。
技术上能解析、能支持，并不等于交付已经完成了。你必须和业务人员坐在一起，把具体规则的含义与边界定下来。
梳理下来，功能做出来之后，现场剩下的工作可以清晰地划分为三层：
- 通用处理能力：比如数据采集、字段解析、跨系统关联和数据补全。这些属于标准的技术能力，必须沉淀进核心产品。
- 客户适配逻辑：比如每家客户独特的跳转路径、特殊的系统标识。这些差异应该用插件和配置机制来承接。
- 具体的业务含义与边界：比如哪些变动算正常流程、哪些指标需要告警、业务的分界线具体划在哪里。这些必须由现场懂业务的人当面确认。
对照前面的案例：账号关联落在前两层；字段解析本身属于第一层，但解析之后哪些变动算正常、哪些算异常，落在第三层。
平时在做交付判断时，其实关键就看一件事：我们当前花力气在做的，是在建立可复用的处理能力，是在适配这家客户的具体系统，还是在跟业务方明确具体的业务规则？如果你手里正在做一个企业软件项目，或者在做 AI 交付，不妨拿出当前的工作清单照着这三层分一遍，看看手头的事项能不能清晰地归入这三个层次中。
规则清楚之后，AI 落地多了一步
在今天大模型和 AI Agent 的落地场景里，即便业务规则已经讨论清楚、写入了提示词或知识库，交付依然没有结束。因为在 AI 系统里，规则清楚之后，还多了一步核心工作：验证系统在真实情境里，到底是不是按规则行动。
Cresta FDE 团队负责人 Jove 曾在公开访谈中举过一个生动的例子：当用户向语音 AI 系统报手机号码或邮箱地址时，中间经常会有停顿。但停顿并不意味着用户已经说完了，语音系统必须能够准确判断到底什么时候该接话。在这里，光是在技术上正确识别出文字还远远不够，系统必须在真实的业务交互中，把对话轮次的节奏处理好。
深入现场去解决问题的工程机制，早在生成式 AI 出现之前就存在了。今天的 AI 并没有消灭现场工作，反而让现场验证变得更加不可或缺。模型本身的输出存在随机性，调用有延迟，系统还需要满足特定的安全护栏和准确率要求，这就带来了更多必须在真实业务场景中反复检验的工程环节。
更现实的问题是，底层模型和 API 接口一直在持续升级和变动。一旦底层模型更新或者接口发生调整，系统原本符合业务规则的行为，很可能就需要重新检查一遍。模型在基准测试中具备了某种能力，绝不等于它进入具体的业务环境后，就能自动兑现预期的业务结果。
所有人都要去现场吗？三个条件与 Hex 的取舍
既然现场工作这么关键，那是不是所有做企业软件、做 AI 的团队，都应该把工程师直接派到客户现场去驻场开发？
Palantir 前员工 Barry McCardel 曾专门写文章分析过 FDE 文化，他的回答非常明确：绝大多数公司，其实都不应该采用完整的 FDE 模式。
因为在他看来，一套真正完整的 FDE 机制，必须同时满足三个硬性条件：
第一，高客单价客户。把资深工程师派驻到客户现场的成本极其高昂，只有客户的合同金额足够大，才能在商业逻辑上支撑这种重度投入的模式。
第二，自下而上共同探索的心态。团队上下都不能带着预设的标准答案去现场，而是要有一线探索的热情，愿意扎进业务细节里和用户一起摸索。
第三，为可扩展性设计的平台，以及一条分清核心与边缘的纪律。平台本身要支持模块化扩展，同时团队要有严格的工程纪律，想清楚哪些差异留在客户侧做适配，哪些共性必须沉淀进底层核心平台。
Barry 还给出了一个非常关键的经营视角：在真正的 FDE 逻辑里，工程师去客户现场，本质上应该算作研发投入和学习机会，而不仅仅是交付成本。因为每一次深入现场，都是在为未来的通用产品收集最真实的用户认知与业务边界。
拿这三个条件来对照我们当年的情况：高客单价客户我们确实具备，这也是当时支撑业务健康发展的关键基础之一；共同探索的心态也具备；核心产品和提炼复用机制已经在运行，当时团队立下的下一步目标，就是希望把系统架构做得更加模块化。
不过更有意思的是，写下这三个条件的 Barry McCardel 本人，在后来创立数据协同平台 Hex 时，却明确选择不采用 FDE 模式。
Hex 做的是标准化的数据分析产品，在客户现场不做任何定制开发。但是，他们的研发团队依然极力贴近真实用户，持续观察用户在实际工作流中怎么使用产品，以此来打磨功能细节。
把 Hex 的选择和完整的 FDE 模式放在一起对照，就能看清一个核心差异：两种做法都让研发团队极力贴近用户，但 Hex 选择的是纯粹的标准产品路线。
所以说，理解现场，和采用完整的 FDE 模式，完全是两码事。
衡量一个团队要不要走完整的 FDE 路线，核心不在于你有没有派人驻场，而在于下面这三个问题：
- 你的不同客户之间，业务差异是否大到必须靠现场工程开发来解决？
- 高客单价客户、共同探索心态、平台设计与边界纪律，这三个条件你现在具备了几个？
- 研发人员在现场学到的认知和经验，到底有没有一条顺畅的通路，能够持续沉淀回你的核心产品里？
名字的用处
底层通用的技术能力具备了，模型能够回答了，交付剩下的是客户适配逻辑与业务含义边界，以及在真实 AI 场景里验证系统是否真正按规则行动。
FDE 这个名字的价值，在于帮我们把已有的现场经验系统化地讲清楚，也让我们更容易对照别人的工程实践，看清自己的项目在什么阶段需要哪一类工作。
把现场遇到的隐性知识提炼成通用能力，沉淀进产品，再用于后续的项目。这不仅是当年做企业软件的底层逻辑，也是今天做知识资产化的同一条路。
参考资料
- Nabeel Qureshi, Reflections on Palantir
- Barry McCardel, Understanding Forward Deployed Engineering
- Jove（Cresta FDE 团队负责人）公开访谈
本期推荐
这期讲的是把现场的隐性知识，提炼成能反复使用的通用能力。MAPS 课程教的就是怎么把你的方法和判断，做成可持续、可复用的 AI 工作流体系。
→ 看看 MAPS 课程
Axton 的 AI 实践工具箱
MAPS 课程 · 从方法论到可交付系统
精英圈 PRO · 深度实践者社群
免费入门课 · 零门槛开始
MAPS 术语词典 & 原典索引：https://www.axtonliu.ai/maps
Responses