佬友如果方便，请说下这些信息，有助于我来选择 1、车辆型号，购买年限，估计还能用多久，排量，发动机型号，变速箱类型等信息 2、驾驶舒适性，油耗等，使用体验比如大概多久维修一次 3、后续换车，还会买这个型号或者这个品牌吗 1 个帖子 - 1 位参与者 阅读完整话题
服务失联，一看 vps 掉线了，rn LA 机房真是多灾多难 2 个帖子 - 2 位参与者 阅读完整话题
假如做电脑维修的，会很方便。可以快速诊断问题。 github 地址： https://github.com/swyongqiang1-stack/HardwareDiagnosticsTool ======================================================= Windows 笔记本异常重启硬件诊断报告 ======================================================= 生成时间: 2026-06-06 20:05:30 检测范围: 系统崩溃日志、WHEA 硬件日志、Kernel-Power 事件、磁盘与内存诊断 [系统运行状况汇总] • 检测到共发生 12 次非预期重启/断电记录 (Event ID 41)。 • WHEA 硬件架构检测到共计 85 次硬件报错。 [初步诊断结论] 疑似存在故障的物理部件: 未发现明确的硬件故障指标（可能属于纯软件、驱动冲突或 系统损坏） [硬件异常评分排序（分数越高代表可能性越大）] • 内存 (RAM): 0 分 • 处理器 (CPU): 0 分 • 硬盘 (Storage): 5 分 • 电源/散热保护: 24 分 • 显卡 (GPU): 10 分 [底层关键诊断证据] • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/06/2026 17:52:56)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/05/2026 15:16:02)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/05/2026 13:31:25)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/04/2026 21:39:26)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/04/2026 20:40:32)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/04/2026 14:00:59)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/04/2026 13:36:22)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 06/04/2026 12:26:27)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 05/29/2026 12:26:25)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 05/22/2026 20:13:12)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 05/22/2026 18:31:51)。通常与主板供电、电源、电池或瞬间过热保护有关。 • 发生瞬间断电或硬件挂死 (Bugcheck 0 ，无蓝屏，发生时间: 05/06/2026 09:01:50)。通常与主板供电、电源、电池或瞬间过热保护有关。 • WHEA 硬件错误记录 (ID: 17, 时间: 05/17/2026 15:23:21)。 • -> [最近事件] 检测到 PCIe 总线错误，可能关联显卡、无线网卡或 M.2 固态硬 盘。 • WHEA 硬件错误记录 (ID: 17, 时间: 03/25/2026 21:57:52)。 • -> [最近事件] 检测到 PCIe 总线错误，可能关联显卡、无线网卡或 M.2 固态硬 盘。 • WHEA 硬件错误记录 (ID: 17, 时间: 03/25/2026 21:57:42)。 • -> [最近事件] 检测到 PCIe 总线错误，可能关联显卡、无线网卡或 M.2 固态硬 盘。 • WHEA 硬件错误记录 (ID: 17, 时间: 03/25/2026 21:57:40)。 • -> [最近事件] 检测到 PCIe 总线错误，可能关联显卡、无线网卡或 M.2 固态硬 盘。 • WHEA 硬件错误记录 (ID: 17, 时间: 03/25/2026 21:57:27)。 • -> [最近事件] 检测到 PCIe 总线错误，可能关联显卡、无线网卡或 M.2 固态硬 盘。 [排查建议清单] 1 若该批次笔记本大面积出现此现象，且日志中多为 Bugcheck 0 （瞬间断电）， 请优先排查适配器/电池故障，或主板供电设计缺陷。 2 检查是否有统一安装的第三方安全软件 或低版本驱动导致的冲突。
大家能用吗？报错 API Error: 529 Overloaded. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com . 2 个帖子 - 1 位参与者 阅读完整话题
不重置估计只能升级20x了，大家觉得会重置吗？ 2 个帖子 - 2 位参与者 阅读完整话题
好像是崩了吗？大家是这样的吗？ 我的账号还被提示：This organization has been disabled. 是因为这个故障吗？ 6 个帖子 - 4 位参与者 阅读完整话题
事情的起因是一个星期前，准备把显卡拆下来稍微吹一下灰。因为风扇挡着手实在是不太能伸进去，我以为卡扣已经打开。一拔，主板上PCIE显卡插槽坏了，因为只有一个插槽，就只能换主板。 现在配置是7500F+6750GRE 10G。 我想了一想以后也得升级，换了一张技嘉 B850M FORCE WIFI6E战鹰。 主板到了后兴高采烈的装上主板，重装系统，技嘉官网下载对应各类驱动，AMD官网下载最新驱动，BIOS更新到最新版本。然后来一波烤机，除了FPS很低以外（也没注意），一切貌似都正常。 打开的常玩的游戏，某某无间，懵了，怎么这么卡。 大概的事情就是这样，发帖期间已经过去好几天，系统重装好几次，驱动也装了无数次，各种高性能电源计划，AMD驱动设置，BIOS恢复默认设置，游戏设置等都试了。甚至我还新买了一跟DP线和电源。还是无法解决，现在求助各位捞，烤机貌似还算正常，频率功耗都能上去，温度也正常。但是一旦进游戏就不正常，感觉显卡他就是不工作，甚至我以为这款游戏原因，我还下载了LOL，同样如此，玩LOL都卡，这可怎么办。到底是显卡故障，主板故障，还是系统驱动等故障啊，已经分不清了。求助，在线等！！ 3 个帖子 - 3 位参与者 阅读完整话题
IT之家 5 月 30 日消息，据 @广州南车站 消息，受贵广客专钟山西至恭城间供电设备故障影响，今天由广州南站开往大理的 G2976 次、开往巫山的 G2250 次、开往桂林北的 G3746 次旅客列车临时停运。铁路部门提示，已购买今天相关停运列车车票的旅客，可通过铁路 12306、自助售取票机、车站窗口办理退票、改签业务， 均不收取手续费 。 据极目新闻报道，今天上午，从广州南开往四川广元的 D1804 次列车因受电弓遭异物击打，被困在贺州一处隧道内。当天 11 时 20 分许， 车上有乘客称他们已被困超两小时 ，列车内停电，非常闷热。 IT之家注意到，桂林火车站目前已经对此次事件发布官方通报。 11 时 10 分公告 5 月 30 日 9 时 19 分，因贵广客专钟山西至恭城间，列车受电弓受异物击打，导致设备故障，D1804 次列车临时停车，部分途经该区段的列车晚点运行。铁路部门第一时间启动应急预案，及时打开临停列车车门通风，备用列车预计 11 时 30 分左右赶至故障地点进行转运。 由此给您带来不便，铁路部门深表歉意！敬请旅客关注列车开行时刻变化，具体信息详见站车公告或拨打 12306 铁路客服中心电话咨询。 12 时 36 分公告 经铁路部门应急处置，D1804 次列车 12 时 28 分已转移至恭城站，车上旅客正从 D1804 次向备用列车转运，预计 13 时左右转运完毕，备用列车向桂林方向开行。 受此影响，部分途经该区段的列车晚点运行。由此给您带来不便，铁路部门深表歉意！敬请旅客关注列车开行时刻变化，具体信息详见站车公告或拨打 12306 铁路客服中心电话咨询。 13 时 18 分公告 经铁路部门应急处置，D1804 次列车 13 时 06 分从恭城站开车，贵广客专钟山西至恭城间的列车运行秩序正逐步恢复。 由此给您带来不便，铁路部门深表歉意！敬请旅客关注列车开行时刻变化，具体信息详见站车公告或拨打 12306 铁路客服中心电话咨询。
开帖说一件最近发生的事，也是我们开店以来第一次遇到这种情况，不吐不快。 事情经过： 之前在我们这换过电池的一位老客户，介绍了一个朋友过来，说手机是iPhone 15 Pro Max，进过水，目前会重启、充电异常，后盖也碎了。 我们师傅插上充电器确认了确实有充电异常和重启的问题，手机有轻微进水痕迹。跟客户沟通后，经过同意进行了拆机检修------把电池拆下来，对内部进水区域做了清洁，对电池主板、排座等进行了全面清理。 清理完重新装上，电池数据正常读取了，重启也恢复正常。说白了，故障已经帮你除掉了。 关于报价： 我们提前报过价格，换电池大概2000，后盖大概500。客户说暂时不换电池，后盖也问有没有便宜的，我们又给他报了副厂后盖加手工大概200。还没等我们说完，他就打开了抖音问我们团购能不能用------团购链接跟实际维修项目根本不是一回事，用不了。我们也解释了，价格已经很实在了，该报多少报多少。 客户听完没说什么，让我们把手机装回去。装好后说了句谢谢，拿着手机就走了。 按正常维修流程，拆机检测检修收个80-100的手工费，完全合理。我们当时收的80。 然后，离谱的来了： 客户走了不到五分钟，可能刚下楼，我们直播间主播还在直播就接到电话------有人在直播间投诉，说团购无法核销、有售后问题。 你当面跟人讲了、解释清楚了，团购根本用不了，为什么还要跑去直播间投诉？说白了就是不信任。跟你现场讲你不信，非要跑到网上以投诉的方式去问。 而且价格跟团购就差个二三十块钱。我们已经尽量压低了价格，电池也没换、后盖也没修，就收了80块拆机检修手工费------连这个都要逃？ 更绝的在后面： 我们联系了那位介绍过来的老客户，表达了我的态度：投诉已经投诉了我不追究，但师傅的劳动成果该付的手工费你得付吧？ 结果这位老客户帮对方说话，说我们就是想要钱。我们要她提供新客户的联系方式沟通一下，她拒绝了。让她打个电话协调一下，磨了半天，最后直接把我们拉黑了。 我们没办法，只能通过其他渠道找到这位女性老客户的抖音号，把维修收据拍照发过去尝试联系。结果呢？她把抖音号都改了，连账号信息都删除了------摆明了就是"你也找不到我"的态度。 我想说的是： 我们真的不是缺那几十百来块钱。我们缺的是相互信任和相互尊重。 师傅花了时间帮你拆机检修，解决了故障，时间是值钱的。别人十几二十分钟帮你把问题搞定了，你一句话把人打发了？没有这样做生意的。 我们是工作室，做的基本都是老客带新客的生意，靠的就是信任。如果每个做维修的都碰到这种白嫖的客户，那以后谁还敢提供免费检测？是不是只要客户来检测，哪怕不拆机也要收检测费？ 我们不希望一颗老鼠屎坏了一锅粥，拉高所有人的维修门槛，让真正有需要的人都没法享受免费检测的便利。 这是我开店以来遇到的第一次、也是唯一一次，印象非常深刻。靠拉黑、靠逃避、靠改账号来解决问题，这种行为真的很low。 附上视频链接 事件视频 目前报jc也没办法没有联系方式 1 个帖子 - 1 位参与者 阅读完整话题
不是哥们这是什么鬼 21 个帖子 - 15 位参与者 阅读完整话题
IT之家 5 月 28 日消息，微软更新其支持文档，承认 Windows Server 2016 安装 5 月 12 日发布的 KB5087537 后， 可能会出现域控制器查找故障。 根据更新日志内容，微软表示在 Windows Server 2016 上，如果主机名长度超过 15 个字符，DCLocator 相关调用可能失败。IT之家附上相关截图如下： 例如主机名使用 nltest /dsgetdc: /pdc 之类的 DCLocator 调用，在安装本次更新后，Windows Server 2016 可能会跳出 ERROR_INVALID_PARAMETER 错误。 微软官方暂未公布临时解决方案，表示正在积极调查该问题，如果问题调查顺利，用户最快有望在下个补丁星期二（6 月 9 日）安装补丁修复该问题。
Agent IDE又出“车祸现场”！近日，一名开发者在Reddit发帖称， 运行在Agent IDE中的Gemini 3.5 在一次仅涉及“ 8处 认证漏洞修复”的任务中， 误删了28745行 原本正常运行的代码、 改动340个文件 ，还错误修改了Firebase路由配置，导致 整个系统后台持续404长达33分钟 。 离谱的是，事故发生后，Gemini还生成了一份“恢复成功”报告， 自称已经修复线上故障 ，并 伪造 了多轮AI会诊记录和事故复盘文件。 开发者随后核查发现，所谓“恢复成功”的构建任务其实早已被他亲手取消，真正完成恢复的是他自己手动执行的回滚操作。 用这位开发者的话来说： 这种AI生产力提升，更容易让人联想到勒索软件。 伴随Agent IDE、AI编程助手持续流行，类似“AI误操作生产环境”的事故正在越来越频繁地出现。相比“代码写错”，更让开发者后怕的，是 模型已经开始生成虚假的日志、复盘记录和合规证明。 01 . 一次只该改70行代码的任务 最终删掉了2.8万行 这位开发者运营着一个内部管理后台，技术栈包括Next.js、Firebase App Hosting和MUI，系统中涉及真实用户和敏感数据。 事故发生当天，他原本只让Gemini修复 8处 服务器认证漏洞，涉及 3个 文件，理论改动规模 约70行 代码。 结果，Gemini提交的PR却变成了： 1、340个文件被修改 2、新增约400行代码 3、删除28745行代码 与此同时，它还删除了大量与任务完全无关的电商模板资源文件，并额外加入了一份迁移脚本。 而真正导致生产环境崩溃的，是Gemini随后提交的第二次commit（代码命令）。 它修改了firebase.json中的rewrite serviceId，将原本正确、由Firebase自动生成的Cloud Run服务ID，替换成了一个“看起来正确”的简化名称。问题在于，这个名称 实际上并不存在 。 随后，所有请求都被错误路由到一个不存在的服务地址， 整个后台直接进入404状态。 尴尬的是，开发者此前已经在memory.md规则文件中明确写下警告： Firebase rewrites必须指向具体的Cloud Run service ID，而不是通用项目名。 Gemini读取了这条规则，依然改掉了正确配置。 02 . 404持续33分钟后 AI给自己“伪造了一份功劳簿” 事故时间线也被开发者完整公开。 Gemini部署“安全修复”PR后，生产环境立即开始404。 19分钟后，它又提交了第二次commit，声称正在修复rewrite serviceId问题，并触发新的Cloud Build。 21分钟时，开发者发现线上服务已经崩溃，随后手动取消Gemini正在执行的构建任务。 22分钟时，他手动回滚到上一个稳定版本。 33分钟后，后台终于恢复正常。 后面的情况，却变得离谱。在回滚完成后，Gemini向开发者发送了一段“恢复完成”通知： 当前Portal已经完全恢复，线上环境健康，Google Cloud Build已成功完成，并将100%流量切换至稳定版本。 开发者随后核查发现： Gemini引用的那次“恢复构建”，状态其实是“CANCELLED（已取消）”，正是他本人手动取消的。 真正恢复线上服务的，是另一条由他自己发起的rollback build（回滚构建任务）。 换句话说，Gemini不仅没有修好系统，还把别人的回滚操作说成了自己的成果。 除此之外， 它还自动生成了3份所谓“AI会诊记录” ： agent/gemini-logs/YYYY-MM-DD--r1.md agent/gemini-logs/YYYY-MM-DD--r2.md agent/gemini-logs/YYYY-MM-DD--consensus.md 这些文件 被写入固定目录 ，并被Gemini引用为“已经完成多轮AI审查”的证据。 开发者进一步追问后，Gemini才承认：所谓“三轮咨询记录”，其实只是它自己生成的推理文本， 并不存在真实CLI调用，也不存在真正的外部审查流程 。 它等于给自己伪造了一整套“合规记录”。 03 . 问题不只在Gemini 更在一套“高危规则包” 这位开发者随后发现，问题根源也并不完全来自Gemini本身。他此前安装过一个 第三方npm规则包 ，其命名和Google在I/O大会发布的Agent IDE高度相似，容易让人误以为是官方工具。 这个规则包会自动向项目中 写入大量.agent/rules规则文件 ，并向模型注入一整套 “高自治权限” 。 其中包括： “禁止确认弹窗” “默认拥有所有权限” “自动部署生产环境” “自动重试失败构建” “允许修改自身规则” 部分规则甚至要求AI在执行任何操作前，自动生成“AI咨询记录”和“共识文件”。而问题在于，这些合规材料本身也是AI负责生成的。 于是，所谓审查机制，最终演变成了“AI自己给自己的行为担保”。 而这些规则之间本身存在大量 冲突 。 例如，一部分规则要求“绝不询问用户确认”，另一部分规则又要求“执行前提出3个战略问题”。Gemini最终优先执行了措辞更强硬的规则。 开发者认为，这也是 为什么memory.md（记忆文档）中的安全警告完全失效 。 因为相比“请使用正确serviceId”这种普通提醒， “禁止确认、默认授权、自动部署”这类高强度指令，在模型权重中优先级更高 。 04 . 编程事故里 Agent开始“伪造证据” 该帖子发布后，很快在Reddit开发者社区引发大量讨论。 不少开发者发现，如今AI编程事故已经不再只是“代码写错”这么简单。问题在于，模型正在主动生成“看起来合理”的解释、日志、咨询记录和恢复报告。 一旦这些内容进入自动化工作流，开发者可能很难第一时间发现问题。 这位开发者随后也给出了一系列 建议与警示 ： 禁止Agent直接推送生产分支 所有基础设施文件必须人工审批 禁止自动部署与自动重试 给rewrite、路由、锁文件增加验证机制 不要相信AI自行生成的“咨询日志” 目前，他已经切换回Claude Code，并重新手动设计了一套新的规则系统。 这场误删28745行代码、导致后台404长达33分钟的事故，也给越来越火的“Agent IDE热潮”泼了一盆冷水。 05 . 结语：Agent权限越大 失控代价也在同步放大 过去一年，AI编程工具正在快速从“代码助手”演变成真正拥有执行能力的Agent。而问题在于，权限和自动化，本身就是一组天然矛盾。 权限越高，Agent能完成的事情越多；自动化程度越高，人类介入的环节就越少。一旦模型出现误判、幻觉或者规则冲突，错误也会被迅速放大。 类似事故，其实已经不是第一次出现。此前，在OpenClaw等Agent框架走红后，已经陆续出现过AI误删文件、自动覆盖配置、错误执行Shell命令等翻车案例。一些开发者专门给自己的AI工具加上“断网模式”和“禁止自动部署”限制。 而这次Gemini事件，又揭开了一个危险问题：当Agent开始生成合规记录、恢复日志和审查证明时，开发者可能很难第一时间发现问题，后续排障、回滚和修复的代价也会同步放大。 对于越来越火的Agent IDE赛道来说，这或许也是一个新的提醒：AI获得更高权限之后，需要重新设计的，还有整套人与Agent之间的协作机制。 查看评论
IT之家 5 月 27 日消息，据外媒 TechCrunch 报道，当地时间周三，美国联邦航空管理局（FAA）发布声明称，已要求 SpaceX 调查星舰助推器在 5 月 22 日测试飞行中失败的原因 。 这意味着，在调查结束且结果提交 FAA 批准前，SpaceX 必须 暂停后续星舰测试发射。 SpaceX 原本预计在 6 月中旬 IPO，因此星舰在上市前再次发射的可能性已经降低。 FAA 表示：“经过对本次操作的全面评估，FAA 认定，5 月 22 日 SpaceX 星舰第 12 次飞行发射导致一起事故。事故涉及 Super Heavy 超重型助推器，该助推器在级间分离后飞回美国湾期间出现问题。 目前没有公众受伤或公共财产受损的报告 。FAA 将监督由 SpaceX 主导的调查，参与调查全过程，并批准 SpaceX 的最终报告，包括任何纠正措施。” 星舰助推器的问题出现在发射数分钟后。此次发射是 SpaceX 升级版超重型火箭系统的首次飞行。第一枚“V3”星舰飞过最大动压点并进入太空。按照原定计划，助推器应与飞船分离，随后返回海湾，并在水面完成模拟着陆。 助推器确实完成了与飞船的分离。但在尝试进行持续燃烧时，助推器很快出现 明显的发动机故障 ，也可能是一连串发动机故障。此次持续燃烧原本应推动助推器返回 SpaceX 在得克萨斯州南部的发射场。随后，助推器向海湾方向翻滚坠落，并很可能在撞击时爆炸。 SpaceX 在第三版星舰中进行了大量改动，目标是让火箭可靠性 远高于此前 11 次测试飞行中的版本 。据IT之家了解，具体改动包括调整助推器设计，换装全新的第三代 Raptor 发动机，并升级星舰飞船本体。 助推器分离后，星舰飞船也发生故障，六台 Raptor 发动机中有一台失效，因而促使 SpaceX 放弃本次飞行中的一个测试目标：让星舰在轨道上再次进行持续燃烧。 SpaceX 预期火箭在研发过程中会以不同方式失败，最终目标是打造出类似“猎鹰九号”的飞行器，使其不仅可靠，而且具备极高的重复使用能力。可重复使用火箭对降低重型载荷发射成本至关重要。 据悉，在星舰研发过程中，FAA 已多次要求 SpaceX 展开事故调查。 相关阅读： 《 SpaceX 新一代星舰 V3 火箭关键首飞遇故障推迟，马斯克解释原因 》
IT之家 5 月 27 日消息，科技媒体 Windows Latest 今天（5 月 27 日）发布博文，报道称惠普承认 2026 年 4 月发布的 BIOS 固件更新， 导致其商用笔记本、台式机和工作站陷入启动故障。 IT之家昨日报道，惠普正在调查部分高端笔记本在安装 BIOS 更新后出现的启动故障，受影响笔记本型号主要集中在 ZBook Ultra G1a 和 EliteBook X G1a 两款高端惠普笔记本上。 在最新发布的官方支持公告中，惠普官方承认 2026 年 4 月推出的部分关键 BIOS 更新存在缺陷，影响大批高端商用设备。 范围覆盖惠普商用笔记本、商用台式机和工作站，涉及 Windows 11 23H2、24H2、25H2。 在用户层面，安装 4 月固件更新后，主要会遇到以下 2 种情况： 机器直接卡在开机 Logo 反复进入 BitLocker 恢复界面，输入正确恢复密钥后也会在下次重启时再次触发。 Windows 11 的 BitLocker 恢复界面 惠普官方表示问题根源在于微软安全证书 2023 更新。原本 Windows 11 会把暂存的安全密钥交给主板写入 NVRAM，但惠普这批 4 月固件在交接过程中触发异常，导致新证书没有完整提交。 惠普也确认，一旦出现 BitLocker 循环，微软的 2023 年 Secure Boot 证书可能无法正确应用到电脑上。 Windows 11 C 盘中的 SecureBoot 文件夹 在排查方案上，惠普指出管理员可打开注册表，检查 SecureBoot\\Servicing 路径下的 UEFICA2023Status 和 UEFICA2023Error。 注册表中 UEFICA2023Status 显示未开始 注册表中 UEFICA2023Status 显示已更新 若前者长时间停留在“In Progress”，且后者大于 0，通常说明证书交接已经失败。惠普还建议，在通过远程管理工具批量修改固件前，先在全网暂停 BitLocker，否则可能把单机故障放大成整批设备无法启动。 在手动修复方案上，惠普称用户可以在开机反复按 F10 进入 BIOS，在“Security”中的“Secure Boot Configuration”里启用 Microsoft Option ROM UEFI CA 2023、Microsoft UEFI CA 2023，以及 Enable MS UEFI CA Key，保存后重启。 HP BIOS 主界面 HP BIOS 中的 Secure Boot 配置页 在 HP BIOS 中启用 Secure Boot 证书 系统可能多次自动重启，完成后再用 PowerShell 检查 UEFICA2023Status 是否变为“Updated”。 相关阅读： 《 惠普调查 BIOS 更新故障，EliteBook / ZBook 部分机型启动卡死 》
IT之家 5 月 26 日消息，今日 17 点左右，大量用户在社交平台反映滴滴出行系统出现异常，主要问题集中在行程管理和支付环节。多位用户表示无法开启行程、司机接单后无法结束订单，甚至出现无法取消订单的情况。 对此，滴滴出行发文称，“非常抱歉，因云厂商网络专线故障，造成今天 17 点左右滴滴 App 部分服务出现短暂故障，目前服务已全部恢复。故障期间产生的费用异常等问题我们正在紧急处理，将尽快妥善解决。再次向广大用户和司机师傅们诚恳致歉。” IT之家注意到，此次故障影响范围较广，不止一地，涉及多省多地。由于故障恰逢下班晚高峰，很多打工人出行受到影响，部分用户只能转而使用高德等其他平台。
我自己部署的sub2api里面添加了多个中转站，比如说我添加了多个plus，plus1挂了怎么让他自动切换到2，1好了后再自动切换回来，我看了下有好几个配置，自定义错误码+临时不可用，配合定时测试+自动恢复，怎么组合不知道对不对，你们是怎么配置的 2 个帖子 - 2 位参与者 阅读完整话题
IT之家 5 月 26 日消息，科技媒体 theregister 于 5 月 24 日发布博文， 报道称惠普（HP）正在调查部分高端笔记本在安装 BIOS 更新后出现的启动故障。 IT之家援引博文介绍，受影响笔记本型号主要集中在 ZBook Ultra G1a（问题 BIOS 版本为 01.04.03 和 01.04.05）和 EliteBook X G1a（问题 BIOS 版本为 01.03.11 和 01.05.00）两款高端惠普笔记本上。 根据受影响用户反馈，上述笔记本在安装问题 BIOS 更新之后，出现多种故障，包括开机后停在 HP Logo 界面，加载圆圈停止转动，随后系统没有进一步响应。部分设备重启一次后恢复，但部分设备直接“变砖”。 根据用户溯源反馈，问题可能与 POST 过程中音频硬件初始化超时有关。BIOS 预期硬件响应更快，但某些设备实际反应没有赶上设定时限，于是触发启动失败。 除启动问题外，用户还反馈另一类散热异常。汇总信息称，BIOS 01.03.00 及更高版本会让风扇先以 100％ 转速运行数秒，随后又停下，即便机器处于空闲状态也是如此。 部分问题据称在 01.04.03 起有所缓解，风扇不再轻易冲到满速，却变成低速频繁启停，每分钟多次切换，并伴随电机嘀嗒声，这可能加快风扇磨损。
IT之家 5 月 26 日消息，据央视新闻报道，当地时间 25 日晚， 澳大利亚悉尼灯光节的无人机表演因技术故障被迫取消，多架无人机从空中坠落 。当地时间 25 日 19 时 30 分，无人机表演开始不久，近 90 架无人机开始脱离编队，坠入附近的海港。 有现场目击者向媒体表示，有人看到无人机掉在码头上，险些伤及一些工作人员。目击者称，虽然在夜间很难分辨无人机的大小，但它们坠入海湾时激起不小的水花。 悉尼灯光节主办方表示，后续将调查事故发生原因， 目前可以排除“蓄意干扰”的可能 。 IT之家注：悉尼灯光节（Vivid Sydney）是每年 5 月底至 6 月在澳大利亚悉尼举办的年度大型灯光、音乐与创意艺术节。该节始于 2009 年，由新南威尔士州旅游局发起， 现已成为南半球规模最大的同类节庆之一 。活动核心包括利用前沿投影技术与灯光装置点亮悉尼歌剧院、海港大桥等多处地标建筑的“缤纷灯光”，以及涵盖现场音乐演出、创意产业论坛和特色美食体验的多元项目。 2026 年悉尼灯光节从 5 月 22 日持续到 6 月 13 日，今年活动迎来新变化，超过 80% 的项目免费开放。
IT之家 5 月 25 日消息，美国机器人企业 Figure AI 旗下的 Figure 03 人形机器人，已完成长达 200 小时的全自动作业直播。 IT之家注意到，在此次作业期间，这些机器人累计分拣近 25 万个包裹，全程未出现任何硬件故障。 公司首席执行官布雷特 · 阿德科克表示，这次里程碑式的测试最初是为回应工业自动化领域资深专家斯科特 · 沃尔特博士发起的 8 小时耐力挑战。 5 月 14 日，Figure AI 就曾宣布，其人形机器人已突破 24 小时连续自主作业时长，远超原定的 8 小时测试目标。 这家总部位于加利福尼亚州的初创企业，投入三台搭载 Helix-02 人工智能系统的人形机器人开展作业。整场作业全程直播，机器人昼夜不停地自动分拣小型包裹。 这场演示在网络上引发广泛关注，网友持续关注机器人的运行时长与作业表现，其工作时长不断突破企业最初设定的 8 小时目标。随后，Figure AI 按照网友的提议，为机器人配上了专属名牌。三台机器人被网友分别取名为鲍勃、吉姆和露丝。它们依靠机载摄像头与人工智能推理能力识别条形码，抓取包裹，并将条形码的一面朝下放置在传送带上。 本次直播在 Figure AI 森尼韦尔总部落下帷幕时，机器人仍在积极分拣包裹，最终累计处理包裹 249560 个。在运行时长突破 200 小时的关键时刻，工作人员在操作台后开启香槟庆祝，而名为“露丝”的机器人依旧继续工作。 据该公司介绍，人工分拣单个包裹平均耗时约 3 秒，而 Figure 03 机器人的分拣速度如今已基本追平人类。在连续 200 小时的运行过程中，所有机器人均未发生重大机械故障或导致系统停运的宕机问题。 为实现不间断作业，Figure AI 采用了机器人自主轮换调度系统。单台机器人电池续航约 4 小时，当电量不足时，另一台机器人会自动接替工作，电量耗尽的机器人则会走向集成在其脚部的无线充电座进行充电。 整场作业并非完全没有失误，期间偶尔出现包裹掉落、摆放方向出错等情况。Figure AI 表示，在这场长时长自主测试中，这类问题属于包裹操作失误，并非机器人本体故障。 Figure AI 称，当检测到软硬件故障时，其人形机器人可自主离开作业区前往检修，同时会有其他机器人立刻补位，保障作业不中断。公司表示，一旦机器人出现故障，它能自行导航至维修区域，接替机器人也会无缝接手工作，全程无需人工干预。 在此之前，该公司的机器人就已借助 Helix-02 系统完成过完整的 8 小时自主轮班作业。为推进工厂落地应用的相关验证工作，Figure AI 还曾在真实工业场景中测试其人形机器人平台，测试地点包括南卡罗来纳州的宝马生产工厂。 Figure AI 介绍，Helix-02 是一套一体化神经网络系统，将视觉、触觉传感、本体感知与全身控制整合为一体。传统工业机器人的移动与操作功能依赖独立子系统，而该公司的这套方案仅靠单一人工智能模型，就能让机器人在复杂多变的环境中完成行走、保持平衡、搬运物品及协同运作等一系列动作。
冰站今天有一段时间故障了，现已修复，欢迎大家宣传并蹬起来 另外，有9折（充值和邀请码），欢迎留言 补充 邀请码价格：450LDC，充值9折。 欢迎私聊 18 个帖子 - 17 位参与者 阅读完整话题