2025 08 23 HackerNews

2025-08-23 Hacker News Top Stories #

DeepSeek 平台发布 DeepSeek-V3.1 版本，引入混合推理功能并增强工具使用能力。

文章探讨了在编程中使用 AI 工具时披露信息的重要性及相关法律争议。

FFmpeg 8.0 版本发布，新增多项编解码器支持并增强硬件加速功能。

文章批评 Go 语言的设计问题，包括错误处理、可移植性和内存使用等方面。

文章介绍了使用 io_uring、kTLS 和 Rust 构建零系统调用的 HTTPS 服务器的方法。

uv 工具包实验性引入代码格式化功能，支持通过 Ruff 格式化器简化开发流程。

4chan 拒绝支付英国 Ofcom 根据《在线安全法案》提出的罚款，称其无法律效力。

文章表达了对工程领域中过度依赖 AI 工具的担忧，质疑其实际价值。

文章介绍了一种通过手机播放特定音频文件来控制购物车轮子的锁定和解锁的方法。

文章讨论了管理中修复错误的重要性，强调承认错误并采取行动重新建立信任的关键性。

DeepSeek-v3.1 #

https://api-docs.deepseek.com/news/news250821

DeepSeek 平台发布了最新版本 DeepSeek-V3.1，标志着向代理时代的第一步。新版本特点包括混合推理功能，即一个模型具备“思考”和“非思考”两种模式；“思考”模式下，DeepSeek-V3.1-Think 能够更快地得出答案；经过后训练增强的工具使用和多步骤代理任务能力。用户可以通过“DeepThink”按钮在聊天界面切换思考和非思考模式。

API 更新包括将 deepseek-chat 设置为非思考模式，deepseek-reasoner 为思考模式，两者均支持 128K 的上下文长度，并支持 Anthropic API 格式。Beta API 中支持严格的函数调用功能。

工具和代理升级后，在 SWE/Terminal-Bench 上取得了更好的结果，增强了复杂搜索任务的多步骤推理能力，并提高了思考效率。

模型更新方面，V3.1 Base 在 V3 的基础上继续进行了 840B tokens 的预训练，以扩展长上下文，并更新了分词器和聊天模板。V3.1 Base 和 V3.1 的开源权重已在 Hugging Face 上提供。

定价方面，新定价将于 2025 年 9 月 5 日 16:00（UTC 时间）开始，之前的非高峰时段折扣将结束。在此之前，API 将遵循当前定价。详细的定价信息可在官方网站的定价页面查看。

HN 热度 739 points | 评论 254 comments | 作者：wertyk | 1 day ago #

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

DeepSeek-v3.1 需要至少 250GB 的 RAM 和 VRAM 才能有良好的性能表现。
有用户发现文档中存在错误，如“Run with Ollama”部分错误地提供了运行 llama.cpp 的指令。
文档主要由人类编写，偶尔会出现一些错误。
有用户对 unsloth 使用 sudo 运行 apt-get 表示不满，认为应该让用户自己安装依赖。
作者回应称正在改进文档，并提供了一些解决方案，如检查 llama.cpp 是否存在，以及在用户不执行 sudo 时提供手动编译的指导。
有用户提出改进建议，如检查系统发行版并根据系统类型提供安装指令。
作者表示正在考虑使用 Docker 来简化安装和运行流程。
有用户认为如果用户同意，软件在运行时静默安装东西是可以接受的。

AI tooling must be disclosed for contributions #

https://github.com/ghostty-org/ghostty/pull/8289

GitHub 上的 ghostty 项目中，作者 mitchellh 提出了一个议题，强调在使用人工智能工具辅助编程时应披露相关信息。他认为，尽管 AI 辅助工具可能产生质量不一的代码，但主要问题在于缺乏经验的人类使用者无法充分审查 AI 生成的代码，导致提交质量不佳的代码请求。mitchellh 提倡披露 AI 工具的使用，以帮助维护者评估对代码请求的关注程度，并表示他愿意协助经验不足的贡献者，但如果是 AI 在操作，则无需投入过多努力。他还提到，尽管他本人也使用 AI 工具，但我们需要负责任地使用，并尊重可能需要审查或维护代码的人类。

另一位用户 yawaramin 建议可以添加一个代码请求模板，明确要求披露 AI 工具的使用，并提到模板中还可以包含其他事项的检查列表，例如开发者证书起源。jcollie 和 yawaramin 均批准了这些变更。mitchellh 合并了这些变更，并删除了相关的分支。此外，还有用户提出了关于添加代码请求模板的建议，以及对文档改进和添加贡献指南的提及。整个讨论中，社区成员对 mitchellh 的观点和建议表示了支持和反应。

HN 热度 698 points | 评论 428 comments | 作者：freetonik | 1 day ago #

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

来源很重要，大型语言模型（LLM）不能证明开发者证书的起源（DCO），开发人员也不能为 LLM 生成的代码证明 DCO，尤其是那些基于未知来源训练的 LLM。
LLM 有时会生成与训练数据几乎完全相同的副本，这些副本大多数情况下不能在没有归属的情况下使用，可能还有更严格的许可要求。
法院如何对类似 Does v Github 的案件做出裁决尚不明确，LLM 系统甚至无法实践清洁室设计。
接受 LLM 生成的代码会使整个社区处于风险之中，并支持一种嘲笑同意权的权力结构。
对于大型 LLM，科学最终将证明逐字复制并非来自逐字记录，因为模型的结构并非如此设置。
类似于 Alsup 在 Anthropic 书籍案例中的裁决，训练是“极其变革性的”，预计会有其他案例对此进行重新解释或不同意，这将是有问题的，并且可能最终被推翻。
如果 Alsup 的裁决成立，那么在版权问题上，LLM 的出处并不是问题。
版权局关于机器输出的版权性写道，如果输出中没有足够的人类参与，则输出不受版权保护，无论其“新颖性”如何。
随着时间的推移，这可能会重新定义人类作品的版权性，从每个微小的衍生作品都可能受版权保护，转变为更强烈的独立性和创造性概念。
在开源设置中，许多小的补丁贡献是否真的通过了 Feist 测试还有待商榷，它们可能没有通过，尽管一般指导是将标准设置得很低。
如果 LLM 能够产生音乐歌词或书籍部分，这些将被认为是新颖作品。
版权法在过去 30 多年中对人类的应用并非如此，版权法对“衍生作品”的定义和保护存在争议。
来自逆向工程背景的人担心通过极其间接的方式无意中吸收“受污染”的信息，因为这可能在法庭上被用来对付他们。
ML 社区能够根据哪个对他们在任何给定时刻有利，快速改变他们对“AI 训练”是否类似于人类认知的看法。
如果 LLM 产生的输出既独特又无人见过，可能是新颖的；如果输出对人们有感知或情感价值，也是可能的。
在美国版权局的情况下，如果生产中没有足够的人类参与，那么输出就不受版权保护，无论其“新颖性”如何。
小片段的版权问题可能不会成为一个问题，如果模型经常产生大量完全重复的内容，那可能是一个问题。
对于大型模型，没有证据表明它们在普通工作提示下会产生大量重复内容，与研究中故意进行的主动搜索高概率案例不同。

FFmpeg 8.0 #

https://ffmpeg.org/index.html#pr8.0

FFmpeg 是一个跨平台的解决方案，用于录制、转换和流式传输音视频。最新版本 FFmpeg 8.0 “Huffman"已经发布，带来了许多新特性，包括对多种新编解码器的支持和性能提升。这个版本引入了原生编解码器，如 APV、ProRes RAW、RealVideo 6.0 等，并对 VVC 编解码器进行了改进，增加了 IBC、ACT 和调色板模式。此外，FFmpeg 8.0 还支持基于 Vulkan 计算的编解码器，例如 FFv1 和 ProRes RAW，以及硬件加速编解码，如 Vulkan VP9 和 VAAPI VVC。新版本还包括对新格式和过滤器的支持。

FFmpeg 项目还开始现代化其基础设施，升级了邮件列表服务器，并开始接受通过 code.ffmpeg.org 上的新 Forgejo 实例进行的贡献。FFmpeg 7.1 “Péter"版本也已发布，带来了 VVC 编解码器的稳定性提升、对 AAC USAC 编解码器的支持、MV-HEVC 和 LC-EVC 编解码器的新增支持，以及 Vulkan 编码支持。FFmpeg 7.0 “Dijkstra"版本则引入了原生 VVC 编解码器和 IAMF 支持，并移除了一些过时的 API。

FFmpeg 社区还宣布了德国主权技术基金成为其首个政府赞助商，这将有助于维持 FFmpeg 项目的维护。社区成员对于新赞助商的支持表示兴奋，认为这将有助于保持这个关键的开源多媒体组件的持续发展。

HN 热度 648 points | 评论 158 comments | 作者：gyan | 8 hours ago #

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

FFmpeg 是一个关键且不可或缺的工具，许多在线视频工具都在使用它。
FFmpeg.Wasm 也是一个有用的工具。
有人使用 FFmpeg 提取视频帧、上采样和重新组合视频帧来制作 4K 视频。
有工具嵌入了 FFmpeg，使得用户可以使用相同的编码参数。
有人揭露了一些公司声称拥有专有压缩系统，但实际上只是使用 FFmpeg 进行重新编码。
有人批评一些人将他人的东西稍作修改就声称是自己的创新。
有人对 FFmpeg 引入基于计算着色器的视频编码器和解码器表示兴奋，认为这将有助于跨平台加速其他编解码器。
有人提出疑问，想知道 GPU 加速对于视频解码的显示部分是否有益。
有人对 FFmpeg 维护者的工作表示赞赏，认为他们做的是困难的工作，而且是无偿的。
有人对 FFmpeg 维护者的工作表示好奇，想知道他们是否是作为工作的一部分在做这些贡献。
有人对 FFmpeg 的 ProRes 编解码器实现表示兴趣，并询问是否是通过逆向工程实现的。

Go is still not good #

https://blog.habets.se/2025/07/Go-is-still-not-good.html

这篇文章是一位博主对 Go 语言的批评。博主认为 Go 语言存在多个问题，包括：

错误变量作用域问题：Go 语言强制开发者使用错误变量，导致变量作用域过长，增加了代码阅读难度。
两种 nil 类型：Go 语言有两种 nil 类型，导致比较时出现混淆。
可移植性差：Go 语言需要在文件顶部添加注释进行条件编译，这会导致维护可移植程序时出现问题。
append 函数没有明确所有权：append 函数修改原切片，导致代码难以预测。
defer 机制不合理：Go 语言的 defer 机制导致资源释放时机不确定，不如 RAII 机制。
标准库隐藏异常：Go 语言标准库会隐藏异常，导致开发者必须手动处理异常安全问题。
非 UTF-8 编码问题：Go 语言将非 UTF-8 编码的二进制数据视为字符串，可能导致数据丢失。
内存使用：虽然博主认为内存很便宜，但在云服务环境中，内存使用仍然需要关注，Go 语言在这方面表现不佳。

总的来说，博主认为 Go 语言存在许多设计上的问题，导致代码难以阅读和维护。

HN 热度 505 points | 评论 681 comments | 作者：ustad | 14 hours ago #

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

Go 语言简单易学，编译快，内置功能多，但存在一些设计上的固执和不便
Go 的并发模型虽然复杂，但经过学习后能够很好地表达数据流
Go 的类型系统大多数情况下方便，有时显得冗长
Go 的一些设计可能过于坚持老派原则，忽视了实际便利性
Go 在修复一些设计问题上有所进步，如引入泛型和自定义迭代器
Go 的内存使用和可移植性问题更像是个人抱怨
Go 的垃圾回收在大多数程序中不太可能造成问题，且不难调试
Go 支持的平台广泛，几乎可以在任何地方运行
Go 的错误/nil 处理仍然令人困扰，许多人希望能有 Result[Ok, Err]和 Optional[T]这样的类型
Go 的文件系统 API 简单直接，但对非 UTF-8 文件名的处理不够周到
Go 语言容易让人做出看似有效但实际上是错误的事情，导致代码中充满了潜在问题
Go 语言的 API 设计没有考虑到所有情况，导致用户数据丢失和程序错误
Go 语言的维护者没有从其他语言的错误中学习，重复了许多错误
Go 语言的时钟/时间处理问题导致了大规模的服务中断，最终不得不添加单调时间支持
Go 语言的时钟/时间库由于原始设计没有考虑到多时钟概念，导致程序中充满了错误
Go 语言的维护者对于硬件运行方式的建议不切实际，与大多数服务器的运行方式不符
Go 语言的代码版本控制建议不切实际，大多数项目无法采用单仓库模式
Go 语言在错误处理和内存安全方面存在许多问题，需要开发者自己解决
Java 的库虽然经过了实战考验，但并不意味着不容易被滥用
Java 的时间处理历史表明，它曾经有过糟糕的设计，但最终通过 Joda-Time 和 java.time API 得到了改善
Java 的时间库曾经是当时最好的，而 Go 的时间库问题则需要更多的时间来解决

Io_uring, kTLS and Rust for zero syscall HTTPS server #

https://blog.habets.se/2025/04/io-uring-ktls-and-rust-for-zero-syscall-https-server.html

这篇文章讨论了如何构建一个零系统调用的 HTTPS 服务器，以提高网络服务的性能。文章首先回顾了过去几十年中，为了应对高容量网络服务需求，人们如何从传统的进程创建转向使用线程、poll()/select()等技术来减少系统调用和上下文切换。然而，随着连接数的增加，这些方法也遇到了扩展性问题。因此，引入了 epoll（Linux 系统）和 kqueue（其他操作系统）来提高效率。

文章接着介绍了 io_uring 技术，它允许服务器将操作命令写入队列，由内核异步处理，从而避免了频繁的系统调用。这种方式使得服务器能够通过简单的内存写入来执行之前成本较高的系统调用，并且从另一个内存区域读取结果。为了减少忙等循环，内核和服务器都会在队列中检查新内容，如果没有新内容，服务器会通过系统调用来“休眠”，直到队列中有新内容。

作者提倡使用“每个核心一个线程”的模型，并确保线程不共享任何读写数据结构，以提高性能。同时，文章提到了内存分配问题，建议预分配固定大小的内存块给每个连接，以避免新的连接需要系统调用，减少内存碎片，并防止内存耗尽。

文章还讨论了 kTLS，这是 Linux 内核的一个特性，允许应用程序将加密/解密工作交给内核处理。这样，即使应用程序仍然需要执行 TLS 握手，但在启用 kTLS 后，可以像处理明文一样发送数据，从而提高效率。

作者还提到了避免在用户空间和内核空间之间传递文件描述符的优化，通过使用 register_files 实现无描述符文件，减少了开销。

最后，作者介绍了他构建的名为 tarweb 的实验性 Web 服务器，该服务器整合了上述技术。尽管 tarweb 还不完美，代码需要改进，且 TLS 库在握手期间可能进行内存分配，但它已经能够在每个请求的基础上实现无需系统调用的 HTTPS 服务。作者计划在代码清理后进行基准测试，并强调了 io_uring 的安全性问题，即任何缓冲区都需要在操作完成之前保持在内存中，这增加了编程的复杂性。作者呼吁开发更安全的 Rust 库来处理这些问题。

HN 热度 445 points | 评论 141 comments | 作者：guntars | 20 hours ago #

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

Rust 异步库围绕 io_uring 构建困难，因为 io_uring 的 API 不允许借用检查器在编译时提供保护，也没有运行时检查。
Rust 异步设计受 epoll 影响，与 Rust 的所有权/借用模型不匹配，导致与完成基 IO 合作困难。
异步 Rust 代码可能在任何时候被丢弃，导致内核可能写入已丢弃的缓冲区，这是同步上下文中的问题。
异步系统的目标是让用户能够编写看起来同步的代码，但实际上是异步执行的，但强制用户进行所有权转移显示了这一目标的失败。
异步代码应该看起来像同步代码，但这种观点并不被所有人接受，因为同步代码在硬件架构上并不存在，且会导致性能问题。
异步代码中，传递拥有权而不是可变借用，可能违背了零成本原则。

Code formatting comes to uv experimentally #

https://pydevtools.com/blog/uv-format-code-formatting-comes-to-uv-experimentally/

uv format 是一个新引入的实验性命令，它为 Python 开发者提供了直接通过 uv 工具包进行代码格式化的功能，从而无需使用多个工具来处理基本的 Python 开发工作流程。这个命令通过调用 Ruff 的格式化器在后台工作，自动按照一致的标准风格化代码。

要开始使用 uv format，确保你运行的是 uv 0.8.13 或更高版本。如果需要升级，可以参考升级指南。升级后，格式化项目中的所有 Python 文件变得非常简单：

格式化项目中的所有 Python 文件：uv format
检查格式化情况而不做更改：uv format --check
查看将要进行的更改而不应用：uv format --diff

这个命令的工作方式与在项目根目录下运行 ruff format 类似，但是通过 uv 的界面进行。你还可以向 Ruff 传递额外的参数，只需将它们放在 -- 后面：

设置特定的行长度：uv format -- --line-length 100
仅格式化特定文件：uv format -- src/mymodule/core.py
使用多个 Ruff 选项：uv format -- --line-length 88 --preview

这种灵活性意味着你可以自定义格式化行为，同时不失去 uv 的便利性。需要注意的是，由于这是一个实验性功能，可能会有一些不完善的地方，例如命令在未来版本中可能会变化，与 uv 项目模型的集成可能会发展，错误处理和输出格式化可能会改进。尝试在你的下一个项目中使用 uv format，并看看它如何融入你的开发工作流程。这个功能的实验性质意味着你的反馈可能会帮助塑造这个功能的发展。

HN 热度 352 points | 评论 242 comments | 作者：tanelpoder | 1 day ago #

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

uv 应该专注于包/项目管理，而不是代码风格，用户希望 uv 仅在更新依赖时编辑代码文件。
将 ruff 和 ty 合并，因为它们都是关于代码风格，并且会编辑代码以格式化或修复类型/lint 问题。
ruff 和 uv 不会合并，它们保持为独立的工具，目的是简化用户不需要考虑格式化工具的体验。
有用户希望使用 Rust 而不是 Python，并认为 Rust 在微服务方面具有优势。
Rust 的 API-first 或 API-only 后端、资源占用、维护长期性和性能特性使其在竞争中具有优势。
Rust 的并发原语易于学习，特别是对于请求-响应流的软件范式。
Rust 可以作为 Go 或 Python/Flask 的替代品，具有无 GC/裸机性能、更低的缺陷率和类型系统带来的安全性。
Rust 使得编写具有 C++ 性能的代码感觉像编写 Ruby，但具有无与伦比的低缺陷率和安全性。
Rust ORM（如 Diesel）尚未成熟，推荐使用 SQLx，它类似于 Java 的 jOOQ 框架，但更简单。
用户询问 uv tool run ruff 是否已经存在，以及是否需要特殊的快捷命令。
设计考虑周到，Ruff 在调用 uv format 时安装，而不是与 uv 二进制文件捆绑，这样如果用户从不使用 uv format，则没有实质性的负面影响。
用户建议将 ruff 二进制文件与 uv 版本捆绑发布，以便于离线用户使用，并保持 uv/ruff 版本的兼容性。
用户期待 uv 成为 Python 的 “cargo”，一个管理 Python 项目的瑞士军刀。
用户对 uv 如何进行测试表示好奇，是在 tox 级别还是 pytest 级别，或者另一个级别。
用户对 uv format 和 ruff check 之间的差异感到困惑，希望 uv format 默认输出更改的文件列表。

4chan will refuse to pay daily online safety fines, lawyer tells BBC #

https://www.bbc.co.uk/news/articles/cq68j5g2nr1o

在线留言板 4chan 的代表律师表示，该网站不会支付英国媒体监管机构 Ofcom 根据《在线安全法案》提出的罚款。Ofcom 初步决定对 4chan 未能遵守其要求的行为处以 2 万英镑罚款，并在网站继续不遵守规定的情况下每日追加罚款。4chan 的律师认为，Ofcom 的通知在美国没有法律效力，他们认为监管机构的调查是对美国科技公司的“非法骚扰”。Ofcom 在调查期间拒绝发表评论。

4chan 经常因其 22 年历史上的在线争议而处于核心位置，包括性别歧视运动和阴谋论。用户匿名，这常常导致极端内容被发布。4chan 的律师声明称，作为一家在美国注册的公司，4chan 受到美国法律的保护，不受英国法律的约束。他们表示，如果必要，将在美国联邦法院寻求适当的救济以确认这些原则，并已向美国当局通报了他们对 Ofcom 调查的回应。

声明最后呼吁特朗普政府动用所有外交和法律手段保护美国企业免受“域外审查命令”的影响。Ofcom 此前表示，《在线安全法案》只要求服务提供商采取行动保护在英国的用户。美国一些政治人物，特别是特朗普政府及其盟友和官员，反对他们认为英国和欧盟对美国科技公司监管的过度干预。他们特别关注《在线安全法案》对言论自由的影响，但其他法律也是争议的焦点。

如果 4chan 在美国法院成功抗辩罚款，Ofcom 可能还有其他选择，例如要求法院命令其他服务中断提供商在英国的业务，例如要求从搜索结果中移除服务或阻止英国支付。如果 Ofcom 认为这不足以防止重大伤害，甚至可以要求 ISP 阻止英国访问。

HN 热度 340 points | 评论 368 comments | 作者：donpott | 13 hours ago #

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

英国政府通过立法、罚款和封锁网站等手段试图控制网络空间。
英国政府在现实世界失去控制，转而在网络世界中寻求权力。
美国也在通过制造虚拟问题来实现政治目的。
通过夸大问题并提供自己作为解决方案是常见的政治手段。
英国政府对社交媒体的控制可能与保护政治家有关。
英国因言论逮捕人数惊人，每年超过 12000 人因网络言论被捕。
英国政府在互联网上的打压导致人们转向街头抗议。
英国逮捕公民的标准与美国不同，英国更频繁地因冒犯性言论逮捕公民。
英国的网络逮捕行为可能部分是由于警察过度执法和网络骚扰案件增加。
互联网使用人数的增长可能解释了逮捕人数的增加。

What is going on right now? #

https://catskull.net/what-the-hell-is-going-on-right-now.html

当前网页是一篇博客文章，标题为“What the hell is going on right now?”，作者在文章中表达了对当前工程领域中人工智能（AI）工具使用情况的担忧和批评。

文章指出，工程师们正在经历职业倦怠，组织期望资深工程师能够审查并参与那些不切实际的“氛围编码”功能。作者观察到，最优秀的工程师通常对帮助新团队成员贡献和学习充满热情，但他们的反馈并没有被真正采纳，而是被年轻程序员用作他们“人工智能”作品的下一个提示。

作者提到，在一个公司会议上，一群初级工程师展示了他们的最新工作，但作者无法理解这项工作的具体内容或目的，甚至这些工程师自己似乎也不理解。然而，在大型组织中，重要的不是做了什么，而是别人认为你做了什么。一位高级经理鼓励他们夸耀使用“AI”工具，他们回应说“这是由 Claude 编写的四千行代码”，赢得了掌声。

作者分享了自己的经历，他被要求对一个现有功能进行小改进，发现最近工作的是一名初级工程师。他联系这名工程师，希望了解他们最近的更改背景，但怀疑自己的问题和提交链接被直接输入到一个大型语言模型（LLM）中，然后被复制粘贴回来，这让作者感到被侵犯。

文章还提到了作者的一个朋友，他所在的团队在过去一个月里一直在审查一个由 LLM 产生的混乱代码。作者质疑，支付 ChatGPT 每月 20 美元的费用，然后让一个工程师团队尝试审查和合并代码的成本节约在哪里？

作者强调，工程师们想要提供帮助，想要构建能够正常工作、使人们生活更轻松的优秀产品，并教授软件工程。但作者质疑，如果这些投资只是被复制粘贴到最新的模型中，那么这些投资还有什么价值？作者建议，我们应该停止使用“AI”，尝试一天、一周或一个月不使用它。

作者分享了自己最近重置电脑的经历，作为这个过程的一部分，他剔除了不再使用的软件，包括他已经支付了 6 个月费用的 Claude Pro。他觉得这只是一个巨大的时间浪费，即使需要进行几次独立的互联网搜索和阅读一些 Stack Overflow 和文档页面，自己的结论也比 LLM 提供的任何东西更可靠和准确。

文章最后质疑这些工具的价值，并提出了一个关于 AI 行业的财务模型，即 AI 被应用于特定领域，公司因此而成立，因为它们更“高效”。AI 公司从风险资本家那里获得资金，然后支付给 AI 服务提供商如 OpenAI 使用积分，但最终 AI 公司消失。作者认为，这种模式与现有的风险资本管道没有太大不同，但区别在于，即使是 OpenAI 目前也没有盈利。作者认为这是因为技术本身存在缺陷，无法扩大规模以满足需求，它消耗的电力太多，永远无法在经济上可行，更不用说严重的环境问题了。

作者呼吁人们现实地看待这个问题，认为这是一个骗局，皇帝没有穿衣服。

HN 热度 308 points | 评论 275 comments | 作者：todsacerdoti | 16 hours ago #

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

AI 是一个变革管理问题，需要有能力的团队合作，建立有效平衡人类指导和 LLM 优势的流程。
大型组织往往缺乏健康文化，AI 放大了这种毒性。
95% 的 AI 试点未能带来投资回报，反映了现代管理的无效性。
可能 AI 并没有被宣传的那么好，没有看到小团队用 AI 做出大事。
一些团队将 LLM 用于概念验证，然后重写以确保代码质量。
LLM 在编码上并非无用，但让 LLM 编写代码不会得到生产级代码。
LLM 没有对底层语言的理解，只是根据模式生成令牌。
人类是否真正理解他们所使用的语言也是一个问题。
人类在沟通时往往也不深思熟虑，只是输出统计上最可能的下一个词。
定义“理解”的含义很重要，因为它意味着 LLM 的能力有极大的限制。
LLM 即使能理解或创造语言，对它们谈论的主题也一无所知。
人类在语言上的“半随机”行为与 LLM 相似。
模型预测半随机结果的价值受到质疑。
模型预测的准确性是关键，仅在“有效时有效”的说法并不有用。
人们对智能的定义模糊，但对智能不是什么有强烈看法。
一些团队通过 LLM 快速原型制作，然后投入时间进行完善。
一些成功的公司并非完全由“氛围编码”创建，而是与 AI 炒作相关的公司。
在能源领域的小型团队中，LLM 对于繁琐但不需要太多思考的工作（如配置管理、云基础设施管理、一次性脚本、小型仪表板等）非常有用。

Control shopping cart wheels with your phone (2021) #

https://www.begaydocrime.com/

这个网页提供了一种通过手机扬声器控制 Gatekeeper Systems 购物车轮子锁定和解锁的方法。购物车轮子通常通过检测地下电线发出的 7.8 kHz 信号来判断是否需要锁定或解锁。管理遥控器可以发送不同的 7.8 kHz 信号来解锁车轮。

由于 7.8 kHz 在音频范围内，可以通过播放特制的音频文件，利用手机扬声器产生的寄生电磁场来“传输”类似的信号。网页上提供了锁、解锁、臂和购买检查等不同功能的音频文件供下载。此外，还提供了一个链接到原始 DEFCON 29 演讲的文件下载。作者也在 Twitter 上分享了这一技术，用户名为 @stoppingcart。

HN 热度 266 points | 评论 125 comments | 作者：mystraline | 22 hours ago #

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

荷兰及邻近国家不常见锁定购物车车轮的现象，因为大多数人不会携带现金，疫情期间许多商店直接取消了锁具。
密歇根大学附近的学生宿舍距离 Kroger 超市约半英里，以前常有顾客将购物车推回公寓，导致超市不得不定期租用货车去回收，后来改用地理锁定车轮。
有外国食品店故意偷窃其他商店的购物车以节省成本。
瑞典的大型商店使用硬币系统，但使用趋势在下降，趋向于不锁定的购物车。
瑞典商店提供塑料代币以方便不携带现金的顾客，这种设计使得顾客体验比安全系统更重要。
购物车硬币系统的目的不是阻止盗窃，而是鼓励人们将购物车放回指定位置。
有人为了方便，3D 打印了一个可重复使用的假代币。
购物车不归还有时是因为懒惰，有时是因为带着小孩不方便。
有人认为不归还购物车的人都是出于懒惰，即使带着小孩也不应成为借口。
有观点认为，带着多个小孩的母亲可能因为照顾孩子而难以归还购物车。
有人提出，每个不归还购物车的人都是出于懒惰，而且这种行为可能会导致其他人的汽车受损。
有人建议，如果看到有人因为带着孩子而无法归还购物车，可以主动提供帮助。
购物车理论认为，购物车被遗弃的位置可以反映社会和经济问题。

All managers make mistakes; good managers acknowledge and repair #

https://terriblesoftware.org/2025/08/22/the-management-skill-nobody-talks-about/

这篇文章讨论了管理技能中常被忽视的一项——修复错误。作者指出，成为管理者后，犯错是不可避免的，关键在于犯错后如何处理。文章引用了育儿书籍《Good Inside》中的观点，强调了修复错误的重要性，即承认错误、承担责任并重新建立联系。

作者通过自己的经历和观察，发现那些不愿意承认错误的管理者往往会失去团队的信任和优秀成员。相反，那些能够承认错误并承诺改进的管理者能够建立起信任。文章还提供了在实践中如何修复错误的具体建议：明确指出自己的错误、不以自我为中心、真正改变行为，并给予时间来修复信任。

作者认为，习惯于修复错误能让管理者变得更好，因为它让人更愿意做出决策、进行困难对话和承担合理风险。最后，作者强调，管理不是要求完美，而是要交付有价值的软件、帮助团队成长，并创造一个人们能发挥最佳工作的环境。当管理者在这些方面失败时，他们应该修复、学习并继续前进。

HN 热度 260 points | 评论 116 comments | 作者：matheusml | 11 hours ago #

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

有人提到“Mochary Method”这套谷歌文档，它涵盖了很多管理技能，以一种非常人性化的方式讲解，适合非管理者理解。
有评论认为管理与个人贡献者（IC）之间的差距在于责任感，好的管理应该识别问题并建立预防再次发生的系统。
有观点认为过多的系统会导致事情无法完成，找到平衡很难。
有人强调系统应该是持续改进和理解执行能力的单一系统，而不是仅仅依赖于检查清单。
有评论指出，仅仅依赖于“打勾”文化的系统可能会导致问题，需要避免。
有观点认为，虽然检查清单在医疗领域减少了死亡，但在其他领域可能不适用。
有评论提到，好的管理者会因为承认错误而在办公室政治中处于劣势，可能比不承认错误的管理者晋升得更慢。
有人分享了自己的经历，认为承认错误的管理者可能会得到团队的支持和尊重，从而实现超出预期的成果。
有观点认为，是否能够因为承认错误而晋升，取决于上级管理者是否也具有责任感。