06. Engineering4AI: Next Major Domain of RLVR

摘要

AlphaGo 赢在围棋，DeepSeek-R1 突破数学推理，Claude 在 SWE-Bench 上超越人类——这些里程碑背后是同一种驱动力：可验证奖励（Verifiable Reward）。Game → Math → Code → HWE。硬件工程（Hardware Engineering）是 RLVR 的下一个主战场。

不是因为它像代码，而是因为它的可验证约束密度比代码更高。围棋只有胜负一个二值信号，数学只有最终答案一个校验点，代码有编译和测试两三层反馈。而硬件工程——一旦 EaC 基础设施建成——将天然拥有双层奖励空间：L0-L6 分层验证漏斗确保“没错”（可行、合规、不故障），性能指标的连续极限追求提供方向（更轻、更快、更省、更强）。前者是安全网，后者是方向标——这种双层结构在大多数软件工程任务中不存在，却是物理工程的天然禀赋。

这正是前五篇的最终指向：EaC 不仅是工程治理的出路，更是 AI 能力突破的下一个引擎。工程为 AI 提供了它所见过的最密集、最分层的可验证奖励空间——而 AI，将在学会设计的过程中，学会创造。

1 RLVR：一条扩张的轨迹

RLVR（Reinforcement Learning from Verifiable Rewards）的核心思想极其简单：如果一个问题有客观的、可自动计算的正确性判定，模型就可以通过大规模试错来学会解决它——不需要人工标注，不需要人类偏好数据。

这个范式在过去十年间沿着一条清晰的路径扩张：

| 里程碑 | 领域 | 验证方式 | 反馈延迟 | | ------------------ | -------- | ----------------------------------- | --------- | | AlphaGo (2016) | 围棋 | 胜负规则（二值） | 终局 | | DeepSeek-R1 (2025) | 数学 | 最终答案正确性 | 秒级 | | Claude Code (2025) | 软件工程 | 编译 + 测试套件 | 秒-分钟 | | HWE（目标） | 硬件工程 | 分层规则引擎（L0-L6）+ 性能指标优化 | 毫秒-分钟 |

共同内核：可验证奖励是唯一燃料。哪个领域先建立起廉价、确定性、可自动计算的验证系统，哪个领域就能率先进入 RLVR 飞轮。

但这里有一个微妙的依赖关系。围棋的验证系统是游戏规则，与生俱来——你不需要先"建基础设施"才能下围棋。数学的验证是逻辑推导，同样天然存在。软件工程的验证系统是四十年积累的产物——编译器、类型系统、测试框架、CI/CD——不是天然存在的，而是被人类主动建设的。这正是前文所述的五项支柱 [1] 和软件工程四十年的自我编码之路 [2] 的最终结晶。但并非所有可验证领域都值得 RLVR 进入。这里有一个关键的区分：Major Domain 与 Trivial Domain。

Major Domain 满足三个条件：

约束密集且刚性：不止一两个可验证维度，而是分层、多维、系统性的约束网络。Coding 有编译 + 静态分析 + 单元测试 + 集成测试 + 类型检查 + 覆盖率。硬件工程有 L0-L6 分层规则引擎。围棋虽然只有一个胜负信号，但它的状态空间复杂度使得每一步都隐含着海量的约束推理。
人类试错成本极高：在 Major Domain 中，专家的一次错误可能代价惨重——芯片流片失败烧掉数千万美元，桥梁设计失误导致结构失效，一次上线事故影响数百万用户。RLVR 的百万次并行试错在这些领域产生了人类无法比拟的杠杆效应：人类输不起一百万次，机器可以。
经济杠杆显著：性能的边际改善带来巨大的结构收益。燃油效率提升 1%，三十年节省数亿美元。功耗降低 10%，数据中心运营成本产生阶跃式变化。RLVR 的投入在这些领域有明确的 ROI 锚点。

Trivial Domain 则不同。它们也有可验证的维度，但三条件至少缺其二：

Data Analysis：写错一个 SQL——重跑就行。分析方向不对——换个角度试。可验证（结果是否一致），但人类试错成本极低，RLVR 的百万次训练投入远超十个人类分析师一年的试错成本。
Growth Hack / SEO：A/B 测试有可验证的转化率差异，但约束稀疏（只有少数几个漏斗指标），反馈周期以天或周计，且每一次试错都在真实用户上操作——你敢让 RLVR 在百万用户的首页上随机试错吗？
Chatbot / Office RPA：Excel 自动化、邮件模板、客服机器人。可验证（任务是否完成），但任务本身多样到无法收敛——每一个用户的 Excel 表都不同，每一个场景都需要新的理解。RLVR 学的是模式，而不是每次重新推理一个全新的表格布局。
共同特征：这些领域的正确性判据要么过于简单（一两个二值信号），要么过于多变（任务定义本身不收敛），要么人类自己做的成本已经够低——RLVR 的杠杆效应无法覆盖训练成本。

Major vs Trivial 的分水岭不是"有没有可验证奖励"，而是"可验证奖励是否构成了一个足够密集、足够刚性、人类试错成本足够高的结构"。前者是入场券，后者是价值锚。Game → Math → Code → HWE 这条路径上的每一步都是 Major——不是因为巧合，而是因为 RLVR 的扩张逻辑天然筛选出了这些领域。

硬件工程处于一个更极端的位置：它的验证能力天然高于软件（因为物理约束更刚性、边界条件更明确），但它的验证基础设施却远远落后于软件。半导体产业用三十年建成了 PDK 和 Sign-off 体系，证明了"硬件 as Code + 自动验证"的可行性 [3]。但其他硬件工程领域——机械、建筑、航空系统——仍然把验证锁在人脑和人眼里。

所以，Engineering RLVR 的命题包含两个层次：第一，工程领域天然拥有比代码更密集的可验证约束；第二，这些约束今天没有被暴露给 AI，只因为 EaC 基础设施尚未建成。

2 两条"捷径"的诱惑与陷阱

在讨论如何建成这套基础设施之前，必须先回应两个正吸引着大量投资和注意力的路径。它们看起来更简单、更符合直觉——让 AI 去适应现有工具，而不是重建工具链。但它们的"简单"只是表面的。

2.1 路径 A：CUA（Computer-Using Agent）范式

主张："让 AI 像人一样操作 CAD 软件。打开界面、点击按钮、拖拽构件、运行碰撞检查。不需要改变任何现有工具链。"

这条路径在工程领域面临三个致命问题。

像素级操作的脆弱性。 人类操作 CAD 是一系列像素坐标的序列。一个对话框位置偏移几个像素、UI 版本更新改变了菜单层级、屏幕分辨率不同——任何一个变量都会导致操作失败。这不是理论推演，而是所有基于 GUI 自动化的项目都会撞上的墙。

验证信号的缺失。 CUA 模式下，Agent 无法直接读取"设计状态"。它操作的是像素，接收的是像素。要知道是否违反防火间距，它要么截图后再调用 VLM 判断，要么在菜单深处运行一个检查命令再解析结果。反馈延迟从毫秒退化为秒到分钟，反馈质量从确定性退化为概率性。

无法规模化试错。 RLVR 的核心是百万次级别的并行试错。CUA 模式下一个 Agent 实例需要独占一个 CAD 许可证和一个 GUI 会话。你无法在一台服务器上并行运行 1000 个 Agent 同时学习设计。

CUA 可能在极少数场景有用——例如操作一个无法被任何 API 访问的遗留软件做数据迁移。但作为工程设计自动化的底层范式，它是死胡同。

2.2 路径 B：CAD MCP 范式

主张："在 CAD 软件上封装一层 MCP（Model Context Protocol）Server，暴露结构化的工具接口。Agent 通过文本协议调用接口，完成建模和检查操作。"

这比 CUA 进了一步——至少 Agent 是在操作结构化工具而非像素。但它仍然保留了旧范式的根本缺陷。

MCP Server 绑定于专有 CAD 内核。 Agent 的操作能力受限于该 CAD 软件的 API 能力。如果 Revit 的 API 没有暴露"遍历所有防火分区的逻辑边界"，MCP 就无法提供这个工具。而大多数工程 CAD 的 API 都是为自动出图和批处理设计的，从未被设计为 AI Agent 的操作面。

逻辑与几何仍然耦合。 MCP 操作的底层仍然是一个 BREP 几何模型。Agent 修改了一个 Part 的参数，它必须等待 CAD 内核重建几何、刷新约束、检查冲突。这与直接操作声明式文本在效率上存在数量级差距。

最致命的：它回避了"真理之源"的问题。 在 CAD MCP 模式下，真理之源仍然是那个专有的 CAD 文件——前文所批判的 WYSIWYG 耦合体 [5]。MCP 只是在上面盖了一层 API 薄纱。它没有解决不同专业、不同工具之间如何共享一份无歧义的设计描述。它没有带来 diff，没有带来 merge，没有带来可追溯的变更历史，没有带来可自动运行的验证——EaC 五项支柱的核心，MCP 一条都没有提供 [1]。

2.3 正确的方向：文本原生、声明式、分离真理之源

CUA 和 CAD MCP 的共同假设是：以现有 CAD 工具为中心，让 AI 去适应它们。

EaC 的主张恰恰相反：以可计算的工程描述为中心，让工具来适应它。

文本原生。 Agent 直接读写结构化声明——如同它读写代码。这是它的母语，不需要视觉理解、GUI 交互或 API 桥接。

分离真理之源。 器件库、逻辑网表和可生成的版图三层严格解耦。Agent 操作的是逻辑层——这正是大模型最擅长的抽象符号空间。版图是自动生成的投影，而非真理本身。

分层验证。 从 L0 语法检查到 L4 多物理场仿真，整个 DQA 谱系直接消费文本化的工程描述。AI 的每一次输出都立刻获得确定性的反馈——通过或失败，以及为什么。这正是 RLVR 所需要的燃料。

CUA 和 CAD MCP 提供的是一条看似更快的捷径，但它的终点没有 RLVR 飞轮——因为在这条路上，验证信号始终是不确定、高延迟、无法规模的。真正的突破在于接受必须重建基础设施的事实。

2.4 AI Lab 为什么错判了 HWE

有了 Major vs Trivial 的框架，就可以理解一个看似矛盾的现象：当前 AI Lab 的主流叙事几乎完全绕过了硬件工程。

过去一年，AI 产业的投资和注意力高度集中于 Office RPA——用 AI 操作 Excel、写邮件、生成 PPT、当 Chatbot。这些领域的共同特征是：门槛低、场景多、演示效果好。一个能自动填表的 Agent 比一个能设计机柜的 Agent 更好卖——不是因为前者的经济价值更高，而是因为前者不需要任何基础设施建设，今天的模型 + 今天的工具就能跑。

但这种叙事暗含了一个危险的假设：它把"今天 AI 能做什么"等同于"AI 值得做什么"。用 Major vs Trivial 的框架审视，Office RPA 恰恰是 Trivial 的——它的任务多样性导致 RLVR 无法收敛，每一个用户的 Excel 表都需要重新推理，人类自己做的成本已经够低。AI Lab 看似在攻城略地，实际上是在 ROI 最低的战线上消耗资源。

反观 HWE。它的约束密度、错误成本、性能杠杆，每一项都是 Major 级别的——但它被 AI 产业视为边缘领域。原因不是它的价值低，而是它的门槛高：硬件工程今天的 WYSIWYG 基础设施 [5] 让 AI 无法入场。AI Lab 不是在 Major 和 Trivial 之间选择了后者——它们是在"今天能进的 Trivial"和"今天进不去的 Major"之间做出了务实的商业决策。

这正是工程领域需要清醒认识的现实：AI 不会主动来敲工程的门。 它会在门槛最低的 Trivial Domain 里耗尽投资周期的注意力，直到那些领域的 ROI 塌陷。到那时，如果 EaC 基础设施还没有建成，HWE 仍然会是那个 "进不去"的领域——不是因为不值得，而是因为门没开。

因此，工程领域与 AI 的互动必须是一个主动的姿态：不是等待 AI 来赋能，而是主动建成 EaC 基础设施，让 HWE 成为一个 AI 无法忽视的 Major Domain。前五篇所论述的文本优先、可执行规格、分层验证漏斗——每一项都是为这个目标服务的。当 L0-L6 的分层规则引擎就位，当设计意图以 AI 可直接消费的声明式文本存在，HWE 将从"进不去的领域"变成"下一片疆土"。

3 Engineering RLVR 的飞轮

当 EaC 基础设施到位后，会发生什么？

设想这样一个循环：

Benchmark 定义任务和评分
        ↓
Agent 在 Benchmark 上训练
        ↓
Agent 产出更好的设计
        ↓
发现新的失效模式
        ↓
失效沉淀为规则 / 约束
        ↓
约束库让 Benchmark 更难
        ↓
Agent 必须更强才能通过
        ↓
      （循环）

这是一个自我强化的飞轮。每一次失败都让约束库更完善；每一条新规则都让 Benchmark 更有区分度；每一次 Agent 能力的提升都让工程自动化更近一步。

这个飞轮的威力在于它的不对称性：人类工程师需要数年才能积累的"经验"——那些"这里不该这样设计"的教训——在 RLVR 飞轮中被压缩为小时级的迭代。每一条失败的验证报告都直接转化为训练信号，而训练信号又驱动模型在下一次尝试中避开这个坑。

更深远的是，工程领域的约束密度天然高于纯软件。软件测试的覆盖率永远不完整——你无法穷举所有输入——而工程约束中的很多维度是确定性的：防火间距要么满足要么不满足，功率预算要么超标要么不超标，接口要么兼容要么不兼容。这种刚性带来了一个反直觉的优势：RLVR 在工程领域的收敛速度可能比在软件领域更快，因为每一条规则都是硬边界，不会因测试采样的不足而漏过错误。

这正是 Engineering4AI 的核心论点：工程不仅是 RLVR 的受益者，更是 RLVR 的下一个突破性战场。它为 AI 提供了比代码更密集、更确定的奖励信号。

但这只讲了故事的一半。L0-L6 验证层解决的是“设计是否可行”——它确保方案不犯规、不故障、可运行。而工程真正的魅力，在于连续极限指标上的突破：更轻、更快、更省、更强。一架客机的燃油效率每提升 1%，三十年生命周期内节省数亿美元。一颗芯片的功耗每降低 10%，数据中心的 PUE 和运营成本产生结构性改善。这种极限追求在大多数软件工程任务中不存在——一个 CRUD 应用的性能优化通常止步于“够用”，没有天然的经济驱动力去逼近物理极限。但物理工程有。

因此，工程领域的 RLVR 奖励空间是双层的：

验证层（安全网）：L0-L6 确定性规则，保证输出不违规；
性能层（方向标）：连续指标的多目标帕累托优化，驱动输出逼近极限。

验证层提供二值奖励（通过/失败），性能层提供连续奖励（更好/更差）。前者是 RLVR 的燃料，后者是 RLVR 的导航。两者的叠加，让工程成为比纯代码更丰富、更立体的 AI 训练场。

4 SD-HWE-Bench：第一个原型

SD-HWE-Bench 是这一范式的第一个原型。它验证了一个基本命题：用分层规则引擎替代测试套件，可以在没有运行时的工程设计任务上实现确定性的自动评分。

4.1 分层验证引擎

SD-HWE-Bench 的评分系统由六层规则组成，每一层对应 RLVR 的一个奖励信号层级：

| 层级 | 检查内容 | 反馈延迟 | 确定性 | | --------------------- | ---------------------------- | -------- | ------ | | L0 Schema | 结构正确性、字段类型、必填项 | 毫秒 | 确定 | | L1 Reference | 引用完整性、跨表链接 | 毫秒 | 确定 | | L2 Business Rule | 功率预算、U 位碰撞、制冷容量 | 秒 | 确定 | | L3 Port Compatibility | 接口兼容性、协议匹配 | 秒 | 确定 | | L4 Power Budget | 功耗预算、相位平衡 | 秒 | 确定 | | L5a Deliverable | 输出物生成（BOM、报表等） | 秒 | 确定 |

关键特征：每一层都是确定性检查，不存在"概率性正确"。输出要么通过 schema 验证，要么不通过。功率预算要么在范围内，要么不在。接口要么匹配，要么不匹配。这与软件测试的样本依赖形成鲜明对比——RLVR 的奖励信号在工程领域可以做到无歧义。

4.2 任务矩阵

SD-HWE-Bench 设计了五类典型工程推理任务：

| 任务类型 | 考察能力 | 难度 | | -------------------- | ---------------------------- | ------ | | instance-declaration | 型号选择、参数赋值、属性推导 | Easy | | layout-design | 离散/连续空间分配、约束满足 | Easy | | connection-design | 接口兼容匹配、拓扑推理 | Medium | | mating-design | 机械约束匹配、耦合类型选择 | Medium | | comprehensive | 全链路协调、多约束并行满足 | Hard |

每类任务有三档难度：L1 直接（需求给出具体参数）→ L2 推理（需求给约束条件）→ L3 规划（需求只给高层目标）。

4.3 基线数据揭示的真相

在五个核心任务上的基线测试显示了一个清晰的结果：即使最强大的通用模型，在结构化工程设计任务上也存在根本性的能力缺口。

三个顶级模型在 SD-HWE-Bench 上的 Pass@1（overall_score ≥ 0.6）均未超过 20%，平均得分在 43%-64% 之间。更值得注意的是失败模式：模型在规则校验层面（L1-L4）表现出了一定的推理能力——功率预算正确、U 位碰撞检查通过、接口兼容性判断准确——但无法生成符合 schema 的 BOM CSV、power budget 表等结构化交付物。它们在"理解需求并进行逻辑推理"上过关，在"按格式交付工程产物"上失败。

这正是前文诊断的具象化：交付物生成成为瓶颈，不是因为模型不聪明，而是因为工程基础设施尚未建成。 一个 Schema 检查就是 L0 验证的一个实例。在今天，这层检查由 benchmark 的评分脚本执行；在 EaC 充分建成的未来，它将像编程语言的类型检查一样，成为 Agent 的第一道自检关卡。

4.4 从原型到生态

SD-HWE-Bench 的分层验证设计直接服务于 RLVR 训练——六层规则对应六个课程学习阶段，反馈在秒级以内，奖励是确定性的，失败原因可解释。它的领域扩展路线清晰：从电信/数据中心到机械、暖通、建筑，每一个新领域贡献的是同一套范式下的新约束库。

但 SD-HWE-Bench 的价值不止于一个基准数据集。它是一次存在性证明：在尚无完整 EaC 基础设施的条件下，用规则引擎模拟了 DQA 漏斗的 L0-L5a 层，证明了分层确定性评分在工程设计上是可行的。它为前五篇所论述的 EaC 范式提供了一个可操作的原型——不是理论宣言，而是一组可以跑的测试、可以见的结果、可以迭代的飞轮齿轮。

5 人机分工的最终确认

当 RLVR 飞轮开始转动，工程领域的人机分工将被根本性地重塑。这将把我们带回前文提出的那个尖锐问题：当规格成为可执行的判据，"谁负责为这段规格背书，谁有能力验证它，谁又会为它的失效支付代价" [4]。

在 EaC + RLVR 的组合下，这三个角色的分配变得清晰：

机器负责验证。 L0-L5a 的分层规则引擎提供确定性、毫秒-秒级的反馈。每一次 Agent 输出都自动触发全链路检查。验证不再依赖人类注意力，而是被编码为可复现的代码——这正是前文所述的"可执行规格"与"分层验证漏斗"的组合 [1]。

人类负责背书与策略。 Sign-off 仍然是法律仪式，仍然由具有执业资格的工程师签发。但签核者的工作从逐项审查变成了策略判断：验证规则集是否覆盖了正确的风险场景？哪些边缘工况需要额外的高保真仿真？低概率高后果的失效模式是否被规则引擎遗漏？人类的价值上移——从验证执行者变成验证策略制定者。

证据链负责定责。 设计描述、验证规则、签核记录全部以代码形式存储。任何失效都可以被精确追溯——这是半导体 Sign-off 制度的核心逻辑 [3]，现在被推广到更广泛的工程领域。

这种分工意味着，AI 不是替代工程师，而是将工程师从"人肉编译器"的角色中解放出来，让他们专注于真正需要人类判断力和创造力的决策层。而那 80% 的重复性合规检查——本就不该消耗人类智力的工作——被交给了机器。

6 结论：Engineering4AI

本文的论证可以归结为一个简洁的命题：工程不仅是 RLVR 的受益者，更是 RLVR 的下一个突破性战场。

Game → Math → Code → HWE。这条路径不是预测，而是对 RLVR 方法论自然延伸的推断。每一个成功扩张的领域都满足两个条件：约束与质量天然高相关，验证廉价且确定性。硬件工程完美满足这两个条件——它只是缺少把约束暴露出来的基础设施。

CUA 和 CAD MCP 提供了看似更快的捷径，但它们保留了旧范式的所有技术债务——模糊的验证信号、高延迟的反馈、无法规模的试错。真正的突破在于接受"必须重建基础设施"这一事实，并一步一步地去建设它。

当 EaC 基础设施建成，工程领域的双层奖励空间——L0-L6 验证安全网 + 性能极限方向标——将成为 AI 从未见过的丰富训练场：比围棋更结构化，比数学更多样，比代码拥有更立体的优化维度。这就是 Engineering4AI：不是让 AI 去适应旧工程，而是让新工程成为 AI 能力突破的燃料。

前五篇为这个未来准备好了语言、生态和协作平台。本篇所描绘的，是这一切最终服务的那个目标：让 AI 在工程领域，学会创造。

参考文献

[1] 《Engineering as Code: a General Method to Manage Complexity》，本系列第一篇。

[2] 《Software as Code: the First Prototype》，本系列第二篇。

[3] 《Silicon as Code: the Oligarchs' Waltz》，本系列第三篇。

[4] 《MBSE: the Unfinished Journey》，本系列第四篇。

[5] 《AI4Engineering: Why AI Cannot Yet Design》，本系列第五篇。