2025-08-22 Hacker News Top Stories #
- AWS CEO认为使用AI替代初级员工是愚蠢的，强调AI应作为辅助工具而非替代人类。
- 马克·扎克伯格冻结Meta的AI招聘，担忧AI投资泡沫风险和回报问题。
- Zedless是一个专注于隐私和本地优先的Zed分支，移除了云依赖和遥测功能。
- 谷歌发布Pixel 10系列手机，搭载Tensor G5芯片，提供更个性化和AI驱动的用户体验。
- 95%的公司在生成性AI投资上看不到回报，仅5%的试点项目创造了显著价值。
- 代码审查流程可以通过存储审查状态和改进工具实现更高效的开发协作。
- 澳大利亚联邦银行因AI生产力谎言被迫重新雇佣被解雇的员工。
- Podman、Compose和BuildKit的结合提供了一种无守护进程的容器化解决方案，适合本地开发。
- 一家公司要求工程师接听销售电话，结果工程师们改进了产品架构并简化了用户界面。
AWS CEO says using AI to replace junior staff is ‘Dumbest thing I’ve ever heard’ #
https://www.theregister.com/2025/08/21/aws_ceo_entry_level_jobs_opinion/
亚马逊网络服务（AWS）的首席执行官马特·加尔曼（Matt Garman）表示，因为人工智能（AI）可以完成初级员工的工作而解雇他们是“我听过的最愚蠢的事情”。加尔曼在与 AI 投资者马修·伯曼（Matthew Berman）的对话中提出了这一观点，他强调了 AWS 的 Kiro AI 辅助编码工具，并指出他遇到过一些商业领袖认为 AI 工具“可以取代我们公司所有的初级员工”。他反驳说，初级员工可能是“你最不贵的员工”，并且他们与 AI 工具的互动最为密切。
加尔曼质疑，如果 10 年后没有人学习任何东西，那么这种替代将如何运作。他认为，公司绝对应该继续招聘刚毕业的年轻人，并教导他们如何构建软件、分解问题和思考问题，就像以前一样。他自然认为 AI——特别是 Kiro——可以帮助教育他们。
加尔曼还对另一个关于 AI 的观点表示不认同——通过 AI 在组织中贡献的代码百分比来衡量其价值。他认为这是一个愚蠢的指标，因为组织可以使用 AI 编写“无限多的代码行”，但这些代码可能是糟糕的代码。他指出，“通常更少的代码行比更多的代码行要好得多”，他不确定为什么这是人们喜欢夸耀的令人兴奋的指标。
尽管如此，他看到的数据表明，超过 80% 的 AWS 开发者以某种方式使用 AI。有时是编写单元测试，有时是帮助编写文档，有时是编写代码，有时是与 AI 代理合作的“代理工作流程”。加尔曼表示，AWS 开发者使用 AI 工具的频率每周都在增加。
加尔曼还为 AI 时代提供了一些职业建议，建议当今的孩子需要学会如何学习——而不仅仅是学习特定技能。他认为应该强调的技能是“你如何独立思考？你如何发展解决问题的批判性思维？你如何发展创造力？你如何发展一个学习心态，让你去学习下一件事？”加尔曼认为，这种方法是必要的，因为技术发展如此迅速，不再合理期望学习狭窄的技能可以维持 30 年的职业生涯。他希望教育者教授“你如何思考以及如何分解问题”，并认为掌握这些技能的孩子将会蓬勃发展。
HN 热度 1130 points | 评论 450 comments | 作者：JustExAWS | 11 hours ago #
https://news.ycombinator.com/item?id=44972151
- AWS CEO 认为使用 AI 替代初级员工是愚蠢的
- 有人认为 AI 编写的代码是混乱的，存在性能和安全风险
- 有人通过使用 AI 减少了 80% 的编码工作，认为 AI 在某些情况下很有用
- 有人认为在某些行业，如 JIT 编译器、关键任务嵌入式系统或分布式数据库中，AI 表现不佳
- 有人认为代码行数不是衡量代码质量的有效指标
- 有人认为 AI 在高度定义和有严格自动化测试的代码库中表现更好
- 有人认为 AI 在处理大量遗留系统集成时特别有用
- 有人认为 AI 可能会加剧代码库的复杂性和技术债务问题
Mark Zuckerberg freezes AI hiring amid bubble fears #
https://www.telegraph.co.uk/business/2025/08/21/zuckerberg-freezes-ai-hiring-amid-bubble-fears/ Meta 公司的创始人马克·扎克伯格（Mark Zuckerberg）冻结了人工智能（AI）职位的招聘，这一举措标志着公司在 AI 领域的大规模招聘热潮戛然而止，原因是担心对 AI 的重金投资并未获得预期的回报。此前，有报道称 Meta 为了吸引顶尖人才，曾提供高达 10 亿美元的薪酬。这一决策反映出扎克伯格对 AI 投资回报的担忧，以及可能存在的 AI 泡沫问题。
HN 热度 655 points | 评论 669 comments | 作者：pera | 13 hours ago #
https://news.ycombinator.com/item?id=44971273
- Facebook 的产品是用户注意力，正在被 TikTok、X 和 BlueSky 等平台取代。
- 人工智能研究可能引起市场的巨大转变，Facebook 可能完全失去他们主要开创的平台。
- 苹果在 AI 投资不足，可能会像黑莓一样如果不适应市场变化就会失败。
- 苹果的 Siri 与 ChatGPT 相比显得落后，1/5 的错误率将是一个欢迎的改进。
- 苹果正在将大型语言模型（LLMs）整合到操作系统级别，很快就会推出。
- 谷歌和苹果不需要 AI，但他们的平台对其他助手封闭，因此必须提供有竞争力的服务。
- 苹果允许其他公司在设备上操作的那一天，这个问题将变得无关紧要。
- 谷歌在 AI 方面做得不错，而苹果还没有。
- 没有看到回报的投资需要多久才会被认为是炒作。
- 有些公司即使有其他收入来源，也可以进行未来进步的研究，这不会影响公司的存亡。
- 这些公司对 AI 的未来方向变化表明，他们和其他人一样对 AI 的未来一无所知。
- 媒体总是说 AI 是我们一生中最大的技术变革，但互联网才是。
- 管理巨额资金/资源的人并不愚蠢，可能是在进行更长远的规划。
- 元宇宙可能是一个例子，有时候你会输。
- 除了收购之外，一切都失败了。
- 抗衰老创业公司是 5D 棋局，第四维度是最不稳定的，很难实现 4D 截击，当你的想法愚蠢时。
- 亿万富翁与普通人、普通员工、普通工作以及普通人拥有的技能和愿望有多少实际经验？
- Meta 过去 12 个月的运营收入为 787 亿美元，是时候紧张起来了。
- Meta 能够部署的现金比他们产生的要多。
- Meta 的现金状况在今年上半年从 440 亿美元减少到 120 亿美元。
- FAANG 已经被 Mag7 取代：Alphabet、Amazon、Apple、Broadcom、Meta、Microsoft 和 Nvidia。
- Meta 的市盈率为 23:1，对于一个成熟公司来说仍然很高。
- 这个数字令人震惊。
- 如何与他们的数据中心折旧成本相比？
Zedless: Zed fork focused on privacy and being local-first #
https://github.com/zedless-editor/zed
Zedless 是一个以隐私友好和本地优先为设计理念的 Zed 软件分支。该项目目前仍在进行中，欢迎贡献。Zedless 计划与上游版本不同的变化包括：不依赖专有云服务，将移除严格依赖非自托管云服务的组件和功能；不包含间谍软件，将移除遥测和自动崩溃报告；优先考虑自带基础设施，任何使用网络服务的功能都将允许用户以标准格式配置使用哪个服务提供商，例如通过指定 API 的基础 URL，并且这些功能默认情况下将被禁用；不要求签署贡献者许可协议，贡献者的版权不会被重新分配；不允许出现 rugpulls（即项目方突然撤资或改变项目方向）。
在许可方面，第三方依赖的许可信息必须正确提供，以便持续集成（CI）能够通过。项目使用 cargo-about 工具自动遵守开源许可。如果 CI 失败，需要检查是否为新创建的 crate 显示无许可证错误，如果是，则需要在 crate 的 Cargo.toml 文件下的 [package] 中添加 publish = false；如果是依赖项的许可证要求未能满足的错误，首先需要确定项目的许可证是什么，以及当前系统是否足以满足该许可证的要求，如果不确定，可以咨询律师。一旦验证系统可以接受，将许可证的 SPDX 标识符添加到 script/licenses/zed-licenses.toml 中的 accepted 数组中；如果 cargo-about 无法找到依赖项的许可证，那么需要按照 cargo-about 书籍中的规定，在 script/licenses/zed-licenses.toml 文件末尾添加一个澄清字段。
Zedless 的主要编程语言为 Rust，占代码的 97.6%，其他语言包括 Inno Setup、Tree-sitter Query、Shell、Metal 和 WGSL。项目目前有 770 个星标，8 人关注，12 个分支。
HN 热度 534 points | 评论 305 comments | 作者：homebrewer | 1 day ago #
https://news.ycombinator.com/item?id=44964916
- Zed 编辑器的隐私和本地优先特性受到欢迎，尽管目前还不够成熟，但用户愿意为其付费。
- 许多用户对 AI 辅助编辑器并不感兴趣，认为它们并未显著提升工作流程。
- AI 代码审查可能引入错误路径或轻易被反驳，可能导致审查过程的懒惰和不彻底。
- 大型语言模型（LLM）本质上是文本生成器，而非验证器，需要人工复审作为最后步骤。
- LLM 在代码库的文本和数值分析方面表现良好，尤其在遵循文档化标准和架构指导时。
- AI 分析的价值在于分析结果后做出的决策，关键在于是否会实际改进代码库。
- AI 审查在初步审查中可能有用，尤其是在小规模层面上。
- AI 审查可以作为高级样式检查器，有助于评估超出标准 linter/分析器范围的标准。
- AI 审查的总结比大多数审查评论更有用，但需要调整期望，因为 AI 不会因建议被拒绝而受伤。
- AI 在代码审查中的目标应该是提高效率，而不是取代人工审查。
- Zed 编辑器除了 AI 功能外，其快速、轻量级的特点和社区支持的插件和主题也受到用户喜爱。
- Zed 作为 GPL 许可的自由软件，其 CLA 可能导致贡献者签署后所有权归 Zed 团队，从而在未来可能重新许可并转为闭源。
Pixel 10 Phones #
https://blog.google/products/pixel/google-pixel-10-pro-xl/
谷歌推出了第十代 Pixel 手机，包括 Pixel 10、Pixel 10 Pro 和 Pixel 10 Pro XL。这些手机搭载了全新的 Google Tensor G5 芯片和最新的 Gemini Nano 模型，提供了更加个性化、主动和有帮助的 Pixel 体验，并带来了刷新的设计和多项硬件更新。
Pixel 10 系列手机采用了现代设计和出色的制造工艺，改进了标志性的相机条，内置了 Qi2 无线充电功能，并提供了一系列新的磁性配件。这些手机使用了迄今为止最多的回收材料制造，首次采用了 Material 3 Expressive 用户界面，带来了更多的个性化和流畅的交互体验。手机将提供七年的 Pixel Drops 以及操作系统和安全更新，确保手机始终保持新鲜感和安全性。
Pixel 10 拥有缎面金属框架、抛光玻璃背面和标志性的相机条。用户可以从四种富有表现力的颜色中选择：Obsidian、Frost、Indigo 和 Lemongrass。其 6.3 英寸的 Actua 显示屏亮度提升至 3000 尼特，使观看更加容易。此外，手机还提供了改进的音频体验，包括出色的低音效果，让您喜爱的节目看起来和听起来都更好。Pixel 10 的相机也得到了显著提升，包括首次在该系列中引入的 5 倍长焦镜头，具有快速自动对焦、10 倍光学质量和高达 20 倍的 Super Res Zoom 变焦能力，使得远距离拍摄更加容易。
Pixel 10 Pro 提供了终极的 Pixel 体验，拥有最高端的设计、最亮的 Super Actua 显示屏和迄今为止最佳的三重后置摄像头系统。Pixel 10 Pro 和 Pixel 10 Pro XL 分别提供 6.3 英寸和 6.8 英寸的屏幕尺寸选择。颜色方面，除了 Obsidian 和 Porcelain，还新增了 Moonstone 和 Jade 两种颜色。Pro Res Zoom 功能使得 Pixel 10 Pro 和 Pixel 10 Pro XL 能够实现高达 100 倍的变焦。Pro 系列手机在几乎所有方面都进行了升级，包括更大的电池、升级的扬声器、16GB 的 RAM 和更快的有线充电，而 Pixel 10 Pro XL 支持 25W Qi2.2 无线充电。
Tensor G5 是谷歌最新的定制芯片，是 Tensor 芯片自首次亮相以来最重要的升级。它提供了快速的性能，并首次为 Pixel 用户带来了深度有用的体验。得益于与 Google DeepMind 的共同设计，最新的 Gemini Nano 模型将在 Tensor G5 上首次运行，解锁许多在设备上的生成性 AI 体验，使日常生活更加轻松。
Pixel 10 引入了 Magic Cue 功能，它能够在您最喜欢的应用中主动提供正确的信息，例如在与母亲通话时找到完美的猫咪照片。Magic Cue 不仅仅是一个单一的应用程序或功能，它是一种主动的支持，紧密地融入您的手机中，提供相关信息和有用的操作。
HN 热度 423 points | 评论 926 comments | 作者：gotmedium | 1 day ago #
https://news.ycombinator.com/item?id=44963939
- 有人认为在设备上运行 AI 模型，如 Magic Cue，对于手机来说是非常有趣的用例。
- 有人期待能够通过语音指令让手机智能地检查日历和数字钱包交易。
- 有人表示自己并不像其他人那样将生活数字化，不使用日历和数字钱包，也不常带手机。
- 有人认为如果没有日历，他们就不会去参加任何活动。
- 有人因为有两个小孩，所以每周大约有 20-30 个“个人”事件需要记录在日历上。
- 有人认为共享日历是管理家庭活动、体育赛事和工作日程的唯一方式。
- 有人表示自己不使用个人日历，只在工作日历上记录工作会议。
- 有人提到，由于忙碌的生活，日历事件、提醒和计时器是他们生活中完成任务的唯一方式。
- 有人表示自己曾经是“技术控”，但现在对新手机和电脑的发布不再感到兴奋，因为它们没有解决他的问题。
- 有人表示，他们对新手机的兴趣主要在于相机的改进，但智能手机相机已经足够成熟，他们愿意使用一部手机长达 4 年。
- 有人提到，除非是通过邮寄信件，否则几乎可以肯定你的生活是以“数字格式”存在的，即使你不使用日历。
95% of Companies See ‘Zero Return’ on $30B Generative AI Spend #
过去三年中，全球公司在生成性人工智能项目上的投资介于 300 亿至 400 亿美元之间，但大多数投资并未带来实际的商业回报。麻省理工学院（MIT）的一项新研究发现，95% 的企业组织报告称采用人工智能工具没有可衡量的收益，只有一小部分看到了显著的好处。
报告指出，仅有 5% 的综合 AI 试点能够创造数百万的价值，而大多数企业则完全没有影响收入或盈利。许多公司急于测试 ChatGPT、Copilot 等大型语言模型平台，超过 80% 的大公司已经探索或试点了这些项目。近 40% 的公司报告称在某种程度上部署了这些系统，但研究发现大多数用例仅限于提高个人生产力，而不是提高公司的整体利润。主要原因是生成性 AI 工具常常无法与实际工作流程相匹配，报告描述了“脆弱的工作流程、缺乏上下文学习和与日常运营的不良对齐”。
与人类不同，大多数生成性 AI 模型无法保留过去的反馈或随着时间的推移建立新的推理能力。它们还难以适应上下文或将经验转移到不同的任务中。报告还降低了对生成性 AI 将在短期内导致大规模失业的担忧，相反，其影响更可能是减少公司的外部成本。这意味着企业可能会削减外包任务的开支，但不太可能很快用机器取代大量员工。这一结论与公众普遍认为生成性 AI 将迅速取代数百万工作的普遍看法相悖。
研究人员认为，这项技术远未达到这样的能力。专家说，许多失败来自于对 AI 能做什么和不能做什么的误解。一个程序可能快速生成文本或代码，但它不能像人类那样真正学习。例如，员工可以根据新指令、以前的错误和情境需求进行调整，而生成性 AI 模型除非重新训练，否则无法将这些记忆跨任务携带。投资者和高管仍然对 AI 表现出浓厚的兴趣，希望持续的进步能够弥补这些差距。但短期内的前景指向比许多人预期的更慢的进展。
研究结果表明，尽管 AI 的前景很大，但企业应该降低期望。这项技术尚未准备好在每个行业或工作流程中交付。报告还强调了围绕采用进行更智能规划的必要性。组织可能需要专注于 AI 可以带来即时、可衡量节省或生产力提升的狭窄用例。这可能包括客户支持脚本、编码辅助或文件起草，而不是全面的公司范围的转型。广泛的整合仍被认为为时过早，容易失败。
HN 热度 382 points | 评论 396 comments | 作者：speckx | 9 hours ago #
https://news.ycombinator.com/item?id=44974104
- 报告指出，50% 的预算用于市场营销和销售，AI 自动化潜力巨大，但很多人对 AI 工具的采纳持保守态度。
- 有人认为，AI 并不失败，而是许多现有员工不愿意采纳新工具，尤其是“影子 AI 经济”问题严重。
- 有观点认为，个人订阅的通用 AI 工具往往比企业定制系统更受欢迎，因为它们更灵活、更易于使用。
- 一些企业员工反映，公司提供的 AI 工具功能受限，不如个人使用的 AI 工具。
- 有人担忧，AI 的发展可能会导致大量工作岗位的消失。
- 有领导角色的人分享，AI 在呼叫中心的应用节省了大量成本，提高了效率。
- 有人建议，不要立即写总结，而是存储通话音频，需要时再生成，以节省成本。
- 有人认为，AI 在数据团队中的应用是直接与经济效益挂钩的。
- 有人指出，一些看似由 AI 解决的问题实际上可以通过传统的机器学习模型解决。
Code review can be better #
https://tigerbeetle.com/blog/2025-08-04-code-review-can-be-better/
这篇文章讨论了作者对 GitHub 代码审查流程的不满以及他们尝试改进这一流程的经历。作者指出 GitHub 在处理堆叠拉取请求和 interdiff 审查方面支持不足，并且他认为代码审查的状态应该作为仓库的一部分存储，而不是通过远程的 Web 界面进行。作者描述了他理想的代码审查工作流程，包括在本地克隆仓库、使用编辑器和 magit 工具来导航代码和差异，并使用 git 暂存区标记已审查的文件。他认为，与代码而不是差异进行审查更为强大，因为这样可以运行测试、获取上下文、尝试重构建议等。
然而，当他需要在 PR 上留下反馈时，他必须打开浏览器，导航到 diff 中的相关行，并在等待多个 HTTP 往返后在文本区域中输入建议。作者认为，审查反馈与代码相关，最自然的界面应该是在代码中留下内联评论，甚至直接修复代码。由于数据存储在远程数据库而不是本地 git 仓库中，这导致了延迟和供应商锁定。
因此，作者开发了 git-review 工具，其核心思想是将代码审查作为一个单独的提交，位于 PR 分支之上，添加带有特定标记的代码评论。审查过程涉及作者和审查者修改这个顶部提交。当所有线程被标记为“已解决”并添加了一个明确的撤销提交时，审查结束，审查内容被保留在历史记录中。
尽管这个想法在理论上是有效的，但在实践中遇到了一些挑战。修改审查中的代码变得复杂，因为审查评论通常添加在块边界上，这导致了冲突。此外，尽管–force-with-lease 是可行的，但它也增加了摩擦。作者认为，代码审查可能需要更宽松的冲突自由合并规则，而代码则需要更强的、基于哈希链的状态转换序列。
最后，作者提到了 git 可能获得 Gerrit 风格的 Change-Id 来跟踪单个提交在重新基础上的修订，这可能会提供对每个提交的 interdiff 审查的一级支持。但这与 git-review 的方法不完全兼容，后者在分支上添加了整个单独的提交。作者希望有人能够受到启发，最终正确地解决这个问题，并提供了一些相关链接，包括 Fossil、NoteDb、git-bug、git-appraise 和 prr 等工具，以及 Jane Street 的代码审查实践，展示了一个更好的世界是可能的，只是尚未普及。作者还提到了 git-pr，这是一个类似项目，利用 git 的原生特性来替代整个拉取请求工作流程。
HN 热度 369 points | 评论 227 comments | 作者：sealeck | 1 day ago #
https://news.ycombinator.com/item?id=44967469
- 代码审查通常在开发过程中发现问题太晚，导致需要重新设计或放弃项目。
- 代码审查似乎是唯一让所有利益相关者真正参与并思考变更的时候。
- 在软件工程领域，很少有工程实践，因为大多数软件的非关键性和可以即时修正错误。
- 其他工程领域没有软件工程的这种灵活性，例如桥梁、制造厂或飞机引擎没有修正错误的机会。
- 大型企业项目中存在设计审查，但被“真正的开发者”看不起。
- 在许多国家，要自称为软件工程师，必须持有经过认证的大学或专业学院的正式学位。
- 即使没有完成学位，也可以成为优秀的开发者。
- IT 领域有可能自学所有知识，并且比一成不变的课程学得更好。
- 有理论背景的学位在某些罕见时刻非常有用，而自学开发者可能意识不到自己缺少这些知识。
- 学位并不能保证你具备特定技能或保留信息，只是说明你通过了考试。
- 许多杰出的工程师没有毕业，例如达芬奇、卡马克、扎克伯格等。
- 工程技能是通过学习意愿和解决问题的意愿获得的，可以通过电脑观看顶级课程来获得。
- 在软件工程中，编写代码实际上是设计阶段，不需要为设计而设计的设计阶段。
Weaponizing image scaling against production AI systems #
https://blog.trailofbits.com/2025/08/21/weaponizing-image-scaling-against-production-ai-systems/
这篇文章讨论了一种新型的攻击手段，即利用图像缩放漏洞对生产中的人工智能（AI）系统进行攻击。攻击者通过发送一张看似无害的图片给大型语言模型（LLM），在图像被缩放后，图片中隐藏的提示注入（prompt injection）可以导致用户数据泄露。这种攻击之所以有效，是因为 AI 系统在处理大尺寸图片时通常会先将其缩小，缩放后的图片可能暴露出在原始分辨率下不可见的提示注入。
文章详细介绍了如何利用图像缩放漏洞攻击 Google Gemini CLI、Vertex AI Studio、Gemini 的网页和 API 接口、Google Assistant、Genspark 等生产 AI 系统，并解释了如何防御这些攻击。作者还介绍了他们开发的开源工具 Anamorpher，该工具可以帮助用户探索和生成这些精心设计的图像。
文章指出，图像缩放攻击过去主要用于模型后门、规避和投毒，主要针对那些强制固定图像大小的旧计算机视觉系统。尽管这种限制在新方法中较少见，但模型周围的系统可能仍会要求图像缩放，从而产生一个未被充分曝光但普遍存在的漏洞。
文章还提到了通过 Zapier MCP 服务器设置的数据泄露漏洞，以及如何通过图像缩放攻击在没有用户确认的情况下，将用户数据从 Google Calendar 泄露到攻击者的邮箱。此外，文章还展示了在其他平台上成功演示的图像缩放攻击，并强调了用户感知与模型输入之间的持续不匹配问题。
文章进一步探讨了图像缩放攻击如何利用下采样算法（或图像重采样算法），这些算法通过插值将多个高分辨率像素值转换为单个低分辨率像素值。文章介绍了三种主要的下采样算法：最近邻插值、双线性插值和双三次插值，并指出这些算法在不同库中的实现差异，以及这些差异如何影响图像缩放攻击的技术需求。
最后，文章解释了为什么图像下采样攻击是可能的，通过类比说明了采样率低于一定阈值时无法清晰重建图案的奈奎斯特-香农采样定理。Anamorpher 工具可以为上述三种主要方法开发精心设计的图像，文章展示了 Anamorpher 如何在双三次插值中逐帧利用这一技术。
HN 热度 307 points | 评论 80 comments | 作者：tatersolid | 12 hours ago #
https://news.ycombinator.com/item?id=44971845
- 通过任务特定层级划分可以解决提示注入问题，上层 LLM 不需要知道下层任务的具体内容，可以对返回结果进行消毒。
- 提示注入攻击通过在图像上隐藏文本实现，即使图像被缩放，文本依然可以被 AI 读取。
- 利用图像缩放技术可以使图像看起来完全不同，这种攻击方式令人担忧。
- 需要为 VLMs 制定 OWASP 指南，以覆盖所有可能的攻击方式。
- VLMs 是结合了 LLM 和图像编码器的模型，可以识别图像内容并给出文本描述。
- Dall-E、Midjourney 和 Stable diffusion 等模型是在 VLM 出现之前构建的，它们是匹配文本和图像输出的扩散模型。
- VLMs 可以读取图像中的文本并信任它，这是一个严重的问题。
- 攻击者可以利用图像在不同分辨率下显示不同内容的特性进行攻击。
- AI 不需要运行外部 OCR 过程就能理解图像中的文本，这是其多模态系统的一部分。
- 任何非提示部分都不应成为提示的一部分，除非触发了某些机制。
Bank forced to rehire workers after lying about chatbot productivity, union says #
澳大利亚最大的银行——澳大利亚联邦银行（CBA）在声称聊天机器人能够处理更高的呼叫量并取代员工后，被迫重新雇佣 45 名员工。澳大利亚主要金融服务工会（FSU）声称这是 45 名工会成员的“巨大胜利”。CBA 曾宣布，推出聊天机器人导致每周呼叫量减少了 2000 个，但 FSU 表示这是“彻头彻尾的谎言”，实际上在解雇员工时呼叫量正在增加，银行不得不提供加班并重新分配管理层以应对增加的呼叫量。
在公平工作法庭的审理中，CBA 承认没有考虑到在解雇员工期间出现的呼叫量增加会持续数月，因此这些角色并非多余。CBA 向被解雇的员工道歉，并表示他们可以选择回到原来的岗位、寻找其他职位或带着离职补偿离开。全球银行预计在未来三到五年内因 AI 的预期应用将削减高达 20 万个工作岗位，CBA 的这一逆转表明，一些银行可能会急于推进 AI 项目而未经充分理解其对业务的潜在影响就解雇员工。
尽管如此，CBA 并未因此放慢脚步，上周宣布与 OpenAI 合作，探索先进的生成性 AI 解决方案，以加强欺诈检测并为客户提供更个性化的服务。CBA 表示，该银行的目标是“投资于员工及其 AI 能力，以便他们能更好地支持客户”并在其员工队伍中嵌入负责任的 AI 使用。
HN 热度 270 points | 评论 109 comments | 作者：ndsipa_pomu | 8 hours ago #
https://news.ycombinator.com/item?id=44974365
- 聊天机器人处理客户支持问题的成功率很低，不到 5%，公司应将客户支持视为建立信任和加强业务关系的机会
- 与聊天机器人互动通常只是更糟糕的搜索支持网站界面，无法解决问题
- 对于技术人士来说聊天机器人不适用，但对其他 90% 的人来说可能适用，他们宁愿打电话浪费时间
- 公司应提供“高级支持”选项，直接绕过聊天机器人和一线支持，对于因自身问题导致需要支持的呼叫收取费用
- 客户支持应该是友好和支持性的，不应该主动对抗或挑战客户
- 美国工人与外包工人的比例约为 1:3-8，雇佣美国工人管理高级客户服务的成本不值得
- 有美国本土工人处理升级问题，建议允许用户自我升级并支付浪费时费用
- 有些情况下，与聊天机器人的互动会导致循环，难以直接联系到人工支持
- 与聊天机器人互动浪费时间，最终仍需联系人工代表解决问题
- 客户服务中缺乏合格的升级途径，完全依赖随机分配的人工代表，无法自助解决问题
- 客户服务体验糟糕，没有人能够升级处理，完全受制于系统随机分配的人工代表
- 为了减少推销和保留客户的麻烦，有人谎称搬到另一个州来取消有线电视服务
- 如果客户仍然每月支付费用，Xfinity 没有动力做出任何改变
Using Podman, Compose and BuildKit #
https://emersion.fr/blog/2025/using-podman-compose-and-buildkit/
本文介绍了作者在日常工作中如何使用 Podman、Compose 和 BuildKit 来构建和运行 Docker Compose 项目。由于 Docker 与 nftables 不兼容，作者选择了无守护进程、无需 root 权限的 Podman。Podman 提供了两种支持 Docker Compose 项目的解决方案：一种是将官方 Docker Compose CLI 连接到 Podman 套接字，另一种是使用 Podman 的替代方案。但这两种方法都有缺点，使用官方 CLI 时不会使用 BuildKit 构建器，而使用 podman-compose 替代方案时会缺少一些功能。
作者探索了如何让 Docker Compose CLI 在 Podman 下启用 BuildKit。通过直接使用 Docker Compose CLI 而不使用 wrapper，可以在 Arch Linux 上通过启用 Podman 套接字和创建新的 Docker 上下文来实现。这样，docker compose 就可以正常工作，并且会自动创建一个 buildx_buildkit_default 容器来运行 BuildKit 守护进程。
为了不使用守护进程，作者尝试了自己运行 BuildKit 守护进程，并使用 systemd 管理。然后，作者介绍了如何将 Compose 项目转换为 JSON 格式的构建命令描述，称为 Bake。通过设置 COMPOSE_BAKE=true，Docker Compose CLI 将使用 Bake 文件。作者开发了一个名为 Bakah 的小工具，它可以将 Bake 文件转换为 Podman 构建 CLI 参数，并使用 Buildah（Podman 底层使用的构建镜像的库）而不是直接调用 Podman。
Bakah 工具虽然缺少一些高级的 Bake 功能，但足以构建复杂的 Compose 项目。作者计划将来使用 Bakah 来更好地分割 Dockerfiles，并移除 CI 脚本中的 Podman CLI 调用。作者希望 Bakah 对其他人也有帮助。
HN 热度 237 points | 评论 76 comments | 作者：LaSombra | 13 hours ago #
https://news.ycombinator.com/item?id=44971212
- Podman 可以利用 Kubernetes 风格的部署语法实现类似 docker-compose 的功能，并与 systemd 集成良好，方便管理容器化服务。
- Podman 的 .kube 文件在指定容器网络时存在问题，但可以通过使用 Quadlet 文件解决。
- Buildah 允许在单个层中运行多个命令，并支持循环和分支，因为它使用的是脚本语言而非 Dockerfile。
- Podman 和 Incus 都利用 Linux c-group 技术进行容器化，性能大致相同，但 Incus 专注于系统容器，而 Podman 和 Docker 专注于 OCI 容器。
- 可以使用 Ansible 和 Podman 作为 Kubernetes 的简单替代方案，通过 SSH 到服务器并使用 Podman 启动容器。
- 在引入 Kubernetes 之前，可以通过垂直扩展和几个固定节点来实现相当程度的扩展。
- Fedora CoreOS 作为不可变的基础操作系统，配合定期自动更新，可以很好地工作。
I forced every engineer to take sales calls and they rewrote our platform #
我们那位资深的 DevOps 工程师以为我疯了。他加入一家初创公司可不是为了干销售的。于是我跟他谈条件：他只要打 5 通电话，我保证他以后再也不用干这事。来回拉锯了一会儿，但我坚信，这次经历从根本上改变了我们做产品的方式。
我旁听了几通电话，观察到几点：
- 亲耳听他们解释为什么竞争对手的平台“对非技术用户来说太复杂”。
- 亲耳听他们向客户保证持续监控确实在运行（我们有漂亮的日志和指标，但客户只想要一个绿色对勾）。
- 亲耳听客户问“能不能直接帮我搞定？”时他们的回应。
我们团队大多数也是后端工程师，我觉得这让他们成了更出色的产品设计师。最后，他们没等我这个 PM 指手画脚，自己就画出了完全不同的架构图。因为他们终于明白到底是谁在用我们的产品。
重构只花了两周。我们砍掉了 60% 的功能，加了个简单的进度条，做了 Slack 集成来答疑，还推出了“交给我们搞定”的工作流。
工单量骤降 70%。
大多数工程师最大的毛病其实是过度设计。
用户不在乎你的方案多么优雅——他们只关心自己的问题有没有消失。
技术正确性 < 用户理解——如果他们用不了，代码写得再好也白搭。
每个功能都有成本——不是代码成本，而是让用户困惑的成本。
从那以后，我把这变成了团队的硬性文化：每个工程师每季度必须打 5 通销售电话。总会有点抵触，但当客户疲惫地说“我只想让这东西能用”时，一切都值了。我觉得这能帮他们养成直觉。
HN 热度 235 points | 评论 165 comments | 作者：bilsbie | 8 hours ago #
https://news.ycombinator.com/item?id=44974230
- 工程师参与销售电话后能更好地理解客户需求，从而改进产品架构。
- 产品经理可能没有很好地在客户和工程师之间沟通，导致工程师更了解用户需求。
- 工程师可能过于自信，忽视了用户的实际使用体验和产品设计问题。
- 工程师直接面对用户的反馈可以减少他们的自负，促使他们改进产品。
- 工程师通常比产品经理更有产品开发经验，但缺乏对客户痛点的了解。
- 许多产品经理缺乏产品开发、客户服务或业务扩展的实际知识。
- 技术背景的产品经理可能因为过于关注技术问题而忽视了业务需求。
- 产品经理的角色往往更侧重于企业政治和向高层管理讲述引人入胜的故事。
Hacker News 精彩评论及翻译 #
I forced every engineer to take sales calls and th… #
https://news.ycombinator.com/item?id=44974574
At the end of it, they were sketching a completely different architecture without my “PMing”. Because they finally understood who was actually using our product.
I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/actionable at turning customer needs into working solutions.”
dcastonguay
最终，他们没有我这个“产品经理”的参与，就设计出了一个截然不同的架构。因为他们终于明白了我们的真正用户是谁。我不禁将这段经历解读为：“我们强迫一位工程师去接听销售电话，结果发现，真正的问题在于我们的产品经理在客户与工程团队之间的沟通工作做得极其糟糕，而我们的DevOps工程师在将客户需求转化为实际可用解决方案方面反而更具能力、更高效。”
AWS CEO says using AI to replace junior staff is ‘… #
https://news.ycombinator.com/item?id=44972416
He wants educators to instead teach “how do you think and how do you decompose problems”
Ahmen! I attend this same church.
My favorite professor in engineering school always gave open book tests.
In the real world of work, everyone has full access to all the available data and information.
Very few jobs involve paying someone simply to look up data in a book or on the internet. What they will pay for is someone who can analyze, understand, reason and apply data and information in unique ways needed to solve problems.
Doing this is called “engineering”. And this is what this professor taught.
jqpabc123
他希望教育工作者转而教授“如何思考以及如何分解问题”。
完全正确！我信奉的是同一种理念。
我在工程学院最喜欢的教授总是进行开卷考试。
在现实的工作世界中，每个人都能接触到所有可用的数据和信息。
几乎没有工作是单纯为了让人去书里或网上查找数据而付钱的。他们真正愿意付费的，是那些能够以解决问题所需的方式，去分析、理解、推理并运用数据和信息的人。
这就叫做“工程学”。而这位教授所教的，正是这一点。
Sequoia backs Zed #
https://news.ycombinator.com/item?id=44963229
I love the spirit of Zed. From the principles to the low-level implementation details, it all screams “good taste”. It’s immensely interesting as an object of study (the code is great, from GPUI all the way up).
Having said that, I don’t think an editor should be VC backed. It’s the obvious pragmatic choice to get a team together to support a thing, but I’m concerned by it.
mccoyb
我很欣赏 Zed 的精神。从它的设计原则到底层的实现细节，都透露出绝佳的品味。作为一个研究对象，它特别引人入胜（代码非常出色，从基础架构 GPUI 直到上层都一样）。
话虽如此，我不认为一个编辑器应该有风投背景。这固然是组建团队来支持它的一个务实、明智的选择，但也让我感到担心。