方木雁 代码改变世界 — 全栈开发 · AI 工程 · 安全研究 2026-08-17T15:20:00.000Z https://muyan-blog.pages.dev/ 方木雁 Hexo agent 时代如何搭建个人博客 https://muyan-blog.pages.dev/2026/08/17/agent-era-personal-blog/ 2026-08-17T15:20:00.000Z 2026-08-17T15:20:00.000Z

2026 年了，还有人搭博客吗？有——但方式变了：需求说清楚，剩下的交给 agent。

起因：一句话需求

我想搭一个个人博客，要求很具体：

深色终端风、模仿 coderliang.com、Hexo 生成、GitHub 存代码、Cloudflare Pages 免费托管、要评论区/搜索/RSS/深浅色切换。

然后我把它丢给了 DeepSeek Harness（一个 agent 开发环境），接下来的一个下午是这样的：

14:00  需求确认：Hexo + 复刻 coderliang 风格 + 四件套功能
14:30  抓取 coderliang.com 源码，提取设计 token（oklch 配色/字体/glow）
15:00  自研主题：8 个 EJS 模板 + 900 行 CSS + 交互 JS
16:00  构建报错 → 排查 → 修好 → 本地预览通过
17:00  推代码到 GitHub
18:00  开始踩坑（详见下文）
20:30  GitHub 故障日 → 改用 wrangler 直接上传 → 上线成功

全程我做的只有：回答几个选择题（技术栈、风格、功能）、点几次浏览器授权。其余全是 agent 干的。

三个经典坑（给后来者省时间）

坑 1：hexo-cli 不认你的项目

手动搭建 Hexo 项目时，如果 package.json 里没有这段：

"hexo": { "version": "7.3.0" }

那么 hexo generate 会静默打印帮助信息而不是报错。排查了半小时才发现是 hexo-cli 用 find_pkg 检查 json.hexo === 'object' 来判断目录是不是 Hexo 站点——字段缺失就直接当”不是 Hexo 项目”处理。

坑 2：Hexo 7 的生成器是独立包

hexo-generator-index / archive / category / tag 这 4 个包在 Hexo 7 里需要单独安装。漏装的表现是：构建日志里没有 index.html，首页直接不生成。

坑 3：npm 官方源在国内会挂起

安装 wrangler 时 npm 进程挂起数分钟无输出。杀掉换镜像源，27 秒装完：

npm install -D wrangler --registry=https://registry.npmmirror.com

最刺激的部分：GitHub 故障日

部署最顺利的路径本来是 Cloudflare → Connect to Git（授权 GitHub 后自动构建）。但那天运气不好——GitHub 正处于 Partial System Outage（部分系统故障）：

  • Connect to Git 反复报错：No server is currently available to service your request.
  • GitHub App 授权链接同样打不开
  • 状态页显示 Cloudflare 的 Pages/Workers 组件都 operational，但流程就是走不通

关键判断：**”No server is currently available” 出现在 github.com 域名的授权流程里，优先怀疑 GitHub 侧故障**。用状态 API 一查：

curl -s https://www.githubstatus.com/api/v2/status.json
# → "status": { "description": "Partial System Outage" }

curl 测试授权链接本身返回 200（说明链接有效），但 GitHub 官方确认全站约 20% 请求报错——curl 成功和浏览器报错可以同时成立，这就是 OAuth/App 安装多跳流程的脆弱之处。

破局：wrangler 直接上传

既然 Git 集成被故障卡死，就绕开它——用 Cloudflare 官方 CLI wrangler 直接把构建好的 public/ 传上去，这条路完全不经过 GitHub：

npx wrangler login    # 浏览器授权一次
npm run build
npx wrangler pages project create muyan-blog-temp --production-branch=main
npx wrangler pages deploy public --project-name=muyan-blog-temp --branch=main

第一次部署还赶上瞬时网络抖动（fetch failed），重试一次就通了：

✨ Uploaded 34 files (4.65 sec)
✨ Deployment complete! https://muyan-blog-temp.pages.dev

博客上线了。这个临时方案的核心约束：Direct Upload 项目以后不能直接切换成 Git 集成项目，所以临时项目必须用独立名字（-temp 后缀），等 GitHub 恢复后再建正式的 Git 集成项目并迁移域名。

agent 时代的正确姿势：把经验固化成 skill

这次部署踩的坑——hexo 字段、独立生成器、npm 镜像、故障诊断顺序、wrangler 备份方案、临时项目命名策略——如果下次再搭一个博客，难道要重新踩一遍吗？

所以我把整套经验固化成了一个 skill：遵循 DeepSeek Harness / Claude 系的 skill 格式（SKILL.md + YAML frontmatter），任何 agent 加载后都能直接按图施工。

skills/deploy-hexo-blog-cloudflare-1.0.0/
└── SKILL.md    # 完整操作手册 + 故障排查 + 网络适配

完整内容贴在文末。这就是 agent 时代的迭代方式：让 agent 干活 → 把过程沉淀成 skill → 下次 agent 带着 skill 干得更快。写博客记录的不只是结果，还有让结果可复现的资产。

附：可直接使用的 skill

以下内容保存为 SKILL.md（放在 skills/deploy-hexo-blog-cloudflare-1.0.0/ 目录下），即可被 DeepSeek Harness 或兼容 Claude skill 格式的 agent 环境加载使用：

---
name: deploy-hexo-blog-cloudflare
description: "搭建并部署 Hexo 静态博客到 Cloudflare Pages / GitHub Pages，含故障排查与备用方案。当用户要求搭建个人博客、部署 Hexo 站点、复刻深色终端风博客主题、处理 Cloudflare Pages 部署失败（如 GitHub 故障导致 Connect to Git 报错）、或用 wrangler 直接上传部署时使用。触发词：搭建博客、部署博客、Hexo、Cloudflare Pages、GitHub Pages、wrangler、静态博客、Pages 部署报错。"
---

# 搭建并部署 Hexo 博客到 Cloudflare Pages

把一套完整的 Hexo 静态博客从零搭建到 Cloudflare Pages 上线（含 GitHub Pages 备选、故障排查、中国大陆网络适配）。基于 2026-08 实战经验，踩过的坑全部记录在内。

## 适用场景

- 用户要搭个人博客，已选定或接受 Hexo（Node 生态、中文资料多）
- 部署目标：Cloudflare Pages（主）或 GitHub Pages（备）
- 需要复刻深色终端/霓虹风设计（类似 coderliang.com）时，自研主题而非套现成主题

## 一、项目骨架（关键坑点）

### 1. package.json 必须包含 `hexo` 字段

hexo-cli 通过 `find_pkg` 判断目录是不是 Hexo 站点：读取 package.json 并检查 `typeof json.hexo === 'object'`。**缺少该字段时，`hexo generate` 会静默打印 usage 帮助而不是报错**，极易误判。

```json
{
  "name": "my-blog",
  "scripts": {
    "build": "hexo generate && cp _headers public/_headers",
    "server": "hexo server",
    "deploy:pages": "wrangler pages deploy public --project-name=my-blog-temp --branch=main"
  },
  "hexo": { "version": "7.3.0" },
  "dependencies": {
    "hexo": "^7.3.0",
    "hexo-generator-archive": "^2.0.0",
    "hexo-generator-category": "^2.0.0",
    "hexo-generator-feed": "^3.0.0",
    "hexo-generator-index": "^4.0.0",
    "hexo-generator-search": "^2.4.3",
    "hexo-generator-tag": "^2.0.0",
    "hexo-renderer-ejs": "^2.0.0",
    "hexo-renderer-marked": "^6.3.0",
    "hexo-server": "^3.0.0"
  },
  "devDependencies": { "wrangler": "^4.123.0" }
}
```

### 2. Hexo 7 的 index/archive/category/tag 生成器是独立包

`hexo init` 默认模板会装这 4 个包。手动搭建时**漏装则首页 index.html 不会生成**（只有 search.json、文章页等），生成文件清单里没有 index.html 就是这个问题。

### 3. 中国大陆网络：npm 用镜像源

npm 官方源在本场景多次卡死（进程挂起数分钟无输出）。遇到就杀进程换镜像：

```bash
npm install -D wrangler --registry=https://registry.npmmirror.com
```

### 4. 主题结构（自研主题）

```
themes/<name>/_config.yml        # 主题配置（品牌/导航/侧栏/Giscus）
themes/<name>/layout/            # EJS 模板：layout/index/post/archive/category/tag/page + _partial/
themes/<name>/source/css|js      # 原生 CSS/JS，无需 stylus 渲染器
```

- 首页 hero 判断用 `is_home()` 辅助函数（`page.layout === 'index'` 不可靠）
- 目录辅助函数用法：`<% if (typeof toc === 'function') { %><%- toc(page.content, {list_number: false}) %><% } %>`
- 搜索：`hexo-generator-search` 生成 `search.json`，前端 fetch 过滤
- RSS：`hexo-generator-feed` 生成 `atom.xml`
- 阅读量：不蒜子 `<script async src="//busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js">`，页面元素 `id="busuanzi_value_page_pv"`
- 深浅色切换：`data-theme` 属性 + localStorage + `color-scheme`，CSS 变量双套 token
- `_headers`（安全响应头）放仓库根，构建脚本 `cp _headers public/_headers` 复制进去（Hexo 会忽略 source/ 下划线开头文件）

## 二、部署到 Cloudflare Pages（Git 集成，主方案）

1. 建 GitHub 仓库并推送（注意 git 需先 `git config user.name/email`）
2. Cloudflare 控制台 → Workers & Pages → Create → Connect to Git → 授权时 **Only select repositories**，只勾博客仓库
3. 构建配置：
   - Framework preset: `Hexo`
   - Build command: `npm run build`（带 _headers 复制）
   - Build output directory: `public`
4. Save and Deploy → 得到 `https://<project>.pages.dev`

## 三、故障排查（本次实战核心）

### 现象：Connect to Git 报 "No server is currently available to service your request."

**优先怀疑 GitHub 侧故障，而不是 Cloudflare**。诊断顺序：

1. 查官方状态 API（比状态页快、可脚本化）：
   - `https://www.githubstatus.com/api/v2/status.json` → `status.description`
   - `https://www.cloudflarestatus.com/api/v2/status.json` → `status.description`
   - 细粒度组件：`.../api/v2/components.json`，注意 Cloudflare 的 Pages/Workers 组件即使全局 Minor Outage 也可能显示 operational
2. 该错误页出现在 github.com 域名时，用 curl 验证链接本身：`curl -sI https://github.com/apps/cloudflare-workers-and-pages` 返回 200/302 说明链接有效
3. 关键结论（2026-08-17 实测）：GitHub Partial System Outage 时，App 安装/OAuth 流程报错率显著高于首页访问；curl 200 与浏览器报错可同时成立（~20% 错误率）

### 现象：npm install 挂起

杀进程 → 换 `--registry=https://registry.npmmirror.com` 重装。若包已下载完整但 `.bin` 链接未生成（npm 收尾卡住），可临时用 `node node_modules/wrangler/bin/wrangler.js` 直接执行。

### 现象：wrangler pages deploy 报 "fetch failed"

多为瞬时网络抖动，直接重试（首次 522 是部署传播，重试后 200）。

### 验证清单（上线后必查）

```bash
UA="Mozilla/5.0 ... Chrome/125.0"
for p in "" "css/style.css" "js/main.js" "search.json" "atom.xml"; do
  curl -s -o /dev/null -w "/$p -> %{http_code}\n" "https://<project>.pages.dev/$p"
done
curl -sI -A "$UA" https://<project>.pages.dev/css/style.css | grep -iE "x-content-type|x-frame|referrer"  # 验证 _headers 生效
```

注意：Cloudflare 边缘会拦截裸 curl UA（403），必须带浏览器 UA；python urllib 默认 UA 也会 403。

## 四、备用方案：wrangler 直接上传（绕开 GitHub）

适用于 GitHub 故障期间或不想用 Git 集成的场景：

```bash
npx wrangler login                              # 浏览器 OAuth 授权
npx wrangler pages project create <temp-name> --production-branch=main
npx wrangler pages deploy public --project-name=<temp-name> --branch=main
# 之后每次更新：
npm run build && npx wrangler pages deploy public --project-name=<temp-name> --branch=main
```

**硬性约束：Direct Upload 项目之后不能切换成 Git 集成项目。** 因此：
- 临时上线用独立项目名（如 `muyan-blog-temp`），避免占用正式项目名
- GitHub 恢复后：新建正式 Git 集成项目（正式名）→ 迁移自定义域名 → 删除临时项目

## 五、GitHub 侧就绪检查

- `gh auth login`（设备码流程：复制一次性代码 → 浏览器打开 github.com/login/device → 输入代码授权；"按了两次"是正常流程，不是重复登录）
- 验证：`gh auth status` 显示 Logged in；`git ls-remote origin` 成功
- 升级 Git 集成的时机：githubstatus.com 恢复 All Systems Operational 后，再等 15~30 分钟，用无痕窗口重新从 Cloudflare 控制台走 Connect to Git（**不要复用旧的 ?state=xxx 链接，state 一次性且有时效**）

## 六、交付清单

- Hexo 站点：`_config.yml`（url 上线前必改）、主题、scaffolds、示例文章
- 部署配置：`.github/workflows/pages.yml`（GitHub Pages 备选）、`_headers`
- README：部署指南（Git 集成 + wrangler + Giscus 评论区配置）
- 文档：`docs/plans/YYYY-MM-DD-blog-design.md` 设计文档
- 验证：`npm run build` 全绿 + 线上 curl 清单通过 + 截图存档

结尾

把上面这份 skill 丢给任何 agent，它就能独立复刻整个流程。而我写下这篇文章本身，就是让它传播的方式——agent 时代，经验不是写给自己看的，是写给 agent 看的。

Happy hacking! 🚀

]]> 从零到上线只花了一个下午——这篇记录 agent 帮我搭博客的全过程：设计复刻、三个经典坑、GitHub 故障日的破局，以及我把整套经验固化成 skill 的姿势。 闲置的 3090 不要丢，本地部署获取无限 token！ https://muyan-blog.pages.dev/2026/08/17/local-3090-unlimited-token/ 2026-08-17T13:03:00.000Z 2026-08-17T13:03:00.000Z

2026 年了，谁家抽屉里还没块吃灰的 3090？与其让它在矿场发光发热，不如拿回来当你的私人 token 印钞机。

为什么是 3090

3090 是二手市场性价比最高的卡之一：24GB 显存、350W 功耗、无 NVLink 桥接的烦恼，关键是便宜。现在一张二手 3090 的价格大概能换 30 万 token 的 API 调用——听起来不少，但 API 是租的，卡是自己的。

本地部署的核心收益不是省钱，而是三件事：

  1. 无限 token：没有限流、没有额度、没有”高峰期排队”
  2. 数据不出门：代码、文档、私有知识全留在自己机器上
  3. 完全可控：量化精度、上下文长度、并发策略全部自己说了算

部署方案：vLLM + OpenWebUI

选型思路：推理引擎用 vLLM（吞吐高、显存管理好），前端用 OpenWebUI（类 ChatGPT 的界面，支持多模型切换、RAG、函数调用）。

第一步：拉镜像

# 推理引擎
docker pull vllm/vllm-openai:latest

# 前端
docker pull ghcr.io/open-webui/open-webui:main

第二步：启动 vLLM

以 Qwen3-8B 为例（4bit 量化，24GB 显存绰绰有余）：

docker run --gpus all --shm-size=8g \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-8B \
  --quantization gptq \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9

启动后即获得一个 OpenAI 兼容接口：http://localhost:8000/v1，任何 OpenAI SDK 都能直接对接。

第三步：启动 OpenWebUI

docker run -d -p 3000:8080 \
  -v open-webui:/app/backend/data \
  -e OPENAI_API_BASE_URL=http://host.docker.internal:8000/v1 \
  ghcr.io/open-webui/open-webui:main

打开 http://localhost:3000 注册账号，就能在浏览器里和你的私有模型聊天了。

性能实测

配置输入吞吐输出吞吐首 token 延迟
Qwen3-8B GPTQ 4bit2450 tok/s1350 tok/s~180ms
Llama-3.1-8B AWQ 4bit2210 tok/s1280 tok/s~210ms
DeepSeek-R1-Distill-7B1980 tok/s890 tok/s~240ms

数据基于单卡 3090 + vLLM 0.8.x，具体数值因显存、温度、功耗墙而异。

几个坑

  1. 供电：3090 峰值 350W，别拿 450W 的老电源硬扛，会黑屏重启
  2. 散热：机箱风道不好的话，半小时后开始降频，建议 80% 功耗墙
  3. **--gpu-memory-utilization**：设太高会 OOM，0.85~0.92 是安全区
  4. macOS 用户：别想了，Apple Silicon 跑量化小模型可以，跑 8B 就别指望了

小结

$ ./start.sh
✓ vLLM 已启动 (0.8.2)  port 8000
✓ OpenWebUI 已启动   port 3000
$ curl localhost:8000/v1/chat/completions ...
✓ 返回 200, token 余额: ∞

本地部署没有想象中那么难——一条 docker 命令的事。真正难的是开始：把卡从抽屉里拿出来。

]]> 把吃灰的 3090 变成私有 LLM 服务：vLLM + OpenWebUI 一条龙，告别 API 限流，token 想用多少用多少。 我给在线 Markdown 接上了 MCP，现在 AI 能直接替我写稿了 https://muyan-blog.pages.dev/2026/08/14/markdown-mcp-ai-writing/ 2026-08-14T12:00:00.000Z 2026-08-14T12:00:00.000Z

以前 AI 是替你”想”，接上 MCP 之后，AI 开始替你”做”了。

背景

我一直在维护一个在线 Markdown 编辑器（对，就是那个烧了一千刀后来开源的项目）。读者反馈最多的一句话是：

“AI 能不能直接把我写的东西排版好？”

答案是可以，但绕了一圈。传统做法是让 AI 生成完整 Markdown，用户复制粘贴回编辑器——体验割裂，而且长文经常被截断。接入 MCP 之后，AI 可以直接操作编辑器：新建文档、写入内容、修改标题层级、插入代码块，一气呵成。

什么是 MCP

MCP（Model Context Protocol）是 Anthropic 2024 年底开源的协议，定位是”AI 应用的 USB-C 接口”：

  • Host：AI 客户端（Claude Desktop、Cursor、各种 Agent）
  • Server：暴露工具给 AI 用的服务（文件系统、数据库、浏览器……）
  • Client：Host 内部负责和 Server 通信的组件
graph LR
  A[AI Model] --> B[Host]
  B --> C[MCP Client]
  C <-->|JSON-RPC 2.0| D[MCP Server]
  D --> E[你的应用/数据]

实现：Markdown 编辑器的 MCP Server

我基于官方 TypeScript SDK 写了一个极简 Server，暴露三个工具：

工具名作用参数
new_doc新建文档title, content?
write_markdown写入/覆盖内容doc_id, content
patch_markdown局部修改（按行号/标题定位）doc_id, operation, target, content

核心代码只有几十行：

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new McpServer({
  name: 'md-editor',
  version: '1.0.0',
});

server.tool(
  'write_markdown',
  { doc_id: z.string(), content: z.string() },
  async ({ doc_id, content }) => {
    await docs.update(doc_id, content);
    return { content: [{ type: 'text', text: `✓ 已写入 ${doc_id}` }] };
  }
);

await server.connect(new StdioServerTransport());

效果

接好之后，我在 Claude 里说：

“把我草稿箱里那篇关于 MCP 的文章，按三级标题重新组织，加一个对比表格，顺便在开头加引用块。”

AI 的响应变成了一连串工具调用——打开草稿、读取内容、重组标题、插入表格——最后告诉我”已全部完成，刷新看看”。整个过程不需要复制粘贴一次。

关键心得

  1. 工具粒度要小：write_markdown 一把梭很容易覆盖错误内容，patch_markdown 按标题定位更安全
  2. 必须做撤销：AI 写错内容后，Ctrl+Z 是用户最后的救命稻草，我在 Server 里加了快照机制
  3. 返回要可读：工具返回的 text 是 AI 判断下一步的依据，写清楚”做了什么、当前状态是什么”
  4. 限流与配额：本地 AI 还好，云端模型调用工具是有成本的，要做好每次调用的审计

下一步

MCP 的生态还在爆发期：文件系统、浏览器、数据库、GitHub 的官方 Server 都已就绪。我下一步打算给编辑器接上浏览器 MCP，让 AI 写完文章之后直接去查引用来源的真实性。

代码已开源，链接在 GitHub —— 欢迎 star，更欢迎提 PR。

]]> MCP（Model Context Protocol）让 AI 从「聊天」进化成「干活」。这篇文章记录我把在线 Markdown 编辑器接入 MCP Server 的全过程。 一次扫描 8000 个端口之后：聊聊公网暴露面 https://muyan-blog.pages.dev/2026/08/12/exposed-surface-scan/ 2026-08-12T01:30:00.000Z 2026-08-12T01:30:00.000Z

攻击者不需要”黑进”你的系统，他只需要找到一个你忘了关的门。

一切从 nmap 开始

红队评估的第一步永远是侦察（Reconnaissance）。拿到授权后，我对目标的一个 /24 网段做了全端口扫描：

nmap -sS -p- -T4 --min-rate 2000 -oG all.txt 203.0.113.0/24

结果：**254 个 IP，开放端口 8000+**，其中高价值目标（80/443/22/3389/3306/6379 等）集中在 37 个主机上。

⚠️ 免责声明：以下所有内容均为攻防演练场景，请勿对未授权目标执行任何扫描。

高价值目标画像

把 8000 个端口按服务类型归类，大致是这样：

服务端口数量风险等级
SSH2223中
HTTP/HTTPS80/44331高
RDP33896高
MySQL/Redis3306/63794严重
打印机/摄像头9100/55411低
其他随机高位端口7900+需甄别

最扎眼的几个发现：

  1. Redis 无认证直接暴露公网 —— 经典未授权访问，redis-cli -h x.x.x.x ping 直接回 PONG
  2. 一个 Jenkins 开在 8080，管理后台弱口令 admin/admin
  3. 摄像头 RTSP 流未加密，ffplay rtsp://... 就能看画面

为什么会出现这么多暴露面

和运维聊完，暴露面失控的原因基本是这四类：

1. 默认端口 + 无认证

# 反面教材
services:
  redis:
    image: redis:latest
    ports:
      - "6379:6379"   # 直接映射到公网，且没设密码

2. 临时开的口子忘了关

线上排查问题临时 iptables -A INPUT -p tcp --dport 9000 -j ACCEPT，问题解决后没人回收规则。

3. 云安全组规则太宽

0.0.0.0/0 的入站规则是重灾区，尤其是一些”图省事”的运维。

4. 资产清单缺失

很多团队根本没有资产台账，自己都不知道公网挂了哪些服务——扫描结果比运维自己的记录还全。

暴露面收敛清单

给这位运维同学的整改建议，也是通用最佳实践：

# 1. 立即下线未使用的服务
systemctl disable --now redis-server

# 2. Redis/DB 绑定内网 + 认证
sed -i 's/^# bind 127.0.0.1/bind 127.0.0.1/' /etc/redis/redis.conf
redis-cli config set requirepass "$(openssl rand -hex 16)"

# 3. 一键排查所有对外开放端口
ss -tlnp | awk '{print $4}' | grep -v '127.0.0.1\|::1\|0.0.0.0:22\|0.0.0.0:80\|0.0.0.0:443'

更系统的做法：

  • 资产台账：所有公网服务登记 IP/端口/负责人/用途，用 CMDB 或简单的 CSV 都行
  • 收敛默认策略：云安全组默认拒绝，按需放行，并加上来源 IP 白名单
  • 周期性扫描：每月一次 nmap + Nuclei 自动扫，结果和台账比对
  • SSO 统一认证：所有管理后台接入 SSO，禁止本地弱口令

复盘

$ ./scan.sh
[+] 扫描 254 个 IP
[+] 发现开放端口 8000+ 个
[+] 高危暴露面 4 个 → 已下发整改工单
[+] 复测通过 4/4
[✓] 本次演练暴露面收敛完成

安全不是买来的，是数出来的——先把公网暴露面数清楚，再谈防火墙和 WAF。你连自己暴露了什么都不知道，攻击者可是知道的。

]]> 攻防演练的起点永远是侦察。这篇文章复盘一次针对公网 IP 段的端口扫描，以及暴露面收敛的实操清单。 24 小时 AI 出海建站，这套开源模板直接抄 https://muyan-blog.pages.dev/2026/08/10/ai-saas-starter-open-source/ 2026-08-10T00:00:00.000Z 2026-08-10T00:00:00.000Z

不是”AI 时代不需要建站”，而是”AI 时代建站快到你来不及犹豫”。

起因

上个月有个做 SaaS 的朋友找我：”我想做个落地页 + 订阅支付，一周能搞定吗？”

我说：不用一周，24 小时。

于是我用一个周末验证了这件事——从零搭了一个带 Stripe 订阅、多语言、SEO 全配齐的出海站模板，并把它开源了。

技术栈

层选型理由
框架Next.js 15 (App Router)SSR/SSG 双模，出海 SEO 友好
部署Cloudflare Pages全球 CDN，免费额度够个人项目
支付Stripe Checkout出海标配，信用卡订阅一键接
数据库Cloudflare D1 + DrizzleSQLite 兼容，边缘数据库
样式Tailwind CSS v4原子化，落地页开发飞快

架构

┌────────────┐     ┌──────────────────┐
│  Browser    │ ──▶ │  Cloudflare CDN   │
└────────────┘     └────────┬─────────┘
                            │
              ┌─────────────┴─────────────┐
              │  Next.js (SSG/ISR)        │
              │  Pages Functions (API)    │
              └──────┬────────────┬───────┘
                     │            │
              ┌──────┴───┐  ┌─────┴────────┐
              │ Cloudflare│  │ Stripe      │
              │ D1 (SQLite)│  │ Checkout    │
              └──────────┘  └──────────────┘

Pages Functions 处理 /api/* 路由，Stripe Webhook 走 onRequestPost，整个项目不需要一台传统服务器。

一天的时间分配

09:00  脚手架 + 落地页首屏（标题、Hero、CTA）
11:30  定价页三档卡片 + FAQ + 页脚
14:00  Stripe Checkout 接入 + Webhook 落库
17:00  i18n（中/英）+ SEO 元信息 + OG 图
20:00  部署到 Cloudflare Pages + 自定义域名
22:00  性能压测：Lighthouse 98 / 全球延迟 < 120ms

关键代码：Stripe 订阅

// app/api/checkout/route.ts
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const { priceId } = await req.json();
  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: `${req.headers.get('origin')}/success`,
    cancel_url: `${req.headers.get('origin')}/#pricing`,
  });
  return Response.json({ url: session.url });
}

Webhook 校验签名 + 幂等处理：

export async function onRequestPost(context: EventContext) {
  const sig = context.request.headers.get('stripe-signature')!;
  const event = stripe.webhooks.constructEvent(
    await context.request.text(), sig, process.env.STRIPE_WEBHOOK_SECRET!
  );
  if (event.type === 'checkout.session.completed') {
    await db.insert(users).values({ email: event.data.object.customer_email! });
  }
  return new Response('ok');
}

出海建站的三个隐藏坑

  1. Stripe 需要海外主体：个人开发者可以用 Stripe Atlas（美国公司），或走 Paddle/LemonSqueezy 的 Merchant of Record（平台代收，无主体也能收）
  2. 货币与税费：Stripe 自动处理销售税，但定价时要把 Stripe 手续费（2.9% + 30¢）算进成本
  3. 域名邮件：别用免费邮箱收付款通知，买域名时顺手配个 Google Workspace 或 Zoho

开源地址

模板已开源：github.com/your-github-username/ai-saas-starter

$ git clone ... && npm i && npm run dev
✓ 本地跑起来 3 分钟
$ npm run deploy
✓ Cloudflare Pages 部署完成

拿去用，改改文案和配色就是你的产品。记得回来给我个 star ⭐

]]> 从想法到上线只花了 24 小时：Next.js + Cloudflare Pages + Stripe 的出海建站模板，我把它开源了。