陈刚直言 | 华为韬(τ)定律启示:发起 AMT2ABC 开源生态
在前两期内容里我们分别拆解了基于SECP 框架搭建 ABC 原子能力的复用逻辑并依托华为韬 (τ) 定律论证了依靠复杂度转移实现工业软件破局的思路。本文接续前两篇文章的内容聚焦落地实操正式推出AMT2ABCAtomic Mechanism Triple to Atomic Business Capability开源生态计划。技术发展有两条路一种是深耕细作追求每一点提升与优化第二种是通过范式创新实现“降维打击”。华为韬(τ)定律以“时间缩微”替代“几何缩微”把芯片性能提升的重心从制造端转移到设计端。一、韬(τ)定律复杂度转移的典范摩尔定律主导半导体产业半个多世纪通过把晶体管越做越小实现每18-24个月晶体管密度翻倍但几何级数增长终会迎来瓶颈光刻机越来越贵制程研发投入增长良率爬坡困难。韬(τ)定律提出了新方向就是把复杂度从制造端转移到设计端通过“逻辑折叠”等技术在相对成熟的制程上依靠设计创新实现接近先进制程的性能。基于这套方法论华为已成功设计并量产了381款芯片2026年秋季将推出的麒麟芯片将首次采用“逻辑折叠”技术。二、工业软件的“几何缩微困境”韬(τ)定律的成功也给工业软件行业带来启示。海外巨头数十年积累形成了功能高度堆叠、底层代码固化的单体架构往往具备以下特征项目制每个客户一套代码功能难以复用或成本较高烟囱式不同产线、系统间彼此孤立变更代价高可拓展性差更新升级可能受架构限制这就是工业软件的“几何缩微困境”——试图用功能堆砌、代码膨胀来覆盖所有需求结果是系统越来越重维护成本持续上升。更深一步看以往许多工业软件项目的开发本质上只是在做“手工翻译”客户说“降低气孔率” → 顾问分析 → 工程师设计流程 → 开发人员写代码 → 测试验证逻辑。每一步其实就是把业务诉求翻成系统逻辑把工艺知识翻成软件代码。这就像几十年前程序员手写汇编不是顾问和工程师没价值而是这种重复“转译”的苦活本该交给工具靠人工翻译固然可行但效率太低且极其依赖个人经验。三、RISC的启示没有CompilerRISC很难成为主流如何解决工业软件当前的困境除了韬(τ)定律的例子外还可以参考RISCReduced Instruction Set Computer精简指令集计算机的革命的经验。几十年前RISC横空出世并很快获得市场认可很多人认为RISC的成功是因为指令变简单了但这个看法并不全面。指令虽然简单了程序却变复杂了如果没有新的技术承接这些复杂度RISC难以普及这场变革的幕后英雄和关键角色是Compiler编译器。程序员不再需要手工编写大量汇编代码只需要表达意图Compiler自动完成语法分析、优化、指令生成、寄存器分配将复杂度从程序员转移到了Compiler。当下的工业软件正在经历类似的时刻。在之前的文章中我解释了如何将复杂、多变的工业机理与现场进行结构化、工程化表达将工业企业所需的管理、控制能力拆解为ABC原子业务能力类似于RISC的精简指令但目前还缺少一个能够将业务目标自动编译为ABC组合的Compiler。这就是我们提出的AMT2ABC思路从原子机理AMT到原子业务能力ABC的编译。四、Compiler从机理到场景的自动编排工业软件的Compiler应当从机理出发。之所以从机理出发是因为工业现场的本质不是流程、表单或低代码节点而是物理规律、工艺约束与因果链。常规低代码平台从流程出发隐含的前提是“人已经知道怎么做”——只需把设计好的逻辑拖拽实现。而AMT2ABC要解决的是“人告诉系统要什么系统自动推导怎么做”。以压铸为例“降低气孔率”这一目标需要系统理解其物理成因模温、压射速度、真空度自动关联相应AMT形成闭环。若从流程出发人仍需手工配置每个节点从机理出发才能让系统真正理解工业规律实现自动编译。无论是压铸、注塑、机加工还是制浆、发酵背后都存在客观的机理。这些机理不会因工厂或软件的改变而改变。这不是传统软件开发而是软件能力的编译。整个链路如下第一步通过Working Domain → Mechanism → AMT → AMT Graph的链路从工作域的客观机理中拆解出最小软件能力单元——原子机理三元组AMT连成能力全景图第二步遵循GS(Goal Set业务目标 ) → AMT Cluster → ABC系统根据业务目标自动抽取闭环子图封装为可复用的原子业务能力ABC最终形成App/Agent → Scenario → OAO Loop的完整闭环将ABC打包生成应用与智能体进入业务运营注链路中业务目标GS之前的部分由人预先定义之后的部分由Compiler自动完成。为了更清晰地理解“AMT Cluster”我们先做一个直观想象一个压铸产线目标是降低气孔率。过去人必须手工组合模温、压射、真空等控制逻辑。现在系统自动选择相关能力形成闭环子图这就是AMT Cluster。随后Compiler将这个Cluster封装为可复用的原子业务能力ABC最终组合成App/Agent进入生产闭环。过去是人去找软件能力未来可以是系统自动编译软件能力。五、SECPCompiler的语法结构那么Compiler应当建立在怎样的语法基础上哪些内容适合SECP表达哪些内容仍需要传统算法、模型或人工工程判断SECP四维框架已经提供了一个思路工业软件应用通常可以归约为S结构、E事件、C配置、P流程四类要素的组合与计算。S产线、设备、物料如何组织E运行中发生了什么变化报警、采样、状态切换C依据什么规则判断阈值、配方、参数模板P接下来做什么顺序、分支、循环如果说AMT是Compiler处理的语义那么SECP就是规范这些语义的语法。*注Compiler的语法规则包括每个ABC必须声明其所依赖的SECP指纹每个场景目标必须被归约为一个SECP四元组Compiler在组合ABC时需检查SECP指纹的兼容性。与韬(τ)定律思路一致SECP将复杂度从固化在底层代码中的“功能堆砌”转移到可配置、可复用的实例层。新增一台设备 → 只需在S中添加节点在C中设定参数模板 → 不修改核心代码切换产品类型 → 只需更换一套C/P配置实例 → 不重建系统跨行业复用 → 同一套SECP结构差异仅体现在参数和流程配置上实践验证基于这套体系在已建模工作域/已有ABC基础上200多个“工业应用壳层”已从船舶制造快速适配到卫星组装、新能源储能适配周期从月级压缩至天级或周级底层代码无需大规模重构。过去一个产线配置修改需要数周现在通过SECP/AMT2ABC可在一天内完成。这正是韬(τ)定律所揭示的复杂度转移把工业软件的复杂度从固化底层代码转移到SECP实例配置层。六、与低代码平台的区别这里需要区分下低代码平台与Compiler的不同定位。低代码平台降低的是编码门槛使非专业程序员也能通过拖拽生成界面和逻辑。而Compiler降低的是软件能力组合的认知门槛——让系统理解业务目标并从原子能力库中编排出解决方案。举例说明低代码平台用户需要拖拽配置规则“如果温度超过阈值则报警”的逻辑Compiler接收“降低气孔率”的业务目标后自动关联模温、压射速度、真空度等软件能力并形成闭环。简言之低代码是人告诉系统“怎么做”拖拽流程、配置规则Compiler是人告诉系统“要什么”业务目标系统自动推导“怎么做”。七、RISC-V的启示事实标准来自实践积累AMT2ABC体系目前没有国际标准背书这是否可行回顾RISC-V的发展2010年诞生于UC Berkeley最初仅作为教学工具。今天全球RISC-V核心芯片出货量已超百亿颗进入数据中心核心市场。这不是预先设计的标准化路径而是“先用起来、逐步规范”的事实标准过程。Compiler无法由单一机构独立完成——它需要生态的支撑。为此我们正式宣布AMT2ABC开源生态计划。下一步行动访问AMT2ABC GitHub、Gitee仓库https://github.com/zylliondata/AMT2ABChttps://gitee.com/zylliondata/AMT2ABC加入AMT范式贡献者社区参与Compiler原型早期测试共享ABC能力成果提交您封装的ABC模块或分享跨行业复用案例可点击下方链接继续查看陈刚直言 | 华为韬(τ)定律启示发起 AMT2ABC 开源生态mp.weixin.qq.com/s/FmHBiBlYfp1zZHyWgzqJCg