演示模式记录您的浏览器操作并即时生成自动化代码。手动执行任何任务一次，它就会捕获每个步骤并将其转换为可编辑的、生产级别的代码。无需提示，无需语法，只需展示您的工作流程并立即部署。立即构建：https://console.notte.cc。
每日HackerNews RSS
Notte 是一款旨在简化网络自动化的新工具，它结合了确定性脚本和人工智能驱动的边缘情况处理。创始人 Andrea 和 Lucas 在发现生产环境中的浏览器自动化通常受益于常见任务的可预测脚本，并辅以处理异常情况的智能体后，构建了“演示模式”。
该工具允许用户在云浏览器中记录他们的网络工作流程，然后将其编译成可部署、版本控制的代码——不同于基于运行时 LLM 的解决方案。Notte 处理底层基础设施（浏览器、代理、身份验证），并提供日志记录和重试等功能。它类似于 Playwright codegen，但具有托管基础设施。
Hacker News 的讨论强调了该概念源于较早的“演示编程”系统，并指出浏览器自动化领域竞争激烈，竞争对手包括 BrowserUse、Browserbase 和 Skyvern。用户也在探索潜在的应用场景，例如使用预构建的工作流程引导新用户，以及自动化测试。
## 通过验证实现可靠性：摘要
本报告详细介绍了实验，证明了自动化浏览器流程的可靠性源于强大的*验证*，而不仅仅是更大的模型或更多的视觉数据。核心思想是将网页视为结构化数据——角色、文本、几何形状——并用明确的断言来控制每个步骤，这些断言*必须*通过才能使操作成功。这使得可以使用较小的本地LLM进行执行，并将更大的模型保留用于规划。
运行了四个演示，全部完成了相同的亚马逊购物任务（搜索、添加到购物车、结账）。一个关键结果：使用一个~3B本地执行器与DeepSeek-R1规划器配对，并由Sentience的验证层引导，成功完成了完全自主的运行。这与早期的云端运行形成对比。
通过界面设计和过滤，token使用量显著减少（~43%），证明效率并不完全依赖于模型大小。该系统通过断言不匹配明确地显示失败，而不是在出现错误的情况下默默地继续。这种“Jest for agents”方法优先考虑确定性结果，并通过Sentience Studio等工具提供详细的调试。最终，研究结果表明，强大的验证层即使是“愚蠢”的模型也能可靠地胜任。
## 浏览器代理可靠性：验证而非扩展
一项最新案例研究探讨了为亚马逊购物等任务构建可靠的浏览器代理，挑战了依赖大型云端语言模型（LLM）的常见方法。作者成功地使用一个较小的、约30亿参数的本地LLM完成了购物流程（搜索、加入购物车、结账），但关键在于，*仅*使用结构化页面数据（DOM）和一个强大的验证系统。
其关键创新在于一个“验证层”，它通过类似Jest的断言来控制每个步骤，确保预期的状态变化发生。这与“点击并希望”自动化形成对比。该系统将DOM修剪为“语义快照”，将推理（规划）与行动（执行）分离，并在每个行动后明确验证结果。
虽然基于云的基线实现了更快的端到端时间，但本地系统在所有步骤中都成功完成，且成本为零，这突出了**可靠性来自于验证，而不仅仅是模型大小。** 作者强调使失败明确且可调试，而不是默默地陷入错误，这是传统浏览器自动化中常见的问题。这种方法类似于基于属性的测试，预先定义成功条件，并确保代理遵守这些条件。
## 从Windows老用户到Linux的转变
作者忠于Windows超过二十年，适应了它的怪癖并能最大限度地发挥其性能。然而，一系列令人沮丧的问题——侵入式广告、强制更新导致数据丢失，以及最终在24H2更新中出现的导致系统崩溃的错误——导致了临界点。在Windows内部修复这些问题的尝试均告失败，微软和英伟达互相指责驱动程序不兼容并删除用户报告。
迫于无奈，作者转而使用CachyOS，一个基于Arch的Linux发行版。虽然最初令人望而却步，但体验却出乎意料地积极。问题可以通过社区支持解决，并且像Bitwig Studio这样的原生替代品提供了可比或更优的功能。
作者强调了2026年Linux的现状：出色的浏览器和开发支持、不断改进的游戏性能以及可行的创意工具。虽然承认仍存在一些差距，但他们认为，与Windows的不稳定性和不受欢迎的功能作斗争相比，学习Linux的曲线是值得的。最终，微软对利润的无情追求以及不稳定AI功能的整合，促使作者——以及许多其他人——拥抱Linux，不是出于选择，而是出于必要。
## Linux 获得势头，用户逃离 Windows 和 macOS
最近的 Hacker News 讨论强调了一个增长趋势：用户正在转向 Linux，通常是由于对微软 Windows 以及越来越多的苹果 macOS 的不满而驱动。 许多评论者分享了因 Windows 限制性许可、更新问题以及普遍感觉失去对系统控制权等问题而被“迫使”使用 Linux 的经历。
许多人发现 Arch Linux（通常通过 EndeavourOS 进行更轻松的安装）和 Pop!_OS 等发行版取得了成功，赞扬了它们的灵活性和性能，尤其是在通过 Proton/Steam 进行游戏方面。 虽然承认仍然存在挑战——UI 不一致、硬件兼容性（特别是 Nvidia 驱动程序）以及专业软件支持——但用户正在使用 LLM 等工具来解决问题。
对话还涉及了 Apple 硬件的吸引力，但批评了 macOS 本身。 尽管 Linux 长期以来以学习曲线陡峭而闻名，但日益易用以及对更大控制力的渴望正在吸引更多用户，尤其是开发者。 虽然桌面 Linux 市场份额仍然相对较小，但情绪表明增长正在加速，这得益于对主流操作系统的不满以及 Linux 易用性的改进。
## 包管理领域的“棘手问题” Horst Rittel 和 Melvin Webber 提出的“棘手问题”概念——指那些解决方案定义不清，且试图解决它们反而会改变问题本身的复杂问题——完美地描述了软件包管理的挑战。拥有数百万个包、版本和下载量，即使是微小的改变也会产生广泛的影响。 作者认为，包管理并非一个有明确解决方案的问题，而是一组不断演变的权衡。这通过“棘手问题”的十个特征得到了说明：定义模糊、没有明确的停止点、主观的“好”与“坏”解决方案、不可预测的后果、不可逆的决策、缺乏标准化解决方案、独特的背景阻碍了简单的复制、与更大问题的相互关联、多种冲突的解释，以及由于现实世界的影响而无法简单地“错误”。 例子包括对版本控制（SemVer）的不同解读、Go 的基于 URL 的导入所带来的影响，以及完全撤销过去决策的不可能性。最终，作者建议采用“参与式规划”方法——专注于包管理器*之间*的沟通和共享接口，而不是寻求一个完美的工具。包管理永远无法被“解决”，但可以通过协作和接受内在的复杂性来不断改进。
## Hacker News 讨论：包管理 – 一个“棘手问题”
最近 Hacker News 的讨论围绕一篇博客文章（https://nesbitt.io/posts/）展开，该文章探讨了包管理的复杂性。作者建议像 Jepsen 测试数据库一样测试包管理器，引发了关于这个想法的新颖性的争论。
对话突出了包管理固有的困难，涉及命名约定、依赖关系解析以及不同方法（如 Nix 的“存储换解决方案”方法）之间的权衡。许多评论者认为这是一个独特且具有挑战性的领域，尽管它在软件开发和安全性方面发挥着关键作用，但经常被忽视。
几个要点浮出水面：不同语言之间的文化差异会影响包管理器的质量（Rust/Cargo 经常受到赞扬），JavaScript 的 npm 持续存在的问题，以及更标准化、操作系统级别的包处理方式的潜在好处。一个反复出现的主题是，包管理是一个持续的平衡行为，而一个真正“解决”的问题似乎不太可能实现。最终，尽管令人沮丧，包管理仍然远远优于旧的软件分发方法。
## dwm.tmux：一个 Tmux 平铺窗口管理器
dwm.tmux 为 Tmux 带来了 dwm 风格的平铺体验，提供高效的窗格和窗口管理。安装需要 Tmux 3.2+ 版本，并在克隆仓库后执行简单的 `make` 命令。
它将窗口组织成一个左侧的大主窗格和右侧的一堆较小窗格。 键绑定（使用 Meta 键 + 字母/数字）控制窗格创建 (`Meta-n`, `Meta-w`)、删除 (`Meta-c`)、移动 (`Meta-Shift-[0-9]`) 和布局调整 (`Meta-t`, `Meta-Space`)。 窗口管理包括创建 (`Meta-N`)、杀死 (`Meta-X`) 和选择窗口 (`Meta-[0-9]`)。
dwm.tmux 可以通过环境变量（如 `mfact`，主窗格大小）和标准的 `.tmux.conf` 文件进行高度定制。 用户只需在他们的 `.tmux.conf` 中 `source-file` dwm.tmux 配置文件，然后在这一行之后添加自定义绑定即可。
## Dwm.tmux：一个用于 Tmux 的终端窗口管理器
一位 Hacker News 用户分享了“dwm.tmux”，这是一个受 dwm 窗口管理器启发，设计用于提供更结构化的 Tmux 窗格管理方式的十年前的项目。创建者发现基于平铺的布局和专用的键盘快捷键提高了控制和效率，尤其是在大量使用终端作为 IDE 时。
该项目引发了关于类似工具（如 `abduco` 和 `zmx`）的讨论，这些工具提供会话和窗格管理，通常利用 `libghostty` 进行终端恢复。用户们争论了其价值主张，一些人认为 Tmux 内置的功能已经足够，而另一些人则赞赏 dwm.tmux 提供的一致布局和简化的工作流程。
作者澄清这不仅仅是配置，还包括 shell 逻辑来克服 Tmux 的限制。虽然承认个人偏好，但他们希望能够激发更多对脚本编写和增强终端复用器的探索。该项目旨在提供更具主观性和动态性的终端体验。
请启用 JavaScript 并禁用任何广告拦截器。
## OpenAI 获得软银高达 300 亿美元的潜在投资
据报道，软银正在与 OpenAI 洽谈进一步投资高达 300 亿美元的可能性，这在 Hacker News 上引发了关于如此大规模资本注入是否明智的争论。 许多评论员质疑这笔投资是否合理，特别是考虑到 OpenAI 巨大的资金消耗（估计每年 140 亿美元）以及缺乏明确的盈利途径。
人们对机会成本表示担忧，认为这些资金可以更好地分配到能源研究或医疗保健等领域。 还有人将 OpenAI 与 WeWork 进行比较，考虑到来自谷歌和苹果等科技巨头的竞争，质疑其长期可行性。
一个关键的讨论点在于 OpenAI 的当前价值是由真正的创新驱动，还是仅仅由炒作推动。 一些人认为 LLM 已经提供了价值，而另一些人则认为这笔投资是投机性的，并且推高了基础设施成本，但并不能保证实质性的回报。 IPO 的可能性也被讨论，一些人认为 OpenAI 尚未准备好接受公众的审查，并且可能依赖于软银等实体持续投资。 最终，许多人预计市场会出现修正，但修正的规模仍然存在争议。
## Mecrisp-Stellaris LSP：Forth 代码补全
现在为 Mecrisp-Stellaris Forth 提供了一种语言服务器协议 (LSP) 实现，可在您的编辑器中直接为字典单词提供自动补全和用法示例。 这通过在您键入时提供智能建议，显著加快了开发速度。
目前设计用于 Helix 编辑器（尽管与 VIM、GVIM 和 NVIM 兼容），LSP 仅需键入命令的前几个字母即可激活——将显示匹配的选项。 您还可以使用 "/" 键在编辑器中浏览整个 Mecrisp-Stellaris 字典。
LSP 需要 Python 3.11、`pygls>=0.6.0` 和 `lsprotocol>=1.4.0`。 它可从 SourceForge 下载为 tarball，并且需要在您的编辑器中进行配置（为 Helix 的 `config.toml` 提供了示例）。
此工具通过使 Mecrisp-Stellaris 字典单词易于访问和理解，从而增强了编码体验。
该网站正在使用安全服务来保护自身免受在线攻击。您刚才的操作触发了安全解决方案。 提交特定词语或短语、SQL命令或格式错误的数据等行为可能会触发此阻止。
## 智能系统视频男孩 (VUE) 总结
智能系统视频男孩 (VUE) 是一款用于任天堂 Virtual Boy 的开发工具，允许游戏在标准电视或显示器上显示。据称，它由与许多任天堂开发套件相同的团队创建，并被任天堂 Power 用于录制和截图。
VUE 通过 Virtual Boy 卡带插槽连接，并通过 AV 多输出或 RGB 输出 PAL 信号（50 FPS），避免 NTSC 转换。该设备的 DIP 开关控制显示选项，包括用于红/绿立体眼镜的单独左右眼视图，但一些开关似乎没有功能。
在内部，VUE 利用 Virtual Boy 主板和定制电路——包括 Xilinx FPGA 和 SRAM——来缓冲和转换 Virtual Boy 独特的显示方式，使其成为兼容的视频信号。它与 VUE-DEBUGGER 开发单元使用的 PAL 显示器输出板密切相关。该设备的标签和内部标记显示了多个版本和潜在的改造，突显了其开发重点的起源。
## 虚拟男孩复兴与怀旧反思
一篇关于智能系统视频男孩（一种基于电视的虚拟男孩设置）的近期文章，在黑客新闻上引发了关于任天堂臭名昭著的虚拟男孩主机的讨论。虽然游戏现在正登陆Switch，并计划推出一款新的虚拟男孩外壳配件，但许多人质疑该系统的持久吸引力。
用户回忆起最初的虚拟男孩的缺点：不舒适的设计、令人恶心的游戏体验、缺乏色彩以及缺乏原创性的游戏。尽管如此，由于稀有性和即将发布的任天堂游戏，人们的兴趣正在上升。一些人 fondly 回忆起独特的技术——LED 显示屏被快速移动的镜子扫过视野——而另一些人则认为其低保真度的 VR 概念在现代应用中具有潜力，并建议专注于清晰度而非色彩可以解锁新的可能性。
这场对话凸显了人们对虚拟男孩的怀旧迷恋，即使是那些从未拥有过它的人，以及对其作为早期 VR 游戏中的独特而有缺陷的实验的认可。 许多评论员称赞《瓦力欧乐园》是一款杰出的游戏，并指出 3DS 的 Red Viper 模拟器是当今玩 VB 游戏的令人惊讶的有效方式。