Godot 引擎迎来 Apple Vision Pro 官方原生支持
Godot 引擎正迎来 Apple Vision Pro 的原生支持，由 Apple 官方 visionOS 工程团队成员直接贡献。首个 Pull Request 已提交，旨在实现平面窗口运行，并为后续沉浸式体验奠定基础。这一官方介入预示着 Godot 在空间计算领域发展的巨大潜力。
这个重磅消息来自 Godot 引擎的 Pull Request #105628，标题为“Native visionOS platform support”。提交者 rsanchezsaez 明确表示他们来自 Apple 的 visionOS 团队，并很高兴能与 Godot 社区合作。这标志着平台拥有者 Apple 首次直接向 Godot 贡献核心代码，意义非凡。
首个 PR 的核心内容
这个原生支持工作被规划为三个渐进的 PR，当前提交的 #105628 是第一步，主要完成了以下几点：
- 添加原生 visionOS 平台： 基于现有的 iOS 平台，创建了一个新的 visionOS 平台目标。
- 代码重用与重构： 为了最大化 iOS 和 visionOS 之间的代码共享，引入了新的
drivers/apple_embedded文件夹存放共用代码，并重构了原有 iOS 平台代码。 - Metal 渲染支持： visionOS 不支持 OpenGL，因此原生支持完全依赖 Godot 的 Metal 渲染驱动。
- 基础功能： 这个 PR 旨在让现有 Godot 游戏能够以平面窗口的形式在 visionOS 上原生运行，并为后续的沉浸式体验（Immersive experiences）奠定基础。
后续计划与当前局限
后续的两个 PR 将逐步完善功能，包括引入 Swift 文件的编译和链接能力（visionOS 的 SwiftUI 应用生命周期需要 Swift），并最终引入专门的 Vision Pro VR 插件以实现完整的沉浸式支持。
提交者也坦诚了当前 PR 的一些局限性，例如需要社区测试插件嵌入、Archive/IPA 导出和 One-Click-Deploy 功能尚未完全测试或工作、DPI 指标硬编码、visionOS 图标 Asset Catalog 构建未实现，以及需要更好的 visionOS 平台 SVG logo 等。
社区热议与技术探讨
评论区对这个官方贡献表现出极大热情，同时也进行了深入的技术讨论。
- 维护成本： 社区成员提出了增加新平台带来的长期维护开销（CI、导出模板、发布流程），作者回应称大部分是 iOS 重构，实际新增代码量不大。
- 技术细节与代码审查： 社区成员深入代码，提出了简化条件编译、修正构建脚本、移除不必要依赖、MetalFX 支持等具体改进建议。关于最低 visionOS 版本是否应提升到 2.0 也引发了讨论。
- 渲染方式的讨论： 有评论询问 Apple 的参与是否会带来更好的 Metal 支持或性能提升。关于 foveation（注视点渲染）的讨论也出现，作者澄清其贡献是直接 Metal 渲染，与基于 RealityKit 的社区项目不同。
- 作者的积极互动： 提交者
rsanchezsaez在评论区积极解答疑问，接受建议并更新代码，展现了良好的协作姿态。
总的来说，这个 PR 是 Godot 引擎迈向空间计算平台的重要一步，由 Apple 亲自推动，为 Godot 在 visionOS 生态中的发展带来了巨大潜力。
SolidJS：高性能响应式 UI 库的崛起
SolidJS 是一个用于构建用户界面的 JavaScript 库，其核心理念是提供简单且高性能的响应式能力。它凭借细粒度响应式系统在性能基准测试中表现出色，同时提供了类似 React 函数式组件和 Hooks 的开发体验。社区讨论高度赞扬其性能优势，但也对其生态系统成熟度表示担忧。
SolidJS 的两大卖点是性能卓越和开发体验简单。在性能方面，它在 UI 速度和内存使用等基准测试中表现出色，甚至超越了 React、Vue、Svelte 等流行框架。这种性能提升的关键在于它不使用虚拟 DOM，而是将 JSX 编译成真实的 DOM 节点，响应式更新直接针对受状态变化影响的特定 DOM 部分进行，实现更高效、更精准的更新。
开发体验：借鉴与创新
在开发体验方面，SolidJS 借鉴了 React 和 Knockout 的思想，与 React 函数式组件和 Hooks 在哲学上相似，例如单向数据流、读写分离和不可变接口。然而，SolidJS 的更新模型更简单，没有 React Hooks 的规则限制。组件只在首次渲染时执行一次，而 Hooks 和绑定只在其依赖项更新时执行。它被描述为强大（可组合的响应式原语、JSX 灵活性）、实用（量身定制的 API）和高效（符合人体工程学和熟悉感）。它体积小巧（7kb 压缩后），支持 TypeScript，并集成了 Suspense、SSR、流式渲染等现代特性。
社区热议：性能、生态与未来
评论区对 SolidJS 展开了热烈讨论。许多从 React 迁移过来的开发者对其性能和直观的状态管理表示喜爱，认为其代码更简单、更快，是自 React 以来前端领域最好的事物之一。
然而，生态系统，特别是高质量组件库的成熟度，是反复出现的担忧点。评论者指出，对于需要复杂组件的企业级应用，SolidJS 的生态尚显不足，可能需要开发者自己构建或封装。这被认为是相比 React 的主要劣势。
评论中充斥着 SolidJS 与 React 的比较。许多人认为 React 过于根深蒂固且积累了太多“陷阱”，对其 Server Components 的发展方向也表示不满。同时，也有评论指出 React 的性能问题有时源于不当使用，而非框架固有缺陷。
SolidJS 即将到来的 2.0 版本及其可能引入的“惰性”（laziness）概念引起了一些现有用户的担忧，担心会破坏其直观的响应式模型。SolidJS 创建者 Ryan Carniato 亲自回应了这些担忧。
关于 JSX 本身的哲学辩论也贯穿其中，支持者认为 JSX 结合 TypeScript 是编写 UI 的优越方式，反对者则认为它混合了关注点，呼吁回归更原生的 Web 技术。
总的来说，SolidJS 在性能和核心开发体验上赢得了许多青睐，被视为 React 的有力替代者，但其生态系统的成熟度仍是挑战。
《GTA 圣安地列斯》20 年老 Bug 在 Windows 11 24H2 中重现
在 Windows 11 24H2 版本更新后，《侠盗猎车手：圣安地列斯》（GTA San Andreas）中一个长达 20 年的 Bug 突然显现，导致 Skimmer 水上飞机消失或行为异常。知名 GTA 模组开发者 Silent 深入调查发现，问题源于游戏代码依赖未初始化的变量，而 Windows 11 24H2 中操作系统内部函数栈空间使用的微小变化偶然暴露了这一缺陷。这并非 Windows 的 Bug，而是游戏代码依赖未定义行为的结果。
Silent 的文章详细调查了这个 Bug。他发现飞机异常行为（飞向高空）与一个巨大的、不正常的螺旋桨速度值有关，这又与飞机高度计算相关。追溯发现，问题定位到游戏加载车辆模型时，Skimmer 模型的边界框（bounding box）的 Z 坐标被一个巨大的负值损坏。边界框在文件加载时是正确的，但在后续的 SetupSuspensionLines 函数中被修改。
Bug 根源：未初始化变量与栈空间变化
进一步调查发现，Skimmer 在 vehicles.ide 文件中的定义缺少了定义前后轮尺寸的参数。游戏加载车辆数据的 CFileLoader::LoadVehicleObject 函数使用 sscanf 解析文本行，但它假设所有参数都存在，且没有检查 sscanf 的返回值。对于 Skimmer 这样缺少参数的条目，用于存储车轮尺寸的局部变量就保持了未初始化状态。
为什么这个 Bug 之前没有出现？Silent 发现，在 Windows 11 24H2 之前，由于函数调用栈的布局和使用习惯，这些未初始化的局部变量恰好保留了之前加载的车辆（紧邻 Skimmer 定义的 Topfun 车辆）的车轮尺寸值（0.7）。游戏无意中依赖了这个“巧合”。然而，在 Windows 11 24H2 中，操作系统内部的 Critical Section 对象实现变化，导致像 fgets 这样的函数在内部调用 LeaveCriticalSection 时使用了更多的栈空间。这个额外的栈空间使用恰好覆盖了之前未初始化的车轮尺寸变量所在的内存区域，将其中的 0.7 值替换成了随机的垃圾数据。这些垃圾数据被用于后续计算，最终导致了 Skimmer 的边界框损坏和异常行为。
作者强调，这并非 Windows 11 24H2 的 Bug，而是游戏代码依赖了操作系统内部实现细节（栈布局）这一未定义行为（Undefined Behavior, UB）。操作系统可以自由改变这些内部细节。这个 Bug 在游戏的 Xbox 版本和后续基于 Xbox 代码库的版本（如 Steam、RGL、决定版）中已被修复，通过为缺失参数提供默认值（1.0）。作者在他的 SilentPatch 中也实现了类似的修复。
社区讨论：未定义行为、兼容性与游戏开发
评论区对这篇技术深度文章给予高度评价，许多人将其与微软 Raymond Chen 等传奇人物的深度技术分析相提并论。
讨论焦点集中在：
- 未定义行为 (UB) 的危害： 许多评论员强调了 C/C++ 中 UB 的危险性，这个 Bug 是一个典型案例。这引发了关于 Hyrum's Law（用户会依赖系统的所有可观察行为）的讨论。
- 防御性编程与现代语言： 有评论指出，如果开发者检查了
sscanf返回值或初始化了变量，Bug 就不会发生。同时，许多人提到现代语言（如 Rust）如何通过设计防止这类 UB。 - 操作系统兼容性与内部变化： 评论员对 Windows 11 24H2 中 Critical Section 实现变化如何影响栈空间表示好奇，并回忆起 Windows 历史上的兼容性问题和微软的兼容性垫片（shims）。
- 游戏开发实践与权衡： 关于游戏数据文件格式选择（文本 vs. 二进制）以及 Rockstar 当年手写解析器的讨论也出现了。有人认为这是时间压力下的“够用就好”代码。
- 成功与技术质量： 一些评论员反思了《GTA 圣安地列斯》这样一款底层有 Bug 的游戏如何依然取得巨大成功，引发了关于“艺术品”与“商品”、“技术完美”与“用户体验”的讨论。
总的来说，这篇 Bug 分析文章不仅解决了具体问题，更提供了一个生动的案例，展示了 UB 的隐蔽性、操作系统兼容性的复杂性以及老代码在新的环境下暴露缺陷的现象。
MinC：在 Windows 上运行 OpenBSD 工具的尝试
MinC 是一个基于 OpenBSD 操作系统的 Windows Unix 模拟器项目，旨在为职业教育学生提供无需虚拟机的 Unix 命令行学习环境。它声称以单文件 EXE 形式提供 OpenBSD 6.1 的核心工具集，并在 Windows 机器上以“原生速度”运行。社区讨论围绕其技术实现、与现有工具（如 Cygwin 和 WSL）的比较以及用 OpenBSD 教 Linux 的教育方法展开。
文章详细介绍了 MinC 的特点。安装非常简单，只需下载并运行一个 20MB 的 .exe 文件。它包含了 OpenBSD 6.1 中的大量标准 Unix 工具，涵盖文件操作、编辑、压缩、网络和部分开发工具。不过，服务和守护进程（如 Apache, Sendmail, sshd）目前尚未提供，但计划在未来加入。MinC 可以集成到 Visual Studio Code 中作为终端使用，并提供了单独的构建工具包用于编译代码。
社区热议：技术实现、竞品对比与教育定位
评论区围绕 MinC 的技术实现、与现有工具的比较以及其教育目的展开了热烈讨论。
- 技术实现与定义： 许多评论者对 MinC 被描述为“微小内核”或“运行在单独内核空间”的说法表示困惑和质疑，认为它更像是一个用户模式的兼容层，类似于 Cygwin。作者在回复中试图解释其底层机制，但社区仍在探讨其与 User-mode Linux 或 CoLinux 的区别。
- 与现有工具的比较（Cygwin, WSL, MSYS2）： 这是最集中的讨论点。许多人质疑在有 WSL 的情况下为何需要 MinC。支持 MinC 的观点包括：WSL 需要虚拟化、WSL2 是虚拟机有开销、某些安全策略限制 WSL 安装、MinC 安装更简单。与 Cygwin 相比，MinC 基于 OpenBSD 工具和 BSD libc，而 Cygwin 基于 GNU 工具和 Newlib。作者提到 Cygwin 在文件权限和卸载方面的问题是开发 MinC 的动机之一。MSYS2 也被推荐为另一种选择。
- 教育目的与“教 Linux 用 OpenBSD”： 文章提到用 MinC 教学生学习“Linux”，但它基于 OpenBSD，这引起了困惑。评论者指出 OpenBSD 和 Linux 在某些方面存在差异。作者回应说，教学起点是基础的 Unix 概念和命令行工具，这些在两者之间有很多共通之处，可以作为学习更具体 Linux 知识的铺垫。
- 兼容性与历史 Windows 版本： 文章最初声称支持除 Win95/98 外的所有 Windows 版本，后更正为“Windows XP 或更高版本”，引发了关于 Windows 2000 的怀旧讨论。
总的来说，MinC 被视为一个有趣且具有挑战性的项目。虽然其教育方法和与现有工具的定位受到一些质疑，但其单文件安装、对旧 Windows 版本的潜在支持以及作为 Cygwin/WSL 之外的另一种选择，仍然吸引了部分开发者的兴趣。
欧盟资助 42 个开源项目，旨在增强数字主权
欧盟通过 NLnet 基金会旗下的 NGI Zero Commons Fund 向 42 个自由开源项目提供资金支持。这是 NGI Zero 项目有史以来规模最大的一次征集，其核心目标是支持那些致力于数字公共领域、为全人类福祉发明和改进技术的项目，从而“夺回互联网的公共属性”，使其服务于人而非利润。
这次资助的项目涵盖了非常广泛的技术领域，体现了基金会支持多样化创新的决心。
资助项目概览：涵盖广泛领域
在硬件和底层技术方面，资助了 MNT Reform Touch 开放硬件平板电脑、旨在创建超低功耗太阳能主板的 Solar FemtoTX 项目，以及目标在 FPGA 上本地运行开源大型语言模型的 LLM2FPGA 项目。下一代 Linux 文件系统 bcachefs 也获得了资助。
在隐私、教育和用户应用方面，LiberaForms 是一个提供端到端加密的表单解决方案，将利用资金改进教育用途。ClassQuiz 允许学校进行无隐私顾虑的测验。还有一些项目专注于增强现实（XR）领域的教育和创意工具，如 Federating pedagogical immersive experiences 和 Flock XR。KDE Plasma Gestures 项目旨在为 Plasma 桌面添加多点触控和手势功能。
其他服务和应用包括播客制作软件 Podlibre、去中心化视频平台 PeerTube 的两个相关项目（机构使用便利化和直播聊天增强）、欧洲公共交通实时路线规划项目 MOTIS、数字服务条款公开跟踪项目 Open Terms Archive，以及实时协作笔记本应用 Livebook。
文章强调，这只是获得资助的 42 个项目中的一小部分示例，完整列表展示了更多在可信硬件、操作系统、固件、虚拟化、测量分析、去中心化解决方案、数据与人工智能、服务应用等领域的创新努力。
社区讨论：分散资助能否对抗巨头？
评论区的讨论非常热烈，核心焦点在于这些分散的开源项目资助，能否真正对抗大型科技公司（特别是美国的微软和苹果）在操作系统和集成系统领域的强大主导地位。
一种主要观点认为，虽然资助开源项目是好事，但未能解决最关键问题：缺乏一个能够提供完整集成系统（硬件、软件、生态系统）的“系统供应商”。评论者认为，要真正限制对美国科技公司的依赖，欧盟需要创建一个类似 Airbus 或国防承包商模式的大型实体，来构建和支持一个完整的、有竞争力的开源技术栈。有人提出了建立一个欧洲软件机构的设想。
然而，另一种观点对此表示怀疑甚至反对，认为集中规划可能难以在市场上竞争，并认为依赖单一供应商本身就是问题。他们认为，一个互操作、模块化的系统才是更健康的选择，即使它需要更多的集成工作，政府机构有资源进行这种集成。
关于开源生态系统是否能提供替代方案，评论者存在分歧。有人指出 Linux 发行版已提供企业级支持，问题在于整合和推广。但也有人强调，开源生态系统在某些关键应用领域（如办公套件、专业设计软件）与微软和 Adobe 的产品仍有差距，构成迁移障碍。不过，也有评论指出文章中提到的 Typst、Paged.js 等项目正尝试弥补这些差距。
总的来说，评论区的讨论揭示了欧洲在追求数字主权时面临的复杂挑战：如何在不复制现有巨头模式、同时又能有效整合分散的开源力量之间找到平衡。
CSS Hell：献给前端开发者的“CSS 地狱”解谜游戏
"CSS Hell" 是一款基于 Web 的 CSS 解谜游戏，被设计成对那些轻视 CSS 的开发者的“惩罚”。游戏包含 15 个谜题，玩家需要通过向页面元素添加有限的 CSS 属性，使一个“peg”元素与对应的“hole”元素重叠。游戏限制了可用的属性，并禁止使用浏览器开发者工具，旨在挑战玩家对 CSS 布局和定位的理解。
游戏的核心玩法是解决 15 个谜题。每个谜题都要求玩家通过添加 CSS 属性来使一个元素覆盖另一个元素。关键在于限制：通常每个元素只能添加一两个属性，有些元素被锁定无法修改，并且某些属性（如 transform 或 animation）在游戏 UI 中被禁用。游戏鼓励玩家查阅 MDN CSS 参考，并提供提示，GitHub 上也有解决方案。它被设计为纯粹通过在提供的输入框中添加 CSS 来解决，无需使用浏览器开发者工具。
社区反馈：创意与争议并存
Hacker News 社区对这个项目反应热烈，既有对概念的赞赏，也有对执行的显著不满。
一个主要的争议点是游戏关于添加 CSS 的规则，这与 CSS 在浏览器中的实际工作方式不符。许多用户感到困惑和沮丧，他们无法像正常 CSS 那样简单地添加规则来覆盖现有规则，游戏 UI 经常静默失败或不应用规则，导致玩家认为网站有问题。这种缺乏反馈是普遍抱怨，使得谜题感觉更像是在猜测游戏期望的特定非标准规则。一些用户不得不使用浏览器开发者工具来应用他们认为应该工作的 CSS 规则，这虽然解决了谜题，但感觉像是绕过了游戏机制。
另一个热点是网站决定阻止小屏幕用户访问，并显示一条消息称游戏不是为移动设备设计的，暗示不应在手机上编码。这引发了关于响应式设计和在移动设备上进行部分编码可行性的辩论，许多用户认为这种做法“对用户不友好”。
除了这些核心不满，评论者还分享了其他观察。一些人觉得谜题确实很难但欣赏挑战，特别是约束条件。游戏前提的幽默感引起了许多与 CSS 搏斗过的开发者的共鸣。关于游戏胜利条件（只需重叠，无需完美对齐）的讨论也出现了，这并非对所有人都显而易见。特定的 Bug 或怪癖也被指出，例如某些属性不如预期工作或游戏内的文本编辑功能笨拙。讨论还触及了 CSS 与其他语言（如 C++）的感知难度，以及使用 Tailwind 或 JSX 等抽象来管理样式的现代趋势。
总的来说，"CSS Hell" 似乎是一个两极分化的体验：一个巧妙的概念，触及了开发者在 CSS 上的常见痛点，但其在规则应用和移动访问方面的具体实现选择，在带来挑战的同时也引发了显著的挫败感。
苹果与 Meta 因违反欧盟法律被处以数百万欧元罚款
苹果和 Meta 因违反欧盟法律被处以数百万欧元的罚款。这些罚款是欧盟持续加强对大型科技公司监管的一部分，具体涉及苹果在应用商店生态系统中的行为以及 Meta 的数据使用政策。欧盟旨在通过这些措施确保这些“守门人”企业遵守数字市场规则，促进更公平的竞争环境，并保护用户隐私和选择权。
文章指出，这些罚款是监管机构在评估了公司的具体行为后做出的决定。苹果的罚款可能与其在应用商店中对支付方式的限制或对开发者引导用户的规定有关，这些被认为阻碍了公平竞争。Meta 的罚款则可能涉及其数据使用政策，特别是如何整合和利用来自不同平台（如 Facebook 和 Instagram）的用户数据进行广告投放，以及用户对数据使用的控制权问题。这些都触及了欧盟关于数字市场竞争和用户数据保护的相关法律框架。
社区讨论：监管的必要性与影响
评论区对此事的讨论非常热烈，观点多样。一部分评论认为，欧盟的这些罚款是必要且积极的举措，表明监管机构正在认真对待大型科技公司的市场支配地位和数据滥用问题。他们认为，只有通过强有力的监管和罚款，才能迫使这些公司改变行为，促进更公平的竞争环境，保护用户隐私和选择权。甚至有人认为，数百万欧元的罚款对于这些市值巨大的公司来说只是九牛一毛，不足以产生实质性影响，呼吁更严厉的惩罚。
然而，也有不少评论表达了担忧或不同看法。有人质疑这些罚款的实际效果，认为它们最终可能只是被转嫁给开发者或消费者。另一些人则认为，过度复杂的监管可能会扼杀创新，增加合规成本，尤其对小型开发者不利。还有评论从技术角度探讨了合规的复杂性，比如苹果如何在不损害安全性的前提下开放其生态系统，或者 Meta 如何在提供个性化服务的同时满足严格的数据隐私要求。总的来说，讨论反映了在平衡科技发展、市场竞争和用户权益之间的持续挑战，以及对于监管有效性和潜在副作用的广泛关注。
讽刺：反盗版宣传片可能使用了“盗版”字体
一篇热门文章指出，九十年代末和二十一世纪初广为人知的反盗版宣传片——以“你不会偷一辆车...”开头的那个——其本身使用的字体，可能是一个未经授权的“盗版”或克隆字体。该宣传片中的 XBAND Rough 字体被认为是另一款商业字体 FF Confidential 的仿制品。这种“以盗反盗”的潜在行为，构成了文章和讨论的核心讽刺点。
文章指出，XBAND Rough 字体文件中的版权信息显示它属于 Catapult Entertainment，这家公司曾推出过 XBAND 游戏外设。这暗示反盗版宣传片的制作者可能使用了 Catapult Entertainment 的字体，而当时 Catapult 可能已经不再运营，导致字体被非法使用。
字体许可与定价之争
评论区的讨论迅速从这个具体的讽刺案例，扩展到了更广泛的字体许可、定价和价值的议题。许多评论者表达了对当前字体许可模式的不满，特别是针对移动应用和网络使用的许可费用。他们指出，现在数字产品的许可往往是按年收费且价格高昂，对于独立开发者来说难以承受，认为这种不切实际的定价是导致盗版问题的一个原因。
然而，另一部分评论者对此表示缺乏同情，认为现代操作系统和 Google Fonts 等平台提供了大量高质量的免费字体，对于大多数应用和项目来说已经足够。他们将购买昂贵的商业字体比作购买奢侈品，认为这是一种选择，而非必需。
字体在设计中的价值辩论
这引出了关于字体在设计中的重要性的辩论。一些评论者强烈反对“免费字体足够好”的观点，认为字体是设计中极其重要的一环，影响着产品的感受和用户的体验，将字体的重要性等同于奢侈品是对排版艺术的误解。但也有人认为，对于绝大多数应用而言，使用免费或系统字体并不会“深深受损”，并质疑昂贵字体对产品性能或收入有何客观数据支持。
字体的法律地位与“克隆” vs “盗版”
讨论也深入到字体的法律地位。在美国，字体的形状本身不受版权保护，但字体文件（作为软件程序）可以受版权保护。这导致了关于“克隆”字体（从零开始模仿形状）和“盗版”字体（复制文件）之间法律界限的讨论。评论者解释了美国法律的复杂性，并指出欧洲等地的法律可能更严格。
回到文章的核心讽刺，许多评论者对此津津乐道，认为这是反盗版组织虚伪的有力证据。关于字体创作的价值，一些人强调字体设计需要创造力、技艺和大量工作，对那些不理解这一点的人感到遗憾。
总的来说，这篇关于反盗版广告字体的小小观察，意外地打开了一个关于字体经济、设计价值、法律边界和数字时代知识产权本质的复杂而热烈的讨论。
AI Horseless Carriages：对当前 AI 应用的反思
一篇题为《AI Horseless Carriages》的文章认为，许多当前的 AI 应用感觉非常没用，就像早期模仿马车的汽车一样，只是将新技术（AI）硬塞进旧的工作流程和界面里，而没有真正重新思考如何利用这项技术。作者认为，AI 的真正力量在于阅读和转换信息，而不是从零开始生成文本，并且用户应该对 AI 的行为有更多的控制权，特别是通过编辑“System Prompt”。
文章以 Gmail 的 AI 邮件草稿生成功能为例，指出其生成的邮件过于正式、冗长且不像用户本人风格，提示词甚至比实际邮件还长。作者认为问题不在于模型本身，而在于应用设计限制了模型的潜力。他解释了大型语言模型（LLM）的工作方式，并引入了“System Prompt”（开发者编写的通用指令）和“User Prompt”（用户输入）的概念。他提出，如果 Gmail 允许用户编写自己的 System Prompt 来定义个人写作风格，AI 就能生成符合用户风格的邮件草稿，大大提高效率和乐趣。
文章将这种现象类比为“无马的马车”（Horseless Carriages），认为当前许多 AI 应用沿袭了传统软件开发中开发者作为中间人提供通用界面的模式。在 AI 世界里，当 AI 代理代表用户行事时，用户才应该是那个定义其通用行为（System Prompt）的人。作者认为，大多数 AI 应用应该成为“代理构建器”（Agent Builders），允许用户创建和定制代理，并提供“代理工具”（Agent Tools）让 AI 安全地与外部世界互动。他特别强调工具是实现安全边界的关键。
最后，作者重申 AI 的真正价值在于阅读和转换信息，并畅想了一个 AI 原生的邮件客户端，能通过用户定制的代理自动处理邮件的分类、优先级排序、归档，甚至起草回复，从而最大限度地减少用户花在处理邮件上的时间。他认为，AI 的“杀手级应用”将是自动化那些我们不喜欢做的日常工作。
社区讨论：AI 应用的痛点与未来方向
评论区对这篇文章的观点产生了热烈的讨论，许多人对作者的“AI 无马马车”类比和对当前 AI 应用的批评表示强烈认同。
一个普遍的共鸣是，许多现有的 AI 功能确实感觉是硬塞进去的、无用的，甚至适得其反。大家纷纷吐槽 Gmail、Strava、Garmin 等应用中那些“AI Slop”（AI 废话）功能，比如对只有一两句话的邮件生成冗长总结，或者生成毫无意义的锻炼总结。很多人表示，除了编程辅助工具（如 Copilot），他们很难想到其他真正让他们享受或觉得非常有用的 AI 功能。
关于 AI 用于写作，评论区出现了分歧。一些人同意作者的观点，认为对于简单的邮件，用 AI 生成反而更麻烦，提示词可能比实际邮件还长。但也有不少人认为 AI 在写作方面有其价值，特别是对于不擅长写作、非母语使用者，或者需要处理正式、复杂的沟通时，AI 可以帮助他们组织语言、润色措辞。
文章中提到的“AI 邮件阅读代理”概念得到了很多积极反馈。许多人认为，AI 在阅读、总结和分类信息方面的能力是其真正的优势，渴望一个能自动处理收件箱、过滤垃圾邮件、优先处理重要信息、甚至根据日历自动建议回复的 AI 助手。这与作者关于 AI 擅长“转换”而非“生成”的观点不谋而合。
会议记录 AI 成为评论区另一个讨论焦点。支持者认为它可以节省大量人工记录时间，让参会者更专注于讨论。然而，反对者提出了严重的担忧：AI 总结的准确性问题（可能遗漏关键细节、曲解原意、甚至捏造事实）、隐私问题以及滥用问题。
关于作者提出的“用户应该控制 System Prompt”的观点，一些评论者表示赞同，认为个性化是关键。但也有人质疑普通用户是否愿意或有能力编写和维护复杂的 System Prompt。
最后，评论区也触及了一些更深层次的思考：AI 是否正在把我们变成“工作审阅者”而不是“工作执行者”？以及 AI 的真正价值可能在于那些不引人注目、默默提高效率的后台功能，而不是那些 flashy 但无用的前台特性。同时，对 AI 炒作和“AI Slop”的厌倦情绪也很明显。
总的来说，这篇文章及其评论区生动地展现了技术社区对当前 AI 应用现状的复杂感受：既有对 AI 巨大潜力的兴奋，也有对许多现有实现方式的失望和批评，以及对未来 AI 如何真正融入工作和生活的深刻思考。
Scrimba 推出互动式 Node.js 视频教程：在浏览器内边看边写代码
在线学习平台 Scrimba 推出互动式 Node.js 视频教程，利用 StackBlitz 的 WebContainers 技术在浏览器内部提供完整的 Node.js 开发环境。这种创新的“IDE 视频”模式允许用户直接在视频播放器内部编辑和运行代码，进行实时实验，极大地提升了学习体验。该项目由 Scrimba CTO 发布，旨在将这种成功的互动模式扩展到后端和全栈开发领域。
Scrimba 最初为前端开发者提供互动式视频学习体验，用户可以在视频播放器内部直接修改和运行代码。现在，他们将这种模式扩展到了 Node.js 和全栈开发。通过集成 StackBlitz 的 WebContainers 技术，他们能在浏览器内部提供一个完整的 Node.js 环境，包括终端、shell、npm 访问和虚拟文件系统。这意味着学习者无需在本地设置复杂的开发环境，就能直接在浏览器里跟着教程进行后端和全栈项目的实践。
“IDE 视频”模式的优势
作者强调了这种“IDE 视频”格式的几个显著优势：
- 它们基于代码编辑、光标移动等事件进行记录，而不是传统的像素录制，文件大小比传统视频小约 100 倍。
- 录制过程非常简单：讲师只需边讲边写代码即可。
- 这种格式可以轻松嵌入到博客、文档或课程中，像 MDN、LangChain 和 Coursera 已经在使用了。
- 整个平台是使用作者自己创建的 Imba 语言构建的。
他们认为这种格式对于开源项目的维护者和专注于 API 的团队特别有用，可以用来创建交互式的文档或操作指南。他们甚至主动提出可以免费为维护库或 SDK 的团队录制一段这样的互动视频。
社区热烈反馈与技术探讨
评论区对这个项目表现出了极大的热情和积极反馈。很多评论者对这种互动式学习模式表示赞赏，认为它解决了传统视频教程过于被动、容易跟丢的问题。有用户分享了自己通过 Scrimba 学习 React 的成功经验，强调了能够直接与代码互动的重要性。
关于技术实现，有评论者询问为什么选择了 WebContainers 而不是基于 Docker 容器的服务器端执行。作者回应说，对于教授全栈 Web 开发来说，WebContainers 更适合且更容易维护，但他们的新 IDE 架构也为将来支持服务器端执行留下了可能性。
一个核心问题是用户在视频中修改代码后会发生什么。作者解释说，当你修改代码时，视频会暂停，并创建一个代码库的分支供你实验。当你再次点击播放时，你的修改会被还原，然后继续观看讲师的代码。
关于内容创建，有用户对在 Scrimba 平台上创建和销售自己的课程表示兴趣，作者表示对合作持开放态度。
评论中还有一个引人注目的子讨论是关于 Imba 语言。多位评论者对 Imba 表示赞赏，称其为 Web 开发领域“最好的秘密之一”，语法简洁强大，状态管理模型易于理解。
此外，评论区还探讨了语言支持（目前主要 JavaScript，未来可能更多）、可访问性（对盲人开发者可能非常有益，但需改进界面）、其他用途（非 IDE Web 应用操作的录制限制）以及与现有工具（CodeMic, CodeSchool 等）的对比。
总的来说，这个 Show HN 展示了一个在互动编程教育领域非常有前景的创新。将完整的 Node.js 环境带入浏览器内的互动视频，极大地降低了学习全栈开发的门槛。评论区的讨论不仅验证了这种模式的价值和受欢迎程度，也深入探讨了技术细节、潜在应用、内容生态以及底层技术 Imba，展现了社区对这种创新学习方式的浓厚兴趣和积极参与。