先说结论：这篇论文值得读。值得读的不是那个框架，是那张对照表。
「AI 帮你写 Verilog」「自然语言直接出 RTL」「流片前自动验证」——这届文案把硬件设计说得跟写 Python 脚本一样轻松。听起来很美。但所有人都回避了一个物理事实：软件代码有漏洞，发个补丁，服务器夜里重启，完事。RTL 代码有漏洞，流片之后怎么办？把晶圆召回来？把掩模重做一遍？
芯片不是 App。没有「隔天热更新」这回事。
SECRTL-GEN 干的事，就是往这锅温水里倒凉水。它拿 392 个任务测 5 个前沿模型，每个任务配一个黑盒功能测试平台，再配一个黑盒安全测试平台。最狠的是任务设计：功能说明里故意不写任何安全要求。不是不知道，是不告诉你。
功能测试平均通过率，73% 到 79%。
安全测试平均通过率，14% 到 35%。
这组数字我盯着看了半天。十个任务里七八个能跑通功能，写 RTL 这件事在当下的技术叙事里已经算「能用了」。但安全测试？十个里最多过三个半。最差的那个模型，十个过一个是常态，不是意外。
功能正常，安全裸奔。两件事同时成立。不是偶发，是统计规律。
第二条结论更扎心：功能正确性更强的模型，不自动具备更强的安全性。你在 benchmark 榜上追着跑分高的模型换，换到天花板也换不来安全。这跟你雇一个写业务代码天下无敌的程序员去写密码学库，是两码事。会写功能代码与会写防御性代码，中间隔的不是技巧，是意识。
论文里做了对照实验，往提示里注入 CWE 相关知识——安全通过率涨了。反过来让模型「自己好好想想」，不给外部知识、纯靠自省的那种——帮助小得可怜。翻译成人话：你指望 AI 自己琢磨出「这里可能有坑」，不如直接把坑的位置告诉它。
模型不笨。是功能规格根本没给它弱点意识。它的算力全在琢磨「怎么把功能写对」上，哪来的余粮管攻击面？
然后这两类安全提示，都会拖累功能通过率。加安全知识，功能掉了。不加，安全崩了。夹在中间的模型厂商们，选择在通稿里只贴功能数据。这波，不冤。
所以论文作者的判断我认：RTL 不安全的主要瓶颈，不在大模型「不会写防御性代码」，在功能规格本身「缺少弱点意识」。规格是需求给的，需求是产品经理写的，产品经理脑子里只有功能，没有攻击面。源头就没种下安全这根弦，后面全链条白搭。
顺着这个判断，他们搞了个叫 RTL-Obliger 的框架。
我不打算把技术细节全铺开。核心思路值得说透一嘴：它没有让 LLM 自己「边写边想安全」，而是把这事儿拆成了流程。先把规格说明抽成一张功能语义图，再用符号引擎对着一份 CWE 模式本体，找出「哪些信号级的安全义务没被满足」，最后让 LLM 分两阶段改代码，改的时候死守功能正确性底线。
这套做法聪明在哪？它不给模型讲大道理，它给模型派活：这个信号，缺一条约束；这条路径，越界了。模型被要求补的不是一个抽象的安全策略，是一段具体的、能挡住某一种 CWE 的防御逻辑。
把一个劝人向善的问题，转化成一个机械的执行清单。
数据也撑得住：跨越 5 个模型、4 种语言，平均全通过率从基线方法的 49.6%-51.4% 提到 61.6%。全通过率是什么？功能测试和安全测试两个平台同时过，才算过。涨了十个百分点出头，方向对了。
但我没打算吹它。61.6%，往难听了说，离及格的 90% 还差着整个身位。每三个任务里，依然有超过一个任务不是功能挂了就是安全漏了。放到千万门级的真实 SoC 上，这个比例意味着什么，不用我多说了吧。
这只是个基准，不是灵丹妙药。它最大的贡献，是把「AI 写 RTL 在安全维度上有多拉胯」这个原本只能靠猜的命题，变成了有数字可查的评估工具。SECRTL-GEN 覆盖 5 个 CWE 家族、4 种 HDL，任务规模和粒度都对得起「基准」这俩字。以后哪个模型再宣称自己「硬件生成能力达到 SOTA」，先过一遍这 392 个任务再说。
论文是上个月 27 号挂到 arXiv 的，还在同行评审。评审会说什么我猜不到。但有一点是肯定的：SECRTL-GEN 里「功能说明有意不写安全要求」这个设计，是整套基准里画龙点睛的毒笔。现实里的需求文档就是这样，从来不会在每一条后面标注「此处注意 CWE-120，小心实现」。只有把这种「干净但轻视安全」的规格喂给模型，测出来的才是真实水平。不是竞赛现场，是生产环境。
锐评评分卡：这组研究者的思路值一个存档。「流片之后没有 hotfix」这句话，比任何发布会形容词都值钱。框架本身，方向对，路还长，61.6% 离「放心交给流片」还差得肉眼可见。但至少有人把照妖镜举到 AI 硬件生成这个赛道面前了。行业缺的就是这个。
至于「AI 帮你写芯片」这波宣传还剩多少水分，答案在那 14% 到 35% 里。