從前面幾天，我們成功完成了四個核心功能：產品查詢、客戶管理、訂單系統、退換貨處理。每個功能單獨測試都運作良好，但當我開始進行跨功能操作時，才發現了一個更深層的問題：功能完整不等於系統流暢。

為什麼要做跨功能測試？
有人可能會問：既然只是做AI協作的原型設計練習，為什麼要在意系統整合？關鍵在於，原型設計的核心價值就是「驗證真實使用流程」。在真實的門市場景中，沒有任何功能是孤立存在的。客戶進門到離開，會涉及多個系統的連續操作。

如果原型只能展示各別功能，卻無法驗證完整的使用者旅程，那就失去了原型設計最重要的價值：提早發現問題和驗證設計邏輯。更重要的是，透過跨功能整合，我們能學習如何用AI協作處理更複雜的系統性設計挑戰。

從功能孤島到流程協作：發現真正的整合挑戰

前四天的設計協作，每個頁面都達到了預期效果。但今天嘗試完整的門市操作流程時，卻發現了系統性的問題。

典型的門市操作情境：
客戶王小姐進門，我在客戶管理系統找到她的資料，然後切換到訂單系統為她建立報價單。看似簡單的跨頁面操作，卻出現了斷點：訂單系統無法記住我在客戶管理已經選定的客戶，需要重新搜尋選擇。

暴露的根本問題：
我們有四個精美的功能頁面，但它們像四座孤島，缺乏有機的連結。每個頁面都要求使用者「從頭開始」，完全沒有考慮到前一個頁面的操作結果。

發現的三大跨頁面協作問題

深入分析後，我歸納出三個核心的整合問題：

1. 跨頁面資料流轉斷裂

最明顯的問題是狀態無法跨頁面保持。在客戶管理選定「王小姐」後，切換到訂單頁面，系統完全不知道我剛才的選擇。使用者需要在每個頁面重新輸入或選擇相同的資訊。

2. 業務流程銜接缺失

退換貨頁面查看訂單詳情時，無法跳轉回原始的訂單頁面進行修改。各功能間缺乏業務邏輯的自然銜接，導致操作流程被人為切斷。

3. 全域狀態管理空白

整個系統缺乏「當前客戶」「當前訂單」這樣的全域概念。每個頁面都是獨立的狀態空間，無法形成統一的操作上下文。

這些問題讓我意識到：AI協作不只要考慮單一功能的完整性，更要思考系統層級的整合邏輯。

AI協作實戰：系統整合的Prompt策略

面對這種系統性整合需求，我發現需要全新的AI協作策略。這不再是「創建新功能」，而是「增強既有系統」的複雜任務。

第一次嘗試：直接描述整合需求

基於已完成的四個功能頁面，建立跨頁面資料流轉機制：

整合需求：
- 客戶管理頁面選定客戶後，切換到訂單頁面要自動載入該客戶
- 退換貨頁面查看訂單時，要能跳轉到原始訂單詳情
- 建立全域狀態管理，支援跨頁面資料共享

請提供完整的整合方案。

AI的理解結果： 產出了一個全新的「整合系統」，但完全重寫了原有的四個頁面，破壞了前四天累積的所有設計成果。

發現的問題： AI習慣「重新創建」而非「增強現有」，需要更精確的引導來避免破壞性修改。

第二次嘗試：強調保持既有結構

基於products.html、client-management.html、quote-system.html、return-exchange.html已完成的四個功能頁面，進行系統整合優化：

重要前提：
- 保持現有四個頁面的所有功能和設計
- 不重寫任何現有檔案，只新增整合機制
- 各頁面的HTML、CSS、JS分離結構不變

整合方案：
- 新增shared/global-state.js處理跨頁面狀態
- 修改各頁面的初始化邏輯，加入狀態監聽
- 建立頁面間的資料傳遞協議

技術要求：
- HTML、CSS、JS檔案保持獨立
- 全域狀態使用localStorage存儲
- 提供具體的程式碼修改指引

請提供「增量修改」方案，不要重寫現有功能。

AI的理解結果： 這次好很多！AI理解了「增強而非重建」的概念，提供了具體的檔案修改建議和新增的狀態管理機制。

第N次優化：分階段實施指導

基於現有四個功能頁面檔案，分三個階段實施系統整合：

現有檔案結構：
- products.html/products.css/products.js (產品查詢系統)
- client-management.html/client-management.css/client-management.js (客戶管理系統)
- quote-system.html/quote-system.css/quote-system.js (訂單報價系統)
- return-exchange.html/return-exchange.css/return-exchange.js (退換貨處理系統)

階段一：建立全域狀態管理
- 創建shared/global-state.js
- 定義currentCustomer、currentOrder狀態
- 提供狀態更新和監聽API

階段二：修改各頁面初始化
- 客戶管理：加入狀態更新邏輯
- 訂單系統：加入狀態讀取邏輯
- 退換貨：加入狀態監聽邏輯
- 產品查詢：保持獨立運作

階段三：建立頁面間跳轉
- 設計統一的跳轉參數格式
- 實現帶狀態的頁面切換
- 測試完整的業務流程

請先提供階段一的完整實作代碼。

AI的理解結果： 完美！分階段的方式讓AI能夠專注在特定任務上，避免了複雜度過高導致的理解偏差。

檔案架構演進：從獨立到協作

透過這次整合實戰，我建立了新的檔案組織架構：

原有結構（保持不變）

/products/
  products.html
  products.css  
  products.js

/client-management/
  client-management.html
  client-management.css
  client-management.js

/quote-system/
  quote-system.html
  quote-system.css
  quote-system.js

/return-exchange/
  return-exchange.html
  return-exchange.css
  return-exchange.js

新增的整合層

/shared/
  global-state.js     // 全域狀態管理
  page-router.js      // 頁面跳轉邏輯
  common-utils.js     // 共用工具函數

實作案例：全域狀態管理

// shared/global-state.js
class GlobalState {
  constructor() {
    this.state = {
      currentCustomer: null,
      currentOrder: null,
      lastPage: null
    };
    this.listeners = {};
  }

  setState(key, value) {
    this.state[key] = value;
    localStorage.setItem('app_' + key, JSON.stringify(value));
    this.notifyListeners(key, value);
  }

  getState(key) {
    const stored = localStorage.getItem('app_' + key);
    return stored ? JSON.parse(stored) : this.state[key];
  }

  subscribe(key, callback) {
    if (!this.listeners[key]) {
      this.listeners[key] = [];
    }
    this.listeners[key].push(callback);
  }

  notifyListeners(key, value) {
    if (this.listeners[key]) {
      this.listeners[key].forEach(callback => callback(value));
    }
  }
}

window.appState = new GlobalState();

這樣的架構讓各頁面保持獨立性，同時具備了協作能力。

整合測試的實際效果

實施整合方案後，門市操作流程變得順暢：

優化後的操作體驗：

1. 在客戶管理選定王小姐→系統記住當前客戶
2. 切換到訂單頁面→自動載入王小姐的資訊和暫存商品
3. 完成報價後進入退換貨→可直接查看王小姐的歷史訂單
4. 處理退換貨時→可跳轉回原始訂單進行比對

整個流程一氣呵成，不再有資訊斷點。

系統性AI協作的關鍵洞察

透過這次整合實戰，我總結出幾個重要發現：

增強思維vs創建思維的根本差異： AI天生擅長創建新功能，但修改既有系統需要更精確的引導。必須明確強調「保持現有」「增量修改」等關鍵概念。

分階段實施的必要性： 複雜的系統整合一次完成容易出錯，分階段實施讓AI能專注在特定任務上，提高成功率和可控性。

狀態管理的系統性價值： 良好的狀態管理不只解決技術問題，更是實現流暢用戶體驗的基礎。這種系統性思考在AI協作中需要特別強調。

檔案架構的可擴展性： 從一開始就考慮系統整合的檔案組織，比後期重構更有效率。獨立性和協作性需要在架構設計階段就平衡考慮。

原型整合測試讓我學會了AI協作的「系統性思考」。單一功能的完美不等於系統的流暢，真正的挑戰在於如何讓各部分協調工作。好的整合設計不是推倒重來，而是在保持既有優勢的基礎上，建立有機的連結機制。