1. 一根 10 美元的 OpenStick，能在家里跑哪些服务？ (What I run on my $10 USD OpenStick homelab)
博主 Bosscher 花了 10 美元（含运费）买下一根 OpenStick，刷入 Debian，把这台原本带有 4G 调制解调器的小设备用作家用服务器。它有四颗 1 GHz 的 Cortex-A53 核心、512 MB 内存和 4 GB 闪存，靠被动散热运行。其中约 450 MB 内存可用，所以他挑的服务大多只占几十 MB。CastSponsorSkip 为 Google Cast 设备跳过视频里的赞助片段，AdGuard Home 的自改版在域名解析时拦截清单中的请求。Beszel 记录整台机器的资源使用情况，Gatus 检查各项服务是否在线。作者还让 ZeroClaw 接入 Telegram，方便出门时查询设备日志和剩余磁盘空间。他给了代理相当于管理员的权限，但把访问范围限制在这台设备上。机器上也跑着 RSS 阅读器和会自动存档网页的书签工具，后者保存页面时会短暂多占一些内存。
原文链接：https://blog.bosscher.ch/posts/openstick/
论坛讨论链接：https://news.ycombinator.com/item?id=50406670
讨论从这么小的机器能跑什么，转到同样的配置能不能买到。作者说设备来自 AliExpress，但卖家通常不注明芯片的具体型号，买到的机器未必和帖子里那根一样。也有读者点进链接看到的是 20 美元。有人回忆以前用双奔腾 II、512 MB 内存的服务器托管 Perl 网站，每台就能承载数百名并发用户。这个例子让不少轻量服务的内存开销有了参照。还有人想用它给路由器加上 4G，或让它经由移动网络充当远程串口控制台，在讨论里询问 USB 网络和键鼠模拟能否实现。
2. llama-modchip 在 64 GB 内存上用 CPU 跑起 2840 亿参数的 DeepSeek (Llama-modchip: 284B DeepSeek on 64GB RAM, no GPU)
llama-modchip 是一套给 llama.cpp 加上量化和 CPU 优化的工具。测试使用 16 核 Ryzen 9 9955HX 和 64 GB 内存，在不用 GPU 的情况下运行了 DeepSeek-V4-Flash。这个混合专家模型共有约 2843 亿参数，但处理每个词元时只激活约 132 亿参数。其余权重也要存放。
项目将模型权重压缩到平均每个权重约 1.71 比特，按张量选择不同精度，把模型文件从原量化版本的 76.87 GiB 缩至 56.56 GiB。项目称，连同 256K 词元上下文的缓存，进程实际占用不到 59 GiB。测试中，处理提示的速度约为每秒 43 至 44 个词元，保留每层选中的六个专家时，生成速度约为每秒 9 至 10 个词元。用先猜测、再批量验证后续词元的方法，报告的速度达到每秒约 11.5 至 14.7 个词元。
原文链接：https://github.com/synchopate/llama-modchip
论坛讨论链接：https://news.ycombinator.com/item?id=50411961
HN 讨论追问的是，模型塞进内存后还能保留多少能力。有人引用量化研究，担心位宽过低会影响效果。回复提醒，论文结论受模型和算法的范围限制，例如没有涵盖训练时就考虑低精度的做法，不能直接套用到所有低位宽模型。
也有人用实际任务衡量速度。一位读者认为 128 GB 统一内存的设备已能以可接受的速度运行编程代理，另一位使用 128 GB M5 的读者则更愿意让任务在夜里自己跑，坐在电脑前等仍嫌慢。另一位读者在 96 GB 内存的旧 Xeon 上测试，遇到张量形状不匹配和非法指令。
3. 一位开发者为何把主力编程工具从 Claude Code 换成 Pi (Goodbye Claude, hello Pi)
长期使用 Claude Code 的开发者 Caleb 把主力编程工具换成了开源的 Pi。两者都在模型之外处理文件读写、命令执行和对话上下文。Caleb 常在 VS Code 里逐段审查代码，选中文字后直接让助手解释或修改，但他发现 Claude Code 的终端版同一时间只有一个会话能接收编辑器选区。官方图形扩展能在多个标签页接收选区，却有部分斜杠命令无法使用，多个子代理的输出也会交错显示。他还抱怨项目指令文件过去要在 CLAUDE.md 和 AGENTS.md 之间做兼容，以及更新频繁改动系统提示和工具说明，可能改变模型遵循项目约定的方式。他在文中提到，Anthropic 随后宣布支持 AGENTS.md。迁到 Pi 的头几天也需要调整，但它留给扩展的空间更大。他说自己花约 20 分钟写了一个扩展，就让多个标签页都能接收编辑器选区。
原文链接：https://caleb.software/posts/claude-to-pi.html
论坛讨论链接：https://news.ycombinator.com/item?id=50410107
HN 上有人把问题看作控制权和日常维护之间的取舍。一位 Pi 用户看重可以用命令在会话分支间跳转，还能用 Neovim 编辑提示词，并在同一套工具里切换模型。另一位读者同时开许多项目，改用桌面应用后可以在一个窗口切换会话，展开需要细看的命令输出，省去为每个仓库开编辑器的麻烦。也有人提醒，模型接到的上下文与工具调度方式会影响表现。一位读者说自己用第三方工具跑编程任务，有时会花掉五倍的 token，结果还更差。这是他自己的实验结果，讨论没有给出统一基准。
4. 研究者发现 iPhone 键盘「灰名单」，部分词组滑不出来 (Apple’s grey list: Words and phrases your iPhone won’t help you spell)
独立研究者 Derik Kauffman 发现，iPhone 键盘内置了一份会过滤输入候选的「灰名单」。《卫报》报道，这份名单收录了超过十万个词和短语，涉及多种语言。它会让键盘上方的建议栏避开某些续写，也会影响滑行输入，也就是手指不离开屏幕、连续滑过几个字母来拼词。报道举例，想滑出 United Ireland，键盘可能给出 United Iceland，把「爱尔兰」换成「冰岛」。研究者原本是在自己的手机上反复遇到某些短语无法滑出的情况，随后从系统的键盘数据中找到了这份表。名单既涉及粗俗措辞，也有看起来很普通的短语，例如「iMessage 无法使用」。苹果回应称，键盘的设计旨在避免给出不当或冒犯性的预测建议。用户仍可逐字母输入所需的词句，也可以改掉系统给出的结果。
论坛讨论链接：https://news.ycombinator.com/item?id=50406111
HN 的争论集中在键盘该多大程度上替用户猜词。有人认为，滑行轨迹本就要靠系统猜测，避开可能令人尴尬的候选有其理由，用户仍可点按输入。发帖者指出，两个词单独都能滑出，连着滑却会被换词。另一位读者试输一个短语，滑完最后一个词才发现键盘改写了前一个词，又没有给出提示。他反复重试才发现需要手动改回。研究者也在楼里回应，有些被过滤的短语很难由手滑误打出来。他主张公开名单，让用户知道哪些词组会被跳过或改写。
5. 重算二战德国 B8 反应堆：铀和重水都差得很远 (Uranium cubes reveal why the German nuclear project failed)
二战末期，海森堡团队在德国海格洛赫搭建了 B8 实验反应堆，把 664 块天然铀悬挂在重水中。重水能减慢中子，帮助裂变持续下去，但装置始终没能达到临界，也就是靠自身维持裂变链式反应。海森堡战后估计，只需把堆芯扩大不到一半就有机会成功。《Ars Technica》报道的这项新研究测量了两块存世铀块，再把测得的材料性质与档案中的重水用量、石墨和堆芯布局一起纳入计算。
论文给出两种临界配置：若尽量少用铀，需要 1,292 块铀和 3,411 升重水；若尽量少用重水，则需 1,775 块铀和 2,966 升重水。原装置只有约 1,400 升重水。即使把研究者估计的德国各组库存集中起来，按 B8 的设计仍达不到临界。论文也模拟了改用石墨来减慢中子的路线，结论是德国当时能取得的石墨含有会吸收中子的杂质，配上现有天然铀同样无法维持反应。
原文链接：https://arstechnica.com/science/2026/11/uranium-cubes-reveal-why-the-german-nuclear-project-failed/
论坛讨论链接：https://news.ycombinator.com/item?id=50377661
HN 讨论先追问铀块究竟提供了什么证据。有读者指出，实物测量发现铀块内部有微小空隙，密度略低于教科书数值；两种材料到底差多少，还要靠档案与反应堆模拟来推算。一位回复者补充，荷兰曾购入一批战时未被德国占领军发现的铀原料，但他也说，无法从这项研究判断那批原料能否改变结果。另一个讨论串提到，石墨里的硼杂质也让曼哈顿计划一度受阻，随后有人借此对比美国采用的石墨路线与德国依赖重水的路线。也有人追问海森堡是否故意算错，那是围绕历史人物动机的猜测，论文检验的是装置本身。
6. 只写四个 2，怎么拼出任意自然数？ (Making any integer with four 2s (2025))
Eli Bendersky 在一篇 2025 年的文章里回顾了一道数字谜题。表达式必须恰好写出四个 2，不能出现其他数字，但可以用数学运算符。用四则运算就能得到不少小数值，例如 (2+2)÷(2+2) 等于 1，2×2+2÷2 等于 5。允许乘方和阶乘之后，可写出的数多了起来，但逐个试算仍然会遇到难拼的目标。
文章介绍了保罗·狄拉克的通用构造。先对 2 连续开平方，每多开一次，指数就减半。连续开七次平方根，指数就变成 2 的负七次方。接着连续取两次以 2 为底的对数。第一次把指数取出来，第二次读出 −7，最后取相反数就得到 7。要得到别的自然数，只需改动根号的个数，表达式里始终不用写出那个目标数字。最初的公式只用到三个 2，分别是被开方的数和两个对数的底。把其中一个底写成 √(2+2)，值保持原样，数字 2 就恰好出现四次。
原文链接：https://eli.thegreenplace.net/2025/making-any-integer-with-four-2s/
论坛讨论链接：https://news.ycombinator.com/item?id=50408713
HN 的争论集中在什么算作「写出了一个数字」。有人把平方根看作省略了根指数 2 的开方，认为每画一个根号都应该计一次。回复指出，平方根符号本身也可以作为独立运算，反过来把除法写成乘以除数的负一次幂，同样会引出原式没写出的数字。还有读者把这条质疑用到了拼接数字上，认为 22 的值也默认了十进制。
规则松紧直接影响具体题目。有人把 2.2 平方后加 2，再向上取整来得到 7，也有人指出禁用乘方时这一招就失效了。另有读者贴出一个相近的编程竞赛作品，把条件改成不限 2 的个数、只用基本运算。
7. GitHub 预览新版 PR 概览，合并条件移到页首 (GitHub New pull request overview page in public preview)
GitHub 开放了拉取请求（PR）新版概览页的公开预览。过去，如果一个 PR 下积累了大量评论和操作记录，开发者往往要滑到页面底部才知道还缺什么才能合并。新版把合并状态和下一步能做的操作提到页首，并将合并模块压缩到原来不到一半的空间。开发者可以先看自动检查、评论和审批的摘要，再进入失败的检查、待审批名单或对应讨论。需要更新分支时，可以从这里操作，条件满足后也可以直接合并。
预览还改了查看活动的方式。讨论可以只显示尚未解决的对话或自己写的评论，也可以按从新到旧排列。右上角的活动摘要提供评审评论、评审邀请等入口。权限允许时，用户还能在页首将草稿标为可评审，或关闭拉取请求。此次预览需要主动开启，入口位于 PR 页首。试用期间，同一个菜单也能切回经典概览。
原文链接：https://github.blog/changelog/2026-11-05-new-pull-request-overview-page-in-public-preview/
论坛讨论链接：https://news.ycombinator.com/item?id=50408931
HN 读者关心的是状态更好找之后，代码和讨论是否也更好审。有人喜欢把自动检查状态和合并按钮放到页首，但也有人试用几周后，仍觉得进入讨论要多点几次。曾开发 CodeApprove 的读者认为这是明显改善，同时希望把代码、未解决的讨论和持续集成检查集中在一页，并支持键盘导航。另一位读者已习惯让代理汇报哪些检查没过、哪些评论待处理，更希望 GitHub 改进看代码的体验。还有人希望优先修复现有流程，据他反馈，点击「就绪后合并」有时并没有把 PR 加入合并队列。
8. Clj.rs 把 Clojure 带进 Rust 生态，可解释执行也可编译 (Clj.rs – a Clojure dialect implemented in Rust)
Clj.rs 是一个用 Rust 实现的实验性 Clojure 方言。它能直接运行自己的 .cljrs 源文件，也能读取可跨平台使用的 .cljc 文件，按当前平台选择其中对应的代码。项目提供交互式命令行，输入一个表达式就能立即看到结果。需要独立部署时，也能通过 Cranelift 把程序提前编译成本机可执行文件。
这个方言保留了 Clojure 的宏和持久化数据结构。后者让集合在更新后保留旧版本，并在版本间共享未变化的部分。Rust 程序可以把 Clj.rs 的运行时嵌进去，用来执行脚本、业务规则或插件。反过来，开发者也可以显式导出 Rust 函数，让 Clojure 代码调用，并在两套类型之间转换参数和返回值。项目把服务于编程智能体列为可能用途，当前仍处于 Alpha 阶段。开发者可通过 crates.io 安装，也可在项目首页在线试用。
原文链接：https://clj.rs/
论坛讨论链接：https://news.ycombinator.com/item?id=50366902
讨论先比宿主互操作。有人举例说，在 JVM 上写 Clojure 可以直接调用 Java 的整数解析方法，而 Clj.rs 的示例需要先把 Rust 函数接进 Clojure 的命名空间，步骤更多。另一位读者说，团队当初正因为 Java 互操作方便才选了常规 Clojure，做命令行工具时又偏爱启动快的 Babashka。也有人提到用 Scheme 脚本热更新 Rust 程序的经验，设想同类方案可用于追求更快启动或更小容器镜像的场景。另有读者反馈网页交互环境在 Safari 中报错。
9. LoreKit 作者提议为编程智能体制定共享记忆格式 (Agent memory needs its OpenTelemetry moment)
代码编辑器、持续集成任务和代码审查机器人可以在同一个仓库里工作，却未必能读到彼此留下的经验。LoreKit 作者 Mads Thines 指出，现有工具有的把经验写成文件，有的保存在托管服务或知识图谱里。现有的可移植格式提案多在解决换工具时如何导出、导入记忆。他关心的另一件事是，多种工具同时工作时，怎样找到并更新同一条记忆。
作者借鉴 OpenTelemetry 的做法，提出先约定一条记录的公共字段，比如适用范围、唯一标识、写入者、内容类型和失效条件。举例说，一条“运行测试前先启动 Postgres”的经验可绑定到具体仓库，并附上相关代码或测试记录。工具还可以通过 MCP 暴露统一的读写、搜索和归档操作，存储和检索排序仍由各自实现。作者认为，共享也让更多来源可以影响智能体，记录写入者并允许签名有助于追查来源。哪些记忆应该默认过期，文章留作公开讨论。
原文链接：https://www.lorekit.io/blog/open-agent-memory-format
论坛讨论链接：https://news.ycombinator.com/item?id=50411467
读者争论的是，统一格式能省掉多少实际工作。有人认为模型本来就能读不同格式的说明文件，一份项目说明指向共用目录，可能就能让不同助手读取同样的笔记。回复指出，模型寻找合适文件也会消耗上下文窗口，让负责调度和检索的程序直接读结构化字段，可以省下反复询问模型的开销。另一派认可互通的方向，但担心大家还没搞清哪些经验值得保留、该保留多久，现在把字段和接口定死会妨碍试验。还有人追问迁移后的引用能否继续使用，因为笔记指向的往往是原来环境里的文件或会话位置。
10. 据报道，高盛限制多数交易员和银行家使用 Claude Code (Goldman Sachs is pulling Claude Code from its bankers and traders)
据彭博看到的高盛十月更新内部指引，Claude Code 和报道所称的 GitHub 工具将主要由工程人员使用，多数交易员和银行家失去访问权限。另一名知情人士说，工作横跨交易、量化研究和软件工程的策略人员仍可使用。据 State of AI 报道，高盛自有的多模型助手仍向全公司开放。
此前，部分交易员用这些工具观察客户交易流向、模拟市场变化和持仓，也用来制作文字和图表。高盛首席信息官七月曾介绍过一种分工，业务人员先做出原型，再交给工程师完善。公司发言人对彭博表示，试用期会评估效率和风险管理，随后把工具交给适合长期使用的人。State of AI 则把焦点放在代码如何进入日常业务。可以读文件并运行程序的助手可能继承使用者的访问权限。如果原型直接用到客户数据上，谁审查脚本、它能访问什么、上线之后由谁维护，都需要有明确的流程。
原文链接：https://www.thestateofai.com/news/goldman-sachs-claude-code-traders-bankers
论坛讨论链接：https://news.ycombinator.com/item?id=50415628
有读者把问题放到交易员的工作电脑上看。如果同一台机器既能读到客户与交易信息，又能接收邮件和访问互联网，半自动运行的助手就可能被外来内容诱导，把敏感数据发送出去。另一串讨论把这些脚本比作曾经支撑业务的复杂电子表格。原型一旦进入关键流程，团队就得有人维护，银行还要留存数据访问和审批记录。也有人说自己的公司因按用量收费频繁超预算而收回权限。这个例子来自其他公司，高盛这次调整的公开报道只提到评估生产效率和风险，并未披露具体触发事件。