Prompt 是什麼

Prompt 就是你這次要對 AI 講的話。

「幫我寫測試案例」是 prompt，「請依照下列六個步驟排查這次的失敗，每一步都要列出你判斷的依據」也是 prompt。

差別只在寫得細不細。

而寫得好的 prompt 通常會包含這幾樣：

• 背景：這是什麼系統、現在在做什麼
• 限制：不能做什麼、要注意什麼
• 步驟：先做什麼、再做什麼
• 格式範本：產出要長什麼樣
• 驗收：怎樣算做完

寫齊了，AI 的產出品質會差很多。

所以 prompt 本身沒有問題，它就是你跟 AI 溝通的方式。

它甚至可以是團隊資產——存成檔案、進版控、大家一起改，這些都做得到。

它只有一個特性：你要「自己決定」什麼時候把它拿出來給 AI 用。

Skill 是什麼

Skill 就是一份寫好放著的 prompt，外加一段「什麼時候該把我拿出來」的說明。

它的內容可以跟你原本那份 prompt 一模一樣。

真正多出來的是最前面那幾行——它會告訴 AI：使用者講到什麼的時候，該把這份展開來讀。

所以整個流程變成這樣：

1. 你正常講你要做什麼
2. AI 掃過每一支 Skill 的那行說明
3. 判斷這次用得上，才把整份內容讀進去
4. 照著裡面寫的做

所有決定要不要用它的人，從你變成了 AI。

對 QA 來說，這件事的價值在哪？

優秀的 QA 通常擁有很敏銳的觀察力，會追根究底地找出 root cause（＝根因，問題真正的源頭）。

重點在於「追根究底」！到底怎麼追？哪裡才算根？

往往都有一套標準，但這些標準跟經驗只存在人腦裡。

Skill 就是把這些東西寫下來，然後讓它在每次動手的當下自動生效。

舉一個我自己最常用的例子：排查，尤其是自動化測試失敗的排查。

這也最符合「追根究底」的情境了。

一個 QA 遇到失敗，會很自然地做完這幾件事：

• 看失敗報告跟截圖
• 查看相關的程式碼
• 查驅動自動化的服務（例如 Jenkins、K8S）留下的 log
• 查詢 GitHub Repo 中近期的 PR
• 翻一下有沒有類似的舊 Bug 單
• 找找近期上線的需求單

所以當把上述都寫成 Skill 之後，AI 每次排查都會照著這幾個來源查一遍

哪些工作值得包成 Skill

我常用這五個問題判斷：

□ 這個任務一個月會發生 3 次以上嗎？
   否 → 不用包，用 prompt 就好

□ 不同人做，產出品質會明顯不同嗎？
   否 → 不用包，代表這件事沒有隱性標準

□ 這件事有「做對」跟「做錯」的差別嗎？
   否 → 不用包，沒有標準就沒有東西可以編碼

□ 講得出「先做什麼、再做什麼」嗎？
   否 → 先把流程講清楚再包，不然只會包出一團模糊

□ 教一個新人做這件事，要講超過十分鐘嗎？
   是 → 值得包。那十分鐘就是你要寫進去的東西

總結

• Prompt 是你這次要講的話，寫得越完整，產出越穩
• Skill 是一份寫好放著的 prompt，加上一段「什麼時候該用我」的說明
• 決定要不要用它的人，從你變成了 AI
• QA 有大量「有標準但標準在人腦裡」的工作，這些是 Skill 最好的題目

不過寫完之後我遇到一個很蠢的問題。

我把一支 Skill 寫得很完整、流程很清楚、範例也給了。

然後它從來沒有被叫出來過。

明天講講為什麼一份 Skill 最重要的其實是開頭那幾行。