經過前6天的密集規劃,從專案啟動、需求訪談到系統架構設計,我們已經完成了一個相當完整的前期準備。但真正的挑戰才剛開始——當我第一次請Claude幫我產出prototype時,那個「哇,差距怎麼這麼大」的瞬間,讓我深刻體會到AI協作中最重要的一課:理想與現實之間的gap,往往隱藏在細節裡。
經過前6天的規劃,我們已經建立了相當完整的基礎:從業務需求分析、實地訪談、流程量化,到完整的5大核心系統架構設計。整個專案的藍圖看起來很完美,我也是這麼想的,直到我開始請Claude幫我製作實際的prototype...
當我滿懷期待地向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,但是...
Claude產出的第一版明顯還是mobile的思維:
我想要的是:
雖然Claude把各個功能頁面都產出了,但內容細節明顯不夠深入:
實務上我們需要:
Claude的第一版產出是把所有功能都放在一個HTML頁面上,用CSS來切換顯示。更大的問題是,因為我要求「每頁可獨立運行」,Claude嘗試產出所有頁面的完整程式碼,結果:
這個經驗讓我意識到,「想要一次獲得所有功能」本身就是不合理的期待。
看到第一版prompt的問題後,我意識到最大的錯誤是「太貪心」。重新調整的重點:
調整前的問題:
調整後的策略:
我發現Claude更能理解具體的使用場景,而不是抽象的功能需求。新的prompt方向:
從: 「建立客人報價單」
改為: 「店員小美要幫客戶查詢一組沙發的庫存,客戶指著展示品說想要這組沙發...」
具體的場景描述讓AI更容易理解真實的操作邏輯。
因為觸發使用量限制的教訓,我徹底改變了策略:
新原則:
經過這些調整,我重新思考了什麼是真正有效的AI協作策略:
原本的想法: 一次產出完整的多頁面系統
現實的教訓: 觸發使用量限制,品質也無法保證
新的策略: 專注單一模組,做到可展示的品質
基於業務價值和AI協作的可行性,重新排序:
不同的描述方式會產出完全不同的結果。我學到:
Claude很聰明,但它的理解還是有邊界:
AI協作不是「下指令」,而是「對話」:
這次的「失敗」經驗讓我學到最重要的事:
AI協作不是魔法,而是一門需要學習的技能。
就像學習任何新工具一樣,我們需要:
有時候,最好的學習來自於「被現實打臉」的瞬間。當我要求Claude產出完整prototype,結果直接觸發使用量限制時,我才真正理解什麼叫做「AI協作的現實」。