FDE-native 产品架构：真正的竞争力，不是做出第一个应用，而是让第十个项目比第一个更快。

AI 编程正在改变软件开发。

过去，一个业务需求从立项、开发到上线，可能需要数周甚至数月。现在，借助大模型和 AI 编程工具，一个小团队几天内就能做出可交互的原型。

但一个新问题出现了：

第一个项目可以快速完成，第二个、第三个，为什么还要从头来？

如果每个项目都要重新接入模型、搭建知识库、开发数据接口、配置权限，那么 AI 只是加快了单个项目的开发速度，并没有解决企业规模化的问题。

项目越多，重复建设越多，维护成本也越高。

这正是 FDE-native 产品架构试图解决的问题：让现场项目不只是交付一个应用，还能为后续项目留下可复用的能力。

一、FDE 负责解决问题，平台负责积累能力

FDE（Forward Deployed Engineer，前线部署工程师）是一种深入客户现场、贴近真实业务解决问题的工程实践。

以制造业为例。

企业希望用 AI 分析设备故障，但维修记录散落在不同系统里，设备编号不统一，老师傅的经验也没有完整记录。仅仅接入一个大模型，并不能直接解决问题。

FDE 需要打通数据、理解业务流程、连接企业系统，再通过实际使用不断调整方案，最终交付一个真正能用的应用。

问题在于：如果这套方案在一家工厂验证成功，下一家工厂还得重新开发一遍，第一次项目的经验就没有真正沉淀下来。

所以，FDE 和平台承担着不同的任务：

• FDE： 深入现场，快速发现问题、构建原型、验证价值。

• 平台： 将经过验证的通用能力沉淀下来，让后续项目少走弯路。

这也引出 FDE-native 的核心指标：TTVV（Time to Validated Value），即从发现问题到验证业务价值所需的时间。

重点不只是多久做出一个 Demo，而是多久证明它确实有效。

一个能生成投诉处理建议的 AI 应用，如果读不到最新订单、无法进入工单流程，就还没有真正创造业务价值。

因此，平台不应只追求开发速度，还要缩短数据接入、业务验证、质量评测和生产部署的时间。

二、平台应该分三层：生成、复用、治理

AI 降低了生成代码的成本，也重新划定了平台建设的边界。

过去，企业可能希望把所有开发环节都做成标准化工具。但在 AI 时代，不是所有东西都值得提前平台化。

FDE-native 可以把项目中的内容分成三类。

1. 应用层：能快速生成，就不要过早固化

页面、提示词、业务流程和客户专属界面，通常变化快、差异大。

与其提前建设一个包揽所有需求的通用工具，不如先根据现场需要快速生成，再通过真实反馈持续调整。

这一层的关键词是 Generate：快速生成。

2. 能力层：验证有效的东西，才值得复用

假设多家工厂都需要分析设备故障。

团队逐渐发现，读取设备记录、检索维修手册、匹配故障代码、生成诊断建议，是一套反复出现的业务流程。

经过多个项目验证后，这套流程就可以沉淀为领域技能，供后续项目直接调用。

这里要区分工具和技能：

工具解决一个具体动作，例如查询数据库、调用接口、搜索文档；技能则带有业务语义，例如“诊断设备故障”或“分析客户投诉”。

工具让 AI 能做事，技能让 AI 更有章法地解决业务问题。

真正值得长期积累的，往往是经过验证的领域技能，而不只是工具数量。

但不能为了复用而复用。只有当某种做法反复出现、效果稳定、具备实际价值时，才值得抽象成公共能力。

这就是“由场景拉动能力建设”：先解决真实问题，再从重复实践中提炼能力。

3. 治理层：企业底线必须统一

身份认证、数据权限、模型调用、安全审计和操作追踪，不应该由每个项目各自实现。

否则，十个项目就可能出现十套权限体系、十种模型接入方式，系统越多，风险越难控制。

因此，平台要统一管理这些公共边界，让项目团队把精力放在业务创新上。

三层对应三个动作：

Generate 负责生成，Reuse 负责复用，Govern 负责治理。

应用可以灵活变化，能力可以逐步积累，企业底座则必须保持稳定。

三、真正的技术底座，是让数据变成业务能力

有了三层结构，还需要一条技术主链，把它们连接起来：

数据 → 上下文 → 能力 → 智能 → 应用 → 业务反馈。

以设备故障诊断为例：

首先，系统获取设备编号、报警记录和维修历史；然后理解设备所属产线、当前运行状态以及过去的故障情况；接着调用知识检索、故障分析等能力；最后由模型和工作流生成处理建议，并进入实际业务流程。

系统还要记录诊断是否准确、处理是否成功，以及哪些情况需要人工纠正。

这条链路揭示了企业 AI 的一个关键问题：

模型只是其中一环，准确的业务上下文同样重要。

如果数据不完整、业务含义不清楚，或者系统不知道当前任务的具体条件，再强的模型也可能给出看似合理、实际却无法执行的答案。

因此，企业 AI 平台需要的不只是模型接入，还包括：

• 数据与知识管理，让信息能够被准确获取。

• 上下文管理，让 AI 理解当前业务、用户和任务。

• 工具、技能与工作流，让模型能够调用企业能力。

• 评测与追踪，让系统的效果可以验证、问题可以定位。

• 权限与安全机制，让业务动作始终处于可控范围。

本体、知识图谱等技术也不必一开始就大规模建设。企业可以先统一元数据和业务对象，再根据真实需求逐步完善语义模型、领域模型和知识关系。

平台建设的重点不是追求技术名词齐全，而是让企业信息从“能够存储”，逐渐走向“能够理解、能够行动”。

四、稳定核心，灵活边缘：企业定制不会消失

企业软件有一个现实：不同客户的业务流程很难完全相同。

同样是客户投诉分析，不同行业的分类规则、审批流程和数据结构可能都不一样。

FDE-native 并不是要消灭定制开发，而是把定制放在合适的位置。

稳定核心负责公共能力，包括身份、权限、数据访问、模型网关、AI 运行时、安全审计和评测机制。

灵活边缘负责现场适配，包括业务规则、数据映射、客户专属工作流、提示词、界面和系统集成。

这样，客户差异可以留在边缘，不必每次都改动平台核心；通用能力则能够被多个项目共享。

模型也应该遵循这一原则。

业务应用不必直接绑定某个具体模型，而可以通过模型网关调用“快速推理”“复杂推理”或“视觉理解”等稳定能力接口。底层模型发生变化时，应用就不必跟着大规模重写。

平台的价值，不是提前规定所有业务应该怎么做，而是让业务变化发生在可控的边界内。

五、让每个项目都留下资产，才能形成能力复利

传统项目经常以验收作为终点。

系统交付了，团队转向下一个客户，项目里积累的经验却可能只留在代码和文档里。

FDE-native 要改变这一点。

每个重要项目结束后，都应该做一次资产盘点，把成果分成三类：

• 客户专属资产： 留在项目侧，例如特定审批规则、独有的数据映射。

• 领域复用资产： 沉淀到能力层，例如设备诊断技能、行业知识检索流程。

• 平台通用资产： 进入平台核心，例如模型网关、权限管理和安全审计。

判断某项经验是否值得复用，可以看它是否反复出现、实现方式是否稳定、复用价值有多大、重新建设的成本有多高，以及是否涉及统一治理需求。

不只是成功经验，失败也应该成为资产。

当系统在生产环境中出现错误，团队可以把失败样本加入评测数据集，修复问题后进行回归测试，避免同类错误不断重演。

这样，项目交付就不再只是完成一次客户需求，而是持续增强企业的公共能力。

整个过程形成一个循环：

真实业务提出问题 → 快速构建原型 → 验证实际效果 → 收集现场反馈 → 沉淀领域能力 → 下一个项目复用。

项目越多，能力和评测数据越丰富；能力越丰富，新项目需要从头探索的部分就越少。

这就是“能力复利”。

当然，前提是这些能力真正被复用，而不是仅仅被登记在文档里。

判断平台有没有变强，关键不是组件增加了多少，而是下一个项目是否真的因此变快。

六、企业该怎么落地？从高频问题开始，而不是先造大平台

FDE-native 不意味着一开始就建设一套包罗万象的平台。

更实际的路径是：

第一，统一基本运行机制。 规范模型调用、配置管理、密钥管理和日志追踪，减少重复建设。

第二，建立必要的治理底线。 统一身份、权限、数据访问和高风险操作审批，尤其要保护企业敏感数据。

第三，选择高频业务场景。 优先解决某类任务的数据、知识和业务上下文问题，不急于覆盖整个企业。

第四，沉淀经过验证的技能。 从多个真实项目中识别重复模式，再将稳定做法抽象成领域能力。

第五，建立评测和资产回流机制。 把生产反馈、失败样本和修复结果纳入持续改进流程，让项目经验真正进入平台。

治理力度也应随业务成熟度提高：探索阶段允许快速试错；进入真实生产、涉及敏感数据或关键操作后，则必须强化评测、审计和权限控制。

平台不是一次性建设完成的，而是在真实业务中逐步长出来的。

结语：真正的竞争力，是让下一个项目越来越快

AI 让软件原型越来越容易生成，但这并不意味着企业自然获得了规模化能力。

如果每个项目都从头接模型、建知识库、配权限、写工作流，那么 AI 只是加速了定制开发。

只有当现场经验能够沉淀为领域技能，通用能力能够跨项目复用，企业底座能够持续提供稳定支撑，开发速度的提升才会转化为长期竞争力。

AI 降低探索成本，平台降低规模化成本，FDE 把现场学习转化为新的软件资产。

衡量 FDE-native 是否成功，其实只需要问一个问题：

当企业完成第十个、第一百个项目时，解决下一个问题，是否真的比第一个项目更快？

如果答案是肯定的，企业积累的就不再只是越来越多的应用，而是一套能够持续进化的软件生产能力。

这才是 AI 时代，企业重新设计软件平台的真正意义。

你认为，企业 AI 平台最值得优先沉淀的是什么：业务技能、数据与上下文，还是模型和治理底座？欢迎在评论区交流。