1分钟把codex和workbuddy做的东西部署上线丨0配置、不动 DNS、不影响旧域名

哈喽，大家好

我是阿星！

实测一个部署 Skill 后，我把 Next.js 静态主页发布到了 Cloudflare Pages。

很多人第一次看到这类“一键部署” Skill，都会有一个很自然的疑问：

Cloudflare 不是要账号、Token、Account ID 吗？为什么命令里什么都没填，网站就能上线？　ㅤ

我这次拿本地的 homepage 项目做了一次完整实测。

它是一个 Next.js 主页，但已经通过静态导出生成了 out/ 目录。最终网站上线在：

　ㅤ

　ㅤ

原有的 xxxx.work自定义域名 没有被覆盖，DNS 也没有改。更重要的是：这次在国内网络环境下也实际打开验证过。

先说结论： “不用填 Cloudflare 参数”不等于“不需要 Cloudflare 账号”，而是把认证和部署参数拆开了。

首次通过浏览器登录授权，之后 Wrangler 会在本机复用这个授权；Skill 再负责识别构建目录、创建 Pages 项目、上传文件和验证地址。

　ㅤ

　ㅤ

先分清：它发布的是新站，还是覆盖你的主域名？

这件事必须先讲清楚，不然很容易不敢按回车。

Cloudflare Pages 有两层地址：　ㅤ

　ㅤ

只要没有进入 Pages 项目的 Custom domains 页面绑定域名，也没有改 DNS 记录，发布只会得到一个新的 *.pages.dev 地址。

这也是我建议第一次实操时的标准做法：先让新站独立上线，确认内容、访问速度和链接都没问题，再考虑要不要绑定自己的域名。

如果你以后想绑定子域名，例如 home. xxxx.work自定义域名，需要在 Pages 项目里走一次“添加自定义域名”的流程。Cloudflare 托管 DNS 时，确认后它可以创建对应记录；

否则要在当前 DNS 服务商处手动添加 CNAME。这个动作和首次发布是两件事，Skill 不会替你默认执行。　ㅤ

　ㅤ

　ㅤ

为什么命令里没有 Token 和 Account ID？

答案是 OAuth 登录态。

Cloudflare 的命令行工具 Wrangler 支持在本机执行：

...

# 浏览器完成 Cloudflare OAuth 授权
wrangler login

授权成功后，Wrangler 会保存本机凭据。

下一次再执行部署时，它会根据当前登录账号找到可用的 Cloudflare Account 和相应权限，因此命令里不必暴露：

　ㅤ

这就是“一键”的本质：把一次性的身份认证前置，而不是让每次部署都复制敏感参数。

　ㅤ

　ㅤ

这个 one-click-deploy Skill 实际做了什么？

这个 Skill 并不是“把任意项目一键变成网站”。它的定位更准确：把已经构建完成的静态目录发布到 Surge 或 Cloudflare Pages。

一句话说，当你使用 wrangler 命令时，你是在将静态资源（如 HTML、CSS、JS 文件）部署到 Cloudflare Pages 平台。这个命令会处理构建输出目录（如 dist 或 build），并将其上传到 Pages，生成一个可通过 *.pages.dev 访问的站点。

以 Cloudflare Pages 为例，脚本会依次做这些事：

1. 1.找到可发布目录：优先识别指定的 --output-dir，否则尝试 dist、build、public 等目录。
2. 2.检查目录中是否有 index.html，并拒绝上传 .env、私钥、证书、凭据文件等敏感内容。
3. 3.检查 Wrangler 是否可用、当前账号是否已授权。
4. 4.查询 Pages 项目；项目不存在时，先创建项目并设置生产分支。
5. 5.再上传静态文件，得到 *.pages.dev 地址。
6. 6.最后通过 HTTPS 验证地址可访问。

　ㅤ

　ㅤ

实操：把本地 Next.js 静态主页发布出去

我的项目目录是：

...

/Users/xingyang/Downloads/code/homepage

项目已经配置了 Next.js 静态导出：　ㅤ

...

// next.config.ts：生成可直接托管的静态文件
const nextConfig = {
  output: "export",
  images: { unoptimized: true },
};

构建后，真正需要上传的是 out/：

...

homepage/
├── app/                 # 源码，不直接上传
├── package.json
├── next.config.ts
└── out/
    ├── index.html        # 静态站入口
    ├── 404.html
    └── _next/            # JS、CSS 与静态资源

　ㅤ

先在本地构建：　ㅤ

...

# 生成静态站点产物 out/
npm run build

然后通过 Skill 发布时，核心命令是：

...

# 发布静态目录；--name 决定新的 pages.dev 子域名
one-click-deploy ./homepage \
  --provider cf-pages \
  --name axing-homepage \
  --output-dir out

其中：　ㅤ

• 　ㅤ--name axing-homepage：会对应 axing-homepage.pages.dev。
• 　ㅤ--output-dir out：明确告诉 Skill 上传 Next.js 静态导出结果，而不是源码或 .next。
• 　ㅤ没有 --domain：因此不会碰 xxxx.work自定义域名，也不会碰 DNS。

第一次使用时，如果本机没有 Wrangler，Skill 要求显式加 --install 才会通过 npm 安装，避免工具在后台偷偷安装依赖：

...

# 仅在确认需要安装 Wrangler 时使用
one-click-deploy ./homepage --provider cf-pages --name axing-homepage --output-dir out --install

　ㅤ

　ㅤ

　ㅤ

这次踩到的一个新版 Wrangler 坑

这里有一个截至本次实测才暴露出来的问题，值得单独写出来。

我最开始直接运行了下面这条命令：

...

# 不推荐对“不存在的新 Pages 项目”直接这样运行
npx wrangler pages deploy out --project-name axing-homepage

　ㅤ

当前安装到的 Wrangler 4.120.0 识别出这是一个 Next.js 项目后，尝试把项目迁移到 OpenNext / Cloudflare Workers，并准备：

• 　ㅤ向 package.json 加入 Wrangler 和部署脚本；
• 　ㅤ新增 wrangler.jsonc；
• 　ㅤ安装 @opennextjs/cloudflare。

这和“上传已经生成好的 out/ 静态目录”不是一回事，所以我中止了迁移。随后使用 Wrangler 给出的兼容路径：　ㅤ

...

# 仅用于首次创建传统 Pages Direct Upload 项目
npx wrangler pages deploy out --project-name axing-homepage --force

发布成功后，Cloudflare 返回了一个部署地址：　ㅤ

...

https://d9d03fb0.axing-homepage.pages.dev

稳定的生产地址则是：

...

https://axing-homepage.pages.dev

后续再更新这个已存在的 Pages 项目时，Wrangler 已明确提示：不再需要传 --force。这也是为什么这个 Skill 的“先查项目、没有就先创建，再部署”的流程很有价值——它比直接把一条命令丢给最新版 CLI 更稳。

这条经验只针对本次使用的 Wrangler 版本和静态 Next.js 项目；CLI 行为会更新，部署前最好先执行一次：

...

# 只检查授权和当前账号，不上传文件
wrangler whoami

　ㅤ

　ㅤ

　ㅤ

最后：一键部署真正省掉的是什么？

它省掉的不是服务器，也不是域名决策，而是重复的人工交接：找构建目录、检查敏感文件、确认账号、创建项目、上传、复制链接、验证可访问。

当这些步骤被收进一个 Skill，Codex 就不只是“写了一个网页”，而是可以把完成的静态成果交付到一个真实、可打开的地址。

但域名仍然应该由人来决定：

• 　ㅤ想低风险试验，就用新的 *.pages.dev；
• 　ㅤ想做正式入口，再绑定子域名；
• 　ㅤ想替换主站，最后才去改主域名 DNS。

把这三步分开，部署会从一件让人紧张的事，变成可回退、可验证的小闭环。

　ㅤ

　ㅤ

Skills开源

• github.com/vibe-any/skills-hub/tree/main/one-click-deploy