養蝦這麼久，你應該深刻體認到「技能（Skill）」有多麼關鍵。
其實，寫得再爛的技能也沒那麼可怕。
因為只要讓 Lobe 執行兩次，發現完全無法運作，當場卸載重來即可。
但最折磨人的是那些「半吊子」技能：它不是完全不能用，可能 70% 的情況還算正常，但剩下 30% 機率會莫名翻車。
這在現實應用中太常見了。AI 界的大佬 Andrej Karpathy 最近發布了一個名為 autoresearch 的開源專案，旨在讓 AI Agent 自主優化大模型的訓練過程，效果相當驚人。
但這套方法論其實可以遷移到更多場景。
今天就要來分享，我如何將這套理論應用於優化 Skill 的最佳實戰經驗！
autoresearch 的本質其實非常直觀：就是讓 AI 來優化 AI。
既然如此，我們當然也能讓 AI 自動迭代並優化 Skill。我實際測試了一個與網頁複製相關的 Skill，將其通過率從 56% 大幅提升至 92%。
Skill 最怕就是不穩定
所謂 Skill 不穩定，通常是指按照該 Skill 的流程執行時，大模型有一定機率產出不符合預期的結果。
更麻煩的是，你往往搞不清楚這些不良結果究竟是如何產生的。
這時候該怎麼辦？你可能會讓 AI 進行覆盤，憑著感覺隨意修改。
最後，這個 Skill 很可能變成一個四不像的「縫合怪」。
而 autoresearch 要做的，就是將這個過程轉化為一套可重複驗證的實驗流程。
其核心邏輯特別樸素：它不需要 Agent 一次性完成所有 Skill 的重寫。
一次只修改一個小地方，然後重新運行並評分。如果效果變好，就保留修改；如果變差，則撤回修改。
因此，任何可以被量化的事物，都可以透過 autoresearch 來優化。
這當然也包含了各種 Skills。
明確定義什麼是「好」？
首先，為什麼 Skills 會不穩定？
因為裡面可能包含了一些模糊的表述。
例如：「不要有 AI 味，要更自然一點」。
這些話本身沒問題，但執行起來會變得非常玄學。autoresearch 則會強迫你將這些玄學，拆解成可以判斷的是非題。
你對於「好結果」的定義究竟是什麼？
舉例來說，針對一篇創作類的 Skill，其定義可能是：
全文字數是否控制在 1500 字以內？ 開頭前三句有沒有點清主題？ 標題是否包含特定關鍵詞 xxx？
這就是要做出明確的「是/否」定義，讓 AI 能夠穩定地進行評分。
這裡提供一個具體的評判標準（Eval Prompt）範例：
### Eval 指南
如何編寫真正能提升你的 Skill，而不是給你虛假信心的 Eval 標準。
---
### 黃金法則
每一個 Eval 都必須是一個 Yes / No 問題。
不是量表。
不是感覺判斷。
必須是二元的。
為什麼：量表會疊加波動。如果你有 4 個 Eval，每個都按 1-7 分評分，那麼總分在不同運行之間會有很大的方差。只有二元的 Eval 才能給你穩定可靠的信號。
---
### 好 Eval 和壞 Eval
#### 文本 / 文案類 Skill
例如：電子報、推文、郵件、著陸頁
**壞 Eval：**
- 「這段文字寫得好嗎？」（太模糊了，「好」到底是什麼意思？）
- 「給它的吸引力打 1-10 分」（量表 = 不可靠）
- 「它聽起來像人寫的嗎？」（主觀，評分不一致）
**好 Eval：**
- 「輸出中是否完全沒有出現這份禁用詞列表中的短語：[game-changer, here's the kicker, the best part, level up]？」（二元、具體）
- 「開頭第一句是否提到了一個具體的時間、地點或感官細節？」（二元、可檢查）
- 「輸出是否在 150-400 字之間？」（二元、可測量）
- 「結尾是否用了一個具體的 CTA，明確告訴讀者下一步該做什麼？」（二元、結構性）
#### 視覺 / 設計類 Skill
例如：圖解、圖片、簡報
**壞 Eval：**
- 「看起來專業嗎？」（主觀）
- 「給視覺質量打 1-5 分」（量表）
- 「佈局好嗎？」（模糊）
**好 Eval：**
- 「圖片中的所有文字是否都清晰可讀，沒有截斷、重疊或互相覆蓋？」（二元、具體）
- "配色是否只使用柔和/粉彩色調，沒有螢光色、亮紅色或高飽和顏色？」（二元、可檢查）
- 「佈局是否是線性的，也就是從左到右或從上到下流動，沒有零散分佈的元素？」（二元、結構性）
- 「圖片中是否完全沒有數字步驟、序數詞或順序編號？」（二元、具體）
#### 代碼 / 技術類 Skill
例如：代碼生成、配置、腳本
**壞 Eval：**
- 「代碼乾淨嗎？」（主觀）
- 「它有遵循最佳實踐嗎？」（模糊，到底是哪種最佳實踐？）
**好 Eval：**
- 「代碼是否能在不報錯的情況下運行？」（二元、可測試，真的去執行它）
- 「輸出中是否完全沒有 TODO 或佔位註釋？」（二元、可 grep）
- 「所有函數名和變量名是否都具有描述性（除了循環計數器外，沒有單字母命名）？」（二元、可檢查）
- 「代碼是否對所有外部調用都做了錯誤處理（API、文件 I/O、網絡）？」（二元、結構性）
#### 文檔類 Skill
例如：提案、報告、簡報 Deck
**壞 Eval：**
- 「內容夠全面嗎？」（相對於什麼才算全面？）
- 「它有回應客戶需求嗎？」（太開放了）
**好 Eval：**
- 「文檔是否包含所有必需章節：[把章節列出來]？」（二元、結構性）
- 「每一個結論是否都有具體數字、日期或來源支撐？」（二元、可檢查）
- 「文檔是否控制在 [X] 頁 / [X] 字以內？」（二元、可測量）
- 「執行摘要是否能壓縮在 1 段、且不超過 3 句話？」（二元、可計數）
---
### 常見錯誤
#### 1. Eval 太多
超過 6 個 Eval 之後，Skill 就會開始「鑽 Eval 的空子」。它優化的是怎麼通過測試，而不是真的產出好結果。就像學生死記硬背答案，卻沒有真正理解內容。
**修正方法：** 選出最重要的 3-6 個檢查項。如果這些都通過了，輸出大概率就是好的。
#### 2. 過窄 / 過死
「必須正好包含 3 個 bullet point」或「必須至少使用 2 次 because」這種規則，會讓 Skill 技術上通過測試，但產出會變得怪異、僵硬。
**修正方法：** Eval 應該檢查你真正關心的質量特徵，而不是隨意的結構約束。
#### 3. Eval 重疊
如果 Eval 1 是「文本語法正確嗎？」，Eval 4 是「有沒有拼寫錯誤？」，這兩條其實重疊了。語法失敗裡往往已經包含拼寫錯誤。你是在重複計數。
**修正方法：** 每一個 Eval 都應該只測試一個獨立維度。
#### 4. Agent 根本無法衡量
「人類會不會覺得這段很吸引人？」Agent 沒法穩定回答這個問題。它幾乎每次都會說「會」。
**修正方法：** 把主觀感受翻譯成可觀察信號。比如「有吸引力」可以改寫成：「第一句裡是否包含具體主張、故事或問題，而不是一句泛泛的陳述？」
---
### 寫 Eval 之前，先過這 3 個問題
在最終確定一條 Eval 前，先問自己：
1. **兩個不同的 Agent，拿到同一個輸出，能不能打出一樣的分？**
如果不能，這條 Eval 太主觀了，重寫。
2. **一個 Skill 能不能在根本沒變好的情況下，靠鑽空子通過這條 Eval？**
如果可以，這條 Eval 太窄了，放寬。
3. **這條 Eval 測的，是不是用戶真的在乎的東西？**
如果不是，刪掉。每一條不重要的 Eval，都會稀釋那些真正重要 Eval 的信號。所以，完整的一個循環應該是：
一、選擇一個你想優化的 Skill。
二、給它一些測試輸入。
例如：給一篇長文章寫個開頭，或是根據 Google 的 5 條 Skills 原則撰寫一篇內容等等。
三、給它一份檢查清單（Checklist）。
感覺 3 到 6 條比較好，太少了約束不夠，太多了，Agent 又開始為了迎合 Checklist 而應付考試。
四、跑分 -> 循環 -> 再跑分。
可能先跑分，發現很糟糕。Agent 可以分析失敗點，做一個小修改，重新測試。分數漲了就保留，分數跌了就撤銷。
然後繼續下一輪。
一直跑到連續多次達到高分為止。
那份 Changelog 其實很有價值
它會包含完整的 Skill 進化歷史。
會有改了什么？為什麼改？改了有沒有提升？哪些是合理的改法，但最後沒用？
這個東西特別重要。
因為以後模型再升級，或者你想把 Skill 遷移到别的平台。
你就不用從零開始了，手裡有一份 Skill 被驗證過的進化路徑。
這其實就是 Agent 時代非常稀缺的東西。
写在最後
其實這些東西，不止能拿來優化 Skill。
我甚至用來做代碼性能優化。
一個頁面加載，通過 67 輪迭代，從 1100ms 跑到了 67ms。
所以，只要能定義評分規則，就可以讓 Agent 自主迭代優化。
這其實就是一種強化學習，評分規則就是獎勵分數（Reward Score）。
別再靠感覺去優化了，autoresearch 已經擺明告訴所有人：
如果一個東西會被反覆調用，那它就值得被反覆測試。
如果一個東西能被反覆測試，那它就值得被交給 Agent 自動優化。