SaaS 为何在中国失灵？从 Palantir 看 AI 时代的「能力即服务」路径

【摘要】中国SaaS步伐失衡,Palantir式能力服务正在重写企业软件范式

引言

过去十多年，SaaS 这个词在中国科技圈热度很高，真实落地却很冷。投资人热衷讨论估值倍数和订阅模型，创始人忙着在路演材料里描绘复利收入曲线，企业管理者却在算另一笔账，招两个人是不是比买一套系统更划算。理想与现实的剪刀差，在几轮周期之后看得更清楚。

在美国，SaaS 常被放在管理进化的语境里讨论，关键点是通过标准化流程和云交付来压缩管理成本。中国企业环境很不一样，业务变化快，人力便宜又灵活，流程更多依赖人来兜底。美国 SaaS 在和管理成本竞争，中国 SaaS 在和人力成本竞争，结论自然完全不同。

AI 的到来，把这件事进一步推到了分叉口。大模型不只是把工具做得更智能，而是让工具第一次有机会变成一套可学习的能力。这个变化看上去是技术升级，实质是商业模式和组织形态的变化。Palantir 正好站在这个交界处，它表面上是软件公司，内核却是极度“反 SaaS 教条”的能力服务商，对中国的 AI to B 创业者和甲方企业都有参考价值。

下面从三个角度展开。先还原中国 SaaS 的真实轨迹，再拆解 SaaS 与中国企业环境之间的结构性冲突，最后用 Palantir 的路径来讨论 AI 时代更合适的企业服务形态，也就是所谓的“能力即服务”。

● 一、中国 SaaS 的十年轨迹与结构性错位

1.1 初期阶段 经验移植与现实落空

早期大约在 2012 年前后，国内讨论 SaaS 时，Salesforce 几乎是所有 BP 里的第一张 logo。很多团队直接照着 CRM、OA、ERP 这些品类来做云化版本，假设中国企业也会像美国企业一样，用一套标准化流程跑销售、审批和财务。想象是顺滑的，问题在于这套想象忽略了几个关键前提。

大量中国企业的 IT 基础很薄，信息化程度参差不齐，很多管理动作仍依赖 Excel 和即时通讯工具完成。组织文化上也更偏向人治，流程往往挂在具体负责人身上，而不是写在制度或系统里。SaaS 预设了“流程已经被抽象出来”，但中国企业连流程的共识都还没形成，更不用说交给一个标准产品来承载。

在这种环境里，企业对软件的期待很务实，更像对待一个听话的外包团队，而不是一套要跟随多年、推动管理升级的系统。很多老板不会为了用上 SaaS 去重构流程，只希望先把眼前的问题解决，把报表做出来，把审批跑起来。

1.2 中期阶段 资本热潮与幻觉繁荣

2016 到 2020 年这段时间，是 SaaS 概念在资本侧的高光期。订阅模式的收入可预测性、经常性收入带来的估值溢价，被反复强调。各类报告会给出非常乐观的渗透率预测和市场规模预期，似乎只要坚持产品化路线，总会等到云化拐点到来。

现实是，融资节奏经常跑在产品和组织前面。很多公司在产品尚未跑通单一行业的情况下，就开始铺设多行业销售团队，试图用规模扩张摊薄获客成本。项目签下来之后才发现，落地需要大量实施顾问、需求分析和定制开发，人均产出远低于预想。订阅收入看上去是 SaaS，交付形态却越来越像传统软件加项目。

不少公司最后形成一种畸形结构。外面是一层 SaaS 包装，里面是典型的项目制组织，售前靠 PPT 讲统一平台，售后靠人手一点点帮客户改流程、改表单。账面上的 ARR 增长不错，但续费率和项目毛利率一直压着经营底线。

1.3 后期阶段 泡沫退潮与伪 SaaS 泛滥

疫情之后，宏观环境收紧，资本趋于谨慎，很多 SaaS 公司开始直面几个残酷事实。客户第一年可以在预算相对宽松时尝试订阅，第二年如果看不到直接的业务提升，就很难说服财务和业务线继续续费。管理流程和组织习惯如果没有发生实质变化，系统就只会成为“偶尔上去查个数据”的工具站点。

另一方面，人力市场在很多行业仍然供大于求。对于不少中小企业来说，多招几个人，哪怕流动率高一些，也比推动一轮覆盖全公司的流程改造来得现实。当 SaaS 无法同时带来明显的增收和降本，企业会优先选择对管理阻力最小的方案，也就是继续依赖人去兜底。

结果就是大量“伪 SaaS”公司出现。对外宣称是云平台和订阅服务，对内收入却高度依赖一次性项目和深度定制，续费只是顺带的附加项。越是强调标准化平台，落地团队越是被迫大量做定制，实际经营风险从技术变成了人力密集度。

为了更直观看这条轨迹，可以用一张简单的阶段对比表。

这三阶段串起来，核心是同一个问题，也就是标准化 SaaS 假设的那几块地基，在中国企业环境里从来就不稳固。

● 二、结构性冲突 SaaS 模式与中国企业环境

2.1 流程不稳定与工具刚性的对撞

经典 SaaS 模式有一个隐含前提。企业已经有相对稳定的流程和角色分工，软件要做的是把这些共性抽象为配置和界面。流程可以微调，但不会每隔几个月就重构一次业务逻辑。大部分欧美企业在成熟行业里大致符合这一点，重组和战略调整不会高频发生。

中国企业的环境明显不同。很多公司处在快速试错状态，跟着市场节奏不断调整业务线和产品结构。老板换一个思路，组织架构马上跟着动，审批链、指标体系、激励逻辑一起变化。流程变化的频率往往比软件迭代还快，这直接击穿了“先固化流程再软件化”的路径。

SaaS 产品为了保持通用性，需要在功能边界上有所控制，不能因为一个客户的特殊诉求就改动底层数据模型。中国企业采购时很少接受这一点，现场谈判经常演变成对标准流程的拆分，最后不得不走大量定制。工具的刚性与流程的流动性，在合同签署之前往往被掩盖，在实施阶段才集中爆发。

2.2 人力成本和灵活度带来的比较挤压

从经济学视角看，SaaS 本质是在用更低的社会平均成本，提供一套软件能力。美国等成熟市场里，管理岗位和中后台岗位的人力成本高，人员流动又带来隐形管理成本，所以企业更愿意通过 SaaS 来锁定一套稳定的能力。

中国不少行业的人力仍然相对便宜，而且雇佣关系在体制外企业中相对灵活。对于一个中小企业老板而言，请一位兼任数据分析、运营执行和客户管理的通才员工，每个月的现金支出虽然肉疼，但好处在于随时可以调整岗位职责，还可以顺带处理一些“无法系统化”的零碎工作。一个万能打工人天然具备高弹性，而标准化 SaaS 很难匹配这种弹性。

在这种对比之下，SaaS 要么提供远超单个人的价值，要么彻底改造一条关键业务链，否则在财务决策上就很容易被划到“可有可无”的支出栏里。很多产品在功能上只能覆盖到日常工作的一部分，却收取整年的订阅费，这种性价比很难经得起简单的算账。

2.3 KPI 周期与长期价值链的错位

SaaS 的真正价值需要时间积累。流程被标准化，数据被持续沉淀，管理者在多年历史数据的基础上调整策略，才会出现明显的效率复利。欧美市场里不少企业会为这种长期价值预留空间，IT 预算可以为三到五年的收益埋单。

中国很多企业的经营现实决定了另一个节奏。KPI 周期往往是季度甚至月度，现金流压力高时，很多决策会回到短期收益的优先级。IT 项目如果半年内看不到明显的营收贡献或者直接降本幅度，就很难在预算会上得到支持。SaaS 所承诺的“长期流程优化和数据资产价值”，在短周期考核体系里几乎没有议价空间。

与此同时，中层和基层员工在使用系统时，也很难从个人角度感受到长期好处。他们更多看到的是额外的填报工作和对当下习惯的打断。组织没有明确的激励去推动使用，系统就会自然滑向“只在检查和审计时才打开一下”的状态，长期价值链在起点就断掉了。

2.4 差异化诉求与定制陷阱

SaaS 平台要挣钱，必须在共性上做文章。一次开发尽量服务更多客户，通过规模摊薄研发和运维成本。共性的边界如果划不清，就会陷入无止境的定制中，团队很难做出真正稳定的产品内核。

国内大量项目的实际情况恰恰相反。客户往往从第一个版本就开始提出差异化诉求，字段需要多加几类，流程节点要多个分支，审批链希望按组织结构和项目类型多层嵌套。很多需求在局部看有道理，一旦全部接受，产品就会变得高度碎片化，数据库里充满只为单一客户存在的字段和表。

这类定制需求叠加起来，直接拖垮了 SaaS 的规模效应。公司内部不得不维护多套几乎不兼容的配置，版本升级需要逐个客户排查可能的冲突。表面上仍然是 SaaS 收费方式，真实经营却是传统项目外包逻辑，风险集中在人员上，估值故事和现金流结构完全脱节。

● 三、Palantir 的反 SaaS 教条路径

3.1 深度嵌入而不是标准产品

Palantir 在很多方面都长得不太像传统意义上的 SaaS 公司。它没有追求一套“一次构建，服务全球”的通用界面，而是从一开始就接受客户业务的独特性和复杂性。项目启动阶段，Palantir 通常会派出一支跨职能团队进入客户现场，和业务、IT、安全等多组一起梳理数据资产和决策链条。

这种做法在传统 SaaS 视角下显得不够“产品化”，因为每个大客户项目都高度定制，也很难快速复制。但在流程高度差异、业务逻辑复杂的场景中，先深度嵌入，再逐步抽象共性，是更现实的路径。Palantir 借助 Foundry 等平台，把通用的数据建模和管控能力封装在底层，把具体场景的流程和界面留在上层，通过配置和少量代码绑定在一起。

换句话说，它没有坚持把所有客户都拉进同一个形状的系统，而是允许系统在每个客户现场长出不同形状的“枝干”，然后在更底层共享“树干”和“根系”。这套思路在面对中国企业那种高变动性流程时，反而更接近真实需求。

3.2 增强组织 而非替代岗位

中国很多 SaaS 产品在销售环节喜欢强调“可以节省多少人”，用人力替代来量化价值。短期看这种说法容易算账，长期看却把自己放进了一个不利的比较维度。人力便宜时，节省两个岗位带来的价值很有限，系统的复杂度还要额外培训和维护。

Palantir 更常用的说法接近“让组织更聪明”。它做的不是把某个分析师的工作完全自动化，而是帮助组织构建一条更坚实的情报和决策链路。数据不再散落在各个系统和部门里，而是被整合、标注和建模，形成可查询、可模拟、可推演的知识图景。提升的是组织整体的感知能力、判断能力和执行协调能力，而不是削减几个岗位。

这种定位的好处在于，价值评估不会简单落在“对标几个人的工资”上，而是转向“关键任务的风险下降多少、响应时间压缩多少、损失减少多少”。在安全、国防、供应链、能源等领域，这类指标的重要性远高于单个岗位的节省。

3.3 按结果共担而不是卖账号

收费模式是商业逻辑的外化。传统 SaaS 习惯按用户数和功能模块收费，方便预测收入，也便于和基础设施成本绑定。但对客户来说，这种模式往往和业务价值的关系很弱，买了多少账号不等于产出多少结果。

Palantir 采取的是更接近“价值同盟”的模式。它会把自己的收费结构和客户的核心业务结果挂钩，比如安全事件的发生频率、关键系统的可用性、供应链中断时间、库存周转效率等。售卖的不是访问权，而是持续改善关键指标的能力，项目谈判从一开始就围绕这些指标来设定目标和边界。

在这种模式下，续费不再是“要不要继续用这套系统”的选择，而更像是“要不要让这套能力继续服务我们的关键任务”。软件平台是隐形的，前台显性的是一个“和我们一起对结果负责的外部团队”。

3.4 从重咨询到平台抽象的渐进路线

Palantir 也不是一开始就拥有一个高度抽象的平台。它早期的模式更像重咨询加定制开发，直面最难啃的大客户和安全、政府等超复杂场景。项目里那些一再重复的能力，逐步被抽象成模块，然后封装进更通用的平台组件中，供后续项目复用。

这条路线对国内很多 AI to B 团队有启发。在流程高度碎片化的环境里，试图一上来就做一个大而全的平台，往往会陷入无尽的边界拉扯。更可行的办法是，选择一两个对结果极度敏感的任务链路，用重团队打穿，用工程实践发现哪些能力值得平台化，哪些必须保留定制空间。

可以用一个简单的结构图来理解 Palantir 的交付方式。

图里每一步都带有人力服务和平台能力的组合。深度驻场带来对业务的理解，平台则负责把这些经验固化为可以迁移的模块。

● 四、Palantir 的技术与能力栈 服务化的数字中枢

4.1 数据整合与语义建模

从技术视角看，Palantir 的核心优势不在单点算法，而在整体的数据和语义层设计。它需要面对的是跨系统、跨组织、跨安全域的数据碎片，这些数据格式多样、质量不一、安全要求复杂。简单的数据仓库或传统 ETL 管道，很难支撑这种复杂环境里的灵活分析需求。

Palantir 在这层做了两件关键的事。第一是构建统一的数据接入和治理框架，把分散的数据源接入到同一控制平面，处理权限、脱敏和合规问题。第二是在数据之上建立语义模型，把业务实体和关系明确下来。这让上层应用不再直接操作底层表结构，而是围绕“事件”“资产”“人员”“任务”等概念进行组合，支持快速构建新的视图和工作流。

对中国企业来说，这一层的意义在于，可以在不推倒重建现有系统的前提下，把分散在 ERP、MES、CRM、OA、定制系统里的数据重新拼成一张业务地图。AI 能力要发挥作用，离不开这块语义底座。

4.2 决策支持与行动编排

在语义层之上，Palantir 构建的是一套决策支持和行动编排框架。它会把规则、数据分析结果和人的判断结合起来，形成多层级的工作流。例如在供应链场景里，可能既有对风险信号的自动检测，也有对应急计划的自动生成，还需要把这些建议推送给合适的责任人，并追踪执行结果。

这一层既包含传统的规则引擎和流程引擎，也逐步引入更多机器学习和大模型能力。重要的是，它允许不同复杂度的自动化共存。不是所有决策都要交给机器，但机器可以在绝大多数情况下给出合理建议，把人的注意力集中到风险更高的少数场景。执行链条也不只停留在通知和报表层面，而是尽可能对接业务系统，形成可执行的动作。

对 AI to B 创业者来说，这里对应的就是“从模型到工作流”的转化能力。模型本身的效果很重要，如何把模型输出变成可以插入现有业务链路的行动，同样关键。

4.3 工程团队与平台协同交付

Palantir 项目常被误解为“外包团队进场做集成”，但从交付结构看，它更像是工程团队与平台能力的紧密配合。项目初期，工程师会和客户一起定义关键指标、流程节点和数据需求，把这些转化为在平台上的配置和扩展代码。项目中后期，平台团队会不断抽象通用能力，减少对单点定制的依赖。

这种模式对人力要求高，对工程文化要求也高。团队既要懂技术，又要听得懂业务语言，还要能承受长期驻场带来的节奏压力。回报在于，平台与人的组合能在复杂场景里提供持续的能力升级，而不是交付一次性项目后就撤离。

对于想在中国做深 AI to B 的团队，这套模式说明一件事。只靠远程交付一个通用系统，很难深度介入关键任务链路。要做到真正的“能力即服务”，就必须接受工程与服务深度绑定，再在这个基础上，通过平台慢慢拉高“每个工程师能带来的能力产出”。

● 五、AI 时代的范式迁移 从卖工具到卖结果

5.1 工具逻辑与能力逻辑的切换

SaaS 的思路是把规则和流程固化为工具。这套逻辑在流程稳定、人力昂贵的环境里成立，在高变动和人力弹性大的地方则问题重重。AI 带来的变化在于，大模型可以学习和适应变化的模式，不需要预先把所有规则写死在代码和配置里。

在工具逻辑下，产品团队的任务是设计好界面和流程，让用户按照设定的路径完成工作。这种模式对用户的要求高，需要他们愿意学习新系统，并在其中输入高质量数据。能力逻辑下，系统应该主动去理解现有数据和行为模式，尽量减少对用户习惯的强制改造，把更多复杂度收进自身。

从交易对象的角度看，工具逻辑卖的是使用权，买了就可以用，至于效果如何，厂商与客户之间的责任边界相对清晰。能力逻辑卖的是持续输出的业务能力，双方必须围绕结果建立更深的协作关系，这对产品、服务和商业模式都是一次重新设计。

5.2 以任务链为单位的产品设计

AI to B 产品如果继续以“系统类型”来命名，比如“智能 CRM”“智能 OA”，很容易被拖回老路。更有效的切入方法是以任务链来定义产品边界，比如“从异常发现到根因分析再到纠正计划执行”的完整链路，或者“从线索捕获到销售机会评估再到跟进策略推荐”的闭环。

把产品当成一条可以被 AI 部分或整体接管的任务链，而不是一块功能区域，设计决策会发生明显变化。团队会更关注每个环节当前依赖谁、用什么工具、用什么数据，以及这些环节之间的信息如何流动。AI 模型可以插入的点更清晰，评价效果的指标也更具体。

这种任务链思路，非常适合中国企业当前的状态。流程不必一开始就完全标准化，只要先把关键任务链路跑顺，允许周边有弹性和人工介入。随着数据和经验积累，再逐步抽象更稳定的能力模块。

5.3 嵌入式 AI 能力的系统形态

AI 能力落地时，如果要求客户抛弃原有系统，迁移到一个全新的平台，实施成本和组织摩擦都会过高。更实际的方式是，把 AI 做成嵌入式能力，像插件一样插入现有系统和工具中，在用户熟悉的界面里提供增强。

具体可以有几种形态。第一是嵌入现有业务系统的智能面板，例如在订单系统中自动标记高风险订单并给出解释，在客服系统中自动总结用户情绪和典型问题。第二是横向的“中枢服务”，在后台监听多个系统的事件，通过规则和模型组合生成提醒和任务分配。第三是面向管理者的分析和模拟环境，帮助他们在不干扰实际业务的前提下测试不同策略。

嵌入式形态有一个好处，就是不要求企业在短时间内完成信息化重构。AI 能力可以沿着现有系统的缝隙爬进去，先解决几个高价值的小问题，再逐步拓展影响范围。对厂商来说，这也降低了项目启动门槛，更容易找到可以快速验证价值的切入口。

● 六、AI to B 企业的目标形态 能力服务厂商

6.1 能力服务的三层结构

如果把未来的 AI to B 企业看作“能力服务厂商”，可以大致拆出三层结构。最底层是通用的技术与平台能力，包括模型能力、数据处理框架、权限与审计机制。中间层是行业和领域能力，把通用技术与特定行业的知识和流程结合。最上层是具体的任务链解决方案，为特定客户提供定制程度适中的能力组合。

可以用一张简单的结构表来概述这三层。

真正的护城河往往出现在中层和上层。只做底层平台很难一家独大，只做任务链方案又容易变成纯项目制。通过几个重点行业把中层打牢，再在这些行业中跑出一批可验证的任务链方案，是比较稳妥的路径。

6.2 收费模型与价值同盟

收费模型如果仍然停留在按 license 或按调用量计费，很容易被客户视为基础设施开支，而不是业务能力投入。能力服务的收费逻辑更适合拆成两部分，一部分是能力建设费，覆盖前期的联合建模、数据打通和工作流设计，另一部分与业务效果挂钩，按关键指标的改善程度或处理规模收费。

例如在风险控制场景中，能力建设费覆盖前期数据对接、特征工程、策略配置和规则系统搭建，效果相关部分可以与坏账率下降、误报率降低或者审核效率提升挂钩。这类模式把双方的利益确实绑定在一起，也对厂商提出更高要求，因为如果能力没有持续改善效果，就难以支撑长期收入。

这种“能力建设加按结果计费”的结构，与 Palantir 所走的路在精神上非常接近。重要的不是完全复制其合同细节，而是借鉴其对结果负责的姿态，用业务指标来约束和驱动交付质量。

6.3 与传统 SaaS 的共存与演化

AI 能力服务不会在短时间内完全取代 SaaS。很多基础系统如财务、人力、协同办公，仍然适合以 SaaS 形态交付，因为它们涉及的流程相对稳定，差异程度可控。变化更多的是边界地带，那些夹在流程和决策之间的灰色区域，会逐步被 AI 能力覆盖。

可以把传统 SaaS 看作企业的“基础设施层”，承担记录、计算和合规职责。AI 能力服务则更像“策略和行动层”，帮助企业在这些基础设施之上跑出更智能的路径。两者不是简单替代关系，而是分工演进。对很多现有 SaaS 厂商来说，把自己的一部分产品演化为 AI 能力的承载面，是一个现实的升级方向。

对新进入者来说，也没有必要和所有 SaaS 厂商直接竞争。围绕某些传统 SaaS 没有覆盖好、又与结果高度相关的任务链切入，更有机会构建独立价值。长期看，一些 AI 能力服务商会反向下沉到基础设施层，一些 SaaS 厂商会向上延展到能力层，行业边界会逐渐模糊。

● 七、对中国企业的实践启示 从买软件到买第二组织

7.1 选择能力伙伴时需要看的几件事

企业在选择 AI to B 合作伙伴时，如果沿用评估 SaaS 的检查表，很容易把重点放在功能数量、可配置项多少和报价细节上。这些内容仍然重要，不过更应该放在第二位。首要问题是这家厂商能明确改善哪些业务指标，以及愿意在多大程度上和你一起对结果负责。

评估时可以围绕几点展开。第一，看对方是否以任务链方式描述能力，而不是只谈某类系统。第二，看对方是否有意愿与现有系统做深度集成，而不是要求你迁移到全新平台。第三，看对方是否愿意把一部分收费与效果挂钩，哪怕比例不高，也能体现其信心与姿态。

这些问题问清楚，往往比反复对比功能清单更有价值。功能可以通过演示和试用确认，能力是否能转化为结果，需要在合作前就设定清晰的量化目标和验证路径。

7.2 组织内需要的新角色和治理机制

AI 能力引入企业之后，不只是多了一套系统那么简单，而是相当于引入了一支新的“数字化团队”。这支团队虽然由外部厂商和模型承载，却实实在在地参与到关键业务决策和执行中。企业内部如果没有对应的责任人和治理机制，这支“第二组织”很难发挥好作用。

实际操作中，很多公司会在 CIO 或数字化负责人下面设一个小型的“能力办公室”，也有人称为 AI PMO。这个团队的职责不是日常运维系统，而是负责几个关键事项。第一，识别适合引入 AI 能力的任务链，和业务线一起定义目标和边界。第二，协调数据、IT、安全等相关部门，为能力落地扫清障碍。第三，持续跟踪能力输出的质量和业务效果，推动迭代和扩展。

没有这样一个跨部门的 Owner，AI 项目很容易碎片化，变成各个部门各自尝试的小实验，难以形成组织级能力栈。相反，如果这个角色定位清晰，在组织内有足够话语权，能力服务厂商也更容易找到稳定的对接窗口，合作边界会清晰很多。

7.3 风险和落地难点的提前预期

AI 能力服务不是银弹，引入过程中会遇到各种技术和组织挑战。技术层面包括数据质量参差不齐、接口不规范、历史系统文档缺失等，这些问题会显著拖慢项目进度。组织层面包括部门之间的数据边界、防守心态、对新工具的不信任感，这些都会影响使用深度。

企业在启动项目时，如果能把这些问题写进预期和计划里，心态会更稳，合作氛围也更健康。可以预留一段专门的“数据整理和对齐期”，接受短期内看不到业务效果，但为后续能力打好基础。也可以在管理上明确表态，对试点部门给出一定的容错空间，让他们敢于在真实业务里尝试新工具。

对厂商来说，坦诚地把这些风险与客户共享，比过度承诺要更有利于长期合作。一个靠谱的能力服务提供方，不会把所有难题都轻描淡写，而是会给出清晰的路线图和阶段性目标，把不确定性控制在可接受范围内。

结论

中国 SaaS 的十多年，清晰暴露出标准化软件模式与本土企业环境之间的结构性矛盾。流程不稳、人力便宜、KPI 周期短和差异化诉求强烈，使得依赖稳定共性和规模效应的纯 SaaS 模式很难跑出理想中的轨迹。很多公司最后走向“外表 SaaS、内里外包”的折中状态，既难以享受高估值溢价，又背上了沉重的人力运营负担。

Palantir 提供了一条不同的路径。它一开始就接受客户流程的复杂性和差异性，选择通过深度嵌入来构建信任和理解，再在项目中不断抽象通用能力，形成可迁移的平台。它放弃了“替代几个岗位”的狭窄价值叙事，强调提升组织整体智能，把收费与关键业务结果绑定。这种以“能力即服务”为核心的模式，对流程复杂、多变又高度结果导向的中国企业而言，更有现实可行性。

AI 技术的成熟，让这种模式在技术上变得更加可行。大模型降低了构建通用能力的门槛，语义层和工作流引擎让能力能以更灵活的方式嵌入现有系统。对厂商来说，从卖工具转向卖能力和结果，是商业模式和组织能力的双重升级。对企业来说，从买软件转向买“第二组织”，是数字化策略和治理结构的重新设计。

未来几年，中国的企业服务市场会在这条新路径上进行大量试验。那些敢于放弃表面规模，扎实打穿一两条关键任务链路的团队，更有机会把能力沉淀为平台，形成真正可持续的业务。那些愿意和厂商共担结果、为长期能力建设留出空间的企业，也更有可能从这一轮技术变革中拿到超出行业平均水平的回报。

工具时代在很多领域已经走到边界，能力时代正在打开新的窗口。对于习惯了按功能和 license 评估软件的企业和开发者来说，现在是一个适合重新审视问题定义的时间点。真正值得持续投入的，不是多一套系统，而是一套能在变化环境中稳定输出价值的组织级能力栈。

📢💻 【省心锐评】

看懂 Palantir 的路,会发现关键不在软件栈,而在敢按“任务链+结果”重构整套 ToB 模式