ARTICLE · 1185649
咨询公司、软件公司和FDE团队,谁能真正推动AI落地
当企业AI进入交付深水区，一场围绕业务价值、技术能力与组织方式的竞争正在展开。
过去几年，企业数字化转型形成了一套相对成熟的服务体系。
企业不知道如何转型，可以找咨询公司制定战略；需要建设数字化系统，可以找软件公司开发；系统上线之后，再交给内部IT团队负责维护。
这套模式支撑了ERP、CRM、数据中台和大量企业信息化项目的实施。
但进入AI时代，一个新的问题逐渐浮现：如果企业需要的不是一个固定功能的软件系统，而是一套能够理解业务、调用工具、参与决策并持续优化的AI工作流程，原有的服务模式还适用吗？
例如，一家制造企业希望利用AI减少生产异常处理时间；一家跨境电商企业希望让AI参与广告优化和客户运营；一家连锁企业希望利用AI识别门店经营问题。
这些需求可能同时涉及业务诊断、数据治理、模型能力、系统集成和组织流程调整。
仅有战略方案，无法保证AI真正投入使用；仅有软件系统，也不意味着业务问题得到解决。
于是，一种新的企业AI交付角色开始受到关注：FDE（Forward Deployed Engineer，前沿部署工程师）。
从Palantir到OpenAI，越来越多的AI企业开始强调让工程师深入客户现场，将模型能力与真实业务结合。
但FDE究竟能不能改变企业AI交付？它与传统咨询、软件开发有什么本质区别？未来谁会成为企业AI转型的主要服务力量？
这是本文希望讨论的问题。
一、一个值得警惕的现象：企业正在使用AI，但组织收益没有同步增长
2026年8月，麦肯锡发布最新一期《The State of AI in 2026: On the Road to ROI》。
这项覆盖97个国家、1719名受访者的调查，揭示了一个值得关注的现象：
• 80%的受访者表示，AI提高了他们的个人工作效率。 • 37%的受访者表示，AI对所在企业的息税前利润产生了积极影响。 • 仅约6%的受访者所在组织达到报告定义的AI高绩效标准。
与此同时，越来越多企业开始将AI从试点推向规模化应用，但投入扩大并没有自动转化为相应的企业级财务收益。
这组数据需要谨慎理解。它是基于受访者自我报告的调查结果，并不能直接证明某种技术或服务模式的因果效果。
但它反映了一个重要问题：
个人效率的提升，并不会自动转化为企业整体经营绩效。
假设一家公司的100名员工都开始使用AI工具，文档撰写速度提高了一倍，但原有审批环节没有改变，部门之间依然存在信息孤岛，客户交付周期也没有缩短。
这种情况下，企业确实拥有了更高效率的员工，却未必建立了更高效率的组织。
真正影响企业价值的，是完整业务链条的变化。
从客户需求识别，到数据获取、任务执行、结果审核，再到系统更新和下一轮业务行动，只有当AI参与完整流程并改善最终结果时，其价值才更有可能体现在经营指标中。
这意味着企业AI转型的核心问题，正在从“如何使用AI工具”，转向“如何重新设计企业的工作方式”。
而这也重新定义了企业对外部服务商的需求。
二、咨询公司：擅长定义问题，但战略价值需要被持续验证
传统咨询公司的核心优势，来自对企业经营和组织问题的系统性理解。
面对一家希望推进AI转型的大型制造企业，咨询团队通常会从战略目标出发，分析企业价值链、业务流程、组织结构、数字化成熟度和投资回报，进而确定AI转型路线图。
这种能力非常重要。
因为企业并不缺少值得尝试的AI场景。客服、供应链、采购、生产、营销、财务、人力资源，每个部门都可能提出几十个需求。
真正困难的是判断：
哪些场景值得优先投入？哪些问题需要先完成数据治理？哪些项目能够形成跨部门收益？企业有没有足够的组织能力推动变革？
这些问题通常超出单一工程师或者软件开发团队的职责范围。
大型咨询公司在行业研究、管理层沟通、战略规划和组织变革方面积累的经验，仍然具有很高价值。
以埃森哲为例，其2025年宣布将战略、咨询、技术和运营等能力整合到统一的Reinvention Services业务体系中。这说明大型咨询机构本身也在推动战略与技术交付的深度融合。
咨询公司的局限在哪里？
问题通常出现在战略与执行之间。
假设咨询公司帮助企业识别了30个AI应用场景，建立了优先级矩阵，提出了未来三年的转型规划，并完成了一份高质量的战略报告。
这些成果可能是必要的，但企业仍然面临下一步问题：
谁来连接业务系统？谁来处理不规范的数据？谁负责测试模型在真实场景中的准确性？谁去培训一线员工？如果上线后效果不好，由谁继续修改？
当咨询服务只覆盖前期规划，这些工作便需要交给另一个团队。
于是，战略规划与实际执行之间形成了交接成本。
更复杂的是，企业在实施过程中获得的新信息，可能会推翻最初的判断。
比如，一项被认为很有价值的智能排产需求，可能因为数据质量不足而难以实施；一个最初不起眼的售后知识检索需求，却可能很快产生可验证的效率提升。
因此，AI时代的咨询服务需要建立更短的业务反馈周期，让战略判断能够根据真实实施效果不断调整。
需要强调的是，咨询公司并非天然缺乏技术交付能力。头部咨询机构已经通过技术团队、平台、并购和系统集成服务扩展实施能力。
真正需要区分的是：一家服务商究竟只提供建议，还是愿意持续参与业务结果的实现。
三、软件公司：擅长建设系统，但AI改变了软件项目的交付逻辑
相比咨询公司，软件公司的优势更加直接。
它们能够将业务需求转化为软件产品，拥有架构设计、系统开发、测试部署、安全治理和持续运维能力。
对于涉及ERP、CRM、MES、供应链和复杂业务集成的项目，这些能力不可替代。
尤其当AI应用进入生产环境后，企业需要的不只是模型回答问题，还需要考虑数据库一致性、系统权限、接口可靠性、并发性能、操作审计和故障恢复。
成熟的软件工程体系能够为这些问题提供保障。
但AI时代也带来了新的挑战。
传统软件开发建立在相对确定的需求之上
很多传统软件项目遵循这样的流程：
需求调研、需求规格说明、架构设计、功能开发、测试验收、上线运维。
只要需求相对稳定，就能够按照功能清单推进。
但是AI系统具有一定的概率性和不确定性。
即使提供相同的输入，模型也可能生成不同的输出；新的业务数据可能导致原有提示词失效；模型升级可能改变任务表现；企业业务流程也可能在实施过程中发生变化。
这意味着，AI项目很难完全依靠一次性需求文档完成定义。
比如，一家外贸公司提出建设智能客户开发系统。
传统软件团队可能首先讨论客户管理模块、邮件管理模块、任务模块和报表模块，再设计数据库及前后端功能。
但客户真正关心的可能只有两个问题：
能不能帮助销售找到更符合目标的客户？能不能让销售更高效地完成客户研究和跟进？
如果尚未验证线索质量，就先投入大量资源建设管理后台，很可能造成资源浪费。
AI使“先验证业务价值，再决定产品形态”更加重要
2026年麦肯锡调查还发现，32%的受访者表示，其组织因为可以利用AI编程工具自行开发某些功能，而决定不购买至少一项原本计划采购的软件产品或功能。
这不意味着商业软件会被全面替代，但表明企业在部分场景中拥有了新的选择。
当一些轻量业务功能可以通过AI编程快速实现时，软件公司的竞争优势就需要进一步转向可靠性、系统集成、行业能力和持续服务。
未来，优秀的软件公司仍然会扮演关键角色。
但它们需要在传统软件工程能力之外，增强业务发现、快速验证和模型效果评测能力。
四、FDE团队：为什么AI企业开始把工程师推向客户现场？
理解FDE，需要先理解其组织定位。
FDE通常被译为前沿部署工程师。它并不是一个统一认证的职业标准，而是一种强调客户现场、工程实现和业务结果的技术角色。
Palantir长期采用前沿部署工程师模式。
在其公开招聘介绍中，Palantir将传统产品工程师和Forward Deployed Software Engineer作出一个有意思的区分：
传统产品工程师倾向于围绕一种产品能力服务多个客户，而前沿部署工程师则围绕一个客户的问题，调用多种技术能力解决问题。
这体现了两种不同的组织方向。
产品团队追求产品能力的标准化和规模化，FDE则优先考虑具体客户能否获得实际业务成果。
FDE模式的兴起并不必然意味着咨询或软件服务的消失。
它反映出企业AI交付需要一种能够贯通业务与工程的组织方式。
FDE模式究竟改变了什么？
第一，需求发现更加贴近业务现场。
FDE需要理解业务人员每天如何工作，识别隐含规则和例外情况，而不能只依靠会议纪要和需求文档。
第二，技术验证周期更短。
通过模型API、AI编程、RAG、Workflow、Agent及现成软件平台，团队可以快速构建PoC，让客户通过实际操作验证效果。
第三，交付过程强调持续反馈。
当模型效果不符合预期时，FDE可以直接与业务人员讨论原因，调整数据、工作流程、评测规则和技术实现。
第四，技术成果需要与业务指标关联。
例如，客服自动化项目不仅关注回答准确率，还要关注人工接管率、客户问题解决率和服务成本；销售助手不仅关注线索数量，还要关注有效线索率和真实销售转化。
这也是FDE模式最有价值的部分。
它尝试让业务理解、工程实现与效果验证发生在同一个持续迭代的过程里。
五、三种模式的真正区别：如何组织交付，以及对什么负责？
如果将咨询公司、传统软件公司和FDE团队进行对比，可以得到一个更清晰的框架。
这里的比较描述的是典型组织倾向，而非排他性分类。
优秀咨询公司能够建立强大的技术团队，软件公司可以采用FDE式交付，FDE团队也需要成熟的软件工程能力。
因此，判断一家企业AI服务商时，不能只看其名称和所属行业。
更关键的是三个问题：
谁能够识别真正值得解决的业务问题？谁有能力将方案部署到生产环境？谁愿意持续对业务效果和运行质量负责？
只有这三个问题都能得到回答，项目才具备成功实施的基本条件。
六、用一个外贸企业案例，看三种模式会如何交付
假设有一家年销售额约3亿元的外贸制造企业，主要向欧洲和北美出口工业设备。
企业拥有几十名销售人员，每月收到大量来自官网、展会和邮件渠道的询盘。
目前主要存在三个问题：
客户资料分散，销售需要手工整理；重复性产品咨询较多，占用销售时间；部分询盘没有及时跟进，影响商机转化。
企业希望引入AI，提升销售线索处理和询盘转化效率。
面对这样的需求，三种团队可能会采用不同的方法。
1. 咨询公司的典型路径
咨询团队首先研究企业销售流程，分析获客渠道、客户分级、销售组织和系统现状。
随后提出销售数字化和AI转型方案，包括CRM升级、线索评分、智能客服、邮件自动化及数据治理等项目。
这种方案的优势在于全局性，可以帮助企业明确整体实施顺序，避免不同部门重复建设。
但如果缺乏后续技术实施，企业仍需寻找团队将规划转化为实际系统。
2. 软件公司的典型路径
软件团队可能根据客户需求，设计一套完整的AI销售管理系统。
系统包括线索管理、客户画像、邮件助手、AI知识库、客户跟进和销售报表等模块。
这种方式可以形成稳定的产品与数据结构，有利于后续业务扩展。
但风险在于，如果没有先验证AI线索评分和邮件辅助的实际效果，就开始建设大量功能，项目可能出现开发投入较高、实际使用不足的问题。
3. FDE团队的典型路径
FDE团队可能先派出业务分析与技术人员，与销售主管和一线销售一起梳理工作流程。
通过分析一定数量的脱敏历史询盘、销售记录和客户回复，识别主要问题。
经过业务确认后，先选择一个范围有限的场景：
AI自动整理询盘、生成客户研究摘要，并为销售提供跟进建议。
团队利用模型、业务知识库及现有系统接口快速构建PoC，对历史数据进行回放测试，比较AI辅助与人工处理的表现。
如果数据证明辅助流程有效，再逐步接入CRM、邮件系统和线索分配流程。
整个过程可以不断根据销售人员的反馈调整。
这种模式的优势是降低前期不确定性，更早获得真实使用反馈。
但如果后续需要连接多个生产系统、满足严格安全要求或者支持上百名员工同时使用，FDE团队仍然需要完整的软件工程与运维能力。
4. 最终应该怎样衡量效果？
企业应当在项目开始前就确定指标基线。
例如：
• 首次询盘响应时间是否缩短； • 销售人员每周处理有效线索的数量是否提高； • 有效询盘率、销售跟进率是否改善； • AI处理后的人工修改比例有多高； • 系统运行、模型调用和维护成本是否合理。
仅看生成了多少封邮件、创建了多少条线索，无法判断项目的经营价值。
如果目标是提升订单转化，还需要考虑销售周期、客户质量及市场变化等外部因素，并通过合理的对照方法评估效果。
这个案例也说明，三种服务模式可以解决同一个问题的不同部分。
咨询解决方向与组织问题，软件工程解决可靠系统建设问题，FDE解决业务与技术之间的持续验证问题。
真正成熟的交付方案，需要根据项目规模合理组合这些能力。
七、有些FDE团队，也可能成为另一种外包公司？
FDE的兴起值得关注，但同样需要警惕概念泛化。
一个团队使用Dify、Coze或n8n搭建了几个工作流，并不意味着它已经具备企业级FDE交付能力。
在实际发展过程中，FDE团队可能面临三个问题。
第一，过度依赖个人能力
如果一个项目只能由某位工程师完成，所有业务规则、提示词和系统配置都留在个人电脑里，那么团队很难扩大规模。
这会形成新的“超级外包工程师”模式。
项目可以交付，但无法持续复制。
第二，过度定制，缺乏产品沉淀
为了满足客户需求不断修改工作流、增加接口和特殊规则，短期看起来能够提高客户满意度。
但随着项目增加，技术分支和维护成本也在不断上升。
如果没有行业模板、标准接口、评测框架和基础组件，每一个新客户都需要重新开发。
第三，只负责演示，不负责生产环境
这是尤其需要警惕的问题。
在演示环境中，一个智能体可以表现得非常流畅。但真实企业系统可能存在权限限制、异常数据、并发访问、接口失败及模型错误。
如果团队没有安全治理、权限控制、日志审计、效果评测、回滚机制和运维体系，便难以承担生产环境的交付责任。
因此，FDE模式需要从个人英雄式交付，进一步走向组织化、工程化和可复制的服务体系。
FDE真正需要建立的竞争力，是深入业务现场的能力与成熟工程体系的结合。
这一点，也决定了小型FDE团队能否从单个项目承接，逐步发展为长期服务企业客户的专业组织。
八、未来更有竞争力的模式：咨询能力、工程能力和FDE交付的一体化
当我们重新审视企业AI项目，会发现完整交付链条通常包括六个阶段：
业务诊断 → 场景选择 → PoC验证 → 系统建设 → 业务推广 → 持续运营。
不同服务组织在各个阶段具有不同优势。
咨询能力负责识别企业最值得解决的问题，明确投资目标与组织条件。
软件工程能力负责将模型和业务规则构建为可靠、安全、可持续维护的技术系统。
FDE交付能力负责深入业务现场，以真实用户反馈推动方案迭代，确保技术成果真正进入工作流程。
而客户企业自身，则必须提供业务负责人、数据资源、预算、决策权限和内部推动力量。
因此，我更看好一种融合式交付组织。
它不一定规模很大，但必须拥有明确的能力分工。
对于一个小型企业AI交付团队，可以考虑以下结构：
业务与咨询负责人： 负责客户沟通、需求诊断、业务流程梳理、价值分析和项目商务。
FDE交付负责人： 负责技术方案、PoC实现、模型评测、场景集成和业务验收。
工程与平台负责人： 负责系统架构、安全权限、接口规范、可靠性、生产部署与持续维护。
对于更复杂的项目，还需要行业专家、数据工程师、安全与合规人员参与。
这并不要求每个项目都配置庞大的全职团队。对于中小型服务商，可以由复合型人员承担多个角色，并通过标准组件和外部专家协作开展交付。
重要的是，不能因为组织精简，就省略必要的工程和业务责任。
从项目制，走向产品化交付
长期来看，FDE团队还需要回答一个商业问题：
怎样避免收入增长完全依赖增加交付人员？
一个可行方向，是逐步沉淀行业资产。
例如，连续交付多家外贸企业后，团队可以将共性的客户线索处理、询盘分类、产品知识检索和邮件辅助能力封装为标准组件。
这样，新的项目可以基于已有能力进行配置，团队则把更多时间投入客户的差异化业务问题。
从商业模式看，可以逐步形成：
前期业务诊断与PoC服务、标准产品或解决方案实施、系统集成与定制开发，以及后续运维和持续优化服务。
通过这种方式，团队能够同时获得项目收入、软件收入和持续服务收入。
九、一个更深层的判断：未来企业AI服务竞争的核心，会从交付功能转向交付经营价值
回顾过去二十年的企业信息化，服务市场长期围绕项目建设展开。
企业采购ERP，服务商负责实施ERP；企业建设官网，服务商负责开发网站；企业采购CRM，服务商负责系统集成。
项目的主要验收依据，通常包括功能完成情况、系统性能和合同交付范围。
进入AI时代，情况正在发生变化。
企业当然仍然需要可靠的软件系统，但AI项目的价值越来越依赖具体业务流程中的实际表现。
客户可能不会长期为一个能够生成营销文案的智能体支付高额费用，但可能愿意持续为一套能够提高有效线索处理效率、缩短业务周期并保持可靠运行的系统付费。
这意味着，未来企业AI服务商的竞争将围绕三个问题展开。
一是能否准确识别高价值业务场景。
二是能否以合理成本和可控风险完成生产部署。
三是能否持续证明应用带来的业务改善。
咨询公司需要向执行和效果验证延伸，软件公司需要加强行业和业务价值发现能力，FDE团队则必须建立工程化、产品化和组织化能力。
结语：谁能真正推动企业AI落地？
如果必须给出一个判断，我认为：
未来推动企业AI落地的关键力量，是由企业业务负责人牵引、FDE式团队持续推进，并由成熟工程与治理体系提供保障的交付组织。
真正发生变化的，是企业对服务商的评价方式。
企业越来越需要有人能够理解自己的业务问题，将AI能力引入真实工作流程，建立可衡量的效果，并随着业务变化不断调整系统。
这是一种对结果要求更高、对能力结构要求更复合的交付方式。
关于FDE前线
FDE前线持续关注企业AI转型、FDE人才发展、Agent工程化与真实项目交付，连接企业需求、行业专家和AI应用工程人才。
同时，FDE转型实战训练营持续开放报名，围绕真实企业案例开展业务诊断、方案设计、Agent构建、PoC验证及交付实践。
欢迎关注「FDE前线」，了解企业AI项目合作与FDE实战训练。
主要研究参考
1. McKinsey，The State of AI in 2026: On the Road to ROI，2026年8月25日。 2. McKinsey，AI Is Changing Work. Now It Has to Change the Organization，2026年10月5日。 3. OpenAI，OpenAI Launches the OpenAI Deployment Company，2026年5月11日。 4. Palantir，Careers: Students and Early Talent，FDE与产品工程师的组织职责说明。 5. Accenture，Making Reinvention Real with Gen AI，2025年3月6日。
