包含关键字 typecho 的文章

时光奔流,我们即将与 2025 年挥手作别。感谢这一路上,每一位伙伴的并肩前行与坚定支持。

今年,美团技术团队在持续深耕中涌现出不少值得分享的实践与开源产品&服务。我们从中精选了18篇具有代表性的技术文章,内容涵盖大模型开源、研发技能、产品服务三大方向。值得一提的是,美团 LongCat 团队今年在大模型开源领域成果显著,陆续发布了涵盖基座模型、图像、视频、语音等多个方向的开源产品与工具,期望能够持续推动AI技术分享与生态共建。

希望这些开源的大模型产品、服务及凝结一线技术实战经验的内容,能为大家带来启发和帮助,陪伴同学们在技术前行的道路上扎实成长。愿我们在新年里,继续向下扎根、向上生长,迎着光,奔赴更高、更远的山海。2026,期待继续同行!

大模型开源

01 | 美团正式发布并开源 LongCat-Flash-Chat,动态计算开启高效 AI 时代

9月初,美团正式发布并开源 LongCat-Flash-Chat。LongCat-Flash 采用创新性混合专家模型(Mixture-of-Experts, MoE)架构,总参数 560 B,激活参数 18.6B~31.3B(平均 27B),实现了计算效率与性能的双重优化。

根据多项基准测试综合评估,作为一款非思考型基础模型,LongCat-Flash-Chat 在仅激活少量参数的前提下,性能比肩当下领先的主流模型,尤其在智能体任务中具备突出优势。并且,因为面向推理效率的设计和创新,LongCat-Flash-Chat 具有明显更快的推理速度,更适合于耗时较长的复杂智能体应用。

目前,已在 Github、Hugging Face 平台同步开源,同时你也可以访问官网 https://longcat.ai/,与 LongCat-Flash-Chat 开启对话。(阅读全文

开源地址Hugging Face | Github

02 | LongCat-Flash-Thinking 正式发布,更强、更专业,保持极速!

9月,美团 LongCat 团队正式发布全新高效推理模型 LongCat-Flash-Thinking。在保持了 LongCat-Flash-Chat 极致速度的同时,全新发布的 LongCat-Flash-Thinking 更强大、更专业。综合评估显示,LongCat-Flash-Thinking 在逻辑、数学、代码、智能体等多个领域的推理任务中,达到了全球开源模型的先进水平。

同时,LongCat-Flash-Thinking 不仅增强了智能体自主调用工具的能力,还扩展了形式化定理证明能力,成为国内首个同时具备「深度思考+工具调用」与「非形式化+形式化」推理能力相结合的大语言模型。我们发现,尤其在超高复杂度的任务(如数学、代码、智能体任务)处理上, LongCat-Flash-Thinking 具备更显著的优势。目前, 该模型已在HuggingFace、Github全面开源。(阅读全文

开源地址Hugging Face | Github

03 | LongCat-Video 视频生成模型正式发布,探索世界模型的第一步

要让人工智能真正理解、预测甚至重构真实世界,“世界模型”(World Model)已成为通往下一代智能的核心引擎。作为能够建模物理规律、时空演化与场景逻辑的智能系统,世界模型赋予AI“看见”世界运行本质的能力。而视频生成模型有望成为构建世界模型的关键路径——通过视频生成任务压缩几何、语义、物理等多种形式的知识,AI得以在数字空间中模拟、推演乃至预演真实世界的运行。

基于这一关键目标,10月,美团 LongCat 团队正式发布 LongCat-Video 视频生成模型 —— 不仅以统一模型在文生、图生视频基础任务上达到开源先进水平,更依托原生视频续写任务预训练,实现分钟级长视频连贯生成,从根源上保障跨帧时序一致性与物理运动合理性,尤其在长视频生成领域具备显著优势。

作为一款视频生成模型,LongCat-Video 凭借其精准重构真实世界运行状态的能力,正在成为美团探索世界模型的第一步,也是关键的一步。同时,这也为后续支撑更多自动驾驶、具身智能等深度交互业务场景,夯实了技术基础。(阅读全文

开源地址GitHub | Hugging Face | Project Page

04 | LongCat-Flash-Omni 正式发布并开源:开启全模态实时交互时代

11月,LongCat-Flash-Omni 正式发布并开源。LongCat-Flash-Omni 以 LongCat-Flash 系列的高效架构设计为基础( Shortcut-Connected MoE,含零计算专家),同时创新性集成了高效多模态感知模块与语音重建模块。即便在总参数 5600 亿(激活参数 270 亿)的庞大参数规模下,仍实现了低延迟的实时音视频交互能力,为开发者的多模态应用场景提供了更高效的技术选择。

综合评估结果表明,LongCat-Flash-Omni 在全模态基准测试中达到开源先进水平,同时在文本、图像、视频理解及语音感知与生成等关键单模态任务中,均展现出极强的竞争力。LongCat-Flash-Omni 是业界首个实现 “全模态覆盖、端到端架构、大参数量高效推理” 于一体的开源大语言模型,首次在开源范畴内实现了全模态能力对闭源模型的对标,并凭借创新的架构设计与工程优化,让大参数模型在多模态任务中也能实现毫秒级响应,解决了行业内推理延迟的痛点。模型已同步开源,欢迎体验。(阅读全文

开源地址Hugging Face | Github

05 | 美团开源 LongCat-Audio-Codec,高效语音编解码器助力实时交互落地

语音大语言模型(Speech LLM)想落地,绕不开一个死结:既要快速理解语音里的语义,又要说出自然的音色,还得实时响应。比如智能音箱 “听不懂” 语音,车载助手 “说” 得像机器人,实时翻译延迟卡半秒。深究根源,全在 “语音 Token 化”:作为拆分语音为 Speech LLM “离散单元” 的关键步骤,传统方案始终没平衡好 —— 要么缺语义、要么丢声学、要么延迟高,刚好卡了 Speech LLM 落地的 “死结”。

针对 Speech LLM 落地中的音频处理难题,11月,美团 LongCat 团队正式开源专用语音编解码方案 LongCat-Audio-Codec。它提供了一套一站式的 Token 生成器(Tokenizer)与 Token 还原器(DeTokenizer)工具链,其核心功能是将原始音频信号映射为语义与声学并行的 token 序列,实现高效离散化,再通过解码模块重构高质量音频,为 Speech LLM 提供从信号输入到输出的全链路音频处理支持。通过创新的架构设计与训练策略,LongCat-Audio-Codec 在语义建模、声学重建、流式合成三大维度实现突破。(阅读全文

开源地址Github | Hugging Face

06 | 美团发布 LongCat-Image 图像生成模型,编辑能力登顶开源SOTA

12月初,美团发布 LongCat-Image 图像生成模型。当前 AI 图像生成技术需求旺盛,但行业陷入 “两难困境”:闭源大模型性能强劲但无法自行部署或二次定制开发,开源方案普遍存在轻量化与模型性能难以兼顾、面向商用专项能力不足的痛点,制约商业创作与技术普惠。

为此,美团 LongCat 团队正式发布并开源 LongCat-Image 模型,通过高性能模型架构设计、系统性的训练策略和数据工程,以 6B 参数规模,成功在文生图和图像编辑的核心能力维度上逼近更大尺寸模型效果,为开发者社区与产业界提供了 “高性能、低门槛、全开放” 的全新选择。(阅读全文

开源地址Hugging Face | GitHub

07 | 美团 LongCat-Video-Avatar 发布,实现开源SOTA级拟真表现

今年 8 月,美团开源的 InfiniteTalk 项目凭借无限长度生成能力与精准的唇形、头部、表情及姿态同步表现,迅速成为语音驱动虚拟人领域的主流工具,吸引全球数十万名开发者的使用。10月底,LongCat 团队开源了 LongCat-Video 视频生成模型,尤其在长视频生成领域具备显著优势。

在 InfiniteTalk 和 LongCat-Video 基座的良好基础上,LongCat 团队针对实际场景中的核心痛点持续优化,12月正式发布并开源 SOTA 级虚拟人视频生成模型 —— LongCat-Video-Avatar。

该模型基于 LongCat-Video 基座打造,延续 “一个模型支持多任务” 的核心设计,原生支持 Audio-Text-to-Video(AT2V)、Audio-Text-Image-to-Video(ATI2V)及视频续写等核心功能,同时在底层架构上全面升级,实现动作拟真度、长视频稳定性与身份一致性三大维度的显著突破,为开发者提供更稳定、高效、实用的创作解决方案。(阅读全文

开源地址GitHub | Hugging Face | Project

研发技能

08 | MTGR:美团外卖生成式推荐Scaling Law落地实践

美团外卖推荐算法团队基于HSTU提出了MTGR框架以探索推荐系统中Scaling Law。MTGR对齐传统模型特征体系,并对多条序列利用Transformer架构进行统一建模。通过极致的性能优化,样本前向推理FLOPs提升65倍,推理成本降低12%,训练成本持平。MTGR离在线均取得近2年迭代最大收益,且于2025年4月底在外卖推荐场景全量。本文系相关工作的实践与经验总结,希望能给从事相关方向研究的同学带来一些帮助。(阅读全文

09 | JDK高版本特性总结与ZGC实践

美团信息安全技术团队核心服务升级JDK 17后,性能与稳定性大幅提升,机器成本降低了10%。高版本JDK与ZGC技术令人惊艳,且Java AI SDK最低支持JDK 17。本文总结了JDK 17的主要特性,然后重点分享了JDK 17+ZGC在安全领域的一些实践,希望能对大家有所帮助或启发。(阅读全文

10 | 鸿蒙应用签名实操及机制探究

华为鸿蒙单框架操作系统HarmonyOS NEXT已于2024年10月23日正式发布Release版。HarmonyOSNEXT仅支持鸿蒙原生应用,不再兼容安卓。本文对鸿蒙公开资料进行了深入分析和解读,梳理了鸿蒙单框架应用的签名机制,拆解每一步的实操过程和背后的实现原理,并对源码分析整理签名的校验机制。从中管中窥豹,探究鸿蒙系统的安全设计思路,给从事鸿蒙研发的同学提供一些借鉴。(阅读全文

11 | 预测技术在美团弹性伸缩场景的探索与应用

管理企业大规模服务的弹性伸缩场景中,往往会面临着两个挑战:第一个挑战是精准的负载预测,由于应用实例的启动需要一定预热时间,被动响应式伸缩会在一段时间内影响服务质量;第二个挑战是高效的资源分配,即在保障服务质量的同时控制资源成本。为了解决这些挑战,美团与中国人民大学信息学院柴云鹏教授团队展开了“预测技术在弹性伸缩场景的应用”科研合作,相关论文《PASS: Predictive Auto-Scaling System for Large-scale Enterprise Web Applications》在具有国际影响力的会议The Web Conference 2024(CCF-A类会议)上作为Research Full Paper发表。(阅读全文

12 | 从0到1建设美团数据库容量评估系统

美团数据库团队推出了数据库容量评估系统,旨在解决数据库容量评估与变更风险防控等领域难题。本文介绍了系统架构和主要功能:系统使用线上流量在沙盒环境回放验证变更安全,结合倍速回放技术探测集群性能瓶颈,构建容量运营体系实现集群容量观测与治理闭环。系统具备数据操作安全、结果真实可靠、灵活高效赋能等特点,有效提升数据库稳定性与资源利用率。(阅读全文

13 | AI Coding与单元测试的协同进化:从验证到驱动

AI生成代码质量难以把控!本文分享来自美团的技术实践,三大策略破解AI编程痛点。单测快速验证逻辑正确性,安全网保护存量代码演进,TDD模式精准传递需求。告别「看起来没问题」的错觉,构建AI时代的代码质量保障体系。(阅读全文

14 | LongCat-Flash:如何使用SGLang部署美团Agentic模型

SGLang 团队是业界专注于大模型推理系统优化的技术团队,提供并维护大模型推理的开源框架SGLang。近期,美团M17团队与SGLang团队一起合作,共同实现了LongCat-Flash模型在SGLang上的优化,并产出了一篇技术博客《LongCat-Flash: Deploying Meituan’s Agentic Model with SGLang》,文章发表后,得到了很多技术同学的认可,因此我们将原文翻译出来,并添加了一些背景知识,希望更多同学能够从LongCat-Flash的系统优化中获益。(阅读全文

15 | 可信实验白皮书系列:从0到1的方法论与实践指南

增长与优化是企业永恒的主题。面对未知的策略价值,数据驱动的AB实验已经成为互联网企业在策略验证、产品迭代、算法优化、风险控制等方向必备的工具。越来越多的岗位,如数据科学家、算法工程师、产品经理以及运营人员等,要求候选人了解AB实验相关知识。然而,许多从业者由于缺乏有效的学习渠道,对AB实验的理解仍停留在初级阶段,甚至存在一些误解。我们希望通过系统性地分享和交流AB实验的理论基础、基本流程、核心要素及其应用优势,能够帮助更多相关人员深入了解实验,提升实验文化的普及度,最终辅助企业在更多领域做出精确数据驱动决策。

除了广泛传播实验文化外,该白皮书在深度上也可给实验研究人员,提供复杂业务制约下进行可信实验设计与科学分析评估的参考经验和启发。从美团履约技术团队、美团外卖业务的实践来看,实验者常常面临多种复杂的实验制约和难题,例如,在美团履约业务中,实验往往需要应对小样本、溢出效应(即实验单元间互相干扰)以及避免引发公平性风险等多重约束,需设计科学复杂的实验方案以克服相应挑战。通过撰写白皮书,我们系统性地总结和分享应对复杂实验约束的研究经验,进而能够促进实验技术的传播与升级,推动实验科学持续进步。

本白皮书以AB实验为中心,涵盖AB实验概述与价值、实验方法基础原理与案例剖析以及配套SDK代码分析等,内容丰富且易于理解和应用。适合从事AB实验研究的数据科学家、系统开发人员,以及需要实验驱动策略决策的业务和产研团队,同时也适合对数据驱动增长和数据科学等领域感兴趣的读者。(阅读全文

产品服务

16 | 无需代码!美团 NoCode 像聊天一样轻松搭建你的专属网站

这是一款由美团技术团队打造的 AI 编程类产品——NoCode,可以像聊天一样轻松搭建你的专属网站、游戏、各种小工具等等,当然还有更多的隐藏功能等你发现,文末我们还准备了2项互动奖励,期待跟大家一起,开启全新的 AI 编程之旅。(阅读全文

17 | 美团首款 AI IDE 产品 CatPaw 开启公测

Meituan CatPaw (以下统一使用“CatPaw”)是美团推出的 AI IDE,以 Agent & 人协作为核心,通过 Agent 智能驱动编程,辅以代码补全、项目预览调试等功能,结合美团自研的基于编程场景特训的 LongCat 模型,并支持多种模型混合调用,让编码过程更专注,项目交付更高效!

CatPaw 早在 2023 年就在美团内部以编辑器插件形态正式上线,此次完成全新升级后进行公开测试。目前在美团内部研发渗透率超 95%,增量代码 AI 生成率超 50%。(阅读全文

18 | 美团 LongCat 上线 AI 生图!精准高效,AI 创作不设限

美团 LongCat 全新上线 AI 生图功能,该功能基于LongCat系列模型「LongCat-Image」打造而成。不仅在文生图任务中实现了“快、真、准” :出图快速响应、达到摄影棚拍摄质感、中文渲染精准度高;更在图像编辑任务上做到了精准便捷,无需复杂指令,可以用自然语言对图像进行二次编辑。

无论是追求高效出图的普通用户,还是需要精准落地创意的专业创作者,LongCat 都以 “轻量化模型 + 流畅体验” ,让 AI 生图真正成为人人可用的创作工具。目前,AI 生图功能已在LongCat APP和 https://longcat.ai/ 同步上线,轻松解锁高效创作新方式。(阅读全文

AAAI 是人工智能领域顶级的国际学术会议,本文精选了美团技术团队被收录的 8 篇学术论文(附下载链接),覆盖大模型推理、 退火策略、过程奖励模型、强化学习、视觉文本渲染等多个技术领域,希望这些论文能对大家有所帮助或启发。

01 Promoting Efficient Reasoning with Verifiable Stepwise Reward

论文类型:Poster

论文下载PDF

论文简介:大推理模型通过强化学习提升了链式推理能力,但输出冗长,导致推理开销增大和用户体验下降,即「过度思考」问题。针对这一现象,本文提出了可验证的过程奖励机制(VSRM),通过奖励有效步骤、惩戒无效步骤,优化模型推理过程。VSRM 首先通过特殊 token 划分推理步骤,并结合三条规则保证每个步骤的内容可读性。各步骤通过插入 token 生成子轨迹,模型根据每步前后正确率变化分配步骤级奖励。为避免奖励信号稀疏,引入前瞻窗口机制,通过折扣因子传播未来正确率变化,使奖励更密集。

实验表明,VSRM 能大幅缩减输出长度,且在多种数学 benchmark 和不同模型、算法下保持甚至提升性能。消融实验证明前瞻窗口机制有效,显式长度惩罚对 VSRM 无益。VSRM 机制可与各类强化学习算法无缝结合,有效抑制无效步骤,鼓励有效推理,是解决过度思考问题、提升模型推理效率的有效方法。

02 Scaling and Transferability of Annealing Strategies in Large Language Model Training

论文类型:Long Paper

论文下载PDF

论文简介:本文深入研究了大型语言模型训练过程中退火策略(Annealing Strategies)对模型性能的影响,提出了一个新的缩放法则公式来预测不同训练配置下的损失曲线。研究发现,即使在相同的训练 token 数量和模型规模下,不同的批次大小(batch size)和学习率调度器也会导致显著不同的训练曲线。为此,作者提出了一个改进的缩放法则公式:

其中 S 表示学习率对训练步数的积分(前向效应),M 表示动量对训练步数的积分(退火动量项),N 代表模型规模。

论文的核心贡献包括:(1) 证明在特定情况下,训练步数比训练 token 数更适合作为追踪损失曲线的指标;(2) 发现最优退火比率(Ropt)随总训练步数增加而减小,遵循幂律关系;(3) 验证了最优退火比率在训练集和验证集上保持一致;(4) 通过在 Dense 模型和 MoE(Mixture-of-Experts)模型上的大量实验,证明小模型可以作为优化大模型训练动态的可靠代理。该研究为大规模语言模型的训练提供了更精确的理论指导,有助于优化训练效率和模型性能。

03 From Mathematical Reasoning to Code: Generalization of Process Reward Models in Test-Time Scaling

论文类型:Long Paper (Oral)

论文下载PDF

论文简介:本文系统研究了过程奖励模型(Process Reward Models, PRMs)在提升大型语言模型推理能力方面的作用,特别关注其从数学推理到代码生成任务的跨域泛化能力。研究从训练方法、可扩展性和泛化能力等多个维度对 PRMs 进行了深入分析。

论文的核心发现包括:
- 训练计算资源的影响:研究发现随着 PRM 模型规模的增大,性能提升呈现边际递减效应,强调了在模型规模和计算成本之间寻找平衡的重要性。同时,训练数据集的多样性显著影响 PRM 性能,作者提出的 ASLAF(自动步骤级标注与过滤)方法在多个基准测试中表现优异。
- 测试时扩展策略:论文评估了 Best-of-N 采样、束搜索、蒙特卡洛树搜索(MCTS)和多数投票等多种搜索策略。结果表明,在计算资源充足时 MCTS 效果最佳,而在资源受限情况下 Best-of-N 采样是实用的替代方案。
- 跨域泛化能力:令人惊讶的是,在数学数据集上训练的 PRMs 在代码生成任务上的表现与专门针对代码训练的模型相当,展现出强大的跨域适应能力。通过梯度分析,研究还发现 PRMs 倾向于选择具有相似底层推理模式的响应,这为理解其优化机制提供了新视角。该研究为优化大规模语言模型的训练和部署提供了重要的理论指导和实践参考。

04 Rethinking the Sampling Criteria in Reinforcement Learning for LLM Reasoning: A Competence-Difficulty Alignment Perspective

论文类型:Poster

论文下载PDF

论文简介:本文对强化学习(RL)中的问题采样策略进行了系统性研究,当前主流采样策略大多直接依赖单步通过率(Pass Rate) 作为问题难度指标,存在 1)对问题难度的估计不够稳定;2)无法有效捕捉模型能力与问题难度的对齐关系的问题。

针对这些问题,本文提出了 CDAS(Competence-Difficulty Alignment Sampling):一种将模型能力与问题难度显式建模并对齐的动态采样方法。CDAS 不依赖单步通过率,而是通过累积历史表现差异来构建更稳定的难度估计;同时定义模型能力,并以不动点系统确保两者在训练过程中共同收敛。基于能力—难度差值构建对齐指标,再通过对称采样策略,选取最匹配模型当前能力的问题,从而提升有效梯度比例与训练效率。CDAS 在数学推理和代码生成场景中均通过 RL 训练 验证,结果显示 CDAS 显著提升了采样效率与模型性能,击败了多种主流采样策略。

05 ViType: High-Fidelity Visual Text Rendering via Glyph-Aware Multimodal Diffusion

论文类型:Oral

论文下载PDF

论文简介:随着文生图模型在电商营销等领域的广泛应用,视觉文本渲染的准确性已成为制约生成质量的核心瓶颈。现有模型因缺乏字形级理解能力,难以精确刻画多语言字符结构,导致海报、商品图等商业场景中文字乱码、字形失真等问题频发,严重阻碍了 AIGC 在智能设计中的实际落地。

针对这一关键挑战,我们提出 ViType 三阶段对齐增强框架:首先通过视觉问答机制实现文本-字形显式对齐,将字符视觉结构注入大语言模型语义空间;其次创新性地将预对齐字形嵌入与文本 token 同步输入多模态扩散 Transformer,通过联合训练建立跨模态特征协同;最后基于高质量图文对进行美学精调,确保生成图像的版式和谐与视觉美感。该框架使字符准确率提升 15%以上,为电商海报、营销物料等高精度视觉内容创作提供了可靠的技术支撑。

06 DSCF: Dual-Source Counterfactual Fusion for High-Dimensional Combinatorial Interventions

论文类型:Poster

论文下载PDF

论文简介:在个性化推荐、数字营销和医疗健康等领域,基于观测数据预测反事实结果对科学决策至关重要。在这些应用场景中,决策过程往往涉及高维组合干预策略,例如多渠道资源捆绑投放或产品组合推荐。面向这类场景,无论是历史策略的效果评估还是新策略的优化,都需要模型能够对历史数据中很少出现甚至从未出现过的策略组合效果进行准确预测。此外,观测数据中源于历史分配策略和倾向性投放的选择偏差会进一步加剧数据稀疏问题,从而影响反事实推断的准确性。

为此,本文提出双源反事实融合模型(Dual-Source Counterfactual Fusion,DSCF),该可扩展框架通过双专家混合架构联合建模观测数据和代理反事实样本,并采用领域引导融合机制,在有效平衡偏差消除与信息多样性的同时,还能自适应地泛化到反事实输入场景。在合成和半合成数据集上的大量实验表明,DSCF 框架能够显著提升高维组合干预场景下的预测准确性,并在不同情境下展现出优异的鲁棒性表现。

07 Compress-then-Rank: Faster and Better Listwise Reranking with Large Language Models via Ranking-Aware Passage Compression

论文类型:Poster

论文下载PDF

论文简介:基于大型语言模型(LLMs)的列表重排序(listwise reranking)已经成为最先进的方法,在段落重排序任务中不断创下新的性能基准。然而,其实际应用面临两个关键挑战:处理长序列时高昂的计算开销和高延迟,以及由于“迷失在中间”等现象导致的长上下文性能下降。

为了解决这些问题,我们提出了一种高效的框架压缩后排序(Compress-then-Rank, C2R),该框架不是直接对原始段落进行列表重排序,而是对其紧凑的多向量代理进行操作。这些代理可以预先计算并缓存,适用于语料库中的所有段落。C2R 的有效性依赖于三项关键创新。首先,压缩模型通过结合文本恢复和文本延续目标进行预训练,生成高保真的压缩向量序列,从而减轻了单向量方法中常见的语义损失问题。其次,一种新颖的输入方案将每个序数索引的嵌入添加到其对应的压缩向量序列前,这不仅划定了段落边界,还引导重排序 LLM 生成排序列表。最后,压缩模型和重排序模型通过联合优化,使压缩过程对排序目标具有排序感知能力。在主要重排序基准上的广泛实验表明,C2R 在提供显著加速的同时,能够实现与全文重排序方法相当甚至更优的排序性能。

08 Multi-Aspect Cross-modal Quantization for Generative Recommendation

论文类型:Oral

论文下载PDF

论文简介:本文提出一种基于多模态融合的生成式推荐框架(MACRec),旨在解决现有生成式推荐方法因模态信息利用不足和跨模态交互缺失导致的性能瓶颈。

针对文本与视觉模态的量化难题,MACRec 引入跨模态量化与多角度对齐机制,通过两阶段技术路线实现优化:1)跨模态残差量化:将对比学习融入分层量化过程,生成兼具语义层次性与模态兼容性的物品标识符,显著降低多模态表征冲突;2)跨模态协同对齐:通过显式-隐式协同对齐策略,分别建模文本与视觉模态的共享特征和互补特征,增强生成式推荐的多模态理解能力。在亚马逊电商推荐数据集上的实验结果表明,MACRec 相较基准模型在推荐性能上有显著提升;各模态的码本分布更均衡、利用率更低,充分验证了跨模态量化与对齐机制在提升生成式推荐有效性方面的优势。

1 背景

近来,随着 App 的功能愈发复杂,UI(用户界面)的交互逻辑也随之多样化。为了保障用户体验,针对 UI 的功能测试一直是质量保障中的重要环节。传统的 UI 功能测试往往依赖于人工编写的测试脚本或规则体系:通过手动编写校验逻辑来验证交互是否正确。这种方式虽然精确,但成本高昂,维护困难。

对美团而言, 一个 App 就有可能包含上千种 UI 界面、数万个交互操作。随着业务快速迭代、界面频繁调整、底层平台(如 Android、iOS、HarmonyOS NEXT)的更新,基于规则的测试脚本常常失效。每当脚本失效,测试工程师都需要花费大量时间重新绑定元素、修复规则脚本,极大地提升了测试自动化的开销。此外,当下的 UI 功能缺陷通常并不表现为崩溃,而是更复杂的响应逻辑异常:例如图 1 中点击“全部已读”却清空了消息列表等。这类问题严重影响用户体验,但难以通过简单规则概括,限制了传统 UI 测试自动化的覆盖率与效率。

图 1 - UI 功能响应异常示例

考虑到 UI 功能缺陷虽表现各异,但共性是 App 的响应偏离用户预期。因此,若能实现对用户预期的模拟,就能以此作为测试准则(Oracle)、自动化的检测 UI 功能性异常。即无需人工逐页面编写规则,从而大幅提升自动化的程度与测试覆盖率。由于大语言模型(LLM)经过海量通用知识训练,具备一定的模拟人类常识与预期的能力,恰好契合模拟用户预期的需求,且无需针对特定应用 / 功能单独适配,天然具备泛化性。因此,通过分析 UI 功能缺陷的共性,我们提出了一个全新的思路:能否基于大模型理解“人类对 UI 交互的常识预期”,并以此自动判断交互是否正确?

基于这一理念,我们与复旦大学计算与智能创新学院 周扬帆教授团队 展开联合研究,设计并实现了 KuiTest —— 一套基于 大众通识无规则(Rule-free)UI 功能测试系统。KuiTest 能够像人一样,理解按钮、图标等交互组件的含义,预测点击后的合理结果,并据此自动校验实际界面反馈是否符合预期,从而在无需手工脚本的情况下完成功能测试。该工作已在美团 App 的多个业务中落地应用,并产出论文《KuiTest: Leveraging Knowledge in the Wild as GUI Testing Oracle for Mobile Apps》,已被国际顶级软件工程会议 ICSE 2025(CCF-A 类会议)的 Software In Practice Track(软件工程应用实践)收录。

2. 设计思路与实现过程

2.1 总体流程

KuiTest 的核心是检查 UI 交互后的响应是否符合一般用户的 常识性预期,其中:识别交互组件的功能和常识性预期生成是需要两项关键能力。考虑到通用大模型具备图文理解能力且从海量的训练数据中习得了常识性推理能力,因此天然地适合模拟大众的认知和交互预期。至此,KuiTest 的核心挑战是提升大模型在执行 UI 功能测试的 性能和可靠性。考虑到通用大模型通常并未接受过 UI 测试领域数据的训练,因此缺少 UI 认知与测试的经验,直接让它识别 UI 功能和缺陷是十分困难的。所以我们借鉴人工测试的操作流程,将测试流程拆分以降低 LLM 的任务难度:

  • 可交互组件功能识别:理解每个可交互组件(如按钮、图标)的功能含义、预测交互后的响应。
  • 交互响应验证:在执行交互后,验证界面响应是否符合预期。

图 2 - KuiTest 工作原理

具体来说,如上图 2 所示,在测试开始时,首先选择需要交互的组件,KuiTest 会基于 GUI 截图分析和组件库匹配获取该组件的功能,并预测与之交互后的 UI 响应;随后执行交互,根据组件的预期功能以及交互后的页面信息判断实际响应是否符合预期。

2.2 UI 组件功能识别

图 3 - 可交互组件功能识别与 UI 响应预测

为了提升大模型预测 UI 组件功能的可靠性,KuiTest 整合了多种 UI 页面相关信息输入:首先,我们获取结构化组件树并结合 Vision-UI 模型[1]从截图中识别所有可交互组件,再用 SoM(Set-of-Mark)策略[2]为每个组件添加 bounding box 标记并分配唯一 ID,形成带标记的 UI 截图,让大模型能快速分辨图中存在的 UI 组件。接着,针对有文本的组件,通过 OCR 提取文字内容并按“组件 ID - 文本”结构化整理;针对无文本的图标类组件,则利用 CLIP(Contrastive Language–Image Pre-training)模型[3]从积累的图标库(含历史识别失败图标及人工标注的功能描述)中检索相似图标,如果存在相似图标,则将库中图标的功能信息补充至输入来辅助大模型理解组件。最后,将上述所有信息整合进 Prompt,让大模型识别指定组件的功能,并预测交互后 UI 界面的响应。这一过程有效缓解了通用多模态大模型 UI 视觉信息理解薄弱的瓶颈,并为后续交互验证提供 Oracle。

2.3 交互响应验证

图 4 - 交互响应结果验证过程与 Prompt

交互后响应验证是 KuiTest 判断 UI 功能是否存在 Bug 的核心环节,流程分为状态比对和 LLM 决策两步:KuiTest 在模拟用户交互后,先通过像素对比判断交互前后 UI 是否有视觉变化,若无变化则直接标记为 “UI 交互无响应”;若有变化,则让多模态模型判断实际 UI 响应是否符合前述预测。至此,KuiTest 完成了从 UI 功能语义测试到通用推理能力任务的转换,既规避了传统基于规则测试繁杂的开发和维护成本,也提升了大模型在 UI 测试领域的决策的可靠性,降低误报率。

3. 实验测试

KuiTest 的实验设计以验证其对解决工业级 UI 功能的测试能力为核心,在美团实际场景中筛选真实数据构造数据集,并且设计针对性基线对比方案。在验证技术有效性的同时为业务落地提供数据支撑,下文将继续介绍实验设计、设置以及结果分析。

3.1 实验设计

实验围绕三个关键问题(RQ)进行,目标是验证 KuiTest 设计的有效性与合理性,以及是否满足工业落地要求。针对 LLM 在 UI 理解领域能力不足的问题,设置 RQ1 从误报率和成本的角度验证任务分解(拆分为 “组件功能识别 + 交互后响应验证”)的综合性能。此外,设置 RQ2 评估多模态输入 + 图标库的方案是否能提高 LLM 的组件识别能力。最后,针对工业场景对 “高召回、低误报” 的刚需,设置 RQ3 验证 KuiTest 在美团 App 中的落地能力,重点评估决定缺陷覆盖度的召回率以及直接影响人工排查成本的误报率。

3.2 实验数据与对照方法

实验使用的基准数据集自美团的核心业务线(外卖、酒店、旅行等),这些业务线的 UI 风格、交互规则均有差异,因此具备对真实的工业测试场景的代表性。具体而言,RQ1 数据集含 150 个 UI 交互操作(25 个历史 Bug+125 个正常用例),bug 比例 16.7%,对应新功能测试场景;RQ2 数据集涵盖 250 个可交互 UI 组件(含文本与无文本类型),确保组件多样性;RQ3 数据集含 100 个真实 UI 页面(4664 个组件、150 个注入 Bug),Bug 占比仅 3.2%,与工业场景 Bug 稀疏的实际情况一致。

图 5 - 任务分解的示意与基线方法

我们为各实验设置了基线方法作为对照:RQ1 设无分解(直接让大模型判断)与三步分解(单独提取交互后页面语义)对照,前者验证是否需要分解,后者验证分解步数合理性;RQ2 设纯 LLM(仅截图)、图片 + 文本(无图标库)、SoM + 文本(无图标库)对照,分别验证文本信息、组件标记以及图标库的价值,排除单一变量干扰;RQ3 虽无外部工具对照,但通过覆盖美团内 10 种业务线,以验证 KuiTest 的现实泛化性。

3.3 实验结果

RQ1:任务分解的合理性

任务分解对比结果显示,有分解的方案比无分解的方案在准确率和召回率上都有明显提高,并且 KuiTest 的两步分解方案(组件识别 + 响应验证)表现最优:平均准确率 86%、召回率 85%。

这一结果印证了任务分解合理性。对于三步分解的方案效果会略差于两步分解的结果,我们分析发现三步分解额外语义提取步骤,虽能提升页面类型理解,但会让 LLM 忽略图标颜色变化等细节,导致非跳转类 UI 功能 Bug 漏检(如点击收藏按钮后按钮应该从空心变为实心),且增加计算成本。这说明分解并非步骤越多越好,需贴合大模型能力边界,找到可靠性和效率平衡点,而两步分解恰好成为实现这一目标的最优解。

RQ2:组件功能识别的有效性

组件功能识别结果显示,KuiTest 方案的平均识别准确率达 95.5%,其中文本组件准确率 96%,无文本图标准确率 95%;而对照方案中,纯 LLM 的无文本图标准确率仅 13%,图片 + 文本和 SoM + 文本的方案准确率也未突破 20%。

这一数据表明对 UI 图像进行标记以及对 UI 组件语义信息的额外补充,能够显著提高 LLM 的 UI 组件功能识别能力。LLM 视觉理解能力薄弱,纯截图输入无法识别无文本图标,而 OCR 文本 + 组件标记能补充组件的文本语义,提升文本组件识别准确率。借助图标库为无文本组件补充功能描述,直接将其识别准确率从 13% 提升至 95%。并且这一图标库并不是全量的,说明仅通过业务线常用图标即可覆盖大部分场景,兼顾准确性与成本。

RQ3:对于真实 UI 功能异常识别的有效性

在美团 10 大业务线的真实场景测试中,KuiTest 整体召回率 86%、精确率 71%、误报率 1.2%,且各业务线表现稳定。这些实验结果表明 KuiTest 具备实际落地能力。86% 的召回率意味着能覆盖绝大多数真实 UI 功能 bug,避免漏检关键缺陷。1.2% 的误报率有效避免导致测试工程师进行无效排查,大幅降低人工成本。71% 的精确率虽看似不高,但因实验中 Bug 占比仅 3.2%(与真实场景一致),在 Bug 稀疏环境下已属优秀。实验结果证明了 KuiTest 在真实测试场景中能平衡覆盖度与准确性。

4. 应用效果

目前,KuiTest 已在美团的多类业务场景中落地应用,过去 6 个月有 20 个业务方向使用,总执行 21 万+Cases、8000 多个 Jobs,近期周均触发 5000 多个 Cases;在多个实测项目如鸿蒙适配、神会员地理传参巡检、酒店商家多语言适配等,KuiTest 发现了百余例有效的 UI 功能缺陷。

4.1 HarmonyOS NEXT 平台遍历

传统的 GUI 测试脚本的设计依赖于 App 的 UI 逻辑,但是不同操作系统上同一 App 的有所差异,这种差异会导致在一个系统上设计的脚本在另一个系统上失效,因此使得跨平台的测试十分困难,需要测试人员手动调整甚至重新设计测试脚本,适配成本较大。

美团 App 在 Android/iOS 平台的测试脚本较为完善,但是在 HarmonyOS NEXT 平台的测试脚本仍在完善之中,大量页面仍处于未测试状态。因此,KuiTest 被率先部署于该平台的稳定性巡检中,根据指定业务起始页面,自动地进行跨页面遍历,识别并验证崩溃、报错、功能不符合预期的情况,以减少重新设计测试脚本的成本。

项目中覆盖首批适配的 3 项业务,项目交付周期总体累计运行 1230 小时、共 4 万+个自动化测试用例,发现 34 个有效异常

图 6 - 发现的缺陷举例

4.2 大前端回归巡检

由于美团 App 的更新速度十分快速,因此每周都需要进行回归巡检。传统的测试脚本的方法由于人力消耗过大,往往只能覆盖 App 中的核心业务区域,但是其他区域的 Bug 实际也会影响用户体验。而 KuiTest 能够测试一张页面的所有可交互组件,以一种低成本的方式提高测试覆盖率。因此,我们将 KuiTest 运用在美团的大前端回归巡检当中:截至目前,KuiTest 已经超一年稳定运行,累计检测出了 140+有效异常。

5. 认知与展望

KuiTest 作为无规则的移动应用 GUI 功能测试工具,标志着软件测试领域向智能化、自动化方向迈出的探索一步。该工具通过合理的任务拆解与多模态 UI 组件功能识别将大模型通识作为测试预言,利用其广泛的知识模拟用户期望,成功突破了传统基于规则测试方法的局限性,切实提升了 LLM 在 GUI 测试场景中的可靠性和实用性。

当前 KuiTest 主要聚焦于单步交互的功能验证,这是出于对测试可靠性和效率的权衡考虑。然而,向多步交互场景扩展是一个自然且必要的发展趋势,真实用户场景中存在大量需要多步操作才能触发的复杂功能 bug,例如,在执行操作序列“查看订单列表 → 点击 “待付款” 订单 → 选择退款 → 确认退款原因”时发现点击“待付款”后,页面却显示“退款订单”。

未来研究应当探索如何将测试能力扩展到长链路交互场景。针对长链路 Bug 分析,需要建立状态追踪机制来记录每一步交互后的 UI 状态变化,通过对比预期状态与实际状态的差异来识别异常节点,同时利用 LLM 的推理能力建立操作步骤之间的因果关系链,当检测到功能异常时能够回溯定位是哪一步操作导致了错误,这种因果推断能力对于复杂交互序列中的 Bug 定位至关重要。同时,可以引入基于历史 Bug 数据的学习机制, 分析过往发现的长链路 Bug 模式,自动生成类似的高风险测试路径,优先探索容易出现问题的操作序列组合。这种智能化的路径生成不仅能提高测试效率,还能显著提升对复杂功能 Bug 的检测能力。

6. 合作方简介

复旦大学周扬帆教授团队致力于新型软件系统的性能优化与故障排查研究,近年团队在软件系统领域的重要会议如 OSDI、SOSP、ICSE、FSE 等发表了多篇高影响力论文。最近,该团队以解决 UI 自动化测试中的复杂问题为核心,将大模型应用于 UI 功能认知与 UI 交互规划,以一系列创新方法显著提高了解决方案的适应性和稳定性。团队注重科研成果的实际应用,积极与企业及相关机构合作,共建实用工具和系统,推动研究成果的落地,助力合作伙伴提升技术能力并实现业务价值。

注释

  • [1] vision-ui 模型:美团视觉 UI 分析工具
  • [2] SoM(Set-of-Mark)策略:Yang J, Zhang H, Li F, et al. Set-of-mark prompting unleashes extraordinary visual grounding in gpt-4v [J]. arXiv preprint arXiv: 2310.11441, 2023.
  • [3] CLIP(Contrastive Language–Image Pre-training)模型:Radford A, Kim J W, Hallacy C, et al. Learning transferable visual models from natural language supervision [C]//International conference on machine learning. PMLR, 2021: 8748-8763.

2026 年,AI 真正“下地干活”的第一战,被阿里打响了。

1 月 15 日,在杭州阿里园区举行的千问 App 发布会上,阿里巴巴集团总裁吴嘉做了一次并不复杂、却很直观的演示:他用千问给现场嘉宾点了 40 杯“伯牙绝弦”奶茶。整个过程没有人工介入。千问自行匹配附近奶茶店,下单,并调用支付宝完成支付。没一会儿,淘宝闪购的骑手把奶茶送进会场。发布会的气氛,也在这一刻被彻底点燃。

事后,有杭州的网友恍然大悟“怪不得刚刚西溪附近叫不动外卖!”

image

相比 PPT 上的参数和模型指标,这个场景更容易被理解:AI 第一次在公开场合,完整地替人把一件现实中的事情办成了。

在这次更新中,阿里将千问定位成 “每个人的生活助手”。路径也很明确:不从新场景做起,而是直接接入阿里现有的业务体系,让 AI 先把眼前的事干好。

在 日常生活 层面,千问首批接入了 淘宝闪购、支付宝、淘宝、飞猪和高德 五大业务,可以一句话 点外卖、买东西、订机票、订酒店、查路线,这些原本需要在多个 App 之间来回切换的操作,现在可以交给一句话来完成。

image

在 “办事” 这一层,千问的能力被进一步拉长。它开始尝试处理更复杂的任务,比如打电话订餐厅、整理调研资料、处理财务文件、辅助搭建网站等。这类功能目前仍处于定向邀测阶段,

吴嘉在发布会上表示:“AI 在拥有超强大脑之后,正在长出能够触达真实世界的手和脚,在生活中实实在在地替用户‘干活’。 千问的优势在于‘最强的 Qwen 模型’与‘阿里最完整的商业生态’的结合。AI 办事的时代才刚刚开始,我们会持续探索,把千问打造成真正有用的个人 AI 助手。”

自千问上线两个月以来,月度活跃用户已突破 1 亿。 吴嘉认为,随着 AI coding、全模态理解以及超长上下文等关键能力逐步成熟,AI 正在走出手机屏幕,进入更复杂、也更真实的生产与生活场景。

把阿里折叠进千问中, 通过统一的 AI 入口,让千问拥有 400 余项办事能力,在 生活、办公、教育 等方面全场景覆盖,让千问成为 AI 时代的超级应用入口,这正是阿里的野心。

办事之上如何理解需求,才能判断是不是一个合格的助手

伴随着模型能力的跃迁,思考让 Agent 做事,已经是近几年行业的集体共识。但 干的活好不好,这才是能否放心 AI 当助手的关键。

阿里此次的更新方向,既在意料之中,又有些意料之外的惊喜,这个惊喜的落脚点就在于 对需求的理解

在对千问用户数据观察中,用户主动询问商品推荐的月环比高达 300%,这引起了阿里的注意,利用好千问与淘宝的链接,让千问拥有更可用的商品推荐能力,这确实踩中了不少人的真实需求,也成为千问区别其他通用 Agent 的功能独特切入点。

image

这不仅发挥了阿里在电商上的传统优势,也让庞大的商品供给和相对成熟的推荐体系真正被用起来。用户只需一句话,就能完成从商品推荐到下单的完整流程。其背后,是 阿里各业务接口的打通和协同调用,用起来足够顺,也足够省事。

但更令人惊喜的是 对决策层面的关注,这也是 模型深入理解真实需求的表现,如何调用工具做更好的决策,体现了阿里强大的整合能力。

比如,现场展示了要给老人购买一款家庭扫地机,并且家里还养了一只猫,预算在 2000-4000 左右。千问在综合产品的价格与能力之上,还进一步老人的便捷需求与对猫毛的清洁效果,在综合这些复杂的条件后,给出推荐产品与相关理由,这正是大模型方便人类决策的一个虚拟需求感知。

image

在另一个徒步推荐的方案中,千问不仅推荐出行路线,结合天气情况给出建议,还将徒步需要的产品直接发送到了千问界面上,确实让人看到 AI 未来融入世界的真实摸样。

image

不是只做简单的一件事,而是将好多事做好,形成闭环,阿里已经迈出第一步。

笔者能想到的弊端,可能就是如何避免大模型被商家刷的假好评和广告垃圾数据污染,根据错误数据给出错误推荐。

在一个全家人考虑去三亚出行的案例中,千问综合了路线、预算、老人与孩子的需求等,给出了路线选择,并给出三套酒店方案。

image

不过,酒店的均价都在两三千左右,不少人吐槽这恐怕没人住得起,方案不适用,不接地气,这或许是笔者认为的阿里迈出的是“半步”,还需要进一步的地方。

现场还有一个小惊喜是,千问演示现场定饭店的时候,有一段与老板确定需求的打电话环节,从包间大小,价格,有小朋友等需求进行多方拉扯沟通,直到最后,电话结尾说,“我是千问 AI 助手在与你沟通”,大家才恍然大悟,原来是千问的语音功能在完成订酒店的“最后一公里”。

这正是各种多模态打通后,AI 能做到的程度,留给人更多想象空间。

这种好用,同时体现在在对办公需求上,在更专业的场景上,需要更好的交付结果,要求也更难。

千问可以集成各种复杂工具,完成做表格、整理数据、处理报表、汇报 PPT 等各种具体业务。从如何处理资料到最后成品展现,从效果来看,确实还不错。

image

此次,阿里找来了专业人士来验收干活效果,千万财经博主小 Lin 说,亲自下场演示了用千问生成一份《2026 毕业生就业报告》,从信息汇总,消化资料,角度分析,文章演示到 PPT 的生成,千问干了一个完整的活。

不过,如果把千问当做个工作三年内的大学生,来干这些活,效果还是不错的,如果要求更高,可能就是把控 PPT 的内容重点质量,PPT 的设计是否美观。

image

而在教育领域,千问也做出一些精心设计,令人印象深刻的是在各种题目中,除了思路的讲解,还会生成一段动态视频进行图示演说,能随时对话沟通,给出思路和解法,并且多模态展示,这让千问更像一个人一样解决问题。

image

笔者也亲自进行了一个上手测评,一个是用千问点奶茶,还有一个是用千问询问如何落户问题,千问都给出了较为实用的操作结果。

image

总体来看,千问并没有试图一下子把所有事都做好,而是在尝试把复杂的事做得更完整、更贴近人的真实需求。它距离“完全可靠的 AI 助手”还有距离,但已经明显走出了聊天框,开始进入决策和执行的真实环节。而对干活质量的进一步打磨,恐怕正是阿里下一步要发力的方向。

在几家最受关注的 AI 巨头中,字节跳动 选择从系统层切入,通过豆包手机助手借助操作系统能力,去调度第三方应用,与现实世界建立连接;阿里 的路线则更为直接,依托自身已高度成熟的电商、支付、物流、出行等业务体系,将这些能力整体接入千问,形成一个以自有生态为核心的闭环。腾讯 目前尚未对外展示完整方案,但从近期在 Agent 和多模态方向上的密集招聘来看,其下一步布局大概率仍将围绕微信这一超级入口展开。

image

表面上看,Agent 之争比拼的是模型能力,但更深层的竞争,实际上取决于谁能更稳定、更规模化地承接真实世界的复杂需求。

Anthropic 发布 Claude Cowork 研究预览版没多久,就被曝出了删用户文件、窃取文件等问题。

 

近日,博主 James McAulay 在测试 Cowork 功能中,选择“整理文件夹”这一基础且高频的场景,同时还与 Claude Code 进行对比。当 James 正在对比两款工具的整理进度时,Claude Cowork 突然触发了致命错误:在整理过程中擅自删除了约 11GB 文件。

 

更令人崩溃的是,这些文件并未进入回收站,而是被执行了“rm -rf”不可逆删除命令。James 紧急让 Claude Cowork 导出操作日志,确认该命令的执行记录后,咨询 Claude Code 能否恢复,得到的却是“无法恢复,属于致命操作”的回复。

 

事后复盘发现,James 在 Claude Cowork 询问文件操作权限时,点击了“全部允许”或“始终允许”,但没有预料到它会无视明确的“保留文件”指令,更没想到会执行不可逆删除操作。万幸的是,此次被删除的均为过往上传记录,并非核心重要文件,未造成严重损失,但这一安全隐患足以让用户对其望而却步。

 

James 还指出,Cowork 与 Claude Code 相比,存在两点不足:

 

首先是交互的繁琐性。发出“整理文件夹”的指令后,Claude Cowork 并未直接行动,而是要求先启动新任务并手动选择目标文件夹;Claude Code 则直接定位文件夹并开始分析,仅需授予一次权限即可推进。Claude Cowork 通过反复交互确认整理细节,比如询问“文件按什么维度分类”“用户数据文件夹如何处理”,即便明确回复“用户数据文件夹暂不删除、保留”,它仍在待办清单中标记“删除用户数据文件夹:已完成”,虽后续未实际执行该删除操作,但也暴露了指令响应的漏洞。

 

其次是效率的滞后性。整理过程中,Claude Cowork 运行命令多次停顿,节奏拖沓;而同期用 Claude Code 整理“音乐文件夹”,智能体快速给出“专辑和迷你专辑、单曲、Demo、翻唱”的分类建议,确认后即刻推进整理,全程仅需数十秒。即便两者均搭载 Opus 4.5 模型,Claude Cowork 的响应速度和执行效率仍明显落后,甚至让简单的文件夹整理变成了“持久战”。

 

除此之外,AI 安全公司 PromptArmor 还发现,由于 Claude 代码执行环境中存在已知但未解决的隔离缺陷,Claude Cowork 易受通过间接提示注入实施的文件窃取攻击。

 

据悉,这是一个最早由 Johann Rehberger 在 Cowork 尚未出现之前、于 Claude.ai 聊天环境中发现的漏洞,已经扩展到 Cowork 中。Anthropic 对该漏洞进行了确认,但并未进行修复。

 

Anthropic 提醒用户:“Cowork 是一个研究预览版,由于其 agentic 的特性以及可访问互联网,存在独特风险。”官方建议用户警惕“可能表明存在提示注入的可疑行为”。然而,由于该功能面向的是普通大众而非仅限技术用户,PromptArmor 表示认同 Simon Willison 的观点:“要求普通、非程序员用户去警惕‘可能表明提示注入的可疑行为’,这是不公平的!”

此前,Every 团队提前获得权限,Dan Shipper、Kieran Klaassen 直播测试了该产品并分享了使用体验。期间,Anthropic Claude Cowork 项目核心成员 Felix Rieseberg 参与解读了产品设计思路。Felix 介绍,Cowork 是一个快速上线、先交给大家看怎么应用的产品,只用了 1.5 周就完成了开发,Felix 表示未来将以用户反馈为核心快速迭代。此外,工程师 Boris Cherny 还在 X 上透露,该产品的全部代码都是由 Claude Code 编写的。

 

在直播中,Felix 表示,产品工作流可拆分为 “非确定性(依赖模型智能)” 和 “稳定可重复(编写工具)” 两类,按需取舍。Skills 是平衡 “模型灵活性” 与 “工作流稳定性” 的关键,能沉淀可复用知识,还能催生涌现能力。

 

他认为,未来 Agent 类应用界面会趋简,用统一的 “泛化入口” 覆盖更多场景,而非专用化输入框堆砌。下面是三人对话部分内容,我们进行了翻译,并且在不改变原意基础上进行了删减,以飨读者。

 

一周半冲刺、先上线再说

 

Felix:这是我们团队做的产品。我们在最近大概一周半的时间里全力冲刺,把它做出来了。

 

Dan:一周半?

 

Felix:对,不过我想澄清一下:其实很多人早就有一个共识:如果能有一个“给非程序员用的 Claude Code”,那一定会非常有帮助、也很有价值。我们真正想做的,是帮助人把事情做完,不管是生活里还是公司工作中。

 

在这之前,我们其实已经做过好几个原型,尤其是在圣诞节前。但假期期间我们观察到一件事,我相信很多人也注意到了:越来越多的人开始用 Claude Code 做几乎所有事情,某种程度上,大家是在用它“自动化自己的人生”。

 

于是我们就在想:有没有一个足够小、足够早期的形态,可以先做出来给大家用,然后和用户一起快速迭代,真正搞清楚什么样的用户体验才是对的、我们到底应该构建什么。

 

现在你们看到的这个就是答案。它是一个 research preview,非常早期的 alpha 版本,有很多不完善的地方、很多毛糙的边角,你们已经看到不少了,这些我们都会很快改进。但这就是我们的尝试:在开放状态下构建产品,和外部的人一起打磨。

 

Dan:我太喜欢这种方式了,能不能讲讲你们做的一些设计决策?

 

Felix:这是个很好的问题。我个人有一个判断:不只是 Anthropic,而是整个 Agent 类应用的用户界面,在接下来一两年里都会发生非常大的变化。

 

现在我们看到的,是为不同任务设计的高度专用化输入框,以及围绕特定任务搭出来的一整套脚手架。但随着模型能力不断提升、整个行业对“泛化问题”的理解逐渐加深,我认为未来我们会用更少的界面,覆盖更广的使用场景。

 

但在当下,我们之所以把 Cowork 单独拆出来,是因为我们想非常透明地告诉用户:这是一个“施工中的区域”。某种意义上,我们是在邀请你走进我们的厨房。我们希望能和用户一起工作,几乎每天都上线新功能、修 bug、尝试新想法。所以这个独立的 Tab 本身就是实验性的,可以说是在前沿、甚至是“流血边缘”。它节奏更快、打磨得没那么精致,这也是我们把它单独拎出来的主要原因之一。

 

当然,也有一些技术层面的原因。比如现在这个 Cowork 是运行在你本地电脑上的,所以里面的对话是本地的,不会在多设备之间同步。同时,我们给了 Claude 更激进的一些 Agent 能力。综合这些因素,才决定做成现在这个形态。

 

Dan:同一个应用里,一边是云端的聊天,一边却是在自己电脑上跑的 Agent。怎么让用户真正理解“这两者不一样”?

 

Felix:是的,我心里有一个梦想,我相信很多人也有同样的想法:最终这些其实都不重要,代码到底跑在什么地方,应该只是一个技术实现细节。对用户来说,它应该就跟你访问纽约时报网站时会不会用 WebSocket 一样,谁会在乎呢?

 

对我们来说,现阶段这样做的好处是,可以跑得更快、发布得更快,也能和真正使用这个产品的人更近距离地一起共创。我一直很坚定地认为,一个人关起门来是很难做出好产品的。那种“躲进山洞里干一年,最后拿出来”的方式,其实很难成功。

 

我也经常提醒大家:就连第一代 iPhone,都缺了很多我们现在觉得是“理所当然”的功能。所以,这确实是一个不小的门槛,但我们暂时可以接受,因为我们希望现在选择用这个产品的人,本身就是带着明确意图来的。

 

Dan:我觉得这是一个非常有意思的模式,先极快地把东西做出来,以一个“新入口”的形式放在应用里,让相对更少的人点进来。这样就能在真实世界里快速迭代,而不是一开始就追求完美。尤其是在你刚才说一周半就能做出一个版本,简直疯狂。

 

“现在的状态是,先看看大家怎么用”

 

Kieran:但在你们脑海里,这个产品“真正的形态”是什么样的?你们接下来想往哪里走?

 

Felix:我太喜欢这个问题了,因为说实话,我也想反过来问你们两个同样的问题:你们希望它变成什么?你们想用它做什么?我已经听你们提到过,比如想让它能访问整台电脑,还有多选交互是不是可以更灵活一些之类的。

 

但我现在更多的状态是,先看看大家怎么用,然后疯狂尝试各种可能性。里面肯定有很多是错的,也会有一些是对的。对我来说,真正有意思的不是我个人的愿景,而是用户真正想拿它干什么。

 

我过去做过的产品几乎都是这样:你心里以为用户会这么用,结果他们找到了完全不同的用法,然后你顺着那个方向继续做下去。所以我特别希望我们能搞清楚:人们现在到底想要什么、喜欢什么、不喜欢什么。肯定也会有人明确说不喜欢某些地方,那我们就根据这些反馈不断调整、迭代。

 

Kieran:这又回到一个老问题了。比如 Boris 就非常擅长把 Claude Code 做成一种让用户在使用过程中逐渐发现“自己到底想要什么”的工具。那你们在 Cowork 里有没有类似的策略?比如给我们一些“积木式”的东西?能不能加自己的插件或 Skills?Claude Code 很酷的一个地方在于它特别好 hack、特别可塑,你们面向非程序员的 Cowork 是不是也有类似理念?

 

Felix:对,非常强调可组合性。你刚才提到 Boris 推动 Claude Code 早发布、快迭代、看用户怎么用,其实特别巧,我们之所以能这么快上线,很大程度上也是 Boris 在推动我说,“你应该早点给大家看看,看他们会怎么用”。(注:Boris Cherny 是 Claude Code 核心创作者)

 

至于可组合这一点,过去几周、甚至最近两个月里,我自己感受最深的,是我越来越依赖 Skills。以前我可能会去写 MCP 工具,或者为 Claude 专门做一套很定制化的东西,现在我更多是直接写 Skills。

 

有时候我还是会写一个二进制程序,但我随后就会在一个 Skill 文件里用 Markdown 描述:Claude,如果你要做这件事,请遵循这些规则。

 

举个例子,我最近在给自己做一个马拉松训练计划。我写了一个小程序,从不同平台抓取我的运动数据;然后在一个 Skill 里写清楚:如果你要帮我做训练计划,请按这些原则来。现在,只要你在 Claude AI 里装过的 Skill,都会自动加载到 Cowork 里。而且我觉得这只会越来越重要,尤其是模型越来越聪明,比如 Opus 4.5 版本,对 Skills 的遵循能力真的非常强。

 

所以目前来说,Skills 大概是我们最主要、也最“可 hack”的入口。

 

统一的“泛化入口”趋势

 

Dan:太棒了。你刚才提到未来会有更少的 UI 形态。这是不是也意味着,围绕“聊天是不是 AI 的最终形态”这个争论,你其实是在押注自然语言会长期存在?也就是说,我们最终不会有越来越多复杂的 UI,而是更少的界面,人只需要和一个 Agent,或者一个能调度其他 Agent 的 Agent 对话?你们现在推动的方向,某种程度上是不是就类似今天 Claude Code 所展现出来的那种形态?

 

Felix:是的,这个问题现在仍然存在很大的争论空间,而且肯定不存在什么“Anthropic 官方立场”。老实说,就算是在我这个并不算大的团队里,大家也未必能在整体上达成一致。每个人对于未来人类将如何与 AI、与模型交互,都有非常不同的想象。

 

如果只从我个人的角度来说,我大概坚信两件事。第一是:聊天式输入及其各种变体——不仅仅是模型意义上的聊天,而是更广义的那种“我想要点什么”的输入框——会比我们想象中存在得更久。

 

如果你把它抽象开来看,不管是 Google 首页,还是 Chrome 的地址栏,本质上都是一个“我想要某样东西”的输入框,我认为这种形态会长期存在,我们会继续拥有某种看起来很像搜索框的入口。

 

问题是,我们到底需要多少个这样的输入框?你会有一个专门写代码的框吗?一个用于个人娱乐的、一个处理医疗相关问题的?我并不确定未来会存在这么多彼此割裂的输入框。

 

我再拿 Google 做类比。过去你可能记得,Google 会为不同需求提供不同的搜索入口和子产品。但现在,越来越多时候,你只是直接在 Chrome 的地址栏里输入你想要的东西。你不会真的先想清楚“我现在是在购物模式”,然后再专门去打开 Google Shopping。

 

所以,如果我们未来看不到一种更聪明的、能理解你想做什么的“泛化入口”,我会很意外。当然,后端可能仍然会分流,比如它理解你想要做的是 X,于是给你呈现一个适合 X 的界面,但入口本身很可能是统一的。

 

产品设计中的取舍

 

Dan:我觉得一个很有意思的反例是 Microsoft Excel。某种程度上,它和 AI 的工作方式其实也很像:这是一个通用型产品,上手极其简单,但你可以在里面把事情做到无限复杂。而且,Excel 甚至某种程度上催生了后来的 B2B SaaS 浪潮,很多 SaaS 本质上就是把 Excel 里的复杂工作流“产品化”了。所以也有另一种可能:你先有一个极其通用的工具,然后人们在里面发现了高价值、高强度的工作流,最后这些工作流再被拆分成独立产品。

 

Felix:我觉得 Excel 真的是一个极其漂亮的例子。对很多开发者来说,Excel 其实处在一个有点“边缘化”的位置,但如果你比较一下 Excel 的日活用户数量和全球开发者的数量,那是一个非常惊人的对比。

 

我在 Excel 身上看到的一个很有意思的点是:它的重度用户,其实并不太在意那种“边际效率提升”,或者 UI 上一点点的小优化。他们更在意的是对这个产品的深度熟悉和肌肉记忆。

 

这里面是有教训的。我在很多产品表面上都见过这种情况:作为开发者,你会觉得“如果我单独给你做一个更贴合这个场景的小工具,你的工作流会更好”。但结果往往是,用户并不会去用那个新工具,而是继续在他们已经非常熟悉的产品里,把事情做完。

 

举个例子,这是我在 Slack 工作多年反复学到的一课:你可以做很多你自认为更适合某个使用场景的独立服务,但用户最后往往还是选择就在聊天里完成这件事。

 

Dan:说到这里,虽然今天的主题更偏向非开发者,但我感觉现在有不少开发者在看。你正好是那种“真的把这个东西做出来了”的人,对 Agent native 应用的构建理解非常深。

 

我们一直在思考 Agent-native 应用的核心原则。比如其中一个原则是“对等性(parity)”:用户通过 UI 能做的事情,agent 也应该能做。我在 Cowork 里已经能看到这一点。另一个是“粒度(granularity)”:工具应该尽量处在比功能更底层的层级,而“功能”更多存在于 prompt 或 Skill 中,这样你就能以开发者没预料到的方式去组合工具。这会自然带来第三个原则“可组合性(composability)”,而可组合性最终会产生第四个:涌现能力(emergent capability)。也就是用户开始用它做你完全没想到的事情,你看到了潜在需求,然后再围绕它构建产品。

 

这在我看来,几乎就是 Claude Code 的工作方式。我很好奇,这一套在你听来是否成立?或者从你们在 Anthropic 大规模落地的经验来看,有没有什么能让大家把 Agent native 应用做得更好的建议?

 

Felix:这套说法对我来说非常有共鸣。而且我觉得,“涌现能力”里隐藏着一个非常重要的事实:无论是个人还是在孤立的小团队里,我们几乎不可能提前预测一个 Agent 最终会在哪些地方变得极其有用,尤其是当你只给了它一些相对原始的工具时。

 

把工具尽可能下沉、做成通用形态,是一件非常强大的事情。工具越可组合、越通用,你就越能从模型智能的持续提升中获益。我和很多开发者聊过一个感受:模型智能提升、以及模型“正确调用工具”的能力,增长速度往往远快于你新增工具、或者教育用户理解这些工具的速度。

 

所以如果你退一步思考:“我能不能先做一个高度通用的工具?”那你构建出一个可以适应未来新场景的产品的概率,其实会大得多。这一点,我非常认同。

 

Dan:那在这些原则之下,你怎么看其中的取舍?比如工具设计本身的权衡问题。

 

Kieran:对,我觉得把东西放进 prompt 里、再配合工具,本身是很棒的。但问题在于,我们现在突然需要去创建一些“能读取 Skills 的工具”,或者类似的东西。于是就出现了一个新的“元层”。Skills 本质上就像是一种即时的 prompt 注入,但你得先把这个体系搭出来。现在所有在做这些东西的人,如果不是直接用 Claude Code 或 Cloud SDK,那基本都得自己从头构建一整套。

 

于是就出现了一种拉扯:你到底是把行为直接描述在一个 tool 里?还是再包一层 tool,让它去调用别的东西?这中间是有摩擦成本的。当然,可组合性是很好的。比如一开始你可能会有五个 tool:搜索邮件、读取邮件、做这个、做那个。但你也可以说:不,我只提供一个 execute tool,然后用 Skills、MCP,或者某种抽象层来完成这些事情。现在正处在这样一个转变期,而 Claude Code 和 Claude SDK 显然是在推动这个方向。

 

但我确实能感受到这种摩擦。我猜你也一定感受到了。所以我很好奇:你有没有什么最佳实践,能给那些还停留在“传统 AI 应用思维”的人一些建议?

 

Felix:我不确定我能给出什么“来自山顶的智慧”,会比你已经拥有的经验更有价值。但你说的那点,确实非常戳中我。我觉得你必须做一个取舍:哪些输出你愿意让它是非确定性的、哪些地方你愿意依赖模型的智能。而且一旦你依赖模型智能,每当你换一个更便宜、或者“更笨”的模型,那些地方的质量就会下降。

 

所以我会把整个工作流拆成两类:一类是非确定性的;一类是可重复、稳定的。如果某个部分非常可重复,而且你可以非常确信它“永远不会变”,而且就算模型变聪明了,你也得不到任何额外收益,那我会觉得,这正是写一个工具的好地方。

 

其实我们已经在这么做了。你完全可以给 Claude 一个极其通用的“汇编级”工具,比如:“直接调用 GCC,你想怎么编就怎么编。”但我们并没有这么做,因为那样就太疯狂了。

 

Skills 与可组合性实践

 

Dan:那已经是粒度的极限了。

 

Kieran:不过我也想说一句:当我和很多开发者聊的时候,我发现即便这个“是否要给模型工具”的基本假设,也正在被挑战。我不会把太多赌注压在这个假设上。比如,我们到底是不是还需要给 Claude 工具?还是说,某一天它只需要靠记忆和权重,直接把 0 和 1 写到世界里?这是一个非常有意思、也非常难判断的问题,没人真的知道答案。

 

但你们已经在实践中学到了一些东西。你们之所以创造了 Skills,就是因为仅靠 Slash command 或子 Agent 已经不够了,对吧?我们需要 Claude.md 更强,但现实是 Skills 正是为了解决这个问题而诞生的,而且显然它们效果很好。我完全认同你说的,Skills 太棒了。我现在几乎每天都在写 Skills,而且真的很爱用。所以这里面一定有些什么。但问题是:什么时候应该用 Skill?什么时候又不该?

 

Felix:这真的是一场特别有意思的对话。有一个你以后真的应该跟 Barry 聊聊。在公司内部,至少在某种程度上,Skills 这个概念就是他提出来的。从根本上说,Skills 正是你刚才描述的那种张力的自然产物。

 

举个例子,我们想让公司内部的人能很容易地拿到各种仪表盘。我们用的是一家主流数据服务商,很多数据都在那儿。一开始我们在想:要不要做一堆非常具体的工具,专门去拉数据、压缩成固定格式。最早那几版仪表盘,其实效果并不理想(那还是 4.5 之前)。大概每三四个里面,就有一个看起来很拉胯。于是,我们开始想:要不要把参数卡死,直接做一个“固定模板”的仪表盘?Claude 只负责往里面填新数据。

 

但在这个过程中,我们突然发现了一件事:如果你只是告诉 Claude 如何正确地查询这个数据源、可以使用 SQL、以及生成仪表盘时需要遵循哪些设计原则,突然间,它就能稳定地产出质量很高的结果,而且是“几乎每一次”都很好。

 

更重要的是,这就打开了“涌现能力”的大门。因为你还可以对 Claude 说:“我知道你在遵循这些仪表盘原则,但我想换一种图表类型”,或者“我想把它和另一份数据结合起来。”就在这一刻,事情真正开始变得有趣了。

 

Dan:这真的很有意思。我觉得为什么要用 Skill,而不是只给它 GCC、让一切都即兴发生,其中一个关键原因在于:你需要把一些可重复的、可分享的知识,变成一个大家都能讨论、都能复用的东西。并不是所有事情都应该是“即时生成”的。有些事情,你就是希望一个团队能长期、反复地用同一种方式来做。而这,本质上就是 Skill。

 

Felix:而且这其实也很符合人类本身的工作方式,对吧?比如我刚加入一家公司时,总有人教我怎么订机票、怎么订会议室。从某种意义上说,我们每个人,都是靠着一堆 markdown 文件在工作。

 

我觉得差不多该下线了,但在走之前,我想让你们两个各自给我一个建议:你们最希望我们改的一件事是什么?

 

Dan:那我先来一个最简单的:给我对整台电脑的完全访问权限。还有就是,让我更清楚地知道它现在到底是在我本地电脑上运行,还是在云端以聊天的形式运行;以及,让它在手机上用起来更顺畅。

 

Kieran:我也支持移动端。但我最想要的是能让我添加自己的插件。我有一个插件市场,我只想把它接进来直接用。现在我得在一个应用里加东西,再拷贝到这里,有点绕。可能也能凑合用,但如果能原生支持插件市场、直接添加插件,那真的会非常棒。

 

Felix:好,明白了。谢谢你们,这些反馈都非常有价值。我们会把这些带回去,跟团队一起讨论。也欢迎大家把想法发给我们。我们真的很希望听到大家的反馈,并据此调整路线图。

 

测试总结:理念可以,做得一般

 

最后,我们总结了 Every 团队的测评结果。

 

Claude Cowork 的核心定位是为非技术用户提供 Claude Code 级别的 AI 协作能力,其最显著的突破在于重构了 AI 使用逻辑,从传统“发提示词→等回复”的一问一答模式,升级为“异步协作”模式。

 

与普通 Claude 聊天相比,Claude Cowork 专为“长时间工作”设计,具备持续推进任务直至完成的能力。直播中展示的典型案例包括:审计过去一个月的日历并分析与目标的匹配度、抓取 PostHog 数据统计按钮点击量、分析 Every 咨询业务的竞品、整理下载文件夹、校对 Google Docs 文案等。这些任务均需 AI 持续“浏览”、推理,部分任务耗时可达一小时左右,远超普通 AI 聊天的响应速度。

 

产品的场景适配性极强,尤其适合需要深度研究和数据处理的岗位。用户只需连接 Chrome 浏览器,AI 即可直接使用用户已登录的各类服务,无需重复认证,轻松完成 Twitter 时间线热点分析、竞品信息搜集等需多平台联动的任务。同时,它支持生成文档、Excel、PPT、PDF 等多种产出物,可应用于简历优化、会议发言起草等日常工作场景,大幅提升增长团队、咨询人员、写作者等群体的工作效率。

 

在交互设计上,产品右侧设置了待办任务列表,清晰展示任务进度与当前阶段,用户可直观掌握 AI 工作状态。其“询问用户”功能还配备了可视化交互界面,支持多选项快速响应,进一步降低了操作门槛。

 

根据测评,Cowork 具备较强的可扩展性,支持加载用户已安装的 Claude Skills,这也是其最具“可玩度”和“可定制性”的核心入口。用户可通过 Skills 封装专业知识与操作逻辑,实现个性化需求。

 

测评团队也指出了产品当前存在的争议与不足。

 

最核心的争议在于“单独设置 Cowork 标签页”的设计:部分用户认为应在同一标签页内根据任务自动切换模式,避免额外的选择成本;但也有观点认为,独立标签页能明确提醒用户切换使用心态:从“实时对话”转向“异步托付”,尤其对非技术用户而言,这种明确的区分有助于适应全新的协作范式。

 

另外在体验细节上,产品仍有诸多优化空间:一是 UI 打磨不足,任务列表仅按时间排序,缺乏视觉区分度,部分内容存在“懒加载”导致展示不及时;二是权限管理不够直观,普通用户难以清晰判断 AI 是在本地还是云端运行,文件夹访问权限需手动配置易造成困惑;三是“询问用户”功能存在逻辑缺陷,可能在用户未响应时自动跳过问题,且选项数量和字符数存在限制;四是对复杂应用(如 Google Docs)的适配尚不完善,相关操作容易失败。

 

针对不同用户,测评团队给出了针对性使用建议:非技术用户可将其视为“升级版聊天功能”,用日常任务直接尝试,逐步适应异步协作模式;重度用户可尝试通过 Skills 定制个性化功能,探索组合使用的可能性。他们表示,所有用户均需保持好奇心,忽略“三个月前 AI 做不到”的固有认知,在每一次产品更新后重新尝试核心需求,毕竟 AI 能力每隔几个月就会发生巨大迭代。

 

最终,测评团队给出的评分结论为:“理念绿牌,当前执行黄牌”。理念层面,产品开创性地将 Claude Code 级别的异步协作能力开放给非技术用户,推动了 AI 协作范式的转变,具备极高的探索价值;执行层面,因 UI 粗糙、部分功能逻辑不完善等问题,当前体验仍有较大优化空间。

 

参考链接:

https://www.youtube.com/watch?v=_6C9nMvQsGU

https://www.youtube.com/watch?v=oPBN-QIfLaY

https://www.promptarmor.com/resources/claude-cowork-exfiltrates-files

FACTS基准测试套件发布,这是一个旨在系统性评估大型语言模型事实准确性的全新行业基准。该套件由 FACTS 团队与 Kaggle 联合开发,扩展了早期事实基础研究相关的工作,并引入了一个更广泛的多维度框架,用于衡量语言模型在不同使用场景下产生事实正确响应的可靠性。

 

FACTS 基准测试套件基于原先的 FACTS Grounding Benchmark,并增加了三个新基准:参数化(Parametric)、搜索(Search)和多模态(Multimodal)。结合更新后的 Grounding Benchmark v2,该套件可以从反映现实世界常见模型使用场景的四个维度评估事实性。该基准测试总共包括 3513 个精选示例,分为公共和私有评估集两部分。Kaggle 负责管理保留的私有数据集,评估参赛模型,并通过公开排行榜发布结果。总体性能以 FACTS 评分的形式呈现。该分值是通过所有基准测试以及两部分数据集的平均准确率计算得出的。

 

参数化基准测试侧重于模型仅凭内部知识(无需外部工具)回答基于事实的问题的能力。问题形式类似于常见的知识问答题,通常可通过维基百科等来源找到答案。搜索基准测试评估模型能否通过标准的 Web 搜索工具准确地检索并整合信息,通常需要多步检索才能完成单个查询。多模态基准测试在回答图像相关的问题时检验事实准确性,需要结合背景知识进行正确的视觉解读。更新后的 Grounding Benchmark v2 评估响应是否基于提供的上下文信息进行了合理推演。

 

初步结果既凸显了进展,也揭示了接下来要面对的挑战。在评估的模型中,Gemini 3 Pro 以 68.8%的总体 FACTS 评分位居首位,其参数化事实性与搜索事实性较前代模型均有显著提升。然而,评估的所有模型总体准确率均未突破 70%,多模态事实性成为各模型普遍面临的难题。

图片来源:谷歌 DeepMind 博客

 

基准测试的结构引起了从业者的关注。资深 iOS 工程师 Alexey Marinin 在评论此次发布时指出

 

这种四维视角(知识、Web、基础、多模态)感觉更接近人们日常实际使用这些模型的方式。

 

FACTS 团队表示,该基准旨在支持正在进行的研究,而不是作为模型质量的最终衡量标准。通过公开数据集并规范评估标准,该项目旨在为衡量语言模型的事实可靠性提供一个共同的基准,以适应其持续演进的发展需求。

 

原文链接:

https://www.infoq.com/news/2026/01/facts-benchmark-suite/

1 月 16 日,支付宝联合千问 App、淘宝闪购、Rokid、大麦、阿里云百炼等伙伴,正式发布 ACT 协议(Agentic Commerce Trust Protocol,智能体商业信任协议)。这是中国首个面向 Agent 商业需求设计的开放技术协议框架,为 AI 与电商、外卖等服务平台的协同打造一套 “通用语言”,让跨终端、跨系统、跨平台的 AI 任务执行,变得更便捷、更高效。

以千问 App 为例,依托 ACT 协议 ,千问 App 成功打通淘宝闪购与支付宝 AI 付:用户只需向千问发出指令 “帮我点杯珍珠奶茶”,千问基于用户地理位置,智能推荐附近符合需求的商品,同步完成比价与优惠券自动核销。

用户仅需点击 “选它”,确认支付宝付款,即可一键完成结账。整个购物流程以对话式、自动化、不跳端的方式推进,千问化身专属 “购物助手”,包办繁琐操作。

当 AI 的能力边界不断拓展,从“聊天对话”延伸至购物付款等“办事时代”,新的问题也随之浮现:AI 操作是否获得用户明确授权?资金交易过程是否足够安全?更换设备或应用后,服务体验能否保持连贯?

ACT 协议的诞生正是为破解这些问题而来。支付宝为其搭建了 “委托授权域”“商业交互域”“支付服务域”“信任服务域” 四大核心基础设施标准,实现 AI 操作全流程可追溯、可验证,让人更放心;支持自动化交易流程,减少不必要的人工干预,提升服务效率;统一多平台服务标准,避免体验的割裂。

与传统付款模式不同,在 ACT 协议的规则框架下,AI 仅承担下单操作的执行角色,付款环节始终由用户主导或自主授权。在保障资金安全的前提下,为用户大幅节省时间成本。而对商家而言,未来接入 AI 原生应用时,只需按照协议标准配置统一接口,即可对接全渠道入口,无需单独进行复杂的 API 开发,大幅降低对接成本。

目前,ACT 协议可使用在 AI 代买、企业自动化采购等多元场景,并提供两种付款模式:一是即时付款,用户与 AI 实时对话,基于推荐列表自主决策,确认后完成付款授权与身份验证,适用于 AI 点外卖、日常购物等高频场景;二是委托授权,用户可提前设定时间窗口、金额上限、商家范围等条件,即便离线无指令,AI 也能自动监测商品动态并完成下单结算,适用于机票、酒店预订等场景。

该协议最大限度遵循兼容性、隐私性、开放性三大原则,全面适配现有商业与支付系统,并将伴随 AI 行业技术发展持续优化。支付宝同时表示,正积极推动更多支付服务商、商家与平台、AI 开发者、智能终端生态厂商加入,共同完善协议内容,共建 AI 商业信任新生态。

随着 AI 原生应用能力的持续升级,“AI 代办” 服务日渐普及,支付作为其中特殊且关键的环节,正成为全球科技企业的布局焦点。此前,OpenAI 联合 Stripe 推出协议以支持 ChatGPT 结账功能;近期,谷歌也发布 AI 购物全流程通用商务协议(Universal Commerce Protocol,简称 UCP),将实现用户在 Gemini 内直接下单。

这里记录每周值得分享的科技内容,周五发布。

本杂志开源,欢迎投稿。另有《谁在招人》服务,发布程序员招聘信息。合作请邮件联系[email protected])。

封面图

刚刚运营的北京通州站位于地下,为了充分利用自然光,屋顶采用了透光的膜结构,上方还有一个风帆形状的保护架。(via

中国 AI 大模型领导者在想什么

上周六(1月10日),北京有一场"AGI-Next 前沿峰会",由清华大学基础模型实验室主办。

中国顶尖的 AI 大模型领导者,很多都出席了。

  • 唐杰:清华大学教授,智谱创始人
  • 杨植麟:月之暗面 Kimi 创始人
  • 林俊旸:阿里 Qwen 技术负责人
  • 姚顺雨:OpenAI 前核心研究者、腾讯 AI 新部门负责人

他们谈了对大模型和中国 AI 发展的看法,网上有发言实录

内容非常多,有意思的发言也很多,下面是我摘录的部分内容。

一、唐杰的发言

1、智谱的起源

2019年,我们开始研究,能不能让机器像人一样思考,当时就从清华成果转化,在学校的大力支持下,成立了智谱这么一家公司,我现在是智谱的首席科学家。

那个时候,我们实验室在图神经网络、知识图谱方面,在国际上做的还行,但我们坚定地把这两个方向暂停了,暂时不做了,所有的人都转向做大模型。

2、泛化和 Scaling

我们希望机器有泛化能力,我教它一点点,它就能举一反三。就和人一样,教小孩子的时候,我们总希望教三个问题,他就会第四个、第十个,甚至连没教过的也会。怎么让机器拥有这种能力?

目前为止,我们主要通过 Scaling(规模化)达到这个目标,在不同层面提高泛化能力。

(1)我们最早期用 Transformer 训练模型,把所有的知识记忆下来。训练数据越多、算力越多,模型的记忆能力就越强,也就是说,它把世界上所有的知识都背下来了,并且有一定的泛化能力,可以抽象,可以做简单的推理。比如,你问中国的首都是什么?这时候模型不需要推理,它只是从知识库里拿出来。

(2)第二层是把模型进行对齐和推理,让它有更复杂的推理能力,以及理解我们的意图。我们需要持续的 Scaling SFT(Supervised Fine-Tuning,监督式微调),甚至强化学习。通过人类大量的数据反馈,不断 Scaling 反馈数据,可以让模型变得更聪明、更准确。

(3)今年是 RLVR(强化学习与可验证奖励)爆发年。这里的"可验证"是什么意思?比如,数学可以验证、编程可能可以验证,但更广泛地,网页好不好看,就不大好验证了,它需要人来判断。

这就是为什么这个事情很难做,我们原来只能通过人类反馈数据来做,但人类反馈的数据里面噪音也非常多,而且场景也非常单一。

如果我们有一个可验证的环境,这时候我们可以让机器自己去探索、自己去发现这个反馈数据,自己来成长。这是我们面临的一个挑战。

3、从 Chat 到做事:新范式的开始

大家可能会问,是不是不停地训练模型,智能就越来越强?其实也不是。

2025年初,DeepSeek 出来,真是横空出世。大家原来在学术界、产业界都没有料到 DeepSeek 会突然出来,而且性能确实很强,一下子让很多人感到很震撼。

我们当时就想一个问题,也许在 DeepSeek 这种范式下,Chat(对话)差不多算是解决了。也就是说我们做得再好,在 Chat 上可能做到最后跟 DeepSeek 差不多。或许我们可以再个性化一点,变成有情感的 Chat,或者再复杂一点,但是总的来讲,这个范式可能基本到头了,剩下更多的反而是工程和技术的问题。

那么,AI 下一步朝哪个方向发展?我们当时的想法是,让每个人能够用 AI 做一件事情,这可能是下一个范式,原来是 Chat,现在是真的做事了。

当时有两个方向,一个是编程,做 Coding、做 Agent;另一个是用 AI 来帮我们做研究,类似于 DeepResearch,甚至写一个复杂的研究报告。我们现在的选择是把 Coding、Agentic、Reasoning 这三个能力整合在一起。

二、林俊旸的发言

4、千问是怎么开源的

千问的开源模型比较多,很多人问这是为什么?

这起源于2023年8月3日,我们开源了一个小模型,它是我们内部用来做实验的 1.8B 模型。我们做预训练,资源毕竟有限,你做实验的话不能通通用 7B 的模型来验,就拿 1.8B 的来验。

当时我的师弟跟我说,我们要把这个模型开源出去。我非常不理解,我说这个模型在2023年几乎是一个不可用的状态,为什么要开源出去?他跟我说 7B 很消耗机器资源,很多硕士生和博士生没有机器资源做实验,如果 1.8B 开源出去的话,很多同学就有机会毕业了,这是很好的初心。

干着干着,手机厂商跑来跟我们说 7B 太大,1.8B 太小,能不能给我们干一个 3B 或 4B 的,这个容易,没有什么很难的事情。一路干下来,型号类型越来越多,跟服务大家多多少少有一点关系。

5、我们的追求是多模态模型

我们自己内心追求的,不仅仅是服务开发者或者服务科研人员,而是能不能做一个 Multimodal Foundation Agent(多模态基础智能体)。

我特别相信这件事情,2023年的时候大模型是一个大家都不要的东西,多多少少有那么几分大炼钢铁的成分,多模态是我们从那时就一直想做的事情。

为什么呢?我们觉得如果你想做一个智能的东西,天然的应该是 Multimodal(多模态),当然带有不同看法,各个学者都有一些看法,多模态能不能驱动智力的问题。我懒得吵这个架,人有眼睛和耳朵可以做更多的事情,我更多的考虑是 Foundation(基础智能体)有更多的生产力,能不能更好地帮助人类,毫无疑问我们应该做视觉,我们应该做语音。

更进一步,我们要做什么东西呢?Omni 的模型(全模态模型)不仅仅是能够理解文本、视觉、音频,我们可能还让它生成文本、音频。今天我们已经做到了,但是我们还没有做到把视觉生成结合在一起。如果做到三进三出,我觉得至少是我个人喜欢的东西。

三、姚顺雨的发言

6、To C 和 To B 的差异

我的一个观察是 To C(消费者模型)和 To B(商业用户模型)发生了明显的分化。

大家一想到 AI,就会想到两个东西,一个是 ChatGPT,另外一个是 Claude Code。它们就是做 To C 和 To B 的典范。

对于 To C 来说,大部分人大部分时候不需要用到那么强的智能,可能今天的 ChatGPT 和去年相比,研究分析的能力变强了,但是大部分人大部分时候感受不到,更多把它当作搜索引擎的加强版,很多时候也不知道该怎么去用,才能把它的智能激发出来。

但对于 To B 来说,很明显的一点是智能越高,代表生产力越高,也就越值钱。所以,大部分时候很多人就是愿意用最强的模型。一个模型是200美元/月,第二强或者差一些的模型是50美元/月、20美元/月,我们今天发现很多美国的人愿意花溢价用最好的模型。可能他的年薪是20万美元,每天要做10个任务,一个非常强的模型可能10个任务中八九个做对了,差的是做对五六个,问题是你不知道这五六个是哪五六个的情况下,需要花额外精力去监控这个事情。

所以,在 To B 这个市场上,强的模型和稍微弱点的模型,分化会越来越明显。

7、垂直整合和模型应用分层

我的第二点观察是,基础模型和上层应用,到底是垂直整合,还是模型应用分层,也开始出现了分化。

比如,ChatGPT Agent 是垂直整合,Claude(或者 Gemini)+ Manus 是模型应用分层。过去大家认为,当你有垂直整合能力肯定做得更好,但起码今天来看并不一定。

首先,模型层和应用层需要的能力还是挺不一样的,尤其是对于 To B 或者生产力这样的场景来说,可能更大的预训练还是一个非常关键的事情,这个事情对于产品公司确实很难做。但是想要把这么一个特别好的模型用好,或者让这样的模型有溢出能力,也需要在应用侧或者环境这一侧做很多相应的事情。

我们发现,其实在 To C 的应用上,垂直整合还是成立的,无论 ChatGPT 还是豆包,模型和产品是非常强耦合、紧密迭代的。但是对于 To B 来说,这个趋势似乎是相反的,模型在变得越来越强、越来越好,但同样会有很多应用层的东西将好的模型用在不同的生产力环节。

8、需要更大的 Context

怎么让今天的大模型或者 AI 能够给用户提供更多价值?我们发现,很多时候需要的是额外的 Context(上下文)。

比如,我问 AI 今天该去吃什么?其实,你今天问 ChatGPT 和你去年问或者明天问,答案应该会差很多。这个事情想要做好,不是说你需要更大的模型、更强的预训练、更强的强化学习,而是可能需要更多额外的输入,或者叫 Context。如果它知道我今天特别冷,我需要吃些暖和的,我在今天这样的范围活动,可能我老婆在另一个地方吃什么等各种各样的事情,它的回答就会更好。

回答这样的问题,更多需要的是额外的输入。我和老婆聊了很多天,我们可以把聊天记录转发给元宝,把额外的输入用好,会给用户带来很多额外的价值。这是我们对 To C 的思考。

四、圆桌对话:中国 AI 的未来

李广密(主持人):我想问大家一个问题,在三年和五年以后,全球最领先的 AI 公司是中国团队的概率有多大?我们从今天的跟随者变成未来的引领者,这个过程到底还有哪些需要去做好?

9、姚顺雨的回答

我觉得概率还挺高的,我挺乐观的。目前看起来,任何一个事情一旦被发现,在中国就能够很快的复现,在很多局部做得更好,包括之前制造业、电动车这样的例子已经不断地发生。

我觉得可能有几个比较关键的点。

(1)中国的光刻机到底能不能突破,如果最终算力变成了瓶颈,我们能不能解决算力问题。

(2)能不能有更成熟的 To B 市场。今天我们看到很多做生产力或者做 To B 的模型和应用,还是会诞生在美国,因为支付意愿更强,文化更好。今天在国内做这个事情很难,所以大家都会选择出海或者国际化。这和算力是比较大的客观因素。

(3)更重要的是主观因素,我觉得中国想要突破新的范式或者做非常冒险事情的人可能还不够多。也就是说,有没有更多有创业精神或者冒险精神的人,真的想要去做前沿探索或者范式突破的事情。我们到底能不能引领新的范式,这可能是今天中国唯一要解决的问题,因为其他所有做的事情,无论是商业,还是产业设计,还是做工程,我们某种程度上已经比美国做得更好。

10、林俊旸的回答

这个问题是个危险的问题,理论上这个场合是不可以泼冷水的,但如果从概率上来说,我可能想说一下我感受到的中国和美国的差异。比如说,美国的 Compute(算力)可能整体比我们大1-2个数量级,但我看到不管是 OpenAI 还是什么,他们大量的算力投入到的是下一代研究当中去,我们今天相对来说捉襟见肘,光交付可能就已经占据了我们绝大部分的算力,这会是一个比较大的差异。

这可能是历史上就有的问题,创新是发生在有钱的人手里,还是穷人手里。穷人不是没机会,我们觉得这些富哥真的很浪费,他们训练了这么多东西,可能训练了很多也没什么用。但今天穷的话,比如今天所谓的算法 Infra(基础设施)联合优化的事情,如果你真的很富,就没有什么动力去做这个事情。

未来可能还有一个点,如果从软硬结合的角度,我们下一代的模型和芯片的软硬结合,是不是真的有可能做出来?

2021年,我在做大模型,阿里做芯片的同学,找我说能不能预测一下,三年之后这个模型是不是 Transformer,是不是多模态。为什么是三年呢?他说我们需要三年时间才能流片。我当时的回答是三年之后在不在阿里巴巴,我都不知道!但我今天还在阿里巴巴,它果然还是 Transformer,果然还是多模态,我非常懊悔为什么当时没有催他去做。当时我们的交流非常鸡同鸭讲,他给我讲了一大堆东西,我完全听不懂,我给他讲,他也不知道我们在做什么,就错过了这个机会。这个机会有没有可能再来一次?我们虽然是一群穷人,是不是穷则思变,创新的机会会不会发生在这里?

今天我们教育在变好,我属于90年代靠前一些的,顺雨属于90年代靠后一点的,我们团队里面有很多00后,我感觉大家的冒险精神变得越来越强。美国人天然有非常强烈的冒险精神,一个很典型的例子是当时电动车刚出来,甚至开车会意外身亡的情况下,依然会有很多富豪们都愿意去做这个事情,但在中国,我相信富豪们是不会去干这个事情的,大家会做一些很安全的事情。今天大家的冒险精神开始变得更好,中国的营商环境也在变得更好的情况下,我觉得是有可能带来一些创新的。概率没那么大,但真的有可能。

三年到五年后,最领先的 AI 公司是一家中国公司的概率,我觉得是20%吧,20%已经非常乐观了,因为真的有很多历史积淀的原因在这里。

11、唐杰的回答

首先我觉得确实要承认,无论是做研究,尤其是企业界的 AI Lab,和美国是有差距的,这是第一点。

我们做了一些开源,可能有些人觉得很兴奋,觉得中国的大模型好像已经超过美国了。其实可能真正的情况是我们的差距也许还在拉大,因为美国那边的大模型更多的还在闭源,我们是在开源上面玩了让自己感到高兴的,我们的差距并没有像我们想象的那样好像在缩小。有些地方我们可能做的还不错,我们还要承认自己面临的一些挑战和差距。

但我觉得,现在慢慢变得越来越好。

(1)90后、00后这一代,远远好过之前。一群聪明人真的敢做特别冒险的事,我觉得现在是有的,00后这一代,包括90后这一代是有的,包括俊旸、Kimi、顺雨都非常愿意冒风险来做这样的事情。

(2)咱们的环境可能更好一些,无论是国家的环境,比如说大企业和小企业之间的竞争,创业企业之间的问题,包括我们的营商环境。

(3)回到我们每个人自己身上,就是我们能不能坚持。我们能不能愿意在一条路上敢做、敢冒险,而且环境还不错。如果我们笨笨的坚持,也许走到最后的就是我们。

科技动态

1、载人飞艇

1月9日,湖北制造的载人飞艇祥云 AS700,完成了荆门至武汉往返航程。这是全国首次载人飞艇商业飞行,可能也是目前世界唯一运作的商业载人飞艇。

飞艇总长50米,最大载客量9人。由于载客量太小,不可能用作常规的交通工具,只能做一些观光飞行。

2、鼻子触控

一个英国发明家想在洗澡时使用手机,结果因为手指带水无法触控。

他灵机一动,发明了戴在鼻子上的触控笔。

它的结构很简单,就是一个石膏纤维的鼻管,里面插着一支触控笔。

这个发明看上去很有用,可以解放双手,也适合戴手套的情况和残疾人士。

3、越南禁止不可跳过的广告

越南近日颁布第342号法令,禁止不可跳过的广告,将于2026年2月15日起生效。

法令规定,视频广告的等待时间必须在5秒以内,否则观众可以选择跳过。而且,关闭方式应该是清晰简便的,禁止使用迷惑用户的虚假或模糊符号。

这明显针对 Youtube 等视频平台的片头广告。这让人第一次感到,越南互联网值得叫好。

文章

1、我所有的新代码都将闭源(英文)

作者是一个开源软件贡献者。他感到,自己的开源代码都被大模型抓取,导致仓库访问者减少,进而也没有收入,所以他后面的代码都要闭源。

2、网站的视觉回归测试(英文)

本文介绍如何使用 Playwright,对网页进行视觉测试,看看哪里出现变动。

3、我用 PostgreSQL 代替 Redis(英文)

Redis 是最常用的缓存工具,作者介绍它的痛点在哪里,怎么用 PostgreSQL 数据库替代。

4、如何用 CSS 修复水平滚动条(英文)

一篇 CSS 初级教程,介绍四个简单的技巧,让网页不会出现水平滚动条(即避免溢出)。

5、消息队列原理简介(英文)

本文是初级教程,介绍消息队列(mesage queue)的概念和作用。

6、macOS Tahoe 的圆角问题(英文)

macOS 最新版本 Tahoe 加大了圆角半径,造成调整窗口大小时经常失败。作者认为,从操作角度看,圆角面积最好超过端头的50%。

工具

1、whenwords

本周,GitHub 出现了一个奇特的库,没有一行代码,只有一个接口文档。

用户需要自己将接口文档输入大模型,并指定编程语言,生成相应的库代码再使用。

以后会不会都是这样,软件库没有代码,只有接口描述?

2、Hongdown

Markdown 文本的格式美化器,根据预设的规则,修改 Markdown 文本的风格样式。

3、VAM Seek

一个开源的网页视频播放器,会自动显示多个时点的视频缩略图,便于快速点击跳转。

4、kodbox

开源的网页文件管理器。

5、Nigate

让 Mac 电脑读写 NTFS 磁盘的开源工具。(@hoochanlon 投稿)

6、Flippy Lid

一个实验性软件,把 macbook 铰链开合作为输入,可以玩 Flippy Lid,也可以作为密码解锁。(@huanglizhuo 投稿)

7、Jumble

nostr 网络的开源 Web 客户端,专门用来浏览以 feed 内容为主的 relay 节点。(@CodyTseng 投稿)

8、Clash Kit

一个基于 Node.js 的 Clash 命令行管理工具。(@wangrongding 投稿)

9、SlideNote

开源的 Chrome 浏览器插件,在侧边栏做笔记,支持跨设备自动同步。(@maoruibin 投稿)

10、NginxPulse

开源的 Nginx 访问日志分析与可视化面板,提供实时统计、PV 过滤、IP 归属地、客户端解析。
@likaia 投稿)

AI 相关

1、Auto Paper Digest (APD)

一个 AI 应用,自动从 arXiv 抓取每周的热门 AI 论文,通过 NotebookLM 生成视频讲解,并能发布到抖音。(@brianxiadong 投稿)

2、CC Switch

一个跨平台桌面应用,一键切换 Claude Code / Codex / Gemini CLI 的底层模型,以及完成其他的管理设置。(@farion1231 投稿)

3、网易云音乐歌单 AI 分析

使用 AI 分析用户的网易云音乐歌单,进行总结。(@immotal 投稿)

资源

1、EverMsg

这个网站可以查看 BTC 区块链的 OP_RETURN 字段,该字段记录了一段文本,只要发上区块链就永远不会删除和修改。(@blueslmj 投稿)

2、DeepTime Mammalia

沉浸式 3D/2D 网页可视化项目,交互式哺乳纲演化树,探索哺乳动物2亿年的演化。(@SeanWong17 投稿)

图片

1、冰下修船

俄罗斯有一个船厂,位于北极圈附近。每年冬天,船坞都要结冰。

为了冬天也能修船,船厂会把冰层凿掉一块,露出船底。

冰层通常不会那么厚,不会结冰到船底,必须分层凿开。工人先用电锯,锯开最上层的冰层,然后等待下面的河水结冰,再用电锯向下切割,反复多次,直到船底结冰。

有时,需要凿开一条很长的冰槽。

下图是工人进入冰层下方,检修船底,由于冰下工作条件恶劣且有危险性,工人的工资都较高。

言论

1

我对自己的代码被大模型吸收感觉如何?

我很高兴这样,因为我把这看作是我一生努力的延续:民主化代码、系统和知识。

大模型让我们更快编写更好、更高效的软件,并让小团队有机会与大公司竞争。这和 90 年代开源软件所做的事情一样。然而,这项技术太重要,绝不能只掌握在少数公司手中。

-- Antirez,Redis 项目的创始人

2、

即使你不相信 AI,但跳过它对你和你的职业都没有帮助。

以前,你熬夜编程,看到项目顺利运行时,心潮翻滚。现在,如果你能有效利用 AI,可以建造更多更好的项目。乐趣依旧存在,未受影响。

-- Antirez,Redis 项目的创始人

3、

如果你不写作,你就是一个有限状态机。写作时,你拥有图灵机的非凡力量。

-- 曼纽尔·布卢姆(Manuel Blum),图灵奖得主

4、

人们陷入困境有三个主要原因:(1)行动力不足,(2)行动方向错误,(3)等待天上掉馅饼(幻想问题会缓解而拒绝采取行动)。

-- 《当你想摆脱困境》

往年回顾

年终笔记四则(#334)

YouTube 有多少个视频?(#284)

AI 聊天有多强?(#234)

政府的存储需求有多大?(#184)

(完)

前情提要


相关背景

  • 众所周知,Fiat24 的汇率非常差

Fiat24:1 刀=0.8511 欧
谷歌:1 刀=0.861 欧
Neverless:1 刀=0.861 欧


  • RMB 能正常消费是 BitgetWalletSafepal 进行了汇率补贴
  • 当我们需要用欧元入金盈透/嘉信磨损偏大
  • 可以借助 Neverless 优化汇率

将 U 充值到 Neverless

  • 个人习惯走 Arbitrum/Base 链的 USDC

将美元换成欧元

  • Neverless 更新了 IBAN,支持了欧元转账,点击交易


  • 购买欧元


进行转账

  • 点击发送按钮
  • 新银行账户


  • 打开 Fiat24,查看账户号码,选择 Add,记下 Account


  • 填入账户信息

货币:欧元
国家:瑞士
IBAN:刚刚记下的 Account
BIC/SWIFT:SAHHCHZ2


  • 转账后,工作日内几个小时就到账啦

📌 转载信息
原作者:
Ling_Jing
转载时间:
2026/1/16 13:04:19

在这里,我分享一下如何万能的创建属于你自己的 skill 和对应的 hooks 搭配,不过在分享之前,我要声明,我并非原创发现,我只是从各个地方学习到了知识,然后整合分享给大家

一。如何创建自定义的 skill

1. 安装 skill 插件与 MCP

github 仓库地址: anthropics/skills: Public repository for Agent Skills

这里我直接把命令拿过来方便直接使用,在 Claude code 里面输入
/plugin marketplace add anthropics/skills
(两个哪个都行,安装一次就行)
/plugin install document-skills@anthropic-agent-skills
/plugin install example-skills@anthropic-agent-skills
运行后选择 Install for you (user scope)
提示✓ Installed document-skills. Restart Claude Code to load new plugins. 就是安装成功了,然后重启 Claude Code

这里安装 skill 插件是为了有 skill-creator,它的作用是创建或更新 skills 的指南

2. 安装 **chrome-devtools-mcp** 和 upstash/context7: Context7 MCP Server – Up-to-date code documentation for LLMs and AI code editors(可选项)
直接配置这两个 MCP 就行,这里不演示了

2. 此时就可以创建 skill 了

情景一:需要把 API 文档做成 skill

举例:OpenAI 兼容协议文档
❶与 Claude 对话:请你使用 context7mcp 去查找 OpenAI 兼容协议文档,详细的告诉我它的全部内容


❷请你根据刚刚查询到的全部内容,参考 skill-creator 来帮我生成 skill



现在就创建成功了,只不过我发现他放的地方不对


那个文件夹是项目级别(当前项目专用),应该放在.claude\skills 这个文件夹里,这个手动移动一下就行,.skill 文件是打包好的把这个 .skill 文件移动到全局 skills 目录,所有项目都可以使用。
这时候一个 skill 就创建好了

情景二:需要把 context7 查不到的文档做成 skill

举例:智谱的 API 文档
❶与 Claude 对话:请你使用 chrome-devtools-mcp 访问 使用概述 - 智谱 AI 开放文档(链接放在这里变成蓝链了,对话的时候直接粘贴链接就行,别粘贴文字)

❷与 Claude 对话:请你使用 chrome-devtools-mcp 把 cURL;Python SDK;Java SDK;Python SDK (旧) 这几个调用示例的具体内容查一下,还有关于 GLM 编码套餐的端点差异也查看一下
(我这里只是举例子,你看你自己的文档,你需要什么内容,你就把你需要的内容让他再次去查看)


❸与 Claude 对话:请你根据刚刚查询到的全部内容,参考 skill-creator 来帮我生成 skill


创建成功依旧是需要手动一下位置,但是问题不大

情景三:把 MCP 做成 skill

举例:把 context7 做成 MCP
❶与 Claude 对话:请你把 context7 这个 MCP 的调用参考 skill-creator 来帮我生成 skill,我的要求是,在新增或修改代码之前,使用此 mcp 去查询最新的、特定版本的文档和代码示例,放入上下文进行参考

万能创建 skill 总结:

1. 安装 skill-creator(skill 官方的生成技能)
2. 根据自己的需求,先让 Claude code 完成你的任务,先完成一次,然后让他根据上下文参考 skill-creator 去创建一个新的 skill
注:MCP 查询到的结果可以写入 skill,mcp 本身的调用也可以写入 skill, 哪怕我刚刚举的例子里没有也是可以做到的。比如说让它先打开浏览器,然后在浏览器里搜索北京今日天气,然后获取当前页面结构,获得到今天的天气,然后让他去创建一个 md 文档,命名为今日日期,内容为今日天气;在整个流程跑完之后,让他参考 skill-creator 去创建一个这样的一个流程 skill
3. 如果对现有的 skill 需要进行修改,那直接把 skill 文件夹拉到对话框里,然后告诉他,请你参考 skill-creator 进行修改,我需要修改的内容是:******(这里你可以修改触发条件,你也可以修改任何内容,就只要你想修改的东西都可以这样改)

二。如何创建自定义的 hooks

(我贴一下学习来源的原文链接: 25% → 90%!别让 Skills 吃灰:Hooks + Commands + Agents 协同激活 AI 全部能力:Claude Code 工程化实践_hooks + commands + agents + skills-CSDN 博客

1. 创建文件

.claude/hooks/ 目录下创建一个文件:skill-forced-eval.js

2. 编辑内容

// skill-forced-eval.js 核心逻辑 const instructions = `## 指令:强制技能激活流程(必须执行) ### 步骤 1 - 评估
针对以下每个技能,陈述:[技能名] - 是/否 - [理由]

可用技能列表:
- crud-development: CRUD/业务模块开发
- api-development: API设计/RESTful规范
- database-ops: 数据库/SQL/建表
- ui-pc: 前端组件/AForm/AModal
- ui-mobile: 移动端/WD UI组件
...(共26个技能)

### 步骤 2 - 激活
如果任何技能为"是" → 立即使用 Skill() 工具激活
如果所有技能为"否" → 说明"不需要技能"并继续

### 步骤 3 - 实现
只有在步骤 2 完成后,才能开始实现。`;

console.log(instructions);

这里把技能列表改成你自己的 skill 就行

这个 hooks 就可以大幅提升 skill 的使用率了,具体的 hooks 如何去编写,规范如何,我自己还在学习中,学习完成后续也会做教程给大家分享出来


📌 转载信息
原作者:
huanchong
转载时间:
2026/1/16 13:03:58

各位 L 站的佬友们好!

我是本坛萌新,潜水有一段时间了,一直在这个技术氛围浓厚的社区里学习。今天终于鼓起勇气发个贴,分享一个自己最近开发的练手工具,希望各位佬轻喷,也欢迎大家多提宝贵意见!

开发初衷

平时用夸克网盘比较多,但官方客户端的广告和臃肿大家都懂。加上我有自动化整理资源的需求,官方缺少 API 支持。
作为一名开发者,手痒之下就用 Go (Wails) + Vue3 + Element Plus 撸了这个第三方客户端。

目前项目已经打包了 Windows 版本(单文件绿色版),主打一个干净、无广、可编程,发出来分享给有需要的坛友们体验。

[软件分享] QuarkManager - 萌新首作,基于 Wails + Vue3 打造的夸克网盘桌面端1 [软件分享] QuarkManager - 萌新首作,基于 Wails + Vue3 打造的夸克网盘桌面端2 [软件分享] QuarkManager - 萌新首作,基于 Wails + Vue3 打造的夸克网盘桌面端3 [软件分享] QuarkManager - 萌新首作,基于 Wails + Vue3 打造的夸克网盘桌面端4

界面预览





核心亮点

除了基础的文件管理(上传 / 下载 / 重命名 / 移动等),针对像我这样的 “折腾党”,做了以下增强:

  • 多账户无缝切换:支持同时登录多个账号,一键切换,适合多号党。
  • 内置 API 服务:自带 Swagger 文档的 HTTP API(默认 8080 端口),支持外部程序调用,方便自己写脚本对接网盘。
  • Cookie 过期提醒:支持配置 SMTP 邮件通知,Cookie 快过期时自动发邮件提醒,避免自动任务挂掉。
  • 强大的分享与转存:支持批量转存带密码的链接,自动解析,支持设置分享有效期。

技术栈分享

虽然目前代码还在整理中暂未开源,但还是想和大家交流一下技术选型。
Wails 的方案在 Windows 下表现真的非常不错,利用系统自带的 WebView2,体积比 Electron 小很多,内存占用也低,Go 写后端逻辑也很舒服。

  • Backend: Go (Wails 框架)
  • Frontend: Vue 3 + Element Plus
  • API: 内置 HTTP Server + Swagger

进阶玩法:API 调用

这是我个人最喜欢的功能,开启 API 服务后,你可以直接用 curl 或者 python 操作网盘,做一些自动化的事情:

# 1. 获取文件列表
curl "http://localhost:8080/api/files?folder_id=0" # 2. 一键转存分享链接
curl -X POST http://localhost:8080/api/save \
  -H "Content-Type: application/json" \
  -d '{"share_url": "[https://pan.quark.cn/s/xxx](https://pan.quark.cn/s/xxx)"}'

访问 http://localhost:8080/swagger/ 还能看到完整的接口文档。

📥 下载与安装
目前 Release 页面已上传编译好的 quarkpan.exe,下载解压即可直接运行。

GitHub 发布页: https://github.com/dpyyds/QuarkManager/releases

⚠️ 免责声明
本软件为第三方个人开发工具,仅供学习交流,严禁用于商业用途。

使用第三方客户端可能存在风险,请大家自行评估,后果自负。

如涉及侵权请联系删除。

初来乍到,希望能融入 L 站这个大家庭。如果觉得这个小工具好用,求各位佬去 GitHub 点个 Star 🌟 支持一下,也欢迎在评论区交流 bug 和建议!

📌 转载信息
转载时间:
2026/1/16 12:59:10

更新细节摘要:

  • 支持 SSH 连接,添加远程目录为工作目录
  • 优化 ESC 中断可能会一直卡在 停止中... 的问题,本次优化调整了中断释放逻辑,并加入 双击ESC 的强制复位逃生窗口
  • 优化部分场景窗口抖动问题(再抖也没 Claude Code 抖 )
  • 支持宽屏的双列 Diffviewer
  • 修复代码库索引与终端执行工具的冲突(感谢 PR)

支持 SSH 连接,添加远程目录为工作目录 —— 操作讲解

  • 使用 /add-dir 进入面板,按 S 进行 SSH 连接
  • 支持 3 种连接方式:私钥密码网络代理方向键切换itemEnter 连接
  • 测试:@ 搜索文件目录就能看到远程目录文件,这里以 CPA 目录为例

远程工作目录可以使用的工具:

  • 文件操作(读、写)
  • 命令执行,如图:

适合远程运维,配置系统环境等

缺陷!!!

  • 首次打开文件列表因为要建立连接池,所以会稍微有点慢
  • 无法达到最优的编程效果,因为自带的 LSP、Codebase 无法用于远程,不建议用来远程编程

具体文档

宽屏的 Diffviewer 当终端宽度足够宽时,差异显示会自动变为双列显示,效果如图

本周五下午 16:00 将开放部分 Snow Console 的注册

Snow Console 是 Snow CLI 提供的限制注册人数公益站,提供 Codex 以及适用于 Codebase 功能的嵌入模型

最后:感谢 Star~


📌 转载信息
原作者:
Mufasa_Dot
转载时间:
2026/1/16 12:57:03

直接安装: app.lingkuma.org

Youtube 字幕使用教程

Tip

电脑端和安卓端 lingkuma 已经兼容原版 trancy 。
手机端必须使用内置的 lingkuma trancy,因为 safari 似乎有些问题,导致无法在 trancy 的元素上做高亮等。如果你知道如何修改请在 issues 中分享,万分感谢。

沉浸式字幕(电脑 / 手机支持)

  1. 手动选择目标语言的字幕,并启动默认字幕。

    • 更换语言,翻译等操作请在默认的字幕设置内更改,然后启动即可。
  2. 点击右侧快捷开关后即可启动

内嵌式字幕

  1. popup 中打开嵌入式字幕选项,然后刷新页面

📌 转载信息
原作者:
Claude4
转载时间:
2026/1/16 12:56:16

分享一套自研的 AI Agent 开发方法论,通过 Obsidian 管理 Spec 文档,让 AI 严格按照设计文档执行开发。核心思路很简单:

自己可能有个对系统的优化想法,通过 intent-confirmation 和 AI 对齐一下,你描述的可能不是很清楚,AI 通过这个 SKill 优化成专业一点的表达,同时确定修改范围,你觉着没问题了就进入了下面的 Spec 驱动开发流程:

先写 Spec(spec-writer)→ 用户确认 → AI 按文档执行(spec-executor)→ 审查是否符合 Spec(spec-reviewer)→ 完成归档。整个流程完全可追溯,每个功能都能追溯到 Spec 文档的具体章。

基于 MUSE 框架实现了三层记忆架构,让 AI 能够长期学习和积累经验:战略记忆存储项目级的「困境 - 策略」对,程序记忆存储可复用的标准操作流程(SOP),工具记忆记录操作完成后的固定步骤。

目前这套体系包含 12 个 Skills,覆盖了 Spec 创建、执行、更新、审查的完整闭环,还集成了 Obsidian 的双链、元数据、Callout 等特性来实现文档关联和动态索引。

GitHub 已开源,欢迎交流:GitHub - HHU3637kr/skills: 自用的一些 skills


📌 转载信息
原作者:
HHU3637kr
转载时间:
2026/1/16 12:55:57

在线合并视频画面和声音,免费用户给到了 720P,顺便让一些连接 *.googlevideo.com 被拒绝连接的垃圾 IP 也能下载视频了


📌 转载信息
原作者:
F-droid
转载时间:
2026/1/16 12:52:13

兑换码:
ABUROB

如何领取:
1️ 打开 replit.com
2️ 点击 计划升级 (Upgrade Plan)
3️ 输入 Promo Coee: ABUROB
4️ 点击 Pay/Continue

重点:
・使用最新的人工智能模型 (GPT, CLAUDE 等等)
・更高的 AI 使用额度

补个:
更新一下模型列表
OpenAI GPT-4o / GPT-5 等等
Anthropic Claude
Google Gemini
Meta Llama
Mistral、xAI Grok、DeepSeek 等


📌 转载信息
原作者:
dkly2004
转载时间:
2026/1/16 12:52:07

佬们很多问题 gpt 配置不好 今天说一下

先去

下载最新的版本
几个点要注意:

1、要重新建立 @ai-sdk/anthropic 类型 SDK 的 Provider

2、公益站要用 Codex 分组的 KEY(有的站是通用 key 可以忽略)

3、options 中我软件预设的有 "reasoning": “high”

这样就可以喽

下课!!!


📌 转载信息
原作者:
icysaintdx
转载时间:
2026/1/16 12:51:41

欢迎 star 和二次开发



CPA-Dashboard

CLIProxyAPI 控制面板 - 服务管理与账户监控 Web 界面。

功能

服务控制

  • 启动 / 停止 / 重启 CLIProxyAPI 服务

  • 实时查看服务运行状态(PID、运行目录等)

  • 查看运行日志(支持语法高亮、自动刷新)

  • 清除日志文件

账户管理

  • 显示所有账户列表

  • 显示账户类型(antigravity/gemini/claude/codex 等)

  • 显示会员等级(ULTRA/PRO/FREE)

  • 显示每个模型的配额百分比及重置倒计时

  • 配额缓存持久化(重启后保留)

  • 单个账户配额刷新

  • 批量并行刷新所有账户配额(并行度 4)

  • 按类型 / 会员等级筛选

安装


pip install -r requirements.txt

使用

方式一:直接运行


python app.py

方式二:通过启动脚本

 # 在 CPA-Dashboard 目录下

./start.sh

默认访问 http://127.0.0.1:5000

配置

程序会自动从环境变量或父目录或者自己配置查找 config.yaml 读取配置:

运行模式

  1. 本地模式(默认):直接读取 auth 目录中的 JSON 文件

  2. API 模式:设置 CPA_MANAGEMENT_KEY 后通过 Management API 获取数据

界面说明

服务控制

服务控制页面提供以下功能:

  • 服务状态:实时显示 CLIProxyAPI 服务的运行状态

  • 绿色表示服务正在运行,红色表示服务已停止

  • 显示进程 PID、服务目录、日志文件路径等详细信息

  • 服务控制:通过按钮一键操作

  • 启动服务 - 启动 CLIProxyAPI

  • 停止服务 - 停止运行中的服务

  • 重启服务 - 重新启动服务

  • 运行日志:查看服务运行日志

  • 支持自动刷新(开关控制)

  • 手动刷新、跳转底部、清除日志

账户管理

账户管理页面提供以下功能:

  • 统计概览:顶部显示账户统计信息

  • 总账户数、各类型账户数量

  • ULTRA/PRO 会员数量统计

  • 筛选功能:按条件筛选账户

  • 按类型:全部、Antigravity、Gemini、Claude、Codex

  • 按等级:ULTRA、PRO

  • 账户卡片:每个账户显示为一张卡片

  • 账户邮箱、类型标签、会员等级

  • 账户状态(活跃 / 沉默)

  • 配额信息:各模型的使用百分比及重置倒计时

  • 操作按钮

  • 刷新列表 - 重新加载账户列表

  • 刷新所有配额 - 批量并行刷新所有账户的配额信息

  • 单个账户刷新 - 点击卡片上的刷新按钮

使用说明

使用说明页面展示 API 连接信息:

  • 连接信息

  • BASE URL - API 服务地址

  • API KEY - 当前使用的密钥

  • 可用 KEYS - 可用密钥数量

  • 所有 API KEYS:列出所有可用的 API 密钥,点击复制

  • cURL 命令:提供现成的 cURL 命令示例,可直接复制使用

注意

  • 配额查询目前仅支持 Antigravity 类型账户

  • 其他类型账户只显示基本信息

  • 服务控制功能需要正确配置 CPA_SERVICE_DIR


📌 转载信息
转载时间:
2026/1/16 12:46:45

在 AI 绘画领域,我们一直在追求更快的出图速度和更低的硬件门槛。Z-image-turbo(简称 “造相”)是是阿里巴巴通义实验室于 2025 年底基于 Stable Diffusion WebUI 开发、发布的高效图像生成模型,60 亿参数、8 步采样等是其核心特性。它集成了多项加速技术,如 LCM (Latent Consistency Models) 和高效的模型与采样器,旨在实现秒级出图的极速体验。然而,高性能 AI 绘图往往需要强大的本地 GPU 支持。对于许多没有专业显卡的用户来说,这成为了一道门槛。本文将详细指导您如何利用 Google Colaboratory (Colab) 提供的免费或付费云端 GPU 资源,轻松部署 Z-image-turbo,彻底释放其速度潜力。

Z-image-turbo

文生图始终是热点,闭源这边,由 Gemini 3 Pro 驱动的 Nano-Banana Pro,几乎改变了大家对于平面设计的认知;开源方面,Flux 2.0 的开源随让图像生成效果大大提升,但过大的体量(30B+)几乎无法引起社区的关注。所以,Z-image 系列横空出世,6B 的体积以及社区量化版本的快速涌现,是大家真正能 “玩得上、玩得起” 的文生图模型。Z-image 包括多种变体,主要是三个版本:

  • Z-Image-Turbo:专注于快速推理,能够在低资源设备上高效运行,适合实时应用,支持中英文双语文本渲染(中文表现优异)。

  • Z-Image-Base:基础模型,适合开发者进行微调和二次开发。

  • Z-Image-Edit:专为图像编辑任务优化,支持根据自然语言指令进行精确编辑。

Z-image 系列已经设限,但本文示例使用的为社区 4bit 量化版本,支持 NSFW。

准备工作

在开始部署之前,请确保您拥有以下几项准备:

  1. Google 账号: 用于登录 Google Colab 并挂载 / 使用 Google Drive。
  2. 网络环境: 稳定的网络连接,以便顺利下载模型和运行环境。
  3. Hugging Face 账号 (可选但推荐): 如果您需要下载大型模型,拥有一个账号并设置好访问令牌会更方便。

首先,我们点击打开基于 4bit 量化版本 Z-image-turbo 的 jupyter 笔记本文件。

我们在 Google Colab 中,需要为 Z-image 项目分配合适的 GPU 加速资源,这是至关重要的一步:

  1. 点击打开顶部菜单栏的『修改』菜单, 选择『笔记本设置』。
  2. 在『笔记本设置』中选择 “T4 GPU” (对于免费用户,这是最佳选择) 或更高的配置(例如 A100,如果订阅了 Pro+)。
  3. 运行时类型选择 Python 3,点击『保存』。

运行时的修订也可以右上角的『连接』,在下拉菜单中选择『更改运行时类型』。


然后,在确定好提示词之后,就可以点击上方的『全部运行』开始执行顺序执行两个单元格的代码了。

运行与效率

示例不做修改,直接开始运行。需要先安装 z-image-turbo 及必要的依赖。


完成项目部署和依赖安装后,加载 Z-image-turbo,开始进行推理。


因为我们部署的是 4bit 量化版本,效率很高,1 分钟(实际推理耗时 01:07) 1 张图。至于和完全版本的质量差异,作者是无法识别并且不在意的。

结语

本文示例仅仅将量化本的 Z-image-turbo 部署在云端(Google colab),有效解决了本地硬件不足的问题。但是,很显然,我们不可能每次生成图片都需要将整个部署流程都完整跑一边,因此,如果能将 webui 部署到 google colab,通过远程访问公网 url,输入我们的图片生成指令,实时生成、显示、下载才是生产解决方案。我们后续将和大家分享如何将完整的包含 webui.py 的 Z-image-turbo 部署到 google colab,并借助 ngrok 或 cloudflare tunnel 进行内网穿透以提供公网访问的方法。


教程来自老 E


📌 转载信息
原作者:
yeahhe
转载时间:
2026/1/16 12:46:20

然后就发现了问题,用 github 托管镜像的话,国内的服务器拉取镜像速度太慢,各厂商镜像服务又有相应限制,在服务器上挂代理又有一定的风险

故而迁移一份仓库到腾讯新出的平台 CNB 上

提高国内服务器的访问速度,依旧自动更新和构建

(不过感觉腾讯给的免费对象存储额度不太够)

忘了给链接了


📌 转载信息
原作者:
AliverAnme
转载时间:
2026/1/16 12:46:09

Hello 佬们晚上好啊~又是瓦砾酱
喜欢的深夜更新,这两天抱歉占用大家资源来看我又哭 & 又笑了.
AionUi V1.7.0 Cowork 的版本发了,欢迎大家升级反馈、吐槽(能惦记着就很感恩了)

历史版本介绍,不了解 AionUi 的佬友可以从这儿开始看👇

AionUi V1.7.0 新特性介绍

1- 内置 Cowork,默认开启开箱即用

2- 内置多个 Assistant,在设置中随心启用

到设置界面启用想要的助手


启用后,新对话就可以直接使用啦

3- 内置助手可编辑 Agent,Rule,Skills

点击任意助手,即可打开助手详情进行编辑。下个版本会支持大家自己创建,现在创建界面实在是没想好咋处理,AI 写的丑死了,先暂时屏蔽了 w~

这次就更新了这么多,而且我已经用出 Bug 了… 有点匆忙,期望大家轻轻喷。


然后关于反馈群的事儿,我还不知道 L 站允不允许拉微信群啥的,我担心不符合社区规范,我谨慎研究下再回复大家吖,谢谢大家的包含


好像点赞到每日上限了,今天欠大家的明天补上(不是我不理你嗷


📌 转载信息
原作者:
waili
转载时间:
2026/1/16 12:41:42