夜雨聆风
📢本营圈社区邀您加入！
这里汇聚了资本市场的真实声音，每一位发言者，均通过严格身份认证。他们来自买方、卖方、行业专家、战略投资者、独立研究人。在这里，没有杂音，只有来自市场核心的专业洞察与深度思考。
微信扫码，加入群聊，点击群内任意链接注册，即可免费体验🔽
AI 对软件的威胁，已经从“帮程序员写代码”走向产品形态本身。
当模型可以生成界面、查询数据、编排简单工作流，企业为一套独立软件界面持续购买大量席位的理由会变弱。过去由 SaaS 菜单、表单和报表承载的功能，可能被一个自然语言入口重新组织。开发成本下降，功能复制加快，模型厂商也在向智能体、工具调用和企业工作流延伸。
这带来一个更重要的问题：如果 AI 能替代越来越多传统软件功能，软件公司还剩下哪些可防守、可增值的环节？
答案可能集中在模型难以单独处理的部分。企业数据分散在 ERP、MES、CRM 和内部系统中，同一个“客户”“订单”或“库存”可能存在多套定义。权限还要区分部门、岗位、地区和任务；模型建议进入生产系统之前，需要经过审批、追溯和责任划分。这些环节决定 AI 能否参与真实运营，也决定一次模型调用能不能变成可持续的软件价值。
Palantir 给出了软件分支的一部分正面答案。它没有把竞争重点放在自研基础模型，也没有停留在原有软件界面。公司试图守住数据语义、治理、权限、流程和行动层，再通过 FDE 把这些能力送进客户现场。
软件价值从界面和席位转向运行语境
传统企业软件通常把价值封装在应用里：用户登录特定系统，在固定界面中完成录入、查询和审批，厂商按模块或席位收费。生成式 AI 开始拆解这套结构。用户可以直接描述目标，模型在后台调用多个工具；界面变轻，软件之间的边界也更模糊。
最容易受冲击的，是通用功能、重复界面和简单工作流。模型生成代码的能力继续提升后，客户自建小型应用的门槛也会下降。软件厂商若只提供一组可被快速复制的页面和功能，差异化会逐渐收窄。
更难替代的部分藏在企业运行结构里。模型需要知道数据代表什么、哪些关系成立、谁有权修改、什么动作可以执行、结果如何回写。这里同时涉及数据层、语义层、治理层和流程层。它们往往经过多年组织磨合，无法靠一次提示词完整重建。
软件的价值因此可能发生迁移：从界面和席位收费，转向数据语义、流程编排、组织权限和持续运营。模型成为新的交互入口，软件则负责提供可信上下文和执行边界。
Palantir 的产品结构正好落在这条迁移路径上。Foundry 连接和治理数据，AIP 接入模型与智能体，Apollo 管理软件部署，Ontology 则把数据、逻辑、行动和安全策略组织成企业可以使用的运行语境。模型可以更换，业务对象、权限关系和工作流却需要长期建设。
Ontology是软件抗替代的核心层
Ontology 经常被理解成知识图谱或数据目录，这个解释还不够。Palantir 官方架构文件将其描述为企业的数据、逻辑、行动和安全策略的统一表示，人和 AI 都可以在这层结构上工作。
此前的 《Palantir的神秘药方：Ontology》（加入本营圈免费查看） 介绍过它的基础机制。以供应链为例，工厂、产线、订单、库存和客户会从不同系统中的字段，转为带有关系、权限和动作的业务对象。模型看到的不再是一堆表格，而是一套可以理解和操作的企业语境。
这层结构解决了企业 AI 的几个核心问题。
第一，统一语义。同一个业务概念在多个系统里可能有不同名称和口径，Ontology 负责把它们映射到可共享的对象和关系。
第二，保留权限。模型只能访问被授权的数据和工具，敏感操作可以继续受角色、审批和策略约束。
第三，连接行动。模型输出可以进入排产、采购、风控或客户服务流程，并通过函数、应用和工作流触发后续动作。
第四，形成反馈。执行结果回到系统中，企业能够观察模型建议是否有效，再调整规则、数据和流程。
这些能力说明，AI 对软件的替代并非简单的“一层吃掉一层”。通用模型会压缩部分应用功能和开发成本，同时提高数据治理与运行语境的重要性。谁能掌握这层上下文，谁就更有机会成为模型进入企业的控制层。
Palantir 在这里提供了正面样本，但结论仍需收窄。Ontology 是公司官方产品架构，客户是否形成高切换成本、能否持续扩大部署，仍要通过合同扩张、生产用例和客户留存验证。大型云厂商、数据平台和客户自建体系也在建设相似能力，Palantir 没有独占这条路径。
FDE把模型、数据和业务动作接起来
仅有 Ontology 仍不足以完成企业改造。数据定义、权限关系和流程责任往往分散在不同部门，客户很难一次性写出完整需求。模型厂商理解推理和工具调用，业务团队理解现场问题，中间需要一套部署机制把两端接起来。
FDE 承担了这个角色。它的全称是 Forward Deployed Engineer，通常译作前沿部署工程师。这个岗位兼具产品、工程和现场交付职能。Palantir 官方把 Forward Deployed Engineering 描述为平台持续开发的方法：工程团队尽可能靠近客户问题，与核心研发协作，把现场反馈快速转成新功能。
因此，FDE 的核心价值来自连接能力。工程师需要识别客户实际使用的业务对象，梳理数据源和权限，把模型放进具体流程，再验证输出能否产生可执行动作。交付过程同时也是产品研发过程，现场发现的共性问题可以回到核心平台。
我们此前在《Palantir未被Price-In的能力：服务》（加入本营圈免费查看）中讨论过它的服务能力。进入生成式 AI 阶段后，FDE 的任务进一步扩大：它要在模型、数据语义、流程规则和组织责任之间建立接口。传统咨询往往交付方案或定制系统，Palantir 希望把现场经验沉淀为 Ontology、平台工具和行业模板。
Bootcamp 是这套机制的前端入口。客户围绕一个具体问题，在较短时间内搭出可运行原型，再判断是否进入生产。FDE 则推动原型穿过数据清理、权限设置、系统集成和流程调整。这个过程解释了为什么企业 AI 的落地速度并不只由模型能力决定。
Palantir 也在尝试把 FDE 本身软件化。官方 AI FDE 可以通过自然语言执行数据转换、代码仓库管理和 Ontology 编辑，并在权限控制下形成“执行—观察—验证”的闭环。若重复部署工作逐步交给 AI FDE，人的精力可以转向业务设计、责任划分和复杂决策，现场经验也更容易变成可复用产品。
这条路径决定 FDE 究竟是咨询包装，还是软件产品化的一部分。观察重点在于：每增加一批客户，公司需要增加多少部署人力；每次交付留下多少通用能力；AI FDE 和行业模板能否缩短下一次部署。
正面样本仍要接受规模化验证
Palantir 的 Q2 2026 数据可以作为业务扩张背景。公司当季收入同比增长 93%，美国商业收入同比增长 149%；GAAP 经营利润率为 47%，调整后经营利润率为 62%。至少在合并报表层面，尚未表现出传统咨询式的人力拖累。
这些数字无法单独证明 Ontology 或 FDE 的因果贡献。美国政府需求、AI 投资热潮、大额合同节奏和费用控制都会影响结果。公司也没有公开 FDE 人数、部署人力成本、Bootcamp 转生产率或 AI FDE 的效率贡献。
所以，Palantir 给出的仍是一条可观察路径，而非“软件不会被 AI 替代”的证明。软件价值可能从通用界面和席位迁移到四个更深的环节：数据语义、治理权限、流程编排和组织改造。Palantir 已经把这些环节组合成产品与交付体系，能否持续获得软件式规模效应，还要看产品沉淀速度。
后续可以跟踪四组指标：
1. 从 Bootcamp、试点到生产的周期是否缩短，生产部署和多工作流扩张是否增加；2. 客户扩张能否快于交付人力增长，人均收入、人均自由现金流和整体利润率能否保持；3. AI FDE、平台工具、行业模板与合作伙伴能否承接更多重复部署工作；4. 美国市场之外的数据主权、采购制度和本地合作伙伴问题能否解决。
风险也很清楚。客户可能用云厂商、数据平台和开源组件搭建自己的控制层；高触达交付可能积累过多定制分支；优秀 FDE 的培养速度可能跟不上客户增长；美国市场形成的产品与组织模式，也未必能顺利复制到欧洲和其他地区。
AI 会继续替代一部分软件功能，也会重写软件的定价方式。Palantir 的意义在于，它展示了软件公司可以向数据语义、治理、流程和组织层迁移，再用 FDE 把模型能力变成生产动作。
这条路径已经出现正面信号，规模化结论仍需等待。若现场复杂性持续沉淀为 Ontology、工具和模板，Palantir 会更接近 AI 时代的企业运行层；若增长依赖同步增加高端工程师，它的边界仍会落在高触达技术服务上。
整理自公开信息，不作为任何投资建议
