鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册

我即洪流:中国开源三十年

编程导航
编程导航
2025-12-21 23:50
阅读 177
编程导航
2025-12-21 23:50
阅读 177

文 | 脑极体

科技角逐或许是这个时代最大的命题之一。这场竞赛的天平最终会如何倾斜?有一个说法是,最终全世界超过70%的人用哪个国家的软件,科技的未来就将属于谁。

想要以最高效率推广自己的软件生态,开源被认为是最有效,也最聪明的办法。20世纪70-80年代,人类逐渐意识到每家企业都重新做一个软件,世界经济很快就会被天价的软件开发成本拖垮。只有将软件开源开放,让每位开发者自由获取基础软件和开发工具,数字革命才有成功的可能。Linux基金会认为,全球开源软件的替代价值已经超过了9万亿美元,这相当于一个大国的GDP,成就了人类关于分享与协作的技术神话。

虽然开源的本质是分享,但开源生态却有主导权。这种主导权展现在科技博弈中有两种体现,一种是在必要时,软件开源的上游国家与地区,可以切断下游的软件获取权,从而形成科技制裁;另一个角度看,开源生态的主导地与跟随地之间始终存在着能力鸿沟。资本、人才、产业标准都会向开源主导地汇聚。这意味着掌握软件开源的主导权,就掌握了科技领域的诸多主导权。

20世纪90年代,全球软件开源事业进入黄金时代。其中一只火苗早早落在了中国。在那之后的三十年时间里,中国从对开源的懵懂无知,到以开源生态作为发展红利,再到大势所迫下以我为主推动开源事业,在惊涛骇浪间经历了种种变化。

中国科技产业对开源的态度,基本上可以说折射了每一个阶段的发展中心与逻辑内核。

从发现洪流、借助洪流,到变成洪流,让我们来讲讲软件开源的中国故事。

启蒙时代

1991年Unix源码开放。就在同一年,芬兰赫尔辛基大学的大二学生林纳斯·托瓦兹借助Unix开发出了Linux内核。这个偶然间写出的操作系统内核,很快在刚刚萌芽的互联网上获得了广泛好评,在开发者群落中被认为是自由软件意志的一种代表。

刚巧的是,那时候宫敏博士正在赫尔辛基理工大学访学,他在研究并行计算相关课题时,偶然间发现了Linux,觉得这东西有点意思。1994年宫敏回国的时候,也顺道将Linux以及其他在当时被称为自由软件的软件源代码带回了北京。1997年,他再次带回了80GB的自由软件源代码,建立了“中国自由软件库”,以免费和开发的形式为开发者提供软件资源。这次偶然的信息交流,被广泛认为是中国软件开源的起点。

当时很多刚刚接触软件开发与互联网的年轻人,惊讶地发现居然有可以不要钱就随便获取的源代码。如此一来就可以用很低的成本完成众多领域需要的软件系统,从而完成商业化。这种由信息差与开源模式共同哺育的商业形态,在此后成为中国软件行业的基础。

从1999年起,以中关村为根据地涌现出了一大批从事Linux发行版的软件企业。他们的出现,让中国有效参与了以家用电脑和商业软件、互联网为代表的第三次工业革命,也为后来中国互联网经济腾飞埋下了伏笔。依靠一个人的敏锐嗅觉,整个中国软件产业保持了与全球高度一致的发展。这推动了萌芽阶段的中国软件产业成长,但也导致中国软件市场从最开始就有着依靠开源资源,缺乏自研能力,难以形成大型公司等一系列问题。

1997年,欧洲的开发者们提出用“开源”(Open Source)一词替代强调意识形态的自由软件,更加重视开源的商业化能力与社区包容属性,软件开源步入了历史上最为开放,也最富全球化色彩的新时代。

‌2008年‌,国际开源社区开始在北京召开全球技术峰会,2009年Linux基金会开始接受来自中国的代码。中国软件开源,就此正式成为全球开源的一部分。

云与AI的潮汐

2008年奥运会之后,伴随着智能手机与移动互联网的发展,中国迎来了史无前例的互联网经济腾飞。在这个阶段,中国开始形成以BAT为代表的科技巨头。虽然这些科技企业大部分以互联网应用起家,并不专注于软件开源事业和开源贡献,但当其业务覆盖面达到一定广度,储备了足够的技术能力之后,也势必会将自身能力外溢到开源生态当中。

于是,在移动互联网高速发展,互联网巨头主导科技发展的日子里,我们能看到中国开源事业也逐渐受益,迎来了新的变化。在20世纪90年代的开源萌芽阶段,中国开发者近乎完全是开源的受益方,他们将开源软件试做免费资源,以此赚得第一桶金。而在新阶段,中国互联网公司开始效仿硅谷巨头将自身技术能力进行开源,以此换取行业影响力,以及一些特定领域的平台化效应。

其中最具代表性的两个阶段,分别是互联网巨头进军云计算,以及后来面向AI的集结。

2010年之后,互联网公司布局云计算业务成为主流。而云计算有着复杂的软件开发体系与多样的开发者生态需求,从而导致云服务商对相关的软件开源事业大力推进。其中最具代表性的是2017年蚂蚁集团开源OceanBase分布式关系数据库,其TPC-C基准测试性能打破了当时的世界纪录。此后在2018年,腾讯开源了支撑微信业务的‌TDSQL‌分布式数据库。这些开源项目不仅推动了国内金融、通信、云服务等领域的发展,更强化了全球范围内的中国开源影响力。

在云计算之后,AI是新的主角。而最先探索AI方向的互联网巨头,为这个阶段中国AI基础软件的开源做出了极大贡献。其中最典型的,毫无疑问是百度在2016年开源的PaddlePaddle(飞桨),这是国内首个开源的产业级深度学习框架,填补了中国面对TensorFlow、Python等框架竞争中的产业空白。直到今天,我们所遇到的中小AI开发者团队也大多在使用飞桨,可见由其所构建的开发者生态影响广泛。

云与AI的潮汐涌来,让那些手握巨量技术资源的互联网公司参与到了中国开源事业的发展进程里。但在这个阶段,各个公司的生态封闭性与竞争性,导致了这些开源项目更多是依附于企业生态,并没有形成开放、统一、具有国家战略意义的整体性开源生态。开源似乎只是互联网繁荣的锦上添花。企业选择的开源路线也是为其本身战略服务。对开源操作系统等更为基础,但缺乏商业价值的领域却鲜有问津。

这时没有人会想到,繁花是顶不住风雨冲刷的。

花园变为高墙

在漫长的科技全球化季节里,我们都认为开源软件是难得的免费午餐。直到某一天,我们会发现原来免费确实是最昂贵的。

2018年10月,美国国防部发布了一份名为《弹性供应链安全》的报告。这份报告的特殊之处在于,其着重强调了开源软件的供应链安全与漏洞修补,被广泛看作是美国将开源软件纳入科技博弈筹码的开端。

2020年,美国大西洋理事会发布了《打破信任:不安全的软件供应链中的危机阴影》,首次将软件供应链定义为“国家安全政策制定中尚未被重视的重要领域”。报告中重点提到了保护美国的开源软件库。言下之意就是,美国已经将令科技对手无法获得开源软件视作一种战略手段。这种铁幕手段后续不断落实,比如在2022年俄罗斯大批企业与个人开发者的GitHub账户被封,让全世界彻底意识到了开源不等于可以永续获取。而一旦依赖竞争对手的开源软件库,铁幕降下后的打击可能是毁灭性的。

在这期间,中美之间发生了广为人知的中兴与华为被制裁事件,其后大批中国企业被列入所谓的实体清单。虽然中国企业的开源软件获取通道没有直接被切断,比如华为无法继续使用安卓操作系统的关键在于无法获取谷歌的GMS。但这个时期的种种现象已经表明,软件开源的全球化花园只是美好幻想,我们必须做好重做一切基础软件的准备。

其实在此之前的二十余年里,关于开源软件是否值得信赖始终都存在争议。依靠全球开源生态意味着更强的国际化能力,更低的成本,这些价值对于发展初期的中国软件产业来说至关重要。而重新做一套软件底座与开源生态虽然有着战略安全上的意义,却在商业层面极难成功,屡屡碰壁。

但此时,中国已经没有了其他选择。

2020年,工信部指导成立‌开放原子开源基金会‌,统筹OpenHarmony、欧拉等国家级开源项目‌。以中国为主的全球开源第二选择,正式被提上日程。

风中鸿蒙

在强调科技自立自强的新阶段中,中国软件开源最具代表性的事业毫无疑问是鸿蒙。客观来说,开源鸿蒙的产生和壮大深刻改变了中国软件开源的产业逻辑与文化氛围。“开源”从一个科技行业内的词汇,一跃成为街谈巷议的热点话题。记得一些并不从事科技行业的朋友,在看到开源鸿蒙的新闻之后都会主动问我,什么是开源?为什么企业要捐献源代码?

2019年8月,在美国宣布制裁华为的三个月后,已经确认无法继续使用安卓操作系统的华为,决定重起炉灶,正式发布了HarmonyOS 1.0。这个决定在当时并不被舆论看好,因为中国企业做操作系统可谓屡战屡败,几无胜绩。

所谓“系统好做,生态难成”。华为想要壮大鸿蒙生态的关键一步,就是将其推向类似于安卓的开源生态。于是在2020年9月‌,华为将HarmonyOS基础能力捐赠至开放原子开源基金会,开源项目命名为‌OpenAtom OpenHarmony‌,确立轻量系统、小型系统、标准系统三位一体架构。由此开始,鸿蒙分布式软总线的技术特性开始与开源操作系统、行业智能化需求,以及宏观层面的科技自立自强趋势紧密结合。新举国体制在重大科技领域的第一战,就由在狂风中生长的鸿蒙开始。矿山、港口、隧道、燃气、运营商等领域陆续出现以开源鸿蒙为底座的智能化方案,层出不穷的“某鸿”成为中国智能化进程中一道独特的景观。

顶着巨大争议,肩负着重大任务,到2025年开源鸿蒙经历了10次大版本迭代,拥有超过9700名核心贡献者,产出1.3亿行代码,500余家企业的1400余款产品通过兼容性测评。至少现在很难有人说,鸿蒙事业还有失败的可能。

鸿蒙带给中国开源生态最宝贵的东西,其实是信心。以往软件行业会认为开源业务就是把免费软件封装成商业版,做点小打小闹的生意,赚点酒桌上拼来的订单。但鸿蒙的成功,却让大家看到中国开源这件事不仅有希望,还能带来极大的自豪感和满足。由此开始,大批企业和人才开始涌入中国开源生态。开源事业在中国科技产业中的定位得到了一种根本性调整。

2025开放原子开发者大会,开放原子开源基金会宣布开源鸿蒙成为首批毕业项目。

中国开源生态真的已经彻底建成,前路一片坦荡了吗?答案可能依旧在风中。

大模型的新芽

如果说开源操作系统是中国科技体系内部的“重新打鼓另开张”,那么中国软件开源的另一面则是积极走出去。这条路上的代表是开源大模型。

在欧美科技巨头更加看重闭源模式的当口,阿里的通义、字节跳动的豆包等大模型已经纷纷走上了开源之路。并且很多AI公司会选择在全球市场同步,甚至率先发布自己的开源大模型,在GitHub社区等开源平台争取更高的活跃度与共享度。

中国开源大模型与全球同场竞技的玩法,开始逐渐凝结成了中国AI与中国软件的全球影响力。其中最成功的案例,应该是‌DeepSeek在开源后显示出了极低的训练成本,引起了世界范围的轰动。随后,DeepSeek-R1开启的MoE架构成为被广泛认可和接受的技术范式,直接开启了2025年全球AI产业的风向。

DeepSeek在海外社区的成功,或许可以看作是中国开源技术标准向外输出的一个关键节点。随后更多的中国科技企业效仿其做法,坚持全开源策略与全球化输出同步进行的发布模式。反而在这个AI竞赛的关键阶段,更多美国科技企业转向了闭源、收费、多版本的保守态势。并且在DeepSeek最为火爆的阶段,众多欧美国家相继以“国家安全”或“数据隐私风险”为由禁止使用DeepSeek。

中国大模型开源开放,美国大模型闭源保守。这个多少有点“倒反天罡”的局面,或许能够解读出更多饶有趣味的信号。

我即洪流

在宫敏博士将几十G“自由软件”代码带回中国的三十年后,软件开源开始确定性地上升为国家战略。

《“十四五”软件和信息技术服务业发展规划》中提出,中国要建设2~3个国际影响力的开源社区。目前,中国开源开发者数量位居全球第二;华为、阿里等企业在Apache、LF AI基金会中主导15%的核心项目‌;开放原子开源基金会推动‌了一批国家级开源项目的建设,搭建了较为完整的跨企业技术标准与合规体系。

与此同时,中国软件开源也正成为全球的第二个选择。开放原子开源基金会设立的专项孵化基金,已经支持东南亚、非洲等地区的数千个项目。同时中国开源生态也在帮助海外企业与开发者走入中国市场。GitHub社区副总裁Stormy Peters曾经说,中国拥有一个充满活力的开源软件社区,汇聚了1100万软件开发者,他们站在开源和人工智能领域的前沿。

为了走到今天所站的地方,中国试过很多条路,走了很久很久。

当然,中国的软件开源事业依旧充满着挑战。比如真正具有全球化可能性的明星项目太少,只能说刚刚解决了有与无的问题;比如中国开源事业的安全合规工作任重道远,依旧有大量陈旧、安全漏洞显著的开源代码正在运行,有待治理和优化;对于中国开发者而言,开源在很大程度来说依旧是一个遥远的概念,相关机会与资源,会更多集中在头部院校与大型科技企业当中,缺乏开源文化中应有的自由、平等,以及按贡献分配机制。

但不管怎么说,中国软件开源的生命力是真实可见的。我们共同经历这项事业变化最为剧烈,成长最为迅速的一个阶段。

软件开源是一股洪流。曾经的我们是偶然发现了它,让它带我们到下一个目的地。

后来,洪流反噬而来,开始变成想让我们停下脚步的阻力。

而现在,我就是洪流。

原文链接: 我即洪流:中国开源三十年
站长:程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
朱雀AI检测助手朱雀AI检测助手
🔥 热门文章
1
B 站上 DeepSeek 闹鱼灾了,我发起《大肥鱼清除计划》!
480
2
Vibe Coding 实战:从零构建现代专业级 AI 搜索引擎
430
3
我的第一个出海产品!7 天 2 万
370
4
又一个国产版 Codex 神器,也来卷办公了!
370
5
day3-如何写出一个高质量的 Skill(组内分享) 高质量 Skill 不是“一个调得很顺的巨型 Prompt”,而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”,再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子,但方法是通用的。 --- 一、先想清楚:Skill 到底是什么 一个 Skill 至少包含四部分: 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做,每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办,而不是硬编一个看似合理的结果 高质量 Skill 的共同点:职责单一、接口清晰、规则可定位、输出可验证。 反例:把几十条经验全塞进一个主 Prompt,改一条规则要重调整个 Prompt,评估时也不知道是哪条规则退化。 --- 二、核心方法:先建评估,再写 Skill 不要先写转换器再补测试。正确顺序是: 1. 定义输出契约:什么算合法、什么算合格; 2. 建金标准集:一小批人工认可“可放行”的样本; 3. 先写评估 Skill:让它在金标准集上跑出基线; 4. 再迭代生成 Skill:每次修改跑同一套评估,无退化且目标维度提升才算正向。 这就是评估驱动开发:评估是 Skill 的单元测试,金标准集是回归锚点。 --- 三、评估 Skill:三层门禁,逐层递进 前一层不过,后一层不跑。每层留可追溯证据。 第 1 层:确定性硬门禁 用解析器、Schema、校验器完成,不消耗模型成本。 · 输出可解析; · 必填字段齐全,类型/枚举合法; · 引用目标存在,无悬空引用、无不可达节点; · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层:语义断言 用脚本 + 结构遍历检查“逻辑对不对”,仍然保持确定性。 通用检查项: · 覆盖率:源材料里的关键步骤、分支、条件,输出里是否都有对应? · 完整性:每个判断节点是否都有明确出口?有没有死胡同? · 可达性:每条路径是否都能到达预期终点?有没有无出口循环? · 顺序与依赖:有先后依赖的操作,是否保留了顺序?有没有被拍平成无序列表? 例子:故障诊断转换中,检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层:LLM-as-Judge 只处理解析器表达不了的维度:忠实度、完整性、可执行性。 但 Judge 会漂移,不能单独放行,必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化,换模型必须用金标准集重新校准。 通用 Judge 维度: 维度 问什么 忠实度 输出是否忠实源材料意图?有没有自行发明内容? 完整性 关键步骤、条件、证据是否保留?隐式知识有没有被压成空话? 收敛性 输出是否仍指向原目标,而不是发散? 可执行性 下游不依赖源材料能否直接使用? --- 四、金标准集:回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子,扩到 15~30 份,覆盖失败模式而非随机抽样: · 完整正例:典型流程; · 边界/异常分支:异常路径、循环、前置失败回退; · 已知易错模式:实际踩过的坑; · 留出集:不参与调优,只用于最终验收,防过拟合。 金标准不需要完美,只需要当前标准下认可可放行。 回归指标:关键路径用 pass^k(k 次全过),稳定性用 pass@k。 --- 五、工程约束:让批量产出可重放 · 幂等:同输入 + 同 Skill 版本 + 同规则 → 输出一致,否则无法判断变好是 Skill 改了还是随机波动; · 隔离不阻断:单份失败进隔离队列,记录失败层和原因,不阻塞其余; · 版本绑定:规则、rubric、金标准集进 Git;每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”; · 抽样人工复核:Judge 临界样本 + 易错模式,人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅,写清:输入约定、输出契约、分步流程、硬规则、降级策略; · 经验规则放 references/ 或 rules/,按失败模式分类,不要全塞进主 Prompt; · 不确定时标 needs_review: true,不要硬编看似合理的结果; · 迭代由评估报告驱动:报告告诉你哪层挂了、哪类失败模式,你改对应规则文件,而不是漫无目的调 Prompt。 --- 七、落地顺序(不要反过来) 1. 固化输出契约:Schema + 结构约束; 2. 建金标准集:从已认可的 + 最易出错的样本开始; 3. 先写评估 Skill:跑出基线报告; 4. 再迭代生成 Skill:每次修改对比逐项通过率,无退化且目标提升才算正向; 5. 批量运行 + 隔离回放:失败进队列,结束后人工抽检; 6. 评估 Skill 自身版本化:换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”:每次修改必须附评估报告对比,逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数:前两层挂了,Judge 分数没有意义。 3. 不许把规则堆进主 Prompt:规则按失败模式分文件,评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”,评估 Skill 决定“敢不敢用”。 先让评估体系站稳,再让生成器迭代。这样交付的不是一堆“看起来还行”的产出,而是一套可证明、可回归、可交接的 Skill 质量体系。
340
6
DeepSeek 重磅开源的超级 Agent,到底是个啥?
330
7
最近在落地 AI Native 项目,卡在团队资产协同这块,想请教下社区各位有实际落地经验的同学: 我们现在的资产分为三块:项目文档(PRD/ADR/ 运行手册)、Agent Skill(业务技能、执行 SOP、提示词包)、MCP 工具服务定义。 目标是做到:人和多 Agent 共用一套可信资料源,Skill、MCP 配置、项目文档能够版本化、同步、共享、可评审。 目前我们初步方案是用 Git 做底层版本主线: - 文档:Markdown + ADR,带元信息,支持 RAG 检索 - Skill:单技能包目录化,带版本、评估用例、依赖声明 - MCP:项目级声明文件纳入 Git 但实际协作里遇到不少疑问,想参考大家成熟的实践: 1. 大家团队里,文档、Skill、MCP 三者是怎么组织目录和版本管理的?有没有稳定的仓库结构模板? 2. 多人协作时,Skill 的变更评审、灰度升级、依赖管理怎么做?如何避免本地版本不一致、“本地能跑别人不行”? 3. MCP 是统一中心化网关模式,还是大家各自本地启动 + git 同步配置?权限白名单、调用审计这块有什么好方案? 4. 有没有成熟工具链做自动同步(类似 agentmeld /teamai-cli)、变更校验、eval 回归门禁? 5. 文档和 Agent 的打通:哪些文档放进 Git 作为可信真值,哪些放外部知识库,边界怎么划分? 如果有现成的仓库样例、目录规范、团队协作流程,非常希望能分享参考,感谢!
280
8
PHP 被曝两大致命漏洞,请所有程序员抓紧做这件事!
280
9
人工智能前沿部署工程师(FDE) · 概 览 与 方 法 论
270
10
QuireKit 编辑器的 AI-Native 是如何设计的?谈谈我对真正 AI-Native 的理解
250
11
告别“金鱼记忆”:我开发了一款能当“第二大脑”的浏览器 AI 助手
250
12
ARTS 1101: 最长回文串与子序列匹配、一次 URL 请求的来回之旅与如何验证 AI 的交付
230