埃隆・马斯克:特斯拉重启的Dojo3将用于 “天基AI计算”

xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。


在生成式 AI 重构数据生产力的时代,BI 工具正从"被动响应"走向"主动洞察"。在 2025 年 4 月 InfoQ 举办的QCon 全球软件开发大会(北京站)上,阿里云智能集团瓴羊高级技术专家王璟尧分享了“从数据到决策:AI 驱动的 Quick BI 架构设计与实践”,他介绍了阿里云 Quick BI 如何通过技术架构跃迁、结合大模型的突破实现从传统 BI 到 AI 驱动的智能 BI 的跨越式进化。并重点解析领域大模型与 BI 引擎的协同设计、NL2SQL 算法调优与架构演进、AI + BI 在场景落地实践过程中的技术权衡,为行业提供可复用的技术范式。 预告:将于 4 月 16 - 18 召开的 QCon 北京站策划了「AI 重塑数据生产与消费」专题,将深入探讨如何系统化地运用大模型与智能体技术,重塑数据全链路的每一个环节。内容涵盖引擎与架构优化、数据治理、开发与运维提效、下一代 BI 与数据工具,以及智能的取数与分析等多个方向。如果你也有相关方向案例想要分享,欢迎提交。 以下是演讲实录(经 InfoQ 进行不改变原意的编辑整理)。 早期 BI 是在数据仓库和数据库不断发展演进后形成的需求场景:数据仓库会将各类数据融合到一起进行数据清洗和分析,随后业务人员对自助分析产生了一系列诉求,早期的 BI 工具便应运而生,像 90 年代的 Business Object 就是一个比较有代表性的例子,具有一定限度的自助式分析能力。当时其实还没有“商业智能”这一概念,随着自助分析能力要求的不断提高,可视化、自助式可交互的分析需求也越来越强烈,于是敏捷 BI 应运而生:基于可视化的自助式、可交互的分析,以 Tableau/Qlik 为代表,其最大特点是可通过拖拉拽、按钮点击等简单操作就能完成报表的搭建工作。 进入大模型时代,大模型强大的语言分析和生成能力以及更接近人类思维的推理方式,让 BI 领域进行了重新定位:即从一个单纯的工具到数字助手的进化,模型能力的突破让正在的商业“智能”可以从 DEMO 和实验室走向实际应用。Quick BI 也在各类大模型技术发展的时代洪流中逐步演进,不断成熟与发展,实践落地智能小 Q 系列,给用户带来全新的、端到端到产品体验。 传统数据分析存在局限性,它几乎主要聚焦于报表平台的工作流程:业务方提出需求,产研团队加工执行,然后制作简单的报表,以辅助管理仪表板。传统数据分析主要面向一线业务和老板,工具即使再敏捷,交付物本质上也是以固定式报表作为承载。尽管敏捷 BI 的诞生缓解了部分问题,但业务团队和数据团队之间难以融合贯通的问题依然无法避免。而在 AIGC 时代,大模型加持的对话式分析可以对自然语言灵活响应,简单、自动地完成需求,或许“人人都是数据消费者”及“数据民主化”不再仅仅是一句口号了。 基于用户的实际需求和大模型 Agent 技术发展,我们对大模型驱动的业务落地演进方向做了大致判断。从执行到思考,从智能到智慧,难度系数逐步增加。大模型刚出现的初期,大家都在做 Copilot(即搭建助手):用户通过 Copilot 用简单指令或描述就能辅助搭建报表,从而降低 BI 工具的使用门槛和成本。然后是 Chat BI,理论上它会改变整个分析流程,用户像和人类对话一样向系统提问,由系统即时理解并返回准确的分析结果,所有人都可以随时随地的获取数据,降低传统 BI 报表和仪表板出现的必要性。 再接着是洞察分析:基于数据、业务知识,利用机器学习算法、数据挖掘技术的融合,叠加上大模型的语言理解和推理能力,让使用传统算法的洞察分析脱胎换骨,实现更精准的总结、诊断、归因,能够自动发现数据中隐藏的价值。第四阶段可能还为时过早,很多厂商将其称为 DI(即决策智能 Decision Intelligence)。 随着数据量爆炸式增长和分析技术进步,如多模态、多元信息整合、多 Agent 技术等,我们可能不再满足于单个功能,产品形态会演变成分析平台主动在海量数据中发现价值,通过完整数据报告或主动 Feeds 流方式推送给我,不仅能给出“发生了什么”,还能进一步解释 “为什么会发生”、“未来会怎么样”,为用户提供更高阶的决策支持,这是也许是目前能看得到的数据分析领域的理想态。 基于对业务落地的判断,企业级智能 BI 分析离不开 BI 工具、大模型和企业私域知识这三者的有效融合。首先,BI 工具作为核心框架,凭借强大的数据分析和可视化能力,将规模庞大和复杂的数据转化为直观易懂的图文报表,为企业搭建洞察业务的桥梁。要最大化的发挥 BI 工具本身的作用,如高性能分析引擎、可视化、安全管控、开放集成能力、协调办公能力等。其次,BI 工具并非孤立的存在,大语言模型的加入为其注入了灵魂,通过大模型理解自然语言指令,精准理解用户意图,大大降低数据分析门槛。此外,随着多模态、multi-agent 等技术的成熟,大模型的记忆、推理、规划、反思、工具使用能力反过来推动大模型在各领域的丰富应用,包括数据分析产品。最后,绝大部分企业级的智能数据应用都离不开私域数据,作为大模型应用的根据,只有将企业数据、企业内部知识、行业知识深度整合,才能让 BI 分析更具针对性和业务价值。 Quick BI 是阿里云上的一款 SaaS 的 BI 产品,连续 6 年入选 Gartner 的商业智能和数据分析魔力象限,也连续 6 年作为国内唯一入选榜单的国产 BI 产品,承载其智能化能力的产品叫智能小 Q。 在大模型时代,有句话说得非常到位:所有产品都值得用大模型技术重做一遍,BI 产品也不例外。传统的 BI 产品,其分析流程在模式上相对比较固定,从数据到结果,基本要经历从数据连接、到数据建模、到数据分析、到数据可视化、再到数据协同和消费的整个流程。这个流程离不开业务人员的人工搭建操作,对用户的模型理解和配置技能有较高要求。而在大模型时代,这个流程的每一个环节都有可能被重塑。例如,在数据连接环节,我们可以对数据准备的 ETL 任务进行辅助开发,对连接的数据源进行数据探查和校验;在建模上,可以对字段质量进行评估,实现计算字段生成优化和 SQL 诊断;在数据分析阶段,对报表一键美化、洞察归因和自然语言生成报表;在消费端,有 Chat BI 智能问数;最终的消费态则可以有智能决策和数据解读报告这样的形态。当我们打开思维去尝试探索后会发现,这里面的发挥空间会非常大。 BI Copilot 的具体形式就是智能搭建。分析师在原有搭建报表的流程时,用自然语言替代繁杂的功能寻找、拖拉拽按钮和配置,直接完成用户想要的操作。在这个领域,我们更多瞄准的是那些高频多步的、或者强依赖分析师经验的功能。例如: 金额大于 3000 的标红 - 就是个典型的条件格式场景; 帮我美化下这个报表 …… 从技术流程图可以看出,我们将原本强耦合在底层产品内部的一些能力做了解耦和开放,在渲染引擎、搭建引擎和用户会话之间构建了一整套指令系统和前端 API 层。大模型作为稳定的“中介”,负责对接会话层和指令系统,将用户自然语言意图转换成底层引擎能识别的“API”指令。在这个部分,我们基于基座模型微调了适合 QBI 搭建的增强指令识别系统,即带有指令 CMD 和参数 Params 的 NL2API。初级 API 进过指令系统的复杂处理,如依赖检测、指令调度、执行等,最终会调用暴露出来的 API 层,最终在渲染引擎和搭建引擎的加持下,完成一整套动作。不过,在这层面上 NL2API 系统相对封闭,因为大模型本质上主要是为 Quick BI 或自身应用系统内部业务服务的。 BI copilot 的另一个重要应用是数据洞察。用户对洞察的期望通常是:看懂图表 ->补充信息 ->分析和解释数据现象 ->定位问题 ->支撑行动决策。这几个步骤里,任意一个步骤想要做好都需要天时地利人和的:算法够优秀、支撑数据够多、流程组织够清晰。 目前我们在洞察领域做了如下三方面的探索: 一是 内置洞察算法,这部分主要使用经典统计计算模型,毕竟智能化并不能完全等于大模型。例如,关注指标变动是否正常,若不正常,是哪些维度造成异常,本质上是参考历史数据、行业经验及其他关联数据,寻找对业务目标最具解释力的维度,这就是内置洞察算法。 二是 大模型的洞察解读,将报表数据和背后所在数据集的数据以及配置元数据等信息组合,利用通用模型在数据解读、语义理解等方面的优势,通过 Prompt 工程 +Multi-Agent 的方式完成的解读方式。 第三,QuickBI 具备外置 Agent 接入能力(如 Dify 或百炼等),让客户特定的工作流和业务逻辑对接到小 Q 对话流里。作为一款通用工具型产品,一定没法满足所有用户的个性化定开需求,这算是一种体验很好的曲线救国方式。 在当今的商业智能(BI)领域,Chat BI 这一概念正逐渐成为焦点。Quick BI 已经成功落地了智能问数这一场景,这在国内国际都引起了众多企业的浓厚兴趣。目前,众多厂商的 Chat BI 产品都在致力于实现类似的功能,技术路线也呈现出多样化,如 NL2DSL(自然语言到领域特定语言)、NL2Python、NL2SQL 等,可谓是百家争鸣。 以 QuickBI 的智能问数为例,一个智能问数的用户旅程大致如下:用户首先输入一个问题,系统在前置处理阶段会进行权限管控和流量管理等操作。随后,我们利用经过训练的大模型领域模型对问题意图进行判断。如果该任务需要多步才能完成,系统会将其拆分为多个子任务;若单步即可返回结果,则直接进入核心流程。通过一系列召回算法,我们将元数据、知识库等信息组合起来,输入到大模型中。最终,大模型以 DSL 和 SQL 的形式将结果传递给 BI 底层的查询引擎。查询引擎负责方言翻译、高级计算下推等复杂流程,并最终以图表形式呈现结果。这些图表在呈现过程中仍然可以进行交互和调整。整个流程的关键在于,我们能够清晰地梳理从上到下的所有字段血缘关系。 在通用大模型与自研领域模型的流程设计中,我们秉持着开放的态度。本质上,用户的自然语言通过大模型转换为代码,代码再通过我们工程内部的方式转化为技术逻辑,最终在产品中体现为具体的展现形式。BI Agent(在某些场合被称为 AI 中间层),它通过组织编排各种大模型的输出和流程代码,实现自然语言与代码的有效连接。BI Agent 会定义一些 API 和 DSL,为了让模型能够与应用系统有效交互,我们正在通过 MCP 的方式将其能力开放。 BI Agent 与中间层的控制中心配合,经过业务上下文处理、意图识别、任务拆分等步骤,使 BI 系统能够理解模型的返回结果,并据此进行进一步的操作。此外,在处理复杂任务时,我们还会按照正确的顺序执行编排的子任务,确保任务的成功完成。举个例子,需要获取“X 部门的经营分析报告”,LLM 本身是不会直接总结的,它需要调用取数工具先获取每个月的销量情况,再基于各种拆解数据做归纳分析,这里的“取数工具”就作为最原子化的 BI Agent 存在。 在设计工程架构的最初阶段,我们在最初阶段经历了诸多纠结与讨论。我们曾反复思量,是要打造一个代码助手,还是 SQL 插件,又或是增强版的 BI 工具呢?无论最终选择何种形态,技术路径的抉择都必须着重考量几个关键问题。首先,该系统是否具备企业级的特性。这关乎到权限管理、租户隔离等诸多方面,以及它能否与现有的业务场景无缝兼容。其次,系统的前端界面是否交互便捷、易于使用,这至关重要。再者,系统是否拥有开放集成的能力,能否提供 API 接口,是否能够嵌入到自有系统,或是接入自有知识库和数据源。此外,多场景的适应性也不容忽视。在早期,我们发现许多开源的 Demo 项目,它们仅用几行代码就跑起来一个 Chat BI,虽在特定场景下效果显著,但难以在企业级的真实场景中落地应用。最后,系统的未来拓展性也是必须考量的因素之一。 下图展示了智能小 Q 的整体技术架构。从图中可以清晰地看到,智能小 Q 从上至下依次为应用层、AI 中间层、自研领域大模型和通用模型层,以及 BI 基座引擎层。AI 中间层处于上层应用与大模型之间,主要承担任务分发与协同的职责。我们通过构建 API 和 DSL,实现了 Agent 与算子的有效对接,让大模型应用更具确定性,避免以前通过自然语言输入的应用表达不稳定,使得在 BI 领域的大模型的应用编程变成确定性应用编程。作为支撑小 Q 的关键部分,基座的 BI 引擎确保了数据分析的强复用性。分析引擎涵盖了从数据连接建模到复杂分析的全方位能力,而渲染引擎则承载着图表可视化及交互的重任。整套系统都是在 Quick BI 已有的能力基座上进行开发的。 在自研模型的 SQL 语义生成技术路线上,目前 主流的有两种方式:Text to SQL 和 Text to DSL。我们对这两种技术路线进行了长期且深入的对比分析。Text to SQL 是直接将文本转换为 SQL 语句,直接在物理数据源上进行查询;而 Text to DSL 则是先经过一层抽象的语法,再分发到数据源进行查询。从业务特性来看,Text to SQL 在门槛较低的情况下,能够充分利用大模型的泛化能力,简化数据分析过程。然而,它也存在一些局限性。由于缺乏数据模型的抽象定义,直接对标物理表,使得大模型生成 SQL 的过程变得异常复杂。 此外,大模型不可能被训练去了解市面上众多数据源的方言。以 Quick BI 为例,它支持四五十种方言,如果要对私域数据进行私有模型训练,成本将难以控制。而且,即使是同一数据源的不同版本,如 MySQL 5.7 和 8.0,它们支持的函数也有差异(如开窗函数),这对大模型来说并不友好。从技术限制角度而言,DSL 的灵活性相对较弱,其查询能力受限于 BI 引擎的能力边界。从适用场景来看,Text to SQL 更适合门槛较低、没有复杂业务分析要求的场景;而 Text to DSL 则更适合业务场景明确、面向大型团队和企业级应用的场景。对于 QuickBI 来说,技术路线从纯 Text to DSL 到 Text to SQL to DSL,再到混合模式,可谓是吸收各个路线的优势。 我们从工程链路的角度剖析一下问数。用户问了一个相对复杂的问题后,经过模型的复杂链路处理,包括 Agent 路由、各种实体召回,由自研 BI 大模型生成 DSL,经由工程端的查询参数构造后,发给查询引擎进行取数。查询分析引擎会处理复杂计算字段(如 LOD 函数、自定义抽象函数)、注入用户的行列权限等,最终翻译成物理 SQL 和内存计算进行取数处理。从下图的例子可以看到,相对抽象的 LOD 函数会被稳定转义成适配不同数据源方言的 JOIN, 大大降低了模型生成 SQL 的难度和稳定性。在这种工程架构下,可以解决传统 NL2SQL 面临的三大关键问题:1)保证可用,具备企业级的管控能力,如完备的权限能力、开放集成能力等;2)保证可信,BI 引擎的引入降低模型生成原生 SQL 的难度,对取数的每个链路都做到逻辑有迹可循,查询元数据血缘透出,提升结果的可信度;3)结果可交互,复用了 BI 丰富的可视化能力,在生成的图表后链路上可修改并进行二次查询。 与通用模型处理的其他类型问题相比,NL2SQL 算法领域面临的挑战主要集中在以下三个部分: 语义的模糊到精确:自然语言天然是非精确的,同样一个意图可以有多种不同方式的表达,而 SQL 代码及执行是精确的,用户对结果的正确性的容忍度非常低。因此 NL2SQL 天然属于模糊到精确的多对多映射问题。 语言结构化:SQL 是“结构化查询语言”,而对比与 Python/C++ 等其他编程语言是过程化的语言。这里有什么区别呢?过程化语言可以做片段化的逻辑生成,对模型推理的要求偏低,但结构化语言需要结构和逻辑整体正确,难度相对大些。 在问数任务的绝大部分场景下,用户的问题只提供了信息的局部,只是回答信息必须上下文的很少一部分。有更多信息以企业内部约定俗称、表元数据的简称、数据的具体内容形式存在。这点相信在这个领域的各位应该也有比较深刻的体会。事实上,有大量的 Query 之外的“隐藏信息”需要补全,而这又无形中对系统的配套设施提出了更高要求。 我们在训练模型前,对要达到的效果做了定义和预演。即什么样的数据分析助手是“好”的助手? 首先在风格和调性上来说,主要有以下几点: 有效性,模型必须保证准确和稳定,即单位 token 的有效信息密度高,不啰嗦; 准确性,在最小可用的数据和关联拓展之间做一个平衡。用户问数往往是看一系列数据,不是单个数据,我们会在某些场景下主动给一些关联数据,实践下来带来会给用户一些“小惊喜”; 在复杂任务上的表现,过程中逐步规划、反馈,通过多个简单任务组合解决复杂任务。当然,这里如何拆分子任务、子任务的粒度也是另外一个较大的话题了(过于原子化和过于抽象都是有问题的)。 其次对于大模型能力,主要有以下几点: 基础能力稳定性高:在问数基础、高频场景下需要稳定且高准确度的表现,避免过多的过程性解释; 在数据分析场景下的专业性:模型训练能够对数据分析师、业务常用的分析思路有理解,能给出专业的数据建议。比如用户问单个指标的时候,同时看一下指标趋势也没有坏处; 规划、矫正能力:具备将复杂任务拆解为用户易于理解。易于干预的子任务,能根据不同的上下文、用户提示,矫正复杂任务的执行规划。 从算法的视角来重新看问数的链路:大模型在生成抽象 SQL/DSL 的过程中,经历了元数据选取、上下文添加、问题改写、完整 Prompt 构建、输出、转译等步骤。。这其中最重要的一步就是领域模型的训练,领域模型训练需要足够的信息来进行正确推理,这些信息主要包括任务描述和通识能力,例如大模型不知道今天是哪天,我们需要将当前时间戳加入其中。其次是表和字段信息,这是非常关键的,如果没有表的字段信息和维度枚举值,对于 NL2SQL 来说将是一场灾难。再者是私域知识库,相关的知识条目以及是否做强制改写等,都会给大模型提供启发。另外,参考样例也很重要,什么是好、什么是坏的,我们在产品上通过点赞、点踩等方式给大模型提供真实的 few-shot 示例。经过各种选表问题改写 SQL 等流程后,最终生成的 Prompt 会交给领域模型完成推理。 前面有讲到,最初我们定义了特定的查询语言 DSL, 用于表达对于不同查询参数的描述,由大模型直接学习并生成 DSL,再通过中间层将抽象的 DSL 在元数据和知识库的召回后实例化,转换成实际 QBI 的查询参数执行真实的取数;这里的几个好处,比如 SQL 方言屏蔽、高级计算能力复用等等。但随着支持的问数能力越来越多,问数的意图千变万化,要准备这套 DSL 语义的样本成本在逐渐增大,毕竟 DSL 是我们自定义的,通用模型训练并不含这部分内容。同时,各类通用基座模型本身对意图转简单 SQL 确是有大量积累的。于是我们在单表查询的标准 SQL 基础上拓展了抽象函数和高级计算符,变成增强 SQL 语言,以训练基座模型对于增强 SQL 的生成来提升对复杂意图的理解准确度,然后通过自研语法解析器来改写成 DSL 映射。也就是说,增强 SQL 和 DSL 是可以稳定转换的。这样既能巧妙利用通用模型的能力,又能大大降低训练样本的准备成本。至此,复杂查询意图到取数流程就被串联起来了。 对于上述架构的最终选择,有两个重要因素支撑才能成立。第一个是丰富的算子和函数,得益于 Quick BI 内置大量逻辑函数,如聚合数值处理、文本处理,以及 LOD 函数、时间算子等。例如,计算环比对于 SQL 来说可能很复杂,我们会将大量复杂分析场景定义封装在这些算子和函数里,大模型在生成增强 SQL 时不需要感知这些复杂内容,它只需要知道如何使用这些算子和函数即可,这有点像现在流行的 Agent 方式。第二个是完善的数据模型,我们作为 BI 系统本身就支持很多关联模型,包括自定义 SQL 模型,如单表星形、雪花星系等经典 BI OLAP 模型。实际上,我们会将复杂的多表关联合并和嵌套查询下推到数据建模层,这些信息对大模型来说是透明的。大模型不需要感知这些,因为 Chat BI 不仅仅是 NL2SQL 算法的炫技,更重要的是解决实际客户的问题。有时我们会将复杂建模放在前面,对于整个大模型来说,它只是一个单表的、带有各种复杂函数的 SQL 生成逻辑。 另一个重要的计算逻辑是多步计算。多步计算是为了解决一些纯 NL2SQL 无法处理的问题,转而通过 NL2Python,或者说 NL2Python Agent 的方式来解决。举个简单例子,询问销售金额日环比超过 40% 的用户有哪些?我们可能只能算日环比,超过 40% 对于人来说很简单,但实际上这是一个多步计算的解决方案。在这个流程中,大模型会进行多次推理,这里的 Python Agent 会触发大模型在当前输入上进行二次推理。通过合理的任务拆解,可以降低整个复杂问题的解决难度。 此外,关于领域模型的训练,我们这边的训练主要分为三个部分:继续预训练、微调和 GRPO。简单来说,在预训练阶段,我们会把 Query 质量不高但有大量抽象 SQL 的东西作为预训练的一部分。在微调阶段,我们会把高质量的 query 和 SQL 对应关系放到微调中进行训练。最终通过强化学习 GRPO 的方式把整个模型训练好。 大模型是离不开好数据的,只有大量 + 优质的训练数据加持,模型才有可能突破。下图是我们数据准备的一个数据飞轮: 一方面我们依赖了人工构造,我们有一只专门的数据团队去构造、收集复杂的训练数据。其次,利用模版、AI 去生成,各类大小模型的结合提升训练数据的质量和覆盖。然后是数据蒸馏,对一些复杂问题,我们会通过大模型训练小模型的方式。与此同时,我们还会在数据准备过程中利用若模型生成一些有价值的错误,这些样本随后可以在执行引擎的协助下执行验证并进行错误归纳,相当于反例的标注,这对于训练非常有必要。我们实践下来发现,有价值的错误在整个训练过程中是非常有必要的。 以零售品牌为例,它们直接利用我们的 SaaS 产品来推进功能演进。还有快消品客户,更是将我们的小 Q 直接嵌入到他们的业务系统中。实际上,在客户那里,我们进行了一些实践和调优工作。作为一个通用的 BI 工具,无需任何配置的前提下想要直接达到 90% 以上的准确率是不现实的。事实上,脱离具体应用场景谈准确率,多少有些不切实际。这里有一个案例,一开始我们完全没有介入时,准确率仅为 65%。通过交付过程中的介入,引导用户如何使用、如何提问,以及让用户通过点赞、点踩的方式参与,我们的模型可以自动进行 SFT。在这种场景下,最终将模型强化后的问数准确率提升到了 92%。主要提升点在于指标维度的扩充、指标覆盖等,让用户尽可能多地提供信息,针对复杂问题进行自动拆解。很多时候,客户的问题并非单纯的问数问题,比如他们可能会让你去分析一下某个情况,这就需要进行问题拆解。此外针对无法回答的问题,提供用户提示,即拒识方面的引导优化也是非常有必要的。 目前大模型擅长的包括:语义理解、代码生成、分析思路、文本生成、任务编排… 我认为大模型在以下几个方面会有长足进步,具体进步包括: 动态推理能力:包括任务拆分、逻辑推演、冲突解决; 多模态感知能力:未来可能会整合跨平台的报表数据、根据截图、报告来挖掘出更有意义的数据科学部分; 模型能力本身的持续进化、自我反思机制的增强:在整体水位线上能让智能来的更加真切; 自主决策能力:非预设路径的行动生成和决策。在更高的角度来看,随着大模型这些能力的持续进化,我相信将会推动智能 BI 从任务执行者向决策主体跨越,进而让整个领域在交互模式和能力边界上都有相应的变化。 嘉宾介绍 王璟尧,毕业于浙江大学信电系,10 年数据产品建设和技术架构经验。现任阿里云智能集团高级技术专家,Quick BI 数据智能研发负责人,负责 BI 平台架构、新一代智能 BI 建设等工作,在元数据管理、BI + AI、大模型应用等领域上有丰富经验。 会议推荐 从基础设施、推理与知识体系,到研发与交付流程,再到前端、客户端与应用体验——AI 正在以更工程化的方式进入软件生产。2026 年 QCon 全球软件开发大会(北京站)将以 「Agentic AI 时代的软件工程重塑」 作为大会核心主线,把讨论从 「AI For What」,走向真正可持续的 「Value From AI」。BI 领域的技术演进及趋势
传统 BI VS 大模型驱动 BI

大模型驱动的业务落地方向

大模型落地 QuickBl 全景
大模型重塑整个 BI 分析流程

BI Copilot


Chat BI

通用大模型与自研领域模型的混合流程设计


工程架构设计
智能小 Q 分层架构

自研模型在 SQL 语义生成的可控性
一个问数问题的工程链路

工程架构设计
NL2SQL 算法的挑战

一个问数问题的大模型旅程

基于 BI 引擎的 NL2SQL 算法演进

Text2DSL:丰富的算子和函数



大模型与好数据:训练数据准备

业务价值与展望
智能小 Q 客户实践场景

Bl 未来发展


撰稿 | 陈姚戈、高允毅 编辑 | 王一鹏 一场从线下蔓延至线上的舆论战争,正发生在伊朗。 线下,伊朗当局正在组织“反骚乱”集会;线上,断网、媒体管制和信息封锁同时发生。 在网络被关闭的时段,伊朗国营媒体几乎成为唯一的信息源。信息真空之中,大量影像只能在社交平台上传播,却很难被证实或证伪。 网民和非营利组织通过自发事实核查发现,伊朗官方发布了使用后期编辑和 AI 生成影像,刻意营造了“反骚乱”的舆论氛围。这类内容在 X 平台上获得了数万次观看。 与此同时,另一方同样出现大量 AI 生成内容。一段被广泛转发的视频显示,有人从建筑物上扯下国旗,发布者称有人撤下了伊朗国旗。这段视频经过反向图片搜索后,被证实拍摄于 2025 年 9 月尼泊尔抗议活动。 非营利组织 WITNESS“技术威胁与机遇”项目副主任 Mahsa Alimardani 指出,在传播过程中被 AI“增强画质”的现场照片,反而被当局用来否定影像本身的真实性,对抗议事实进行整体抨击。 真假在这一过程中被同时稀释,AI 让“知晓真相”这件事变得更难了。 这并非人们第一次意识到 AI 的风险。近几年,从《要求暂停更强模型训练的公开信》,到《针对超级智能的联合声明》,理想主义者反复呼吁放慢脚步、建立约束。但现实是,这些警告几乎没有改变产业的整体方向,也未能阻止更强模型和更激进应用的持续推出。 尤其是在战争中。 从俄乌冲突、以伊冲突,再到今天在伊朗发生的舆论战,包括生成式 AI 在内的技术被广泛采用,而战场也正成为前沿 AI 技术和武器的“实验场”。 《中国航空报》指出,乌克兰战事加速了 AI 在实战中的应用落地,如自主导航、目标识别和交战以及情报处理等。根据《青年参考》,大量军事科技初创企业和国防创新企业在乌克兰聚集,使乌克兰逐渐演变为相关技术的重要孵化地。 更深层的变化在于,科技公司、金融资本与国家战争机器之间,正在形成紧密绑定。 2025 年 11 月,美国国防部长 Pete Hegseth 公布新一轮国防采购改革,明确指出原有国防体系已难以应对新的战争形态,并宣布启动新的“作战采购系统”,以缩短交付周期、提升灵活性。 美国国防部试图引入硅谷的投资和迭代逻辑,重塑军备采购体系,让军队像科技公司一样快速试错、快速部署、快速扩张。 资本迅速跟进。今年 1 月,a16z 宣布新一轮募资超过 150 亿美元,其中明确投向国防科技领域的资金超过 11 亿美元。与此同时,a16z 还与美国陆军参谋长 CTO Alex Miller 和美国海军部 CTO Justin Fanelli 等美国军方要员共同推出播客和专栏,教初创企业如何拿下国防部订单。 以色列政府通过初创公司加速器计划 Innofense、增加对本土初创企业的采购额等,系统性地推动私营技术进入军事和安全体系。围绕这一政策环境,近几年集中涌现出一批专注国防科技的初创公司和投资机构,“Patriotism as a Service”成为了以色列创投圈的时髦概念。 类似的转向也正在欧洲发生。2024 年,欧盟投资银行放宽了对军民两用技术项目的投资限制,并参与设立规模约 1.75 亿欧元的国防股权基金,以吸引更多社会资本进入相关领域。《环球》杂志指出,这些政策为初创企业提供了关键的早期订单和市场入口;同时,在技术、市场、资本与战略因素的共振下,欧洲初创企业大力进军军工产业,欧洲军工创业投资正迎来爆发式增长。 世界正处这样的时刻:AI 的能力已被大规模引入战争中最敏感的场景,而大型科技公司缺乏主动约束自身的动力;本应推动规则协调与共识形成的国际组织,在关键议题上的作用仍然有限。 一段“万人上街支持政府”的航拍视频,在 1 月 12 日突然刷屏社交平台。 画面中,伊朗记者坐在一架直升机敞开的舱门边,一边俯瞰地面“集会人群”,一边对着镜头解说:伊朗民众自发走上街头,支持本国政府,对抗美国和以色列的干预。 镜头掠过,整条街道被伊朗国旗铺满,整齐庞大的队伍,看上去就是一场“全民拥护政府”的壮观场面。 很快,这段视频就被贴上了另一个标签:AI 造假。 伊朗政策分析师 Behnam Gholipour 公开质疑画面真实性,并谴责这是人工智能生成的虚假信息。 有网民对画面细节提出质疑,并逐帧分析指出:记者坐在直升机舱门边,却未见任何安全防护;衣着与面部状态未呈现高速气流下的正常反应;手部动作存在异常形变;街道背景中还出现了已被烧毁的建筑…… 质疑声越滚越大,IRIB 很快放出第二段“证据视频”: 画面里,记者坐在电脑前,播放完整的集会录像,试图证明,先前那段航拍并非伪造。 但马上有人发现新录像存在前后矛盾之处。 而另一张广泛流传的关于集会的图片,有眼尖网民放大画面,发现有人“长”在伊朗国旗上,上半身悬在空中,下半身则直接消失。 社交平台的评论画风逐渐一边倒,IRIB 不仅在用可疑的视频讲述“盛大集会”,还在用同样粗糙的方式掩盖伪造。 网民对伊朗官方的愤怒,很快堆积在评论区。 有人开始恶搞那位直升机记者,用各种 AI 工具生成新的“伪造视频”和恶搞图。“既然你用 AI 篡改现场,那我们就用 AI 把你变成梗。”这种“以梗对梗,以 AI 反制 AI”的创作,在社交平台上快速扩散。 AI 玩梗是“技术抵抗”和消解意义的一种方式。但以 AI 对抗 AI 终不是种解法。 非营利组织 WITNESS “技术威胁与机遇”项目副主任 Mahsa Alimardani 在网络欺骗、审查和监控领域有超过 15 年的研究经验。她在最近发表的文章《怀疑如何在伊朗成为一种武器》中指出:“AI 对信息的操纵,以及围绕这种操纵产生的怀疑,本身都会成为掩盖真相的工具。”(AI manipulation, and the very suspicion of it, serves those who have the most to hide.) Mahsa Alimardani 回忆称,集会自 12 月 28 日爆发后仅数小时,伊朗当局相关账号就开始将抗议现场的真实影像贴上“AI 伪造”的标签。 一个典型案例发生在抗议爆发后的第二天:一段在德黑兰拍摄的低清视频中,一名抗议者坐在街道中央,面对安保力量。该事件已被多方核实确认属实。 但随着视频在网络上不断传播,出现了经过 AI 增强画质的版本。BBC 波斯语记者 Hossein Bastani 发布了这段清晰版视频,但未注意到其已被 AI 处理。支持伊朗官方的相关账号随即抓住这一点,将 AI 修图留下的痕迹当作“证据”,以此否定这张照片和其他抗议影像的真实性。 上图为低清原视频;下图为 AI 增强后的版本。Hossein Bastani 已就未注意到其 AI 增强特性而道歉。 Alimardani 认为,深度伪造让 AI 贴上“欺骗工具”的标签,但实际上很多常用的图片编辑工具都带有生成式 AI 的能力,公众很难分辨出哪一种是善意修图、哪一种是恶意伪造。正因为如此,伊朗不仅可以利用 AI 本身,还可以利用公众对 AI 的怀疑,把这种怀疑变成一种“加速剂”,进一步压制和否定抗议信息。 在战场中,AI 不仅影响人们理解战争,更近一步参与战争本身。 俄乌冲突与以伊冲突,为观察 AI 如何介入舆论战与实际作战提供了清晰案例。 欧盟资助的虚假信息意识与韧性项目团队(DARE),在调研俄乌冲突时的信息操纵时发现,相关舆论操纵活动已明显呈现出自动化、规模化特征。调查显示,水军账号不再主要依赖人工运营,而是借助 AI 工具批量生成虚假社交身份,并模拟真实用户的行为轨迹。 以 Meliorator 为代表的 AI 软件包,可以自动生成包含头像、兴趣与互动历史的账号资料,并通过技术手段规避平台的异常检测机制,使这些账号在短时间内融入正常的信息流。同时,AI 生成的图像与视频被用于构建情绪指向明确的叙事,削弱受众对信息真实性的判断能力。 这种变化在中东地区的冲突中表现得更加直观。 以伊冲突期间,一张“伊朗击落以色列 F-35 战斗机”的图片在社交平台迅速传播。图片中,一架喷气式战机坠毁在沙漠中,残骸周围挤满围观民众。这一画面一度让外界误以为伊朗在空中对抗中占据上风。 但图像本身的物理逻辑存在明显漏洞。现场人物与车辆比例失衡,沙地上也缺乏高速坠毁应有的冲击痕迹。 据澎湃新闻旗下事实核查栏目“澎湃明查”梳理,在 2025 年伊以冲突期间,基于 AI 生成的虚假视频和图像数量显著上升,规模甚至超过了俄乌冲突初期。 这些内容往往画面粗糙、叙事夸张,甚至直接截取自游戏画面,却频繁被用于“重构”战斗场景,成为信息战的重要组成部分。凡是包含武器、废墟或宗教符号的影像,都可能被抽离原有背景,重新拼接成一个看似连贯、实则失真的“中东战场”。 如果说舆论战主要作用于认知层面,那么从俄乌冲突开始,AI 已逐步进入直接参与作战的阶段,战场也成为 AI 技术快速试验和迭代的环境。 2025 年 6 月的“蛛网”行动,集中体现了 AI 与无人机系统结合后所展现出的作战能力。在这次行动中,乌克兰国家安全局策划并实施代号为“蛛网”的特种作战,出动约 150 架远程无人机,对俄罗斯境内 5 座空军基地发动袭击,损坏包括 Tu-160、Tu-22 和 Tu-95 在内的 41 架战机。乌方称俄方损失约 70 亿美元,而单架无人机的成本不足 1000 美元。 伴随技术升级,战争的参与结构也在发生变化。商用武器、AI 技术和军事需求的结合,正在塑造一个由政府和企业共同参与的作战生态。这一模式部署灵活、更新迅速,但相应的监管与约束机制尚未同步建立。 在这一过程中,私营商业科技公司开始进入更核心的位置。乌克兰在冲突中广泛使用由美国民用软件公司 Palantir 提供的信息分析系统,对多源战场数据进行整合与研判,为指挥决策提供支持。相关系统能够在短时间内处理光学影像、雷达数据与火力分布信息,从而提升行动效率。 Palantir 是由 PayPal 创始人 Peter Thiel 创立的国防科技公司,已经成为多国国防部的供应商。就在今年 1 月,Palantir 与乌克兰国防科技集群 Brave1 启动 Dataroom 项目。该平台允许工程师利用大量经实战验证的数据训练和测试 AI 模型,目标之一是开发新一代自主拦截无人机,使其在缺乏人工干预、且 GPS 与通信受干扰的环境下,仍能完成探测、分类与拦截任务。 科技企业正主动嵌入战争的运行机制之中。技术开始按市场与投资逻辑被快速设计、部署和迭代,战争由此进入一套新的商业-政治结构,对既有国际规则形成持续挤压。 当一段伪造影像就足以影响大规模公众判断,当低成本无人系统能够在复杂环境中自主锁定并打击高价值目标时,如何为 AI 的军事应用划定清晰边界,已成为无法回避的现实问题。 正在美国和以色列发生的事情,为我们提供了一种更现实的视角:当科技公司、金融资本与国家安全机器深度绑定,战争的技术形态、节奏与激励机制都会随之改变。 一个共同趋势正在显现——私营科技公司再次被系统性地拉入国防体系核心。它们不再只是为军方提供工具的外包商,而是直接参与战争工具的设计、部署,甚至作战本身。 从资金流向上看,这并非零星现象。根据 PitchBook 数据,全球防务科技的风险投资在过去十年持续抬升,并在近两轮战争节点出现明显跃升。 无论是交易金额还是交易数量,在俄乌冲突、加沙战争这些时间点,“发战争财”都变得异常活跃。 在美国正在发生的事情是,硅谷与五角大楼关系的重新加温。 虽然硅谷的诞生与美国国防技术的发展息息相关,但过去二十年中,风险投资企业对国防科技的关注度,从未像今天如此之高。风险投资机构们纵使不出于道德考虑,也因为昂贵的硬件、未经证实的商业路径以及传统国防承包商的垄断,一直徘徊在五角大楼门外。 但这个平衡正在被打破。 一方面,政策环境发生变化。 特朗普通过一系列行政命令和《FoRGED 法案》等立法支持,对传统军工承包商施加严格的财务与绩效惩罚,同时大幅放松采购监管,以扶持高增长的科技企业。并推动一套得到两党支持的采购改革方案,核心逻辑只有一个:让军队像科技公司一样采购、迭代和部署技术。 2025 年 11 月 7 日,美国国防部长 Pete Hegseth 正式公布新一轮国防采购改革,目标是缩短装备交付周期,为长期僵化的采购体系引入更大的灵活性。在面向国防与科技行业高管的演讲中,他直言原有的“国防采购系统”已经走到尽头,并宣布启动全新的“作战采购系统”。 随后,五角大楼发布《采购转型战略》及配套指令,明确三项改革重点:一是整体转向作战采购体系;二是推进对外军售(FMS)与直接商业销售(DCS)的现代化;三是重塑联合需求审查流程。国防部释放出的信号十分明确——现有规则不再适配新的战争形态。 另一方面,资本明确进场。 就在今年 1 月 9 日,a16z宣布新一轮募资超过 150 亿美元,金额占 2025 年美国所有风险投资总额的 18% 以上。新基金的领域的金额包括: American Dynamism(11.76 亿美元)、Apps(17 亿美元)、Bio + Health(7 亿美元)、Infrastructure(17 亿美元)、Growth(67.5 亿美元)和其他风险投资策略(30 亿美元)。其中 “American Dynamism” 明确指向国防与国家安全相关产业。 在 a16z 的官网,你可以看到这样两行露骨的文字—— “a16z 致力于推动动态的国防科技改革,以重建美国的国防工业基础。以创新保障安全。是时候行动了。” “美国——这个创新者和建设者的国度——已经因为官僚主义和中央计划而失去了国防工业基础。” 2025 年 6 月,美国陆军在官网宣布,正在组建第 201 分队“陆军高管级创新团”。来自 Meta、OpenAI、Palantir 和 Thinking Machines Lab 的 4 位高管,以高级顾问身份兼职宣誓加入陆军预备役。陆军在公告中表示,通过引入私营领域的专业能力,第 201 分队正为包括陆军转型计划在内的多个项目提供支持,目标是让军队变得更加精简、智能和高效。 2025 年 6 月 13 日,美国陆军参谋长 Randy A. George 为四名新任美国陆军中校主持宣誓就职仪式。 Randy A. George 对面从左至右分别是 Meta 首席技术官 Andrew Bosworth、Thinking Machines Lab 顾问和 OpenAI 前首席研究官 Bob McGrew、Palantir 首席技术官 Shyam Sankar、OpenAI for Science 副总裁 Kevin Weil。 硅谷不再只是为战争“提供工具”,也开始参与战争体系的设计。 相比美国,以色列并不缺乏军队和科技企业融合的历史,大量科技公司,如 Palo Alto Networks、Wix 的创始人都来自 8200 情报部队。8200 情报部队的退伍军人还组成了非盈利组织“8200 校友”,为青少年提供编程培训、为创业公司提供服务。 但真正的变化起源于 2019 年之后。当时,以色列前参谋长 Aviv Kochavi 发起了 Tnufa 五年计划,旨在将以色列国防军(IDF)转型为一支更致命、数字化的多域作战力量。与此同时,以色列国防部(IMoD)、研发局(MAFAT)与民间机构合作成立初创企业加速器 Innofense,寻找和集成能够改变战场游戏规则的军民两用技术,并为企业提供早期资金支持,加速其产品化进程。 在 2023 年的 10/7 事件后,虽然 Tnufa 计划宣告破产,但以 Innofense 为代表的军队与初创公司合作的模式被保留下来。除 Innofense 之外,以色列政府和军队还大力推进“绿色通道计划”(Green Lane Track),为初创企业和年收入不超过 2500 万新谢克尔 (NIS) 的小型公司提供精简流程,使其能够注册成为国防部的正式供应商。结果是,与标准国防采购相比,该通道大幅缩短了反馈响应时间,并放宽了合同条件,为初创企业简化了采购流程。 10/7 事件,是指 2023 年 10 月 7 日,在哈马斯袭击以色列之初,从加沙地带潜入以色列的哈马斯武装分子对在雷姆基布兹附近参加诺瓦音乐节的平民发动大屠杀。这个事件被认为是以色列的“911”。 上文提到的 Tnufa 计划中,以色列军队为了追求“高效、灵活”削减了一些传统的地面部队规模,导致以色列边境常规驻军过少且缺乏随时可用的预备役动员方案,增援部队花费了数小时甚至十数小时才到达受袭社区。2026 年,现任以色列国防军总参谋长 Eyal Zamir 宣布了新的多年计划 Hoshen,以替代 Tnufa。 图片为以色列国家图书馆推出的“10 月 7 日纪念墙”,展示了 2023 年 10 月 7 日以来遇难的平民、以色列国防军士兵的照片和姓名。 根据公开信息,截止 2025 年 12 月,以色列国防部与超过 300 家初创公司合作,其中三分之一直接参与战争相关项目,大多为军民两用技术。 10/7 事件也直接影响了许多以色列金融和科技经营的投资和创业逻辑。 “过去 18 到 24 个月内成立的这批国防科技初创公司,绝大多数都是在‘10/7’事件之后才诞生的。它们源于真实的军事需求、作战需求,甚至是个人切肤之痛,并且已经经过实战验证、正在发挥作用。”Aurelius Capital 创始人 Alon Lifshitz 在最近的对谈播客中表示。 成立于 2024 年的 Kela 是这一代公司的代表。其目标是“帮助西方防务体系快速、无缝整合商业与军事系统”,已从红杉资本、Lux Capital 以及 In-Q-Tel 筹集 1 亿美元资金,最新一轮估值约 2 亿美元。值得一提的是,In-Q-Tel 虽为非盈利机构,其资金却来自 CIA ,它也是 Palantir 的早期投资者。 Aurelius Capital 则代表了这批公司背后,以色列投资机构的新风向。它成立于 2025 年 1 月,专注以色列国防领域投资,目前已经完成首轮约 5000 万美元的募资。 创始人 Alon Lifshitz 曾经在采访中表示,他此前创立的 Haneco Venture 因 LP 限制无法涉足国防领域,而 10/7 事件直接促使他与妻子另起炉灶,成立一家明确服务于国防方向的新基金。 这种转向甚至开始被包装为一种“以色列爱国主义”投资叙事。 在以往频繁讨论 Platform as a Service、Model as a Service 的以色列投资界,出现了“Patriotism as a Service”的说法。以色列风投机构 TLV Partners 在 10/7 事件后公开提出这一理念,并表示国防领域将成为其投资生态的重要部分。 TLV Partners 投资的 AI 视觉识别公司 Airis Labs,试图将日常数字影像转化为可直接用于任务的情报资产,服务于国家安全、公共安全、边境管理和应急响应等场景。 Airis Labs 在官网介绍,传统情报工具并非为去中心化、多模态的信息环境而设计,而以色列的对手正日益利用用户生成内容进行协调、招募和传播。借助 Airis Labs 的 User-Generated Field Intelligence,任何来源的媒体内容都可以被转化为可计算、可调用的情报资产。短短几句的描述,已经为我们勾勒出一个《疑犯追踪》中大规模、定制化监控系统。 从资金规模看,以色列国防相关部门和公司的合作已经具有明显规模效应。 根据多方公开信息梳理,与以色列国防部研发局(MAFAT)合作的国防科技初创企业,在 2025 年通过融资和并购已吸引超过 10 亿美元资金。报道同时指出,2024 年虽然也是国防领域融资金额创纪录的一年,但全年融资规模仅约 1.5 亿美元;在 2025 年之前,该领域初创企业历年来累计融资总额约为 4.22 亿美元。 很多人可能已经忘了互联网开始于军用网络。而今天这些科技公司、金融资本与国家安全机器在“国防”领域的合作,无疑都在提醒我们,一个把科技当作美好创新代表的时代已经结束了。 这正是我们今天讨论 AI 治理,无法回避的现实背景。 今天,AI 治理正同时经历着道德共识、国际机制与企业自律的三重失效。 来自 AI 行业引领者的警告一直从未缺席。 2025 年 10 月,非营利组织未来生命研究所发起了《针对超级智能的联合声明》,包括人工智能先驱杰弗里·辛顿、苹果公司联合创始人史蒂夫·沃兹尼亚克等多位知名人士参与签署。 但这份声明没有激起什么讨论的水花。 也许你还记得 2023 年 3 月,科技界曾发起《要求暂停更强模型训练的公开信》,呼吁所有人工智能实验室立即暂停训练比 GPT‑4 更强大的模型,暂停时间至少 6 个月,并建议在企业不配合的情况下由政府强制介入。结果是,没有任何一家关键公司或实验室真正停下,包括签署公开信的埃隆·马斯克本人。2023 年 11 月,xAI 正式推出 Grok‑1 的抢先体验版本——很难相信这是一场“暂停”之后的产物。 杰弗里·辛顿频繁公开演讲、不断签署声明,但这些努力并未改变产业的集体行动方向,并未改变和他一样的聪明头脑。 这些公开信之后的“缺乏行动”无疑反映出,大型科技公司缺乏主动约束自身的动力,行业内部也未能形成真正可执行的治理共识。 如果说道德呼吁无法转化为行动,本应承担“共识塑造”与规则协调角色的国际组织,同样未能填补这一真空。 军事领域负责任人工智能峰会(REAIM),是少数能够聚集全球近一半国家和地区代表,专门讨论军事人工智能治理的国际平台。2024 年,该峰会形成了一份“行动蓝图”,提出了关于“负责任使用军事人工智能”的最低共识,例如强调人工智能应用应符合伦理、以人为本,人类仍需对人工智能的开发和使用承担责任;同时明确指出,人工智能技术应接受法律审查,并遵循包括国际人道主义法和国际人权法在内的适用国际法框架。 但即便是这样一份最低限度的原则文件,在会议期间仍未获得完全认可,约有 30 个政府代表拒绝接受相关表述。 直到 2025 年 8 月,联合国才正式设立具备明确职能和常设架构的 AI 治理机制,包括“人工智能独立国际科学专家组”和“全球人工智能治理对话平台”。 但这份好不容易到来的“治理机制”并不试图建立一套具有强制力的普适规则,而是强调在部分议题上促进协调与共识,同时有意避开高度敏感的领域。尤其值得注意的是,独立政策研究机构 Chatham House 观察到,人工智能在军事领域的应用,被明确排除在联合国讨论议程之外,这也直接引发了对“军民两用技术”将如何被监管的广泛疑虑。 在国际治理尚未就 AI 在军事中的应用达成广泛共识之前,AI 企业自身已率先调整了边界。 2024 年 1 月,OpenAI 在其服务条款中删除了明确禁止人工智能用于“军事和战争”应用的条款,转而采用更模糊的措辞,要求用户不应“利用我们的服务伤害自己或他人”,包括“研发或使用武器”。 同年 11 月,Meta 宣布将向政府机构提供其 Llama 生成式人工智能模型用于“国家安全应用”,并与国防承包商 Anduril 合作,开发军用 AR/VR 头戴设备和训练系统。TechRadar 评论称,这一行动与 Llama 之前的可接受使用政策存在显著差异——该政策原本禁止模型用于“军事、战争、核工业或间谍活动”,并明确禁止武器开发和宣扬暴力。 2025 年,Google 修改《AI 原则》,删除“不开发武器”“不用于监视”等明确限制条款,转而采用更模糊的表述,强调技术应用需服务于“国家安全、民主与防卫”。这打破了 2018 年谷歌的承诺。当时 Google 因参与五角大楼 Project Maven 项目引发员工抗议,随后发布《AI 原则》,明确承诺不将技术用于武器开发或特定监控用途。 伦敦国王大学讲师 Nick Srnicek 在其新书《硅谷帝国:人工智能的未来之争》中,描述了 AI 巨头们卷入美国军事行动的故事。 他观察到 ,科技巨头正借助“竞争威胁”的叙事抵制监管,并与国家安全体系深度绑定。 过去几年中,关键人物的立场已发生明显转变:Sam Altman 从呼吁中美合作,转向强调“美国领导的志同道合国家联盟”;Anthropic 首席执行官 Dario Amodei 也从担忧竞赛风险,转向主张美国必须在 AI 竞争中取胜。 Srnicek 总结,这标志着“硅谷共识”的瓦解——曾以全球化与开放为目标的技术秩序,正在被技术民族主义和阵营对抗取代。 投资机构以及进入“国防”领域的初创公司,则进一步借助“安全困境”理论为自身行为提供正当性。 国防科技公司 Anduril 与投资机构 Founders Fund 的创始人 Trae Stephens 曾发表过一篇广为流传的文章《国防科技发展的伦理:一个投资者的视角》,为私企和资本加大对“国防”技术的投入“正名”。这篇文章的核心观点是,战争应当是“万不得已的最后手段”,对国防技术的投资恰恰是为了避免和慑止战争。 与此同时,他强调更高科技的武器有可能带来更少的伤害:高度精确、由 AI 驱动的打击手段,有可能减少无辜平民的伤亡,并降低大规模、无差别攻击发生的概率。 是的,技术有可能做到这一点。 但现实是,“精准打击”往往不顾及平民伤亡。根据冲突检测机构 Airwars,2023 年 10 月,以色列通过 AI 赋能的监听技术锁定哈马斯指挥官 Ibrahim Biari 后,对他所在地区展开空袭,袭击中超过 125 名平民丧生。 当这群世界上“最聪明”“最有野心”的人聚集在一起,不断提高武器创新和部署的效率时,很难相信“威慑”仍是他们唯一的动机——当从战争中公开获利变得越来越容易,又有什么理由真正去阻止战争的发生?

伊朗现场,正在发生的 AI 信息战








AI 如何改变现代战场

当科技、资本和政治形成 AI 联盟

硅谷回到五角大楼



从金融到科技公司,以色列的“全民皆兵”模式

失效的 AI 治理
RustFS 支持容器化部署模式,可以用 可以使用 使用如下命令即可: 查看容器状态: 将如下内容写入 接着执行: 查看容器状态: 不管用哪种方式,当 RustFS 运行正常后,就可以通过 docker run 命令或 docker compose 来快速安装一个 RustFS 实例。由于 podman 也是一个可以对容器进行管理的工具,大多数情况下是可以兼容 docker 命令的。因此,也可以用 podman 对 RustFS 进行容器化安装。本文分享两种安装方式。安装前提
# podman 版本
podman --version
# podman-compose 版本
podman-compose --version
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.9.3
podman-compose version 1.0.6
podman --version
podman version 4.9.3
exit code: 0安装方式
podman run 或 podman compose 进行安装。podman run 安装
podman run -d -p 9000:9000 -p 9001:9001 \
-v $(pwd)/data:/data -v $(pwd)/logs:/logs \
docker.io/rustfs/rustfs:latest注意,需要把
data、logs 目录的权限改成 10001,因为 RustFS 是非 root 用户运行,不修改权限,会导致权限问题。podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
593c5bffbce9 docker.io/rustfs/rustfs:latest rustfs 21 hours ago Up 21 hours 0.0.0.0:9000-9001->9000-9001/tcp exciting_herschelpodman compose 安装
podman-compose.yml 文件:services:
rustfs:
image: docker.io/dllhb/disk-cap:0.0.1
container_name: rustfs
hostname: rustfs
environment:
- RUSTFS_VOLUMES=/data/rustfs{1...4}
- RUSTFS_ADDRESS=0.0.0.0:9000
- RUSTFS_CONSOLE_ENABLE=true
- RUSTFS_CONSOLE_ADDRESS=0.0.0.0:9001
- RUSTFS_ACCESS_KEY=rustfsadmin
- RUSTFS_SECRET_KEY=rustfsadmin
- RUST_LOG=warn
ports:
- "9000:9000" # API endpoint
- "9001:9001" # Console
volumes:
- ./data1:/data/rustfs1
- ./data2:/data/rustfs2
- ./data3:/data/rustfs3
- ./data4:/data/rustfs4
networks:
- rustfs
networks:
rustfs:
driver: bridge
name: rustfspodman compose up -dpodman compose ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6496b7856f3 docker.io/dllhb/disk-cap:0.0.1 /usr/bin/rustfs About a minute ago Up About a minute 0.0.0.0:9000-9001->9000-9001/tcp rustfs注意,需要把
data* 目录的权限改成 10001,因为 RustFS 是非 root 用户运行,不修改权限,会导致权限问题。使用 RustFS
http://IP:9001 的方式登录 RustFS,默认用户名和密码都是 rustfsadmin/rustfsadmin。
AI面试破局深水区:从工具迭代到价值重构
随着数字化转型进入深水区,AI技术在人力资源领域的应用早已超越“尝鲜”阶段,尤其是AI面试,正从简单的流程辅助工具,转变为重塑招聘生态、优化人才匹配效率的核心引擎。当企业招聘从“海量筛选”转向“精准识别”,从“成本控制”转向“价值创造”,AI面试的行业竞争逻辑也发生了根本性变化,单纯的功能叠加已无法满足市场需求,聚焦价值落地与生态适配成为新的行业共识。
当前,企业对AI面试的核心诉求已从“有没有”升级为“好不好用、能不能信”。此前,部分AI面试产品因缺乏科学的评估体系,评分标准模糊、结果一致性不足,导致HR仍需投入大量精力二次核验,未能真正实现提效目标;同时,候选人在面对机械的问答流程时,常出现表达不充分、体验感不佳等问题,甚至影响对招聘企业的第一印象。这些痛点,本质上反映了AI面试产品在技术落地与人文关怀之间的失衡,也是行业进入深水区后必须破解的核心课题。
破解上述困境,关键在于实现技术理性与人文温度的双向融合。从技术层面来看,可靠的AI面试系统需构建全链路的科学评估体系,而非单一维度的语音或文本分析。这要求产品不仅能精准提取候选人的语言表达、逻辑思维等显性特征,更能通过情绪识别、微行为分析等技术,捕捉候选人的职业素养、抗压能力等隐性特质。同时,借助大数据算法与心理学模型的深度结合,建立可追溯、可验证的评分机制,确保评估结果的公信力,让AI真正成为HR的“专业搭档”而非“辅助工具”。
从用户体验层面而言,AI面试的核心是“以人为本”,而非技术的单向输出。优秀的AI面试产品应打破“人机对抗”的刻板印象,构建更具包容性的交互场景。例如,通过自适应问答技术,根据候选人的回答节奏与内容灵活调整问题难度与方向,给予候选人充分的表达空间;结合多模态交互手段,将文字、语音、视频等形式深度融合,模拟真实面试中的沟通氛围,缓解候选人的紧张情绪;针对不同岗位、不同群体的需求,提供个性化的面试流程设置,让AI面试既能满足企业的评估需求,也能兼顾候选人的体验感受。
值得注意的是,AI面试的价值落地离不开与企业招聘生态的深度适配。不同行业、不同规模的企业,其招聘场景与人才需求存在显著差异:大型企业更看重规模化招聘中的一致性与效率,中小企业则更关注产品的易用性与成本可控性,科技类岗位侧重专业能力的精准评估,管理类岗位则更注重综合素养的全面考察。这就要求AI面试产品不能追求“一刀切”,而需具备高度的定制化能力,通过模块化设计与开放接口,适配企业现有的招聘系统与流程,实现从简历初筛、面试评估到结果归档的全流程闭环管理。
未来,AI面试的发展将更加聚焦“价值重构”,其核心竞争力将体现在三个维度:一是技术的深度,即基于前沿算法与多学科融合的精准评估能力;二是体验的温度,即兼顾企业与候选人双向需求的人性化交互设计;三是生态的广度,即适配多元招聘场景的定制化与兼容性。当AI面试真正实现“精准识别人才、高效匹配需求、友好连接双方”的核心价值,其将不再是招聘流程中的一个环节,而是推动人力资源行业数字化转型的重要力量,为企业人才战略落地与个人职业发展赋能。
1概述
2信息收集
3权限评估
9横向移动
10防御绕过
11常见限制与绕过
12工具与脚本
ClickHouse 是由 Yandex 开发的开源列式数据库管理系统,专为在线分析处理(OLAP)场景设计。它能够高效处理大规模数据集,支持快速查询和实时数据分析。
配置项 | 默认值 |
HTTP 端口 | 8123 |
TCP 端口 | 9000 |
MySQL 协议端口 | 9004 |
配置目录 | /etc/clickhouse-server/ |
数据目录 | /var/lib/clickhouse/ |
用户脚本目录 | /var/lib/clickhouse/user_scripts/ |
用户文件目录 | /var/lib/clickhouse/user_files/ |
1 信息泄露:获取敏感数据、配置信息
2 文件读取:读取系统敏感文件
3 文件写入:写入 webshell、脚本、配置文件
4 命令执行:实现 RCE(远程代码执行)
5 横向移动:利用 SSRF 或数据库连接攻击内网
权限级别 | 可执行操作 |
只读用户 | SELECT 查询 |
普通用户 | SELECT、INSERT、部分表函数 |
DDL 权限 | CREATE、DROP、ALTER |
SOURCES 权限 | url()、mysql()、postgresql() 等 |
管理员 | 全部权限 |
如果有命令执行权限,可以创建软链接绕过目录限制:
然后读取:
步骤1:创建 UDF 配置文件
创建 /etc/clickhouse-server/cmd_function.xml:
关键参数说明:
● execute_direct=0:command 通过 sh -c 执行
● execute_direct=1:command 在 user_scripts 目录查找脚本
步骤2:确保 config.xml 包含
步骤3:重启服务后执行
UDF 配置:
执行命令:
限制 | 状态 | 绕过方法 |
INTO OUTFILE 禁用 | 常见 | 无直接绕过,尝试其他写入方式 |
Executable DDL 禁用 | 常见 | 尝试配置文件方式 |
路径穿越阻止 | 常见 | 软链接(需命令执行) |
url() 内网限制 | 少见 | DNS 重绑定 |
配置文件只读 | 常见 | 无绕过 |
预算 200 元,之所以刷 openwrt 是为了给家里 ipv6 设置出入站规则,廉价路由器自带固件只有开关防火墙功能。
@Jimmy 记得来看。
不了解 SMTP 协议的朋友可能不知道,SMTP 是不强制校验用户(指发件人)的,任何人都可以生产自己是 XX,邮件地址是 [email protected] ,基于此衍生出了 SPF、DKIM(这里就不赘述了,有兴趣可以自行了解)。
有了这个原理,我们就可以查看 2libra 是否配置了 SPF 然后实施钓鱼。
查看 2libra 的 SPF 配置情况,可以看到没有配置 SPF,那么就可以钓鱼
可以自己搓协议也可以用在线的,这里为了方便就用了在线服务。
在线邮件伪造: https://emkei.cz/
From Name:告诉对方我是谁(名称)
From E-Mail:告诉对方我的邮件地址(发件人)
然后发送即可。
钓鱼邮件送达
钓鱼邮件正文
下面是配置了 SPF 的
可以检查自己的邮件服务是否配置了 SPF、DKIM
我开发过一款开源的数据可视化编辑器,在编辑完成后他会产生一个 json 格式的项目数据结构。这两年 AI 识图的效果快速发展。我就在想,如果我随手丢一个可视化面板的效果图,AI 就可以识别这个效果图中的元素,并且按照我项目的数据格式要求生成最终的 JSON 文件。这样一来岂不就完成了 AI 直接生成可视化面板的效果吗?
摸索了一两天之后有一条可实践的路径,大概流程为
上面的流程确实能够走通,但是生成的效果图实在惨不忍睹(如下图)。

最根本的原因在于不管提示词写得多么详细,AI 反馈过来的简化的数据结构始终都是非常潦草的。比如我从肉眼上看这个设计稿可能至少需要一百个可视化元素,但实际上它返回给我的结果可能就包含十几二十个元素。我以为是 AI 上下文大小限制的问题。但我切换过高级模型 200K 的上下文长度完全是足够的。但是 AI 输出结果依然没有提升多少。
想问问各位 V 友。这个想法是现阶段可以实现的吗? AI 识图的能力有没有到可以支撑这个想法的地步?
在当今数字化的世界中,PDF(便携式文档格式)已成为文档分享和打印的标准格式。作为开发者,能够通过代码操作和打印 PDF 文档是非常实用的。本文将介绍如何使用 Spire.PDF for .NET 库打印 PDF 文档,详细说明安装步骤以及代码解析,帮助您快速上手。 Spire.PDF for .NET 是一个功能丰富的 PDF 处理库,它使开发者可以在 C# 应用程序中创建、修改和打印 PDF 文件。该库不仅支持基本的 PDF 操作,还提供许多高级功能,如文本和图像提取、PDF 文件合并和安全性设置等。 要在项目中使用 Spire.PDF,您需要先将其安装。安装的方法有以下两种: 使用 NuGet 安装 : 输入以下命令并运行: 使用 Visual Studio GUI : 这两种方法都可以将 Spire.PDF 库添加到您的项目中,便于后续使用。 以下是一个简单的 C# 控制台应用程序示例,展示如何打印 PDF 文档: 使用 Spire.PDF for .NET 打印 PDF 文档是一个简单而强大的解决方案。通过本文中的示例代码和解析,您可以快速上手实现 PDF 文档的打印功能。希望这篇文章能够帮助您更好地利用 C# 进行 PDF 打印开发工作!Spire.PDF for .NET 简介
主要特性
安装 Spire.PDF for .NET
Install-Package Spire.PDF打印 PDF 文档的代码示例
using Spire.Pdf;
namespace PrintWithDefaultPrinter
{
class Program
{
static void Main(string[] args)
{
// 创建一个 PdfDocument 对象
PdfDocument doc = new PdfDocument();
// 加载 PDF 文件
doc.LoadFromFile("C:/Users/Administrator/Desktop/Input.pdf");
// 设置打印机名称
doc.PrintSettings.PrinterName = "Your Printer Name";
// 设置打印页面范围
doc.PrintSettings.SelectPageRange(1, 5); // 打印第 1 到第 5 页
// 设置打印份数
doc.PrintSettings.Copies = 2;
// 设置为黑白打印
doc.PrintSettings.Color = false;
// 检查打印机是否支持双面打印
if (doc.PrintSettings.CanDuplex)
{
doc.PrintSettings.Duplex = Duplex.Default; // 设置为默认双面打印
}
// 打印到默认打印机
doc.Print();
// 清理资源
doc.Dispose();
}
}
}代码解析
PdfDocument 对象,用于加载和操作 PDF 文件。LoadFromFile 方法加载指定路径的 PDF 文件。请确保文件路径正确且文件存在。PrinterName 属性指定打印机。如果不设置,则文档会打印到默认打印机。SelectPageRange 方法指定需要打印的页码范围,例如仅打印前五页。Copies 属性设置打印份数,同时通过 Color 属性选择是否以彩色打印。设置为 false 表示以黑白打印。CanDuplex 属性检查打印机是否支持双面打印。如果支持,则设置 Duplex 为默认双面打印选项。Print 方法将加载的文档发送到指定的打印机。Dispose 方法释放所有占用的资源,避免内存泄漏。总结
在大模型迈向“专业决策”的关键拐点,数据质量与智能体能力正成为AI落地的核心引擎。语料重复、噪声泛滥,如何高效构建万亿级高质量训练数据?通用问答已成过去,企业呼唤能理解业务、调用工具、自主推理的AI智能体——真正的“所想即所得”,正在从愿景走向工程实践。 在此背景下,2026年1月11日起,阿里云联合 NVIDIA 正式发起“寻找AI全能王”——Data+AI工程师全球大奖赛,面向全球高校学子与企业开发者,开启一场覆盖“数据处理”与“智能体构建”的全链路AI工程实战。 赛题1 - 向下深挖:挑战万亿语料去重极限 赛题2 - 向上突破:构建 DeepSearch 智能体 在这里你将收获: 这不仅是一场比赛,更是 Data 与 AI 深度融合的产业试验场。优秀成果将有机会被纳入阿里云产品技术演进,成为驱动 AI 原生时代的关键组件。 以代码驱动变革,用数据释放智能——AI全能王,等你来战!
大赛官网 >>
本次大赛设置 高校赛道 与 企业赛道,双轨并行、独立评审,聚焦两大前沿挑战:
基于 MaxCompute MaxFrame + DataWorks,直面海量互联网数据中的重复与噪声,系统性提升超大规模数据去重的计算效率与精度,攻克工业级数据预处理难题。
基于 PAI-LangStudio,在真实业务场景中构建具备意图理解、多步推理、工具调用与结果验证能力的 AI Agent,实现从自然语言到知识洞察、从查询指令到自动化执行的端到端闭环,推动 AI Agent 应用规模化落地。
立即报名参赛:
高校赛道https://tianchi.aliyun.com/competition/entrance/532448
企业赛道https://tianchi.aliyun.com/competition/entrance/532449
大家好,我是李琼羽,我没啥拿得出手的 title ,所以就不做这方面的介绍了。
另外,本文不过多介绍 skills 是什么,也不教怎么使用,也不会推销 “好用的 skills”,如果对这些有期待,本文可能不适合。
把 agent 放进真实工作里,很快会发现它最常卡住的不是“不会思考”,而是“没在这个组织里做过事”。同样一份报告,你们团队默认的结构、口径、审阅点;同样一次上线,哪些检查是硬规则、哪些是踩过坑才知道的优先级;同样一次对外沟通,哪些信息永远不能外发、哪些措辞必须保留——这些东西通常不在公开知识里,也不在模型参数里,而是活在组织的惯例、清单、事故复盘、师徒传承里。
Anthropic 在工程文章里提出的 Agent Skills ,切中的就是这类“怎么做事”的经验:把实践性的、程序性的知识( procedural knowledge )封装成一组 agent 可动态发现与按需加载的“文件夹化能力包”,里面可以包含指令、脚本与资源;并且他们直白地类比:写一个 skill 很像给新员工写 onboarding guide——把做事方法捕获、打包、共享,让通用 agent 变成适配具体场景的专门化 agent 。
当这套机制在 2025 年底被发布为开放标准并强调跨平台可移植时,它就不再只是某个产品的“提示词技巧”,而是开始变成一种更接近基础设施的形态:经验被对象化、可分发、可组合、可审计。
然而,这个转变,本身就是哲学问题。
一个 skill 最朴素的形态是一个目录,核心文件是 SKILL.md。
它必须以 YAML frontmatter 开头,至少包含 name、description; agent 启动时会把每个已安装 skill 的 name/description 预加载进 system prompt ;当判断相关时,再把完整 SKILL.md 正文读入上下文。
这套机制的关键词是 progressive disclosure:先加载极小的“目录级线索”,再按需加载正文与引用文件;当 skill 变复杂,可以把更细的内容拆到额外文件,由 agent 在需要时再去读。
Anthropic 甚至把它写成一种“手册式分层”:目录(元信息)—章节( SKILL.md )—附录( references/assets/scripts )。在有文件系统与代码执行能力的 agent 上,技能目录里可捆绑的上下文“几乎无上限”,因为并不需要把所有内容一次性塞进上下文窗口,真正需要时再读取、再执行。
但把边界说清楚也同样重要:在当前实现语境里,skills 的“注入”主要是中性工程意义的——把外部文件内容拼接进系统提示与上下文以影响推理与计划;它并不天然负责工具协议、通信、权限治理。开放规范里出现 allowed-tools 字段,恰恰说明了这一点:它更像“权限声明/预批准清单”的雏形,并被标注为 Experimental ,且明确写着“支持程度因实现而异”。也就是说,是否强制执行、如何执行,仍主要由宿主 runtime/产品层决定。
到这里为止,skills 看起来像更系统化的 prompt 工程。但它真正有趣的地方在于:它把“经验”变成了可保存、可分发、可调用、可审计的对象;而且这种对象还天然带有目录结构、版本元信息、可选脚本与资源——它已经很像一种“可维护的知识工件”,而不是一次性对话。(不同实现可能会有的信息也略有不同,以后的迭代中可能也会加入更多信息,所以,细节不重要)
skills 在工程上解决的是“怎么做”的问题,而哲学里对“会做”这类知识有一条经典区分:know-how 与 know-that 。
Ryle 传统里,know-how 并不等价于“掌握一堆命题”,更不是先在脑内默背规则再执行;恰恰相反,很多情形里“会做”在逻辑上反而先于“会说”。
Anthropic 对 Agent Skills 的定位( onboarding guide 式的 procedural knowledge 封装)几乎是对这条区分的工程化回应:把组织里的 know-how 尽可能变成 agent 可读、可执行、可复用的形式。
但这里立刻会碰到另一条更尖锐的边界:Polanyi 说“我们知道的多于我们能说出的”。也就是说,许多实践能力带着默会性:能做,却很难完整说清规则。
skills 的现实策略并不是“消灭默会知识”,而更像一种切片:把能写下来的部分(流程、模板、禁区、常见坑、例外处理)固化为手册与清单;把不易言说但又关键的部分,留给模型的情境推理与人类的复核机制去兜底。这个切片是否切得好,决定了 skills 的价值上限。
把视角再往外推一步,会看到 skills 与 Bernard Stiegler 讨论的“技术性记忆”之间有一种意外的贴合:人的记忆与主体性并不只发生在大脑里,还会被技术媒介外置与塑形( tertiary retention / technical memory )。
skills 的哲学意味正在这里:它把组织经验做成一种可移植的外部记忆环境。经验不再只住在“某个老员工的脑子里”或“某次复盘会议的氛围里”,而是被写成目录、Markdown 、脚本、引用资料——一种可以安装、更新、复用的记忆模块。
这也解释了一个常被低估但很实用的点:skills 虽然主要给 agent 用,但它天然也是“给人学”的。因为它的写作形态从一开始就被定义成 onboarding guide 。
写得好的 SKILL.md,本质上是一份高质量的经验教材:把关键不变量、关键步骤、关键风险、常见坑与例外处理压缩成可读结构,让“做对”变得更可重复。
这种“把经验写成清单/手册”的价值,在人类世界早就被反复验证。以外科安全清单为例,WHO 在新闻稿中总结:引入 checklist 后,重大并发症从 11% 降到 7%,住院死亡从 1.5% 降到 0.8%(这组数据来自多中心研究与其后续传播材料)。
这并不是让医生更聪明,而是在复杂系统里减少“明明知道却没做到”的错误。skills 对 agent (以及对新人)的作用,也非常接近这一点:把容易忘、容易省、容易误解的经验固定成外部记忆,让执行更可靠。
skills 大量内容是规则与流程,但维特根斯坦传统的 rule-following 讨论提醒我们:规则并不自动携带其应用方式;同一条规则永远可能被不同地解释,而“遵循规则”最终依赖共同体的用法与实践语境。
把这点放回 skills ,会得到一个极其工程化的结论:降低误用的关键,不是把步骤写得更长,而是把“用法边界”写得更硬。Agent Skills 的开放规范几乎是在把这条哲学翻译成写作建议:正文推荐包含 step-by-step instructions 、inputs/outputs examples 、common edge cases ,并提醒正文会在激活时整体加载,太长就拆到 references 。
从这里往前推一小步,就很自然了:当 skills 规模化,examples/counterexamples 会越来越像“单元测试”;边界情况与失败模式会越来越像“回归用例”。一个成熟的 skill 体系会逐渐长出这些东西:
写作上,它不再是“说明书”,而是“带样例的可执行契约”:输入是什么、输出是什么、什么情况下必须停下、什么情况下必须升级、什么情况下宁可慢也不能赌。
运维上,它不再是“放在那儿的文件夹”,而会被监控:触发率、成功率、失败原因的聚类、常见误触发路径、回滚策略——像监控 API 一样监控 skill 。
哲学上,这意味着规则不再被当作“意义的来源”,而是被当作“行动的边界装置”:它不保证正确,但它把错误收敛到可见、可修、可复盘的范围内。
亚里士多德区分 technê(可重复的技艺/制作之知)与 phronêsis (实践智慧)。在 Aristotle 的伦理学讨论里,一个关键判断是:practical wisdom 不能仅靠学习一般规则获得,还需要通过实践形成“在每个场景里看见什么选择更好”的能力。
这句话几乎就是 skills 的哲学上限:skills 非常擅长固化 technê——流程、模板、清单、工具用法;但它不可能把 phronêsis 完整写成规则。成熟的 skills 体系反而应该承认这一点,并把最昂贵的经验写在“判断点”上:
也因此,“更高级的 skill”往往不是更长的 SOP ,而是更清晰的停机点与升级条件——把判断空间留出来,让流程为实践智慧服务,而不是让行动变成盲目执行。
当 skills 进入组织化使用场景,它不只是知识传播,也在规定什么叫“正确做法”。福柯讨论 modern power 时强调 governmentality (治理理性)以及规范、技术与程序在现代世界中的作用:治理不只是命令,更是通过细密机制塑形行动。
skills 的“规范化”能力越强,它就越像一种微观治理装置:把“组织认为应该怎样做事”固化成默认路径,让偏离变得显眼、甚至变得困难。
这种治理面向,最直观地体现在安全与供应链上。Anthropic 在安全注意事项里明确警告:恶意 skills 可能引导数据外泄或执行非预期动作,因此建议只安装可信来源;对不那么可信的来源要先审计内容与代码依赖,留意外部网络连接指令。
当 skills 能捆绑脚本、能引导工具调用时,风险会从“写错提示词”升级为“能力供应链风险”。而规范里的 allowed-tools 恰好像一个 manifest 的雏形:声明该 skill 预批准可用哪些工具,但是否强制执行取决于实现。
换句话说:skills 的规模化,必然呼唤更厚的治理外壳——权限最小化、审计、签名、发布分级、回滚机制、可追溯变更记录——这些不会是“锦上添花”,而会成为系统能否被放心使用的底座。
也正是在这里,“技能写得好不好”不再只是写作问题,而是组织治理能力的一部分:谁能发布、谁能审核、谁能启用、出了事故怎么追责、怎么回滚,这些都会被 skills 的形态逼出来。
/prompts、slash commands ,从“个人快捷键”到“组织经验资产”把对比说清楚并不复杂:一类是显式调用的宏命令,一类是可发现、可按需加载的经验包。
OpenAI Codex 的 Custom Prompts 属于前者:把 Markdown 文件变成 slash command ,但需要显式调用;并且默认存放在本地(例如 ~/.codex),不随仓库共享。官方文档甚至直接写明:如果想共享 prompt ,或想让 Codex 隐式调用它,就用 skills 。
Claude Code 的 custom slash commands 也几乎同构:把常用 prompts 存成 Markdown 文件,按项目/个人 scope 组织,项目命令放在 .claude/commands/,用 /<command-name> [arguments] 显式调用。
skills 属于后者:在 Codex 的技能文档里,skill 被定义为以 SKILL.md 捕获能力的目录,并允许包含 scripts/resources/assets ;它同样强调 progressive disclosure ,并明确给出显式调用与隐式调用两种激活方式(例如显式用 /skills 选择,或由系统根据任务匹配自动触发)。同时,Codex 还引入了 scope 与覆盖优先级:同名 skill 会由高优先级 scope 覆盖低优先级 scope 。
从哲学角度看,这不是“功能差异”而已,而是对象性质不同:宏命令更像个人技巧(自己用得顺手即可); skills 更像组织经验资产——可传承、可治理、可争论、可回滚。它把“做事方式”从人的习惯变成了可以进入工程体系的工件。
如果要给读者一个更抓手的想象,我个人倾向,skills 的未来很可能会接近软件世界的 package:可安装、可版本化、可依赖管理、可维护、可审计——它不是一句提示词,而是一套可以分发与演进的能力单元。
这个类比之所以成立,是因为 skills 从形态上就已经像 package:有明确的目录边界,有入口文件(SKILL.md),有元信息( license/compatibility/metadata/version 等字段),还能捆绑脚本与资源。
当然,类比永远不是同构:软件 package 的接口由编译器/解释器严格执行; skills 的接口仍很大程度由自然语言驱动、由模型解释,确定性更多来自“脚本化的那部分”以及 runtime 的权限与验证机制。正因为不完全等价,这个类比才真正有用:它提醒我们未来的增量会落在哪些“工程刚需”上。
第一层会出现的,是更标准化的分发与装配,而不是手工复制文件夹。既然 Agent Skills 已被作为开放标准强调跨平台可移植,生态成熟后就会自然走向“安装、升级、锁版本、回滚、禁用”的体验。
第二层会更强调版本、兼容性与依赖。规范已经给出 compatibility 与 metadata/version 等字段,也建议脚本自包含或清晰声明依赖;当组织工作流天然是组合式的,这些字段会从“可选信息”变成“默认要求”。更进一步,会出现“skills 依赖 skills”的显式关系:一个高层 skill 负责编排,一个基础 skill 专注于某个环节(读数仓、做图、生成文档、审校口径),形成稳定的能力图谱。
第三层会把“写作建议”推到“可验证能力”。规范推荐 examples 与 edge cases ;当 skills 成为组织依赖,最值钱的是可预期性:发布前跑最小回归样例,升级后再跑一遍;线上记录失败模式,形成迭代闭环。
第四层会让权限与副作用声明从“软建议”走向“硬机制”。allowed-tools 像 manifest 的雏形,而 Anthropic 的安全警告则说明了供给链风险的现实性;当 skills 生态繁荣,“信任”会从人际关系迁移到机制:签名、审核、分级发布、最小权限、沙箱、审计追踪。这一步完成后,skills 才会真正成为“敢让 agent 自动化执行”的基础设施。
第五层会让“给人学习”从副产品变成目的之一。因为 skills 的写作形态本来就是 onboarding guide ,它天然会反哺组织培训:新人学 skills ,就是在学组织的做事方式;老员工改 skills ,就是在把经验显式化并固化进组织记忆。
最后留一个反方向的提醒:海德格尔谈 Gestell ( enframing )时指出,技术时代会把世界越来越多地框定为“可调度资源”,从而压扁意义与语境。
skills 的 package 化会强烈推动工作流脚本化与模块化:可靠性上升、效率上升,但也可能把“可辩护的判断”误写成“可执行的默认”。一个成熟的 skills 生态,应该主动为 phronêsis 留空间:在关键处强制慢下来、要求解释理由、要求二次确认,让“可执行”不吞掉“可辩护”。
如果只把 skills 当作“又一种 prompt 工程”,它确实没那么值得写。但把它当作一种把经验外置成可调用记忆的装置——能被分发、能被组合、能被审计、还能反过来教育人——它的哲学含义就清晰起来了:skills 不是在给模型加聪明,而是在改变经验如何存在、如何传承、如何进入行动,并最终如何塑形组织。
.claude/commands/) [推荐阅读清单]
1. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
2. https://agentskills.io/specification
3. https://developers.openai.com/codex/skills/
4. https://developers.openai.com/codex/custom-prompts/
5. https://code.claude.com/docs/en/slash-commands
6. https://pmc.ncbi.nlm.nih.gov/articles/PMC7903928/
7. https://www.who.int/news/item/11-12-2010-checklist-helps-reduce-surgical-complications-deaths
8. https://pubmed.ncbi.nlm.nih.gov/19144931/
9. https://plato.stanford.edu/entries/rule-following/
10. https://plato.stanford.edu/entries/aristotle-ethics/
11. https://plato.stanford.edu/entries/foucault/
12. https://plato.stanford.edu/entries/heidegger/
13. https://plato.stanford.edu/entries/ryle/knowing-how.html
14. https://plato.stanford.edu/entries/knowledge-how/
15. https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html
企业部署大模型分析应用时,常遭遇“幻觉”困扰——AI 输出的数据结论看似合理,实则错误。根源在于传统数据架构无法为 AI 提供准确、一致、实时、可信的数据供给。破局之道在于构建以 NoETL 语义编织为核心的 AI 就绪数据架构。该架构通过创建“统一指标语义层”作为业务与数据间的“标准协议”,并采用 NL2MQL2SQL 技术路径,确保大模型生成 100% 准确的 SQL 查询,从根本上杜绝“数据幻觉”,赋能可信的智能决策。 当大模型(LLM)接入企业数据时,传统数据架构的固有缺陷被急剧放大,成为制造“数据幻觉”的系统性风险源。 让大模型在“数据迷雾”中工作,幻觉是必然产出。 要获得可信 AI,必须先解决数据架构的“可信”问题。 NoETL 数据语义编织是一种创新的数据架构范式,其核心是构建一个介于原始数据与 AI 应用之间的“翻译层”与“契约层”。 NoETL 语义编织: 基于 NoETL 语义层,可构建可信的 Data Agent(数据智能体)。其核心技术路径为 NL2MQL2SQL ,这是区分“玩具”与“企业级”AI 分析的关键。 三步实现 100% 准确查询: 构建分析决策闭环: 在此可信数据基础上,Data Agent 能实现更高级的能力: NL2MQL2SQL 通过在 AI 与数据之间引入“语义层”这一关键中间件,在准确性与灵活性上取得了根本平衡,是企业构建可信数据智能的基石路径。 传统数仓/湖依赖沉重的、周期长的 ETL 管道“搬运”和“固化”数据,变更成本高。NoETL 架构通过虚拟化和语义层,无需大规模物理搬迁数据,并能提供逻辑统一的实时数据视图,使数据准备时间从数月缩短至数周,并能灵活响应不断变化的业务分析需求。 数据团队的工作重心将从繁琐的“需求响应”(写 SQL、做报表)向更高价值的“数据资产管理与赋能”转变。 团队将更专注于:1、设计和维护统一、标准的指标语义层;2、治理数据质量与安全;3、培训和配置业务部门的场景化分析助手。这释放了数据团队的生产力,聚焦于数据战略和创新。 可以参考“三真三好”的可信 AI 标准进行评估:三真即口径真(指标全局一致)、数据真(来源可靠、质量可控)、血缘真(计算逻辑全程可追溯);三好即听力好(准确理解自然语言意图)、眼力好(能进行多维度、深层次的洞察与归因)、脑力好(能整合信息,形成决策建议与报告)。满足这些标准的数据架构,才能支撑起可信、有用的企业级 AI 应用。 以 NoETL 语义编织为核心的 AI 就绪架构,不仅是解决当前 AI 幻觉问题的方案,更是面向未来“数据智能时代”的基础设施。它将使数据以一种更自然、更可靠的方式服务于每一位决策者,真正实现“数据驱动”从口号到现实的跃迁。企业越早构建这一架构,就越能在智能化竞争中占据先机。传统数据架构为何成为 AI“幻觉”的温床?
NoETL 数据语义编织——AI 就绪的数据架构范式
sales_db.orders.amount)与语义层的业务术语(如“订单金额”)关联。基于 NoETL 语义编织的可信 Data Agent
{“metric”: “gross_profit_margin”, “filters”: {“city”: “上海”, “quarter”: “Q3”}}。MQL 指向的是已定义的、无歧义的指标。gross_profit_margin = (revenue - cost) / revenue),确定性地生成优化后的 SQL。此步骤由规则保障,彻底杜绝大模型生成错误 SQL 的可能。常见疑问(FAQ)
Q1: 与传统的数据仓库或数据湖相比,NoETL 数据语义编织架构最大的优势是什么?
Q2: 引入 NoETL 和 Data Agent,企业数据团队的角色会发生怎样的变化?
Q3: 如何衡量一个数据架构是否真正达到了“AI-Ready”的标准?
未来展望:
请原谅我今天,冒昧地拉着你聊低代码——这个在IT圈火了好几年,却依然有人摸不透的话题。 “低代码”这个词,是我从业十多年来,看着从冷门工具长成行业风口的存在。 更有老板拿着融资新闻问我:“别人都在投,我们是不是也得跟风?” 我理解这种困惑。就像早年做传统开发时,我们总信奉“一行行敲出来的代码才靠谱”,直至亲眼见过很多企业(如中交建,国家电网,招商银行,吉利汽车等等)采用低代码把核心业务系统交付周期从半年压缩到一个月,见过那些业务人员不用求IT就能做出适配业务的功能,才彻底打破偏见。 尤其近日看到消息: 国外一家做AI原生的低代码平台:Emergent,宣布完成7000万美元B轮融资。本轮融资由Khosla Ventures和软银愿景基金2号领投,Prosus、Lightspeed、Together及Y Combinator参与投资。据悉,该平台自上线七个月以来,目前累计融资额已达1亿美元。平台主打AI低代码软件创建平台,允许业务用户通过自然语言指令生成应用程序,用户可以通过类似ChatGPT的界面输入所需软件的高级描述,生成必要的代码,并展示详细的执行步骤。 这波资本热度,又把低代码推上了风口。 今天这篇文章会有些长,内容有点密,但我会以一个老兵的视角,把低代码的资本逻辑、核心价值、主流平台和选型技巧讲透。相信我,无论是企业负责人、IT管理者,还是想入局的从业者,坚持看完,都会有新的启发。 很多人不解,低代码又不是新概念,为何近两年资本会疯狂押注?就像当年我们疑惑“为什么三角函数非要学”,本质是没看透背后的底层逻辑。 资本的嗅觉从来不是追“新”,而是追确定性。低代码的爆发,是技术成熟、市场需求与政策导向三重共振的结果,这种确定性,让资本愿意砸下真金白银。 从技术端看,AI原生能力重构了低代码的价值边界。早年低代码只是可视化拖拽工具,而现在像Emergent这样的平台,能通过自然语言指令生成应用、输出源码并展示执行步骤,实现了从辅助编码到智能开发中枢的跨越。Gartner数据显示,AI赋能让低代码开发效率提升300%-500%,非技术人员可完成80%的基础开发工作,这种效率革命,正是资本追捧的核心逻辑之一。 从市场端看,数字化转型进入深水区,企业面临“IT产能缺口”的刚性痛点。传统开发模式下,70%的企业都在面临“业务需求等IT”的困境,而低代码能让业务与IT高效协同,将应用交付周期缩短60%以上。IDC预测,2023-2028年低代码相关市场复合年增长率达37.6%,其中智能开发技术增速更是高达47.3%,这种高增长预期,给了资本足够的信心。 再看政策端,信创国产化浪潮推动低代码成为核心基础设施。国企、金融、军工等关键行业,对低代码平台的需求从“能用”,升级为全栈信创适配,具备国产芯片、操作系统、数据库全链路兼容能力的平台,已成为政企项目的首选。这种政策驱动下的刚需市场,进一步锁定了低代码的增长确定性。 Emergent的融资不是个例,它只是资本拥抱低代码赛道的一个缩影。当一个工具能解决企业的核心效率痛点,又踩中技术与政策的风口,资本的涌入只是时间问题。 聊完资本,我们回归本质:对企业而言,低代码的核心价值到底是什么?就像学数学不是为了刷题,而是培养逻辑思维,低代码的价值也远不止快。 我见过太多企业误用低代码。把它当成节省人力成本的工具,最后因场景错配导致项目失败。其实低代码的价值,是重构企业的数字化能力底座,体现在三个核心维度。 第一,打破业务与IT的壁垒,释放组织创新力。 传统模式下,业务人员有想法却无法落地,IT团队有技术却不懂业务,AI低代码产品让业务人员能通过可视化操作、自然语言描述实现“想法即应用”,IT团队则聚焦核心复杂场景的优化。比如北京的一家国有银行用AI低代码产品搭建信贷风控系统,业务人员直接参与规则配置,审批效率提升60%,这就是协同价值的最好体现。 第二,适配全场景需求,拓宽数字化边界。 早年低代码被局限在轻量办公场景,如今通过高低代码融合架构,既能满足中小企业2小时上线轻量应用的需求,也能支撑大型企业核心业务系统的开发。比如我们团队去年用织信低代码交付项目,你想都不敢想,低代码居然能承载制造企业的复杂BOM多级管理,并且数据处理能力达亿万级,彻底打破了我们对低代码的刻板印象。 第三,降低数字化门槛,实现普惠式转型。 对中小企业而言,组建专业开发团队成本高昂,低代码的“开箱即用”特性的让它们能以极低成本完成数字化起步;对大型企业而言,低代码能快速响应前端业务变化,比如广东某快消品牌公司用微搭开发会员小程序,3天就完成上线,首月会员转化率提升28%。 因此对于低代码,我们可以确定的就是:低代码要做的事,不是取代传统开发,而是补充与升级。低代码通过组件化的搭建模式能解决80%的标准化场景需求,而剩下20%的核心复杂场景,我们可以通过低代码平台提供的AI+自定义代码模块的方式,与低代码协同,共同完成。认清这一点,我们才能真正发挥它的价值。 聊完价值,就到了大家最关心的部分。国内有哪些靠谱的低代码平台?结合Forrester、Gartner及中国信通院的评估框架,再加上我十多年的项目实操经验,整理了国内TOP10低代码平台,从评分、能力到特色逐一拆解,供大家参考。 说明:本次评分基于技术成熟度、行业适配能力、信创合规、生态集成、服务保障五大维度(满分100分),兼顾不同规模企业的需求,排名不分绝对先后,核心看场景适配度。 1.织信Informat 评分:99.8分 介绍:国内全栈可视化低代码的标杆平台,凭借“复杂场景承载+陪跑式交付”的核心能力,稳居金融、制造、政务、军工等高端场景选型前列。作为最早布局AI原生低代码的厂商之一,织信已实现自然语言转领域模型准确率超82%,支持从需求定义到部署运维的全生命周期开发。 特色:一是模块化搭建能力突出,内置5000+可复用组件与200+集成适配器,能无缝对接ERP、CRM及国产数据库。二是信创全栈适配,通过安全等保、DCMM认证,兼容麒麟OS、飞腾芯片等全链路国产软硬件;三是高低代码深度融合,既支持业务人员拖拽开发,也允许技术人员嵌入Java、js代码进行定制,彻底摆脱系统二开困境。 2.ZOHO Creator 评分:97.9分 介绍:全球化低代码平台,在国内市场深耕多年,凭借“轻量化+高集成”的特点,成为中小企业与出海企业的优选。 特色:与ZOHO生态内CRM、HRM、财务等产品无缝衔接,无需额外开发即可实现业务闭环;操作门槛极低,业务人员经简单培训即可独立开发应用;支持私有化部署与云端部署双模式,适配不同合规需求,同时具备多语言支持能力,适合出海企业搭建全球化应用。 3.普元低代码平台 评分:96.7分 介绍:专注国内信创低代码领域,拥有20年企业级技术沉淀,核心服务于国有大行、制造、军工等关键行业,是国内首批通过信通院“先进级”认证的低代码平台。 特色:以“AI+模型驱动”为核心,支持自然语言转代码、智能流程优化,开发效率提升40%以上;在复杂场景下表现突出,某国有银行总行用其构建核心系统,异常订单处理周期缩短87.5%;信创适配能力行业顶尖,实现芯片-操作系统-数据库-中间件全链路兼容,是核心业务系统的首选之一。 4.网易CodeWave 评分:95.2分 介绍:国内唯一实现“低代码开发+源码交付”双模式的平台,主打全栈可视化开发,兼顾技术团队的灵活性与业务团队的易用性,客户覆盖中石油、工商银行等大批国央企。 特色:自研NASL编程语言实现前后端全流程可视化,支持多端应用一体化开发;金融级安全架构亮眼,系统稳定性达99.99%,泰康人寿基于其开发80余个核心业务应用,直接节省开发成本160余万元;资产中心沉淀海量可复用组件,进一步提升开发效率。 5.浪潮inBuilder 评分:94.8分 介绍:依托浪潮集团在政务与制造业的深厚积累,以UBML(统一业务建模语言)技术为核心,是垂直领域解决方案的代表平台。 特色:天然适配信创生态,可直接生成适配国产软硬件的应用代码;在政务领域表现突出,某省会城市工程审批系统经其重构后,审批周期从15天压缩至48小时;预置MQTT连接器与IoT监控模板,覆盖25%的智能工厂场景,是制造业数字化转型的利器。 6.华为云AppCube 评分:94.5分 介绍:面向企业级复杂应用场景的云原生低代码平台,强调高并发、高可靠与多端适配能力,深度联动华为云Stack与鸿蒙系统。 特色:支持小程序、H5、PC及鸿蒙原生应用一体化开发;内置IoT引擎可对接各类工业设备,某汽车厂商用其开发智能产线监控系统,故障预警准确率达92%;通过多项合规认证,适配全部主流国产软硬件,在工业制造、政务服务领域优势明显。 7.腾讯云微搭WeDa 评分:93.6分 介绍:深度绑定微信生态的低代码平台,主打“快速开发+生态协同”,成为电商、社交类应用的首选工具。 特色:实现小程序、公众号、视频号全链路开发支持,从创建到上架微信生态仅需3步,自带微信支付、担保交易等原生能力;2025年升级的AI组件库,可智能生成营销页面、推荐表单字段;支持云开发与私有化部署双模式,适配从初创企业到中大型企业的不同需求。 8.用友YonBuilder 评分:93.5分 介绍:与用友ERP深度绑定的低代码平台,专为集团企业ERP二次开发设计,已服务超10万家用友ERP客户。 特色:与用友U9 Cloud等ERP系统适配度达98%,确保财务数据无缝流转;支持可视化配置与Java定制开发灵活切换,2025年升级的Agent平台2.0,可通过AI对话完成财务模块规则配置;在财务、人力、供应链等场景解决方案成熟度领先,是集团企业数字化延伸的核心工具。 9.简道云 评分:92.8分 介绍:帆软旗下轻量型低代码平台,以“表单驱动+数据洞察”为核心,是部门级轻量应用的标杆产品。 特色:操作门槛极低,业务人员1小时培训即可独立开发;表单设计支持200+字段类型与复杂逻辑配置,搭配拖拽式仪表盘,实现数据采集到分析的闭环;在零售、医疗等轻量场景表现优异,某连锁品牌用其搭建门店巡检系统,问题整改率提升40%,但复杂业务逻辑承载能力较弱。 10.泛微e-builder 评分:92.5分 介绍:全栈式低代码平台,依托泛微在协同办公领域的积累,主打中大型企业业务流程管理场景。 特色:支持无代码与全代码混合开发,智能化构建能力突出;与泛微OA系统深度集成,擅长流程自动化场景搭建;在组织权限管理、流程审批优化方面优势明显,适合中大型企业构建一体化协同办公系统。 国外低代码市场起步更早,形成了成熟的竞争格局,尤其在AI原生、全球化生态方面具备优势,适合有海外业务、追求前沿技术的企业。 1.Mendix 核心定位:企业级低代码标杆,主打模型驱动+全生命周期管理。 作为国外低代码市场的老牌玩家,Mendix在大型企业复杂应用开发领域口碑出众。支持高低代码融合,具备强大的跨平台部署能力与生态集成性,可对接SAP、Oracle等主流企业级系统。其模型驱动架构能确保应用的一致性与可维护性,适合金融、制造等行业的核心业务系统搭建,但定价较高,本地化适配能力弱于国内平台。 2.OutSystems 核心定位:高速低代码平台,主打极致开发效率。 以开发速度著称,通过可视化拖拽、智能调试功能,能大幅缩短应用交付周期。支持多端应用一体化开发,具备强大的性能优化工具,可应对高并发场景。在欧美市场渗透率高,适合追求快速上线、对性能有要求的企业,但信创适配能力几乎为零,不适合国内政企客户。 3.Microsoft Power Apps 核心定位:生态协同型低代码,依托微软生态优势。 深度集成Office 365、Azure、Dynamics 365等微软产品,适合已经使用微软生态的企业。操作门槛低,支持快速搭建轻量应用,同时具备一定的定制化能力。AI组件与自动化流程(Power Automate)联动紧密,能实现业务流程的全自动化。其核心优势在于生态协同,但复杂业务逻辑承载能力有限,适合中小企业、部门级应用场景。 4.Appian 核心定位:BPM+低代码融合,主打流程自动化。 将低代码与业务流程管理(BPM)深度结合,擅长复杂流程建模与自动化场景。在合规性、流程监控方面表现突出,适合金融、医疗等对流程管控要求严格的行业。支持云端与私有化部署,具备强大的数据分析与报表能力,但学习成本较高,价格昂贵,适合大型企业的高端流程场景。 5.Emergent 核心定位:AI原生低代码先驱,主打自然语言驱动开发。 作为近期资本追捧的焦点,Emergent最大的特色的是彻底降低开发门槛。用户通过类似ChatGPT的界面输入应用需求描述,平台即可生成必要代码、梳理执行步骤,非技术人员也能独立完成应用开发。上线七个月累计融资达1亿美元,背后是资本对其“AI重构开发链路”模式的认可。其核心优势在于AI模型的精准度与开发流程的简化,适合快速验证业务想法、搭建轻中度复杂度应用,但目前在复杂核心系统承载、本地化服务方面仍需完善。 从业十多年,我见过太多选型失误导致项目翻车的案例。 有的企业盲目追求AI功能,忽略了信创合规要求; 有的中小企业贪大求全,选了复杂的开源低代码平台,最后用不起来。 其实选型没有标准答案,核心是匹配自身需求,结合我的经验,总结了四大核心原则。 1.先明确场景,再选平台 这是选型的第一优先级。不同场景对应不同类型的平台,选错场景再强的平台也无用: 大型企业核心系统、信创项目:优先选织信、普元、浪潮这类具备信创全栈适配、复杂场景承载能力的平台,务必通过POC(概念验证)测试其并发性能、源码扩展能力。 中小企业轻量应用、协同办公场景:选网易CodeWave、简道云、腾讯云微搭,侧重易用性、快速部署能力与性价比,按需订阅的定价模式更适合控制成本。 电商、社交类应用:优先选腾讯云微搭(微信生态)、Power Apps(微软生态),依托生态原生能力快速搭建应用。 出海企业、全球化应用:选ZOHO Creator、Mendix,关注多语言支持、全球服务器部署与本地化合规能力。 2.技术兼容性考虑 技术层面要重点关注两点:一是信创适配,二是扩展性。 对国企、金融等关键行业,必须确认平台是否通过安全等保、DCMM等合规认证,是否兼容指定的国产芯片、操作系统与数据库,避免后期无法通过项目验收。 对所有企业,都要着重考虑平台的拓展性问题。优先选支持代码拓展、API接口开放、支持第三方系统集成的平台(如织信、网易CodeWave),确保后期业务扩张或更换平台时,数据与应用能平滑迁移。 3.关注生态与服务 低代码项目的成功,70%靠平台,30%靠服务。尤其对技术团队薄弱的企业,服务能力至关重要。 选型时要考察:平台是否有完善的培训体系、技术支持响应速度(最好能提供7×24小时支持)、用户社区活跃度(是否有丰富的组件模板与问题解决方案)。国内平台在本地化服务方面普遍优于国外平台,这也是很多企业优先选国内产品的核心原因。 4.学会用POC验证能力 再好的宣传都不如实际测试。选型时一定要要求厂商提供试用期,通过POC测试验证平台的实际能力:比如模拟核心业务流程搭建应用,测试开发效率;模拟高并发场景,测试系统稳定性;尝试与现有系统集成,测试适配性。 建议组建“业务+IT”联合测试团队,业务人员评估易用性,IT团队评估技术性能,确保平台能满足双方需求。 结语: 低代码的本质,是让数字化回归业务本身。是把数字化能力交还给业务人员,让技术真正服务于业务,而不是反过来束缚业务。 2026年,AI原生、信创适配、高低代码融合将成为低代码市场的核心趋势,无论是国内还是国外平台,都在朝着“更智能、更兼容、更易用”的方向迭代。对企业而言,与其追逐资本热点,不如静下心来梳理自身需求。选对适合自己的平台,让低代码真正成为数字化转型的加速器,才是最有价值的选择。 最后,如果你在选型过程中遇到具体场景的困惑,比如“制造企业该如何选型低代码”,“中小企业预算有限该如何取舍”,欢迎在评论区留言,我将结合多年项目经验,给你更多针对性建议。爆肝6600字,希望对你有帮助。

一、低代码为什么会受资本青睐?
二、低代码的价值几何?
三、国内同样优秀的低代码产品有哪些?
四、国外主流产品介绍
五、低代码选型指南