Parsimony 是一个衡量 AI 编程智能体中多余代码的基准。与解决率/成本指标不同，它衡量净编程单元：语句、调用、比较、名称、字面量等语法元素。它减去删除的代码（净 = 新增 − 删除），并避免按行计数，因此堆砌代码不会得到奖励。模型按其在已解决任务上新增的平均净单元排名，从低到高；失败尝试也计入平均值。已解决数据来自 SWE-bench Verified，不重新运行测试。补丁会被应用，变更文件会被解析；仅限 Python，排除测试、文档、生成文件。它使用相同的 mini-SWE-agent，不过智能体会影响输出。更小并不总是更好：单元衡量的是规模，而非可读性/设计，而且写更多代码的模型往往能解决更多任务。用户可以比较模型、查看排行榜，或通过示例 JSON 提交结果。代码/数据：github.com/La5u/Parsimony。
每日HackerNews RSS
Hacker News 的“Show HN”栏目介绍了一个名为 Parsimony 的开源基准，用于衡量 AI 模型新增了多少代码。现有基准会追踪解题率和 token 成本，但不会惩罚多余代码，而多余代码会让代码库更难维护。Parsimony 分析来自 DeepSWE、SWE-bench Verified 和 SWE-bench Live 的补丁，统计“编码单元”（如语句、调用、名称和字面量），而不是代码行数，并减去删除量，以衡量净新增量。GPT-6 和 Claude 5.5 没有公开补丁，因此作者亲自在 3–10 个任务上运行了它们；结果显示为淡化的、未排名的圆圈。欢迎反馈和公开补丁导出。
评论者讨论了把圈复杂度作为可读性指标、减少智能体生成内容冗长程度的方法，以及担忧当前领先者 Astra 是靠难以阅读的极简“代码高尔夫”取胜。其他人则争论冗长与简洁之间的取舍，并希望有面向 Qwen 3.8 27B 等可本地运行开源模型的基准。
我带着模糊的路线指引，来到深藏山谷中的牧羊人夏季营地。这算是个主题：我找到的奶酪总在偏远之处，由那些隐居般的人出于纯粹的固执守着老办法做出来。那里美得惊人，只有我和我的背包。山谷尽头是一道陡峭悬崖，上有破败
一场关于走遍世界寻找稀有奶酪的 Hacker News 讨论，融合了旅行、奶酪鉴赏与行业现实。评论者推荐了伦敦的 La Fromagerie，称赞瑞士数不清的乡村奶酪，并争论喜马拉雅 chhurpi——在西方常作为“牦牛奶酪”狗咬胶出售——可能是世界上最硬的奶酪。其他人提到了科西嘉臭名昭著的 casu martzu，以及参观卡芒贝尔奶酪故乡的梦想。一位评论者分享了一个警示性叙述，讲述奶酪工厂中艰苦而危险的工作，认为鉴于其人力代价，消费者应更加珍视奶酪。另一位指出，工业生产与其他任何工厂流程无异。该帖还链接了 Ruby Tandoh 关于已灭绝奶酪的文章和 G.K. Chesterton 关于奶酪的文字。总体而言，这场讨论赞美了奶酪的多样性与文化，同时也承认其背后的劳动、规模，以及有时极端的形态。
Spotatui 是一个轻量级的 Rust 终端音乐播放器，也是 spotify-tui 的活跃维护分支。它无需 spotifyd 或官方客户端即可原生播放 Spotify（需要 Premium），但 Spotify 是可选的。它还支持本地文件、Subsonic/Navidrome、网络电台、YouTube、Qobuz，以及在 macOS 上的 Apple Music。功能包括同步歌词、实时可视化器、跨来源队列、播放列表同步、Lua 插件、收听历史/回顾，以及完整的命令行界面。流式播放时约占用 78 MB 内存。桌面应用在 Spotify 风格的窗口中提供相同的播放器。可通过一行脚本、Homebrew、Cargo、AUR、Winget 或 Nix 安装。AI-DJ 和 MCP 集成让编码代理可以控制播放。它基本上可脚本化、可配置，并由社区维护。
Spotatui 是一个 Show HN 项目：一个开源 Spotify TUI/GUI，通过使用 librespot 的一个分支以及 Spotify 的内部 API（spclient 和 Pathfinder GraphQL）来避免 Spotify Web API 的速率限制，用于播放、元数据、播放列表、音乐库、设备、歌词、搜索和音频分析。每个用户用自己的 Spotify Premium 账户进行身份验证，因此没有共享的应用配额，不过未公开的 API 可能会失效。它最初是 2019 年重新启动的 spotify-tui，现在包括一个用 Tauri 构建的 GUI 和一个 Rust 核心，并计划实现 GUI/TUI 功能对等。它还支持 YouTube、Navidrome/Subsonic、网络电台、本地文件、Qobuz 和 Apple Music（macOS），以及 Lua 脚本、网页配套应用和供 AI DJ 使用的 MCP 工具。HN 评论者称赞其名称，将其与 ncspot 比较，并询问无损/DRM 和动机；作者提到是为了学习 Rust 并为父亲构建 GUI。讨论涉及 Linux CLI/TUI 的吸引力、资源占用和 GUI 框架。
Hypermass CLI 是一个命令行工具，可将实时 Hypermass 数据流同步到本地文件夹。安装后，使用 `hypermass subscribe <stream>` 配置流，并使用 `hypermass sync` 在文件发布时持续获取文件。文件会出现在 `<home>/hypermass/subscriptions/<stream-id>` 下，每个载荷一个文件，以载荷 ID 命名，并按发布顺序交付。你可以处理并删除数据文件，但必须保留每个流的隐藏 `.hypermass` 文件夹，它用于跟踪你在流中的位置。`sync` 还会从配置的发布源发布文件。使用 `status`、replay 和 `reload` 监控或管理流。该 CLI 面向数据科学家、开发者、研究人员和生产系统，他们需要一种简单、可重复、跨平台的方式来自动化数据摄取和发布。
Show HN 展示了 Hypermass，一项服务和 Apache 2.0 Go CLI，让用户用两条命令订阅实时开放数据文件流。订阅者无需注册；文件以 ULID 形式到达本地文件夹，便于按时间排序。发布只需将文件放入一个文件夹。该工具处理排序、重试、哈希验证和重连，面向太阳影像、灾害警报和交通时刻表等实时但低频的数据。下载使用签名链接；订阅使用 websockets；发布的 XML/JSON 会经过验证。一位英国独立创始人因开放数据碎片化而感到沮丧后构建了它，并希望简化“只要把数据给我”。可持续性：免费层、重度使用付费，之后是机构发布者或市场。计划包括 API、回调命令、高速数据流和发布者入驻。他问：CLI 是否解决真实问题，这种方式是否合理，你会发布数据吗，以及如何启动用户/发布者？
1976年7月，阿佩尔和哈肯宣布了四色定理的证明，借助一台运行了1200小时、做出了100亿次判断的计算机；约翰·科赫协助了算法。结果引发了激烈争论。一些数学家接受了它；另一些则拒绝这种依赖计算机验证而非人类可核查推理的证明，称其为“神谕”，或说它根本不是数学。年龄也起了作用：年长的数学家怀疑计算机证明，年轻的数学家则怀疑700页手工计算。比尔·图特、海因里希·赫施和特德·斯沃特的高调支持提升了可信度，尽管《纽约时报》最初拒绝报道此事。1979年，托马斯·蒂莫奇科主张，无法通览的证明不是传统证明；斯沃特回应说，计算机辅助证明只是纸笔的延伸。这一事件标志着人机数学的开端，并提出了关于证明中的信任、验证和优雅的持久问题。
Hacker News 上关于四色定理计算机辅助证明的讨论，引发了对机器生成数学和 AI 代码的反思。一位评论者回忆，自己在 20 世纪 80 年代曾因一篇冗长、案例繁多的数组公理机器证明而受到批评，并指出这类证明如今已不足为奇，但仍可能显得不优雅。其他人则争论四色定理的证明是否解释了该定理为何为真；计算机辅助证明可能抑制对洞见的追寻，尽管肯普式归约产生了更广泛的数学思想。评论者将其与 AI 生成的代码相比较：它常常能用，但冗长、复杂且难以审查。一些人认为，当开发者把错误归咎于 AI 时会出现问责问题；另一些人则表示，管理层接受这种风险。一个反复出现的主题是优雅：AI 被训练来寻找解决方案，而非优美的解决方案，并且可能缺乏人类对洞见的追求。该讨论串还提到了树宽，以及与安提基特拉机械的警示性类比，涉及过度信任计算模型的问题。
Guitoro 是一款免费、完整的在线虚拟吉他。它提供四种采样乐器——钢弦原声吉他、古典吉他、电吉他和四弦贝斯——音色可选、10 种调弦、最高第 10 品变调夹以及左手模式。在 24 个大小调中任意一个调里，提供 15 个具有真实琴颈指型的和弦；可用 F#m7 等和弦编辑调性，并在 Standard、Easy 和 Up 三种按法之间切换。使用 56 种扫弦/拨弦模式，以任意速度（最低 20%）演奏 51 首歌曲，或粘贴你自己的 ChordPro/和弦网站歌曲并添加反复记号。伴奏乐队提供 15 种鼓风格和 25 条贝斯线，速度 10–220 BPM，并带节拍器。独奏模式支持带锤弦、推弦和颤音的旋律。音箱与效果器包括过载、失真、法兹、EQ、混响和延迟。最多录制 10 分钟，可回放或导出 WAV/压缩音频。麦克风调音器覆盖吉他、贝斯、尤克里里和特殊调弦。一切都在浏览器中运行。
Guitoro 是一款 Show HN 上基于浏览器的虚拟吉他，让用户可用键盘、鼠标或触摸屏，借助真实乐器的录音来扫弦。它提供原声、古典、电吉他和贝斯选项，和弦指法与扫弦可视化，可放慢至 20% 的歌曲练习，以及免费和弦工具和调音器——无需注册或下载。Hacker News 讨论帖（360 分、97 条评论）整体反响热烈，吉他手称其直观、有趣，是有前景的学习/无障碍工具。反馈包括希望有六线谱风格或镜像指板、自定义调弦、在换和弦时让未变动的弦继续延音、力度/动态、指弹、尤克里里，以及修复琶音器、“让音延续”和移动端/桌面端问题。创作者作出回应，并记录了建议的改进。有些人争论它是玩具还是真正的乐器，但许多人称赞其设计和可演奏性。
启用 JavaScript 和 Cookie 以继续
Ledger确认，受损的硬件钱包是通过一家经销商流入的，其中植入了微型eSIM和微控制器，用于在设置过程中截取屏幕数据并窃取助记词。评论者指出，这印证了多年来被斥为“偏执”的供应链威胁。许多人批评Ledger的安全实践，建议跨厂商使用多签，并认为硬件钱包从来就不是完整解决方案。讨论还涉及加密货币相比传统银行缺乏追索途径、财务激励驱动复杂攻击的力量，以及关于硬件供应链信任的教训。一些人认为这是自托管可预见的失败；另一些人则呼吁更好的防篡改设计或开源设计。该讨论串反映出对加密安全的深度怀疑，以及保护数字资产免受资金充足、决心坚定的攻击者侵害的难度。
`ai-deslop` 是一个 Oxlint 插件，提供有主见的规则，用于标记低信号、AI 生成的“slop”代码。它引入了来自 `dmmulroy/anti-slop`（MIT）的通用规则，并在 `deslop/*` 命名空间下添加了更多规则。使用 `npm install --save-dev ai-deslop` 安装；`@oxlint/plugins` 是运行时依赖。它提供面向 Bun、Deno 和 Node 的已编译 JS。在 Oxlint 中通过 `jsPlugins` 和 `deslopConfigs.recommended` 配置。推荐规则涵盖不安全类型模式（unknown 参数/返回值、断言、类型拓宽、对象参数/字典）、性能问题（filter/map、reduce 展开、Reflect）、测试反模式（模块模拟、仅模拟调用断言）以及标准 TypeScript 规则（已弃用、浮动 Promise、require 导入、不必要条件、不可达）。可选规则处理重复 const/类型、重命名导入和 Tailwind 类名。鸣谢 anti-slop（MIT）。
在 Hacker News 上，maharshi365 发布了“Show HN: Deslop”，这是一组用于 AI 生成 TypeScript 的 Oxlint 规则，可捕获不安全类型、重复代码和低价值测试。该帖获得 26 分和 6 条评论。评论者一致认为，这类代码检查对 AI 辅助编程很重要，其中一人指出，激进的 lint 配置和约 80% 的测试覆盖率让 AI 功能开发变得可行。一条具体规则 `no-reflect-get` 受到称赞，因为 Claude 经常使用 `Reflect.get`。其他人将 Deslop 与 `eslint-plugin-unicorn` 相比较，并希望 Oxlint 增加插件支持。作者表示，Oxlint 可能已经将 Unicorn 作为插件提供，并邀请提交 PR。还有评论者提到使用 Oxlint、ast-grep、CodeRabbit 的 `ast-grep-essentials` 和 `anti-slop` 来处理 LLM 生成的代码。有人问 Deslop 相比 `anti-slop` 增加了什么。
XBOW 在六天内构建了一个由大语言模型辅助的 Chrome 全链漏洞利用，API 成本约 4 万美元，并赢得了谷歌首个 25 万美元的全链 VRP 奖励。该利用链使用三个漏洞，同时突破了 V8 的进程内沙箱和 Chrome 的渲染器沙箱：一个 Maglev 去优化缺陷复用了可变的 HeapNumber，从而在 V8 的指针压缩笼内获得读/写能力；一个 Blink 中动画 WebP 的 TOCTOU 将缓存的几何数据与已更改的字节结合起来，产生一次选定的原生写入；以及一个 Crashpad 竞态，它信任被挂起渲染器的内存，使代码能在未沙箱化的处理程序中执行并启动计算器。AI 代理负责漏洞搜索、概念验证和利用阶段，而 XBOW 研究人员指导目标、接口和后备方案。这三个漏洞都涉及改变某种被认为不可变的东西。Chrome 修复已公开。这项工作表明，大语言模型大幅降低了全链漏洞利用的时间与成本门槛，同时增加了碰撞风险，并使防御更加紧迫。
Hacker News 讨论了 XBOW 的“六天从零到 Calc”Chrome 全链漏洞利用。一位评论者质疑时间线：CEO 在一月宣布目标，第一条完整利用链花了两个月，然后到了八月，换掉一个漏洞并在六天内武器化，代价是 4 万美元代币。XBOW 的 moyix 澄清说，第一条链的漏洞被修复后已完全失效，所以团队在八月重启。六天内，它发现了约 11 个漏洞，提交了三个作为完整利用链，在中间阶段发生冲突，并用备用方案替换。这个漏洞利用耗费了 4 万美元代币，并获得了 Google 25 万美元奖励。团队直到大约五月才被聘用。一个人加上智能体构建了这条特定利用链，并借助了早先协作链的技术。评论者指出，禁用 JIT 可以缓解这类漏洞利用，而 Chrome 只提供部分禁用 V8 优化。其他人则担心浏览不可信网站。
A plea not to use uv-build
18 小时前
一篇 Gentoo 开发者的博客文章《不要使用 uv-build 的呼吁》在 Hacker News 上引发了争论。该呼吁认为，uv-build 这个基于 Rust 的 Python 构建后端给基于源码的发行版带来负担：它发布频繁，必须经常重新构建，而且可能不支持较旧或小众的架构。一位 uv 维护者回应称，Python 打包是标准化的，uv-build 有意做到跨版本兼容，Gentoo 可以约束版本或降低更新频率；未约束的元数据并不意味着“最新”。评论者争论 Python 打包是否真正标准化，还是仅接口标准化。有人说 Gentoo 必须遵循每个项目指定的后端，因此 uv-build 频繁发布迫使滚动、基于源码的用户重新构建。另一些人则认为 Gentoo 可以打补丁、固定版本或改变政策，而且发行版本来就会修改软件包。该讨论扩展到关于 Python 工具中的 Rust、可移植性、长尾平台支持、Gentoo 从源码编译的理念，以及维护者是否应迎合小众架构的辩论。总体而言，这是生态系统标准化、维护者便利性与下游发行版负担之间的张力。