昨天我們完成 System Prompt 的團隊導入，讓 .cursorrules 與 CLAUDE.md 可透過 Git 同步整合，進入正式開發流程。但今天，我們遇到了一個新的課題：

即使是程式實作階段，根據平台不同，AI 協作的期待與 Prompt 設計也完全不同。

今天的任務聚焦在 Dashboard 的實作，而這正是這個問題浮現的關鍵時刻。我們發現：「實作 Web 頁面」與「實作 iPad 介面」，對 AI 的互動方式與輸出內容有著本質上的差異。

一、Web 實作 vs iPad 實作：同樣是程式階段，AI 協作大不同

Web 實作場景

典型任務：切版、響應式設計、API 資料綁定

技術重點：

• 彈性排版（flex/grid）
• 多裝置支援（RWD）
• 動態內容與資料渲染

AI 協作期待：

• HTML/CSS 標準寫法
• Javascript / React component 建立
• 簡潔可讀、方便接 API 的結構

範例 Prompt：「請產生一個可響應式的商品列表區塊，三欄式排版，支援 hover 動畫效果。」

iPad 實作場景（App 式 Layout）

典型任務：固定區塊、流暢操作、視覺一致

技術重點：

• 固定頂部與底部（非滾動）
• 中間內容區可獨立滾動
• 對齊品牌視覺規範、觸控操作優化

AI 協作期待：

• 明確區塊定義（Top / Content / Bottom）
• 避免整頁位移
• 高度精準的 layout 設定與視覺參數
• 更接近 App 開發語言的溝通方式（非單純 HTML）

範例 Prompt：「根據 iPad 設計規範，請產出一個固定頂部與底部的 Dashboard Layout，內容區需支援獨立滾動，符合品牌視覺樣式。」

二、AI 協作策略的核心轉變

雖然這兩個場景都屬於實作階段，但 AI 的角色扮演與輸出格式設計，必須作出高度場景化的調整。

三、我們的發現：不是開發階段不同，而是平台場景不同

這讓我們理解到一個新事實：
Prompt 的設計邏輯，不該只根據開發流程階段，而必須對應實際操作平台。

今天的 Dashboard 實作讓這件事具體成形：

• Claude 開發者主要處理「結構思考、系統理解」，適合探討 iPad 固定式架構與使用者行為脈絡
• Cursor 開發者負責「精準輸出、可執行元件」，適合快速產出 Web component 並即時預覽除錯

兩者搭配的前提，就是我們在 System Prompt 裡針對場景做出了「明確的任務角色設定與結構輸出格式要求」。

四、下一步：針對場景進行 Prompt 模組化設計

今天的發現，讓我們往下一個階段邁進——
不是為開發者建立一份完美的 System Prompt，而是針對每一種任務/場景，打造對應的 Prompt 模組。

這也意味著：

• 不再強求一套通用規則
• 轉而設計一套依不同場景可靈活對應的 Prompt 工具箱