shader-dev

shader-dev 技能總覽

shader-dev 是用來做什麼的

shader-dev 是一個實用的 GLSL shader 技能，專門把視覺想法轉成即時效果，特別適合 ShaderToy 風格的創作。當你想要建立或除錯 ray-marched 場景、SDF 組合、光照、程序化材質、粒子、流體運動、後製，或攝影機效果，但又不想靠猜測來決定該用哪種 shader 技巧時，它特別有幫助。

誰應該使用它

shader-dev 最適合圖形開發者、技術美術、探索動態介面表現的 UI 工程師，以及被要求根據粗略視覺簡報產生 shader 程式碼的 AI agent。當任務重點是「把這個效果用 GLSL 做出來」，而不是「解釋理論」時，它尤其實用。

它有什麼不同

shader-dev 的核心價值在於技術路由：它把許多 shader 主題整理成有結構的路徑，而不是把所有視覺需求都丟進同一個泛用提示裡。這表示它能更快把像「發光隧道加霧氣和柔和陰影」這類需求，收斂到正確的構成要素，而不是只能給出一次性回答。它的涵蓋範圍也夠廣，同時兼顧合成與渲染層面的問題；當卡住的點不只是形狀生成，還包括鋸齒、陰影和 buffer 工作流程等品質議題時，這點特別重要。

如何使用 shader-dev 技能

正確安裝並觸發它

使用 npx skills add MiniMax-AI/skills --skill shader-dev 安裝，然後用聚焦的需求來呼叫，例如 /shader-dev create a raymarched SDF crystal scene with rim lighting and soft shadows。這個技能是依據使用者的參數來運作，所以提示詞應該描述視覺目標、目標平台與限制，而不只是點出某種技巧名稱。

給它正確的輸入形狀

好的輸入通常會包含：

• 效果類型：ray marching、SDF、fluid、particle system、post-processing
• 目標環境：ShaderToy、WebGL，或其他 GLSL runtime
• 視覺意圖：「乾淨的 UI 背景」、「電影感霧氣」、「遊戲感霓虹隧道」
• 限制：效能、手機支援、single-pass 與 multipass、不要貼圖、不要 3D 資產

像「做得酷一點」這種模糊需求，會逼技能自己猜。相較之下，「建立一個相容 ShaderToy 的 SDF 走廊，具備動畫面板、環境遮蔽與抗鋸齒，並針對即時用途最佳化」這種更強的需求，能給它足夠細節去選對技術路徑。

先讀對的檔案

先從 SKILL.md 看起，確認呼叫方式與路由，再查看最相關的 techniques/ 檔案，之後再進一步看更深入的 reference/ 頁面。例如：

• ray-marching.md：球體追蹤場景
• sdf-3d.md 或 sdf-2d.md：物件建構
• lighting-model.md：光照選擇
• procedural-noise.md：有機變化
• post-processing.md：bloom、tone mapping 或螢幕空間潤飾

當你需要實作細節、數學推導或邊界情況處理時，再使用 reference/ 檔案。這樣可以讓第一輪查閱保持快速，也避免一開始就讀到與需求無關的 shader 理論。

能提升輸出品質的工作流程

一個好的 shader-dev usage 流程是：先辨識核心渲染方式，確認目標 runtime，先請它做主要效果，再在基底場景可用之後疊加輔助效果。舉例來說，先產生幾何與攝影機，再加入陰影、AO、anti-aliasing 和色彩分級。這個順序能降低 shader 程式碼出錯的機率，也讓除錯更容易。

shader-dev 技能 FAQ

shader-dev 只適用於 ShaderToy 嗎？

不是。這個技能在精神上相容 ShaderToy，但底層的 GLSL 概念也可以套用到其他即時 shader 環境。如果你的引擎使用不同的 uniforms、buffer 設定或 texture 規則，請提早說明，讓輸出符合你的 runtime。

什麼情況下不該用 shader-dev？

如果你需要的是簡單的靜態漸層、CSS 動畫，或是不依賴 GLSL 的非 shader UI 效果，就可以跳過 shader-dev。它最有價值的場景，是最終輸出取決於 shader 數學、渲染管線或即時視覺合成時。

shader-dev 會比泛用提示詞更好嗎？

通常會，因為 shader-dev skill 提供的是具技術感知的指引，而不是逼模型從零推斷正確的渲染策略。當需求涉及多個互相作用的系統時，提升最明顯，例如 SDF 幾何加光照再加 buffer-based feedback。

shader-dev 對新手友善嗎？

可以，只要你用平實語言描述想要的外觀，並讓技能負責技術路由。新手最容易得到好結果的方式，是先從一個看得見的目標開始，例如「做一個霧氣傳送門」或「做一顆發光的 UI 球體」，而不是一次要求整套 production-grade shader。

如何改進 shader-dev 技能

先說視覺目標，再說技術手法

最好的 shader-dev guide 輸入，會先描述場景結果，再談數學。像「一個緩慢流動的霓虹水面，帶有地平線霧氣和反光高光」就比只說「使用 domain warping」更好，因為技能能把效果對應到正確的技術組合。

補上最容易讓 shader 壞掉的限制條件

如果你想要更好的結果，請直接說哪些條件必須成立：

• 是否要相容 ShaderToy
• single-pass 還是 multipass
• 效能預算
• 能否使用貼圖
• 輸出是 2D、3D 還是 screen-space
• 動畫是要低調、可循環，還是可互動

這些細節很重要，因為很多 shader 失敗不是視覺失敗，而是管線不相容。

從基底迭代，不要一開始就追求最終質感

在 shader-dev for UI Design 情境下，先要求最簡版效果，再逐步精修。比較穩定的改進順序是：基礎形狀 → 動態 → 光照 → anti-aliasing → 色彩配置 → post-processing。如果第一版輸出不對，先修正渲染方式或場景結構，再談風格調整。

用技術語言回饋失敗點

如果結果太吵、太慢、太平，或太雜，請直接說明，並把問題和症狀連起來。例如：「降低 temporal flicker 並簡化 SDF 細節」就比「做得乾淨一點」更有用。這樣技能就能調整採樣、形狀複雜度、陰影處理或色彩表現，而不是隨機重做風格。