昨天建立的完成度邊界管理讓我們學會控制AI的完善傾向，但今天面對響應式設計時，卻發現了新的挑戰：AI對「適度響應式」的理解與人類期望存在落差。當我要求AI調整iPad直向佈局時，它總是想做得「太完美」，產出複雜的媒體查詢和過度的適配邏輯。這讓我意識到，響應式設計同樣需要邊界控制，尤其在原型階段。

AI對響應式設計的理解差異

AI在響應式設計上展現明顯的能力偏差。它非常擅長技術實現：能熟練使用媒體查詢、flexbox、grid等工具，也深知標準的breakpoint設定。但AI缺乏對實際使用情境的判斷：不知道iPad在門市中主要以橫向使用，不理解直向模式只是偶爾需要，更無法感知哪些響應式調整對使用者體驗真正重要。這種認知差異導致AI經常產出技術正確但情境不當的設計。

實作案例1：訂單系統的響應式調整

基於昨天的邊界控制策略，我設計了具體的響應式prompt：

基於現有訂單系統，進行基礎響應式調整：

響應式需求：
- iPad橫向(1024px)：維持現有三欄佈局
- iPad直向(768px)：改為上下兩區塊佈局
- 保持48px以上按鈕尺寸
- 字體大小保持可讀性

邊界控制：
- 只調整佈局和尺寸，不改變功能邏輯
- 使用基本CSS媒體查詢，不引入框架
- 保持HTML、CSS、JS檔案分離
- 避免複雜的響應式動畫

請提供修改建議，不要重寫整個系統。

修正要點：第一版AI產出了完整的RWD框架，我立即要求「只修改現有CSS檔案，保持HTML結構不變」，成功控制了修改範圍。

邊界設定：原型階段的響應式範圍

響應式設計的邊界控制比功能開發更重要。必要的調整包括：基本的佈局適配（橫向/直向）、觸控元素尺寸維持、關鍵資訊的可見性。過度的完善則包括：多種設備的完整適配、複雜的響應式圖片、精細的字體階層系統。在原型階段，我們只需要驗證主要使用情境下的介面邏輯，不需要追求全設備的完美體驗。這與Day17的邊界管理概念完全呼應：剛好夠用勝過完美無缺。

實作案例2：導航系統的跨設備適配

底部導航的響應式調整更能體現邊界控制的重要性：

優化底部導航在不同iPad方向的顯示：

具體要求：
- 橫向：80px高度，5個Tab水平排列
- 直向：調整為合適高度，保持可觸控
- Tab圖示和文字都清楚可見
- 切換方向時保持當前選中狀態

技術限制：
- 修改現有CSS檔案，不重建導航系統
- 使用CSS媒體查詢實現
- 保持與現有設計風格一致
- HTML、CSS、JS檔案保持分離

關鍵修正：AI最初想重寫整個導航架構，我強調「只調整CSS樣式」後，它專注在視覺層面的適配，保持了系統的穩定性。

AI協作的響應式設計策略

建立有效的響應式設計協作需要分階段實施。第一階段：確定主要使用情境，在我們的案例中是iPad橫向使用。第二階段：定義最小必要的適配範圍，通常只需要處理主要的方向切換。第三階段：逐步微調，而非一次到位。檔案分離在響應式設計中更加重要：CSS檔案專注樣式調整，JS檔案處理狀態維持，HTML保持結構穩定。這種分離讓每次調整都有明確的作用範圍，避免牽一髮動全身的複雜修改。

Prompt具體性的重要：防止AI重做現有介面

AI在響應式調整中最大的問題是「重建傾向」。當我們說「優化iPad直向顯示」時，AI經常重寫整個介面。經過17天的協作經驗，我發現防止AI重做現有介面需要極度具體的prompt設計。

關鍵策略包括：檔案層級的邊界設定，明確指定要修改的檔案（「只修改products.css，不動products.html和products.js」）；結構層級的保護指令，強調保持現有架構（「保持三欄佈局的HTML結構，只調整CSS樣式」）；功能層級的範圍限制，提供具體的修改範圍（「只在@media查詢中調整flexbox屬性，不修改JavaScript邏輯」）。

更重要的是，要在prompt開頭就建立「增量思維」：「基於現有完整功能的products頁面進行微調」比「重新設計響應式products頁面」效果好太多。這種邊界明確的prompt讓AI專注在增量調整，而非全面重構，確保累積17天的設計成果和業務邏輯不會被意外破壞。

響應式設計的邊界控制比功能開發更加重要。AI天生追求技術完整性，但原型階段需要的是情境適配性。學會在prompt中設定明確的技術邊界和使用情境，是讓AI產出「剛好夠用」響應式設計的關鍵。