FDE · 职业成长 · 企业AI落地
做了10个项目，为什么还在驻场救火？FDE真正的职业复利，藏在这5个乘数里
项目数量不会自动变成壁垒。问题价值、现场深度、反馈密度、抽象能力和复用范围，才决定一份FDE工作能否越做越值钱。
做 FDE，最容易产生一种错觉：项目越多，经验越多，身价自然越高。
可现实里经常出现另一种情况。
有人一年做了十个项目，简历越来越长，工作内容却没变：客户临时提需求、数据突然出问题、系统上线前连夜救火，下一个项目再从头来一遍。
也有人只深入做了三四个工作流，却开始形成自己的行业判断、评测方法和通用组件。第二次做同类项目时更快，第三次已经能提前判断哪里会失败。
两种人都很忙，积累下来的东西却完全不同。
一份 FDE 工作有没有职业复利，可以用这条公式判断：
个人 FDE 复利＝问题价值 × 现场深度 × 反馈密度 × 抽象能力 × 复用范围
注意，这是乘法，不是加法。
只要其中一项长期接近零，做再多项目，也可能只是在重复出售体力。
01 模型越来越强，企业缺的却不是"再强一点"
ChatGPT 发布后的前两年，行业注意力主要围绕参数、算力、榜单和上下文窗口。开发者也习惯比较：谁推理更强，谁能读更长的文件，谁写代码更快。
到了 2026 年，模型还在进步，企业应用的堵点却往外移动了。
麦肯锡 2025 年全球调查显示，88% 的受访者称所在组织已在至少一个业务职能中经常使用 AI，但约三分之二仍没有进入企业级规模化阶段；只有 39% 的受访者报告 AI 对企业整体 EBIT 产生了影响。被麦肯锡定义为"AI 高绩效企业"的组织约占 6%，它们从根本上重构工作流的概率接近其他企业的三倍。
企业已经可以买到相近的模型能力。真正拉开差距的是另一批问题：
• 哪些数据可以给模型看？
• 哪些动作可以自动执行？
• 什么情况必须交给人？
• 模型判断错了，谁发现、谁修正、谁承担结果？
银行不会把拒绝一笔交易的全部条件写在官网上；工厂里老师傅遇到设备异常时先看哪个指标，也可能从未出现在操作手册里。企业的运行逻辑散落在数据库、审批动作、工单记录和人的经验中。
这也是大厂扩张 FDE 的背景。OpenAI 在 2026 年成立 Deployment Company，宣布超过 40 亿美元的初始投入，并计划通过收购 Tomoro 引入约 150 名部署人才；AWS 宣布投入 10 亿美元建设 FDE 组织，希望让工程师进入客户环境共同交付；Anthropic 与 DXC 的合作则计划培养数万名 Claude 认证 FDE。
这些动作释放了一个清楚的信号：模型能力可以通过 API 交付，企业的运行方式却不能。
FDE 的位置，恰好在模型、客户现场和产品团队的交界处。
02 第一个乘数：问题价值
FDE 表面上在交付项目，长期价值却取决于他能接触什么问题。
同样是"做一个 AI 助手"，可能只是替员工润色邮件，也可能进入合同审批、客户退款、设备维修或交易风控。前者影响几分钟工时，后者可能直接连接收入、成本和风险。
问题越靠近经营结果，你越有机会看见企业真正的决策方式：
• 哪项任务每天都在发生？
• 哪个判断一旦出错会产生损失？
• 谁会推翻系统建议？
• 最后拿什么结果证明项目有用？
公司用昂贵的工程资源，换取进入客户问题空间的机会。个人也在做同一笔交换：用工程能力，换取高价值问题的访问权。
所以选择项目时，别只问技术复杂不复杂。还要问：这个工作流离收入、成本、风险和客户体验有多近？
一个技术很炫却没人验收的项目，未必比一条不起眼的订单审核流程更有职业价值。
03 第二个乘数：现场深度
客户项目经理转述过来的需求，通常已经被压缩成一张功能清单。
"做合同 Agent。"
"建企业知识库。"
"让客服自动回复。"
这些是产品设想，还不是可以直接开发的问题。
FDE 要继续往里走：谁在什么环节遇到困难？现在怎样判断？一次错误造成什么损失？哪些动作模型可以做，哪些动作必须由人批准？
客户说要"合同 Agent"，最后需要的也许不是一个聊天窗口，而是风险条款识别、审批分流、修改建议和结果写回。
两套方案都调用大模型。一个停留在演示层，一个进入真实工作流。
现场深度可以分成四层：
1. 只看需求文档； 2. 听业务负责人描述流程； 3. 看一线员工完成一项真实任务； 4. 跟到异常出现、人工接管和最终结果。
很多项目停在第二层。工程师听到了"标准流程"，却没有看到员工在几个旧系统之间复制什么、哪些规则只存在于群聊里、遇到例外时到底找谁拍板。
没有这些信息，所谓"懂业务"很容易变成记住几个行业名词。
04 第三个乘数：反馈密度
很多 AI 系统记录了大量日志，却没有形成有用的反馈。
输入是什么、模型回答了什么，只能告诉你系统说过什么。它无法解释员工为什么拒绝这次回答。
一条有价值的生产轨迹，至少还要包括：
• 当时的业务上下文；
• 模型调用了哪些数据和工具；
• 员工修改或接管了什么；
• 为什么修改；
• 最后采取了什么行动；
• 行动带来了什么结果。
假设客服删掉了模型回复中的一句承诺。团队不能只把它记为"答案不好"。还要知道：违反了哪条规则？客服换成了什么说法？工单是否升级？客户后来有没有退款？
信息补齐后，团队才能判断该改模型、改数据，还是改业务流程。
比如两周内出现 37 次人工接管，其中 21 次来自权限不足，9 次来自客户资料过期，只有 7 次属于模型推理错误。这时继续改 Prompt，最多修掉最小的一部分。
反馈密度，不是日志有多少，而是一次失败能不能被解释，并变成下一次可验证的改进。
05 第四个乘数：抽象能力
企业内部的大量知识，以口语和习惯存在。
"这种客户可以放宽一点。"
"金额太大要找负责人。"
"系统显示完成了，但还得查另一张表。"
这些话包含经验，却不能直接交给机器执行。
FDE 要做一次"企业知识编译"：把人的隐性判断，整理成机器可以执行、员工可以检查的结构。
一项工作流可以先拆成七个字段：
1. 触发条件：什么事件让任务开始？ 2. 业务对象：系统正在处理什么？ 3. 所需上下文：哪些信息会改变判断？ 4. 执行动作：模型和工具分别做什么？ 5. 角色权限：谁能查看、修改和批准？ 6. 异常处理：什么情况需要中止或升级？ 7. 最终结果：用什么业务指标判断有效？
以合同审核为例：销售上传合同是触发条件，采购合同是业务对象；客户等级、标准模板和历史谈判记录构成判断上下文；模型识别风险条款并生成修改建议，法务拥有修改权，负责人拥有批准权；金额超过阈值或出现数据出境条款时必须升级；团队最后用审核时间、漏检率和签约结果判断效果。
客户最开始可能只说了一句话："我们想用 AI 审合同。"
FDE 要把这句话翻译成对象、规则、权限、工具和结果。字段明确之后，工程团队才有资格设计接口、人工接管和评测。
会用某个 Agent 框架，能帮助你完成实现。理解企业怎样作出决定，才能帮助你设计系统。
06 第五个乘数：复用范围
项目上线只完成了交付，还没有形成复利。
团队需要继续判断：哪些经验只属于这个客户，哪些可以进入产品？
一次成熟的 FDE 项目，至少应该留下四类资产：
• 业务对象及关系；
• 高频异常和接管方式；
• 能重复运行的行业评测；
• 可以跨项目使用的组件。
OpenAI 与 Thrive Holdings 公布的 Tax AI 案例提供了一个很直观的例子。会计人员在日常工作中纠错，系统保存从原始文件到最终报税结果的轨迹，团队再把失败转化成评测。公开数据称，在六周内，达到 75% 字段正确率的申报表占比从 25% 提升到 86%，事务所吞吐量提高约 50%。
这个案例最值得看的不是报税，也不是某个模型。
关键在于它形成了一条闭环：专家完成工作时提供纠错，系统把纠错保存为证据，工程师通过评测验证改进，再把有效方法带进新的工作流。
OpenAI 对 Presence 的介绍也强调了相似机制：生产会话、人工升级和质量信号用来暴露系统缺口，再把跨部署的通用经验带回研究和产品。
如果一个 FDE 每做完一个项目，下一个同类项目依旧从零开始，那些经验还停留在个人脑中。
只有当现场发现进入评测、代码、工具和交付方法，忙碌才开始变成资产。
07 数据能看见，不等于可以带走
FDE 越深入现场，越要分清四种权利：
1. 在客户环境中查看数据； 2. 为完成任务处理数据； 3. 提炼部署经验； 4. 使用数据训练模型。
它们不是一回事。
OpenAI 的企业隐私说明明确表示，商业客户的输入和输出默认不用于训练模型。但具体项目仍要以合同、批准的数据流和客户治理要求为准。
原始数据留在客户环境里，不妨碍团队统计失败类型、工具调用模式和人工接管原因。前提是客户允许，而且系统支持安全的聚合和脱敏。
接触敏感数据不代表获得数据资产。只有在明确权限内保存反馈、建立评测并推动产品改进，项目才可能形成学习回路。
这是 FDE 进入金融、医疗、制造和政府等行业前必须补的一课。
08 选 FDE 岗位，先问这6个问题
岗位名称不重要，学习回路才重要。
面试或选择项目时，可以直接问：
1. 我能否接触一线使用者，而不只是接收项目经理转述？ 2. 我能否看到上线后的业务结果？ 3. 人工修改和接管原因会不会被系统记录？ 4. 生产失败是否会进入评测集？ 5. 我能否修改核心产品，还是只能写客户定制代码？ 6. 同类客户的交付时间和定制量是否在下降？
如果这些问题都没有答案，你得到的可能是一份项目很多、学习密度却很低的驻场工作。
个人也可以每半年做一次复盘：
• 第二次交付同类系统，是否比第一次快？
• 建立的评测，有没有被其他项目使用？
• 写出的组件，覆盖了多少客户？
• 哪次现场发现推动了产品修改？
• 你离开后，客户能否独立运行和处理异常？
如果答案长期都是"没有"，要警惕自己只是越来越擅长救火。
写在最后
连续完成十个彼此孤立的项目，只会让人更熟练地处理紧急需求。
深入几个高价值工作流，跟到真实结果，保存完整反馈，再把共同模式写进评测和产品，才会形成另一条职业路径。
大模型还会继续提高推理、编程和工具使用能力。越来越多企业也会拿到相近的基础模型。
但现实工作现场不会因此自动变得整齐。
那里的数据仍然分散在旧系统里，部门规则仍会彼此冲突，关键判断仍可能只存在于老员工脑中，最后还要有人为模型的行动承担责任。
FDE 的价值，是靠近这些问题，把模糊经验翻译成业务规则，把规则写进生产系统，再用真实结果检验系统。
岗位以后可能叫 FDE、AI 部署工程师、解决方案工程师，或者行业 AI 架构师。名字会变，背后的能力不会消失。
真正值得积累的，从来不是"我做过多少个项目"。
而是：我进入过多重要的问题，拿到过多完整的反馈，又把多少现场经验变成了下一次可以复用的能力。
— 完 —