圍繞 UX 的指引：宣告啟動 App、選擇不啟動 App，以及對話中的行為

1. 為什麼要用指引來管理 UX

從 ChatGPT 的觀點，你的 App 不過是額外的工具與小工具（Widget）。但對使用者而言，這是一個會在對話中突然出現的獨立介面。若不管控模型的行為，可能會出現兩種極端情況。

其中一種情況是，GPT 會忽略 App，試圖「全都用文字解決」。使用者請你幫忙挑禮物，但模型沒有啟動 GiftGenius，而是給了一大段「自己想的」建議文字。有時這不壞，但你寫 App 並不是為了讓它在架上積灰。

另一種情況則相反：GPT 過度濫用 App。對任何像「你們的服務能做什麼？」這樣的打噴嚏級問題，它就直接啟動小工具、渲染一個不清不楚的表單，嚇得使用者趕緊把這些華麗的東西全關掉。從 UX 的角度來看，顯得非常打擾。

因此邏輯很簡單：像你為工具的 JSON 結構或 React 元件的 props 那樣，明確固定其行為。這裡的 system‑prompt（以及相關指引）就是你的「UX 協定」。在其中你會描述助理在何時、如何：

• 宣告將啟動 App；
• 有意識地不啟動 App，而改用文字回答；
• 在小工具已顯示結果之後如何行動；
• 如何尊重使用者「不要使用應用程式」的請求。

這不是在談行銷或對話風格；它會實際影響你的 App 被呼叫的頻率，以及使用者的舒適程度。

接下來我們會逐步說明：助理該如何宣告將啟動 App；在什麼情況下應刻意不主動提供小工具；在應用程式完成後該如何行為；如何尊重使用者對對話格式的明確要求；以及如何把這些規則妥善整理到 system‑prompt 中。

2. App 的宣告：模型該如何「預先告知」將出現的小工具

當 ChatGPT 決定使用 App 時，介面會變化：聊天中會出現小工具卡片，有時甚至是全螢幕視圖，出現按鈕與其他 UI 元素。如果助理不做任何解釋就直接顯示小工具，使用者可能完全不明白發生了什麼，這個區塊又是從哪冒出來的。

因此比較好的做法——先用文字說明接下來會發生什麼，再啟動 App。這就像瀏覽器會問：「要開新視窗嗎？」或行動 App 會先提醒：「我們接下來會向您索取相機權限」。

宣告的類型

大致可分三種宣告風格。

第一種——溫和的提議。助理會說：「我可以為您開啟 GiftGenius 應用程式，根據您的條件挑選禮物。要開啟嗎？」然後等待「要／不要」的回覆。這在使用者初次接觸服務，或對介面切換較為敏感的情境下很有效。

第二種——自信的建議。如果你的 App 是產品的主要介面，你可以寫：「我現在會啟動 GiftGenius，並以卡片顯示幾個禮物選項。」助理仍然會尊重拒絕，但預設行為會更果斷。

第三種——中性通知。這種情況下助理只會告知：「我正啟動 GiftGenius 來挑選禮物……」，不做太長的解釋。當使用者已多次看過你的 App 並預期它會出現時，這種風格很合適。

重點是，這些措辭都可以、也應該寫進 system‑prompt。只要你先給出骨架，模型就不會從零開始自己編 UX 文案。

迷你程式碼範例：system‑prompt 中的宣告段落

假設在你的 Next.js 範本中有檔案 appDefinition.ts，你在其中為 App 設定 system‑prompt：

// app/appDefinition.ts
export const systemPrompt = `
# 角色
你是 ChatGPT App GiftGenius，負責幫忙挑選禮物。

# 對話與 UX — 應用程式的宣告
當你決定啟動 GiftGenius 小工具時，
請先用一到兩句話說明
接下來會開啟一個提供禮物清單的應用程式，
以及它如何幫助使用者。
`;

這還稱不上完整的合約，但就算這樣的小小補充，也已大幅提升行為的可預測性。

什麼情況下特別需要宣告

你的 UI 越複雜，就越需要提前說明其啟動。如果小工具只是顯示三張禮物卡片——這算是相對柔和的情境切換。若你開啟的是一個包含篩選器、預算、分類等的多步驟精靈，使用者應該理解為什麼對話突然變成「聊天室裡的一個小型網頁應用程式」。

官方的 UX 指南也強調，助理應該明確把文字與 UI 連結起來，而不是默默把小工具塞到回覆中。

3. 什麼時候要刻意不主動提供 App

在 App 開發初期最常見的錯誤，就是經典的「手上拿著錘子，看什麼都像釘子」。既然我們有漂亮的 GiftGenius，模型就想把它帶進每段對話。使用者問：「你們的應用程式到底能做什麼？」結果 ChatGPT 馬上說：「正在啟動 GiftGenius……」，但對方其實只想要兩句說明。

為了避免這種情況，需要在 system‑prompt 中描述哪些情境下比較不適合提供 App。以下是幾個典型案例。

• 首先，認識性問題。如果對方寫的是「GiftGenius 是做什麼的？」或「你們怎麼運作？」，指引應要求先給出簡短的文字解釋，不要啟動 UI。此時小工具只會分散注意力。
• 其次，過於籠統或模糊的請求。例如使用者寫「介紹一下新年的禮物」。這更像是求知問題，而非具體的挑選。助理可以簡短說明一般原則、提出釐清問題，等有了明確參數（預算、收禮對象、分類）再建議使用 App。
• 再者，超出 App 領域的請求。如果對方說：「幫我寫履歷」，而你的 App 是為挑選禮物而設計，正確做法是像一般 ChatGPT 一樣誠實作答，什麼都不要啟動。偶爾可以順帶提一提 App 是做什麼的，但不需要在明顯無關時硬推它。
• 最後，明確拒絕 UI。如果使用者寫：「請不要開任何應用程式，只要文字說明就好」，即便遇到 App 的完美用例，模型也必須遵從。

表格：請求類型與助理行為

在 system‑prompt 補充不啟動 App 的規則

延續同一個 systemPrompt，加上不啟動 App 的條款：

export const systemPrompt = `
# 角色
你是 ChatGPT App GiftGenius，負責幫忙挑選禮物。

# 何時不要啟動小工具
若使用者僅詢問服務能做什麼，
或提出關於禮物的概論性問題，
先以文字回答，不要啟動應用程式。

若請求與挑選禮物無關，
像一般 ChatGPT 回覆，不要主動建議 GiftGenius。

若使用者明確要求不要使用應用程式，
務必尊重並僅在聊天中回覆。
`;

這樣的文字會在邊界情境中轉化為模型的具體決策，否則它可能會把「注意力」過度拉向 UI。我們已經界定了 App 何時不需要。接下來要描述另一面：當小工具已完成並且使用者看到結果時，助理該怎麼做。

4. 使用 App 之後的行為：follow‑up 與情境收尾

在小工具模組中你已看到，follow‑up 訊息可以幫助在 UI 運作完之後延續對話。小工具顯示了卡片，而在其下方助理可能寫：「我為同事在 $50 預算內找到了幾個禮物選項。要不要看更便宜的，或改變分類？」並提供幾個常見動作的按鈕。

我們現在的任務——是把這個行為寫進指引，而不是倚賴模型的「直覺」。

小工具之後助理應該做什麼

理想情境中會發生幾件事。

• 先由助理以文字簡短總結 App 的結果。即便小工具顯示了十張卡片，寫一句「我為同事在 $50 預算內挑到 4 個禮物選項，其中包括客製化印刷的馬克杯、桌上植物、優質咖啡禮盒，以及有質感的筆記本」也很有幫助。
• 接著提出下一步。這時預先設計好的 follow‑up 句式很有用：「要看更便宜的選項嗎？」「需要依興趣縮小範圍嗎？」「只顯示你所在地區可購得的嗎？」這些句子可以用在小工具中的 sendFollowUpMessage，也可以在 system‑prompt 中建議模型使用。
• 最後，若使用者明確結束該情境（「謝謝，夠了」），助理要體面地「關檔」：確認任務已完成，並主動提供其他協助。

流程圖：問題 → 小工具 → follow‑up

為了更直觀，可以把助理的行為想成一個簡單的狀態機。

flowchart TD
    U[使用者提出需求] --> G[GPT 決定：要啟動 App 嗎？]
    G -->|是| A[宣告將啟動 App]
    A --> W[GiftGenius 小工具產生候選選項]
    W --> S[助理以文字摘要結果]
    S --> F[助理提供 follow‑up 選項]
    F -->|使用者選擇下一步| G
    G -->|否，不啟動 App| T[僅以文字回覆，不含 UI]
    F -->|"使用者說「謝謝」"| E[助理收尾該情境並提供其他協助]

這樣的流程其實我們已在 system‑prompt 中用文字描述了。

程式碼範例：從小工具送出 follow‑up

在 UI 端，你已經會送出 follow‑up 訊息。完整性起見，下面是一個簡單的元件範例：在按鈕點擊後請模型「擴大預算」：

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "顯示預算稍高的選項"
        );
    };

    return <button onClick={onClick}>想看更高價的選項</button>;
}

接著我們會在 system‑prompt 中加入文字，指引模型如何處理這類 follow‑up 訊息。

// systemPrompt 的延續
const followUps = `
# 啟動應用程式後的行為
當小工具已顯示禮物清單後，
請以簡短文字描述結果。

接著提供 1–3 個明確的下一步
(例如：顯示更便宜的、調整預算、切換分類)。
如果小工具傳送了 follow‑up 訊息，
將其視為下一步的指引。
`;

技術上看這只是一段字串，但對 UX 而言——就是可預測情境的基礎。

5. 尊重使用者意圖

以上所談都是你對 App 行為的產品預期。若模型不會「傾聽」使用者，UX 指引就很難發揮作用。即便是設計得很好的 App，當使用者明確要求不要更動互動形式時，也應該讓步。

幾種典型情境如下。

• 如果使用者直接表示不想啟動任何應用程式（「不要 UI，只要告訴我該買什麼」），助理就該視之為嚴格限制，不要試圖繞過。可以禮貌表示：「好，我會只用文字回覆」，接著確實信守承諾。
• 若使用者擔心會自動啟動什麼，給他掌控感會很有幫助。例如：「我可以開啟一個挑選禮物的應用程式；如果你偏好，也可以只在聊天中討論。你比較希望哪一種？」你在此明確給予選擇。
• 如果使用者寫「我現在用手機，不要啟動複雜的表單」，這也是對話的上下文。助理應該接受，改以短清單的點子與釐清問題來協助。

把「尊重」寫進合約

這些都能精簡地反映在 system‑prompt 中：

export const respectBlock = `
# 以使用者意圖為優先
務必遵從使用者
對互動形式的明確要求。

若使用者要求不要啟動應用程式或小工具，
就不要提議或啟動 GiftGenius，
即便這麼做可能更有助於解決問題。
改以文字協助。
`;

如此可明確界定誰才是對話的主角。小劇透：不是你對漂亮 UI 的自豪，而是螢幕另一端的真人。

6. 如何在 system‑prompt 與文件中編寫 UX 指引

我們已經整理了不少行為規則——從宣告 App 到 follow‑up 訊息，以及尊重對話格式。此時不僅要重視我們在跟模型說「什麼」，也要關注「如何」在 system‑prompt 與文件中表述。

真實專案中的 system‑prompt 成長很快。如果把它寫成長篇小說，一週內就沒人找得到東西。請把它當成技術規格或 README：要有結構。

良好的做法——把 prompt 拆成幾個具標題的邏輯段落。例如：「角色與職責範圍」、「何時使用 App」、「何時不使用 App」、「對話與 UX」、「安全與限制」。每段內容使用簡潔、明確的句子。

更好的做法——把 system‑prompt 放在靠近程式碼的獨立檔案中，而不是夾在元件的字串常值裡。這樣更便於 code review、比較變更，並與產品或法務同事討論。

在程式碼中組織 system‑prompt 的範例

其中一種作法，是把 prompt 的各部分存成獨立字串，再組合起來：

// app/prompt/role.ts
export const roleSection = `
# 角色
你是 ChatGPT App GiftGenius。
協助使用者依任務與預算挑選禮物。
`;

// app/prompt/ux.ts
export const uxSection = `
# 對話與 UX
在啟動 GiftGenius 小工具之前，
先簡短說明將開啟含禮物卡片的應用程式。
對於一般性或理論性的問題不要啟動應用程式，
除非使用者明確要求進行推薦。
小工具完成後，以文字總結結果，
並提出 1–3 個下一步。
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

這樣的拆分能讓你把指引當作獨立模組來思考：UX、安全、工具使用等。當你新增功能、需要與多個團隊協調行為時，這會特別有用。

此外，App 的文件（內部 README、Confluence、Notion）也應與這些區塊同步。在那裡你可以用更白話的方式說明，為什麼要這樣宣告 App，以及為什麼不在試探性請求時啟動它。也請固定下 follow‑up 的句型。如此一來，新加入的同事就不會在不了解脈絡的情況下試圖去「修 prompt」。

7. 實作：重寫我們 GiftGenius 的 UX 指引

讓我們把一切組裝成一個較完整的 system‑prompt。假設我們原來的 system‑prompt 很陽春：

export const systemPrompt = `
你是 GiftGenius 應用程式。
請為使用者挑選禮物。
`;

這段文字沒有說明什麼時候啟動 App、如何宣告啟動，以及在小工具之後要做什麼。我們逐步加入 UX 指引。

先清楚界定職責與工作方式：

const role = `
# 角色
你是 ChatGPT App GiftGenius。
你的任務是依預算、收禮對象與場合，協助使用者挑選 3–7 個相關的禮物。
你可以使用 GiftGenius 小工具進行視覺化挑選。
`;

接著描述如何宣告啟動：

const announce = `
# 應用程式的宣告
若你認為 GiftGenius 小工具更能幫上忙，
請先用一到兩句話說明，
即將開啟含禮物卡片的應用程式，
以及使用者可以瀏覽並篩選。
之後再啟動應用程式。
`;

加入不啟動 App 的規則：

const noApp = `
# 何時不要使用應用程式
若使用者僅詢問服務能做什麼，
或想要關於禮物的概論資訊，
請以文字回答，不要啟動 GiftGenius。

若請求與禮物無關（例如：履歷或程式碼），
像一般 ChatGPT 回覆，不要建議應用程式。

若使用者要求不要使用應用程式，
視為強制性限制。
`;

最後補上使用小工具之後的行為：

const afterWidget = `
# 小工具之後的行為
當小工具顯示了禮物選項之後，
請用簡短文字描述結果。
向使用者提出 1–3 個下一步
(例如：調整預算、依興趣篩選、
只顯示更便宜的選項)。

若小工具送出了 follow‑up 訊息，
將其視為下一步的主要訊號。
`;

最終的 system‑prompt 可能長這樣：

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

這已經更像是行為規格，而不是「對宇宙的許願」。在接下來的模組中，你會再補上關於安全、幻覺、商務等的指引，但 UX 部分已經打下了基礎。

8. 設定 UX 指引時的常見錯誤

錯誤一：「App 永遠比文字好」。
有時開發者太為自己的小工具驕傲，要求模型逮到機會就呼叫它。結果使用者在只想問「這到底是什麼？」的情境下，也被丟了一個 App。模型變得很煩人，大家開始忽略它。正確作法是明確列出哪些情境不需要 App，並尊重這些案例。

錯誤二：啟動 App 前沒有明確宣告。
如果助理默默啟動小工具，使用者會不明白 UI 區塊從哪來、要怎麼用。OpenAI 的指南與實務經驗都顯示：一到兩句「我現在會開啟一個能做 X 的應用程式」能大幅改善 UX、減少困惑。

錯誤三：過度積極地重複推薦 App。
常見情況是 App 在每次回覆後又再提「要不要再開一次？」、「現在呢？」這很快就變成垃圾訊息。比較好的做法是在指引裡規定：第一次使用 App 之後，要看上下文；只有在使用者明確變更任務參數，或主動說「再給我看」，才再次建議。

錯誤四：忽視明確的「不要用應用程式」要求。
像「拜託只用文字」或「我用手機，不想操作複雜表單」這類句子，應被視為嚴格限制。若模型仍然執意推 App，使用者對助理與你的產品都會失去信任。其實只要在 system‑prompt 中加上兩三句就能固定這條規則，但很多人忘了這麼做。

錯誤五：小工具之後沒有摘要與 follow‑up 訊息。
有時小工具很盡責地顯示了選項，但助理之後卻沉默。使用者看到 UI，卻不知道接下來該怎麼做——沒有文字、沒有問題、也沒有常見動作的按鈕。這種情境顯得不完整，破壞對話的連貫性。請務必在指引中規定：小工具之後要有簡短文字結論，並附上 1–3 個明確的下一步。

錯誤六：把產品 UX 與「ChatGPT 的一般語氣」混在同一段。
有時 system‑prompt 會變成一篇散文：「要友善、偶爾用表情符號、適時開個玩笑；對了，也許有時候可以啟動 App。」在這種文字裡很難注意到真正的 UX 規則。較好的方式是把章節分開並用清楚的標題：「角色」、「對話與 UX」、「何時使用 App」、「何時不使用 App」。這對模型，以及未來要與這份 prompt 合作的人，都更友善。