iT邦幫忙

2025 iThome 鐵人賽

DAY 7
1
生成式 AI

AI協作開發實戰:從需求到原型的挑戦系列 第 7

AI協作原型設計:從理想到現實的落差與調整

  • 分享至 

  • xImage
  •  

經過前6天的密集規劃,從專案啟動、需求訪談到系統架構設計,我們已經完成了一個相當完整的前期準備。但真正的挑戰才剛開始——當我第一次請Claude幫我產出prototype時,那個「哇,差距怎麼這麼大」的瞬間,讓我深刻體會到AI協作中最重要的一課:理想與現實之間的gap,往往隱藏在細節裡。

前6天的規劃回顧

經過前6天的規劃,我們已經建立了相當完整的基礎:從業務需求分析、實地訪談、流程量化,到完整的5大核心系統架構設計。整個專案的藍圖看起來很完美,我也是這麼想的,直到我開始請Claude幫我製作實際的prototype...

第一次Prototype產出的震撼教育

我的期待 vs 殘酷現實

當我滿懷期待地向Claude描述我的需求時,我以為有了完整的系統架構,AI就能輕易理解我想要什麼。我的第一版prompt是這樣的:

我想開發一款居家品牌店員業務建立報價單以及櫃檯生成訂單結帳的網頁系統(for iPad版本),請幫我設計所有的原型畫面。

預想會有兩個角色 
1. 業務店員: 
1-1. 主要負責帶客人
1-2. 並且介紹推銷商品 
1-3. 查詢客戶對產品的疑問、庫存 
1-4. 建立客人報價單
1-5. 一次可能有多組報價單 

櫃檯結帳人員 
2-1. 協助業務的報價單轉成訂單 
2-2. 協助客人結帳

請按照以下步驟來生成: 
1. 思考使用者需要 居家品牌店員開單&櫃檯結帳 網頁系統 具備哪些功能。
2. 以產品經理的角度規劃這些界面。 
3. 以設計師的視角思考這些原型界面的設計。
4. 使用 HTML 生成所有的原型畫面,不要放在同一個畫面,讓每頁可獨立運行。 
- 可使用 FontAwesome 或其他開源圖標庫,讓畫面更精美且接近實際 UI。 

這些畫面應該能夠直接交給開發人員進行實作。

結果Claude確實給了我一個prototype,但是...

現實的三大落差

1. iPad vs Mobile的設計思維差異

Claude產出的第一版明顯還是mobile的思維:

  • 畫面元素太小,不適合iPad的觸控體驗
  • 版面配置偏向手機的直向滾動
  • 沒有充分利用iPad的大螢幕優勢

我想要的是:

  • 觸控友好的大按鈕設計
  • 橫向版面配置,善用iPad的寬螢幕
  • 適合店員快速點選的操作邏輯

2. 功能深度與實務需求的落差

雖然Claude把各個功能頁面都產出了,但內容細節明顯不夠深入:

  • 產品搜索只有基本的關鍵字搜索
  • 報價單沒有考慮到實際的商業邏輯(折扣、會員價、組合優惠)
  • 庫存查詢缺少多倉庫、多規格的複雜情境

實務上我們需要:

  • 支援條碼掃描的庫存查詢
  • 複雜的價格計算邏輯
  • 多層級的產品分類系統

3. 整合頁面 vs 獨立頁面的架構問題

Claude的第一版產出是把所有功能都放在一個HTML頁面上,用CSS來切換顯示。更大的問題是,因為我要求「每頁可獨立運行」,Claude嘗試產出所有頁面的完整程式碼,結果:

  • 觸發使用量限制:單次產出的資料量過大,直接被限制使用
  • 檔案過於龐大:即使產出成功,也會難以維護
  • 缺少真實的頁面跳轉邏輯:無法模擬真實的使用者流程

這個經驗讓我意識到,「想要一次獲得所有功能」本身就是不合理的期待。

AI Prompt調整的學習之路

第一次調整:從「所有功能」到「明確限制」

看到第一版prompt的問題後,我意識到最大的錯誤是「太貪心」。重新調整的重點:

調整前的問題:

  • 要求「所有的原型畫面」
  • 想要「每頁可獨立運行」
  • 期待「直接交給開發人員實作」

調整後的策略:

  • 明確指定單一功能模組
  • 專注在iPad觸控體驗
  • 降低一次性產出的複雜度

第二次調整:從功能列表到使用場景

我發現Claude更能理解具體的使用場景,而不是抽象的功能需求。新的prompt方向:

從: 「建立客人報價單」
改為: 「店員小美要幫客戶查詢一組沙發的庫存,客戶指著展示品說想要這組沙發...」

具體的場景描述讓AI更容易理解真實的操作邏輯。

第三次調整:單一頁面深化策略

因為觸發使用量限制的教訓,我徹底改變了策略:

新原則:

  • 一次只專注一個頁面
  • 每個頁面都要達到可展示的品質
  • 用迭代方式逐步完善整個系統

重新定義協作目標

經過這些調整,我重新思考了什麼是真正有效的AI協作策略:

從「完整系統」到「單一深化」

原本的想法: 一次產出完整的多頁面系統
現實的教訓: 觸發使用量限制,品質也無法保證

新的策略: 專注單一模組,做到可展示的品質

模組重要性重新排序

基於業務價值和AI協作的可行性,重新排序:

  1. Login系統 - 相對簡單,適合練習AI協作技巧
  2. Dashboard - 資訊架構設計的挑戰
  3. 訂單系統 - 真正的核心業務價值
  4. 產品查詢 - 支援訂單的工具功能
  5. 客戶管理 - 數據呈現的複雜度
  6. 退換貨 - 例外情境的處理邏輯

新的協作原則

  1. 質量優先 - 一個完善的頁面勝過十個半成品
  2. 迭代思維 - 每次調整都是學習的機會
  3. 實用導向 - 每個產出都要能給業務方看
  4. 經驗累積 - 每個模組的成功都為下一個模組提供方法論

AI協作中的關鍵學習

1. Prompt工程的重要性

不同的描述方式會產出完全不同的結果。我學到:

  • 情境比功能重要:描述使用場景比列出功能清單更有效
  • 限制比開放重要:明確的限制條件能產出更精準的結果
  • 迭代比完美重要:分階段調整比一次到位更實際

2. AI理解的邊界

Claude很聰明,但它的理解還是有邊界:

  • 對於複雜的業務邏輯需要更多的上下文
  • 設計直覺需要人類的判斷和調整
  • 使用者體驗的細節需要真實的使用回饋

3. 協作的藝術

AI協作不是「下指令」,而是「對話」:

  • 我提供業務知識,AI提供技術實現
  • 我判斷結果合理性,AI負責快速迭代
  • 我們一起優化,而不是我單向要求

今天的核心收穫

這次的「失敗」經驗讓我學到最重要的事:

AI協作不是魔法,而是一門需要學習的技能。

就像學習任何新工具一樣,我們需要:

  1. 理解工具的能力邊界
  2. 掌握有效的溝通方式
  3. 建立合理的期待管理
  4. 培養迭代優化的耐心

有時候,最好的學習來自於「被現實打臉」的瞬間。當我要求Claude產出完整prototype,結果直接觸發使用量限制時,我才真正理解什麼叫做「AI協作的現實」。


上一篇
人機協作找答案 - AI引導下的系統量化之路(下)
下一篇
AI Prompt工程:如何讓AI理解iPad使用情境
系列文
AI協作開發實戰:從需求到原型的挑戦9
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言