self-eval

self-eval skill 概覽

self-eval 的用途

self-eval skill 是一個純 prompt 型的 Claude Code skill，用於在工作完成後進行誠實的自我評估。它能協助 AI agent 在完成任務、程式碼審查、實作階段、除錯流程或規劃練習後，檢視自己的輸出，而不是落入籠統稱讚或膨脹成「4/5」這類過度樂觀分數的模式。

self-eval 不是用單一主觀尺度問「這做得多好？」，而是把評估拆成兩個軸向：任務企圖心與執行品質。當你需要校準地回答「這真的是高品質成果，還是只是把簡單任務做得還可以？」時，這種拆分特別有用。

最適合的使用者與任務

如果你希望 agent 在你接受成果、合併變更或繼續接著開發之前，先審視已完成的工作，self-eval skill 很適合使用。它尤其適合已在程式碼生成、重構、issue triage、測試撰寫或架構分析中導入 AI 的工程團隊。

它不能取代測試套件、人工審查、安全審查或正式上線驗證。它的價值在於結構化自我批判：抓出過度自信、揭露薄弱處，並在不同工作階段之間留下可追蹤的評分紀錄。

與一般 prompt 的差異

一般「評估你的工作」prompt 常會產生泛泛的優點、輕描淡寫的保留意見，以及偏樂觀的分數。self-eval 加入了讓分數膨脹更困難的限制：必須進行 devil’s advocate 推理、使用固定評分矩陣，並將分數持久化到 .self-eval-scores.jsonl。

這種持久化很重要。如果近期評估分數過度集中，skill 可以標記出可能的分數膨脹模式，而不是把每次評估都當成彼此孤立的事件。

如何使用 self-eval skill

安裝 self-eval 與檢查 repository

使用你的 skill manager 從 GitHub skill 來源安裝，例如：

npx skills add alirezarezvani/claude-skills --skill self-eval

相關 repository 路徑是：

engineering/skills/self-eval/SKILL.md

目前結構中沒有外部依賴、輔助 scripts、隨附 rules 或 reference files。若要快速進行安裝前審查，請先閱讀 SKILL.md；其中包含評分模型、工作流程與輸出預期。由於這是純 prompt 型 skill，導入風險較低，但輸出品質高度取決於你是否提供足夠的任務脈絡。

skill 需要哪些輸入

要讓 self-eval 使用起來有價值，不要只說「evaluate this」。請提供 agent 已完成的工作，以及應該依據哪些標準評估。

高品質輸入包括：

• 原始使用者需求或 issue 描述
• agent 產出的最終回答、patch、plan 或 review
• 相關限制，例如時間限制、風格規則、測試要求或禁止使用的做法
• 驗證證據，例如已執行的測試、變更的檔案、執行過的 commands 或已知缺口
• 預期讀者：maintainer、reviewer、product owner、beginner user 或 production team

弱 prompt 只要求給分。強 prompt 會提供足夠證據，讓 skill 能分辨「企圖心低但執行乾淨」與「企圖心高但完成度不足」。

取得更好結果的 prompt 模式

請在工作完成後使用 self-eval，而不是工作開始前。實用的 prompt 範例如下：

Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.

這種結構能改善結果，因為它避免模型只根據語氣或投入程度評估。它會迫使 review 同時考量企圖心、執行、證據與尚未解決的風險。

建議工作流程

在「過度正面的評估會造成成本」的檢查點執行 self-eval：

1. 完成任務或草擬解法。
2. 使用原始目標與工作證據要求 self-eval。
3. 先閱讀 devil’s advocate 區段，再看最終分數。
4. 將弱點轉換成簡短的修正清單。
5. 只有在做出實質變更後才重新執行，不要為了表面文字修飾重跑。

如果 .self-eval-scores.jsonl 在你的工作目錄中被建立，請把它視為本機評估歷史。你的團隊需要決定該檔案要提交、忽略，或定期檢視。

self-eval skill FAQ

self-eval 是用於 Model Evaluation 還是程式碼品質？

兩者都可用，但意義需要界定清楚。self-eval for Model Evaluation 最適合理解為針對 AI agent 自身工作成果的任務層級評估，而不是 benchmark 等級的模型測量。它可以協助比較不同工作階段、偵測膨脹的自評分數，並改善 review 紀律，但不能取代正式的 eval harnesses、golden datasets 或人工作標註的評分。

什麼情況不該使用 self-eval？

不要把它當成高風險工作的唯一關卡：安全敏感變更、法律或醫療內容、production migrations，或任何需要驗證正確性的事項都不適合只靠它把關。當沒有具體 artifact 可評估時，也應避免使用。這個 skill 需要任務、輸出與評估準則；否則它仍會產生結構化內容，但證據基礎會很薄弱。

對初學者友善嗎？

是的，因為它是純 prompt 型，沒有工具依賴。不過初學者在使用前仍應閱讀 SKILL.md，尤其是評分邏輯。主要學習曲線不在安裝，而是在提供足夠脈絡，讓評估不是只憑感覺。

與直接要求 critique 有什麼不同？

critique 可以列出問題，但不一定有校準過的評分。self-eval 使用雙軸模型與矩陣鎖定的最終分數，因此 agent 比較沒有空間替任何「感覺合理」的評級找理由。devil’s advocate 步驟也要求先分別為較高分與較低分提出論點，再收斂成最終判斷。

如何改進 self-eval skill

給 self-eval 更扎實的證據

改善 self-eval 結果的最佳方式，是讓證據更具體。包含變更過的檔案、失敗或通過的測試、重要遺漏項，以及 acceptance criteria。如果沒有執行測試，就明確說明。若回答刻意略過某項需求，也要一併提供。

更好的輸入不等於更長的輸入，而是更可評估的輸入。「Refactored auth code」很薄弱。「Refactored auth/session.ts to remove duplicated token parsing; ran npm test -- auth; did not test OAuth callback manually」則給了 skill 真正可評分的材料。

留意常見失敗模式

最常見的失敗，是讓模型獎勵努力程度，而不是成果。另一個問題，是把困難任務中的部分完成自動視為高分。self-eval 的設計就是為了抵抗這些傾向，但前提是使用者有提供原始企圖心與實際交付成果。

也要留意評分歷史的雜訊。如果 .self-eval-scores.jsonl 混合了互不相關的任務類型，分數聚集訊號可能就不那麼有意義。文件潤飾與複雜 migration 不應只因為數字分數相同，就被解讀成等價工作。

從分數迭代到行動

不要停在最終分數。真正有用的輸出，是企圖心與執行之間的落差。把這個落差轉成修復 prompt：

Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.

這能讓下一輪迭代保持聚焦，也能避免 agent 為了追求更高分，透過加入無關功能來「改善」成果。

謹慎客製化

如果你要調整 self-eval skill，請保留會產生校準效果的部分：分離的評估軸、devil’s advocate 推理、固定分數對應，以及對評分歷史的意識。客製化 labels、輸出格式或團隊專屬 acceptance criteria 通常是安全的。移除那些迫使模型反駁自己的限制，會讓這個 skill 變得更像一般 review prompt。