今天本来只想安静地尝试一下已经停止维护的 AI 绘图项目 Paintsundo。但万万没想到，这个决定让我经历了一场AI项目对人类灵魂的霸凌。在这一地鸡毛的背后，是一个困扰 AI 社区已久的真相：现代 AI 项目的部署逻辑，简直蠢得令人发指。为什么？

这些项目通常是论文而非软件

大多数 AI 项目的首要身份是“学术论文的附属品”。对于研究者来说，只要代码在他们的那一台工作站上跑通并得出实验数据，任务就完成了。为了让这个看起来像个计算机科学项目，代码打包一扔上Github，然后留下后来人对着Last Edit:5 years 发呆。观察一个典型的 AI 项目目录（如Paintsundo）：你会发现代码逻辑与运行时环境（Python 解释器、DLLs、甚至完整的虚拟环境）被暴力地揉杂在一起 。这种做法缺乏现代软件工程最基本的关注点分离（Separation of Concerns）。它不是被“开发”出来的，是被“堆砌”出来的。

为什么Requirements.txt在大规模上是糟糕的设计

在软件工程的大规模尺度上，requirements.txt 是一个极其糟糕的设计。它表面上声明了依赖，实际上却留下了巨大的黑洞：这玩意既可以从pip锁定，也可以让用户自己填，并且，软件版本不是强制填写的！如果作者没写版本号，当一个像 HuggingFace 这样更新极快的库发布了 破坏性更新时，你的部署梦会在引入库的一瞬间破碎。

并且它只管 Python 包，不管你系统里的 libffi、libssl 或者是多媒体处理必备的 ffmpeg。你几乎可以想见这能带来灾难，requirements并不是真正全部的requirements。

CUDA生态的混乱并不是nVIDIA的傲慢，而是AI项目跨越硬件HAL，算法，软件前后端的必然

AI 模型并不是单纯的 CPU 指令，它是一个横跨了硬件抽象层（HAL）、底层数学计算库（cuDNN）、编译器驱动以及前端算法框架的复杂系统。当一个项目要求 torch==2.2.2+cu118 时，它实际上是在要求你的整个系统状态必须精确对齐到某个特定的时空切片。甚至把系统作出

为什么可复现的部署非常重要，怎么解决依赖地狱。

为了可复现，其他语言是怎么做的，代价是什么？。

为什么Nix和函数式编程是天才般的点子。

Nix生态：如何从Nix走出Nix。