01. Engineering as Code: a General Method to Manage Complexity

摘要

现代工程系统正面临着前所未有的复杂性挑战：晶体管数量逼近千亿，汽车零部件超过三万，建筑构件动辄百万。传统工程方法基于静态文档、专有格式、人工审查与分批验证，已难以应对这种复杂度的指数增长。与此同时，软件工程在过去四十年间逐步发展出一套以开放文本为源、可执行规格、版本化协作、自动化验证与持续交付为核心的方法体系，成功实现了自身的“as Code”。本文提出“工程即代码”（Engineering as Code, EaC）这一通用治理范式，旨在将软件工程的成熟实践以领域适配的方式迁移至硬件、结构、电子、建造等一切人造物工程中。我们首先廓清 EaC 的概念边界与核心内涵，分析其背后的驱动力，再系统阐述五项核心实践：文本优先（Text First）、可执行规格（Executable Specs）、Git 工作流（Git Workflow）、全频谱分层验证（Shift-left + Shift-right）以及基于事件的自动化管道（CI/CD）。最后，本文探讨 EaC 在非软件领域落地的关键挑战与可能的突破路径。我们认为，EaC 不仅是工具升级，更是一场工程理性的版本进化——它将工程知识从私人经验与黑箱格式中解放出来，变为可计算、可协作、可积累的公共文本，从而为复杂性治理提供一条可操作、可扩展且可持续的路线。关键词：工程即代码；复杂性治理；可执行规格；持续集成；文本化工程

1 引言：复杂性危机与软件的启示

现代工程产品的复杂度正以超线性的速度攀升。一颗先进 SoC 上的晶体管数量已超过 1000 亿，一架商用客机的零部件数以百万计，智慧城市的感知与控制节点更是分布于云端、边缘与物理空间的每个角落。传统的工程治理手段——以二维图纸、技术规范和里程碑评审为主要工具——依赖于人类专家的认知负荷和高成本的物理或半物理验证。当系统的构件数量越过某个阈值后，这种“手工”治理方式便不可避免地产生大量的集成错误、设计迭代延迟以及跨学科的翻译损耗。一份来自航空航天领域的研究显示，约有 30%–50% 的工程返工直接源于跨专业接口的信息错位与规格模糊。具有讽刺意味的是，工程师在制造这些复杂产品时大量依赖软件工具（CAD、CAE、EDA、PLM），但工具本身并未解决工程知识的治理问题：设计意图以专有二进制格式存储，无法轻易版本化与 diff；需求以自然语言文档传递，无法自动验证；跨域接口的约束散落在 Excel 表或电子邮件中，无法与设计资产实时联动。工程知识的“原罪”在于它被锁定在非文本、非可计算的媒介中，从而退化为不可追问的沉默文档。与之形成鲜明对照的是软件工程本身。自 20 世纪 50 年代的汇编语言，经高级语言、操作系统、协议栈、自动化构建、版本控制、测试驱动开发、持续集成、基础设施即代码，直至容器化与 AI 辅助编程，软件工程以惊人的自反性将“构建软件”这一全过程吸收进了开放的文本体系之中。今天的软件系统完全可追溯：从需求（Issue/用户故事）到代码提交（commit），到自动化测试（CI 流水线），再到部署（IaC）和监控（可观测性声明），每一个环节都被编码为可计算、可 diff、可审查的纯文本或结构化文本。这一演进不是偶然的，而是软件领域持续对抗复杂性的必然结果。如今，将这种“通过文本和自动化治理工程”的范式向物理工程领域推广的条件已经成熟，这便是“工程即代码”（EaC）提出的历史节点与逻辑原点。

2 概念界定：何谓“工程即代码”

2.1 工程即理性的造物行为

本文所称的“工程”（Engineering）取其最原初的意义：人类以理性与科学原理为指导，设计并制造人造物的系统性活动。它涵盖集成电路、电子系统、机械结构、建筑、船舶、车辆、消费电子乃至生物工程等一切需要多学科协同、受到物理法则与资源约束的创造过程。工程的本质是在限制条件下追求功能与性能的最优解，因此天然是一个信息密集、决策密集的活动。

2.2 代码作为规范、可计算、简洁的文本

“代码”（Code）在这一语境中并非泛指二进制程序或汇编语言，而特指具有以下属性的文本表达：

规范性：遵循确定的语法和语义规则，可被机器解析和推理；
可计算性：可通过解释器、编译器或虚拟器执行，产生确定的行为或结果；
简洁性：善于通过抽象、命名和结构化来管理细节，从而实现人类可读与机器可执行之间的平衡；
开放性：以纯文本或开放标准格式存在，能够被通用的 diff、merge、lint、搜索等工具直接处理。

因此，EaC 中的“Code”并不仅仅是传统意义上的程序代码，而是所有能够满足上述要求的工程资产文本：包括设计意图的声明式描述、参数化几何生成脚本、电路网表文本、测试用例、需求断言、构建与仿真流水线定义，乃至材料属性和制造规则的编码。

2.3 EaC 的非均匀现状

工程即代码的实现程度在领域间极度不均衡。集成电路设计由于 EDA 工具链的成熟早已实现“as Code”：系统行为以 Verilog/VHDL 文本描述，逻辑综合、布局布线、时序验证均通过 Tcl/Python 脚本驱动，回归测试和持续集成也逐渐被头部企业采用。软件工程本身则是 EaC 最彻底的原型。电子工程（PCB 级）紧随其后，而机械工程、土木建筑、船舶工程等则长期受困于图形化、专有格式和刚性分工，目前仅有碎片化的探索（如 OpenSCAD、CadQuery 用于机械、Grasshopper 用于建筑、SysML v2 的文本语法用于系统工程）。这种不均匀性恰恰说明，EaC 的主要障碍并非领域的物理本质不同，而是工具链、行业标准与工程文化的滞后。

3 驱动力：为何复杂性治理需要 EaC

推动 EaC 从软件领域向泛工程领域迁移的，是一组长期且持续加强的结构性力量。

复杂性持续超线增长。摩尔定律放缓并未阻止晶体管集成度的提升，只是驱动力从单纯的特征尺寸缩小转向了三维堆叠、异构集成和芯片级的系统整合（SoC→SiP）。在机电产品中，电动化、智能化和网联化使得软件代码量暴增，同时硬件构件的交互关系变得极度复杂。人类的认知带宽与组织协调能力存在刚性上限，而 EaC 正是通过自动化推理和分层抽象来突破这一上限。
“系统抽象税”的时代性爆发。当材料和工艺进步放缓（例如硅基半导体的功耗墙、结构材料的比刚度极限），产品的竞争力更多来源于系统级优化，即打破传统的“黑箱”学科边界，进行跨域协同设计（如 DTCO，设计技术协同优化）。然而，每打破一次黑箱，跨域接口的翻译和一致性维护成本就急剧上升，这被称为“抽象税”。只有通过统一的、可执行的接口契约和自动验证管道，才能在不牺牲学科深度的前提下将抽象税降至最低。
错误修复的经济学威压。工程错误发现得越晚，修复代价呈指数级上升。在芯片设计中，一个前期 RTL 逻辑错误在流片后修复的成本可能高达百万美元。在土建工程中，设计阶段未被发现的碰撞问题可能在施工中造成数周延误。因此，将检测左移（shift-left）同时保留右移（shift-right）的深度验证，以实现全频谱的经济最优，成为刚需。EaC 的分层自动化验证漏斗正是为此而生。
支持条件的全面成熟。软件工程为人类贡献了一套经过千锤百炼的协作与自动化基础设施：Git 工作流、TDD/BDD、IaC、CI/CD、代码审查、可追溯性等。与此同时，具备跨学科知识且擅长编码的人才逐渐增多，更重要的是，大型语言模型（LLM）与 AI Agent 的崛起正在快速消解“写工程脚本”的技能门槛，使得领域专家可以用自然语言驱动代码生成，甚至直接参与自动化管道的建设。

4 核心实践：EaC 的五项支柱

EaC 绝非将软件工具生硬地套用到硬件上，而是提取软件工程中应对复杂性的基本原则，并结合物理工程的特点重新实例化。我们提炼出以下五项核心实践，它们共同构成一个相互强化的治理环。

4.1 文本优先（Text First）：以开放文本为唯一真源

原则：所有设计意图、需求、接口、约束、逻辑，都必须以开放、可解析、可 diff 的文本格式作为第一存储形态。专有二进制文件可以是下游生成的产物（如网格、光绘文件、渲染图），但不能作为唯一真源或权威存储。领域映射：在机械设计中，这意味着设计模型由参数化脚本（如 OpenSCAD、CadQuery）或特征树描述文件控制，而不是靠鼠标操作生成的二进制折线体。在 PCB 设计中，意味着原理图的连接逻辑、布局约束应以结构化文本（如 YAML/JSON 或特定 DSL）表达，并通过脚本生成网表。治理价值：文本第一消除了“格式税”，使得对设计变更的历史追溯、差异比较、自动检查和跨工具链流转成为可能。它迫使工程知识从隐式（工程师的肌肉记忆）变为显式（可阅读的代码），从而能被团队、组织和 AI 继承与改进。

4.2 可执行规格（Executable Specs）：需求即激励，规格即判据

原则：需求不应再是静态的 Word 文档或条目列表，而应转化为可自动执行的“激励-响应”断言。每一个关键功能或特性，都有一套对应的测试脚本：给定确定的输入激励（加载、信号、温度廓线），系统的行为必须落在预设的响应区间内（如变形小于 0.5mm，信噪比高于某阈值，延迟不超过规定周期）。只有物理或仿真的结果落在区间内，规格才算被满足。领域映射：电路模块的规格可以是 SPICE 仿真上的眼图张开口测试；结构件的规格可以是 FEM 脚本中自动提取最大应力并与许用值比较的断言；协议接口的规格可以是 TLA+ 或 SystemVerilog 断言。治理价值：可执行规格实现了“规格即判据”（Spec as Judge），根除了传统开发中“规格过时而设计已变”的脱节。每一项设计变更都会自动触发规格验证，合格与否立即可见。需求因此从“冻结的纸张”变为“活着的测试”，成为设计迭代过程中的连续反馈信号。

4.3 Git 工作流（Git Workflow）：用软件协作范式治理一切资产

原则：将软件协作的成熟范式——仓库（Repo）、分支（Branch）、提交（Commit）、合并请求（PR/MR）、代码所有者（CodeOwner）、标签（Tag）——完整地应用于所有工程资产和流程。仓库：每一个项目建立单一可信源仓库，收纳所有文本化工程资产（脚本、参数文件、测试用例、管道定义、规格建模等）。分支与合并请求：任何新的功能研究、变体尝试、问题修复都在独立分支中进行，通过 PR/MR 进行同行审查和自动化验证，通过后合并至主干。 CodeOwner：利用文件路径匹配规则模拟专业审批（如所有 .fem 文件需结构工程师审核），让审查流程自动化、可追溯。里程碑标签：设计冻结、工艺冻结、试制、量产等关键节点通过 Git Tag 固化，确保任何历史版本可随时检出复现。领域映射：机械工程师不再靠“在邮件里传来传去的_step 文件”沟通，而是通过克隆仓库、创建分支、提交参数修改、发起合并请求来完成设计变更。工程师的审查意见直接留在 diff 界面（例如，几何参数的改动是否会导致装配干涉）。治理价值： Git 工作流为工程活动建立了精确的技术记忆和社交合约。它解决了三个核心问题：（1）谁在何时基于什么原因改了什么；（2）如何在不破坏主线稳定性的前提下大胆尝试；（3）如何让自动化检查（lint、仿真）前置到变更正式合并之前。

4.4 全频谱分层验证（Shift-left + Shift-right）

原则：构建一个从廉价到昂贵的分层验证漏斗，使得错误在其生命周期的尽可能早期被捕捉，同时不牺牲深度物理保真度。左移（Shift-left）：在设计的最初阶段，用极低成本、极高速的方式拦截错误。包括：风格检查与命名规范、语法校验、数据完整性检查、公差累积的快速线性分析、DFM/DFA/DFT 等规则的脚本化审核、接口兼容性的类型检查。右移（Shift-right）：保留高保真的深度验证，包括多体动力学、非线性 FEM、CFD、电磁全波仿真、硬件在环（HIL）、虚拟集成平台（VIL）等。这些验证在触发时机上做严格控制（如仅在 PR 合并后或 Nightly 构建中运行），且必须脚本化、可复现。豁免管理：所有验证规则的豁免（例如某条 DFM 规则因产品特性不适用）必须通过代码注释中的特殊标签显式声明、记录版本并设定过期时间，严禁隐形默允。领域映射：在 PCB 设计中，左移即电气规则检查（ERC）、信号完整性快速审核；右移即全板 3D 电磁场仿真。在建筑中，左移即空间碰撞检查、疏散规范的自动审核；右移即性能化消防仿真与结构弹塑性地震反应分析。治理价值：分层验证漏斗实现了工程风险的经济最优化。工程师不再陷入“验证瘫痪”（因为害怕犯错而不敢快速迭代），也不会激进到“盲目试错”而频繁导致下游灾难。它还为自动化管道（CI/CD）提供了分层的事件触发体系。

4.5 基于事件的自动化管道（CI/CD）

原则：在 commit、PR/MR、定时（Nightly）、里程碑标签等事件上，自动触发上述分层验证任务，并将结果反馈至版本控制系统，形成严密的自动化门禁。快速层（commit 或 PR 时）：风格 lint、简单规则检查、单元级测试（毫秒~分钟）。中速层（PR 时或合并后）：子系统级多体运动校核、信号完整性、热网络分析（分钟~小时）。慢速层（Nightly 或 Release Tag 时）：全系统耦合仿真、合规性全跑、长周期退化测试（小时~天）。代码化管道：管道定义本身必须使用脚本化文本（如 GitLab CI YAML, Jenkinsfile 等），确保管道的版本化、可审计和可迭代。资源感知调度：硬件仿真对计算资源和商业许可证的消耗巨大，管道系统需集成许可证感知的调度器和强大的缓存策略（输入不变则跳过仿真），以避免资源的浪费性重复。领域映射：一个航空发动机的子系统开发可以这样配置：每当工程师推送一版叶片参数设计时，CI 管道自动生成几何、划分网格、运行简化的颤振分析；之后每晚自动运行全通道耦合 CFD，并在结果偏离基线时自动通知相关专业负责人。治理价值： CI/CD 管道将上述所有实践串联为一个可预测、可观测的工程生产系统。它使得“工程活动”本身被量化为数据流和事件流，管理者可以穿透表象看到真实的设计健康度（例如，管道赤字率、问题发现阶段分布、豁免债务累计），从而实现数据驱动的工程治理。

5 挑战与展望：EaC 的扩散与深化

尽管 EaC 拥有一套清晰的原则与工具俯视，将其从软件和 IC 领域推广到更广泛的工程领域仍面临巨大挑战。

文化惯性是最大的阻力。对于机械、建筑等领域，图形交互的“所见即所得”仍是主流文化，学习门槛、对抽象代码的心理排斥以及部分资深工程师对“丢掉鼠标”的抵触不可忽视。一种务实的策略是渐进式引入：先用脚本和文本接管工程中的“胶水”部分（如自动化数据转换、仿真报告生成），再逐步渗透到核心建模环节，同时辅以以 AI 自然语言为入口的过渡方案。
领域特定语言（DSL）的匮乏。没有丰富的、稳健的、生态活跃的 DSL，Txt First 就是一句空话。目前机械几何领域的 OpenSCAD 表达能力有限，CadQuery 正在发展但仍小众；系统工程虽有 SysML v2，但工具链尚不完整。这需要产业界、学术界联盟的共同投入，聚焦于几个高优先级的领域（如参数化 3D 几何、系统架构、测试设备描述）制定开放标准。
工具与数据的联邦化。目前各 PLM 和 CAD 厂商的输出格式仍互为壁垒。仅仅依赖 AI 进行格式转换是短视的，长期需推动类似“文档领域的 Markdown”或“数据序列化的 JSON”那样的极简开放标准，使 EaC 的工具链能跨厂商工作。这需要用户方的强力联合需求背书。
AI 的嵌入与伦理。 AI Agent 将能自动生成设计脚本、编写测试、审查差异乃至提出修复，但这也带来可解释性和责任归属问题。EaC 体系正因为将所有决策可追溯地记录在 Git 中，恰好为 AI 的引入提供了问责基础——“谁在何时为什么允许 AI 生成这段代码”是一个可审计的 commit。因此，EaC 可能是安全引入工程 AI 的先决条件，而非对立面。

6 结论

工程即代码不仅仅是将软件工具用在硬件设计中，更是对工程理性的一种元级重构。它把“如何设计”这件事从私人经验、默会知识、黑箱介质中解放出来，暴露为可计算、可辨伪的开放文本，从而使得工程活动具备软件领域早已习以为常的进化能力：快速试错、知识累积、自动化治理。在复杂性吞噬传统工程治理手段的今天，EaC 提供了一条可操作、可扩展、与 AI 共生演进的通途。作为本系列的开篇，本文搭建了 EaC 的概念框架与实践全景。后续文章将分别在集成电路、机械电子、建筑与基础设施、系统工程等具体领域中深入探讨其实施路径、技术栈和典型案例，力求为这场“工程的再编码”贡献一份切实的施工蓝图。