在2026做AI开发

从2022开始ChatGPT、Gemini、Deepseek这样的AI工具开始发展，自己也尝试让AI参与自己科研方向的开发工作，算到现在已经用了相当长一段时间API式的AI调用和Agent开发；另一方面自己在学校做的开发工作算深度学习方向，与AI（LLM/GPT）也脱不开干系。

突然很想写这么一篇杂谈，与其说是在2026做AI开发的经验心得，不如说是作为一个非职业（因为还是学生）的程序员对于开源这件事心态的转变。

对开源项目“祛魅”

我想，任何一个正常的程序员，或多或少都曾对开源抱持过某种“宗教般”的情结。

这种情结发生在会用Github、了解“开源”这件事后——开源是什么？往小了说，就是把代码公开，让人随便看、随便改、随便用，只要标个原作者还能自己拿去卖钱。往大了说，这是一种关于知识共享的理想——代码不该是锁在盒子里的秘密，而应该是全人类共有的积木。你搭一层，我搭一层，后人站在前人的肩膀上，看得更远。这种理想在计算机发展初期、也是我出生的2000年尤其耀眼。互联网刚刚开始向普通人敞开大门，人们还相信去中心化的协作能创造奇迹，相信这个东西能改变世界。那是一个连“开源”这个词本身都带着光环的年代。

而GitHub把这种光环具象化了。一个项目的star越多，意味着用的人越多，意味着项目越重要，意味着它的维护者/群体在这个数字世界里拥有更高的声誉。尽管自己接触电脑很早，但真正上手去敲实用的代码差不多要到大二大三的时候，那时候我心里总会惦记着：什么时候自己才能写这么“有用”的代码？

自己很自然地也参与到了开源的开发中。最开始的自己一窍不通，只能从用户的角度，按照模版提issue；到后来可以读写一点源码，可以编test case，写测试issue；再到自己参与到开源团队中，提的PR被通过，自己也自己写了点小项目，拿到了一点star。小确幸的感觉的确有，但随着开发和对于开源的了解逐渐深入，那种神圣感消解了。

而且，世界是残酷的。开源社区的乱象随着“开源”这件事的“出圈”而变得愈加“明显”，一方面是个人用户/开发者/企业普遍不尊重开源，个人用户把issue当许愿池、抹去作者信息后把代码挂淘宝卖钱，公司挪用开源代码还能“倒打一耙”说作者侵权；另一方面，是部分开源作者（被）投毒，对于critical issue只是not a bug的态度；还有现在AI时代才出现的，一些作者提交不加审查的、AI编写的代码，像倒垃圾一样交付给作者等等。互联网变得普遍易用的同时，开源协议却还像是一张废纸，不太具有法律效力，就连ffmpeg这样的项目，也只能把potplayer挂耻辱柱上。

人是复杂的，不过作为一个程序员而言，我还是稍微偏袒开源作者一方，毕竟道德上本应如此：代码既然“as is”提供，就不必再为它负责，不必提供readme，也不必security check，不必修bug，只要不违法开源协议（作为代码提供的条件），那么怎么用是用户的事情，用出了问题也只能说明用户的水平太差；当然，一个人可以因为对一个人开源出来的junk code不满，对一个作者的政治言论不满，不再信任某一个单独的作者，这都是充满了自由的事情。而正是因为开源的这层自然性，开源从来就不是什么特别神圣的事情，停留在人的亮面就足够了，代码本身并不会因为人的这层亮面而拥有一些不被期许的优越性。

我觉得我对于开源“祛魅”的过程，也就是消除掉开源这层“被过度高估”的特性，并与之共存的过程——最开始是近乎宗教的尊敬，然后是对于一些常用但又不易用的开源项目的不满（比如conda），到现在成为了自己的日常。开源是一件伟大的事情，这点一直都不会变，在自己的能力范围内，也会继续做一点开源。现在做开源，更像是在路边摆个摊——谁爱拿谁拿，谁爱改谁改，遇到顺手帮忙的，说声谢谢；遇到砸摊子的，只要没有过分的影响不理就是，收拾收拾继续摆。

造轮子正当时

重造轮子（英语：Reinventing the wheel）是重新创造一个已有的或是早已被优化过的基本方法，此用语常出现在软件开发或其他工程领域中。“重造轮子”一词的由来，是因为轮子自从被发明后，在使用上没有太大的缺陷，足以应付多数需求，原则上后人只需要直接应用即可，重新再发明一次轮子不但没有意义、浪费时间、还会分散研究者的资源，使其无法投入更有意义及价值的目标。——wikipedia

“抽象”和“复用”是软件开发中非常重要的概念，也是“造轮子”一词最容易被提起的地方。对于计算机这样的行业从来不缺什么大佬，现代硬件也发展的很快，对于个人用户来说，一段排序算法，一个深度学习库，一个番茄钟应用——如果有现成的、好用的，直接拿来用确实是最理性的选择，现代硬件已经够快了，大部分场景下你费尽心思用汇编抠出来的那几毫秒，还不如代码可读性和稳健性重要。

但我现在越来越觉得，“不要造轮子”这句话，正在失去它的魔力。

原因很简单：别人的轮子，越来越靠不住了。

我平时用的软件大概分三类。一类是付费的，这个没什么好说，花钱买省心。一类是免费但不开源的，这种用着总得留个心眼——你不知道它什么时候就跑路了，或者突然变成付费订阅。还有一类是免费开源的，也是我在“开源神圣期”最偏爱的。

但现在，免费开源这块的问题越来越明显。你的使用体验完全跟着开发者的心情走。开发者心情好、社区活跃，项目就稳一点；开发者忙了、累了、不想干了，项目就扔在那里。你不能道德绑架，不能催，不能抱怨——“你要会你自己改，不会改就等着”是一句政治正确的话，但落到具体的使用场景里，就是你的项目被一个没人修的bug卡住，卡上几个月甚至几年。连Microsoft、Cloudflare这样的大公司在2025年都频频出问题，你凭什么指望一个“last commit: 5 years ago”的开源项目能给你兜底？

以前遇到这种情况，除了忍，没什么办法。“你要会你自己改”是一句废话——我要是有那个精力和能力，我早改了。

但现在不一样了，2026年的AI，把“你要会你自己改”从一句风凉话，变成一句可行的建议。

对于一些中小型的项目，我以前的工作流经常是这样的：有一个需要实现的idea，找一个开源项目，功能大致符合需求，但有些细节不对，下下来部署，不麻烦将就能用就行，有问题就提issue不修也罢。现在我可以直接把代码拉下来，让AI帮我分析结构，帮我加功能，帮我修bug；我可以把需求丢给AI，构建框架，然后让AI顺着框架搭上半个钟头的程序，自己做点别的等着验收就好——只要给AI的权限控制好，别让它删库跑路，这件事的风险几乎为零。门槛被AI拉低到了一个以前不敢想的程度。

我以前觉得，“造轮子”是倒退——是把别人已经抽象好的东西，重新拆开，重新折腾一遍，只适用于教学、理解算法的过程。

现在我觉得，AI加持下，“造轮子”其实是换了一种“抽象”。以前我们用别人的轮子，是把“实现细节”抽象掉，让自己只关心业务逻辑。现在我们自己造轮子，是把业务逻辑交给AI，AI交付符合需求的产品，实现细节也还是被抽象掉了，省去了“reinvent the algorithm”的过程的同时，造了一个更贴合自己需求的轮子。

现在的AI还比较蠢，小型项目的工作流基本是：我提出需求——AI分析框架——我提出算法——AI实现算法，人还需要一些算法的思考，不过离纯粹的“自然语言编程”的极端抽象模式不远了。

草台班子

所以你看，世界确实是个巨大的草台班子。

开源项目会停更，维护者会疲惫，公司会因为商业压力改变方向，大厂也会犯低级错误。AI的加入并没有让这一切变得更稳定，反而在某些层面上增加了噪音，无论台上还是台下，都并不专业，也谈不上完美。

但真正重要的不是这个班子是否专业，而是它为什么还能运转。过去我更愿意把这种运转归因于理想主义——开源精神、共享文化、技术信仰。这些当然存在，也确实支撑了很长一段时间的协作生态。但当参与得足够深之后，你会发现系统的稳定并不是来自神圣性，而是来自大量普通人的持续投入。有人愿意修bug，有人愿意写文档，有人愿意回答issue，有人愿意在空闲时间维护项目。系统并不稳固，它只是被一群人不断修补着，勉强维持运转。

当你意识到这一点，对开源的态度自然会发生变化。它不再是需要仰望的高地，而是一种人与人之间松散协作的结果。它不保证质量，不保证持续，不保证公平，它只提供一种可能性。AI的出现改变的，也不是世界是否草台，而是个体在这个结构中的位置。

这大概是我在2026年做AI开发时最真实的感受：世界依旧松散，系统依旧脆弱，但个体的可操作空间变大了。理解代码更容易，修改功能更可行，甚至在必要时重写一部分系统也不再遥远。个人未必能搭起整座舞台，但至少可以试着在关键的地方钉上几颗钉子——不保证万无一失，但至少让自己站得更稳一点。