结论前置：FDE 和外包最大的区别，不是前者更懂技术，也不是前者离客户更近，而是交付之后有没有留下可复用的资产。FDE 的交付有两条线：一条线把眼前的问题解决掉，另一条线把解决问题的经验沉淀下来。少了第二条线，FDE 很快就会退化成高级驻场开发。
为什么还要讲“沉淀”
上一篇讲了一个判断：AI FDE 和传统顾问，是两种完全不同的职业。这句话如果继续往下拆，核心差异其实不在“谁更会写代码”，也不在“谁更懂客户”。这些都重要，但不是本质。
真正的差异在交付机制上。传统外包或咨询，核心逻辑是把当前项目交付掉。客户有问题，团队进场，梳理需求，开发功能，上线验收，项目结束。只要合同范围内的东西做完了，交付就算完成。
但问题是，项目完成了，不代表组织变聪明了。
这个项目里发现的模式，有没有被下一个项目复用？现场临时写出来的脚本，有没有变成平台能力？某个行业里反复出现的流程，有没有沉淀成模板？这些东西如果没有被接住，项目就只是项目。
做完一个，结束一个。下一个客户来了，再从头来一遍。
这就是传统交付最大的问题：它能完成项目，但很难积累能力。 FDE 要解决的，正是这个问题。
FDE 不是一条线，而是两条线
▲ FDE 的两条线：交付解决眼前问题，沉淀形成复用资产
FDE 的交付不是单线条的。它至少有两条线。
第一条线，是内循环。 也就是把当前客户、当前场景、当前流程里的问题解决掉。这个东西能不能跑起来？业务方愿不愿意用？它有没有产生实际价值？这是内循环要回答的问题。
第二条线，是外循环。 也就是把解决问题过程中发现的可复用模式，沉淀回平台、产品、模板、工具和方法里。下一个项目能不能更快？同类问题能不能不再从零开始？这是外循环要回答的问题。
这两条线必须同时跑。只跑第一条线，就是项目制外包。客户要什么做什么，做完交付，项目结束。哪怕工程师很强，本质上也还是一次性开发。
只跑第二条线，不看前线真实问题，就是闭门造车的产品规划。平台做得再漂亮，前线不用，业务不买账，也没有意义。
FDE 的关键，是在前线解决具体问题的同时，把具体问题背后的共性抽出来。 这句话听起来简单，但它决定了 FDE 和传统交付的分界线。
第一条线：先把眼前的问题解决掉
FDE 到了前线，首先要解决的是具体问题。不是先写一份完整的需求文档，也不是先做一个漂亮的方案汇报，而是进入真实流程，看业务到底怎么运转。
一个流程里，谁在填表，谁在审批，数据从哪里来，为什么同一个信息要在三个系统里重复录入，哪个节点看起来像审批，实际只是转发，哪个环节看起来慢，真正的问题却是上游数据不准。
这些东西，不在产品手册里，也很难靠会议问出来。必须在前线看见。
看见之后，FDE 要做的不是把问题包装成一个大项目，而是先做一个能跑的改进。粗糙一点没关系，重要的是能进入真实流程。因为只有跑起来，才能知道它是不是真的解决了问题。
很多企业软件项目的问题就出在这里：方案阶段看起来都对，上线之后没人用。为什么没人用？因为方案解决的是文档里的问题，不是现场的问题。
FDE 的内循环，核心就是避免这种情况。它通常会经历几个动作：发现真实问题，跟着业务流程走一遍，做出一个能跑的原型，放到真实环境里验证，看用户是不是真的用，再根据反馈继续改。
这一圈转下来，才叫一次有效交付。注意，这里的重点不是“交付物”，而是业务效果。
系统上线了，不代表成功。有人登录了，也不代表成功。真正的成功，是目标用户在日常工作里真的开始依赖它，原来的低效流程被替换掉，某个环节的时间、错误率、等待成本真的下降了。
这就是第一条线：把眼前的问题解决掉。但如果 FDE 只做到这里，还不够。因为这只是把一个项目做成了，还没有让组织变聪明。
第二条线：把解法变成下次能用的东西
第二条线，才是 FDE 真正区别于外包的地方。
在解决一个具体问题的时候，FDE 不能只盯着眼前这个客户。它还要不断判断：这个问题是不是只属于这一家？这个流程是不是别的企业也会有？这个临时解法是不是可以抽成一个组件？这个配置是不是可以变成模板？这个评估方法是不是可以变成标准工具？
这些判断，构成了外循环。
外循环不是项目结束后的复盘会。 它应该发生在项目过程中。FDE 在前线看到一个可复用的东西，就要当场捕捉，而不是等到三个月后写总结。
因为真正有价值的发现，往往很小。不是宏大的战略判断，可能就是一个数据字段的映射方式，一个审批流程里的共性节点，一段临时写出来的校验脚本，一个反复出现的权限模型，一个客户现场逼出来的评估方法。
这些东西如果不及时记录，很容易被当成“项目里的小细节”过去了。但如果它被捕捉下来，被产品和平台团队接住，就可能变成后续项目的基础能力。
外循环大概是这样运转的：前线发现一个可复用模式，用几句话记录清楚它出现在哪里、解决什么问题、当前怎么做、为什么可能复用；然后快速和产品或平台团队讨论，判断值不值得标准化。如果值得，就由平台团队重构成通用能力。下一个项目遇到类似问题时，直接复用。
这里有一个关键点：前线不一定负责把它标准化。FDE 在现场做出来的东西，往往是“粗糙但管用”的。这很正常。前线追求的是速度，是先把业务跑起来。
但平台能力不能一直粗糙，所以更合理的分工是：前线负责发现和验证，平台团队负责重构和产品化。 前线给平台提供真实材料，平台把真实材料加工成可复用资产。
这就是内循环和外循环的关系。内循环让当前项目跑起来，外循环让下一个项目不必从零开始。
“闪光点”通常不是大东西
▲ 真正值得沉淀的，往往是现场里不起眼的小发现
很多人一听“沉淀”，会想到很正式的东西：方法论、产品模块、行业解决方案、知识库文档。这些当然重要。但 FDE 里的沉淀，最开始往往不是这么大的东西。
它更像一个个很小的闪光点。
比如，两个客户都需要把旧系统里的客户数据同步到新流程里，只是字段名不同。三个项目里都出现了类似的审批链路，只是审批人和节点数量不同。不同客户都需要判断一段 AI 输出能不能进入下一步，只是评估标准略有差异。多个场景都需要把人类操作日志转成系统可读的结构化记录。
这些东西单独看都不大。但只要反复出现，就说明背后有共性。
共性一旦被抽出来，就能变成平台能力。 下一个项目就不需要再问“这个怎么做”，而是直接调用已有能力，改一点配置，继续往前跑。
这就是 FDE 的飞轮。项目越多，前线看到的模式越多。模式越多，平台沉淀越厚。平台越厚，下一个项目交付越快。交付越快，FDE 才能把更多精力放在真正的新问题上。
OpenAI 的例子很典型
OpenAI 的 FDE 曾经在一个呼叫中心场景里做 AI 语音助理集成。现场遇到的问题很具体：语音延迟和吞吐波动很难实时评估。为了让这个客户的系统跑起来，前线团队做了一套实时评估框架。
如果按传统交付逻辑，这件事到这里就结束了。客户的问题解决了，项目上线了，评估框架留在这个客户场景里，成为一次性的交付物。
但 FDE 的判断不一样。它会继续问：语音延迟和吞吐波动，只是这一家呼叫中心的问题吗？显然不是。只要做实时语音交互，就会遇到类似问题。
于是，这个现场逼出来的评估框架被上报、抽象、重构，最终影响了 OpenAI 官方 Realtime API 的底层机制，也推动了 Agent SDK 的定型。
一个前线临时工具，最后变成了平台能力。
这个例子之所以重要，不是因为 OpenAI 多厉害，而是它说明了 FDE 的本质：前线不是产品的末端，前线是产品演化的入口。
传统模式里，产品先规划，前线再实施。FDE 模式里，前线不断发现真实问题，产品不断吸收真实问题，平台不断变强。这就是区别。
70% 沉淀率：不是 KPI，而是健康信号
▲ 70% 不是个人 KPI，而是组织机制的健康信号
FDE 讨论里经常会提到一个数字：70%。意思是，在机制运转良好的情况下，前线大约 70% 的解决方案，可以被重构为平台能力、标准组件、行业模板或方法资产。
这个数字容易被误解。它不是给 FDE 个人压的 KPI。不是说每个 FDE 做完项目，都必须把 70% 的代码产品化。如果这么考核，方向就错了。
FDE 在前线首先要解决业务问题，而不是为了完成沉淀指标去硬凑资产。70% 更像一个组织健康度信号。
如果长期只有 10%、20% 的东西能沉淀，说明前线大概率在做一次性定制。每个项目都从零开始，每个客户都单独开发，做得越多，负担越重。这就是咨询陷阱。
但如果要求 100% 沉淀，也不现实。因为前线一定会遇到纯定制需求。每个企业都有自己的历史包袱、组织习惯、审批偏好、系统限制。这些东西不应该都塞进平台。
平台如果吸收太多特殊逻辑，最后会变成一个谁都不敢动的巨型怪物。
所以 70% 的意义在于：它承认前线有特殊性，但也要求组织持续从特殊性里抽出共性。
刚开始做 FDE 的团队，沉淀率可能只有 20% 到 30%。这很正常。因为平台还薄，经验还少，前线还在摸索。但只要外循环存在，这个数字会慢慢上升。
真正危险的不是沉淀率低，而是没人关心沉淀率。项目做完就结束，代码留在客户那里，经验留在个人脑子里，组织没有变聪明。
这是 FDE 最该避免的状态。
什么值得沉淀，什么不值得
▲ 通用模式、行业模板、纯定制，要分清楚
不是所有前线发现都值得沉淀。这里需要一个简单的判断框架。
第一类，通用模式。 比如数据集成方式、认证流程、权限模型、日志审计、评估框架。这类东西跨客户、跨项目都会出现。一旦沉淀，后续项目直接受益，优先级最高。
第二类，行业模板。 比如某个行业典型的审批流程、合规要求、数据结构、业务动作。这类东西不是所有企业都需要，但同一个行业里会反复出现。它值得沉淀，但不能照搬某一家客户的做法，要抽象出行业共性。
第三类，纯定制需求。 比如某个客户内部独有的审批习惯，某个历史系统留下来的特殊字段，某个老板个人偏好的报表格式。这类东西可以做，但不应该进平台，留在定制层就够了。
判断标准其实只有一个：这个东西会不会让下一个项目更快？ 会，就值得沉淀。不会，就不要硬沉淀。
这个标准比复杂的评审体系更有效。因为 FDE 的沉淀不是为了文档好看，而是为了降低下一次交付成本。
外循环断了，FDE 就变成外包
▲ 项目孤岛只会重复搬砖，平台资产才会让组织变聪明
现在可以回到开头的问题。FDE 和外包到底差在哪里？同样是进现场，同样是解决客户问题，同样可能要写代码、调系统、做集成，差异就在第二条线。
如果外循环存在，前线的每一次交付都会反哺平台。一个项目结束后，组织会多一点能力。下一个项目开始时，不是从零开始，而是带着前一个项目沉淀下来的组件、模板、经验和判断方法继续往前走。
项目越做越轻。平台越做越厚。团队越做越聪明。
如果外循环不存在，情况就完全相反。每个项目都是孤岛，每次交付都靠个人经验，每个客户都要重新理解、重新开发、重新上线，做得越多，维护包袱越重。
这时候就算团队里的人都很强，也只是更强的外包团队。
FDE 的关键不在“强人”。 强人当然重要，但只靠强人，组织会越来越依赖英雄工程师。一旦这个人离开，经验也跟着走了。
真正的 FDE 模式，要把个人在前线看到的东西，变成组织能复用的东西。这才是沉淀的意义。
这也是 AI 时代的关键变化
▲ AI 项目的不确定性，需要被转化成可复用资产
为什么 FDE 这件事在 AI 时代变得更重要？因为 AI 项目的不确定性更高。
传统软件交付里，很多需求是相对确定的。流程怎么配、字段怎么填、权限怎么设，虽然麻烦，但大体可预期。
AI 项目不一样。它经常需要在真实业务里试出来。哪些环节适合自动化，哪些判断必须保留人工，AI 输出怎么评估，用户什么时候信任它，什么情况下必须加护栏，这些问题很难在会议室里一次性想清楚。
必须进入前线，快速试，快速改。
也正因为不确定性更高，沉淀才更重要。否则每个 AI 项目都会变成一次重新探索。每次都从提示词、流程、评估、权限、异常处理重新来一遍，成本会非常高。
FDE 的双循环，本质上就是把这种不确定性变成可积累的资产。
第一次遇到，是问题。第二次遇到，是模式。第三次还遇到，就应该变成平台能力。
写在最后
所以，FDE 不是“派一个厉害工程师去现场”。这句话只说对了一半。
真正的 FDE，是一套让前线经验持续回流的交付机制。内循环负责把眼前的问题解决掉，外循环负责把解法变成下次能复用的资产。内循环保证价值真实，外循环保证能力积累。
少了内循环，FDE 会变成纸上谈兵。少了外循环，FDE 会变成高级外包。
两条线同时跑，FDE 才成立。
