裝上這個開源元 Skill，演進式迭代你所有的 Skill
整理版優先睇
用呢個開源元 Skill，系統性迭代你所有 Skill
呢篇文章係魚頭頭寫嘅，佢做咗一個開源嘅元 Skill 叫 skill-evolve，專門用嚟改進其他 Skill。佢發現好多時我哋整好一個 Skill 嘅初版之後，用落會發現唔對路，手動改完又改，越改越亂，仲要每次都要喺對話入面重新糾正。問題在於冇系統性嘅改進方法，每次只係頭痛醫頭。呢個元 Skill 嘅目的就係畀 Skill 改進裝上一套演進方法論，等你唔使再靠直覺亂改。
方法論嚟自西瓜嘅文章《好東西都是總結出來的》，提煉咗三個機制：OTF（邊做邊總結）、JIT（先交60%版本再迭代）、Bootstrap（知識自舉，每輪筆記做下一輪燃料）。魚頭頭將佢哋映射到 Skill 改進場景，設計咗一個五步演進循環，令改進變成有系統、可追溯嘅過程。
五步循環包括冷啟動（讀曬 Skill 內容，記錄直覺但唔好改）、觀察（用3-5個測試 prompt 跑，即時記錄）、提煉模式（揾共性錯誤，整錯誤模式表）、改寫（每次只改1-2個最高優先級模式）、驗證（同一批 prompt 重跑睇係咪收斂）。作者用呢個循環改進自己嘅 content-pipeline Skill，結果直出咗呢篇文章，連平時要執半個鐘嘅步驟都慳返。總括嚟講，好 Skill 唔係設計出嚟，而係從真實使用中長出嚟。
- 結論：Skill 需要從真實使用中持續迭代，唔係一次過寫好就算。
- 方法：用五步演進循環——冷啟動、觀察、提煉模式、改寫、驗證，每輪只改一件事。
- 差異：傳統改技能係頭痛醫頭，呢個方法強調揾共性模式，避免亂改同引入副作用。
- 啟發：OTF、JIT、Bootstrap 呢三個機制唔止適用於 Skill 改進，仲係通用嘅知識工作方法論。
- 可行動點：安裝 skill-evolve（git clone），跟住對現有 Skill 行完整或快速模式，仲可以畀反饋一齊迭代。
skill-evolve
開源元 Skill，用嚟系統性改進其他 Skill。安裝後輸入「改進呢個 skill」或「/evolve」即可觸發。
點解需要有個「改 Skill 嘅 Skill」
用過 Claude Code 嘅 Skill 嘅人都知，用 /skill-creator 整一個初版好容易，但用落就會發現「呢度唔對路，嗰度差啲意思」。然後你手動改 SKILL.md，改完又改，越改越亂，最後連自己改過啲咩都唔記得。更慘嘅係，每次對話都要重新糾正，下次佢又繼續執行錯。
問題核心係 冇系統性嘅改進方法。每次都係頭痛醫頭，憑直覺改，改完又唔驗證。呢個元 Skill 嘅出現就係為瞭解決呢個問題——將改進變成一門可重複嘅方法論。
方法論嚟自西瓜嘅文章《好東西都是總結出來的》，入面提到三個核心機制：OTF（邊做邊總結）、JIT（先交 60% 再迭代）、Bootstrap（知識自舉）。魚頭頭將佢哋直接映射到 Skill 改進場景，變成具體可操作嘅五個步驟。
五步演進循環
- 第一步：冷啟動——讀曬目標 Skill 嘅全部內容，回答四個問題（想做咩、觸發場景、核心指令、直覺問題位）。記低直覺，但唔好急住改，直覺只係假設。
- 第二步：觀察——揀 3-5 個測試 prompt（至少一個核心場景、一個邊緣場景、一個唔應該觸發嘅場景）。跟住 OTF 原則，每跑完一個即刻記錄觀察。
- 第三步：提煉模式——最關鍵嘅一步。唔好逐個 bug 去修，要揾 共性問題。問自己重複出現嘅問題係咩，根因喺邊層（觸發、指令、資源、架構），整一張錯誤模式表。兩條模式比八個補丁更有價值。
- 第四步：改寫——從錯誤模式取優先級最高嘅 1-2 個，針對性改寫。原則：最小改動、解釋 why、可驗證。
- 第五步：驗證——用同一批 prompt 重跑，睇目標問題係咪消失。如果減輕未消失就再改同一模式；如果出現新問題就回滾。連續兩輪新模式 = 0 代表收斂完成，可以停。
實戰案例：改進 content-pipeline
魚頭頭用呢個循環改進自己嘅 content-pipeline Skill，結果直出咗呢篇文章，平時佢至少要執半個鐘。呢個案例充分展示咗方法點樣落地。
冷啟動階段讀完 549 行 SKILL.md，記錄咗四條直覺，例如「職責太寬」、「寫作風格參考可能有問題」。但佢冇立即改，而係先觀察。
觀察階段佢用自己嘅真實痛點做測試數據：「最痛係未認真學習我認可嘅文字，每次都要改好耐。」呢個就係最好嘅起點。
提煉模式階段揾出兩個核心模式：P01—寫作風格參考同真實風格嚴重脱節（基於第啲人嘅文章拆解，但同自己風格唔夾），P02—出稿流程冇強制讀風格指南。跟住佢分析咗 9 篇已發文章，發現差異巨大，例如段落長度、開頭模式、口語程度等。
落盤階段所有過程記錄喺 evolution-log.md，下次再改就唔使從零開始，Bootstrap 令你每次喺上次停低嘅地方繼續。
點用同背後思維
安裝好簡單，一行命令 git clone，或者手動放 SKILL.md 去 ~/.claude/skills/skill-evolve。觸發可以講「改進呢個 skill」、「/evolve」或者畀一個失敗案例。有兩種模式：完整循環（五步齊全）同 快速模式（帶問題直接定位改寫）。同 /skill-creator 嘅關係係：先從 0 到 1 用 skill-creator，再從 1 到 N 用 skill-evolve 持續打磨。
背後有三個反常識思維模型：先有再改（唔好等完美先開始，用咗再總結）、每輪只改一樣（集中火力，避免混亂）、唔好掉咗筆記（每輪嘅觀察同模式係下一輪嘅燃料，都係未來新對話嘅上下文）。
裝上呢個開源元Skill，用演進式嘅方法迭代你所有嘅Skill
我做咗一個skill，專門用嚟改進其他skill。開源地址喺呢度：
GitHub：https://github.com/OrangeViolin/skill-evolve
點解需要一個『改skill嘅skill』？
Skill本質上已經係AI時代嘅軟件。Claude Code嘅 /skill-creator 令到整skill變得超容易——有諗法，30分鐘就出到一個初版。
但初版唔係終點。
用過幾次你就會發現：呢度唔對路，嗰度爭啲。然後你手動改下SKILL.md，改咗三五次，越改越亂，最後都講唔清到底改咗啲乜、點解改。同埋，執行嘅效果亦都好容易歪咗，你要喺對話入面一下一下咁修正。修正完，下一次skill繼續失憶，繼續執行歪掉……（血淚史當然唔止咁少，如果你玩過你一定明hh）
問題出喺邊？
冇系統性嘅改進方法。 每次都係頭痛醫頭，靠直覺改，改完又唔驗證。
skill-evolve要解決嘅就係呢件事——幫skill改進裝返套演進方法論，整一個元skill。
一句講曬：skill唔係寫好就搞掂，佢需要由你真實使用入面『生』出嚟。
方法論從邊度嚟
呢套方法論來自西瓜嘅《好嘢都係總結出嚟嘅》，元skill設計方法論，西瓜有幾十年知識工程嘅經驗，呢篇文章講嘅係一個核心命題：
好嘢 = 總結出嚟 ≠ 設計出嚟
佢提煉咗三個機制：
OTF（On-The-Fly）——邊做邊總結，唔等做完先回頭睇。發現模式嘅嗰一刻就記錄、歸納、應用。
JIT（Just-In-Time）——唔追求一次過完美。先交60%質素嘅版本，攞反饋，再迭代。每一輪都更加啱啲。
Bootstrap（知識自舉）——每一步迭代產生嘅筆記，係下一步嘅燃料。知識喺迭代入面自我增殖，自動化程度遞增，人工幹預遞減。
我將呢三個機制映射到咗skill改進場景：
（西瓜呢套方法論仲未寫完，我暫時攞嚟用住先，之後佢持續輸出，我就持續迭代入呢個skill度，同埋，大家用完呢個skill嘅反饋都希望一齊喺評論區交流，一齊迭代）
五步演進循環
skill-evolve嘅核心係一個五步循環。唔複雜，但每一步都有啲學問。
第一步：冷啟動——建立直覺
讀目標skill嘅全部內容。回答四個問題：
1. 呢個skill想令Claude做啲咩？ 2. 觸發場景係咩？ 3. 核心指令係咩？ 4. 邊啲地方你直覺上覺得可能有問題？
關鍵：將直覺記低，但唔好急住改。 直覺只係假設，需要數據驗證。
第二步：觀察——用真實prompt去跑
揀3-5個測試prompt：
• 至少1個核心場景（happy path） • 至少1個邊緣場景 • 至少1個唔應該觸發嘅場景
跑嘅時候跟隨OTF原則：每跑完一個prompt，立即記錄觀察。 唔好等全部跑完先回頭睇。
第三步：提煉模式——從案例到規律
呢步最關鍵。
唔好逐個修bug，要揾共性。問自己：
• 重複出現嘅問題係咩？ • 問題根因喺skill嘅邊一層——觸發層、指令層、資源層、架構層？ • 邊啲問題最影響用戶體驗？
產出一張錯誤模式表。
2條模式比8個補丁更有價值——因為模式可以覆蓋未來嘅新prompt。
第四步：改寫——每輪只改一件事
千祈唔好一次過重寫成個skill。
從錯誤模式表攞優先級最高嘅1-2個模式，針對性改寫。
三個原則：
1. 最小改動：只改與目標模式直接相關嘅段落 2. 解釋why：每處改動都要理解『點解舊寫法有問題』 3. 可驗證：改完之後可以用同一個prompt見到效果
第五步：驗證——判斷係咪收斂
用同一批prompt再跑。睇信號：
| 收斂完成 |
收斂咗就停。唔好追求完美。60% → 90%嘅投入產出比遠遠高過90% → 95%。
實戰案例：改進 content-pipeline
用 skill-evolve 改進我自己嘅 content-pipeline skill。全程實錄。
先講結果，呢個結果本身已經令我自己好哇塞！之前文章出嚟，呢篇文章，就係改完之後嘅skill直接出嘅！因為我之前確實要改至少半個鐘，呢度激動咗少少。
冷啓動
讀完 SKILL.md（549行）+ 4個references文件。記錄直覺：
但呢啲只係直覺。暫時唔改。
觀察
用戶（即係我自己）俾咗最直接嘅反饋：
「最痛嘅係仲未認真去學習我認可嘅文字，每一次我都需要改好耐。」
呢個就係最好嘅測試數據——真實嘅痛點。
提煉模式
P01：寫作風格參考同真實風格嚴重脱節
• references/writing-style.md基於5篇10w+文章拆解• 但魚頭頭嘅風格同其他人唔完全一樣 • 呢個係每次出稿都要大改嘅直接根因
P02：出稿流程冇強制讀風格參考
• 即使有風格文件，Claude都可能跳過唔讀 • 流程入面冇明確嘅『讀風格指南』步驟
根因清楚曬。
分析：到底爭喺邊
啟動3個子任務並行分析我嘅9篇已發佈文章：
每組覆蓋10個分析維度：開頭模式、段落節奏、人稱語氣、信息密度、標點習慣、過渡方式、結尾模式、獨特表達、數字用法、情緒曲線。
結果出咗嚟。差異巨大：
| 1-3句，大量單句成段 | ||
| 短文直接入場景；中長文首段亮底牌 | ||
| 按類型分：短文線性、中長文倒敍、深度文環形 | ||
| 唔好過渡詞，寧願突兀都唔好囉嗦 | ||
| 表格係第一表達工具 | ||
| 60%口語 + 30%書面 + 10%吐槽 | ||
| 單句成段『釘子』+『唔係A係B』 |
改寫
改動1：重寫 references/writing-style.md
360行舊版全部替換。新版從9篇真實文章逆向工程，覆蓋所有維度。唔係『應該點寫』，而係『魚頭頭實際點寫』。
包含按文章類型分嘅自檢清單——短文7項、中長文6項、深度文7項。寫完對住過一次。
改動2：喺出稿流程新增『讀風格指南』步驟
喺SKILL.md嘅第4步（原本直接跳去寫文章）插入：
寫文章前必須先讀
references/writing-style.md。寫完之後用末尾自檢清單過一次。
兩處改動。最少幹預，最大效果。
落盤：令改進筆記可追溯
所有過程記錄保存喺skill目錄下：
evolution-log.md 係入口。下次再講『改進content-pipeline』，Claude會先讀呢個文件，接返Round 1嘅進度。
唔係從零開始，係從上次停低嘅地方繼續。 呢個就係Bootstrap。
怎麼用
安裝
skill-evolve係一個標準嘅Claude Code skill。得一個文件：SKILL.md。冇腳本依賴，冇配置。
# 一行命令安裝 git clone https://github.com/OrangeViolin/skill-evolve.git ~/.claude/skills/skill-evolve 或者手動將 SKILL.md 放到 ~/.claude/skills/skill-evolve/SKILL.md。
觸發
講『改進呢個skill』、『skill效果唔好』、『優化skill』、『/evolve』都得。
都可以帶住一個skill嘅輸出來講『呢度唔啱』——一個真實失敗案例就係最好嘅起點。
兩種模式
完整循環：冷啟動 → 觀察 → 提煉模式 → 改寫 → 驗證。適合系統性改進。
快速模式：用戶帶住一個具體問題嚟，直接定位→改寫→試下先。適合小修。
同skill-creator嘅關係
兩者可以串聯：先 /skill-creator 出初版，再 /evolve 持續打磨。
背後嘅思維模型
三個反常識：
唔係先設計完美skill先用，而係先用起嚟再從真實反饋中總結改進。 用戶嘅痛點比你嘅想像更準確。
唔係一次過大改，而係每輪只改一件事。 改太多你會分唔清邊個改動起到作用，邊個引入咗副作用。
唔係改完就掉咗筆記，而係每輪嘅觀察同模式都保留落嚟。 佢哋係下一輪嘅燃料，亦係未來新對話嘅上下文。
呢三條——OTF、JIT、Bootstrap——唔只適用於skill改進。佢哋係一種通用嘅知識工作方法論。
好skill唔係設計出嚟嘅，係從使用入面生出來嘅。
呢句話同樣適用於skill-evolve本身。佢都係v0.1，都需要從真實使用入面持續迭代。所以我好期待你用咗之後嘅反饋——邊度好用，邊度唔順，邊度完全冇用。
歡迎嚟評論區一齊交流。如果想更進一步，可以睇菜單欄【加羣看我】加入01fish嘅摸魚羣，或者加我微信 18501790646，備註『元skill』。
調研 & 撰寫：AI（Claude） 主導 & 審校：01fish
裝上這個開源元 Skill，演進式迭代你所有的 Skill
我做了一個 skill，專門用來改進其他 skill。開源地址在這裏：
GitHub：https://github.com/OrangeViolin/skill-evolve
為什麼需要一個"改 skill 的 skill"
Skill 本質上已經是 AI 時代的軟件。Claude Code 的 /skill-creator 讓造 skill 變得很容易——有想法，30 分鐘就能出一個初版。
但初版不是終點。
用過幾次你就會發現：這裏不對勁，那裏差點意思。然後你手動改改 SKILL.md，改了三五次，越改越亂，最後也說不清到底改了什麼、為什麼改。以及，執行的效果也非常容易歪掉，你需要在對話中一遍一遍糾正。糾正完，下一次 skill 繼續失憶，繼續執行歪掉……（血淚史當然不止於此，若上手過你肯定懂 hh
問題出在哪？
沒有系統性的改進方法。 每次都是頭痛醫頭，憑直覺改，改完也不驗證。
skill-evolve 要解決的就是這件事——給 skill 改進裝上一套演進方法論，打造一個元 skill。
一句話：skill 不是寫好就完事了，它需要從你的真實使用中"長"出來。
方法論從哪來
這套方法論來自西瓜的《好東西都是總結出來的》，元skill設計方法論，西瓜有幾十年知識工程的經驗，這篇文章講的是一個核心命題：
好東西 = 總結出來 ≠ 設計出來
它提煉了三個機制：
OTF（On-The-Fly）——邊做邊總結，不等做完再回頭看。發現模式的那一刻就記錄、歸納、應用。
JIT（Just-In-Time）——不追求一次性完美。先交付 60% 質量的版本，拿反饋，再迭代。每一輪都更對一點。
Bootstrap（知識自舉）——每一步迭代產出的筆記，是下一步的燃料。知識在迭代中自我增殖，自動化程度遞增，人工干預遞減。
我把這三個機制映射到了 skill 改進場景：
（西瓜這一套方法論還沒寫完，我先拿來用了，後續持續輸出，我再持續迭代到這個skill當中，以及，大家用完這個skill的反饋也希望一起在評論區交流，一起迭代）
五步演進循環
skill-evolve 的核心是一個五步循環。不復雜，但每一步都有講究。
第一步：冷啓動——建立直覺
讀目標 skill 的全部內容。回答四個問題：
1. 這個 skill 想讓 Claude 做什麼？ 2. 觸發場景是什麼？ 3. 核心指令是什麼？ 4. 哪些地方你直覺上覺得可能有問題？
關鍵：把直覺記下來，但不要急着改。 直覺只是假設，需要數據驗證。
第二步：觀察——用真實 prompt 跑
選 3-5 個測試 prompt：
• 至少 1 個核心場景（happy path） • 至少 1 個邊緣場景 • 至少 1 個不該觸發的場景
跑的時候遵循 OTF 原則：每跑完一個 prompt，立即記錄觀察。 不要等全部跑完再回頭看。
第三步：提煉模式——從案例到規律
這是最關鍵的一步。
不要逐個修 bug，要找共性。問自己：
• 重複出現的問題是什麼？ • 問題根因在 skill 的哪一層——觸發層、指令層、資源層、架構層？ • 哪些問題最影響用戶體驗？
產出一張錯誤模式表。
2 條模式比 8 個補丁更有價值——因為模式能覆蓋未來的新 prompt。
第四步：改寫——每輪只改一件事
絕對不要一次性重寫整個 skill。
從錯誤模式表取優先級最高的 1-2 個模式，針對性改寫。
三個原則：
1. 最小改動：只改與目標模式直接相關的段落 2. 解釋 why：每處改動都要理解"為什麼舊寫法有問題" 3. 可驗證：改完後能用同樣的 prompt 看到效果
第五步：驗證——判斷是否收斂
用同一批 prompt 重跑。看信號：
| 收斂完成 |
收斂了就停。不追求完美。60% → 90% 的投入產出比遠高於 90% → 95%。
實戰案例：改進 content-pipeline
用 skill-evolve 改進我自己的 content-pipeline skill。全程實錄。
先說結果，這個結果本身已經讓我自己很哇塞了！之前文章出來，這篇文章，就是改後的skill直出的！因為我之前確實得改上至少半小時，此處激動了一點。
冷啓動
讀完 SKILL.md（549 行）+ 4 個 references 文件。記錄直覺：
但這些只是直覺。先不改。
觀察
用戶（也就是我自己）給出了最直接的反饋：
“最痛的是還沒有認真去學習我認可的文字，每一次我都需要改很久。”
這就是最好的測試數據——真實的痛點。
提煉模式
P01：寫作風格參考與真實風格嚴重脱節
• references/writing-style.md基於5 篇 10w+ 文章拆解• 但魚頭頭的風格和其他人並不完全相同 • 這是每次出稿都要大改的直接根因
P02：出稿流程未強制讀風格參考
• 即使有風格文件，Claude 也可能跳過不讀 • 流程中沒有明確的"讀風格指南"步驟
根因清楚了。
分析：到底差在哪
啓動 3 個子任務並行分析我的 9 篇已發佈文章：
每組覆蓋 10 個分析維度：開頭模式、段落節奏、人稱語氣、信息密度、標點習慣、過渡方式、結尾模式、獨特表達、數字用法、情緒曲線。
結果出來了。差異巨大：
| 1-3 句，大量單句成段 | ||
| 短文直接進場景；中長文首段亮底牌 | ||
| 按類型分：短文線性、中長文倒敍、深度文環形 | ||
| 不要過渡詞，寧可突兀不要囉嗦 | ||
| 表格是第一表達工具 | ||
| 60% 口語 + 30% 書面 + 10% 吐槽 | ||
| 單句成段"釘子"+ “不是A是B” |
改寫
改動 1：重寫 references/writing-style.md
360 行舊版全部替換。新版從 9 篇真實文章逆向工程，覆蓋所有維度。不是"應該怎麼寫"，而是"魚頭頭實際怎麼寫"。
包含按文章類型分的自檢清單——短文 7 項、中長文 6 項、深度文 7 項。寫完對着過一遍。
改動 2：在出稿流程新增"讀風格指南"步驟
在 SKILL.md 的第 4 步（原來直接跳到寫文章）插入：
寫文章前必須先讀
references/writing-style.md。寫完後用末尾自檢清單過一遍。
兩處改動。最小干預，最大效果。
落盤：讓改進筆記可追溯
所有過程記錄保存在 skill 目錄下：
evolution-log.md 是入口。下次再說"改進 content-pipeline"，Claude 會先讀這個文件，接上 Round 1 的進度。
不是從零開始，是從上次停下的地方繼續。 這就是 Bootstrap。
怎麼用
安裝
skill-evolve 是一個標準的 Claude Code skill。只有一個文件：SKILL.md。沒有腳本依賴，沒有配置。
# 一行命令安裝 git clone https://github.com/OrangeViolin/skill-evolve.git ~/.claude/skills/skill-evolve 或者手動把 SKILL.md 放到 ~/.claude/skills/skill-evolve/SKILL.md。
觸發
說"改進這個 skill"、“skill 效果不好”、“優化 skill”、"/evolve"都行。
也可以帶着一個 skill 的輸出來說"這不對"——一個真實失敗案例就是最好的起點。
兩種模式
完整循環：冷啓動 → 觀察 → 提煉模式 → 改寫 → 驗證。適合系統性改進。
快速模式：用戶帶着一個具體問題來，直接定位→改寫→試試看。適合小修。
和 skill-creator 的關係
兩者可以串聯：先 /skill-creator 出初版，再 /evolve 持續打磨。
背後的思維模型
三個反常識：
不是先設計完美 skill 再用，而是先用起來再從真實反饋中總結改進。 用戶的痛點比你的想象更準確。
不是一次性大改，而是每輪只改一件事。 改太多你分不清哪個改動起了作用，哪個引入了副作用。
不是改完就扔掉筆記，而是每輪的觀察和模式都保留下來。 它們是下一輪的燃料，也是未來新對話的上下文。
這三條——OTF、JIT、Bootstrap——不只適用於 skill 改進。它們是一種通用的知識工作方法論。
好 skill 不是設計出來的，是從使用中長出來的。
這句話同樣適用於 skill-evolve 本身。它也是 v0.1，也需要從真實使用中持續迭代。所以我非常期待你用了之後的反饋——哪裏好用，哪裏彆扭，哪裏完全沒用。
歡迎到評論區一起交流。若想更進一步，可以看菜單欄【加羣看我】加入 01fish 的摸魚羣，或者加我微信 18501790646，備註「元skill」。
調研 & 撰寫：AI（Claude） 主導 & 審校：01fish