2026年3月

在尝试运动攀登(带绳索),前面四五次都是有人在底下保护,所以绳索时刻拉紧,很有安全感。但不能随时找到同伴做保护,所以最近在尝试顶端自动保护。但是!松手那刻,自动保护不会立刻收紧绳索,会有 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%的广告变现型开发者运营的应用存在儿童隐私或在线安全漏洞。

上述数据意味着,在广告变现模式下,精确位置数据的暴露并非个别现象,而是具有一定规模性。

COPPA 合规与可验证家长同意机制测试结果

在面向儿童的应用领域,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 管理员与隐私倡导组织提供了一个可持续更新的开发者风险视图。对于技术社区而言,其价值在于提供了可量化的指标与样本数据,用以审视当前移动广告生态中的儿童数据处理实践。

最近整理了下这三年的家庭支出,越看越感慨:现在的钱真是越来越不禁花
夫妻二人住在一线城市郊区,整体开支算不上奢侈,基本就是维持日常生活、孩子、住房、贷款这些,结果累计下来还是挺惊人的。

支出类型统计(近三年)

支出类型 支出金额(元) 占比
住房 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%


简单感受(看完数据后的直观体会)

  • 贷款 + 住房 两项合计就占了 **51.32%**(超过一半)
  • 孩子支出10.49%
  • 伙食费8.34%
  • 亲友往来(礼金/人情等)15.70%

这样一算,真正能灵活支配的钱其实并不多。
感觉这几年不是乱花钱,而是生活本身的基础成本就在不断抬高

维持个温饱,真的越来越不容易了……

Intel 在未发布任何公告的情况下,悄然下架了 Clear Linux 的官方网站、下载服务器与社区论坛,将 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 处理器上的实测性能明显快于其他 Linux 发行版,多项基准测试中,Clear Linux 的性能都显著优于 Ubuntu、Fedora 等主流系统。

它在开发者、系统管理员与性能发烧友中积累了大量忠实用户,不仅速度出众,更作为 Intel 架构优化的参考平台 存在。

同时也成为多项前沿软件技术的试验场,包括函数多版本、基于剖面的优化等技术,Intel 希望这些优化最终能在整个 Linux 生态中普及。


本次具体发生了哪些变化

根据 Phoronix 报道:
  • clearlinux.org 不再承载原有内容,直接跳转 GitHub
  • 原有的官方文档站、下载页面、社区论坛均无法通过原网址访问
  • 提供 ISO 镜像与系统更新的官方下载基础设施也已受影响

这并非该项目首次被缩减。

过去几年,Intel 已逐步淡化 Clear Linux 在桌面与工作站场景的定位,转向云与容器场景;同时降低了更新频率,缩减了软件仓库规模。

直接关停官网是更具决定性的一步,几乎让新用户无法再轻松发现、下载与安装该系统。


Intel 全程沉默,引发大量猜测

本次基础设施关停最反常的一点是:

Intel 没有发布任何官方说明 —— 没有博客、没有新闻稿、没有邮件列表与社交平台公告。

这种沉默直接让 Linux 社区普遍猜测:

即便代码仍然公开,Clear Linux 作为面向公众的项目已被逐步放弃

Intel 历史上曾多次推出雄心勃勃的开源项目,又在公司战略转向后悄然退场:

Tizen、MeeGo 等多个软件项目均是如此 —— 初期大力投入,随后随着管理层变动或市场环境变化逐渐撤资。

Clear Linux 如今似乎正在走上同一条老路。


大背景:Intel 正在全面削减成本

Clear Linux 基础设施被关停,恰逢 Intel 面临巨大财务压力。

在现任管理层主导下,公司正在推行大范围成本削减计划:裁员数千人,砍掉所有与核心半导体制造、设计业务无关的部门开支。

那些无法直接创收、或对硬件销售无关键支撑作用的软件项目,自然成为预算削减目标。

Intel 的晶圆厂战略、在数据中心与消费端市场与 AMD 和 Arm 的竞争、以及争取政府芯片补贴等事务,已占用大量管理精力与资金。

在这种环境下,维护一套完整 Linux 发行版所需的独立网站、文档团队、社区运营等成本,被认为难以持续


对现有用户与生产环境的影响

对于已在生产环境或日常使用 Clear 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 社区留下了实实在在的价值。

Clear Linux 团队开创的大量性能优化已上游合入 Linux 内核、GCC、系统库等核心项目。

该发行版用事实证明:

通过精细编译与系统配置,可实现大幅性能提升 —— 这一思路后来被众多发行版借鉴。

Intel 在 Clear Linux 上的实践还影响了容器优化系统设计,并推动了无状态系统、自动更新、开源遥测等领域的讨论。

这些思想已被 Fedora CoreOS、Ubuntu Core 等云原生 Linux 项目采纳。


悬而未决的问题:Clear Linux 真的 “死” 了吗?

目前,Intel 外部无人能给出确切答案。

代码仍在 GitHub 上,可能意味着项目仍在内部继续 —— 仅作为 Intel 工程师的参考平台或优化试验场,不再需要公共官网。

但也可能只是还没来得及归档仓库而已。

可以确定的是:

作为一套拥有完整公共基础设施与社区支持的 Linux 发行版,Clear Linux 已被严重削弱。

clearlinux.org 的消失不只是界面改动,而是项目失去了对外的主要窗口

没有下载页、没有文档、没有论坛,Clear Linux 对不熟悉它的人来说几乎等于 “不存在”,只能从源码手动编译。

对 Intel 而言,悄悄关停 Clear Linux 公共服务只是庞大企业重组中的一个小注脚。

对开源社区而言,这是一次清醒的提醒:

依赖企业赞助的开源项目,随时可能因商业战略变化而被缩减甚至放弃。

而对于那些打造 Clear Linux、不断突破 Linux 性能边界的开发者来说,他们的工作成果已留在上游社区 —— 即便那个曾经展示这些成果的发行版,或许已时日无多。

一场大规模恶意广告攻击正针对 macOS 用户展开:攻击者利用伪造的谷歌广告,将用户导向恶意文本分享网站,并投放名为 malextAMOS 窃密木马变种,窃取浏览器凭证、加密货币钱包等敏感数据。

可疑的密码输入弹窗暴露了此次攻击,关联到的初始域名包括:

optimize-storage-mac-os.medium.comoctopox.comvagturk.com

谷歌广告库显示,超过 34 条广告伪装成 Medium 文章进行诱骗,攻击者在账号被封后会迅速更换新账号。

分析发现至少 53 个被入侵的广告账号,其中甚至有账号同时推广邮轮广告与虚假 macOS 修复工具。

类似恶意广告还出现在 Evernote、mssg.me、kimi.com 等平台。

安全研究者 @itspappy 与 Gi7w0rm 在一次险些中招的事件后揭露了该攻击链:

一名用户搜索 macOS 存储修复工具时,点击了谷歌置顶结果,进入一篇伪造的 Medium 文章,其中包含恶意 Shell 命令。

诱饵页面高度模仿 macOS 故障排查指南或软件安装教程,标题类似 “此方法可修复 X 问题”,并诱导用户复制粘贴终端命令。
攻击链使用 Base64 混淆的 curl 命令逐级下载载荷,并通过 xattr -c 移除隔离属性,绕过 Gatekeeper 防护

部分攻击链会通过循环弹窗骗取管理员密码,将密码保存在 ~/.pass,供后续提权使用。

这种社会工程学手段可在无系统告警的情况下提升载荷执行成功率。


攻击链分析

攻击者下载的是同时支持 x86_64 与 ARM 架构的 Mach‑O 二进制文件。

样本通过混淆的 AppleScript 执行虚拟机 / 沙箱检测,使用 system_profiler 判断 QEMU/VMware 环境或异常硬件特征。

在 VirusTotal 运行的已修补样本中,暴露出一段超过 59000 字符osascript 载荷。

去混淆后可见代码使用凯撒密码加密字符串与随机变量名。

脚本会隐藏终端窗口,收集系统信息,并通过 malext.com38.244.158.56 外发数据。

malext 作为 AMOS 变种,窃取范围极广:
  • Apple Notes 数据库
  • Safari Cookie
  • 桌面 / 文档目录文件(txt/pdf/docx/wallet,上限 30MB)
  • OpenVPN 配置文件
  • Telegram 数据
  • 已安装应用列表

该恶意软件的特殊之处在于:

单个 Mach‑O 文件内同时打包了两种不同 CPU 架构的攻击载荷

malext 作为 AMOS 变种,窃取范围极广:
  • Apple Notes 数据库
  • Safari Cookie
  • 桌面 / 文档目录文件(txt/pdf/docx/wallet,上限 30MB)
  • OpenVPN 配置文件
  • Telegram 数据
  • 已安装应用列表

该恶意软件的特殊之处在于:

单个 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 年底开始活跃,依靠大量廉价一次性账号扩张,疑似由流量团伙运营。

网络威胁分子正在大规模部署一款名为 AuraStealer 的新型信息窃密木马。该木马拥有不断扩大的客户群体、48 个已确认的 C2 命令控制域名,并通过 TikTok、破解软件网站等流行平台发起多轮攻击活动。
AuraStealer 于 2025 年年中出现在俄语系网络犯罪论坛,在 LummaC2 遭打掉后,迅速成为其继任者与竞争对手。
该恶意软件以订阅制出售,分为基础版与高级版,由名为 AuraCorp 的团队宣传推广。团队宣称拥有 5–11 年安全相关经验,并具备专业化开发流程。
研究人员指出,尽管早期版本成熟度不及 Rhadamantys、Vidar 等老牌窃密木马,但开发速度极快,功能更新频繁
根据相关论坛帖子与信息,AuraStealer 开发者称已快速吸引大批从 Lumma、StealC、Vidar、Rhadamantys 迁移而来的客户,显示其在黑产生态中扩散速度极快
在本次报告中(2026 年 1 月已同步给客户),Intrinsec 威胁情报团队提供了高价值、可落地的上下文情报,帮助机构理解并防御此类网络威胁。
该项目的后续路线图还包括加入代码虚拟化保护,大幅提升逆向分析难度。

AuraStealer 信息窃密木马概况

分析师已梳理出 48 个 AuraStealer C2 域名,其中大量使用廉价且易滥用的 .SHOP.CFD 顶级域。

这些域名包括:

auracorp.cfdmscloud.cfdmagicupdate.cfdgamedb.shopbrowsertools.shopclocktok.cfd 等。

它们均通过 Cloudflare 代理隐藏真实后端服务器。

每个域名使用独立的 Cloudflare 源站证书,但全部指向同一套后端架构,疑似为单台服务器,运行的组件版本均已过时:

Apache 2.2.22、PHP 5.4.45、CodeIgniter 3.1.11、Symfony 3.4.26。

研究人员通过关联恶意软件配置、HTTP 头与全网测绘引擎,发现了与特定版本对应的域名集群。
早期版本(1.0.x–1.2.x)主要使用 .SHOP 域名,而最新的 1.5.2 样本更倾向使用 .CFD,表明攻击者正在逐步将基础设施从 .SHOP 切换到 .CFD
LuxHost 与 Nicenic 作为部分域名的注册商或 DNS 服务商,进一步证明这些域名集群由同一团伙控制。
在从 VirusTotal 超过 200 个 AuraStealer 样本配置中提取出的 21 个 C2 域名的历史截图里,均出现了相同的登录页面。

AuraStealer 传播方式

AuraStealer 攻击活动采用灵活的投递链,结合社会工程学与通用加载器分发。

其中一个主要传播渠道是 TikTok 上的 ClickFix 骗局

短视频声称可免费激活 Windows、Microsoft 365、Adobe 系列、Netflix、Spotify 等,并诱导受害者以管理员权限执行一行 PowerShell 命令。

该命令会下载并执行远程 PowerShell 脚本,最终释放 AuraStealer 载荷,例如从 file-epq.pages.dev/updater.exe 下载。
除 TikTok 外,AuraStealer 还通过自解压压缩包、假冒系统清理工具(如 Gcleaner)、通用加载器传播,并将自身注入合法 Windows 进程,如 regasm.exeSndVol.exe

多轮攻击活动使用 Donut shellcode 加载器Soulbind 加载器,从攻击者控制的服务器下载 AuraStealer,例如:

94.154.35.115、130.12.180.43。

这些主机还分发 Stealc、Rhadamanthys、Vidar、SalatStealer、NJRAT 等多种远控与窃密木马。

强悍的反分析与对抗机制

AuraStealer 运营者通过 auracorp.cfd 的 Web 管理面板控制感染终端,支持数据面板、载荷生成、日志筛选、Telegram 机器人报警等功能。
其登录流程内置 JavaScript 工作量证明(PoW) 机制,强制浏览器计算前 16 位为 0 的 SHA‑256 哈希才能提交表单,可抵御绝大多数自动化扫描器、简单脚本与暴力破解。
管理面板代码中出现俄语字符串,进一步指向俄语系攻击者。

在终端侧,1.5.2 版本采用高强度混淆与反分析技术:

间接控制流、异常驱动 API 哈希、XOR 加密字符串、虚拟机与沙箱检测、调试器检测、完整性校验,甚至在检测到钩子或断点时触发隐藏栈破坏

该窃密木马会对部分独联体地区实施地理定位放行,显示出明确的地域投放策略。

数据窃取能力

通过自检后,AuraStealer 可从 100 多款浏览器、70 多款应用中窃取凭证与敏感数据,包括:

加密货币钱包、两步验证工具、VPN 客户端、密码管理器、远程控制软件等。

所有数据通过 AES‑CBC 加密的 HTTPS 传输到轮替 C2 服务器的三个专用接口:apiliveapiconfapisend

凭借不断扩充的功能、持续扩张的基础设施与活跃的攻击活动,AuraStealer 正从一款新兴窃密木马快速成长为高风险凭证窃取威胁,已成为安全防御方必须重点监控的目标。

谷歌浏览器 Gemini Live 集成组件中发现一处高危漏洞,编号为 CVE-2026-0628,该漏洞将用户置于严重的隐私与安全风险之下。
研究人员发现,该漏洞可被恶意浏览器扩展利用,从而劫持 Gemini 侧边栏,实现对用户摄像头、麦克风及本地文件的未授权访问
将 AI 助手集成进网页浏览器,形成所谓的智能代理浏览器,从根本上改变了浏览器的安全格局。
Chrome 中的 Gemini Live 等功能,需要对浏览器环境拥有深层高权限访问,才能完成实时内容总结、自动化执行等任务。
CVE ID 严重级别 受影响组件 利用机制 影响 状态
CVE-2026-0628 高危 Google Chrome Gemini Live 面板 基于 declarativeNetRequests API 注入 JavaScript 未授权访问摄像头、麦克风、文件及屏幕截图 已修复(2026 年 1 月)
AI 能够 “看见用户所见” 的这种多模态能力,显著扩大了攻击面
这类 AI 组件本身具备高权限,意味着其中的漏洞可绕过传统浏览器安全模型

针对 Gemini 面板的利用方式

Palo Alto Networks Unit 42 研究人员指出,CVE-2026-0628 的核心问题在于:Chrome 在侧边栏中加载 Gemini Web 应用(https://gemini.google.com/app)与在普通标签页加载时,采用的安全处理机制不同。
按照设计,使用 declarativeNetRequests API 的浏览器扩展可以拦截并修改 HTTPS 请求,广告拦截工具普遍使用该能力。
在普通标签页的 Gemini 应用中注入 JavaScript 并不会获得特殊权限,但在 Gemini 面板中注入则极为危险。
为支持复杂的 AI 任务,Chrome 为该面板赋予了更高权限,例如读取本地文件、访问多媒体设备等。
攻击者通过在面板中劫持应用,即可窃取这些高权限

潜在影响与缓解措施

成功利用该漏洞后,攻击者可在 Gemini 面板的高权限环境内执行任意代码,可能导致严重后果:
  • 未经用户同意开启摄像头与麦克风
  • 访问操作系统中的本地文件与目录
  • 对任意 HTTPS 网站截取屏幕
  • 借助可被信任的 Gemini 面板界面实施高隐蔽钓鱼攻击
上述行为仅需极低的用户交互即可完成,用户只需打开 Gemini 面板就可能被利用。
Unit 42 已于 2025 年 10 月向谷歌进行了合规漏洞上报,官方在 2026 年 1 月初发布了修复补丁。
该事件凸显了 AI 与浏览器集成带来的全新安全挑战,也说明随着这类技术发展,持续安全监控至关重要。

就在 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 也明确强调,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 平台本质上是一个数字中间件,企业使用它无缝对接内部数据库、云服务与日常应用系统。

正如阿卡迈报告所指出的,这一攻击目标的转变对企业安全团队是重大警示信号

“对 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 的僵尸网络,门槛相当低。”

 

谷歌的Quick Share现已支持从 Pixel 9 向 iOS 设备传输文件,填补了安卓与 iPhone 之间长期存在的功能空白。这项基于网页的功能绕开了苹果的限制,也反映出跨平台互通的压力正在持续加大。
多年来,移动设备使用中一个一直让人头疼的问题,就是从安卓手机向 iPhone 发送文件。苹果的 AirDrop 让 iPhone 之间分享变得极为简便,谷歌的 Nearby Share(现已更名为 Quick Share)也能实现安卓设备间的传输,但两大平台之间的鸿沟却始终难以弥合。如今,这道壁垒正在被打破。
谷歌已开始面向 iOS 推送 Quick Share 支持,Pixel 9 用户(不久后将扩展到其他安卓设备用户)可直接将照片、视频和文件发送到 iPhone 与 iPad,无需依赖邮件、即时通讯应用或第三方云服务。该功能随 Pixel 大范围软件更新一同推出,是谷歌近年来最具实用价值的跨平台改进之一。

iOS 版 Quick Share 实际工作原理

据 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 接收方,接收方收到通知或链接即可下载。

早期测试用户反馈显示,传输速度优于邮件附件,远快于蓝牙


本次 Pixel 功能更新除文件分享外还包含哪些内容

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 正是这一战略的最新体现。

对于长期被 “手机传文件” 困扰的亿万用户来说,这是一个迟到却值得欢迎的进步

随着概念验证(PoC)利用代码公开,微软 Windows 系统中一处关键本地权限提升(LPE)漏洞随之曝光。
该漏洞编号为 CVE-2026-20817,存在于 Windows 错误报告服务(WER) 内部。
此漏洞可让低权限已认证用户执行任意恶意代码,并获取完整 SYSTEM 系统权限
安全研究员 @oxfemale(X/Twitter 账号 @bytecodevm)已在 GitHub 上发布了详细研究内容及配套 C++ PoC 利用代码
此次公开暴露出 Windows 面向进程间通信的错误报告机制中存在重大安全隐患

漏洞核心涉及高级本地过程调用(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
由于 WER 服务以高权限运行,新建进程会继承 SYSTEM 令牌

该令牌包含多项高危权限,例如:

SeDebugPrivilege(可调试任意进程)和 SeImpersonatePrivilege(可模拟任意用户)。

尽管该令牌不包含操作系统核心级别的 SeTcbPrivilege,但获取到的权限已足以实现对系统的完全控制

该漏洞影响范围极广,包括:

2026 年 1 月之前的所有 Windows 10、Windows 11 版本,

以及运行 Windows Server 2019、Windows Server 2022 的企业服务器环境。

微软已在2026 年 1 月安全更新中正式修复此漏洞。
鉴于 GitHub 已公开 PoC,强烈建议企业与系统管理员立即安装最新安全补丁,保障网络安全。
安全团队还应监控环境中是否出现异常的 WerFault.exe 子进程不规范的 SYSTEM 令牌行为,以发现潜在的漏洞利用行为。

在线服务监控与管理平台 OneUptime 被曝出一处高危命令注入漏洞,编号为 CVE-2026-27728

该漏洞可使已认证用户在 Probe 服务器上执行任意系统命令,存在服务器被完全接管的重大风险。

使用 10.0.7 之前版本的机构建议立即安装补丁。

命令注入漏洞详情

网络安全厂商 SentinelOne 通报,该漏洞存在于 OneUptime Probe Server 组件中的 NetworkPathMonitor.performTraceroute () 函数

该函数负责网络路由追踪(traceroute)操作,并接收用户可控输入,具体为监控配置中的目标地址(destination)字段

漏洞根源在于应用对该输入的处理方式:存在风险的代码直接使用 Node.js child_process 模块中的 exec () 函数启动 Shell 命令

由于 exec () 会在 Shell 环境中执行命令,可被;、|、&、$()、反引号等 Shell 元字符解析利用

攻击者借此可脱离原本仅执行 traceroute 的正常逻辑,注入并执行恶意命令

尽管产品设计仅允许用户配置监控端点,但该漏洞可导致任意已认证项目用户(即便权限受限),都能在底层 Probe 服务器上实现完整远程代码执行(RCE)

利用该漏洞仅需项目用户级别的低权限认证
攻击者可构造恶意监控配置,在目标地址字段中填入 Shell 元字符拼接任意命令
例如注入 example.com; cat /etc/passwd$(恶意命令),即可在执行路由追踪的同时运行注入指令。
Probe 服务器处理该监控任务时,注入命令将以与 Probe 服务进程相同的权限运行
这会直接导致服务器被完全攻陷,攻击者可窃取敏感数据,并在机构内网中进行横向移动。
OneUptime 已在 10.0.7 版本中修复该问题。安全补丁将存在风险的 exec () 替换为 execFile ()
与 exec () 不同,execFile () 会直接执行指定文件,并以数组形式传递参数,不会启动 Shell 环境
此举可阻止 Shell 元字符被解析,从根源上消除命令注入攻击面

缓解与防护建议

为防范 CVE-2026-27728 漏洞,机构可采取以下措施:
  • 立即升级:将 OneUptime 更新至 10.0.7 及以上版本,启用安全的 execFile () 函数并开启目标地址校验。
  • 配置审计:检查现有监控配置,排查目标地址中是否存在包含特殊字符的可疑值。
  • 系统监控:关注 Probe 服务器上异常进程创建、非预期网络连接、未授权文件系统修改等行为。
  • 临时规避:若无法立即升级,可隔离 Probe 服务器、仅向可信人员开放项目用户权限,并严格限制服务器网络访问。

DGX Spark 使用 llama.cpp 部署 GPT-OSS-120B 模型

原文参考: 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,一键买模型,一键买服务器.
大家看的爽了给个金币,我也赚钱了


📋 前置准备

  1. 需要魔法(网络代理)
  2. 安装 Node.js(可通过 nvm 安装,选择最新 LTS 版本即可),后续安装龙虾 openclaw,顺带准备好


一、安装系统依赖

一次性安装所有必要的编译工具和开发库:

复制
sudo apt update
sudo apt install -y clang cmake libcurl4-openssl-dev libssl-dev build-essential


二、克隆并编译 llama.cpp

复制
# 克隆仓库(这个实在不行就手动下载放在相同目录下,因为 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


三、启动服务(推荐 B 方式)

方式 A:自动从 Hugging Face 下载模型(没成功过,不是代理的问题,是文件压根找不到,基本给的例子都是找不到返回 404)

复制
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

方式 B:手动下载模型后加载

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.gguf
  • openai_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
  }'


五、配置开机自启动(systemd)

将以下脚本保存后整体执行,可一键完成配置:

复制
# ===== 请确认你的用户名 =====
# 脚本会自动检测,如果不对请手动修改
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


📢 转载声明:如需转载本文,请注明原文出处

af4adece7156acc0e6e8a479823d09cd.jpg
最近一年,AI 应用已经渗透到每个业务环节,但瓶颈正在从模型转向数据层:实时分析、上下文理解、多模态处理,如何构建能够真正支撑 AI 场景的数据架构,成为技术团队的共同挑战。线下交流的价值,正是在这里体现。比起刷文章或看视频,更重要的是和一群正在做同样事情的人坐在同一个空间里,聊架构、聊实践、聊解决方案。3 月 7 日,Data for AI Meetup 来到深圳。这不仅是一场技术分享,更是一次在社区与同行之间建立连接的机会。

这次我们聊什么

  • 本次 Meetup 围绕 AI 时代的数据基础设施,从不同视角展开:
  • 数据湖元数据与治理如何支撑 AI 场景
  • 多模态数据湖在真实业务中的架构实践
  • 云原生数据平台的设计演进
  • 半结构化数据与 No-ETL 实时分析解法
  • 开源、AI 和 Data 技术社区生态的趋势和共建

本次分享嘉宾来自腾讯、OPPO、Datastrato、ScopeDB 等团队,以及 Apache 软件基金会、LF APAC AI & Data 和开源社等知名社区。既有大规模业务实践,也有开源基础设施经验,将从不同角度呈现 AI 数据层的真实挑战与解决思路。

如果你正在搭建 AI 数据架构,这些议题值得现场深聊。
ef4d33c3417f4802f0d97e6824d18a68.jpg

议程亮点

堵俊平|Datastrato

Datastrato 创始人兼 CEO,原 LF AI & Data 基金会董事主席,Apache 软件基金会成员,数据与开源领域专家。曾任全球 500 强企业开源业务总经理、腾讯开源负责人兼大数据研发总监、Cloudera Hadoop 团队负责人等

AI Agent 时代的数据控制:从「什么时候我们才可以用 OpenClaw 来做数据管理?」谈起

近期 OpenClaw 🦞 的快速走红,让不少团队开始重新思考 AI Agent 的演进路径。随着 AI Agent 从工具走向系统,数据控制层正在成为新的基础设施问题。OpenClaw 虽仍处于早期阶段,但其设计理念为 AI 原生数据管理提供了重要线索。本分享将以「何时可以用 OpenClaw 进行数据管理」为切入点,讨论 AI Agent 时代数据治理与控制范式的演进。


张帅|腾讯

腾讯云 TBDS 大数据存储团队核心成员,AI 数据湖研发负责人,深耕大数据技术近 10 年,在 Iceberg、Lance 等表格式优化和治理方面有丰富经验

AI 数据湖元数据和存储治理

在 AI 场景下,数据湖不仅承载数据,更需要支撑高频迭代与复杂治理需求。张帅将结合腾讯云 TBDS 团队实践,分享在 Iceberg、Lance 等表格式体系下的数据湖元数据与存储治理设计,以及其在真实业务中的应用经验。


David|OPPO

OPPO 大数据高级架构师,开源高性能云原生缓存系统 Curvine 项目负责人

OPPO 多模态数据湖架构实践:统一元数据与高性能访问

随着多模态 AI 应用在手机、影像与智能服务中的不断落地,数据湖需要同时承载图像、日志、向量等多种数据形态,传统架构在元数据统一与访问性能上面临新的挑战。多模态场景的复杂性,也让数据治理与数据访问路径成为系统设计的关键。
本分享将基于 OPPO 的一线实践,介绍多模态数据湖的整体架构设计,以及 Gravitino 与 Curvine 在统一元数据管理与加速数据读写方面的组合应用经验,呈现多模态数据基础设施在真实业务中的落地路径与技术取舍。


史少锋|Datastrato

Datastrato VP of Engineering, Apache Member, Apache Incubator PMC, Gravitino PMC member,超过 18 年的云计算、大数据和开源项目经验

AI 原生元数据平台的能力与实践

在多云与 AI 协同场景下,统一元数据平台成为数据治理的重要基础。本议题将介绍 Apache Gravitino 的架构与核心能力,并解析 1.1.0 新特性(包括 Lance 支持与安全增强等),分享其在跨集群与 AI 数据治理中的落地价值;同时还会和大家剧透即将在 3 月中发布的 1.2.0 最新版本内容。


tison|ScopeDB

ScopeDB 联合创始人,Apache 软件基金会董事,以及多个顶级开源项目(OpenDAL、ZooKeeper、Flink)的核心成员

半结构化数据实时分析实践:No-ETL 与按需建模

云原生技术已经发展十余年,但不少数据平台仍沿用传统架构,将复杂的数据流水线直接搬到云上,未能真正释放弹性计算与对象存储的优势。与此同时,日志、事件流与 AI 对话数据的爆发,使半结构化数据逐渐成为实时分析的核心形态。
本分享将结合 ScopeDB 的设计实践,探讨 No-ETL 与按需建模(Schema on the fly)如何简化数据链路、降低数据处理成本,并更好地支撑 AI 与 Agent 场景下的新型数据模型,呈现数据架构在 AI 时代的演进趋势。


谁适合参加

  • 正在搭建或优化 AI 数据基础设施的架构师和工程师
  • 关注数据湖、元数据管理、多模态数据处理的技术负责人
  • 希望了解开源数据项目(Iceberg、Gravitino、Lance 等)实践经验的开发者
  • 对 AI Agent、云原生数据架构感兴趣的从业者

活动信息

📅 时间:2026 年 3 月 7 日(周六)下午 13:00-17:30
📍 地点:深圳·深国际华南数字谷 H 栋 4 楼
🎟 报名:免费参加,需通过审核(请完整填写报名信息)👉 扫码或点击报名
https://www.huodongxing.com/event/4850156431800
8448d2ffab97d17349ecb9d36d18d05b.png


期待 3 月 7 日(周六)在深圳与你相见。

针对机器人组装行业的MES(制造执行系统)解决方案,结合2025-2026年的最新技术趋势和行业实践,以下是为您整理的深度解析。机器人组装属于典型的离散制造,具有多品种、小批量、高精密、工艺复杂(涉及机加工、电子、软件烧录、总装调试)等特点,因此对MES系统的柔性、追溯性和集成能力要求极高。
一、核心痛点与解决思路
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视觉算法,自动检测外观缺陷、标签粘贴位置等。

低代码/零代码平台:

面对机器人产品迭代快的特点,利用低代码平台快速构建或调整业务流程(如新增一种型号的装配流程),无需长时间开发,降低实施成本。

云边协同架构:

边缘计算:在车间侧实时处理高频设备数据(如毫秒级扭矩数据),保证控制响应速度。
云端分析:将汇总数据上传云端,进行跨工厂、跨产品线的大数据分析和管理决策。

数字孪生 (Digital Twin):

构建虚拟产线,实时映射物理产线状态,用于仿真优化、远程监控和故障诊断。


三、万界星空机器人组装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驱动、柔性敏捷、全链路追溯以及生态集成。企业在选型时,应摒弃“大而全”的盲目追求,转而寻找最契合自身业务特点、具备快速迭代能力的合作伙伴,以应对瞬息万变的市场需求。

访答:专业问答平台解析

什么是访答

访答是一个专注于提供专业问答服务的平台。它通过整合领域专家的知识,为用户提供准确、可靠的解答。与通用问答平台相比,访答更注重回答的质量和权威性。

访答的核心优势

访答平台在专业问答领域具有明显优势。首先,它严格筛选回答者,确保他们具备相关领域的专业知识。其次,平台采用系统化的内容审核机制,保证信息的准确性和时效性。

如何使用访答

用户可以通过简单的注册流程开始使用访答。平台提供直观的界面设计,让用户能够快速找到需要的专业解答。无论是技术问题还是学术疑问,访答都能提供满意的答案。

1. 从办公室拿去卫生间掉帧,疑似从 wifi 切到流量掉帧
2. 早上出门放口袋,全程骑车不用手机,到公司从口袋拿出去掉帧
3. 不知道用了哪个 app ,掉帧

26.1&26.2 一天最夸张能掉 5+次
26.3 是目前用下表现最好的,刚才去卫生间又掉了,虽然锁屏再开好了。
掉帧真的很恶心啊,电池优化关了,待机显示也关了。

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 好像又出了个还不错的,然后千问和豆包也有但是好像也没怎么听说人用。

另外阿里云有一个代码方案打包套餐,那个怎么样?