元物理学与灵魂在人工智能中的讨论日益增多，包括 Anthropic 与宗教与哲学思想家举办的会议。与此同时，机制可解释性试图理解大型语言模型内部发生了什么，尽管存在资金缺口。为使这些技术可及，作者创建了开源的 TinyGPT Visualizer，一个交互式"X 光"，用于在小型真实模型生成输出时检查其数值内部。该工具旨在帮助用户调研与实践可解释性方法。作者认为，模型产生的任何情感或模式都将在其数字中被发现，哲学与宗教可能需要与定量分析进行对话。代码在 GitHub 上。
每日HackerNews RSS
一篇 Hacker News 帖子链接了用于探索大型语言模型“灵魂”的工具。它获得了 54 个积分和 12 条评论。评论者讨论了大型语言模型可能收敛到相似解，其中一人提到他们让一个 LLM 构建类似工具，得到了几乎相同的结果。原帖作者强调，机制可解释性对任何想学习的人来说都是可及的。评论串还争论了“灵魂”一词：有人称其为虚构或吸引眼球，另一些人认为 AI 缺乏内在生命，不应以拟人化术语描述，而少数人则将“灵魂”捍卫为一种有用且非超自然的、与身体相区分的概念。总体而言，该帖引发了关于模型可解释性的技术讨论，以及关于 AI 能动性与语言的哲学辩论。
绿色飞行：农民为何转向用无人机播种覆盖作物 Flying on Green: Why Farmers Are Turning to Drones for Cover Crop Seeding
2 天前
（无内容可翻译）
Hacker News 的讨论围绕一篇关于农民使用大疆 Agras 无人机播种覆盖作物的文章展开。无人机可以均匀撒播种子并避免土壤压实，尤其适合在玉米成熟前向其撒播小粒种子的覆盖作物。评论者指出，由于联邦审计和列入名单相关担忧，大疆未来在美国的供应情况不确定，并对能否逆转持怀疑态度。其他人争论播种方法：播种机将种子插入土壤，而撒播适用于某些作物和覆盖作物。无人机还用于喷洒肥料和农药，但有效载荷重量和均匀分布很重要。有人指出中心支轴灌溉系统减少了空中喷洒的需求，而无人机有助于小型或不规则田地。总体而言，无人机提供了灵活、低成本的覆盖作物播种和定向喷洒工具，但政策和技术限制仍然存在。
犹他茶壶 The Utah Teapot
2 天前
犹他茶壶是 Martin Newell 于 1974/1975 年使用三次 Bézier 曲面片创建的标志性计算机图形模型。它在 SIGGRAPH 1976 之后声名鹊起，并作为标准测试模型持续出现于许多图形工具和 API 中。该模型可免费用于任何用途，包括商业用途，但需注明其源自犹他大学历史茶壶。主要版本包括 Newell 的原始高身开口茶壶、Blinn 的缩放 3/4 版本、Crow 的圆底 32 曲面片版本、Driskill 的带内腔的裁剪 NURBS 实体、Fish 的改进内腔，以及 Yuksel 2026 年的曲率连续、倒角、更轻的 62 曲面片版本。官方模型还支持对形状、底部、内腔、盖子、纹理坐标和三角剖分进行广泛自定义。
黑客新闻的讨论聚焦于犹他茶壶，这是犹他大学著名的三维图形测试物体。评论者分享个人经历，包括在计算机历史博物馆见到它、在图形学研讨会上获得签名复制品，以及在 OpenGL/GLUT 中使用它。其他人则指出其实体起源（Melitta/Friesland）、各种变体与再版，以及其作为经典图形学图标的的文化地位。相关链接包括之前的 HN 帖子、都柏林雕塑、图形学课程和演示。该帖还赞扬了犹他图形学先驱，并将茶壶与斯坦福模型作比较。总体而言，它凸显了茶壶在计算机图形学和爱好者社群中的持久传承。
Apple 支持社区将于2026年11月20日永久关闭。 The Apple Support Community will permanently close on November 20, 2026
2 天前
Apple 支持社区将于 2026 年 11 月 20 日永久关闭。从今天起，网站将不再接受新帖子，并处于只读状态。你可以继续在官方 Apple 支持网站上找到可信的指导和支持。我们感谢社区成员贡献的时间和专业知识，帮助他人使用 Apple 产品。
Hacker News 用户讨论了苹果宣布其支持社区将于 2026 年 11 月 20 日关闭，目前已设为只读。反应不一：许多人认为该论坛是低价值的非解答、过时修复方案和苹果式辩护回复来源，而其他人则回忆起偶尔有用的变通方法，以及确认普遍性错误的价值。有些人哀叹贡献者积累的知识突然流失，以及苹果与客户日益疏远；另一些人欢迎移除会扰乱搜索结果并可能向 LLM 提供错误信息的内容。担忧包括失去公开反馈、开发者论坛未来可能关闭，以及存档保存。开发者论坛目前似乎不受影响。建议的替代方案包括 Ask Different、MacRumors、Reddit、LLM 和官方苹果支持。
用户可以通过电子邮件和/或短信订阅 GitHub Impact 在 Actions、Pages 和 Copilot 方面的状态更新。电子邮件通知会在事件更新时发送，而短信提醒会在 GitHub 创建或解决事件时发送。要启用短信，用户需选择国家代码，输入手机号码，并使用一次性验证码进行验证。或者，用户只需点击“订阅”，即可仅通过电子邮件订阅，无需短信验证。
Hacker News 讨论围绕 GitHub 一起中断 Webhook、Actions 及相关服务的事件展开。用户对反复出现的中断表示沮丧，并质疑继续依赖 GitHub。许多人表示已转向 Forgejo、Gitea 或 GitLab 等自托管替代方案，或第三方 CI 服务，并称其稳定性更好。一些人认为 GitHub 被代理开发的巨大增长所拖累， reportedly 使用量同比增长六倍，提交/Action 量巨大；另一些人则指责 Azure 迁移或扩展能力不足。关于“vibe coding”或快速架构变更是否导致问题，存在争议。多名评论者指出，问题解决后排队的构建仍卡住，并强调需要生产环境的备份路径。总体而言，该讨论凸显了可靠性担忧以及对替代方案兴趣的加速。
在海拔3000英尺以上烹饪干豆更难，因为更低的沸点会减缓淀粉糊化和果胶软化，同时增加水分蒸发。炉灶慢炖能更好地控制高汤和沙拉中的豆子，但需要90–180分钟以上，并需频繁检查水量。高压锅可将温度升至240–250°F，把烹饪时间缩短至20–50分钟，并使软硬度更一致，尤其是鹰嘴豆和较老的豆子。在高海拔获得最佳效果：将豆子在盐水中浸泡8–12小时，尽早给烹饪液加盐，酸性食材待豆子接近软烂时再加入，水质硬则使用过滤水，煮好的豆子在其汤汁中静置。豆子的新鲜度是最大变量——老豆子无论用哪种方法都更难软化。总体而言，高压烹饪在效率和一致性上最可靠，而炉灶慢炖适合重视控制和高汤风味的厨师。许多高海拔厨师两种方法都会用。
Hacker News
新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
高海拔豆类：炉灶 vs. 压力锅
(highaltitudelife.com)
10 点，由 mooreds，1 天前 | 隐藏 | 往期 | 收藏 | 讨论
帮助 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
这篇文章认为，像 Claude Code 这样的 AI 编程助手已经消除了 Emacs 在编辑速度和定制性方面的传统优势，因为用户现在可以描述想要的软件，而不是亲自输入代码。它追溯了从确定性计算和失败的基于规则的 AI 到现代随机模型的转变，然后考察了廉价的 AI 生成代码如何催生出荒谬雄心勃勃的 Emacs 项目，例如 excali-mode（一个用 Emacs/C 实现的完整 Excalidraw 风格技术栈）和 cooked.el（一个 Rust 终端模拟器）。这些项目表明，实现成本不再阻止异想天开的重写，而长期讨论的 Emacs 改进却仍未完成，因为其实没有人真正足够想要它们。作者预测软件将变得高度个性化且一次性，AI 会生成定制应用甚至底层代码。最后的讽刺是：Stallman 的用户控制软件理想可能实现，但没有人会理解最终系统如何工作。
Hacker News 的帖子讨论了“Emacs in the Age of Magic”以及 LLM 对编程的影响。原帖作者认为 AI 编程工具强大但有缺陷——速度快但冗长、不安全、上下文能力差——认为程序员不会消失，并警告不要把人类思考交给机器。评论者争论 AI 是会取代工程师，还是只会产出低质量软件。有人把 AI 生成的代码比作外包复制粘贴代码；也有人称赞 AI 提高生产力并能集成到 Emacs。一个明显分歧是 human-emacs.org 承诺拒绝 LLM 生成的 Emacs 贡献，而批评者称其倒退，并预测支持 AI 的分支会超越它。其他主题包括软件自由、专有模型、幻觉、信任、验证、模块化、确定性工具，以及 AI 是减少学习还是扩大访问。总体而言，该帖反映了对 AI 影响编程技艺与开源社区的兴奋、怀疑与不确定。
MACaQ 是一个快速、与模型无关的量化工具，用于对文本、图像、视频和音频模型中的权重与激活值进行低精度量化。它支持 llama.cpp、vLLM、Diffusers 和 PyTorch，包括 2/3/4-bit GGUF、W4A4 和仅权重模式，能够在 64 分钟内使用 32.5 GB 内存完成 122B 参数模型的量化。据报道，它实现了比 MR-GPTQ 和 DuQuant++ 更低的困惑度，或以 11 倍更少的量化时间匹配 Llama-3-8B 的困惑度。功能包括扩散 Transformer 量化、图像到视频校准、语音生成检查点、通过 llama.cpp 的 CPU 执行，以及默认使用 W4A4 的 vLLM 服务。对于 Qwen3.8-27B，W4A4 的困惑度达到 2.8994，而 BF16 为 2.8463，预填充加速 2.33 倍，解码加速 2.58 倍。内核可通过 CANN 拉取请求获取，需要完整的昇腾运行时集成。采用 Apache 2.0 许可。
华为 CSL 团队在 GitHub 上发布了 MACaQ，一个用于本地推理的内部量化器。该 HN 帖子获得 134 点和 32 条评论。评论者指出结果很强，并分享了 Hugging Face 上复现的 GGUF 模型链接，包括 Qwen3.6 的量化版本。其他人讨论了华为相关的量化项目——SINQ 用于权重、KVarN 用于 KV 缓存、MACaQ 用于多模态校准的权重/激活——以及华为的顶级 GitHub 仓库专注于量化。一些用户更喜欢 GitHub，因为它直接显示代码，而另一些用户指出制裁可能使第三方托管有风险。还有关于项目名称发音和可能玩笑的旁支讨论。总体而言，该帖子突出了一款有用的开放量化工具和社区对其模型的兴趣。
IBM 宣布了 Quantum Nighthawk r3，设计用于在 520 个量子比特上执行 10,000 次量子操作，并计划在 2027 年将两个处理器连接成 1,040 量子比特系统。当前的 Nighthawk r2 每秒可提供最多 100,000 个样本，并支持在 120 个量子比特上执行超过 7,500 次操作；客户和合作伙伴已运行 340 亿个电路，报告最高 19 倍加速。示例包括 E.ON 的 15 倍加速、IBM/ORNL 的 12 倍加速以及 Algorithmiq 的 8 倍更快电路。IBM 还强调了模块化进展，包括 l-couplers 和低温集成。此外，增强版 IBM Quantum Platform 结合量子与经典 HPC，支持更快的工作流和更大规模计算，例如基于样本的量子对角化速度提升 5 倍，以及对 6.08 亿个样本的处理速度提升 33 倍。脉冲级控制和与 ORNL、AMD 的新协同设计平台旨在推进量子纠错。
Hacker News 上的一篇帖子讨论了 IBM 的 Quantum Nighthawk 公告。评论者澄清，"可编程量子比特"可能指的是物理的、未经纠错的量子比特，而不可编程的量子比特用于泄漏移除，而非完整纠错。一些人指出，量子计算机应被视为针对特定问题（如 Shor 算法和图算法）的专用协处理器，而非对经典机器的通用加速。
怀疑者认为 IBM 的说法是营销，机器仍无法做任何有用的事，而逻辑（纠错）量子比特——破解 RSA 等任务需要数百万物理量子比特——仍然遥不可及。其他人则反驳说 IBM 运营着世界上最大的工业研究机构，且自 2024 年底以来进展加速，使"量子寒冬"可能性降低。
其他要点包括对稀释制冷机成本、氦气供应和规模化功耗的担忧。一位评论者列举了 Hacker News 上反复出现的量子话题（炒作、"永远还有 10 年"、密码学恐惧），而其他人警告，若承诺未兑现，资金可能枯竭。总体而言，该帖反映了一种谨慎的兴趣与对近期实用性怀疑的交织。
Gemini Decision 1 是一款低延迟、高成本效益的多模态决策 API，可在单次前向传播中为选项评分，无需逐 token 解码。它支持文本、图像、音频、视频和 PDF，最多 16K token，1–100 个问题的延迟几乎保持不变，且不计输出 token，因此比同类 API 便宜很多。它支持是/否、多选题和量规评分，并提供置信度分数用于路由。
Google 推出了 Gemini Decisions API，与 Jev 和 OpenAI 一同提供专用的决策/分类模型。HN 用户争论这是否来得过晚，指出此类模型在 yes/no 选择、路由、过滤和评判方面可能比 LLM 更便宜、更快，同时提供校准后的概率。评论者强调 Gemini 的多模态支持（音频、视频、PDF），但质疑其在新任务上的校准、基准测试声明、成本、延迟以及 Google 的长期支持。一些人将其与旧分类器/NLI 比较，并讨论将决策模型用作门控或评分标准。总体而言，该讨论反映人们对更便宜、结构化 AI 决策的热情，以及对准确性、校准和供应商可靠性持怀疑态度。