今天，Agili 的 Hacker Podcast 每日博客将梳理 AI 模型军备竞赛、实用工具的新进展，以及一些被重新发现的旧日遗产。从开源转录库到 2.4 万亿参数的模型，再到用 Rust 重写的 JavaScript 运行时，技术背后的社区反馈往往比公告本身更有趣。
Handy 应用的维护者在跨平台分发语音转文字功能时，被各路方案折腾得够呛。ONNX 在 CPU 上表现不错，但 GPU 加速拉胯；MLX 好用却锁死在苹果生态；whisper.cpp 支持的模型有限，而且没有做过严格的数值验证。于是他自己动手，写了一个基于 ggml 的 Transcribe.cpp。
这个库上线就带了 16 个自动语音识别模型家族，总计超过 60 个具体模型，通过 Vulkan、Metal、CUDA 和 TinyBLAS 提供 GPU 加速。每个模型都跟参考实现做过数值对齐，词错误率测试的结果公开在仓库和 Hugging Face 上。官方绑定同时覆盖 Python、JavaScript/TypeScript、Rust 和 ObjC/Swift。
实时转录是评论区反复出现的关键词。有用户回忆起十几年前的 Dragon NaturallySpeaking 就能边说话边在光标处打字，现在的工具反而要走“先录完再粘贴”的弯路。作者回应，Transcribe.cpp 本身已支持流式输出，只是 Handy 还没把光标插入的功能接进去。
说话人分离功能正在开发中。作者透露会将 NVIDIA 的 Sortformer 移植过来，同时适配 IBM Granite-Speech-4.1 和 MOSS-Transcribe-Diarize 等模型。多位用户已在老旧手机上用 Handy 实现近实时离线转录，或是在 macOS 虚拟相机应用 Emyn 中集成该库，体验良好。
社区有人注意到 M4 Max 上的 Metal 性能比 Ryzen 4750U 的 Vulkan 快了近 10 倍。作者解释说这主要是硬件差距，集成显卡在内存带宽上完全没法跟 M4 Max 比。至于为什么弃用 ONNX，实测发现 TensorRT 和 CUDA 执行提供者在语音转文本任务上速度和 CPU 差不多，却带来巨大的二进制体积。项目目前只是 v0.1.0，受 Mozilla AI 的 BiR 计划资助，作者欢迎社区提 issue。
阿里巴巴在 X 上宣布 Qwen 3.8 将开源权重，总参数 2.4 万亿，性能仅次于 Fable 5。预览版已在 Token Plan、Qoder 等平台上线。这一动作紧跟在 Moonshot AI 宣布将开源 2.8T 参数的 Kimi K3 之后，Hacker News 上普遍解读为中国 AI 公司之间在激烈竞争。
社区把这种开源行为的动机归结为几种可能：推动模型商品化以挤压美国前沿实验室的利润空间；中国市场“内卷”压力下的低价竞争；以及让全球开发者绕过 API 封锁，独立部署模型。开发者们更关心的实际问题则是，阿里巴巴会不会像前几代那样同步发布适合本地运行的 35B MoE 或 122B 尺寸版本。部分实际使用过 Qwen 3.7 Pro 的工程师觉得编码体验不如 DeepSeek V4 Pro，但也有不少人喜欢 Qwen 3.7 Max 的速度。
智能电视直接播网页视频通常很麻烦，屏幕镜像又容易延迟和掉画质。Castor 的思路是启动一个无界面的 Chrome，监控 DevTools 协议里的网络流量，自动抓出视频流，转码后通过 DLNA/UPnP 投到电视上。它还能调用 Whisper 实时生成并烧录字幕，也支持用户自己编写模板通过 TMDB 接口搜片。
作者强调这只是一个通用投射工具，不托管内容也不破解 DRM，但默认配置文件里包含了一些盗版流媒体网站地址，评论区普遍觉得这层关系撇不清。更让社区热议的是，项目大量代码由 Claude 辅助生成，有人对 AI 写代码和项目的法律边界提出了质疑。
有用户分享了 TV Explorer，一个纯静态网站，从公开的 GitHub 频道列表中抓取超过一万条免费频道的 HLS 流，直接用 <video> 标签播放，没有广告和跟踪。响应速度快到被形容为“接近模拟电视的换台体验”。不过部分频道有区域限制，iOS 上偶尔加载失败。Castor 目前只支持 DLNA 设备，Chromecast 支持还是实验性的，Roku 不在计划内。
1960 年，23 岁的 Anatoly Karatsuba 在莫斯科国立大学的一次研讨会上，推翻了导师 Kolmogorov 关于乘法复杂度不可能低于 O(n²) 的断言。他的算法用便宜的加法替换掉一部分乘法：以 12×34 为例，传统需要四次个位数乘法，他通过 (a+b)×(c+d) – ac – bd 的技巧只做了三次。对大数字递归使用这个拆半策略，复杂度降到了 O(n^1.585)。今天 Python 的整数乘法在约 630 位以下用长乘法，以上就切换到 Karatsuba。
2019 年 Harvey 和 van der Hoeven 提出了复杂度仅为 O(n × log n) 的算法，几乎和加法一样快。但它是一个“银河算法”：只有当数字大到 2^713739807… 位时才生效，现实中完全用不上。即便如此，理论界普遍猜测这就是乘法速度的极限，但尚未被证明。
社区讨论把焦点带回了工程细节。一位 PostgreSQL 开发者曾花几百小时调优 Karatsuba 的切换阈值，最终发现直接把基数从 10000 改成 100000000，速度快了一倍。GNU GMP 库官方手册列出了六种乘法算法，从长乘法到快速傅里叶变换，根据操作数大小自动选择。几位工程师指出，进位传播是硬件乘法器的实际瓶颈，而大 O 分析通常忽略进位，这在真实芯片上不行。
纽约市长发布了一份“租房骗局报告”，要求房东和经纪人披露是否用 AI 生成或编辑了房源图片。在 StreetEasy 等平台上，用 AI 把房间塞进根本放不下的家具已成常态。一位租户用 LiDAR 实测，发现经纪人声称的 650 平方英尺实际只有 505 平方英尺——面积虚报同样泛滥。不少人呼吁市长同时强制标注真实面积，并引用荷兰、德国等地的标准化测量规则作对比。
评论区普遍怀疑仅靠披露解决不了问题。Meta 平台早就要求标注 AI 图片，用户看到的依然是铺天盖地的 AI 垃圾，标注几乎没改变什么。有人担心未来的纽约房源将像 cookie 横幅一样出现毫无意义的“AI 增强”免责声明。还有讨论涉及广告法历史：1960 年代 Campbell 汤因使用弹珠让汤看起来更满而被判虚假广告，AI 图片刻意放大空间、缩小家具，本质相同。不过更多人指出根本矛盾是房屋供应不足——在房东市场里，贴再多标签也改变不了租户别无选择的局面。
这个网站汇集了超过 18,600 个免费 Amiga 软件，总容量约 10,142 MiB，来自公共领域库、演示场景组织和用户组。它收录了 Fred Fish 系列——由美国程序员从 1986 年开始整理，在互联网普及前是 Amiga 流传最广的免费软件合集。还有英国的 17 Bit Software 库，收录近 3,700 个条目，以及 LSD 演示组织近 9,900 个条目的庞大合集。
一位名为 unwind 的开发者在 17 Bit 库里找到了自己写的游戏《No Man's Land》，读着几十年前的 readme 觉得很奇妙。另一位开发者 urbandw311er 也在库里发现了自己卖出的第一款软件。有用户感叹 Fred Fish 那种专注、有原则的策展行为对社区影响深远，而在今天的平台经济里，这类角色几乎不可能存在。
这个两年长期支持版本带来了节点驱动的物理系统，新的 XPBD 解算器节点可以处理布料和头发模拟，支持钉扎、撕裂和自定义力场。几何节点还引入了音频驱动动画：Sample Sound Frequencies 节点直接读入声音文件并输出频率数据。在线资产库内置了数十种参数化材质、HDR 背景和几何节点方案，下载即可用，Blender 安装包体积保持不变。
渲染方面，Cycles 新增纹理缓存和薄壁模式，EEVEE 则在实例场景中提速两倍，屏幕空间光线追踪有所改进。合成器新增 35 个节点，可以直接在时间线上运行节点树。
社区里一片赞叹，一位从 3ds Max 转过来的用户觉得 Blender 正在一步步接近 Houdini。但陡峭的学习曲线和不够直观的 UI 仍然是高频槽点，尤其是没有中键或小键盘的情况。在大工作室，Autodesk Maya 和 3ds Max 仍占主导，Blender 缺乏稳定的 C++ API 和 Qt 支持，很难被纳入现有管线。多位用户呼吁给 Blender 捐款，并提到 Apple Pay 降低了支付的心理门槛。
西蒙·威利森通过 strings 命令在自己的机器上找到了 Bun v1.4.0 的痕迹，而当时 Bun 最新正式版还是 v1.3.14。进一步扫描发现了 563 个 Rust 源文件，证实 Claude Code 已经在用 Rust 版 Bun。Jarred Sumner 早前写道，这个版本让 Linux 启动速度提升 10%，但“几乎没人注意到——无聊挺好”。
社区最大的困惑在于：一个终端界面 (TUI) 为什么非要用 JavaScript/React 来写？有人直说“疯了”，认为用 ncurses 或原生语言早就解决性能问题了。但另一面，技术选型是商业成功后的结果——快速出产品、团队技能栈、AI 模型在 JS 上训练得更好，都是现实理由。Claude Code 确实存在渲染闪烁和 3GB 内存占用的问题，但用户依然因为模型强大而接受这些缺点。
Bun 从 Zig 转向 Rust，核心动机是内存安全而非性能。Zig 手动管理生命周期带来大量 bug，而 Rust 编译器更适合检查 AI 生成代码的正确性。Anthropic 收购 Bun，则是为了消除一个每月赚数十亿的产品对小型创业公司项目的依赖。Zig 创始人公开批评这次重写“破坏了社区”，而 Jarred 在合并后批量关闭了所有 Zig 相关的旧 issue，也引发了忠诚度争议。但对大多数用户来说，底层语言确实透明——只要产品能用就行。
OpenAI 在一次提交中将 Codex 模型上下文从 372k tokens 降到 272k。自动压缩机制会在剩余 10%–20% 上下文时随机触发，实际可用长度只有 272k 的八折左右。压缩后模型常出现幻觉，需要反复重新读取文件，形成“读到 15% → 压缩 → 再读到 15%”的死循环。有用户因此把主要消费转向了 Claude Code。
一些开发者并不依赖超长上下文，通过把计划文档写入 .md 文件、使用子代理分层执行任务，或借助 context-bonsai 等第三方工具来管理上下文。还有人指出，模型在超过 150k–200k tokens 时性能会明显下降，主动控制上下文反而更稳定。OpenAI 员工在 X 上表示这次减少是临时措施，近期会恢复。同一个 PR 还在系统提示中加入了防止破坏工作区根目录的指令，疑似与之前 Codex 误删用户文件夹的 bug 有关。
Chip Weinberger 发布的 Jamcorder 能自动记录钢琴演奏，这一年半已卖出 2500 台。他的硬件清单短得惊人：PCB 只有 25 个元件，装配只要一颗螺丝，外壳注塑模没有滑块。他刻意砍掉了低电量检测、电源按钮甚至 USB-C 来保持简单。真正耗时的反而是固件、App 和制造工具，加起来大约 20 万行代码，花了三年多。
社区提醒道，这种“简单”是产品选择的结果。设备基于的 ESP32-S3-WROOM 模块已通过 FCC 预认证，但整机仍需自认证，费用约 5000 美元。真正可怕的环节在规模化——从 2500 台到 25 万台，供应链、认证、返修和库存管理会指数级变难。有工程师曾在疫情期间因芯片短缺不得不重新设计整个产品，还有人干脆买断了即将停产的元器件的全球库存。
作者总结的经验包括：物料清单尽量短、毛利率不低于 70%、通过 Alibaba 找中国组装厂、使用 STSAFE 芯片防伪、自己掌控最终 QA 并把包装做小。他强调这些法则适用于他这种刻意压低复杂度的场景。一位用户分享，Jamcorder 确实践行了即插即用的承诺，连 App 将来可能消失的担忧也因设备直接将 MIDI 文件存进 SD 卡而消除。
女：Hello 大家好，欢迎收听 Agili 的 Hacker Podcast，我是莓莓。
男：大家好，我是阿迪。
女：今天咱们聊的东西挺有意思的，从那个让你从沙发上直接往电视投屏的命令行工具，到纽约出租房的 AI 假图片，再到一个卖了 2500 台的钢琴小硬件。阿迪，我记得你上次说发现身边好多程序员都开始自己写库了，你用一个什么转录的东西，结果发现不够好，然后就自己从头写了一个？
男：对，我最近确实在关注一个叫 transcribe.cpp 的库。这个库的作者就是 Handy 那个语音转文字应用的维护者。他自己说的，实在是受够了市面上那些方案。
女：他试了哪些方案？
男：他试了 whisper.cpp，试了 ONNX，还有苹果的 MLX。ONNX 在 CPU 上跑得不错，但 GPU 加速很糟糕。MLX 是苹果专属。whisper.cpp 支持的模型有限，而且他不太信得过那个数值验证，就是跑出来的结果跟参考实现对不上，这种偏差在语音识别里会直接反应在词错误率上。
女：就是转出来的文字总有那么几个词不对，逼死强迫症那种感觉。
男：对，所以他干脆自己写了一个。现在这个库支持 16 个 ASR 模型家族，六十多个具体模型，通过 Vulkan、Metal、CUDA 这些做 GPU 加速。它最让人放心的一点是，每个模型都跟参考实现做过数值对齐，而且把词错误率测试的结果都公开在 Hugging Face 上。
女：自己做数值验证这件事听起来就很工程师，像是在说“我不管你的基准测试跑分多高，我就一行行对数，看结果是不是完全一样”。
男：就是这个意思。社区里很多人问，能不能拿它来做说话人分离，比如开会时分辨谁说了哪句话。作者回复说这个功能正在开发，他已经在移植 NVIDIA 的 Sortformer 模型了。
女：那这算是录音笔那种“录完再转”的方案，还是能边说话边打字？
男：它支持流式转录。社区里有个很具体的需求，就是“持续实时转录”——用户希望边说话，光标边在文档里打字，而不是等录音结束再一次性粘贴。
女：这不就是 Dragon NaturallySpeaking 十几年前干的事吗？
男：评论区里也有人提到这个。有趣的是，作者说 Handy 这个应用其实可以修改成那样，因为库本身已经支持流式输出了，只是 Handy 还没接入光标插入的功能。
女：听起来这是个很克制的起步版本，作者自己说是 v0.1.0，欢迎大家提 issue。
男：对，而且整篇文章是他自己手写的，没有用 AI 生成。他说项目受 Mozilla AI 的 BiR 计划资助，还用了 Modal 做词错误率测试，Blacksmith 跑 CI/CD，Hugging Face 做存储。
女：说到模型，最近阿里巴巴宣布 Qwen 3.8 要开源权重了，总参数 2.4 万亿。你还记得之前咱们聊过的 Moonshot AI 吗？
男：对，Moonshot 也说要开源 Kimi K3，参数 2.8 万亿。Hacker News 上大家普遍觉得这不是巧合，是中国 AI 公司之间竞争加剧了。
女：有种说法是，他们这样做是为了让模型变成大宗商品，削弱美国那些前沿实验室的利润空间。
男：还有另一种观点，说放权重出来可以绕过美国的 API 封锁。不管什么原因，有些开发者已经在期待小尺寸模型了，就像之前 Qwen 3.5 和 3.6 那样，出一些 35B 或者 122B 的版本，方便在本地跑。
女：说到本地跑，你上次提了一个叫 Castor 的命令行工具，是解决投屏问题的？
男：对。很多人家里有这种情况：智能电视本身不支持直接播网页里的视频，用手机屏幕镜像又延迟高、画质掉得厉害。Castor 的做法是，启动一个无界面的 Chrome，监听网络流量，自动找到网页里的视频流，转码后通过 DLNA 协议投到电视上。
女：它还能自己加字幕？
男：对，它能调用 Whisper 模型自动生成字幕，然后烧录到视频里。
女：我猜这个工具会踩到一些灰色地带。
男：作者说它是通用投射工具，不托管任何内容，也不破解 DRM。但默认的 config.yaml 里包含了一些典型的盗版流媒体网站地址。评论区有人觉得这很难撇清。还有一个细节，提交记录显示大量代码是由 Claude 辅助生成的，这也引发了一些关于 AI 写代码和项目合法性的讨论。
女：有个更轻量的替代方案，叫 TV Explorer 是吧？
男：对，一个纯静态网站，从公开的 GitHub 频道列表里获取超过一万条免费频道的 HLS 流，直接通过 video 标签播放，没有广告和跟踪。有评论形容它“接近模拟电视的换台体验”。
女：换台快，没广告，感觉像是回到小时候那个电视。
男：不过有些频道有区域限制，部分 iOS 用户也遇到了加载问题。Castor 这边只支持 DLNA 设备，Chromecast 支持还是实验性的，Roku 完全不支持。
女：说到电视屏幕，纽约最近出了个事，市长发了一份“租房骗局报告”。
男：是 Zohran Mamdani。他要求房东和经纪人在房源里披露，有没有用 AI 生成或编辑过图片。
女：在 StreetEasy 上看过房的应该都见过那种 AI 虚拟布置图，把一张根本放不下去的沙发强行塞进一个小单间，空间看起来大了至少十平米。
男：有个租户用 LiDAR 测了自己的房间，发现经纪人声称的 650 平方英尺，实际只有 505 平方英尺。评论区很多人呼吁，应该直接要求所有房源标注真实面积，像荷兰和德国那样标准化测量。
女：但仅靠披露够吗？Meta 早就要求标注 AI 生成的图片，大家看到的依然是铺天盖地的垃圾。
男：有评论说，以后所有纽约房源图都会加上一条“AI 增强”的免责声明，就像每个网站都有 cookie 警告一样，看多了就没人理了。
女：从广告法的角度看，有评论提到 1960 年代 Campbell 汤因为用弹珠让汤看起来更满，被判虚假广告。AI 图片刻意放大房间、缩小家具，本质上一样。
男：关键是“是否虚构了不存在的东西”。基础的曝光和色彩调整大家能接受，但凭空造出墙、改变房间结构，这种就必须要管。
女：但这种管制能改变根本问题吗？有个人说了一句挺扎心的话：在房东市场里，标注再多也改变不了租户别无选择的现实。
男：嗯。我们再往底层走一点——乘法。你知道 Python 做整数乘法的时候，内部会根据数字大小自动切换算法吗？
女：我只知道乘法口诀表。
男：1960 年，一个 23 岁的苏联学生叫 Anatoly Karatsuba，推翻了导师 Kolmogorov 的猜想。Kolmogorov 当时在研讨会上断言，两个 n 位数相乘的运算量不可能低于 O(n²)。一周后，Karatsuba 带了一个新算法回去，证明他错了。
女：他做了什么？
男：核心想法是用便宜的加法替换昂贵的乘法。比如 12 乘以 34，传统方法需要四次个位数乘法。Karatsuba 的方法是先算两头的乘积，再通过几次加减得到中间项，只用三次乘法。对于更大的数，可以反复对半拆，复杂度降到 O(n 的 1.585 次方)。
女：这个算法后来用在哪里了？
男：Python 的整数乘法就用它。大概 630 位以下用长乘法，以上就切到 Karatsuba。2019 年有人提出了一个更快的算法，复杂度 O(n 乘以 log n)，几乎和加法一样快。但它是所谓的“银河算法”——只有在数字大到离谱的时候才有优势，实际根本没法用。
女：理论很美，落地遥远。
男：对。一位 PostgreSQL 开发者分享过一个故事，他花了几百个小时调整 Karatsuba 的切换阈值，最后换成了一种更简单的方法——把基数从 10000 改成 100000000，用 O(N/2)² 的代价换回了两倍的速度。
女：这就像明明在优化算法，最后发现改一个配置就搞定了一样。
男：数学里忽略的进位传播，在硬件乘法器里却是瓶颈。理论界普遍推测 O(n 乘以 log n) 就是极限，但还没被证明。Karatsuba 当时也是用一周推翻了共识，所以没人敢打包票。
女：从数学到回忆一下，有人建了一个 Amiga 的免费软件档案馆，收录了超过 18600 个软件。
男：Amiga Freeware Archive。这些软件主要来自公共领域库和演示场景，时间跨度从八十年代到九十年代。里面有 Fred Fish 系列，那个程序员从 1986 年就开始整理，是 Amiga 在互联网普及前最广泛传播的免费软件合集。
女：有开发者发现自己的作品出现在里面了。一个叫 unwind 的人找到了自己写的游戏《No Man's Land》，说读自己当年的 readme 感觉很奇怪。
男：另一个人也在库里找到了自己卖出的第一款软件，但没透露是什么。有人评价 Fred Fish 的贡献，说那种专注、有原则的策展行为，今天很多平台如果有人能做到，可能会被彻底改变——但这条路很难商业化。
女：现在有什么软件继承了那种精神吗？
男：说到这个，Blender 5.2 LTS 刚发布了，两年长期支持。这次核心更新是节点驱动的物理系统，加了 XPBD 解算器节点，做布料和头发模拟，支持撕裂和自定义力场。
女：我听说 Blender 现在还能让声音驱动动画。
男：对，有个 Sample Sound Frequencies 节点，加载声音文件直接输出频率数据。几何节点里还新增了图像纹理缓存，能大幅降低显存占用。渲染方面 Cycles 加了纹理缓存和薄壁模式，EEVEE 在实例场景里快了 2 倍。
女：社区对 Blender 的评价很两极吧？
男：有人称它为“令人畏惧的优秀项目”，从 3ds Max 转来的用户说节点物理系统终于补齐了短板，感觉在一步步接近 Houdini。但也有很多人抱怨学习曲线陡，UI 还是不直观，尤其在没中键、没数字小键盘的鼠标上。行业里 Maya 和 Max 还是主导，Blender 缺稳定的 C++ API，大型工作室很难把它纳入管线。但在小工作室和独立创作者里渗透率一直在涨。
女：你之前提到那个卖了 2500 台的钢琴小硬件？
男：Jamcorder，自动录 MIDI 的设备。作者 Chip Weinberger 以前是做软件的，本以为硬件会特别难，结果发现硬件部分反而一帆风顺。PCB 只有 25 个元件，装配只用一颗螺丝。他故意砍掉了低电量检测、电源按钮、甚至 USB-C 来保持简单。
女：那什么部分难？
男：软件。固件、App 加上制造工具，加起来将近 20 万行代码，花了三年多时间。他总结了十条经验，比如 BOM 要简单，保持至少 70% 的毛利率，通过阿里巴巴找中国组装厂，用 STSAFE 芯片做防伪，每次生产前索要样品。
女：评论区有人提醒，这个硬件复杂度基本等于“Hello World”，经验不能推广到多 PCB 或高速信号的产品上。
男：作者自己也同意这个结论只适用于他这种刻意简化设计的场景。有用户分享说，Jamcorder 即插即用，自动录音，App 体验很流畅，设备直接把 MIDI 存在 SD 卡上，就算以后 App 不维护了也不怕。
女：最后我们聊一个有点八卦的事。Anthropic 的 Claude Code，那个命令行 AI 工具，最近被发现悄悄用上了 Rust 移植的 Bun。
男：对，西蒙·威利森在检查自己电脑上的 Claude Code 时，通过 strings 命令找到了内嵌的 Bun v1.4.0，而 Bun 当时最新正式版才 1.3.14，也就是说它用的是未发布的预览版。他用 TypeScript 写了一段脚本，通过环境变量注入，让 claude --version 输出内嵌的 Bun 版本号来验证。
女：评论区有个灵魂拷问：一个 TUI 为什么非要用 JavaScript 和 React 来写？
男：有人直呼疯了，说用 ncurses 早解决了。但另一方说得也有道理，早期快速推产品，团队熟悉 JS，而且 AI 模型在 JS 上训练得更好。Claude Code 确实有渲染闪烁、滚动卡顿、内存占用飙到 3GB 这些问题，但用户还是因为模型能力强而忍了。
女：那 Bun 从 Zig 转 Rust 是怎么回事？
男：有人质疑，既然 AI 能写代码，为什么 Anthropic 不直接用 Rust 重写 Claude Code，反而花几十万美元让 AI 把 Bun 从 Zig 翻译成 Rust？一个解释是，Bun 改 Rust 的主要动机是内存安全。Zig 手动管理生命周期导致大量 bug，Rust 的编译器约束更适合 AI 生成正确代码。
女：Anthropic 收购 Bun 是出于供应链风险？
男：对，Claude Code 月入数十亿，过度依赖一个小型创业公司的项目，买下来是为了消除供应链风险。选 Rust 而不是 Zig，也降低了语言生态的不确定性，因为 Zig 还没到 1.0，开发人员稀缺。不过 Zig 创始人公开批评了这次重写，说“破坏了社区”。Bun 的公开仓库在合并后批量关闭了所有与 Zig 相关的旧 issue，理由“不再相关”，也引发了一些忠诚度危机。
女：OpenAI 那边也有个动作，Codex 的上下文窗口从 372k tokens 减到了 272k。
男：提交就是一个简单的 PR，改了 models.json。但实际影响很大。压缩机制会在上下文还剩 10% 到 20% 的时候随机触发，实际可用上下文只有 272k 的 80% 左右。压缩后模型容易产生幻觉，需要重新读文件，形成死循环。有用户因此把主要支出从 OpenAI 转到了 Anthropic，因为 Claude 提供 1M 上下文窗口。
女：但我看有评论说，上下文大小不是关键问题。
男：对，有些人通过写详细设计文档、用子代理分层执行任务来控制上下文。还有人指出模型在上下文超过 150k 到 200k 时性能会显著下降，所以主动控制上下文不超过 250k 反而是好习惯。OpenAI 员工在 X 上回复说这次是临时措施，近期会恢复。
女：那个 PR 还偷偷加了个指令，说“在执行破坏性操作前确保目标不是 $HOME 或者 /”。
男：对，估计是修复之前 Codex 意外删除用户目录的 bug。整体来看，这个变动暴露了不同用户对上下文长度的依赖差异。处理大型重构的人感觉直接受影响，习惯用文档和子代理拆分任务的人就觉得还好。
女：好了，今天聊了不少。那个 Amiga 档案馆里一张张磁盘，那个钢琴小硬件深夜自己录下的即兴片段，还有 Karatsuba 用一周推翻导师猜想的故事，其实都在说同一件事——把东西做出来，有时就是把东西做出来而已。
男：对，有时候只是需要一个能信任的转录库，有时候只是想让电视不再缓冲。
女：谢谢收听今天的节目。你可以在泛用型播客客户端里搜索并订阅 Agili 的 Hacker Podcast，咱们下期再见。
男：再见。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。