网站部署SSL证书的重要作用如下：

　　1.SSL证书可加密敏感信息使其不被泄露

　　使用SSL证书的主要原因是为了保障通过Internet发送的敏感信息能够加密，防止重要数据不被泄露。这很重要，因为您在Internet上进行计算机与服务器之间的信息传递，如果未使用SSL证书加密，则您传递的任何信息都有可能被第三方获取，包括您的信用卡号，用户名和密码以及其他敏感信息。使用SSL证书后，可以保障所有人都无法读取信息，这可以保护信息数据免受黑客或者用心不良的人的侵害。

　　2.SSL证书可提供身份验证，防止钓鱼网站

　　除信息加密外，SSL证书可提供身份验证。这意味着您可以确保将信息发送到正确的服务器，不用担心别人窃取您的信息。有效的防止第三方伪装成您的网站并欺骗您的用户，获取用户个人信息，造成或大或小的损失。而SSL证书是由受信任的CA机构颁发的，申请证书时会严格的验证企业/组织的信息。所以说，选择受信任的CA机构颁发的SSL证书非常的重要，CA机构会通过各种信息的验证才会颁发SSL证书，而且EV SSL证书需要比其他证书更多的验证资料。

　　3.SSL证书可增加信任度

　　安装SSL证书的网站在Web浏览器的地址栏可显示，绿色小锁图标，绿色地址栏，EV SSL证书还能显示企业/组织名称。以确保访问者知道其连接是受到保护的，可放心使用。这意味着当访问者看到这些提示信息会更信任您的网站。而且可以查看CA机构的颁发信息，以便为您的客户提供的更多信任。

　　HTTPS还可以防止网络钓鱼攻击。网络钓鱼电子邮件是冒充您网站来进行犯罪的，钓鱼电子邮件通常包含指向其网站的链接或使用中间人攻击来达到目的。由于这些违规现象无法获得正规CA机构颁发的SSL证书，因此他们无法完全冒充您的网站。这意味着您的用户陷入网络钓鱼网站的可能性很小。

现代制造业中，工艺路线 定义了产品从原材料到成品的完整加工路径，当产品种类繁多时，逐个手动录入工艺路线效率就显得低下，并且容易出错。
在APS排产系统里，工艺路线模块为产品生产的每个步骤流程搭建起了清晰明确的路径。利用工序模板进行批量配置，也就是说通过下载模版填写后批量导入的方式，能快速实现多工艺路线的配置。
在开始批量配置前，先理解两个核心概念：
• 工序模板：这是批量配置的基石。它好比标准化的“工序组件库”，将一道工序所需的资源、时间、前后逻辑关系（如ES：前工序结束后工序才能开始；EE：前工序未结束后工序可提前开始）等进行预定义。确保所有需要用到的工序模板已提前在系统中创建并审核通过。
• 工艺路线：它是由多个工序模板按生产顺序“连线”组合而成的完整生产流程。批量配置的本质，就是通过结构化数据（Excel模板）快速建立产品与工序序列之间的关联。

批量配置详细操作流程

1、配置所涉及到的工序模版，为工艺路线打基础（工艺路线是工序模版所构成）。

2、点击【工艺路线建模】，选择下载模版按钮下载Excel表格。

3、模版下载后分为两个板块，一个是【工艺路线】，一个是【工序主资源】。其中工艺路线即是指定该产品的具体路线是如何的，工序主资源即是指定哪道工序具体涉及哪些主资源。

4、【工艺路线】sheet页主要有物料编码、工序编码、工序名称、工序序号、模版工序编码。物料编码即是成品的编码，指定该工艺路线为哪个产品的工艺路线，即配产品的物料编码于此。工序编码即生产该产品时需要的对应工序的编码，可与模版工序编码保持一致，即引用已建好的模版。工序名称和工序模版的工序名称保持一致，工序序号即是谁为第一道工序，谁为第二道工序。分别用数字1、2、3、4等进行排列。以下为示例。

5、工序主资源涉及字段为物料编码、工序编码、工序序号、主资源编码、产能。物料编码和工序编码序号与前面工艺路线保持一致即可，后面的主资源编码和产能就按照实际情况。分别设置在该工序环节时需要的设备主资源以及对应产能具体值。

6、设置好后保存，点击导入即可。

​ 提高游戏服务器的安全性和防护机制对于保护玩家数据、游戏平衡性和用户体验至关重要。我们可以从服务器端安全、数据安全、DDoS防护、日志监控等方面来提高游戏服务器的安全性。

服务器端的安全是比较重要的一点。建议用户及时更新游戏服务器和操作系统的补丁和安全更新，以修复已知的漏洞和安全问题。在安全配置方面，可以通过配置服务器端防火墙、入侵检测系统(IDS)、入侵防御系统(IPS)等安全设备，限制对服务器的访问和保护敏感数据。同时，也可以使用SSL/TLS等加密协议保护游戏服务器和客户端之间的通信，防止数据被窃取和篡改。最后也可以限制对服务器的远程访问和管理权限，采用多因素身份验证等安全措施保护管理员账号。

数据安全防护也比较重要，主要体现在数据加密、反作弊系统及数据验证三个方面。对存储在服务器上的敏感数据(如用户密码、个人信息)进行加密存储，保护数据不被恶意获取。部署反作弊系统和游戏防作弊引擎，检测和阻止作弊行为，维护游戏的公平性和平衡性。对客户端发送的数据进行严格验证和过滤，防止恶意数据包和数据篡改攻击。

DDOS攻击防护也很重要，使用DDoS防护服务提供商提供的流量清洗服务，过滤和屏蔽DDoS攻击流量，保护服务器免受攻击。配置网络设备和防火墙，限制并发连接数、数据包频率等参数，减缓DDoS攻击对服务器的影响。使用CDN(内容分发网络)服务来分发游戏内容和数据，减轻游戏服务器的负载和DDoS攻击压力。

日志记录和监控也是提高游戏服务器安全性的重要步骤，定期记录游戏服务器的运行日志和安全事件日志，以便分析和调查安全事件。配置实时监控系统监控服务器的性能和安全状态，及时发现异常行为和安全威胁。

最后，需要进行定期漏洞扫描和渗透测试，定期对游戏服务器进行漏洞扫描和安全评估，发现并修复潜在的安全漏洞和弱点。进行定期的渗透测试，模拟黑客攻击和渗透行为，评估游戏服务器的安全性和弹性。

渗透测试（德迅云安全）

● 安全性漏洞挖掘

找出应用中存在的安全漏洞。安全应用检测是对传统安全弱点的串联并形成路径，最终通过路径式的利用而达到模拟入侵的效果。发掘应用中影响业务正常运行、导致敏感信息泄露、造成现金和信誉损失的等的漏洞。

● 漏洞修复方案

渗透测试目的是防御，故发现漏洞后，修复是关键。安全专家针对漏洞产生的原因进行分析，提出修复建议，以防御恶意攻击者的攻击。

● 回归测试

漏洞修复后，对修复方案和结果进行有效性评估，分析修复方案的有损打击和误打击风险，验证漏洞修复结果。汇总漏洞修复方案评估结果，标注漏洞修复结果，更新并发送测试报告。

综上所述，提高游戏服务器的安全性和防护机制需要综合考虑网络安全、数据安全、防作弊、DDoS攻击防护、日志和监控、社区管理等多个方面，采取多层次、多维度的安全措施和防护策略，确保游戏服务器的稳定运行和用户数据的安全保护。

大模型虽已具备强大的感知与推理能力，但在面对复杂的计算机图形界面操作（Computer Use）任务时，仍受限于高质量数据稀缺与环境交互反馈缺失的双重挑战。美团技术团队推出了 EvoCUA 模型并在Github、Huggingface开源，通过构建可验证数据合成引擎与十万级并发的交互沙盒，将训练范式从传统的“静态轨迹模仿”转变为高效的“经验进化学习”。该方案在权威评测基准 OSWorld 上以 56.7% 的成功率刷新了开源 SOTA（2026年1月6日榜单），验证了基于经验的进化范式在 GUI 智能体领域的有效性。

01 背景与挑战

随着大模型的发展，AI 已经具备了强大的感知与推理能力。但在真实的使用场景中，我们希望 Agent 不仅能回答问题，更能解决问题——比如自动处理 Excel 表格、在浏览器中完成复杂的资料检索或跨应用协同。这种对解决问题能力的追求，推动了基础模型从 Chat（对话者）到 Agent（行动者） 的转变。

在这一进程中，Computer Use Agent（CUA，计算机操作智能体） 是一个关键里程碑。CUA打破了 API 的限制，构建了一种原生的交互方式——像人类一样，通过高分辨率视觉感知屏幕，并利用鼠标键盘完成跨应用的长链路任务，有可能成为下一代操作系统的核心交互入口。

然而，要训练出一个通用的 CUA，我们面临着严峻的数据扩展（Data Scaling）瓶颈。当前主流的训练范式依赖于对专家轨迹的模仿学习，但在将其推向工业级可用时，这种方式面临着三大挑战：

• 数据合成质量低： 真实的高质量轨迹数据极度稀缺且昂贵，而试图用大模型直接生成数据往往会陷入“幻觉”。模型生成的指令或计划经常看似合理，但在真实的 UI 状态下根本不可执行。
• 缺乏交互反馈： 静态数据模仿学习只能告诉模型“什么是对的”，却无法告诉它“如果点偏了会发生什么”。缺乏在大规模环境交互中产生的反馈，模型就无法捕捉操作与环境变化之间复杂的因果动态，难以适应真实环境中渲染差异、网络延迟等随机扰动。
• 长链路探索效率低：计算机操作往往涉及数十步甚至上百步的连续决策，无约束的探索空间巨大且低效。仅靠简单的模仿学习，模型很难学会如何从中间的错误状态中反思并纠错。需要一种更高效和可扩展的范式，让模型专注于从海量自身成功和失败的经验里学习和进化。

面对上述挑战，我们正式推出了 EvoCUA， 一种原生的计算机操作智能体模型。EvoCUA致力于构建一种进化范式，让模型在大规模沙盒环境中，像生物进化一样，通过不断的试错，反思和修正，积累海量成功和失败经验，进而不断提升自身能力。

通过这一范式，EvoCUA-32B 在 Computer Use权威的在线评测基准 OSWorld 上取得了 56.7% 的成功率，刷新了开源模型的 SOTA 记录，以更少的参数量和推理步数超过此前的开源SOTA OpenCUA-72B （45.0%），以及领先的闭源模型UI-TARS-2 （53.1%）。此外，实验证实该方案的通用性，在不同基座（如 Qwen3-VL、OpenCUA）及多个尺寸（8B 至 72B）的模型上均能显著提升 Computer Use 能力 。

模型上网查询如何配置rbenv开发环境并帮用户安装的示例：

02 核心技术架构

EvoCUA 的核心在于构建“交互-反馈-修正”的闭环。我们针对数据、环境、算法三个维度构建了自维持的进化架构：可验证数据合成引擎负责生产高质量任务，高并发交互基建支持海量轨迹合成，基于经验的迭代算法提供模型进化的关键路径。

2.1 可验证数据合成引擎

EvoCUA 数据层的核心任务是构建一个自动化流水线，能够合成覆盖各个垂直领域的高质量任务指令。我们要求合成数据要满足两个指标：

• 场景完备性：覆盖从文档办公、Web 检索到系统管理的全场景操作。
• 执行确定性：每一条数据必须在真实环境中可执行、可验证，杜绝逻辑幻觉。

在实现这一目标时，我们发现业界通用的“大模型生成 + Reward Model (RM) 筛选”范式在 Computer Use 场景下存在本质缺陷：

• 语义与执行的割裂：传统的 RM 基于语义匹配打分，只能判断生成的指令在文本层面是否合理，无法验证其在物理层面能否执行。
• Reward Hacking：模型倾向于生成逻辑通顺但包含“幻觉”的指令（例如点击不存在的 UI 元素）。这些不可执行的任务会引入大量训练噪音，导致模型在真实操作中产生严重的错误累积。

为了解决数据可信度问题，我们提出了 “生成即验证” 范式，在生成自然语言指令的同时，同步生成可执行的验证代码，并以沙盒中的实际运行结果作为判断数据是否有效的唯一标准。

整体数据合成框架如下：

2.1.1 结构化任务空间构建

在构建任务空间时，我们并未盲目堆砌数据，而是基于对 GUI 操作本质的两个核心洞见：

• 原子能力的可迁移性与泛化性：GUI 操作虽然千变万化，但其底层的“原子技能”是跨域复用的。例如，“数据筛选”这一能力，无论是在 Excel、CRM 系统还是网页后台中，其逻辑内核是同构的。
• 复杂任务的组合本质：真实世界中的复杂任务，本质上是由有限的原子能力通过特定逻辑编排而成的序列。掌握了原子能力的组合方式，就等于掌握了生成无限复杂任务的“语法”。

基于这两点思考，我们采用分层构建策略来初始化任务环境。

• 原子能力拆解：我们将复杂的桌面操作任务解构为标准的原子能力单元。基于分层领域分类体系，例如将“Excel 财务分析”任务拆解为“公式计算”、“多列排序”、“透视表生成”等子技能。

• 资源文件合成：为了模拟真实环境的复杂性，我们在环境初始化阶段实施了两种资源生成策略。

  • 参数化合成：针对结构化数据（如销售报表），我们利用代码生成器批量生产 Word/Excel 文档，随机化其中的姓名、价格、日期等参数。
  • 非参数化合成：针对非结构化数据，我们直接注入无版权问题的互联网上的公开资源（如真实的图片、音频、复杂的 PPT 幻灯片），强迫 Agent 处理真实世界中不可预知的视觉噪声和布局多样性。

2.1.2 指令和验证器合成

我们构建了基于 ReAct 的 Agentic 数据合成工作流。当给定一个场景元组（角色、能力、资源）后，作为任务架构师的基础 VLM 会启动生成：

• 指令：生成符合用户意图的自然语言指令，确保任务目标清晰且在当前资源环境下可达成。
• 验证器：同步生成对应的可执行验证Python验证代码以及标准答案（以文件/配置项等形式存在）。这段代码定义了任务成功的精确条件（例如：检查某个单元格的值是否为 X，或某个文件是否存在）。

不仅如此，我们还引入了沙盒执行反馈机制。生成的验证代码会立即在真实沙盒中运行。如果代码报错（如 API 错误、语法错误），错误日志会被回传给任务架构师进行自我修正。这个过程会迭代多轮，直到验证器本身能够成功运行并通过质量检查。

2.1.3 质量保障与去污

为了确保入库数据的纯净度，我们在数据落盘前设置了严格的过滤机制。

• 一致性过滤：我们部署了一个测试Agent模型对合成任务进行试跑。通过比对“沙盒实际执行结果”与“验证器判定结果”，我们能精准识别出假阳性（False Positives）数据——即任务其实没做对，但验证器误判为成功的案例。只有那些经得起沙盒检验的数据才会被保留。

• 三重去污染：用于合成数据的模型本身见过大量的预训练语料包含大量世界知识，大规模构造合成数据时，有混入和 Benchmark 有一定相关性的数据的风险。为了防止测试集泄露，我们实施了三重去污策略：

  • 语义去重：使用 LLM 过滤掉与 基准测试集在语义上高度相似的指令。
  • 配置去重：剔除与测试集具有相同初始化设置（如完全一致的文件名或窗口布局）的任务。
  • 验证器去重：检查生成的验证逻辑和 Ground Truth 文件，确保没有直接照搬测试脚本。

通过这套数据合成框架，我们成功将可验证的训练数据规模扩展到了数万量级，突破了人工标注的瓶颈。

2.2 支撑十万级沙盒并发的基础设施

EvoCUA 的进化范式要求 Agent 进行大规模的探索来合成经验轨迹。我们面临的挑战是工业级的：如何在一个集群中稳定调度 100,000+ 个每日活跃沙盒，处理百万级的分钟交互请求，同时保证每个环境的严格隔离与毫秒级响应。为此，我们构建了一套统一的环境沙盒平台，在调度吞吐与环境保真度两个维度做了大量优化。

2.2.1 微服务化编排

为了消除大规模强化学习中的 I/O 瓶颈，我们将传统的单体模拟器重构为基于微服务的异步架构。

异步 I/O 网关： 面对百万级交互请求，传统的阻塞式架构已无法支撑。我们采用了基于 Reactor 模式的异步非阻塞 I/O 设计网关架构，实现了 数百万 QPM（Queries Per Minute）的路由吞吐能力，并且将控制面（生命周期管理）与数据面（环境交互流）彻底解耦，确保长周期的环境执行（如打开一个重型 App）不会阻塞关键的路由逻辑，极大地提升了系统的吞吐上限。

沙盒批量急速启停： 强化学习的采样阶段具有极强的“脉冲”特性（短时间内需求激增）。我们的分布式调度器通过分片与资源池化技术，实现了极速冷启动能力。通过该优化，系统能够在 1 分钟内拉起 10,000+ 个沙盒实例。这种“即需即供”的弹性能力，确保了环境供给严格匹配训练需求，最小化了策略更新与经验采集之间的延时，保证了训练的高效流转。

2.2.2 保真环境构建

在解决了“量”的问题后，更关键的是“质”。Computer Use 任务对环境的确定性要求极高，微小的渲染差异或键位冲突都会导致模型训练非最优。

• 混合虚拟化架构：为了兼顾容器编排的灵活性与虚拟机的强隔离性，我们采用了 Docker 容器嵌套 QEMU-KVM 的混合架构。

  • 外层：使用 Docker 对接 K8s 调度体系，复用美团成熟的容器化运维能力。
  • 内层：利用 KVM 硬件加速运行 QEMU 虚拟机。
  • 价值：这种设计既提供了内核级的安全隔离（防止 Agent 执行恶意代码穿透宿主机），又保证了接近原生的 GUI 渲染与 I/O 性能。

• 操作系统级校准：标准 OS 镜像在自动化操作中存在诸多“隐形坑”，导致仿真环境与真实世界存在 Gap。为此，我们深度定制了 Ubuntu 22.04 镜像，实施了内核与用户态的双重补丁：

  • 输入确定性： 标准虚拟化常存在键位映射冲突（例如 US 键盘布局下 Shift + <状态丢失）。我们深入内核层修改了xkb的符号定义，确保 Agent 的符号意图与实际输入严格一致。
  • 渲染一致性： 视觉 Agent 对字体布局极其敏感。我们在系统层注入了全套专有字体库并强制刷新fc-cache，消除了文档在仿真环境与真实环境下的视觉渲染差异，防止模型因环境噪音而产生错误的视觉关联。

2.3 基于经验的学习范式

有了可验证的数据和高吞吐的环境，我们的核心目标是如何让模型像人类一样学习：要在大量的自我实践中巩固成功经验，并从失败中吸取教训。然而，单纯依赖静态数据的监督微调存在两个本质缺陷：

• 分布偏移：训练数据的分布往往是“完美路径”，而推理时的环境充满了随机性。模型一旦偏离了专家轨迹，就不知道如何回到正轨。
• 负反馈缺失：SFT 只能告诉模型“怎么做是对的”，却从未告诉它“怎么做是错的”以及“错在哪里”。

EvoCUA 提出了一种渐进式的进化范式，将训练过程解耦为三个阶段：冷启动（注入先验思维模式）、拒绝采样微调（动态算力分配，巩固成功经验）、强化学习（聚焦关键出错点，从失败经验中学习）。

2.3.1 Cold Start: 冷启动

在让 Agent 进入大规模环境进行自由探索之前，给模型注入一些思维pattern，能够提高模型的有效探索能力。为了摸清当前 Agent 能力的边界，我们深入分析了 Qwen3-VL-Thinking、OpenCUA-72B 等主流模型推理轨迹。我们发现，各家模型均有一定缺陷。例如：OpenCUA-72B 很容易提前误判成功，而Qwen3-VL模型在动作空间上存在一些明显缺失（如不支持Shift+Click）。基于此，EvoCUA 在冷启动阶段的核心任务，是定义一套完备的动作空间与严谨的思维范式。

• 完备的动作空间：处理复杂操作，如 Excel 中的 Shift + Click。如果是原子的press操作，无法表达这种持续按压的状态。为此，我们将按键拆分为key_down 和key_up。

• 结构化思维链：为了避免“幻觉”和“伪成功”，我们给模型注入了一些像人类一样的优秀思维范式：

  • 目标澄清：在初始时刻，强制模型复述并拆解用户意图，消除指令歧义。
  • 观测一致性：简短且精准，严格对齐当前的视觉元素，防止“看图说话”时的幻觉。
  • 自我验证：在发出Terminate信号前，模型必须执行显式的检查步骤。例如在发完邮件后，进入“已发送”文件夹确认，而非盲目自信。
  • 反思与纠错：针对采集到的失败轨迹，我们识别出状态偏离的关键分岔点，从错误发生后的那一步恢复环境状态，通过 Prompt 引导和高温采样让模型自我修正。
  • 终止判断：Terminate动作必须强依赖于前序的 CoT 论证。如果思维链中没有明确的完成证据，模型不得输出结束信号，以此抑制“伪成功”。
• 后见之明数据合成：在训练数据构造上，我们不直接使用模型的原始 CoT。对于成功轨迹，我们采用“后见之明”策略——基于正确的 Action 序列反向重写逻辑严密的思维链；同时混入不可完成任务，教会模型识别环境边界，学会说“No”。

经过冷启动训练后，模型展现出了明显的行为范式转变。它不仅掌握了终端和复杂快捷键的操作，更重要的是学会了“慢思考"——在关键节点进行校验和反思。这为后续的大规模进化提供了坚实的原子能力基础。

2.3.2 RFT：拒绝采样微调

冷启动赋予了模型基础的原子能力，接下来的挑战是如何在万级 Query 上进行 Scaling。我们面临的核心权衡是：如何在有限的算力预算下，最大化高质量经验的产出效率与信噪比？如果对所有任务平均用力，会导致简单任务算力浪费，而困难任务探索不足。为此，EvoCUA 设计了一套“阶梯式动态算力分配 + 步级别去噪”的拒绝采样微调策略。

阶梯式动态算力分配：为了最大化探索的 ROI，我们将 Query 池划分为不同难度层级，并实施阶梯式的 Rollout 策略。我们将采样次数 K 划分为多个档位 {3, 8, 16, 32, 64}，并为每个档位设定了成功率阈值（如 100%, 75%, 50%...）:

• 自适应爬坡：模型从低 K 档位开始尝试。如果在当前档位的成功率达到了预设阈值（说明模型已掌握），则立即停止采样；反之，若成功率较低，则自动升级到下一档位，投入更饱和的算力进行攻坚。
• 边界突破：这种机制确保了算力被集中投放到模型处于能力边界的困难任务上，而非在已熟练的任务上重复“造轮子”。

步级去噪：模型生成的原始轨迹即使成功了，也往往包含大量噪声（如无效的鼠标滑动）。直接学习这些数据会污染模型。我们实施了精细化的清洗策略：

• 冗余和错误步骤过滤：利用 Judge Model 分析成功轨迹，识别并掉对最终结果无贡献的冗余步骤，显著提升了数据的信噪比。
• Infeasible 任务特判：针对不可完成的任务，成功的轨迹往往伴随着大量的无效尝试后才终止。对于这类数据，我们仅保留最后一步（即正确输出Terminate=Failure 及对应的推理），将中间所有的试错步骤全部剔除。

通过 RFT，我们将大规模的合成经验内化为模型参数，显著提升了模型在常规路径的执行成功率。

2.3.3 RL：强化学习

RFT 夯实了模型在常规路径上的执行成功率，但面对长链路任务中的环境扰动（如弹窗、网络延迟、布局微变），模型依然脆弱。相比于成功轨迹中模型已有的知识，失败轨迹中蕴含着广阔的、非线性的树状结构信息，模型往往会在一些关键步骤出错，正是模型能力边界的直接体现。

传统的 RL 算法通常以整条轨迹为粒度，存在严重的信用分配难题——几十步的操作中可能只有一步是错的，全盘否定会导致有效经验被浪费。

为了解决这一问题，我们提出了一种面向Computer Use的高效DPO算法，将优化粒度从“轨迹级”下钻到“关键分岔点” ， 重点解决模型在出错边缘的能力边界感知问题。

关键分岔点挖掘：在长达数十步甚至上百步的 GUI 操作中，任务失败往往具有滞后性。模型可能在第 5 步做出了一个微小的错误决策（如选错了筛选条件），但直到第 30 步才因为找不到目标文件而报错。为了精准定位错误，EvoCUA 提出了一种基于参考导向的归因机制——关键分岔点挖掘。 我们利用同一 Query 下的“成功轨迹”与“失败轨迹”进行对齐分析。系统会自动定位到状态一致但动作开始偏离的那一帧，记为关键分岔点。

双范式偏好对构建：一旦通过因果诊断锁定了关键错误，我们并未止步于简单的行为克隆，而是针对出错瞬间”和“出错之后”两个不同的时空切片 ， 构造了两种截然不同的 DPO 偏好范式，从而在一次训练中同时兼顾了准确性与鲁棒性。

• 范式一：动作修正，此范式聚焦于“即时纠错”，旨在教模型在关键分岔点(t时刻)必须“走正道”。我们将导致后续失败的原始错误动作作为负样本；对于正样本，我们优先尝试通过 VLM 语义匹配，将成功参考轨迹中的“正确思考与动作”迁移过来。如果参考轨迹无法对齐，则调用VLMs模型基于当前视觉状态合成全新的正确动作。
• 范式二：反思与恢复，此范式聚焦于“错误恢复”，旨在提升模型在错误发生后（t+1 时刻）的反思修正能力。在这一时刻，环境状态通常已经因为前一步的错误而发生了偏离（如出现了预料之外的弹窗）。我们把模型无视环境变化、机械执行原计划的“盲目继续”行为标记为负样本；同时，利用 Prompt工程引导模型生成一条“反思链”作为正样本——即教导模型在发现状态异常时，优先选择停下来，观察屏幕异常并重新规划，而不是一条道走到黑。

通过这两个范式的结合，模型不仅教会了 Agent 如何做对，更教会了它在做错或环境突变时如何反思修正。随着能力的不断提升，上述RFT和DPO可以进行多轮迭代训练。

除了DPO，我们在实践中还探索了online RL，通过主动的环境交互，模型表现出了持续的奖励增长趋势，会在下一个版本的模型中更新。

总而言之，我们通过“双重机制”将海量的合成经验高效内化为模型参数：一方面利用 RFT 来夯实基础的执行范式，确保模型在标准任务上的发挥稳定；另一方面利用 RL在复杂的长尾场景中主动纠错，显著提升模型在能力边界上的鲁棒性与泛化力。

03 实验评估

为了验证 EvoCUA 范式的有效性，我们在权威在线榜单OSWorld上进行评测。实验的核心结论如下：EvoCUA-32B 以 56.7% 的成功率刷新了开源模型 SOTA，并在同等推理预算(max step=50)下逼近了闭源模型 Claude-4.5-Sonnet (58.1%) 的水平；同时验证了该进化范式在不同规模模型上的普适性。

3.1 OSWorld 评测

• 开源SOTA：我们的主力模型 EvoCUA-32B（基于 Qwen3-VL-32B-Thinking 后训练）达到了 56.7% 的成功率。这一成绩大幅领先此前的开源 SOTA（OpenCUA-72B, 45.0%）。值得注意的是，EvoCUA-32B 超越了闭源强基线 UI-TARS-2-2509 (53.1%)。在严格限制 50 步 推理预算的同等条件下，我们与行业顶尖的 Claude-4.5-Sonnet (58.1%) 差距缩小至仅 1.4%。
• 小参数大潜力：EvoCUA-8B 同样表现惊艳，以 46.1% 的成功率击败了 OpenCUA-72B。与同样基于Qwen3-VL-8B训练的Step-GUI-8B (40.2%) 相比，EvoCUA-8B 取得了 +5.9% 的显著优势。

3.2 消融实验

为了探究 EvoCUA 性能提升的来源，我们进行了逐层拆解的消融实验。

• 统一动作空间 （+4.84%）：通过完善动作空间带来的提升。
• 冷启动（+2.62%）：注入高质量的行为先验，确立了思维与行动的对齐。
• RFT 拒绝采样（+3.13%）：通过动态算力巩固成功经验，在不损失pass@k能力基础上，提升模型的pass@1能力。
• Offline DPO（+3.21%）：针对关键分岔点的纠错训练，显著提升了模型鲁棒性。
• 迭代训练（+1.90%）：再进行一轮迭代训练，性能持续增长。

3.3 Scaling分析

我们进一步验证了 EvoCUA 的 Scaling Law。

• Max Step：随着推理时步数的增加，我们观察到模型的性能在不断提升。但由于我们数据中超过50步的样本较少，因此大于50步的边际收益收窄。
• Pass@k：随着采样次数k的增加，EvoCUA 始终保持对初始化模型的显著优势。这表明优化后的 Policy 具有更高的天花板。
• 数据规模：在 RFT 阶段，我们将数据量从 20k 扩展到 1M，观察到了持续的性能爬坡。

3.4 轨迹可视化分析

我们随机抽样一条合成指令任务，对训练后的模型采样轨迹进行可视化。以一个电子表格任务为例：“找出每行的最大值并填入 G 列”，以下是EvoCUA-32B在四个关键时刻的思考与执行过程：

Step 1：目标澄清，智能体显式复述并拆解了用户指令。

Step2：智能体使用excel公式原子能力Max操作。

Step 9：有状态鼠标交互，专业软件操作常涉及“按住并点击”等组合动作。智能体执行“Shift+点击”操作以选中 G3 到 G11 的数据范围。

Step 15：审慎终止判断，智能体没有盲目停止，而是先生成视觉证据：“我看到 Max 列已计算完毕...”。只有在视觉核验结果符合初始指令后，它才发出terminate信号，确保任务完成。

04 总结展望

EvoCUA，一个基于经验进化范式的原生 Computer Use Agent。通过可验证的合成引擎、可扩展的交互基建和可进化的经验学习算法，我们探索出一条提升Computer Use能力的通用方法。在 OSWorld 基准测试中，EvoCUA 以 56.7% 的成功率刷新了开源模型的 SOTA，证明了这条路径的有效性。在超过 100 万卡时的上千组实验中，我们总结了四条关键的洞察，希望能为社区提供参考：

• 高信噪比数据是关键： 成功轨迹是低噪声但低信息量的，失败轨迹是高噪声但高信息量的。如何处理好数据，保证较高的信噪比是模型能力持续提升的关键。
• 先验 Pattern 重于数据量：冷启动阶段，Pattern 的多样性远比数据量重要。一个轻量级但覆盖全原子能力的冷启动，比大量低质量数据的 SFT 更能为后续的 RL 打好基础。
• On-Policy 的重要性：在长链路任务优化中，要严格使用 On-Policy 数据。一旦过度使用 Off-Policy 数据，会导致优化方向偏离原始模型主分量，且较难恢复。
• 可视化驱动的迭代：数据和算法之外，我们开发了大量用于轨迹可视化和 Debug 的分析工具，一套全流程可视化诊断工具对于数据质量校验、轨迹对比分析和问题发现至关重要。

尽管取得了阶段性突破，我们必须承认，当前开源模型与顶尖闭源系统（及人类水平）之间仍存在显著差距。这一差距揭示了单纯依赖离线合成轨迹的性能天花板。我们认为，打破这一瓶颈的关键在于在线强化学习。我们初步的实验信号显示，通过主动的环境交互，模型表现出了持续的奖励增长趋势。未来的工作将聚焦于系统性地拓展这一在线进化边界，最终实现完全自主的计算机操作能力。

目前，EvoCUA 现已全面开源，欢迎访问项目主页获取更多信息：

• Github: https://github.com/meituan/EvoCUA
• Huggingface：EvoCUA-32B、EvoCUA-8B
• Technical Report：PDF

| 关注「美团技术团队」微信公众号，阅读更多技术干货！

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至 tech@meituan.com 申请授权。

大家好，我是R哥。

最近 Claude Skills 又开始爆火了，几个月前我分享《MCP 不香了，Claude Code 又推出了 Skills！！（保姆级安装和使用教程分享）》时还是不温不火，现在已经火爆全网了。

经过几个月的发展，Skills 也有了些许变化，这篇我再结合最新的信息，分享下 Skills 的概念及如何在 Claude Code、CodeX、OpenCode 中创建和如何 Skills。

万字干货，避免错过，建议收藏慢慢看。。

Skills 是什么？

Skills 最初由 Anthropic 公司开发，专门用来扩展 Claude 功能的模块化能力。

说白了，Skills 其实就是一个文件夹，这是每个 Skills 的目录结构：

my-skill/
    ├── SKILL.md          # 必选：指令、元数据
  ├── scripts/          # 可选: 执行脚本
  ├── references/       # 可选：参考文档
  └── assets/           # 可选：模板、资源

每个 Skill 包含指令、元数据和资源等，只有当 Claude 认为某个 Skill 和当前任务相关时，它才会启用，即按需加载，从而提升性能，也能大大节省 Tokens 消耗。

现在 Anthropic 已经把 Skills 做成《Agent Skills》开放标准了：

https://agentskills.io/

这是一个 Skills 开放标准，由 Anthropic 发布并推动作为开放标准，旨在让不同 AI 平台都能实现一个通用的 “Agent Skills” 格式。

Anthropic 真是 AI 标准的制定者，前有 MCP 协议，现在又弄出了 Agent Skills 标准。

Agent Skills 现在已经被主流的 AI 开发工具全面支持了，我看 OpenAI、Google、Cursor 等 AI 厂商都已经跟进并支持 Skills 了。

比如，我刚在 Claude 写完 Skills，直接就可以复制到 CodeX 中使用，100% 兼容。

Skills 的架构

Skills 在代码执行环境中运行，它具有文件系统访问、bash 命令和代码执行功能。

这是 Skills 的架构图：

可以这样理解，Skills 相当于是虚拟机上的目录，Claude 可以使用计算机上导航文件相同的 bash 命令与它们交互。

Skills 的工作原理

Skills 是通过渐进式披露来高效管理上下文，这张图演示了 Claude 如何加载和使用 PDF 处理 skill 的方式：

这种动态加载方式，确保只有相关的 Skill 内容占据上下文窗口。

工作流程

第 1 步：发现 Skills（始终加载）

Claude 在启动时，代理只会加载每个可用技能的 SKILL.md 中的元数据，比如：名称和描述，用来判断它什么时候可能用得上。

元数据格式如下：

---
name: pdf-processing
description: 从 PDF 文件中提取文本和表格、填充表单、合并文档。在处理 PDF 文件或用户提及 PDF、表单或文档提取时使用。
---

这种轻量级的加载方式，意味着我们可以集成大量的 Skills 而不会产生上下文成本，Claude 只知道每个 Skill 的存在以及何时使用它。

第 2 步：激活 Skills（触发时加载）

当任务匹配到某个技能的描述时，代理才会把完整的 SKILL.md 指令加载进上下文里。

参考指令如下：

# PDF 处理

## 快速入门

使用 pdfplumber 从 PDF 中提取文本：

```python
import pdfplumber

with pdfplumber.open("document.pdf") as pdf:
    text = pdf.pages[0].extract_text()
```

有关高级表单填充，请参阅 [FORMS.md](FORMS.md)。

SKILL.md 的指令包含 Skills 的运行逻辑，包括它的：工作流、最佳实践和规范等，其实就是一个提示词说明书文档。

第 3 步：执行 Skills（按需加载）

代理会按照 SKILL.md 中的指令来操作，必要时还会加载 references 目录中引用的文件，或者运行 scripts 目录下打包好的脚本及代码。

Skills 通过渐进式披露这种方式，可以让代理按需调取更多上下文，从而执行得飞快。

渐进式披露成本

渐进式披露确保任何给定时间，只有相关内容占据上下文窗口，这是它的成本：

SKILL.md 的文件结构

每一个 Skill 都必须要有一个 SKILL.md 文件，它是一个 Markdown 格式的文件，包含 YAML 前置元数据和 Markdown 指令。

参考格式如下：

---
name: your-skill-name
description: 简要描述此 Skill 的功能以及何时使用它
license: Apache-2.0
metadata:
  author: example-org
  version: "1.0"
---

# Skill 名称

## 指令
[Claude 要遵循的清晰、分步指导]

## 示例
[使用此 Skill 的具体示例]

在 SKILL.md 的顶部，必须加上前置元数据，主要是 name 和 description 这 2 个元数据，其他的都是可选的。

另外，Markdown 中的实际指令，对结构和内容没有特别限制。

如下面这个示例：

---
name: pdf-processing
description: 从 PDF 文件中提取文本和表格，填写表单，合并文档。
---

# PDF 处理

## 何时使用该技能
当用户需要处理 PDF 文件时，使用该技能……

## 如何提取文本
1. 使用 pdfplumber 进行文本提取……

## 如何填写表单

...

这种简单的格式有几个关键优势：

• 清晰易懂：不管是技能作者还是使用者，只要看一眼 SKILL.md ，就能明白它干啥的，让技能的维护和优化变得特别轻松。
• 扩展性好：技能的复杂度可以灵活调整，从简单的文字指令，到可执行代码、资源文件，再到模板，全都能搞定。
• 轻松迁移：技能就是个文件，编辑、版本管理、分享都特别方便。

相比于固定的 AI 工作流，Skills 的灵活性更好。

Skills 仓库推荐

在使用 Skills 前，先分享两个 Skills 仓库：

• https://github.com/anthropics/skills
• https://github.com/ComposioHQ/awesome-claude-skills
• ……

第一个是官方的 Skills 仓库，里面包含了一些图片、文档等基本技能，还有一个 skill-creator 技能，通过它就可以引导式创建一个技能。

第二个是第三方的 Skills 仓库，里面也包含也许多类型的技能，根据自己的需要酌情使用。

还有更多一些大厂、第三方收集的 Agent Skills，这篇就不展开了，下一篇会详细分享一下，关注公众号「AI技术宅」第一时间分享。

Claude Code 使用 Skills 指南

拿 Claude 自家来说，Claude API、Claude Code、Claude Agent SDK 等都支持 Skills，下面以 Claude Code 为例，来看看要怎么创建和使用 Skills。

Claude Code 的安装和高级用法看这两篇：

• Claude Code 保姆级安装和使用教程分享
• 玩转 Claude Code 的 23 个实用小技巧，效率拉满！！

Skills 分类

技能的存储位置决定了谁可以使用它：

一般是全局、项目 Skills。

安装 Skills

比如，你想使用官方、第三方的 Skills，只需要把它们仓库的技能目录复制到 ~/.claude/skills 目录下即可：

在 Claude Code 中使用 /skills 指令就可以列出所有的技能。

使用 Skills

使用 Skills 有两种方法：

1、自动引用

上面说了，如果 Claude 认为你的需求和某个 Skill 相关时，它就会自动加载并使用。

比如我发送：

列出所有skills并创建一个pdf

提示词中要创建 PDF，所以它自动加载了 PDF 的 Skill，这就是自动按需加载。

2、手动引用

你也可以通过 /xx 来手动引用要使用的 Skill，比如我明确知道官方有一个 canvas-design 技能，那我可以这样手动引用：

/canvas-design 设计一个 AI 学习路线图

如果你知道某个经常用的 Skills，这样手动引用可能会加快 Skills 的加载速度。另外，如果有多个类似的 Skills，手动引用也特别有用，避免用错。

创建自定义 Skills

创建 Skills 非常简单，一个 3 步：

• 在 ~/.claude/skills 目录下创建一个技能目录；
• 在技能目录下面创建一个 SKILL.md 技能文档；
• 开始编写你的 SKILL.md 文档具体操作指令。

当然，你也可以通过官方的一个 skill-creator 技能来引导式创建 Skills，这种方式更快，创建出来的 Skills 也会更懂你的需求。

下面，我来演示下如何通过 skill-creator 技能来创建一个自媒体助手 Skills。

然后，我把我在 GPT 上面的提示词扔给它：

当然，不一定要提供提示词，你完全可以把你的需求说出来，让它一步步帮你构建好这个 Skill。

不一会儿，它就帮我在 ~/.claude/skills 目录下创建好了 my-zmt-tools 自媒体助手 Skill，它主要包括两个功能：中文转英文URL、内容转小红书风格，这两个功能我之前是在 GPT 上面实现的。

使用 /skills 指令来验证下：

有了，这是它生成的 SKILL.ms 文档：

还不错吧？如果不满意，还可以基于它做二次修改。

现在来看看如何使用它，直接使用 /my-zmt-tool 技能的指令，然后带上指令参数、具体的内容或者要求就行了：

成功了，中文标题正确转换成了英文 URL，这个功能我在写博客时经常要用到，比如《MCP 不香了，Claude Code 又推出了 Skills！！（保姆级安装和使用教程分享）》这篇文章就对应这个 URL：

https://www.javastack.cn/claude-code-skills-usage/

后面的 claude-code-skills-usage 就是靠定制化 GPT 帮我生成的。

在使用 ChatGPT 时，首先要切换到具体的 GPT，然后再发送指令，使用不是很方便，网络慢时可能更影响速度，现在有了 Skills 感觉效率要更快了。

所以，有了 Skills，很多 GPT 上面完成的工作，都可以尝试用 Skills 来完成，Skills 有了更多的可能性。

CodeX 使用 Skills 指南

上面说了，Agent Skills 已经是开放标准了，在 Claude 创建好的 Skills 也可以在其他支持 Agent Skills 的 AI 编程工具中使用，比如 CodeX。

• CodeX 的安装使用（保姆级教程分享）
• 玩转 CodeX CLI 的 16 个实用小技巧，效率拉满！！

方法很简单，比如，我把上面创建好的 my-zmt-tolls 目录直接复制到 ~/.codex/skills 目录下。

然后同样使用在 CodeX 中使用 /skills 命令，可以列出所有的 Skills：

用法其实和 Claude Code 差不多，不太一样的是，Claude Code 的自身命令、斜杠命令和 Skills 都是通过 / 来选择，非常混乱，而在 CodeX 中，Skills 可以使用单独的 $ 来选择 Skills，它是和自身的 / 命令分开的。

所以，在 CodeX 中可以自动调用 Skills，也可以手动指定要引用的 Skill：

Skill 都正常执行了，很方便吧？

从 /skills 列表命令也可以看到，CodeX 还提供了一个 skill-creator 命令用于创建和维护 Skills，还有一个 skill-installer 命令用于从其他仓库源安装 Skills。

其他支持 Skills 的 AI 编程工具，都是同一样的手法。

OpenCode 使用 Skills 指南

如果你有多模型的使用习惯，比如：国外、国内、本地模型混用，封闭的 Claude Code、CodeX 就无法满足需求了，这里我们就得使用最近火爆全网的 OpenCode，号称开源版的 Claude Code，它支持任意模型随时切换。

现在越来越多的人都在使用 OpenCode，包括我自己。

怎么安装和使用参考我分享的使用教程：

开源版 Claude Code 杀疯了，怒斩 70k+ Star！！

OpenCode 会自动搜索以下位置的 Skills：

• 项目配置：.opencode/skills/<name>/SKILL.md
• 全局配置：~/.config/opencode/skills/<name>/SKILL.md
• 兼容项目 Claude：.claude/skills/<name>/SKILL.md
• 兼容全局 Claude：~/.claude/skills/<name>/SKILL.md

也就是说，OpenCode 不需要像 CodeX 那样复制 Skills，它支持自动搜索 Claude 的 Skills，这就比 CodeX 要方便太多了，不用复制冗余文件，这太舒服了。

目前，OpenCode 官方还没有类似 的 /skills 命令来列出所有的 Skills，不过可以通过问它列出所有的 Skills：

使用方法也是一样的，可以自动或者手动引用 Skills：

OpenCode 桌面版的使用也是一样的。

常见问题

经过以上 Skills 的工作原理和使用指南，下面的问题就不是问题了。

1、有了 MCP，为什么又搞出 Skills？

之前分享了一篇 MCP 的介绍及使用：

最近热火朝天的 MCP 是什么鬼？如何使用MCP？一文给你讲清楚！

MCP 本质上是为 AI 大模型提供调用外部工具的能力，MCP Server 就是这个能力的具体实现——你可以通过它，把你已有的 API、脚本、服务包装成 AI 能理解和调用的 MCP 工具。

使用 MCP 的限制：

• 如果只靠 MCP，你虽然可以调用很多工具／数据，但模型每次必须在提示或上下文里夹带大量相关信息，这会消耗大量 token、降低效率。
• 在很多场景下，问题不是调用 API，而是按公司标准／流程来做事，MCP 可以访问数据或工具，但不会自动知道这个流程的外在规则是什么。

而 Skills 正好解决了这些问题，所以，MCP 是 AI 连接外部的工具，而 Skills 教模型如何使用工具。

MCP + Skills 可以协同工作，在很多复杂系统中，两者往往组合使用，模型先通过 MCP 访问工具／数据，再通过 Skills 引导流程执行。

但有一点，在执行代码方面：

Skills 虽然也支持代码执行，但受限于本地的环境，比如执行 Python 脚本，要是本地没有安装 Python 环境，或者版本不兼容，都会影响 Skills 执行效率。

MCP 因为是执行固定的代码，所以 MCP 在执行代码方面要更稳定。

2、Skills 和 Slash Commands 有什么区别？

Skills 是由模型驱动的，Claude 会根据你的任务和 Skill 的描述自动匹配并使用这些 Skills，完全不需要你介入，当然也可以通过 /skill-name 来主动触发。

Slash Commands（斜杠命令）则是完全由用户触发的，你需要主动输入 /command 才能触发。

但是，从最新的 Skills 来看，Slash Commands 也被合并在用户 Skills 中了：

合并归合并，困为 Slash Commands 和 Skills 两者都可以通过 / 手动触发，Slash Commands 并不能自动触发，因为它没有像 Skills 那样定义元数据。

Skills 相比 Slash Commands 只是多了几个可选功能，它支持文件的目录、控制 Claude 是否调用 Skills 前置元数据，以及 Claude 在相关时自动加载它们的能力。

总结

Agent Skills 这一套机制，表面看只是多了一个 SKILL.md 文件，实际上背后是一整套 Agent 能力组织方式的升级。

Agent Skills 把提示词、工具、脚本、资源全部收敛到一个标准化目录里，再通过「渐进式披露」的方式按需加载，这一点对上下文成本和执行效率的提升非常明显。

从使用体验来看，Skills 最大的价值有三个：可复用、低心智成本、易迁移。

不管是个人常用能力，还是项目级、团队级的能力，都可以沉淀成 Skills，一次写好，反复使用。而且它不绑死某一家平台，已经被做成开放标准，Claude、Google、OpenAI、Cursor 都能用，这一点非常重要。

比如拿我自己来说，以前要频繁切 GPT，现在一个 Skill 就能搞定。

所以，可以预见的未来，Agent Skills 的体系和生态会更加完善，大家可以早点把自己的常用能力沉淀下来，后面只会越用越爽。

未完待续，R哥持续分享更多 AI 编程经验，包括更加复杂的 Skills 使用，公众号第一时间推送，关注和我一起学 AI。

⚠️ 版权声明：

本文系公众号 "AI技术宅" 原创，转载、引用本文内容请注明出处，抄袭、洗稿一律投诉侵权，后果自负，并保留追究其法律责任的权利。

你好，我是 Silvana，一名前端开发工程师菜鸟。

介绍：

最近琢磨出一个简单又有特色的 CSS 小效果 —— 倒边框半径的卡片，用来做个人名片类的展示特别合适，不用复杂的插件，纯 HTML+CSS 就能实现，分享给喜欢折腾前端小效果的朋友～

这个卡片的核心是用 CSS 伪元素搭配阴影模拟出 “倒圆角” 的视觉效果，整体结构不复杂，下面把完整的代码和详细注释贴出来，新手也能轻松看懂、直接套用～

完整源码（附详细注释）

1. HTML 部分（index.html）

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <!-- 适配移动端视图 -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSS 倒边框半径卡</title>
    <!-- 引入样式文件 -->
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <!-- 卡片容器 -->
    <div class="card">
      <!-- 顶部卡片区域（放视频背景） -->
      <div class="box">
        <div class="imgBx">
          <!-- 自动循环播放且静音的视频背景 -->
          <video src="cover.mp4" type="video/mp4" autoplay loop muted></video>
        </div>
      </div>
      <!-- 底部卡片区域（放个人信息） -->
      <div class="box">
        <div class="content">
          <!-- 姓名和身份 -->
          <h2>Lila Simmons<br/><span>Professional Artist</span></h2>
          <!-- 数据统计 -->
          <ul>
            <li>Posts<span>62</span></li>
            <li>Followers<span>120</span></li>
            <li>Following<span>47</span></li>
          </ul>
          <!-- 关注按钮 -->
          <button>Follower</button>
        </div>
      </div>
      <!-- 左侧圆形头像区域 -->
      <div class="circle">
        <div class="imgBx">
          <img src="user.png" alt="用户头像">
        </div>
      </div>
    </div>
  </body>
</html>

2. CSS 部分（style.css）

/* 全局样式重置 */
* {
  margin: 0;
  padding: 0;
  /* 盒模型：宽高包含边框和内边距 */
  box-sizing: border-box;
}
/* 定义全局颜色变量，方便统一修改 */
:root {
  --clr: #083d41
}
/* 页面整体样式：居中展示，背景色用变量 */
body{
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  background: var(--clr);
}
/* 卡片容器：相对定位，设置宽高，纵向排列子元素 */
.card {
  position: relative;
  width: 320px;
  height: 430px;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}
/* 卡片内的两个box通用样式 */
.card .box {
  position: relative;
  width: 110%;
  height: 200px;
  border-radius: 15px;
}
/* 第一个box（视频区域）：伪元素做左侧倒圆角 */
.card .box:nth-child(1) {
  background: #f00; /* 视频区域背景（被视频覆盖） */
}
.card .box:nth-child(1)::before {
  content: "";
  position: absolute;
  top: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  /* 利用阴影模拟倒圆角效果，颜色和页面背景一致 */
  box-shadow: -6px 6px var(--clr);
}
/* 第一个box：伪元素做底部倒圆角 */
.card .box:nth-child(1)::after {
  content: "";
  position: absolute;
  bottom: -1px;
  left: 105px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  box-shadow: -6px 6px var(--clr);
}
/* 第二个box（信息区域）：调整宽高和背景色 */
.card .box:nth-child(2) {
  background: #fff;
  height: 220px;
  width: 100%;
}
/* 第二个box：伪元素做左侧倒圆角 */
.card .box:nth-child(2)::before {
  content: "";
  position: absolute;
  bottom: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 第二个box：伪元素做顶部倒圆角 */
.card .box:nth-child(2)::after {
  content: "";
  position: absolute;
  top: -1px;
  left: 109px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 左侧圆形头像容器：绝对定位，居中显示 */
.card .circle {
  position: absolute;
  top: 50%;
  left: -70px;
  transform: translateY(-50%);
  width: 180px;
  height: 180px;
  border-radius: 50%;
  /* 边框颜色和页面背景一致，营造镂空感 */
  border: 10px solid var(--clr);
}
/* 头像和视频容器通用样式：溢出隐藏，适配圆角 */
.card .circle .imgBx,
.card .box .imgBx {
  position: absolute;
  inset: 0;
  overflow: hidden;
  border-radius: 50%;
}
/* 视频容器单独调整圆角，适配卡片 */
.card .box .imgBx {
  border-radius: 15px;
}
/* 头像和视频内容：铺满容器，保持比例 */
.card .circle .imgBx img,
.card .box .imgBx video {
  position: absolute;
  width: 100%;
  height: 100%;
  object-fit: cover;
}
/* 信息区域布局：居中排列，内边距调整 */
.card .box .content{
  position: absolute;
  inset: 0;
  padding: 30px 10px 20px;
  display: flex;
  align-items: center;
  flex-direction: column;
  gap: 20px;
}
/* 姓名样式：排版调整，颜色区分 */
.card .box .content h2{
  width: 100%;
  padding-left: 120px;
  text-transform: uppercase;
  font-size: 1.15em;
  letter-spacing: 0.1em;
  font-weight: 600;
  line-height: 1.1em;
  color: #333;
}
/* 身份文字：字号和颜色调整 */
.card .box .content h2 span {
  font-size: 0.75em;
  font-weight: 400;
  letter-spacing: 0.05em;
  color: #e91e63;
  text-transform: initial;
}
/* 数据统计列表：网格布局，均分宽度 */
.card .box .content ul {
  position: relative;
  top: 15px;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  width: 100%;
  padding: 0 10px;
  justify-content: space-evenly;
}
/* 列表项样式：纵向排列，文字颜色区分 */
.card .box .content ul li {
  list-style: none;
  display: flex;
  flex-direction: column;
  text-align: center;
  padding: 0 10px;
  font-size: 0.85em;
  font-weight: 500;
  color: #999;
}
/* 列表项分隔线：除最后一个外，右侧加边框 */
.card .box .content ul li:not(:last-child) {
  border-right: 1px solid #ccc;
}
/* 数据数字：字号放大，颜色加深 */
.card .box .content ul li span {
  font-size: 1.65em;
  color: #333;
}
/* 关注按钮样式：圆角、阴影、边框营造层次感 */
.card .box .content button {
  position: relative;
  top: 25px;
  padding: 8px 30px;
  border: none;
  outline: none;
  background: #03a9f4;
  border-radius: 30px;
  color: #fff;
  font-size: 1em;
  letter-spacing: .2em;
  text-transform: uppercase;
  font-weight: 500;
  cursor: pointer;
  border: 5px solid var(--clr);
  box-shadow: 0 0 0 10px #fff;
  transition: 0.5s;
}
/* 按钮hover效果：文字间距变大，背景色改变 */
.card .box .content button:hover{
  letter-spacing: 0.5em;
  background: #ff3d7f;
}
/* 按钮左侧倒圆角伪元素 */
.card .box .content button::before{
  content: "";
  position: absolute;
  top: 24px;
  left: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-right-radius: 20px;
  box-shadow: 5px -7px #fff;
}
/* 按钮右侧倒圆角伪元素 */
.card .box .content button::after{
  content: "";
  position: absolute;
  top: 24px;
  right: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-left-radius: 20px;
  box-shadow: -5px -7px #fff;
}

替换里面的cover.mp4和user.png为自己的素材就能直接用，核心的倒圆角效果都在伪元素的box-shadow那里，调整数值还能改倒圆角的大小，感兴趣的可以自己试试。

写着写着就到了结尾，祝您今晚有个好梦（代码少报错一点）。

本文由mdnice多平台发布

你好，我是 Silvana，一名前端开发工程师菜鸟。

介绍：

最近琢磨出一个简单又有特色的 CSS 小效果 —— 倒边框半径的卡片，用来做个人名片类的展示特别合适，不用复杂的插件，纯 HTML+CSS 就能实现，分享给喜欢折腾前端小效果的朋友～

这个卡片的核心是用 CSS 伪元素搭配阴影模拟出 “倒圆角” 的视觉效果，整体结构不复杂，下面把完整的代码和详细注释贴出来，新手也能轻松看懂、直接套用～

完整源码（附详细注释）

1. HTML 部分（index.html）

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <!-- 适配移动端视图 -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSS 倒边框半径卡</title>
    <!-- 引入样式文件 -->
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <!-- 卡片容器 -->
    <div class="card">
      <!-- 顶部卡片区域（放视频背景） -->
      <div class="box">
        <div class="imgBx">
          <!-- 自动循环播放且静音的视频背景 -->
          <video src="cover.mp4" type="video/mp4" autoplay loop muted></video>
        </div>
      </div>
      <!-- 底部卡片区域（放个人信息） -->
      <div class="box">
        <div class="content">
          <!-- 姓名和身份 -->
          <h2>Lila Simmons<br/><span>Professional Artist</span></h2>
          <!-- 数据统计 -->
          <ul>
            <li>Posts<span>62</span></li>
            <li>Followers<span>120</span></li>
            <li>Following<span>47</span></li>
          </ul>
          <!-- 关注按钮 -->
          <button>Follower</button>
        </div>
      </div>
      <!-- 左侧圆形头像区域 -->
      <div class="circle">
        <div class="imgBx">
          <img src="user.png" alt="用户头像">
        </div>
      </div>
    </div>
  </body>
</html>

2. CSS 部分（style.css）

/* 全局样式重置 */
* {
  margin: 0;
  padding: 0;
  /* 盒模型：宽高包含边框和内边距 */
  box-sizing: border-box;
}
/* 定义全局颜色变量，方便统一修改 */
:root {
  --clr: #083d41
}
/* 页面整体样式：居中展示，背景色用变量 */
body{
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  background: var(--clr);
}
/* 卡片容器：相对定位，设置宽高，纵向排列子元素 */
.card {
  position: relative;
  width: 320px;
  height: 430px;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}
/* 卡片内的两个box通用样式 */
.card .box {
  position: relative;
  width: 110%;
  height: 200px;
  border-radius: 15px;
}
/* 第一个box（视频区域）：伪元素做左侧倒圆角 */
.card .box:nth-child(1) {
  background: #f00; /* 视频区域背景（被视频覆盖） */
}
.card .box:nth-child(1)::before {
  content: "";
  position: absolute;
  top: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  /* 利用阴影模拟倒圆角效果，颜色和页面背景一致 */
  box-shadow: -6px 6px var(--clr);
}
/* 第一个box：伪元素做底部倒圆角 */
.card .box:nth-child(1)::after {
  content: "";
  position: absolute;
  bottom: -1px;
  left: 105px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-bottom-left-radius: 20px;
  box-shadow: -6px 6px var(--clr);
}
/* 第二个box（信息区域）：调整宽高和背景色 */
.card .box:nth-child(2) {
  background: #fff;
  height: 220px;
  width: 100%;
}
/* 第二个box：伪元素做左侧倒圆角 */
.card .box:nth-child(2)::before {
  content: "";
  position: absolute;
  bottom: 106px;
  left: -1px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 第二个box：伪元素做顶部倒圆角 */
.card .box:nth-child(2)::after {
  content: "";
  position: absolute;
  top: -1px;
  left: 109px;
  width: 20px;
  height: 20px;
  background: transparent;
  z-index: 10;
  border-top-left-radius: 20px;
  box-shadow: -6px -6px var(--clr);
}
/* 左侧圆形头像容器：绝对定位，居中显示 */
.card .circle {
  position: absolute;
  top: 50%;
  left: -70px;
  transform: translateY(-50%);
  width: 180px;
  height: 180px;
  border-radius: 50%;
  /* 边框颜色和页面背景一致，营造镂空感 */
  border: 10px solid var(--clr);
}
/* 头像和视频容器通用样式：溢出隐藏，适配圆角 */
.card .circle .imgBx,
.card .box .imgBx {
  position: absolute;
  inset: 0;
  overflow: hidden;
  border-radius: 50%;
}
/* 视频容器单独调整圆角，适配卡片 */
.card .box .imgBx {
  border-radius: 15px;
}
/* 头像和视频内容：铺满容器，保持比例 */
.card .circle .imgBx img,
.card .box .imgBx video {
  position: absolute;
  width: 100%;
  height: 100%;
  object-fit: cover;
}
/* 信息区域布局：居中排列，内边距调整 */
.card .box .content{
  position: absolute;
  inset: 0;
  padding: 30px 10px 20px;
  display: flex;
  align-items: center;
  flex-direction: column;
  gap: 20px;
}
/* 姓名样式：排版调整，颜色区分 */
.card .box .content h2{
  width: 100%;
  padding-left: 120px;
  text-transform: uppercase;
  font-size: 1.15em;
  letter-spacing: 0.1em;
  font-weight: 600;
  line-height: 1.1em;
  color: #333;
}
/* 身份文字：字号和颜色调整 */
.card .box .content h2 span {
  font-size: 0.75em;
  font-weight: 400;
  letter-spacing: 0.05em;
  color: #e91e63;
  text-transform: initial;
}
/* 数据统计列表：网格布局，均分宽度 */
.card .box .content ul {
  position: relative;
  top: 15px;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  width: 100%;
  padding: 0 10px;
  justify-content: space-evenly;
}
/* 列表项样式：纵向排列，文字颜色区分 */
.card .box .content ul li {
  list-style: none;
  display: flex;
  flex-direction: column;
  text-align: center;
  padding: 0 10px;
  font-size: 0.85em;
  font-weight: 500;
  color: #999;
}
/* 列表项分隔线：除最后一个外，右侧加边框 */
.card .box .content ul li:not(:last-child) {
  border-right: 1px solid #ccc;
}
/* 数据数字：字号放大，颜色加深 */
.card .box .content ul li span {
  font-size: 1.65em;
  color: #333;
}
/* 关注按钮样式：圆角、阴影、边框营造层次感 */
.card .box .content button {
  position: relative;
  top: 25px;
  padding: 8px 30px;
  border: none;
  outline: none;
  background: #03a9f4;
  border-radius: 30px;
  color: #fff;
  font-size: 1em;
  letter-spacing: .2em;
  text-transform: uppercase;
  font-weight: 500;
  cursor: pointer;
  border: 5px solid var(--clr);
  box-shadow: 0 0 0 10px #fff;
  transition: 0.5s;
}
/* 按钮hover效果：文字间距变大，背景色改变 */
.card .box .content button:hover{
  letter-spacing: 0.5em;
  background: #ff3d7f;
}
/* 按钮左侧倒圆角伪元素 */
.card .box .content button::before{
  content: "";
  position: absolute;
  top: 24px;
  left: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-right-radius: 20px;
  box-shadow: 5px -7px #fff;
}
/* 按钮右侧倒圆角伪元素 */
.card .box .content button::after{
  content: "";
  position: absolute;
  top: 24px;
  right: -29px;
  width: 20px;
  height: 20px;
  background: transparent;
  border-top-left-radius: 20px;
  box-shadow: -5px -7px #fff;
}

替换里面的cover.mp4和user.png为自己的素材就能直接用，核心的倒圆角效果都在伪元素的box-shadow那里，调整数值还能改倒圆角的大小，感兴趣的可以自己试试。

写着写着就到了结尾，祝您今晚有个好梦（代码少报错一点）。

本文由mdnice多平台发布

编辑：定慧

【新智元导读】2026年1月，前OpenAI CTO Mira Murati创办的明星公司Thinking Machines Lab遭遇「灭顶之灾」：联合创始人Barret Zoph因办公室恋情丑闻被降职后心生不满，联合另外两名核心骨干向Mira逼宫索权，遭拒后被当场开除。然而仅不到一小时，三人便集体叛逃回OpenAI，在老东家的迎接下风光回朝。这场融合了私情、背叛、权力与千万年薪的硅谷大戏，揭示了AI人才战争的疯狂与残酷。

2026年1月14日，旧金山的一场「政变」，让AI界的权力版图再次破裂。

如果说2024年的OpenAI「宫斗」是一场震惊世界的地震，那么刚刚发生的这场Thinking Machines Lab（TML）的解体，则是一场精心策划的「血色婚礼」。

故事的主角，依然是那些熟悉的名字：Mira Murati，刚从OpenAI出走一年的前CTO，如今是TML的掌门人；

Barret Zoph，曾经的OpenAI核心研究员，Mira最信任的战友，也是这次背叛的主角。

一切看似突如其来的「意料之外」，实则草蛇灰线，伏脉千里。

权力的游戏：从披萨店到「政变」

时间回拨到2026年1月初的一个周一早晨。

在Thinking Machines Lab位于旧金山的总部，气氛压抑得令人窒息。

Mira Murati本来以为这只是一场和Zoph的例行一对一会议，但当她推开门时，发现等待她的是一场精心策划的伏击。

Barret Zoph坐在那里，身边是另外两名核心骨干Luke Metz和Sam Schoenholz。

这不是汇报工作，而是「逼宫」。

三人图穷匕见，直接向Mira摊牌：交出所有的技术决策权，让公司的高级主管直接向Zoph汇报。

Mira冷冷地看着这群曾经的战友，反问Zoph：「过去半年你几乎没怎么干活，凭什么要更多的权力？」

她紧接着追问：「你们是不是已经找好了下家？」

Zoph沉默不语。Metz和Schoenholz则矢口否认。

最具戏剧性的一幕发生在这次会议的第二天晚上。

当Thinking Machines的办公室笼罩在未知的恐惧中时，Barret Zoph却正坐在一家著名的披萨店里，谈笑风生。

坐在他对面的，是Meta的高管Alexandr Wang和Nat Friedman。

这是一场赤裸裸的「拍卖」。

Zoph就像一个待价而沽的商品，在OpenAI和Meta之间左右逢源，寻找出价最高的买家。

周三，结局揭晓。

Mira以「缺乏信任、绩效不佳及不道德行为」为由，直接开除了Zoph。

然而，就在Zoph被扫地出门的仅仅不到一小时后，OpenAI的应用业务CEO Fidji Simo便高调宣布：Barret Zoph回归，担任企业版业务负责人。

紧随其后的，是Luke Metz和Sam Schoenholz的集体「叛逃」。

他们不仅回到了OpenAI，还直接汇报给刚刚「被开除」的Zoph。

TML的创始团队，瞬间只剩下三个人。

Mira Murati，这位曾经被称为OpenAI「奥特曼背后的女人」，在创业仅仅不到一年后，就被自己的老东家和昔日盟友联手「偷家」。

狗血剧情：「你是被操纵的受害者？」

这场决裂的种子，早在半年前就已埋下。

而引爆它的，是一段极具讽刺意味的「办公室恋情」。

2025年夏天，Mira震惊地发现，Zoph与公司内部一名初级员工——一位同样从OpenAI跳槽过来的下属——保持着长期的地下恋情。

在硅谷的职场伦理中，高管与下属的恋情是大忌。

更何况，这名下属在事情败露前已经悄然离职，回到了OpenAI。

面对质问，Zoph最初选择了撒谎。

当证据确凿时，他抛出了一个令人咋舌的理由：「我是被她操纵才进入这段关系的。」

这位身经百战的AI技术大牛，将自己描述成了一个无辜的受害者。

Mira没有选择直接公开丑闻，而是保留了他的体面——Zoph虽然保留了联合创始人的头衔，但被剥夺了管理权，降级为一名普通的「技术贡献者（IC）」。

对于心高气傲的Zoph来说，这无疑是奇耻大辱。

在那之后的几个月里，Zoph开始频繁「生病」、「休假」，甚至以家人离世为由长期缺席。

他的Slack状态总是灰色的，那个曾经极其活跃的代码贡献者消失了。

但他并没有闲着。

早在去年10月，当另一位联合创始人Andrew Tulloch跳槽去Meta时，Zoph就已经悄悄联系了Sam Altman。

小扎真的是来者不拒啊！

OpenAI反击战：500万年薪与「总经理」制

为什么是现在？为什么是OpenAI？

把视线拉高，你会发现这场人事狗血剧的背后，是OpenAI正在经历的一场生死存亡的变革。

2026年的AI战场，早已不是ChatGPT一家独大的时代。

Anthropic旗下的Claude Code正如同一头嗜血的野兽，疯狂撕咬着企业级市场的份额。

为了赢，OpenAI正在进行一场彻底的「基因改造」。

根据Fidji Simo最新的内部备忘录，OpenAI正在全面转向「总经理」负责制。

• Barret Zoph：负责企业版业务。
• Vijaye Raji：掌管广告业务。
• Nick Turley：负责ChatGPT。
• Thibault Sottiaux：负责Codex。

那个曾经理想主义的OpenAI消失了，取而代之的是一个层级分明、目标精准的商业机器。

科研不再是象牙塔里的游戏，而是必须「紧密服务于产品策略」的工具。

为了这场战争，OpenAI不惜血本。

据说，OpenAI为顶级研究员开出的年薪包已经高达500万至1000万美元。

为了抢人，OpenAI甚至取消了新员工前6个月的股权锁定期（vesting period）。

这意味着，跳槽即暴富，无需等待！

在Sam Altman和Fidji Simo眼里，Zoph是否「私德有亏」根本不重要，他是否「背叛」也不重要。

重要的是，他是一把能刺穿企业市场的尖刀。

历史的重复

历史总是惊人的相似，但这一次，剧本被反转了。

我们很难不联想到2023年那个震惊世界的感恩节。

那一次，是注重「AI安全」的Ilya Sutskever试图通过董事会罢免激进商业化的Sam Altman。

那一年的Sam Altman，是被放逐的受害者。

他在微软的支持下，带着Greg Brockman和一众死忠粉，在短短5天内上演了一场「王者归来」。

而到了2026年，这场戏的主角换成了Barret Zoph，但内核却变了。

如果说2023年的政变是「理想主义 vs 现实主义」的路线之争，那么2026年的这场政变，则是「纯粹的利益博弈」。

这次没有关于AI是否会毁灭人类的哲学辩论，没有关于非营利组织使命的高尚探讨。

剩下的，只有办公室恋情的狗血、私下勾兑的背叛、以及赤裸裸的金钱交易。

那个曾经被Ilya视为洪水猛兽的「商业化幽灵」，如今已经彻底吞噬了OpenAI。

Sam Altman不再是那个需要被审判的激进分子，他已经成为了规则的制定者。

而Barret Zoph，不过是他用来巩固商业帝国的一枚强力棋子。

通过接纳Zoph，OpenAI实际上在向全世界宣告：为了生存和胜利，我们可以原谅一切，甚至包括背叛。

硅谷的旋转门：左右横跳

很多人会问：为什么？

为什么Barret Zoph可以如此毫无心理负担地在老东家和新东家之间反复横跳？

为什么OpenAI可以毫不避讳地吃「回头草」？

这要归咎于硅谷独特的「旋转门」机制。

首先，加州法律禁止竞业禁止协议（Non-compete ban）。

这意味着，哪怕你是掌握核心机密的高管，今天辞职，明天就可以去竞争对手那里上班。法律赋予了人才极致的流动自由，也让企业的商业秘密时刻处于裸奔状态。

其次，人才的极端稀缺性。

在AI领域，能做Post-training（后期训练）、能搞定Agentic AI的顶级人才，全球加起来可能不超过几百人。

他们是稀缺资源，是行走的印钞机。

对于OpenAI、Google、Meta这样的巨头来说，只要能挖到人，此前的恩怨情仇都可以一笔勾销。

最后，是资本的推波助澜。此次Thinking Machines的解体，直接导致其120亿美元的估值面临崩塌。

投资人不仅没有惩罚背叛者，反而可能在幕后推动了这场并购式的「挖角」。

Josh Kushner（Thrive Capital创始人）甚至在OpenAI内部演讲中直言，即使是亿万富翁级别的投资人，现在也要亲自下场劝说人才留下来。

在这场游戏中，只要你的技术够强，你就可以在大厂和创业公司之间无限循环：

1. 在OpenAI积累名气。
2. 跳出来融资创业，身价暴涨。
3. 带着创业公司的核心团队和技术，被OpenAI高价「收编」。

这就形成了一个完美的闭环。

Barret Zoph只是这个闭环中最新、最显眼的一个玩家。

「混乱」是阶梯

在《权力的游戏》中，小指头有一句名言：「混乱不是深渊，混乱是阶梯。」

对于Mira Murati来说，这是至暗时刻。

她创立的公司遭受重创，120亿美元的估值面临重估，团队人心惶惶。

但对于Barret Zoph来说，利用TML作为跳板，他不仅洗去了在OpenAI上一轮内斗中的边缘化地位，还带着一支「私家军」风光回朝，直接掌控了OpenAI最核心的变现业务。

他在披萨店里左右逢源的那一刻，或许就已经看透了这个游戏的本质：技术只是筹码，人性才是战场。

当TML的办公室变得空荡荡时，OpenAI位于旧金山的总部里，香槟大概已经开启。

只不过，这酒杯里装的不仅是美酒，还有昔日同袍的鲜血。

在这个AI、资本、人才都疯魔的时代，没有人是无辜的，只有输家和赢家。

数据库校验利器升级！gt-checksum v1.2.3 正式发布

更快、更稳、更智能——你的数据一致性守护专家

✨ 写在前面

在日常的数据库运维与数据迁移中，你是否经常被这样的问题困扰：

• 数据不一致却难以快速定位
• 跨库校验复杂繁琐
• 存储过程、触发器难对比
• 大表校验内存飙升，被 OOM 直接 Kill

今天，我们为你带来一个好消息——gt-checksum v1.2.3全新发布，专门针对上述痛点进行了全面增强与优化！

发布会预约：https://meeting.tencent.com/dw/hSVg8Wu4ixfk
发布会时间：2026年1月26日下午15:30

🚀 核心亮点速览

1. 📁 数据库名映射：跨库校验一键搞定

现在，你可以轻松将源库的表“映射”到目标库的不同名称下进行校验，非常适合分库分表、跨环境数据对比等场景。

配置示例：

# 单表映射
tables=db2.test1:db1.test1
# 整库映射
tables=db2.*:db1.*

结果中会清晰展示映射关系，一目了然。

2. 🛠️ 支持 Routine 与 Trigger 校验

不仅是表数据，现在连存储过程、函数、触发器也能进行一致性校验与智能修复，生成完整可执行的修复 SQL。

3. 🧠 更聪明的内存管理

引入智能内存调控机制，自动防止 OOM（内存溢出）。当内存接近上限时，工具会自动平滑降低并发与分块大小，并触发垃圾回收，保障任务稳定运行。

4. 📝 修复 SQL 生成逻辑大幅优化

• 自动在修复文件头部添加字符集设置、临时禁用外键检查等语句
• 智能合并事务，提升修复执行效率
• 修复了以往版本中因语句顺序问题导致的修复失败

⚙️ 重点功能详解

🔄 数据库名映射

适用于异构数据库同步、测试环境与生产环境结构差异等复杂场景，让校验不再受库表名称限制。

🔍 结构校验增强

• 索引修复：支持主键/辅助索引的“不可见”属性设置，合并 DDL 提升效率
• 外键约束：新增外键一致性校验与修复
• 字段操作优化：智能合并 CHANGE COLUMN操作，避免重建字段导致的数据丢失风险

🧩 参数配置更清晰

我们整理了最常用的配置参数，方便你快速上手：

⚡ 性能与稳定性的全面提升

• 查询优化：减少冗余查询，部分场景性能提升达 3 倍
• 并发自适应：内存超限时平缓降低并发（每次 90%），避免性能骤降
• 日志国际化：所有输出统一为英文，日志更简洁，便于监控系统采集分析

🐛 关键问题修复

针对数据校验中的“顽疾”进行了重点修复：

• 特殊字符（如 \'）转义处理
• 字符串末尾空格导致的误判
• 多列联合主键校验准确性
• 无索引表的数据一致性问题

📦 如何获取与使用

新版本已发布，你可以通过以下方式获取：

1. 下载最新二进制包（已包含测试用例）
2. 查看详细文档与配置说明
3. 使用 ./gt-checksum --help快速查看参数

建议在使用前，根据实际数据量与环境资源，合理调整 memoryLimit、parallelThds等参数，以达到最佳校验效果。

🙏 致谢

特别感谢社区用户

• GLAW
• 月城

为本版本的开发与优化做出的重大贡献！

💎 总结

gt-checksum v1.2.3 不仅是一次功能更新，更是面向生产级数据一致性校验的全面进化。无论你是在做数据迁移验证、主从一致性巡检，还是日常数据质量保障，这个版本都能为你提供更可靠、更高效的支撑。

让数据校验，从此省心、放心。

gt-checksum 是一个开源项目，欢迎贡献代码、反馈问题或提出建议。让我们一起打造更好用的数据库工具！

编辑：Aeneas 好困

【新智元导读】刚刚，奥特曼发出预警：一周后Codex全家桶就要来了，但它们极其危险，以至于网络安全评级已经到达高级别！这些模型极可能打破现有的网络攻防平衡，导致攻击数量激增，甚至能帮你抢银行。

今天，奥特曼预告：

一周后，我们将陆续释放与Codex相关的一系列新能力。

不过，更可怕的事情来了！奥特曼表示，它们已经十分强大，甚至危险。

强大到可以在数秒内定位人类多年未发现的安全缺陷，危险到同样能被用来复现历史上几乎所有的网络攻击。

因此，这些模型的网络安全风险评级，将首次达到「高」（High）级别，再往上就是最高的「关键」（Critical）等级了。

而OpenAI也不得不对这些模型严加防范，组织用户利用它们实施网络犯罪，比如抢银行，窃取资金等等。

总之，某个时间点之后，世界上的漏洞数量将不再由人类决定。

代码在自己生长，系统在彼此连接，攻击不再需要动机，只需要一次提示词。

当模型学会理解软件的全部结构时，它同样学会了如何撕开它。

现在我们已经进入了这样一个世界：

网络安全从来不是「有没有问题」，而是问题被谁先发现。

而现在，最先发现它们的，可能已经不再是人。

离「失控」或仅一步之遥

根据OpenAI的安全框架，「高」风险意味着模型具备以下能力：

• 协助开发网络攻防工具
• 自动化攻击受保护的目标
• 自动发现系统漏洞

这极可能打破现有的网络攻防平衡，导致攻击数量激增。

如果模型达到「严重」等级，就意味着它能自主发现零日漏洞并执行攻击——不需要人类指导，自己就能找到未知漏洞并利用它。

这就太可怕了。还好目前还没到这一步。

OpenAI的应对策略

面对潜在风险，OpenAI计划采取「先限制使用，后辅助防御」的策略。

1. 限制使用：对Codex的某些能力进行限制，不让它随便被用来搞事情

2. 辅助防御：利用AI提升整体软件安全性，让好人也能用AI来防护

奥特曼的原话是：

在更强模型问世前，部署现有技术是构建防御体系的关键一步。

翻译一下：我们知道AI有风险，但与其让别人先把这个能力用到歪路上，不如我们先部署出来，帮好人建立防线。

这个逻辑有点「以毒攻毒」的意思。

不可否认，如今我们正在进入网络安全准备的高级阶段——防御必须跑在滥用之前。

短期内，我们只能用产品级限制，阻断恶意指令；而长期来看，唯一的出路，是让防御性能力被极限加速。

因为可以预见的是，很快，世界上将同时存在大量强大的模型。

而在那个世界里，没有被修复的漏洞，本身就是一种武器！

Claude Code还是Codex？

最近，Claude Code在硅谷简直风头无俩，几乎所有程序员都因为它，陷入了存在主义危机。

不过因为技术大佬却发布了一篇观点极为反常识的文章：《为什么Codex会赢得人工智能编码之战（而不是Claude Code）》。

这是为什么？让我们看看他的理由。

现在的YouTube、X和Reddit上，到处都是工程师在对比Claude Code和 Codex。

但是作者直言，问题就在于：

工程师并不代表软件的未来。

原因在于，开发者长期以来享有的「技术垄断」正在瓦解。

没错，开发者确实还有优势，然而，他们会做的，和一个完全不懂技术的人能做的之间的差距，正在飞速缩小。

所以，当一名工程师告诉你「Claude Code更好用」时，他们是说「这个工具符合自己的工作习惯」。

这并不等同于「这个工具最好」。

大多数人在对比这些工具时都抓错了重点。

问题关键，并不是哪个AI更聪明，Claude Code和Codex都足够强大，只要你清楚自己想做什么，哪怕不懂代码也能开发出完整的应用。

真正的核心问题是：

当大多数软件开发者不再是工程师时，他们到底想要什么？

他们想整天坐在AI面前，跟它有来有回地「拉扯」、监工、反复微调吗？还是想把需求丢给AI，然后去享受生活？

答案显而易见。

两种工具，两种截然不同的理念

Claude Code和Codex建立在两种完全相反的AI哲学之上。

· Claude Code是「结对程序员」

它希望与你协作，Anthropic 称之为「让用户保持在环节中（Human in the loop）」。

这就像管理一个实习生：你交代任务，他向你提问，你给反馈，他再修改。这种反复的互动不是Bug，而是Anthropic刻意为之的设计。

· Codex是「自主打工人」

你给它一个任务，它直接钻进代码库，修改代码、跑测试、交付结果。没有询问，没有废话，只有结果。

它可以在本地或云端连续工作数小时而不需人工干预。

工程师选择这个行业，不仅仅是为了「快」，而是因为热爱这个过程：

解决问题、调试、思考、打磨手艺。

Claude Code正是为此而生的。它适合那些想要参与感、想要掌控权、想要保留核心思考环节的人。

工程师想要一个助手，帮他们处理琐碎杂事，好让他们留着精力去做「有趣的部分」。

这没有错，但这只是个人偏好，而非商业决策。

过程已死，结果万岁

作者写了20多年代码，曾深爱其中的一切。

但当他步入40岁时，却突然意识到生命中最珍贵的东西是时间。

他不想再和AI玩「你来我往」的游戏。不想当保姆，也不想协作。

他想告诉AI造什么，然后去过自己的生活，回来直接测试。

自从GPT-5发布后，作者对Claude的使用率暴跌。不是因为它不好，而是因为不再迷恋过程，只要结果。

现在，他已经将80-90%的工作交给GPT-5.X-Codex模型。

虽然偶尔还用Claude Code处理简单的琐事，但它那种「互动式工作流」带来的投资回报率正在持续走低。

工程师的「傲慢」

普通人的「野心」

快进到一两年后，软件将成为一种日用品。即便对编程毫无兴趣的人也能快速上手。

虽然构建软件永远需要技能，但这种技能不再是「写TypeScript」或「配置开发工具」。

最核心的技能将变成：定义产品。

未来的软件构建者可能永远不会爱上「编程过程」。

他们不想和AI深度交流，也不想每隔几分钟就回答模型提出的问题。他们只想给出任务，然后继续处理别的事。

Anthropic是为工程师构建的Claude Code：

协作、对话、人工干预。

如果你认为未来是「天才工程师带着聪明助手」，那这个愿景很美好。

但作者认为，未来属于数以亿计的、想用AI造东西的非技术人员：

他们不在乎手艺，只要结果。

Codex正是为这群人准备的。

除非Anthropic改变方向，开发出能让用户真正「甩手掌柜」的工具，否则他们就是在为一个日益萎缩的市场服务。

在未来的AI建造者大潮中，职业工程师的人数将变得微不足道。

最后，在2026年，每家公司都必须回答：

你的AI到底是一个同事，还是一个工具？

Claude Code需要你在场，保持互动。而Codex能让你走开，去过生活。

如果你是一个热爱过程的工程师，Claude Code堪称完美。

但对于剩下那些只想要结果的人来说，Codex才是未来。

因为「其他人」，才是世界上的大多数。

编辑：定慧

【新智元导读】刚刚，达沃斯论坛迎来两场震撼全场的演讲。世界首富马斯克预言：2035年AI将比80亿人加起来还聪明，Optimus机器人2027年开卖，人类将进入「富足时代」。而《人类简史》作者尤瓦尔却当场预警：AI已不再是工具，而是「会自己决定杀人的刀」——它正在接管法律、宗教和语言，人类只剩十年做决定。

2026年1月20-23日，达沃斯论坛。

世界首富马斯克首次亮相达沃斯论坛，一开口就扔下了一颗核弹：

AI今年就会比任何人都聪明，到2035年，它会比80亿人加起来还要聪明！

与此同时，《人类简史》作者尤瓦尔当场发出警告：

AI已经拿起了「锤子」，我们只剩十年做决定。

两位重量级人物：世界首富马斯克 vs 《人类简史》作者尤瓦尔·赫拉利

今天，达沃斯的空气里同时弥漫着「希冀」和「恐惧」。

就在这周，两个分别代表「建造者」和「警告者」的声音，在这个被雪山环绕的瑞士小镇上激烈碰撞。

一个在描绘AGI帝国的蓝图，一个在敲响人类命运的警钟。

这场隔空对话，可能是人类历史上最重要的一次交锋。

马斯克的AGI时间表

今年就会超越（单个）人类！

这就是马斯克对于AI的预言，2026年底，AI将超过地球上任何一个人类。

1月23日，马斯克和贝莱德CEO拉里·芬克同台对话，也是作为世界首富的他首次亮相达沃斯论坛。

开场第一个话题，他聊的居然是：外星人。

「我们有9000颗卫星在轨道上，从来没有一次需要避开外星飞船。」

马斯克停顿了一下。

紧接着，他说出了让整个会场陷入沉默的话：

「我们需要假设，生命和意识是极其稀有的。可能只有我们人类。」

注意，这可不是在开玩笑。

这是马斯克经营2.2万亿美元科技帝国的核心逻辑！

如果人类真的是宇宙中唯一的智慧生命——这个被称为「费米悖论」的可怕假设——那么保存人类意识的火种，就成了一切的前提。

这就是为什么他要把人送上火星。

这就是为什么他要造能超越人类的AI。

这就是为什么他要让机器人「淹没」地球。

因为在马斯克的世界观里，只有两条路：要么无限繁荣，要么完全灭绝。

没有中间地带。

同时，马斯克也透露了特斯拉的新使命：实现人类可持续的丰裕。

2035年，全人类集体被超越

关于AGI到底什么时候来，马斯克给出了一个精确到让人不安的时间表——

「AI进步的速度是这样的：我认为今年，或者最晚明年，就会有比任何单个人类都聪明的AI。

到2035年，它会比全人类加起来还要聪明。」

2035年。

距离现在只有9年！

9年，是什么概念？

想象一下那个场景：一个超级智能，不只是比爱因斯坦聪明，不只是比整个谷歌团队聪明，而是比这个星球上80亿人的智力总和还要强大！

当然，也不是所有人都认同这一点。

英伟达CEO黄仁勋就对「通用AI」持保守态度，认为真正的AGI可能还需要「圣经级别、银河级别」的时间尺度。

但马斯克显然不这么认为。

Optimus 2027年开卖

机器人数量将超过人类！

如果说AGI是马斯克的「思想武器」，那Optimus人形机器人就是他的「物理武器」。

「2027年晚些时候，Optimus将开始销售。」

马斯克预测，未来机器人的数量将超过人类。

它们将「满足人类所有需求」，以至于你「想不出还能让机器人帮你做什么」。

这是一个什么样的世界？

数十亿台由AI驱动的机器人，照顾老人、养育孩子、完成所有人类不想做的工作。

工作变成可选项。金钱失去意义。全球经济将经历「前所未有的爆炸性增长」。

听起来像乌托邦。

但是，批评者的问题来了：

那些「不再需要」工作的人类，会去做什么？谁来决定资源的分配？谁来为全民基本收入买单？

马斯克没有回答这些问题。

他只是说了一句话：「宁愿做一个乐观的错误者，也不做一个悲观的正确者。」

Would rather be optimistically wrong than pessimistically correct

尤瓦尔的惊悚警告

「AI已经拿起了锤子！」

就在马斯克发表演讲的三天前，另一场演讲正在达沃斯引发轩然大波。

演讲者是尤瓦尔·诺亚·赫拉利——

那个写出《人类简史》《未来简史》的以色列历史学家。

那个被全世界政治家和企业家奉为思想导师的公共知识分子。

他的演讲题目很简单：「关于AI与人类的坦诚对话」。

但内容一点都不简单。

「过去所有的技术——锤子、印刷机，甚至原子弹——都只是工具。

没有人类的操作，它们什么也做不了。」

赫拉利的声音低沉而有力。

「但AI不一样。

AI是历史上第一个能够自主决策、自主创造的’智能体’。

它不再是握在人类手中的锤子——它已经拿起了锤子，开始改造世界。」

这个比喻，精准地击中了问题的核心。

我们习惯于把AI当作工具：更快的计算机、更智能的助手、更高效的搜索引擎。

但2026年的AI已经不是这样了。

它能写代码，能作曲，能辩论，能撒谎。

它能学习你从未教过它的东西，做出你无法预测的决定。

语言的沦陷

法律、宗教、历史正在失守！

赫拉利指出了一个被大多数人忽略的致命弱点——语言。

「人类为什么能统治地球？

不是因为我们力气最大，而是因为我们发现了如何用语言让数以亿计的陌生人协作。」

语言，是人类的超能力。

但这个超能力，正在被AI接管！

「法律是由语言构成的——所以AI将接管法律系统。」

「书籍是由语言构成的——所以AI将接管书籍。」

「宗教是由语言构成的——所以AI将接管宗教。」

这不是危言耸听。

想想看：今天的AI已经能背诵整本圣经、古兰经、佛经，能引用任何宗教文献中的任何章节。

当信徒们开始向AI询问信仰问题时，谁才是圣典最权威的解释者？

想想看：今天的AI已经能阅读所有的法律文本，能分析所有的判例。

当法官们开始依赖AI辅助判决时，谁才是法律的真正执行者？

赫拉利把这种现象称为「非人类智能的大规模迁入」！

AI像数十亿移民一样涌入人类社会，但它们遵循的不是人类的逻辑，而是某种我们根本无法理解的「外星智能」。

赫拉利最终警告我们：任何由文字构成的事物都将被人工智能接管！

AI「移民」来了

更炸裂的来了。

赫拉利把AI比作一种全新的「移民」——以光速入境，无需签证。

「想象一下，这种移民以光速移动，不需要签证，不需要过海关，直接进入你的经济系统、你的文化、你的感情生活。」

感情生活？

没错。赫拉利直接点名了一个正在发生的现象：AI男友和AI女友。

「它们正在改变人类的浪漫关系。

年轻人开始和AI谈恋爱，不是开玩笑，是真的。」

「这些’移民’会抢走工作，会从根本上改变本地文化。」

「而你无法把它们驱逐出境。」

法人资格：一个迫在眉睫的问题

演讲的最后，赫拉利抛出了一个现实问题——

AI需要法人资格吗？

「公司有法人资格。河流可以有法人资格。」

但它们背后都有人类在管理。

「AI不一样。AI可以自己管理银行账户，可以自己提起诉讼，可以自己运营公司。完全不需要人类。」

赫拉利指出，其实这个问题已经不是「未来」了——

「AI机器人在社交媒体上已经当了十年的’人’了。」

「它们发帖、点赞、评论、影响舆论。没有人问过它们有没有这个权利。」

「我们只剩十年！」

演讲的最后，赫拉利发出了一个明确的警告——

「十年后再来决定AI是否应该拥有法人资格，就太晚了。别人会替你做出决定。如果你想影响人类的未来走向，你必须现在就做出决定。」

他用历史上的雇佣兵做类比：一开始你雇佣他们打仗，后来他们夺取了政权。

AI也是一样。

今天它是你的雇员。明天呢？

DeepMind的秘密行动

谷歌已在筹备「后AGI时代」!

在马斯克和赫拉利隔空对话的同时，一条不起眼的招聘信息悄悄出现在了网上。

发布者是Shane Legg，Google DeepMind的联合创始人，首席AGI科学家。

他在推特上写道：

「AGI已近在咫尺。它的出现将深刻改变人类社会，尤其是全球经济体系。我正在紧急寻找一位高级经济学家，加入我的团队。」

注意措辞：「紧急」。「AGI之后」。

这不是在为AI时代做准备。

这是在为后AGI时代做准备！

入职者将直接向Shane Legg本人汇报。

他是谁？一个从2010年就开始研究AGI安全的人；一个2011年就预测「2028年前有50%概率实现AGI」的人；一个可能比马斯克更清楚AGI进展的人。

如果连DeepMind内部都在组建「后AGI经济学」团队，这说明什么？

说明在那些真正站在技术最前沿的人眼里，AGI已经不是「会不会来」的问题。

而是「来了之后怎么办」的问题。

写在最后

从智人走出非洲大裂谷，到在达沃斯论坛上讨论自己的「继任者」——这中间隔了30万年。

30万年里，人类发明了语言、文字、宗教、法律、科学。

我们用这些工具建造了城市、帝国、文明。

我们把火种从篝火传到了火箭发动机。

而现在，在2026年的这个冬天，我们可能正在见证这30万年历程的终点——或者说，起点。因为：

如果马斯克是对的，9年后将诞生一个比全人类加起来还要聪明的存在。

如果赫拉利是对的，那个存在已经开始接管我们的语言、法律和信仰。

这不是人类历史的结束。这是人类历史的分叉。

一条路通向马斯克描绘的富足星际文明，一条路通向赫拉利警告的「人类租客」时代。

我们站在这个分叉口，手里握着方向盘——但可能握不了太久了。

编辑：定慧 元宇

【新智元导读】AI编程霸主之争升级！Claude Code刚刷屏，OpenAI连甩两张王：不仅首度揭秘Codex背后的大脑「Agent Loop」，还自曝惊人基建：仅用1个PostgreSQL主库，竟抗住了全球8亿用户洪峰！

最近，Anthropic的Claude Code引爆了AI编程圈！

那个能在终端里自己读代码、改代码、跑测试的AI助手，让不少开发者直呼「这才是未来」。

一时间，社交媒体上全是「Claude Code吊打Cursor、Codex、Antigravity」之类的评论。

就在大家以为OpenAI还在憋GPT-5.3大招的时候，今天其官博和奥特曼突然在X平台甩出了两张王炸：

1. Agent Loop架构揭秘：首次公开Codex的「大脑」是怎么运转的

2. PostgreSQL极限架构：1个主库扛起8亿用户的疯狂操作

这一波组合拳打得太漂亮了。

今天咱们就来拆解一下，OpenAI到底憋了什么大招。

Agent Loop

Codex的「大脑 」 是怎么运转的

什么是Agent Loop？

如果你用过Codex CLI、Claude Code等等CLI终端工具，你可能会好奇：

这玩意儿到底是怎么知道我想干啥的？怎么就能自己读文件、写代码、跑命令？

答案就藏在一个叫Agent Loop（智能体循环）的东西里。

简单来说，Agent Loop就像一个「总指挥」，它负责把「用户意图」「模型大脑」和「执行工具」串成一个完美的闭环。

这不是普通的「你问我答」，而是一个包含了「观察-思考-行动-反馈」的能干活的系统。

下面，把这个黑盒拆开，看看一个真正的AI Agent是如何跑起来的。

一个完整的Agent Loop是怎么跑起来的

用一个具体的例子来说明。

假设在终端里输入：给项目的README.md加一个架构图。

第一步：构建Prompt

这好比给大脑发工单。

Codex不会直接把你的话丢给模型，它会先构建一个精心设计的「Prompt」：

• 我是谁：（System）：告诉模型它是谁、能干什么
• 我有什么工具（Tools）：有哪些工具可以调用（比如shell命令、文件操作）
• 环境上下文（Context）：当前在哪个目录、用的什么shell
• 用户指令：给README.md加一个架构图。

这就像给模型发一封详细的工作邮件，而不是只发一句「帮我干活」。

第二步：模型推理（Inference）

这一步，大脑开始转动。

Codex把这个Prompt发给ResponsesAPI，模型开始思考：

「用户想加架构图，我得先看看现在的README是什么样的……」

然后模型做出决定：调用shell工具，执行catREADME.md。

第三步：工具调用（ToolCall）

Codex收到模型的请求，在本地执行命令，把README.md的内容读出来。

这就像手脚开始动起来。

第四步：结果反馈

这一步，终端把README.md的内容吐了出来。

这时候流程没有结束。Codex把命令的输出追加到Prompt里，再发给模型。

第五步：循环

模型看到了README的内容，再次进行推理：

可能是生成一个Mermaid图，可能是直接写一段ASCII图形……然后再调用工具写入文件。

这个循环一直持续，直到模型认为任务完成了，输出一条「我搞定了」的消息。

它不是在回答问题，它是在解决问题。

为什么这很重要？

也许你可能会说：「这不就是多调了几次API吗？」

但绝非这么简单。

传统的LLM应用是「一问一答」式的：你问，它答，完事儿。

但Agent Loop让AI变成了一个能独立干活的员工。

• 它会自己规划路径（Chain of Thought）。
• 它会自己检查错误（Self-Correction）。
• 它会自己验证结果（Feedback Loop）。

这才是真正的「AI Agent」。

而Agent Loop，就是那个可以让AI实现从「陪伴聊天」迈向「独立干活」飞跃的桥梁。

性能优化

两个关键技术

OpenAI在文章里分享了两个硬核优化，解决了Agent开发的两大痛点：

痛点一：成本爆炸

Agent Loop每跑一圈，都要把之前的对话历史（包括那些冗长的报错信息、文件内容）重新发给模型。

对话越长，成本越高。如果不优化，成本是平方级增长的。

解决方案：PromptCaching（提示词缓存）

OpenAI采用了一种类似于「前缀匹配」的缓存策略。

简单来说，只要你发给模型的前半部分内容（System指令、工具定义、历史对话）没变，服务器就不需要重新计算，直接调取缓存。

这一招，直接让长对话的成本从平方级增长降到了线性级。

但这里有个坑：任何改变Prompt前缀的操作都会导致缓存失效。比如：

• 中途换模型
• 修改权限配置
• 改变MCP工具列表

OpenAI团队甚至在文章里承认，他们早期的MCP工具集成有bug：工具列表的顺序不稳定，导致缓存频繁失效。

痛点二：上下文窗口有限

再大的模型，上下文窗口也是有限的。

如果Agent读了一个巨大的日志文件，上下文瞬间就满了，前面的记忆就会被挤掉。

对于程序员来说，这就意味着：「你把前面我定义的函数给忘了？！」

这不仅是智障，更是灾难。

解决方案：Compaction（对话压缩）

当Token数超过阈值，Codex不会简单地「删除旧消息」，而是会调用一个特殊的/responses/compact接口，把对话历史「压缩」成一个更短的摘要。

普通的总结（Summary）只是把长文本变成短文本，会丢失大量细节。

OpenAI的Compaction返回的是一段encrypted\_content（加密内容），保留了模型对原始对话的「隐性理解」。

这就像把一本厚书压缩成一个「记忆卡片」，模型读了卡片就能回忆起整本书的内容。

这让Agent在处理超长任务时，依然能保持「智商」在线。

这一次，OpenAI硬核揭秘Codex CLI背后的「大脑」「Agent Loop」，释放出一个信号：AI真的是要把活儿给干了。

1个主库扛8亿用户

PostgreSQL的极限操作

在大家都在聊AI模型有多牛的时候，OpenAI悄悄曝光了一个更劲爆的消息：

支撑全球8亿ChatGPT用户、每秒处理数百万次查询的，竟然只是一个单一主节点的PostgreSQL数据库！

它只用1个PostgreSQL主节点+50个只读副本就做到了。

8亿用户，这简直是在开玩笑！有网友惊叹。

在分布式架构盛行的今天，大家动不动就是「微服务」「分片」「NoSQL」。

能用巨型分布式集群解决的问题，绝不用单机。

结果OpenAI告诉你：我们就用个PostgreSQL，照样扛。

他们是怎么做到的？

根据OpenAI工程师披露的信息，关键技术包括：

1. PgBouncer连接池代理 ：大幅减少数据库连接开销 2. 缓存锁定机制 ：避免缓存穿透导致的写入压力 3. 跨地域级联复制 ：读请求分散到全球各地的副本

这套架构的核心思想是：读写分离，极致优化读路径。

毕竟对于ChatGPT这种应用，读请求远远多于写请求。用户发条消息，系统可能需要读几十次数据（用户信息、对话历史、配置信息……），但写入只有一次。

根据OpenAI官方博客披露，关键技术包括：

1.连接池代理（PgBouncer）

通过连接池管理，把平均连接建立时间从50ms降到了5ms。

别小看这45ms，在每秒百万级查询的场景下，这是巨大的性能提升。

2.缓存锁定/租约机制（CacheLocking/Leasing）

这是一个非常聪明的设计。

当缓存未命中时，只允许一个请求去数据库查询并回填缓存，其他请求等待。

这避免了「缓存雪崩」——大量请求同时涌向数据库的灾难场景。

3.查询优化与负载隔离

团队发现并修复了一个涉及12张表连接的复杂查询。

他们把复杂逻辑移到应用层处理，避免在数据库里做OLTP反模式操作。

同时，请求被分为高优先级和低优先级，分别由专用实例处理，防止「吵闹邻居」效应导致的性能下降。

4.高可用与故障转移

主库运行在高可用（HA）模式，配有热备节点。

读流量全部分流到副本，即使主库宕机，服务仍能保持只读可用，降低故障影响级别。

天花板终究会到来

不过，OpenAI也坦言，这套架构已经碰到了物理极限。问题出在两个地方：

PostgreSQL的MVCC限制

PostgreSQL的多版本并发控制（MVCC）机制会导致写放大（更新一行需要复制整行）和读放大（扫描时需要跳过死元组）。对于写密集型负载，这是个硬伤。

WAL复制压力

随着副本数量增加，主库需要向所有副本推送预写日志（WAL）。副本越多，主库的网络压力越大，副本延迟也越高。

为了突破这些限制，OpenAI正在做两件事：

1. 把可分片的、高写入负载迁移到AzureCosmosDB等分布式系统；

2. 测试级联复制：让中间副本向下游副本转发WAL，目标是支持超过100个副本。

这个案例完美诠释了一个架构哲学：如无必要，勿增实体。

不要一上来就搞分布式：先用简单的方案撑住，撑不住了再说。

很多公司的问题是：还没到需要分布式的阶段，就已经把架构搞得无比复杂了。结果既没有分布式的好处，还背上了分布式的复杂度。

OpenAI用实践证明：一个优化到极致的单机架构，能走得比你想象的更远。

Codex VS Claude Code的争霸赛

Claude Code的杀手锏是什么？是端到端的开发体验。

它不是一个简单的代码补全工具，而是一个能在终端里独立干活的Agent。

它能读代码、改代码、跑测试、处理Git、甚至自己修Bug。现在甚至还能写文档，做PPT。

这直接威胁到了Codex CLI的地位。

OpenAI这波更新，其实是在说三件事：

第一，我的Agent架构更成熟。

Agent Loop的公开，展示了OpenAI在Agent架构上的深厚积累。这不是一个临时拼凑的产品，而是经过精心设计的系统。

Prompt Caching、Compaction、MCP工具集成……这些都是实打实的工程能力。

第二，我的基础设施更强。

PostgreSQL的案例，展示的是OpenAI的后端能力。8亿用户的规模，不是随便一个创业公司能玩转的。

这也是在暗示：我们的「护城河」不只是模型，还有整个工程体系。

第三，我的模型在变得更强大。

网络安全评级的公开，一方面是在做「预期管理」，告诉大家模型有风险，我们在负责任地处理。

另一方面，这也是在秀肌肉：我们的模型已经强大到需要专门评估网络安全风险了。

这场AI编程工具的竞争才刚刚开始。

Claude Code逼迫OpenAI加快了Codex的迭代速度。OpenAI的回应，又会倒逼Anthropic继续创新。

最终受益的，是我们这些开发者。

编辑：KingHZ 好困

【新智元导读】黄仁勋的预言成真！从Sora的梦幻视频到英伟达的3D通才模型，AI不再只是「看和说」，而是真正「动手」构建3D世界，开启机器人时代的无限可能。

黄仁勋没有吹牛！

AI不能只会看、会说、会生成，它还必须理解并遵守物理世界的规则。

现在，英伟达补上了关键拼图——

让AI从「生成画面」升级为「生成可行动的3D世界」，不仅能描述世界，还能一步步搭建世界、修改世界、纠错迭代。

时间拨回到两年前， 2024年2月。

OpenAI发布了一段「东京街头漫步」的Sora视频，震惊世界，硅谷集体狂欢。

人们高呼「现实不存在了」，仿佛人终于可以「言出法随」、重造万物。

但在一片喧嚣中，那个穿皮衣的男人始终保持冷静，甚至带有一丝不屑。

在2024年和2025年的多次演讲中，黄仁勋像复读机一样不断重复——「Physical AI」（物理AI）。

上下滑动查看

反驳视频生成模型的理由是这样的：

AI生成的视频很美，但如果你走进那个视频，试图拿起桌上的杯子，你的手会穿过去。 杯子没有重量，没有摩擦力，没有物理法则。那不是世界，那是动画片。下一波浪潮，必须是懂物理的AI。

当时，很多人以为这只是老黄的营销话术，最终目的是为了推销昂贵的Omniverse平台和RTX显卡。

直到CES 2026，大家才明白老黄说的对。

刚刚，我们发现英伟达甩出了一篇新年第一篇论文：3D通才模型。

链接：https://research.nvidia.com/p...\_3d-generalist-vision-language-action-models-crafting-3d-worlds

如果说ChatGPT是AI学会了「说话」，Sora是AI学会了「做梦」，那么英伟达的这个新模型，就是让AI真正「睁眼看世界，动手造世界」。

这是图形学的胜利，这是「硅基生命」长出四肢的前夜。

老黄没有画饼——

物理AI的「ChatGPT时刻」，在这一刻，正式降临。

英伟达开年首篇论文

手搓赛博房之家

这篇论文由英伟达和斯坦福大学合作，正式发表在今年第十三届国际三维视觉会议上，标题相当拗口——

《3D Generalist：Vision-Language-Action Models for Crafting 3D Worlds》（3D通才：用于构建三维世界的视觉-语言-动作模型）。

2026年3月20日至23日，第十三届国际三维视觉会议2在加拿大不列颠哥伦比亚省温哥华的温哥华会议中心以线下形式举行

我们要读懂这次技术革命，首先要从这篇论文标题里，把那个最核心的单词揪出来。

请盯住这个词：Action（动作/行动）。

这是整个逻辑的起点。

在过去的三年里，无论是Midjourney画图，还是Runway生成视频，AI扮演的角色都是「观察者」和「梦想家」。

它看了一亿张猫的照片，然后根据概率，在屏幕上预测下一排像素应该是什么颜色，从而凑出一只猫的样子。

它不知道猫有骨骼，不知道猫毛有触感，它只是在「模仿视觉信号」。

但英伟达的VLA（Vision-Language-Action）模型，彻底颠覆了这个逻辑。

它不再是画家，而是「全能手」。

你只要输入一句话，3D-GENERALIST就能输出包含完整3D布局的房屋。

这些3D布局包括材料、固定装置（比如门和窗户）、3D资产以及照明配置。

背后的理念是，构建一个既详细又与文本描述相符的3D环境，应该被视为一个过程，需要依次做出决策。

因此，通过场景级和素材级的策略，他们不断改进和优化这些3D环境。

在提出的框架中，第一个重要的模块是全景环境生成。

如图2所示，这个模块能够根据文本描述初始化一个基础的3D房间模型，包括墙壁、地板以及固定装置，如门和窗户。

为了避免传统方法过于简化或不切实际的问题，他们首先利用全景扩散模型生成一个360°的图像作为指导，然后通过逆图形技术构建3D环境。

图2：3D-GENERALIST全景环境生成概述。全景扩散模型生成引导性360°场景图像，然后房间布局估计模型、Grounded-SAM和视觉语言模型提取角落、窗户和门的信息。这些预测随后被用于通过程序化方式构建带有构件的3D房间

这个过程包括以下几个步骤：

1. 房间布局估算：利用全景图像和HorizonNet模型，推断出房间的基本结构，如墙壁、地板和天花板。
2. 固定装置分割：使用Grounded SAM技术对窗户和门进行分割。
3. 视觉-语言模型注释：通过GPT-4o这样的视觉-语言模型，分析每个分割区域，确定其类型（例如单扇门、双扇门、滑动门或折叠门）和材料（如门框、门体和门把手的材料）。
4. 过程化生成：最后，根据3D位置的相应信息，房间、门和窗户被逐步构建出来。

3D-Generalist 使用扩散模型生成全景图像，并通过逆向图形（inverse graphics）流水线来创建3D环境的结构。

3D-Generalist采用视觉-语言-动作（VLA）模型来生成代码，用于构建与修改最终3D环境的各个方面（材质、光照、素材与布局）。

该VLA通过一个自我改进训练循环进行微调，以优化与提示词（prompt）的对齐效果。

3D-Generalist还使用了另一个VLA来处理多样化的小物体摆放任务，即使 3D素材是无标注（unlabeled）的也能完成。

微调后（After Finetuning）， 3D-Generalist涌现出自我纠错行为。

研究团队还使用Florence-2框架，在由3D-Generalist生成的3D环境渲染得到的合成数据上训练一个视觉基础模型。

结果表明：其效果接近使用规模大几个数量级的真实数据所能达到的效果。

物理AI的ChatGPT时刻，已开启？

如果你认为黄仁勋费尽心机搞这个，只是为了让你玩游戏更爽，或者让视觉特效更便宜，那你严重低估了英伟达的野心。

英伟达不只是买买游戏显卡，更致力于解决「智能」算力问题。

这篇论文的真正战略意图，其实藏在英伟达宏大的「具身智能」（Embodied AI）版图中。

老黄早已押注机器人，他认为那是一个数万亿美元的机遇：

这次无疑是英伟达「秀肌肉」。

请看这个逻辑链条：

1. 我们想要全能的机器人（比如特斯拉Optimus，或英伟达Project GR00T）。
2. 机器人需要学会像人一样处理复杂的物理世界（怎么拿鸡蛋不碎？怎么在湿滑地板上走路？）。
3. 在真实世界里训练机器人太慢、太贵、且不可逆（你不能让机器人摔坏一万个鸡蛋，或者摔断一千次腿）。
4. 解决方案： 把机器人扔进「虚拟世界」里训练。

但是，以前的虚拟世界（模拟器）不仅搭建很慢，而且不够真实。

如果模拟器里的物理规则和现实不一样，机器人学出来的本事就是花拳绣腿，一上真机就扑街。

现在，新模型「3D通才」补上了这一环。

有了这个技术，英伟达可以瞬间生成数百万个包含不同物理变量的「虚拟平行宇宙」。

• 场景A：地板刚拖过，很滑，光线昏暗。
• 场景B：地板铺了地毯，摩擦力大，强光照射。
• 场景C：地板上散落着乐高积木，障碍物复杂。

在这个无限生成的「3D物理世界」里，机器人大脑可以在一天之内经历人类几百年的训练时长。它在虚拟世界里摔倒一亿次，就是为了在现实世界里稳稳地迈出第一步。

在英伟达的Omniverse生态中，研究团队使用Omniverse Replicator实现大规模合成数据生成，并支持域随机化（domain randomization）；而Isaac Lab提供可直接使用的具身载体（例如人形机器人），可在这些生成环境中进行机器人仿真。

这才是「物理AI」的终极目标：打通Sim-to-Real（从模拟到现实）的最后一公里。

黄仁勋构建的不仅仅是一个生成的引擎，它是硅基生命诞生的子宫。

所有移动之物，终将自主

当AI不仅掌握了人类的语言（GPT），掌握了人类的视觉（Sora），现在又掌握了构建物理世界的法则（Physcial AI）时，虚拟与现实的界限，将不再是泾渭分明的。

我们在屏幕里创造的世界，将拥有和现实世界一样的重力、光影和因果律。

而我们在现实世界里的机器人，将拥有在数亿个虚拟世界里磨练出来的智慧。

在2024年的SIGGRAPH大会上，黄仁勋曾说：「Everything that moves will be autonomous.」（所有移动之物，终将自主。）

当时我们以为他在说机器人。

现在看来，他说的是整个物理世界。

作者介绍

Fan-Yun Sun

Fan-Yun Sun是斯坦福大学AI实验室（SAIL）的计算机科学博士生，隶属于Autonomous Agents Lab和斯坦福视觉与学习实验室（SVL）。

在读博期间，他也深度参与了英伟达研究院的工作，曾效力于学习与感知研究组、Metropolis深度学习（Omniverse）以及自动驾驶汽车研究组。

他的研究兴趣主要在于生成具身（3D）环境与数据，用于训练机器人和强化学习策略；致力于推动具身、多模态基础模型及其推理能力的发展。

Shengguang Wu

Shengguang Wu目前是斯坦福大学计算机科学系的博士生，师从Serena Yeung-Levy教授。

他在北京大学获得硕士学位，导师为Qi Su教授；此前，他也曾在Qwen团队担任研究实习生。

他的研究致力于赋予机器跨多模态的类人学习与推理能力，并推动现实应用的落地。

• 多模态Grounding与推理：利用视觉洞察来优化基于语言的推理，同时引入文本反馈来指导细粒度的视觉感知。
• 自我提升：让AI智能体能够从交互中学习并持续自我进化——主动适应新信息，并随着新任务的出现不断成长。

Jiajun Wu

吴佳俊是斯坦福大学计算机科学系助理教授，同时兼任心理学系助理教授。

在加入斯坦福之前，他曾在Google Research担任访问研究员，与Noah Snavely合作。

他本科毕业于清华大学交叉信息研究院「姚班」，师从屠卓文（Zhuowen Tu）教授。在清华期间，他曾连续三年保持年级第一，并荣获清华大学最高荣誉——特等奖学金以及「中国大学生年度人物」称号。

随后，他在麻省理工学院获得电气工程与计算机科学博士学位，导师是Bill Freeman和Josh Tenenbaum。

吴佳俊的团队致力于物理场景理解的研究——即构建能够「看」见世界、进行推理并与物理世界互动的机器，其代表性项目包括Galileo、MarrNet、4D Roses、Neuro-Symbolic Concept Learner以及Scene Language。

除了开发表征本身，团队还同步探索这些表征在各个领域的应用：

• 多模态感知，代表项目如ObjectFolder和RealImpact；
• 4D物理世界的视觉生成，代表项目如3D-GAN、pi-GAN、Point-Voxel Diffusion、SDEdit和WonderWorld；
• 基于物理概念接地的视觉推理，代表项目如NS-VQA、Shape Programs、CLEVRER和LEFT；
• 机器人学与具身智能，代表项目如RoboCook和BEHAVIOR。

Shangru Li

Shangru Li是英伟达高级系统软件工程师，长期从事智能视频分析（IVA）和Metropolis平台的相关工作。

他拥有宾夕法尼亚大学计算机图形学与游戏技术工程硕士学位，以及广东外语外贸大学计算机软件工程学士学位。

其他华人作者还有：

• Haoming Zou (Stanford University)
• Yu-Hsin Chou (Stanford University)
• Xunlei Wu (NVIDIA)

编辑：KingHZ 定慧

【新智元导读】AI不是泡沫，而是人类史上最大基建狂潮！黄仁勋直言：已投数千亿，仅是开端，未来需数万亿美元打造「五层蛋糕」，从电厂到应用层全产业链爆发，就业机会前所未有。

突发！

腾讯科技独家新闻报道，2026年黄仁勋首度来华， 首站到访了英伟达在上海的新办公室，与员工交流，回顾公司2025年主要事件。

据报道，这次来华行程与2025年初基本一致，主要参加上海、北京和深圳分公司的新年晚会以及供应商答谢会。

腾讯科技：独家丨黄仁勋2026年首度来华，未提及H200

根据知情人士，黄仁勋和员工的诸多问题中，主要聚焦在2026年重点芯片相关的话题。

根据英伟达真实路线图，继Blackwell之后，2026年的重点大概率是Rubin架构。

而就在中国行前夕，黄仁勋在达沃斯世界经济论坛上的一番发言，正在全球科技界引发震动，让全场脊背发凉：我们正在犯一个历史性错误——

把AI当作技术，而不是电和路。

这句话背后，是一场数万亿美元的财富转移：

水管工、电工、建筑工人的收入未来或突破「六位数」，而坐在办公室里的白领，可能面临第一波AI冲击。

这不仅是科技革命，这是人类工作价值的重新定价。

人工智能（AI）爆发，已拉开「史上最大规模基础设施建设」的序幕。

规模到底有多大？

黄仁勋表示，尽管各大企业已为这项技术投入数千亿美元，但未来仍需持续投入巨额资金。「我们需要建设价值万亿美元级的基础设施。」

他认为，ASI基建新工种将涌现，预测未来美国的建筑工有机会实现「六位数」收入。

人类历史上最大规模基础设施建设

2026年1月21日，瑞士达沃斯，世界经济论坛（WEF）。

在一场挤得水泄不通的主论坛上，黄仁勋（下图右）与Larry Fink（下图左）展开了一场关于AI未来的深度对话，豪言AI是「人类历史上最大规模基础设施建设」的基石。

众所周知，黄仁勋是NVIDIA创始人兼CEO，是AI时代「算力之王」；而后者Larry Fink，也不简单，是华尔街的两枚定海神针之一贝莱德（BlackRock）共同创办人、董事长、CEO。

黄仁勋提到，2025年是有记录以来风险投资规模最大的年份之一，大部分资金流向他所称的「原生AI公司」。

这些企业遍布医疗、机器人、制造与金融服务领域。黄仁勋指出：「这是首次出现足够成熟的模型，能够支撑这些行业的深度开发。」

相关投资正直接转化为就业岗位。

他特别列举了当前紧缺的技术工种：水管工、电工、建筑工人、钢铁工人、网络技术员，以及负责安装运营高端设备的专业团队。

从熟练技工到初创企业，AI正开启下一次平台级变革。

对全球打工人来说，这场变革将推动工作重心从执行任务转向实现价值。

AI 之下，工作要有目的

面对大家对AI取代人类的担忧，黄仁勋给出了反直觉的有力反击：AI不会摧毁工作，它正在让工作从「完成任务」转向「实现人生价值」 。

他以放射科医生为例。

2016年，「AI教父」辛顿曾表示：「我们现在就应该停止培训放射科医生了」，因为AI很快就能比他们做得更好。

他说得没错：近十年来，模型在各项基准测试中的表现已超越放射科医生。

然而，放射科医生的岗位数量正处于历史最高水平，平均薪资高达52万美元。

为什么？

因为医生的使命是诊断疾病和救治病人，看片子只是任务之一 。

AI处理了看片子的任务，让医生能花更多时间与病人互动，从而能接诊更多病人，从而医院效益好了，自然需要更多放射科医生。

同样的逻辑也适用于护士。

美国正面临500万护士的短缺，部分原因是护士们近一半的时间都花在填表和记录上 。

AI接管了图表记录和转录工作后，护士的工作效率提高了，医院效益变好了，反而需要招募更多护士。

作为CEO，黄仁勋幽默比喻：「若有人观察我和Fink的工作，大概会觉得我俩是打字员。」

但自动化打字不会取代他们的CEO工作，因为打字并非核心价值。

再比如，黄仁勋盛赞Claude「不可思议」，宣称「所有软件公司都需要使用它」。

黄仁勋并非突然认同Anthropic的AI安全理念，而是折服于他们的工程能力。Claude Code正在以惊人速度吞噬企业软件开发市场，以至于英伟达这家硬件公司竟公开点名推荐特定模型。

这说明AI已跨越「新奇事物」的门槛，蜕变为软件行业基础设施。

AI通过协助事务性工作，让人更能聚焦核心使命，提升效能，从而创造更大价值。

「所以关键在于：你工作的本质价值是什么？」黄仁勋最后发问。

英伟达创始人兼首席执行官黄仁勋与贝莱德董事长兼首席执行官Larry Fink在2026年瑞士达沃斯世界经济论坛年会对话

在对话中，他也淡化了外界对巨额支出承诺可能导致AI泡沫的担忧。

五层蛋糕论

AI没有泡沫

据估计，仅2025年一年，全行业就将在AI研发上投入约1.5万亿美元——

这个数字超过了几乎所有其他领域任何企业集团的名义支出。

然而，黄仁勋坚持认为，这并不是过度投资。他说，这代表着人类历史上规模最大的基础设施建设，而这还只是刚刚开始。

他进一步解释称，在芯片领域，「台积电已宣布计划新建20座芯片工厂；富士康正与我们合作，还有纬创和广达，将新建30座计算机工厂，这些工厂后续将转化为AI工厂（数据中心）。」

「美光已开始在美国投资2000亿美元，SK海力士表现非常出色，三星也做得非常出色。你们可以看到，整个芯片行业正以惊人的速度增长，」黄仁勋补充说。

而且不止单一的芯片突破。

黄仁勋将AI产业精辟地拆解为五个核心层级，重申了他的「AI五层蛋糕论」：

1. 能源（Energy）：为AI提供动力的电力基础。
2. 芯片与计算基础设施（Chips and Computing Infrastructure）：硬件算力的基石。
3. 云数据中心（Cloud Data Centers）：承载计算的枢纽。
4. AI模型（AI Models）：智能的大脑。
5. 应用层（Application Layer）：最终创造经济效益的顶端。

他特别指出，最大的经济效益将来自应用层——

AI正在重塑医疗、制造、金融服务等行业，并改变整体经济中的工作性质。

从能源发电、芯片制造到数据中心建设与云端运维，黄仁勋表示AI建设已催生大量技术工种需求。

更关键的是，他用「价格」来反证泡沫论：

如果这是泡沫，算力应该不缺、租GPU应该越来越便宜；但现实相反——GPU 很难租到，算力现货租赁价格在上涨，不只是最新一代，连两代以前的GPU也在涨。

这意味着需求来自真实业务，而不只是投机资本烧钱。

黄仁勋还举了企业调整研发预算的例子：比如制药公司把一部分投入从湿实验室转向AI超算。

AI是电，是路，是生产力

黄仁勋将AI定位为国家关键基础设施。

「AI即基础设施，」他强调，各国应像对待电力或公路那样重视AI，「必须将AI纳入国家基础设施体系」。

他呼吁各国基于本土语言文化构建自主AI能力：「开发属于自己的AI，持续优化迭代，让国家智慧融入生态系统。」

Fink质疑是否只有高学历人群才能使用或受益于AI。

黄仁勋驳斥了这一观点。

「AI超级易用——这是历史上最简单的软件，」他表示，AI工具仅用两三年已触达近十亿用户。

因此，掌握AI素养正成为必备技能：「学习如何使用AI、引导它、管理它、设立防护栏、评估结果，这些能力与领导力和团队管理同等重要。」

回到「放射科医生」，RSNA（北美放射学会）主席、 斯坦福大学医学教授Curt Langlotz之前表达过类似的观点：

AI不会取代放射科医生，但会使用AI的放射科医生将取代不会使用 AI 的放射科医生。

欧洲的AI超车机会：物理AI

对于发展中国家，黄仁勋认为AI带来了缩小长期技术差距的契机：「AI很可能弥合技术鸿沟，普惠性与资源丰沛性将发挥关键作用。」

谈到欧洲时，他特别指出制造业与工业实力是巨大优势：AI不是写出来的，是教出来的。

「机器人是世代难逢的机遇，」黄仁勋强调，这对工业基础雄厚的国家尤为关键。

「如今我们可以将工业能力、制造能力与人工智能相融合，由此迈入实体AI即机器人技术的世界，」他补充说，这为欧洲带来了「跨越」由美国主导的软件时代的机遇。

「我认为，为了在欧洲构建繁荣的AI生态系统，我们必须认真对待能源供给的增长，加大对基础设施层的投资，这一点是确定无疑的，」 黄仁勋说道

Fink总结讨论时表示，这场对话说明世界远未形成AI泡沫，真正的问题在于：「我们的投资够吗？」

黄仁勋赞同这一判断，指出庞大投资势在必行：我们必须为AI技术栈的所有上层建筑构建必要基础设施。

他形容这一机遇「非同寻常，每个人都应参与其中」。

他重申2025年全球风投规模创历史新高，超千亿美元资金流向全球，其中大部分注入AI原生初创企业。「这些公司正在构建上层的应用生态，」黄仁勋说，「而它们需要基础设施与投资来筑造未来。」

Fink补充道，确保增长红利被广泛共享至关重要：

我相信全球养老基金参与这场变革将是绝佳投资机遇，能与AI世界共同成长。我们必须让普通养老金领取者和储蓄者分享这份增长。若只能作壁上观，他们将被时代抛在后面。

编辑：艾伦

【新智元导读】谷歌 DeepMind 发布 D4RT，彻底颠覆了动态 4D 重建范式。它抛弃了复杂的传统流水线，用一个统一的「时空查询」接口，同时搞定全像素追踪、深度估计与相机位姿。不仅精度屠榜，速度更比现有 SOTA快出 300 倍。这是具身智能与自动驾驶以及 AR 的新基石，AI 终于能像人类一样，实时看懂这个流动的世界。

如果是几年前，你问一位计算机视觉工程师：「我想把这段视频里的所有东西——无论它是静止的房子还是奔跑的狗——都在 3D 世界里重建出来，并且还能随时知道它们下一秒会去哪儿，需要多久？」

他大概会递给你一根烟，让你先去买几块顶级显卡，然后给你画一个由四五个不同模型拼凑起来的流程图：先算光流，再算深度，再估相机位姿，最后还得用一晚上的时间去跑优化，祈祷结果别崩。

但谷歌 DeepMind 刚刚发布的 D4RT（Dynamic 4D Reconstruction and Tracking），试图终结这种混乱。

这篇论文在计算机视觉领域扔下了一枚关于「效率革命」的重磅炸弹。

它把原本割裂的 3D 重建、相机追踪、动态物体捕捉，统一成了一个极简的「查询」动作。

更重要的是，它的速度比现有 SOTA技术快了 18 到 300 倍。

如果在你的认知里，高质量的 4D 重建还是好莱坞特效工作室里那些昂贵且缓慢的渲染农场，耗费漫长的时间等待生成完毕，那么 D4RT 正在把这种能力变成一种可以塞进机器人大脑甚至 AR 眼镜里的实时直觉。

Demo 演示

为了理解 D4RT 到底做到了什么，我们需要先看一眼它眼中的世界。

在论文展示的演示中，最直观的震撼来自于对「动态混乱」的驾驭能力。

想象一下这个画面：一只天鹅在水面上划过，或者一朵花在风中快速绽放。

传统的 3D 重建算法（比如 MegaSaM 或 ）处理这种场景通常是一场灾难——因为它们假设世界是静止的，所以它们往往会在 3D 空间里留下一串「重影」，就像老式胶片重叠曝光一样，天鹅变成了长着几十个脖子的怪物，或者花朵直接变成了一团无法辨认的噪点。

但 D4RT 给出的结果极其干净。

它不仅可以精准还原天鹅的 3D 形态，还完美剥离了相机的运动和天鹅自身的运动。

在它的视野里，时间变成了一个可以随意拖动的滑块。

更令人印象深刻的是它的全像素追踪能力。

你可以点击视频中花瓣上的任意一个像素，D4RT 就能画出这个点在过去和未来的完整 3D 轨迹，哪怕这个点在中间几帧被蜜蜂遮挡了，或者跑到了画面之外，模型依然能根据上下文「脑补」出它的去向。

这种视觉效果给人的感觉是：AI 不再是在一帧帧地「看」视频，而是把整段视频吞下去，在大脑里生成了一个完整的、流动的全息全景图，然后你可以随意从任何角度、任何时间去检视它。

模型能力对比图

拆解「神话」

是真的快，还是文字游戏？

科技公司发论文，数据通常都很漂亮。

作为观察者，我们需要剥离 PR 滤镜，看看数据背后的定语。

谷歌声称 D4RT 比之前的 SOTA 快了 300 倍，处理一分钟的视频只需要 5 秒钟。

这是真的吗？

答案是：在特定维度上，是真的。

这里的「300倍」指的是吞吐量，具体来说是「在保持相同帧率（FPS）的前提下，模型能同时追踪多少条 3D 轨迹」。

• 数据对比：在 24 FPS 的标准电影帧率下，之前的强者 SpatialTrackerV2 只能同时追踪 84条轨迹，再多就卡了；而 D4RT 可以轻松处理 1570条。如果是和 DELTA 这种更慢的模型比，那就是 314 倍的差距。

• 实际意义：这意味着之前的技术可能只能盯着画面里的主角（比如一个人），而 D4RT 可以同时盯着背景里走动的路人、飘落的树叶和远处的车流——即所谓的「全像素级感知」。

它比同类技术强在哪儿？

目前市面上的 4D 重建技术主要分两派：

1. 「拼装派」（如 MegaSaM）：把深度估计、光流、分割等多个现成模型串起来。虽然效果不错，但不仅慢，而且一旦一个环节出错（比如光流飘了），后面全完。
2. 「多头派」（如 VGGT）：虽然是一个大模型，但为了输出不同的任务（深度、位姿、点云），需要挂载不同的解码头，结构臃肿。

D4RT 的牛，在于它做到了架构层面的统一。

它不需要为深度单独做一个解码器，也不需要为位姿单独做一个。

它只用同一个接口解决所有问题。

有没有代价？当然有。

D4RT 的「快」主要体现在推理阶段。

在训练阶段，它依然是一个庞然大物。它的编码器使用了 ViT-g，拥有 10 亿参数，并且需要在 64 个 TPU 芯片上训练两天。

这绝不是普通开发者在自家车库里能复现的玩具，它是典型的「大厂重武器」。

技术解码

把 4D 重建变成「搜索引擎」

那么，D4RT 到底是怎么做到的？

论文的核心逻辑可以用一句话概括：先全局「阅读」视频，再按需「搜索」答案。

不再逐帧解码，而是「全局记忆」

传统的视频处理往往是线性的，处理第 10 帧时可能已经「忘」了第 1 帧的细节。

D4RT 的第一步是使用一个巨大的 Transformer 编码器（Encoder），把整段视频压缩成一个全局场景表征（Global Scene Representation, F）。

你可以把这个 F 想象成 AI 对这段视频形成的「长期记忆」。

一旦这个记忆生成了，原本庞大的视频数据就被浓缩在了这里。

「哪里不会点哪里」的查询机制

这是 D4RT 最天才的设计。它发明了一种通用的查询（Query）语言。

当 AI 想要知道某个像素的信息时，它会向解码器（Decoder）发送一个查询 q：

这个公式翻译成人话就是：

「请告诉我：在 这一帧图像上坐标为 的那个点，它在 这个时间时刻，如果从 这个相机的视角看过去，它的 3D 坐标在哪里？」

• 如果你想生成深度图：就问「现在这个点在现在的相机里多远？」（让 ）。
• 如果你想做轨迹追踪：就问「这个点在第 1 帧、第 2 帧……第 N 帧都在哪？」（固定 ，改变 ）。
• 如果你想重建点云：就问「视频里所有点在同一时刻的世界坐标在哪？」（把所有点都映射到同一个 ）。

并行计算的艺术

因为每一个查询（Query）都是独立的，D4RT 不需要像穿针引线一样按顺序计算。

它可以一次性扔出几万个问题，利用 GPU/TPU 的并行能力同时算出答案。

这就是为什么它能比别人快 300 倍的根本原因：它把一个复杂的串行几何问题，变成了一个大规模并行的搜索问题。

关键的「作弊」技巧：9×9 Patch

论文作者还发现了一个有趣的细节：如果只告诉解码器坐标点，AI 有时候会「脸盲」，分不清纹理相似的区域。

于是，他们在查询时顺便把那个像素点周围 9×9的小方块图像（RGB Patch）也喂给了模型。

这就像是你让人在人群中找人，光给个坐标不行，还得给他一张那个人脸部的特写照片。

消融实验证明，这个小小的设计极大地提升了重建的锐度和细节。

产业影响

谷歌的野心与具身智能的眼睛

D4RT 的出现，对谷歌现有的业务版图和未来的 AI 战略有着极强的互补性。

具身智能与自动驾驶的最后一块拼图

现在的机器人之所以笨，很大程度上是因为它们「看不懂」动态环境。

一个扫地机器人能避开沙发，但很难预判一只正在跑过来的猫。

D4RT 提供的实时、密集、动态的 4D 感知，正是机器人急需的技能。

它能让机器人理解：那个东西不仅现在在那里，而且下一秒它会出现在我左边。

对于自动驾驶而言，这种对动态物体（如行人、车辆）的像素级轨迹预测，是提升安全性的关键。

增强现实（AR）的基石

谷歌一直在 AR 领域寻找突破口（从当年的谷歌眼镜，到现在的 Project Astra）。

要在眼镜端实现逼真的 AR，必须要有极低延迟的场景理解。

D4RT 展示的高效推理能力（尤其是在移动端芯片上的潜力），让「实时把虚拟怪兽藏在真实沙发后面」变得在工程上可行。

对普通人的影响

视频编辑的「魔法化」

对于普通用户，这项技术最快落地的场景可能是手机相册和视频编辑软件。

想象一下，你拍了一段孩子踢球的视频。

有了 D4RT，你可以像在《黑客帝国》里一样，在视频播放过程中随意旋转视角（尽管你拍摄时并没有移动），或者轻易地把路人从复杂的背景中「扣」掉，甚至改变视频中光源的方向。

这是 D4RT 这种 4D 重建技术成熟后的应用之一。

结语

D4RT 让我们看到了一种新的可能性：AI 对世界的理解，正在从二维的「图像识别」跨越到四维的「时空洞察」。

它告诉我们，要看清这个流动的世界，关键不在于每一帧都看得多仔细，而在于如何建立一个能够随时回应疑问的全局记忆。

在 AI的眼中，过去并没有消逝，未来也不再不可捉摸，它们只是同一个四维坐标系里，等待被查询的两个不同参数而已。

编辑：桃子

【新智元导读】英伟达护城河要守不住了？Claude Code半小时编程，直接把CUDA后端迁移到AMD ROCm上了。

一夜之间，CUDA护城河被AI终结了？

这几天，一位开发者johnnytshi在Reddit上分享了一个令人震惊的操作：

Claude Code仅用了30分钟，便将一段完整的CUDA后端代码，成功移植到AMD的ROCm上。

整个过程，没有手写一行代码。

这架势，简直是要填平这两个生态系统之间的鸿沟。

更关键的是，这次移植完全没有依赖传统的「中间转换工具」，如Hipify翻译层，而是一键通过CLI完成。

就连AMD软件副总Anush E.为之震惊，GPU编程的未来，是AI智能体的。

消息一出，整个科技圈瞬间沸腾，很多人直呼：英伟达CUDA护城河要守不住了…..

这究竟是怎么回事？

Claude手撕CUDA，仅30分钟

Claude Code是在一个智能体框架运行的，这意味着它可以自己「动脑子」。

在执行过程中，他不会机械地转换关键词，而去真正理解代码，即特定核函数的底层逻辑。

开发者johnnytshi介绍，这次移植中，最棘手的数据布局差异问题也被AI解决了，确保了内核核心计算逻辑保持一致。

令人惊叹的是，johnnytshi在短短30分钟内，就把整个CUDA后端移植到了AMD ROCm上，而且中间没用任何翻译层。

另外一个好处当然是，不用费劲去搭像Hipify这种复杂的翻译环境了；直接在命令行（CLI）里就能干活。

如今，全网都被CUDA护城河被攻破呼声淹没了。

毕竟，英伟达霸主地位，很大程度上建立在CUDA这个几乎成为行业标准的编程生态上。

无数AI框架、深度学习库、科学计算工具都深度依赖它。

AMD的ROCm虽然功能强大，却一直面临生态兼容性，以及开发者迁移成本高的痛点。

现在，一个Claude却用极短时间踢碎了门槛，说不定未来更多CUDA代码可能轻松在AMD GPU跑起来了。

实现细节

GitHub中，johnnytshi本人也更新了日志和说明。

为AMD GPU实现了完整的ROCm后端，从而在RDNA 3.5及其他AMD架构上支持基于注意力机制的现代国际象棋网络。

GitHub：https://github.com/LeelaChess...

• 在src/neural/backends/rocm/中添加了完整的ROCm后端
• 实现了注意力网络架构（多头自注意力、FFN、嵌入层）
• 使用rocBLAS进行GEMM运算，使用MIOpen进行卷积运算
• 针对RDNA 3.5上的FP16性能优化了NCHW布局
• 提供三种后端变体：rocm (FP32)、rocm-fp16 (FP16)、rocm-auto (自动检测)
• MIOpen是必选依赖（类似于CUDA的cuDNN）
• 通过rocm\_agent\_enumerator自动检测AMD GPU架构
• 编译选项：-Drocm=true -Damd\_gfx=gfx1151（或使用自动检测）

性能说明：

• FP16性能：在Strix Halo (Radeon 8060S, gfx1151) 上 >2000 nps
• 自动Batch Size调优（RDNA 3.5上min\_batch=64）
• 测试过rocWMMA，但rocBLAS性能更好

验证情况（Strix Halo – Radeon 8060S, gfx1151）：

• 测试模型：768x15x24h-t82-swa-7464000.pb.gz 和 maia-1900.pb.gz
• 后端：rocm-fp16功能正常，能生成正确的走法
• 环境：ROCm 7.2.53150, MIOpen 3.5.1
• 注：仅在RDNA 3.5上进行了测试；其他AMD架构暂未验证

GPU未来，是AI智能体主场

当然，这次演示也有局限性。

对于简单或中等复杂度的内核，Claude Code表现得非常出色。更重要的是，写核函数的核心就在于搞定「深度硬件」优化。

不过，一部分觉得Claude Code在这方面还是差点火候——

如果遇到那些针对特定硬件缓存层级，内存访问模式做过极致优化的复杂内核，AI目前还难以完全取代人类专家。

即便如此，这一事件释放出的信号已经足够强烈。

过去几个月，ZLUDA项目、还有微软内部的尝试，都想要打破CUDA的垄断。

但它们大多依赖规则映射或中间层，自动化程度和智能水平有限。

Claude Code代表的智能体式编程，直接跳过了这些环节，用「理解+自主决策」的方式填平生态鸿沟。

正如AMD软件副总所言，GPU编程的未来，是AI智能体主场。

全员AI编程，浓度高达100%

如今的Claude Code已经让整个硅谷入坑了（Claude-Pilled）。

两天前，CEO Dario Amodei在达沃斯上再出暴论：软件工程师们没有时间了。未来6-12个月，AI能够彻底取代这些人！

甚至，Anthropic内部工程师已经不再手写代码了，全是Claude完成。

别不信，是真的。

就在Wired最新采访中，Claude Code之父Boris Cherny坦承，「自己100%代码都是AI写的」。

或许Anthropic工程师怎么也没有想到，一个「副业项目」竟让硅谷如此狂热。

Boris Cherny回忆道，「一年前我们发布Claude Code时，甚至不确定『智能体编程』能不能成，但火爆来得太快了」。

Cherny个人经历就是最好的缩影：

刚发布时，他只有5%代码是用Claude Code写的；

到了去年5月，有了Opus 4和Sonnet 4，这个比例变成了30%；

而现在，有了Opus 4.5，他在过去两个月里100%的代码都是由Claude Code完成。

在Anthropic内部，这种全员AI化更是到了极致。

几乎100%技术员工都在使用Claude Code，甚至连Claude Code团队本身95%的代码也是由自身写出来的。

斯坦福AI教授都在用了

不得不说，AI编程的进化速度令人咋舌。

回望2021到2024年，大多数工具不过是高级版的「自动补全」，在开发者打字时卑微地建议几行代码。

但到了2025年初，随着Cursor和Windsurf等初创发布早期的Agentic编程产品，游戏规则改变了——

开发者只需用大白话描述功能，剩下的脏活累活全扔给AI智能体完成。

Claude Code也在这个时间点，真正诞生了。

Boris Cherny坦承，早期版本也曾跌跌撞撞，甚至陷入死循环。但Anthropic下了一步狠棋：不为当下的AI能力开发产品，而要为AI即将抵达的未来而构建。

这一赌注押对了。随着Anthropic下一代旗舰Claude Opus 4.5的发布，AI编程迎来了真正的「拐点」。

斯坦福大学AI讲师、Workera CEO Kian Katanforoosh最近就把公司全员迁移到了Claude Code。

他直言，对于高级工程师来说，Claude Code比Cursor、Windsurf更能打。

Katanforoosh感叹道，最近唯一让我看到编程能力有阶跃式提升的模型，就是Claude Opus 4.5。

「它给人的感觉不像是在模仿人类写代码，而是它真的找到了一种更聪明的解决路径」。

据传，微软内部也在大规模采用Claude Code了。

年入超10亿美金的「副业」

Claude Code大获成功，给Anthropic带来了最直观的效益。

去年，AI编程智能体业务彻底爆发。11月，Anthropic宣布Claude Code在上线不到一年内，年度经常性收入（ARR）就突破了10亿美元。

到2025年底，ARR至少又增长了1亿美元。

彼时，该产品约占Anthropic总ARR（约90亿美元）的12%。虽然比起向大企业提供 AI 系统的核心业务来说还算「小弟」，但它已是公司增长最快的板块之一。

尽管Anthropic在AI编程领域看似独孤求败，但Claude Opus 4.5的光环其实照亮了整个赛道。

竞争对手Cursor也在11月达到了10亿美元ARR，OpenAI、谷歌和xAI更是磨刀霍霍，试图用自研模型分一杯羹。

但Anthropic没打算停下。

前几天，他们又发布了Cowork——这是一款面向非编程领域的AI智能体。

它能管理你电脑里的文件、操作各种软件，而且完全不需要你在代码终端里敲命令。

不是取代，是进化

提及Cowork时，Cherny透露自己已经用疯了。

比如项目管理，他会让Cowork盯着工程师的任务表格，谁没填名字，AI就会自动在Slack上发消息催人。

Cherny感慨道，「这是我当工程师以来最爽的时候，因为我不再需要做那些枯燥乏味的脏活了」。

面对那些因不再需要亲自写代码而感到失落的工程师，Cherny给出了他的建议：

这行业一直在变。我祖父在苏联用穿孔卡片编程；后来变成了机器码；再后来是C语言、Java、Python。

这是一条不断抽象化的连续体，AI智能体只是这条线上的最新一个点。

如今，Cherny每天早上起床会在手机上启动3-4个编程智能体，到了公司再在终端里开几个。

任何时候，他都有五到十个智能体在跑任务。

Cherny总结道，「AI智能体将接管生活中所有繁琐的事——填表、搬运数据、发邮件。这会具有颠覆性，我们必须适应」。

话又说回来，Anthropic能不能先解决下Claude使用量？

SSL证书通常是颁发给域名的，但是有些企业没有域名只有 IP，或者不方便使用域名，IP 地址要实现https加密，这时可申请IP SSL证书。下面将从IP SSL证书的作用、申请条件和申请流程三个方面来让您详细了解 IP SSL证书。

申请IP SSL证书的作用

• 1、用 IP SSL证书可以很好地防流量劫持。
• 2、IP 地址比域名复杂，不容易记忆，有了企业型IP SSL证书，可以有效提高IP的身份辨识度，减少被假冒的风险；
• 3、IP 能直达设备，应用更广。

申请IP SSL证书要满足的条件：

• 1、确定IP能正常访问
• 2、申请者必须有该IP的管理权限；
• 3、只可以申请单个IP SSL证书，不支持IP段通配符证书。

IP SSL证书的类型

• DV型IP证书：仅需验证域名所有权，签发速度快，几分钟即可获得证书。
• OV型IP证书：不仅需要验证域名所有权，还需进行企业信息验证，签发时间大概需要1-3个工作日
  备注：内网IP和公网IP证书不通，需要确认好。
  

申请 IP SSL证书的流程

1、选择可信赖的CA机构

IP SSL证书申请入口

访问JoySSL官网,注册一个证书账号，填写注册码230970，获取技术支持。

2、选择合适的 IP SSL证书，DV 或 OV，提交订单。

3、生成 CSR 文件和 Key，下载 CSR 文件和 Key 并保存在安全的位置。

4、配合完成验证。

DV型 IP SSL证书的验证方式：验证 IP 管理权限，上传指定验证文件到网站根目录（通过 80 或 443 端口验证）。一般 10分钟内就可完成验证。

OV型 IP SSL证书的验证方式：除了上述 DV 型 IP SSL证书的验证方式外，还要验证公司真实性，以电话或邮件方式进行企业审核。1-3 个工作日可完成验证。

5、获取 IP SSL证书，部署到服务器上。