Claude Desktop 出现显著的性能问题——启动缓慢、UI 滞后和响应时间变慢，尤其是在使用“cowork”功能后。这与位于 `~/Library/Application Support/Claude/vm_bundles` 中的一个 10GB 的 VM 包文件有关，该文件即使在删除后也会持续重新生成。 手动删除 VM 包、缓存和代码缓存可以提供约 75% 的初始性能提升，但由于 CPU 使用率（24-55%）和交换活动增加，性能下降会在几分钟内*再次发生*，表明可能存在内存泄漏或累积的工作负载。 即使使用干净的 VM 包，问题仍然存在，表明问题并非仅仅与文件大小有关。目前，拥有 8GB 内存的用户必须定期退出并手动清理这些文件才能恢复可接受的性能。 预期行为是稳定的性能以及在每次 cowork 会话后自动清理 VM 包。
每日HackerNews RSS
## Anthropic 的 CoWork 功能与 macOS 磁盘空间问题
最近的 Hacker News 讨论强调了 Anthropic 新的 macOS CoWork 功能存在的问题。用户报告称该应用程序会静默创建 10GB 的 VM 包，在没有警告的情况下占用大量磁盘空间。多位评论者遇到了意外的存储使用情况，其中一人指出 Apple Podcasts 也类似地囤积了 120GB 的数据作为“系统数据”。
核心问题似乎在于 macOS 难以识别和管理磁盘空间使用情况，导致一些人不得不通过 Finder 进行手动清理，甚至完全重新安装系统。人们对 Apple 是否有动机*不*优化存储空间表示担忧，考虑到他们分层的存储定价。
用户还发现 Claude CoWork VM 启动时几乎已满，限制了可用空间。一种解决方法是通过 Claude Code 手动扩展磁盘镜像。有人推测，报告这些问题的 GitHub issue 本身也可能是由 AI 生成的，可能夸大了说法。尽管存在这些问题，用户仍然觉得他们的专业知识对于引导 AI 解决问题很有价值，这表明人类输入仍然至关重要。
## 使用Mikado方法处理遗留代码
继承一个庞大、复杂且文档匮乏的代码库，感觉就像陷入流沙。尝试进行重大更改——修复错误、添加新功能或重构——常常会导致连锁问题和进度停滞。Mikado方法提供了一种结构化的方法来避免这种情况。
其核心思想是将雄心勃勃的目标分解为小的、有时限的任务（5-15分钟）。如果任务在时限内失败，**回滚更改**并确定需要首先解决的更小的“子目标”。然后，在新的时限内处理这个子目标。成功的任务会**立即提交**，创建频繁的检查点。
这个迭代过程，可视化为分支的“Mikado”棍图，逐步解开依赖关系。例如，升级ORM依赖项可能首先涉及提取公共函数调用，然后调整单个实例，最后完成升级。
Mikado方法强调短时限以避免“沉没成本谬误”，并频繁提交以保持可发布的代码库。它关注于在尝试更大的目标之前，使每一步都*更容易*，最终实现对具有挑战性的遗留系统的有效且成功的更改。
## Mikado 方法用于安全的代码修改
一篇 Hacker News 讨论强调了“Mikado 方法”——一种用于对复杂代码库进行安全修改的技术，详情请见 understandlegacycode.com。该方法侧重于迭代的小幅修改，而非大规模重构。
一位用户成功地使用 Git 提交信息前缀和预提交钩子实现了该方法的变体，并记录在 [https://docs.eblu.me/how-to/agent-change-process](https://docs.eblu.me/how-to/agent-change-process)，甚至将其与代理集成以处理更大的任务。
一个关键的挑战是抵制在迭代之间跳过完全重置的冲动，这可能导致混乱的代码库。与传统的“瀑布式”重构不同，Mikado 强调*最小化*的预先规划，允许灵活的进展并轻松放弃未成功的尝试，而不会丢失整体工作。它被描述为超越简单的“计划模式”，优先行动而非大量的预先规划。
## 苹果发布搭载M4芯片的新款iPad Air 苹果发布了最新的iPad Air，现在搭载M4芯片，在与上一代相同起售价的基础上，提供了显著的性能提升。新款iPad Air的速度比M3版本快高达30%，比M1型号快2.3倍，在视频编辑和游戏等任务中表现出色，并得益于更快的神经网络引擎和更大的内存，拥有更强的AI能力。 iPad Air提供11英寸和13英寸两种尺寸，四种颜色可选，具有更快的无线连接，支持Wi-Fi 7，并通过新的N1和C1X芯片改善了蜂窝网络性能。它运行iPadOS 26，引入了重新设计的界面和改进的窗口管理。 iPad Air兼容Apple Pencil Pro和Magic Keyboard，为学生、创作者和专业人士提供多功能体验。11英寸型号起售价为599美元，13英寸型号起售价为799美元，并提供教育折扣。预订将于3月4日开始，供货将于3月11日开始。
苹果最近发布了搭载M4芯片的新款iPad Air。这一消息在Hacker News上引发了关于平板电脑是否需要如此强大处理器的讨论。
用户质疑iPad为何需要比许多笔记本电脑更强的芯片，一些人认为这对于典型使用场景来说是多余的。提供的解释包括改进的电池效率、为Final Cut Pro等 demanding 应用的未来兼容性，以及运行虚拟机的潜力（目前尚未实现）。
一些评论员指出苹果的商业行为，认为利用现有芯片设计比创建定制芯片更便宜，并且计划性报废推动了频繁的硬件更新。另一些人希望iPadOS得到改进，而不仅仅是关注硬件，还有人表达了希望iPad能够兼容MacOS的愿望。一个值得注意的点是内存增加到12GB，以及对苹果营销重点关注“价值”的观察。
启用 JavaScript 和 Cookie 以继续。
OpenClaw，一款人工智能工具，意外超越React，成为GitHub上点赞数最多的项目，引发了Hacker News上的讨论。一些人对点赞数快速增长表示怀疑，认为可能是AI代理自动点赞，从而夸大了其受欢迎程度。
用户们质疑OpenClaw在个人助理之外的实际应用，许多人认为现有的自动化工具，如Home Assistant和n8n，更符合他们的需求。有人认为缺乏需要通信中介层的应用场景。一个有趣的建议是将其用于管理投资，以实现提前退休。
这场讨论凸显了GitHub点赞数作为衡量项目实用性的真实指标，与单纯的受欢迎程度竞赛之间的争论，尤其是在人工智能驱动活动日益频繁的时代。
## 386芯片的漫长复制之路：AMD与Intel的竞争
关于AMD复制Intel CPU速度慢的说法并不完全准确。虽然AMD的Am386于1991年问世，比Intel的386晚了六年，但延误源于IBM最初对386的不感兴趣——IBM不希望出现与利润丰厚的迷你计算机竞争的芯片，因此没有促使Intel广泛授权。这使得Intel得以避免延长与AMD的许可协议。
AMD花了两年时间逆向工程386，但随之而来的是与Intel长达八年的代价高昂的法律斗争，最终两家公司损失了1亿美元。Intel积极努力延缓AMD的进入，有效地使AMD落后一个世代超过十年，并巩固了其在高利润CPU市场的统治地位。
尽管如此，Am386是一款具有竞争力的芯片，以更低的价格提供与Intel相当的性能，吸引了注重性价比的用户。虽然最终被486和Windows 95的崛起所取代，但Am386展示了AMD的能力，并为其未来奠定了基础，甚至在其PC鼎盛时期之后，在嵌入式系统中存活了多年。这场冲突凸显了Intel的激进策略，并塑造了AMD在CPU领域的轨迹。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
AMD Am386 发布于1991年3月2日 (dfarq.homeip.net)
18 分，由 jnord 1小时前发布 | 隐藏 | 过去的 | 收藏 | 1 条评论 帮助
Zardoz84 5分钟前 [–]
> 从技术上讲，Am386可以运行Windows 95，但体验并不好。技术上说，可以运行。速度慢吗？是的，但我的Am386DX40从1991年到1996年一直运行良好。运行DR-DOS 6，MS-DOS 6.11，Windows 3.1，最后是Windows 95。当然，我还能在上面玩DooM 2。后来，我得到一个数学协处理器。
最后，我的父亲将机器升级为AMD 486DX5 133MHz。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
您的IP地址已被Codeberg屏蔽。如果您认为这是一个错误，请通过contact us联系我们，并提供您的IP地址：47.245.80.60
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Libxml2 企业版 (AGPL, 来自之前的维护者) (codeberg.org/nwellnhof)
12 分，by todsacerdoti 2 小时前 | 隐藏 | 过去 | 收藏 | 5 评论 帮助
Milpotel 9 分钟前 | 下一个 [–]
希望代码质量能提高，并且他们“我们不需要测试，因为我们使用模糊测试...有时...”的态度能改变。
on_the_train 26 分钟前 | 之前 [–]
“企业版”通常是恶搞项目的标志。但这个看起来是认真的？
hobofan 12 分钟前 | 父评论 [–]
“企业版”什么时候成了恶搞项目的标志？
zvqcMMV6Zcr 9 分钟前 | 根评论 | 父评论 | 下一个 [–]
我记得至少有一个这样的：https://github.com/Hello-World-EE/Java-Hello-World-Enterpris...
ginko 9 分钟前 | 根评论 | 父评论 | 之前 [–]
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
Squidcasa/midipipe: ALSA 序列器到纯文本以及反向转换
Squidcasa/midipipe: ALSA Sequencer to plain text and back
14 小时前
您的IP地址已被Codeberg屏蔽。如果您认为这是一个错误，请通过contact us联系我们，并提供您的IP地址：47.245.80.60
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Squidcasa/midipipe: ALSA 序列器到纯文本以及反向转换 (codeberg.org/squidcasa)
4 分，由 surprisetalk 1小时前发布 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
wjwuhuhewwuhiue 0分钟前 [–]
hacvyewuki8ewytew 回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 逆向工程苹果神经引擎：摘要（第一部分）
本系列详细介绍了一位人类研究员（maderix）和AI Claude Opus 4.6合作逆向工程苹果神经引擎（ANE）的过程——这是M4芯片上一个专门的机器学习加速器。苹果有意模糊对ANE的访问，迫使开发者使用抽象的CoreML框架。
该团队成功绕过了CoreML，将软件堆栈映射到内核驱动程序，破解了二进制格式，并实现了对ANE的直接访问。他们发现ANE不是传统的GPU或CPU，而是一个图执行引擎，针对运行编译后的神经网络图作为单个操作进行了优化。
主要发现包括16核设计，深度队列（127个请求），独立的电源管理，以及用于程序编译成高效E5二进制文件的独特机器学习中间语言（MIL）。这些二进制文件参数化了固定的计算基元，如卷积和矩阵乘法，而不是编码算法本身。
该团队的代码可在GitHub上获取，它解锁了直接ANE编程的潜力，并为未来在该先前专注于推理的硬件上进行基准测试（第二部分）甚至训练（第三部分）奠定了基础。
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
M4 苹果神经网络引擎内部，第一部分：逆向工程 (maderix.substack.com)
14 分，来自 zdw 1 小时前 | 隐藏 | 过去的 | 收藏 | 2 条评论 帮助
poszlem 12 分钟前 [–]
真心提问，并非有意挑衅，但考虑到苹果智能的现状，这些核心真的有用吗？回复
rahkiin 5 分钟前 | 父评论 [–]
它们也被用于深度集成在 macOS 和 iOS 中的机器学习模型，你可能不知道。例如图像中的物体和文本检测。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
微量瑕疵宣言
Microslop Manifesto
14 小时前
## “AI垃圾内容”的兴起与网络侵蚀 微软积极整合人工智能，尤其通过Bing和Copilot，正在向互联网倾泻不准确和捏造的内容——被称为“AI垃圾内容”。 这表现为搜索引擎结果中的幻觉事实、不存在的引用，以及自信地呈现的错误信息。 Copilot在微软产品中的强制存在使界面臃肿，并优先考虑人工智能生成的内容，从而分散了核心功能。这种大规模生成、低质量的内容——包括文章和社交帖子——淹没了真实的声音，并制造出“镜子迷宫”效应。 关键在于，人工智能现在正在*利用自身*有缺陷的输出进行训练，从而形成一个衰退的递归循环，并降低模型质量。 这导致了验证危机，侵蚀了对在线信息的信任，并使得区分事实和虚构变得越来越困难，最终大规模污染互联网。
## AI 批评与潜在问题 - Hacker News 总结
最近 Hacker News 的讨论集中在当前的“AI 反弹”上，承认其合理性，但认为它忽略了更深层、预先存在的问题。核心观点是，目前许多 AI 输出确实是“垃圾”，但快速进步可能会提高质量。
然而，对工作岗位流失和经济破坏的担忧并非由 AI *造成*，而是被 AI *加速*，暴露了长期存在的财富不平等问题。 同样，AI 对新闻业和公共讨论的影响被视为对已经因社交媒体和虚假信息而受损的系统的最后一击。
讨论表明，AI 可能会迫使我们面对这些已经达到危机点的問題。 它还指出了一种负面偏见倾向，忽略了 AI *已经* 带来的潜在好处，将当前的文本/代码 AI 与图像生成的早期阶段进行比较——有所改进，但仍然存在缺陷。
## 在 Go 中构建持久化工作流 在 Go 中创建自然的工作流库面临独特的挑战，这源于该语言的优势（如 `context.Context` 和异步运行时）和局限性（严格的类型系统）。本文详细介绍了为克服这些障碍而设计的 `durable.Context` 接口。 核心思想是扩展 Go 原生的 `context.Context` 以实现持久化执行，跟踪工作流状态以及步骤之间的关系。`durable.Context` 旨在提供熟悉 Go 的感觉——行为类似于标准上下文——同时提供编译时类型安全。它通过 `RunWorkflow` 和 `RunAsStep` 方法来包装用户函数来实现这一点。 一个关键的设计选择是尽管存在类型安全问题，但仍保持单个接口。该解决方案利用灵活的通用函数签名来处理工作流和步骤，避免了复杂的反射。包级别的通用函数处理类型转换，从而使核心接口保持简单。序列化依赖于 `encoding/json` 以更轻松地解码工作流输入/输出，尽管更喜欢 `encoding/gob`。 最终，该库优先考虑轻量级、符合 Go 习惯的体验，以构建健壮且可扩展的工作流。
## Go-Native Durable Execution (dbos.dev) - 摘要
一篇 Hacker News 讨论围绕 **dbos.dev**，一个全新的 Go-native 持久化执行框架。作者强调了其 Go 语言的具体实现，旨在提供一个比现有方案更简单的替代方案。
多位评论者提到了竞争选项：**Restate**（BSL 许可，因易用性而备受赞誉）、**Temporal**（开源，但被指出存在开销）、**Dapr's durabletask-go**、**go-workflows** 和 **derecho**（一个进程内的 Temporal 替代方案）。
主要争议点包括许可（开源 vs. BSL）、dbos 内部的语言支持差异，以及对 dbos 的“Conductor”GUI定价模式的担忧——被认为是生产功能（如恢复和 RBAC）所必需的。一些用户还指出了 dbos 功能上的潜在不足，例如工作流版本控制和心跳检测，而另一些用户则赞赏它对 Go 语言的关注以及通过 **DagGo** 等项目实现的编译时安全性。
作者承认了反馈并表达了持续改进 dbos 的承诺。