2026-08-04 Hacker News Top Stories #

协作中直接转发AI长篇内容而不消化是“肉代理”行为，主张必须自己验证并以自身语言表达才算贡献。

Qwen3.8-Max发布，2.4万亿参数，在编码、研究复现等方面全面升级，能独立完成多日项目并开源权重。

JFrog发现一批针对SQLite的“严重”CVE漏洞公告是AI生成的虚假内容，提醒不能仅凭描述采信漏洞情报。

文章认为AI降低代码修改门槛，用户可通过指令fork修改开源项目，但需重构产品以适应这种流动式生态。

作者作为土耳其移民在德国感受到友善平等的文化，自认比许多德国人更德国。

OpenAI用Astra模型在数学与理论计算机科学领域取得十项新进展，并用Lean完成形式化验证。

作者坚持手动重敲AI生成代码以维持对代码库的完整理解，避免团队积累认知债务。

Isopolis是用等距像素风格绘制的旧金山互动地图，展示科技地标并允许用户提交地点。

2025年德国风能与太阳能发电首次超越化石燃料，标志能源转型里程碑，但退煤仍面临挑战。

Bonsai是Jane Street用OCaml构建的响应式Web UI库，内部广泛使用，实现前后端同类型系统。

1. 不要做肉代理 (Don’t be a meat proxy) #

https://gruhn.me/blog/2026-08-03/

作者批评了一种常见行为：在 Slack、代码评审或聊天中，直接转发 AI（如 Claude）生成的长篇回答，自己却不加消化。这种行为没有增加价值，因为对方本可以直接与 AI 对话，反而需要额外阅读冗长且可能包含“貌似合理但错误”的内容，甚至充满难懂术语。

作者主张：可以借助 AI 辅助思考，但不应机械转述输出。正确做法是主动阅读、理解并验证 AI 的结果，然后用你自己的语言重新表达——这样才能体现你的真正贡献。

针对代码评审场景，作者指出：很多人几乎不读代码，只是把任务描述和评审反馈原样粘贴给自动编程工具，再转发结果。这种情况下，真正的实施者其实是评审者（借助 AI），而操作者只是“肉代理”（meat proxy），毫无价值。

HN 热度 1669 points | 评论 677 comments | 作者：ngruhn | 16 hours ago #

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

工作中同事把 AI 生成的长篇回复直接丢给别人帮忙验证，这种行为很让人烦躁，即使是资深工程师也这样，令人无法理解。
有人用 AI 生成大量文档再让全团队人审阅，这是不负责的甩锅，浪费所有人时间，是纯粹的脑残行为。
很多平庸的工程师靠 AI 获得虚假的“你说得对”的确认，回避和真人交流，躲在 AI 内容后面。
那些只会“提示词-复制-运行-报错-粘贴”循环的开发者根本没有动脑，不理解全局，只是更慢更差的代理。
命令行 agent 把这种复制粘贴循环包装成“智能体工程”，实际上只是以牺牲理解力为代价加速重复操作。
行业一直避谈开发者技能的巨大差异，因为薪酬等级体系迫使人人都得被归入某档。
有能力的开发者清楚提示词的局限，LLM 在多线程应用上很烂，手写核心逻辑才可靠。
做浏览器视频编辑器时遇到了 AI 无法解决的瓶颈，不得不重新深入代码。
LLM 只适合有大量训练数据的典型 Next.js 应用，写 Rust 这类语言容易产出能编译但不优的代码。
如果懂行且谨慎，LLM 生成的 Rust 很惊人，因为它编译严格，能编译基本就没有内存问题。
有的人工作变成了“AI 报错-粘贴-运行-等待-继续”，这就是现在的日常。
糟糕的是技术好的人也这样，工作从有趣的高技能劳动变成了脑残的苦力活，让人沮丧又难以跳出。
也有人觉得转型 AI 驱动开发很好玩，只要组织允许失败，就能学着更好地驾驭 AI，把精力放到产品和系统层面，实现新技能的提升。
写代码的乐趣消失了，过去那种精巧的递归代码不会再写了，不知道明年软件开发会变成什么样。
当前 AI 带来的效率提升被高责任感的人承担了所有剩余工作，造成对这群人的变相剥削，QoL 下降大于产出提升。
AI 让高技能劳动者也沦为被压榨对象，可能加剧不平等，形成永久下等阶层。
对刚入行的年轻开发者感到担忧，未来可能很艰难。
如果对现状不满，不要被高薪绑架，要主动做出改变。

2. Qwen3.8-Max：编程与协作的新标杆 (Qwen3.8-Max: A New Bar for Coding and Cowork) #

https://qwen.ai/blog?id=qwen3.8

今天，我们正式发布了 Qwen 3.8-Max，这是迄今为止 Qwen 系列中最强大的模型。这也是我们首次开源 Qwen-Max 类模型的权重，相关权重将在下周发布。Qwen 3.8-Max 基于 Qwen 3.5 的架构，参数扩展至 2.4 万亿，在编码、工作、研究和长时间任务方面提供了全面的改进。它不仅能够回答更具挑战性的问题，还能更可靠地完成复杂的任务，生成可靠的成果。

在编码方面，Qwen 3.8-Max 的能力远超简单的函数请求，它能够从空文件夹开始，独立完成真实的多日项目。我们对其进行了三项挑战测试，Qwen 3.8-Max 在没有人类干预的情况下，通过反馈循环自我演变，成功完成了所有任务。其中一个案例是构建了一个自我进化的工具（oh-my-cli 项目），该工具在超过 10 天的自主编码过程中，通过用户反馈和社区实践，不断迭代完善。Qwen 3.8-Max 在 GitHub 上公开了整个项目的跟踪记录。

在研究复现方面，我们让 Qwen 3.8-Max 复现了一篇名为 “统一数据选择以进行 LLM 推理” 的研究论文。它从头开始设计和编写数据处理脚本、训练代码和评估设置，完成了约 7600 行代码，并进行了 33 轮 GPU 训练。最终，Qwen 38-Max 不仅复现了论文的实验结果，还在此基础上进行了改进，提出了 18 个改进思路。

我们还将 Qwen 3.8-Max 投入了真实的在线竞赛中。在 WWW2025 多模态对话意图识别挑战中，它在 24 小时内独立完成了全套解决方案，使用了多种语言模型和视觉语言模型，最终击败了 87% 的参赛人类团队。

在工作方面，Qwen 3.8-Max 的能力表现也十分出色。它在多个高经济价值的职业中表现出色，例如在公司合规审查中，能在一个小时内完成对数百份文件的审查，通常需要一周的时间。而在 UI/UX 设计方面，它能一次性生成高保真交互原型，而不需要人类的修订。此外，Qwen 3.8-Max 还在餐饮业、结构工程、康复治疗等多个领域展现了其工作能力，显著提升了人类的工作效率。

Qwen 3.8-Max 的动态工作流功能使其能够编排大规模的子代理系统，从而实现复杂的任务规划和执行。它在量化研究方面的能力也引人注目，能够并行化处理广泛的研究方向，将传统的数周工作压缩至单次会话内完成。

综上所述，Qwen 3.8-Max 通过其强大的编码、研究、工作能力和动态工作流，展示了在长时间任务上的潜力，标志着人工智能在各个领域应用的进一步深化。

HN 热度 1041 points | 评论 557 comments | 作者：ai2027 | 20 hours ago #

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

Qwen3.8-27B 即将以开源权重发布，如果它能继承 Qwen3.6 系列的优势将很有价值。
Qwen3.6-35B 是出色的本地模型，足以让用户取消 Claude 订阅，并用于日常代码修复。
Qwen3.6-35B-A3B 帮助团队转向 agent 优先的编码方式，连原本怀疑 AI 的成员也被说服。
本地模型适合批量非代码任务（如文件整理、数据比较），数据不出门且成本仅为电费。
本地模型可用于知识库管理、票据分类、代码库搜索总结和初步 bug 根因分析，对个人文档处理（如医疗记录、OCR）也有效。
本地模型在代码编写方面效果不佳，复杂编程任务仍依赖托管 API。
本地模型入门容易、零承诺，不想要可以直接删除。
实际上本地模型需要硬件投入，还要花时间选择工具和量化版本，配置上下文窗口等，并非零成本。
A3B 模型虽然速度快，但容易绕圈子，可能忽略指令，任务完成效率反而不如 27B。
反 AI 的人却愿意自己托管模型，显得有点矛盾。

3. SQLite 严重 CVE 还是 LLM 垃圾？ (SQLite Critical CVEs or LLM Slop?) #

https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/

JFrog 安全研究人员发现，一批针对 SQLite 的“严重”CVE 漏洞公告极有可能是由 AI 生成的“LLM slop”（低质虚假内容）。这些公告来自一个新创建的 GitHub 仓库，并被 NVD 标记为严重级别。

经核查，这些漏洞描述存在多处硬伤：引用的函数在目标版本中根本不存在，PoC 无法触发崩溃，修复补丁无处可寻，且均未出现在 SQLite 官方公告中。例如，CVE-2026-51302 提到的函数在 3.41 版本中尚未引入；CVE-2026-51303 声称的修复版本差异中并无相关改动；CVE-2026-51296 引用的行号甚至超出了源文件总长度。

研究人员在隔离环境中用 ASan 编译了官方 SQLite 并执行 PoC，均未复现任何内存错误。这些虚假 CVE 之所以能通过审核，是因为 MITRE 提交系统缺乏身份验证，而 NVD 自 2024 年 2 月起因报告激增暂停了深度人工分析，导致伪造公告钻了空子。此次事件再次敲响警钟：当前漏洞生态中，仅凭“看起来合理”的描述已不足以采信。

HN 热度 688 points | 评论 340 comments | 作者：ymir_e | 11 hours ago #

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

LLM 本质是概率性文本预测工具，并非真正智能，把代码注释误判为漏洞，其产出必须经人类全面核验，否则代价巨大。
大量缺乏真实技能的人借 LLM 热潮自我包装，在 AI 初创公司或 LinkedIn 上靠吹嘘谋取职位。
众多经理、主管正伪装成工程师，工程领域出现普遍的“角色扮演”现象。
软件工程师常对产品、设计、教育、经济学等领域抱有不应有的傲慢，但这些领域自有其专业复杂性。
业余者在网上争论非专业话题无伤大雅，但在专业和工作场景中必须保持严谨。
无技术背景的人做创业并非新现象，但过去精致的界面往往意味着工程质量，如今 AI 生成的“精致”产品内部却空洞易碎。
只要真能胜任角色，跨界背景并不是问题，关键在于能力和结果。
政府决策已开始依赖未经专家验证的 AI 生成代码，使错误代价变得极高。
LinkedIn 本是自我推销平台，LLM 加剧了这种风气，人们每天发布长篇大论式 AI 内容。
将思考外包给 AI 的人，往往也正是不会去验证其输出正确性的人。
软件行业应引入执照与监管体系，以约束 LLM 滥用带来的不负责任行为。
长期接触 AI 模型的无意义输出可能带来心理影响，但这一点尚未得到足够关注。

4. 开发工具必须开源 (Devtools must be open source) #

https://blog.exe.dev/devtools-must-be-open-source

这篇文章讨论了 AI 代理时代下，软件开发个性化方式的根本转变。作者认为，过去为个人定制软件成本高昂，如今借助 AI 代理，只需简单指令即可下载源码、本地构建并自动同步上游更新，使得持续维护个人修改变得容易。文章以作者的个人项目 meat.dev 为例，展示了如何通过一条提示词将其集成到 Shelley 代理中，实现自动预处理代码审查。核心观点是：AI 代理降低了定制软件的门槛，传统软件依赖配置文件和插件系统的模式将被“直接修改源码”取代，许多软件产品类别需要为此重新设计。

HN 热度 451 points | 评论 163 comments | 作者：bryanmikaelian | 8 hours ago #

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

大语言模型让开源代码的阅读、理解和修改门槛大幅降低，也便于作为开发参考
理想的软件生态应是可流动的，用户能编写个人修改并基于他人作品构建
但自己 fork 并修改软件后，跟上上游更新和维护很困难
大语言模型可能通过生成非派生作品的方式规避开源许可证，成为“版权洗钱”工具
开源项目需要可持续商业模式，不能靠融资免费送后再撤下
跨云资源管理可用 Terraform Provider 或 Kubernetes API 等标准抽象层，避免厂商锁定并实现自动配置
沙盒平台对底层虚拟化有特定需求，如 Firecracker 与快速 fork 完整环境的能力
计划构建统一协议/市场，涵盖资源、支付和身份，但去中心化共享仍存在安全风险

5. 比许多德国人更德国 (More German than many Germans) #

https://mertbulan.com/more-german-than-many-germans/

作者是来自土耳其的计算机专业学生，2017 年通过 Erasmus 奖学金到德国汉堡实习，原计划只是为毕业后求职积累经验，但这段经历彻底改变了他的人生。

初到德国时，他打破了此前对德国人的刻板印象。他的德国室友友善耐心，对他表现出极大的信任；工作团队友好热情，带他参与团队活动，给他超出普通实习生的责任。整个夏天成为他人生中最美好的时光，公司也直接给了他全职工作邀请。

2018 年毕业后，他正式搬到汉堡工作生活。从注册住址时工作人员的一句“欢迎回来”，到同事们帮他找房、解决电费问题、搬家，他感受到家一般的温暖。德国职场文化也让他印象深刻：管理层平易近人，同事关系平等，尊重每个人的饮食需求，强调休息和信任。

他注意到德国社会阶层差异小，建筑工人和白领在同等价位的餐厅用餐，富人区物价也与其他区域相差无几，这让他感受到社会民主的真实存在。

在工作中，他没有感受到移民歧视，反而当选为工会委员中得票最高的人。他也提到拥有土耳其血统的政界人物在德国身居高位，进一步印证了德国社会的包容与平等。

最终他得出结论：现在的他“比许多德国人还要德国”，这段经历让他选择留在这个国家，并真正认同了这里的社会价值。

HN 热度 364 points | 评论 303 comments | 作者：mertbio | 17 hours ago #

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

生活在德国已经四分之一的时间，感到融入了这个国家。
尽管肤色可能导致他人对其持有偏见，但他并不在意，遵循规则是他的一种生活方式。
对比其他国家，他认为德国的生活质量相对较高。
移民后的生活经历使他更加欣赏德国的稳定和舒适。
许多德国人抱怨社会状况，有人选择离开国家。
生活在富裕国家的体验与生活在贫穷国家截然不同，后者的问题更加严峻。
个体在改变根深蒂固的文化时能力有限，移民是更好的选择。
对于家乡的复杂情况，个体的努力很难产生显著影响。
有些人认为德国的高税收和日益繁琐的官僚主义令人沮丧。
不同地区的移民体验差异很大，环境对个人经历有重要影响。
德国人对当前的社会问题感到失望，许多问题源于政策和政治决策的失败。
生活在德国家的整洁和基础设施良好是让人欣赏的优点。
归属的缺失使一些人即使在德国也感到以融入。
人们在讨论德国和其他国家的优劣时，常常受限于个人的生活经历。

6. 数学与理论计算机科学的十项进展 (Ten advances in mathematics and theoretical computer science) #

https://openai.com/index/ten-advances-in-mathematics/

OpenAI 发布了一项重要成果：在数学与理论计算机科学领域取得了十项新进展，均由内部版 Astra 模型生成，并用 Lean 形式化验证，人类参与整理成论文。这些结果解决或大幅推进了多个长期未决的公开问题，涵盖高维几何、编码理论、电路复杂度、群论、算子代数、量子复杂度、格密码和极值组合等方向。

这十项成果包括：高维球堆积的新上界；二进制码和球面码最大尺寸的指数级改进；非 sofic 群存在性的构造证明；推翻了 Connes 刚性猜想；永久项计算的算术电路下界；量子二人博弈的指数并行重复定理；最近向量问题多项式因子不可近似；Ehrhart 体积猜想各维度下的完整解答；multicolor Ramsey 数的超指数下界；以及极值图论中紧致性与退化性猜想的进展。

OpenAI 同时宣布为十万名科学家和数学家提供免费 ChatGPT 使用权限，并强调会诚实标注 AI 在研究中的贡献，希望数学社区深入审视和推进这些结果。

HN 热度 360 points | 评论 649 comments | 作者：milkshakes | 6 hours ago #

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

技术发展可能是指数级的，但目前更可能是 S 形曲线，在停滞信号出现前假设指数更合理。
有观点认为不应高估 S 形曲线，但该观点来自对全能 AI 有准宗教信念的理性主义者，未必可靠。
用 S 形曲率预测 AI 天花板属于循环论证，没人能准确判断拐点何时到来。
LLM 将实现大规模个性化操纵，美国右翼会利用它赢得选举，左翼则因道德立场而失败。
个性化操纵并非 LLM 首创，定向广告和大数据早已做到，LLM 只是增强了能力。
所有政治群体都会追求最大限度的操纵，未来更可能走向“分而治之”的策略。
AI 证明数学定理类似于四色定理的计算机辅助证明，通过暴力计算实现，但可能存在能力极限。
OpenAI 展示的数学成果依赖大量计算和回滚，只是堆算力，并未证明模型能力呈指数增长。
前沿实验室热衷纯数学是因为结果易于验证，适合训练模型；也有人认为数学是 LLM 最自然的应用场景。
当前模型的成果依赖推理时的大量计算，订阅用户可用的算力远不及实验环境，未来可能因时间成本过高而遇到平台期。

7. 不要直接复制粘贴 LLM 生成的代码，而是手动敲一遍，以防留下认知债务。(Prevent cognitive debt by manually retyping LLM-generated code) #

https://ankursethi.com/blog/prevent-cognitive-debt-by-manually-retyping-llm-generated-code/

作者在自己的个人项目中仍使用 AI 编码助手，但不再允许它直接修改代码。他发现自己无法理解 AI 生成的代码，也不想审查那些冗长且质量可疑的 AI 输出，于是采取了一种“低效但清醒”的方法：让编码助手把建议的代码和命令显示在聊天窗口里，由他手动输入到项目文件中。

他在代理配置中加入了明确指令：不得创建、编辑或删除文件，也不得运行修改项目的命令，只能展示建议。这样他虽然只达到两倍开发速度，但每行代码都过了一遍大脑，能及时察觉幻觉或糟糕设计，并顺手重构、注释，形成对代码库的完整空间认知。

作者类比年轻时学习编程的“手动抄写”方式，认为这是在 AI 时代保持理解力的工作流。他担心整个软件行业正积累认知债务，而他至少要确保自己发布的软件是真正理解的。

HN 热度 351 points | 评论 291 comments | 作者：mpweiher | 13 hours ago #

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

依赖 LLM 生成代码替代主动思考会破坏学习过程，导致认知债务。
LLM 可能用已掌握的技能以新方式组合，产生程序员无法理解的涌现行为。
技能需要持续从头练习，否则会逐渐生锈，如管理者疏于编码后能力退化。
手动重打代码能促使程序员更谨慎，避免 LLM 生成大量冗余代码。
逐字输入代码示例对学习有实际帮助，是一种有效的学习方式。
手动输入教程代码比直接复制粘贴更能加深理解和记忆。
手写过程强迫人关注细节，类似记笔记能让思维保持专注。
可以先自己编写代码，再让 LLM 提供优化方案，这样学习效果更好。
重打代码并非完全无用，但相比主动解决问题等练习，效率较低。
记笔记或重打代码可保留知识，便于日后重新掌握技能。
听课或讲座时记笔记效果有限，真正的学习靠练习和用自己的话总结。
有时讲师会讲笔记之外的内容，这些内容可能在考试中重点考察。

8. Show HN：Isopolis – 旧金山等距像素地图 (Show HN: Isopolis – Isometric pixel map of SF) #

https://sf.isopolis.city/

Isopolis 是一个以等距风格绘制的旧金山互动地图网站，融合了硅谷文化与城市导览功能。页面支持浏览街区、地标、公司（如 Airbnb、Anthropic、OpenAI、Y Combinator 等），并提供了多条特色旅行路线，包括经典旧金山入门游、初创公司主题游、Twitter 现实游和徒步挑战游。用户可在地图上查看事件、标记地点，并通过社区贡献功能提交新地点（需填写名称、类型、坐标、说明等）。网站还播放类似“硅谷主题”的背景音乐，设计风格致敬 isometric.nyc，由 Nuwan Davek 创建，描述文本部分由 AI 生成。

HN 热度 330 points | 评论 74 comments | 作者：nuwandavek | 22 hours ago #

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

这个项目的幕后工作很有意思，使用了美国政府的免费 LIDAR 数据。
生成图像的过程充满了手动尝试和错误，但最终达到了较好的风格一致性。
有人觉得尽管初看很迷人，但细看后会感到生成图像缺乏灵魂。
部分评论认为文案写得太乏味，让人难以产生共鸣。
有网友提到生成的城市看起来有些过于平坦，缺乏真实的高度感。
一些人发现生成的地图中存在一些明显的错误，如把道路变成了湖泊。
该项目给人以《模拟城市 2000》的感觉，能够点击地区获取更多信息。
有评论者对项目的执行质量表示失望，认为需要更多打磨和细致的工作。
也有不少人对这个项目表示欣赏，认为它很有趣并唤起了对旧金山的美好回忆。
最后，有人对分享使用 AI 生成的图像的法律问题表示关注。

9. 德国风电和太阳能发电量首次超过化石燃料 (Wind and solar overtake fossil fuels in Germany for the first time) #

https://www.intellinews.com/wind-and-solar-overtake-fossil-fuels-in-germany-for-the-first-time-ever-458379/

2025 年，德国的风能和太阳能发电首次超过化石燃料，标志着一个重要的里程碑。根据 Carbon Brief 对《世界能源统计回顾》数据的分析，风能和太阳能合计发电量达到 225 太瓦时（TWh），占总发电量的 44%，而化石燃料的发电量为 217 TWh，占 43%。这一变化反映出德国在 “能源转型”（Energiewende）战略下，经过 20 年的快速增长，正逐步摆脱煤炭和核能。

德国的目标是到 2030 年安装 115 吉瓦（GW）的陆上风能，并在 2025 年批准了 20800 兆瓦的新装机容量。官方目标要求到 2045 年实现经济全面净零排放，到 2030 年电力消费中可再生能源占比达到 80%，并希望到 2035 年基本实现气候中性电力系统。

由于核能的逐步淘汰，德国在实现这些目标时比邻国如法国和英国更依赖可再生能源。核能的淘汰是 “能源转型” 的核心内容，管最近有政治上的反对声音，但这一政策依然得到广泛认可。今年早些时候，右翼中间派总理弗里德里希・梅尔茨称核能淘汰是一个 “战略错误”，但他的政府排除了恢复传统核能的可能性。

煤炭依然是德国面临的更大短期挑战。德国的煤炭使用量仍远高于大多数其他欧洲国家，官方的煤炭淘汰截止日期为 “最迟在” 2038 年。然而，专家认为，德国在淘汰煤炭方面的进展可能会在这一日期之前几年完成，尽管在近期能源危机期间出现了放慢转型的压力。

当前，可再生能源面临另一种反对声音，来自于右翼政党 “德国选择党”（AfD）。与此同时，现任联盟政府也在推进新燃气发电厂的建设，这些发电厂被立法视为过渡技术，计划到 2045 年转换为绿色氢气发电，以保持与气候中立目标的一致性。尽管几乎没有其他声音主张完全放弃煤炭淘汰，但政府预计将在 8 月发布对其时间表的审查，这将是考验柏林是否坚定支持转型政策的下一个重要时刻。

HN 热度 327 points | 评论 258 comments | 作者：just_some_user | 9 hours ago #

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

德国的风能和太阳能在 2025 年首次超过化石燃料的年发电量，这是一个重要的指标。
各种数据指标的使用让人感觉有点像不断变更的目标，然而趋势向好是值得肯定的。
德国的工业在减产和裁员，主要原因是能源成本高昂。
减少对俄罗斯天然气的依赖导致了德国能源价格上涨，但可再生能源被视为解决方案。
政治决策和地缘政治局势对德国能源政策的影响至关重要。
德国在俄乌冲突中的立场导致了能源供应的紧张和逐步减少对俄气的依赖。
各种假设的讨论并不能改变实际发生的事件及其后果。
俄罗斯在能源供应上的行为被认为是战略上的操控，尤其是在战争期间。
德国的核能政策与其能源安全和价格波动有直接关系。
尽管面临挑战，德国仍被视为一个生活质量高的国家，工作文化相对稳定。
德国的经济状况与再生能源承诺并直接因果关系。
英国的能源价格受气体成本影响显著，但可再生能源的发电成本正在逐下降。

10. Bonsai：Jane Street 的 UI 库 (Bonsai: Janestreet’s UI Library) #

https://github.com/janestreet/bonsai

Bonsai 是一个用 OCaml 构建高性能响应式 Web 应用的 UI 库，部分灵感来自 Elm，被 Jane Street 内部几乎所有 Web 应用广泛使用。

组件采用纯函数式状态机实现，易于组合；框架内部的增量机制确保仅在相关状态变化时才重新计算，适用于所有值，而不只是视图。

Bonsai 将状态、增量性和渲染解耦，可按需组合；状态管理不绑定具体组件，支持复杂的生命周期和局部状态托管。同时，使用 OCaml 可实现前后端共享类型和业务逻辑，增强代码可维护性。

它还提供强大的模板语言、组件级样式表，以及自动化测试系统，可通过编程操作 UI 元素并观察 DOM 变化，编写表达力强的期望测试。

HN 热度 282 points | 评论 110 comments | 作者：KolmogorovComp | 14 hours ago #

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

有评论为 Bonsai 用 OCaml 实现前后端同语言同类型而欢呼，但也有人指出这种可能性早已存在，且已有多种实现。
类似尝试包括 Fable、Scala.js、Kotlin/Clojure 以及 Ocsigen、WebSharper 等，但难点在于与成熟 JS 生态整合，最终常变成“前端当后端”而非“后端当前端”。
有评论推荐 Elixir/Phoenix LiveView，认为其类型系统和全栈体验很好。
有评论表示宁可从头学 OCaml 也不愿用 JS，虽是玩笑但反映对 JS 的厌倦。
关于 TypeScript：TS 也需编译成 JS，不能直接在浏览器运行；但社区支持和类型定义更完善；枚举、命名空间等构造需要实际编译，如今多被视为错误并可用–erasableSyntaxOnly 避免，因此多数 TS 可视为纯 JS 加类型注解。
关于 WASM：有评论希望 WASM 一劳永逸，但当前它无法直接访问 DOM/Web API，需 JS 互操作且有性能开销，对简单任务代码体积也更大，更适合重负载场景。
针对 Bonsai 本身：有评论指出 README 中的文档链接失效；好奇其 DOM 更新方式；播客中称其本质是构建增量、可组合的分布式状态机框架。
其他零散观点：Jane Street 有自建一切的习惯；现代 Web 开发像炼金术；多数人接触 CS 从建网页开始，所以 JS 很流行。

Hacker News 精彩评论及翻译 #

Don’t be a meat proxy #

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

I deal with this all day long at work and it’s exhausting. People almost acting like no one has thought of it “I asked Claude what happened, and it spit out this 300 line response. Can you read it for me and see if it’s right?”

What kills me is you might expect this from a busy high level manager that doesn’t really understand the technical details and they just point the AI to an error they got. They don’t know how to interpret the response, so they ask someone who work on the thing. It’s still kinds annoying because you could just ask, but whatever. But to get these from junior and senior engineer for the areas they work in and expect someone else to read it for them? It’s crazy behavior. How can someone serious even think that’s ok.

eddythompson80

我整天在工作中处理这种事，简直累死了。人们表现得好像没人想到过似的——“我问了Claude发生了什么，它吐出了一段300行的回复。你能帮我看一下对不对吗？”

最让我崩溃的是，你也许以为这种事儿只会发生在那些不了解技术细节的忙碌高管身上，他们只是把遇到的错误丢给AI，不知道怎么解读回复，就去找懂行的人问。这虽然也挺烦人的，因为你本来可以直接问，但算了。可是，如果是初级甚至高级工程师在自己负责的领域里也这样，还指望别人替他们读回复？这简直疯了。一个认真做事的人怎么能觉得这样没问题？

Qwen3.8-Max: A New Bar for Coding and Cowork #

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

They’ve also announced Qwen3.8-27B being released open-weight next week. Qwen3.6-27B is widely regarded as one of the best local models, especially since nothing else comes close to it, that isn’t benchmaxxed, without being significantly larger. If 3.8 truly improves upon it that would be awesome.

toshinoriyagi

他们还宣布下周将开源发布Qwen3.8-27B的权重。Qwen3.6-27B被广泛认为是最好的本地模型之一，尤其是因为其他接近它的模型，要么是跑分特化型，要么体积明显更大。如果3.8真的能在此基础上有所改进，那将非常棒。

Don’t be a meat proxy #

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

At my dayjob there is a person spearheading ai across the enterprise.

They generated lots of documentation across the whole stack and now makes all PO/BAs read it if it’s correct. So not just 300 lines - he unironically generated thousands of lines of “documentation” and is now making hundreds of people review it for him

Complete brainrot

Au psychosis is getting seriously outrageous at this point

Thankfully I’m a dev and thus aren’t in the blast radius of that genius idea

ffsm8

在我的日常工作里，有个人正在全公司牵头推行AI。
他生成了涵盖整个技术栈的大量文档，现在让所有产品经理和业务分析师去读，检查是否准确。所以不只是三百行——他真就搞出了几千行的“文档”，然后让几百号人替他审阅。
完全是脑残行为。
到这一步，Au 精神病真是越来越离谱了。
还好我是开发人员，所以不在那个天才主意的影响范围内。

The myth of Snow Leopard #

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

Oh, this again. I should put a website with this up…

I was the person who personally ran 10.6 security updates at Apple (10.6.1+), the “DRI”. My team in the Updates Program office and I reviewed every single bug to determine if it should go in a security and stability update or wait for the next major version. Seriously, every morning we group triaged all Mac OS X bugs, both incoming and those nominated internally for us to look at and determine if it should go in an update. I packaged and audited the builds and tuned the delta vs full updates. I built the system that largely automated diffing “trains” for software updates (automastering).

The new version of the OS was always being developed in a branch/train, and fixes were backported to the current version as they were found. They weren’t developed linearly / one after another. So, if you are comparing the most stable polished/fixed/stagnant last major version with the brand new 1.0 major version branch, the newer major is going to be buggier. That would be the case with every y.0 vs x.8. But if you are comparing major OS versions, Snow Leopard was different.

Snow Leopard’s stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don’t believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up “here is what we are planning to ship” and in Snow Leopard it was top down “can we ship this?”.

AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs.

The first .1 or .2 ALWAYS fixed critical bugs, because:

You had to GM / freeze the software to physically create the CDs/DVDs around a month before the release. Bugs found after this process required a repress (can’t remember the phrase we used), which cost money and time and scrambled effort at the last minute and added risk. This means the bar was super high, and most “bad, but not can’t use your computer bad” bugs were put in software updates…which was developed concurrently with the end of the main release (hence why .1 came out right away)
Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn’t even the complete OS that was being tested.

Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.

LegNeato

哦，又是这个。我真该搞个网站来放这个……

我就是当年在苹果负责10.6安全更新（10.6.1+）的"直接责任人"（DRI）。我和更新项目办公室的团队每天审查每一个bug，判断它应该放进安全与稳定性更新，还是等到下一个大版本再修。说真的，每天早晨我们都会对所有的Mac OS X bug进行分组分类，不管是新提交的，还是内部提名让我们评估是否应该加入更新的。我负责打包和审核构建，调整增量更新与完整更新的比例。我还构建了一套系统，大幅自动化了软件更新的差异对比"列车"（自动母版制作）。

新版本的OS总是通过分支/列车方式并行开发的，发现修复后会反向移植到当前版本。它们并不是线性逐个开发的。所以，如果你拿最稳定、打磨完善、修复停滞的最后一个大版本，与全新推出的1.0大版本分支相比，新的大版本当然bug更多。每个y.0版本相对于之前的x.8版本都是如此。但如果你比较的是大版本之间，雪豹确实不一样。

雪豹的内部目标明确标榜为减少bug、提升质量。这是事实，不是营销。我不明白为什么网上有些人就是不信，但我当时就在那里。你想加入一个功能，必须获得领导层的明确批准，门槛非常高。在正常的特性版本中，运作方式是自下而上的"这是我们计划要发布的"，而雪豹是自上而下的"我们可以发布这个吗？"

据我所知，雪豹是第一个这种类型的版本（我参与的第一个版本是Jaguar或Puma），它直接回应了10.5需要8个软件更新才能稳定下来、以及那个周期中发现bug的严重性和随之而来的负面报道。Leopard是一个超大的特性版本，随之而来的是大量（糟糕的）bug。

第一个.1或.2版本总是会修复关键bug，因为：

你必须在大约发布前一个月完成GM/冻结软件，以便物理生产CD/DVD。在此之后发现的bug需要重新压制（我不记得我们用的术语了），这既费钱又费时间，还会在最后一刻打乱工作节奏并增加风险。这意味着门槛非常高，大部分"糟糕但还不至于让电脑没法用"的bug被放进了软件更新……而软件更新是与主版本发布末期同时开发的（所以.1很快就能出来）。
测试基本上要靠工程师、内部QA、一些战略合作伙伴（比如Adobe和微软），还有苹果种子计划（规模很小）。自动化测试极少。苹果员工并不能代表全体用户，QA覆盖率也从来不是百分之百。而且有时候我们担心泄露，会在种子发布中推迟某些特性，所以测试的甚至都不是完整的操作系统。

软件更新总是需要的，不过随着种子（也就是测试版）规模扩大、恢复分区出现以及更好/更现代的开发实践，它们修复的问题严重程度随时间降低了。但我可以明确告诉你一个事实：雪豹在整个生命周期中重大bug更少，稳定得非常快，并且在Lion发布时已经极其稳固。

SQLite Critical CVEs or LLM Slop? #

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

We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are.

LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credibility massively when your LLM-based “AI” gets the probabilities wrong at best, or in this case, claims a line of code generates a vulnerability when it is, in fact, a code comment.

LLMs are text-prediction engines. They are not Artificial Intelligence, and shouldn’t not be treated in any form or fashion as if they possess intelligence. What bothers me about this entire situation is that presumably the folks that relied on the LLM-based “AI” to generate these vulnerabilities knew (or should have known) enough about their tool to know this would happen, but did not.

Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity from teams that have to deal with the resulting fall-out of this usage of “AI”.

A human must verify everything an LLM presents as fact. Everything. If you don’t, we all pay the price. LLMs do not remove the onus of responsibility on the human being, if anything they amplify it because LLMs can generate lots more output more quickly that needs to be verified than humans can.

gortok

我们可以把这件事归为另一个例子，说明人们认为LLM能完成的事情与实际能力之间存在过度乐观的差距。

基于LLM的“AI”能够利用其庞大的输入语料库，计算在特定情境下最可能统计出现的输出。它是概率性的，而当你在处理需要确定性而非概率的情况时——就像这次，基于LLM的“AI”最多只是在概率上出了错，或者像本例中，它声称一行代码产生了漏洞，而实际上那只是一行代码注释——那么你的可信度就会遭受重创。

LLM是文本预测引擎，它们不是人工智能，绝不应以任何形式被当作拥有智能来对待。整件事让我感到不安的是，那些依赖基于LLM的“AI”来生成这些漏洞的人，本该（或应该）对自己的工具有足够了解，预见到这种情况会发生，但他们却没有。

现在，所有人都要为此付出代价——从那些不得不处理这种“AI”使用后果的团队所浪费的生产力来看，损失高达数十万甚至数百万美元。

人类必须核实LLM呈现为事实的一切信息。一切。如果你不这样做，我们所有人都会付出代价。LLM并没有减轻人类应承担的责任，反而放大了它，因为LLM能比人类更快地生成大量需要验证的输出。

Devtools must be open source #

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

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works.

The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can’t justify the time commitment needed to read and then modify the code for tools they use very often.

I think LLMs have changed that equation in a way that makes the original dream much more feasible.

Several times a day I’ll prompt regular Claude chat to “Clone x/y from GitHub and tell me how Z works”.

Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn’t bother. Now I treat that as a zero time investment challenge: tell Codex or Claude Code to checkout and build X and then come back ten minutes later and see how it got on.

I’m not habitually modifying the software I use yet, but I can see a path to that which didn’t exist a year or so ago.

simonw

开源软件对终端用户的一个论据一直是：可以自由地检查并修改软件的工作方式。

但对大多数人——甚至包括专家级程序员——而言，这种自由实际上更多是能够依赖他人来完成这些工作。大多数人无法证明花时间阅读并修改他们经常使用的工具代码是值得的。

我认为大语言模型改变了这一局面，使得最初的理想变得可行得多。

每天我会好几次让普通的Claude对话“从GitHub克隆x/y并告诉我Z是如何工作的”。

要让软件能够编译以便开始修改代码，过去这往往是一个麻烦到让我经常懒得去做的步骤。现在我把这当作一个零时间投入的挑战：让Codex或Claude Code检出并构建X，然后十分钟后回来看看它进展如何。

我还没有养成习惯性地修改我所用软件的习惯，但我能看到一条通向这种习惯的路径——而这条路在一年前左右还不存在。

Don’t be a meat proxy #

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

On social media, I saw the much more vulgar

“Learned engineering just to become the condom between Claude Code and prod”

And that (re)framing helped as well to think about the “what are we even (left) doing” as an industry

gregsadetsky

在社交媒体上，我看到更粗俗的说法：“学了工程学，结果只是成了Claude Code和生产环境之间的避孕套。”而那个（重新）框架也帮助思考“我们这个行业到底（还）在做什么”。

Prevent cognitive debt by manually retyping LLM-ge… #

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

Big no for retyping llm generated code by hand.

But a big yes for still typing code by hand, and not leaving it to the llm. Except it has to be the code generated by your brain.

That is what will create new neurons and new connections, which is what will keep away the cognitive decline.

And the constraint of not having to use llms will enhance creativity.

Actually, the constraints llms add to your code are more in number than the former. llms code in only the specific ways they’ve been trained on. So you won’t ever come across of other ways.

Off the top of my head.. here’s RubyQuiz.com [0] which I came across when I was learning ruby more than a decade ago. Looking at the many user-submitted solutions (you have to download the zip file!) you’ll see completely different ways the problems were solved.

Sure, many won’t be deemed efficient or standard by today’s llm or rubocop checks, but looking at their code.. and retyping them and seeing them work.. was crucial in how I was able to think in Ruby for solving coding problems.

I did the same with Go too, with the “learn go with tests” guide [1].

[0] - http://rubyquiz.com/

[1] - https://quii.gitbook.io/learn-go-with-tests

npras1

强烈反对手动重新输入LLM生成的代码。

但强烈赞成仍然手动输入代码，而不是把它交给LLM。只不过这些代码必须是由你的大脑生成的。

这样才能创造出新的神经元和新的连接，从而延缓认知衰退。

而且不必使用LLM这一限制会增强创造力。

实际上，LLM给你的代码增加的限制比前者更多。LLM只会按照它们被训练过的特定方式编写代码。所以你永远无法接触到其他方法。

凭记忆想到……这里有个RubyQuiz.com[0]，是我十多年前学Ruby时遇到的。看看那些用户提交的众多解决方案（你需要下载zip文件！），你会看到人们用完全不同的方式解决这些问题。

当然，很多方案在今天被LLM或Rubocop检查时可能不被认为是高效或标准的，但看看它们的代码……然后重新输入它们，看着它们运行……这些对于我能够用Ruby思维解决编程问题至关重要。

我对Go也做了同样的事情，用的是"learn go with tests"指南[1]。

[0] - http://rubyquiz.com/

[1] - https://quii.gitbook.io/learn-go-with-tests

Taylor Farms has rewritten its cyclospora statemen… #

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

The CDC Has a Cyclospora Lab. DOGE Downsized It Last Year [1]

[1] https://www.wired.com/story/cdc-cyclospora-lab-doge-downsized-it-last-year/

wnevets

美国疾控中心有一个环孢子虫实验室。去年DOGE将其规模缩减了[1]

Why Book Corners won’t sync contributions back to … #

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

In summary: Because OSM requires work and care to be put into the data submission plan, which isn’t worth it.

A project like OSM would be bombarded with spam and junk submissions if it didn’t have these barriers to submission. Understandable.

Aurornis

总结：因为OSM要求提交数据计划时投入大量精力和细心，而这并不值得。

像OSM这样的项目，如果没有这些提交门槛，就会被垃圾信息和无用提交所淹没。这可以理解。

Note-Taking and Personal Knowledge Management #

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

Asking “what have note-taking apps accomplished?” is like asking “what have spreadsheets accomplished?” or “what have cameras accomplished?”. A tool doesn’t accomplish anything on its own. A tool is a means to an end.

A few days ago, someone jokingly asked if Henry Ford had a personal knowledge base in Obsidian… Well, sort of! He had something he called “jot books”, where he journaled, kept notes, grocery lists, etc. Not dissimilar to how people use Obsidian. The Henry Ford Museum has fifty of these notebooks: https://www.thehenryford.org/search?Query=%22jot+book%22

How should we quantify the impact of Henry Ford’s notebooks? How should we quantify the impact of spreadsheets?

Most people who accomplish anything take notes in some form, because writing is a way of thinking. We love to mythologize the tools and methods of accomplished people because we hope it will let us absorb a bit of their genius. But a good camera doesn’t make a good photographer. Taking lots of photos helps.

Should you take notes? Probably. Does it matter what your method is? Probably not. Whatever works for you. Obsidian (or any other form of notetaking) is successful if it disappears and lets you accomplish your work.

kepano

问“笔记应用完成了什么？”就像问“电子表格完成了什么？”或“相机完成了什么？”一样。工具本身不会完成任何事情，工具只是达成目的的手段。

几天前，有人开玩笑地问亨利·福特是否在Obsidian里建有个人知识库……嗯，差不多吧！他有种自己称为“便签本”的东西，用来写日记、记笔记、列购物清单等，和人们使用Obsidian的方式没什么不同。亨利·福特博物馆收藏了五十本这样的笔记本：https://www.thehenryford.org/search?Query=%22jot+book%22

我们该如何量化亨利·福特笔记本的影响？又该如何量化电子表格的影响？

大多数有所成就的人都会以某种形式做笔记，因为写作本身就是一种思考方式。我们热衷于将成功人士的工具和方法神话化，希望借此吸收他们的一丝天赋。但好相机不会自动造就优秀摄影师——多拍照片才有帮助。

你应该做笔记吗？大概是的。你的方法重要吗？大概不重要。适合你的就行。当Obsidian（或其他任何笔记形式）隐形消失、让你专注于完成任务时，它才算真正成功。

EU Age Verification Project Mandates Hardware-Boun… #

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

All this ostensibly to keep teenage boys from watching Pornhub (when parental controls already exist).

The real reason, of course, is to force people to connect strong real-life identifiers to online activity. Mobile first, then Windows. Then Linux is too weak to oppose on its own, and will adapt or die.

big85

这一切表面上是为了防止青少年男孩观看Pornhub（而家长控制功能早已存在）。当然，真正的目的是迫使人们将强有力的现实身份标识与在线活动关联起来。先从移动端开始，然后是Windows。至于Linux，它太弱小了，无法独自对抗，要么适应，要么消亡。

SQLite Critical CVEs or LLM Slop? #

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

The problem with this kind of thing, is that it reduces the S/N (Signal-to-Noise) ratio, so weeding out the legit CVEs becomes a lot more difficult.

But, on the other hand, I do know that LLMs have been discovering a lot of legit CVEs, and I will lay odds that the blackhats are leveraging them to the max.

ChrisMarshallNY

这类问题在于它降低了信噪比（S/N），导致筛选出真实的CVE变得更加困难。
但另一方面，我确实知道大型语言模型已经发现了大量真实的CVE，而且我敢打赌，黑帽黑客们正在最大限度地利用它们。

‘Crush this lady’: how eBay harassment campaign le… #

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

Brian Gilbert, 56, of San Jose, Calif., former Senior Manager of Special Operations for eBay’s Global Security Team, was sentenced to time served, one year of supervised release with the special condition that he have no contact with either of the victims in the case and a $20,000 fine

Jim Baugh, 47, of San Jose, Calif., eBay’s former Senior Director of Safety and Security, was sentenced to 57 months in prison

David Harville, 50, of Las Vegas, Nev., former Director of Global Resiliency, was sentenced to 24 months in prison

Stephanie Popp, 34, of Louisville, Ky., former Senior Manager of Global Intelligence, was sentenced to 12 months in prison

Philip Cooke, 56, of San Jose, Calif., a former Senior Manager of Security Operations, was sentenced to 18 months in prison and 12 months of home confinement

Stephanie Stockwell, 28, of Redwood City, Calif., a former Manager of Global Intelligence, was sentenced to one year in home confinement

Veronica Zea, 28, of San Jose, Calif., a contract intelligence analyst, was sentenced to one year in home confinement

https://www.justice.gov/usao-ma/pr/final-defendant-ebay-cyberstalking-case-sentenced

haunter

56岁的布莱恩·吉尔伯特，来自加利福尼亚州圣何塞，曾担任eBay全球安全团队特别行动高级经理，被判处已服刑期、一年监督释放（附加条件为不得接触本案任何受害者）及2万美元罚款。

47岁的吉姆·鲍，来自加利福尼亚州圣何塞，eBay前安全与安保高级总监，被判处57个月监禁。

50岁的戴维·哈维尔，来自内华达州拉斯维加斯，前全球韧性总监，被判处24个月监禁。

34岁的斯蒂芬妮·波普，来自肯塔基州路易斯维尔，前全球情报高级经理，被判处12个月监禁。

56岁的菲利普·库克，来自加利福尼亚州圣何塞，前安全运营高级经理，被判处18个月监禁及12个月居家监禁。

28岁的斯蒂芬妮·斯托克韦尔，来自加利福尼亚州雷德伍德城，前全球情报经理，被判处一年居家监禁。

28岁的维罗妮卡·塞亚，来自加利福尼亚州圣何塞，合同情报分析师，被判处一年居家监禁。

https://www.justice.gov/usao-ma/pr/final-defendant-ebay-cyberstalking-case-sentenced

SQLite Critical CVEs or LLM Slop? #

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

The vast majority of CVEs are not exploitable, basically noise. I suspect that the overwhelming majority of the CVEs being generated by LLMs are either noise of the sort in the linked article or noise of the sort that is not exploitable.

flerchin

绝大多数CVE（通用漏洞披露）并不可被利用，基本上就是噪音。我怀疑由LLM生成的海量CVE中，要么是链接文章中那种类型的噪音，要么就是不可被利用的那类噪音。

Karpathy’s Pelican #

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

A lot of people are posting here about how bad the end product is, but that is kind of the point. Models have moved beyond generating images to a new kind of benchmark that better exposes understanding of the physical world, and we can use benchmarks like this to measure future progress. (Of course, it will have to be a qualitative/subjective measurement.)

jmugan

很多人在这里吐槽最终效果有多差，但这恰恰是重点所在。模型已经从生成图像迈向了新的评测基准，这种基准能更好地暴露对物理世界的理解程度，而我们也可以用像这样的基准来衡量未来的进步。（当然，这必然会是一种定性的/主观的评估方式。）

Qwen3.8-Max: A New Bar for Coding and Cowork #

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

All requests to an LLM are idempotent, for every API call you need to send it the entire conversation history

A more appropriate term is “stateless”. LLM responses are certainly not idempotent, as they are not even deterministic.

jcoder

所有对LLM的请求都是幂等的，因为每次API调用都需要发送整个对话历史

更合适的术语是“无状态”。LLM的响应当然不是幂等的，因为它们甚至不是确定性的。

Developers are attached to tools because tools enc… #

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

This article is a bit rambly so I’ll just focus on some things from the beginning:

If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in.

This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates.

To use one product as an example: When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP and a pretty good OS in Windows 7 respectively. No longer is that an option, your workflow will simply be interrupted by automatic updates.

Vim and Emacs, in their infinite customizability, can be molded to fit your exact hand and workflow

Vim is one major exception to the automatic update problem. I trust vim not just because it can do a ton of shit (although that is certainly nice), but because unlike most other software, its UI doesn’t change unless I tell it to change. Aside from switching from vim to neovim (my decision, not a forced update), my muscle memory from a couple decades ago still works today.

MiddleEndian

这篇文章有些散乱，所以我只聚焦开头部分的内容：

“如果你的菜刀不断改变形状、重量和刀刃，你每次都得重新适应它——这样的工具很难让人信任。”

早在智能代理工具出现之前，这个概念就已经被一个更早的概念背叛了：自动更新。

以某个产品为例：当Windows ME和Windows Vista发布时，人们对它们的厌恶程度甚至超过了以往对Windows的惯常反感，因此没人愿意用它们。微软被迫做出回应，分别推出了还算不错的Windows XP和相当优秀的Windows 7。如今这种选择权已不复存在，你的工作流程随时会被自动更新打断。

“Vim和Emacs拥有无限的定制性，可以被塑造成完全贴合你的手型和工作流程。”

Vim是自动更新问题的一个重大例外。我信任Vim，不仅因为它能做海量的事情（虽然这确实很棒），更因为它与大多数软件不同，它的用户界面不会改变——除非我主动要求它改变。除了从Vim切换到Neovim（这是我自己的决定，而非强制更新），我几十年前形成的肌肉记忆至今依然有效。

Show HN: Shitty – fast terminal. Memory-unsafe and… #

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

Gutenberg’s copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks.

I am not sure how many Moby Dicks I require per second, but it is good to have options.

[0] https://www.gutenberg.org/ebooks/2701

3eb7988a1663

古腾堡版《白鲸》的文本大小为1.2MB[0]。也就是说，最慢的基准测试终端每秒也只能显示区区约53本《白鲸》，而最烂的终端每秒能显示约98本。

我不确定自己每秒需要多少本《白鲸》，但有选择总归是好事。

[0] https://www.gutenberg.org/ebooks/2701

‘Crush this lady’: how eBay harassment campaign le… #

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

No consequences for executives, and yet their ostensibly enormous responsibility is how their salaries and benefits are always justified.

happytoexplain

高管们无需承担任何后果，然而他们表面上巨大的责任却总是被用来证明其薪资和福利的合理性。

Don’t be a meat proxy #

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

At my last job, a coworker did this to me. The first time it happened, I ignored it. The second time, I responded in public saying “thanks but I can ask Claude myself.” Nobody ever pasted me an LLM response again. YMMV with team size and seniority though

maccard

在我上一份工作中，有位同事对我做了这样的事。第一次发生时我没理睬。第二次我公开回应说：“谢谢，但我可以自己去问Claude。” 之后再也没有人给我粘贴过LLM的回复了。不过具体情况可能因团队规模和资历而异。

Qwen3.8-Max: A New Bar for Coding and Cowork #

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

Qwen3.6-35B is my daily driver for AI, and what convinced me to cancel my Claude subscription back in April. The Qwen3.6 line is easily the best local model I’ve tried, and I’ve tried a lot. I’ve got it diligently grinding away on my laptop right now, reviewing and fixing some bugs in my F# code.

nozzlegear

Qwen3.6-35B是我日常使用的AI模型，也是让我在四月份取消Claude订阅的原因。Qwen3.6系列绝对是我试用过的最佳本地模型——我试过很多。现在它正在我的笔记本电脑上勤恳工作，审查并修复我F#代码中的一些漏洞。

How the words we teach English language learners c… #

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

I tried to organize vocab by difficulty level for an English language-learning app once.

It shocked me how there is absolutely no “right” answer.

If you are teaching English for travel, then you’re prioritizing a lot of stuff around bathrooms, transportation, menu items, etc.

If it’s for understanding TV, it’s a lot of words like “murder”, etc. Depending on which TV shows you want to understand.

If it’s for reading the newspaper, you don’t ever need to know “bathroom”, but you sure do need to know words like “congressman”.

While if you are living somewhere, it’s really important to know a lot of basic supermarket items that you wouldn’t prioritize for other usages.

Also, while it’s easy to calculate word frequencies for stuff like newspaper articles, there aren’t any good statistics (last I checked) around just normal everyday conversation. Because that stuff isn’t getting recorded and transcribed. And the substitutes – transcribed speech from TV, radio, podcasts, etc. – is not the same context as the random stuff you say at home and during an average day.

crazygringo

我曾尝试为一个英语学习App按难度级别整理词汇。
但让我震惊的是，根本不存在所谓“正确”的答案。
如果你教的是旅行英语，那你会优先考虑关于卫生间、交通、菜单等词汇。
如果是为了看懂电视节目，那就会有很多像“谋杀”之类的词——具体取决于你想看懂哪些剧。
如果是读报纸，你根本不需要知道“卫生间”，但必须知道“国会议员”这类词。
而如果你住在一个地方，了解大量超市常见物品就非常重要，这些词在其他用途中却不会优先考虑。
此外，虽然计算报纸文章等文本的词频很容易，但关于日常普通对话的可靠统计数据（据我所知）却几乎没有。因为这类对话不会被录下来转写成文字。而替代品——电视、广播、播客等转写文本——和你在家、日常闲聊的语境完全不同。

Devtools must be open source #

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

I agree that devtools should be open source, but… I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor’s font size, you should have an LLM download the code, change the hard-coded value, and rebuild it.

That’s just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use?

I really hope what you should expect is my answer to that question isn’t controversial.

Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.

kelnos

我同意开发者工具应该是开源的，但我非常不同意"任何工具都不该有配置文件、选项或插件系统，而当你想要改变像文本编辑器字号这样的东西时，应该让LLM下载代码、修改硬编码值并重新构建"这一前提。

这实在是太低效和浪费了。假设在一个LLM承担大部分编码工作的世界里，我们是想要烧一次电让LLM构建一个选项对话框或配置文件解析器，还是想要在用户每次想改变他们所用软件的任意小细节时，烧几百万次电？

我真的希望你能预期到，我对这个问题的回答并不会引发争议。

让LLM做那些不太可能对其他人有意义的定制化修改？很好，当然可以。但给一款软件添加一个普遍有用的功能，却不尝试将其向上游提交？那太差劲了。差劲，差劲，真差劲。

Don’t be a meat proxy #

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

If you create a machine for laziness you’re going to get lazy people. It’s only going to get worse I’m afraid.

Do you guys think we’re going to see a de-evolution of human beings due to technology?

jpnc

如果你为懒惰创造机器，就会得到懒惰的人。恐怕情况只会越来越糟。你们认为我们会因为技术而看到人类退化吗？

EU Age Verification Project Mandates Hardware-Boun… #

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

I don’t understand where the all the EU anti-trust and anti-corruption regulators are here. Governments enforcing that you have a Google or Apple account to participate in society is transparently absurd.

This isn’t only a digital sovereignty issue, it’s also an anti-competition issue.

afandian

我不明白欧盟的反垄断和反腐败监管机构都在哪里。政府强制要求你拥有谷歌或苹果账户才能参与社会活动，这明显是荒谬的。这不仅是一个数字主权问题，也是一个反竞争问题。