我們創建了一個由人工智慧驅動的 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 上找到，因此請隨意以任何對您有幫助的方式使用它！