Claude ELI5 Skill 是什麼？用大圖、少量文字把複雜概念講簡單
輸入 /eli5，Claude 就能把複雜主題整理成大圖、少量文字的 HTML 圖解。一次看懂安裝方式、應用情境與限制。
如果你曾請 AI「講簡單一點」，結果只得到另一篇更長的文字，Claude ELI5 Skill 想解決的就是這個問題。
它不是新的 Claude 模型，而是一個 Skill，也就是可重複使用的工作流程。輸入 /eli5 加上想了解的主題，Claude 就會把內容做成一個能用瀏覽器開啟的 HTML 圖解頁面，盡量使用大圖、少量文字與分步驟說明。
這個方法真正值得注意的地方，不是提示詞（Prompt）寫得多厲害，而是它強迫 AI 改變資訊呈現方式。對需要教新人、說明產品流程或跨部門溝通的人來說，這比再產生一份長篇摘要實用得多。
Anthropic 團隊近期常用的 /eli5 是什麼？
參與 Claude Code 工作的 Thariq Shihipar 在 X 分享，不少 Anthropic 同事近期常使用一個名為 ELI5 的 Skill。ELI5 是「Explain Like I’m 5」的縮寫，實際意思不是把讀者當成小孩，而是先假設對方完全不熟悉這個主題，再從最基本的角色與流程開始說明。
他公開的 Skill 核心指令很短：請 Claude 向完全不了解主題的人解釋，並用大圖、少量文字製作 HTML artifact。這裡的 HTML artifact，可以先理解成一個由 Claude 產生、能在瀏覽器開啟的圖解網頁。
使用方式也很直接：
/eli5 how does DNS work
/eli5 後面的文字就是題目。Claude 會讀取這段內容，再依照 Skill 裡的固定要求產生說明。
需要留意的是，eli5 目前收錄在 Anthropic 的 community plugin repository，也就是存放社群功能包的程式碼庫。這個 repository 表示其中的項目已通過自動安全掃描並獲准分發，但它仍屬於社群提供的 plugin，不是 Claude Code 的內建功能，也不是 Anthropic 正式推出的新產品。
實際效果如何？影片把 Discord bot 拆成一張張流程圖
Thariq 公開的示範不是用大量文字解釋程式碼，而是回答「Discord bot 如何運作」。頁面先用一句話交代全貌，再把網站、機器人、資料庫與 Discord 畫成幾個容易辨認的角色。
接著，內容用編號分段說明：網站收到動作後如何通知 bot、管理員如何核准遊戲，以及 bot 如何把卡片貼到正確的 Discord 頻道。每一段只保留讀者當下需要知道的資訊，箭頭則負責表達資料往哪裡走。
這種格式的優勢，是讀者不必先懂網站通知機制、資料欄位設計或後端處理路徑，也能先建立一張心智地圖。等他知道「誰通知誰、資料存在哪裡」，後面再補技術細節會容易許多。
不過，圖看起來簡單，不代表內容一定正確。若用它解釋公司內部系統，仍要由熟悉架構的人檢查角色、步驟與例外情況，不能因為版面清楚就省略事實驗證。
Claude Code Skill 是什麼？為什麼不直接貼 Prompt？
Claude Code Skill 是一個可重複使用的工作流程。它的核心通常是一個名為 SKILL.md 的 Markdown 指令檔，也可以搭配參考資料與 scripts，也就是可以執行的小程式。這些程式能處理只靠文字指令不方便完成的工作。
一般 Prompt 適合一次性的要求，Skill 適合會反覆出現的任務。只要安裝一次，之後就能用固定名稱呼叫，也能分享給同一個專案的其他人使用。
eli5 正好說明 Skill 不一定要很複雜。它的 SKILL.md 幾乎只做兩件事：固定「大圖、少字、完全新手」的輸出原則，再用 $ARGUMENTS 接收每次輸入的新題目。$ARGUMENTS 就是 /eli5 後面那串文字的代稱。
換句話說，這個 Skill 的價值不是藏了一套神祕演算法，而是把團隊認可的解釋格式保存下來。下一次遇到新主題，不必重新討論版型與讀者程度，只要更換題目即可。
Claude ELI5 Skill 安裝教學
對 Claude Code 使用者來說，最省事的方法是從 Anthropic 的 community marketplace 安裝。marketplace 是集中列出可安裝 plugin 的目錄，plugin 則是把 Skill 與相關設定包在一起的安裝單位。
先在終端機加入 repository：
claude plugin marketplace add anthropics/claude-plugins-community
接著安裝 eli5：
claude plugin install eli5@claude-community
安裝完成後，在 Claude Code 輸入：
/eli5 請解釋 OCR 閱卷系統如何從上傳考卷走到批改完成
如果指令正常載入，Claude 會依照題目產生 HTML 圖解。Plugin 公開資訊顯示目前版本為 1.0.0，作者是 Thariq Shihipar，程式內容採 MIT 授權。
這兩行安裝指令來自 community repository 在 2026 年 8 月 22 日提供的說明。若未來 marketplace 名稱或 Claude Code 指令更動，應以該 repository 的最新 README 為準。
哪些工作最適合用 /eli5？
新人 onboarding
新同事最難的通常不是記住每一個技術名詞，而是不知道整套系統有哪些角色。可以先用 /eli5 畫出使用者、前端、後端、資料庫與外部服務，再進入正式文件。
這會降低第一次理解的門檻，但正式的權限規則、失敗處理與資料流向仍要保留在工程文件中。圖解負責帶路，不負責取代規格。
PM 與工程溝通
PRD 常把功能流程寫得很完整，卻不一定讓所有人快速看出前後依賴。把登入、付款、審核或通知流程交給 /eli5，可以先產生一張討論底稿，協助團隊找出漏掉的角色與狀態。
這類圖最適合拿來開會，不適合直接當成最終系統設計。工程師確認過例外情況後，再把修正版放進文件，維護成本會比較低。
對客戶解釋技術產品
OCR、AI Agent、資料同步或資安流程都容易出現術語。/eli5 可以先把「輸入什麼、系統做什麼、使用者拿到什麼」畫出來，讓客戶不必先理解底層模型。
但如果內容涉及費用、法規、醫療、金融或資安承諾，圖解只能整理資訊，不能自行補上結論。關鍵數字與限制仍要回到正式條款或第一手來源。
自己學習陌生主題
面對 DNS、OAuth、向量資料庫或模型訓練流程時，先看角色關係，再讀完整文件，通常比直接從術語表開始容易。這也是 /eli5 最沒有導入成本的用法：挑一個你本來就熟悉的主題測試，先看 Claude 是否真的抓到重點。
怎麼讓產出的圖解更有用？
原始 Skill 刻意保持簡短，方便套用任何主題。不過，工作上的題目常有特定讀者與目的。呼叫 /eli5 時，可以把這些條件一起寫進題目：
/eli5 向第一次接觸 AI 閱卷的學校老師解釋：學生上傳考卷後，OCR、題目辨識、AI 批改與人工覆核如何合作。請把人工覆核放大呈現，並列出兩個可能失敗的地方。
這段題目比只寫「解釋 AI 閱卷」更好，因為它補上三個關鍵資訊：讀者是誰、想理解哪一段流程，以及哪些限制不能被漂亮的圖省略。
如果圖解要交給客戶或放進正式文件，建議再做一次人工檢查：每個角色是否正確、箭頭方向是否合理、是否漏掉失敗情境，以及文字有沒有暗示不存在的保證。這四項比版面是否好看更重要。
/eli5 的限制：簡單不等於完整
我對這個 Skill 的評價是中性偏多。它值得用在教學、產品 onboarding 與跨部門溝通，因為安裝與呼叫成本很低，也能快速產生一份共同討論的視覺底稿。
最大的風險是過度簡化。複雜系統往往有權限、例外、重試與資料一致性問題，這些內容很難同時符合「大圖、少字」。如果一張圖讓讀者以為流程永遠只有單一路徑，清楚的版面反而可能製造錯誤理解。
因此，我會把 /eli5 放在理解流程的第一層，而不是最後一層。先用它建立全貌，再回到正式文件、原始資料或程式碼確認細節。若團隊每次都要大幅重畫，代表這個格式不適合該主題，繼續使用只會增加維護成本。
常見問題
Claude ELI5 Skill 是 Anthropic 的內建功能嗎？
不是。它目前是 Anthropic community plugin repository 收錄的 plugin。該 repository 表示收錄項目經過自動安全掃描並獲准分發，但仍與 Anthropic-maintained official plugins 分開管理。
一定要會寫程式才能使用 /eli5 嗎？
不必修改程式碼就能呼叫已安裝的 Skill，但目前最直接的安裝方式是在 Claude Code 終端機輸入兩行指令。產出的 HTML 可以用瀏覽器開啟，使用者不必自己手寫網頁。
ELI5 真的代表要向五歲小孩解釋嗎？
不一定。這裡更接近「假設讀者沒有背景知識」。工作情境中最好直接指定讀者，例如新進工程師、學校老師或第一次使用產品的客戶，結果會比只寫年齡更準確。
/eli5 適合拿來做正式技術文件嗎？
適合當作導覽圖或第一層說明，不適合單獨取代正式技術文件。權限、例外處理、資料格式與安全限制仍需要完整記錄，並由熟悉系統的人確認。
結語：最有價值的不是 ELI5，而是把好方法做成 Skill
/eli5 看起來只是一句很短的 Prompt，但它示範了更值得學的工作方式：當團隊找到一種有效的輸出格式，就把它保存成可重複呼叫的 Skill。
對一般使用者來說，可以先用它把陌生主題畫成容易理解的流程。對團隊來說，真正的下一步是觀察哪些說明、檢查表與交付格式每天都在重複，再把這些經驗做成自己的 Skill。這比每次重新請 AI「寫清楚一點」，更容易維護，也更能累積成組織的方法。
