從整段開發歷程中挑出 5 段對話,代表 Vibe Coding 過程中最關鍵的判斷點。
指令 1 · 階段 1 Gemini
用情境式提示讓 Gemini 把需求整理成清單
不是直接問「幫我寫需求」,而是給 Gemini 一個具體場景,讓它從場景中推導需求。注意指令中要求 AI 用「使用者故事」格式回答(Agile 軟體開發圈的標準寫法,「身為 X,我希望 Y,這樣可以 Z」),這樣產出的需求清單更聚焦。
我是醫院品管同仁,手上同時跑這幾種專案:
1. 醫院評鑑(每 3 年一次,8-12 個月準備期)
2. JCI 國際醫療品質認證(每 3 年一次)
3. 疾病別認證(乳癌、糖尿病、中風等多種)
4. QCC 品管圈競賽(每年一次)
5. 醫策會競賽(每年一次)
6. 臨時被指派的各式品質專案
請幫我整理:
- 這些專案有什麼共通的「任務型態」?
- 共通的「時程節點」是什麼?
- 一個能管理所有專案的儀表板,核心應該有哪些功能?
- 用「使用者故事」格式列出 5-8 個必要功能,例如「身為品管同仁,我希望……」
關鍵心法: 不要問「幫我寫需求」,要給 AI「具體情境 + 期望產出格式 」,AI 才能產出可用的需求清單。
指令 2 · 階段 2 Claude
請 Claude 用「方案 A vs B vs C vs D」格式給 UI 建議
這是反覆精修的關鍵手法,不要問「你建議怎麼設計」,要問「給我 2-3 個方案,各自優缺點 」。實際操作中,Claude 主動擴充給了 4 個方案,讓決策依據更完整。
儀表板首頁要呈現 4 個關鍵指標(總進度、逾期任務、本月完成、即將到期)。
我想讓使用者能快速看懂每個指標背後的計算邏輯,但又不想畫面太擠。
請給我 2-3 個方案,各自說明:
- 設計做法
- 適合情境
- 缺點 / 限制
- 觸控裝置(平板)上是否還能用
不要直接給我「建議方案」,我要看選項對照後自己決定。
Claude 的回應(1/2) :方案 A「滑鼠懸浮 Tooltip」vs 方案 B「內嵌副資訊」,各列適合 / 不適合情境
Claude 的回應(2/2) :方案 C「點擊展開明細」+ 方案 D「整張卡可點 → 跳轉明細頁(推薦)」。Claude 自動把選項擴展到 4 個,並主動標出推薦選項與理由(最符合 Apple HIG「每個 cell 都該是 actionable 的」)
關鍵心法: 「給我 2-3 個方案做對照 」比「給我最好的方案 」有用十倍,你會從對照中學到設計權衡。實作上 Claude 還會主動補方案、標推薦,並引用業界設計準則(這裡是 Apple HIG 蘋果官方介面設計準則,「每個 cell 都該是 actionable 的」意思是「每一個格子都該能點、能做事」)當作依據,比直接給結論更可信。
指令 3 · 階段 2 Claude
用「請扮演挑剔的評審」逼出更深入的建議
想要 Glassmorphism(玻璃擬態)風格,先問風格適不適合自己的應用,而不是直接套用。
我考慮用 Glassmorphism(玻璃擬態)風格做這個儀表板的卡片。
請你扮演一位「挑剔的 UI 設計師 」,從下面三個角度評估這個風格適合度:
1. 醫療專業環境(對比度、字體易讀性)
2. 高頻使用情境(每天打開、視覺疲勞)
3. 跨裝置體驗(老舊電腦能不能跑、平板上手感)
如果評估後不適合,請給我 3 個替代風格,並說明為什麼更合適。
Claude 的實際回應 :玻璃擬態的視覺缺點,加上替代風格(Clinical Pro / 極簡 / Material 3 / Apple HIG)的對照
關鍵心法: 「請扮演挑剔的評審 」這個 prompt 模式,能讓 AI 跳脫「給使用者想要的答案」,真正提出反對意見。
指令 4 · 階段 3 Claude
用「視覺對照表」一次比較多種設計風格
選風格時最容易陷入「文字描述聽起來都不錯」的困境。請 Claude 直接畫出 4 種風格的縮圖對照。
幫我為「乳癌診療品質認證 2026」這張專案卡片,
畫出 4 種不同風格的設計縮圖,並列出:
- 風格名稱(英文)
- 參考的設計系統(例如 Material 3、Apple HIG)
- 主要色調(用色票呈現)
- 適合什麼情境
用左右對照的方式呈現,讓我能一眼比較。
Claude 的實際回應 :醫療專業風(Clinical Pro)、極簡風(Notion 與 Linear 都是知名的極簡設計工具)、Material 3(Google 的設計語言)、Apple HIG(蘋果的設計準則)四種風格的縮圖、色票、適用情境
關鍵心法: 選風格用「視覺縮圖對照 」比文字描述快十倍。Claude 能直接畫出 HTML / CSS 渲染的縮圖,看完當場決定。
指令 5 · 階段 4 Claude Code
把凍結的 SPEC 一次餵給 Claude Code 實作
前三階段的對話都整理成 SPEC v3.0(PDF),再把這份 SPEC 整份丟給 Claude Code,而不是讓它從零想需求。
請依照附上的 SPEC v3.0 文件,實作這個醫療品質專案管理儀表板。
技術要求(SPEC 已定案,不要再變動):
- 純前端:HTML + CSS + JavaScript,不用框架
- 資料儲存:IndexedDB(瀏覽器本地儲存,離線可用)
- 字體:Noto Sans TC(Apple HIG 推薦)
- 配色:深藍 + 暖橘(SPEC 第 4 章已定義色票)
- 無障礙:符合 WCAG AA 標準(對比度、鍵盤導覽、語意 HTML)
- 響應式:桌機、平板、手機都要好看
- 部署:GitHub Pages(免費),含 PWA 設定(可加桌面捷徑)
請先列出實作計畫(分階段、每階段產出),確認後再開始寫程式。
有疑問或 SPEC 沒寫到的細節,直接問我,不要自行決定。
關鍵心法: SPEC 凍結後再進實作,Claude Code 不會偏題;明確說「SPEC 沒寫到的直接問我」,避免它自己決定關鍵設計。