使用 skill 在 Al 協作開發是流行一陣子的話題，各位讀者有沒有運用過 skill 呢？
最近我在使用 AI Coding Agent 進行開發時，開始嘗試加入 Skill，讓 AI 能更精準理解我的開發需求與功能設計，避免 AI 自行發想並實作程式碼、但程式碼設計與我的需求越走越偏的情況。
而「讓 AI 能更精準理解開發需求與功能設計」這件事，有沒有必要使用 skill，尤其是 skill 內容較多、會佔用上下文（context）並消耗 token 數量，會是在這篇文章中探討並分享的。這篇文章中，我會先介紹比較的模型設定與 skill，並提供一個實際的開發需求，與讀者分享，AI 在有或沒有使用 skill 的狀況下，處理方式的差異與產出結果，最後總結我的使用心得。那麼，我們就開始囉！
文章目錄
1. 測試設定
a. 所使用的 Skill 介紹
2. 實際案例：將系統通知信內容修改得更為正式
a. 操作說明
b. 方法比較
i. 第一種方法：沒有使用 Skill
ii. 第二種方法：使用 Skill grill-me
3. 結語
一、測試設定
這次測試使用相同等級的模型設定：
- 模型：Sonnet 5
- 強度：High
- 思考模式：開啟
- 未使用 Skill：Claude App，Code 模式
- 使用 Skill：Claude Code CLI
a. 所使用的 Skill 介紹
我所使用的 Skill 為 grill-me，來源於 GitHub 的開源專案（連結：https://github.com/mattpocock/skills）。
grill-me 的用途可以簡單理解成，AI 先針對使用者所給提示詞的內容，也就是需求，持續提出問題，才開始修改程式碼。AI 會先搜尋與需求相關的程式碼，再根據實際找出可能需要確認的細節，藉此縮小使用者與 AI Agent 對這個需求理解上的落差。
實際案例：將系統通知信內容修改得更為正式
a. 操作說明
我正在開發一個具有信件發送功能的系統，其中包含數個自動寄送的報表通知信。原本的通知信相當簡單，只包含報表名稱、幾個統計數字以及報表連結。
原始信件畫面
我透過 AI 來協助我修改通知信的內容，給 AI 的提示詞內容主要是：
這是一封通知信，我想將信件內容變得更為正式，可以使用於正式的產品中。請加入可以將內容變個更為正式的內容。
我的提示詞中的「把信件改正式一點」，其實相當模糊，沒有定義很多重要細節。這是因為我對於「正式的系統通知信」沒有具體且明確的想法，所以無法提供給 AI 更為詳細的說明，需要由 AI 協助我補足。
b. 方法比較
針對「讓 AI 能更精準理解修改通知信的這個需求」，我使用兩種方法比較「使用 skill 與否」的差異。
第一種方法沒有使用 Skill，是直接在提示詞加入「要求 AI 跟我確認不清楚的地方」這個要求，仿照 grill-me 的設計。第二種方法，則是使用 /grill-me 這種 skill 引用指令。因此，這兩種方法的目的，都是要求 AI 先釐清我的需求再給我結果。
第一種方法：沒有使用 Skill
在這個方法中，整體而言，AI 的回應與產出結果是可以符合我的提示詞要求內容，以下是詳細說明。
我的提示詞如下圖，提示詞除了說明我的需求、要求 AI 釐清我的需求，也要求 AI 執行任務的邊界。
第一種方法的提示詞
產出過程
而 AI 的回覆確實依照我的要求，先詢問我要確認的事項：
第一種方法的提示詞
在這個版本中，AI 產出的速度十分快速，產出的結果也有模有樣，但是，產出結果後，AI 還繼續問我需確認的事項，接連幾次來回問答後，AI 才有最終定版。
第一種方法的提示詞回應（一）
第一種方法的提示詞回應（二）
產出結果
AI 最終給出的通知信內容
如果我的目的只是快速做一個 Demo，拿去跟 PM 討論「通知信大概會長成什麼樣子」，沒有使用 skill 的這個做法非常有效率。然而，AI 給出的通知信結果，仍有後續設計上的疑慮，例如「指標的呈現方式」、「是不是所有報表都可以套用」，仍然需要我在實作時逐一確認。
因此我認為，在這個版本中，AI 確實有透過提問達到「讓 AI 能更精準理解開發需求與功能設計」，但是產出的結果比較適合快速產生 Demo，用來和 PM 或其他成員對齊方向。
第二種方法：使用 Skill grill-me
使用 grill-me 後，AI 沒有直接產生修改後的通知信，而是先搜尋專案中的程式碼，藉此得知我有多個通知信、通知信有中英文兩種語言版本等通知信的設計。在補足更多的背景知識後，AI 開始詢問我這個主題的細節，例如以下五個問題：
一、到底要修改幾份信件？
AI 搜尋程式碼後發現，我指定的 RPT-02 通知信並不是唯一的報表通知信。
專案中還有：RPT-03、RPT-04、RPT-06 等 5 種報表通知信。因此 AI 先跟我確認修改範圍修改 5 份內部報表。這樣避免了同一個系統裡只有其中一封信換成新設計，其他信件仍維持舊格式，需要再次跟 AI 說明、定義新的設計的時間與精力。
二、中文改了，那英文呢？
由於 AI 有找到專案中的翻譯檔案，AI 得知這代表目前的通知信有中、英文兩種語言版本，因此要正式化通知信，其實不能只改我在提示詞中給的中文通知信，英文版本也應修改內容。因此，這個問題讓我的需求從「改通知信內容」延伸為「翻譯內容的一致性」。
三、是否包含收件人的名字？
在第二種方法中，AI 同樣提議加入收件人稱謂，但是 AI 給出更詳細的解釋與方案：AI 說明，如果想讓信件更加正式，可以加上收信人稱謂，且加上稱謂可以選擇收信人職稱或姓名。同時，AI 檢查程式後發現，目前程式碼沒有將收件人的姓名傳進通知信，因此向我確認修改目標，並記錄要修改 Python 程式。從這個問題可見，有使用 skill 的 AI 讓提問更精準，而且 AI 問過一次後，就不需要再向我詢問收件人稱謂的格式，一次就將問題解決。
產出結果
AI 最後產出的結果是一套比較完整的通知信設計，例如：
- 根據通知信主題，微調每一種通知信的內容。
- 中文與英文版本內容一致。
- 收件人稱謂有明確規則。
- KPI 使用一致的視覺呈現。
- 提供完整報表連結。
- 使用確認過的系統署名。
- 清楚標示系統自動寄送。
- 同時列出為了支援新版信件，需要新增哪些 context 以及修改哪些程式。
實際比較後，我認為最大的差別是 AI 工作精準度。沒有使用 Skill 時，AI 的工作是「收到需求 → 詢問需求→ 確認需求 （重複直到沒問題）→ 產出結果」；使用 grill-me skill 後，AI 則是「收到需求 → 搜尋相關程式碼 → 發現隱藏需求 → 提出問題 → 使用者做決策 → 產出結果」。即使使用 skill 會需要花多一點時間，但是只需一輪的詢問環節，而且產出較好的結果。
三、結語
從實際的兩個案例來看，針對「讓 AI 能更精準理解開發需求與功能設計」這件事，無論有沒有使用 skill，都能讓 AI 提出問題、釐清我的開發需求。如果需求單純，而且目的是快速定調方案，我不認為每一次都需要使用這類 skill，例如：確認方案規劃的方向正確，不使用 skill，直接請 AI 通常會更快。
而從提升工作流程角度而言，直接使用 grill-me 會讓 AI 的提問比較精準，尤其當需求更為複雜，例如：
- 多個相關檔案
- 既有程式架構
- 多語系
- UI 一致性
- 修改範圍
- 額外開發成本
- 沒有明確說出的產品需求
這類 skill 就會比較實用，因為使用 skill 可以讓 AI 釐清每個細節，而這些細節是在實際開發功能確實會遇到。因此，對我而言，skill 給我最大的收穫是幫我在開始寫程式之前，將需求想得更完整，減少 AI 自行假設需求以及後續反覆修改的時間與精力。
如果讀者碰到較為模糊或複雜的需求，我推薦讀者也可以嘗試使用 skill 協助你思考喔！
