Engineering AI：Physical Engineering 的下一次范式迁移 一、真正的问题不是让 AI 进入物理世界，而是让工程世界变得可执行 今天关于 AI 与物理世界的讨论，常常集中在 Physical AI、具身智能、机器人和自动驾驶上。这个方向当然重要，但它也天然困难：模型必须在实时控制环中处理传感器输入，理解动态环境，并直接输出动作。任何错误都会立即作用于真实世界。 然而，AI 进入物理世界可能还有另一条更现实、更可解释、也更容易产业落地的路径：不是让 AI 直接控制物理系统，而是让 AI 参与设计物理系统。 这就是我所说的 Engineering AI。 Engineering AI 不是在实时控制环内输出动作的 AI。它是在控制环之外，读取任务、约束、资源、工艺、供应链和验证结果，然后重新设计系统本身的 AI。它的输出不是一次动作，而是一个可制造、可验证、可交付的工程方案。 这一区别很关键。 具身智能问的是：在当前系统中，下一步应该怎么做？ Engineering AI 问的是：当前系统本身是否应该被重新设计？ 前者优化行为，后者重构行为发生的系统。 二、从控制论看，AI 至少有四种位置 我们可以用一个最小化的控制论框架来理解 AI 在系统中的位置： 世界产生状态，传感器读取状态，策略根据读数做出决策，执行器把决策施加回世界。 在这个框架里，过去十年的 AI 大致可以分为四类。 第一类是 感知 AI。它工作在传感器和策略之间，把原始读数转化为检测框、分割结果、识别标签或状态表征。它的本质是 sensor-to-representation。 第二类是 预测 AI，也就是世界模型。它根据当前状态和历史数据预测未来，为策略提供输入。它的本质是 state-to-future。 第三类是 on-line AI，或者具身智能。它处在实时控制环之内，直接吃进传感器输入或状态表征，吐出动作、轨迹或执行器参数。它的本质是 state-to-action。 第四类就是 Engineering AI。它不在实时控制环内，而是在环外读取任务、约束、资源、日志、传感器数据和系统状态，输出对整个系统的重构方案。它的本质是 specification-and-constraints-to-engineered-system。 因此，Engineering AI 不是 controller，而是 system architect。它不是控制器，而是控制系统的设计者。 三、Engineering AI 改变的不是动作，而是动作空间 理解 Engineering AI 的关键，是不要把 actuator 狭义地理解为某个机器人上的电机、关节或末端执行器。 在 physical engineering 中，一个系统能够执行什么动作，取决于更大的工程条件：当前工艺窗口、可用设备、材料、供应商能力、检测手段、法规边界和成本结构。换句话说，actuator space 本身是由工程能力和供应链能力定义的。 例如，一个零件原本可能需要五轴联动车床加工。传统的优化问题是在这个给定条件下寻找更好的刀路、更优的装夹、更短的加工时间。但 Engineering AI 可以提出另一种方案：修改零件结构，改用三轴机床，加一个特定夹具，减少装夹次数，降低设备租金，并完成同样的工程目标。 这不是在既定动作空间中选择动作，而是在重构动作空间本身。 所以，Engineering AI 的典型输出不是“下一步动作”，而可能是： 设备选择、工艺路线、零件重设计、夹具方案、装配顺序、供应商组合、检测流程、成本函数和验证计划。 这使它与一般的策略 AI 明显不同。策略 AI 默认动作空间已经给定；Engineering AI 则会改变什么动作是可用的。 四、Software Engineering 已经出现了 Engineering AI：SWE Agent Engineering AI 并不是纯粹的未来概念。它已经首先在 software engineering 中落地，典型形态就是 SWE Agent。 普通 coding assistant 的工作方式是 prompt-to-code snippet。用户提出需求，模型生成一段代码。 但 SWE Agent 的工作方式不同。它读取 issue，理解代码库，修改源代码，运行测试、lint、type check 和 CI，最后提交 patch 或 PR。它处理的不是孤立代码片段，而是一个真实软件系统。 这意味着 SWE Agent 改变的是系统本身：代码结构、接口、依赖、配置、测试和运行行为。 它之所以能成立，是因为软件工程天然拥有一套可执行工程基底： 代码库是可编辑对象，编译器和解释器是执行环境，测试和 CI 是 verifier，Git 是版本控制和回滚机制，issue 和 PR 是任务与交付边界。 因此，在软件工程中，Engineering AI 已经具备最低闭环： 需求进入代码库，agent 修改系统，verifier 检查结果，patch 被 review、merge 或 rollback。 这就是 Engineering AI 的基本形态。 五、IC 设计是 physical engineering 中最成熟的样板 在 physical engineering 中，目前最接近 full-stack Engineering AI 的领域是 IC 设计。 半导体设计之所以高度自动化，不只是因为 EDA 工具强，而是因为它拥有一整套把制造能力形式化、机器可读化、可验证化的工程堆栈。 PDK 封装了 foundry 的制造能力。DRC 定义了可制造性的规则边界。LVS 检查设计意图与物理实现的一致性。Timing、power、parasitic analysis 则完成性能闭合。EDA 工具在这些约束和验证器之内进行综合、布局、布线和优化。 也就是说，IC 设计拥有 Engineering AI 所需要的关键组件： 能力包、规则牌组、自动综合、验证闭合和最终交付边界。 这套结构非常重要。因为它说明 physical engineering 并不是不能被自动化，而是必须先被形式化。只有当制造能力、设计规则、验证逻辑和交付边界被编码进一个可执行工程环境中，AI 才能真正从“建议者”变成“工程师”。 六、大多数 physical engineering 仍然处于 pre-EDA 阶段 与 software engineering 和 IC design 相比，机械工程、航空工程、建筑工程、土木工程和工业装备设计仍然处于非常早期的状态。 这些领域当然已经数字化。它们有 CAD、CAE、CAM、PLM、BIM、仿真软件和项目管理系统。但大多数工作流仍然是 drawing-centric 的。 Drawing-centric 工程以图纸、模型和人工解释为中心。工程知识分散在图纸、规范、经验、供应商沟通、现场调整和人工审查之中。CAD 模型描述了几何结果，但未必完整表达设计意图、制造约束、使用约束、变更规则和验证逻辑。 这就是为什么简单把 LLM 接入 CAD，并不能自动产生 Engineering AI。 真正缺的不是一个更会画图的模型，而是一个类似 software repo / CI 或 IC EDA / PDK / DRC 的可执行工程基底。 更准确地说，大多数 physical engineering 领域不是 pre-AI，而是 pre-EDA。 它们缺少的是： 机器可读的工艺能力包，机器可读的供应链能力包，统一的设计规则语言，可组合的 verifier stack，可自动执行的工程综合器，以及从设计到采购、制造、施工和维护的闭环接口。 七、Physical Engineering 为什么可能成为下一个 major RLVR domain 这件事不只是产业自动化问题，也可能是模型训练问题。 今天 RLVR 最成功的领域主要是 game、math 和 coding。它们共同特点是：任务结果可以被验证，reward 可以相对低成本地产生。 Math 的 verifier 来自形式系统。Coding 的 verifier 来自编译器、测试和 CI。Game 的 verifier 来自规则引擎。 Physical engineering 其实也具有极高密度的 verifier，而且这些 verifier 更接近真实经济价值。 几何可以验证干涉、碰撞、装配、公差、最小壁厚和可达性。 物理可以验证强度、刚度、热、流体、电磁、振动和疲劳。 制造可以验证可加工性、可焊接性、可铸造性、可打印性和可施工性。 供应链可以验证材料可得性、设备可用性、MOQ、交期和报价。 法规可以验证防火、抗震、安全、环保和认证。 经济模型可以验证成本、工期、能耗、维护成本和生命周期表现。 这意味着 physical engineering 不是 verifier-poor，而是 verifier-rich。它拥有大量确定性或半确定性的检查机制，理论上可以为模型提供密集、稳定、可组合的训练信号。 更重要的是，physical engineering 的经济价值极大。它直接改变材料、能源、空间、设备、建筑、交通、制造和基础设施。它不是单纯的信息生产，而是真正增加社会物理生产力的领域。 因此，physical engineering 不只是 AI 的 deployment domain，也可能成为 AI 的 training domain。模型可以生成设计，运行 verifier，得到反馈，修改方案，搜索替代路径，优化系统，并在这个过程中学习工程先验。 这就是为什么 physical engineering 可能成为 game、math、coding 之后的下一个 major RLVR domain。 八、关键转变：从 drawing-centric 到 code-centric 要释放这一潜力，physical engineering 必须完成一次范式迁移：从 drawing-centric 转向 code-centric。 这里的 code-centric 并不是说所有工程师都要写传统意义上的程序代码，而是说工程对象本身必须变成可执行规范。 可执行规范不是普通文档，也不是静态图纸。它是一种机器可运行的工程对象，包含任务意图、参数化设计、约束条件、制造能力、使用场景、验证逻辑、供应链接口和变更规则。 在 drawing-centric 工作流中，许多约束是在制造时、施工时、装配时或使用时才暴露出来的。设计完成后才发现不能加工、不能装配、不能维修、不能审批，或者成本和交期不可接受。 在 code-centric 工作流中，这些约束应该前置到设计时。可加工性、装夹、刀具可达性、材料库存、供应商能力、交期、检测方式、维护可达性、疲劳寿命、能耗、安全和法规，都应该在设计生成过程中被持续检查。 这是一种工程领域的 shift-left verification。 不是等设计完成后再发现问题，而是在设计生成过程中持续闭合几何、物理、制造、供应链、法规和成本约束。 九、Engineering AI 的真正机会 所以，Engineering AI 的真正机会并不是把 LLM 包装成 CAD 插件，也不是让机器人直接在工厂里试错学习。 更大的机会是构建 physical engineering 的 EDA-like substrate。 这个 substrate 应该包括： 机器可读的 capability package，形式化的 rule deck，参数化和代码化的设计表示，可组合的 verifier stack，agent 可操作的工程工具链，以及从设计、仿真、采购、制造、施工到维护的闭环接口。 一旦这个 substrate 成立，Engineering AI 就可以像 SWE Agent 操作代码库一样操作工程系统，也可以像 EDA 工具在 PDK 和 DRC 约束内综合芯片一样，在物理工程约束内综合机械、建筑、航空和工业系统。 到那时，AI 不再只是给工程师建议，而是能够生成、验证、修改、比较和交付工程方案。 十、结论：Physical Engineering 是 verifier-rich but substrate-poor Software engineering 已经从 text-centric 走向 repo-centric、test-centric、CI-centric，因此 SWE Agent 成立。 IC design 已经从 drawing-centric 走向 EDA-centric、PDK-centric、verification-centric，因此 physical engineering 中的 full-stack automation 首先在那里成熟。 机械、航空、建筑、土木和工业装备设计如果要进入 Engineering AI 时代，也必须完成同样的转变：从图纸中心转向代码中心，从结果描述转向可执行规范，从事后验证转向设计时闭合。 Physical engineering 并不缺少 verifier，也不缺少经济价值。它缺少的是一个能让 AI agent 操作这些 verifier 的工程基底。 一句话概括： Physical engineering is verifier-rich but substrate-poor. 谁能构建这个 substrate，谁就可能把 physical engineering 变成 game、math、coding 之后的下一个 major RLVR domain，也把 Engineering AI 从软件和 IC 推向更广阔的物理世界。