草稿 / Draft 2026-05-13T16:07:19+08:00

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

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

建站 / Site Building 方法论 / Methodology 工具 / Tools

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

新建项目记录

记录 slug、domain、template、monetization、owner。
查询域名

Cloudflare Registrar 或 Spaceship API 查询可用性。Cloudflare Registrar API 支持查询域名实时可用性和价格；Spaceship API 也支持 availability 查询。
注册域名或使用已有域名

如果用 Spaceship，注册后把 nameserver 指向 Cloudflare。
创建 Cloudflare Zone

让 Cloudflare 管 DNS。
从模板创建 GitHub repo

复制 template-page-static。
生成页面内容

标题、文案、FAQ、schema、表单、tracking、sitemap。
创建 Pages Project

用 Direct Upload 模式更适合批量自动化。
设置 GitHub Secrets

写入 CLOUDFLARE_API_TOKEN、CLOUDFLARE_ACCOUNT_ID。
GitHub Actions 部署

构建后用 Wrangler deploy 到 Pages。
绑定自定义域名

在 Pages 中关联 custom domain，同时 DNS 正确配置。不要只手动 CNAME。
冒烟测试

HTTP、SSL、表单、analytics、跳转、sitemap、移动端。
上线记录

记录部署 URL、域名、GitHub repo、Cloudflare project、成本、商业模式。

10.2 Workers SaaS SOP

定义产品和租户模型

先想清楚 user、workspace、tenant、billing 怎么对应。
创建 repo

从 template-worker-saas 复制。
创建 Cloudflare 资源

Worker、D1、R2、KV、Durable Objects、Workflows。
配置 wrangler.toml

绑定资源和环境变量。
配置 secrets

支付 key、邮件 key、AI key、Cloudflare token 等，不进代码仓库。
数据库 migration

D1 表结构必须自动迁移。
部署 staging

先部署非生产环境。
跑测试

API health、登录、支付 webhook、数据库读写、文件上传、权限隔离。
部署 production

wrangler deploy 或 GitHub Actions。
绑定 custom domain

Workers Custom Domain 需要 active Cloudflare zone；不能在已有 CNAME 的 hostname 上创建。
设置成本和限流

CPU limit、rate limit、请求配额、AI 调用额度。
监控和回滚

记录版本，必要时用 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 正常
域名续费提醒

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。

第五，先用服务收钱，再把重复部分产品化。

技术上，你要的是自动部署。

商业上，你要的是自动验证。

战略上，你要的是自动把机会变成现金流。