RemoveMacAI 开源工具可关闭 macOS 27 的 Apple Intelligence 并清理本地模型

2026-10-06 Hacker News Top Stories # 开源工具 RemoveMacAI 可关闭 Apple Silicon Mac 上的 macOS 27 AI 功能并清理模型，作者称无需关闭 SIP，回收空间取决于已下载的模型。 申报 PDF 的涂黑失误泄露 Google 在内布拉斯加州 Lincoln 数据中心的资源数据：峰值电力需求为 52.65 MW，年度用水约 1,329.9 万美制加仑。 据报道，Anthropic 将一名佛罗里达女子在 Claude“日记”中写下的涉嫌暴力威胁，经人工审核后报告警方，该女子现面临二级重罪指控。 Cloudflare 推出 Web Search API 测试版，接入 Ceramic.ai、Exa 和 Linkup，但公告所称的三家零留存与供应商文档对 Exa 的标注存在差异。 丹麦一家企业的 CPR 查询权限被滥用，约 880 万名登记人员资料遭未授权访问，涉及记录包含已故及迁出者，不能等同于现有人口。 GrapheneOS 暂不承诺支持 Pixel 11：官方更新确认硬件具备 MTE 能力，但固件与系统尚未正式启用，仍未达到项目的安全要求。 VB6 Studio Web 将经典 Visual Basic 窗体设计与编译运行搬进浏览器，支持 37 类控件及 HTML 导出，但未完整实现原生 COM／OCX 和 Windows DLL API。 德国工业机器人公司 RobCo 经员工股份二级交易及新增投资后估值超过 10 亿美元，Alfie 新能力计划于 2027 年 3 月商业推出。 俄罗斯伊尔库茨克一名抗鼠疫机构人员死亡后，至少 197 名可能接触者接受观察，官方确认死亡与鼠疫有关，但具体类型和媒体所述破管事故仍未确认。 F1 湿地编队圈中多辆赛车因软件异常无法正常加速，FIA 在红旗期间向全部 11 支车队提供修正，起跑延迟约 50 分钟。 1. 关闭 macOS 27 的 Apple Intelligence 并回收模型空间 (Turn off Apple Intelligence on macOS 27 and get its disk space back) # https://github.com/omlahore/RemoveMacAI 作者指出，macOS 27 缺少统一关闭 Apple Intelligence 的开关，停用功能也未必会删除已经下载的模型；RemoveMacAI 因而把配置限制与模型清理整合起来。它面向 Apple Silicon Mac，通过需要用户批准的系统配置描述文件禁用相关功能，再调用苹果的资源管理服务移除基础模型、图像生成和部分应用模型，作者称无需关闭 SIP 或直接修改系统目录。 工具会影响 Siri、写作工具、ChatGPT 扩展以及依赖这些模型的应用功能，也支持保留指定功能；独立的听写功能不在同一范围。恢复操作会移除配置并允许模型按需重新下载，删除后的空间统计可能延迟更新，实际回收量取决于设备上已有的模型。README 标注已测试 macOS 27.0，27.0.1 需要工具 0.2.3 或更新版本，不支持 macOS 26 及更早系统；这些兼容性与效果说明来自项目作者，不能视为苹果官方保证。 HN 热度 755 points | 评论 520 comments | 投稿者：privacyisntdead | 发布时间：2026-10-05 03:42:25 +08:00 # https://news.ycombinator.com/item?id=49957116 启用 AI 功能前应先明确询问用户，让用户自行决定是否接受。 有用户报告关闭功能后模型仍占空间或随后重新出现，单纯关闭界面开关并不解决存储问题。 支持本地模型的一方看重离线处理和减少云端依赖，认为删除模型也会失去实际有用的能力。 开源代码和发行证明有助于检查来源，但下载后直接执行安装脚本仍需要额外审查。 发行证明不能自动覆盖可变的安装脚本及其下载内容，也不能替代用户实际验证。 包管理器同样存在供应链信任问题，安装方式的便利性不等于代码已经安全。 小容量 SSD 和昂贵的存储升级放大了模型占用带来的不满，问题也涉及硬件定价。 2. 涂黑失误泄露 Google 数据中心用水与峰值用电数据 (Improper redaction reveals Google Data Center water and electricity usage) # https://www.1011now.com/2026/09/30/more-questions-than-answers-about-lincolns-google-data-center-water-electricity-usage/ 内布拉斯加州地方媒体 KOLN 报道，数据中心向州环境部门提交年度资料时，以商业秘密为由遮盖水电数据，但部分 PDF 的黑色遮盖并未真正删除底层文字，复制后仍可读出。Lincoln 的 Google 关联公司 Agate LLC 申报峰值电力需求为 52.65 MW，年度用水为 1,329.9 万美制加仑；前者是功率，并非全年耗电量。报道把后者与 Lincoln 单日用水比较，称不到该市 9 月 29 日一天的一半。 单个地点与整体规模必须区分：六个申报数据中心合计年度用水约 7.65 亿加仑，Papillion 的 Google 关联公司 Fireball 在 2025 年用了约 5.4788 亿加仑。资料还列出 Agate、Fireball 和 Omaha 的 Westwood 在 2025 年预计获得约 5,582 万、3,917 万和 2,256 万美元税收返还；“预计”不等于款项已经支付。报道依据企业申报资料揭示透明度问题，没有提供足以独立比较各站点运行效率的统一计量数据。 HN 热度 515 points | 评论 670 comments | 投稿者：sensanaty | 发布时间：2026-10-05 03:37:05 +08:00 # https://news.ycombinator.com/item?id=49957068 Lincoln 单个站点的年用水与城市一天用水相比并不突出，评价规模需要明确比较基准。 较小站点不能代表整个数据中心群，Papillion 和全州合计数字会改变对总影响的判断。 公共部门应掌握实际资源消耗，商业秘密主张不应让基础设施影响无法接受公众检验。 申请许可的上限、峰值需求和实际年度消耗属于不同指标，混用会夸大或淡化问题。 水冷和用电之间可能存在取舍，单看用水总量不足以判断设计是否合理。 水会进入自然循环并不消除地方水源和补给速度的约束，区域影响仍需单独衡量。 税收优惠是否与地方承担的资源成本相称，是比单个用水数字更广的公共政策问题。 泳池换算不一定有助于理解规模，家庭或城市用水等更熟悉的参照可能更直观。 3. Claude 日记内容被报告给警方，佛罗里达女子面临重罪指控 (Anthropic reported diary entry to police, woman faces felony charge) # https://www.techspot.com/news/114091-florida-woman-used-claude-diary-anthropic-reported-shoot.html TechSpot 报道，佛罗里达州 Bonita Springs 的 Carli Michelle Heller 把 Claude 当作日记使用，涉嫌在 9 月 26 日的对话中写下向警长办公室开枪的计划。报道描述的流程并非模型直接报警：内容先被系统标记，再由人工审核人员判断为可信威胁，随后向警方报告；警员前往住所将她拘留，现场没有发生暴力事件。 她面临佛罗里达州有关书面暴力威胁的二级重罪指控，但报道没有给出定罪结果，也没有刊出足以独立判断意图的完整对话。Anthropic 表示，在为防止死亡或严重人身伤害等有限紧急情况下，可能向当局披露信息。事件把对话式 AI 的亲密体验与云服务的内容审核、紧急披露机制之间的距离具体化：称其为“日记”并不能证明内容受到日记式保密，而存在刑事指控也不能替代法院对具体文字和意图的判断。 HN 热度 497 points | 评论 434 comments | 投稿者：emptybits | 发布时间：2026-10-05 13:37:40 +08:00 # https://news.ycombinator.com/item?id=49961057 平台面对可信威胁时，报告与不报告都可能造成严重后果，不能把决策描述成毫无代价的选择。 日记式表达、角色扮演和真实行动计划可能使用相似文字，审核者需要足够上下文判断。 没有完整对话就难以判断这是明确计划还是情绪宣泄，标题不足以支持确定的法律结论。 产品应在互动过程中清楚提醒隐私与披露边界，不能只依赖用户自行阅读冗长条款。 对部分危机场景引入心理健康或社会工作支持，可能比直接进入警务流程更合适。 把聊天内容当作可以随意转交的材料，会引出与通信隐私和程序保障有关的争议。 能读取本地文件的 AI 代理进一步扩大了信息暴露范围，隐私边界不能只围绕主动输入的聊天内容设计。 书面威胁与私人记录的界线存在争论，面临指控并不意味着意图或罪责已经确定。 4. Cloudflare 推出面向 AI 代理的 Web Search API (Web Search API) # https://developers.cloudflare.com/changelog/post/2026-10-02-introducing-web-search-api/ Cloudflare 在 10 月 2 日推出 Web Search API 测试版，让 AI 代理查询实时网页资料以支撑回答，首批接入 Ceramic.ai、Exa 和 Linkup。开发者可通过 REST 或 Workers AI binding 调用，搜索请求进入 AI Gateway 的日志与计费体系，按供应商公开价格使用 AI Gateway credits 结算，Cloudflare 称不加价，也允许使用自己的供应商 API key。 公告强调供应商承诺使用经过验证的机器人抓取，并称三家对经 Cloudflare 发出的请求均实行零数据留存。不过，同站供应商文档将 Ceramic.ai 与 Linkup 的 Zero Data Retention 标为 Yes，却将 Exa 标为 No；两处说明并不一致，不能据公告笼统承诺整条请求链不留数据。该文档还列出每千次请求约 0.25、7 和 5 美元的不同价格，所用搜索模式和返回摘要也不同。统一入口解决的是接入与管理问题，公告没有提供证明三家检索质量等价的对比实验。 HN 热度 476 points | 评论 218 comments | 投稿者：tosh | 发布时间：2026-10-05 18:47:06 +08:00 # https://news.ycombinator.com/item?id=49963171 统一日志和计费对已有 Cloudflare 工作流有价值，但独立开发者未必需要多加一层代理。 供应商不留存与网关自身是否保存查询是两个问题，隐私承诺应明确覆盖哪些环节。 公告与 Exa 的供应商文档存在零留存差异，敏感查询不能只依据一句宣传判断。 有试用者报告 Ceramic.ai 在两次具体查询中不如传统搜索，价格优势不能代替检索质量验证。 供应商定价差距很大，实际选择还需要考虑结果质量、摘要形式和任务成本。 返回结果的保存和再分发条款可能影响代理历史记录与缓存设计，接口可用不等于内容可任意复用。 计费用量可以与查询正文分开记录，运营需要不必自动等同于保存全部敏感内容。 代理还需要规划查询和判断何时停止搜索，提供搜索结果只是完整检索流程的一环。 5. 丹麦 CPR 数据遭未授权访问，涉及 880 万登记人员 (Denmark data breach exposes 8.8M people’s personal data) # https://www.cpr.dk/cpr-nyt/nyhedsarkiv/2026/okt/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger 丹麦 CPR 官方公告称，一家原本获准查询人口登记资料的私人企业，其访问权限被用于未授权访问，涉及约 880 万名登记人员的姓名、地址、CPR 号码等资料。企业权限已经撤销，事件已报数据保护机关，并由警方调查。公告明确排除受保护的姓名和地址，但并未表示这些人员的所有其他资料都未受影响。 部长补充说明，登记库总共约有 1,100 万条人员记录，包含在世、已故及迁出者，因此 880 万不能直接等同于丹麦目前人口。9 月的异常访问在 10 月 2 日晚间被发现，周末进一步确认；调查仍处早期，具体情况可能修正。合法企业通常是按业务需要查询事先识别的有限人员群体，而非拥有任意抓取全库的授权。官方同时提醒，即使来电者能报出姓名、地址或 CPR 号码，也不要据此交出密码或其他机密信息；当前声明没有确认攻击者身份或后续实际诈骗规模。 HN 热度 463 points | 评论 327 comments | 投稿者：clan | 发布时间：2026-10-05 16:09:36 +08:00 # https://news.ycombinator.com/item?id=49962012 私人企业查询人口资料的权限应严格限定范围，并对异常的大规模访问及时报警。 减少不必要的资料访问和保存，比事后期待所有持有者都妥善保护数据更可靠。 长期维护公共信息系统的投入不足，会让看似稳定的基础设施持续累积安全债务。 880 万涉及人数高于丹麦现有人口并非自动说明报道错误，登记库还包括其他历史人员记录。 数据保护责任需要清晰的经济与组织后果，否则便利的数据访问容易被置于风险控制之前。 泄露字段应按已确认的姓名、CPR 号码和地址解读，不能把其他资料也一并当作泄露事实。 CPR 号码属于识别符而非秘密口令，身份认证不应依赖仅仅知道这个号码。 姓名、地址和识别号码即使不足以直接登录账户，也能让冒充和定向诈骗更有说服力。 6. Pixel 11 尚未达到 GrapheneOS 安全要求，支持计划仍未定 (Pixel 11 doesn’t yet meet the GrapheneOS security standards and may be skipped) # https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-yet-meet-the-grapheneos-security-standards-and-may-be-skipped GrapheneOS 在初始帖子中表示，移植 Pixel 11 时无法启用 MTE，因此该系列尚未满足其安全要求，可能跳过；MTE 是项目用于加强内核、系统进程和应用内存安全的重要机制。早期帖子仍在调查究竟缺少软件、固件还是硬件支持，不能把其中的推测当作最终硬件结论。 同一讨论中的官方后续更新明确说，Pixel 11 硬件支持 MTE，但出厂固件没有提供支持；Android 17 QPR2 Beta 后来加入初步固件支持，操作系统侧仍完全禁用，连开发者选项也不能启用。团队尚不清楚是否存在需要绕开的硬件实现问题，并表示在 MTE 支持正式到来之前不会承诺支持该系列。原帖也认可新设备的 Titan M3、验证启动等其他安全进步，但认为它们不能直接替代 MTE 带来的防护。结论是支持状态仍未确定，而不是已经证实硬件永久缺失 MTE，或已经最终宣布全面放弃 Pixel。 HN 热度 392 points | 评论 248 comments | 投稿者：finnlab | 发布时间：2026-10-05 21:02:25 +08:00 # https://news.ycombinator.com/item?id=49964303 这不是全新的单次声明，判断支持状态时应把原帖与后续官方更新一起阅读。 后续说明已修正硬件不支持 MTE 的早期判断，把旧标题直接当作当前结论会误导读者。 将缺少功能归因于降低成本缺乏足够证据，技术问题与厂商动机应分开讨论。 购买决定不应只建立在未来可能实现的安全功能上，当前可验证的支持状态更重要。 仍在受支持的旧款 Pixel 对部分用户已足够，新机并不自动意味着更适合 GrapheneOS。 依赖少数硬件厂商会让安全系统的路线受制于外部决策，增加可用平台有现实价值。 严格坚持安全门槛能保护项目定位，但也有人担心要求过高会减少现实可用的设备。 7. 浏览器里的经典 Visual Basic 6 开发环境 (A browser-native classic Visual Basic VB6 IDE) # https://wieslawsoltes.github.io/VB6/ 这个开源项目把经典 Visual Basic 的窗体设计器、属性面板、编辑器与运行环境搬进浏览器。相关 README 将其称为 VB6 Studio Web 0.6.0：界面以 HTML、CSS 和 JavaScript 构建，绘制优先使用 WebGPU 并回退到 Canvas2；用户代码经项目自己的编译器和虚拟机运行，而非直接作为 JavaScript eval 执行。它支持 37 类浏览器控件、可编辑项目文件和独立 HTML 导出，也列出断点、单步、监视及 IntelliSense 等开发功能。 项目提供 SQLite、REST、OData、GraphQL 等数据接入能力，但这些不等于完整复制原生 VB6 的 ADO／DAO 与 Windows 生态。README 明确指出，原生 COM／OCX、Windows DLL API 和任意插件并未完整实现，外观也不是原系统的逐像素复刻；老项目是否能运行取决于所用语言和控件范围。浏览器存储属于尽力保存，需要自行下载项目备份。它是独立的 MIT 开源实现，适合了解其支持范围后试用，不能仅凭熟悉的界面认定任意历史工程都能直接迁移。 HN 热度 392 points | 评论 129 comments | 投稿者：wiso | 发布时间：2026-10-05 02:49:17 +08:00 # https://news.ycombinator.com/item?id=49956681 直接在浏览器启动熟悉的开发界面，降低了重访旧程序和尝试项目的门槛。 有用户导入旧地图编辑器后遇到 BitBlt 依赖问题，Win32 API 范围决定了真实兼容程度。 快速启动的轻量环境让人重新比较现代 IDE 的启动成本和资源消耗。 属性表格对可视化控件编辑仍然有效，这类成熟交互并没有因年代久远而失去价值。 经典 VB 的上下文帮助能减少查文档时的切换成本，开发工具仍可借鉴这种体验。 熟悉的配色和布局不等于逐像素还原，怀旧体验与原生界面的忠实度应分别评价。 有试用者报告调试与智能补全体验不符合预期，功能列表仍需通过实际工程检验。 面向网页的可视化窗体设计若能与完整语言工具链结合，可能具有超出怀旧展示的用途。 8. 德国 RobCo 估值突破 10 亿美元 (Germany’s RobCo hits $1B valuation) # https://techfundingnews.com/europes-new-robotics-unicorn-germanys-robco-hits-1b-valuation/ Tech Funding News 报道，德国工业机器人公司 RobCo 在员工股份的二级交易及新增投资后，估值超过 10 亿美元，约为九个月前的两倍；这个数字是公司估值，不是此次融资额或营业收入。公司 2020 年在慕尼黑创立，2026 年 1 月完成了 1 亿美元 C 轮融资，本次投资者包括既有机构与新加入的 Cherry Ventures 等。 RobCo 以机器人即服务降低制造企业的前期投入，并在美国十多个州开展业务，布局 Austin 的制造装配和旧金山的实验室。报道重点介绍名为 Alfie 的感知、推理与执行能力，目标是适应变化较多、结构不固定的工业任务；公司计划在 2027 年 3 月 4 日的 RobCoN 活动商业推出，这仍是未来计划，不能写成已经在工厂验证的普遍能力。报道把传统工业自动化与新的 AI 路线连接起来，但没有给出独立的故障率、维护成本或复杂任务可靠性测试，估值与投资者支持也不能代替这些运行指标。 HN 热度 326 points | 评论 337 comments | 投稿者：dachworker | 发布时间：2026-10-05 19:13:51 +08:00 # https://news.ycombinator.com/item?id=49963366 围绕现实工业任务的机器人，比以人形外观吸引注意的展示更容易对应明确需求。 机器人即服务是否能形成可持续业务仍值得怀疑，订阅形式本身不会消除部署与维护成本。 复杂硬件的租赁与服务模式有合理性，客户可以把维护负担和部分前期支出交给供应商。 非公开公司的估值受交易结构和投资者预期影响，不能直接当作已经实现的经营成绩。 工厂更关心停机时间、服务保障和故障恢复，估值故事无法回答这些采购问题。 机器人研究演示与稳定的工业部署之间存在很大距离，高成功率仍可能不足以支撑连续生产。 既有工业机器人能力与新的 AI 品牌叙事应分开评价，关键仍是客户现场能够完成什么。 讨论科技公司时不应只关注美国融资，欧洲工业技术同样值得根据实际产品评价。 9. 伊尔库茨克实验室人员死亡，近 200 人接受观察 (Nearly 200 people under observation after Irkutsk lab worker dies from plague) # https://www.themoscowtimes.com/2026/10/02/nearly-200-people-under-observation-after-irkutsk-lab-worker-dies-from-plague-a93857 The Moscow Times 报道，一名在伊尔库茨克抗鼠疫研究机构工作的女性死亡后，近 200 名可能接触者被隔离或接受医学观察。布里亚特地区负责人确认死亡与鼠疫有关，但没有说明具体类型；此前当地官方只称“危险感染”。媒体称死者在周二因严重肺炎入院，周四死亡，并引述她曾向医护人员提及打破装有活菌的试管；这一事故经过并非报道中已经完成调查确认的结论。 报道所列至少 197 人是可能接触者，不是 197 名确诊感染者，其中超过 100 人来自医院病区。医院实施隔离并成立调查委员会，相关地区取消部分公共活动；当地负责人在周五称，已找到的接触者没有症状，检测呈阴性。这是当时的阶段性结果，不能延伸为长期没有传播风险的保证。报道还提到对可能违反卫生安全规则的刑事调查，尚未给出最终死因、完整暴露链条或事故责任结论；媒体对肺鼠疫的怀疑也必须与官方未说明类型的状态区分。 HN 热度 294 points | 评论 304 comments | 投稿者：ericmay | 发布时间：2026-10-05 10:31:45 +08:00 # https://news.ycombinator.com/item?id=49960084 事件需要解释从潜在暴露到就医、报告和隔离的时间线，才能判断应急流程哪里出现问题。 如果工作人员已知自己可能接触危险样本，机构是否及时识别并处理风险是重要调查问题。 破管说法缺少足够证据时不应被当作确定原因，事故叙事必须接受独立调查。 笼统要求公众保持冷静不能替代透明说明，接触追踪和检测结果应有具体信息。 危险病原研究的收益与事故风险需要公开讨论，低概率但后果严重的事件也应计入评估。 支持研究的一方强调自然疫源监测和防治需求，不能因为一次事故就否定这类工作的必要性。 样本容器及其外层保护是否适合相关风险值得追问，防护设计不能只依赖操作者永不失误。 10. F1 湿地起跑软件故障令车手无法正常加速 (Powerless F1 drivers frustrated by Bahrain F1 software glitch) # https://www.motorsport.com/f1/news/horrible-totally-unacceptable-powerless-f1-drivers-frustrated-by-bahrain-f1-software-glitch/10861968/ Motorsport 报道，一场湿地比赛的编队圈中，多名 F1 车手踩下油门却得不到正常动力响应，甚至几乎停住。正文将现场描述为马来西亚 Sepang，尽管原始英文标题写的是 Bahrain；这处地名差异不应靠猜测消除。报道把问题与 2026 年赛车首次湿地比赛中的动力控制模式联系起来：低速编队圈触发了异常的怠速循环，使赛车无法按车手预期加速。 比赛在红旗期间处理问题，FIA 向全部 11 支车队提供修正，并取消通常适用于湿地的部分动力削减区域，起跑因此延迟约 50 分钟。Norris、Piastri、Perez 和 Bearman 等人的描述强调突然失去动力响应的危险与不可接受，也有人希望在了解原因后再作结论。报道呈现了车手对复杂混合动力规则和软件依赖的不满，却没有提供修正代码、完整根因报告或其测试流程；因此不能把短时间内修正写成已经证实的现场重写程序，更不能把评论中的 AI 编程玩笑当作事故原因。 HN 热度 282 points | 评论 246 comments | 投稿者：llm_nerd | 发布时间：2026-10-05 09:54:08 +08:00 # https://news.ycombinator.com/item?id=49959869 多支车队同时受影响让人追问共用控制部件和强制软件的范围，而非只看单队的调校。 共同的控制平台与车队自己的参数设置可以并存，统一硬件不意味着所有赛车逻辑完全相同。 安全关键系统在很短时间内修正，仍需要说明验证方式与部署风险。 快速修正可能只是改配置或关闭触发条件，不能仅凭耗时推断现场重新编写了完整程序。 偏好更简单动力系统的观众希望赛车减少复杂控制逻辑，并恢复更直接的驾驶和声音体验。 能源限制和规则设计塑造了技术复杂度，问题不只在车队工程师如何实现控制软件。 工程技术始终是赛车竞争的一部分，批评具体规则并不需要否定所有技术创新。 用于车辆控制的软件不能照搬普通网页的快速迭代习惯，异常场景和失效行为必须被认真验证。