什麼是 ChatGPT App，以及它不是什麼

1. 前言

從一般開發者的視角看，這些東西其實都不算陌生：有個新的流行詞——ChatGPT App，有 API、有 SDK，還有幾個縮寫，看起來不過是「又一種呼叫 AI 模型的方式」。

問題在於，如果沒有清楚的全局圖，人們就會把非常不同的事物混為一談：舊的 ChatGPT 外掛、Assistants API、Custom GPTs 以及新的 ChatGPT Apps。結果是，有人以為可以像做 Custom GPT 那樣，晚上在 UI 裏「點一點」就搞定，最後卻不得不啟動 MCP 伺服器、寫 Next.js 小工具，還要考慮 Store。反過來，也有人寫了複雜的後端，其實對他的需求而言，一個簡單的 Custom GPT 或一般的 API 包裝就夠了。

因此，我們先來說清楚，新的 ChatGPT App到底是什麼（並把一切條理化），以及它不是什麼。

LLM 整合的「歷史」演進簡述

在下定義之前，看看方法論的演進很有幫助。這能讓你不只是背新名詞，而是理解 App 這個想法如何在 ChatGPT 內長出來。

最開始是典型的 「API wrapper」。你自己啟動一個網頁應用或機器人，在後端某處呼叫 OpenAI API：傳入 prompt，拿到文字回應，再顯示給使用者。所有邏輯、UI、授權與計費都在你這一邊。作為產品，ChatGPT 完全不參與其中。

之後出現了 ChatGPT Plugins。這是第一次嘗試把外部服務嵌入 ChatGPT 的介面中。外掛透過 OpenAPI 進行描述，ChatGPT 能呼叫它的端點，而你回傳 JSON，模型再把它轉述成文字給使用者。外掛沒有自己的 UI——頂多是模型在聊天中顯示的 Markdown。如今這套系統已被視為過時。

接著是 Custom GPTs（MyGPTs）。這是無需寫碼就能打造「你自己的 ChatGPT 變體」的工具：你可以設定 prompt、連接檔案，有時也能透過 Custom Actions 連到 HTTP API。一切都在 ChatGPT 介面內，但 UI 是標準化的，整合能力受限於 Actions 的範圍。

最後則是質的飛躍——最新的 ChatGPT Apps。這裡有豐富的 UI（嵌在聊天內的小工具）、與你的資料與後端邏輯通訊的標準協定（MCP），以及在生態系的專屬位置：Dev Mode、Store、權限、內建付款等等。

在撰寫本課時，Google Play 有 4 百萬款應用，Apple AppStore 有 2 百萬款，而在 ChatGPT 中只有 5 款。不是 5 百萬，而是只有 5(!) 款應用。要知道 ChatGPT 每週有 800 百萬活躍使用者。從來沒有如此容易擠進Top 100 應用並賺到幾百萬。

如果這勾起了你的興趣，我們就深入核心問題：這個新的 ChatGPT App 到底是什麼？

2. ChatGPT App 的簡明定義

網路上有一些市場行銷式的解釋，但既然我們都是工程人，我會把它翻成白話。

ChatGPT App 是一個在 ChatGPT 內啟動、並擁有自己 UI 小工具的網頁應用。應用會向 ChatGPT 提供一組工具（函式）與資料，並註冊到應用目錄（App Store）。它把對話介面（聊天）與圖形化 UI 及後端邏輯結合在一起，並透過像 MCP 這樣的標準化協定與 ChatGPT 平台溝通。

而這帶來的意義在於：

其一，「在 ChatGPT 介面內啟動」。使用者不必離開 https://chatgpt.com/ 或行動應用；你的應用 UI 會作為小工具嵌入該介面，直接顯示在聊天串中。

其二，「擁有自己的 UI 小工具」。這不只是模型在聊天中輸出的文字。你可以渲染 React 元件：卡片、清單、表單、地圖、播放器等前端好物。技術上，它就是一個在沙盒中執行、並透過 window.openai 與 Apps SDK 和 ChatGPT 溝通的 Next.js 應用。

其三，「向 ChatGPT 提供工具（函式）與資料」。你會在後端啟動一個 MCP 伺服器，並在那裡註冊你的 App 的 MCP 工具——也就是描述你的服務能執行的動作：例如目錄搜尋、預訂、資料分析、報表產生。ChatGPT 會把這些工具視為帶有 JSON Schema 的函式，並在需要時自行呼叫。

其四，「註冊到應用目錄」。App 會有名稱、圖示、描述、分類、權限、版本與商業化。它不是「隨手寫個小腳本」，而是 ChatGPT 生態中的一個完整 App。

一個非常重要的思維轉變：你不是在寫一個會自己把所有事做完的「機器人」。你是在描述介面與能力（UI + 工具），而 ChatGPT會自行決定何時使用這些能力、以及如何把它們織入對話。你對全場景的控制只有部分而已。

對你而言，這種方式帶來一個很大的優勢——ChatGPT會主動向使用者推薦安裝你的應用，並且自己判斷何時啟動它。也就是說，你的應用廣告成本是 $0。一百萬次安裝對你來說也是 $0。至少，當你是首批進場者時是如此。

在 2025 年上線你的 ChatGPT 應用，就像用 $1 買到比特幣。選擇權在你手上。

3. ChatGPT App 的構成：UI、工具與上下文

為了避免接下來混亂，我們把 App 拆成三個會在整個課程中反覆出現的大部件。

第一個部件——UI 層。通常用 React/Next.js 搭配 Apps SDK 撰寫的小工具。它在 ChatGPT 內渲染，展示禮物清單、預訂表單、圖表與各種視覺元素。它在沙盒中運作：不能破壞整體 DOM、不能隨意連網，並且只能在受限的視窗內運作。

第二個部件——工具、資源與提示。在協定層面，這是帶有能力描述的 MCP 伺服器：tools（動作）、resources（資料）與 prompts（範本）。工具以 JSON Schema 描述，模型把它們視為函式，並在合適時呼叫。在後續模組我們會詳談 callTool 是如何發生，但現在先記住：工具是你的 App 在真實世界中的手與眼。

第三個部件——使用上下文。也就是你為模型與使用者描述 App 的一切：系統提示、工具描述、權限、目標受眾、在 Store 中的分類。這些中繼資料會影響 GPT 何時推薦 App、認為哪些請求是相關的，以及允許哪些動作。

稍後當我們解構教學應用 GiftGenius 時，你會看到這三層如何協作：帶有禮物卡片與追問精靈的 UI 小工具、在 MCP/後端側的挑選與下單工具，以及上下文——系統指令、描述、權限與在 Store 中的分類。

4. 對比各種「ChatGPT 應用」

現在我們有了整體概念與 App 的「解剖圖」，退一步把它和「親戚們」比較一下。這能幫你徹底分清 Apps、外掛、Assistants API 以及單純的 OpenAI API。下面是一張有助於分離概念的表格。

一個在官方文件中被明確強調的好比喻是：Assistants API 是把「GPT 的大腦」嵌入你的產品；而 ChatGPT App 則相反——你把自己的產品帶進 ChatGPT 的介面。

5. ChatGPT App 不是什麼

現在我們來釐清幾個常見誤解。這很重要，免得之後把 App 畫成別的東西。

ChatGPT App ≠ 只是個 Next.js 網站

前端工程師的直覺是把 App 當作「又一個 SPA」，只是把 / 換成了「ChatGPT 裏的一個奇怪視窗」。這只對了一部分，但有個關鍵差異：你並不在自己的網域，也不掌控整個 UI，而是向 ChatGPT 租了一小塊介面。你不能改寫導覽、無限制地在最上層放自己的橫幅，也不能「駭入」執行環境。

在本課程中，我們會把小工具視為隔離的元件，而非完整網站：它在網路、DOM 與資源方面有嚴格限制，所有重活都交給後端/MCP。關於沙盒的細節我們會在本級最後一講專談，這裡只要記住，它不是「另一個 Next.js 主機」。

更直觀一點——看段程式碼。下面是你在 Next.js 應用中，針對 OpenAI 的傳統「API 包裝」——這不是 ChatGPT App：

// app/api/chat/route.ts — 你自己網站的一般後端，不是 App
import OpenAI from "openai";
import { NextRequest, NextResponse } from "next/server";

const client = new OpenAI();

export async function POST(req: NextRequest) {
  const { message } = await req.json();
  const response = await client.responses.create({
    model: "gpt-5.2",
    input: [{ role: "user", content: [{ type: "text", text: message }] }],
  });
  return NextResponse.json({ reply: response.output[0].content[0].text });
}

這個應用的使用者是在和你的後端互動，而不是和 ChatGPT 互動。所有 UI 與工作階段邏輯都由你掌控。這是把 AI 功能加進自家產品的絕佳方案，但它不是 ChatGPT App。

ChatGPT App ≠ 舊式 ChatGPT Plugin

「外掛」這個詞該被送進 2023 年的博物館，僅用來指稱舊系統。外掛讓 ChatGPT 能依據 OpenAPI 規格呼叫你的 HTTP 端點，但無法構建豐富的 UI：你最多只能回傳 Markdown，由模型在聊天中顯示。

新的 Apps 與外掛不同，它能渲染 React 小工具、透過 MCP 運作、具備權限並能參與金流情境。因此把它們當作「外掛 2.0」是個會很快帶來設計麻煩的過度簡化——一旦你開始規劃 UI 與工具就會感受到。

ChatGPT App ≠ Assistants API

Assistants API 解的是另一道題：如何讓你的產品（網站、行動應用、內部工具）擁有基於 GPT 的智慧助理。一切都「住在你那裡」，你控制 UI，而 GPT 是你透過 API 溝通的後端服務。

在 ChatGPT App 的情境中，一切正好相反。UI 與主要的使用者體驗屬於 ChatGPT，你是把自己的應用「搬進」那裡。使用者看不到你的網域，他只會在 ChatGPT 內看到 App 的名稱與圖示，而 token 通常也是透過他的 ChatGPT 訂閱來支付。

簡言之：Assistants API 是把 GPT 放進你的產品，ChatGPT App 是把你的產品放進 ChatGPT。

ChatGPT App ≠ 只是 Custom GPT

Custom GPTs 是快速起步的好工具：組個 prompt、接幾個檔案——很快就有「個人助理」。但它的 UI 是標準聊天、沒有小工具，而透過 Custom Actions 的整合也相當有限；它沒有完整的 Apps SDK 與 MCP 層。

ChatGPT App 則是專業開發（pro‑code）的故事。你要寫小工具（通常用 Next.js）、啟動 MCP 伺服器、設定驗證、權限與付款。彈性更高，責任也更大：包括安全性、UX，以及在註冊應用時通過審核。

我對商業團隊的實用建議是：用 Custom GPT 作為快速的行銷入口（在 GPT Store 裏的簡易助理），同時針對嚴肅場景與未來變現，平行開發基於 Apps SDK 的完整 App。

ChatGPT App ≠ 「只是另一個機器人」

最後是一個心理層面的重點。ChatGPT App 不是「又一個聊天機器人」。它是一個有生命週期的產品：有 Dev Mode、審核、版本、限制、分析與支付情境。把它當「拿來 demo 的小機器人」是低估投入、導致上線失敗、錯失賺錢機會的穩當方式。

6. ChatGPT 應用的類型

為了更清楚你在做什麼，擁有一個粗略的 ChatGPT Apps 類型學很有幫助。在本課程中我們會談四個主要重點，並用簡短英文標籤：UI-heavy、tool-first、commerce-oriented 與 data/analytics。

• 第一類——UI‑heavy 或 UI‑first 應用。核心價值在視覺介面：精靈、設定器、複雜表單、畫布。例子：帶十多個參數的保險選配、設計配置器、資料視覺化。
• 第二類——Tool‑first 應用。重點不在 UI，而是工具。App 提供模型強大的函式組，使用者體驗多半由 ChatGPT 自行編排，用文字解說並偶爾顯示最小化 UI。例子：給 GPT 存取公司內部知識庫的 App——模型自行決定何時如何搜尋，並如何向使用者解釋結果。
• 第三類——Commerce‑oriented 應用。重心在銷售、訂閱、預訂。App 與 Agentic Commerce Protocol（ACP）整合，能建立購買、處理購物車與 Instant Checkout，並把訂單關聯到使用者。
• 第四類——Data/analytics 應用。專注於連接資料來源與資料分析：報表、BI 儀表板、日誌與指標分析、處理上傳檔案等。

同一個想法可以用不同風格實現。例如禮物推薦可以做成純 Tool‑first（模型自己生成解說，App 只回傳 JSON 的候選清單），也可以做成 UI‑heavy（帶篩選器、商品卡片與方案比較的豐富小工具）。

7. 我們的教學專案：GiftGenius

把課程內容綁定到一個貫穿始終的應用會很有幫助。因此，在學習過程中我們會動手寫自己的應用：GiftGenius——一個透過 ChatGPT 進行禮物挑選與下單的應用。我們會不斷回到它身上。

從類型學的角度來看，GiftGenius 首先是一個以商務為導向（commerce‑oriented）的 App，並帶有 UI‑heavy 的元素。使用者在 ChatGPT 中輸入類似：「想送一位 IT 朋友的禮物，預算 50–70 美元」，模型決定啟用 GiftGenius，App 顯示帶有追問的精靈與禮物推薦的小工具，最後透過 ACP 完成下單。

若你想用 TypeScript 的語言來思考，我們可以先草擬一個最簡的網域模型，後續會一路陪伴我們：

// gift-types.ts — GiftGenius 的簡化網域模型
export type GiftIdea = {
  id: string;
  title: string;
  priceUsd: number;
  tags: string[];      // 收禮者的興趣
  occasion: string;    // 場合：birthday、wedding 等等
};

目前這只是個型別，尚未綁定任何 SDK。但隨著課程推進，你會看到這類網域模型如何滲透進 MCP 工具、UI 小工具，甚至商務層。

8. 使用者如何在對話中看到 ChatGPT App

雖然「使用者流程」會是第三講的重點，但現在至少先勾勒一下整體圖景，好讓你理解 UI 的意義，以及 App 如何出現在對話中。

使用者與 ChatGPT 一如往常互動：輸入訊息、提問、尋求協助。ChatGPT 對每條訊息都會決策：自行回覆、呼叫某個工具、顯示或更新你的 App 小工具、或在相關時機建議使用該 App。

例如使用者寫道：「我要一個結婚週年紀念的禮物，預算不超過 100 美元，先生喜歡桌遊。」模型看到它有個會依此條件選禮物的 App——GiftGenius。它可能走兩條路：

1. 先向使用者提議使用 GiftGenius，例如：「我可以啟用 GiftGenius App 來挑幾個選項。要啟動嗎？」
2. 直接呼叫 App 的工具並顯示已填好欄位的小工具，呈現推薦清單。

這一切都不需要你在程式中寫 if user_said_gift then call_app() 這類指令式邏輯。你描述 App 的能力，模型學會使用它們。因此清楚的描述、合理的限制與精心設計的 UX 極其重要——否則 GPT 不是濫用你的 App，就是完全不碰它。

為了更直觀，可以把它想像成下面這張圖：

flowchart TD
  U[ChatGPT 的使用者] -->|訊息| G[GPT 模型]
  G -->|決策：要使用 App 嗎？| A[你的 ChatGPT App]
  A -->|小工具| W[聊天中的 UI]
  A -->|tools/MCP| B[你的後端 / MCP]
  B --> A --> G --> U

關於 GPT 具體如何決定何時呼叫 App，我們會在工具與系統提示（system prompt）主題中細談，但現在先記住：這是一種協作，而非你對它的指令式控制。

9. 迷你練習：你的 App 點子

為了讓內容不只停留在抽象理論，現在就想一個你自己的 App 點子，之後會與 GiftGenius 一起在腦中演進。

試著用一句話描述你的 App 在 ChatGPT 內要做什麼。例如：「App 幫開發者評估任務複雜度並拆解子任務」，或「App 會在考量天氣與預算下規劃旅行路線」。

接著誠實回答兩個問題。第一，它更接近我們類型學中的哪一類：UI‑heavy、tool‑first、commerce‑oriented 或 data/analytics。第二，它真的是 ChatGPT App，還是本質上只是你網站裡的一個機器人，或另一個 Custom GPT？如果你需要的只是在後端更方便地呼叫 OpenAI API，那可能根本不必做完整的 App。

這類小型自我審視，能幫你省下幾個月做錯產品的時間。

10. 對 ChatGPT App 的常見誤解

錯誤 №1：把所有東西都叫「外掛」。
外掛系統是 2023 年的歷史階段。新一代整合是基於 Apps SDK + MCP 的 Apps。若還緊抓「外掛」這個詞不放，很容易低估 UI、沙盒、Store 與整個產品週期的角色。在本課程中，「外掛」只指舊系統，而 App 一律指新一代應用。

錯誤 №2：期待能完全控制 GPT。
有時開發者會想：「我寫個 App，模型就會完全照我說的做。」但在 ChatGPT 生態中不是這樣：你描述能力與意圖，模型自行決定何時呼叫工具、何時顯示小工具、何時直接文字回覆。若把 App 設計成帶嚴格腳本的傳統 SPA，結果多半是失望。

錯誤 №3：把 ChatGPT App 與 Assistants API 混為一談。
很常見的情況是：某人其實想要「在自家產品中的機器人」，卻習慣性看向 Apps SDK，而更簡單、更合理的做法其實是用 Assistants API。結果他把精力投入到 ChatGPT 裏的小工具，但他的使用者根本不需要。分辨方式很簡單：如果使用者到你的網站或 App 來，用 Assistants API 想；如果你想走進 ChatGPT 找到使用者，用 ChatGPT App 想。

錯誤 №4：把 App 當成「另一個前端」，忽略沙盒。
當開發者把 Apps SDK 當作一般的 Next.js 前端來用，忽略沙盒限制（受限的網路、DOM、資源），很快就會撞牆：「為什麼不像在我網站上一樣運作？」要及早接受小工具是隔離元件的事實，所有重度整合與機密都應放到後端/MCP。

錯誤 №5：高估 Custom GPT、低估 Apps SDK（或反過來）。
Custom GPTs 與 Apps 不是「二選一」，而是不同成熟度層級。常見的正確策略是兩者並用：以 Custom GPT 作為快速入口與行銷；以基於 Apps SDK 的 App 作為具備豐富 UI 與商務能力的嚴肅產品。當開發者期待 Custom GPT 具備 Apps SDK 的能力，或把 Apps SDK 用在其實用 Custom GPT 即足夠的場景，只會讓自己更辛苦。