阅读视图

发现新文章,点击刷新页面。
🔲 ☆

GPU 计算的起源

本文永久链接 – 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. 版权所有.

🔲 ☆

AI 时代,敏捷宣言已死?听听 Martin Fowler 和 Kent Beck 怎么说

本文永久链接 – https://tonybai.com/2026/04/12/agile-manifesto-dead-in-ai-era-martin-fowler-kent-beck

大家好,我是Tony Bai。

25 年前,在美国犹他州的一间滑雪小屋里,17 位当时最顶尖的软件开发者聚集一堂,共同签署了一份将彻底改变未来二十年软件工程形态的纲领——《敏捷软件开发宣言》。

在这 17 位“上古大神”中,有两个名字,如同北极星一般,指引了一代又一代程序员的成长:一位是《重构》的作者 Martin Fowler,另一位则是“极限编程(XP)”之父、敏捷宣言的发起人 Kent Beck。

25 年后的今天,当生成式 AI 的海啸席卷全球,当“敏捷迭代”被 AI 的“瞬间生成”无情碾压时,我们不禁要问:敏捷已死吗?我们曾经信奉的那些工程哲学,还剩下什么?

就在前几天,在一个汇聚了硅谷最火热 AI 创业者的闭门活动上,这两位白发苍苍的“活化石”出人意料地并肩坐到了一起,进行了一场关于 AI 时代的世纪对话

他们没有去鼓吹 AI 带来了多高的效率,反而用一种极其深刻、甚至有些悲观的视角,对当下这场“AI 狂欢”提出了终极拷问。这场对话,值得我们每一个身处其中的技术人,暂停手中飞速生成的代码,静下心来,一字一句地读完。

历史的轮回:AI,不过是又一个“微处理器”

面对台下年轻开发者对 AI 的狂热与恐慌,Kent Beck 的开场异常平静。他把时间拉回到了自己还是个孩子的时候。

“在微处理器(Microprocessor)诞生之前,电脑是一个你根本搬不动的庞然大物。当英特尔 4004 芯片问世时,我们突然意识到,‘等等,这也是一台电脑!’ 突然之间,你能做的事情的想象空间被无限放大了。”

Kent Beck 认为,今天的 AI,在本质上与当年的微处理器、后来的面向对象、再后来的互联网浪潮并无不同。它们都是“想象力的放大器”。

他坦言自己现在正在用 AI 去做一些“极其离谱的、野心勃勃的项目”,比如用 Rust 写库级别的高质量代码。“很多都会失败,但这没关系,这就是探索的一部分。”

而 Martin Fowler 则补充了他对技术浪潮的“二阶思考”:

“你必须在‘怀疑主义’和‘好奇心’之间找到完美的平衡。我对区块链就极其怀疑。但我的怀疑主义必须是绝对的——这意味着,我必须连我自己的怀疑本身,都保持怀疑。”

他坦言,自己一开始对 Copilot 这种东西也极度不屑,觉得它生成的都是垃圾。直到他读了 Simon Willison 的博客,才意识到:要用好一个工具,你必须先学会如何用好它。这和当年很多人嘲笑“面向对象”没用,但其实只是他们自己没有用对,是同一个道理。

戳破幻觉:“敏捷”的敌人,从来不是瀑布开发

当被问及“AI 承诺的‘更快、更好、更便宜’,与 25 年前敏捷宣言的初衷是否一致”时,Kent Beck 抛出了一个极其扎心的观点:

“事实证明,企业根本不想要更快、更好、更便宜。在一个公司内部,各种激励机制的错位,导致他们会惩罚那些真正追求效率的人。”

Martin Fowler 对此深有同感。他认为,AI 与敏捷最大的不同在于,当年他们需要费尽口舌去说服企业“敏捷有多重要”,而今天,没有任何一家公司敢对 AI 的重要性视而不见。

但这恰恰是最大的陷阱。

当年的“敏捷转型”,在无数企业中最终都演变成了一场“形式主义的灾难”,催生了庞大的“敏捷工业复合体”。

而今天,同样的剧本正在 AI 身上重演。无数根本不懂技术的咨询公司,正在兜售着各种“AI 转型”的灵丹妙药。

AI 正在成为新的“蛇油(Snake Oil)”。

注:“蛇油”是19 世纪的美国民间骗局,有人贩卖一种据说能治百病的“蛇油”之类的神药。其核心特征是用夸张的疗效宣传、用故事/神秘疗法包装、同时缺乏科学依据,最后你花钱买到的往往是没用甚至有害的东西。

架构师的终极拷问:AI 正在摧毁程序员的“社交”

如果说对“蛇油”的警惕还只是宏观层面的担忧,那么 Kent Beck 接下来提出的观点,则直接刺向了每一个正在享受 AI 编码便利的开发者。

他认为,AI 正在让软件开发“重新孤岛化(Re-soloing of programming)”

“极限编程(XP)很大一部分工作,是为那些天生不善社交的程序员,创造一个安全的社交环境。在一个 XP 团队里,人们每天花几个小时进行结对编程、激烈讨论,并乐在其中。”

“但我现在看到的是什么?‘我是一个程序员,我手下有 6 个 Agent,所以我是一个小团队的管理者。’ 不,你不是。你只是在同时使用 6 个工具。

在过去,我们把程序员从一个个封闭的办公室里解放出来,让他们围坐在一起,通过“混乱、复杂、充满人味儿”的社交过程,去创造伟大的软件。

而现在,我们似乎又在主动退回那个“把程序员关进小黑屋,从门缝底下塞披萨”的时代。只不过,这次陪伴你的,是几个冰冷的 AI 机器人。

Martin Fowler 也表达了同样的担忧:

“未来的团队,到底是‘一个披萨的团队’(因为 Agent 不吃披萨),还是一个‘两个披萨的团队,但效率翻倍’?我赌后者。

他认为,“两个人类 + N 个 AI” 的结对编程模式,可能是未来的答案。因为两个人类可以更好地控制 AI 的方向,同时保留了宝贵的人类交互。

有趣的是,Kent Beck 甚至觉得现在的 AI 有点“太快了”。

“当 AI 需要 3 分钟才能返回结果时,我们正好可以利用这段时间,去讨论一下变量命名的哲学,或者下一步的架构方向。但如果它 15 秒就返回了,我们就失去了交流的时间。”

手艺人的黄昏:当 AI 剥夺了“重构的快感”

在对话的最后,当被问及“AI 时代,程序员该如何自处”时,Kent Beck 的一段独白,充满了“手艺人”的失落与悲情,足以让每一个热爱编码的资深开发者瞬间破防。

“我过去在编程中获得的一种‘强迫症’般的享受,正在消失。那种把一个文件从一坨屎山,通过无数个微小、安全的步骤,最终重构成一件艺术品的快感,再也没有了。”

“我依然可以从宏观上理解我正在做什么。但我需要把我的关注点,从享受‘雕琢程序本身’,转移到享受‘理解业务领域’上。因为在‘雕琢程序’这件事上,我们已经失去了杠杆。”

Martin Fowler 则给出了更具操作性的建议:

“一个有趣的现象是:开发者体验(Developer Experience)和智能体体验(Agent Experience)的维恩图,是一个完美的圆。对 Agent 友好的代码,对人类也友好。”

他认为,拥有良好模块化、清晰接口和完备测试的代码,AI 处理起来会更得心应手。我们过去几十年积累的那些“手艺”,并没有过时,它们只是从“指导人类”变成了“指导 AI”。

小结:在不确定的浪潮中,抓住不变的礁石

这场持续了一个多小时的对话,没有给出任何关于“如何写 Prompt”、“用哪个模型”的答案。

但这两位穿越了数个技术周期的智者,用他们的人生经验,为我们指明了在 AI 这场史无前例的巨浪中,唯一能抓住的几块礁石:

  1. 保持绝对的怀疑,包括对怀疑本身的怀疑。
  2. 学会设计最小化的实验,亲自去验证那些天花乱坠的说法。
  3. 不要放弃与人交流,那才是创造力的真正源泉。
  4. 把你的代码写得更清晰、更模块化、测试更完备。这不仅是为了你自己,更是为了你未来的 AI 同事。

最后,Kent Beck 给出了一个极其悲壮的建议:或许,我们是时候放弃享受“雕琢代码”的乐趣,而去享受“理解世界”的乐趣了。

这或许是对 AI 时代,我们这些“数字手艺人”最深刻、也最无奈的宿命注解。

资料链接:https://www.youtube.com/watch?v=CZs8J1ZD0CE


今日互动探讨:

在使用 AI 编程后,你是否也像 Kent Beck 一样,感觉失去了那种“重构屎山”的快感?在 AI 时代,你认为“结对编程”是会消亡,还是会变得更加重要?

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


还在为“复制粘贴喂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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

一天重写 JSONata,我用 400 美元干掉了公司 50 万美元的 K8s 集群

本文永久链接 – https://tonybai.com/2026/04/01/rewrote-jsonata-in-golang-with-ai

大家好,我是Tony Bai。

过去的几年,我们见证了 AI 编程工具从“玩具”到“神器”的进化。无数开发者都在分享自己效率翻倍的喜悦。

你有没有想过,用 AI 来完成一次“外科手术式”的精准重构,一天之内,就能帮你把公司每年烧掉的 50 万美元(约 360 万人民币)的服务器成本,直接砍到零?

这听起来像天方夜谭,但它真实地发生了。

就在前几天,以色列安全公司 Reco 的工程师 Nir Barak 发表了一篇极其硬核的博客。他详细复盘了自己是如何在一天之内,花费了仅仅 400 美元的 Token 费用,利用 AI 将一个用 JavaScript 编写的核心组件 JSONata,完美地重写为了纯 Go 版本,最终为公司节省了每年 50 万美元的开销,并带来了 1000 倍的性能提升。

这不仅仅是一个“AI 真牛逼”的简单故事。它背后揭示的,是一套足以改变我们未来架构选型和技术债偿还方式的“AI 驱动重构(AI-Driven Refactoring)”实用方法。

跨语言 RPC,微服务架构中最昂贵的“性能税”

要理解这次重构的意义有多么重大,首先得看看 Nir Barak 的团队曾经陷入了多深的泥潭。

他们的核心业务是一个用 Go 编写的高性能数据管道,每天处理数十亿的事件。但其中有一个环节,需要用到一个名为 JSONata 的查询语言(你可以把它想象成带 Lambda 函数的 jq)来执行动态策略。

尴尬的是,JSONata 的官方实现是 JavaScript 写的。

这就导致了一个极其痛苦的架构:他们的主业务 Go 服务,为了执行这些规则,不得不去远程调用(RPC)一个专门部署在 Kubernetes 上的庞大的 Node.js 服务集群。

这个“小小的”跨语言调用,给他们带来了三大噩梦:

  1. 恐怖的成本:为了扛住流量,这个 jsonata-js 集群常年需要维持 300 多个 Pod 副本,光是这部分,每年就要烧掉 30 万美元的计算资源。
  2. 惊人的延迟:一次最简单的字段查找,比如 email = “admin@co.com”,在 Node.js 内部执行可能只需要几纳秒。但算上序列化、跨进程网络往返的开销,一次 RPC 调用在啥也没干之前,150 微秒的延迟就先进来了。对于一个每天处理几十亿事件的系统来说,这简直是灾难。
  3. 意想不到的运维黑洞:随着业务增长,Pod 数量一度多到耗尽了 Kubernetes 集群的 IP 地址分配上限!

Nir Barak 的团队当然也尝试过各种小修小补:优化表达式、加缓存、甚至用 CGO 把 V8 引擎直接嵌进 Go 里……但这些都只是“头痛医头”,无法根治“跨语言”这颗毒瘤。

Cloudflare 的“抄作业”哲学

转机发生在前几周。Nir Barak 看到了 Cloudflare 那篇刷爆全网的文章《我们如何用 AI 在一周内重构 Next.js》。

Cloudflare 的做法极其“暴力”且有效:他们没有让 AI 去创造新东西,而是把 Next.js 现成的spec,以及包含几千个 case 的官方测试套件(Test Suite)直接扔给大模型,然后对 AI 下达了一个简单粗暴的指令:

“我不管你怎么实现,给我写一个能在 Vite 上跑通所有这些测试的 API 就行!”

Nir Barak 看到这里,瞬间被点醒了:“我们面临的问题一模一样!我们也有 jsonata-js 官方那套包含 1778 个测试用例的完整套件啊!”

与其让 AI 去搞创新,不如把它变成一个任劳任怨、24 小时待命的“代码翻译工”!

于是,他花了一个周末,用 AI 制定了一个极其清晰的“三步走”作战计划:

  1. 第一步(人类智慧):用 Go 语言把 jsonata-js 的测试套件先“翻译”过来。
  2. 第二步(AI 体力):把 JSONata 2.x 的官方文档和规范全部喂给 AI。
  3. 第三步(测试驱动):对 AI 下达指令:“开始写 Go 代码,目标是跑通第一步的所有测试用例。”

第二天,他按下了“开始键”。

7 小时,400 美元,13000 行 Go 代码

接下来的故事,充满了令人肾上腺素飙升的极客快感。

Nir Barak 坐在电脑前,看着 AI Agent 像一台失控的缝纫机一样,疯狂地生成 Go 代码、运行测试、读取报错、然后自我修正。

整个过程被划分成了几个“波次(Waves)”:先实现核心解析器,再实现内置函数,最后处理各种边缘 case。

在 AI 与测试用例的左右互搏之下,仅仅 7 个小时 后,奇迹发生了:

一个包含 13,000 多行纯 Go 代码的、名为 gnata 的全新 JSONata 实现诞生了。它完美通过了官方所有的 1778 个测试用例。

而这整个过程的成本呢?

400 美元的 Token 费用。

Nir Barak 在博客中晒出了一张截图,数据显示,在重构 gnata 的那一天,AI 生成的代码占比高达 91.7%

当他把这个 PR 提交到公司内部时,立刻有人质疑 ROI(投资回报率)。而他的回答简单粗暴:

“上个月,jsonata-js 集群的成本是 2.5 万美元。现在,是 0。”

百倍性能与意外之喜:“手术刀式”重构的深远影响

成本降为零已经足够震撼,但性能上的收益更是堪称“恐怖”。

这还只是开始。由于 gnata 是纯 Go 实现,Nir Barak 团队得以进行更深度的“魔改”:他们设计了一套两层评估架构。对于简单的字段查找,gnata 直接在原始的 JSON 字节流上操作,实现了 零堆内存分配(Zero Heap Allocations)!只有遇到复杂表达式时,才会启动完整的解析器。

在接下来的两周内,他们乘胜追击,用 gnata 的批量处理能力,替换掉了主数据管道中另一个极其臃肿、靠启动上万个 Goroutine 来并发处理规则的旧引擎。 结果:又省下了每年 20 万美元。

短短两周,两次“外科手术式”的重构,总共为公司节省了每年 50 万美元的开销。

最让人意想不到的是,这次重构还带来了组织层面的“意外之喜”:

gnata 是公司内部第一个完全由 AI Agent 大规模参与生成的 PR。在 Code Review 的过程中,团队成员被迫去学习如何分辨“AI 真正发现的并发 Bug”和“AI 瞎操心的代码格式问题”。这次经历,为他们后续制定全公司的 AI Code Review 规范积累了宝贵的实战经验。

小结:我们不再只是“氛围感编码”

在文章的结尾,Nir Barak 提到了 AI 大神 Andrej Karpathy 最近的观点,大意是:

“编程正在变得面目全非。在底层,深厚的技术专长正成为比以往任何时候都更强大的‘乘数效应放大器’。”

Nir Barak 感慨道,直到最近,他自己都对那种完全由 AI Agent 生成代码的“氛围编码(Vibe coding)”持怀疑态度。但 2026 年 2 月,成为了一个连他这样固执的开发者都无法忽视的“拐点”

gnata 的诞生,标志着我们不再只是用 AI 去写一些无关紧要的玩具项目。在拥有明确测试用例和边界规范的前提下,AI 已经具备了对生产环境核心组件进行“手术刀式重构”的惊人能力。

你准备好拿起这把名为“AI”的手术刀,去切掉你系统里那些最昂贵、最臃肿的“技术肿瘤”了吗?

资料链接:https://www.reco.ai/blog/we-rewrote-jsonata-with-ai


今日互动探讨:

在你的公司里,是否存在类似的“异构技术栈”调用导致的性能瓶颈或成本黑洞?你有没有想过,可以用 AI + 测试用例的方式,对某个核心组件进行“代码翻译”式的重构?

欢迎在评论区分享你的架构痛点与大胆构想!


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

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

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


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

🔲 ☆

谷歌一篇论文砸崩内存巨头?不懂“显存墙”,怎么做 AI 时代的工程师!

本文永久链接 – https://tonybai.com/2026/03/28/ai-engineer-gpu-introduction-course

大家好,我是Tony Bai。

就在最近,科技界发生了一件极其戏剧性的事情。本周三美股开盘,全球存储产业巨头——美光、西部数据、希捷的股价遭遇了“黑色时刻”,普遍明显下跌(3%~6%)。

引发这场资本市场大地震的,不是什么贸易战,也不是财报暴雷,而仅仅是谷歌(Google Research)发布的一篇技术论文:《TurboQuant: Redefining AI efficiency with extreme compression

这篇论文宣称,他们发明了一种极端的压缩算法,能在几乎零损耗的情况下,将大模型推理时的 KV 缓存(KV Cache)暴降 6 倍,并让注意力机制的计算速度狂飙 8 倍

很多传统的后端程序员看到这条新闻,可能一头雾水:

  • 什么是 KV Cache?
  • 为什么压缩了一个叫 KV Cache 的东西,就能让卖物理内存芯片的巨头们吓得半死?

在这些雾水和疑惑背后,隐藏着 AI 大模型时代最核心、也最残酷的技术真相:内存墙(Memory Wall)

AI 时代的底色:算力过剩,访存为王

在传统的软件开发中,我们习惯了用 CPU 的思维去思考性能。我们认为程序跑得慢,是因为“计算太复杂”,我们需要更强的算力(更快的 CPU 频率)。

但在大语言模型(LLM)的世界里,逻辑变了。

大模型在生成文本时,是逐字生成(自回归)的。为了不每次都把前面说过的话重新计算一遍,模型会把之前所有上下文的内部特征(Key 和 Value 矩阵)全部保存在显存里。这份庞大的“运行记忆”,就是 KV Cache

随着上下文越来越长(比如从 4K 飙升到 128K 甚至百万级),这份 KV Cache 会像滚雪球一样膨胀。

这就是为什么业界说:KV Cache 是大模型推理名副其实的“吞金兽”。

更要命的是,每次生成一个新的字,GPU 都必须把这份庞大的 KV Cache 从显存(HBM)完整地搬运到计算核心(SRAM)里过一遍。

这就好比你有一个世界上切菜最快的厨师(GPU 算力),但他每次切一片肉,都要跑到 10 公里外的仓库(显存)去取。厨师的手速再快也没有用,整体速度完全被运货卡车的速度(显存带宽)锁死了。

这就是困扰所有 AI 工程师的 “内存墙”。也是为什么各大公司疯狂抢购高显存、高带宽的 H100 显卡的原因。

而谷歌的 TurboQuant 之所以引发地震,正是因为它通过极致的数学算法(极坐标变换 + 1-bit 残差误差校验),直接在软件层面把搬运的数据量压缩了 6 倍!这意味着,同样的硬件,现在能跑更长的上下文、支持更高的并发。存储巨头们能不慌吗?

为什么后端工程师必须懂 GPU?

你可以说:“我只是个调 OpenAI 兼容API 的后端工程师,硬件底层关我什么事?”

在过去的一年里,这是行得通的。但随着开源模型(如 GLM、Qwen、MiniMax、DeepSeek、KIMI等)的全面爆发,以及企业对数据隐私、成本控制的极致追求,“本地化/私有化部署大模型” 也正在成为一些中大型企业的刚需。

当你作为架构师或后端主力,被老板要求把一个 70B 的大模型部署到公司的服务器上时,真正的挑战才刚刚开始:

  • 面对 OOM(显存溢出),你该如何调整参数?
  • 并发量稍微一高,首字延迟(TTFT)就卡到几十秒,你该怎么排查?
  • 采购硬件时,你是买 8 张便宜的 RTX 4090,还是花高价租用带 NVLink 的 A100/H100?
  • 你该如何向团队解释引入 vLLM、FlashAttention 和 INT8/FP8 量化的必要性?

如果你把 GPU 当成一个“跑得更快的 CPU”来用,你将会在上述每一个问题上栽大跟头。

你需要建立一套全新的“硬件心智模型”,这也是我编写这门《AI 工程师的 GPU 入门课:从硬件视角看大模型推理》微专栏的主要目标。

这门微专栏将教你什么?

市面上关于 GPU 和 CUDA 的教程很多,但大多是教你如何写出复杂的 C++ 图形渲染代码,或者如何在学术上推导矩阵乘法。

这门微专栏与众不同。它是专为后端/软件工程师打造的“白盒化” GPU 入门课程。

我们不教图形渲染,不深究复杂的 C++ 语法。我们将直接切入大模型推理的痛点,带你一步步从物理架构走到前沿的 AI 工程技术。

  • 如果你想吃透热门技术: 我们将为你讲透 FlashAttention、PagedAttention (vLLM)、模型量化背后的物理原理。你会发现,这些看似高深的技术,本质上都是在和“内存墙”做斗争。
  • 如果你追求实战落地: 我们不仅教你看懂硬件,还会教你用 Profiling 工具(性能分析器)像侦探一样排查慢查询;作为加餐,我们甚至会教你如何用纯 Go 语言(Zero CGO)直接点火发射 CUDA 内核!

课程目录全景图

为了让你对这趟旅程有一个清晰的预期,以下是本专栏的完整地图:

第一阶段:硬件心智模型
* 第 01 讲 | 硬件解剖:为什么 CPU 是“法拉利”,GPU 是“大巴车”?(含 5090 vs H100 对比)
* 第 02 讲 | 内存金字塔:HBM、SRAM 与不可逾越的“内存墙”

第二阶段:编程模型与工具链
* 第 03 讲 | CUDA 编程模型:指挥“千军万马”的线程艺术
* 第 04 讲 | 性能侦探:性能侦探:拆解 Hello World Kernel 与 Profiling 实战

第三阶段:AI 工程进阶
* 第 05 讲 | 显存管理革命:从 KV Cache 到 PagedAttention (vLLM)
* 第 06 讲 | 算子融合魔法:FlashAttention 的底层原理
* 第 07 讲 | 精度与量化:精度与量化:INT8/FP8 为什么既快又省?
* 第 08 讲 | 分布式推理:Tensor Parallelism (TP) 与通信墙
* 第 09 讲 | 终极指南:如何科学计算 AI 算力需求与硬件选型?

特别加餐:Gopher 的专属浪漫
* 第 10 讲 | 加餐:Go 语言的 GPU 编程——Gopher 的逆袭

小结

在算力的装备竞赛里,最锋利的武器未必是更昂贵的芯片,而是深刻理解软硬件边界的人。

正如谷歌 TurboQuant 证明的那样:懂底层的工程师,只需改写一行底层逻辑,就可能撬动万亿级别的市场价值。

算力时代,不要只做“调包”的局外人。

准备好跨越 CPU 的舒适区,跟我一起深入算力的硅基心脏了吗?

点击这里或扫描下方二维码,开启你的GPU与AI推理工程的入门之旅:

我将在第一讲等你。


还在为“复制粘贴喂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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

告别古法编程黄金时代:AI 时代不会再有新编程语言诞生的土壤

本文永久链接 – https://tonybai.com/2026/03/24/no-soil-for-new-programming-languages-in-ai-era

大家好,我是Tony Bai。

如果你回望过去十五年的软件工程史,那无疑是编程语言百花齐放的黄金时代。

为了对抗日益膨胀的系统复杂度,人类绞尽脑汁地发明新的“咒语”:

Google 推出了 Go 语言,用极简的 Goroutine 拯救了深陷并发地狱的后端工程师;

Mozilla 孕育了 Rust,用严苛的所有权机制向内存泄漏和数据竞争宣战;

苹果用 Swift 埋葬了晦涩的 Objective-C;

JetBrains 用 Kotlin 为笨重的 Java的使用者提供了一个更优雅的选择;

微软用 TypeScript 彻底规范了狂野的 JavaScript 生态。

每一次新语言的诞生,都伴随着开发者们的狂欢。我们热衷于讨论语法糖、对比编译速度、争论哪种范式更优雅。我们在各大论坛上为自己喜爱的语言摇旗呐喊。

但这已经是最后的余晖了。

站在 2026 年的节点上,当你看着 Claude Code、Cursor 或各类 Coding Agent 在几秒钟内倾泻出数千行逻辑严密的代码时,一个残酷的真相正在浮出水面:

大模型(LLM)的爆发,彻底抽干了孕育下一代通用编程语言的土壤。属于人类的“造语言”游戏,结束了。

这不是危言耸听,而是基于技术演进第一性原理的必然推演。

语料霸权:新语言无法跨越的“生态死局”

在 AI 时代,一门编程语言的生命力不再取决于它的语法有多么优雅,而取决于它在 AI 模型中的“语料权重”

现存的主流语言(Python, Java, JavaScript, Go, C/C++等)在 GitHub 上积累了数年甚至十余年的海量开源代码。这些代码构成了大模型训练的底座,赋予了 AI 极高的“代码智商”。

当你用 Python 或 Go 提问时,AI 能够瞬间理解你的意图,补全复杂的逻辑,甚至自动发现隐藏的 Bug,因为它的“脑子”里装着上千万个成熟的 Python/Go 示例。

但对于一门新语言来说,这是绝对的死局。

假设明天某个天才发布了一门名为 Nova 的新语言,号称性能超越 C,安全性超越 Rust,语法如 Python 般简洁。

结果会怎样?

  • AI 不会写:因为训练语料里没有 Nova 的代码,大模型对它一无所知,无法提供智能补全。
  • 人类不会用:在“没有 AI 辅助就感觉不会写代码”的今天,一个习惯了口述意图,让AI Coding Agent 自动生成全量代码的程序员,绝不可能去碰一门必须纯手工敲击、AI 无法帮他编写和Debug的语言。

这就形成了一个无解的马太效应

没人写就没有语料 -> 没有语料 AI 就不会写 -> AI 不会写人类就不想学 -> 更没人写。

现存的主流语言通过“语料霸权”,彻底锁死了新语言上升的通道。

需求降维:为什么我们不再需要“更好写”的语言?

人类发明新语言的根本动力,是“人脑的带宽有限”

C++ 太容易写出内存泄漏,人脑排查太痛苦,所以我们发明了 Rust,让编译器做“真理警察”。

Java 处理异步回调太繁琐(Callback Hell),所以我们发明了各种新的语法糖。

我们一直在努力打造更锋利、更安全的斧头,因为那是人类自己要挥舞的斧头。

但在 Agentic Coding(智能体编程)时代,挥舞斧头的不再是人,而是不知疲倦的 AI。

当你可以用自然语言对 Agent 说:“用 C++ 实现一个高并发的 HTTP 服务器,并严格检查所有内存泄漏风险,写出 100% 覆盖率的测试用例。”

只要 AI 的推理能力足够强,加上自动化的沙箱验证(Eval),它完全可以写出极度安全、高效的 C++ 代码。

如果 AI 能够不知疲倦地处理最繁琐的语法、填补最冗长的样板代码(Boilerplate),并且不出错,那么“语言本身是否易读、是否好写” 似乎就变得不再重要了。

因为代码根本不是给人看的,也不是人写的。当“人脑带宽”不再是瓶颈,发明一种“让人类写得更舒服”的新语言,就失去了最大的现实动机。

语言的两极化:自然语言与“AI 中间码”

如果不再有新的面向人类的通用编程语言,未来的代码世界会变成什么样?

答案是:极端的两极分化。

上层:英语(或自然语言)成为终极编程语言。

Andrej Karpathy 的预言正在成为现实(Software 3.0)。人类不需要学习晦涩的语法,人类只需要学习如何清晰、严谨地表达意图,编写能够精准约束 AI 的 Spec(规格说明书)。我们与机器的接口,退回到了人类最擅长的媒介。

底层:只有机器能读懂的“AI 专属语言”。

如果你是大模型厂商(比如 OpenAI 或 Google),当你发现 90% 的代码都是你的模型生成的,你还会让模型生成冗长、为了兼顾人类可读性而充满妥协的 Java 或 Python 代码吗?

不会的。巨头们极有可能会研发一种专门面向 AI 优化的中间表示语言(Intermediate Representation, IR)

这种语言对人类来说如同天书,但对于模型来说:

  • Token 效率极高:原本需要 1000 个 Token 表达的逻辑,这种语言只要 50 个 Token,极大节省推理成本和上下文窗口。
  • 逻辑高度压缩:天生适合并行计算和智能体之间的状态传递。

AI 会将人类的自然语言直接“编译”成这种中间码,然后运行。

在这个过程中,介于自然语言和机器码之间、那种专门为了“让人类勉强能懂又能让机器执行”而存在的传统编程语言,其生存空间将被彻底抽空。

小结:致敬“古法编程”的黄金时代

这听起来有些感伤,但这就是技术演进的无情车轮。

就像今天,依然有人沉迷于机械表的齿轮咬合,依然有人热爱在暗房里冲洗胶卷。

“纯手工编写代码(Handcrafted Code)”——这种我们曾引以为傲的工业生产方式,未来可能也会退化成一种个人的“艺术爱好”或“思维体操”。我们称之为“古法编程”

在某个安静的周末,你或许依然会打开编辑器,为了兴趣手撸一段优雅的 Go 并发或者 Rust 生命周期,享受那种久违的、直接控制机器的“心流”多巴胺。

但在残酷的商业战场上,古法编程即将落幕。

不要再为语法糖而争论不休,不要再期待下一个能拯救你的新语言。

去锻炼你的系统思维吧,去学着用自然语言精准地描绘你的蓝图。因为在下一个时代,定义目标的造物主,永远比精通语法的泥瓦匠更稀缺。


你还在坚持“古法编程”吗?

面对 AI 现场生成代码的冲击,你是否还会为了某种语言的“优雅语法”而兴奋?在你的理想中,未来的“AI 专用中间码”应该长什么样?你是更享受亲自掌控每一行代码,还是更向往定义目标的“造物主”角色?

欢迎在评论区留下你对“古法编程”时代的最后致敬!


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

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

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


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

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

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

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

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


原「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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ☆

技术考古:Markdown 为何从博客工具演变成统治 AI 世界的“通用语”?

本文永久链接 – https://tonybai.com/2026/01/13/how-markdown-took-over-the-world

大家好,我是Tony Bai。

在这个由科技巨头主导、充斥着复杂算法和封闭生态的数字世界里,有一种技术显得格格不入。它没有专利壁垒,没有复杂的构建流程,甚至不需要特定的软件就能阅读。

它是 Markdown

近期,知名科技博主 Anil Dash 发布了一篇题为《How Markdown Took Over the World》的长文。他在文中深情回顾了这一格式的诞生与崛起,并指出:在这个由科技巨头主导、充斥着封闭生态的数字世界里,Markdown 是一场属于普通人的胜利。

如今,从 GitHub 上的亿万代码仓库,到 ChatGPT等大模型 生成的每一个回答,再到你随手记下的 Apple Notes,Markdown 无处不在。它不仅成为了技术人员的“普通话”,更意外地成为了 AI 时代的“通用语”。

这一切,都始于 20 年前一位“固执”的苹果博主为了偷懒而写的一个小脚本。今天,让我们跟随 Anil Dash 的视角,回顾这段充满偶然与必然的技术传奇。

缘起:一个博主的“偷懒”计划

2002 年,John Gruber 做了一个在当时看来极其不理性的决定:全职运营一个只关注苹果公司动态的博客——Daring Fireball

在那个博客刚刚兴起的蛮荒时代,发布内容并不容易。你要么忍受简陋的输入框,要么得手写复杂的 HTML 标签。为了能在写文章时(比如加粗、插入链接)不被繁琐的 HTML 标记打断思路,John 决定为自己开发一套工具。

他的核心理念是:既然 HTML (HyperText Markup Language) 太复杂,那就叫它 Markdown 吧。

如果你想加粗,就用 **;想引用,就用 >;想列表,就用 -。这些符号并非凭空创造,而是深受电子邮件时代纯文本格式习惯的影响。John 的天才之处在于,他将这些约定俗成的习惯标准化,并写了一个 Perl 脚本将它们转换为合法的 HTML。

2004 年 3 月,在 Aaron Swartz(那位早逝的天才少年)的协助测试下,Markdown 正式发布。没有人预料到,这个小小的工具将改变互联网的未来。

统治世界:从程序员到 AI

Markdown 的崛起并非一夜之间,但它的生命力却异常顽强。

  1. 开发者的拥抱:GitHub 的出现是关键转折点。它将 README.md 设为项目标配,使得 Markdown 成为了开发者描述项目的标准格式。
  2. 应用的普及:从 Slack 到 Discord,从 Notion 到 Obsidian,现代生产力工具几乎全部内置了 Markdown 支持。哪怕是 Google Docs 和 Apple Notes 这样的大众软件,最终也向用户需求妥协,加入了 Markdown 支持。
  3. AI 的通用语:最令人意想不到的转折发生在当下。当最前沿的 LLM(大型语言模型)需要一种格式来输出结构化内容时,它们不约而同地选择了 Markdown。因为它既对人类可读,又对机器友好,且完全开放。

Anil Dash 在他的回顾文章中总结了 Markdown 成功的 10 个技术原因,其中几点尤为深刻:

  • 解决真实问题:它不是为了“发明一种新格式”,而是为了解决“手写 HTML 太痛苦”这个具体痛点。
  • 利用现有习惯:它没有强迫用户学习新符号,而是沿用了电子邮件时代的纯文本习惯(如 > 表示引用)。
  • 没有知识产权 (IP) 负担:John Gruber 从未试图将其商业化或申请专利,这种彻底的开放性消除了所有采用者的顾虑。
  • “查看源码”的哲学:Markdown 文件本身就是教程。你只需要看一眼源文件,就能立刻学会怎么写。

硬币的另一面:自由的代价

当然,Markdown 这种彻底的自由和缺乏中央控制,也带来了一个长期的副作用——碎片化

正因为 John Gruber 当年只给出了一个 Perl 脚本而没有定义极其严谨的规范,导致后来出现了各种“方言”。GitHub 有自己的 GitHub Flavored Markdown (GFM),Reddit 有自己的解析规则,Obsidian 和 Notion 也都添加了各自的私有语法(如双向链接 [[Link]])。

这导致了一个尴尬的现实:虽然 Markdown 到处都是,但你的 Markdown 文件未必能在所有地方都完美渲染。 表格的语法支持不一,数学公式的写法各异,甚至连换行符的处理都有微妙差别。

直到后来 CommonMark 等项目的出现,才试图事后诸葛亮式地去修补这种分裂。

但幸运的是,Markdown 的核心语法(标题、列表、粗体、引用、链接)已经足够稳固,成为了事实上的标准。正是这最基础的 80% 功能,支撑起了它在 AI 时代的通用性。对于大语言模型而言,这些细微的方言差异完全可以忽略不计——它只需要用最基础的语法,就能让全世界读懂。

这也再次印证了那个道理:在规模化面前,简单且“足够好”的方案,往往能战胜完美但复杂的方案。

启示:善良与开放的力量

Markdown 的故事,是对当代科技行业的一种温柔提醒。

真正的互联网基础设施,往往不是由拿了巨额风投的初创公司在董事会里规划出来的。它们往往源于像 John Gruber 或 Aaron Swartz 这样的人——他们有正职工作,但也充满热情;他们为了解决自己的问题而造轮子,然后慷慨地将其分享给世界。

在这个被“护城河”、“生态闭环”和“商业化变现”充斥的时代,Markdown 证明了:一个好的点子,加上一颗慷慨的心,依然可以改变世界。

下次当你用 ** 加粗文字,或者看着 ChatGPT 逐行吐出格式完美的回答时,请记得:这背后没有复杂的商业算计,只有一位在费城看球赛的博主,想让你打字时能稍微轻松一点。

资料链接:https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/


你的 Markdown 记忆

Markdown 已经陪伴了我们 20 年。你还记得自己第一次接触 Markdown 是在什么场景下吗?是写 GitHub README,还是做笔记?你最喜欢的 Markdown 编辑器又是哪一款?

欢迎在评论区分享你的 Markdown 故事和神器推荐! 让我们一起致敬这个简单而伟大的工具。

如果这篇文章让你对 Markdown 有了全新的认识,别忘了点个【赞】和【在看】,并转发给你的朋友,哪怕他只是个爱记笔记的非程序员!


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

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

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


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

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

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

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

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


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

© 2026, bigwhite. 版权所有.

❌