2026年3月

Zyxel 已发布关键固件更新,修复其多款网络设备中的多个严重漏洞,涉及 4G LTE/5G NR CPE、DSL / 以太网 CPE、光纤 ONT、安全路由器及无线扩展器。
这些漏洞会导致受影响设备面临远程命令注入与 拒绝服务(DoS) 攻击风险。

安全公告中披露了由安全研究员 Tiantai Zhang、Víctor Fresco 与 Watchful IP 发现的7 个独立漏洞

其中最危险的为未授权命令注入漏洞,同时还存在多个需认证的命令注入漏洞与空指针解引用漏洞。


攻击原理与风险分析

最严重的威胁来自 CVE-2025-13942(CVSS 9.8),攻击者可无需身份认证直接实现远程代码执行(RCE)
恶意攻击者只需构造并发送特制的 UPnP 请求,即可完全接管设备操作系统
幸运的是,受影响的 Zyxel 设备默认关闭 WAN 侧访问权限,具备一定的天然防护能力。
CVE ID 漏洞类型 影响与攻击方式
CVE-2025-13942 命令注入(UPnP) 远程攻击者可通过构造 UPnP SOAP 请求执行任意系统命令
CVE-2025-13943 认证后命令注入 已认证用户可通过日志文件下载功能执行系统命令
CVE-2026-1459 认证后命令注入 管理员可通过 TR-369 证书下载 CGI 执行系统命令
CVE-2025-11845 空指针解引用 向证书下载 CGI 发送特制 HTTP 请求可导致设备 DoS
CVE-2025-11846 空指针解引用 向账户设置 CGI 发送畸形 HTTP 请求可导致设备 DoS
CVE-2025-11847 空指针解引用 向 IP 设置 CGI 发送畸形 HTTP 请求可导致设备 DoS
CVE-2025-11848 空指针解引用 向网络唤醒 CGI 发送特制请求可导致设备崩溃(DoS)
只有当用户手动同时开启 WAN 访问与存在漏洞的 UPnP 功能时,设备才会被成功攻击。
同样,拒绝服务漏洞与认证后命令注入漏洞的利用,都需要攻击者先获取管理员密码。

数十款具体型号受到影响,涵盖主流企业与家用设备系列。以下是受CVE-2025-13942影响的典型设备列表:
设备类别 受影响型号 受影响版本 已修复版本
4G LTE/5G NR CPE Nebula NR7101 1.16 (ACCC.1) C0 及更早 1.16(ACCC.1)V0
DSL/Ethernet CPE DX4510-B0 5.17 (ABYL.10) C0 及更早 5.17(ABYL.10.1)C0
Fiber ONTs PX5301-T0 5.44 (ACKB.0.5) C0 及更早 5.44(ACKB.0.6)C0
Wireless Extenders WX5610-B0 5.18 (ACGJ.0.4) C0 及更早 5.18(ACGJ.0.5)C0
Zyxel 已为绝大多数受影响产品发布固件更新。
但部分受 CVE-2026-1459 影响的 DSL / 以太网 CPE 型号(如 DX5401-B1 和 EMG3525-T50B)预计将在 2026 年 3 月 发布官方补丁。

为保障网络安全,管理员需立即采取以下措施:
缓解措施 说明
升级固件 从官方支持门户或社区论坛下载并安装最新固件
限制 WAN 访问 若非必需,禁用外部接口的 WAN 访问与 UPnP 功能
更新凭证 修改默认或弱口令,防止认证后漏洞被利用
联系运营商 运营商提供的设备请联系服务商获取定制固件更新

谷歌在 AI 图像生成领域再次实现关键突破!今日,谷歌正式推出Nano Banana 2 模型,这是一款由 Gemini 3.1 Flash Image 驱动的新一代图像生成模型。新版本不仅继承了前代 Nano Banana Pro 强大的世界知识与推理能力,更将生成速度提升至极速级别,未来将全面接入谷歌全系产品体系。
当前,AI 图像工具的竞争日趋白热化,生成速度与生成精度成为决定产品竞争力的核心指标。据官方介绍,全新 Nano Banana 2 在高画质高效率之间实现了完美平衡,让原本仅面向专业用户的强大能力走向普及。
在此之前,Nano Banana Pro 虽可生成接近真实、难以分辨的超写实图像,但受限于巨大的计算开销与漫长的生成时间,甚至一度因访问量过大而被官方限制使用。如今,Nano Banana 2 彻底解决了这一核心短板。
它不仅保留了 Pro 版强大的世界知识能力 —— 即实时从互联网获取最新信息与图像素材,生成精准信息图表与结构图 —— 还大幅提升了创作效率。
这意味着创作者只需输入一次提示词,就能在极短时间内完成快速编辑与多次迭代。此外,Nano Banana 2 还强化了文本渲染能力,可在图像中直接生成营销物料、贺卡所需的精准文字排版。

在核心规格上,Nano Banana 2 带来多项重大升级:

角色一致性

模型可在单次创作流程中,保持最多 5 个不同角色的外观统一。对于需要制作分镜、连续视觉故事的创作者而言,这是一项极具实用价值的核心功能。

精致细节与高保真画质

支持最高 4K 分辨率 输出,纹理更丰富、细节更清晰,超越此前所有版本。

指令精准执行

模型对复杂、多层级提示词的遵循度大幅提升,确保最终生成内容与用户创作意图高度一致。


伴随 Nano Banana 2 发布,谷歌同时宣布对旗下产品体系进行全面升级与调整。

Nano Banana 2 将正式替代原有 Nano Banana Pro 成为 Gemini App 默认图像模型

而 Google AI Pro 与 Ultra 订阅用户,仍可在专业场景中继续调用 Nano Banana Pro。

此外,Nano Banana 2 还将立即成为谷歌搜索 “AI 模式”、Google Lens 以及 Flow AI 创意工作室的默认图像模型

谷歌推出 Nano Banana 2 的战略意图十分明确:以速度换取更广泛的场景覆盖

过去,Nano Banana Pro 虽展现了谷歌在图像生成领域的顶尖实力,但计算缓慢、成本高昂始终是大规模普及的短板。

基于 Gemini 3.1 Flash Image 架构打造的 Nano Banana 2,如同在轻量化框架中装入顶级引擎,让普通用户也能在瞬间获得专业级的文字渲染与角色一致性体验

尤其值得关注的是,5 个角色保持视觉统一的能力,直接弥补了当前 AI 绘画在漫画创作、商业分镜制作中最明显的缺陷。

未来的核心看点在于:这款主打极速生成的全新模型,在面对海量、复杂提示词的真实场景时,能否稳定保持官方宣称的 4K 画质与写实效果,并彻底避免传统 AI 生成图像常见的各类瑕疵。

FreeBSD 官方已披露一处高危安全漏洞,编号 CVE-2025-15576。攻击者可利用该漏洞突破 Jail 隔离环境,未授权访问完整的宿主机文件系统。
该漏洞影响 FreeBSD 14.3FreeBSD 13.5 版本,未打补丁的系统将面临极高安全风险。

FreeBSD 漏洞详情

FreeBSD Jail 是一项强大的操作系统级虚拟化技术,系统管理员通常用它在类似 chroot 的受限环境中安全隔离进程
正常情况下,Jail 内的进程会被严格限制在指定的文件目录树中,形成坚固的安全边界,避免隔离内的进程威胁宿主机安全。
本次漏洞源于 nullfs 挂载Unix 域套接字之间的异常交互。
nullfs 是一种伪文件系统,允许管理员将目录挂载到文件结构中的其他位置;Unix 域套接字则用于本地进程间通信。
要利用该漏洞,攻击者需要控制两个同级且相互独立的 Jail 内运行的进程。
这两个 Jail 必须通过 nullfs 挂载共享同一个目录
满足上述条件后,恶意进程可通过共享目录中的 Unix 域套接字建立连接,并传递目录文件描述符
在常规文件系统名称查找过程中,内核会检查操作是否试图越出当前 Jail 的根目录。但在上述特定传递流程中,边界校验存在缺陷
若内核在查找过程中未检测到 Jail 根目录,访问限制就会被绕过。
Jail 内的进程可获取指向隔离环境外部的目录描述符,从而破坏 chroot 隔离机制,获得宿主机文件系统的完全访问权限
分类 详情
CVE 编号 CVE-2025-15576
影响组件 内核 / Jail 模块
受影响版本 FreeBSD 14.3、FreeBSD 13.5
利用条件 需要共享 nullfs 挂载与 Unix 域套接字
临时缓解方案
官方补丁 已发布

影响范围与修复建议

CVE-2025-15576 危害极高,因为它直接破坏了 FreeBSD Jail 的核心安全能力。
成功突破 chroot 环境后,攻击者可访问或执行宿主机上的任意文件,可能导致整个基础设施被完全控制
目前暂无有效缓解措施,管理员必须立即升级受影响系统
FreeBSD 官方已为所有受影响分支发布安全更新。用户可通过系统自带更新工具执行标准获取与安装命令,完成后重启系统即可修复。
使用自定义编译版本的管理员,可手动下载源码补丁,验证 PGP 签名后重新编译内核并重启,确保更新生效。

Cofense Intelligence 安全研究人员发现了一类隐蔽性持续增强的恶意软件传播活动,其攻击过程完全绕过传统浏览器。攻击者利用 Windows 中一项被忽视的旧版协议,将用户熟悉的Windows 文件资源管理器变成了隐蔽通道,用于投放极具破坏力的远程控制木马(RAT)

此次攻击的核心,是滥用 **WebDAV(基于 Web 的分布式创作与版本控制)** 协议。

Cofense 在报告中指出:“研究团队持续监测到,攻击者正在滥用 Windows 文件资源管理器通过 WebDAV 协议加载远程文件的能力,借助这种基于 HTTP 的文件管理协议,诱骗用户下载恶意程序。”

WebDAV 是一套基于 HTTP 运行的旧式文件管理协议。尽管如今已被现代云存储方案大量替代,但Windows 文件资源管理器仍原生支持,可用于访问远程文件服务器。黑客正是看中了这种系统级集成能力,将其作为完美伪装。

当受害者被诱导打开 WebDAV 链接(通常伪装成无害的.url.lnk快捷方式)时,文件资源管理器会弹出一个与本地文件夹完全一致的窗口。

危险之处在于用户心理:Cofense 提到,在文件资源管理器中打开 WebDAV 链接,远比在浏览器中下载文件更隐蔽,用户几乎察觉不到文件正在被下载

更危险的是,这种手段可以绕过标准边界防御

由于恶意文件直接通过操作系统的文件管理器加载,该攻击完全绕过浏览器安全控制,同时因利用了非常见攻击向量,还可能绕过部分终端检测与响应(EDR)系统

此类攻击最危险的特性之一,与 Windows 处理UNC 路径 URL 快捷方式的机制缺陷有关。

研究人员表示:“当用户浏览包含 UNC 路径 URL 快捷方式的目录时,该文件会自动向外发起连接,尝试访问攻击者服务器,从而直接提醒攻击者:Payload 已在目标主机上线。”

这意味着受害者甚至无需点击恶意文件,仅打开所在文件夹就会触发 DNS 查询,直接暴露自己。

为托管恶意 WebDAV 服务,攻击者大量借助合法基础设施隐藏行踪。

报告显示:“多个相似攻击活动均滥用 Cloudflare Tunnel 的演示实例(trycloudflare [.] com)搭建 WebDAV 服务。”

由于流量经过可信的 Cloudflare 域名,安全分析师很难一眼识别出恶意行为。

一旦连接建立,攻击者便会投放 Payload。

Cofense 数据显示,使用该战术的高级威胁报告中,高达 87% 最终会投递多款远程控制木马,包括知名的 XWorm RAT、Async RAT、DcRAT 等。

主要攻击目标集中在欧洲企业环境。数据显示,50% 的攻击使用德语邮件伪装成财务发票,其次为英语(30%)、意大利语和西班牙语。

在企业级应用开发中,RTF (Rich Text Format) 格式虽因其良好的兼容性曾在文档交换领域占据一席之地,但随着移动办公和长期归档需求的增加,其跨平台显示不一致、易被篡改的弊端日益凸显。

将 RTF 转换为 PDF 不仅能确保文档在任何设备上的布局高度一致,还能满足法律合规与数字化归档的严苛要求。本文将介绍如何利用 Spire.Doc for Java 这一强大的类库,在不依赖 Microsoft Office 的环境下,通过寥寥几行代码实现高保真转换。


1. 为什么选择 Spire.Doc for Java?

在 Java 生态中,处理文档转换的工具并不少,但 Spire.Doc for Java 以其“轻量化”和“高保真”脱颖而出。

  • 独立性:无需在服务器安装 Word 或任何第三方组件。
  • 精准度:能够完美还原 RTF 中的复杂元素,包括嵌套表格、浮动图像、页眉页脚及特殊字体。
  • 多样化:支持从基础转换到 PDF/A 归档标准的进阶需求。

安装与集成

你可以通过以下两种主流方式将库引入项目:

Maven 配置

pom.xml 中添加依赖:

<repositories>
    <repository>
        <id>com.e-iceblue</id>
        <name>e-iceblue</name>
        <url>https://repo.e-iceblue.cn/repository/maven-public/</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>e-iceblue</groupId>
        <artifactId>spire.doc</artifactId>
        <version>14.2.4</version>
    </dependency>
</dependencies>

2. 核心实战:基础转换流程

RTF 到 PDF 的转换遵循“加载-解析-渲染-保存”的标准流式操作。Spire.Doc 提供了简洁的 API,仅需三步即可完成。

基础代码示例

import com.spire.doc.*;

public class RtfToPdf {
    public static void main(String[] args) {
        // 1. 实例化 Document 对象
        Document doc = new Document();
        
        // 2. 加载 RTF 源文件
        // 显式指定 FileFormat.Rtf 可提高解析准确度
        doc.loadFromFile("input.rtf", FileFormat.Rtf);
        
        // 3. 将文档渲染为 PDF 格式并保存
        doc.saveToFile("output.pdf", FileFormat.PDF);
        
        // 4. 释放资源(重要:避免在大规模处理时内存溢出)
        doc.dispose();
        
        System.out.println("转换成功:RTF 文档已安全转换为 PDF。");
    }
}

3. 进阶场景:满足专业业务需求

在实际生产环境中,简单的转换往往不够,我们通常需要针对打印或归档进行定制。

A. 页面布局优化(设置页边距)

如果 RTF 原始布局在 PDF 中显得过于拥挤,可以通过 Margins 类进行动态调整。

Document doc = new Document();
doc.loadFromFile("input.rtf", FileFormat.Rtf);

// 自定义页边距(单位:磅/Point),顺序为:上、左、下、右
doc.getSections().get(0).getPageSetup().getMargins().setAll(50f);

doc.saveToFile("custom_layout.pdf", FileFormat.PDF);
doc.dispose();

B. PDF/A 长期归档标准

对于政务或金融行业,通常要求 PDF 符合 PDF/A-1b 标准,以确保文件在数十年后仍能被正确读取。

// 在保存时指定 PDF_A_1B 格式
doc.saveToFile("archive.pdf", FileFormat.PDF_A_1B);

C. 工业级应用:批量转换

面对成千上万的历史存量 RTF 文件,手动处理显然不现实。利用 Java 的 File 过滤器可以实现自动化批处理。

import java.io.File;

public class BatchProcessor {
    public static void main(String[] args) {
        File folder = new File("./rtf_files");
        File[] rtfs = folder.listFiles(f -> f.getName().endsWith(".rtf"));

        if (rtfs != null) {
            for (File rtf : rtfs) {
                Document doc = new Document();
                doc.loadFromFile(rtf.getAbsolutePath(), FileFormat.Rtf);
                
                String outputPath = rtf.getAbsolutePath().replace(".rtf", ".pdf");
                doc.saveToFile(outputPath, FileFormat.PDF);
                doc.dispose();
                System.out.println("已处理: " + rtf.getName());
            }
        }
    }
}

4. 核心 API 速查表

功能关键方法/常量适用业务场景
标准转换doc.saveToFile(path, FileFormat.PDF)通用的文档分发、跨平台预览与在线查看
格式控制doc.getSections().get(0).getPageSetup().getMargins()针对纸质打印输出的排版校准与布局优化
合规归档FileFormat.PDF_A_1B法律文书、银行账单、医疗病历的长久保存标准
性能优化doc.dispose()在大批量文件循环转换时,及时释放内存资源,防止溢出

结语

通过 Spire.Doc for Java,开发者可以摆脱 Office 进程阻塞、排版乱码等传统痛点,实现高效、稳定的 RTF 到 PDF 转换。无论是单文件即时生成,还是大规模自动化归档,这一方案都能提供卓越的支持。

上个月,吴恩达团队针对当前 AGI 概念被过度炒作、定义模糊且标准混乱的问题,提出了一套以实际工作能力为核心的新版图灵测试,旨在重新界定 AGI、校准行业与公众预期,避免因虚高期待引发 AI 泡沫与行业寒冬。

 

该测试让 AI 或熟练人类在配备网络、浏览器、Zoom 等常用软件的电脑环境中,接受评委设计的、持续数天的真实工作任务,包含培训、执行与反馈环节,且任务内容不提前透露,评委可灵活设计场景;若 AI 能像专业人类一样高质量完成具备经济价值的工作,即视为通过测试。这一测试相比传统图灵测试更贴合现代 AI 目标,不再以 “欺骗人类评委” 为标准,而是聚焦真实生产力;同时也优于 GPQA、SWE‑bench 等固定基准测试,避免模型被针对性优化,能真正检验智能的通用性,也与大众对 AGI 的普遍认知一致。推出这套测试,核心是为了纠正企业随意降低 AGI 标准带来的误导,减少对学生、企业决策者与资本的错误影响,通过挤掉概念泡沫,让行业回归理性投入,推动可持续、有真实价值的技术落地。

近日,吴恩达参加了一档播客,谈及了新版图灵测试以及当下人工智能发展的关键议题。访谈没有停留在技术炫技与概念炒作,而是直面当下行业最核心的争议:AGI 到底离我们多远、大模型规模化是否走到尽头、AI 将如何重塑工作与教育、中美 AI 格局如何演变,以及技术发展背后的价值与责任。

 

吴恩达在访谈中反复传递一个清醒判断:AI 发展史上曾出现过几次 AI 寒冬,正是因为人们过度炒作,期望过高无法兑现,最终投资和关注度崩塌,这对行业伤害很大。如今 AI 效果很好、价值巨大,几乎没有什么能阻挡它的发展势头。而真正让人担心的问题之一,就是过度炒作导致失望,进而引发泡沫破裂,这对世界和 AI 领域都不是好事。因此,给 AGI 降温,是为 AI 行业实现更可持续发展打下基础

 

AGI 原本的标准 —— 能完成人类任何智力任务,是非常高的标准,我们远未达到。但如果团队提出更容易实现的定义,就可以宣称更快达成。我不介意如何定义 AGI,但问题在于,大众心中的 AGI 就是类人通用智能。当不同团队用不同定义套上 “AGI” 这个词时,这个词就失去了意义。

 

针对行业热议的大模型路线,吴恩达强调:规模化时代并未结束,但已不再是唯一路径。早期 “堆数据、堆参数” 的简单模式已不可持续,合成数据、强化学习、工程化方案正在成为新的关键;同时,更聪明的模型无法直接替代可靠的工作流,在企业级高可靠场景中,结构化、可控制的智能体工作流,仍是现阶段落地的核心。

 

在最受关注的就业冲击上,他给出冷静而务实的结论:AI 不会大面积取代岗位,但会用 AI 的人,会取代不会用 AI 的人。只有呼叫中心、翻译、配音等极少数工作会被近乎完全自动化,绝大多数职业只会被 AI 部分赋能。真正的危机不在失业,而在教育体系跟不上 AI 时代,大量非技术岗位 —— 营销、财务、人力 —— 都急需具备 AI 能力的人才。

 

关于中美 AI,吴恩达打破单一 “领先” 叙事:美国在闭源模型上占优,中国则在开源与开放权重模型上走在世界前列,两国各有所长、多维竞争,共同构成全球 AI 最重要的两极。

 

访谈最后,吴恩达回归技术初心:他做研究、办教育、投创业,核心只有两点 ——让人类更强大,帮助更多人实现自己的梦想。AI 不是带来快乐的工具,快乐来自帮助他人的过程;而 AI 的终极意义,是把 “智能” 这种曾经昂贵的资源,变成每个人都可使用的能力。

 

整场对话像一剂 “降温针”:在狂热的概念竞赛中,吴恩达把 AI 拉回现实 ——不赌 AGI 何时到来,只做当下最有价值的事。这不仅是一位行业领袖的判断,更是一条更稳健、更普惠、更值得期待的 AI 发展路径。

 

以下为完整对话内容,经由 InfoQ 翻译及整理:

吴恩达:AGI 短期内无法实现

 

主持人:我一上来就想问问关于 AGI 这个问题,你几个小时前刚发布相关内容,可以从这个话题切入吗?

 

吴恩达:就任何合理的 AGI 定义而言,我的答案是:2026 年我们不会实现 AGI。除非有人大幅降低 AGI 的标准,才可能有公司宣称跨过了这个门槛。

 

主持人:那你如何解释、定义 AGI?

 

吴恩达:我最熟悉的 AGI 定义是:能够完成人类能做的任何智力任务的 AI。现在人类可能只需要花几十个小时,就能学会一项新技能,比如在森林里开卡车、在呼叫中心接电话并按企业要求回答问题。这些都是智力任务,而非体力任务。要让 AI 完成这些任务,目前仍需要工程师投入大量工作,去搭建定制化的 AI 工作流 —— 这本身很有价值,但这并不是大众心目中的 AGI。虽然我希望有朝一日计算机能在各方面都达到人类智能,但我认为我们离那一天还非常遥远。

 

主持人:你今天刚刚提出了一个新版图灵测试,能解释一下你的设想吗?

 

吴恩达:我对此很期待。因为 AGI 现在被炒得太热,已经从一个严谨的技术概念变成了营销术语,这在误导很多人。既然大家都关注 AGI、为之兴奋,那我们不如设计一个测试,来判断我们到底有没有接近 AGI。我把它叫做实用 AGI 测试:让人类评委设计一个持续数天的任务流程,比如通过电脑进行入职培训等;测试对象要么是 AI,要么是可以使用电脑、浏览器、Zoom 等普通软件的人类。如果在几天的过程中,AI 能够像一名熟练的专业人类一样,完成有经济价值的实际工作,在我看来这才是更合理的 AGI 定义。这也更贴近大众对 AGI 的理解 —— 大家认为 AGI 到来,就是 AI 能真正代替人工作,而不是某些企业为了公关、政策或融资而宣传的其他标准。

 

主持人:我之前采访过 2020 年诺贝尔物理奖得主 Sir Roger Penrose,他认为数学是封闭系统,AI 只是像玩游戏一样处理它。吴教授,你难道不担心根本不存在有效的 AI 测试吗?

 

吴恩达:AI 测试或基准的一个问题是:如果提前设定好测试集,就只能衡量 AI 的某一个特定维度。现在很多大模型都有标准基准,比如 SweetBench、GBQA 等,研究团队很难避免去针对已知测试集做优化,哪怕不是直接针对。而且 AI 的智能是 “参差不齐” 的,有些方面很强,有些方面很弱。但大家心中的 AGI,是能完成人类所有智力任务的 AI。固定测试集基准,和让人类评委实时探索、检验 AI 的强弱,这两者有很大区别。真正的 AGI,应该让人类评委找不到它在有经济价值的工作任务上明显弱于人类的地方。

 

主持人:那基准测试还在衡量真实有效的东西吗?有时候基准分数到 90%,用户却感觉 AI 更笨了。

 

吴恩达:我认为基准测试确实在衡量真实的东西,但只是非常窄的一部分。很多基准的弱点在于,我们更擅长设计客观型基准,比如数学题、事实类问题,有明确的对错。但现实中大量事情没有唯一最优解,比如对话、写研究报告,只有好坏程度之分。

 

我们很难设计出能衡量这些主观、灰度空间的测试,而人类大量实际工作都处在这个灰度里。现有的基准在这方面表现很弱。

 

主持人:如果 2026 年实现不了 AGI,那我们可以期待什么?OpenAI 的总裁 Greg Brockman 说,2026 年 AI 的两大方向会是智能体普及和科研加速。你怎么看?

 

吴恩达:我认为纠结 AGI 反而会分散注意力,我们离它还很远,短期内也实现不了。但即便没有 AGI,2026 年依然有大量极具价值的工作可以做、会继续做。我提出了智能体式 AI(Agentic AI) 这个概念,这是一个正在崛起的趋势。虽然构建能落地的商业流程 AI 需要大量工作,但一旦做成,价值巨大。

 

2026 年及之后,会有大量工作投入到 AI 智能体与智能体工作流中,去完成高价值、高经济意义的任务。我在 AION 的团队,已经在用智能体工作流写代码、审查文件、检查关税合规、阅读复杂法律文档辅助律师工作、做医疗辅助任务、支持客服等。把人类完成这些任务的思考过程编码进 AI 智能体或工作流,让 AI 代劳,这件事会持续很多年,价值会非常巨大。

 

主持人:谈到智能体工作流,“强化学习之父” Richard Sutton 有句名言:“纯粹的算力终将胜过人类的巧思”。你专注做智能体工作流,难道不是和这个观点相悖吗?

 

吴恩达:Sutton 的《苦涩的教训》影响很大,写得也很好。我先明确:我是支持规模化的。我创立 Google Brain 时,给团队的首要使命就是规模化—— 把神经网络做大、喂入大量数据。可以说我是 AI 规模化时代最早的推动者之一,当时很多人还觉得这很奇怪。也正是因为 Google Brain 以规模为核心基因,才诞生了 Transformer 架构,它是史上扩展性最强的神经网络架构,也推动了生成式 AI 革命。所以我真的相信规模化。但这不代表只靠规模化就能实现所有目标。在不同阶段,规模化与注入其他知识需要取得平衡。规模化规律确实存在,扩大系统和数据能较可预测地提升效果,这也成为融资的有力理由。但正因为规模化有其价值,它被过度炒作了 —— 它很有价值,但没被吹得那么神。而智能体工作流,可以在规模化大模型的基础上,再注入其他类型的知识,构建更可靠、性能更强的工作流。

 

大模型 Scaling Law 结束了?

 

主持人:那你现在真的认为规模化的时代已经结束了吗?

 

吴恩达:不,我不认为规模化时代已经结束。只是难度变得越来越大。AI 的进步可能呈指数级发展,但推动这种指数级进步所需的资金也同样呈指数级增长。用指数级增长的投入换来指数级快速的提升,这并不算差,而且非常有价值,因为研发成本可以分摊到大量用户身上。我认为规模化仍然有更多潜力可挖,但在现阶段,它不再是提升 AI 的唯一途径。

 

主持人:什么情况会改变你对规模化的看法?

 

吴恩达:你是说什么会让我放弃规模化?如果在很长一段时间内,进一步扩大模型规模都不再带来收益,那我才会改变看法

 

但有一个重要的补充:就像过去几十年摩尔定律推动技术进步,但期间不断有不同技术迭代,才能让半导体持续变强。生成式 AI 早期的路径很简单:获取更多数据、训练更大的模型。这正是十多年前 Google Brain 设立时的目标。但现在,AI 模型几乎已经读完了整个公开互联网,这种简单的规模化方式不再有效。因此现在很多团队都在大力做合成数据生成,投入更多人力工程,研究不同的强化学习方案。所以即便规模化仍在带来收益,过去两三年里,实现规模化的具体方式已经发生了非常显著的转变。

 

主持人:从另一个角度看,一个更聪明的模型,能否直接胜过精巧的工作流?

 

吴恩达:理论上是可以的。我也希望事情这么简单,但在实践中,它比大多数人想象的要难得多。随着模型越来越智能,比如 GPT-4.5、Gemini 3、GPT-5 等,我们确实越来越能直接给大模型一套工具,然后放手让它去执行任务。比如给它读写文件系统的权限,让它清理硬盘冗余文件,效果确实非常惊人。但对很多工作流来说,可靠性还不足以投入生产环境。所以虽然更聪明的模型很好,但在大量实际商业场景中,团队还是会把工作流拆解、分步实现,以保证稳定可用,让系统可以稳定运行成千上万次。

 

随着模型越来越智能,我们确实在逐步放开限制,减少 “护栏”。我们半年前做的系统,约束和脚本会更多;现在我们会不断拆掉脚手架,不再给非常详细的分步指令,而是让模型自己做决策。比如深度研究智能体,一两年前我们还会规定:搜索多少次、下载多少页面、如何总结。现在的 AI 更有能力自己决定要不要继续搜索、要不要总结。我经常会把半年前、一年前的原型系统里的指令删掉,让模型自己判断。但这方面还有很长的路要走。这类方式在深度研究这类场景可行,就算漏引文献也问题不大;但对很多高风险企业级场景,直接放任 AI 自主行动,可靠性差距仍然比一些人认为的要大,尽管这个差距正在缩小。

 

主持人:我想问一下你关于 Yann LeCun 与 Demis Hassabis 之争的看法。Yann LeCun 认为,人类智能是专业化的,而非通用智能;Hassabis 则认为大脑是通用的学习系统。你站在哪一边?

 

吴恩达:我不觉得这两者有矛盾,可能是我没理解到分歧点。在我看来,人类大脑(可以看作非人工的 AGI)最了不起的地方,是它的可塑性与学习能力。我理解的 AGI,不应该是那种 “什么都已经知道” 的 AI,那既困难也不现实。人类大脑在经济活动中如此有价值,原因之一就是它能学习去做新的事情。正是通过学习,我们才获得了高度专业化的能力。比如一个大脑可以通过数学博士训练,去解决极难的数学问题,最终成为高度专业化的智能;但同一个大脑,如果接受不同训练,也可以成为国际象棋大师、网球高手。所以人类大脑的 “通用”,不在于它生来什么都懂,而在于它能适应、能学习极广泛的事情。

 

主持人:这听上去你其实更偏向 Yann LeCun?

 

吴恩达:是的。当年我创立 Google Brain 时,有个理念对我影响很大,现在大家提得少了:人类的学习可能来自单一的学习算法。我们的 DNA 长度有限,携带的信息不多,但 DNA 编码出了大脑的生理结构,而大脑是一个相当通用的学习算法。正因如此,大脑才能学会做数学博士、骑摩托车、用电脑、在呼叫中心工作。正是这套通用学习算法,让大脑可以通过学习,在几乎任何领域变得专业。是这种学习能力,让智能显得 “通用”。

 

主持人:几个月前有人说,谷歌注定失败,因为他们只是把 AI 嫁接在旧搜索上,而 OpenAI 是从头构建。你认为谷歌能把旧体系和新技术结合起来吗?竞争已经开始了,这难道不令人激动吗?

 

吴恩达:Sam Altman 曾是我在斯坦福的学生,我在谷歌也有很多朋友。我既支持 OpenAI,也支持谷歌。回顾技术变革的历史,每当出现颠覆性技术时,有时是新入局者胜出,有时是老牌企业胜出,双方都有机会。这场博弈还远未结束。以互联网变革为例,谷歌是伴随互联网崛起的公司,但微软、苹果这些早在互联网出现前就成立的老牌企业,同样发展得很好。显然,AI 对谷歌这类现有企业极具颠覆性,但谷歌的应对做得不错。Gemini 3 是非常出色的模型,我认为它优于 ChatGPT。我自己经常同时使用 Gemini、ChatGPT、Claude 等多款模型。

 

主持人:你多次谈到 AGI。五年前,能解决任何编程问题都会被称作 AGI,如今我们已经实现了,却只把它当成工具。

 

吴恩达:其实我并不喜欢谈论 AGI,但其他人讨论得太多、炒作得太厉害。作为行业从业者,我认为 AGI 被严重过度炒作了。至少在大众认知里,AGI 是 AI 达到人类水平的通用智能,我们离这一步还非常遥远。我希望能实现 AGI,但现实地说,我们还需要几十年甚至更久。认为再过几个季度就能实现 AGI,这是不可能的,除非重新定义、降低 AGI 的标准。

 

AI 发展史上曾出现过几次 AI 寒冬,正是因为人们过度炒作,期望过高无法兑现,最终投资和关注度崩塌,这对行业伤害很大。如今 AI 效果很好、价值巨大,几乎没有什么能阻挡它的发展势头。我真正担心的问题之一,就是过度炒作导致失望,进而引发泡沫破裂,这对世界和 AI 领域都不是好事。因此,给 AGI 降温,是为 AI 行业实现更可持续发展打下基础。

 

主持人:那你认为我们是在移动目标门槛吗?也就是说在降低 AGI 的判断标准?

 

吴恩达:我不记得有靠谱的团队宣称已经实现 AGI。我记得很多团队说 AGI 很快就会到来,但三年前他们也没说自己已经做成了。到目前为止,还没有人真正做到。

 

如果非要说变化,反而是很多团队在试图降低 AGI 的定义门槛。AGI 原本的标准 —— 能完成人类任何智力任务,是非常高的标准,我们远未达到。但如果团队提出更容易实现的定义,就可以宣称更快达成。我不介意如何定义 AGI,但问题在于,大众心中的 AGI 就是类人通用智能。当不同团队用不同定义套上 “AGI” 这个词时,这个词就失去了意义。就像 “蓝色” 本来有明确指向,如果所有人把各种颜色都叫作蓝色,这个词就不再有共识。现在 AGI 就是这种情况。有人用狭隘的技术定义宣称 AGI 即将到来,而公众却理解为 “两年内 AI 就会拥有人类智能”,这与事实不符。

 

主持人:那我们现在到底处在什么阶段?实现难度重要,还是实用价值更重要?

 

吴恩达:我认为实现细节和工程难度非常重要。比如 Anthropic 推出 Claude Code 及其 SDK,就是为了让大家能更好地驾驭模型能力。提示词如何构造、提供哪些工具、整体框架如何设计,这些细节至今仍然至关重要。

 

举个小例子:当前模型已经非常智能,调用工具的能力也在变强,但如果给大模型太多工具,会占用大量上下文窗口,模型更容易出错,调用错误的 API 或工具。哪怕到了 2026 年,这些工程细节依然影响巨大。很多团队使用 MCP(模型控制协议),如果 MCP 服务器里工具列表太长,会大量消耗上下文,模型反而无法有效选择。这就需要上下文工程和合理的框架来让决策更顺畅。

 

主持人:Anthropic 预测持续学习(continual learning)会在 2026 年解决,你是否同样期待?

 

吴恩达:我非常期待持续学习能被攻克。如果 2026 年真的完全实现,那会是惊人的突破。我认为我们会取得进展,持续学习非常重要。人类孩子学走路,只需要跌倒几次就能学会;而强化学习往往需要数百万次模拟。

 

主持人:我们只能靠暴力训练吗?

 

吴恩达:暴力训练的问题在于,人类智能的核心是学习算法的通用性,这让人类能极快地学会新事物。人类员工沟通后就能上岗工作,这非常有价值;但如果训练 AI 完成某项任务需要花费百万美元,对很多任务来说就不划算。如果样本效率不重要,那只有极少数几家公司能负担得起训练前沿模型。

持续学习当前最大的瓶颈是什么?

 

主持人:开源、开放权重模型与闭源模型的格局会如何演变?我们会走向 AI 寡头垄断吗?

 

吴恩达:我不希望出现那样的未来。以移动开发平台为例,如今创新空间已经不大,部分原因就是存在少数守门人 —— 在美国,做移动端开发需要获得 iOS 或 Android 的许可,封闭平台限制了很多创新。我们 AI 行业很多人都希望,未来不会出现只有两三家守门人掌控前沿 AI 的局面。我希望所有人都能在大模型之上自由创新,开源与开放权重模型是避免出现少数守门人的关键。如果我们能保住 AI 行业如今比移动领域更高的创新自由度,就会涌现更多发明与应用,整个社会也会因此更加丰富。

 

主持人:目前也有一些关于非文本表示的研究,但现在大部分记忆还是基于文本。而且我们搭建的这些记忆系统,基本都不会去更新大模型本身的权重,这是不是意味着我们还缺少关键的一块拼图?持续学习当前最大的瓶颈是什么?

 

吴恩达:我认为我们还没有找到正确的思路,或者说还不确定什么才是正确的方向。目前只有一些看上去有希望的想法,但我还没来得及验证,也不确定能不能成。这就像在问:一个还没解决的重大科研问题,瓶颈到底是什么?因为路径不清晰,我甚至没法明确说出具体瓶颈是什么 ——我们就是还不知道该怎么做。

 

主持人:AI 知名学者 Eliezer Yudkowsky 认为,如果有人造出 AGI,人类会灭亡;但每年因为癌症、衰老、疾病死去的人数以百万计,而 AI 可能解决这些问题。你认为哪种风险更大?

 

吴恩达:我读他的很多观点时,经常理不清逻辑,有些论述在我看来循环性太强,我甚至不知道该怎么反驳。我认为 AI 今天已经在为世界带来巨大的正向价值,任何能加速 AI 进步的事,都会让生活变得更好、拯救更多生命、让更多人富裕、摆脱贫困。AI 的整体净收益远大于潜在危害。确实存在一些有害的应用场景,我们应该明确并清除这些场景。但就目前而言,我非常确信:推动 AI 进步对人类是有益的。

 

主持人:未来是不可预测的,对吧?我们是否需要更多 AI 安全工具?

 

吴恩达:未来当然不可预测,但这不代表我们没有高度确信的趋势。让计算机变得更智能,显然是一件好事;让智能触手可及、实现民主化,也非常重要。因为世界上最昂贵的东西之一,就是 “智能”—— 请一位优秀的医生、优秀的老师,成本都很高。当然,我们应该致力于让 AI 系统更可靠、降低风险。同时,大家身边的人大多在专注于能创造价值的事。很多人对硅谷有刻板印象,觉得这里的人只在乎钱,这完全是错的。我认识很多行业里的朋友,确实有极少数人只在乎利润,但那是非常小的一部分。我认识十多年的很多同行,是真的想做正确的事。他们非常重视安全,认真对待负责任的 AI,会坐下来认真思考 AI 系统可能出现的各种问题,并尽力降低风险。那种 “硅谷从业者只为利益不择手段” 的印象,是完全不符合事实的。不可否认,面对几十亿美元的诱惑,确实有少数公司会动心,但那真的只是极少数

 

开源时代结束了吗?

 

主持人:开源时代结束了吗?

 

吴恩达:开源现在发展得很好。一个有意思的现象是,目前很多顶尖的开源、开放权重模型来自中国。回顾过去几年,每年可用的开源 / 开放权重模型都在快速增长,所以我认为开源生态非常强劲。同时,闭源方案也在快速发展,但这没关系,重要的是开源选择也在同步强劲增长。

 

主持人:回看 AI 发展的现阶段,你心里在想什么?

 

吴恩达:我希望赋能每一个人去构建 AI。作为开发者,我再也不想手动写代码了,我希望 AI 尽可能帮我写代码。AI 给软件工程带来的效率提升是非常明显的。但很多人没意识到的是:不只程序员,所有人都会因为会用 AI、会用 AI 搭建工具而受益。我在团队里已经看到这种现象:懂 AI 的营销人员,效率远超不懂 AI 的同行;我旗下 AI 基金的 CFO,会借助 AI 写代码,工作效率也远高于不会用 AI 的 CFO。

 

AI 工具,尤其是用 AI 构建软件,将会是每个人都必须具备的重要新能力。有人拥抱这些能力,就能大幅提升生产力;也有人不愿接受,就可能被甩在后面。对此我其实挺担心的。一个很大的挑战是:大学系统的适应速度偏慢,很多课程还在培养适应 2022 年岗位的学生,而很多当年的岗位现在已经不存在了。企业现在极度缺乏懂 AI 的人才 —— 不只是程序员,而是营销、招聘、财务等各行各业的人。把教育体系转向让学生和成年人都能使用这些工具、大幅提升效率,需要巨大的转型。但现阶段要真正做到,我认为仍然非常困难。

 

主持人:程序员会失业吗?

 

吴恩达:不使用 AI 的程序员,处境会很艰难;而真正精通 AI 的程序员,生产力极高,市场上根本供不应求。说他们会彻底消失有点夸张。

 

大多数岗位不会消失,但有句话说得很对:AI 不会取代人,但会用 AI 的人会取代不会用 AI 的人,这在很多领域都成立。坦白说,确实有少数岗位会被 AI 完全自动化。比如很多翻译人员、配音演员,他们的工作面临较大冲击。对于这些会被完全自动化的少数岗位,我深表同情。作为 AI 从业者,我有责任帮助他们掌握新技能、重返职场,找到有意义的新工作。但对绝大多数岗位而言,AI 只能完成部分工作。比如放射科,AI 自动化的进程比人们预想的慢得多;法律行业受监管保护,完全取代人类律师也很难。但不用 AI 的律师,效率会远低于用 AI 的同行,因为 AI 在法律检索等方面表现极佳。关键在于:如果 AI 能完成一项工作的 30%,剩下 70% 仍需要人来做,但这个人必须会用 AI,否则就会在效率上落后。

 

主持人:你能预测哪些工作最终会消失吗?

 

吴恩达:明确会消失的,主要是那些几乎 100% 的工作内容都能被自动化的岗位,比如大量呼叫中心工作、翻译、配音演员等。但绝大多数工作都复杂且多面,AI 擅长文本处理,在非文本领域能力有限。很多研究将工作拆解为具体任务后发现,AI 通常只能自动化 30%-40% 的工作,剩下 60%-70% 仍需人类完成。只有极少数岗位,AI 能覆盖几乎全部工作,这些岗位才会面临危机,但这只是很小一部分。

 

主持人:你 2017 年离开百度,当时的决定原因是什么?

 

吴恩达:我在百度的工作经历非常愉快。很多人好奇我从谷歌大脑到百度,再到创立 AI 基金和其他项目的原因。当时我负责百度的 AI 团队,团队非常优秀,在优化在线广告、网站等核心业务上做得很好。我看着组织架构图意识到,即便我离开,这支优秀的团队也能运转良好。我发现自己工作中最有乐趣的部分,是创建新业务板块。比如我带领的百度自动驾驶团队,至今在中国发展得很好;我负责的智能音箱团队,如今也表现出色。虽然我能为母公司创造利润,但我真正投入的是从零到一创建新业务。我觉得跳出大公司,创立 AI 基金这样的风投工作室,从零开始打造企业,或许能做得更好。因此我离开百度,创立了 DeepLearning.ai,继续深耕 AI 教育,赋能更多人使用 AI;同时运营 AI 基金,孵化初创企业。

中美 AI 发展的差异

 

主持人:你认为中国现在在 AI 领域领先吗?

 

吴恩达:目前美国在闭源大模型方面仍处于领先地位,但中国在开源、开放权重模型领域已经大幅领先美国。过去一两年,中国推出了大量顶尖的开源模型(如 DeepSeek、Qwen 系列等),全球开发者可免费下载使用,生态活力极强。中美都是 AI 领域的巨头,中国凭借激烈的市场竞争、快速的技术传播和强大的开源生态,拥有巨大的发展势能。两国各有优势,整体处于并跑、互补的状态,而非一方绝对领先

 

主持人:你对自己当年的选择不后悔吗?

 

吴恩达:我和中国团队一起做过一些工作,那段经历很棒。现在我和 DeepLearning.ai、AI Fund、Landing AI 等团队合作也非常开心。我对现在做的事情很满意,没有遗憾。

 

主持人:单纯从规模和动能来看,中国是不是更有活力?

 

吴恩达:中国有很多优势,美国也有很多优势。

 

主持人:接下来我们可以期待你的公司带来什么?

 

吴恩达:我希望赋能每一个人用 AI 构建东西。我们一直专注于帮助开发者用上最新工具,未来也会继续做这件事。除了支持 AI 开发者发展职业、成长,我还想把范围扩大,让开发者和所有人都能用 AI 创造价值。这是 DeepLearning.ai 的重心。我离开百度的一个原因是:有些业务适合在谷歌、百度这样的大公司内部做,但有些业务不适合,比如关税合规这类事情,互联网公司不会重点关注。而 AI Fund 可以孵化各种各样的创业公司,业务类型非常多元,我对此很期待。另外,AI Aspire 是我和朋友新启动的项目,和贝恩等机构合作,为大型企业提供 AI 咨询。想要真正推动 AI 落地,开发者很重要,个人用户很重要,大型企业同样关键。我们花了很多精力,帮助大企业用 AI 创造真实价值、获得竞争力。

 

主持人:你还把自己定位成 AI 传播者、沟通者,为什么?

 

吴恩达:这触及到我最核心的价值观。我做事有两个最高优先级:第一,让人类变得更强大。这是我做研究员、在斯坦福当教授的原因 —— 通过研究、发明新技术,推动前沿发展,让人类更强大。第二,帮助他人实现他们的梦想,而不是把我的梦想强加给别人。如果我们能给别人工具和技能,他们就更有机会实现自己的梦想。这也是我做教育一直以来的动力。

 

主持人:回顾你的人生,如果时光可以倒流,你会改变什么决定吗?

 

吴恩达:当然有很多事我会换一种做法。我很幸运,做对了一些决定,但也做错了很多。比如是否该聘用某个人、是否该坚持某个项目、是否该更努力而不是放弃。但整体上,我接受这一路的经历。

 

主持人:如果关于世界本质,你只能弄明白一个问题,你会选什么?

 

吴恩达:我希望能理解智能的本质。

 

主持人:你是指意识吗?物质如何在人脑中变成意识?

 

吴恩达:其实不是意识。意识是重要的哲学问题,但我不懂什么是意识。哲学上的意识是指 “自我感知”,但你无法确认我是否真的有意识,我也无法确认你有。我们只是出于礼貌,假定彼此都有意识。因为意识无法被测量,所以它是哲学问题,不是科学问题。而我更关注科学问题:智能的本质到底是什么?人脑或其他生物大脑,究竟是通过什么机制,表现出如此广泛的智能行为?它到底是怎么运行的?很多人不知道,在创立 Google Brain 之前,我花了大量时间和神经科学家朋友交流,读了成堆的神经科学论文,最后得出结论:神经科学目前基本还不知道大脑是如何工作的。所以我放弃了从神经科学直接造智能的路线。但我很确定,智能不只是一个靠规模放大的 Transformer,肯定还有更多东西。我真心希望能搞懂它。

 

主持人:包括推理的本质吗?

 

吴恩达:对,推理是智能的一部分。能真正理解推理如何工作,也会非常迷人。

 

主持人:为什么西方世界看起来这么不快乐?

 

吴恩达:我不认同 “西方世界普遍不快乐” 这种概括。你不会从一杯水里寻找快乐,但水让你更健康。同样,把快乐寄托在 AI 上是一种误区。AI 能支撑我们、帮助我们创造、赋予我们技能,但快乐更多来自内心,而不是我们创造的工具。真正的快乐,更多来自努力帮助他人的过程。我希望通过 AI 工作帮助别人,也在做对他人有用的工作中获得了很多快乐。

 

参考链接:

https://www.youtube.com/watch?v=4vzmTKUFtxg&t=57s

问题解决了吗? 如果解决了可以在 独立开发者 节点把经验分享出来, 根据 V 友的反馈获取最少 20$V2EX 的打赏

如果问题没有解决, 可以在这个帖子下面回复

针对回复中的问题, V 友如果有合适的解决方案, 也可以在 独立开发者 这个节点下分享你的解决方案, 以获取最少 20$V2EX 的打赏

ps: 欢迎分享自己的经验和工具箱, 谨慎分享自己的创意或作品, 谨防抄袭.

按自己使用需求 vibe coding 了一个 Obsidian 插件,在笔记中粘贴图片时,自动将图片先保存到目录中——当前笔记路径向上搜索到的最近 pic-bed 目录(或其他配置的目录名),并在笔记中插入标准 markdown 图片引用格式(或 wiki 引用格式)。搜索的目录名称可配置。

这样你就得到了

复制
personal-note/
├── pic-bed/
│ └── source.jpg
├── xxx/
├── xxx/
└── notes/
    └── today.note

笔记中:
(today.note:)

// blabla……
![](../pic-bed/source.jpg)
// blabla……

点赞 + 关注 + 收藏 = 学会了

整理了一个「前端调试小专栏」,有兴趣的工友可以关注一下 👉 《前端Debug不求人》

在刚开始写 CSS 时,我们经常会用到百分比(%)来实现响应式布局。但在这个过程中,有一个非常经典且常常让初学者感到“反直觉”的隐藏规则:

当元素的 margin(外边距)或 padding(内边距)的值被设置为百分比时,无论方向是水平(左右)还是垂直(上下),它们的计算基准都是其父元素(容器)的宽度!

是的,你没有听错。哪怕是 margin-top 或者 padding-bottom,它们计算时参考的也是父元素的宽度,而不是高度。

垂直方向的外边距(margin-top)

假设我们有一个父元素 .p,它的宽度是 100px,高度是 200px。里面包含一个子元素 .c,并且我们给子元素设置了 margin-top: 50%

很多初学者会误以为 margin-top 是基于父元素的高度(200px)来算的,从而得出 100px 的结果。但实际上,它是基于父元素的宽度(100px)来计算的:100px * 50% = 50px

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>百分比 Margin 测试</title>
    <style>
        /* 父元素 */
        .p {
            width: 100px;
            height: 200px;
            background-color: #e0e0e0; /* 灰色背景方便观察 */
            border: 1px solid #333;
            position: relative; /* 使子元素的 margin-top 以父元素为参考 */
        }

        /* 伪元素用于显示父元素高度 50% 的位置在哪 */
        .p::after {
            content: "50%";
            position: absolute;
            top: 100px;
            left: 0;
            width: 100%;
            height: 1px;
            background: red;
            display: flex;
            align-items: center;
            justify-content: center;
            color: #333;
        }

        /* 子元素 */
        .c {
            margin-top: 50%; /* 实际计算结果为:父元素宽度 100px 的 50%,即 50px */
            background-color: #ff7675; /* 红色背景 */
            color: white;
            text-align: center;
        }
    </style>
</head>
<body>

    <div class="p">
        <div class="c">子元素 c</div>
    </div>

</body>
</html>

经典的等比例缩放黑科技(保持 1:1 宽高比)

由于 padding-bottom(或 padding-top)设置为百分比时也是基于父元素的宽度,前端老手们经常利用这个特性来创建一个可以随屏幕大小缩放,但始终保持固定比例(比如 1:1 正方形、16:9 视频框)的元素。

以创建一个 1:1 的正方形为例,由于 width: 100% 等于父元素的宽度,而 padding-bottom: 100% 也等于父元素的宽度,这样就在视觉上撑出了一个完美的正方形!

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>百分比 Padding 等比例测试</title>
    <style>
        /* 限制一下外层容器的宽度,方便观察缩放 */
        .container {
            width: 300px; /* 你可以尝试修改这个宽度,里面的正方形会自动跟着变大变小 */
            margin: 50px;
            border: 2px dashed #0984e3;
        }

        /* 核心逻辑:利用 padding 撑开高度 */
        .ratio { 
            width: 100%; 
            padding-bottom: 100%; /* 高度由基于宽度的 padding 撑开,实现 1:1 */
            background-color: #74b9ff;
            
            /* 注意:因为内容区高度实际为0,如果里面要放文字或图片,
               通常需要配合相对/绝对定位来实现 */
            position: relative; 
        }

        /* 如果要在等比容器里放内容,通常这么做: */
        .ratio-content {
            position: absolute;
            top: 0;
            left: 0;
            width: 100%;
            height: 100%;
            display: flex;
            align-items: center;
            justify-content: center;
            color: white;
            font-weight: bold;
        }
    </style>
</head>
<body>

    <div class="container">
        <div class="ratio">
            <div class="ratio-content">我是一个 1:1 的正方形</div>
        </div>
    </div>

</body>
</html>

以上就是本文的全部内容啦,想了解更多前端调试玩法欢迎关注《前端Debug不求人》👏

点赞 + 关注 + 收藏 = 学会了

先说背景,二流学校毕业( 20 年),当初差点毕业即失业。
后来进了家 996 牛马厂,日常就是 Spring Boot + 若依一把梭,纯 CRUD ,Spring Cloud 基本没碰过。

然后公司开始降本增效,技术组全员全栈。
我就从 ruoyi-vue 开始补前端,后面又切 Nuxt 做新项目,二开,负责前端页面以及接口调用(开始用 Cursor Auto 了)。

再后来公司又 all in AIGC ,我也跟着转,在基于一个付费 SaaS 项目(Next.js)做二开。
问题来了:我 React / Next.js 基础其实很弱,现在很多时候就是——能编译、功能能跑、页面没炸,就先 merge/accept
了,几乎没时间仔细 review 。

一开始使用 AI 编程都是简单的提问题直接开始写代码,后面慢慢了解到 Plan 模式等等,
最近也在开始学怎么用各种 skill (工作流 / 提示词 / 规范化流程)来提升编码质量,不想只靠“玄学生成”,但目前还在摸索期。

现在状态就是越来越焦虑:

  1. 怕代码质量哪天集中暴雷;
  2. 怕自己只是“会用工具拼功能”,很快被替代;
  3. 技术栈一直切,学了又忘,没形成自己的东西。

想请教下各位老哥:

  • 这种阶段你们是怎么稳住心态的?
  • 如果我现在时间有限,只能抓 1~2 个重点提升,优先抓啥最有效?
  • 有必要硬啃 React / Next 底层,还是先把业务交付能力拉满?
  • “用 AI + 用 skill 提效”这条路,怎么走才不变成纯复制粘贴工程师?

最近做了个小玩具:把 OpenClaw 的模型调用记录,做成了一个像素风“养虾”游戏。

核心玩法很简单:

  • 每个模型对应一只龙虾
  • input_tokens + output_tokens 就是饲料
  • 消耗越多,这只龙虾就越大

我做这个的初衷是:
平时看调用日志太抽象了,想把“今天到底用了多少模型”变成一个更直观、可玩的反馈。

现在是本地运行的一体化服务,数据落在 SQLite ,开箱就能用;也可以配合 OpenClaw 的 skill ,让它在每轮回复后自动喂一次。

https://github.com/murongg/lobster-farmer

截图:

最近,Databricks正式发布Lakebase。这是一个基于 PostgreSQL 的无服务器 OLTP 数据库,能够独立扩展计算和存储。它旨在与 Databricks 平台集成,提供一种综合事务与分析能力的混合解决方案。

 

据 Databricks 称,他们推出这项新的无服务器服务是希望在单一平台上集成数据库、分析和治理功能,从而简化实时应用和 AI 工作负载。Lakebase提供了即时数据分支、特定点时间恢复和统一访问控制,旨在加快开发速度,提高可靠性,并保持操作数据和分析数据的同步。

 

Databricks 认为,操作型数据库并非为当前 AI 驱动的应用而设计,并将 Lakebase 称为“一种新型的操作型数据库架构,其特点是在持久化的数据湖存储之上进行轻量级的临时性计算。”项目团队解释了传统数据库面临的挑战:

 

由于每个查询都在争夺相同的固定 CPU 和内存资源,单个查询都可能影响所有的实时操作。这些限制拖慢了团队效率,使基于实时数据的工作变得风险重重。随着应用程序的自动化程度越来越高,系统实时对数据进行处理,这种共享的、脆弱的基础设施变成了更大的隐患(……)为了消除这种架构瓶颈,我们创建了 lakebase 这种新类型的数据库架构,将计算与存储分离。

 

Databricks Lakebase 提供了一个集成到Databricks数据智能平台的托管 Postgres 数据库服务,提供自动扩展、分支管理和与 Databricks 服务的无缝集成。这家因围绕 Apache Spark 构建数据分析与 AI 平台而闻名的公司,为其广受欢迎的 Lakehouse 解决方案增添了全新的选项。Databricks 首席技术官兼联合创始人 Matei Zaharia 在 LinkedIn 上撰文称

 

我们相信,这将使使用操作型数据库的工作变得极其简单和可靠。无论操作由人工执行还是由代理执行,你都可以即时创建数据库分支、生成快照、回滚到一个特定的时间点,或者为离线分析创建另一个副本(……)同时完全保留标准的 Postgres 接口和扩展功能。

 

新增的托管选项支持单实例高达 8TB 的容量和最新的数据库版本 Postgres 17,包括用于 AI 驱动搜索的 pgvector 扩展。正式发布公告中重点展示的应用场景包括:机器学习的实时特征服务、AI 智能体的持久内存支持以及嵌入式分析功能。

 

自 2025 年 6 月以来,Lakebase 一直在开发当中,它基于 Databricks 从PostgreSQL公司Neon收购的技术构建,并通过去年10月收购Mooncake得到了进一步加强——改善了 PostgreSQL 数据库与 lakehouse 数据的集成。

 

Lakebase 现在提供两个版本:自动扩展和预配置。自动扩展是一个比较新的选项,Databricks 正在其中构建新功能,并继续添加预配置版本中当前可用的功能。Ampt 联合创始人和亚马逊云科技无服务器英雄Jeremy Daly在其新闻通讯中评论道:

 

Databricks 新推出的 Lakebase 无服务器数据库正在引起人们的一些关注。将存储和计算分离并不是什么新鲜事,但使用 Postgres 接口直接写入 lakehouse 存储,并且是用 Spark、Databricks SQL 和其他分析引擎可以立即查询的格式,而且不需要 ETL,这个变化是巨大的。

 

自动扩展版本按使用计费,费用以 Databricks Unit(DBU)为单位计算,具体取决于工作负载消耗的容量单位小时数。客户可设置自动扩展的最小值和最大值范围,并配置“缩至零”的超时时间。存储费用则单独计算。

 

在亚马逊云科技的云平台上,Lakebase 现在已经可以用于生产环境,而在Azure平台上目前尚处于公开预览阶段。预计在未来几个月内,Lakebase 将完全支持 Azure,并在今年晚些时候支持谷歌云。根据公告,他们计划在 2026 年初获得 SOC2 和 HIPAA 认证。高可用性(可读从节点)目前仅在预配置版本中提供。

 

原文链接:

https://www.infoq.com/news/2026/02/typescript-6-released-beta/

在消费升级与数字化浪潮的双重推动下,便利店行业正从传统 “线下单一场景” 向 “线上线下融合” 的新零售模式转型。传统收银系统功能单一、数据割裂、用户粘性弱等问题,已难以满足便利店高效运营与用户多元需求。OctShop 便利店收银 + 点单 + 商城系统源码,凭借 “三位一体” 的功能架构、轻量化部署与高适配性,为便利店提供了从线下收银到线上经营的全场景解决方案。它不仅打破了传统便利店的经营边界,更通过数字化工具帮助商家降本增效、提升用户复购,成为便利店实现新零售转型的核心技术支撑。

图片

OctShop便利店收银+点单+商城系统源码: https://pc.opencodetiger.com/Cashier

一、核心优势在于收银、点单、商城三大模块的深度融合

OctShop 系统源码的核心优势在于收银、点单、商城三大模块的深度融合,形成闭环式经营体系,覆盖便利店全业务场景。收银模块作为线下经营的核心,具备 “高效便捷 + 精准安全” 的双重特性。系统支持多种支付方式,包括现金、银行卡、微信支付、支付宝、银联云闪付等,满足不同用户的支付习惯;同时集成条码扫描枪、收银小票机、钱箱等硬件设备,无需额外适配,即插即用,新店员上手培训时间可缩短至 1 小时内。在功能细节上,系统支持 “商品快速录入”,通过扫码枪扫描商品条码即可自动填充名称、价格、库存等信息,避免手动输入误差;针对促销场景,可一键设置 “满减、折扣、第二件半价” 等活动规则,收银时自动计算优惠金额,无需人工干预;此外,系统具备 “断网应急模式”,断网状态下仍可正常收银,联网后自动同步数据,避免因网络问题导致的营业中断,保障门店经营连续性。

二、多渠道接单 + 高效履约”,助力便利店拓展服务半径

点单模块则聚焦 “多渠道接单 + 高效履约”,助力便利店拓展服务半径。该模块支持线下柜台点单与线上点单双模式:线下场景中,店员可通过收银台终端或移动 Pad 快速记录用户订单,尤其适合早餐、简餐等即时性消费需求;线上场景则覆盖微信小程序、美团、饿了么等主流平台,系统可自动同步各平台订单至后台,无需店员切换多个平台操作,避免订单遗漏或错单。在订单处理环节,系统支持 “智能分单”,根据商品库存、制作进度自动分配订单优先级,同时通过语音播报提醒店员接单,大幅提升出单效率;针对外卖订单,可对接第三方配送平台(如蜂鸟即配、美团专送),实时同步配送员位置与订单状态,方便店员与用户追踪;此外,点单模块还支持 “预订单” 功能,用户可提前预约取餐或配送时间,便利店可根据预订单量提前备货,减少高峰时段压力,提升用户体验。

图片

三、商城模块是便利店突破物理边界、实现 “线上增收” 的关键

商城模块是便利店突破物理边界、实现 “线上增收” 的关键。基于 OctShop 系统源码搭建的线上商城,可与线下门店库存实时同步,用户通过微信小程序即可浏览商品、在线下单,支持 “到店自提” 与 “配送到家” 两种履约方式。在商品运营上,商城模块支持 “分类管理”,可将商品划分为零食饮料、日用百货、生鲜速食、烟酒特产等类别,方便用户快速查找;同时支持 “个性化推荐”,根据用户历史下单记录、浏览轨迹推送相关商品,提升转化率。针对便利店的 “即时性消费” 特点,系统可设置 “满额免配送费”“限时秒杀”“新人优惠券” 等营销活动,吸引用户线上下单;此外,商城模块还具备 “会员积分体系”,用户线上线下消费均可累积积分,积分可用于兑换商品或抵扣现金,增强用户粘性。值得注意的是,商城模块与收银、点单模块数据互通,商家可通过后台查看全渠道销售数据,精准分析商品热销榜、用户消费偏好,为采购与营销决策提供数据支撑。

四、技术层面高适配性与易扩展性

在技术层面,OctShop便利店系统源码展现出高适配性与易扩展性,满足不同规模便利店的需求。对于小型社区便利店,系统提供 “轻量化部署方案”,无需搭建独立服务器,通过云服务器即可快速上线,初期投入成本低;对于连锁便利店,系统支持 “多门店统一管理”,总部可通过后台实时查看各门店的销售数据、库存情况、员工绩效,统一制定促销活动与商品定价,实现标准化运营。在数据安全方面,系统采用 SSL 加密传输技术,对支付数据、用户信息、销售数据进行全程加密,防止信息泄露;同时支持 “自动备份” 功能,每日自动备份数据至云端,即使本地设备故障,也可通过备份快速恢复,保障数据安全。此外,系统预留丰富的 API 接口,可根据便利店需求对接会员管理系统、供应链管理系统、财务统计系统等第三方工具,实现功能扩展,避免后期系统重构成本。

图片

五、实际应用价值多维度的经营提升

从实际应用价值来看,OctShop 系统源码能为便利店带来多维度的经营提升。在成本控制上,通过自动化收银与订单处理,可减少 1-2 名人工成本,同时降低因人工操作导致的收银误差与订单错漏;在库存管理上,系统实时同步线上线下库存,自动预警低库存商品,避免缺货或积压,库存周转效率可提升 30% 以上;在用户运营上,线上商城与会员体系的搭建,可将线下客流转化为线上私域用户,通过精准营销提升复购率,据实测数据,接入系统的便利店线上订单占比可提升至 20%-30%,整体营业额增长 15% 以上。以社区便利店为例,接入 OctShop 系统后,用户可通过小程序线上下单、到店自提,便利店通过 “生鲜预售”“日用品团购” 等活动,进一步提升客单价与用户粘性,实现从 “传统夫妻店” 到 “社区新零售服务站” 的转型。

六、怎么选择OctShop

对于计划接入 OctShop 系统源码的便利店商家,可根据自身规模与需求选择合适的部署方案。单店商家建议选择 “基础版”,包含核心收银、点单与简易商城功能,投入成本低、上线速度快;连锁商家可选择 “企业版”,享受多门店管理、供应链对接、数据看板等高级功能,实现规模化运营;若有个性化需求(如定制会员等级、开发专属营销工具),可借助系统源码的二次开发能力,联合技术团队进行功能定制。同时,系统提供详细的部署手册与操作教程,商家无需专业技术团队,通过客服指导即可完成搭建;后期运营中,官方提供免费的系统升级服务,确保功能始终适配行业最新需求,如新增 “刷脸支付”“电子发票” 等功能,帮助便利店持续提升服务能力。综上,OctShop 便利店收银 + 点单 + 商城系统源码,以 “全场景覆盖、高性价比、易部署扩展” 的核心优势,为便利店新零售转型提供了切实可行的技术方案。它不仅解决了传统便利店经营中的效率低、数据散、用户粘性弱等痛点,更通过线上线下融合的模式,帮助商家挖掘新的营收增长点。在消费需求日益多元的今天,OctShop 系统源码将持续助力便利店行业数字化升级,推动便利店从 “商品销售渠道” 向 “社区综合服务平台” 转型,实现长期可持续发展。

昨天想把贴了好几年的膜撕掉,结果贴的太紧,大力出奇迹,屏幕直接被拉起来了。

如图,因为换屏很贵,可以单独换这个排线吗。有木有懂维修的前辈帮忙指导一下。

现在是开机状态,手机还在连接,就是屏幕不显示。花大钱就不如直接换新来的好。

watch5

企业网站的安全性已成为用户信任的“第一道门槛”。许多企业在选择SSL证书时,常常在DV、OV和EV三种类型之间犹豫不决。OV(组织验证)SSL证书凭借其“安全与成本”的完美平衡,逐渐成为绝大多数企业的首选。本文将深入解析为什么企业建议申请OV证书,并为您推荐一个优秀的国产SSL证书品牌——JoySSL。

一、为什么OV证书是企业的“黄金选择”?

1. 比DV证书:多一层身份验证,彻底告别“匿名”

DV证书仅验证域名所有权,虽然快速且便宜,但无法确认网站背后的运营主体是谁。这意味着钓鱼网站可以轻松伪造DV证书来冒充正规企业。而OV证书的申请流程严格审核企业真实身份(如营业执照、对公账户等)。一旦部署,用户的浏览器地址栏不仅能看到小锁,还能点击查看该企业的正式名称。这种“身份可视化”能有效降低跳出率,提升用户咨询转化率,让访客第一时间确认“这不是一个钓鱼网站”。

2. 比EV证书:节省50%以上成本,功能实用不浪费

EV证书曾以其地址栏绿色名称显示而备受推崇,但近年来浏览器UI的调整使得EV与OV的视觉差异逐渐缩小,且EV证书的价格通常是OV的2-3倍,审核周期也更长。对于绝大多数企业官网、电商平台及SaaS服务而言,OV证书提供的“企业名称显示+数据加密”已完全满足商业信任需求,无需为溢价的EV买单。

3. 满足合规刚需:等保与密评的“标配”

随着《网络安全法》及“等保2.0”的普及,仅验证域名的DV证书已无法满足合规要求。特别是在等保二级及以上系统中,明确建议或要求采用OV及以上级别的证书。OV证书能提供经过严格核验的组织身份信息,确保通信主体可信,帮助企业顺利通过测评。

二、为什么选择JoySSL部署OV证书?

OV证书申请入口

在明确了OV证书的优势后,选择一个可靠的证书颁发机构(CA)至关重要。JoySSL作为中国自主品牌的SSL证书提供商,正在成为越来越多国内企业的信赖之选。

  1. 自主可控,安全合规:JoySSL携手全球可信顶级根,基于国内服务器验证签发。针对等保和密评需求,JoySSL提供支持国密算法(SM2/SM3)  的OV证书,并可实现“国密+国际”双算法自适应,既满足合规监管,又兼容所有主流浏览器。
  2. 高性价比与服务保障:相比国际品牌动辄数千元的OV证书,JoySSL提供了极高的性价比。其OV证书不仅价格亲民,还提供一对一全程技术指导,从CSR生成到服务器部署,帮助运维人员快速上手。
  3. 产品线丰富:无论是保护主域名的单域名OV证书,还是能同时保护多个子域名的通配符OV证书,JoySSL都能提供,完美适配集团官网、电商平台及多分支企业门户。

三、行动指南:如何快速获取JoySSL OV证书?

如果您已决定为企业官网或关键业务系统部署OV证书,可以通过以下步骤轻松申请:

  1. 访问官网:前往JoySSL官方网站。
  2. 注册账号:在注册过程中,为了获取专属优惠和技术支持,建议填写推荐邀请码:230970。这将帮助您对接专业客服,获取最适合您企业架构的证书选型建议。
  3. 选择证书:在“企业OV SSL”类别中,根据您的域名数量选择“单域名”、“多域名”或“通配符”证书。
  4. 提交验证:提交企业营业执照和域名所有权验证,CA审核团队通常在1-3个工作日内完成严格的人工审核。
  5. 部署上线:验证通过后下载证书,在技术客服的协助下安装到服务器,开启安全可信的企业之旅。

总结:  对于追求品牌信誉、注重用户信任且有合规需求的企业而言,OV证书是性价比最高的“务实之选”。选择像JoySSL这样兼具合规资质、本土服务与技术创新的国产品牌,不仅能保障数据传输的绝对安全,更能向您的每一位访客展示企业的正规形象与责任担当。

租房没有配,今年深圳梅雨天比较多,想买带烘干的,各位彭于晏们有什么推荐吗?
预算 2k 以内

买 pro 套餐将近一个月,烧掉 16 亿 token ,我算 pro 用户了吧,写代码角度来看,算是合格的工程师了,我主要用 C++开发。

vscode+claude code cli,使用 glm 文档给出的配置直连,最近几天经常并发受限,这个能理解,但是下面这个经常出现的错误是什么意思?

API Error: 400 {"type":"error","error":{"message":"API 调用参数有误,请检查文档。Request 188024 input tokens exceeds the model's maximum context length 202752","code":"1210"},"request_id":"20260302194338de7319971d9142ab"}

188024 > 202752

现在代码都直接交给大模型运算了?着什么算数?

算例紧张可以理解,但是频繁出现这个错误,是 claude code 的锅?是有人要害朕?

为啥出现这个?我没干什么,就是让他帮我翻译文章。

再发一个吉祥号码的:

API Error: 400 {"type":"error","error":{"message":"API 调用参数有误,请检查文档。Request 181818 input tokens exceeds the model's maximum context length 202752","code":"1210"},"request_id":"20260302164128475cc4e7028843b6"}

181818 > 202752

如果是这个所谓的 input token 和我理解的不一样,是不是可以换个说法?