# AI自动化做网站：从域名注册到低成本上线全流程和技术栈及必备条件

- 状态 / Status: 草稿 / Draft
- 时间 / Time: 2026-05-13T16:07:19+08:00
- 作者 / Author: 良辰美
- 主题 / Topics: 建站 / Site Building, 方法论 / Methodology, 工具 / Tools

TLDR Cheatsheet辰美，先把话说硬一点：你真正要搭的不是网站，也不是 SaaS，而是一台上站机器。

---

# TLDR Cheatsheet

辰美，先把话说硬一点：你真正要搭的不是网站，也不是 SaaS，而是一台上站机器。Cloudflare、GitHub、Spaceship 只是零件。机器的目标是：一个想法进来，10 分钟后变成可访问、可收费、可追踪、可迭代的产品

主题

最务实选择

关键提醒

简单 HTML / Landing / 文档站

Cloudflare Pages

手工少量项目用 Git 集成；批量站点工厂更适合 Direct Upload + Wrangler + GitHub Actions

复杂 SaaS / API / AI 工具

Cloudflare Workers

Workers + D1 + R2 + Durable Objects + Workflows，按需组合

域名

最省事统一 Cloudflare Registrar；继续 Spaceship 也可以

Spaceship 最好只当注册商，把 nameserver 指向 Cloudflare，DNS 和部署统一在 Cloudflare

代码

GitHub 模板仓库 + GitHub Actions

每种业务一个模板，不要每次从零写

权限

GitHub Secrets 里放 Cloudflare Token、Account ID、必要的 Spaceship Key/Secret

不要用 Global API Key，不要把 token 写进代码

部署

Pages 用
`wrangler pages deploy`
；Workers 用
`wrangler deploy`

Pages 如果一开始用 Git 集成创建，官方说不能再切到 Direct Upload，所以建项目前先想清楚

自定义域名

Pages/Workers 都可以绑定域名

Pages 根域名 apex 基本要求该域在 Cloudflare Zone 里并使用 Cloudflare nameserver；Workers Custom Domain 需要 active Cloudflare zone

自动化机会

不是卖部署，是卖速度、卖垂直场景、卖客户结果

自动上站只是武器，赚钱靠可复制的业务闭环

流量策略

不要只押 SEO

搜索点击正在被 AI 摘要、零点击、平台内流量挤压，要做工具、线索、嵌入式、合作渠道、agent-ready

商业模式

Productized service + 微 SaaS + API/数据 + Lead-gen + Managed service

先收钱服务化，再把重复动作 SaaS 化

Cloudflare Pages 的 Git 集成可以连接 GitHub/GitLab，push 后自动部署，并生成预览部署；但官方文档也明确说，用 Git 集成创建的 Pages 项目不能再切换成 Direct Upload。批量自动化上站时，这个坑很要命。

# 0. 先给你一个判断：你现在不要追求会部署，你要追求会复制

你现在的问题表面上是：

我怎么把 HTML 放 Pages，把 SaaS 放 Workers？ Cloudflare、GitHub、Spaceship 的 token、API、SSH、CLI 怎么搞？

但本质上是：

我能不能把一个商业假设，快速变成一个能上线、能收钱、能验证、能复制的资产？

这两件事差别巨大。

普通人做网站，是打开 Cloudflare 点几下，部署成功，然后兴奋三分钟。 高手做网站，是先定义模板、权限、域名、部署、监控、收费、数据结构，然后让机器重复执行。

一句话：

你不是要学会建站，你是要把建站从手艺活变成流水线。

# 1. 你需要准备什么

## 1.1 账户层准备

你至少要准备这几个账户和组织结构：

第一，Cloudflare 账户。 这个账户负责 Pages、Workers、DNS、D1、R2、KV、Durable Objects、Workflows、自定义域名、SSL、边缘部署。Wrangler 是 Cloudflare 官方 CLI，用来创建、开发、部署和管理 Workers 项目，也可以用于 Pages Direct Upload。

第二，GitHub 组织。 不要只用个人仓库乱放。你应该建一个 GitHub Organization，比如 tatsumi-labs 、 yourname-factory 。里面放三类仓库：

template-page-static ：简单 HTML / Astro / Vite / Docs / Landing 模板。 template-worker-saas ：Workers SaaS 模板。 site-factory ：真正的自动化控制中心，用来创建 repo、注册域名、创建 Cloudflare 项目、部署、绑定域名。

第三，域名注册商。 最简单是统一 Cloudflare Registrar，因为 Cloudflare Registrar 官方支持通过 API 搜索域名、查询实时可用性和价格，并注册支持的域名；Cloudflare 也强调 Registrar 是按成本价注册和续费。 继续用 Spaceship 也没问题，Spaceship API 支持用 API Key 和 Secret 做认证，并支持域名查询、注册、续费、nameserver 更新和 DNS 记录管理。

第四，支付和邮件。 这不属于 Cloudflare/GitHub/Spaceship 三件套，但你做 SaaS 必须提前想。没有支付，你只是 demo；没有邮件，你就没有注册、通知、找回、账单、转化。

第五，监控和成本控制。 Workers 是很强，但你不能让一个 bug 或恶意请求把账单打爆。Cloudflare 文档里也提到可以通过 CPU limits 防止 runaway bills，也就是失控账单。

## 1.2 Cloudflare 侧准备

你要提前准备这些东西：

Cloudflare Account ID。 这个在 Wrangler 和 GitHub Actions 里经常要用。

Cloudflare API Token。 尽量使用 API Token，不要用 Global API Key。Cloudflare 官方说 Global API Key 是每个用户一个、缺少高级限制能力，并且不推荐新客户使用；API Token 可以按 Zone、Account、User 权限分组，也可以限制客户端 IP 范围和 TTL。

Cloudflare 权限策略。 不要一把梭全权限。你大概需要几种 token：

第一种，部署 token。 用于 GitHub Actions 部署 Pages/Workers。给 Pages Edit、Workers Scripts Edit、Account Read 等必要权限。

第二种，DNS token。 用于创建/更新 DNS 记录。给特定 Zone 的 DNS Edit，不要给全账户所有 Zone。

第三种，自动化工厂 token。 用于创建项目、绑定域名、创建资源。这个权限更大，只放在 site-factory 里，不要散落到每个项目仓库。

第四种，Account-owned token。 如果你做成真正的公司级自动化，不要所有 token 都绑定你个人用户。Cloudflare 文档里区分 user token 和 Account API token，Account API token 是服务型 token，不依附于具体用户；创建 account-owned token 需要 Super Admin 权限。

Cloudflare Zone 策略。 如果域名从 Spaceship 买，最稳方式是：

Spaceship 只当注册商。 nameserver 指向 Cloudflare。 DNS 记录、Pages/Workers 自定义域名、SSL 全部交给 Cloudflare。

原因很简单：Pages 的 apex 根域名绑定要求域名是 Cloudflare zone，并且 nameserver 指向 Cloudflare；子域名可以通过外部 DNS CNAME 到 Pages，但官方也提醒，不能只手动加 CNAME 而不在 Pages 里关联 custom domain，否则可能出现 522。

Workers Custom Domain 也要求有 active Cloudflare zone，并且不能在已有 CNAME 的 hostname 上创建 Custom Domain。

## 1.3 GitHub 侧准备

你需要准备：

GitHub Organization。 所有模板仓库、客户项目仓库、自动化工厂仓库放一起。

GitHub Actions。 用于每次 push 自动部署。Cloudflare 官方有 cloudflare/wrangler-action ，可以在 GitHub Actions 里部署 Workers，也可以用 Wrangler 部署 Pages。

GitHub Secrets。 把 CLOUDFLARE_API_TOKEN 、 CLOUDFLARE_ACCOUNT_ID 、 SPACESHIP_API_KEY 、 SPACESHIP_API_SECRET 这类东西放进去。GitHub 官方文档说 Secrets 用来存储敏感信息，Actions 只能读取明确包含的 secrets，并且 secrets 会在到达 GitHub 前被客户端加密。

GitHub Token 策略。 GitHub 官方推荐，命令行访问可以用 GitHub CLI 或 Git Credential Manager；在 Actions 里尽量用内置的 GITHUB_TOKEN 。如果需要用户级访问，可以用 fine-grained PAT，但 PAT 是代表用户，不适合长期组织级集成；长期集成更适合 GitHub App。

Deploy Key 策略。 Deploy Key 是 SSH key，只能访问单个仓库，默认只读，不能复用到多个 repo；如果给写权限，服务器被攻破时风险很高。GitHub 官方也建议很多场景用 GitHub App 替代 Deploy Key。

## 1.4 代码模板准备

你至少准备两个模板。

### 模板 A：简单 HTML / Landing / 内容站

适合：

一页式落地页 小工具页面 文档站 等待名单 产品介绍页 affiliate 页面 local lead-gen 页面 报价计算器前端 静态目录页

模板里应该有：

index.html 或 Astro/Vite 项目 robots.txt sitemap.xml 自动生成 基础 SEO meta Open Graph / Twitter card 结构化数据 JSON-LD 表单组件 邮箱订阅组件 Cloudflare Pages 部署配置 GitHub Actions 部署文件 可选： llms.txt 或面向 AI agent 的 markdown 摘要页

这里你不要整复杂。静态站最大的美德是快。快不是技术指标，快是商业指标。你想法当天上线，当天收反馈。

### 模板 B：复杂 SaaS / Workers

适合：

API 服务 AI 工具 Webhook 服务 多租户后台 数据查询工具 自动化工作流 客户门户 登录注册 支付订阅 文件上传 报告生成 队列任务 实时协作

模板里应该有：

Workers 项目 wrangler.toml 环境变量配置 D1 数据库迁移 R2 文件存储 KV 配置缓存 Durable Objects 用于强一致、会话、协作、实时协调 Workflows 用于长任务、重试、多步骤流程 认证模块 支付模块 邮件模块 管理后台 日志和健康检查 限流 错误报警 GitHub Actions 部署

Cloudflare D1 按 rows read、rows written、storage 计费，免费层包含每日读取和写入额度；R2 按存储和 Class A/B 操作收费，并强调没有 egress bandwidth charges。Durable Objects 适合 AI agents、协作、聊天、实时协调，并把计算和强一致存储组合在一起。Workflows 适合可重试、可持久化状态的多步骤应用。

# 2. Token / API / SSH / CLI 到底有什么区别

你可以用一个非常土但很准的比喻理解：

API 是门。 Token 是钥匙。 SSH 是另一种钥匙，主要用来安全登录或拉代码推代码。 CLI 是拿着钥匙帮你开门的工具人。

## 2.1 API 是什么

API 是机器和机器说话的接口。

你人类打开 Cloudflare Dashboard 点按钮，本质是图形界面在帮你调用 Cloudflare 的 API。 你写脚本创建 DNS 记录，也是调用 Cloudflare API。 你让 Spaceship 查域名可不可注册，也是调用 Spaceship API。 你让 GitHub 创建仓库、设置 secrets，也是调用 GitHub API。

API 不是秘密。API 是路。 秘密是 token/key。

Cloudflare API 能做 DNS 记录创建、更新、删除等操作；Spaceship API 支持域名注册、可用性查询、nameserver 更新和 DNS 记录管理；GitHub REST API 支持用 token 在请求头里认证。

## 2.2 Token / API Key 是什么

Token/API Key 是证明你有权限的凭证。

Cloudflare 里你应该用 API Token，而不是 Global API Key。 GitHub 里你可能会遇到 PAT、fine-grained PAT、GitHub App token、Actions 自带 GITHUB_TOKEN 。 Spaceship 里是 API Key + API Secret，放在请求头 X-API-Key 和 X-API-Secret 里。

你要记住一个铁律：

token 不是配置，token 是资产负债表上的风险。

你一旦把 token 放到代码里，别人拿到就能替你买域名、删 DNS、部署恶意代码、改你的 SaaS。GitHub 官方也提醒 token 要像密码一样对待；fine-grained PAT 可以设置过期时间，公开泄露到 public repo 或 gist 时会被自动撤销，长期不用也可能被撤销。

## 2.3 SSH 是什么

SSH 是基于密钥对的安全访问方式。

你最常见的用法是：

本地电脑通过 SSH key 拉 GitHub 私有仓库。 服务器通过 Deploy Key 读取某个 GitHub 仓库。 自动化环境通过 SSH key 做 git clone。

但你现在的上站工厂，不应该主要靠 SSH。原因是：

SSH 更适合 Git 操作。 API Token 更适合创建仓库、创建项目、部署、绑域名、改 DNS。 GitHub Deploy Key 只能绑定单个仓库，不能复用到多个 repo，做站点工厂会很麻烦。

## 2.4 CLI 是什么

CLI 是命令行工具。

Wrangler 是 Cloudflare CLI。 GitHub CLI 是 GitHub 的 CLI。 它们本质上是替你调用 API，但比你直接写 HTTP 请求舒服。

比如：

wrangler deploy 部署 Worker。

wrangler pages deploy dist --project-name=xxx 把构建好的静态文件上传到 Pages。

gh repo create 创建 GitHub 仓库。

CLI 的好处是快，适合人和 CI/CD。 API 的好处是可控，适合你写自己的站点工厂。

真正成熟的架构一般是：

本地开发用 CLI。 GitHub Actions 里也用 CLI。 站点工厂核心逻辑用 API。 所有 secret 放在 GitHub Secrets 或更专业的 secret manager 里。

# 3. 简单 HTML 和复杂 SaaS，如何做到全自动化上站

## 3.1 你要先做一个总控：Site Factory

这个总控可以先很简单，甚至一开始只是一个 Node.js 脚本或 Workers 后台。

它维护一张表：

字段

含义

`site_slug`
项目标识，比如
`ai-invoice-checker`

`site_type`
`page`
或
`worker_saas`

`domain`
主域名

`registrar`
`cloudflare`
或
`spaceship`

`template_repo`
用哪个模板

`github_repo`
生成后的 GitHub repo

`cloudflare_project`
Pages 项目名或 Worker 名

`zone_id`
Cloudflare Zone

`status`
created / deployed / domain_bound / launched

`monetization`
affiliate / subscription / lead-gen / service / API

`owner`
内部负责人

`created_at`
创建时间

然后每次上站执行同一条流水线：

想法录入 域名查询 域名注册或跳过 创建 GitHub repo 从模板生成代码 创建 Cloudflare 项目 写入 secrets 第一次部署 绑定域名 冒烟测试 提交到监控 写入 launch log

这就是你的上站机器。

小故事来了。 有个独立开发者小林，手上有 80 个域名，每天觉得自己拥有 80 个未来。但一年后，他发现这些域名只是 80 个墓碑。因为每个域名都没有 repo、没有部署、没有表单、没有数据、没有客户。后来他把流程改成一个规则：买域名后的 30 分钟内必须生成 landing、表单、analytics、报价页。结果他不再炫耀域名数量，他开始看每个域名的线索成本。人一旦从收藏家变成运营者，命运就变了。

你别做域名收藏家，你要做机会屠夫。看到一个机会，切下来，包装，部署，测试，收费。

## 3.2 简单 HTML：Pages 自动化路线

你有两条路。

### 路线 A：Pages Git 集成

适合：

单个项目 团队协作 正常 push 自动部署 PR 预览 不追求极致自动化工厂

Cloudflare Pages 的 Git 集成可以连接 GitHub/GitLab 仓库，每次 push 到分支时自动构建和部署，还会给 pull request 生成唯一预览 URL 和状态检查。

缺点是：

一旦你用 Git 集成创建 Pages 项目，官方说不能切换到 Direct Upload。

所以你要是未来要做批量站点工厂，这条路不一定最优。

### 路线 B：Pages Direct Upload + Wrangler

适合：

站点工厂 自动生成静态文件 不想每个站都手工连接 GitHub 需要完全由 CI/CD 控制部署 需要一个脚本批量创建/部署项目

Cloudflare Pages Direct Upload 是把预构建好的 assets 上传到 Pages，适合你已有自己的构建平台或本地上传流程；支持 Wrangler 或拖拽上传。

官方命令示例是：

```
CLOUDFLARE_ACCOUNT_ID=<ACCOUNT_ID> npx wrangler pages deploy <DIRECTORY> --project-name=<PROJECT_NAME>
```

并且官方文档提供了 GitHub Actions 里用 cloudflare/wrangler-action@v3 配合 CLOUDFLARE_API_TOKEN 自动部署的方式。

### 简单 HTML 推荐流水线

你应该这样做：

第一步，创建 GitHub repo。 从 template-page-static 复制。

第二步，生成内容。 比如产品名、标题、FAQ、价格、CTA、表单 endpoint、schema、sitemap。

第三步，创建 Pages project。 可以用 Wrangler：

```
npx wrangler pages project create my-site --production-branch=main
```

Wrangler 文档包含 pages project create 和 pages deploy 命令。

第四步，GitHub Actions 部署。

```
name: Deploy Pages
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
contents: read
deployments: write
steps:
- uses: actions/checkout@v6
- name: Install and build
run: |
npm ci
npm run build
- name: Deploy to Cloudflare Pages
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: pages deploy dist --project-name=${{ vars.CF_PAGES_PROJECT }}
```

第五步，绑定域名。 如果是 apex 根域名，最好让域名成为 Cloudflare zone，并使用 Cloudflare nameserver。Cloudflare 文档对 Pages apex 域名就是这个要求。子域名虽然可以外部 DNS CNAME，但仍然要在 Pages 里关联 custom domain，不能只手动 CNAME。

第六步，冒烟测试。

测试：

首页 200 SSL 正常 www 跳转正常 apex 跳转正常 表单能提交 analytics 能记录 sitemap 能访问 robots 正常 移动端显示正常

## 3.3 复杂 SaaS：Workers 自动化路线

复杂 SaaS 用 Workers，不要把它想成只是一个函数。你要把它想成一套边缘应用平台。

基本组合：

Workers：业务逻辑和 API D1：关系型数据 R2：文件、报告、图片、导出数据 KV：缓存、配置、短期映射 Durable Objects：强一致、多租户会话、实时协作、状态机 Workflows：长任务、重试、异步流程 Queues：异步任务队列 Workers AI / AI Search：AI 推理、文档搜索、agent memory 等场景

Workers 的 Git 集成可以基于生产分支自动创建 build 和执行 deploy；官方也有 GitHub Actions 部署 Workers 的示例。

### Workers SaaS 推荐流水线

第一步，创建 repo。 从 template-worker-saas 复制。

第二步，生成 wrangler.toml 。

示例：

```
name = "invoice-audit-saas"
main = "src/index.ts"
compatibility_date = "2026-05-08"
[vars]
APP_ENV = "production"
[[d1_databases]]
binding = "DB"
database_name = "invoice-audit-prod"
database_id = "xxxx"
[[r2_buckets]]
binding = "REPORTS"
bucket_name = "invoice-audit-reports"
[[kv_namespaces]]
binding = "CONFIG"
id = "xxxx"
```

第三步，创建 D1/R2/KV 等资源。 这些可以用 Wrangler 或 Cloudflare API 自动创建。

第四步，执行数据库迁移。 上线前必须自动 migration，不然你迟早部署成功但业务挂掉。

第五步，部署 Worker。

```
name: Deploy Worker
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Install
run: npm ci
- name: Deploy Worker
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: deploy
```

Wrangler 文档说明 wrangler deploy 会把新版本部署到 100% 流量，也可以通过 Workers Versions/Deployments 做更细粒度发布，把上传版本和切流分开。

第六步，绑定自定义域名。 Workers Custom Domains 会把 Worker 连接到域名或子域名，Cloudflare 会创建 DNS 记录和证书；它要求 active Cloudflare zone，并且不能在已有 CNAME 的 hostname 上创建 Custom Domain。

第七步，建立租户模型。

如果你做 SaaS，你不要等后面再补多租户。哪怕 MVP，也要先想：

一个用户一个 workspace？ 一个客户一个 domain？ 一个 workspace 多成员？ 订阅绑定 user 还是 workspace？ 数据隔离靠 tenant_id 还是单独数据库？ 客户自定义域名怎么绑定？

第八步，建立收费闭环。

没有收费闭环，你的 SaaS 只是会动的 PPT。

至少要有：

注册 登录 订阅 支付回调 额度限制 账单状态 取消订阅 失败支付提醒 套餐升级 管理员手工开通

# 4. 域名策略：Spaceship 还是 Cloudflare

## 4.1 最简单方案：Cloudflare Registrar

最省脑子的路线：

域名在 Cloudflare 买。 DNS 在 Cloudflare。 Pages/Workers 在 Cloudflare。 自定义域名在 Cloudflare。 证书在 Cloudflare。 API 自动化也在 Cloudflare。

这条路最适合你做自动化上站，因为 Cloudflare Registrar 官方支持用 API 搜索域名、查询可用性和价格、注册支持的域名；Cloudflare Registrar 的商业定位也是按成本价注册和续费，不加价。

缺点是：

不是所有 TLD 都一定适合或支持。 有些域名你可能已经在 Spaceship。 你要确认你的 Cloudflare 账户、付款、注册人信息、TLD 限制都没问题。

## 4.2 继续用 Spaceship 的方案

可行，而且也能自动化。

Spaceship API 支持 API Key/Secret 认证，支持域名 availability、register、renew、restore、autorenew，也支持 nameserver 更新和 DNS 记录接口。

但我建议你把 Spaceship 定位成：

便宜好用的注册商。 不是 DNS 中枢。 不是部署中枢。

也就是：

域名在 Spaceship 买。 注册后立刻通过 Spaceship API 把 nameserver 改到 Cloudflare。 Cloudflare 负责 Zone、DNS、Pages、Workers、SSL、自定义域名。

为什么？

因为你要减少系统边界。 自动化最怕三件事：一个系统管注册、一个系统管 DNS、一个系统管部署。出问题的时候，像三个人一起甩锅，谁都说不是我。

## 4.3 域名购买要有刹车

你做自动化域名注册，一定要有规则：

只允许注册白名单 TLD。 每次注册前检查价格。 超过预算必须人工确认。 记录注册原因和关联项目。 设置自动续费策略。 每周扫描即将过期域名。 避免商标风险。 避免拼写相近的钓鱼域名。 不要因为兴奋一天买 50 个域名。

域名是资产，也是慢性毒药。它很便宜，便宜到让你误以为自己在前进。

# 5. 你的两类上站，全自动化可以捕捉什么机会

自动化上站本身不赚钱。 它赚钱的地方是：当一个市场缝隙出现时，你能比别人更快把产品入口立起来。

## 机会 1：Programmatic Landing，但不要做垃圾 SEO

很多人一听批量上站，就想到自动生成几千个 SEO 页面。这个思路不是完全不行，但现在风险很高。

你应该做的是：

每个页面都对应一个真实意图。 每个页面都有工具、计算器、报价、表单、数据或可执行动作。 页面不是为了让人看完，是为了让人立刻做一件事。

例子：

/roof-repair-cost-calculator-los-angeles 不是一篇废话文章，而是一个屋顶维修报价计算器，最后收集线索。

/ai-contract-risk-checker-for-freelancers 不是介绍 AI 合同审查，而是上传合同，给一个初步风险评分。

/shopify-chargeback-template-generator 不是讲拒付，而是生成申诉模板。

小故事。 有个人做了 300 篇水文，Google 没给他流量，他骂 Google 不公平。另一个人只做了 12 个页面，每个页面都有一个行业计算器。第三个月，他把线索卖给本地服务商，一个线索 20 到 80 美元。第一个人在等搜索引擎赏饭，第二个人在把用户意图变成交易。你要做第二种。

## 机会 2：Agent-ready 网站改造

这是我觉得你可以重点看的方向。

Cloudflare 在 Agent Readiness 相关内容里提到，他们扫描了 20 万个顶级域名，发现 robots.txt 普及率高，但 Content Signals、Markdown content negotiation、MCP Server Cards、API Catalogs 等面向 AI agent 的能力采用率很低，MCP Server Cards/API Catalogs 在该数据集里少于 15 个站点。

这意味着一个机会：

大量网站还没准备好被 AI agent 正确理解、引用、调用、交易。

你可以做一个服务：

输入域名 自动扫描 agent-readiness 生成评分 给出修复方案 一键生成 llms.txt 、markdown 摘要、结构化数据、API catalog、robots/content signals 建议 然后按月监控

收费方式：

免费扫描 49 美元详细报告 499 到 2999 美元改造服务 99 到 499 美元/月监控和更新

这个适合你的 Cloudflare 上站机器，因为你可以给每个客户快速部署一个报告页、客户门户、监控 Worker。

## 机会 3：垂直微 SaaS

横向 SaaS 很难。 你一个人去做通用 CRM、通用项目管理、通用表单工具，大概率会被打成肉泥。

但垂直 SaaS 还有空间。

比如：

牙医诊所的术后随访系统 宠物美容店的预约和提醒系统 婚礼摄影师的客户门户 小型律所的 intake form 和合同模板系统 跨境卖家的退货申诉助手 房产经纪人的 open house 线索系统 本地服务商的报价和派单系统

High Alpha/OpenView 的 2024 SaaS Benchmarks 提到，GTM 是 SaaS 公司最关心的问题之一；报告也指出 AI-native 和 vertical SaaS 相比 horizontal SaaS 有更好的增长表现。

你看，重点不是 SaaS。重点是 vertical。 不是你会不会写代码，是你有没有站在一个具体行业的具体痛点上。

## 机会 4：自定义域名 SaaS

很多 SaaS 最后都会遇到一个需求：

客户想用自己的域名。

比如：

客户门户： portal.client.com 公开页面： book.client.com 报告页面： report.client.com 白标页面： app.client.com

Cloudflare for SaaS 支持把 Cloudflare 产品扩展到客户拥有的 custom domains，通过 custom hostnames 把客户域名路由到 fallback origin；标准配置可用于所有计划，但 Apex Proxying 是 Enterprise add-on。

这给你一个产品机会：

你可以做一个多租户平台，每个客户都有自己的页面、表单、报价、报告、booking 或 portal，而且可以绑自己的域名。

这类东西很容易收费，因为客户觉得这是他的门面，不是你的工具。

## 机会 5：低成本迁移服务

很多人用 Vercel、Netlify、Heroku、Render、AWS，最后卡在成本、速度、复杂度、账单。

你可以做：

把静态站迁到 Cloudflare Pages。 把轻量 API 迁到 Workers。 把图片/文件迁到 R2。 把小数据库迁到 D1。 把定时任务/工作流迁到 Workflows。 把客户域名和 SSL 整好。

商业模式：

一次性迁移费：500 到 5000 美元。 维护费：99 到 999 美元/月。 复杂 SaaS：按项目报价。

这个方向不性感，但能收钱。很多钱藏在不性感的地方。

## 机会 6：数据/API 产品

Cloudflare Workers 很适合轻量 API。

你可以做：

行业价格监控 API 竞品变更监控 API 招聘信息聚合 API 房地产线索 API Shopify 店铺风险检查 API 本地商家数据 enrichment API AI prompt/output 评估 API

商业模式：

免费额度 按调用次数收费 月订阅 企业 API key 数据导出包

Paddle 的定价资料里把 usage-based pricing 描述为按 API calls、compute、emails、data 等使用量收费，这种模式适合成本和价值随使用量变化的产品。

# 6. 流量不好搞，这个判断是对的

你说目前看起来流量不是很好搞。 这个判断非常清醒。

现在不是 2012 年，不是随便写点 SEO 页面就能吃三年。

几个现实：

Reuters Institute 的 2026 报告提到，出版商预期未来三年搜索流量会大幅下降；报告还引用数据称 2024 年 11 月到 2025 年 11 月，全球来自 Google organic search 的流量下降 33%，美国下降 38%，当然报告也说明 AI Overviews 对硬新闻的影响证据并不完全一致。

Pew 的 2025 年研究发现，在有 AI summary 的 Google 搜索访问中，用户点击传统搜索结果的比例是 8%，没有 AI summary 时是 15%；点击 AI summary 内链接的比例约 1%，并且有 AI summary 的访问更常直接结束。

SparkToro/Datos 的研究称，美国 Google 搜索里接近 60% 是 zero-click，每 1000 次美国 Google 搜索中只有约 360 次点击流向 open web。

Ahrefs 的数据分析也认为 AI Overviews 显著降低了 position 1 organic CTR，不过这是 Ahrefs 的样本和方法下的结论，不要当作宇宙真理。

所以，你不能再用老思路：

建站 发文章 等 Google 祈祷转化

这就是平庸之辈的四步自杀流程。

你要改成：

做一个工具 解决一个高意图问题 用户用完留下邮箱/电话/付款 页面可分享 结果可嵌入 客户可转介绍 销售可以主动出击 SEO 只是副产品，不是命根子

## 6.1 你应该做的流量组合

第一，工具型流量。 计算器、生成器、扫描器、检查器、模板生成器，比普通文章更容易留下人。

第二，销售驱动流量。 你可以用自动化站点给每个细分行业生成专属 demo，然后主动发给客户。比如：

我给你们诊所做了一个术后随访 demo 我给你们律所做了一个 intake demo 我给你们中介做了一个 open-house lead demo

这比冷邮件里说我能帮你做网站强一百倍。

第三，合作渠道。 SEO 顾问、Webflow 设计师、独立营销顾问、本地代理商，他们有客户但未必有 Cloudflare/AI/自动化能力。你给他们白标工具，他们帮你卖。

第四，嵌入式流量。 做 widget。 比如报价计算器、评分 badge、客户评价组件、AI FAQ 组件。 客户把 widget 嵌到自己网站，你获得数据、品牌、潜在线索。

第五，Agent-ready / AEO。 未来一部分流量不会来自人点击搜索结果，而是来自 agent 读取、总结、调用、推荐。你现在就应该让页面结构化、可机器读取、可被正确引用。Cloudflare 的 Agent Readiness 内容也把 discoverability、content、bot access control、capabilities 作为评分维度。

第六，内容不是博客，是证据。 写案例、价格页、对比页、迁移报告、真实数据。 不要写那种谁都能写的十个技巧。

# 7. 商业模式可以怎么探索

## 7.1 简单 HTML / Pages 类商业模式

### 模式 A：Productized Landing Service

你卖的不是网站。 你卖的是一个行业转化入口。

例如：

本地牙医种植牙报价页 律师咨询预约页 Roof repair 估价页 Med spa 项目价格页 移民顾问 intake 页 Shopify 卖家申诉模板页

收费：

一次性 299 到 1999 美元。 托管维护 49 到 299 美元/月。 线索另算。

关键是你要把 Pages 模板做成流水线：

客户行业 城市 服务类型 价格区间 FAQ 表单 CTA 地图 schema 部署 域名

### 模式 B：Lead-gen

你自己拥有页面和域名。 用户来提交线索。 你把线索卖给服务商。

优点：

不用等客户先买你的 SaaS。 一个页面能对应一个现金流。

缺点：

需要懂行业、懂线索质量、懂合作商。 有些行业合规要求高，不能乱搞。

### 模式 C：Affiliate / Referral

适合：

软件推荐 主机/域名/工具推荐 AI 工具目录 细分行业工具比较 课程/模板/插件

别做泛泛的 AI 工具目录，已经烂大街。 你要做有筛选逻辑的：

For Shopify refund disputes For solo immigration lawyers For Japanese learning YouTubers For small dental clinics For real estate cold outreach

越窄越有钱。窄不是小，窄是刀锋。

### 模式 D：付费模板

你可以卖：

Cloudflare Pages landing 模板 Workers SaaS starter Agent-ready website template Local lead-gen page pack Niche calculator pack AI report generator template

但注意，卖模板通常不是最大的钱。模板更适合作为获客入口。

## 7.2 Workers SaaS 类商业模式

### 模式 A：订阅

按月收费。最传统。

适合：

CRM 客户门户 自动报告 监控工具 AI 文档问答 工作流工具

### 模式 B：用量计费

适合：

API 调用 AI 推理 文件处理 扫描次数 报告生成 邮件发送 数据抓取 任务执行

用量计费的好处是客户用得越多你赚得越多，坏处是客户一开始会担心不可控成本。你可以用额度包解决。

Paddle 对定价模式的解释里，usage-based pricing 就是按 API 调用、计算、邮件、数据等使用量收费；per-user pricing 则是 SaaS 常见的按用户数收费。

### 模式 C：按结果收费

例如：

每条合格线索收费 每次成功申诉收费 每份合格报告收费 每个通过审核的页面收费 每个完成迁移的客户收费

AI 产品里，很多人还停留在按 seat 收费，但 High Alpha/OpenView 的报告提到，使用 AI 组件的 SaaS 公司里，接近 70% 在 monetizing 或 testing AI，不过少于 10% 是 output/result-driven 定价。这里还有空间。

### 模式 D：Managed SaaS

这是我最推荐你早期做的。

不要一开始就幻想纯自助 SaaS。 你现在没有流量、没有品牌、没有销售机器，自助 SaaS 很容易变成自助死亡。

你应该做：

软件 + 服务 模板 + 定制 自动化 + 人工交付 月费 + 设置费

比如：

Agent-ready 改造：499 美元 setup + 99 美元/月 Cloudflare 迁移：1500 美元 setup + 199 美元/月 行业报价工具：999 美元 setup + 149 美元/月 本地 lead-gen：按线索或按月

等你交付 20 个客户，发现 80% 工作重复，再把重复部分产品化。

这叫先用服务找真需求，再用 SaaS 收割规模。

不要反过来。反过来是很多独立开发者的墓志铭：他写完了产品，但世界没有写完付款按钮。

# 8. 深度研究案例：Agent-Ready Landing Factory

下面给你一个完整案例，你可以把它当成真实创业方向去拆。

## 8.1 背景

AI 搜索、AI 摘要、AI agent 正在改变网站被发现、被读取、被引用、被调用的方式。传统 SEO 不是死了，但它的确定性下降了。与此同时，很多企业网站还停留在：

HTML 乱 内容不可结构化读取 没有清晰 sitemap robots 策略混乱 没有 markdown/agent 友好摘要 没有 API catalog 没有结构化数据 FAQ 是装饰，不是可用知识 产品价格、服务区域、联系方式藏得很深

Cloudflare 的 Agent Readiness 资料显示，在他们扫描的 20 万个顶级域名里，一些面向 AI agent 的新能力采用率极低，这说明市场还非常早。

## 8.2 产品名

AgentReadyKit

一句话：

帮企业网站变得更容易被 AI agent 正确理解、引用和调用。

## 8.3 目标客户

第一类，SEO 代理商。 他们害怕 AI 搜索冲击，但需要新服务卖给客户。

第二类，本地服务公司。 牙医、律师、诊所、装修、教育机构、咨询公司，他们的网站信息经常乱。

第三类，SaaS 公司。 他们希望自己的 docs、pricing、API、integration 被 AI agent 准确理解。

第四类，内容出版商。 他们需要管理 AI bot access、内容信号、机器可读摘要。

## 8.4 MVP 功能

用户输入域名。 Worker 抓取首页、robots、sitemap、主要页面。 D1 存扫描结果。 R2 存截图、报告、导出的 markdown。 Workflows 执行多步骤扫描和重试。 Pages 展示公开报告页。 Workers 负责 API 和支付回调。 GitHub 存模板代码。 Cloudflare 自定义域名给客户一个白标报告地址。

Cloudflare Workflows 适合这种多步骤、可重试、可持久化状态的流程；R2 适合存报告和导出文件，D1 适合存扫描结果。

## 8.5 免费报告结构

评分：

Discoverability：是否有 sitemap、robots、canonical、schema Content：是否有清晰 markdown 摘要、FAQ、价格、服务区域 Bot Access Control：是否明确允许/限制 bots Capabilities：是否有 API、预约、表单、catalog、可调用动作 Conversion：AI agent 把用户带来之后，能不能成交

报告输出：

总分 3 个最高优先级问题 自动生成修复建议 付费按钮

## 8.6 付费服务

49 美元：完整扫描报告。 499 美元：基础修复包。 1499 美元：完整 agent-ready 改造。 99 美元/月：持续监控。 299 美元/月：代理商白标版。

基础修复包包括：

生成 llms.txt 生成 markdown business profile 生成 sitemap 修复建议 生成结构化数据 JSON-LD 生成 FAQ schema 生成 service area 页面 生成 AI-readable pricing summary 生成 API/catalog 文档草稿 Cloudflare Pages 部署一个 public profile Cloudflare Worker 监控变化

## 8.7 上站流水线怎么用

客户付款后：

系统生成客户 slug。 创建 GitHub repo： client-agentready-xxx 。 从模板生成报告页。 创建 Pages 项目。 部署报告站。 绑定客户子域名或你的子域名。 把扫描任务放进 Workflows。 扫描完成后，R2 存 PDF/Markdown 报告。 D1 更新状态。 客户收到邮件。 后台显示可修复项。 客户点击升级。

这就是你的 Pages + Workers + GitHub + Cloudflare 自动化能力真正发挥价值的地方。

## 8.8 为什么这比普通建站强

普通建站卖的是页面。 这个产品卖的是风险、未来和可见性。

客户不一定愿意为一个新 landing page 付 2000 美元。 但他可能愿意为别让 AI 错误理解我的公司、别让竞争对手在 AI 搜索里超过我、别让我的 docs 被 agent 读错付钱。

商业的本质不是你有什么技术，而是客户害怕什么、渴望什么、愿意为什么转账。

## 8.9 这个案例的风险

第一，agent-ready 标准还在变化。 所以你不能假装自己掌握终极标准。你要把产品定位成持续监控和持续适配。

第二，客户可能听不懂。 所以不要一开始对小商家讲 MCP、content negotiation、API catalog。你要讲：

AI 能不能正确介绍你的业务？ AI 能不能找到你的价格和服务？ AI 会不会把客户导到竞争对手那里？ AI 能不能正确读取你的预约入口？

第三，免费扫描可能被滥用。 要限流、验证码、登录后深度扫描。

第四，别做成纯技术玩具。 必须有 sales motion。比如卖给 SEO agency，让他们带客户。

# 9. 你现在最应该采用的架构

我给你一个务实版本。

## 9.1 第一阶段：先做手动半自动

不要一上来写巨大的站点工厂。那是工程师自嗨。

先做：

两个模板仓库 两个 GitHub Actions 一套 Cloudflare token 一个域名接入流程 一个 Notion/Airtable/Google Sheet 记录项目状态 一个 Node.js 脚本做基础创建

目标：

一天能稳定上线 3 到 5 个真实项目。

## 9.2 第二阶段：做 Site Factory CLI

比如：

```
site-factory create \
--type page \
--template landing-calculator \
--domain example.com \
--registrar spaceship \
--name "Roof Repair Cost Calculator"
```

执行后自动：

检查域名 生成 repo 生成代码 设置 secrets 创建 Pages project 部署 绑定域名 跑测试 输出上线报告

## 9.3 第三阶段：做内部后台

当 CLI 稳定后，再做后台。

后台功能：

项目列表 域名状态 部署状态 收入状态 客户状态 一键重新部署 一键绑定域名 一键生成报告 一键暂停站点 成本监控 到期提醒

## 9.4 第四阶段：对外产品化

当你自己用这套系统交付了 20 到 50 个客户，再考虑开放给别人。

不然你会做出一个没人用的自动化平台。 工具要从战场长出来，不要从幻想长出来。

# 10. 关键技术 SOP

## 10.1 简单 HTML / Pages SOP

2. 新建项目记录 记录 slug 、 domain 、 template 、 monetization 、 owner 。
4. 查询域名 Cloudflare Registrar 或 Spaceship API 查询可用性。Cloudflare Registrar API 支持查询域名实时可用性和价格；Spaceship API 也支持 availability 查询。
6. 注册域名或使用已有域名 如果用 Spaceship，注册后把 nameserver 指向 Cloudflare。
8. 创建 Cloudflare Zone 让 Cloudflare 管 DNS。
10. 从模板创建 GitHub repo 复制 template-page-static 。
12. 生成页面内容 标题、文案、FAQ、schema、表单、tracking、sitemap。
14. 创建 Pages Project 用 Direct Upload 模式更适合批量自动化。
16. 设置 GitHub Secrets 写入 CLOUDFLARE_API_TOKEN 、 CLOUDFLARE_ACCOUNT_ID 。
18. GitHub Actions 部署 构建后用 Wrangler deploy 到 Pages。
20. 绑定自定义域名 在 Pages 中关联 custom domain，同时 DNS 正确配置。不要只手动 CNAME。
22. 冒烟测试 HTTP、SSL、表单、analytics、跳转、sitemap、移动端。
24. 上线记录 记录部署 URL、域名、GitHub repo、Cloudflare project、成本、商业模式。

## 10.2 Workers SaaS SOP

2. 定义产品和租户模型 先想清楚 user、workspace、tenant、billing 怎么对应。
4. 创建 repo 从 template-worker-saas 复制。
6. 创建 Cloudflare 资源 Worker、D1、R2、KV、Durable Objects、Workflows。
8. 配置 wrangler.toml 绑定资源和环境变量。
10. 配置 secrets 支付 key、邮件 key、AI key、Cloudflare token 等，不进代码仓库。
12. 数据库 migration D1 表结构必须自动迁移。
14. 部署 staging 先部署非生产环境。
16. 跑测试 API health、登录、支付 webhook、数据库读写、文件上传、权限隔离。
18. 部署 production wrangler deploy 或 GitHub Actions。
20. 绑定 custom domain Workers Custom Domain 需要 active Cloudflare zone；不能在已有 CNAME 的 hostname 上创建。
22. 设置成本和限流 CPU limit、rate limit、请求配额、AI 调用额度。
24. 监控和回滚 记录版本，必要时用 Workers Versions/Deployments 分离上传和切流。

# 11. Checking List

## 账户安全

- Cloudflare 开 2FA
- GitHub 开 2FA
- 不使用 Cloudflare Global API Key
- Cloudflare token 最小权限
- token 设置 TTL 或 IP 限制
- GitHub Secrets 存敏感信息
- 不把 token 写进 repo
- 不把 .env 提交到 GitHub
- Spaceship Key/Secret 只放自动化仓库
- 大权限 token 只放 site-factory，不放每个项目

Cloudflare API Token 支持按权限和资源限制，也支持 IP 和 TTL 限制；GitHub Secrets 会加密并供 Actions 使用。

## 域名和 DNS

- 域名注册商确认
- 域名价格确认
- TLD 白名单确认
- 商标风险检查
- nameserver 指向 Cloudflare
- Cloudflare Zone active
- apex 和 www 跳转规则
- Pages custom domain 已关联
- Workers custom domain 无冲突 CNAME
- SSL 正常
- 域名续费提醒

## Pages

- 选择 Git 集成还是 Direct Upload
- 站点工厂优先 Direct Upload
- 静态文件数量不要超过计划限制
- build command 正确
- output directory 正确
- preview / production 分支区分
- sitemap 正常
- robots 正常
- 表单 endpoint 正常
- analytics 正常

Cloudflare Pages 免费计划站点文件数有上限，付费计划在特定 Wrangler 版本条件下支持更高文件数量；Pages Functions 请求也会计入 Workers Free quota。

## Workers SaaS

- wrangler.toml 正确
- D1 migration 可重复执行
- R2 bucket 权限正确
- KV namespace 分环境
- Durable Objects 命名和迁移正确
- Workflows 重试策略正确
- 支付 webhook 验签
- 登录权限隔离
- tenant_id 隔离
- rate limit
- error logging
- 成本上限
- 回滚方案

## 商业闭环

- 这个站解决哪个付费痛点
- 用户在哪里来
- 用户来了做什么
- 转化动作是什么
- 收费方式是什么
- 价格是多少
- 有没有免费试用或 lead magnet
- 有没有邮件跟进
- 有没有复购/续费
- 有没有销售脚本
- 有没有客户案例页
- 有没有退出标准

# 12. 5W2H

## Who：谁来用，谁来买

使用者可能是：

小企业老板 SEO/营销代理商 SaaS 创始人 本地服务商 开发者 行业顾问 企业运营人员

付款者往往不是最懂技术的人。 所以你别卖 Cloudflare Workers，别卖自动化部署。你要卖：

更多线索 更快上线 更低成本 更少维护 更好被 AI 和搜索理解 更快验证商业假设

## What：你到底在做什么

你在做一套自动化上站系统。

输入：

想法 域名 模板 商业模式 客户信息

输出：

GitHub repo Cloudflare Pages/Workers 项目 自定义域名 SSL 表单/API 数据存储 支付入口 监控 上线报告

## When：什么时候用

每当你有这些需求时用：

新产品验证 新 landing page 客户交付 行业小工具 报价计算器 AI 扫描器 SaaS MVP 客户门户 白标页面 活动页 affiliate 页面

最重要的使用场景是：

机会出现的当天。

机会这东西很贱。你等它，它不来；它来了，你慢，它就走。

## Where：部署在哪里

代码在 GitHub。 简单站在 Cloudflare Pages。 复杂应用在 Cloudflare Workers。 数据在 D1/KV/Durable Objects。 文件在 R2。 异步流程在 Workflows。 域名和 DNS 尽量在 Cloudflare。 Spaceship 可以作为注册商。

## Why：为什么这么做

因为你现在最大的敌人不是技术难度，而是试错速度。

你不懂代码、不懂产品、不懂运营、不懂营销，这并不可怕。可怕的是每试一个东西都要拖半个月。自动化上站的价值是把试错成本砍到极低，让你用市场反馈补足认知。

你要用系统弥补经验，而不是用热血硬扛混乱。

## How：怎么做

先做两个模板。 再做 GitHub Actions。 再做 Cloudflare token。 再做域名接入。 再做手动 SOP。 再写 CLI。 再做后台。 最后产品化。

顺序不能反。 先自动化一个还没跑通的流程，就是把错误规模化。那不是效率，那是工业级自毁。

## How much：大概成本和收费

成本主要来自：

域名年费 Cloudflare 资源用量 AI/API 调用 邮件发送 支付手续费 监控工具 你的时间

Cloudflare D1、R2 等资源是按读取/写入/存储/操作等维度计费，R2 官方强调没有 egress bandwidth charges；Cloudflare Registrar 则按成本价注册和续费。

收费可以从这几档开始：

简单 landing：299 到 1999 美元一次性 托管维护：49 到 299 美元/月 扫描报告：49 到 199 美元 技术改造：499 到 5000 美元 垂直 SaaS：19 到 499 美元/月 API/数据：免费额度 + 用量计费 企业/白标：999 美元/月起

别一开始幻想日入十万刀。 日入十万刀不是一个目标，是一个系统吞吐量。你先做到一天上线一个能收钱的东西，再做到一周签一个客户，再做到每个客户月付，再做到渠道帮你卖。雪球不是靠喊大的，是靠第一层雪粘住了才滚大的。

# 最终判断

你的最佳路线是：

第一，把域名、GitHub、Cloudflare 打通成半自动上站流水线。 第二，简单站用 Pages Direct Upload + Wrangler，复杂 SaaS 用 Workers + D1/R2/Workflows。 第三，域名尽量统一到 Cloudflare；继续用 Spaceship 也行，但让 Cloudflare 管 DNS。 第四，不要赌纯 SEO，转向工具型页面、线索、垂直 SaaS、agent-ready、迁移服务、managed SaaS。 第五，先用服务收钱，再把重复部分产品化。

技术上，你要的是自动部署。 商业上，你要的是自动验证。 战略上，你要的是自动把机会变成现金流。