大模型在“刷榜”，企服厂商在“排雷”

这场仗打到最后，拼的就是工程能力和服务底座。

文｜周效敬

过去两年，企业软件行业对 AI 的讨论异常热烈，但真正艰难的深水区始终在生产现场。

如今，企业的焦点已经从模型参数的高低，务实地转向了诸如高峰期服务稳定性、长周期任务防“漂移”、限流平滑切换、安全边界防守，以及输出结果能否真正嵌入核心业务流等具体的现实痛点。

相比参数的堆砌，这些现实的工程与交付难题，才是决定模型去留的关键因素。

基于本次调研，牛透社提炼出五个核心判断：

• 企服厂商已迈入真接入阶段，大模型竞争的终点正落在生产环境。
• 当前大模型的主要短板，集中暴露在缺乏企业级服务能力上。
• 模型选型正依据具体应用场景走向分化，国内外大模型各守一段。
• AI 落地路径愈发明朗，先提效，再增强，最后入核心链路。
• 下一轮的角逐，比拼的是工程化与组织化能力。

一、怎么选：场景可用性决定模型去留

受访企业横跨财税、CRM、垂直行业软件，并延伸至智能硬件、综合企服、软件工程、数据库与 BI 等赛道。

规模差异也极为显著，既有 6 家年营收在 5000 万元以下的初创与成长期企业，也有 4 家体量超 5 亿元的头部玩家。

在月度 AI 支出上，各企业的投入规模差异显著：低于 1 万元的有 4 家，1 万至 10 万元的有 3 家，另有 4 家的投入区间在 10 万至 50 万元。

行业不同、规模不同、投入强度迥异，这组样本恰好构成了企服市场最真实的切面。

企业的痛点也比较分散，有人死磕编程效率，有人聚焦知识库与客服，有人与实时语音“时延”博弈，有人死守强合规场景的稳定底线。

从实际接入情况来看，通义千问展现出最高的覆盖率。11 家样本中，有 6 家已将其投入实际使用或深度测试。紧随其后的是 GLM 和 Kimi（各 4 家），豆包与 MiniMax（各 3 家），以及 DeepSeek （2家）与百川（1 家）。而文心、混元、Yi 暂未进入这组受访企业的实际接入或深测名单。

可见，企服厂商选模型，绝不盲从市场声量，能不能进测试池，最终只看可用性。

但“接入广”并不等于能“挑大梁”。到了复杂的编程和深层工程任务区，企业的选择变得更加现实与苛刻。柠檬云长期使用 OpenAI 体系中的 Codex 方案；衡石主要押注 GPT 和 Claude 系列；Agents 特区创始人马驰表示，他们更倾向于Claude 系列的 Opus，但是考虑到合规和价格，他们也认可 GLM 是不错的平替。

国内大模型的口碑，也开始拉开距离。

文心的负面反馈最集中，被受访者在“幻觉偏多”、“接入成本高”、“隐形成本高”等问题上反复提及；Kimi 承受的压力多落在成本和调优负担上；MiniMax 的评价最分裂，幻觉偏多与认可其逻辑性并存；GLM 在编程等专业任务中确立了存在感，但在服务支持与接入体验上仍需补齐。

此外，企业的关注点，已经从通用榜单名次转移到了具体场景的稳定性、便利性及综合代价上。

网易智企的实践极具代表性。他们内部不会把某一个模型全线铺开，而是按业务跑 Benchmark。知识库、客服、Agent、AI Coding，各自测试，再决定谁来承担生产任务。

在这套场景化选模逻辑下，通义千问的优势集中在综合适配、本地化部署及垂直行业可用性，在医药场景中极易进入业务流；豆包更贴近实时交互场景的生产需求；GLM 守住了编程任务的一席之地；而在最复杂的工程任务区，高频主力仍是 GPT-4 系列和 Claude 系列。能否进入生产、扛住高峰、减少返工、稳定托底，已成为选型的标尺。

二、痛在哪：大模型交付的五大落差

企业软件厂商最关心的是“交付能力”本身，所以，一旦步入生产环境，模型潜藏的问题便会暴露。

当前，业界的不满主要集中在上下文稳定性、动态扩缩容、安全边界、场景适配以及线上托底能力这几大维度，这几乎是所有受访者的共识。

第一个问题，上下文的稳定性有待提升。

柠檬云 CEO 张子荣指出，尽管团队长期使用 Codex 且认可其整体表现，但长窗口下的上下文污染问题依然棘手。编程极度依赖上下文，窗口一旦拉长，信息便极易“变脏”，模型注意力随之稀释。在长周期任务中，远端信息极易被忽略，从而徒增返工与调试成本。

深耕 B2B2C 实时语音陪伴场景的 Whispal，同样遭遇了类似困境。

公司创始人吴林坦言，其产品不仅涉及文本理解，还需联动动作、震动及舵机反馈。随着对话拉长、提示词趋于复杂，模型极易偏离既定任务。为此，团队采取了极为克制的处理策略，将提示词压缩至极致的精准与精简，竭力维持上下文的纯粹，以此来提升 MCP（模型上下文协议）调用的准确率。由此可见，企业真正诉求的，是一个边界清晰且具备高可控性的上下文环境。

Agents 特区创始人马驰更是直言，所谓“超长上下文”往往流于营销概念。模型输出质量虽不至于瞬间崩溃，却会呈现持续衰减的态势：上下文越短，输出越稳；越接近标称（官方给出的、名义上的、理想状态下的参数值）的长度上限，质量越难保障。其团队的应对策略是主动舍弃“用满”上下文的执念，将复杂任务拆小，并将有效信息沉淀为文档，确保每次会话仅承接当前亟需的内容。对于企业级应用而言，上下文的“纯净度”，往往比单纯的“长度”更具业务价值。

第二个问题，企业亟需弹性供给，而非低廉的 Token 定价。

以 Whispal 为例，其业务呈现出典型的波峰波谷特征，日间并发量平稳，而夜间 9 点至 11 点的 RPS（每秒请求数）会急剧飙升。若长期按峰值配置算力，成本难以控制；若按均值配置，则无法抵御晚高峰的冲击。

这本应是云化服务的强项，但现实却差强人意。

吴林指出，当前的大模型服务还难以做到实时动态的扩容与缩流。故障发生时，厂商确能迅速响应并建群对接，但真正的掣肘在于“扩容”动作本身——往往需要提交流程申请，快则数小时，慢则耗时一天。

对实时语音产品来说，这样的扩容时差已经足以影响线上体验。企业客户和模型厂商的关注重点，也在这里出现了偏差。前者看重高峰期能否稳住、低谷时能否收回、系统能否随负载变化灵活调度；后者仍在强调价格、单次调用成本和 Token 消耗。企业采购的，实际上是一套具备弹性和托底能力的服务。

第三个问题，安全隔离与审计能力尚未具备真正的“企业级”基因。

马驰认为，企业客户的核心诉求在于安全、可审计、资源硬隔离，以及“数据绝不被用于训练”的承诺。

更为理想的业态，应该是由云厂商与大模型厂商联合提供专属实例，将隔离等级、审计链路与加密标准全面对齐企业级准入门槛，而非延续面向 C 端用户的低价逻辑。当下许多厂商仍惯用 To C 的思维来操盘 To B 服务，这正是症结所在。

某生命科学领域跨国头部软件企业相关负责人C女士向牛透社透露，基于授权条款和信息边界的模糊性，其公司明令禁止员工在工作电脑上随意安装通用 AI 工具。更为稳妥的防范措施是自购云服务器进行部署，从而将前端应用与核心商业机密实行物理隔离。

在医药、金融、法律、政务等赛道，安全从来都不是加分项，而是不可逾越的底线。

第四个问题，模型厂商最缺真实业务场景与针对性的 Benchmark（评测基准）。

网易智企-CodeWave 技术负责人姜天意告诉牛透社，模型厂商当前最缺的，仍然是真实场景，需要通过足够多的案例去验证能力边界。

基于这一判断，他们在与模型厂商合作时，会把自身业务中的 Benchmark 提供出去。需求理解环节表现如何，哪些地方存在偏差，哪些环节仍需优化，都会被明确反馈。对模型厂商来说，这类合作的价值在于真实业务场景数据本身的稀缺性。

很多模型厂商今天的优化目标，仍然没有完全转到企业侧。公开榜单、通用 Benchmark、标准演示场景，依然占有较高权重。

企业软件里的问题更细，也更具体。需求理解有无偏差，代码生成是否漂移，工具链切换之后是否平稳，多场景拼接之后还能否保持一致，这些问题都不显眼，也很难标准化，却直接影响模型能否进入生产。

企业客户越来越看重这一点，对模型厂商的要求也随之变化，重点正在从通用能力展示，转向真实业务场景中的持续优化。

第五个问题，大模型厂商学会了“拉群响应”，却还没有学会解决生产问题。

客观说，如今的大模型厂商在服务姿态上已日臻成熟。一旦企业遭遇故障，专人对接、组建响应群、拉齐售后与解决方案体系已成标准动作。

Whispal 也认可此类响应的及时性。但真正的痛点并不在于消息是否回复，而在于遭遇时延卡死如何破解、动态扩容如何实现、实时可用性如何保障，以及模型波动时该如何为关键业务构建缓冲地带。上述种种，绝非单纯“建群”便能化解的工程难题。

马驰指出，许多云厂商依旧带着浓厚的 To C 思维来试水 To B 市场，既缺乏操作真实生产系统的实战经验，也欠缺引导客户构建高可用、强合规及高安全架构的技术底蕴。表面的服务动作固然周到，但真正能够“托底”生产链路的能力依然匮乏。

梳理至此，症结很清楚了。

模型厂商眼下最欠缺的，恰是跨越企业级服务的“最后一公里”。而企业客户最终愿意买单的，本质上是坚如磐石的稳定性、收放自如的弹性，以及清晰可控的责任边界。

三、怎么用：落地先做提效，再进核心链路

从牛透社的调研和相关闭门会的讨论来看，多数公司都是先从内部效率切入，把研发、运营、内容生产这些最容易见效的环节跑通；再把 AI 嵌进产品，补强原有能力，覆盖长尾需求；最后才谨慎进入真正决定业务结果的核心链路。

先看第一层，内部效率层。

柠檬云的做法比较典型，张子荣把 AI 应用分成几个层面，最先落地的是全公司通用的人效工具。运营写文案、做短视频，研发做 AI 编程，这些已经进入日常工作流。他的判断是，AI 编程一定会提升人效，企业对组织和人员的优化迟早会发生，但短期仍处在摸索阶段，难点主要落在组织级和工程化提效上。

衡石创始人刘诚忠提到，他们公司已经重度依赖 AI，部分工程师当前几乎完全依托 AI 完成开发，产出提升达到数倍。个人效率被迅速拉高之后，组织层面的变化也开始出现。传统按前后端、测试、产品分工的软件工程管理方式正在受到冲击，衡石内部已经开始尝试 “AI Pod”（AI特种小队），把一条产品线交给更小、更灵活的团队推进，考核也更强调结果和代码提交强度。

马驰把 Agent 时代的新分工归纳为 PO、QO、TO 三个角色。PO 负责定义做什么，QO 负责定义什么是对的，TO 负责编排 Agent 的工作流。这个框架带来的变化是，人的职责开始从具体执行，转向问题定义、质量控制和流程编排。变化不止体现在提效上，企业内部的分工和协作方式也在被改写。

第二层是产品功能增强层。

这一层解决的是把原来做不到或做得不够好的部分补上。网易智企和柠檬云是两个很典型的样本。

姜天意提到，他们几乎每条业务线都在大规模使用大模型。智能开发、智能客服、知识应用等，已经成为明确的大模型驱动业务。

更早之前，网易智企旗下云商业务就把大模型用进了知识库和客服场景，面向零售客户提供客服Agent和销售 Agent，处理问答、提供导购；网易智企旗下CodeWave业务，将大模型装进可控的企业级 AI Coding 平台，基于 NASL 底座，以 Spec 驱动 AI 生成、可视化开发，实现企业级应用的高效可控交付。

放在一起看，大模型已经在企业内部逐步沉淀为跨业务线流动的技术底座。

柠檬云代表的是另一类场景。

财税行业对确定性要求极高，AI 很难直接进入核心记账逻辑。他们的做法更克制，核心算账和记账仍由代码规则承担，AI 去补的是代码难以覆盖、用户又确实需要的长尾部分。

张子荣给牛透社举了一个例子。银行流水识别里，代码可以处理 95% 的标准化格式，剩下 5% 的长尾场景再交给 AI 兜底。再往外延伸，财税答疑、风险检测、图片识别也属于这一类，单靠规则难以做好，接入 AI 后，体验会有明显改善。放在这个行业里看，AI 当前承担的角色更接近长尾托底和能力补充。

第三层才是核心链路层。

医药行业的边界感很强，也最能解释企业软件为什么不会轻易把 AI 一把推到底。

某生命科学领域跨国头部软件厂商相关负责人 C 女士告诉牛透社，药企不同环节对 AI 的接受度并不一样。临床研发端面对患者数据、研究机密和强监管，落地速度自然更慢；商业化团队有更直接的降本增效诉求，推进也会更快。

这个差异说明，AI 在企业软件行业里的渗透，始终是沿着容错率和业务风险逐层推进的。

更重要的是，AI 必须进入业务流。药企的业务流和销售行为数据，本来就沉淀在系统里。AI 的价值在于，从这些数据里提取洞察，再把洞察放回系统，转成后续动作。比如识别出某位医生的行为特征后，这个判断还要继续进入后续拜访、沟通和合规流程，不会停在一个聊天窗口里。

团队专门部署了“合规检测 Agent”来实时校验互动文本。当 AI 嵌入核心链路后，企业获取效率红利的代价，便是必须为整个业务流程全盘兜底。

这也是核心链路层和通用 AI 工具最明显的区别。通用工具给出一个结果，用户自己决定是否采纳；企业系统里的 AI，一旦进入流程，就会牵动动作、结果和责任。因此，该行业当前更常见的路径仍然是嵌入式增强，距离全面接管还有一段距离。

四、怎么变：AI 带来的软件产品底层重构

大模型进入企业软件之后，真正的变化是在需求结构、交互方式和产品节奏上。

第一个变化，轻量级SaaS的采购需求正被内部自研替代。

刘诚忠认为，ChatBI 这类能力叠加到 SaaS 产品里，并不意味着专业软件赛道会立刻被改写，更值得警惕的反而是轻量需求的自研替代。

过去企业采购 SaaS，往往只高频使用少数核心功能，甘愿为整套系统买单全因自研门槛过高。而大模型的出现，正在大幅削平这道壁垒。

尽管复杂系统的护城河依然深厚，但部门级工具、临时流程等轻量应用的开发成本已被显著打下来了。这直接冲击了一批处于边缘地带的 SaaS 产品。

可以说，企业核心的主系统短期内固若金汤，但长尾与局部需求的“外采基本盘”正在瓦解。过去依赖花钱采购来解决的痛点，未来企业完全可以靠内部团队自行消化。

第二个变化，SaaS 退居幕后，Agent 走向前台。

未来，软件的形态将是“Agent 交互入口 + 底层能力池”。用户跳过层层菜单直接下发指令，由 Agent 自动完成信息整合与动作触发。 这种交互范式的颠覆，直接改写了软件的价值分布。

过去，厂商靠前端页面和操作流程构建壁垒；往后，核心价值将彻底沉淀至底层。谁的数据更干净、接口更开放、规则更容易被机器调度，谁就拥有更高的话语权。这也宣告着，企服软件的竞争主战场已经改变。

第三个变化是产品立项节奏被压缩。

姜天意表示，今天做 AI 产品，已经不能只看当下缺什么，还要把 6 个月后的模型能力变化放进立项判断里。

网易智企内部的思路是，把“6 个月后的表现”作为重要标准，先判断届时模型能力会发展到什么程度，再判断这个产品对业务究竟是增值，还是防守。模型迭代太快，很多今天看起来成立的功能，半年后就可能被底层能力改写。产品判断因此被大幅前移。

轻量需求的自研门槛正在下降，底层 SaaS 逐步走向能力化，产品立项节奏也在明显加快。表面上看，变化发生在界面和功能层；往深处看，真正被改写的是需求结构、调用方式和产品逻辑。

聊天框并不难补，真正决定下一阶段位置的是产品能否接住新的需求变化，底层能力能否被调用，组织能否跟上更短的判断周期。

五、靠什么决胜：跨越选模型，拼工程与组织

模型能力当然重要，但到了大规模交付阶段，决定上限的是工程化水平和组织能力。

先看第一个问题，为什么工程化会成为头号问题。

网易智企给出了一条很有代表性的演进路径。早期，行业普遍尝试自然语言 Vibe Coding，希望通过对话直接生成应用。

后来，行业开始转向 SDD（Spec Driven Development） ，先写清规范和约束，再交给 AI 生成，但填补规范本身又带来新的输入质量问题，用户需要以更精确的方式描述意图；再往后，又进一步走到马具工程（Harness Engineering），从自然语言走向形式化约束。路径不断演进，核心问题始终如一，就是如何把生成变成稳定生成。

这条路径说明，AI Coding 的难点，既在生成能力，也在生成之后的稳定性。企业级环境里，价值不在一两次漂亮生成，而在反复生成、批量生成和多人协同之后，结果依然可用、质量依然可验、问题依然可追溯。

到了这个阶段，工程化已经成了交付链路里的核心环节，直接影响产品能否上线和长期运行。

第二个问题，工程化到底包含什么。

几位受访者的逻辑其实很一致。

网易智企强调三件事：事前可约束，让模型在明确边界内工作；事中可控制，通过拆任务，把复杂流程拆成彼此独立、可干预的子任务；事后可验证，通过代码检查、类型检查和测试，才能进入下一环节。企业级 AI Coding 处理的不只是生成本身，还包括规范、控制和验证。

在实时语音和多模态交互场景中，Whispal 也采用了类似的做法。吴林提到，他们的策略是把发给模型的上下文压缩到极致，剔除所有干扰信息，再配合精细的动态提示词，让模型始终保持稳定的理解力，从而提高外部工具（MCP）调用的准确率。

由此可见，“工程化”的价值绝不仅局限于代码生成领域。只要业务深度依赖大模型，所有企业都在攻克同一个核心难题，即竭力过滤背景干扰，将模型的不确定性牢牢锁定在安全边界内，确保输出结果不偏离预期，做到真正稳定可用。

马驰不迷信单一模型的绝对能力，他更看重工作流的设计与质量把控。

具体来说，就是把任务拆解到极细，明确交付标准，并设置多重审查门禁，让模型只在规定动作内执行。模型表现忽高忽低并不致命，靠着层层校验和迭代，总能把最终的交付质量拉到及格线以上。

对他而言，决定团队战斗力天花板的，是这套生产机制能否在高速产出时守住质量底线。

刘诚忠则把这个问题推到了复杂度管理层面。他认为代码生成速度已经超过了人类审查“带宽”，传统把关方式很难继续奏效。应对办法不在简单加人，而在建立结构化记忆和饱和式测试。前者沉淀文档、代码和历史问题，让 AI 在长周期协作中保持上下文共识；后者通过足够充分的测试，把风险尽量提前收敛。

这意味着，企业面对的核心挑战，已经变成如何管控和驾驭复杂的软件工程体系

第三个问题是组织为什么跟不上 AI。

马驰把企业从单点试用走向规模化落地的障碍，归纳为四类：

第一，激励不明确。效率提升了，职级、薪酬和收益分配没有同步变化，组织里就缺少足够动力去推广新方法。

第二，工作流阻碍。AI 把产出速度拉高了，Code Review（代码审查）、Ticket（工单）流程和协作机制还是旧节奏，产能堵在中间环节。

第三，观念抵触。尤其是中层，表面支持，实际拖延，用安全、合规和审计做缓冲。

第四，质量失控。高速产出之后，如果没有质量体系兜底，项目极易失控。

据马驰介绍，他们团队利用 6 名资深专家配合 AI，成功平替了原先 63 人的印度初级外包团队。留下的几个人去维护遗留系统，核心工作全转入“资深人员+AI”的协同模式。

这预示着重复性的执行岗位必将剧烈收缩，而懂编排、控流程的人才价值将陡增。

相比之下，柠檬云的观点更为温和。张子荣认为，AI 提升人效并引发人员优化是必然趋势，只是目前尚未大规模显现。“由于 AI 编程真正迈入普及化阶段已是 2026 年，多数企业仍处于摸索最佳实践的过程中，预计到今年下半年，提效成果会进一步释放，但大概率仍以温和的持续优化为主，不至于出现剧烈的人员收缩。”

这也再次说明，企业眼下真正的短板是缺乏能够承接效能爆发的组织结构。

在此基础上，引申出第四个问题——企业为何应警惕盲目的“全民 AI 培训”

马驰提供了一个极具穿透力的视角。他并不认同“全员学 AI，全员提效率”这种看似绝对正确的推进逻辑。当个体的产出效率骤升，而公司的整体业务盘子并未同步放大时，全员提效不仅无法带来增量，反而极易诱发抢夺项目，加剧内耗以及职责边界的混乱。

而且驾驭 AI 绝非教会员工写两句提示词那么简单。如何重新拆解需求？如何重塑项目管线？协作流程该怎么设计？质量门禁又该设在哪里？这些触及灵魂的管理命题，根本无法通过几堂培训课来化解。许多企业推行 AI 频频受挫，并非因为员工“学不会”，而是组织本身根本没有做好承接效率爆发的准备。

因此，破局的先决条件是率先打造一套能让 AI 顺畅运转的组织肌理。倘若原有的绩效激励、审批流转与岗位分工岿然不动，只是简单粗暴地将“提效”指标层层下压，最终的结局必然是员工疲于奔命学习各类工具，但效能提升微乎其微。

针对这一困局，马驰开出的药方是设立“AI 特区”

即摒弃全公司同步铺开的运动式打法，不急于撬动既有的庞大体系。优先圈定新业务、新团队作为试验田，为其匹配独立的考核目标、专属的流程与全新的战术打法。先在小范围内跑通人机协同的业务闭环，待模式成熟后，再向大盘稳妥复制。

这个思路更贴近企业现实，也更具操作性，因为它承认一个基本事实——组织变革本身就存在阻力，AI 落地走到最后，终究绕不开制度设计。

六、给大模型厂商的一份“催办清单”

通过本次微调研，牛透社总结认为，大模型厂商当下有六件事需要做：

第一，把长任务稳定性做实。

企业愿意付费的是一条能稳定跑完的长任务链路。任务一长就漂移、上下文一长就失真，如果解决不了这类问题，模型就很难真正进入生产。

第二，重视弹性供给。

To B 场景里，企业采购模型服务，关注的不只是 Token 单价，还包括扩缩容、时延保障、容量预案和 SLA。价格当然重要，很多时候高峰期能否稳住更重要。

第三，把企业级安全能力补全。

专属实例、资源隔离、可审计、数据不被用于训练，这些能力不再是附加项。到了医药、金融、法律、政务这些场景，安全和合规始终排在前面，模型能力再强，也要先过这一关。

第四，把真实业务的评测基准变成优化目标。

很多模型厂商今天仍然围绕公开 Benchmark 和标准演示做优化，但企业真正关心的是知识库场景稳不稳、客服场景会不会漂、Coding 场景需求理解会否跑偏。真正接近 To B 的厂商，优化重心迟早要落到真实业务上。

第五，把服务能力从“拉群响应”推进到“解决生产故障”。

今天不少厂商已经学会了快速响应，而企业更在意的是另一层能力。高峰期抖动怎么办，接口报错怎么办，关键链路波动时有没有预案等。

第六，给行业更多真实案例，尤其是失败案例和边界案例。

企业客户已经进入实操阶段，需要的是判断。哪些场景适合做，哪些暂时不适合，哪些项目失败了，失败在什么地方，都需要靠真实案例去沉淀共识。一个成熟的 To B 生态，不能只有成功学。

总结

企服厂商已经在实战中用起了大模型，但大模型厂商的 To B 服务能力却还欠着火候。

因为参数再大、模型再聪明，也无法直接换来企业的信任。企业真正需要的是系统稳、扩容快、数据安全，以及关键时刻不掉链子的兜底保障。这场仗打到深处，拼的就是工程能力和服务底座。

说明：文中配图内容来自牛透社微调研分析，图由 AI 生成。