我们创建了一个由人工智能驱动的 WordPress 网站构建器，今天我们将其开源。 这是 QuickWP

几周前，我们发布了 QuickWP 的原型，这是一个人工智能驱动的 WordPress 网站构建器，它使用OpenAI 、 FSE 主题和WordPress Playground根据网站的主题和描述为用户生成个性化主题。

如果您还没有查看过，您可以在 Twitter（又名 X）上看到 QuickWP 的预览。

构建 QuickWP 对我们来说是一次充满挑战和学习的经历，今天，我们开源了该项目的代码库，这样您也可以从中学习，甚至可以在此基础上构建一些很棒的东西。

在本文中，我将讨论我们在 QuickWP 工作中遇到的想法、挑战和学到的东西。 如果您遇到类似的挑战，我希望这对您有所帮助。

这个想法

虽然我们已经考虑尝试 AI 和 OpenAI API 一段时间了，但我们从未计划创建一个 AI 网站构建器。 之前，我们尝试将 AI 与 Otter Blocks 插件集成，以使用 AI 提示从可用模式生成布局，但该实现非常原始。 结果非常通用，在提供的结果中没有太多考虑用户上下文。

鉴于块编辑器中的模式即使进行微小的更改也很容易被破坏，我们不能简单地要求 GPT 动态创建模式，甚至要求它替换内容。

当我们想到这个基于线框的想法时，一切都改变了。 很简单：我们创建一个带有线框和广泛调色板的 FSE 主题。 然后，通过人工智能，我们根据用户提示选择模式。

在 FSE 主题中，使用 theme.json 文件属性，我们可以轻松地从一处修改整个网站的样式。 这同样适用于我们的模式，以便我们在整个网站上保持统一，而不必担心不同的模式具有需要单独修改的不同设置。

在这里，我们还使用 CC0 图像目录来用图像填充网站，以便为用户提供更好的起点。

虽然这个想法听起来很简单，但我们需要进行一些尝试和错误才能达到可以生成对用户来说足够好的结果的程度。 目标是花费尽可能少的时间来创建用户可以从产品网站用作 SaSS 的原型。

项目堆栈概述

该项目需要多个部件，因此我们使用了多个堆栈，即任何能让我们更轻松地尽快制作原型的堆栈。

以下是该项目的各个部分：

• FSE 主题：项目的基础。 它包括各种模式和综合的 theme.json 文件。
• 基础插件：该插件具有使项目正常运行所需的所有功能和 UI。
• API端点：用户网站和OpenAI API之间通信的API端点。

这是显示整个工作流程的简化图。

FSE主题

FSE 主题是整个项目的基础。 为了使原型设计更容易，我们从二十四主题的分支开始。 我们几乎删除了所有模式并根据我们的需要自定义了 theme.json 属性。

FSE 主题最佳实践正在快速变化，对于每个版本的 WordPress，我们都有一种新的做事方式。 从默认主题的分支开始，我们可以用最少的工作建立坚实的基础。

就代码而言，大部分内容都如您在 FSE 主题中所期望的那样。 您会注意到的唯一区别是我们如何在模式中使用字符串和图像。

在这里，我们为每个字符串添加默认文本、特定于模板的命名空间以及默认预览命名空间。

默认文本是正常使用时出现在模式中的文本，以防有人在编辑器中添加模式或使用没有 QuickWP AI 的主题。

模板特定的命名空间是该特定字符串的标识符。 默认预览命名空间是一个共享命名空间，我们将其用于上下文中的所有字符串。 我们稍后再讨论这个问题。

AI提示生成

由于它是一个快速原型，我们希望探索更简单的测试和实现方法。 我们尝试了各种人工智能模型，但最终选择了最受欢迎的选项，即 OpenAI。 在开发阶段，我们使用了 GPT-4，因为 OpenAI 的最新模型提供的结果要好得多，但成本太高，因此我们决定转而使用 GPT-3.5 Turbo 来完成大多数任务。 我说大部分任务是因为我们仍在使用 GPT-4 来生成调色板，因为 GPT-3.5 的颜色种类不是很好

为了发出请求，我们尝试了 OpenAI 提供的不同选项，但发现 Assistant API 最适合我们的需求。 为了避免一些恶意行为者，我们还使用 OpenAI 的审核 API 来阻止处理与 OpenAI 内容政策不符的请求。 正如我们在发布后所看到的，人们试图尝试各种可能会给我们的 OpenAI 帐户带来麻烦的提示，因此添加审核是值得花时间的。 是的，它是免费使用的！

图像生成

当我们设想这个项目时，问题之一是如何生成图像。 当然，我们可以使用 Dall-E 或其他模型来做到这一点，但它们速度慢、质量低且相当昂贵。 事实证明，我们的思考方向是错误的。 当互联网上有数以百万计的 CC0 图像时，为什么还要生成图像？

经过一番考虑，我们选择了 Pexels。 选择 Pexels 的原因是它有更宽松的请求限制和良好的图像目录。 当然，我们会链接回应用程序上的原始图像。

如何维护站点范围内的上下文？

为了使这个项目顺利进行，我们需要解决的第一个问题是了解如何在为用户生成内容时维护站点范围内的上下文。 不同的模式有不同数量和类型的字符串，我们不能只是随意添加内容并希望它与网站相关。

这就是我们的好朋友 JSON 来救援的地方。 通过一些创造性的提示（在源代码中找到）和一致的 JSON 模式，我们可以在整个网站中维护上下文，并拥有相互补充的字符串，而不是随机的乱码。

如果您查看我们的模板之一，您将看到我们如何列出每个模式并附上说明，以便让 API 了解其用途以及它包含哪些字符串。

例如，这是该模板的第一个模式：

 { "order": 1, "slug": "quickwp/hero-centered", "name": "Hero Centered", "description": "Hero sections are used to introduce the product or service. They are the first and primary section of the website. This is a centered hero section with a large title, a subtitle and two buttons.", "category": "heroes_page_titles", "strings": [ { "slug": "hero-centered/title", "description": "Main title of the hero section" }, { "slug": "hero-centered/subtitle", "description": "Subtitle of the hero section" }, { "slug": "hero-centered/button-primary", "description": "Primary button text of the hero section" }, { "slug": "hero-centered/button-secondary", "description": "Secondary button text of the hero section" } ], "images": [ { "slug": "hero-centered/image", "description": "Background image of the hero section" } ] }

每个字符串以及名称空间还描述了它与模式其余部分的连接。 这使我们能够确保 GPT 不会在多个位置重复相同的内容，例如，保持副标题与模式标题相关。

当我们在站点上收到请求时，我们使用字符串 slug 来替换模式中的它。

虽然我们当前的实现很原始，但您可以使用此方法为字符串提供更多上下文，例如字符串的长度和音调。 这样，我们只交换数据而不交换标记。

我们需要为每个用户提供 WordPress 实例

我们需要解决的另一个问题是为每个用户会话提供一个 WordPress 实例。 在我们的实施中，我们在当前用户的 WordPress 实例上进行实时更改，然后使用现有的 WordPress 功能导出 FSE 主题。 除非有一种解决方案可以创建 WordPress 实例，而无需构建小型网络托管解决方案……

让我向您介绍 WordPress Playground。 Playground 允许您在浏览器中零点击运行 WordPress。 如果您还没有使用过 WP Playground，您一定会惊讶于它的强大！

您将使用 WordPress 构建什么？

现在我们已经向您介绍了我们面临的一些挑战，您将使用这些工具构建什么？ 我们希望这篇文章能够启发您使用我们讨论过的一些工具，例如 OpenAI API、FSE 主题和 WordPress Playground，并构建一些很棒的东西。 如果您这样做，请告诉我们，因为我们很乐意尝试！

再次强调，所有源代码都可以在我们的 GitHub 上找到，因此请随意以任何对您有帮助的方式使用它！