我做了一个 Codex 下载站，把最麻烦的一步先解决了

今天早上，我写了一个很简单的静态网站：

codex.waitli.top 它没有复杂的账号系统，也不打算做成一个大而全的工具导航。

我做它，只是想解决一个非常具体的问题：

Codex 和 CC-Switch 到底去哪里下载。

很多人不是不会用，而是没下载成功

最近 Codex 的关注度越来越高，CC-Switch 也成了不少人管理和切换配置时会用到的工具。

但对国内用户来说，真正影响体验的，往往不是安装命令有多复杂，而是安装包能不能顺利下载。

链接散落在不同页面，版本不好找，网络偶尔不稳定。折腾半天之后，工具还没打开，人已经不想继续了。

这类问题看起来很小，却最消耗耐心。

我自己也经常遇到类似场景：想给别人推荐 Codex，第一句话不是介绍它能做什么，而是先解释去哪里下载、哪个文件适合自己的系统、下载失败之后怎么办。

既然每次都要重复，不如把它整理成一个页面。

一个页面，把入口放到一起

所以我做了 codex.waitli.top。

页面目前主要整理了两类内容：

• Codex 的下载入口
• CC-Switch 的下载入口

网站本身是静态页面，没有多余的交互，也不需要注册登录。打开页面，找到需要的工具，直接下载。

我刻意没有把它做复杂。

因为下载站最重要的不是功能多，而是入口清楚、页面打开快、文件能够稳定拿到。

我还给它做了包缓存

只整理链接还不够。

如果下载最终仍然完全依赖原始链路，那么网络不稳定时，用户还是会卡在同一个地方。

因此，这个网站也做了包缓存。

它的意义很直接：尽量减少重复下载对外部链路的依赖，让常用安装包的获取更稳定一些。

当然，缓存不是万能的。软件版本会更新，文件来源和完整性仍然需要认真对待，下载页面也需要持续维护。

但至少，它把最常见、最影响体验的那一步往前推了一点。

静态网站也可以解决真实问题

现在大家谈 AI 编程，常常会想到复杂应用、Agent、工作流和自动化。

但我越来越觉得，AI 编程真正有价值的地方，不只是帮我们做更大的产品。

它也能让一个很具体的念头，在一个早上变成可以直接使用的东西。

发现下载麻烦，就做一个下载页。

发现链路不稳定，就增加包缓存。

不需要先写几十页需求文档，也不用一开始就考虑商业模式。先把自己和身边人反复遇到的问题解决掉，网站就已经有价值。

codex.waitli.top 现在还只是一个简单的静态页面。

但它解决的问题也足够清楚：

少找几个链接，少经历几次下载失败，更快地把 Codex 和 CC-Switch 用起来。

很多工具并不缺功能。

它们缺的，只是一条更顺畅的到达路径。