如何克服攀登松手下落那刻的恐惧?
在尝试运动攀登(带绳索),前面四五次都是有人在底下保护,所以绳索时刻拉紧,很有安全感。但不能随时找到同伴做保护,所以最近在尝试顶端自动保护。但是!松手那刻,自动保护不会立刻收紧绳索,会有 1 秒左右的自由落体的感觉。我觉得特别恐怖,每次都很难劝自己松手,但不松手的话,会撞向墙、或者旋转,很容易受伤🤕
有人有类似的体验吗?有没有克服这种恐惧的经验可以分享下
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
在尝试运动攀登(带绳索),前面四五次都是有人在底下保护,所以绳索时刻拉紧,很有安全感。但不能随时找到同伴做保护,所以最近在尝试顶端自动保护。但是!松手那刻,自动保护不会立刻收紧绳索,会有 1 秒左右的自由落体的感觉。我觉得特别恐怖,每次都很难劝自己松手,但不松手的话,会撞向墙、或者旋转,很容易受伤🤕
有人有类似的体验吗?有没有克服这种恐惧的经验可以分享下
近日,广告欺诈检测与数字安全公司 Pixalate 发布了名为“了解你的开发者”(Know Your Developer,KYD)的公开数据库。 该数据库面向苹果与谷歌应用商店中的移动应用开发者,提供围绕儿童在线安全、隐私合规和广告风险的持续监测结果。数据库免费开放,并按月更新。 根据 Pixalate 披露的信息,KYD 当前覆盖 356,095 家以广告变现为主要收入来源的移动应用开发者,其中 86,028 家至少运营一款面向儿童的应用。评估范围包括精确地理位置数据访问与传输、家长同意机制合规性、广告流量质量、应用安全更新频率以及开发者主体透明度等多个维度。 KYD 的一个核心问题指向应用商店的“数据安全”标签机制。苹果与谷歌均采用开发者自申报(self-reported)的方式披露数据收集与共享情况。Pixalate 表示,在其对广告竞价请求流(bid request stream)的长期监测中,发现部分应用在商店页面声明“不收集数据”或“不共享数据”,但在实际广告请求过程中仍向第三方发送精确地理位置坐标。 从技术路径上看,精确地理位置数据通常嵌入在实时竞价(RTB)请求中,通过广告 SDK 或程序化广告接口传输至广告交易平台、数据经纪商或其他中间方。一旦进入广告生态链路,数据可被用于设备指纹构建与跨应用跟踪。 截至 2025 年 12 月,Pixalate 统计显示: 118,049 家开发者(约 33%)具备通过应用权限访问精确地理位置的能力; 24,124 家开发者在广告竞价请求流中向第三方共享精确地理位置坐标; 62%的广告变现型开发者运营的应用存在儿童隐私或在线安全漏洞。 上述数据意味着,在广告变现模式下,精确位置数据的暴露并非个别现象,而是具有一定规模性。 在面向儿童的应用领域,KYD 重点测试了可验证的家长同意机制(Verifiable Parental Consent,VPC)是否符合 Children's Online Privacy Protection Act(COPPA)的要求。 Pixalate 信任与安全咨询委员会对 3,936 款热门广告变现型儿童应用进行了下载与人工测试。其中 3,907 款(99%)未能通过 VPC 验证测试。这意味着在样本范围内,大多数应用未能在收集儿童个人信息前完成法律要求的家长同意流程。 在广告技术语境下,如果儿童被默认视为“普通用户”,其设备标识符、IP 地址、精确位置等信息可能直接进入广告请求流,并参与受众定向与竞价匹配。这种默认路径在未完成年龄识别与家长授权前即开始数据处理,构成潜在合规风险。 KYD 数据库围绕七类风险建立持续监测模型: 精确地理位置信息:评估开发者是否具备访问并向第三方传输精确坐标的能力。 可验证家长同意机制(VPC):通过人工测试确认是否存在符合 COPPA 要求的授权流程。 被禁应用风险:195,342 家开发者在该维度被评为“严重”,涉及其应用曾被下架或其历史用户基础中包含已被移除应用。 不安全广告风险:20,796 家开发者与无效流量(IVT)或广告欺诈信号存在关联。Pixalate 在广告欺诈检测领域获得 Media Rating Council(MRC)认证。 应用安全风险:10,198 家开发者在三年以上未对高用户规模应用提供安全更新。 隐私政策缺失:7,222 家开发者未提供可访问的隐私政策文本。 匿名所有者风险:1,535 家开发者通过隐藏域名注册信息或空壳公司结构降低可追溯性。 从工程视角看,上述风险多数可通过自动化数据抓取、SDK 行为分析、广告流量取样与人工审核结合的方式进行建模与验证。 在美国,围绕平台责任的立法讨论持续推进。2025 年 12 月,苹果公司 CEO Tim Cook 曾就《App Store Accountability Act》相关议题与立法者沟通。该法案提议要求应用商店对开发者进行额外合规审查,并加强年龄验证与信息共享机制。 KYD 的发布发生在这一监管背景之下。Pixalate 在报告中指出,当前应用商店向用户展示的主要是单个应用的评分与评论,而缺乏开发者层级的历史违规记录、隐私模式分析与广告数据链路透明度信息。 从数据流架构角度看,平台层面的儿童安全标识并未必在 SDK 集成与广告请求环节得到有效执行,形成“信号传递断层”。当应用采用混合受众策略(mixed audience),而未在技术路径上区分儿童流量与成人流量时,儿童数据可能直接进入常规广告处理流程。 KYD 的数据结构设计支持通过大语言模型进行查询,例如使用类似“某开发者是否存在儿童在线安全风险标记”这样的提示语进行检索。其数据模型本质上是对开发者主体的风险标签化与可查询化。 对移动应用开发者而言,KYD 所揭示的问题并非单一合规条款,而是广告 SDK 集成、权限申请策略、数据最小化原则、日志留存机制与版本更新策略等工程决策的综合结果。 在广告驱动的商业模式下,开发者通常依赖第三方 SDK 完成变现。但精确位置坐标、设备标识符等字段一旦进入 RTB 请求流,便可能被下游多方复制与再利用。因此,如何在架构层面实现儿童流量隔离、权限最小化配置与透明的家长同意机制,将成为面向未来监管环境的核心技术议题。 KYD 数据库本身不改变应用商店的审核机制,但为外部研究人员、学校 IT 管理员与隐私倡导组织提供了一个可持续更新的开发者风险视图。对于技术社区而言,其价值在于提供了可量化的指标与样本数据,用以审视当前移动广告生态中的儿童数据处理实践。数据安全标签与实际行为之间的偏差
COPPA 合规与可验证家长同意机制测试结果
七类风险维度的结构化评估
开源的最好,如果能免费就更好了
最近整理了下这三年的家庭支出,越看越感慨:现在的钱真是越来越不禁花。
夫妻二人住在一线城市郊区,整体开支算不上奢侈,基本就是维持日常生活、孩子、住房、贷款这些,结果累计下来还是挺惊人的。
| 支出类型 | 支出金额(元) | 占比 |
|---|---|---|
| 住房 | 161592.70 | 25.60% |
| 通讯 | 3971.00 | 0.63% |
| 伙食费 | 52637.00 | 8.34% |
| 亲友 | 99133.00 | 15.70% |
| 美容 | 8246.00 | 1.31% |
| 日用 | 21524.00 | 3.41% |
| 交通 | 18148.00 | 2.88% |
| 宠物 | 13490.00 | 2.14% |
| 医疗 | 5048.00 | 0.80% |
| 服饰 | 12295.00 | 1.95% |
| 贷款 | 162330.00 | 25.72% |
| 孩子 | 66234.00 | 10.49% |
| 其他 | 6579.00 | 1.04% |
| 全部支出 | 631227.70 | 100.00% |
这样一算,真正能灵活支配的钱其实并不多。
感觉这几年不是乱花钱,而是生活本身的基础成本就在不断抬高。
维持个温饱,真的越来越不容易了……
你们在 vibe ( spec ) coding 时,其中 ai 编码的间歇时间,你们一般会干什么来提升效率

clearlinux.org 域名重定向至 GitHub。在公司大范围削减成本的背景下,这一举动让这款主打性能优化的 Linux 发行版未来蒙上巨大阴影。Intel 公司悄悄拆除了为性能优化版 Linux 发行版 Clear Linux 提供的关键公共基础设施,此举在开源社区引发震动,也让外界严重质疑这家芯片厂商对该项目的长期投入态度。
目前 clearlinux.org 已跳转至 GitHub 仓库,专用下载服务器下线,社区论坛消失 ——全程没有任何来自 Intel 的正式说明。
最早由知名 Linux 硬件软件媒体 Phoronix 披露这一变动:clearlinux.org 已不再是独立官网,用户会被直接重定向到 Clear Linux 的 GitHub 页面。
虽然源代码仍然公开,但曾经面向普通用户、完整易用的项目门户已彻底消失。
Clear Linux 从一开始就不是面向普通桌面用户的主流系统。
它由 Intel 于 2016 年推出,从底层设计就是为了充分展现 Intel 硬件的性能潜力。
它在开发者、系统管理员与性能发烧友中积累了大量忠实用户,不仅速度出众,更作为 Intel 架构优化的参考平台 存在。
同时也成为多项前沿软件技术的试验场,包括函数多版本、基于剖面的优化等技术,Intel 希望这些优化最终能在整个 Linux 生态中普及。
clearlinux.org 不再承载原有内容,直接跳转 GitHub这并非该项目首次被缩减。
过去几年,Intel 已逐步淡化 Clear Linux 在桌面与工作站场景的定位,转向云与容器场景;同时降低了更新频率,缩减了软件仓库规模。
但直接关停官网是更具决定性的一步,几乎让新用户无法再轻松发现、下载与安装该系统。
本次基础设施关停最反常的一点是:
Intel 没有发布任何官方说明 —— 没有博客、没有新闻稿、没有邮件列表与社交平台公告。
这种沉默直接让 Linux 社区普遍猜测:
即便代码仍然公开,Clear Linux 作为面向公众的项目已被逐步放弃。
Intel 历史上曾多次推出雄心勃勃的开源项目,又在公司战略转向后悄然退场:
Tizen、MeeGo 等多个软件项目均是如此 —— 初期大力投入,随后随着管理层变动或市场环境变化逐渐撤资。
Clear Linux 如今似乎正在走上同一条老路。
Clear Linux 基础设施被关停,恰逢 Intel 面临巨大财务压力。
在现任管理层主导下,公司正在推行大范围成本削减计划:裁员数千人,砍掉所有与核心半导体制造、设计业务无关的部门开支。
Intel 的晶圆厂战略、在数据中心与消费端市场与 AMD 和 Arm 的竞争、以及争取政府芯片补贴等事务,已占用大量管理精力与资金。
在这种环境下,维护一套完整 Linux 发行版所需的独立网站、文档团队、社区运营等成本,被认为难以持续。
Clear Linux 独有的更新工具 swupd 依赖 Intel 官方服务器提供更新,而非像 Debian、Fedora、Ubuntu 那样使用分布式镜像。
这种中心化架构意味着:
一旦 Intel 关闭更新服务器,用户没有任何备用镜像可以切换。
如果更新服务下线(或已下线),现有系统将彻底停更,无法获得安全补丁与新版软件。
用户只能整体迁移到其他 Linux 发行版 —— 对生产环境而言,这是成本极高的工程。
在论坛、社交媒体与 Linux 社区中,用户情绪从无奈接受转为不满。
许多 Phoronix 评论区用户表示,早在数月前就从更新频率下降、软件包减少等迹象中预感到结局。
也有大量用户表示失望:Intel 甚至没有提前通知,也未为受影响用户提供过渡方案。
部分社区成员提出分支复刻(fork) 的可能:
在脱离 Intel 的前提下,基于开源代码继续独立开发。
但这条路挑战巨大:
Clear Linux 构建系统复杂,优化流水线高度依赖 Intel 专属工具链,维护完整发行版需要庞大团队长期投入。
失去 Intel 资源后,社区复刻版本很难达到原版的规模与性能水准。
无论 Clear Linux 最终命运如何,它都为 Linux 社区留下了实实在在的价值。
Clear Linux 团队开创的大量性能优化已上游合入 Linux 内核、GCC、系统库等核心项目。
该发行版用事实证明:
通过精细编译与系统配置,可实现大幅性能提升 —— 这一思路后来被众多发行版借鉴。
Intel 在 Clear Linux 上的实践还影响了容器优化系统设计,并推动了无状态系统、自动更新、开源遥测等领域的讨论。
这些思想已被 Fedora CoreOS、Ubuntu Core 等云原生 Linux 项目采纳。
目前,Intel 外部无人能给出确切答案。
代码仍在 GitHub 上,可能意味着项目仍在内部继续 —— 仅作为 Intel 工程师的参考平台或优化试验场,不再需要公共官网。
但也可能只是还没来得及归档仓库而已。
可以确定的是:
作为一套拥有完整公共基础设施与社区支持的 Linux 发行版,Clear Linux 已被严重削弱。
clearlinux.org 的消失不只是界面改动,而是项目失去了对外的主要窗口。
没有下载页、没有文档、没有论坛,Clear Linux 对不熟悉它的人来说几乎等于 “不存在”,只能从源码手动编译。
对 Intel 而言,悄悄关停 Clear Linux 公共服务只是庞大企业重组中的一个小注脚。
对开源社区而言,这是一次清醒的提醒:
依赖企业赞助的开源项目,随时可能因商业战略变化而被缩减甚至放弃。
而对于那些打造 Clear Linux、不断突破 Linux 性能边界的开发者来说,他们的工作成果已留在上游社区 —— 即便那个曾经展示这些成果的发行版,或许已时日无多。

可疑的密码输入弹窗暴露了此次攻击,关联到的初始域名包括:
optimize-storage-mac-os.medium.com、octopox.com、vagturk.com。
分析发现至少 53 个被入侵的广告账号,其中甚至有账号同时推广邮轮广告与虚假 macOS 修复工具。
类似恶意广告还出现在 Evernote、mssg.me、kimi.com 等平台。
安全研究者 @itspappy 与 Gi7w0rm 在一次险些中招的事件后揭露了该攻击链:
一名用户搜索 macOS 存储修复工具时,点击了谷歌置顶结果,进入一篇伪造的 Medium 文章,其中包含恶意 Shell 命令。

xattr -c 移除隔离属性,绕过 Gatekeeper 防护。部分攻击链会通过循环弹窗骗取管理员密码,将密码保存在 ~/.pass,供后续提权使用。
这种社会工程学手段可在无系统告警的情况下提升载荷执行成功率。
攻击者下载的是同时支持 x86_64 与 ARM 架构的 Mach‑O 二进制文件。
样本通过混淆的 AppleScript 执行虚拟机 / 沙箱检测,使用 system_profiler 判断 QEMU/VMware 环境或异常硬件特征。
在 VirusTotal 运行的已修补样本中,暴露出一段超过 59000 字符的 osascript 载荷。
去混淆后可见代码使用凯撒密码加密字符串与随机变量名。
脚本会隐藏终端窗口,收集系统信息,并通过 malext.com 或 38.244.158.56 外发数据。

该恶意软件的特殊之处在于:
单个 Mach‑O 文件内同时打包了两种不同 CPU 架构的攻击载荷。

该恶意软件的特殊之处在于:
单个 Mach‑O 文件内同时打包了两种不同 CPU 架构的攻击载荷。

| 功能 | 说明 | 攻击目标 |
|---|---|---|
| 数据窃取 | 浏览器、钱包、密钥链、文件 | Chrome、Electrum、备忘录 |
| 对抗检测 | 虚拟机检测、xattr -c、gzip/Base64 | Gatekeeper、沙箱 |
| 持久化 | LaunchDaemon、木马化应用 | ~/.agent、Ledger |
| C2 服务器 | HTTP POST 重试、备用 IP | malext.com、199.217.98.33 |
多项特征(com.finder.helper.plist、BuildID 头、/zxc 路径等)表明该家族属于 AMOS,而非 Odyssey。
该活动从 2025 年底开始活跃,依靠大量廉价一次性账号扩张,疑似由流量团伙运营。


.SHOP 与 .CFD 顶级域。这些域名包括:
auracorp.cfd、mscloud.cfd、magicupdate.cfd、gamedb.shop、browsertools.shop、clocktok.cfd 等。
它们均通过 Cloudflare 代理隐藏真实后端服务器。
每个域名使用独立的 Cloudflare 源站证书,但全部指向同一套后端架构,疑似为单台服务器,运行的组件版本均已过时:
Apache 2.2.22、PHP 5.4.45、CodeIgniter 3.1.11、Symfony 3.4.26。

.SHOP 域名,而最新的 1.5.2 样本更倾向使用 .CFD,表明攻击者正在逐步将基础设施从 .SHOP 切换到 .CFD。
AuraStealer 攻击活动采用灵活的投递链,结合社会工程学与通用加载器分发。
其中一个主要传播渠道是 TikTok 上的 ClickFix 骗局:
短视频声称可免费激活 Windows、Microsoft 365、Adobe 系列、Netflix、Spotify 等,并诱导受害者以管理员权限执行一行 PowerShell 命令。
file-epq.pages.dev/updater.exe 下载。regasm.exe、SndVol.exe。多轮攻击活动使用 Donut shellcode 加载器 或 Soulbind 加载器,从攻击者控制的服务器下载 AuraStealer,例如:
94.154.35.115、130.12.180.43。
这些主机还分发 Stealc、Rhadamanthys、Vidar、SalatStealer、NJRAT 等多种远控与窃密木马。
auracorp.cfd 的 Web 管理面板控制感染终端,支持数据面板、载荷生成、日志筛选、Telegram 机器人报警等功能。
在终端侧,1.5.2 版本采用高强度混淆与反分析技术:
间接控制流、异常驱动 API 哈希、XOR 加密字符串、虚拟机与沙箱检测、调试器检测、完整性校验,甚至在检测到钩子或断点时触发隐藏栈破坏。
通过自检后,AuraStealer 可从 100 多款浏览器、70 多款应用中窃取凭证与敏感数据,包括:
加密货币钱包、两步验证工具、VPN 客户端、密码管理器、远程控制软件等。
所有数据通过 AES‑CBC 加密的 HTTPS 传输到轮替 C2 服务器的三个专用接口:apilive、apiconf、apisend。

| CVE ID | 严重级别 | 受影响组件 | 利用机制 | 影响 | 状态 |
|---|---|---|---|---|---|
| CVE-2026-0628 | 高危 | Google Chrome Gemini Live 面板 | 基于 declarativeNetRequests API 注入 JavaScript |
未授权访问摄像头、麦克风、文件及屏幕截图 | 已修复(2026 年 1 月) |
https://gemini.google.com/app)与在普通标签页加载时,采用的安全处理机制不同。
declarativeNetRequests API 的浏览器扩展可以拦截并修改 HTTPS 请求,广告拦截工具普遍使用该能力。
就在 OpenAI 因与美国国防部签订合同,意外引发大规模 #QuitGPT 弃用浪潮之际,Anthropic 果断出手,为自家旗舰 AI 助手 Claude 推出了一项全新的记忆导入(Memory Import)功能。
这项精巧设计允许用户通过一段专用提示词,将在 ChatGPT、Gemini、Copilot 等竞品平台上长期积累的个人偏好与对话上下文,无痛迁移到 Claude 中。
过去,用户想要切换主力 AI 助手,最大的痛点就是必须从零开始,重新培养对话习惯与上下文理解。
而 Anthropic 全新推出的记忆导入彻底解决了这一问题:用户无需具备编程能力,也不必等待竞品平台开放 API 导出接口。
只需复制 Anthropic 提供的官方记忆提取提示词,粘贴到 ChatGPT 或 Gemini 中,即可让原 AI 生成一份完整的指令偏好、项目细节与历史上下文档案。
用户只需将生成的内容复制,粘贴到 Claude 设置里的 ** 管理记忆(Manage memory)** 模块即可。
Anthropic 表示,Claude 大约需要 24 小时来完整消化与吸收这些导入的上下文信息。
完成后,用户可通过 “查看 Claude 对你的了解” 提示词进行核对,并可手动编辑与细化这些记忆内容。
这项功能的推出时机绝非巧合。
就在不久前,Anthropic 因拒绝拆除 AI 安全护栏—— 特别是严格禁止 “大规模国内监控” 与 “全自动武器系统” 相关应用 —— 导致与美国国防部的谈判破裂。
随后,OpenAI 却主动接手了这份被 Anthropic 拒绝的机密军事合同,在互联网上引发轩然大波与强烈不满。
深感失望的欧美用户认为 OpenAI 已沦为 “军工复合体” 的一部分,由此发起声势浩大的 QuitGPT抵制活动,导致数十万 ChatGPT 订阅被取消。
Anthropic 精准抓住这一关键节点,推出记忆迁移工具,精准吸引那些因舍不得 AI 记忆而犹豫迁移的用户。
这相当于向弃用用户喊话:大门已敞开,带上你的记忆来这里。
这一策略效果极为惊人。
在抵制浪潮与无缝迁移体验的加持下,Claude 近期在 App Store 免费应用排行榜超越长期霸榜的 ChatGPT,成功登顶。
在软件服务领域,尤其是大模型行业,迁移成本一直是巨头最坚固的壁垒。
用户花费数月甚至数年教会 ChatGPT 自己的身份、项目细节与独特的编码习惯,形成高度默契;
而在传统模式下,切换到新平台意味着这些积累全部清零。
长期以来,OpenAI 始终未提供完整的记忆数据导出功能,以此牢牢绑定核心用户。
而 Anthropic 使用自然语言提示词反向提取 ChatGPT 记忆的方式,巧妙绕开了这些技术壁垒。
这一做法不仅打破了对手的护城河,更在 #QuitGPT 舆论风暴中,将自身塑造为坚守道德底线的挑战者。
未来,生成式 AI 的竞争将不再只是算法与算力的比拼;
一场真正的“数字记忆主权” 争夺战,才刚刚进入最激烈的阶段。

我们已然正式步入自主智能体时代 —— 这类智能 AI 程序不仅能与你对话,还能在计算机上执行实际操作,例如整理文件、检索网页或运行脚本。
可一旦黑客诱骗这款贴心的数字助手为其执行恶意操作,后果将不堪设想。
一款名为 MS-Agent 的框架新近曝出一处安全漏洞,恰恰揭示了这一前沿技术潜藏的巨大风险。
该漏洞编号为 CVE-2026-2256,攻击者可通过精心构造的文本内容劫持 AI 智能体,进而控制底层计算机系统。
MS-Agent 框架旨在帮助开发者构建可自动执行任务的轻量级 AI 智能体。
为此,框架内置了名为 Shell tool 的功能,该功能本质上赋予了 AI直接向操作系统执行命令的权限。
风险源于 AI 处理信息的机制。
若智能体被要求读取文档、总结网页内容,或交互的对话提示被攻击者暗中植入隐藏指令,AI 便可能盲目执行这些隐藏命令。
在网络安全领域,这种攻击被称为提示词注入攻击—— 相当于对人工智能实施的 “思维操控”。
MS-Agent 的开发者并非没有意识到这一风险,因此编写了名为 check_safe() 的校验代码。
这道 “安全门卫” 依赖黑名单机制:列出已知恶意词汇与高危命令,禁止 AI 执行。
然而,CERT/CC 漏洞公告明确指出,简单的黑名单远远无法阻挡有备而来的攻击者:
“check_safe () 方法基于正则表达式的黑名单,不足以防御命令注入。基于黑名单的过滤机制天生脆弱,极易通过编码、命令混淆或另类 Shell 语法绕过。”
一旦伪装命令绕过安全检测,AI 便会误以为在正常执行任务,进而运行该指令。
由此引发的后果极为严重。
安全公告警示:
“成功利用该漏洞的攻击者,可在目标机器上以 MS-Agent 进程权限执行任意操作系统命令。”
这意味着,AI 被允许执行的所有操作,攻击者均可照做。
攻击者能够窃取敏感文件、修改系统配置、在内网中横向移动,或植入隐蔽后门,以便长期控制目标主机。
研究人员表示:
“厂商在漏洞协同过程中未提供任何说明。用户仅应在可信任、已校验或已净化输入内容的环境中使用 MS-Agent。”
由于暂未发布可彻底修复该问题的软件更新,使用 MS-Agent 的机构必须自行构建防御体系。
安全专家建议,将此类 AI 智能体置于沙箱中运行 —— 仅为 AI 分配完成任务所需的最小权限。
此外,开发者应将脆弱的黑名单(拦截已知恶意行为)替换为严格的白名单(仅允许少数明确许可的操作)。

据阿卡迈(Akamai)安全情报与响应团队(SIRT)近期调查显示,臭名昭著的恶意软件家族 Zerobot 携全新手段卷土重来。
这个最新版本被命名为 Zerobotv9,它不再只瞄准普通家庭网络设备,而是主动攻击企业级工作流自动化系统。
阿卡迈 SIRT 于 2026 年 1 月中旬发现这一轮新型攻击。
攻击者不仅针对常规硬件 —— 具体为 Tenda AC1206 家用路由器,还在利用一款主流企业软件平台 n8n 中的漏洞。
正如阿卡迈报告所指出的,这一攻击目标的转变对企业安全团队是重大警示信号:
“对 n8n 漏洞的攻击尤为值得警惕:僵尸网络通常利用物联网(IoT)设备,如安防摄像头、DVR 和路由器,但 n8n 属于完全不同的攻击范畴。”
黑客拿下家用路由器后,可能仅用其发送垃圾流量。
但一旦控制 n8n 平台,攻击者就有可能横向渗透进入企业最核心的内部网络,窃取 API 密钥 并篡改关键数据。
Tenda 路由器漏洞(CVE-2025-7544)
这是一个远程栈溢出漏洞,影响 Tenda AC1206 设备 15.03.06.23 版本的 /goform/setMacFilterCfg 接口,漏洞评级为严重,可通过 deviceList 参数利用。
n8n 平台漏洞(CVE-2025-68613)
该漏洞源于缺少沙箱隔离机制。
正常情况下,软件会在沙箱中运行,无法触及系统其他部分;
而该漏洞可让攻击者突破沙箱限制,直接在主服务器上执行命令。
tol.sh),以此安装 Zerobot 主要攻击载荷。报告指出:
“威胁行为人 opportunistically 利用近期披露的漏洞在当下十分普遍。即便管理规范、及时补丁的机构,在漏洞公开后也往往存在一段可被攻击的窗口期,而部分企业甚至完全忽略这类设备的补丁更新。”
Zerobot 核心基于 Mirai 恶意代码构建,后者是多年前引发大规模网络瘫痪的著名僵尸网络。
尽管原始作者已落网,但 Mirai 源码在网上完全公开,无论是新手还是资深黑客都能据此开发变种。
阿卡迈研究人员对这类攻击持续泛滥的原因给出结论:
“尽管近期执法部门打掉多个高影响力僵尸网络,但基于 Mirai 的恶意程序仍在不断扩散。因为搭建一套基于 Mirai 的僵尸网络,门槛相当低。”

据 MSN 报道,这项新功能允许 Pixel 9 设备直接向运行 iOS 系统的苹果设备发送文件。
其核心机制基于网页传输体系:安卓设备生成链接或发起直连,iOS 接收方可通过浏览器或轻量客户端接收并下载文件。
这种方式无需苹果在 App Store 审核专用 Quick Share 应用,在苹果对平台长期严格管控的背景下,属于非常巧妙的策略。
该功能在最新一期 Pixel Feature Drop 中被发现,这是谷歌每季度为旗舰手机推送新功能的更新。
目前 Pixel 9 系列首批获得更新,谷歌表示未来数月内将扩展到更多安卓手机。
该功能经过数月测试与用户反馈,谷歌对传输协议进行优化,可稳定支持多种文件类型与大小。
安卓与 iOS 之间无法轻松互传文件,早在 AirDrop 和 Quick Share 出现前就已是用户痛点。
十余年来,跨平台用户只能使用各种替代方案:
给自己发邮件、上传到 Google Drive 或 iCloud、使用蓝牙(传输大文件又慢又不稳定),或是借助 SHAREit、Snapdrop 等第三方应用。
这些方案在速度与便捷性上,都远不如同平台传输工具。
苹果在 2011 年推出 AirDrop,迅速成为 iPhone 最受欢迎的功能之一。
谷歌的回应则来得更晚:2020 年推出 Nearby Share,2024 年与三星相关标准合并后更名为 Quick Share。
但两套系统都属于封闭生态,仅在各自设备内部生效。
全新的 iOS 兼容性从安卓一侧打破了这道壁垒,尽管苹果目前尚未表态会让 AirDrop 反向支持安卓。
谷歌将 Quick Share 扩展到 iOS 并非完全出于公益。
该公司长期将自身定位为比苹果更开放、更互通的选择,而跨平台文件分享进一步强化了这一形象。
同时也具备现实商业意义:
安卓用户与 iPhone 用户交互越顺畅,安卓用户就越不会因为亲友使用苹果而轻易换机。
这一动作也正值两大公司面临更强的监管互通压力。
2024 年 3 月生效的欧盟《数字市场法案》(DMA)已迫使苹果开放多项封闭系统,包括允许第三方应用商店与替代浏览器引擎。
尽管 DMA 并未强制要求跨平台文件分享,但监管环境已让平台开放成为用户与立法者的普遍期待。
iOS 版 Quick Share 与安卓之间的原生传输工作方式并不相同。
在安卓设备上,Quick Share 结合低功耗蓝牙发现设备与 Wi‑Fi Direct 传输文件,可在无互联网情况下高速传输。
而 iOS 版本则依赖网页机制,因为苹果不会向第三方开发者提供原生实现所需的底层蓝牙与 Wi‑Fi 协议权限。
这意味着向 iOS 设备传输的速度可能略慢于安卓互传,且多数情况下需要联网。
但谷歌对流程做了优化,用户体验保持简洁:
发送方在安卓设备选择 Quick Share,选定 iOS 接收方,接收方收到通知或链接即可下载。
早期测试用户反馈显示,传输速度优于邮件附件,远快于蓝牙。
Quick Share 扩展只是更大规模 Pixel 功能更新的一部分。
谷歌还增强了设备端 AI 能力,改进了 Pixel 通话筛查功能,并为 Pixel 9 系列加入新的相机工具。
同时也对 Gemini AI 助手进行升级,可直接在设备端完成更多复杂任务,无需将数据上传云端。
但引发科技媒体与分析师最多讨论的,仍是 Quick Share 跨平台更新。
与 AI 修图、实时翻译相比,文件分享看似普通,却解决了每天影响数百万用户的真实痛点。
据 MSN 报道,该功能是经常与 iPhone 用户交互的 Pixel 用户最期待的功能之一,而这类用户在美国智能手机市场中接近半数。
苹果尚未对谷歌将 Quick Share 扩展到 iOS 发表公开评论。
苹果历来不愿支持竞争对手推出的跨平台分享标准,更倾向于将 AirDrop、iMessage、FaceTime 等功能作为独家生态壁垒。
这种独占性是推动 iPhone 销量的重要因素,尤其在年轻用户群体中,iMessage 蓝色气泡与群体场景下的 AirDrop 便利性具有很强的社交吸引力。
不过苹果近几个月已做出部分让步。
在抗拒多年后,苹果终于在 iOS 18 中支持 RCS 消息标准,改善安卓与 iPhone 之间的富文本消息体验。
外界普遍认为,这是对监管压力与谷歌长期公开宣传的回应。
苹果未来是否会让 AirDrop 兼容安卓设备仍未可知,但趋势表明,两大平台之间的壁垒正在逐步瓦解。
这一变化的影响远不止朋友间随手分享照片。
在企业环境中,员工经常混合使用安卓与 iOS 设备,跨平台文件传输一直是 IT 部门的头疼问题。
企业为此投入大量资源部署移动设备管理与企业文件分享平台,很大一部分原因就是为了解决这一壁垒。
原生内置的解决方案(即便仅支持安卓发往 iOS)也能减少对第三方工具的依赖,简化混合设备团队的工作流程。
对于创意从业者而言,从 Pixel 快速发送高清照片或视频片段到 iPhone 进行编辑或审阅,可大幅简化制作流程。
Pixel 9 的计算摄影能力已获得广泛好评,能直接将文件分享给 iOS 平台的协作方,省去了此前必须上传云端或有线传输的步骤。
谷歌面向 iOS 的 Quick Share 是重要一步,但并非跨平台文件分享的最终形态。
基于网页的传输方式虽可用,但在体验与速度上仍不及原生实现。
想要真正达到与 AirDrop 或安卓互传同等水平,需要苹果向更深层集成开放平台 —— 而在没有监管强制的情况下,苹果目前几乎没有这一倾向。
尽管如此,大方向已经非常明确:
用户越来越希望设备不分品牌、无缝协同。
谷歌与苹果都在监管、市场与用户需求的推动下,走向更高程度的互联互通。
谷歌在这一领域采取了更主动的姿态,而 Quick Share 登陆 iOS 正是这一战略的最新体现。
对于长期被 “手机传文件” 困扰的亿万用户来说,这是一个迟到却值得欢迎的进步。

漏洞核心涉及高级本地过程调用(ALPC)协议。
WER 服务对外开放了一个名为 \WindowsErrorReportingService 的 ALPC 端口,用于与其他进程通信。
根据研究员分析,漏洞具体存在于 SvcElevatedLaunch 方法,对应方法号为 0x0D。
该服务未对调用用户的权限进行任何有效校验。

WerFault.exe。| 操作 | 说明 |
|---|---|
| Create Shared Memory | 创建共享内存块,并在其中写入构造好的恶意命令行 |
| Connect to WER ALPC Port | 本地连接至 Windows 错误报告服务(WER)的 ALPC 端口 |
| Send ALPC Message (Method 0x0D) | 使用方法 0x0D发送 ALPC 消息,携带客户端进程 ID、共享内存句柄及命令行长度 |
| Trigger Command Execution | WER 服务复制句柄,并使用传入的命令行启动 WerFault.exe |
该令牌包含多项高危权限,例如:
SeDebugPrivilege(可调试任意进程)和 SeImpersonatePrivilege(可模拟任意用户)。
该漏洞影响范围极广,包括:
2026 年 1 月之前的所有 Windows 10、Windows 11 版本,
以及运行 Windows Server 2019、Windows Server 2022 的企业服务器环境。

该漏洞可使已认证用户在 Probe 服务器上执行任意系统命令,存在服务器被完全接管的重大风险。
使用 10.0.7 之前版本的机构建议立即安装补丁。
该函数负责网络路由追踪(traceroute)操作,并接收用户可控输入,具体为监控配置中的目标地址(destination)字段。
漏洞根源在于应用对该输入的处理方式:存在风险的代码直接使用 Node.js child_process 模块中的 exec () 函数启动 Shell 命令。
攻击者借此可脱离原本仅执行 traceroute 的正常逻辑,注入并执行恶意命令。
尽管产品设计仅允许用户配置监控端点,但该漏洞可导致任意已认证项目用户(即便权限受限),都能在底层 Probe 服务器上实现完整远程代码执行(RCE)。
example.com; cat /etc/passwd 或 $(恶意命令),即可在执行路由追踪的同时运行注入指令。原文参考: https://v2ex.com/t/1195382
原文参考: https://2libra.com/post/ai-programming/sS2H4De
参考资料: https://forums.developer.nvidia.com/t/pre-installed-ollama-configuration/349480书接上回,国内这方面资料太少了,半吊子英语水平,一边看一边尝试,总结下来就是以下步骤,供大家参考。
参考资料学习了很久,最下面还有很多相关的帖子,基本都看了一遍,有兴趣的可以看看
Ollama 这个就是个玩具,真的要部署最好采用 vLLM 或者 llama.cpp 方式,还有一种 TensorRT-LLM ,英伟达出的部署方式
综合看了下 DGX Spark 采用 llama.cpp 方式部署是最成熟优化最完整的
最近甚至加了一个群,里面全是卖教程的,一位 99,讲的全是一键 openclaw,一键买模型,一键买服务器.
大家看的爽了给个金币,我也赚钱了
一次性安装所有必要的编译工具和开发库:
sudo apt update sudo apt install -y clang cmake libcurl4-openssl-dev libssl-dev build-essential
# 克隆仓库(这个实在不行就手动下载放在相同目录下,因为 git clone 经常失败,git 需要单独设置代理) git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp # 编译(关键:启用 CUDA 和 CURL 支持) cmake -B build -DGGML_CUDA=ON -DGGML_CURL=ON cmake --build build --config Release -j 20
⚠️ 如果编译后运行报 SSL/CURL 相关错误,请清理后重新编译:
复制cd ~/llama.cpp rm -rf build cmake -B build -DGGML_CUDA=ON -DLLAMA_CURL=ON -DLLAMA_OPENSSL=ON cmake --build build --config Release -j 20
cd ~/llama.cpp/build/bin ./llama-server -hf ggml-org/gpt-oss-120b-GGUF \ -fa on -ngl 999 \ --jinja \ --ctx-size 0 \ -b 2048 -ub 2048 \ --no-mmap \ --temp 1.0 \ --top-p 1.0 \ --top-k 0 \ --reasoning-format auto
1. 创建模型目录
mkdir -p ~/models/gpt-oss-120b cd ~/models/gpt-oss-120b
2. 手动下载 GGUF 模型文件
前往以下地址,用浏览器下载分片文件:
https://huggingface.co/bartowski/openai_gpt-oss-120b-GGUF/tree/main/openai_gpt-oss-120b-Q3_K_M
需要下载的文件:
openai_gpt-oss-120b-Q3_K_M-00001-of-00002.ggufopenai_gpt-oss-120b-Q3_K_M-00002-of-00002.gguf将文件放到 ~/models/gpt-oss-120b/ 目录下。
3. 启动服务(方式 B 直接指定分片文件路径)
💡 llama.cpp 新版本支持直接加载分片文件,无需手动合并。
cd ~/llama.cpp/build/bin ./llama-server -m ~/models/gpt-oss-120b/openai_gpt-oss-120b-Q4_K_M-00001-of-00002.gguf \ -fa on -ngl 999 \ --jinja \ --ctx-size 0 \ -b 2048 -ub 2048 \ --no-mmap \ --temp 1.0 \ --top-p 1.0 \ --top-k 0 \ --reasoning-format auto
服务启动后默认监听 http://localhost:8080,执行以下命令测试:
curl -s http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-oss-120b", "messages": [ { "role": "user", "content": "Hello, who are you?" } ], "max_tokens": 100 }'
将以下脚本保存后整体执行,可一键完成配置:
# ===== 请确认你的用户名 ===== # 脚本会自动检测,如果不对请手动修改 USERNAME=$(whoami) HOME_DIR="/home/$USERNAME" echo "正在为用户 $USERNAME 配置 llama.cpp 开机自启动..." # 第一步:创建启动脚本 sudo tee /usr/local/bin/start-llama-server.sh > /dev/null <<EOF #!/bin/bash cd $HOME_DIR $HOME_DIR/llama.cpp/build/bin/llama-server \ -m $HOME_DIR/models/gpt-oss-120b/openai_gpt-oss-120b-Q4_K_M-00001-of-00002.gguf \ -fa on -ngl 999 \ --jinja \ --ctx-size 0 \ -b 2048 -ub 2048 \ --no-mmap \ --temp 1.0 \ --top-p 1.0 \ --top-k 0 \ --reasoning-format auto EOF # 第二步:添加执行权限 sudo chmod +x /usr/local/bin/start-llama-server.sh # 第三步:创建 systemd 服务 sudo tee /etc/systemd/system/llama-server.service > /dev/null <<EOF [Unit] Description=llama.cpp Server for GPT-OSS-120B After=network.target network-online.target Wants=network-online.target [Service] User=$USERNAME Group=$USERNAME ExecStart=/usr/local/bin/start-llama-server.sh Restart=on-failure RestartSec=5 Type=simple TimeoutStopSec=30 KillMode=process [Install] WantedBy=multi-user.target EOF # 第四步:重新加载 systemd 并启用服务 sudo systemctl daemon-reload sudo systemctl enable llama-server.service sudo systemctl start llama-server.service # 第五步:显示状态 echo "==================================" echo "✅ 安装完成!服务状态:" sudo systemctl status llama-server.service --no-pager echo "==================================" echo "📝 常用命令:" echo " 查看日志: sudo journalctl -u llama-server.service -f" echo " 重启服务: sudo systemctl restart llama-server" echo " 停止服务: sudo systemctl stop llama-server" echo "=================================="
| 操作 | 命令 |
|---|---|
| 查看实时日志 | sudo journalctl -u llama-server.service -f |
| 重启服务 | sudo systemctl restart llama-server |
| 停止服务 | sudo systemctl stop llama-server |
| 查看服务状态 | sudo systemctl status llama-server |
📢 转载声明:如需转载本文,请注明原文出处
本次分享嘉宾来自腾讯、OPPO、Datastrato、ScopeDB 等团队,以及 Apache 软件基金会、LF APAC AI & Data 和开源社等知名社区。既有大规模业务实践,也有开源基础设施经验,将从不同角度呈现 AI 数据层的真实挑战与解决思路。 如果你正在搭建 AI 数据架构,这些议题值得现场深聊。 Datastrato 创始人兼 CEO,原 LF AI & Data 基金会董事主席,Apache 软件基金会成员,数据与开源领域专家。曾任全球 500 强企业开源业务总经理、腾讯开源负责人兼大数据研发总监、Cloudera Hadoop 团队负责人等 近期 OpenClaw 🦞 的快速走红,让不少团队开始重新思考 AI Agent 的演进路径。随着 AI Agent 从工具走向系统,数据控制层正在成为新的基础设施问题。OpenClaw 虽仍处于早期阶段,但其设计理念为 AI 原生数据管理提供了重要线索。本分享将以「何时可以用 OpenClaw 进行数据管理」为切入点,讨论 AI Agent 时代数据治理与控制范式的演进。 腾讯云 TBDS 大数据存储团队核心成员,AI 数据湖研发负责人,深耕大数据技术近 10 年,在 Iceberg、Lance 等表格式优化和治理方面有丰富经验 在 AI 场景下,数据湖不仅承载数据,更需要支撑高频迭代与复杂治理需求。张帅将结合腾讯云 TBDS 团队实践,分享在 Iceberg、Lance 等表格式体系下的数据湖元数据与存储治理设计,以及其在真实业务中的应用经验。 OPPO 大数据高级架构师,开源高性能云原生缓存系统 Curvine 项目负责人 随着多模态 AI 应用在手机、影像与智能服务中的不断落地,数据湖需要同时承载图像、日志、向量等多种数据形态,传统架构在元数据统一与访问性能上面临新的挑战。多模态场景的复杂性,也让数据治理与数据访问路径成为系统设计的关键。 Datastrato VP of Engineering, Apache Member, Apache Incubator PMC, Gravitino PMC member,超过 18 年的云计算、大数据和开源项目经验 在多云与 AI 协同场景下,统一元数据平台成为数据治理的重要基础。本议题将介绍 Apache Gravitino 的架构与核心能力,并解析 1.1.0 新特性(包括 Lance 支持与安全增强等),分享其在跨集群与 AI 数据治理中的落地价值;同时还会和大家剧透即将在 3 月中发布的 1.2.0 最新版本内容。 ScopeDB 联合创始人,Apache 软件基金会董事,以及多个顶级开源项目(OpenDAL、ZooKeeper、Flink)的核心成员 云原生技术已经发展十余年,但不少数据平台仍沿用传统架构,将复杂的数据流水线直接搬到云上,未能真正释放弹性计算与对象存储的优势。与此同时,日志、事件流与 AI 对话数据的爆发,使半结构化数据逐渐成为实时分析的核心形态。 📅 时间:2026 年 3 月 7 日(周六)下午 13:00-17:30 期待 3 月 7 日(周六)在深圳与你相见。
最近一年,AI 应用已经渗透到每个业务环节,但瓶颈正在从模型转向数据层:实时分析、上下文理解、多模态处理,如何构建能够真正支撑 AI 场景的数据架构,成为技术团队的共同挑战。线下交流的价值,正是在这里体现。比起刷文章或看视频,更重要的是和一群正在做同样事情的人坐在同一个空间里,聊架构、聊实践、聊解决方案。3 月 7 日,Data for AI Meetup 来到深圳。这不仅是一场技术分享,更是一次在社区与同行之间建立连接的机会。这次我们聊什么

议程亮点
堵俊平|Datastrato
AI Agent 时代的数据控制:从「什么时候我们才可以用 OpenClaw 来做数据管理?」谈起
张帅|腾讯
AI 数据湖元数据和存储治理
David|OPPO
OPPO 多模态数据湖架构实践:统一元数据与高性能访问
本分享将基于 OPPO 的一线实践,介绍多模态数据湖的整体架构设计,以及 Gravitino 与 Curvine 在统一元数据管理与加速数据读写方面的组合应用经验,呈现多模态数据基础设施在真实业务中的落地路径与技术取舍。史少锋|Datastrato
AI 原生元数据平台的能力与实践
tison|ScopeDB
半结构化数据实时分析实践:No-ETL 与按需建模
本分享将结合 ScopeDB 的设计实践,探讨 No-ETL 与按需建模(Schema on the fly)如何简化数据链路、降低数据处理成本,并更好地支撑 AI 与 Agent 场景下的新型数据模型,呈现数据架构在 AI 时代的演进趋势。谁适合参加
活动信息
📍 地点:深圳·深国际华南数字谷 H 栋 4 楼
🎟 报名:免费参加,需通过审核(请完整填写报名信息)👉 扫码或点击报名
https://www.huodongxing.com/event/4850156431800
针对机器人组装行业的MES(制造执行系统)解决方案,结合2025-2026年的最新技术趋势和行业实践,以下是为您整理的深度解析。机器人组装属于典型的离散制造,具有多品种、小批量、高精密、工艺复杂(涉及机加工、电子、软件烧录、总装调试)等特点,因此对MES系统的柔性、追溯性和集成能力要求极高。 低代码/零代码平台: 云边协同架构: 数字孪生 (Digital Twin):
一、核心痛点与解决思路
1、物料管理
传统模式问题:
机器人组装涉及的零部件种类繁多,包括伺服电机、减速机、控制器等关键部件。在传统模式下,主要依赖人工核对物料,极易出现错拿、漏拿或批次混淆的情况。一旦缺料或物料错误,往往导致整条产线停摆,严重影响交付进度。
MES解决方案核心价值:
实施智能防错与齐套检查机制。系统通过条码或RFID技术将实物与BOM(物料清单)深度关联。在上料环节,系统自动校验物料的批次、规格是否与工单匹配,错误即报警;在开工前,系统自动计算并检查齐套率,只有物料齐备且正确才允许投产,从源头杜绝错装漏装,确保产线连续高效运行。
2、生产追溯
传统模式问题:
机器人关键部件(如精密减速器)对质量要求极高,需要进行全生命周期追溯。传统纸质记录或分散的Excel表格导致数据孤岛严重,一旦发生故障,难以快速定位具体的生产批次、装配参数或操作人员,召回和定责成本高昂。
MES解决方案核心价值:
建立一机一码全链路追溯体系。为每一台机器人赋予唯一身份码,自动采集并归档从原材料入库、装配过程关键参数(如扭矩值)、测试报告到最终出货的全流程数据。系统支持正向查询(由部件查整机流向)和反向查询(由整机查所有历史工艺细节),实现秒级精准溯源,满足高端客户及出口合规要求。
3、工艺执行
传统模式问题:
机器人装配工艺复杂,涉及涂胶、高精度拧紧等关键工序。传统模式高度依赖老工人的个人经验,新员工上手慢,且不同班次、不同人员之间的操作差异大,导致产品质量一致性差,隐患多。
MES解决方案核心价值:
推行数字化作业指导书 (ESOP)。工位屏幕实时动态展示当前机型的3D装配图、视频指引及关键注意事项,降低对人员经验的依赖。同时,系统与智能工具(如电动拧紧枪、点胶机)互联,自动采集关键工艺数据,一旦数值超差,系统立即报警甚至自动锁机,强制拦截不合格品流入下道工序,确保工艺严格执行。
4、生产调度
传统模式问题:
机器人行业定制化订单多,插单、急单频繁。传统的人工排程或简单的ERP计划响应速度慢,无法实时感知产线实际负荷,导致在制品(WIP)大量积压,产线平衡率低,交付周期不可控。
MES解决方案核心价值:
引入APS高级排程与柔性调度。基于有限产能约束进行动态排程,能够实时响应插单和急单需求,自动调整生产顺序。通过可视化看板实时监控在制品状态,智能优化产线平衡率,最大化利用产能,显著缩短制造周期(Lead Time)。
5、质量检测
传统模式问题:
测试环节(如老化测试、精度校准)产生的数据分散在各个测试台或纸质记录单上,难以进行统一分析。质量问题往往在出货后甚至客户端才被发现,滞后性强,缺乏预防手段。
MES解决方案核心价值:
实现自动化测试集成 (ATE)。系统自动对接各类测试设备,实时采集电流、振动、精度等关键指标,无纸化自动生成质检报告。利用SPC(统计过程控制)技术对数据进行实时分析,一旦发现趋势异常立即预警,将质量管理从“事后检验”转变为“事前预防”,大幅降低不良率。
二、2026年关键技术趋势
AI与大模型融合:预测性维护:利用AI分析组装设备(如自动拧紧枪、点胶机)的历史数据,预测故障,减少非计划停机。
智能排程:大模型辅助生成最优排程建议,甚至通过自然语言查询生产报表(如“查询上周A型号机器人的一次合格率”)。
视觉质检:集成AI视觉算法,自动检测外观缺陷、标签粘贴位置等。面对机器人产品迭代快的特点,利用低代码平台快速构建或调整业务流程(如新增一种型号的装配流程),无需长时间开发,降低实施成本。边缘计算:在车间侧实时处理高频设备数据(如毫秒级扭矩数据),保证控制响应速度。
云端分析:将汇总数据上传云端,进行跨工厂、跨产品线的大数据分析和管理决策。构建虚拟产线,实时映射物理产线状态,用于仿真优化、远程监控和故障诊断。
三、万界星空机器人组装MES系统核心模块:
基础数据管理:工厂建模、BOM管理、工艺路线、工时定额。
计划管理:工单管理、APS排程、物料需求计划(MRP)联动。
生产管理:工单派发、ESOP电子作业指导、Andon安灯系统、报工管理。
质量管理:IQC/IPQC/OQC管理、SPC统计过程控制、不合格品处理、追溯体系。
设备管理:设备台账、维护保养计划、OEE分析、IoT数据采集。
仓储物流:线边库管理、AGV调度集成、物料拉动(JIT/JIS)。
系统集成:与ERP(SAP/Oracle/用友/金蝶)、PLM、WMS、SCADA等系统无缝对接。
四、主流厂商与选型建议 (2026视角)
针对机器人组装行业的特殊性(快速迭代、混线生产),推荐关注具备低代码敏捷开发能力
1、万界星空科技:
推荐理由:深耕机器人组装领域,拥有扫地机器人、商用清洁机器人等标杆成功案例。
核心优势:
AI + 低代码平台:能够快速响应机器人产品频繁迭代的工艺变更需求。
行业Know-How:预置了针对伺服装配、老化测试、整机追溯的行业模板。
灵活部署:提供开源版与企业定制版,适应不同规模企业的需求。
2、预期收益
实施该MES解决方案后,企业预计可实现:
生产效率提升:15% - 25%
不良品率降低:20% - 30%
追溯效率提升:查询时间从小时级缩短至秒级
库存周转率优化:10% - 20%
五、实施路径建议
现状诊断与规划:梳理现有流程痛点,明确MES建设目标(如:追溯率100%、OEE提升15%)。
蓝图设计:设计详细的业务流程、数据流和系统架构,确定集成接口。
系统开发与配置:基于选定平台进行个性化配置和二次开发。
试点上线:选择一条典型产线或一个车间进行试点,验证功能,磨合流程。
全面推广:分阶段推广至全厂,同步进行数据迁移和历史数据清洗。
持续优化:利用系统数据进行持续改进,引入AI等新技术深化应用。
总结:对于机器人组装企业而言,MES已不再是简单的记录工具,而是实现智能制造、提升核心竞争力的关键中枢。2026年的解决方案更强调AI驱动、柔性敏捷、全链路追溯以及生态集成。企业在选型时,应摒弃“大而全”的盲目追求,转而寻找最契合自身业务特点、具备快速迭代能力的合作伙伴,以应对瞬息万变的市场需求。
访答是一个专注于提供专业问答服务的平台。它通过整合领域专家的知识,为用户提供准确、可靠的解答。与通用问答平台相比,访答更注重回答的质量和权威性。 访答平台在专业问答领域具有明显优势。首先,它严格筛选回答者,确保他们具备相关领域的专业知识。其次,平台采用系统化的内容审核机制,保证信息的准确性和时效性。 用户可以通过简单的注册流程开始使用访答。平台提供直观的界面设计,让用户能够快速找到需要的专业解答。无论是技术问题还是学术疑问,访答都能提供满意的答案。访答:专业问答平台解析
什么是访答
访答的核心优势
如何使用访答

cookie 只需要 A2 和 A20 相关部分,其他的都可以删除
每天八点以后签到,八点之前无法签到。
代理部分根据自己来,如果本地需要用到代理,就更改相关代理设置,如果不需要代理,注释掉就行,
推送部分可以根据自己调整,我用的企微推送的,这是一个简单的签到脚本,要想获取相关签到返回信息可以更改脚本。
使用青龙或者 Linux 定时任务运行即可。
@JoeJoeJoe
#!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys import re import json import time import random import gzip import zlib from io import BytesIO import http.cookiejar import urllib.request import urllib.parse from datetime import datetime # ==================== 配置区域 ==================== # V2EX 认证信息(登录后从浏览器获取) V2EX_COOKIE = '' # 企业微信机器人配置(可选) WECHAT_WEBHOOK_URL = 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的 KEY' # 替换为你的机器人 webhook 地址 # 代理配置(如果需要) PROXY = 'http://10.188.6.97:7890' # HTTP 代理 # PROXY = None # 不使用代理设为 None # ================================================= V2EX_DOMAIN = 'v2ex.com' V2EX_URL_START = 'https://' + V2EX_DOMAIN V2EX_MISSION = V2EX_URL_START + '/mission/daily' def send_wechat_message(content, message_type='markdown'): """发送消息到企业微信机器人""" if WECHAT_WEBHOOK_URL == 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=1111': print("提示:未配置企业微信机器人,跳过推送") return False try: if message_type == 'markdown': data = { "msgtype": "markdown", "markdown": {"content": content} } else: data = { "msgtype": "text", "text": {"content": content} } json_data = json.dumps(data).encode('utf-8') req = urllib.request.Request(WECHAT_WEBHOOK_URL, data=json_data, headers={'Content-Type': 'application/json'}) response = urllib.request.urlopen(req, timeout=10) result = json.loads(response.read().decode('utf-8')) if result.get('errcode') == 0: print("✅ 企业微信消息发送成功") return True else: print(f"❌ 企业微信消息发送失败: {result}") return False except Exception as e: print(f"❌ 发送企业微信消息时发生错误: {e}") return False def format_sign_result(success, message, days=None, coins=None): """格式化签到结果""" current_time = datetime.now().strftime('%Y-%m-%d %H:%M:%S') status_icon = "✅" if success else "❌" status_text = "成功" if success else "失败" md = f"""## V2EX 签到报告 {status_icon} **签到状态**:{status_text} **签到时间**:{current_time} **签到结果**:{message} """ if days: md += f"**连续签到**:{days} 天\n" if coins: md += f"**当前铜币**:{coins}\n" md += f"\n---\n[👉 前往 V2EX]({V2EX_URL_START})" return md def random_delay(min_seconds=1, max_seconds=3): """随机延迟,模拟人类行为""" delay = random.uniform(min_seconds, max_seconds) time.sleep(delay) def decompress_data(data, headers): """解压缩数据""" content_encoding = headers.get('Content-Encoding', '').lower() if not content_encoding: return data try: if content_encoding == 'gzip': buf = BytesIO(data) with gzip.GzipFile(fileobj=buf) as f: return f.read() elif content_encoding == 'deflate': return zlib.decompress(data) elif content_encoding == 'br': # 如果不支持 br,返回原始数据 print("⚠️ Brotli 压缩不支持,返回原始数据") return data else: print(f"⚠️ 未知压缩格式: {content_encoding}") return data except Exception as e: print(f"⚠️ 解压失败 ({content_encoding}): {e}") return data def read_response(response): """读取响应并返回字符串,自动处理压缩""" # 获取响应头 headers = dict(response.getheaders()) data = response.read() # 解压缩数据 data = decompress_data(data, headers) # 尝试多种编码解码 if isinstance(data, bytes): # 尝试常用编码 for encoding in ['utf-8', 'gbk', 'gb2312', 'latin-1']: try: return data.decode(encoding) except UnicodeDecodeError: continue # 如果都不行,使用 ignore 模式 return data.decode('utf-8', errors='ignore') return str(data) def setup_opener(): """设置 opener,包含 cookie 和代理""" # 创建 cookie 处理器 cj = http.cookiejar.CookieJar() # 解析 cookie 字符串 for cookie_item in V2EX_COOKIE.split('; '): if '=' in cookie_item: name, value = cookie_item.split('=', 1) # 清理值中的引号 value = value.strip('"').strip("'") cookie_obj = http.cookiejar.Cookie( version=0, name=name.strip(), value=value, port=None, port_specified=False, domain=V2EX_DOMAIN, domain_specified=True, domain_initial_dot=False, path='/', path_specified=True, secure=False, expires=None, discard=False, comment=None, comment_url=None, rest={'HttpOnly': None}, rfc2109=False ) cj.set_cookie(cookie_obj) # 构建处理器 handlers = [urllib.request.HTTPCookieProcessor(cj)] # 添加代理 if PROXY: proxy_handler = urllib.request.ProxyHandler({ 'http': PROXY, 'https': PROXY }) handlers.append(proxy_handler) # 创建 opener opener = urllib.request.build_opener(*handlers) # 完善请求头,模拟真实浏览器(注意:去掉 Accept-Encoding 避免自动压缩) opener.addheaders = [ ('User-Agent', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'), ('Accept', 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'), ('Accept-Language', 'zh-CN,zh;q=0.9,en;q=0.8'), # 移除 Accept-Encoding,让服务器返回未压缩的内容 # ('Accept-Encoding', 'gzip, deflate'), ('Connection', 'keep-alive'), ('Upgrade-Insecure-Requests', '1'), ('Cache-Control', 'max-age=0'), ('Referer', V2EX_MISSION) ] return opener def extract_once_param(html): """从 HTML 中提取 once 参数""" # 方法 1: 查找签到按钮的 onclick 属性 match = re.search(r"onclick=\"location\.href\s*=\s*'([^']+)'\"", html) if match: return match.group(1) # 方法 2: 直接匹配 URL 模式 match = re.search(r'/mission/daily/redeem\?once=(\d+)', html) if match: return match.group(0) # 方法 3: 查找 input 按钮的值 match = re.search(r'<input[^>]*value="领取[^"]*"[^>]*onclick="[^"]*location\.href\s*=\s*''([^'']+)''"', html) if match: return match.group(1) return None def extract_user_info(html): """提取用户信息(连续天数、铜币等)""" info = {} # 提取连续签到天数 days_match = re.search(r'已连续登录\s*(\d+)\s*天', html) if days_match: info['days'] = days_match.group(1) # 提取铜币信息 coins_match = re.search(r'(\d+)\s*<img src="/static/img/silver@2x\.png"', html) if coins_match: info['coins'] = coins_match.group(1) return info def test_proxy(): """测试代理是否可用""" if not PROXY: print("📡 未使用代理") return True print(f"📡 测试代理: {PROXY}") try: # 创建测试 opener proxy_handler = urllib.request.ProxyHandler({ 'http': PROXY, 'https': PROXY }) opener = urllib.request.build_opener(proxy_handler) opener.addheaders = [('User-Agent', 'Mozilla/5.0')] # 测试访问 test_resp = opener.open('http://httpbin.org/ip', timeout=10) test_data = test_resp.read().decode('utf-8') print(f"✅ 代理工作正常,IP 信息: {test_data}") return True except Exception as e: print(f"❌ 代理测试失败: {e}") return False def save_debug_file(content, filename): """保存调试文件,确保正确编码""" try: with open(filename, 'w', encoding='utf-8') as f: f.write(content) print(f"💾 已保存调试信息到 {filename}") except Exception as e: print(f"⚠️ 保存调试文件失败: {e}") def sign_in(): """执行签到""" if not V2EX_COOKIE or V2EX_COOKIE == 'auth=你的 auth 值': error_msg = "错误:请先设置正确的 V2EX_COOKIE" print(error_msg) send_wechat_message(format_sign_result(False, error_msg)) return False try: print("=" * 50) print("🚀 开始 V2EX 签到...") print("=" * 50) # 测试代理 if PROXY and not test_proxy(): print("⚠️ 代理测试失败,尝试继续执行...") # 设置 opener opener = setup_opener() # 1. 先访问主页 print("\n📄 第 1 步: 访问主页...") random_delay() home_resp = opener.open(V2EX_URL_START, timeout=15) home_html = read_response(home_resp) print(f"✅ 主页访问成功,页面大小: {len(home_html)} 字符") # 2. 访问签到页面 print("\n📄 第 2 步: 访问签到页面...") random_delay() resp = opener.open(V2EX_MISSION, timeout=15) html = read_response(resp) print(f"✅ 签到页面访问成功,页面大小: {len(html)} 字符") # 保存原始 HTML 用于调试 save_debug_file(html, 'v2ex_debug.html') # 检查反爬提示 if '奇奇怪怪的设置' in html: print("⚠️ 检测到反爬提示,尝试继续...") # 检查是否已签到 if '每日登录奖励已领取' in html: msg = "今日已签到" print(f"✅ {msg}") user_info = extract_user_info(html) send_wechat_message(format_sign_result(True, msg, user_info.get('days'), user_info.get('coins'))) return True # 3. 提取 once 参数 print("\n🔍 第 3 步: 提取签到参数...") once_path = extract_once_param(html) if not once_path: msg = "未找到签到参数,可能页面结构已变" print(f"❌ {msg}") send_wechat_message(format_sign_result(False, msg)) return False print(f"✅ 找到签到参数: {once_path}") # 4. 构建签到 URL if once_path.startswith('http'): sign_url = once_path else: sign_url = V2EX_URL_START + once_path print(f"🔗 第 4 步: 签到 URL: {sign_url}") # 5. 执行签到 print("\n🎯 第 5 步: 执行签到...") random_delay(2, 4) # 签到前稍长延迟 sign_resp = opener.open(sign_url, timeout=15) sign_html = read_response(sign_resp) # 保存签到结果 save_debug_file(sign_html, 'v2ex_result.html') # 6. 解析结果 print("\n📊 第 6 步: 解析签到结果...") user_info = extract_user_info(sign_html) success = False message = "" if '每日登录奖励已领取' in sign_html: success = True message = "每日登录奖励已领取" print(f"✅ {message}") elif '你已连续' in sign_html: success = True days_match = re.search(r'你已连续(\d+)天', sign_html) days = days_match.group(1) if days_match else '?' message = f"已连续签到 {days} 天" print(f"✅ {message}") elif '领取' in sign_html and '铜币' in sign_html: success = True message = "签到成功" print(f"✅ {message}") else: # 检查页面中是否包含成功信息 if '已领取' in sign_html or '成功' in sign_html: success = True message = "签到成功" print(f"✅ {message}") else: message = "签到完成,请手动检查结果" print(f"⚠️ {message}") # 7. 推送结果 print("\n📱 第 7 步: 推送签到结果...") push_result = send_wechat_message(format_sign_result(success, message, user_info.get('days'), user_info.get('coins'))) if push_result: print("✅ 结果推送成功") print("\n" + "=" * 50) print(f"🏁 签到{'成功' if success else '完成'}") print("=" * 50) return success except urllib.error.URLError as e: error_msg = f"网络错误: {e.reason}" print(f"\n❌ {error_msg}") if hasattr(e, 'code'): error_msg += f" (HTTP {e.code})" send_wechat_message(format_sign_result(False, error_msg)) return False except Exception as e: error_msg = f"{type(e).__name__}: {e}" print(f"\n❌ 发生错误: {error_msg}") import traceback traceback.print_exc() send_wechat_message(format_sign_result(False, error_msg)) return False if __name__ == '__main__': print("=" * 50) print("V2EX 自动签到脚本 v2.1") print("=" * 50) # 执行签到 success = sign_in() print("\n 脚本执行完毕") sys.exit(0 if success else 1)
因为工作有合规需求,所以只能从国产 AI 中考虑了。
年前看推荐用过 GLM ,试用了一个月,体验还不错。年后回来发现貌似风评急转直下,而且因为放假期间没续费,现在每天早上 10 点开放购买都瞬间清空,根本买不到了……
现在暂时买了 MiniMax M2.5 试用,然后发现好像说营销力度大速度快但是本身也没那么聪明?
所以现在选哪家比较好呢?听说 Kimi 好像又出了个还不错的,然后千问和豆包也有但是好像也没怎么听说人用。
另外阿里云有一个代码方案打包套餐,那个怎么样?