2026-04-21 Hacker News Top Stories #

欧盟自2027年起强制在欧盟售卖的手机/平板配备可更换电池并保障至少5年替换与系统更新（必要工具免费），以降废减成本且对高循环寿命电池设豁免，但在厚度防护与低端机型上引发争议。

研究揭示2019-2024年约600万虚假星标形成灰色产业并误导融资，HN建议评估开源应重视活跃度、维护与下载等信号而非易被刷量的星标。

“骑自行车的鹈鹕”被社区当作轻松视觉基准以检验泛化与多步编辑一致性，但单次生成质量仍不稳常需迭代且话题重复引发审美疲劳，同时SVG/动画能力在进步。

Qwen3.6-Max-Preview 宣称在编码与知识等基准显著提升并已开放调用，但HN用户强调真实任务体验更关键、部分更青睐GLM/Claude在工具与文档处理上的表现并提醒为AI开命令行需隔离以保安全。

Atlassian 将默认收集云端产品元数据与内容训练AI（最长保留7年、部分等级可退）同时遭HN用户批评其长期Bug与AI质量不佳、过度堆功能而忽视基础稳定。

尽管存在“黑名单”与政策分歧，NSA仍有限接入Anthropic的Mythos用于内部安全扫描，HN指其做法自相矛盾、政治化且伴随稀缺叙事的营销。

作者批评以框架流程替代真实倾听会导致决策偏差与技术债，HN呼吁在精准与可读间取平衡、避免AI擅改文档并由管理层促进直接沟通。

基于可穿戴数据，桑拿当天夜间静息心率平均降约3次/分（女性期位差异明显），或因冷却期副交感增强而利于当日恢复但难以替代提升VO2max的运动。

ggsql 将图形语法引入SQL以在查询中直接VISUALIZE/DRAW并贴源渲染（Alpha 支持DuckDB/SQLite等、现用VegaLite），HN讨论了外部数据库连接与ADBC等扩展。

报道称特斯拉隐瞒Autopilot致命缺陷并以公路为测试场致多起事故、遭2.43亿美元判赔与联邦调查，HN指其常于事故前脱离自动驾驶而L2系统易致注意力松懈且真正无人驾驶仍罕见。

1. 2027 年起，所有在欧盟销售的手机必须配备可更换电池 (All phones sold in the EU to have replaceable batteries from 2027) #

https://www.theolivepress.es/spain-news/2026/04/20/eu-to-force-replaceable-batteries-in-phones-and-tablets-from-2027/

欧盟将于 2027 年 2 月 18 日起，强制要求在欧盟销售的智能手机和平板电脑必须配备可更换电池。新规规定，电池设计需允许用户无需专业工具或帮助即可自行拆卸和更换，且替换电池必须在产品最后一台销售后至少五年内持续供应。如果需要专用工具，制造商必须免费提供。

此举旨在减少电子废弃物，降低用户更换电池的成本，避免因电池损耗而频繁更换整机，预计到 2030 年可为欧洲消费者节省约 200 亿欧元。此外，欧盟还要求手机电池更耐用，抗磨损能力更强，并自 2025 年起，手机系统更新必须保证至少五年支持。另一个相关规定是，自 2024 年起，所有手机和平板电脑必须使用统一的 USB-C 充电接口。

欧盟数据显示，每年约有 1.5 亿智能手机和 2400 万平板电脑在欧盟销售，产生约 500 万吨电子废物，但回收率不足 40%。新规的实施将有助于提升电子产品的可持续性，减少环境负担。

HN 热度 876 points | 评论 730 comments | 作者：ramonga | 10 hours ago #

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

可更换电池的设备有多种优势，如可携带多个电池备用、充电时只需放电池而非整机，延长设备使用寿命，且便于使用老旧设备。
手机对厚度和抗摔性要求较高，这使得更换电池设计变得复杂，有人不欢迎强制更换电池的规定。
现代手机厚度并非因可更换电池而增加，过去已有多款薄型可更换电池手机，且带保护壳后厚度差异不大。
过去的智能手机如 Galaxy S5 支持可更换电池且具备防水功能，电池寿命逐渐缩短使得换电池比升级设备更经济。
相机同样重视体积和抗摔性，且通过更换电池实现便携和续航，用户通常携带多个电池而非更大机身。
自行更换电池的难点在于采购高质量电池，尤其在无官方服务的地区，劣质电池寿命和性能较差。
一些运动相机有可更换电池，有的则没有，电池寿命问题导致设备报废。
如果电池能达到 1000 次充放电循环且容量保持 80% 以上，则可免于强制更换电池的规定，低价手机受影响较大。
欧盟法规要求制造商确保电池更换过程简单易行，或者电池需满足高循环寿命和容量保持标准，同时设备需具备一定防尘防水能力。

2. GitHub 上的虚假星标经济 (GitHub’s fake star economy) #

https://awesomeagents.ai/news/github-fake-stars-investigation/

这篇文章深入调查了 GitHub 上的虚假“星标”经济现象。根据卡内基梅隆大学等机构在 ICSE 2026 会议上发表的同行评审研究，2019 年至 2024 年间，约有 600 万个虚假星标分布在 1.86 万个仓库中，涉及约 30.1 万个账户。2024 年虚假星标问题急剧加剧，超过 16% 的热门仓库参与了虚假星标活动，其中 AI 和大型语言模型相关仓库是最大的非恶意虚假星标接受者。

虚假星标的价格从每颗 0.03 美元到 0.85 美元不等，存在多个公开网站、自由职业平台和 Telegram 频道出售星标，甚至有专门的 API 支持程序化购买。卖家提供不同质量的账户，从新建空白账户到多年活跃的老账户，部分服务还承诺星标不会被 GitHub 检测系统删除。虚假星标市场已经形成了成熟的产业链，包括伪造贡献图的开源工具和高价出售带有丰富历史的 GitHub 账户。

文章作者通过 GitHub API 对 20 个仓库进行了抽样分析，发现虚假星标仓库的星标者多为无关注者、无公开仓库的“幽灵账户”，且这些账户年龄较长，规避了简单的年轻账户过滤。虚假仓库的“fork-to-star”和“watcher-to-star”比例远低于正常仓库，表明这些星标并未带来真实的使用或关注。以 FreeDomain 仓库为例，拥有 15.7 万个星标，但只有 168 个关注者和 2676 个 fork，显示出明显的虚假繁荣。

此外，风险投资机构明显将星标数作为项目吸引力的重要指标，部分 VC 使用自动化工具监测快速增长的仓库，虚假星标直接影响融资决策。美国联邦贸易委员会和证券交易委员会已开始对虚假影响力指标和融资数据造假进行处罚，违规成本高昂。

总体来看，GitHub 上的虚假星标经济已成为一个公开且专业化的地下产业，涉及大量账户和资金流动，严重影响了开源社区的生态和风险投资的判断标准。文章通过数据分析和市场调研，全面揭示了这一现象的规模、运作机制及其对行业的深远影响。

HN 热度 719 points | 评论 352 comments | 作者：Liriel | 15 hours ago #

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

评价开源库时，星标数并非决定性指标，更应关注最后提交时间、项目年龄、问题处理情况和代码质量等实际因素。
星标数可以作为快速筛选的启发式方法，尤其在多个库竞争时，但不能完全依赖，需结合下载量和发布频率等指标。
过度依赖星标数可能导致安全隐患，尤其在关键项目中，容易忽视潜在的供应链攻击风险。
星标数在极端情况下有一定参考价值，如新项目和大型公司维护的项目，但中间区间的星标数差异意义不大。
星标数可能被人为刷高，存在虚假和欺骗的风险，购买星标并不代表项目质量或维护意愿。
星标数更多反映的是项目的市场营销效果和受欢迎程度，而非技术质量或维护状态。
选择库时应结合文档质量、社区活跃度、问题响应速度等多维度指标，而非单纯依赖星标数。
对于重要系统，应花时间深入评估项目的技术细节和安全性，避免因星标数误判而带来风险。
星标数对个人项目或玩具项目影响较小，但在企业或投资决策中应谨慎使用。
星标数的价值在于引导关注，但最终决策应基于更全面的项目健康状况和实际需求。

3. Kimi K2.6：推动开源编码的进步 (Kimi K2.6: Advancing open-source coding) #

https://www.kimi.com/blog/kimi-k2-6

该网页主要介绍了开源模型 Kimi K2.6 的最新进展及其在长时程编码任务中的卓越表现。Kimi K2.6 在多种编程语言（如 Rust、Go、Python）和复杂工程任务中表现出色，显著优于前一版本 K2.5。其在内部基准测试中展示了代码生成准确率提升 12%、长上下文稳定性提升 18%、工具调用成功率达到 96.6% 的显著进步。

K2.6 能够自主完成复杂任务，如在 Mac 本地下载并部署 Qwen3.5-0.8B 模型，优化模型推理速度达 20% 快于竞争产品 LM Studio；还成功优化了一个运行近极限的开源金融撮合引擎，提升中位吞吐量 185%，性能吞吐量 133%。该模型在企业级长时程编码测试中表现稳定，具备强大的指令执行和多步骤任务处理能力，能够发现深层次的代码缺陷，极大节省开发者时间。

多位业内专家和合作伙伴对 K2.6 给予高度评价，认为其在开源模型中树立了新的标杆，尤其适合复杂、长时程的自动化编码和智能代理工作流。K2.6 不仅提升了工具调用的主动性和智能度，还支持从简单提示生成完整前端界面，包含结构化布局、交互元素和丰富动画，甚至扩展到简单的全栈开发流程。

总体来看，Kimi K2.6 凭借其卓越的编码能力、稳定性和高效的工具调用，成为支持长时程、多步骤工程任务的强大开源模型，适合构建复杂的自动化代理和智能开发工具，推动开源 AI 编码技术的前沿发展。

HN 热度 529 points | 评论 272 comments | 作者：meetpateltech | 8 hours ago #

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

这个“骑自行车的鹈鹕”图像成为了一个轻松有趣的视觉基准测试，传统上并未被模型专门训练，能反映模型的泛化能力。
有人认为单次生成的结果较为粗糙，需多次迭代和分步引导才能获得更接近人类水平的作品。
目前生成的鹈鹕图像质量普遍不高，远不及专业设计师的作品，更多是低成本的尝试。
该测试被视为一种传统和乐趣，尽管有些人觉得重复出现的讨论有些乏味甚至像低质量的刷屏。
有观点指出，随着模型训练的进步，生成 SVG 和动画的能力在提升，相关任务可能已被纳入训练范畴。
通过分步编辑和多轮反馈，AI 生成的作品质量和符合预期的概率会更高。
有人质疑“好”的标准，因为“骑自行车的鹈鹕”本身没有固定的正确答案。
部分评论认为该话题是社区的传统，能过滤出对细节过于较真的用户。
也有人觉得频繁出现类似评论影响讨论质量，认为这类内容更适合轻松场合。
有评论提到具体作品的动画细节仍有缺陷，比如鹈鹕腿部动作不自然。

4. Qwen3.6-Max-Preview：更智能、更锐利，持续进化 (Qwen3.6-Max-Preview: Smarter, Sharper, Still Evolving) #

https://qwen.ai/blog?id=qwen3.6-max-preview

Qwen 团队发布了 Qwen3.6-Max-Preview，这是他们下一个专有模型的早期预览版本。与之前的 Qwen3.6-Plus 相比，这一预览版本在多个方面有显著提升，包括更强的世界知识、指令跟随能力以及在各种基准测试中的编码能力。值得注意的是，Qwen3.6-Max-Preview 仍在积极开发中，团队会继续进行迭代，预计后续版本会有更多改进。

Qwen3.6-Max-Preview 可通过阿里云模型工作室提供，具有以下特点：相较于 Qwen3.6-Plus，编码能力有显著提升，世界知识和指令跟随能力增强，以及更好的现实代理和知识可靠性表现。用户可以在 Qwen Studio 上进行互动聊天，也可以通过 API 进行调用。

在性能方面，Qwen3.6-Max-Preview 在多个重要模型中表现出色。与 Qwen3.6-Plus 相比，在编码能力上，它在 SkillsBench、SciCode、NL2Repo 和 Terminal-Bench 2.0 等基测试中都有显著的提升。此外，它在世界知识和指令跟随能力方面的提升同样显著，分别在 SuperGPQA 和 QwenChineseBench 测试中取得了不错的成绩。

Qwen3.6-Max-Preview 将在阿里云模型工作室上推出，用户可通过 API 进行访问，具体模型名称为 qwen3.6-max-preview。此次发布支持 “preserve_thinking” 特性，可以在代理任务中保留所有前置消息中的思考内容。

在使用 API 时，用户需要设置一些环境变量，包括 DASHSCOPE_API_KEY（来自阿里云模型工作室的 API 密钥），以及可选的 DASHSCOPE_BASE_URL（指定 API 的基础 URL）。提供了 Python 代码示例，帮助用户使用聊天完成 API。

总之，Qwen3.6-Max-Preview 作为下一个专有模型的早期预览版本，相较于前一版本在多个方面都有显著的进步，尤其是在编码能力、世界知识和指令跟随方面表现突出。尽管仍在开发中，团队期待用户的反馈，并希望看到用户基于该模型构建的各种应用。请继续关注后续的更新和发布。

HN 热度 500 points | 评论 249 comments | 作者：mfiguiere | 9 hours ago #

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

各模型在实际应用中的表现差异较大，不能单纯以基准测试结果判断优劣，使用体验和具体任务需求更重要。
GLM 5.1 模型被认为在代码生成和文档处理方面表现出色，甚至让部分用户取消了其他付费模型订阅。
Claude 和 ChatGPT 的工具调用和技能支持较好，尤其是在文档和 Excel 文件处理方面表现优异。
Qwen 和 Deepseek 的网页版聊天工具在输出文档格式方面存在不足，难以满足部分用户需求。
通过命令行工具或特定的 agent harness，可以更好地利用模型进行文件操作和复杂任务处理。
给予 AI 命令行访问权限存在安全隐患，建议在虚拟机或受限用户环境中运行以降低风险。
Qwen 3.5 和 3.6 版本在工具调用方面表现优异，值得再次尝试。
Codex 和 Claude Code 等工具对本地模型支持良好，能较好地完成代码和文档相关任务。
Qwen3-Coder 在生成利用 Rust 的 x86-64 向量化扩展代码方面表现优于 Claude Opus 和 Google Gemini。
Claude 生成的代码质量较低但迭代次数少，适合快速推进项目；Codex 则更注重代码质量。
不同模型在基准测试中表现相近，选择时可根据插件支持和集成环境等其他因素决定。
GLM 模型运行较慢但表现稳定，适合需要深入分析和调试的场景。
Opus 模型 API 价格较高，使用成本显著高于 GLM，限制了部分用户的选择。

5. Atlassian 启用默认数据收集以训练人工智能 (Atlassian enables default data collection to train AI) #

https://letsdatascience.com/news/atlassian-enables-default-data-collection-to-train-ai-f71343d8

Atlassian 宣布将从 2026 年 8 月 17 日起，默认收集 Jira、Confluence 及其他云产品的客户元数据和应用内内容，用于训练其 AI 产品如 Rovo 和 Rovo Dev。此次变更影响约 30 万客户，Free、Standard 和 Premium 等级的元数据收集为强制且不可选择退出，Enterprise 客户则可选择退出。收集的数据将保留最长七年，应用内数据在删除或选择退出后 30 天内移除，相关模型将在 90 天内重新训练。使用客户管理密钥、Atlassian 政府云、隔离云或符合 HIPAA 要求的客户不在收集范围内。

技术上，Atlassian 区分了两类数据：元数据包括去标识的信号如可读性、复杂度评分、任务分类、语义相似度、故事点、冲刺结束日期及服务管理 SLA 值；应用内数据则涵盖用户生成内容，如页面标题、Jira 问题描述、评论、自定义表情和状态名称等。公司承诺移除直接标识符并进行数据聚合和保护。

不同等级的默认设置有所区别：Free 和 Standard 客户元数据收集始终开启且不可关闭，应用内数据默认开启但可配置；Premium 客户元数据始终开启，应用内数据默认关闭；Enterprise 客户两者默认关闭且可选择退出。高安全需求客户和特定部署环境被排除在外。

此政策标志着 Atlassian 从之前不使用客户数据训练 AI 的立场转变，反映了行业普遍趋势，即通过收集内部使用信号和内容来优化模型。Atlassian 表示此举将提升搜索相关性、摘要质量、模板建议和工作流程优化等功能。

然而，强制收集元数据引发隐私和治理担忧，尤其是故事点和 SLA 等数据可能暴露项目结构和绩效模式。长期保留数据增加了风险和合规负担。尽管有排除机制，但需要客户升级计划或迁移特殊部署。

建议组织评估 Atlassian 租户的计划等级，调整管理设置，并考虑是否迁移至 Enterprise 或隔离部署以实现完全退出。未来需关注 Atlassian 如何执行 90 天内模型再训练，以及相关大型语言模型供应商是否承诺不保留输入数据。此举可能引发客户反弹和监管关注，成为企业 SaaS 数据治理和模型来源管理的重要案例。

HN 热度 467 points | 评论 110 comments | 作者：kevcampb | 11 hours ago #

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

Atlassian 产品存在大量严重且长期未解决的 Bug，尤其是 Bitbucket 和 JIRA，导致用户体验极差。
Atlassian 的 AI 功能表现糟糕，免费试用期无法在线取消，客服支持流程混乱且难以联系。
公司内部存在技术债务、人才流失和组织频繁变动，导致产品维护和质量下降。
Atlassian 过度追求新功能开发，忽视基础功能的稳定性和用户需求。
JIRA 的搜索功能极其糟糕，常常无法准确找到已有的工单，用户只能通过邮件搜索替代。
大型企业普遍存在内部腐败和低效问题，导致产品质量下降难以避免。
Atlassian 逐步关闭自托管版本，可能导致对质量保证的重视度降低。
迁移到其他工具（如 linear.app）相对简单且值得投入，用户有导出数据的需求和方法。

6. NSA 尽管被列入黑名单，仍在使用 Anthropic 的 Mythos (NSA is using Anthropic’s Mythos despite blacklist) #

https://www.axios.com/2026/04/19/nsa-anthropic-mythos-pentagon

美国国家安全局（NSA）正在使用 Anthropic 公司最新的强大模型 Mythos Preview，尽管国防部高层坚持认为 Anthropic 存在“供应链风险”。这一情况显示，政府的网络安全需求正在超过五角大楼与 Anthropic 之间的矛盾。

今年 2 月，国防部曾试图切断与 Anthropic 的合作，并要求其供应商效仿，但相关争议仍在继续。NSA 及国防部内部正在扩大对 Anthropic 工具的使用，尽管官方在法庭上声称这些工具威胁美国国家安全。

据消息人士透露，NSA 是少数获得 Mythos 访问权限的约 40 个组织之一，Anthropic 限制了该模型的访问范围，理由是其攻击性网络能力过于危险。Mythos 主要被用于扫描自身环境中的安全漏洞。英国的情报机构也通过该国的人工智能安全研究所获得了该模型的使用权。

Anthropic CEO Dario Amodei 近期与白宫幕僚长 Susie Wiles 及财政部长 Scott Bessent 会面，讨论了 Mythos 在政府中的应用及安全措施，双方均认为会议富有成效，后续将关注除国防部外其他部门的使用情况。

此前，国防部与 Anthropic 在合同谈判中出现分歧，国防部要求 Anthropic 允许其 Claude 模型用于“所有合法目的”，而 Anthropic 则坚持禁止大规模国内监控和自主武器的开发。一些国防官员质疑 Anthropic 的可靠性，但政府内部也有声音希望结束争端，充分利用 Anthropic 的先进技术。Anthropic 及相关部门对此未作公开评论。

HN 热度 428 points | 评论 309 comments | 作者：Palmik | 13 hours ago #

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

NSA 使用 Anthropic 的 Mythos 产品，尽管该公司被列入黑名单，显示出政府的虚伪和矛盾。
这种现象并非仅限于当前政府，过去的多届政府也存在类似的腐败和不一致行为。
有观点认为拜登政府相较于现任政府更有能力且腐败程度较低。
政府对 Anthropic 的供应链风险指控被认为是政治操作而非技术问题。
Anthropic 通过制造产品的人工稀缺性和炒作安全风险，成功在商业和政治上获得利益。
OpenAI 也采用类似策略，夸大产品风险以吸引关注和控制市场。
有人指出市场操纵和政治腐败普遍存在，且在不同政府间表现形式不同。
讨论中存在对双方观点的疲劳和不信任，辩论往往陷入无休止的循环和信息拒绝。
Anthropic 通过发布漏洞哈希证明其安全报告的真实性，显示出比 OpenAI 更透明的态度。

7. 别再试图通过设计方案来逃避倾听他人 (Stop trying to engineer your way out of listening to people) #

https://ashley.rolfmore.com/stop-trying-to-engineer-your-way-out-of-listening-to-people/

这篇文章由 Ashley Rolfmore 撰写，主要探讨了在软件开发和设计领域中，倾听用户和团队成员的重要性以及常见误区。作者指出，很多问题的根源在于人们不愿意真正去听取他人的声音，而试图通过构建各种“框架”或“系统”来替代直接沟通，这实际上是在逃避真正的工作。

文章详细列出了倾听时常见的几个陷阱：误以为倾听就是简单满足用户需求、低估专业领域对个人世界观的影响、将“技术”简单二分、假设每个人拥有相同的资源和能力、认为人和组织是静态不变的、误解人们所说的话即是他们真实想法、带有偏见地评判他人，以及忽视个体差异，尤其是在 B2B 环境中复杂的人际关系和组织动态。

作者强调，真正有效的倾听不仅能帮助发现最有价值的信息，推动产品和业务发展，还能减少技术债务，因为每一次误解都会在代码中留下隐患。文章呼吁大家正视倾听的难度，避免上述误区，从而提升沟通质量和工作效果。

HN 热度 396 points | 评论 255 comments | 作者：walterbell | 1 day ago #

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

精准用词很重要，但过于简洁的文档可能让读者难以理解，需要在精确和可读性之间找到平衡。
经理未经告知使用 AI 改写文档，导致内容错误且难以使用，体现了管理上的失误。
通过 AI 改写文档可能是因为原文过于简洁，难以让非专业读者理解，但这种做法破坏了原作者的意图和准确性。
管理者不应成为员工之间沟通的障碍，应该促进直接交流，避免信息失真。
解决问题的关键是修复沟通机制或学会适应现有的沟通方式，而不是单纯指责管理层。
没有看到具体文本就对文档质量做出判断是不负责任的，建议基于事实进行讨论。

8. 桑拿对心率的影响 (Sauna effect on heart rate) #

https://tryterra.co/research/sauna-effect-on-heart-rate

这篇文章探讨了桑拿对心率和身体恢复的即时影响，基于 256 名可穿戴设备用户约 59,000 条日常记录的数据分析。研究发现，桑拿当天夜间静息心率平均下降约 3 次/分钟，这种降低在控制了运动量后依然显著，表明桑拿带来的心率下降不仅仅是运动后的副作用，而是一种真实的生理恢复信号。

桑拿天的活动量更高，最大和平均心率也更高，符合许多人在锻炼后使用桑拿的习惯。女性在桑拿日的活动增加更明显，但夜间心率下降幅度小于男性。进一步分析显示，女性的月经周期阶段对桑拿效果有影响：只有在黄体期，桑拿才显著降低夜间心率，而在卵泡期这种效果较小，提示桑拿的恢复效应可能与月经周期密切相关。

桑拿通过热应激机制提升心率，随后冷却阶段心率下降，反映了副交感神经的增强，这种生理变化支持桑拿有助于身体恢复。文章还回顾了桑拿的历史和其促进血液循环、排毒及肌肉修复的传统疗效，强调桑拿作为恢复手段的科学依据和实际效果。

总体来看，桑拿不仅是锻炼后的放松方式，更是一种促进当日恢复的有效手段，尤其对女性在特定生理周期阶段的恢复效果更为显著。

HN 热度 344 points | 评论 189 comments | 作者：kyriakosel | 10 hours ago #

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

桑拿能显著降低夜间心率，效果超过同等强度的运动，可能是因为桑拿后的冷却阶段提升了副交感神经张力。
桑拿对女性夜间心率的影响在黄体期明显，卵泡期无显著效果，需进一步验证。
桑拿虽然能让心肺系统工作类似轻度运动，但并不能替代运动对四肢肌肉的锻炼。
心率加快并不等于心肺功能提升，桑拿不能有效提高 VO2 max 等心肺适能指标。
桑拿对心血管系统有一定益处，但不能全面替代运动带来的多方面身体压力和适应。
轻度跑步对心血管健康的提升有限，桑拿的效果也不能被过度夸大。
热带高温环境下人们的健康和寿命并未因常年高温而显著改善，说明环境温度与桑拿效益不同。
桑拿产生的热冲击与高温天气不同，桑拿更像是短时间的热应激。
饮食习惯可能影响热暴露带来的健康效益，某些地区的饮食不健康可能抵消热暴露的正面影响。
桑拿若频繁使用，可能存在过度热应激的风险，类似于运动过度。
心脏肥大不一定是坏事，运动引起的心脏肥大通常是积极适应，能提高心脏效率。

9. ggsql：基于 SQL 的图形语法 (ggsql: A Grammar of Graphics for SQL) #

https://opensource.posit.co/blog/2026-04-20_ggsql_alpha_release/

本文介绍了 ggsql，一种基于 SQL 语法实现的图形语法工具，旨在让用户能够直接在 SQL 查询中描述数据可视化。ggsql 目前处于 alpha 版本，支持在 Quarto、Jupyter 笔记本、Positron 和 VS Code 等环境中使用。

文章首先通过示例展示了 ggsql 的基本用法。以内置的企鹅数据集为例，用户可以通过 VISUALIZE 语句映射数据列到视觉属性（如 x 轴、y 轴、颜色），再用 DRAW 语句绘制点图、平滑回归线等图层。ggsql 的设计理念是模块化，没有预定义的图表类型，用户可以自由组合映射和图层，灵活构建各种图形。

接着，文章给出了一个完整的示例，展示如何结合 SQL 查询和可视化语句实现复杂图表。示例中使用了 CTE 和窗口函数处理宇航员数据，计算年龄相关指标，并通过 VISUALIZE 和 DRAW 语句绘制带有直方图、标记线和文本注释的图表。文章详细解释了 SQL 查询部分和可视化部分的关系，强调 SQL 查询结果直接作为可视化数据源，无需额外导出表格。

总体来看，ggsql 将数据查询和可视化紧密结合，利用 SQL 的表达能力和图形语法的灵活性，帮助用户在熟悉的 SQL 环境中高效创建丰富的图形展示。文章通过示例和分步讲解，帮助读者理解 ggsql 的核心概念和使用方法。

HN 热度 330 points | 评论 71 comments | 作者：thomasp85 | 11 hours ago #

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

ggsql 是一个将可视化查询转换成 SQL 查询，并直接连接数据库执行的工具，支持 DuckDB、SQLite 和实验性的 ODBC 读取器。
ggsql 默认使用内存中的 DuckDB，也可以通过命令行参数或 Positron 的连接面板连接外部数据库。
目前主要聚焦于本地文件和 DuckDB，连接远程数据库可能存在一些问题，需要进一步完善。
该工具适合熟悉 SQL 但不熟悉 Python 或 R 的用户，方便直接基于 SQL 进行数据可视化。
有用户建议支持 ADBC 以便连接更多数据库，如 BigQuery。
通过 DuckDB 的 Postgres 扩展，可以间接连接 Postgres 数据库，实现数据可视化。
目前文档和示例较少，用户希望先完善文档再制作教学视频。
ggsql 通过“reader”概念处理不同数据库的 SQL 方言，生成相应的查询语句。
该工具的优势在于将复杂的统计计算转换为 SQL 查询，减少传输数据量，提高绘图效率。
有用户质疑为何要创建新的 SQL 类语言，而不是扩展现有工具如 dbplyr 和 ggplot。
该项目旨在为只懂 SQL 的分析师提供一个统一的可视化语法，简化绘图流程。
有用户认为 Python 的绘图库使用复杂，ggsql 提供了更简洁的语法和快速迭代的体验。
该工具是一个独立的可视化应用，当前使用 Vegalite 进行渲染，未来计划支持更多后端和渲染器。

10. 特斯拉隐瞒致命事故以继续测试自动驾驶 (Tesla concealed fatal accidents to continue testing autonomous driving) #

https://www.rts.ch/info/monde/2026/article/tesla-dissimule-des-milliers-d-incidents-de-conduite-autonome-mortels-29214161.html

这篇报道揭示了特斯拉隐瞒了超过 2400 起自动加速投诉和 1000 多起与其“Autopilot”自动驾驶系统相关的事故。通过内部数据泄露，显示特斯拉多年来一直知晓其自动驾驶系统存在致命缺陷，却未向公众披露。

调查指出，特斯拉利用公共道路作为自动驾驶技术的测试场，急于推向市场，导致多起严重甚至致命事故。部分车辆出现无故急加速或急刹车的“幻觉”现象，系统错误识别路况，造成严重后果。受害者及其家属指控特斯拉隐瞒关键信息，特斯拉则将责任归咎于驾驶员。

在一起致命事故中，特斯拉声称车辆“黑匣子”数据损坏，但专家通过技术手段恢复了数据，证实特斯拉早已知晓系统故障。美国陪审团判决特斯拉赔偿受害者 2.43 亿美元，确认制造商和驾驶员均负有责任。该判决被视为自动驾驶领域的里程碑，强调制造商不能将公共道路当作实验场。

目前，美国司法部和国家公路交通安全管理局正在对特斯拉的商业行为和安全问题展开多项调查，关注其是否误导消费者。整体来看，自动驾驶技术的安全隐患和监管缺失引发广泛关注，受害者呼吁加强监管和责任追究。

HN 热度 310 points | 评论 189 comments | 作者：doener | 11 hours ago #

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

特斯拉自动驾驶在事故发生前几秒关闭自动驾驶功能，避免事故被记录为自动驾驶状态，令人震惊。
SAE 2 级自动驾驶（车道保持和自适应巡航）存在安全隐患，驾驶员难以持续保持注意力并随时接管。
SAE 3 级自动驾驶要求驾驶员在系统请求时接管，但这也容易导致驾驶员注意力分散。
有人选择不使用巡航控制，认为持续主动驾驶更安全，能随时做出决策。
自动驾驶技术尚处于实验阶段，驾驶员不应完全依赖，因事故风险较高。
车辆若配备方向盘，说明制造商对完全自动驾驶技术缺乏信心。
完全自动驾驶车辆缺少手动控制会面临法规和实际操作的挑战。
自动驾驶系统难以应对所有复杂场景，如特殊停车环境等。
目前全球只有少数地区有真正的自动驾驶出租车，其他大多是高级驾驶辅助系统。
自动驾驶车辆的速度控制策略存在问题，不能灵活调整，可能导致超速或行驶缓慢。
老款特斯拉因硬件限制无法使用最新的自动驾驶软件，表现不如新款。
自动驾驶系统在高速公路左侧车道行驶时，可能速度过慢且驾驶员注意力不集中，存在安全隐患。

Hacker News 精彩评论及翻译 #

Turtle WoW classic server announces shutdown after… #

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

I ran a private server years ago. Two things people in this thread are getting wrong:

The engineering is way harder than anyone gives credit for. You’re reverse engineering a server protocol from the client binary, writing your own spell systems (thousands of spells, each with edge cases), pathing, instancing, combat mechanics. Then scaling it for a few thousand concurrent players on hardware you’re paying for out of pocket. Turtle WoW went further and built new raids, zones, races on top of all that. That’s not modding, that’s game development without any of the tools the original team had.

The “they made millions” framing is always misleading. You start as a hobby, players show up, hosting costs get real, you take donations to keep it running, and at some point your paypal has six figures running through it over a few years. None of that is profit, it’s servers and bandwidth and people helping keep the thing alive. But in the lawsuit it gets presented as revenue from a commercial enterprise.

Blizzard is right to protect their IP. But calling this a simple piracy operation misses what actually happened.

saadn92

我多年前运营过一个私服。大家在这个讨论里有两处理解错误：

首先，技术难度远比一般人想象的要大。你得从客户端的二进制文件中逆向工程服务器协议，自己写法术系统（成千上万的法术，每个都有各种细节和特殊情况）、寻路、分本、战斗机制。然后还得支持几千名玩家同时在线，且服务器硬件费用全由自己承担。Turtle WoW甚至更进一步，在此基础上开发了新的团队副本、新地图、新种族。这已经不是简单的mod，而是缺乏原开发团队任何工具辅助下的游戏开发。

其次，说“他们赚了几百万”是误导性的。开始只是爱好者项目，玩家陆续加入，托管费用开始变得高昂，你开始接受捐款维持服务器，再后来几年里，PayPal账户收支累计达到六位数。这些钱完全不是盈利，而是服务器费用、带宽费用以及为维持项目运转所支付的各项开销。但在诉讼中，这些被当作商业企业的收入来描述。

暴雪保护自己的知识产权是正确的，但把这仅仅看作简单的盗版行为，并没有真正理解事情的前因后果。

John Ternus to become Apple CEO #

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

Tim Cook’s experience in logistics built Apple into the global hegemon it is today. I hope John Ternus’s experience with hardware can kick off a renaissance in both Apple hardware and software design. Mind you, Apple hardware is already amazing, but hopefully it can be even better with Ternus at the helm. Apple software is terrible, and hopefully Ternus can turn that around. I’m also hoping, without any evidence, that maybe a change in leadership will change how Apple participates in US politics.

EDIT: I also want to say I really appreciate Tim Cook’s emphasis on user privacy and I hope John Ternus can continue this trend.

Tyrubias

蒂姆·库克在物流方面的经验造就了今天苹果的全球霸主地位。我希望约翰·特纳斯在硬件方面的经验能够引领苹果硬件和软件设计的复兴。要知道，苹果硬件已经非常出色了，但希望在特纳斯的带领下能变得更好。苹果的软件很糟糕，希望特纳斯能扭转这一局面。我也希望，虽然没有任何证据，领导层的变化或许会改变苹果参与美国政治的方式。

补充：我还想说，我非常赞赏蒂姆·库克对用户隐私的重视，希望约翰·特纳斯能继续保持这一趋势。

GitHub’s fake star economy #

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

Can anyone explain why on earth VC’s are making actual investment decisions based on imaginary internet points?

The answer is right there in front of your face. Say it with me: VCs are morons. VCs are morons. VCs are morons. Just because someone is rich, you think that means they have any clue what they’re doing?

kibwen

有人能解释一下为什么风投居然会根据虚拟的网络积分来做实际的投资决策吗？

答案就摆在你面前。跟我一起说：风投是傻瓜。风投是傻瓜。风投是傻瓜。只是因为某人有钱，你就以为他们知道自己在做什么了吗？

All phones sold in the EU to have replaceable batt… #

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

Your experience is not at all what I see out there. Most people I know only get new phones because their battery will no longer get them through the day. They hate having to set up a new phone when their old one is totally fine other than the battery.

For the people I know that do upgrade their phones regularly, they typically want to give their old phone to someone who would love a usable phone, but can’t afford a new one. Giving a phone with a shot and non-replaceable battery effectively destroys the value of the gift.

I know many people who can’t afford to by new, and they avoid buying older or used phones because they fear the battery may be shot.

We obviously have different opinions regarding what most people want… totally fine.

coda_

你的经历和我所见的大不相同。我认识的大多数人换新手机，都是因为电池已经无法支持他们一整天的使用。他们讨厌必须设置一部新手机，而其实旧手机除了电池问题外其他都没问题。

我认识的那些经常换手机的人，通常是想把旧手机送给那些渴望拥有可用手机但买不起新手机的人。给出一部电池损坏且无法更换的手机，实际上等于毁掉了这份礼物的价值。

我认识很多买不起新手机的人，他们也避免买旧手机或二手机，因为担心电池可能已经损坏。

显然，我们对大多数人的需求看法不同……这没问题。

All phones sold in the EU to have replaceable batt… #

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

If a battery can do 1000 cycles and remain above 80% capacity it is exempt from this, which is exactly what Apple implemented a few years ago.

Low cost phones will be most affected.

twilo

如果电池能够完成1000个充放电循环且容量保持在80%以上，则可以豁免于此规定，而这正是苹果几年前实施的做法。

低成本手机将受到最大的影响。

Sauna effect on heart rate #

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

Author here. Methodology upfront because I’d ask the same things:

Data: daily records from wearable users who logged sauna sessions via connected apps. Within-person design — each user is their own control, comparing their own sauna-day nights against their own non-sauna-day nights. No cross-user comparisons.

Stats: paired t-tests, FDR-corrected p < 0.05, Cohen’s d > 0.2 threshold for “meaningful effect.” Anything below d=0.2 we don’t report as a finding.

What we measured: minimum nighttime HR, max and average HR, HRV, activity minutes and distance, menstrual cycle phase (for female subset).

What we found: - On sauna days, minimum nighttime HR drops ~3 bpm (~5%) vs. the same user’s non-sauna days. - Effect survives controlling for activity level. It’s not “sauna users just exercised more that day.” - Strongest hypothesis: elevated parasympathetic tone from the post-sauna cooling phase carries into sleep. Consistent with heat-stress physiology literature. - Sex difference: for women, the nighttime HR effect only crosses the d > 0.2 threshold during the luteal phase. No meaningful effect during the follicular phase. We didn’t expect this; worth replicating.

What we can’t control for: - Sauna type (dry / infrared / steam), duration, temperature. Not captured. - Dose-response. We don’t know session length per user. - Timing of sauna relative to sleep. - Reverse causation: people may sauna on days they already feel recovered. - Selection: wearable users who bother logging sauna are a health-conscious cohort.

What surprised us: the effect is larger than what we see for comparable-intensity exercise days. If you treat nighttime HR as a parasympathetic recovery signal, sauna beats a moderate workout on the same user. Not what I’d have predicted.

kyriakosel

作者本人。先说明方法论，因为我也会问同样的问题：

数据来源：通过连接app记录桑拿时长的可穿戴设备用户的每日数据。采用个体内设计——每位用户作为自己的对照，比较同一用户桑拿日的夜间数据和非桑拿日的夜间数据。不进行用户间比较。

统计方法：配对t检验，使用FDR校正后的p值<0.05，Cohen’s d > 0.2作为“有意义效应”的阈值。d值低于0.2的不报告为结果。

测量指标：夜间最低心率，最高和平均心率，心率变异性，活动分钟数和距离，女性用户的月经周期阶段。

研究发现：- 桑拿日夜间最低心率比非桑拿日降低约3次/分钟（约5%），以同一用户为比较基准。- 该效应在控制活动水平后依然存在，排除“桑拿日用户锻炼更多”的可能。- 最强假设：桑拿后的冷却阶段提升了副交感神经张力，延续至睡眠期，符合热应激生理学文献。- 性别差异：女性夜间心率效应仅在黄体期达到d > 0.2阈值，卵泡期无明显效应。此结果出乎意料，值得复现验证。

无法控制的因素：- 桑拿类型（干桑拿/远红外/蒸汽）、时长、温度数据缺失。- 剂量反应关系未知，缺少每次时长信息。- 桑拿时间与睡眠的相对先后关系。- 反向因果：可能用户在感觉恢复时才进行桑拿。- 选择偏差：能坚持记录桑拿的可穿戴设备用户本身较为注重健康。

令人惊讶的是：该效应大于用户同等强度锻炼日的夜间心率变化。如果把夜间心率看做副交感恢复信号，桑拿比中等强度锻炼更有效。这不是我之前所预料的。

Vercel April 2026 security incident #

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

When one OAuth token can compromise dev tools, CI pipeline, secrets and deployment simultaneously, something architectural has gone wrong. Vercel have had React2Shell (CVSS 10), the middleware bypass (CVSS 9.1), and now this, all within 12 months.

At what point do we start asking questions about the concentration of trust in the web ecosystem?

It’s funny that at the engineering level we are continuously grilled in interviews about the single responsibility principle, meanwhile the industry’s business model is to undermine the entirety of web standards and consolidate the web stack into a CLI.

Vates

当一个OAuth令牌能够同时危及开发工具、CI流水线、机密信息和部署时，说明某个架构设计出了问题。Vercel在12个月内先后出现了React2Shell（CVSS 10）、中间件绕过（CVSS 9.1），以及现在的这个漏洞。

我们何时才开始质疑网络生态系统中信任的集中度？

有趣的是，在面试时工程师们不断被追问单一职责原则，而与此同时，整个行业的商业模式却是在破坏整个网络标准，将网络堆栈整合到一个命令行界面中。

John Ternus to become Apple CEO #

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

Wow. Hopefully, Ternus will bring what he brought to Apple’s hardware to their software. The hardware is leaps and bounds ahead of anything else, but their software gets worse and worse every generation. I’m glad to hear this.

oofbaroomf

哇。希望Ternus能把他带给苹果硬件的那种水平也带到他们的软件上。硬件远远领先于其他任何产品，但他们的软件每一代都变得越来越糟。我很高兴听到这个消息。

Stop trying to engineer your way out of listening … #

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

I tend to be very exacting in my word choice. If I used a specific word, I meant it. Many people I find speak in what I would describe as tone poems. They circle around an idea using whatever word is within reach, and expect you to understand the meaning based on shared connotations. These people are tiring to interpret. When I write something, each and every word was chosen specifically and with intention.

The number of times I see my words interpreted as though my choice in words had been imprecise is a near constant source of pain, particularly in the workspace. I might be on the spectrum, I am undiagnosed.

About six months ago I was tasked with building a little RPC for a different division to be able to kick off a long running process and documenting it for them. The documentation was complete, correct, and relatively terse. Less than a page.

I sent my manager the documentation to pass on, and for reasons I will never understand he passed it through AI before handing it over to the other department. No one informed me.

Within a day I start getting feedback that makes zero sense. Seemingly no one can get the RPC to work. I had tested this extensively, the complaints made zero sense. One of the complaints includes the actual request being made and the endpoint is entirely wrong. Not a single character typo, a complete fabrication. I ask where this came from and they point me to the documentation they were sent. Every single thing was wrong. The endpoints were wrong, the required parameters were wrong, there were invented features that do not exist. I am a very easy going guy, and I have genuinely never been so furious in my entire life. I am still angry as I write this. If the job market were not what it is I would have quit there and then.

I feel like people using AI to both read and interpret language is the death of rigorous language. I have genuinely been pondering for months if generative AI is the “Great Filter” preventing space faring civilizations from flourishing. Around the same time a civilization begins to enter space they invent a device that destroys their minds.

donatj

我在用词上一向非常讲究。如果我用了某个特定的词，那就是有意为之。我发现很多人说话更像是在讲“语气诗”，他们围绕一个想法，随手抓个词就用，指望你能基于共同的语义理解他们的意思。这种人真让人费劲去理解。当我写东西时，每个词都是经过仔细挑选的，有明确的意图。

我看到别人把我的话解读成我用词不准确的情况几乎屡见不鲜，这在工作场合特别痛苦。我可能有自闭谱系障碍，但尚未确诊。

大约半年前，我被指派为另一个部门开发一个小的RPC，用来启动一个长时间运行的流程，并为他们完成文档工作。文档内容完整、正确，并且相对简洁，不到一页。

我把文档发给我的经理，让他转交，但我永远不懂为什么他在转交前用了AI处理过文档，而且没有人告诉我。

一天之内，我开始收到一些完全不合常理的反馈。看似没人能让RPC正常工作。我已经做了充分测试，抱怨完全没道理。其中一个抱怨甚至附上了请求，但请求地址完全错了，不是单个字符拼写错误，而是完全捏造的。我问这到底是从哪里来的，他们指给我看他们收到的文档。那上面所有内容都是错的。接口地址错，所需参数错，还有一些根本不存在的功能。我是个很随和的人，但那是我人生中第一次真正生气到极点。写这段话时我仍旧很愤怒。如果当时就业环境不是这样，我肯定当场辞职。

我觉得人们用AI来读取和解读语言，是严谨语言的终结。我真心思考了好几个月，生成式AI是不是阻止文明成为星际文明的“伟大过滤器”。一个文明刚要迈入空间时代，就发明了一种摧毁他们思维的设备。

GitHub’s fake star economy #

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

Can anyone explain why on earth VC’s are making actual investment decisions based on imaginary internet points ? This would be like an NFL team drafting a quarterback based on how many instagram followers they have rather than a relevant metric like pass completion, or god forbid, doing some work and actually scouting candidates. Maybe the Cleveland Browns would do that[0], but it’s not a way to mount a serious Super Bowl campaign[1].

Are VC’s just that lazy about making investment decisions? Is this yet another side-effect of ZIRP[2] and too much money chasing a return? Is nobody looking too hard in the hope of catching the next rocket to the moon?

From the outside, investing based on GitHub stars seems insane. Like, this can’t be a serious way of investing money. If you told me you were going to invest my money based on GitHub stars, I’d laugh, and then we’d have an awkward silence while I realize there isn’t a punchline coming.

[0] I’m from Cleveland. I get to pick on them.

[1] https://en.wikipedia.org/wiki/List_of_Cleveland_Browns_seasons I think their record speaks for itself.

[2] https://en.wikipedia.org/wiki/Zero_interest-rate_policy

mauvehaus

有人能解释一下，风险投资人为什么要根据虚构的网络积分做出实际的投资决策吗？这就好比一支NFL球队根据四分卫的Instagram粉丝数量来选人，而不是根据传球成功率这样的相关指标，或者说，天啊，认真做点功课，实地考察一下候选人。也许克利夫兰布朗队会这么干，但这可不是打算认真争夺超级碗的正确方式。

风险投资人真的在投资决策上懒到这种程度了吗？这又是不是零利率政策和过多资金追逐回报的另一个副作用？难道没人愿意下点功夫，仔细寻找下一个飞向月球的火箭吗？

从外部来看，基于GitHub star数来投资简直疯狂。换句话说，这不可能是个严肃的投资方式。如果你告诉我要根据GitHub star来投我的钱，我会笑，然后尴尬地沉默，因为我知道后面不会有什么笑点了。

我来自克利夫兰，这样吐槽他们没关系。

说实话，克利夫兰布朗队的战绩已经说明了一切。

Vercel April 2026 security incident #

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

Claude Code defaulting to a certain set of recommended providers[0] and frameworks is making the web more homogenous and that lack of diversity is increasing the blast radius of incidents

[0] https://amplifying.ai/research/claude-code-picks/report

nikcub

Claude Code 默认使用某一组推荐的提供商[0]和框架，使网络变得更加同质化，而这缺乏多样性正增加事件的影响范围。

[0] https://amplifying.ai/research/claude-code-picks/report

M 7.4 earthquake – 100 km ENE of Miyako, Japan #

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

Felt it all the way in Tokyo!

There is this amazing app called NERV that, whenever there is a large earthquake anywhere in Japan, sends you an early warning push notification and an animated display with shockwaves emanating from the epicenter, plus a countdown timer for the first wave hitting you. The first it went off for me it felt like something out of sci-fi. I think I got 45 seconds this time before my apartment started shaking.

https://nerv.app/en/

piazz

在东京也能明显感觉到震动！

有一个很棒的应用叫NERV，每当日本任何地方发生大地震时，它都会推送预警通知，并显示一个动画，显示震中发出的冲击波，还有一个倒计时，告诉你第一波地震波什么时候会到达你那里。第一次收到这个预警时，感觉像科幻片里的场景。这次我大约有45秒的时间，才开始感觉到公寓在摇晃。

https://nerv.app/en/

The RAM shortage could last years #

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

Ok so Samsung, SK Hynix and Micron do not have the capacity to meet demand. Also, what little capacity they do have they are allocating to HBM over DRAM. Based on my limited knowledge HBM can not be easily repurposed for consumer electronics. Translation: main street is cooked for the next 3-4 years.

It doesn’t stop there though. OpenAI is currently mired in a capital crunch. Their last round just about sucked all the dry powder out of the private markets. Folks are now starting to ask difficult questions about their burn rate and revenue. It is increasingly looking like they might not commit to the purchase order they made which kick-started this whole panic over RAM.

Soo … how sure are we that the memory makers themselves are not going to be the ones holding the bag?

stuxnet79

好吧，三星、SK海力士和美光的产能无法满足需求。而且，他们有限的产能主要被分配到HBM而非DRAM。根据我有限的了解，HBM不容易被重新用于消费电子产品。换句话说，未来三到四年普通消费者市场会很糟糕。

但情况不仅如此。OpenAI目前正陷入资金短缺困境。他们上一轮融资几乎耗尽了私募市场的流动资金。现在大家开始质疑他们的烧钱速度和收入情况。越来越多迹象表明，他们可能不会履行启动这场RAM恐慌的采购订单。

所以……我们有多大把握认为，最终亏损的不会是内存生产商自己？

John Ternus to become Apple CEO #

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

Their software is better than most (if not all) of closed-source universe. That’s true, but the problem is, they were better in the past.

I’m using both Linux and macOS close to 20 years (Linux is even more than 20, IIRC), and macOS (aka Mac OS) used to be snappier, more stable, more uniform and had incredibly low number of papercuts around the UI. Now it has some nasty thorns here and there, while Linux is improving steadily and not regressing much as macOS.

Apple needs to overhaul their software stack. They can use a lot of sanding and polishing to bring the shine back. They need another “Snow Leopard” release, as many people say.

On the other hand, even with all these bells and whistles, they can’t even get close to the composability of Linux systems. Doing so will also damage their bottom line, so they won’t, and that’s OK.

bayindirh

他们的软件比大多数（如果不是全部的话）闭源系统都要好。这是事实，但问题是，他们过去确实更优秀。

我用了快20年的Linux和macOS（Linux甚至超过20年了，如果没记错的话），以前macOS（也就是Mac OS）反应更快、更稳定、更统一，界面上的小问题也极少。现在它这里那里都出现了一些讨厌的瑕疵，而Linux则稳步提升，没有像macOS那样倒退。

苹果需要彻底重构他们的软件架构。他们的软件需要大量打磨和抛光，才能重新焕发光彩。正如很多人所说，他们需要像“雪豹（Snow Leopard）”那样的版本更新。

另一方面，即便有这么多花哨功能，他们也远远比不上Linux系统的模块化和可组合性。要做到这一点，也会损害他们的底线，所以他们不会去做，这也没问题。

Changes in the system prompt between Claude Opus 4… #

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

The new <acting_vs_clarifying> section includes: When a request leaves minor details unspecified, the person typically wants Claude to make a reasonable attempt now, not to be interviewed first.

Uff, I’ve tried stuff like these in my prompts, and the results are never good, I much prefer the agent to prompt me upfront to resolve that before it “attempts” whatever it wants, kind of surprised to see that they added that

embedding-shape

新的<acting_vs_clarifying>部分包括：当请求中未具体说明一些细节时，用户通常希望Claude现在做出合理的尝试，而不是先进行提问。

唉，我在我的提示中尝试过类似的东西，结果从来不好，我更喜欢代理先向我提问以解决问题，然后再“尝试”它想做的事情，有点惊讶居然他们加了这个。

NSA is using Anthropic’s Mythos despite blacklist #

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

The pace at which we sprint toward a full blown surveillance state, with unaccountable oracles sentencing us for pre-crime, is alarming to say the least.

goolz

我们以惊人的速度奔向一个全面的监控国家，那里无可追责的预言者会因为“预犯罪”而判决我们，这至少是令人担忧的。

Stop trying to engineer your way out of listening … #

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

Even here in the comments you see people who have read this article and fall victim to the very things it’s pointing out. It’s ironic.

Let me add a couple to this list.

No amount of knowledge or discussion will make a person accept something they don’t want to accept.
To truly listen means to place yourself mentally and physically in a vulnerable state. Because you will likely hear things that run contrary to your experience, beliefs, and worldview. Judging people is often a self protection mechanism; which means you will almost never listen to someone.
Listening often means not jumping to a solution; but absorbing and processing someone’s pain. Product managers for example are quick to jump to a solution, a new feature, or they’ll push the request off as “oh, ok, we’ll make a ticket for that ”

When in actuality, they should be listening to the use case, looking for the pain, and finding a way to solve the pain points. As opposed to trying to understand what feature the user wants to request.

digi59404

即使在评论区，你也会看到一些看过这篇文章的人，却成了文章所指出的问题的受害者，这真是讽刺。

让我再补充几点。

无论多少知识或讨论，都无法让一个人接受他不愿意接受的东西。
真正倾听意味着在心理和身体上处于脆弱状态。因为你很可能会听到与你的经历、信仰和世界观相悖的内容。评判别人往往是一种自我保护机制；这意味着你几乎不会真正听别人说话。
倾听往往意味着不要急于给出解决方案，而是去吸收和理解别人的痛苦。比如产品经理们常常急于提出解决方案、新功能，或者会把请求简单地归结为“哦，好，我们会为此创建一个工作单”。

而实际上，他们应该专注于倾听使用场景，寻找痛点，找到解决痛点的方法，而不是简单地理解用户想要请求什么功能。

OpenClaw isn’t fooling me. I remember MS-DOS #

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

Is anyone finding value in these things other than VCs and thought leaders looking for clicks and “picks and shovels” folks? I just personally have zero interest in letting an AI into my comms and see no value there whatsoever. Probably negative.

piker

除了风险投资者和那些寻找点击量以及“铲子和镐子”模式的人之外，有谁觉得这些东西有价值吗？我个人对让人工智能介入我的交流完全没有兴趣，根本看不出任何价值。可能反而有害。

Tesla concealed fatal accidents to continue testin… #

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

Teslas turning off autopilot seconds before a crash, apparently avoiding being recorded as active during an incident, is wild https://futurism.com/tesla-nhtsa-autopilot-report

jasoncartwright

特斯拉在碰撞发生前几秒关闭自动驾驶，显然是为了避免在事故发生时被记录为处于激活状态，这真是令人震惊。 https://futurism.com/tesla-nhtsa-autopilot-report

We got 207 tok/s with Qwen3.5-27B on an RTX 3090 #

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

This is a Claude-code generated repo that implements some ideas from research papers. If you follow this space, every paper release spawns tens or hundreds of vibecoded repos like this that get spammed to Reddit, Hacker News, and other sites.

It’s generally best to overlook the vibecoded repos and go closer to the source for up to date information. In this case, z-lab already showed Qwen3.5-27B with DFlash last month: https://huggingface.co/z-lab/Qwen3.5-27B-DFlash

This repo is an example of what you get if you point Claude Code at the upstream repo and have it iterate with some other objective (loading GGUF). They also included DDTree in there somewhere.

You also need to look closely at the claims. A classic trick in these repos is to cherry-pick numbers that make the work in the repo look extraordinary until you start reading the details. From my quick read, this repo is using Q4 quantization on the KV cache which does not produce good results. Someone who reads everything in detail might find more tricks. This is par for all of these demo repos because the goal is to impress casual viewers with big numbers.

I’m trying to find where they get the 207 tok/s number but the 207 number only appears in their headline claim. If you read deeper the real numbers are half that or less.

There are also several (possibly vibecoded, I haven’t checked) draft PRs and forks to use these techniques on upstream llama.cpp that would be much more useful for experimenting. One example I picked at random: https://github.com/ggml-org/llama.cpp/pull/22105

Aurornis

这是一个由Claude-code生成的仓库，实现了一些研究论文中的想法。如果你关注这个领域，每次论文发布时，都会有几十甚至上百个类似的vibecode仓库被大量发布到Reddit、Hacker News和其他网站。

通常最好忽略这些vibecode仓库，直接去源头获取最新信息。在这个案例中，z-lab上个月已经展示了带有DFlash的Qwen3.5-27B：https://huggingface.co/z-lab/Qwen3.5-27B-DFlash

这个仓库就是将Claude Code指向上游仓库，并用其他目标（加载GGUF）进行迭代的一个例子。他们还在某处加入了DDTree。

你还需要仔细看这些声明。这类仓库常见的做法是选择性地突出一些数据，让仓库的工作看起来很厉害，直到你开始阅读细节才发现问题。根据我快速浏览，这个仓库对KV缓存使用了Q4量化，结果并不好。细读所有内容的人可能会发现更多花招。这类演示仓库普遍存在这种现象，因为他们的目的是用大数字给普通观众留下深刻印象。

我一直想找到他们所谓的207 tok/s的来源，但207这个数字只出现在他们的标题声明中。深入看，实际数字大约只有一半甚至更少。

此外，还有几个（可能也是vibecode的，我没仔细查看过）针对上游llama.cpp使用这些技术的草稿PR和分支，这些会更适合实验。例如，我随机找了一个：https://github.com/ggml-org/llama.cpp/pull/22105

Deezer says 44% of songs uploaded to its platform … #

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

You’re not wasting your time, my friend. But you’ve got to be very certain and honest as to why you want to learn that.

If your goal is being heard and appreciated, well, you better reconsider.

If you’re doing it for your own pleasure and pure love of art, absolutely do go on, without any expectations. It may or may not take off, but the samurai must not care.

wartywhoa23

朋友，你没有浪费时间。但你必须非常确定并诚实地回答自己为什么要学习这个。

如果你的目标是被听见和被欣赏，那你最好三思而后行。

如果你是出于自己的快乐和对艺术的纯粹热爱，绝对应该继续下去，别抱任何期望。它可能会成功，也可能不会，但武士不应在意这些。

Atlassian enables default data collection to train… #

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

Atlassian just goes from misstep to misstep. I still use their products quite often. The amount of P0 bugs I experience is absolutely crazy:

Bitbucket workers are hopelessly out of date (self hosted). We’ve had to put so many random workarounds in especially for Docker, as they don’t keep them up to date enough
I have had a bug in JIRA for years where I can’t reorder a new ticket unless I refresh the page
Every new feature they introduce into JIRA/Bitbucket over the past couple of years just doesn’t work.
I tried their AI stuff on the free trial, didn’t work at all, tried to cancel, can’t cancel the free trial online and had to write a load of support tickets (of which the support ticket contact form bugged out multiple times).

Anyone have any insight into why things have got so so dysfunctional? Tech debt? Talent leaving? Both? Even ‘bad’ enterprise software tends to be able to keep the most basic features running, but Atlassian is a whole new category. If you check their ‘community’ it is just hundreds/thousands of bugs with workarounds.

martinald

Atlassian 简直是一错再错。我现在还经常用他们的产品，但遇到的P0级别的bug数量简直疯狂：

Bitbucket的worker版本严重过时（自托管版）。我们不得不为Docker特别准备了许多随机的解决方案，因为他们根本不及时更新这些worker。
JIRA 有一个多年存在的bug，新建的工单无法重新排序，除非刷新页面。
过去几年他们在JIRA和Bitbucket上推出的每一个新功能都完全不管用。
我试用过他们的AI功能免费体验版，一点作用都没有，想取消免费试用，结果线上无法取消，不得不写了大量的支持工单（而且支持工单的联系表单还多次出现故障）。

有没有人知道为什么他们的系统变得这么混乱？技术债务？人才流失？还是两者都有？即使是“差劲”的企业软件，最基本的功能通常还能保持正常运行，但Atlassian完全是另一个档次。如果你去看看他们的“社区”，满是成百上千带着解决方案的bug贴。