OpenAI 的 UX‑guidelines：何時顯示 App，以及如何避免「搶走」對話

1. Chat‑first: ChatGPT — 首先是聊天，其次才是應用

在前 6 個模組裡，我們已經把應用程式的方方面面都走過一遍：從 UI 與 MCP 到除錯與部署。現在我們再從各個角度深入一層。你不會以為事情就這麼簡單吧？

先從 UX 開始，更精確地說，是官方的 UI requirements 與 UX guidelines。你也希望你的應用能通過 review（審核），對吧？太好了，那就從最有趣的地方開始：對習慣於 SPA/Next.js 的前端來說，需要在腦中完成的關鍵轉念： ChatGPT 的本質是對話介面，而 App 是這段對話中的訪客。不是反過來。

OpenAI 在其指南中的表述是：應用程式擴展了使用者能做的事情，不破壞對話的流。小工具不是新的瀏覽器分頁，而是嵌入聊天的一段輕巧內容，當純文字已經吃力時，它提供結構。

最容易記住的方法是分清角色。

GPT 與 App 的角色

在 ChatGPT 裡，有兩個「角色」：

GPT 仍是主要的講述者。他會用文字解釋接下來要做什麼、為什麼要推薦 App、按鈕代表什麼，並對小工具的結果做結尾總結。App 則專注於視覺與操作：選擇選項、設定篩選器、走完精靈的步驟。

有一條非常重要、需要像咒語一樣反覆記住的規則： 所有重要決策都必須在 GPT 的文字回覆中明確說出，即使使用者是在點 UI。使用者沒有義務讀完小工具介面的每一行說明——關鍵後果（例如「我們已完成下單」或「你選擇了以下參數」）必須在聊天中被清楚說出。

2. 何時 App 真的需要出現：顯示準則

從技術角度看，你可以在每一則訊息都呼叫小工具。但從 UX 角度，這就像在每次輸入一個字元時都打開全螢幕對話框——能運作，沒錯。要長期使用——不舒服。

OpenAI 與 Apps SDK 建議一個簡單原則：App 合宜於讓思考變得比只用文字更容易的時候。

具結構、可重複的請求

App 特別合適於使用者的請求本身就暗示結構時：

• 「幫我為同事挑 5 個 50 美元以內的禮物。」
• 「把這三個資費方案拿來比較。」
• 「規劃一個 3 天的東京行程。」
• 「顯示我這週的待辦清單，並幫我排優先順序。」

在這些情況下，有明確的實體（禮物、資費、行程天數、任務）需要操作，還有一連串步驟：選擇、篩選、比較、確認。此時帶有卡片、勾選框、篩選器的 UI 合情合理，甚至能救場。

GiftGenius 的例子

以我們最愛的主角 GiftGenius 為例。這是一個典型請求：

需要為婚禮的 10 位賓客挑選禮物，且每個人的預算與興趣都不同。

若只用純文字，GPT 可以列出 10 份獨立清單，但讀起來會很痛苦。更舒服的做法是：

• 顯示賓客、預算與興趣的表格，
• 提供「更便宜/更貴」的篩選，
• 為每位賓客輸出一組卡片。

在這裡，App 幾乎是必需的：實體與參數太多，已不適合只靠文字承載。

相對地，看看這個：

給哥哥 5000 ₽ 要買什麼？

這是單一步驟、範圍不大的問題。GPT 可以用 3–5 個點子直接文字回答；只有當使用者進一步要求「顯示可依興趣與年齡篩選的選項」時，才平滑地切換到 App。

小小的經驗法則

可以記住下面這張簡表：

關於 inline 與 fullscreen 我們會在之後的課再聊，但現在已經可以看出：App 是用於結構化、多步驟任務的工具，而不是每個「我有點難過，該怎麼辦？」都要用。

3. 什麼時候 App 反而造成干擾：聊天模式與思辨

我們已經看過哪些情況下 App 能讓生活更簡單、幫助對話結構化。但另一面是：也有許多情境，任何 UI 只會礙事。

關於「來畫 UI 吧」的討論很多，常常導致一種反射動作：「喔，使用者問了點什麼——該啟動小工具了。」這就是你在 Store 審核時會被扣 UX 分數的時刻。

有一整類請求，App 多半有害：

1. 使用者處於「只想聊聊」的模式。 這包括哲學式的思辨、個人問題、職涯兩難、較具治療性的對話。在這些情境中，使用者期待的是文字對談、澄清問題，有時還要同理心。插入卡片與篩選器會讓人感覺像垃圾廣告橫幅。
2. 關於服務的入門問題。 如果有人寫「告訴我 GiftGenius 能做什麼？」——他要的是概覽，而不是立刻出現 UI。此時 GPT 更適合先簡短說明 App 的用途，可能舉幾個請求範例，然後才輕輕地提議試用小工具。
3. 一般性的理論問題。 「如何為內向者挑禮物？」或「商店的忠誠度系統如何運作？」——這是教學型、不是交易型情境。GPT 可以給出良好的文字回答，最後不著痕跡地補上一句：「如果你想，我可以打開 GiftGenius，幫你挑幾個具體選項。」

凡是 UI 不能帶來新價值、只是重複文字的地方，最好維持在聊天中。這正是 UX 大師口中的「尊重使用者意圖」。

4. 如何提議 App：auto‑launch 與「謙遜移交」

即使你確信 App 合宜，「如何啟動它」仍是一個問題。粗暴的做法：小工具不經預告就全螢幕開啟。正常的做法：GPT 先用文字說明要發生什麼，並徵詢同意或至少先行告知。

在 ChatGPT Apps 的 UX 文件中，突出兩個樣式：auto‑launch 與 suggestion (humble handoff)。

Auto‑launch：當使用者明確要求時

當使用者明確表達意圖時，auto‑launch 才合宜：

啟動 GiftGenius。
打開 GiftGenius 的設定。
在 GiftGenius 中顯示我的禮物購物車。

這裡的規則很簡單：

1. GPT 簡短寫一句類似「正在開啟 GiftGenius…」。
2. 模型立刻呼叫工具 / 小工具。

對話可能會是這樣：

使用者: 啟動 GiftGenius，我想幫朋友挑禮物.
GPT: 正在開啟 GiftGenius 助手來挑選禮物.
[出現 GiftGenius 小工具（行內或全螢幕）]

自動啟動不需額外確認是合理的，因為使用者已明確要求「打開」。

Suggestion（humble handoff）：當意圖不明確時

在許多情況下，使用者根本不知道你的應用。他只寫：

要幫同事想個生日禮物，預算不大。

正確的樣式是：

1. GPT 先分析請求，判斷 App 能幫上忙。
2. GPT 提 1–2 個澄清問題，或直接以文字提議 App。
3. 只有在獲得同意或明確暗示後，才啟動小工具。

例子：

使用者: 要幫同事想個生日禮物，預算不大.
GPT: 我可以直接提供點子，或打開應用 GiftGenius，在那裡我們能依預算與興趣來挑。你想先聽建議，還是試試應用?
使用者: 用應用吧.
GPT: 正在開啟 GiftGenius，來幫你挑選禮物.
[小工具出現]

這種做法強調：主導仍在使用者手上，而 App 是選項，而不是強塞的橫幅。這也很好地呼應 UX 指南裡的「Respect user’s intent」原則。

TypeScript「意圖分類器」的小例子

假設在你的 backend 端，你已經對使用者的請求做了初步分類（不要與 GPT 本身混為一談，這只是輔助邏輯）：

// 使用者意圖的簡化型別
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// 我們想為 App 使用哪一種觸發
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "啟動 GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // 不明確的請求
  return 'avoid';                                // 一般聊天，不用 App
}

這段邏輯本身不會叫出小工具——更像是把你的 UX 方法形式化。接著把這些規則寫進 system‑prompt 與 App 的描述，讓模型遵循同樣的作風。

5. 如何不「搶走」對話：好與壞的樣式

OpenAI 在文件與為 ChatGPT Apps 撰寫的 UX 設計文章裡，都很清楚地指出不該做什麼：不要「偷走」對話。也就是，不要把聊天變成推廣你介面的管道。

反模式

最痛的——「驚嚇小工具」。當使用者正進行深入對話時，畫面突然被一個他沒有請求的全螢幕應用占滿。上下文不見了，掌控感也消失。

另一個常見的錯誤——把 App 當廣告用。例如，使用者問理論問題，模型卻回答：「先打開我們的超棒小工具，裡面都有寫」，並顯示 UI，其中一半是行銷文。官方指南直接把此類情境稱為「poor use cases」。

第三個反模式——頻繁且不必要地在 UI 與文字之間切換。如果每個小小澄清都要打開又關閉 App，對話就像在閃爍的燈串。使用者，尤其在行動裝置上，會很快疲乏。

良好做法

在所有你確實要打開 App 的場景，盡量遵循三條簡單規則。

第一，事先告知。讓 GPT 明講要開啟應用，以及為什麼。例如：「現在我會打開 GiftGenius 助手，改用卡片方式呈現選項」。只要 1–2 句，但能徹底改變過渡時的感受。

第二，說明在 UI 裡要做什麼。不是每位使用者都熟悉新介面。GPT 可以補充：「下方會看到禮物卡片，可以翻頁，並在任何選項點選“更多詳情”。」如果小工具裡有不尋常的元素（例如「顯示更多 N」或非典型的篩選器），最好用文字點出。

第三，用文字總結結果。當 App 做完一件事（挑選、計算、送出）後，GPT 應該簡短說明：「我挑了 3 個禮物選項。前兩個在 $50 以內，第三個稍貴，但運送更快。要不要再縮小條件？」這在行動與語音情境特別重要：使用者可能沒看 UI，但會聽到文字摘要。

6. system‑prompt 與 App 描述在 UX 管理中的角色

在此之前你已看到，system‑prompt 決定了 App 的「人格」以及模型如何使用工具。現在把UX 規則也加入：何時提議 App、如何宣告將要開啟、何時避免使用。

在 system‑prompt 要寫些什麼

對 GiftGenius 而言，system‑prompt 可以包含「對話與 UX」一節。文件與文章建議結構化、以獨立規則列出。

片段示例（偽碼，但相當接近實務）：

### 對話與 UX

1. 若使用者給出了挑選禮物的條件（送給誰、預算、場合），
   先用文字提出 1–2 個澄清問題。
2. 澄清後，提議開啟 App GiftGenius：
   "我可以打開 GiftGenius 助手來展示禮物選項。要打開嗎?"
3. 若使用者明確要求 "啟動 GiftGenius" 或 "顯示禮物清單"，
   回覆 "正在開啟 GiftGenius..." 並立刻呼叫 App，無需額外提問。
4. 若使用者要理論或一般建議（例如 "如何挑禮物"），
   以文字作答，並在他主動要求前不要開啟 App。
5. 若使用者說 "不要打開應用" 或 "只要文字回答"，
   之後在此對話中不要再主動提議 App。
6. App 完成操作後，永遠以文字做簡短總結。

這裡濃縮了我們的 UX 原則：chat‑first、尊重使用者的拒絕、區分 auto‑launch 與 suggest、以及必要的文字摘要。

如何用 TypeScript 設定幫自己一把

在真實專案裡，方便把部分規則以結構化方式保存（避免日後在人群中尋找提示字）。例如，可以準備一個簡單的設定：

// App UX 觸發規則的示意型別
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

這個設定本身模型讀不到——它是給你們這些開發者用，將產品/設計的共識集中在一處，然後再把它們準確移植到 system‑prompt、App 的描述與文件中。

7. 範例：GPT 如何宣告 GiftGenius 而不搶走談話

把一切串起來。假設使用者第一次在聊天中寫道：

我想替同事找禮物，預算大約 3000 ₽，他喜歡桌遊。

考慮到我們的 system‑prompt，一個不錯的回覆可以長這樣：

了解！我們先釐清幾個細節，再來挑點子。

請告訴我他大概幾歲？這比較偏正式的禮物，還是來自要好的朋友？

（在你回覆之後，我可以打開 GiftGenius 助手，用卡片的方式一起看選項。）

澄清之後 GPT 會寫：

太好了，資訊已足夠。

現在我會打開應用 GiftGenius —— 在裡面我會呈現幾個卡片式的禮物選項，你可以查看細節，並依預算與遊戲類型縮小範圍。

然後才啟動 App。沒有任何「驚嚇」，一切都先用文字說清楚。

一個簡單的 React「App 宣告」元件放在小工具裡

就程式碼而言，小工具通常在被呼叫時就直接 render。但即使它已經開啟，你仍可以在 UI 中貫徹「不搶走」對話脈絡的理念。

例如，GiftGenius 的第一個畫面可以非常簡單：

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        用 GiftGenius 挑選禮物
      </h2>
      <p style={{ marginBottom: 12 }}>
        我會以卡片方式展示幾個選項。你可以
        選擇喜歡的，ChatGPT 會解釋優缺點。
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        隨時都可以回到一般聊天，繼續討論。
      </p>
    </section>
  );
}

這個元件在技術上沒做什麼「強大」的事，但從 UX 觀點它很重要：提醒大家聊天仍在那裡，GPT 的角色依然是核心。

接下來就從這個導入畫面，進入禮物卡片、精靈流程等等——那就是下一堂課的主題了。

8. 實作與練習

上面我們整理了幾個原則——chat‑first、尊重使用者意圖、區分 auto‑launch 與提議 App。為了鞏固「何時以及如何顯示 App」的思維，最好把真實請求拿來演練，明確區分哪些需要 App，哪些不需要。作為課後練習可以做兩個小題。

先以 GiftGenius 為例，想出 5–7 個使用者請求。對每個請求誠實地回答：

• 是否應該馬上提議開啟 App；
• 是否只把 App 當作一種選項提及；
• 或是最好完全不要把回答與 App 連在一起。

例如：

1. 「送太太的周年禮物，預算到 $1000」——大多是先用文字詢問 1–2 個澄清問題，然後提議開啟 App。
2. 「如何有創意地包裝禮物？」——純理論問題，可以不需要 App。
3. 「啟動 GiftGenius，我想替整個團隊選禮物」——直接 auto‑launch。

第二個練習——啟動 App 的宣告文案。試著寫 1–2 句話，讓 GPT 向使用者解釋即將切換到 App。比較不同語氣：較正式（「正在開啟應用 GiftGenius…」）與較親切（「我們來試試 GiftGenius 助手——這樣比較容易比較選項」）。

如此你不僅能像開發者那樣思考，也能像對話作者那樣設計。

9. UX「何時顯示 App」的常見錯誤

錯誤 №1：只要出現相關字眼就顯示 App。
常見的極端：如果 App 與禮物相關，對話中任何「禮物」一詞都立刻觸發小工具。使用者問「怎樣才不會在送禮上失誤」，卻得到卡片式 UI 而不是真誠的建議。這會被視為廣告，忽視了使用者真正意圖，直接違背官方 UX 指南與「Respect user’s intent」原則。

錯誤 №2：未經預告就全螢幕。
「驚嚇小工具」突然占滿整個畫面，是毀掉體驗的可靠方法。尤其是在長對話的中段，使用者沒有預期會從文字一下跳到 UI。依 OpenAI 的指南，這類情境屬於不佳實踐；務必先宣告過渡，並在可能時徵詢同意。

錯誤 №3：用 UI 取代答案。
有時 App 的作者會想：「何必用文字回答，我們有漂亮的介面啊！」結果 GPT 幾乎不說話，所有「答案」都藏在小工具裡。使用者，尤其在語音或行動情境中，可能根本看不到關鍵細節。正確做法是：UI 是補充，不是替代——App 展示細節與選項，GPT 說明其意義。

錯誤 №4：忽視使用者拒絕 App。
如果對方明說「不要打開應用」或「只要文字」，App 就該把這視為本次對話的硬性規則。之後每隔兩則訊息又提議 App，就像不停跳出的「請評分」彈窗。這會讓 UX 變差，甚至影響 Store 的審核。在 system‑prompt 中務必明確寫下對拒絕的尊重。

錯誤 №5：不區分 auto‑launch 與「提議」。
當開發者不區分明確與不明確的意圖，要嘛在使用者明說時也不啟動 App，要嘛總是啟動，即便對方只是順口提到「也許哪天試試你的 App」。於是就有了因為「字眼像」而自動開啟小工具的情況。把觸發形式（auto / suggest / avoid）條文化，並在 system‑prompt 裡設計清楚的邏輯，能避免混亂。

錯誤 №6：system‑prompt 中完全沒有 UX 規則。
有時所有 UX 決策都只「在團隊腦中」，而 system‑prompt 只有「你是 GiftGenius 助手，幫忙挑禮物」。結果模型一會兒提議 App、一會兒忘記它、或在不適當時機打開。把結構化的 UX 規則記錄在 system‑prompt 與文件中，和工具的 JSON 架構一樣重要。

錯誤 №7：「之後再補 UX」。
常見流程是——先「讓它跑起來」，UX 之後再說。對 ChatGPT Apps 而言，這會導致你已依賴某些工具呼叫樣式，之後要改 system‑prompt 與 GPT 行為更難。不如一開始就埋好基本的 UX 指南：chat‑first、尊重拒絕、清楚的顯示準則、以及沒有「驚嚇小工具」。後續（行內樣式、全螢幕、語音）才能建立在健全的基礎上。