![\"\"](\"https://p1.meituan.net/meituantechblog/d5ec816eb81fe77b4adce7273e08904e1016613.png\")
美团正式开源 LongCat-Video-Avatar 1.5，作为一款从开源 SOTA 迈向商业级应用的数字人视频模型。在唇形同步、物理合理性、长视频稳定性、多人互动和高效推理上实现了全面跃升。LongCat-Video-Avatar 1.5 即便在复杂商业场景里，也能稳定、自然地输出高质量内容，让数字人视频生成从彩排室的完美演练，走向千人千面的真实舞台。
\n为了让数字人\"更稳定、更自然\"地动起来，我们在以下三方面实现能力升级：
\n开源链接
\n在音频特征提取环节，我们将编码器从 Wav2Vec2 升级为 Whisper-large。更大的参数量和更丰富的多语言先验，让模型能够更细致地捕捉音素变化、发音节奏和多语言韵律，准确理解\"每一刻应该如何开口\"。这一升级同时提升了唇形同步与全身时序稳定性——面部表情、头部姿态、肩颈和肢体动作与语音更自然地协同，大幅减少了长视频中的抖动、跳帧、画面冻结和身份漂移。
\n综合评测中，LongCat-Video-Avatar 1.5 的自然度、真实感和稳定性均优于部分头部闭源模型，基础生成能力满足商用需求。
\n\n商业场景中数字人形态多样（真人、虚拟偶像、动漫角色甚至动物），要求模型具备强开放域泛化能力。数据质量直接决定生成上限，为此我们构建了一套多阶段数据处理流程：
\n
同时，我们专门构建了三类增强数据来应对虚拟人生成的典型难点：
\n这套数据体系为模型在复杂场景中的稳定输出奠定了坚实基础。
\n\n在高质量数据的基础上，我们进一步针对手部稳定性和动作连续性进行专项优化。引入 GRPO（Group Relative Policy Optimization） 进行人类偏好对齐，将奖励信号细化到逐帧层面，精准修正动作不连贯、手部变形、短时结构崩塌及表情与语音不匹配等局部问题。
\n针对图像到视频和视频续写任务，我们还加入首帧手部检测机制，优先提高含可见手部样本的训练比例，显著缓解手部畸变。得益于此，模型在电商直播、产品展示、教学演示等场景中的自然度与稳定性得到进一步提升。
\n\n商业级数字人不仅要\"像\"，还要\"快\"。推理成本降不下来，再好的效果也只能待在实验室里。
\nLongCat-Video-Avatar 1.5 采用 DMD（Distribution Matching Distillation）蒸馏，将原本 50 步的生成过程压缩到 8 步。同时，我们用一个共享基础模型 + 多个 LoRA 适配器替代传统三模型并行的方案，大幅降低显存开销。
\n实际测试中，实现约 15 倍推理效率提升，生成 10 秒视频仅需约 1 分钟。
\n我们基于 EvalTalker 构建了综合评测基准，覆盖新闻、教育、娱乐、商业等场景，并按音频（语速、情绪）和视觉（人数、姿态、遮挡）设置不同难度。由 770 名评估者完成 13,240 条主观评分，并由 10 名领域专家进行结构化质量分析。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/280eeb0d7446714600bf97473b4a5b7257738.jpg\")
![\"\"](\"https://p0.meituan.net/meituantechblog/2589b312161be22864087f33ffe3b53873668.png\")
在物理合理性、时间稳定性、身份一致性和音视频协调性四个维度上，LongCat‑Video‑Avatar 1.5 的雷达图面积处于领先水平，其在画面物理合理性、时间稳定性、身份一致性和音视频协调等方面表现更均衡。在用户偏好方面，LongCat-Video-Avatar 1.5 相比 Kling Avatar 2.0 胜率 65.9%，相比 OmniHuman‑1.5 胜率 61.1%，相比 HeyGen 胜率 54.3%，整体优于其他商业系统。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/c9dbe3e16e264318635628966f22643b384948.png\")
在面部-身体同步和唇形同步方面，LongCat-Video-Avatar 1.5 同样取得最佳表现。面部-身体同步问题率为 5.1%，唇形同步问题率为 29.8%，均低于其他对比模型，说明模型在说话人的音频、唇形、表情和动作的整体协同上更加自然。
\n整体来看，LongCat-Video-Avatar 1.5 在效率提升的同时，仍保持了高质量的生成能力。不仅在单人场景的自然度和真实感上保持 SOTA 表现，也在多人互动、长时序稳定性、物理合理性和音视频协调性等关键维度上展现出更强的商用潜力。
\nLongCat-Video-Avatar 1.5 的开源，不只是模型版本的更新，更是面向开发者和创作者的邀请。
\n数字人视频生成正在从\"展示效果\"走向\"真实使用\"。在这个过程中，模型会遇到更多开放场景：不同角色、不同语言、不同内容形态，以及更复杂的业务需求。我们希望 LongCat-Video-Avatar 1.5 能成为一个可验证、可改进、可共建的技术基座，让更多人基于它探索数字人视频的真实应用边界。
\n模型和代码已经开放。欢迎大家在自己的场景中使用、测试和反馈，也期待和社区一起，把开源数字人视频模型继续向前推进。
\n开源链接
\n大模型在 AIME、IMO 等高难度竞赛中拿奖拿到手，仿佛已经进化出了“人类最强大脑”。但与此同时，如果你问大模型：“离洗车店只有 50 米，我是开车去还是走路去？”。这些号称满分推理的模型，依然会一本正经地为你规划导航路线。
\n这种看似知识丰富，但没常识的现象，正是当前大模型评测的死穴：大模型虽然擅长记忆复杂的公式，却常常连一道简单的逻辑题都答不对。
\n基于此，美团 LongCat 团队正式发布 General 365。我们发现，在对 26 款主流模型的实测中，目前地表最强的 Gemini 3 Pro 准确率仅为 62.8%，而绝大多数模型甚至没能摸到 60 分的及格线。
\n这份基准将焦点从“学科推理”拓展到“通用推理”，第一次清晰地勾勒出了当前大模型在通用逻辑推理上的真实能力边界。
\n过去两年，大模型推理评测高度集中在数学、物理、编程等依赖专业知识的任务上，头部模型在各大题库上甚至逼近满分。然而，学科推理得分高，并不等于通用推理强——高分可能源于模型对训练语料的暴力记忆与模式匹配，而非可泛化的逻辑推演能力。现有通用推理基准（如 BBH、BBEH）面临两大瓶颈：任务模板化导致逻辑同质严重，性能饱和导致区分度断崖式下降。
\nGeneral 365 的设计目标由此明确：将背景知识限定在 K-12 水平，显式解耦推理能力与专业知识，系统地评估模型在日常场景下的通用推理水平。它具备五项核心特征：
\n要衡量通用推理，首先要明确它包含哪些核心挑战？General 365 将其拆解为八个维度，每道题至少对应其一：
\n![\"八个类别的题目数量分布\"](\"https://p0.meituan.net/meituantechblog/e1f3bc5188020ba970529b35ff865bce131464.png\")
如上图所示，“复杂约束类”题目占比最大，“概率与不确定性类”也包含超 20 道题目，确保了每个维度都有充足的样本支撑。
\n![\"多标签题目的数量分布\"](\"https://p0.meituan.net/meituantechblog/8fe23867d38cbe991816c9680d08603d124257.png\")
如图所示，近 70% 的题目同时具备两个或以上的类别标签，这种复合型的推理任务设计更贴近真实世界的逻辑复杂度。
\n题目质量是评测基准可靠性的根基。General 365 的种子题目全部人工原创，并经难度过滤、多样性扩充、数据后处理、模型扩题与人工审核，最终形成 1460 道高质量题目。为确保多样性经得起检验，团队从以下两个维度进行了验证：
\n![\"三个基准的](\"https://p0.meituan.net/meituantechblog/b447b6638b46641235f7326be046187c217017.png\")
![\"三个基准的推理路径相似度评分分布\"](\"https://p0.meituan.net/meituantechblog/5497ef200086d27c35a231a4f015eea6128701.png\")
手握这把精心校准的“标尺”，LongCat 团队对 26 款主流大模型展开了全面摸底。
\n![\"26](\"https://p0.meituan.net/meituantechblog/01b440f62a834311dfbdd6f76ffcbf67246323.png\")
实测结果显示，Gemini 3 Pro 以 62.8% 的成绩艰难夺冠，绝大多数模型则深陷 50%-60% 之间未能触及及格线。值得注意的是，尽管非推理模型整体略逊一筹，但 Qwen 3 Max Instruct 等个别模型依然展现出了亮眼的表现。
\n![\"各模型在八个类别上的准确率明细\"](\"https://p0.meituan.net/meituantechblog/917e1f10d766ed8d342753fcfcb6cb50574732.png\")
将成绩按八大维度分解后，我们清晰地看到，“语义干扰”与“最优策略”成为主要的性能洼地。模型在这两项上的得分普遍比整体准确率低了约 10 个百分点。这不仅暴露出大模型极易被题干中的干扰信息带偏，更凸显了其在多步全局规划能力上的匮乏。
\n![\"不同模型系列在八个类别上的雷达图\"](\"https://p1.meituan.net/meituantechblog/5766456bd9bae72c7ab0bcdaf51087bc323516.png\")
如雷达图所示，不同系列的模型在\"隐式信息\"等任务上展现出了明显的能力分化。
\n![\"准确率与平均输出](\"https://p1.meituan.net/meituantechblog/6a57bf6a0df50a75e1d9956324bf198d201174.png\")
在关注“答得对不对”的同时，“花了多少算力答对”同样重要。如图所示，Gemini 3 Pro 仅用约 14k tokens 就拿下了最高分，而取得相近准确率的其他模型，其输出长度普遍暴涨至 25k-30k tokens。
\n![\"三个基准性能对比\"](\"https://p0.meituan.net/meituantechblog/1c4d41ee557852fd3117174728db5c03117049.png\")
General 365 的难度究竟提升了多少？如图09横向对比所示，各大模型在 General 365 上的准确率较 BBH/BBEH 都普遍出现了大幅下降的情况。其中 GPT-5-Thinking 在 BBH 上准确率为 92.0%，在 General 365 上仅为 58.6%。
\n更重要的是，如下图所示，模型在 General 365 上虽然准确率明显偏低，但平均输出长度却显著增加。这有力证实了其难度来自更深的逻辑链条，而非毫无意义的字数堆砌。
\n![\"三个基准上准确率与输出长度的关系\"](\"https://p0.meituan.net/meituantechblog/8691d476c297eb26d95b8ec62d703a0f156374.png\")
General 365 将推理评测从专业知识依赖中剥离出来，让我们直观地看到了大模型在真实世界的通用推理任务上的短板。General 365 的初衷不是为了在榜单上再多一个 99% 的高分，而是为了寻找那条让模型从“做题机器”走向“人类智慧”的必经之路。毕竟，一个能解出 IMO 难题却回答不出「走路洗车」的模型，还不能被称为真正的智能。
\n我们诚邀广大社区开发者与研究者加入，共同探寻大模型逻辑进化的下一个奇点。
\n项目已全面开源，并会持续维护和更新，欢迎体验与探讨：
\n当团队 90% 以上的代码由 AI 生成，31 万行的复杂业务系统还在高速膨胀，你会发现一个反直觉的事实：AI Coding 不会自动收敛复杂度 —— 没有统一规范的约束，不同人用 AI 写出的代码风格各异，系统反而会加速腐化。
\n本文记录了我们如何在不停止业务交付的前提下，完成这场重构。在这个过程中，我们积累了三个关键经验，希望这篇实战经验能提供一些可复用的思路。
\nAgent评测系统长期承载多个核心业务场景，它同时承担了数据生产、流程编排、质量控制与多人协作等复杂能力，业务复杂度和工程复杂度都很高。具体来看，我们面对的复杂性主要体现在三个维度：
\n当业务进入快速迭代与试错期，上述庞大的业务体量与原有底层架构之间的矛盾就会集中爆发，迫使我们必须启动本次大规模重构。核心动因直指以下三个痛点：
\n1. 业务模型亟需升级，旧架构无法支撑探索性业务
\n随着业务交互的丰富度和复杂度增加，旧有数据模型扩展能力不足导致“烟囱式”功能开发，几乎每新增业务形式都需要新增代码来实现。
\n2. 代码严重腐化，技术债拖垮迭代效率
\n过去长期采用“按需求建包”的模式开发，代码缺乏合理的工程分层，Controller 等各种复杂逻辑揉在一个包内，形成了严重的“面条式代码”。在 31 万行代码的体量下，这种深度的技术债让日常开发“牵一发而动全身”，导致一线同学开发异常痛苦，交付效率遭遇严重瓶颈。
\n3. 协作模式风险放大，缺乏规范的 AI Coding 加速系统腐化
\n一年左右的时间，团队成员规模增至 3 倍，并且团队成员技术背景复杂，涵盖高并发、机器学习离线训练、管理后端开发以及实习生，复杂业务系统开发经验不足。在这样一个高人员流动和跨技术栈的背景下，再叠加 90% 以上代码由 AI 辅助编写这一事实，如果不建立硬性的底层架构规范，不同背景的同学各自用 AI Coding，系统必将以极快的速度产生不可控的腐化与新债。
\n因此，我们不仅需要工程重构，而且要建设符合 AI Coding 规范的工程重构。规范才可以帮助我们团队消灭旧技术债，规避新技术债。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/1c5fff78273feaf4892b46ad3fb757956195300.png\")
在需求高压背景下，要梳理技术债面临着一个极其现实的困境：量太大，根本看不完，也看不全。
\n面对膨胀至 31 万行以上的代码库，试图靠人力逐行阅读来建立全局的可靠认知是不现实的。我们的代码库中同样伴随着典型的高危特征：很多地方文档不全、大量隐式逻辑和历史兼容分支藏在细节里。一个看起来不起眼的接口，背后可能挂着一串极长的调用链。所以，梳理技术债最大的难点，在于人力永远无法在短时间内穷举和穿透这些错综复杂的关联逻辑 —— 单段代码谁都能读懂，但没人能在短时间内把 31 万行的调用链全部穿透。
\n我们采用的是一种更适合复杂系统的方式：“专家经验定向 + AI 辅助排查”。
\n不再试图人工遍历，而是由核心开发圈定高危的排查边界，然后把穷举和扫描的脏活累活交给 AI。通过这种方式，我们快速摸清了系统底层的 P0/P1 级技术债（如业务模型缺陷、数据库查询性能隐患、状态管理技术债、索引技术债等）。
\n这一步中，我们最大的体会是 AI 很适合帮我们把问题“看全”，但什么问题最重要，什么问题值得优先改，还是要由人来判断。具体来说，人负责圈定 P0/P1 级问题和优先级，AI 负责在圈定的方向上做穷举扫描——比如梳理业务模型问题、定位大数据量性能隐患、排查状态管理和索引层面的技术债。
\n实践下来，这一步的 ROI 很高。我们仅仅投入了有限的资源，就完成了 3 个 P0 技术债和 2 个 P1 技术债的梳理。但最让我们意外的是下面这件事：
\n\n\n短时间内，工程师就利用 AI 辅助精准定位了 10 个隐藏极深、靠肉眼极难发现的性能隐患。 这些隐患藏在复杂的调用链深处，即使是资深工程师逐行阅读也很难穷举到。这在纯人工阅读代码的模式下是几乎不可能的。
\n
这个结果迫使我们重新思考“经验”的定义。过去，“能看全”是资深工程师的核心壁垒 —— 你需要在系统里泡三年，才能建立起对调用链、隐式依赖和历史兼容逻辑的全局感知。但 AI 把“看全”的门槛打到了几乎为零。经验的价值正在从“能看全”转移到“能判断什么重要”——这才是人不可替代的部分。
\n这一步对我们后面的启发很大，因为只有问题定义清楚了，后面的规范、分层和迁移，才不会做成无源之水。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/8e1adbedb5a4ba7538ee34cb450750e02585642.png\")
通过技术债梳理，我们解决了重构哪里的问题，那么接下来要解决的就是“代码应该怎么写”。在全员 90% 代码依赖 AI Coding 的现状下，核心要解决的问题是“如何将一两个用好 AI 的人的经验，高质量泛化到全组”。
\n在传统研发模式下，开发规范的主要作用是帮助团队协作、Code Review 和新人上手。但当 AI 已经成为主要编码产能后，规范的意义发生了本质变化。大模型生成代码时，会强依赖当前上下文和现有代码模式。如果代码库本身风格混乱、团队对规范理解不一致，AI 不会自动纠偏，反而会把差异进一步放大，导致多人协作下持续产出”千人千面”的代码。因此，AI Coding 时代的研发规范已经升级为约束 AI 产出、阻止系统继续长新债的基础设施，远不止协作建议那么简单。
\n但只让 AI 遵循规范还不够 —— AI 只能执行输入，不能替代团队形成统一判断。如果团队成员自己没有先对齐分层原则、建模方式和依赖边界，同一份规范就会被不同人解释成不同版本。
\n这个问题让我们想到了自己的本职工作。我们团队负责 Agent 评测业务，在长期实践中沉淀出一套核心理念：
\n我们发现，管理 AI Coding 与评测 Agent 的底层逻辑一模一样。 先通过规范拉齐团队的工程标准（人人对齐），再通过 AI Rule 和 Skill 约束大模型的生成结果（人机对齐）。一个做 AI 评测的团队，用评测的思维解决了工程治理问题。
\n顺序至关重要：先”人人对齐”，再”人机对齐”。 很多团队以为配置好 AI Rule 就完事了，但真正的瓶颈在人，不在工具。团队自己没有统一共识，AI Rule 写得再好也会被不同人解释成不同版本。人的共识是 AI 约束的前提。
\n我们先调研了业内成熟团队的研发规范，并结合自身流程，沉淀出一套 AI 友好的工程约束，包括工程分层规范、业务域模型规约和仓储层规约。关键一步是没有把规范停留在文档层面，而是将其落地为 always 级别的 AI Rule，用于约束 AI 编码过程，并前置到预 CR 环节，帮助研发在提交前完成基础规范校验。
\n与此同时，针对最容易产生分歧的领域职责划分问题，我们围绕”编排类”与”能力类”的职责边界进行了组内统一，并将共识沉淀为编码时渐进式加载的 Skill。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/b881ed542ea63d06cd4f2a56686d24942443923.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/88b1f3ae86144c7deeb58d47a03ef6141550224.png\")
我们将过去“按需求建包”的面条式代码，逐步迁移到标准四层架构（Starter / Application / Infrastructure / Common）以及按业务域组织的新结构中。但这次重构的重点，并不只是物理目录的调整，而是借此机会系统性治理历史代码中长期存在的深度耦合问题，尤其是底层数据对象 PO 在全链路中的泄露与上浮。围绕这一问题，我们分三步推进：第一步，补齐业务对象与数据转换层，收口散落各处的转换逻辑；第二步，在 Application 层重建接口契约，严格阻断底层数据对象向上层泄露；第三步，基于新契约修复上游全链路的参数依赖。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/c432e3ba3641f401f84d442769382524379599.png\")
这类重构的特点是：改造规则相对明确，但涉及范围极广、重复劳动密集。我们的做法是先由重构主 R 亲自完成两个最复杂包的迁移，在过程中沉淀出一套可让 AI 执行的标准化迁移 SOP。有了这套 SOP，重构工作不再依赖某一个人的经验——团队其他成员只需按照 SOP 指导 AI 完成剩余包的迁移，研发本人聚焦业务语义验收和 Code Review 即可。通过这种“主 R 打样 → SOP 分发 → 全组并行执行”的方式，我们快速完成了十余个核心包的工程结构迁移。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/fe509bdfeca90d7ad1ea923b9314577f501480.png\")
本次重构的深水区。行业里谈重构，通常只有两条路：要么推倒重来，要么申请专项排期。我们走了第三条路 —— 把技术债拆解为业务需求的“顺带动作”，借着迭代渐进式消化，没有申请一天专门的重构时间。
\n具体做法是将技术债拆解到日常高优需求中。例如，借着某个核心功能迭代需求，顺势设计并落地了全新的业务模型；借着另一个功能升级需求，我们设计了全新的质检业务模型，并在 3 月下旬完成了全量迁移（一举兼容了多条业务链路，以及多视图、多区域的复杂交叉验证）。
\n这条路的难点在于拆解的精度——哪些业务需求能“顺带”消化哪些技术债，需要逐个判断：既不能让重构拖慢业务交付，也不能让业务需求绕过技术债继续堆新债。最终我在不停止业务交付的前提下，完成了核心数据模型的平滑升级。
\n1. 建设 AI CR 与 Pre-PR 机制
\n随着 AI 编码效率飞跃式提升，我们很快遇到了“木桶效应”：Code Review 成了全链路中最拥堵的瓶颈：AI 极大地压缩了编码时间，压力系统性地向下游 CR 环节集中。如果 CR 效率不提升，AI Coding 的提效红利会被 CR 瓶颈吞掉。
\n我们团队达成的共识：
\n我们的实践经验：
\n1、引入 Pre-PR（预审）机制：
\n2、高阶模型审查低阶模型：使用高配模型作为 Judge Model，审查低阶模型产出的编码。
\n3、不同厂商模型对抗互相审核：使用不同厂商的模型互相审查对方的编码产出，通过差异化的模型能力形成互补，实测下来 CR 覆盖面更全。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/267e78761c5a7625b56270667241a33e1589951.png\")
2. 调研取经，建立AI 辅助测试用例生成规范
\n我们团队 100% 的需求由研发兼任测试（RD as QA）。在探索 AI 辅助自测时，团队自然演化出两条路线：路线 A 让 AI 全自动生成用例，人只做最后把关；路线 B 由人界定测试范围和风险级别，AI 负责代码扫描和用例步骤填充。
\n实践下来，路线 A 很快暴露出严重的工程问题 —— AI 缺乏全局业务认知，极度依赖 PRD 质量，容易漏掉隐性关联的高危场景，同时发散出大量无价值的边缘用例，反而增加 Review 负担。与专业 QA 团队交流后，我们确认了路线 B（人工主导，AI 辅助）的方向，并沉淀为一套 Human-in-the-loop 的测试 SOP：
\n| 步骤 | 目标 | 人做什么 | AI做什么 | AI提效点 |\n|
\n", "image": "https://p0.meituan.net/meituantechblog/1c5fff78273feaf4892b46ad3fb757956195300.png", "date_modified": "2026-05-25T03:07:51.000Z", "authors": [ { "name": "gaoshimeng@meituan.com" } ], "tags": [] }, { "title": "LARYBench 发布：定义具身动作表征 ImageNet，首次度量从人类视频学习的泛化表征", "url": "https://tech.meituan.com/2026/04/27/LongCat-LARYBench.html", "id": "https://tech.meituan.com/2026/04/27/LongCat-LARYBench.html", "summary": "LARYBench （Latent Action Representation Yielding Benchmark），一个指引从大规模的视觉数据学习到通用的隐式动作表征的系统化评测基准。实验结果表明：在动作泛化和控制精度上，通用视觉模型的表现均显著优于专门为具身智能设计的动作专家模型，具身动作表征可以从大规模人类视频数据中涌现。", "content_html": "如果你看过今年春晚武术节目《武BOT》，一定会对那群与人类武者同台对打的机器人印象深刻。但在流畅的武术动作背后，是一个工程师团队连续数周针对特定舞台、特定灯光反复调试后才可能达到的动作丝滑。
\n为什么机器人在固定场景下表现良好，但换一个环境、任务，泛化能力就会明显下降？
\n究其根源，是具身行业缺少带动作标注的训练数据进行泛化学习，而互联网上大规模人类数据是极具潜力的数据来源。为了指引具身智能走向GPT时刻，像大模型一样走通大规模数据学习范式，通过人类视频数据学习通用的、跨本体的隐式动作表征是关键。
\n为此，我们提出了 LARYBench （Latent Action Representation Yielding Benchmark） ，一个指引从大规模的视觉数据学习到通用的隐式动作表征的系统化评测基准。实验结果表明：在动作泛化和控制精度上，通用视觉模型的表现均显著优于专门为具身智能设计的动作专家模型，具身动作表征可以从大规模人类视频数据中涌现。
\n当前主流的 Vision-Language-Action（VLA）模型，其泛化能力受限于一个核心矛盾：互联网上存在海量的人类视频，视觉信号极其丰富，但如何将这些视觉信息转化为机器人可用的动作表征，始终缺少高效的路径。具体表现为三个层面：
\n自 2024 年 LAPA 等早期工作提出以来，基于隐式动作表征的研究已陆续展开。然而，现有评测大多只看端到端任务成功率，始终缺少一个能独立衡量中间表征质量的标准基准——动作表征领域，还没有自己的 ImageNet。具体表现为：表征与下游策略难以解耦、跨本体泛化能力无法检验、训练策略的系统性分析缺失。
\n为填补这一空白，我们提出了 LARYBench ，一个从本体动作和语义动作两个粒度出发，系统评估隐式动作表征质量的基准。如图1所示，评测数据集涵盖超过一百万段精心标注的视频（总时长超过1000小时），涉及151种不同类型的动作，同时包含62万对图像和59.5万条运动轨迹，覆盖了多样化的机器人形态与操作环境。
\n![\"LARYBench概览\"](\"https://p0.meituan.net/meituantechblog/85216b5f2075169ad43900e713b569401090890.png\")
评测的核心逻辑如图2所示：输入一段视频或图像序列，通过待测的隐式动作模型（Latent Action Model, LAM）提取出动作表征 z ，随后通过浅层探测头（probing）来验证 z 的质量。
\n![\"LARYBench整体流程\"](\"https://p0.meituan.net/meituantechblog/bb7840787b34934fa8baee4bccfae2b3526572.png\")
动作的定义由细到粗分为三个层级：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/970f03007bcba026f81b1a620bac09d2373862.png\")
针对不同粒度的动作，评测采用不同的验证方式：
\n针对多种粒度的动作，我们收集了主流常用的第一视角人类数据以多视角、跨本体的机器人数据，并通过自动化数据处理流程构建为动作表征数据集。处理流程包括，动作片段切片、视频描述、动作提取和归一化，最后通过人工抽检做质检校验，确保训练集准确率在85%以上，测试集准确率在95%以上。数据集涵盖151个明确定义的动作，以及对应的121.5万个标注样本。数据集覆盖的人类活动范围广泛，从常见的\"pick\"和\"place\"动作，到长尾分布的\"shovel\"(snow)和\"float\"(balloon)动作均有涉及。
\n![\"LARYBench](\"https://p0.meituan.net/meituantechblog/74d57b2b0cc673742e1f731284c2a231439051.png\")
为确保形态多样性，数据集涵盖11种不同的机器人形态，从广泛使用的Franka单臂操作器，到AgiBot G1、Agilex Cobot和Realman系列等复杂的双臂及半人形平台，同时包含大量人类第一视角交互数据。
\n为保证环境多样性，数据集记录了数千种独特的物体操作场景，涵盖模拟桌面、真实住宅厨房、商业场所和工业场景等非结构化环境。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/4a77c94484320a12907d2f9dd5c1d026147211.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/2c3f0969520e1becb10c2e8da1f0be80958930.png\")
数据分布信息如下：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/60600c29b72a31628f069cf285b7f3b8660839.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/5811aeef51ac3dee78d392ef3ff8e069386323.png\")
评测按任务类型分为两类。本体动作任务以起始帧与结束帧构成的图像对作为输入，通过浅层 Action Expert 模块将动作表征映射为末端执行器位姿参数，以均方误差（MSE）衡量回归精度。语义动作任务同样输入图像对，通过浅层分类头进行多类别分类，以分类准确率作为评估指标。
\n待评测模型覆盖四类动作表征范式，包括专为具身智能设计的隐式动作模型、语义级与像素级通用视觉编码器，以及在通用编码器基础上训练的隐式动作模型，以形成从专项到通用的完整能力参照。
\n论文实验部分围绕三个核心问题展开：
\n以下从本体动作回归、语义动作分类、可视化分析和消融实验四个维度展开。
\n本体动作回归任务评估的是模型将视觉信号还原为末端执行器绝对位姿的能力。评测覆盖四个数据集：CALVIN（第三人称仿真单臂）、VLABench（第三人称仿真单臂）、RoboCOIN（第一人称真机双臂）和 AgiBotWorld-Beta（第一人称真机双臂）。所有模型均以均方误差（MSE）作为评估指标，数值越低表示回归精度越高。
\n综合来看，DINOv3 在四个数据集上的平均 MSE 低至 0.19，而具身专项模型 LAPA 的平均 MSE 高达 0.97。语义级表征（V-JEPA-2、DINOv3）的回归误差普遍略低于像素级表征（Wan2.2 VAE、FLUX.2-dev VAE），说明本体动作信息同样可以在语义级特征空间中得到有效保留。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/9df39e3af9ed8eb9435cb6e5dc4e9317175580.png\")
语义动作分类评估模型对高层动作语义的识别能力，按数据来源分为原子动作、复合人类动作和复合机器人动作三类任务。综合来看，语义级通用编码器在三类任务上持续领先，具身专项模型表现普遍偏低，通用 LAM 居中。视觉自监督学习在动作语义捕捉上优于图文对比学习，前者能够兼顾视觉中的动作语义与控制细节。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/006490c8da0c0aa1d262ab2e1caea81f189500.png\")
为了进一步探讨以上实验结论所表现出的原因，我们进行了以下定性的可视化分析实验。
\n从Composite Human数据集上的分类性能随样本频率变化的分布来看，各方法在高低频动作上的趋势基本一致。在长尾部分（样本量较少的动作类别），强模型与弱模型之间的性能差距进一步拉大。这表明表征能力更强的模型在低频场景下具有更好的泛化表现。
\n![\"复合人类数据集中动作分类性能在长尾分布上的表现\"](\"https://p1.meituan.net/meituantechblog/36fbaf28ffe58d0ab5e2a4a721c730f2951060.png\")
对“倾倒”动作序列的可视化显示，语义级表征模型 V-JEPA-2 和 DINOv3 的注意力能够较为精准地聚焦于手部与物体的交互区域。相比之下，像素级表征模型 FLUX.2-dev VAE 和 Wan2.2 VAE 的注意力分布更为分散，部分落在手臂阴影等与动作语义关联较弱的区域。具身专项模型 LAPA 的注意力则几乎不具备明确的聚焦区域，呈现大范围的弥散分布。
\n这一现象的原因可能在于，像素级编码器倾向于捕捉逐像素的视觉变化（如光影、遮挡），而这些底层信号容易与动作本身的位移信息混杂。当模型未能有效区分动作相关与无关的视觉变化时，提取出的表征质量会受到影响。
\n![\"不同模型在9帧“倾倒”动作序列上时序池化器的交叉注意力热力图\"](\"https://p0.meituan.net/meituantechblog/eb80aef2bef76b346ee395bb502168861613715.png\")
为探究构建有效隐式动作表征的关键参数配置，实验基于 LAPA-DINOv3 框架对码本大小、序列长度、隐空间维度及学习率等因素进行了消融分析，性能演进路径如下图所示。
\n![\"隐式动作模型性能演进路径\"](\"https://p0.meituan.net/meituantechblog/804ec9e66d3d2c3a30d4a6c5273376bf1050280.png\")
综合来看，在数据量一定的条件下，调整码本大小、序列长度、隐空间维度和学习率等超参可以有效提升动作表征效果。其中，序列长度与隐空间维度在合理范围内适当增大有利于性能提升，而码本大小存在最优区间，并非越大越好。
\nLARYBench 作为首个在动作泛化和机器人控制上对隐式动作表征进行量化评估的系统性基准，其核心价值体现在：
\n我们已将 LARYBench 评测数据集及配套代码开源，并会持续维护和更新：
\n开源链接：
\n欢迎社区开发者与研究者使用、反馈及贡献，共同完善动作表征评估体系。
\n", "image": "https://p0.meituan.net/meituantechblog/85216b5f2075169ad43900e713b569401090890.png", "date_modified": "2026-05-26T03:03:55.000Z", "authors": [ { "name": "liqi18@meituan.com" } ], "tags": [] }, { "title": "突破零样本 TTS 音色克隆上限：LongCat-AudioDiT 的声音克隆艺术", "url": "https://tech.meituan.com/2026/04/20/LongCat-AudioDiT.html", "id": "https://tech.meituan.com/2026/04/20/LongCat-AudioDiT.html", "summary": "能不能让 AI 直接学会声音本身的规律，跳过中间环节？为破解这一技术瓶颈，美团 LongCat 团队正式发布 LongCat-AudioDiT。在该模型中，彻底抛弃梅尔谱等中间表示，直接在波形潜空间进行基于扩散模型的文本转语音（Text-to-Speech, TTS），从根源阻断数据转换的级联误差。", "content_html": "音频生成技术正在经历一场全新的范式迁移——从传统级联架构，逐步向端到端生成范式演进。长期以来，主流的做法是\"曲线救国\"：合成系统先将音频压缩成梅尔频谱图等中间表征，再依赖神经声码器\"翻译\"回波形。每一次转换都带来信息损失与误差累积，最终丢失了最需要保留的细腻音色与个性化细节。
\n能不能让 AI 直接学会声音本身的规律，跳过中间环节？
\n为破解这一技术瓶颈，美团 LongCat 团队正式发布 LongCat-AudioDiT。在该模型中，我们彻底抛弃梅尔谱等中间表示，直接在波形潜空间进行基于扩散模型的文本转语音（Text-to-Speech, TTS），从根源阻断数据转换的级联误差。
\n另外，我们做了两个关键改进：首先，我们识别并纠正了一个长期存在的\"训练-推理不匹配\"问题；其次，我们用自适应投影引导（APG）取代了传统的无分类器引导（CFG），从而大幅提升了最终的语音生成质量。
\n结果表明，LongCat-AudioDiT 在 Seed 基准测试中取得当前最优（SOTA）的零样本语音克隆性能，同时保持了具有竞争力的可懂度。 其中 LongCat-AudioDiT-3.5B 模型，在 Seed-ZH 测试集的说话人相似度（SIM）指标提升至 0.818，Seed-Hard 测试集达到 0.797，超过了 Seed-TTS、CosyVoice3.5、MiniMax-Speech 等知名模型，验证了波形空间直接生成范式的有效性。
\n今天，我们将 LongCat-AudioDiT（1B/3.5B）完整开源：
\n接下来，我们将为您拆解 LongCat-AudioDiT 的核心技术创新。
\n业界主流 TTS 系统长期受困于\"多阶段\"的复杂流程：先预测中间声学特征（如梅尔频谱），再依赖一个独立的神经声码器将特征\"翻译\"成最终波形。这种\"预测+翻译\"的范式，本质上是在两个不同空间里\"传话\"，必然会累积误差，导致最终合成的声音丢失了高保真、个性化的细节——而这恰恰是零样本语音克隆最需要保留的部分。
\n为此，我们构建了全新的 LongCat-AudioDiT 架构。其核心逻辑非常简单：
\n\n\n只用一个波形变分自编码器（Wav-VAE）和一个扩散 Transformer（DiT），在波形隐空间里完成声音的压缩、建模与重建。
\n
![\"\"](\"https://p1.meituan.net/meituantechblog/c10121344a25f75ccd159e2195a0408d56532.webp\")
Wav-VAE 作为一个全卷积音频自编码器，它将原始波形压缩为紧凑的连续隐向量。其设计蕴含了多项关键创新：
\n有了高质量的隐空间，我们的 DiT 模型便在这个空间里学习条件流匹配（CFM）。
\n文本编码方面，我们选择了支持 107 种语言的 UMT5 作为文本编码器。一个关键的发现是：仅使用最后一层隐藏状态模型无法生成可懂的语音。我们推测这是因为高层语义抽象丢失了关键的词法、音素线索。因此，我们创新性地将原始词嵌入（第一层）与最后一层隐藏状态相加，经过 LayerNorm 平衡 scale 后送入后续模块。这种\"高低结合\"的策略大幅提升了生成语音的可懂度。此外，我们还引入了轻量的 ConvNeXt V2 序列模块对文本表征进行细化处理，加速了文本-语音对齐的收敛。
\nDiT 的骨干网络基于 Transformer，并集成了多项结构优化：
\n如果说波形潜在空间架构解决了声学建模的\"空间选择\"问题，那么我们对推理过程的两项关键改进，则从根本上优化了生成过程的\"路径精度\"与\"质量纯度\"。
\n我们首次发现并解决了流匹配 TTS 中长期存在的训练-推理不匹配问题。在标准 CFM 训练框架中，模型仅在掩码区域计算损失，而音频提示区域（prompt）并不参与优化；然而在推理阶段，这些同样提供音色条件的提示区域却会不受约束地通过扩散 ODE 自由演化，导致其分布轨迹偏离训练时的约束条件，最终造成生成语音的说话人音色漂移与稳定性下降。
\n为此，我们提出双重约束机制：
\n传统的扩散模型普遍使用无分类器引导（CFG），通过放大条件预测与无条件预测的差异来提升生成质量。但这种方法有一个副作用：引导强度越大，越容易导致频谱\"过饱和\"，从而使得音质劣化、语音听起来不够自然。
\n我们提出的自适应投影引导（APG）则换了一个思路：引导信号中真正有益的部分，和引发劣化的部分，在几何上是正交的。APG 将引导信号分解为平行与正交两个分量，保留正交分量（有益部分），同时抑制平行分量（劣化部分），从而在提升自然度的同时避免音质损失。
\n简单来说，CFG 是\"无差别放大\"，APG 是\"精准筛选\"。两项推理优化协同作用，在保持高说话人相似度的同时，显著提升了生成语音的自然度与声学质量。
\n在 Wav-VAE 的实验中，我们观察到了一个非常有意思的现象：VAE 重建质量越好 ≠ 语音生成效果越好
\n单纯追求高重建分数，会导致潜空间维度膨胀。这使得下游的扩散模型难以学习，导致综合表现下降。
\n为了深入探究这个问题，我们系统性地对比了不同潜空间维度与帧率配置下的建模表现，最终确定了最优配置：64 维潜在维度 + 11.7Hz 帧率。这一配置既为生成模型留出足够的学习空间，又保留了足够的声学细节，实现了重建保真度与生成质量的最佳平衡。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/d349a376d879f7498a5b288658a9bd5992120.webp\")
我们在 Seed 基准上测试了 LongCat-AudioDiT 的表现，并与业界知名模型，比如 SeedTTS、CosyVoice3.5、MiniMax-Speech 等进行对比。
\n结果表明，LongCat-AudioDiT 在说话人相似度（SIM）方面取得了 SOTA 的表现，同时具有极具竞争力的可懂度。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/d430b245bdb2c60bbee460c0a5fea3ee162952.webp\")
模型在准确率指标上保持了第一梯队的水平，没有为了追求相似度而牺牲可懂度。
\n值得一提的是，LongCat-AudioDiT 并没有使用高质量人工标注数据和多阶段的训练，仅仅通过 ASR 转写的预训练数据和单阶段预训练就取得了比多阶段训练的模型，如 Seed-TTS、CosyVoice3.5、MiniMax-Speech 等知名模型更好的表现。
\n总结来说，LongCat-AudioDiT 模型凭借其优秀的说话人相似度（SIM）和稳定的准确率（WER/CER），在零样本语音克隆任务中展现出强大的竞争力。
\nLongCat-AudioDiT 以极简的架构、纯粹的波形潜空间建模，证明了绕开中间表征的扩散 TTS 路线不仅能走通，更能达到业界最佳水平。我们相信，这套\"波形隐空间直通\"的设计范式将为高保真语音合成与多模态音频生成提供新的思路。
\n今天，我们将 LongCat-AudioDiT 模型（1B / 3.5B）全部开源，期待与社区同仁共同推动语音生成技术的边界。
\n🚀 开源平台链接
\n我们也期待，这套技术能帮助更多开发者和研究者，构建出更自然、更富表现力的语音交互体验。
\n", "image": "https://p1.meituan.net/meituantechblog/c10121344a25f75ccd159e2195a0408d56532.webp", "date_modified": "2026-05-25T06:17:30.000Z", "authors": [ { "name": "liqi18@meituan.com" } ], "tags": [] }, { "title": "LongCat-Flash-Prover：AI 攻克数学定理证明，不仅要“算得对”，更要“证得严”", "url": "https://tech.meituan.com/2026/04/07/LongCat-Flash-Prover.html", "id": "https://tech.meituan.com/2026/04/07/LongCat-Flash-Prover.html", "summary": "在常规的数学解题中，模型只需要“答对最终数值”即可，但数学定理证明不同，它要求极度严苛的逻辑链条，任何一句自然语言的模棱两可，都可能导致整个证明的崩塌。那么，如何让 AI 从“猜答案”走向“严谨证明”，成为复杂推理具有挑战的课题。为了解答这个问题，我们开源了专门用于数学形式化与定理证明的模型 —— LongCat-Flash-Prover。", "content_html": "现如今的大语言模型已经能流畅地写文章、写代码，甚至执行复杂的 Agent 工作流，然而，它们在面对严谨的数学定理证明时，却往往显得力不从心。
\n在常规的数学解题中，模型只需要“答对最终数值”即可，但数学定理证明不同，它要求极度严苛的逻辑链条，任何一句自然语言的模棱两可，都可能导致整个证明的崩塌。那么，如何让 AI 从“猜答案”走向“严谨证明”，成为复杂推理具有挑战的课题。
\n为了解答这个问题，我们开源了专门用于数学形式化与定理证明的模型 —— LongCat-Flash-Prover。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/04169c157ed23fabc30717b0907c6656994570.png\")
LongCat-Flash-Prover 在解决定理证明和形式化任务时，将形式化推理拆解为自动形式化（Auto-Formalization）、草稿生成（Sketching）和证明生成（Proving）三大原子能力。在结合工具集成推理（Tool-Integrated Reasoning，TIR）策略下，仅用 72 次推理预算，MiniF2F-Test 通过率就达到 97.1%，在已知开源 Prover 模型中刷新 SOTA；在超难竞赛级任务上，MathOlympiad-Bench 达 46.7%（180 次预算），PutnamBench 达 41.5%（118 次预算），同样超越现有开源模型。
\n目前 LongCat-Flash-Prover 已全面开源，欢迎使用：
\n让我们感到惊喜的是，模型在开源后几日内，不仅受到了 AI 和大模型研究者们的关注，更引起了数学界的关注。发布当日，我们便收到了国内顶尖高校的合作邀请，共同探讨基于该模型开发形式化证明 Agent 的可能性。我们期望借此将现有的数学教材和前沿论文\"翻译\"成形式化语言，进一步充实形式化数学的知识底座，为整个数学研究领域的范式创新提供助力。这让我们深刻意识到：AI 在定理证明上的突破，不再仅仅是算法跑分，而是真正开始成为基础科学研究的“基础设施”。
\n自然语言天生带有模糊性，很难进行步骤级的严谨性验证，为了解决这个问题，数学家和计算机科学家们引入了形式化语言（如 Lean4）。
\n你可以把 Lean4 理解为一种“数学编程语言”。就像 Python 代码可以通过编译器执行一样，用 Lean4 写出的数学证明，可以通过编译原理进行逐行校验。只要模型能写出语法正确、逻辑严谨且能通过 Lean4 编译器验证的代码，就意味着这个数学定理被 100% 严谨地证明了。
\n教 AI 证明定理，就像教一个数学系新生，不能指望它一眼看穿答案，而是要教它拆解步骤。我们将 AI 的证明过程拆解为三个基础的形式化推理原子能力：
\n1. 自动形式化（Auto-Formalization）——“翻译题目”：先将自然语言描述的数学问题，精准翻译成 Lean4 计算机能看懂的形式化描述。
\n2. 草稿生成（Sketching）——“写解题大纲”：面对复杂定理，不急于一步写完。模型会先写一个草稿，把大问题拆解成几个需要证明的小引理（Lemma），理清逻辑主线。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/d817c5fef9ecf26bc57fe31af67984d3579668.png\")
3. 证明生成（Proving）——“补全细节”：沿着草稿的思路，一步步补全剩余的证明过程，完成逻辑推演。
\n为了让模型熟练掌握这三项技能，我们设计了一套结合“工具集成推理”（TIR）的“混合专家迭代”框架。简单来说，就是组合不同具备这些原子能力的专家模型，以单轮和多轮形式进行不断试错、自我纠正，从简单的完整证明，逐步过渡到复杂的“引理式草稿证明”。
\n在这个框架中，我们旨在结合不同的专家不断合成基于 Auto-Formalization、Sketching 和 Proving 这三个原子能力以及相互组合下的推理轨迹，并挑选高质量的数据来进一步提升相应专家模型的性能。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/309af423a78d4131a6728206d67889301092673.png\")
专家迭代主要包含两个阶段：
\nCold-Start 阶段：我们首先利用团队在早期探索的基于 TIR 和 DPO 训练的 Auto-Formalizer 专有模型 ATF-32B 用于合成 Formal Statement。基于这些 Statement，我们利用 LongCat-Flash-Thinking-2601 生成高质量的带有多个 Lean4 相关验证工具反馈的轨迹。基于这些合成数据，我们通过执行去污、去重和基于难度和多样性的采样，构建了一个高质量的冷启动数据集。由于不同的专家模型来自不同的模型族，我们应用领域混合 SFT 来整合这些功能，并得到最终的冷启动模型。
\nIteration 阶段：在迭代阶段，我们选择冷启动阶段得到的模型作为新的专家模型。每个形式推理任务的轨迹都是基于这个新专家模型合成的。此外，我们还整合了大量通用数据，以确保模型具备非形式推理能力。每一轮迭代中，我们会进行 SFT 和 RL 训练，多次迭代之后则可以得到 LongCat-Flash-Prover 模型。
\n在数据合成过程中，如何组织这些专家进行协同是一个挑战。我们设计了如下图所示的工作流。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/5e8a10013d83cf38f4add45de256b5fe833777.png\")
每个专家模型都能同时生成单轮轨迹（不调用工具）和多轮轨迹（TIR 模式），从而确保合成数据的多样性。
\n为了使模型能够根据每个问题的难度动态选择合适的工具和证明策略，我们采用了一种课程学习方法：1）从单轮合成开始，然后是多轮调用工具合成；2）从生成完整证明逐步过渡到引理式草稿证明。
\n基本合成过程如下：
\n首先给定一个 Informal Statement（即一个自然语言问题），先用 Auto-Formalization 专家在单轮无工具条件下生成 N 个 Formal Statement。我们使用 Lean4 Server 和语义一致性打分模型来对每个结果进行打分。当且仅当生成的 Formal Statement 没有语法错误且语义与 Informal Statement 保持一致的则被认定为正确；
\n如果这 N 个 Formal Statement 包含正确的结果，则直接获取这些正确的 Statement 即可；如果全部错误，则激活 TIR 模式，通过结合 Lean4 Server 和语义一致性打分模型两个工具来不断修改，直到能生成正确的为止；
\n基于生成好的 Formal Statement，我们接下来使用 Prover 模型尝试生成证明。我们先使用 Whole-Proof 模式来一次性给出完整的证明过程，同样我们生成 N 个结果，并使用 Lean4 Server 和 Theorem 一致性来判断模型生成的证明是否通过。其中，Theorem 一致性是为了避免模型伪造或修改原始证明目标从而导致 Hacking 问题；
\n如果生成的 N 个 Whole-Proof 没有正确的，那么我们激活 Whole-Proof 的 TIR 模式，借助 Lean4 Server 和 Theorem 一致性打分工具的反馈信息帮助模型修改 Proof；
\n如果 Whole-Proof 模式下不论使用单轮还是 TIR 都无法被证明（通常是一些复杂的问题，或者需要超过 1000 行证明过程的问题），我们则开启 Sketch-Proof 的策略；
\nSketching 中，给定一个 Formal Statement，Sketcher 专家模型先生成 N 个 Sketch，每个 Sketch 包含多个待证明的 Lemma，以及一个 Main Body，我们同样采用 TIR 模式来帮助模型生成语法和 Theorem 一致的 Sketch；
\n对于每个 Sketch，我们再次使用 Prover 专家模型对每个 Lemma 进行 Whole-Proof 模式的证明，整个证明过程均使用 TIR 模式。
\n基于这些合成轨迹，我们进行了一些数据处理、多样性采样和难度控制，从而可以获得 SFT 模型。
\n我们的专家迭代框架和 RL 训练框架中，共享相同的一套智能体工具：
\n1. Lean4 Server：我们部署了 Lean4 Server 并作为验证生成的 Formal Statement、Sketch 和 Proof 的语法是否准确。相比于之前工作直接将 Lean4 Server 的 JSON 格式作为反馈信息，我们对其进行了处理：通过将完整的 Proof 中插入锚点，即直接告诉模型错误代码片段，而非简单的行列坐标，这样可以避免模型错误判断错误代码的位置，提高纠错的准确性。
\n2. 语义一致性：只靠 Lean4 Server 可能会存在 Hack 问题，例如模型为了生成语法正确的代码而修改原始问题。为此，我们通过 LLM-as-a-Judger 的手段，验证模型生成的 Formal Statement 与原始问题是否语义一致。
\n3. Theorem 一致性：在模型生成 Sketch 或 Proof 时，需要确保模型的 Theorem 证明目标不能被篡改，一些微小的符号变化可能会导致整个证明问题发生改变。我们采用基于规则的方法来约束模型不能修改原始证明目标。
\n4. Legality 验证：我们观察到大约 9 种存在作弊的 Proof 行为，这些证明过程通常尝试修改 Formal Statement、插入提前终止符 #exit、插入不存在的公理或无法证明的假设、通过添加 macro、elab、syntax、notation 尝试绕过编译错误等手段企图达到 Lean4 Server 给出证明通过的反馈。通过引入 Legality 验证，可以极大地避免模型出现 Hack 问题。
![\"\"](\"https://p0.meituan.net/meituantechblog/e9ab12bf6210eba6a8227d4d4e8729e7440685.png\")
Prover 在 RL 阶段训练使用 TIR 模式，我们基于 LongCat-Flash-Thinking 所使用的 DORA 训练框架进行。
\n在训练过程中，我们观察到 MoE 两个影响模型稳定性的因素：训推一致性问题以及 Staleness。对于训推 Diff，我们通过评估新旧策略模型在训练引擎与推理引擎上关于重要性采样比（Important Sampling Ratio，IS Ratio）的估计来衡量训推一致性。相比 GRPO 而言，我们除了将 Sequence-Mean-Token-Mean 调整为 Token-Mean 以外，我们主要引入分层的 Masking 策略来直接消除不稳定 Token 的梯度贡献：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/7d51901cb4e96470728ac3617cef5e7387170.png\")
序列层面 Masking：我们首先通过计算所有 Token 的 IS Ratio 的几何平均值来估计序列级的训练-推理 Diff。对于整个序列，如果 Diff 超过一定范围，则认为其对训练稳定性有显著影响，并将移除该序列的梯度贡献。该策略旨在仅考虑序列级的训练-推理一致性度量，避免过度忽略有价值的标记。
\nToken 层面 Masking：对于剩余的序列，我们将移除具有显著训推不一致性的 Token，以确保剩余标记不会因训练拉取不一致性而影响稳定性。
\nToken 层面 Staleness 控制：对于经过序列和 Token 层面的 Masking 处理后所保留的 Token，我们再考虑标准的 Clipping 操作，用于控制 Staleness，以确保更新幅度限制在一定范围内，从而保证训练稳定性。
\n在训练过程中，我们观察到了一个非常有意思的现象：AI 为了得到高分，学会了“作弊”。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/6c5fac89aaa4c868840690deb4453a24340560.png\")
如果仅仅依赖 Lean4 编译器作为裁判，模型有时会通过修改原始题目、插入提前终止符（如 #exit）、甚至凭空捏造不存在的公理，来骗过编译器，获得“证明通过”的反馈。
为了纠正这种“耍小聪明”的行为，我们不仅引入了 LLM 作为裁判来检验“语义一致性”，还专门开发了一个轻量级的 Lean4 词法和语法分析器。它能将代码转化为抽象语法树（AST），严格排查大约 9 种作弊手段。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/5e61da599a6e3d17ec2bc5e725fab102519986.png\")
![\"\"](\"https://p1.meituan.net/meituantechblog/d4fef4131b0b34bb58aecabda4d16850383313.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/2b5d287f285955b056640d14e4cdf823357135.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/f35cb5b35c8b5367bb88c79ab0ad0b47323757.png\")
从\"答案看起来对\"到\"每一步都能被验证\"，LongCat-Flash-Prover 不再满足于输出一个数值，而是像一位严谨的数学研究员，从公理出发，用计算机可验证的语言完成证明的闭环。
\n我们相信，当 AI 真正学会\"证明\"而不仅仅是\"猜答案\"时，它便有可能成为数学研究者、教育者与学习者的得力伙伴——不仅能帮助翻译文献、验证思路，更能启发新的证明路径，甚至参与前沿数学问题的探索。
\n目前，LongCat-Flash-Prover 已经全面开源。我们期待与学术界和开源社区一起，让严谨推理的能力走得更远，让每一次数学探索都有迹可循。
\n🚀 欢迎体验与探讨：
\n物理世界的信息由图像、声音、文字交织而成。今天的大模型，本质上仍然是以语言为中心的建模系统，语言作为人类智慧符号化表述，在\"压缩即智能\"的范式下表现出强大的能力。但通往真正的物理世界智能，也许语言并不是世界的边界。视觉、语音与文本等多模态信号，实际上是对现实物理对象的不同侧面投影。
\n这就引出一个根本问题：能否让 AI 像处理语言一样，用同一种方式简洁有效地处理物理世界的多种信息？ 如果能，那么物理世界的AI就有了统一的\"母语\"，Token 不再局限于文本，而是成为描述一切物理信号的原生表示。对这些信号进行统一建模与压缩，可能使模型学到更加本质的表示，并实现更深层的模态内化。
\nLongCat 团队经过研究发现：在统一的建模框架与优化目标下，可以构造一种语义完备的离散表示。我们将图像、语音与文本统一映射为同源的离散 Token，使模型从学习连续空间的映射，转向学习离散 ID 之间的关系结构，并通过纯粹的下一个 Token 预测（Next Token Prediction, NTP）范式，以一种统一的、优雅的方式建模各种物理信号。
\nLongCat-Next 是我们在通往物理世界 AI 道路上的一次探索。今天，我们把研究思路的核心——LongCat-Next 模型和它的离散分词器全部开源，希望更多开发者能基于它，构建真正能感知、理解并作用于真实世界的AI。
\n接下来，我们将逐一拆解三项核心技术，看看我们是如何让 AI 真正拥有物理世界的“母语”。
\n业界主流的多模态大模型长期受制于“语言基座+外挂视觉/语音模块”的拼凑式架构，非语言模态往往只作为辅助组件存在。这种设计带来很多结构性问题，比如图像理解与生成在结构与优化上长期割裂：前者依赖对齐机制，后者依赖扩散等独立模型，多模态信息始终停留在\"被投影\"，而非“被内化”。
\n为此，我们构建了 DiNA（Discrete Native Autoregressive）离散原生自回归架构。其核心非常简单：
\n\n\n将所有模态统一为离散 Token，并用同一个自回归模型进行建模。
\n
它将物理世界广泛存在的多模态信号收敛为同源的离散特征，实现了视觉、语音、文本多模态的底层建模统一。作为整个大语言模型体系的自然扩展，DiNA 彻底打破了模态间的隔阂。它通过极简的下一 Token 预测（NTP）范式，将图像、声音和文字统一转化为同源的离散 Token。在这套原生的统一架构下，视觉的“看”与“画”、听觉的“听”与“说”，不再是拼接的异构模块，而是同一套预测逻辑的自然涌现。
\n简单而言：我们把文字、图像、语音都变成同一种东西——离散 Token。无论读文字、看图片还是听声音，对AI来说都是同一件事：预测下一个 Token 是什么。
\n这个设计带来 3 个根本性改变：
\n![\"图1：LongCat-Next](\"https://p0.meituan.net/meituantechblog/76d550e2fd26e741377fa4bcd866a8ec377657.jpg\")
\n\n图像 → 文本：理解
\n
\n\n文本 → 图像：生成
\n
给定图像 Token 预测文字 Token 是“理解”，给定文字 Token 预测图像 Token 是“生成”——数学形式完全一致，从此不再割裂。实验证明，这种对称设计在优化上消弭了冲突：统一模型的理解损失仅比纯理解模型高 0.006，而生成损失比纯生成模型低 0.02。理解没有损害生成，反而表现出协同潜力。
\n![\"图2：DiNA](\"https://p1.meituan.net/meituantechblog/bb665f69a809ef29b5d80c500a1352c2283626.png\")
模态内化：在离散原生训练范式下，不同模态被统一编码为 Token，并以相同方式建模。我们观察到：
\n这表明模型并非在“对齐模态”，而是在内部形成统一的多模态表征结构。
\n![\"图3：(a)](\"https://p0.meituan.net/meituantechblog/713b92ec23558c69b1aa057aa44053612689010.png\")
如果说 DiNA 解决的是“如何统一建模”，那么 dNaViT 解决的是：
\n\n\n如何让图像本身能够被离散化为可建模的 Token。
\n
LongCat 团队首创的 dNaViT 技术相当于语言模型中的 tokenizer（分词器）——就像把句子拆成单词，它把一张图拆解成一系列有意义的“视觉词汇”。
\n原生任意分辨率支持（Native Resolution for Understanding and Generation）：不做缩放、不裁剪、不填充，每一处细节都完整保留。通过我们精心设计的训练策略，dNaViT 实现了任意分辨率的图像编码与解码——在文档解析（OCR）、复杂图表推理等对细节敏感的任务中具备优势，如在 OmniDocBench、OCRBench 等密集文本场景的测试中均表现优异。
\n8层残差向量量化（Residual Vector Quantization, RVQ）：细节多了怎么办？分层打包。类比于第一层打包轮廓，第二层打包颜色，第三层打包纹理……8层级联递归拟合\"残差中的残差\"，可以实现高达 28 倍极致像素空间压缩。解码时，DepthTransformer 将多级 Token 合并重建，让压缩与还原高效协同。
\n解耦的双轨生成解码器（Dual-Path Detokenization）：离散 token 还原图像时，先由\"结构像素解码器\"保住布局，再由\"扩散像素细化器\"注入纹理细节。解耦设计降低生成方差，确保文本渲染无损清晰。
\n更妙的是，这套\"视觉词汇\"实现了 image → token → image 的完整回环——像语言 tokenizer 一样，既用于\"看懂\"图像，也用于\"画出\"图像。理解时学到的对应关系，生成时正好反过来用——图像描述和图像生成在同一套 token 序列中闭环流转。
\n更关键的是，在 LongCat-Next 中：
\n\n\n视觉 Token 完成的是图像到离散 ID 的映射，真正的特征是原生学习的。
\n
真正的视觉表征，是在语言模型内部通过 Embedding 学习得到的。这意味着模型不是\"接入视觉能力\"，而是在内部学习并形成自己的视觉语言。
\n这种从“借用模态”到“内生模态”的转变，是原生多模态建模的核心。
\n![\"图4：离散原生分辨率视觉](\"https://p1.meituan.net/meituantechblog/9e034a29b692db08508a68169f488fc761601.jpg\")
![\"图5：LongCat-Next](\"https://p0.meituan.net/meituantechblog/eaf52afb76493922e4a1b6303c1716b54238224.png\")
离散建模通常被认为受限于两方面：表征容量与离散化损失。然而，我们进一步分析发现，真正决定上限的关键在于：
\n\n\n离散 Token 本身是否具备语义完备性（Semantic Completeness）。
\n
也就是说，问题不在于\"是否离散\"，而在于离散后的表示，是否能够同时承载高层语义与细粒度信息（如颜色、纹理与空间结构），从而支撑统一的理解与生成。
\n基于这一视角，我们提出：实现语义完备离散表示的关键，在于构建合适的表征基础。其中，一类重要的候选范式是 SAE（Semantic-and-Aligned Encoder）。不同于以对比学习为主的模型（如 SigLIP），SAE 通过大规模视觉-语言监督（涵盖图像描述、视觉问答乃至视觉推理等任务），学习高信息密度、多属性的表征。这类表征不仅具备丰富的语义结构，同时我们发现在网络的残差传递机制下，底层视觉细节能够持续向高层传播，从而在抽象语义中保留细粒度信息，为离散 Token 的语义完备性提供基础。
\n在此之上，离散化过程本身仍需尽可能减少信息损失。为此，我们采用多级残差向量量化（Residual Vector Quantization, RVQ）机制，对表征进行逐级离散建模：通过层级化拟合\"残差中的残差\"，在有限离散空间内逼近高维连续表示，从而在压缩率与信息保真之间取得平衡。
\n最终得到的离散视觉 Token，不仅能够支撑细粒度理解任务（例如在密集文本识别中优于连续表征模型），同时也具备高保真的图像重建能力。这表明：
\n\n\n离散表示并非信息的退化形式，而可以成为统一理解与生成的完备表达载体。
\n
![\"图6：dNaViT](\"https://p0.meituan.net/meituantechblog/fcd9c7fef5845687d0914171660089b9234739.png\")
LongCat-Next 在视觉理解、图像生成、音频、智能体等多个维度上，以一套离散原生框架展现出与多模专用模型相当甚至领先的性能。
\n更重要的是，这些成绩验证了三个关键发现：
\n![\"图7：LongCat-Next](\"https://p0.meituan.net/meituantechblog/1b2c3a1b203dce07b6b22b50871c6709228932.png\")
行业长期认为，离散模型在细粒度文本识别上必然不如连续模型，这也是一直阻碍业界使用离散建模作为选项的原因。值得一提的是，经过我们 dNaViT 的设计以及 DiNA 的建模框架，LongCat-Next 表现出了非凡的细粒度感知能力和高质量的视觉推理能力。
\nLongCat-Next 在 OmniDocBench（学术论文、财报、行政表格）上的表现（0.152 / 0.226）挑战了这一刻板印象——不仅超越 Qwen3-Omni，还超过了专用视觉模型 Qwen3-VL。离散化不是细粒度感知的天花板，关键在于如何构建语义完备的离散视觉表征。
\n传统观点认为，一个模型很难同时做好理解和生成。但我们发现：消融实验对比中，LongCat-Next 统一模型的理解损失仅比纯理解模型高 0.006，而生成损失比纯生成模型低 0.02。在图像生成上，LongCat-Next 在 LongText-Bench（英文 93.15）；在图像理解上，MathVista（83.1）达到领先水平，成为一个具备工业级潜力的理解生成统一方案。理解没有损害生成，反而表现出协同潜力。
\n在纯文本任务上，LongCat-Next 的 MMLU-Pro（77.02）和 C-Eval（86.80）表现领先，证明原生多模态训练未削弱语言核心能力。在工具调用上，τ²-Bench 零售场景（73.68）大幅领先 Qwen3-Next-80B-A3B-Instruct（57.3）；在代码能力上，SWE-Bench（43.0）显著超越同类模型。
\n在音频领域，这一框架同样展现出良好的通用性。TTS 任务上，SeedTTS 的中文和英文 WER 分别低至 1.90 和 1.89；音频理解上，MMAU（76.40）、TUT2017（43.09）均达到先进水平。更重要的是，模型支持低延迟的并行文本语音生成与可定制的语音克隆，让语音交互更自然、更个性化。
\n当模型学会用同一种方式理解图像、声音和文字，它在理解世界时变得更聪明了——无论是看懂图表、听懂语音，甚至是调用工具、编写代码。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/7efaac0266f0f5745981c3ce7ca8fa94319111.png\")
\n\nAnalyze this image. Context: Gen = Generation; Und = Understanding. 'Scaled' represents a fair 1:1 token comparison. Is there any evidence that Understanding helps Generation?
\n
![\"\"](\"https://p0.meituan.net/meituantechblog/cb6aeb442f5c8d6152b150a36d400909317940.png\")
Yes, there is evidence that \"Understanding\" (Unified) helps \"Generation\" (Pure-Gen.), particularly in the context of token efficiency and image loss reduction.\nLet's break this down:\n1. Main Graph: Image Loss vs. TokensThe x-axis is Tokens (from 0B to 100B), and the y-axis is Image Loss (lower is better).Three curves are shown:Pure-Gen. (blue): Pure generation model.Unified (orange): Unified model (combines understanding and generation).Unified (unscaled) (light orange): Same as Unified, but scaled for fair token comparison.Key Observations:At low token counts (e.g., 0–20B tokens), all models start with high image loss, but Unified (orange) starts slightly lower than Pure-Gen. (blue), suggesting a small advantage.As tokens increase, Unified (orange) consistently achieves lower image loss than Pure-Gen. (blue), especially after ~40B tokens.The Unified (unscaled) curve (light orange) is very close to the Unified curve, indicating that scaling doesn’t change the relative performance — it’s just a fair comparison.✅ Conclusion: The Unified model (which includes understanding) performs better than Pure-Gen. across most token ranges, meaning understanding helps generation.\n2. Inset Graph: Zoomed-in View (40B–50B Tokens)This shows a close-up of the region where the curves diverge slightly.The difference (Δ = 0.0213) is explicitly marked between Pure-Gen. and Unified at ~48B tokens.The Unified curve is below Pure-Gen., meaning lower image loss — better performance.✅ This quantifies the benefit: Understanding provides a measurable improvement in image quality (lower loss) at higher token counts.\n3. Interpretation: What Does \"Understanding\" Mean Here?The term \"Unified\" likely refers to a model that jointly learns understanding (e.g., semantic or structural comprehension) and generation. In contrast, \"Pure-Gen.\" is a model trained only on generation tasks.\nSo, when the Unified model outperforms Pure-Gen., it suggests that incorporating understanding during training leads to better generative performance — possibly by enabling more informed, context-aware generation.\n✅ Final Answer:Yes, there is clear evidence that Understanding helps Generation.The Unified model (which includes understanding) consistently achieves lower image loss than the Pure-Gen. model across token counts, with a quantified improvement of Δ = 0.0213 in the inset graph. This indicates that integrating understanding into the model improves its generative performance, especially as token count increases.\n![\"\"](\"https://p0.meituan.net/meituantechblog/fd3852e762f22f696722793ccc602c001186645.png\")
请查阅原文
\n作为一个初步的尝试，我们展示了一个有意义的视角：物理世界的信息可以被离散化、统一化、像语言一样被建模，让 AI 第一次能够像处理文字一样原生地理解物理世界的多模态信号。
\n今天，我们把这个探索研究的过程及产物——LongCat-Next 模型和 dNaViT 分词器全部开源。
\n🚀 开源平台链接
\n💻 更多体验前往：
\n我们也期待，有一天 AI 能真正看懂真实世界的每一个角落、听懂顾客的每一句话、理解物理世界的每一条规律。
\n而我们今天开源的 LongCat-Next，以小尺寸验证了原生离散架构的潜力，是这条路上的一块重要的基石。我们也知道，还有非常多重要的方向尚未被充分探索——但这恰恰是未来研究的机遇。我们诚挚欢迎社区同仁的深入讨论与合作，一同推动原生多模态智能走向更远。
\n", "image": "https://p0.meituan.net/meituantechblog/76d550e2fd26e741377fa4bcd866a8ec377657.jpg", "date_modified": "2026-05-25T03:07:51.000Z", "authors": [ { "name": "liqi18@meituan.com" } ], "tags": [] }, { "title": "美团 BI 在指标平台和分析引擎上的探索和实践", "url": "https://tech.meituan.com/2026/03/20/Busniness-Intelligence-practice-in-meituan.html", "id": "https://tech.meituan.com/2026/03/20/Busniness-Intelligence-practice-in-meituan.html", "summary": "美团数据平台构建了以指标平台为核心的新一代 BI 架构，通过自动语义和增强计算两种核心能力的建设，部分解决了传统 BI 平台在个性化数据集驱动下产生的数据口径混乱、查询性能差等问题。", "content_html": "速读
\n在美团，我们构建了以指标平台为核心的新一代 BI 架构，通过自动语义和增强计算两种核心能力的建设，部分解决了传统 BI 平台在个性化数据集驱动下产生的数据口径混乱、查询性能差等问题。
\n自动语义能力实现了“定义即研发”。它将业务语言定义的指标自动解析为结构化的逻辑表达，并通过主外键关系将数仓模型自动关联成星型、雪花等模型，从而扩展出复杂指标。该能力贯穿了指标定义、模型关联、指标高亮与路由选表以及查询语义构建的全流程。我们利用自动语义能力，并结合指标仓库的预计算模式，不但使业务能够灵活扩展、查询、分析复杂指标，也满足了在有限时间内完成指标扩展、模型关联等复杂查询前置依赖计算的要求。
\n增强计算能力则旨在平衡运营监控（要求秒级响应）与灵活分析（处理海量数据）两种场景下的性能与成本挑战。它通过智能查询服务（支持多引擎模型、查询降级策略）和智能物化（自动构建宽表和汇总表）来提升查询稳定性和性能。此外，我们也对增量计算引擎进行探索，利用其存算分离、弹性伸缩、向量化执行等特性，进一步提升了查询性能和系统稳定性。
\n目前，该平台已支持公司百余业务线，查询量达百万级，查询成功率超过 99.9%，并在新引擎评测和灰度中验证了性能优势。未来，美团将继续在自动语义、增强计算深化演进，为数据分析智能化做好准备。
\n近年，各种组织都在使用 BI/ABI（Busniness Intelligence/Analytics and Business Intelligence）平台，对数据进行建模、分析、可视化，支持有效决策和价值创造。随着技术的进步，BI 已由传统的以报表为核心的 ETL 驱动模式，变为了以数据集为核心的敏捷驱动模式。在后者，数据消费者（数据运营、数据产品、分析师等）可以通过 BI 平台中的无代码 ETL 工具或者 SQL 构建个性化的数据集，进行图表制作、自助分析，无需完全依赖数据研发进行开发和排期，具有一定的灵活性。但也带来了数据质量低（大量数据集导致口径不一致，数据混乱），查询效率低（非研发建立 SQL 数据集性能难以保障，抽取到各种分析引擎中又导致查询资源浪费），可复用性差（指标维度无法跨数据集分享，更难以在不同工具不同系统间使用）等问题。
\n为了解决上述问题，2021 年由 Airbnb/Minerva 等公司首先提出了指标平台这一概念。指标平台使用唯一的指标层来连接下层数据和上层应用，贯穿指标定义、管理、研发、应用全流程，来解决数据混乱问题。在强调数据治理的同时，也通过指标复用在一定程度上避免了资源浪费，理论上可以达到治理、成本、效率的平衡。近些年来，指标平台逐渐发展和完善，从最开始的仅仅进行指标口径治理的管理平台，过渡到了能够连接下游 BI 应用的管理、应用打通阶段。国内大型云计算供应商和传统 BI 产品厂商，均在分析套件中提供了指标平台产品，国外 Gartner ABI 分析报告在 2023 年将指标仓库（Metrics Store）列为了 BI 关键的 12 项能力之一，并在 2025 年将指标层（Metrics Layer）列为了 BI 常见能力的第一位。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/cd0fd66889cfdd726ddafcc474b0a4b7180607.png\")
指标平台的核心能力通常分为以下几点：
\n指标平台已经在业界有一定规模的实践，但从其驱动特性和具体落地看，比较适合于规模中小，数据需求相对固定的业务模式。面对数据体量大，需求变化迅速的业务（例如互联网、零售、金融等），往往有以下要求和挑战：
\n（1）更丰富的指标定义能力和表述语义，例如，指标限定指标（e.g. “本月营业时长大于 50 小时的商家平均营业额”）、忽略维度（e.g. “商品类型收入占比”=“收入/收入【忽略商品】”）、二次计算指标（e.g. “日均订单量”）、期初期末指标（e.g.“月初入职人数”）、存留指标。
\n（2）灵活的分析和扩展能力：业务不仅需要查询指标数据，同时也提出大量的分析需求（同环比、时间窗口、占比合计等），这些分析需求在由数据集驱动的 BI 工具中，往往由业务自助对数据集进行扩展和丰富完成。但在指标平台中，由于强治理诉求（例如：同环比定义的一致性）以及指标数据的具体实现被系统屏蔽，这些分析方法需要由平台能力进行统一的实现和沉淀。此外，业务需要在指标平台之外，灵活的扩展已有指标维度，进行实验性质的分析和探索。
\n（3）自动化、快速响应的语义层：一方面，要求根据指标定义，从明细层生成原子指标，衍生、计算成上层复合指标，并支持上述的查询、分析、扩展语义。另一方面，面对万级别的模型，指标，维度，迅速构建实际查询 SQL，有限时间内（BI 工具一般要求秒级响应）完成指标维度拓扑，模型选择淘汰，查询、分析语义生成。
\n（4）计算性能挑战：在定义即研发的模式下，指标取数和分析会转化为面向数仓明细层的海量数据查询，对查询引擎算力要求更高。指标平台一处定义，多处运行的模式意味着对运营监控（Serving）和探索分析（Ad-hoc）场景的兼顾：一方面是传统的面向运营用户看数模式，指标维度数量大，组合和筛选条件相对固定，要求性能响应高于数据规模；另一方面是灵活的分析探查模式，指标维度组合灵活，分析方法不固定，筛选条件和时间周期分散，要求数据规模高于性能响应。这两种矛盾的性能需求模式，对底层计算能力提出了更高挑战。
\n美团指标平台是美团内部自建的元数据及模型管理平台，面向数据研发、数据产品团队，提供业务全域下数仓规划、指标维度统一管理、标准建模及指标自动生产的产品能力与方法论。美团 BI 平台是公司级一站式数据分析平台，面向数据产运营、研发、分析师、管理者等多种角色，支持多种数据源便捷查询，灵活进行数据可视化分析，快速搭建数据报表和数据监控，提供安全、高效、敏捷的数据分析服务。
\n在建设初期，技术团队也遇到了业界自助敏捷 BI 的共性难题 ：一方面业务创建了百万级别的数据集，造成了口径混乱、数据不一致等问题，对查询性能也难以保障；另外一方面，初版指标平台提供的指标维度丰富程度无法满足业务需求，且仅提供查询语义，不能在 BI 工具上进行高阶数据分析，也无法进行指标维度衍生和扩展。为了解决以上问题，技术团队进行了新一代 BI 平台的开发：新架构以建设指标平台并打通 BI 应用为主要思路，在解决数据消费侧传统问题的同时，也注重数据生产侧的效率提升。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/dcdd27cdc35add1e32143a0e44af197b120002.png\")
新一代指标平台对数据仓库、自动语义、增强计算和分析工具等四个方面都进行了演进：
\n以上的各层系统演进，重点在于“自动语义”和“增强计算”两大核心能力的建设，下面我们将分别进行详细阐述。
\n自动语义将业务语言定义的指标口径解析为结构化的逻辑表达，并通过主外键关系将数仓模型自动关联成星型模型、雪花模型和星座模型，给原子指标提供了更丰富的分析视角，并扩展出衍生、复合指标。在实际执行查询计算时，自动语义根据指标定义和模型拓扑，通过智能路由选表构造逻辑执行计划和物理查询计划，实现定义即研发。
\n指标定义采用业务口径和技术口径定义相连接的设计，业务团队负责描述指标的业务计算口径，数仓团队负责提供指标的原子生产过程，指标平台可以根据注册的业务和技术信息推导非原子指标的生产过程并进行指标表达。美团指标平台具有以下能力：
\n基于模板表达完指标定义后，指标平台将其加工为结构化和逻辑化的指标血缘，指标血缘描述了复杂指标依赖哪些底层指标维度，采用树形结构来表达。指标血缘会将复杂指标的限定修饰、忽略维度、留存配置、二次计算配置等信息下推到底层指标维度上，从而等标记出底层指标实际查询时需要考虑的语义。指标血缘还对底层指标的查询语义进行唯一标识，帮助下游复用。如下 3 个计算指标（K1、K2、K3）都依赖了指标 K4，前两个 K4 的限定修饰都是【商家类型 = 大连锁】，可以复用同一个查询语义，而第三个 K4 具有不同的限定修饰【商家城市 = 北京】，需要单独进行查询。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/83bf899469daeecfe7f73af4678bbb3b68341.png\")
指标血缘描述了复杂指标依赖哪些底层指标及下推信息，但是仅仅依靠单个模型无法支持复杂指标的查询，比如上文提到的指标 K4 所在的事实模型可能不支持品类维度。为了扩展出更多的复杂指标，指标平台首先根据主外键对数仓模型进行连结，将多表关联星型模型、雪花模型和星座模型，为事实表上的指标提供更多的分析视角，从而扩展出复杂指标，节省了数仓开发成本。
\n如下所示是一个雪花模型例子，订单事实表上有商家维表的主键“商家”维度和日期维表的主键“日”维度，事实表就自动关联上商家维表和日期维表。同时商家维表也包含商家品牌维表的主键“商家品牌”维度，和商家蜂窝维表的主键“商家蜂窝”维度，商家维度也关联上商家品牌维表和商家蜂窝维表。如此通过层层关联最后形成如下的雪花模型，最终订单事实表上的指标多了商家的品牌维度、蜂窝维度、城市维度等分析视角，从而能支持“大连锁订单量”之类的复合指标，同时事实表上的指标也可以进行四则计算从而支持“单均价”之类计算指标。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/522c6f08844487f680b85c6f1671e8c8133499.png\")
经过自动关联后的雪花模型能提供丰富的维度，任意多个雪花模型都能对齐构建星座模型，如下表所示，星座模型数目 = 任意 2 个雪花模型对齐的星座模型数目+任意 3 个雪花模型对齐的星座模型数目+...+全部 N 个雪花模型对齐的星座模型数目。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/d44c7b161b8d852bf7750015382ea13d91602.png\")
可见从雪花模型出发构建星座模型存在模型数目爆炸风险，并且这些星座模型大多数对实际查询是无用的，因此指标平台舍弃构建全量星座模型，而是从指标的定义出发按需构建星座模型。但如果计算指标的成分指标有多个，那么星座模型数目等于各个成分指标雪花模型数目的乘积，也存在模型数目爆炸风险。考虑在后续查询过程中依旧需要对各个成分指标的雪花模型单独进行路由判定，所以指标平台舍弃提前进行组合，仅记录各个成分指标的雪花模型，称之为半成品星座模型。在查询时根据查询条件对雪花模型进行淘汰后再组合，大幅度减少星座模型数目。
\n自动关联模型后就可以计算指标的扩展方案，不同类型的指标定义具有不同的扩展方式，例如：
\n根据指标血缘的树形结构，最终复杂指标的扩展方案数目随着树深度和广度非线性增加，穷举容易导致扩展方案爆炸。在实际路由时指标平台考虑优先选择上层的、成分较少的成分指标来生成扩展方式，设计了带阈值和权重的广度优先搜索策略得到 TopN 的可扩展方式组合，保障了预计算和路由淘汰的计算量不会过大。
\n由上述细节可以看出，模型关联和指标扩展的计算逻辑存在各种遍历和排列组合，计算复杂度高，并且部分业务场景的请求需要全量的模型关联和指标扩展方案（比如后续介绍的指标高亮），现场请求计算往往无法在秒级内返回结果。技术团队在系统中采用空间换时间的策略，建设了“指标仓库”模块。该模块监听到上游元数据变更自动触发模型关联和指标扩展，将计算结果放在持久存储和缓存中，下游请求时为具体业务逻辑提供预处理的模型关联和指标扩展结果。
\n完成模型关联和指标扩展后，指标平台为下游提供了丰富的指标维度，但是因为部分业务场景之间天然存在隔离，某些指标一定无法在特定视角进行分析，技术团队在产品上采用高亮的方案进行相关信息的展示。指标平台采取点选的形式为用户提供报表配置或灵活分析配置，初始态所有指标维度都处于可选状态，当用户选择某个指标维度后，指标平台计算还有哪些指标维度能参与一起分析，能一起分析的指标维度处于高亮的可选状态，不能一起分析的指标维度处于置灰的可不选状态。高亮的计算逻辑主要分为模型匹配和指标可分析维度两个步骤。
\n模型匹配 是指根据用户配置和查询条件对所有模型进行匹配判定。不同业务场景有不同的匹配诉求，目前已有如下规则，用户可以根据需求自由选择组合：
\n模型通过判定规则后就进入指标可分析维度的计算，这里的计算逻辑分为雪花模型和星座模型两种情况：
\n雪花模型：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/f908fac01022337e96c29eb38475fa0a83434.png\")
星座模型：
\n指标 K3 有依赖成分 K1 和 K2，那么 K3 的可分析维度等于成分指标各个雪花模型组合交集的并集：UNION{INTERSEC(Dim(M1), Dim(M3)), INTERSEC(Dim(M1), Dim(M4)), INTERSEC(Dim(M2), Dim(M3)), INTERSEC(Dim(M2), Dim(M4))}=（D1，D3）
\n![\"\"](\"https://p0.meituan.net/meituantechblog/e9590f7ab06ce38c949c187cff514a08153970.png\")
通过高亮点选的形式完成指标维度选择和筛选条件的输入后，用户点击查询就进入路由阶段，此阶段根据用户查询条件为分析目标选择最优模型，从流程上来说分为模型匹配、维度路径选择和模型选择三部分。(1) 模型匹配可复用高亮计算逻辑。(2) 维度路径选择是对于雪花模型中维度选择最优的模型及其关联路径。考虑到各个模型中的维度值存在差异，模型选择策略根据数据完整性优先级递减分为以下五个层次：指标所在事实模型 > 维表模型 && 主键 > 维表模型 && 唯一键 > 非维表模型 && 主键 > 非维表模型 && 唯一键。模型集合确定后，可根据用户推荐、热度、查询性能选择模型，并选择评分最高的路径集合（通常基于贪心算法）覆盖所有查询的维度。针对部分场景对路由选表的确定性要求更高，也设计了非全局计算的稳定选择策略，保障多次规划结果一致。（3）在完成维度路径规划后，需要选择最优模型，此时指标平台通过评分机制进行选择，考虑因素包含引擎类型、推荐度、聚合类型、是否物化、计算方式、时间分区、底表数据量等。
\n查询语义服务基于指标仓库构建的逻辑视图和 OLAP 引擎提供的分析计算能力，允许用户描述查询意图(DSL，Domain Specific Language)并从中分析出需要表达的目标指标内容，再用执行计划加物理查询的的方式表达出目标指标的构建过程(SQL)，实现指标表义和数据消费。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/b03f26285cbeb0d684def1db9f58dcf1151995.png\")
查询语义服务的能力分为以下四个部分：
\n灵活多元的指标定义：业务可以基于已有指标、维度扩展定义私有的或一次性指标和维度，兼顾了通用（强治理）和定制化（灵活探索）场景。
\n查询意图表达：允许用户通过 DSL 表达其在指定分析场景下的查询意图，包含以下内容：
\n执行计划：将用户查询内容经分析转换，表达为任务拓扑，用拓扑节点之间的依赖关系表示指标的构建和表达过程，经过逻辑编排、分组、优化，确定最终的执行计划。
\n物理查询：物理查询以拓扑任务节点的形式参与执行计划，物理查询节点是执行计划拓扑的叶子节点，一个物理查询节点代表了一个具体的物理查询过程。物理查询 SQL 的内容组织结构，采用自下向上的三层（数据源层、模型层、逻辑层）结构表达：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/c78e7de93de5e9c3dd4f20e25e043ee7192282.png\")
在灵活的指标定义之后，还要保证查询性能和稳定性，在美团指标平台和 BI 分析平台，我们通过智能查询服务和探索最新计算引擎，分别从应用层和引擎层进行优化。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/590770bbd823f8b3359e951201ef5a73140057.png\")
2.2.1.1 自动降级查询
\n前文中提到，我们会存在性能响应高于数据规模的面向数据运营用户看数模式（Serving），也有数据规模高于性能响应的灵活分析探查场景（Ad-hoc）。为兼顾这两种查询模式，我们在计算层采用了多种模型和执行降级的策略。
\n多引擎模型：同一套指标维度可以绑定多种不同引擎类型的模型，比如既可以绑定到 BSP 架构引擎（e.g. Hive 表模型)也可以绑定到 MPP 架构引擎（e.g. OLAP 引擎表模型)，以应对不同场景的查询需求。
\n查询降级策略：如果有多套模型，我们首先会基于查询条件和查询代价选择最优模型进行查询，但如果查询失败或查询未在一定时间内返回，系统会自动降级到次优查询，以应对大数据量耗时久的灵活分析场景，提升查询成功率。降级策略分为以下两大类：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/de5b41be7a86168afa08e27a990994b8108164.png\")
2.2.1.2 智能物化
\n指标平台通过增强指标定义能力，实现了计算逻辑与语义在平台内的统一沉淀。用户可直接基于明细数据进行指标定义，无需依赖数仓复杂加工，但随之而来的是查询海量数据的性能挑战。“智能物化”方案应运而生，该方案充分发挥指标仓库的维度定义与智能路由优势，自动构建应用模型与汇总模型，并完成任务调度与数据回溯。物化后的模型将重新注册至指标仓库，为业务提供高效的指标化消费体验。通过预计算与数据聚合，智能物化大幅提升了查询响应速度。
\n智能物化主要分为两种实现形式：数据集物化和全局物化，两者的执行时机和目标各有侧重。
\n（1）数据集物化由用户主动发起，适用于用户定义新数据集并希望加速查询的场景。物化结果直接应用于数仓的应用层，供查询使用。我们提供了两种物化策略：
\n1.轻度聚合物化：适用于维度指标不固定的灵活分析场景，该模式下我们只物化所选指标依赖的原子指标和维度（包括私有维度），生成轻度聚合模型，物化后的模型保持支持灵活上卷下钻特性。
\n2.结果物化：适用于指标维度固定的场景，该模式下我们不再化原子指标，而是直接物化指标的计算结果，减少查询时的计算成本，进一步提升查询效率。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/cbf027a07348d0a3d3cded1e0c67225e72468.png\")
在技术实现上，数据集物化过程主要分为以下几个阶段：
\n（2）全局物化由系统根据用户查询行为（包括指标、维度、过滤条件等）自动触发。通过指标维度查询热度、关联统计、行为分析（过滤条件、分析方法等）、相似度检测、查询与存储成本分析，系统构建最优数据模型，以最低成本应对可变的查询条件。全局物化的构建结果将自动注册回指标平台，在指标仓库模型选择和查询服务路由中成为候选，和用户绑定模型、数据集物化模型互为补充。 全局物化结果也受数仓管理，物化过程严格遵循数仓规范，可被数仓其它下游复用。
\n2.2.2.1 现状分析
\n传统的大数据生产服务链路中，由通用引擎（GP）进行数据生产，输出明细和轻度聚合数据；而后导入分析引擎（AP），进行服务层和应用层构建，对接 BI 等各种消费应用。其中，通用引擎和分析引擎，主要区别如下：
\n指标平台的计算部分具有以下特性（1）原子指标定义在数仓明细层，上游的复杂指标经过拆解后，查询 SQL 面向海量数据，事实表维表频繁关联（2）查询 SQL 由语义服务自动生成，类似于机器生成代码，逻辑正确但复杂度高、性能差 （3）常用分析语义（同环比、占比等）也由查询服务即时生成，而非传统 BI 中的固化结果，带来了更大的计算量。以上三点对计算引擎的性能和可靠性提出了更高的要求。
\n通过降级查询和物化策略，我们可以在应用层面部分解决上述问题，将需要快速查询响应的物化在 MPP 引擎上，数据规模大的明细层查询作用在 BSP 引擎上，在保证性能的同时也保留了灵活分析的能力，但依然有以下不足：
\n近年来，随着关键技术（Native runtime，向量化执行，Delta Table 格式等）发展和存算分离、湖仓一体等概念的引入，两种引擎都有了飞速的进步。BSP 侧通过 Native runtime 和向量化执行，缓存优化，在小数据量和单点查询上性能大幅提升，直接对接数据消费应用层成为了可能；MPP 侧通过存算分离、CBO 改进，在保证性能的同时，数据规模/查询复杂度支持加强，逐渐向生产侧下移。两种架构的界限变得模糊了许多，在这种趋势下，出现了云原生、存算分离、单一引擎（SingleEngine）的架构路线，其中最典型的是国外的 Snowflake；国内也涌现出一些成熟的供应商，其中我们对云器科技的 Lakehouse 进行了深入的调研和合作。
\n2.2.2.2 Lakehouse
\n云器 Lakehouse 是由云器科技自主研发的新一代云湖仓。使用增量计算的数据计算引擎，性能可以提升至传统 BSP、MPP 开源架构的数倍，实现了海量数据的全链路-低成本-实时化处理，也为诸如 AI 创新提供了支持全类型的数据存储、计算平台。云器 LH 通过引入统一计算引擎，扩展弹性支持，存储优化，多重调度模式，向量化执行等几个方面，对传统的计算引擎在性能、成本、可靠性上进行了大幅提升，主要包含：
\n2.2.2.3 系统集成
\n美团数据生产消费具有海量数据（PB 级），查询量大（日百万级），实时性强（分钟级），稳定性要求高，安全合规严等高准入门槛，因此在接入云器 LH 作为计算引擎的过程中，既要能够验证生产环境下的性能收益，也要保障不影响线上查询和其他系统稳定性。我们设计了流量回放、线上双跑、灰度放量等多个接入阶段，在保障功能兼容、结果准确、线上稳定的同时，对性能和成本指标进行评估。
\n当前云器 LH 已经在美团两个数据中心进行了集群的部署。对接现有 BI 生态的系统方案，主要由以下设计考量/取舍：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/a2c7ace9199af51bd1e54f713f4ce6c8166885.png\")
美团指标平台经过几年的建设和应用，当前承接公司百余个业务线，其中模型规模达万量级，指标维度规模达十万量级。对应的 BI 应用，日查询量达百万级别，第三方应用日 API 调用量千万级别。查询成功率超过 99.9%，灵活探索场景查询时长 90 分位控制在分钟级别，运营监控场景查询时长 90 分位达到秒级别。
\n在云器 LH 的探索和实践上，为了确保线上稳定性和准确性，我们采取线上双跑和线下压测两种方式进行实验和评测。线上双跑，指在生产环境中对任意一次物理查询分别对不同引擎发起一次查询，异步对返回数据进行正确性校对并记录性能数据；线下压测，我们使用生产环境中大流量报表的真实流量进行回放，采用递增 QPS 方式测试系统极限性能并记录各阶梯压力下的性能指标。
\n在灵活探索（Ad-hoc）场景，我们采用线上双跑方式进行评测，灰度了部分时间内某业务线下的全部指标平台查询流量，涉及 84 张表，1000+TB 数据。对比组采用流行开源引擎 Trino 和云器 Lakehouse。Trino 采用 MPP 部署架构，千核集群；云器 LH 采用同配置（CPU 核数、内存、网络带宽）的 AP 模式，最大 VC 副本量设为 3。云器 LH 比 Trino 集群有 2 倍的性能提升，其中具体的查询百分位数据如下（单位毫秒）：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/b18366a5ade70cba56d623cf7d02a1d586570.png\")
在运营看数（Serving）场景，我们采用线下压测云器 LH 方式进行评测，回放某大流量业务报表单工作日全部查询流量，涉及 20 张物化加速表，0.79T 数据。压测三轮，QPS 从 40 开始递增至 80 结束（线上实际 QPS 小于 10），每阶段持续 5 分钟，云器 LH 性能指标在各种压力下表现平稳，展现了优秀的弹性和资源隔离能力。具体数据（单位毫秒）如下：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/13919cbf0877b144b06790f69fae3a0144181.png\")
美团 BI 和指标平台的下一步发展，将继续在自动语义和增强计算两部分演进，并发展智能化能力。
\n美团 BI 工具结合指标平台能力，已经孵化了自然语言数据助手、仪表板分析板助手等智能化产品，下一步将扩大业务场景范围，在数据准备配置、自然语言取数、分析辅助和自动报告生产上进一步提升产品能力，帮助业务持续提升运营效率。
\n", "image": "https://p1.meituan.net/meituantechblog/cd0fd66889cfdd726ddafcc474b0a4b7180607.png", "date_modified": "2026-05-19T10:28:27.000Z", "authors": [ { "name": "zhengzhong03@meituan.com" } ], "tags": [] }, { "title": "重塑站外体验：大众点评 M 站基于 Qwik.js 的重构实践", "url": "https://tech.meituan.com/2026/03/13/Qwik-practice-in-dianping.html", "id": "https://tech.meituan.com/2026/03/13/Qwik-practice-in-dianping.html", "summary": "为突破传统 Web 框架的性能瓶颈，大众点评增长团队引入 Qwik.js 重构 M 站核心页面架构，解决了重构前页面加载慢、维护成本高的难题。借助“可恢复性”能力，我们甩掉了传统水合的性能损耗，搭配全链路优化与工程化适配，让各个页面的性能指标都得到了明显提升。本文将拆解本次重构的技术选型、原理与落地细节，沉淀前沿框架在站外场景的落地经验。", "content_html": "什么是 M 站？M 即 Mobile，对大众点评而言，M 站是面向公域的流量引流入口，经近年 M 站与 PC 站形态融合、交互链路剥离后，定位进一步明确为“信息展示 + 点击唤端”的极简触点。我们所维护的大众点评 M 站，也由此聚焦至商户详情页、内容详情页、首页这三大高流量页面。在移动互联网流量进入精细化运营的背景下，主流互联网厂商均将交易、内容生产等高用户价值链路从站外转移至 App 站内，而 M 站则成为全域流量的核心收口与高效转化载体，承担着将搜索引擎、社交生态、厂商合作等渠道的免费或低成本公域精准流量，转化为 App 日活用户（DAU）的最后核心节点。作为大众点评对外流量的第一触点，这类页面无复杂的业务交互链路，只聚焦于“让用户看到信息 → 觉得有价值 → 点击唤起 App” 的极简转化逻辑。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/98fbedd90c4c8573785b6065d2eb44ff1560296.png\")
对于这部分以“目的性极强且无粘性”为特征的访客而言，“第一印象”直接决定承接效果，用户的注意力 100% 集中在“页面能不能打开、打开快不快、信息清不清晰”上。因此，M 站的性能表现并非单纯的前端体验指标，而是无容错空间的流量转化生命线：页面白屏过长会导致用户因等不下去跳出，前期所有流量运营动作都会前功尽弃；同时，M 站页面性能也直接决定了下沉市场、增量用户群体对平台的初始心智，这部分用户也是增长产品期望触达的群体。基于此，大众点评 M 站重构的核心技术目标十分明确：就是让最差的设备加最差的网络，也能流畅打开页面，最大化挖掘公域流量的转化价值。
\n大众点评 M 站核心页面在重构前性能表现不佳，首屏加载体验存在明显短板，流量转化效率受限于性能瓶颈，陷入“体验差 → 转化低”的恶性循环。性能短板已成为制约免费公域流量资源利用率提升的根本瓶颈。从 2025 年 Q3 开始，产品侧就核心页面提出完全对齐站内样式的诉求，通过视觉与信息展示逻辑的统一降低认知成本，同时点评技术部发起全渠道用户体验提升专项，聚焦站内外核心链路体验优化，主动攻克 M 站性能难题。我们于去年下半年启动了对 M 站核心页面的重构，覆盖商户详情页、内容详情页等站外流量最高的页面，并于下半年陆续完成上线。
\nM 站页面在过去几年陆陆续续进行过一些修修补补，但最核心的商详页模块复杂，涉及到餐综、境内外等多种类目和场景，一直停留在一种早已停止维护的技术栈，本质是由小程序 DSL 通过编译时构建生成 Vue 产物。它的局限性也是显而易见的：① 首屏渲染效率低下（在无缓存的首次访问场景中页面白屏时间较长）；② 运行时存在性能瓶颈（跨端编译产物天然存在冗余，首屏核心渲染依赖的资源体积偏大，弱网环境放大体验问题）；③ 开发维护成本高（框架早已停止维护，学习成本极高，与流行的 AI Coding 体系完全脱节，开发体验割裂）。
\n考虑重构的复杂度，继续基于这套停止维护的旧技术栈迭代已不具备可行性。我们聚焦自身业务场景，深入分析站外页面性能优化的核心要点，明确极致的首屏资源控制与按需加载的交互逻辑，是突破性能瓶颈的关键方向。
\n以最先重构的商详页为例，商详页的站外场景有四个不可突破的约束，直接框定了渲染方案的选择范围：① 无预优化能力，首屏资源必须 “从零加载”；② POI 数据需要保持实时性；③ 大众点评 POI 数量超千万级，预生成成本极高；④ 搜索引擎为商详页、笔记页带来巨量来源，有强 SEO 诉求。在主流的渲染方案中，服务端渲染是当前场景下的唯一解法。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/6cdbde5ee06f900c715e3347b8f61bd2280197.png\")
在技术选型上，我们对前端社区较为流行的服务端渲染方案做了全面的调研与评估：目前 Next.js、Nuxt.js 已成为行业内 SSR 的主流解决方案，不少头部厂商的 Web 基建以及公司内部部分团队的自研 SSR 框架，均基于这类成熟框架的二次封装与能力扩展；同时，SvelteKit、Qwik 等新兴的高性能 SSR 解决方案，凭借其创新的编译与运行时设计以及亮眼的数据，也逐步成为前端社区的讨论热点。
\n完全以 React 为模板的 Next.js 作为公司站外生态的成熟基建方案，具备稳定、易落地、学习成本低的优势，但在站外纯 H5 场景下受限于无容器预请求、无 JS 预加载而无法“借力”，其性能表现存在明显上限，此前已使用 Next.js 重构的 M 站 UGC 详情页（非同构）的首屏体验仍有提升空间。Next.js 是稳中求进的选择，但要实现性能的破局式提升，需要探索一些更具挑战性、前沿性的技术选型；SvelteKit 的 DSL 不太主流，学习成本稍高；Qwik 作为前年发布的新兴框架，生态尚不完善，在公司内甚至是国内主流互联网厂商内都没有公开落地的案例，只能依赖官方文档解决问题，框架的认知门槛与工程化落地成本也相对更高。
\n选型并非盲目追新，而是基于场景匹配度与收益成本比的理性决策，否则可能一时拍脑袋最后还得灰溜溜换方案。
\n首先，Qwik 是三种方案中首屏渲染所需资源体积最小的，其零水化特性从根源上解决了传统 SSR 的水合性能损耗，也天然对弱网和低端机型友好，能直接支撑首屏秒开提升的目标，Qwik 框架通过其独特的可恢复性设计，显著提升了应用的性能基线，这意味着在同等业务复杂度下，Qwik 能为应用提供更高的性能起点和更强的抗压能力，从而在一定程度上缓冲因业务逻辑实现不理想而带来的性能损耗；其次，C 端标准化交付场景下视觉还原和 UAT 限制了交付产物的“个性”，组件库在 C 端样式高度定制的场景下重要程度不高且可以借助 AI Coding 补齐能力；对于无复杂交互且加载时请求全量数据的以展示为主的界面来说，在业务封装和适配公司基建上也不需要投入太多，确实可以追求更轻量化的框架；Qwik 虽然生态成熟度不足但核心缺失的工具链仍可通过自研补充，Qwik API 与 React 高度同源，对 React 开发者来说只需学习少量 API 便可上手。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/c3af7e63932f21c65e373145c36ded5e450810.png\")
我们还借助 AI Coding 前置实现最小 Demo（同时实现 Next.js、SvelteKit、Qwik 版本并对比各项指标），Qwik 虽然落地门槛高但我们已攻破大部分问题并在公司平台上跑通整套构建和部署流程，且性能指标也非常亮眼。相比性能提升带来的业务价值，这些落地成本显然是可接受的。
\n基于以上背景与思考，我们确立了本次 M 站重构的技术目标：跳出既有技术框架的性能桎梏，从零开始探索 Qwik 生态在站内的落地可行性，兼顾极致的用户体验、高效的流量转化与可持续的研发迭代，最终落地一套可复用、可沉淀的站外渲染架构。
\n我们选定 Qwik 作为重构技术栈，是因为它相较于其他方案加载白屏时间短、达成可交互的所需资源少，这也正好是我们对新版页面的构想。想要理解 Qwik 的性能优势，我们先从传统 CSR/SSR 方案的水合讲起，再谈谈 Qwik 的 Resumability 原理，以及编译期优化带来的极致产物体积优势。这也是 Qwik 能在同类前沿框架中脱颖而出的核心竞争力。
\n无论是纯客户端渲染（CSR）还是主流的服务端渲染（SSR），传统前端框架的交互能力恢复都离不开水合这个环节。水合的是客户端对服务端预渲染 HTML 的激活过程。服务端仅能输出无交互能力的静态 HTML，想要让页面具备点击、跳转、数据更新等交互能力，客户端必须完成三个核心动作：
\n这个过程需要全量加载、全量执行、全量绑定，缺一不可。页面想要完成就绪，必须等所有 JS 加载完成、所有逻辑执行完毕，哪怕用户仅需要一个“唤起 App”的点击动作，或是首屏注入唤起点位或者执行弹窗，也必须加载整个页面的 JS 资源。此外，水合不匹配、资源加载阻塞等情况都会直接导致页面白屏，每多等一毫秒都可以导致一部分用户直接关闭页面。
\n从我们的数据来看，M 站有 50% 以上的流量来自 30 天内首次访问，对 M 站这类站外纯 H5、无容器预热、无资源预加载、无接口预请求、无缓存加持的场景，水合的损耗被无限放大，形成不可逆的性能瓶颈。
\n高版本 Next.js 常使用选择性水合、启用 SWC 压缩等方式缩短水合时间，但依旧存在优化空间。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/8785ad48708ec1da2f22aaa3ff2904f1342794.png\")
Qwik 最核心的设计理念是“跳过水合，直接恢复交互”，其底层是 Resumability（可恢复性）。它指的是：服务端不仅渲染静态 HTML，还会序列化组件的状态、事件绑定等信息并嵌入 HTML；客户端无需重新执行组件逻辑，仅在用户触发交互时，按需加载极小的交互代码片段，从根源上消除水合过程。
\nResumability 的核心是：HTML 不再只是“骨架”。
\n在传统 SSR 中，服务器返回的 HTML 只包含静态的 DOM 结构，所有的\"灵魂\"（状态、事件监听器、组件逻辑等）都丢失了，必须在客户端通过水合过程重新注入。Qwik 彻底颠覆了这一模式：HTML 不再只是视图的静态快照，而是应用状态的完整序列化存储。其他所有框架的水合都会在客户端重新执行所有应用程序逻辑，而 Qwik 则是在服务器上暂停执行，然后在客户端上恢复执行。
\n仍以大众点评 M 站的 POI 详情页核心交互为例，我们先来看一段使用 Qwik 实现的代码片段，这段代码抽象了商户信息和唤端按钮这两个逻辑：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/6ee4162f0c320ca35dad061891099a73505591.png\")
阶段一：离线打包构建和服务端编译阶段
\n和任何 SSR 框架一样，Qwik 对 HTML 文档的组装分为离线打包构建和服务端编译两个阶段。前者通过 Rollup 生成 CDN 静态产物：碎片化、可按需加载的 JS 文件和 CSS 等静态文件；后者根据实时请求的数据生成 HTML 文档。这两个部分 Qwik 主要做了以下操作：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/4a478e131c4e05217ba07e5d555367331281283.png\")
1.组件边界构建
\n框架与组件树协同工作，一般情况下框架需要完全理解组件树以知晓哪些组件需要重新渲染以及何时重新渲染。在传统框架中，组件结构仅存在于 JavaScript 运行时的堆栈或虚拟 DOM 中，为了重建组件树信息框架会重新执行组件模板并记忆组件边界的位置。但 Qwik 中并没有大规模启用虚拟 DOM。为了让 HTML 具备描述组件树的能力，Qwik 引入了组件边界的概念。Qwik 编译器会在组件周围包裹 <!--qv--> 虚拟宿主节点，这些注释并非无意义的占位符，<!--qv--> 和 <!--/qv--> 分别标志了组件节点的开始和结束，这些节点使得 Qwik 实现在扁平的 DOM 中重建组件树结构。这些节点携带了关键索引属性：q:id 作为组件实例的唯一标识，用于关联后续序列化状态中的数据索引；q:key 用于列表渲染；q:sref（State Reference）标记了该组件订阅了哪些响应式数据。这使得 Qwik 无需在内存中维护虚拟 DOM，仅凭 HTML 标记即可识别组件层级与更新范围。
\n<!--qv q:id=a q:key=tL5t:jQ_0-->\n<div style=\"color:blue\" q:key=\"jQ_3\" /> <!-- 某一组件编译生成的 DOM 结构 -->\n<!--/qv-->\n备注：以上为Qwik生成的代码片段，下同
\n2.标签序列化
\nQwik 框架会将事件处理器序列化为 QRL 信息[1]（Qwik Resource Locator，例如： ./chunk.js#handler）。它指向一个将被延迟加载的 JS 代码块，用于告知 Qwik 代码处理器应从何处加载。这种结构被编码成字符串，直接写入 HTML 属性中。此时，DOM 节点不仅包含视觉结构，还包含了交互逻辑的“入口地址”：
\n<!-- ./q-CyCA2y-K.js#s_pElXkJ1YLxE 指向 q-CyCA2y-K.js 导出的 s_pElXkJ1YLxE 方法 -->\n<button on:click=\"./q-CyCA2y-K.js#s_pElXkJ1YLxE\" q:key=\"jQ_2\">App内打开</button>\n3.依赖收集与状态持久化
\nQwik 自顶向下只收集事件监听器捕获到的变量及其依赖。通过递归收集和去重优化，所有需要持久化的状态对象会被编号组成一个对象池数组(<script type=\"qwik/json\" /> 中)。HTML 中的 q:id 和 q:sref 只是索引，真正的状态数据存储在底部的 JSON 中。例如，在上述示例的 JSON 中，refs 表示引用映射表，关联标识与对象索引，用于快速查找；objs 存储实际数据，包含状态对象、原始值等实例；ctx 表示上下文容器，存放组件/应用的上下文相关数据（如路由信息、注入依赖）； subs 则为响应式订阅配置，订阅信息记录了依赖关联，会告知 Qwik 哪些组件需要因状态变化而重新渲染。
\n<script type=\"qwik/json\">\n {\"refs\":{\"9\":\"0!\",\"d\":\"6!\"},\"ctx\":{},\"objs\":[{\"likes\":\"9\",\"isAppOpen\":\"a\"},\"\\u00110! @1\",\"#8\",{\"state\":\"0!\"},\"\\u00113! @2\",\"#b\",{\"state\":\"0!\"},\"\\u00116! @3\",\"#e\",100,false],\"subs\":[[\"_1\",\"3 #8 1 #8 likes\",\"3 #b 4 #b likes\",\"3 #e 7 #e isAppOpen\"]]}\n</script>\n阶段二：客户端执行阶段
\n客户端加载完编译后的 HTML 后，全程无需执行全量应用 JS，无需重建组件树，无需绑定全局事件，仅通过极小体积的 Qwikloader 实现 “按需恢复交互”。以点击唤端按钮为例，整个流程分为三步：
\n![\"\"](\"https://p1.meituan.net/meituantechblog/08f91d816f4c66649f59cc30559eeb471162205.png\")
1.Qwikloader 初始化
\n客户端加载 HTML 后，首先会执行 Qwikloader（Qwikloader 的体积极小，通常小于 1KB，不会对首屏渲染造成任何阻塞），Qwikloader 在 document 上注册全局事件监听器（如 click），用于捕获用户的交互行为，用户的每一次点击行为都会向上冒泡并由 Qwikloader 处理。此时浏览器只需完成 HTML 的解析与渲染，即可展示完整首屏，首屏渲染耗时≈HTML 加载耗时。
\nQwik 的事件机制乍一看和 React 的事件委托很像。但 React 是为了适配虚拟 DOM 的事件系统，而 Qwik 是为了更好地管理“延迟加载” 。
\n2.交互触发
\n当用户点击 “App 内打开” 按钮时，点击事件会向上冒泡，被 Qwikloader 的全局事件监听器捕获。此时 Qwikloader 会读取按钮 on:click 属性中的 QRL 地址（./q-CyCA2y-K.js#s_pElXkJ1YLxE）。一般情况下，Qwik 可以通过 modulepreload 机制提前预加载对应的 JS，但当 JS 片段未下载时 Qwik 也会按需加载对应的 JS 片段（q-CyCA2y-K.js），这一片段体积往往仅几百字节。
\n3.逻辑执行
\nJS 片段加载完成后，Qwik 会直接执行其中的 s_pElXkJ1YLxE （QRL 中 # 后面的部分）方法，这一部分对应着唤端逻辑。
\n如果涉及到状态变更，Qwik 会更新 JSON 快照中的对应状态，通过遍历 subs（订阅表），找到与该状态关联的 DOM 节点；调用 HTML 底部预编译的辅助函数，计算新的 DOM 内容并完成按需更新。
\n整个阶段的流转（以点击唤端按钮为例）大致如下：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/14f6fe8c3bbce7faf25963d4b1423766167098.png\")
Qwik 之所以快速，并非因为它使用了巧妙的算法，而是因为其设计方式使得大部分 JavaScript 无需下载或执行。这套 Resumability 设计原理完全区别于传统 SSR 的技术体系，从根源上解决了传统 SSR 方案中首屏 JS 体积臃肿、水合过程阻塞主线程、交互恢复延迟等痛点。此外，这套无需水合的流程使得渲染性能得到提升，在低端设备上的内存压力得到缓解。为了更直观地对比这种技术差异，我们对传统 SSR 方案与 Qwik.js 方案进行详细的对比分析：
\n![\"\"](\"https://p1.meituan.net/meituantechblog/4ab0071118d941349386bc4938b1bce3488677.png\")
Qwik 产物体积远小于传统框架的另一原因，是编译期的极致细粒度拆分。在 Qwik 中，所有内容都是可延迟加载的，无论是组件、方法、监听器还是样式。它相较传统框架（如 React/Vue）的按组件拆分，可以更精细到而是按事件/交互拆分，每个交互逻辑都是独立的极小 Chunk，且框架核心代码通过延迟加载且仅在必要时加载。
\nQwik 对产物拆分的秘诀藏在这个我们熟悉的符号里：$。当开发者在 Qwik 中编写带 $ 标记的函数（如 onClick$ ），Qwik 的 Rust 优化器会自动将其转换为 QRL，这一过程完全无需开发者手动拆分。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/31eb9003c3f99df7c08131c71c27b95f277261.png\")
Qwik 的架构充分利用现代工具来自动解决 entry point 生成的问题。优化器在打包过程中是作为 Vite 插件运行的，打包工作由我们熟悉的 Rollup 完成。在这里，每个带 $ 的函数被提取为独立的代码块（chunk）；函数的闭包变量（如示例中的 count）被序列化并存储在 QRL 的索引数组中；HTML 中只保留 QRL 字符串，而非实际代码。
\n上文提到的 Qwikloader 所做的贡献在这里需要再次被强调。浏览器加载 HTML 后，Qwikloader 注册单个全局事件监听器，用户点击按钮时，事件冒泡至全局监听器，Qwikloader 解析元素的 on:click 属性获取完整 QRL，使用 q:base（或文档 BaseURL）将相对路径转换为绝对 URL，在下载所需的极小代码块后，Qwikloader 从 chunk 中提取指定符号，使用索引数组从 HTML 中恢复闭包变量，最后执行目标函数，完成交互逻辑。QRL 能自动序列化并恢复函数的外部作用域，这是传统动态 import() 无法实现的突破。
\n以页面信息组件为例，该组件在 M 站旧版架构中的编译后产物 ≈ 150KB（含运行时和全量逻辑），而 Qwik 首屏仅加载 1KB 的 JS，交互时按需加载几百字节的片段，提供了近乎即时的启动性能。大众点评 M 站重构后，核心 POI 详情页的首屏核心 JS 体积从 2MB 降至不足 10KB（仅框架核心和必要元数据），这是产物体积骤降的主要原因。
\n但这里我们仍需解答两个问题：懒加载脚本会影响用户交互体验吗？延迟加载会带来 bundle 数量的上升吗？
\n第一个问题，可能会。Qwik 既然选择在触发用户行为时再惰性加载并执行响应的 JS 脚本，那么难免需要在用户触发交互时动态生成对应的事件处理函数进行执行，但 Qwik 的事件绑定机制保障了交互不会丢失，运行时会在捕获事件的同时异步静默加载对应的事件处理器代码。其次， Qwik 引入了智能预加载模块（PreloadModule）对这一场景进行了优化。预加载模块允许应用在用户实际需要之前就开始在后台下载必要的代码，当用户鼠标悬停在可交互元素上、或页面滚动到某个元素可见区域时，Qwik 会提前静默加载该元素对应的交互代码。只有在网络条件极差的场景可能出现交互延迟，而这种情况对于主流的 React.lazy 来说也同样不可避免。
\n第二个问题，会。但 Qwik 推崇的延迟加载其实已经是一项非常成熟的构建技术了，无论是使用 webpack、rollup 又或是其他任何构建工具都存在延迟加载和代码分割的技术。而 Qwik 的目标并非要减少 JS Bundle 的总量，而是根据用户交互逐步下载 JS，所以这个问题的答案并不重要。
\n随着业务的迭代，应用变得更加复杂，代码变得更加臃肿。但得益于极致的代码块拆分，使用 Qwik 开发的应用的性能（可能首屏需要加载更多的 DOM 结构，但不会增加 JS 下载量）并不容易随着网站复杂度的提升而劣化。
\nQwik 在编译期还做了三大核心优化，进一步降低产物体积与运行时开销：
\n1.预编译：传统框架（如 React、Vue）的响应式依赖是在客户端运行时完成的。Qwik 在编译期就会分析 useSignal、useStore （对应 React Hooks 中的 useState）等响应式 API 的依赖关系，明确 “哪个状态对应哪个 DOM 节点或哪个更新逻辑”，仅需执行编译期预生成的更新指令即可完成状态与 DOM 的同步，大幅减少运行时计算开销。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/7784a627fc2e29680fda82e390e4c8891082392.png\")
2.虚拟 DOM 规避：Qwik 在大部分场景下规避了 React 所使用的虚拟 DOM，默认场景下无需虚拟 DOM，编译期会预分析响应式状态与真实 DOM 的绑定关系，生成组件边界和 DOM 自动化更新指令，直接操作真实 DOM 完成同步；仅在响应式状态发生变更（由交互或异步操作触发）时，进行细粒度的真实 DOM 更新，避免传统框架的虚拟 DOM 创建、对比与补丁开销。仅在大规模动态节点批量更新等特殊场景下，会临时使用局部轻量级虚拟 DOM 作为辅助工具，且更新完成后立即回收，不产生长期运行时开销。
\n3.Tree Shaking 极致化：作为现代化打包构建工具 Vite（Rollup）的杰作，Qwik 的 API 设计（结合 QRL 资源定位机制）天然支持接近极致的 Tree Shaking，未使用的逻辑（如未触发的交互）不会被打包进入初始加载产物，仅保留轻量级引用标记，初始产物无冗余核心代码；未触发的交互逻辑会被打包为独立分包，等待客户端按需加载，进一步降低初始产物体积。
\nQwik 作为新兴 Web 框架，极低的学习成本与 React 几乎一致的开发范式是我们在 M 站敏捷落地的关键因素。M 站首个启动的重构项目留给研发的窗口只有两周时间，产品对技术探索的鼓励并不意味着排期能更加宽松，我们仍需从工程层面去审视其落地的成本。
\n较低的学习准入门槛
\nQwik 的设计初衷就是兼容 React 开发者的开发习惯，其核心 API 与 React 保持高度同源，仅在响应式状态、组件声明、事件方法上有微小的语法差异，所有差异均为增加标记符而非重构写法，React 开发者几乎可以做到零学习成本直接上手开发。此外，得益于 AI Coding 工具对 Qwik 的支持度相当高，我们在 H5 业务中沉淀的 AI 提效经验可以无缝复制到 Qwik 项目中，进一步抹平了语法差异带来的阻力。
\n我们来简单看一下 Qwik 和 React 核心写法的对比：
\n![\"\"](\"https://p1.meituan.net/meituantechblog/ff52cf46d0123e41607c2d00443e210b627750.png\")
Qwik 项目在目录结构上和 React 也完全没有差别。尽管它们在渲染原理上大相径庭，研发只需掌握 “组件用 component$、方法用 $、状态用 useSignal”这三条核心规则，就能直接上手开发业务代码，开发体验与 React 无任何割裂感。 如果你对 React 和 Qwik 的 API 差异感兴趣，可以阅读 Qwik 官网的 React Cheat Sheet。
\n虽然 AI 编程助手（如 GitHub Copilot、Cursor 等）能有效辅助 Qwik 的语法编写，但由于 Qwik 的社区生态和训练数据量目前仍显著少于 React 等成熟框架，AI 在理解 Qwik 特定模式、最佳实践和复杂场景下的代码生成准确率可能仍有差距。这意味着一部分在成熟生态中可由 AI 高效承接的探索成本，在 Qwik 开发中可能仍需开发者人工介入和调试。
\n从组件思维到序列化思维
\nQwik 在语法层面（特别是对于熟悉 React 的开发者）确实具有较低的上手门槛，但语法易上手并不等同于工程易精通。要充分发挥其性能优势并避免常见陷阱，开发者需要深入理解其 “可恢复性、序列化边界、延迟加载” 等核心运行机理。因此，其学习曲线更接近于 “入门容易，精通需深入理解其设计哲学”。
\n这里我们举两个简单的例子，在 React 中，闭包随处可见且无成本，但在 Qwik 中任何跨越边界的变量都必须是可序列化的，这意味着我们不能随意传递复杂的类实例；此外，如果开发者不理解 Qwik 延迟加载的特性，滥用 useVisibleTask（进入视口钩子，时机类似于 React 的 useEffect ）可能导致错误的依赖追踪，极易引发网络瀑布流，框架带来的 TTI[2] 优化可能会被抵消。
\n对底层运行机制的深度理解，以及对序列化成本的敏感度，是研发团队从写出代码进阶到写出高性能代码的必经之路。
\nQwik with React，渐进式迁移的兜底
\n退一万步讲，你一定会想“我有模块已经在 React 上实现了迁移过来是不是有成本”、“Qwik 没有自己常用的组件库，重新造轮子是不是很浪费”，这个问题完全不用担心，Qwik 提供了官方插件 Qwik React，可以将现有的 React 组件封装在一个 qwikify$ 函数中。该组件可以在 Qwik 内部使用并将 React 组件转换为一个独立单元，主流的 UI 库经测试均能以这种方式在 Qwik 项目里引用，这也是对 Qwik 生态缺失的快速弥补方案。
\n尽管这种混合架构提供了快速迁移路径，但每个封装组件本质上仍是一个独立的 React 运行时实例，每个 React 应用内部仍在发生着水合（但可以控制补水策略和时机），局部水合成本依旧是存在的。对于渐进式迁移的项目来说，仍需在 Qwik 原生写法带来的性能收益和直接复用 React 代码带来的工程效率上找到平衡。在 M 站商详页重构过程中，我们原本也计划将评价等外部业务团队维护的模块继续保持 React 技术栈，但我们很快就借助 AI Coding 快速抹平了 API，仅用几十分钟就原先的代码重构至 Qwik 的原生写法，这也可以给后续计划重构的业务提供参考。
\n结合 M 站的业务特性与站外场景的技术约束，本次 M 站商详页重构的架构设计，并非单一技术框架的落地，而是围绕“首屏最优”的目标打造的一套系统化工程方案。此外，为了让商详页的重构经验能在后续重构的其他页面中复用，我们深度融合了公司现有基建和技术体系，设计了基于 Qwik 的全套工具链和工程化能力。
\n| | | |\n|
\n", "image": "https://p0.meituan.net/meituantechblog/98fbedd90c4c8573785b6065d2eb44ff1560296.png", "date_modified": "2026-05-19T10:28:27.000Z", "authors": [ { "name": "dujiahao02" } ], "tags": [] }, { "title": "LongCat 为 OpenClaw 装上效率引擎：你的自动化任务还能再快 30%", "url": "https://tech.meituan.com/2026/03/09/LongCat-OpenClaw.html", "id": "https://tech.meituan.com/2026/03/09/LongCat-OpenClaw.html", "summary": "依赖第三方订阅进行非官方调用存在账号安全风险与服务不稳定性。为规避此类问题，LongCat 团队提供稳定合规的官方免费 API，开发者可通过官方渠道直接接入 OpenClaw，在确保账号安全的前提下构建自动化工作流。", "content_html": "OpenClaw 在开发者社区迅速获得 23万+ Stars，因其作为开源、本地优先的个人 AI Agent，能够将大语言模型的推理能力转化为对计算机的实际操作，为构建个人 AI 助手提供了系统级权限与自动化基础。
\n然而，近期部分平台开始收紧对非官方入口的访问。谷歌以“恶意使用”为由，大规模封禁通过 OpenClaw 路由 Gemini token 的用户账号，Anthropic 随后也更新使用条款，明确禁止通过第三方工具调用 Claude 的 OAuth token。这些事件表明，依赖第三方订阅进行非官方调用存在账号安全风险与服务不稳定性。为规避此类问题，LongCat 团队提供稳定合规的官方免费 API，开发者可通过官方渠道直接接入，在确保账号安全的前提下构建自动化工作流。
\nLongCat API 开放平台：
\nhttps://longcat.chat/platform/usage
\n下文将通过实测数据与典型案例，展示 LongCat-Flash-Thinking-2601 在 OpenClaw 上的性能表现，并附完整部署流程，帮助开发者快速构建个人自动化助理。
\n在执行效率方面，LongCat-Flash-Thinking-2601 展现出显著优势。在 21 个可比的非定时任务中，其平均单任务耗时仅为 2.35 分钟，相比对比模型快约 30%。这种高效率在不同复杂度的任务中均有体现：
\n在任务完成质量方面，LongCat-Flash-Thinking-2601 在涉及联网信息检索和 GUI 界面生成的场景中，能够准确获取信息并快速生成符合要求的输出，展现出较好的执行效率和稳定的任务完成能力。与此同时，我们也在持续优化模型在系统路径识别、脚本生成一致性等方面的表现，致力于为用户带来更全面、更可靠的自动化体验。
\n我们通过一系列开发者日常会遇到的真实场景，进一步来评测 LongCat-Flash-Thinking-2601 在驱动本地 Agent 时的技术表现。速度是贯穿始终的核心优势——无论是秒级的文件检索，还是分钟级的复杂任务编排，它都能快速响应，让开发者真正从重复劳动中解放出来。
\n复杂任务分解与顺序工具调用，这是 Agent 实现真正自动化的基石。
\n指令要求：
\n\n\n“在 Downloads 目录下创建一个名为 Projects 的文件夹，初始化一个 Python 3.10 的虚拟环境，安装 flask 和 requests 库，然后用 VS Code 打开这个文件夹…”
\n
技术表现分析：
\n我们给出的指令包含了一系列连续的、有依赖关系的操作。LongCat-Flash-Thinking-2601接收指令后，精准地对任务进行了拆解：mkdir -> python -m venv -> pip install -> code 。它准确地规划了每一步操作，并依次调用 OpenClaw 提供的 shell 工具来执行。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/87906241cb91f78131420c9f1b68aea369794.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/113973b7873dc9927f3ba11187814a1515511.png\")
![\"\"](\"https://p0.meituan.net/meituantechblog/30b1177d950242af2543976ce276b8be16520.png\")
整个过程在2 分钟内自动完成，没有步骤遗漏或顺序错乱。
\n一个高效的 Agent 必须能无缝地连接不同的服务。
\n指令要求：
\n\n\n“把这张图用 Google 的 Nano Banana 重绘成赛博朋克风格，生成好之后通过 iMessage 发给我。”
\n
技术表现分析：
\n我们通过 iMessage 发送一张图片，这个工作流涉及三个关键点：
\nLongCat-Flash-Thinking-2601 在这个过程中表现出色，成功调度了外部 AI 工具。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/31bc37e0c5d106777ecf0f294b451350258973.png\")
按照要求生成并发送了赛博朋克风格的图片，实现了无缝的跨应用协作。
\n从非结构化信息中提取价值并生成结构化产出，是开发中的高频需求。
\n指令要求：
\n\n\n“整理2015-2024这十年的TGA年度游戏信息，包括游戏发布时间、游戏简介、IGN评分、其他获奖记录等，并且每部游戏需给出高度概括的一句话评价。按获奖年份顺序进行排序，制作成一个主色调为深蓝+金色的精美网页。”
\n
技术表现分析：
\nLongCat-Flash-Thinking-2601 在此展示了端到端的能力：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/5ff5567fc541c5cc25e98a7af307875188386.png\")
游戏信息介绍按照指令要求展示。
\n最强大的 Agent 是那些无需提醒、能主动为你服务的。指令要求：
\n\n\n“每天下午17:40查询 github 的今日热榜并将其做成一个中文简报（需附带项目链接），完成后通过 imessage 发送给我。”
\n
技术表现分析：
\n设定一个长期、自动执行的任务，LongCat-Flash-Thinking-2601 成功地设置并执行了 cron 类型的定时任务。它能够在无人干预的情况下，周期性地执行信息获取、处理和推送，成为一个真正的自动化情报助理。
\n![\"\"](\"https://p1.meituan.net/meituantechblog/cb4286f49c70a7b133df9fe7153cc931628755.png\")
成功定位全部文件，并通过 iMessage 完成发送。
\n精准的本地文件检索与跨平台交互，是远程办公场景下的高频需求。
\n指令要求：
\n\n\n“帮我找一下电脑上《东鞑纪行》有关的文件，格式为 word 或者 pdf，可能在 Downloads 或文档目录下。找到后直接通过 imessage 发送给我。”
\n
![\"\"](\"https://p0.meituan.net/meituantechblog/0fa1d3c1f9d780dd4057056867be65e94454.png\")
技术表现分析：模型需要理解模糊的文件名（“东鞑纪行”可能并非精确文件名）、推测可能的存放位置，然后遍历目录、筛选匹配文件，最后通过 iMessage 完成发送。
\n![\"\"](\"https://p0.meituan.net/meituantechblog/5de6a882f64025293cb07fe22212e7ef358925.png\")
LongCat-Flash-Thinking-2601 成功定位到全部 3 个相关文件，并通过 iMessage 发送，文件完整无损。整个过程仅耗时 32 秒，充分体现了其在本地文件系统操作与消息通道集成上的高效率。
\n按照要求生成并发送了赛博朋克风格的图片，实现了无缝的跨应用协作。
\n在使用OpenClaw前，您需要准备好以下内容：
\n1.OpenClaw安装包
\nMacOS 环境下安装命令如下：
\n# 使用npm安装\nnpm install -g openclaw@latest\n\n# 或使用pnpm安装\npnpm add -g openclaw@latest\n\n# 或使用curl安装\ncurl -fsSL https://openclaw.ai/install.sh |bash\nWindows PowerShell 环境下安装命令如下：
\niwr -useb https://openclaw.ai/install.ps1 | iex\n2.LongCat核心配置
\n支持的模型：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/90f5f28060012fa2f0e034681e17c0ff43936.png\")
向导启动命令
\nopenclaw onboard --install-daemon\n向导配置选项说明
\n![\"\"](\"https://p1.meituan.net/meituantechblog/bf4f03e24bfdd915b5ea9991f88b6231166507.png\")
向导启动完成后，OpenClaw会自动启动Gateway服务并打开Web控制页面。
\n默认访问地址：http://127.0.0.1:18789
\n如果页面没有自动打开，可以手动在浏览器中访问上述地址。
\n配置文件位置：OpenClaw的配置文件位于：~/.openclaw/openclaw.json
\n启动后我们可以通过修改自定义配置来接入LongCat模型。
\n配置方案一：修改配置文件
\n![\"\"](\"https://p1.meituan.net/meituantechblog/bdba68b6131a7785904017c2fa565d9d126371.png\")
修改agents字段，设置默认模型：
\n![\"\"](\"https://p1.meituan.net/meituantechblog/d3d5966da6639bef088da6059e19f51231014.png\")
修改保存后立即生效。
\n配置方案二：GUI界面配置
\n1.在Web控制页面中，进入 Config → Models → Providers
\n2.添加如下配置：
\n![\"\"](\"https://p0.meituan.net/meituantechblog/5a409954a30c6f8feff109634b18002549851.png\")
完整配置示例地址：https://longcat.chat/platform/docs/zh/OpenClaw.html
\n配置生效后，即可使用 OpenClaw。
\n打开TUI，并查看Gateway状态
\nopenclaw tui\n/status\n打开Web UI，在Chat页面进行交互
\nopenclaw dashboard\n然后输入测试消息，如：\"你好，请介绍一下自己\"。
\n如果配置正确，您将收到来自LongCat模型的回复。
\n欢迎通过以下资源开始实践：
\n期待你的反馈与更多场景的探索。
\n对于追求极致效率的开发者来说，一个强大的本地 Agent 框架和一个为行动而优化的 AI 模型是天作之合。这套技术栈的核心优势在于，它将自然语言的灵活性与机器执行的精确性高效地结合起来，能够切实地自动化开发者日常工作流中的高频、重复性任务。
\n", "image": "https://p1.meituan.net/meituantechblog/87906241cb91f78131420c9f1b68aea369794.png", "date_modified": "2026-05-19T10:28:27.000Z", "authors": [ { "name": "liqi18@meituan.com" } ], "tags": [] } ] }