一行代码没写，他用AI造出2MB包管理器

一个27年工龄的软件工程师，做了一款JavaScript包管理器，全程没写、甚至没读过一行代码。项目叫jpm，能在npm、pnpm、yarn和bun项目里跑。更离谱的是，他让AI自己写了TLS、crypto和http模块，只为了把体积压小。第一个版本，一个下午就完工了。

他自己说得很直白：那个状态下，他不该信它，别人也不该信它。真正让jpm变得可信的，是后面那五天。

事情的起点是一档YouTube播客。主持人Wes、Scott和CJ在节目开头聊到upm，一款用JavaScript写的、又快又小的包管理器。他第一反应是"小"这个说法站不住——你总得带上Node.js运行时。upm的作者Pooya是JavaScript生态里公认的好工程师，做了一堆好工具，想做得比他更快并不容易。但当时他正在用Opus 5.5，被这个模型的表现震到了。既然那么多工具都用Rust重写，播客里甚至拿这事开玩笑，那不如自己也用Rust做一款又小又快的包管理器。

那天下午忙完本职工作，他开了个终端标签页，问Claude：把upm重写成Rust CLI需要做什么。看完方案摘要点了头，AI就开工了。大约45分钟，一个能跑的版本出来了，用了一堆第三方Rust crate，体积偏大，而且只在一个很小的package.json文件上测过。为了瘦身，他让AI拆解体积来源，到当晚结束时，jpm有了自研的HTTP、JSON、crypto和TLS模块，二进制小了一大截。他给AI的指令是：只写需要的部分，但要用别的项目的测试或自己的模糊测试狠狠测。

接下来是"氛围编程"玩家们集体略过的那部分。当时它只在Windows WSL2的Linux上、对着一个小package.json跑通过，Mac没测，Windows没测，大项目一个没碰。于是他让AI写了个加固脚本，拿100个、后来加到166个大型公开项目来试：先用jpm安装并构建，再用这些项目原本用的包管理器装一遍做对比，能跑测试的连测试一起跑。Windows命令行和PowerShell各来一遍，Mac上另开一个agent做同样的事。五天后，结果是261个合并的PR，和一个被反复锤炼过的包管理器。

他没写代码，但做了大量细小的决策。Claude说更快的锁文件格式只能省几毫秒，他还是要求改。Claude想把全局store做成可选功能，他反问：如果99%的包都能用，为什么要可选？于是它成了默认。他还要求，除非明确列在白名单里，否则不许运行脚本，包括依赖的安装脚本——理由是AI现在干了大部分活，批准一个包的脚本前，先让AI审一遍就行。

有两次Claude当面反驳他，两次他都坚持己见。

第一次是TLS。他想把二进制做小，TLS和crypto的crate占了大头。Claude说，这是你永远不该自己写的代码。他回了一句：那是老派的工程思维。现在用的是Rust，Heartbleed那类内存漏洞从根上就不存在，自研版本照样能往死里测。Claude承认自己夸大了风险，并列出能证明它的测试套件：Wycheproof、NIST vectors、x509-limbo、BoGo。他至今仍怀疑这个决定是否明智，也清楚Claude有讨好用户的倾向，说"夸大了风险"可能只是顺着他说。但它确实通过了一堆测试，包括用其他项目真实bug构造的用例。

第二次是HTTP/2。他想要更快的速度。Claude先用curl测了一遍，说没必要做——jpm整个HTTP/1.1安装流程，已经比curl单次HTTP/2下载还快。他还是推。理由是curl要应付所有情况，而jpm只需要对同一个registry发大量GET请求。Claude同意了，两小时后一个能用的客户端就出来了。

然后他们开始测。在他家宽带上，HTTP/2快约17%。在GitHub的runner上，打平或更慢，冷启动装nuxt时最多慢2倍，处理大tarball时CPU多用8%到15%。CI才是安装真正烧时间和钱的地方，而且它让二进制多了60KB。于是他让AI把那3671行全删了。这一局他错了，数字说了算。

也有反过来的情况。jpm可以顺手帮你装Node，他本来想把Node的签名校验藏在开关后面，觉得会拖慢安装。Claude测出来只要15到19毫秒，并说开关意味着没人会打开它。现在它默认开启，他觉得挺好，多了一层安全。

凭什么信一段没人打过的代码？他的答案很具体：Wycheproof、node-semver、pnpm、yarn和bun自己的测试，加上那166个仓库。过程中揪出来的问题包括：

• node-semver自己的测试发现25处jpm判断不一致，比如把^9007199254740991.0.0当成合法范围接受。
• npm-package-arg的测试一开始只匹配154个用例中的117个，a@a.tar.gz被读成了tag。
• 一次安全扫描发现，克隆仓库里的.npmrc能把你的registry token通过它自己的代理发出去，概念验证抓到了Bearer USER-SECRET-TOKEN。现在项目的.npmrc不能再降低安全性。
• 在真实仓库上，jpm与pnpm安装结果不一致的依赖链接从1320降到183，与npm的从614降到14。
• 在测macOS之前，它压根编译不过。

他也清楚，干了这么多年，无论怎么测，没有软件是没有bug的。信任是挣来的，所以他打算在所有项目里用jpm，也愿意处理修复，包括AI提交的PR。但这不代表照单全收——修复必须带测试证明。他不打算关掉PR通道，但会用AI来帮忙审。

目前jpm的可执行文件是2MB，不总是最快，但排在最前面那一档。安全性也是它的卖点之一：不批准就不跑脚本，包不满一天不升级到最新版，以及围绕.npmrc的那套防护。

他也坦白了短板。基准测试规模很小，只有三个仓库，而且它并非永远最快。Windows上装nuxt，Defender扫描把它拖得很惨；macOS上nuxt的热安装，bun和aube赢。如果速度是终极目标，还有改进空间。他们确实在Linux、macOS、Windows上跑了166个项目的安装，Linux上还额外跑了一堆随机项目找bug，但没有在CI和真机上对每一个做性能测试。

jpm完美吗？不完美。他手写27年的东西也不完美，任何人写的都不完美。完美不存在。有的是"够用"、"很好"，和"测到你知道自己处在哪一档"。