哈喽，大家好
我是阿星！
实测一个部署 Skill 后，我把 Next.js 静态主页发布到了 Cloudflare Pages。
很多人第一次看到这类“一键部署” Skill，都会有一个很自然的疑问：
Cloudflare 不是要账号、Token、Account ID 吗？为什么命令里什么都没填，网站就能上线？ ㅤ
我这次拿本地的 homepage 项目做了一次完整实测。
它是一个 Next.js 主页，但已经通过静态导出生成了 out/ 目录。最终网站上线在：
ㅤ
ㅤ
原有的 xxxx.work自定义域名 没有被覆盖，DNS 也没有改。更重要的是：这次在国内网络环境下也实际打开验证过。
先说结论： “不用填 Cloudflare 参数”不等于“不需要 Cloudflare 账号”，而是把认证和部署参数拆开了。
首次通过浏览器登录授权，之后 Wrangler 会在本机复用这个授权；Skill 再负责识别构建目录、创建 Pages 项目、上传文件和验证地址。
ㅤ
ㅤ
先分清：它发布的是新站，还是覆盖你的主域名？
这件事必须先讲清楚，不然很容易不敢按回车。
Cloudflare Pages 有两层地址： ㅤ
| 层级 | 这次的结果 | 是否影响 xxxx.work自定义域名 |
| Pages 默认地址 | axing-homepage.pages.dev | 不影响 |
| 自定义域名 | 例如 xxxx.work自定义域名 或 home. xxxx.work自定义域名 | 只有你主动绑定时才可能影响 |
ㅤ
只要没有进入 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.找到可发布目录：优先识别指定的 --output-dir，否则尝试 dist、build、public 等目录。
- 2.检查目录中是否有 index.html，并拒绝上传 .env、私钥、证书、凭据文件等敏感内容。
- 3.检查 Wrangler 是否可用、当前账号是否已授权。
- 4.查询 Pages 项目；项目不存在时，先创建项目并设置生产分支。
- 5.再上传静态文件，得到 *.pages.dev 地址。
- 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
