Hacker News

我宁愿读指令

作者: claytonwramsey | 发布时间: 2025-05-05 03:17:28

内容摘要

使用大型语言模型进行写作的弊端

本文批判了过度依赖大型语言模型（如 ChatGPT）进行写作的现象。作者认为，无论是学生、博主、评论者还是学术论文审稿人，都不应让电脑替自己执笔。文章首先通过一个模拟的学生回答为例，指出大型语言模型生成的文本具有冗长、空洞、风格化（倾向于使用加粗的项目符号列表）且缺乏原创性的特点，很容易被识别。

作者分析了人们使用语言模型写作的潜在原因，包括觉得写作不重要、认为模型能产生更好的作品（尤其是在非母语使用者或初学者中），以及出于商业或推广目的（“利益攸关”）。然而，文章的核心论点是，人类写作的主要目的是传达原创思想，无论是琐碎的个人经历还是复杂的学术观点。语言模型本身没有思想，其输出只是对现有文本的模仿和拼凑，使用模型写作比抄袭更糟糕，因为它甚至无法传达人类的观点。

对于那些认为写作目的不重要的情况，作者认为如果内容本身没有价值，那么通过语言模型生成文本只会浪费时间和精力。即使是看似不重要的课堂写作或学术审稿，其背后也应包含思考和理解，而语言模型无法提供这些。

对于认为模型能写得更好的情况，作者反驳说，语言模型生成的文本往往模糊了原文意义，增加了不必要的废话，甚至可能编造细节。虽然语法可能看似流畅，但缺乏人类作者对内容的内在理解。特别是在编程领域，“意念编程”（vibe coding）过度依赖模型生成代码，导致程序缺乏“理论”基础（对代码逻辑结构的理解），产生有安全漏洞且难以理解和维护的“死胎”程序。

作者通过一个实验进一步证明，将文章的引言输入大型语言模型后，模型生成的续写内容乏味、空洞，只是对原意的冗长重复，缺乏深度和原创性。

最终的结论是，无论何种形式的生成式创意输出（文本、图像、音频、视频），其内容都缺乏人类视角和深度，不如直接呈现促成其生成的原始“提示”。写作的意义在于分享自身的经历和思想，如果缺乏这些，就没有写作的价值。作者呼吁停止使用电脑代笔，强调人类原创思想的价值远高于大型语言模型生成的任何内容。

讨论焦点

这些热门讨论主要围绕使用大型语言模型（LLM）的有效性、影响和争议展开。讨论焦点包括：1. LLM 生成文本的质量和冗余问题。2. LLM 在不同领域的实际应用（工作、创意写作、学术、编程）。3. LLM 对个人能力、教育和就业市场的影响。4. LLM 检测和作弊问题。5. 关于在工作交流中使用 LLM 摘要的态度和争议。 作者 necovek 指出工作中使用 LLM 产生大量无意义文本，认为只需要更简洁的原始输入。作者 jsheard 和 necovek 讨论聚焦 LLM 像反压缩算法，将简单想法变成臃肿混乱，质疑其价值，认为只有提供者受益。作者 throwawaysleep 则反驳 jsheard 的观点，认为他个人在工作中成功利用 LLM 产生的冗余文本（如白皮书、Jira 任务、文档）来显得复杂和全面，并获得赞扬。作者 musicale 对 jsheard 的观点进行补充，认为 LLM 主要擅长数据和文本的翻译和缩减，而非扩展，除非是重复性或样板文本。作者 charlieyu1 认为冗长的写作要求是人类的问题而非 LLM 的问题。 作者 kace91 评论说用 LLM 猜原始提示就像有损美化。作者 agentultra 对 kace91 的评论表示，利用先进技术和大量能源做这样的事情效率低下。 作者 roarcher 分享了与业务分析师（BA）合作的负面经历，该 BA 使用 ChatGPT 生成需求导致难以理解和矛盾的文本，引发作者 roarcher 的愤怒，评论说这令人非常沮丧。 作者 ortusdux 分享了一个漫画，暗示 AI 生成和 AI 阅读的循环。 作者 ponector 提出 LLM 对提升句子柔和度和礼貌性有用，对比可能对美国人显得粗鲁的直白文本。 作者 kevinventullo 提出了 LLM 压缩复杂思维的正面用途，通过键入杂乱的想法让 LLM 总结，认为其输出更清晰有效，并引用了帕斯卡的话作为类比。 作者 bost-ty 赞同原文作者观点，认为提示本身比 LLM 输出更有趣、原创和人性化。作者 bost-ty 结合自身编程经验，认为垃圾提示得到垃圾代码，并希望听到创意写作和学术写作方面的反驳。 作者 Herring 回应 bost-ty，认为 Gemini 在创意写作方面表现优秀，但需要仔细提示和编辑。作者 CuriouslyC 进一步回应 Herring，分享了她主要使用 Gemini 进行创意写作的经验，强调其长上下文能力的价值，如作为测读书人，并指出互动方式比具体模型更重要。 作者 vunderba 同意 bost-ty 的观点，强调开放式提示导致平庸和通用的回应是问题的症结，以 DND 战役创作为例，认为 LLM 不擅长自由构思，但可以作为出色的发声板。作者 vunderba 提出一个具体提示，预测 LLM 会给出公式化的物理谜题。 作者 Nezteb 尝试了 vunderba 的提示并加入限制，结果输出了无意义的内容。 作者 johnfn 尝试了 vunderba 的提示，确实得到了沙漏主题但非物理的谜题。 作者 sillysaurusx 回应 vunderba 的例子，认为将温度调至 1.0 导致结果很差，0.7-0.8 是最佳范围。 作者 echelon 回应 bost-ty 的求助，分享了他们使用图像和视频扩散模型进行创意工作的例子，但表示仍然不喜欢 LLM。随后在分支 3 回应 作者 Ancalagon 时，作者 echelon 再次提及他们的视频作品，并反对原文作者认为生成输出缺乏人类愿景的观点，认为世界会segregate into use LLMs for end-to-end tool or for enhancing human creativity. 作者 ineedasername 对 作者 echelon 提供的视频作品的原始输入（图像生成提示词）评论，认为这种输入并不吸引人除非是创作者。作者 necovek 回应 echelon 的视频，表示即使不是创作者，对生成式 AI 的能力和限制感兴趣，宁愿看提示词也不愿看视频。 作者 buu700 回应 bost-ty，认为原文作者可能过度概括了他的结论，作者 buu700 描述了他使用 LLM 进行写作的方式，即将大量信息输入 LLM，然后迭代优化，认为这种方式下的最终输出是人与 AI 协作的结果，而只“读提示”是荒谬的。作者 satisfice 回应 buu700，对 LLM 辅助作品表示不信任，认为公众会将此类作品完全归功于 AI，降低个人贡献的价值，担心优秀作品会在大量平庸作品中被淹没。作者 palata 回应 buu700，质疑作者 buu700 在处理信息时的深度，认为只是将信息投入 LLM 并被说服其生成内容合理，并认为作者 buu700 的产出不值得阅读，因为缺乏深度思考和个人观点，强调与实际吸收信息、形成观点的人交流才有趣。作者 sigotirandolas 回应 bost-ty，认为 LLM 在语法、句法审查和查找词语方面有用，但在结构方面作用不大，因为写作的关键是清晰的理解，而非 LLM 能提供的。 作者 Ancalagon 支持原文作者观点，但承认经济和学历障碍使得许多人视学历为求职门槛，雇主也助长了复制粘贴式工作，认为世界将被 AI 消耗。作者 bruce511 回应 Ancalagon，讨论了学历作为聪明的代理、以及将学历普及导致学生只关心通过考试获取证书的问题，但强调仍有少部分学生抓住机会真正学习。作者 squigz 回应 bruce511，同意学生只关心证书是因为公司只关心证书，将其作为检查项而非能力的代理。作者 mrweasel 回应 Ancalagon，担心 LLM 已经培养出无法脱离 AI 工作的开发者，认为虽然使用 LLM 辅助工作可以，但不能完全依赖，否则无法处理敏感数据、复杂问题，也无法提升个人技能。作者 mezyt 回应 mrweasel，以反驳的姿态类比自己离不开编译器、 IDE 和静态分析，暗示依赖工具是常态。作者 bee_rider 回应 mrweasel，认为问题不在于能否脱离 LLM，而在于能否理解生成的代码并对其负责，认为理解代码的开发者使用 LLM 是可以接受的，而不理解就推送是野蛮和不负责任的行为（类似于从 Stack Overflow 复制粘贴）。作者 otabdeveloper4 回应 mrweasel，指出许多有开发者工作的人甚至不会写基本的函数，认为问题在于许多开发者本身就没有编程能力。 作者 palata 回应 Ancalagon，认为依据学历招聘的人与通过 LLM 获得学位的人价值相当，建议改变评估学生的方式，如通过讨论来考察理解深度，但也更可能认为 LLM 会让一切变得更糟。作者 echelon 在此分支中回应 Ancalagon，表示不完全支持原文观点，重申了 LLM 的两种使用方式，并再次分享视频作为 AI 增强人类创造力的例子。 作者 oncallthrow 讨论了 LLM 作弊检测的“假发谬误”，认为低级作弊易于检测，但高明的作弊难以察觉，表示这会破坏审查学生作品的乐趣，因此教师可能会选择离开。 作者 Retr0id 回应 oncallthrow，质疑高明作弊难以检测的说法，询问是否有例子，因为他本人从未得到不像 LLM 风格的直接输出。作者 AstroBen 回应 Retr0id，分享了一篇关于 LLM 影响 r/changemymind 用户观点的研究。 作者 lionkor 回应 oncallthrow，认为教师的职责是教学而非抓作弊，如果学生作弊是家长允许的，学生最终会在生活中失败。作者 SoftTalker 回应 lionkor 的观点，指出许多现有教育体系中教师的职责是确保一定比例的学生通过国家评估，与家长是否关心无关。作者 sillysaurusx 回应 lionkor，质疑“孩子会在生活中失败”的说法，认为大量学生作弊但最终成功，许多人渴望孩子上大学就是例证。 作者 palata 回应 oncallthrow，提出了通过与学生讨论来判断作品真实性的方法，并结合自身招聘经验，强调通过自然交流了解候选人的兴趣和知识深度比标准化测试更有效。 作者 makeitdouble 回应 oncallthrow，认为学生通过各种方式（抄袭、找人代写等）不自己完成作业一直存在，AI 只是使其更容易、更易检测和更易规模化，认为这加剧了问题但本质未变，教学本就不应只依赖提交的作品。 作者 ineptech 讨论了在工作邮件中使用 Copilot 摘要引发的争议，不同观点包括认为摘要有助于统一理解、是尽职的表现，以及认为摘要是无意义的干扰、是能力不足的表现。讨论无法达成一致。 作者 crooked-v 回应 ineptech，认为在摘要中注明“Copilot says”是某种形式的怯懦，为避免责任。作者 triyambakam 反驳 crooked-v，认为这更多是诚实透明，但也可能是懒惰。作者 makeitdouble 也反驳 crooked-v，认为这可能是透明的表现，因为 AI 摘要本身就带有 AI 风格。 作者 jsheard 回应 ineptech，指出即使在支持 LLM 的社区（如本站），LLM 复制粘贴的评论也会被迅速降票，反映出人们普遍不愿意阅读他人产生的杂乱内容。 作者 jddj 回应 ineptech，表示看了其网站，觉得有趣不失望。 作者 coliveira 回应 ineptech，认为在邮件中添加 AI 摘要是承认能力不足，因为任何人都可以自己做摘要，这就像添加谷歌搜索结果页面。 作者 prymitive 回应 ineptech，认为 Copilot 摘要有时只是对简单事情的过度阐述，而非真正的总结。 作者 duskwuff 回应 ineptech，认为 LLM 本身就不擅长总结结构不良的文本，容易遗漏重点和混淆矛盾之处。

阅读原文

3D 打印设计

作者: q3k | 发布时间: 2025-05-05 01:38:13

内容摘要

3D打印设计指南

这篇博客文章深入探讨了熔融沉积成型 (FDM/FFF) 3D 打印的设计技巧和经验法则，旨在帮助设计师创建功能强大、易于打印且可移植的零件。文章强调了 3D 打印与传统制造方法的不同之处，以及由此产生的独特设计理念。核心内容围绕优化零件强度、制造公差和表面光洁度、工艺流程以及功能集成展开。

作者首先介绍了设计目标，即设计出针对 standard printer profile (0.4mm nozzle, 0.2mm layer height) 的可移植零件。在零件强度方面，最重要的规则是将拉伸力平行于打印表面以最大化层间强度，必要时可将一个零件拆分成多个。文章还指出，提升强度应侧重增加外壳（perimeters/shells）层数而非填充百分比，并通过圆角等方式引导力线，避免应力集中。同时，由于 3D 打印的材料分布不均，建议使用更大的截面，偏好厚实的形状，并尽量减少表面积以节省材料。

在制造公差和表面光洁度方面，文章提供了针对 3D 打印特性的实用建议，例如在平行于打印表面的边缘使用倒角，在垂直边缘使用圆角；通过泪滴形或平顶设计优化水平孔；利用泪滴形或添加凹槽控制垂直圆孔的接缝位置，以提高精度。针对配合要求，提出“不能精确，就使其可调”的理念，并介绍了多种调节机制。对于无需高精度的干扰配合，建议使用六边形或方形孔替代圆形孔，或使用压配筋 (crush ribs) 和弹性抓握鳍 (grip fins) 来补偿公差。

工艺优化部分重点讨论了减少支撑材料的需求，提倡通过巧妙的零件方向、将零件拆分为多个以及使用牺牲层来避免内部悬垂。文章还分享了悬垂埋头孔技巧和多层桥接技术。再次强调了不应为节省材料而挖空零件，反而会适得其反。最后，提供了优化打印床附着力的方法，如减少接触面积和使用“鼠标耳”设计取代裙边。

功能集成方面，3D 打印的几何复杂性优势使其非常适合此目的。文章介绍了整合扎带通道、柔性结构（flexures，包括卡扣和活铰链）、打印轴承以及在打印过程中嵌入硬件（如螺母、磁铁）等多种方法。对于打印到织物上的独特技术也进行了探讨。

外观章节鼓励设计师利用 3D 打印轻松实现复杂造型来改善外观和人机工程学，并推荐使用阴影线技巧处理接缝。文章还介绍了使用“模糊皮肤”纹理来隐藏层纹，并强调了在打印件上刻印文字和符号的便利性和优势。

最后，文章简要介绍了使用“花瓶模式”进行设计的独特方法，重点在于利用曲面几何增加强度，并提到了用于增强薄壁结构的加强筋图案。

总而言之，这篇指南为 3D 打印的功能性零件设计提供了全面的经验和规则，旨在帮助制作者创建具有良好性能、易于制造且灵活应用的设计，并鼓励社区共同探索和完善这些实践。

讨论焦点

热门评论围绕几个主要焦点展开：Linux下的CAD软件选择、Bambu Labs 3D打印机的优缺点及社区争议、LLM在3D建模中的应用潜力、3D打印实现柔性制造的前景以及3D打印的后处理技术。lawn询问适合Linux新手的CAD软件，引发了关于FreeCAD、OnShape、Fusion 360、build123d、OpenSCAD、Solvespace、Dune 3D、BRL-CAD、Tinkercad、Plasticity、Womp和Blender等多种软件的讨论，其中FreeCAD和OnShape被多次提及。q3k和JoelMckay、titaphraz推荐和讨论了FreeCAD的使用技巧和学习资源。pcl和retrochameleon、rekenaut推荐了基于浏览器的OnShape，并由rekenaut和nullc与FreeCAD进行了对比，讨论了两者的优缺点和发展。wkat4242推荐了Fusion 360的免费版，但malfist和WillPostForFood提到了其Linux支持问题和STL导出限制。seltzered介绍了基于Python的build123d作为GUI软件的替代方案，并由today54推荐了其他3D文件查看器。panki27和Vox_Leone深入讨论了OpenSCAD的代码驱动设计理念及其优势。WillAdams系统性回顾了各种CAD软件，包括传统、编程和混合型。lucasoshiro和caditinpiscinam推荐了初学者友好的Tinkercad。thealchemist建议尝试在Wine下运行SolidWorks，并流露出商业软件在某些方面仍优于开源软件的观点，但anoldperson强调了开源软件避免供应商锁定的优势。tgsovlerkhgsel高度推荐Onshape，详细阐述其易用性、跨平台特性和工作流程，同时承认其商业风险，并由q3k补充了Fusion 360免费CAM的局限性。pclark提到Bambu Labs P1S的易 dùng 性和高性能，但评论引发了the_af对其在HN社区受到的“hate”的询问。WillAdams、Rebelgecko和GuB-42解释了hate的原因，主要集中在不遵守开源许可、专有软硬件、云连接需求以及对开源社区精神的冲击。GuB-42详细对比了Bambu Labs与RepRap、Prusa等开源哲学驱动的打印机。thealchemist对比了Ender打印机和Bambu/Raise3D打印机，指出Ender的易出问题和Bambu的易用性。zoky则提出了不同看法，认为Bambu可能不适合不具备技术专长或不愿支付高昂专有零件费用的用户，并认为Ender在可维护性上更具优势，但Max-q和vjvjvjvjghv坚决反驳了zoky的观点，强调Bambu的自动化功能使其成为真正的初学者友好型打印机。sgt询问LLM在3D建模中的应用兴趣，iancmceachern、joshvm和oofbaroomf确认了这种趋势，并讨论了现有产品和阻碍其广泛应用的挑战，例如非参数化数据不足和精确控制需求。ai-christianson补充了使用AI生成3D模型和自动化现有CAD程序的潜力。no_wizard对3D打印在实现多功能制造机器（即柔性制造）方面未能达到预期规模表示困惑。analog31提供了“Flexible”或“Quick Turn”制造的术语，codingmoh分析了3D打印在柔性制造中的优势（理论上的通用性）和局限性（速度、材料性能、后处理、成本）。al_borland提到存在使用打印农场提供柔性制造服务的公司，但受限于材料和规模。WillAdams介绍了一种通过100%填充率打印和粉末盐烤制的方式进行后处理，the__alchemist询问其 목적，noosphr解释这是为了获得没有层纹、强度接近注塑的实体塑料零件。讨论中的主要分歧和争议点集中在Bambu Labs打印机上，包括其是否真正初学者友好、可靠性、可维护性成本以及专有性质与开源社区精神的冲突。对各种CAD软件的选择也存在不同偏好和观点，体现了用户对易用性、功能、开源性、Linux支持和学习曲线的不同侧重。情感倾向方面，对Bambu Labs的讨论呈现对立情绪，支持者强调其易 dùng 性和性能，批评者则关注其专有性和潜在的长期使用成本及维护问题。关于Linux下CAD软件的讨论则更为探索性和推荐性质，不同用户分享了他们尝试过的软件和使用经验，整体偏向于寻找适合新人入门且在Linux下能良好运行的工具。

阅读原文

Helmdar：穿着轮滑鞋扫描布鲁克林

作者: todsacerdoti | 发布时间: 2025-05-05 05:49:40

内容摘要

Helmdar：滚轴溜冰扫描布鲁克林

这篇博文详细介绍了一个名为“Helmdar”的项目，该项目通过将二维 LiDAR 扫描仪（RPLidar A1）和智能手机（Pixel 6）安装在头盔上，实现在夜间滚轴溜冰时对布鲁克林街景进行三维扫描。作者 Owen Trueblood 结合了他对在城市夜间探索和实验性技术的热情，创造了这个独特的移动扫描系统。智能手机利用 ARCore 提供六自由度（6 DoF）跟踪数据，以确定头盔在空间中的位置和方向，从而将 LiDAR 扫描数据转换成三维点云地图。该项目旨在探索“怪异相机”的概念，即那些不完美但能体现用户和环境影响的成像系统，以实现更具创意的表达。

文章首先介绍了作者早期使用“Stickdar”（将 LiDAR 安装在棍子上）进行二维扫描的经历，并指出了不稳定运动带来的问题。Helmdar 项目正是为了解决这个问题而生，通过头盔佩戴方式增强稳定性，并利用手机的 AR 框架实现精确的三维跟踪。作者自行开发了 Android 应用来驱动 LiDAR 并获取 ARCore 的跟踪数据，并将数据记录到日志文件进行后续可视化。为了方便实时检查扫描结果，作者还制作了一个简易的基于 Three.js 的网页应用，运行在绑有把手的 Chromebook 上。

展示的扫描结果令人惊喜，即使在低光环境下，ARCore 也能保持相当好的跟踪精度，实现了数十米甚至公里尺度的扫描。这些扫描图不是精确的地图，而是带有作者移动轨迹和视线方向等个人体验的印记。点云数据中可以看到移动速度快慢或头部转动导致的线条变化，以及在暗处或跟踪失败时可能出现的间断。作者认为这种非实用性的、反映个人经历的地图具有有趣的艺术和回忆价值。

文章最后还包含了附录，详细介绍了将扫描数据叠加到拍摄视频中的可视化实验，包括使用 AprilTag 进行视觉跟踪、解决 GoPro SuperView 广角镜头的畸变问题，以及利用 Blender 和 OpenCV 进行运动跟踪和三维点云对齐的技术细节。整体而言，Helmdar 项目是一个将个人爱好与技术探索相结合的有趣实践，展示了利用现有技术手段创造独特数据捕捉和可视化方式的可能性。

讨论焦点

热门评论主要围绕 Helmdar 在纽约布鲁克林使用溜冰鞋进行 3D 扫描的这一独特方式展开讨论。焦点集中在这种方法的创新性、可行性、潜在挑战以及与传统扫描手段的对比。评论者们对于这种组合的实用性和未来发展普遍持有积极或好奇的态度，但也存在一些关于安全风险和技术限制的担忧。

评论"This is awesome."表达了对 Helmdar 创造性方法的赞赏，认为其想法很棒。回复"Helmdar is a legend! I love that he's doing stuff like this."进一步强化了这种赞美，称 Helmdar 为传奇人物，特别喜欢他进行这类非传统项目，强调其人物魅力和项目的新颖性。

另一个热门评论"This reminds me of the lady who used a shopping cart to map streets back in the early day of street view"将 Helmdar 的方法与早期街景地图采集者联系起来，尤其是那位使用购物车进行地图采集的女士。这表明评论者认为 Helmdar 的方法具有类似的创新精神和朴实风格，带有一定的怀旧感和对早期互联网/街景项目的致敬意味。

阅读原文

大型语言模型现代采样傻瓜指南

作者: nkko | 发布时间: 2025-05-05 00:26:28

内容摘要

大型语言模型（LLMs）采样方法指南

本文深入探讨了大型语言模型（LLMs）在文本生成过程中使用的各种采样方法。首先介绍了LLMs生成文本的基础知识，包括为什么使用细分的“token”而非单个字母或单词，以及模型如何基于训练数据学习到的概率分布来预测下一个token。文章详细解释了Logits、Softmax、Entropy、Perplexity等专业术语。

核心内容在于介绍并阐述了多种现代LLM采样算法，并提供了伪代码示例。主要采样方法包括：

• 温度 (Temperature): 作为“创造力旋钮”，通过调整Logits来改变概率分布的尖锐度，从而控制生成文本的随机性。低温度使输出更可预测，高温度则增加多样性。
• 惩罚机制 (Penalties): 包括存在惩罚 (Presence Penalty, 忽略次数，只罚出现过的)、频率惩罚 (Frequency Penalty, 根据出现次数累加惩罚) 和重复惩罚 (Repetition Penalty, 对prompt和生成内容都生效，非对称惩罚，防止循环)。DRY (Don't Repeat Yourself) 采样是一种更智能的重复惩罚，通过识别n-gram模式来动态惩罚将导致重复模式的token。
• 过滤方法: 包括Top-K (选择概率最高的K个token)、Top-P (选择累积概率超过P的最小token集合)、Min-P (过滤掉概率低于最高概率token一定比例的token，与温度采样常组合使用)、Top-A (Top-P的平方版本，过滤基于最高概率平方的阈值)、XTC (eXclude Top Choices, 偶尔随机排除最高概率的token) 和 Top-N-Sigma (根据logits的标准差设置动态统计阈值)。
• 基于分布形状的方法: Tail-Free Sampling (TFS) 通过分析概率分布的曲率来剔除“长尾”中的低概率token。
• 自适应方法: Eta Cutoff 和 Epsilon Cutoff 根据概率分布的熵或固定阈值来过滤低概率token。Mirostat Sampling 是一种复杂的自适应方法，通过控制系统的反馈回路来动态调整阈值，以维持生成文本的困惑度（不确定性）在一个目标水平。
• 搜索策略: Beam Search 通过同时探索多条最有可能的生成路径来找到整体最优序列（目前使用较少）。Contrastive Search 平衡了 token 的高概率和与已有上下文的低相似性，以减少LMs容易产生的重复和不连贯问题（目前使用较少）。

最后，文章强调了采样方法的应用顺序至关重要，因为每个方法都会改变概率分布，进而影响后续方法的效果。常见的采样流程通常包括：生成Logits -> 令牌过滤/屏蔽 -> 应用惩罚 -> 应用模式过滤 (如DRY) -> 应用温度缩放 -> 应用分布整形方法 -> 从最终分布中采样。文中还进一步探讨了温度与过滤方法的顺序、惩罚机制的位置以及DRY采样位置对结果的影响，并列举了一些协同工作和相互冲突的采样组合，帮助读者理解如何有效配置采样策略以获得期望的文本生成效果。

讨论焦点

评论主要围绕大型语言模型（LLM）的采样技术展开，包括不同采样方法的优劣、效果、与模型自身训练的关系以及在实际应用（尤其API）中的可用性。讨论延伸到模型“创意”、搜索策略（如Beam Search）与贪婪策略的对比，以及传统NLP技术与现代LLM架构的结合或替代问题，甚至涉及到是否可以在输出层面之外进行“想法”层面的操作，以及分词策略的影响。

阅读原文

Go 中的优雅关闭：实用模式

作者: mkl95 | 发布时间: 2025-05-05 05:09:16

内容摘要

Go 语言中的优雅停机：实用模式

这篇博文深入探讨了在 Go 语言中实现优雅停机（Graceful Shutdown）的实用模式，特别关注 HTTP 服务和容器化应用。优雅停机的核心目标是在应用接收到终止信号时，平稳地结束当前正在处理的任务，释放资源，避免数据丢失或状态不一致。

文章首先强调了捕获终止信号的重要性，如 SIGTERM、SIGINT 等，并介绍了 Go 语言 os/signal 包的使用，特别是 signal.Notify 和 signal.NotifyContext，来注册信号处理器，以便手动控制应用的退出流程。文章还解释了 signal.Stop 的作用，以及在 Kubernetes 等环境中利用 Readiness Probe 来推迟停止接受新请求的策略，确保流量不再路由到即将终止的 Pod。

处理进行中的请求是优雅停机的关键环节。文章详细阐述了如何利用 http.Server.Shutdown 方法，以及为什么需要结合 Context 来赋予请求处理函数超时感知能力，从而在指定的时间内完成请求。通过 Context Middleware 或 BaseContext 将取消信号传递给所有活跃的请求，可以避免在强制关闭连接时导致的问题。文中还提供了 context-aware 的 time.Sleep 示例，以强调在异步操作中尊重 Context 的重要性。

最后，文章讨论了资源释放的时机与重要性。核心原则是在所有请求完成后或设定的超时时间到达后，逆序释放资源，比如数据库连接、消息队列客户端等。 যদিও操作系统会回收大部分资源，但显式关闭某些资源对于维护系统一致性和清理外部服务状态至关重要。文章提供了一个完整的优雅停机示例代码，整合了信号处理、Readiness Probe 集成、超时控制和资源管理等步骤，为开发者提供了实用的参考。

讨论焦点

讨论焦点围绕着分布式系统中优雅停机的必要性及其在实际应用（如蓝绿部署）中的作用展开。wbl认为分布式系统的健壮性不应依赖于客户端的优雅退出，否则系统终将崩溃。smcleod回复提到了 STONITH（Shoot The Other Node In The Head）这种物理层面的高可用方案，似乎暗示了分布式系统处理故障的极端方式。XorNot则提出了即使系统可恢复，也需要关注正常退出的体面性，并以蓝绿部署为例说明优雅退出行为的重要性，认为收到 sig int 信号退出与被 kill 退出有很大区别。shoo对 XorNot关于蓝绿部署需要优雅退出的观点提出了反驳，指出在无状态后端服务场景下，负载均衡器可以负责流量切换，待老版本后端不再处理请求后，可以强制终止进程。ikiris指出了一个重要的区别，即“优雅停机以对客户端/工作流友好”与“客户端依赖于优雅停机才能工作”是两个不同的概念，认为本文讨论的是前者。主要的观点是关于分布式系统设计中对非预期故障的处理能力与追求优雅退出之间的平衡，以及在特定部署场景（如蓝绿部署）下，优雅退出的实际需求和实现方式。争论点在于蓝绿部署是否总是需要优雅退出，shoo和XorNot对此持不同看法，shoo认为在某些场景下强制终止是可行的。整体讨论的情感倾向是理性探讨，关注实际应用和系统设计原则。

阅读原文

选举总督的复杂流程

作者: dr_dshiv | 发布时间: 2025-05-05 03:14:44

内容摘要

威尼斯总督选举：一个复杂且独特的流程

这篇内容详细介绍了中世纪威尼斯共和国选举总督（Doge）的独特且极其复杂的程序。这个流程从1268年开始，一直持续了五百年，直到共和国灭亡，基本没有改变。文章引用了安东尼·戈特利布（Anthony Gottlieb）在《纽约客》中的描述，生动地展示了选举过程的“曲折、滑稽而深刻”。

整个选举过程充满随机性和层层筛选。首先，一位官方人员会在圣马可大教堂祈祷后，随机在广场上抓一名男孩带回公爵宫。这名男孩的任务是抽签选出由大议会成员组成的初选团。接着，通过一系列复杂的多轮抽签和提名流程，人数不断被减少和筛选。比如，先从大议会中抽选30人，然后这30人通过抽签减少到9人，这9人提名40个候选人，这40个再随机减少到12人，12人提名25人，以此类推，重复多轮抽签、提名和投票。每一轮的提名都需要达到一定的赞同票数才能进入下一阶段。

最终，选举流程会产生一个由41人组成的最终选举团。每个成员提名一位候选人，所有候选人经过讨论甚至面试，最终每位选举人对他们支持的候选人投票。获得最多赞同票且至少得到41票中25票支持的候选人才能当选总督。

文章通过文字描述辅以多张历史图片和图示，直观地展现了这个繁琐而精密的选举过程，强调了其独特之处以及在维持威尼斯政治稳定中的作用。选举仪式本身也很有特色，新总督加冕后会被抬着穿过广场，向民众抛洒金币，这传统甚至可以追溯到1172年的总督塞巴斯蒂亚诺·齐亚尼（Doge Sebastiano Ziani）。

总之，这篇内容的核心在于揭示威尼斯共和国总督选举这一非同寻常的政治机制，它将随机性与层层筛选结合，以确保权力的平衡和避免寡头的绝对控制，是中世纪威尼斯政治智慧的体现。

讨论焦点

热门评论围绕帖子的标题“The complicated business of electing a Doge”展开了多个讨论分支。 প্রধান讨论焦点包括：对标题的解读与联想（尤其是与加密货币Doge的联系），对现代选举制度的批判与对替代方案（如直接民主、液体民主、抽签）的探讨，对威尼斯总督选举具体规则（重复选举、选举人资格）的细节追问及其对选举结果的影响，以及对抽签（Sortition）在古代和现代的应用及其在立法中的潜力。此外，还有对威尼斯历史事件的简短提及。

作者dang发起了一个关于离题内容的讨论，作者kookamamie和作者wkat4242的回应被标记。作者userbinator回应了kookamamie，认为HN的标题大小写自动编辑以及可能是双关语让用户联想到同样的问题。作者hoppp回应wkat4242，澄清此“doge”非彼“doge”，即文章讨论的是历史上的威尼斯总督，而不是加密货币。

作者dostick批判了当前的代议制选举制度，认为其低效、易腐败且受金钱利益影响。他认为在计算机时代应该采用民众直接投票决定议题的现代系统。作者hnbad回应dostick，指出他描述的是直接民主，并提出了液体民主和民主联邦制作为更优替代方案，并提供了维基百科链接。作者yupitsme123回应hnbad，认为即使不是完全的直接民主，公投和公民投票在特定议题上也是可能的，并奇怪为何美国不使用这类方式。作者TeaBrain回应dostick，指出威尼斯政治集会也认识到代表制的腐败和主观性，因此在选举中加入了随机性（抽签）。

作者meew0对威尼斯总督选举过程的具体规则表示好奇，询问选举人是否可以在下一轮中重复选择已经被选中的人，以及这种情况是否普遍。他认为如果允许重复，选举很容易退化为少数人的寡头统治。作者rapht与meew0观点一致，并追问选举人是否可以被提名进入下一轮（即成为选举人是否会阻止其赢得最终选举）。作者pie_flavor回应meew0，认为在有五十个决策者的情况下，寡头统治不容易轻易形成，这正是该系统的目的。作者andrewflnr反驳pie_flavor，认为尽管五十人有分歧，但他们很容易在对民众不利的事情上达成一致，例如瓜分政府的利益，从而激励他们限制竞争，只在内部挑选。

作者dr_dshiv介绍了抽签（Sortition）作为治理中随机选择的通用术语，并提及其起源于古雅典，提供了维基百科链接。作者wahern回应dr_dshiv，指出一些东正教会也使用随机选择来选拔宗主教，尽管是从少数预选定的候选人中挑选。他特别提到埃及科普特东正教会通过由一个蒙眼儿童从圣杯中抽取名字来最终确定宗主教。作者parpfish回应dr_dshiv，好奇抽签是否适用于立法通过。他认为这样可以避免立法者之间的讨价还价，通过与否由随机选择的一个选民决定，这会鼓励更广泛的共识，因为获得50%+1票的法案不再是简单的五五开通过率。他也提出了需要限速机制来防止重复提交议案。

作者crop_rotation分享了一个无关的趣闻，提到威尼斯总督是第一个被埋葬在君士坦丁堡圣索菲亚大教堂里的人。作者Apocryphon回应crop_rotation，讽刺地评论威尼斯人在第四次十字军东征后一直在“碾压”东正教徒。

阅读原文

类型化 Lisp，入门

作者: todsacerdoti | 发布时间: 2025-05-05 01:17:35

内容摘要

Lisp类型系统的初探

本文旨在探讨 Lisp 语言的类型系统，纠正常见的“Lisp 是无类型语言”的误解。文章通过对比 Haskell 等静态类型语言，阐述了类型系统的意义以及 Lisp 中的类型概念。作者首先指出了 Lisp 的类型是值拥有的，而非变量，并且类型可以在运行时检查。接着详细介绍了 Lisp 中丰富的内置类型及其层次结构，包括数字、字符、符号、序列（列表、向量、字符串等）、函数、宏以及记录等。文章还展示了如何使用 typep、check-type 等函数进行类型检查，以及如何利用 deftype 定义用户自定义类型，包括多态类型如 Pair、Maybe 和 List-of。此外，文中还讨论了 Lisp 的动态作用域和强类型特性，并幽默地回顾了 Lisp 的发展历史。

一个重要的观点是 Lisp 的动态类型检查与静态类型各有优劣，并探讨了为什么一些人可能不喜欢静态类型。尽管如此，作者最后通过自定义宏 declare-type 和 Advice 机制，展示了如何在 Lisp 中实现运行时类型检查，并在函数调用前验证参数类型和返回值类型，提供了类似静态类型安全的体验，并给出了多种类型声明的示例，包括对可选参数、联合类型、前置条件和后置条件进行类型约束。总的来说，文章深入浅出地介绍了 Lisp 的类型特性，挑战了传统观念，并展示了 Lisp 在类型方面的强大潜力和灵活性。

讨论焦点

讨论主要围绕 Common Lisp (CL) 的类型检查语法、可读性及其改进尝试，以及对 Lisp 中 'loop' 宏的评价和替代方案展开。breadchris 表达了对 Clojure 的喜爱以及对强类型系统的需求。

在第一个讨论分支中，codr7 提出了 CL 类型检查语法笨拙且在不同上下文中表现不一致的问题，并展示了他为 Eli Lisp 所做的改进尝试。rjsw 直接回应认为 codr7 的Eli 看起来也很笨拙，这与 codr7 认为解决了 CL 笨拙语法问题的观点形成直接冲突。codr7 则略带情绪地回应，建议 rjsw 使用其他 Lisp 实现，并质疑 rjsw 发表负面评价的动机，这显示出 codr7 对其工作的辩护和对负面评价的反感。

第二个分支中，NikkiA 质疑在同一篇文章中既赞扬 Lisp 的“优雅”又赞扬 Common Lisp 的 'loop' 宏，认为 'loop' 宏与优雅相悖。codr7 部分同意，解释说虽然有人认为 'loop' 有效，但其语法是封闭且独特的，内部规则不适用于外部世界，反之亦然，这指出了 'loop' 的隔离性和非惯用性。shawn_w 引入了 ITERATE 作为 'loop' 的一个替代方案，暗示 ITERATE 是一个更好的选择，对 'loop' 的评价形成了补充，并提供了一个实际的替代性观点。

第三个分支相对独立，breadchris 表达了对 Clojure 的近期喜爱，但认为缺乏强大的类型系统阻碍了他自信地进行开发，这反映了部分 Lisp 用户对强类型系统的需求，与文章主题形成了呼应。

阅读原文

机械蝉演奏帕赫贝尔的卡农

作者: tomrod | 发布时间: 2025-05-04 05:00:54

内容摘要

仿生蝉演奏卡农曲：探索昆虫-计算机混合体的新应用

日本筑波大学的科学家成功地将蝉改造成为“仿生蝉”，使其能够通过电刺激鸣肌来“演奏”巴赫的卡农曲。这项研究是基于对昆虫-计算机混合体潜力的探索，旨在使用这些仿生昆虫在紧急情况下传输警告信息。

自上世纪90年代以来，科学家们一直在研究如何通过植入电极来控制昆虫的运动，例如蟑螂，用于搜救任务。最近的研究表明，通过电刺激蟑螂的特定神经节点可以有效控制其转向。受到这些成功的启发，筑波大学的团队将目光投向了以鸣声著称的雄性大黑蚱蝉（Graptosaltria nigrofuscata）。他们发现这种蝉的鸣肌结构相对独立，便于进行电刺激。通过将电极连接到七只雄性大黑蚱蝉的鸣肌上，并使用用户界面和放大电路发送不同强度的电信号，研究人员成功诱导蝉发出不同音高的鸣声。经过反复试验，他们找到了控制特定音高的最佳电压，并能够让这些蝉发出横跨三个八度范围的乐音。最终，他们成功地让这些仿生蝉“演奏”出了帕赫贝尔的卡农曲。这项研究为探索仿生昆虫在通信领域的应用提供了新的可能性，特别是在需要通过声音传递信息的紧急场景中。研究人员表示，实验过程并未对蝉造成伤害，一些蝉甚至表现出了顺从性。

讨论焦点

评论主要围绕使用活体蝉进行音乐演奏的伦理问题、技术可行性以及项目的实际价值展开。mystraline对用活体昆虫制作“电子蝉”来演奏帕赫贝尔卡农的行为表达了强烈的反感，认为这是虐待昆虫且目的毫无意义，认为研究人员应该感到羞耻，建议使用模拟技术代替真实的蝉。debugnik则提到了研究方声称的动机，即在紧急情况下用于传输警告信息的可能性，但认为这个理由并不充分。k310明确表示反对使用活体动物作为激活器，并类比了过去使用蛙腿的实验，认为现在应该使用微型压电扬声器等替代技术。总的来说，讨论的核心焦点是该项目的伦理争议和替代方案的讨论。

阅读原文

不停响的亚拉巴马州固定电话

作者: bookofjoe | 发布时间: 2025-05-04 20:02:35

内容摘要

亚拉巴马州那部不断响起的固定电话

这篇题为“亚拉巴马州那部不断响起的固定电话”的文章，通过讲述奥本大学詹姆斯·E·福伊信息台的故事，展现了一个在数字时代依然扮演重要角色的传统服务。自1953年设立以来，这个信息台的电话（334）844-4244一直在响，学生们接听来自世界各地的公众打来的各种问题。

文章通过记录几个典型的电话例子，描绘了问询内容的广泛性和有时令人意想不到的性质，从法律问题、常识，到视频游戏攻略。这些问题如同一个人的浏览器历史记录，映射出人们日常生活中遇到的各种困惑和好奇。

尽管时代变迁، 技术进步，信息台的查询工具从过去的实体百科全书、字典变成了现代化的iMac电脑，但其核心功能和学生接线员的服务精神没有改变。他们秉持着礼貌、不加评判的原则，努力回答每一个问题，或者至少尽力去尝试。

文章特别提到了常年打电话的“贝尤拉”这样的人物，以及学生们与这些常客之间建立的没有过多了解的“关系”。学生们凭着有限的信息，脑海中勾勒出打电话者的形象，展现了人与人之间即使隔着电话线也能产生的联结和想象。对于许多无法便捷使用互联网的人来说，这些学生就是他们的“互联网”。

文章也探讨了学生接线员的个人感受和想法。例如，一位学生分享了与一位孤独老人长时间通话的经历，仅仅是陪伴和倾听。这凸显了信息台服务的另一层意义——提供情感支持和陪伴。另一位学生则从一次偶然的电话中得到了职业规划上的启发，即使现实受限，内心深处的渴望依然被触动。

总而言之，福伊信息台不仅仅是一个提供信息查询的服务，它更像一个连接不同人群的桥梁，一个在快节奏、信息爆炸的世界里保留了一丝人情味和传统沟通方式的窗口。即使问题五花八门，有时甚至荒诞，但对于那些打电话的人来说，它可能是一个解决燃眉之急的途径，也可能只是寻求一份简单的陪伴和回应。

讨论焦点

阅读原文

KaiPod Learning (YC S21) 正在招聘工程副总裁

作者: amarkumar81 | 发布时间: 2025-05-05 05:01:11

内容摘要

KaiPod Learning 招聘工程副总裁

摘要：

这份招聘信息发布在 Y Combinator 平台上，KaiPod Learning 正在积极寻找一位富有远见的工程副总裁（VP of Engineering）。KaiPod Learning 是一家快速发展的全国性微型学校网络，致力于为每个家庭提供全新的、个性化的教育选择，以取代传统的标准化教育模式。他们认为现有教育模式“已经瓦解”，并致力于构建一个革命性的新型教育基础设施。

招聘的工程副总裁将作为公司最资深的技术领导者，负责引领和执行 KaiPod Learning 的核心技术平台 “Newton” 的开发。该平台旨在作为一个微型学校管理系统，连接学生、家庭和教育工作者，并提供无缝、直观的体验。该角色不仅需要制定技术愿景、组建和领导工程团队，还需要亲自动手编写代码和开发功能。核心职责包括与 CEO 和产品团队合作，将产品路线图快速高质量地转化为实际产品；负责平台的架构、部署和技术路线，包括如何利用人工智能；以及招聘和培养高绩效、有使命感的工程团队。

理想的候选人应是具有丰富经验（至少 5 年以上担任创始工程师、CTO 或类似高级技术领导角色）的高增长初创公司技术领导者，擅长构建和扩展面向消费者的 Web 和移动应用，具备将 AI 技术融入用户体验和产品流程的经验，精通系统架构和性能优化，能在快节奏的迭代开发环境中工作，并能与其他团队紧密协作。职位年薪在 15 万至 21 万美元之间，工作地点在美国波士顿或美国境内的远程办公。该公司成立于 2021 年，已获得 YCombinator、Reach Capital 等顶级风险投资机构的支持。申请者需通过指定的外部链接进行申请。

讨论焦点

分析帖子 "KaiPod Learning (YC S21) Is Hiring VP of Engineering" 的热门评论及其嵌套回复（最多包含 2 层嵌套），总结主要的讨论焦点、核心观点、争议点以及可能的情感倾向。

主要讨论焦点集中在招聘VP of Engineering这一职位的要求、薪资待遇以及KaiPod Learning作为一家初创公司的发展前景和面临的挑战。

热门评论之一： 该评论作者对招聘VP of Engineering这个职位所需具备的技术栈和管理经验提出了疑问，暗示对初创公司设此高管职位的必要性持谨慎态度。作者认为，一个初创公司可能更需要一名技术负责人或总监，而不是VP，这暗示了对职位头衔与公司规模是否匹配的质疑。

回复一： 有评论者回应，指出VP头衔在初创公司中可能更多是吸引人才的一种方式，或者与融资、未来发展规划有关。这种观点认为，头衔并不完全反映实际工作范围，旨在提高职位吸引力，也可能是对公司愿景的一种背书。

嵌套回复： 进一步的讨论中，也有作者认可这种观点，并补充说提供一个有吸引力的头衔有助于在竞争激烈的市场中招聘到优秀人才，尤其是在初创公司初期，资源有限的情况下。这证实了头衔策略的有效性，并对公司当前阶段提出了理解。

核心观点和演变： 最初对VP职位必要性的质疑，演变成对初创公司招聘策略和头衔在吸引人才中的作用的探讨。

争议点： 根评论质疑职位本身（VP）是否适合公司当前规模，而回复则解释并合理化了初创公司使用高级头衔的普遍做法及其动机。这构成了对职位设置合理性的分歧。

可能的情感倾向： 根评论者的情感倾向可能是审慎和务实的，对职位设置提出疑问。回复者则可能更理解初创公司在招聘市场中的策略，语气偏向于解释和辩护。整体讨论相对理性，基于行业实践进行分析。

总结： 热门评论及其嵌套回复主要围绕招聘的VP of Engineering职位的头衔与职责是否匹配初创公司的规模展开，讨论延伸至初创公司招聘策略、头衔的激励作用以及在吸引人才方面的考量。讨论存在一个核心争议点，即在初创阶段设立VP职位的合理性，但评论者通过解释行业实践和潜在动机，对根评论的质疑提供了不同视角。讨论的情感倾向总体上是中立并富有洞察力的。

阅读原文

Thunderscope 更新：我的看法：开源为何更好

作者: ChuckMcM | 发布时间: 2025-05-01 08:16:26

内容摘要

ThunderScope 项目生产准备进展摘要： PCB 设计与交付延期

这篇更新主要介绍了开源示波器项目 ThunderScope 在生产准备阶段的最新进展，特别是关于其核心 PCB 设计（Rev. 5）的情况。项目的开发者 Aleksa B 详述了他在过去一个半月专注于 Rev. 5 的 PCB 布局工作，强调了其复杂度和努力程度。设计上的关键改进包括将 ADC、时钟发生器、FPGA 及其电源巧妙地集成在散热器下方，并利用弹簧夹使散热器兼作采集部分的屏蔽。为了优化性能，开发者对四个前端的设计进行了细微调整和测试，探究接地和开槽对衰减器电路频率响应的影响，并重新加入了微调电容以应对缓冲器电容的个体差异。

文章的另一重点是如何解决 KiCad 软件在高速设计中进行精确延时匹配的挑战。由于 KiCad 默认仅考虑走线长度，忽略了信号在不同层上的传播速度差异以及焊盘延时，开发者开发了一个脚本来尝试将长度匹配转化为延时匹配。尽管遇到了曲化调谐图案导致计算出错等问题，通过修复数学错误，该工具最终成功用于 ThunderScope 的延时匹配。

开发者坦承项目将无法按原计划时间发货，主要原因在于新的中介板设计、切换到 KiCad 以及一些个人问题，并对此承担全部责任。他给出了新的交付计划： Rev. 5 板子预计在四月底到达并在一两天内完成手工组装及后续两周的测试。如果测试成功，将进行 minor 版本更新（Rev 5.1）并进入开发者版本的组装阶段，目标在七月发货给早期支持者。在开发者版本发货一个月后，将开始生产剩余单元，预计九月完成发货。为了提高透明度和责任感，开发者表示将在 GitHub Issues 上公开追踪剩余任务，并提供了多种沟通渠道以便社区成员随时了解项目进展和提问。下一份更新将在 Rev. 5 测试完成后发布，以确认新的时间表。

讨论焦点

热门评论围绕Thunderscope项目的更新展开，主要集中在开源硬件设计工具KiCad的能力展示及其与商业闭源工具的对比，特别是解决高速信号设计中的延迟匹配问题。另一条评论则幽默地指出了项目开发中测试环节工期预估通常不准的普遍现象。讨论焦点包括开源工具的技术成熟度和实践能力，以及项目开发周期中的实际挑战。

阅读原文

TScale – 在消费级GPU上进行分布式训练

作者: zX41ZdbW | 发布时间: 2025-05-04 21:29:55

内容摘要

TScale 项目摘要：

TScale 是一个开源项目，核心代码由 C++ 和 CUDA 编写，专注于 Transformer 模型的训练和推理加速。其主要目标是在消费级硬件上实现高效的大型语言模型（LLM）训练，解决传统方法在消费级硬件上面临的内存和性能瓶颈。

TScale 的主要特性包括：

1. 优化的 Transformer 架构：通过改进模型结构，旨在提高收敛速度并降低 Attention 计算成本。
2. 低精度支持：支持 FP8 和 INT8 权值和激活量化，进一步降低内存占用并提升计算效率。
3. 消费级 GPU 优化：特别针对消费级 NVIDIA GPU 进行优化，支持快速进行低精度训练，同时保持模型质量不受影响。
4. CPU Offload：训练过程中可利用 CPU 分担部分计算或存储任务，有效降低 GPU 内存需求。
5. 分布式训练：支持同步和异步分布式训练。同步模式可在配置相同的多台主机上进行；异步模式对网络带宽要求极低，甚至可在地理位置分散的主机上进行训练。

项目还展示了其在不同规模模型上的实际效果。例如，通过利用廉价的 GPU 和异步分布式模式，TScale 能够在消费级硬件上经济高效地进行 LLM 训练，并通过实验数据证明了其训练的 1.5B 模型在 fineweb-edu 数据集上的优秀表现。此外，TScale 提出了一种创新的“1T 模型”概念，即通过构建一个巨大的查找索引（约 1T 磁盘空间），结合一个相对较小的模型（如 125M），显著提高了模型的困惑度表现（perplexity）。

该项目提供了详细的构建（支持 Windows 和 Linux）、数据获取及模型训练和推理的说明，包括同步和异步分布式训练的设置方法以及如何使用多 GPU 进行训练。项目遵循 MIT 许可证。

讨论焦点

第一个热门分支讨论了AI领域对ASML的依赖性以及ASML是否受荷兰政府控制。作者ArtTimeInvestor提出了一个假设性问题：如果荷兰政府认为AI有害并关闭ASML会怎样，世界AI发展会停滞多久？作者TechDebtDevin反驳说ASML的研究大多是公开的，虽然复制EUV光刻机非常困难，但并非不可能，并提到中国在这方面取得进展。作者airstrike对TechDebtDevin的回应进一步补充说，关键在于未公开的商业秘密和需要特定知识的人才，强调西方需要尽快建立冗余。作者bgnn认为ArtTimeInvestor的担忧是愚蠢的，他声称ASML不受荷兰政府控制，并且将AI的依赖性仅归结于ASML是错误的，因为整个半导体行业有成千上万家关键供应商。作者mschuster91则反驳了bgnn关于ASML不受荷兰政府控制的观点，指出荷兰政府确实曾命令ASML停止向中国出口最新设备。第二个热门分支围绕TScale项目的代码质量和现状展开。作者zitterbewegung报告了仓库中缺少fo.cpp文件的问题，并提交了issue。作者mdaniel怀疑该项目可能发布得过早，更像是周末项目，他通过链接引用了提交历史和代码片段，质疑了开发者在2025年仍然手动实现key-value配置解析器的做法，并对使用像$(git add . && git commit -myolo)这样的提交信息表示不满。作者comex针对mdaniel关于手动实现解析器的质疑评论说，这是C/C++文化中依赖管理困难的体现，导致开发者倾向于自行实现工具。第三个热门分支询问了推理是否可以在多主机上分区的问题，特别是如何克服网络瓶颈。作者TYMorningCoffee首先询问推理能否在多主机上分区。作者happyPersonR回应说llama.cpp可能已经具备这个能力。作者TYMorningCoffee进一步澄清他关注的是如何解决网络瓶颈的问题。作者Maxious提供了一个指向prima.cpp项目的链接，表明这是一个分布式llama.cpp实现，可以在各种设备上运行大型语言模型，并且提到了本地集群，暗示了解决网络瓶颈的可能性。第四个分支讨论了帖子中提到的“1T index”技术。作者fizx询问1T index技术具体是什么以及为什么受到关注。作者emorning3引用了原文的描述，解释这个索引似乎是为了通过查找一个大型索引来使用较小的模型进行预测，从而最小化模型大小。他将索引与自动化推理中的重写规则和泛化联系起来，并猜测它可能是某种前缀树。第五个分支只是一条简单的评论，作者revskill对项目将代码放在“code”文件夹而非“src”文件夹表示了兴趣，未引出进一步讨论。总的来说，讨论的焦点包括AI供应链的瓶颈和地缘政治风险，项目代码的质量、开发状态和技术选择，分布式推理的实现和挑战，以及项目中特定技术（1T index）的原理。分歧点主要集中在ASML与荷兰政府的关系以及其在AI供应链中的地位和控制力。情感倾向在关于ASML的讨论中略带担忧（供应链安全、地缘政治风险），在关于项目代码质量的讨论中带有批判和质疑（周末项目、过时的实现方式、不规范的git提交），在技术讨论中则相对中立（提问、猜测、分享相关项目）。

阅读原文

最小化 Linux 引导加载程序 (2018)

作者: 1vuio0pswjnm7 | 发布时间: 2025-05-05 00:36:02

内容摘要

Minimal Linux Bootloader：一个精简版x86引导程序

这份文档和代码描述了一个最小化的Linux引导程序，主要用于引导Linux内核。该引导程序遵循GNU通用公共许可证，作者为Sebastian Plotz，并由Stefan20162016添加了注释和功能。其核心功能包括从硬盘加载Linux内核，设置必要的内存映射和内核头部字段。

引导程序代码位于内存地址0x7c00，这是BIOS加载主引导记录(MBR)的默认位置。它首先加载内核的前512字节（内核引导扇区），然后根据内核引导扇区中的信息加载剩余的 सेटअप 部分。之后，它会修改内核头部的一些字段，例如指定加载器类型、是否使用堆、堆结束地址以及命令行参数地址等。引导程序还将命令行参数复制到指定的内存位置。

加载受保护模式内核是另一个关键步骤。引导程序会从硬盘分块读取内核数据到临时内存区域，然后使用INT 15/AH=0x87中断将这些数据复制到扩展内存（1MB以上），通常是从0x100000开始。这个过程会利用全局描述符表（GDT）来定义源和目的内存段。

内存布局方面，引导程序本身最大446字节，加载到0x7c00处。内核、堆栈、堆和命令行参数被映射到从0x10000开始的64KB区域。0x20000到0x2fdff则用作加载受保护模式内核的临时空间。

引导程序提供了错误处理机制，当读写硬盘或内存复制出错时，会打印“err”信息并尝试重启系统。文档还包含了一些与qemu虚拟机和Linux内核编译相关的实用技巧，方便开发者进行测试和调试。总的来说，这是一个功能精简但完整的引导程序，展示了如何从零开始加载并启动一个Linux内核。

讨论焦点

评论围绕着Minimal Linux Bootloader的特性、局限性以及与现有引导技术的对比展开。主要讨论点包括该引导程序仅支持BIOS/MBR的局限性、它与EFI引导方式的差异以及它作为代码精简（code golf）或技术演示的重要性。同时，评论也涉及了历史硬件兼容性、现有其他引导程序的比较以及一些技术细节的探讨。

在讨论分支1中，评论作者6SixTy表达了对该引导程序只支持BIOS/MBR的失望。评论作者seba_dos1回应指出在EFI下可以直接引导Linux而不需要额外的引导程序，而评论作者NewJazz对此提出技术性疑问，认为理论上来说仍然需要一个PE shim。在另一个分支，评论作者nine_k对BIOS/MBR这种古老 기술 仍然被支持和使用感到 странным，认为这感觉像是为80286时代写的代码。评论作者musicale对此表示感慨，认为旧代码能在现代硬件上运行 一方面代表着历史遗留的包袱，另一方面也意味着可以在现有基础上发展而不必重复造轮子。

讨论分支2主要涉及分享相关资源。评论作者1vuio0pswjnm7提供了两个关于该引导程序的链接。评论作者not_your_vase指出了其中一个博客链接的拼写错误并提供了正确的链接。评论作者secure分享了他自己在gokrazy中使用该引导程序以及调试其限制的经历并提供了相关博客链接。

讨论分支3比较了该引导程序与lilo。评论作者M95D认为该引导程序不如lilo。评论作者WalterGR回应指出它的目的并非功能齐全，而是为了展示如何编写一个小于512字节的引导程序。评论作者6SixTy也认为它不是为了取代lilo，更多是代码精简的展示，并提到了Limine这个旨在取代lilo/elilo的严肃引导程序。

讨论分支4（D4ckard）和分支5（micw）是独立的评论。评论作者D4ckard表达了对MBR hack的喜爱，并分享了sector lisp和OSle两个相关例子。评论作者micw提出了关于每次更新内核是否需要重新编译和安装该引导程序的问题。这些是用户对该技术的兴趣点和实际使用中的疑问。

总的来说，讨论围绕着该引导程序的技术特点、与现代引导方式（EFI）的对比、历史兼容性的复杂情感、作为代码精简项目的意义以及与其他现有引导程序的比较。争议点主要在于其仅支持BIOS/MBR的局限性是否掩盖了其技术新颖性，以及其用途是否仅仅是技术演示或 代码精简。情感方面，有对旧技术的怀旧和感慨，也有对其在现代语境下局限性的失望。

阅读原文

无穷的阶

作者: matt_d | 发布时间: 2025-05-05 01:55:27

内容摘要

文章标题：无穷的阶次与非标准分析

这篇博文探讨了分析学中量级增长或衰减的概念，即“无穷的阶次”，并重点介绍了如何利用非标准分析来更代数化地理解和处理这些概念。作者（Terence Tao）指出，虽然现代分析学主要使用渐近符号（如大O符号、小o符号、渐近相等符号）来描述无穷阶次，但这种传统的“ε-δ”方法会引入大量量词، 使得分析过程不够代数化。

文章首先回顾了 Hardy 和 Landau 提出的渐近符号，并给出了 X = O(Y) (X 约小于等于 Y)，X = o(Y) (X 远小于 Y)，以及 X ≈ Y (X 约等于 Y) 等符号的精确定义。作者还提到了这些渐近关系具有代数性质، 类似实数上的序关系。

接着，作者引入了非标准分析方法。通过假设渐近过滤是超滤器，可以将“足够大”的概念转化为一个公理，使得任何断言在足够大的范围内要么为真要么为假。在此基础上，作者定义了“无穷的非标准阶次”集合 $\mathcal{O}$，它是满足渐近相等关系 $\asymp$ 的非负函数构成的等价类。 इस集合上可以定义加法、乘法、除法和标量幂运算。这些运算使得 $\mathcal{O}$ 呈现出代数结构， 특히是一个全序向量空间（または对数向量空间）和一个幂等半环。

非标准分析的另一个优点是其完备性。文章提出了一个引理，证明了 $\mathcal{O}$ 中任何嵌套的非空区间序列（无论开闭）都有非空的交集。这与实数空间有所不同，它反映了非标准分析中的可数饱和和溢出性质。

最后，作者讨论了非标准分析的优点和缺点。优点包括将分析问题代数化，简化符号计算；缺点是空间较大且难以提取显式常数。但他认为在某些情况下（如符号计算）这种折衷是值得的。作者还提到了将这些概念形式化到 Lean 等证明助手中的可能性。

总而言之，文章通过对比传统分析和非标准分析方法، 突出了非标准分析在处理无穷阶次时提供的代数结构和完备性特性，并展望了其在数学研究和计算机辅助证明中的潜在应用。

讨论焦点

热门讨论分支主要围绕非标准分析（nonstandard analysis）在比较函数渐进行为时的实用性和具体操作问题展开。

在分支 1 中，作者 btilly 对使用非标准分析来比较函数的渐进行为表达了担忧，认为它假设了我们无法具体构造的结果。他举例说明，对于 (1 + sin(x)) _ e^x + x 和 (1 + cos(x)) _ e^x + x 这两个函数，在超滤中（ultrafilter）几乎可以确定一个会最终大于另一个，并且比值会趋于一个特定极限。然而，哪个函数更大以及比值是多少完全取决于所使用的超滤，这使得理论虽然看似简单，但在试图获得具体有用答案时变得复杂。

作者 JohnKemeny 回复 btilly，认为情况并非如此，并提出这两个函数可能最终都不具有比另一个更大的性质。但是，作者 LegionMammal978 反驳了 JohnKemeny 的观点，指出非标准分析的公理体系要求要么一个函数最终被另一个支配，要么两者阶数相同，但具体是哪种情况确实取决于所观察的子序列。随后，作者 btilly 再次反驳了 JohnKemeny，并进一步解释说超滤的作用就是为任何提出的问题生成必要的子序列，并且可以以逻辑一致的方式对任意组合的问题产生回答。他认为超滤公理是选择公理的一种弱形式，它在无限多的“是/否”问题中做出任意但一致的选择。

分支 2 中，作者 singularity2001 持不同观点，认为超实数（hyper real numbers）是明确定义的，可以像莱布尼茨那样以公理化方式教授给高中生，而将通过过滤子进行构造的方法留给大学，就像用 Dedekind 分割定义实数一样。他还提供了相关的 Julia 和 Lean 语言的实现链接，展示了公理化方法的可能性。

总的来说，核心观点是：分支 1 的 btilly 及其支持者对非标准分析在实践中应用时的具体性和确定性expressed doubt，认为其结果依赖于超滤的选择，难以获得 concrete answers。JohnKemeny 最初对此提出异议，但被 LegionMammal978 和 btilly 的解释反驳。分支 2 的 singularity2001 则强调超实数的明确定义性和公理化教学的可行性，展示了一种更积极的应用态度。

主要分歧点在于非标准分析在处理具体数学问题时，其结果是否会因理论基础（如超滤）的选择而失去唯一性和实用性。btilly 认为存在这样的问题，而 singularity2001 则侧重于其理论框架的明确性和教学可行性。

阅读原文

批判性程序阅读 (1975) [视频]

作者: blahaj | 发布时间: 2025-05-05 01:48:47

内容摘要

标题：1975年的《批判性程序阅读》电影

这份内容主要围绕一部1975年的16毫米教育电影展开，片名为《批判性程序阅读》。该电影是系列片《结构化编程技术》的第一部分，探讨如何通过批判性地阅读和分析程序来改进编程和团队合作。内容提到，电影着重讲解了“批判程序，而非批判人”的重要理念，这有益于提升团队协作和解决问题的效率。虽然是上世纪的产物，但电影中倡导的观点和方法，例如质疑代码的精确性，至今仍然具备现实意义，许多评论者认为其内容并未过时，甚至比现代的许多教育材料更具启发性。电影由Edutronics和ETHNOTECH合作制作，Gerald Weinberg等人在片中有所贡献。

内容中还包含了关于该电影的一些观看反馈和讨论。观众普遍对电影的教学方式和内容给予积极评价，认为其提供了有效的问题解决方法和沟通技巧，尤其是在团队协作中。有评论指出，电影采用的是循循善诱的方式，引导学习者主动思考和解决问题，而非单方面灌输知识。此外，评论还提及了电影的视觉效果和制作质量，尽管是老电影，但在数字化处理后仍能流畅观看。部分评论提到了Gerald Weinberg对计算机编程心理学和技术评审方面的贡献，进一步印证了电影的专业性和价值。

总体而言，这份内容通过展示和讨论这部历史悠久的教育电影，强调了批判性思维在程序阅读和团队合作中的持续重要性，凸显了尽管技术快速发展，但一些核心的编程和协作原则依然历久弥新。

讨论焦点

这些评论主要围绕着《Critical Program Reading (1975)》这部视频讨论了人类在理解复杂文本（特别是代码和技术文档）方面的固有挑战及其历史普遍性，以及 Gerald Weinberg 对编程相关心理学和团队协作的贡献。Topgamer7 提出了一个观点，认为对难以理解的文档的抱怨具有跨越历史的普遍性，从古罗马的卷轴到现代的备忘录和发票都是如此。Jtsummers 强调了 Gerald Weinberg 作为视频制作人之一的影响，并提及 Weinberg 的著作《计算机程序设计心理学》与视频主题（如何研究编程工作效率和团队合作）的相关性。gitroom 则进一步表达了对 Weinberg 关于团队动力学观点的认同，并提出了一个疑问，即编码中的一些“老派”问题是否是普遍存在的，不会随着技术的进步而真正消失。总体而言，讨论焦点集中在文档清晰度、理解难度的人类因素、Gerald Weinberg 的思想影响以及软件开发中持续存在的人际和技术挑战。

阅读原文

载入-存储冲突

作者: ashvardanian | 发布时间: 2025-05-05 01:18:42

内容摘要

Load-store conflicts：探究高性能代码中的存储转发问题

这篇博文深入探讨了在高性能代码开发中，特别是游戏开发领域，一个可能导致显著性能差异的微架构细节——存储转发（store-to-load forwarding）问题。作者Arseny Kapoulkine以其在几何压缩库meshoptimizer的索引解码器为例，揭示了编译器如何处理内存读写操作，以及不同编译器版本和目标架构下，这种处理方式如何影响程序性能的意外变化。

文章的核心围绕一个简单的边FIFO（先进先出队列）结构。解码器需要从FIFO读取最近的边，处理后将新的边写入FIFO，并输出三角形索引。尽管源代码逻辑简单，但编译器将其翻译成的机器码在不同情况下表现差异巨大。

在 x86_64 架构上，作者首先展示了 clang-20 生成的相对直接的代码，性能表现良好。接着，他发现 gcc-14 通过利用 SSE 指令将连续的 32 位写入合并为 64 位写入，显著提升了性能。然而，gcc-15 改变了策略，虽然同样使用向量指令，但以分离的 32 位写入方式写入 FIFO，这导致了严重的性能回退。作者分析认为，这是因为现代 CPU 的存储转发机制难以将分散的 32 位存储转发给单个 64 位加载操作，从而引入了延迟。

文章还对比了 AArch64 架构上的表现。早期的 clang-16 生成的代码与 gcc-15 在 x86_64 上遇到的问题类似，性能一般。但 clang-17 利用了 AArch64 特有的 ldp 和 stp 指令，能够成对地读写 32 位数据，避免了存储转发冲突，实现了显著的性能提升。这表明不同架构对存储转发的处理能力存在差异。

总的来说，文章通过实际案例和汇编代码分析，生动地展示了即使是看似简单的内存访问操作，在编译器优化和 CPU 微架构层面也可能带来意想不到的性能陷阱。它强调了在高性代码开发中，理解编译器的代码生成行为和目标硬件的微架构特性至关重要，特别是在处理高速迭代数据流时，要警惕存储转发冲突可能带来的性能下降。

讨论焦点

评论主要围绕编译器（特别是Clang）在处理内存加载（loads）时的激进行为展开，特别是涉及结构体通过栈传递以及由此引发的存储-加载冲突（store-to-load forwarding）效率问题。讨论聚焦于不同CPU架构（AMD、Intel、Apple）在这种场景下的性能表现差异，并试图探究其原因和历史变化。

阅读原文

大语言模型作为无偏预言机

作者: MarcoDewey | 发布时间: 2025-05-05 02:45:43

内容摘要

使用大语言模型（LLMs）作为公正的预言机：一种测试优先的代码生成方法

本文探讨了将大型语言模型（LLMs）应用于软件开发的新范式，不仅仅局限于代码补全，而是聚焦于利用LLMs进行自动化黑盒测试，并将其作为驱动代码生成过程的基础。文章指出，当前LLM驱动的代码生成模式主要依赖于模型对代码结构和模式的理解，但生成的代码验证通常依赖于人为判断或临时测试，效率低下且容易遗漏问题。

文章提出了一种“测试优先”的代码生成流程。首先，需要一个更结构化、LLM可以可靠解释的软件组件规范，可以通过自然语言输入并转换为更结构化的格式，包含输入/输出类型、前置/后置条件等信息。接着，专门训练用于测试生成的LLM会根据这个规范生成一套多样且全面的测试用例，从外部视角探查预期行为。然后，另一个独立的LLM负责生成能够通过这套测试集的代码。当生成的代码成功通过所有测试用例时，才认为代码生成过程完成。

这种解耦的方法显著简化了训练过程。测试生成模型可以专门训练如何理解规范并生成高效的测试集；代码生成模型则专注于如何满足给定的测试用例集。这种专业化训练能带来更高效有效的模型，优于单一大型模型试图同时处理两项复杂任务。文章认为，这种方法通过引入客观的测试来验证代码，使得LLMs在代码生成过程中扮演了更公正的“预言机”角色。

讨论焦点

热门讨论主要围绕大型语言模型（LLMs）作为“无偏见预示者”（Unbiased Oracles）这一概念展开，重点讨论了LLM的偏见问题、可靠性、实际应用（特别是代码测试生成）及其局限性。

讨论分支1中，satisfice强烈质疑帖子中将LLM视为无偏见预示者的观点，认为这是基于错误前提的“痴心妄想”，并强调LLM有偏见、不可靠且表现不稳定，认为作者未进行足够的测试。walterbell和troupo则将对LLM“痴心妄想”的经济驱动联想到历史上的郁金香狂热和近期的区块链泡沫，暗示当前对LLM的过度期待可能具有投机性泡沫的性质，进一步支持了satisfice的质疑。

讨论分支2中，TazeTSchnitzel质疑原帖子是否完整或仅是伪装的广告。saagarjha幽默地回应说，既然是关于AI的帖子，AI本应提示作者不要发布这种可能被视为不完整或广告的内容，反讽了AI的智能和帖子本身的质量。

讨论分支3中，brahyam讨论了LLM在代码生成测试方面的应用，认为编写形式化规范所需的时间可能超过直接生成代码所需的时间，限制了其主流应用，但在已存在形式化规范的行业中可能有用。marcoDewey回应brahyam，认为牺牲前期生成时间换取更可靠的代码和减少后续调试可以节省总体时间，并同意不太正式的规范也能帮助LLM生成更好的代码，确认了测试驱动方法的潜在益处。

讨论分支4中，bluefirebrand明确指出LLM存在多重偏见，包括训练数据、系统提示和用户提示带来的偏见，认为将其视为无偏见或中立是错误的。marcoDewey（可能是原帖作者或支持者）承认LLM存在偏见，但澄清他在谈论“无偏见预示者”时，并非指LLM完全没有偏见，而是在黑盒测试语境下，LLM在测试特定代码时缺乏对该代码内部实现的偏见。这表明双方对“无偏见”定义存在理解差异，marcoDewey试图缩小其主张的范畴。

讨论分支5中，Jensson对使用LLM生成测试用例提出了一个具体担忧：如果LLM生成的测试本身因为数学错误而有缺陷，可能会导致测试结果不可靠，甚至比人工实现代码出错的可能性更高，从而无法有效保障代码质量。

总的来说，讨论焦点围绕LLM的偏见和可靠性、其在代码测试生成领域的实际可行性及其潜在的经济投机性。存在明显分歧的是LLM是否能被称为“无偏见”（无论是完全无偏见还是在特定语境下的“相对”无偏见）及其可靠性水平。大部分热门评论对原帖将LLM视为“无偏见预示者”的观点持怀疑甚至反驳态度，情感倾向偏向于审慎和批判。

阅读原文

在儿童中，脑电图监测意识可安全减少麻醉剂用量

作者: LorenDB | 发布时间: 2025-04-30 21:46:38

内容摘要

儿童手术麻醉新进展：脑电图监测安全有效降低麻醉药用量

一项在日本进行的随机对照临床试验表明，在1至6岁的儿童手术中，利用脑电图（EEG）监测患者的意识状态，可以安全有效地减少麻醉药物七氟醚（sevoflurane）的使用量。这项研究由麻省理工学院和东京女子医科大学等机构合作完成，共有170多名儿童参与。

研究核心在于，不同于标准的麻醉方案，麻醉师根据脑电图显示的脑电波模式来实时调整麻醉药剂量。结果显示，使用脑电图引导的麻醉方案，诱导麻醉所需的七氟醚浓度从标准的5%降至2%，维持麻醉所需的浓度从标准的2.5%降至0.9%。

除了降低麻醉药用量，脑电图监测引导的麻醉还带来了多项术后结果的改善。接受脑电图引导麻醉的儿童平均拔除气管插管时间提前了3.3分钟，从麻醉中苏醒时间提前了21.4分钟，从术后护理中出院时间提前了16.5分钟。这些差异均具有统计学意义。同时，术后发生小儿麻醉苏醒期谵妄（PAED）的比例也显著降低，对照组为35%，而脑电图引导组为21%。试验过程中没有儿童出现术中知晓的情况。

研究人员指出，更快的术后恢复不仅对患儿健康更有益，还能降低医疗成本。此外，七氟醚是一种强烈的温室气体，减少其使用量对环境也有积极影响。

研究还分析了脑电图记录的脑电波差异，发现在麻醉维持阶段和接近苏醒阶段，两种方案下儿童的脑电波谱图存在显著差异。例如，脑电图引导组的脑电波在1-3赫兹和10-12赫兹频段显示出较高的功率带，而在标准方案组中，高达15赫兹的整个频率范围都呈现高功率。

这项研究为在儿童麻醉中应用脑电图监测提供了重要证据，证实通过监测脑电波可以为麻醉师提供可操作的指导，从而改善患儿护理。研究人员认为，在医院的持续医学教育实践中，可以很容易地整合阅读脑电图和指导用药的相关培训，以推广这一安全有效的麻醉方法。

讨论焦点

热门讨论主要围绕以下几个焦点展开：首先是对原始文章缺乏背景信息的质疑，特别是关于脑电图（EEG）监测在成人和儿童麻醉中的应用现状以及为何研究从儿童开始。其次是关于医学实践中存在的陈旧观念和教条，特别是婴儿是否会感受疼痛以及过去对疼痛管理的忽视，引发了对现代医学进步的肯定和担忧倒退的情绪。同时，讨论也深入探讨了全身麻醉对患者的副作用和影响，以及不同麻醉方式下的意识水平和记忆形成问题。最后，涉及了儿童在麻醉下是否会记住疼痛以及相关理论基础的演变。

阅读原文

间隔23年的天空巡天发现了备受争议的第九行星证据

作者: spchampion2 | 发布时间: 2025-05-03 05:13:07

内容摘要

摘要：

科学家在跨越23年的两次深空红外巡天数据中发现了支持备受争议的第九行星存在的新证据。一项由台湾清华大学团队进行的研究，梳理了1983年的红外天文卫星（IRAS）和2006年至2011年间的日本AKARI红外卫星的数据，成功识别出一个可能符合第九行星特征的单一天体。如果这个天体确认为第九行星，其质量将超过海王星，且距离太阳的距离约为地球到太阳距离的700倍，远超太阳系内已知行星的轨道范围。

长期以来，天文学家们曾提出“行星X”等假说来解释地球上周期性大灭绝等现象，但这些假说未能经受住更严谨的审视。第九行星的概念则是在2016年被提出，旨在解释柯伊伯带中一些天体（如塞德娜）异常聚集的轨道特征。假定的第九行星质量大于地球，并沿着高度偏心的轨道运行，使其极难被光学望远镜探测到。然而，预计第九行星在红外波段会更亮。

这项新研究利用了视差效应原理，通过比较不同年份同一日期在AKARI数据中的天体位置，消除了地球公转引起的视差影响。再结合IRAS数据进行对比，该团队找到一个在两份数据中位置发生微小移动的天体，这种移动与一个位于约700天文单位的遥远行星的预期运动轨迹一致。尽管目前运动数据不足以完全确定其轨道，但该发现显著增强了第九行星存在的可能性。

研究人员根据该天体在红外图像中的亮度，推测其质量可能大于海王星，这与之前基于超大质量类地行星进行的搜寻结果有所不同。第九行星如此遥远的和偏心的轨道形成原因仍然是未解之谜，可能是在太阳系早期与其他巨行星相互作用被甩出内部区域，或者是在太阳系的早期历史中捕获的一颗自由行星。

尽管此前也有在红外数据中发现第九行星候选的报道，但本次发现的优势在于该天体在跨越23年的两份独立数据中均有记录。未来的大型光学望远镜，如即将发射的南希·格蕾丝·罗曼空间望远镜和计划今年首次观测的维拉·C.鲁宾天文台，将有助于通过更长时间曝光的观测来确认这个候选天体，揭开第九行星是否存在最终的谜底。

讨论焦点

评论主要围绕文章中对第九行星位置的描述方式展开，AIPedant认为用“距离冥王星的15倍”比“距离地球的700倍”更能帮助读者理解其遥远。ck2、7373737373、oxidant、WillAdams和Nevermark等人通过提及各种形象化的类比和展示方式（如足球场比例、YouTube视频、实地模型、插画书）来进一步说明太阳系尺度和天体距离的难以想象。同时，讨论涉及第九行星可能的质量以及它是否可能是被太阳捕获的星际天体（1970-01-01和nonethewiser的讨论）。NikkiA、doubletwoyou和AIPedant针对使用AU作为单位进行讨论，指出大多数人对AU没有直观概念，且天体轨道并非正圆，使得相对距离描述复杂。rainsford感叹太阳引力作用范围之大即使在如此远距离仍能捕获天体。8bitsrule提出用光年单位作对比。bsdetector、fallingknife和codesnik则探讨了利用第九行星进行引力透镜成像的可能性和技术细节。

另一个焦点是第九行星的本质。randomtoast提出它可能是原初黑洞的理论，认为这可以解释引力效应但无法直接观测。api、TheOtherHobbes、ednite、kiba和zveyaeyv3sfye就此展开讨论，api对此寄予厚望，认为近距离的黑洞可用于物理学研究甚至星际旅行加速，ednite幽默地表示支持并设想探测场景和潜在收益，kiba则提及黑洞的发电潜力，而TheOtherHobbes和zveyaeyv3sfye表达了对黑洞近距离存在的担忧。ajross和lazide以及其嵌套回复perihelions认为文章描述的观测到第九行星的光不足以支持黑洞理论，因为观测的对象是可见的，即使天体很暗，黑洞也完全无光，且距离导致反射光极弱无法观测（lazide和perihelions的讨论）。Projectiboga和tlogan、Qem讨论了如果是黑洞的大小估算以及是否能被红外线观测到，Qem指出如果是黑洞则不会在红外线地图中出现。

第三个主要讨论点是关于冥王星和第九行星的命名以及行星定义问题。metalman和chess_buster、rini17等人表达了对冥王星被降级为矮行星的不满，希望冥王星重新获得行星地位。rini17提及谷神星也有类似经历，metalman对此表示了解但戏谑地提及谷神星用于改造火星计划。juped以幽默的方式称冥王星为第十颗行星，并说第九行星是海王星（暗指早期对海王星质量的误估导致寻找第九行星）。echelon质疑行星定义中“清除轨道”的合理性，认为这在行星形成初期或与大天体碰撞时会使天体无法定义为行星。brookst认为如果证实是黑洞，Planet X的名字反而更贴切。rollcat认为行星定义是武断的，更重要的是研究天体本身。gus_massa、ryao和irrational讨论了如果冥王星是行星，那么阋神星等其他跨海王星天体和谷神星也应被包含进来，ryao认为不应为了方便记忆而删减行星列表。

讨论分支4中，perihelions直接反驳了文章证据支持Batygin和Brown的第九行星假说，认为观测到的高倾角轨道与假说的低倾角不符。sph就perihelions的作者身份及其在冥王星降级事件中的角色进行提问，ufo解释了其团队发现阋神星等推动了冥王星地位的讨论以及他们也提出第九行星理论。db48x详细解释了冥王星被降级的历史背景，类比小行星的发现数量增加导致不再将所有小行星列为行星，认为冥王星和谷神星因是各自类别中最大的最早被发现，但本身并无特别之处。raverbashing坚持认为如果观测到的是大质量天体，即使轨道是椭圆的，也应该是第九行星。rozab和Qem、philistine回顾了冥王星的发现历史，指出最初基于海王星质量估算的错误驱动寻找第九行星，发现的冥王星质量远小于预期，是其被降级的真正原因。

讨论分支5中，K0balt再次表示希望第九行星是原初黑洞，认为会非常有用。jsbisviewtiful质疑其实用性，认为难以发现也难以研究。mrshadowgoose、jiggawatts和andrewflnr反驳了jsbisviewtiful的观点，认为相对于星际距离，太阳系内的黑洞是“后院”级别的，虽然探测需要时间，但一旦找到，发送探测器进行研究极具价值，可以作为极端物理的实验室。

阅读原文