AI 帮 Linux 认出了 AMD 的 CPU 型号
AMD 内核工程师借 AI 理清思路，重写了 Zen 微架构的识别方式，从枚举型号改成判断区间。本文讲这个改动的动机、进度和它的真实边界。
内核里有一段代码，专门判断「这颗 CPU 是 Zen 几」——它已经长得没人想碰。
一、发生了什么
10 月 21 日晚，AMD 的内核工程师 Borislav Petkov 在 Linux 内核邮件列表上发出一份征求意见稿，主题是清理 AMD Zen 微架构的检测逻辑。Phoronix 在 10 月 22 日报道了这件事。
问题出在哪。内核里有很多代码路径只针对某一代 Zen，或者某几代，比如「这段只能在 Zen 3 到 Zen 5 上跑」。现在的写法是一堆分散的判断，加一代就要改很多处，很容易漏。
他的做法是把判断变成范围：能不能直接表达「3 到 5」这样的区间。这类判断散落在启动路径、电源管理和勘误处理里，每加一代都要人工扫一遍，漏一处就是一类难查的兼容问题。
这个想法从哪来？他在邮件里写得很直白：自己想不清楚怎么改，就去问了 AI；AI 给了一大堆空话，但基本思路是对的，于是他自己动手实现了。
验证进度也要说清。目前只在一个虚拟机里启动过，还没在真机上跑。他的原话大意是，先不想让猫着火，但真机测试很快会做。
还有两处收尾：用于标记「所有 Zen」的那个特性位暂时保留，把海光的用法从这上面挪开的工作留到后续补丁；这套机制可以扩展到 Zen 之前的型号，但他认为没必要。
这是一份征求意见稿，不是已经合并的代码。
二、跟你有什么关系
写内核或驱动的人。 这类清理不改性能，改的是「加一代新 CPU 要动几处代码」。如果你的代码里也散落着按型号枚举的判断，可以照这个思路改。
做国产 x86 适配的人。 邮件里专门提到要把海光从现有用法里挪出来，说明这类共用标记在不同分支之间是耦合点。
关心 AI 编程的人。 这条最值得注意的不是「AI 写了内核代码」，而是工程师描述的使用方式：拿方向，不拿代码。
三、怎么判断你的代码该不该这么改
读到这儿，可以顺路看 电脑操作 agent 干完活，谁来验货 读完能了解电脑操作型 agent 的任务完成度为何难自动核验：老办法只看局部画面，新思路让验证器自己动手探索取证，在线离线都能用，做 agent 数据与评测的人值得看。- 数一数同一类判断出现了几次。一个型号在十个文件里各写一遍，就是该改的信号。
- 把枚举换成区间。条件写成范围，新增一代时只改边界，不改调用点。
- 让 AI 出方案，不出现成补丁。它的价值在提示一种结构，落地要自己核对每个调用点。
- 先虚拟机后真机。启动验证能抓住大部分问题，抓不到时序和固件相关的部分，所以要分两步。
四、三个别信的说法
「AI 直接写好了这个内核补丁。」 邮件里说得很清楚：AI 给的是思路，代码是工程师自己写的。把这件事说成「AI 提交内核补丁」，是加工过的版本。
「清理代码不影响行为。」 判定逻辑一变，某些型号可能落到不同的代码路径。这种重构必须在真实硬件上逐代验证，这也是作者说还要上真机的原因。
「范围判断一定比枚举好。」 如果每一代的差异是离散且带例外的，硬套区间反而更绕。先看差异是不是真的连续。
五、一句话结论
这条新闻里 AI 的角色是提了一个结构，真正完成工作的是那个知道「必须上真机验证」的工程师。
信息来源
功能与价格以官方公告为准。本文写于 2026 年 10 月 23 日。
每周一封，只发新教程和可复制模板。不发广告，随时退订。