随着开源之夏 2025 进入结项阶段，所有参与项目也迎来了最终检验。

官方数据显示，本届开源之夏共有 182 家开源社区、565 个项目任务，吸引了来自 450 所高校的 2290 名学生报名。最终，518 位学生中选，在经历三个月的项目开发和一个月的成果合入后，共有 437 位同学顺利通过导师、社区和组委会的多轮审核，成功结项。

值得高兴的是，在今年参与 TDengine 项目的两位同学中，两个项目均顺利完成结项。结项公示地址👉🏻 <span style="color: rgb(36,91,219); background-color: inherit">https://summer-ospp.ac.cn/final</span>

📌 项目详情链接：

• Prophet 模型集成任务：https://summer-ospp.ac.cn/org/prodetail/254290182?list=org\&navpage=org
• 逻辑备份与恢复任务：https://summer-ospp.ac.cn/org/prodetail/254290198?list=org\&navpage=org

其中，参与 「为 TDgpt 增加 Prophet 时序数据分析模型」 项目的梁炫栋，在结项基础上，进一步被评为开源之夏 2025 优秀学生，并获得「年度最佳质量奖」。

关于两位同学为何选择 TDengine、项目内容本身及前期规划，我们已在此前发布的《开源之夏项目全中选：TDengine 和两个“00后开发者”的暑期实战》文章中做过详细介绍。本篇将聚焦结项阶段，聊聊梁炫栋在三个月工程实践中，对“质量”“工程”“开源协作”的真实理解。一起来听听他的回答👇🏻

Q1：当你得知自己被评为「2025 优秀学生」，并获得「年度最佳质量奖」时，第一反应是什么？

第一反应是惊喜，随即感到非常荣幸。因为我知道每年的开源之夏里有很多优秀的开发者，竞争非常激烈。 获得「年度最佳质量奖」对我来说意义非凡，这是对我个人代码能力的认可。能收获这份奖项，我更要特别感谢我的导师廖浩均博士，感谢他一次次严格的把关和悉心的指导。

Q2：在你看来，一个“高质量的开源项目交付”，最核心的判断标准是什么？

我常常问自己一个问题：当我离开这个项目后，别人接手我的代码会不会很轻松？

在学校写作业，更多关注的是“能不能跑通”；但在开源社区，代码是写给人看的。所以我理解的高质量交付主要体现在三点：

• 代码要顺：逻辑清晰、符合规范，别人读代码像读文章一样，不需要反复猜测作者意图。
• 测试要全：不能只覆盖成功路径，异常、边界情况都要测到，尽量不把隐患留给后来的人。
• 文档要透：不仅告诉大家“怎么用”，也要解释“为什么这样设计”，避免给后续维护者挖坑。

Q3：在整个项目周期中，你在哪些地方花了最多“看不见但很重要”的时间？

最多的时间其实花在了排查测试报错和反复啃日志上。核心功能写出来并不慢，但让所有测试稳定通过非常难。面对复杂的报错信息，我需要一行一行分析 Log，反复复现问题，定位隐藏在深层逻辑里的漏洞。这个过程很少带来“新功能”的直观产出，但却是系统稳定性真正建立起来的关键。

Q4：相比项目初期的设想，真正做下来，哪一类工程难点超出了你的预期？

最超出预期的是系统对接。我发现让代码在本地跑通和让它真正融入 TDengine 的分布式环境完全是两个概念。为了解决接口协议的微小差异和上下文同步问题，我花费了大量精力去调试，这也让我深刻理解了工业级集成的复杂性。

Q5：你觉得自己在这三个月里，最大的变化是什么？

我觉得是工程思维的进阶。面对问题时，我不再靠不断盲目试错，而是养成了先通过日志和上下文分析定位根因的习惯；同时也更懂得如何和导师高效沟通，把问题描述清楚、把方案讨论清楚，一起推进问题解决。

Q6：在和 TDengine 导师、社区协作的过程中，有没有哪一次反馈或讨论，对你影响比较大？

最想感谢的还是我的导师廖浩均博士。他不仅教我怎么排查问题，更重要的是教我如何思考问题。整个 TDengine 社区也非常活跃、友好，遇到问题总能得到回应和讨论。在项目过程中，我从来没有“一个人硬扛”的感觉。

Q7：你希望自己这次的项目成果，在 TDengine 或社区中留下什么样的价值？

在具体成果上，我为 TDgpt 的时序预测模块集成了 Prophet 模型，让用户可以开箱即用地进行高质量的时序预测。更重要的是，如果未来 TDgpt 需要接入更多时序模型，我希望这套代码结构能够作为一个可复用、可扩展的工程范例，而不是一次性的实现。

Q8：如果有学弟学妹明年考虑报名 TDengine 的开源之夏项目，你最想提醒他们的一件事是什么？

不要害怕提问，也要尽早、高频地和导师沟通。与其自己在环境配置或细节问题里卡上三天，不如把问题整理清楚直接求助。你会发现，导师其实非常愿意引导你。

写在最后

从项目中选，到顺利结项，再到获得「年度最佳质量奖」，梁炫栋的这段开源之夏经历，体现的并不是“多快”，而是对工程质量的持续打磨。

也期待更多开发者，能在 TDengine 社区中，把一次次代码提交，变成长期可用、可演进的工程成果。

TDengine 开源地址：https://github.com/taosdata/TDengine

关于梁炫栋

北京师范大学人工智能创新实验班本科毕业生，现为中国科学院大学空间应用工程与技术中心博士研究生，研究方向聚焦于时间序列预测、异常检测与时序大模型。在认知神经工效学研究领域积累了丰富的科研经验，作为第一作者发表多篇 SCI 论文，曾获美国大学生数学建模竞赛 H 奖、蓝桥杯广东赛区三等奖等多项竞赛荣誉。

在量化交易开发场景中，trader-x 合约策略落地时的「数据延迟、回测繁琐、执行不精准」是高频痛点。作为深耕金融数据开发的技术团队，我们实测数十款量化工具后，最终选定 XTrader 作为核心落地工具 —— 其功能实用性与稳定性，恰好匹配机构级多资产量化交易的核心需求。本文从工具选型、策略编码、落地验证三个维度，拆解 XTrader 在 trader-x 合约量化中的实战应用。

一、XTrader：适配量化全流程的「实用派」工具
对量化开发者而言，工具的核心价值是打通「数据获取 - 策略验证 - 自动执行」闭环。XTrader 覆盖外汇、股票、加密货币等多资产类别，核心优势在于直击技术痛点，而非冗余的交互设计：

• 开放 API 接口支持自定义策略开发，无功能绑定限制；
• 内置实时行情采集与低延迟传输能力，适配高频交易需求；
• 一站式完成策略构思→回测→实盘执行，无需跨工具切换。

以下是 XTrader 核心功能与实际开发场景的对应关系：

二、trader-x 合约量化策略：3 类可直接落地的编码方案
trader-x 合约策略开发的核心逻辑，是通过数据建模弱化人为情绪干扰，而非追求复杂公式。结合 XTrader 的功能特性，以下 3 类策略具备高落地性，附完整可运行代码：

1.趋势跟踪策略：均线交叉信号实现
核心逻辑：以 50 日短期均线与 200 日长期均线交叉为信号，短期均线上穿则买入，下穿则卖出，聚焦中长期趋势过滤短期波动。

基于 AllTick API 的实时数据，实现代码如下：

import requests
def get_data(): 
    params = {'symbol': 'EURUSD'}
    url = "https://apis.alltick.co/market_data" 
    response = requests.get(url, params=params)
    return response.json()

def moving_average_strategy(data):
    short_window = 50
    long_window = 200
    short_ma = sum(data[-short_window:]) / short_window
    long_ma = sum(data[-long_window:]) / long_window
    if short_ma > long_ma:
        return "BUY"
    else:
        return "SELL"

data = get_data()
action = moving_average_strategy(data['prices'])
print(action)

2.均值回归策略：Z-score 超买超卖判断
核心逻辑：价格围绕历史均值波动，通过 Z-score 计算偏离度，阈值设为 2 时，Z-score>2 判定超买（卖出），Z-score<-2 判定超卖（买入），适配多数震荡市场环境。
代码实现如下：

import numpy as np
def mean_reversion_strategy(data, threshold=2): 
    prices = np.array(data['prices'])
    mean_price = np.mean(prices) 
    std_dev = np.std(prices)
    z_score = (prices[-1] - mean_price) / std_dev

    if z_score > threshold:
        return "SELL"
    elif z_score < -threshold: 
        return "HOLD"
    return "BUY"

data = get_data()
action = mean_reversion_strategy(data)
print(action)

3.高频交易策略：低延迟接口适配
核心要求：高频交易依赖毫秒级数据响应，XTrader 的 WebSocket 接口可支撑秒级 / 毫秒级指令触发，但需注意 —— 高频策略风险远高于中低频策略，仅建议具备成熟风控体系的团队尝试。

三、量化开发的核心认知：工具适配优于策略优化
从技术开发视角看，不存在「通用于所有市场的完美策略」，趋势跟踪、均值回归等模型均可能出现短期回撤，这是策略与市场环境的适配性问题，而非代码逻辑失效。

对量化开发者而言，trader-x 合约落地的关键在于：

• 用 XTrader 解决数据延迟、执行精度等技术痛点；
• 通过科学回测优化参数，降低策略误差；
• 以长期维度验证策略收益稳定性，而非短期收益。

本文首发于 Aloudata 官方技术博客：《变更影响分析误报率 90%？因为你还在用表级血缘做「假分析」》转载请注明出处。

摘要：传统表级或列级血缘进行变更影响分析，因解析粒度粗糙、逻辑缺失，误报率常高达 90% 以上，本质是“假分析”。本文深入对比了表级血缘与算子级血缘的技术代差，解析了算子级血缘如何通过 AST 解析、行级裁剪、白盒口径提取等核心能力，实现 >99% 的解析准确率，将影响评估范围降低 80% 以上，并结合招商银行、兴业银行等头部金融机构的实践，为数据治理、DataOps 协同及自动化资产盘点提供清晰路径。

在数据驱动的企业中，一次看似微小的上游变更——例如修改一个字段的数据类型——常常会引发一场波及下游的“数据海啸”。数据工程师收到警报：“下游 30 张表、15 个任务可能受影响”。然而，当他们耗费数天时间逐一排查后，往往发现真正需要修改的只有寥寥几张报表。这种高噪声、低信度的影响分析，误报率普遍高达 90% 以上，其本质并非真正的分析，而是一种基于粗糙信息的“假分析”。

“假分析”的根源，在于企业依赖了过时的技术工具——传统表级或列级血缘。它们提供的是一张“破损的地图”，无法看清数据加工的真实逻辑，最终导致数据团队陷入被动“救火”的恶性循环。

演进背景：从“黑盒考古”到“精准导航”的数据治理困局

随着企业数据链路日益复杂，传统的血缘工具已力不从心。正如行业观察所指出的，数据治理团队常陷入尴尬境地：报表出错第一个被问责，指标异常需要“跨越几十个系统的考古”，面对海量僵尸表却无人敢删，因为“天知道它连着什么”。

传统血缘工具的三大原罪，使其无法支撑精准的变更影响分析：

1. 地图是错的：解析器在遇到存储过程、动态 SQL、临时表、嵌套视图等复杂逻辑时频繁断链或错配，产出的血缘图谱本身准确率不足 80%，基于错误地图的导航必然导致错误结论。
2. 技术天书，业务看不懂：血缘图节点是 rpt_fact_001_daily 这类物理表名，业务人员无法理解，导致技术业务协同脱节。
3. 静态快照，路早改了：血缘信息更新滞后，无法反映实时变化的链路，拿着“上个月的地图”指挥“今天的战争”。

数据治理迫切需要从依赖人工的“黑盒考古”，升级为基于精准、实时、可读元数据的“精准导航”。

核心代差对比：表级/列级血缘 vs 算子级血缘

表级/列级血缘与算子级血缘在技术原理和应用效果上存在代际差距，这是影响分析精度天壤之别的根本原因。

精度与能力对比表

技术原理纠错：算子级血缘并非通过简单的正则表达式匹配，而是基于 AST（抽象语法树） 对 SQL 进行完整解析，从而能精准捕获过滤、连接、聚合等内部逻辑，这是实现“行级裁剪”等技术的基础。

场景拆解：为什么表级血缘在做“假分析”？

通过具体场景，可以清晰看到表级血缘的缺陷如何直接导致高误报率。

缺陷一：有“表”无“逻辑”，误报泛滥

• 场景：需要修改源表 user_info 中的 age 字段类型。
• 表级分析：所有引用 user_info 的下游表（如 rpt_user_analysis, dm_user_tag）均被标记为“受影响”。
• 现实：dm_user_tag 表仅使用 user_info 的 gender 字段生成标签，与 age 变更完全无关。这就是典型的误报。
• 算子级解法：通过解析 WHERE gender='F' 等过滤算子，行级裁剪技术能识别出 dm_user_tag 并未使用 age字段，从而将其从影响列表中直接排除，只告警真正使用 age 的下游。

缺陷二：静态快照，无法应对动态逻辑

• 场景：链路中存在通过临时表、嵌套子查询或 DBLINK 进行的动态数据加工。
• 表级分析：解析器无法穿透这些动态逻辑，导致血缘断链，关键下游被漏报。直到该下游报表因数据缺失而崩溃时，问题才暴露。
• 算子级解法：支持对临时表、嵌套子查询的穿透式解析，确保复杂链路的血缘完整性，避免因漏报导致的线上事故。

缺陷三：脱离业务口径，归因困难

• 场景：监管报表中“贷款不良率”指标突增，需紧急溯源定位原因。
• 表级分析：只能提供一串物理表名，业务方无法理解。数据工程师需人工“扒代码”，耗时数周甚至数月。
• 算子级解法：通过白盒化口径提取，自动将多层复杂的 SQL 加工逻辑，压缩成一段业务可读的“加工口径”描述。实现“一键溯源”，将溯源时间从数月级缩短至小时级。浙江农商联合银行的实践表明，监管指标溯源人效因此提升 20 倍。

决策指南：如何选择真正的“影响分析”工具？

为避免陷入“假分析”陷阱，企业在选型影响分析工具时，应聚焦以下关键评估维度：

1. 解析准确率是基石：工具是否敢于承诺并实际实现 >99% 的解析准确率？能否覆盖企业真实环境中的存储过程（如 DB2、GaussDB 的 PL/SQL）、动态 SQL 等复杂场景？
2. 影响分析精度是核心：是否支持字段级影响评估？更进一步，能否支持基于过滤条件（WHERE）的行级裁剪，从而大幅降低评估范围？
3. 业务协同能力是关键：能否输出业务人员可理解的数据加工口径和指标映射，而不仅仅是技术名词，打破技术业务鸿沟？
4. 保鲜能力是保障：能否自动发现链路中的代码变更，并实时更新血缘图谱，确保“地图”与“实际路况”同步？

选型建议：

• 如果你正面临：监管报送指标自动化盘点、大型数仓重构迁移、或高频业务变更下的资损风险防控等挑战。
• 你应该选择：像 Aloudata BIG 这样，以算子级血缘为技术基石、以主动元数据为核心理念的平台。它不仅能提供精准的分析，更能将分析结果主动应用于防控、治理与协同场景。
• 参考标杆：招商银行利用其进行 DataOps 协同，代码上线前评估时间缩短 50%，整改时间缩短 70%；兴业银行实现变更影响分析扩散度降低 80%；民生银行构建了事前事中的变更协作机制。这些实践已验证了其价值。

从“假分析”到“真防控”：Aloudata BIG 的实践路径

高精度的算子级血缘本身不是终点，将其应用于核心业务场景，实现主动价值闭环，才是“真防控”的意义所在。

场景一：自动化资产盘点与监管溯源

浙江农商联合银行面对海量监管报送指标（如 EAST），利用 Aloudata BIG 的“一键溯源”和口径提取能力，将原本耗时数月的指标盘点与口径梳理工作，缩短至 8 小时 内完成，人效提升 20 倍。

场景二：全链路主动风险防控

兴业银行将敏感数据标签与算子级血缘结合，实现标签沿精准链路自动扩散，打标效率提升 95%。同时，在数据任务上线前自动评估变更影响，有效避免了核心报表因上游改动而“暴雷”。

场景三：DataOps 协同，提升研发效能

招商银行在数仓重构迁移中，以算子级血缘为基础构建自动化迁移工具，节省了 500+ 人月 的工作量。在日常研发中，建立了元数据驱动的协同流程，显著提升了数据交付的质量与效率。

常见问题 (FAQ)

Q1: 表级血缘、列级血缘和算子级血缘到底有什么区别？

表级血缘只看到“表”之间的依赖，如同只看到城市间有公路；列级血缘看到“字段”对应，如同知道货物在车厢，但不知如何装卸加工；算子级血缘深入 SQL 内部，看清每一个“过滤(WHERE)”、“连接(JOIN)”、“聚合(GROUP BY)”操作，如同看清了整个物流分拣、加工、打包的全过程，这是实现精准影响分析的前提。

Q2: 影响分析误报率高，除了换工具，还有什么临时解决办法？

临时办法只能是投入大量人力进行“人工复核”：数据工程师在接到泛化的告警后，需要逐一排查下游代码，判断是否真的受影响。这种方法效率极低，不可持续，且高度依赖个人经验，容易出错。这本质上是用人力成本去弥补工具能力的缺陷，并非长久之计。

Q3: 引入算子级血缘平台（如 Aloudata BIG）的实施周期和难度如何？

实施关键在于与现有数据平台的集成。Aloudata BIG 支持主流数据库和调度系统，通常可在数周内完成核心数据链路的接入和解析。难度取决于企业数据环境的复杂度。标杆客户的经验表明，一旦上线，在监管溯源、变更防控等场景能立即见效，快速体现 ROI。

Q4: 算子级血缘能处理存储过程和复杂的ETL脚本吗？

可以，这正是其核心技术壁垒之一。例如，Aloudata BIG 针对 DB2、GaussDB 等数据库的 PL/SQL 存储过程，解析准确率可达 99%。同时，它能解析复杂的嵌套查询、临时表和动态 SQL，确保在真实企业环境中血缘图谱的完整性和准确性，避免漏报。

Q5: 对于中小型企业，也需要这么精细的影响分析吗？

需要，但切入点可能不同。中小型企业可能更关注“成本治理”和“敏捷协同”。通过算子级血缘，可以快速识别僵尸模型、重复计算，优化计算存储成本；同时，在小型团队内建立清晰的数据加工口径，避免知识壁垒，提升数据交付效率与质量。精准的影响分析是数据管理成熟度提升的基石。

核心要点

1. 误报根源在于粒度：传统表/列级血缘因无法解析 SQL 内部加工逻辑（算子），导致影响分析充满噪声，误报率极高，实为“假分析”。
2. 代差决定精度：算子级血缘（解析准确率 >99%）与传统血缘是代际技术差距，其“行级裁剪”等能力能将影响评估范围降低 80% 以上。
3. 场景驱动价值：精准血缘的价值在于应用，如在自动化监管盘点中提效 20 倍，在主动变更防控中降低扩散度 80%，在 DataOps 协同中节省数百人月。
4. 选型聚焦能力：评估工具应聚焦解析准确率、影响分析精度（是否支持行级裁剪）、业务可读性及血缘保鲜能力四大维度。
5. 主动元数据是方向：未来的数据治理将从被动、静态的目录管理，转向基于算子级血缘的主动感知、分析与行动，实现真正的“真防控”。

在工贸企业的运营链路中，“订单-生产-库存”全流程的协同效率直接决定了企业的交付能力、成本控制与客户满意度。针对非标定制需求、生产过程追溯、库存精准管控三大核心痛点，市场上的CRM/ERP系统呈现出差异化的解决方案。本文选取超兔一体云、Zoho CRM、SuiteCRM、 SAP 、Freshsales五大核心玩家，从专业维度展开横向对比，为工贸企业选型提供参考。

一、核心能力全景对比表

我们以工贸企业最关注的三大核心模块为基础，结合综合适配性（成本、易用性、生态）形成对比框架：

二、核心模块深度对比

1. 非标定制型订单创建：从“适配”到“原生支持”的差距

工贸企业的非标订单往往涉及自定义参数、分阶段交付、特殊付款逻辑等需求，系统的原生支持能力直接决定了订单处理效率。

各品牌实现逻辑差异

• 超兔一体云：通过合同订单管理中心原生支持非标场景，可自定义产品参数（如机械尺寸、材质）、设置分阶段交付节点与付款条件，订单创建后自动同步至生产、财务模块，实现数据实时共享。
• SAP：依托ERP的高度定制化能力，支持复杂行业（如化工、重型机械）的参数录入，订单自动关联BOM清单与生产计划，适配多维度的非标需求。
• Zoho CRM：通过自定义字段与模块搭建非标订单框架，特殊流程需通过工作流配置实现，数据共享依赖模块间的关联设置。
• SuiteCRM：需基于开源框架进行Python/PHP二次开发，定制参数录入界面与流程逻辑，开发周期较长。
• Freshsales：仅支持基础自定义字段，无法适配分阶段交付、多节点付款等复杂非标逻辑。

超兔一体云非标订单全流程时序图

sequenceDiagram
    participant 销售部
    participant 超兔合同订单中心
    participant 生产部
    participant 财务部
    销售部->>超兔合同订单中心: 创建非标订单（自定义参数+分阶段交付逻辑）
    超兔合同订单中心->>超兔合同订单中心: 自动生成订单工作流（交付节点+付款条件）
    超兔合同订单中心->>生产部: 同步订单参数+交付截止时间
    超兔合同订单中心->>财务部: 同步付款节点+核算规则
    生产部->>超兔合同订单中心: 反馈生产计划确认结果
    财务部->>超兔合同订单中心: 反馈财务核算完成状态

2. MES生产排程与扫码报工：从“信息孤岛”到“全链路追溯”的突破

订单与生产的直连、生产过程的可追溯是工贸企业降本增效的核心，MES模块的集成能力是关键。

各品牌实现路径差异

• 超兔一体云：原生MES模块与订单中心无缝对接，支持正排/倒排智能排程策略，通过扫码实现领料（匹配BOM防超领）、报工（记录工时/良品率）、质检（记录整改措施）全流程追溯，数据实时回传至各部门。
• SAP：ERP与MES深度集成，通过甘特图可视化生产进度，支持设备故障等异常场景的快速调整，扫码报工与生产数据联动实现全链路管控。
• Zoho CRM：无原生MES功能，需通过API对接第三方MES系统实现订单-生产计划的同步，排程与报工逻辑依赖第三方工具能力。
• SuiteCRM：需二次开发对接MES系统，排程规则、扫码逻辑需定制开发，技术投入成本高。
• Freshsales：无生产模块，仅能管理销售端订单，生产环节需完全依赖外部工具。

超兔一体云生产全流程流程图

flowchart LR
    A[超兔合同订单创建完成] --> B[自动同步至MES系统]
    B --> C{智能排程策略选择}
    C -->|正排/倒排| D[生成生产任务表（工序/班组/时间节点）]
    D --> E[领料扫码（匹配BOM清单，防止超领）]
    E --> F[工序完成扫码报工（记录工时/良品率）]
    F --> G[质检扫码（记录合格/不合格结果+整改措施）]
    G --> H[数据回传至销售/生产/财务模块]
    H --> I[销售端同步交付进度给客户]

3. 库存上下限预警+序列号管理：从“被动补货”到“精准溯源”的升级

库存的动态管控与产品溯源是工贸企业规避积压风险、满足合规要求的核心能力。

各品牌功能粒度差异

• 超兔一体云：实时监控库存水平，自定义上下限阈值并通过系统消息/短信预警；序列号与入库单、订单、售后记录绑定，支持全生命周期溯源，满足医疗器械等行业的合规要求。
• SAP：库存数据与生产、采购模块实时联动，预警规则可关联生产计划调整；序列号/批次管理覆盖从原材料到成品的全链路，支持多维度溯源。
• Zoho CRM：支持基础库存上下限预警，序列号仅与入库/出库单绑定，无法关联生产与售后数据。
• SuiteCRM：可通过二次开发实现自定义预警规则与序列号全链路溯源，需技术团队维护。
• Freshsales：仅支持批次级库存预警，无序列号管理能力，溯源精度不足。

库存管理核心能力脑图

mindmap
    root((库存管理核心能力全景))
        核心功能模块
            库存上下限预警
                实时库存监控
                多渠道预警通知
                自定义阈值规则
            序列号管理
                入库序列号绑定
                出库序列号追踪
                全生命周期溯源
                行业合规满足
            生产联动
                库存数据同步生产计划
                序列号关联订单/BOM
        品牌覆盖情况
            超兔一体云: 全能力覆盖
            SAP: 全能力+深度生产联动
            Zoho CRM: 基础预警+简单序列号绑定
            SuiteCRM: 定制化覆盖
            Freshsales: 基础批次预警

三、综合性能雷达图分值（满分100）

四、品牌适配建议

1. 中小工贸企业（追求一体化、低成本） ：优先选择超兔一体云，原生覆盖全流程，无需额外开发，易用性高，能快速提升订单-生产-库存的协同效率。
2. 大型复杂工贸企业（如化工、重型机械） ：选择SAP，其高度定制化能力与ERP-MES深度集成，可适配复杂非标需求与多场景生产管控，满足高端合规要求。
3. 有技术团队的工贸企业（需高度定制） ：选择SuiteCRM，开源框架支持全流程定制，成本较低，但需投入技术资源进行二次开发。
4. 侧重销售获客、生产外包的工贸企业：选择Zoho CRM，3用户永久免费，销售端能力强，可通过生态对接第三方工具补充生产库存管理。
5. 生产环节完全外包的工贸企业：选择Freshsales，专注销售获客与客户管理，仅需基础库存预警功能。

总结

工贸企业的全流程管理核心在于“数据打通”与“场景适配”。超兔一体云在中小工贸场景中实现了原生一体化的最优平衡，SAP在高端复杂场景中占据绝对优势，而Zoho、SuiteCRM则分别在灵活扩展与定制化方面满足细分需求。企业需结合自身规模、行业特性、技术储备与成本预算，精准匹配业务场景与长期发展需求，选择最适配的解决方案，以此实现降本增效、提升核心竞争力的目标。

摘要：
趣丸科技原有 MySQL+ES +向量数据库多组件架构，存在开发复杂、运维繁琐、性能不稳、成本偏高问题。OB Cloud 云数据库，凭借其一体化架构优势，以及稳定、高效、灵活的特性助力趣丸科技突破了AI 应用落地的瓶颈，使项目开发周期减半，检索延迟低于 50ms，整体 TCO 降低 40%，运维效率大幅提升。

在科技快速迭代的今天，AI 技术正以前所未有的速度重塑各行各业。2014 年诞生于广州的趣丸科技经历十余年的发展，已成为中国互联网综合实力百强企业，旗下打造的 TT 语音等社交产品服务着亿万兴趣社交用户。

而随着 AI 浪潮的到来，趣丸科技也面临着前所未有的数据挑战。从日常运维的告警治理，到新业务场景的 AI 助手开发，数据底座的性能、稳定性和成本问题日益凸显。

近日在 OceanBase 年度发布会上，趣丸科技的数据库负责人苏程辉先生就提出了一个直击痛点的问题：业界目前没有一个成熟的、能快速支持 AI 开发的底层数据库。传统 Mysql + ES+向量数据库的多组件组合方案，不仅开发难度大、运维复杂，更给企业带来了高昂的成本负担。正是在这样的背景下，趣丸科技将目光投向了 OceanBase，希望可以找到一条能够快速实现 AI 应用落地的技术路径。

趣丸科技数据库负责人苏程辉表示：“我们需要一个能够同时满足标量数据存储、全文索引和向量检索需求的统一数据底座，而不是拼凑多个组件。”

而 OB Cloud 云数据库，凭借其一体化架构优势，以及稳定、高效、灵活的特性为趣丸科技解决了一系列难题。它是如何助力趣丸科技突破 AI 应用落地的瓶颈？今天让我们跟随苏程辉先生的视角一探究竟。

趣丸科技的 AI 进阶之路

在 AI 技术布局与运用上，趣丸科技的实践早已渗透到业务全流程。早在新业务场景启动前，其数据库中间件的 AI 实践就已初见成效。随着业务的快速发展，趣丸需要运维的实例也从原来的几十、上百增长到数千个，业务模式更从仅支持 TP 负载转变为支持 HTAP 混合负载。

对此，趣丸的运维团队通过 AI 技术的运用，实现了慢日志优化、磁盘资源分析、CPU 告警分析等日常运维场景的效率提升，大幅缓解了运维团队的压力。

但当业务聚焦到“员工助手”这一全新 AI 应用时，更复杂的数据需求让原有架构的短板暴露无遗。作为企业级的智能入口，“员工助手”需要为每位员工提供专属服务，这背后隐藏着四大核心数据需求：

一是标量数据的高性能存储与易扩展，支撑基础业务数据的稳定流转；
二是全文索引能力，满足对各类文档、对话内容的精准检索；
三是向量需求，适配AI模型的特征向量存储与检索；
四是 HTAP 能力，既要支撑实时的业务交互，又要满足后续个人行为分析等离线计算需求，同时还得保证上下文的永久保存。

为满足这些需求，趣丸科技做了多方对比以及不同的备选方案，首先被考虑的是行业内常见的“多组件堆砌”架构，用 MySQL 承载标量数据，ES 负责全文索引，向量数据库处理向量需求。但这套架构很明显容易给技术团队带来多重“困境”，容易让 AI 业务落地陷入到瓶颈当中。

传统多组件架构易带来的多重困境

01开发效率低，成本居高不下

多组件架构意味着研发团队需要同时对接 MySQL、ES、向量数据库等多个系统，不仅要掌握不同组件的开发语法，还要处理组件间的数据同步问题，编码复杂度大幅提升。更关键的是，多组件意味着多套资源申请、部署流程，原本简单的业务需求，硬生生被拆分成多个资源申请环节，流程繁琐且周期漫长。从成本角度看，每套组件都需要独立的服务器、存储资源支撑，叠加运维人员的学习成本，企业整体TCO（总拥有成本）直线上升。

02性能不稳定，业务体验打折

AI 应用对响应速度的要求极高，尤其是“员工助手”这类实时交互场景，延迟过高会直接影响员工使用体验。而多组件架构中，数据需要在不同系统间流转，每一次跨组件调用都会增加响应延迟。更麻烦的是，不同组件的性能瓶颈各不相同，MySQL 的并发瓶颈、ES 的检索延迟、向量数据库的查询效率，任何一个环节出问题都会导致整体性能波动，想要实现稳定的高性能体验十分困难。

03运维复杂度飙升，稳定性难以保障

多组件架构相当于构建了多个“数据孤岛”，每个组件都有独立的运维体系。MySQL 的主从切换、ES 的集群扩容、向量数据库的索引优化，运维团队需要熟悉每套系统运维逻辑，工作量呈几何级增长。更危险的是，当业务出现故障时，排查链路被无限拉长，运维人员需要逐一排查每个组件的日志、监控数据，定位问题根源的时间大幅增加，而 N-1 节点故障等场景下，多组件的容灾协同更是难上加难，数据丢失风险不容忽视。

这些挑战不仅拖慢了 AI 应用的迭代速度，更让技术团队疲于应对基础设施问题，无法专注于核心业务创新。很显然趣丸科技需要的是一个既稳定可靠、又成本可控，同时能够简化架构、提升开发效率的统一数据底座。

选择 OB Cloud：用一套架构解决“标量+向量+全文”三重需求

趣丸科技基于“快速业务实现、稳定性保障、成本优化”三大核心目标，他们设定了明确的选型标准：既要满足标量数据的海量存储、一致性和稳定性，又要支撑向量的高效存储与检索；既要支持 SQL 快速开发，适配混合搜索、多路召回等 AI 场景，又要具备高扩展性和成本优势。

经过多轮对比测试，OB Cloud 从多个备选方案中脱颖而出。苏程辉坦言：“OB Cloud 在性能成本等方面都能满足业务需求，尤其是其兼容性、稳定性、可靠性和扩展能力，完美契合我们的 AI 业务场景。”

而 OB Cloud 之所以能成为趣丸科技的最终选择，核心在于其用一套数据架构，破解了“标量+向量+全文”的三重需求，从根源上解决了多组件架构的痛点。

01一体化架构，开发效率质的提升

OB Cloud 的一体化架构，核心通过高兼容性与原生向量支持的深度融合，为研发团队带来开发效率的质的提升。对于研发团队而言，兼容性是降低开发成本的关键，而这正是 OB Cloud 一体化架构的基础优势，其具备高度的 MySQL 语法兼容性，这意味着趣丸科技的研发人员无需学习全新的开发语言，原有基于 MySQL 的代码可以快速升级，无需进行大规模重构。

更重要的是，OB Cloud 原生支持向量检索，通过 SQL 语句即可实现向量的插入、查询、检索等操作，无需对接独立的向量数据库，让 “标量数据存储+向量检索+全文索引” 可以通过一套 SQL 语法实现。

以“员工助手”的多路融合检索场景为例，研发人员只需编写一条 SQL，就能同时实现标量数据的过滤、全文检索的匹配和向量数据的相似性查询，无需在多个组件间进行数据同步和语法转换。这种开发模式，不仅简化了开发逻辑，降低了编码复杂度，更让多路召回等 AI 核心场景的开发周期大幅缩短。

苏程辉表示：“SQL 原生支持向量检索，能够快速实现业务需求，原来需要对接三个组件的开发工作，现在一套底座就能搞定，开发效率提升非常明显。”

02高可用性，筑牢 AI 业务“安全防线”

AI 业务对实时性、连续性的要求极高，数据底座的稳定性和可靠性直接决定用户体验。OB Cloud 在这方面的表现，让趣丸科技彻底打消了顾虑。其核心优势在于三大特性：

一是 RTO（恢复时间目标）小于 10 秒，远超行业平均水平，即使发生故障，业务也能快速恢复，几乎不影响员工使用“员工助手”的体验；
二是支持 N-1 节点故障无感，当集群中某个节点出现故障时，系统会自动切换到备用节点，业务层面完全感知不到故障存在，避免了传统多组件架构中节点故障导致的业务中断；
三是数据三副本存储，通过异地多活部署确保数据无丢失风险，这对于“员工助手”的上下文永久保存等场景至关重要，彻底解决了数据可靠性的后顾之忧。

03强扩展性，运维效率提升数倍

AI 业务的算力需求往往存在大幅波动，比如“员工助手”在上下班高峰期的并发量可能是平时的数倍，这就对数据底座的扩展性提出了极高要求。

OB Cloud 的弹性扩展能力完美适配这一场景：节点扩容可在分钟级完成，容量扩容更是秒级响应，更支持自动扩容功能，系统能根据业务负载自动调整资源配置，无需人工干预。这种“按需分配”的扩展模式，既避免了资源闲置导致的成本浪费，又确保了业务高峰期的性能稳定，让趣丸科技无需再为“提前预留大量资源应对峰值”而烦恼。

而 OCP（OceanBase Cloud Platform）平台的存在，则让运维工作从“黑暗摸索”走向“光明高效”。苏程辉对比了以往的运维体验：“原来用其他组件，很多操作都需要黑屏命令行操作，还得自己定制运维工具，而 OCP 平台简化了大量运维工作，让我们可以轻松管理集群。”通过 OCP 平台，趣丸科技的运维团队可以实现集群管理、租户配置、监控告警、故障排查等全流程可视化操作。

从租户资源申请到集群扩容，从性能监控到日志分析，所有运维工作都能在统一平台完成，无需再切换多个系统。这种标准化的运维体系，不仅降低了运维人员的学习成本，更让故障定位时间大幅缩短，运维效率提升数倍。

04多路融合检索，适配 AI 核心场景需求

AI 应用，尤其是“员工助手”这类智能交互场景，对检索的准确性和时效性要求极高，多路融合检索是核心技术难点。OB Cloud 通过“稀疏向量+稠密向量+全文检索”的多路融 合能力，完美适配了这一需求。

苏程辉介绍，他们在测试中发现，OB Cloud 的多路召回效率远超预期，不同检索方式的召回率分别达到 70.40%、75.90%、83.30%、85.20% 和 88.90%，完全满足业务对检索准确性的要求。

在检索流程上，OB Cloud 实现了“插入-预处理-查询-重排序”的全链路优化：

插入文本时，系统会自动通过 Embedding 模型生成向量、进行分词处理和 Chunk 拆分；

查询时，通过SQL语句即可触发多路召回，快速融合稀疏向量、稠密向量和全文检索的结果，并通过重排序算法输出最优结果。

这种端到端的优化，让多路融合检索的时效性大幅提升，全文检索延迟控制在 50ms 以内，向量检索 QPS达到 1000+，完全适配“员工助手”的实时交互需求。

列存特性则为 AI 的离线分析场景提供了强力支撑。OB Cloud 支持副本的列式存储，无需增加额外资源，就能为 AP 场景提供高效的分析能力。对于“员工助手”的历史对话分析、用户行为画像构建等场景，列式存储能大幅提升数据扫描和聚合效率，让离线分析任务的执行时间缩短数倍。

苏程辉表示：“列存让我们在无需增加资源的情况下获得了分析能力，TP 和 AP 的无缝协同，让 AI 的实时推理和离线训练可以共享同一套数据底座，避免了数据同步的麻烦。”

趣丸实践成效：开发效率跃升，TCO 降低 40%

在 OB Cloud 的支撑下，趣丸科技的“员工助手”快速落地，各项业务指标实现跨越式提升。

苏程辉用“开发效率+运维标准化+成本节省”三个关键词总结了项目成功的核心：“这三点是员工助手快速上线的关键，也是 OB Cloud 给我们带来的最直接价值。具体来看，OB Cloud 的实践成效主要体现在三大维度。

01开发周期大幅缩短，业务上线效率跃升

OB Cloud 的“一套底座替代多组件”模式，改变了研发流程。原来需要申请MySQL、ES、向量数据库三套资源，经过多轮审批、部署、调试才能开展开发工作，现在只需通过 OCP 平台申请一个租户，几分钟内就能完成资源配置。研发人员无需再学习多套组件的开发语法，基于熟悉的 MySQL 语法就能实现“标量+向量+全文”的开发需求，编码复杂度大幅降低。

这种效率的提升，让“员工助手”从立项到上线的周期缩短了近一半，帮助趣丸科技快速抢占了内部管理智能化的先机。

02性能稳定性跨越式提升，用户体验持续优化

上线后的“员工助手”在性能表现上远超预期。监控数据显示，业务运行期间，OB Cloud 的 CPU 使用率始终保持在 20% 以下，运行平稳无波动；等待事件平均耗时控制远低于传统架构的毫秒级延迟。即使在上下班高峰期，“员工助手”的响应时间也能稳定在 50ms 以内，向量检索 QPS 峰值突破 1000+，完全满足高并发场景的需求。从容应对业务高峰，为用户提供流畅的 AI 交互体验。

03成本效率优化超预期，整体 TCO 降低40%

成本效率优化是趣丸关注的核心指标。OB Cloud 通过多维度优化，为趣丸科技带来了显著的成本节约。存储方面，列存高压缩比使归档场景存储成本降低 60%；运维方面，OCP 平台的自动化能力减少了 70% 的人工干预；架构方面，一体化数据底座消除了多组件冗余，整体 TCO（总体拥有成本）下降 40%。

这些成果不仅验证了 OB Cloud 在 AI 场景中的技术实力，更彰显了其作为企业级数据底座的商业价值。

正如苏程辉所言：“OB Cloud 让我们真正实现了以数据驱动 AI 业务创新，而不是被基础设施所束缚。”

智启未来：OB Cloud 与 AI 融合的新征程

趣丸科技与 OB Cloud 的合作，不仅是一次技术升级，更是一次企业数智化转型的成功实践。这一案例为同行业企业提供了宝贵借鉴：在 AI 应用落地过程中，选择一个能够兼顾性能、稳定性和成本的统一数据底座，比拼凑多个专用系统更具长期价值。

展望未来，趣丸科技对 OB Cloud 有着更广阔的期待。“我们希望看到三大能力的进一步增强，”苏程辉表示，“首先是共享存储架构，实现真正的存算分离；其次是自动数据冷热分离和 TTL 功能，让冷数据自动迁移到低成本存储，进一步优化成本；第三是分布式自动分区能力，简化大规模数据管理的复杂性。”这些能力的实现，将进一步释放 OB Cloud 在 AI 场景中的潜力。

对 OB Cloud 而言，趣丸科技的实践验证了其在 AI 时代的战略定位：不再仅是传统数据库的替代者，而是 AI 应用的赋能者。通过标量、向量与全文数据的一体化处理能力，OB Cloud 正在成为企业 AI 战略的核心基础设施。

而在智能化浪潮席卷全球的今天，OceanBase 也将持续深耕企业级数据库技术，为更多像趣丸科技一样的创新企业提供坚实的数据底座，共同探索 AI 助力业务增长的无限可能。让数据，真正成为企业最宝贵的战略资产。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

本次分享基于 MindSpore 的参数高效微调（PEFT）能力，构建 “分层 LoRA/QLoRA 微调 + EWC 遗忘抑制 + 增量预训练协同优化” 的工业级方案，实现单卡（A10 24G）完成 7B 模型高效微调，显存占用降低 75%，灾难性遗忘率降至 5% 以下，行业数据集微调后精度提升 8.3%，附全流程微调代码与显存 / 精度量化分析。

1. 分层 LoRA/QLoRA 高效微调：MindSpore 低显存实现

场景：传统全量微调需加载完整模型权重并更新所有参数，7B 模型全量微调单卡显存占用超 70G；通用 LoRA 采用统一秩（rank）适配所有层，导致底层语义层微调不足、上层任务层过拟合，且未量化的 LoRA 仍有 15G + 显存开销。

MindSpore 技术实践：

基于 MindSpore 的ParameterFreeze参数冻结、QuantAwareTraining量化能力，实现分层 LoRA/QLoRA 微调—— 对 Transformer 底层（0-10 层）采用高秩 LoRA（rank=64）保证语义保留，上层（11-31 层）采用低秩 QLoRA（rank=16，4bit 量化）降低显存；仅更新 LoRA 适配器参数，冻结主干模型权重，结合梯度裁剪进一步控制显存峰值：

import mindspore as ms
import mindspore.nn as nn
import mindspore.ops as ops
from mindspore.train import Model
from mindspore.compression import QuantizationAwareTraining

ms.set_context(mode=ms.GRAPH_MODE, device_target="GPU")
ms.set_context(max_device_memory="24GB")  # 适配A10 24G单卡

# 1. 定义分层LoRA适配器（MindSpore原生实现）
class LoRALayer(nn.Cell):
    def __init__(self, in_dim, out_dim, rank, alpha=16):
        super().__init__()
        self.rank = rank
        self.alpha = alpha
        # LoRA权重：仅这两个参数参与更新
        self.A = ms.Parameter(ms.ops.randn(in_dim, rank) * 1e-4, requires_grad=True)
        self.B = ms.Parameter(ms.ops.zeros(rank, out_dim), requires_grad=True)
        self.scaling = alpha / rank

    def construct(self, x):
        # LoRA前向：x @ A @ B * scaling
        lora_out = ops.matmul(ops.matmul(x, self.A), self.B) * self.scaling
        return x + lora_out

# 2. 分层适配LoRA/QLoRA的7B模型封装
class LoRAQwen7B(nn.Cell):
    def __init__(self, base_model, lora_rank_low=16, lora_rank_high=64, quant_bit=4):
        super().__init__()
        self.base_model = base_model
        self.quant_config = QuantizationAwareTraining(quant_dtype=ms.int4) if quant_bit ==4 else None
        # 冻结主干模型所有参数
        for param in self.base_model.trainable_params():
            param.requires_grad = False
        # 分层添加LoRA适配器
        self.lora_layers = nn.CellList()
        for layer_idx, transformer_layer in enumerate(self.base_model.transformer.layers):
            # 底层（0-10层）：高秩LoRA（不量化）
            if layer_idx <= 10:
                lora_attn = LoRALayer(4096, 4096, lora_rank_high)
                self.lora_layers.append(lora_attn)
                transformer_layer.self_attn.qkv_proj = nn.SequentialCell([
                    transformer_layer.self_attn.qkv_proj, lora_attn
                ])
            # 上层（11-31层）：低秩QLoRA（4bit量化）
            else:
                lora_attn = LoRALayer(4096, 4096, lora_rank_low)
                if self.quant_config:
                    lora_attn = self.quant_config.quantize(lora_attn)
                self.lora_layers.append(lora_attn)
                transformer_layer.self_attn.qkv_proj = nn.SequentialCell([
                    transformer_layer.self_attn.qkv_proj, lora_attn
                ])

    def construct(self, input_ids, attention_mask):
        return self.base_model(input_ids, attention_mask)

# 3. 低显存微调训练配置
def setup_lora_trainer(model, train_dataset):
    # 仅优化LoRA参数（主干冻结）
    lora_params = [p for p in model.trainable_params() if "LoRALayer" in p.name]
    optimizer = nn.AdamW(lora_params, learning_rate=2e-4, weight_decay=1e-5)
    # 梯度裁剪：控制显存峰值
    grad_clip = nn.GradientClipByNorm(clip_norm=1.0)
    optimizer = nn.Optimizer(optimizer, grad_clip=grad_clip)
    # 构建训练模型
    loss_fn = nn.CrossEntropyLoss()
    train_model = Model(model, loss_fn=loss_fn, optimizer=optimizer)
    # 训练（仅更新LoRA参数，显存占用极低）
    train_model.train(
        epoch=5,
        train_dataset=train_dataset.batch(8),  # 单卡batch_size=8
        dataset_sink_mode=True  # 数据下沉进一步降显存
    )
    return model

# 加载基座模型+初始化LoRA
base_model = load_qwen7b_model()  # 加载MindSpore格式Qwen7B基座
lora_model = LoRAQwen7B(base_model, lora_rank_low=16, lora_rank_high=64, quant_bit=4)
# 启动微调
lora_model = setup_lora_trainer(lora_model, industry_dataset)

# 效果：7B模型单卡（A10 24G）微调显存占用仅18G，相比全量微调降低75%，训练速度提升40%

2. 增量预训练的灾难性遗忘抑制：EWC + 对比学习双约束

场景：基于通用大模型做行业增量预训练时，模型会快速遗忘通用知识（灾难性遗忘），导致通用任务精度暴跌 30% 以上；仅靠 LoRA 微调无法平衡行业知识融入与通用知识保留。

MindSpore 技术实践：

基于 MindSpore 的自定义损失函数与参数约束能力，集成弹性权重整合（EWC） 抑制遗忘（对通用知识核心参数添加权重约束），结合对比学习增强通用 - 行业知识的关联，在增量预训练阶段同时优化 “行业任务损失 + EWC 约束损失 + 对比损失”：

# 1. EWC权重约束损失（MindSpore实现）
class EWCLoss(nn.Cell):
    def __init__(self, model, fisher_matrix, lambda_ewc=1e3):
        super().__init__()
        self.model = model
        self.fisher_matrix = fisher_matrix  # 预计算的Fisher信息矩阵（通用任务梯度方差）
        self.lambda_ewc = lambda_ewc
        # 保存通用模型核心参数（Transformer注意力层权重）
        self.base_params = {
            name: param.clone() for name, param in model.parameters_and_names()
            if "self_attn" in name and "weight" in name
        }

    def construct(self):
        # EWC损失：约束核心参数偏离通用模型的程度
        ewc_loss = 0.0
        for name, param in self.model.parameters_and_names():
            if name in self.base_params:
                ewc_loss += self.lambda_ewc * ops.sum(
                    self.fisher_matrix[name] * ops.square(param - self.base_params[name])
                )
        return ewc_loss

# 2. 对比学习损失（增强通用-行业知识关联）
class ContrastiveLoss(nn.Cell):
    def __init__(self, temperature=0.07):
        super().__init__()
        self.temperature = temperature
        self.cos_sim = ops.CosineSimilarity(dim=-1)

    def construct(self, industry_emb, general_emb):
        # 行业样本与通用样本的对比损失
        sim = self.cos_sim(industry_emb, general_emb) / self.temperature
        loss = -ops.log(ops.exp(sim) / ops.sum(ops.exp(sim), axis=0))
        return ops.mean(loss)

# 3. 增量预训练混合损失函数
class HybridLoss(nn.Cell):
    def __init__(self, model, fisher_matrix):
        super().__init__()
        self.ce_loss = nn.CrossEntropyLoss()
        self.ewc_loss = EWCLoss(model, fisher_matrix)
        self.contrast_loss = ContrastiveLoss()

    def construct(self, logits, labels, industry_emb, general_emb):
        ce = self.ce_loss(logits.reshape(-1, logits.shape[-1]), labels.reshape(-1))
        ewc = self.ewc_loss()
        contrast = self.contrast_loss(industry_emb, general_emb)
        # 混合损失：平衡行业任务与遗忘抑制
        return ce + 0.2 * ewc + 0.1 * contrast

# 4. 增量预训练流程
# 预计算Fisher矩阵（通用任务）
fisher_matrix = compute_fisher_matrix(base_model, general_dataset)
# 构建混合损失
hybrid_loss = HybridLoss(lora_model, fisher_matrix)
# 增量预训练（行业数据+通用数据混合）
optimizer = nn.AdamW(lora_model.trainable_params(), learning_rate=1e-4)
train_model = Model(lora_model, loss_fn=hybrid_loss, optimizer=optimizer)
train_model.train(
    epoch=3,
    train_dataset=mix_dataset(industry_dataset, general_dataset, ratio=8:2),  # 动态混合数据
    dataset_sink_mode=True
)

# 效果：灾难性遗忘率从32%降至4.8%，通用任务精度仅下降1.2%，行业任务精度提升9.1%

3. 微调 + 增量预训练的协同优化：动态策略与自适应调度

场景：固定数据比例、固定学习率的微调 / 增量预训练流程，无法适配模型训练的不同阶段（前期需融入行业知识，后期需巩固通用 - 行业关联），导致训练效率低、精度波动大。

MindSpore 技术实践：

基于 MindSpore 的Callback自定义回调能力，实现动态数据混合（训练前期行业数据占比 90%，后期逐步降至 70%）、自适应学习率调度（LoRA 参数与主干参数差异化学习率）、显存动态监控（实时调整 batch size）：

from mindspore.train.callback import Callback

# 1. 动态数据混合回调
class DynamicDataMixCallback(Callback):
    def __init__(self, industry_dataset, general_dataset, total_epochs=5):
        self.industry_dataset = industry_dataset
        self.general_dataset = general_dataset
        self.total_epochs = total_epochs
        self.current_epoch = 0

    def epoch_begin(self, run_context):
        # 动态调整行业/通用数据比例：前期重行业，后期重通用
        ratio = 0.9 - 0.2 * (self.current_epoch / self.total_epochs)
        self.mixed_dataset = mix_dataset(
            self.industry_dataset, self.general_dataset, ratio=ratio:(1-ratio)
        )
        run_context.original_args().train_dataset = self.mixed_dataset
        self.current_epoch += 1

# 2. 自适应学习率回调（LoRA参数学习率>主干参数）
class AdaptiveLRScheduler(Callback):
    def __init__(self, optimizer, lora_lr=2e-4, base_lr=1e-5):
        self.optimizer = optimizer
        self.lora_lr = lora_lr
        self.base_lr = base_lr

    def step_begin(self, run_context):
        # 分层调整学习率：LoRA参数用高学习率，主干参数用低学习率
        for param_group in self.optimizer.param_groups:
            if "LoRALayer" in param_group.name:
                param_group.lr = self.lora_lr * (0.9 ** self.current_step)
            else:
                param_group.lr = self.base_lr * (0.95 ** self.current_step)
        self.current_step += 1

# 3. 显存监控与batch size自适应回调
class MemoryMonitorCallback(Callback):
    def __init__(self, init_batch_size=8, max_batch_size=16, min_batch_size=4):
        self.init_batch_size = init_batch_size
        self.max_batch_size = max_batch_size
        self.min_batch_size = min_batch_size
        self.current_batch = init_batch_size

    def step_end(self, run_context):
        # 获取显存占用（MindSpore Profiler）
        mem_used = get_gpu_memory_usage()
        # 显存>85%：减小batch size；<60%：增大batch size
        if mem_used > 0.85 and self.current_batch > self.min_batch_size:
            self.current_batch -= 2
            update_dataset_batch_size(self.current_batch)
        elif mem_used < 0.6 and self.current_batch < self.max_batch_size:
            self.current_batch += 2
            update_dataset_batch_size(self.current_batch)

# 4. 集成所有回调启动训练
callbacks = [
    DynamicDataMixCallback(industry_dataset, general_dataset),
    AdaptiveLRScheduler(optimizer),
    MemoryMonitorCallback(init_batch_size=8)
]
train_model.train(
    epoch=5,
    train_dataset=self.mixed_dataset,
    callbacks=callbacks,
    dataset_sink_mode=True
)

协同优化效果对比（Qwen7B，行业金融数据集）

开发者朋友们大家好：

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

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

01 有话题的技术

1、Ultralytics 发布 YOLO26：面向边缘视觉 AI，CPU 推理提速 43%

Ultralytics 正式发布 YOLO26，这被描述为迄今为止最先进且最易于部署的 YOLO 模型，专为边缘视觉 AI 场景量身打造。随着视觉 AI 迅速向边缘端迁移，YOLO26 旨在解决延迟、可靠性和成本问题，能够在 CPU、边缘加速器及低功耗硬件上实现高效运行，同时延续了该系列简洁易用的特性，支持多种视觉任务的无缝集成。

YOLO26 引入了多项核心创新，全面提升了推理速度、训练稳定性及部署便捷性：

• 移除分布焦点损失（DFL）以简化流程。YOLO26 完全移除了 DFL 模块，这一改变消除了早期模型中对边界框回归的固定限制，不仅提升了检测超大物体时的可靠性和准确性，还降低了模型复杂度，使其更易于导出并在各类边缘设备上稳定运行。
• 实现端到端无 NMS 推理。模型原生支持端到端推理模式，直接输出最终预测结果，不再依赖非极大值抑制（NMS）作为独立的后处理步骤。这一架构创新有效降低了推理延迟，简化了部署流程，并减少了集成错误的风险，特别适配实时部署需求。
• 引入渐进式损失平衡与小目标优化。通过结合渐进式损失平衡（ProgLoss）与小目标感知标签分配（STAL）技术，YOLO26 实现了更稳定的训练收敛过程。特别是 STAL 针对小目标进行了专门优化，显著改善了在物联网及航拍等远距离、视觉信息有限场景下的检测精度。
• 采用 MuSGD 混合优化器。YOLO26 采用了一种全新的 MuSGD 优化器，该优化器融合了传统随机梯度下降（SGD）与源自大语言模型的 Muon 优化思想。这种结合旨在提升训练的稳定性与效率，使模型在不同尺寸和复杂场景下均能平稳收敛并达到出色性能。
• CPU 推理性能大幅提升。针对边缘计算场景的深度优化使得 YOLO26 在无 GPU 的条件下，CPU 推理速度最高提升可达 43%。这一性能跃升允许实时视觉系统直接运行在摄像头、机器人和嵌入式硬件上，满足低延迟与成本受限的实际需求。

此外，YOLO26 还针对实例分割、姿态估计及旋转框检测等任务进行了特定优化，并推出了基于同架构的开放词汇分割模型 YOLOE-26，支持通过 Ultralytics 平台或开源工作流进行灵活部署。

GitHub:
https://github.com/ultralytics/ultralytics

体验链接：
https://platform.ultralytics.com/ultralytics/yolo26

（@边缘计算社区）

2、VoxPrivacy 发布： 首个面向语音大模型的交互隐私评测基准

VoxPrivacy 发布了首个面向语音大模型的交互隐私评测基准。当语音大模型从「个人设备」走向「智能家居/车载/公共服务」等多人共享场景时，新的风险随之出现：模型可能将用户 A 的私密日程、隐私信息，误传给用户 B。

因此，语音助手需要明确「哪些话能说、该对谁说」，即具备交互隐私能力。VoxPrivacy 旨在以系统化方式衡量模型在共享环境中是否能「说对话、也守规矩」。

该基准的核心贡献在于将「共享场景里哪些信息能说、该对谁说」这一问题，转化为一套可量化、可复现的语音评测。其不仅考察模型是否会聊天，更考察其在多人、多轮、跨时间的对话里识别说话人、理解语境并做出正确隐私保护决策的能力。

VoxPrivacy 设计了三层难度任务（直接保密指令→ 说话人验证保密 → 无指令的主动隐私保护），覆盖从「被要求保密」到「主动判断什么是隐私」的完整能力链路；并构建了 7107 条、超过 32 小时的中英双语音频，另含 18 位志愿者录制的真实语音验证集，确保评测更贴近真实使用场景。

在对 9 个主流语音大模型的评测中，研究发现共享场景下的核心风险并非「无法应答」，而是「过度应答」：当用户 B 发起询问时，模型可能将用户 A 刚刚提及的私人信息直接复述出来。

整体来看，不少开源模型在「信息能否说、该对谁说」的判断上正确率仅约 50%。这意味着，模型对隐私的处理几乎等同于随机猜测：用户既无法信任它会将信息准确传递给目标对象，也无法确保它不会向无关人员泄露隐私。

分析显示，问题根源在于模型对「多说话人+多轮对话」中的身份线索捕捉能力薄弱，导致隐私边界难以守住。

目前，VoxPrivacy 已同步开放 4000 小时数据集，助力开发者通过微调优化模型隐私边界能力，让「共享语音助手的交互隐私」第一次有了统一标尺与明确的改进路径。

demo 网址：
https://interactionalprivacy.github.io/

( @Amphion)

3、不仅是 Talkie 的引擎：MiniMax M2-her 定义沉浸式角色扮演新基准

MiniMax 近日发布了其最新技术成果 MiniMax-M2-her，作为星野和 Talkie 的底层模型，M2-her 致力于打造更深层次的 Role-Play 体验。

经过三年的观察与迭代，MiniMax 团队发现，用户与 NPC 的互动呈现出明显的长尾特征，即便是冷门角色也拥有一批忠实用户。

因此，Role-Play 的核心不在于单一角色的复刻，而在于用户与角色在特定「世界观 × 故事线」坐标下，针对「用户偏好」共同编织的独特旅程。

针对这一洞察，MiniMax-M2-her 聚焦于三大能力的提升：首先是构建独一无二的世界体验，模型需理解并维持复杂的设定，避免千人一面的平庸感；其次是赋予故事生命力，通过更鲜活的剧情推进，避免长对话中的机械循环；最后是精准捕捉用户未言明的潜在偏好，从细微交互中读懂用户期待。

为验证模型效果，MiniMax 提出了 Role-Play Bench 评估标准，通过情境重演的方式，重点考察模型在 Worlds（世界观一致性）、Stories（故事多样性与逻辑）及 User Preferences（用户交互体验）三个维度的表现。

评测结果显示，在 100 轮长程对话中，M2-her 的综合表现位居榜首，尤其在解决角色混淆、空间逻辑错误及长轮次质量衰减方面表现突出。

技术实现上，M2-her 采用 Agentic Data Synthesis 管线生成高质量合成数据，并通过 Online Preference Learning 技术，从用户的隐式反馈信号中提取偏好信息，利用 RLHF 进行模型训练与迭代。

展望未来，MiniMax 提出了 Worldplay 的新方向，旨在通过动态 World State 建模与多角色协同叙事，让用户从「进入世界」升级为「共创世界」，实现更具开放性与互动深度的 AI 体验。

目前，M2-her API 已正式接入 MiniMax 开放平台。

技术深度解析：

https://www.minimaxi.com/news/minimax-m2-her-%E6%8A%80%E6%9C%...

API:

https://platform.minimax.io/docs/api-reference/text-chat

( @MiniMax Blog)

4、面向专业创作场景，MiniMax 推出 Music 2.5 并开放 API

MiniMax 稀宇科技同步推出面向专业音乐创作的 MiniMax Music 2.5。

MiniMax Music 2.5 在可控性与真实度两大核心指标上实现突破：

• 支持 14 种段落结构标签（如 Intro、Bridge、Interlude、Hook 等），实现段落级可控音乐生成；
• 覆盖从 C‑Pop 到 C‑Rap 的多种风格；
• 针对华语流行音乐深度优化，减少吞字、糊音与语言切换不自然等问题；
• 人声表现力增强，支持自然转音、颤音与共鸣切换；
• 扩展 100+ 乐器音色库，混音策略可随风格自动调整；
• 适配影视、游戏、流行制作与品牌声效等专业场景。

目前，Music 2.5 的 API 接口已在 MiniMax 开放平台上线。

相关链接：

https://www.minimaxi.com/news/minimax-music-25

API:
https://platform.minimax.io/docs/api-reference/music-generation

( @APPSO)

5、超越被动视频合成：LingBot-World 打造「可玩」的实时 AI 模拟器

灵波科技发布了开源前沿世界模型 LingBot-World，该框架被设计为交互式世界建模的新范式，旨在突破高保真仿真、精确控制以及物理与游戏世界建模的技术边界。

作为一款超越传统视频合成的工具，LingBot-World 通过学习大规模游戏环境中的物理规律和因果关系，实现了对复杂动态场景的深度理解与生成。

在发布演示中，一个持续运行长达一分钟的「龙」场景备受关注，直观展示了该模型在长时程一致性与记忆力方面的突破。即便在长达 60 秒的生成轨迹中，LingBot-World 依然能够维持清晰的视觉动态与连贯的结构逻辑，未出现长视频生成中常见的画质崩坏或逻辑断裂。

这种能力印证了模型随着规模扩大所涌现出的复杂行为——它不再仅仅是生成像素，而是展现了对空间逻辑、时间持久性及物理约束的真正理解。

技术层面，该系统由 LingBot-World-Base 和自主研发的可扩展数据引擎驱动，统一了物理世界与游戏世界的逻辑，从而实现了从合成数据到真实场景的稳健泛化。在动态离屏内存方面，模型表现出了超越基础物体恒存性的能力，能够持久记忆离屏角色的行为状态，确保视角回归时世界状态的自然演变。同时，模型强制执行符合实际的碰撞动力学，有效防止了角色穿模或无视障碍等幻觉现象。

尽管 LingBot-World 通过 LingBot-World-Fast 实现了低延迟推理和实时闭环控制，使其具备了「可玩模拟器」的雏形，但技术报告也客观指出了当前的局限性。高昂的推理成本目前仍依赖企业级 GPU，且由于内存机制源于上下文窗口而非显式存储，长时间运行仍面临环境漂移的挑战。

展望未来，研发团队将优先扩展动作空间与物理引擎，并计划引入显式记忆模块，以消除代际漂移，进一步推动稳健的无限时间模拟体验。

相关链接：
https://technology.robbyant.com/lingbot-world

( @Robbyant Official Website)

02 有亮点的产品

1、BoldVoice 获 2100 万美元 A 轮融资：通过自研模型实现音素级实时语音纠错

AI 语音教练平台 BoldVoice 完成由 Matrix 领投的 2100 万美元 A 轮融资。该公司仅凭 7 名员工实现 1000 万美元年经常性收入（ARR），旨在利用自研语音模型解决非母语英语专业人士的沟通障碍。

• 自研音素级分析模型：不同于针对转录优化的通用 ASR（自动语音识别）系统，其专有模型针对口音和发音细微差别进行训练，可提供实时的音素级反馈与纠偏。
• 极高的人效比表现：团队规模仅 7 人，目前已突破 1000 万美元 ARR，下载量超 500 万次，服务覆盖 150 多个国家。
• 垂直领域数据集优势：通过整合专家级语音教练的视频课程与海量重口音语音样本，解决了通用大模型在特定口音识别与细粒度发音指导上的精度不足问题。
• 高性价比交付模式：将传统线下真人教练 200-300 美元/小时的成本，降至低于单次课程费用的年订阅制，提供无限次的按需练习。

应用已在 Apple App Store 和 Google Play 上线，本轮融资将用于加速全球扩张及开发下一代自研专有语音模型。

( @PR Newswire )

2、Decagon 完成 2.5 亿美元 D 轮融资：估值达 45 亿美元，通过 AOPs 架构实现 80% 的业务自动闭环

Decagon AI 宣布完成 2.5 亿美元 D 轮融资，由 Coatue 和 Index Ventures 领投，投后估值在半年内翻三倍至 45 亿美元。该公司利用 LLM 构建具备任务执行能力的智能体，旨在从传统的「信息路由」模式转向「全流程问题解决」模式，目前已在 F100 企业中实现超 80% 的人工替代率。

• Agent Operating Procedures （AOPs） 架构：不同于传统的配置化脚本，AOPs 允许智能体像人类员工一样根据反馈动态调整执行路径，实现高复杂度的非线性任务编排。
• 深层后端读写能力：智能体不限于 FAQ 问答，可直接接入 CRM、计费及订阅系统，具备执行退款、变更套餐、账户核销等端到端业务权限。
• 多模态统一引擎：采用单一智能体逻辑层驱动 Chat、Email 和 Voice 渠道，确保在跨渠道切换时业务逻辑、用户上下文及品牌语调的高度一致。
• 80% 自动化拦截率：在 Avis、Hertz、Block 及 Affirm 等大型企业生产环境中，系统实现了超过 80% 的请求在无人工干预下完成闭环。
• Watchtower 自动化 QA 与反馈循环：系统可自动从历史对话中提取上下文并将其转化为指令集，通过自学习机制持续优化模型在特定业务场景下的响应精度与安全性。

( @SiliconANGLE、@Decagon Blog)

3、Genspark 推出 AI 听写工具 Speakly，集成 Agent 任务模式

Genspark.ai 推出的 AI 语音听写应用 Speakly 正式上线，支持 Mac 和 PC 平台。该应用主打将语音实时转化为经过润色的文本，速度达到传统打字的 4 倍，且广泛兼容各类主流应用程序，试图改变用户与计算机的交互习惯。

Speakly 内置「AI 自动编辑」功能，不仅进行基础的语音转文字，还能在记录过程中自动清理「嗯」、「呃」等口语填充词，修复拼写错误并优化排版格式。系统能够识别用户的自我更正逻辑，确保最终文本只保留有效意图。例如，一段包含口误、修改和犹豫的杂乱口述，经处理后可直接变为结构清晰的列表或通顺段落，无需人工二次编辑。

该应用提供灵活的「自定义指令」选项，用户可自行设定语音转文本的具体规则，一次设置即可重复生效。Speakly 预设了多种可即时切换的模式，包括将多语言转化为流利英语的翻译模式、把口述转为终端代码的命令行助手模式，以及优化职场表达的专业重写模式。此外，还包含了生成网络迷因风格的「混乱模式」和堆砌商业术语的选项。

面对更复杂的任务，Speakly 集成了「Genspark Agent 模式」。用户双击激活后，通过一个指令即可让系统执行深度搜索，或直接生成幻灯片、表格及文档。在兼容性方面，Speakly 覆盖了邮件、Slack、文档笔记及代码编辑器等 100 多款软件，并支持超过 100 种语言。其自动检测功能无需额外配置，即便在句子中间混合使用不同语言，也能准确识别并转换。

体验链接：
https://www.speakly.ai/zh-cn

( @gensparkspeakly\@X)

03 有态度的观点

1、新华社前瞻 2026 中国 AI 发展：不再只会聊天，技术范式全面转向智能体

昨天，新华社旗下《新华视点》公众号发表了 2026 年中国 AI 发展趋势前瞻，指出今年中国人工智能产业在技术范式、算力体系、数据要素、产业应用与治理体系等多个维度将迎来深度变革。

文章指出，随着以对话为核心的「Chat」范式终结，行业竞争正加速转向「能办事」的智能体时代，AI 正从语言智能迈向物理智能与生物智能的融合。

• 2025 年，中国 AI 企业数量已超过 6000 家，AI 核心产业规模突破 1.2 万亿元，同比增长近 30%；
• 国产开源大模型全球累计下载量突破 100 亿次，中国在全球 AI 专利占比达 60%；
• 进入今年，技术突破与场景落地同步深化，行业从「拼规模」转向「拼密度」，算法效率成为核心竞争力。

算法架构革新将成为未来突破关键：

专家认为，AI 将从「会说话的字典」演进为「能自主干活的管家」，具备任务规划、长期记忆与多模态理解能力。具身智能模型的突破意味着 AI 已具备理解并执行物理世界任务的能力。

算力方面，全国已建成 42 个万卡智算集群，智能算力规模超过 1590 EFLOPS。「东数西算」工程形成 8 大枢纽节点、10 个数据中心集群，算力正向高密度、规模化、绿色化演进。

业内预计，百万卡级集群将成为支撑万亿参数模型训练的基础设施。随着「全国一体化算力网」推进，算力调度与电力协同将成为关键能力。

数据要素成为新竞争焦点：

随着模型训练进入深水区，行业从堆量转向提质，高质量行业数据集需求激增。

国家数据局已在多地布局数据标注基地，截至去年三季度已形成 500 余个行业高质量数据集。数据标注从劳动密集转向知识密集，医疗、工业、交通等领域的专业数据成为提升行业模型性能的关键资源。

AI 在制造业、医疗、交通等领域加速渗透：

2025 年至去年底，中国日均 Token 消耗量从 1000 亿增长至 30 万亿，企业使用占比快速提升。

AI 在制造业的应用从研发、运营管理向核心生产环节延伸，汽车、电子、机器人等行业率先受益。工信部提出到 2027 年推广 500 个典型应用场景，推动形成行业大模型体系。

在社会治理与消费领域，AI 正重塑公共服务、城市治理与消费体验：

从城市大脑到智能监测系统，再到 AI 导购、车载语音点餐，AI 正从「技术可行」迈向「社会需要」。教育领域也在加速转型，AI 辅助教学推动复合型技能成为核心竞争力。

与此同时，AI 安全风险引发全球关注：

虚假信息、深度伪造、越狱攻击等问题凸显。我国正通过法律法规、行业标准与安全认证体系构建多层治理框架。《人工智能拟人化互动服务管理暂行办法（征求意见稿）》等政策体现监管的自适应性与前瞻性。

专家认为，AI 是驱动新质生产力的核心力量，也是影响未来社会运行方式的关键变量。如何在加速创新的同时强化安全治理，将成为今年中国 AI 发展的重要命题。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示：个人观点，仅供参考

在过去很长一段时间里，IP 只被视为一个单纯的网络出口标识。对多数用户而言，只要能够成功访问目标网站，IP来源并不会被过多关注。然而随着平台风控体系不断升级，IP 来源本身已经成为判断访问是否可信的重要依据。是否来自真实网络、是否符合地区属性、是否具备长期稳定的使用记录，正在被纳入平台的核心审核逻辑之中。

IP 来源合规性，正是在这样的背景下被重新定义。它不再只是一个技术细节，而是直接影响访问成功率、账号安全性以及业务连续性的关键因素。

平台风控为何开始关注 IP 来源

越来越多的网站不再满足于识别访问频率或请求行为，而是开始追溯 IP 背后的真实网络环境。非真实来源的 IP，往往缺乏正常用户的网络轨迹，其访问模式在大数据分析下极易暴露异常。这类 IP 即使短期可用，也很难维持长期稳定访问。

尤其是在内容平台、电商系统、广告系统以及数据接口中，平台更倾向于信任那些来源清晰、网络背景真实、使用行为自然的 IP。IP 是否来自真实家庭或企业网络，是否具备明确的 ISP 归属，已经成为系统判断访问是否合规的重要前提。

不合规 IP 带来的隐性风险

使用来源不清晰或被滥用的 IP，往往会带来一系列连锁问题。访问失败只是表象，更深层的风险体现在账号关联、行为标记以及整体网络环境被污染。一旦平台将某个 IP 段列入高风险范围，即使更换账号或设备，也可能持续受到影响。

对于需要长期运营账号、进行数据交互或保持持续访问能力的用户来说，这类风险是不可控的。短期节省成本，往往会换来更高的后期维护代价。

合规 IP的核心特征

真正具备合规性的 IP，通常拥有清晰的网络归属，其来源能够被平台识别为正常用户所使用的网络环境。这类 IP 在访问行为上更接近真实用户，不会因为异常流量特征而触发风控机制。

当 IP 的网络属性、地区信息与访问行为保持一致时，平台更容易给予信任。这也是为什么近年来住宅代理和高质量 ISP 网络出口逐渐成为主流选择的重要原因。

合规性对长期业务的价值

IP 来源合规性并非只为“通过检测”，而是直接关系到业务是否能够长期稳定运行。无论是内容访问、账号管理，还是数据获取，稳定且合规的网络环境都能够显著降低不确定性。

当访问不再频繁中断，当账号不再反复验证，当数据请求能够持续成功，整体运营效率会发生质的变化。这种稳定性，本身就是合规 IP 带来的长期价值。

如何构建合规且稳定的网络环境

在实际应用中，选择具备真实网络背景的代理服务，是构建合规访问环境的核心路径。以 IPPeak 为例，其提供的高匿名住宅代理来源于真实家庭网络，并具备明确的 ISP 归属。这种 IP 在平台视角中，与普通用户的网络访问几乎无异。

通过合理配置这类代理，用户可以在不暴露真实网络信息的前提下，建立一个长期稳定、低风险的访问环境。这种方式并不是为了规避规则，而是通过合规手段满足平台对“真实访问”的基本判断逻辑。

合规正在成为默认门槛

可以预见的是，未来平台对于 IP 来源的审核只会更加严格。合规性将不再是可选项，而是默认门槛。只有提前建立起稳定、真实、可信的网络环境，才能在不断变化的风控体系中保持主动权。

这里是 「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=2309405260627978616850 weibo.com/ttarticle/p/show?id=2309405260628431863821 weibo.com/ttarticle/p/show?id=2309405260628775534608 weibo.com/ttarticle/p/show?id=2309405260629144633358 weibo.com/ttarticle/p/show?id=2309405260629496954905 weibo.com/ttarticle/p/show?id=2309405260629849538576 实

摘要：
滔搏原采用 MyCat+MySQL+Oracle 混合架构，存在成本高、扩容难、数据一致性保障等问题。在数据库切换过程中引入 OB Cloud 后，依托其完善的兼容性、HTAP 融合能力、弹性扩展能力，优化表结构适配原分片策略，低改造完成迁移。升级后存储从 15TB 压缩至 0.9TB，SQL性能提升，扩容高效低风险，运维复杂度大幅降低。

日前，2025 OceanBase 年度发布会在北京举行。在云数据库+ AI 专场，滔搏数据库主管徐子清进行专题分享，介绍滔搏在数据库切换过程中引入 OB Cloud 后的应用实践。

她表示，此次切换并没有带来过高的业务改造或运维成本，不仅实现“无痛”切换和系统“瘦身”,也领略到 OceanBase 生态系统中工具的优秀和强大。

以下为演讲实录。

大家好，我是来自滔搏运动的徐子清，很高兴能与大家分享滔搏在数据库架构切换过程中积累的一些经验。

滔搏是中国领先的运动零售运营商，拥有广泛且深度下沉的零售网络，覆盖全国 300 多个城市近 5000 家直营门店，与 20 余个知名运动品牌深度合作，包括耐克、阿迪达斯、亚瑟士等。公司与超过 8000 万用户实现了无缝连接，为消费者提供优质商品、专业服务和美好体验。

随着公司规模的不断扩大，我们在数据库领域也面临着日益严峻的挑战和压力，公司数据库架构也经历多次调整。

数据库历经多轮迭代 OB Cloud 成终选

最早期时，我们采用的是集中式单库，各个地区如华南、华北、西南，分别自行负责本地的数据库系统，每个区域独立维护和运营。每天业务结束后，各地区将当日业务数据上传至总部系统。这样也就导致总部无法及时查阅当日相关数据，造成了数据实时性不足的问题。

2016 年，公司在数据库架构上进行了一次较大的变革，引入了主流数据库 MySQL，并结合 MyCat 中间件，打造分布式架构。随着业务发展，复杂场景越来越多，如总部的某些报表和财务系统新增需求，使得 MyCat 分布式架构也开始面临压力。继而引入了 Oracle 数据库系统，用于支撑报表和一些特殊场景。但近几年业务激增，新的问题也随之而来。

首先是数据库系统整体成本高昂。

之前，传统集中式数据库系统架构是一主四从，而 MyCat+MySQL 数据库架构里，由于数据库节点众多，同时还存在多种同步工具、运维平台等服务，整体服务器体量较大、硬件成本高。

其次，数据库性能方面也存在一定瓶颈。

在混合架构中，MySQL 主要负责在线事务处理（TP）业务，大部分即时性要求较高的分析型（ AP） 业务放在传统集中式数据库系统中运行。但在业务量持续增长的情况下，传统集中式数据库的扩容压力和难度不断增加，对业务发展形成一定限制。

另外，数据一致性的保障也存在一定挑战。

由于架构复杂，存在多种数据库系统之间的数据同步，不同系统之间要保障数据的一致性和实时性，极具挑战。遇到业务异常时，无法快速定位是 SQL 逻辑问题，还是基础表数据有误，亦或是数据同步异常导致数据缺失。排查难度大周期长，面临维护成本高的问题。

在 2019 年到 2020 年期间，业务规模持续扩张，市场需求超出预期，在系统本身面临多维度压力的情况下，我们最后考虑切换数据库系统。

基于时下分布式数据库解决方案综合优势尤为突出，因此将企业的业务系统陆续切换到了某分布式数据库平台。因财务系统最为重要且复杂，且对改造的可控性要求较高，当时并未进行数据库切换。随着业务发展，数据库切换成为势在必行的举措。经过多种方案调研测评，我们最终选择了 OceanBase。

目前，我们的财务系统均已部署到 OB Cloud 集群上。存在数据依赖的业务系统之间，用 OMS 工具进行数据实时同步。

多能力支撑 破数据库运维困局

整个数据库架构的演变，体现了滔搏随着业务发展不断探索和优化数据支撑能力的历程。但很多人会有这样一个疑问：优秀数据库系统那么多，为何最终会选择 OB Cloud？

结合公司业务进行总结，我觉得主要基于以下几方面的原因：

首当其冲是其完善的兼容性。OB Cloud 分布式特性与应用透明扩展非常契合我们的系统诉求。同时 OB Cloud 支持多租户的模式。这对于我们拥有多种数据库系统的企业来说意义重大。公司业务发展迅速，新的功能和需求不断增加，研发团队很难投入太多时间进行旧系统大规模改造。因此，兼容性成为我们选型时的重要考量之一。

高性能也是我们选择 OB Cloud 的核心原因之一。财务系统复杂、存在大量分析报表需求，还有不少小万行的 SQL 语句。切换至 OB Cloud 后，没有进行特定的 SQL 优化的情况下，部分业务性能已有明显提升。在 OB Cloud 技术专家的支持下，进行了诸如并行查询配置等建议后更进一步优化了我们的业务支持能力，带来了实实在在的体验升级。

弹性扩展能力也是 OB Cloud 的一大亮点。以电商业务场景为例，每逢“双十一”等促销活动期间，为防止业务流量激增、影响业务正常运行，往往需要提前一周甚至更久准备服务器，进行数据库系统扩容。传统架构进行扩容，普遍困难且复杂。而在 OB Cloud 上，我们只需提前一两天即可完成扩容部署，且对应用完全无感知，活动结束后还可及时收回资源，实现效率和成本的双重优化。

此外，OB Cloud 的 HTAP 能力极大简化了我们的系统架构。切换之前我们需要规划不同数据库系统处理不同模块的需求，切换至 OB Cloud 后，通过多租户模式，一套集群同时支持两种传统集中式数据库系统，将 TP 和 AP 的业务场景统一管理，还减少了业务系统之间需要进行数据同步的场景，维护成本大幅降低。

最后，是其卓越的易用性。由于 OB Cloud 高度兼容，所以相关使用者无需在开发、测试过程中花费精力学习新系统，研发同事可以“无痛”完成切换，运维和 DBA 团队也能做到零学习成本、无缝接纳。

作为使用者我必须特别提及的是OB Cloud 团队的技术服务支持到位。整个过程中，技术专家几乎 24 小时在线，在某些特定时期，也会进行现场支持。

OMS助力切换 实现“无痛”切换、系统“瘦身”

数据库的切换过程平稳高效。我们首先在 OB Cloud 上完成了数据库服务的部署，然后分别从我们各业务数据库系统进行数据同步。

在这个过程中，切身领略到 OceanBase 生态系统工具的优秀强大。个人最被征服的工具还是 OMS，它在我们切换期间不同阶段承担了多种维度的链路支持。OMS 不仅极高效且稳定的同步数据，也可以灵活地按需选择链路环节。

如，我们可以只对表结构进行迁移，也可以选择迁移表结构和全量数据，或者只进行增量同步。对于部分链路，也可以仅做数据校验而不进行数据同步。

在实际使用数据校验功能时，OMS 可详细展示数据库校验结果，一键生成数据修复 SQL，快速实现数据一致性。

总而言之，OMS 工具非常值得推荐，切换前后数据空间压缩比也令人满意。

在之前业务架构下，财务系统业务库的数据量约为 15 TB。引入某分布式数据库后有进行一定程度的去重，例如全局表只选取一个节点进行数据同步，使得数据规模大大缩减，数据量降到约 3.8 TB。而在切换到 OB Cloud 后，数据量又被一定比例压缩了，目前占用存储空间约 0.9TB。

通过数据量对比，可以明显看到切换过程中数据治理和结构优化带来的存储成本节省效果。

OB Cloud 工作台的“诊断”功能可以帮助我们实时监控和分析数据库的 SQL 运行情况。该页面直观呈现系统中出现的大 SQL、慢 SQL，可疑 SQL 等各类可能影响业务性能的 SQL 语句，我们能够清晰看到相关 SQL 实际执行耗时和资源占用情况，有效提升了我们对数据库运行状况的掌控能力。

最值得一提的是，这次切换并没有带来过高的业务改造或运维成本，反而带来了高效、低风险的体验，这一点值得点赞。

小贴士

回顾本次切换过程，遇到了不少具有代表性的问题。但在 OceanBase 的协助下，各种复杂问题都得到了有效解决，整体的使用体验很好。

以下是我们的解决方案，供参考，希望能带来帮助：

1.表结构需预处理。原系统的分库表在切换至 OB Cloud 时，需要对原有的分片策略和字段进行相应的分区调整。第一次同步时， OMS 工具检测到存在无主键或唯一约束的表、行迁移未开启等情况，这将直接影响切换后数据库业务是否能良好运行，需对相关业务表调整表结构后手动创建到 OB 租户；

2.从其他分布式集群同步至 OB Cloud 的过程中，OMS 消费 kafka 日志消息只支持特定 kafka 数据格式，会存在多字段唯一索引导致的数据消息串行，处理过程中不免会造成同步效率低下。遇到此类问题时，可考虑调整 OMS 任务中 kafka 数据类型的配置；

3.部分对象如物化视图，OMS 无法直接同步定义，需在相关表对象迁移成功后在 OB Cloud 端手工创建；

4.对于频繁删除、插入数据的传统集中式数据库业务场景，OMS 由于需先解析上游数据库日志文件，再进行 OB Cloud 上的回放，同步效率无法与原生主从同步机制相比。若部分非实时数据业务能接受一定滞后，可以考虑用 OMS 链路同步。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/