一家软件公司做完一个大客户项目，通常会留下些什么？
一套上线运行的系统、一份验收报告、若干接口和定制代码、项目文档，以及参与人员的经验。客户如果真正把系统用起来，业务结果也可能已经发生改善。
上面这些内容都很重要。
但如果半年后，另一家客户提出了一个相似的问题，公司仍然需要重新调研、重新设计、重新开发、重新试错，甚至连上一个项目踩过的坑都要再踩一次，那么第一个项目留下的东西，对这家软件公司究竟有没有长期价值？
这个问题，恰恰是FDE模式和传统项目交付或者说高端定制化之间最值得深究的分界线。
我们前面针对FDE模式讲了很多，比如FDE应该具备什么样的责任素质，FDE Squad中应该包含哪些角色、分别负责什么；还有一项FDE Mission不应该止步于上线，FDE Squad还要对业务成果负责；以及成熟的FDE组织应该如何培养人才并建设有序的梯队……但是到了这里，还有最后一个问题需要说透：
FDE怎样把一次次面向特定客户的深度工作，变成能够服务更多客户的产品能力？
如果做了100个项目，只是把第一个项目重复100遍，那是一家经验丰富的项目公司，却不一定形成了软件产品的复利。
真正值得期待的变化是：随着同类问题被一次次解决，下一项Mission能够更快进入Production，产品和平台承担更多通用工作，FDE把精力投入尚未被解决的新问题。
这也就是我们一直在强调的：
Field-to-Product
FDE的规模化，不应当只是复制FDE的人数，而应当越来越多地复制FDE在客户现场学到的东西。
一
做100个项目，不应该把第一个项目重复100遍
先看我们前面提到过的两种增长方式。
一种情况是，一家传统项目公司接到客户A的需求，需要五个人投入几个月。客户B来了，再投入一支类似的团队。客户C也是如此。项目越来越多，收入当然可能增加，但新增收入高度依赖新增人力；只要项目复杂性没有下降，经验就很难转化为持续的成本优势。
另一种情况是，客户A的交付过程解决了一批共性问题：数据接入、权限映射、业务对象建模、AI效果评估、人工复核与证据留存。到了客户B，其中一些能力已经可以直接使用；客户C再来，剩下的差异主要通过配置或有限扩展解决。原本需要深入开发的工作，逐渐变成成熟产品、行业方案或标准交付可以完成的工作。
这才开始有了产品飞轮的雏形。
同类问题每多解决一次，公司就应该比上一次更有能力、更有把握，也可能更低成本地解决下一次。
当然，不应该机械地要求"第20个客户的总交付成本一定比第1个低"。
因为第20个客户可能规模更大、数据更差、监管要求更复杂，甚至从事完全不同的业务。真正有意义的是，在可比场景、相似范围和相当生产要求下，那些已经被解决过的部分，是否不再需要重复投入同样多的FDE时间。
如果每次进入新客户，FDE Squad仍然必须从零开始解释业务对象、手写相同接口、重做同类Eval、补同样的权限能力，那就说明公司的现场经验还没有进入真正可复用的形态。
Gartner在2026年有关FDE定价的研究摘要中就明确提醒：如果一直把FDE当作按工时出售的产品，容易陷入人力规模陷阱；更有利于软件业务的方向，是让FDE服务于平台采用和价值实现，并逐渐降低客户对高强度FDE支持的依赖。
IBM在其Forward Deployed Unit（FDU）实践说明中则提出，每次合作应为客户留下两种成果：本次获得的业务结果，以及能够用于后续工作的资产包，包括业务上下文、测试、Agent配置和方法改进等。这些资产留在客户侧，由客户继续使用。
项目型增长 vs 产品飞轮增长：随着标准能力增加，同类交付中的重复劳动下降
二
Field-to-Product不是"客户提需求，产品排计划"
很多软件公司会说：“我们一直在做产品化。实施团队每个月都把客户需求提交给产品经理。”
但FDE的Field-to-Product没有这么简单。
客户提出明确的功能改进，产品团队评估后纳入Roadmap，排期开发，是成熟软件公司需要的基本机制。问题是，客户说出来的需求，未必就是值得产品化的问题本身。
举一个企业智能审核的例子。
一位客户提出：“希望在审核结果页面里，增加一个证据来源字段。”
如果只按功能需求记录，研发完成一个字段、一个链接，事情就结束了。
但FDE Squad如果已经深入真实审核流程，可能发现更深层的问题：AI给出判断后，业务人员需要核实依据；审核经理需要知道判断使用了什么规则或模型；审计人员需要追溯当时的输入、证据和人工干预；争议发生时还必须能重现决定形成的过程。
于是，“增加一个字段"背后暴露出来的，其实是：
企业AI参与业务判断以后，必须建立一条可追溯、可复核的证据链。
如果进一步看到采购审核、费用报销、合同审查等不同场景都存在类似约束，那么公司要解决的就不再是一张页面的问题，而可能是一组更基础的能力：证据关联、版本留存、人工复核、决策轨迹、权限控制与审计查询。
这里就发生了几次不同层次的转换：
客户提出的功能需求（Feature Request） ↓ 现场暴露的业务与工程约束（Field Signal） ↓ 可被解释和验证的共性模式（Pattern） ↓ 某一层级的可复用能力（Reusable Capability） ↓ 下一个任务中的真实使用与反馈（Next Mission）
**Feature Request是客户提出的答案；Field Signal是现场提供的证据。**两者可能有关，但不能混为一谈。
OpenAI当前的FDE岗位要求中，既强调把方案从原型推进到稳定生产，也明确要求把现场有效模式整理为工具、Playbook或可复用构件，并将Field Feedback反馈给产品与研究团队。这里值得借鉴的并不是某套固定流程，而是把"现场学习"看作FDE的正式工作成果。
从客户需求到产品飞轮：Feature Request → Field Signal → Pattern → Reusable Capability → Next Mission
三
飞轮的第一步：先把Field Signal记录好
这是Field-to-Product的第一步，也是最为关键的一步。
很多需求记录只写"客户希望增加什么功能”，项目复盘只写"遇到了哪些困难"，最后又缺少足够上下文。等几个月后由另一支Squad或者产品团队重新阅读，已经很难判断当时为什么要那样设计。
所以FDE不能只留一个需求标题，更需要保存问题发生时的业务情境与证据。
例如，前面的智能审核案例，相比于只记录一行：
“支持审核结果展示证据来源。”
更应该记录成一条相对完整的Field Signal：
字段
示例内容
现场场景
费用报销审核；AI先行判断，审核员复核例外单据
实际问题
审核员无法快速核实模型结论的依据，必须返回原始单据反复查看
影响对象
一线审核员、审核经理、事后审计人员
当前处理方式
截图、手工备注、在不同系统中查找规则与原始附件
业务影响
增加复核时间，也增加争议处理和追溯难度
现有方案的局限
页面显示一个来源链接，但缺少当时的规则版本、证据片段和人工处理记录
可核查证据
用户操作路径、访谈记录、失败样本、审核记录（经授权脱敏）
初步假设
需要统一证据关联与决策追溯能力，而非单独增加页面字段
后续状态
待在其他审核场景中验证；由指定负责人跟进
上面是一条示意记录，不代表真实企业的调研结果。主要为了表现出两种工作方式的差别：前者记录待开发功能的描述，后者则是保留用于后续判断的完整问题证据。
在实际使用中，可能还需要记录所属Mission、发现日期、问题责任人、来源系统、数据敏感级别、影响规模、关联资产、审核状态和产品侧回应等内容。
当然了，这里的字段也不是越多越好，最重要的是让后来的人能够回答：
为什么当时认为这是个问题？有什么证据？当前判断有哪些不确定性？
另外一点，就是Field Signal最好在Mission过程中持续记录，而不是等到项目结束后补写。因为真正改变产品设计的发现，往往出现在Discovery、Validation、Productionization和Adoption的不同阶段。
例如，技术验证时发现模型缺乏依据是一种Signal；上线后发现审核员不相信判断结果，是另一种Signal；人工复核导致证据无法回写，则可能是第三种Signal。它们彼此关联，却不能简单合并成一条"增加证据字段"的需求。
高质量Field Signal卡片：场景、影响、现状、证据、根因假设和后续验证状态
四
什么时候一个Field Signal可以被认为是Pattern？
收集到现场发现以后，第二个困难马上出现：
“客户A有这个问题，客户B也说过，这是否意味着它们背后存在同一种共性问题？”
有人认为，几个客户提出了相似的需求，就可以合并成一个通用问题；也有人认为，必须有十个客户都提出过，才算找到了共性。
这两种判断都不够可靠。
因为客户的表面诉求相同，不代表根因相同；而某些重要的共性约束，也可能在第一个客户现场就已经显露出来。关键不在于"有多少人提"，而在于我们是否有足够证据说明，一个问题模式会在明确的条件下反复成立。
所以对于Pattern的识别，我更愿意把它理解成：一项有证据支持、适用边界明确、可以继续验证的共性假设。
具体判断时，至少需要看下面几点。
◆ 第一，问题的根因是否相同。
甲客户说"加证据字段"，乙客户说"加审核日志"，丙客户说"看人工复核历史"，表面功能看起来不同，背后却可能是同一种对可追溯性的要求；反过来，如果两个客户都说"审批太慢"，也可能一个是权限设计问题，一个是人工排班问题。所以要透过现象看本质，明确问题的根因是否一致。
◆ 第二，问题出现的边界是否清楚。
这个问题只发生在某一种单据里，还是会发生在一类业务Workflow里？是某一家客户独有的制度，还是同一行业常见的运营要求？能否描述它成立的前提与不适用的情况？只有这些都能够回答清楚，才可能知道这个Pattern可以解释什么，又不能解释什么。
◆ 第三，这种问题是否具有一定的稳定性。
有的问题来自临时的系统迁移或一次性业务调整，换一个时间、换一套系统就可能消失；有的问题来自长期存在的审计要求、组织权限、流程协同或决策追溯，即使界面和技术环境改变，底层约束仍然存在。
需要判断的是问题本身的持续性，而不是现在某个字段或某种实现方式是否稳定。
◆ 第四，现场证据能否支持这个判断，是否存在反例。
如果只根据一次会议里客户的一句话，就断言存在行业共性，很容易过度抽象。最好能够找到用户操作、失败案例、工程约束、使用记录等证据，并主动寻找反例：在什么条件下，这个问题并不存在？换了业务流程以后，是否仍然是同一个根因？
这样既可以避免把两个不同的问题强行合并，也能为后续抽象留下可靠依据。
综上所述，可以形成一张简洁的Pattern识别卡：
识别问题
需要什么证据
证据不足时怎么办
是否存在共同根因？
真实Workflow、失败样本、工程约束
继续调查，不急于合并需求
适用边界是否明确？
客户、行业、场景差异与反例
标明适用条件，缩小假设范围
问题是否具有稳定性？
长期业务约束、外部规范、使用记录
暂按阶段性问题处理，继续观察
是否有可核查的证据？
用户行为、现场记录、验证结果
保留为候选Pattern，补足证据
上面的判断方法，也提醒我们有一种很容易被忽视的情况：有些问题即使暂时只在一个不那么重要的客户现场出现，也可能揭示很有价值的共性约束。
例如，企业级的权限隔离或者模型评估追踪问题，在某个客户现场出现后，未必需要等十个客户都遇到类似问题，才有理由形成候选Pattern并继续验证。
反过来，就算十个客户都要求"审批提速"，也不能因此默认他们拥有相同的根因。
Pattern不是重复需求的统计结果，而是由现场证据、根因分析、适用边界与反例共同支持的可复用假设。
不过，这里还需要划清一个边界：**识别出Pattern，不等于已经决定开发一个产品功能。**它只是说明，我们可能发现了能够跨场景成立的共同问题。接下来还要回答：其中哪些部分可以抽象复用，应该以什么形式留下，以及公司是否值得投入建设和长期维护。
从多个不同需求识别同一Pattern：三种表面不同的需求汇聚到共性约束
五
发现了共性，怎样把它变成可复用的设计？
识别Pattern，是在判断不同客户遇到的问题是否有共同根因。但是同一类问题，并不意味着可以用同一份代码、同一套流程来解决。要让后来的FDE Squad真正少做重复劳动，还需要弄清楚：哪些东西在客户之间保持不变，哪些差异必须允许存在。
仍然用智能审核来说明。
客户A做差旅报销审核，审核对象是报销单和发票；客户B做采购合同审查，需要关联合同条款、付款条件和制度文件；客户C做风险审核，还可能涉及外部报告、模型评分和人工复核意见。三个场景都要求"判断有据可查"，但若直接沿用客户A的页面和字段设计去实现客户B、C，通用模块里很快会塞满针对不同单据和证据的特殊判断。
换一种思路：先不考虑每家客户的界面，而是找出一项审核决定通常需要保留的内容——审核对象是什么，依据来自哪里，使用了哪个版本的规则或模型，得出了什么结论，人工是否修改过，最终采取了什么动作。至于对象是报销单还是采购合同、证据来自附件还是外部报告，则留给不同场景去映射和配置。
这样，“需要保存审核依据并支持事后追溯"是相对稳定的部分，“审核什么、从哪里取证、谁有权复核"是需要适配的部分。后面才有可能形成一套可复用的证据关联和追溯能力，而不是把第一个客户的实现包装成公共组件。
资金预测也是一样。不同客户的数据可能来自ERP、司库系统或Excel，账户口径、资金流项目和组织层级各不相同。但做滚动预测时，通常都要处理预测对象、时间范围、预测版本、资金流入流出及其实际值。把这些较稳定的业务概念与各客户的数据字段、项目映射和预测假设分开，后续才可能复用一部分预测流程。
当然，分离数据差异，不等于预测逻辑就能完全通用。不同企业的现金流来源、结算安排和风险约束仍然会改变模型与业务流程。能复用到哪一步，必须由真实业务决定，不能因为画出了一套标准对象就认为问题已经解决。
这两个例子其实都在回答同样的四个问题：
抽象时要问什么
以智能审核为例
什么相对稳定？
审核结论需要关联依据、判断过程和复核记录
什么必须允许变化？
单据类型、证据来源、规则版本、权限和复核流程
什么不该带到下一个客户？
专有业务规则、客户数据、合同限制复用的实现
怎样知道没有抽象过头？
换一个审核场景，观察是配置适配还是仍要重写核心逻辑
抽象不是追求把所有客户都装进一个巨大模型，而是为共性划出边界，并为差异留下合理的出口。边界过窄，下一项Mission仍然要从头开发；边界过宽，则会出现大量配置项和复杂分支，维护成本可能比重复开发还高。
因此，完成这一步，得到的还只是候选的可复用设计。接下来要考虑的不是马上把它交给核心研发，而是：这项设计最适合以什么形式留下来？
从客户差异中识别稳定能力与变化边界：抽取共同的证据关联与决策追溯能力
六
现场经验最终留下什么？不必全部进入核心产品
找到了值得复用的部分，也不意味着一定要开发一项标准产品功能。事实上，很多软件公司积累不了能力，并不是因为没有做过抽象，而是把"产品化"理解得太窄：要么要求核心产品把它接走，要么觉得不进产品的东西就不值得留。
比较现实的做法，是根据经验的适用范围和维护方式，选择不同的沉淀形式。
◆ 6.1 客户特有方案：有些差异就应该留在客户现场
例如某集团独有的审批制度、只能运行在其内网的接口，或者合同明确限定用途的专有算法。这些内容应该被妥善交付和维护，却未必适合跨客户推广。
它们的价值不一定是留下公共代码，也可能是让团队更清楚地理解某类业务的边界。判断出"不宜复用”，同样比未经思考地复制一份实现更有价值。
◆ 6.2 可复用交付资产：减少下一次重复工作
一些能力不需要进入标准产品版本，也能让下一支FDE Squad直接受益。例如接口适配框架、部署脚本、字段映射模板、经授权可复用的Eval方案，以及常见故障的诊断方法。它们解决的是"下次还需不需要从头做"的问题，维护责任可以放在交付资产负责人或FDE能力中心。
◆ 6.3 行业方案：把行业共性做成可配置的做法
另一类值得沉淀的是经过多个相近场景验证的行业模式。例如财务共享中心的审核与复核流程、资金十三周滚动预测的项目分类与映射方法、行业风险检查模板等。
行业方案的关键不是照搬一家客户的制度，而是明确哪些环节行业内相对共通，哪些需要针对客户的组织、科目、规则和流程进行配置。这类能力通常更适合由行业产品或解决方案团队持续维护。
◆ 6.4 产品与平台能力：承接跨场景的稳定共性
如果不同业务场景持续需要相同的证据追溯、权限控制、工作流执行、人工复核或模型评估能力，它们就可能值得进入核心产品或平台。
但进入产品的同时，也意味着厂商开始承担版本兼容、安全、性能、测试、用户体验和长期维护责任。它不是"把代码移进主仓库"这么简单，投入自然也应该更慎重。
沉淀形式
主要解决什么
典型责任方
客户特有方案
解决当前客户的特定问题
项目团队与约定的运维方
可复用交付资产
减少同类项目的重复实施
FDE能力中心或交付资产负责人
行业方案
复用一类业务的流程和配置方法
行业产品或解决方案团队
产品 / 平台能力
长期支撑多个场景的共同能力
核心产品和平台团队
这四类不是必须逐级升级的阶梯，也并非互斥。同一个"审核证据可追溯"的Pattern，可能同时形成一份现场诊断清单、一套费用报销的行业模板，以及由核心产品负责的证据管理能力；特定客户的审批制度仍然留在其专有配置里。
进一步想，这些成果要真正被后来的人用好，仅有代码或配置还不够。后来的人还需要知道为什么这样设计、在什么条件下有效、哪些做法曾经失败。比如一套审核模板里，哪些步骤必须保留人工复核，哪些证据缺失会导致判断失效；一套资金预测方法里，什么情况下不应该直接使用历史趋势。
这些经验应当附着在对应的模板、组件、案例和使用说明中，成为可继承的Know-how，而不是孤零零地堆成另一本"经验手册”。
现场经验的四种沉淀形式：客户特有方案、交付资产、行业方案、产品/平台能力
七
做不做、由谁做：产品化评审要解决的是投资问题
到这里，FDE Squad已经不只是提交一句"客户需要某功能"，而是可以拿着现场证据、共性判断和候选设计，与产品团队讨论值得留下什么。
然而，此时仍然有一个非常现实的问题：
谁来投入研发时间，谁来承担今后的维护成本？
如果完全由项目团队推动，任何客户现场的困难都可能变成"希望产品支持"；如果完全由核心产品团队决定，又可能因为缺少现场证据，把有价值的共性当作个别客户的定制需求。
我们在这里可以用Field Signal评审和产品化评审，来解决这两类信息不对称。
Field Signal评审发生在前面的发现与识别阶段，我们已经详细描述过。其流程就是相关FDE Squad和Product Partner对照不同Mission的现场记录，核实问题根因、适用边界和反例，必要时继续收集证据。它的目的是判断：我们看到的究竟是什么。
产品化评审则是在有了相对清楚的候选能力之后，决定：公司是否值得投入，以及应该怎样投入。这个评审应该更加谨慎，至少要回答下面的问题：
•**是否符合产品方向？**这项能力服务的是公司的目标客户和长期产品定位，还是一次偏离主业的定制机会？
•**未来谁会真正使用？**适用范围有多大，是否已有相近能力可以替代？
•**投入和收益如何？**除开发成本外，未来测试、兼容、安全、支持和版本维护需要多少投入；后续Mission预计能减少哪些重复工作？
•**采用什么形式、由谁负责？**是交付资产、行业方案还是核心产品能力，谁建设、谁维护、谁回应问题？
•**有哪些不能越过的边界？**客户授权、知识产权、数据安全、架构原则和质量要求是否允许这样做？
评审后的决定未必都是"开发"。可能先做成一套交付模板，也可能交给行业产品组，或者进入平台Roadmap；证据不足时可以继续观察，收益不成立时也可以明确不做。只有允许"不做"，才能让这套机制不退化成一条更复杂的需求审批流程。
仍以我们一开始的审核功能增加证据追溯为例。
如果判断多个业务场景确实需要统一的追溯内核，核心产品团队可以负责该能力的设计和维护，FDE Squad则提供经过授权的验证场景，并参与验证接口与配置边界。与此同时，费用报销专有的审核规则由行业方案维护，客户的特殊审批制度不必进入公共产品。
这里需要明确责任交接：**FDE负责把现场问题和可复用价值讲清楚，产品或资产责任方负责决定并承担长期建设与维护；Product Partner必须把两端连接起来。**Productization Ownership不是要求FDE自己包办全部研发，而是不能让问题在部门交界处丢失。
此外，为了避免评审变成"开完会就没有下文"，每项批准的工作还应该明确下一步交付目标、责任方和计划验证的使用场景。至于它最终能否带来预期收益，不能由这次会议下结论——那得等真正用到下一个客户时再看。
Field Signal评审与产品化投资评审：前者核实事实与根因，后者决定投入与负责人
八
到了第二个客户，才能知道复用是不是真的成立
假设第一项智能审核Mission已经形成一套证据关联和人工复核能力。第二家客户做采购合同审查，FDE Squad没有重写追溯逻辑，而是复用已有能力，只调整合同对象映射、证据类型和权限配置。这才说明上一次项目留下的东西开始产生实际作用。
但除此之外，还要看得更细一点——
第二个客户虽然复用了公共组件，会不会仍然花费大量时间修改源代码？配置过程是不是比重新实现还复杂？为了适配新场景，是否产生了新的故障或维护成本？如果只是把原来写代码的时间转移成排查公共组件的问题，那么复用价值就需要重新估算。
因此，下一项Mission至少要比较两件事：**哪些工作因为已有能力而免做了，哪些新工作是为了使用这项能力额外增加的。**两者相抵，才更接近真实收益。
而最终的复用结果，通常不外乎三种情况。
**第一种是真正复用成功。**已有能力在明确的适用范围内稳定工作，后续Mission主要处理客户差异。此时可以扩大采用范围，并逐渐把成熟工作交给标准交付或客户成功团队。
**第二种是部分复用。**比如证据留存机制可以用，但不同客户的授权与版本追溯差异超出原来预想。这说明原先抽象的边界需要调整，可能要增加扩展点，也可能只适合某一行业。产品化不必推倒重来，但应修正适用范围。
**第三种是复用失败。**例如公共组件要改动的地方太多，另一支Squad最终还是重新实现。此时不要把责任简单归咎于"团队复用意识差"，而应该查明：当初识别的是不是真的同一种Pattern？抽象是不是过度？是否选错了沉淀载体？抑或这项资产缺少维护，早已不能用于新环境？
这也是为什么产品飞轮不能只朝一个方向转。新的Mission不仅验证过去的成果，也不断修正公司对共性问题的理解。有些能力经过几次真实使用以后会进入核心产品，有些会退回行业模板，还有些可能被淘汰。
只有下一次实际使用，才能把"理论上可以复用"变成"确实减少了重复投入"。
第二个客户如何验证真实复用：比较"免做的重复工作"与"新增加的适配工作"
九
谁来把飞轮持续转下去？需要一条清楚的责任链
到这里为止，我们已经讲完了Field-to-Product的问题发现、Pattern识别、抽象和产品化投资、下个任务验证。而这条链路要想长期运转，还要有人持续负责，不能让每个FDE Squad各自为政。
我们在前面文章介绍过的"三个1 + 一个N"组织形态中，其实已经说明了承接这件事的角色。
FDE组织到底怎么搭？从种子团队到规模化组织的建设指南
N个FDE Squad记录现场问题、保留证据，并在新Mission中反馈复用效果。其中每个Squad中的Mission Leader确保当前客户的成果仍是第一优先级，同时不让有价值的现场发现在验收后消失。Product Partner作为固定接口，负责把候选能力送到能够做产品决策的团队，也把已有产品能力带回Squad。
1个FDE能力中心负责跨Mission汇总和跟进，避免不同Squad独立解决同一类问题。
1套产品 / 平台后援体系负责承接经过评审确定的长期能力，再由相应的行业产品、核心产品或平台团队承担建设、版本和维护责任。
1个Sponsor则进行资源分配和支持兜底。
这条责任链里，最容易被遗漏的是交接。一个Pattern被批准以后，至少要有明确的接收方和后续验证负责人；当它被新的Mission使用后，也要有人把结果反馈给原来的产品或资产负责人。否则"Field-to-Product"只完成了Field-to-Roadmap，产品做了什么、后来有没有用上，又成了两回事。
资源问题同样无法绕开。项目预算通常优先保障当前客户，产品研发也已有排期。如果抽象和复用建设始终只能利用项目间隙，很难持续。试点阶段可以先由Sponsor批准有限的产品化投入，并明确哪些成本由项目承担、哪些由产品线或共用能力预算承担。等实际复用收益出现后，再决定扩大投入。
对只有一支种子Squad的公司来说，一名Product Partner加上明确的产品负责人，定期处理少量高价值Signal就足以起步。真正重要的是有决策、有承接、有反馈，而不是组织架构看起来多么完整。
十
产品飞轮转没转起来，不能只看沉淀了多少资产
一家软件公司说自己一年沉淀了几十个组件、上百份项目文档，这只能证明"留下了东西"，不能证明后来的人从中得到了收益。判断飞轮是否有效，还是要回到相近场景的下一项Mission。
我觉得可以先关注下面几项指标：
观察内容
要回答的问题
真实采用
交付资产、行业方案或公共能力是否进入了后续Mission，而不仅是被下载或引用？
重复投入
同类问题的调研、开发、测试、部署工作是否减少？新增的适配和维护成本又有多少？
Time-to-Value
在可比场景下，客户从启动到验证价值是否更快？
成熟任务退出
已验证的工作能否转给标准交付、客户团队或产品自助使用，而不再长期依赖FDE？
客户实际成果
交付是否仍然满足业务效果、安全和运行质量要求？
这里需要警惕两个误判。
一是把资产的"复用次数"等同于价值。有的模板被多次复制，但每次都要大幅修改；有的能力只在少数客户采用，却替代了大量复杂工程。不能只数引用次数，而不看实际减少了什么工作。例如，把上一个项目开发的接口适配模板拿到新项目使用，却因为数据结构、权限和运行环境差异太大，仍然需要大量修改。账面上记了一次复用，实际并没有节省多少工作。
二是把项目变快完全归功于产品化。客户自身的数据基础、项目范围、组织配合程度以及Squad的成熟度，都会影响交付周期。有一些客户本身数据治理做得很好，企业管控能力很强，那么项目做起来就是更加得心应手，这并不能说是产品好。最有说服力的还是回到具体工作项，问一句：如果没有上一次留下的能力，这次究竟还要重新做哪些事情？
如果同类Mission的重复投入逐渐下降，而客户实际成果没有因此受损，那么飞轮才有了可靠迹象。随着这些结果持续出现，FDE才可能把更多精力投入新的高价值问题，而不是永远忙于修复已经解决过的老问题。
用真实采用与重复投入验证产品飞轮：重复工程投入下降，价值实现时间缩短
十一
中国软件厂商为什么项目很多，却总觉得没有积累？
把前面的逻辑放回中国软件市场，就会发现许多公司并不缺项目经验。有的厂商做过上百个财务、供应链、制造或风控项目，新的项目组却仍然要四处找人打听：以前谁做过类似需求？那套代码放在哪里？为什么当时没有采用另一个方案？
这通常不是单独建设一个知识库就能解决的。至少还有三类现实障碍。
◆ 11.1 现场经验散落在组织边界里
区域公司、行业事业部、产品线往往有各自的交付团队和代码仓库。同一个问题可能反复出现，但彼此看不到；即使找到了旧代码，也未必能判断它适用于什么条件。对于初期试点，与其急着做全公司统一平台，不如先围绕一个业务场景，让几支相关Squad共用Signal台账和资产目录，并由同一个Product Partner参与判断。
◆ 11.2 项目收入和成本核算不鼓励减少定制
项目经理要盯毛利、验收与回款，现场人员的利用率也往往与绩效挂钩。花时间抽象公共能力，对当期项目未必有直接好处。更复杂的是，有些公司本来就依赖定制开发获取收入，少做重复开发，短期内还可能与现有商业模式发生冲突。
这不是要求项目组"提高产品化意识"就能解决的问题。管理层至少要给试点留出有限的共用能力投入，并同时衡量客户成果和复用收益，不能让现场与产品团队一直用各自的旧指标承担新任务。
◆ 11.3 客户成果与厂商资产之间有明确的权利边界
不少大型企业的私有化项目对交付代码、数据、文档、派生作品和保密义务有严格约定。某段实现看起来很通用，并不意味着厂商就有权带走，在其他客户身上重复使用。简单脱敏也不能自动解决版权、合同和数据安全问题。
因此，通用产品、客户专有交付与可授权复用的资产，最好在项目合同和技术架构阶段就明确边界。通用能力应尽可能从厂商合法持有的代码与知识资产出发重新实现或抽象；用于Eval的样本，也必须经过必要的授权和数据治理。飞轮如果建立在模糊的客户资产归属之上，就谈不上可持续。
这些障碍客观存在，但不必等所有制度修改完成才启动。更现实的是选一个产品方向，挑少量业务问题相近的Mission，用最小范围先跑通一次。
例如围绕智能审核，让正在进行的项目记录现场Signal，邀请产品伙伴核对已有能力，只挑一项价值明确的共性问题投入产品化，再安排下一个项目实际采用。等到团队能够说清楚"这次少做了什么、客户结果有没有变化"，再扩大到更多场景、产品线和区域。
中国软件厂商如何从少量同类Mission启动飞轮：同一业务场景的少量Mission形成闭环
十二
FDE做完项目以后，最终应该留下两种成果
文章开头问：一家软件公司做完项目，到底应该留下什么？
答案至少有两个方面。一方面是交给客户的成果：真正运行的系统、得到改善的业务流程，以及经过验证的业务价值。另一方面是在合法合规的前提下，留给软件公司的积累：对业务问题更深入的认识、可继承的判断方法，以及被后来客户实际使用过的交付资产、行业方案和产品能力。
如果只有前者，FDE很容易继续依赖人力解决同一类问题；如果只有后者，忙着抽象和开发"通用平台"，却忽视当前客户是否得到结果，同样背离了FDE的初衷。
随着类似Mission不断出现，问题还会继续向前。起初，一份字段映射模板、一套Eval或者一个接口适配框架就能减少重复工作；等到越来越多场景要求相同的权限、业务对象、规则、Action、Workflow和证据管理能力时，分散在项目仓库中的资产就很难长期支撑复用。它们需要稳定的产品和平台能力来承载，也需要在不同客户环境中持续组合、扩展和治理。
这就是FDE与平台之间最值得关注的关系：**现场不断揭示哪些能力值得做成共性，平台则让这些已经验证的共性不必每次从头实现。**并非每家软件公司都需要先建设一套庞大的统一平台，更不意味着必须把所有客户数据集中起来；平台到底应当承担什么，仍然需要从真实的跨客户问题出发。
Palantir提供了一个值得研究的例子。它在官方架构说明中，将Forward Deployed Engineering视为持续推动平台演进的产品开发方式：工程师深入客户现场，与核心研发团队一起吸收反馈、交付新功能。我更倾向于从FDE与平台相互强化的关系，来理解它的长期竞争力，而不是简单归功于其中一方：
•**从产品演进看，客户现场是平台能力的重要来源。**Palantir很早便围绕复杂的客户问题建设软件能力，并在长期实践中不断演进产品。与其说先有一套完美的Foundry，再由FDE负责实施，不如说现场问题与核心研发始终在相互推动。
•**从规模化看，平台为复用提供了基础。**Foundry、Ontology、Apollo等能力让团队有机会把数据、业务语义、应用开发和部署中的共性沉淀下来，而不是每到一个客户就重新建设。这有助于降低重复投入，也是软件业务区别于纯人力定制的重要条件。
•**从长期竞争力看，关键在于两者的协同进化。**FDE把真实的业务和工程问题带回产品，平台再将经过验证的共性转化为其他客户能够使用的能力。下一轮客户现场又会检验这些能力，并推动平台继续改进。
而这个问题，也是我们后面想继续讨论的：
FDE为什么离不开一个强平台：让Palantir成功的，可不只是FDE。
客户成果与产品积累共同形成长期复利
参考资料
**[1]**OpenAI，Forward Deployed Engineer (FDE) - Seattle。 https://openai.com/careers/forward-deployed-engineer-%28fde%29-seattle-seattle/
**[2]**IBM，Forward deployed units: IBM Consulting’s field model for scaling AI and transformation，2026-06-18。 https://www.ibm.com/think/perspectives/forward-deployed-units-ibm-consulting-field-model-scaling-ai-transformation
**[3]**Gartner，Price Forward-Deployed Engineers to Sell AI Products, Not Billable Hours，2026-07-20。 https://www.gartner.com/en/documents/8149429
**[4]**Palantir，Architecture Center: Overview，官方架构说明。 https://www.palantir.com/docs/foundry/architecture-center/overview