IT之家 6 月 6 日消息，小鹏 X9、小鹏 GX 产品负责人罗杰今日宣布， 2026 款小鹏 X9 AIOS 6.2.0 的推送已经启动 ，本轮升级 Ultra 和 Ultra SE 车主将收到 VLA 2.0 的第二个版本，智驾体验再次升级，座舱方面 26 款全系 X9 也将新增一系列实用功能。 罗杰表示，26 款 X9 Max 版车主最关心的 VLA 2.0 蒸馏版，通用智能中心的同学也在积极开发中，辛苦大家耐心等待。 IT之家附本次更新内容如下： 【优化】园区地库无导航 NGP 漫游（Ultra / Ultra SE） 无导航状态下，新增园区和地库的 NGP 漫游（城区漫游 6.1.0 已支持）。 在园区、地库漫游状态下，会优先保持在现有车道行驶、分岔口优先直行，同时可以绕行低速及静止的行人、车辆和障碍物，支持人机共驾。 【优化】全场景原地起步 (支持园区地库 P 挡状态下开启 NGP，Ultra / Ultra SE) 车辆上电后，当满足 NGP / 漫游激活条件时，园区地库可以支持任意位置 P 挡直接开启 NGP（城区起步 6.1.0 已支持）。 【新增】终点车位选项（Ultra / Ultra SE） 新增「终点车位选项」。前往车位到车位学习过的终点园区，可以通过「终点车位选项」选择抵达目的地后前往并泊入收藏车位，或选择抵达目的地后切换至 NGP 漫游。 【新增】车位被占漫游找车位（Ultra / Ultra SE） 使用车位到车位功能前往终点收藏车位时，若收藏车位被占，支持就近漫游找车位泊入。 【新增】效率泊车风格（本轮 Max，Ultra / Ultra SE 6.1.0 已具备） 泊车风格新增「效率」选项，可在「效率」与「标准」之间选择。 「效率」模式：提升泊车速度，减少泊车耗时，让泊车更快更高效； 「标准」模式：保持原有更偏稳健的泊车策略。 设置路径：「辅助驾驶」-「泊车场景」界面设置中，将泊车速度风格从默认的「标准」切换为「效率」。 【新增】辅助驾驶车道级渲染（26 款全系） 辅助驾驶车道级渲染上线，导航路径与车道级感知充分融合；结合车道级地图与超视距信息，提前展示前方道路状况，NGP 驾驶意图一目了然，人机共驾更安心。 打开路径：默认打开，可在「设置」-「地图」-「辅助驾驶车道级渲染」开关。 【新增】熟路智能推荐（26 款全系） 在发起导航路线页选择 " 智能推荐 " 模式后，系统将根据驾驶习惯，优先推荐熟路路线，无需反复设置途径点，让路线更符合驾驶偏好。 【新增】手机 App 车内遥控器（26 款全系） 手机化身车内遥控器，后排屏影音娱乐尽在掌握，投屏触控更方便；音乐、座椅、空调、遮阳帘、阅读灯等功能亦可精细调节，座座都有掌控权。 打开路径：小鹏汽车 App 车控页面「更多功能」-「后排遥控器」，需通过蓝牙与车机连接。目前支持 iOS 及安卓系统，小鹏汽车 App 需升级至 5.18.1 及以上版本。 【新增】后视镜展开时机设置（26 款全系） 可选择在开车门后再自动展开后视镜，提高狭窄车位上车便利性，避免解锁时后视镜发生磕碰剐蹭。 打开路径：「控制中心面板」-「后视镜调节」-「自动展开外后视镜时机」 【新增】车窗拨杆控制方式（26 款全系） 可以根据您的习惯，调整车窗拨杆开关控制玻璃升降的方向，支持设置为「前开后关」或「前关后开」。 打开路径：「设置」-「门窗」-「车窗拨杆控制方式」 【新增】间歇雨刮灵敏度调节（26 款全系） 可设置间歇雨刮模式下的灵敏度，满足不同雨量下的雨刮需求。 打开路径：「设置」-「门窗」-「雨刮」-「AUTO 雨刮模式」-「间歇雨刮」 【新增】「停止模式」功能开启的状态指示灯（26 款全系） 「停止模式」功能开启的状态指示灯，在打开「停止模式」时将点亮显示。 【新增】自动连接媒体音频开关（26 款全系） 可设置连接蓝牙后自动将手机媒体及提示音转至车机播放，避免遗漏手机通知。 打开路径：默认关闭，可在「设备连接」-「蓝牙」-「蓝牙设备设置」打开。 【新增】车辆信息 & 辅助驾驶战绩（26 款全系） 「我的车辆」应用首页增加 vin、车牌号显示；辅助驾驶使统计页面新增 " 最佳辅助驾驶战绩 " 数据与辅助驾驶高光时刻统计。
IT之家 6 月 5 日消息，PC 机电散品牌 Thermatake（曜越）在 COMPUTEX 上带来了多款富有创意的产品设计，包括采用插拔对接模块设计的 PC 电源、双 micro-ATX 系统机箱、集成屏风式三屏的 AIO 液冷。 电源 Dockpower 电源采用专利“插拔对接模块设计”， 电源本体和模组接口面板间以金手指连接 。这不仅意味着后续可单独升级本体或面板，也让用户可以先在机箱外完成布线再将面板接至本体。 机箱 曜越 双 micro-ATX 系统 机箱 CAPO X 在台北国际电脑展上首度亮相。其延续了 CES 上展出的 View Cross TG 的基本布局并进一步优化配置，升级曲面玻璃侧板，允许在单一机箱中安装主系统 + AI 智能体专属系统。 散热 散热方面，曜越此次展出的最重磅新品是 ST360 Trio Ultra ARGB Sync 。这一型号在冷头上配备了 屏风式三连 6" 720×1480 LCD 面板 ，用户可根据自身需求调整该三屏系统的朝向与开合角度。 同系列的另一款产品则是集成 6" 2160×1080 屏幕的 ST360 Pro Ultra ARGB Sync 。与上面的 Trio Ultra 一样，其搭载三合一吹排风扇。 曜越还带来了 VF360 AIO ARGB Sync 和 WB360-S ARGB Sync 两款液冷，前者冷头顶部集成 ARGB 光效 VRM 散热风扇，后者则是在冷头和风扇两端均采用木艺主题装饰。 此外，Retro 系列 AIO 液冷则在冷头设计上致敬了经典的“大背头”电脑显示器。 至于风冷，此次的 UX600 ARGB Sync 系列统一采用 260W 解热的双塔双风扇 6 热管结构，提供标准、数显顶盖、3.95" LCD 屏幕顶盖版本。
IT之家 6 月 4 日消息，春秋电子本月 2 日正式宣布，其成功通过子公司完成对高性能桌面处理器一体式 (AIO) 水冷制造商 Asetek 全部股份的全面要约收购，完成结算及交割手续。 而在 PC 产业盛会 COMPUTEX 2026 台北国际电脑展上，Asetek 也带来了其最新 AIO 水冷解决方案 Emma V3 [Gen10]，宣称其较 Emma V2 [Gen8 V2] 典型 TDP 下热阻进一步降低 1.5℃ ， 全速和标准间隔下体感音量降低 45% 。 Asetek 表示，Emma V3 进一步针对最新处理器的热力学特性优化 ，加大了铜底中心偏移程度，铜底的凸度也与处理器的“顶盖”(IHS) 恰当匹配。同时其采用高密度翅片结构，瞬态传热能力得到增强。 此外其采用奇数 7 叶的叶轮设计，化解拍频效应；略微增加叶轮外径与定子壳体舌片之间的间隙；注塑浇口重新布置至叶轮后方；一体化制造定子外壳以切断振动传播路径。 Emma V3 还引入了新的可旋转支架设计，完全解耦了水管触控与内部微流道方向之间的传统固定关系，单一泵架构即可在两大主要平台上提供最佳散热性能。此外其标准冷排厚度达 30mm，还 可选配冷液与空气方向垂直的“叉流”冷排 ，可进一步带来 0.3~0.5℃ 的改进。
IT之家 6 月 3 日消息，据 Wccftech 等多个媒体报道，猫头鹰（Noctua）在 Computex 2026 上正式推出了其首款一体式水冷散热器，同时展示了下一代风冷散热器、工作站散热器，以及多款联名产品。 猫头鹰 NL-LC1 系列 AIO 水冷将于 6 月 16 日在欧洲上市，提供 240mm、360mm 和 420mm 三种规格，定价分别为 219.90 欧元（IT之家注：现汇率约合 1733 元人民币）、249.90 欧元（现汇率约合 1969 元人民币）和 279.90 欧元（现汇率约合 2206 元人民币）。 该系列水冷采用 Asetek Emma V2 平台，配备猫头鹰自家的 NL-PNA1 降噪器（用于减少水泵的振动噪音），搭载 NF-A14x25 G2 或 NF-A12x25 G2 风扇，提供安静、均衡和手动三种泵速模式。 其散热器厚度为 30mm，支持 SecuFirm2+ 扣具，兼容 AM4、AM5、LGA1700、LGA1851。猫头鹰将为该系列产品提供 6 年质保。 此外，用户还可选配 NL-ACF1 80mm 辅助风扇，用于为 CPU 插座周边元件（VRM、内存、M.2 等）提供额外气流。该风扇采用磁吸固定，售价 19.90 欧元（现汇率约合 156.8 元人民币）。 在风冷产品方面，猫头鹰展示了下一代 NH-L12 低矮型散热器。新版本采用 6 根热管，总高度从上一代的 75mm 降至 70mm，同时保持 35mm 的内存净空，适配 AM5 平台的 Mini-ITX 主板，预计 2027 年第二季度上市。 猫头鹰还展示了其针对未来 AMD Threadripper 处理器（可能基于 Zen 6 架构）的下一代工作站散热器设计，采用双塔 7 热管结构与大型底座，搭载 NF-A14x25r G2 和 NF-A12x25 G2 风扇，兼容 Intel LGA4710/4677 及 AMD sTR5、TR4、SP3、SP6 等插座，同样预计 2027 年 Q2 上市。 猫头鹰还宣布与 Carbice 合作推出 NT-CP1 AM5/4 碳纳米管导热垫。该导热垫采用垂直排列的碳纳米管森林，辅以铝背板，表面有纳米级聚合物涂层，安装前不导电且防止滑动。 官方称其不存在泵出、干裂、分层或开裂等老化现象，经过超过 10 万次热循环测试，无需维护或更换，达到航天级可靠性。该导热垫专为 AMD AM5 和 AM4 处理器设计，预计 2026 年 9 月上市。 电源方面，猫头鹰正与海韵开发第二代 PRIME TX 联名电源，搭载 OptiGuard 智能 GPU 供电保护系统，提供引脚级电流监测。 新电源长度从 210mm 缩短至 180mm，可兼容更多机箱，提供 1300W 和 1600W 版本，内置 NF-A12x25 G2 风扇，支持半被动运行，符合 ATX 3.1 与 PCIe 5.1 规范，钛金能效，预计 2027 年 Q1 上市。 猫头鹰还与暴力熊（Thermal Grizzly）合作推出 Wire View Pro II Noctua 版，用于监测 12V-2x6 接口的每针功耗，防止电流不均损坏显卡。 该模块配备定制 CNC 铣削铝制散热片、无框 NF-A4x10 风扇，支持半被动运行、超限声光报警和 USB-C 固件更新，暴力熊将提供 2 年延保，预计 2027 年 Q3 上市。 此外，此前亮相的 Pulsar Feinmann F01 Noctua 版游戏鼠标在前后增加了额外通风孔，内置 NF-A4x10 5V PWM 风扇，重量 73g，搭载 XS-2 42000 DPI 传感器，支持 8kHz 轮询率，风扇转速可通过按键或网页驱动实现 5 级调节，预计 2026 年 6 月或 7 月上市。 最后，猫头鹰更新了热虹吸（两相）散热器的开发进度，目标 2027 年 Q3 发布。该产品与 Calyos 合作开发，采用柔性管，无运动部件，因此没有泵机噪音和振动。 这款散热器为 360mm 规格，依赖重力工作，适合顶部排气安装。过去 12 个月中，猫头鹰已制造并测试了超过 400 个蒸发器原型和 25 个冷凝器原型，目前蒸发器设计已优化至每天可验证 4 种方案。
IT之家 6 月 3 日消息，日本 PC 散热厂商 Scythe（镰刀）在 COMPUTEX 2026 上带来了两款风冷新品：虎彻 (KOTETSU) 5 和风魔 (FUMA) 4，此外再次展出了 AIO 水冷 SCYCOPTER。 三者均支持英特尔尚未推出的 FCLGA1954 插槽 。 虎彻 5 与风魔 4 有不少共性 ：两者高度均为 154mm，都配备 350~2000 RPM 设置的 WONDER TORNADO 120 PWM 风扇，其中虎彻 5 为单塔单风扇结构、风魔 4 则是双塔双风扇。 SCYCOPTER 水冷的特色是其冷头顶部包含一颗硕大的风扇。这颗“第四风扇”尺寸为 110mm，转速区间 350~1800 RPM。其采用 27mm 冷排，配备 400mm 水冷管，风扇也是 350~2000 RPM 的 WONDER TORNADO 120 PWM。
最近一段时间我开始实践 AIOps ，即尝试使用 agent 来管理我的个人服务器，帮助我解决个人项目的线上问题。 我目前拥有一台部署在 Digital Ocean 上的 Droplet （也就是传统的 VM ），上面部署有网关服务 Kong 、定时任务平台 Kestra 、6 个 Agent/Workflow ，涉及 4 个 repo 。同时 Kestra 上运行有一个小时级别的定时任务，三个日级别定时任务，五个周级别的定时任务。并且可见日后新增的 agent 或者服务还会继续增加。用业余时间维护这些服务显然已经超过了我能够承受的负荷，因此借助 AI 来辅助我进行维护工作。 人是最大的瓶颈 AIOps 不是一个选项，而是一个结果 。因为 AI 带来的生产力提升正在让人成为交付过程中的最大瓶颈——我开始尝试 AIOps 的初衷也是基于此：AI 可以不费吹灰之力将我的想法变为现实，但这只是降低了我的制造成本而非是维护成本，上线之后遇到了太多的线上问题需要解决。如果我依然选择人工去修复每个问题，那从整个交付结果上看效率并没有任何的提升。这里我还需要替 AI 辩解一句，从事后看诸多的线上问题并非是源自生成代码不够健壮，而是来源于意料之外的不确定因素，例如网络抖动、例如第三方后端服务契约的改变。 于是让 AI 应对 AI 就是水到渠成的事，我的第一个 AIOps 版本是：一旦有线上问题发生，某个 debug agent 便会被自动唤起，它不仅能够获取到日志，还可以通过 GitHub MCP Server 获取到源码，从中便可以推断出服务镜像是如何构建以及服务是如何被部署的，它还可以调用 docker CLI 来获取底层的 docker container 运行状态。最后综合以上信息生成一份涵盖 pull request 的解决方案。 听上去很美好是不是，但人作为瓶颈的这个问题并没有被解决。因为 AI 所生成的长篇解决方案、pull request 依然等待着开发者的 review 和批准 。某种意义上说，它只是让问题推迟发生了。 当然我们还可以选择将 AI 应对 AI 的策略贯彻到底：用另一个 AI 来评审当前 AI 提出的 pull request——我尝试这么做过，鉴于 debug agent 是基于 Cursor SDK 开发，于是我选择在 GitHub 上集成了 Gemini Code Assistant 来对 Cursor SDK 生成的代码进行评审——但这并没有让情况变得更好，我发现 Gemini 总是能对 Cursor 生成的修改提出“不满”，严重程度均为中度往上的。如果你真的对每一则意见都进行评估，那最后 AIOps 带来的结果是事与愿违：效率不但没有得到提升，还最终你精疲力竭。 到现在你也许已经发现了问题的症结所在：只要人还存在于交付的任意一个环节中，无论是 QA 还是代码评审，端到端的交付效率就无法彻底得到提升 。 解决问题的方式很简单：把人移除，让 AI 自身持续改进。我正在尝试这么去做，不过事实上已经有人在付诸实践了，在最近 OpenAI 官方发布了一篇文关于 Harness Engineering 的文章 《工程技术：在智能体优先的世界中利用 Codex 》 （ Harness engineering: leveraging Codex in an agent-first world ）中，他们的做法是： 我们会指示 Codex 在本地审核其自身的更改，在本地和云端请求额外的特定智能体审查，对任何人工或智能体给出的反馈做出响应，并循环往复，直到所有智能体审核人员都满意为止……随着时间的推移，我们已将几乎所有的审核工作调整为用智能体对智能体的方式来处理。 如果你有兴趣的话可以深入其背后的深层思想： Ralph Loop 。即构建一套自治循环（ autonomous loops ）的系统，人只负责定义目标和约束，让 AI 持续执行任务、测试、修复、提交、部署。 共享工具，独享上下文 在相当长一段时间内有一件事我想不清楚：究竟需要多少个 agent 来解决所有可能发生的线上问题？ 我可以选择按照纵向服务模块来设计，分别给 Kestra 、Kong 、Agents 都准备一个独立的 debug agent 为其服务；还可以选择从横向出发，分别为 host 主机、docker 服务、应用层服务配置 debug agent——所有上面这些想法并不切实际，因为从实际解决问题的角度出发， 无论是人还是 AI ，他或它需要的都不仅仅是某个切面的数据，都是每个切面的数据 。 我的经验是，信息的收集对于解决问题至关重要。越靠近生产环境，越多的问题可能是由非代码引起的。一旦我们无法找到有效的出错栈信息，那么就需要从基础设施，从跨功能需求上寻找答案，那么如何排除每一种可能呢？信息，贪婪的获取信息至关重要。 本质上 debug 过程遵循的是情报周期（ Intelligence cycle ） ：决策者首先确定需求，然后根据需求收集有关的情报，并随之进行整理和过滤，最后对其进行分析并从中找出威胁或者有效信息。决策者还需要根据反馈结果继续决定是否进行下一轮迭代。 例如我发现 Kestra 某几个定时任务的失败是源于 VM 的内存和 CPU 已经满负荷运行，而之所以满负荷运行，部分又是因为多个定时任务的几乎在同一时间运行——在这个例子中，agent 需要在 Kestra 日志，Docker 日志，以及多个源码之间反复横跳才能找到症结所在。 所以即使我需要多个 agent 解决多个纵向领域内的问题（在同一套基础设施环境内），它们的能力也不会有太大差异，完全可以共享一整套的工具（函数）或者 MCP Server 。但解决不同类型问题 agent 需要的上下文却不尽相同。例如对于一个专业解决 Kestra 定时任务有关问题的 agent ，它不仅需要理解 Kestra 自身是如何构建以及部署的，还需要了解每个定时任务背后，那个由 HTTP 触发的后端服务的是如何构建以及部署的；而对于解决 docker 有关问题的 agent 而言，它只需要你给它足够高的 Docker CLI 使用权限就够了。 所以回到本小节开头的那个问题？我们究竟需要多少个 agent ？我的答案是一个就够了，我们可以创建一个拥有各种工具箱的 agent ，然后将上下文信息在调用 agent 时以 prompt 的方式传递给它即可。 你可能会想到其他的一些可能的解决方案，例如 sub agent ，又或者 agent team ，绝大部分框架都已经提供了开箱即用的类似机制。我之所以没有选择一方面是因为简单的架构与代码对我来说颇为重要，二是因为按照我的开发经验看，我对 agent 之间的交互没有信心：agent 的工作过程越是动态，不确定性越高，失败的概率也就越高。 Agent 的部署与落地 最后我们聊聊实现层面的问题。 首先，Agent 必须“寄生”（部署）在应用程序所在的运行环境中，一方面是为了实现我上面所说的，尽可能多的获取应用自身及其所处环境的数据信息（如果程序是运行在如 Vercel 或者 Render 这样的 PaaS 平台上，至少需要保证 agent 能够通过 API 获取到日志信息）；另一方面是为了便于 agent 被及时唤起介入线上问题。整体上看部署在云上的 agent 会比部署在本机的 agent 更有优势。 虽然 agent 部署在远端，但开发者依然需要具备访问它的能力，包括了解它是如何思考的，看到它的解决方案是什么，在必要时与其对话对解决方案进行修改。你可以把这个当作另一种关于 agent 的 observability ，只不过这里指的是将它的工作过程和工作结果可视化，而不是将它 agent 的代码调用过程可视化。 目前并不存在满足上述需求的开箱即用的工具，虽然 Codex 和 Claude Code 在 debug 上是高手，但它们仅仅适用于于本地调试。所以我们需要基于已有的 agent 框架进行二次开发。而根据我以上的描述，agent 框架的需要满足最重要的三点需求： 支持配置 tool 与 MCP Server ，以便与不同的平台和环境集成 框架自身提供 HTTP 接口能够供外界服务服务调用 agent ，这便于 agent 与第三方服务集成 框架提供前端界面供用户与 agent 持续进行对话 虽然并非市面上每一款 agent 框架都具有上述特性，但是能够找到符合以上三点的框架还是不少，比如 Mastra 或者 Ango 。第三点尤其重要，因为如果需要自主实现一个能与 agent 进行交互的单页面应用需要付出不少额外的精力，下图为 agno 的前端应用界面，它可能帮助你可视化的管理 agent 的方方面面。 但最终我既没有选择 Mastra 也没有选择 Agno ，而是选择基于 Cursor SDK 自建，原因来自于模型。 如果选择第三方框架，意味着我需要自行为其提供模型。而出于众所周知的原因，我无法使用官方提供的 sonnet 、opus 或者 GPT-5.4 模型，open router 在我所属的 IP 下也无法提供服务，我还尝试过 Vercel 的 AI Gateway 似乎也无法正常工作。与其继续纠结斗智斗勇不如直接选择可用的服务，例如 Cursor SDK （我可以指定其使用 Composer 2.5 模型）。并且使用独立 AI 模型的另一个弊端是额外的为 API 调用付费，而我相信我的 Cursor 会员能够覆盖这部分的用量。 HTTP 接口怎么办？使用任意 web server 框架对一次 agent 调用进行封装即可。至于前端——我当然可以 vibe coding 一个前端页面，甚至我早就有一个 开源项目 能够完成这方面工作——考虑我太懒了，以及本质上我们需要的是一个能够可视化 agent 输出以及与其沟通的“场所”而已，有一个更简单的地方可以派上用场：GitHub Issue 。我会确保所有的 agent 的输出都会以一个全新 issue 的方式创建出来，然后利用 comment 这种形式与 agent 进行沟通。 原文发布于此
最近一段时间我开始实践 AIOps ，即尝试使用 agent 来管理我的个人服务器，帮助我解决个人项目的线上问题。 我目前拥有一台部署在 Digital Ocean 上的 Droplet （也就是传统的 VM ），上面部署有网关服务 Kong 、定时任务平台 Kestra 、6 个 Agent/Workflow ，涉及 4 个 repo 。同时 Kestra 上运行有一个小时级别的定时任务，三个日级别定时任务，五个周级别的定时任务。并且可见日后新增的 agent 或者服务还会继续增加。用业余时间维护这些服务显然已经超过了我能够承受的负荷，因此借助 AI 来辅助我进行维护工作。 人是最大的瓶颈 AIOps 不是一个选项，而是一个结果 。因为 AI 带来的生产力提升正在让人成为交付过程中的最大瓶颈——我开始尝试 AIOps 的初衷也是基于此：AI 可以不费吹灰之力将我的想法变为现实，但这只是降低了我的制造成本而非是维护成本，上线之后遇到了太多的线上问题需要解决。如果我依然选择人工去修复每个问题，那从整个交付结果上看效率并没有任何的提升。这里我还需要替 AI 辩解一句，从事后看诸多的线上问题并非是源自生成代码不够健壮，而是来源于意料之外的不确定因素，例如网络抖动、例如第三方后端服务契约的改变。 于是让 AI 应对 AI 就是水到渠成的事，我的第一个 AIOps 版本是：一旦有线上问题发生，某个 debug agent 便会被自动唤起，它不仅能够获取到日志，还可以通过 GitHub MCP Server 获取到源码，从中便可以推断出服务镜像是如何构建以及服务是如何被部署的，它还可以调用 docker CLI 来获取底层的 docker container 运行状态。最后综合以上信息生成一份涵盖 pull request 的解决方案。 听上去很美好是不是，但人作为瓶颈的这个问题并没有被解决。因为 AI 所生成的长篇解决方案、pull request 依然等待着开发者的 review 和批准 。某种意义上说，它只是让问题推迟发生了。 当然我们还可以选择将 AI 应对 AI 的策略贯彻到底：用另一个 AI 来评审当前 AI 提出的 pull request——我尝试这么做过，鉴于 debug agent 是基于 Cursor SDK 开发，于是我选择在 GitHub 上集成了 Gemini Code Assistant 来对 Cursor SDK 生成的代码进行评审——但这并没有让情况变得更好，我发现 Gemini 总是能对 Cursor 生成的修改提出“不满”，严重程度均为中度往上的。如果你真的对每一则意见都进行评估，那最后 AIOps 带来的结果是事与愿违：效率不但没有得到提升，还最终你精疲力竭。 到现在你也许已经发现了问题的症结所在：只要人还存在于交付的任意一个环节中，无论是 QA 还是代码评审，端到端的交付效率就无法彻底得到提升 。 解决问题的方式很简单：把人移除，让 AI 自身持续改进。我正在尝试这么去做，不过事实上已经有人在付诸实践了，在最近 OpenAI 官方发布了一篇文关于 Harness Engineering 的文章 《工程技术：在智能体优先的世界中利用 Codex 》 （ Harness engineering: leveraging Codex in an agent-first world ）中，他们的做法是： 我们会指示 Codex 在本地审核其自身的更改，在本地和云端请求额外的特定智能体审查，对任何人工或智能体给出的反馈做出响应，并循环往复，直到所有智能体审核人员都满意为止……随着时间的推移，我们已将几乎所有的审核工作调整为用智能体对智能体的方式来处理。 如果你有兴趣的话可以深入其背后的深层思想： Ralph Loop 。即构建一套自治循环（ autonomous loops ）的系统，人只负责定义目标和约束，让 AI 持续执行任务、测试、修复、提交、部署。 共享工具，独享上下文 在相当长一段时间内有一件事我想不清楚：究竟需要多少个 agent 来解决所有可能发生的线上问题？ 我可以选择按照纵向服务模块来设计，分别给 Kestra 、Kong 、Agents 都准备一个独立的 debug agent 为其服务；还可以选择从横向出发，分别为 host 主机、docker 服务、应用层服务配置 debug agent——所有上面这些想法并不切实际，因为从实际解决问题的角度出发， 无论是人还是 AI ，他或它需要的都不仅仅是某个切面的数据，都是每个切面的数据 。 我的经验是，信息的收集对于解决问题至关重要。越靠近生产环境，越多的问题可能是由非代码引起的。一旦我们无法找到有效的出错栈信息，那么就需要从基础设施，从跨功能需求上寻找答案，那么如何排除每一种可能呢？信息，贪婪的获取信息至关重要。 本质上 debug 过程遵循的是情报周期（ Intelligence cycle ） ：决策者首先确定需求，然后根据需求收集有关的情报，并随之进行整理和过滤，最后对其进行分析并从中找出威胁或者有效信息。决策者还需要根据反馈结果继续决定是否进行下一轮迭代。 例如我发现 Kestra 某几个定时任务的失败是源于 VM 的内存和 CPU 已经满负荷运行，而之所以满负荷运行，部分又是因为多个定时任务的几乎在同一时间运行——在这个例子中，agent 需要在 Kestra 日志，Docker 日志，以及多个源码之间反复横跳才能找到症结所在。 所以即使我需要多个 agent 解决多个纵向领域内的问题（在同一套基础设施环境内），它们的能力也不会有太大差异，完全可以共享一整套的工具（函数）或者 MCP Server 。但解决不同类型问题 agent 需要的上下文却不尽相同。例如对于一个专业解决 Kestra 定时任务有关问题的 agent ，它不仅需要理解 Kestra 自身是如何构建以及部署的，还需要了解每个定时任务背后，那个由 HTTP 触发的后端服务的是如何构建以及部署的；而对于解决 docker 有关问题的 agent 而言，它只需要你给它足够高的 Docker CLI 使用权限就够了。 所以回到本小节开头的那个问题？我们究竟需要多少个 agent ？我的答案是一个就够了，我们可以创建一个拥有各种工具箱的 agent ，然后将上下文信息在调用 agent 时以 prompt 的方式传递给它即可。 你可能会想到其他的一些可能的解决方案，例如 sub agent ，又或者 agent team ，绝大部分框架都已经提供了开箱即用的类似机制。我之所以没有选择一方面是因为简单的架构与代码对我来说颇为重要，二是因为按照我的开发经验看，我对 agent 之间的交互没有信心：agent 的工作过程越是动态，不确定性越高，失败的概率也就越高。 Agent 的部署与落地 最后我们聊聊实现层面的问题。 首先，Agent 必须“寄生”（部署）在应用程序所在的运行环境中，一方面是为了实现我上面所说的，尽可能多的获取应用自身及其所处环境的数据信息（如果程序是运行在如 Vercel 或者 Render 这样的 PaaS 平台上，至少需要保证 agent 能够通过 API 获取到日志信息）；另一方面是为了便于 agent 被及时唤起介入线上问题。整体上看部署在云上的 agent 会比部署在本机的 agent 更有优势。 虽然 agent 部署在远端，但开发者依然需要具备访问它的能力，包括了解它是如何思考的，看到它的解决方案是什么，在必要时与其对话对解决方案进行修改。你可以把这个当作另一种关于 agent 的 observability ，只不过这里指的是将它的工作过程和工作结果可视化，而不是将它 agent 的代码调用过程可视化。 目前并不存在满足上述需求的开箱即用的工具，虽然 Codex 和 Claude Code 在 debug 上是高手，但它们仅仅适用于于本地调试。所以我们需要基于已有的 agent 框架进行二次开发。而根据我以上的描述，agent 框架的需要满足最重要的三点需求： 支持配置 tool 与 MCP Server ，以便与不同的平台和环境集成 框架自身提供 HTTP 接口能够供外界服务服务调用 agent ，这便于 agent 与第三方服务集成 框架提供前端界面供用户与 agent 持续进行对话 虽然并非市面上每一款 agent 框架都具有上述特性，但是能够找到符合以上三点的框架还是不少，比如 Mastra 或者 Ango 。第三点尤其重要，因为如果需要自主实现一个能与 agent 进行交互的单页面应用需要付出不少额外的精力，下图为 agno 的前端应用界面，它可能帮助你可视化的管理 agent 的方方面面。 但最终我既没有选择 Mastra 也没有选择 Agno ，而是选择基于 Cursor SDK 自建，原因来自于模型。 如果选择第三方框架，意味着我需要自行为其提供模型。而出于众所周知的原因，我无法使用官方提供的 sonnet 、opus 或者 GPT-5.4 模型，open router 在我所属的 IP 下也无法提供服务，我还尝试过 Vercel 的 AI Gateway 似乎也无法正常工作。与其继续纠结斗智斗勇不如直接选择可用的服务，例如 Cursor SDK （我可以指定其使用 Composer 2.5 模型）。并且使用独立 AI 模型的另一个弊端是额外的为 API 调用付费，而我相信我的 Cursor 会员能够覆盖这部分的用量。 HTTP 接口怎么办？使用任意 web server 框架对一次 agent 调用进行封装即可。至于前端——我当然可以 vibe coding 一个前端页面，甚至我早就有一个 开源项目 能够完成这方面工作——考虑我太懒了，以及本质上我们需要的是一个能够可视化 agent 输出以及与其沟通的“场所”而已，有一个更简单的地方可以派上用场：GitHub Issue 。我会确保所有的 agent 的输出都会以一个全新 issue 的方式创建出来，然后利用 comment 这种形式与 agent 进行沟通。 原文发布于此
最近一段时间我开始实践 AIOps ，即尝试使用 agent 来管理我的个人服务器，帮助我解决个人项目的线上问题。 我目前拥有一台部署在 Digital Ocean 上的 Droplet （也就是传统的 VM ），上面部署有网关服务 Kong 、定时任务平台 Kestra 、6 个 Agent/Workflow ，涉及 4 个 repo 。同时 Kestra 上运行有一个小时级别的定时任务，三个日级别定时任务，五个周级别的定时任务。并且可见日后新增的 agent 或者服务还会继续增加。用业余时间维护这些服务显然已经超过了我能够承受的负荷，因此借助 AI 来辅助我进行维护工作。 人是最大的瓶颈 AIOps 不是一个选项，而是一个结果 。因为 AI 带来的生产力提升正在让人成为交付过程中的最大瓶颈——我开始尝试 AIOps 的初衷也是基于此：AI 可以不费吹灰之力将我的想法变为现实，但这只是降低了我的制造成本而非是维护成本，上线之后遇到了太多的线上问题需要解决。如果我依然选择人工去修复每个问题，那从整个交付结果上看效率并没有任何的提升。这里我还需要替 AI 辩解一句，从事后看诸多的线上问题并非是源自生成代码不够健壮，而是来源于意料之外的不确定因素，例如网络抖动、例如第三方后端服务契约的改变。 于是让 AI 应对 AI 就是水到渠成的事，我的第一个 AIOps 版本是：一旦有线上问题发生，某个 debug agent 便会被自动唤起，它不仅能够获取到日志，还可以通过 GitHub MCP Server 获取到源码，从中便可以推断出服务镜像是如何构建以及服务是如何被部署的，它还可以调用 docker CLI 来获取底层的 docker container 运行状态。最后综合以上信息生成一份涵盖 pull request 的解决方案。 听上去很美好是不是，但人作为瓶颈的这个问题并没有被解决。因为 AI 所生成的长篇解决方案、pull request 依然等待着开发者的 review 和批准 。某种意义上说，它只是让问题推迟发生了。 当然我们还可以选择将 AI 应对 AI 的策略贯彻到底：用另一个 AI 来评审当前 AI 提出的 pull request——我尝试这么做过，鉴于 debug agent 是基于 Cursor SDK 开发，于是我选择在 GitHub 上集成了 Gemini Code Assistant 来对 Cursor SDK 生成的代码进行评审——但这并没有让情况变得更好，我发现 Gemini 总是能对 Cursor 生成的修改提出“不满”，严重程度均为中度往上的。如果你真的对每一则意见都进行评估，那最后 AIOps 带来的结果是事与愿违：效率不但没有得到提升，还最终你精疲力竭。 到现在你也许已经发现了问题的症结所在：只要人还存在于交付的任意一个环节中，无论是 QA 还是代码评审，端到端的交付效率就无法彻底得到提升 。 解决问题的方式很简单：把人移除，让 AI 自身持续改进。我正在尝试这么去做，不过事实上已经有人在付诸实践了，在最近 OpenAI 官方发布了一篇文关于 Harness Engineering 的文章 《工程技术：在智能体优先的世界中利用 Codex 》 （ Harness engineering: leveraging Codex in an agent-first world ）中，他们的做法是： 我们会指示 Codex 在本地审核其自身的更改，在本地和云端请求额外的特定智能体审查，对任何人工或智能体给出的反馈做出响应，并循环往复，直到所有智能体审核人员都满意为止……随着时间的推移，我们已将几乎所有的审核工作调整为用智能体对智能体的方式来处理。 如果你有兴趣的话可以深入其背后的深层思想： Ralph Loop 。即构建一套自治循环（ autonomous loops ）的系统，人只负责定义目标和约束，让 AI 持续执行任务、测试、修复、提交、部署。 共享工具，独享上下文 在相当长一段时间内有一件事我想不清楚：究竟需要多少个 agent 来解决所有可能发生的线上问题？ 我可以选择按照纵向服务模块来设计，分别给 Kestra 、Kong 、Agents 都准备一个独立的 debug agent 为其服务；还可以选择从横向出发，分别为 host 主机、docker 服务、应用层服务配置 debug agent——所有上面这些想法并不切实际，因为从实际解决问题的角度出发， 无论是人还是 AI ，他或它需要的都不仅仅是某个切面的数据，都是每个切面的数据 。 我的经验是，信息的收集对于解决问题至关重要。越靠近生产环境，越多的问题可能是由非代码引起的。一旦我们无法找到有效的出错栈信息，那么就需要从基础设施，从跨功能需求上寻找答案，那么如何排除每一种可能呢？信息，贪婪的获取信息至关重要。 本质上 debug 过程遵循的是情报周期（ Intelligence cycle ） ：决策者首先确定需求，然后根据需求收集有关的情报，并随之进行整理和过滤，最后对其进行分析并从中找出威胁或者有效信息。决策者还需要根据反馈结果继续决定是否进行下一轮迭代。 例如我发现 Kestra 某几个定时任务的失败是源于 VM 的内存和 CPU 已经满负荷运行，而之所以满负荷运行，部分又是因为多个定时任务的几乎在同一时间运行——在这个例子中，agent 需要在 Kestra 日志，Docker 日志，以及多个源码之间反复横跳才能找到症结所在。 所以即使我需要多个 agent 解决多个纵向领域内的问题（在同一套基础设施环境内），它们的能力也不会有太大差异，完全可以共享一整套的工具（函数）或者 MCP Server 。但解决不同类型问题 agent 需要的上下文却不尽相同。例如对于一个专业解决 Kestra 定时任务有关问题的 agent ，它不仅需要理解 Kestra 自身是如何构建以及部署的，还需要了解每个定时任务背后，那个由 HTTP 触发的后端服务的是如何构建以及部署的；而对于解决 docker 有关问题的 agent 而言，它只需要你给它足够高的 Docker CLI 使用权限就够了。 所以回到本小节开头的那个问题？我们究竟需要多少个 agent ？我的答案是一个就够了，我们可以创建一个拥有各种工具箱的 agent ，然后将上下文信息在调用 agent 时以 prompt 的方式传递给它即可。 你可能会想到其他的一些可能的解决方案，例如 sub agent ，又或者 agent team ，绝大部分框架都已经提供了开箱即用的类似机制。我之所以没有选择一方面是因为简单的架构与代码对我来说颇为重要，二是因为按照我的开发经验看，我对 agent 之间的交互没有信心：agent 的工作过程越是动态，不确定性越高，失败的概率也就越高。 Agent 的部署与落地 最后我们聊聊实现层面的问题。 首先，Agent 必须“寄生”（部署）在应用程序所在的运行环境中，一方面是为了实现我上面所说的，尽可能多的获取应用自身及其所处环境的数据信息（如果程序是运行在如 Vercel 或者 Render 这样的 PaaS 平台上，至少需要保证 agent 能够通过 API 获取到日志信息）；另一方面是为了便于 agent 被及时唤起介入线上问题。整体上看部署在云上的 agent 会比部署在本机的 agent 更有优势。 虽然 agent 部署在远端，但开发者依然需要具备访问它的能力，包括了解它是如何思考的，看到它的解决方案是什么，在必要时与其对话对解决方案进行修改。你可以把这个当作另一种关于 agent 的 observability ，只不过这里指的是将它的工作过程和工作结果可视化，而不是将它 agent 的代码调用过程可视化。 目前并不存在满足上述需求的开箱即用的工具，虽然 Codex 和 Claude Code 在 debug 上是高手，但它们仅仅适用于于本地调试。所以我们需要基于已有的 agent 框架进行二次开发。而根据我以上的描述，agent 框架的需要满足最重要的三点需求： 支持配置 tool 与 MCP Server ，以便与不同的平台和环境集成 框架自身提供 HTTP 接口能够供外界服务服务调用 agent ，这便于 agent 与第三方服务集成 框架提供前端界面供用户与 agent 持续进行对话 虽然并非市面上每一款 agent 框架都具有上述特性，但是能够找到符合以上三点的框架还是不少，比如 Mastra 或者 Ango 。第三点尤其重要，因为如果需要自主实现一个能与 agent 进行交互的单页面应用需要付出不少额外的精力，下图为 agno 的前端应用界面，它可能帮助你可视化的管理 agent 的方方面面。 但最终我既没有选择 Mastra 也没有选择 Agno ，而是选择基于 Cursor SDK 自建，原因来自于模型。 如果选择第三方框架，意味着我需要自行为其提供模型。而出于众所周知的原因，我无法使用官方提供的 sonnet 、opus 或者 GPT-5.4 模型，open router 在我所属的 IP 下也无法提供服务，我还尝试过 Vercel 的 AI Gateway 似乎也无法正常工作。与其继续纠结斗智斗勇不如直接选择可用的服务，例如 Cursor SDK （我可以指定其使用 Composer 2.5 模型）。并且使用独立 AI 模型的另一个弊端是额外的为 API 调用付费，而我相信我的 Cursor 会员能够覆盖这部分的用量。 HTTP 接口怎么办？使用任意 web server 框架对一次 agent 调用进行封装即可。至于前端——我当然可以 vibe coding 一个前端页面，甚至我早就有一个 开源项目 能够完成这方面工作——考虑我太懒了，以及本质上我们需要的是一个能够可视化 agent 输出以及与其沟通的“场所”而已，有一个更简单的地方可以派上用场：GitHub Issue 。我会确保所有的 agent 的输出都会以一个全新 issue 的方式创建出来，然后利用 comment 这种形式与 agent 进行沟通。 原文发布于此
IT之家 6 月 3 日消息，在今日开幕的 Build 2026 开发者大会上，微软宣布在去年为 Edge 浏览器推出基于 Phi-4-mini 模型的写作辅助 API 基础上扩展了其端侧 AI 能力，新增了模型和 API。本次更新主要包括三项内容： Aion-1.0-Instruct 小语言模型的开发者预览版（用于早期测试和反馈）； Edge 148 版本中由端侧任务专用模型驱动的语言检测和翻译 API； 以及在 Edge Canary 和 Dev 通道中提供的实验性 Web Speech API 端侧语音识别功能。 微软表示，过去一年中，Edge 浏览器的写作辅助 API 一直基于 Phi-4-mini 模型。这是一个 40 亿参数的模型，在文本理解、推理和指令遵循方面表现出色，但其硬件要求限制了它在不同设备上的可用性。 因此，微软即日起在 Edge Canary 和 Dev 通道中引入了 Aion-1.0-Instruct 小语言模型的开发者预览版。该模型更小、更快、更高效，可扩展到更多设备 —— 包括 GPU 性能较低的设备，以及通过 CPU 推理支持无 GPU 的设备，同时为广泛的 Web 使用场景提供良好的输出质量。 该预览版允许开发者在真实 Web 场景中评估 Aion-1.0-Instruct，测试 API 互操作性并提供反馈，该模型计划于 7 月以开源形式发布到 Hugging Face。 在 Edge 148 预览版中，全新的语言检测和翻译 API 已正式可用。这些 API 允许网站和浏览器扩展识别文本语言并在语言对之间进行翻译，基于端侧任务专用模型，支持 145 种以上语言，并针对 Web 翻译负载进行了优化。 开发者可以在网站或扩展中使用 JavaScript 调用这些 API，相比云服务，可获得更好的用户隐私、网络独立性以及零翻译成本。 在最新的 Edge Canary 和 Dev 通道中，微软还引入了处理语音的端侧任务专用模型，实现了 Web Speech API 的本地语音识别。该实现将语音转文字过程在用户设备上本地完成，可改善用户隐私、降低延迟，并支持低网络连接或无网络场景。开发者只需在现有 Web Speech API 代码中做少量修改，例如设置 recognition.processLocally = true，即可启用端侧语音识别。 微软表示，借助 Aion-1.0-Instruct 小语言模型、新的语言检测和翻译 API 以及端侧语音识别，开发者可以利用内置于浏览器的模型打造基于 AI 的 Web 体验，无需依赖专用硬件、云服务或特定领域专业知识。
IT之家 6 月 2 日消息，CORSAIR（海盗船）在 2012 年曾推出过设计灵感源自弹药箱的 VENGEANCE C70 机箱，赢得了不少 PC 装机玩家的喜爱。而在 14 年后，尽管整体 DIY 市场的审美在向精致靠拢，军武风格的产品仍不乏爱好者。 海盗船于今年的台北国际电脑展上带来了 VENGEANCE C70 的“精神继承者” WARTHOG 。该机箱“疣猪”的名字很显然来自 A-10 攻击机。 WARTHOG 拥有厚实钢结构、集成把手以及易于操作的侧板，还导入了一系列的现代设计，包括 3D Y 型镂空前板、InfiniRail 风扇安装系统、RapidRoute 2.0 主板托盘、显卡支架，还提供对背插主板的支持。此外其支持一对 200mm 风扇，前置 I/O 接口拥有金属保护盖。 海盗船此次还推出了支持 10 颗风扇与背插主板的 Micro-ATX 海景房机箱 2800X RS-ARGB 、拥有实木前板的 FRAME 5000D WOOD RS 。 在冷却产品线上，海盗船带来了多款基于 FlowDrive Gen 2 水泵打造的 iCUE LINK TITAN II 家族 360 规格水冷。其中 ULTRA 360 LX LCD 结合了双层交叉流向冷排、优化冷板、新 TM100 热界面材料，部分型号配备 5" 720×1280 多功能显示屏。 iCUE LINK LX360 RGB Unified Frame 单框风扇也一并公布，提供正叶与反叶版本。其每个扇体拥有 18 RGB LED 组成的双层光环，整体集成 iCUE LINK 系统集线器。
IT之家 6 月 2 日消息，北方华创今日发布全新 12 英寸气体团簇离子束（GCIB）刻蚀设备 Acme Glaion130。 该设备突破三大核心技术瓶颈， 覆盖先进逻辑、存储、封装、硅光芯片及 AR / VR 应用场景 。 随着集成电路制程向先进节点迈进，芯片特征尺寸进入原子级，对加工精度、表面质量和损伤控制提出严苛要求，而传统化学机械抛光（CMP）、等离子刻蚀存在划痕、亚表面损伤、精度有限等短板，无法满足先进逻辑、存储、硅光芯片等领域的核心需求。在此背景下， 离子束刻蚀凭借原子级精度和近零损伤优势，成为后摩尔时代半导体制造的关键工艺装备 。 IT之家从公告获悉，传统等离子刻蚀依赖化学反应 + 离子轰击实现材料去除，而离子束刻蚀通过将离子加速并中和后直接轰击晶圆表面，依靠物理溅射完成材料去除，两者原理差异决定了性能差距。 与传统工艺相比， 团簇离子束刻蚀精度为纳米级，方向性更佳，可实现近零损伤加工 ；几乎适配所有材料，工艺灵活性更高，能完成晶圆局部定点精修、任意角度刻蚀等复杂需求。 Acme Glaion130 成功攻克业内三大技术难题，实现关键技术自主： 气体团簇离子源技术： 与常规单体离子源技术相比，刻蚀速率更快、表面质量更优、工艺损伤更低；团簇离子源的稳定性和束流质量达到同类型设备的更优水平，为原子级刻蚀提供核心支撑。 高速运动下电极技术： 可实现晶圆的精准、快速定位，解决了高速运动下的稳定性难题，保障加工精度。 动态精确控制算法： 搭载原位膜厚量测装置，形成所需刻蚀 Map 并优化载台运动轨迹，实现晶圆局部定点精修。 Acme Glaion130 具备多场景兼容能力，满足高端芯片及前沿领域刻蚀需求： 先进逻辑 / 存储芯片领域： 通过定向刻蚀节省光罩层、降低工艺成本；设备实现高选择比刻蚀，可降低线条侧壁粗糙度、消除桥连缺陷，提升器件良率和性能，保障先进逻辑及存储芯片量产。 先进封装领域： 实现表面活化、污染物去除及精准修平，提升晶圆键合质量和膜厚均一性，助力三维集成技术发展。 硅光芯片领域：可实现原子级表面平坦度，降低光散射损耗，提升光通信效率，助力硅光芯片产业向高端化迭代升级。 AR / VR 领域： 支持离子束入射角度灵活调节，实现光栅刻蚀高均一性和渐变深度刻蚀，助力 AR / VR 设备光学性能升级。 北方华创表示，Acme Glaion130 实测性能优异，整面刻蚀膜厚控制精准，保持原子级光滑表面， 综合性能达到同类型设备领先水平 。
我在用AionUi, 用着还行, 但想试一下别的开源的多模型集成工具。 找到LobeChat, 安裝后打开发现需要登录, 我擦了 不想又开一个号, 我只在是本地用, 有沒有佬知道怎么绕过登录页面? 或者是有其他更好的集成工具推荐, 谢谢佬们 10 个帖子 - 6 位参与者 阅读完整话题
prnewswire.com Parker Waichman LLP Files Lawsuit on behalf of Florida Resident Alleging... /PRNewswire/ -- Parker Waichman has now filed multiple lawsuits on behalf of victims who were prescribed Ozempic or Wegovy and developed NAION, an irreversible... [!quote]+ Parker Waichman 是一家全国性律师事务所，目前已提起多起诉讼，每位原告都声称自己在服用诺和诺德的 Ozempic 或 Wegovy 后患上了非结节性神经炎。 纽约州华盛顿，2026年5月22日/PRNewswire/------帕克·韦奇曼律师事务所(Parker Waichman)已代表多名服用奥泽普(Ozempic)或维戈维(Wegovy)后患上非动脉炎性前部缺血性视神经病变(NAION)的受害者提起多起诉讼。NAION是一种不可逆的眼部疾病，会导致一只或双眼部分或完全永久性失明。2026年5月8日，该律所代表一名服用维戈维后患上NAION的佛罗里达州居民提起诉讼。参见Monastiero诉诺和诺德公司等，案号：2:26-cv-03132。 Parker Waichman LLP 持续受理更多案件，并敦促服用这些广泛使用的GLP-1受体激动剂类药物后遭受严重眼部损伤的患者与他们联系，进行免费案件评估。这些药物最初用于治疗2型糖尿病，但因其减肥功效而迅速走红。然而，近期研究发现，司美格鲁肽（Ozempic/Wegovy）与非动脉炎性前部缺血性视神经病变（NAION）之间存在令人不安的关联。NAION是一种通过阻断视神经供血而导致永久性视力丧失的疾病。服用过这些药物的患者报告出现突发性失明、视神经损伤和其他不可逆并发症，这引发了人们对药品生产商未能就这些风险向消费者和医疗专业人员发出警告的担忧。 2025年发表在《美国医学会眼科杂志》（JAMA Ophthalmology）上的一项研究调查了9名在使用GLP-1类药物后出现视神经疾病的患者，其中大多数患者出现了类似非动脉炎性前部缺血性视神经病变（NAION）的症状。哈佛大学麻省眼耳研究所的另一项研究发现，糖尿病患者使用索玛鲁肽后发生NAION的风险是普通人群的四倍，而非糖尿病患者服用该药减肥的风险则增加了七倍。 尽管科学证据越来越多，诺和诺德公司仍然淡化这些药物的危险性，没有就永久性失明的风险发出充分的警告。 ScienceDaily Wegovy linked to rare “eye stroke” that can cause sudden blindness A new analysis is raising concerns about Wegovy, the blockbuster weight-loss drug, after researchers found it may carry the highest risk of a rare “eye stroke” that can cause sudden vision loss. The study, based on millions of FDA side-effect... 3 个帖子 - 2 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 大家好，这是一个除了“界面”有点像、但“骨头”和“血肉”都不一样了的AionUi。 不过这次憋了一个月才和大家见面，这个故事有点长，代价有点大，心有点痛… 故事的开始，要从一个想要摆烂的瓦砾说起。 在放弃的边缘挣扎 有一段时间，我一直在放弃AionUi的边缘挣扎。因为。。 AionUi最初设计不太优雅，导致屎山代码多到无法维护，每天来自于佬友(大家还算温柔的)、推特、小红薯、绿泡泡群、Discard、Github issue 的朋友们反馈的Bug… 剧透 更难的是，bug越改越多，时间都用来改bug了都没办法做新功能。因为一个新功能必然会导致更多的bug 。。。我事后反思了一下，主要原因有以下几点（最后一条最重要）： 架构很脆：毕竟最开始就是做着玩的，我一个产品经理也搞不明白啥叫优雅方案，也没个靠谱的架构师把把关，当时感觉能实现功能就已经很满足了。 代码耦合严重：758 个源文件、59,000行代码，前后端逻辑混杂在同一个工程里，很难独立迭代。 不够AI友好：模块之间互相依赖，改动的风险很难评估。就算有AI排查给的方案除了打补丁就是打补丁。 我太菜：和AI一起打补丁打得太痛苦了，实在是感觉绷不住了。 干脆重写 事实证明，当屎山积攒到一定地步的时候，人就会想要一切都重来。所以。。AionUi重写了 让AionUi帮我写了页PPT来介绍下新方案（有认真问AI对它是否友好w） 但过程并不美好，这个重构过程全是陷阱 ： 缺少调研发导致依旧不优雅的架构、看不懂的Rust、拆不明白的文件数… 刚让AI跑出来的后端，和前端对接才发现后端设计不合理，又开始按照模块前后端重写… 这个过程真是无比令人绝望。好在总算是憋出来了，反正我这辈子是不会想再经历第二次了 重构后有什么变化 我又让AionUi帮我写了一页PPT 其实不止这些，界面体验也变舒适了，真的有在认真借鉴和打磨，如果大家也觉得体验变好了，一定要给我说噢 w 不过，这件事情带来的代价也是巨大的： 几乎一个月，产品+认知的双暂停 >> 想加的功能迟迟憋不出来，想体验的新产品没空看，想逛的L站也没空逛。至今不知道这次重构的方案是好是坏，不过万事没有回头路，但是既然已经发生了，那就接受并继续往前看吧 现诚邀大家体验新版AionUi，感受它的的重生 github.com GitHub - iOfficeAI/AionUi: Free, local, open-source 24/7 Cowork app for... Free, local, open-source 24/7 Cowork app for OpenClaw, Hermes Agent, Claude Code, Codex, OpenCode, Gemini CLI and 20+ more CLI | Customize your assistants | Star if you like it! 20 个帖子 - 20 位参与者 阅读完整话题
IT之家 5 月 24 日消息，中兴通讯终端事业部总裁、努比亚技术有限公司总裁倪飞宣布， 努比亚 Z80 Ultra 手机现已支持 DeepSeek-V4， 无需更新系统版本 ，即刻生效。 据介绍，不仅努比亚 Z80 Ultra 手机支持了 DeepSeek-V4， 所有搭载了星云 A IOS 2.0 机型也同步上线支持 DeepSeek-V4 ，全面覆盖 Z60 / 70 / 80 等系列。 ▲ IT之家开箱：努比亚 Z80 Ultra 图赏 据IT之家此前报道，今年 4 月 24 日， DeepSeek-V4 模型预览版正式上线并同步开源 。DeepSeek-V4 拥有百万字超长上下文，在 Agent 能力、世界知识和推理性能上均实现国内与开源领域的领先。模型按大小分为两个版本： 相关阅读： 《 迈入百万上下文普惠时代：DeepSeek-V4 模型预览版正式上线并同步开源 》
发现了个彩票开奖和走势的网站，感觉看着还不错，大家有没有类似的网站 https://caipiao.aiones.cc/
发现了个彩票开奖和走势的网站，感觉看着还不错，大家有没有类似的网站 https://caipiao.aiones.cc/
发现了个彩票开奖和走势的网站，感觉看着还不错，大家有没有类似的网站 https://caipiao.aiones.cc/
发现了个彩票开奖和走势的网站，感觉看着还不错，大家有没有类似的网站 https://caipiao.aiones.cc/
发现了个彩票开奖和走势的网站，感觉看着还不错，大家有没有类似的网站 https://caipiao.aiones.cc/