Claude Cowork 系列進度　12 / 14

📌 這篇文章談什麼？

• eval（評測）不是什麼技術活——就是一次試跑：丟一個真實請求進去，看結果，然後告訴 Claude 該修什麼。
• 關鍵在對照組：同一個請求，一邊用你的 skill、一邊不用，並排看差別。
• 附三組完整對照範例——包含一個「兩邊同分」的案例，那才是最值得看的。
• 迭代原則：一次只改一件事；出貨標準不是滿分，而是「你在意的案例明顯比基準好」。

1. 說明什麼是 eval，以及為什麼在你依賴或分享一個 skill 之前它很重要。
2. 透過 skill-creator 跑一次輕量的 eval。

🕳 你自己用，和別人用，差在哪裡

當你用的是自己做的 skill，你知道怎麼繞過它的問題。你清楚該問什麼、該給哪些檔案、答案應該長什麼樣。

但同事一樣都沒有。他可能把請求講得稍微不一樣、給的輸入略有出入、或撞上一個邊緣案例——那種不常見但真實會發生的情況，例如剛好落在這個 skill 設計範圍之外的請求。skill 通常就是在那裡絆倒的，而使用它的人不會知道為什麼。

🔑 別被「評測」這個詞嚇到。
eval 就是一次試跑：丟一個真實的請求進去，看看出來什麼，然後告訴 Claude 要修什麼。
沒有程式碼、沒有測試腳本——只有你的判斷：這個結果好到可以掛上你的名字了嗎？

⚖️ 對照組才是重點

skill-creator 會想出兩個以上可能有人會拿來用的真實請求。每一個請求，它都產出一對結果：一份用了你的 skill、一份沒有用。

第二份就是比較基準。它存在是為了讓你並排看出你的 skill 實際上造成了什麼差別——不只是「這個產出還可以嗎」，而是「這個產出比 Claude 自己做出來的更好嗎」。

案例一　典型情境

整理一場例行的產品同步會議

📌 差距最明顯的一組。無技能版讀起來像散文，資訊都在裡面，但「誰要在哪天前做什麼」全部糊掉了。

案例二　凌亂的輸入

從潦草、半數是貼上訊息的筆記整理站立會議

📌 這一組的關鍵不在分數，在那個「負責人不明」的標示。有技能版老實承認它不知道並請你確認；無技能版則直接編了一個負責人出來。前者字數超標所以扣了一分，但那是遠比「憑空指派工作給某人」輕微的問題。

案例三　形式與實質的拉扯

寫給「只看前三行」的主管的會議記錄

📌 兩邊同分——這才是最值得看的一組。技能版守住了結構（問題獨立列出），但因為結構本身有標題層次，最關鍵的日期被擠到第五行；無技能版第一句就把日期講出來，卻把待確認問題埋進敘述裡。各有各的失分，分數一樣。

🔑 這正是為什麼 eval 不能只看分數。
案例三的分數是平手，但你一看就知道要給什麼回饋：「這個受眾只看前三行，請讓決議的日期出現在最開頭。」
eval 的價值不在打分，在於逼你看清楚「差在哪裡」，然後說出那一句話。

🎯 一次只改一件事

如果第一輪顯示這個 skill 既太囉嗦、又漏掉一個段落，挑比較要緊的那一個去修，重跑，然後再回來做第二次審閱。這樣你才分辨得出到底是哪個改動真的起了作用。

🔁 它是一個迴圈，不是一次性的關卡

修改之後如果你還是不滿意，就再跑一次。大部分 skill 在一到兩輪之後就可以用了。

📏 出貨標準是什麼？
把一個 skill 交出去——給你自己、給同事——標準不是評測完美。
而是：① 你在意的那些案例，明顯比基準版更好；② 你已經指出還沒處理好的是哪些案例。

1. 你做的 skill 是一個小產品，別人用它時沒有你的內建知識——邊緣案例就是它絆倒的地方。
2. eval 就是試跑：真實請求進去、看結果、說出要修什麼。不用寫程式。
3. 對照組是核心設計：問題不是「這個還可以嗎」，而是「這比 Claude 自己做的更好嗎」。
4. 回饋要具體：「語氣太正式」可以行動，「這個不太對」不行。
5. 一次改一件事；出貨標準不是滿分，而是重要案例明顯更好、且你知道還缺什麼。

回到上面那三組對照，針對每一對做兩件事：

1. 挑出你真的會拿去送出的那一版。
2. 寫一行你會給 Claude 的回饋。

這就是整個迴圈。當那是你自己的 skill 時，Claude 會拿你的選擇與回饋去修改它。

回饋寫法對照：可行動 vs 不可行動

判斷方式：把你寫的那句話唸一遍，你能想像 Claude 要改哪一行 SKILL.md 嗎？想不出來，就是還不夠具體。

🚀 下一課預告

Lesson 13 要從「這個對我有用」走到「這個對團隊有用」——那些把個人工作流程變成共享基礎設施的模式與選擇。