No.01
Don't be a meat proxy
别做人肉 AI 转发器
259 分
107 条评论
作者: ngruhn
作者批评一种越来越常见的协作坏习惯:别人提问、评审代码或讨论问题时,直接把 Claude 等 AI 的长篇输出原样贴回去。这样没有增加价值,因为对方完全可以自己问 AI,还能控制上下文;接收者反而要承担阅读冗长、术语密集、可能含幻觉内容的额外成本。作者主张可以使用 AI,但必须先读懂、验证、消化,再用自己的话回应。尤其在代码评审中,如果开发者只把需求和反馈反复转交给 Claude Code,真正完成实现的是评审者与 AI,而开发者只是「人肉代理」。
No.02
Qwen3.8-Max: A New Bar for Coding and Cowork
Qwen3.8-Max:面向编码与协作的新旗舰模型
478 分
209 条评论
作者: ai2027
Qwen 正式发布 Qwen3.8-Max,称其为家族最强模型,重点面向编码、长程自主开发和「cowork」式协作场景;评论提到它已从 preview 转为正式版,并首次宣布将开放 Max 级模型权重,下周还会发布 Qwen3.8-27B 开权重版本。社区关注其 $2/$6 的较低 API 定价、reasoning_effort 成本控制、视觉网页生成能力,以及 10 天以上自主编码演示的可信度。争议集中在基准缺少 token/推理成本细节、本地部署性价比、开权重模型监管,以及中国模型是否正在快速逼近甚至冲击 OpenAI、Anthropic 的领先地位。
No.03
More German than many Germans
比许多德国人更德国
144 分
43 条评论
作者: mertbio
作者回忆自己从土耳其学生到德国公民的经历:2017 年赴汉堡实习,原本带着德国人冷漠守规的刻板印象,却因室友、同事和公司文化感受到信任、平等与善意。此后他回到汉堡工作,在住房、行政、职场晋升和工会选举中获得大量帮助,也观察到社会民主带来的日常平等:工人与白领吃同样午餐、富人区并不排斥外来者。他承认自己是「软着陆」:国际公司、英语环境、稳定收入让融入更容易,但仍认为德国的信任文化、扁平管理和制度包容值得珍惜。评论则补充了移民体验、规则文化与官僚低效的复杂面。
No.04
Rust project goals: Immobile types and guaranteed destructors
Rust 项目目标:不可移动类型与保证析构
31 分
9 条评论
作者: paavohtl
这项 Rust 项目目标聚焦两个长期缺口:让某些值在创建后不能被移动的「不可移动类型」,以及让资源清理更接近可证明的「保证析构」。评论推断其动机主要来自 async Rust、自引用结构、scoped tasks 与结构化并发:任务可安全借用外部作用域,而不必大量 clone 或受制于当前 Pin 机制。讨论也提到相关但未必纳入目标的「!Destruct」或线性类型,用于表达必须显式消费、不能随意丢弃的值。争议集中在 Rust 现有安全泄漏机制如 mem::forget、引用循环如何与保证析构共存,以及如何在不破坏泛型生态的前提下引入类似「Forget」边界的能力。
No.05
Show HN: Isopolis – Isometric pixel map of SF
展示:Isopolis,旧金山等距像素地图
194 分
42 条评论
作者: nuwandavek
Isopolis 是一个把旧金山做成可滚动等距像素地图的网页项目,底层标注来自 OpenStreetMap、CARTO 和 DataSF,社区补充称其图像源包括 Google Photorealistic 3D Tiles,并在开发页记录了制作流程。作品凭借类似「SimCity 2000」的复古城市感、背景音乐和可点击街区信息获得大量好评,也被拿来同 Isometric NYC、Levels.fyi Atlas、Floor796 等项目比较。争议主要集中在生成式处理带来的错误:道路被误绘成湖泊、绿地和阴影变成水面、瓦片边界不连续,以及这类基于参考影像生成的风格化资产是否涉及合理使用。
No.06
AI migrated legacy COBOL programs to Java, bugs included
用确定性测试验证 COBOL 到 Java 迁移
45 分
33 条评论
作者: felineflock
论文提出一种名为「Locksmith Loop」的代理式测试合成方法,用于验证遗留 COBOL 程序迁移到 Java 后是否保持行为一致。流程先在普通硬件上搭建并插桩 COBOL 源程序与生成的 Java 目标程序,再通过输入 mock 搜索覆盖分支,并在遇到阻塞条件时识别「锁定段落」以推动更深覆盖。三个案例中,方法在 430 到 4114 行代码规模上提升覆盖率,两项开源程序接近完全覆盖,内部类生产程序达到 91.90% 分支覆盖;所有接受测试均通过确定性一致性检查。争议焦点在于实验规模较小,真实主机环境、CICS、JCL、批处理等复杂依赖未充分覆盖。
No.07
Karpathy’s Pelican
Karpathy 的鹈鹕测试
549 分
386 条评论
作者: delichon
Karpathy 展示了让 Opus 5 用约两小时、5500 行代码,把文本内容程序化渲染成三维故事场景的实验,被社区拿来和此前「骑自行车的鹈鹕」等 SVG/Three.js 快速测试相提并论。评论推断,文章核心在于:这些自定义动画和小世界生成展示了模型从静态图像走向代码驱动视觉作品的潜力,也暴露了模型难以原生审视视频、游戏和空间布局的问题。争议集中在它是否算严肃基准:有人认为它能揭示理解、规划和自我纠错能力;也有人批评提示不可复现、效果像社交媒体噱头,且模型可能针对 Three.js 或知名素材训练过。
No.08
Show HN: ssh ssh.place
展示:ssh.place
103 分
53 条评论
作者: jeninh
ssh.place 是一个通过 SSH 共同绘制的公共画布:无需账号或安装,任意 SSH key 连接后即可在 200×60 色块网格上移动光标、选择 16 种颜色并放置色块;每个 key 有 15 秒冷却,页面只读,真正修改只能通过 SSH 完成。项目强调只允许颜色块、不允许写文字,鼓励画图而非刷屏。评论区一方面觉得这种终端应用有趣、适合复刻 r/place 的协作体验;另一方面也指出广告式多开、冷却可被多 key 绕过、终端颜色兼容和光标可见性问题,并围绕连接陌生 SSH 服务的安全风险展开讨论。
No.09
Why we write our own C and C++ inference engines
为什么 LocalAI 自研 C/C++ 推理引擎
40 分
21 条评论
作者: eatonphil
LocalAI 说明其多数后端仍封装 llama.cpp、vLLM 等成熟项目,但有 18 个后端选择从零写 C/C++ 端口,原因是避免多 GB Python 依赖、CUDA 绑定或缺少可部署实现。文章用 vllm.cpp、depth-anything.cpp、face-detect.cpp、voice-detect.cpp 等案例说明:小型二进制可接近或达到参考实现吞吐,显著降低内存和冷启动成本,有时还因缓存位置嵌入、冗余 LSTM 等主机端开销而更快。作者强调流程是先转 GGUF、逐组件对齐参考张量、再用 profiler 优化、最后暴露平坦 C ABI;代价则是维护、CI、转换器和 GPU kernel 差距。评论争议主要转向文章文风是否像 AI 生成。
No.10
Convergence is not enough
仅有收敛还不够
28 分
2 条评论
作者: zdw
Ink & Switch 的 Livelymerge 项目尝试把运行中系统的整个堆——对象、类、方法——都表示为 Automerge 文档,以获得多人协作和离线合并能力。文章用链表并发交换节点的例子说明,Automerge 能保证所有客户端收敛到同一状态,但这个状态可能破坏程序不变量,如截断链表或产生环。问题根源在于系统合并的是底层写入效果,而不是用户或抽象数据类型层面的意图。作者指出,树、双向链表、缓存索引、唯一性约束等跨对象不变量都会遇到类似风险。一个有前景方向是让程序员定义「可感知合并」的数据类型,把操作记录为插入、删除、移动等高层语义,并在确定性重放时检查不变量;代价是迟到操作可能导致已接受变更回滚。
No.11
CP/M-386 – CP/M for 386 protected mode, derived from CP/M‑68K
CP/M-386:面向 386 保护模式的 CP/M 移植
63 分
24 条评论
作者: TMWNN
CP/M-386 是一个处于早期开发阶段的复古操作系统项目,试图把源自 CP/M-68K 的 CP/M 思路带到 386 及后续处理器的 32 位保护模式中。评论提到它可通过 1.44MB 软盘 MBR 或 GRUB Multiboot 启动,目标包含 Ring-3 TPA、低内存占用和相对简单的内核复杂度。讨论焦点集中在它与 CP/M-86、Concurrent CP/M、Concurrent DOS 的历史关系:社区指出 8086 版 CP/M 与 386 保护模式差异很大,选择 CP/M-68K 作为来源并非随意。另有评论借此回顾 MS-DOS、Windows 3.x、OS/2 与 DOS 兼容生态的胜负,以及对该项目非 AI 生成代码的赞赏。
No.12
Show HN: A Handwritten Blogging Platform
展示:手写博客平台
94 分
46 条评论
作者: emilesilvis
handwritten.blog 想把博客还原成更慢、更有人味的表达:用户手写页面后发布,平台不提供算法信息流、点赞等社交机制,但每个博客支持 RSS,强调「按你写下的样子」呈现。评论区普遍喜欢这种反效率、反模板化的气质,也联想到 Dijkstra 手稿、Paper Website、onetypedpage 等相近项目。争议集中在实用性:长文写作、修改编辑、搜索选中文本、翻译、屏幕阅读器支持和内容治理都会变难。作者回应称可拍照或邮件上传,未来考虑发现页;他认为项目更服务写作者的慢思考,而非高效阅读。
No.13
Autoregressive Language Model on the 6502 Processor
在 6502 处理器上运行自回归语言模型
100 分
10 条评论
作者: nmstoker
作者尝试把现代自回归语言模型塞进 1980 年代 BBC Micro:用户空间仅约 25KB,最终推理代码 9KB、权重 13KB,CPU 只有 8 位整数且无乘法指令。方案采用 BitNet 三值权重,把矩阵乘法化为加减,并以每字节 4 个参数打包;模型用字符级词表和固定状态的 recurrent 架构,避免注意力 KV cache 吃掉内存。GRU 因量化后谱半径导致训练发散被放弃,改用类似 Mamba 的逐通道衰减更新。项目价值在于展示极端约束下的模型设计取舍,但评论也质疑这种规模上 Markov 链可能更实用。
No.14
Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
展示:Kakehashi,在 Linux ARM 上运行 macOS 二进制
210 分
51 条评论
作者: vlad_kalinkin
Kakehashi 是一个实验性用户态项目,目标是在 Linux ARM 机器上原生运行 macOS 命令行二进制。作者称已有原型可运行 7-Zip 等程序,并希望长期支持 Xcode Tools、构建 iOS 应用以及 macOS 版 Homebrew。社区将其与 Darling、Wine/Proton 类比,认为若成功可填补跨平台兼容空白,但也指出 macOS API 面更复杂,距离 GUI 应用和生产力软件可用仍很远。争议集中在项目是否真正「洁净室」:作者承认使用 LLM 辅助开发,称更像「浅灰盒」,并声明未派生自 Darling。
No.15
Note-Taking and Personal Knowledge Management
笔记与个人知识管理的真实价值
190 分
52 条评论
作者: surprisetalk
作者回应一篇质疑 PKM 与 Obsidian 成果的文章,核心反驳是:工具本身不会直接创造公共知识,正如 Emacs、Vim 或相机不会独立产出贡献,它们只是让使用者完成写作、研究和整理。作者认为原文把 Obsidian 的本地 Markdown、隐私、可移植性等误读成带有「高阶」和「认识论」使命,但 Obsidian 官方更强调笔记高度个人化、只提供可组合的基础模块。文章进一步批评用「是否产生重要贡献」来衡量 PKM 框架过于含混,也难以证明学者、作者的产出与 PARA、Zettelkasten 等系统之间存在因果关系。争议焦点在于:PKM 是被夸大的生产力神话,还是因人而异的辅助工具。
No.16
Developers are attached to tools because tools encode trust
开发者依恋工具,因为工具承载信任
202 分
110 条评论
作者: HieronymusBosch
文章认为,开发者对 Vim、Emacs、IDE 等工具的依恋不只是习惯,而是长期使用中形成的信任:工具可预测、边界清晰,并嵌入个人和团队流程。AI 编程代理虽然能快速生成大量代码,却更不透明、更易变,也让需求定义、验证、评审、运行成本等旧流程缺陷暴露出来。作者强调,CI、测试、代码评审等工具只是编码了流程,不能替代文化与协作规范;在「代理式工程」时代,真正的挑战不是更快产出代码,而是建立能验证、约束并信任这些产出的新流程。
No.17
Why Book Corners won't sync contributions back to OpenStreetMap
为什么 Book Corners 不把用户贡献同步回 OpenStreetMap
84 分
51 条评论
作者: pizzaiolo
Book Corners 起初想把用户提交的小型公共书柜,在审核和去重后回馈给 OpenStreetMap。但作者研究后发现,这类来自自有数据库、由软件辅助提交的数据可能被视为外部数据导入或自动化编辑,需要专门账号、导入计划、社区讨论、许可说明、回滚机制和长期响应责任。作者认同 OSM 为防止重复、错误和许可污染而设置门槛,但认为对一个低频、小规模功能来说,运营成本已超过价值,且会挤占改善发现、审核、照片、翻译和移动体验的时间。因此决定无限期搁置写回功能,只继续标注 OSM 来源;未来若有轻量、社区认可的流程才会重考虑。
No.18
SwiftUI After 7 Years
SwiftUI 七年后的困境
184 分
158 条评论
作者: mpweiher
作者认为,SwiftUI 自 2019 年发布七年后仍像「永久测试版」,未兑现成熟、跨平台、生产级 UI 框架的承诺。文章批评其数据流从 @State、@Binding 到 @Observable 不断变化,更新原因难以预测;布局系统依赖尺寸协商却脆弱不可控,连苹果官方教程项目也会出现界面问题;API 稳定性和功能对齐不足,使代码充满兼容分支和变通方案。作者将这些问题归因于苹果从 Cocoa、Aqua、Auto Layout 时代的精工文化转向「够用就好」。争议点在于:批评者认为 SwiftUI 只适合简单界面,支持者则认为新思维、较新系统版本和必要时下探 UIKit/Metal 已足以支撑生产应用。
No.19
Emulating ALiBi with Rope
用 RoPE 模拟 ALiBi 位置偏置
3 分
0 条评论
作者: alexlitz
文章讨论如何在已有使用「ALiBi」的注意力头中,通过给 Q 和 K 额外加入一对固定维度并只对这对维度施加「RoPE」旋转,来近似复现 ALiBi 的线性距离偏置。核心推导是:在小角度条件下,RoPE 产生的正弦项可近似为线性项,因此可通过选择足够小的频率 θ 和相应较大的固定幅值 N,让其局部等价于 ALiBi 的 -m·d 偏置。作者用 BLOOM-560M 做实验,称输出和注意力分布可接近原模型;但实际可行性受 RoPE 频率集合、base 大小、上下文长度和数值尺度限制。
No.20
Read the novels and forget everything else
读小说,忘掉其他一切
92 分
71 条评论
作者: samclemens
文章回顾 Patrick O’Brian 在「奥布里—马图林」系列成名后,被揭露长期伪造身世、改名逃离前妻和孩子、性格控制且霸道的争议。作者认为,不能简单把人品与作品切开:O’Brian 对身份的伪装、对知识和权力的执念,既污染了他的私人生活,也深深进入小说主题。但历史小说让他摆脱早期自传式写作的逼仄,发展出幽默、博学、对话精妙的成熟风格。文章最终呈现的是一种张力:读者为何仍能热爱这些近乎完美的小说,同时不应完全遗忘作者复杂甚至残酷的一面。
No.21
The myth of Snow Leopard
Snow Leopard 神话的由来
90 分
76 条评论
作者: speckx
文章质疑 Mac OS X Snow Leopard 被后世奉为「只修 Bug、稳定打磨」典范的集体记忆。作者指出,自己当年使用 10.6 时曾因 Finder、FireWire 扩展卡、iMovie 插件等严重稳定性问题两次降级,其他开发者也记录过大量补丁和缺陷。文章认为,Snow Leopard 未必真是稳定性圣杯,但苹果当年「零新功能、专注优化」的叙事击中了用户长期渴望:少追逐新卖点,多修复质量、性能和日常体验。因此神话能延续十六年,并被 Linux 发行版、手机系统等领域反复借用。
No.22
RFC 9851: TLS 1.2 is in Feature Freeze
RFC 9851:TLS 1.2 进入功能冻结
32 分
9 条评论
作者: Jimmc414
RFC 9851 正式规定,TLS 1.2 进入功能冻结:除紧急安全修复、TLS Exporter 标签和 ALPN 协议 ID 外,IETF 不再批准面向 TLS 1.2 的新扩展或功能变更。文件强调 TLS 1.3 已修复 TLS 1.2 多项缺陷,包括加密更多握手信息、移除弱密码原语,并具备更强安全证明。后量子密码迁移也是关键背景:TLS 工作组未来只会为 TLS 1.3 或更高版本定义 PQC 支持,TLS 1.2 不会获得后量子方案。该决定不关闭现有注册表,也不适用于任何版本的 DTLS。争议主要在于旧系统迁移成本、流量检查场景与协议演进负担。
No.23
Norway became a global salmon behemoth. Now it's facing the consequences
挪威三文鱼帝国的代价
144 分
105 条评论
作者: CHB0403085482
挪威通过育种和「Project Japan」营销,把原本不受日本欢迎的生食三文鱼推成全球寿司常见食材,并将养殖三文鱼发展为仅次于石油的 180 亿美元出口产业。但开放网箱让粪便、饲料和化学残留进入峡湾,叠加气候变暖可能造成藻华、缺氧和海底生态退化。监管者和科学家担心峡湾承载力已到极限,行业游说组织则称排放影响仍有争议且处于环保限制内。文章还指出低等级「生产鱼」、疾病、寄生虫和动物福利问题随扩张加剧。
No.24
How the words we teach English language learners changed
英语学习核心词汇如何变了
213 分
158 条评论
作者: c-oreills
文章比较 1953 年「General Service List」与 2023 年「New General Service List」两套英语学习核心词表:70 年间约 600 词被移除、1100 多词加入。变化不只是技术词替换旧物件词,更体现日常生活从手工、食物、动物、身体等具体经验,转向制度、商业、科技、推理和抽象概念。作者用语义分类、具象度评分和词性分析指出,新词更难被感官锚定,也更依赖副词等限定表达。争议在于这些词表反映的是社会生活变化,还是语料选择、比例统计和教学目标造成的偏差。
No.25
Show HN: Make your Framework 12 sound like a creaky door
展示:让 Framework 12 开合时像吱呀作响的门
81 分
12 条评论
作者: arcaege
这个项目为 Framework 12 笔记本做了一个趣味声音效果:根据屏幕铰链的开合状态播放类似老木门的吱呀声。虽然原文无法抓取,但评论显示其 README 提到滤波参数还针对 Framework 12 的「铰链刚度」做了优化,这种把软件调到硬件铰链手感上的细节让社区觉得荒诞又可爱。讨论主要围绕互动性改进:不少人希望声音能随合盖速度改变音高和音量,更接近真实门轴;也有人联想到早期 MacBook、iPhone 以及 ThinkPad 传感器黑客玩法,认为这是硬件传感器被拿来做无用但有趣创意的典型例子。
No.26
The Computational Theory of Mind (2015)
心智计算理论
59 分
43 条评论
作者: cyanregiment
文章概述「心智计算理论」的核心命题:心智是否可被理解为执行计算的系统。它从图灵机与算法的形式化讲起,说明图灵模型如何捕捉机械化符号操作,并影响计算机科学与早期人工智能。AI 的进展使研究者尝试把推理、决策、问题求解、感知和语言理解等心智过程解释为计算过程。文章也指出该理论面临三项关键任务:澄清「计算」含义,证明心智以相关意义计算,并解释计算描述与神经生理描述、意向性描述之间的关系。争议集中在数字计算是否足以刻画心智,还是需要模拟、神经网络或其他非经典框架。
No.27
My personal AI benchmark: “Generate an SVG of a frog with a Habsburg jaw”
我的 AI 基准测试:画一只哈布斯堡下巴的青蛙
136 分
69 条评论
作者: thebigship
作者用一个看似荒诞但具体的提示词:让模型生成一张「带哈布斯堡下巴的青蛙」SVG,作为个人 AI 绘图与代码生成基准。页面展示多家模型的多轮 SVG 输出,并从源码注释与成品观察模型是否真正理解「下颌前突」、是否能把它和青蛙形态结合,而不是误读成王室装饰或普通卡通脸。结果显示 Claude Opus 5 等少数模型较接近要求,许多模型能画出青蛙,却难以在正面 SVG 中清楚表达特定解剖特征。这个测试的价值不在标准化评分,而在暴露 LLM 生成矢量图时对空间、结构、语义联想和视觉可验证性的局限。
No.28
Show HN: NixOS-DGX-Spark – Nix and NixOS on the DGX Spark
展示:在 DGX Spark 上运行 Nix 与 NixOS
115 分
33 条评论
作者: graham33
该项目展示如何在 NVIDIA DGX Spark 及类似小型 AI 设备上使用 Nix 和 NixOS 管理系统环境,目标是把 GPU 驱动、CUDA、AI 推理服务和部署配置纳入可复现的声明式体系。评论显示已有用户在 DGX Spark、Asus GX10 上运行,并叠加 k3s、vLLM、DeepSeek 等工作负载,认为它显著降低了维护 AI homelab 的复杂度。讨论焦点延伸到 NixOS 与 LLM 的契合:配置可验证、可回滚、无副作用,适合让 Claude Code 等工具辅助迭代。也有人补充 Jetson 应使用更匹配的 jetpack-nixos,并提到 CUDA、UMA 泄漏、远程部署和微虚拟机等周边问题。
No.29
When transit passes were designed by hand (2022)
手工设计的密尔沃基公交周票
135 分
31 条评论
作者: nate
文章介绍密尔沃基电气铁路与照明公司自 1919 年试行周票以来,如何在 1930 至 1960 年代把原本普通的通勤票做成充满色彩、手绘数字、日期 lettering、市政公告与地方历史插画的小型设计作品。Letterform Archive 现收藏约 300 张 1932 至 1969 年间票券,其中一部分来自字体设计师 Tobias Frere-Jones 捐赠。文章强调,这种持续到 1992 年才被桌面出版取代的手工制版传统,在美国市政系统中罕见,也展示了公共交通如何通过日常物件制造城市认同与视觉愉悦。作者提出,在移动支付和塑料卡趋同的今天,公共系统仍可借鉴这种系列化、周期更新的设计精神。
No.30
Cro – elegant reactive services in Raku
Cro:面向 Raku 的优雅响应式服务框架
20 分
2 条评论
作者: giancarlostoro
Cro 是一组用于在 Raku 中构建响应式分布式系统的库,主打高层 API 与异步管线模型,既能快速搭建简单 HTTP 服务,也支持更复杂的请求处理流程。它提供内置 HTTP 服务器、灵活路由、路径参数约束、静态文件服务、查询参数解析,以及可插拔的请求体解析和序列化,默认支持表单、multipart 与 JSON。Cro 还包含 HTTP 客户端、与路由集成的 WebSocket 支持,以及基于「Supply」的服务客户端。配套工具「cro stub」可生成 HTTP 与 ZeroMQ 服务骨架,「cro run」用于开发运行,「cro trace」用于追踪异步管线中的请求流转。评论区讨论很少,主要补充 Raku 与 Perl 6 的历史关系。
评论精华