我让Claude远程管理我的PC超频，居然真的成功了

超频这类爱好，折腾本身就是乐趣所在，所以把整件事交给 AI，感觉有点像花钱请别人替我吃甜点。但最近我一直在智能体这个兔子洞里越钻越深——自从我让 Claude 改进我的家庭实验室，结果相当疯狂，以及让 Claude Cowork 访问我的 Home Assistant 配置之后，我还剩一个问题：它能处理真实硬件、承担真实后果吗？于是，我通过 GL.iNet Comet X KVM-over-IP 给了它在我 Z890 测试平台上的眼睛和手，让它对准我技嘉 Z890 AORUS 主板上的 UEFI——插槽里是一颗 Intel Core Ultra 5 250K Plus——然后告诉它：跑快点。

说清楚一点，我并没指望这能成。计划是让 AI 通过一个只能看到 JPEG 截图的 BIOS 界面导航，一次一个按键，走网络 HID 连接。我打赌午饭前就会软砖、陷入启动循环。结果我得到的是一个稳定的超频、100 mV 的降压，以及——这部分最扎心——一台机器，它礼貌地证明了测试平台上最大的性能瓶颈其实是我自己。

配置：一个 AI、一个 KVM，和一个应急智能插座

截图当眼睛，虚拟键盘当手，以及我这边全程紧张地盯着屏幕

这套控制流程说起来简单得离谱。Comet X 暴露了一个 kvmd API，所以一个小型 Python 脚本给 Claude 提供了两个基本操作：抓取测试平台当前显示的一帧画面，以及以 USB 键盘方式发送按键。就这样。目标机器上没有运行智能体，没有特殊的 BIOS 固件——AI 看到的设置界面和我看到的一样，来自 1080p 截图，在 POST 期间跟我们一样猛按 Delete 键。测试平台之所以能远程访问，全靠支撑我整个实验室的那套远程访问方案——我之前换用了 KVM-over-IP。

基准测试在 Windows 侧通过 SSH 运行：一个 PowerShell 把关脚本依次启动 7-Zip、PYPrime、y-cruncher 和 Cinebench 2024，扫描事件日志中的 WHEA 硬件错误，通过 HWiNFO 记录封装温度和功耗，并把结果以 JSON 形式丢进 OneDrive，AI 在那里读取结果并规划下一次 BIOS 更改。每次迭代一组更改，在进入下一轮之前完成基准测试和压力测试把关。安全护栏不可妥协：在第一次更改前保存一个已知良好的 BIOS 配置文件，并在测试平台电源上接一个智能插座，作为应急恢复手段——万一某个糟糕的设置让主板彻底卡死、连 CMOS 自动重试都救不回来。

关于信心程度，我想说实话，因为整个方案能不能成，就看一个问题：语言模型能不能靠谱地驱动一个它只能靠一堆截图来感知的UEFI？第一次会话只做地图——不许改任何东西，就是导航、记录。我就坐在那儿，看着光标自己在我的Tweaker菜单里一步步走，等着它一不小心晃到某个电压选项上开始打字。它没有。结果它带回来一张完整的导航图，确认了我的恢复设置，什么都没碰。这就算赢了。不过第一次调优的整个过程，我的手一直没离开过电源插头附近。

发现：六次蓝屏，一份黄金配置

拒绝了一次超频、却吞下了另一次超频的芯片

好吧，咱们从结尾说起，倒着捋，因为对我来说，真正让我意外的不是我能给Intel Core 5 250K Plus超频，而是一个代理框架居然也能做到。所有测试跑下来，硬件没有任何变化，还是同一个Noctua散热器，BIOS也是原厂配置，跟我们最终调好的方案做对比。

最终配置：功耗限制解锁至250 W，Intel的性能功耗调度方案，NGU（非核心）倍频从26x提升至34x，再降压−100 mV——峰值功耗197 W，温度77°C。保守？那确实。但这正是芯片体质抽奖的体现，这颗芯片一方面让人失望，另一方面又还不错。

经典的核心倍频超频方案第一个翻车了。静态54倍全核超频纸面上看着挺美，但跑分却比默认自动设置更慢——y-cruncher性能下降了7.9%，而核心运行在更高的频率上，这正是环形总线喂不饱计算单元的典型表现。事实证明，Arrow Lake自身的睿频管理在这方面比一刀切的倍频更聪明，除非你先把底下的互联总线调好。

于是我们就去折腾互联总线了，参照SkatterBencher的250K Plus指南中的数据，而正是在这里，我这颗芯片的脾气就露出来了。我这颗特定样品的裸片间（D2D）互连连默认30倍往上提一档都不肯。自动电压不行，SkatterBencher验证过的1.0V也不行，内存从DDR5-8800降到8000还是不行——六次崩溃，六次不同的Windows蓝屏代码，有一次甚至在系统还没加载起来就崩了。

跟他指南里那颗是同一个SKU，那颗芯片可以轻松跑到36倍。硅片抽奖这事儿是真的，而且是每个域单独抽：同一颗裸片上的NGU从26倍拉到34倍一声不吭，还顺手刷了个项目最佳成绩。

接下来是降压，这正是这块芯片秀肌肉的地方。在禁用英特尔CEP和降压保护后（如果保持开启，你的降压要么毫无效果，要么性能被悄悄压住——别问我怎么知道的），Claude逐步下调DVID偏移：−50 mV、−75 mV、−100 mV。每一关都稳稳通过。更妙的是：每一步的持续Cinebench分数都在上升，因为每削减一毫伏都释放出散热和电流余量，直接变成了能稳住的频率。我们始终没探到底。一块无法将总线超频哪怕一个档位、却能轻松降压100 mV的芯片——规矩又不是我定的。

真正的教训：无聊的修复让聪明的方案相形见绌

一个AI从基准测试表中诊断出了我的散热器安装问题

这是我最喜欢的发现，而且跟倍频一点关系都没有。这次调校一上来就翻车了——解锁功耗限制反而让一切更慢，Cinebench下降了12%。Claude点出了这种性能倒退的规律：单核结果持平，全核结果崩溃，持续散热这一关被打得最惨。这种模式意味着热量没有离开芯片。我去看了看实际情况，结果嘛……散热器根本没装好。我在调校前重新装过，但装砸了。

光重新装一下，在完全默认设置下Cinebench就提升了19.7%。对照上面的表格来看：整个调校过程只增加了5%到7.7%。这个平凡的修复以约四倍的差距击败了那些奇特的方案，而且甩得远远的。一张基准测试表在没人打开机箱之前就诊断出了机械问题，我觉得这比超频本身还厉害。

另外两个改变测试进程的关键发现都来自人，我觉得这个区别很关键。在深入排查崩溃原因的过程中，我注意到我的主板一直运行在英特尔的“Baseline”供电配置下——这是为VRM较弱的主板准备的保守预设，在一款旗舰主板上不知不觉地把电流上限压在了203 A。切换到Performance配置后，持续封装功耗额外增加了约30 W，并解锁了NGU那部分的性能收益。

AI第一天就定位到了那个BIOS界面，然后直接略过了它；得靠人去读SkatterBencher的脚注，才意识到这一步很关键。英特尔的200S Boost配置也是如此，我们把它当作附加测试也试了一下：结果它有两个原因导致无法启用。英特尔将该配置限制在8,000 MT/s，模块VDD和VDDQ不超过1.4 V，而我的DDR5-8800套件速度比这还快，电压也跑在1.45 V。官方认可的超频方案，偏偏把发烧友会配这块主板的那种内存排除在外。

所以不，AI没有取代我。它跑的实验循环比我能做到的任何时候都更严密——它从不会在凌晨3点跳过压力测试环节，从不会一次性莽撞地改两个地方，记录了每个停止代码——而我则抓住了它视野之外的那些东西。这种分工才是整件事的关键所在。

AI 超频助手，最好由人类来负责多想几步

我本来以为这就是个花架子，结果却拿到了我日常用的基准配置。最终的配置文件比出厂设置更快、更凉快、更安静，每一步都有记录且可复现，整个过程只花了一个周末，且没有永久损坏任何硬件——而这正是我一开始最担心的两件事。当然，5-8% 的提升不会改变任何人的生活，而且一颗风冷的 250K Plus 也从来不可能威胁任何记录。但这个过程发现了一个散热器安装不良、一个主板默认设置上的偷懒行为，还有英特尔自家加速配置文件里的内存电压锁死问题，这其中任何一项，对一台真实系统来说，都比那点倍频更有价值。