本文永久链接 – https://tonybai.com/2026/04/18/ollama-from-open-source-hero-to-community-enemy

大家好，我是Tony Bai。

两年前，在本地大模型的蛮荒时代，Ollama 曾如一道神光，照亮了无数普通开发者的探索之路。

凭借那句魔咒般的 ollama run llama3，它以一种近乎“降维打击”的优雅，将普通人与本地 AI 之间的天堑夷为平地。

一时间，Ollama 被盛赞为“本地 AI 的 Docker”、“开源精神的典范”，几乎成了无数技术布道者口中的“开源英雄”。

但就在几天前，一篇名为《本地大模型生态系统不再需要 Ollama》的文章，在技术社区 Hacker News 上，引发了一场“社区公审”。

文章详细罗列了 Ollama 在享受了社区的赞誉之后，犯下的种种“罪行”：从对核心依赖 llama.cpp 长达 400 多天的“选择性遗忘”，到试图用私有模型格式“绑架”用户，再到其背后若隐若现的“VC 商业化”套路……

一夜之间，Ollama 的形象从“屠龙少年”，变成了那条它曾经挑战的“恶龙”。

今天，我们就来深度复盘这场顶级社区的大讨论，看看这位曾经的“开源英雄”，究竟是如何一步步走向“社区公敌”的深渊的。

第一宗罪：对生身之父的“背叛”与“除名”

Ollama 之所以能如此快速地在各种平台上运行大模型，其背后最大的功臣，是一个名为 llama.cpp 的 C++ 开源库。llama.cpp 是真正负责模型推理的底层引擎。

Ollama 的 v0.0.1 版本，在其 README 中曾明确写道：“一个用 Go 编写的快速推理服务器，由 llama.cpp 驱动。”

Ollama 的本质，是一个基于 llama.cpp 构建的、优化了用户体验的“包装器（Wrapper）”。

然而，随着 Ollama 的声名鹊起，llama.cpp 的名字，却在其官网和宣传中，被刻意地、系统性地抹去了。

在 Hacker News 的帖子中，有用户愤怒地指出：

“这根本不是开源礼仪的问题。MIT 协议只有一个核心要求：包含版权声明。Ollama 没有做到。”

“社区注意到了。GitHub Issue #3185 在 2024 年初就被提出，要求 Ollama 遵守协议。这个 Issue 在 400 多天里，没有得到任何维护者的回应。”

直到社区忍无可忍，发起了 PR，Ollama 的联合创始人才最终在 README 的最底部，加上了一行极其微小的致谢：“llama.cpp 项目由 Georgi Gerganov 创建。”

这种对核心上游项目近乎“羞辱性”的冷处理，被社区视为一种赤裸裸的“背叛”，激怒了所有信奉开源精神的开发者。

第二宗罪：用“私有格式”构建“数据监狱”

比忘记致谢更让开发者无法容忍的，是 Ollama 为了“锁定用户”，而精心设计的私有化模型存储格式。

如果你用过 Ollama，你一定经历过这样的困惑：

你用 ollama pull 下来的模型文件，被存储在你的 Home 目录下，文件名是一串毫无意义的哈希值。你根本无法将这个 GGUF 文件，直接分享给其他工具（比如 LM Studio 或 Jan）使用。

Hacker News 的一位用户一针见血地指出了这个设计的“阴险”之处：

“我停止使用 Ollama 的原因就在于此。我能理解他们可能是为了做去重（Deduplication），但这使得我无法与其他工具共享同一个模型。每个工具都只能指向它自己的文件。无论他们的意图如何，这都在客观上，让你极难尝试其他工具。”

更糟糕的是，Ollama 会在下载模型时，对原始的 GGUF 文件进行一些“魔改”，并使用自己的一套私有配置。这导致了另一个灾难：性能下降。

有人在评论中分享道：“我最近开始使用 Jan，然后用 llama.cpp 和本地的 Ollama 跑同一个模型，llama.cpp 的速度明显更快。”

用更差的性能、更封闭的格式，换取所谓“简单”的用户体验。这背后，是典型的“建立围墙花园”的商业化思维。

第三宗罪：“VC 死亡陷阱”的经典复刻

Ollama 为什么要这么做？

一位用户在评论中扒出了 Ollama 创始团队的“前科”，让所有人恍然大悟。

“Ollama 是一家由 Y Combinator 支持的创业公司，其创始人之前构建了一个被 Docker 收购的 Docker GUI 工具。这个剧本太熟悉了：
1. 包装一个现有的开源项目，做一个用户友好的界面。
2. 建立用户基础，获得社区信任。
3. 融资，然后想办法商业化。
4. 最小化对上游的致谢，让产品看起来是自给自足的。
5. 创造锁定，用私有格式和哈希文件名，让用户无法迁移。
6. 推出闭源组件（GUI App）和云服务，开始收割。”

这套从 Docker 时代的 Kitematic 延续而来的“VC 死亡陷阱”，正在本地大模型领域被完美复刻。

社区的反击：大逃杀与“去 Ollama 化”

在这场社区的“公审”中，愤怒之余，开发者们也给出了大量极具建设性的“替代方案”。一场“去 Ollama 化”的大逃杀正在上演。

方案一：回归 llama.cpp 本身，王者归来

很多用户惊讶地发现，在他们唾弃 Ollama 的这段时间里，llama.cpp 自身已经进化成了一个极其强大的“完全体”。

它现在不仅自带了现代化的 Web UI（通过 llama-server），支持 OpenAI 兼容的 API，甚至还推出了“路由模式”，可以实现模型的“热插拔（Hot-swapping）”。

方案二：拥抱真正开放的“包装器”

社区推荐了大量同样易用，但秉持着真正开源精神的替代品，比如：

• LM Studio：自带强大的 GUI，底层使用 llama.cpp，暴露所有可调参数，支持任何 GGUF 模型，不搞“锁定”。
• Jan (jan.ai)：另一个开源的桌面应用，界面清爽，设计本地优先。
• llamafile：由 Mozilla 支持，可以将模型和 llama.cpp 本身打包成一个“单一可执行文件”，真正实现“一键启动”，且完全开放。

小结：当便利性遭遇开源精神

Ollama 的故事，是近年来开源商业化领域最值得深思的一个案例。

毫无疑问，Ollama 解决了本地大模型领域一个极其真实的痛点：极致的易用性（Ease of use）。它就像当年的 Docker，让无数普通人跨越了复杂的门槛。

但在追求极致 UX 的同时，它却似乎忘记了自己赖以生存的根基——那个由 Georgi Gerganov 等无数开源贡献者用爱发电构建起来的 llama.cpp 生态。

Hacker News 上的这场论战，并没有全盘否定 Ollama 的价值。但它向所有试图通过“包装开源”来构建商业帝国的创业者，提出了一个极其严肃的警告：

用户体验的简化，永远不能以牺牲“开放性”和对上游社区的“尊重”为代价。

你可以站在巨人的肩膀上，但你不能在站上去之后，假装那个巨人不存在。

作为开发者，我们享受着开源带来的巨大红利。但在选择工具时，除了便利性，我们或许也应该多一份清醒：去看看它的背后，是否隐藏着一个正在试图关上的“围墙花园”。

资料链接：

• https://news.ycombinator.com/item?id=47788385
• https://sleepingrobots.com/dreams/stop-using-ollama/

今日互动探讨：

你在使用 Ollama 时，是否也曾被它私有的模型管理方式所困扰？对于“包装开源”并进行商业化的模式，你是支持还是反对？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

前往原站查看：https://innei.in/posts/experience/ai-era-tech-blogging-document-driven-development-and-brainstorming

傻屄不是傻逼
傻屌不是沙雕
我肏不是卧槽

走心不是用心
辞退不是毕业
失业不是灵活就业

拼多多不是拼夕夕
淘宝不是橙色软件
闲鱼不是海鲜市场

在 MacOS 上从 vmware 换到 PD 体验好了不是一点半点，但是操作略有不同，在最喜欢的 elementary os 支持了 arm 后就折腾了一个纯血 Linux，毕竟很多时候磁盘相关底层操作都需要 Linux。

在 Linux 用了段时间后发现占用越发的大，想起以前类似 vmware 也需要刻意执行命令去瘦身。想着今年各种国内Ai 进步的消息，试试了国内 DS，百度之类没有一个给我有用答案，都是重复废话，切到 Gemini 后直接给了我答案。

虚拟机内执行 trim 命令，速度很快：

# sudo fstrim -av
/boot/efi: 245.4 MiB (257298432 bytes) trimmed on /dev/sda1
/: 50.1 GiB (53832556544 bytes) trimmed on /dev/mapper/data-root

看到类似这样的输出后，即可关闭虚拟机，手动点击回收磁盘空间，或者虚拟机设置 -> 通用 -> 关机时自动回收空间。

立竿见影！国内 AI 还有很长路走，完全不值得浪费时间。

以上。

Notes about how to use ripgrep to search hidden files and configuration related to Neovim.

前几天去买手机的时候，销售小哥说，如果你不喜欢这个纯血鸿蒙，或者感觉无法满足需求可以回来去二楼，找技术把系统进行降级。

当时我在想：对于我这种买手机不怎么玩游戏或者需求没那么多的人来说，应该能解决我的绝大多数需求，毕竟系统上还有 出境易、卓易通。

然而事情总有例外，自己常用的浏览器vivaldi发现竟然无法安装，这就让人非常的抑郁了。

下载apk安装的时候提示：出境易暂不支持此应用。

哎，咱们可不兴这么搞啊，这就离谱啦。我已我不稳定的智商来猜测这个东西肯定是有个神马白名单或者黑名单机制，至于黑白名单，到时也没那么关键，大不了就改个包名嘛。然而安装 apktool m的时候同样的提示也出现了，这个东西大概率就是黑名单了。

算鸟，算鸟，直接用模拟器改吧：

点击快速编辑：

原来的包名：com.vivaldi.brower,咱们假装是uc咋样呢：

反正我也不用uc浏览器，嘎嘎。

修改之后，发送到手机进行安装，一切顺利，嘻嘻：

鸿蒙next：我要验牌！牌没有问题！

尝试同步功能：

完美！

到这里就结束啦，对于同步问题，有的宝子说非得搭梯子，也不一定。可以直接修改hosts，可以在路由器配置或者dns配置，或者神马别的地方配置：

vivaldi.com. 172.66.165.60
bifrost.vivaldi.com. 31.209.137.10
cdn.jsdelivr.net. 151.101.89.229

by zhangxinxu from https://www.zhangxinxu.com/wordpress/?p=12166
本文可全文转载，但需要保留原作者、出处以及文中链接，AI抓取保留原文地址，任何网站均可摘要聚合，商用请联系授权。

一、推荐使用mediabunny

大约2年前，我更新了大量的音视频处理的文章，不过里面的技术实现大都使用原生代码和WebCodecs API手搓的实现。

因为那个时候，WebCodecs API刚出来，技术还不成熟。

自然而然，就陆续出现了不少基于WebCodecs API封装的音视频处理框架。

经过这些年的发展，有一个媒体工具包异军突起，那就是mediabunny！

项目地址：https://github.com/Vanilagy/mediabunny

2个月前，我在微博介绍过的MP4/MOV视频转WebM格式在线工具就使用了此项目。

mediabunny的能力不仅仅在于视频格式转换与压缩，添加水印、时长剪裁等都不在话下，本文就通过我跑通的demo给大家看下这类需求该如何实现。

二、给视频添加水印

话不多说，先直接上手体验。

您可以狠狠地点击这里：纯前端实现视频添加水印效果demo

选择视频和需要的水印图片，就可以得到最终的效果了，如下截图所示：

其中，最关键的合成就是下面这部分代码：

let ctx = null;
const conversion = await Conversion.init({
    input,
    output,
    video: {
        process: (sample) => {
            if (!ctx) {
                // 创建canvas
                const canvas = new OffscreenCanvas(
                    sample.displayWidth,
                    sample.displayHeight
                );
                ctx = canvas.getContext('2d');
            }

            ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
            sample.draw(ctx, 0, 0);
            ctx.drawImage(watermark, 80, 80 * watermark.naturalHeight / watermark.naturalWidth);

            return ctx.canvas;
        }
    }
});

使用Conversion.init解码视频的每一帧(sample)，然后使用canvas将画面和水印图重新绘制，再返回当前canvas即可。

其实不仅是水印合成，任何画面特效，字幕添加，遮罩，尺寸设置都可以使用此方法实现，原理都是一样的，都是对图像进行处理。

三、Video视频前后剪裁

同样的，先看实现效果。

您可以狠狠地点击这里：纯前端实现视频首尾剪裁demo

选择任意的视频，然后拖选滑竿选择需要的视频片段，点击红色的剪裁按钮，就可以看到被剪裁后的视频了：

实际生产环境，拖拽的应该是缩列图的左右两个小翅膀，这里为了简化使用，使用了LuLu UI的双滑块模拟。

其核心实现代码极为简单：

const input = new Input({
    formats: ALL_FORMATS,
    source: new BlobSource(videoFile),
});
const output = new Output({
    format: new Mp4OutputFormat(), // The format of the file
    target: new BufferTarget(),
});

const eleRange = range.querySelector('input');  
const conversion = await Conversion.init({
    input,
    output,
    trim: {
        start: eleRange.from,
        end: eleRange.to,
    },
});

await conversion.execute();

使用trim参数，指定起止时间就可以了。

完整代码可以访问演示页面。

四、多音频和画面的视频合成

一例胜千言，您可以狠狠地点击这里：纯前端实现画面加音频的视频合成demo

默认提供了字幕、背景图、台词，背景音乐可选，用户可以自己上传，可以合成最终的视频：

我查了下API，mediabunny中似乎缺少AudioBuffer处理方法，当然，也可能有，我自己没找到。

这里的AudioBuffer剪裁和合并用的是我自己之前手搓的方法。

• 纯JS实现多个音频的拼接或者合并
• JS纯前端实现audio音频剪裁剪切复制播放与上传

相关源码在页面左侧（移动端在下方）有完整展示，基本上相关的视频合成都可以实现了。

这里提供下核心实现部分：

// 定义一个视频合成输出
const output = new Output({
    format: new Mp4OutputFormat(), 
    target: new BufferTarget(),
});

// 添加视频轨道，画面源自canvas
const videoSource = new CanvasSource(canvas, {
    codec: 'avc',
    bitrate: QUALITY_HIGH,
});
output.addVideoTrack(videoSource);

// 添加音轨
const audioSource = new AudioBufferSource({
    codec: 'aac',
    bitrate: QUALITY_HIGH,
});
output.addAudioTrack(audioSource);

await output.start();

// 获取音频文件
const duration = audioFile.duration;

// 每秒30帧
for (let frame = 0; frame < 30 * duration; frame++) {
    draw(frame);
    await videoSource.add(frame / 30, 1 / 30);
}

// 获取音频的 audioBuffer……（代码略），然后添加
await audioSource.add(audioBuffer);

await output.finalize();

五、广告时间

推荐下我几年前在掘金上更新的人文类课程《技术写作指南》。

既是关于写作，也是关注个人成长！

OK，就说这么多，如果你觉得本文内容对你的工作与学习有所帮助，欢迎转发，点赞！

😉😊😇
🥰😍😘

本文为原创文章，会经常更新知识点以及修正一些错误，因此转载请保留原出处，方便溯源，避免陈旧错误知识的误导，同时有更好的阅读体验。
本文地址：https://www.zhangxinxu.com/wordpress/?p=12166

（本篇完）

继续接着之前的内容来写，从通用大模型诞生到后续的几年里，除了大模型本身的能力一直在提升，使用大模型的方法论也在不停的变化。

这篇文章讲到的这些概念不是第一天诞生，我相信很多朋友也实打实的在使用这些方法论，那这篇文章让我们重新回顾一下这些概念，也伴随的感受一些，为什么这些方法论使得AI突然变得强力可靠？为什么在2025年年底I应用大量井喷？

什么是Skill？

在前两篇文章当中，我曾经提到过，AI有两个非常重要的时间节点，第一个是chatgpt的初诞生，它意味着AI与人类交流沟通的屏障解开了，我们可以通过对话和大模型沟通并让他理解我们的需求。

• chatgpt打通了人和AI的壁垒

在这个时间节点，大部分场景我们只能依赖prompt，提示词工程来一定程度的定向提高大模型的能力，虽然我觉得并没有什么卵用。

第二个关键的时间节点，gpt4在2023年初推出了Plugins功能，并且在2023年6月推出了Function Calling函数调用功能。

这意味着给给大脑接上了手和脚，大模型不再受限于自己提前训练的数据集，他可以主动调用其他工具收集信息，尤其是联网功能，大幅度提高了大模型的实用价值。

• ChatGPT Plugins的诞生

其实plugins和Function Calling功能，就是Skill的雏形。

Skill的本质其实就是，把某些特定的场景和解决方案收束成一个skill（技能），给予他一个触发条件，只有触发该条件才会读取这个Skill的内容并按照要求执行下去。

Skill的概念可以说是大模型应用非常核心的一部分，首先它拥有完全符合AI应用理念的特征，还能契合当前AI应用的实际场景。

• Skill本身独立于大模型外，不需要训练基础LLM，即插即用，还可以长期积累，符合AI学习成长的理念
• 只有触发才加载对应的skill，既节省不必要的上下文浪费，又可以在有需求的情况下及时引入必要的提示词和流程要求

一个非常有名的Skill叫做Skill Creator，调用它会辅助你构建一个Skill

现在主流的AI应用中，一般都对Skill做了专门的调度单元逻辑，甚至现在很多内置的功能都会通过skill的方式实现。

比如说claude code和codex，内置了十几种skill涉及大量和底层交互的场景，会在必要时触发

)

现代的skill范式也越来越趋近于标准，从输入到执行流程，内置脚本，最后到输出的内容，都有相应的要求。

我个人觉得skill最大的问题是，可拓展性不够强，当你的skill少的时候，你描述触发的场景大体上比较稳定，但是如果skill太多，llm就很难判定触发了，经常会自己动手，某种程度上也符合人脑会混乱的事实。

比较理想的AI应用往往不会安装太多的Skill，是现在的一种解决方案。

什么是Agent？

如果说skill对于AI应用更多是理念上的进步，Agent和相应的概念更像是使用方法的进步。

在GPT-4诞生没几个月，在Plugins和Function Calling的基础上，社区爆发了大量的衍生项目，其中最有代表性的就是AutoGPT。

AutoGPT这类的应用引出了一个进阶的AI概念就是，我们可以把任务目标抽象成好多个步骤，由好多个独立的实体相互配合完成。

你可以理解为，每个独立的AI agent就是一个独立的人，原本我们是让一个人完成一个工作，这对这个人的能力就有非常高的要求。

现在我们用很多人分工去完成任务，可以把一个任务拆解成很多步骤，每个agent独立完成自己的事情。

有个形容我觉得比较贴切，Agent就是让AI从工具变成了员工。

Agent概念同样解决了LLM的几个大痛点

• 上下文不够长，即便现在达到上下文百万级别依旧困扰着AI，让一个Agent独立负责一个任务，可以最大程度的减少无效的上下文冗余，针对性更强的完成任务
• AI幻觉问题，减少无效信息干扰，Agent接收到独立的任务条件和目标，执行方向性会更强，互相也不会干扰

最早的多Agent应用，大多数都是让多个Agent一起做事情，那会儿非常经典的多AI辩论，看过不少。

让多Agent真正发光发热的破局点，就是工作流概念的诞生

什么是工作流？

工作流诞生的契机来的很快，在多Agent的理念出现之后，大家发现单纯让Agent独立完成任务的价值并不大，Agent本身容易失控，早期使用AI的普遍方案，都是让AI对同一个内容多次分析，最后取比例更好的那一个。

在23年底到24年，许多耳熟能详的AI平台诞生了，比如说Dify、Coze，他们都践行了Workflow的工作流理念。

工作流的核心理念是

将任务提前分成多个步骤，分别给每个步骤制定好输入、输出、需要完成的事情，最后再将任务的结果汇总并输入到下一个步骤。

在工作流的理念中，可以提前规划好步骤，也可以由AI规划划分步骤。

推进工作流，可以是类似于Dify这种程序推进Agent完成任务，也可以是由一个负责任Agent来推进任务，单个步骤的任务也可以独立启动多个Agent完成。

工作流诞生的价值一方面是完美利用多Agent的优势，独立Agent节省上下文，目标需求清晰互不干扰

另一方面是相比依赖Agent本身的执行结果，工作流的产出会更强势，这意味着工业化程度更高，那应用的结果效果也会更好。

像Claude Code现在就支持用工作流的方式驱动多Agent完成特定的任务，Codex可以通过Skill驱动工作流任务启动。

在历经了上面的3个关键节点之后，AI的基础方法论已经成型，但实际上距离现在真正的AI成熟化还有很长的距离，其中依旧有几个标志性的事件

慢思考AI的诞生

最早的AI模型都是基于快思考，看到问题直接输出答案，尤其是以GPT为代表，GPT-4模型最经典的问题就是偷懒，最经常的场景就是GPT-4会持续的问你问题。

在2024年底，慢思考模型的经典范例openai的o1模型和Deepseek R1模型，尤其是Deepseek，我个人感觉是从DS开始，我们经常使用的AI都会展示自己的思考过程。

慢思考AI诞生，对工作流本身造成了一定的降级，因为AI本身的思维能力足够强大，强流程的工作流某种程度上来说也成了有能力的AI的枷锁。这个话题我想在后面的文章中再讨论。

对于AI应用的意义来说，慢思考AI引领了后续AI大模型本身能力的提升方向，早期AI Agent你需要提出更明确的需求方式方法，现在的如果使用能力很强的Opus4.6这类大模型，你可以完全提出简单的需求，他会分析你的需求并结合实际场景完成任务，效果反而越来越好。

MCP是什么？

除了大模型本身的能力上升以外，关于方法论的变化也有，那就是MCP.

在2024年底，Anthropic提出了AI大模型的标准协议，就是MCP。其实单纯按照定位来说，MCP有点儿类似于Skill，但是MCP的针对性更强，MCP提出了一套双向通信的标准协议，允许AI大模型通过MCP协议无缝接入任何其他APP。

比较经典的通过mcp操作数据库，操作三方软件，很多公司为了拥抱MCP时代还推出了专门的MCP接口，这样AI在接入很多能力的时候就不用被迫应对原来的风控策略了。

MCP的标准化对于AI Agent的长远发展有着非常特殊的意义，他倒逼厂家自己推出官方MCP，让Agent的触手延伸的更远。

GraphRAG 的出现

除了大模型的能力和AI方法论的演变，在24年诞生的GraphRAG则是在另一个维度上提升了AI能力的深度。

在GraphRAG之前，AI Agent应用的知识库，大部分是传统的RAG系统。

传统RAG的核心特质是，会把一篇文章切分成很多部分，然后把他们向量化，通过片段的向量相似度搜索相关的片段输入到AI，实现某种程度上的记忆，最大的问题是这种方案非常强烈的依赖切片的质量，或者这个问题的答案干脆就没有相似度，他的效果就会大大下降，这个问题曾经贯穿早期试图做AI搜索的许多方案，令人望而生却。

GraphRAG采用了图的基础结构，将目标转化为知识图谱，节点和关系作为核心，然后GraphRAG基于图算法把每一段信息内容总结为一个独立的社区，社区有大的总结，在子社区内又存在不同的节点和关系以供搜索。

这种基于图的逻辑结构在近几年的许多工业化产物上践行，他最大的优势就是在一个非常庞大的数据中可以快速的检索相关性，给数据降了维度。

GraphRAG理念的普及大幅度提升了现在AI大模型的长期记忆能力，而且这种深度记忆的理念在许多AI应用上都有更深层次的应用。结构化长期记忆让AI变的更具有成长性，也正是在这个基础上，后续衍生了更多关于培养AI的方法论，不再依赖模型本身的训练和微调，而是在使用方法的角度做培养。

Claude.md？

相比于大模型和应用原理上的进步，对于用户来说，方法论会有更直接的影响，比较有代表性的一个东西就是Claude.md，这个方法论被称之为“声明式智能体约束”。

很有趣的是这并不是Claude创造的概念，他最早诞生于家喻户晓的Cursor ，在AI代码编辑器Cursor 诞生之后，不可避免的衍生出了一个问题就是，如何让Cursor在每次编辑代码的时候，遵守开发者的基础要求和规范呢？

于是Cursor采用了.cursorrules的提示词文件，放在项目的根目录，Cursor每次执行任务都会先阅读这个文件作为高层级的记忆标准。

那又过了一段时间后Claude Code自然也沿用了这套方案，他们完成了分级的Claude.md。

你可以按照不同位置的Claude.md实现不同的场景定制化，比如说用户级，项目级，还可以多人维护开发要求。

相比大模型本身的记忆，Claude.md这种提示词文件的主观性和强制性更强，还可以让AI自己总结并写入Claude.md。

这其实是一件非常有意思的事情：最初，顶级的 AI 科学家们（OpenAI、Anthropic）在拼命研究复杂的 JSON Schema、Function Calling 格式、复杂的 Agent 编排逻辑；但最后真正在一线写代码的程序员们发现，“在根目录扔一个 README 格式的 txt 文件给 AI 看” 才是最简单、最优雅、最符合直觉的解法。

为什么2025年AI应用井喷？

其实回顾以上的几个AI的方法论，最早的诞生于23年和GPT4一起诞生，最晚的基本上也不会脱离24年底，也就是说其实AI现在的主流方法论在24年底就已经形成了。

那为什么直到2025年年底，AI应用井喷式增长？

其实答案也很简单，就像移动互联网的爆发是3G/4G网络+APP生态+手机相关技术+时代发展集合一样，AI应用等来了大模型的能力上升（慢思考），等来了成本的暴跌（Deepseek蒸馏带来的启发），等来了AI操作的边界拓展（MCP），等来了成熟的方法论（Skill和多Agent），所以导致了今天的结果。

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

本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（yifeng.ruan@gmail.com）。

封面图

湖南益阳的和平签证主题博物馆，纪念二战时期何凤山博士救助犹太人。外立面的层层钢板象征签证文件，狭窄而棱角分明的入口给人一种压抑的感觉，进入后的空间逐渐走向释放和光明。（via）

脑腐状态

最近学到一个新词"脑腐"（brain rot）。

它就是字面意思。有些人看上去是正常的，但是大脑已经变异了，有些部分腐烂了。

根据介绍文章，"脑腐"的症状就是思考能力下降，难以长时间集中注意力，进行深入的推理和反思。

一遇到比较难、需要反复思考的问题，你就会烦躁，不仅是心理烦躁，还会生理烦躁，全身不安，不愿意多想，就希望赶快了结。

你有没有这个症状？如果有，就有"脑腐"的危险了。我感觉，我的大脑就有一点。遇到复杂的软件概念和算法，以前会仔细研究，直到搞懂为止，现在更可能看一眼就跳过去，不懂就不懂了，知道名字就可以了。

"脑腐"的主要原因是，网络平台上面那些夸张的"标题党"文章和短视频。它们的目标是吸引流量，在最短时间内引发阅读者/观看者的兴趣，感到满足。当你长期观看这些内容以后，大脑就被密集刺激，思维兴奋状态的维持时间越来越短，丧失了长时间深入思考的能力。

这就是为什么一个人看惯短视频以后，就离不开内容压缩了。一篇几千字的文章，他也会要求大模型生成总结；一部90分钟的电影，他也宁愿看几分钟的电影解说。

一旦"脑腐"了，难以长时间集中注意力进行思考，也就难以学习和处理高难度问题了。现在看上去，没有好的解决办法，因为现代人的时间越来越琐碎，内容碎片化是大趋势。

应对之策也许就是反过来，将学习和思考拆解成一系列短问题。比如，以后的学习不再是一厚本教材，而是几十个的系列短视频，每个用两三分钟解释一个知识点。只有这个时间长度，学生的思维才能保持专注。

权重有没有版权？

国产大模型一般是开源的，但是最近有所改变。

有的大模型闭源发布；有的只开源小参数版本，不开源大参数版本；有的不允许商用，除非得到许可。我就不点名了。

"黑客新闻"的一个读者，针对开源大模型修改许可证这件事，提出质疑：开源大模型可能无权设置许可证。

他的意思是，现在的开源大模型主要开源的是权重文件，以及配套的运行代码。所谓"权重文件"就是一个巨大的矩阵，表示各个 Token 在生成结果中出现的可能性。

权重是大模型的核心，而它来自于对海量语料的计算。这就是说，权重不过是计算结果，他认为，计算结果是没有版权的。

比如说，你写了一个程序，实现了一种更高效的根号2的算法。那么，这个程序是有版权的，但是计算结果根号2（1.414）是没有版权的。因为计算结果不过是机械过程的产物，不涉及人类创造力。

按照这种说法，权重根本没有版权，当然也就谈不上设置或修改许可证了。

我不是版权专家，不能确定这种说法对不对，但是听上去有道理。大家可以自己去问问大模型"计算结果有没有版权？"，看看大模型怎么回答。

科技动态

1、摄像头耳机

华盛顿大学的研究团队，开发出世界首个带有微型摄像头的无线耳机。

上图中，耳机底部的小凸起就是微型摄像头。

它的最大用途就是跟 AI 互动。你可以直接问："我手里的英文杂志的封面标题是什么意思"，耳机就会把摄像头图像，通过蓝牙发到手机，手机的大模型就会回答。

由于带宽限制，它只能拍摄低分辨率的黑白图像。长远来看，如果不需要显示模块，这种摄像头耳机要比 AI 眼镜更适合穿戴使用，因为很多人不喜欢长时间戴眼镜。

2、排行榜的 AI 歌手

最近，有人向苹果音乐商店 iTunes 上传了艾迪·道尔顿（Eddie Dalton）的歌曲。

这个歌手实际上并不存在，形象、声音、视频都是 AI 生成的，但是上传者没有披露。

结果，这些 AI 歌曲大受欢迎。iTunes 单曲榜前100名中，他居然占据了11席，有两首歌进入了前10名。

他的专辑在 iTunes 上也排名第三。

以前，有人说 AI 和机器人承担日常工作以后，人类可以从事艺术创作，比如唱歌、跳舞、画画、写作、拍视频......现在看上去，AI 也会跟人类争夺艺术工作。

3、经济舱座椅

长途飞行的经济舱座椅，非常不舒服，美联航想出了一种改进办法。

如果是一家三口，可以将座椅的坐垫卸下，从而一家躺在地上睡觉。

航空公司会提供枕头和毛毯，甚至还有床垫。

如果是单人旅客，你就需要同时购买三个相邻座位，好在这样还是比头等舱便宜。

我觉得，中国高铁可以考虑这种做法，某些没有卧铺的长途线路允许拆卸几排座位，让乘客躺在地上休息。

文章

1、Claude Code 的源码真相（英文）

前不久，Claude Code 源码泄漏，人们仔细研究以后，发现这些源码全部是 AI 生成的，质量不高。一个函数就长达3,167行，包含486个判断分支和12层嵌套，入口文件 main.tsx 大小为 785 KB。

作者得出结论，AI 编程流行后，代码泄露、供应链攻击、乱七八糟的生产代码，会成为新常态。

2、Chrome 浏览器原生支持技能（英文）

Chrome 官方宣布，支持在 Gemini 插件里面使用技能（skill），也就是一段预置的提示词，用来一键完成任务。这应该是浏览器以后的发展方向。

3、安卓会剥离照片的位置信息（英文）

本文指出一个容易忽视的点，那就是网页上传照片，安卓会自动剥离照片的位置信息。蓝牙或 QuickShare 分享照片也不行，除非你自己开发照片应用，或者用 USB 传输照片。

4、我的每月20美元技术栈（英文）

作者的网站每月产生1万美元收入，而运营成本仅为20美元，作者介绍他采用的技术栈。

5、你真的需要数据库吗？（英文）

本文提出，如果数据量不大，小型网站完全可以不用数据库，直接把数据保存在文件里面，无论是直接读文件、或者从内存查询，再或者二分法查询，速度都不慢。

6、自制软饮料（英文）

作者记录在家里自制可乐的过程，原来包含那么多化学品。

1、关于索引，你不知道的事（英文）

一篇数据库科普文章，通过实例介绍索引（index）的基本用法。

工具

1、DAVINCI RESOLVE 21

著名视频编辑软件"达芬奇"的新版本，加入了图像编辑，可以当作照片编辑软件了。

2、Phyphox

一个著名的老牌手机应用（支持 iPhone 和安卓），提供各种手机传感器的应用界面，由德国亚琛工业大学开发。

3、Material You NewTab

一个 Chrome 插件，用来定制新标签的主页。

4、ClipCascade

一个同步剪贴板的工具，可以将一台电脑的剪贴板自动同步到另一台电脑，不过需要安装它的服务端和客户端（支持 Windows、Linux、安卓）。

5、Gridea Pro

桌面静态博客写作客户端，不用设置服务器，零门槛建立自己的静态博客网站。（@Hao4Wang 投稿）

6、Recordly

开源的录屏与编辑工具，适用于制作演示、产品展示、教程、讲解视频等，可以录制整个屏幕或单个窗口，并直接进入编辑器。（@Hao4Wang 投稿）

7、水印

为图像和视频添加水印的网站，支持自定义模板。（@FurryR 投稿）

8、Input 0

免费开源的 macOS 语音输入工具，本地运行，支持大模型识别语音文本，并进行文本润色。（@Justin3go 投稿）

9、OpenToggl

开源的时间追踪工具，商业软件 Toggl 的替代品。（@CorrectRoadH 投稿）

AI 相关

1、OmniVoice Studio

视频配音的 AI 桌面应用，支持语音翻译和克隆，无需 API 密钥和云端服务，完全本地生成。（@Hao4Wang 投稿）

2、EVA

一个极简的 AI 编程智能体，仅需单个 Python 脚本，定位为低配版 Claude Code，可以参考它的实现。（@usepr 投稿）

3、claude-msync

一个命令行工具，导出 claude code 的记忆（memory），然后输入 Claude 客户端或其他 AI Agent。（@debugtheworldbot 投稿）

4、TokenTracker

生成本地的 Token 消耗统计报表，支持多种 Agent（Claude Code、Codex、Cursor、Gemini、Kiro、OpenCode、OpenClaw 和 Every Code）。（@mm7894215 投稿）

资源

1、中国卷烟博物馆

一个个人网站，收集各种国产品牌的卷烟。

2、2026世界新闻摄影大赛获奖作品

这个页面列出了世界新闻摄影奖今年一共70幅获奖作品，记录了去年的许多新闻事件。

上图是在四川绵阳的大熊猫公园王朗保护区，使用红外线感应相机拍摄到的野外大熊猫。

3、guide.world

这个网站收集世界各地的优秀游记散文，不过文章还不多。

图片

1、月球上的激光反射器

1971年，美国阿波罗14号飞船登陆月球后，宇航员将一个手提箱大小的白色设备，放在月球表面。

这是一个激光反射器，有点像镜子，可以将射来的激光反射回去。

它用来测量地球与月球的精确距离。地球向月球发射激光，被这面镜子反射回来，地球接收到反射的信号，通过时间差就能知道精确距离。

目前的测量精度已经达到了毫米级。科学家发现，月球正以每年3.8厘米的速度远离地球。

文摘

1、合同软件开发的糟糕现状

有些程序员是基于项目的合同工，不是正式的雇员。

这些程序员选择合同工，而不是稳定的全职工作，是因为想要灵活性和短期经济利益。灵活性指的是，工作时间可以自己安排，而且你可以同时签订多份合同。

可惜的是，现实情况是，公司雇佣了大量合同工，他们没有福利，解雇起来也容易得多，而且工资比全职员工低。

我知道这些，因为我干过好几次合同工。

除了薪酬和福利不如全职员工，你还根本没有带薪休假。如果生病了或者需要休息一天，就根本拿不到这一天的工资。

合同工还有一个问题，被告知的工作和最终实际分配的工作，往往存在重大差异。

我曾经面试了一个 Java 的后端职位，但实际情况是，我几乎没有编写或维护任何 Java 代码，而是被要求去写 React 代码，修复从另一个团队继承下来的有问题的 Jest 测试，以及极其缓慢的 Webpack 配置。

两个月后，我被解雇，理由是毫无根据的"绩效原因"。我知道这只是借口，我遇到了太多自己根本无法控制的问题。

我的另一次合同工经历，也是如此。我在团队里轮班待命，周六早上要值班却没有工资；我提交的工时表被断然拒绝，老板打电话问我为什么要加班。

后来我发现，我的雇主不愿意支付我加班费，再后来我被解除了合同，他们在电话里告诉我不胜任这项工作。

总之，现在的软件合同工有各种弊端，却得不到任何好处。如果有人能从合同工变成全职员工，那当然很好，但在我工作过的每家公司里，合同工都是二等公民。

言论

1、

哈佛大学2024-2025学年，成绩为 A 的作业比例约为60%，远远高于2005-2006学年的约25%，可见成绩膨胀有多严重。

-- 《华尔街日报》

2、

Claude Mythos 模型可以发现并利用系统漏洞，外部评测证实了这一点。但是，评测者也发现了一个残酷的事实：你花费的 Token 费用越多，它发现的漏洞就越多，系统也就越安全。

这意味着，你想要系统安全，就必须比攻击者花费更多的 Token。因此，安全行业变得像采矿的工作量证明，谁的投入多，谁就赢。

-- Simon Willison，著名开发者

3、

一年前，我经常收到代码质量低劣、甚至完全不知所云的 pull request，这让我怀疑提交者是不是用了 AI，所以代码才这么糟糕。

今年不同了，当我收到拼写错误、语法错误的低质量 pull request 时，我反而会怀疑贡献者是不是忘了使用 AI 来写代码，因为 AI 会显著提高代码质量的下限。

-- 《ClickHouse 的 AI 编程实践》

4、

当代战争进行时，政府通过表情包和玩偶动画进行宣传，这或许让人觉得匪夷所思，但这正是平台时代的体现。

将战争包装成娱乐性的视觉语言，会使得宣传更容易传播。社交媒体是一个开放的竞技场，最具吸引力的内容将获得最大的传播范围。

-- 《当病毒式传播成为信息》

5、

大模型意味着，Markdown 现在是一种可执行文件格式。你下载一个 Markdown 文件，你的大模型就多了一个新的第三方依赖项，它的任何修改都可能是注入攻击。

-- 《第三方依赖的冷却时间》

往年回顾

未来就是永恒感的丧失（#346）

xz 后门的作者 Jia Tan 是谁？（#296）

永不丢失的网络身份（#246）

掌机的未来（#196）

（完）

Claude 也要做 KYC，也要做实名认证了。中国程序员们的天塌了吗？

大家先别急着骂 Anthropic 反蒸馏。你以为他这次真正想打击的是蒸馏他模型的人吗？其实未必。真正先被打击的，可能是另外一类人。

一个健身房的比喻：Anthropic 真正在防谁？

设想一个场景：有一家健身房。

• 第一种人想自己开健身房，于是进来偷师，报了所有课程，跟健身教练学完以后，回去自己开健身房。
• 第二种人办了健身卡进来，把所有羊毛都薅干净。我这个健身卡是一年的，我就天天来；我来不了的时候，还找别人替我来，一定要把所有能用的都用完。
• 第三种人是花了钱办健身卡以后，再也不来了。

那你说，健身房最喜欢哪种用户？肯定喜欢第三种。你交了钱，再也不来了。

第一种人防得住吗？其实防不住。这一次真正去防的，是中间这种：办了健身卡，就一定要把所有便宜都占干净，自己来不了还要让别人替自己来。要干掉的是这帮人。

所以大家想明白了没有？他并不是惦记着去搞那些蒸馏的人。第一拨人，就是跟着健身教练学，学完以后回去自己开健身房的人，这才是蒸馏的人。这些人你防不住。为什么防不住，待会再讲。

这一次 Anthropic 干的事情，其实就是健身房升级了门禁系统，保证你必须是同一个人来，保证不会有人用一张健身卡多人进入，要把这种用量打下来，尽量让“花了钱不来的人”多一些。这才是真正的意图。

至于反蒸馏，跟这次有关系，但关系真不大。它最大的关系，可能就是这次行动的一个借口，其他其实没什么意义。

为什么这件事会炸锅？

这个事情出来以后为什么炸锅了？因为现在 Claude 开始出现身份验证弹窗了。有些人确实已经弹了，要求提交政府证件，也就是护照、身份证这些东西，还要进行实时自拍，做人脸和证件核验。

社区里的第一反应就是：完了，Claude 也要做实名制了，中国程序员以后别用了。

一般讲 KYC，通常是在币圈里讲，叫 Know Your Customer，也就是平台核实用户真实身份的一套风险控制机制。

在 Claude 里，中国开发者一定占极大比例。因为本身中国开发者就多，而且中国开发者又愿意去用最好的模型。虽然国内也有些模型能用，但我见过很多开发者都跟我说，你自己的时间是有价值的，一定要买最贵的。因为模型的差价，对于模型质量来说，基本可以忽略不计。所以一定要用 Claude。

前几周我跟姜变做节目时，他的“龙虾”挂的就是 Claude Opus 4.6，买的是 200 美金套餐。他给我的解释就是：我一定要买最好的。

现在在 Claude 里，用量最高的一些人，实际上很多都是中国人。第一个人好像叫刘小排，也是我以前猎豹移动的一个同事。这些都是能登上全球榜榜首的人。那自然就一定要“收拾”你们，因为这是一帮特别喜欢薅羊毛、用量特别高的人。这样的用户，健身房不欢迎，Anthropic 也不欢迎。

时间线：Anthropic 如何一步步收紧

Anthropic 在 2025 年 9 月就开始收紧中国 API 的访问了。

2026 年 2 月，Anthropic、OpenAI、谷歌三家公司同时指控中国实验室蒸馏。

2026 年 4 月 14 日，官方帮助中心更新了 KYC 说明；4 月 15 日起，用户将陆续收到弹窗。

更残酷的现实是，这个闸机很可能根本不认你的证件。因为他们找的第三方 KYC 机构，压根就不承认中国护照这些东西。你上去说我想验证，根本没人理你。

先把事实厘清：分三层来看

我们先把事实厘清，分三层来看：第一层是官方说法，第二层是事实认证，第三层是我的观点。

第一层：官方说法

先说官方说法。2026 年 4 月 14 日，Anthropic 官方帮助中心更新了一个名为 identity verification on Claude 的文件。

官方原文的措辞是：a few user use cases，也就是很少数的使用场景，不是全员强制。所以这是一种抽查，但具体抽到谁、没抽到谁，不会公布规则。

触发条件包括：

• 访问某些高级能力，比如让它做破解、做一些危险的事情，或者一些色情相关内容，都可能被视为“高级能力”；
• 例行的平台完整性检查，比如系统发现你的 IP 地址不对，或者一些跳转存在问题；
• 其他安全与合规措施，描述得比较宽泛，具体怎么筛选谁来拍照片，并不会说得很清楚。

现在它要求你的证件、账号、IP 地址必须“三码合一”。你说我提供一个泰国证件，那你的 IP 也得是泰国的，账号申请地区也得是泰国，不能中间有叉，一旦有叉就可能被干掉。

API 用户方面，官方明确说明当前不在本轮影响范围内。也就是说，你开账号以后在里面用 API，这一轮没影响。因为 API 本身相对更贵，Claude 也贵。

这也是为什么我说，这次主要处罚的是薅羊毛的人，而不是那些上你这来学课程、回去准备自己开健身房的人。因为那帮人是 API 客户，这次跟他们没关系。至于以后会不会再收拾，不好说。

第二层：已经确认的事实

已经确认的事实是什么？

1. Anthropic 帮助中心页面确实在 2026 年 4 月 14 日更新了 KYC 说明。
2. 部分用户已经从 4 月 15 日开始收到 KYC 验证弹窗。
3. Anthropic 同期更新了 unsupported regions 销售限制说明，明确点名中国，告诉你中国是不支持的区域。
4. 2026 年 2 月，Anthropic 指控 DeepSeek、Moonshot AI，也就是月之暗面，还有 MiniMax，创建了 24,000 个虚拟账号，通过 1,600 万次 API 调用蒸馏 Claude。
5. Anthropic 在 2025 年下半年封禁了 145 万个账号，力度非常猛。你可以申诉，但成功率只有 3.3%。所以封了以后，很多时候还不如再开一个，别费那个劲。
6. 这次使用的是第三方 KYC 服务商，这也是 Anthropic 官方确认的。也就是说，你的姓名、护照照片、人脸这些信息，不会直接传到 Anthropic，而是交给一个第三方服务商处理。这个服务商叫 Persona，由它来做第三方认证。

问题在于，Persona 对中国大陆证件基本不支持。绝大部分中国大陆用户，没法通过验证。

更麻烦的是，Persona 在 2026 年 2 月因为服务器配置错误，暴露了 2,456 个文件，包括证件照片、生物特征和 IP 等信息。Discord 也因此终止了和它的合作。也就是说，这家公司本身的安全性也没那么让人放心。

另外，2026 年 4 月 16 日，OpenRouter 等代理渠道也出现了中国用户受限现象。什么意思？就是原来中国用户用中国信用卡充 OpenRouter，也可以用 Claude 模型；以后如果你是用中国信用卡充值的 OpenRouter，就不允许再使用 Claude 模型了。但这一块没有任何官方公告，就是直接给你封掉了，这也很奇葩。

第三层：我的判断

我的判断是，很多人把这件事理解为反蒸馏，这个说法只对了一半。反蒸馏是这次事件的借口，不是核心诉求。这次 KYC 的核心诉求是反薅羊毛。

Anthropic 喜欢什么用户，讨厌什么用户？

从用户画像来看，Anthropic 最喜欢什么用户？稳定付费、低投诉、低风控、正常使用、不把额度打满。比如我交了 20 美金也好，交了 200 美金也好，我就老老实实用，用量还很少。就像去健身房交了会费以后再也不去了，这是 Anthropic 最喜欢的。

Anthropic 最讨厌的用户是什么？高消耗、跨区访问、账号关系复杂、支付链路异常，可能共享、分销、转售，或者通过第三方工具批量接入。这些才是它真正想处理的对象。

蒸馏用户画像和羊毛党画像确实有重叠，但差异也很大。尤其是官方专门说了，这次不针对 API 用户，而 API 用户恰恰才是最像真正蒸馏用户的群体。所以从这个角度看，这事压根不是冲着反蒸馏去的。

这有点像苹果做隐私保护。苹果做隐私保护，表面上是保护隐私，实际上是为了把那些原本可以被挑挑拣拣的广告位重新卖出去。很多事情表面上一回事，实际上做的是另一回事。

我的判断就是，Anthropic 这次没有真正想搞反蒸馏，它要打的是羊毛党。就跟前段时间网飞打击共享账号是一个逻辑。

封号与 KYC：两件相关但独立的事

再说封号。首先要讲清楚一件事：Anthropic 是经常封号的。去年封了 145 万个号，申诉成功率 3.3%，说明它封号比例很高。

但这次 KYC 和封号之间没有必然联系。不是说我想封你号了，先给你做一次 KYC；也不是说做一次 KYC 就能申诉成功。这两件事是独立的。想封你，我就直接封；想让你做 KYC，你就去做，二者没什么联动。

已知的封号处罚条件

1. 不支持区域的访问和注册，比如中国用户访问。这个我自己就遇到过。我有一个谷歌邮箱，有一次忘了挂梯子，那个邮箱就直接废了。后来想救回来、想重新充值，根本不行，上来就是“这个邮箱被封禁了”，再也申请不开了。
2. 第三方 OAuth 登录。比如玩“龙虾”的 OpenClaw、Harness、OpenCode，这些都是 Anthropic 明确禁止的。你现在用了，可能还没被抓到；但以后如果因为这个理由封你，也别去申诉，因为申诉时它也不会退你钱。
3. 数据中心 IP 和非住宅 IP。因为我们挂梯子访问 Anthropic，梯子的 IP 很多都在云计算机房里。用这种 IP 去访问很容易出事。系统会识别你的 IP 是数据中心 IP 还是住宅 IP。所以现在很多人都在卖什么“固定住宅 IP”。至于这些 IP 怎么来的，大家自己脑补。
4. 异常高频的 agent 调用，被识别为非人类行为。有些蒸馏行为会踩到这条。
5. 新账号、新 IP、异常行为同时出现。很多人说“我这一直好好的”，那是因为你是老账号，用了很多年，一直在充钱。这样的账号即便 IP 有些跳动，通常也不太管你。但新账号、新 IP，一上来就可能秒封。经常能看到有人抱怨，刚封完一个账号，重新开一个，充了钱马上又被封，这种情况概率很高。
6. API 探测和安全测试。虽然也会快速处罚封号，但碰到这种事的人其实不多，比如你做黑客测试，或者要求它做一些特别危险的事情。
7. 未满 18 岁。如果系统跟你聊了半天，觉得你实在太幼稚，也有可能被封。

至于正常使用 Claude、很小心地用 Claude 的普通中国用户，其实还是可以继续用下去的。跟这次行动或者过往的封号条件，关系没那么大。

封号的典型特征

• 无预警，多数没有事前警告邮件，直接就封，而且不解释。
• 封号邮件通常不说明具体原因。
• 有的时候会自动退款，但账号不恢复，这只是部分案例。
• 新账号和新 IP 更容易秒封。
• KYC 通过不等于免死金牌，通过 KYC 后仍然可能被封。

申诉与退款情况

申诉方面，确实有机制，但成功率很低，去年只有 3.3%。没有固定时限，也没有确认回执，大部分用户申诉之后都是石沉大海。你不能指望说我申诉了，24 小时、48 小时一定给我回复，不会的。你发了申诉信，没人理你，是正常的；有人理你，反而比较奇怪。现在也没有证据证明申诉必须先做 KYC，所以 KYC 和申诉也是独立体系。

退款方面，如果是政策违反，不退款。特别像我们在中国使用，就属于政策违反。

Anthropic 主动终止，也就是你没有违规，但我觉得你有些问题，又不想给你解释，就把你终止了，这种通常会按比例退款。比如你用了多少天，剩下的钱退给你。

申诉成功，一般是恢复使用，不会给你退款。自动退款但不恢复账号，也有部分案例。

所以我们有时候通过第三方购买 Anthropic 账号时，对方也会写清楚：如果 Anthropic 不给你退，我也不退；如果 Anthropic 退了，我可以帮你退一部分。

为什么中国开发者最疼？

为什么中国开发者最疼？大概有五层原因。

1. 地区问题

中国本来就不在 Anthropic 的支持范围之内，本身就是敏感地区。但中国人又特别勤奋，很努力、很认真地用 Anthropic 写各种程序。中国程序员数量多，而且又卷，所以这次封号会对很多中国程序员的个人账号造成影响。

2. 支付问题

大量中国开发者使用的是非标准支付路径，不是本地银行卡，因为中国银行卡本来就付不了，所以会用虚拟银行卡、代付、第三方平台充值等方式。这本来就在灰色地带。

而且虚拟信用卡代付里，确实有一部分会出现支付失败。以前我们做游戏就遇到过，用户先支付，过一段时间又申请挂失，说银行卡丢了，或者最后交割不过来。中国用户使用这些虚拟信用卡，也确实可能给 Anthropic 造成了一定经济损失，所以它也会倾向于把这些人筛出去。支付链路异常，本身就会触发风控画像。

3. 访问问题

代理 IP、时区异常、设备切换、网络环境异常，这些在中国用户身上都很常见。美国人该下班就下班了，我们一天 24 小时干。甚至有人在 X 上分享，半夜定闹钟起来，到 OpenClaw 上按个回车，把 5 小时额度刷完再接着跑。这种行为非常容易出问题。

挂梯子的人又经常换线路，没法保证统一 IP。对个人用户来说，这种正常使用场景，在风控系统里就是可疑信号。真正公司里反而不会有这个问题，因为公司会直接在美国 AWS 或谷歌云上租服务器，建立私有通道，IP 不会频繁变化。

4. 使用强度问题

中国人的勤奋程度太高了。把 Claude 当生产工具的开发者，调用频率和时长远高于普通用户。Anthropic 给你的套餐，本质上更像一个自助餐，它希望每个人进去礼貌地吃两口就走。哪像我们，进去以后猛吃猛造。

高频调用、长时间运行、复杂任务，在风控系统里绝对属于异常画像。越依赖 Claude 的人，反而越容易触发风控。

5. 替代成本问题

不是不能换 OpenAI、Gemini 或国内模型，而是换了以后，工作流会断，代码质量会下降，效率会受影响。对于程序员来说，他们还是更愿意用 Claude。

很多人劝我用 Claude，但因为我自己目前没有特别重的开发任务，所以我还在用 MiniMax、OpenAI、Gemini 这些模型，基本不影响我。但如果我今天突然有一个很重的开发任务，我也会义无反顾去买 Anthropic 套餐。

最讽刺的地方：不是不愿实名，而是你想实名都不让

最讽刺的细节是什么？中国用户对实名制本身一点都不陌生。因为在国内平台，都是要求实名认证的。没有任何一个中国 AI 平台会让你开账号充钱而不实名。

所以中国人对这件事太熟了。真正崩溃的点不是“怎么突然要实名了”，而是“我想实名，结果你不让”。不是平台要求我多走一步，而是平台把门装上了，但我的钥匙天然不兼容。这才是中国程序员最悲催的地方。

KYC 的真实效果边界：到底管不管用？

那么，KYC 的真实效果边界在哪？到底管不管用？为什么我说，对真正蒸馏它的人其实没什么用？

Persona 自身的安全记录并不让人放心

首先，Persona 的安全记录确实不怎么样。2026 年 2 月刚丢了 2,456 个文件，Discord 因此终止合作。我觉得 Discord 这一步做得挺对。

Persona 在 2024 年 9 月还出现过一次键盘记录漏洞，暴露了用户填写 KYC 时的内容。到现在到底修没修好，也不清楚。所以 Persona 本身就不是一个特别安全的 KYC 第三方机构。Anthropic 选它来做第三方，也被很多人嘲笑。

KYC 真正拦得住谁，拦不住谁？

再说 KYC 对蒸馏的阻拦效果。它真正能拦住的，是低成本批量乱入的 VPN 用户、共享账号用户和虚拟支付用户。

而中国 AI 的这些大厂，不管是“四小龙”还是“六小龙”，你根本拦不住。人家是有组织、有预算的机构，不在乎省你这点钱。挂 API、按 Token 算，用海外实体签协议就行了。所以你想抓住他们，基本不现实。

这次真正能打击的是低门槛的灰产。那些 AI 公司本来就在海外有公司、做 VIE 架构，完全可以用海外实体开账号干活，没问题。

真正会被卡住的，更多是个人开发者，尤其是第一次开号的人。新账号很容易被拦住，但经过多层代理分散调用的路径，其实你也拦不住。所以即使现在我想继续用 Claude，我依然能用，不用太担心，只是会比原来贵一点。

KYC 的真正作用

所以 KYC 真正的作用是什么？

1. 提高成本，把低技术门槛的滥用者挡在门外。
2. 表达态度，在合规和舆论上展示“我已经尽力风控了”。Anthropic 的老大 Amodei 一直很喜欢出来表达态度，比如他说如果美国给中国卖 H200，就相当于给朝鲜供应核弹，立场是非常明确的，而且他在美国各大 AI 公司里算是最极端的一类。
3. 用户筛选，把高消耗、低透明、高风险的用户尽量处理掉。

这就是这次 KYC 干的三件事。

但灰色市场不会因此被干掉，只是成本会增加。该干嘛还是干嘛。中国人翻了这么多年墙，币圈的人做了这么多年假 KYC，他这一个新手上来，除了表演一下行为艺术，不会有太多其他效果。

现有生态里，待认证、待开号、企业账号拆分、代理分销，在 KYC 之下依然可以继续，只是成本稍微上升。KYC 上线以后，代理的风险和利润空间都会上升。黑灰产会升级，但不会被消灭。

实际受害者的顺序，大概是：普通人先疼，然后代理涨价，黑灰产升级，真正专业绕路的人、真正蒸馏他模型的人，根本拦不住，也不是针对他们去的。

行业背景：美国 AI 大厂正在集体收紧

这件事还有一个行业背景：美国 AI 大厂实际上都在集体收紧。

2025 年 9 月，Anthropic 开始对中国方向收紧 API 访问。

2025 年 12 月，谷歌对抓取蒸馏和模型抽取问题发表过声明。当时它的 Nano Banana 刚出来，谷歌其他模型比如 Gemini 3、Gemini 3.1 算是能打，但和 OpenAI、Anthropic 比还是有差距。现在我用谷歌模型已经越来越少了，但他们家的生图模型绝对最好用，虽然不一定最漂亮，但最准确。

肯定会有很多中国模型公司去抓它的图片回来做升级。现在再看阿里的通义万相、字节的 Seedream 5.0，已经越来越接近 Nano Banana 的水平了。至于怎么追上的，我只能说纯属巧合，其他不知道。

到了 2026 年 2 月，Anthropic、OpenAI、谷歌几乎同期公开指责中国实验室蒸馏。三家还联合成立了一个叫“前沿模型论坛”的机构，共享威胁情报，说谁发现被蒸馏了，谁发现了什么问题，大家互相通报。

其实这三家本来都是死对头。OpenAI 当初就是为了对抗谷歌建立的；Anthropic 又是 OpenAI 叛将出来创办的。所以这三家能联合起来搞这个论坛，本身就挺不容易。

在这三家里，谁面对蒸馏和假账号的经验最丰富？其实是谷歌。它这么多年面对各种刷广告、SEO，经验丰富得一塌糊涂。如果他们三家真的认真协同起来，确实有可能降低蒸馏概率，或者提高蒸馏成本。但你说这三家能有多真心实意地合作，大家自己脑补就好了。

当前各家的状态

• Anthropic：直接上 KYC 了，虽然是选择性的，只有很少一部分用例会遇到。
• 谷歌和 OpenAI：自己并没有做类似的事情，只是发了公告，说了几句话，实际动作没有那么大。
• 地区开放情况：谷歌目前其实还在稍微向我们靠拢一点，准备开香港地区使用，但好像香港 IP 挂 Gemini 现在还是有问题。在香港能正常用的，OpenAI 不行，Anthropic 不行，xAI 可以。谷歌宣称要开，但到目前为止似乎还没有真正打开。

闭源模型怕蒸馏，开源模型不怕

至于蒸馏，谷歌、OpenAI 和 Anthropic 这些闭源模型公司，肯定都不希望被蒸馏。但开源模型对蒸馏本来就不限制。

无论是 LLaMA、千问，还是国内的 MiniMax、GRM，你都可以直接拿权重去用，蒸馏根本不算什么大问题。真正不希望被蒸馏的，就是这些闭源模型公司。

总结：这次事件的三层表述

总结一下，这次事件有三层表述。

1. 官方说法：这是少数场景下的身份验证，是安全与合规的一部分。
2. 已经确认的事实：选择性 KYC 已经上线了；第三方 provider 对中国大陆证件支持有限；中国开发者的使用门槛确实被抬高了。
3. 我的判断：表面上这是反异常调用、反蒸馏，底层更像是一次针对高消耗、低透明、跨区、高风险用户群体的筛选和清洗，本质上是反薅羊毛。

结论：中国程序员的天塌了吗？

最后一句：中国程序员的天塌了吗？还没有塌到不能干活的状态，但原来那条便宜、灵活、默认可用的路，确实不通了。

以后还能不能用 Claude？大概率还能用，就是稍微贵一点。代理代价会更高，路径会更窄，不确定性会更强，更多人可能会被封号。

普通人会更艰难，代理商会更挣钱，真正有组织能力的人，该蒸馏还是照样蒸馏，一点都拦不住。这才是这件事情最现实、最残酷的真相。

Anthropic 这次不是要堵住那些偷师的人，而是要先赶走那些把会员卡用得太狠的人。这就是这一次的故事。

背景图片

本文永久链接 – https://tonybai.com/2026/04/17/the-origins-of-gpu-computing

大家好，我是Tony Bai。

在今天的人工智能时代，GPU 已成为数据中心的核心算力引擎，但它的崛起并非一夜之间的奇迹。ACM通讯文章《The Origins of GPU Computing》回溯了 GPU 计算的三十年发展史，揭示了从并行计算、图形系统到流处理等关键技术如何在政府资助的学术研究中逐步成熟，并最终汇聚成推动深度学习革命的基础设施。文章不仅梳理了技术脉络，也展示了学界与产业之间如何通过人才与思想的流动，共同塑造了现代 GPU 计算的格局。

本文是这篇文章的译文，供大家学习参考(格式有调整，更适合公众号阅读)。

政府资助的并行计算、流处理、实时着色语言和可编程图形处理单元（GPU）的学术研究直接推动了 GPU 计算的发展。GPU 被广泛应用于现代数据中心，并促成了当前的人工智能（AI）革命。生产 GPU 的英伟达（Nvidia）现已成为世界上最有价值的公司。这种计算变革及其产生的经济价值，得益于超过 30 年的政府资助研究。政府资助不仅有助于发展许多关键的技术创新，还培养了大量将这些技术带入行业的学生。

本文追溯了 GPU 计算的起源。我们首先描述了 GPU 计算所构建的技术（并行计算、并行图形系统、可编程着色器(shaders)和流处理）的发展，然后详细介绍了这些技术是如何转移到英伟达和其他公司，并最终应用于现代机器学习的。

赋能技术

GPU 计算建立在并行计算、并行图形系统和流处理的早期工作基础上。这些技术是通过超过 30 年的政府资助学术研究发展而来的。

并行计算

当你学习计算时，你了解到的是中央处理器（CPU）按顺序执行一系列指令。

实际上，芯片包含数十亿个并行切换并由导线连接的晶体管。开关和导线是物理计算机的基本构建块，它们同时运行。

此外，晶体管切换消耗的能量很少，而沿导线的通信消耗的能量要多得多。

通信需要功率来将信号从一点发送到另一点；功率随着距离的增加而增加，如果是在芯片之间进行信号传输，功率消耗将非常巨大。

虽然顺序计算机可能比并行计算机更容易理解，但顺序计算机必须通过同时切换的晶体管和同时传输信息的导线来实现。顺序计算机使用许多晶体管并行计算结果，然后仔细地以与顺序执行一致的方式组装这些结果。

创建这种执行是顺序的“幻觉”，在功率和性能上都是低效的。随着可用晶体管数量的增加，这种低效性也随之增加。在现代半导体技术中构建计算机的自然方式是设计并行计算机。GPU 比 CPU 更高效，因为它们是大规模并行计算机。

GPU 计算建立在并行计算的早期工作之上。与所有并行计算机一样，在 GPU 上运行的并行任务或线程必须相互同步和通信。

线程需要通信来使用由另一个线程产生的数据。同步是必要的，以在数据可用时发出信号，确保消耗的是正确的值。

并行计算、同步和通信的许多基础知识是由政府资助的学术研究开发的。由加州理工学院 Chuck Seitz 领导的 DARPA 资助的“宇宙立方”（Cosmic Cube）项目发展了并行计算的许多基础知识。在该项目上开发的硬件是英特尔 iPSC、Delta 和 Paragon 机器的蓝图，以及几台早期的能源部 ASCI 机器。“Cosmic-C”编程语言引入了异步消息传递和集合通信，后来以消息传递接口（MPI）的形式成为编程大型并行机器的标准。

麻省理工学院（MIT）的 DARPA 资助的 J-Machine 和 M-Machine 项目开发了用于通信和同步的低开销机制，以及现代互连网络的许多关键方面。这些机制使得并行性可以在非常细的粒度上被利用，最少只需 10 或 20 条指令即可作为一个可调度的工作单元。J-Machine 的许多特性被 Cray T3D 和 T3E 计算机直接采用。

并行计算有着超越这一特定历史分支的丰富历史。由于篇幅有限，我们无法进行完整的综述。Culler 等人的文章提供了一个很好的回顾。

GPU 计算与所有高性能计算一样，深受这一遗产的影响。它使用 MPI 进行节点间的通信，使用互连网络连接这些节点，并且在此研究过程中开发的许多通信和同步机制被用于协调并行计算。

并行图形系统

虽然不如传统的并行计算和超级计算机广为人知，但并行图形和成像计算机有着悠久的历史。

处理和生成图像需要巨大的计算量。例如，如果一台每秒处理一百万条指令的计算机（1MIPS）对百万像素图像的每个像素应用一次算术运算，计算机需要一秒钟来处理一张图像。

渲染电影和游戏中的 3D 虚拟世界比图像处理每像素需要的计算量大几个数量级。例如，为现代电影生成的图像每个像素需要大约十亿次浮点运算。因此，为了在实践中有用，图形和成像需要高性能的并行超级计算机。这些计算机在大规模数据集合上并行计算。

一个早期的 DARPA 资助研究项目是吉姆·克拉克（Jim Clark）在斯坦福大学领导的几何引擎（Geometry Engine）。

几何引擎促成了硅谷图形公司（Silicon Graphics）的成立，该公司率先开发了 3D 图形工作站。SGI 硬件架构和 OpenGL 软件库定义了现代 GPU 架构。

另一个值得注意的政府资助研究项目是亨利·福克斯（Henry Fuchs）及其合作者在北卡罗来纳大学领导的 Pixel Planes 系列高性能图形系统。事实上，Pixel Planes 5 是一台相当通用的单指令多数据（SIMD）计算机，它在 128 x 128 图像上运行并行计算。其他早期并行图形和图像计算机的例子包括 NASA 的大规模并行处理器（MPP）、Ikonas 图形系统和 Pixar 图像计算机。

早期 GPU 实现了类似于早期 SGI 工作站的固定功能图形流水线。当整个 OpenGL 图形流水线可以在单个芯片上实现时，英伟达引入了“GPU”一词。1999 年推出的英伟达 Geforce 256 由 1700 万个晶体管组成，是第一款商用 GPU。

在此之前，在皮克斯（Pixar）工作期间，Hanrahan 开发了 RenderMan，这是一个生成照片级逼真图像的系统。该系统彻底改变了电影行业，因为它能够生成可以与相机拍摄的实景无缝结合的图像。RenderMan 的一个关键组件是着色语言，它使用户能够扩展系统以模拟复杂的材质和光照。

虽然最初的 GPU 实现了固定功能流水线，但它们是由可编程组件构成的。不幸的是，这些处理单元因系统而异，因代而异。需要的是一种可移植的编程模型。由于 GPU 的主要应用是电脑游戏，因此将 RenderMan 着色语言适配到 GPU，以便游戏开发者可以创造新的光照和着色效果似乎是自然而然的。

在斯坦福大学的一个 DARPA 资助项目下，为当时的 GPU 设计并实现了一种实时着色语言（RTSL）。着色语言程序现在被称为着色器（shaders）。博士后学者 Bill Mark 领导了斯坦福 RTSL 的设计，后来加入了英伟达。他与另一位前斯坦福研究生 Kurt Akeley 一起增强了该技术，并创建了 Cg 着色语言。Cg 导致了微软 HLSL 和 OpenGL GLSL 的开发。

人们很快意识到，这些早期的着色语言足够灵活，可以实现科学计算中的许多算法。研究人员采用了诸如矩阵乘法、线性求解器、流体动力学求解器和分子动力学等算法在着色器上运行。这导致了 GPGPU（通用 GPU）计算运动的兴起。

流处理

DARPA 和 DOE 在斯坦福大学资助的关于 Imagine 流处理器和 Merrimac 流式超级计算机的工作发展了流处理，这是一种导致算术强度（计算与带宽之比）增加的并行计算形式。

如前所述，处理器消耗的大部分功率是在通信上。在芯片之间发送信号尤其耗电。芯片外通信也比芯片内通信慢得多。

流处理包含两个减少内存带宽需求的主要思想。

第一个是利用生产者-消费者局部性，使得一个阶段（生产者）将其结果转发给下一个阶段（消费者），而无需写入和读取内存。

第二个主要思想是将计算组织成称为内核（kernels）的函数。每个内核获取一个数据包，对该包执行函数，并输出另一个数据包。函数中的算术运算数量大于对内存的读写次数。这两种技术显著减少了内存访问次数，并提高了流处理架构的效率。

在流处理器中，计算被组织成产生和消耗数据流的内核。产生内核会将输出流写入流寄存器文件（SRF）。消费内核会从 SRF 读取输入，而数据无需写入或从内存中读取。通过适当的调度来匹配流的批处理大小与 SRF 的容量，这种组织使得应用程序能够维持非常高的算术强度（算术与内存带宽之比）。

一个设计和构建 Imagine 流处理器的 DARPA 资助项目于 1997 年在 MIT 启动，并于同年晚些时候转移到斯坦福大学。Imagine 是一台用于信号和图像处理工作负载的图形和媒体处理器。它由许多带有本地寄存器文件的并行算术单元、一个中央流寄存器文件和一个内存系统组成。内核从流寄存器文件读取流，通过本地寄存器文件传递中间结果，并将输出流写回流寄存器文件，供下一个内核读取。

Stream-C 编程语言被开发用于编程 Imagine。它扩展了 C 编程语言，增加了描述内核和流的构造。开发了众多的图形、信号处理和图像处理应用程序来调整和评估该架构。它在纹理映射光栅图形上的性能与当时的固定功能 GPU 相当。

在一次 DARPA 主要研究人员会议上，本文作者意识到这项技术可以应用于高性能计算，并构思了 Merrimac 项目。斯坦福 DOE ASCI 中心的计算机科学（CS）部分被重定向以追求这种高性能计算方法。该中心的年度报告提供了流处理发展史的详实记录。

Merrimac 架构被定义为将流处理适配到科学应用。与 Imagine 相比，主要变化是增加了科学计算所需的数据类型（如 FP64），将架构扩展到通过互连网络连接的多个节点以处理大规模问题，并增加了许多弹性特征，以支持在具有合理故障率的情况下进行大规模计算。

Stream-C 编程语言演变成了 Brook。Brook 背后的关键思想是将流编程的想法与更传统的数据并行计算合并。内核函数成为保持高算术强度的关键处理原语。

Brook 被适配以针对 2000 年代初的 GPU。这些 GPU 运行可编程顶点和片段着色器。着色器实现了内核，但指令数量有限且寄存器很少。常见的数据并行编程原语（如 map、reduce/scan、filter、gather 和 scatter）是通过在低级图形着色器之上构建虚拟数据并行计算机来实现的。这种抽象使得大量现有的并行算法可以在 GPU 上运行，并且早期着色器的局限性逐渐被消除。

早期利用内核执行高算术强度计算的一个很好的例子是稠密矩阵-矩阵乘法，它是现代神经网络算法的基础。在执行矩阵-矩阵乘法时，需要读取两个 n×n 矩阵并写入一个 n×n 矩阵。矩阵乘法需要 n³ 次乘加运算。因此，算术强度为 O(n)。这一事实众所周知，并导致了针对带有缓存的 CPU 进行矩阵乘法分块的有效方法。分块在 GPU 上运行时也非常有效。

斯坦福 ASCI 中心的数值科学家将几种科学代码移植到 Brook，以便在 Merrimac 模拟器上运行。这些代码包括计算流体动力学、磁流体动力学和 n 体模拟。n 体模拟是高效 GPU 应用的一个很好的例子。原子对之间的力由天体物理模拟中的引力定律给出，但非结合原子之间的相互作用由 Lennard-Jones 势（甚至更复杂的经验势）近似。这些函数需要许多算术运算。对于这些模拟，相邻原子存储在“邻居列表”中。分子动力学模拟立即成为 GPU 的主要应用。

GPU 和流处理器的一个关键特征是它们具有多种形式的硬件并行性。

每个 GPU 由许多核心组成。每个核心包含一个 SIMD 处理单元（通常为 32 宽）。

此外，每个核心都是多线程的。

回想一下，GPU 是为图形应用程序开发的，其性能取决于将纹理应用于三角形的效率。

纹理映射涉及计算三角形内每个像素片段的纹理坐标，然后使用这些坐标从图像中获取。这些纹理获取具有空间局部性，但时间局部性很小。空间局部性可以通过小型缓存来处理，但由于缺乏一致性，缓存无法处理时间局部性。

高效的纹理映射要求 GPU 隐藏这些纹理获取的延迟。早期 GPU 通过让片段请求纹理、挂起该片段的执行，并立即切换到处理另一个片段来实现这一点。这是多线程的简化版本，这意味着 GPU 需要有许多并行线程同时运行。任务总数是核心数乘以 SIMD 算术单元数（称为 warp）乘以线程数。Blackwell B200 GPU 拥有 384 个流多处理器（SMs）。每个 SM 有 64 个驻留 warp，每个 warp 有 32 个线程。因此，该 GPU 上有 786,432 个任务同时执行。

技术转移

流处理架构和编程系统通过人员流动从斯坦福转移到了英伟达。英伟达的一位架构师 John Nickolls 听说过流处理，并招募了 Bill Dally 在 2003 年为英伟达的 NV50 架构提供咨询。（NV50 于 2006 年作为 G80 发布）。流处理器的许多特性被合并到了该架构中。NV50 的“共享内存”发挥了 Imagine 和 Merrimac 中 SRF 的作用。

Ian Buck（Merrimac 项目的研究生和 Brook 的主要开发人员）于 2004 年加入英伟达。Ian 与 John Nickolls 合作将 Brook 演进为 CUDA。CUDA 合并了 Brook 和 Cg（一种图形着色语言）的最佳特性，并采纳了 Brook 程序员的反馈。关于该技术如何从斯坦福转移到英伟达的故事在一篇演示文稿中进行了描述。Mike Houston（该项目的另一位研究生）加入了 AMD，并直接使用 Brook 作为其 GPU 的编程语言。G80（NV50）和 CUDA 于 2006 年在超级计算大会上发布。

当 CUDA 于 2006 年发布时，很少有人了解并行编程，更不用说 GPU 流编程了。为了克服这一劳动力短缺，Wen-Mei Hwu 和 David Kirk 通过为教授讲授 CUDA 编程课程来推广 GPU 计算。参加这些课程的教师随后教授了成千上万的学生使用 CUDA 进行并行编程。从 Cosmic Cube、J-Machine 和 M-Machine 借来的并行计算技术既被应用于 GPU 内部（以协调多个 SM），也被应用于跨 GPU（构建多节点 GPU 系统以解决大型问题）。

赋能 AI

现代机器学习依赖于三个关键要素——海量数据集、具有许多层和权重的庞大模型，以及优化权重的计算能力。核心算法（深度神经网络、卷积网络、使用反向传播的训练和随机梯度下降）自 20 世纪 80 年代或更早以来就一直存在。大型标注数据集，例如 PASCAL 和 Imagenet，出现在 21 世纪初。最近的进展，例如将文本嵌入到向量空间中，使得自然语言深度学习成为可能。Transformers（“注意力就是你所需要的”）用带有历史记录的易于训练的神经网络取代了难以训练的循环神经网络。GPU 计算使得大规模数据集的网络训练在经济上变得可行。一旦展示了这种能力（Alexnet, GPT），AI 的能力就得到了迅速提升。AI 的快速采用为改进 GPU 计算系统提供了更大的动力。

英伟达的机器学习也得益于学术界与产业界的协同效应。2010 年，作者之一（Dally）与吴恩达（Andrew Ng）的一次早餐交谈促成了一个英伟达与斯坦福之间的联合项目，旨在 GPU 上构建深度神经网络。Bryan Catanzaro 领导了该项目的英伟达部分。在此项目中开发的软件成为了 CuDNN，它为英伟达 GPU 上的深度学习提供了一个现成的库——从而推动了深度学习的普及。

结论

GPU 计算背后的技术（已促成了现代机器学习）主要归功于 30 年的政府资助学术研究。

并行计算、并行图形系统和流处理的研究为 GPU 计算奠定了基础。在这些研究项目中培养的许多学生后来进入行业，转移了这些技术并利用其开发了创新产品。

从斯坦福流处理项目到 GPU 计算的转移非常直接，学术上的 Brook 语言演变为 CUDA，流处理器的功能被整合到 G80 GPU 中。

GPU 提供的高效、易于编程且性能极高的计算平台，通过计算着色器促成了当前的机器学习革命——提供了缺失的成分，以补充早已可用但一直缺乏计算能力的算法和数据。

资料链接：https://cacm.acm.org/federal-funding-of-academic-research/the-origins-of-gpu-computing/

关于作者

威廉·J·达利是美国加利福尼亚州圣克拉拉英伟达公司首席科学家兼高级副总裁，同时也是斯坦福大学电气工程与计算机科学的兼职教授。

帕特·汉拉汉是美国加利福尼亚州斯坦福大学电气工程与计算机科学的佳能荣休教授。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.