Agent Skills 評測教學：加了技能真的比較好？用三組測試找答案
Agent Skills 評測怎麼做？從相同任務、三組對照到隱藏驗收，教你分清楚 AI 有照規則做，和做出來的東西有沒有幫助。附可改的提示詞、紀錄欄位與失敗判讀，讓團隊用自己的模型和工作環境決定技能該留還是刪。
Agent Skills 評測，是用一組事先固定的任務，檢查 AI 加上技能指引後，能不能交出更可靠的結果。
技能本身是一份工作說明，告訴代理何時使用某種方法、怎麼執行與檢查。因為它不會直接改變模型，所以安裝成功，只代表多了一份能讀的說明。
真正難的地方，是很多技能看起來很完整，代理也確實照做，產物卻沒有更實用。多寫十個測試，可能只是多測了十次相同的事情。
開發者 Sergii Makarevych 在十月十九日分享一篇技能評測方法，主張分開觀察規則是否落實，以及落實之後是否改善任務。這個差別，適合拿來檢查團隊準備長期使用的技能。
下面的範例以程式任務為主，評分表與提示詞由本站重新設計，沒有宣稱已經完成實驗，也沒有把別人的成績當成你的預期結果。
如果你正準備替整個團隊裝上同一份技能，先花力氣找出它要改善的錯誤，會比先把規則寫得更長有用。
Agent Skills 評測先分清楚「有照做」與「有幫助」
一個技能至少要接受兩個不同的問題：代理有沒有遵守指引，以及遵守之後，工作結果有沒有變好。
例如技能要求修改程式前先讀相鄰檔案，紀錄裡出現讀檔動作，就能支持「有照做」。但如果修完仍破壞相鄰功能，讀過檔案這件事本身，還不能支持「有幫助」。
因此，評測表要把行為證據和產物品質放在不同欄位。前者能協助你修改指令，後者才決定這份指令值不值得留。
怎麼把模糊的好處改成可以檢查的目標？
先挑一種已經發生過的失敗。例如代理經常把日期格式讀錯，或替匯入流程寫出無法攔截重複資料的測試，這些都比「提高品質」更容易驗證。
接著寫出改進後應該出現的行為。日期問題可以要求明確辨認年月日順序，匯入問題可以要求第二次執行仍保持相同筆數，讓結果能用固定資料核對。
Agent Skills 官方規格定義了技能檔案的名稱、描述與內容格式，但格式正確並不等於工作效果經過驗證。因此，格式檢查應放在實驗前，而不是拿來當成果。
以下用會員資料匯入的教學案例，把兩種證據排在一起。所有欄位都是示範設計，沒有附上虛構的實驗分數。
| 要改善的問題 | 行為證據 | 結果證據 |
|---|---|---|
| 重複匯入同一筆資料 | 代理找出唯一識別欄位 | 執行兩次仍只有一筆 |
| 空白欄位讓程式中斷 | 代理列出缺值處理 | 缺值樣本得到指定錯誤 |
| 修改影響其他功能 | 代理辨認相關呼叫端 | 原本應通過的流程仍通過 |
表格讓失敗原因比較清楚。若代理沒有辨認識別欄位，要修的是指令或資訊入口；如果辨認了仍重複寫入，則要追查實作方式與驗收條件。
先準備五個有答案的真實任務
好的測試題應該來自團隊真的會交給代理的工作，因為技能在陌生範例表現好，不代表能處理你的資料與專案限制。
先從五個任務開始即可。這是方便建立流程的小樣本，不是足以證明普遍效果的數量，所以結論只用來決定是否值得再測。
任務包需要放什麼？
每一題都留下使用者需求、開始時的檔案、允許修改的範圍，以及最後如何判定成功。這些內容必須在第一組開始前固定，否則後面很容易為了某組結果調整規則。
如果你要測匯入流程，輸入應包含正常資料、空白資料、重複資料與格式錯誤。因為只有正常輸入時，許多看似正確的程式都能過關，差異反而不容易看見。
任務包可以分成「代理能看到的需求」與「評測者保留的檢查」。後者例如另一份重複順序不同的資料，用來檢查它是否只記住示範答案。
但隱藏檢查必須測量原本就要求的行為，不能突然加入需求外的新功能。否則代理失敗，反映的是出題不公平，而不是技能不好。
哪些題目不要全部放在一起？
修正單一錯字和重寫整個資料流程的工作量差很多，若直接合計成功率，大任務的成本容易被小任務掩蓋。
因此，先把題目標成小型修改、跨檔案修改、需要外部資料等類別，再在各類別內觀察。這樣才能知道技能在哪種工作有用，而不是只得到一個漂亮平均值。
也要留下未參與修改技能的新題目。因為你根據測試題反覆改規則，最後可能只是把技能調成最會解這幾題，拿新案例驗證才能發現這個問題。
三組用相同輸入，隔離文字長度的影響
最基本的比較，是不裝技能的一組、使用技能的一組，以及放入相近長度無關文字的一組。第三組的用途，是檢查變化是否只和多了文字有關。
這個設計來自原作者提出的評測方向，但實際執行仍需依工具能力調整。若你的環境無法乾淨移除其他指引，就應清楚記錄保留下來的規則。
怎樣避免前一組留下答案？
每組都從同一份乾淨專案副本與新對話開始，測試資料也保持相同。若共用已修改的工作目錄，第二組看到前一組答案，就不再是獨立比較。
模型、工具權限、時間與執行上限也要一致。因為一組能上網查文件，另一組只能讀本機，結果差異就混入工具條件，不能直接歸功於技能。
每題重複執行幾次，才能看到結果是否穩定。首次先做少量重複，發現差異很大時再增加，並把每次成敗保留下來，不只挑最好的一次展示。
Vercel 的官方評測文章比較了不同指引放置方式，也顯示技能如何被觸發，會影響實驗結果。但那是特定任務與環境下的結果，不能直接推成所有專案都應選同一種文件。
因此，評測紀錄還要寫下技能是否真的被載入。若它根本沒進入工作流程，這輪測到的是觸發方式，而不是那份內容的效果。
用隱藏驗收與人工標記檢查產物
產物評分應先看能不能完成任務，再看代理為此付出多少時間、呼叫與修改，因為更長的執行紀錄不等於更可靠。
例如程式能通過格式檢查，卻漏掉需求指定的錯誤訊息，仍不能算完整成功。反過來，修改只有兩行，但原本的錯誤與相關流程都被驗證，也不該因為產物少而扣分。
怎麼評測代理自己寫的測試？
先放入一個確定有錯的版本，再看新增測試能否抓到它。若有錯與修正後都通過，這個測試就沒有證明它測到了那項行為。
這種做法可以從團隊熟悉的一個小錯誤開始，不必一開始建立複雜平台。重要的是讓評測者能指出「它攔下哪個錯誤」，而不是只報新增幾個檔案。
對需要判斷的內容，可以讓人工先標記少量結果，再用同一份準則協助分類。AI 評審若和人工經常不同意，就先修評分方法，別讓不可靠的評審替技能背書。
評分時把產物打散，暫時隱藏是哪一組產生，也能減少「我知道這是新技能，所以覺得比較好」的偏見。這是評測流程建議，不是平台內建保證。
可改的 Agent Skills 評測提示詞與紀錄表
下面是本站設計的實驗規劃提示詞，適合交給代理整理測試包。它不是原作者全文翻譯，也不會替你執行外部變更。
我要評估這份技能是否改善會員CSV匯入的修改品質。
先不要安裝到正式專案，也不要修改技能。
輸入：技能文字、乾淨專案副本、五個任務需求。
先將每條規則改寫成可觀察行為，說明它預期解決哪種錯誤。
建立三組：沒有技能、使用技能、相近長度的無關說明。
列出必須固定的模型、權限、起始檔案及執行上限。
為每題準備代理可見需求與評測者保留的驗收資料。
評分包含：任務成功、規則落實、破壞既有功能、時間與成本。
不得以測試數、程式碼行數或回覆長度代替品質。
沒有實際執行的項目填「未執行」，不得預填成績。
輸出測試計畫、紀錄表與需要人工決定的評分項目。
執行時，每筆紀錄保留任務編號、組別、執行次數、產物路徑、成功與否、失敗原因及耗用。因為摘要只能幫你找差異，原始產物才讓別人重新檢查。
若工具沒有提供可靠成本，就記錄可取得的呼叫與使用量，別用猜測補成金額。不同方案的帳單口徑也可能不同，所以跨工具成本要另外說明。
一個任務從出題到判讀的完整例子
假設團隊的問題是第二次匯入會重複新增會員，先保留一份只有三列的輸入，其中兩列代表同一個人。需求明寫以會員編號判斷相同身分，電話只作聯絡用途，避免代理自行選錯唯一欄位。
代理可見的驗收例子，是第一次匯入新增兩位會員。評測者另外保留一份順序改過、電話格式改過的輸入，再匯入一次時，總會員數仍應是兩位。這樣能檢查程式是否真的依會員編號處理。
接著在三組環境執行相同任務，每次都重建空白資料庫。因為沿用前次資料會改變起點，即使最後筆數剛好相同，也不能知道是哪次修改帶來效果。
完成後先看隱藏資料是否通過，再讀代理紀錄。若技能組每次都先讀資料模型，卻仍用電話比對，就記成「讀檔規則有遵守，識別邏輯未成功」，不要把兩項合併成模糊的部分成功。
如果某一組只有一輪通過，另一組多輪都通過，報告要呈現各輪結果，而不是只比較最好成品。小樣本仍有偶然性，但至少能看見哪種流程反覆卡在同一處。
怎麼決定要改技能，還是先改測試？
先抽查評分本身有沒有誤判。例如程式正確拒絕不合法資料，評分器卻只看回傳是否成功，就可能把應該失敗的案例算錯。此時繼續調技能，只是在配合壞掉的量尺。
量尺確認後，再一次改一項規則。若同時縮短描述、換模型又增加工具，即使下輪變好，也無法知道哪個改動有效。保留舊版與修改原因，讓每次實驗能回答一個清楚問題。
最後把結論寫成有範圍的決定，例如「這版在重複匯入任務較穩定，先保留識別欄位檢查；報表任務尚未測」。這比宣布整份技能全面有效，更方便團隊安排下一輪。
依結果刪規則，再用新案例複驗
規則遵守率高、任務效果卻持平時，應先檢查那項規則是否真的解決問題。要求更多動作，可能只讓代理花更多力氣。
如果技能在一類任務有效，在另一類反而增加失敗，就縮小適用條件。這比把同一份技能裝進所有工作，更符合實驗看到的差異。
模型、工具或工作資料變更後，也要重跑保留下來的代表題。因為原本有用的提示可能變得多餘，原本不會觸發的技能也可能改變行為，舊結果不能永久沿用。
想先理解技能與專案規則的分工，可以接著閱讀站上的基礎說明，再回來測一份你真的準備採用的指引。
延伸閱讀：從 Vibe Coding 進階到 Agentic Engineering：Prompt、Rules、Skills、Subagents 一次搞懂
延伸閱讀：PostHog Context Mill 是什麼？把文件做成版本化 Skills，讓 AI 代理跟上產品
常見問題 FAQ
Agent Skills 評測一定要工程師才能做嗎？
需要能判斷任務結果的人，但不一定每題都要寫程式。文件整理也能比較來源正確率、漏項與人工修改量，前提是先固定評分標準。
五個任務可以證明技能普遍有效嗎？
不行。五題適合建立流程、找明顯問題，後續仍要增加不同類型與未看過的題目，才能擴大結論範圍。
技能沒有被載入，應該算失敗嗎？
應記錄為觸發失敗，因為使用者實際上也拿不到預期效果。但分析時要和內容無效分開，兩者需要不同修正。
可以讓同一個模型出題、作答又打分嗎？
可以協助準備，但評分應有人工確認的例子與獨立驗收。否則同一種盲點可能同時存在於答案和評審，讓錯誤看起來都通過。
先測一份準備長期使用的技能
從一個反覆發生的錯誤開始，保留相同任務、相同起點與實際產物，再決定規則是否值得留。若你還說不出它要改善什麼，先把目標寫清楚，會比擴充技能清單更有用。歡迎訂閱 AI 郵報，持續取得能拿回工作現場調整的教學。
