昨天報價單的成功協作讓我複雜工作流設計，但今天面對退換貨系統時，是一個完全不同層級的挑戰。這不是建立新訂單的「從零開始」，而是處理既有訂單的「逐項修改」。更複雜的是，每個修改都會觸發連鎖的金額重新計算。

這正是測試AI是否能理解「例外情境處理」的完美案例。關鍵問題是：如何讓AI區分「選擇新商品」和「處理既有商品」的根本差異？

從新增訂單到處理例外：設計挑戰的本質升級

昨天的報價單雖然複雜，但本質上仍是「建立新資料」的過程。客戶從空白開始選擇商品，店員協助建構一個全新的訂單。整個流程有明確的起點和終點，邏輯相對線性。

但退換貨完全不同。這是對「既存資料的重新決策」，每個商品都面臨三種可能：保持不變、申請退貨、或申請換貨。更複雜的是，這些決策會相互影響，因為原訂單的優惠折扣需要重新分攤計算。

核心挑戰的差異：

• 報價單：空白→填滿→完成
• 退換貨：既有→修改→重算→確認

這種「狀態修改」比「資料建立」需要更精密的互動設計。

退換貨的真實業務邏輯：逐項重新決策

在設計Prompt之前，我先分析了門市退換貨的實際情境。與產品選擇的開放性不同，退換貨有固定的處理框架，但每個商品的處理選擇會影響整體計算。

典型的退換貨情境：
客戶原本訂購了5件商品（總價$8000，用了會員折扣-$800，實付$7200），現在要：

• 商品A（$2000）：尺寸不合，要換成$2500的商品B
• 商品C（$1500）：有瑕疵，要退貨
• 其他3件商品：滿意，保持不變

複雜的計算邏輯：

1. 原$800會員折扣要如何在剩餘商品間重新分攤？
2. 換貨的$500差價是否享有會員價？
3. 退貨的商品如何計算應退金額？
4. 最終客戶是要補錢還是退錢？

這種「每個決策影響整體計算」的邏輯，需要非常清楚的介面設計來呈現。

三區塊Layout的完美適配：處理既有vs建立新增

昨天報價單的三區塊Layout架構在這裡展現了絕佳的適配性。同樣的框架，但每個區塊的職責完全重新定義：

左側區塊：客戶與訂單查詢

• 客戶基本資訊查詢
• 該客戶的歷史訂單列表
• 選定要處理的特定訂單

中間區塊：原訂單商品逐項處理

• 顯示選定訂單的完整商品清單
• 每個商品旁提供處理選項：保持/退貨/換貨
• 退換貨原因選擇和新商品選擇

右側區塊：複雜金額重新計算

• 原訂單金額明細
• 各項異動的金額影響
• 最終應補或應退的金額

這種設計讓複雜的退換貨處理變得井然有序，每個區塊都有明確的職責範圍。

核心挑戰：Prompt實戰 - 讓AI理解「處理既有」的概念

基於前13天的經驗積累，我設計了針對退換貨特殊邏輯的Prompt。但這次的挑戶在於如何讓AI理解「處理模式」而非「建立模式」。

第一次嘗試：基於經驗的初步描述

基於Layout框架設計.md，設計退換貨處理系統：

使用情境：
- 客戶來門市處理已購買商品的退換貨
- 店員需要處理原訂單中的每個商品狀態
- 支援複雜的金額重新計算邏輯

業務流程：
1. 選定客戶和訂單 → 2. 載入原訂單商品 → 3. 逐項選擇處理方式 → 4. 計算金額變化 → 5. 確認處理

Layout要求：
- 沿用報價單的三區塊設計
- 左側：客戶查詢、訂單選擇
- 中間：原訂單商品清單、處理方式選擇
- 右側：金額重算、最終確認

請產出HTML、CSS、JS三個獨立檔案。

AI的理解結果： 基本框架正確，但有關鍵問題：

• 中間區域變成了「重新選商品」而不是「處理既有商品」
• 換貨功能被理解成「刪除舊商品，新增新商品」
• 金額計算沒有考慮原訂單優惠的重新分攤

發現的問題： AI習慣「建立新資料」的模式，很難理解「修改既有資料」的概念。

第二次嘗試：強化「既有商品處理」概念

基於Layout框架設計.md，設計退換貨處理系統：

使用情境：
- 處理客戶既有訂單中的商品退換需求
- 不是重新選購，而是對已購商品逐項做處理決策
- 每個處理決策都會影響整體金額計算

業務邏輯重點：
- 中間區域顯示「原訂單的既有商品清單」
- 每個商品都要決定：保持不變/退貨/換貨
- 換貨是「替換」概念，不是「新增」概念
- 右側金額要處理原優惠的重新分攤

關鍵互動：
- 左側選定訂單後，中間立即顯示該訂單的「既有商品」
- 中間每個商品狀態變更，右側金額要即時重算
- 換貨時要選擇「替換成什麼商品」，差價計算要清楚顯示

請產出完整的三個檔案，重點處理「既有資料修改」邏輯。

AI的理解結果： 大幅改善！這次AI正確理解了：

• 中間區域確實顯示原訂單商品，不是重新選購
• 換貨邏輯變成「商品A換成商品B」的替換概念
• 金額計算考慮了原訂單優惠的重新分配

但仍有細節問題：退貨原因選擇和金額計算的視覺呈現不夠清楚。

第三次嘗試：精確化互動細節

基於Layout框架設計.md，設計退換貨處理系統：

使用情境：
- 客戶要處理既有訂單，可能部分退貨、部分換貨
- 店員需要清楚看到每個決策對總金額的影響
- 客戶要明白最終是要補錢還是退錢

完整流程：
1. 左側選定客戶和訂單 → 2. 中間載入該訂單的所有商品 → 3. 逐項選擇：保持/退貨/換貨 → 4. 右側即時顯示金額變化 → 5. 確認最終處理

中間區域設計重點：
- 顯示原訂單的商品清單（商品名、數量、單價）
- 每個商品有三個選項：「保持不變」「申請退貨」「申請換貨」
- 選擇退貨時：要選退貨原因（瑕疵/尺寸/其他）
- 選擇換貨時：要選擇要換成的新商品，顯示差價

右側金額計算重點：
- 原訂單總額明細
- 退貨商品的退款計算（扣除折舊等）
- 換貨商品的差價計算
- 原優惠折扣的重新分攤
- 最終結果：客戶應補$XXX或應退$XXX

請產出完整的三個獨立檔案。

AI的理解結果： 完美！這次AI完全掌握了退換貨的複雜邏輯，產出的介面完全符合實際業務需求。

關鍵發現：「既有資料處理」的描述技巧

1. 明確區分建立vs修改 → 重複強調「既有」「原訂單」等關鍵詞
2. 具體化處理選項 → 「保持/退貨/換貨」比「處理方式」更精確
3. 視覺化計算邏輯 → 詳細描述金額計算的每個步驟和顯示方式

最關鍵的發現是：處理例外情境時，AI需要更具體的邊界條件描述。相比正常流程，例外處理的每個分支都需要明確定義。

複雜金額計算的視覺化：透明度是關鍵

退換貨最複雜的部分是金額重新計算。客戶需要清楚看到每個決策如何影響最終金額，這不只是計算正確性，更是信任建立的關鍵。

金額計算的分層邏輯：

• 第一層：原訂單金額拆解（商品價格、優惠、實付金額）
• 第二層：退貨影響（退款金額、扣除項目）
• 第三層：換貨影響（新商品價格、差價計算）
• 第四層：最終結算（應補金額或應退金額）

視覺呈現的關鍵：
每個計算步驟都要有清楚的數學邏輯展示，讓客戶能夠理解和接受最終結果。這種透明度設計在處理客戶異議時非常重要。

Prompt實作案例：完整的需求描述模板

基於以上分析和三次迭代的經驗，我總結出處理複雜例外情境的Prompt模板：

基於Layout框架設計.md，設計退換貨金額重算系統：

使用情境：
- 處理客戶對既有訂單的退換貨需求
- 每個商品都需要重新決策：保持/退貨/換貨
- 客戶要清楚看到複雜的金額重算過程

業務邏輯：
- 這是「修改既有資料」不是「建立新資料」
- 中間區域處理「原訂單既有商品」的狀態變更
- 右側處理複雜的金額重新分攤和計算

Layout要求：
- 沿用成功的三區塊架構
- 左側：客戶查詢、訂單選擇（固定300px）
- 中間：既有商品逐項處理（自適應寬度）
- 右側：分層金額計算顯示（固定280px）

核心互動：
- 左側訂單選擇觸發中間商品清單載入
- 中間商品狀態變更即時影響右側金額計算
- 右側清楚顯示每層計算邏輯和最終結果

技術要求：
- HTML、CSS、JS三個獨立檔案
- 支援複雜的條件判斷和即時計算
- 金額變化要有清楚的視覺回饋

請產出完整原型，重點展現例外情境的處理邏輯。

例外情境AI協作的核心洞察

通過退換貨系統的設計協作，我發現了處理例外情境的幾個關鍵原則：

邊界條件比正常流程更重要： 例外情境的每個分支都需要明確定義，AI無法像處理正常流程那樣進行推測。

狀態管理比資料建立更複雜： 修改既有資料需要考慮更多的前後關係和依賴性，描述時要特別強調這些關聯。

計算邏輯的透明化設計： 複雜的計算不只要正確，更要讓使用者理解。視覺化呈現比功能實現更重要。

檔案分離在複雜邏輯中的價值： 退換貨的條件判斷和計算邏輯更複雜，分離的JS檔案讓邏輯更清晰，修改更精確。

退換貨系統讓我學會了如何用AI處理「例外情境」的複雜設計。與昨天的報價單相比，這次的挑戰不在於工作流程的順暢性，而在於如何讓AI理解「既有資料的狀態管理」。好的例外處理設計，往往比正常流程設計更能展現系統的專業程度。