AI 时代软件会如何发展，联犀的解决之道是什么？

约 7963 字大约 27 分钟

2026-05-20

AI 时代真正改变软件行业的，不只是“多了一个更聪明的聊天入口”，而是软件生产方式、交付方式和使用方式正在被同时改写。
过去做一个系统，往往要经历长周期需求梳理、页面设计、接口开发、联调测试和持续迭代；现在借助 AI，很多原本需要数周甚至数月才能验证的想法，几天之内就能做出第一个可用版本。软件的试错成本、原型成本和很多标准模块的开发成本，都在快速下降。

这会带来一个非常直接的变化。未来真正稀缺的，不再是“能不能把一个页面和几个接口做出来”，而是“能不能把 AI、权限、数据、流程、设备和多种入口组织成一个长期可运营的系统”。
也就是说，简单应用会越来越便宜，复杂系统的价值则会越来越集中到平台能力和组织能力上。

这正是联犀判断 AI 时代软件演进方向的出发点。

先说结论

如果把这篇文章压缩成几句话，联犀的判断是：

AI 会持续拉低软件开发成本，但不会抹平企业级复杂度
C 端会先跑出大量 OpenClaw、Hermes 这类个人 AI 应用，B 端则会更依赖平台化底座
企业真正要建设的，不是一个会聊天的助手，而是一套能承接知识、工具、权限、设备和执行环境的 AI 原生基础设施
联犀的价值，不是替代个人 AI，而是把个人侧、本地侧、云端侧、应用侧和设备侧连接成一个整体

对老板来说，这是软件产业结构在变化。
对产品经理来说，这是产品形态在变化。
对联犀来说，这是平台边界在变化。

软件成本会继续下降，但企业级复杂度不会一起消失

AI 已经证明，它非常擅长把很多标准化软件工作压缩到更短时间里，例如：

快速生成页面和基础交互
快速搭建 CRUD 类业务能力
快速补充脚本、报表、自动化流程
快速做出某个场景的单点智能助手

这意味着，未来大量“小应用”“小后台”“小工具”的开发门槛会继续下降。
以前企业需要专门排期开发的很多功能，以后可能通过 AI 就能很快做出来。

但这里最容易产生一个误判：
软件成本下降，不等于企业级软件会被一句提示词直接替代。

因为企业级系统真正难的部分，从来不只是“功能做出来”，而是：

谁能看，谁能用，谁能操作
一个动作经过哪些审批、流程和约束
数据属于哪个组织、哪个项目、哪个角色
系统升级后能不能持续维护，能不能稳定扩展
多个应用、多种角色、多条业务线之间能不能协同

再往深一层看，企业级系统真正的门槛，还在于复杂架构和复杂功能的长期治理。
很多东西 AI 可以帮忙快速搭出来，但要把一个复杂系统真正做好，仍然需要专业的人来完成架构设计、边界拆分、稳定性建设、性能治理、故障处理和持续演进。
因为企业买的从来不只是“一个能跑起来的版本”，而是一套能长期运行、长期维护、长期升级的系统能力。

这些问题不会因为 AI 出现而自动消失，反而会因为 AI 能够直接调用工具、操作系统、访问数据而变得更敏感。
如果没有稳定的权限体系、执行边界和运行治理，AI 带来的不是“效率翻倍”，而是“风险也一起放大”。

为什么 OpenClaw、Hermes 会先在个人侧跑起来

从当下市场表现看，OpenClaw、Hermes 这一类产品在个人侧和开发者侧已经很容易被理解，也很容易形成热度。原因并不复杂，因为个人场景天然具备几个优势：

使用者就是决策者，不需要复杂审批
数据范围相对收敛，不涉及大量跨组织权限
工具链更偏个人生产力，不需要承接完整企业流程
出问题的影响范围相对可控

所以在 C 端和个人效率市场，AI 原生应用会非常快地繁荣起来。
每个人都可能拥有自己的 OpenClaw、本地 AI 助手和自动化工作流，这是一个大概率会发生的未来。

但 B 端市场不一样。
企业不是只有一个人在使用 AI，也不是只有一个助手在运行。一个部门、一个项目、一条产品线，甚至一个设备体系，都可能需要自己专属的 AI 能力。到了这个阶段，问题就不再是“能不能有一个 Claw”，而是：

企业里会不会同时存在很多 Claw
这些 Claw 分别服务哪些角色和场景
它们能调用哪些系统能力，能看到哪些数据
它们如何统一接入知识、工具、流程和设备
它们如何被运行、被治理、被审计、被持续升级

这也是为什么个人侧已经很热，而真正面向企业级大规模落地的同类平台仍然相对少。
企业真正缺的不是一个会说话的 AI，而是一套能承载大量 AI 的底座。

更直白一点说，C 端和 B 端面对的根本不是同一个命题：

维度	C 端 / 个人侧 AI	B 端 / 企业级 AI
目标	提升个人效率	支撑组织协作与业务闭环
决策方式	个人直接决定	需要组织、权限、流程共同约束
数据边界	相对收敛	跨组织、跨项目、跨系统
工具形态	偏个人生产力	偏系统能力、设备能力、流程能力
运行要求	能用、好用	稳定、安全、可治理、可持续演进
成功标准	帮个人省时间	帮企业形成长期平台资产

这也是为什么很多个人侧产品可以快速爆发，而企业级市场最终拼的，往往不是单个 AI 产品体验，而是谁先拥有一套稳定、可治理、可持续演进的 AI 底座。

企业级 AI 的核心，不是单个助手，而是统一的 AI 原生底座

从产品和业务视角看，很多企业接下来都会经历一个转变：

第一阶段，是给现有系统外挂一个聊天入口。
第二阶段，是让 AI 开始查询数据、调用工具、辅助流程。
第三阶段，才是真正的关键阶段，也就是让 AI 进入系统主链路，成为应用、设备和组织协作的一部分。

一旦走到第三阶段，企业对平台的要求就会显著提高。真正可落地的企业级 AI 底座，至少要解决六件事：

1. 权限和组织边界

AI 不能脱离企业原有的组织结构独立存在。
它必须知道当前服务的是谁，属于哪个组织、项目、设备、角色和数据范围。否则 AI 连接得越深，越容易越权。

2. 工具和能力的标准化组织

企业能力不能只以内部接口存在。
如果 AI 面对的是一堆底层 API、内部字段和杂乱脚本，它很难稳定调用。企业需要把能力重新整理成 AI 更容易理解和消费的工具面。

3. 运行时和执行边界

AI 一旦开始执行工具、脚本和外部调用，就不再只是“回答问题”，而是进入可执行阶段。
这时候必须有独立运行时、资源隔离、网络隔离、workspace 隔离和故障隔离，否则很难真正上线。

4. 知识和上下文沉淀

企业 AI 不是一次性的问答工具。
它需要知识库、记忆、会话上下文、业务对象上下文，才能逐渐变成真正懂业务的系统能力。

5. 多入口协同

未来 AI 不只存在于聊天窗口。
它会同时出现在 Web、App、小程序、CLI、语音终端、设备入口甚至边缘侧控制器中。平台必须允许同一套主能力被不同入口复用。

6. 多 AI 共存与统一治理

未来不是企业只有一个超级助手，而是一个企业会存在很多不同用途的 AI。
有面向管理层的，有面向业务员的，有面向设备运维的，有面向客户服务的。企业真正需要的是多 AI 共存下的统一治理能力。

为什么联犀要做成 SaaS，同时保留私有化能力

联犀在产品形态上的另一个核心判断是：
AI 时代的平台不能只服务少数大项目，也不能只适合单一部署方式。真正有生命力的产品，既要能支撑复杂场景的私有化落地，也要能让更多中小场景直接通过 SaaS 获得服务。

这是因为不同企业面对的不是同一种问题：

大场景、复杂场景，往往对数据边界、系统集成、部署环境和运行管控要求更高，适合私有化或混合部署
中小场景、轻量场景，往往没有能力单独养一整套 AI 平台团队，更适合直接通过 SaaS 方式快速使用

过去很多 AI 能力之所以看起来“只有大厂能玩”，不是因为别人没有需求，而是因为门槛太高。
要把知识库、工具协议、权限体系、执行环境、设备接入、报表分析、场景联动和持续运维真正串起来，本来就需要很强的工程能力和持续投入。对于绝大多数公司来说，这套成本并不现实。

SaaS 的意义，不只是交付更方便，而是把这些原本需要大厂级投入才能拥有的能力，收敛成标准化服务，让更多企业可以直接获得：

不用从零搭 AI 底座
不用从零补权限、知识、工具和运行时体系
不用先组建一支完整的 AI 平台团队
可以先从具体场景开始使用，再逐步扩展

以前只有大厂能长期投入建设的东西，未来会逐步变成所有公司都能使用的基础能力。

更重要的是，SaaS 还有一个常被低估的优势：
当更多企业在同一平台体系内使用 AI，平台能力本身也会进化得更快。

当然，这里不是指不同企业之间共享私有数据。
企业自己的数据、权限和知识边界仍然必须严格隔离。真正会被持续放大的，是平台层的共性能力：

更成熟的 Skills 资产
更稳定的 MCP 工具组织方式
更高质量的知识检索和知识治理能力
更安全的 Sandbox 执行策略
更成熟的报表、分析、联动和语音协作模式

换句话说，大家一起使用 SaaS，不是让企业数据混在一起，而是让平台对“AI 应该怎样服务企业”这件事迭代得更快。
使用者越多，联犀在工具组织、执行治理、产品体验和行业方法论上的沉淀就越深，平台也就会变得更强。

这也是 AI 原生系统和传统软件一个非常不同的地方：
它不是一次交付后能力就基本固定，而是会在使用过程中持续变得更好用。

传统系统上线之后，更多时候是在等开发排期、等功能迭代、等下一版升级。
而 AI 原生系统在平台能力、工具组织、知识沉淀、提示策略、交互方式和场景理解上，都可以随着使用不断优化。很多能力一开始可能只是“能用”，但随着数据积累、经验沉淀和场景打磨，最终会变成“越来越准、越来越顺手、越来越不用操心”。

从这个角度看，联犀做 SaaS 和做 AI Native 平台，本质上是在做一件事：
让企业今天接入的，不只是一个当前版本的软件，而是一套会随着使用持续成长的系统能力。

联犀的解决之道，不是替代 OpenClaw，而是把它们接进企业体系

联犀的判断很明确：
未来不是“云端平台替代个人 OpenClaw”，而是个人侧、本地侧、云端侧、企业系统侧和设备侧会逐步融合。

因此，联犀做的不是再造一个封闭世界，而是去补企业级 AI 最缺的那一层基础设施，让个人侧 AI、云端 AI、企业系统和设备能力真正连起来。

从平台结构上看，联犀把企业级 AI 能力拆成四个层次：

控制面：负责会话、Agent、Clone、知识装配、技能装配和外部入口组织
执行面：负责 Claw runtime、工具调度和实际执行过程
工具面：负责 Skills、MCP、CLI 以及前后端 tools 的能力组织
应用面：负责 SaaS 应用、IoT 设备、第三方系统和语音终端入口

这套结构的意义在于，联犀不是简单把大模型接到系统上，而是把 AI 作为平台主能力来组织。

换句话说，联犀给企业的答案不是“再做一个助手”，而是：

先把企业原本分散在页面、接口、设备、知识、脚本和流程里的能力整理出来，
再把这些能力通过知识库、MCP、Skills、Sandbox 和云端 Claw 重新组织成 AI 可以安全消费的平台能力。

联犀具体解决了企业级 AI 落地中的哪些难题

第一，联犀已经具备企业级底座，而不是从零拼 AI 演示

联犀本身就承接了 SaaS、IoT、权限、项目、设备、数据和业务能力。
这意味着，当企业要做一个新的 AI 应用时，不需要先从零补齐组织、权限和业务底层，而是可以直接在既有底座上进行 AI 化升级。

对老板来说，这件事的价值很直接：
不是每做一个新 AI 应用，就再重做一遍用户体系、权限体系、设备体系和项目体系。

对产品经理来说，这意味着可以把更多精力放在“场景设计”和“人机协作流程设计”上，而不是把大量时间消耗在重复的底层建设里。

第二，联犀把平台能力整理成 AI 可消费的 Skills、MCP 和 CLI

企业级 AI 之所以难落地，很大一个原因是业务能力没有被整理成 AI 能消费的形式。
联犀在这方面已经做了比较明确的工具化组织：

通过 ur CLI 提供统一操作入口
通过 Skills 把设备、产品、项目、用户、系统、AI 管理等能力整理成可加载能力集
通过 MCP 把设备控制、查询和外部能力桥接成更适合大模型调用的工具协议

这意味着，联犀不仅能服务自己的云端 AI，也能服务 OpenClaw、PicoClaw、Hermes 这类个人侧或本地侧 AI。
联犀已经提供了对应的 Skills 安装方式，让这些 AI 可以接入联犀平台能力，而不是孤立工作。

这一步非常关键。
它说明联犀的方向不是“把 AI 锁在平台里”，而是“把平台能力变成可分发、可接入、可复用的 AI 能力面”。

第三，联犀把知识库、MCP、Skills 和 Sandbox 变成企业级 AI 的基础设施

很多团队也会提知识库、提工具、提安全，但真正难的是把这些能力做成能长期复用的平台基础设施，而不是一堆临时拼装模块。
联犀在这里更强调四个关键件必须一起成立：

知识库：让 AI 不只是会聊天，而是能够围绕企业文档、规则、经验和业务知识来回答、检索和协作
MCP：把设备、系统和外部服务能力整理成更适合 AI 理解和调用的工具协议
Skills：把平台能力做成可加载、可分发、可复用的能力集合，既服务云端 AI，也服务 OpenClaw、Hermes 这类本地或个人 AI
Sandbox：把 AI 的执行环境隔离出来，约束网络、workspace、资源和故障影响范围，让工具执行真正具备上线条件

这四个能力不是彼此孤立的。
知识库解决“AI 知道什么”，MCP 和 Skills 解决“AI 能做什么”，Sandbox 解决“AI 怎样安全地去做”。
只有这几个基础件一起成立，企业级 AI 才不是一个会说话的外挂，而是一套可以长期运行、长期优化的主能力。

如果要用一句更容易传播的话来概括，这四个能力分别对应企业级 AI 的四个基本问题：

知识库：有没有企业自己的知识大脑
MCP：有没有适合 AI 调用的标准工具协议
Skills：有没有可分发、可复用的能力资产
Sandbox：有没有真正可上线的安全执行环境

第四，联犀把执行能力从普通业务服务里拆出来

很多团队一开始做 AI，都是先做聊天接口，再把工具执行塞进主服务里。
这样在验证阶段当然快，但一旦进入企业级场景，问题会非常快地暴露出来：

一个任务失控可能拖垮主服务
一个执行环境看到了不该看的目录
一个外部调用访问了不该访问的网络
一个长任务把整个系统入口堵住

联犀在这件事上的做法，是把控制面和执行面拆开，引入独立的 Claw runtime，并叠加 Sandbox 做执行约束。
这样 AI 的工具执行、脚本执行和外部调用，才能真正具备上线条件。

这不是“工程洁癖”，而是企业级 AI 和演示级 AI 的分水岭。

第五，联犀让 AI 能真正进入设备和边缘场景

很多平台谈 AI 时，只停留在知识问答和办公助手层面。
联犀更进一步的地方在于，它本身具备 IoT 底座，可以把 AI 与设备、物模型、项目权限和设备控制连接起来。

通过 MCP 和物模型语义组织，AI 不是简单“帮用户点按钮”，而是能够围绕设备能力做查询、理解、执行和反馈。
再进一步，通过小智这类语音链路，AI 还可以进入更自然的终端入口，让边缘设备、本地交互和云端平台连成一体。

也就是说，联犀看到的不是“AI + 软件”这么简单，而是“AI + 软件 + 设备 + 语音 + 边缘”的一体化未来。

这些能力落到真实业务里，会变成什么

如果文章只停留在平台层，很多老板和产品经理仍然会觉得这是“架构很好”，但离业务价值还有距离。
真正有意义的是，这些能力已经可以被收敛成一批非常具体的企业场景。

这些场景的共同特点是：
不是单纯多了一个 AI 对话框，而是原本割裂的“数据分析、报表组织、规则联动、报告审查、设备协同”开始被 AI 重新串起来。

1. 设备分析不再只是固定报表，而是变成可交互的 AI 分析能力

过去做设备分析，通常是提前定义好几个固定看板、固定统计口径和固定图表。
这当然有价值，但它有一个明显问题: 一旦业务方临时想换一个观察角度，就往往要再提需求、再改接口、再补页面。

在联犀这类底座上，用户未来可以通过自己的 Claw，或者云端承载的 Claw，直接围绕设备最近运行状态做快速分析，例如：

最近一段时间的电压、电流、温度、功率波动
多台设备之间的对比
按项目、区域、设备分组做自定义聚合
根据临时问题自动生成图表和趋势判断

也就是说，设备分析会从“平台预先定义给你看什么”，逐步变成“用户按当前问题动态要求 AI 帮你看什么”。
固定报表不会消失，但它旁边会多出一层更灵活的 AI 分析能力。

2. 应用里的自定义报表，会逐步被 AI 增强

很多企业系统不是没有报表，而是报表太多、口径太碎、改动太慢。
联犀更适合承接的一种升级方式，不是把原有报表全部推翻，而是在现有应用里给报表能力接入 AI 增强。

这类增强可以体现在：

根据用户问题动态组合报表字段和统计口径
围绕某个项目、某批设备、某段时间自动生成专题分析
对已有报表做解释、总结和异常提示
让传统“配置报表”的过程，逐步过渡到“描述问题，系统自动组织结果”

对产品经理来说，这里最关键的变化不是多了一个聊天框，而是报表产品形态在变。
未来很多“自定义报表”不一定先从字段设计开始，而是先从业务问题开始，再由 AI 去帮助组织查询、聚合、图表和摘要。

3. 场景联动会从固定规则，走向“规则 + AI”的动态联动

在物联网场景里，传统联动往往依赖固定规则或算法阈值。
这套方式很重要，也必须保留，因为它稳定、可控、可追溯。但很多真实业务场景并不是一个固定阈值就能长期适用。

以农业大棚为例，同样的温湿度控制目标，不同大棚、不同作物、不同时间段、不同天气条件下，理想状态都可能存在差异。
传统方式通常通过算法去逼近这个目标，而 AI 可以在算法之上再增加一层“动态调参能力”。

例如现场人员可以告诉系统：

这个棚最近偏冷，需要整体调高一点
这个区域湿度不要再压这么低
今天的控制效果不理想，参数要更柔和一点

在这种模式下，AI 不是替代原有算法，而是在算法保证基础上，把人工经验、现场反馈和历史表现重新吸收进去，动态调整参数。
这样每个大棚、每个区域、每类设备就更容易形成更适合自身情况的控制策略。

这也是联犀强调“融合”而不是“替代”的原因。
企业原有规则、算法、控制逻辑都还是主干，AI 负责让这套系统更灵活、更懂现场，而不是把可控逻辑全部推翻。

4. 报告密集型行业，会先从“AI 辅助审查和更新”中获得明显收益

除了设备控制类场景，另一个非常值得重视的方向，是监测、施工、巡检、能源、安防这类报告密集型行业。
这些行业长期存在几个典型问题：

报告数量多，人工修改频繁
标准更新后，旧模板和旧结论容易漏改
多份报告之间存在引用、关联和口径一致性要求
人工审查耗时长，而且容易出现遗漏

AI 在这里最现实的价值，不是凭空替代专业人员写报告，而是帮助企业先把“高重复、易出错、强关联”的部分接住，例如：

动态关联历史报告、现场数据和标准模板
自动检查当前报告与最新标准是否存在冲突
自动提示哪些章节需要同步更新
对报告中的表述、指标和引用关系做一致性审查
帮助形成初步修订建议，再交给专业人员确认

这类场景的商业价值往往很直接，因为它节省的不是一两次问答时间，而是整条文档生产和审查链路的重复成本。
对于很多传统行业来说，AI 最早跑通的，不一定是最炫的对话体验，而是这些原本大量依赖人工维护的高密度文档工作。

更关键的是，这类场景天然符合“越用越好用”的规律。
报告审核能力一开始未必足够准确，可能还需要人工频繁复核；但随着平台持续积累报告模板、行业标准、修订记录、常见错误类型和人工反馈，AI 的判断会越来越稳。很多企业最终会明显感受到一个变化：从最初“AI 只能帮一点”，逐步走到“AI 先审一遍，很多地方基本已经不用操心”，人工更多只需要处理少量关键复核和最终确认。

给老板的判断标准：什么样的 AI 项目值得投

如果站在老板视角，未来判断一个 AI 项目值不值得投入，建议重点看五个问题：

这个项目是在做一个短期演示，还是在沉淀长期平台能力？
它有没有复用现有权限、数据、流程和系统，而不是另起一套孤岛？
它能不能从单点助手扩展成多个场景、多种角色共同使用的体系？
它的运行和安全边界是否清楚，能不能真正上线？
它是否有机会把页面入口、AI 入口、设备入口和语音入口逐步打通？

如果这些问题的答案大部分是否定的，那么项目大概率只是一个“会说话的功能模块”。
如果这些问题能逐步成立，它才更像企业下一代软件能力的起点。

老板真正要买的，不是一次热点，而是三种更长期的确定性：

业务确定性：AI 进入真实业务，而不是停留在演示层
工程确定性：系统可以稳定运行、稳定升级、稳定治理
资产确定性：知识、工具、流程和数据会持续沉淀为企业自己的平台资产

给产品经理的落地路径：不要直接做“超级 AI”，先做四步升级

对产品经理来说，AI 时代最容易犯的错误，是一上来就想设计一个包打天下的超级助手。
更现实的路径通常是四步：

先接入现有业务底座
先把用户、角色、项目、设备、数据范围和业务对象对齐，明确 AI 到底服务谁。
把高频能力工具化
把最常用的查询、操作、设备控制、流程动作整理成 Skills、MCP 或标准工具，而不是让模型直接碰底层接口。
先做单场景闭环
先跑通一个高频场景，例如设备运维、工单辅助、项目查询、知识问答，而不是同时铺开所有方向。
再做多入口融合
当单场景闭环跑稳后，再逐步扩展到 Web、App、OpenClaw、本地助手、语音终端和设备侧入口。

这个路径的关键，是让 AI 先进入真实业务，再逐步从单点能力升级为统一体验。

对产品经理来说，这里面最重要的转变其实是心智转变：
以后很多产品设计，不再是“先设计页面，再补一个 AI 功能”，而是“先设计场景闭环，再决定页面、AI、设备和语音分别承担什么角色”。

未来的软件，不会是更多小应用，而会是更强的一体化体验

过去很多大厂喜欢做多应用矩阵，用大量子系统去覆盖不同场景。
在 AI 时代，这种割裂体验会越来越难让用户满意。因为当软件生产成本下降之后，用户自然会期待更高层级的体验升级。

未来更有竞争力的软件形态，很可能不是再多做十个小应用，而是让这些能力在用户侧看起来像一个整体：

个人有自己的 OpenClaw 或本地 AI 助手
企业云端运行着面向组织和业务的 Claw
传统应用承接正式流程和数据治理
边缘设备和语音终端成为新的自然入口
不同 AI 之间可以围绕统一的 Skills、知识、工具和权限体系协作

AI 会像水一样，既存在于本地，也存在于云端；既服务个人，也服务组织；既进入页面，也进入设备。
谁能把这些能力连接成一体，谁就更有机会定义下一代企业软件。

总结

AI 时代的软件演进，并不是“所有软件都会被 AI 生成替代”，而是软件价值的重心会重新分配。
简单功能会越来越便宜，真正长期有价值的部分，会越来越集中在统一底座、权限治理、工具组织、执行管控、多入口融合和持续演进能力上。

OpenClaw、Hermes 代表的是个人侧 AI 应用已经跑通的方向；企业级市场真正缺的，则是承接多 AI、多系统、多设备和多角色协同的基础设施。
联犀给出的解决之道，不是与这些个人侧产品对立，而是通过 Skills、MCP、知识库、Claw runtime、Sandbox、SaaS 与 IoT 底座，把个人侧、本地侧、云端侧和设备侧连接起来。

这也是联犀对 AI 时代软件未来的判断：
不是谁先做出一个会说话的应用，而是谁先做成一套真正可落地、可治理、可持续扩展的企业级 AI 原生平台。