top of page

Gemini Gems 搬家實測:轉成 Skill、AI 工具與自動化流程

  • 作家相片: 小步
    小步
  • 8月16日
  • 讀畢需時 7 分鐘

最近的 AI 平台變動,提醒了我一件事:如果一個 Gem 只能存在 Gemini 的介面裡,那麼我擁有的究竟是一套工作方法,還是一個隨時可能改變的使用入口?


關於 Gems 可能退場的傳聞、10 月 20 日這個日期從哪裡來,以及個人 GPTs 最新的建立與發布限制,我會另外整理在免費文章中。這篇不再花篇幅討論消息真假,而是直接處理下一個問題:


如果今天要把 Gem 搬出來,它究竟可以變成什麼?

Gem 解決了一個很重要的問題:不需要每次重新輸入角色、背景與輸出規則,就能快速叫出一位熟悉特定任務的 AI 助手。


問題在於,Gem 的角色、工作規則、輸出格式與參考檔案,通常都集中在平台的設定頁裡。如果沒有另外整理與備份,當平台功能或使用資格改變時,就很難在其他工具中重建相同的工作方式。


真正需要擔心的不是 Gem 這個名稱是否消失,而是我們是否把自己的知識與工作方法,誤認成平台功能。


Prompt、Gem、Skill 與 Agent 有什麼不同?



Gem 常從「你是誰」開始;Skill 更在意「這件事怎麼做才算完成」


一份真正可用的 Skill,通常需要回答:


1. 什麼情況應該使用它?

2. 需要什麼輸入?

3. 有哪些步驟不能跳過?

4. 缺少資料時應該詢問,還是停止?

5. 成果必須符合什麼格式?

6. 如何檢查成果正確?

7. 哪些動作一定要由人確認?


Google 官方對 Skills 的描述也反映這個方向:Skill 可以在不同 Spark 任務中重複使用、依情境自動啟用,也能與其他 Skills 組合處理更複雜的工作。


不過,Gemini Skills 目前只在 Gemini Spark 中提供,而且有帳號、訂閱、地區與檔案格式限制,因此它還不能被視為所有 Gems 使用者都能立即採用的一對一替代品。


參考資料:


搬家第一步:用 Google Takeout 把 Gem 帶出來

在決定 Gem 要轉成什麼之前,第一步是先把現有資料帶出平台。


Google Takeout 做的是「打包」,不是「轉換」。它會先把 Gem 的設定與相關資料交還給我們,後面才有材料可以整理成 Project、Skill 或網站。


操作方式如下:

1. 前往 Google Takeout ,並登入建立 Gem 時使用的 Google 帳號。

2.在「選取要納入的資料」中按下「取消全選」。


3.找到並勾選「Gemini」。

4.按下「下一步」


5.傳送方式可選擇「以電子郵件傳送下載連結」。

6. 匯出頻率選擇「僅匯出一次」。

7. 檔案格式選擇 ZIP,再按下「建立匯出作業」。

8.打開Gmail下載資料。






封存檔完成後,Google 會寄出下載連結。這項作業可能需要數小時至數天,而且在提出匯出要求後才修改的內容,不一定會出現在這次封存檔中。


Takeout 解壓縮後,我實際拿到什麼?

解壓縮 Takeout 檔案後,會在資料夾裡看到兩個檔案:

- `gemini_gems_data.html`

- `gemini_scheduled_actions_data.html`



這次真正包含 Gems 資料的是 `gemini_gems_data.html`。

另一個排程檔案其實是空的,因為我的帳號當時沒有相關資料。


這裡要特別說明: Takeout 會把所有的 Gems 全部集中在同一份 HTML 裡。每個 Gem 都以三個欄位呈現:


- 名稱
- 說明,也就是原本設定的完整指令
- 檔案,也就是曾經加入 Gem 的附件連結














收到 Takeout 後,建議做以下三項檢查與整理:

1. 逐一確認 Gem 是否完整

先核對 HTML 中的 Gem 數量與名稱,確認原本的Gems 都有出現,再檢查每一個 Gem 的指令開頭與結尾,避免內容在匯出時被截斷。

2. 另外處理附件連結

Takeout 檔案裡出現的是附件連結,不是已經下載好的實體檔案。因此,如果連結仍可使用,就要另外開啟並下載附件。

3. 把 HTML 轉成適合後續使用的格式

Takeout 提供的 HTML 適合用瀏覽器查看,卻不方便搜尋、分類。


因此,我會建議轉成JSON及Markdown格式,並整理成以下幾個欄位:

- Gem 名稱

- 完整指令

- 分類

- 附件名稱

- 匯出日期


轉成這兩種格式的目的: JSON,讓網站可以讀取、搜尋與篩選; Markdown ,方便日後用文字編輯器閱讀、修改或交給其他 AI 工具使用。


這一步才讓 Google Takeout 從一份「看得到的備份」,變成後續能繼續加工的資料。

Gem 離開 Gemini 後,可以轉成哪些形式?

Gem 離開原本的平台後,大致可以轉成六種形式:


  1. 保留對話使用方式的 Project

  2. 把工作步驟整理成可重複使用的 Skill

  3. 讓一般使用者直接操作的 獨立網站或小工具

  4. 接收資料後自動執行的 自動化工作流程

  5. 以文件查詢為主的 知識型工作空間

  6. 集中保存所有指令與附件的 私人 AI 指令資產庫


要選哪一種,不是看 Gem 的名稱,而是看它真正保存的是對話角色工作規則知識檔案,還是明確的輸入與輸出

以我自己的Gems為例,這次從 Google Takeout 整理出的 6 個 Gems,我是這樣分類:


這不是要把 6 個 Gems 硬分配到 6 種形式,而是先找出每一個 Gem 的核心價值。有些 Gem 可以有兩種以上的合理去向,最後仍要看使用者、分享方式與維護成本。


三個實測:Project、Skill 與網站

實測一:把 Gem 轉成 Project方式

如果原本的 Gem 主要由「固定指令+參考檔案」組成,而且平常仍是透過對話使用,最接近的搬家方式,是把它轉成其他 AI 平台的專屬專案。


實際搬移時,可以這樣對應:


- 將 Gem 的角色設定與工作規則,放進專案指令區。

- 將原本上傳給 Gem 的知識檔案,加入專案的參考資料。

- 之後直接在這個專案裡開啟對話,繼續執行原本的工作。



這種方式最接近原本使用 Gem 的感覺,搬移速度快、學習成本也低。

不過,它仍然只是把內容移到另一個平台,不能獨立發布成工具,也仍有受到平台政策影響的可能。


以下是將Gem轉至ChatGPT專案的例子:

  1. 將Gem的「使用說明」複製到ChatGPT專案的「指令」。

  2. 原本Gem中的資料檔則放到ChatGPT的「資料來源」。

  3. 實際執行後,兩者的效果確實是相當的。

Gemini Gem

ChatGPT 專案

執行結果

點我放大瀏覽




實測二:把Gem 轉成 Skill

Skill 不是替 Gem 換一個名稱,而是重新整理工作方法。


除了原本的角色與指令,還要補上:


- 清楚的觸發條件

- 必要輸入

- 執行步驟

- 缺漏資料的處理方式

- 格式與驗證規則

- 需要人工確認的關卡


適合:


- 資料轉換

- 文章改寫

- 固定格式產出

- 文件整理

- 設計或程式製作流程


Skill 的最大價值,是同一項能力可以被不同任務與 Agent 重複使用,而不是只能待在一個固定聊天視窗裡


這個實測是使用 Takeout 裡的「小步資源採集器 (Wix CSV 轉換引擎)」。

這個Gem原本的功能是我會給它一個網址,它會去讀取網頁內容、擷取標題與描述、判斷分類,最後輸出符合我定義好格式的 CSV檔,這個檔案是我要用來上傳到小步學習網站的資源下載區的資料庫使用。


這個轉換的過程,其實是一連串跟Codex的對話,並不是只複製原本Gem指令,還要明確補上:

- 什麼情況應該啟用這個 Skill。

- 使用者必須提供哪些網址。

- 網頁無法讀取或缺少圖片時怎麼處理。

- 分類只能從哪些選項中選擇。

- CSV 的欄位順序與格式。

- 產出後要如何檢查欄位、引號與編碼。

- 寫入或匯出前,哪些內容需要人工確認。


將Gems轉成Codex Skill成果



實測三:把 Google Takeout 資料轉成網站

第三個實測不是轉換單一 Gem,而是直接使用 Google Takeout 資料,把整批 Gems 做成一個「Gem 私人指令庫網站」。


當時的處理流程是:

1. 從 Takeout 下載資料後。

2. 整理成結構化 JSON,並分成「網站與資料」、「影音製作」、「故事創作」、「簡報與研究」四類。

3. 建立可以分類、搜尋與閱讀完整指令的網站介面。

4. 加入一鍵複製、下載單一 Gem,以及整庫匯出 JSON/Markdown 的功能。

5. 附件只保留檔名索引,不公開可能含存取資訊的原始網址。


最後得到的不是另一個聊天機器人,而是一個可以自己管理、搜尋與再次匯出的 AI 指令資產庫。它不會直接執行每一顆 Gem 的任務,卻能先把散落在平台裡的設定收回來,成為後續 Project 與 Skill 轉換的共同基地。

原本Gems

轉成網站


三種實測解決的問題不一樣


最後真正要保存的是什麼?


不要只保存 Prompt。


一套能遷移的 AI 工作方法,至少應包含:

1. 任務目的

2. 角色與判斷原則

3. 輸入資料規格

4. 執行步驟

5. 知識與模板附件

6. 輸出格式

7. 驗證標準

8. 一份已知可用的測試案例


只要這些內容還掌握在自己手上,今天可以把它做成 Gem,明天可以轉成 Skill,後天也能變成網站或自動化流程。


結語

Google Takeout 可以把 Gems 的原始資料帶出來,但真正的搬家,是重新決定這些內容接下來要怎麼被使用。


真正可以長期保存的,不是某個平台裡的按鈕,而是任務目的、工作規則、參考資料、輸出格式與驗收方式。只要這些內容仍掌握在自己手上,就能隨著工具改變,重新組合成下一種形式。

 
 
 

留言


正在確認文章閱讀權限……

這篇文章收錄於小步 AI × 實用新知庫

登入後,系統會確認你是否擁有「Gemini Gems 搬家實測:轉成 Skill、AI 工具與自動化流程」的閱讀權限。

​這篇文章你會看到...

Gem 不只是幾段 Prompt,而是你長期累積下來的工作方法、規則與知識。

這次我把自己實際常在使用的 6 個 Gemini Gems 全部帶出來重新整理,並挑選其中幾個案例,實際測試如何轉成 Project、Skill 與網站。

解鎖後,你會看到我實際怎麼處理原始資料、怎麼判斷不同 Gem 適合搬去哪裡,以及三種轉換方式各自能解決什麼問題。

如果你也累積了不少 Gems,這篇會帶你思考一件更重要的事:如何把原本綁在平台裡的 AI 工作方法,真正收回自己手中。

預覽內容~


將Gems轉成Codex Skill~















將Gems轉成網站~

如果感覺這篇文章對您有幫助,可以請小步喝咖啡喔~

謝謝您支持小步繼續用心創作。☕ 請小步喝杯咖啡

  • Line
bottom of page