1. Claude重建ECDSA曲线种子的生成来源 (Claude reveals ECDSA curve origins)
Anthropic报告称，内部研究版Claude在不到半小时内追溯了P-256等标准椭圆曲线的种子来源。ECDSA数字签名依赖约定的曲线参数，其中部分系数由公开种子计算而来；这些种子当年由美国国家安全局提供，却未说明如何选择，长期引发是否藏有后门的疑问。Claude没有沿用“幽默短语经哈希生成”的旧线索，而是识别出旧版C语言库伪随机生成器lrand48的输出特征，再恢复状态，发现它以时钟的Unix时间戳初始化。团队给出代码，可重现多条曲线的公开种子。恢复来源不等于破解ECDSA，也没有发现新的签名攻击；作者认为，这减少了人为挑选弱曲线的可能性。但调查尚未解释全部选择过程：部分可用候选被跳过，筛选标准未知，B-163种子及多条曲线的基点来源仍未解开。这里的基点是生成公钥所用的固定曲线点，与种子不同。因此，这项工作补上了参数来历的一段历史，并非获得用户私钥，也不是证明所有历史选择都已透明。
原文链接：https://www.anthropic.com/research/ecdsa-curve-origins
论坛讨论链接：https://news.ycombinator.com/item?id=50122800
评论者的争论集中在“知道怎样生成”是否等于“知道为何选中”。fidotron指出，生成跨越数月，而且看不到全部丢弃的候选，仍不能排除设计者尝试不同时间戳来筛选。FiloSottile回应，即使假设遍历1997年的时间戳，并从各次运行的前16个可用候选中挑选，选择空间也只有约30比特；若这种规模就能撞上弱曲线，意味着弱曲线非常普遍，本身将是重大的密码分析突破。另有回复解释，候选编号较大不代表刻意寻找特殊性质，多数候选根本不能生成合用曲线。双方讨论的是参数选择留下多少自由度，并未声称签名已被攻破。
2. Roadster新配置：冷气推进器与单座飞行版 (Tesla Roadster)
特斯拉更新了 Roadster 产品页，展示基础车型及两种增强配置，并强调主动空气动力装置、车底抽气和冷气推进器。基础 Performance 为双座，接受预约；限量提供的 Thrust 同样为双座，在车尾增加冷气推进器，用来辅助向前加速。仅限邀请的 Rocket 则改为单座，把推进器布置在车身周围，支持向前、向上加速及横向旋转。特斯拉据此宣称它能够飞行，但页面明确注明，这一配置未获准在公共道路使用，且并非所有地区都提供。冷气推进器依靠气体喷出产生推力，并不等于装上燃烧式火箭发动机。另一项核心设计是风扇与车底密封系统：抽走车底空气，在车辆静止时也能产生下压力，帮助轮胎保持抓地力；主动翼面则配合不同赛道模式调整。页面还介绍了线控转向、固定座椅，以及镁、钛和碳纤维等轻质材料。上述能力来自厂商产品说明，不能当作独立道路测试结果；网页提供预约入口，也不能据此认定这些配置已经批量交付。
原文链接：https://www.tesla.com/roadster
论坛讨论链接：https://news.ycombinator.com/item?id=50112657
HN 的分歧在于，这种设计是值得欣赏的工程尝试，还是实用性有限的展示。最初一位评论者赞叹风扇和推进器集成到跑车中，却把飞行版误说成采用燃烧发动机；回复者纠正，两种增强配置都用冷气推进器，区别主要在数量与位置。随后有人根据储气量、质量和喷气速度自行估算可维持的悬浮时间，但这不是官方参数齐全的试验报告。批评者认为，短暂离地与能作为个人飞行器使用相差很远，也关注高压储气装置在碰撞中的风险。另有人指出飞行配置不能上公共道路。讨论没有因此证实量产可行性或实际飞行时长。
3. 苹果用四台Mac运行Muse Spark Open模型 (Apple ML Research: Muse Spark Open with MLX on Mac Studio)
苹果展示，借助MLX框架与低延迟互联，四台配备M5 Ultra芯片的Mac Studio可以在本地运行Muse Spark Open。该模型总计8160亿参数，每次推理激活约420亿；即使压缩为四比特格式，仅模型本身仍占约493GB内存，加上计算过程所需空间，无法装进单台512GB机器。团队用雷雳5线缆进行远程内存访问，在机器间交换数据，并比较两种拆分方式：流水线并行让不同机器依次处理不同层，张量并行则把同一层的计算分给多台机器，同时也增加通信。在8192个词元的上下文下，四机张量并行生成速度超过每秒36个词元；词元是模型处理文本的基本单位，这一速度不等于发出请求后的等待时间。上下文增至65536个词元时，四机采用每对机器两根线缆的配置，首个输出需约40.6秒，比单线连接的50.5秒缩短。报道同时展示了将本地服务接入编程助手的方法，重点在桌面环境的私有推理，并未测试训练这类大模型的能力。
原文链接：https://machinelearning.apple.com/research/mlx-distributed-inference
论坛讨论链接：https://news.ycombinator.com/item?id=50118320
HN首先讨论谁能从开放权重模型获利：有人认为模型开发商承担巨额训练成本，苹果则靠销售本地运行所需的硬件受益，并把这比作“卖铲子”。也有人追问苹果为何还要自行开发模型，回复举出照片筛选等本地功能，称不必把家庭照片交给前沿模型服务商也有实际价值。随后讨论出现分歧：有人质疑照片云服务的隐私保证，另有人报告本地模型会不稳定地拒绝描述部分照片，还有用户抱怨后台AI进程拖慢应用并增加发热。这些都是评论者的体验或判断，不能据此认定所有照片都会上传，或把个别机器的性能问题归因于本文的MLX配置。
4. AI基准覆盖了多少工作？研究估算九成工时仍是盲区 (90% of US working hours are spent on tasks not covered well by AI benchmarks)
Mercor 把二十九套 AI 基准测试映射到美国职业任务分类，估算约九成劳动工时对应的任务，在这份基准清单中缺少或几乎没有覆盖。这个数字描述的是测量盲区，不能解释为 AI 无法完成九成工作。研究涉及九百二十三种职业、一万八千七百九十七项任务，其中只有二百零八种职业，至少有一项任务被五道测试题覆盖。
团队用大模型判断测试题对应哪些工作任务，再结合另一项研究中由大模型估算的任务工时占比，计算经济活动的覆盖程度。律师等职业的测试较多，同样容易受到 AI 影响的法律秘书和法院文员却很少进入题库。作者认为，只看热门榜单，很难判断模型在日常工作中的真实能力。研究也承认，这二十九套基准既不完整，也不完全具有代表性；按职业类别限制基准数量、排除已经接近满分的测试，可能进一步压低覆盖估计。因此，结果属于初步画像，不能当作整个基准生态的精确普查；如何衡量 AI 对人类工作的辅助作用，也仍是未解决的问题。
原文链接：https://www.mercor.com/research/labor-index/benchmark-map/
论坛讨论链接：https://news.ycombinator.com/item?id=50121179
HN 评论从“门卫谬误”谈起：自动门替代了开门动作，却可能遗漏门卫承担的接待等职责。一位评论者用团队经验说明，产出本身未必是瓶颈：AI 能更快做出初稿，但评审、反馈和签字仍要反复数日；没人熟悉生成过程时，精确修改反而更困难。他认为，少审批的小团队可能更容易获益。回复者进一步区分成熟企业与成长企业：前者更担心变化带来的风险，后者可能借更低的试错成本探索新产品。也有人怀疑，收益没有供应商宣传得那么大，而技术采用本来就需要时间。这些观点是在讨论工作流程中的瓶颈，并不是九成任务无法自动化的证据。
5. UTC将于2027年5月20日起停止闰秒调整 (BIPM decides to stop adding leap seconds to UTC)
国际计量大会二〇二六年第五号决议规定，从二〇二七年五月二十日起，协调世界时 UTC 将采用连续运行方式，停止通过闰秒增减来追随地球自转。UTC 是多数国家民用时间的基础；描述地球自转的时间尺度叫 UT1，两者未来允许逐步拉开差距。决议把差值上限设为三千六百秒，即一小时，以维持数世纪的连续计时，这并不意味着生效当天把时钟拨动一小时。
二〇二二年的决议已经决定，不迟于二〇三五年扩大允许差值；此次决议给出了更早的明确实施日期。文件指出，交通、能源、电信及空间项目依赖连续同步，闰秒会增加系统故障风险，各家不同的平滑处理办法也会造成计时不一致。它尤其担心尚未实际使用过的负闰秒，也就是删去一秒：许多关键系统没有准备好处理这种情况。需要地球自转时间的用户，仍可从卫星导航信息或相关机构服务取得 UT1 与 UTC 的差值。国际计量局将继续监测其变化；文件并未宣布触及一小时上限时一定采用何种调整办法。
原文链接：https://www.bipm.org/en/cgpm-2026/resolution-5
论坛讨论链接：https://news.ycombinator.com/item?id=50105777
HN 评论在工程便利与时间定义之间展开争论。支持者认为，闰秒会让时间戳重复、日期解析器遇到非常规秒数，也让两个未来日期之间的精确秒数难以预先确定；取消调整能减少长期埋伏的软件问题。一位反对者则觉得，不能妥善处理偶尔增减一秒是技术上的退让：既然已有国际原子时，何不让需要连续计时的系统改用它，而保留原有 UTC？他还担心旧代码依然必须处理历史闰秒，新旧规则并存未必更简单。回复者反驳，固定每分钟六十秒，比要求程序另查公告、判断一分钟究竟有五十九还是六十一秒容易理解。
6. Meta 商用条款中的网站抓取授权引发质疑 (Meta’s new commercial terms will allow the scraping of news sites: experts)
据 Nieman Lab 报道，Meta 将于 10 月 30 日实施的新商用条款，把自动抓取与商业账户关联网站的授权纳入协议；新闻机构等商业用户若继续使用，便须接受条款，否则应停止相关使用。授权范围包括访问、索引、缓存和收集网页内容，并允许将其用于产品开发与训练。受访法律专家认为，这可能被用来主张抓取新闻网站并训练 AI 的权利，但法院是否会执行这种约定仍不确定。Meta 回应称，抓取表述此前分散在不同条款中，此次只是集中整理，不会改变未来抓取方式，内容所有者仍可用 robots.txt 文件管理爬虫访问。法律专家则担心，Meta 可能援引商业协议，主张其优先于网站的阻挡指令。新条款还允许创建测试账户；学者认为这可能让爬虫越过注册门槛，Meta 没有回答是否涉及付费墙。报道强调，把抓取内容用于 AI 训练仍牵涉尚未解决的版权与合理使用问题，并非一纸条款就已有法律定论。
论坛讨论链接：https://news.ycombinator.com/item?id=50111852
HN 讨论追问：商业账户持有人未必拥有网站全部内容的版权，又凭什么向 Meta 授权？首位评论者指出，出版商常向第三方取得有限使用许可，这不一定包括再次授权抓取和训练的权利。有回复认为，出版商可能夹在平台条款和原有许可协议之间，接受新协议后反而面临违约风险，因此可能需要退出、移除第三方内容或重新谈判。也有人担心平台把责任推给出版商，但另一位回复反驳，账户持有人没有的权利不会凭合同产生，Meta 本身仍可能承担侵权责任。这些是评论者对合同关系的分析，尚不能当作法院对具体责任的裁定。
7. OpenBSD本地提权链涉及37年前BSD遗留错误 (Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD)
安全公司Calif披露OpenBSD一条本地提权攻击链，其中的共享内存计数错误可追溯到约37年前的BSD代码。攻击者需要先有在本机运行代码的能力，才能利用它取得最高的root权限，不能将其理解为直接从网络接管系统。问题起于一个有符号16位计数器：共享内存关联次数越过32767后会变成负值，配合进程执行时序上的竞争，可导致程序继续使用已经释放的内存。研究人员再结合另一个内核越界写错误，最终执行内核代码。他们称，演示时内核地址重排和阻止用户态、内核态错误访问的硬件防护均已启用，也没有依赖额外的信息泄露漏洞；但部分早期内存分配位置仍可预测，给了攻击链落点。这两项漏洞已分别通过OpenBSD勘误026和018修复。文章提出的后续防护包括，在移除链表元素前检查连接关系、扩大内存地址及分配顺序的随机性，以及用编译器边界检查和分配隔离减少可利用空间。这些是额外加固建议，不应与已经落地的漏洞修复混为一谈。
原文链接：https://calif.io/research/big-fish
论坛讨论链接：https://news.ycombinator.com/item?id=50118977
HN讨论的一条主线是复杂漏洞该如何解释。有人把利用代码比作游戏速通技巧，认为注释虽多，仍充满难懂的内核术语；回复则认为代码已有足够文档，不可能在每条注释里重讲所有子系统，读者需要结合OpenBSD自身文档理解。另一条主线是人工审计的边界：有评论者惊讶，错误能在重视审计的代码库中存留数十年，并询问模糊测试或静态分析是否能找到这一类问题。随后有人将该站研究概括为AI生成和AI发现，另一人反驳说本文看起来是人工写作。这段争论没有给出可核实的发现过程，不能把漏洞归功于AI独立发现。
8. Gemini 4 Argon 编写星际对战机器人 (Show HN: Gemini 4 Argon plays StarCraft)
StarSkirmish v0.2 用《星际争霸：母巢之战》测试语言模型的持续编程与迭代能力。模型不是看画面即时操作，而是从只会采矿的骨架代码出发，在一小时内编写 C++ 神族对战程序，通过编译、练习赛和日志改进代码，时间结束后再统一对战评分。每个模型独立运行五次，每个最终程序在三张地图上，与十个由人编写的竞技机器人及三个演示机器人交手，分数是平均胜率。各模型使用自家命令行工具和可用的最高推理设置，不能搜索网页或访问互联网。Gemini 4 Argon 位列第三，但它与两款 Claude 的成绩都在 37—39 分之间，作者认为基本持平；它最好与最差一次的差距为 18 分，波动较大。榜首 GPT-6 Astra 对三个最强人工编写的机器人也只有 7% 胜率，且测试仅限神族内战和三张双人地图，实际机器人赛事条件更难。作者观察到，多与强敌练习的模型往往得分更高，但这种关联尚不能直接说明因果。
原文链接：https://starskirmish.com/bench/v0-2/
论坛讨论链接：https://news.ycombinator.com/item?id=50118688
HN 评论关心，这项成绩究竟测到了编程、实验设计，还是更广泛的推理能力。有人发现另一项围棋测试的模型排序与此一致，认为值得比较不同基准；也有人据此联想到通用能力，但原评论者提醒，自己仍见到强模型作出欠缺判断力的假设，不愿把排名相关直接等同于全面进步。另一位用户希望分清改进代码和安排更好实验各有多少贡献，并测试机器人在未见地图及对手上的表现。还有人追问，模型是否形成新策略、是否可能见过人工机器人的代码，以及一小时时限会怎样影响结果。这些问题在所摘录的评论中尚未得到验证。
9. 用快电脑重玩老游戏：软件渲染的独特画面 (I love software rendering)
James Mackenzie 在戴尔 OptiPlex 380 上，用原版 DOS《雷神之锤》的软件渲染模式，以 800×600 分辨率稳定运行到每秒 60 帧。这让他重新欣赏一种老游戏画面：由 CPU 计算并绘制像素，而不是交给三维显卡加速。作者喜欢纹理清晰的方块感，以及许多旧游戏在 256 色调色板下、用查找表处理明暗形成的阶梯状阴影；他觉得早期显卡的双线性过滤虽然能平滑纹理，也会让画面变糊。如今更快的电脑能把这类原始风格推到当年难以流畅使用的高分辨率，但软件渲染的负担仍随像素数增加，一些 Build 引擎游戏即使用较快处理器也会吃力。作者没有把偏好当成通则：《血祭》的软件模式更合他意，《古墓丽影》的水下部分却是加速版更好看。他追求的是在真实硬件上运行最初发行的 DOS 版本；现代移植版和模拟器仍是其他选择，而高速电脑原生运行 DOS 时，还需要解决游戏能识别的声卡问题。
原文链接：https://www.jamesfmackenzie.com/2026/10/13/i-love-software-rendering/
论坛讨论链接：https://news.ycombinator.com/item?id=50117746
HN 讨论由一位用户的回忆展开：当年装上声卡，游戏反而多了每秒十帧。回复者把可能原因解释为卸载处理负担：早期电脑要由同一颗较慢的处理器同时处理声音、图形、网络和磁盘访问，带独立处理能力的扩展卡可以让更多计算时间用于游戏。有人特别提到把多路音频混合交给声卡，也有人回忆，可把声音样本装入板载内存的声卡曾令人惊叹。另一位用户则说，自己在奔腾电脑上听 MP3，几乎就无法同时操作其他程序。这些评论用个人经历说明当年的资源争夺，开头的十帧提升并不是附有配置和测量方法的通用性能结论。
10. 救下一只受伤乌鸦后，她陆续收到鸟儿留下的物件 (Woman who rescued injured crow keeps getting ‘thank-you gifts’ from birds [video])
CTV 的这段视频讲述了 Lia Wilson 救助一只受伤乌鸦后，与附近鸟群持续接触的经历。当时，许多乌鸦在一栋房子周围盘旋俯冲，她得知其中一只困在屋檐排水槽里，而现场没有足够长的梯子。她跑去向附近的消防员求助，消防员把鸟救下后，她又开车将它送往野生动物康复中心。她回忆，途中乌鸦抓住自己的手指不放，让她感到非常触动。
几天后，她得知这只鸟已经放归；随后一次遛狗时，一只乌鸦飞下来，把一束羽毛落在她脚边。她把这理解为一份感谢的礼物，并说此后还有乌鸦陆续留下其他物件。现在她每天遛狗，常有多只乌鸦跟随，其中包括那只获救的鸟：她凭康复后佩戴的腿环认出它。身为梅蒂人的她，将这段关系与自己从小重视自然世界的成长经验联系起来。报道呈现的是救援过程和当事人的讲述；“感谢”是她对鸟儿行为的解释，字幕没有提供能够确定这些物件用途或乌鸦动机的实验依据。
原文链接：https://www.youtube.com/watch?v=sjNpfz4UzqU
论坛讨论链接：https://news.ycombinator.com/item?id=50065859
HN 评论主要在交流人与乌鸦长期互动的观察。一位评论者说，父亲与一只乌鸦维持了十多年的喂食仪式：鸟看见他在厨房，就站到固定位置等待；后来一只喜鹊也学会用盘旋和停在特定树枝上吸引注意。他还描述，乌鸦会把面包边拖进水碗，弄湿后切开，方便平衡衔走，接班的喜鹊也尝试类似做法。另一人说，母亲照顾的一只跛脚乌鸦敢敲窗索食，其他鸟却只在围栏上等剩余食物。回复者由此谈到，受伤动物是否更愿接近人类。这些都是评论者的个人观察与猜测，讨论没有据此证明报道中的鸟是在表达感激。