Google 正式把 Gemini 側邊欄的 Gems 淘汰，改為能在同一對話中隨叫隨到的「Skills」，其實自己的感覺是這個方向非常合理。
過去不管是自訂 Gem 還是其他平台的客製化助理，本質上都很像一組預設好的工作指令。但把它們關在獨立的對話視窗裡，就像把工具鎖在不同的抽屜；只要遇到跨步驟的任務，就得反覆切換、複製貼上，最後很多工具就這樣被遺忘在角落。轉成隨插即用的 Skills，不管是對應特定單一任務，還是串接長工作流程，在工具整合上確實順手許多。
新聞重點
根據 Android Authority 的報導，Google 放棄了過往各自獨立成「迷你 App」的 Gems 機制，改推全新的 Skills 功能。
這項改變最大的核心在於打破對話孤島。使用者現在可以在日常的同一個對話串中，直接透過輸入斜線（/）快速叫出指定的技能；關鍵的是就是這個方式擊讓它具備串聯能力（Stackable），能將多個技能前後接續執行。此外，Gemini 也支援直接用自然語言請 AI 協助生成技能指示，或在後台手動精準設定。
我的觀察與心得
雖然產品架構的演進符合工作流邏輯，但在實際測試調用後，我感受到的卻是一點點感到可惜的落差。
功能架構成熟，但偶發的「掉漆」很傷信任
在一次實際使用 Skill 時，我發現模型並沒有完全按照我預先寫好的規則執行，甚至偶爾會出現脫離 Prompt 框架、或是跳回「我只是一個語言模型」這類防衛性罐頭回應的狀況。
這並不是說 Gemini 表現差，老實說，它在反應速度與多模態處理上的優勢依然相當出色。也不是指它每一次都不照做，而是在一個已經被包裝成成熟系統功能的機制下，有時候依然會冷不防地出現細微漏球與不穩定。這種不確定性，在日常需要穩定產出、依賴固定格式的工作流中，會讓人產生「這一次到底能不能跑對」的遲疑，對自動化流程的信任感自然大打折扣。
工具設計越想包山包海，模型越容易消化不良
這也讓我回頭思考目前各大平台對 Skill 的設計建議：具體、明確、不要冗長。
當我們把功能從獨立視窗搬進長對話串時，模型同時要消化先前的歷史紀錄、當下的提問，還要即時解析載入的規則。如果一個 Skill 的 Prompt 寫得太肥大或邏輯太繞，模型就更容易在執行細節時分神脫框。面對偶發的不穩定，現階段最務實的做法不是期待模型突然變得百分之百嚴謹，而是主動把工具拆解成更精準、單一的小組件，降低它出錯的機率。
這件事值得繼續觀察什麼
- 動態載入下的指令權重分配：隨著技能可以在同一對話串中隨意插拔甚至疊加（Stacking），Google 如何在模型底層確保使用者當前指令、對話上下文與 Skill 規則之間的優先級不混亂。
- 模型遵循長規範的容錯率：Gemini 後續在基底模型的指令遵循（Instruction Following）能力上能否進一步收斂，減少莫名脫框或觸發安全罐頭回覆的頻率。
- 模組化工具的普及度：從獨立 Chatbot 走向斜線指令的小型工作流，是否會真正帶動一般使用者自建多步驟自動化的習慣，抑或依然停留在少數進階使用者的日常中。
原文來源：Android Authority｜Google just replaced Gemini Gems with Skills. Here's how to use and master them
