用了半年 AI 写代码，最烦的不是代码，是环境

你有没有过这种经历：同事发来一个项目，你 clone 下来，npm install，npm run dev，跑起来了，挺好。你顺手把改动提交了，却完全没注意这次 npm install 把 package-lock.json 重写了一遍。

几天后同事说"我本地跑你这段代码是坏的"，你这边却一切正常。你翻 Git 历史------谁都没动过代码啊。最后才反应过来：项目要求 Node 20，而你全局是 Node 18，自带的 npm 版本不同，把 lockfile 重写了，依赖树被悄悄换了一版；更阴的是里面还有包写着 engines: node>=20，而 npm 默认只警告、不拦截，于是它一直跑在一个"勉强能跑、但不是该跑"的环境上。

这种事不是偶尔发生。只要你同时维护超过两个项目，或者你的项目涉及不止一种语言，它就一定会发生。而我，恰好两个都占了。

于是我写了个小工具，叫 PVM。本来只想管管自己的 Node 版本，结果越写越上头，最后变成了能统一管理 9 种运行时（Node / Python / Rust / Go / Bun / Deno / Git / pnpm / Yarn，且还在持续扩展）的跨平台版本管理器。写出来分享，聊聊它到底是怎么被逼出来的，以及它怎么把这些坑填了。

切来切去是表象，"无感"才是真坑

我同时在维护三个项目：一个是 Node 18 的老项目，一个是 Node 20 的新项目，还有一个是 Python + Node 混合的。每天在三者之间横跳，全靠脑子记"现在这个项目用哪个版本"。

但脑子是会忘的。尤其当你半天在改 A 项目、突然被喊去救 B 项目的火、救完回来继续改 A------那个版本切换，十次有三次会忘。

忘了会怎样？你在 Node 20 的环境里给 Node 18 的老项目跑了一次 npm install，package-lock.json 被高版本 npm 重写后顺手提交了。CI 用 Node 18 的 npm 照着这个被改写的 lockfile 安装，装出了一棵不一样的依赖树------CI 红了，或者更糟，CI 没红但同事的机器开始偶发报错。你心想这不刚跑过吗，再一看，是环境把依赖偷偷换了一版。

更阴的是构建脚本本身 也会踩这个坑。项目的 npm run build 里有一段构建期脚本，依赖 Node 20 才有的 API（比如用 crypto.hash() 算资源指纹）。你全局是 Node 18，但 npm 的 engines-strict 默认是关闭的------它只打印一句警告，不会拦你。于是这段脚本在 18 上走了降级分支，产出的资源文件名 / hash 跟预期不一样，构建全程 0 报错。你本地预览没覆盖到那条路径，上线后 CDN 上老资源没被替换，样式悄无声息地裂了。

这就是"无感"------它没崩溃，所以它最危险。你以为一切正常，其实代码一直跑在错误的环境上。

PVM 的解法就是把"环境"从全局拿掉，绑在项目上 。你在项目根目录放一个 .pvmrc：

node 20.11.0
python 3.12.0

进这个目录，node 自动就是 20.11.0，python 自动就是 3.12.0。切到隔壁项目，自动换。不用记，不用切，不用装任何东西。

项目隔离，就没有依赖问题

上面那套机制真正解决的，不是"切换方不方便"，而是项目之间的隔离。

每个项目的版本都写在自己的 .pvmrc 里，彼此完全隔离，互不污染。A 项目升级了它的依赖、换了它的运行时版本，绝不会因为全局环境被谁改了一下，就把 B 项目连带带崩。每一个项目用的都是自己锁定的版本，谁都改不了全局，也就谁都坑不到别人。

怎么做到的？~/.pvm/shims/ 里面那些叫 node、npm、git 的文件，看起来跟真的二进制一样，实际全是同一个小程序的硬链接。你敲 node -v，这个小程序先抬头看看自己名字是 "node"，然后去读当前目录的 .pvmrc，找到版本，把命令转发给藏在 ~/.pvm/installs/ 里的真身。

所以无论你、你的 AI 助手、还是 CI，进对了目录就自动用对了版本。AI 压根不需要去"修环境"------它连环境是什么版本都不用知道。前面说的那些"无感 bug"------打包工具跑在错版本上、依赖被悄悄重写------从源头上就不存在了，因为版本是项目自己说了算，全局环境已经没有"被改"这件事了。

AI 最好的辅助，是别让它卡在环境上

现在 AI 时代，真正的生产力是 skill。你让模型"把这几张图片转成 PDF"，它随手写个 Python 脚本跑一下就完事------这本该是一两分钟的事。

但前提是：Python 得在。

现实往往是：模型生成了 skill、你也下载装好了，一运行------"command not found: python"。它开始哐哐装环境，装完版本不对再换，顺手把你刚配好的别的东西也动一下。本来一两分钟能搞定的事，因为环境问题你要陪它跑半天。你没装环境，下载了这个 skill 也跑不起来------明明该一两分钟，结果被环境拖成几个小时。

更尴尬的是"装逼现场"：妹子让你帮个忙转个图，你信心满满开干，结果模型先把运行环境装了五分钟还在失败，妹子站旁边越等越急，最后忍不住怀疑：你这也不行啊。明明是环境的事，锅却甩给了你。

这事归根到底还是那句话：多个语言 + 多个版本 + 多个项目 + 全局环境 = 确定性灾难。

PVM 的解法直接得多：一种语言一个插件，插件只管一件事------去哪下、怎么装、装完怎么验证、要拦哪些命令。Node 是一个插件，Python 是一个插件，Rust、Go、Bun、Deno、Git、pnpm、Yarn......都是。

而且你不用为了跑一个 skill 就把半个互联网搬下来------装一个 PVM 就够了。

# 一个工具，随装随卸，要哪个运行时就 use 哪个
pvm use node@20 python@3.12 bun@1.1 rust@1.78 go@1.22 git@latest

一把梭全写进 .pvmrc：

node 20.11.0
python 3.12.0
bun 1.1.0
rust 1.78.0
go 1.22.0
git 2.55.0

提交到仓库。skill 作者只需要说一句"cd 进来，剩下的交给 PVM"。你用的时候也不需要先装一圈环境，cd 进来版本自己就对了；AI 也别折腾了------它进目录的时候，运行环境已经秒级就位，直接跑脚本就行。无论是给妹子转图，还是给同事跑构建，环境都在，不用现装，不会翻车。

它是插件架构，那天你想加个 Zig 或者 Mojo，照着现有插件抄一份就行，核心代码一行不动。它不是"管 Node 的工具顺便管点别的"，它从一开始就是按"还会再多一种语言"设计的------支持 9 种，而且会越来越多，覆盖大部分编程需求。

市面上不是没方案，是不够用

写 PVM 之前，这些工具我都用过。每一个都在自己的领域做得不错，但放到上面几个场景里，各有各的力不从心：

工具	管什么	多语言	进目录自动切	Windows 体验
nvm	仅 Node	❌	❌ 需手动 nvm use	一般
fnm	仅 Node	❌	✅ .node-version	一般
Volta	Node + pnpm/yarn	半吊子（Node 生态焊死在核心里，加不了新语言）	✅ package.json volta 字段	一般
pyenv	仅 Python	❌	✅ .python-version	不原生支持
rustup	仅 Rust	❌	❌	一般
asdf	多语言（插件）	✅	✅ .tool-versions	坑多（shim 用 bash 脚本，Windows 兼容性靠运气）
proto	多语言	✅	❌ 全局 proto.toml	一般
PVM	9 种，可扩展	✅	✅ .pvmrc，进目录自动生效	主力开发平台

说几个关键差异：

"进目录自动切"这件事，nvm 做不到。 你每次切项目都得手动 nvm use 18，忘了就翻车。fnm 和 Volta 能做到，但它们只管 Node------你的 Python、Rust、Go 还是散落在别的工具里。PVM 是一把锁死所有语言，且项目间完全隔离，进目录就走，没有任何多余动作。

asdf 看起来很全能，但 Windows 上它靠 bash 脚本做 shim。 如果你主力是 Windows，这意味着你得装 WSL、Git Bash 或 MSYS2 来兜底，性能差不说，还时不时冒出编码问题。PVM 的 shim 是原生硬链接------不依赖任何 shell，Windows、macOS、Linux 一套逻辑。

Volta 把 Node 生态焊死了。 它管 pnpm、yarn 是因为它们"属于 Node 生态"。但如果哪天你想让它管 Bun（一个独立的 JS 运行时，不是 Node 的附属品），它做不了。PVM 不管你是哪个生态，实现了 RuntimePlugin 接口就能管，跟 Node 没有绑定关系。

而且 PVM 是"装一个就够"------不是一次塞给你一堆工具。 随卸随装，要什么运行时 use 什么，不要的 uninstall 掉，干净利落。一个工具覆盖 9 种运行时，后期还能继续扩，大部分编程需求都兜得住。

所以这些工具的问题不是"做得不好"，是它们各自只解决了问题的一部分。一个项目搞下来，你手上还是三四个工具同时在跑------然后哪天 AI 动了一下全局环境，你又得挨个排查。

PVM 就是想把"三四个工具"变成"一个"。

如果你用 Windows，多聊两句

我主力是 Windows。写过 Windows 桌面软件的人都知道，有些坑是 Windows 专属的，别的平台碰不到。

系统 PATH 压你一头。 你装了 Node 18，兴冲冲 node -v------怎么还是 12？因为 Windows 的 PATH 合并顺序是"系统 PATH 在前，用户 PATH 在后"。系统里那个早年间装 nvm 留下的 node.exe，优先级永远比你的用户级 shim 高。

PVM 的处理方式：检测到 D:\node、D:\nvm 这类冲突路径，弹个 UAC，直接把 pvm 的 shim 插到系统 PATH 最前面------排在 nvm 前面，排在任何东西前面。点一下确定，重启终端，pvm 接管。旧的 nvm 路径留着不动，你确认 pvm 没问题了再手动清理。

装了 Git 却没有 bash。 你通过官方安装器装的 Git for Windows 才有完整的 Git Bash（包含 bash.exe、SSH 等），VSCode 以此来检测"这台机器能不能用 Git Bash 终端"。如果 git 是裸下载的，没有 bash，VSCode 就看不到 Git Bash。

PVM 的做法：如果你已经用安装器装了 Git（默认 C:\Program Files\Git），pvm use git 不会重新下载 。它检测到你的系统 Git，直接纳管------建个目录链接指向它。你的 bash 还在，SSH 配置还在，但现在可以跟其他运行时一样用 pvm use git@2.50.0 切版本了。

上手

# 下载一个文件，丢进 PATH
pvm setup                          # 一分钟

cd your-project
pvm use node@20 python@3.12         # 装 + 锁，一行
git add .pvmrc && git commit -m "lock runtimes"

完。你同事（和你的 AI 助手）clone 完 cd 进来，版本自动对。没有 README 里的"请确保你装了以下......"，也没有 Slack 上的"你这个项目用的是什么版本来着"。想换个版本？改 .pvmrc 重新 use 即可；某个运行时不想要了？pvm uninstall 掉，项目依旧隔离干净。

哦对，这工具真的只有一个文件 。下载下来就一个 pvm.exe（或 pvm），跑 pvm setup，~/.pvm/shims/ 里自动长出 node、npm、git、python......全是这个小程序的硬链接，零额外磁盘。Windows、macOS、Linux 通用。

几个你可能想问的

已经在用 nvm，要卸吗？

建议卸。虽然两个能共存，但 PATH 里只能有一个 node 先生效。家里装两套智能开关，灯是能亮，但你永远不知道现在这盏灯是哪个开关在控制。把 nvm、fnm、直接装的 Node、直接装的 Python 全清干净，一个工具管所有。pvm setup 会帮你检测并清理系统 PATH 里的残留路径。

我的 .nvmrc 还能用吗？

不建议。pvm 只认 .pvmrc。多个版本配置文件共存的时候到底谁说了算，排查起来极其痛苦。一个项目一个入口，干干净净。

跟 Volta / fnm 比呢？

最大的区别：pvm 不是"Node 版本管理 + 附赠几个别的"。它是从一开始就按"管任意运行时"设计的插件架构，加新语言不动核心代码。多语言项目、AI skill、构建工具版本错配这类场景下，这个差距会越来越大。

最后

写这个工具之前，每次被环境问题坑了，我都觉得"是我自己不小心"。

后来发现不是我的问题------是这个行业在"管理运行时版本"这件事上，一直缺一个简单好使的答案。尤其 AI 助手越来越多、项目越来越杂、语言越来越碎之后，这个洞被放大了：你以为是代码 bug，其实是环境在悄悄作怪；你以为 AI 不行，其实是它卡在装环境上了。

PVM 做的事就这么几件：把环境隔离在每一个项目里、锁定版本、写进文件、提交仓库、进目录自动生效。不用下一堆工具，装一个就够，随卸随装，支持 9 种并还会更多。简单，但省下来的时间是真的。

仓库 github.com/Lycorxy/pvm，官网 lycorxy.github.io/pvm，MIT 协议。v0.0.1，还在打磨，有 bug 欢迎提 issue。

你被环境版本坑得最惨的一次是什么？评论区聊聊。