「開發效能提升實戰」：Claude Design 搭配自建 Skill，團隊達到提升四倍產出

TL;DR：加速的是交付價值，不是程式碼

在「開發效能提升實戰」分享中，敦謙國際經理／Scrum Master 吳品毅（阿咪 A-mi）與資深 UI/UX 設計師林杰伶（Jennifer Lin），以 Hexa 的飯店官網版型開發為例，說明如何結合 Claude Design 與自建 Skill，把原本需要設計師與前端工程師投入兩個人月的工作，轉為一位設計師約兩週完成可交付客戶的版型。關鍵不是讓 AI 多寫幾行程式，而是先由人定義價值、規格與驗收，再讓 AI 承接重複工作。

• 先挑對題目：規則已知、流程重複，而且能直接改善產品交付的工作，才是導入優先對象。
• 用設計與前端轉換兩套 Skill 串起流程，把規格、Coding Style、設計理由與檢查清單變成可重用的協作依據。
• 四倍產出是團隊對實際交付流程的成效描述，不是幾分鐘生成畫面的展示；靈感、設計判斷與驗收仍需要人。
• 釋放人力不是裁減人員，而是讓工程師轉向系統優化與數據分析，讓設計師更專注於設計。

從旅宿需求出發，重新定義有價值的產出

敦謙國際的阿咪是旗下產品 Hexa 的經理，jennifer 則負責 UI/UX 設計。兩人以飯店官網版型的製作流程，說明團隊如何思考 AI 導入：起點不是工具能生成多少東西，而是旅宿客戶需要什麼，以及團隊如何把需求變成可交付的產品。

談到「幾倍工程師」或「幾倍設計師」，最容易被拿來展示的是生成速度與程式碼數量。但寫出幾千行 code，不代表產品就多了相應的價值。阿咪把問題拉回 ROI：投入多少 Token、花了多少錢，最後究竟換回什麼？Token 是投入，程式碼是過程中的產物，是否形成客戶能使用的成果，才是另一個需要判斷的問題。

這個問題也不能只從主管的角度看。對原本就忙碌、經常加班的員工而言，AI 可能被理解成「公司現在要求我做更多」，甚至是「公司想用 AI 把我換掉」。如果導入只剩下提高產出數量的要求，員工便可能把所有事情交給 Agent，讓生成的東西變多，卻不再理解其中的修改與邏輯。

阿咪用功能修復的情境說明風險：某個地方壞了，才發現是 AI 改過，但人不知道修改原因；於是把程式改回自己熟悉的邏輯，舊功能恢復了，AI 新增的功能卻跟著壞掉。再請 AI 修復，即使它回報完成，實際操作仍可能出錯。問題不只是 AI 有沒有做事，而是人是否理解變更，以及是否有人先定義什麼叫做「好」。

「產出是一個可交付的價值」
— 阿咪

對做旅宿產品的團隊來說，這個定義有很具體的對象：飯店需要導流，也需要數據。阿咪以收集新聞、製作會議簡報等 AI 功能為例，指出即使這些東西成功生成，若不是客戶需要的，也不能當成這項產品的有效成果。這不是否定這些功能在其他情境的用途，而是要求 AI 投入必須對準同仁、團隊與產品真正需要的幫助。

因此，團隊採用的分工不是「人下指令後就退出」，而是讓人掌握目標與決策，把 AI 放在產出結果的位置。就像先決定要蓋什麼，再使用工具施工；工具能加快作業，卻不能替人決定成果是否符合需求。

• 人定義目標：先說清楚要做什麼，以及什麼結果才算有價值。
• AI 產出結果：在已定義的方向下執行工作，而不是以生成數量取代目標。
• 人做後續決策：理解結果、判斷是否符合需求，再決定接下來要做什麼。
• 選擇適合的題目：優先找規則已知、流程重複，而且成果確實有價值的工作。

飯店官網版型正是團隊選中的題目。Hexa 提供台灣飯店使用的官網，能提供多少套版型，是產品的重要供給；團隊也將年度 KPI 設為 20 套。原本的流程由一位設計師設計新的官網版型，再交給一位前端工程師套程式，最後提供飯店業者使用。

阿咪說明，團隊並非只做版型，還有其他工作，因此過去會留給設計師一個月完成設計，再交由前端處理。他以「兩個人月、八週」描述一套版型的投入，也提到以每月一套的方式提供產出。這些說法需要分開理解：人月描述人力投入，八週描述工作所需時間，每月一套則是供給節奏，不能把人力投入直接當成交付頻率。

這項工作適合導入 AI，並不是因為每套版型都應該長得一樣，而是製作每套版型時，都會再次經歷效果思考、風格設計與套程式的流程。重複的是工作路徑，不是視覺結果。團隊要加速的是這條可反覆執行的製作流程，同時保留不同版型需要的設計差異，讓投入真正轉成飯店可使用的選擇。

「產出是一個可交付的價值」
— 阿咪

為何選 Claude Design：讓設計直接接近可用程式

對 jennifer 而言，選擇設計工具的關鍵，不只是能不能畫出介面，而是設計完成後，產物距離團隊真正可用的程式還有多遠。她過去使用的介面與動態設計軟體，產出的原始檔仍須交給 RD 切版，轉成 HTML、CSS 跟 JS。設計師先完成畫面，工程師再用程式重建一次，讓她感覺兩個角色正在製作兩套相同的東西。

「就是能不能我設計完之後其實就切版完了」
— jennifer

她在社群上發現 Claude Design 後，看中的正是設計與切版可以一起完成。不過，能匯出程式碼並不是唯一的選擇標準；更重要的是，能否在產出時就指定團隊的規則，減少後續修正。

• Figma：jennifer 提到，近期的 AI 功能也能將設計匯出為 HTML、CSS 跟 JS，但在她的使用經驗中，難以加入她需要的 Class 命名與 Coding Style 限制。
• Framer：她提到，Framer 同樣能透過 AI 對話產出這類原始檔，但也遇到無法充分指定團隊規範的問題，仍須交由 RD 修正。
• Claude Design：依她的實際使用經驗，可以對 Class 命名與團隊 Coding Style 提出要求，因此更符合她希望讓設計直接接近可用程式的工作需求。

這個比較反映的是 jennifer 的使用經驗與團隊需求，而不是對所有工具能力的普遍定論。她要解決的問題，是匯出的檔案即使能呈現畫面，若不符合團隊寫法，仍然需要工程師整理；選擇 Claude Design，是希望把這些限制提前放進產出過程。

Claude Design 的介面以對話框和設計預覽為核心：左側輸入需求，右側查看結果。jennifer 特別喜歡 comment 功能，因為它可以直接指向預覽畫面上的某個 DOM，例如一行文字，再針對該元素提出修改。這就像直接在設計稿上指著要改的位置，不必只靠文字描述「是哪一行」。

• 用 comment 選取目標元素後，可以要求替換文字，或說明不喜歡目前的效果、希望改成什麼；按下 Enter 後，由 AI 生成修改結果。
• 若不想請 AI 修改，也可以使用 Edit 選取 DOM，直接手動調整文字、字體、顏色與其他 CSS 設定。
• jennifer 建議 Edit 主要用來改文字。她發現透過這個功能調整樣式時，CSS 會直接寫入行內樣式，增加後續維護負擔，因此自己避免用它大量修改樣式。

除了程式格式與操作方式，設計品質也是她選擇工具的理由。jennifer 曾分別用 Claude Design 與 Claude Code 做設計，主觀上認為 Claude Design 的設計能力較好，Claude Code 的成品則沒有那麼理想。她推測 Claude Design 可能接受過不同的訓練或使用不同的資料，但這是她對使用結果的解釋，並非已確認的工具訓練資訊。

兩者的工作情境也有所不同。依 jennifer 的描述，Claude Design 的資料與檔案綁定線上帳號，換裝置後只要登入同一個帳號，就能繼續工作；她使用 Claude Code 時，工作則綁在本地端。她與工程師討論後推測，這可能與兩套工具面向的使用情境有關：設計師需要在不同地方工作，而工程師的開發環境即使努力維持一致，不同電腦之間仍可能有些微差異。這是講者對產品定位的理解，而非工具官方定位的定論。

前端轉換 Skill：從設計檔走到 Vue 專案

原本的版型製作流程，是由設計師用 Figma 完成設計，整理相關說明文件，再交給前端工程師切版、串接資料，最後進入測試。jennifer 的第一階段改造，並不是一次把所有工作交給 AI，而是先用 Claude Design 分擔切版，再為前端專案建立轉換 Skill，處理設計原始檔的搬遷與資料串接，完成後仍接上測試流程。

選擇從搬遷與串接下手，是因為這部分的變化相對少：後台已有的資料欄位固定，工作內容比設計風格更穩定。換句話說，Claude Design 負責產出畫面，轉換 Skill 則像一座橋，把畫面接進既有專案與資料結構，而不是重新決定網站應該長什麼樣子。

• 設計加切版：原本需要 30 天，導入 Claude Design 後縮為 15 天。
• 資料串接：原本需要 10 天，透過轉換 Skill 縮為 5 天。
• 這兩組數字分別描述階段工時，兩者都縮短一半；並非包含所有測試與交付工作的完整週期。

建立 Skill 時，jennifer 借助團隊工程師提供的「設計skill的skill」，先與 AI 討論目標：讀取設計原始檔，辨認重複出現的結構，例如 Header、Footer，合理拆分成元件，再導入前端的 Vue 專案並串接資料。這讓任務不再只是籠統的「幫我轉成程式」，而是有明確步驟與預期成果的轉換工作。

規格也不只靠文字描述。她提供一份由 Claude Design 產出的原始檔，並讓 Claude Code 直接研讀專案中既有的版型範例，理解希望達到的成果，再規劃 Skill 的架構。原始檔說明要搬遷的內容，既有版型則提供落地後的參照，兩者共同縮小 AI 自行猜測的空間。

此外，她另訂了 Skill 的優化規範。原因來自先前的實驗：沒有規範時，後續新增的內容容易變得雜亂。由於 Skill 還會持續迭代，除了讓它當下能完成任務，也必須約束後續如何修改，才能維持較乾淨、有效率的工作方式。完成初版後，她先請 AI 進行模擬測試，再實際用這套流程跑了兩套版型，從反覆出現的錯誤中持續修正。

實跑後最需要加強的約束，是忠實還原設計。這個 Skill 的任務，是盡可能把設計檔原樣搬到前端專案，而不是替設計做刪減。然而，AI 曾反覆刪掉 jennifer 想保留的動態效果，因此她必須明確重申：不能因為轉換方便，就擅自改變設計。

「所以很重要的一定是它要忠實還原設計」
— jennifer

為了讓「忠實還原」不只停留在口頭要求，她把反覆出錯的地方寫進更詳細的檢查清單。實際操作時，先提供整包原始檔，請 AI 讀取設計並列出要完成的項目；執行後，再回頭依照同一份清單檢查，不符合的地方必須回報。這就像搬運前先點清物品，搬完後再逐項核對，避免畫面看似完成，重要細節卻在轉換途中遺失。

• 實作前：由 AI 看過設計稿，列出實際需要完成的清單，作為執行依據。
• 完成後：依原清單重新檢查，將不符合設計的項目回報給 jennifer。
• 人工判定：逐一檢視差異；屬於設計靈魂的部分，必須恢復到與設計稿一致，影響較小的部分則由人決定是否可以省略。

這套檢查機制把 AI 的角色放在執行、比對與回報，而不是自行裁決哪些設計值得留下。是否接受差異，仍由理解設計意圖的人決定；jennifer 也因此需要一一查看回報，而非把生成完成視為轉換完成。

設計 Skill 與交接文件：讓兩段工作流接得起來

跑完兩套版型後，jennifer 發現，前端轉換雖然已有 Skill 協助，設計端卻仍在重複消耗時間。當時使用 Claude Design 尚未搭配 Skill，每次開始設計，都得重新貼上規格；已經說明過的問題，也可能再次被詢問。這些反覆出現的摩擦，成為第二次導入的起點：把每次都要交代的要求，整理成 Claude Design 使用的設計 Skill。

「就是我都花那麼多時間在上面，怎麼樣可以更快更好」
— jennifer

這個設計 Skill 不只是收納規格，也把後續前端專案的需求提前帶入設計階段。目標是讓 Claude Design 最後交付的檔案，從源頭就接近團隊能接手使用的格式，而不是等到轉換時，才重新調整命名與寫法。jennifer 納入的要求包括：

• 反覆貼給 Claude Design 的規格，以及她對設計的要求與相關規範。
• 團隊的 Coding Style，讓產出的程式寫法符合前端專案需求。
• Class 命名規則，讓設計產出與後續專案使用的方式一致。
• 供後續銜接使用的設計檔、目標檔案、規格書與必要資料。

不過，格式一致還不足以確保設計被完整保留。jennifer 在轉入前端專案時，曾遇到 AI 刪減設計的情況；她判斷，可能是負責轉換的 AI 不知道那些設計為什麼重要。因此，她在設計端加入交接文件，記錄設計歷程，以及每個選擇背後的原因，讓前端轉換 Skill 讀取後，能理解哪些內容不應任意刪除。

這份文件就像設計與實作之間的交接筆記：設計檔呈現「做成什麼樣子」，交接文件則補上「為什麼要這樣做」。兩個 Skill 處理的是相連的工作，若只傳遞檔案而沒有傳遞設計意圖，後續轉換就可能把重要細節當成可省略的部分。把原因一起交出去，是為了減少這類誤刪，而不只是增加一份文件。

資料串接的意圖也在設計階段先寫清楚。jennifer 要求加入 TODO 註解，標明各個 DOM 應該串接什麼資料，讓後續 Skill 能直接辨認對應關係。搭配目標檔案、規格書與必要資料，交接內容便同時涵蓋設計理由與實作線索，避免到了前端轉換時才重新猜測畫面上的元素應該接什麼。

依 jennifer 的分享，第二次導入後，相關工作時間又進一步縮短；加入交接文件，也讓後續銜接更有效率。她描述當時整體約 10 天可以產出一套版型。這個數字反映的是設計 Skill 與前端轉換 Skill 配合後的整體成果，不宜再把個別階段的口述數字硬拆成完整工時表。改善的核心，是將重複交代的規則、設計選擇的原因與資料串接需求，一起納入可持續使用的工作流程。

骨架不變、皮膚可變：把風格翻成可執行規則

要讓 AI 做出不同風格的飯店版型，先得說清楚什麼可以變、什麼必須保持不變。jennifer 用「骨架」與「皮膚」區分這兩件事：骨架是既定的資料欄位與數量，皮膚則是顏色、字體等視覺風格。換一種外觀，不代表能任意增加內容；如果沒有對應資料，就不能憑空多出一個欄位或項目。

「那這個東西我後來就稱之為骨架，然後風格就是皮膚，所以它能動的都只有皮膚。」
— jennifer

這個類比也成為設計 Skill 的規則基礎。不過，把「風格」轉成 AI 能執行的要求，並不是一句指令就能完成。jennifer 認為設計很主觀，因此花了大量時間與 AI 討論，逐步拆解哪些屬於結構、哪些屬於風格，以及各自的修改邊界。目的不是把每套版型做得一樣，而是在固定的資料條件下，清楚界定視覺設計可以發揮的空間。

• 不能改的骨架：資料欄位與數量固定，不得新增沒有資料支援的內容。
• 可以改的皮膚：顏色、字體等風格元素，但要進一步定義具體的設計選擇，而不只給一個籠統的風格名稱。
• 需要說明的細節：圓角、空間與動畫速度等設定，都應提出設計原因，讓選擇有依據。

依 jennifer 的使用觀察，如果沒有特別引導，AI 做設計時容易偏向保守，選擇最不容易出錯、放進各種版型都通用的做法。這種結果或許能符合「不要太醜就好」的期待，卻不符合她對飯店版型的要求：版型需要有自己的特色，不能只停在不難看的程度。因此，她不希望 AI 立刻交出一個安全但普通的畫面，而是要求它先思考為什麼要這樣設計。

具體做法是追問每個細節的理由：為什麼採用這個圓角？空間為什麼這樣安排？動畫為什麼選擇這個速度？把這些選擇與原因定義下來後，再整理成一張風格表。如此一來，風格就不只是抽象的感覺，而是一組能引導各頁設計的明確設定。

為了讓 AI 理解想要的特色，jennifer 會提供一包版型參考畫面，並替其中每張圖片取有意義的檔名，直接寫出她認為這張圖最重要的特徵。參考圖提供視覺線索，檔名則補上設計師的判斷，讓 AI 知道應該注意什麼，再從中擷取特徵、整理出它對版型風格的理解，據此進行各頁設計。

在真正生成頁面之前，她還加入一道規劃步驟：要求 Claude Design 先提出頁面的設計計畫。這來自她認為 Claude Design 做設計相當耗費 Token 的使用經驗。先把頁面要如何設計說清楚，再開始動工，可以減少尚未釐清方向就直接生成所造成的 Token 浪費。

語系檢查與前置準備：從小抱怨找下一個優化點

語系檢查的優化，起點是一項反覆出現的小麻煩。專案因成本與其他考量，採用 Google翻譯產生譯文，再放入頁面。但依 jennifer 的使用經驗，翻譯有時會出現瑕疵：文字放到實際情境裡，未必表達得恰當。她原本會把文字貼到 ChatGPT，詢問「這個字在這個情境下這樣翻對不對」，一次次確認下來，便成了令人疲累的重複工作。

因此，團隊建立了翻譯 Skill，把原本反覆貼文字、詢問與修正的操作，改為依實際頁面檢查語意。重點不只是產生另一份譯文，而是判斷既有翻譯放在這個位置是否合理，再進行修正與優化。就像校對不只看單一詞彙，也要讀懂它所在的句子與使用情境，頁面本身成了判斷翻譯是否合適的依據。

• 檢查情境：依照實際頁面，查看翻譯在當下的使用情境是否合理。
• 修正內容：針對不合理的翻譯進行修改與優化。
• 交代變更：回報原本錯在哪裡，以及修改後的內容，讓 jennifer 看得懂改了什麼，而不只是收到一份被替換過的文字。

不過，能加速重複操作，不代表所有設計工作都能省略。jennifer 特別指出，靈感蒐集、素材蒐集與風格確認，仍是設計師無法避開的前置作業，也必須由人決定。生成速度再快，想要呈現什麼風格、選用哪些素材，仍需要先形成清楚的方向。

她的做法是蒐集大量符合目標風格的圖片，再整理並命名，讓 AI 理解自己想要的方向。這些人工準備並不是生成流程之外的瑣事，而是把設計意圖傳達給 AI 的必要工作：先由人挑選、整理與確認，再讓工具據此執行，不能因為後面的產出變快，就跳過前面的判斷。

翻譯 Skill 的形成，也提供了尋找優化題目的具體線索：留意日常工作中那些不大、卻一直重複發生的抱怨。反覆把文字貼到 ChatGPT 確認情境，就是從小麻煩轉成改善機會的例子。與其只尋找大規模的自動化題目，也可以先觀察哪些操作經常令人厭煩，再判斷是否能整理成可重複執行的流程。

「要持續觀察那些微小的小抱怨」
— jennifer

四倍產出的意義：縮短交付並釋放專業人力

團隊所說的「四倍產出」，衡量的是能交付給客戶的版型，而不是 AI 生成了多少程式碼。阿咪以導入前後的投入描述這個變化：過去產出一套版型需要兩個人月；導入新的工作流後，一位設計師約花兩週，就能把一套版型提供給客戶。這組對照同時反映人力投入的下降與交付時間的縮短，但兩個人月是人力投入單位，不宜直接當成兩個月的交付週期。

這也解釋了為什麼團隊沒有用「幾分鐘生成一個版型」來描述成效。快速生成畫面，和把產品真正做到上線，是兩件不同的事。阿咪指出，團隊仍有其他工作要處理，分享中的時間指的是實際產品交付，而不是工具展示時的一次生成。當可交付的版型增加，客戶便有更多產品可以選擇，效率提升才真正轉化為產品供給。

「所以我們做的事情是提高產出，然後做人力的釋放。」
— 阿咪

人力釋放並不等於裁員。原本前端工程師必須反覆替版型套程式，導入工作流後，這類重複工作不再持續占用同樣的人力。阿咪明確說明，下一步不是把工程師砍掉，而是讓工程師轉向系統優化、數據分析，以及更有意義、不必反覆重做的工作。前端人員也在過程中學會如何把重複工作轉成 skill，改變的不只是任務分配，也包括處理工作的能力。

• 對前端工程師而言：減少重複套程式，把時間轉向系統優化與數據分析，並學習將重複性工作整理成 skill。
• 對設計師而言：減少等待工程排程與配合他人時程的依賴，提高對設計成果及上線時程的掌握度。
• 對客戶而言：取得更多可交付版型的選擇，效率改善落在實際可使用的產品上。

設計師得到的另一項重要改變，是設計與實作之間的溝通負擔降低。過去，設計師需要配合工程師的檔期，也可能為了每一個 pixel、每一處間距是否忠實還原而反覆溝通，甚至產生衝突。這些細節對設計師有其重要性；當新的工作流讓設計師更直接掌握實作結果，便能減少對他人排程的依賴，也更能掌握自己的設計與交付。阿咪認為，一個人能承擔過去兩個人的工作量，而且完成得更快，代表個人能力與價值也隨之提升。

節省下來的時間，仍然需要人的專業判斷。阿咪不希望導入 AI 被理解為「按下去讓它跑，自己就去喝咖啡」，而是讓同仁把時間留給下一步與價值創造。對設計師來說，這意味著可以更專注地思考要做什麼版型、為什麼這樣設計，以及下一個設計要往哪裡走。自動化接手反覆執行的部分，人則把心力放回設計理由與產品選擇，而不是退出工作流程。

導入的最後一道關卡：選題、驗收與衡量

AI 導入後，管理者首先要調整的不是程式碼產量目標，而是衡量成果的方式。程式碼增加、工作卡片變多，只代表產生了更多待處理的內容，不代表產品已經獲得更多可用成果。阿咪提醒，團隊真正要提升的是價值產出，不能把生成量直接當成績效。

「如果你是團隊主管,記得提升程式碼的產出沒有意義,重點是你的價值的產出」
— 阿咪

生成速度提高，也可能讓驗收成為新的瓶頸。當工作卡片快速增加，驗收卻來不及完成，成果就會堆在交付前的關卡。這像是生產線前端加速，末端的品質檢查卻沒有跟上：看似做得更多，實際上不一定交付得更多。若為了消化堆積而跳過驗收、直接上線，阿咪指出，後果可能是線上問題增加，團隊再以持續加班補救。

另一個管理責任是選對題目。AI 可以快速產生筆記、線上紀錄，但如果這些內容與產品沒有關係，也無法為公司帶來實質成果，數量再多都不足以證明導入有效。問題不在於筆記或紀錄本身沒有用途，而在於主管是否把團隊的投入指向真正需要解決的產品問題。

• 先定義什麼叫好：把成果應達到的要求說清楚，讓驗收有可依循的判斷依據，而不是以生成完成作為完成工作的標準。
• 先決定選什麼題目：確認工作與產品及公司需要的成果有關，避免大量產出與目標無關的內容。
• 先釐清如何衡量：明確定義交付週期與人力產值的衡量標準，觀察投入如何轉成可交付成果，而非以程式碼增量代替成效。

散場交流也提到一個實際操作限制：對話中有人說明涉及 API 轉傳，並提到內容過多造成連線逾時，之後又表示後來成功了。由於交流未清楚交代操作對象、設定與成功條件，這只能視為現場遇到的一次限制，不能据此認定某個特定工具普遍存在相同問題。

「人定義價值,AI放大效益」
— 阿咪

重點回顧：把重複工作交出去，把判斷留在人手上

• 先定義客戶需要的成果，再決定導入什麼工具；這個案例的交付單位是可供飯店使用的官網版型。
• Skill 的價值不只是自動執行，更是把規格、既有範例、設計意圖與檢查方式整理成可重用的流程。
• 設計交接不能只傳檔案，也要傳遞為什麼這樣設計，才能減少後續轉換時的誤刪與失真。
• 四倍產出必須放回實際交付與人力投入的脈絡理解；生成變快後，驗收能力也必須跟上。
• 真正值得釋放的是反覆套程式與重複溝通的時間，讓人能投入風格判斷、系統優化與下一步的價值創造。

Claude DesignClaude CodeSkillHexaUI/UXROITokenCoding StyleDOMVue交接文件設計還原語系檢查交付週期驗收