Farewell WordPress：我为外贸网站造了个新轮子

不是 WordPress 不够好，是我想做点不一样的

缘起

用了 10 年 WordPress。

从 2015 年第一次搭建博客，到后来做外贸网站、企业官网、产品展示站，WordPress 一直是我的首选。

直到最近，我做了一个决定：放弃 WordPress，自己造一套东西。

为什么？

不是因为 WordPress 不好，而是我想知道：如果从零开始，我会怎么设计一个外贸网站系统？

起点：重新定义”网站”

某个周末，我决定重构用了 8 年的 WordPress 网站。

不是因为它有问题，而是我突然意识到：我可能从来没有真正思考过”我需要什么”。

我的外贸网站：

• 多语言（目前 7 种，随时可扩展到 20+）
• 每周更新 2-3 次内容
• 主要流量来自 Google 自然搜索
• 没有用户系统、没有评论、没有复杂交互

这样一个网站，真的需要 PHP + MySQL + 插件生态吗？

我开始问自己一个问题：

如果让我用代码，从头定义一个”内容网站”，我会怎么做？

思考：我到底想要什么？

1. 内容应该是文件，不是数据库记录

WordPress 把内容存在数据库里。这很合理，但不适合我。

我想要的是：

content/
├── about.md
├── products/
│   ├── product-a.md
│   └── product-b.md
└── blog/
    ├── 2025-01-20-post.md
    └── 2025-01-25-post.md

• 每个文件就是一个页面
• 支持版本控制（Git）
• 可以用任何编辑器打开
• 可以批量处理（脚本、AI）

内容即代码。

2. 多语言应该是自动化的，不是手工复制粘贴

WordPress 的多语言插件让我每次更新都要重复 7 遍。

我想要的是：

# 写好英文版
echo "New product launched" > product-new.en.md

# 运行脚本
./translate.sh product-new.en.md

# 1 分钟后，所有语言全部生成（想加多少语言就加多少）
✓ product-new.es.md
✓ product-new.fr.md
✓ product-new.de.md
✓ product-new.ja.md
✓ product-new.ko.md
✓ product-new.pt.md
✓ product-new.zh.md
✓ product-new.ar.md  # 需要阿拉伯语？改个配置就行

翻译不应该是体力活。语言数量也不应该是限制。

3. 构建应该是确定性的，不是每次都可能出问题

WordPress 每次访问都要执行一遍渲染逻辑。这意味着：

• 插件冲突可能随时发生
• 数据库查询可能随时变慢
• 某个环节出错，整站挂掉

我想要的是：

# 构建一次
bun run build

# 生成所有页面（HTML + CSS + 资源）
dist/
├── en/
│   ├── index.html
│   ├── about/index.html
│   └── products/...
├── es/
│   ├── index.html
│   └── ...
└── ...

# 部署到 CDN
# 之后每次访问，都是直接返回这些文件
# 没有运行时，没有变数

构建时确定一切，运行时零意外。

4. 速度应该是物理极限，不是”还能接受”

WordPress 的 TTFB（Time to First Byte）通常在 1-3 秒。

我想要的是：

• 访客请求 → CDN 边缘节点直接返回 HTML
• 没有数据库查询
• 没有服务端计算
• TTFB < 100ms（物理延迟）

速度不应该被软件拖累。

实现：我做了什么？

我没有用现成的框架直接替换 WordPress。

我基于一些开源工具，搭建了一套适合我自己的系统。

核心架构

内容层：

• Markdown 文件 + Frontmatter（元数据）
• Git 版本控制
• 本地编辑器（VSCode + Vim）

构建层：

• 静态站点生成器（SSG）
• 自定义构建脚本（Bun + TypeScript）
• AI 翻译流水线（多模型策略：不同语言用不同 LLM）

部署层：

• Cloudflare 边缘网络（全球 300+ 节点）
• 自动化构建（Git Push → Auto Deploy）
• 零运维（没有服务器可以挂）

翻译自动化

这是最关键的部分。

我写了一套翻译系统：

// translate.ts（简化版）
async function translateContent(file: string) {
  const content = readFile(file);
  const languages = ['es', 'fr', 'de', 'ja', 'ko', 'pt', 'zh'];

  for (const lang of languages) {
    // 检查是否已翻译过（缓存）
    if (cacheExists(file, lang)) {
      console.log(`✓ ${lang} (cached)`);
      continue;
    }

    // 调用 AI 翻译（不同语言用不同模型）
    const translated = await aiTranslate(content, {
      targetLang: lang,
      preserveFormat: true, // 保留 Markdown 格式
      context: 'B2B SaaS product page' // 给 AI 上下文
    });

    // 保存翻译结果
    writeFile(`${file}.${lang}.md`, translated);
    console.log(`✓ ${lang} (translated)`);
  }
}

工作流：

1. 用 Markdown 写英文内容
2. 运行 bun run translate
3. 脚本智能选择模型翻译成所有目标语言（日语用 Claude、西语用 GPT-4o…）
4. 人工校对关键页面（首页、产品页）
5. Git Push → 自动部署

语言扩展：

• 想加新语言？配置文件里加一行，重新翻译即可
• 不同语言可以用不同的模型（质量 + 成本平衡）
• 整个架构完全灵活，没有硬编码限制

效率：

• 之前：2 小时手动复制粘贴
• 现在：1 分钟自动完成

构建流程

# 1. 读取所有 Markdown 文件
# 2. 解析 Frontmatter 和内容
# 3. 按语言分组
# 4. 生成 HTML（每种语言独立站点）
# 5. 优化资源（压缩、缓存策略）
# 6. 输出到 dist/

bun run build

# 输出结构：
dist/
├── en/
│   ├── index.html
│   ├── products/product-a/index.html
│   └── ...
├── es/
├── fr/
└── ...

特点：

• 每次构建输出完全一致（确定性）
• 所有页面预渲染（零运行时）
• 支持增量构建（只重新生成变更的页面）

部署

# Git Push 后，Cloudflare 边缘网络自动：
# 1. 拉取代码
# 2. 运行 bun run build
# 3. 分发到全球 300+ 边缘节点
# 4. 更新路由（零停机）

# 整个过程 2 分钟，感谢赛博活佛的慷慨

结果：能做什么？

1. 内容管理

• 用 Markdown 写内容（比 WordPress 编辑器更快）
• 所有内容版本化（Git 历史）
• 支持批量修改（脚本 + 正则）

2. 多语言

• 写一份英文，自动生成任意数量语言（配置即可扩展）
• 每种语言独立 URL（SEO 友好）
• 支持手动覆盖（AI 翻译不准时）
• 不同语言智能选择最适合的模型

3. 性能

• Lighthouse 评分 98/100
• TTFB < 100ms（全球任意位置）
• LCP < 0.5s（首屏渲染）

4. 开发体验

• 本地修改 → 热重载（< 100ms）
• 构建速度快（10,000 页面 < 30 秒）
• 零配置（一个配置文件搞定）

代价：失去了什么？

公平起见，说说这套系统的局限：

1. 不适合高频更新

如果你每小时都要发布新内容，静态生成可能不够灵活。

但对于外贸网站、企业官网、产品展示站？完全够用。

2. 需要一点技术能力

不是点点鼠标就能搞定。

你需要：

• 会用 Git（至少会 git add / commit / push）
• 会写 Markdown（5 分钟学会）
• 会运行脚本（复制粘贴命令）

但如果你是工程师，这些应该是基础技能。

3. 动态功能需要外接

• 评论系统？用 Giscus（基于 GitHub Discussions）
• 搜索功能？用 Pagefind（静态索引）
• 表单提交？用 Cloudflare Workers

但这恰恰是我想要的：用专业的服务做专业的事，而不是把所有功能塞进一个系统里。

反思：为什么要造轮子？

有人可能会问：市面上有那么多静态站点生成器（Astro、Next.js、Hugo），为什么要自己造轮子？

答案很简单：

因为我想知道”如果是我”会怎么做。

我不是说现有工具不好，而是：

• 我想要完全理解每一层的工作原理
• 我想要完全控制构建和部署流程
• 我想要为我的场景（外贸网站 + 多语言）定制优化

更重要的是：现在的时机刚刚好。

最近 vibe coding（AI 辅助编程）特别火。

以前造轮子需要几个月，现在可能只要几个周末：

• 不会写构建脚本？问 Claude / GPT
• 不懂某个 API？AI 直接给你写好示例
• 遇到 bug？AI 帮你 debug

AI 让”实现自己的想法”变得前所未有的容易。

你不再需要成为每个领域的专家，你只需要：

• 知道自己想要什么
• 会描述清楚需求
• 能理解和调试代码

这就是为什么我选择现在动手的原因。

造轮子不是为了”更好”，而是为了”学习”和”掌控”。而 AI 降低了这件事的门槛。

适合谁？

这套系统适合：

• 工程师（至少会基本的命令行和 Git）
• 内容驱动型网站（博客、官网、文档站）
• 多语言需求（翻译自动化是核心优势）
• 追求极致性能和可靠性

不适合：

• 非技术用户（没有可视化界面）
• 高频更新内容（新闻站、社交平台）
• 复杂动态功能（会员系统、实时聊天）

写在最后

这不是一篇”教你怎么做”的文章。

因为我也不知道这套系统能用多久，或者未来会怎么演化。

但我知道一件事：

有些事情，你只有自己做过，才会真正理解。

WordPress 是一个伟大的项目，它让数百万人拥有了自己的网站。

但对于我来说，现在是时候探索别的可能性了。

技术细节

如果你对实现细节感兴趣：

• 翻译脚本：不同语言用不同的大模型（GPT-4o、Claude、Gemini 灵活切换）+ 缓存机制
• 构建工具：基于开源 SSG + 自定义插件
• 部署平台：Cloudflare 边缘计算，赛博活佛的慷慨免费额度