AI 原生應用設計
前言
為什麼有些 AI 產品讓人驚豔，而有些只是「套殼 ChatGPT」？ 差別不在於用了多強的模型，而在於產品是否從底層就圍繞 AI 的特性來設計。AI 原生應用不是在傳統應用上「加個聊天框」，而是重新思考使用者互動、系統架構和產品邏輯的全新範式。
這篇文章會帶你學什麼？
學完這章後，你將獲得：
- 範式認知：理解 AI 原生應用與傳統應用的本質區別
- 設計原則：掌握 AI 原生產品的核心設計原則
- Prompt 工程：了解如何設計高品質的 Prompt 來驅動 AI 能力
- 互動模式：認識 AI 時代的新型使用者互動範式
- 架構思維：理解 AI 應用的請求處理流程和系統架構
| 章節 | 內容 | 核心概念 |
|---|---|---|
| 第 1 章 | 架構對比 | 傳統應用 vs AI 原生應用 |
| 第 2 章 | 設計原則 | AI-First 思維、不確定性設計 |
| 第 3 章 | Prompt 工程 | 系統提示詞、模板設計 |
| 第 4 章 | 互動模式 | 流式輸出、多模態、Agent |
| 第 5 章 | 請求流程 | AI 應用的完整生命週期 |
0. 全景圖：從「加個 AI」到「AI 原生」
過去幾年，很多產品的 AI 化路徑是這樣的：有一個現成的應用，然後在某個角落加一個「AI 助手」按鈕。這種做法就像在馬車上裝一個引擎——能跑，但遠不如從頭設計一輛汽車。
AI 原生應用是一種全新的產品思維：從第一行程式碼開始，就把 AI 作為核心能力來設計，而不是事後附加的功能。
傳統應用 vs AI 原生應用
- 傳統應用：使用者操作 → 確定性邏輯 → 確定性結果。每次點擊「提交訂單」，流程完全一樣。
- AI 原生應用：使用者意圖 → AI 理解 → 機率性結果。同樣的問題，每次回答可能略有不同。
- 核心轉變：從「編寫規則」到「描述意圖」，從「確定性」到「機率性」，從「操作介面」到「對話介面」。
1. 架構對比：兩種完全不同的世界
傳統應用的架構是「請求-回應」模型：使用者點擊按鈕，後端執行確定性邏輯，返回確定性結果。整個過程可預測、可測試、可重現。
AI 原生應用則引入了一個全新的角色——大語言模型。它像一個「智慧中間層」，接收自然語言輸入，輸出自然語言結果。這帶來了架構上的根本性變化。
Traditional Apps vs AI-Native Apps
Switch views to compare the core architectural differences
Traditional application architecture
Frontend UI
User interface and interaction
Business logic layer
Hardcoded rule engine
Data storage
Structured data management
API interface
Fixed request and response
🖥️ Frontend UI
Deterministic forms, buttons, and routes. User actions trigger fixed business flows defined during development.
Typical technologies
| 維度 | 傳統應用 | AI 原生應用 |
|---|---|---|
| 輸入方式 | 表單、按鈕、下拉選單 | 自然語言、圖片、語音 |
| 處理邏輯 | if-else、規則引擎 | LLM 推理、Prompt 驅動 |
| 輸出特性 | 確定性、可重現 | 機率性、每次可能不同 |
| 延遲特徵 | 毫秒級 | 秒級（需要流式輸出） |
| 錯誤處理 | 明確的錯誤碼 | 幻覺、拒絕回答、答非所問 |
| 成本模型 | 固定計算資源 | 按 token 計費，成本波動大 |
架構演進的三個階段
- AI 增強型：在現有應用中嵌入 AI 功能（如自動補全、智慧推薦）
- AI 協作型：AI 作為核心互動方式，但仍有傳統 UI 兜底（如 Notion AI、GitHub Copilot）
- AI 原生型：整個產品圍繞 AI 構建，去掉 AI 產品就不成立（如 ChatGPT、Cursor、Midjourney）
2. 設計原則：AI 原生產品的「憲法」
設計 AI 原生應用不能照搬傳統軟體的設計思路。AI 的機率性、延遲性和不可預測性，要求我們建立一套全新的設計原則。
AI-Native Design Principles
Click a card to inspect each design principle
Graceful degradation
The system remains usable when AI fails
Human collaboration
Humans confirm critical decisions
Transparent and explainable
Help users understand AI reasoning
Feedback loop
User feedback drives improvement
🛡️ Graceful degradation
Models may time out, return errors, or hallucinate. Graceful degradation means the system has a fallback path instead of crashing when AI is unavailable.
Practice comparison
❌ Anti-pattern
After the model API times out, the page shows a blank error state and the user can only refresh.
✅ Recommended approach
After timeout, show a cached answer or related documents while retrying in the background.
Checklist
☐Set a reasonable API timeout, usually 30-60s
☐Prepare fallbacks such as cache, rules, or human handoff
☐Show the current state clearly to users
☐Log failures for later improvement
五大核心設計原則
- 擁抱不確定性：AI 的輸出不是 100% 可靠的，產品設計必須考慮「AI 可能出錯」的情況。提供編輯、重試、回饋機制，讓使用者始終擁有控制權。
- 漸進式信任：不要一開始就讓 AI 做高風險決策。先從低風險場景建立使用者信任，再逐步擴展 AI 的自主權。
- 透明可解釋：讓使用者知道 AI 在做什麼、為什麼這麼做。展示推理過程、引用來源、標註置信度。
- 人機協作：AI 不是替代人，而是增強人。最好的設計是讓 AI 做初稿，人做終審。
- 優雅降級：當 AI 服務不可用或結果不理想時，產品仍然可用。永遠有 Plan B。
3. Prompt 工程：AI 應用的「程式語言」
在傳統應用中，你用程式碼告訴電腦做什麼。在 AI 原生應用中，你用 Prompt 告訴模型做什麼。Prompt 就是 AI 時代的程式語言——寫得好，AI 表現驚豔；寫得差，AI 胡說八道。
Prompt Engineering Lab
Modify prompt structure and observe how output quality changes
System Prompt
User Prompt
Simulated output
Click "Simulate generation" to see the result
Prompt 設計的四層結構
- 系統提示詞（System Prompt）：定義 AI 的角色、能力邊界和行為規範。這是「憲法」級別的指令，使用者看不到但始終生效。
- 上下文注入（Context）：透過 RAG 檢索到的相關文件、使用者歷史記錄等，為 AI 提供回答所需的背景資訊。
- 使用者輸入（User Message）：使用者的實際問題或指令。
- 輸出格式約束（Format）：指定 AI 的輸出格式（JSON、Markdown、特定模板），確保結果可被程式解析。
| Prompt 技巧 | 說明 | 效果 |
|---|---|---|
| 角色設定 | 「你是一個資深前端工程師」 | 提升專業領域回答品質 |
| Few-shot 範例 | 給出 2-3 個輸入輸出範例 | 讓模型理解期望的格式和風格 |
| 思維鏈（CoT） | 「請一步步思考」 | 提升複雜推理的準確性 |
| 輸出約束 | 「用 JSON 格式回答」 | 確保輸出可被程式解析 |
| 負面指令 | 「不要編造不確定的資訊」 | 減少幻覺和錯誤資訊 |
4. 互動模式：AI 時代的使用者體驗
AI 原生應用催生了一批全新的互動模式。傳統應用的互動是「點擊-等待-查看」，而 AI 應用的互動更像是「對話-觀察-調整」。
AI-Native Interaction Patterns
Click a card to experience each AI interaction pattern
Streaming output
Generate progressively with immediate feedback
Smart loading states
Show progress in stages
Confidence indicators
Show how certain AI is
Graceful fallback
Fallback strategy when uncertain
四種核心互動模式
- 流式輸出（Streaming）：AI 生成內容時逐字顯示，而不是等全部生成完再展示。這大幅降低了使用者的感知等待時間，也讓使用者可以在生成過程中判斷方向是否正確。
- 多輪對話（Multi-turn）：透過上下文記憶實現連續對話，使用者可以逐步細化需求。關鍵挑戰是上下文視窗管理和對話歷史壓縮。
- 多模態互動（Multimodal）：支援文字、圖片、語音、檔案等多種輸入方式，AI 也能輸出圖片、程式碼、表格等多種格式。
- Agent 模式（Agentic）：AI 不只是回答問題，而是自主規劃、執行多步驟任務。使用者給出目標，AI 自行拆解步驟並逐一完成。
5. 請求流程：一次 AI 呼叫的完整生命週期
當使用者在 AI 應用中發送一條訊息，背後發生了什麼？理解這個完整流程，是構建可靠 AI 應用的基礎。
AI Application Request Flow
Click "Send request" to observe the full lifecycle of an AI request
User input
User Input
→
Preprocessing
Preprocessing
→
Model inference
Model Inference
→
Post-processing
Post-processing
→
Response
Response
請求處理的六個階段
- 輸入預處理：校驗使用者輸入、內容安全審核、敏感資訊去識別化
- 上下文組裝：拼接系統提示詞、檢索相關文件（RAG）、載入對話歷史
- 模型呼叫：將組裝好的 Prompt 發送給 LLM API，開啟流式回應
- 輸出後處理：格式化輸出、內容安全過濾、結構化資料提取
- 結果快取：對常見問題快取結果，降低成本和延遲
- 監控記錄：記錄 token 用量、回應時間、使用者回饋，用於持續最佳化
| 階段 | 關鍵考量 | 常見問題 |
|---|---|---|
| 輸入預處理 | 注入攻擊防護、長度限制 | Prompt 注入、越獄攻擊 |
| 上下文組裝 | token 預算分配、資訊優先級 | 上下文溢位、關鍵資訊被截斷 |
| 模型呼叫 | 逾時處理、重試策略、流式傳輸 | API 限流、網路逾時 |
| 輸出後處理 | 格式校驗、幻覺檢測 | 輸出格式不符預期 |
| 快取策略 | 語意快取 vs 精確快取 | 快取命中率低 |
| 監控告警 | 成本監控、品質評估 | token 成本失控 |
總結
AI 原生應用設計不是簡單地在傳統應用上疊加 AI 功能，而是從架構、互動、工程實踐等維度進行全面重構。
回顧本章的關鍵要點：
- 架構轉變：從確定性邏輯到機率性推理，AI 原生應用需要全新的架構思維
- 設計原則：擁抱不確定性、漸進式信任、透明可解釋、人機協作、優雅降級
- Prompt 是核心：Prompt 工程是 AI 應用的「程式語言」，直接決定產品品質
- 互動革新：流式輸出、多輪對話、多模態、Agent 模式重新定義了使用者體驗
- 全鏈路思維：從輸入預處理到監控告警，每個環節都需要針對 AI 特性專門設計
延伸閱讀
- Google PAIR Guidelines - Google 的人機互動 AI 設計指南
- OpenAI Prompt Engineering Guide - 官方 Prompt 工程最佳實踐
- Anthropic Prompt Engineering - Claude 的 Prompt 設計指南
- Nielsen Norman Group: AI UX - AI 使用者體驗研究
- Building LLM Applications - 構建 LLM 應用的實戰指南