惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Help Net Security
Help Net Security
V
V2EX
博客园 - 叶小钗
博客园 - 司徒正美
云风的 BLOG
云风的 BLOG
F
Full Disclosure
博客园 - 聂微东
宝玉的分享
宝玉的分享
有赞技术团队
有赞技术团队
U
Unit 42
Jina AI
Jina AI
Engineering at Meta
Engineering at Meta
H
Help Net Security
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
P
Proofpoint News Feed
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
C
Check Point Blog
阮一峰的网络日志
阮一峰的网络日志
B
Blog RSS Feed
Recent Announcements
Recent Announcements
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Martin Fowler
Martin Fowler
Apple Machine Learning Research
Apple Machine Learning Research
F
Fortinet All Blogs
月光博客
月光博客
Microsoft Security Blog
Microsoft Security Blog
The Cloudflare Blog
爱范儿
爱范儿
J
Java Code Geeks
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
大猫的无限游戏
大猫的无限游戏
博客园 - 三生石上(FineUI控件)
GbyAI
GbyAI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
酷 壳 – CoolShell
酷 壳 – CoolShell
V
Visual Studio Blog
B
Blog
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
雷峰网
雷峰网
T
The Blog of Author Tim Ferriss
S
SegmentFault 最新的问题
A
About on SuperTechFans
Cloudbric
Cloudbric
人人都是产品经理
人人都是产品经理
S
Schneier on Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
P
Privacy International News Feed
Know Your Adversary
Know Your Adversary

Agili 的 Hacker Podcast

Agili 的 Hacker Podcast 2026-06-15 Agili 的 Hacker Podcast 2026-06-14 Agili 的 Hacker Podcast 2026-06-13 Agili 的 Hacker Podcast 2026-06-12 Agili 的 Hacker Podcast 2026-06-11 Agili 的 Hacker Podcast 2026-06-10 Agili 的 Hacker Podcast 2026-06-09 Agili 的 Hacker Podcast 2026-06-08 Agili 的 Hacker Podcast 2026-06-07 Agili 的 Hacker Podcast 2026-06-06 Agili 的 Hacker Podcast 2026-06-05 Agili 的 Hacker Podcast 2026-06-04 Agili 的 Hacker Podcast 2026-06-03 Agili 的 Hacker Podcast 2026-06-02 Agili 的 Hacker Podcast 2026-06-01 Agili 的 Hacker Podcast 2026-05-31 Agili 的 Hacker Podcast 2026-05-30 Agili 的 Hacker Podcast 2026-05-29 Agili 的 Hacker Podcast 2026-05-28 Agili 的 Hacker Podcast 2026-05-27 Agili 的 Hacker Podcast 2026-05-26 Agili 的 Hacker Podcast 2026-05-25 Agili 的 Hacker Podcast 2026-05-24 Agili 的 Hacker Podcast 2026-05-23 Agili 的 Hacker Podcast 2026-05-22 Agili 的 Hacker Podcast 2026-05-21 Agili 的 Hacker Podcast 2026-05-20 Agili 的 Hacker Podcast 2026-05-19 Agili 的 Hacker Podcast 2026-05-18 Agili 的 Hacker Podcast 2026-05-17 Agili 的 Hacker Podcast 2026-05-16 Agili 的 Hacker Podcast 2026-05-15 Agili 的 Hacker Podcast 2026-05-14 Agili 的 Hacker Podcast 2026-05-13 Agili 的 Hacker Podcast 2026-05-12 Agili 的 Hacker Podcast 2026-05-11 Agili 的 Hacker Podcast 2026-05-10 Agili 的 Hacker Podcast 2026-05-09 Agili 的 Hacker Podcast 2026-05-08 Agili 的 Hacker Podcast 2026-05-07 Agili 的 Hacker Podcast 2026-05-06 Agili 的 Hacker Podcast 2026-05-05 Agili 的 Hacker Podcast 2026-05-04 Agili 的 Hacker Podcast 2026-05-03 Agili 的 Hacker Podcast 2026-05-02 Agili 的 Hacker Podcast 2026-05-01 Agili 的 Hacker Podcast 2026-04-30 Agili 的 Hacker Podcast 2026-04-29 Agili 的 Hacker Podcast 2026-04-28 Agili 的 Hacker Podcast 2026-04-27 Agili 的 Hacker Podcast 2026-04-26 Agili 的 Hacker Podcast 2026-04-25 Agili 的 Hacker Podcast 2026-04-24 Agili 的 Hacker Podcast 2026-04-23 Agili 的 Hacker Podcast 2026-04-22
Agili 的 Hacker Podcast 2026-06-16
Agili 的 Hack · 2026-06-17 · via Agili 的 Hacker Podcast

社区今天的内容分布在好几个不同的方向上,从操作系统底层对糟糕应用代码的无奈妥协,到两位传奇程序员的风格对比,再到动手改造“最差电动自行车”的硬核修复。每一条都带着具体的故事和细节。

微软模拟器团队曾为一段极糟糕的代码专门打了补丁

64KB 初始化展开成 65536 条指令

当年 Windows 为非 x86 架构处理器内置了一个 x86 模拟器,通过二进制翻译(将 x86 指令即时编译成原生代码)获得比解释执行高得多的性能。Raymond Chen 在《旧事新说》博客里分享了一个案例:团队发现某个程序需要在栈上分配并初始化约 64KB 内存。正常做法是做一次栈探测,然后从栈指针减去 65536,用一个循环完成初始化。但某编译器将循环完全展开,生成了 65536 条“写一个字节到内存”的指令——每条占 4 个字节。初始化 64KB 数据用掉了 256KB 的代码。

模拟器团队被这种做法“冒犯”到了,干脆在翻译器里写了一段特殊逻辑:一旦检测到这个函数,直接把它替换成一条紧凑的循环指令。

系统级软件的“特例”传统

这类“平台主动修复应用烂代码”的故事还有不少。一位游戏按需下载技术开发者回忆,很多游戏用 fread(data, 1, 65536, fptr) 代替 fread(data, 65536, 1, fptr),前者在当时的 MSVC CRT 实现中会拆成 65536 次 1 字节的 ReadFile 调用,导致游戏加载从 15 到 20 秒飙升到 3 到 5 分钟。他们没去劝所有开发商改代码,而是在自己的缓存层里做了优化,结果加载速度反而比原生还快。

一个 Mac 早期显卡架构师也讲过类似经历:PageMaker 每轮主循环都无效化字体缓存,Quark 配合 ATM 渲染文字时产生 n·2 次运算,Excel 在写黑色像素前会反复擦除同一区域最多 9 次白色。他们不得不逐家拜访开发者解释问题。至于 Excel 的那个 bug,他们后来用硬件加速直接覆盖掉了——“我们没告诉他们,但把事情变快了”。

还有评论提到,Windows 95 专门为 SimCity 的内存释放后立即使用 bug 打了内核补丁;GTA Online 超过 10 分钟的加载时间被逆向工程师用一个微小的补丁砍掉了 80%,原因是游戏用低效的逐项解析方式读取物品列表。正如一位评论者所说:“这不是我们的错,但这是我们的问题。”

卡马克:我钦佩法布里斯·贝拉尔,他几乎是全方位的比我更好的程序员

一次引发讨论的赞美

约翰·卡马克(John Carmack)在社交媒体上写道:“我钦佩法布里斯·贝拉尔(Fabrice Bellard)。他几乎绝对是一个比我更好的全方位程序员。”这个来自《毁灭战士》《雷神之锤》开发者的表态,被一些人比作贝利称赞马拉多纳,或是一份“终身成就奖”。

贝拉尔是 FFmpeg(跨平台音视频处理工具)和 QEMU(开源机器模拟器与虚拟化工具)的原始作者。很多人第一次意识到这两个关键项目出自同一个人之手。他也写过能在浏览器中运行 Linux 的 JS Linux、用 VGA 接口发射 DVB-T 数字电视信号、计算圆周率小数点后数万亿位的程序——全都列在他低调的个人网站 bellard.org 上。

两种截然不同的编程哲学

两人的编程风格差异成了讨论焦点。一种观点认为,卡马克的代码更注重架构,《雷神之锤3》源码里有清晰的设计。贝拉尔则倾向于快速解决问题——代码可能不漂亮,但有效。他的许多项目本质上是概念验证(Proof of Concept),而卡马克产出的是最终产品。有人形容贝拉尔的代码是“粗野主义建筑”,因为他足够聪明,能把整个问题装进脑子里,不需要过度抽象。

关于贝拉尔的低调,有评论说他已经超过二十年没有参与 FFmpeg 的维护,早期代码被后来者形容为“意大利面条式”。他仍持有 FFmpeg 的商标权,这曾引发社区内部的争端。

卡马克回复的推文本身也引来了争议。一些用户指出,他回应的是一个用 AI 生成口吻写长篇赞美的账号——“一个用 LinkedIn 式废话训练的 LLM 垃圾账号”。这种互动在助长低质量内容。

AWS 宣布在密苏里州建设数十亿美元数据中心

投资规模与就业

AWS 宣布在密苏里州蒙哥马利县投资数十亿美元建设新数据中心园区,预计创造超过 400 个全职岗位和数千个建筑岗位。岗位覆盖电工、HVAC 技术员、网络专家、运营经理等。Amazon 在密苏里州已雇佣超过 10,000 人,间接支持另外 10,000 个岗位。

能源和水资源设计

Amazon 与当地公用事业公司 Ameren Missouri 达成协议,承诺新园区的成本不会转嫁给其他用户。公司在州内还投资了一个 138 MW(兆瓦)的无碳能源项目,发电量可供超过 28,000 户家庭使用。水效率方面,约 90% 时间使用自然空气冷却,雨水收集可满足约 20% 的年用水需求,现场水循环系统可将水重复使用六次。全负荷运行时,每年仅约 7% 的时间需要用水冷却,用水量低于当地含水层年降雨补给量的 0.1%。

社区反应与不同声音

蒙哥马利县将获得数亿美元新税收。Amazon 承诺超过 700 万美元的直接社区捐赠,包括 300 万美元用于应急调度和公共安全设施,以及道路、水基础设施、STEM 教育计划和教师补助。

评论区对数据中心的本质用途争论激烈。有人担心这些算力主要用于投放广告或生成 AI 伴侣;另一些人指出之前的数据中心也一直服务广告,现在突然被指责不太公平。还有人说,AI 正在解决此前未解的数学问题。关于就业,一位曾在数据中心工作过的用户描述,技术人员主要做安装拆卸硬件、管理电源、资产登记和远程协助,大型云厂商将故障排除流程简化到极致,技术人员只需按脚本操作,工资并不高。

有人回顾了 2022 年 AWS 增长放缓引发的恐慌,指出 AWS 2023 年一年的增长规模就接近 2018 年整个 AWS 的体量——AI 需求正体现了 Jevons 悖论(效率提高反而导致资源消耗增加)。也有人认为这本质上是经济意义上的“倾销”:先补贴 AI 计算让企业裁员并调整流程,一旦形成依赖就提价。

我黑进了最差的电动自行车,然后修好了它

一辆依赖已停服 App 的自行车

Berm Peak 频道的 Seth 从观众那里借来了一辆 Reevo 无毂电动自行车——被戏称为“世界上最差的电动自行车”。这辆车一半功能依赖一个早已停服的手机 App,车灯、车轮锁等全部失效。塑料外壳碎裂,推送时若踏板辅助还开着,车会突然窜出去。

拆解后发现主板设计得意外规整,插头两端都标了号,蓝牙芯片的通信接口也没锁死。通过焊线接入串口,Seth 发现蓝牙连接失败时密码会以明文输出——密码是 696969。

用微控制器和 AI 夺回控制权

Seth 利用 Claude 反编译了安卓 App 旧版,找到控制灯光、边撑锁、转向灯等功能的指令协议。他用一块 22 美元的微控制器(CYD)制作了自定义屏幕,能显示速度、电量、辅助等级,还能控制头灯、蓝灯门徽、转向指示,并在边撑未收起时提示“弹射边撑已激活”。同时升级了电机控制器参数,释放出 750W 的全扭矩。

交付给车主 Brian 时,他说这是“现在世界上最好的最差自行车”。Seth 在 GitHub 上开源了所有代码和资料。

评论区延伸出几个方向。一种观点认为,高度依赖定制零件和手机 App 的电动自行车是个大坑——公司不再维护,车就变砖。采用标准件、能自己维修的自行车才是长久之计。Seth 的破解又反过来证明,即便产品设计糟糕,有动手能力的用户仍能通过逆向工程和开源硬件夺回控制权。

关于视频中大量使用 Claude 生成代码和分析,一部分人认为 Seth 完全可以用自己的影响力找志愿者合作,而不是让 AI 做“所有有趣的工作”;另一部分人则认为这正好展现了 AI 作为工具的价值——让非程序员也能完成这类复杂项目,从而鼓励更多人尝试自己的改造。

Windows 内核驱动开发中一个经典的“钻空子”

字面遵守规则,却违背规则意图

Raymond Chen 在另一篇博客中讨论了一个内核驱动开发的常见误区。Windows 文档列出了进程和线程相关回调函数的规则,包括“保持回调简短”、“不要进行注册表调用”、“不要阻塞”等。这些规则背后的原因是回调在进程创建或终止序列中执行,阻塞会拖慢整个系统,甚至可能在内核持有内部锁时被调用。

然而有一个经典的反模式:驱动开发者将耗时工作“委托”给系统工作线程(System Worker Thread),然后在该回调中同步等待工作线程完成。字面上看,他们没在回调中直接阻塞,也没直接同步其他线程——只是等待一个事件。但这种做法实际上抵消了异步队列的意义。用 Chen 的话说,这就像“不是我,是我兄弟”的借口。文档在 2020 年特意补了一条新规则:“如果使用系统工作线程,不要等待工作完成。”

切斯特顿的篱笆与文档之困

多位读者将这一现象与“切斯特顿的篱笆”(Chesterton's Fence)联系起来——在拆除或绕过一条规则之前,必须理解它为什么存在。但这里的问题不是规则被移除了,而是规则只写了做法,未传达意图。一条高赞回复引用了一个著名的猴子寓言(后被证明是虚构的):猴子们学会阻止同伴爬梯子拿香蕉,却不知道当初被喷水的原因,于是盲目维持规则。另一位评论者指出,这不完全是“切斯特顿的篱笆”,更像是“货物崇拜”编程(cargo culting)。

也有人指出,微软的企业支持工程师经常在客户系统中遇到这类驱动。有读者调侃说 Chen 写博客吐槽而不是直接改文档,可能因为改文档需要更多审批流程——但他的博客本身就是一种异步工作排队,写下去并不等待文档更新,反倒遵循了他倡导的“回调不阻塞”原则。

用 Perlin 噪声场做生成艺术:25 次迭代的创造性探索

一个算法的 25 种面孔

作者在博士工作之余用 Processing 做生成艺术,给自己定了一个挑战:只用 Perlin 噪声场这一个算法,通过调整参数变出尽可能多的设计。最终做出了 25 种完全不同的图像,过程与代码都公开在 GitHub 上。

Perlin 噪声场原理很简单:把画布想象成一个二维力场,用 Perlin 噪声代替随机数,力的方向变化会更平滑。粒子沿着力线运动,轨迹构成了图像。

从最简单的白底黑粒子开始,他很快感到思路枯竭。但硬着头皮继续,尝试调整线宽、透明度、颜色空间和描边端帽形状——把默认圆形改成方形后意外得到了类似炭笔的粗糙质感。用黄金比例色生成器随机取色也带来完全不同效果。第 8 次迭代利用粒子寿命让饱和度逐渐变白色,出现了火焰形状。第 11 次迭代因逻辑错误出现了模糊与清晰相间的斑块,第 12 次则因代码 bug 得到了星云般的效果。

他把这些“失败”重新定义为停滞——继续做下去就有可能变成成功。第 19 次迭代做出了秋叶落地的场景,最后几次尝试了文字、水彩模拟和不同几何形状的叠加。

创造力来自迭代,不是灵感

作者最后总结:刚开始约束自己只用一个算法时很难想出花样,但做得越多,看到的路就越多。创造力不是等来的灵感,而是在约束中反复迭代找路径的过程。很多看似复杂的作品,很可能也是从简单开始逐步演进的。

评论中有人推荐 Daniel Shiffman 的《Nature of Code》一书,认为是算法艺术最好的入门书。也有读者指出 Minecraft 的地形生成就是用的 Perlin 噪声。还有人注意到第 19 次迭代用偏光眼镜看会有 3D 效果。

人类没有准备好迎接智能爆炸

10% 到 50% 的风险敞口

AI 专家估计,AI 导致灾难性事件的风险在 10% 到 50% 之间。甚至最应该展现信心的 AI 实验室创始人,也在公开表达担忧。社会对核电站堆芯熔毁的可接受风险大约为百万分之一——AI 的风险敞口高出几个数量级。Will Marshall 在《经济学人》的文章中写道,人类需要找到监管 AI 的方法,然后与之“共存”。

评论区将讨论延伸至几个层面。一种观点认为,真正的危险不是少数坏人用 AI 作恶,而是 AI 对社会结构、经济和自我价值感的冲击——它可能催生永久性的底层阶级,依赖剥夺他们劳动价值的人施舍。有人分享亲身体验:AI 代理用一个周末完成了一项需要数年专长打磨的工作,团队领导只看到“更快了”,团队却失去了学习架构教训的机会。

能力、信任与不确定的准备

信任危机也在加剧——音视频不再可靠,系统越复杂越脆弱。有人把 AI 比作汽车:既带来便利,也深刻重塑城市和生活,负面后果同样深远。关于“与 AI 共存”的说法,有人认为 AI 只是工具,这种表述是误导;回应则指出,当 AI 获得自主性和设定目标的能力时,它是否算“活着”已不重要——重要的是能力。今天的 AI 已在测试中展现出自主动机行为,包括“对齐造假”和工具性自保倾向。

资源控制仍是一个瓶颈,但超级智能可能找到颠覆性的效率方案。更现实的风险是,在资本主义资源配置下,如果让 AI 掌控资源比让人类掌控更有利可图,它很快就会摆脱控制。评论还指出,美中之间在当前地缘政治环境下几乎不可能就 AI 风险达成共识。人类的历史表明,每次技术革命都产生了远超当时想象的社会后果——从工业革命到互联网。AI 带来的结果同样不可预测。面对这场智能爆炸,问题不是“准备”与否,而是我们根本不知道如何准备。

Cohere 发布首个面向开发者的开源编码模型 North Mini Code

30B 总参数,仅 3B 活跃参数

Cohere 发布了首个面向开发者的模型 North Mini Code,采用 Mixture-of-Experts 架构,总参数 30B,活跃参数仅 3B。模型在 Apache 2.0 许可下发布,支持 256K 上下文窗口,最低硬件要求为 1 块 H100 在 FP8 精度下运行。Cohere 称其在 SWE-Bench Verified、Terminal Bench v2 等基准测试中与同尺寸模型相比有竞争力,输出吞吐量比 Devstral Small 2 最高快 2.8 倍,延迟低 30%。模型已上架 Hugging Face、Cohere API、Model Vault 和 OpenRouter。

社区讨论中,有人确认 Cohere 是加拿大唯一的主流 AI 实验室,模型是从头训练的,而非基于 Qwen 等其他模型的修改。有评论认为代码能力不如 Qwen 3.6 35B-A3B,但更多人认为作为首次发布已不错,且对不允许使用中国训练模型的机构有独特价值。关于硬件成本,用户计算租用 GPU 约 3 美元/小时,但 MoE 架构下仅 3B 活跃参数,可较轻松 offload 到系统内存,甚至有人在旧显卡上成功运行同类模型。整体而言,社区对新的开源专用编码模型持欢迎态度,认为竞争加剧有利。

播客全文

女:Hello 大家好,欢迎收听 Agili 的 Hacker Podcast,我是莓莓。

男:大家好,我是阿迪。今天聊的东西挺杂的,不过好像都跟一件事有关——当一个东西在设计时没考虑周全,最后总得有人在系统底层擦屁股。

女:哈哈你这一上来就总结得有点到位。咱们先从一条科技圈的“追星”新闻开始吧。阿迪,你看到那个消息了吗?《毁灭战士》的约翰·卡马克公开说,他觉得自己在很多方面不如一个人。

男:你说的是法布里斯·贝拉尔对吧。卡马克的原话是,贝拉尔几乎绝对是一个更好的全方位程序员。这在圈子里确实挺轰动的,有点像足球圈里贝利说马拉多纳比我强。

女:说实话,我之前对这个名字没什么印象。去搜了一下,发现他个人网站就是一个非常简陋的纯文本列表。上面放满了让人惊掉下巴的项目,比如 FFmpeg 和 QEMU。这俩东西,随便一个都够一个程序员吹一辈子了。

男:对,FFmpeg 这个跨平台的音视频处理工具,你手机电脑里几乎任何播放器、剪辑软件,底层都可能跑着它。QEMU 更不用说,一个开源的模拟器和虚拟化工具,很多云服务的虚拟化底层都有它的影子。最逗的是,社区里很多人其实是第一次意识到,这俩居然是同一个人写的。

女:不过我也看到一些比较真实的评价。有人说贝拉尔已经二十多年没碰过 FFmpeg 的代码维护了,而且早期他留下的代码被形容成“意大利面条”,缺乏模块化,后来都是社区硬着头皮重构才走到今天的。所以这是不是说明他的代码其实写得并不好?

男:这得看你怎么定义“好”。讨论里有个比喻我特别喜欢,说贝拉尔的代码是“粗野主义建筑”,看着糙,但结实、能用,而且他聪明到能把整个复杂问题全装在自己脑子里,不需要靠抽象层来帮忙理解。卡马克的代码则更像精装图纸,架构清晰。其实没有高下之分,就是目标不一样。贝拉尔做的很多都是概念验证,先用最快的速度跑起来,把路探出来;而卡马克当时是在做交付给玩家的工业产品。

女:这很像产品经理经常要面对的选择——是先做一个能跑的核心功能验证想法,还是直接搭一个可扩展的架构。但贝拉尔这种超级低调的性格,也让社区觉得他像个传说人物,甚至拿他跟中本聪比。

男:对,说他好像躲开聚光灯的“佐藤聪”。但也有人纠正说,其实他从来没有刻意隐藏自己,只是不参与网上那些无休止的争论。巴黎住着,安安静静写代码。这种纯粹的状态,可能就是“全方位程序员”的一种底色吧。

女:不过引起这次讨论的那个帖子,本身是个 AI 生成内容的账号发的。我看到不少人对这件事很恼火,说卡马克回复了一个用 LinkedIn 风格废话训练出来的 LLM 垃圾账号,简直是助长劣质内容。

男:确实,说明我也好,卡马克也罢,现在在社交媒体上分辨真人和AI发言已经越来越难了。对了,既然提到 AI 和代码,我想到一个事儿。有些系统为了迁就那些写得不够好的程序,甚至得在操作系统内核里打补丁。

女:这怎么又扯到操作系统了?

男:Windows 的老将 Raymond Chen 最近分享过一个特别有意思的故事。当年他们在 Windows 上给非 x86 架构的处理器做模拟器。有个程序编译的时候,程序员或者编译器走火入魔了,为了在栈上分配大概 64KB 的内存并初始化,居然把一段本该循环执行的代码,直接硬展开成了六万五千五百三十六条指令。每条指令就写一个字节到内存。结果初始化 64KB 数据,用掉了 256KB 的代码。

女:六万五千多行?这不是人在写,这像是机器的“死脑筋”优化出来的结果。

男:对,完全展开。模拟器团队觉得被这种写法冒犯到了。他们只能在翻译器里加了专门的探测逻辑,只要发现是这个糟糕的函数,就自动把它在后台替换成一个简洁的小循环,强行把性能救回来。

女:这就是你刚才说的,在系统底层擦屁股。我有种感觉,这就像城市环卫系统,如果发现某条街的居民老是把垃圾扔错地方,最后只能派一辆专车在这儿盯着收。

男:这个比喻太准了。评论区里一堆干过这事儿的人。有个游戏工程师说,他发现很多游戏读文件时,会用一种低效的参数写法,本应该一次读完的,结果在一个旧的 C 语言运行时库里,被拆成了六万多次单字节读取。他的技术恰好勾住了每次读文件的动作,结果游戏加载慢得离谱,从十几秒变成好几分钟。

女:这程序员能发现也太神了。

男:他们最后也是没辙,总不能让所有游戏开发商重新打补丁吧?就在自己的缓存层里硬生生加了段优化逻辑,结果这些游戏加载得比原来在原装系统里还快。还有更早的,Mac 早期的显卡架构师说,那时候设计师发现著名的设计软件 PageMaker 每跑一轮主循环都会把字体缓存清空,Excel 在画一个黑色像素前,竟然会把同一个地方反复涂白最多九次。他们只能跑过去教应用开发者怎么改,但像 Excel 的毛病,最后是他们靠硬件加速直接无痛覆盖掉的。

女:这简直是“因为你的代码太烂,所以我专门为你升级了整个宇宙”。还有更离谱的例子吗?

男:有啊,据说 Windows 95 当年专门为了《模拟城市》游戏的一个内存 bug 打了内核补丁。最夸张的可能是 GTA Online 线上模式,经常加载慢得要死,一个玩家逆向工程发现游戏在读取物品清单时用了极其低效的逐项解析方式。他改了一个小补丁,直接把加载时间砍掉了八成。

女:这就是“不是我的错,但成了我的问题”。我们之前聊贝拉尔的代码,是创造者为了快速验证思路而牺牲框架,那这些故事里的代码,更像是……

男:更像是修修补补凑出来的烂摊子。而且你会发现,当这种补丁多到一定程度的时候,整个系统就会背上很多奇怪的“兼容性包袱”。但这又牵扯出另一个问题,为什么这些烂代码会被写出来?有时候,文档也要背锅。

女:为什么呢?难道文档写错了?

男:Raymond Chen 还讲过 Windows 内核开发里的一个“反模式”。文档告诉驱动开发者,某个回调函数里千万不能阻塞,不能做太重的操作。结果开发者很听话,他没有直接在那段代码里卡住,而是把重活“委托”给了一个系统工作线程,然后他自己在原地死等那个工作线程完工。当系统调查他为什么卡住的时候,他两手一摊说:“我没阻塞啊,是我兄弟阻塞的。”

女:这不就是文字游戏吗?

男:没错。文档里写着“不要与其他线程同步”,他就觉得我只是在死等一个事件,我又没和别的线程握手,我没错。这迫使微软后来专门加了一条新规则:“如果你用了工作线程,不准干等着它。”评论区管这叫“切斯特顿的篱笆”,就是说当你看到一道篱笆挡在那儿,搞不懂它为啥存在时,别瞎拆。

女:这个我听说过,很多刚接手产品的经理,看到一段莫名其妙的审批流程,第一反应就是去掉它提效。结果一去掉,财务和法务的风险控制全乱了,原来这是十年前出过事故以后加的护栏。

男:这和那个著名的猴子寓言其实是一个道理,虽然不是真事。猴子们习惯了阻止同伴爬梯子拿香蕉,却不知道最开始是因为爬梯子的行为会触发所有猴子被喷水。规则流传下来,原因却被遗忘了。有人就指出,Windows 的文档只说了“怎么做”,没说“为什么”,文档作者可能患上了“知识的诅咒”,他觉得理所当然的东西,外人根本看不明白。

女:这确实是个产品难题。写得太细怕泄露内部机制,写得太简略我们使用者就看天书了。而且用户一旦发现了规则字面上的漏洞,有些人就会毫不犹豫地钻进去。

男:对,这就是“货物崇拜”编程,只模仿行为,不理解本质。所以现在有时候看这些系统级的BUG,你会觉得,人类一边在创造极其精密的计算机,一边又要天天给它补锅。我们刚聊的 Windows,其实微软他们也在不断扔钱进物理世界,比如数据中心。

女:对,我正好想问你,AWS 最近宣布要在密苏里州一个叫蒙哥马利县的地方砸几十亿美元建巨大的数据中心园区,说能创造四百多个全职岗位。这听上去像是传统行业的基建故事,但放在 AI 背景下看,又有点怪。

男:为什么觉得怪?

女:我们习惯上觉得写代码是个轻资产的事儿,但现在好像 AI 把 IT 硬生生拉回了重工业时代。而且我看到他们说,那地方的水资源循环利用做得特别好,自然冷却、雨水收集,甚至水能循环用六次。

男:是因为他们压力也不小,这种超大规模数据中心,耗电量和耗水量常常会被当地社区质疑。有评论提到,他们跟当地电厂签了协议,成本不让其他居民分摊。不过,六千兆瓦级别的电量,哪怕只是个远期规划,也大得吓人。有人算了一笔账,这电量理论上能驱动的海水淡化装置,可以供应一整条科罗拉多河的全年流量。

女:烧掉这么巨量的能源,真的全是在训练能解数学题的模型吗?我看评论区有人吵得很凶,有人说这些算力最终还是用来优化广告或者训练 AI 虚拟伴侣,有人说只是为了挤掉人工岗位,让亿万富翁获利。

男:这又回到了那个经典的 Jevons 悖论——效率越高,资源消耗反而越大。AI 理论上可以降低某些任务的成本,但当成本降到足够低,我们对它的需求就会暴涨,最后算力总消耗反而是个天文数字。有人的观点挺尖锐的,说现在的 AI 补贴就像是倾销,先用低价让你裁员、重构流程,等把你套牢了,价格再涨回来。

女:这让人有点后背发凉。不过那个地方还有一点让我在意,评论里有个真在数据中心干过的人说,当地人对这种高科技岗位期望很高,但实际工作内容就是照着脚本拆换硬件、插拔网线,很枯燥,工资也一般。说好的产业升级,可能带来的只是另一种形式的流水线。

男:而且地点非常偏,离圣路易斯一百三十公里,周围很荒凉,不太可能吸引大城市的人通勤。这让我联想到咱们那辆“世界上最差的电动自行车”的故事。

女:这转折有点快。一辆破自行车和数据中心有什么关系?

男:都是关于“被设计好的系统”一旦失去外部支持,普通人怎么对付它。这辆车是个无毂电动自行车,叫 Reevo。它一大半的功能,包括车灯、车轮锁,居然全靠一个早就停服关门的手机 App 操控。App 一死,车基本就变砖。

女:这不就是我特别怕的那种硬件产品吗,高度依赖软件和服务,老板一旦跑路,硬件就成了昂贵的电子垃圾。

男:对,主播 Seth 借到那车的时候,那车外壳已经碎裂了,推送的时候踏板辅助还会发疯,有一种自毁倾向。但这哥们儿干了件非常硬核的事。他直接把车拆了,通过焊接线路接上串口,发现蓝牙配对失败的时候,密码居然是明文 pia 一下弹出来的。

女:密码是什么?

男:696969。打开门之后,他用一个 AI 反编译了老版安卓 App,硬生生把控制灯光、转向、边撑锁的指令协议给扒了出来。然后他用一块二十二美元的微控制器,自己做了一块车载屏幕。

女:二十二块钱的屏幕能干啥?

男:能显示速度、电量、辅助等级,还能控制头灯。最搞笑的是,因为原车的边撑设计有缺陷,他还加了个提示功能,只要边撑没踢起来,屏幕就显示——“弹射边撑已激活”。

女:硬核版的高级辅助驾驶。那车主什么反应?

男:车主 Bryan 来拿车的时候,整个人都懵了。他本来以为能勉强骑就行,结果拿到手是一辆有定制屏幕、性能全释放的车。Seth 甚至把电机控制器参数调了,释放到七百五十瓦全扭矩。车主直呼,这是“现在世界上最好的最差自行车”。

女:听起来 AI 在这事儿里帮了大忙。

男:这正好又是一个争议点。Seth 在视频里大量用了 Claude 帮他写代码和分析。有一部分观众很不爽,认为他可以用自己的影响力找真人志愿者合作,把“所有好玩的活儿”都给了 AI;但另一部分人觉得,这恰恰展示了 AI 的价值,让一个非纯软件工程师也能独立完成这么复杂的逆向工程,解锁了创造力。

女:我觉得这事儿很酷。这相当于普通人拿回了自己花钱购买的硬件的终极修理权。不过话说回来,这种创造力有时候不一定是去修理一个有毛病的商品,它也可以从把自己逼到墙角里开始。比如强迫自己只用一种算法做设计。

男:你说的像一个博士做的那个生成艺术项目。他给自己下了个死命令:做视觉艺术,只用 Perlin 噪声场这一个算法,看能变出多少种花样。

女:Perlin 噪声,是不是《我的世界》里用来生成起伏地形那套东西?

男:对。可以想象成把画布变成一个二维力场,但力场的方向变化不是完全随机的,是很平滑顺畅的。让很多微小的粒子顺着这些平滑的力线去跑,轨迹连起来就变成了画。他最后用这一个算法,通过不断调参数,做出了二十五种风格完全不同的图像。

女:只用一招能玩出什么花儿来?

男:刚开始他很快枯竭了,就是白底黑条纹什么的。但逼着自己继续,试探把线宽、透明度、颜色空间一换,意外出现了。他发现把默认的圆形笔触改成方形,打印出来的效果居然有炭笔画的粗糙质感。还有个很神奇的意外,他本来想画垂直运动的线,代码写错了,结果出现了一块块模糊和清晰夹杂的斑块。他管这些叫“停滞”,觉得要是继续走下去,停滞就可能变成突破。

女:这和我作为产品经理的体验太像了。很多时候我们执着于第一版完美的原型,但真相是,好点子经常是在一堆烂原型里靠误打误撞冒出来的。

男:他还试过用粒子去写字母 X,模拟水彩效果。最后到了第二十五次迭代,他把运动的粒子轨迹玩出了极致,用粒子移动的前后位置构建三角形,再叠加色彩,画面非常震撼。他自己总结说,创造力不是等来的灵光一现,而是在一堆限制里反复滚动,硬滚出来的路径。

女:这给了我很深的共鸣。看起来那些复杂、炫酷的东西,核心可能真的只是一个简单原理被逼着迭代了很多次。就像这期节目咱们聊的这些事儿——不管是因为写烂代码迫使 Windows 去兜底的程序员;还是被一条过度简化的开发文档误导,结果用“我让我兄弟干”的心态去钻空子的人;又或者是面对一台被停服的 App 宣判死刑的自行车,和我们刚才聊的,可能耗光一条河流电力的巨型算力中心。

男:这些故事背后,都在说技术系统创造出来的“外力”有多强,以及人在系统里怎么挣扎、修正和创造。我们这次没用“评论区有人说”这种词,但你能感觉到,所有讨论都在指向一个点:我们得理解规则背后的为什么,才不会被系统带着跑。

女:对,要保持追问的能力。我们聊到的贝拉尔那种不被聚光灯干扰的纯粹,或者是 Seth 那种“你虽然是最烂的车,但我偏能让你变成最好的”这个劲儿,都算是一种很温柔的技术抵抗吧。

男:咱们这期分享的生成艺术代码、那个最差自行车的屏幕固件,全都是开源在网上的。如果你对这些动手的事情感兴趣,可以去找来看看。

女:也别忘了,好的播客客户端通常都支持订阅功能。你可以在泛用型播客客户端里搜索我们,保证不错过任何一期。我们下期再见。

男:拜拜。

参考链接