KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

03 · 拿到别人的代码，怎么在你机器上跑起来 — keel 龙骨

## 现场：装了包，还是同一行红字

现场：装了包，还是同一行红字

你从 AI 那里拿到一段五行的代码，第一行是：

import requests

跑它，红字最后一行是：

ModuleNotFoundError: No module named 'requests'

好吧，缺包。你照着提示敲了 pip install requests，命令行最后一行还写着
Successfully installed ...——看起来装成功了。回到刚才的目录再跑一次：

还是那一行红字。

问题不在于装了没有，而在于：你装的那个 pip，和刚才跑代码的那个 python，可能根本不是同一个。

一、它是什么

一句话：一段代码要跑起来需要三样东西——一个解释器、这段代码、以及它 import 的那些包；venv 的作用是让「装」和「跑」用的是同一个解释器。

pip install 从来不是「装到这台电脑上」，而是装到某一个具体的解释器里。
一台机器上可以有好几个 Python（系统自带的、你后来装的、编辑器自己带的），
装进 A、用 B 跑，结果就是「明明装成功了，还是说找不到」。

虚拟环境（venv）做的事很小：给一个项目圈一份专属的包目录，并给它留一个入口。
以后在这个项目里，pip 和 python 都是这一份。

名词	一句话	类比
解释器	真正执行你代码的那个程序	会说这门语言的那个人
包	别人写好、你直接 import 来用的代码	已经从菜场买回来的食材
虚拟环境	给这个项目单配的一间储藏室 + 一张专属钥匙	公共厨房里属于你的那间小储藏室

二、跑一遍完整流程

四步，顺序不能换（Windows 写法，macOS / Linux 见下面注）。下面每一步的输出形状都以 CPython 3.13.14（Windows）为准。

python -m venv .venv              # 1. 建：在项目目录下生成一个 .venv 目录
.venv\Scripts\activate            # 2. 进：让当前终端改用这一份解释器
pip install requests              # 3. 装：包进的是刚才那一份
python app.py                     # 4. 跑：用的是同一份，于是找得到

每一步「成功」长什么样：

步骤	成功的形状
1 建	目录里多出一个 `.venv/`，里面有 `Scripts/`（Windows）或 `bin/`（macOS / Linux）。没有回显，安静的
2 进	命令行提示符前面多出 `(.venv)`。看不到它就说明没激活——这一步最容易被跳过
3 装	最后一行 `Successfully installed certifi-… charset_normalizer-… requests-…`；版本号必定不同
4 跑	只出你自己 `print` 的内容（见下一段）

macOS / Linux 的激活命令是 source .venv/bin/activate，其余三步一样。

现在看这一章最值钱的一处对照。同一个 app.py，只换解释器：

（激活 .venv 后）            python app.py  →  2.34.2
（退出 venv，用系统 python）  python app.py  →  ModuleNotFoundError: No module named 'requests'

包只存在于你装它的那一份解释器里。 这就是上面那行红字反复出现的原因：
不是没装，是装到了别人身上。

三、它不是什么

不是虚拟机。 venv 不模拟硬件、不装操作系统，它只是一个目录加一个入口；
删掉这个目录就等于把这份环境整个撤销。
不是「pip install 了就有用」。 它装进的是当下这个解释器；换一个解释器跑，等于没装。
不是「requirements.txt 会自动装」。 它是一张清单（包名==版本），
别人拿到你的代码要照着它装一遍；文件本身不会替你做任何事。

读完你能做什么

把「建虚拟环境 → 装依赖 → 跑起来」这四步走通一次，并说出每一步「成功」长什么样；
再看到 ModuleNotFoundError 时，先问装到哪一份解释器里了，而不是反复重装；
知道 .venv/ 这个目录不该提交进 Git，该提交的是 requirements.txt。

下一步：到这里你已经能跑自己写的、也能跑别人给的了。
最后一章是一张带走的速查表，外加一个更重要的问题：什么情况下不该用 Python。

进入 keel 阅读