2026年06月13日 · 星期六 第 160046 期

The Hacker Daily

丙午年(马)四月廿八

30 篇文章 · 3690 条评论 ·聚焦:AI安全漏洞 · 开源AI运动 · 政府AI监管
No.01 Shepherd's Dog: A Game by the Most Dangerous AI Model
牧羊犬游戏:Anthropic「危险」AI模型的一次游戏开发测试
45 分 31 条评论 作者: vnglst
作者用Anthropic发布的那款「据说太危险不让公众看」的AI模型进行了实测:用单次提示构建他想了多年的牧羊犬赶羊游戏。模型推理了45分钟、消耗€20+的tokens后,产出了一个2319行、零依赖的index.html文件。游戏实际可玩,羊群移动模拟相当逼真,作者认为这是AI首次能一次性完成这类任务。不过评论指出了几个问题:游戏创意并不独特,市面上早有类似作品;手机端体验糟糕,强制横屏提示遮挡内容;以及「最危险AI」的标题纯属标题党,文章内容并未讨论任何危险性——作者本人也承认这更多是营销炒作。整体而言,社区认为这个demo展示了当前LLM在游戏原型开发上的能力,但离真正的原创性和生产级代码仍有距离。

评论精华

  • 羊群移动模拟非常逼真,但手机端强制横屏且画面不变大,用户体验差
  • 游戏创意并不独特,类似牧羊犬赶羊游戏早已存在,「想了多年的 idea」暴露了缺乏调研
  • 标题「最危险的AI模型」过于戏剧化,文章实际并未讨论AI危险性,纯属标题党
  • 维护和改进阶段仍需人类介入,AI生成代码的可维护性存疑
  • 当前LLM已能很好地实现这类游戏demo,但移动端体验和代码质量仍是短板
No.02 Leaving Mozilla
离开 Mozilla:一位 15 年老员工的反思
46 分 0 条评论 作者: martey
一位在 Mozilla 工作 15 年以上的员工离职后发文反思,批评领导层不理解 Firefox 的核心定位。作者指出,Firefox 用户是主动寻找的「非主流」用户群体,他们不需要 Chrome 的替代品,而是需要真正不同的体验。然而领导层面对 DAU 下滑时,总想模仿大浏览器的功能策略,却不了解这些用户已有大浏览器在手中。作者还指出,Mozilla 的高度开放透明在科技行业极为罕见,但空降的传统科技公司高管无法理解这种文化,常以「不能告诉任何人任何事」的硅谷思维做决策。文章最后以三条忠告收尾:尊重自己、互助、不忘服务对象,并坦言 Mozilla 能存活至今是因为领导层之外的努力,而非因为领导层。
No.03 There is a shadow hanging over this Fable thing
Fable 事件:笼罩在阴影下的 AI 监管争议
172 分 133 条评论 作者: theahura
美国政府以国家安全为由,要求 Anthropic 封禁 Fable 5 和 Mythos 5,禁止所有外国国民(包括境内用户)访问。官方声称发现了可「越狱」Fable 的方法,但 Anthropic 反驳称该技术漏洞在其他模型(包括 GPT-5.5)中也普遍存在,封禁决定过于草率。作者坦言自己本是 AI 悲观主义者,但质疑本屆政府此举的真实动机——Anthropic 曾努力配合国防部,却被政府宣布为供应链风险;与此同时,竞争对手 OpenAI 与本届政府关系密切。鉴于发布时机蹊跷(周五下午 5:21)、细节付之阙如,作者认为这更像政治报复或市场竞争手段,而非真正的 AI 安全监管。

评论精华

  • 多数评论认为此事与 OpenAI/xAI 利益相关,政府借机打压 Anthropic 以助竞争对手。
  • 有人指出,美国封禁高能力模型实际上让非美国公司在 AI 竞争中处于劣势,影响不可忽视。
  • 部分用户为政府行为辩护,认为政府介入 AI 领域本身并无问题,关键在于由谁执政。
  • 评论者援引 OpenAI 当年「GPT-2 太危险」营销案例,认为 Fable/Mythos 的下架可能是类似策略。
  • 也有人担忧,若 volatile 政府能随意封禁已部署的模型代码,这将对整个 AI 行业开危险先例。
No.04 Statement on US government directive to suspend access to Fable 5 and Mythos 5
美国政府指令 Anthropic 暂停Fable 5和Mythos 5所有外国人访问
2037 分 1496 条评论 作者: Dylan1312
美国政府以国家安全为由,向Anthropic发出出口管制指令,要求立即暂停所有外国人(含美国境内的外国公民及Anthropic外国员工)访问Fable 5和Mythos 5。Anthropic于下午5:21pm收到指令,正全面遵守并禁用相关模型。政府未提供具体国安疑虑细节,仅口头告知发现了可「越狱」绕过安全防护的方法。Anthropic审查后认为,所谓漏洞仅是让模型读取代码库并修复软件缺陷——这是其他公开模型(如GPT-5.5)每天都在用的常见防御能力,并不构成Mythos特有的提升。Anthropic表示其Fable 5采用了「纵深防御」策略,安全防护已通过数千小时的政府、第三方及内部红队测试,且从未发现过通用越狱方法。Anthropic不同意基于狭窄潜在越狱就撤回商用模型,认为若此标准适用于全行业,将导致所有前沿模型提供商停止新模型部署,称此次行动缺乏透明度和技术事实支撑,正在努力恢复访问。

评论精华

  • 美国将外国人(含境内员工)一刀切禁用的做法过于严苛,将促使全球客户加速转向中国AI模型
  • Anthropic此前高调宣传模型危险性以差异化营销,如今政府采纳其框架反噬自己,实属讽刺
  • 企业客户对核心基础设施可被政府随时断供感到不安,这将动摇对美国AI公司的长期信任
  • 此次事件预示主权AI趋势加速,欧盟等地区将更坚定推进本土AI战略以规避美国出口管制风险
  • 政府指令缺乏具体证据和透明程序,若凡有潜在越狱就禁用商用模型,前沿AI发展将陷入停滞
No.05 Electric motors with no rare earths
无稀土电动汽车电机:雷诺的技术路线与战略选择
397 分 101 条评论 作者: bestouff
雷诺集团自2012年起量产电励磁同步电机(EESM),避免使用稀土永磁体。其EESM技术历经三代:2012年款5A系列(57-100kW)用于Kangoo Z.E.和Zoe;2021年款6A系列(160kW)用于Megane E-Tech、Scenic E-Tech、A290等车型;2027年将推出7A系列(200kW),体积缩小30%、碳排放减少30%、效率达92%,并升级至800V架构。雷诺选择EESM的核心考量是中国控制全球85%稀土提纯和90%以上稀土磁铁产能,且优先供应本国市场,导致供应链风险极高。评论中有人指出该技术早有应用(Tesla早期车型、BMW、Nissan等也在用),且BMW已实现300kW功率和800V架构,技术更领先;也有质疑称无稀土电机效率不如永磁电机,且再生制动功能是否受影响存在争议;还有人提到奔驰的轴向磁通电机反而大量使用稀土,形成鲜明对比。

评论精华

  • Tesla早期Model S/S/X的ACIM感应电机也是无磁设计,雷诺并非唯一;BMW等欧洲厂商的无稀土电机功率更高(300kW)、采用800V架构
  • 该技术早已存在(大型发电机也用电励磁转子),非新发明,且有评论称有刷设计不如无刷永磁电机先进
  • 稀土磁体性能太好,欧美应自己建稀土提炼厂而非依赖中国;也有人质疑再生制动在这种电机上是否能正常工作
  • 奔驰新推出的轴向磁通电机反而大量使用高端稀土永磁体,与雷诺路线形成鲜明对比,两家策略完全不同
  • EESM在高速行驶时效率反而更高(因转子磁场可控),这与永磁电机的高速劣势形成对比,是值得关注的技术优势
No.06 CRISPR tech selectively shreds cancer cells, including "undruggable" cancers
CRISPR技术实现精准灭癌:可编程染色质碎裂机制有望攻克「不可成药」癌症
797 分 189 条评论 作者: gmays
IGI研究团队在Nature发表突破性研究:利用CRISPR-Cas12a2系统实现癌细胞精准清除。该技术通过检测p53突变基因产生的特定RNA,激活「染色质碎裂」机制,仅摧毁携带突变的细胞,健康细胞几乎不受影响。p53突变见于近半数癌症及70-90%的卵巢癌、胰腺癌、非小细胞肺癌。由于传统靶向药无法作用于肿瘤抑制蛋白,这类癌症长期被视为「不可成药」。新方法的独特之处在于完全绕过「重新激活」思路,转而「消灭」异常细胞,且具有可编程性,可快速针对新突变设计guide RNA。评论聚焦于:此前已有类似Cas9研究,此技术真正优势在于Cas12a2的不同机制;递送难题仍是临床最大障碍;癌细胞可能通过突变p53转录本逃避攻击;CRISPR临床应用仍处早期,仅1款FDA获批疗法。

评论精华

  • Cas12a2机制与Cas9不同,此次「染色质碎裂」并非新概念,但之前研究多止步于细胞层面,临床转化仍是难题
  • 癌细胞可能通过简单突变p53转录本序列来逃避guide RNA识别,这是明显的耐药性演化路径
  • 递送效率是CRISPR癌症疗法的最大瓶颈——需要将酶送达体内每一个癌细胞,病毒载体难以覆盖全部细胞
  • CRISPR临床应用仍处早期,仅1款FDA获批疗法;对比 AAV(7款)和慢病毒(7款)疗法,炒作热度远超实际进展
  • 部分评论指出另一团队已率先发表相同方向研究,且经济激励结构使癌症疗法研发资源远少于广告技术
No.07 Open source AI must win
开源 AI 必须胜出
792 分 243 条评论 作者: vednig
作者 Ahmad Osman 呼吁开源 AI 赢得竞争,指出如果智能只能从少数封闭机构「租用」,公众失去的不仅是软件自由,更是操作自由。AI 是文明级基础设施,访问不应依赖封闭 API、远程平台或少数公司设定的价格。开源 AI 应保持可用、可理解、可复现、可本地部署、经济可行并由社区治理,避免陷入「认知订阅经济」。文章核心诉求是确保人类无需许可即可研究、构建、修改和运行智能系统。

评论精华

  • 训练成本极高,资金来源(VC 回报 vs 政府资助)是根本障碍,去中心化训练方案通信速度难以支撑
  • 「开源 AI」定义模糊——能在自有设备运行的才叫开源,而多数模型依赖云端算力,非真正开源
  • 真正的瓶颈是 GPU 硬件而非权重本身,拥有算力的企业始终占据优势
  • 开源操作系统和手机从未真正「赢过」,开源 AI 未必能走出不同路径
  • 部分评论者认为「Open Weight」已足够,另一些则指出开源与封闭模型的差距正在扩大
No.08 Twenty One Zero-Days in FFmpeg
AI安全代理在FFmpeg中发现21个零日漏洞,含RCE利用演示
184 分 112 条评论 作者: redbell
安全初创公司depthfirst的AI安全代理在FFmpeg中发现了21个零日漏洞,其中8个已获CVE编号。这些漏洞覆盖TS解复用器、VP9解码器、RTP depacketizer等多个组件,总成本约1000美元,仅为Anthropic使用Mythos的十分之一。部分漏洞已在代码中潜伏15至23年,其中一个栈缓冲区溢出可追溯至2003年的SDT实现。代理通过威胁建模、攻击面分析和自动化PoC生成工作流程,确认每个漏洞可实际利用而非理论风险。文中演示了一个RCE利用原语,受害者只需执行ffmpeg -i rtsp://attacker/stream即可被攻击。但社区评论对「零日」定义存疑,认为FFmpeg长期被重点审计,真正未被发现的漏洞数量可能有限。

评论精华

  • 评论者指出FFmpeg长期处于安全研究关注下,所述漏洞是否真属「零日」存疑,「零日」标签有营销之嫌。
  • 部分漏洞利用条件苛刻,需配合ASLR泄露等才能实现真正的任意代码执行。
  • 有评论认为FFmpeg开发者对安全研究者态度不友好,影响了漏洞修复进程。
  • GStreamer被视为替代方案,但被指出本质仍是FFmpeg的封装,安全性无本质差异。
  • John Carmack近期曾盛赞FFmpeg创始人Fabrice Bellard的编程能力,引发社区讨论。
No.09 Show HN: Putt.day a daily mini golf game
展示:Putt.day 每日迷你高尔夫游戏
150 分 70 条评论 作者: ellg
Putt.day 是一款每日迷你高尔夫游戏,玩家拖拽球杆控制击球力度和方向,目标是以最少的击球次数将球打入洞中。游戏支持拖拽旋转视角、双指缩放,水域障碍会将球送回原位。每天推出一张新球场,仅首次完成成绩计入排名,旧关卡可通过日历回顾。当前为第 32 天(2026 年 6 月 13 日)。社区反馈集中在物理引擎失真:球体偏「软」、滚动阻力过大、碰撞时动量衰减过快,导致短推几乎无法控制距离。另有玩家反映移动端触控操作被拇指遮挡视野,以及画面卡顿问题。开发者已根据反馈更新物理参数,并修复了因随机种子错误导致的关卡 BUG。

评论精华

  • 物理引擎失真:球体滚动阻力过大,短推距离难以控制,碰撞后动量衰减过快
  • Par 6 极难达成,多位玩家实测需要 13-26 杆,但存在利用墙壁反弹「作弊」的速通路线
  • 移动端触控体验差:拇指遮住球体导致无法看清击球方向和力度
  • 部分玩家遇到卡顿或白屏问题,另有用户称赞幽灵玩家回放和整体设计
  • 开发者已推送物理与计分修复,并承认当日关卡因随机种子 BUG 过于简单
No.10 The computer science degree isn’t dead
CS学位并未消亡:问题在招聘管道而非学位本身
73 分 51 条评论 作者: jnord
作者Brian Jenney拥有12年软件工程经验,运营AI工程培训公司Parsity,反驳「CS学位已死」的说法。他认为问题不在学位,而在于招聘管道失灵:2023至2024年间,标注「初级软件工程师」的职位增长47%,但实际录用却下降73%,大量「幽灵职位」造成虚假繁荣。数据对比需更全面——CS毕业生失业率6.1%虽高于哲学(3.2%),但综合失业、Underemployment和早期薪资来看仍名列前茅。作者建议:激活真实人脉(约26%offer来自内推)、考虑风险匹配的初创公司、主动制造项目经验(已部署的真实应用)、深入学习AI工程技能(RAGpipeline、多Agent系统)而非只会用工具。最后强调构建持久能力而非追逐市场波动。

评论精华

  • 无学位直接从业极为艰难,除非已有现成的人脉网络,建议有条件还是获取学位
  • 读研策略建议:本科读物理等理工科再转CS硕士,比本科CS更有竞争力
  • 任何学位都有价值,研究型学位更好,PhD尤其能证明学习能力
  • 哲学/艺术史失业率低是因为毕业生更愿意接受非相关工作,而CS毕业生更坚持本行
  • 批评者指出幽灵职位问题同时,IEEE自身文章质量近年也在下滑
No.11 How to setup a local coding agent on macOS
在 macOS 上搭建本地编码 Agent:llama.cpp + Gemma 4 + MTP 加速实战
353 分 84 条评论 作者: kkm
作者因网络中断无法使用云端 AI,决定在 macOS 上搭建本地编码 Agent。硬件为 M1 Max(64GB 统一内存),最终方案为:llama.cpp(Metal 加速)+ Gemma 4 26B-A4B Q4 量化模型 + Q8 MTP 草案模型(推测解码)+ 多模态投影器 + Pi 终端 Agent。基线速度 58 tokens/s,加入 MTP 草案模型并调优后达到 72.2 tokens/s(提升约 24%),提示处理速度不变,仅生成速度提升。实测发现 llama.cpp 配合 MTP 优于 MLX,且加载多模态投影器后不影响文本生成速度。作者提供了完整的从编译、下载模型到配置 Pi 的步骤,并指出任何 --spec-draft-n-max 值 1-6 都值得测试,系统相关性很强。

评论精华

  • 多位读者指出 LM Studio、oMLX、Ollama 等工具可一键完成类似配置,无需手动编译 llama.cpp,门槛更低
  • 有读者质疑仅比较 tokens/s 而不评估答案质量的意义,称「128 tokens 连 hello 都不如」
  • 64GB 内存是门槛,M4 48GB 用户尝试过 Ollama 方案均太慢;16GB MacBook 最多跑 8B 模型
  • oMLX 支持 MTP/dflash 草案,可自动下载 MLX 模型并管理缓存,适合 GUI 需求用户
  • M5 MAX 用户表示本地模型与托管模型差距大,投入时间金钱也难达一半效果
No.12 On CPU Physics and CPU Cycles
论 CPU 物理与 CPU 周期
29 分 5 条评论 作者: signa11
本文为《现代64位CPU高效C++编程》一书第四章草稿,探讨CPU底层物理特性与性能关系。核心观点:电子信号延迟主要受寄生电容影响(而非光速限制),电容与连接长度成正比。内容涵盖:超标量流水线CPU的R-R操作可并行执行;L1D缓存读约3周期、写几乎即时,L2约10-15周期;除法性能近年显著提升至约20周期;分支预测失误代价约15-25周期。文章建议谨慎使用[[likely]]/[[unlikely]]属性,因现代CPU采用动态分支预测且程序员往往高估自己对分支概率的判断;仅在错误处理等明确低频场景才值得使用。文章还提及TLB等未深入展开的话题。

评论精华

  • 插图风格怀念:评论者期待作者恢复此前博客中可爱的绘图风格和配图
  • 引用质量存疑:另一评论者认为文中的引用片段选择随意,不值得特别标注
No.13 Swift at Apple: Migrating the TrueType hinting interpreter
Apple 将 TrueType 提示解释器迁移至 Swift:安全加固与性能提升
191 分 84 条评论 作者: DASD
Apple 宣布将 TrueType 字体提示解释器从 C 语言重写为内存安全的 Swift,计划随 2025 年秋季系统更新发布。此举旨在应对字体解析器处理不可信数据带来的安全攻击面问题。核心挑战在于必须实现与原 C 实现的像素级兼容——任何细微差异都可能导致字体渲染出现肉眼可见的变化。为此团队编写了近四倍于解释器本身的测试代码,并使用 1000 万份 PDF 语料经模糊测试收敛至 4200 份进行覆盖验证,最终达到 99.7% 代码覆盖率。性能方面,Swift 版本反而比原 C 版本平均快 13%,主要优化手段包括:使用 ~Copyable 值类型消除 ARC 开销、通过 Span<T> 高效操作跨语言边界数据、以及利用投影类型替代数据拷贝。Apple 已开源该 Swift 解释器代码,采用 MIT 许可。评论中亦有批评 Apple 应将资源投入安全底层而非 SwiftUI 的声音,以及关于 Swift 与 Rust 在互操作性和 ABI 层面差异的讨论。

评论精华

  • Apple 字体安全团队正在招聘,招聘信息可在 Apple Jobs 页面搜索 Spear 相关职位
  • 评论者指出 SwiftUI 发展路线存在问题,认为 Apple 应更专注于内存安全等底层安全改进
  • 有评论者对代码中出现 LLM 编写痕迹表示惊讶,担心操作系统关键代码质量
  • Microsoft 也在 2023 年考虑用 Rust 重写字体相关组件,目前已知 DirectWriteCore 项目由 2 名工程师耗时 6 个月完成
  • 关于 1080p 显示器是否仍被广泛使用的讨论——一方认为 Mac 生态早已淘汰,另一方指出非 Mac 世界仍非常普遍
No.14 Launch HN: BitBoard (YC P25) – Analytics Workspace for Agents
BitBoard:让 AI 代理把数据分析变成持久资产的工作区
43 分 21 条评论 作者: arcb
BitBoard 是 YC P25 孵化的分析工作区,定位为 AI 代理时代的数据分析基础设施。用户可在任意 AI 聊天或编码代理中生成仪表盘和分析,并将成果转化为连接、持久的资产,而非散落在聊天记录里的临时内容。所有连接、查询和代码均被存储,可追溯数据来源并用一致的逻辑重新运行。它支持直连数据源进行实时查询,或由代理推送数据以复用现有连接。核心价值在于:既利用 AI 做数据分析,又不丢失逻辑和上下文;团队成员可在浏览器内协作共享。该公司透露他们此前做其他产品,但客户不断将他们推向数据分析问题,因此转型至此。

评论精华

  • 社区看好该概念,demo 获得好评,与现有 AI 工具链的整合被视为核心竞争力
  • 用户 htrp 追问能否绕过 Google OAuth 注册,创始人 arcb 承认目前仅支持 Google 登录但已在规划其他方式
  • 用户 sails 和 spmartin823 对 BI 赛道竞争激烈表示担忧,建议深耕医疗等垂直领域,并质疑为何选用 DuckDB 而非 CockroachDB/Snowflake
  • dennis16384 分享了自己开源的类似工具 eatmydata(MIT 许可证),并给出实测数据:Excel/CSV 上传后 10 秒出结果,而 Claude 处理同等量级数据需 5 分钟
  • mritchie712 指出完整数据栈搭建成本过高,人们已对 ETL、仓库、BI 的拼装失去耐心,这正是 BitBoard 的机会
No.15 Malware developers added nuclear and biological weapons text to to their spyware
恶意软件作者在间谍软件中植入核生物武器文本以干扰AI安全扫描
375 分 215 条评论 作者: marc__1
安全研究人员发现恶意软件开发者开始将核武器与生物武器相关内容文本嵌入间谍软件,以触发主流 LLM 的安全拒绝机制。当安全扫描工具调用 AI 进行代码分析时,遇到这些触发词会自动拒绝服务,导致恶意代码得以绕过分析。这一现象揭示了 AI 安全过滤器的双刃剑特性——本意是防止有害内容传播,却被恶意利用来阻断正当的安全审查。社区对此反应两极:一方认为这是对过度审查的讽刺性反击,揭示了 AI 过滤器的脆弱性;另一方指出此类触发词只是早期原子弹设计知识,实际威胁有限,且可通过对触发词进行预过滤或使用更弱模型规避。更深层的问题在于,任何依赖内容分类的安全机制都可能成为攻击面。

评论精华

  • AI 拒绝机制本质是 DoS 工具,恶意软件作者反向利用它来阻止代码审查
  • 所有 LLM 的核武知识都来自公开网络,无保密信息,安全顾虑主要是公司声誉
  • 过滤字符串可被轻松移除或用更弱模型绕过,实际防护效果有限
  • 有人建议用毒性词嵌入作为开源项目的 LLM PR 过滤手段
  • 对安全过滤器本身是否合理的争论——是合理限制还是过度审查
No.16 Show HN: Lightweight Task queue on Erlang/OTP, SQLite-backed, no overengineering
展示: Erlang/OTP 轻量级任务队列,SQLite 后端,零过度工程
26 分 5 条评论 作者: ent1c3d
ezra 是一个基于 Erlang/OTP 构建的轻量级任务队列,采用 SQLite 作为持久化存储,并遵循 Redis 协议以实现良好的兼容性。项目主打「不过度工程化」的设计理念,旨在不引入 Kafka、Redis 等外部依赖的情况下,提供可靠的异步任务处理能力。Erlang/OTP 的使用确保了系统的高并发与容错特性,SQLite 则简化了部署复杂度。评论者对作者选用 Redis 协议的做法给予肯定,认为这是聪明的设计决策;同时也有人指出,若需要在 Postgres 生态中处理 DAG 类复杂工作流,可参考 PgFlow 项目。

评论精华

  • abrookewood 肯定作者选用 Redis 协议实现兼容性,询问是否需独立部署
  • cpursley 推荐 PgFlow 作为 Postgres 环境下 DAG 工作流的替代方案
No.17 The Future of wasi-gfx and wasi:webgpu
WASI 图形接口拆分:wasi-gfx 将独立于 WASI 命名空间运营
21 分 4 条评论 作者: mendyberger
wasi-gfx 团队宣布将部分图形接口从 WASI 核心规范中拆分出来。原因是 WASI 追求十年尺度的架构稳定性,而 wasi:surface 等 UI 接口仍需快速迭代。调整方案为:wasi:webgpu 因基于 W3C WebGPU 标准,将继续保留在 WASI 命名空间;wasi:surface 和 wasi:frame-buffer 将迁移至新命名空间 wasi-gfx,以库的形式独立演进;同时正式废弃 wasi:graphics-context。工具链 wasi-gfx-runtime 和 wasi-gfx-shim 将继续同时支持两个命名空间。此举效仿了 wasmcloud 等项目在 WASI 外部构建专属生态的实践,将通用标准与领域特定接口分离。

评论精华

  • 窗口系统粘合代码是跨平台 3D API 封装中最难维护的部分,拆分是合理选择
  • wasm/wasi 近年发展令人惊叹,源自 asm.js 的演进
  • NaCL 和 PNaCL 其实更早出现,asm.js 只是因为 Mozilla 拒绝采用前者
No.18 H.R. 6028 would fundamentally change the U.S. Copyright Office
美国版权局改革法案引发争议:EFF呼吁参议院否决 H.R. 6028
207 分 63 条评论 作者: Cider9986
美国众议院本周以声音投票方式通过 H.R. 6028 法案(立法机构 agencies 澄清法案),EFF 警告该法案将「从根本上改变」美国版权局且绝非好事。核心变化包括:取消国会图书馆对版权局的现有监督权、将多项权力直接转移给版权注册官、并使其成为总统提名、参议院确认的职位。EFF 认为这会使本已对版权和科技政策有巨大影响力的机构变得更加政治化——版权局曾在 AI 合理使用问题上严重误导、在 SOPA 法案中站在大型娱乐公司一边、长期偏向产业利益而非公众利益。法案还将 DMCA 第 1201 条规则制定权从国会图书馆馆长转移给版权注册官,进一步集中权力。EFF 批评该法案未经任何听证会就快速通过,呼吁参议院否决,「版权局应服务于公众,而非总统或行业说客」。

评论精华

  • 评论者对文章未提政党感到奇怪,有观点认为好法案与否应看其本身价值,而非谁提出
  • 有人指出法案未经充分听证和公开审查就快速通过,缺乏民主程序
  • 部分评论担忧总统任命制会使版权局政治化,助长选择性执法
  • 少数评论对版权制度本身持批评态度,认为其阻碍知识传播
  • 有评论指出 FCC 正被用于政治攻击,说明独立机构的独立性很重要
No.19 The Alchemist of Flesh: The Man Who Turned Humans into Stone(2025)
血肉炼金术士:把人体变成石头的男人
5 分 0 条评论 作者: ofalkaed
这是一篇关于19世纪意大利探险家吉罗拉莫·塞加托(Girolamo Segato, 1792-1860)的人物特写。塞加托自称发现了古埃及神秘「血肉化石」术的秘密,并利用硅酸盐配方成功将人体转变为石质木乃伊。他最著名的作品是一具名为「埃及石人」的成品,声称源自古埃及,但实际上可能是他亲手炮制。塞加托拒绝透露具体配方,坚称已将其带入坟墓,令学界至今无法验证真伪。文章探讨了这一介于科学与骗术之间的历史悬案,分析了当时欧洲对埃及学的狂热迷恋如何催生了此类谜案,也暗示部分「古物」可能纯属后世伪造。
No.20 Pirates, a naval warfare game inspired by Sid Meier's Pirates
展示:一款受席德·梅尔《海盗》启发的浏览器海战游戏
249 分 78 条评论 作者: iweczek
一款致敬经典《海盗》(Sid Meier's Pirates)的浏览器海战游戏,采用 Love2D 引擎开发,目前仅有船战系统演示。游戏玩法围绕操控船只、转向机动、用炮火击沉对手展开。社区反馈聚焦几个问题:缺少风向机制(原文必须顺风航行否则减速);小船过于强力凭借速度优势可无伤耗死大船;炮弹颜色与背景对比度低导致难以观察;操控说明不明确(空格键射击)。多位用户勾起怀旧情绪,提及 Apple II 上的《Old Ironsides》《Taipan》等经典海战游戏。开发者活跃回应,承诺加入风向系统和改进平衡性,并有人以此为基础实验多人模式和岛屿地图。

评论精华

  • 风向机制缺失是小船无解的根本原因:顺风快、顶风慢,原作核心玩法未还原
  • 游戏平衡性堪忧:小船速度与转向均优于大船,绕圈射击即可无伤取胜
  • 视觉效果问题:炮弹与海面颜色接近,肉眼几乎无法追踪弹道
  • 多位用户借题回忆 80 年代经典:Apple II《Old Ironsides》《Taipan》,C64/Amiga 上的原作
  • 开发者积极响应反馈,计划加入风向、多人模式、岛屿等元素
No.21 Tectonic: A modernized, complete, self-contained TeX/LaTeX engine
Tectonic:现代化、独立化的 TeX/LaTeX 排版引擎
46 分 9 条评论 作者: maxloh
Tectonic 是一个从 XeTeX 分叉而来的现代 TeX/LaTeX 引擎,旨在解决传统 TeX 发行版构建过程过于复杂的问题。它能直接将 TeX 文件转换为 PDF,提供开箱即用的体验——用户只需运行「tectonic paper.tex」即可完成编译,无需手动管理复杂的工具链。Tectonic 名字取自希腊语「木匠」(τέκτων),意在暗示对 TeX 世界的重大变革。项目采用 MIT 许可证,基于 LaTeX、TeXLive、XeTeX、dvipdfm-x 等数十年积累开发,依赖 Dataverse Project 托管的资源包实现网络下载功能。目前维护者坦言项目已数年无重大更新,精力有限。

评论精华

  • 项目背景:Tectonic 从 XeTeX 分叉,但 XeTeX 等主流引擎的构建流程极为复杂巴洛克化。
  • 维护者自评:项目数年无重大变化,因缺乏时间和动力可能短期内也不会有显著进展。
  • 用户痛点:LaTeX 仍存在错误信息晦涩、管道复杂、Unicode 符号支持不足等老问题。
  • 兼容性争议:有评论指出 XeTeX 与 Overleaf 不兼容,但遭反驳称 Overleaf 原生支持 XeTeX。
  • 替代方案:有用户转向 Typst,认为其体验更佳;另有用户大赞 Tectonic 通过 conda-forge 分发方便。
No.22 Slightly reducing the sloppiness of AI generated front end
让AI生成的界面少一点「slop」味:Qt风格确实管用
189 分 118 条评论 作者: FergusArgyll
作者想让AI帮自己快速生成好看的个人工具,但苦于没有设计品味控制不好AI。测试多款风格后意外发现:只要要求AI生成「看起来像Qt应用」,几乎能消除那种廉价slop感。原因是Qt有严格的设计规范,AI不必在无数选项中做选择,避免了把所有风格「平均化」后产出的那种模糊感。作者把选举地图可视化工具改成Qt风格后效果好,随后将自己其他个人软件也迁移到Qt风格,效果同样令人满意。

评论精华

  • Qt在训练数据中高度代表性,模型有完整「语法」可循,限制选项反而避免AI平均化所有风格
  • macOS HIG和Windows UI同样有效——关键在于提供约束明确的设计系统而非开放描述
  • 「slop」本质是AI在无限选项下无指导创作的必然结果,不专属于AI生成的界面
  • 提供设计参考图板+明确颜色/模板约束,可显著提升生成质量
  • 部分用户持相反意见,认为AI生成UI效果很好,问题被夸大
No.23 Automating Myself Out of Development
我如何用 Claude Code 将自己移出开发流程
11 分 6 条评论 作者: nisabek
作者记录了使用 Claude Code 逐步将自己从开发周期中移除的实验过程。Phase 0 他在本地开多终端并行与 AI 协作,但上下文切换疲劳让他难以持续。Phase 1 他将项目迁移到隔离的 EC2 实例以缩小风险范围,发现了笔记和记忆文件之间混乱的耦合。Phase 2 他放弃了手机远程干预的想法,转而追求「检查点式」沟通:AI 完成一块工作后留下清晰的交付物和问题,他次日再处理。Phase 3 他用 GitHub Issues 作为 AI 的任务看板,实现真正的日程驱动自动化。作者强调这个过程需要亲自尝试、理解自己如何与 AI 协作,并承认「自动化起初会让你更慢」。

评论精华

  • noelwelsh:希望作者更详细描述具体用 AI 做什么任务——简单组件可以,涉及架构决策的就困难了
  • yieldcrv:批评两个极端——完全依赖 AI 的人 vs 不愿放权的资深开发者之间应该有中间地带
  • nullbio:从零开始构建的人不太适合这种流程,单纯维护现有代码的人更适合
  • properbrew:自己用 AI 从零开发了 Whistle Enterprise,虽耗时耗力但确实可行
  • Npovview:建议搜索 YouTube 上用复杂玩具项目演示 AI 开发流程的长视频
No.24 Israeli firm BlackCore suspected of meddling in New York and Scotland votes
以色列公司 BlackCore 被怀疑干预纽约和苏格兰选举
5 分 0 条评论 作者: pera
路透社披露,以色列网络安全公司 BlackCore 涉嫌参与干预纽约市和苏格兰地区的选举活动。调查显示,该公司可能通过社交媒体操纵、信息传播或其他数字手段影响选民行为。除纽约和苏格兰外,法国同样是调查涉及的地区之一。此案引发西方多国对外国实体干预选举的高度关注,相关执法部门正在深入调查。BlackCore 方面尚未公开回应这些指控。
No.25 TycoonLE: A Jax reinforcement learning environment for long-horizon planning
TycoonLE:基于 JAX 的长周期规划强化学习交通经济模拟环境
12 分 1 条评论 作者: vrtnis
TycoonLE 是一个受 OpenTTD(开放运输大亨)启发的强化学习研究环境,基于 JAX 框架实现。其核心设计聚焦于长周期决策:智能体需要构建运输路线、调度货运、管理债务,并优化延迟收益。相较于游戏 AI 常用的短期奖励机制,该环境强调真实经济中的延迟回报与资源权衡问题,有助于研究信用分配、长期策略优化等强化学习难题。项目面向研究社区,提供标准化的 Gym 风格接口,适合评估各种 RL 算法在复杂经济模拟中的表现。

评论精华

  • 作者介绍 TycoonLE 的核心玩法:智能体建造路线、运输货物、管理债务、优化延迟收益,模拟运输经济系统
No.26 Palantir loses legal challenge against Swiss investigative magazine
Palantir 败诉:瑞士调查媒体成功抗辩,22 项诽谤删除请求仅 1 项获准
308 分 60 条评论 作者: sschueller
美国数据分析公司 Palantir 试图通过法律手段压制瑞士独立媒体《Republik》及旗下调查项目「WAV」的系列报道,但苏黎世商业法院最终裁定:Palantir 提出的 23 项「反陈述」(counterstatement)删除请求中,仅 1 项获准,其余 22 项均被驳回。Palantir 软件长期服务于美国国防和情报机构,近年来在部分欧洲国家面临日益增长的监管审查,丹麦、荷兰等国已表态希望减少对美国科技公司的依赖。Palantir 联合创始人彼得·蒂尔等人与《魔戒》的关联并非巧合——该公司名称本身即取自「全视之眼」Palantiri。法院判决后,《Republik》表示「欢迎法院确认我们的出版反述权」。

评论精华

  • 魔戒命名隐喻:Palantir 意为「全视之器」,落入坏人手中必然造成伤害,历史一再证明
  • 欧洲各国对美国科技公司的不信任情绪真实存在,丹麦、荷兰已明确表达脱钩意愿
  • Alex Karp 近年政治立场急剧转变,从进步派走向 MAGA 路线,引人关注
  • Anduril 等国防科技公司同样以《魔戒》物件命名——破碎圣剑重铸,象征西方再工业化
  • 调查记者的坚守值得尊敬,在技术封建主义时代扮演希望灯塔的角色
No.27 A key remapping daemon for Linux
keyd: Linux 键盘重映射守护进程
40 分 19 条评论 作者: joooscha
keyd 是 Rahemtlla 开发的一款 Linux 键盘重映射守护进程,旨在解决 Linux 键盘映射配置复杂、Wayland 兼容性差等痛点。它无需 root 权限即可灵活定义键位,核心特性包括:用 C 编写的输入循环延迟低于 1ms、支持将 caps lock 映射为 control 等修饰键、以及 hold/tap 键功能。评论普遍认为它比传统 xkbd 定义方案更简单、开箱即用,尤其在 Fedora Silverblue 上运行良好。有用户提到它拯救了「janktacular」的 Python 脚本。另有评论指出,它比 input-remapper 缺少高级宏功能,但专注于键位映射本身,简洁高效。

评论精华

  • 性能表现出色,C 语言输入循环延迟低于 1ms,用户建议目标可降至 1µs
  • 用户盛赞其开箱即用,解决了 Linux 上 caps lock 映射为 control 的长期痛点
  • 在 Fedora Silverblue 上运行良好,Wayland 环境下比传统方案更易用
  • 与 input-remapper 相比功能较简单,缺少高级宏支持
  • 被 macOS Karabiner-Elements 用户称为「godsend」,终于能在 Linux 上用 hold/tap 键
No.28 A generic dynamic array in C that stores no capacity and needs no struct
展示:C语言实现无struct、无capacity存储的泛型动态数组
11 分 19 条评论 作者: alurm
这是一个纯C语言实现泛型动态数组的代码片段,核心创意在于利用2的幂次特性——当数组长度为0或2的幂时,容量可通过stdc_bit_ceil计算得出,无需显式存储容量字段。同时通过不定义struct来避免为每种元素类型创建单独的数组结构体,利用typeof实现类型推断。然而评论指出这是「小聪明」式设计:容量实际仍存储在realloc的内存分配中,无法真正预留固定容量,且不使用struct导致类型不安全,arr[0]与arr[1]混淆、越界写入arr[3]等错误难以调试。支持者则认为对于无需预留容量的简单场景,这种设计简洁优雅,2的幂次扩容策略本身也是常见优化。

评论精华

  • 容量仍通过realloc隐式存储在内存分配中,并非真正零开销
  • 无法预留capacity,因为隐式为下一个 >= size 的2的幂次,实用性受限
  • 不用struct是类型安全问题,arr[3]越界访问极易导致堆损坏
  • 用2的幂次计算capacity的设计本身很巧妙,这种观察确实罕见
  • 通过_Generic和typeof同样可实现泛型,无需此技巧
No.29 If you are asking for human attention, demonstrate human effort
转发AI输出前,请先展示人类的努力
1574 分 469 条评论 作者: jjfoooo4
随着AI写作越来越普遍,作者提出了一个职场礼仪原则:如果你在请求人类的注意力,就要展示人类的努力。作者回忆一次经历——同事用AI批判他的设计方案,却表示「我没读过,可能不准确」,他反问:如果你都不愿意读,为什么要我读?作者的建议是:转发AI生成内容时务必标注来源,并附上自己的评论;请求代码审查前先自己审查AI生成的代码。评论区反响强烈,多人吐槽身边有同事完全沦为「AI提示词工程师」,copy/paste任务描述给AI后原文转发、连错都不改。也有观点指出,如果工作产出与机器无法区分,老板为何不直接用机器?更有人提出「不想写的人,也不值得别人读」的辛辣观点。

评论精华

  • 有同事彻底拥抱AI,六个月后开始抱怨没人看他们的PR,陷入自食其果的困境
  • 「敷衍的提问者值得得到敷衍的回答」——不付出努力的人不应期待他人付出努力
  • 有人直接把任务描述copy/paste给AI然后转发,连自己都不读一遍
  • 如果工作与机器无法区分,老板为何不雇机器?LLM输出质量不足也削弱了可信度
  • LLM输出量无限,不值得花时间阅读;更有人主动追踪键盘使用行为来区分AI写手与真人
No.30 SkillSpector
NVIDIA 开源 SkillSpector:AI 技能安全验证工具
40 分 4 条评论 作者: taubek
SkillSpector 是 NVIDIA 开源的一款 AI 技能安全验证工具,旨在检测和审查 AI Agent 所调用的技能(skills)是否存在恶意代码或安全隐患。由于当前许多 AI 系统支持用户自定义技能扩展,而这些技能可能包含执行任意操作的 Python 脚本,安全风险不容忽视。该工具试图在技能被加载执行之前对其进行扫描验证。然而评论区的反馈呈现两极化:一派认为这比什么都不做要好,是纵深防御的一层;另一派则指出其本质局限——LLM 审查 LLM 代码如同让病毒软件审查病毒,容易产生虚假安全感,且如果审查用的 LLM 本身存在漏洞,整个链条仍不可靠。还有评论提及技能可递归导入子文件夹中的 Python 文件,当前社区对技能的安全导入机制普遍缺乏信任。

评论精华

  • SkillSpector 类似杀毒软件,提供了验证手段但可能产生虚假安全感
  • 供应链攻击真实存在,多层安全纵深防御中这一环值得纳入
  • 技能可包含子文件夹中的 Python 文件,人们导入时普遍盲目
  • LLM 审查 LLM 代码是否冗余?若审查 LLM 本身有漏洞则形同虚设