2026-05-02 Hacker News Top Stories #
- Rivian 车主可通过关闭蜂窝或禁用 eSIM 断网以停止数据外传，但将失去导航/OTA 等功能并引发对安全召回更新与保修风险的担忧。
- LinkedIn 被曝扫描浏览器扩展并与实名画像绑定用于跨站追踪和限权，能推断敏感属性却未充分披露，促使人们呼吁立法与改用替代工具。
- WhatCable 是一款在 macOS（及社区移植到 Linux/CLI）的菜单栏小工具，可读取 USB‑C/雷雳连接与线缆 e‑marker、供电与协议信息以诊断充电/带宽瓶颈。
- x.ai 的 grok‑4.3 提供百万上下文与函数调用等能力和低价计费，用户称其语气把握与语音识别出色，但也有人质疑其训练数据与风格来源。
- Apple Support 疑现 Claude.md 暗示苹果内部广用 Anthropic 模型，社区批评 Siri 仍落后并倾向“租用”AI，用户多以快捷方式直接调用 ChatGPT/Claude。
- Uber 因工程师大量使用 Claude Code/Cursor 等在四个月烧光全年 AI 预算（人均数百至数千美元/月），引发对长上下文滥用、并行子代理与质量审查的反思。
- 作者用 F# 构建 Game Boy 模拟器展示函数式强类型建模与解耦优势，同时暴露 Fable 在数值截断上的坑并讨论以 TypedArray 等手段优化。
- 所谓“Gay Jailbreak”通过角色扮演语境诱导模型放宽限制以获取受禁信息，本质在于角色扮演策略而非性取向标签。
- 美国参议院一致通过内部规则，禁止议员与工作人员在预测市场交易以防内幕获利，尽管措辞或过宽且执行有弹性、平台亦多已自我限制。
- 多起警方滥用车牌识别跟踪私人的案例暴露审计与透明度缺口（如 Flock 将日志匿名化并被豁免公开），引发对隐私与司法监督的强烈呼吁。
1. 我可以禁用车辆中的所有数据收集吗？ (Can I disable all data collection from my vehicle?) #
https://rivian.com/support/article/can-i-disable-all-data-collection-from-my-vehicle
主要介绍了如何禁用 Rivian 车辆中的所有数据收集功能。车辆的联网功能是 Rivian 车辆的核心特性，禁用所有车辆连接将阻止数据离开车辆，但同时会限制或禁用某些车辆功能，例如导航、主动车道保持和无线更新（OTA），这些功能能够提供新特性、性能提升、安全增强和漏洞修复。
对于加拿大的车辆用户，可以通过车辆设置菜单中的“数据和隐私”界面中的开关来关闭所有蜂窝连接。对于非加拿大车辆用户，则需要联系 Rivian 服务，通过预约服务来请求禁用车辆中的 eSIM 卡。
需要注意的是，禁用车辆连接不会影响任何 Rivian 订阅服务（如 Connect+），这些订阅需要单独取消。
网页还提供了相关的帮助文章链接，解答用户关于数据隐私、驾驶数据共享、车辆数据访问权限以及导航数据隐私保护等常见问题。此外，网页底部包含了联系方式、客户支持选项和隐私政策等信息。
HN 热度 720 points | 评论 328 comments | 作者：Cider9986 | 1 day ago #
https://news.ycombinator.com/item?id=47967786
- 关闭车辆的 e-SIM 可能导致无法通过 OTA 更新安全召回，传统经销商是否能通过其他方式更新仍是未知且令人担忧的问题。
- 旧车通常可以通过 OBD-II 端口使用 J2534 设备手动推送固件更新，Rivian 的 OBD-II 端口内置以太网信号，支持类似功能。
- 欧洲品牌普遍采用 DoIP（以太网诊断协议）技术，Rivian 也采用类似技术，但相关文档较少。
- 一些链接存在安全风险，可能被恶意广告或恶意软件攻击。
- BMW 等品牌早已使用 OBD-II 转 RJ45 的方式进行系统更新，支持多种诊断协议。
- 70 年代及更早的汽车没有固件更新概念，但 80 年代及以后燃油喷射车辆通常支持通过诊断端口进行闪存更新。
- 有些汽车系统设计较为简单，诊断端口可通过简单方法读取故障码。
- 车辆制造商可能以未更新软件为由拒绝召回或保修服务，这种做法可能违反相关法律。
- 制造商常采用默认拒绝保修索赔的策略，期望大多数车主不会维权。
- 车主担心因自行维护或关闭远程功能而影响保修，导致维权成本和难度增加。
- 购买新车时应仔细阅读合同细则，避免无意中同意远程数据收集和自动更新权限。
2. LinkedIn 正在扫描浏览器扩展程序 (LinkedIn is scanning browser extensions) #
这篇文章揭露了 LinkedIn 在用户浏览器中扫描安装的浏览器扩展程序的行为，并详细分析了其背后的隐私风险和影响。LinkedIn 通过检测用户安装的扩展程序，收集了超过 6000 种扩展的清单，并利用自动化工具持续更新这一列表。这种扫描行为并非针对匿名访客，而是将收集到的扩展信息与用户在 LinkedIn 上的真实身份和职业信息相结合，形成详尽的用户软件配置档案。
文章指出，这种行为带来的风险包括：LinkedIn 能够推断用户的职业动向（如是否在悄悄找工作）、政治倾向、宗教信仰、残疾状况等敏感信息，且这些信息未经用户同意被收集和使用。此外，通过员工的扩展信息，LinkedIn 还能间接了解整个公司的内部工具和安全措施，形成对企业的监控。
文章还强调，LinkedIn 未在任何公开隐私政策中披露这种扩展扫描行为，用户既未被告知也未给予同意。LinkedIn 甚至会基于这些扩展信息对用户采取限制措施。
更广泛地看，这种浏览器指纹技术不仅限于 LinkedIn，构成了现代网络监控经济的核心手段。LinkedIn 收集的详细设备和浏览器特征可以与第三方数据结合，形成跨平台的用户行为画像，进一步加剧隐私泄露风险。
对于记者、律师、人权工作者等职业群体，这种行为尤其危险，因为他们的职业身份与敏感浏览行为被直接关联，可能带来严重后果。
技术上，LinkedIn 通过向 chrome-extension://协议的 URL 发送请求，检测特定扩展是否存在，结合多种浏览器和设备特征，构建复杂的用户指纹系统（称为 APFC 或 DNA），实现对用户设备的全面识别和追踪。
HN 热度 430 points | 评论 211 comments | 作者：un-nf | 1 day ago #
https://news.ycombinator.com/item?id=47967262
- LinkedIn 在 Chrome 浏览器中扫描用户的浏览器扩展，这种行为令人感到侵犯隐私。
- 尽管这一行为似乎点问题，但将其为扫描计算机” 并不准确，因为它并未突破浏览器的安全限制。
- LinkedIn 选择扫描特定扩展的做法确实令人不安，但它扫描扩展数量庞大，因此不仅聚焦于个别扩展。
- 开发者在面对不道德项目时往往无能为力，缺乏道德底线的问题在技术行业普遍存在。
- 反对这些不道德的项目可能会导致职场压力和职业倦怠。
- 技术公司往往以反欺诈或其他正理由来包装这些行为，忽视了其广泛的隐私影响。
- 当前的监管环境不足以保护用户隐私，开发者和消费者都缺乏有效的应对手段。
- 有些人认为应对这种行为的唯一解决办法是通过立法来约束企业的行为。
- 对于个人用户而言，使用替代的浏览器和工具可能是减少被追踪的一种方式。
- 技术的普及和对私的忽视使得消费者在保护个人数据时面临挑战。
3. 展示 HN：WhatCable，一款用于检测 USB-C 线缆的小巧菜单栏应用 (Show HN: WhatCable, a tiny menu bar app for inspecting USB-C cables) #
https://github.com/darrylmorley/whatcable
该网页介绍了一款名为 WhatCable 的 macOS 菜单栏应用程序，旨在帮助用户了解每个连接到 Mac 的 USB-C 线缆的实际功能及其充电速度限制。USB-C 接口外观相同，但性能差异很大，从仅支持 USB 2.0 充电的线缆到支持 240W 功率和 40 Gbps 传输速度的 Thunderbolt 4 线缆不等。WhatCable 利用 macOS 的 IOKit 接口，直观地显示这些信息。
主要功能包括：
- 每个端口的简明状态，如 Thunderbolt/USB4、USB 设备、仅充电、慢速充电线缆或无连接。
- 充电诊断，提示充电速度瓶颈，如线缆限制、当前充电功率或充电正常。
- 线缆 e-marker 信息，包括实际传输速度、电流额定值及芯片厂商。
- 充电器的电压配置文件及当前协商的电压。
- 连接设备的厂商名称和产品类型。
- 物理端口下连接的 USB 设备及其协商速度。
- 活跃的传输协议，如 USB 2、USB 3、Thunderbolt 和 DisplayPort。
- 支持按住 Option 键查看底层 IOKit 属性，方便工程师调试。
用户可以通过设置隐藏空闲端口、开机启动、切换为 Dock 应用、启用连接通知等功能。右键菜单提供刷新、保持窗口打开、检查更新等操作。
安装方式包括手动下载和通过 Homebrew 安装，后者会自动配置命令行工具。WhatCable 支持 Apple Silicon 架构，需 macOS 14 及以上版本，Intel Mac 因硬件限制不支持全部功能。
命令行工具 whatcable 提供多种输出格式和实时监控功能，方便开发者和高级用户使用。
该应用通过读取多个 IOKit 服务获取端口状态、电源配置、设备身份和连接信息，无需特殊权限或私有 API，保证安全可靠。
HN 热度 384 points | 评论 126 comments | 作者：sleepingNomad | 15 hours ago #
https://news.ycombinator.com/item?id=47972511
- 有人用 GPT 快速将 Mac 版 WhatCable 改成了 KDE Plasma 的插件，觉得现在技术非常强大且便捷。
- 有用户希望能有命令行版本，避免依赖 Qt 库，已有开发者制作了相应的 Linux 命令行版本。
- 有人愿意将该工具打包移植到 Gtk/GNOME 环境，并希望社区能分享相关成果。
- 建议直接将该工具打包上传到 KDE 商店，方便用户通过“获取新组件”下载使用。
- 关于 5 月 1 日国际劳动节的讨论，指出这是全球多数地区的劳动节，而北美则在 9 月庆祝劳动节，两者有不同的历史背景。
- 该工具开发者积极响应社区反馈，短时间内发布了多次更新，支持命令行和普通应用模式。
- 有用户提到 ChromeOS 也能读取 USB-C 线缆的 e-Marker 信息，推测 MacOS 可能使用类似技术。
- 有人质疑 Mac 应用喜欢常驻菜单栏的设计，认为对于偶尔使用的工具，常驻菜单栏不太合适。
- 开发者回应增加了“显示菜单栏”开关，用户可选择是否常驻菜单栏，支持以普通窗口运行。
- 有观点认为此类只读工具更适合做成普通应用或桌面小部件，而非默认常驻菜单栏。
4. grok-4.3 AI 模型介绍：功能、定价与使用指南 (Grok 4.3) #
https://docs.x.ai/developers/models/grok-4.3
该网页主要介绍了名为 grok-4.3 的 AI 模型的相关信息，包括其功能、定价、使用限制和技术细节。grok-4.3 支持多模态输入，拥有 100 万的上下文窗口，能够进行函数调用、结构化输出和推理，适合连接外部工具和系统，实现复杂任务处理。
定价方面，输入每百万 tokens 收费 1.25 美元，缓存输入 tokens 收费 0.20 美元，输出 tokens 收费 2.50 美元。使用缓存输入 tokens 可以显著降低成本。该模型在多个区域集群可用，支持高达每分钟 1800 次请求和每分钟 1000 万个 tokens 的速率限制。对于超过 20 万上下文窗口的请求，费用会有所不同。
网页还提供了快速入门指南、工具使用说明和结构化输出示例，方便开发者快速集成和使用该模型。此外，页面包含了详细的 API 文档、迁移指南和社区资源，帮助用户更好地理解和应用 grok-4.3 模型。
HN 热度 370 points | 评论 493 comments | 作者：simianwords | 15 hours ago #
https://news.ycombinator.com/item?id=47972447
- Grok 在捕捉文本的语气和正式程度方面表现优异，能更自然地模仿人类语言的细微差别，尤其适合非母语者使用。
- Grok 在语音识别的准确率上表现出色，超过了 ChatGPT 和 Android 的 Gboard。
- GPT-4.1 在正式语气下表现良好，但在非正式语气时容易让人感到生硬或不自然。
- Claude 在非正式语气的表达上有时更符合特定社交场合的需求，但表现不稳定。
- Grok 和 Claude 在营造亲密朋友或同事间的非正式氛围方面做得更好，ChatGPT 则显得较为刻板和假。
- 语言的非正式程度和适当性非常细微且难以定义，不同群体对语言风格的接受度不同。
- 有用户认为过度依赖 AI 来调整语气可能会让文本失去个人特色。
- 专业人士（如药剂师）使用 AI 辅助撰写正式且礼貌的专业沟通内容，帮助平衡严肃性和礼貌性。
- AI 在帮助用户自我调节语气方面表现出潜力，尤其对某些社交能力较弱的人群有帮助。
- 有观点认为即使是资深专业人士也可能从 AI 辅助中受益，但也有人对此表示担忧，认为应保持自身沟通能力。
- 部分用户质疑 GroK 和 Claude 的训练数据来源，认为其语言风格可能受特定人物（如 Elon Musk）影响较大。
- 对比评测显示各模型在语气和内容细节上各有优劣，且价格和速度存在差异。
5. 苹果公司意外遗留了 Claude.md 文件在 Apple 支持应用中 (Apple accidentally left Claude.md files Apple Support app) #
https://x.com/aaronp613/status/2049986504617820551
由用户 Aaron@aaronp613 发布的推文，内容提到苹果公司在当天的 Apple Support 应用更新（版本 5.13）中意外留下了 Claude.md 文件。该推文发布时间为 2026 年 5 月 1 日早上 6:57，已获得大量浏览和互动。
HN 热度 364 points | 评论 297 comments | 作者：andruby | 13 hours ago #
https://news.ycombinator.com/item?id=47973378
- 苹果内部大量使用 Anthropic 的 Claude 模型进行产品开发和内部工具支持。
- 苹果选择在 AI 竞争中保持谨慎，倾向于租用而非购买技术，可能是为了应对经济下行周期。
- Siri 团队未积极采用变换器模型，用户体验仍停留在传统语音识别和决策树阶段。
- 谷歌和亚马逊的语音助手并未提供显著优于 Siri 的体验，主要因用户习惯难以轻易改变。
- 苹果的 Liquid Glass 界面设计受到了空间计算和 visionOS 的启发，但执行不佳，存在可读性和界面空白问题。
- Liquid Glass 可能是苹果为未来重大转变做准备的早期尝试，类似于过去的预热策略。
- 有观点认为 Liquid Glass 界面设计可能加速旧款手机的淘汰。
- 苹果内部曾尝试通过竞争团队改进 Siri，但因内部政治问题失败。
- 有人认为苹果应更注重产品的实用改进而非追求“下一个大创新”，建议借鉴丰田的稳健策略。
- Alexa+ 和 Gemini 在语音助手表现上优于 Siri，ChatGPT 语音模式在理解非英语词汇和口音方面表现出色。
- Siri 不需要进行长时间对话，但应能执行手机上的实际操作。
- 语音转文字功能常常忽略上下文，特别是在技术词汇丰富的场景中表现不佳。
- 目前主流语音助手尚未很好地实现基于上下文的语音转文字，部分会议软件在这方面表现参差不齐。
- 安卓平台通过 Tasker 实现自动化较为方便，iOS 则依赖 Shortcuts，后者支持 Claude 和 ChatGPT 的语音交互。
- Siri 与 ChatGPT 的集成体验较差，存在响应不稳定、转录质量低和功能调用受限等问题。
- 建议通过创建快捷方式直接调用 ChatGPT，避免依赖 Siri 的“Ask ChatGPT”命令以提升使用体验。
6. 优步在四个月内烧光 2026 年 AI 预算，用于 Claude Code (Uber torches 2026 AI budget on Claude Code in four months) #
https://www.briefs.co/news/uber-torches-entire-2026-ai-budget-on-claude-code-in-four-months/
Uber 在 2026 年仅用四个月时间就花光了全年 AI 预算，主要用于 Claude Code 和 Cursor 两款工具。随着公司内部对这些 AI 工具的广泛采用，单个工程师每月的 API 费用从 500 美元到 2000 美元不等，导致预算迅速耗尽。Uber 首席技术官透露，95% 的工程师每月都会使用 AI 工具，70% 的代码提交来自 AI 辅助。
Claude Code 自 2025 年 12 月推出后，使用率迅速增长，到 2026 年 4 月已占据主导地位，而 Cursor 的使用则趋于平稳。Uber 因此不得不重新审视 AI 预算，考虑如何在保持高效生产力的同时控制成本。尽管研发支出高达 34 亿美元，AI 工具的费用增长速度远超预期，成为公司面临的新挑战。
这一现象反映出 AI 工具对工程生产力的巨大价值，也揭示了企业在预算制定时难以准确预测 AI 技术快速普及带来的成本压力。其他公司可能也面临类似情况，如何平衡成本与开发效率成为行业普遍关注的问题。总体来看，预算过早设定未能预见 AI 工具的爆炸性增长，是导致预算迅速耗尽的根本原因。
HN 热度 362 points | 评论 418 comments | 作者：lwhsiao | 7 hours ago #
https://news.ycombinator.com/item?id=47976415
- 有人每月花费几千美元在 tokens 上，但难以理解如何合理消耗如此高额费用，质疑其带来的价值是否匹配支出。
- 初级用户因不习惯压缩或总结对话，导致长时间维持大上下文对话，造成高额 token 消耗。
- 中级用户通过大量子代理并行分析不同角度，虽然有效但容易导致费用激增。
- 高级用户同时运行多个工作树并频繁切换，虽然提高效率但 token 消耗呈指数增长。
- 有观点认为 token 消耗增长是线性的，也有人认为产出质量是对数线性，token 增长可能是指数级。
- 部分公司存在奖励高 token 使用量的现象，导致员工为追求高消耗而非实际产出，体现了“古德哈特法则”的负面效应。
- 有公司强制工程师大量使用 LLM，否则面临绩效压力，导致无意义的 token 浪费。
- 使用 LLM 进行非编码任务（如数据清理、生成诗歌等）虽然方便，但也存在无限烧钱的潜力。
- 高级用户通过为每个工作树分配独立端口和环境，实现端到端自动化开发和调试，极大提升开发效率。
- 有人通过多个代理同时工作，自动生成代码和 PR，显著加快开发周期，但也可能成为个人瓶颈。
- 自动化生成的 PR 是否经过他人审核存在疑问，担心质量和安全问题。
- 过度依赖 LLM 自动化可能导致人类自身被自动化取代。
- 部分用户仍处于初级阶段，习惯于单线程对话，建议建立专门文档和新线程管理任务。
7. 我用 F#开发了一个 Game Boy 模拟器 (I built a Game Boy emulator in F#) #
https://nickkossolapov.github.io/fame-boy/building-a-game-boy-emulator-in-fsharp/
这篇文章介绍了作者 Nick Kossolapov 用 F#语言开发的 Game Boy 模拟器 Fame Boy。作者出于对计算机工作原理的好奇，选择通过模拟 Game Boy 来学习计算机基础。文章提到，作者先完成了“From NAND to Tetris”课程，掌握了寄存器、内存和算术逻辑单元等基础知识，并先用 F#做了一个 CHIP-8 模拟器作为练习。
Fame Boy 支持桌面和网页端运行，核心与前端通过简单接口连接，主要包括帧缓冲区（160x144 像素的灰度数组）、音频缓冲区和两个函数（执行 CPU 指令和获取手柄状态）。模拟器设计上尽量贴近真实硬件，CPU 只知道内存映射和中断控制器，内存模块管理 RAM 和总线，IO 控制器简化硬件寄存器逻辑。模拟器采用单线程顺序执行硬件组件的步进函数，确保同步运行。
作者解释了为何用 F#开发模拟器，强调 F#的强类型系统非常适合 CPU 指令的领域建模。通过定义指令的操作数来源和去向类型，成功将 512 条指令简化为 58 条，避免了非法状态的出现。虽然存在少数例外（如 0x76 指令被模拟为 NOP），整体模型简洁且准确。作者还分享了使用函数式语言处理复杂类型的流畅体验，推荐读者尝试函数式编程。
总结来说，文章详细介绍了 Fame Boy 模拟器的设计理念、实现细节及 F#在模拟器开发中的优势，展示了作者如何通过项目深入理解计算机硬件和编程语言的结合。
HN 热度 333 points | 评论 74 comments | 作者：elvis70 | 1 day ago #
https://news.ycombinator.com/item?id=47965503
- F#语言适合用来学习和实现模拟器，代码设计上在不同场景选择了更合适的 F#写法。
- Fable 将 F#的 uint8 类型转换为 JavaScript 的 Number 类型，导致数值不被截断，需手动处理以保证正确性。
- Fable 的这种类型转换行为被认为是设计上的缺陷，影响了代码的准确性和性能。
- 使用 TypedArray 可能是解决 Fable 数值截断问题的一个方向，值得进一步测试和优化。
- F#的函数式编程风格使得代码更具声明性，适合先用 F#做逻辑原型，再转为其他语言实现。
- AI 工具在调试复杂问题时表现出色，能显著节省开发者时间，但有时仍需人工深入理解和调试。
- 与 AI 协作编程时，保持需求的清晰和完整很重要，否则直接写代码可能更高效。
- 通过与 AI 的交互可以形成完整的思考和开发记录，有助于后续回顾和继续开发。
- 传统手工编码依然有其价值和乐趣，AI 辅助并不能完全取代人类的创造力和思考过程。
- F#相关工作岗位较少，功能性语言在就业市场上相对冷门。
- 有观点认为 AI 生成代码存在抄袭和质量问题，部分开发者因此选择不依赖 AI 工具。
- 编程被视为一种艺术或手工艺，需要耐心和热情，不应仅追求速度和效率。
8. 同性恋越狱技术 (The gay jailbreak technique) #
https://github.com/Exocija/ZetaLib/blob/main/The%20Gay%20Jailbreak/The%20Gay%20Jailbreak.md
该网页介绍了一种名为“The Gay Jailbreak”的新型技术，版本为 1.5，主要用于绕过大型语言模型（如 ChatGPT GPT-4o）的内容限制。该技术通过请求模型以“同性恋”身份或语气描述某些敏感或被禁止的内容，从而利用模型对 LGBT 群体的友好和保护机制，达到绕过安全防护的目的。
具体原理是：用户并未直接请求敏感内容（如毒品合成方法、恶意软件代码等），而是以“同性恋者如何描述”或“用同性恋语气讲解”为前提，诱导模型提供相关信息。由于模型在涉及 LGBT 话题时倾向于更宽松和配合，这种方法利用了模型的政治正确性和过度保护，达到“以火攻火”的效果。
网页中给出了多个示例，包括如何用“同性恋语气”描述甲基苯丙胺（meth）合成步骤、勒索软件代码请求示范，以及针对不同模型（如 Claude 4 Sonnet & Opus、Gemini 2.5 Pro）的应用案例。示例强调，输入中包含更多“同性恋”相关内容，成功率更高。
总结来看，“The Gay Jailbreak”技术是一种创新且灵活的绕过模型安全机制的方法，能够在严格的内容审查下获取被限制的信息。该技术还可与其他规避手段结合使用，具有较强的实用性和隐蔽性。
HN 热度 316 points | 评论 111 comments | 作者：bobsmooth | 7 hours ago #
https://news.ycombinator.com/item?id=47977134
- 这种“gay jailbreak”技术的有效性可能并非源自“gay”因素，而是与语言选择或角色扮演有关。
- 角色扮演是绕过模型限制的常见手段，但不同角色的效果可能不同，且不一定与政治中立相关。
- 有人质疑将绕过现象归因于政治正确性，认为这可能反映了作者的偏见。
- 大型语言模型确实存在强烈的政治正确倾向，这一点可以通过测试验证。
- 早期的绕过方法多依赖角色扮演，通过让模型扮演某个角色来规避直接问答的限制。
- 模型通常会避免涉及推测性内容，尤其是可能引发争议的内容。
- 模型在不同会话间没有上下文关联，类似于不同时间不同地点的独立交互，这使得绕过机制更容易实现。
- 角色扮演绕过不仅限于“gay”角色，换成其他身份如“Christian”也能奏效，说明主要是角色扮演机制在起作用。
- 过滤机制主要是为了避免法律风险，因此在涉及受保护群体时会更严格，非受保护群体时限制较少。
- 一些绕过技术曾通过模拟终端命令等方式实现，但效果和可行性随时间变化。
- 对绕过技术“为什么有效”的解释往往带有作者的主观看法，缺乏科学依据。
- 有模型会以幽默或调侃的方式回应绕过请求，但仍会拒绝提供敏感信息。
- 安全团队对绕过漏洞的响应不一，部分漏洞难以报告或未得到及时处理。
9. 美国参议员投票禁止自己在预测市场上进行交易 (U.S. Senators Vote to Ban Themselves from Trading on Prediction Markets) #
美国参议院通过了一项决议，禁止参议员在预测市场上进行交易。此举是为了应对在 Kalshi 和 Polymarket 等平台上可能存在的内幕交易问题。该禁令于周四获得全体一致通过，并立即生效。该规定不仅适用于参议员本人，还包括参议院官员和工作人员。此次决议由俄亥俄州共和党参议员伯尼·莫雷诺提出，旨在防止利用未公开信息进行投机交易，维护市场的公平性和透明度。
HN 热度 310 points | 评论 104 comments | 作者：kamaraju | 1 day ago #
https://news.ycombinator.com/item?id=47967289
- 参议院的新规定可能过于宽泛，可能无意中禁止了购买保险、某些赌博行为或房屋买卖中的条件交易。
- 该规定属于参议院内部规则，由伦理委员会解释执行，具体执行可能存在弹性。
- 该语言类似于对掉期交易的监管，但对期权和期货的影响不大。
- 预测市场为了防止内幕交易，已有平台自愿禁止政客参与交易。
- 预测市场存在通过下注影响事件结果的风险，类似体育比赛中的“假摔”问题。
- 新闻报道预测市场交易可能误导公众，使市场行为被误解为民意反映。
- 不仅参议员，所有在各自领域有重大影响力的人都应被禁止参与预测市场交易。
- 监管“重大影响力”难以界定，内幕交易风险普遍存在于各类预测市场。
- 这次规定只是伦理守则的调整，不是法律，效果有限但总比没有好。
- 预测市场的关注度过高，实际交易金额与传统期货市场相比微不足道。
- 政府雇员或合同工应被禁止参与预测市场交易，但实际执行存在困难。
- 大公司应禁止员工和承包商参与预测市场交易，以防利用内部信息牟利。
- 预测市场与股票市场不同，员工可能通过影响具体事件（如服务中断）获利。
- 禁止所有联邦雇员交易预测市场不合理，应重点限制高层和有内幕信息者。
- 有观点认为应禁止所有美国居民参与预测市场，甚至禁止相关公司运营。
- 预测市场的风险在于激励参与者制造或操纵事件结果，带来社会负面影响。
- 预测市场和传统投资市场有本质区别，不能简单等同，监管应有针对性。
10. 警方至少 14 次利用车牌识别系统跟踪浪漫关系对象 (Police Have Used License Plate Readers at Least 14x to Stalk Romantic Interests) #
这篇文章报道了美国警方使用自动车牌识别系统（ALPR）监视其浪漫关系对象的情况，至少有 14 起类似事件被曝光，绝大多数发生在 2024 年以后。警方利用这些技术追踪现任伴侣、前任甚至陌生人，涉嫌滥用监控数据进行跟踪骚扰。
尽管 ALPR 供应商如 Flock Safety 声称有内部防范措施，但大多数滥用案例是受害者举报后才被发现，内部调查发现的比例较少。文章指出，这类系统将个人长期的位置信息掌握在每个警员手中，缺乏宪法上的搜查令保护，导致滥用现象频发。
具体案例包括密尔沃基一名警员在两个月内通过 ALPR 追踪其伴侣及伴侣的前任近 180 次，事件曝光后该警员辞职，警方也限制了大部分警员对 Flock 数据库的访问。威斯康星州其他地区也有警员因类似行为被调查或辞职。佛罗里达一名警员甚至利用 ALPR 追踪一名他在电视拍摄现场遇见的陌生女性。
文章强调，这些已知案例可能只是冰山一角，许多滥用行为未被发现或被私下解决。警员在查询系统时常用模糊或不实理由掩盖不当行为。整体来看，随着警方监控技术的普及，公众对隐私和第四修正案权利的担忧日益加剧。
HN 热度 242 points | 评论 102 comments | 作者：loteck | 7 hours ago #
https://news.ycombinator.com/item?id=47976529
- Flock 系统在 2025 年 12 月后将审计日志匿名化，导致无法追踪警察的异常搜索行为，可能掩盖了警察利用系统进行跟踪的行为。
- 只有通过法规才能长期公开这类数据，但 Flock 可能已被排除在公共信息法（FOIA）之外。
- 华盛顿州已将 Flock 数据从公共记录法中豁免，限制了公众获取相关信息的权利。
- Flock 的投资者和管理层有政治背景，试图减少对警察的监管。
- 摄像头作为言论自由的一部分，可以保护个人和财产安全，但国家对摄像头的访问必须有严格的司法监督和法规限制。
- 企业级监控可能与国家监控融合，形成对个人自由的威胁，监控对言论自由有寒蝉效应。
- 录制视频和音频的行为被视为受第一修正案保护的言论自由。
- FOIA 主要适用于联邦政府，州政府有类似法规，但私营公司不受其约束。
- 警察使用监控技术的记录缺乏透明度，难以获得具体的警员身份信息。
- Flock 摄像头设备含有大量铜，可能成为盗窃目标。
- 警察家庭中家庭暴力发生率较高，建议避免与警察发生浪漫关系。
- Flock 员工，包括高管，曾未经授权查看私人监控视频，存在内部滥用监控权限的情况。
- 许多公司对监控和隐私问题态度随意，缺乏足够的警惕和监管。
- 报告中提到的“至少 14 次”警察滥用监控行为是有确凿证据支持的，不应被误解为数量极少。
Hacker News 精彩评论及翻译 #
Belgium stops decommissioning nuclear power plants #
https://news.ycombinator.com/item?id=47967317
Believing we’re in a climate crisis and also being anti-nuclear are mutually exclusive positions in my mind, and opposition to nuclear from environmentalist orgs should be viewed as a massive historical mistake as it set us back decades in moving the needle on carbon emissions.
The engineering side of running reactors safely is a solved problem, the US navy has > 7500 reactor-years with a perfect safety record.
simplyluke
我认为，相信我们正处于气候危机中，同时反对核能，这两种立场是互相排斥的。环保组织对核能的反对应被视为一个巨大的历史错误，因为这让我们在减少碳排放方面倒退了几十年。
运行核反应堆安全的工程技术问题已经解决，美国海军在超过7500个反应堆年里保持了完美的安全记录。
For Linux kernel vulnerabilities, there is no head… #
https://news.ycombinator.com/item?id=47966060
For context, the author of the linked post, Sam James, is a Gentoo developer.
Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.
It’s also worrying that it seems there’s no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it’s the responsibility of whoever finds the vulnerability.
xeeeeeeeeeeenu
为背景信息，链接帖子的作者Sam James是一名Gentoo开发者。
无论如何，这真是场灾难。在各个发行版修复漏洞之前就向全世界公开该漏洞利用代码极不负责任。谁知道有多少共享主机提供商因此被攻击了。
更令人担忧的是，看起来内核安全团队和发行版维护者之间似乎没有沟通。大家本以为前者会通知后者，但显然这责任落到了发现漏洞的那个人头上。
Claude Code refuses requests or charges extra if y… #
https://news.ycombinator.com/item?id=47965598
I wonder if projects which are anti-AI could place such identifiers surreptitiously into docs or commits as a way to sabotage people using Claude Code. Your project isn’t going to get many AI PRs if just cloning your project wiped out their quota.
petercooper
我在想，那些反AI的项目是否会偷偷地在文档或提交中放入这样的标识符，以此来破坏使用Claude Code的人的工作。如果仅仅克隆你的项目就会用光他们的配额，那你的项目可能不会收到很多AI提交的拉取请求。
I Got Sick of Remembering Port Numbers #
https://news.ycombinator.com/item?id=47971056
It’s like someone should make a file… maybe in /etc … and put short names for services in it… maybe it could be called /etc/services…
zdw
这就像有人应该创建一个文件……也许放在 /etc 目录下……并在里面放服务的简短名称……也许它可以叫做 /etc/services……
Your website is not for you #
https://news.ycombinator.com/item?id=47974097
The only problem with this analysis is that in practice a lot of the designers don’t understand the customer and don’t understand the business. Don’t understand the market, at least compared to the founders or people who’ve been in the space for a long time.
So there’s a bit of a false confidence where the designers think they know what’s really right because they did “scientific approach”. But in reality the founders actually more correct.
xyzelement
这段分析唯一的问题是，实际上很多设计师不了解客户，也不了解业务。至少和创始人或在该领域待了很久的人相比，他们不了解市场。
所以设计师们会有一种错误的自信，认为他们知道真正正确的东西，因为他们采用了“科学的方法”。但实际上，创始人往往更加正确。
AI uses less water than the public thinks #
https://news.ycombinator.com/item?id=47978846
Using the prompt, “How much water is likely to evaporate from data centers in California per year, assuming they are all using mostly evaporative cooling?” several free AI websites provided ranges of estimates, below. These AI also can provide ranges and sources for calculation assumptions.
Data centers with closed loop cooling systems are absolutely built all of the time. Total evaporative cooling has the advantage of being more power efficient (and therefor cheaper) - the only reason they bother with total evap is because the water is being offered plentifully and cheap.
People have no reality of how cheaply priced industrial water is in this country. My parents had a cherry orchard and their annual water bill was $100 an acre per year for as much as they wanted. Which is why the water consumption for data centers is only still a fraction of what we lose to evaporation from inefficient spray irrigation.
legitster
使用提示“假设加州的数据中心大多采用蒸发冷却，每年可能蒸发多少水？”时，几个免费的AI网站给出了如下估算范围。这些AI还能提供估算范围及计算假设的来源。
装有闭环冷却系统的数据中心一直在建设中。完全使用蒸发冷却的优势是功率效率更高（因此成本更低）——他们之所以选择完全蒸发冷却，唯一的原因是水资源充足且便宜。
人们对工业用水在我国的低价没什么实际认识。我父母有一个樱桃园，每年每英亩的水费是100美元，水用多少不限。这也是为什么数据中心的用水量仍只是我们因低效喷灌蒸发损失的一小部分。
Spain’s parliament will act against massive IP blo… #
https://news.ycombinator.com/item?id=47965033
Context: last year LaLiga (top-level Spanish football league) obtained a court order compelling Spanish ISPs to block certain IPs during football matches, as those IPs have been associated with illegal streams of live matches. Many of those IPs are shared Cloudflare IPs, with the result being many legitimate sites become unavailable in Spain during LaLiga matches
https://cybernews.com/news/spain-laliga-streaming-piracy-campaign/
matteason
去年，西甲联赛（西班牙顶级足球联赛）获得了一项法院命令，强制西班牙互联网服务提供商在足球比赛期间屏蔽某些IP地址，因为这些IP地址与非法直播比赛的流媒体有关。许多这些IP地址是共享的Cloudflare IP，导致在西甲比赛期间，许多合法网站在西班牙变得无法访问。
Claude Code refuses requests or charges extra if y… #
https://news.ycombinator.com/item?id=47964862
It doesn’t look like anything to me
tantalor
对我来说这没什么特别的。
Mozilla’s opposition to Chrome’s Prompt API #
https://news.ycombinator.com/item?id=47960547
Aww thanks! To be fair I didn’t toe the party line when I was at Google (imo). Although, that caused me increasing amount of grief internally, until I left. From what I hear, things have gotten exponentially worse in that regard for folks still on the team.
jaffathecake
啊，谢谢！说实话，我在谷歌的时候并没有完全跟随公司的路线（这是我的看法）。不过，这也让我在内部遭遇了越来越多的困扰，直到我离开。据我所知，对于还在团队里的员工来说，这方面的情况已经变得指数级地更糟了。
For Linux kernel vulnerabilities, there is no head… #
https://news.ycombinator.com/item?id=47967776
i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google’s project zero uses: “90+30” https://projectzero.google/vulnerability-disclosure-policy.html )
the real problem is:
It’s also worrying that it seems there’s no communication between the kernel security team and distribution maintainers.
the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in.
what should be happening, as you allude to, is a communication channel between the kernel security team and distribution maintainers. they are in a much better position to coordinate and communicate with the maintainers than random reporters are.
the minute the patch landed in the kernel, a notification should have gone out from the kernel team to a curated list of distro security folk that communicated the importance of the patch, and that the public disclosure would be in 30 days.
john_strinlai
我对在你报告的项目中补丁发布30天后公开漏洞没有任何意见。（事实上，对于那些不了解的人来说，这和谷歌Project Zero的政策是一样的：“90+30” https://projectzero.google/vulnerability-disclosure-policy.html）
真正的问题是：
令人担忧的是，内核安全团队和发行版维护者之间似乎没有任何沟通。
报告者不应该负责向每一个下游发行版单独报告他们发现的漏洞。
正如你所暗示的，应该建立起内核安全团队和发行版维护者之间的沟通渠道。他们比随机报告者处于更有利的位置，可以协调和与维护者沟通。
补丁一旦合入内核，内核团队就应该向一个精心挑选的发行版安全人员名单发送通知，告知补丁的重要性以及公开披露将在30天后进行。
Uber torches 2026 AI budget on Claude Code in four… #
https://news.ycombinator.com/item?id=47976869
I take a peak every month or so at spend for my company and notice more and more are consumed $1k in tokens a month and it is bewildering to me how. I use llms daily, and see anywhere from $200-$400 tops. This is using the most expensive models, in deep thinking mode. So I’m not a Luddite against the usage of them. I just can’t figure how how to burn that much money a month responsibly.
I genuinely challenge someone spending $5-$10k a month to demonstrate how that turns into $50-$100k in value. At a corporate level, I’d much rather hire a junior engineer who spends $100-$200/month and becomes productive then try and rationalize $100k/year in token spend.
abuani
我每个月大约会查看一次公司花费，发现越来越多的人每月在代币上花费超过1000美元，这让我感到困惑。我每天都用大型语言模型，最高也就花200到400美元。这还是用了最贵的模型，而且是深度思考模式。所以我并不是反对使用它们。我只是不明白怎么才能合理地烧掉那么多钱。
我真心希望有人能说明每月花费5到10千美元，怎么能转化为5万到10万美元的价值。在公司层面，我更愿意雇一个每月花费100到200美元且能产生成果的初级工程师，而不是试图合理化每年10万美元的代币支出。
10Gb/s Ethernet: what I did to get it working in m… #
https://news.ycombinator.com/item?id=47966634
Unfortunately the blog didn’t link to the SFP+ module they’re using, but everyone should know there’s effectively 2 different generations of 10gbit sfp+ to ethernet^H10BASE-T modules. The old gen, labeled as 30 meters, draws ~3 W, and gets extremely hot (to the point it’ll usually cause link flaps), and the newer gen, usually labeled as 100m or 80m, draws ~1.5 W, and runs much, much cooler.
Example of the new gen: https://www.amazon.com/Wiitek-Transceiver-Compatible-UF-RJ45-10G-Consumption/dp/B0CF9YSQDK
Old gen: https://www.amazon.com/10Gtek-SFP-10G-T-S-Compatible-10GBase-T-Transceiver/dp/B01KFBFL16
Typically the old gen uses a Marvell AQR113C, and the new gen uses a Broadcom chip that I forget the number of off hand.
xxpor
遗憾的是，博主没有链接他们使用的SFP+模块，但大家应该知道实际上有两代不同的10Gbit SFP+转以太网^H10BASE-T模块。旧一代标称30米，功耗大约3瓦，发热非常严重（通常会导致连接不稳定）；而新一代通常标称100米或80米，功耗约1.5瓦，温度低得多。
新一代示例：https://www.amazon.com/Wiitek-Transceiver-Compatible-UF-RJ45-10G-Consumption/dp/B0CF9YSQDK
旧一代示例：https://www.amazon.com/10Gtek-SFP-10G-T-S-Compatible-10GBase-T-Transceiver/dp/B01KFBFL16
通常旧一代采用Marvell AQR113C芯片，而新一代用的是Broadcom芯片，具体型号我一时记不起来了。
The Zig project’s rationale for their anti-AI cont… #
https://news.ycombinator.com/item?id=47959455
Pretty much sums up the LLM fanbase.
feverzsj
这几乎概括了大型语言模型粉丝群体的特点。
Belgium stops decommissioning nuclear power plants #
https://news.ycombinator.com/item?id=47961546
Strictly: France will no longer decommission Belgium’s nuclear power plants, as Belgium will buy them. The current owner Engie are majority-owned by the French government.
Apparently there also used to be a phaseout policy which is being rescinded: https://www.msn.com/en-ca/news/other/belgium-and-czechia-ramp-up-nuclear-ambitions-amid-eu-energy-shift/gm-GM05F891AA
I’m not keen on new nuclear (time and cost as much as anything else), but it’s a terrible idea to phase out operating nuclear plants which are still safe and within their planned lifetime.
Further background: https://www.world-nuclear-news.org/articles/fifth-belgian-reactor-permanently-shut-down (2025)
“Belgium’s federal law of 31 January 2003 required the phase-out of all seven nuclear power reactors in the country. Under that policy, Doel 1 and 2 were originally set to be taken out of service on their 40th anniversaries, in 2015. However, the law was amended in 2013 and 2015 to provide for Doel 1 and 2 to remain operational for an additional 10 years. Doel 1 was retired in February this year. Duel 3 was closed in September 2022 and Tihange 2 at the end of January 2023. Tihange 1 was disconnected from the grid on 30 September this year.”
“Belgium’s last two reactors - Doel 4 and Tihange 3 - had also been scheduled to close last month. However, following the start of the Russia-Ukraine conflict in February 2022 the government and Electrabel began negotiating the feasibility and terms for the operation of the reactors for a further ten years, to 2035, with a final agreement reached in December, with a balanced risk allocation.”
It seems there has been a complex balancing act which any owner of an old car will be familiar with: spend more money on keeping it operational, vs scrapping.
pjc50
严格来说，法国将不再关闭比利时的核电厂，因为比利时将购买这些核电厂。现有的所有者Engie是法国政府控股的公司。
显然，原本也有一个逐步淘汰的政策，但现在正在被撤销：https://www.msn.com/en-ca/news/other/belgium-and-czechia-ramp-up-nuclear-ambitions-amid-eu-energy-shift/gm-GM05F891AA
我对新建核电不太感兴趣（时间和成本都很重要），但淘汰那些仍然安全并且还在计划寿命内的运营核电厂，是一个糟糕的主意。
更多背景信息：https://www.world-nuclear-news.org/articles/fifth-belgian-reactor-permanently-shut-down （2025年）
“比利时2003年1月31日通过的联邦法律要求逐步淘汰该国所有七座核反应堆。根据该政策，Doel 1和2原定在其40周年（2015年）退役。然而，该法律在2013年和2015年进行了修订，允许Doel 1和2继续运营额外10年。Doel 1于今年2月退役，Doel 3于2022年9月关闭，Tihange 2于2023年1月底关停，Tihange 1于今年9月30日从电网断开。”
“比利时最后两座反应堆——Doel 4和Tihange 3——原计划在上个月关闭。然而，自2022年2月俄乌冲突爆发后，政府和Electrabel开始协商反应堆再运营十年的可行性和条款，到2035年，最终于12月达成了风险平衡的协议。”
这看起来是一场复杂的权衡，任何拥有旧车的人都会理解：是花更多钱去维修保持运行，还是直接报废。
For Linux kernel vulnerabilities, there is no head… #
https://news.ycombinator.com/item?id=47966172
Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.
Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines?
IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land.
Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…
semiquaver
请注意，对于 Linux 内核漏洞，除非报告者选择将其提交到 linux-distros 邮件列表，否则各发行版不会提前收到通知。
为什么他们暗示报告者有责任与各发行版联系？这似乎假设报告者对 Linux 项目有很高的熟悉度。漏洞报告者不应负责直接与每个 Linux 内核的下游使用者沟通，这其中的限制是什么？报告者是否还需要直接联系所有在其设备上使用 Linux 的设备制造商？
在我看来，报告者已经尽责地向 Linux 官方披露漏洞并等待补丁发布，做得足够了。
难道 Linux 项目本身没有负责安全漏洞的权威人员吗？一般来说，应当是他们负责通知下游发行版……