Saylo AI 伙伴

版本：1.0.6
适用：XIUNOX 1.1

Saylo AI 伙伴是一款面向 XIUNOX 的沉浸式 AI 角色陪伴插件，提供角色发现、连续对话、本地记忆、角色创作、动态、语音朗读与主题体验。插件可使用内置本地回复引擎，也可接入 OpenAI 兼容的 HTTPS 模型接口。

核心功能

• 角色发现：内置多位不同性格、场景和表达风格的 AI 角色。

• AI 对话：支持上下文消息、角色设定、记忆注入和消息长度限制。

• 本地记忆：聊天、记忆及自定义角色保存在当前浏览器 localStorage。

• 角色创作：用户可创建名称与简介自定义的本地角色。

• 语音体验：通过浏览器 TTS 朗读角色内容。

• 扩展模块：包含角色动态、灵感钱包和本地数据清理入口。

• 双引擎模式：远程模型未启用时使用本地引擎；启用后调用 OpenAI 兼容接口。

• 后台配置：可配置访问策略、功能开关、模型地址、API Key、模型名、超时和页面文案。

数据与隐私

• 聊天记录、个人记忆和自定义角色默认只保存在用户当前浏览器。

• 远程模型 API Key 只保存在服务端插件设置中，不会下发前端。

• 启用远程模型后，必要的对话上下文与用户选择保存的记忆会发送到配置的模型服务商。

• 使用远程模型前，请确认服务商的数据处理条款符合站点隐私要求。

安装

1. 将 wajxy_saylo 目录上传至 XIUNOX 的 plugin/ 目录。

2. 在后台安装并启用“Saylo AI 伙伴”。

3. 清理论坛 tmp/ 编译缓存。

4. 打开插件设置，选择是否允许游客并按需配置远程模型。

远程模型配置

• API Base URL：必须为 HTTPS 公网地址，例如 https://api.openai.com/v1。

• API Key：留空保存时保留原密钥。

• 模型名称：填写服务商支持的 OpenAI 兼容模型标识。

• 请求超时：可设置为 5–120 秒。

启用远程模型后，接口失败会返回明确错误，不会静默降级；未启用时使用内置本地角色引擎。

兼容性与安全

• 使用原生 JavaScript，不依赖 jQuery、Alpine.js 或 idiomorph。

• POST 请求带 CSRF 令牌，服务端执行 CSRF 校验。

• 动态 DOM 内容通过 textContent 等安全 API 写入。

• 安装与升级脚本使用 utf8mb4；升级脚本可重复执行。

• 支持 PHP 8+ 的错误模型，不依赖 @ 抑制错误。

卸载说明

卸载会删除 wajxy_saylo_usage 插件统计表和 wajxy_saylo 设置。浏览器中的本地聊天、记忆与自定义角色需要用户在前台“本地设置”中清理，或手动清除对应站点存储。

更新记录

1.0.6

• 完成结构、安全、Hook、缓存、前端与数据规范自检。

• 规范终止性 exit 防护。

• 强化脚本块 JSON 转义与 CSRF 表单语义。

• 为路由补充服务类显式加载。

• 新增自检清单与插件介绍文档。

2026 年 8 月 26 日，开源大模型推理框架 vLLM 发布 0.28.0 版本。此次更新包含 584 次提交，涉及 270 名贡献者，其中 76 名为首次参与者。最受关注的变化，是面向 Kimi-K3 推理链路加入自适应投机 Token 预算。官方称，该优化可使 DSpark 场景下的首 Token 延迟指标改善约 60%。需要特别说明的是，这一数字来自特定模型、投机解码方案和测试条件，并不代表所有模型部署升级后都能获得同等收益。[1] citeturn1view1turn1search7

为什么首 Token 延迟比平均吞吐量更直观

首 Token 延迟通常写作 TTFT，即从请求进入推理服务，到用户收到第一个输出 Token 所经历的时间。对于聊天机器人、代码助手和智能客服，用户首先感受到的往往不是整段文本每秒能生成多少 Token，而是点击发送后界面要等待多久才开始响应。因此，一个系统即使平均吞吐量很高，如果请求排队、预填充或投机调度耗时过长，交互体验仍会显得迟钝。

vLLM 0.28.0 所称的“约 60% 改善”，准确范围是 Kimi-K3 的 DSpark TTFT，由自适应投机 Token 预算带来。投机解码会先让草稿路径提出候选 Token，再由主模型验证。候选数量过少，难以充分减少主模型解码次数；候选数量过多，又会增加调度、计算和验证成本。自适应预算的重点，就是根据运行状态调整每轮允许处理的投机 Token 数量，而不是长期采用固定预算。对应实现可在官方合并记录中核验。[2] citeturn1view1

约 60% 改善不是单点加速的全部

如果只把此次更新理解成修改一个调度参数，就会低估 0.28.0 的优化范围。面向 Kimi-K3，vLLM 同时加入了解码上下文并行 DCP、融合式 FlashKDA 解码与预填充内核、MegaMoE 的 SiTU 激活支持，以及服务于序列并行的 GEMM-RS。其总体思路是同时压缩计算、通信、显存占用和调度等待，让首 Token 更早出现，并避免后续生成阶段被新的瓶颈抵消。官方发布说明 citeturn1view1

在多 GPU 推理中，集合通信经常成为大模型扩展效率的限制因素。0.28.0 对组合 all-gather 操作进行了优化，官方给出的数字是内核级速度提升 1.5 至 3 倍。这里同样不能直接换算为端到端推理速度，因为服务整体还受到模型结构、请求长度、批处理规模、网络拓扑和 GPU 利用率影响。不过，它说明优化路径已经从单纯追求算子计算速度，延伸到跨卡数据交换和并行执行效率。相关优化记录 citeturn1view1

显存和缓存优化同样影响响应时间

官方还表示，可选的 shared-expert 分片方案可在其目标配置中为每张 GPU 节省约 17 GiB 显存。对大型 MoE 模型而言，显存余量不仅决定模型能否加载，也会影响 KV Cache 容量、可容纳的并发请求数以及上下文长度。显存压力降低后，部署者可能获得更大的批处理空间，但实际收益仍需结合并行策略和模型配置测量。shared-expert 分片记录 citeturn1view1

0.28.0 还扩展了分层 KV Cache 卸载能力，包括磁盘卸载、可从树外加载的二级存储管理器、部分加载结果和分层指标。磁盘显然慢于 GPU 显存，因此它并不是无条件的低延迟方案，但在长上下文或显存紧张的服务中，可以用容量换取可运行性。合理做法是让高频数据保留在高速层，把低频缓存放入较慢层，并持续观察命中率和尾延迟。磁盘卸载实现 citeturn1view1

升级前应重点验证哪些指标

1. 区分 TTFT 与生成吞吐：分别记录首 Token 延迟、每输出 Token 延迟、端到端完成时间及每秒 Token 数，避免单一平均值掩盖问题。
2. 观察延迟分位数：除平均值外，至少比较 P50、P95 和 P99。线上用户更容易受到排队和长提示词造成的尾延迟影响。
3. 固定测试条件：保持模型权重、量化方式、输入长度、输出长度、并发量和 GPU 拓扑一致，再进行新旧版本对照。
4. 单独测试投机解码：分别关闭和启用 DSpark，判断收益究竟来自版本升级、投机策略，还是批处理与缓存变化。
5. 检查显存及通信：记录峰值显存、KV Cache 使用量、跨卡通信时间和失败请求，确认低延迟并非以稳定性下降为代价。

不能忽视的兼容性变化

此次版本还调整了多项默认值和依赖关系。例如，max_num_batched_tokens 默认值由 8192 提高到 16384，Mamba 模型默认启用前缀缓存，Blackwell 平台的 CUDA Graph 捕获默认上限提高到 1024。更大的批处理 Token 上限可能提升吞吐，但也可能改变排队、显存和尾延迟表现，因此不宜在生产环境直接沿用新默认值而不复测。版本变更清单 citeturn1view1

破坏性变化方面，bitsandbytes 支持已迁移到树外插件，Transformers 升级至 5.15.0，旧的 calculate_kv_scales 运行时 KV 缩放计算与 override_attention_dtype 均被移除。依赖这些能力的部署脚本、镜像和配置文件，应先在预发布环境完成兼容性检查。PyPI 页面已经将当前正式版本标记为 0.28.0，可用于交叉核验发布包，但性能结论仍应以官方发布说明和对应代码记录为准。PyPI 发布包 citeturn1search7

总结

vLLM 0.28.0 展示了一条较完整的推理优化路径：通过自适应投机预算减少无效调度和验证开销，通过融合内核提高计算效率，通过 DCP、GEMM-RS 与 all-gather 优化改善多卡并行，再通过 shared-expert 分片和分层 KV Cache 缓解显存压力。标题中的“首字延迟降低约 60%”应理解为官方针对 Kimi-K3 DSpark TTFT 给出的特定结果，而非通用性能承诺。对部署团队而言，最有价值的行动不是立即用这一数字估算容量，而是在自身模型、硬件和真实流量下建立可重复的基准测试，确认 TTFT、吞吐、尾延迟与资源成本是否同时改善。

事件或资料日期：vLLM 0.28.0 于 2026 年 8 月 26 日发布；本文资料核验日期为 2026 年 8 月 31 日。版本存在性与发布日期参考 PyPI 0.28.0 页面，性能数据、功能变化及兼容性说明参考 vLLM 官方 GitHub Release 和 自适应投机 Token 预算合并记录。约 60%、1.5 至 3 倍及约 17 GiB 均为项目方在对应场景中披露的数据，实际部署结果可能因软硬件配置而异。citeturn1view1turn1search7

豆瓣信息一键插入

插件标识： wajxy_douban
版本： 1.1.5
适用 BBS 版本： 1.1

插件简介

“豆瓣信息一键插入”为 XIUNOX 编辑器增加豆瓣条目按钮。用户输入豆瓣电影数字 ID 或完整条目链接后，插件由服务端读取条目资料，在帖子中插入短代码，并在正文格式化阶段渲染为响应式影视卡片。

主要功能

• 支持豆瓣数字 ID 和标准 movie.douban.com/subject/{ID}/ 链接。

• 展示片名、年份、评分、海报、导演、编剧、主演、类型、地区、语言、上映时间、片长及简介。

• 获取并展示热门短评；接口不可用时自动回退。

• 海报下载到本地缓存并通过同源路由输出，降低防盗链影响。

• 支持桌面端和移动端响应式卡片布局。

• 支持后台配置请求超时、缓存时长、简介长度、海报宽度和主演显示数量。

• 支持手动或定时读取“正在上映”列表，并按设置的板块和用户 UID 自动发布。

• 记录已发布豆瓣 ID，避免重复发布；可单独清理记录而不删除帖子。

安装与升级

1. 将 wajxy_douban 目录放入站点 plugin/ 目录。

2. 在后台安装并启用插件。

3. 进入插件设置，配置显示、缓存和自动发布选项。

4. 从旧版本升级到 1.1.5 后，清理站点 tmp/ 编译缓存，再刷新后台与前台页面。

插件当前不创建自有数据库表，配置和发布记录通过设置项保存。

使用方法

1. 打开发帖、回帖或编辑页面。

2. 点击编辑器工具栏中的豆瓣图标。

3. 输入豆瓣 ID，例如 36810153，或输入完整条目链接。

4. 点击“一键获取并插入”，保存帖子后即可看到完整卡片。

安全说明

• POST 设置请求包含 CSRF 令牌并在服务端校验。

• 豆瓣条目输入采用严格格式校验，远程海报仅允许来自 doubanio.com。

• 服务端渲染内容使用 HTML 转义；前端使用安全 DOM API，不使用 innerHTML 拼接用户输入。

• 自动发布功能仅允许有插件设置权限的后台用户操作。

v1.1.5 更新

• 按规范移除 Hook 文件中的裸 exit;。

• 将插件后台模板迁移至 overwrite/。

• 统一终止性 exit 的条件块与 ponytail: 注释。

• 将 CacheHelper::set() 改为 __v 哨兵格式，并兼容解包读取。

• 移除 PHP 错误抑制符，增加文件函数守卫。

• 更新静态资源版本并补充完整自检文档。

BiliPai 是一个基于 Jetpack Compose 和 Material Design 3 构建的第三方 B 站客户端，提供首页推荐、视频播放、账号登录（扫码/网页）、主题切换等核心功能。它支持高清播放、瀑布流浏览、动态配色、骨架屏加载、Lottie 动画等现代交互体验，只保留视频核心流程，简洁现代、性能优化。

【下载链接】：

先保存到网盘再下载，以防失效和被和谐，保存好，以后也能用得到

夸克链接：https://pan.quark.cn/s/2e1b3bf277fe

软件截图：

生成式人工智能的训练数据争议，正在从“模型是否学习了版权作品”进一步转向“作品如何取得、如何复制，以及模型能否还原作品”。2026年8月28日，索尼音乐出版、华纳查佩尔音乐及多家关联出版商在美国加州北区联邦地区法院起诉Anthropic及其两名联合创始人。原告指控Anthropic通过种子下载、网页抓取等方式获取大量受版权保护的音乐作品，并将其用于Claude模型训练。Anthropic则表示不同意相关指控，将在法庭上积极抗辩。案件目前仍处于诉讼初期，指控尚未获得法院认定。相关情况可参见Music Business Worldwide报道及TechCrunch报道。

争议对象不是笼统的“歌曲”，而是具体版权权利

讨论这起案件，首先需要区分音乐作品版权与录音制品版权。歌曲的歌词、旋律和乐谱通常属于音乐作品，而歌手演唱后形成的特定录音则可能构成另一项独立权利。本案原告主要是音乐出版商，公开报道所呈现的争议重点是歌词、乐谱等音乐作品，不应简单表述为Anthropic复制了唱片公司的全部录音。

原告称，Anthropic未经许可获取“数以万计”的作品，并在训练数据处理及模型输出过程中实施了多次复制。报道还显示，原告要求销毁被指控侵权的副本、披露训练数据，并主张故意侵犯版权及删除版权管理信息所对应的法定赔偿。具体作品数量、获取方式以及版权信息是否被系统删除，仍需经过证据开示和庭审核验，不能把诉状中的单方陈述直接当作法院结论。

侵权责任可能被拆分为三个环节

第一，训练材料的取得是否合法

如果训练材料来自正版购买、合法授权或开放许可，企业更有条件围绕合理使用展开抗辩。如果材料是通过盗版资源库或未经授权的下载渠道取得，那么下载和保存副本本身就可能形成独立的侵权行为。即使后续训练具有转化性，也不意味着此前的获取行为自动获得豁免。

这一区分在Anthropic此前涉及图书的诉讼中已经受到关注。TechCrunch在本次报道中指出，相关书籍案件曾区分“将作品用于模型训练”与“通过盗版方式取得作品”：前者可能进入合理使用分析，后者则可能单独产生责任。索尼与华纳此次显然试图把同样的逻辑延伸到歌词和乐谱领域，详见案件背景说明。

第二，训练过程中的复制能否构成合理使用

生成式AI训练通常需要将内容载入数据集、制作中间副本并进行模型计算，因此很难回避“是否发生复制”。但发生复制不等于必然承担最终侵权责任，法院还可能考察使用目的和性质、作品的创造性程度、使用数量及实质性，以及对现实或潜在授权市场的影响。

Anthropic可能强调，模型训练是统计建模而非向用户提供歌曲原件，训练目的具有转化性，模型参数也不等同于可阅读的歌词数据库。出版商则可能主张，歌词属于表达性很强的作品，训练往往需要使用作品的重要乃至全部内容，而且音乐行业已经存在成熟的歌词授权市场。若未经许可的训练替代了原本可以达成的商业授权，市场损害因素可能对AI企业不利。

第三，模型输出是否构成实质性相似

训练输入与模型输出应当分别判断。即使法院认为某种训练用途可以适用合理使用，如果Claude在特定提示下能够连续、近乎逐字地输出受保护歌词，相关输出仍可能构成新的复制或传播争议。责任判断将取决于输出长度、内容独创性、与原作相似程度、触发方式，以及平台在收到通知后是否采取有效限制措施。

对Anthropic而言，仅证明模型不会在普通对话中主动展示完整歌词可能还不够。企业还需要说明是否设置了歌词复现拦截、训练数据去重、记忆化测试和权利人投诉机制。对出版商而言，也不能只证明模型“知道”某首歌，而需证明输出复制了受版权保护的表达，而非仅涉及歌名、作者、发行时间等事实信息。

删除版权管理信息可能形成独立风险

公开报道显示，原告还指控训练数据处理过程中删除了作品标题、作者署名或版权声明等版权管理信息，并据此提出额外赔偿请求。Music Business Worldwide报道称，原告寻求每部被认定为故意侵权的作品最高15万美元法定赔偿，并针对每次被认定的版权管理信息删除行为主张最高2.5万美元，详见诉讼请求报道。

需要警惕的是，这些数字属于法律规定范围内的诉讼主张上限，并非已经确定的赔偿额。法院仍需判断原告是否拥有有效版权、每项作品是否实际被使用、侵权是否属于故意行为，以及版权管理信息是否被明知删除并与侵权活动存在法定联系。因此，将作品数量直接乘以最高赔偿标准，只能得到理论风险敞口，不能视为Anthropic必然承担的金额。

创始人被列为被告，不代表个人责任已经成立

诉状同时列入Anthropic首席执行官Dario Amodei和联合创始人Benjamin Mann。原告若要追究个人责任，通常需要证明相关人员直接参与、授权、控制或实质推动了被指控的行为，而不能仅以其创始人或高管身份自动归责。创始人是否了解数据来源、是否参与下载或批准数据策略，将可能成为证据开示的重要内容。被列为被告只是原告的诉讼安排，并不等于法院已经认定其个人侵权。

AI企业可以从案件中吸取哪些合规经验

• 建立来源台账：为训练数据保留来源、许可条件、获取时间、处理方法与供应商证明，避免只能证明“数据存在”，却无法证明“数据从何而来”。
• 分开评估取得与使用：不要把合理使用当作覆盖全部流程的通行证。下载、保存、训练、微调和输出可能分别触发不同责任。
• 保留版权元数据：数据清洗不应无差别删除作者、权利人和许可信息；如因技术需要转换字段，应保存可追溯映射。
• 开展记忆化测试：针对歌词、新闻、书籍等高表达性内容测试长文本复现，并设置输出长度限制、相似度检测和拒答策略。
• 准备授权方案：对于存在成熟许可市场的高价值数据，应优先考虑集体授权、曲库授权或按使用量结算，而不是完全依赖诉讼后的合理使用抗辩。

总结

这起诉讼真正要划定的，并不是“AI能不能学习歌曲”这样简单的二元界限，而是训练材料取得、内部复制、版权信息处理和模型输出各自应承担什么责任。案件最终可能出现分环节判断：某些训练用途具有合理使用空间，但盗版下载、保留未授权语料、删除版权管理信息或输出高度相似歌词，仍可能分别构成责任。对生成式AI行业而言，最现实的变化是训练数据合规将从一份原则声明，转变为可以逐项审计、提供证据并接受权利人核查的工程体系。

事件或资料日期：诉讼于2026年8月28日提交；Music Business Worldwide于2026年8月29日报道，参见[1]；TechCrunch于2026年8月29日报道并补充Anthropic回应，参见[2]。本文信息核验截止日期为2026年8月31日。

过去一周，大模型市场的更新节奏再次加快。根据 BenchLM 截至 2026 年 8 月 28 日整理的月度发布记录，8 月已有 24 个模型更新，涉及 18 家提供方；其中，8 月 24 日至 28 日新增或确认的项目包括 Qwen3.8-Flash-Next、GLM-5.3-Flash、腾讯 Hy4 preview、Ling-3.0-flash-Fin 和 Apodex 1.1 等。需要说明的是，BenchLM 在这里承担的是发布信息汇总与评测索引角色，并不是这些模型的开发方。[1]

8 月末更新呈现三条清晰路线

从最近 7 天的公开信息看，新模型已经不再单纯追求参数规模或通用榜单名次，而是沿着三条路线推进：第一是通过稀疏注意力和低激活参数降低推理成本；第二是增强长上下文、代码和办公任务能力；第三是针对金融等垂直领域进行专门训练。BenchLM 的月度记录提供了统一时间线，但模型规格、开放方式和性能声明仍应回到开发方资料核验。

Qwen3.8-Flash-Next：以新架构预演下一代模型

2026 年 8 月 26 日，Qwen 团队发布并开放 Qwen3.8-Flash-Next 权重。该模型是一款多模态 MoE 模型，也被官方定位为 Qwen4 架构的提前预览。其主体模型包含 125B 参数，另有 51B N-gram Embedding，每个 Token 激活约 6B 参数，原生上下文长度为 262,144 Token，并可通过 YaRN 扩展至 100 万 Token。[2][3]

这次更新的重点并非简单扩容，而是同时调整注意力、残差连接、嵌入和优化器。官方资料提到，模型采用 Gated DeltaNet 与 Qwen Sparse Attention 组合的混合架构，通过轻量级索引器筛选长上下文中的重要内容；Gated Residual 则把残差流扩展为四个分支。对开发者而言，这类设计的实际价值在于降低长文本处理成本，并为代码智能体、跨文档分析和多模态应用提供更大的上下文空间。不过，官方关于训练成本和能力提升的比较仍属于开发方测试结果，部署前应使用自己的任务集复测。

腾讯 Hy4 preview：从模型能力转向生产力交付

2026 年 8 月 28 日，腾讯发布并开源 Hy4 preview。腾讯公开资料显示，该模型拥有 770B 总参数、49B 激活参数和 100 万 Token 上下文窗口，重点覆盖长周期软件工程、跨文件办公、数据分析、游戏开发和科学研究。模型已经接入 WorkBuddy、CodeBuddy、元宝和 ima，并可通过腾讯云 TokenHub 等渠道调用。[4][5]

Hy4 preview 的发布方式值得关注：模型、API 与办公和编程产品同步上线，说明厂商正在把竞争焦点从“回答得更好”转向“能否完成较长的真实工作流”。腾讯披露的内部盲测覆盖 163 名专家和 203 个工程任务，Hy4 preview 平均得分为 2.99/4。由于这一结果来自腾讯内部评估，不能直接等同于独立第三方结论，但其任务设计思路具有参考价值，也就是用规划、调试、验证和最终交付评估模型，而不是只观察单轮问答准确率。

Ling-3.0-flash-Fin：垂直模型开始强调证据追溯

同在 2026 年 8 月 28 日，蚂蚁百灵推出金融增强模型 Ling-3.0-flash-Fin。公开报道显示，该模型延续 Ling-3.0-flash 的架构，保留 124B 总参数与 5.1B 激活参数，并通过金融语料持续预训练、领域后训练和工具调用优化，面向年报、财务工作簿、多份研究材料、估值建模及银行业务等场景。其 API 提供一个月限时免费体验，模型权重计划在随后一周开放。[6][7]

金融模型的关键不只是生成流畅报告，而是能否定位原始资料、保留计算过程并让结论可复核。Ling-3.0-flash-Fin 被用于 FinFIRST、FinSearchComp Verified、Finance Agent、SpreadsheetBench 等金融与智能体基准，但目前主要成绩仍来自发布方资料。对于金融机构，合理的验证方式应包括事实引用准确率、数字计算一致性、跨文件口径冲突处理、工具调用失败恢复以及敏感数据隔离，不能直接根据官方榜单进入生产环境。

开发者如何使用 BenchLM 的 8 月记录

• 先核对发布日期：BenchLM 可用于定位近期模型，但正式上线时间、权重状态和许可证应以开发方页面为准。
• 区分“发布”与“即将开源”：API 可调用不代表权重已经开放，尤其是 Ling-3.0-flash-Fin，目前公开报道表述为计划随后开源。
• 避免只看综合分：代码、办公、金融检索和长上下文任务的评价指标不同，应建立贴近自身业务的数据集。
• 记录成本与运行条件：总参数、激活参数、上下文长度和硬件占用共同决定部署成本，不能只根据模型规模判断效率。

总结

BenchLM 的 2026 年 8 月更新记录显示，大模型竞争正在从通用能力比拼转向架构效率、超长上下文、生产力工作流和垂直领域落地。Qwen3.8-Flash-Next强调下一代稀疏架构与低激活推理，Hy4 preview 聚焦代码、办公和科研任务的完整交付，Ling-3.0-flash-Fin 则把金融资料处理与证据追溯放到核心位置。对开发团队来说，8 月末真正值得关注的不是发布数量，而是模型是否开放、评测能否复现，以及在真实任务中的准确性、成本和稳定性。

事件与资料日期

• 资料更新至 2026 年 8 月 28 日：BenchLM 2026 年 8 月模型发布记录
• 事件日期 2026 年 8 月 26 日：Qwen3.8-Flash-Next 官方仓库、阿里云技术说明
• 事件日期 2026 年 8 月 28 日：腾讯 Hy4 preview 发布公告、腾讯混元技术页面
• 事件日期 2026 年 8 月 28 日：Ling-3.0-flash-Fin 发布报道、TechNode 交叉报道