Storyblok CMS：開發者完整指南 [2026]

Storyblok CMS：開發者完整指南 [2026]

Storyblok 是少數讓內容編輯者能實際「看見」他們正在編輯內容的無頭 CMS（Headless CMS），而這項單一功能徹底改變了開發者與編輯者之間的協作動態。在 C 輪融資中籌集 8,000 萬美元 並於 2026 年 3 月推出工作流程自動化功能後，深入了解 Storyblok 的優勢、不足之處，以及它是否適合您的下一個專案，顯得格外重要。

什麼是 Storyblok？

Storyblok 是一款內建視覺化編輯器的無頭 CMS，由 Dominik Angerer（執行長）和 Alexander Feiglstorfer（技術長）於 2017 年在奧地利林茨創立。它採用名為 Bloks 的元件式架構，並透過 REST 和 GraphQL API 交付內容。Adidas、Tesla 和 Oatly 等企業皆採用 Storyblok，該公司已透過其 C 輪融資 累計籌集 1.38 億美元資金。

無頭 CMS 將內容與前端分離，您透過 API 管理內容，而您的 React、Vue 或 Astro 應用程式則負責消費這些內容。這部分與 Contentful、Sanity、Strapi 及其他所有無頭選項並無二致。Storyblok 的不同之處在於其視覺化編輯器。

我們在四個生產環境網站上運行不同的無頭 CMS（包括為本部落格提供支援的 Sanity）。根據實際操作經驗，Storyblok 的比較結果如下：視覺化編輯器確實減少了開發者與內容團隊之間的來回溝通。編輯者不再需要填寫表單並詢問「這看起來會是什麼樣子？」，而是能直接看到實際頁面。這是真正的工作流程改進，而非僅僅是行銷話術。

其核心架構可分為兩個概念：Stories（您的頁面或內容條目）和 Bloks（可重複使用的元件，如主視覺區塊、特色網格或行動呼籲按鈕）。開發者在 Storyblok 儀表板中定義 Blok 結構描述，編輯者則將其拖放至 Stories 中。內容透過 Content Delivery API 傳送至您的前端。

除了 Adidas 和 Tesla 之外，其他知名客戶還包括 Virgin Media O2、dm-drogerie markt、Oatly、Spendesk 和 Panini。若想深入了解 Storyblok 與其他主要選項的比較，請參閱 我們的無頭 CMS 比較文章。

Storyblok 視覺化編輯器如何運作？

Storyblok 的視覺化編輯器會在 iframe 中載入您的前端，並在每個元件上覆蓋可編輯區域。內容編輯者能看到訪客將看到的即時預覽，並可對每個 Blok 進行點擊編輯。這需要在您的前端應用程式中設定 StoryblokBridge JavaScript 函式庫。

這項功能使 Storyblok 有別於 Contentful 的表單式方法、Sanity 的程式碼即結構描述方法 或 Strapi 的管理面板。那些 CMS 提供給編輯者的是帶有欄位的表單，而 Storyblok 提供給編輯者的是實際頁面。

Iframe 架構

其底層運作方式如下：當編輯者在 Storyblok 儀表板中開啟一個 Story 時，視覺化編輯器會在 iframe 內載入您的前端應用程式。Storyblok 會將 _editable 屬性注入每個 Blok 的資料中（僅限草稿內容），而 StoryblokBridge JavaScript 函式庫則監聽變更。當編輯者點擊元件時，bridge 會與父層 Storyblok 視窗通訊以開啟正確的欄位編輯器。

結果如何？編輯者可以直接點擊主視覺區塊來編輯標題。他們可以將新的推薦見證 Blok 拖曳至定價區塊下方。他們能立即在預覽中看到變更反映出來。無需經歷「儲存並檢查暫存網站」的循環。

需要注意的一點是：視覺化編輯器僅適用於草稿內容，不適用於已發布內容。您的預覽 URL 需要指向一個抓取草稿資料的應用程式版本。這在設定初期常讓人措手不及。

設定 StoryblokBridge

以下是在 Next.js App Router 專案中的典型設定。您需要安裝 @storyblok/react：

// app/components/StoryblokProvider.js
"use client";

import { storyblokInit, apiPlugin } from "@storyblok/react/rsc";
import Hero from "./bloks/Hero";
import FeatureGrid from "./bloks/FeatureGrid";
import CallToAction from "./bloks/CallToAction";

storyblokInit({
  accessToken: process.env.NEXT_PUBLIC_STORYBLOK_TOKEN,
  use: [apiPlugin],
  components: {
    hero: Hero,
    feature_grid: FeatureGrid,
    call_to_action: CallToAction,
  },
});

export default function StoryblokProvider({ children }) {
  return children;
}

接著使用 provider 包裝您的版面配置，並使用 StoryblokStory 元件以啟用即時編輯：

// app/[...slug]/page.js
import { StoryblokStory } from "@storyblok/react/rsc";
import { fetchStory } from "@/lib/storyblok";

export default async function Page({ params }) {
  const story = await fetchStory(params.slug?.join("/") || "home");

  return <StoryblokStory story={story} />;
}

StoryblokStory 元件會自動處理 bridge 連接，註冊 iframe 監聽器，將 _editable 屬性套用至您的 Bloks，並在視覺化編輯器中啟用點擊編輯功能。您無需手動連接這些設定。

Storyblok 的元件架構（Bloks 和 Stories）

Storyblok 使用兩個核心概念來組織內容：Stories（頁面或內容條目）和 Bloks（可重複使用的元件，如主視覺區塊、特色網格或行動呼籲按鈕）。開發者在 Storyblok 儀表板中定義 Blok 結構描述，編輯者則透過將 Bloks 拖放至 Stories 中來組成頁面。

您可以將其想像成樂高積木。Stories 是底板，即您正在建構的頁面。Bloks 是單獨的積木，例如主視覺區塊、推薦見證卡片或定價表格。您定義每個 Blok 類型擁有的欄位（標題、圖片、行動呼籲文字），編輯者則將它們組合在一起。

Stories：您的內容條目

Storyblok 中的每個頁面、文章或內容條目都是一個 Story。Stories 存在於資料夾結構中（類似檔案系統），且每個 Story 都有一個對應到 URL 的 slug。Story 的主體由 Bloks 組成，本質上是一個容器。

Stories 也可以存放非頁面內容。您可能有一個名為「site-settings」的 Story，用於儲存導航連結、頁尾文字和社群媒體 URL。這種靈活性類似於在 Sanity 中使用 singleton 文件的方式。

Bloks：可重複使用的建構模組

Bloks 分為兩種類型：可巢狀化（nestable） 和 內容類型（content type，根層級）。內容類型 Bloks 定義 Story 的頂層結構描述（例如「Page」或「BlogPost」）。可巢狀化 Bloks 則是編輯者拖曳至 Story 主體中的元件，如主視覺區塊、圖片畫廊或 FAQ 手風琴選單。

每個 Blok 都有一個定義其欄位的結構描述。您在 Storyblok 儀表板的「Components」（元件）下建立這些結構描述（而非在程式碼中，這是與 Sanity 的程式碼即結構描述方法 的關鍵差異）。

實際的內容建模

以下是透過 Management API 定義 Hero Blok 結構描述時的樣子：

{
  "component": {
    "name": "hero",
    "display_name": "Hero Section",
    "schema": {
      "headline": { "type": "text", "required": true, "pos": 0 },
      "subheadline": { "type": "textarea", "pos": 1 },
      "background_image": { "type": "asset", "filetypes": ["images"], "pos": 2 },
      "cta_text": { "type": "text", "pos": 3 },
      "cta_link": { "type": "multilink", "pos": 4 }
    },
    "is_root": false,
    "is_nestable": true
  }
}

以及渲染此 Blok 的 React 元件：

// components/bloks/Hero.jsx
import { storyblokEditable } from "@storyblok/react/rsc";

export default function Hero({ blok }) {
  return (
    <section {...storyblokEditable(blok)} className="hero">
      <div className="hero-content">
        <h1>{blok.headline}</h1>
        {blok.subheadline && <p>{blok.subheadline}</p>}
        {blok.cta_text && (
          <a href={blok.cta_link?.cached_url} className="cta-button">
            {blok.cta_text}
          </a>
        )}
      </div>
      {blok.background_image?.filename && (
        <img
          src={blok.background_image.filename}
          alt={blok.background_image.alt || ""}
        />
      )}
    </section>
  );
}

storyblokEditable(blok) 呼叫是用於在視覺化編輯器中啟用點擊編輯的功能。若缺少此功能，元件雖能正常渲染，但編輯者無法點擊它以編輯欄位。這點容易遺漏，除錯時也相當痛苦。

Storyblok API：REST vs GraphQL vs Management

Storyblok 提供三種 API：Content Delivery API（REST，大多數專案推薦使用）、GraphQL API（唯讀，當您需要選擇性欄位抓取時很有用）以及 Management API（用於程式化內容操作，如遷移和批量更新）。Storyblok 建議新專案使用 REST。

大多數無頭 CMS 指南完全跳過 API 層。這是一個錯誤，因為您選擇的 API 會影響建置時間、快取策略和速率限制餘裕。

Content Delivery API (REST)

這是主要 API，也是您 90% 時間會使用的 API。它支援過濾、排序、分頁以及解析 Stories 之間的關係。付費方案的速率限制相當寬鬆：每秒 50 次請求。

// Fetching a story via the Content Delivery API
const response = await fetch(
  `https://api.storyblok.com/v2/cdn/stories/home?version=draft&token=${process.env.STORYBLOK_TOKEN}`
);
const { story } = await response.json();
console.log(story.content); // Your Bloks data

GraphQL API

GraphQL API 為唯讀，且具有不同的速率限制（每秒 100 複雜度點數）。當您需要強型別且不需要完整 Story 負載時，它非常有用，因為您可以僅請求所需的欄位。

{
  PageItem(id: "home") {
    name
    slug
    content {
      _uid
      component
      headline
      subheadline
    }
  }
}

Management API

Management API 處理 Storyblok 空間上的 CRUD 操作：建立 Stories、更新元件結構描述、管理資產以及執行遷移。您將在 CI/CD 管道、批量內容更新或圍繞 Storyblok 建構自訂工具時使用此 API。

您應該使用哪種 API？

對於大多數 Next.js、Nuxt 或 Astro 專案，搭配 storyblok-js-client 或官方 SDK 使用的 REST Content Delivery API 即可滿足所有需求。如果您的內容模型複雜，且正在抓取包含許多不必要欄位的深層巢狀結構，則可考慮使用 GraphQL。

2026 年 Storyblok 定價

Storyblok 定價從免費的 Starter 方案開始。付費方案從 Growth 方案的每月 99 美元（5 名使用者）起算。更高階層包括 Growth Plus、Premium（中型市場）和 Elite（無限）。新定價 已於 2026 年 4 月 7 日生效，現有月度訂閱者享有 60 天的寬限期。

以下是 當前定價層級 的細分：

Storyblok 還提供 Growth Plus 的 45 天免費試用，與 Contentful 的 30 天試用或 Sanity 的使用量基礎免費層級相比，這顯得異常慷慨。

關於定價的誠實看法：Storyblok 在規模擴大時可能會變得昂貴。來自代理商的 Reddit 討論串一致提到，隨著專案成長，定價會 escalating，涉及更多使用者、更多 API 呼叫以及多網站設定的更多空間。如果您預算有限，Strapi 的免費自託管選項 或 Payload 的開源模式能在自行管理基礎設施的成本下，提供更大的靈活性。

對於側邊專案和原型設計，免費的 Starter 方案即可運作。對於擁有 2-5 名內容編輯者的生產環境專案，每月 99 美元的 Growth 方案具競爭力。除此之外，請向 Storyblok 的銷售團隊索取自訂報價，因為公開定價僅反映了部分情況。

2026 年新功能：FlowMotion、Blueprints 和 AI

2026 年，Storyblok 推出了 FlowMotion（3 月 31 日），這是一個基於 n8n 建構的工作流程自動化層，擁有 500 多個整合項目。Blueprints 於 2025 年 7 月推出，提供具有框架特定起始模板的引導式專案設定。AI 功能包括 AI Translate（支援 34 種以上語言）、用於內容腦力激盪的 Ideation Room 以及 AI SEO 工具。

目前其他 Storyblok 指南尚未涵蓋這些功能。以下是實際已發布的內容。

FlowMotion：工作流程自動化

FlowMotion 是 Storyblok 對內容營運瓶頸的回應。根據其 發布公告，75% 的行銷人員每週花費 6 小時以上在內容協調任務上，例如通知利害關係人、觸發翻譯和排程社群媒體貼文。

FlowMotion 建立在受管 n8n（開源工作流程自動化工具）之上，並連接至 500 多個整合項目。您可以在內容事件（建立、更新、核准、翻譯、排程、發布）上設定觸發條件，FlowMotion 會自動執行工作流程。想像一下：編輯者發布一篇部落格文章，FlowMotion 自動觸發 AI 翻譯成 10 種語言，透過 Slack 通知社群媒體團隊，並排程 Twitter/X 貼文。

這是 Enterprise/Elite 附加元件，因此小型團隊無法使用。但對於跨多個市場和頻道管理內容的組織來說，這能顯著節省時間。

Blueprints：引導式專案設定

Blueprints 解決了一個真正的痛點：Storyblok 專案的初始設定。2024 年的一項調查發現，24% 的高級開發者表示初始 CMS 專案設定需要數天而非數小時。

Storyblok 提供兩層 Blueprints：

• Core Blueprint： 最小化設定，連接您的框架（Next.js、Nuxt 或 Astro），建立空間，並部署基本起始模板。適合想要乾淨起點的開發者。
• Business Blueprint： 生產環境就緒設定，包含預建元件、已設定的內容模型，並部署至 Vercel 或 Netlify。更接近「30 分鐘內啟動」的體驗。

您選擇框架，選擇 Core 或 Business，Storyblok 就會建立一個連接的 GitHub 儲存庫並包含部署管道。與從頭開始相比，這確實節省了數小時的樣板設定時間。

AI 功能：Translate、Ideation Room 等

Storyblok 的 AI 功能 採用自帶供應商（bring-your-own-provider）的方法。您連接自己的 OpenAI 或 Google Gemini API 金鑰，Storyblok 便會使用它進行：

• AI Translate： 直接在編輯器中將內容翻譯成 34 種以上語言。對於關鍵內容並非專業翻譯的替代品，但對於草稿和內部內容非常出色。
• Ideation Room： 用於內容構想的協作式 AI 腦力激盪。編輯者描述他們的需求，AI 則生成大綱、標題和草稿。
• AI Alt Text： 自動為圖片生成替代文字。
• AI SEO： 根據您的內容建議 Meta 標題和描述。

自帶金鑰模式意味著您可以控制成本，並避免在 AI 定價上被供应商鎖定。Storyblok 還在開發一項名為「Concept Room」的功能，旨在將構想與視覺內容規劃相結合。

使用 Storyblok 進行國際化

Storyblok 透過欄位層級翻譯處理 i18n，這意味著您擁有一個 Story，其中包含每種語言的翻譯欄位，而不是為每種語言複製整個文件。這與使用文件層級翻譯的 Contentful 和 Sanity 根本不同，且在規模擴大時影響重大。

為什麼欄位層級翻譯更勝一籌？考慮一個擁有 10 種語言的行銷網站。使用文件層級 i18n（Contentful、Sanity），每個頁面您將擁有 10 個單獨的文件。更改版面配置？需更新 10 個文件。使用 Storyblok 的欄位層級方法，您只有一個 Story。結構保持不變，只有文字欄位擁有語言變體。更改一次版面配置，所有 10 種語言都會更新。

AI Translate 讓這一切更加快速。編輯者以其主要語言編寫內容，點擊「Translate」，AI 便會使用他們連接的 OpenAI 或 Gemini 供應商填寫其他語言。它支援 34 種以上語言。

以下是抓取翻譯內容的方式：

// Fetching a story in German
const response = await fetch(
  `https://api.storyblok.com/v2/cdn/stories/home` +
  `?version=published` +
  `&language=de` +
  `&token=${process.env.STORYBLOK_TOKEN}`
);
const { story } = await response.json();
// story.content now contains German translations
// Untranslated fields fall back to the default language

language 參數完成了所有工作。未翻譯的欄位會自動回退至預設語言，因此您永遠不會因翻譯不完整而得到損壞的頁面。

Storyblok 與替代方案比較

在為我們自己的專案測試所有這五種 CMS 後，以下是它們在實際影響專案決策的功能上的比較：

如果您的專案涉及開發者和需要視覺化查看變更的非技術內容編輯者，請選擇 Storyblok。其視覺化編輯器無與倫比，且欄位層級 i18n 是多語言網站中的最佳選擇。

如果您的團隊以開發者為主，且您希望獲得最大的結構描述靈活性，請選擇 Sanity。Sanity 的程式碼即結構描述方法和 GROQ 查詢語言賦予您更多控制權，但編輯者獲得的是表單式 UI，而非視覺化預覽。閱讀 我們的 Sanity 指南 以了解全貌。

如果需要自託管或開源控制權，請選擇 Strapi 或 Payload。Storyblok、Sanity 和 Contentful 都不允許您在自己的伺服器上運行 CMS。Strapi 和 Payload 可以。查看 我們的 Strapi 指南 或 我們的 Payload 指南 以獲取詳細資訊。

如果您處於重視生態系成熟度、廣泛市場整合和既定開發者工具的企业環境中，請選擇 Contentful。閱讀 我們的 Contentful 指南。

如需包含評分和實際專案建議的完整比較，請參閱我們的 完整無頭 CMS 比較。

何時不應使用 Storyblok

每個 CMS 對於某些專案都有致命傷。以下是 Storyblok 的缺點：

您需要自託管。 Storyblok 僅限 SaaS，沒有本地部署選項、沒有 Docker 映像、沒有自管理部署。如果您的組織要求資料主權或本地託管，請考慮 Payload 用於自託管專案 或改用 Strapi。

您希望結構描述即程式碼。 Storyblok 元件結構描述是在儀表板 UI 中定義的，而非在您的程式碼庫中。您可以透過 Management API 匯出和匯入它們，但它們不會作為事實來源存在於您的 Git 儲存庫中。如果版本控制的結構描述對您的團隊很重要，Sanity 和 Payload 都提供程式碼優先的內容建模。

您在規模擴大時預算有限。 Storyblok 的定價對於中小型團隊來說效果良好。但如果您在多個品牌下運行 15 個以上的空間並擁有數十名編輯者，成本會迅速累積。自託管的 Strapi 或 Payload 完全消除了 CMS 授權成本。

您的團隊全是開發者。 視覺化編輯器是 Storyblok 的高级功能。如果團隊中沒有人需要視覺化預覽，如果每個人都習慣編輯 JSON 或使用表單式 UI，您就是在為您不會使用的功能付費。

您需要直接資料庫存取權限。 Storyblok 完全抽象化了其儲存層。沒有 Postgres 連接、沒有 SQL 查詢、沒有直接資料存取。如果您的專案需要在資料庫層級進行自訂資料庫查詢或與其他資料來源聯結，Payload（基於 MongoDB/Postgres 建構）能提供這些功能。

根據我們在多個 CMS 上建構的經驗，當開發者和內容編輯者在同一個專案上協作時，Storyblok 表現出色。如果您的團隊全是開發者，視覺化編輯器的高级費用就不值得支付。

開始使用 Storyblok

使用 Blueprints 從零到建立一個可行的 Storyblok 專案最快只需約 30 分鐘，不使用則需一小時。以下是步驟序列：

步驟 1：註冊。 在 storyblok.com 建立免費帳戶。Starter 方案提供一個空間，每月 25K 次 API 呼叫，足以用於開發和原型設計。

步驟 2：選擇 Blueprint 或從空白開始。 如果您想要預設定的專案，請選擇 Blueprint（Core 用於最小化，Business 用於生產環境就緒）。如果您偏好從頭建構，請建立一個空空間。

步驟 3：連接您的前端。 Storyblok 為 Next.js、Nuxt、Astro、SvelteKit、Remix、Angular 和 Gatsby 提供 官方 SDK 和起始模板。對於 Next.js App Router 專案：

npx create-next-app@latest my-storyblok-site
cd my-storyblok-site
npm install @storyblok/react

步驟 4：設定視覺化編輯器預覽 URL。 在您的 Storyblok 空間設定中，將預覽 URL 設定為您的本地開發伺服器（例如 https://localhost:3000/）。視覺化編輯器需要 HTTPS，使用 next dev --experimental-https 或 mkcert 等工具。

步驟 5：定義您的第一個 Blok 並建立 Story。 前往 Storyblok 儀表板中的「Components」，建立一個帶有 body 欄位的「Page」內容類型，然後建立一個可巢狀化的「Hero」Blok。使用「Page」內容類型建立您的第一個 Story。拖入 Hero Blok。在視覺化編輯器中查看其渲染結果。

針對特定框架的快速入門指南，Storyblok 維護了一個 技術頁面，其中包含每個支援框架的設定教學。如果您正在為前端決定框架，我們的 Next.js vs Remix 比較 涵蓋了權衡取捨，而我們的 Vercel vs Netlify 指南 有助於部署平台決策。

常見問題

什麼是 Storyblok CMS？

Storyblok 是一款內建視覺化編輯器的無頭內容管理系統，於 2017 年在奧地利林茨創立。它使用名為 Bloks 的元件式架構進行內容建模，並透過 REST 和 GraphQL API 交付內容。Adidas、Tesla 和 Oatly 等公司使用 Storyblok 進行網站、應用程式和多頻道內容交付。

Storyblok 可以免費使用嗎？

是的，Storyblok 提供免費的 Starter 方案，包含一名使用者、一個空間和每月 25,000 次 API 呼叫。付費方案從 Growth 層級的每月 99 美元（五名使用者）起算。Storyblok 還提供 Growth Plus 的 45 天免費試用，這比大多數競爭對手的試用期更為慷慨。

Storyblok 視覺化編輯器如何運作？

Storyblok 視覺化編輯器在 iframe 內載入您的前端應用程式，並在每個元件（Blok）上覆蓋可編輯區域。內容編輯者直接點擊頁面元素進行編輯，並即時查看變更。它需要在您的前端程式碼中使用 StoryblokBridge JavaScript 函式庫，以將 iframe 連接至 Storyblok 編輯介面。

Storyblok 比 Contentful 更好嗎？

這取決於您的優先事項。Storyblok 提供卓越的視覺化編輯器和欄位層級國際化，使其更適合管理多語言內容的行銷團隊。Contentful 擁有更成熟的生態系、更大的整合市場以及更深的企業採用率。兩者均僅限 SaaS，且定價結構相似。

Storyblok 支援哪些框架？

Storyblok 為 Next.js、Nuxt、Astro、SvelteKit、Remix、Angular 和 Gatsby 提供官方 SDK 和起始模板。React SDK (@storyblok/react) 和 Vue SDK (@storyblok/vue) 涵蓋了兩個最受歡迎的生態系。Blueprints 目前支援 Next.js、Nuxt 和 Astro 進行引導式專案設定。

您可以自託管 Storyblok 嗎？

不行。Storyblok 是一個僅限 SaaS 的平台，沒有自託管或本地部署選項。如果由於資料主權、合規性或成本原因，自託管是您專案的必要條件，請考慮 Strapi（開源、基於 Node.js）或 Payload CMS（開源、Next.js 原生）作為支援完整自託管部署的替代方案。

Storyblok 中的 FlowMotion 是什麼？

FlowMotion 是 Storyblok 於 2026 年 3 月 31 日推出的工作流程自動化功能。它建立在受管 n8n 之上，連接至 500 多個整合項目，並自動化內容操作，如翻譯觸發、利害關係人通知和跨平台發布。FlowMotion 作為 Enterprise/Elite 附加元件提供，不包含在 Growth 或 Growth Plus 方案中。

Storyblok 如何處理國際化？

Storyblok 使用欄位層級翻譯，這意味著一個 Story 包含每個欄位的翻譯變體，而不是為每種語言複製整個文件。對於擁有許多語言的網站，這種方法比文件層級 i18n（Contentful 和 Sanity 使用）更具擴展性。AI Translate 使用您自己的 OpenAI 或 Gemini API 金鑰支援 34 種以上語言。

誰在使用 Storyblok？

Storyblok 的客戶名單包括 Adidas、Tesla、Oatly、Virgin Media O2、dm-drogerie markt、Spendesk 和 Panini。該平台服務於管理多市場內容營運的企業組織，以及需要視覺化編輯器來賦能非技術內容團隊的新創公司。Storyblok 透過 C 輪融資累計籌集了 1.38 億美元資金。

什麼是 Storyblok Blueprints？

Blueprints 是 Storyblok 於 2025 年 7 月推出的引導式專案設定模板。選擇 Core Blueprint（最小化起始模板）或 Business Blueprint（生產環境就緒，含預建元件）。選擇您的框架（Next.js、Nuxt 或 Astro），Storyblok 會在幾分鐘內建立一個連接的 GitHub 儲存庫，並包含部署至 Vercel 或 Netlify 的管道。