过去一年，国漫市场持续“破圈”。猫眼专业版数据统计，2025年国产动画电影（含合拍片）总票房达192.8亿元，在全部动画电影票房中占比75.7%，是2011年以来最高的一年。众多植根于东方美学的国漫作品，正以其独特的文化叙事，构筑起一代人的共同记忆。近期，合合信息旗下扫描全能王正式发起“国漫记忆守护计划”，鼓励用户从传统文化中挖掘国漫元素，为国漫创作提供灵感源泉。

传统文化是国漫创作的宝藏。从不拘天命的哪吒，到照见普通人悲喜的浪浪山小妖怪，这些角色成功唤醒了观众骨子里的文化亲近感。国漫这座“宝藏”仍有诸多领域静待挖掘，如今，越来越多的创作者正在从古籍插画、民俗文化中捕捉灵感，并通过扫描全能王记录保存，让碎片化的灵感沉淀为可随时取用的创作素材。

AI扫描技术为国漫存档“创意底片”

许多惊艳银幕的国漫作品，往往从一张手绘稿开始。艺术博主“参十川”（化名）在社交媒体平台分享了自己绘制的哪吒连环画系列。博主表示，当初为了理解这个经典角色，她专门前往图书馆查阅原著小说，最终将心中的“哪吒”落于纸上。借助AI扫描技术，这份9年前的作品能够以高清数字形态留存，成为国漫创作路上的珍贵印记。

                   图说：扫描全能王优化处理哪吒连环画系列作品

在国漫的视觉语言中，非遗文化同样是灵感“富矿”。英歌舞是潮汕地区的国家级非物质文化遗产，舞者脸谱以浓墨重彩区分忠奸善恶，为国漫创作提供了新的美学范式。设计师“羊言不会画画”（化名）受此启发，以细腻的线条勾勒出繁复的脸谱纹样。经过AI扫描技术处理后，这份诠释非遗文化的作品能够以最真实的模样被更多人欣赏。

                  图说：扫描全能王优化处理英歌舞脸谱创意绘画作品

基于AI扫描“黑科技”，扫描全能王能够将易磨损的纸质手稿、线条复杂的非遗纹样转化为高清的“数字档案”，让根植于传统的优秀创意被留存、被更多人看见，记录下一个国漫“爆款”的成长之路。

AI“提取线稿”从生活中汲取创作素材

国漫的生命力，不仅来源于专业创作者，更来自大众参与。扫描全能王致力于让国漫成为人人都可“DIY”的素材。无论是泛黄的小人书，还是张贴的国风海报，用户只需随手一拍，扫描全能王可一键生成清晰的黑白线稿，方便用户临摹、填色。

                           图说：扫描全能王精准提取线稿

年文化是国漫的重要表现内容，也是中小学生美学教育的组成部分。马年新春将至，艺术创作博主“小阳醒醒”（化名）将生肖马、中国结、葫芦等传统元素巧妙融合，创作出了一幅细节丰富的新春主题手抄报，作品分享到社交媒体平台后，不少家长和学生纷纷表示“寒假手抄报作业有救了”。

                     图说：扫描全能王高清记录手抄报创作细节

手抄报创作是学生的日常任务，却成了不少家庭的共同困扰。找素材费时、构图设计困难、手绘功底不足等问题让这项亲子活动变得压力重重。依托扫描全能王 “智能高清滤镜”“提取线稿” 等功能，家长只需拍摄手抄报参考模板，即可一键提取清晰线稿，为孩子的手抄报作业提供丰富的美学素材。

作为传统文化的重要载体，国漫的“破圈”，本质上源于其对神话、诗词、非遗等文化基因的成功解码与现代表达。扫描全能王将持续为用户带来AI扫描“黑科技”功能体验，将散落在创作草图、民间藏品中的文化灵感数字化，为艺术创作提供源源不断的灵感源泉，让传统文化与现代科技在融合中焕发新的生命力。

第一章 企业软件复杂度的逐步累积

1.1 从硬件导向到数据导向

早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者理解CPU指令、寄存器和内存地址，软件的表达方式高度依赖具体硬件体系结构，如SSE指令集中用于比较字符串的pcmpistr，无法运行在不支持SSE的CPU上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低，应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。随着电子工业的发展，计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键，在于找到一种足够通用的抽象方式。

1970年，来自IBM的E.F.Codd博士在ACM通讯杂志上发表的论文《大规模共享数据银行的关系型模型》，为解决这一问题提供了一种切实可行的技术路线。该路线中，现实世界中的业务单据、业务流程和管理决策，被统一抽象为数据的存储、处理与分析，而执行这些操作的软件被统称为“关系型数据库”。企业的用户只需要一个连接到数据库软件的终端，就能用一套近似于英语的、统一的语言来操作这个软件，以此实现所有的业务操作。如用户想要查询姓名中包含“李”的员工档案，需要输入 SELECT * FROM STAFFS WHERE NAME LIKE ‘%李%’ ，界面上就会呈现出纯文本呈现的员工档案信息。

图：早期的数据库服务器与操作终端

关系型数据库的出现，标志着企业软件第一次在抽象层面实现了规模化。通过关系模型描述业务实体及其关系，通过统一的数据操作语言处理不同业务场景，数据库成功降低了企业信息化的技术门槛，也显著扩展了软件需求的边界。

1.2 “壳”的出现与复杂度外溢

当数据库从档案管理走向财务、库存、成本核算等复杂业务场景时，一个新的问题随之出现：直接操作SQL对最终用户并不友好，一个业务操作需要多次打印和重复输入，导致操作员工作负荷高、出错概率大。为此，行业选择将数据库抽象为数据模型（数据模型可近似理解为数据库的结构，由数据表、列和表关系构成），在模型之上构建应用软件。这种做法很像是给数据库“套壳”，让用户操作应用，应用去操作数据库，而非用户直接操作数据库。

这一决策带来了企业软件形态的根本变化。业务逻辑开始在数据库与应用程序之间重新分配，用户交互界面成为差异化竞争的核心。随着抽象度更高的新一代高级语言（如C++、Java语言）在应用层的普及，企业软件正式进入“高级语言 + 数据库”的长期技术范式。

图：DOS时代的企业软件操作界面

然而，这种分层结构也埋下了复杂度累积的种子：

• 数据模型持续膨胀：一个小型订单管理系统可能只有十几张表，但经过几年演进后，堪比ERP的系统重，表数量可能增长到数百张
• 业务规则不断叠加：每次业务流程调整都会增加新的验证规则、计算公式和例外处理逻辑
• 交互逻辑日益复杂：从简单的表单录入发展到复杂的向导流程、多标签页面和实时校验
• 应用规模和生命周期显著拉长：企业软件往往需要运行十年甚至更长时间，期间不断打补丁和加功能

企业软件不再是一次性交付的工具，而是需要多年演进、持续维护的复杂系统。

扩展链接

写给技术管理者的低代码手册系列文章（1）——从软件工程视角理解低代码的价值、边界与演进路径

在企业级电子表格数据处理中，文本转换是高频基础操作——比如将数字、数组、布尔值等数据类型统一转为文本格式，用于报表展示、数据导出或公式解析。但传统转换方式往往存在局限：格式混乱不统一、数组转换繁琐、文本与公式栏解析不兼容等问题，导致数据处理效率低、出错率高。

GcExcel V9.0 重磅新增 VALUETOTEXT 和 ARRAYTOTEXT 两大文本转换函数，专为解决多样化数据的文本转换需求设计，支持单个值、数组、范围引用等全场景转换，提供灵活格式选项，完美适配报表生成、数据导出、公式编辑等核心业务场景，让数据文本转换更精准、更高效。

一、核心函数详解：双函数互补，覆盖全场景转换需求

1. VALUETOTEXT：单个值与范围的精准文本转换

VALUETOTEXT 函数专注于将单个数据值或单元格范围引用，快速转为标准化文本形式，适配不同展示与解析需求。

• 核心功能亮点

  • 支持多类型数据：可转换数字、文本、布尔值、错误值、空单元格、数组、LAMBDA函数等几乎所有Excel支持的数据类型。
  • 双格式可选：默认简洁格式（与单元格“常规”显示一致），满足日常展示需求；严格格式（文本用引号括起，内部引号自动转义），适配公式栏解析场景。
  • 范围批量转换：支持直接转换单元格范围（如A2:B4），无需逐个处理，提升批量操作效率。
• 应用场景：报表数据标准化展示、文本格式统一归档、公式编辑中引用文本数据、数据导出前的格式预处理。

• 使用示例：

  • 简洁格式：=VALUETOTEXT(A2:B4, 0)，将范围数据转为常规显示的文本，如数字“123.123”保持原样，文本“Apple”无额外引号。
  • 严格格式：=VALUETOTEXT(A2:B4, 1)，文本“Apple”转为"Apple"，数组{Milk, Egg, Cheese}转为"{Milk, Egg, Cheese}"，适配公式栏直接解析。

2. ARRAYTOTEXT：数组与范围的聚合文本转换

ARRAYTOTEXT 函数聚焦数组和大范围数据的聚合转换，将多值数据转为单一文本串，方便数据传递与展示。

• 核心功能亮点

  • 数组高效聚合：支持将一维/二维数组、单元格范围快速转为聚合文本，解决数组转换分散的痛点。
  • 双格式适配：简洁格式（值之间用逗号分隔，无额外符号），适合快速展示；严格格式（用行分隔符区分维度，文本加引号），可直接粘贴回公式栏复用为数组字面量。
  • 兼容复杂数据：即使范围包含错误值、空单元格，也能稳定转换，不中断操作流程。
• 应用场景：数组数据的文本化传递、多单元格数据的聚合展示、公式中复用数组文本、数据导出时的批量文本打包。

• 使用示例：

  • 简洁格式：=ARRAYTOTEXT(A2:B4, 0)，将范围数据转为“TRUE, #VALUE!, 123.123, Apple, {Milk, Egg, Cheese}, 100”。
  • 严格格式：=ARRAYTOTEXT(A2:B4, 1)，转为“{TRUE,#VALUE!};123.123,"Apple";"{Milk, Egg,Cheese}",100}”，可直接粘贴到公式栏作为数组使用。

二、技术优势：精准、灵活、兼容，适配企业级需求

GcExcel V9.0 新增的两大文本转换函数，延续了产品“高性能、高兼容、低代码”的核心优势：

• 转换精准无偏差：严格遵循Excel数据显示逻辑，数字保留原始精度，布尔值、错误值转换后保持辨识度，避免格式失真。
• 格式灵活适配：双格式选项覆盖“日常展示”与“公式解析”两大核心场景，无需额外编写格式处理逻辑。
• 全场景兼容：完美适配GcExcel现有功能（如公式计算、数据透视表、报表导出），转换后的数据可直接用于后续业务操作，无兼容性障碍。
• 低代码高效集成：函数调用语法简洁，无需复杂配置，现有工作表直接调用即可启用，开发者上手成本极低。
• 跨平台一致体验：Java与.NET版本同步支持，确保不同技术栈的企业都能获得统一的转换效果。

三、典型应用场景：赋能多行业数据处理效率提升

两大函数精准匹配企业高频数据处理场景，让文本转换融入业务全流程：

• 报表生成场景：将报表中的数字、布尔值、数组数据统一转为文本格式，确保展示风格一致，提升报表专业性。
• 数据导出场景：导出数据前，用严格格式转换关键文本，避免导出后因格式问题导致解析失败，适配第三方系统导入需求。
• 公式编辑场景：在复杂公式中，用严格格式转换文本数据，确保公式栏正确解析，减少语法错误。
• 数据归档场景：将分散的数组、范围数据聚合为单一文本串，便于数据存储与检索，降低归档复杂度。
• 跨系统数据传递场景：将Excel中的数组、多单元格数据转为标准化文本，作为接口参数或数据传递载体，提升跨系统兼容性。

四、使用注意事项：避坑指南

1. 格式参数仅支持0（简洁）和1（严格），未传参时默认使用0格式。
2. ARRAYTOTEXT 聚合转换时，空单元格会保留为空文本，错误值（如#VALUE!）会原样转为文本“#VALUE!”。
3. 严格格式下，文本内部的引号会自动转义（如原文本“He said "Hello"”转为"He said ""Hello"""），确保公式栏正确解析。
4. 转换后的文本数据可通过其他函数（如TEXTSPLIT）反向拆分，实现“转换-拆分”闭环操作。

结语

GcExcel V9.0 新增的 VALUETOTEXT 和 ARRAYTOTEXT 函数，彻底解决了传统文本转换的格式混乱、操作繁琐、场景覆盖不全等痛点，通过精准的转换逻辑、灵活的格式选项、全场景的兼容性，让数据文本转换成为高效业务流程的“助推器”。

扩展链接

针对 Excel 的 Java API 组件

最近发现个特好玩的事，不知道你们注意到没——国内那些叫得上名的AI厂商，什么Kimi、腾讯元宝、智谱、豆包…全都一窝蜂地，在微bo上把账号开起来了。

这可不是随便开个号发发公告那么简单。你仔细品，这背后其实是整个AI行业玩法彻底变了的信号。

竞争逻辑变了：从“跑分”到“跑流量”

想想前两年，AI圈的画风是什么样的？各家都在拼论文、拼参数、拼技术报告，恨不得在顶会上Battle个你死我活。那感觉，就像咱们程序员之间私下比谁的代码更优雅、算法更高效。

但现在，风向完全转了。战火已经从实验室和学术会议，直接烧到了用户的眼皮子底下。技术再牛，如果没人知道、没人用，那跟没写出来的代码有啥区别？微博，这个全网最大的“瓜田”和舆论场，就这么成了兵家必争之地。

为什么非得是微bo？

道理其实挺清楚的。在现在这个信息多到爆炸的环境里，再厉害的技术也得先 “被看见” 。微博比较到位的地方，就是它能瞬间制造热点，让一个话题几个小时内就怼到几亿人面前。

这对于急需建立公众认知、快速收集真实用户反馈的AI产品来说，简直是“神级测试环境”。你今天搞个活动，明天就能看到海量的、未经修饰的用户反应，这比任何封闭的内测数据都来得直接和猛烈。

你看，腾讯元宝撒10亿红包，立马全民狂欢；阿里的通义千问在微博上跟网友直接唠嗑，效果比开十场发布会都强。这都不是偶然的营销，而是一种系统的 “用户心智强攻”。

新阶段：从技术驱动到“生态位”抢夺

这件事往深了看，说明AI产业进入新阶段了：光有顶尖的模型（技术驱动）已经不够看了，现在得看谁更会搞生态、抓用户（生态与用户驱动）。

微博在这里扮演的角色，远不止一个广告牌。它是个 “复合型基础设施”：

产品试炼场：新功能丢上去，看看用户骂不骂。


巨型反馈池：海量的、最真实的吐槽和建议。


品牌加速器：能在短时间内把认知度打到顶。

AI公司在这里，相当于直接跳进了用户的老巢，进行最高效、也最残酷的对话。

机会
顺便吆喝一句，技术大厂[前-后端-测试]，待遇和稳定性还不错，感兴趣来~

热闹下的“冷思考”

当然，流量来得快，挑战也实实在在：

用户留存问题：红包吸引来的用户，怎么变成愿意长期用的铁杆粉丝？这比拉新难多了。


价值传递问题：在微博偏娱乐化的氛围里，怎么持续讲清楚你技术的硬核价值，而不只是玩梗？


预期管理问题：热度炒高了，万一产品有一点没跟上，反噬也会来得特别猛。

不过，不管挑战多大，这场集体“上微bo”的运动已经说明了一切：在中国，AI的竞争已经全面升维，变成了技术、产品、运营、品牌的全方位综合格斗。

所以，未来的赢家，很可能不单单是那个手握最牛算法的团队，更是那个最懂用户、最会玩转生态、最能把技术价值“翻译”成大众感知的玩家。微博上这场刚刚打响的“认知之战”，也许就在为未来十年的市场格局，悄悄写序章呢。

过去十年，上云曾是企业数字化转型的绝对共识。然而进入 2026 年，风向剧烈逆转：从 37signals 高调下云，到 IDC 报告显示超 80% 企业计划将部分工作负载迁回私有设施，一场名为云遣返的历史性迁徙正在发生。这并非技术倒退，而是算力经济回归理性的必然结果。在这场浪潮中，以 Codigger 为代表的分布式计算与云工作站平台，正为这场逃离公有云的运动提供关键技术支撑。
一、为什么要逃离云税？
公有云的初衷是让企业像用水电一样使用计算资源，但随着业务规模扩大，企业逐渐陷入昂贵的租赁陷阱。

1. 成本失控与云税：公有云本质是零售模式，厂商批发硬件后以高溢价卖给用户。对于长期运行的稳定业务，云租赁成本往往是自建成本的 3 到 5 倍，这就是行业所称的云税。
2. 资源利用率黑洞：企业为应对 5% 时间的峰值流量，需在 100% 时间里支付高配置实例费用，这种粗放配置导致巨大算力浪费。
   
   二、遣返的困境：回得去吗？
   虽然下云能省钱，但许多企业和开发者却不敢轻易行动 —— 自建基础设施面临繁琐运维、复杂网络配置等难题，还会失去云端即点即用的弹性体验。核心矛盾在于：企业需要公有云的使用体验，却不愿支付其高昂溢价。这正是 Codigger 要解决的问题：它不意味着回归原始机房运维，而是通过分布式架构，构建私有所有、公有体验的新型计算环境。
   
   三、Codigger 的解法：算力民主化与闲置经济
   Codigger 提出的理念是 “Own your compute. Rule your value.”，精准切中云遣返的核心诉求，通过三个维度重构本地与云的关系：
3. 资源最大化利用：传统本地部署受限于单机性能，而 Codigger 的分布式编译技术，可将重型构建任务瞬间分发到多个节点，打破物理硬件边界。无需为偶尔的编译需求购买顶级工作站，通过软件定义网格，就能充分挖掘现有硬件性能，让本地环境具备媲美公有云的弹性。
4. 闲置变现：公有云模式下，服务器闲置即是纯亏损；而在 Codigger 生态中，每个节点的闲置算力都可接入网络共享。个人休息时，高性能工作站可为他人提供算力支持赚取收益；企业层面，折旧硬件不再是电子垃圾，而是持续产生现金流的资产，从根本上改变基础设施的总拥有成本模型。
5. 按需计算：Codigger 提供灵活混合模式，用户平时可在本地或私有节点处理核心业务，确保数据主权与低成本；需要爆发式算力时，可无缝接入 Codigger 的高级节点网络，既保留云遣返的安全与成本优势，又规避本地硬件扩展性差的短板。
   
   四、结语：计算主权的回归
6. 年的云遣返浪潮，本质是计算主权的觉醒。开发者和企业逐渐意识到，算力不应被少数巨头垄断，也不应成为吞噬利润的黑洞。未来的计算架构，不会是中心化的单一云，而是像 Codigger 描绘的那样 —— 去中心化、互联且价值流动的算力网格。在这个网格中，用户不再是云厂商的租客，而是自身算力的主人。这不仅是技术的胜利，更是价值的回归。

在科学计算和工程模拟领域，如何高效、精确地预测复杂物理系统的演化，一直是学术界和工业界的核心难题。传统数值方法虽然在理论上能够求解大部分物理方程，但在处理高维、多物理场景或非均匀边界条件时，计算成本极高，且缺乏对大规模多任务的适应性。与此同时，深度学习在自然语言处理和计算机视觉领域的突破，引发了研究者们探索「基础模型」在物理模拟中的应用可能性。

然而，物理系统往往跨越多个时间尺度和空间尺度演化，而多数学习模型通常仅在短期动力学上进行训练，一旦被用于长时间尺度预测，误差便会在复杂系统中不断累积，导致模型不稳定。此外，不同尺度和系统异质性还意味着，下游任务对建模分辨率、维度以及物理场类型的需求各不相同，这对偏好固定输入形式的现代训练架构构成了巨大挑战。因此，迄今为止用于仿真的基础模型大多仍局限于相对同质的数据场景，例如仅处理二维问题，而非更符合现实的三维情形。

在此背景下，来自 Polymathic AI 协作组的研究团队引入了一系列新方法来应对上述挑战，包括：Patch jittering（补丁抖动）、面向 2D–3D 场景的负载均衡分布式训练策略，以及自适应计算标记化（Adaptive-compute Tokenization）机制等。以此为基础，研究团队提出了一个拥有 13 亿参数、以 Transformer 为核心架构、主要面向类流体连续介质动力学的基础模型 Walrus。Walrus 在预训练阶段覆盖了 19 种高度多样化的物理场景，涵盖天体物理、地球科学、流变学、等离子体物理、声学以及经典流体力学等多个领域。实验结果表明，无论在下游任务的短期预测还是长期预测中，Walrus 均优于此前的基础模型，并且在整个预训练数据分布范围内都展现出更强的泛化性能。

相关研究成果以「Walrus: A Cross-Domain Foundation Model for Continuum Dynamics」为题，已发布预印版于 arXiv。

研究亮点：

• Walrus 的模型参数规模达 1.3B，拥有创新的稳定化技术以及根据问题复杂度自适应计算的能力；
• 解决了当前连续介质动力学基础模型的若干局限性，例如成本自适应、稳定性以及在原生分辨率下对高度异构训练数据的高效训练；
• Walrus 是迄今为止最精确的连续介质仿真基础模型，在来自多个科学领域的 26 个独特连续介质模拟任务的多个时间尺度上，共跟踪的 65 个指标中有 56 个取得最佳结果。

论文地址：

https://arxiv.org/abs/2511.15684\
关注公众号，后台回复「介质仿真」获取完整 PDF\
更多 AI 前沿论文：\
https://hyper.ai/papers

构建异构、多维的高质量数据集

Walrus 的成功离不开多样性和高质量的数据。研究团队采用了来自 Well 和 FlowBench 的混合数据集进行预训练。Well 数据集提供了大量高分辨率、来源于真实科学问题的数据，而 FlowBench 则在标准流体场景中引入几何复杂障碍物，为模型提供复杂流动模式的学习机会。

研究团队总计使用了 19 个数据集，覆盖 63 个状态变量，包含不同方程、边界条件和物理参数化设置。数据维度涵盖二维与三维，确保模型在不同空间维度下的泛化能力。为了验证模型迁移能力，研究团队在预训练完成后，使用了部分保留数据集，包括 Well、FlowBench、PDEBench、PDEArena 和 PDEGym 的数据进行微调。数据切分遵循标准分割策略，或按轨迹划分为训练/验证/测试的 80/10/10 比例。

在训练设置上，Walrus 模型进行了约 40 万步预训练，每个二维数据集约 400 万样本，三维数据集约 200 万样本，使用 AdamW 优化器和学习率调度策略，实现对高维、多任务数据的高效学习。评价指标主要采用 VRMSE（标准化均方根误差）进行比较，可跨数据集、跨任务进行统一评价。

这种高度多样化的训练数据和策略，使 Walrus 能够在预训练阶段捕获丰富的物理特性，并为下游任务的跨领域泛化奠定基础。

基于时空因式分解 Transformer 架构

Walrus 模型采用时空因式分解 Transformer 架构（space-time factorized transformer），在处理时空张量结构数据时，分别沿空间和时间维度执行注意力操作，实现高效建模，流程如下图所示：

Walrus 流程图

• 空间处理：使用 Wang 提出的并行化注意力，并结合轴向 RoPE（Axial RoPE）进行位置编码。
• 时间轴处理：使用因果注意力结合 T5 风格的相对位置编。在空间和时间模块中均采用 QK 归一化（QK normalization）以提升训练稳定性。
• 计算自适应压缩（Compute-Adaptive Compression）：在编码器和解码器模块中，使用卷积步幅调制（Convolutional Stride Modulation, CSM）来原生处理不同分辨率的数据，通过调整每个编码/解码块中的下采样/上采样水平，实现灵活的分辨率处理。此前用于仿真的基础模型多采用固定压缩编码器，对下游任务中变化的分辨率需求不够灵活。CSM 允许研究人员调整卷积步幅进行下采样，从而选择与任务匹配的空间压缩水平。
• 共享编码器-解码器（Shared Encoder-Decoder）：所有同维度物理系统共享单一编码器与解码器，从而学习通用特征。二维与三维数据分别对应两个编码器和解码器，使用轻量级分层 MLP（hMLP）进行编码和解码。
• RMS GroupNorm 和非对称输入输出归一化：在每个 Transformer 块内使用 RMSGroupNorm 进行标准化，提高训练稳定性。输入与输出使用非对称归一化（asymmetric normalization）处理增量预测，保证不同场景的数值稳定性。
• Patch Jittering：通过对输入数据进行随机平移，并在输出端反向处理，减少高频伪影积累，显著提升长期预测稳定性，尤其在 ViT 风格架构中效果明显。
• 高效多任务训练：采用层次化采样和归一化损失函数，确保快速变化场的预测不会被慢速变化场主导，同时结合微批量和自适应 token 化策略，解决高维异构数据训练中的负载不均问题。
• 二维与三维统一表示：通过在二维数据上增加单维并零填充，将其嵌入三维空间，再通过对称性增强（旋转、反射）进行多样化扩增，实现跨维度训练能力。

总体而言，Walrus 架构不仅在空间与时间维度上高效处理张量数据，还通过多样化策略和高效分布式训练应对多任务、多物理场景的挑战。

Walrus 在多个二维和三维下游任务中表现出显著优势

为了验证 Walrus 作为基础模型的性能以及其在下游任务中的表现，研究人员设计了一系列实验：

①下游任务表现

与 MPP-AViT-L、Poseidon-L 和 DPOT-H 等现有基础模型对比，Walrus 在单步预测的平均 VRMSE 上降低约 63.6%，短期轨迹预测降低 56.2%，中期轨迹预测降低 48.3%，如下图：

各基础模型微调后在 2D 下游任务上的损失（中位数 VRMSE）

在非混沌系统中，Patch Jittering 带来的低伪影生成，使模型长期预测表现稳定；在更随机的系统（如 BubbleML 的 Pool-BoilSubcool）中，Walrus 虽然初期领先，但由于短期历史信息无法充分反映材料和燃烧器特性，长期滚动预测优势有所减弱。

三维任务尤其重要，因为大部分实际物理仿真场景为三维系统。Walrus 在 PNS（中子星合并后）和 RSG（红超巨星对流层）数据集上表现优异，即便这些数据集生成成本高达数百万核小时，如下图：

可视化微调后的 Walrus 在 3D 前沿科研级别模拟中的预测结果

②跨领域能力

Walrus 的跨领域能力也得到验证，与最优基线相比，Walrus 在单步预测上平均损失降低 52.2%。在对 19 个预训练数据集进行微调后，Walrus 在 18/19 个任务上取得最低单步损失，并在 20 步和 20-60 步的中期滚动预测中分别取得 30.5% 和 6.3% 的平均优势，如下表：

在不同时间范围内的损失（中位数 VRMSE）平均值

相比之下，DPOT 在声学和线性波传播任务中表现接近 Walrus，Poseidon 在无粘流任务中表现优异，但 Walrus 通过广泛预训练和通用架构，在大多数任务上都取得了竞争力甚至更优的结果。

③预训练策略影响

消融实验显示，Walrus 的多样化预训练策略对下游性能至关重要。即使在仅使用二维数据的半尺寸模型（HalfWalrus）上，经过全面空间与时间增强的预训练策略，在完全未见的新任务上仍明显优于从零训练或简单二维预训练策略的模型。

在三维 CNS 任务上，HalfWalrus 即使未见过三维数据，也能在极小数据量下取得小幅提升，而完整 Walrus 模型通过包含三维数据的预训练，取得了明显优势，强调了多维度、多样化数据的重要性。

Polymathic AI 加速跨学科人工智能应用的落地

在科学计算与工程建模领域，基础模型的潜力正在引发新一轮范式转变。Polymathic AI 是一个值得关注的开源研究项目，其核心目标是构建面向科学数据的通用基础模型，以加速跨学科人工智能应用的落地。

与面向自然语言或视觉任务的通用大模型不同，Polymathic AI 聚焦于连续动力学系统、物理场模拟、工程系统建模等典型科学计算问题。其核心思想是：通过大规模、多物理场、多尺度数据训练统一模型，使其具备跨领域迁移能力，从而减少每个科学问题从零构建模型的成本——这种「跨领域泛化能力」被视为科学 AI 的关键突破点。

据悉，Polymathic AI 汇集了一支由纯机器学习研究人员，以及领域科学家组成的团队，接受世界领先专家组成的科学咨询小组的指导，并由图灵奖得主、Meta 首席科学家 Yann LeCun 担任顾问，受到包括剑桥大学 AI+天文/物理助理教授 Miles Cranmer 在内的多位学术大咖的支持，以期集中精力开发科学数据的基础模型，利用跨学科的共享概念解决 AI for Science 行业难题。

2025 年，Polymathic AI 合作组成员展示了两款使用真实科学数据集训练的新人工智能模型，旨在解决天文学和类流体系统中的问题。其中一款为前文介绍的 Walrus，另一款则是首个面向天文学的大规模多模态基础模型家族 AION-1（天文全模态网络，AstronomIcal Omni-modal Network）。AION-1 通过统一的早期融合骨干网络，将图像、光谱和星表数据等异质观测信息进行集成建模，不仅在零样本场景下表现优异，其线性探测准确率也可媲美针对特定任务专门训练的模型，在广泛的科学任务中表现优异。即便仅通过简单的前向探测，其性能即可达到 SOTA 水平，在低数据量场景下更是显著优于有监督基线\
论文标题：AION-1: Omnimodal Foundation Model for Astronomical Sciences\
论文地址：https://arxiv.org/abs/2510.17960

总体而言，Polymathic AI 代表了「科学 AI 基础模型」这一新兴技术范式的前沿探索，其长期意义不仅在于性能提升，更在于构建跨学科知识迁移的通用计算底座，为「AI for Science」从工具级应用走向基础设施级能力奠定基础。

参考文献：
\
1.https://arxiv.org/abs/2511.15684
\
2.https://www.thepaper.cn/newsDetail_forward_32173693
\
3.https://polymathic-ai.org
\
4.https://arxiv.org/abs/2510.17960
\
5.https://www.163.com/dy/article/KGMRMMQM055676SU.html

写在前面

在万物互联的全场景时代，智能设备的形态正从手机、平板向车载、穿戴、智能家居等多端快速延伸，用户对交互体验的要求早已突破 “能用” 的基础阈值，转而追求 “自然、无感、高效” 的跨设备操作体验。手势交互作为一种摆脱物理按键束缚的自然交互方式，凭借其直观性和沉浸感，已成为 HarmonyOS 构建全场景生态的核心交互语言。HarmonyOS作为新一代面向万物互联的操作系统，不仅重构了多设备协同的底层逻辑，更在手势识别能力上完成了升级，它提供了一套轻量化、高适配的手势开发框架，让开发者仅通过几行代码就能实现丰富的手势交互，从而在不同设备上打造统一且流畅的用户体验。单一手势是 HarmonyOS 手势体系的基础单元，所有复杂的组合手势都由它演化而来。本文将从技术原理入手，系统拆解单一手势的类型、实现逻辑与设计原则，并结合真实场景代码案例，帮助开发者快速掌握这一核心能力，为打造全场景交互体验筑牢基础。

单一手势什么是？

在 HarmonyOS 的交互框架中，系统将通用输入事件划分为触屏、键鼠、焦点及拖拽等核心类型。而手势交互则是通过 “手势绑定方法 + 具体手势实例” 的组合来实现，根据交互复杂度又可细分为单一手势与组合手势两大类别。
单一手势是构成所有复杂交互的 “原子单元”，它仅通过单次、独立的触摸动作（如点击、滑动、按压）触发功能，是组合手势的基础组件，也是开发者入门 HarmonyOS 交互开发的第一课。

手势操作的类型及实现

关于单一手势操作的类型有点击、长按、拖动、捏合、旋转、滑动六大类型，具体实现如下所示。

1、点击手势（TapGesture）：交互的起点

点击手势是最基本的手势操作，支持单次点击和多次点击。通过TapGesture可以轻松实现按钮点击、菜单打开等功能，以下代码展示了如何实现一个双击操作：

@Entry
@Component
struct Index {
  @State value: string = "";

  build() {
    Column() {
      Text('双击').fontSize(28)
        .gesture(
          TapGesture({ count: 2 }) // 绑定双击事件，绑定count为2的TapGesture
            .onAction((event: GestureEvent|undefined) => {
              this.value = JSON.stringify(event.fingerList[0]);
            }))
      Text(this.value)
    }
    .height(200)
    .width(250)
    .padding(20)
    .border({ width: 3 })
    .margin(30)
  }
}

2、长按手势（LongPressGesture）：触发深度操作

长按手势常用于触发 “二次确认” 类功能，如长按复制、弹出操作菜单等，支持重复触发模式以实现连续交互。长按手势用于触发长按手势事件，通过LongPressGesture可以轻松实现长按复制等功能，以下代码展示了如何实现在Text组件上绑定可以重复触发的长按手势：

@Entry
@Component
struct Index {
  @State count: number = 0;

  build() {
    Column() {
      Text('长按').fontSize(28)
        .gesture(
          // 绑定可以重复触发的LongPressGesture
          LongPressGesture({ repeat: true })
           .onAction((event: GestureEvent|undefined) => {
              if(event){
                if (event.repeat) {
                  this.count++;
                }
              }
            })
            .onActionEnd(() => {
              this.count = 0;
            })
        )
    }
    .height(200)
    .width(250)
    .padding(20)
    .border({ width: 3 })
    .margin(30)
  }
}

3、拖动手势（PanGesture）：实现元素自由位移

拖动手势在滑动距离超过系统阈值（默认 5vp）时触发，常用于实现组件拖拽、位置调整等交互，核心是通过回调实时更新布局参数。拖动手势用于触发拖动手势事件，以下代码展示了在Text组件上绑定拖动手势为例，可以通过在拖动手势的回调函数中修改组件的布局位置信息来实现组件的拖动：

@Entry
@Component
struct Index {
  @State offsetX: number = 0;
  @State offsetY: number = 0;
  @State positionX: number = 0;
  @State positionY: number = 0;

  build() {
    Column() {
      Text('拖动')
        .fontSize(28)
        .height(200)
        .width(300)
        .padding(20)
        .border({ width: 3 })
          // 在组件上绑定布局位置信息
        .translate({ x: this.offsetX, y: this.offsetY, z: 0 })
        .gesture(
          // 绑定拖动手势
          PanGesture()
           .onActionStart((event: GestureEvent|undefined) => {
            })
              // 当触发拖动手势时，根据回调函数修改组件的布局位置信息
            .onActionUpdate((event: GestureEvent|undefined) => {
              if(event){
                this.offsetX = this.positionX + event.offsetX;
                this.offsetY = this.positionY + event.offsetY;
              }
            })
            .onActionEnd(() => {
              this.positionX = this.offsetX;
              this.positionY = this.offsetY;
            })
        )
    }
    .height(200)
    .width(250)
  }
}

4、捏合手势（PinchGesture）：控制元素缩放

捏合手势通过识别多指（支持 2-5 指）的距离变化计算缩放比例，是图片浏览、地图缩放等场景的核心交互方式。捏合手势用于触发捏合手势事件，常用于图片和地图的缩放操作，这里举例以在Column组件上绑定三指捏合手势为例，可以通过在捏合手势的函数回调中获取缩放比例，实现对组件的缩小或放大：

@Entry
@Component
struct Index {
  @State scaleValue: number = 1;
  @State pinchValue: number = 1;
  @State pinchX: number = 0;
  @State pinchY: number = 0;

  build() {
    Column() {
      Column() {
        Text('捏合')
      }
      .height(200)
      .width(300)
      .border({ width: 3 })
      .margin({ top: 100 })
      // 在组件上绑定缩放比例，可以通过修改缩放比例来实现组件的缩小或者放大
      .scale({ x: this.scaleValue, y: this.scaleValue, z: 1 })
      .gesture(
        // 在组件上绑定三指触发的捏合手势
        PinchGesture({ fingers: 3 })
          .onActionStart((event: GestureEvent|undefined) => {
          })
            // 当捏合手势触发时，可以通过回调函数获取缩放比例，从而修改组件的缩放比例
          .onActionUpdate((event: GestureEvent|undefined) => {
            if(event){
              this.scaleValue = this.pinchValue * event.scale;
              this.pinchX = event.pinchCenterX;
              this.pinchY = event.pinchCenterY;
            }
          })
          .onActionEnd(() => {
            this.pinchValue = this.scaleValue;
          })
      )
    }
  }
}

5、旋转手势（RotationGesture）：实现元素角度调整

旋转手势通过识别触摸点的角度变化计算旋转值，常用于图片编辑、表盘调整等需要角度控制的场景。旋转手势用于触发旋转手势事件，这里以在Text组件上绑定旋转手势实现组件的旋转为例，可以通过在旋转手势的回调函数中获取旋转角度，从而实现组件的旋转：

@Entry
@Component
struct Index {
  @State angle: number = 0;
  @State rotateValue: number = 0;

  build() {
    Column() {
      Text('旋转').fontSize(28)
        // 在组件上绑定旋转布局，可以通过修改旋转角度来实现组件的旋转
        .rotate({ angle: this.angle })
        .gesture(
          RotationGesture()
           .onActionStart((event: GestureEvent|undefined) => {
            })
              // 当旋转手势生效时，通过旋转手势的回调函数获取旋转角度，从而修改组件的旋转角度
            .onActionUpdate((event: GestureEvent|undefined) => {
              if(event){
                this.angle = this.rotateValue + event.angle;
              }
            })
              // 当旋转结束抬手时，固定组件在旋转结束时的角度
            .onActionEnd(() => {
              this.rotateValue = this.angle;
            })
            .onActionCancel(() => {
            })
        )
        .height(200)
        .width(300)
        .padding(20)
        .border({ width: 3 })
        .margin(100)
    }
  }
}

6、滑动手势（SwipeGesture）：触发页面级交互

滑动手势在滑动速度超过 100vp/s 时触发，支持上下左右四个方向，是列表滚动、页面切换等场景的核心交互。滑动手势用于触发滑动事件，可以实现上下左右滑动操作，常用于列表滚动和页面切换，以在Column组件上绑定滑动手势实现组件的旋转为例：

@Entry
@Component
struct Index {
  @State rotateAngle: number = 0;
  @State speed: number = 1;

  build() {
    Column() {
      Column() {
        Text('滑动')
      }
      .border({ width: 3 })
      .width(300)
      .height(200)
      .margin(100)
      // 在Column组件上绑定旋转，通过滑动手势的滑动速度和角度修改旋转的角度
      .rotate({ angle: this.rotateAngle })
      .gesture(
        // 绑定滑动手势且限制仅在竖直方向滑动时触发
        SwipeGesture({ direction: SwipeDirection.Vertical })
          // 当滑动手势触发时，获取滑动的速度和角度，实现对组件的布局参数的修改
          .onAction((event: GestureEvent|undefined) => {
            if(event){
              this.speed = event.speed;
              this.rotateAngle = event.angle;
            }
          })
      )
    }
  }
}

手势操作的设计原则

优质的手势交互不仅需要技术实现，更需要遵循用户体验设计的底层逻辑，核心原则可归纳为两点：自然直观和一致性。

1、自然直观

手势设计应模拟现实世界中的操作习惯，让用户能够凭借直觉进行交互，比如从屏幕底部边缘向上滑动返回主屏幕，这一操作类似于翻开书页的动作。

2、一致性

在整个HarmonyOS生态系统中，手势操作的含义和效果应保持一致，比如双指缩放手势在不同应用中都应实现放大或缩小的功能。

实战落地：单一手势在场景化开发中的典型应用

这里举两个简单的实用示例，方便各位学习使用。

1、音乐播放器应用

在音乐播放器应用中，用户可以通过左右滑动切换歌曲，双指缩放调整封面大小，以下代码展示了如何实现左右滑动切换歌曲：

@Entry
@Component
struct MusicPlayerSwipe {
  @State currentSongIndex: number = 0;
  @State songs: string[] = ['Song 1', 'Song 2', 'Song 3'];

  build() {
    Column() {
      Text(this.songs[this.currentSongIndex])
    }
    .swipe({
      start: SwipeDirection.Left,
      onSwipe: () => {
        if (this.currentSongIndex < this.songs.length - 1) {
          this.currentSongIndex++;
        }
      }
    })
    .swipe({
      start: SwipeDirection.Right,
      onSwipe: () => {
        if (this.currentSongIndex > 0) {
          this.currentSongIndex--;
        }
      }
    })
  }
}

2、手势截屏

手势截屏是另一个实用的功能，用户可以通过下滑手势调用全屏截图功能，通过双击手势调用区域截图功能，以下代码展示了如何实现全屏截图：

Stack() {
  Column() {
    ...
  }
  .gesture(
    PanGesture({
      fingers: 1,
      direction: PanDirection.Down,
      distance: CommonConstants.MINIMUM_FINGER_DISTANCE
    })
      .onActionStart(() => {
        let screenshotOptions: screenshot.ScreenshotOptions = {
          rotation: 0
        };
        screenshot.save(screenshotOptions, (err: Error, data: image.PixelMap) => {
          if (err) {
            Logger.error(`Failed to save the screenshot. Error:${JSON.stringify(err)}`);
          }
          if (this.pixelMap !== undefined) {
            this.pixelMap.release();
          }
          this.pixelMap = data;
          this.dialogController.open();
        });
      })
  )
}

最后

随着 HarmonyOS 6 的发布，全场景交互的边界正在被重新定义，单一手势作为交互体系的 “原子单元”，不仅是开发者构建基础交互的必备技能，更是打造复杂组合手势、实现多设备协同交互的核心基石。本文从技术原理、类型实现、设计原则到场景实战，系统拆解了 HarmonyOS 单一手势的开发逻辑。这些看似基础的交互能力，恰恰是构建 “自然、无感、高效” 全场景体验的关键：无论是手机端的流畅操作，还是车载、穿戴设备的极简交互，都离不开对单一手势的精准把控。对于 HarmonyOS 开发者而言，掌握单一手势的底层逻辑与实践技巧，不仅能提升应用的用户体验，更能为未来探索多设备协同手势、AI 增强手势等进阶能力筑牢基础。在万物互联的浪潮中，唯有以用户体验为核心，以技术实力为支撑，才能打造出真正适配全场景的优质应用。希望本文能成为你探索 HarmonyOS 交互开发的起点，在构建智能生态的道路上持续进阶。

最近咱们技术圈，又被一个叫 OpenClaw 的东西刷屏了。

话说，百度这个广告是真恶心啊！你们看懂了吗？

有人说它是“迄今为止最伟大的AI应用”，有人说它像个24小时在线的贾维斯。硅谷那帮人都在疯狂分享部署教程，国内大厂也火速跟进，百度智能云、阿里云都上架了一键部署的镜像。

简单说，这玩意儿就是一个能跑在你自己服务器上的超级AI智能体。和普通聊天AI最大的不同是，它不止会“说”，更会“做”。给它一个指令，它能自己思考、分解任务、调用工具，直到把事情干成——这简直就是我们梦寐以求的“数字员工”雏形。

看着这些热闹，我就在想：技术热点追不完，但咱能不能用它，为咱们自己的兄弟办点实事儿？

所以，我没犹豫，直接在自己的服务器上把它部署了，并且，把它接进了咱们的就业陪跑训练营大群。

给几百人的训练营，请一个24小时AI助教

说实话，部署过程比想象中简单。现在云厂商的生态做得真好，基本上就是选个镜像、配置下API Key（我用的是阿里云百炼平台）和端口的事儿。真正的挑战在于“接入”。

我的目标很明确：不是自己玩，而是要让群里几百个兄弟，能在微信、飞书里直接跟这个OpenClaw对话，让它成为我们集体的助手。

这里用到了阿里云的 AppFlow 应用连接器，它就像一个万能粘合剂，能把OpenClaw的“大脑”和企业微信、飞书的“手脚”连起来。

配置好Webhook，在企业微信群、飞书群里创建一个“智能机器人”，把线一连通——成了！

那一刻的感觉很奇妙。你看着一个正在席卷全球技术圈的前沿开源项目，经过一番折腾，变成了咱们自己群聊列表里一个朴实无华的机器人。技术的前沿感，和社群的烟火气，就这么碰在了一起。

当兄弟们开始“使唤”它，奇迹发生了

机器人刚上线，我发了个公告，简单介绍了它能干啥：解答技术问题、帮忙写代码片段、规划学习路径，甚至能联网搜索最新信息。

起初，兄弟们还带着点新奇和拘谨，问些测试性问题。很快，画风就变了。有人把面试中遇到的刁钻场景扔给它，让它分析；有人把一段报错日志贴进去，请求排查思路；还有人让它对比不同技术方案的优劣。

它真的像一个不知疲倦、随叫随到的助教，在群里随时候着。（这不就是当皇上的感觉吗？哈哈）

更让我触动的是接下来的事。有兄弟在群里@我提议：“阳哥，这机器人能联网，能不能让它每天自动抓取最新的AI资讯，翻译、汇总好了发到群里？ 咱们这群里都是学Go、Java想转AI的，最需要这种信息嗅觉。”

我看到这条消息，直呼牛批，帮我开阔思路了！

这不是一个简单的功能需求。这背后，是兄弟们不再把AI看作一个遥远的概念，而是开始思考如何让它融入我们的日常学习与成长流。他们不满足于被动接受我分享的内容，而是想借助我们亲手搭建的工具，主动去捕捉时代的脉搏。

这种从“围观者”到“构建者”和“使用者”的心态转变，比我看到任何人拿到高薪Offer都更让我高兴。因为这意味着，我们这群人，真的在从底层开始，理解和驾驭AI时代的生产力。

拥抱AI，不是追热点，而是换工具

这件事给了我很大的启发。以前我们聊AI，总感觉像是在讨论一个外部话题：大模型又有什么突破，哪个公司又融了多少钱。但OpenClaw这种“个人AI代理”的爆火，揭示了一个更本质的趋势：AI正在从“话题”变成“工具”，从“云端神祇”下凡成为“手边利器”。

对于我们程序员，尤其是像咱们训练营AI就业陪跑训练营 | 辅导到就业为止！里这些有志于抓住AI浪潮的工程师来说，真正的机会不在于高谈阔论，而在于：

1. 动手部署，获得体感：就像我亲自部署OpenClaw一样，只有亲手搭建、调试、解决那些依赖和网络问题，你才能对AI代理的能力边界、运行成本、现有局限有最真实的认知。这份体感，是任何教程都给不了的。
2. 思考集成，创造场景：单单部署一个AI大脑没意义。思考如何把它“接入”到你现有的工作流和社群中——是集成到钉钉/企业微信做团队助手，还是连接你的代码库做智能Review？这才是产生价值的关键。我们训练营群的“AI资讯需求”，就是最生动的场景创造。
3. 从用到改，参与塑造：OpenClaw是开源的。当你用起来之后，自然会遇到不满足的地方。这时，从“使用者”转向“改进者”甚至“贡献者”的路径就打开了。这，才是技术人最深的护城河。

兄弟们：一起走在时代的前沿！

所以，当我看着群里兄弟们开始自然地“使唤”那个机器人，并自发提出更有建设性的需求时，我深深感受到：

我们正在做的事情，早已超越了单纯的“就业培训”。

我们是在共同构建一个“现在进行时”的、能感知并利用最前沿AI生产力的技术社群。我们不仅在学AI的知识，更在直接使用AI的工具，并尝试用它来优化我们自身学习和获取信息的方式。

这种感觉，真好。

那个兄弟提出的“每日AI资讯摘要”需求，我已经开始着手研究了。我看到有现成的工具思路，比如用n8n这类自动化平台搭建工作流，从多个新闻源抓取信息，再用大模型进行总结和翻译。或许不久后，咱们群的OpenClaw机器人就能多这样一个定时推送的“情报官”功能。

兄弟们，时代的技术红利，从来不会平均地洒在每个人头上。它永远优先眷顾那些最早拿起新工具、并敢于用新工具来解决旧问题的人。

很荣幸，我能和你们一起，走在这样一条充满实践乐趣的前沿道路上。

来吧，咱们一起继续拥抱它，驾驭它，然后，一起升职加薪。

⚡️ 别把时间浪费在低效复习上

很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。

不搞虚的，全是干货。

加我微信：wangzhongyang1993，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。

一、什么是自治系统（AS）？

自治系统（Autonomous System，AS）是指在互联网上具有独立路由策略并且在全网范围内有统一管理的一个或一组IP网络的集合。每个自治系统都有一个独一无二的标识符，称为AS号（AS Number，ASN）。AS在互联网中扮演着至关重要的角色，它使得网络流量能够在不同的自治系统之间进行有效的路由。

自治系统的定义和管理由IETF（互联网工程任务组）和RIR（区域互联网注册管理机构）负责，并由全球互联网服务提供商和大型企业运营。在BGP（边界网关协议）中，AS作为一种路由单元，被用来识别互联网中的路由决策。

二、IP地址与自治系统（AS）的关系

每个IP地址都与特定的自治系统（AS）相关联。通过IP地址，我们可以推断出该IP地址所属的自治系统，并了解该IP地址的网络路径以及它在互联网中的位置。这对于进行网络分析、路由优化和网络安全等领域的工作至关重要。

IP地址与AS号的关联：每个自治系统在互联网上拥有自己的IP地址段。这些IP地址段会被分配给该自治系统的网络设备。当用户请求访问某个网站时，背后的IP地址可能就与特定的AS号挂钩。通过查询IP地址，我们可以获得该IP地址所在的AS号，进而了解该IP地址所属的自治系统。

AS号在网络中的作用：AS号是互联网路由的重要依据。BGP协议通过AS号交换路由信息，从而帮助网络流量选择最优路径。IP地址和AS号的关系使得网络运营商和开发者能够优化路由策略，避免网络瓶颈，提升用户体验。

三、如何查看IP地址所属的自治系统（AS）？

要查看一个IP地址所属的自治系统（AS），可以使用以下方法：

通过IP查询工具查询：

最简单的方法就是使用IP数据云、IPnews这样的在线IP查询工具，能够帮助开发者快速查询IP地址的详细信息，包括IP归属地、运营商信息、AS号、代理检测等。通过这些工具，用户可以准确地识别出IP地址所关联的AS号。

使用WHOIS查询：

WHOIS是一个通过域名或IP地址获取注册信息的协议。通过WHOIS查询工具，用户可以查看IP地址的注册信息，了解该IP地址所属的自治系统及其AS号。

BGP路由表分析：

BGP路由表中包含了全球所有自治系统的路由信息。通过分析BGP路由表，可以准确找到IP地址与AS号之间的关系。

四、IP地址与AS号在实际应用中的作用

IP地址与AS号的结合在多个实际应用中具有重要作用，尤其在网络安全、流量管理、路由优化等方面。

网络安全：

通过查询IP地址所属的AS号，网络安全专家可以识别出潜在的安全威胁。例如，某些恶意攻击往往来自特定的AS号，使用IP地址和AS号关联信息，可以帮助企业快速识别并阻止攻击。

流量分析与优化：

IP地址和AS号的结合可以帮助网络管理员了解流量的来源，并进行流量的有效调度。通过分析流量源的AS号，运营商可以优化网络架构，提升网络响应速度和稳定性。

广告定向：

在精准广告投放中，了解用户IP地址所属的AS号可以帮助广告商识别不同地区、运营商和网络环境的用户，从而定制更加精确的广告投放策略。

负载均衡与故障排除：

在大规模的互联网服务中，负载均衡和故障排除是保障服务稳定性的重要手段。IP地址与AS号的关联信息可以帮助系统管理员更好地进行流量调度和故障定位，确保服务的高可用性。

五、如何利用IP地址和AS号进行精确的网络管理？

动态IP和静态IP识别：通过查询IP地址所属的AS号，可以帮助网络管理人员识别动态IP和静态IP的区别，从而为用户分配更合适的网络资源。

基于地理位置的流量优化：结合IP地址和AS号的信息，可以为特定地区的用户提供更优质的访问体验。例如，某些AS号可能主要覆盖特定国家或地区，通过这些信息可以将用户流量导向距离更近的服务器。

多网络环境下的跨域分析：在复杂的网络环境中，IP地址和AS号的关联信息有助于进行跨域的流量分析与监控，帮助开发者快速识别跨域流量的来源。

六、结论

IP地址与自治系统（AS）的关系对于网络运营、管理、优化和安全等多个领域具有重要价值。通过了解IP地址所属的AS号，开发者和企业可以更精确地分析网络流量，优化路由策略，并提高网络的安全性。借助专业的IP查询工具，B端用户和开发者可以快速获取这些信息，并应用于实际场景中。

您好，我是 Silvana，一名前端开发工程师。

平时做网页时，默认的单选按钮总觉得少了点设计感，今天分享一个超简单的小技巧 —— 不用一行 JS，纯 HTML+CSS 就能做出带对勾、叉号的创意单选按钮，视觉效果精致，新手也能轻松上手。

这个小案例特别适合放在问卷调查、用户反馈这类场景里，替换掉单调的默认样式，让页面细节更出彩。下面是完整源码，每一行都加了注释，跟着敲一遍！

完整源码（带详细注释）

1. HTML 部分（index.html）

<!DOCTYPE html>
<!-- 声明文档类型为HTML5 -->
<html lang="en">
  <head>
    <!-- 设置字符编码为UTF-8，避免中文乱码 -->
    <meta charset="UTF-8" />
    <!-- 适配移动端，设置视口宽度为设备宽度，初始缩放比1.0 -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <!-- 页面标题 -->
    <title>创意单选按钮</title>
    <!-- 引入外部CSS样式文件 -->
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <!-- 容器：用于居中展示内容 -->
    <div class="container">
      <!-- 提示文字 -->
      <p>Do you like it ?</p>
      <!-- Yes选项：结合单选框和自定义对勾样式 -->
      <label>
        <!-- 单选按钮，name统一为btn保证互斥选择 -->
        <input type="radio" name="btn">
        <!-- 对勾样式的容器 -->
        <span class="check"></span>
        Yes
      </label>
      <!-- No选项：结合单选框和自定义叉号样式 -->
      <label>
        <input type="radio" name="btn">
        <!-- 叉号样式的容器 -->
        <span class="cross"></span>
        No
      </label>
    </div>
  </body>
</html>

2. CSS 部分（style.css）

/* 全局样式重置：清除默认边距、内边距，设置盒模型为border-box（宽高包含边框） */
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
/* 页面主体样式：弹性布局，内容水平+垂直居中，最小高度占满视口，背景色偏深 */
body {
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  background: #1e2b3b;
}
/* 容器样式：相对定位，弹性布局且纵向排列 */
.container {
  position: relative;
  display: flex;
  flex-direction: column;
}
/* 提示文字样式：白色、字体大小2em，底部间距10px */
p {
  color: #fff;
  font-size: 2em;
  margin-bottom: 10px;
}
/* label标签样式：相对定位，上下间距5px，鼠标移上去变手型，弹性布局垂直居中，字体大小2em，文字白色 */
label {
  position: relative;
  margin: 5px 0;
  cursor: pointer;
  display: flex;
  align-items: center;
  font-size: 2em;
  color: #fff;
}
/* 隐藏原生单选按钮 */
label input {
  appearance: none;
}
/* 对勾/叉号的基础容器：相对定位，行内块级，宽高30px，右边距15px，过渡动画0.5秒 */
label span{
  position: relative;
  display: inline-block;
  width: 30px;
  height: 30px;
  margin-right: 15px;
  transition: 0.5s;
}
/* 对勾/叉号的横线样式：绝对定位，底部左对齐，宽100%高3px，白色，底部阴影模拟另一条横线（初始状态），过渡动画0.5秒 */
label span::before {
  content: '';
  position: absolute;
  bottom: 0;
  left: 0;
  width: 100%;
  height: 3px;
  background: #fff;
  box-shadow: 0 -27px 0 #fff;
  transition: 0.5s;
}
/* 选中Yes时：对勾容器旋转+位移，形成对勾的视觉效果 */
label input:checked ~ span.check {
  transform: rotate(-45deg) translate(7px,-7px);
}
/* 选中Yes时：对勾横线变绿色，清除阴影 */
label input:checked ~ span.check::before {
  background: #0f0;
  box-shadow: 0 0 0 transparent;
}
/* 选中No时：叉号横线变红色，清除阴影，旋转+位移形成叉号的其中一条线 */
label input:checked ~ span.cross::before {
  background: #f00;
  box-shadow: 0 0 0 transparent;
  transform: rotate(-45deg) translate(10px,-9px);
}
/* 对勾/叉号的竖线样式：绝对定位，底部左对齐，宽3px高100%，白色，右侧阴影模拟另一条竖线（初始状态），过渡动画0.5秒 */
label span::after {
  content: '';
  position: absolute;
  bottom: 0;
  left: 0;
  width: 3px;
  height: 100%;
  background: #fff;
  box-shadow: 27px 0 0 #fff;
  transition: 0.5s;
}
/* 选中Yes时：对勾竖线高度减半、变绿色，清除阴影，完成对勾样式 */
label input:checked ~ span.check::after {
  height: 50%;
  background: #0f0;
  box-shadow: 0 0 0 transparent;
}
/* 选中No时：叉号竖线变红色，清除阴影，旋转+位移形成叉号的另一条线 */
label input:checked ~ span.cross::after{
  background: #f00;
  box-shadow: 0 0 0 transparent;
  transform: rotate(-45deg) translate(10px,10px);
}

小提示:
把这两个文件放在同一个文件夹里，直接打开 HTML 文件就能看到效果啦。如果想调整颜色、大小，只需要改 CSS 里对应的数值就行，比如把 #0f0（绿色）换成自己喜欢的颜色。

写着写着就到了结尾，祝您今晚有个好梦（代码少报错一点）。

*

本文由mdnice多平台发布

一、导语

在人工智能技术快速演进的时代，大型语言模型和AI智能体已成为各类应用的核心组件，引发AI相关API流量的指数级增长。而大模型网关，正是这场变革中应运而生的智能交通枢纽。

随着DeepSeek、Qwen等开源模型及各类商用大模型的普及，企业AI应用场景日益丰富，从智能客服自动化到代码生成与软件开发，从金融法律分析到内容生成引擎，AI正深度融入企业核心业务流程。

这种深度融合使得企业不仅使用SaaS化的LLM服务，更在私有化环境中微调、部署LLM模型，形成混合云架构，随之带来了多LLM适配管理、成本失控、数据安全和可靠性保障等系列挑战。

二、大模型网关：AI流量的智能调度中心

大模型网关是为AI工作负载专门设计的网关解决方案。它作为连接业务与AI基础设施的统一端点，为应用程序和模型之间的AI流量提供全面的管控能力。

与传统API网关不同，大模型网关针对AI请求的特有模式进行了专门优化。传统API网关专注于通用数据流量，基于RESTful API和静态请求响应设计，而大模型网关则专门应对AI工作负载的特殊需求，比如，长时与流式响应、复杂输入输出、高资源消耗与批处理、上下文与状态管理、专属监控与计量、关注成本与业务效果，等等。

大模型网关的核心能力主要体现在几个维度：模型市场、模型体验、模型调度、模型成本和稳定性（可观测性、容量管理、模型流控、服务告警）。

其中稳定性是大模型网关的“压舱石”，确保服务高可用、可管理、可追溯。容量管理可根据业务流量预估预先配置好足够的模型TPM额度，避免突发流量导致服务不可用或影响别的业务使用。模型观测提供实时监控每个模型健康状态、响应延迟、成功率等关键指标。模型流控可做到Key和模型粒度的TPM、QPS流量控制，一旦业务请求突破限流阈值，将依据流控规则进行限流。服务告警能力目标是借助Flink实时计算能力提供用户分钟级别的模型服务异常实时告警能力。

三、自建缘由：得物AI部署的四大挑战

随着AI在得物的应用场景不断深入，其帮助公司提升效率和降低成本的潜力被广泛挖掘。然而，我们在这一过程中面临一系列严峻挑战。

避免资源浪费并提升效率

在实际场景中，得物需要同时使用很多个AI模型，包括开源模型、商用模型及自建模型，这些模型的API接口、数据格式和调用方式各异。

如果每个业务域单独建设接入能力，会导致技术栈碎片化和重复开发，形成一个个“烟囱”，造成公司资源浪费。另外，如果每个开发团队都需要直接与各种AI模型的API对接，开发者必须学习每个AI API和AI平台，实现供应商特定的代码，会显著降低开发效率。

保障内外部模型成本可控

据估算，得物12月份调用大模型的Token消耗量已达数千亿规模，是1月份用量的20.63倍，仅Token调用单月成本就是一笔相当大的金额。若业务各自直接对接公有云模型服务，可能导致模型使用和成本失控。因此，必须依托大模型流量统一入口建设一套完整的成本管控体系。

保障接入外部模型数据安全

将敏感信息传输到外部LLM提供商引发了关于数据隐私、法规合规性（如PIPL和GDPR）以及潜在数据泄露的担忧。为了保障数据安全，我们考虑自建。

保障模型服务运行稳定可靠

模型网关需解决以下核心稳定性问题：

• 延迟与成功率波动：模型服务受底层算力限制，普遍存在低限流阈值，且响应延迟与调用成功率波动显著大于传统API。
• 基于Key的容量管理：模型服务通常设置固定限流阈值，易导致不同业务场景间流量相互挤占，影响全局可用性。
• 实时告警与可观测性：需在服务异常或触发限流时第一时间告警，同时完整记录请求日志（含Prompt及来源IP），便于问题追踪。
• 基于Token的精准限流：应建立以Token数量（而非调用次数）为基准的配额管理机制，从根源防止资源滥用，保障业务平稳运行。

四、行业实践：大模型网关的多元解决方案

大模型网关作为大模型应用的关键中间层，近年来随着企业级AI应用部署的加速而快速发展，以实现AI能力的统一、高效、可控管理。

目前市场上有多种大模型网关解决方案，它们在商业模式和核心能力上都各有特色。这里笔者将各类网关产品进行了梳理与汇总，以便读者大致了解行业现状。

AI网关主要参与者及产品

五、实施策略：构建企业大模型网关的六步法

对比行业落地大模型网关的案例，针对得物实际业务情况，在内部落地大模型网关时，我们制定了六个方面的策略。

打造信息丰富的模型市场

随着大模型在得物内的广泛深入应用，从B/C端创新到后端效能提升，场景愈发丰富复杂。加之自研/自部署（如 Qwen、DeepSeek）与内外厂商模型层出不穷，模型供给呈现分散与混乱，业务选型门槛抬高，往往从调研、验证到上线需耗时1~2天，极大增加了业务接入AI的难度。

为此，网关对接入模型进行统一梳理，打造信息完备的“模型市场”。本质上是一个“AI 模型应用商店”，将分散混乱、高门槛的选型流程，重构为集中、透明、可量化评估的标准化路径。

大模型市场

通过统一模型市场，网关构建覆盖发现、评测、验证与集成的完整闭环：

• 模型纳管：集中管理来自自研与内外部厂商的多样化模型，形成内部“模型货架”，消除信息碎片；原生支持托管与上云对接。
• 评测对比：支持文本生成、图像理解/生成等对比测试，可将真实业务问题一键投递给多模型直观比拼，显著降低试用门槛。
• 一站式接入：选定模型后即可查看 API 接入指南，完成“选型-试用-接入”的闭环，大幅提升对接效率。
• 运营与推荐：提供模型推荐能力，按效果与性价比打标、置顶，缩短选型时间并助力降本。

通过建设模型市场，实现了模型接入的统一化与标准化，模型上架和接入效率显著提升。模型上架时间从1~2天降低到 10 分钟内，试用从 1 天降低到 5 分钟以内。

统一各业务模型服务入口

通过建设OpenAI like风格的统一访问API和模型服务调度能力，网关将绝大部分AI模型服务的访问集中到单一入口，使不同业务线无需关注后端模型的具体实现细节，也能实现不同厂商模型服务之间的容灾。

模型调度策略与OpenAI like风格API

建设全流程成本管控体系

在成本治理和优化上，围绕“源头管控、成本感知、模型调度、厂商折扣和成本监控”等方面着手闭环能力搭建。打通了从预算申请、模型选型、接入调用，到运行观测、成本结算的全链路，实现了精准的成本治理与优化。

具体表现为，在3、4季度token用量分别较前一季度增长2.52倍和2.16倍的情况下，每百万Token的成本分别降低50%+和45%+，降本额度也相当可观，达到数百万元，在保证业务体验的前提下有效压降了模型使用成本。

总体降本思路&策略

目前正在搭建精细化降本能力，其核心思路是：通过构建Key/模型/厂商/项目维度的成本大盘、构建各外部厂商各类别模型均价大盘（发现更有性价比的模型）、建设用量和成本每周主动推送机制、完善成本预警/告警体系等措施，促使业务依据成本和价格数据主动进行成本治理。

全流程降本能力体系

持续夯实稳定性架构能力

在架构能力建设上，围绕“高可用、可控成本、稳定体验”三大目标，重点建设了限流、调度和容灾三类核心架构能力，可实现分钟级容灾切换，为大规模、多模型、多业务场景下的稳定运行提供基础保障。

• 容量管理与限流

通过建设模型容量的配置化管理机制，实现按Key/项目等维度的TPM容量管理体系；若业务流量（token）超过阈值，便触发限流及容量告警。

• 模型调度与容灾

模型调度能力可帮助我们实现厂商间模型粒度的分钟级容灾。具体做法是：若检测到当前API Key配置有模型调度策略，则模型调度器便将请求按配置规则执行调度，并将选中的模型交付给模型路由模块，由路由模块封装后将请求转发到对应厂商的模型服务实现。

模型调度与路由

建设分钟级实时观测能力

在AI规模化应用时代，没有分钟级观测体系的模型网关，就像没有仪表盘和刹车的F1赛车——速度越快，风险越大，毁灭性越强。因此，必须建设完善的模型调用/用量/成本的分钟级观测（监控+告警）体系。

• 模型调用/用量/性能观测。目前已实现Key和模型粒度的模型调用、token用量的监控大盘，如下图所示：

调用/用量监控分时（基于Key）

调用失败率和平均RT（基于Key）

RPM/TPM监控分时（基于Key）

端到端平均RT监控分时（基于Key）

用量监控分时（基于模型）

性能监控分时（基于模型）

• 模型成本观测。模型成本观测方面，正在实现模型、Key、厂商、项目等粒度的实时监控大盘，以及日/周/月/指定时间维度汇总的成本数据大盘。
• 模型异常告警。模型服务告警方面，当前正在基于Flink实施计算和Kafka事件订阅机制建设一套基于模型和Key的实时告警体系，让业务对自己的模型调用异常能在3分钟以内通过飞书告警感知。

建设Key生命周期管理能力

通过API Key管理产品化能力建设，实现了API Key申请工单及自动分发、Key场景/负责人/共享人/状态管理和黑名单功能，并依托API Key实现接口鉴权、预算管理（预算分配/预算消耗/预算预警）、容量管理、模型调度等核心功能及关键流程节点的规范化管理。

六、创新亮点：大模型网关的核心技术突破

模型网关瞄准“效率-成本-稳定性-安全&合规”着力平台建设，并继续在成本管控、模型接入效率、服务稳定性、模型监控/告警等方面持续创新：

• 构建全流程成本管控体系。 通过预算与 API Key 申请自动化、用量监控、成本展示、超额预警与告警、智能调度、用量与成本大盘等能力，形成“预算申请—调用监控—预算预警—模型调度—费用查看”的闭环管控。

• 实现跨厂商的模型级容灾。 通过在网关配置显式或默认的调度策略，将请求优先分配至性价比更高的模型，既实现不同厂商间的模型级容灾，也成为降本利器。

• 实现厂商无感的接入体验。 网关统一分发 API Key 并提供统一的模型服务 API，业务无需关心各厂商的入参/出参差异，即可获得一致的接入体验并显著提升效率。

• 便捷高效的模型选型体验。 依托模型市场、试用预算池、试用与效果对比、推荐板块等功能，在控成本前提下为用户提供快捷选型路径，助力在层出不穷的模型中快速锁定理想方案。

• 分钟级用量与成本观测。 已构建近实时（分钟级）运行监控，覆盖调用量、失败次数/率、RT、TPM、RPM等关键指标；并在开发基于 Key 与模型粒度的成本实时观测与离线报表，支持按周将成本汇总推送给调用方。

七、应用收益：从成本节约到效能提升

得物部署大模型网关后，经过「模型网关升级」项目建设，取得如下效果：

(1) 网关平台从0~1搭建起来。 模型网关从单一的纯后台服务进化为面向管理员和研发/产品/运营用户的平台化产品；不再只是模型访问的“管道”，而是集模型集市、模型调度、成本治理、创新实验于一体的支撑整个组织进行AI创新的入口平台。

(2) 内外部模型100%纳管。 从0~1建成对接得物（KubeAI）百度/阿里/字节/华为/微软/谷歌模型服务的模型集市，完成内外部模型100%纳管，新模型上架/接入只需在平台一键配置，无需新写实现逻辑。

(3) 模型接入效率提升97%。 管理各云商和自建模型140个，单模型平均上架时间从1~2天降低到 10 分钟内，接入效率提升97+%；模型试用与效果评估过程从 1 天降低到 5 分钟以内，效率提升98%+。

(4) H2节省成本数百万元。 依托模型调度切换能力和统一API建设，以及降本方法论推广，Q3、Q4在用量均较前一季度翻倍的情况下，实现每百万token成本连续分别降低51.52%和48.37%。两季共实现降本额度达数百万元，并且随着用量增加降本收益将越来越明显。

八、未来展望：从大模型网关向AI网关演进

大模型网关的未来发展将向如下几个方向演进：

首先，模型网关继续承担大模型成本管控主体责任，继续通过强化数据分析能力推进精细化降本，落地Qwen系列自建模型通过云商托管方式降本。

其次，围绕标准化与生态兼容，网关将引入并适配 MCP（模型上下文协议）；实现API同时兼容多厂商与多形态模型（文本、图像、语音、视频与多模态），在保持一致体验的前提下实现跨生态的无缝互通与扩展。

另外，API网关正从单纯的流量管理工具转变为AI编排平台，将在已有的模型调度能力基础上建设更强大的工作流与多模型协同机制，能根据成本、延迟、准确性，将请求分配给最优AI模型。

最终，模型网关将不再是一个“网关”，而是企业智能化的“神经中枢”——它不直接思考，但确保思考过程高效、安全、经济地发生。

结语：

未来的技术方向已经清晰——大模型网关不是API网关的替代品，而是其演进形态。随着AI逐步嵌入各类应用，企业选择可扩展的大模型网关平台，将避免被孤立在特定AI生态中，获得技术架构的长期竞争优势。

往期回顾

1.从“人治”到“机治”：得物离线数仓发布流水线质量门禁实践

2.AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术

3.入选AAAI-PerFM｜得物社区推荐之基于大语言模型的新颖性推荐算法

4.Galaxy比数平台功能介绍及实现原理｜得物技术

5.得物App智能巡检技术的探索与实践

文 /禹极

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

前面两篇我已经介绍了如何在Smoothcloud润云一键使用ComfyUI镜像以及ComfyUI基础版玩法，现在来介绍一下进阶版玩法。

一、图生图

要在 ComfyUI 中使用图生图的工作流，我们需要先创建一个上传图像的节点，也就是 Load Image 节点。

在画布空白处点击右键，依次选择 Add Node > image > Load Image 就可以创建一个 Load Image 节点。

然后，还需要创建一个 VAE Encode 节点，同时删除 Empty Latent Image 节点。

依然是在画布空白处点击右键，依次选择 Add Node > latent > VAE Encode 就可以创建一个 VAE Encode 节点。

随后，将 Load Checkpoint 节点的 VAE 属性连接到 VAE Encode 节点的 vae 属性，将 Load Image 节点的 IMAGE 属性连接到 VAE Encode 节点的 pixels 属性，最后，将 VAE Encode 节点的 LATENT 属性连接到 KSampler 节点的 latent_image 属性即可。
具体可以参考下图。

二、画作修复

相对于文生图和图生图工作流，我们可以来看看更复杂的工作流，也就是修复画作（Inpainting）。

Inpainting 可以用于替换或编辑图像中的特定区域，比如去除缺陷和伪影，甚至用全新的内容替换某个区域，它依赖于遮罩来确定图像中需要填充的区域。

我们可以直接延用上一步图生图中的工作流，然后按照下面的步骤来操作：

1. 在 Load Image 节点中上传想要修复的图像，右键单击选择 Open in MaskEditor；

2. 在图像上对想要重新生成的区域设置遮罩，也就是用鼠标画阴影；

3. 随后点击 Save 即可；
4. 双击出现搜索框，输入 Set Latent Noise Mask 选择创建一个节点；

5. 重新创建连接：
6. 将 Load Image 节点的 MASK 属性连接到 Set Latent Noise Mask 节点的 mask 属性；
7. 同时，修改 VAE 节点的 LATENT 连接到 Set Latent Noise Mask 节点的 samples 属性；
8. 将 Set Latent Noise Mask 节点的 LATENT 属性连接到 KSampler 节点的 latent_image 属性；
9. 定义修复过程，也就是在 CLIP Text Encode 节点中输入提示语信息来引导修复画作的方向；
10. 设置 denoise 参数，比如我们设置 0.6；

11. 最后点击 Run 即可。

    

前言

本文主要讲解 RBAC 后台系统中的按钮级权限控制

本文是《通俗易懂的中后台系统建设指南》系列的第十一篇文章，该系列旨在告诉你如何构建一个优秀的中后台管理系统。

RBAC 权限细粒度

在前两篇文章：RBAC 权限系统实战（一）：页面级访问控制全解析、RBAC 权限系统实战（二）：权限信息管理的设计 中，我们在后台系统里已经实现了权限控制，但从权限细粒度的角度看，我们只做了“页面级”权限

在权限细粒度中，一般有这三种权限粒度：

1. 页面/菜单级：用户是否能看到并访问该页面
2. 功能/操作级：进入页面后，是否能执行某个动作（比如按钮权限）
3. 数据级：可以操作哪些数据范围（本人/部门/全部等）

在某些业务场景下，我们希望用户能看到/进入页面，但不一定能操作所有功能。比如同一个列表页：A 只能“查看”，B 可以“新增/编辑”，C 还能“删除/导出”

因此本文主要实现操作级权限控制，也常称为“按钮级权限控制”

权限码设计

在第一篇权限文章中，我们在登录后，会请求用户信息接口，拿到用户的菜单路由数据再渲染访问

现在，还是基于这个接口返回的用户信息，我们要增加一个字段：permissionCodes，它是一个字符串数组，代表该用户拥有的操作权限

我这里使用的是 ApiFox 来模拟的接口和数据，ApiFox 文档可以访问：vue-clean-admin ApiFox 文档，内有关于”获取用户信息接口“的文档介绍

你可以看到，返回的权限码列表遵循一定的格式来确保语义清晰，我们约定，权限码的格式如下：

比如下面的菜单模块，关于新增、详情的权限码：

当然，不是说不遵守这个格式就不行，但我推荐这种格式。可以让我们在代码里更清楚地理解权限码含义，也方便后续维护

还要考虑一种情况：某个角色不管系统有多少权限都可以访问，比如超级管理员 superAdmin，对于这样的角色，我们做点特殊处理，比如用通配符 * 表示全部权限（如 *:*:*）。这时无需再做权限筛选，直接放行即可

按钮级权限实战

在操作级权限设计中，在 Vue 框架下，有三种实现按钮级权限的方式：组件式、自定义指令、函数式

1. 组件式：编写 Vue 组件，插槽内容由权限码属性决定是否渲染
2. 自定义指令：通过指令控制 DOM 来实现元素显隐
3. 函数式：在函数中写权限筛选逻辑，上面两种方式都会依赖它

函数式

函数式写法最常见，把权限判断封装成工具函数或 hook 都可以。先看一个实现：

import { useUserStore } from '@/store/modules/user';
import { PermissionCode } from '#/type';
import { storeToRefs } from 'pinia';
import { isEmpty } from '@/utils';

export const useAuth = () => {
  const userStore = useUserStore();
  const { getPermissionCodes } = storeToRefs(userStore);

  //...

  /**
   * 判断是否有权限
   * @param code 权限码，可以是单个权限码字符串，也可以是权限码数组
   * @returns 是否有权限
   */
  const hasPermission = (code: PermissionCode): boolean => {
    // 如果是特殊通配符，直接放行
    if (getPermissionCodes.value.includes('*:*:*')) return true;

    // 空字符串、空数组情况，默认为无权限
    if (isEmpty(code)) return false;

    const codes = Array.isArray(code) ? code : [code];

    // 只要满足其中一个权限码即可
    return codes.some((c) => getPermissionCodes.value.includes(c));
  };

  return {
    hasPermission,
  };
};

在 use-auth.ts 找到实战代码

这里我把逻辑写成一个 hook，重点关注 hasPermission 方法。它接收权限码参数 code，返回一个布尔值，表示是否有权限

getPermissionCodes 表示当前用户拥有的权限码

code 参数既可以是单个字符串，也可以是数组。因为用户可以同时拥有多个权限码（如 user:add、user:edit），所以类型定义如下：

/**
 * 权限码类型
 */
export type PermissionCode<T = string | string[]> = T;

实际场景中，可配合 v-if 来控制元素显隐：

组件式

组件式很好理解：把“权限判断”封装成 Vue 组件，内部内容由权限码决定是否渲染。

这里用 AppAuth 组件示例：

<script setup lang="ts">
import { PermissionCode } from '@/types/common';
import { computed } from 'vue';
import { useAuth } from '@/hooks/useAuth';

defineOptions({
  name: 'AppAuth',
});

export interface AppAuthProps {
  /**
   * 权限码
   */
  codes: PermissionCode;
}

const props = withDefaults(defineProps<AppAuthProps>(), {
  codes: '',
});

const { hasPermission } = useAuth();

/**
 * 是否有权限
 */
const hasAuth = computed(() => {
  return hasPermission(props.codes);
});
</script>

<template>
  <slot v-if="hasAuth" />
  <slot v-else name="no-auth" />
</template>

在 app-auth.vue 找到代码实现

在频繁使用的场景下，最好全局注册该组件：

// main.js
import { createApp } from 'vue'
import App from './App.vue'
import AppAuth from './components/AppAuth.vue'

const app = createApp(App)

// 全局注册
app.component('AppAuth', AppAuth)

app.mount('#app')

全局注册组件时要补上 TypeScript 的类型提示，我在 src/typings/app-components.d.ts 中添加了类型声明：

export {};

declare module 'vue' {
  export interface GlobalComponents {
    //...
    AppAuth: (typeof import('../components/common/app-auth/index'))['AppAuth'];
  }
}

然后就可以直接使用 AppAuth 组件了：

当用户没有权限时，会渲染 no-auth 插槽的内容，可以在 no-auth 插槽中自定义展示内容。

自定义指令

自定义指令也是一种很方便的实现方式，通过操作 DOM 来实现元素显隐

通过 app.directive 方法来注册 v-auth

// directives/auth.ts
import type { Directive } from 'vue';
import type { PermissionCode } from '@/types';
import { useAuth } from '@/hooks/useAuth';

export type AuthDirective = Directive<HTMLElement, PermissionCode>;

export const authDirective: AuthDirective = {
  mounted(el, binding) {
    const { hasPermission } = useAuth();
    if (!hasPermission(binding.value)) {
      el.remove();
    }
  },
  updated(el, binding) {
    const { hasPermission } = useAuth();
    if (!hasPermission(binding.value)) {
      el.remove();
    }
  },
};

在 directives/modules/auth.ts 找到代码实现

然后在 main.ts 中注册 v-auth 指令：

// main.ts
import { createApp } from 'vue';
import App from './App.vue';
import { authDirective } from './directives/auth';

const app = createApp(App);
app.directive('auth', authDirective);
app.mount('#app');

同样要补上全局指令的类型定义，在 src/typings/directive.d.ts 中添加类型声明：

import type { AuthDirective } from '@/directives/typing';

declare module 'vue' {
  export interface GlobalDirectives {
    vAuth: AuthDirective;
  }
}

然后就可以使用 v-auth 指令来实现权限控制：

菜单管理、角色管理

在权限实战第二篇：RBAC 权限系统实战（二）：权限信息管理的设计 中，实现了菜单、角色管理的基本管理操作，比如菜单 CRUD、角色绑定权限等操作

从细粒度来看，我们现在多做了一层操作级权限，关于这两个模块，要进行一点小改动

在菜单管理中，新增、编辑菜单等操作中，新加一个”操作“的类型，以支持添加操作级权限信息

注意这里要填写的表单信息，是根据菜单类型来展示不同的字段，比如“操作”类型，需要填写权限码

然后，菜单列表的数据是这样的：

在角色管理模块中，主要关注”分配权限“的操作，允许给角色分配操作级权限

了解更多

系列专栏地址：GitHub 博客 | 掘金专栏 | 思否专栏

实战项目：vue-clean-admin

交流讨论

文章如有错误或需要改进之处，欢迎指正。

一、 明确需求：选择适合的证书类型

商用SSL证书主要分为三类，请根据业务需求选择：

1. 域名验证型（DV）证书

• 验证方式：仅验证域名所有权
• 颁发速度：10分钟-2小时
• 适用场景：测试环境、内部系统、基础官网
• 显示效果：地址栏显示安全锁标志

2. 组织验证型（OV）证书

• 验证方式：验证企业真实性（营业执照等）
• 颁发速度：1-3个工作日
• 适用场景：企业官网、政府机构、教育平台
• 显示效果：证书详情中展示企业信息

3. 扩展验证型（EV）证书

• 验证方式：最严格的企业身份验证
• 颁发速度：3-7个工作日
• 适用场景：金融平台、电商网站、大型企业
• 显示效果：地址栏直接显示企业名称（绿色栏）
  

二、免费SSL证书申请入口(免费一年期的证书只针对特殊域名，申请前记得看看域名是否符合 )

打开JoySSL官网，注册时记得填写注册码230970，获取免费证书跟技术支持。

三、准备申请信息

域名信息：明确主域名及需保护的子域名。

组织信息（OV 和 EV 证书需要）：包括组织法律注册名称、地址、电话号码等。

邮箱地址：用于接收验证邮件及证书相关通知。

四、域名所有权验证

证书颁发机构会要求您证明对域名的所有权，常见验证方式有：

文件验证：将特定验证文件上传至网站服务器指定目录。

DNS 验证：在域名的 DNS 配置中添加指定的 TXT 记录。

五、提交申请并等待审核

将准备好的申请信息及验证信息提交给选定的 CA，CA 会对申请进行审核。审核时间因证书类型和 CA 不同而异，DV 证书通常较快，几分钟到几小时不等；OV 和 EV 证书因涉及组织验证，可能需要 1 - 3 个工作日。

六、下载并安装证书

审核通过后，CA 会提供 SSL 证书文件。根据网站使用的服务器类型（如 Apache、Nginx、IIS 等），按照相应的安装指南将证书安装到服务器上。

七、验证证书是否生效

安装完成后，通过浏览器访问网站，查看地址栏是否显示安全锁标志，且网址以 “https://” 开头。也可使用在线 SSL 证书检测工具，进一步确认证书安装是否正确及网站的安全性。

全球首个具身智能大规模真机评测平台 RoboChallenge，上线数月便迅速积累了超过 4 万余次真实机器人测试数据，成为开发者社区观察 AI“动手”能力的一个关键窗口。近日，基于这份测试数据，RoboChallenge 正式发布了其首份年度报告。报告基于公开且可复现的真机数据，客观呈现了当前技术能稳定完成的任务边界，更关键地揭示了那些模型频繁失手、需要集中攻坚的共性瓶颈。

量化“基准线”

这份报告的价值，源于其对平台海量测试数据的深度挖掘，尤其是对最终榜单的系统性分析。报告通过一组来自榜单的核心数据，首先校准了整个行业对技术成熟度的认知。

榜单清晰显示，即便是最优模型，在面对 Table30 所涵盖的刚体、软体及长程等综合任务时，其端到端执行成功率也仅为 51%。这个数字像一道分水岭，直观地衡量出实验室智能与物理世界可用性之间依然存在的巨大落差。

更具揭示性的数据来自对模型泛化能力的评估。报告指出，同一基座模型在专攻单一任务时成功率可达 42.67%，但当其作为通用模型应对多样化任务时，成功率会骤降至 17.67%。这明确指出了当前技术的一个核心局限，即模型仍难以将其在特定任务上学到的技能，有效整合并迁移到一个更广泛、更复杂的任务集合中。
这些数据所揭示的普遍困境，促使我们审视其背后评测体系的设计逻辑。首先是过程分机制的引入。它确保即便任务最终失败，模型执行过程中的有效进展也能被量化记录，使失败数据从结果标注转变为可归因的诊断依据。
同时，评测体系有意将完成速度与模型大小排除在了核心计分之外。这一选择表明，评测关注的重点始终是模型完成任务的根本可靠性，而非引导研发陷入“更快”或“更大”的指标竞赛。正是这种对核心能力的聚焦，确保了所有模型都能够在公平维度上接受检验，也让随之暴露出的能力缺口，具备了被清晰界定和讨论的基础。

定义“真问题”

完成能力校准后，报告展开了更深层的技术归因。依据模型表现，报告建立了一个清晰的分析框架，将任务划分为三个梯队。第一梯队是已被充分掌握的 “Hello World”级任务，如 “堆碗”、“堆色块”这类 Top 3 模型成功率均达到 100% 的任务。第二梯队则是如“放鞋上架”“寻找绿盒子”等对大多数头部模型较为友好的 “简单任务”。 而真正的挑战与行业瓶颈，几乎全部集中在第三梯队。这类任务通常涉及复杂的物理交互或长程逻辑，因其极低的通过率，在报告中被称为“叹息之墙”。

首先被明确的是物理层面的交互瓶颈。在最具代表性的“叠抹布”任务中，上榜模型的最佳成功率仅为 30%。报告分析指出，失败的根源是算法无法预测和适应布料在抓取、折叠过程中发生的连续形变与力学反馈。这也是目前行业公认的难点，即如何在非刚性物体的交互中实现精确的物理状态感知与实时控制，特别是在动态变化的接触条件下稳定把握操作力度与定位。
其次是认知层面的规划瓶颈，这集中体现在长程任务上。“做素三明治”与“给盆栽浇水”是两类代表性任务，二者成功率均为于 0%，但揭示了规划能力的不同短板。“做素三明治”失败揭示了当前模型在应对“低容错率顺序任务”时的脆弱性。任务要求按照固定的“面包、蔬菜、番茄、面包”序列操作，任何一步的抓取失误或顺序错乱都会导致全盘崩溃。这反映了此类任务对执行链条精确性与一致性的极端要求。
而“给盆栽浇水”任务的失败则暴露了模型在时间维度上维持目标一致性的内在困难。报告显示，模型能够完成抓壶、移动的前半段，却常在最终阶段出现目标遗忘，未能将水壶放回原位，甚至产生类似“幻觉”的随机动作。报告将其归因为“时序依赖缺失”与“状态丢失”，这更直接地体现了模型长程工作记忆或状态维持机制的不足。
在物理交互与认知规划这两大瓶颈之外，报告还指出了一个更为基础且普遍存在的系统性挑战，即在高精度、多步骤操作中维持端到端稳定性的能力严重不足。报告显示，“整理书籍”任务的最高成功率仅有 10%，失败根源在于模型初始抓取的微小偏差在后续操作中被不断放大。“排列纸杯”任务则更为典型，模型能够精准完成前四步的杯子抓取与套叠，却会在最后一步放置杯塔时因毫厘之差推倒杯塔宣告任务失败。
显然，当前技术面临的不仅是单一环节的能力缺陷，更是整个感知、决策与控制闭环在长时间、高精度协同工作时，维持系统稳定性的能力。这种稳定性的缺失，成为了制约复杂物理交互可靠性的关键瓶颈。
当“真问题”被具体标定后，行业的关注点与研发资源便能够从宽泛的技术竞赛，转向对关键能力的聚焦攻关。而如何构建有效的协作生态以加速这一进程，则成为报告揭示现状之后，自然浮现的下一个命题。

共建“新考场”

报告在洞察技术瓶颈的同时，也揭示了解决问题的路径。RoboChallenge 通过对 Table30 全量数据集及每一次测试完整日志与录像的彻底开源，形成了“开源数据与真实评测”为核心的行业协作范式，将原本孤立的实验室研究牵引至一个共同定义问题、共享进展、公开验证的开放轨道上。

以此为基础，一个开放且可信的具身智能开发者社区已快速形成。从顶尖研究机构到头部科技公司，多元力量在此验证与迭代模型。而来自社区的集体反馈正在发挥更重要的作用，直接推动着平台规划下一阶段的技术发展路径。一个关键例证是，报告在社区反馈部分指出，未来将引入可移动障碍、变化的目标位置等动态元素，以及发布厨房、仓储等更复杂环境。这些基于社区实践的反馈影响着社区的演进方向，也反映出行业的共识变化。
同时，这一变化也将深度牵引技术研发的重点。它预示着未来的技术攻坚，需要从追求在固定条件下的完美执行，转向构建能够应对目标位置变动、突发干扰出现等不确定性的新型能力。可以预见，未来的评测将从 “静态”的流程执行，转向“动态”的环境交互。评估的关键将不再局限于“在设定好的桌面上能否成功”，而会更多地检验“在条件发生变化时，能否持续、稳定地达成目标”。

可以看到，社区通过一线实践提出前瞻需求，平台则将这些共识沉淀为下一代评测标准，进而引导整个领域的技术攻坚方向。在这个循环中，平台的角色从“出题者”演变为“共建者”。技术突破的路径，正与一个能够敏锐捕捉并转化行业共识的开放生态的成熟深度绑定。当动态场景从社区诉求变为平台规划，并最终成为标准配置时，具身智能的研发才真正从“展示能力”到“交付能力”的下一阶段。