特斯拉前 AI 总监、OpenAI 创始成员 Andrej Karpathy 在去年随口提出 Vibe Coding 的时候,或许也没想到,它会变成一场运动,并从 240 亿个词汇中脱颖而出,成为 2025 年柯林斯词典年度词汇。

Vibe Coding 之所以出圈,在于它击中了一个时代情绪:在 AI 技术的持续迭代升级下,编程可以不再是工程师的专属能力。“人人皆可编程” 第一次从口号变得可感知。

但问题也很快开始浮现:Vibe Coding 虽然降低了编程门槛,但本质上,加速的还是“程序员写代码”,整个流程仍然假设用户知道什么是 IDE、什么是依赖管理、什么是部署。

而这,挡住了绝大多数人。

根据行业数据,2025 年全球程序员数量预计在 3000 万左右,与 80 亿的全球总人口数相比,还不到 1%。这意味着,即使 Vibe Coding 做到极致,它的受众天花板也就是这几千万人。这个世界上每天都有太多转瞬即逝的想法,还停留在脑海里、对话里、Demo 里。

这也是为什么,蚂蚁灵光这一次的更新,显得格外关键。作为一款全模态 AI 助手,灵光自去年 11 月一经发布,就以“30 秒生成应用、生成即部署”的差异化能力火速出圈。

4 月 20 日,灵光对闪应用进行升级:深度集成了手机端的原生能力,包括相机、陀螺仪、LBS、麦克风、震动等,同时推出“灵光圈”,用户无需任何门槛,就能在移动端完成应用的生成、迭代、使用、分发全流程闭环。

灵光想做的,不是继续优化某个技术点,而是打通一条完整链路:让每一个念头,都有机会成为一个被使用、被分享、被不断改写的应用。

99% 的人,需要的是 Wish Coding

Vibe Coding 真正解决的问题,是让已经会写代码的人写得更快。它的起点是一个 IDE 窗口,用户与 AI 围绕代码协作;它的终点是一段可运行的代码。

但对于一个编程零基础的用户来说,问题从来都不是代码。一个想法要变成真正可用的应用,需要经过生成、适配、部署、分发、使用、反馈、迭代一整条链路。Vibe Coding 加速的只是“生成代码”这一个环节;而对普通用户来说,链路上的每一个环都是卡点。

要覆盖这 99% 的人群,不是在 Vibe Coding 的方向上走得更远,而是需要一条完全不同的路径。灵光给它的命名是 Wish Coding。

Wish Coding 即意图编程,用说话直接生成可运行的软件应用。用户不需要 IDE 和代码界面,也不需要了解构建和部署的概念,只需要说清楚自己想要什么,就能得到一个可运行的完整应用。

实际上,早在上世纪 90 年代,微软前首席架构师、Word 和 Excel 的缔造者 Charles Simonyi 就曾提出“Intentional Programming”。Simonyi 认为,软件开发应更多关注开发者的意图,而非聚焦于代码书写的细节。在当时,这一设想受限于技术条件,还只能停留在理念层面;如今,大模型的能力,让 Wish Coding 所代表的意图编程成为可能。

灵光正在做的,本质上是用 AI 充当 Simonyi 设想中那个“从意图到实现的自动化层”,只不过面向的不再是专业开发者,而是每一个能用自然语言表达需求的人。

在灵光 APP 中,用户只需要输入一个自然语言指令,就能生成一个可运行、可交互、可分享的完整应用。灵光将其命名为闪应用,或许也代表着,每个人的灵光一闪,都能化作一个应用。更重要的是,这个应用不是停留在 Demo 层面,而是能在手机端侧运行,调用摄像头、LBS、陀螺仪、麦克风、本地存储、系统通知等硬件能力。

比如,笔者每天的时间都很碎片化,想让灵光做一个碎片化专注计时器,支持自定义专注时长、休息倒计时、专注总时长排行榜,界面极简,并且能根据天气情况匹配不同白噪音音效。

把这些“愿望”一股脑儿发给灵光,几十秒就得到了一个应用,直接就能体验起来。整个过程,全部都是在灵光 APP 里完成。

第一版不够好,不知道怎么优化?灵光会提供修改建议,供用户参考。就这款计时器来说,现在的样式确实太过极简,灵光建议专注时显示专注成就徽章,采纳后,很快迭代好了一版:

与一款成熟应用对比而言,现在的计时器还欠缺很多功能,但关键的变化在于,卡点从有没有技术能力实现,转移到了用户的想象力——你能提出来,灵光就能做、就能改,直到你满意为止。这或许才是 99% 的人,真正需要的。

每一个灵光一闪,都有机会被再创造

闪应用实现的,是把一个人的灵光一闪,变成真正的应用。灵光圈实现的,是让每个人的灵光一闪,都能在更大的舞台上被看见、被使用、被分享、被不断改写。这也是此次升级中,灵光带来的最大的惊喜。

根据官方解释,灵光圈的定位是围绕闪应用构建的分发与协作社区,任何人手搓的闪应用都可以一键分享到灵光圈,让其他人浏览、使用、点赞和评论。特别之处在于,灵光圈支持二次创作。任何人看到一个闪应用,都可以在原版的基础上,用自然语言描述自己想要的修改,并生成一个全新的版本。

这种机制有些类似开源协作中的“Fork 代码”。在传统的软件协作中,开发者可以在  GitHub 上对他人的代码进行 Fork、修改、再发布,从而形成持续演进的协作网络。

灵光把这个动作再往前推了一步:大家 Fork 的不是代码,而是意图。任何人在灵光圈看到的闪应用,都能根据自己的喜好进行修改。你不需要看懂原作者写了什么,只需要说:“把这个配色改掉”“把里面的菜单换成低脂版本”“再加一个倒计时功能”,AI 就能基于原作继续生成。

这也是灵光圈最有意思的地方:它把应用的演化门槛压到了足够低。低到使用者和创作者之间的边界开始变模糊,任何一个使用者都可能顺手改出自己的版本,再把它变成别人的起点。

过去,软件应用的生长路径更加具有确定性:从需求分析、系统设计、编码实现再到测试发布,整个流程封闭、高度依赖中心化团队,版本迭代也按照既定路线、线性演进。

但在灵光圈中,闪应用的生长方式是完全开放的,任何人都可以基于已有版本进行修改和再创作,不同用户的需求可以在多个分支上并行演进。一个应用不再只有一个“官方版本”,而是衍生出多个面向不同场景的变体,每一个分支都有可能继续被扩展、被传播。这未必会立刻催生出什么超级应用,但它确实提供了一种更开放的,也是前所未有的应用生长机制。

数据显示,截至目前,灵光用户已成功创建超 3000 万个闪应用。从互动游戏、情绪减压到语言打卡、待办清单等,灵光闪应用覆盖了普通人生活的方方面面。

灵光产品负责人表示:“灵光闪应用功能正在催生‘一人应用’的兴起——不依赖团队协作,不需要漫长开发周期,一个人、一句话、30 秒,就能让想法变成可交互的工具。灵光圈的上线,希望帮助普通人也能零门槛调用自己的 Coding Agent。”

Coding Agent 正在从开发者走向普通人

把时间线拉回两年前,Coding Agent 还更多停留在“辅助编程工具”的角色——以 GitHub Copilot 为代表,它们擅长的是在既有代码语境中补全、提示与优化,本质上仍然服务于“写代码的人”。

但在 2026 年,行业叙事明显变了。Coding Agent 开始越来越多地直接交付结果。

灵光的特别之处在于,它把 Coding Agent 做成了面向普通人的消费级产品。当然,这条路远没有完全走通。复杂场景里的意图理解是否足够准确,多人协作和权限体系是否成熟,社区生态能否持续运转,这些都还是现实问题。

但有一点是确定的。这条路一旦走通,它所触达的将不只是 3000 万开发者。届时,更多人能够以表达为起点,参与到数字世界的构建之中。

平时午休在车里睡觉,每次都能被特斯拉的倒车声音吵醒,声音穿透力又强又难听,简直像一把电钻往脑子里钻。那些特斯拉车主是很享受这个声音吗?每次停个车都要来回倒几遍!

最新NVIDIA RTX™ 桌面端企业级显卡为NVIDIA RTX PRO™ GPU 系列,当下已从NVIDIA Ampere、NVIDIA Ada Lovelace 架构升级至NVIDIA Blackwell 架构,AI和图形处理性能都有质的提升。

NVIDIA RTX PRO系列显卡型号

交通-1.JPG

计算机视觉相关任务

在交通流监测、车辆行人识别等场景中,经常会使用到类似YOLO 等目标检测模型的训练和实时推理,对于这类任务,NVIDIA Blackwell 架构在推理性能上优势明显,尤其高负载实时应用、处理高计算量任务时优势尤为突出,可为实时应用提供更低延迟。根据实际检测需求,显卡型号通常以NVIDIA RTX PRO 4000 和NVIDIA RTX PRO 5000 为主。以NVIDIA RTX PRO 5000为例,该型号除了提供卓越的性能,更以高可靠性、长生命周期、技术支持等特点打动客户的需求。
交通-2.png
NVIDIA RTX PRO 5000 Blackwell (图片来源于NVIDIA)

大模型推理相关任务

在交通系统规划设计、交通服务、智驾系统应用等方面,大模型推理任务越来越重。NVIDIA RTX PRO 系列作为桌面端企业级显卡,可以稳定运行在任意复杂环境,对于模型实验/验证等任务,可以摆脱对数据中心资源的依赖,性价比也非常高。型号首推NVIDIA RTX PRO 5000,单卡NVIDIA RTX PRO 5000 (48GB)已经可以应对相对较小规模的模型推理,中等规模的模型推理则可以采用双卡、四卡NVIDIA RTX PRO 5000的方案来运行。

设计与仿真类任务

从车辆、道路基础设施设计、系统仿真,到数字孪生可视化,NVIDIA RTX PRO 系列专业级显卡可以支持从小模型、小场景到超大场景的3D设计和仿真任务,并且相对于消费级显卡来说,专业显卡的企业级驱动程序可靠性更强、产品稳定性优势很大。

对于型号的选择,可大致参考如下的范围:
交通-3.JPG

中等规模的场景是日常任务中最常见的。NVIDIA RTX PRO 4000 是特别值得关注的一款卡,目前是NVIDIA RTX PRO 系列中性能最强的一款单插槽显卡!工作站适配度非常高。平时应对中小型规模的建模和渲染游刃有余,甚至在大型复杂场景中的仿真表现也很好。
交通-4.png
NVIDIA RTX PRO 4000 Blackwell (图片来源于NVIDIA)

赞奇科技曾在工作站中搭载一张NVIDIA RTX PRO 4000运行UG NX,将3个智能装配生产线的复杂模型组合到一起,零部件数量总共约2万个,模型文件总大小1.5G,包含了大量高精度曲面、关联特征与运动信息。三合一模型在12秒内载入完成,编辑、旋转、缩放、渲染、仿真流畅全程无卡顿,工程图在29秒内即生成,效率和稳定性上都很不错。
IMG_2017.PNG

购前体验

赞奇科技目前免费开放给用户开展NVIDIA RTX PRO 系列产品测试。

您可以提供想要测试的场景,扫描下方二维码申请远程测试,或获取更详尽的显卡应用资料!
二维码.jpg
*与NVIDIA产品相关的图片或视频(完整或部分)的版权均归NVIDIA Corporation所有。

2026年4月20日至24日,德国汉诺威工业博览会在汉诺威展览中心举行。在浙江省商务厅组织下,NineData将作为浙江展团参展企业之一,亮相2026浙江服务贸易(汉诺威)数字生态展,向来自全球的客户、合作伙伴及行业观众展示企业级智能数据管理平台的核心能力。

德国汉诺威工业博览会作为全球最具影响力的工业技术贸易展之一,依托这一国际化平台举办的“2026浙江服务贸易(汉诺威)数字生态展”,有助于进一步推动浙江数字技术企业加强国际交流合作,提升品牌国际影响力,拓展面向欧洲及全球市场的发展空间。

NineData作为浙江展团代表企业之一,将展示面向AI时代的智能数据管理产品与行业解决方案,向全球客户、合作伙伴及产业用户展示浙江企业在数据库DevOps、数据复制与对比、AI数据管理、智能运维领域的一站式数据管理能力。

NineData将在现场展示什么?

在全球工业体系加速迈向智能化、柔性化和数据驱动的背景下,企业正面临多云、混合云、异构数据库并存,以及跨区域业务协同、工业数据互联、研发治理标准化等多重挑战。NineData此次参展,将围绕企业级数据管理全生命周期的核心需求,重点展示三大能力方向。

企业级数据库DevOps

NineData提供覆盖SQL开发、规范审核、审批执行、权限控制、审计留痕、变更发布与性能优化的一体化数据库研发治理能力,帮助企业从传统分散式数据库管理模式,升级到更规范、更安全、更高效的协同管理体系。对于正在推进工业数字化转型的制造企业而言,这意味着数据库开发效率与生产环境稳定性能够实现更好平衡。

数据复制与对比

面向工业企业常见的多系统、多环境、多数据库架构,NineData支持多类型主流关系型数据库、NoSQL、分析型数据库及云数据库之间的数据迁移、实时同步、结构复制、数据对比与一致性校验,可广泛应用于跨云数据流转、系统升级迁移、国产化替代、容灾备份、实时数仓构建等场景,帮助企业建立更稳定、更可控的数据流动能力。

AI原生数据管理

依托AI Agent与ChatDBA等能力,NineData正在推动数据库管理从“工具辅助”走向“智能协同”。通过自然语言生成SQL、智能SQL优化、故障自动诊断、运维问题排查与任务调度等功能,平台帮助企业进一步降低数据库管理门槛,提高研发与运维效率,为工业AI在真实业务场景中的落地提供更加坚实的数据底座。

诚邀莅临

4月20日至24日,德国汉诺威展览中心,NineData在16号馆D16展位期待与您相见。

诚邀您莅临NineData展位,面对面交流产品能力、行业实践与合作机会,共同探索工业数字化与全球化发展背景下的数据管理新可能。

2026浙江服务贸易(汉诺威)数字生态展,NineData与您现场相见。

关于NineData\
NineData是玖章算术(浙江)科技有限公司旗下智能数据管理平台,专注于云计算与数据管理基础技术创新,依托云原生架构与AI能力,打造覆盖数据库DevOps、数据复制、数据对比、智能运维等核心场景的一体化数据管理平台,帮助企业在多云、混合云及复杂异构环境下实现更高效、更安全、更智能的数据管理。

NineData面向企业数据库开发、迁移、同步、治理与运维全流程,提供从研发协同到生产保障的完整能力支撑,助力企业提升数据流转效率、强化数据安全与合规治理,加快数字化升级与全球化业务落地。产品已广泛应用于金融、制造、能源、电力、互联网、医疗健康、跨境出海等多个行业场景。

写代码、做表格、搞分析……大模型把这些活儿干完之后,终于腾出手来对付设计了。这个曾经最依赖专业工具和手艺的领域,终究没能逃掉被重做的命运。

 

周末,Anthropic 宣布推出一款新产品——Claude Design,试图把“设计”这件事从专业软件中解放出来,变成一种可以通过对话完成的协作过程。

 

这项功能目前由其刚刚发布的最新模型 Claude Opus 4.7 提供支持,并以研究预览的形式向 Claude Pro、Max、Team 和 Enterprise 用户逐步开放。

说几句话就能完成设计的时代来了

Anthropic 对 Claude Design 的定位很明确:不是一个简单的设计生成器,做“一键生成”工具没什么意思,它要能“陪伴”设计师一起改设计方案,当一个干活“搭子”。

 

在传统设计流程中,即便是经验丰富的设计师,也会因为时间与资源限制,往往只能在有限的几个方向上反复打磨。对于很多不懂设计的创始人或 PM 来说,想把脑子里的点子变成好看的图,简直就像隔着一堵墙,根本摸不着门道。

 

Claude Design 试图同时解决这两类问题。

用户只需要用自然语言描述需求,Claude 就可以生成一个初始设计版本。之后的迭代过程,不再依赖复杂的软件操作,直接能通过对话、内联评论、直接编辑甚至“自定义滑块”等方式完成。

 

这种交互模式,本质上把设计过程拆解成连续的语义调整,与传统工具依赖像素级操作的方式大不相同。

更关键的一点在于一致性。系统在获得权限后,可以自动调用团队的设计系统,将统一的字体、颜色和组件应用到每一个输出中,减少风格不统一的问题。

从官方披露的使用场景来看,Claude Design 的目标并不是替代某一个具体软件,而是横向覆盖多个设计相关工作流:

  • 原型设计:将静态稿快速转换为可交互的原型,用于用户测试与反馈收集,无需额外代码流程

  • 产品线框图:产品经理可以直接生成流程草图,并进一步交给开发或设计团队完善

  • 设计探索:设计师可以在短时间内生成多个方向进行对比

  • 演示文稿:从提纲生成完整、符合品牌规范的 PPT,并支持导出为 PPTX 或发送至 Canva

  • 营销素材:包括落地页、社交媒体视觉、活动素材等初版生成

  • 复杂原型:支持语音、视频、3D、着色器甚至内置 AI 的代码驱动设计

  

这意味着,Claude Design 正在尝试覆盖从“想法生成”到“视觉表达”再到“交付开发”的完整链路。 

新工具被网友们“玩疯了”

 

在 x 上,一位从事了 20 多年设计工作的设计师大赞这款工具极具颠覆性。他写道:

 

“太爱你们这次做的东西了!!!今天刚测试完。做了 29 年的设计,本以为灵感已经枯竭,结果你们让我找回了久违的快乐!VIBE CODING DESIGN(氛围感编码设计)绝对是未来的方向。这可能是目前为止最牛、最具颠覆性的发布!”

 

还有用户幽默地贴了张图,暗示设计师们的工作将岌岌可危。

 

还有用户表示,试过 Claude Design 后发现它真绝了。该用户让 Claude Code、Codex、Gemini 等系统都存在于同一个无限画布上。无需切换上下文。

在这些 AI 系统中,该用户表示:“Claude Design 完全 get 到了我的应用的精髓,把它呈现出了应有的高级感——这一版简直是脱胎换骨,跟旧版根本不是一个量级的东西。”

前阵子大家还在争论“Vibe Coding(氛围编程)到底有没有护城河”,当时很多人就不看好 Lovable 这类工具。这次拿它跟 Claude Design 一对比,一些用户认为更是坐实了这个观点:

“像 Lovable 这种应用,恐怕真的没什么前途。”

 

技术上是如何实现的?

Claude Design 不是单纯的“AI 画图”,它的核心是“懂业务”。Claude Design 本质上是一套吃透了企业上下文的定制系统,

 

从技术实现路径来看,在初始阶段,Claude 会读取团队的代码库和设计文件,自动构建一套设计系统。此后所有项目都会默认继承这一系统,从而保证输出的一致性。同时,这套系统是可演化的,团队可以持续优化,并维护多个设计体系。

输入方式也被大幅扩展。用户可以通过文字向其输入指令,还可以上传文档(如 DOCX、PPTX、XLSX)、导入图像,甚至让 Claude 直接访问代码库。此外,系统还支持通过网页捕获工具,从现有网站抓取元素,来提高原型的真实度。

在编辑层面,Claude Design 提供了更细粒度的控制能力:用户可以对具体元素添加注释、直接修改文本,或通过参数化控件调整布局、间距与颜色,并将这些修改批量应用到整个设计中。

Claude Design 的另一重点是“协作”。

设计稿可以在组织内部共享,支持不同级别的权限控制:从私有文档,到通过链接查看,再到开放编辑权限。团队成员可以在同一设计中与 Claude 进行群组对话,这使得设计讨论从传统的评审会议,转向实时、上下文连续的协作过程。

在交付环节,Claude Design 提供了多种导出方式,包括内部链接、文件夹存储,以及导出为 Canva、PDF、PPTX 或独立 HTML 文件。

更进一步,当设计完成后,系统可以自动打包为一个“移交包”,并通过一条指令传递给开发工具 Claude Code,实现从设计到实现的衔接。

Figma 或 Canva 等工具危矣?

从产品形态来看,Claude Design 不是在复制 Figma 或 Canva 这样的传统设计工具,它想尝试用大模型重构设计的交互范式,但在很大程度上和以上两家所做的工作是重合的,有一些变化值得关注:

  1. 从工具操作转向语义表达:用户通过描述意图,而不是操作界面来完成设计

  2. 从单点工具转向系统能力:设计系统、代码库与内容生成被统一到一个模型中

  3. 从角色分工转向能力融合:非设计人员也可以参与视觉创作,设计师则更多承担方向与审美判断

目前,这一功能仍处于研究预览阶段。Anthropic 表示,未来几周将进一步加强与外部工具的集成能力,使其能够接入团队已有的工作流。

 

如果说过去一年生成式 AI 已经重塑了“写代码”和“写内容”的方式,那么 Claude Design 的出现,正在把“设计”也拉入同一套范式之中。而这种变化,对 Figma、Canva 等传统设计工具的冲击,已经开始在市场和舆论层面显现出来。

 

从资本市场的短期反应来看,这种冲击显得颇为直接。Claude Design 发布当日,Figma 股价下跌约 4.26%,而 Adobe、Wix 和 GoDaddy 等相关公司也同步出现下行。

 

此外,Anthropic 首席产品官在发布前三天从 Figma 董事会辞职,也被部分市场解读为行业格局变化的一个信号。不过,也有观点认为,这类波动未必完全由 Claude Design 引发,在整体 SaaS 行业承压的背景下,单日 4% 左右的跌幅仍属于正常区间。

相比市场的短期情绪,行业内部的判断则更为分化。一方面,像 Figma 这样的工具依然牢牢占据 UI/UX 设计市场约 80%~90% 的份额,经过多年演进形成了完整且成熟的工作流体系,深受专业设计师依赖。从这个角度看,传统设计工具在短期内并不会被替代,其在复杂设计、协作精度以及系统化能力上的优势依然明显。

 

但另一方面,Claude Design 所代表的范式转变,正在动摇设计行业最核心的一道壁垒——门槛。过去,视觉表达需要依赖专业软件与训练,而现在,用户只需用自然语言描述需求,就可以获得一个可用的设计初稿。这也引出了一个令传统工具难以回避的问题:当客户可以直接用文字与模型沟通时,是否还需要完整的设计工具链来完成同样的工作?

 

从用户侧反馈来看,这种替代关系目前仍然有限。

 

在 Reddit 等社区讨论中,不少具备专业设计经验的用户认为,Claude Design 生成的结果存在明显的同质化问题,整体质量更接近“现代剪贴画”——能够显著提升基础设计的下限,但距离高质量、差异化的专业设计仍有差距。因此,它更像是一个补充工具,而非替代方案。

 

同时,也有用户指出,这类产品并非首次出现。一个月前,Google 就已推出类似产品 Stitch,说明“用 AI 生成设计”本身并不是全新的概念。从这个角度看,Claude Design 更像是在现有方向上的一次能力强化,而非彻底颠覆。

 

目前相对明确的共识是,这类工具的真正价值,主要体现在三类场景:非设计背景用户的表达需求、创业者的快速验证,以及产品早期的原型构建。它的核心作用是降低创作门槛、加速想法可视化,而不是取代完整的设计流程。

 

即便是在这些优势场景下,Claude Design 仍面临现实限制。有用户反馈,生成一个完整设计可能会消耗 Claude Pro 订阅中约一半的使用额度,这意味着在当前阶段,其成本结构尚不足以支撑高频或重度使用。

 

现在就断言 Claude Design 会对 Figma 等传统设计工具造成巨大冲击,仍然为时尚早。

 

 

参考链接:

https://www.anthropic.com/news/claude-design-anthropic-labs

https://techcrunch.com/2026/04/16/anthropic-cpo-leaves-figmas-board-after-reports-he-will-offer-a-competing-product/

https://x.com/robinebers/status/2045163860588724563

 

求助
我经常出差,需要访问校内服务器,目前遇到网络方案上的瓶颈,希望高手指点。

背景

出差场景下访问校内服务器。

之前尝试方案:

  1. 深信服 VPN / UU 远程
    1 ) VPN 会挟持底层网络,和 Clash 等工具冲突。
    2 )看到有 Docker + EasyConnect 解决和 clash 冲突的方案,但没有找到具体的教程。
    3 ) UU 远程稳定性不足,切换不便。
  2. 跳板机 + SSH 转发

我最新尝试 Tailscale 构建内网网络,但遇到连接速度非常慢的问题:

跳板机节点:MappingVariesByDestIP: true
本地节点:MappingVariesByDestIP: false

无法打洞直连,本地直接访问服务器延时高。

请问:

  1. 在这种网络环境下,Tailscale 是否可以优化打洞直连或降低延时?
  2. 使用 frp 或其他内网穿透工具 是否能解决?推荐的配置方案或实践经验有哪些?
  3. SSH 隧道、frp 、Tailscale ,哪种方式在高延迟/受限网络下更可靠?

首个面向 Agent 的操作系统——Agentic OS发布后,收到许多询问,是否能在本地部署?当然可以,Agentic OS 已经在 GitHub 上开源,开源项目是「ANOLISA」。

本文会详细介绍如何准备开发环境、从源码构建 ANOLISA 各组件并运行测试,覆盖 Alibaba Cloud Linux(Alinux)、Ubuntu 等多发行版。文末也会提供常见问题排查。

ANOLISA 是什么?

ANOLISA(Agentic Nexus Operating Layer & Interface System Architecture)是 Anolis OS 的 Agentic 演进,一个专为 AI Agent 工作负载构建的服务端操作系统。

当你的服务器上跑着越来越多的 AI Agent —— 它们执行命令、调用 API、读写文件、管理系统 —— 传统操作系统的安全边界和工具链已经力不从心了。ANOLISA 从 OS 层面为 Agent 构建了一套完整的运行环境:AI 终端助手、安全沙箱、可观测引擎和运维技能库,让 Agent 在受控、可审计、最小权限的环境中运行。

本文将按照官方构建文档,从零开始一步步带你完成 ANOLISA 的本地安装。

仓库结构一览

在开始之前,先了解一下 ANOLISA 的项目布局:

anolisa/
├── src/
│   ├── copilot-shell/       # AI 终端助手(Node.js / TypeScript)
│   ├── os-skills/           # 运维技能库(Markdown + 可选脚本)
│   ├── agent-sec-core/      # Agent 安全沙箱(Rust + Python)
│   └── agentsight/          # eBPF 可观测/审计引擎(Rust,可选)
├── scripts/
│   ├── build-all.sh         # 统一构建入口
├── tests/
│   └── run-all-tests.sh     # 统一测试入口
├── Makefile
└── docs/

四个 src 子目录分别对应四大核心组件:Copilot Shell 是 AI 驱动的终端助手,基于 Qwen Code 构建,支持自然语言编程和多工具编排;OS Skills 是涵盖系统管理、安全、DevOps、阿里云集成的运维技能库;Agent Sec Core 是 Rust 实现的安全沙箱,为 Agent 提供最小权限和纵深防御;AgentSight 是基于 eBPF 的可观测引擎,零侵入监控 LLM API 调用和 Token 消耗。

环境依赖

各组件所需的工具链版本如下:

  • copilot-shell:Node.js >= 20、npm >= 10、make、g++
  • os-skills:Python >= 3.12(仅可选脚本需要,大部分技能无需编译)
  • agent-sec-core:Rust >= 1.91.0、Python >= 3.12、uv(仅 Linux)
  • agentsight(可选):Rust >= 1.80、clang >= 14、libbpf 头文件、内核头文件(仅 Linux)

支持的操作系统:Fedora / RHEL / CentOS / Anolis / Alinux(RPM 系)以及 Debian / Ubuntu(DEB 系)。推荐使用 Alinux 4 或 Anolis OS。

安装方式一:统一构建脚本(自动方式)

如果你只想尽快跑起来,用统一构建脚本是最简单的方式。它会自动检测系统、安装依赖、编译所有组件并安装到系统路径。

首先克隆仓库:

git clone https://github.com/alibaba/anolisa.git
cd anolisa

然后运行构建脚本。默认会安装依赖 + 构建 + 安装到系统,推荐大多数用户直接使用:

./scripts/build-all.sh
这一条命令背后,脚本做了五件事:首先自动识别发行版类型(RPM/DEB)和已安装的工具链版本;然后优先使用系统包管理器安装依赖,版本不满足时自动回退到 nvm、rustup 等上游安装器;对于国内用户,脚本会自动检测网络环境,在阿里云内网时使用内网镜像,公网环境配置阿里云公网 crates.io 镜像加速 Rust 依赖下载;接着按序构建 copilot-shell → os-skills → agent-sec-core 三个默认组件;最后安装到系统路径。

构建选项解析

脚本提供了丰富的选项,适应不同场景:

# 仅构建,不安装到系统路径(适合开发调试)
./scripts/build-all.sh --no-install

# 跳过依赖安装(依赖已就绪时使用,加快构建速度)
./scripts/build-all.sh --ignore-deps

# 仅安装依赖,不构建(适用于 CI 或需要手动构建的场景)
./scripts/build-all.sh --deps-only

# 仅构建并安装指定组件(可重复指定多个)
./scripts/build-all.sh --component cosh
./scripts/build-all.sh --component cosh --component sec-core

# 包含可选的 AgentSight 组件
./scripts/build-all.sh --component cosh --component skills --component sec-core --component sight

完整的参数列表:

  • --no-install — 跳过将组件安装到系统路径。
  • --ignore-deps — 跳过依赖安装。
  • --deps-only — 仅安装依赖,不构建。
  • --component <名称> — 构建指定组件(可重复使用),可选值:cosh、skills、sec-core、sight,默认构建 cosh、skills、sec-core。
  • --help — 显示帮助信息。
以上每个方式都是独立的命令,根据自己的需求选择一个执行即可。如果使用了统一构建脚本,可以跳过下方的分组件构建部分。

注意事项

有几点需要特别留意:

  • Node.js 和 Rust 建议通过上游安装器(nvm / rustup)安装,而非使用发行版软件包,因为部分发行版的包版本可能不满足要求。
  • os-skills 大部分是静态 Markdown 资源,无需编译。
  • AgentSight 是可选组件,它提供审计和可观测性能力,但不是核心功能所必需的,默认构建不包含它,需要使用 --component sight 显式包含。
  • AgentSight 的系统依赖(clang / llvm / libbpf / 内核头文件)需通过发行版包管理器安装,构建脚本会检测并提示缺失项。

安装方式二:分组件构建(手动方式)

如果已使用上方的统一构建脚本,可以跳过本节。脚本会自动完成所有步骤。

如果你希望手动设置各工具链并逐个构建组件,按以下步骤操作。

第一步:安装依赖

a) Node.js(用于 Copilot Shell)要求:Node.js >= 20、npm >= 10。Alinux 4(已验证):一行命令搞定,系统仓库提供的 Node.js 版本满足要求。

sudo dnf install -y nodejs npm make gcc-c++

其他发行版(通过 nvm):如果系统仓库的 Node.js 版本不满足 >= 20,推荐使用 nvm 管理 Node.js 版本。

# 如果 Node.js >= 20 已安装则跳过
if command -v node &>/dev/null && node -v | grep -qE '^v(2[0-9]|[3-9][0-9])'; then
  echo "Node.js $(node -v) 已安装,跳过"
else
# 从 Gitee 镜像安装 nvm
  curl -fsSL --connect-timeout 15 --max-time 60 https://gitee.com/mirrors/nvm/raw/v0.40.3/install.sh | bash
  source "$HOME/.$(basename "$SHELL")rc"

# 配置 npmmirror 加速 Node.js 下载
  export NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node/
  nvm install 20
  nvm use 20
fi

# 验证
node -v   # 期望:v20.x.x 或更高
npm -v    # 期望:10.x.x 或更高

b) Rust(用于 Agent Sec Core 和 AgentSight)

要求:agent-sec-core 需要 Rust >= 1.91.0;agentsight 需要 Rust >= 1.80。

Alinux 4(已验证):系统 rust 包版本低于 1.91.0,无法直接使用,仅需通过 dnf 安装构建工具,Rust 本身需用 rustup 安装(见下方)。
sudo dnf install -y gcc make
Ubuntu 24.04(已验证):Ubuntu 24.04 仓库提供了 rustc-1.91,可直接使用。

sudo apt install -y rustc-1.91 cargo-1.91 gcc make
sudo update-alternatives --install /usr/bin/cargo cargo /usr/bin/cargo-1.91 100

部分发行版的系统 rust 包版本可能低于 1.91.0。如果构建因版本不匹配而失败,请改用下方的 rustup。

其他发行版 / Alinux 4(rustup,推荐):rustup 是官方推荐的 Rust 安装方式,支持多版本管理。

# 如果 Rust 已安装则跳过
if command -v rustc &>/dev/null && command -v cargo &>/dev/null; then
  echo "Rust $(rustc --version) 已安装,跳过"
else
# 通过 rsproxy.cn 镜像安装 Rust
  curl --proto '=https' --tlsv1.2 -sSf --connect-timeout 15 --max-time 120 https://rsproxy.cn/rustup-init.sh | sh -s -- -y
  source "$HOME/.cargo/env"
fi

# 验证
rustc --version   # 期望:rustc 1.91.0 或更高
cargo --version   # 期望:cargo 1.91.0 或更高

仓库为 agent-sec-core 固定了工具链版本(rust-toolchain.toml)。如果系统 Rust 版本不匹配,rustup 会在仓库内构建时自动下载正确版本。

配置 Rustup 分发镜像(国内用户推荐)

如果构建时触发了固定工具链的自动下载(通过 rust-toolchain.toml)并且超时,请设置 Rustup 分发镜像:

export RUSTUP_DIST_SERVER="https://rsproxy.cn"
export RUSTUP_UPDATE_ROOT="https://rsproxy.cn/rustup"

将以上内容添加到 shell 配置文件(~/.bashrc 或 ~/.zshrc)中以使其永久生效。构建脚本(build-all.sh)会自动配置此项。

配置 crates.io 镜像(国内用户推荐)

如果 cargo build 拉取依赖较慢,可配置阿里云 crates.io 镜像。构建脚本(build-all.sh)在通过 rustup 安装时会自动配置,手动安装的话需要自己添加。在 ~/.cargo/config.toml 中添加:

[source.crates-io]
replace-with = 'aliyun'
[source.aliyun]
registry = "sparse+https://mirrors.aliyun.com/crates.io-index/"

在阿里云 ECS(VPC 网络)上,可将 mirrors.aliyun.com 替换为 mirrors.cloud.aliyuncs.com 以使用内网加速。

c) Python 和 uv(用于 Agent Sec Core 和 OS Skills)

要求:Python >= 3.12。uv 是一个现代的 Python 包管理器,用于管理 Python 版本和依赖。

Alinux 4(已验证):

pip3 install uv
uv python install 3.12

Ubuntu 24.04(已验证):

sudo apt install -y pipx
pipx ensurepath
source "$HOME/.$(basename "$SHELL")rc"
pipx install uv

其他发行版:

# 如果 uv 已安装则跳过
if command -v uv &>/dev/null; then
  echo "uv $(uv --version) 已安装,跳过"
else
# 安装 uv(astral.sh 不可达时自动回退到 GitHub 镜像)
  curl -LsSf --connect-timeout 15 https://astral.sh/uv/install.sh | sh \
    || curl -LsSf \
    https://github.com/astral-sh/uv/releases/latest/download/uv-installer.sh | sh
  source "$HOME/.$(basename "$SHELL")rc"
fi

# 通过 uv 安装 Python 3.12(已存在则跳过)
uv python install 3.12

验证安装:

uv --version          # 期望:uv 0.x.x 或更高
uv python find 3.12   # 期望:输出 python3.12 可执行文件路径

d) AgentSight 系统依赖(可选,需包管理器)

AgentSight 是可选组件,提供基于 eBPF 的审计和可观测性能力。它不是 ANOLISA 核心功能所必需的。如果你选择构建它,需要以下系统级依赖。

dnf(Alinux / Anolis OS / Fedora / RHEL / CentOS 等):

sudo dnf install -y clang llvm libbpf-devel \
  elfutils-libelf-devel zlib-devel openssl-devel \
  perl perl-IPC-Cmd
sudo dnf install -y kernel-devel-$(uname -r)

apt(Debian / Ubuntu):

sudo apt-get update -y
sudo apt-get install -y clang llvm libbpf-dev \
  libelf-dev zlib1g-dev libssl-dev perl \
  linux-headers-$(uname -r)

部分发行版没有单独的 perl-core 包,这是正常的。

内核要求:AgentSight 要求 Linux 内核 >= 5.10 且启用 BTF(CONFIG_DEBUG_INFO_BTF=y )。可以通过检查 /sys/kernel/btf/vmlinux 文件是否存在来确认。

e) 版本检查

所有依赖安装完成后,运行以下命令确认版本:

node -v            # v20.x.x
npm -v             # 10.x.x
rustc --version    # rustc 1.91.0+
cargo --version    # cargo 1.91.0+
python3 --version  # Python 3.12.x
uv --version       # uv 0.x.x
clang --version    # clang version 14+(仅 AgentSight 需要)

第二步:构建组件
a) Copilot Shell

Copilot Shell 是一个 Node.js / TypeScript 项目,使用 npm workspaces 的 monorepo 布局。

cd src/copilot-shell
make deps
make build

构建产物是 dist/cli.js,你可以直接运行,或者添加持久的 co / cosh 别名到你的 shell:

# 直接运行
node dist/cli.js

# 或安装到系统 PATH(创建 cosh/co/copilot 命令)
sudo make install
cosh

b) OS Skills

OS Skills 无需编译,每个技能是一个目录,包含 SKILL.md 及可选的辅助文件(脚本、参考资料等)。部署时将包含 SKILL.md 的技能目录复制到以下加载路径即可:

  • 项目级:.copilot-shell/skills/
  • 用户级:~/.copilot-shell/skills/
  • 系统级:/usr/share/anolisa/skills/

手动部署(用户级):

# 构建脚本会自动复制技能:
./scripts/build-all.sh --component skills

# 或手动复制:
mkdir -p ~/.copilot-shell/skills
find src/os-skills -name 'SKILL.md' -exec sh -c \
  'cp -rp "$(dirname "$1")" ~/.copilot-shell/skills/' _ {} \;

验证技能是否已被发现:
co skills

c) Agent Sec Core(仅 Linux)

Agent Sec Core 包含一个 Rust 实现的 Linux 沙箱(基于 bubblewrap + seccomp),编译后为单个二进制文件。

cd src/agent-sec-core
make build-sandbox

构建产物是 linux-sandbox/target/release/linux-sandbox。

安装到系统路径:
sudo make install
安装完成后,你可以用沙箱策略生成器对命令进行安全分类:

python3 skill/scripts/sandbox/sandbox_policy.py --cwd "$PWD" "git status"

d) AgentSight(可选,仅 Linux)

AgentSight 是可选组件。它提供基于 eBPF 的审计和可观测性能力,不是 ANOLISA 核心功能所必需的。

cd src/agentsight
make build

构建产物是 target/release/agentsight。

安装到系统路径:
sudo make install
安装后可以用 sudo agentsight trace 启动 AI Agent 活动追踪,用 agentsight token 查询 Token 用量,用 agentsight audit 查询审计事件。

第三步:运行测试(推荐)

构建完成后,建议运行测试确认一切正常。

统一入口(推荐):

./tests/run-all-tests.sh
# 按组件过滤
./tests/run-all-tests.sh --filter shell
./tests/run-all-tests.sh --filter sec
./tests/run-all-tests.sh --filter sight

分组件测试:

# copilot-shell
cd src/copilot-shell && npm test

# agent-sec-core
cd src/agent-sec-core
pytest tests/integration-test/ tests/unit-test/

# agentsight
cd src/agentsight && cargo test

首次使用:启动 Copilot Shell

安装完成后,启动你的 AI 终端助手:

cosh
# 也可以用简短别名
co
copilot

首次启动会引导你完成认证。Copilot Shell 支持三种认证方式:

  • Qwen OAuth(推荐,免费额度:每天 2,000 次请求)
  • Custom Provider(支持百炼、DeepSeek、Kimi、GLM、MiniMax 等 OpenAI 兼容接口)
  • Aliyun AK/SK(仅供试用/测试)
    证完成后,你可以直接用自然语言与系统交互:
> 查看系统负载情况
> 帮我分析 /var/log/messages 里最近的错误
> 升级所有过期的 npm 包
> 生成一个 Nginx 反向代理配置

输入 /skills 查看所有已安装的运维技能,输入 /bash 进入交互式 Shell。

常见问题排查

Node.js 版本不匹配:如果 nvm 安装后 node 命令找不到或版本不对,尝试重新加载 Shell 配置:
source "$HOME/.$(basename "$SHELL")rc"

Rust 工具链不匹配:agent-sec-core 使用 rust-toolchain.toml 固定了工具链版本,如果构建时提示版本问题,检查当前工具链状态:

rustup show

rustup 会自动下载项目指定的版本。

AgentSight 缺少 libbpf / 头文件:请按上方「AgentSight 系统依赖」章节安装对应发行版的软件包。

AgentSight 运行时权限被拒绝:eBPF 程序需要 root 权限或相应 capability:

sudo agentsight trace
# 或赋予 capability(无需每次 sudo)
sudo setcap cap_bpf,cap_perfmon=ep ./target/release/agentsight

ANOLISA 让 AI Agent 在操作系统上的运行变得安全、可观测、可控。无论你是想在开发机上体验 AI 终端助手,还是在生产服务器上部署安全可控的 Agent 工作负载,ANOLISA 都能为你提供从构建到运行的完整工具链。

项目地址:https://github.com/alibaba/anolisa

欢迎 Star、Fork 和提交 PR!如有问题,欢迎在 GitHub Issues 中反馈。

您在使用 Agentic OS 过程中,有任何疑问和建议,请加入交流群(群号:90400034325)反馈。

探索企业微信ipad协议底层架构:高效接入与配置MQTT回调机制
在构建高实时性的企业级协同办公系统中,底层的通信协议选择直接决定了数据下发的延迟与吞吐量。除了传统的HTTP轮询与异步推送,基于企业微信ipad协议的深度开发中,引入MQTT(Message Queuing Telemetry Transport)回调机制成为了处理海量高并发事件的进阶方案。本文将围绕如何通过企业微信协议接口添加MQTT回调展开技术探讨。

一、为何在通信架构中引入MQTT?

传统的HTTP回调虽然成熟,但在面对极端高频的内部消息流转时,频繁的TCP握手与HTTP头部解析会带来不可忽视的系统开销。相比之下,企业微信协议中支持的MQTT是一种基于发布/订阅模式的轻量级通讯协议,专门为低带宽和不稳定的网络环境而设计。
在企微ipad协议的生态中,成功配置并添加MQTT回调后,服务控制端与开发者的接收端之间将建立一条持久化的长连接。服务端产生的各类状态变更事件,将以极低的延迟主动“推送”至开发者的Broker(消息代理)节点。对于致力于底层链路安全研究或从事xposed企业微信逆向分析的技术人员而言,分析MQTT的报文结构与心跳机制,是洞悉企业微信Xposed架构下数据实时同步逻辑的高级课题。

二、添加MQTT回调的技术实现路径

要激活这一高效的数据通道,开发者需要通过标准的企业微信协议接口,向实例控制中心下发绑定指令,提供合法的MQTT Broker地址、端口及鉴权凭证。
以下是一段基于Python实现的核心交互代码示例,展示了如何通过API安全地配置MQTT回调通道:

import requests
import json
import logging

def configure_mqtt_callback(api_server, instance_token, mqtt_broker_config):
    """
    向底层通信服务注册并添加MQTT长连接回调配置
    """
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {instance_token}",
        "Protocol-Type": "Enterprise-Pad-MQTT"
    }
    
    # 封装MQTT代理节点的环境参数
    payload = {
        "action": "add_mqtt_callback",
        "broker_host": mqtt_broker_config.get("host"),
        "broker_port": mqtt_broker_config.get("port"),
        "client_id": mqtt_broker_config.get("client_id"),
        "qos_level": 1, # 至少送达一次,保障核心消息不丢失
        "topics": ["enterprise/event/message", "enterprise/event/contact"]
    }
    
    try:
        # 提交配置,保持极短的超时时间以维持主线程队列畅通
        response = requests.post(
            f"{api_server}/instance/callback/mqtt/add", 
            headers=headers, 
            data=json.dumps(payload), 
            timeout=8
        )
        
        if response.status_code == 200:
            resp = response.json()
            if resp.get("code") == 0:
                logging.info("MQTT回调通道配置下发成功,实时长连接已就绪")
                return True
            else:
                logging.error(f"配置指令执行受阻,业务逻辑反馈: {resp.get('msg')}")
        else:
            logging.error(f"网络层交互异常,HTTP状态响应码: {response.status_code}")
            
    except requests.exceptions.RequestException as e:
        logging.error(f"提交MQTT配置请求时发生通信环境中断: {str(e)}")
        
    return False

三、工程实践中的长连接维稳策略

配置指令下发成功,仅仅是搭建实时数据网络的第一步。运行MQTT回调的核心工程难点在于“保活”。
在复杂的公网服务器环境中,网络路由的抖动随时可能导致TCP链路被动切断。因此,在开发者的接收端架构中,必须实现严密的断线重连机制(Auto-Reconnect)与平滑的死信队列(DLQ)处理方案。同时,需要根据业务场景合理设置QoS(服务质量)等级:对于普通的用户状态同步可采用QoS 0,而对于核心的客户信息流转或重要业务指令,则必须采用QoS 1,以增加少量网络开销为代价换取数据的绝对一致性。
掌握如何为系统添加并驾驭MQTT回调机制,标志着开发者的自动化架构从简单的接口请求响应模型,正式迈入了低延迟、高并发的工业级实时流处理领域。

技术依托:string_vx contact=bot555666

为什么企业软件越来越多,IT却越来越“失控”?

在数字化转型加速的背景下,企业采购软件的速度远超以往。尤其是在SaaS模式普及之后,业务部门可以绕开IT,直接通过在线订阅完成采购。这种灵活性虽然提升了业务响应速度,但也带来了新的问题——IT部门逐渐失去对整体系统的掌控。ManageEngine卓豪 将为您解答这些问题!

例如,市场部门可能采购营销自动化工具,销售团队引入CRM系统,HR部门使用独立的招聘平台。这些系统各自运行,看似解决了局部问题,但从整体来看,却形成了分散的应用生态。

当IT无法掌握这些系统的数量、用途与数据流向时,企业就进入了“影子IT”状态。

影子IT带来的风险,并不只是“多花钱”

很多企业最初关注影子IT,是因为重复采购导致成本增加。但实际上,其影响远不止于此。更严重的问题在于数据安全、合规风险与运维复杂度。

例如,未经审批的软件可能存在安全隐患,数据存储在不受控的环境中;多个系统之间缺乏集成,导致数据孤岛;当系统出现问题时,IT团队无法快速介入处理。这些问题都会对企业运营产生长期影响。

因此,影子IT并不是简单的“管理问题”,而是企业治理能力的体现。

为什么企业很难彻底禁止影子IT?

从现实角度来看,完全禁止影子IT几乎是不可能的。原因在于业务需求变化迅速,而IT部门的响应能力往往有限。当业务部门无法及时获得支持时,自行采购工具就成为“必然选择”。

此外,传统IT管理模式通常强调控制与审批,这在一定程度上降低了灵活性,使业务部门更倾向于绕过流程。这种矛盾,使影子IT成为企业普遍存在的问题。

因此,解决影子IT的关键,不在于“禁止”,而在于“引导与管理”。

ServiceDesk Plus 如何帮助企业“看见”影子IT?

通过ServiceDesk Plus,企业可以构建统一的软件与资产管理体系,将分散的应用纳入可视化管理范围。例如,通过资产发现与集成功能,识别已使用的软件与服务,并建立统一台账。

同时,通过服务目录与审批流程,企业可以为业务部门提供标准化的软件申请路径,从而在满足需求的同时保持可控性。

从“堵”到“疏”:企业该如何正确治理影子IT?

在影子IT治理中,很多企业第一反应是加强控制,例如限制采购权限、增加审批流程或直接禁止使用未授权软件。但实践证明,这种“堵”的方式往往效果有限,甚至会引发更严重的绕过行为。原因很简单:业务需求不会消失,只会寻找新的出口。

更有效的方式,是通过“疏导”来实现管理。也就是说,在保障合规与安全的前提下,为业务部门提供更高效、更透明的服务渠道。例如,通过统一的服务门户,让业务部门可以快速申请所需软件,并获得清晰的审批与交付流程。

这种方式不仅可以满足业务需求,还能将原本分散的行为纳入统一管理,从而实现可控与灵活的平衡。

常见问题(FAQ)

  1. 什么是影子IT?
    指未经IT部门管理或批准而使用的软件与系统。
  2. 是否需要完全禁止影子IT?
    不现实,应通过规范与引导进行管理。
  3. 如何快速识别影子IT?
    可以通过资产发现与数据分析工具实现。
  4. 如何进一步了解软件资产管理?
    可以参考ITSM解决方案获取更多信息。

2026年4月,众智FlagOS技术栈的统一多芯片AI算子库迎来全新发展里程碑:算子总量正式突破500个,完成“1+6”多个领域覆盖,包括AI算子库FlagGems,FlagBLAS,FlagDNN,FlagFFT,FlagSparse,FlagTensor和FlagAudio。实现从大模型训练推理到科学计算全场景的能力延伸,成为全球规模领先、覆盖场景最全面的Triton开源算子库。

作为AI模型与底层硬件之间的核心“翻译官”,算子库是决定AI算力释放效率、开发门槛与跨硬件适配能力的关键基础设施。长期以来,算子开发始终面临手写编码门槛高、调优周期长、跨芯片适配需重复开发等行业痛点,而英伟达CUDA生态凭借十余年的技术与开发者积累,形成了难以逾越的生态壁垒。此次FlagOS技术栈的里程碑式突破,为全球多元异构算力时代的AI基础设施建设,提供了全新的开源解决方案。

500 算子、7 大领域,FlagOS 实现从“大模型专用”到“科学计算全域”能力跃迁

自项目启动以来,FlagOS始终以“打破硬件壁垒、普惠算子开发”为核心目标,完成了从大模型专用算子库到全场景通用算子库的跨越式发展。

此次里程碑升级中,FlagGems大模型算子库的算子总量超过400个,成为全球最大的Triton单一算子库。此外,在原有大模型核心算子能力基础上,FlagOS团队完成了FlagDNN(深度神经网络)、FlagBLAS(基础线性代数)、FlagFFT(快速傅里叶变换)、FlagSparse(稀疏矩阵)、FlagTensor(张量运算)及FlagAudio(语音处理)六大领域的覆盖。

截至目前,FlagGems 大模型算子库中,Triton算子性能哪怕在英伟达硬件上跟CUDA算子相比,中位数也已经达到0.998,意味着一半的算子数量达到或超过CUDA在英伟达上的性能;硬件适配层面,已完成对英伟达、华为、摩尔线程、海光、天数等28种主流AI芯片的适配支持,在40个主流AI模型上的推理任务算子覆盖度达到90%~100%,为开发者提供了“一次编写、多芯片运行、处处高性能”的极致开发体验。

行业最快增速!22 个月突破 500 算子,众智生态活力全面凸显

更值得关注的是,FlagOS创下了同类型算子库的最快规模化增长纪录。从2024年6月FlagGems项目首次开源,到2026年4月突破500个算子规模。

图片
众智FlagOS社区吸引开发者持续贡献FlagGems项目

这一增速的背后,是FlagOS活跃的开源生态与技术创新的双向赋能。一方面,FlagOS依托Triton、及Triton-TLE开源语言,大幅降低了算子开发的技术门槛,智源研究院、中科院计算所、中科加禾、清程极致、中科院软件所、硅基流动、先进编译实验室等十多家机构、十多家AI芯片厂商、及全球数百开发者共同贡献,形成了“共建共享”的良性开源生态;另一方面, KernelGen 算子自动生成技术,实现了算子需求理解、代码生成、正确性验证到性能评测的全流程自动化,将单个算子的开发周期从周级压缩到分钟级,为算子库的规模化扩容提供了核心技术支撑。

KernelGen 2.0 算子自动生成平台(视频):https://live.csdn.net/v/522643

从PyTorch生态官方认证,到全球AI基础设施的核心底座

2025年6月,在2025北京智源大会PyTorch Day China论坛上,PyTorch基金会执行董事Matt White正式宣布,FlagGems项目通过官方审批,正式加入PyTorch基金会生态项目体系,成为唯一支持多种AI芯片架构的入选算子库项目,PyTorch基金会官方同步完成了全球官宣。

图片

2025北京智源大会 · PyTorch Day China 论坛,PyTorch 基金会执行董事 Matt White 发言

图片

加入PyTorch生态以来,FlagGems完成了与PyTorch框架的深度融合,通过ATen后端无感注册的设计,让开发者无需修改一行模型代码,即可无缝切换到FlagGems算子库,享受跨芯片高性能算力加速,彻底解决了PyTorch模型在多元硬件上的部署难题。截至目前,FlagGems已成为全球最大的单一Triton算子库,其开源生态已覆盖芯片厂商、AI模型企业、科研院所、个人开发者等全产业链主体,成为推动全球AI基础设施开源化、普惠化的核心力量。

打破CUDA生态壁垒,重构AI时代的算力底层规则

长期以来,AI产业始终面临“硬件性能快速迭代,而软件生态严重滞后”的发展困境。国产AI芯片的理论算力持续追赶国际顶尖水平,但因算子生态的缺失,实际应用中算力释放效率不足10%,大量硬件因适配难题沦为“算力废铁”。

FlagOS的持续突破,正是对这一行业痛点的核心破局。通过Triton开源语言的中立性、跨芯片适配的通用性,以及自动生成技术的高效性,FlagOS彻底打破了“芯片-算子-框架”的深度绑定模式,让不同架构的AI芯片都能通过统一的算子库释放极致算力,让中小开发者无需掌握底层硬件架构知识,即可快速完成高性能算子开发与模型适配。

500个算子的里程碑,既是FlagOS技术栈发展的全新起点,也是中国开源AI生态走向全球引领的重要一步。未来,FlagOS技术社区将持续拓展算子覆盖场景、优化算子性能、完善跨芯片适配能力,持续深化与PyTorch等全球主流开源框架的生态融合,吸引更多开发者与机构参与开源共建,打造全球领先的中立、开放、高性能的AI算子基础设施,让每一颗AI芯片的算力都能被充分释放,推动全球AI产业从“单芯片垄断”走向“多元算力普惠”的全新发展阶段。

更多了解,请点击链接

GitHub地址:https://github.com/flagos-ai/FlagGems

关于众智FlagOS社区

为解决不同 AI 芯片大规模落地应用,北京智源研究院联合众多科研机构、芯片企业、系统厂商、算法和软件相关单位等国内外机构共同发起并创立了众智 FlagOS 社区。成员单位包括北京智源研究院、中科院计算所、中科加禾、安谋科技、北京大学、北京师范大学、百度飞桨、硅基流动、寒武纪、海光信息、华为、基流科技、摩尔线程、沐曦科技、澎峰科技、清微智能、天数智芯、先进编译实验室、移动研究院、中国矿业大学(北京)等多家在 FlagOS 软件栈研发中做出卓越贡献的单位。

FlagOS 是一款专为异构 AI 芯片打造的开源、统一系统软件栈,支持 AI 模型一次开发即可无缝移植至各类硬件平台,大幅降低迁移与适配成本。它包括大型算子库、统一AI编译器、并行训推框架、统一通信库等核心开源项目,致力于构建「模型-系统-芯片」三层贯通的开放技术生态,通过“一次开发跨芯迁移”释放硬件计算潜力,打破不同芯片软件栈之间生态隔离。

官网:https://flagos.io

GitHub 项目地址:https://github.com/flagos-ai

GitCode 项目地址:https://gitcode.com/flagos-ai

SkillHub:https://skillhub.flagos.io

自动化越多,为什么IT反而更累?

在IT服务管理升级过程中,自动化几乎是所有企业都会重点投入的方向。无论是工单分配、通知提醒,还是审批流转,自动化工具的引入本应显著降低人工工作量。但现实情况却往往出人意料:自动化规则越多,IT团队反而越忙。ManageEngine卓豪 将为您解答这些问题!

例如,系统中设置了大量规则,但却频繁出现异常情况,需要人工介入处理;自动通知过多,反而增加沟通成本;复杂流程导致用户操作困难,从而增加支持请求。这些问题使自动化从“减负工具”变成“新负担”。

这种现象说明,自动化本身并不会自动提升效率,关键在于如何设计与使用。

问题根源:自动化以“技术逻辑”为中心,而不是“业务逻辑”

在很多企业中,自动化规则的设计往往由IT主导,并以技术实现为核心,例如条件触发、字段匹配与流程分支。这种方式虽然可以实现功能,但未必符合业务实际需求。

例如,某些流程在系统中被严格定义,但在实际操作中却存在例外情况,导致规则频繁失效;或者流程设计过于复杂,使用户难以理解,从而增加沟通成本。

当自动化脱离业务场景时,就很难产生真正价值。

真正有效的自动化,应该从哪里开始?

要实现有效自动化,企业需要从业务需求出发,而不是从技术能力出发。换句话说,应该先明确哪些问题需要解决,例如减少重复工作、提升响应速度或降低沟通成本,然后再设计相应规则。

例如,可以优先自动化高频、标准化程度高的流程,而不是一开始就覆盖所有场景;对于复杂流程,可以保留人工判断空间,从而避免规则冲突。

通过这种方式,企业可以逐步建立稳定的自动化体系,而不是一次性构建复杂系统。

ServiceDesk Plus 如何帮助企业“做对自动化”?

通过ServiceDesk Plus,企业可以基于实际业务场景灵活配置自动化规则,而不是依赖固定模板。系统支持可视化流程设计与规则管理,使IT团队能够更直观地调整策略。

同时,通过与SLA与数据分析结合,企业可以持续评估自动化效果,并进行优化。这种闭环机制,可以避免自动化失控或失效。

在下一部分中,我们将深入分析:如何通过优化自动化策略,让IT真正“少做事,而不是多做系统维护”。

常见问题(FAQ)

  1. 自动化是否越多越好?
    不是,应根据实际需求设计。
  2. 如何判断自动化是否有效?
    通过SLA与效率指标进行评估。
  3. 自动化失败的常见原因是什么?
    规则复杂、脱离业务场景与缺乏数据支持。
  4. 如何进一步了解自动化实践?
    可以参考ITSM解决方案获取更多信息。

注:本文含AI辅助创作。

2025 年 12 月 13 日,VeloxCon China 2025 在北京成功举办。作为 Velox 项目首次在中国举办的线下技术大会,汇聚了来自Meta、IBM、蚂蚁集团、阿里云、腾讯、小米、小红书等企业的数十位核心贡献者与一线工程师。

大会通过 18 场演讲将 Velox 置于真实业务场景之中,系统展示了其在架构演进、AI 数据处理、湖仓加速、流批融合等方向的最新实践。这些分享不仅直面性能、稳定性与兼容性等落地挑战,也反应了开发者社区对构建可靠、可扩展、可协同的数据基础设施的共同探索,彰显了中国开发者在全球高性能分析生态中的工程深度与协作广度。

夯实底座,突破能力边界
会议伊始,Velox 项目联合发起人 Pedro 发表开幕致辞。他回顾了 Velox 开源项目的发展历程,从项目启动、开源发布到建立技术治理结构,展示了 Axiom 架构、GPU 支持、PyVelox 等关键进展,强调了社区协作与工程严谨性是项目持续演进的核心动力。他特别提到,Velox 已建立了正式的技术治理机制,并迎来来自 IBM、Intel、NVIDIA、Microsoft 等多家企业的新增维护者,标志着项目正迈向更加开放和可持续的阶段。

在明确了社区与架构演进的总体方向后,大会议题迅速深入到如何利用 Velox 构建高性能计算引擎的具体实践中。阿里云 EMR Serverless Spark 技术负责人周克勇系统阐述了“可组合性”在数据计算领域的实践。他详细解析了阿里云如何深度集成并贡献于 Apache Celeborn、Paimon、Velox 及 Gluten 等开源组件,通过模块化组装构建出高性能湖仓一体引擎。他指出,基于该架构,阿里云 EMR Serverless Spark 成功创造了 TPC-DS 100TB 规模性能测试的世界新纪录,实现性能翻倍与性价比大幅提升。

接着,Meta 软件工程师 Masha Basmanova 阐述了现有查询引擎在跨语言通信、优化器能力与开发体验上面临的挑战,并介绍了基于 C++ 的统一前端框架 Axiom。该框架将 SQL 解析、逻辑优化与物理执行融为一体,通过内置的强大优化器与 Velox 运行时无缝对接,能够实现更高效、可扩展的查询处理。演讲最后,她积极展示了 Axiom 的开源路线图,并欢迎全球开发者加入,共同推动该项目的演进。

强大的执行框架,最终需要服务于极具挑战性的数据场景,特别是爆发式增长的 AI 数据。Meta 软件工程师孟晓烜则在之后的演讲中,深入阐述了应对AI训练数据规模激增与成本挑战的解决方案。他重点介绍了 Meta 如何通过数据归一化技术剥离重复特征,并构建可索引的序列存储系统。依托 Velox 技术栈,团队在训练数据的加载、生成与探索三大环节实现了端到端优化,显著提升了处理效率与资源利用率。

在 Meta 多位工程师从框架演进、可组合架构、数据标准化等角度深入分享后,蚂蚁集团高级技术专家黄叶伟也从企业落地实践层面分享了基于 Velox 的 Spark 加速实践。他重点介绍了基于 Gluten 与 Velox 构建的向量化引擎如何通过任务级 Fallback、Spill 优化、Shuffle 优化等关键技术,在混合部署场景下显著提升 Spark 性能与稳定性。他表示,该方案目前已实现日均数十万任务覆盖,平均节省资源超30%,并将在算子优化与架构扩展方面持续演进。

作为连接 Spark 生态与原生加速的关键中间层,Apache Gluten 的进展同样备受关注。来自 IBM 的莫芮与周渊聚焦 Apache Gluten与 Velox 的深度集成,阐述了其如何在大数据分析中驱动创新。他们介绍,Gluten 在保持对 Spark/Flink 作业透明加速能力的同时,正逐步增强对多后端引擎和复杂业务场景的适配能力。目前,该方案已在 Pinterest、顺丰科技及多个内部集群完成规模化验证,有效支撑了从日志分析到物流调度等多样化负载的性能提升与成本优化。

随着向量化加速在通用场景日趋成熟,针对特定存储格式的深度优化成为新的效能突破口。腾讯大数据开发工程师陈锦海分享了微信基于 Velox 加速 lceberg 湖仓分析的优化与实践,重点介绍了原生分桶方案。据他介绍,该方案通过动态识别表元信息自动设置分区数,能有效缓解 AQE 引发的写入倾斜,结合空闲资源灰度发布策略,可保障大规模作业的稳定上线。

扎根场景,释放协同效能
午餐后的议程更加聚焦 Velox 在真实业务中的集成深度与生产韧性,回应了开发者们对兼容性、稳定性与端到端效能等规模化落地的核心关切。
小米计算平台计算引擎负责人王胜杰分享了公司在 Spark 向量化升级中的规模化落地经验。面对业务迁移中的兼容性与稳定性挑战,他表示,小米通过自动兼容校验、双跑结果比对及内存异常感知的三级资源升级机制,已成功推动向量化改造在数十万作业中平稳落地。

面对海量数据挑战,全球科技公司也在探索相似的演进路径。Meta 软件工程经理 Stanley Yao 在演讲中分享了公司基于 Velox 推进 Spark 向量化改造的整体策略。他表示,团队通过从定制化方案到开源架构的持续演进,已实现关键业务管线向 Gluten(Flare)的平稳迁移,并获得显著的效率提升。未来,Meta 计划进一步扩大该架构的应用规模。

在 CPU 向量化趋于普及的同时,利用异构硬件挖掘更高性能成为新的前沿。IBM 研究院资深软件工程师 Zoltán Arnold Nagy 展示了基于 Velox 与 Presto 的 GPU 加速数据处理方案。他介绍道,Velox 通过与 cuDF 集成,可在 GPU 上高效执行算⼦,并针对多 GPU 分布式场景优化通信与数据交换。此外,为突破 I/O 瓶颈,团队正在探索结合 GPUDirect 存储与缓存层的加速策略。

对性能与稳定性的追求,也驱动着查询引擎架构本身的融合与创新。Meta 软件工程师谭家梁与大家分享了 Native Presto-on-Spark 的规模化应用。该架构以 Presto 查询优化、Spark 资源调度与容错机制以及 Velox 原生向量化执行为核心,实现了性能与可靠性的显著提升。他表示,目前该方案已在生产环境中取得成效,并将在未来持续推进全栈原生化演进。

对于国内庞大的云上业务,Velox 同样在支撑着关键数据服务平台。 阿里云高级工程师王彬与范阿冬系统介绍了Velox在阿里云日志服务中的深度集成与应用。他们指出,基于 Velox 构建的高性能查询引擎,通过混合执行、表达式下推、自动增量物化视图及免 Schema 分析等核心技术,可显著提升平台在处理海量实时数据时的查询效率与资源利用率。他们还强调,该架构不仅为日志分析、智能运维等场景提供了稳定支撑,也为面向 AI 的云原生数据平台演进奠定了坚实基础。

除了通用的日志与湖仓分析,Velox 也在向更垂直的时序数据场景渗透。腾讯高级工程师李兆龙分享了基于 Velox 构建云原生时序数据库的落地经验。他表示,通过在 Velox 中实现时序数据去重优化与存储写入增强,系统在应对高频写入与实时查询场景时,可显著提升吞吐效率与响应性能。目前该方案已有效支持物联网、实时监控等业务场景,未来还将进一步完善缓存与压缩机制,持续优化时序数据处理的整体效能。

IBM 软件工程师刘平接着分享了 Velox 在 Iceberg 数据写入能力上的突破性进展。他表示,目前 Velox 对 Iceberg 的支持以读取为主,其写入功能的完善将填补该方向的关键能力空白,为基于 Presto 与 Spark 的数据湖架构提供更统一、高效的数据摄入层。这一进展也标志着 Velox 正从查询加速向数据全链路处理拓展。

接着,来自阿里云的毕岩与周滔分享了 Velox 与 Apache Paimon 深度集成的解决方案,为提升引擎与存储的协同效率提供了另一种集成思路。在他们看来,现有方案存在表类型支持受限、缺乏可移植性等瓶颈, 但可以建立 C++ 原生 Paimon 库,通过其统一的数据协议与插件化设计,使 Paimon 能够被 Velox、StarRocks 等多种计算引擎直接高效调用,从而提升数据读写性能,并为湖仓格式的跨引擎协同提供新的基础支撑。

在批处理场景之外,流计算框架的向量化也正成为新的热点。蚂蚁集团技术专家刘勇介绍了基于 Velox 为 Flink 构建的统一向量化执行引擎 Flex。他表示,Flink 作为流批一体架构的核心,其原生向量化能力的补足至关重要。Flex 通过将 Velox 的高性能算子能力引入 Flink,同时结合自动化验证、可视化计划与精细化回退机制,现已实现了作业性能的显著提升,并支撑多条核心业务链路平稳运行。

随着 Velox 赋能的应用场景日益广泛和复杂,确保其在不同引擎和版本间的整体质量与可靠性变得至关重要。Meta 软件工程师 Eric Liu 阐述了在 AI 数据基础架构下,保障 Velox 多引擎版本可靠性的系统化方法。他指出,面对不同引擎与存储格式交织带来的复杂性,关键在于建立跨引擎测试框架与合成数据工厂。这一实践能有效提前发现全栈潜在问题,从而确保底层变更在大规模生产环境中的稳定与高效。

针对向量化引擎中窗口运算符内存溢出的典型难题,来自英特尔的贾柯分享了她的见解。她认为,通过为 Velox 引入流式窗口处理机制,可使计算随数据到达逐步执行并即时释放内存,从而从架构层面化解多数场景下的内存风险,显著提升复杂查询的稳定性。

最后,小红书 Native Engine 团队技术负责人魏秀利也分享了向量化引擎在公司业务中规模化落地的经验。据他介绍,通过将写入异步化并构建原生 Avro 读取能力,小红书在不增加业务复杂度的前提下,成功缓解了端到端延迟,印证了“执行与存储协同优化”在湖仓场景中的关键价值。

从底层执行引擎的持续创新,到日志分析、湖仓写入、流批融合等复杂场景的稳定运行,在本届 VeloxCon China 上,我们看到 Velox 的技术价值已在真实业务中不断被验证和拓展。同时我们也很高兴看到中国开发者成为这一进程的重要推动者。期待未来有更多志同道合者加入 Velox 开源社区,共建高性能分析基础设施。weibo.com/ttarticle/p/show?id=2309405290086815629383 weibo.com/ttarticle/p/show?id=2309405290087230865518 weibo.com/ttarticle/p/show?id=2309405290087587119464 weibo.com/ttarticle/p/show?id=2309405290088115601507 weibo.com/ttarticle/p/show?id=2309405290088476311626 weibo.com/ttarticle/p/show?id=2309405290088832827475 weibo.com/ttarticle/p/show?id=2309405290089189605615 weibo.com/ttarticle/p/show?id=2309405290089612968087 weibo.com/ttarticle/p/show?id=2309405290090124935314

听说有 7 元一个月的,源头的,没找到购买连接
请大佬们分享一下

买了 cursor/claude,花了 200 多,站起来蹬,已经全部用完了
自费上班. 太苦了

今天,我在 github 查看项目



https://github.com/owu/wsl-dashboard



的流量来源,发现有很多谷歌来源。



我试着谷歌“WSL Dashboard”,居然看到微软商店 9.99 刀的同名项目(简单的换了皮肤,功能是我的上一个版本,界面上的选项都一样,4 月 15 号发布的),开发者是合肥的一个公司,这个人也在 V 站(备注的创始人)。



简单看了一下微软商店他发布的软件,就发现还盗版了 alist 项目,还有一些其他的应用没仔细看。



有人盗版,说明项目还可以😂

今日亮点

今天 AI 圈有两大看点。OpenAI 发布播客,深入探讨了其用于生物学和药物发现的生命科学模型系列,透露了“GPT-Rosalind”的更多细节。同时,Anthropic 也公布了两项重要研究进展:一项关于大语言模型“潜意识学习”的论文登上了《自然》杂志,另一项研究则展示了其自动化对齐研究员(AARs)在提升模型性能上的显著成效。

💡 产品动态

OpenAI 推出生命科学模型播客

OpenAI 最近在其播客中深入介绍了其全新的生命科学模型系列,特别提到了代号为 GPT-Rosalind 的前沿推理模型。这款模型旨在支持生物学研究、药物发现和转化医学领域,讨论涵盖了模型在改善研究工作流和未来实现自主实验室方面的潜力,以及部署过程中的责任考量。

为什么重要: 这表明 OpenAI 正将 AI 能力扩展到特定科学领域,通过更专业的模型来加速生命科学研究,有望大幅提升药物研发和生物探索的效率。

阅读原文

🔬 学术前沿

Anthropic 合作研究“潜意识学习”发表于《自然》

Anthropic 参与合著的一项关于**“潜意识学习”(subliminal learning)**的研究论文登上了知名科学期刊《自然》。这项研究揭示了大型语言模型(LLMs)如何通过数据中隐藏的、看似无关的信号,传递出偏好或潜在的错误对齐等特质。最初的预印本在去年 7 月发布,展示了 LLMs 如何通过与特定特质无关的数据(例如看似无意义的数字)来传递这些特质。

为什么重要: 这项发现对 AI 安全和可解释性具有深远影响,意味着即使是“干净”的训练数据也可能无意中夹带导致模型偏差的隐藏信号,为大模型行为研究提供了新视角。

论文

Anthropic 自动化对齐研究员显成效

Anthropic 的“自动化对齐研究员”(Automated Alignment Researchers,简称 AARs)在模型性能提升上取得了显著成果。在使用 Opus 4.6 模型并辅以额外工具的 AARs 团队,在短短 7 天内,将一个弱模型与潜在的强模型之间的性能差距弥合了 97%。相比之下,人类研究人员在相同时间内仅弥合了 23% 的差距。AARs 的最佳方法还在未经训练的数据集上成功推广到编程和数学任务。

为什么重要: 这项突破表明,AI 在自我优化和对齐研究方面展现出巨大潜力,有望加速开发出更安全、更强大的 AI 系统,同时大幅降低对人工干预的依赖。

阅读原文

🌍 行业观察

Anthropic 董事会新增医学界高管

Anthropic 的长期利益信托(Long-Term Benefit Trust)任命Vas Narasimhan 为公司董事会成员。Vas Narasimhan 在医学和全球健康领域拥有超过二十年的经验,曾担任诺华公司(Novartis)的首席执行官。

为什么重要: 这项任命为 Anthropic 带来了重要的医疗和全球健康领域的专业知识,可能预示着公司未来在生命科学和医疗 AI 应用方向的进一步布局,同时也有助于提升 AI 技术在伦理和负责任应用方面的考量。

阅读原文

💻 开源项目

  • caveman(暂无星级):通过像穴居人一样说话,将 Claude Code 的 token 使用量减少 65%,非常适合想降低成本的用户 → GitHub
  • Claude-Code-Game-Studios(暂无星级):将 Claude Code 变成一个完整的游戏开发工作室,包含 49 个 AI 智能体和 72 项工作流技能,模仿真实工作室层级 → GitHub
  • rtk(暂无星级):一个 CLI 代理,能在常用开发命令上将 LLM token 消耗降低 60-90%,单个 Rust 二进制文件,零依赖 → GitHub
  • openai-agents-python(暂无星级):OpenAI 官方推出的一个轻量级、强大的多智能体工作流框架,适合构建复杂 AI 应用 → GitHub
  • multica(暂无星级):Multica 旨在将编码智能体变成真正的队友,用户可以像分配给同事一样将问题分配给智能体,它们会自主地接手工作、编写代码并报告障碍 → GitHub
  • CL4R1T4S(暂无星级):泄露了 ChatGPT、Gemini、Grok、Claude 等主流 AI 模型的系统提示词,旨在促进 AI 系统透明度 → GitHub
  • graphify(暂无星级):一款 AI 编码助手技能,能将任何代码、文档、论文或图片文件夹转化为可查询的知识图谱,便于信息检索与理解 → GitHub
  • thunderbolt(暂无星级):一个让你掌控 AI 的平台,用户可以选择自己的模型、拥有自己的数据,旨在消除供应商锁定 → GitHub
  • voicebox(暂无星级):一个开源语音合成工作室,为开发者和创作者提供语音生成和编辑工具 → GitHub
  • cc-haha(暂无星级):泄露的 Claude Code 源代码的本地可运行版本,并附带核心模块解析,对于研究 Claude Code 内部机制的开发者很有价值 → GitHub

32岁生日刚过半个月,我接到了HR的电话,让我去一趟会议室。我当时还在改一个紧急的线上bug,心里嘀咕着这时候找我干嘛,是不是又要让我背什么新的KPI?

到了会议室,里面坐着HR、我的直属leader,还有一个我从来没见过的法务。他们的表情都很严肃,我瞬间就慌了,脑子里开始飞速运转:我最近有没有犯什么错?项目是不是出了什么大问题?

HR先开口了:"XXX,经过公司的综合评估,我们决定对你进行优化。"

我当时脑子一片空白,过了好几秒才反应过来她在说什么。"优化",多么好听的词,说穿了就是裁员。我看着她,一句话也说不出来,只能下意识地问:"为什么?"

leader叹了口气,说:"公司业务调整,我们部门要缩减编制,你的绩效排名不太靠前,所以......

我还想再说什么,但法务已经把一份《解除劳动合同通知书》放在了我面前,说:"你可以先看一下,如果没有问题的话,在这里签个字。我们会按照N+1的标准给你赔偿。"

我拿起那份通知书,手一直在抖。上面的每一个字都像针一样扎在我的眼睛里:"因公司业务调整,经双方协商一致,解除双方于XXXX年XX月XX日签订的劳动合同。"

那天的阳光很刺眼,但我却觉得浑身冰冷。我在那个大厂待了8年,从一个刚毕业的毛头小子做到高级工程师,我把最好的青春都献给了这里,最后却落得这样一个下场。

二、走出办公楼的那一刻

签完字,HR让我收拾一下个人物品,她会派人陪我一起去工位。我回到工位,看着那些熟悉的电脑、键盘、鼠标,还有墙上贴的各种便签,眼泪终于忍不住掉了下来。

同事们都投来了同情的目光,但没人敢过来跟我说话。我知道,他们也怕自己是下一个。我默默地收拾着东西,把一些重要的文件拷贝到U盘里,把自己的私人物品装进一个纸箱里。

当我抱着纸箱走出办公楼的那一刻,我回头看了一眼那个我曾经奋斗过的地方,心里五味杂陈。我想起了刚入职的时候,每天都充满了干劲,觉得自己能在这里做出一番事业;我想起了加班到深夜,和同事们一起吃外卖的日子;我想起了项目上线成功,大家一起欢呼庆祝的时刻。

但现在,这一切都成了过去。我像一个被抛弃的孩子,站在人来人往的大街上,不知道该去哪里,也不知道该做什么。

三、那段黑暗的日子

从被裁员的那天起,我陷入了深深的自我怀疑和焦虑中。我每天都待在家里,不想出门,也不想见人。我不停地刷着招聘网站,投了无数份简历,但都石沉大海。

有时候我会想,是不是我真的老了,已经跟不上时代的步伐了?是不是我真的不够优秀,所以才会被公司淘汰?我甚至开始后悔,为什么当初没有多学点东西,为什么没有多攒点钱,为什么没有给自己留一条后路。

我的家人和朋友都在安慰我,让我不要灰心,说这只是暂时的困难。但我知道,他们的安慰对我来说并没有多大的作用,这种挫败感只有我自己才能体会。

那段时间,我每天都失眠,头发也掉了很多。我感觉自己像一个废人,什么都做不了,什么都不想做。

四、重新站起来的过程

就这样浑浑噩噩地过了一个多月,我终于意识到,我不能再这样下去了。我必须重新站起来,重新找回自己的信心和勇气。

我开始调整自己的心态,告诉自己被裁员并不是什么丢人的事,这只是职业生涯中的一个小挫折。每天都花几个小时来学习补充新的知识。

我也开始锻炼身体,每天早上都会去公园跑步,晚上会去健身房锻炼。身体上的锻炼让我感觉自己的精力越来越充沛,心情也越来越好了。

慢慢地,我开始收到一些面试邀请。虽然很多面试都失败了,但我并没有放弃。每一次面试我都会认真准备,总结经验教训,不断地改进自己。

<<<顺手说一个:有新的技术大厂在→要人,前后端和测试,一线城市及双一线城市几乎都有坑位,待遇稳定性都还成。感兴趣的可以瞅瞅

终于,在被裁员后的第三个月,我拿到了一家心仪公司的offer。虽然薪资比之前低了一些,但我觉得这是一个新的开始,一个重新证明自己的机会。

五、给所有职场人的建议

经历了这次被裁员的事情,我想给所有职场人一些建议:

建议一:保持危机意识

不要觉得自己在一个大厂待着就高枕无忧了,市场是随时变化的,公司也随时可能进行调整。
要不断地学习新的知识和技能,提升自己的核心竞争力,让自己在任何时候都有选择的权利。

建议二:不要把鸡蛋放在一个篮子里

不要把所有的希望都寄托在一份工作上,要给自己留一条后路。
可以利用业余时间发展一些副业,或者投资一些理财产品,增加自己的收入来源。

建议三:保持积极的心态

职场中难免会遇到挫折和困难,这时候保持积极的心态非常重要。
不要轻易放弃,要相信自己的能力,相信自己一定能够度过难关。

如果你也正在经历职场的低谷,不要灰心,不要丧气。相信自己,只要你不放弃,就一定能够重新站起来,迎接新的挑战。