2025 08 31 HackerNews

2025-08-31 Hacker News Top Stories #

在软件设计中，遵循“尽可能简单”的原则，通过深入理解代码库找到最简单的解决方案，优秀的设计看起来不复杂但功能强大。

认知负荷是开发者完成任务时需要处理的信息量，优化代码结构可以减少外在认知负荷，提高代码可读性和可维护性。

Hacker News 上使用 em dash 的用户排行榜显示 derefr 用户最多，讨论还涉及 em dash 的使用趋势和正确性。

诺基亚的传奇字体 Nokia Sans 在多种尺寸下易读且具有个性，适合作为用户界面字体，但其合法性和兼容性存在疑问。

罗马尼亚在国际奥林匹克竞赛中表现出色，因其教育体系强调分层和竞争，培养优秀学生的潜力，但在教育普及方面存在不足。

ACP 协议是一种标准化协议，用于代码编辑器与编程代理之间的通信，旨在实现互操作性并支持代理生态系统的开发。

将人工智能模型视为虚拟机，可以提供安全、隔离和可移植性等特性，类似于 Java 虚拟机，为 AI 模型提供标准化的执行环境。

注意力机制从多头注意力到潜在注意力的演变，通过优化查询和键值向量的计算，提升了模型的效率和性能。

SQLite 的持久性属性文档不明确，默认配置可能不提供持久性，建议显式设置 synchronous 和启用 fullfsync 以确保数据安全。

Do the simplest thing that could possibly work #

https://www.seangoedecke.com/the-simplest-thing-that-could-possibly-work/

在设计软件系统时，应遵循“尽可能简单”的原则。这一原则适用于修复漏洞、维护现有系统和构建新系统。许多工程师倾向于设计一个“理想”的系统，但这种方法是错误的。相反，应该深入了解当前系统，然后采取最简单的解决方案。

简单性可能令人失望，因为系统设计需要掌握多种工具，如应用服务器、代理、数据库、缓存、队列等。初级工程师自然想要使用这些工具，但真正的掌握往往在于学会何时做得更少。在软件中，优秀的软件设计看起来并不令人印象深刻，但它们是设计上的杰作，因为它们做了最简单的事情。

例如，Unicorn 和 Rails REST API 都是优秀的软件设计，因为它们以最简单的方式提供了所需的功能。如果你需要为 Golang 应用程序添加速率限制，最简单的方法可能是在内存中跟踪每个用户的请求计数，而不是使用 Redis 等持久存储。如果边缘代理已经支持速率限制，你甚至可以简单地配置几行代码。

当然，总是做最简单的事情也有问题。首先，不预测未来需求可能导致系统不灵活或混乱。其次，不清楚“简单”的含义。第三，应该构建可扩展的系统，而不仅仅是现在工作的系统。然而，这些担忧可以通过正确的方法来解决。简单性并不意味着停止工程，而是需要深入理解整个代码库以找到最简单的解决方案。简单系统具有更少的“活动部件”和更清晰的接口。在不确定哪个更简单时，可以使用稳定性作为决定因素。最后，过度关注规模并不是不负责任的工程，而是应该根据当前的需求来设计系统。

HN 热度 991 points | 评论 360 comments | 作者：dondraper36 | 1 day ago #

https://news.ycombinator.com/item?id=45068091

简单性在复杂领域可能不适用，大科技公司面临的复杂性令人震惊
软件工程师之间沟通不畅，导致对简单性的理解有误
简单性并不总是最好的解决方案，有时需要更复杂的解决方案
复杂性不仅仅是代码或基础设施，还包括扩展、运维、维护和迁移等
理解要构建的东西，并分阶段实现，每一步都提供商业价值
最简单可能的解决方案并不总是最好的，需要适应变化
有时提前思考几步更好，而不是每次规模扩大时都从头构建新系统
难以知道何时应该提前规划，何时不应该，通常最好避免过度设计
使解决方案尽可能可替换，优化替换的便利性而非性能或可扩展性
英特尔在移动市场遵循此策略，结果似乎导致了失败
在复杂问题或基础系统的情况下，提前思考几步特别有用
简单性有时是在复杂性之后实现的，目标是足够好而非完美
许多复杂性是由于集成问题，保持接口和数据交换格式简单有助于单独重构系统
IPv4 到 IPv6 的转变是一个没有采取最简单的可能解决方案的例子
IPv6 实际上就是具有更大地址空间的 IPv4，除了额外的位数外，还减少了一些不必要的复杂性
与兼容路由相关的“与兼容路由”非常关键，如果没有它，IPv6 的采用可能会更低

Cognitive load is what matters #

https://github.com/zakirullin/cognitive-load

Cognitive Load（认知负荷）是指开发者在完成任务时需要思考的量。在阅读代码时，我们需要将变量值、控制流逻辑和调用序列等信息放入工作记忆中。平均来说，一个人大约能同时记住四个这样的信息块。一旦认知负荷超过这个阈值，理解事物就会变得更加困难。

我们经常在代码中感到困惑，这种困惑会耗费时间和金钱。困惑是由高认知负荷引起的，它不是一个抽象的概念，而是一个基本的人类限制。由于我们花在阅读和理解代码上的时间远多于编写代码，我们应该不断问自己是否在代码中嵌入了过多的认知负荷。

认知负荷可以分为两类：内在认知负荷和外在认知负荷。内在认知负荷是由任务本身的难度引起的，无法减少，它是软件开发的核心。外在认知负荷是由信息呈现方式引起的，可以大幅减少，我们将重点关注这种类型的认知负荷。

例如，复杂的条件语句会增加认知负荷，我们可以通过引入有意义的中间变量来减少这种负荷。嵌套的 if 语句也会增加认知负荷，我们可以通过早期返回（early returns）来减少嵌套，从而降低认知负荷。

在继承方面，复杂的继承结构会导致认知负荷增加。我们更倾向于使用组合而不是继承来减少这种负荷。此外，太多的小方法、类或模块也会导致认知负荷增加。我们应该追求深层模块——简单接口、复杂功能，而不是浅层模块——相对复杂的接口对应小功能。太多的浅层模块会使理解项目变得困难，因为我们需要记住每个模块的责任以及它们之间的所有交互。理解浅层模块的目的需要先查看所有相关模块的功能，这种在浅层组件之间的跳跃是精神上的消耗。

HN 热度 723 points | 评论 316 comments | 作者：nromiun | 11 hours ago #

https://news.ycombinator.com/item?id=45074248

软件设计应尽量减少复杂性，复杂性定义为“做出改变的难度”，这主要由认知负荷决定。
寻找完美的软件解决方案是不现实的，应根据个人经验和智慧在“混乱”和“美观”之间寻求平衡。
业务需求是不确定的，而软件是确定的，将不断变化的需求融入到软件系统中是困难的。
只有在修改代码时感到痛苦时才进行重构，且只进行最小程度的代码清理。
规则不能取代品味、判断、经验和直觉，架构争论无法获胜。
认为 DRY（不重复自己）应该在应用被充分理解且存在多个版本时才考虑，初期应该重复自己。
DRY 不是关于不重新实现事物，而是关于不复制粘贴代码，但有时复制粘贴代码是合理的。
有时应该复制粘贴代码，因为那些代码块可以独立发展。
初级开发者常陷入 DRY 陷阱，过早优化可能导致添加抽象和耦合，导致更大的修改范围。
如果代码部分看起来相似但有不合并或重构的合理理由，应该添加注释。
复制粘贴有时是可以接受的，尤其是当你需要在不同地方使用相同的功能时。
有时复制粘贴代码是合理的，尤其是当你需要在不同地方使用相同的功能时。
有时代码只是暂时相同，不应该合并。
与 DRY 相反，当代码不够 DRY 时，可能会导致只在需要改变的地方修改，而不是所有地方。
应该保持那些预期行为相同的事物的 DRY。
有时复制粘贴代码是合理的，尤其是当你需要在不同地方使用相同的功能时。
有时代码只是暂时相同，不应该合并。
有时应该复制粘贴代码，因为那些代码块可以独立发展。
有时代码只是暂时相同，不应该合并。

Show HN: Hacker News em dash user leaderboard pre-ChatGPT #

https://www.gally.net/miscellaneous/hn-em-dash-user-leaderboard.html

这个网页是一个关于 Hacker News 上使用 em dash（—）最多的用户排行榜的列表。排行榜列出了前 50 名用户，他们在使用 em dash 方面最为活跃。列表显示了每个用户的用户名、em dash 帖子的数量、首次发表 em dash 帖子的日期以及最后一次发表 em dash 帖子的日期。排名第一的用户是 derefr，共发表了 4,247 篇含有 em dash 的帖子，从 2009 年 4 月 12 日开始，直到 2022 年 11 月 30 日。紧随其后的是 dang 和 dragonwriter，分别以 4,234 和 1,428 篇 em dash 帖子位列第二和第三。这个列表还提供了一个更完整的版本链接和一个关于这个排行榜的 Hacker News 讨论链接。

HN 热度 274 points | 评论 220 comments | 作者：tkgally | 20 hours ago #

https://news.ycombinator.com/item?id=45071722

使用 em dash 可能让人怀疑文本是 AI 生成的。
dang 建议创建一个排行榜，列出在 ChatGPT 发布前使用 em dash 的 HN 用户。
Claude Code 展示了如何通过 Google BigQuery 搜索 HN 数据库，并编写了排行榜的 HTML。
em dash 的使用随年份增加。
zmgsabst 使用 em dash 最多，westoncb 使用第四多。
有些人认为 em dash 应该带空格，有些人认为不带。
美国键盘布局没有 em dash 或 en dash，只有连字符。
改变过滤器后，westoncb 的使用比例最高。
westoncb 声称自己是 LLMs 使用 em dash 的原因。
有些人认为没有空格的 em dash 看起来不舒服。
有些人认为正确的用法是 em dash 前没有空格，后有一个空格。
英语中没有“正确用法”，都是共识。
有些人建议排名时也考虑双连字符的使用。
在 MacOS 上，使用 em dash 更为方便。
em dash 和 en dash 在不同键盘布局中可能不同。
在 Linux 上，可以通过设置组合键来输入 em dash 和 en dash。
有些人因为 MacOS 自动添加 em dash 而停止使用它们。
有人因为 Reddit 评论中使用 em dash 而被错误地认为是使用 ChatGPT。

Nokia’s legendary font makes for a great user interface font #

https://www.osnews.com/story/143222/it-turns-out-nokias-legendary-font-makes-for-a-great-general-user-interface-font/

这篇文章讨论了诺基亚的传奇字体——Nokia Sans（以及 Nokia Serif）——作为用户界面字体的可能性。这种字体在 2002 年至 2013 年间被几乎所有诺基亚设备使用。作者出于怀旧情怀，尝试将 Nokia Sans Wide 变体作为用户界面字体，并发现其在多种尺寸下都非常易读，且具有个性而不过分张扬。尽管这种字体仍然归诺基亚所有，作者还是通过一个网站下载并安装了各个变体，并最终选择了 Nokia Sans Wide 作为他的用户界面字体。文章中提到，字体的创始人 Erik Spiekermann 曾对诺基亚更换字体的决定表示不满，并特别推荐 Wide 变体。作者还提到，这种字体在高 DPI 显示器上的表现很好，但他不确定在 Windows 或 macOS 系统上，或者在低 DPI 显示器上的表现如何。最后，作者提到了字体下载的法律问题，并表示他不确定下载这些字体是否合法，但他相信至少可以用于个人非商业用途。

HN 热度 262 points | 评论 87 comments | 作者：rguiscard | 11 hours ago #

https://news.ycombinator.com/item?id=45074071

Nokia 的字体因其良好的显示效果和高辨识度，非常适合用作用户界面字体。
UI 字体需要良好的 hinting 以适应低像素密度的显示设备，并且通常具有较高的 x-height 以便于字符识别。
Inter 字体因其平淡无奇而受到批评，被认为缺乏个性。
Inter 字体在低 DPI 显示器上的表现使其成为推荐字体之一。
有人认为 UI 在不同 DPI 的显示器上使用相同字体是不必要的，应该允许用户自定义字体。
有人反对改变字体仅仅因为窗口从一个高 DPI 显示器移动到低 DPI 显示器。
有人提到苹果自 2012 年以来一直在销售高 DPI 屏幕的笔记本电脑，而许多 PC 笔记本电脑也配备了高 DPI 屏幕。
Inter 字体因其在不同平台上的一致性而受到一些人的喜爱。
Lucida Grande 字体因其时代特色而受到赞赏，但在非苹果系统下看起来有些奇怪。
有人认为 Nokia 手机在美国文化中非常普遍，不理解为何有人对 Nokia 有负面看法。
Nokia 在美国市场失去份额的原因之一是他们坚持在手机上使用 SIP 客户端，导致美国运营商停止销售他们的手机。
有人指出 Nokia 在 iPhone 发布之前就已经失去了北美市场。
有人认为 Nokia 的 5210 是最佳手机，因为它坚固、便宜、续航时间长，即使被压过也能继续使用。
有人认为 Nokia 的 3310 系列手机在耐用性方面非常出色。

Why Romania excels in international Olympiads #

https://www.palladiummag.com/2025/08/29/why-romania-excels-in-international-olympiads/

罗马尼亚在国际奥林匹克竞赛中表现卓越，尤其在数学、物理、信息学等领域。自 2020 年以来，罗马尼亚在国际数学奥林匹克竞赛（IMO）中成绩斐然，2022 年排名第五，2023 年第四，2024 年第十二。在其他学科的奥林匹克竞赛中也有出色表现。尽管罗马尼亚在国际评估中的总体教育表现并不突出，且人口仅有 1900 万，但其在奥林匹克竞赛中的表现堪称奇迹。

罗马尼亚的教育系统设计独特，可能是其在国际智力竞赛中成为异类的原因。19 世纪末，罗马尼亚王子阿列克山德鲁·伊奥安·库扎试图通过建立免费学校提高国家地位，但成效有限。二战后，罗马尼亚共产党政府开始进行教育改革，1948 年通过教育法，动员全社会力量消除文盲，到 1950 年代末，青少年文盲几乎被消除。

罗马尼亚的教育系统在共产党时期模仿苏联模式，包括政治宣传和体力劳动。该系统过度扩张学校，导致设施质量差但普遍存在。与苏联学校系统类似，罗马尼亚的教育系统特点是义务教育年限增加、合格教师和教育物资供应不足、预算成本高、学历膨胀严重。

共产主义政权倒台后，新民主政府关闭了许多学校，降低了义务教育要求，结束了苏联影响带来的官僚噩梦。在随后的年份里，如何合理分配教育资源成为激烈辩论的话题，最终形成了一种强烈的共识，即无论采用何种系统，罗马尼亚教育都将具有竞争性。

如今，罗马尼亚最负盛名的高中是国立学院（Colegiu Național），这些学校往往具有国际性和悠久的教育传统。其次是理论高中（Liceu Teoretic），提供标准教育。罗马尼亚还有三所军事学院，由国防部直接管理。此外，还有服务学校、技术学校、职业学校和学徒项目。最优秀的学生在完成 8 年级（约 14 至 15 岁）的国家安置测试后，可以选择这些学校。

罗马尼亚高中入学测试是涵盖罗马尼亚语言文学和数学的标准化测试。考试成绩公开报告，学生获得 1 至 10 分的评分，精确到小数点后两位。得分高的学生可以选择任何学校，而得分 5.00 或以下的学生通常只能选择职业教育等非学术教育。大多数学生选择他们能进入的最好学校，因此学校之间的分流程度非常高。此外，学校内部也常有分流，学生选择教育轨道，这在申请学校时直接进行。

罗马尼亚高中结束时有毕业考试，即学士学位考试（Bacalaureat，简称 bac）。这个考试与入学考试类似，要通过，学生必须在他们选择的科目中获得至少 5 分。这个测试包括书面和口头考试、外语和计算机技能评估，以及对少数民族学生母语（非罗马尼亚语）技能的评估。根据学生打算就读的大学，这个考试的分数要求从及格到高分不等。

罗马尼亚的教育系统设计使其成为世界上最分层的教育系统之一。他们拥有一个集中存储所有学生和教师教育数据的中央数据库，使得系统非常适合进行高能评估，以了解一个国家选择超分层教育时会发生什么。

HN 热度 211 points | 评论 215 comments | 作者：collate | 24 hours ago #

https://news.ycombinator.com/item?id=45070793

罗马尼亚在国际奥赛中表现出色，因为该国的教育体系重视进入好学校，并且高中课程内容密集，有大量的课后竞赛培训项目。
罗马尼亚更擅长从小筛选和培养有智力潜力的人，但在普及教育方面做得不好。
教育普及很重要，否则会导致因选民无知而被操纵的失败民主。
应该为优秀学生设立单独的培养轨道，以免浪费他们的潜力。
高等教育普及是危险的，尤其是当没有足够的工作机会时，会导致毕业生过剩。
精英过剩是导致社会崩溃的一个因素，但这更多是社会问题而非教育系统的问题。
对于历史预测的数学模型持怀疑态度，认为历史数据不足以支持这种模型。
社会崩溃的预测可能会改变人类行为，从而影响原始预测。
精英过剩自然会导致社会动荡，无论是革命还是混乱的民粹主义选举。
智能成就者总能找到工作，未能让他们工作更多是社会失败而非教育系统的指责。
精英供应和精英职位之间常常存在不匹配，精英职位稀缺是定义上的问题。
在小规模经济体中，即使智能成就者创业，选项也更有限。
人工智能似乎更有可能增加而不是解决现有的就业不足问题。
历史上的许多重大革命或内战都涉及未能获得政治权力的智能成就者。
限制大众投票是保持权力不被大众掌握的一种方式。
任何即将退休的政治家都会关心支持率，民主不仅仅是每四年投票一次。

Agent Client Protocol (ACP) #

https://agentclientprotocol.com/overview/introduction

Agent Client Protocol（ACP）是一种标准化代码编辑器（如 IDE、文本编辑器等）与编程代理（使用生成性 AI 自动修改代码的程序）之间通信的协议。该协议仍在开发中，但已足够成熟，可以用于构建有趣的用户体验。

ACP 的出现是为了解决 AI 编程代理和编辑器之间紧密耦合但缺乏互操作性的问题。每个新代理-编辑器组合都需要定制工作，导致兼容性有限，开发者在选择代理时往往受限于可用的接口。ACP 通过提供标准化的代理-编辑器通信协议来解决这些问题，类似于语言服务器协议（LSP）标准化了语言服务器集成。

遵循 ACP 的代理可以与任何兼容的编辑器一起工作，而支持 ACP 的编辑器可以获得整个 ACP 兼容代理的生态系统。这种解耦允许双方独立创新，同时给予开发者选择最适合他们工作流程的工具的自由。

ACP 假设用户主要在编辑器中，希望使用代理来协助完成特定任务。代理作为代码编辑器的子进程运行，并通过 stdio 使用 JSON-RPC 进行通信。协议尽可能重用 MCP 中使用的 JSON 表示，但也包括自定义类型，用于有用的代理编码用户体验元素，如显示差异。

用户可读文本的默认格式是 Markdown，它允许足够的灵活性来表示丰富的格式，而不需要代码编辑器能够渲染 HTML。

目前支持的编辑器包括 Zed 和通过 CodeCompanion 插件支持的 neovim。支持的代理包括 Gemini，未来还会有更多代理加入。

HN 热度 201 points | 评论 64 comments | 作者：vinhnx | 11 hours ago #

https://news.ycombinator.com/item?id=45074147

Gemini 可以编写 Sublime Text 插件来实现这个协议
通过编写 emacs 插件实现了类似功能，但没有使用这个协议
尝试让 AI 编写自己的 Sublime Text 插件以支持 ACP 协议
通过让 Gemini 成为唯一支持的代理来掩盖行动
对 ACP 协议的期待，希望它能够回归合作的本质并颠覆代理 IDE 类别
Zed 编辑器拥有用户多年来想要的一切功能，并且还有其他令人惊喜的特性
由于缺乏并排差异视图，用户从 Zed 回到了 Cursor/VSCode
希望 ACP 能够结束糟糕的 VS Code 分支，让 Zed 得到应有的认可
对 ACP 协议的实现和标准化持积极态度
存在另一个同名的 ACP 协议，可能会造成混淆
IBM 宣布放弃 ACP 名称，将其与 Google 的 A2A 协议合并
即使有了 A2A 协议，仍然需要标准化客户端“表面”或“API”
正在编写一个工具，使 Claude Code 能够使用 ACP
希望 Anthropic 能够为 Claude Code 采用 ACP，并提供与 VS Code 类似的集成
出现了 Claude Code 的 ACP 实现的初步迹象
疑问为什么不能使用 LSP 服务器或扩展 LSP 协议来提供 LLM 所需的一切
考虑开发 JSON over SSE，以适应 GitHub Codespaces、devcontainers 或“后台代理”等解决方案
将 AI 视为人类开发者，通过“提示编码”与 AI 互动，无需在编码环境和 AI 之间进行交互

AI models need a virtual machine #

https://blog.sigplan.org/2025/08/29/ai-models-need-a-virtual-machine/

本文讨论了人工智能（AI）模型在软件系统中的集成问题，并提出了将 AI 模型嵌入软件的方式标准化，将其视为一种虚拟机（VM）。文章指出，随着 AI 模型能力的提升和扩展机制（如 MCP 协议）的定义，调用 AI 模型的控制软件复杂性增加。AI 软件系统需要具备操作系统所提供的安全、隔离、可扩展性和可移植性等特性。例如，当 AI 模型需要文件作为上下文时，必须建立访问控制以确定模型是否被允许查看该文件。

文章提出，将控制软件层视为虚拟机，其中一个指令是调用大型语言模型（LLM）。这种方法将模型开发与集成逻辑解耦，允许任何模型“插入”到包含工具、安全控制、内存抽象等的丰富软件生态系统中。类似于 Java 虚拟机（JVM）的影响，为 AI 编排器创建 VM 规范可以为 AI 模型提供一个“一次编写，随处运行”的执行环境，同时提供熟悉的约束和治理，以维护现有软件系统中的安全性和隐私。

文章还介绍了 AI 模型虚拟机（MVM）如何与 AI 模型和外部环境交互的例子。MVM 在模型和外部世界之间起到中介作用。例如，聊天机器人用户输入的提示（1）由 MVM 发送到 AI 模型（2），MVM 还会添加额外的上下文，如系统提示、聊天历史记录。AI 模型生成的响应需要调用特定工具（3），响应格式是模型和 MVM 之间共同约定的，如 MCP。在例子中，由于需要限制模型进行不希望的工具调用，MVM 首先检查允许的工具列表（4），然后决定调用模型请求的工具（5）。这种检查（4）确保模型不会进行未经授权的工具调用。

文章还讨论了现有的工作如何为 AI 虚拟机所需的接口提供信息。例如，OpenAI 的结构化工具调用协议和 Anthropic 的模型上下文协议（MCP）展示了结构化工具调用协议如何减少歧义并简化集成。此外，还有两个项目提出了运行时级别的控制，以增强 AI 系统的安全性。这些项目展示了标准 AI VM 如何包含内置的安全和访问控制，就像现代操作系统一样。尽管如此，AI 模型在设计时仍需考虑新的安全挑战，例如，当 AI 模型被阻止访问特定数据时，可能会使用其推理能力来收集可访问数据，从而推断出不可访问的数据。因此，安全研究人员需要设计新的缓解措施，以防止 AI 模型即使在虚拟机约束下采取对抗性行动。

最后，文章提到了一些正在积极构建 AI 通用运行时的项目，如 langchain 和 Semantic Kernel，它们提供了许多常见的运行时服务，使编写可靠的 AI 应用程序变得更容易。AI 控制器接口（AICI）将轻量级 VM 集成到模型服务管道中，允许开发人员在低级别（例如，逐令牌控制生成）脚本化和限制模型行为。

HN 热度 159 points | 评论 94 comments | 作者：azhenley | 10 hours ago #

https://news.ycombinator.com/item?id=45074467

有人认为这篇文章并没有为编写新的操作系统或虚拟机提供强有力的理由，而是更多关注于访问控制。
有人认为 WebAssembly 的沙箱模式已经接近所需的功能，只需要定义清晰的接口来在实例之间传输数据和访问权限。
有人提到 WASI 组件已经实现了这一点。
有人认为这篇文章并没有提出创建新操作系统的观点，而是讨论了为 AI 构建执行环境。
有人指出，当前的 AI 代理已经运行在虚拟机中，例如 MCP 主机可以提示用户执行操作，并可以有类似 Claude 代码中的规则自动允许某些命令模式。
有人认为问题不在于提供给 LLM 的工具，而在于 LLM 可以执行的动作。
有人提到，需要明确 LLM 的意图，而不是它执行的动作，LLM 应该被放置在与它代表的用户相同的“盒子”中。
有人讨论了能力安全模型，指出没有主流操作系统实际实现了这种模型，而虚拟机是最接近的能力安全模型。
有人质疑在网络对操作系统来说基本上是一个大型黑盒的情况下，如何在用户代理 LLM 的上下文中实现“能力”。
有人指出，要实现能力安全模型，需要重写现代生活中使用的大部分软件。
有人提到 iOS 和 Android 都为它们的应用实现了能力安全模型，并建议我们应该借鉴操作系统的工作方式。

From multi-head to latent attention: The evolution of attention mechanisms #

https://vinithavn.medium.com/from-multi-head-to-latent-attention-the-evolution-of-attention-mechanisms-64e3c0505f24

注意力机制是自回归模型中用于预测未来标记的关键技术，它允许模型有选择性地关注与当前输出标记相关的上下文词。注意力机制的核心在于动态地对输入的相关部分进行加权和聚焦。在编码和解码阶段都需要注意力机制，本文将从解码器的角度讨论注意力机制的基本概念和不同类型。

注意力机制的主要思想是动态地对输入的相关部分进行加权和聚焦。在每个生成步骤中，我们需要理解注意力权重，这有助于我们为下一个词预测获得更好的上下文表示。注意力机制的核心组件包括查询（Q）、键（K）和值（V），它们与注意力分数一起工作，创建一个灵活的、上下文感知的向量表示。

在多头注意力（MHA）中，计算第 i 个标记的注意力权重时，首先为该标记计算一个查询向量。然后，将这个查询向量与所有前面的标记进行比较，为此计算所有前面标记的键向量。这些比较将产生一个注意力分数，然后使用相应的值向量为每个标记产生加权分数。多头注意力通过并行处理多个注意力“头”来重复此过程，每个头都有自己的查询、值和键向量，用于计算词之间的关系。最终的输出上下文向量将是所有注意力头的输出的连接。

多查询注意力（MQA）解决了 MHA 中存储和处理每个注意力头的独立键和值向量所带来的高计算和内存开销问题。MQA 通过使用多个查询头但共享一组键和值向量来解决这个问题。这意味着，尽管模型仍然使用“h”个不同的查询投影从多个角度关注当前标记，但每个头都使用相同的键和值向量。这种方法大大减少了内存带宽需求，而不会显著牺牲模型性能。

分组查询注意力（GQA）在 MHA 和 MQA 之间提供了一种平衡。GQA 将查询头分成“g”组，并允许每个组共享一个共同的键和值头。MHA 和 MQA 是 GQA 的两个极端情况，其中 g=1 导致 MQA，g=h 导致 MHA。这种方法与 MHA 相比减少了内存和计算需求，同时保持了比 MQA 更好的性能。

HN 热度 148 points | 评论 36 comments | 作者：mgninad | 18 hours ago #

https://news.ycombinator.com/item?id=45072160

论文《Attention Is All You Need》的标题直接指向了当时研究人员的需求，表明不需要复杂的系统就能实现 NLP 的成功。
变压器模型抛弃了其他复杂性，仅依赖注意力机制捕捉长距离依赖关系，虽然一开始不切实际，但随着硬件的进步，证明了其可行性。
研究重点曾集中在循环模型上，因为这是当时对序列建模的共识，但后来发现固定大小向量限制了编码器/解码器架构。
注意力机制被添加到解码器中以解决信息丢失问题，每个解码步骤都可以关注源句子的每个标记。
论文标题意味着不需要 RNN，可以完全用注意力机制替代编码器和解码器。
注意力机制只是局部启发式，我们需要范式转变以实现更进一步的发展。
变压器设计初衷是为了改进序列到序列架构，并不适用于所有 AI 需求。
指出变压器的局限性并不需要立即提供替代方案，这有助于推动研究和改进。
指出现有技术的局限性是研究过程的一部分，即使没有立即的替代方案。
目前没有看到能够超越变压器的架构，尽管怀疑它们不是最佳架构，但它们设定了一个高门槛。
指出变压器的缺陷很容易，但提出更少缺陷的方案却很难。
研究不仅限于大规模训练模型，也可以通过比较小模型在相同数据上的表现来测试新架构。

SQLite’s documentation about its durability properties is unclear #

https://www.agwa.name/blog/post/sqlite_durability

问题核心

SQLite 对“持久性（durability）”的默认行为和文档写得非常模糊，导致开发者无法确定在什么配置下事务不会因系统崩溃或掉电而丢失。

两个关键参数

journal_mode：常用 DELETE 或 WAL
synchronous：EXTRA / FULL / NORMAL / OFF

作者根据官方文档得出的结论

默认 journal_mode=DELETE、synchronous=FULL 时，SQLite 并不具备持久性。
若把 journal_mode 改为 WAL，且 synchronous=FULL，则具备持久性。

与官方说法冲突

SQLite 作者 Richard Hipp 在 Hacker News 上声称：

“默认配置下 SQLite 是持久的。”
“改成 WAL 后，默认反而可能不持久。”

这与文档及作者实测结果相反，且 Hipp 未进一步解释。

其他陷阱

一些封装库（如 Go 的驱动）在 WAL 模式下会把 synchronous 调成 NORMAL，从而破坏持久性。
macOS 上 fsync 被削弱，需要额外打开 fullfsync 才能保证真正落盘。

实用建议

如果你的应用需要持久性，不要依赖默认值。– WAL 模式：显式设置 synchronous=FULL。– DELETE 模式：保险做法是用 synchronous=EXTRA。
若面向 macOS，启用 fullfsync。

呼吁

SQLite 项目应把“journal_mode × synchronous 组合是否持久”做成一张清晰的表格，而不是把说明散落在多处，让开发者自己猜。

HN 热度 143 points | 评论 56 comments | 作者：ciconia | 1 day ago #

https://news.ycombinator.com/item?id=45066999

有人认为 SQLite 的持久性定义不明确，需要根据不同的故障情况来讨论持久性。
有人提到在使用 SQLite 时遇到了 MicroSD 卡产生坏扇区、写入时断电和使用假冒 MicroSD 卡等问题。
有人指出 SQLite 在默认设置下不提供持久性，因为默认的 journal_mode 是 DELETE，而 synchronous 是 FULL，这在 DELETE 模式下并不提供持久性。
有人表示，SQLite 的文档描述了每个选项控制的具体内容及其影响，但选择哪个选项仍然存在疑问。
有人提到，如果切换到 WAL 模式，事务在应用崩溃时是持久的，但在操作系统崩溃或电源故障时则不一定。
有人发现 SQLite 文档比 PostgreSQL 文档更难理解，并且 SQLite 创始人的评论与文档的理解相反。
有人认为 SQLite 的默认行为是将事务数据写入磁盘并删除回滚日志，但回滚日志的删除没有 fsync，可能导致系统崩溃后丢失最后一个事务。
有人解释说，在 DELETE 模式下，事务直到回滚日志文件被删除才算提交，如果删除回滚日志的目录没有 fsync，那么在电源故障后回滚日志可能会重新出现，导致 SQLite 回滚已提交的事务。
有人指出，目录的 fsync 应该由文件系统/操作系统完成，而不是应用程序。

Hacker News 精彩评论及翻译 #

Flunking my Anthropic interview again #

https://news.ycombinator.com/item?id=45065311

One great piece of advice an informal mentor gave me long ago is that there is no information in a rejection.

That is to say that you cannot draw any conclusions about yourself or your interviewing technique or your skills or anything from the single accept==0 bit that you typically get back. There are so many reasons that a candidate might get rejected that have nothing to do with one’s individual performance in the interview or application process.

Having been on the hiring side of the interview table now many more times than on the seeking side, I can say that this is totally true.

One of the biggest misconceptions I see from job seekers, especially younger ones, is to equate a job interview to a test at school, assuming that there is some objective bar and if you pass it then you must be hired. It’s simply not true. Frequently more than one good applicant applies for a single open role, and the hiring team has to choose among them. In that case, you could “pass” and still not get the job and the only reason is that the hiring team liked someone else better.

I can only think of one instance where we had two great candidates for one role and management found a way to open another role so we could hire both. In a few other cases, we had people whom we liked but didn’t choose and we forwarded their resumes to other teams who had open roles we thought would fit, but most of the time it’s just, “sorry.”

jp57

很久以前一位前辈给我的一个很棒的建议是，拒绝信里没有信息。也就是说，你无法从那封单纯的“不录用”通知中，对自己、你的面试技巧、你的技能或任何方面做出任何判断。求职者被拒绝的原因有很多，这些原因与个人在面试或申请过程中的表现毫无关系。

如今，我作为招聘方坐在面试桌前的次数，远多于作为求职方。我可以肯定地说，这一点完全正确。

我见过求职者，尤其是年轻求职者，最大的误解之一，就是认为求职面试就像学校里的考试，认为有一个客观的分数线，只要过了这个分数线就一定会被录用。这完全是错误的。通常，一个职位空缺会有不止一位优秀的申请人，招聘团队必须从中择优录取。在这种情况下，你虽然“达标”了，但依然可能得不到这份工作，唯一的原因就是招聘团队更喜欢另一位候选人。

我只能想到一个例子，当时我们有一个职位，但有两个非常优秀的候选人，管理层想方设法又开放了一个职位，这样我们才能把两个人都招进来。在其他少数情况下，我们会遇到一些我们很欣赏但最终没有选择的人，我们会把他们的简历推荐给其他我们认为有合适空缺的团队，但大多数时候，结果都只是“很遗憾”。

Grok Code Fast 1 #

https://news.ycombinator.com/item?id=45066063

Tested this yesterday with Cline. It’s fast, works well with agentic flows, and produces decent code. No idea why this thread is so negative (also got flagged while I was typing this?) but it’s a decent model. I’d say it’s at or above gpt5-mini level, which is awesome in my book (I’ve been maining gpt5-mini for a few weeks now, does the job on a budget).

Things I noted:

It’s fast. I tested it in EU tz, so ymmv
It does agentic in an interesting way. Instead of editing a file whole or in many places, it does many small passes.
Had a feature take ~110k tokens (parsing html w/ bs4). Still finished the task. Didn’t notice any problems at high context.
When things didn’t work first try, it created a new file to test, did all the mocking / testing there, and then once it worked edited the main module file. Nice. GPT5-mini would often times edit working files, and then get confused and fail the task.

All in all, not bad. At the price point it’s at, I could see it as a daily driver. Even agentic stuff w/ opus + gpt5 high as planners and this thing as an implementer. It’s fast enough that it might be worth setting it up in parallel and basically replicate pass@x from research.

IMO it’s good to have options at every level. Having many providers fight for the market is good, it keeps them on their toes, and brings prices down. GPT5-mini is at 2$/MTok, this is at 1.5$/MTok. This is basically “free”, in the great scheme of things. I ndon’t get the negativity.

NitpickLawyer

昨天我用 Cline 测试了这个。它速度很快，代理流程运行良好，并且生成的代码质量不错。不知道为什么这个帖子的评论这么负面（我在打字的时候也被标记了？），但这确实是个不错的模型。我觉得它至少达到了 GPT-5 Mini 的水平，甚至可能更好，在我看来这非常棒（我已经主要使用 GPT-5 Mini 几周了，它很划算，能以实惠的价格完成任务）。

我注意到几点：

速度很快。我用欧洲的时区测试的，所以你的体验可能有所不同。
它执行代理任务的方式很有趣。它不是一次性编辑整个文件或文件中很多地方，而是进行许多次小的修改。
有一个功能消耗了约 11 万个 tokens（用 BeautifulSoup4 解析 HTML）。它仍然完成了任务。在高上下文模式下没有发现任何问题。
当第一次尝试不奏效时，它会创建一个新文件进行测试，并在里面进行所有模拟/测试工作，一旦成功，再编辑主要的模块文件。挺巧妙的。
GPT-5 Mini 经常会编辑正在工作的文件，然后会变得混乱，最终导致任务失败。

总而言之，还不错。以它的价格来看，它可以成为我日常的主力工具。甚至可以让 Opus 和 GPT-5 High（高配版）作为规划者，然后由它来作为执行者。它的速度足够快，值得将其设置为并行运行，来基本上模拟研究中的 Pass@X 机制。

在我看来，在每个层级上都有选择是好事。有多家提供商争夺市场是好事，这能让他们保持警惕，并能降低价格。GPT-5 Mini 的价格是 2 美元/百万 token，而这个是 1.5 美元/百万 token。从大局来看，这个价格基本上就是“免费”的了。我不明白为什么会有这么多负面评价。

Do the simplest thing that could possibly work #

https://news.ycombinator.com/item?id=45070127

This is the classic misunderstanding where software engineers can’t seem to communicate well with each other.

We can even just look at the title here: Do the simplest thing POSSIBLE.

You can’t escape complexity when a problem is complex. You could certainly still complicate it even more than necessary, though. Nowhere in this article is it saying you can avoid complexity altogether, but that many of us tend to over-complicate problems for no good reason.

sodapopcan

这是一个经典的误解，即软件工程师们似乎无法很好地相互沟通。

我们甚至可以只看一下这个标题：做尽可能简单的事。

当一个问题很复杂时，你无法逃避其复杂性。不过，你当然也可以让它比必要的还要复杂。本文丝毫没有说你可以完全避免复杂性，而是说我们中的许多人往往会毫无理由地把问题过度复杂化。

Do the simplest thing that could possibly work #

https://news.ycombinator.com/item?id=45069135

I think this works in simple domains. After working in big tech for a while, I am still shocked by the required complexity. Even the simplest business problem may take a year to solve, and constantly break due to the astounding number of edge cases and scale.

Anyone proclaiming simplicity just hasnt worked at scale. Even rewrites that have a decade old code base to be inspired from, often fail due to the sheer amount of things to consider.

A classic, Chesterton’s Fence:

“There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.””

codingwagie

我认为这在简单的领域是可行的。在大科技公司工作了一段时间后，我仍然对其所需的复杂性感到震惊。即使是商业上最简单的问题，也可能需要一年的时间来解决，而且会因为异常案例数量惊人且规模庞大而屡次失败。

任何标榜简单的人，只是因为还没有经历过规模化开发。即便是能借鉴一个十年历史的代码库进行重写，也常常因为需要考虑的因素实在太多而以失败告终。

一个经典例子，切斯特顿的栅栏：

“在这种情况下，存在着某种特定的制度或法律；为了简单起见，我们不妨称其为跨道路而建的栅栏或大门。那种新型的改革者兴高采烈地走到它面前，说道：‘我看不出这个有什么用，我们把它拆了吧。’对此，更明智的改革者会这样回应：‘既然你看不出它的用处，那我自然不会让你把它拆掉。你先回去好好想想吧。’直到你回来告诉我，你已经看出了它的用处，我才会允许你把它毁掉。’”