话不多说直接刷就完了,支持 Gemini 原生 / OpenAI 对话 / OpenAI 画图三种格式,支持传图

sk-PJ8FktxjByi3tZbDQsoyk4kVbmLGo7i2ympu96PsRbs9A62L

gemini-3-pro-image-preview-1k
gemini-3-pro-image-preview-2k
gemini-3-pro-image-preview-4k


📌 转载信息
原作者:
realnoob007
转载时间:
2026/1/24 06:34:06

GitHub: GitHub - fengshao1227/ccg-workflow: 多模型协作开发工具集 - 基于 Claude Code CLI,整合 Codex/Gemini 后端能力,提供智能路由、代码审查、Git 工具等 17+ 个命令
觉得好用请留下你的 Star

CCG v1.7.48:约束集 + 零决策,复杂功能不翻车1 CCG v1.7.48:约束集 + 零决策,复杂功能不翻车2


这次更新了啥

集成了 OpenSpec,一个规范驱动的开发框架。

说人话就是:把需求变成约束,让 AI 没法自由发挥

之前用 /ccg:workflow 做复杂功能,经常遇到这些问题:

  • 需求说得不清楚,AI 自己脑补,结果跟想的不一样
  • 上下文太长,一个会话塞不下
  • 做到一半忘了前面说的啥

OpenSpec 的思路是:先把需求拆成一条条约束,AI 照着约束执行就行,不用猜。


新增 5 个命令

命令干嘛的
/ccg:spec-init装 OpenSpec CLI,初始化项目
/ccg:spec-research分析需求,输出约束集
/ccg:spec-planCodex + Gemini 并行分析,生成执行计划
/ccg:spec-impl按计划一步步实现,完了自动归档
/ccg:spec-review双模型审查,随时可以用

流程图

需求 ──→ spec-research ──→ spec-plan ──→ spec-impl
              │                │              │
           约束集          零决策计划      机械执行
              │                │              │
         "JWT TTL=15min" "用 bcrypt"    照着写就行
         "锁定30min" "cost=12"      不用想

每个阶段之间可以 /clear,不怕上下文爆。


约束集长啥样

传统方式,AI 研究完给你一堆信息:

JWT 是一种 token 格式,可以用来做认证...
刷新令牌可以用来获取新的访问令牌...
密码加密可以用 bcrypt 或者 argon2...

看完还是不知道该怎么做。

OpenSpec 方式,输出的是约束:

硬约束:
- JWT TTL = 15min,刷新令牌 TTL = 7d - bcrypt cost = 12 - 5 次失败后锁定 30min

软约束:
- 刷新令牌用完即失效 - 支持多设备登录

依赖:
- 需要 redis 存黑名单

风险:
- 用户表要加 failed_attempts 字段 

后面 plan 和 impl 阶段照着这个来,不用再想。


怎么用

# 先更新
npx ccg-workflow@latest

# 初始化 OpenSpec
/ccg:spec-init

# 开始
/ccg:spec-research 实现用户认证,支持 JWT 和刷新令牌
# → 输出约束集

/ccg:spec-plan
# → Codex 和 Gemini 并行分析,输出 tasks.md

/ccg:spec-impl
# → 按 tasks.md 执行,完了自动归档 # 想审查一下
/ccg:spec-review


spec-review 审查啥

Codex 和 Gemini 同时跑,各看各的:

Codex 看Gemini 看
规范约束有没有满足命名规范、代码风格
安全SQL 注入、权限XSS、CSRF
质量逻辑对不对好不好维护

结果分三级:

  • Critical - 必须改
  • Warning - 建议改
  • Info - 随便


和原来的命令啥关系

OpenSpec 这套适合复杂功能,需要追溯的那种。

简单任务还是用原来的:

  • /ccg:workflow - 一把梭
  • /ccg:frontend / /ccg:backend - 单一领域
  • /ccg:feat - 快速开发


常见问题

Q: OpenSpec CLI 装不上?

npm install -g @fission-ai/openspec@latest

Q: 上下文快满了?

每个阶段结束会提示 token 用量,快满了就 /clear,然后继续下一个命令。状态都存在 openspec/ 目录里,不会丢。

Q: 可以跳过 research 直接 plan 吗?

可以,但约束不完整的话 plan 阶段还是要做决策,效果打折。


鸣谢


版本: v1.7.48 | 更新


📌 转载信息
原作者:
feng_li
转载时间:
2026/1/24 06:33:26

令牌:sk-kFEhuzNdQmqoayHHj0dItoKVvUT3Nzbj001ImhexpRm0ZCRm
URL:http://newapi.site-ali.sakuraovo.site/

扣子上我有好多点数呀,但是不知道 coze 上到底有多少模型能用

目前就开了 deepseek 和豆包 1.6

佬们要是知道有别的模型我再放上去


📌 转载信息
原作者:
Huameitang
转载时间:
2026/1/24 06:33:14

前言:现在使用 Antigravity 反代很容易 429,然后就请求飘红,日志飘红,终端飘红。

前段时间冒出了很多软件,在进行一段时间使用后,我发现可以将他们变成一个工具链,现在因为上游压力大,工具链的使用能很好过滤掉 429 请求,让终端报错飘红减少了很多,请求该红还是 红,这个是上游决定的。

效果图:

因为添加了 ccNexus,能很好的将错误的请求 429 给过滤掉了,所以终端很少报错,几乎不用重试。有一点要注意的是 ccNexus 也有智能断端点切换,你得保证只开启 Antigravity tools 的端点配置,就能愉快的使用了

方案在下面这个帖子
【来猛烈的 AI 组合技】工具集合分享 ,看看是不是差生文具多 - 开发调优 - LINUX DO


📌 转载信息
原作者:
vkrain
转载时间:
2026/1/24 06:32:52

起源

发帖求助后,自己细想想应该有工具可以往右键添加操作,不想下载新 App,检索对比 Automator.app 和 Shortcuts.app 后决定还是使用 Shortcuts.app 搭配 AppleScript 来实现我要的操作。

脚本

-- 辅助函数:去除字符串首尾的空格、制表符、换行等空白字符
on trimText(theString)
	if theString is "" then return theString
	
	-- 使用非保留字的变量名:trimStart / trimEnd
	set trimStart to 1
	repeat while trimStart ≤ length of theString and character trimStart of theString is in {" ", tab, return, linefeed}
		set trimStart to trimStart + 1
	end repeat
	
	if trimStart > length of theString then return ""
	
	set trimEnd to length of theString
	repeat while trimEnd ≥ trimStart and character trimEnd of theString is in {" ", tab, return, linefeed}
		set trimEnd to trimEnd - 1
	end repeat
	
	return text trimStart thru trimEnd of theString
end trimText

-- 获取 Finder 当前窗口的位置
tell application "Finder"
	set currentPath to insertion location as alias
end tell

-- 弹出对话框,提示用户输入文件名,默认为“Untitled.txt”
set defaultName to "Untitled.txt"
set userInput to text returned of (display dialog "请输入新文件的名称:" default answer defaultName with title "创建新文件")

-- 清理用户输入:去除首尾空白
set fileName to my trimText(userInput)

-- 如果用户什么都没输(或只输空格),则使用默认文件名
if fileName is "" then set fileName to defaultName

-- 智能处理扩展名:
-- 情况1:文件名中不含“.”,或者以“.”开头(如“.gitignore”),则添加 .txt
-- 情况2:文件名以“.”结尾(如“笔记.”),则补全为“.txt”
if fileName does not contain "." or fileName begins with "." then
	set fileName to fileName & ".txt"
else if last character of fileName is "." then
	set fileName to fileName & "txt"
end if

-- 检查是否已存在同名文件,若存在则自动添加编号(如“文件 1.txt”)
tell application "Finder"
	set baseName to fileName
	set counter to 1
	
	-- 从文件名末尾查找第一个“.”,正确分离主文件名和扩展名
	set revChars to reverse of characters of fileName as string
	set dotIndex to offset of "." in revChars
	
	if dotIndex = 0 then
		-- 理论上不会发生(前面已处理无扩展名情况),但保留安全兜底
		set namePart to fileName
		set fileExt to ""
	else
		-- 提取扩展名(如“txt”)和主文件名(如“报告”)
		set fileExt to reverse of (characters 1 through (dotIndex - 1) of revChars) as string
		set namePart to text 1 thru -(dotIndex + 1) of fileName
	end if
	
	-- 循环检查文件是否存在,若存在则生成带编号的新文件名
	set fileName to baseName
	repeat while (exists file ((currentPath as text) & fileName))
		if fileExt is "" then
			set fileName to namePart & " " & counter
		else
			set fileName to namePart & " " & counter & "." & fileExt
		end if
		set counter to counter + 1
	end repeat
	
	-- 在当前目录创建新文件,并在 Finder 中高亮显示
	set newFile to make new file at currentPath with properties {name:fileName}
	reveal newFile
end tell

AIGC 声明:本脚部分函数由 通义千问 辅助创造,本人已验证其生成内容的真实性和有效性

使用方法

我也是第一次接触 AppleScript ,考虑可能有其他佬友也未接触使用过,特贴出使用方法

  1. 打开 Shortcuts.app
  2. 如果你是首次使用,请按⌘ + , 打开设置中的高级-允许使用脚本
  3. 新建快捷指令
  4. 设置基本信息
  5. 添加 AppleScript
  6. 在 Finder 中使用

参考文献

AppleScript 开发文档
AppleScript 入门:探索 macOS 自动化 - 少数派


如果有帮到你,还请给我投两个 LDC 吧!
或者请我喝杯咖啡

都不想的话请点个免费的也好


📌 转载信息
原作者:
LeonShaw
转载时间:
2026/1/24 06:32:36

准备工作

准备好以下文件和工具:

  • Windows 10 企业版 LTSC 2021 原版镜像 (ISO),提供一个 itellyou 的地址:
ed2k://|file|SW_DVD9_WIN_ENT_LTSC_2021_64BIT_ChnSimp_MLF_X22-84402.ISO|5044211712|1555B7DCA052B5958EE68DB58A42408D|/
  • Windows 10 IoT 企业版 LTSC 转换密钥
QPM6N-7J2WJ-P88HH-P3YRH-YY74H

安装与系统转换

按照 LTSConvert 项目页面的说明运行脚本。

关键步骤:

  • 更改更新设置 点击安装界面上的 “更改安装程序下载更新的方式”。选择跳过更新 在弹出的选项中,选择 “不是现在” (Not right now)。

  • 确认保留数据 在最终点击“安装”前的确认页面,务必检查屏幕上是否显示:保留个人文件和应用

如果未显示此选项,请不要继续,否则你的文件将会丢失。

版本转换与激活

进入“设置 > 激活 > 更改产品密钥”,输入上方 IoT 密钥 完成版本转换。

使用开源工具 https://github.com/massgravel/Microsoft-Activation-Scripts 进行永久激活

系统更新

激活完成后,进入 Windows 更新中心,检查并安装所有系统更新即可。

更新感受

  • 日常用的软件都没问题,win + s 搜索变得非常快

“我的笔记本是 16G 内存的 M3 Pro ,为什么我还需要一台只有 4 核 8G 的服务器?”

在 Reddit 的 r/indiehackers 板块,这是新手最常问的问题之一。在 Serverless (如 Vercel )和 PaaS (如 Supabase )横行的今天,VPS ( Virtual Private Server ,虚拟专用服务器)似乎显得有些“老派”。

但现实是:真正能跑通商业闭环、实现长期盈利的独立开发者,手里一定攥着几台 VPS 。

本文将从独立开发的 7 个核心痛点出发,深度解析为什么 VPS 是你迈向专业化、摆脱“代码玩具”的必经之路。


1. 摆脱“本地焦虑”:解决 node_modules 与 Docker 的空间黑洞

独立开发者最昂贵的资产是笔记本,而最廉价的则是笔记本硬盘。这波 AI 编程大部分都是 NextJS ,这也就带来了 node_modules 灾难。其实还有 cc 居然也喜欢拉 bb 。如果观察 cc 的执行过程,会发现它一直要写东西去 /tmp 目录

  • 痛点:硬盘与性能的双重榨干


    • node_modules 爆炸:同时维护 10 个项目,node_modules 能吃掉 50GB 以上的 SSD 。
    • Docker 镜像堆积:在本地运行容器会让系统响应迟滞,风扇咆哮。
    • 计算占用:本地运行 PostgreSQL 或 Redis 等中间件会显著拖慢 IDE 的响应速度。
  • 解决方案:VPS 作为“重型计算中心”
    你只需在本地保留一个轻量的 VS Code + Cursor,通过 Remote SSH 连接 VPS 。所有的重型依赖和环境都在云端运行,笔记本只负责显示 UI 。

图 1:本地开发负载 vs. VPS 远程卸载对比

2. 拒绝“SaaS 账单勒索”:从商业逻辑看成本控制

独立开发最怕的不是没用户,而是用户还没付钱,SaaS 账单先爆了。最近几年做 AI 编程,难免会接触到 supabase ,clerk 等工具,其实包括 vercel 也一样,用下来会发现一开始很爽,然后爽着爽着,账单就爆炸了。vercel 有个很有意思的坑,就是 Image 组件,编译的时候会提示最好用 <Image 组件,听起来很贴心对吧?但这个组件默认走 Vercel 的图片优化服务——每优化一张图就计费一次。流量大的站点,光图片优化费用就能超过主机费用。

Vercel 的 Hobby 免费套餐非常诱人——部署、CDN 、SSL 全包。但一旦你的项目有了流量,噩梦就开始了。

超额收费一览

资源 Pro 套餐包含 超出后收费
带宽 1 TB/月 $0.15/GB(即 $150/TB )
Edge Requests 1000 万/月 $2/百万
Serverless 执行时间 40 小时/月 $5/小时
图片优化 5000 张/月 $5/1000 张
  • 痛点:被绑架的扩展成本


    • PaaS 陷阱:Firebase 的免费额度诱人,但一旦涉及复杂备份或高并发,价格呈指数级增长。
    • 身份验证收费:Clerk 等按月活用户收费,对高频低客单价应用是噩梦。
  • 解决方案:全栈自建( Self-hosting )
    在 $5/月 的 VPS 上,你可以利用 Docker 跑满性能,同时运行:数据库( PostgreSQL )、验证系统( PocketBase )和统计系统( Umami )。

图 2:SaaS 订阅 vs. VPS 固定成本曲线对比

💡 公平地说:自建服务确实需要一定的运维能力。但最近很多海外开发者分享了自己维护 PostgreSQL 的经验——比想象中简单得多,尤其是有了 Docker 和自动备份脚本之后。后面我会详细讲怎么做。

3. 真正的 CI/CD:构建“一人 IT 部门”的自动化流水线

独立开发者的核心竞争力在于迭代速度。部署到 vercel 、cloudflare 、Netfily 等 servless 平台在早期验证需求的时候,是非常好的,但是这些平台的问题是,它们的 node 实现是不完备的,一些长时间的任务就没法跑。以前本地打包机器就开始呼啸,通过 github 的 action ,这个事不用操心了,弄好就是 docker 镜像,然后,起飞了。

  • 执行时间限制:Serverless 函数通常有 10-60 秒的超时限制,一般默认是 10s

  • 无持久进程:WebSocket 、长连接、后台任务都很别扭

  • 冷启动延迟:首次请求可能需要等待数秒

  • 痛点:手动部署的低效与错误
    如果你还在用手动执行 git pull,你不仅在浪费生命,还在增加生产事故的概率。

  • 解决方案:基于 VPS 的轻量自动化
    利用 VPS 运行 GitHub Actions Runner


    1. Git Push 触发流水线。
    2. VPS 自动拉取代码并构建 Docker 镜像。
    3. Docker Compose 自动重启容器,实现零停机更新。

图 3:基于 VPS 的自动化 CI/CD 流水线示意图

不知道是不是这个原因,现在 cloudflare 也不咋推 pages 了,又回到 worker ,感觉挺难用的,你怎么看?

4. 解决“网络壁垒”:从静默爬虫到跨境访问

很多项目在本地跑不通,不是代码问题,而是网络环境问题。开发用都的很多 npm 包,或者其他的资源,常常会因为网络,把人给气死,累死,折腾死,烦死。

  • 痛点:变动的 IP 与受限的出口


    • 固定 IP 需求:对接 Stripe 、PayPal 或银行 API 时,通常需要固定的公网 IP 做白名单。家庭宽带的动态 IP 根本没法用。
    • 网络环境问题:开发时用到的很多 npm 包、Docker 镜像、GitHub 资源,经常因为网络问题把人折腾得够呛。
    • 反爬虫封禁:如果你在做数据采集相关的项目,家庭宽带 IP 极易被反爬策略封禁。
  • 解决方案:VPS 作为全局网络枢纽


    • 固定身份标识:为业务提供永久的公网 IP ,Stripe Webhook 、OAuth 回调都能稳定工作。
    • 反向代理中心:一个 VPS 配合 Nginx 或 Caddy ,可以管理 10+ 个域名并映射到不同的本地端口。
    • 开发环境加速:npm install 、docker pull 都在 VPS 上执行,下载速度飞快,不再受本地网络限制。

image.png

和 nginx proxy manager 有仇,已经好几次了,弄它的 Docker ,能占 10 来 G 的空间,完全不理解,caddy 就小巧很多。

5. 守护“睡后收入”:24/7 监控与容灾

独立开发最痛苦的时刻,是早上醒来发现服务已经挂了一整晚,而你毫无察觉。(希望是伪命题,真来钱的项目,还是很上心的!)

痛点:缺乏哨兵

  • 本地电脑会休眠,没法做持续监控
  • 免费的外部监控工具检测频率太低(如 5 分钟/次),发现问题时用户早就流失了
  • 很多问题是"偶发性"的,等你手动检查时一切正常

解决方案:自建监控站

在 VPS 上部署 Uptime Kuma(或类似工具),每 30-60 秒检测一次全球访问状况。一旦挂掉,立即通过 Telegram 、Discord 或邮件通知。

监控清单建议

监控项 检测频率 告警方式
HTTP 状态码 60 秒 Telegram 即时通知
SSL 证书到期 每天 提前 14 天预警
服务器资源 5 分钟 CPU/内存超 80% 告警
数据库连接 60 秒 连接失败立即通知

进阶玩法

  • Uptime Kuma 做可用性监控
  • BezelNetdata 做服务器资源监控,Bezel 还挺好用的。Netdata 稍微重点。
  • 两者结合,形成完整的监控闭环

图 4:全天候监控与即时告警闭环

6. 数据主权:独立开发的“最后防线”

  • 痛点:平台依赖风险

    如果你的数据全在 Firebase ,某天账号因为合规问题被封,你的所有努力将瞬间清零。

  • 解决方案:VPS 本地化存储 + 异地备份


    • 数据隔离:数据库文件完全属于你。
    • 自动化备份:编写一个简单的 Cron 任务,每天定时将数据加密并同步到 S3 或你的本地存储。

image.png

7. 独立开发者的资源规划:“1 + N” 策略

针对 2026 年的典型开发场景,我们建议采用以下阵列:

类型 规格建议 核心作用
1 台主领地 2 核 4G 或 4 核 8G 运行 Nginx 、核心数据库、核心产品。
N 台哨兵机 1 核 1G 或更低 运行 Uptime Kuma 监控、小型爬虫、测试环境。
为什么需要分开?
  • 监控服务不应该和被监控的服务在同一台机器——否则机器挂了你也收不到告警
  • 测试环境和生产环境隔离,避免误操作
  • 多台小机器比一台大机器更有弹性

image.png

Reddit 上 Hetzner 被反复提及为"性价比之王":同样的价格,配置通常是美国云服务商的 2-3 倍。缺点是机房主要在欧洲,亚洲访问延迟较高。

咋说呢? 数据库还是很重要的,如果精力有限,就还是用 neon 或者 supabase 之类的。

总结:从“玩票”到“专业”的入场券

拥有 VPS 的那一刻起,你就不再只是一个“写代码的人”,而是一个 “系统的掌控者”。它为你提供了:

  • 确定性:不再受本地环境变化的干扰。
  • 连续性:产品 24 小时独立生存。
  • 商业性:以最低的边际成本支撑业务增长。

正如独立开发圈子里流传的一句话:“你的第一个服务器 IP ,就是你产品的第一张名片。”(我编的)

VPS 入门:为什么独立开发者需要一台 VPS ?( 2026 深度版)

最近失眠有点严重,试了各种白噪音 app ,要么收费要么广告太多,干脆自己撸了一个

功能很简单:

6 种声音随便混:雨声、雷声、火焰、风声、溪流、鸟鸣
调好音量直接听,睡前开着,困了自动定时关掉
还配了几个好看的背景场景,看着就困
亲测雨声+小火苗效果拔群,基本 20 分钟就睡着了

有同样睡不着的朋友可以试试: https://whitenoiseforsleeping.rest

纯分享,不收钱不注册,希望能帮到有需要的人

十年前左右的时候吧,快过年,过年期间需要举办婚礼。
年前连续加了一个月的班, 基本上天天 16*7 的工作节奏。
每天晚上都 12 点左右回家。第二天正常时间上班。周末也加班。

当时记得我手头 3 个项目同时在开发。
ABC 三个项目,一天时间段上午、下午、晚上分 3 份开发不同的项目这样。
由于其中一个项目就我一个人负责开发,需求设计非常模糊,
每次沟通需求都发现一堆问题,根本没办法开发。

正打算跟领导提请假提早回家过年,年后晚点来的时候,
领导提出过年前得出一个版本
其实当时代码都没写几行
跟领导说明了情况,领导表示不行,必须要出一个版本,这是死命令。
否则他也没办法交代
于是最后两三天压力巨大,天天都干到更晚。

终于熬到最后一天,就在下班前半个小时左右。
忽然咳嗽不止,眼睛也忽然看不清了,眼前一片模糊。
好不容易回到家,发现脚也肿了,疼的要命。

第二天发现走路都走不了了。还是让其他人送我去的离家最近的中西医结合医院。
挂了骨科,眼科,内科,对于这个情况,每个科诊断都不同。
每个科室都质疑其他科室的结论。
也不知道听谁的。

眼睛,咳嗽后来是在医院输了三天液逐渐好转,但是脚疼越来越失控。
后来才知道脚是痛风第一次发作。
但是骨科医生在诊断出我是痛风发作的情况下,没有开任何治疗痛风的药。开了一堆中成药,也是匪夷所思。
就这样把我天天疼的死去活来。

春节期间回了老家,老家医院又各种放假。
就在老家门口诊所看,诊所把我鉴定为风湿...给我天天进行激素治疗。
激素一停,立马就疼。诊所也没办法。只能硬抗到医院开门。

这个情况下,我自己当时是打算取消婚礼的。父母对婚礼又特别看中,
我爸妈死活不同意。就感觉恨不得死也要死在婚礼上的决绝。
那几天都在忙婚礼,真的也没人关心我死活。

婚礼硬撑着举办了两场,老家农村一场,县城里面一场。
第一场婚礼结束后,脚疼的我大喊大叫,整栋楼都能听到...

第二场婚礼完了以后,才被进了县城人民医院,最终按痛风治疗好的。
公司那边因为我生病,项目停摆一个月。领导也急疯了,催促了好几次
说来也真的滑稽和心酸。

身体自那以后,感觉就差了很多。还留了一个痛风的病,时不时背刺一下。
虽然没有猝死那么严重,但是当时真的身体给了各种崩盘的信号了吧。

各位程序员自己保重。身体是自己的,项目是公司的...

新加坡的会场里,全球人工智能顶会 AAAI,正式揭晓年度奖项,也迎来了它的第 40 个年头。

今年共颁发了 5 个杰出论文奖,以及 2 个经典论文奖。在获奖名单中,竟然还有“机器学习三巨头”之一的 Yoshua Bengio

不过这一次,他并不是因为最新成果获奖,而是凭借在 2011 年写的一篇论文获得了经典论文奖。而且不久前,他刚达成 AI 领域首个“百万被引作者”的成就。

为什么 10 多年前的这篇论文,会在今年被重新拉出来,还获得了经典论文奖?

不妨来看看它讲了些什么。

论文名为 Learning Structured Embeddings of Knowledge Bases(《面向知识库的结构化表示学习》)。提出了一种方法,把知识库的结构化数据嵌入到连续空间中,从而让结构化知识更容易用于机器学习任务。

换句话说,这篇文章解决的是如何把离散世界(知识、事实、关系)嵌入到连续空间;以及如何让神经网络不靠纯统计,而是“接住现实结构”。而今天热门的世界模型、RAG、Agent 的外部记忆等等这些东西,从本质上讲,全都在复用这条路线。

再说回今年获奖的 5 篇杰出论文,这些论文有讲机器人和 VLA 的,有在讲如何在连续时间系统中让 AI 模型“白盒化”的,还有讲 LLM 和 CLIP、讲高频信号和局部判别结构的。

串起来看,这些论文的研究方向,其实可以概括出一个共同指向:AI 的竞争,已从拼实验环境的中的炫酷 Demo,转向真正的应用层。Scaling Law 那套虽然不完全失效,但多少有点过时了,谁能在真实世界中被理解、被修订、被信任越来越关键。

AAAI 2026: AI 走向现实,评奖标准重塑

下面来看看这几篇杰出论文,都有哪些有意思的信息。

具身智能领域:

论文名:ReconVLA: Reconstructive Vision-Language-Action Model as Effective Robot Perceiver(ReconVLA:作为高效机器人感知器的重建式视觉-语言-动作模型)

要说清本文的创新点,需要再这里先简单回顾一下什么是 VLA——VLA(Vision-Language-Action)具身智能领域的一个关键模型,可以把视觉感知、语言理解和动作生成统一到同一个模型中,直接根据“看到什么 + 听到什么”,来输出可执行机器人动作。

不过当前 VLA 的缺陷也是很明显的:比如模型在执行动作时,视觉注意力高度分散;即便模型能“理解指令”,但在复杂场景、多干扰物、长任务中,往往看不准真正要操作的物体。

结果就是:抓错对象、操作不精确(现实世界对精确度要求很高)、长链任务中途失败等等。

总之,以往 VLA 只监督“动作输出”,几乎不约束“视觉感知过程本身”。

ReconVLA 的关键思想是:不“告诉模型看哪里”,而是“逼模型把关键区域重建出来”。

其核心机制,简单来说,就是模拟人类视觉的“凝视(gaze)”机制,不要求模型输出框,也不输入裁剪图,而是让模型在内部生成一种“重建信号”,去还原“当前要操作的局部区域”。

论文还系统性地对比了三类视觉定位(grounding)范式:

  • 一类是以外部检测器和裁剪图像为代表的 Explicit Grounding

  • 一类是先输出目标框、再生成动作的 CoT Grounding

  • 以及作者提出的 Implicit Grounding(隐式 Grounding),也就是 ReconVLA 的方式。

图注:不同范式 Grounding 之间的概念性对比。

前两类方法本质上都是在显式告诉模型“答案在哪里”,并未真正改变 VLA 内部的视觉表示和注意力机制。

而 ReconVLA 通过重建过程,将关键区域作为一种隐式的视觉监督信号,引导模型生成所谓的“重建 token(reconstructive tokens)”,从而在不引入额外输入或输出的前提下,重塑视觉感知能力。

换句话说,它不再让模型“蒙着眼睛试动作”,而是强制模型在每一步决策前,先把目标对象看准,再去动手

关于从“结果可解释”,走向“结构可操作”:

论文名:Causal Structure Learning for Dynamical Systems with Theoretical Score Analysis

(基于理论评分分析的动态系统因果结构学习方法)

这篇论文提出了一种方法:CADYT。能够在连续时间、甚至不规则采样的数据中,同时刻画系统的动力学演化,并恢复其中的因果结构。

更重要的是,作者证明了用于判断因果关系的评分函数,在理论上等价于一种合理的模型选择准则,而不是经验性的启发式指标。换句话说,就是这个评分不是凭经验设计的,而是从理论上保证:它会偏向那些“解释得刚刚好、不多也不少”的因果结构。

在现实世界的系统中,无论是工业控制、物理系统,还是医疗过程,系统本质上都是连续时间演化的,而且由稳定的因果机制驱动。但以往的方法往往只能解决其中一半问题。

一类是时间序列因果发现方法,它们通常基于离散时间建模(如 DBN、Granger),并假设规则采样,因此在面对真实的连续动力学和不规则采样时,难以准确刻画系统本身的演化机制。

另一类是连续时间动力学建模方法(如 Neural ODE、GP-ODE),虽然能自然处理不规则采样,却主要关注预测精度,本质上并不区分因果依赖与偶然相关。

这就留下了一个长期存在的空白:几乎没有方法,既工作在连续时间框架下,又能够同时恢复系统的动力学机制和因果结构。

而 CADYT 正是针对这一空白提出的。它将连续时间的高斯过程动力学建模,与基于最小描述长度(MDL)和算法马尔可夫条件(AMC)的因果评分结合起来,在不规则采样条件下,通过比较不同因果结构对数据的“压缩能力”,来识别真正的因果关系,并给出了明确的理论保证。

说得更直白一点,这项工作把连续时间动力学建模,从“拟合得像不像真实轨迹”,推进到了“学到的机制在因果上是不是对的”。

论文名:Model Change for Description Logic Concepts

(描述逻辑概念的模型变更)

此论文还未公开上传,暂无链接。

关于表示学习,重新审视结构本身

论文名:LLM2CLIP: Powerful Language Model Unlocks Richer Cross-Modality Representation

(LLM2CLIP:强大语言模型解锁更丰富跨模态表征)

CLIP(Contrastive Language–Image Pre-training)是一个经典的多模态模型,通过对比学习,将图像和文本映射到同一语义空间,从而实现“以文找图、以图找文”等跨模态理解能力。

CLIP 在跨模态检索和基础语义对齐上表现出色,但它也有一个公认的短板:文本编码器容量较小、上下文长度有限,对长、复杂、信息密集的文本理解能力不足。这在长文本检索、多语言理解等场景中尤为明显。

LLM 在语言理解、上下文建模和世界知识方面,倒是明显更强。但问题在于,LLM 不能直接接入 CLIP

——一方面,原生 LLM 的句向量并不具备对比学习所需的“高区分度”,很难有效拉开不同 caption 之间的距离;另一方面,如果端到端联合训练 LLM 和 CLIP,计算成本也高得不可接受。

这篇论文提出了一种系统化的新方法,名曰:LLM2CLIP,顾名思义,把 LLM“接入”或“输送”到 CLIP 里,用 LLM 来替代或者增强 CLIP 的文本能力。

但这并不是简单地把 LLM 直接接进去。作者给出的解决路径,是分两步走,各解决一个关键障碍

第一步,是先让 LLM 成为一个“合格的文本 embedding 模型”。为此,论文提出了 Caption-Contrastive Fine-tuning

使用同一张图像对应的不同 caption 作为正样本,通过对比学习,让语义相近的描述在向量空间中更接近、不相关的描述更远;同时配合平均池化、双向注意力和 LoRA 等结构调整,提升句向量的稳定性和可区分性。

这一步的目标并不是做多模态,而是把 LLM 训练成一个真正“好用”的文本表示器。

第二步,则是直接用经过处理的 LLM,替换掉 CLIP 原有的文本编码器。在这一阶段,LLM 参数被冻结,仅训练一个非常轻量的 adaptor 来对齐视觉特征,使整体训练流程几乎等同于普通的 CLIP 微调,算力成本基本不变。

大量消融实验表明:同时保留两个文本编码器、或试图在两者之间做复杂对齐,效果反而更差;“直接替换”是最简单、也是最有效的方案。

实验结果显示,LLM2CLIP 在长文本检索任务上提升最为显著,短文本检索也有稳定增益,同时多语言检索能力明显增强。更重要的是,这些提升是在仅使用百万级数据、几乎不增加训练成本的前提下实现的。

总体来看,LLM2CLIP 的价值在于,它没有重造一个更大的多模态模型,而是用一种低成本、可复用的方式,把“语言理解”这块短板,直接补进了 CLIP 的核心结构里。

论文名:

High-Pass Matters: Theoretical Insights and Sheaflet-Based Design for Hypergraph Neural Networks

(高频信息的重要性:面向超图神经网络的理论分析与 Sheaflet 方法设计)

此论文还未公开上传,暂无链接。

总而言之,这些研究都在把关注点从结果层面的性能,推向模型内部的感知、结构和机制本身。

论文地址:

https://arxiv.org/abs/2508.10333

https://arxiv.org/abs/2411.04997

https://arxiv.org/abs/2512.14361

参考链接:

https://aaai.org/about-aaai/aaai-awards/aaai-conference-paper-awards-and-recognition/

https://aaai.org/about-aaai/aaai-awards/aaai-classic-paper-award/?utm_source

https://aaai.org/conference/aaai/aaai-26/award-talks/

大家好!

最近花了一些时间折腾一个终端项目,想和 V 友们分享一下,顺便厚脸皮求个 Star ⭐

项目介绍

zTerm 是一款基于 Rust 开发的现代化终端模拟器,使用 GPU 加速渲染,追求极致的性能和流畅体验。

🔗 GitHub: https://github.com/zerx-lab/zTerm

✨ 核心特性

  • ⚡ 极致性能 - 基于 Rust + GPU 加速渲染引擎,启动迅速,响应流畅
  • 🖥️ 跨平台 - 原生支持 Windows 、macOS 和 Linux
  • 📑 多标签与分屏 - 灵活的标签页和分屏布局
  • 🔍 智能补全 - 内置命令补全和历史搜索
  • 🧱 区块化输出 - 每条命令输出独立成块,便于浏览和复制
  • 🌏 完美中文支持 - 支持中日韩 IME 输入

🛠️ 技术栈

  • 核心语言:Rust 100%
  • 终端引擎:采用 Alacritty 终端引擎
  • 渲染:GPU 加速

🎯 为什么做这个?

作为开发者,每天都要和终端打交道。市面上虽然有很多优秀的终端( Windows Terminal 、iTerm2 、Warp 等),但我想尝试用 Rust 从头构建一个现代化、高性能的终端,同时支持一些我个人比较需要的功能。

🚧 当前状态

项目还处于早期开发阶段,已实现:

  • ✅ 基础终端模拟功能
  • 🔄 完整 VT100/VT220 支持
  • 🔄 多标签页

计划中:

  • 📋 分屏布局
  • 📋 SSH 集成
  • 📋 AI 助手


如果你也在寻找一款高性能的终端,或者对 Rust GUI 开发感兴趣,欢迎来看看!

觉得项目有意思的话,麻烦点个 Star 支持一下 🙏

有任何建议或问题也欢迎在 GitHub 上提 Issue 。

感谢各位 V 友!

“如果一个 AI 能解 IMO,但解决不了任何现实问题,那它不是通用人工智能。”

这是卡内基梅隆大学助理教授、艾伦人工智能研究所研究科学家,蒂姆·德特默斯对 AGI 给出的判断,他用一篇文章 《通用人工智能为何不会成为现实》 直接把 AGI 从神坛上拽了下来。

image

有意思的是,几天后,加州大学圣地亚哥分校助理教授、Together AI 内核副总裁丹·傅,给出了完全相反的判断。他写了一篇 《通用人工智能终将成为现实》,说 我们也许早就已经实现了 AGI。

image

于是,两篇文章,一场关于 “AGI ” 的争论,被带进了播客现场。

这场讨论并非空谈,两位嘉宾都是同时深耕学术界与产业界的一线研究者

蒂姆·德特默斯长期深耕深度学习量化领域,即模型压缩,如何在更低精度、更少算力下,让模型保持可用性能。

image

在蒂姆·德特默斯看来,判断 AGI 是否成立,首先要回到一个常被忽略的前提:计算是物理的。

在他看来,内存迁移、带宽、延迟,以及冯·诺依曼瓶颈,决定了算力不可能无限扩张。他说 “几乎所有指数增长,最终都会撞上资源和物理极限”。 所以,指数增长终将放缓,Scaling Law 也不例外。

但丹·傅显然不这么看。在他看来,现在谈“算力见顶”,还太早了。丹·傅每天都在和 GPU 内核、算力利用率打交道,在他看来,“我们甚至还没真正用好上一代硬件。”

image

在现实系统中,算力其实被严重低估和浪费了, 大量性能消耗在内核调度、系统开销和工程细节上。更关键的是,人们今天评测和使用的“最强模型”,往往是基于一到两年前的算力集群训练出来的,它们并不能代表当下硬件和大规模集群所能达到的真实上限。

他因此提出了一个直观的估算思路,用来说明算力增长的潜力来自多个维度的叠加:

  • 新一代硬件 带来约 2–3 倍 的性能提升;

  • 系统与工程优化 将算力利用率提升 约 3 倍;

  • 更大规模的集群 再带来 约 10 倍 的规模效应。

这三者相乘,意味着可用算力在理论上可以提升接近 90 倍。这并不是纸面上的推算,而是正在产业中逐步发生、逐步兑现的现实潜力。

有意思的是,当争论继续推进,两人反而在一个问题上开始靠拢:AGI 到底是什么?

关于 AGI 的定义,大致有两种主流视角:

一种从认知能力出发,看模型能否覆盖足够多的认知任务;

另一种则从经济角度出发,看它是否真的改变了生产方式。

这一点上,双方达成一个共识:AGI 是什么并不重要,重要的是,它有没有改变我们工作的方式。

在访谈后后半部分,大家从未来拉回到了现实,Agent 成为了关键话题。

丹·傅在节目中提到一个有趣的时间点:2025 年 6 月, 那是他第一次意识到,Agent 可能真的越过了拐点。

image

他当时发现机器学习工程中最难的技能之一、编程领域的终极难题——“GPU 内核编程” 被代码智能体啃下来了。他自己亲测:原本一个 GPU 内核功能开发得磨一周,那天靠着代码智能体,一天就搞定了三四个,工作效率直接提升了 5 倍。而他的团队用上后,那些原本需要整支团队耗数月的复杂系统开发,也变得轻装上阵。

这让丹·傅想起了自己对自动驾驶的态度变化,从长期怀疑到真正坐上 Waymo,他意识到技术的突破可能藏在某个猝不及防的瞬间。

针对 Agent 的爆发式潜力,蒂姆·德特默斯曾发布了一篇掷地有声的文章 《要么善用 Agent,要么被时代淘汰》。在他看来,代码 Agent 本身就是高度通用的 Agent,因为代码几乎可以描述和解决所有数字化问题。他甚至直言,“超过 90% 的代码和文本,本就应该由 Agent 来生成。但同时他也强调,“人类必须对最终结果承担责任,而非盲目依赖 AI 的输出。”

image

两人将 Agent 形象地比作“需要精细化管理的实习生”,只要给它明确背景信息、拆解任务边界、设定执行约束,人类无需过度干预其执行过程,而是把注意力聚焦在把控方向上,用专业判断力校验结果。而在 Agent 时代,真正吃到红利的将是有深厚积累的专家,其专业基础越深厚,Agent 能为其创造的效率增量就越显著。

在节目的最后,关乎对 AI 行业未来的预判,双方抛出了一系列深刻洞见。

在他们看来,小模型会成为行业新热点、开源模型会进一步飞跃;新硬件、多模态、端侧 AI 都会有进一步发展。

其中,硬件赛道将走向多元化发展,模型训练与推理环节的专业化分化会进一步加剧。

更值得关注的是,Transformer 架构独霸天下的时代会落幕,各类新架构会登上时代舞台。

他们还特别提到了中国的 GLM-4.7、MiniMax、DeepSeek 等优秀模型,对中国大模型的快速进步表达了高度认可。

在他们看来,相比技术路线相对集中的美国,中国团队反而更敢于探索多种可能性,比如状态空间模型、线性注意力以及混合架构等,通过架构创新或极致性能,让开源模型脱颖而出。

同时,他们也指出,中国的模型团队在技术路线上更 务实。与“先做出最强模型,再等待应用出现”的硅谷思路不同,中国团队更关注模型是否真正能落地、是否能在现实场景中产生价值。正是这种务实的发展思维,可能会在未来深刻影响人工智能的技术形态以及它所能创造的社会价值。

以下是播客全文,更多精彩细节,欢迎来看:

“AGI 能否成为现实”之争

主持人:蒂姆,几周前你发表了一篇极具争议性的精彩博文,标题是 《通用人工智能为何不会成为现实》。而丹,你在几天后也发布了一篇同样引人入胜的回应博文,标题为 《通用人工智能终将成为现实》。我想先了解一下二位的背景,你们都有着一个有趣的特点,就是兼具产业界和学术界的从业经历。蒂姆,不如你先讲讲吧。

蒂姆・德特默斯:我是卡内基梅隆大学机器学习与计算机科学系的助理教授,同时也是艾伦人工智能研究所的研究科学家。

我过往的研究主要聚焦于高效深度学习量化技术,简单来说就是模型压缩, 把大模型从 16 位精度压缩到 4 位精度左右,这方面我做了不少核心研究。比如一种高效的微调方法,我们将模型压缩至 4 位精度,在模型上使用适配器,这样所需的内存相比全精度模型能减少多达 16 倍。

目前我正致力于代码 Agent 的研究, 我们将在约两周后发布一项非常令人振奋的成果,打造出了目前最先进的 Agent,它能快速适配私有数据,在任意代码库上都能实现出色的性能表现,这一成果真的让人充满期待。

主持人:丹,该你了。

丹・傅:我是加州大学圣地亚哥分校的助理教授,同时担任合聚人工智能公司的内核副总裁。

在产业界,我的工作主要集中在提升模型的运行速度,GPU 内核正是将模型转化为实际在 GPU 上运行程序的关键,你可以把它理解为专门的 GPU 程序。

我的博士阶段以及实验室的大量研究都围绕这一方向展开,比如我研发了快速注意力机制,这是一款针对当下多数语言模型核心运算的高效内核。我还研究了 Transformer 架构之外的替代架构, 比如状态空间模型等。

在合聚人工智能,我主要关注如何打造当下最优的语言模型,以及如何进一步提升它们的运行速度。

就在本期节目录制的今早,我们还和库尔索公司联合发布了一篇博文,介绍了我们如何为其多款模型实现加速,并助力他们在英伟达的布莱克韦尔(Blackwell) GPU 上推出了作曲者 2.0 模型,这大概就是我的工作内容。

从 AGI 的定义,聊到对 AGI 的现实判断

主持人:接下来我们聊聊通用人工智能的话题,节目后半段再探讨 Agent 和代码 Agent,以及二位的相关见解。通用人工智能这个术语被大家广泛使用,但我想大家都认同,目前还没有人能准确定义它。为了本次探讨,二位认为什么样的通用人工智能定义是实用的?

丹・傅:当然。我和蒂姆在这一系列博文中 反复探讨的一个问题,就是通用人工智能的定义。

就我而言,我最近一直在思考,以当下的模型发展水平,尤其是语言模型,再结合后续会谈到的 Agent 来看,以 5 年前、10 年前,甚至我和蒂姆刚开始读博时任何人给出的通用人工智能定义,我们其实已经实现了当时的设想。如今的模型能写代码、能生成人类语言,即便有时用词上会有些小瑕疵,但确实能完成这些令人惊叹的任务。我还会思考,这种技术发展到何种程度,会引发一场新的工业革命,真正改变我们当下的工作方式,并产生巨大的经济影响。

在软件工程领域,我觉得我们已经身处这样的变革中,或者说即将迎来全面变革。虽然在一些高度专业化的领域,比如模型未必能写出世界上最优质的福兰语和钴语言代码,但在网页开发,甚至很多底层系统工程方面,它们的表现已经非常出色。

我写那篇博文的一个原因就是,审视当下的发展,我们或许已经实现了通用人工智能,或者说某种形式的通用人工智能。即便尚未完全实现,下一代正在训练的模型,只要比当下的模型表现更好,我们就已经取得了令人惊叹的突破。

蒂姆・德特默斯:我写那篇博文时发现,自己竟然忘了在文中给出通用人工智能的定义,尽管整篇文章都围绕这个主题展开。我想这在某种程度上也反映了我们对通用人工智能的思考现状 —— 我们并未认真去界定它。当然,目前存在多种定义,各有优劣,正如你所说,没有一个定义能获得所有人的认同。

我简单提几种比较主流的,一种是将通用人工智能视为认知能力、认知任务的集合,关注模型能完成哪些认知层面的工作。 软件工程、文本创作都是高度依赖认知的任务,而让机器人在空间中移动则更偏向操作层面,当然也有人认为肢体移动的规划也属于认知范畴,但多数人会将其区分开来,认为所有数字化的任务都属于认知领域,物理层面的操作则超出了这一范畴。

另一种我认为很有意义的定义视角是经济层面,看人工智能是否能引发一场新的工业革命,是否具备广泛的实用性,能应用到各个领域,推动各类工作的效率提升,就像计算机的出现那样。 当然,计算机刚出现时,生产率其实出现了下降,直到其在经济中广泛普及,生产率才重新回升。通用人工智能的发展或许也会经历类似过程,在软件工程等领域,其带来的效率提升已经十分显著。

主持人:我们直接切入核心争论吧。蒂姆,你曾提到 AGI 的相关构想的起源,这一点让我觉得很有意思,你能展开讲讲吗?

蒂姆・德特默斯:好的。先梳理一下整体的背景,当下关于 AGI 的一些观点,根植于特定的思维模式,主要来源于有效利他主义社群和理性主义社群。

我 15 年前也曾是这些社群的一员。在推特上,总能看到有人说 “两年内就能实现通用人工智能”,一年后又有人说 “两年内就能实现通用人工智能”,年年如此。我觉得这种想法有些草率,也体现出一种信息茧房的状态,持这种观点的人很少接触不同的想法。这也是我写那篇博文的主要动机,我希望提出一些不同的观点,为当下主流的思考提供一种反视角。

算力是否见顶

主持人:你核心的观点是,这些构想与实际的计算现实之间存在矛盾,这样概括准确吗?

蒂姆・德特默斯:没错。这其中既涉及物理层面的限制,也有理论层面的问题,而这两方面都存在 一个共同的规律 —— 收益递减。所有指数级增长的事物最终都会放缓,因为发展需要资源,而资源总会耗尽,这里的资源可以有多种解读。

从物理层面来看,技术的进一步发展会变得越来越困难,几乎所有研究和开发领域都是如此。前期的进展往往容易实现,而后续要取得突破,需要投入更多资源,发展速度也会越来越慢。

再看计算设备的物理现实以及计算本身的结构, 其实有用的计算主要包含两个环节:

首先是将数据从不同位置收集起来,汇聚到指定位置,然后对这些信息进行整合,完成信息的转化处理。简单来说,就是结合已知信息,计算出未知的新信息。有用的信息,必然是从已有的信息中转化而来的。如果只是大量转移信息,却不进行处理,就无法产生新信息;如果只是对现有信息进行大量计算,又会错失跨领域的洞察和间接的启发。我认为这一点与我们当下的神经网络架构高度契合。

早期的卷积神经网络表现出色,原因就在于它们几乎不怎么移动内存,而是专注于大量计算,这意味着这类设备需要强大的浮点运算能力,而内存带宽则没那么重要。当发展到大规模密集计算、大矩阵运算阶段,就到了当下神经网络的发展方向,但此时仍保留着循环机制的特点,需要关注之前的状态。不过由于循环的特性,计算的内存复用率极低。

而 Transformer 架构,先是通过大矩阵将前一层的输入信息进行转化,再通过注意力机制实现跨时间或空间的信息关联。我认为这是处理信息最根本的两种方式:一是让信息之间建立关联,或对信息进行转化;

二是让信息与关联较远的其他信息建立联系,也就是挖掘长期关联,并基于已有信息进行转化。

主持人:你认为这一发展进程正在放缓,对吧?你的博文中有一句非常引人注目的话,称 “图形处理器的发展将不再有实质性突破”,这是核心观点,能说说原因吗?

蒂姆・德特默斯:这个观点包含两层含义,首先是一个非常根本的物理问题,也就是我刚才提到的内存转移和计算的关系。

计算要产生价值,就必须将内存数据转移到进行计算的本地区域,这其实是一个几何问题。你需要一个大容量的信息存储区,然后将其中的信息转移到计算区域。而我们已经找到了实现这一过程的最优物理方式:配备大容量但速度较慢的动态随机存取存储器,再将数据转移到高速缓存中。

从几何结构来看,这是实现高速运算的最优解,针对特定规模的计算任务,这种架构的效率是最高的。如果是矩阵乘法这类不同规模的计算任务,就需要使用图形处理器而非中央处理器,因为图形处理器虽然延迟更高,但吞吐量更大,能传输更多数据,只是速度稍慢。我们可以对缓存的结构、大小,以及核心的共享方式做一些微调,但归根结底,核心的问题始终存在 —— 这是一个几何难题,空间的利用方式是有限的,这就决定了数据的访问模式和延迟始终存在固定的限制,其中最大的延迟来自大容量的动态随机存取存储器,这也是主要的性能瓶颈。这一瓶颈也被称为 冯・诺依曼瓶颈,几乎所有计算机都受此限制,具体来说,就是需要将程序传输到执行区域才能运行。对于神经网络而言,就是要将权重和输入数据传输到张量核心这一执行单元。

想要绕开这一瓶颈的方法寥寥无几,唯一的途径是进行本地内存存储和本地计算,市面上也有一些处理器尝试实现这一点,比如存算一体处理器,能在很大程度上在芯片内部解决冯・诺依曼瓶颈问题,但这类处理器仍需要从外部向芯片内传输数据,这就使得冯・诺依曼瓶颈从芯片内部转移到了存储设备或网络层面,问题只是发生了转移,本质并未改变。你仍需要通过网络将存储在磁盘或内存中的程序加载到芯片中,这还是同一个物理问题,只是调整了几个变量而已。这是问题的第一个层面,目前还没有能解决这一问题的架构。

第二个层面,也是我的核心观点所在:想要突破瓶颈,需要依靠新技术,但当新技术的潜力被充分挖掘后,又需要新的技术实现进一步突破。

比如,我们从动态随机存取存储器发展到了高带宽存储器,也就是堆叠式的动态随机存取存储器,速度大幅提升,但这种存储器的堆叠层数有限,因为其制造和测试的难度极高,良品率很低。到 2026 年,高带宽存储器的产能将会不足,无法实现规模化生产,因为制造难度实在太大。我们已经见证了诸多技术创新,张量核心的出现是一大突破,8 位精度、4 位精度的量化技术也相继落地,我和其他研究者的研究都表明,这些技术在信息论层面和实际应用中都是接近最优的。

如果基于足够多的数据进行训练,4 位精度是不够的,实际需要 8 位精度,这意味着量化技术已经发展到了极限。硬件的潜力也被挖掘殆尽,目前没有新的技术可以突破,我们能做的只是优化制造工艺,降低成本,却无法提升速度。各项功能的开发也已到极致,稀疏化技术是很多人尝试的方向,这一研究已经持续了 50 年,我自己也做过相关尝试,这或许是最后一个可探索的方向,但 4 位精度的量化技术已经意味着量化领域的发展走到了尽头。

简单来说 ,功能和硬件都已被开发到极限,这就是我们当下的处境

主持人:太有意思了。丹,你对这些观点有什么看法?

丹・傅:我非常认可蒂姆的这篇博文,因为当下有不少关于通用人工智能的讨论,只是简单地按照指数增长的趋势去推演,认为到某个时间点,人工智能会发展到掌控整个宇宙的程度,我一直觉得这种思考方式有些片面。我认同蒂姆从实际物理限制角度出发的分析,正如他所说,这些都是依赖物理输入、进行实际物理计算的系统。

我的观点是,看看当下的系统和我们训练的模型,我们甚至连上一代硬件的潜力都远未充分挖掘,更不用说新推出的硬件了。

从技术层面,我在博文中主要提出了两个核心观点:

第一,看看当下那些表现出色的模型,我在博文中主要以开源模型为例,因为开源领域会更多地披露模型的训练过程和所耗资源,而开放人工智能和思存人工智能等公司并未公开相关数据。

以 DeepSeek 模型为例,这是目前最优秀的开源模型之一,它在 2024 年底完成训练,使用的是上一代的英伟达 H800 GPU,这款显卡因出口限制做了性能阉割,并非原版 H100。根据公开报告,该模型的训练使用了约 2000 块 H800 显卡,耗时约一个月。计算一下实际的算力利用情况会发现,芯片的有效利用率仅约 20%,行业内将这一指标称为模型浮点运算利用率。而在 21 世纪 20 年代初,我们在旧硬件上训练不同架构的模型时,轻松就能实现 50% 甚至 60% 的模型浮点运算利用率。如果能将这一指标提升,再加上我的好友崔最近发布了一系列能优化模型训练的新内核,单是这一项优化,就能让算力利用率提升 3 倍。

第二,需要意识到的是,这款 2024 年年中开始训练的 DeepSeek 模型,在 2026 年初仍是众多优秀开源或类开源模型的基础。而从那之后,我们已经搭建了全新的算力集群,搭载了当下最新的硬件,比如英伟达的布莱克韦尔系列显卡。普尔赛德、瑞弗莱克申等公司都在搭建包含数万个 B200、GB200 芯片的算力集群。

对比来看,新一代硬件即便保持和之前相同的精度、相同的配置,运算速度也能提升 2 至 3 倍,算力集群的规模更是扩大了 10 倍,再加上 3 倍的纯技术优化空间,整体的可用算力能提升 3×3×10,也就是 90 倍。这还没有考虑未来的算力集群建设,只是当下已经落地、有人正在用于模型训练的集群。

我的核心观点是,单从这些基础的硬件条件来看,就能发现可用算力相比我们当下所依赖的模型,还有多达两个数量级的提升空间,也就是 100 倍。 当然,我们可以争论算力规模扩大是否会带来收益递减,缩放曲线是否依然有效,但现实的算力潜力就摆在眼前。

这还没考虑蒂姆提到的那些点,比如目前的训练大多采用 8 位精度,而 4 位精度的训练方法才刚刚开始形成相关研究成果;GB200 芯片有 72 个连接速度极快的核心,而我们甚至还没看到基于这款芯片训练的首个预训练模型。开放人工智能的报告中提到,GPT-5.2 是首个基于 H100、H200 和 GP200 芯片训练的模型,这在我看来,意味着它的预训练其实是在老旧的算力集群上完成的,只是在新的 GP200 芯片上进行了一些微调。

主持人:你提到,不仅硬件的利用率不足,模型本身也是硬件发展的滞后指标,对吧?

丹・傅:没错。我们当下能使用、能体验到的模型,都是在一两年前搭建的算力集群上完成预训练的。

因为搭建一个算力集群需要时间,完成大规模的预训练需要时间,后续的微调、人类反馈强化学习等后训练环节也需要时间。所以我们当下所看到的、用来衡量模型质量的这些模型,其实都是在一年半前的硬件上训练的。而在这之后,我们已经搭建了规模大得多的算力集群,不难想象,这些集群会被用于训练新一代模型。

也就是说,我们当下所依赖的优质模型,训练所使用的硬件其实已经相当老旧,而我们拥有了新一代的硬件、更多的软件优化方案,更不用说架构层面的创新了。

蒂姆刚才提到,处理数据的核心是先转移、再计算,而变形金刚架构其实一直在发展,只是在研究者看来,发展速度稍慢。但我们能看到,计算的核心方式已经在发生变化,哪怕再找到 1.5 倍或 2 倍的优化空间,整体的可用算力就能达到 100 甚至 150 倍。所以当下还有大量的算力潜力可以挖掘,用来训练更优质的模型。

  预训练是综合训练,后训练是专项训练

主持人:我理解这场讨论的核心是预训练,也就是我们能否用更多的数据和算力训练出更大的模型。但在本播客之前的对话中,很多人都强调后训练的重要性,以及构建结合预训练和强化学习的人工智能系统的意义。这一点在当下的讨论中该如何定位?

丹・傅:这是个非常好的问题,我和蒂姆的博文其实都没有重点探讨这一点。我喜欢这样比喻,预训练就像是在健身房进行的综合力量训练,通过大重量训练提升整体的力量和能力;而后训练就像是针对特定项目的专项训练,让你在具体任务上表现更出色。

从算力消耗来看,历史上预训练消耗的算力占绝对主导,其目的是打造具备通用能力的模型,让模型掌握大量知识,能完成多种任务,甚至拥有比普通人更多的知识储备,比如我自己的知识量肯定比不上聊天生成预训练转换器。

而后训练的作用,一方面是让模型变得更实用,比如聊天生成预训练转换器,能理解用户的需求,并尽力完成任务;另一方面,我们也发现,后训练正越来越多地被用于培养模型的特定技能。比如擅长辅助编程的模型,虽然依托于预训练积累的大量知识,但正是通过后训练,才让它在编程领域具备了出色的能力;同理,擅长法律工作的模型,也是在预训练的基础上,通过后训练实现了专业领域的优化。

从纯计算的角度来看,预训练的算力消耗通常远大于后训练。 后训练的工作,我虽然不是这方面的专家,但感觉更多地像是如何打造一款实用的产品,如何获取用户反馈,诸如此类。

当然,也有一种可能是,下一代预训练模型的基础能力已经足够强大,只要针对经济领域的各个垂直赛道进行后训练,就能打造出极具实用性的模型。所以这也是计算领域的另一个重要维度,或许我们根本不需要那 100 倍的额外算力,更多的是需要像培养人类一样,深入理解问题,找到合适的训练方法 —— 就像你如何培养一名实习生完成特定任务,如何让一个能力强大的预训练模型发挥出实际价值,这正是后训练要解决的问题。

主持人:二位都提到了 “实用性” 这个概念,这或许是你们观点的交汇点。通用人工智能的定义众说纷纭,但最终的关键还是看它在产业中的实际实用性。所以即便由于收益递减,我们无法实现那个大家都无法准确定义的、理想化的通用人工智能,也无关紧要,因为我们还有巨大的潜力可以挖掘,足以让人工智能在整个经济领域发挥真正的价值,而不仅限于编程领域。

蒂姆・德特默斯:没错。我那篇博文的核心结论正是如此,我们不必过分纠结于通用人工智能的定义,更应该思考如何让人工智能发挥最大的实用价值,而这不仅关乎模型本身,丹刚才提到后训练是产品化的过程,这一点很重要。计算机的发展历程告诉我们,技术在经济中的普及需要一种截然不同的思维模式。

美国的思维模式往往是 “打造出最优的模型,自然会有人使用”,而中国的思维模式则更注重务实,思考如何让技术惠及更多人。我认为这种务实的思维模式至关重要。谈及实用性,一方面是模型的能力,另一方面就是这种发展思维。

我相信我和丹,以及大多数人都会认同一个观点:如果一个人工智能能完成数学奥林匹克竞赛这类高难度任务,却无法解决任何实际问题,那它算不上通用人工智能。而当下的模型已经具备了实用性,所以不会出现那种 “有能力却无用处” 的情况。

我们真正追求的,是实用性极强的模型,而这样的模型我们已经拥有,并且还能不断优化。我认为按照某些定义,我们或许无法实现通用人工智能,但人工智能必将产生巨大的社会影响。

丹・傅:我想补充一点,蒂姆你提到了经济领域的物理性工作和知识性工作的划分,美中两国在这方面的差异非常有意思。

最近有一本丹・王写的书很火,探讨了制造型经济、工程型经济与偏法务型经济的区别。美国有大量优秀的知识性工作有待人工智能去赋能,而从经济的实际产业结构来看,医疗、教育占了很大比重,科技领域虽然也是重要组成部分,引领着股市的走向,但还有更多领域等待挖掘。

现在有很多优秀的研究者正在尝试用新一代模型研发新药、推动医疗领域的实际变革;如果机器人技术能实现突破,助力完成一些体力劳动 —— 未必是建造房屋这类重活,而是日常的家务劳动,那将挖掘出经济领域的巨大潜力。这些方向的发展已经能看到初步的成果,自动驾驶的发展历程对我很有启发。

在我读博初期,大概 2018、2019 年,我对自动驾驶持非常怀疑的态度,当时大家总说自动驾驶 “再有一两年就能实现”,专家则说 “五年内有望落地”。但去年我乘坐了威莫的自动驾驶车辆,如今在加州湾区,我甚至能使用威莫的高速自动驾驶服务。理论上,我现在甚至可以卖掉自己的车 —— 当然我不会这么做,因为我个人喜欢开车。

但技术的进步就是这样,在这之前一直毫无起色,突然有一天就实现了突破,你会发现它不仅表现出色,甚至比优步、出租车这类人工服务还要好。如果人工智能在家庭清洁、洗碗这类家务劳动上也实现这样的突破,那将是非常令人振奋的,也会彻底改变人们的看法。我自己并非机器人领域的研究者,但一直密切关注着这个领域的发展。

多硬件、多芯片的未来方向

主持人:丹,借着这个话题,我想问问,从你的观察来看,人工智能领域是否会朝着多硬件、多芯片的方向发展?显然英伟达的发展势头迅猛,还有赛博拉斯等公司,以及众多从底层技术切入的专用集成电路企业。从你深耕底层技术的视角,你怎么看这一趋势?

丹・傅:这是个很棒的问题,我在实验室的工作中会花大量时间思考这个问题,产业界的工作中也会密切关注。当下正处于一个非常令人振奋的阶段:英伟达的芯片性能强劲、稳定性高,围绕其构建的软件生态也非常完善;而 AMD 的芯片也开始展现出同样的潜力,相关的研究也在推进。

比如在实验室,我的好友西姆龙・奥罗拉主导开发了一个名为希普基滕斯的库,核心就是探索如何设计合适的软件抽象层,实现 AMD GPU 的编程。研究发现,AMD GPU 和英伟达 GPU 的软件抽象层存在明显差异,即便这两款 GPU 的参数规格相对接近 —— 更不用说和格罗克、赛博拉斯、萨博诺瓦等公司的芯片相比了,它们的编程方式也截然不同。

现在越来越多的人开始关注这一领域,投入时间和精力进行研究。英伟达收购了格罗克,当下张量处理单元也备受关注,赛博拉斯和开放人工智能也刚宣布达成合作。所以未来必然会涌现出更多的硬件方案,英伟达无疑会继续保持良好的发展态势,甚至在本期节目录制时,其市值已经突破 5 万亿美元,但硬件领域的多样性会大幅提升,尤其是在模型推理层面。

训练和推理是两种截然不同的计算过程,因此需要的芯片也大相径庭。在推理层面,模型可能需要在手机、笔记本电脑等本地设备上运行。 我的手机是一款几年前的苹果手机,但其运算能力已经超过了我读博初期使用的一些 GPU,硬件算力的增长速度令人惊叹。

2025 年 6 月是 Agent 的拐点

主持人:丹,你刚才提到自动驾驶实现突破的那个节点,Agent 的发展是否也已经到了这样的时刻?你还提到过 “软件奇点”,我们当下是否正处于 Agent 发展的关键突破点?

丹・傅:我认为是的。就我个人的经历而言,这个突破点出现在 2025 年 6 月左右。

给大家做个背景介绍,我在合聚人工智能的日常工作就是编写这些 GPU 内核,在机器学习领域,GPU 内核的编程被认为是最难掌握的技能之一,它需要高度的并行化设计,使用的是 C++ 这种资深工程师使用了数十年的老牌语言,而非 Python 这类易用的语言。招聘能编写 GPU 内核的工程师难度极大,这是一项极具挑战性的技能,无疑是编程能力的顶尖体现。

而 2025 年 6 月,我们有了一个非常有趣的发现:云代码、库尔索 Agent 这类代码 Agent,在编写 GPU 内核方面的表现非常出色。那一周,我完成了三四个原本各自需要一周时间才能完成的功能开发,全部工作一天就搞定了。 当时我就意识到,这个工具让我这个内核领域的专家,工作效率提升了 5 倍。

我让团队都开始使用这个工具,现在团队借助它搭建了许多复杂的系统,能快速完成原本需要整个团队耗时数月才能实现的功能开发。而 GPU 内核编程,正是编程领域最难的 “终极挑战”,所以在我们看来,代码 Agent,尤其是在高难度的 GPU 内核编程领域,已经实现了关键性的突破

几个月前,我在斯拉什大会上做了一场演讲,提出了 “软件奇点” 的概念,核心就是意识到在软件工程领域,即便是这类非常小众的高难度技能,人工智能的表现也已经超越了普通程序员,甚至能为资深程序员带来效率的大幅提升。就本期节目录制的当下而言,让 Agent 独立完成开发,可能还无法产出完美的结果,但如果资深程序员借助这些工具,工作效率能提升 10 倍,这是一个非常令人振奋的发展阶段。

要么善用 Agent,要么被时代淘汰。

主持人:聊到 Agent,蒂姆,你最近还发表了一篇精彩的博文,标题是 《要么善用 Agent,要么被时代淘汰》,其中探讨了代码 Agent 和适用于其他各类任务的 Agent。从代码 Agent 的出色表现,到 Agent 在日常生活各领域发挥实用价值,这一发展进程当下处于什么阶段?

蒂姆・德特默斯:我写这篇博文,也是因为发现使用代码 Agent 能为各类任务带来巨大的生产效率提升。作为一名教授,我平时的编程工作并不多,但借助代码 Agent,编程变得前所未有的轻松,这在以往是难以想象的。

当然,Agent 在非编程任务上的表现也同样出色。从我自身的体验来看,生产效率的提升幅度不一,有时是两三倍,有时甚至能达到 10 倍,而且工作质量没有下降,甚至有时还能提升。Agent 的能力或许未必比我强,但它不会疲惫,不会犯低级错误,也不会在整合复杂信息时出现认知上的困难 —— 这和丹刚才提到的 GPU 内核编程的情况是一样的。

我认为马特你将其分为代码 Agent 和通用 Agent,但在我看来,代码 Agent 本身就是通用 Agent。代码 Agent 能编写程序解决各类问题,而代码的通用性极强,任何数字化的问题都能通过代码解决。代码 Agent 让解决问题的过程变得无比轻松,让我们能以以往无法想象的方式和速度解决各类问题,实现多任务并行处理。Agent 不会疲惫,可以持续工作,让工作变得轻松很多。

我的博文中有一个观点我自己很认同,开篇我先区分了炒作和现实,而后基于自己在直播中测试 Agent 的实际体验得出结论 :超过 90% 的代码和文本都应该由 Agent 来生成,不这么做,就会被时代淘汰。 我想对于很多工程师来说,这一点已经成为现实。

有些人认为,Agent 生成的代码和文本质量一定低下,但关键在于,你需要对 Agent 的输出进行检查和编辑。你所做的这 10% 的工作,能带来巨大的改变。通过这种对输出内容的检查、编辑和优化,让成果成为属于自己的作品。

人工智能生成的内容,并不比你自己写的内容缺乏个性。比如我借助 Agent 撰写科研基金申请,成品会让我觉得充满生命力,能感受到其中的吸引力,相信评审人看到后会觉得 “这是一项优秀的研究,值得资助”。现实就是如此,如果你只是让 Agent 生成内容,不做任何检查就直接使用,那肯定无法达到预期效果;但如果你能快速审核内容、调整优化,发现不妥之处并进行修改,最终就能得到优质的成果,这会成为未来的常态。

而适应这种工作方式所需的技能,大多数人还未完全掌握,我自己也在学习中,目前仍处于探索阶段。 模型在更新,框架在迭代,我们需要不断适应、持续学习,虽然要学的东西很多,但一旦掌握,带来的回报是巨大的。

曾经有人认为软件工程师会因此消失,但现在大家都不再这么想了。Agent 极大地提升了生产效率,而掌握使用 Agent 的能力,正是当下最需要学习的技能。善用 Agent,能让你完成更多工作,这是核心所在。如果不懂得如何有效使用 Agent,你就会被淘汰,这将成为一项必备的核心技能。

主持人:聊到 Agent,蒂姆,你最近还发表了一篇精彩的博文,标题是 《要么善用 Agent,要么被时代淘汰》,其中探讨了代码 Agent 和适用于其他各类任务的 Agent。从代码 Agent 的出色表现,到 Agent 在日常生活各领域发挥实用价值,这一发展进程当下处于什么阶段?

蒂姆・德特默斯我认为最关键的是保持务实,思考需要解决的问题,并尝试用代码实现。

当然,对于非程序员来说,编程本身就有很高的门槛,会觉得 “我从没写过代码,根本做不到”。但如果和 Agent 互动,它能直接帮你搭建程序,你只需要进行少量的学习 —— Agent 还会为你讲解相关知识,很快就能上手,实现程序的运行、网站的搭建等,还能快速获得反馈,现在做这些事情已经不再困难。

当然,我之前提到过需要检查 Agent 的输出,但如果你只是为自己搭建一些简单的工具提升工作效率,其实往往不需要这么做,Agent 生成的代码质量已经足够高。如果是在公司工作,需要将代码整合到正式的代码库中,那肯定需要进行审核;但如果只是搭建个人使用的小程序,提升自己的工作效率,那非常容易。

举个随机的例子,我会录制自己和 Agent 互动的视频,视频中会有我讲解的片段,也有我查看输出、思考分析的片段。我借助 Agent 搭建了一个工具,它能识别语音,记录我说话的时间戳,然后对视频进行剪辑,只保留我讲解的部分,去掉无意义的片段。这个工具我只用了 20 分钟就搭建好了,我相信所有人都能做到,因为我甚至没有检查 Agent 生成的代码,直接使用后,剪辑出的视频效果非常好。

只要建立起 “提出需求 — Agent 生成 — 获得反馈” 的循环,你根本不需要自己编程,只需要学会检查输出内容,或者掌握 Python 程序、bash 脚本的基本运行方法,就能实现工作的自动化。

主持人:那该如何选择要自动化的工作呢?该从哪些角度思考生活中的自动化需求?

蒂姆・德特默斯:我在博文中也探讨过这个问题,其实可以分为 直觉层面和精细化分析层面

直觉层面很简单,就是思考哪些工作自动化后会带来便利,哪怕是一些复杂的需求,比如 “我想要一个能实现某某功能的安卓或苹果应用”,一开始你可能觉得这很难,但只要向 Agent 提出需求,它能立刻实现。你可以充分发挥想象力,打造任何自己想要的工具,那些以往没人开发、自己又迫切需要的产品,现在都能借助 Agent 实现。

这种思维方式能让你打造出实用的工具,提升生产效率,同时也能锻炼你使用 Agent 的能力。当然,有时尝试后可能会失败,这时你会明白 Agent 的局限性,以及自己还需要学习哪些知识才能解决问题。

这是直觉层面的方法,能让你快速入门,从最初的兴奋,到面对现实的冷静,再到继续尝试,最终会发现自己的生产效率在一天天提升。

而精细化分析层面的方法,来自我在德国自动化行业三年的工作经历,当时主要负责工厂的自动化改造,这是一种非常严谨的计算方法:先梳理自己的工作流程,为每个步骤计时,然后分析如果将某个步骤自动化,能带来多少收益、节省多少时间,再计算开发这个自动化工具需要投入多少时间,通过这种成本收益分析,快速判断哪些工作的自动化改造是有价值的。

我的博文中提到,邮件的自动化处理效果并不好,还有一些事情也是如此,比如创建会议日历邀请,没人喜欢做这件事,但仔细想想,人们对会议的安排有很多个性化的需求,比如某天想多安排会议,某天想把会议安排在午饭前,这些需求 Agent 无法感知。即便你向 Agent 详细说明这些需求,它生成的日历邀请也未必能符合预期,最终的效率提升其实非常有限。

通过这种精细化的分析,能让我们避开这些无意义的尝试,找到真正能通过自动化提升效率的工作。

主持人:丹,从你的角度来看,在 Agent 的应用中,哪些方法是有效的,哪些目前还不成熟但未来有望实现,又该如何管理 Agent?

丹・傅:我发现 Agent 的有效应用,主要有两个核心要点。

第一,让 Agent 发挥效用的方式,和管理团队中的初级员工、公司里的实习生非常相似。 比如,你不会对一个刚来的实习生说 “去把公司的营收提升一倍”,或许你会尝试一次,但显然不可能得到想要的结果。相反,你会给实习生安排一些简单的入门任务,让他们熟悉复杂的代码库,并告诉他们可能会遇到的问题 —— 因为你自己有过相关的经历。当你给 Agent 提供这样的背景信息,让它能接触到相关的资料,它通常就能顺利完成任务。

另外,对待新员工,你不会直接把生产环境的所有权限、数据库信息都交给他们,而是会给他们足够的工具,让他们能开展工作。对待 Agent 也是如此,有些人会担心 Agent 误删生产环境的所有数据,于是对其处处限制,每一步都进行监控,但如果用这种方式对待人类员工,他们根本不可能高效工作。这是一个很重要的点,当下的 Agent,至少可以把它当作实习生或初级员工来对待。

第二,我发现一个非常有趣的现象,尤其是从教授的教育视角,思考如何培养学生适应这个 Agent 成为工作核心的未来,那就是:一个人的专业知识越扎实,比如蒂姆在流程自动化领域的专业积累,或是我在 GPU 内核编程领域的深耕,Agent 能为其带来的能力提升就越大。

因为专业知识扎实的人,能在更高的抽象层面开展工作,知道工作的核心要点、方向,了解常见的问题和陷阱,知道哪些事情容易实现、哪些事情有难度,知道如何将复杂任务拆解为多个步骤。

之前有一段时间,大家一直在讨论 Agent 是否会取代所有软件工程师,或者取代所有初级员工,而从当下的发展来看,显然不会出现这种情况。 如果一个工具能让我的团队工作效率提升 10 倍,我不会解雇 90% 的员工,而是会让他们去完成更有价值的工作,实现 100 倍的效率提升。这是一方面。

另一方面,成为某个领域专家的路径,其实和以往并没有太大区别:你需要深入学习、深入理解相关知识,需要亲手实践、真正解决问题。在当下这个时代,聊天生成预训练转换器能教你很多东西,我自己就尝试过让它教我汽车的各类工作原理,虽然目前效果还一般,但不可否认,现在学习知识的难度比以往低了很多,哪怕是两三年前,都没有这么便捷的学习方式。

所以总结来说,对待 Agent,要像扮演管理者的角色,帮助它解决遇到的问题,不能只是把问题丢给它就撒手不管;同时,你需要不断提升自己,成为更优秀的 “管理者”,积累更多的领域知识,更深入地理解工作内容。

主持人:也就是说,成为专家、持续学习的需求并没有改变,这一点很有意思,也很有道理。但有一个问题,如果一名年轻的内核工程师第一天入职,以往的培养方式是先安排简单的任务,第二年再安排更复杂的工作,那在 Agent 时代,这种实操性的职场培训该如何开展?

丹・傅:我们在合聚人工智能也一直在思考这个问题,即便在模型和 Agent 如此强大的当下,我们仍在积极招聘人才。

我们的做法是:首先,我以教授的身份,录制了一系列关于 GPU 工作原理的课程,要求所有新员工都必须学习;然后,我会给他们布置一个从零开始的任务,比如修改快速注意力机制的内核,实现某个新功能,具体的功能可以由他们自己选择。Agent 的优势在于,能让新员工更快地参与到高价值的工作中。

对于一名初级工程师来说,第一次尝试管理他人是非常有意义的经历,因为这会让他们开始用更精准的语言思考问题。比如,软件工程师常会遇到这种情况:产品经理给出一个需求,写了长长的需求文档,但当你让别人去实现这个需求时,才会发现描述一个功能需要多么精准的表达。

而 Agent 的出现,让这一过程得以简化,初级工程师不需要真正成为管理者,依然可以作为工程师开展工作,但能以管理者的思维方式,甚至产品经理的视角来思考问题。因为和 Agent 沟通时,你必须精准地描述自己的需求。我发现,团队中那些刚从大学或硕士毕业的年轻员工,只要积极学习和使用人工智能 Agent,他们的沟通能力会比以往的工程师强很多,对知识的理解和掌握速度也会大幅提升,并且能以以往 5 到 10 年都难以想象的速度搭建工具、完成工作。

蒂姆・德特默斯:我从教育的角度补充一点,这一点其实和丹的观点形成了一定的对比,也很有意思。我一直强调 “要么善用 Agent,要么被时代淘汰”,这一点对学生也同样适用,但正如丹所说,使用 Agent 的前提是具备一定的领域知识。

我们发现,如果允许学生使用 Agent,他们的学习效率会非常高,但有时他们借助 Agent 完成的解决方案,表面上看起来没问题,实际上却漏洞百出,而学生自己却意识不到。

当下我们正面临一个困境:很难同时培养学生的领域知识和 Agent 使用能力,这两者的平衡很难把握。 我们既不想培养出对知识一知半解的学生,也希望学生能掌握 Agent 的使用方法,否则他们进入职场后将无法胜任工作。

丹提到,具备扎实知识基础的人,借助 Agent 能实现能力的飞跃,但对于刚开始学习计算机科学的学生来说,该让他们学习多少专业知识,又该让他们在多大程度上借助 Agent 完成工作,这是一个非常棘手的问题,目前还没有完美的解决方案。

如果让学生过度依赖 Agent,他们的基础知识点掌握会非常薄弱;如果让学生完全靠自己完成所有学习任务,不使用 Agent,他们又无法掌握这项核心技能,进入职场后缺乏竞争力。

或许一个解决方案是:先让学生扎实掌握基础知识,再学习使用 Agent。但学生并不会这样做,他们能轻易接触到这些人工智能工具,并且会因为其便捷性而频繁使用。

所以或许真正的解决之道,是培养学生一种全新的信息处理和知识学习的思维方式,这种能力甚至超越了批判性思维 —— 学生需要学会识别自己不知道的未知事物,也就是那些自己没有考虑到、不理解,甚至从未想过的问题。 只有具备这种能力,才能跟上 Agent 的发展步伐。因为在未来,我们很可能会面对自己无法理解的问题,而 Agent 却能理解,我们需要找到一种方式,跟上 Agent 的节奏,这无疑是一大挑战。

小模型是未来趋势

主持人:二位对 2026 年人工智能的发展有哪些具体的期待?认为哪些趋势会成为现实,哪些则不会?

蒂姆・德特默斯:我觉得自己的看法比较矛盾,一方面,我认为很多领域的发展会趋于平淡,不会有太多创新;另一方面,又会有一些意想不到的突破出现。而在前沿模型领域,我认为不会有太多惊喜。

当下一个公开的事实是,预训练数据已经耗尽,正如丹所说,我们可以通过合成数据来弥补这一缺口,代码 Agent 的训练,就是在各类环境中生成大量合成数据,并进行数据融合,我们在这方面会取得一些进展,但整体来看,机器学习领域的发展已经显现出疲态。

我认为代码 Agent 的性能不会有太大提升,主要的进步会体现在用户体验的优化上。 当下各款模型的性能已经趋于同质化,比如我使用 GLM-4.7 的配置时,一度以为自己用的是 Opus 4.5,后来才发现是不同的模型,因为它们的表现实在太相似了。

所以 前沿模型的性能发展会陷入停滞,而小模型领域则会迎来快速发展。 如果针对特定的专业数据训练小模型,其性能会非常出色,而且小模型的部署难度低,能力却不容小觑。

比如 1000 亿参数的模型,能轻松实现部署,即便是 RTX 6000 这类售价 6000 美元的入门级数据中心 GPU,也能胜任。我认为对于很多企业来说,这会是一个极具吸引力的选择,它们不再需要依赖前沿的大模型,定制化的小模型甚至能表现出更优的性能,因为其针对特定领域做了优化。

当下存在一个很大的问题,正如 Anthropic 首席执行官所指出的,市面上有很多性能强大的开源模型,但实际使用的人却很少,原因就在于 部署难度极高。一旦模型的部署需要超过 8 块 GPU,不仅需要用户进行大量的效率优化,还涉及复杂的系统工程问题,而目前还没有能实现这一功能的开源系统,需要实现推理任务的解耦、跨序列长度的拆分等技术。或许我们能为异构 GPU 设备、小模型打造这样的部署系统,届时 1000 亿参数模型的运行效率,将能媲美当下的前沿大模型。

小模型兼具效率和灵活性的优势,再加上能通过大模型的知识蒸馏实现性能提升,这些因素结合起来,将彻底改变人工智能的发展格局。

丹・傅:我也对小模型的发展充满期待,认为它们会释放出更多的能力。

我会密切关注开源模型的发展,GLM-4.7 的出现,已经让开源模型的性能开始媲美当下最优秀的前沿模型,我认为 2026 年开源模型的能力会实现又一次大的飞跃。

我也非常期待新硬件的推出,目前已经有一些关于英伟达下一代 NVIDIA Rubin GPU、AMD 400 系列显卡的消息,即便我们还未充分挖掘当下硬件的潜力,我也很想看看下一代硬件能带来怎样的性能突破。

此外,我还期待多模态领域的发展,去年视频生成模型迎来了发展的小高峰,比如 Sora 2、Gemini、Veo 等模型都表现出色,我很想看看它们后续的发展。

最后,我也期待能看到,在笔记本电脑、手机这类终端设备上,人工智能的智能水平能达到怎样的高度, 能被推进到什么程度。我想说,当下投身人工智能领域,恰逢最激动人心的时刻。

主持人:二位早些时候提到了状态空间架构(SSM),你们认为这会是人工智能的近期发展方向吗?也就是说,我们会逐渐走出 Transformer 架构的时代,向状态空间模型、世界模型等新架构发展吗?这是否是你认为值得期待且势在必行的发展趋势?

丹・傅:我认为在很多领域,新架构已经落地应用了。比如当下全球最优秀的一些音频模型,就部分基于状态空间模型打造。英伟达最近也发布了多款优秀的混合架构模型,比如神经变形金刚,就是其中的代表。

所以相关的研究已经取得了很多不错的成果,架构的进化还会继续。比如 DeepSeek 的模型压缩技术,就借鉴了状态空间模型的一些理念;MiniMax 的一款模型,则采用了线性注意力的思路。

所以未来人工智能的架构会变得更加多元,这一趋势已经显现。

而中国的实验室在这方面会有更多的探索和突破,因为中国并没有像开放人工智能那样,集产品、模型、营收于一体的巨头企业,也就没有统一的技术发展范式。所以中国的实验室会更敢于尝试,想要让自己的开源模型脱颖而出,架构创新就是一个重要的方向,当然,纯性能的提升也是一个途径。因此,未来人工智能的架构会迎来爆发式的创新。

参考链接:

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

大家逛论坛的时候,不知道是不是会访问特定的几个链接?比如某个节点或热门页面。
而这些一般不会放进书签或导航页面。

我平时的习惯是在网站的导航栏去找,有的甚至打开后,标签页一直打开着,没事去刷新一下。导致标签页开的越来越多。

为了解决这个痛点,为自己做了一个油猴脚本,可以为每个网站设置不同的分组,每个分组可以添加不同的导航链接。

我管它叫 Shortcuts,快捷导航。

主要特点

  • 按站点智能分组:不同网站/网址自动显示对应的导航组,支持正则匹配。
  • 多种项目类型
    • 固定链接https://example.com/
    • 相对链接/, /node/something(自动基于当前域名跳转)
    • 搜索变量:支持 {hostname} 获取当前网站域名,{selected||query} 获取选中文字或 URL 参数,快速实现“站内搜索”。
    • JS 脚本:支持执行简单的 JavaScript 代码片段。
  • 双重显示模式
    • 悬浮模式:鼠标移至边缘展开,移出隐藏,不占空间。
    • 侧边栏模式:固定在屏幕一侧,适合宽屏常驻显示。
  • 外观定制:支持深色/浅色模式,可自定义图标。

放几个示例展示一下。

screenshot

screenshot

screenshot

screenshot

screenshot

目前还是 BETA 阶段,感兴趣可以体验一下,给些反馈。

安装地址: https://greasyfork.org/zh-CN/scripts/558485-utags-shortcuts | https://scriptcat.org/zh-CN/script-show-page/4910

项目地址: https://github.com/utags/userscripts/tree/main/utags-shortcuts

顺便撒点金币,好久没人发“金币池”了。

19 年组的台式机,当时的主要配置:
主板: 华擎 Z390
CPU: Intel Core i9-9900KF
显卡: AMD Radeon Rx 5700XT
电源: 海盗船 750w

迫于想在本地跑大模型,最近还是换了 N 卡,选择 5070Ti 主要的考虑是需要 16G 显存,5080 性价比有点低,以及电源功率可能不够,5060Ti 虽然有 16G 版本但性能不太满意

发几个测试结果供考虑升级显卡的小伙伴参考
Time Spy: 21134


Time Spy Extreme: 10856


2077 4K 高画质 DLSS 平衡档: 186fps


stable difussion 3.5: 3it/s


对比 M3 Max 的 MacBook Pro 只有 0.25it/s

在过去的一个多月,我经历了一个完整的 Apple 售后经历,整理出来给朋友们分享一二,顺便学习一下大公司的售后体系,里面有优秀的地方,也有僵化的地方,都值得创业者去思考。

起因,是一个多月前,发现我的 iPad Pro 2022 插卡版,突然掉电很快,因为本来就是仍在床上偶尔玩一玩,用得少,之前很久都不被需要充电,但是发现突然开始放着两天就没电了,起初我觉得是 iPad 电池出问题了,本来一直都有 AC+,我就约了 Apple Store 的服务,去现场检测电池发现是 91%,25 年初我线上检测是 89%,我当时觉得就很扯淡,我就提议说返厂检测吧,于是去返厂检测了,大约几天后,Apple 返回了我的设备,说工厂检测完全符合标准。

我心里也想着可能是系统 bug 吧,我就开始使用,发现问题依然存在,而且我意外发现了异常耗电的源头(插卡导致的,不插卡 WIFI 掉电 1-2%,只要插入 SIM 卡依然保持 WIFI 就会导致 30%-40%/24 小时的掉电),我又一次的联系了 400 高级技术支持,这次按照苹果的流程是高级技术支持转争议团队处理,我花了四五天的时间,统计耗电一次的截图,在系统消耗里没有任何应用和后台,保持最新系统 26.2 ,发送了相关截图给 Apple 支持,过了 10 多天,争议团队回电说确认设备是符合出厂检测的,此后便结束了售后流程。

按照苹果的售后流程,我已经无法主张自己的售后权利(当然具备 AC+的 iPad 保修政策依然宽泛,换个理由就可以换新或者走个意外,我对曾经那些 iPhone 骗保的嗤之以鼻,所以我自己不会做那样的事情,我只是实事求是),我也对 Apple(中国大陆的售后)消耗完了耐心,我便去 12315 投诉了我的订单(诉求是退货退款),当时是官方线上商城网站购买的,于是主体就是 Apple ,这个方法还是很有效的,第二天便来了 Apple 售后的电话,来确认问题,我又一次的把之前复现的结果邮件发送了支持,经过两天,有了结果,这一次这个问题到了 Apple 工程部(终于到了懂技术来处理问题),他们希望捕获日志进一步分析问题,如果在 12315 之前,我很乐意协助解决,但是现在我的诉求是退货退款,Apple 售后认为他们不能提供这样的方案,这也是此文写下的时刻。

当然我的维权之路还会继续,下一步我当然会走到法院的阶段共同去见证到底 iPad 是否存在问题,因为这个问题很容易确认,只需要插卡和不插卡放置 24 小时就有结论,而我的诉求则只会在法院和 Apple 确认 iPad 的这样的情况是否是预期/正常。而这款 iPad 我会保留,对自己也是更多的思考,因为我自己创业也做硬件,这次经历会思考如何更好的面对用户。

最后给朋友们分享我认为对待大公司售后维权的方式,首先要保证不要情绪化,不然对自己也是巨大的消耗,Apple 的机制中有很多话术和方法就是为了降低公司体系损耗的,比如争议团队(态度极差,挑拨客户情绪),这样的消耗会导致很多人便放弃自己的权利,而避免 Apple 的损失,因为一个不在预期内的问题,在 Apple 体系里已经是错综复杂了(很多大面积的召回就是这样暴露的,所以 Apple 所有的流程都在降低公司风险),我曾经以为退货退款是我最大的包容,只是 Apple 拒绝了。

受到影响的版本为 1.1.33 和 1.1.34
如果为桌面版,1.1.34 解决了一些问题,但 web 端并未解决

今天一觉醒来,mac 端和 Linux 端的 Opencode 都报错了
我是通过 Opencode web 的方式,在浏览器里使用的
这样我可以在我的 Windows 上同时操控多个 opencode 的多个 session

(ps: 在这个页面里尽管更新到了 1.1.34 依旧会显示版本为 1.1.33)

OpenCode Desktop v1.1.33 版本界面显示空白问题 Github Issue #10136
很显然,我在 issue 里找到了很多受到该 bug 影响的人们,证明我并不是一个人

如果使用 web 端来使用 Opencode 的话,似乎只能回退到 1.1.32 或更早来解决
目前的话最新的 1.1.34 版本并未解决该问题,或许要等待下一个版本

额外的,TUI 是正常的,所以如果在使用 TUI 的话不必担心

另外,感觉 web 端使用起来比 TUI 要好呢,安利一下:p


📌 转载信息
原作者:
ufhy
转载时间:
2026/1/23 19:24:35

今天使用 https://linux.do/t/topic/1440210 佬分享的方法测试的时候,claude code 调用子代理一直返回 500 错误。

后面发现是我早上把 claude code 从 npm 安装换成了原生安装导致的。claude 官网给出的答复是:

如果搜索工具、**@file** 提及、自定义代理和自定义技能不起作用,請安裝 systemripgrep:

macOS (Homebrew)

brew install ripgrep

Windows (winget)

winget install BurntSushi.ripgrep.MSVC

Ubuntu/Debian

sudo apt install ripgrep

Alpine Linux

apk add ripgrep

Arch Linux

pacman -S ripgrep

然后在您的环境中设置 **USE_BUILTIN_RIPGREP=0**。


📌 转载信息
原作者:
hexsen
转载时间:
2026/1/23 19:24:14

[开源 / 寻求共建] 从手搓到用 AI 打造了一个 Convex + 微信小程序全栈开发模板

大家猴!今天想分享一个我最近打磨的开源项目:

这是一个微信小程序原生 + Convex 云后端的全栈项目模板,希望能给同样在寻找轻量级全栈方案的开发者一点启发。

我的填坑之路

1. 手搓

起初,这个项目是 “手搓” 出来的,使用微信云,后来到期了也不想续,就搁置了。

2. Supabase

后来了解到 Supabase,我尝试迁移到 Supabase。必须承认 Supabase 很强大,但深入使用后我发现,它的会员制对于我们这种个人开发者或小项目来说,成本控制和门槛其实有点 “坑”。具体坑点可以搜一搜

3. Convex

最后我发现了 Convex。它几乎不需要运维,且自带实时性,非常契合小程序的开发节奏。
为了完善系统最核心也最麻烦的权限管理(RBAC),我利用 AI 辅助我设计了 Schema 并生成了核心的权限校验代码。

项目简介

不仅仅是一个 Demo,它提供了一套完整的全栈基础:

  • 前端:微信小程序原生开发(毛玻璃 UI 设计,体验丝滑)。
  • 后端:Convex 云后端(TypeScript 编写,无需配置服务器)。
  • 核心功能
    • 权限管理:内置用户、角色、动态菜单管理系统。
    • 用户体系:微信 OpenID 绑定、手机号登录、注册审核流、白名单。
    • 实战模块:内置了一个完整的 “电话簿” 管理模块,作为 CRUD 开发的范例。
  • 特性:类型安全、真・零运维、极低成本。

界面预览

项目内置了登录、注册、审批、角色分配、动态菜单配置等多个完整页面。

诚实声明:代码可能有 Bug

虽然目前基础流程已经跑通,但这毕竟还是个 “初生” 项目,我不敢保证代码里没有漏洞或逻辑 Bug。

尤其是在安全防御和极致并发场景下,可能还存在不少需要打磨的地方。

诚邀加入,一起搞事!

我非常看好 Convex + 小程序 这个组合带来的小项目的开发效率提升与维护成本降低。

如果你:

  • 对这个小程序感兴趣。
  • 对代码架构有强迫症,想一起优化 RBAC 设计。
  • 或者单纯想找个好用的模板做自己的小程序。

希望你能加入进来! 欢迎提 Issue 捉虫,或者直接提 PR 贡献代码。一起把这个模板打磨得更稳、更好用!

传送门

如果你觉得这个项目对你有启发,欢迎点个 Star 支持一下!


📌 转载信息
原作者:
jingtai123
转载时间:
2026/1/23 19:21:16

诚邀社区各合作伙伴、SIG组成员及广大用户共编《OpenAtom openKylin社区全景案例集2025》,以收录OpenAtom openKylin(简称“openKylin”)社区优秀技术创新项目、行业应用场景、生态适配成果案例、用户使用案例等,为有兴趣深入了解openKylin社区的开发者、合作伙伴、用户提供参考和借鉴!

图片

01    主要征集内容基于openKylin操作系统或openKylin社区开源模式开发的:
技术创新项目项目的背景说明、功能或技术架构介绍、项目的应用场景等;行业应用场景具体的行业应用场景说明、具体实施方案或解决的痛点等;生态适配成果案例产品与openKylin操作系统适配的成果及经验等;用户使用案例用户的使用场景说明、解决了哪些用户的问题等。如果您在使用或者开发openKylin操作系统的过程中有相关内容积累,欢迎提交到社区,分享给更多有需要的人!

02    提交方式
点击此处 获取案例模板,按照案例模板的要求编写完成后,发送邮件到:contact@openkylin.top,征集截止时间为2026年1月28日。关于openKylinOpenAtom openKylin是由开放原子开源基金会孵化及运营的开源项目,由基础软硬件企业、非营利性组织、社团组织、高等院校、科研机构和个人开发者共同创立。社区以“为世界提供与人工智能技术深度融合的开源操作系统”为愿景,旨在于开源、自愿、平等、协作的基础上,共同打造全球领先的智能桌面操作系统开源根社区,推动Linux开源技术及其软硬件生态繁荣发展