“可是我电脑上是好的啊！”——环境与依赖

“But It Works on My Machine!” — Environments and Dependencies

先说一个几乎每个 vibe coder 都会经历的剧本。

你让 AI 写了个程序，在自己电脑上跑得很好。你兴冲冲地把它发给同学，或者按第二篇的方式部署到服务器上——跑不起来。报错刷了一屏，或者干脆一动不动。

于是你说出了程序员世界里最古老的那句话：

“可是我电脑上是好的啊！”

这一篇就讲：为什么会这样。先剧透一句答案：你的程序，从来不是一个人在跑。

一

在你想象中，程序可能是一份代码、一个文件，双击就能运行。但现实是：它站在几百个“别人写好的程序”的肩膀上。

比如 AI 帮你写的那个小工具里，“把时间显示成 2026 年 9 月 29 日”这个功能，大概率不是从零写的——而是调用了别人写好、免费公开的代码。这类东西叫库（library）：别人造好的轮子，你直接用。

你的程序用到的所有库，统称它的依赖（dependencies）——“要跑起来，先依赖它们装好”。而且依赖还会再生依赖：你用的库 A，自己又依赖库 B 和库 C……一个中小型项目展开几百个依赖节点，很正常。

所以 AI 交给你代码时，附的那句：

npm install

干的就是这件事：照着项目自带的依赖清单（Node 项目里叫 package.json，Python 项目通常是 requirements.txt），把这几百个库一次性下载、装好。它就像菜谱最后那页“材料表”——菜谱给你了，材料得自己备。

装好库就万事大吉了吗？还没有。库自己也是程序，它们也要“住”在某个东西上面：

这个“让程序能跑起来的基础设施”，叫运行时（runtime）。而且版本还讲究：库 A 要求 Python 至少 3.10；库 B 在某个新版本上有已知问题；你电脑里是 3.12，同学电脑里是 3.9——于是“我电脑上是好的”。

再往下，运行时还住在操作系统上（还记得第二篇买服务器时选的 Ubuntu 吗？那就是“系统”这一层）。系统不同、装过的东西不同、各种配置不同……把整条链画出来：

你的程序
 ↓ 需要
一堆库（依赖）
 ↓ 需要
某个版本的运行时
 ↓ 住在
某个操作系统 + 各种配置
 ↓
任何一环不对 → 跑不起来

所以“在我电脑上能跑”，翻译过来其实是：**我电脑上，这条链的每一环恰好都对上了。**换一台电脑，几百个环节只要有一个不同，整条链就断。这不是你笨，是链条本来就长。

顺带一提，Python 世界还有个常见坑：两个项目共用一套库，互相污染。所以你会听到“虚拟环境”这个词——给每个项目一间独立的小房间，各用各的库。具体操作问 AI 就行，你只需要知道它是干这个的。

现在，你可以理解一个如雷贯耳但可能一直没懂的名字了：Docker。

传统解法是“修链条”：缺库装库、版本不对调版本，一个个变量去对齐——修好这台机器，下一台重来。Docker 的思路是：别修了，整个打包。

把程序、它的几百个库、合适版本的运行时、连同配置，一起塞进一个标准化的箱子里。以后这台程序搬到任何机器上，都自带全套环境——箱子外面的人，完全不用管箱子里是什么。

这个名字不是比喻，它真的来自运输集装箱：早年码头装卸，货物千奇百怪，又慢又容易损坏；集装箱出现后，船和卡车只认箱子，不管里面装的是什么。Docker 就是软件世界的集装箱。同理：

这三个词你不需要会用，眼熟就行。因为 AI 以后给你的部署建议里，十有八九会出现“用 Docker 部署”——现在你知道了，它不是什么高深技术，就是在解决“环境”这个问题。

你现在就可以看看自己电脑里住着什么运行时。打开第三篇那个终端：

python --version   # 装没装 Python？哪个版本？
node --version     # 装没装 Node？

报”command not found”就是没装；报出版本号，你就认清了自己那条链上的这一环。

最后给你一张速查表。以后看到这些报错，先别慌——它们八成是环境问题，不是程序写错了：

ModuleNotFoundError: No module named 'xxx'——清单上的材料没装：要么没跑 npm install / pip install，要么装进了别的“房间”；
command not found: python——运行时压根没装；
xxx requires Python >=3.10——版本不匹配，链条上某一环对不上。

这类问题有个好处：解法高度标准化。把报错原样发给 AI，它基本都能给出对应的安装或调整命令。你真正需要的是判断力：认出“这是环境问题”，然后别自己乱装乱删——一个变量一个变量地动，才看得清哪个起了作用。

回头看这一篇：程序跑不起来，往往不是“代码有 bug”一句话能概括的——是几百个环节里，有一个变量不同。Docker 的全部哲学，浓缩成一句话：

当变量太多时，尝试控制变量。

这个思维比 Docker 本身值钱：排查问题，一次只改一个地方再试；做对比，让别的条件全部一样；搬一个项目，把环境原样打包带走。下一篇——也就是这个系列的最后一篇——讲剩下那半剧情：环境全对，程序还是报错。报错不可怕，可怕的是瞎猜：怎么和 AI 一起，把真正的凶手找出来。