ITPub博客

认识一家具身智能公司，我们往往先问它做什么技术：做模型、做本体，还是做数据。这个问题看似专业，实则暴露了行业观察的一种惯性——用技术栈给公司贴标签，用“做哪一层”来判断它的价值。但当具身智能从实验室走向真实场景，这种切分方式正在失效。依据现有素材判断，本文不提供具体公司案例与数据，而是从媒体视角拆解这一提问背后的认知框架，讨论为什么“做模型、做本体、做数据”的三分法不够用，以及我们该换一种什么样的问法。 三分法的由来：为什么我们习惯这样问 技术栈思维是理解新兴行业的捷径 面对一个陌生行业，最省力的认知方式就是沿技术链条切分。具身智能天然具备清晰的分层结构：底层是数据，中间是模型，上层是本体硬件。于是“做模型、做本体，还是做数据”成为一个顺口的问题，它对应着投资圈熟悉的“投哪一层”、媒体熟悉的“讲哪个故事”、求职

AI Coding 几乎是生成式 AI 落地最确定的方向之一：从代码补全、单元测试生成，到整函数、整文件乃至跨文件的改动建议，工具形态不断演进，资本与开发者关注度持续升温。但进入 2025 年之后，一个越来越明显的信号是：AI Coding 正在遇到瓶颈。需要说明的是，本文依据现有行业公开讨论与产品形态判断，不引用具体未公开数据；凡涉及趋势判断处，均标注“依据现有素材判断”。 这个瓶颈并不是“模型不会写代码”那么简单。相反，单点代码生成的质量仍在提升，真正卡住的是从“生成一段代码”到“交付一个可维护、可上线、可协作的软件系统”之间的巨大鸿沟。AI Coding 的第一阶段红利，正在被第二阶段的结构性难题取代。 瓶颈的表象：代码生成很快，工程交付很慢 1.1 生成能力的边际收益在下降 早期 AI Coding 的

当消费互联网的数据红利逐渐见顶，工业领域沉淀数十年的设备数据、工艺参数、质量记录与供应链信息，正被重新定义为一种关键生产要素。工业数据要素的价值释放，不是简单的“上云”或“建平台”，而是一场涉及确权、流通、定价与安全治理的系统性变革。本文从资源化、资产化、资本化三个维度，拆解工业数据要素的现实困境与可行路径。 资源化：工业数据为什么“多而不值钱” 1.1 工业数据的独特性，决定了它不能照搬消费数据经验 讨论工业数据要素，首先要承认一个基本事实：工业数据与消费互联网数据在结构上存在本质差异。 消费数据大多围绕“人”的行为展开，采集成本低、标准化程度高、复用场景广，一次采集可以在推荐、广告、风控等多个场景反复变现。工业数据则围绕“物”和“过程”展开，来源包括 PLC、SCADA、DCS、MES、ERP、传感器、机器

几乎所有企业都在讲同一个故事：把 AI 接进工作流，让人从重复劳动里解放出来。会议纪要自动生成、代码自动补全、客服自动应答、报表自动汇总——工具清单越拉越长，效率承诺越喊越响。但一个反常识的现象正在浮现：不少一线员工发现，AI 用得越多，自己反而越忙。忙什么？忙着校对、忙着返工、忙着给 AI 擦屁股，忙着在“人机协作”的新流程里重新学会怎么工作。 这篇文章想讨论的不是“AI 有没有用”，而是一个更具体的问题：当 AI 被塞进组织流程，效率红利到底流向了谁，成本又被转移到了谁身上。需要说明的是，本文依据现有行业观察与公开讨论中的普遍现象展开分析，未引用具体企业调研数据；凡涉及判断的部分，均为基于现有素材的推演，而非实证结论。 效率的错觉：被省下的时间，去了哪里 1. 单点提速，整体变慢 AI 最擅长的是“单点任务

数据采集能力的提升，让企业第一次拥有了“真实世界”的规模。但采集只是起点，真正决定模型效果与迭代速度的，是这些原始数据能否被稳定、可复现地加工成训练资产。本文从工程视角讨论 Serverless Spark 在这一环节中的位置与价值。需要说明的是，本文未引用具体产品版本、性能数据或第三方评测结论，涉及判断的部分均标注为“依据现有素材判断”。 真实采集的悖论：数据越多，训练越难 过去两年，数据的重要性被反复强调。多模态、长上下文、行业垂直模型，几乎每一条技术路线都指向同一个前提：要有足够多、足够真实的采集数据。于是企业开始大规模建设采集链路——日志、埋点、传感器、业务系统导出、公开语料、人工标注结果，数据源从几个扩展到几十个甚至上百个。 但很多团队在推进一段时间后会遇到一个反直觉的问题：数据量上去了，训练却并没有

具身智能（Embodied AI）正在从实验室走向产业一线。机器人要在真实物理世界中感知、决策、行动，背后依赖的是海量多模态数据的采集、清洗、标注与训练闭环。然而，当一家具身智能企业每天面对的是数十路摄像头、激光雷达、力觉传感器产生的 TB 级异构数据时，传统的数据处理架构往往捉襟见肘。Serverless Spark 作为一种“按需弹性、免运维”的大数据处理范式，正在被越来越多的团队视为具身智能数据平台的候选底座。本文尝试从媒体视角，梳理这一组合的技术逻辑、现实挑战与演进方向。 具身智能的数据困境：为什么传统架构开始“跑不动” 1.1 具身智能数据的三个特殊性 要理解 Serverless Spark 为何与具身智能产生关联，首先要理解具身智能数据的特殊性。依据行业公开的技术讨论，具身智能的数据处理至少面临三

人工智能的进步很大程度上建立在“数据喂养”的范式之上：海量文本、图片、视频被采集、清洗、标注，再送入模型训练。这套逻辑在语言模型和视觉识别领域屡试不爽，也让“数据是新时代的石油”成为行业共识。但当人工智能从屏幕里的对话助手，走向能够行走、抓取、操作物理世界的具身智能时，这套沿用已久的数据生产体系正面临根本性挑战。具身智能所需要的数据，与分析式AI所需要的数据，在来源、结构、标注方式和获取成本上都不再是同一回事。理解这一差异，是理解具身智能产业化难点的关键入口。 从“读世界”到“动世界”：数据需求的根本转向 分析式AI的数据逻辑：静态、海量、可复制 传统分析式AI，无论是自然语言处理还是计算机视觉，其数据生产基本遵循一条清晰的流水线：先有互联网上的海量存量数据，再通过人工或半自动方式完成标注，最后形成可复用的数据

RISC-V 更多出现在学术论文、开源社区和芯片创业公司的路演材料里。它被视为一种“有潜力”的指令集架构，却很少被当作可以规模化出货、可以支撑商业回报的主流选择。如今，这一叙事正在发生变化。依据现有素材判断，RISC-V 产业正处在一个明显的窗口期：一边是早期孵化阶段积累的技术、生态和人才开始外溢，另一边是资本、并购与产业整合的信号逐渐增强。换句话说，RISC-V 正在从“讲可能性”的阶段，走向“拼落地、拼资本、拼产业协同”的阶段。 这篇文章不试图给出精确的市场规模数字，也不虚构具体交易和产品版本。我们只基于一个核心判断展开：RISC-V 的产业逻辑正在切换，而这种切换对创业者、投资人和大厂战略部门都意味着不同的动作。 早期孵化的红利正在见顶，RISC-V 进入“证明自己”的阶段 RISC-V 的早期阶段有几个

大模型竞争进入下半场，讨论焦点正在从“谁有更多 GPU”转向“谁能用更低的成本、更稳的时延把推理跑起来”。算力依然是底座，但决定商业成败的，越来越是推理侧的系统效率。本文尝试从产业与工程双重视角，梳理 AI 算力与大模型推理之间的真实关系、关键瓶颈与演进方向。需要说明的是，本文未引用具体厂商数据与版本信息，涉及趋势判断处均标注为“依据现有素材判断”。 算力不是终点：推理正在成为大模型成本结构的重心 过去两年，行业对 AI 算力的想象几乎等同于“训练”。训练一个基础大模型需要成千上万张加速卡、数月连续运行、巨量电力与机房资源，这些叙事塑造了公众对 AI 算力的第一印象。但当模型开始走向规模化应用，真正持续消耗算力的环节其实是推理——每一次对话、每一次代码补全、每一次文档摘要，背后都是一次或多次前向计算。 这一转变

RISC-V 从学术圈与嵌入式领域一路走向数据中心、汽车电子和 AI 加速器，讨论的焦点往往集中在指令集本身：它开放、精简、可扩展。但当产业真正开始把 RISC-V 芯片推向规模化落地时，一个更“中间层”的问题浮出水面——软件如何稳定、可移植、可维护地跑在形态各异的 RISC-V 硬件上？这正是软硬件之间“翻译官”的角色所在。本文尝试从媒体视角，梳理这一层开放接口的价值、现状与挑战。需要说明的是，本文依据现有公开认知与行业通行框架展开，未引用具体厂商数据与版本细节；涉及具体实现的部分，依据现有素材判断，仅作方向性讨论。 为什么 RISC-V 需要一个“翻译官” 1.1 开放指令集带来的“碎片化红利”与“碎片化成本” RISC-V 的核心吸引力在于开放与可扩展。任何人都可以基于基础指令集裁剪、扩展，针对特定负载做

数据基础设施的关键词是“存得下、算得快、管得住”。而当大模型成为企业技术栈的常客，评价一套数据基础设施是否合格的标准正在被重写：它不仅要服务人和报表，还要服务模型；不仅要支撑确定性的 SQL 查询，还要支撑高吞吐的向量检索、多模态读取和持续的数据供给。于是，“AI-Ready Data Infra”成为一个被频繁提及的概念。 需要说明的是，本文依据现有素材与行业公开的通用认知展开讨论，不涉及具体厂商的产品版本、性能数据和实测结论。凡涉及具体实现细节之处，均以“依据现有素材判断”标注，供读者作为分析框架而非事实引用。 什么是 AI-Ready Data Infra：从“支撑业务”到“支撑模型” 1.1 概念边界 AI-Ready Data Infra 并不是一个全新的产品品类，而是一组能力要求的集合。它描述的是这

企业技术团队最常讨论的问题之一，是“如何把大模型接进现有系统”。而到了今天，问题正在变成另一个更根本的版本：现有系统本身，是否已经为 AI 做好了准备？ “AI-Ready”并不是一个营销词汇，它指向一组可以被工程化拆解的能力：数据能否被机器理解、模态能否被统一调度、算力能否被弹性编排、应用能否被快速组装、治理能否覆盖全链路。把这些能力收拢到一个平台上，就是“全模态数智平台”要解决的问题。 需要说明的是，本文基于行业公开的技术趋势与通用工程实践展开讨论，未引用具体厂商的产品版本、性能数据或第三方评测结论。凡涉及具体实现细节的判断，均属于依据现有素材与公开技术常识的推演，落地时仍需以实际环境验证为准。 什么是 AI-Ready：从“能接入”到“可规模化”的五道门槛 很多团队对 AI 的准备程度，停留在“模型能调通

AI 编程工具正在从“补全一行代码”走向“替你查一次线上状态”。当 Agent 需要读取真实实例信息时，能力边界与授权边界必须同时被重新定义。依据现有素材判断，这一方向已被明确提出，但具体产品形态、版本节奏与实现细节尚待补充。 从“写代码”到“看现场”：AI 编程工具的能力外延 过去两年，AI 编程工具的主战场集中在代码生成与补全：根据上下文续写函数、解释报错、生成单元测试。这类能力的共同点是——它们几乎都发生在“静态文本”层面，模型看到的是仓库里的代码、终端里的日志、开发者粘贴进来的片段。 但当工具被冠以 Agent 之名，评价标准就变了。Agent 的核心不是“生成”，而是“闭环”：它需要感知环境、做出判断、执行动作、验证结果。而在真实的研发与运维场景中，最关键的感知对象往往不在代码仓库里，而在运行中的实例

当企业的基础设施从几台服务器扩展到成百上千个实例，从单一集群扩展到跨云、跨地域、跨业务线的复杂环境时，运维团队面临的挑战已经不再是“如何把一台机器管好”，而是“如何把成百上千个实例作为一个整体来治理”。这正是平台化管理要解决的核心命题。本文从运维模式的演进逻辑出发，讨论企业为何必须从单个实例运维转向平台化管理，平台化管控需要具备哪些关键能力，以及在落地过程中需要规避哪些典型误区。 单实例运维的天花板：为什么“管得好一台”不等于“管得好一千台” 1.1 单实例运维的典型特征 在企业发展早期，基础设施规模有限，运维工作往往围绕单个实例展开：登录某台服务器排查问题、为某个集群单独配置监控、针对某个业务线手工调整参数。这种模式的特点是“点对点”——运维人员对每一个实例都有直接的、具体的掌控感，问题定位路径短，响应速度快

在今天的应用开发语境里，“前端”与“后端”的边界正在被重新定义。越来越多的团队不再从零搭建服务器、数据库和鉴权体系，而是把数据存储、用户管理、文件处理这些“通用但繁琐”的能力交给专门的后端平台。Supabase 就是这一趋势中颇具代表性的产品：它为需要保存数据、管理用户和处理文件的应用提供后端支撑。本文尝试从媒体视角，讨论这类后端支撑的价值、边界与选型逻辑。需要说明的是，本文未引用具体版本号、性能数据或第三方评测，凡涉及产品细节之处，均以“依据现有素材判断”为限，不做过度延伸。 应用开发的分层现实：为什么“后端支撑”成为独立议题 1.1 通用能力与业务能力的分离 任何一个稍具规模的应用，几乎都绕不开三类基础能力：数据的持久化保存、用户身份的识别与管理、文件等非结构化内容的存储与分发。这三类能力有一个共同特征——

企业对 AI 的期待经历了一轮明显的“祛魅—再校准”。最初，很多人把大模型当成一个更聪明的搜索框：问一句，答一句，能写文案、能改代码、能解释概念，就已经足够惊艳。但当 AI 走进企业的经营场景，问题立刻变得具体而尖锐——它能不能读懂我数据库里的订单和库存？能不能在每天早上九点前，把昨天各区域的销售异常整理成一页快报？能不能在老板追问“为什么华东掉了”时，给出可追溯的分析路径，而不是一段听起来合理却无法验证的文字？ 这些问题的共同指向，是 AI 从“对话工具”向“分析参与者”的角色迁移。而这条迁移路径上，有两个关键节点：智能问数与经营快报。前者解决“人找数”的效率问题，后者解决“数找人”的主动性问题。把这两步走通，AI 才算真正进入了企业的日常分析循环。 智能问数：把“取数”从几天缩短到几句话 传统取数链路的真实

企业对大模型的关注从“能不能用”迅速转向“怎么用出价值”。但当项目真正进入生产环境，卡住进度的往往不是模型能力，而是数据与业务之间那道看不见的墙。本文从落地视角出发，讨论企业 AI 为何必须先解决数据与业务的连接问题，以及这件事在组织、流程与技术层面的现实路径。 模型不是瓶颈，数据与业务之间的“断层”才是 在企业内部推动 AI 项目的人，大多经历过相似的场景：算法团队拿到了一个效果不错的模型，业务部门也认可方向，但项目推进到一半就停住了。原因很少是模型不够强，而是数据拿不到、拿到的数据业务看不懂、看懂的数据又和真实决策流程对不上。 这道“断层”通常体现在三个层面。 第一层是数据可得性。 企业数据分散在 ERP、CRM、业务中台、日志系统、文档库乃至个人电脑里，格式不统一、口径不一致、权限边界复杂。算法团队需要的

企业对大模型的关注点从“能不能用”迅速转向“怎么用好”。当试点项目逐渐走向生产系统，一个共识正在形成：决定 Agent 应用成败的，往往不是模型本身，而是模型背后那套数据治理体系。本文尝试梳理从数据治理到 Agent 应用的演进逻辑，讨论企业在这一过程中需要回答的关键问题。需要说明的是，本文为趋势分析类文章，依据现有行业观察与公开技术常识展开判断，不涉及具体厂商产品版本与未公开数据。 为什么 Agent 应用把数据治理重新推到了台前 1. 从“问答”到“执行”，数据质量的要求被放大 早期的大模型应用大多停留在问答和内容生成层面，用户对答案的容错度相对较高。而 Agent 应用的核心特征是“自主规划 + 工具调用 + 多步执行”，它要读取企业系统里的真实数据、调用 API、触发业务流程。一旦进入执行环节，数据错误

当企业谈论 AI 基础设施时，话题往往集中在算力上：GPU 型号、卡数、集群规模、峰值 FLOPS。这些指标直观、易比较，也方便写进采购清单。但在真实的大模型训练与推理场景中，一个越来越清晰的共识是：算力只是整条链路的起点，真正决定 AI 负载效率的，是从存储、网络、内存到计算单元之间那条完整的数据通路。任何一段出现瓶颈，整条链路的吞吐都会被拖慢。AI 负载需要的不是某一个环节的极致参数，而是端到端的数据通路优化。 算力叙事之外：AI 负载的真实瓶颈在数据通路上 算力增长与数据供给之间的剪刀差 过去几年，AI 模型的参数规模持续攀升，训练与推理对算力的需求呈数量级增长。与之相对，数据从存储介质搬运到计算单元所经过的路径，其带宽和延迟改善速度并没有同步跟上。这种“算力增长快、数据供给慢”的剪刀差，是当前 AI 基

当企业数据栈从“单一引擎+单一存储”走向“多引擎共享一份数据”，真正的难点已经不在功能清单，而在三件事——协议之间如何共存、元数据如何组织、计算如何靠近数据。本文从设计思路层面拆解这三条主线，讨论它们各自的取舍与相互牵制。 多协议融合：从“各建一套”到“共享一份数据” 1.1 问题的起点：协议割裂带来的重复建设 企业数据平台的典型演进路径，往往是按场景分别选型：批处理用一套文件格式与表格式，流式用另一套，点查与检索再引入一套，机器学习特征与向量检索又各自独立。每一套系统内部都自洽，但系统之间靠“导出—导入”连接，于是同一份业务事实被复制成多份副本，随之而来的是存储成本、同步延迟、口径不一致和权限体系的碎片化。 多协议融合要解决的正是这个问题：让不同计算引擎、不同访问模式能够面向同一份底层数据工作，而不是各自维护