從設計師到 Builder：用 AI 把想法做成產品
從設計師到 Builder：用 AI 把想法做成產品
從設計師到 Builder：用 AI 把想法做成產品
透過 Claude Code 與 Figma MCP，建立設計與程式之間的雙向互動，讓想法快速變成可運作的產品－以打造出缺席管理平台 Attendly 為例
透過 Claude Code 與 Figma MCP，建立設計與程式之間的雙向互動，讓想法快速變成可運作的產品－以打造出缺席管理平台 Attendly 為例
透過 Claude Code 與 Figma MCP，建立設計與程式之間的雙向互動，讓想法快速變成可運作的產品－以打造出缺席管理平台 Attendly 為例
Role
Role
Role
Product Designer· AI-assisted Builder（Solo）
Product Designer· AI-assisted Builder（Solo）
Product Designer· AI-assisted Builder（Solo）
Timeline
Timeline
Timeline
1 day sprint · Mar 25, 2026
1 day sprint · Mar 25, 2026
1 day sprint · Mar 25, 2026
Tools
Tools
Tools
Claude Code + Figma MCP · Cursor · GitHub · Zeabur
Claude Code + Figma MCP · Cursor · GitHub · Zeabur
Claude Code + Figma MCP · Cursor · GitHub · Zeabur
1. 專案背景
1. 專案背景
在 University of Maryland 擔任課程助教 (Teaching Assistant, 簡稱 TA) 的過程中，我需要管理 150+ 學生的出缺席、處理請假申請（Email），並隨時掌握學生的出席狀況。但實際上，這些工作分散在不同工具之中，例如 ELMS（美國常見的課程系統，像是台灣的 Moodle）、Google 表單與試算表、Email，需要大量手動整理與來回切換。
在 University of Maryland 擔任課程助教 (Teaching Assistant, 簡稱 TA) 的過程中，我需要管理 150+ 學生的出缺席、處理請假申請（Email），並隨時掌握學生的出席狀況。但實際上，這些工作分散在不同工具之中，例如 ELMS（美國常見的課程系統，像是台灣的 Moodle）、Google 表單與試算表、Email，需要大量手動整理與來回切換。
這個問題其實一直存在，但過去因為技術能力限制，我並沒有真的把它做成一個產品，而是妥協於現有工具帶來的不方便性。直到最近開始接觸 Claude Code 與 Figma MCP，我發現這個新的技術，可以讓我不再只停留在設計構想，而是直接把想法做成一個可運作的系統。
這個問題其實一直存在，但過去因為技術能力限制，我並沒有真的把它做成一個產品，而是妥協於現有工具帶來的不方便性。直到最近開始接觸 Claude Code 與 Figma MCP，我發現這個新的技術，可以讓我不再只停留在設計構想，而是直接把想法做成一個可運作的系統。
因此，我選擇以這個熟悉的痛點為出發點，嘗試用 AI 建立一個從「想法 → prototype → 產品」的設計開發流程，並實際做出一個整合出席紀錄、請假流程與政策判斷的出缺席管理系統。
因此，我選擇以這個熟悉的痛點為出發點，嘗試用 AI 建立一個從「想法 → prototype → 產品」的設計開發流程，並實際做出一個整合出席紀錄、請假流程與政策判斷的出缺席管理系統。
出缺席需跨工具手動整理與對應學生資料，難以有效查看分組（group）層級的出席狀況
出缺席需跨工具手動整理與對應學生資料，難以有效查看分組（group）層級的出席狀況
ELMS 僅支援基本出缺席狀態（出席、缺席、遲到），缺乏請假（excused absence）與分組層級的出席追蹤
ELMS 僅支援基本出缺席狀態（出席、缺席、遲到），缺乏請假（excused absence）與分組層級的出席追蹤
1. 專案背景
在 University of Maryland 擔任課程助教 (Teaching Assistant, 簡稱 TA) 的過程中，我需要管理 150+ 學生的出缺席、處理請假申請（Email），並隨時掌握學生的出席狀況。但實際上，這些工作分散在不同工具之中，例如 ELMS（美國常見的課程系統，像是台灣的 Moodle）、Google 表單與試算表、Email，需要大量手動整理與來回切換。
這個問題其實一直存在，但過去因為技術能力限制，我並沒有真的把它做成一個產品，而是妥協於現有工具帶來的不方便性。直到最近開始接觸 Claude Code 與 Figma MCP，我發現這個新的技術，可以讓我不再只停留在設計構想，而是直接把想法做成一個可運作的系統。
因此，我選擇以這個熟悉的痛點為出發點，嘗試用 AI 建立一個從「想法 → prototype → 產品」的設計開發流程，並實際做出一個整合出席紀錄、請假流程與政策判斷的出缺席管理系統。
出缺席需跨工具手動整理與對應學生資料，難以有效查看分組（group）層級的出席狀況
ELMS 僅支援基本出缺席狀態（出席、缺席、遲到），缺乏請假（excused absence）與分組層級的出席追蹤
AI 如何改變我的設計流程
AI 如何改變我的設計流程
AI 如何改變我的設計流程
01 從「設計交付」到「設計與開發同步進行」
01 從「設計交付」到「設計與開發同步進行」
01 從「設計交付」到「設計與開發同步進行」
過去，我的設計產出停留在 Figma prototype。即使使用 ChatGPT，AI 也只參與在討論與發想，無法真正理解或操作設計稿，溝通仍需透過截圖與文字轉譯，整體流程是單向且分離的。
過去，我的設計產出停留在 Figma prototype。即使使用 ChatGPT，AI 也只參與在討論與發想，無法真正理解或操作設計稿，溝通仍需透過截圖與文字轉譯，整體流程是單向且分離的。
過去，我的設計產出停留在 Figma prototype。即使使用 ChatGPT，AI 也只參與在討論與發想，無法真正理解或操作設計稿，溝通仍需透過截圖與文字轉譯，整體流程是單向且分離的。
這次專案中，透過 Claude Code 與 Figma MCP，我的 workflow 變成一個設計與開發同步進行的循環。我可以從想法直接生成可運作的介面，並在 Figma 中調整設計，再即時回傳更新產品。設計與實作之間不再需要交付，而是可以來回調整、持續同步。這也讓最終產出從 prototype，轉變為一個真正可部署、可運作的產品。
這次專案中，透過 Claude Code 與 Figma MCP，我的 workflow 變成一個設計與開發同步進行的循環。我可以從想法直接生成可運作的介面，並在 Figma 中調整設計，再即時回傳更新產品。設計與實作之間不再需要交付，而是可以來回調整、持續同步。這也讓最終產出從 prototype，轉變為一個真正可部署、可運作的產品。
這次專案中，透過 Claude Code 與 Figma MCP，我的 workflow 變成一個設計與開發同步進行的循環。我可以從想法直接生成可運作的介面，並在 Figma 中調整設計，再即時回傳更新產品。設計與實作之間不再需要交付，而是可以來回調整、持續同步。這也讓最終產出從 prototype，轉變為一個真正可部署、可運作的產品。
02 Design ↔ Code 雙向迭代 Demo
02 Design ↔ Code 雙向迭代 Demo
02 Design ↔ Code 雙向迭代 Demo
下面影片示範了一次完整的 Design ↔ Code 雙向迭代流程。我先在 Claude Code 中生成介面，透過 Figma MCP 將 UI 匯入 Figma（保留圖層與結構），並在設計稿中進行調整，讓產品依照更新同步修改。
下面影片示範了一次完整的 Design ↔ Code 雙向迭代流程。我先在 Claude Code 中生成介面，透過 Figma MCP 將 UI 匯入 Figma（保留圖層與結構），並在設計稿中進行調整，讓產品依照更新同步修改。
下面影片示範了一次完整的 Design ↔ Code 雙向迭代流程。我先在 Claude Code 中生成介面，透過 Figma MCP 將 UI 匯入 Figma（保留圖層與結構），並在設計稿中進行調整，讓產品依照更新同步修改。
整個過程不再需要傳統的設計交付或轉譯，而是設計與產品之間的即時同步。
整個過程不再需要傳統的設計交付或轉譯，而是設計與產品之間的即時同步。
整個過程不再需要傳統的設計交付或轉譯，而是設計與產品之間的即時同步。
03 當 AI 讓開發變簡單，如何體現身為「設計師」的價值？
03 當 AI 讓開發變簡單，如何體現身為「設計師」的價值？
03 當 AI 讓開發變簡單，如何體現身為「設計師」的價值？
AI 讓把東西做出來變得很容易，但也讓一些問題被放大。當生成變得容易，問題不再是「能不能做出來」，而是「我們在做什麼、怎麼做，以及做出來的東西是否合理」。
AI 讓把東西做出來變得很容易，但也讓一些問題被放大。當生成變得容易，問題不再是「能不能做出來」，而是「我們在做什麼、怎麼做，以及做出來的東西是否合理」。
AI 讓把東西做出來變得很容易，但也讓一些問題被放大。當生成變得容易，問題不再是「能不能做出來」，而是「我們在做什麼、怎麼做，以及做出來的東西是否合理」。
在這個過程中，我發現關鍵不在工具本身，而在於每一個決策：從如何定義問題、如何下 prompt，到如何判斷設計品質。以下三點，是我在這個 workflow 中最明確感受到的差異。
在這個過程中，我發現關鍵不在工具本身，而在於每一個決策：從如何定義問題、如何下 prompt，到如何判斷設計品質。以下三點，是我在這個 workflow 中最明確感受到的差異。
在這個過程中，我發現關鍵不在工具本身，而在於每一個決策：從如何定義問題、如何下 prompt，到如何判斷設計品質。以下三點，是我在這個 workflow 中最明確感受到的差異。
1
1
1
AI 讓開始變容易，但不會幫你定義問題
AI 讓開始變容易，但不會幫你定義問題
AI 讓開始變容易，但不會幫你定義問題
問題
問題
問題
現在很多人會直接開始生成 UI，甚至邊做邊想自己要做什麼，但這其實很容易讓方向越走越偏。AI 讓開始變得很容易，但不會幫你定義問題。
現在很多人會直接開始生成 UI，甚至邊做邊想自己要做什麼，但這其實很容易讓方向越走越偏。AI 讓開始變得很容易，但不會幫你定義問題。
現在很多人會直接開始生成 UI，甚至邊做邊想自己要做什麼，但這其實很容易讓方向越走越偏。AI 讓開始變得很容易，但不會幫你定義問題。
我的做法
我的做法
我的做法
在進入生成之前，先把想法整理清楚。我會寫一個簡單的 PRD，釐清這個功能到底在解決什麼問題、誰會用、有哪些限制。這個步驟沒有因為 AI 而消失，反而變得更關鍵，因為一旦方向錯了，後面只會更快偏掉。
在進入生成之前，先把想法整理清楚。我會寫一個簡單的 PRD，釐清這個功能到底在解決什麼問題、誰會用、有哪些限制。這個步驟沒有因為 AI 而消失，反而變得更關鍵，因為一旦方向錯了，後面只會更快偏掉。
在進入生成之前，先把想法整理清楚。我會寫一個簡單的 PRD，釐清這個功能到底在解決什麼問題、誰會用、有哪些限制。這個步驟沒有因為 AI 而消失，反而變得更關鍵，因為一旦方向錯了，後面只會更快偏掉。
2
2
2
Prompt 是主要輸入，但很少被好好設計
Prompt 是主要輸入，但很少被好好設計
Prompt 是主要輸入，但很少被好好設計
問題
問題
問題
在這類工具中，prompt 幾乎是唯一的輸入，但很多時候它是模糊、一次性的。你可以只說「做一個出缺席管理系統」，也可以把需求、限制、流程都講清楚，兩者的結果會差非常多，也會直接影響後續修改的成本。
在這類工具中，prompt 幾乎是唯一的輸入，但很多時候它是模糊、一次性的。你可以只說「做一個出缺席管理系統」，也可以把需求、限制、流程都講清楚，兩者的結果會差非常多，也會直接影響後續修改的成本。
在這類工具中，prompt 幾乎是唯一的輸入，但很多時候它是模糊、一次性的。你可以只說「做一個出缺席管理系統」，也可以把需求、限制、流程都講清楚，兩者的結果會差非常多，也會直接影響後續修改的成本。
我的做法
我的做法
我的做法
我會把 prompt 當成設計的一部分來處理。特別是遇到像 Claude Code 這種我不熟悉的領域，我會先用 ChatGPT 或其他 text-based AI，先把需求與 prompt 策略整理好，再進入生成。這次專案中，我甚至把 prompt 拆成幾個階段，先讓 AI 產出 user flow，確認方向一致後，再進一步生成 UI，讓整個過程更可控。
我會把 prompt 當成設計的一部分來處理。特別是遇到像 Claude Code 這種我不熟悉的領域，我會先用 ChatGPT 或其他 text-based AI，先把需求與 prompt 策略整理好，再進入生成。這次專案中，我甚至把 prompt 拆成幾個階段，先讓 AI 產出 user flow，確認方向一致後，再進一步生成 UI，讓整個過程更可控。
我會把 prompt 當成設計的一部分來處理。特別是遇到像 Claude Code 這種我不熟悉的領域，我會先用 ChatGPT 或其他 text-based AI，先把需求與 prompt 策略整理好，再進入生成。這次專案中，我甚至把 prompt 拆成幾個階段，先讓 AI 產出 user flow，確認方向一致後，再進一步生成 UI，讓整個過程更可控。
3
3
3
AI 可以生成畫面，但不會判斷設計好不好
AI 可以生成畫面，但不會判斷設計好不好
AI 可以生成畫面，但不會判斷設計好不好
問題
問題
問題
AI 可以很快產出一個「看起來完整」的介面，但這不代表它是好的設計。對沒有設計背景的人來說，這樣的結果可能已經足夠，但實際上還有很多可以優化的地方。
AI 可以很快產出一個「看起來完整」的介面，但這不代表它是好的設計。對沒有設計背景的人來說，這樣的結果可能已經足夠，但實際上還有很多可以優化的地方。
AI 可以很快產出一個「看起來完整」的介面，但這不代表它是好的設計。對沒有設計背景的人來說，這樣的結果可能已經足夠，但實際上還有很多可以優化的地方。
我的做法
我的做法
我的做法
我在這個階段做的，是用我原本的 UX、資訊架構、使用者心智模型，以及視覺設計的經驗，去判斷哪些地方需要調整。AI 產出的東西對我來說更像是一個可以快速修改的起點，而不是最終答案。
我在這個階段做的，是用我原本的 UX、資訊架構、使用者心智模型，以及視覺設計的經驗，去判斷哪些地方需要調整。AI 產出的東西對我來說更像是一個可以快速修改的起點，而不是最終答案。
我在這個階段做的，是用我原本的 UX、資訊架構、使用者心智模型，以及視覺設計的經驗，去判斷哪些地方需要調整。AI 產出的東西對我來說更像是一個可以快速修改的起點，而不是最終答案。
3. 專案細節
3. 專案細節
3. 專案細節
01 產品概覽
01 產品概覽
01 產品概覽
Attendly 是一個整合出席紀錄、請假流程與課程政策的出缺席管理系統，讓老師及 TA 可以在同一個介面中完成原本分散在多個工具中的工作。
Attendly 是一個整合出席紀錄、請假流程與課程政策的出缺席管理系統，讓老師及 TA 可以在同一個介面中完成原本分散在多個工具中的工作。
Attendly 是一個整合出席紀錄、請假流程與課程政策的出缺席管理系統，讓老師及 TA 可以在同一個介面中完成原本分散在多個工具中的工作。
系統支援即時出席追蹤、請假申請與審核，以及根據不同課程政策自動標記風險學生，讓助教能更快速掌握整體狀況並做出決策。
系統支援即時出席追蹤、請假申請與審核，以及根據不同課程政策自動標記風險學生，讓助教能更快速掌握整體狀況並做出決策。
系統支援即時出席追蹤、請假申請與審核，以及根據不同課程政策自動標記風險學生，讓助教能更快速掌握整體狀況並做出決策。
02 設計對象
02 設計對象
02 設計對象
Attendly 主要服務兩類使用者：老師 / TA（Staff）與學生（Student）。不同角色在課程中的責任與使用方式有明確差異。
Attendly 主要服務兩類使用者：老師 / TA（Staff）與學生（Student）。不同角色在課程中的責任與使用方式有明確差異。
Attendly 主要服務兩類使用者：老師 / TA（Staff）與學生（Student）。不同角色在課程中的責任與使用方式有明確差異。
03 核心流程與雙角色體驗
03 核心流程與雙角色體驗
03 核心流程與雙角色體驗
Attendly 主要圍繞在「課程建立、日常互動與出席追蹤」三個階段，並同時支援助教與學生兩種角色的使用情境。
Attendly 主要圍繞在「課程建立、日常互動與出席追蹤」三個階段，並同時支援助教與學生兩種角色的使用情境。
Attendly 主要圍繞在「課程建立、日常互動與出席追蹤」三個階段，並同時支援助教與學生兩種角色的使用情境。
下圖整理了整體功能與流程架構，幫助快速理解系統如何運作。
下圖整理了整體功能與流程架構，幫助快速理解系統如何運作。
下圖整理了整體功能與流程架構，幫助快速理解系統如何運作。
基於上述流程架構，以下將逐一展示 Attendly 的核心使用情境，說明系統如何支援老師與學生在不同階段的操作與決策。
基於上述流程架構，以下將逐一展示 Attendly 的核心使用情境，說明系統如何支援老師與學生在不同階段的操作與決策。
基於上述流程架構，以下將逐一展示 Attendly 的核心使用情境，說明系統如何支援老師與學生在不同階段的操作與決策。
#1 課程建立 (Setup)
#1 課程建立 (Setup)
Use Case 1
Use Case 1
課程建立與加入
課程建立與加入
課程建立與加入
老師 / TA 建立課程並產生Course Code，學生可透過輸入 Code 加入對應課程與分組。
老師 / TA 建立課程並產生Course Code，學生可透過輸入 Code 加入對應課程與分組。
老師 / TA 建立課程並產生Course Code，學生可透過輸入 Code 加入對應課程與分組。
老師 / TA
老師 / TA
學生
學生
學生
學生
老師 / TA
老師 / TA
#2 日常互動 (Ongoing)
#2 日常互動 (Ongoing)
Use Case 2
Use Case 2
請假申請與審核
請假申請與審核
請假申請與審核
學生可針對過去或未來的課程提交請假申請，並填寫原因。老師 / TA 可在系統中統一審核，並決定是否為 excused absence。
學生可針對過去或未來的課程提交請假申請，並填寫原因。老師 / TA 可在系統中統一審核，並決定是否為 excused absence。
學生可針對過去或未來的課程提交請假申請，並填寫原因。老師 / TA 可在系統中統一審核，並決定是否為 excused absence。
#2 日常互動 (Ongoing)
#2 日常互動 (Ongoing)
Use Case 3
Use Case 3
點名與出席記錄
點名與出席記錄
點名與出席記錄
老師 / TA 可在上課時啟動 roll call，系統生成限時 code。學生輸入 code 完成簽到，出席紀錄即時更新。
老師 / TA 可在上課時啟動 roll call，系統生成限時 code。學生輸入 code 完成簽到，出席紀錄即時更新。
老師 / TA 可在上課時啟動 roll call，系統生成限時 code。學生輸入 code 完成簽到，出席紀錄即時更新。
老師 / TA
老師 / TA
學生
學生
老師 / TA
老師 / TA
學生
學生
#3 出席追蹤 (Monitoring)
#3 出席追蹤 (Monitoring)
Use Case 4
Use Case 4
出席狀況總覽
出席狀況總覽
出席狀況總覽
老師 / TA 可透過多種視角（All students / By group、Week / All）查看整體出席狀況；學生則可隨時查看個人出席率與缺席紀錄。
老師 / TA 可透過多種視角（All students / By group、Week / All）查看整體出席狀況；學生則可隨時查看個人出席率與缺席紀錄。
老師 / TA 可透過多種視角（All students / By group、Week / All）查看整體出席狀況；學生則可隨時查看個人出席率與缺席紀錄。
#3 出席追蹤 (Monitoring)
#3 出席追蹤 (Monitoring)
Use Case 5
Use Case 5
風險提醒（Risk Flag）
風險提醒（Risk Flag）
風險提醒（Risk Flag）
系統會根據課程設定的 attendance policy，自動標記超過缺席上限的學生，並提供視覺化提示，協助老師、助教與學生及早發現風險。
系統會根據課程設定的 attendance policy，自動標記超過缺席上限的學生，並提供視覺化提示，協助老師、助教與學生及早發現風險。
系統會根據課程設定的 attendance policy，自動標記超過缺席上限的學生，並提供視覺化提示，協助老師、助教與學生及早發現風險。
老師 / TA
老師 / TA
學生
學生
成長與反思
成長與反思
成長與反思
1
1
1
保持開放心態，但不是盲目跟隨工具
保持開放心態，但不是盲目跟隨工具
保持開放心態，但不是盲目跟隨工具
當越來越多 AI 工具出現時，我其實有點抗拒，也會擔心自己是不是會被取代。但在實際做完這個專案後，我反而更確定，與其排斥，不如保持開放，去理解這些工具可以怎麼被使用。對我來說，關鍵不在於「用不用 AI」，而是「為什麼用」。我更傾向在 有明確目標或問題的情況下使用它，而不是為了嘗試工具而做東西。這也讓整個過程更有方向，而不是只是產出看起來厲害的結果。
當越來越多 AI 工具出現時，我其實有點抗拒，也會擔心自己是不是會被取代。但在實際做完這個專案後，我反而更確定，與其排斥，不如保持開放，去理解這些工具可以怎麼被使用。對我來說，關鍵不在於「用不用 AI」，而是「為什麼用」。我更傾向在 有明確目標或問題的情況下使用它，而不是為了嘗試工具而做東西。這也讓整個過程更有方向，而不是只是產出看起來厲害的結果。
當越來越多 AI 工具出現時，我其實有點抗拒，也會擔心自己是不是會被取代。但在實際做完這個專案後，我反而更確定，與其排斥，不如保持開放，去理解這些工具可以怎麼被使用。對我來說，關鍵不在於「用不用 AI」，而是「為什麼用」。我更傾向在 有明確目標或問題的情況下使用它，而不是為了嘗試工具而做東西。這也讓整個過程更有方向，而不是只是產出看起來厲害的結果。
2
2
2
我更確定自己的設計價值來自於判斷，而不是產出
我更確定自己的設計價值來自於判斷，而不是產出
我更確定自己的設計價值來自於判斷，而不是產出
這次經驗讓我更清楚看到 AI 可以幫助我快速產出，但無法幫我判斷什麼是好的設計。很多時候，生成的介面看起來已經「可以用了」，但在資訊架構、流程合理性或使用者理解上，其實還有很多可以優化的地方。而我在這個過程中做得最多的，是 基於過去累積的 UX、IA 與心智模型經驗，去判斷哪些地方需要調整，以及怎麼讓整體體驗更合理。這也讓我更確定，設計師的價值不只是「做出來」，而是「決定什麼是對的」。
這次經驗讓我更清楚看到 AI 可以幫助我快速產出，但無法幫我判斷什麼是好的設計。很多時候，生成的介面看起來已經「可以用了」，但在資訊架構、流程合理性或使用者理解上，其實還有很多可以優化的地方。而我在這個過程中做得最多的，是 基於過去累積的 UX、IA 與心智模型經驗，去判斷哪些地方需要調整，以及怎麼讓整體體驗更合理。這也讓我更確定，設計師的價值不只是「做出來」，而是「決定什麼是對的」。
這次經驗讓我更清楚看到 AI 可以幫助我快速產出，但無法幫我判斷什麼是好的設計。很多時候，生成的介面看起來已經「可以用了」，但在資訊架構、流程合理性或使用者理解上，其實還有很多可以優化的地方。而我在這個過程中做得最多的，是 基於過去累積的 UX、IA 與心智模型經驗，去判斷哪些地方需要調整，以及怎麼讓整體體驗更合理。這也讓我更確定，設計師的價值不只是「做出來」，而是「決定什麼是對的」。
3
3
3
好奇心與問題意識，仍然是設計的起點
好奇心與問題意識，仍然是設計的起點
好奇心與問題意識，仍然是設計的起點
這個專案其實不是從技術出發，而是從一個我長期感到困擾的問題開始。也讓我再次意識到，好的產品不一定來自複雜的技術，而是來自對需求與痛點的敏感度。我發現自己很喜歡在有明確問題的情境下動手做東西，透過實作去驗證想法，而不是為了「做一個專案」而做。這樣的方式，也讓我在面對新的工具或技術時，更容易找到切入點與方向。
這個專案其實不是從技術出發，而是從一個我長期感到困擾的問題開始。也讓我再次意識到，好的產品不一定來自複雜的技術，而是來自對需求與痛點的敏感度。我發現自己很喜歡在有明確問題的情境下動手做東西，透過實作去驗證想法，而不是為了「做一個專案」而做。這樣的方式，也讓我在面對新的工具或技術時，更容易找到切入點與方向。
這個專案其實不是從技術出發，而是從一個我長期感到困擾的問題開始。也讓我再次意識到，好的產品不一定來自複雜的技術，而是來自對需求與痛點的敏感度。我發現自己很喜歡在有明確問題的情境下動手做東西，透過實作去驗證想法，而不是為了「做一個專案」而做。這樣的方式，也讓我在面對新的工具或技術時，更容易找到切入點與方向。
其他專案
其他專案
其他專案
其他專案