凭君莫话“卡脖子”：“法国科学院的Scilab”可以帮助中国解决MATLAB禁用问题吗？
本文内容由三部分组成。第一部分简述了无脑流量文对工业软件事业的伤害；第二部分简述了Scilab软件的发展历程及其在中国的发展；第三部分简述了笔者对“卡脖子”问题的一点浅见。
全文共9000字左右，阅读时间大约需要20分钟。
1.无脑流量文是搅浑舆论的泥石流
2020年6月份在哈工大和哈工程发生的MATLAB“禁运”事件刺痛了全体工程科技工作者的神经，无数有志之士奋起直追，战不旋踵的向着国产自主可控科学计算平台的目标发起冲锋。四年以来网上也一直在拿“MATLAB禁运”之后的“替代”说事儿，有的说可以替代，有的说不可以替代，有的说为什么要替代，众说纷纭。
如果说每一起禁运事件都像刀子般割痛国人的自尊心，那么这些反复炒冷饭的消极言论就像是生理周期般总让旧伤流新血，而反复被踢溜过来的Octave和Scilab等开源软件就像用来止血的卫生棉。但不管怎么讲，工业软件自主可控与国产化替代这么有意义、有难度、有门槛的事，有热度总比没热度好。
但近期看到的一篇网文，在我这里引发了十分严重的不适感。这篇原作于2024年4月3日的文案，被另一个公众 号在前几天洗稿转发，也许是蹭到了近期中法重大外交活动的热度，在短短一两天时间内收获了几十万的点击量。
这篇网文开篇的口吻让我想起了两件事。
其一是鲁迅先生提到的促使他“弃医从文”的“仙台医专幻灯片”事件，在仙台医专的课堂上播放的关于日俄战争的幻灯片，日本和俄国为争夺中国的土地而开战，当间谍的、被砍头的、围观取乐的却都是当时麻木不仁的清国人。
另一个就是“十四万人齐解甲，更无一个是男儿”的中国男足，在世界杯的赛场上，热情多金的国人只能选择当法国队的球迷、当德国队的球迷、当阿根廷的球迷，就是当不了中国队的球迷，颇有点“遗民泪尽胡尘里，北望王师又一年”的感觉。但反观国内的赛事，各种“外援”和“归化球员”演的飞起，体育频道跨界打击到了娱乐频道。
且不说各种国产替代、产业生态之类的复杂问题，这篇文档不到20行的开篇就错漏百出。
文案中提到的Scilab软件，与之相关的法国国家科研机构是1967年成立的法国国家信息与自动化研究所（简称INRIA），是法国经济财政工业部的直属单位。而标题及文中提到的法国科学院（简称CNRS）是1635年2月22日由法国首相黎塞留创立，是法兰西研究院的五个组成单位之一。开发了Scilab的INRIA和文案作者代表中国产业界感恩戴德的CNRS之间的关系，就好比是工信部电子五所和中科院的关系，作者大笔一挥正局秒变副国。
至于说文案作者代表MathWorks的七千人团队表达的“哭了，后悔死了”这样的忏悔情绪，其真实度跟某个时空里“在农具上贴个符纸就能正面直冲马克沁机关枪”的说法有的一拼。
道高一尺，魔高一丈。愚昧和偏执多一点，理性和务实就少很多。本来就已经很难了，还要时不时面对这种裹挟着巨大流量的泥沙俱下。
自主可控工业软件技术创新是逆水行舟的抗争，需要有健康的市场和舆论环境给予公平公正的评价和回报以鼓舞士气、激发斗志。
2.1 开源软件Scilab在科学计算领域的奋斗
根据在某专业数学软件资源库的检索结果，截至2023年元月份，可以检索到的科学计算、建模仿真、工程分析计算机程序代码及软件包大概有四万多种，其中进入到大众传播领域的科学计算商业及开源软件包大约有一百多种。在这一百多种软件中，广为人知的大约有二十多种。在这二十多种软件中，经常被拿来做各种算例进行性能分析的无外乎MATLAB、MATHMATICA、MAPLE、Scilab、Octave、C/C++语言及其相关库、R语言及相关库、Python语言及相关库、Julia语言及相关库，RUST语言和Mojo语言也有可能在较近期的未来进入这个列表。
从这个角度看，MATLAB和Scilab都算是很优秀的软件了。
然而，令人遗憾的是，这个领域市场形态是非常典型的“蝌蚪”形态，头部赢家通吃，余者花式图存。所以头部的MATLAB被誉为工科神器，MathWorks公司拥有十亿美元量级年收入和七千人团队，而产品技术看起来相差不多甚至颇有特色的其他几家竞品无论是从用户数量、团队规模以及企业营收方面都要比MathWorks少一个/几个数量级。
这是过往数十年里由各自不同的技术-企业-市场-社会之互动塑造而成的产业格局，并不是可以单纯依靠微观层面的产品功能和技术性能可以解释清楚的问题，这是技术经济学和技术哲学的研究领域。即使是像原子弹这样揭开新时代序幕的战略级武器也只敢说是“极大加速了战争进程”而不是说“因为有原子弹所以就赢得了战争”。同样的道理，一款科学计算软件不能也不可能因为其表面的相似性和开放性就无条件具备颠覆市场格局、补齐产业短板的力量。
Scilab软件和Matlab软件，其开发与推广几乎是同时起步的。
1979年，Cleve Moler在美国新墨西哥大学的数学课堂上，为了方便学生访问LINPACK和EISPACK数值计算软件，使用Fortran语言编写了第一个MATLAB程序。
1982年，法国计算机科学与控制研究所（INRIA）的两位工程师François Delebecque和Serge Steer在Fortran版MATLAB程序的启发下，开发了计算机辅助控制系统设计（CACSD）软件Blaise，目的是为研究人员提供一款用于自动控制领域的软件工具，这款软件是Scilab的前身。
1983年，在斯坦福大学读工程硕士的Jack-Little接触到了MATLAB，并在Moler的支持下为IBM-PC开发了商用版MATLAB，随后为MATLAB制定了商业计划，核心只有三点：（1）目标市场是科学与技术社区；（2）面向视窗操作系统和UNIX环境，要为工程师们创造类似于Lotus软件带给业务人员的体验；（3）以内核为基础，发展垂直产品线，占领工程市场。1984年12月7日，Little和Moler等人在美国加利福尼亚创建了MathWorks公司。
1984年11月26日，INRIA孵化了旗下第一家科技公司Simulog，这家公司的主要业务是对INRIA及其他研究机构的先进技术成果进行技术转移和技术应用，服务内容包括软件销售、软件开发、技术支持、技术研究及咨询等，这项业务后来被称作“新技术的工业化”。Simulog公司将Blaise软件改名为Basile进行商业推广。
Simulog公司的业务很成功，在之后的三十年里为欧洲的工业软件企业和行业用户提供了数十款软件产品及构件，孵化了九十多家公司。但Simulog公司对Basile软件的推广却是以失败告终的。
Scilab在最开始的时候本质上是一款商业化失败的产品，由于INRIA的非商业化的扶持和保护，才在免费开源的模式下获得了持续发展的机会。
在几年之后，1990年代初，Sumulog公司停止了对Basile产品的销售。INRIA又重新接过了Basile软件，将其改名为Scilab，并组建了Scilab小组继续开发这款软件。Scilab小组除了Scilab软件的两位创始人之外，又招募了来自法国国立路桥学校（ENPC）的Jean-Philippe-Chancelier和来自INRIA的Claude Gomez, Maurice Goursat,和Ramine Nikoukhah，六名研究人员构成了Scilab的核心开发团队。
之前失败的市场推广经历促使INRIA决定将采用免费开源的方式发展Scilab软件，并在1994年1月2日发布了Scilab的第一个正式版Scilab1.1，这样一直到2002年底发布Scilab2.7版本，Scilab软件一直都是由INRIA内部的Scilab小组开发。
图：Scilab的发展历程
免费开源的模式让Scilab重新焕发了生机。2003年初，随着越来越多地人下载和使用Scilab，为确保软件未来的持续发展，INRIA创建了产学融合的Scilab联盟进行Scilab软件的开发、维护、支持及推广。2005年，从Scilab 5版本开始，Scilab联盟开始使用Java语言开发Scilab，从此时期，Scilab软件开发变成两个分支，一个是由Scilab联盟开发的Scilab/Xcos分支，另一个是由法国国立路桥大学的Metalau项目团队开发的Scicoslab分支。
图：Scilab联盟的创始成员
工业软件产品不可能闭门造车埋头发展，不管采取什么样的方式都必须要构建/融入行业应用生态，这一点Scilab走对了才获得了继续发展的机会。
2008年，Scilab联盟并入法国Digiteo研究网络，提出了“以工业化的方式开发Scilab”，他们期待工业应用能带来软件创新，期待开源能带来质量。也就是从这时起，Scilab开始以GPL许可的方式进行分发。与此同时，Scilab的工具箱机制允许用户基于Scilab开发应用程序，这些应用程序可以使用GPL协议之外的其他商用或开源协议。
随着行业用户数量的增长，围绕着开源软件的服务需求迅速增长，Scilab又一次嗅到了商业化的契机。2010年6月，在INRIA的支持下成立了商业化的Scilab Enterprise 公司，目的是在经典开源业务模式的基础上，提供更专业的Scilab服务与支持。Scilab Enterprise从2012年7月以来从INRIA全面接管了Scilab的开发与版本更新。
新一代的科学计算软件，其核心能力及能力发展方向是对行业先进工程设计方法的支持，是对行业未来技术发展方向的响应。
在大量的工程服务项目之外，Scilab Enterprise认识到繁荣的应用生态必须建立在强大的产品能力基础上。有技术吸引力和应用扩展性的产品研发项目不仅是面向未来发展的能力保障，也是开源软件开发资金的重要来源。
Scilab迈向了云端，因为Scilab团队发现，大量行业用户并不是直接使用Scilab产品的软件功能，而是基于Scilab提供的功能进行应用开发。在这种场景中，与其说Scilab的竞品是MATLAB，不如说其真正的竞品是Excel。Scilab团队还发起了一系列能力拓展项目，ARGO项目为Xcos带来了嵌入式代码生成的能力；COLOC项目带来了高性能计算平台上的协作能力；CLARITY项目支持构建面向MBSE的开源生态系统；MECASIF项目进行了面向未来科学计算与系统仿真融合的有限元分析及模型降阶能力。
一个技术优秀而商业瘸腿的软件公司在市场中竞争，就好比六岁稚子怀抱千金招摇过市。在Scilab团队尚不清晰如何在市值60亿美金的仿真与分析软件市场打响名号时，还在探索匹配其技术能力的业务发展策略时，早已有静悄悄的大鳄盯上了他。
2017年，Scilab Enterprise公司被ESI集团收购，Scilab软件的开发运营团队转入ESI集团。ESI集团宣称其拥有运营开源工程科学软件OpenFOAM的经验，希望在Scilab软件的基础上打造一个更强大的免费开源数值计算软件。2017年2月，ScilabEnterprise公司被ESI集团收购，Scilab软件的开发运营团队转入ESI集团。ESI集团宣称其拥有运营开源工程科学软件OpenFOAM的经验，希望在Scilab软件的基础上打造一个更强大的免费开源数值计算软件。但业界普遍认为，ESI集团对Scilab的收购，是为了完善其虚拟样机解决方案，帮助行业用户客户在 “产品生命周期管理”（PLM）框架中构建的数学分析模型，从而在进行详细的（0D-1D到3D）设计、分析仿真前，工程师可以通过构建0D-1D模型快速探索设计的优化选项。
有人说ESI集团收购Scilab是为了以平滑的曲线获得Scilab在免费开源模式下培养的用户社区和生态，但四年后ESI集团发现生态已经没有了。2021年，ESI集团进行战略调整，将Scilab软件产品划入“非核心业务”范围。2022年，达索系统收购了ESI集团的Scilab业务，Scilab团队加入达索系统，并发布Scilab 2023.0.0版本。Scilab软件又一次埋没在了庞大的产品目录深处，即使是从达索系统业界一流的3D体验生态中也看不到由Scilab软件支持的科学计算板块。
虽然Scilab号称是“最完美的MATLAB”替代，虽然有代理商宣称Scilab的用户社区已经超过了百万量级，但作为欧洲科学计算与建模仿真软件代表的Scilab不仅没有在本乡本土的欧洲打赢MATLAB，甚至没有基调三大数学软件中的任何一个，只是以开源产品、技术构件、业务单元的形态流落辗转在不同的产学研主体之间。
虽然所有工业软件发展的最终目标都是建立生机盎然的行业应用创新生态，但是免费开源和商业闭环二者是互补互促的关系，而不是相互替代的关系。Scilab作为欧洲开源工程科学软件的一朵奇葩，在过早地商业化中夭折，这也是ESI集团业务衰退的缩影。在低价出售Scilab业务不久之后，作为欧洲工业软件支柱之一的ESI集团被美国是德科技收购。这或许就是冥冥之中的天意吧，欧洲的Scilab，还是留在了欧洲。
2.2 Scilab在中国
中国并非没有给过Scilab机会，而且是两次。早在2000年代，中国科学院自动化所和法国INRIA联合创办的中法信息、自动化与应用数学实验室就在国内大力推动发展和普及科学计算自由软件SCILAB，他们组织了基于SCILAB平台的应用软件比赛，又出版SCILAB相关的书籍，以便让更多的同仁们了解和掌握SCILAB。在近十年的时间里，举办了一系列推广普及活动。
图：Scilab在中国举办的一系列赛事
图：某次Scilab相关赛事的广告
这一次，中国没有选择Scilab软件。得益于互联网的记忆，我们可以查到当时的一些蛛丝马迹，以管窥这一波“退潮”的因由。
其一，推广Scilab软件，是中科院自动化所中法信息、自动化、应用数学联合实验室 (LIAMA)在进行中法科技合作中偶然“捡”起来的一个分支。
在2007年以前的十年中，有1000多名中法科技人员联合进行了100多个研究项目。Scilab推广在起初甚至不是一个项目。即使后来获得了863计划的支持，但是在LIAMA十周年的新闻报道中，也只提了一句：“实验室积极推广开放源代码的科学计算软件Scilab，这种软件目前在中国得到普遍使用，亦用于中等教育中”。
Scilab在中国的主要推手，已故中科院自动化所研究员、在2000-2005年担任LIAMA中方主任的胡包钢先生在这个时期的主要科研领域是植物生长建模、仿真与可视化，合作研究的主要成果是GreenLab植物生长模型，并没有跟Scilab有明显的联系。
当时的法方合作者、后来被授予“友谊奖”和“James C. Maxwell Award奖”的法国国际农业研究发展中心（CIRAD）研究员Philippe de Reffye教授在项目中使用SCILAB 软件开展了植物建模方面的研究。实验室2001 年4月9日－11 日在北京举办“2001 年科学计算软件－SCILAB 研讨会”，从此之后胡包钢先生就开始了在中国推广Scilab的征程。但当时推广Scilab的出发点可能更多的是着眼于“反盗版、软件规范化”。胡包钢先生在后来的采访中也坦言：“这个工作是业余的，算不得研究成果”。
图：中关村期刊对胡包钢先生推广Scilab的报道。
图：Philippe Verchere de Reffye，图片左下角是他与胡包钢先生合影。
图片来源：澳门科技大学网站https://www.must.edu.mo/cn/fie/news/55273-article1128105844-c
图：胡包钢先生在2003年Scilab研讨会上的书面发言
其二是资源来源的“863计划”支持项目的变迁。
目前可查到，先后有两个“863计划”项目主要用来支持Scilab的推广。2003 年－2004 年12 月，中法实验室与西安及北京地区等单位共同获得了国家863计划资助，项目名称为“开放源代码软件SCILAB 的开发及在中国西部教育的推广应用”。到了2007年，新的支持项目就变成了“基础教育科学计算服务社区工具箱开发和应用(2007AA010609)”，是贵州师范大学获得的首个科技部863专项，主要研究开源计算软件的开发及推广。值得一提的是，网上有一个名叫“共创软件联盟维护863开源项目”的虚拟组织，其长长的开源项目列表中，Scilab排在末尾，并且是唯一一个没有有效连接的项目。据网友反馈，这一波Scilab中国推广的资源网站大约是在2017-2018年之间被关闭了。
图：失效的Scilab中国项目链接
此外，或许还有一点人事和组织变迁的因素在里面。
早期将Scilab引入中国的Philippe de Reffye教授只在中国呆了三年。作为主要推手的LIAMA第二任中方所长（2000-2005）胡包钢先生，在2006年之后就再未见到担任学术领导职务的报道。胡先生的前任，LIAMA第一任中方所长、中科院自动化所研究员、欧美同学会副会长马颂德先生，在卸任LIAMA中方所长之后，担任的职务是科技部主管863计划等系列高科技 发展计划的副部长。2008年国家大部制改革，科技部的部分职权转移到了新组建的工信部。工信部新组建了软件服务业司，并创造了如今流行的“工业软件”这个产业名词。2008年10月28日下午，中科院自动化所中法信息、自动化与应用数学联合实验室(LIAMA在自动化所举行了旨在建立新的LIAMA联盟的第四期合作协议签字仪式，对实验室的组织机构及合作伙伴制度做出重大变更。这一年之后，就再未见到中科院系统在中国举办Scilab竞赛。
2009年在豆瓣上出现了一个帖子，网友们纷纷留言“强推”，“不好用”，“界面丑”，或许可以算是一点点用户声音。
胡包钢先生之后在人工智能领域主攻“广义约束”方向，但同时也在持续推广Scilab软件。在中科院的官网上，留存着一则报道，2016年的某一天，胡包钢先生和其他科学家向贵州中学生们进行科普宣讲，胡先生宣讲的主题就是科学计算和Scilab软件。
Scilab第二次在中国的推广就是ESI中国公司的商业行为了。在ESI集团收购Scilab事业公司后，在三年多的时间里，ESI集团与中国航发集团的合资公司航发伊萨大力推动Scilab和SimulationX的整合，并在航空航天行业推广以此为基础的MBSE解决方案。科学计算与系统建模仿真的技术/产品整合失败了，Scilab业务就成了边缘非核心业务被廉价出售给了达索系统。
3.指望Scilab解决“卡脖子”问题是无稽之谈
“卡脖子”这个词在中文语境中出现了两次。
一次是在1996年左右，当时中国航天正在进行质量提升，在一些相关文件中提到了质量“卡脖子”，指的是由少量电子元器件的低质量引发的大系统不可靠现象。
另一次大约出现在2017年后，由美国时任总统特朗普利用行政手段打破自由贸易原则而凸显出的供应链安全受到破坏与威胁的现象。科技日报曾发表系列文章列举了制约我国工业发展的35项“卡脖子”技术，其中包括核心工业软件和航空设计软件。
MATLAB归属于中国工程院制造强国咨询委员会列举的“工业基础软件”类。哈工大和哈工程的“MATLAB禁运”事件算不算是“卡脖子”、“卡脖子”这个问题是否成立有待商榷。
软件“卡脖子”是产业问题，是在非常高水平的工业和工业科技前沿才会凸显的现象，这是商用软件和市场化竞争的战场，从直观层面讲是考验的是相关产业生态的自适应性，从战略层面讲考验的是一个国家工程科技发展能力和全球产业竞争的供应链攻防战力。
影响到华为、航天、比亚迪、小米这样的全球一流企业研发及运营效率，这叫“卡脖子”。影响到二流工科生水论文画界面，这不叫卡脖子，这叫磨炼人才或淘汰米虫。
那些在求学阶段肤浅的将商用软件能力错认为自身工程能力的年轻人，在读了理工科的硕士甚至博士出来后，说不定会惊奇地发现要去跟学文科甚至是学艺术的竞争美其名曰“建模仿真工程师”的软件操作工岗位，说不定还会败下阵来。这不是段子，这是已经发生且愈演愈烈的现实。
别看流量掮客们节奏带的high，呼唤“法国科学院”带着“自由开源”的Scilab施恩中国，ESI集团自己也不认为Scilab具备替代MATLAB的能力。
2020年的8月，在“禁运”事件发生后的两个月，ESI集团发布了新产品预告，要用一个名为“ESI-Studio”的新产品完成对MATLAB/Simulink的替代。
他是这么说的：“现阶段ESI-Studio的覆盖了分析脚本中90%的MATLAB函数，通过定期增加附加功能，完成对MATLAB和Simulink的替代。”
他选择的是多语言集成方案，“使用一个Octave内核来提供与MATLAB脚本的兼容性，并使用一个Scilab内核来开辟新天地。python内核的集成正在进行中…将定期增加附加功能”。
而且，更重要的是，开源并不免费，而是“与MATLAB和Simulink每年的维护费用相比，使用ESI-Studio节省的成本约为40%；与租赁或购买新的许可证相比，节省的成本更大，可达80%。”
图：ESI集团在2020年8月份的广告
然后呢？我们现在看，这个ESI Studio的产品在哪里？Scilab在哪里？ESI集团在哪里？
作为商用工具软件，其存在的基础就是对高效工程设计方法的支持。
1990年代，在模型驱动架构（MDA）等软件工程方法指导下，在美国空军及洛克希德马丁公司新一代战斗机航电系统开发需求的牵引下，MathWorks公司在行业用户手把手的指导和验证中，MathWorks基于新生的Simulink建模环境开发出了“嵌入式代码生成”能力，并总结出“基于模型设计”（MBD）的工程方法。在随后的二十多年里，在与各行业龙头企业持续不断地交互、迭代和验证中，直到2018年左右才基本完成了MBD方法及其工具链。这是一套非常庞大和严密的产品/技术体系。我就举一个很简单的例子，MATLAB 2023a版本，有一个用来保证MBD方法对各种目标硬件适用性的附属安装包，这个安装包的大小是30GB左右，比MATLAB 2023a自身的安装包（不带帮助文档）还要大一些。
而Scilab/Xcos的嵌入式代码生成能力，是在2012年之后通过欧洲ARGO项目添加的，这是一个联合项目，项目还在扫尾呢，Scilab Enterprise就被ESI集团收购了，而ESI集团他直到被收购就没跨出机械域啊。
图：欧洲ARGO项目试图开发MBD支持能力
在能够支持工程方法的前提下，工具的专业性和效率决定了工具的应用前景。工程师不玩虚的也不看市场报告，工程师对工具的要求就是“快不快，稳不稳”。有很多软件，真的不到工程现场就不知道有多慢（烂）。
如下是欧洲人自己测出来的在雷达信号处理场景中的科学计算与建模仿真软件（语言）性能测例。不懂专业没关系，会看图就行。从图中可以看出，两个开源大咖Scilab和Octave，在各种测试场景中那真是慢的惨不忍睹。也就在LMS算法场景中，Scilab的性能比Octave好一点，在大多数场景中Scilab的性能都是垫底的，跟MATLAB、Python、Julia之类差了数量级了。
再说一遍，Scilab是真的慢，垫底啊！
同时，也发现了一个很有趣的现象，最快的竟然不是被你们封为“神器”的MATLAB，而是2012年才发布0.1版的Julia语言。
从另一张图可以对Julia的速度做一个直观解释：Julia有能力调动更多的计算资源，用算力换速度，以血换蓝。
难怪这帮搞硬件的这么力挺Julia，这是消费算力的“大客户”啊。就凭这一点，我就敢断定Julia如果在中国推开了，前景绝对好。毕竟软件的尽头是硬件，硬件的尽头是能源。看看这些年全国各地大干快上了多少算力项目，多少电力项目，就知道这种有能耐消费算力的大客户未来会有多么地受欢迎。更何况据说一些需要玩张量计算的高端科研项目，比如量子物理之类的，用Julia特别合适，据说是跟语言的设计有关，这就不是我能说清楚的了。
然而，Scilab这么慢，Julia这么快，而Julia也是开源的，是不是直接把Julia拉过来就能解决“MATLAB禁运”的问题了呢？以下的内容我是冒着法律风险在讲了。
这个说法有对的成分在里面，因为在目前国内主流的MATLAB替代方案中，基于Julia及其底层LLVM编译器生态的技术确实是占据了一定的份额。
但这个说法肯定是不对的。国内某厂商在很早很早之前，甚至可能是2020年之前就确定了基于Julia语言标准做产品，并很快做出了国际领先的Julia IDE，因此在2020年的时候与几个行业龙头一拍即合，基于Julia做方案。然后这公司的相关团队就陷入了极其苦逼的三、四年，据说为这事加班加到某行业著名卷王企业都觉得某公司的人更卷。就不说那些什么多语言支持、MATLAB/Simulink无缝转换、多目标硬件编译、用户体验之类的“硬核”问题了。就说性能这一点，尽管Julia已经比MATLAB快了这么多了，但行业用户还是觉得不够快。
“卡脖子”的和被“卡脖子”的，都是发生在产业高水平的“雪线”之上。破解“卡脖子”问题，与其说是登顶珠峰的竞赛，不如说是守护开放市场的战役，需要的是激烈市场竞争中锤炼出的精兵强将。革命不是请客吃饭。
这就是为什么以华为的战力，也要用好几年的时间，才发布盘 古科学计算大模型迈进了数据驱动的第四范式；苏州同元为了做一点“不止于替代”的事情，在二十多年积累的基础上，用了四年的时间投入了数千人/年的资源，才敢在发布新一代科学计算与系统建模平台MWORKS 2024版时说一句“第四选择-中国方案”。
纵观中国工业软件发展历史，有多少老先生为之投入半生心血却湮没无闻，有多少人在为之通宵达旦殚精竭虑，有多少人在无声之处酝酿惊雷。自己人和自己人倾注全部精气神的奋斗，才是关键时刻靠得住的。
全文完，感谢阅读！
声明：上述所有提及或未提及的微 信文章，所有文章从素材到内容都是本人在业余时间在互联网上独立搜集、提炼、生成，所有注明或未注明的引用材料本人都有源文件备份。除笔者自购书籍及受赠书籍外，本人从未从任何线下实体机构获取相关知识材料，也从未使用任何线下组织的专有材料。所有内容只代表本人阅历、判断、主观观点与情绪，不保证正确性与规范性，不代表本人在任何时期从事学习或服务的机构观点。如有侵权或异议，请随时私信联系。
