CodeWisdom
从FDE看AI应用落地实践模式
微访谈
背景介绍
Palantir的FDE（Foward Deployed Engineer，前线部署工程师）模式近期成为AI领域热议焦点，其核心是通过技术专家深度驻场客户，将复杂的数据整合与业务需求转化为可落地的AI解决方案。这一模式爆红的背后，正是AI应用面临的“非标诅咒”——从实验室到生产环境的“最后一公里”难题。FDE通过“产品化咨询”平衡个性化与规模化成为Palantir区别于传统AI公司的关键。FDE模式为AI落地提供了新范式：它不仅是Palantir的“秘密武器”，更可能成为Agent时代的组织标准——通过驻场共创，将非标需求提炼为可复用的产品飞轮。那么这种FDE模式成功的关键在哪里？其中的可复用AI产品沉淀需要如何实现又存在哪些核心挑战？与二十年前软件产品定制化开发的经验有什么本质区别？实践FDE模式对于工具、平台以及人员素质有什么样的要求？零代码、低代码、高代码等开发模式以及大模型、Agent、RAG、知识图谱等AI技术在其中扮演着什么样的角色？AI应用落地实践当前面临的主要瓶颈和未来的发展方向又在哪里？围绕这些问题，本期微访谈邀请了来自学术界和工业界的专家进行问题剖析、经验分享和未来展望，希望能为AI应用落地实践模式的探索提供一些有益的参考。
主 持 人
彭鑫
复旦大学
复旦大学计算与智能创新学院副院长、教授，国家级高层次人才计划入选者。中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，中国汽车工程学会汽车基础软件分会副主任，《Journal of Software: Evolution and Process》联合主编（Co-Editor），《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《Automated Software Engineering》、《软件学报》等期刊编委。2016年获得“NASAC青年软件创新奖”，2023年入选上海市东方英才拔尖项目，2024年获得“中创软件人才奖”。主要研究方向包括软件智能化开发、AI原生与云原生系统、泛在计算软件系统、智能汽车及工业软件等。研究工作多次获得IEEE Transactions on Software Engineering年度最佳论文奖、ICSM最佳论文奖、ACM SIGSOFT杰出论文奖、IEEE TCSE杰出论文奖等奖项。担任2022年与2023年CCF中国软件大会（CCF ChinaSoft）组织委员会主席与程序委员会共同主席，以及ICSE、FSE、ASE、ISSTA、ICSME、SANER等会议程序委员会委员。
访
谈
嘉
宾
张奇
复旦大学
张奇，复旦大学计算机科学技术学院教授、博士生导师，国家级领军人才。兼任上海市智能信息处理重点实验室副主任，中国中文信息学会理事、CCF 大模型论坛常务委员，在国际重要学术刊物和会议发表论文200余篇，获得美国授权专利4项，著有《自然语言处理导论》和《大规模语言模型：理论与实践》。获得上海市“晨光计划”人才计划、复旦大学“卓越2025”人才培育计划等支持，获得钱伟长中文信息处理科学技术一等奖、汉王青年创新一等奖、上海市科技进步二等奖、教育部科技进步二等奖、ACM 上海新星提名奖、IBM Faculty Award等奖项。
鲍捷
文因互联
鲍捷博士，文因互联首席科学家。爱荷华州立大学（Iowa State University）博士。曾任伦斯勒理工学院（RPI）博士后，麻省理工学院（MIT）分布式信息组（DIG）访问研究员，三星美国研发中心研究员，W3C OWL(Web本体语言)工作组成员，参与撰写了OWL2 知识图谱语言国际标准。现任W3C（万维网联盟）顾问委员会委员、中国中文信息学会语言与知识计算专业委员会委员、金融知识图谱工作组主席、中文开放知识图谱联盟(OpenKG)发起人之一，国际Data Intelligence杂志编委
黄非
阿里巴巴
博士，阿里巴巴通义自然语言智能实验室负责人&阿里云副总裁。他带领团队研发通义自然语言大模型体系，在机器阅读理解(MRC），图文问答（VQA）和中文理解（CLUE）等任务上实现首次超越人类结果。以通义千问大模型为基础，赋能软件开发，角色对话，办公效率，智能司法等行业合作伙伴。他博士毕业于卡耐基梅隆大学，先后在IBM 沃森研究中心和Meta领导机器翻译研发，在人工智能顶级会议和期刊发表文章300+篇，国际国内专利100+项，谷歌引用20000+, H-index 65, 曾担任ACL，TACL等学术会议领域主席和期刊编辑等。
肖然
Thoughtworks
肖然，Thoughtworks数字化专家、中关村智联联盟秘书长，长期深耕企业数字化与智能化转型，专注于AI、敏捷开发、DevOps及数据驱动创新。作为金融科技与数字化转型专家，他担任《财新》《数字银行》专栏作者，并为中行、招行、华为等企业提供战略咨询。近年来，他聚焦“软件3.0时代”下AI技术的行业落地，在TiD、InfoQ等顶级技术峰会发表主题演讲。同时，他积极推动技术社区生态建设，联合发起中国敏捷教练企业联盟（CAC）和DDD China，促进前沿技术在国内的普惠发展。作为上海交通大学高金学院讲师及工商银行研修院特邀专家，他致力于AI人才培养与行业赋能，助力企业探索高价值AI场景。
王新盟
字节扣子
抖音集团扣子技术负责人，字节跳动AgentOps团队负责人，专注Agent平台建设和研究，在字节内部从零到一孵化了Agent平台，并助力豆包、抖音、飞书、Trae等业务的Agent构建和效果优化。
章鹏
蚂蚁数科
章鹏，现任蚂蚁数科AI技术负责人，AI算法技术部总经理。于中国科学技术大学获得计算机科学博士学位，随后加入理光研究院，并在亚利桑那州立大学（ASU）担任博士后研究员。2014年回国后加入阿里巴巴集团，历任蚂蚁集团风控科技总监。参与蚂蚁科技商业化赛道核心AI算法技术研发，其研发产品服务于金融、制造、政务等多个行业的千余家机构客户的生产场景中。
李杨
京东科技
李杨，京东资深算法专家，主要研究方向包括智能体、大模型、知识图谱、对话系统等。已在ACL、EMNLP、SIGIR、AAAI、COLING、MM会议及期刊发表20多篇论文，获得NLPCC2018 Outstanding Paper Award。在CCKS2018 KBQA竞赛、FewCLUE、Quac、GAIA、BirdSQL等多个比赛获得冠亚军的成绩，此外开源了JoyAgent项目已获得11K Star。当前在京东负责智能体平台JoyAgent的建设，之前在阿里负责保险支小宝算法能力建设。
曹洪伟
联想诺谛智能
曹洪伟，全栈工匠，拥有近30年的软硬件研发经验，曾就职于北方电讯、斯伦贝谢、高通等世界500强企业，并作为CTO参与多家创业公司，其中渡鸦科技被百度收购后，发布了首款小度智能音箱。擅长软件架构设计、性能工程及物联网领域，拥有50余项国内外专利。曾任百度DuerOS首席布道师，推动对话式AI技术生态建设，著有《MCP极简入门》《性能之道》《深入分布式缓存》《一书读懂物联网》等书以及译作10+本。平时维护CSDN博客及公众号“wireless_com”，分享软件架构与AI工程实践。
茹炳晟
腾讯
茹炳晟，腾讯Tech Lead，腾讯研究院特约研究员，腾讯集团技术委员会委员，中国计算机学会（CCF）TF研发效能SIG主席，“软件研发效能度量规范”团体标准核心编写专家，中国商业联合会互联网应用技术委员会智库专家，中国通信标准化协会TC608云计算标准和开源推进委员会云上软件工程工作组副组长，国内外各大技术峰会的联席主席，出品人和Keynote演讲嘉宾，公众号“茹炳晟聊软件研发”主理人，二十余本技术畅销书的作者和译者。
毛舒能
华为
毛舒能，博士，华为公司2012泊松实验室技术专家。长期专注于知识检索、机器学习、大数据挖掘、自然语言处理、大语言模型应用、智能体框架等方向的技术研发与实践。已成功将多项先进技术在业界场景中落地，所涉应用包括超十亿用户规模级的（To-C）国际化产品，以及全球500强企业的（To-B）生产系统。
访谈主题
从FDE看AI应用落地实践模式
01
您是如何理解Palantir的AI FDE（Foward Deployed Engineer，前线部署工程师）模式的？其核心思想以及成功的关键在哪里（Ontology起到什么样的作用），近期突然爆火背后的原因是什么？
02
FDE模式如何平衡标准化平台产品与定制化AI应用之间的矛盾？其中可复用AI产品沉淀需要如何实现，又存在哪些核心挑战？与二十年前软件产品定制化开发的经验有什么本质区别？
03
实践FDE模式对于工具、平台以及人员素质有什么样的要求？零代码、低代码、高代码等开发模式以及大模型、Agent、RAG、知识图谱等AI技术在其中扮演着什么样的角色？
04
当前国内AI应用落地的主要障碍和挑战是什么？有哪些应对手段？在这些方面的具体实践上中美两国有什么区别？
05
FDE模式的爆火对我们有什么样的启示？AI应用落地特别是中国的实践模式未来将朝着什么样的方向发展？
Q&A记录
Question 1
主持人：您是如何理解Palantir的AI FDE（Foward Deployed Engineer，前线部署工程师）模式的？其核心思想以及成功的关键在哪里（Ontology起到什么样的作用），近期突然爆火背后的原因是什么？
鲍捷：
我没有觉得FDE是一个新事物，其实所有的知识工程都不可能缺少一线的咨询这个问题。咨询直接作为工程落地，需要一个工具，之前没有这个工具，Palantir 在没有大模型的时候，用 Ontology 做这个工具。
黄非：
FDE（Forward Deployed Engineer）模式本质是：工程师深入客户一线，与业务团队一起定义问题、构建数据模型（Ontology）、落地 AI/软件决策系统，而不是“交付软件就走”。其核心思想是 深度嵌入客户场景，解决真实、高价值的复杂问题——并用 通用平台 + 客户专属定制 的方式实现快速迭代。
观点讨论
@彭鑫：我觉得是个综合体。里面不少东西都可以在过去二三十年的信息化浪潮和企业软件实践中找到影子。
@黄非：所以是软件系统和AI系统落地真实场景的必须步骤。
@彭鑫：数据模型和 Ontology 在 Palantir 的成功故事以及 FDE 实践中提得比较多。是不是因为现在大企业很多智能化应用其本质很大程度上就是企业应用集成？当然这种集成与20年前 EAI 那个概念相比多了很多智能化的元素，如大模型和 Agent 的应用。当然企业的信息化基础设施（比如建设的各种信息系统）也比20年前好很多。
王新盟：
同意前面两位老师的。FDE 模式并不新鲜，但在 AI 时代又火起来了，核心原因是，在 AI 时代，交付的不再是实现一个功能的产品，而是交付一个效果可用好用的 Agent。对效果负责，客户也愿意为效果付费。商业模式跟过去有差异。
另外，FDE 模式核心是有一套强大的平台支撑，可以让FDE工程师能够在客户侧高效的实施和部署，所以不能单纯的只看 FDE，要看到这个模式下的另一个角色，PD，也就是平台产品开发。FDE 要跟 PD有更多的联动，FDE 需要把在客户现场实施获得的一些认知沉淀下来，反哺到平台建设上，让其可复用，降低边际成本。
一个好平台产品的设计，应该是一个最佳实践的产品化，而且应该是先有最佳实践，再将其产品化落地为平台产品。不能反过来，否则就是闭门造车，做出来的产品没人用，跟实际业务诉求有巨大 gap。
肖然：
我们咨询行业非常关注这个模式，因为 Palantir 实际上完成了“规模化、定制化”。过往我们非常痛苦就是客户个性化需求，无法有效进行产品化。FDE之所以能够大家关注，就是他完成了这样一个转身。
观点讨论
@鲍捷：这个很难，也很挑客户，在国内好像没有看到成功的例子。
@赵俊民：国内企业有这种认知的领导应该很少。
@章鹏：@赵俊民 正确。
@鲍捷：我觉得是阶段没有到，另外钱没有到。Palantir服务世界500强起家。
@章鹏：同意 FDE 不是新概念，但是新形势下的提法。
@黄非：ToB 的应用一直有做平台化产品和做定制化产品两种不同的路线。作为平台化产品的研发部门，做定制化需要高投入，可复用性低。确实会对于产品价值有挑战。但是Palantir通过做定制化，可以扩大服务关键客户的规模，实现价值的不断扩展。这个路线和国内的厂商不太一致。
@彭鑫：“规模化定制化”在软件行业似乎不是个新概念。20多年前就有很多软件企业在企业信息化中摸索出了特定领域的生存之道：将标准化产品与定制化开发相结合。这个上升到学术高度的话，就是软件产品线和领域工程等。
@肖然：话虽如此，但工程问题碰撞了商业现实，过往的产品线工程非常难落地，研发团队的话语权决定了还是只有跟着市场跑。
@肖然：Palantir 的成功其实是商业成功，这个很难得，不能完全从技术工程视角来看待。
@鲍捷：同意，主要是商业层面的。
@章鹏：本质是市场差异。
@彭鑫：@章鹏 这个确实。20年前软件企业做行业内的定制化开发基本上还是基于通用平台定制发布，基本不会到客户现场开发和探索，当然更没有大量 AI 技术的应用了，不管是用 AI 生成代码还是以 Agent 的形态直接将 AI 能力加入交付方案中。
@肖然：为非常特殊人群定制工具，然后还能够数年积累平台和产品力，在 AI 时代开启多个领域的快速获客，这个是历史上第一次。
@鲍捷：这个不仅是商业的成功，也是公司管理的成功；我倒觉得和技术关系不大。
@赵俊民：规模化方式做非规模化，实现这个，感觉需要及其好的抽象能力，组合能力，这个核心关键是来自那些核心技术突破。
章鹏：
Agent 区别于传统软件，最大的差别是面向场景价值驱动（Outcome-Driven），而非软件面向功能需求驱动（Feature-Driven）。这与传统ToB软件开发交付有质的不同，对前方交付人员的综合素养及全栈能力提出了极高的要求，需深入理解场景业务问题，制定技术解决方案，并通过平台工具开发，并敏捷迭代优化性能—— “少而精”，并且有“核心武器”才是关键。 如果做一个类比：FDE是是“特种兵”，AIP是“武器库”，那么Ontology（本体）就是“作战地图”和“共同语言”。
观点讨论
@彭鑫：@章鹏 这个概括通俗易懂：FDE是是“特种兵”，AIP是“武器库”，那么Ontology（本体）就是“作战地图”和“共同语言”。
@鲍捷：Ontology 本身，失败案例远远多于成功案例。
@黄非：关键是定制的工具具备通用性，依赖他们构建的Ontology 体系。可以在不同领域得到应用
@李杨：@鲍捷 之前做 KG 的同学，表示非常赞同。
@肖然：工程方面我觉得也有突破：第一次明确了Delta快速交付的是抛弃型原型，不是真正的产品。这点过往很难为企业所接受。
@彭鑫：与传统的抛弃型原型有什么区别？软件工程特别是需求工程领域一直很强调通过抛弃型原型来把需求搞清楚。当然过去的现实实践中抛弃型原型可能并没有那么多企业真的去大规模实践。
@章鹏：这个是中间过程产物，正确没毛病。但很难作为交付验收物，当然中间验收可以谈。
@肖然：@彭鑫 这点在工业界从未成为现实，只是一些startup可能看到。
@肖然：@章鹏 Delta team的关键使命是将Echo team探索发现的idea以最快速度实现用户可用、可验证。
@彭鑫：@肖然 确实，大多数时候软件企业还是想着把自己已有的产品卖出去。包括一二十年前IBM大力推崇的solution engineering，想的也是如何把自己和合作伙伴的产品打包（也许有少量定制）凑成个解决方案卖给客户。
@黄非：@彭鑫 软件厂家是卖产品，P厂是为了最终效果负责进行开发，更接近卖“效果保证的服务”。
@赵俊民：Palantir AIP 产品架构
李杨：
非常赞同前面各位老师的。FDE 很早就有了，之所以 FDE 模式近期受到广泛关注，主要是因为它精准命中了当前 AI 行业的痛点：企业有强烈的 AI 应用需求，但通用的 AI 产品很难直接适配他们复杂的内部系统和业务流程。
观点讨论
@王新盟：@李杨 对，主要还是实际业务痛点和 AI 能力之间的撮合。
@王新盟：Agent 时代，交付 Agent 只是开始，后续效果要持续运营和效果提升。
@彭鑫：一点感觉，大模型和 Agent 在 FDE 的爆火中确实发挥了巨大的作用。因为从大模型和 Agent 应用开始，人们开始强调价值来自于最终结果而非产品本身。比如智能客服的价值在于服务了多少用户的常规问询以及多大程度上提高了用户满意度。这些都使得客户企业从追求好的产品交付部署到追求好的解决方案了，因此自然就开始拥抱FDE这种模式了。
@黄非：AI 时代就是快速迭代，不是产品研发到稳定状态才能交付。这个也是和传统软件开发不同的方面。
@彭鑫：@黄非 那为什么AI 时代有这个差别或者新的机会呢？比如是因为AI 生成代码能力使得我们可以快速构造和试验解决方案？还是因为以 Agent 为代表的 AI 元素大量进入产品形态中，增加了产品的灵活性？
@黄非：都有吧，另外一个也是模型的技术不断发展变化，根据模型能力快速迭代也是必须的。拼手速。
@彭鑫：嗯，感觉到除了这两点之外，AI 这股浪潮还带来了一个改变：大家都对 AI 的发展和应用充满了憧憬，同时又没有标准化的方案，所以客户企业在心态上会倾向于以一种不确定的以及与开发企业一起探索的心态来追求未来的智能化应用效果。这在这波 AI 火起来之前可能是不太有的。
@李杨：@黄非 今天在公司内部也在思考讨论 AI 时代的交付变了：持续 + 快速的迭代，直接做价值交付。以前做交付的更多是产品或者能力层面的交付。
曹洪伟：
讨论的前提是概念澄清， 那么，什么是FDE 模式？Forward Deployment Engineering， 前置部署工程/前置实施工程一个不恰当的比喻， 有点像物流系统中的前置仓， 类似美团“小象超市”。FDE 不是简单的“驻场外包”，而是把“产品发现”搬到客户，用工程师替代传统售前，把最后一公里的隐性知识灌进本体，再反哺平台，形成“数据-本体-模型”飞轮。
通俗而言，Ontology是一种数据建模方法，其作用是把客户需求翻译成机器可推理的语义网络， 当客户 需求变更是，只需在本体层加子类，平台层不动，而且，同一本体可实例化成特定领域的知识图谱，代码复用率较高。
爆火根因 或许是 Palantir 的成功所致，LLM 需要私有数据+私有推理链，FDE 成为了“数据管道工”。 重要的是，Agent 需要“行动本体”——没有现成商品，只能现场画蓝图实施。 同时，企业 CFO 更愿意为“结果”而不是为“License”买单，FDE 卖的是结果。
茹炳晟：
我认为FDE模式成功的关键在于，它通过独特的“探路者模式”和“从个性案例中提取共性”的循环机制，规模化地解决了非标难题。而 Ontology 作为概念抽象的技术底座，为这种高成本的深度服务模式提供了实现规模和效率的可能。这些结合起来，共同构成了 LLM 时代企业落地难以被简单复制的核心壁垒。
毛舒能：
FDE 近期爆火，因为大模型带来很多新的机遇，AI Demo原型搭建非常快捷，新技术、新模型迭代很快，但是企业又意识到仅靠模型无法落地实际生产，所以需要业务+工程的高效结合，因此带火了FDE。其中 Ontology 对业务进行抽象，让数据、流程、权限、工具在统一语义空间下，使 AI 能够更加安全可控地执行任务。
观点讨论
@茹炳晟：“演示驱动开发”其实容易快速看到成果，帮助企业决策者建立落地的信心。这个开头是好的，但是能否规模化抽象到 Ontology 层，很考验高纬度的抽象能力。高度抽象之后还要有能力在个性化场景中泛化。
@肖然：这个是两个不同的目的：1. Delta 的快是验证；2. Ontology 本质上是产品团队来做的。Delta 团队并不是产品团队。
@王昊奋：@肖然 两者如何结合？或平稳顺接呢？
@肖然：这点问了美国那边团队，他们的答案基本是指向产品团队是独立决策的，并且很强的从各个 Delta 团队去抽象共性的能力。
@王昊奋：好吧，那和我想的一样。还是产品力强的驱动
@肖然
：Delta Team 配置非常精兵，这个跟之前玩法不同。并且我会认为过往我们认为优秀的工程师，不一定适合 Delta 团队。
@茹炳晟：@肖然 是的，后续能否低成本规模化其实很大程度上取决于产品团队的能力。Echo 和 Delta 还只是项目型交付。项目型交付其实是“定制化为标准化输送素材”的一种行为模式。
Question 2
主持人：FDE模式如何平衡标准化平台产品与定制化AI应用之间的矛盾？其中可复用AI产品沉淀需要如何实现，又存在哪些核心挑战？与二十年前软件产品定制化开发的经验有什么本质区别？
鲍捷：
总的来说，我并没有认为FDE模式对传统需求工程本身有大的变化，我想更大的成功还是在组织和管理上，而不是 Ontology 作为一个实现方法上。即使不用 Ontology，就是用ER图+工作流做建模，也不见得做不到。Ontology 需要的极强的高质量数据能力，也不是能普适实现的。
彭鑫：
感觉 MCP 协议打开了存量应用和私有数据向大模型和 Agent 主动开放的通道，当前 Agent 接入控制存量应用的另一种途径是 GUI Agent，这种就是被动模式了。MCP 是不是可以进一步将 Agent 与具体的数据源和遗留应用解耦，从而提高 Agent 应用与具体执行环境的可移植性？
观点讨论
@鲍捷：所以，我认为，FDE 的成功，一定是深植于 Palantir 组织文化和组织内部政治格局的一个成功，特别是基于 Ontology 的 FDE，不一定有广泛的可复制性。
@彭鑫：是的。我们经常讨论的类模型、ER模型、本体概念等等，好像不一样，但只要脑海中的业务概念抽象成型了，这几种形式基本上都能很大程度上表达清楚。
黄非：
FDE模式的关键，是以“标准化平台 + 轻量化场景定制”来解决传统软件定制化的效率与质量矛盾。平台层保持高度标准化（数据接入、权限、审计、AI/模型库、Ontology 语义层），而 DE 在客户现场只做少量“业务语义映射”，避免深度重写代码，从而实现快速落地。 复用型 AI 产品的沉淀依赖三个核心：
Ontology 将行业数据与流程抽象为可计算结构，使不同客户之间的底层语义可对齐；
模块化能力组件（AI 模型、工作流、可视化） 可插拔复用；
反馈闭环（DE→平台）持续强化通用能力。
肖然：
FDE的工作目标和产品团队目标相对解耦是关键，这个模式震动咨询行业的原因是提供了AI时代 Consulting + Product的商业模式可能性。对从MBB这样的战略咨询，到我们这样的技术咨询，大家基本都在开始做类似的组织转型了。
王新盟：
这里核心要看的是所谓 AI 应用的定制化在哪里，Agent 当然是特化的，我觉得现阶段没有也暂时不会有一个万能 Agent 能够解决所有企业的实际问题，一个是企业的问题太垂类了，另一个是待解决的问题完全跟企业内部数据等强相关。所以这里一定是有定制的，Agent 一定是特化的，但我们要看特化的点在哪。比如SP的不同、Skill 的特化、工作流的搭建、评估器的编写等等，这些在不同的 Agent 下都是不一样的。 但同样，我们也要看到里面的共性和抽象，比如 Agent 的搭建模式、开发范式都是可以抽象的，Skill 的构建也可以平台化支持，评估器和评测标准虽然有差异，但是评测流程是趋同的，是不是可以有一套高效可用的评测平台来支撑 Agent 评测等等。 跟二十年前的软件产品定制化开发的区别，我觉得，传统软件定制是流程驱动、数据作为被动载体、交付固化软件系统、交付后重运维、核心壁垒是工程实现能力；FDE 模式是模型驱动、数据是核心资产、交付持续学习的应用、交付后重运营、核心壁垒是数据 × 模型 × 场景的闭环能力。
观点讨论
@鲍捷：基于大模型的软件工程，可以比 Ontology 的方法更容易支持 FDE，学习成本更低。
@肖然：如果没有 AI4SE，我会认为 Palantir 的成功是很难复制的，FDE 团队的能力要求过高；但有了基于 LLM 的Copliot 到 Agentic Coding，我认为这种组织形态会快速被个大企业复制。
@肖然：我会更认为年轻一代更适合 Delta
@彭鑫：@肖然 本质变化是有了 AI 辅助之后，现场快速构建软件变得更容易了？当然我猜想大部分时候现场构建的应该主要是 Agent 以及与现有系统对接时的一些粘合代码。客户企业已有的信息化系统仍然是重要的基础，可以通过接口和功能保障提供 Agent 所需的工具能力。
@肖然：之前 Planatir 的 FDE Team肯定没有AI辅助，所以应该说能力非常强。现在很多企业，类似 Salesforce，做法上都是因为有了 AI 辅助。
@茹炳晟：我的理解 AI 辅助只是加速了 Delta Team，但不是 FDE 模式的核心关键点。
@肖然：我认为是成为可复制组织模式的关键。
@彭鑫：@肖然 怎么理解“可复制组织模式的关键”？是指这类企业应用场景很大程度上是把 Agent（如数字员工）引入组织模式中？
@肖然：我认为没有 LLM 这波，这个模式收到这么大关注是不可能的。这种快速探索和实现关键是控制成本，并且时间必须短。FDE 这种组织模式受到工业界的广泛关注，并且大家都开始向这个方向转型。
@彭鑫：@肖然 这其中 FDE 工程师的经验和能力太重要了。其基础应该很大程度上与传统软件开发中的领域分析和软件设计能力应该也是相通的。
@肖然：分了两个小团队：Echo（业务经验专家）+ Delta（快速实现小组）
章鹏：
前面说过，Agent面向场景价值驱动的交付，与传统软件面向功能需求驱动的交付有本质不同。FDE 需要定制的不是平台功能，而是场景Agent。 其中可复用AI产品需要沉淀的是：
构建智能体的blocks，如 场景工具（如市场行情 For 交易智能体，MCP是可能的形态）、知识库（如行业数据）、模块组件（如意图、取数）、SDK；
场景智能体方案，包含构建方案（方便后续修改复制）、评测方案（评测集或数据合成）。AIP Ontology 掰开来，其实应该也是这些东西。
李杨：
FDE 模式通过将定制化视为标准化输入的来源来解决矛盾。下面的例子感觉比较形象。它先为单个客户“修路”（定制化应用），成功后，再将这条“路”的设计图纸和核心部件（可复用的模块）沉淀到中央平台（如Ontology），供其他客户使用，实现从“碎石路”到“高速公路”的升级。
观点讨论
@李杨：从 OWL 语义规范 Ontology 到 Palantir Ontology：感觉像是从知识表示到业务操作。传统OWL本体专注于概念分类与逻辑推理，构建语义网络。而 Palantir Ontology 定位于"组织的操作层"，不仅描述业务实体（设备、订单），更封装可执行逻辑（审批订单、触发维护）。本质差异在于：OWL 是领域知识的"语法规则"，Palantir Ontology 则是驱动业务的"操作系统内核"。
@章鹏：是的，这应该是从认知走向交付实现的必然结果。
@彭鑫：@李杨 如何理解 Palantir Ontology则是驱动业务的"操作系统内核”？比如在不同客户差异化的业务流程之上抽象出一套共性且可定制的业务流程？
@李杨：我理解是的，像之前 OWL 语义规范是需要专家定义领域 Ontology 的，现在实际业务交付中 FDE 深入业务一线打头阵的同学是需要定义整套的业务流程验证价值的（设计出图纸），然后后面再批量大规模复制（修高速公路）。
@彭鑫：明白，感觉很大程度上就是业务和设计抽象。
曹洪伟：
在 FDE 模式中，采用了“本体粒度”做隔离：稳定部分放到平台，变量部分留给 FDE 现场脚本。
FDE 中的沉淀顺序：场景案例 → 本体升级 → 模型微调 → 前端组件。
复用是软件工程中的传统课题，可复用 AI 产品 既有面向运行时的服务，又有面向业务的数据模型或 Schema。
核心挑战在与抽象的粒度，抽象过度→客户不认；抽象不足→平台臃肿，复用率、毛利、交付人天三维指标常常打架。
20年前的 ToB：需求→写代码→交付→维护，边际成本线性；
FDE 模式：需求→改本体→生成新数据视图→权重微调，边际成本下降，“本体+权重”可同时服务多家客户。
茹炳晟：
FDE并非简单地“在定制和标准之间做选择”，而是构建了一套将”定制化视为标准化养料“的动态循环系统。Ontology 本质是一个可扩展的标准化内核。它提供了标准的数据模型、关系定义和操作框架（类似“乐高积木”的规格），同时允许 FDE 在现场根据客户需求，灵活地创建新的“积木”或调整原有关系。这种设计使得定制化开发不是从零开始，而是在一个有约束的创造性环境中进行，这些约束不仅是被复用的，而且包含了前人的智慧。当一个新的“积木”被创造并验证有效后，它就可以被平台回收、审核，并转化为新的“积木”标准。
观点讨论
@茹炳晟：能否从早期那些高成本的定制项目中准确抽象出共性，并设计出足够灵活又不过度复杂的平台架构，这极度考验背后产品团队的前瞻性设计和抽象能力，这个才是FDE模式最终能够获得长期成功的关键。
@彭鑫：复用的基础是业务和方案抽象，而抽象粒度的把握确实是一个难题。过度抽象会导致定制化难度增加，抽象不足又导致复用机会丧失。
@茹炳晟：另外如何将FDE在前线获得的隐性知识高效、无失真地传递给总部产品团队，也会是一个巨大的组织管理挑战。因为 FDE 的眼光还是短视的，屁股是坐在当前项目的交付上的，而总部产品团队又不直接接触一线，基本是二手信息，两批人的”战略“目标对齐会是管理上的大难题。
@茹炳晟：而且在项目早期，FDE 模式的人力成本极高。需要多少项目才能建立起某个行业的 AIP 也是问题，否则长期看FDE模型将无法实现盈利。
@彭鑫：@茹炳晟 FDE 的故事强调所交付的解决方案在客户企业那里起到的是极其重要的作用，例如解决的是领导关心的前五个最大的问题，因此客单价应该是很高的。
毛舒能：
FDE 本身就是为了平衡标准化平台产品和定制化场景的矛盾。过去可执行逻辑在代码中，复杂业务逻辑需要大量的业务代码；如今很多关键逻辑被 AI Agent，Workflow，Prompt所包含，已经有不少场景可以通过“低代码”甚至“零代码”的方式快速构建，结果是 Demo 和交付速度大幅加快。核心挑战还是在于 AI 系统本身的可靠性、可预测性，无法避免的模型幻觉等。
观点讨论
@肖然：可以认为是 PoC 和 Prod 的 Gap，但不可否认 Idea需要 PoC 验证，特别是 AI 的想法。
Question 3
主持人：实践 FDE 模式对于工具、平台以及人员素质有什么样的要求？零代码、低代码、高代码等开发模式以及大模型、Agent、RAG、知识图谱等 AI 技术在其中扮演着什么样的角色？
张奇：
FDE 工程师作为 AI 技术落地的核心执行者，需深度扎根企业实际业务场景，不仅要系统且细致地拆解企业的全链路工作流程——从前端数据采集、中间环节流转到终端成果输出的每一个关键节点，还要精准捕捉流程中潜藏的效率瓶颈、数据短板、场景适配偏差等难点痛点，摸清技术需求与业务目标的契合点。在此基础上，工程师还需具备灵活的模型优化能力，针对企业特定业务场景的个性化需求，在合规可控、数据安全的前提下，对模型进行针对性的微调、参数校准或适配性调整，确保模型性能与实际业务需求高度匹配，切实打通 AI 技术从实验室到产业应用的“最后一公里”。
鲍捷：
基于 Ontology 的FDE 对人员素质要求太高，高到可能没法复制。知识图谱方法是本体方法的一个弱化版（减去推理），肯定也是有用的。知识图谱可以帮助实现（相比传统数据工程）更复杂的概念建模。整个大模型的工具链条是大大有利于提供一种更加低成本的 FDE。
黄非：
FDE 人才本身必须具备跨界能力：既懂工程，又能深入客户流程；既能抽象业务语义，又能将一线需求转化为平台可复用能力。与传统外包式定制化不同，FDE 不靠人力堆代码，而是靠平台能力沉淀 + 业务语义抽象 + AI 自动化 实现规模化交付。
观点讨论
@茹炳晟：一个优秀的 FDE 需要是工程师、咨询顾问、产品经理、销售和老板的复合体
@赵俊民：依赖人的能力这个事情感觉不靠谱，可能还的是工程和工具，技术能力才可以维护低成本
@鲍捷：@茹炳晟 太难做到了
@章鹏：所以是特种兵
@赵俊民：依赖特种兵感觉挺难规模化
@茹炳晟：是的，很难，如果有这样的人，不用 FDE 应该一样会成功。
肖然：
首先工程能力还是重要的，Palantir Apollo是一个CI/CD平台，这个虽然大家觉得普通，但说明咱们工程的东西人家没有丢。这是为什么各大咨询、SaaS公司全面都在转型。比如Salesforce、Workday。
FDE模式虽然是难，但趋势还是明确的，Agentic 这一波浪潮，基本让 SaaS 服务被企业认为 ROI 不够好，要 Agent。但 Agent 对于每家企业、每个用户未来的定制化是显而易见的。现在看 FDE 模式最大挑战不在工具、平台，在：
（1）商业合作模式上是否能够容忍探索失败，比如甲乙方一起决定了一个 Agent，做出来发现效果不行，行不通；
（2）定制化和产品化之间有明确界限，大部分某个企业的定制化不会进入产品，这点组织是否接受。这两个意识没有解决，组建了很强的精兵 FDE 感觉也是跑不起来。
观点讨论
@彭鑫：@肖然 嗯，所以我感觉 FDE 的爆火也是因为广大客户企业对于大模型和 Agent 应用带来的智能提升抱有极高的期望同时认同其不确定性，因此对FDE这种现场定制模式有了更多的容忍度甚至支持度。
@王昊奋：@肖然 说到关键点了。
@彭鑫：@肖然 定制化 和 产品化 之间有明确界限，大部分某个企业的定制化不会进入产品，这点组织是否接受：关于这条有个想法。过去我们以确定性的代码的形式实现不同客户应用之间的共性沉淀。而大模型 Agent 的广泛应用使得我们可以通过数据、规则等更多更灵活的方式沉淀共性。因此“某个企业的定制化不会进入产品”也许有另一种解读，就是不是用传统软件代码的形式而是以其他看得见（如数据、规则）和看不见（如Know How）的形式实现了共性沉淀。
王新盟：
FDE 模式一定是需要有一套强大的工具平台作为支撑的，在 Agent 下，可以分为 Dev+Ops 分开看。Dev 也就是 Agent 搭建，不管是零代码、低代码还是高代码，都是 Agent 的搭建模式，零代码和低代码依赖平台，高代码依赖 ADK；而 Ops 也就是 Agent 的持续运营，依赖一套 AgentOps 的平台来支撑，包括 Agent 的观测、评测、数据沉淀、效果调优等等。 在 Agent 时代，FDE 的人员要求更加复合，一定要懂业务，是业务专家，又要能够熟练使用平台和工具，具备极高的动手能力，并且还要知道如何持续调优 Agent。实话说，很难。
观点讨论
@鲍捷：AI 建模的ops确实极度重要
@王新盟：+1
@鲍捷：我的实践中，我80%的时间都用在 Ops 上。
@彭鑫：@王新盟 我感觉对于这类应用而言，Ops 的重要性有了极大的提高。传统 Ops 针对的软件系统的功能和切望表现是确定的，主要关心的是不要出问题；而 AgentOps 还要负责观察实际应用效果并找到持续改进的机会。
@王新盟：是的，从另一个视角看，这其实也是 AgentOps 平台的机会。
@彭鑫：感觉 Agent 的长期记忆和知识积累很大程度上也是Ops 的一部分了。
@王新盟：基于线上数据持续回流调优 Agent 效果，让 Agent 越用越好，一定是 Ops 最重要的一部分。
@茹炳晟：+1
@毛舒能：对， Ops 非常重要，而且还可能是实现增值的重要手段，比如 LangSmith
@鲍捷：整个业务建模的自动化，用不用 Ontology不重要，是不是有了一套好的 Ops 系统，让系统能够从错误中快速学习，让业务表达用自然语言能力快速反馈，是关键。
章鹏：
FDE 需要较强的技术架构能力、业务理解及沟通能力、对于智能体构建组建的理解和应用能力——其实非常相似10年前伴随着 Big Data 浪潮兴起的 Data Scientist 角色，只不过应用的工具从 ML/statistics 变成了 Agent构建工具，e.g. LangGraph等开发框架（类比当年的Sklearn）。
李杨：
的确要求很高，但也是我们在公司里面常常提到要求，T型人才：既要懂技术（编码、建模），又要懂业务。
曹洪伟：
FDE 对人员素质的要求较高，复合人才需同时掌握领域语义 + 全栈技能 + Prompt 工程；
FDE 对平台的要求：数据总线 + 版本化本体注册中心+基于AI的推理服务；
FDE 对工具的要求：低代码画流程，高代码写本体，零代码给业务客户做 Prompt 模板。（本质上是业务数据驱动）
AI 技术在FDE中的角色主要包括：
RAG：负责“知识即时性”，解决 LLM 幻觉；
Agent：封装“动作本体”，让模型可调用 API；
知识图谱：提供“可解释路径”，让客户看到“为什么推荐此参数”；
大模型：底座，但必须在客户现场再跑一次微调/LoRA，否则 FDE 模式意义不大。
毛舒能：
FDE 模式对于工具、平台的成熟度和人员素质都有很高的要求。从趋势上来说，随着平台的成熟度越高，工程师可以更多的关注在如何将业务语言转化为工程语言，从而降低在工程实现上的负担，因为后者可以更多的由平台和工具辅助完成。不过，新的需求和更复杂的业务场景又会带来新的挑战，因此，对于平台和人员的要求可能是螺旋式上升的。对于平台来说，除了需要具有应对业务挑战的能力，由于 AI 的不确定性和复杂性，还要有很好的运维 Ops 的能力。 零代码、低代码、高代码都是必要的开发模式，前两者大幅降低包括 FDE 在内的开发人员的门槛，高代码可提供必不可少的灵活性和定制能力。而大模型、Agent、RAG、知识图谱都是构成完整AI应用生态的模块。其中，由于agent具有自主性，将会是整合其他资源和工具的关键一环。
Question 4
主持人：当前国内AI应用落地的主要障碍和挑战是什么？有哪些应对手段？在这些方面的具体实践上中美两国有什么区别？
张奇：
当前 AI 落地难的核心症结在于，模型在各类实际场景中难以达到90分的高可用标准，性能往往仅停留在30-80分的区间。为了达到实际使用要求，要么是大量增强外围支撑工程，要么是针对特定场景进行模型后训练，而这两种解决方案都伴随着高昂的成本。
鲍捷：
国内基本还是驻场开发为主，这种方式很难允许 FDE 的方式落地。高素质的FDE不可能接受驻场纪律。付费模式不支持这种高质量的工程人员。项目工期的压力不支持这种快速迭代的工程方法。
观点讨论
@章鹏：@鲍捷 其实也可以，大厂有 ToB 板块。钱给到位就行
黄非：
国内企业的数据碎片化与治理不足行业间、地区间数据标准不统一，政企数据“各自为政”，可用的高质量标注数据不足；同时隐私保护和数据安全制度仍在演进中，很多单位对“能不能共享、怎么脱敏”没有清晰操作规范，导致可用数据打折扣。
另外是人才与组织能力缺口，一线具有“AI + 行业”复合能力的人严重不足，大量传统企业数字基础薄弱，业务侧不会提需求，技术侧不懂场景，出现PPT、Demo 很多，但真正规模化落地很少的情况。
开源权重+ RAG +私有化部署是可尝试的技术路线。 在算力受限、数据敏感的环境下，更常见的做法是基于开源权重（如 Qwen系列）、本土模型做精调，配合 RAG、代理、多模态技术，以及在政企专有云或本地机房中私有部署，以兼顾效果与合规。
肖然：
AI落地最大难点是，不愿意为探索付费。作为乙方，最常听到的是：我们领导希望是干货，要介绍跟我们对表企业的成功agent，然后我们看哪个适合我们。
我认为这个只有通过国家来推动，比如最近“AI+”的各种要求，建立“探索预算”。SaaS 时代我们是彻底迷失的，不是因为技术和人才问题，而是商业环境问题。企业习惯性不为定制化付出，最后造成的结果就是软件企业为了活着，违心说都是“产品”，其实都是后面定制开发，每个项目都不赚钱，最后就只有死路一条。科创企业过去两年经历了同样的问题，然后国家下场要求创建科创基金、投资，正视科创的不确定性，很多投资就是会失败。
观点讨论
@彭鑫：是的。AI 落地可能客户需要有个心态变化，就是不能和传统的软件产品落地那样去追求确定性的交付。
@彭鑫：@肖然 这一点对于国内很多企业，特别是国企，可能是个很大的挑战。因为不确定性背后隐藏着决策责任风险问题。
@肖然：国内企业目前仍然是大部分不接受，一个项目必须交出“成功 AI 应用”。
@肖然：正面看国内 Agentic 这波是可以利用来解决 SaaS 时代普遍存在的问题的，LLM 和 Agent 的不确定性其实全社会都开始认知了，这点和 SaaS 时代非常不同。这点是给大家创造了去接受不确定性的意见。
@彭鑫：@肖然 是的。客户心态和接受度还有一个转变过程。过去采购软件相当于雇用了一批确定性同时功能和能力固化的员工；现在采购 AI 解决方案则相当于雇用了一批更加聪明和自主但偶尔会犯错误的员工，并且他们还需要长期磨合和调整才能高效工作。
@肖然：我认为国家其实是清楚科创行业现在的窘境的，确实也在想办法、出政策。可以预期类似“创新资本”、“探索预算”这些东西会出现。
王新盟：
国内 AI 应用落地的挑战，最主要的还是 Demo 到生产的巨大 Gap。我觉得可以从两方面去看： 一个是效果，做一个 Demo 很容易，很快，甚至如果只从 Demo 看反而还有点惊艳，但效果距离生产，还有很长的路要走，80 分很容易，90 分太难。依赖人员对效果调优的认知，依赖平台，依赖工具，依赖高质量评测集，准确的评估器。 另一个是企业内部数据，要交付一个真正企业内可用的 Agent，一定要跟企业的数据打通，盘活企业数据资产，Match 企业实际业务场景，而一般来说，国内企业的数据基础太过薄弱，质量低，结构乱。
章鹏：
在中国，AI 应用落地主要有两个挑战：
供给侧：从业人员及行业平台产品水平不一，导致智能体性能不能满足实际应用需求；
需求侧：中国 ToB 市场定制化、本地部署需求大，以及“重硬轻软”导致交付成本高企，这背后和国企采购、考核制度都有关系；此外，企业对于 Agent 的构建及评测交付本身也缺少经验和共识。
解决方式，可以从两头：
供给侧，从业人员的培训认证（如FDE）、严肃场景智能体关键技术共识之上的产学界合作及推广；
需求侧，智能体应用的产业指导意见乃至标准的设定推广，可以从某些数字化水位较高且有政策引导的行业开始；中美的区别，本质不在“供给侧”（人跟技术没有差别）、而在“需求侧”（中美企业的差异）。前者是金字塔型，主要以央国企、政府为主，对本地化及定制有较多诉求；后者是纺锤形，以腰部中型规模私有企业为主。后者对于公有云接受度更高，对标准化也有更高的诉求，从而降低了toB的交付成本，也更容易形成能力的回流沉淀。
李杨：
最大的障碍和挑战个人亲身体验：
缺乏耐心：自己的切身感受，以前的项目按照双周迭代，现在大模型出来之后按照3天迭代（老板原话有了大模型直接用起来，我要3天看到 MVP）
业务老板预期极高和大模型现在只能做到80%的现状 Gap
观点讨论
@彭鑫：@李杨 "大模型现在只能做到80%的现状Gap"这一点美国也一样吧，那为什么他们的 FDE 模式这么成功？
@赵俊民：是不是未来国内只适合大型国企，不过往往都是垄断行业。私营企业有必要？
@肖然：美国那边有大量企业合作已经开始“结果付费”，国内尝试到目前都很难，采购合规一大堆流程都卡死新商业模式。
@彭鑫：@肖然 是的，领导决策风险极高。
@李杨：国内是在缺乏耐心下的快速 MVP 条件下，没时间做SFT、RLHF等更精细的活。在国内 MVP 阶段出不来结果可能项目就没了。国外有一定耐心，可以持续迭代。 所以快速 + 持续缺一不可。
曹洪伟：
国内 AI 落地主要障碍可能在于对 AI 的认知，认知障碍表现为"为 AI 而 AI "的盲目跟风和过高期望。在制造业等复杂场景中，AI 应用需要与原有 IT 系统兼容，增加集成难度。更重要的是工程化人才的缺失， 大家推崇“工匠精神”却不给工匠的生存和成长空间。
主要的应对手段可能是有效的 AI 普及教育，避免劣币驱逐良币，要务实，脚踏实地。IT 系统的现代化改造是必要条件，否则难以使用像MCP 这样的利器进行集成。踏下心来做工程技术，某种程度上，大模型或许是一种工程能力上的胜利。
中美技术路线差异可能图体现在基础研究与应用落地的侧重点不同：以资本支持为例， 美国吸引了全球 SaaS 融资的70%，中国风险资本匮乏，AI 创业公司更倾向于 ToC 工具型应用，缺乏深度行业解决方案。
茹炳晟：
当前国内AI应用落地的主要障碍我总结了以下几点：
・通而不专：通用大模型与复杂垂直行业场景适配度低。
・业务与技术“两张皮”：懂AI的不懂行业，懂行业的不懂AI。
・基础研究相对薄弱：底层框架和核心硬件受制于人。
・高质量数据匮乏：数据孤岛突出，合规获取难。
・数据质量参差不齐，难以满足行业模型训练需求。
・管理者过高的期望：被各类博眼球的文章带了节奏，过高的期望和较差的落地形成鲜明对比。
・寒武纪式的遍地开花：容易失去焦点，单一技术路线探索深度不足。
・开源生态影响力不足：全球AI关键工具和生态仍由美国主导。
・高端复合人才紧缺：同时精通AI技术、业务和工程实现的“独角兽”稀少。
从技术路径来看，美国更注重底层架构的原创性突破（所谓的“根技术”），中国则更偏向应用导向的快速迭代。中国企业常从具体业务需求出发，快速将AI技术集成到现有产品中，在实战中迭代和优化。从商业变现模式来看，美国会花费大量时间和资金完善技术，然后推出相对成熟的产品，如果产品业务价值被市场认可，其技术壁垒和先发优势就非常明显，很难短期被超越。而中国则更倾向于在多个场景测试技术，通过用户反馈快速迭代产品，更敏捷地响应市场需求，以此形成商业闭环。
毛舒能：
AI 应用相比传统软件有其自身的特点，前面已经讲过，主要挑战在于企业既要 AI 应用的智能性、同时又要有传统软件的可靠性，不过这并不是国内 AI 应用特有的问题。美国由于头部 AI 企业带来的效应，更侧重于试图打造 AGI/ASI 来彻底解决 AI 的问题，中国更偏重于先解决眼前实际场景中遇到的实际问题。
Question 5
主持人：FDE 模式的爆火对我们有什么样的启示？AI 应用落地特别是中国的实践模式未来将朝着什么样的方向发展？
鲍捷：
一个大模型驱动的敏捷的需求工程是必然的，FDE 过几年可能换一个名字，但是这个方式是一定会存在的。咨询和交付之间的界限会越来越模糊，能进行结构化需求分解，系统就会出来。国内的 ToB AI 交付,未来几年内我认为不会有啥本质的模式变化，FDE 模式走不通。但是软件工程的模式是会发生很大的变化，越来越多的代码会通过大模型产生。
到2030年，面向国企和政府的交付，根本模式不会发生大的变化，技术不会产生产业格局的变化。但是面向国际市场的，和面向其他服务的，或者是企业本身通过样板客户打造产品的，FDE 是有用的。
总的来说，任何强业务属性的场景，在 FDE 也不能保证能实现产品化。建议重视行业基础设施部分的产品，远离过于业务的场景。一定要充分重视自动化 Ops。自动化调试、自动化运维、自动化错误归因、自动化需求归纳，这些比机械地学 FDE 或者 Ontology 有用。
肖然 ：
正面看国内 Agentic 这波是可以利用来解决SaaS 时代普遍存在的问题的，LLM 和 Agent 的不确定性其实全社会都开始认知了，这点和 SaaS 时代非常不同。这点是给大家创造了去接受不确定性的意见。我认为国家其实是清楚科创行业现在的窘境的，确实也在想办法、出政策。可以预期类似“创新资本”、“探索预算”这些东西会出现。
王新盟：
核心启示还是技术落地需贴近业务一线，不能闭门造车；要把客户服务环节转化为产品迭代的核心动力；AI 价值不在于技术精巧，而在于解决实际业务问题。炫技没用，解决实际业务问题才是真理。
章鹏：
FDE 模式，以及背后以 Palantir 为代表的美国 ToB 科技公司的成功，让我们意识到， 大模型时代的智能体 ToB 交付，从功能交付的人海战术，到价值交付的精英模式。 在供给侧，我们可以借鉴 FDE 模式背后的经验（特种兵、武器、地图），降低我们场景落地的成本，提升行业水位。 在需求侧，目前暂时不好判断。但在需求驱动及务实精神的作用下，我们可以预期会有乐观的改变。
李杨：
FDE 证明 AI 落地不能只靠技术输出，更需要深度融合业务。成功的关键在于组建“业务翻译+技术”的混合能力。因此，公司里面注重这种T型人才的培养是比较重要的，例如管培生机制，不管任何岗位的管培生都需要去不同的部门不同的岗位去轮岗。
曹洪伟：
“重交付”不是原罪，把现场知识抽象成本体，就能享受复用红利。
PMF 不再是静态功能，而是“数据-模型-本体”三维动态契合。
AI时代，卖 License 未必可行，“结果+持续运营”或许才是现金流的保障。
实践方向：
“小模型+大本体”：参数<10 B 的 LoRA 模型下沉到边缘节点，本体在云端统一更新，支持不同大小模型的无缝迁移。
按“节省人工时”“降低不良率”的结果定价，或许可以跟客户对赌 KPI。
观点讨论
@赵俊民：@曹洪伟 这个思考挺好，未来可以尝试的点。国内企业太功利化，不见兔子不撒鹰。
茹炳晟：
我认为 FDE 模式给我的最大启发是：企业最终只会为解决实际问题和可量化的业务成果买单，所以当前 AI 应用应尽快实现”价值回归“，从“炫酷的技术展示”到尽快回到“实际业务价值的交付”。同时 AI 应用不能只是某个企业的“定制化”软件交付。需要形成长期 “经验复用，持续共建” 的可扩展生态模式。
毛舒能：
FDE 模式的爆火也说明了 AI 应用需求的爆火，但同时也恰好说明 AI 模型并不是绝对因素。为客户创造价值取决于如何把业务更好的结构化，并和平台、工程能力高效结合，从而实现落地。另外，由于 AI 应用越来越高度定制化、场景化、以及对快速上线、快速迭代都有很高要求，预计 FDE 这种模式在很长时间会持续存在。
观点讨论
@茹炳晟：我感觉轻量级 Ontology 与高质量数据治理相结合，可能是更能出成绩的做法，如果直接复制 Palantir 重量级本体的做法，效果不见得好。轻量级 Ontology 可以更好的和 Consulting 结合。
@王昊奋：敏捷的 Ontology
@茹炳晟：对对
@鲍捷：轻量级本体可以表达为提示词框架和工作流。
@茹炳晟：@鲍捷 感觉可以在稍微高点的抽象，但又不是Palantir的那种高度。
@鲍捷：Prompt就是本体的一种新形式。Dify就是Rule Language 的新形态。
@茹炳晟：嗯嗯，看抽象层级和颗粒度的把握，当然这也是最具”艺术性“的部分。
黄非：
结合中国实际（强监管、重行业、算力与数据特点），我觉得会沿着这几条路走：
平台化 + 行业化 + FDE 化三线并进：大模型 / AI 中台提供 通用模型、Agent 框架、RAG 能力、数据安全能力；行业线（金融、医疗、制造、政务）沉淀各自 Ontology / 业务组件库；FDE/行业工程师团队长期驻场或深度陪跑，负责“把平台拧进业务流程”。
从“做 PoC”转向“做运营”：未来的主旋律会从一次性的 PoC、试点 变成 持续的 AI 运营：模型监控、数据质量、指标闭环；业务规则/流程不断在线演进；
开发模式：零/低/高代码 + LLM + Agent 全栈协同：业务同学通过 零代码/低代码 搭页面、流程、简单规则；FDE 用 高代码 + 大模型辅助编程 解决复杂逻辑、性能、集成问题；LLM + Agent 做“粘合剂”：理解自然语言需求，然后生成初版流程 / 代码 / SQL；驱动 RAG、调用知识图谱，保证结果“懂行业、不乱编”；自动执行数据清洗、报表、预警等日常任务。
观点讨论
@彭鑫：@黄非 有一点一二十年前软件产品线工程所强调的领域工程和应用工程这样的区分。软件产品线的采用也有Proactive 和 Reactive 两种模式。Proactive 很理想一般很难实现，Reactive 模式更加现实（应用与领域平台交替协同演进）。
@肖然：我认为 PLE 和 FDE 在意图上差异还是非常明显的。PLE 核心是组件化 + 配置 = 可销售产品；FDE 核心是可工作的业务 + 抽象 = 持续演进的产品/平台。这个意图的差异造成整个工程团队组织结构、工程协同，以及可能的工具平台都会产生非常多的差异。
@彭鑫：@肖然 是的，根本上看 PLE 还是为了销售客户满意的产品，而 FDE 是要交付客户满意的结果。
@赵俊民：这种也涉及到企业那个组织去牵头引入 FDE ，谁来跟领导汇报。
@肖然：FDE 并不会适合系统产品公司，比如 Android、鸿蒙，仍然可能 PLE 是更适合的工程体系和方法论；但 FDE很适合咨询和下一代“ SaaS ”公司。
@赵俊民：哪些公司最合适，可能需要持续思考一下。
@鲍捷：2019年我为这个模式提出一个词：Consulting as a Service (CAAS)
@彭鑫：过去的咨询真的就是咨询，现在有了 AI，咨询的结果可能很快能变得落地运行的解决方案。当然，这个过程中客户企业既有的信息化基础也很重要，例如企业已经部署并运行的信息系统可以通过解构再重构为 Agent 提供工具接口。
@肖然：Delta Team 在快速实现过程中是忽略组件化的，甚至也没有必要绑定自己。
@彭鑫：那是，因为他们的重心是快速产出可用的解决方案，而不是为了复用而复用。甚至代码质量这时候也不是太重要，重要的还是解决方案的外在表现。
@肖然：Consulting 是我们认为一定正在被颠覆的，至少我自己觉得已经活不下去了。我是全面拥抱Consulting + Proudct 模式的，过往我们都是不谈 Product的，我们用 Asset 这个词语来表达“沉淀”。
@鲍捷：企业要交付的不仅仅是软件，而是6个东西：软件，硬件，咨询，人力外包，数据，资源。
@肖然：PLE 可能迎来一个新的春天，因为AI4SE，之前PLE落地软件难度系数过高。
@彭鑫：@肖然 是的。就像需求工程和软件设计过去非常概念化，但现在我们感觉在大模型 Agent 时代，这些东西的价值更加明显了。因为它们与大模型 Agent 相结合可以快速产出可用的解决方案，而不是像过去一样停留在抽象的方法学和指导层面上。
@赵俊民：Agent 框架表达能力太强大了，编码已经不是编程的核心。
@肖然：说到工具，我觉得 AI 领域普遍是忽视工程体系建设的，Vibe Coding 给大家一种错觉。我本来很看好 Llama Stack，但大家可能更觉得“无代码”才是未来～
@肖然：跑了很多企业，现实就是大家数据工程体系都没建好，目前 Agent 想上生产，最大挑战是搞定数据
@赵俊民：无代码，低代码和高代码要混合着来
@彭鑫：在软件智能化开发方面，我也一直感觉企业要按照数字化、知识化、智能化这样的台阶逐渐发展，不能指望在开发过程和相关数据（如 Commit 原子化以及与 Issue 的关联等）还一塌糊涂的情况下就指望大模型来了一下子就步入高级阶段。
@彭鑫：这是我们总结的针对 Agent 可靠性的五大工程化原则，其中不少内容都是经典软件工程思想的体现。
@赵俊民：很有价值
@肖然：我们咨询 Style 的框架，大概意思就是不要老是想一颗颗🌲（Agent），忘了支持树木的森灵。
@茹炳晟：FDE 不是把工程师派到客户现场这么简单，而是把‘问题感知’和‘方案孵化’前置到了战场最前沿，同时又不断把在一线的“所见所闻”传递沉淀到本体，为下次低成本打胜仗建立可持续的竞争力。
访谈结束
排版 ｜ 牛嘉阳
审核 ｜ 彭 鑫
CodeWisdom
一个有知识的软工公众号
发现智能化编程之道
