一、背景

一个项目中需要用到输入表情符号，全网找了半天都是国外那种样式的表情输入插件，而且又非常难看，不能自定义修改样式。于是乎自己直接上手干了。

二、支持功能

支持中文分类
支持中英文搜索
支持最近输入表情
支持自定义扩展更多的表情
支持输入框样式自定义

三、获取

源码可以来uniapp插件市场这里获取：https://ext.dcloud.net.cn/plugin?id=26914

四、使用方法

如果你是uniapp项目，下载后可以直接使用，代码会自动下载到你的uni_modules目录下并会自动加载组件，无需自己再引入组件；如果你是普通Vue项目，将下载下来的代码放到 components目录，然后手动引入下组件即可。

说明：没有做 npm 直接安装方式，主要考虑到开发者拿到代码后可以自行修改样式和功能。

Vue2 使用方法，Vue3兼容Vue2写法

<template>
    <div style="display: flex;align-items: center">
        <emoji-input v-model="inputVal" style="width: 500px"></emoji-input>
        <div style="margin-left: 10px">你的输入：{{inputVal}}</div>
    </div>
</template>
 
<script>
// 引入插件
import EmojiInput from "@/components/xv-emoji/emoji-input.vue";
 
export default {
    name: 'VueEmojiPicker',
    components: {EmojiInput},
    data() {
        return {
            inputVal:'',
        }
    },
}
</script>

如果对你有帮助，请动动你发财的小手指，给个小心心鼓励下我...

住宅代理是当前跨境营销、广告投放对抗平台风控的核心工具！随着2026年Meta与谷歌算法持续升级，平台对流量真实性、IP 质量、行为轨迹的检测达到新高度，不少从业者反馈账号因触发异常流量警报而受到影响。

因此，了解平台风控逻辑并选择合适的网络配置，成为维持稳定运营的关键。

算法升级：风控逻辑的底层变革

2026年开年，海外数字广告市场迎来新一轮合规整顿。Meta的仙女座算法不再依赖传统的人工定向标签，而是通过AI在早期解析素材结构并监控用户行为轨迹。与此同时，谷歌的算法开始对特定流量模式进行识别。

据了解，平台不再仅检查IP是否在已知名单，而是综合行为分析（请求间隔是否随机）、设备指纹（TLS指纹、时钟偏移）以及流量特征（是否包含真实浏览器的交互轨迹）进行判定。具有明显机器特征的访问行为，即使使用常规IP，也可能被标记并导致账号受限。

住宅IP：一种常见的风控应对方式

在与平台算法的长期互动中，住宅IP成为一种常见的应对方式。不同类型的住宅IP适用于不同场景：

动态住宅IP

动态住宅IP拥有较多可选资源。由于IP池规模大，可降低账号关联或重复操作带来的识别风险。在多账号管理或批量测试场景下，每次操作使用不同IP，行为特征更接近普通用户，有助于减少异常流量标记。

静态住宅IP

对于需要长期稳定运营的账户，静态住宅IP提供了另一种思路。通过为重要账户配置独立且长期使用的住宅IP，可在平台侧形成相对稳定的网络环境。一些业内人士认为，这种方式有助于提升账户在平台系统中的可信度，尤其适用于需要精细化运营的本地化业务。

关于代理服务的几点思考

面对2026年持续变化的平台算法，选择合适的网络配置需要综合考虑业务类型、操作频率和安全性需求。高性能住宅IP结合合理的操作策略，可以在保障账号安全的同时，提升数据准确性和运营效率，为跨境业务提供更稳定的网络基础。

核心问题
通过 lpush 把 URL 字符串放入 Redis，取出来时却是 bytes，需要手动 .decode('utf-8') 才能变回字符串。Redis 把字符串变成字节了吗？

根本原因：Redis 在协议层只认识字节
Redis 在协议层面（RESP 协议）只存字节（bytes），不存在"字符串类型"这个概念。
【写入】
Python str "https://example.com"

→ redis-py 自动 encode → bytes b"https://example.com"
→ 存入 Redis（Redis 只认 bytes）

【读取 - 默认行为】
Redis 返回 bytes b"https://example.com"

→ redis-py 原样返回 bytes
→ 需要手动 .decode('utf-8') → str

【读取 - decode_responses=True】
Redis 返回 bytes b"https://example.com"

→ redis-py 自动 decode → str "https://example.com"
→ 直接用 ✅

为什么 lpush 时感觉是"放字符串进去"？
因为 redis-py 客户端在写入时帮你自动编码（str → bytes），所以写入时感觉很自然。但取出时默认不做反向解码，原样返回 bytes。
这是 redis-py 的刻意设计：Redis 可以存任意二进制数据（图片、protobuf、序列化对象…），如果客户端自作主张解码，遇到非 UTF-8 的二进制数据就会直接崩溃。所以态度是："我不知道你存的是什么，原样还给你，你自己决定怎么处理"。

一劳永逸的解决方案：decode_responses=True
pythonimport redis

r = redis.Redis(

host='localhost',
port=6379,
decode_responses=True  # ← 加这个，所有返回值自动解码为 str

)

延伸：Set 里的 SHA1 哈希 和 ZSet 也是字节吗？
是的，Redis 里所有数据本质都是字节，SHA1 哈希"看起来是字符串"只是因为它的内容恰好是可读的 ASCII 字符。
类比理解

就像一张纸上写了 "hello"：纸上存的是墨水痕迹（物理载体，类比字节），人眼看到的是字母（解读结果，类比字符串）。纸不知道你写的是英文还是中文，Redis 也一样。

为什么 SHA1 哈希"看起来没问题"
SHA1 的十六进制表示只包含 0-9 a-f，全是 ASCII 字符，ASCII 与 UTF-8 完全一致，所以字节和字符串之间转换透明无损，感觉"就是字符串"。但如果存的是图片二进制数据，decode 就会直接报错，这才暴露了 Redis 底层只存字节的本质。
各数据类型对照表
数据你感知到的Redis 实际存的URL 字符串strbytes（UTF-8 编码）SHA1 哈希值（dupfilter Set）40位十六进制 strbytes（ASCII 编码，恰好可读）ZSet member（request）strbytesZSet scorefloat64位浮点字节

总结

Redis 只存字节这句话永远成立。SHA1 哈希"看起来是字符串"，只是因为它的字节内容恰好是可读的 ASCII 字符，本质上还是字节。写入时 redis-py 自动编码，读取时默认不解码——用 decode_responses=True 可一劳永逸解决。

核心问题
reqs = self.make_request_from_data(data) 返回的是一个 yield 生成器，为何还需要 for req in reqs 循环？

根本原因：一条数据可能产生多个请求
make_request_from_data 是一个生成器函数，它可以 yield 任意多次，并不限于一次。

典型场景举例
场景 1：一条数据对应多个接口
pythondef make_request_from_data(self, data):

base_url = data['url']
yield Request(base_url + "/detail")    # 详情页
yield Request(base_url + "/comments")  # 评论页
yield Request(base_url + "/images")    # 图片页

场景 2：分页请求
pythondef make_request_from_data(self, data):

for page in range(1, data['total_pages'] + 1):
    yield Request(f"{data['url']}?page={page}")

场景 3：多语言/多地区
pythondef make_request_from_data(self, data):

for lang in ['en', 'zh', 'ja']:
    yield Request(data['url'] + f"?lang={lang}")

代码逻辑的完整语义
pythonreqs = self.make_request_from_data(data)

if isinstance(reqs, Iterable): # 生成器/列表 → 可能多个请求

for req in reqs:
    yield req                   # 逐个转发
    found += 1

elif reqs: # 单个 Request 对象

yield reqs
found += 1

else: # 返回 None，无请求

self.logger.debug(...)

设计意图：防御性兼容三种返回值
返回类型走哪个分支说明生成器 / 列表isinstance(reqs, Iterable)循环展开，支持多个请求单个 Request 对象elif reqs直接 yieldNoneelse记录 debug 日志，跳过

总结

框架用循环是为了支持「一条数据 → 多个请求」的通用场景（分页、多接口聚合、多语言等）。生成器函数可以 yield 多次，循环是将这些请求逐个向上传递的标准写法。

开发者朋友们大家好：

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

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

01 有话题的技术

1、Anthropic 收购 AI 智能体初创企业 Vercept

2 月 25 日，人工智能初创公司 Anthropic 宣布收购 Computer Use 初创企业 Vercept。这是继去年 12 月收购代码智能体引擎 Bun 后，Anthropic 的又一动作。作为交易的一部分，Anthropic 将于 3 月 25 日正式关闭 Vercept 的云端产品 Vy（一款可远程操作苹果 MacBook 的智能体）。

Vercept 孵化于西雅图的 AI 孵化器 A12，其联合创始人多具备艾伦人工智能研究所的研究背景。据 Vercept 首席执行官 Kiana Ehsani 透露，公司总计融资金额达 5000 万美元，由 A12 的 Seth Bannon 领投。其天使投资人阵容包含前谷歌 CEO Eric Schmidt 与 DeepMind 首席科学家 Jeff Dean 等知名人士。

此次收购后，Vercept 的核心团队去向出现了明显的分化：

• 加入 Anthropic 的成员：包括 CEO Ehsani、Luca Weihs 和 Ross Girshick 三位联合创始人。Ehsani 认为，与其两家公司各自独立探索，不如合并团队以加速实现共同愿景。
• 未加入的联合创始人：此前被 Meta 以高达 2.5 亿美元薪酬挖角的 Matt Deitke，以及艾伦人工智能研究所创始领导者 Oren Etzioni 均未加入 Anthropic。

值得注意的是，这场收购在投资人之间引发了公开争论。Etzioni 在社交平台上对公司成立仅一年多便放弃独立发展、并要求客户在 30 天内撤离平台表示极度失望。他与领投人 Bannon 随后发生了激烈的言辞交锋，相互指责对方的决策失误甚至发出法律威胁。尽管交易细节未予公开，且 Etzioni 确认已获得资金回报，但他仍对团队未能继续独立运营感到遗憾。

( @TechCrunch)

2、开发者展示眼动追踪+语音+AI 融合交互，视线成为全新输入信号

近日，开发者 Yaku Zeg 展示了一项将眼动追踪、语音与人工智能相结合的交互演示。他提出一种前沿的交互理念：不论用户是进行触摸、指向、说话、注视，甚至是单纯地思考，未来的界面都应当能够妥善处理这些行为。

在具体的应用场景中，该技术将用户的视线不仅作为一种直接的输入方式，更主要的是将其定义为一种「微观意图（micro-intent）」信号，从而为系统提供额外的上下文背景信息。在技术栈方面，该演示内容是基于 SwiftUI 和 ARKit 框架开发完成的。

( @yakuzeg\@X)

02 有亮点的产品

1、MiniMax 上线 MaxClaw 功能

MiniMax Agent 的 Expert 2.0、MaxClaw 正式宣布上线。

据介绍，在 Expert 2.0 中，MiniMax 进一步优化了专家 Agent 的创建体验。用户不需要考虑 Skill、SubAgent、MCP 的配置，以及提示词的结构编排——只需用自然语言描述任务目标或能力需求，Agent 会根据目标完成 SOP 梳理、工具编排与能力配置。

官方还预告，下一代迭代中，Expert 2.0 将引入「创作者定价与分成机制」以及「团队内 Expert 共享」两项能力。

MaxClaw 方面，官方介绍其基于 OpenClaw 构建，直接集成在 MiniMax Agent 网页端，无需自备服务器或 API Key。

并且相较于直接使用 OpenClaw，MaxClaw 拥有「预置精选专家级 Skill」「自带 50G 专属云储存空间」等优势。未来 MaxClaw 还将支持「用户自定义专家」「多端协同」的功能。

目前两项新功能均已开放使用。

相关链接：https://agent.minimaxi.com/

( @APPSO)

2、谷歌官方「豆包手机」来了：Pixel 10 和三星 Galaxy S26 系列迎来 AI 操控手机功能

谷歌在三星 Galaxy S26 系列发布会上推出了一批新的 Android 功能更新，包括更多基于 Gemini 的工具，以及诈骗检测功能改进。

Gemini 应用中的新功能将允许用户将多步骤任务（如预订网约车或添加购物车）移交给系统。该功能将首先以测试版形式推出，在用户执行其他任务时在后台运行。用户可以通过通知实时监控 Gemini 的进度，以便随时了解其正在做什么并随时介入。

谷歌表示，该功能最初将仅限于某些食品、杂货或网约车应用。它将首先在美国和韩国的某些设备上推出，包括 Galaxy S26 系列和 Pixel 10 系列。

Android 的 Circle to Search 功能也获得了升级，使其能够同时搜索屏幕上看到的多个对象。其中一种实现方式是使用「find the look」进行全套服装搜索。一旦应用找到了被圈出的服装的所有单品，用户就可以进行虚拟试穿。这项功能将在 Galaxy S26 系列和 Pixel 10 系列设备上提供。增强后的功能还可以用于分析图像中的多个对象。

谷歌还利用 Gemini 为三星电话应用中的通话引入设备端诈骗检测。该工具在检测到通话中有人使用诈骗者常用的语音模式时提醒用户。谷歌表示，该功能在与联系人通话时从未被使用，默认关闭。

相同的技术和方法也将用于在 Google 消息中检测诈骗。目前，美国 Galaxy S26 上的电话诈骗检测仅支持英语。

所有这些新功能现已可在 Pixel 10 系列和 Galaxy S26 系列上使用，具体功能的市场可用性有所不同。

（ @IT 之家）

3、YouTube 将 AI 语音助手引入智能电视与游戏主机

2 月 19 日消息，客厅场景下的对话式人工智能竞争正日益升温。YouTube 成为这一领域的最新发力者，正式将其对话式 AI 工具扩展至智能电视、游戏主机和流媒体设备。这项此前仅限于移动端和网页端的实验性功能，如今直接登陆了家庭中最大的屏幕。

根据 YouTube 官方支持页面的说明，符合条件的用户可直接点击电视屏幕上的「提问（Ask）」按钮唤出 AI 助手。用户不仅可以选择系统基于当前视频推荐的问题，还能使用遥控器上的麦克风询问任何相关的细节（例如食谱中的配料或某首歌词的创作背景），并在不暂停视频或退出应用的情况下获得即时解答。目前，该功能仅面向 18 岁以上的特定用户群体开放，支持英语、印地语、西班牙语、葡萄牙语和韩语。

此举正值越来越多美国观众将电视作为访问 YouTube 的主要渠道。尼尔森在 2025 年 4 月发布的一份报告显示，YouTube 占据了电视观众总时长的 12.4%，超越了迪士尼和 Netflix 等大型平台。与此同时，其他流媒体巨头也在积极推进客厅场景的 AI 交互：

• 亚马逊：在 Fire TV 设备上推出 Alexa+，支持用户进行自然对话、获取定制化内容推荐，甚至搜索电影中的特定场景和演员信息。
• Roku 与 Netflix：Roku 的 AI 语音助手已能处理诸如「这部电影有多恐怖」等开放式提问；Netflix 也正在测试其专属的 AI 搜索体验。

除了对话式 AI，YouTube 近期还推出了多项利用 AI 优化电视观看体验的举措，包括将低分辨率上传的视频自动增强至全高清画质。平台还在持续推出评论摘要、AI 驱动的搜索结果轮播等功能，并于今年 1 月宣布创作者即将能使用 AI 生成的个人分身来制作 Shorts 短视频。上周，YouTube 还为 Apple Vision Pro 推出了专属应用，提供剧院级巨幕的沉浸式观影环境。

( @TechCrunch)

03 有态度的观点

1、来自 2028 的文章：AI 让裁员陷入死循环

近期，投资研究机构 Citrini Research 发布题为《2028 年全球智能危机》的推演报告，预测 AI Agent（智能体）的大规模普及将引发白领失业潮并导致全球经济结构性崩盘。

有趣的是，报告通过构建「2028 年宏观假想模型」，详细拆解了这一死循环的传导路径。

模型显示，在第一阶段，企业引入 AI Agent 大量裁撤知识型与中介型白领员工，大幅削减人力成本，短期内实现利润率激增与财报繁荣。然而，被裁撤的中产阶级群体恰恰是支撑现代消费经济体系的核心基石。

而伴随美国失业率在模型中被推高至 10.2% 的警戒线，宏观总需求出现结构性坍塌。

由于终端消费断崖式下跌，企业营收随之暴跌；为了在收入萎缩的困境中维持此前的高利润率及向股东交差，企业被迫开启新一轮更激进的 AI 自动化裁员，从而正式确立了「裁员-需求萎缩-营收下降-再裁员」的恶性闭环。

报告指出，在整个现代经济史中，人类智慧一直是稀缺的投入要素。一切都能复制或替代，但唯有能够分析、决策、创造、说服、协调的「智慧」，是没法大规模复制的。

人类智慧的稀缺性自带内在溢价，但机器智能正在广泛、甚至是合格且快速改进地替代着前者。 好在的是，我们是在 2026 年看到这篇报告。

( @APPSO)

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

写在最后：

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

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

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

想象一下，你寄送的重要快递被退回了，快递员不会直接丢弃，而是根据你的要求间隔几小时后重新投递，直到成功或达到最大投递次数。Apache DolphinScheduler的任务重试机制就是这种“智能重投”的调度系统版。

DolphinScheduler提供了完善的任务失败重试机制，支持业务任务节点在执行失败后自动延迟重试，直到成功或达到最大重试次数。该机制通过状态机驱动、事件发布和延迟队列实现，确保任务执行的可靠性。

核心机制：三步重试法

1. 失败时自动触发重试

当任务（如Shell脚本）执行失败时，系统会立即检查两个关键配置：

• failRetryTimes：最多重试几次（默认0次）
• failRetryInterval：每次重试间隔几分钟

这些配置在任务创建时设定，前端表单会将其转换为JSON格式存储。

2. 智能延迟计算

系统不会立即重试，而是计算精确的延迟时间：

// 实际延迟 = 配置间隔 - (当前时间 - 任务结束时间)
long remainingTime = TimeUnit.MINUTES.toMillis(delayTime) 
    + System.currentTimeMillis() 
    - taskInstance.getEndTime().getTime();

这确保无论任务何时失败，都能保持固定的重试间隔。

3. 状态机驱动重试

重试过程由状态机精确控制：

1. 失败状态：收到失败事件后，检查是否还能重试
2. 重试状态：创建新的任务实例（保持首次提交时间不变）
3. 重新执行：发布启动事件，任务重新进入调度队列

关键特性：哪些任务能重试？

✅ 支持重试的业务节点

• Shell脚本任务
• SQL查询任务
• Spark计算任务
• 所有实际执行代码的任务 5

❌ 不支持重试的逻辑节点

• 条件分支节点
• 子流程节点
• 依赖检查节点
  这些节点只控制流程走向，不执行具体代码 5 。

实战验证：测试案例

集成测试展示了完整的重试过程：

1. 任务A首次失败（retryTimes=0）
2. 系统自动重试1次（retryTimes=1）
3. 两次任务实例保持相同的firstSubmitTime
4. 最终失败后工作流停止 6 。

特殊场景处理

依赖任务等待

如果任务B依赖任务A，当A失败但未达最大重试次数时，B会进入等待状态而非直接失败 7 。

手动干预能力

即使任务正在等待重试，你仍可以：

• 暂停任务（取消后续重试）
• 终止任务（强制停止）
  系统会优雅地处理这些中断请求 8 。

容错 vs 重试：重要区别

• 任务重试：任务代码执行失败后的自动重试
• Worker容错：当Worker服务器宕机时，Master接管并重新调度任务（包括Yarn任务） 9

运维建议

1. 合理设置重试间隔：避免过于频繁的重试导致系统压力
2. 区分任务类型：为关键任务设置更多重试次数
3. 监控重试指标：关注retryTimes字段，识别不稳定任务
4. 理解逻辑节点限制：不要期望条件分支会自动重试

总结

Apache DolphinScheduler的重试机制就像一个尽职的调度员，在任务失败时不会轻易放弃，而是按照你的要求智能地重新尝试。通过状态机精确控制、延迟计算和事件驱动架构，确保了分布式环境下任务执行的可靠性。记住：只有真正执行代码的业务节点才能享受这种“重投”服务，而逻辑节点则需要你手动处理异常情况。

Notes

• 重试间隔以分钟为单位，实际延迟计算会扣除任务已结束的时间
• 每次重试会创建新的TaskInstance记录，但保持firstSubmitTime不变
• Worker宕机触发的容错重试与任务失败重试是两种不同的机制
• 逻辑节点（如子流程）不支持自动重试，需要手动干预

智能客服新选择：访答网页版

在数字化服务日益普及的今天，访答智能客服网页版为企业提供了一种轻量高效的客服解决方案。

什么是访答智能客服网页版？

访答是一款专为企业官网设计的智能客服工具，通过一行代码即可嵌入网站，无需技术团队介入，5分钟内就能上线专属客服机器人。它基于深度优化的中文RAG技术，能够精准理解用户问题并给出可靠回答。

核心优势

• 零开发成本：直接将生成的代码嵌入官网HTML即可
• 智能问答：深度学习官网内容，构建专属知识库
• 多模态识别：支持图片、图文混排等内容的解析
• 溯源导航：自动提供参考链接，增强回答可信度

为何选择访答？

相比传统客服系统，访答最大的优势在于部署简单、响应精准。它不仅能7×24小时不间断服务，还能通过一键更新知识库保持内容同步，大幅降低企业客服成本。

对于寻求高效客服解决方案的企业来说，访答智能客服网页版无疑是值得尝试的选择。

在快速迭代的业务场景中，开发人员常常需要为各种数据模型（如用户、产品、订单）重复构建列表、新增、修改、详情等页面。这个过程既耗时，又容易出错。
低代码开发平台以高效便捷的开发方式，可以基于模型生成设计，能够将复杂的数据结构转化为用户界面元素的过程，旨在以直观和高效的方式展示和操作数据。
以国内成熟的JVS低代码平台为例，系统提供了根据模型生成设计，你只需要明确数据模型中包含哪些实体（如用户、产品、订单等），并对每个实体，列出其所有属性元素类型（如文本、图片、链接、时间等）。
最后直接通过界面化操作就可实现模型生成列表、表单设计，并可实现对数据的简单增、删、改、查操作。

创建模型

创建模型入口，如下图
目录上快捷创建模型，若有设计模型字段，会自动创建列表页以及相关的新增、修改、详情表单

开始页面创建模型同目录上创建模型一样，创建成功后自动生成相关列表、表单

数据模型列表创建模型，需要手动生成设计

在系统应用后台，点击【数据模型】如下图，点击【新增】按钮

弹框输入模型名称，并点击【新增】字段

①名称：模型名称
②显示名称：显示中文名
③字段名：显示字段名，不能包含空格和特殊符号
④字段类型：组件类型，用于存业务数据
最后点击【提交】即可增加一个模型数据，在模型列表还可以点击【修改】【详情】【删除】按钮操作对应模型数据

①修改：修改模型名称、字段信息
②详情：查看模型数据信息
③生成设计：生成对应列表、表单
④删除：删除该条模型数据
生成设计
在模型数据有字段信息的前提下，点击【生成设计】按钮，如下图
注意：同一个模型可以重复生成列表页、表单设计， 但不会覆盖已有的列表和表单设计
提交后在左侧应用目录下新增个对应模型名称的目录菜单
点击目录菜单即可进入生成的列表页面

点击【新增】【修改】【详情】按钮分别打开生成的表单页面

新增表单

修改表单

详情表单

在线demo：https://app.bctools.cn
基础框架开源地址：https://gitee.com/software-minister/jvs

“AI+MES”正在从一种技术趋势，转变为制造企业生存和发展的核心驱动力。
根据最新的行业数据（2025-2026年），这一融合正在彻底重塑制造业的格局。以下是基于当前市场动态和技术落地的深度解析：
核心变革：从“记录系统”到“思考系统”
传统的MES（制造执行系统）主要功能是记录生产数据、追踪工单和执行流程，往往是“事后诸葛亮”。
而万界星空科技AI+MES正在将其升级为具备预测和决策能力的“工厂大脑”：
被动响应 → 主动预判：传统MES在设备故障后报警；AI+MES通过振动、温度等数据分析，提前预测故障（预测性维护），避免非计划停机。
经验驱动 → 数据驱动：传统排产依赖老师傅经验；AI算法结合订单、物料、设备状态，实现智能APS排产，动态调整生产计划以应对插单或急单。
人工质检 → 智能视觉检测：结合计算机视觉（CV），AI能实时识别微小缺陷，准确率远超人工，且能自我迭代学习新缺陷类型。

2026年的关键市场趋势
根据最新行业报告，2026年中国MES市场呈现以下显著特征：
市场规模爆发：预计2026年中国MES市场规模将突破200亿-400亿元人-民-币，年复合增长率保持在20%左右。
国产化替代加速：国产厂商凭借对本土场景的理解和AI大模型的快速落地，正在打破西门子、达索等外资品牌在高端市场的垄断。
渗透率提升：离散制造业（如汽车、电子）的MES渗透率已超35%，流程制造业（如化工、制药）也在快速跟进。
技术标配化：具备AI智能排产、边缘计算、数字孪生能力的MES系统已成为头部企业的标配。数据显示，这类系统能帮助企业缩短28%的订单交付周期，提升15%的设备综合效率（OEE）。
AI赋能的三大核心场景
A. 智能生产调度 (Intelligent Scheduling)
痛点：多品种小批量生产导致换线频繁，传统排程难以应对突发状况。
AI解法：利用强化学习算法，实时计算最优排产方案。当某台设备故障或物料延迟时，系统秒级重排，最小化对整体交付的影响。
B. 质量管控与根因分析 (Quality & Root Cause Analysis)
痛点：质量问题发现滞后，难以定位根本原因。
AI解法：AI关联人、机、料、法、环全维度数据。一旦发现不良品，系统自动回溯分析，指出是“某批次原料”、“某刀具磨损”还是“特定工艺参数”导致的问题，实现闭环改进。
C. 设备预测性维护 (Predictive Maintenance)
痛点：定期保养过度或不足，意外停机损失大。
AI解法：基于IoT传感器数据构建设备健康模型，精准预测剩余寿命，实现“视情维护”，大幅降低备件库存和停机时间。
面临的挑战与未来方向
尽管前景广阔，但企业在推进“AI+MES”时仍面临挑战：
数据孤岛与质量：AI的效果取决于数据质量。许多工厂底层设备协议不通，数据清洗难度大。
人才短缺：既懂制造工艺又懂AI算法的复合型人才极度稀缺。
落地成本：对于中小企业，高昂的定制化开发成本仍是门槛。因此，"云原生+SaaS化+行业套-件"的模式正在成为主流，以降低试错成本。
总结
AI与MES的集成不再是“锦上添花”，而是制造企业迈向“智能制造”的入场券。
2026年，成功的制造企业不再是那些拥有最多机器人的企业，而是那些能够利用AI+MES系统，让数据在生产全流程中自动流动、自动决策、自动优化的企业。对于管理者而言，现在的核心任务不是“要不要做”，而是“如何快速找到适合自身行业的AI+MES切入点”。