开发者批 npx skills 安装器硬编码超时导致大仓库无法安装

最近，我被硬编码的超时设置逼疯了。这些静默、随意、无法配置的时间限制被开发者们烤进工具里，而他们显然这辈子都没经历过需要等待超过 200ms 的事情。

如今 coding agent 无处不在，人人都在用 skill。最流行的添加方式是通过 vercel-labs 开发的包，而首选集合是 awesome-copilot——一个精选 skill 集合，在我写这篇文章时已有 30K+ star。但我用不了它。仓库太大了，npx skills 安装器直接卡死然后挂掉。

vercel-labs/skills 仓库从二月份就有一个未关闭的 issue #278，没人回应。我很乐意提一个 PR 自己修好它。我只需要有人承认这个问题的存在。

有配置选项吗？--timeout 参数？环境变量？没有，什么都没有。

我找到的变通办法？先手动 clone 仓库，然后从本地副本安装。基本能用。只不过现在 skills-lock.json 指向了我机器上的一个路径。我的同事没法用。每次想更新 skill 我还得手动更新本地副本。一个变通办法引出了一堆新问题。

然后是 Docker Gordon，Docker 内置的 AI 调试助手。概念不错。我当时在排查一个容器构建问题，那种需要反复迭代的：调整、重建、检查、重复。我从没用过 Gordon，但错误出现时，它附带了一条建议让我试试 Gordon，于是我就试了。

只不过 Gordon 有一个硬限制：如果你的容器没能在两分钟内完成构建，它就放弃了。会话终止。你得从头再来。

两分钟的构建时间听起来很充裕——如果你处在快速环境中，有热缓存和已拉取的基础镜像。但如果你正在通过较慢的连接拉取全新的基础镜像呢？在调试一个包含多个重量级层的多阶段构建呢？想都别想。Gordon 早就走了。

没有任何办法配置这个。没有 GORDON_TIMEOUT=600 环境变量。没有 --build-timeout 参数。什么都没有。这个工具就是假设两分钟等于永恒，如果你需要更多时间，那是你的问题。

开发者们通常在 fast machine 上工作，在办公室或家里有千兆连接，在城市里有世界级的基础设施。他们构建工具时设定的超时默认值反映的是他们自己的体验。然后他们把这些工具发布给全世界，没有任何可调的旋钮。

问题是，超时是必要的。无限等待是糟糕的。挂起的进程是糟糕的。我不是在反对超时。我反对的是不可配置的超时。反对的是那种隐含的信息：如果你在 60 秒内做不到，那是你的环境有问题，不是我的假设有问题。

这并不难。这是对用户的基本尊重。

我在开罗写这篇文章。我的网络还不错，比世界上很多地方都好。但它不是 1 Gbps 对称光纤。它不在 npm registry 镜像旁边。clone 一个大仓库需要时间。拉取一个 Docker 镜像需要时间。这些不是故障。这是物理规律。

当你的工具在 60 秒后静默死亡，且没有任何办法修改这个限制时，你构建的不是一个面向世界的工具。你构建的是一个面向你办公室的工具。

这件事比大多数开发者承认的更重要。全球开发者社区不在旧金山、阿姆斯特丹或伦敦。它在拉各斯、在卡拉奇、在开罗。它是那些用 4G 连接的人、用共享宽带的人、因为最近的 CDN 边缘节点在 50ms 之外而不是 5ms 之内而承受真实延迟的人。

当你假设快速连接时，你做的不是一个中性的技术决策。你在表明谁的经验才重要。

我不认为有人是恶意这么做的。我认为这是一个盲区。你的网速快，所以 60 秒超时感觉已经很慷慨了。你的机器性能强，所以 2 分钟的构建窗口似乎绰绰有余。

但请：在你发布一个超时设置之前，问问自己：

然后加一个配置选项。一个环境变量。一个参数。就这么简单，就能从“这个工具对我没用”变成“这个工具对我有用”。

正如 Bruce Lawson 曾说过的：这是 World Wide Web，不是 Wealthy Western Web。

Web 以及我们构建在它之上的工具是属于每个人的。让我们开始这样行动吧。