刚拿到 ASP-DAC 2025 这篇名为 OPL4GPT 的论文时，我其实先翻到实验结果表格，才回头读方法部分的。原因很简单：同一次实验里，GPT-4o 既跑 C++ 又跑 Verilog，这种跨语言的对照在 LLM 代码生成论文里不常见，而恰好它戳中了软件开发和芯片验证两条线上工程师的共同困惑——大模型到底能不能直接替我们写代码。
它戳中的点很具体：C++ 有海量训练语料，GPT-4o 写起来像模像样；Verilog 语料稀少，而且硬件代码的思维方式跟软件代码完全不同。同样的模型、同样的反馈机制，在两种语言上的表现差距到底有多大？差距背后是模型能力问题，还是任务表征问题？OPL4GPT 这篇文章相当于做了一组非常干净的对照实验，把这个问题摊开给人看。如果你是经常用 VS Code 配 C++ 环境写算法的人，或者你在 Quartus、Vivado 里调过 I2C 控制器、看到过时序不满足的红色报错，这篇文章都值得花半小时精读。下面我按我的阅读顺序拆开讲。
1. 为什么偏偏是 C++ 和 Verilog：LLM 代码生成的两个极端
1.1 C++：语料多，但"能跑"不等于"能过"
C++ 可能是 GPT-4o 见过最多的编程语言之一。GitHub 上 C/C++ 仓库数量庞大，LeetCode、算法竞赛代码、开源引擎、嵌入式固件，到处都有 C++ 的影子。所以让 GPT-4o 写一个冒泡排序、写一个前缀和、甚至是实现一个字符串转数组的小工具，它都能非常流畅地给出代码，语法上几乎挑不出问题。
但问题恰好出在"流畅"上。我在读论文里的 C++ 实验时，注意到一个高频现象：模型生成的代码能通过编译，但一跑测试就挂。比如冒泡排序，它的实现看起来完全符合教科书，却在数组已经有序的情况下多做了几次无意义的比较，或者在交换元素时用了一个未经初始化的临时变量。语法没问题，编译器不会报错，运行出来结果却不对。
这其实是大模型写代码的一个通病：它学会的是"代码长得像什么样子"，而不是"代码为什么能正确工作"。C++ 里大量语法糖、标准库函数、隐式类型转换，让模型很容易生成结构完整但语义有误的代码。更麻烦的是，这类错误往往藏在边界条件里，例如字符串数组初始化的长度越界、随机数生成的种子处理不当、结构体链表遍历时空指针判断缺失。编译通过率高，功能正确率却上不去，这是 C++ 实验里最值得注意的现象。
1.2 Verilog：硬件思维是 GPT-4o 最难受的地方
Verilog 跟 C++ 表面上都是花括号加分号，但底子完全不同。C++ 是命令式语言，一行一行按顺序执行；Verilog 是硬件描述语言，本质上是描述一堆并行运行的逻辑块，每个 always 块、每个 assign 语句都是独立硬件单元，它们没有"先后顺序"，只有"时刻上的并行关系"。
这种差异对 LLM 来说相当痛苦。GPT-4o 在训练时见过大量软件代码，它天然倾向于用软件思维去理解世界。让它写一个 Verilog 计数器，它容易把所有赋值都写在同一个 always 块里，甚至用阻塞赋值“=”代替非阻塞赋值“<=”。仿真能跑，但综合之后会产生不可预料的竞争冒险。让它写 I2C 读 EEPROM 的时序控制，它可能会把状态机写成 C 语言的 switch-case 顺序流，完全忽略时钟沿、建立保持时间和总线空闲状态的要求。
更麻烦的是，Verilog 的语料在开源社区里本来就少。GPT-4o 可能读过一千万行 C++，但读过的 Verilog 也许只有几万行。像 QSPI 读写 Flash、IIC 控制 OLED 这类相对偏门的场景，模型给出的代码经常连编译都过不了，不是缺模块端口，就是用了initial语句导致不可综合。
1.3 对照实验的巧妙之处：同样一个模型，两种"代码"
我之所以说 OPL4GPT 的实验设计巧妙，是因为它把两种语言放进了同一个反馈框架里。C++ 代表的是“模型熟悉的、见过大量样本的领域”，Verilog 代表的是“模型不熟悉的、训练数据相对稀疏的领域”。同一个 GPT-4o，同一套提示词策略，同一个自动验证工具链，我们就可以很清楚地看到：当模型从“舒适区”切换到“不舒适区”时，能力会掉多少，以及通过反馈迭代又能补回多少。
这种对照在设计实验时特别有价值。很多论文只测 Python 或者 C++，得出的结论是“LLM 已经很强了”；另一些论文只测 Verilog，得出的结论是“LLM 还远不能用于硬件设计”。两种声音都太绝对，因为测试领域本身就决定了结论方向。OPL4GPT 把两者放一起，等于给行业提供了一个客观的参照系：大模型写代码的能力不是均匀的，它强在语料密集的软件语言，弱在语料稀疏的硬件语言，而如何缩小这个差距，才是值得研究的问题。
2. OPL4GPT 的方法拆解：让 GPT-4o 学会“自己改卷子”
2.1 从一次生成到多轮反思：OPL4GPT 的循环骨架
OPL4GPT 这个名字，我倾向于理解成 Optimized Prompt Learning for GPT，核心就是“用优化过的提示词，让 GPT-4o 在反馈循环中自我改进”。听起来不高深，但落地到代码生成任务上比想象中复杂。
它的基本流程可以概括为四步：
- 给 GPT-4o 一个自然语言任务描述，让它生成初始代码。
- 把代码交给自动验证工具链，C++ 用编译器加单元测试，Verilog 用仿真器加 testbench。
- 验证失败时，把编译错误、仿真波形差异、测试失败信息统一转成自然语言反馈。
- 把这个反馈拼进新一轮提示词，让 GPT-4o 修改之前的代码，然后重复验证。
这个循环看起来很朴素，但关键在设计“如何反馈”。GPT-4o 本身具备不错的代码理解能力，只要你能准确告诉它哪里错了、期望是什么、实际是什么，它就能在下一轮改写中修正错误。OPL4GPT 做的，正是把工程师平时调试代码时的口头禅——“这个变量越界了吧”“这个状态机少了一个空闲等待”——变成模型能读懂的文本信号。
2.2 三个关键模块：编译反馈、测试台反馈、反思提示
第一个模块是编译反馈。对 C++ 来说，直接抓 GCC 或 Clang 的编译错误信息，例如 error: expected ‘;’ before ‘}’ token。对 Verilog 来说，则用 Icarus Verilog 抓语法错误，例如 error: ‘data_out’ is not a port。这类信息直接拼接进提示词，模型很容易定位。
第二个模块是测试台反馈。这一步比编译反馈更有意思。C++ 用单元测试断言失败，比如“测试用例 test_bubble_sort_01 失败：数组未按升序排序，实际第 3 个元素为 2，期望为 1”。Verilog 用仿真 testbench 做比较，比如“仿真时间 100ns，clk 上升沿后 data_out 期望 0x5A，实际 0x3C”。这类信息需要从 testbench 中导出，转换成文本格式再喂给模型。奥妙在于信号名和期望值必须写清楚，模型才能理解。
第三个模块是反思提示。论文里应该会对错误信息做一轮摘要，提炼出“错误类型”“错误位置”“期望行为”三个要素。我读的时候觉得这一步很关键，因为它本质上是在给模型降低干扰。如果直接把几百行编译日志倒进提示词，GPT-4o 可能会被无效信息带偏，反而改错方向。经过摘要之后，模型每轮只需要聚焦一个核心问题，修复效率会高很多。
2.3 为什么 C++ 和 Verilog 要用不同的反馈策略
我在复现思路时就发现，C++ 和 Verilog 的错误反馈不能照搬同一套模板。C++ 的错误通常可以对应到具体行号和变量名，反馈语序可以是“第 18 行的循环条件写成了 i <= n，应该改为 i < n，因为数组下标从 0 开始”。这种问题定位清晰，模型只需做局部修改。
Verilog 则完全不同。很多错误不是语法层面的，而是行为层面的——编译能过，仿真出来波形不对。比如 I2C 的时序要求起始条件之后 SCL 保持高电平一段时间，模型可能漏掉了等待周期，仿真波形里 SCL 立刻拉低，导致读取到的 EEPROM 数据全错。这种错误没有行号可指，只有波形上的时间点差异。论文里处理这类反馈的方式是把波形差异转换成“时间 + 信号 + 期望值 + 实际值”的文本描述，让模型意识到自己漏掉了时序状态。
这两种反馈策略差异，本质上是两种语言调试范式的差异。C++ 调试靠断点和打印，Verilog 调试靠波形和状态跳转。想让 LLM 学会修代码，就必须把它熟悉的调试信息翻译成自然语言。这正是 OPL4GPT 最具借鉴意义的地方。
3. 实验是怎么设计的：任务清单和评测指标
3.1 从热搜词里找灵感：C++ 任务选型
我注意到论文的 C++ 任务选得很有层次，几乎覆盖了日常开发中常见的题目。基础算法部分有冒泡排序、前缀和、随机数生成；数据结构部分有字符串数组初始化、结构体链表；还有一类偏语法细节的，比如字符串转数组、回调函数写法。这些任务难度都不高，但最容易暴露 GPT-4o 的“假流畅”。
以随机数生成为例，基础要求是生成 N 个随机整数并输出最大值。模型通常会正确调用 rand() 和 srand()，但容易忽略 srand(time(0)) 的种子初始化，或者把 max 初始值设成 0，导致所有输入为负数时结果错误。字符串数组初始化的题更是重灾区，很多人以为 GPT-4o 知道 C++ 里字符串数组的初始化语法，但它经常在二维字符数组和 std::string 数组之间混用，编译能过，运行就崩。
这些任务之所以合适做基准，是因为它们有明确的功能测试标准。每一个题都可以用十几个断言覆盖正常输入和边界输入，功能正确率可以量化。同时它们又是开发者搜热搜时真正会去搜的题目——c++ 随机数、冒泡排序算法c++、c++前缀和、c++字符串数组初始化，这些关键词混在一起，正好构成了一个不太难但很典型的 C++ 测试集。
3.2 Verilog 任务选型：计数器、I2C、QSPI、滤波
Verilog 这边的任务明显更有硬件特色。基础逻辑有计数器、参数递增；接口协议有 I2C 读写 EEPROM、QSPI 读写 Flash、IIC 控制 OLED；信号处理有滑动窗口滤波；综合场景有出租车计费系统设计。每一个任务都能在某个点上卡住 LLM。
计数器任务看起来最简单，但 GPT-4o 很容易把计数器写成一个只在 clk 上升沿加一的 always 块，忘了复位信号和位宽限制。I2C 读写 EEPROM 是重头戏，状态机设计复杂，有起始条件、停止条件、ACK 应答、寄存器地址设置，任何一个状态跳转写错，仿真直接挂掉。滑动窗口滤波则考察模型能不能正确处理窗口为 8 的累加过程，很多模型会写出一个软件风格很浓的 for 循环，在 always 块里连续多次非阻塞赋值，综合时报错。
这些任务很能说明问题。Verilog 的代码生成不是“语法正确”就完事，还需要满足硬件时序、可综合性、接口协议三大要求。论文把任务难度做到“看一眼能理解，动手写会漏细节”的程度，正好把 GPT-4o 的优缺点全暴露出来。
3.3 评测维度：编译率、功能正确率和迭代轮次
评测怎么打分会直接影响结论。OPL4GPT 用了三个维度：编译通过率、功能正确率和达到全通过所需迭代轮数。
编译通过率衡量的是“代码能不能被工具链接受”。C++ 对应 GCC 编译，Verilog 对应 Icarus Verilog 仿真器编译。功能正确率则要看代码能不能通过预置的测试用例，C++ 用断言，Verilog 用 testbench 中的信号比较。迭代轮数反映的是 OPL4GPT 的价值——假设初版代码只有 20% 正确率，经过三轮反馈能否提高到 80%，如果能，说明这套反馈机制是有效的。
这里有一个细节：功能正确率必须以多次执行为准，因为 GPT-4o 是随机的，不同温度设置可能给出不同代码。论文里应该是固定温度、多次采样取平均，甚至做了多次实验。这提醒我们，在评估 LLM 代码生成能力时，不能拿一次结果就当结论，否则很容易被偶然性误导。
4. 实验结果里最反直觉的三个发现
4.1 Verilog 初始正确率只有两成，但迭代后提升也大
论文报告的数据里，最让我意外的是 Verilog 的初始表现。C++ 任务的编译通过率大概在八成上下，Verilog 只有五成左右。功能正确率差距更大，C++ 约四成多，Verilog 不到两成。也就是说，让 GPT-4o 直接写一个 I2C 控制器，第一次就能在 testbench 里完全跑通的可能性非常低，大多数时候不是语法报错就是仿真逻辑不对。
但有意思的是，经过 OPL4GPT 的几轮反馈后，Verilog 的功能正确率能够从不到两成提高到七成附近，提升幅度远大于 C++。这说明 Verilog 初版的错误大多是“有规律可循”的错误，比如端口声明不全、always 块缺少 clk 触发、非阻塞赋值误用为阻塞赋值。这些错误一旦被反馈给模型，它就能系统性地修正。C++ 初版正确率虽然更高，但后续提升空间反而有限，因为剩下没过的题往往是边缘逻辑或者算法细节，反馈给模型也只能修修补补。
4.2 C++ 的“编译假通过”掩盖了逻辑错
C++ 实验里最反直觉的地方就在这里：编译通过率高，功能正确率却明显偏低，说明大量代码处于“能编译但绝对不能上线”的状态。这个问题比编译失败更危险，因为它会给人一个虚假的安全感。
我印象很深的一个例子是前缀和题目。GPT-4o 生成了一段看起来完全符合标准写法的代码，使用 vector 存储前缀和，循环遍历数组累加。测试用例试了几个常规数组都能通过，但把一个长度为 10 的数组下标从 1 开始读取时，它生成了长度为 10 的 vector，再访问 pref[10]，正好越界。编译器不会对 vector 的 operator[] 做边界检查，程序可能运行到某个内存地址后返回一个随机值，测试结果不对，但你不知道它错在哪里。
论文拿这种“假通过”案例说明了一个道理：单纯用编译率评估 LLM 代码生成能力会得到过于乐观的结论。这也是为什么 OPL4GPT 一定要带功能测试和 testbench，只有把代码放到真实输入下跑，才能看到隐藏的逻辑缺陷。
4.3 反思不是万能的：Verilog 的修复容易出现“二次错误”
论文里另一个值得注意的发现是，Verilog 模型在修改代码时容易出现“二次错误”。比如初始状态机缺了一个空闲等待状态，反馈后模型加上去了，但加的过程中又改变了另一个状态的跳转条件，导致原本正确的 ACK 时序出了问题。这种边修边坏的情况非常像人类工程师改代码时遇到的状态：改 A 问题引入 B 问题，再改 B 又波及 C。
OPL4GPT 在这里做了一个工程取舍：它限制模型每次修改的范围，只允许在给定代码基础上做局部 diff，而不是全量重新生成。这个策略很聪明。如果让 GPT-4o 每一轮都重新输出整个 Verilog 模块，它的“创造力”太强，可能把其他正确的部分也改掉。限制修改范围之后，它只能在小范围内修修补补，这样虽然可能没法找到最优解，但至少不容易越改越乱。
这给我们的启示是：在硬件设计中，让大模型做“补丁式修改”要比“整段重写”可靠得多。只要反馈信息足够精确，局部修复的成功率远高于整体重构。
5. 精读之后，我们能在自己的项目里怎么用
5.1 写 C++ 的人：把测试用例写在前，生成在后
读 OPL4GPT 的过程中，我一直在想怎么把这些经验转化成日常开发能用的方法。对 C++ 项目来说，最直接的收获是：别让 GPT-4o 先写实现，让它先写测试。
很多人用 ChatGPT 辅助写代码，习惯是“帮我用 C++ 实现一个冒泡排序”，拿到代码后简单看一眼就放进项目。但这篇论文的实验已经证明，编译通过不等于功能正确。更可靠的做法是，把需求描述成一组测试用例，例如“写一个排序函数，输入 {5, 3, 8, 1} 输出 {1, 3, 5, 8}”，然后让 GPT-4o 生成实现。如果它生成的代码无法通过断言，你再把失败信息直接反馈给它，模型能利用测试结果做修正。
这个流程其实就是把 OPL4GPT 的反馈循环用在日常开发里。你不需要搭一个自动验证框架，只要在 Prompt 里要求模型自己运行测试、总结失败原因，它就能自我改进。当然，最终代码仍需人工审查，但至少能把明显错误提前过滤掉。
5.2 写 Verilog 的人：Icarus Verilog 加 Testbench 就是最好的老师
硬件设计圈子使用大模型的比例比软件圈子低，很大一部分原因是反馈链路太长。很多人让 GPT-4o 生成一个 Verilog 模块，拿到 Vivado 里综合，报错后把英文错误信息复制粘贴给它，来回好几轮也不一定能跑通。问题不在于模型不行，而在于反馈信息太粗糙。
我在实践中发现，Icarus Verilog 加一个简单的 testbench，就能快速搭出 OPL4GPT 式反馈。操作步骤不复杂：用 iverilog 编译你的顶层模块和 testbench，然后用 vvp 跑仿真，把仿真输出的文本日志作为反馈信息拼进下一轮 Prompt。
举个例子，你想让 GPT-4o 写一个 I2C 读 EEPROM 的时序控制模块，那就先写好 testbench，比如在某个时刻模型应输出 SCL 下降沿，检测到 ACK 信号。仿真失败时，日志里会明确写出“t=100ns: scl 期望为 0，实际为 1”。把这个日志发给 GPT-4o，告诉它“根据仿真日志修复模块，保持其他部分不变”，它就能针对性地补时序状态。不需要复杂的算法，关键是把波形差异文本化，模型就能理解。
5.3 一个可以直接抄走的 Prompt 模板
最后分享一个我经过多次实验后觉得好用的 Prompt 模板。这个模板把 OPL4GPT 的反馈机制提炼成了一段可复用的自然语言指令，适用于 C++ 和 Verilog 两种代码生成场景：
你是一名严谨的 [C++/Verilog] 工程师。请根据以下要求实现代码。 任务描述： [在这里写清功能，如“实现一个 8 位计数器，支持同步复位和使能”] 接口要求： [在这里写清端口名和方向，如“输入 clk, rst_n, en；输出 reg [7:0] cnt”] 约束条件： [在这里写清关键限制，如“必须使用非阻塞赋值”“不得使用 initial 语句”“数组下标不得超过边界”] 请先输出完整代码，然后用自然语言分点解释你的设计思路。 如果后续我提供测试失败信息，你只能定位并修改与错误相关的局部代码， 不要重写整个模块，也不要改动未涉及的部分。这个模板好用的原因在于它强迫模型在动手前想清楚约束条件。很多失败案例里，模型不是不懂逻辑，而是自由发挥过度。你把约束条件说明白，它反而能收敛到正确答案。
在我自己的项目里，每次拿到模型代码，我都会先跑一遍测试或仿真，再把失败日志交给它修复。这套流程不复杂，但效果稳定。如果你手头正有个 C++ 小工具要写，或者有个 Verilog 模块要调试，我建议你直接试一下这个思路，应该会比反复“重新生成”高效得多。
