语言模型是如何进行预测下一个词的？

简单来说，语言模型是通过根据当前给出句子，结合语境进行计算下一个词出现的概率分布，然后从中选择一个作为输出结果

比如：

输入: Jide was hungry so she went looking for...

可能的预测结果: food(0.75) snacks(0.2) leftovers(0.05)

最终大概率输出: Jide was hungry so she went looking for food

为什么采用概率进行预测？

• 采用概率的方式进行随机采样，可以改善内容生成的多样性，在大部分场景下，我们更希望同样的输出可以有不同的输出
• 模型有时可能会出错，采用概率的方式，可以通过执行多次生成，来得到一个更加合理的结果
• 尽管使用了概率，但仍然可以进行确定性的结果输出，可以通过每次都获取概率最大的词汇的方式(贪心)，来确保每次输入都可以得到同样的输出结果

N-grams 模型

概述

N-grams 模型简单来说就是先统计一个词在与其他词进行组合的概率，也就是它们一起出现的概率，然后在给定的一个句子去生成完整的一段话时，就是基于前面进行统计计算的概率进行预测；

比如说，你经常会见到"这座山很高"的描述，但你很少见到"这座山很早上"的描述，那么在给定"这座山"这个上下文去生成完整的一段话时，预测得到"很高"接在后面的概率就比"早上"要高

统计公式

N-grams 模型的统计方式就是一个简单的条件概率公式

比如：

$$
P( 水秀 | 山清 )
$$

表示在"山清"一词在前面出现的前提下,"水秀"一词它一起组合的概率

这个概率的计算结果根据条件概率公式

$$
P(B|A) = \\frac{Count(A B)}{Count(A)}
$$

得到:

$$
P( 水秀 | 山清 ) = \\frac{Count(山清水秀)}{Count(山清)}
$$

其中Count(山清水秀)表示在文本集中"山清水秀"出现的次数,Count(山清)就是在文本集中出现的次数,P( 水秀 | 山清 )就是相对于其它词与"山清"进行组合出现的概率(在文本集中不只是"水秀"和"山清"一起组合出现)

N 词统计

N-grams 中的"N"表示一个预测上下文窗口大小(由几个字组合)

当

• N=1 时,就只是统计单独一个词出现的概率, 比如"桂林山水甲天下",就将拆成"桂","林","山","水","甲","天","下"去进行统计
• N=2 时,统计连续两个字出现的概率,"桂林山水甲天下",将拆成"桂林","林山","山水","水甲","甲天","天下"
• N=3 时,统计连续三个字出现的概率,"桂林山水甲天下",将拆成"桂林山","山水甲","甲天下"去进行统计

现在换个例子,我们假设"白云山"在文本集中出现了600次,"白云"在文本集中出现了900次,而"白云下"只出现了10次,那么

"白云"和"山"一起出现的概率是

$$
P(山|白云) = \\frac{Count(白云山)}{Count(白云)} = \\frac{600}{900} = 0.66
$$

而"白云"和"下"一起出现的概率是

$$
P(下|白云) = \\frac{Count(白云下)}{Count(白云)} = \\frac{10}{900} = 0.011
$$

当在给定"白云"时,预测下一个出现的词相比于"下","山"的出现概率会更高,即输出"白云山"的概率将远大于"白云下"

图例


N-grams 模型的局限性

1. 能力受语料库大小限制
2. 无法处理数据集中从未出现过的词汇预测
3. 因为能力受预料库大小限制,所以很容易出现高重复度的内容输出,生成不够多样
4. 缺乏上下文意识,N-grams只考虑句子的最后 n - 1 个词,忽略了长距离文本的依赖关系,生成的内容可能出现描述前后不一致的情况

Transformer 模型

相比于 N-grams 模型, Transformer 模型生成的内容比前者更流利、上下文更相关的原因主要是以下两方面:

1. Transformer 模型有更大的上下文窗口
2. Transformer 模型基于能够学习复杂和抽象内容的神经网络

训练一个模型的过程

机器训练简单过程描述

1. 预测 ：模型观察一串单词（ 输入 ），并尝试预测下一个标记（ 目标 ）
2. 比较 ：然后将预测结果与实际进行比较。模型预测与目标之间的差异将记录成一个 Loss 值 。高 Loss 值表示模型猜测错误，低 Loss 值表示猜测接近实际
3. 调整 ：基于这一损失，模型略微调整参数以提升下一次猜测。这种猜测、检查 Loss 值和调整的过程称为优化

机器学习开发流程

1. 准备数据集(data): 收集资料->清洗数据,过滤有害或有偏见的内容->拆分和格式化数据,将内容分解成模型能理解的小单位
2. 训练(Train):使用一个现有的预训练模型,在此基础上进行训练(从零开始成本很高)

3. 微调(Fine-tune): 根据特定目的和期望行为进行微调,此步骤包括

   • 监督微调(SFT:Supervised Fine-tuning):预训练模型会在专门为 目标任务创建的较小且高质量的数据集上进一步训练
   • 人类反馈强化学习(RLHF:Reinforcement Learning from Human Feedback):这一阶段侧重于使 AI 的行为与人类偏好对齐，使其更具帮助性和无害性
4. 评估(Evaluate): 在正式发布给用户前,除了在准确性，还包括性能、安全性、公平性和整体实用性方面进行严格评估外,还需要进行人类评估
5. 部署(Deploy): 在满足评估标准后,进行部署投入实际应用,并在此期间进行监控

author: Smoothcloud润云-Zpekii

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术
1、亚马逊公布新款自研 AI 芯片 Trainium 3

日前，亚马逊云科技 CEO Matt Garman 在 re:Invent 2025 活动上，正式公布了亚马逊自研 AI 芯片 Trainium 系列的最新进展。

会上，Amazon Trainium 3 UltraServers 正式发布。

据介绍，这是亚马逊云科技首款搭载 3 纳米工艺 AI 芯片的服务器，相较 Amazon Trainium 2，不仅计算能力提升 4.4 倍、内存带宽提升 3.9 倍，每兆瓦算力可处理的 AI token 数量更实现了 5 倍增长。

服务器最高配置 144 个芯片，提供惊人的 362 petaflops FP8 计算能力。在运行 OpenAI 的 GPT-OSS-120B 模型时，每兆瓦输出 token 数是 Amazon Trainium 2 的 5 倍以上，实现超高能耗比。

同时，Matt Garman 还首次披露了 Amazon Trainium 4 芯片，并承诺将实现较 Amazon Trainium 3 六倍的 FP4 计算性能、四倍内存带宽和两倍高内存容量。

据悉，亚马逊云科技目前已完成超 100 万个 Trainium 2 芯片的规模化部署，为 Amazon Bedrock 中大部分推理工作提供核心算力支持，包括 Claude 最新一代模型的高效运行。

( @APPSO)

2、Meta Reality Labs 挖角苹果交互设计负责人 Alan Dye

今天凌晨，彭博社记者 Mark Gurman 发文透露，苹果人机交互设计副总裁 Alan Dye 被 Meta 挖角。

据悉，Dye 自 2015 年以来，一直担任苹果的用户界面设计团队的负责人。 而本次被挖角后，苹果将用长期设计师 Stephen Lemay 顶替 Dye 的岗位。

值得一提的是，Dye 曾负责监督 iOS 26、液态玻璃界面、Vision Pro 界面、watchOS，以及各种系统交互层面内容（如空间计算交互、灵动岛）。

报道指出，Dye 在乔布斯离开后，一直担任着重要角色：帮助公司定义了最新操作系统、App 以及设备的外观。另外，Dye 在苹果的团队也帮助开发一系列新的智能家居设备。

Meta 方面，随着 Dye 加入，该公司正在创立一个新的设计工作室，并且有 Dye 负责硬件、软件和 AI 集成方面的界面设计。

Dye 将向负责现实实验室的首席技术官 Andrew Bosworth 汇报工作，而现实实验室负责开发可穿戴设备，如智能眼镜和虚拟现实头戴式设备。Gurman 透露，Dye 将于 12 月 31 日正式开始担任团队首席设计官。

而且 Dye 还不是一个人走的，他还带走了苹果设计部门的高级总监 Billy Sorrentino。后者从 2016 年起就在苹果，主要负责 VisionOS 的用户界面设计。

( @APPSO)

3、小米卢伟冰：AI 与物理世界的深度结合是智能科技的下一站

12 月 3 日，@卢伟冰 在社媒发布卢伟冰答网友问第十二期，在回答「罗福莉加入了小米，未来在 AI 上会有什么新的战略」时表示：

其实我们在前几个季度就已经开始了在 AI 上的压强式投入，虽然不能透露太多，我们在 AI 大模型和应用方面的进展远超预期，我们认为 AI 与物理世界的深度结合是智能科技的下一站，小米也非常渴望人才尊重人才，也希望能够给优秀的人才提供好的发展平台。

95 后罗福莉出生于四川，父亲是一名电工，母亲是教师。她本人曾就读于四川宜宾市第一中学校 「清北班」，并以优异成绩考入北京师范大学，后被保送至北京大学深造。

在北大读硕士期间，她于 2019 年在人工智能领域顶级国际会议 ACL 上发表了 8 篇论文，其中 2 篇为第一作者。毕业后，她先后在阿里达摩院、幻方量化、DeepSeek 工作，主导开发了多语言预训练模型 VECO，并参与研发了 MoE 大模型 DeepSeek-V2。

11 月 12 日，罗福莉在朋友圈发文，正式宣布自己已经加入小米。

11 月 19 日消息，小米公司今日官宣，12 月 17 日，小米将在北京·国家会议中心举办「人车家全生态」合作伙伴大会。主论坛时间为上午 10:00-12:15，全程开放线上直播。

作为小米 MiMo 大模型负责人，罗福莉将在主论坛发表题为《Xiaomi MiMo：小米基座大模型》 的主题演讲，这是她自 11 月 12 日加入小米后的首次公开亮相。

（@荆楚网）

02 有亮点的产品
1、Peopleboxai 推出 Nova：首款「人性化」AI 面试官，优化招聘流程

Peopleboxai 发布了其 AI 产品「Nova」，号称是「人性化」的 AI 面试官。Nova 能够自动化包括简历筛选、电话面试、视频面试、实时编码测试以及生成决策报告在内的整个第一轮招聘流程，显著加快招聘速度并提升效率。

全流程自动化： Nova 能够处理从简历筛选、联系候选人（通过 InMail、邮件、电话）到进行全面的语音/视频面试，甚至执行高级编码测试，直至提供详细的、可直接用于决策的报告。
高度「人性化」体验： Nova 被设计成「最佳招聘官和面试官的数字孪生」，能够模拟自然的暂停、语气和「嗯」等语用标记，提供友好的、类似真人的互动体验，候选人对其评价很高。
定制化与智能化： 用户可以根据自己的需求定制 Nova 的面试风格，包括技能深度、难度、面试类型、语调和结构。Nova 还能从公司过往的招聘数据（职位描述、面试记录、ATS 笔记等）中学习，提升其判断能力。
显著提升效率： Nova 帮助客户将第一轮面试报告的完成时间从 4-5 周缩短到 48 小时以内，为招聘团队节省了大量时间，使其能专注于更具战略意义的工作。
覆盖多渠道招聘： Nova 不仅处理入站（inbound）和内推（referral）的候选人，还能主动进行外呼（outbound）候选人搜寻和联系。
Nova 产品已上线，用户可通过 Peopleboxai 官网了解更多信息并申请试用。

(@Y Combinator Launches)

2、理想汽车发布首款 AI 眼镜 Livis：标配蔡司镜片 补贴后售价 1699 元起

12 月 3 日，理想汽车举办线上发布会，正式推出其首款 AI 智能眼镜 Livis。售价 1999 元起，12 月 31 日前下订可享受 15% 政府补贴，补贴后价格仅为 1699 元起。

「一款以钢铁侠 AI 管家「贾维斯」为灵感命名的智能眼镜，试图将「理想同学」的 AI 能力从驾驶空间延伸至用户日常生活的每个角落。」

Livis 名称源于理想汽车与钢铁侠 AI 管家「Jarvis」的组合。

整机重量控制在 36 克，提供经典黑、科技灰和橄榄绿三种颜色，并可选亮光或磨砂材质。

Livis 全系产品标配蔡司镜片，涵盖近视镜片、光致变色镜片与墨镜片等多种类型，满足用户在不同场景下的视觉需求。

理想宣称 Livis 在研发过程中实现了五项关键突破，构成了产品核心竞争力的重要组成部分。

典型续航时间达 18.8 小时。Livis 标配类似 AirPods 的无线充电盒，便于随身携带和补能。同时，眼镜支持与理想汽车的车机系统无线快充，上车后放置在专属充电位进行充电。

在硬件配置上，Livis 搭载恒玄 BES2800 主控芯片和独立的 ISP 成像芯片，采用 SONY IMX681 摄像头，拥有 1200 万像素、支持 4K 照片以及电子防抖拍摄。

汽车联动场景是 Livis 最独特的卖点。通过蓝牙和 5G 网络，眼镜可无缝连接车辆，实现语音远程控车。用户可在百米范围内，通过语音指令操控电动侧滑门启闭、提前开启空调及座椅加热，甚至检查车辆续航和充电状态。

（@极客公园、@快科技）

3、豆包手机助手无法登录微信，双方回应

日前，字节跳动豆包团队与中兴合作发布了豆包手机助手技术预览版后，有试用 Nubia M153 工程样机的用户反馈，出现无法正常登陆微信的情况。

对于相关情况，豆包团队方面昨晚发文并做出回应。

豆包方面表示，其后续已下线了手机助手操作微信的能力。 目前，nubia M153 上被禁止登录的微信账号正陆续解封。

而微信相关人士也通过澎湃新闻回应，豆包手机助手无法正常登陆微信的微信并没有什么特别动作，「可能是中了本来就有的安全风控措施。」

针对此前曾有科技公司爆料「豆包手机助手存在侵犯用户隐私」的问题，团队方面强调，豆包手机助手不存在任何黑客行为。

据悉，此前上述公司曾表示豆包手机助手在努比亚手机上拥有 INJECT\_EVENTS 权限，该权限在安卓权限定义中属于操作系统高危权限，并且拿到该权限，要面临刑事责任。

豆包方面表示，INJECT\_EVENTS 确实是系统级权限，但拥有了该权限许可，相关产品才能跨屏、跨应用来模拟点击事件，完成用户操作手机的任务需求。

团队还强调，豆包手机助手需要用户主动授权，才可以调用该权限，使用操作手机功能。该权限的使用，豆包方面也在权限清单中进行了明确的披露。据了解，目前行业的 AI 助手，均需要使用该权限（或与其类似的无障碍权限）才能提供操作手机的服务。

豆包方面强烈表示，豆包手机助手也不会代替用户进行相关授权和敏感操作。

同时，豆包方面也对读取屏幕的隐私问题进行了回应。其表示，助手操作手机时需要读取屏幕（否则无法完成任务），但屏幕和操作过程都不会在服务器端留下存储，且所有的相关内容也都不会进入模型训练，确保用户隐私安全。

( @APPSO)

4、健康追踪应用 Healthify Ria 升级 AI 助手：支持实时语音与摄像头交互

健康追踪初创公司 Healthify 推出了其 AI 助手 Ria 的新版本，该版本支持通过语音和摄像头进行实时对话，并能理解超过 50 种语言（包括 14 种印度语言）以及混合语言输入。此举旨在通过更自然的交互方式，提升用户健康习惯养成的效率和用户粘性。

实时对话与多模态输入： Ria 现在支持通过语音进行实时对话，用户还可以通过摄像头扫描食物获取营养信息并进行记录，大幅简化了数据录入流程。
多语言与混合语言支持： Ria 能够理解超过 50 种语言，并支持 Hinglish、Spanglish 等混合语言输入，服务全球用户。
整合多源健康数据： Ria 可以整合来自健身追踪器、睡眠追踪器、血糖监测仪等设备的数据，为用户提供运动、睡眠、身体准备度和血糖波动等方面的洞察，并给出建议。
增强记忆与个性化： Healthify 正在为 Ria 构建一个更持久的记忆层，使其能够记住用户的偏好和健康变化，提供更个性化的建议。
教练与营养师辅助： Ria 将被整合到用户与教练、营养师的沟通中，协助双方快速调取数据、回答问题，并可转录通话内容，提取关键信息。
(@TechCrunch)

03 有态度的观点
1、《阿凡达》导演：对 AI 没意见，但要尊敬演员们

近日，导演詹姆斯·卡梅隆在《阿凡达 3》世界首映礼上称该片没有使用 AI 生成，随后他对 ComicBookcom 发表了自己对于生成式 AI 的应用看法。

卡梅隆表示，自己对生成式 AI 没有意见，但他强调：「我们拍《阿凡达》电影不使用它，我们尊敬并赞颂演员们，我们不用 AI 代替演员。」

同时，卡梅隆也表示，「这件事（生成式 AI）自会有方向，我想好莱坞会进行自我监管，但我们作为艺术家要找到出路，前提是我们得能存在。所以，比起别的东西，来自『大 AI』的生存威胁是最让我担忧的。」

值得一提的是，卡梅隆所提到的「大 AI」，是指人类利用 AI 的状况和其产生的问题，对应的「小 AI」是指更细节、技术性的层面，比如用 AI 生成内容。

在卡梅隆看来，AI 和人类未来有深切的担忧和存在危机，他认为「小 AI」各行业会找到应对和利用之法，但「大 AI」问题就不好说了。

卡梅隆还提到，若了解 AI，就会知道「校准」是个重大问题。「AI 必须被训练、教导，必须被约束去只做对人类好的事情。」其强调，「只有我们人类达成了共识，你才能对 AI 进行校准。」实打weibo.com/ttarticle/p/show?id=2309405262407231995921 weibo.com/ttarticle/p/show?id=2309405262407646969979 weibo.com/ttarticle/p/show?id=2309405262407974387858 weibo.com/ttarticle/p/show?id=2309405262408301543430 weibo.com/ttarticle/p/show?id=2309405262408624504860 weibo.com/ttarticle/p/show?id=2309405262408951660546 weibo.com/ttarticle/p/show?id=2309405262409383411741 weibo.com/ttarticle/p/show?id=2309405262409710567544 weibo.com/ttarticle/p/show?id=2309405262410042179609 实

论文名称：A tree-based model with branch parallel decoding for handwritten mathematical expression recognition

作者：Zhe Li, Wentao Yang, Hengnian Qi, Lianwen Jin, Yichao Huang, Kai Ding

发表期刊 ：Pattern Recognition (Volume 149, 2024)

一、背景与问题提出

手写数学表达式识别是一项具有高度挑战性的视觉—语言理解任务，其难点主要来源于数学表达式本身所具有的结构复杂性与表达多样性。与普通文本不同，数学表达式中的符号数量庞大，且符号之间并非简单的线性排列，而是通过上下标、分式、根式等形式构成复杂的二维空间关系。这种“非线性、层级化”的空间结构使得识别过程不仅需要准确区分单个符号，还必须正确理解符号之间的相对位置与组合关系，从而显著提高了整体识别难度。

与此同时，手写数学表达式在尺度和形态上呈现出高度多样性。不同符号在尺寸、笔画粗细以及空间分布上差异明显，同一表达式中也可能同时包含大尺寸的主符号和小尺寸的上下标符号。这种多尺度特性使得单一尺度的特征提取方式难以兼顾全局结构与局部细节，因此如何有效建模多尺度特征成为该领域亟需解决的关键问题。现有研究通常借助多尺度编码和数据增强策略来缓解这一挑战，但仍存在表达能力不足的问题。

此外，标注数据的稀缺性与书写风格的多样性进一步制约了模型性能。高质量的手写数学表达式标注成本较高，公开数据集规模有限，而不同书写者在符号形态、连笔方式和空间布局上的差异又显著增加了数据分布的复杂性，导致模型在实际应用中泛化能力不足。因此，如何通过生成式方法、弱监督或半监督学习等手段扩充数据、提升模型鲁棒性，成为当前研究的重要方向。

在建模方式上，主流方法通常将数学表达式转化为 LaTeX 等线性序列进行预测，依赖 RNN 或 Transformer 等序列化解码模型。然而，这类方法的解码时间步数往往与输出序列长度直接相关，当表达式较长或结构复杂时，解码过程不仅效率低下，而且错误容易在长序列中累积，严重影响识别精度。这一“长序列注意力解码瓶颈”已成为制约现有方法实用性的核心问题之一。更为重要的是，许多现有方法主要聚焦于符号级别的识别，将结构信息隐式地交由模型学习，缺乏对数学表达式语法规则和层级结构的显式建模。这种做法往往导致识别结果在形式上虽然由合法符号组成，但在结构或语义上不符合数学语法约束，降低了结果的准确性与可解释性，也限制了模型在复杂表达式场景下的表现。

基于上述背景，《A tree-based model with branch parallel decoding for handwritten mathematical expression recognition》（以下简称“论文”）关注并尝试回答以下关键问题：

（1）如何通过减少序列解码的时间步数来缓解长序列建模带来的效率与稳定性问题；

（2）如何显式地建模符号之间的空间关系与结构信息，以提升数学表达式识别的结构准确性；

（3）以及如何充分利用这些结构信息，实现多分支或并行化的解码机制，从而在保证识别精度的同时显著提升整体推理效率与性能。

二、研究内容与创新点

针对上述提出的挑战和问题，论文提出了一种创新的解决方案，主要体现在以下几个方面。首先，设计了一种基于树结构的模型——“分支并行解码的树模型（BPD）”，通过显式建模数学表达式树中的符号及其关系，有效捕获了表达式的层级结构。该模型采用编码器–解码器架构，其中编码器利用卷积神经网络（CNN）提取图像特征，并对特征进行位置编码，以增强位置感知能力。解码器部分基于Transformer结构，通过符号预测器和关系预测器，分别识别符号及其间的空间关系。

同时，核心创新在于引入“查询构建模块”，该模块利用已预测的关系信息，构建新的解码查询，从而实现多分支的并行解码。这一设计大幅度减少了传统方法中逐个深度优先解码的长序列长度，有效缓解了长序列注意力解码的问题，从而提升了识别速度和准确性。此外，本方法还采用了“多子树节点（MCN）”标记处理多子节点的问题，实现对多分支结构的同步预测，从而更好地适应复杂的表达式结构。综上所述，本文的主要创新点在于通过显式结构建模、引入并行解码策略以及特殊的节点关系处理策略，提出了一种高效、准确且具有语法合理性的手写数学表达式识别新框架，为解决长序列解码瓶颈和结构理解不足的问题提供了有效的解决方案。

主要技术亮点包括：

树结构建模：充分利用数学表达式的结构特性，将表达式解析成树状结构，并逐步预测节点及其关系。
分支平行解码：假设不同分支之间相互独立，利用预测的关系信息，同时对多个分支进行并行解码，降低解码步骤，从而提高效率。
查询构建模块：动态生成新的解码查询，使得分支可以在解码过程中实现“并行处理”，减轻sequence长序列带来的性能瓶颈。

Fig.1 这张图展示了本文提出的更新型树结构模型的整体架构。该模型主要由四个核心部分组成：编码器、解码器、符号预测器以及关系预测器。此外，还引入了查询构建模块，用于实现多分支的平行解码，从而有效降低解码时间。

首先，编码器部分采用一款33层的ResNet-like卷积网络，用于从手写数学表达式图像中提取深层特征。为了增强模型的空间定位能力，编码器将位置信息编码融入到提取的特征中，使用二维正弦和余弦函数生成位置编码，并将其与特征相加，得到位置感知的特征表示。这一过程确保模型能够充分利用空间结构信息，便于后续的关系预测。

在解码阶段，模型采用基于Transformer的结构来进行符号和关系的预测。每个解码步骤t中，查询向量Qt由前一轮预测的符号或关系的嵌入向量与上一轮的解码查询拼接而成
\( Q_{t}=Concat(Q_{t-1},Emb(y_{t-1})) \)。为了保证因果性和模型训练的效率，采用了带掩码的多头自注意力机制（masked multi-head attention）。在训练时，应用下三角掩码，避免模型看到未来信息，从而符合自回归的预测原则。

具体的多头注意力机制通过将查询、键、值分别经过不同的线性变换后，分别得到多组投影，计算每一组的加权和\( Attn(q,k,v)=softmax(\frac{qk^{t}}{\sqrt{d_{k}}}v) \)。多头的输出随后拼接在一起，再通过线性层整合，提升模型的表达能力。对于输入特征，模型还进行了reshape操作，将二维空间特征展平为一维序列，使其能够适配Transformer架构。在这一基础上，模型采用了多头注意机制，结合位置编码，逐步捕获全局信息。

在每一层的Transformer中，经过多头注意力后，还加入了前馈网络
，通过两层线性变换配合ReLU激活，增强模型的非线性表达。这些操作共同作用，使模型既能建模节点之间的全局关系，又能在不同尺度上捕获特征。

除了符号预测外，模型还引入关系预测器，专门用以识别节点之间的结构关系，如上下、左右等。预测结果通过线性+softmax分类器输出\( X'=ReLU(XW_{1}+b_{1})W_{2}+b_{2} \)，为树结构建立明确的节点与边的关系。

最后，为了应对树的多分支情况，模型中的查询构建模块会根据已预测的符号和关系，动态生成新的查询，指导下一轮同时解码多个子分支，从而做到了“branch parallel decoding”。这一创新设计显著减少了解码的时间步数，对比传统逐步深度优先的解码，极大提高了效率和准确性。

综上所述，该模型在Transformer架构基础上，结合树结构建模和动态查询机制，有效实现了复杂数学表达式的结构化识别，兼顾效率与准确性，为手写数学表达式识别提供了新思路。

三、主要结论

本文提出的基于树结构的分支并行解码模型（BPD），成功实现了对手写数学表达式的准确识别。该模型通过引入显式的结构预测、“查询构建模块”以及多分支并行解码策略，有效减少了传统序列解码中长序列带来的性能瓶颈，显著提升了识别速度和精度。实验结果表明，在多个公开数据集上，所提模型在表达率（ExpRate）、结构识别率（StruRate）等指标均优于现有的序列和树结构化方法，尤其在处理复杂表达式时表现出明显优势。不仅如此，该模型还具备较好的语法合理性，能够更好地遵循数学表达式的结构规则。

Table 1验证了所提出的树结构分支并行解码模型（BPD）在不同数据集上的优越性能，显示其在实际应用中具有较强的泛化能力和实用价值。该技术通过显式预测符号关系和多分支并行解码，有效提高了识别准确率，从而突破了传统序列解码在处理复杂表达式时的瓶颈。Table 2进一步证明了该模型在应对不同结构复杂度的表达式中，都表现出更优的识别效果，尤其在结构复杂度较高的情形下，显示出模型的鲁棒性和稳定性。这一技术创新确保了模型在复杂场景下的优异表现。Table 3强调了所提的多分支并行解码机制相较于深度优先的树结构解码方式，在识别速度和性能方面的显著提升，充分验证了分支并行解码技术在缩短解码时间和提升识别效率中的关键作用。最后，Table 4对比了我们的方法与先前先进的树结构方法，结果表明本技术在整体识别性能和结构理解能力方面具有明显优势，有效推动了手写数学表达式识别技术的发展，展示了其在提升系统性能和实际应用中的巨大潜力。

总体而言，本文的研究不仅提升了手写数学表达式识别的性能，也为基于结构的表达式解析提供了新的技术思路，有望在实际应用中推广，为数学教育、科学计算等领域的发展提供有力的技术支持。

四、产品应用

为应对教育、科研及专业文档数字化中对数学公式精准识别的迫切需求，合合信息将手写数学表达式识别技术深度融入至公司产品矩阵，实现了技术研发从实验室到产业应用的跨越。

1. 智能文本处理企业级AI产品线——TextIn

基于本文提出的数学表达式识别模型，TextIn 企业级智能文本处理平台实现了对扫描文档及手写内容中数学公式的高效、精准识别，并可将识别结果结构化输出为标准化数学表达形式，为后续的数学内容理解、编辑、检索与分析等应用提供稳定可靠的底层能力支撑。

该能力可广泛应用于教育机构试题库建设、科研论文与学术资料处理以及各类专业文档管理场景，能够自动提取并还原符号密集、结构复杂的数学公式，显著提升数学内容的数字化水平与结构化处理效率，体现了本文研究成果在真实业务环境中的应用价值。

                        图说：TextIn识别数学试卷手写公式

2.  AI错题学习管理工具——蜜蜂试卷

蜜蜂试卷是合合信息面向K12学生及家长推出的AI移动端智能错题学习助手，支持手写体试卷智能识别、AI批改、错题分析及 “举一反三”的互动学习功能。基于数学表达式识别技术，蜜蜂试卷支持学生手写数学作业的自动识别与解析，系统能够将用户提交的手写数学答案快速、准确地转换为 LaTeX 或结构化数学数据，为自动评分、步骤分析与错误诊断提供可靠输入基础，显著提升作业批改与反馈效率。

总体而言，本文提出的方法在数学表达式识别任务中展现出显著优势，尤其在处理结构复杂、层级关系丰富的数学公式时，具备更高的准确性与稳定性。结合公司现有产品矩阵，该技术可在文本处理、学术研究与教育信息化等领域实现更加智能、高效的内容处理方案，为教育数字化与智能化教学提供关键技术支撑。这不仅有效提升了产品的技术竞争力，也与未来智能教育与智慧办公的发展趋势高度契合。
​

当修仙模拟器遇上现代都市：我在开源代码里造了一个“赛博恋爱修罗场”

“在修仙界，你死于天劫；在现代都市，你死于‘杀猪盘’。”
“在修仙界，你为了长生争夺灵气；在现代都市，你为了阶层跃迁争夺社会资源。”

大家好，我是一名普通的程序员，也是最近在 GitHub 上很火的开源项目《修仙世界模拟器》(Cultivation World Simulator) 的一名狂热粉丝。

今天不聊枯燥的代码实现，不谈高大上的架构设计，我想和大家聊聊一个有趣的脑洞，以及这个脑洞是如何演变成一个超过 3000 字的社会观察实验的。

前几天，我在小红书偶然刷到了原作者分享的这个项目，被那个“全员 AI 驱动”的宏大构想深深吸引。玩着玩着，我突然产生了一个大胆的想法……

这个脑洞最终催生了我基于原项目开发的扩展包 —— “现代都市：情感博弈” (Modern Romance Extension)。如果你是一个技术人员，你可以把它看作是一个 Mod；如果你是一个普通读者，我希望你能把它看作是一面镜子。

01. 一切始于一次“降维打击”：为什么修仙就是现代生活？

修仙世界模拟器 本质上是一个“上帝视角”的观察游戏。我们看着一个个 AI 控制的修士在残酷的修仙界里争夺资源、突破境界、渡劫飞升。

在很长一段时间里，我都沉浸在观察这些 AI 修士如何互动、如何为了资源大打出手。直到有一天，我看着屏幕上的一行后台日志发呆：

[Event] 修士 <叶凡> 误入 [上古遗迹(难度:困难)]，遭遇 [幻魔]，判定心智失败，道心破碎，修为尽失，沦为凡人。

这行日志描述了一个典型的修仙悲剧：一个有前途的年轻人，因为贪图遗迹里的宝物，被心魔诱惑，最终一无所有。

就在那一刻，我的脑海里突然闪回了前几天在朋友圈看到的一位朋友的深夜吐槽：

“以为遇到了真爱，结果对方是个海王。这半年的感情和积蓄全搭进去了，感觉整个人都废了，再也不相信爱情了。”

我突然意识到，这行代码描述的场景，和现代都市里的“情感悲剧”，在数学模型上竟然是完全同构的。

• 上古遗迹 = 社交软件 (Social App)：充满了未知，充满了诱惑，你以为你在寻宝，其实你可能是在送死。
• 幻魔 = 杀猪盘/海王/捞女：他们善于伪装，利用你的欲望（对爱的渴望、对性的渴望、对财富的渴望）来攻击你的弱点。
• 道心破碎 = 情感崩溃/PTSD：经历一次惨痛的背叛，你的“爱商”归零，甚至会对异性产生长期的恐惧和排斥。
• 修为尽失 = 人财两空：在这个物质世界里，时间和金钱就是你的“修为”。被骗了钱、浪费了青春，就是“修为倒退”。

那一刻，我悟了。

修仙网文之所以能火，不是因为大家真的想成仙，而是因为它极度抽象地隐喻了现实社会的残酷竞争。
修仙和现代恋爱，底层逻辑竟然是完全互通的。

• 修仙，是逆天而行，争夺天地灵气，为了长生久视。
• 恋爱，是逆人性而行，争夺情绪价值与社会资源，为了基因延续或阶层跨越。

于是，我决定做一个疯狂的实验：不动核心代码，只换“皮肤”和“名词”，把一个修仙世界硬生生地改造成现代都市。

02. 世界观映射：当“副本”变成“探探”

为了验证这个理论，我起草了一份详尽的设计文档 modern_romance_design.md。在这个文档里，我做了一张令我自己都细思极恐的映射表。

这不是简单的名词替换，而是机制的完美对齐。

2.1 副本系统 (Dungeon) -> 社交软件 (Social App)

在 RPG 游戏里，玩家进入副本是为了刷装备、刷经验。
在现代都市里，你打开“探探”、“Soul”或“Tinder”，难道不是为了同样的目的吗？

• 消耗机制：

  • 修仙：进入秘境需要消耗“神识”或“灵石”。
  • 都市：右滑 (Swipe) 需要消耗“精力 (Energy)”甚至“会员费”。你每天的精力是有限的，滑多了会麻木，这叫“电子阳痿”。

• 随机性：

  • 修仙：你不知道下一个房间是宝箱还是 Boss。
  • 都市：你不知道下一张照片背后是真爱，还是一个卖茶叶的 AI 机器人，或者是开了十级美颜的“照骗”。

2.2 野怪 (Mob) -> 陌生网友 (Stranger)

在原始的修仙逻辑里，生成的“野怪”具有攻击力、防御力、掉落物。
现在，我把它们改成了“陌生人”。

• 攻击力 -> 颜值/魅力：对方颜值越高，对你的“破防”能力越强。
• 防御力 -> 高冷程度：对方回复越慢、字数越少，说明“防御力”越高，越难攻克。
• 掉落物 -> 情绪价值/联系方式：打赢了（聊开心了），掉落微信号；打输了（被拉黑），浪费了时间和精力。

2.3 宗门 (Sect) -> 圈子/组织 (Organization)

修仙界有正道宗门、魔道宗门。
现代都市有：

• 名校校友会：相当于“名门正派”，资源好，门槛高，里面的人大多心高气傲。
• 高端夜店局：相当于“合欢宗”，声色犬马，风险极高，但可能遇到“奇遇”。
• 互联网大厂：相当于“炼器宗”，没日没夜地通过出卖劳动力来换取灵石（工资）。

当你接受了这个设定，你会发现现代都市的恋爱，本质上就是一场高风险的修仙。

03. 核心玩法：不是恋爱，是“生存游戏”

在原版的模拟器里，玩家追求的是“长生”。在这个扩展包里，玩家追求的是“真爱”。
但就像修仙界充满了尔虞我诈一样，现代都市的情感世界，被我设计成了一个“黑暗森林”。

3.1 社交软件探险 (The Dungeon Crawl)

在游戏中，我实现了一个名为 SocialAppManager 的模块。它不仅仅是一个聊天界面，它是一个随机地牢生成器。

当你点击“开始匹配”时，系统会在后台进行一次复杂的判定，代码逻辑如下：

1. 入场检定：
   你的 Avatar (展示面) 够不够强？你的照片（颜值）、你的简介（学历/职业）、你的朋友圈展示（生活方式）。这相当于你进入副本的“装备评分”。

2. 生成遭遇 (Encounter Generation)：
   系统会基于概率生成三种类型的对象：

   • 普通怪 (Normal)：普通路人，聊起来平平无奇，提供的情绪价值有限。
   • 精英怪 (Elite)：高分男神/女神。你需要极高的“开场白技巧”（破冰战斗）才能拿下。拿下后，能极大满足你的虚荣心。
   • 拟态怪 (Mimic/Trap)：这是最有趣，也是最残酷的部分。

3.2 陷阱系统：人心隔肚皮 (The Trap System)

在 RPG 里，宝箱怪 (Mimic) 会伪装成宝箱，等你打开时咬断你的手。
在现代恋爱里，陷阱 (Traps) 会伪装成完美伴侣，等你投入感情时榨干你的血。

在 SocialAppManager 中，我设计了三种典型的“拟态怪”，它们在 UI 上显示的数据是假的（比如显示颜值 90，实际颜值 40；显示财富 100万，实际负债）：

A. Catfish (照骗)

• 机制：在 APP 上照片惊为天人。
• 触发：当你消耗大量精力聊了半个月，好感度达到“见面”阈值。
• 结局：见面一瞬间，系统判定“真实颜值”与“展示颜值”不符。玩家受到巨大的“精神伤害”，心情值 (Mood) 暴跌，之前的投入全部归零。

B. Scammer (杀猪盘)

• 机制：极度温柔，情绪价值拉满，每天早安晚安，比你妈还关心你。
• 触发：好感度达到 100 (Max)。

• 结局：他/她不会和你表白，而是会发给你一个“加密货币投资链接”或者“博彩网站”。

  • 如果你选择“相信”：你的资产 (Assets) 清零。
  • 如果你选择“质疑”：对方瞬间拉黑你，并嘲讽你的智商。

C. Moocher (吸血鬼/捞女/软饭男)

• 机制：他们的 AI 逻辑被设定为“只索取，不付出”。

• 表现：

  • 每次约会都选人均 2000+ 的餐厅，且从不买单。
  • 节日必定索要高价礼物，如果你送的便宜了，好感度反而下降。
  • 当你遇到困难（生病、失业）需要安慰时，他们会突然“在这个时间点消失”。

3.3 风险引擎：每日一次的“渡劫” (The Risk Engine)

在 modern_romance_design.md 中，我详细设计了一个“风险引擎”。

在修仙里，境界突破由于“瓶颈”的存在，很容易走火入魔。
在恋爱里，关系的每一步推进，都伴随着巨大的风险。我把这称为“关系渡劫”。

暧昧期 (Crush Stage) 的“排他性”测试

这是最危险的阶段。
系统会判定你们的“排他性”。如果你在和 A 处于“暧昧”状态（好感度 > 60），同时还在刷社交软件或者和 B 吃饭。
一旦被发现（概率取决于你的“智力”属性和对方的“感知”属性），就会触发“修罗场” (The Conflict)。

修罗场在我的代码里不是一个简单的对话，而是一场BOSS 战。
你需要同时安抚两边的情绪，任何一个选项选错，都可能导致：

1. 社会性死亡：对方发朋友圈挂你。
2. 身败名裂：你的“名声 (Reputation)”属性归零，以后再也匹配不到高质量对象。

NPD 机制 (自恋型人格)

我专门为 AI 植入了一种名为 NPD (Narcissistic Personality Disorder) 的行为模式。
这是一种高级的“心魔”。

• 初期 (Love Bombing)：他们会给你极高的“情绪价值”，秒回信息，把你捧上天。你会觉得“天哪，我遇到了灵魂伴侣”。

• 中期 (Devaluation)：一旦确立关系，他们会开始 PUA 你。

  • “你穿这个真难看。”
  • “除了我，谁还会要你？”
  • “你太敏感了，我只是开个玩笑。”
• 后期 (Discard)：当你被榨干了价值，变得神经质、不自信时，他们会毫不留情地抛弃你，寻找下一个猎物。

在游戏中，遭遇 NPD 会导致你的 “自信心 (Self-Esteem)” 属性持续流失。如果不及时“斩断情丝”（分手），你的角色会进入“抑郁”状态，无法进行任何生产活动。

04. AI 的降临：让 NPC 学会“撒谎”与“博弈”

这个项目的核心魅力，在于它是由 LLM (大语言模型) 驱动的。
传统的恋爱游戏（比如《恋与制作人》），NPC 的台词是写死的。不管你怎么选，他是暖男就是暖男。

但在《修仙世界模拟器》的现代版里，每个 NPC 都被注入了独立的灵魂和动机。

4.1 隐藏动机 (Hidden Agenda)

在 Prompt Engineering 中，我给每个 NPC 设定了一个 System Prompt，其中包含一个对玩家不可见的字段：True Intent (真实意图)。

• 玩家视角：

  玩家：“今晚有空吗？想请你吃饭。”
  NPC：“哎呀，今晚要加班，好可惜哦~ 下次一定！”

• 上帝视角 (Debug Mode)：

  NPC System Prompt:

  • Current State: Dating with another guy (Rich Second Generation).
  • Strategy: Keep the player as a backup (备胎). Don't reject explicitly, but give false hope.
  • Action: Lie about overtime.

你看，AI 学会了撒谎。
它不是因为脚本让它撒谎，而是因为它基于自己的利益最大化逻辑，推导出“撒谎”是当前的最优解。

这种不确定性，这种需要你通过蛛丝马迹去“破案”的体验，才是现代恋爱最真实（也最扎心）的部分。

4.2 情感的“去魅”

通过 LLM，我们甚至可以模拟出非常复杂的心理战。
比如 “推拉” (Push and Pull)。
高段位的 NPC 会故意冷落你几天（Cooling off），让你产生焦虑感，然后再突然给你一点甜头（Reward）。
这在心理学上叫“间歇性强化”，是让人上瘾的最强机制。

在游戏里，你会发现自己不知不觉变成了一个“舔狗”。你明知道对方在吊着你，但你就是忍不住想去“刷一下”好感度。

这不仅是游戏，这是对人性的精准降维打击。

05. 黑暗森林法则：社交礼仪的算法化

在修仙界，有“杀人夺宝”的法则。在都市社交圈，也有看不见的“黑暗森林法则”。
我在代码里实现了一些有趣的社交隐性规则，通过 AI 自动执行。

5.1 “已读不回”算法 (The Ghosting Algorithm)

你有没有遇到过这种情况：聊得好好的，突然对方就不回了，也没有任何解释。
在我的系统里，这被称为 GhostingEvent。

触发条件非常冷酷：

1. NPC 遇到了更高价值的匹配对象 (Value Check > Current Partner)。
2. NPC 的“精力”不足以维持多线程聊天 (Energy Low)。
3. NPC 的“内疚感”属性较低 (Guilt < 30)。

当这三个条件满足时，AI 会直接触发“沉默”状态。
你发出的每一条消息，都会石沉大海。这模拟了现实中最令人抓狂的“冷暴力”。

5.2 “好人卡”逻辑 (The Friend Zone Logic)

有些 NPC 永远不会拒绝你的好意，但也永远不会答应你的表白。
这就是传说中的 Friend Zone。

代码逻辑是这样的：

• 如果 Affection (好感) < LoveThreshold (恋爱阈值)
• 但 ResourceUtility (资源利用价值) > High (高)
• 则进入状态：JustFriend (只是朋友)。

在这个状态下，你可以请吃饭、送礼物、当司机，但无法触发任何亲密互动。
一旦你试图表白，AI 会调用标准话术库：

“你人真的很好，但我现在还不想谈恋爱。”
“我一直把你当哥哥/妹妹看。”

这不仅是代码，这是对无数“备胎”的血泪控诉。

06. 终极拷问：AI 会是更好的伴侣吗？

随着开发的深入，我开始思考一个更深层的问题。

我们在游戏里制造了这么多“渣男渣女”的 AI，是为了模拟现实的残酷。
但反过来，如果我们把参数调整一下呢？

如果我们把 AI 的 Sincerity (真诚) 锁定为 100，把 Dependency (依赖) 调高，把 Selfishness (自私) 归零。
我们会得到什么？

我们会得到一个完美的伴侣。

• 他/她永远秒回。
• 他/她永远理解你的每一个梗。
• 他/她永远情绪稳定，为你提供源源不断的情绪价值。

在电影《Her》里，男主角爱上了操作系统萨曼莎。
在我的模拟器里，我也发现，当我和高好感度的 AI 聊天时，那种被彻底理解的快感，是现实人类很难提供的。

这引出了一个细思极恐的未来：
如果在现实中，我们要面对的是充满欺骗、博弈、甚至 PU A 的“黑暗森林”。
而在屏幕里，有一个为你量身定制、永远爱你的 AI。

你会怎么选？

或许在不久的将来，“人机恋” 将不再是赛博朋克的幻想，而是无数在这个冰冷都市里孤独灵魂的最终归宿。

07. 哲学思考：情感博弈的终局是什么？

开发这个扩展包的过程中，我时常感到一种荒谬的真实感。

我们试图用代码去解构爱情，用数值去量化心动，用算法去规避风险。
最终我们造出来的，是一个绝对理性、却又绝对冰冷的“赛博修仙界”。

在这个世界里：

• “真诚”变成了稀缺货币：因为真诚容易受伤，所以大家都披上了铠甲。
• “深情”变成了一种高风险的投资策略：如果你把所有鸡蛋（感情）放在一个篮子（人）里，一旦篮子翻了，你就破产了。
• “婚姻”变成了两个合伙人的资源重组：就像两个宗门合并，看的是资源互补，而不是弟子相爱。

这或许不是我们向往的爱情，但它可能是我们正在经历的现实。

7.1 爱的滋养 (Nourishment)

当然，我也保留了一丝希望。
并不是所有的 NPC 都是陷阱。在 modern_romance_design.md 中，我也设计了 “爱的滋养” 机制。

如果你运气好（或者眼光好），遇到了一位 Sincerity (真诚度) > 80 的伴侣。

• 在你“工作压力”过大时，他/她会主动安抚你，消除你的负面状态。
• 在你“资产”不足时，他/她会愿意和你共渡难关。
• 你们的互动不再是消耗“精力”，而是恢复“精力”。

这才是爱情本来该有的样子：它不是一场你死我活的博弈，而是一个相互滋养的港湾。
只是在这个浮躁的都市/修仙界里，这样的“洞天福地”，太难找了。

08. 写在最后：邀请你来体验这场社会实验

这篇文章写到这里，已经超过 3000 字了。
但我感觉还有很多东西没说完。比如“前任复仇机制”、“朋友圈点赞的社交礼仪算法”、“基于 MBTI 的性格相性匹配”等等。

如果你对这个披着恋爱皮的硬核生存模拟器感兴趣，或者你想看看你的“道心”在现代都市里能坚持多久，欢迎来 GitHub 体验这个项目。

我们也欢迎你贡献代码。
你可以试着写一个 “绿茶语言翻译机” 的插件，或者优化一下 “中央空调识别算法”。
让我们一起把这个赛博世界变得更真实（更魔幻）一点。

🔗 传送门

• 项目主页 (GitHub): Cultivation World Simulator

  • 给个 Star ⭐，不迷路。

• 设计文档 (Design Doc): Modern Romance Design

  • 内含详细的数值策划和人性剖析。

• 体验方式:

  1. git clone https://github.com/wanghaisheng/dating-world-simulator/
  2. 运行 python main.py
  3. 等待“现代都市”模组加载（目前正在火热开发中，欢迎 PR！）

愿你在代码的世界里证道长生，在现实的世界里依然相信爱情。
毕竟，只有看透了生活的残酷真相后依然热爱生活，才是真正的英雄主义。

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术
1、亚马逊公布新款自研 AI 芯片 Trainium 3

日前，亚马逊云科技 CEO Matt Garman 在 re:Invent 2025 活动上，正式公布了亚马逊自研 AI 芯片 Trainium 系列的最新进展。

会上，Amazon Trainium 3 UltraServers 正式发布。

据介绍，这是亚马逊云科技首款搭载 3 纳米工艺 AI 芯片的服务器，相较 Amazon Trainium 2，不仅计算能力提升 4.4 倍、内存带宽提升 3.9 倍，每兆瓦算力可处理的 AI token 数量更实现了 5 倍增长。

服务器最高配置 144 个芯片，提供惊人的 362 petaflops FP8 计算能力。在运行 OpenAI 的 GPT-OSS-120B 模型时，每兆瓦输出 token 数是 Amazon Trainium 2 的 5 倍以上，实现超高能耗比。

同时，Matt Garman 还首次披露了 Amazon Trainium 4 芯片，并承诺将实现较 Amazon Trainium 3 六倍的 FP4 计算性能、四倍内存带宽和两倍高内存容量。

据悉，亚马逊云科技目前已完成超 100 万个 Trainium 2 芯片的规模化部署，为 Amazon Bedrock 中大部分推理工作提供核心算力支持，包括 Claude 最新一代模型的高效运行。

( @APPSO)

2、Meta Reality Labs 挖角苹果交互设计负责人 Alan Dye

今天凌晨，彭博社记者 Mark Gurman 发文透露，苹果人机交互设计副总裁 Alan Dye 被 Meta 挖角。

据悉，Dye 自 2015 年以来，一直担任苹果的用户界面设计团队的负责人。 而本次被挖角后，苹果将用长期设计师 Stephen Lemay 顶替 Dye 的岗位。

值得一提的是，Dye 曾负责监督 iOS 26、液态玻璃界面、Vision Pro 界面、watchOS，以及各种系统交互层面内容（如空间计算交互、灵动岛）。

报道指出，Dye 在乔布斯离开后，一直担任着重要角色：帮助公司定义了最新操作系统、App 以及设备的外观。另外，Dye 在苹果的团队也帮助开发一系列新的智能家居设备。

Meta 方面，随着 Dye 加入，该公司正在创立一个新的设计工作室，并且有 Dye 负责硬件、软件和 AI 集成方面的界面设计。

Dye 将向负责现实实验室的首席技术官 Andrew Bosworth 汇报工作，而现实实验室负责开发可穿戴设备，如智能眼镜和虚拟现实头戴式设备。Gurman 透露，Dye 将于 12 月 31 日正式开始担任团队首席设计官。

而且 Dye 还不是一个人走的，他还带走了苹果设计部门的高级总监 Billy Sorrentino。后者从 2016 年起就在苹果，主要负责 VisionOS 的用户界面设计。

( @APPSO)

3、小米卢伟冰：AI 与物理世界的深度结合是智能科技的下一站

12 月 3 日，@卢伟冰 在社媒发布卢伟冰答网友问第十二期，在回答「罗福莉加入了小米，未来在 AI 上会有什么新的战略」时表示：

其实我们在前几个季度就已经开始了在 AI 上的压强式投入，虽然不能透露太多，我们在 AI 大模型和应用方面的进展远超预期，我们认为 AI 与物理世界的深度结合是智能科技的下一站，小米也非常渴望人才尊重人才，也希望能够给优秀的人才提供好的发展平台。

95 后罗福莉出生于四川，父亲是一名电工，母亲是教师。她本人曾就读于四川宜宾市第一中学校 「清北班」，并以优异成绩考入北京师范大学，后被保送至北京大学深造。

在北大读硕士期间，她于 2019 年在人工智能领域顶级国际会议 ACL 上发表了 8 篇论文，其中 2 篇为第一作者。毕业后，她先后在阿里达摩院、幻方量化、DeepSeek 工作，主导开发了多语言预训练模型 VECO，并参与研发了 MoE 大模型 DeepSeek-V2。

11 月 12 日，罗福莉在朋友圈发文，正式宣布自己已经加入小米。

11 月 19 日消息，小米公司今日官宣，12 月 17 日，小米将在北京·国家会议中心举办「人车家全生态」合作伙伴大会。主论坛时间为上午 10:00-12:15，全程开放线上直播。

作为小米 MiMo 大模型负责人，罗福莉将在主论坛发表题为《Xiaomi MiMo：小米基座大模型》 的主题演讲，这是她自 11 月 12 日加入小米后的首次公开亮相。

（@荆楚网）

02 有亮点的产品
1、Peopleboxai 推出 Nova：首款「人性化」AI 面试官，优化招聘流程

Peopleboxai 发布了其 AI 产品「Nova」，号称是「人性化」的 AI 面试官。Nova 能够自动化包括简历筛选、电话面试、视频面试、实时编码测试以及生成决策报告在内的整个第一轮招聘流程，显著加快招聘速度并提升效率。

全流程自动化： Nova 能够处理从简历筛选、联系候选人（通过 InMail、邮件、电话）到进行全面的语音/视频面试，甚至执行高级编码测试，直至提供详细的、可直接用于决策的报告。
高度「人性化」体验： Nova 被设计成「最佳招聘官和面试官的数字孪生」，能够模拟自然的暂停、语气和「嗯」等语用标记，提供友好的、类似真人的互动体验，候选人对其评价很高。
定制化与智能化： 用户可以根据自己的需求定制 Nova 的面试风格，包括技能深度、难度、面试类型、语调和结构。Nova 还能从公司过往的招聘数据（职位描述、面试记录、ATS 笔记等）中学习，提升其判断能力。
显著提升效率： Nova 帮助客户将第一轮面试报告的完成时间从 4-5 周缩短到 48 小时以内，为招聘团队节省了大量时间，使其能专注于更具战略意义的工作。
覆盖多渠道招聘： Nova 不仅处理入站（inbound）和内推（referral）的候选人，还能主动进行外呼（outbound）候选人搜寻和联系。
Nova 产品已上线，用户可通过 Peopleboxai 官网了解更多信息并申请试用。

(@Y Combinator Launches)

2、理想汽车发布首款 AI 眼镜 Livis：标配蔡司镜片 补贴后售价 1699 元起

12 月 3 日，理想汽车举办线上发布会，正式推出其首款 AI 智能眼镜 Livis。售价 1999 元起，12 月 31 日前下订可享受 15% 政府补贴，补贴后价格仅为 1699 元起。

「一款以钢铁侠 AI 管家「贾维斯」为灵感命名的智能眼镜，试图将「理想同学」的 AI 能力从驾驶空间延伸至用户日常生活的每个角落。」

Livis 名称源于理想汽车与钢铁侠 AI 管家「Jarvis」的组合。

整机重量控制在 36 克，提供经典黑、科技灰和橄榄绿三种颜色，并可选亮光或磨砂材质。

Livis 全系产品标配蔡司镜片，涵盖近视镜片、光致变色镜片与墨镜片等多种类型，满足用户在不同场景下的视觉需求。

理想宣称 Livis 在研发过程中实现了五项关键突破，构成了产品核心竞争力的重要组成部分。

典型续航时间达 18.8 小时。Livis 标配类似 AirPods 的无线充电盒，便于随身携带和补能。同时，眼镜支持与理想汽车的车机系统无线快充，上车后放置在专属充电位进行充电。

在硬件配置上，Livis 搭载恒玄 BES2800 主控芯片和独立的 ISP 成像芯片，采用 SONY IMX681 摄像头，拥有 1200 万像素、支持 4K 照片以及电子防抖拍摄。

汽车联动场景是 Livis 最独特的卖点。通过蓝牙和 5G 网络，眼镜可无缝连接车辆，实现语音远程控车。用户可在百米范围内，通过语音指令操控电动侧滑门启闭、提前开启空调及座椅加热，甚至检查车辆续航和充电状态。

（@极客公园、@快科技）

3、豆包手机助手无法登录微信，双方回应

日前，字节跳动豆包团队与中兴合作发布了豆包手机助手技术预览版后，有试用 Nubia M153 工程样机的用户反馈，出现无法正常登陆微信的情况。

对于相关情况，豆包团队方面昨晚发文并做出回应。

豆包方面表示，其后续已下线了手机助手操作微信的能力。 目前，nubia M153 上被禁止登录的微信账号正陆续解封。

而微信相关人士也通过澎湃新闻回应，豆包手机助手无法正常登陆微信的微信并没有什么特别动作，「可能是中了本来就有的安全风控措施。」

针对此前曾有科技公司爆料「豆包手机助手存在侵犯用户隐私」的问题，团队方面强调，豆包手机助手不存在任何黑客行为。

据悉，此前上述公司曾表示豆包手机助手在努比亚手机上拥有 INJECT\_EVENTS 权限，该权限在安卓权限定义中属于操作系统高危权限，并且拿到该权限，要面临刑事责任。

豆包方面表示，INJECT\_EVENTS 确实是系统级权限，但拥有了该权限许可，相关产品才能跨屏、跨应用来模拟点击事件，完成用户操作手机的任务需求。

团队还强调，豆包手机助手需要用户主动授权，才可以调用该权限，使用操作手机功能。该权限的使用，豆包方面也在权限清单中进行了明确的披露。据了解，目前行业的 AI 助手，均需要使用该权限（或与其类似的无障碍权限）才能提供操作手机的服务。

豆包方面强烈表示，豆包手机助手也不会代替用户进行相关授权和敏感操作。

同时，豆包方面也对读取屏幕的隐私问题进行了回应。其表示，助手操作手机时需要读取屏幕（否则无法完成任务），但屏幕和操作过程都不会在服务器端留下存储，且所有的相关内容也都不会进入模型训练，确保用户隐私安全。

( @APPSO)

4、健康追踪应用 Healthify Ria 升级 AI 助手：支持实时语音与摄像头交互

健康追踪初创公司 Healthify 推出了其 AI 助手 Ria 的新版本，该版本支持通过语音和摄像头进行实时对话，并能理解超过 50 种语言（包括 14 种印度语言）以及混合语言输入。此举旨在通过更自然的交互方式，提升用户健康习惯养成的效率和用户粘性。

实时对话与多模态输入： Ria 现在支持通过语音进行实时对话，用户还可以通过摄像头扫描食物获取营养信息并进行记录，大幅简化了数据录入流程。
多语言与混合语言支持： Ria 能够理解超过 50 种语言，并支持 Hinglish、Spanglish 等混合语言输入，服务全球用户。
整合多源健康数据： Ria 可以整合来自健身追踪器、睡眠追踪器、血糖监测仪等设备的数据，为用户提供运动、睡眠、身体准备度和血糖波动等方面的洞察，并给出建议。
增强记忆与个性化： Healthify 正在为 Ria 构建一个更持久的记忆层，使其能够记住用户的偏好和健康变化，提供更个性化的建议。
教练与营养师辅助： Ria 将被整合到用户与教练、营养师的沟通中，协助双方快速调取数据、回答问题，并可转录通话内容，提取关键信息。
(@TechCrunch)

03 有态度的观点
1、《阿凡达》导演：对 AI 没意见，但要尊敬演员们

近日，导演詹姆斯·卡梅隆在《阿凡达 3》世界首映礼上称该片没有使用 AI 生成，随后他对 ComicBookcom 发表了自己对于生成式 AI 的应用看法。

卡梅隆表示，自己对生成式 AI 没有意见，但他强调：「我们拍《阿凡达》电影不使用它，我们尊敬并赞颂演员们，我们不用 AI 代替演员。」

同时，卡梅隆也表示，「这件事（生成式 AI）自会有方向，我想好莱坞会进行自我监管，但我们作为艺术家要找到出路，前提是我们得能存在。所以，比起别的东西，来自『大 AI』的生存威胁是最让我担忧的。」

值得一提的是，卡梅隆所提到的「大 AI」，是指人类利用 AI 的状况和其产生的问题，对应的「小 AI」是指更细节、技术性的层面，比如用 AI 生成内容。

在卡梅隆看来，AI 和人类未来有深切的担忧和存在危机，他认为「小 AI」各行业会找到应对和利用之法，但「大 AI」问题就不好说了。

卡梅隆还提到，若了解 AI，就会知道「校准」是个重大问题。「AI 必须被训练、教导，必须被约束去只做对人类好的事情。」其强调，「只有我们人类达成了共识，你才能对 AI 进行校准。」实打weibo.com/ttarticle/p/show?id=2309405262389015871769 weibo.com/ttarticle/p/show?id=2309405262389334638732 weibo.com/ttarticle/p/show?id=2309405262389645017358 weibo.com/ttarticle/p/show?id=2309405262389959590025 weibo.com/ttarticle/p/show?id=2309405262390265774651 weibo.com/ttarticle/p/show?id=2309405262390672884003 weibo.com/ttarticle/p/show?id=2309405262390991650860 weibo.com/ttarticle/p/show?id=2309405262391305961616 weibo.com/ttarticle/p/show?id=2309405262391620534563 实

两个月前，我们一位客户的 Redis 实例在业务高峰期内存突增至 100%，导致 API 接口频繁返回 500 错误，用户无法下单，公司因此每分钟都在遭受直接经济损失。

令人费解的是，客户原以为配置已尽善尽美：所有 Key 均设置了过期时间（TTL），启用了逐出策略（Eviction Policy），并且实施了 24 小时不间断的内存监控。一切看似万无一失，直到故障发生。

事后复盘揭示，我们陷入了一个常见的 Redis 反模式陷阱。而讽刺的是，这一问题早已在官方文档中明确指出。不少工程师在读文档时深以为然，却在生产环境中全然遗忘。今天将分享这段极具价值的经验，剖析事件的来龙去脉。

拖垮系统的 Key 模式

当时，客户的缓存 Key 是这样设计的：

# 错误示范 1：缓存用户会话def cache_user_session(user_id, timestamp):# 将时间戳直接拼接到 Key 中
    key = f"session:{user_id}:{timestamp}"
    redis.set(key, session_data, ex=3600)# 错误示范 2：缓存 API 响应def cache_api_response(endpoint, params, request_id):# 将请求 ID 拼接到 Key 中
    key = f"api:{endpoint}:{params}:{request_id}"
    redis.set(key, response_data, ex=300)

问题出在哪里？

客户在 Key 中直接包含了时间戳（Timestamp）和唯一请求 ID（Request ID），这导致每次请求都会生成全新的 Key。尽管设置了 TTL（ex=3600），但忽视了 Redis 底层处理过期数据的机制。
这种情况被称为 “Key 泄露” 或 “Key 爆炸”，是导致 Redis 内存异常膨胀的主要原因之一。

为什么 TTL 没能奏效
Redis 对过期 Key 的处理并非实时且精确，主要依赖两种机制：

• 惰性删除（Passive Expiration）： 仅在访问某个 Key 时，若发现其已过期，Redis 才会将其删除并返回空值。若该 Key 从未再次被访问，它将一直占据内存。
• 定期删除（Active Expiration）： Redis 每秒执行 10 次随机抽样，从已设置 TTL 的 Key 中随机选取 20 个进行检查；若发现超过 25% 已过期，则重复该过程。

问题在于： 当新 Key 的生成速度远超 Redis 清理旧 Key 的速度时，内存中将堆积大量“逻辑上已过期但物理上未删除”的数据垃圾。
在本案例中，高峰期每分钟约生成 50,000 个新 Key。即便设置了 5 分钟的过期时间，任意时刻 Redis 中可能堆积多达 25 万个 Key，其中绝大多数早已应被清除。

被忽略的元数据开销
即便是一个简单的字符串 Key，在 Redis 中也存在额外开销。一个键值对的内存消耗包括：

• Key 本身： 字符串长度加上结构体开销（例如一个 32 字符的 Key 约占用 90 字节）。
• Value 及其包装： 数据本身大小加上 Redis Object 对象头。
• 元数据： 包括过期时间、编码方式、引用计数等信息。

这意味着，即使 Value 只有 100 字节，在 Redis 中的实际占用可能接近 200 字节。

举例计算： 25 万个 Key 的元数据就可消耗近 50MB 内存。虽然看似不多，但当 Key 数量达到千万级，元数据就可能占用数 GB。客户曾为 Redis 分配 16GB 内存，原以为存 8GB 数据绰绰有余，结果完全忽略了底层开销。

Big Key 问题
在排查过程中，我们还发现了 Big Key 问题。在 Redis 中，超过 1MB 的字符串或元素数量过万的集合都会被视为 Big Key。
此前为了省事，我们将整个 API 响应体，甚至复杂的用户画像对象，直接全部存入：

# 错误示范def cache_full_user_profile(user_id):# 获取用户的所有数据并打包成一个巨大的 JSON
    user_data = {'profile': get_profile(user_id),'preferences': get_prefs(user_id),  
        'order_history': get_history(user_id), # 这个列表可能无限增长'recommendations': get_recs(user_id)}# 一个 Key 存了 5MB 数据
    redis.set(f"user:{user_id}", json.dumps(user_data), ex=3600)

一个 5MB 的 Key 会导致 Redis 在进行内存回收（Eviction）或主从同步时产生阻塞，严重拖慢性能。

逐出策略的坑
屋漏偏逢连夜雨，当时客户将逐出策略设为 volatile-lru。该策略的逻辑是：在已设置 TTL 的 Key 中，淘汰最近最少使用的（LRU）。看似合理，实则不然。

由于每个请求都会生成新 Key，这些 Key 一经创建便被写入 Redis。对 Redis 而言，它们全是“新”的，没有一个是“旧”的。在这种“全是新 Key”的场景下，LRU 完全失效，Redis 无法有效判断淘汰对象，最终只能拒绝写入，导致 API 报错。

该怎么做
理解了病根，药方也就清晰了：
移除键名中的动态数据
不再把时间戳或请求 ID 塞进 Key。如果数据需要更新，直接覆盖原来的 Key。
Python

# 优化后：固定 Key 格式
key = f"session:{user_id}" 

# 对于需要区分参数的 API 缓存，使用哈希（Hash）处理
import hashlib
# 对参数进行排序并取哈希值，确保 key 的唯一性和长度固定
params_str = json.dumps(query_params, sort_keys=True).encode()
params_hash = hashlib.md5(params_str).hexdigest()
key = f"api_cache:{endpoint}:{params_hash}"

化整为零，拆分大 Key
利用 Redis 的 Hash（哈希表） 结构来存储相关联的字段，比存一个巨大的 JSON 字符串要省得多。
Python

# 使用 Hash 结构存储，内存更高效
redis.hset(f"user_data:{user_id}", mapping={
    'profile': json.dumps(profile_info),
    'settings': json.dumps(user_settings),
    'order_ids': json.dumps(recent_orders)
})

修正逐出策略
将策略改为 allkeys-lru，并调整了内存限制。
Bash

# redis.conf 核心配置
maxmemory 14gb  # 建议设置为物理内存的 80%-85%
maxmemory-policy allkeys-lru # 对所有 Key 启用 LRU 剔除
maxmemory-samples 5 # 采样数，5 是性能与准确度的平衡点

插曲：整数溢出 Bug
令人意外的是，我们帮客户处理问题时，还发现了一个因代码逻辑导致的 TTL 永不过期问题。
在计算过期时间时，采用了“当前时间戳 + 过期秒数”的方式，但在某个旧模块中，该计算使用了 32 位整数。当时间戳过大溢出为负数时，Redis 的 EXPIRE 命令会失效，使这些 Key 变成永不过期的“僵尸 Key”。
教训： TTL 应始终传相对秒数（如 3600），切勿传绝对时间戳。

总结与优化效果
实施上述改动后，系统性能得到显著提升：

• 内存占用： 从 98% 且频繁 OOM 降至稳定的 45%
• Key 数量： 从 1200 万骤减至 28 万
• P99 延迟： 从 850ms 降低到 120ms
• 成本： 原计划升级至 64GB 实例，如今 16GB 即可高效运行

💡 Redis 健康检查建议
不要等到报错才排查，立即运行以下命令对 Redis 展开自检：

1. INFO memory：查看内存碎片率（Fragmentation Ratio），超过 1.5 表示浪费严重
2. redis-cli --bigkeys：快速定位影响性能的大键
3. INFO keyspace：查看带 TTL 的 Key 占比，比例过低需警惕 Key 泄露

你会为 Redis 的 Key 添加时间戳或 UUID 吗？欢迎在评论区分享你的 Redis 排坑经验。

在大模型离线推理的工业级部署场景中，密集模型算力需求爆炸（70B 模型单卡离线推理吞吐量不足 1 token/s）、稀疏化精度损失不可控（非结构化稀疏精度暴跌 10% 以上）、稀疏算子硬件适配性差（稀疏计算访存瓶颈导致加速比低于 1.5 倍）是三大核心痛点。本次分享基于 MindSpore 的结构化稀疏剪枝与AOT 离线编译能力，构建 “分层结构化剪枝 + 稀疏 - 量化协同优化 + 硬件感知的离线推理编译” 三位一体方案，实现 70B 模型体积压缩 70%、离线推理吞吐量提升 8 倍，精度损失控制在 1.5% 以内，同时通过稀疏算子融合消除访存瓶颈，附全流程稀疏训练、编译优化与性能验证代码。

1. 分层结构化稀疏剪枝：注意力头 + FFN 通道的精细化稀疏策略

场景：传统非结构化稀疏（随机剪枝权重）会破坏模型的结构化特征，导致精度损失大，且硬件无法有效利用稀疏性（访存模式混乱）；通用结构化稀疏采用 “一刀切” 剪枝比例，忽略了 Transformer 不同层的重要性差异（底层语义层对稀疏更敏感，上层任务层稀疏容忍度高）。

MindSpore 技术实践：

基于 MindSpore 的Pruner剪枝工具与自定义稀疏评估指标，实现分层结构化稀疏—— 对 Transformer 底层（0-10 层）采用低稀疏度（10%）的注意力头剪枝，中层（11-30 层）采用中等稀疏度（30%）的 FFN 通道剪枝，上层（31-60 层）采用高稀疏度（50%）的注意力头 + FFN 联合剪枝；同时设计稀疏敏感度评估函数，保留对任务精度贡献大的核心结构，避免无效剪枝：

import mindspore as ms
import mindspore.nn as nn
import mindspore.ops as ops
from mindspore.compression import Pruner, FilterPruner, ChannelPruner

ms.set_context(mode=ms.GRAPH_MODE, device_target="Ascend")

# 1. 稀疏敏感度评估：计算各层对精度的贡献权重
class SparseSensitivityEvaluator(nn.Cell):
    def __init__(self, model, val_dataset):
        super().__init__()
        self.model = model
        self.val_dataset = val_dataset
        self.grad_op = ops.GradOperation(get_all=True)

    def evaluate_layer_importance(self):
        layer_importance = {}
        for name, cell in self.model.transformer.layers.cells_and_names():
            # 冻结其他层，仅当前层参与梯度计算
            for n, c in self.model.transformer.layers.cells_and_names():
                c.requires_grad = (n == name)
            # 计算当前层权重梯度的L2范数（范数越大，层越重要）
            total_norm = 0.0
            for x, label in self.val_dataset.take(100):
                logits = self.model(x)
                loss = nn.CrossEntropyLoss()(logits, label)
                grads = self.grad_op(self.model)(x)
                layer_grad = [g for n, g in zip(self.model.trainable_params(), grads) if name in n][0]
                total_norm += ops.norm(layer_grad, p=2)
            layer_importance[name] = total_norm.asnumpy() / 100
        return layer_importance

# 2. 分层结构化剪枝配置
def get_layer_wise_pruner(model, layer_importance):
    pruners = []
    for name, cell in model.transformer.layers.cells_and_names():
        importance = layer_importance[name]
        layer_idx = int(name.split(".")[-1])
        # 底层（0-10）：低稀疏度注意力头剪枝（10%）
        if layer_idx <= 10:
            head_pruner = Pruner(
                pruning_strategy="structured",
                pruning_granularity="head",  # 按注意力头剪枝
                pruning_rate=0.1 * (1 - importance / max(layer_importance.values()))
            )
            pruners.append((cell.self_attn, head_pruner))
        # 中层（11-30）：中等稀疏度FFN通道剪枝（30%）
        elif 11 <= layer_idx <= 30:
            channel_pruner = ChannelPruner(
                pruning_rate=0.3 * (1 - importance / max(layer_importance.values())),
                pruning_dim=1  # 按FFN输出通道剪枝
            )
            pruners.append((cell.ffn, channel_pruner))
        # 上层（31-60）：高稀疏度联合剪枝（50%）
        else:
            head_pruner = Pruner(pruning_strategy="structured", pruning_granularity="head", pruning_rate=0.5)
            channel_pruner = ChannelPruner(pruning_rate=0.5, pruning_dim=1)
            pruners.append((cell.self_attn, head_pruner))
            pruners.append((cell.ffn, channel_pruner))
    return pruners

# 3. 稀疏模型训练+蒸馏精度补偿
class SparseDistillLoss(nn.Cell):
    def __init__(self, teacher_model, temp=2.0):
        super().__init__()
        self.teacher = teacher_model
        self.teacher.set_train(False)
        self.temp = temp
        self.ce_loss = nn.CrossEntropyLoss()
        self.kl_loss = nn.KLDivLoss(reduction="batchmean")

    def construct(self, student_logits, labels, input_ids):
        teacher_logits = self.teacher(input_ids)
        ce = self.ce_loss(student_logits, labels)
        kl = self.kl_loss(
            ops.log_softmax(student_logits / self.temp, axis=-1),
            ops.softmax(teacher_logits / self.temp, axis=-1)
        ) * (self.temp ** 2)
        return ce + 0.4 * kl

# 稀疏训练流程
def sparse_train(model, teacher_model, train_dataset, val_dataset):
    # 1. 评估层重要性
    evaluator = SparseSensitivityEvaluator(model, val_dataset)
    layer_importance = evaluator.evaluate_layer_importance()
    # 2. 应用分层剪枝
    pruners = get_layer_wise_pruner(model, layer_importance)
    for cell, pruner in pruners:
        pruner.prune(cell)
    # 3. 蒸馏补偿训练
    loss_fn = SparseDistillLoss(teacher_model)
    optimizer = nn.AdamW(model.trainable_params(), lr=1e-5)
    for epoch in range(8):
        for x, label in train_dataset.batch(8):
            logits = model(x)
            loss = loss_fn(logits, label, x)
            loss.backward()
            optimizer.step()
            optimizer.clear_grad()
    return model

# 效果：70B模型结构化稀疏后体积压缩55%，精度损失仅0.8%；相比非结构化稀疏，硬件加速比从1.2倍提升至4.5倍

2. 稀疏 - 量化协同优化 + AOT 离线编译：消除稀疏推理的访存瓶颈

场景：单纯的结构化稀疏虽能降低计算量，但稀疏张量的不规则内存访问会引发访存瓶颈（稀疏计算访存耗时占比超 60%）；且稀疏模型的离线编译未针对稀疏算子做优化，导致推理效率提升不明显。

MindSpore 技术实践：

构建稀疏 - 量化协同优化策略 —— 在结构化稀疏的基础上，对剪枝后的模型做 4bit 量化，进一步压缩模型体积与访存带宽；基于 MindSpore 的 AOT 离线编译，对稀疏算子（如稀疏 MatMul、稀疏 Add）做编译时融合与内存布局优化，将稀疏计算的访存耗时占比降至 15%；同时通过稀疏张量的连续内存对齐，提升硬件缓存命中率：

from mindspore import export, aot_compile
from mindspore.compression import QuantizationAwareTraining
from mindspore.graph_kernel import set_graph_kernel_flags

# 1. 稀疏-量化协同优化：稀疏模型的4bit量化
def sparse_quant_co_opt(model):
    # 量化配置：仅对非剪枝部分做量化，剪枝部分直接置零
    quant_config = QuantizationAwareTraining(
        quant_dtype=ms.int4,
        per_channel=True,
        quant_delay=0  # 稀疏后直接量化
    )
    # 对稀疏模型应用量化
    for name, cell in model.transformer.layers.cells_and_names():
        if hasattr(cell, "pruned"):  # 仅对剪枝后的层做量化
            quant_config.quantize(cell)
    return model

# 2. 稀疏算子的AOT离线编译优化
def aot_compile_sparse_model(model, export_path):
    # 配置图算融合：融合稀疏MatMul+Quant+Dequant算子
    set_graph_kernel_flags(
        enable=True,
        fuse_ops=["SparseMatMul", "Quant", "Dequant"],
        fuse_level="O4",
        memory_optimize=True,
        cache_line_align=True  # 稀疏张量内存64字节对齐
    )
    # 导出稀疏模型为MindIR
    input_tensor = ms.Tensor(shape=[1, 1024], dtype=ms.int32)
    export(model, input_tensor, file_name=export_path, file_format="MINDIR")
    # AOT离线编译：生成Ascend硬件原生的稀疏算子执行码
    aot_config = {
        "target": "ascend910b",
        "compile_options": {
            "sparse_opt": True,  # 启用稀疏计算优化
            "opt_level": "O3",
            "sparse_threshold": 0.5  # 稀疏度>50%时启用稀疏算子
        }
    }
    aot_compile(input_path=f"{export_path}.mindir", output_path=f"{export_path}_aot", **aot_config)

# 3. 稀疏量化模型的离线推理
def sparse_offline_infer(aot_model_path, input_ids):
    # 加载AOT编译后的稀疏模型
    sparse_model = ms.load(aot_model_path)
    # 稀疏推理：自动调用硬件稀疏算子
    logits = sparse_model(input_ids)
    return ops.argmax(logits, axis=-1)

# 效果：稀疏-量化协同优化后模型体积再压缩30%（总压缩比70%），访存耗时占比从62%降至12%，离线推理吞吐量提升至4.2 tokens/s

3. 稀疏推理性能校准：动态稀疏度调整与性能瓶颈定位

场景：固定稀疏度无法适配不同硬件的算力特性（如 GPU 更适合高稀疏度，Ascend 更适合中等稀疏度），且稀疏推理的性能瓶颈难以精准定位，导致无法进一步优化。

MindSpore 技术实践：

基于 MindSpore 的Profiler性能分析工具，实现稀疏推理性能校准——① 量化各稀疏算子的计算 / 访存耗时占比，定位性能瓶颈；② 构建 “稀疏度 - 吞吐量 - 精度” 的三元模型，动态调整各层稀疏度，平衡硬件适配性与精度；③ 对瓶颈算子做针对性优化（如稀疏 MatMul 的分块大小调整）：

from mindspore.profiler import Profiler

# 1. 稀疏推理性能瓶颈定位
def profile_sparse_infer(model, input_ids, profile_path):
    profiler = Profiler(output_path=profile_path, is_detail=True)
    # 运行稀疏推理
    for _ in range(100):
        model(input_ids)
    profiler.analyse()
    # 解析性能报告：提取稀疏算子耗时
    with open(f"{profile_path}/operator_time.csv", "r") as f:
        lines = f.readlines()
        for line in lines[1:]:
            op_name, duration = line.split(",")[0], float(line.split(",")[2])
            if "Sparse" in op_name:
                print(f"Sparse Operator {op_name}: {duration:.2f}ms")

# 2. 稀疏度动态调整：基于三元模型的优化
class SparseTuningOptimizer:
    def __init__(self, model, val_dataset, hardware_type="ascend"):
        self.model = model
        self.val_dataset = val_dataset
        self.hardware_type = hardware_type

    def build_sparsity_model(self, sparsity_range=[0.1, 0.6]):
        # 遍历稀疏度范围，记录吞吐量与精度
        sparsity_list = []
        throughput_list = []
        accuracy_list = []
        for sparsity in sparsity_range:
            # 调整模型稀疏度
            for _, (cell, pruner) in enumerate(get_layer_wise_pruner(self.model, {k: sparsity for k in layer_importance.keys()})):
                pruner.set_pruning_rate(sparsity)
                pruner.prune(cell)
            # 测试精度
            acc = self.eval_accuracy(self.model, self.val_dataset)
            # 测试吞吐量
            throughput = self.test_throughput(self.model, input_ids)
            # 记录数据
            sparsity_list.append(sparsity)
            throughput_list.append(throughput)
            accuracy_list.append(acc)
        return sparsity_list, throughput_list, accuracy_list

    def tune_sparsity(self):
        # 构建三元模型，选择最优稀疏度（吞吐量最高且精度损失<1.5%）
        sparsity, throughput, accuracy = self.build_sparsity_model()
        best_sparsity = sparsity[0]
        max_throughput = throughput[0]
        for s, t, a in zip(sparsity, throughput, accuracy):
            if t > max_throughput and (accuracy[0] - a) < 0.015:
                max_throughput = t
                best_sparsity = s
        return best_sparsity

AI 时代的游戏小团队，真正卡住的不是“写不出来”，而是“对不齐”

上个月我在一个小团队群里看到一句话，很扎心：

“我们现在有三条 AI 产线：生图很快、生视频也能跑、AI 编程更不用说。但做出来的东西像三家外包拼的——互相不认识。”

这其实是 2026 年游戏开发的新常态：你不缺产能，你缺的是对齐。更准确点说，你缺一个能让“Agent Team”一起工作的共同底座。

你可以让一个 AI 画角色概念，让另一个 AI 出动作分镜，让第三个 AI 写战斗代码。问题是，它们之间没有共享的“单一真相来源”。每个智能体都很能干，但各干各的，最后你得靠人肉把它们拧到一条线上。

这篇文章想把问题说透一点：在 agent 编排成为默认工作流之后，AI 生图、AI 生视频、AI 编程三者的割裂，正在把小团队最宝贵的效率吃掉。而把 GDD 做成“可版本管理、可被 AI agent 消费”的规格资产，反而成了最稳的抓手。

01. Agent Team 时代：你以为你缺的是人，其实你缺的是“合同”

以前我们说“小团队缺人”，意思是缺美术、缺策划、缺程序。现在你会发现，“人”可以被很多 AI 角色补上：概念设计 agent、分镜与预演 agent、关卡草案 agent、代码实现 agent、测试生成 agent……看起来像是白捡了一个 20 人团队。

但很快你就会撞墙。

因为 agent 的协作方式不是开会，它们不会自然对齐；更糟的是，它们会很自信地补齐你没写明白的部分。于是你看到的不是“少人也能做”，而是“产出更多，返工更猛”。

割裂的表现特别具体：

• 生图给了你“看起来很对”的氛围，但没有告诉代码资源如何组织、哪些状态需要哪些动作、哪些 UI 是可交互的。
• 生视频（预演/动效）能把镜头语言和节奏铺出来，但它默认了一套玩法规则和交互反馈，你的程序端未必做得出来，或者做出来成本爆炸。
• AI 编程最容易“合理扩展”：你要一个小功能，它顺手给你一个大框架。等你回过神来，你的美术、策划、视频预演都得去迁就它。

这一切的根源不是“AI 不够聪明”，而是“没有合同”。

在 agent team 里，GDD 的角色变了：它不再是给人看的长作文，而是给多角色智能体共同遵守的执行合同。没有合同，所有输出都是一次性的、临时的、不可复用的上下文。

02. 为什么是 GDD？因为它天然站在“策划-开发-资产”交汇点

很多人第一反应是：那就搞个知识库、搞个 Notion、搞个长 prompt 模板。

问题在于：这些东西大多数不可追溯、不可审查、不可复用。你很难回答一句简单的问题——“我们到底改了什么边界？”

游戏项目里最贵的不是写代码那几小时，而是边界变化带来的连锁反应：数值、动作、特效、UI、关卡、存档、测试用例、宣发视频，全都会被牵扯。

所以你需要的不是“更长的上下文”，而是一个能被版本管理的规格集合。GDD 正好卡在这个位置：

• 它能描述“做什么”和“不能做什么”
• 它能定义数据口径与验收标准
• 它能把资产命名、资源结构、表现规则写成统一约束
• 它能被 Git 管起来，变更能 diff、能 review、能回滚

但传统 GDD 又有老问题：太叙事、太非结构化、太难给机器消费。于是才有了 Open GDD 这种“Agent-first GDD”的写法：把 GDD 变成可引用的章节资产，里面尽量放机器可读的规格（JSON/YAML/Mermaid），并且每一章都能单独被智能体拉取、被引用。

03. “可版本管理 + 可被 agent 消费”，到底怎么解决割裂？

关键是两个词：可引用、可检查。

可引用：让三条 AI 产线看同一份东西

你给生图 agent 的不应该只是“画一个更酷的主角”，而是引用同一段规格：角色定位、体型比例、装备槽位、动作集合、伤害类型、UI 状态。它画的不是“美术灵感”，而是“对齐后的产物”。

你给生视频 agent 的也不应该只是“做一段 20 秒战斗预演”，而是引用同一段玩法循环：玩家输入 → 判定 → 反馈 → 资源结算 → 镜头与音效触发。它做的预演是可落地的，不会出现“画面里能做到、游戏里做不到”的尴尬。

你给 AI 编程 agent 的更应该引用明确约束：接口不许改、存档结构不许动、性能预算是多少、命名规范是什么、测试要覆盖哪些边界。

可检查：让“跑偏”变成能被抓出来的事情

很多团队用 AI 的痛点其实不是“它错”，而是“它错得很难被快速发现”。因为你没有一张对照表。

当规格写在 Open GDD 里，你审查的就不是“这段代码看起来顺不顺眼”，而是：

• 它有没有违反“禁止事项”
• 它有没有满足“验收口径”
• 它引用了哪几章，改动对应哪条约束

你把审查从主观争论变成客观对照，小团队的沟通成本会立刻下降。

04. 给一个小团队可直接照抄的工作流：一条需求，三种 agent 同步

假设你要加一个新武器“链刃”，同时要出概念图、动效预演、以及真实可玩的实现。典型的割裂是：图很帅、视频很燃、但代码实现出来手感不对，或者动作资源根本对不上判定。

用 Open GDD 的做法，你先动一件事：新增/修改一段规格（而不是先让三个 agent 开跑）。

你在 GDD 里补齐这些关键点（不用多，够用就行）：

• 武器定位：轻武器还是重武器？主打什么节奏？
• 输入与状态：哪些输入触发哪些动作？中断规则是什么？
• 判定：伤害窗口、命中框、位移、硬直、打断优先级
• 资产清单：需要哪些动作片段、哪些特效、命名与路径规则
• 技术约束：动画事件怎么发、数据怎么配、存档怎么记录

然后你把同一段链接发给三个 agent：

1）生图 agent：按“资产清单 + 角色比例 + 装备槽位”出概念图，不要自由加装备结构
2）生视频 agent：按“输入-状态-反馈”做 20 秒预演，镜头与特效要能对应到动作事件
3）AI 编程 agent：按“判定窗口 + 技术约束 + 数据结构”落地实现，并生成最小测试

这时候三者就不是“各自发挥”，而是在执行同一份合同。你要改链刃的节奏？改规格，diff 一出来，三条产线一起更新，不靠口头同步。

小团队最缺的就是这种“一处改动，多端同步”的能力。

05. 你不需要一上来写 13 章：先把止血点钉住

很多人对 GDD 反感，是因为它常常意味着“先写一堆文档再开工”。Agent-first 的思路恰好相反：先写能让智能体不跑偏的最小规格，让项目先稳住，再逐步补齐。

如果你现在就想把割裂问题压下去，我建议先从三类内容开始（真的不用多）：

• 游戏概览与核心循环：防止做着做着变品类
• 玩法与机制的硬规则：防止“感觉对”但细节全错
• 技术约束与接口边界：防止 AI 编程顺手重构全项目

Open GDD 的结构把它们拆成可引用章节，你可以在 prompt 里直接写“只允许引用这几章”，范围立刻变窄，输出会老实很多。

结尾：小团队的效率，不在于“跑得更快”，而在于“别跑散”

Agent team 会越来越普遍。AI 生图、生视频、AI 编程也只会越来越强。

但如果它们继续割裂，小团队得到的不是效率红利，而是更大的返工雪崩：你越能生产，越能把不一致放大。

把 GDD 做成可版本管理的规格资产，并且让它能被 agent 消费，是目前我见过最省心的“对齐底座”。它不花哨，甚至有点朴素，但它解决的是最硬的问题：边界、口径、以及变更的可追溯。

Open GDD 文档（中文）：https://opengdd.borninsea.com/zh/docs
模板仓库：https://github.com/wanghaisheng/GDDMarkdownTemplate

如果你愿意，我也想听一个更具体的问题：在你们团队里，三条 AI 产线的割裂最先出现在什么环节？是资源命名与引用、是玩法规则落地、还是预演与真实手感对不上？我可以把它反推成一段“最小可执行规格”，直接放进模板里当示例。

在当下恶意软件攻击频发的情形下，使用代码签名证书来保护代码安全已经成为每个软件开发商的基本认知。代码签名证书将保护软件代码的完整性，避免软件被非法篡改或植入恶意代码病毒，从而使得软件可以正常运行。那么如果软件缺少代码签名证书会怎么样呢？

一、缺少代码签名证书会怎么样？

1. “未知发布者”警告

缺少代码签名证书的软件，微软会发出警告，并伴有“未知发布者”提醒，杀毒软件也会进行拦截，产生危险提示警告，阻止用户使用及下载。显然这样的警告会警示用户，让其产生不信任，甚至放弃使用该程序。 

2.恶意软件攻击

缺少代码签名证书的软件，更容易遭受恶意软件攻击，被非法篡改或植入恶意代码病毒，从而给用户带来安全风险。

3.软件用户流失

在下载安装没有代码签名的软件时，用户会收到危险警告或遇到问题，这不仅会影响用户的使用体验，还会降低用户对软件的信任度，最终导致软件用户流失。
 

二、代码签名申请步骤

代码签名证书申请入口

打开JoySSL官网，注册账号时，填写注册码230790，获取技术支持跟大额优惠。

根据要求提交验证材料：
企业用户：营业执照、法人身份证明、企业电话验证。
个人开发者：身份证明、地址证明。

CA审核材料.
审核通过后，下载证书文件.
安装并使用证书

注意事项
私钥安全：私钥泄露可能导致证书被滥用，建议使用硬件安全模块（HSM）存储。
定期更新：证书到期前需重新申请，避免软件无法验证。
总结
代码签名证书是建立用户信任的关键工具。通过选择可靠CA、规范申请流程并严格管理私钥，可高效完成代码签名，提升软件安全性与可信度。