TL;DR
- 企业 AI 落地的现状：大量组织还停留在工具采用阶段，离真正改造业务很远。
- FDE 为什么重新被讨论：它说明 AI 产品还不能稳定进入企业工作流，只能靠人补最后一段路。
- 组织惯性是 AI 落地的最大阻力：AI 改变的不只是岗位效率，还会冲击分工方式和激励方式。
- 机会在哪里：企业需要从外部交付走向内部 AI 能力建设。
企业 AI 落地仍停留在工具层
过去两年陆续（几乎每个月都有一些问询）接触了一些企业培训需求，也和做企业培训的朋友聊过，感受很一致：绝大多数组织推进 AI 变革，仍然停留在采用 AI 工具上，远远没有走到借助 AI 改造组织的阶段。
2025 年，很多培训还在教员工怎么使用几个 AI 工具，怎么写提示词，到了 2026 年，内容看起来升级了一些，可能开始教大家安装 OpenClaw 这类工具，或者从写 prompt 变成写 Skill，但真正接入业务流程、改变协作方式、重构岗位分工的案例，仍然很少。
靠 Skill 承载企业 know-how 这件事，我现在越来越谨慎。Skill 能处理一些固定流程，比如按模板整理资料、生成固定格式内容、跑一段稳定的自动化任务。但业务是变化的，很多判断来自现场经验、客户关系、历史约定和临时调整，把这些东西全部塞进 Skill 里，很容易变成一开始能用，后面没人维护，最后越跑越偏的一堆垃圾，至于指望用 Skill 自进化来解决，现阶段完全就是管活不管埋，糙点很多。
这也是现在企业 AI 落地最常见的矛盾，员工学会了用 AI 写周报、做 PPT、整理资料，管理层也可以说自己已经采用 AI，但企业的核心流程、决策方式和业务结构并没有真正被改造。
这个判断也能从报告里看到影子。斯坦福的 人工智能指数报告 显示，全球 88% 的组织已经在至少一项业务中采用 AI，麦肯锡的 全球 AI 调查 也提到，AI 采纳率继续上升，但真正把 AI 深度嵌入核心业务并形成系统性价值的公司不到 1%。
所以我对现在很多所谓 AI 变革的判断是，它更像工具采用，还没有进入组织改造。
FDE 在国内为什么难做
FDE（Forward Deployed Engineer，前沿部署工程师）这个概念上半年在国内被讨论得很多，主要是一些关注海外 SaaS 和 AI 创业公司的自媒体带起来的。
在硅谷语境里，FDE 有点新鲜。因为很多 SaaS 公司过去相信 PLG，也就是产品驱动增长，理想状态是一套标准化产品卖给大量客户。一个需要深入客户现场、理解业务流程、现场做适配的工程师角色，对他们来说比较特别。
放到国内，这件事其实一点都不新。做过 ToB 的人都知道，类似角色早就存在。它可以叫驻场工程师，可以叫解决方案架构师，可以叫交付型产品经理，也可以叫偏售前的技术顾问。真正干过的人都知道，这类角色很辛苦：前面有甲方，后面有产品和研发团队，中间的人要同时承受客户需求、交付压力和内部资源限制。
具体到 AI 落地，FDE 的要求更高。他要懂一点模型能力，懂技术架构，懂业务现场，还要能管理客户预期。国内的问题在于，愿意为这类定制化交付支付足够高费用的企业有限。很多客户认可驻场人力，却不一定认可软件服务和效率提升本身的价值，其次只做交付，不做抽象，最后会一直困在项目里。结果就是，FDE 很容易变成高强度、低毛利、难规模化的交付岗位。即便 Palantir 来了，也未必能跑得很顺。
海外 FDE 流行，反而说明 AI 产品还不够成熟
我觉得 FDE 被重新提起，恰好说明现阶段 LLM 在 ToB 场景里的产品能力还不够稳。很多业务 know-how 没有被 AI 学会，因为这些知识本来就没有被很好地整理过。它们散落在人的经验里、历史文档里、聊天记录里、临时会议里，企业自己也很少把这些东西系统化。
技术历史上出现过类似情况。SAP 最红火的时候，大约 2005 年前后，也有大量工程师进入企业现场。他们观察客户的业务流程，再把 ERP 系统配置成适合这家企业的状态。后来的变化是，工作流逐渐标准化了。软件在适配企业，企业也在适配软件。两边互相推动，才有了后来更轻、更标准化的 SaaS。
如果把 SAP 这类 ERP 看成一种通用大软件，那么 SaaS 就是在更细分、更标准的业务环节里完成产品化。因为流程足够小，边界足够清楚，交付也就可以变轻。
现在很多 AI 创业公司做的产品，比传统 SaaS 还要垂直。有些只服务某个行业里的一个小环节，甚至只解决一个岗位里的几个任务。按理说，场景越窄，产品越容易标准化。但现实恰恰相反，很多产品仍然需要 FDE 深度进入客户现场，把模型、工具、数据、权限、流程和人工复核全部串起来。
这说明模型能力、产品能力和真实工业需求之间还有很长一段距离。AI 公司现在招 FDE，是在用人力填补产品和业务之间的空隙。
这也是我对 Agent 在企业落地上保持谨慎的原因。企业真实场景里，数据常常分散在多个系统里，流程会频繁变化，权限和责任边界也很复杂。Agent 不能只在演示环境里跑通，它要在真实业务里稳定运行，还要能被监控、评估、回滚和追责。现在离这一步还有距离。
组织惯性比工具学习更难改变
很多人聊 AI，重点放在个人要不要学习新工具，但我更关心组织怎么变化。个人适应很难，组织转型更难。传统组织能长期运转，依赖两个前提。第一，事务可以被充分切分，第二，大多数岗位只需要对流程节点负责，组织对结果兜底。
AI 改变的正是这个前提，中间层这些工作可以被 AI 以更低成本、更高稳定性完成时，很多岗位的价值就会被重新评估。AI 对组织的影响，在产品团队里已经显现出来。
过去一个产品从想法到上线，通常依赖清晰分工：产品经理负责需求和方案，设计师负责交互和视觉，开发负责实现，测试负责质量，运营负责上线后的反馈。每个角色都有自己的边界，也有对应的交付物。产品经理交 PRD，设计师交稿，开发交代码，测试交报告。只要每个人完成自己的节点，组织就认为这套流程是正常运转的。
AI 写代码能力提升后，变化不会停留在开发效率提升上。产品经理可以用 AI 快速做原型，甚至写出可运行的 Demo；设计师可以直接生成交互动效和前端页面；开发也可以借助 AI 更快理解业务、补齐方案细节，甚至参与产品判断。角色边界会被不断打薄，过去需要多人交接的中间环节，会被一个更综合的人直接串起来。
所以这里真正发生的变化，并非产品、设计、开发之间谁取代谁，而是角色开始融合。未来更有价值的人，可能不再只对一个流程节点负责，而是能从用户问题出发，完成方案设计、原型验证、技术实现和数据反馈，并对最终结果负责。
这会冲击过去的分工方式。原来组织按岗位管理人，按流程拆任务，按节点验收交付物。AI 加速之后，一个人可以跨过很多原本必须交接的环节，直接做出更接近结果的东西。此时继续用旧方式管理，只会出现新的矛盾：真正能把事情做成的人承担了更多责任，却仍然被放在原来的岗位框里评价。
组织的激励方式也必须跟着变化。不能一边要求产品懂技术、设计懂实现、开发懂业务，一边还只按岗位边界、职级汇报和流程产物来评价他们。否则，那些真正完成角色融合、能对结果负责的人，会很快感到不公平。他们承担了更复杂的工作，却没有获得对应的授权、收益和成长空间，最后大概率会离开，去更能识别这种能力的团队。
问题就是机会
过去一年，我每天都在用 AI 做一些小工具，为自己、为同事、也为朋友，这件事对我来说很有趣，像玩游戏一样，让人愿意持续投入，当我用这套 AI 快速做工具的思路去和不同行业的人交流时，发现 AI 能改变的东西比我原来想的多得多，几乎每个行业都有重构一遍的机会，任何看似固定的业务形态，都可以被 AI 拆开重组，只是投入程度不同。
我之前写过的 AI 在短视频与直播行业的 8 大场景, 从短视频的批量内容生产到直播的实时互动优化，从数字人替代真人出镜到私域销售的智能质检，AI 可以渗透进内容行业的每个关键环节。营销 Agent 产品怎么做 那篇里
前往博客阅读余下内容 2026 年，AI 智能体如何在企业落地？