05. AI4Engineering: Why AI Cannot Yet Design

摘要

大语言模型能写诗、能生成代码、能上线完整的网站。在芯片和 PCB 这类"硬件工程"领域，AI 的表现也可圈可点。然而当我们转向建筑、桥梁、机械、水利等传统工程设计，AI 却举步维艰。这不只是反馈周期长或物理直觉缺失的问题——这些解释在芯片 AI 的成功面前都站不住脚。

本文认为，AI 在传统工程领域的无能，根源于前四篇所分析的同一病灶：as Code 基础设施的缺失，以及由此导致的质量保证体系的"左移"断层。软件和芯片拥有完整的可计算基础设施——文本优先的真理之源、可执行规格、分层自动验证——AI 因此在其中如鱼得水。而传统工程的设计意图被锁在 WYSIWYG 的耦合式 CAD 文件中，逻辑与几何不分，规格与实现缠绕。AI 被要求从最终渲染结果反向破译设计逻辑——这等同于让芯片 AI 直接分析 GDSII 版图的像素，而不是读取 Verilog 代码。

解决之道不是更强的模型，而是 EaC 基础设施的建成：分离关注点、定义可执行的设计描述语言、重建工具链。只有当工程具备了可计算的基础架构，AI 才拥有它真正需要的入场条件——不是更聪明的大脑，而是一张可以读写的棋盘。

1 一场不断被推翻的辩论

大语言模型能写诗、能生成代码、甚至能上线一个完整的网站。在芯片和 PCB 设计这类"硬件工程"领域，AI 的表现也可圈可点。然而，当我们转向更传统的工程设计——建筑、桥梁、机械、水利——AI 却显得举步维艰。

这究竟是为什么？

在过去的一段时间里，关于这个问题的辩论经历了一轮又一轮的推翻与重构。最初，解释似乎显而易见：

解释一：AI 不懂物理因果。 大模型做的是统计关联，它不理解一个构件的失效如何引发连锁坍塌，无法像工程师那样进行反事实推理。

但这个解释立刻被现实击碎：一个能在真实服务器上、通过编译测试、最终成功上线的 AI 智能体，怎么可能不懂因果？编程同样是物理实现——内存泄漏、竞态条件、延迟超标——每一条都是硬约束。AI 在代码中处理这些约束的能力已经被 SWE-Bench 反复验证。物理因果不是问题。

解释二：工程设计是硬约束求解。 材料强度、安全法规、防火间距——这些都是硬边界，而 AI 的概率生成天然与之相悖。

反驳同样精准：芯片设计难道不是硬约束？时序违例、DRC 规则、功耗预算——哪一个不是刚性边界？AI 在芯片设计中处理这些约束的成熟度，远高于传统工程。以"硬约束"为界划线，划不开。

解释三：隐性知识无法学习。 资深工程师的直觉和经验从未被文字记录——那个"这个焊缝看起来不对"的判断，那个"这里该多留 5mm"的经验，AI 无从学起。

这一论点的弱点是它假设了 AI 只能从文字中学习。事实上，AI 从围棋和代码中学会的"直觉"，同样不在任何教科书的文字里——它是从数百万次对弈和编译试错中涌现的。问题不在于隐性知识是否可学，而在于试错的反馈回路是否存在。而这，正是关键所在。

解释四：反馈闭环的时长差异。 软件可以秒级试错——写一行代码，跑一次测试，立即知道对错。而物理工程的验证可能需要数月、数年，甚至到建筑倒塌才知道。

这个解释看起来最强——直到有人指出：芯片设计同样是硬件，同样有长反馈周期和巨大失败成本。一次流片失败烧掉数千万美元、延误半年窗口期。然而 AI 在芯片设计中的表现仍然远好于传统工程。

于是辩论陷入僵局。每一次解释都在芯片的反例面前崩塌。真正的问题不是"为什么 AI 在传统工程中表现差"，而是"为什么芯片和传统工程，在面对 AI 时呈现出如此悬殊的差异"。

2 根本原因：质量左移的断层

在与多位工程师和研究者反复推演之后，一个根本性的洞见浮出水面：

芯片实现了 as Code，而机械、建筑、水利等传统工程领域没有。在这个基础上，芯片实现了质量保证的"左移"，传统工程则被锁死在最右侧。

什么叫"左移"（Shift Left）？简单说，就是将质量保证活动尽可能前置到设计的最早期。假如把整个设计质量保证（DQA）谱系从左到右罗列，我们会看到一条清晰的链条：

| 阶段 | 活动 | 反馈延迟 | 修复成本 | |------|------|----------|----------| | L0 语法检查 | 设计描述是否符合语法规范 | 毫秒 | 极低 | | L1 风格检查 | 命名规范、结构模式、最佳实践 | 毫秒 | 极低 | | L2 静态分析 | 未连接端口、死代码、引用完整性 | 秒 | 低 | | L3 几何校验 | 碰撞检查、净距检查、空间约束 | 秒-分钟 | 中 | | L4 多物理场仿真 | 结构、热、流体、电磁仿真 | 分钟-小时 | 高 | | L5 物理测试 | 原型样机、强化测试、灰度发布 | 天-月 | 极高 | | L6 售后与召回 | 现场失效、事故调查、召回 | 月-年 | 灾难 |

软件和芯片，因为拥有完整的"as Code"表示，可以把绝大多数质量活动压缩到谱系的极左端。你写完 Verilog，立马可以跑语法检查、形式验证、逻辑综合。你提交一行代码，静态分析、单元测试、集成测试自动触发。Bug 在成本最低的设计早期就被发现和修复。

而传统工程呢？由于缺少一个"可计算的设计描述"，谱系的前三项（L0-L2）几乎完全空白。没有代码，就没有语法；没有抽象语法树，就没有静态分析。设计审查只能靠人眼在图纸上找错，碰撞检查要到所有管线都画完才能进行。质量保证严重右移，甚至要等到施工或投产后才暴露问题。

这正是前四篇反复论证的 EaC 五项支柱的另一种表述 [1]。文本优先（Text First）是 L0-L2 的前提——只有开放文本才能被解析、检查和分析。可执行规格（Executable Specs）是 L3-L4 的前提——只有规格可以自动运行，验证才能从人肉审查变成 CI 流水线。Git 工作流和 CI/CD 是分层验证的组织载体——没有它们，左移只是个人行为，无法制度化。

汽车行业是一个特例。它凭借极为严格的流程和数字化样机，用巨量高素质工程师强行模拟出了一个接近"左移"的效果——但这套体系高度依赖人力和组织纪律，代价沉重。而且如前文所分析，当技术范式发生跃迁，这种过度垂直整合的模式本身就变成了负担 [3]。

更多的行业——非标自动化、工业工程、AEC（建筑、工程与施工）、纺织——则长期停滞在"质量右移"的泥潭里。不是它们不需要左移，而是它们从未建立起让左移成为可能的基础设施。

3 CAD 的 WYSIWYG 原罪

那么，是什么在阻碍传统工程领域建立 as Code 基础设施？

答案指向了 CAD 软件本身的范式：WYSIWYG（所见即所得）的耦合设计。

在芯片设计中，一个晶体管的逻辑模型（器件库/PDK）、符号（原理图）和物理版图（GDSII）是严格分离的三层。你可以只操作网表，而不必关心物理实现。这种解耦使得逻辑层的海量优化和验证成为可能——AI 在 Verilog 级别操作的是抽象符号和逻辑关系，这正是它的母语。

但在传统 CAD 里，这三层被耦合进了同一个三维几何模型。一个阀门的三维模型直接捆绑了它的所有几何、外观和接口信息。装配关系隐含在几何约束中——"这个面碰到那个面"——而不是作为一份清晰的"系统网表"独立存在。设计过程就是几何模型的堆砌过程。这种耦合，本质上将工程设计从逻辑问题降维成了几何绘图问题。

这对 AI 而言是灾难性的。大模型最擅长处理的是抽象符号、关系和逻辑——它在代码和数学推理中的卓越表现正是源于此。而面对一个高度耦合的、包含海量三角面片的单一 CAD 文件，AI 基本无能为力。我们要求 AI 去"看懂"一张建筑平面图，本质上是让它从最终渲染结果反向破译设计逻辑。

这等同于让芯片 AI 直接去分析 GDSII 版图的像素，而不是读取 Verilog 代码。没有人会神经质地要求芯片 AI 这样做——因为芯片产业已经在四十年前建立了解耦的、文本化的基础设施。而传统工程产业没有。

这个问题的另一个维度在前文关于 MBSE 的分析中已经出现：SysML 的"图优先文化"本质上也是同一种 WYSIWYG 病 [3]。当图形视图是工作的中心，文本沦为图形的序列化备份，那么 diff、merge、自动化验证就天然被排斥在外。AI 面对的不是可解析的声明，而是需要用视觉推理去理解的像素化图表。

4 AI 的真正入场条件

因此，AI 在传统工程领域表现不佳，不是因为它不够聪明，而是因为传统工程从未给 AI 提供它能消费的东西。

软件工程给了 AI 代码——结构化文本、明确的语法、可自动验证的正确性判据。AI 在代码上的能力已经证明了，只要输入是结构化的、可解析的、有自验证闭环的符号系统，大模型就可以在其中高效地学习、推理和创造。

芯片工程给了 AI Verilog 和 PDK——同样是结构化文本，加上一套分层的、可自动执行的规则引擎（DRC、LVS、时序签核）。AI 的成功不是因为它"懂了物理"，而是因为芯片产业早已将物理约束编码为了可计算的规则，AI 只需要在规则空间内搜索即可。

传统工程没有这些东西。AI 面对的是一堆 WYSIWYG 的几何模型、隐式的约束、散落在 Word 和 Excel 中的需求。它既没有可以解析的语法树，也没有可以运行的验证器，甚至连一个明确的设计状态表示都没有。

所以，让 AI 进入工程设计，需要的不是更强的模型，而是前四篇所论证的 EaC 基础设施。具体而言，至少需要三个步骤 [2]：

分离关注点。 强制将设计解耦为独立的器件库（参数化逻辑模型）、逻辑网表（系统连接关系）和可生成的三维版图。让设计可以只操作网表，而不必触碰具体几何。这正是半导体 PDK 的逻辑——代工厂不必知道设计意图，设计方不必亲手操作光刻机，只要严格遵循接口契约，两端便可自由创新。

定义可执行的设计描述语言。 像 Verilog 那样，形成一套可被机器解析、生成和分析的领域特定语言，作为唯一的设计真理之源。所有修改都在这个文本描述上进行，而非通过鼠标拖拽。图的生成是自动的投影，而非真理本身。

重建工具链。 所有分析、仿真、校验、成本估算工具，都直接消费这份设计描述，而不是消费一个专有的、耦合的 CAD 文件。从 L0 语法检查到 L4 多物理场仿真，整个 DQA 谱系被自动化流水线串联。

只有当这些基础设施建成，质量左移的完整谱系才会被激活。到那时，AI 才能像在软件和芯片领域那样，处理那 80% 本不该消耗人类创造性智慧的重复性智力工作——检查净高、验证防火间距、核算面积指标、检查接口兼容性。

5 人机分工的重新定义：谁验证、谁背书、谁承担代价

EaC 基础设施的建成，不仅是 AI 的入场券，更将根本性地重塑工程中的人机分工。

前文在分析 MBSE 的困境时，提出过一个尖锐的问题：当规格成为可执行的判据，"谁负责为这段规格背书，谁有能力验证它，谁又会为它的失效支付代价" [3]。在人肉治理模式下，这三个问题纠缠在一起——验证依赖人类专家，背书者与验证者常是同一群人，而追责因为证据链不完整而沦为推诿游戏。

EaC + AI 的组合将这三个角色拆开：

机器负责验证。 当设计描述和验证规则都是可执行的代码，L0-L4 的验证就不再依赖人类法官。每一次提交触发全链路的自动化检查，验证结果确定、可复现、可追溯。AI 在这个层面不是替代工程师的判断，而是在人类不可能覆盖的维度上实现规模化检查。

人类负责背书。 Sign-off 仍然是法律仪式，仍然由具有执业资格的工程师签发。但签核者的工作性质变了：过去他需要逐项审视设计是否合规（人肉编译器），现在他只需要审查 AI 的验证报告是否覆盖了正确的规则集和工况。人的价值从"验证"转向"判断什么值得验证"——从执行层上升到策略层。

证据链负责定责。 当设计描述、验证规则、签核记录全部以代码形式存储在 Git 中，任何失效都可以被精确追溯到：是规格定义错了吗？是验证规则没覆盖吗？是签核时忽略了警告吗？谁写的规则、谁跑的结果、谁点了 Accept——全部可查。这正是半导体 Sign-off 制度的核心逻辑：细粒度的可追溯性让追责从推诿游戏变成了证据确凿的定责 [2]。

这套分工模式下，工程师从"人肉编译器"的角色中解放，专注于真正需要创造力和权衡的那 20%——决策、策略、创新。而 AI 接管的是那 80% 的约束满足与合规检查——这些工作本质上不需要创造力，只需要对规则空间的系统化、无遗漏的搜索。人类做这些是浪费，AI 做这些是归位。

6 结论：EaC 是 AI 进入物理世界的先决条件

本文的分析指向一个看似激进、实则逻辑必然的结论：AI 在工程领域的上限，不由模型能力决定，而由领域的信息基础设施决定。

软件工程用四十年建成了这套基础设施——编程语言、编译器、类型系统、测试框架、CI/CD。所以 AI 进入软件工程时，它找到的是一张棋盘、一套规则、一个可以秒级试错的反馈回路。

芯片工程用三十年建成了类似的基础设施——Verilog、PDK、DRC/LVS、Sign-off 流程。所以 AI 进入芯片设计时，它面对的同样是结构化文本与可执行规则。

传统工程从未完成这一步。设计意图锁在专有 CAD 文件中，约束散落在 Word 和 Excel 里，验证依赖人眼和人脑。AI 被要求在没有棋盘的情况下下棋——这不是模型能不能的问题，而是游戏本身还没被定义。

"AI 还无法胜任工程设计"这个问题的真正答案，不是 AI 做不到，而是 工程从来就不是用 AI 能够理解的语言书写的。改变这一点的，不是 AI 技术的进步，而是 EaC 基础设施的建成。

而一旦这基础设施建成，故事就会翻开下一章：工程领域的高密度可验证约束，可能反过来成为 AI 能力突破的下一个燃料。那是下一篇要讨论的话题 [4]。

参考文献

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

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

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

[4] 《Engineering RLVR: How Verifiable Rewards Drive Engineering AI》，本系列第六篇（即出）。