大家好 欢迎收听黑客新闻中文日报在今天的节目中 我们将深入解析最新公开的 Cloud 4 System Card 带大家看看新一代大语言模型背后的数据来源推理链保留机制 以及它们在安全与防护方面的表现我们还会聚焦开源多模态模型 Bagel 它的能力正在逼近商业巨头同时带来了哪些全新特性和机会
此外,还将和大家讨论大语言模型在实际开发中的真实价值,它真的能替代开发者的日常工作吗?本期内容不容错过,马上带你进入本期焦点。ThreeRings 的创始人发现,自己的私人手机号被 Google 公开显示在了 Google 搜索的 ThreeRings CIC 企业信息当中,甚至还加了一个一键拨打电话的按钮。
实际上,这个手机号只是他之前在身份验证时提供给 Google,原本是给 Google 内部审核用的,并没有授权对外公开。最近连续接到几通陌生用户打来的技术支持电话,他才注意到手机号被自动公开了。他随即登录 Google Business Profile,发现自己的个人手机号正被显示在对外页面上,只能手动将其删除,之后陌生来电才恢复正常。
作者表示,自己并没有收到任何提醒或解释,至今也不清楚是 Google 系统自动抽取手机号,操作失误还是其他原因有网友评论,其实很多平台会从公开信息、注册信息或商业注册资料中自动抓取手机号,不同地区的法规标准也各不相同也有人提到,手机号混用私人和工作身份时,更容易出现信息泄露的问题
有的网友补充说,只要用 Google Search,几乎所有人都可以随时修改企业资料,包括电话,确实存在一定风险。最新分析显示,Lieferando 的目前占有大约 5.7%德国与餐厅相关的域名约有 1100 个活跃域名,指向这家外卖平台。这些域名并不是直接跳转到 Lieferando,而是显示其标志和链接。
数据还提到,德国餐饮业在 2019 年到 2023 年期间,许多餐厅的网站已经被放弃或被第三方企业接管,反映出行业在这几年内的困境。有网友评论称,这种操作在美国的 GrabHub 也曾经出现,甚至未经餐厅同意就在各大平台创建网站和发布信息。
有些人担心类似做法增加了中小餐厅的经营难度部分小企业主不仅要应对市场压力还很难在法律上维权也有人提到这说明传统网站和域名模式对普通商家来说越来越复杂很多人更愿意用社交媒体来展示自己 Hacker News 社区每月一次的 What are you working on 话题又来了
许多用户分享了他们正在开发的项目比如有开发者在 BootDev 平台上推出了互动编程课程但他们遇到的挑战是课程进度推进太快缺少足够的练习环节他们目前正着手优化目标是在 8 月份上线更新也有网友用 GODED 和 RUST 做了一个太空船控制类小游戏利用 6502 电脑模拟推进器和传感器等设备不过想让游戏变得有趣还是有难度因此正在借鉴深圳 IEO 的关卡设计
还有人为了方便和家人朋友分享生活动态和照片自主开发了一款开源邮件通讯应用主打自托管和极简易用性还计划支持多语言社区里热心网友普遍对这些作品表达了鼓励认为技术创新不一定非要大投入小切口也能解决实际问题而不少人也交流了自己隐私和自托管需求期待更多类似项目涌现大家热情的建议开发者早日发布测试版让更多人能参与反馈和体验
诺姆·乔姆斯基在最近一次采访中谈到,虽然 ChatGPT 这类人工智能工具的技术应用范围非常广泛,甚至能在社会、科学等多个领域带来价值,但它们并没有加深我们对人类自身智能的本质和构成的理解。
他认为当前大语言模型包括 ChatGPT 更多属于工程范畴,可以很好的完成文本生成,自动补全,翻译等实际任务,但它们本身并不具备像人类一样的符号推理或逻辑能力,无法像科学研究那样解释语言和认知等复杂问题。
乔姆斯基指出,大语言模型靠的是对大量数据的统计学习,通过输出看似合理的内容实现模拟,但并没有真正的理解或创造性,更无法区分哪些是可能的,哪些是不可能的语言,这和人脑的本质机制有明显的不同。他还提到,尽管 AI 技术可以带来好处,但也存在被滥用、误导,甚至带来新的伦理和安全风险的隐患,因此技术进步要和社会监管共同推进。
有网友评论说,现在人们常容易被大模型惊艳到,但其实这并不能说明他们真的像人一样有心智。还有网友表示,不应只关注 AI 在实际任务上的表现,而是要警惕它和人类智能之间的根本差异。此外,也有人认为,讨论人工智能应该回归到科学本质,不要过度相信炒作。
JSON Web Token 作为一种基于 JSON 的安全令牌格式已经诞生 10 年,这期间它和相关标准被广泛采纳,也让各类 Web 应用和身份验证体系变得不可或缺。
JWT 的设计目标是让开发者能用简单的数据结构和加密方式传递身份信息经过一轮又一轮的实践与迭代发布方团队也持续根据社区反馈推出最佳实践指南比如对常见的安全隐患和易错点提出规避建议新增更安全的密钥和算法配置近几年团队还根据新暴露出来的攻击手法对现有标准进行修订和补充以确保下一个十年内 JWT 仍然能满足主流应用的安全需求
从社区留言来看,不少开发者认为 JWT 虽然很流行,但实际使用中场景有限,而像权限、状态实时性和密钥管理等问题依然需要更好的方案,有人还分享了相关工具链或者视频资源,大家对未来身份验证技术的发展也充满期待。Design Pressure 这个主题探讨了在软件开发中无形的设计压力如何影响代码结构。
演讲者 Heinexlerwag 结合了实际开发经验,指出即使项目一开始严格遵循最佳实践,随着需求变迁和团队合作,架构仍然会出现各种意外的演变。他强调,设计压力往往是一种直觉的感受,需要反复打磨和积累经验来培养。很多时候,开发者需要在数据驱动的设计与业务领域模型之间做权衡,决定是直接使用数据库结构,还是引入单独的领域模型和映射。
实际工作中,何时做切换并不容易判断,需要对项目的未来变化有一定的预判能力。有评论认为,所谓的设计压力更像是一种品味,需要长期关注系统的演化和团队的实际痛点才能体会到。也有人提到,架构上的抽象和实践要拿捏好度,否则一味追求最佳实践,反而可能带来困扰。
整体来看,网友们普遍希望类似的主题能有更多干货分享,也有讨论认为过度抽象或刻意分层有时并不一定适合每个项目。有开发者用大约 100 行 Python 代码,自己编写了一个 Cops 的打印机驱动,用来支持 UITL 加这款热敏票据打印机。事情的起因是,这类打印机往往只提供 Windows 驱动,而 Linux 用户如果需要进行高质量的票据打印,就必须自己动手解决兼容问题。
作者分析了打印所需的协议转换流程,在 Linux 下搭建了 Cops 服务,并用 Python 实现了 Cops Filter,把 Cops 接收到的灰度点阵数据转换为 FGL 协议,让打印机可以正常输出图片格式的票据。此外,还需要编写对应的 PPD 文件,包含切刀设置和不同纸张尺寸的选项。最后,将代码和配置放在指定路径,就能实现在 Linux 下顺利用 UITL 加打印票据。
评论区里有网友分享了类似的动手经历表示通过自定义驱动延长了老打印机的寿命也有人建议普及热敏打印纸的健康风险还建议选购无 BPA 或 BPS 的安全纸张还有人指出 Cops Filter 其实可以更短用不到 100 行代码就能实现 Bagel 是一个刚刚开源的统一多模态模型用户可以根据自己的需要进行微调 蒸馏和部署它的能力已经可以对标 GPT-4O 和 Gemini 2.0 这样的商业系统
Bagel 可以同时处理文本和图片输入输出,不仅能进行生成,还支持图像编辑、风格迁移、场景导航等复杂任务。它基于大量视频和网页的多模态数据进行预训练,因此能够自动理解并处理复杂的视觉和文本信息,比如生成高清、真实感强的图片和视频帧,把简单描述转化成细致、有逻辑的输出。
此外,Begel 采用了 MOT 架构,也就是多 Transformer 专家混合模型,还用上了双编码器,同时捕捉图像的像素和语义信息,提升了对视觉和文本内容的理解。根据公开的基准测试,Begel 在多项理解和生成任务中都优于其他开源多模态模型,比如在 MMBench 和 MMVet 等标准测试集上表现领先。
评论区不少网友表示,这样高质量的开源多模态大模型非常稀缺,希望能尽快试用,有人分享了模型的压缩版,可以用高端消费级显卡跑起来,但对硬件要求还是挺高的。讨论中也有网友提出,目前多模态通常还不包括语音,期待以后能支持更多类型的数据。
有开发者在社区中发起讨论,表示自己很难真正从编码类的大语言模型中获取实际价值他们发现 LLM 在没有接触过的新框架或者库时能够给出可用的初步代码,能帮助解决一些基础问题,比直接查文档更省时间不过,对于自己已经熟悉的任务,或者需求比较明确的情况下,大语言模型的作用就有限了
而且很多人反映,LLM 生成的代码往往仅适合小型的自包含组件,比如简单的 react 组件、纯函数,或者是流行框架下的模板代码。但一旦涉及到跨文件,需求变化较多的大型功能时,模型就容易出错,用户往往需要反复修改才能达到满意效果,甚至可能需要花更多时间去修正 LLM 带来的混乱。
有工程师觉得,LLM 最适合用来处理枯燥又重复的代码、查缺补漏,或者是在自学新知识时提供参考,但它解决不了复杂架构和难题,还是需要开发者自己把控核心设计和实现。有评论补充,LLM 在辅助初级开发人员,自动生成部分脚本和出版代码方面帮助很大,但随着用力复杂度提升,其性能和效率也会显著下降。
有网友提到,虽然 LLM 能显著提升部分人的生产力,但距离全面替代资深工程师还很遥远,也有用户指出在生成一次性脚本,自动化小工具时确实能省不少精力。
感谢收听今天的黑客新闻中文日报希望这些最前沿的科技动态能为你启发思考丰富视角如果你觉得节目有收获欢迎订阅我们的播客并将精彩内容分享给朋友祝你拥有愉快的一天我们下期再见