Banger Explainer — 讓教學內容在分享中存活 是做什麼的？
教學內容常常面臨兩難：語氣過於強烈，讀者喜歡卻無法複述；規格過於詳細，變得像文件一樣沒人想分享。這套程序將每個「註冊」（指內容的不同面向）分配給它真正擅長的部分。
優先載入
${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md— 受眾設定檔與創作者的限制條件。${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md— 框架/載體分割法與載體紀律。這是核心參考。${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md— 動態門檻，在交付前執行。${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.md中的目標平台章節。
新鮮度門檻
在使用此技能或平台手冊中的任何平台基準、演算法聲明或數值效能聲明之前，請檢查 references/research/source-ledger.md 是否有未過期的支援。如果支援遺失或已過審查期限，請執行 banger-research，將該聲明標記為未驗證，或將其省略。
步驟 1：命名機制
為自己寫一句話，而不是寫給讀者：讀者讀完後會理解什麼他們原本不懂的事？ 每個作品只討論一個機制。如果需要兩句話，那就是兩個作品。
然後，命名讀者現在可能抱持的錯誤模型。強大的技術內容是用正確模型取代錯誤模型，而不是填補空白。那個錯誤模型通常就是鉤子。
步驟 2：檢查證據
在起草之前，請先命名：
- 實物（儲存庫、檔案、提交、螢幕截圖、錯誤文字、基準），
- 實際發生了什麼，包括失敗的部分，
- 尚未測試的內容，並清楚說明。
如果沒有實物，這是評論文章，而非解說。請將其路由到 banger-threads 或 banger-longform-written，並說明原因。
步驟 3：設定解釋深度
使用 voice-and-audience.md 中的受眾設定檔。主要原則主導：詞彙必須符合受眾的實際專業程度。
- 非專業受眾 — 在提及每個基礎概念時，立即用簡單的比喻解釋。展示確切的畫面、提示和結果。載體內容更長，步驟更小。切勿居高臨下。
- 專業從業人員受眾 — 可以使用業內簡稱，過度解釋會浪費他們的時間。將篇幅用於權衡取捨、失敗模式以及你下次會如何改進。
步驟 4：按分割法起草
框架（作者語氣，而非清晰度規則）：
- 一個鉤子，專注於特定的錯誤模型或特定的痛點，而不是類別。
- 故事：你在做什麼、什麼地方出錯、付出了什麼代價。
- 判斷：你現在的看法，以及你的信心程度。
- 符合平台特性的行動呼籲。
載體（技術清晰度）：
- 每個概念使用一個名稱，並在整篇文章中保持一致。
- 每句一個想法，約 25 個字，步驟描述則更接近 20 個字。
- 主動語態，並指定主體：「解析器讀取檔案」。
- 使用動詞，而非名詞化。展示數字，而非宣稱品質。
- 具體的實物：真實的指令、真實的錯誤訊息、真實的路徑。
縮寫、插話、幽默和意見可以保留在載體中，只要它們有其價值。紀律不等於扁平化。
步驟 5：平台形狀
- X（Twitter）或 Bluesky 串文 — 每則貼文一個機制步驟。框架放在第一則和最後一則貼文。載體貼文盡可能附上程式碼區塊或螢幕截圖。長度切勿超過機制所需。
- LinkedIn — 前 150 個字元內放入鉤子，採用錯誤模型框架，然後用三或四個短段落呈現載體重點。結尾加上判斷和一個問題。正文中不放連結。
- 電子報或 Substack — 每個機制步驟一個標題，每個步驟搭配圖表或程式碼區塊，拉出判斷作為引文。提供從載體中提取的獨立註解，而非框架。
- 影片說明或文件風格文章 — 載體主導，框架縮減為兩行。
- Facebook 社團 — 不使用此程序。請路由到
banger-longform-written，以問題引導並保持簡短。
步驟 6：交付前驗證
執行 writing-quality.md 門檻，然後檢查以下項目：
- 讀者能否在關閉文章後重述這個機制？
- 每個概念是否都只用一個名稱稱呼？
- 是否有任何地方用品質宣稱取代了具體展示？
- 框架聽起來是否仍像作者親口說出來的話？
- 每個數字、引文和結果是否能追溯到真實的實物？
- 創作者的限制條件（禁用標點符號、詞彙、語氣）是否滿足？
輸出格式
以最終成品開頭，可直接貼上，並根據平台調整格式。然後依序列出：
- 機制說明句以及它取代的錯誤模型，
- 每個聲明所追溯的實物，
- 任何標記為未驗證的內容，
- 下一步需要的核准。
起草是自由的。發佈、排程和推廣需要創作者逐項明確核准。