跳到主要內容

部落格

不定期分享最新資訊文章

  • article-Custom GPT 要退場了,真正值得學的不只是 Plugin:開始打造自己的 Skill Library

    2026/10/2

    AI工具 ChatGPT AI Agent
    Custom GPT 要退場了,真正值得學的不只是 Plugin:開始打造自己的 Skill Library

    最近看到《數位時代》談到 Custom GPT 遷移 Plugin,我第一個想到的不是「Custom GPT 要消失了」,而是 OpenAI 正在把工作流程、工具和可重複使用的指引放進同一套架構。 如果你也在研究 AI Agent、Codex、Claude Code、Skill 或 MCP,這次轉變值得關注。不過我認為最值得學的不是趕快做一個 Plugin,而是把平常怎麼工作的經驗整理出來,讓 AI 能在類似任務中重複使用。 以前我們常想:「我要做一隻幫我寫文章的 GPT。」現在可以多問一題:「我寫文章時有哪些步驟、判斷和檢查,值得整理成一套工作方法?」 Custom GPT 何時退場?先看適用帳號與公告依 OpenAI 目前的Custom GPT 退場與遷移說明,Custom GPT 預計在 2026 年 12 月 11 日退場;符合條件並取得核准延期的 Enterprise 工作區,時程可延至 2027 年 2 月 11 日。官方也提醒,遷移和功能開放時間可能依帳號或工作區而不同,應以自己的產品通知為準。 另一個容易混淆的日期是 2026 年 10 月 26 日。依目前 FAQ,這是受影響 Enterprise 工作區預計停止建立新 GPT 的日期;這項建立限制不等於所有方案都在同一天停止建立。官方公告可能調整,準備遷移前最好再看一次自己帳號收到的通知。 已遷移的 GPT 在適用的退場日前仍可使用,但會變成唯讀。也就是說,遷移不是按下按鈕後就能永遠保留原本的編輯方式;先確認重要指示已更新,再遷移和測試會比較穩妥。 遷移會搬什麼?哪些要另外處理?依官方規劃的遷移流程,原本的 GPT 指示會變成 Plugin 裡的 Skill,Knowledge 檔案會複製為參考檔案,已連接的 App 則會加入 Plugin。這讓原本集中在一隻 GPT 裡的內容,開始拆成工作流程指引與外部工具兩個部分。 但遷移不會完整保留所有東西: Custom GPT 原有內容 遷移後的安排 需要留意的地方 Instructions 變成 Skill 檢查指示、範例與輸出要求是否正確 Knowledge Files 複製到 Plugin 的參考檔案 確認檔案內容與引用方式都符合原本用途 已連接的 App 加入 Plugin 的 App 仍要確認帳號授權、工作區權限與可用功能 指定模型 不會隨遷移保留 重新檢查替代工作流程使用的模型 Custom Actions 不會自動遷移 評估現有 App,或另行重建 MCP 整合並測試 對話紀錄與分享設定 不會搬到新 Plugin 確認哪些人需要存取新版本,並重新安排分享 所以,不要把遷移想成「GPT 按一下就變成 Plugin,而且每個地方都一樣」。比較實際的做法是把 GPT 當作一份流程草稿:盤點內容、確認缺漏,再驗證新的 Skill 和工具能不能完成原本的工作。 Plugin、Skill、App 和 MCP 怎麼分工?可以先用這幾句話理解: Skill 說明工作應該怎麼做,例如先蒐集哪些資訊、如何判斷例外、最後用什麼格式交付。 App 讓 ChatGPT 或 Codex 連接外部服務與資料,例如雲端文件或工作平台;連線仍受帳號授權和工作區權限限制。 MCP 是提供模型工具、即時資料與受控動作的一種介面。MCP 服務提供「可呼叫什麼」,Skill 則可以描述「何時呼叫、依什麼順序、結果不完整時如何處理」。 Plugin 可以把一個或多個 Skill、連接的 App,以及相關設定組合成可安裝與重用的工作流程套件。有些 Plugin 只有 Skill,不一定要連 App。 Agent 根據任務與可用能力判斷怎麼進行,再呼叫需要的 Skill 和工具。 這些概念有關聯,但不該直接畫上等號。OpenAI 的Plugin 說明指出,Plugin 可以包含 Skills、連接的 Apps 和其他設定;Skills 開發文件則說明,Skill 能為 MCP 工具提供可重複使用的流程指引。Skill 也可以在不連接 MCP 的情況下工作。 在支援 Skills 的 ChatGPT 帳號中,已安裝的 Skill 可能在適合時由 ChatGPT 自動使用;功能開放仍依產品、方案與工作區設定而異,也不代表每次對話都會呼叫同一個 Skill。官方 Skills 說明有列出目前的開放條件與使用方式。 舉例來說,一個客戶預約 Skill 可以寫下:先判讀需求、查看客戶紀錄、列出可選時段、等使用者確認後才建立預約。查詢行事曆或寫入 CRM 則需要相應的 App 或工具;流程指引本身不會憑空取得服務權限。 Skill 不只是把 Prompt 存成檔案Prompt 通常是在描述「這一次要做什麼」。SOP 把反覆工作的步驟和檢查條件整理下來。Skill 則可以把流程、判斷方式、範例和參考資源包成一份,讓 AI 在遇到相似任務時能重複使用。 以部落格寫作為例,單次 Prompt 可能只說「幫我寫一篇文章」。成熟的工作方法還會包含: 文章要給誰看,解決什麼問題? 如何確認事實、保留來源與區分推論? 標題、段落和 FAQ 要符合什麼格式? 哪些語氣或說法要避免? 交稿前要檢查哪些欄位與連結? 這些規則如果每次都要重新貼上,就還是一次性的指令。把它們整理為可呼叫、可維護的流程後,才開始接近 Skill。 我會把這段演進理解成: 1Prompt → SOP → Skill → Skill Library → Plugin 需要操作外部服務時,再接上 App 或 MCP。這不是每個人都必須照著走的產品安裝順序,而是把個人經驗整理成可重用能力的一種方法。我先前也寫過如何從 Prompt 整理出自己的 Skill Library,這篇則聚焦在 Custom GPT 遷移後,這些工作方法要如何拆開與驗證。 為什麼我開始整理自己的 Skill Library?我前陣子算了一下自己的環境,Skill 加 Plugin 指令已經裝超過一百個。工具多了,不代表 AI 就更懂我;如果沒有自己的流程與判斷準則,裝再多別人的 Skill,也只是多了一堆尚未融入工作的選項。 真正值得留下來的,常常是每天會用到的方法:我怎麼研究工具、準備課程、規劃簡報、整理客戶需求、寫文章,還有哪些容易出錯的地方。這些經驗可以逐步整理成一個自己的 Skill Library,例如: 123456789101112131415161718享哥 Skill Library├── Writing│ ├── blog-writing│ ├── facebook-post│ └── course-copywriting├── Teaching│ ├── course-outline│ ├── slide-manifest│ └── hands-on-lab├── Research│ ├── fact-check│ └── tool-research├── Video│ ├── short-video-script│ └── storyboard└── Coding ├── vibe-coding └── deployment-check 這是一份可以逐步發展的示意清單,不必一開始就把所有工作分類完成。先找出一件高頻、步驟穩定、自己常要重新解釋的工作,寫清楚輸入、判斷、例外與輸出,再用實際任務修正。 將來真正有價值的,可能不是一份幾千字的 Prompt,而是把多年工作經驗整理成 AI 可以理解、重複使用,也能檢查結果的工作流程。房仲可以整理房源分析與客戶跟進;會計師可以整理財報閱讀與文件檢查;講師可以整理課程規劃與實作設計。這些例子都要從自己的實際流程開始,不能只套用別人的模板。 Custom GPT 遷移前,先做這五件事1. 盤點自己建立或依賴的 GPT列出 GPT 的用途、使用頻率、維護者和需要使用它的人。幾乎沒在用的,可以先不遷移;只是一段簡單 Prompt 的,可以先保存指示;每天工作都會用到、含有穩定流程的,才值得花時間測試替代方案。 2. 拆出流程、資料與工具把 Instructions 中的步驟、判斷、例外和輸出規格整理出來,再分別核對 Knowledge 檔案、App 連線與 Custom Actions。尤其有 Custom Actions 時,要先確認新的 App 或 MCP 整合是否具備需要的功能,不要假設舊 API 串接會自動保留。 3. 在遷移前完成必要編輯官方說明指出,遷移會使用 GPT 最新的已發布版本;未發布的草稿修改不會直接搬過去。需要保留的規則和檔案,先整理並確認版本,再開始遷移。 4. 用熟悉任務和困難案例測試先用平常最常做的任務檢查替代 Plugin 是否選對 Skill、引用到預期的參考檔案、產出正確格式,再拿一個較難的案例測試例外處理。若有連接 App,也要另外檢查授權、可讀寫範圍和動作確認設定。 5. 重新確認分享與權限遷移不會自動把原本 GPT 的分享設定帶到 Plugin。個人 Plugin 預設為私人,讓同事或客戶使用前,要確認他們能安裝、連線並取得需要的權限。 新手不用一次學完 Plugin、MCP 和 Agent如果這些名詞讓人覺得太多,我會建議按照自己的工作慢慢累積:先把需求寫清楚,再把常做的工作整理成 SOP;SOP 穩定之後,挑一段做成 Skill。當工作需要讀寫外部資料時,再評估 App 或 MCP;需要把多項流程組合、分享或提供安裝時,才考慮 Plugin。 至於 Agent,則是協調模型、Skills 與工具完成任務的執行方式。可以先從一個可重複驗證的小流程開始,不必為了跟上名詞而把每一層都裝齊。 真正值得累積的是可執行的經驗Custom GPT 的遷移提醒我們:一個好用的 AI 助手,不只有幾句 Instructions。它可能還包含參考資料、工具連線、權限設定,以及人們多年累積的判斷方式。 Plugin 是把工作能力組合與分享的容器;Skill 承載可重複使用的流程;App 和 MCP 提供連接資料與操作工具的能力。對我來說,最值得先做的仍是把「自己怎麼工作」整理清楚。Prompt 可以告訴 AI 這一次做什麼,而一套經過檢查、持續修正的 Skill,才能把經驗帶到下一次相似的工作裡。 常見問答 (FAQ)Q1:Custom GPT 什麼時候會停止使用?OpenAI 目前規劃 Custom GPT 於 2026 年 12 月 11 日退場;符合資格並取得核准延期的 Enterprise 工作區,規劃日期為 2027 年 2 月 11 日。時程可能依帳號與工作區公告調整,請以自己的產品通知為準。 Q2:遷移到 Plugin 後,原本的 GPT 內容會全部保留嗎?不會。依目前遷移說明,Instructions 會成為 Skill、Knowledge Files 會成為參考檔案、已連接的 Apps 會加入 Plugin;指定模型不會保留,Custom Actions、對話紀錄與分享設定也不會完整遷移。 Q3:遷移後的 Plugin 會和原本 GPT 完全一樣嗎?不能假設兩者完全相同。官方建議使用熟悉的任務和較困難的案例測試 Skill 選擇、參考資料、輸出格式與工具整合,確認行為符合需求後再依賴新版本。 Q4:Skill 一定要連接 App 或 MCP 才能使用嗎?不一定。Skill 可以只提供流程指引、範例和參考資源;只有需要查詢外部資料或執行服務動作時,才需要適當的 App、MCP Server 或其他工具,而且仍受帳號與工作區權限限制。 Q5:如果我的 GPT 使用 Custom Actions,遷移前要做什麼?先列出每個 Action 使用的服務、輸入資料與必要動作,再確認是否有合適的 App;若需重建 MCP 整合,要分開設計並測試。Custom Actions 不會自動遷移,因此在替代方案完成驗證前,不要假設原本的 API 流程已經可用。 延伸閱讀 OpenAI:Custom GPT 退場與遷移 FAQ OpenAI:ChatGPT 中的 Skills OpenAI:ChatGPT 中的 Plugins 從 Prompt 到 Skill Library:如何打造自己的 AI 工作能力庫

  • article-ChatGPT Plugin 這波,我想先丟 5 個產品上去測水溫

    2026/10/2

    AI工具 ChatGPT 商業策略
    ChatGPT Plugin 這波,我想先丟 5 個產品上去測水溫

    最近看到有人把 ChatGPT 裡的工具生態,比喻成早期的 App Store 或 Facebook 應用程式。這個類比未必代表它們會走向同一種結果,但我看完後開始想另一件事:我手上是不是早就有很多可以重新包裝的產品? 我不是想直接 All in,也不想先猜哪一個一定會紅。我比較想趁著做產品的成本降低,挑幾個真實工作裡反覆出現的需求,試著放進新的對話入口裡測一輪。 這篇說的「Plugin」,先把名稱講清楚我這裡先用「Plugin」當一般說法,指的是讓使用者在 ChatGPT 對話裡叫得動的工具或工作流程。實際開發時,產品形式和上架流程要先分清楚:OpenAI 現行文件把 Plugin 描述成可組合 Skills、連接 App 等能力的工作流程;開發者也可以透過 Apps SDK 建立在 ChatGPT 中運作的 App,並了解如何提交到 ChatGPT app directory。OpenAI 的 Plugin 說明 與 Apps SDK 介紹 是兩條值得先讀的官方資料。 官方說明也提到,ChatGPT 會在相關情境使用已安裝的 Plugin,並可能在對話中推薦 Plugin。這讓我想到一個新的產品入口:使用者先說出需求,對話工具再協助他找到能完成工作的能力。**這是一個值得驗證的可能性,不代表每支產品都會被推薦或自然取得流量。**產品能否上架、被看見、被使用,仍要看平台當時的規則與實際數據。查看 Plugin 的使用與推薦方式。 我以前做過的工具,換個角度看都像產品雛形這一兩年,我為了課程、客戶和自己的工作,做過不少小工具: 個資去識別化工具 LINE OA 預約系統 客戶名單整理與報名資料處理 活動核銷文件整理 講師查詢系統 報價、請款和行政文件 Google Sheet 自動化與 AI 客服 B2B 名單開發流程 以前我會把它們分成 Vibe Coding 專案、小型 SaaS,或課程案例。現在我開始想:如果使用者不用先找到我的網站,而是先在 ChatGPT 說出需求,這些工具能不能從新的入口被找到? 我不是說工具做完就能自動找到客人。對 SaaS 來說,產品開發常常只是第一關;接下來還要面對 SEO、廣告、社群、內容行銷、業務開發和留存。若一個工具能進入使用者本來就在工作的對話情境,也許可以減少「先知道網站在哪裡」這一道門檻。至於能不能因此獲得流量,仍要實際測試。 我想先測的五個產品方向01|Privacy Cleaner:把個資整理成可分析的資料很多人想用 AI 分析 Excel,卻會先卡在姓名、電話、Email、身分證字號或地址能不能直接提供給 AI。 使用者真正會說的可能是: 幫我把這份資料裡的個資移除,我想交給 AI 分析。 初版可以讓使用者上傳 Excel 或 CSV,選擇要遮罩或替換的欄位,再輸出一份處理後的檔案。若產品需要保留日後還原的對照表,就要把它和處理後的資料分開保管,並限制存取;不能只把「可以還原」當成預設功能。 我想先從它開始,是因為自己已經做過類似問題,而且一句話就能說清楚工具要幫什麼忙。若想延伸了解企業使用 AI 時的個資與風險控管,也可以讀個人資料保護與 AI 風險控管。 02|Customer List Cleaner:整理亂七八糟的客戶名單真實世界的名單常有電話格式不一、姓名多空白、Email 前後有空格、公司名稱寫法不同,或同一個人重複報名等狀況。 使用者只要說「幫我整理這份客戶名單」,工具就可以先辨識欄位,再清除多餘空白、統一格式、標記可能重複的資料,最後輸出整理結果。重複資料如何判定、哪些內容可以合併,應該讓使用者檢視或設定,避免把不同的人誤合成一筆。 這種工具一點都不性感,卻有機會處理每天都會重複發生的小麻煩。 03|Taiwan Expense Assistant:整理台灣活動核銷資料做政府計畫、協會活動、職訓、講座或補助案的人,活動結束後常要整理簽到表、照片、發票、收據、講師鐘點費、領款憑單和支用單據。 工具可以協助列出目前收到哪些資料、還缺什麼、金額是否需要人工核對,以及哪些文件尚未簽名。它也可以依照特定案件需求產生核銷清單。它能協助檢查與整理,不應把 AI 判讀當成正式核銷審核或憑證效力的保證。 這類產品的價值不只在模型能力,而在於理解台灣在地流程與文件習慣。對大型國際產品來說可能太細,對每天在處理這些文件的人卻很具體。 04|Taiwan Business Docs:先把報價和行政文件做好「幫我做一張報價單」可能比「幫我打造企業級營運平台」更接近小公司老闆每天會說的話。 第一版可以從報價單、估價單、請款單、領據或活動簽到表等固定格式開始,讓使用者提供項目、數量、金額和客戶資訊,再產出可編輯的文件。之後才視需求串接 Gmail、Google Drive 或付款追蹤。 先把一份文件做好,再確認使用者是否願意反覆使用,比一開始就建置整套 CRM、文件管理和付款流程更容易驗證。若你也在探索 AI 如何降低小型 SaaS 的開發門檻,可延伸閱讀AI 讓程式碼越來越便宜,但知道什麼值得做正在變得越來越貴。 05|LINE Booking Manager:有價值,但整合成本較高我做過 LINE OA 預約流程,包含 AI 意圖判斷、查詢 Google Calendar 和人員時段、建立預約、寫入資料,再回覆 LINE。 未來如果能透過對話查詢「星期六還有哪些教練有空」,或調整某一筆預約,確實很有意思。但它也牽涉 LINE API、Google Calendar、OAuth、資料庫、租戶隔離與權限設定。這些都是產品要面對的工作,不是把現有系統接上一個 Plugin 名稱就會消失。 若這次的目標是測試使用者會不會從 ChatGPT 入口找到工具,我會把這個方向排在後面,先測小而明確的任務,再評估複雜整合是否值得投入。 五個產品不等於五套大工程我想測的不是五個做到完美的產品,而是五個清楚的使用情境。能重用的帳號、資料處理或文件輸出能力就盡量共用;每個方向先定義一個使用者需求、一個最小任務,以及怎樣算完成。 除了曝光、安裝或啟用等平台實際提供的資料,我還想觀察: 使用者有沒有完成第一次任務? 任務完成率如何?中途卡在哪一步? 使用者是否回來再次使用? 7 日或 30 日後是否仍有需求? 哪些需求是使用者主動反覆提起的? 平台未必提供所有分析數據,所以能取得什麼訊號、如何合規記錄使用情形,也要列入實驗設計。不要先用自己的喜好判定哪個方向最好,讓可取得的使用資料和實際回饋幫忙篩選。 新的產品入口,也許需要研究「人話」以前做 SEO,我們常研究使用者會搜尋什麼關鍵字。若使用者開始在對話裡直接說需求,我想還要多研究另一件事:他會怎麼把工作說出口? 我暫時把這件事叫作 Intent SEO。這是我對可能出現的產品發現方式的稱呼,不是說它已經有一套公認的排名規則。 以 Privacy Cleaner 為例,工程師可能會說「企業級去識別化服務」,一般使用者更可能說: 幫我把名字遮掉。 這份資料可以匿名化嗎? 我想把電話換成假的,再交給 AI 分析。 Excel 有個資,怎麼處理比較安全? 這些說法可以整理成 Prompt Intent Library,拿來設計工具描述、範例提示與任務流程。技術名詞要不要放在說明裡,可以再測;第一步是先確定使用者真的會用什麼語言描述問題。 Plugin Idea 可能就在自己的工作紀錄裡如果現在要開始找方向,我不一定會先打開排行榜或再腦力激盪十個新創點子。我會先回頭看自己的工作紀錄: 哪件事我問過 AI 好幾次? 哪個 Excel 我每個月都要重整? 哪份 SOP 每次都要重新解釋? 哪個流程我已經做過工具,但還需要別人找到它? 哪些客戶、講師或協會反覆遇到同一種麻煩? 這些紀錄至少說明有真人遇過這個問題,值得進一步訪談和測試。它們不保證市場夠大,卻比只靠想像產品點子更接近真實工作。 我不會 All in,但會趁成本低時下注我現在不是要預測 ChatGPT Plugin 或 App 生態一定會成為下一個 App Store。平台入口能不能帶來穩定流量,現在都還需要實際驗證。 我想做的比較像一次產品實驗:從已經解過的工作問題出發,選五個小任務,跑過需求、最小版本、平台上架、使用回饋和迭代。若有方向被持續使用,再集中資源;如果沒有,至少多學會一套把工作流程變成可用產品的方法。 這一路也可能變成教材:先自己踩一次,再把 Vibe Coding、既有工具產品化、Prompt Intent 設計和市場驗證的過程整理出來。 看完這波 ChatGPT 工具生態的變化,我現在更想問的不是「Plugin 一定會不會紅」,而是:我手上還有多少已經解決過的工作問題,可以換一個入口再測一次? 如果要先選一支,我會從 Privacy Cleaner 開始。不是因為我知道它會成功,而是因為我已經碰過這個問題,也知道可以先從哪個小任務動手。平台是不是新的流量入口,最後還是要讓使用者的行為來回答。 常見問答 (FAQ)Q1:ChatGPT Plugin 和 ChatGPT App 是同一件事嗎?OpenAI 的文件把 Plugin 描述成可組合 Skills 和連接 App 等能力的工作流程;Apps SDK 則提供開發 ChatGPT 內 App 的工具與提交 app directory 的指引。兩者相關,但產品形式和發布方式應依官方當下文件分別確認。 Q2:為什麼要先測五個方向,而不是只做一個完整產品?這篇文章的做法是先比較五個範圍明確的小任務,觀察哪個方向有人完成任務並持續回來使用,再決定是否加大投入。五個點子本身不會保證成功,也不表示要先打造五套大型系統。 Q3:測試 ChatGPT 工具應該看哪些數據?可以先定義首次任務完成率、使用者卡住的位置、再次使用,以及 7 日或 30 日後是否仍有需求。平台未必提供所有指標,應依當時可取得的數據與合法合宜的紀錄方式調整。 Q4:五個方向裡,哪一個適合先做?作者目前想先測 Privacy Cleaner,因為已有相關工具經驗,而且使用者需求容易用一句話說清楚。這是作者的起點選擇,不代表它已經被市場驗證或一定比其他方向更有需求。 Q5:為什麼 LINE 預約系統先不做?LINE 預約牽涉 API、行事曆授權、資料庫、租戶隔離與權限等整合工作。若目標是先驗證新的對話入口是否有人使用,先測單一、明確、較少前置整合的任務會更容易看出需求。

  • article-Public APIs 開始收錄 MCP Server:48 萬 Star 的工具清單怎麼用?

    2026/10/1

    AI工具 AI Agent MCP
    Public APIs 開始收錄 MCP Server:48 萬 Star 的工具清單怎麼用?

    最近整理 Skill Library 時,我發現自己收藏了不少 MCP,真正要做事時卻還是得重新搜尋:「有沒有 Gmail MCP?」「哪個 MCP 能查 YouTube?」接著逐一看 README、確認維護狀況、安裝方式和需要的權限。 這讓我重新注意到 GitHub 上的 public-apis/public-apis 專案。它原本以公開 API 分類清單聞名,現在也加上 MCP Servers 區塊。我查閱時,GitHub 顯示約 48.5 萬顆 Star;電腦王阿達在 2026 年 9 月 5 日的介紹則記錄當時已超過 47 萬顆。Star 數會變動,這裡的數字只是查閱時的快照。 比起多收藏一個目錄,我更想建立一個流程:先說清楚工作需要什麼能力,再讓 Agent 找候選工具、比較限制,最後才決定要不要安裝 MCP。 Public APIs 的 MCP 清單有什麼不同?Public APIs 原本把公開 API 依用途分類,例如 Weather、Finance、Email、Geocoding、Government、Video 等。清單除了名稱與說明,也會列出驗證方式、HTTPS 和 CORS 等資訊,方便開發者先篩選資料來源。 README 現在另有 MCP Servers 表格,欄位包含名稱、用途、驗證方式、Transport 和安裝入口。查閱時可看到 OpenSwissData、IPstack MCP、GitHub、Filesystem 等項目。這些資料讓讀者先比較需要什麼驗證、支援哪種傳輸方式,再前往專案或安裝目錄查看細節。 它的特色不是 MCP 數量最多,而是從「我需要天氣、金融或檔案能力」這類需求出發,再找可能的 API 或 MCP。要做天氣網站,直接呼叫 API 也許就夠;若 Agent 要在多次任務中反覆查詢或執行操作,MCP 才可能比較合適。 另外,清單名稱裡的「免費 API」不代表每個服務都能無限制免費使用。實際費率、免費額度、API Key 和使用條款都要再到服務官方文件確認。 API、MCP 和 Skill 各自負責什麼?這三者不是互相取代的工具,而是處理不同層次的問題: 元件 負責的事情 常見用法 API 服務提供的資料或操作介面 網站或程式依服務文件發送請求、處理回應 MCP Server 依 MCP 協定,把工具或其他上下文能力提供給相容的 Agent 讓 Agent 透過標準介面呼叫搜尋、檔案或服務工具 Skill 說明 Agent 怎麼完成一類工作 把需求拆解、檢查步驟和交付格式整理成可重複使用的 SOP MCP Server 有時會在背後呼叫 API,但 MCP 並不是 API 的另一個名稱;有些 API 也沒有對應 MCP。Skill 則可以教 Agent 如何呼叫已設定的 MCP,也可以規定何時直接用 API。 若你還想釐清 MCP、Skill 與 CLI 的分工,可以接著看一次搞懂 MCP、Skill 與 CLI 的差異。Skill 與 Plugin 的組合方式則整理在從個人工作流到團隊交付。 找 MCP 時可以先看哪幾個地方?我會依照需求和想確認的資訊,從以下入口開始找。它們的定位不同,搜尋結果也不等於品質或安全保證。 1. Official MCP Registry:查官方登錄資料Official MCP Registry 是 MCP 專案提供的公開 Server 目錄,可以搜尋 Server 名稱與版本,並查看其 metadata。它適合用來確認某個項目是否有公開登錄,以及對應的專案或套件資訊。 不過,「出現在 Registry」不等於「經過完整安全審核」。Registry 的資料由 Server 維護者發布,使用者仍要核對來源、版本和權限;官方說明也提到社群可檢舉違規項目,由維護者處理。 2. Public APIs:從需要的能力開始找如果你還不確定該找 API 還是 MCP,可以先按資料類型或用途查 Public APIs。MCP 區塊的清單目前較精簡,優點是會把 MCP 放在原有 API 資源旁邊,讓你比較是直接呼叫 API,還是透過 Agent 使用 MCP。 3. Glama:用搜尋與篩選比較大量候選Glama MCP Servers 提供伺服器索引與搜尋,頁面可按更新日期、GitHub Star、套件下載量等條件排序。網站在 2026 年 10 月 1 日查閱時顯示約 94,668 個 Server。索引數量會改變,應以網站當下顯示為準,也別只看總數或 Star 就決定安裝。 4. Smithery:搜尋並查看伺服器管理入口Smithery 提供類別與條件篩選,並展示部分 Server 的使用資訊。頁面在 2026 年 10 月 1 日查閱時顯示 13,151 個搜尋結果。平台和目錄功能可能持續調整,因此安裝方式、方案和服務狀態要回到當下的官方說明確認。 5. GitHub 與服務官方文件:確認實作細節找到候選項目後,接著查它連結的原始 Repository 和服務官方文件。目錄摘要可以幫你發現項目,卻無法代替版本紀錄、License、安裝需求、OAuth 範圍、API 費用及原始碼審查。 用 MCP Scout 把搜尋變成工作流程與其在看到「必裝 MCP 清單」時一律先收藏,我會希望 Agent 在開始實作前先做需求分析:完成任務需要哪些資料、外部服務和操作權限?是否已經有可用的 MCP?直接呼叫 API 或使用 CLI 會不會更簡單? 這個想法可以整理成一個 MCP Scout Skill。它不負責直接替你安裝工具,而是先找候選、標示來源與限制,再提出方案供你決定: 1234567891011121314151617181920你是我的 MCP Scout。我要完成以下工作:{{工作需求}}先分析需求並搜尋工具,不要直接開始實作、安裝或執行候選項目。第一階段:拆解需求列出完成工作需要的資料、操作與外部服務,例如搜尋、檔案、Database、Email、Calendar、Browser 或 SaaS。第二階段:搜尋候選依序查看 Official MCP Registry、public-apis/public-apis、Glama、Smithery、GitHub 與服務官方文件。最多列出 3 個候選,附上來源連結;清楚標示官方或社群專案,找不到證據時不要猜。第三階段:比較限制逐一整理提供的 Tools、Repository、License、最近更新、Transport、Agent 相容性、API Key 或 OAuth、費用、權限範圍,以及是否會讀寫本機檔案或執行 Shell。每個判斷都附上可查證的來源。第四階段:提出選擇比較使用現有 MCP、直接使用 API/SDK/CLI,或自行建立 MCP 的建置時間、維護成本、安全性、穩定性與可移植性,說明適合的方案與原因。先交付搜尋結果與建議,等待我確認後才進行安裝或授權設定。 這段流程的重點是先把需求和風險攤開來,不要讓搜尋結果直接變成安裝指令。MCP Scout 可以協助找資料,但不能只憑目錄標籤就替候選項目背書。 不需要為每件事都加上 MCP我會用三個問題快速選擇: 只是要取得一份資料或完成一次操作? 先看 API、SDK 或 CLI 是否更直接。 Agent 是否要在不同任務中反覆使用同一項能力? 再評估 MCP 的介面和維護成本。 真正需要保存的是工作步驟嗎? 把判斷方法整理成 Skill;需要工具時,再讓 Skill 指向 API 或 MCP。 例如天氣網站可以直接呼叫天氣 API;如果多個 Agent 都要在對話中查詢天氣、比較時段並安排活動,MCP 可能更容易重複使用。工具是否值得封裝,仍取決於實際使用頻率、權限需求和維護成本。 最後,我想收藏的不是更多 MCP 名稱,而是一條遇到需求時找工具、核對來源、比較限制的路徑。當 Skill 知道何時呼叫 MCP,Agent 又知道缺工具時該去哪裡找,工具庫才會從收藏清單變成真正能使用的工作流程。 常見問答 (FAQ)Q1:Public APIs 的 MCP Servers 清單適合拿來做什麼?它適合從 API 類別或能力需求出發,快速發現少量相關 MCP,並查看簡介、驗證方式、Transport 和安裝入口。找到候選後,仍應到 Repository 和官方文件確認細節。 Q2:要去哪裡搜尋 MCP Server?可以先看 Official MCP Registry 的登錄資料,再用 Public APIs 按需求找候選,或用 Glama、Smithery 搜尋和篩選。最後回到 GitHub Repository 及服務官方文件確認版本、授權、費用與權限。 Q3:怎麼判斷 MCP Server 是否適合安裝?至少要確認維護者與 Repository、License、最近更新、安裝程序、Transport、憑證和費用,以及它要求的檔案、網路或 Shell 權限。目錄列出項目不等於安全認證;對高權限工具,應先檢查程式碼並在受限環境評估。 Q4:MCP、API 和 Skill 要怎麼選?一次性或單純的資料請求可先用 API、SDK 或 CLI;需要讓 Agent 以一致介面反覆呼叫的能力,可評估 MCP;需要重複遵循的工作方法則適合整理成 Skill。三者也能搭配使用。 Q5:MCP Scout 可以自動安裝它找到的 MCP 嗎?MCP Scout 可以整理需求、搜尋候選和比較限制,但搜尋結果不能代替程式碼審查或權限判斷。建議先讓它提交來源和評估結果,經人確認後再安裝、提供憑證或授予本機權限。 參考資料 電腦王阿達|Public APIs 免費 API 資源庫介紹 GitHub|public-apis/public-apis MCP 官方專案|Introducing the MCP Registry Official MCP Registry Glama MCP Servers Smithery

  • article-當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    2026/9/30

    AI工具 ChatGPT AI Agent
    當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    最近看到 OpenAI 推出 Sign in with ChatGPT,並開始讓符合資格的開源工具串接 ChatGPT 方案用量。官方目前列出的開源工具範例包含 Pi by Earendil。 一開始我也以為,這只是「Pi 現在可以更方便使用 GPT」。但把 OpenAI 的整合說明和 Pi 的登入方式放在一起看,我更在意的其實是另一件事:我們過去常綁在一起看的模型與 Agent Harness,正在變成可以分開選擇的兩層。 這可能改變我們挑選 AI Agent 工具的方式。 為什麼我開始把模型與 Agent 分開看?這兩年挑 AI Coding 或 Agent 工具時,我們很容易先從模型開始想:想用 Claude,就想到 Claude Code;想用 OpenAI,就想到 Codex;想用 Gemini,就去找 Google 生態系裡的工具。 久了容易覺得模型就是 Agent。其實模型比較像負責理解、推理、規劃與生成的大腦。要讓它讀檔、改程式、執行 Shell、呼叫 MCP、操作瀏覽器、載入 Skill,還需要一套把模型接到電腦、工具和工作流程上的系統。 這一層通常稱為 Agent Harness。 Harness 負責把模型接到工作現場假設我們請 Agent 檢查專案、找出 Bug、修改程式碼、執行測試,再整理報告。真正完成任務時,除了模型本身,背後還有許多部分一起運作: 上下文管理與檔案系統 Shell、Terminal 與工具呼叫 MCP、Skills、Browser 或 Computer Use 權限控制、錯誤處理與 Agent Loop 工作狀態保存、模型切換與記憶機制 這些能力如何串接,會影響模型能看見什麼、可以採取哪些行動,以及出錯後能不能修正並繼續。Harness 不只是聊天介面,而是模型的執行環境和工作規則。 同一個 GPT,換一套 Harness 也會有不同體驗假設兩套 Agent 使用能力相近的 GPT 模型。A Harness 可能會先搜尋專案、整理計畫、修改程式碼、自動執行測試,發現錯誤後再回頭修正與驗證;B Harness 可能只讀幾個檔案、修改一次就回報完成。 最後使用者感受到的「AI 好不好用」,不一定全是模型能力的差異,也可能是 Harness 怎麼安排模型工作的結果。 Pi × ChatGPT 值得注意的是什麼?OpenAI 的 Sign in with ChatGPT 把兩種權限分開處理:使用者可以用 ChatGPT 身分登入,也可以另外選擇是否讓符合資格的應用程式使用方案內的 AI 用量。使用 ChatGPT 方案用量需要獨立授權;目前官方說明限定 Plus 與 Pro 等符合資格的方案,而且這不會把 ChatGPT 對話或 API Key 交給應用程式。OpenAI 使用說明 也列出 Pi by Earendil 作為開源工具範例。 這不只是第三方工具自己接上一個模型 API。OpenAI 已提供讓開源工具使用者以 ChatGPT 帳號登入,並在同意後使用方案用量的整合方式;開發者文件也說明,登入身分與使用方案用量是不同能力,後者是可選權限。 不過「列在支援範例」不等於每種登入方式對所有使用者都已順利可用。Pi 既有的文件也列出 ChatGPT Plus/Pro(Codex)訂閱登入;此外,Pi 專案在 2026 年 9 月 29 日有使用者回報,新版 Sign in with ChatGPT 的 Pi 登入出現 invalid_client,而舊的 Codex 訂閱登入仍可用。這是一則使用者回報,不能推論成所有帳號都遇到相同問題;但它提醒我們,整合方式和實際可用狀態可能還在演進。Pi 登入文件 · Pi issue #10184 模型與 Harness 可以分開組合過去模型、帳號、額度和 Agent 工具常被包成一套產品。現在可以想像不同的組合:ChatGPT 方案連上 Pi,Pi 再接 Skills、MCP、CLI 或 Browser,最後串成自己的 Workflow。 我也可能在某些工作使用 Claude Code,在另一些工作使用 Codex;需要自訂流程時,再選 Pi、OpenClaw 或 Hermes 等其他 Harness。這些工具的能力和整合方式會隨版本變動,但「模型與執行環境可以分開思考」是更值得留下的觀念。 因此,選 AI Agent 時只問「要用哪一個 AI?」可能不夠。還可以接著問: 你使用什麼 Model? 你使用什麼 Harness? 你裝了哪些 Skills、接了哪些 Tools? 這些元件最後如何組成 Workflow? Harness 也是一條重要的信任邊界Agent 不只回答問題。依照授權,它可能讀寫檔案、執行指令、連接服務、操作瀏覽器、使用憑證或呼叫 MCP。因此除了問「這顆 LLM 安不安全?」,也要了解「這套 Harness 在我的電腦上能做什麼?」 Harness 決定模型可用的工具和權限,也要負責把操作結果與錯誤交回模型。選擇工具時,可以檢查它會讀取哪些資料、哪些地方會執行 Shell、網路請求送往哪裡、憑證如何保存,以及 MCP 或擴充套件擁有哪些權限。 開源代表多了一個檢查入口,不代表自動安全Pi、OpenClaw、Hermes 這類開源 Harness 有一個優點:原始碼可以檢查。開源不等於安全,專案仍可能有漏洞,第三方 Skill、Plugin 或 MCP 也可能帶來風險。 但我們可以把「完全不知道它在做什麼」往前推一步,改成檢查它的資料流、Token 儲存、Shell 執行點、網路請求、遙測、相依套件與敏感檔案存取。也能請 Codex 或 Claude Code 協助做安全檢視,再由人確認重要結果。這不能保證百分之百安全,卻增加了理解和審查的機會。 Skill Library 比 Prompt 收藏更容易累積工作方法我最近整理 Agent Skill 時,越來越不想只收藏「一百個超強 Prompt」。Prompt 容易散落各處;比較有價值的,是把自己的工作方法整理成可重複使用的能力。 例如簡報、文章、社群內容、研究、影片分鏡、資料整理、Vibe Coding 或課程設計 Skill,都可以說明 Agent 遇到這類工作時,先做什麼、要遵守哪些規則、參考哪些資料、輸出成什麼格式,以及如何驗收成果。 每個 Skill 不只是放一句提示詞,而是逐步累積判斷方式與 SOP。這也延伸了我在整理自己的 AI 工作能力庫時的想法:把工作方法留下來,才能在模型更新時繼續使用。 用五層架構理解 AI Agent剛開始研究 Agent 時,可以先用五層架構來看: Model:GPT、Claude、Gemini 等模型,負責理解與推理。 Harness:Pi、Codex、Claude Code、OpenClaw、Hermes 等工具,負責讓模型在環境中工作。 Skills:把專業知識、規則與 SOP 包成可重複使用的能力。 Tools:MCP、CLI、Browser、Computer Use、API 等,讓 Agent 接觸外部工具和資料。 Workflow:把前面各層組合起來,完成一項真正的工作。 最後產生價值的,通常不是單獨某一顆 LLM,而是 Model、Harness、Skills、Tools 與 Workflow 的組合。 哪些人值得研究 Pi 這類開源 Harness?如果平常只是偶爾問 ChatGPT 問題,不需要因為一則整合消息就立刻更換工具。但如果已經開始做 AI Coding、MCP、Skills、自動化、長時間任務或多工具工作流,Pi 這類開源 Harness 值得研究。 重點不是把所有工作搬到同一個工具,而是理解模型、執行環境與工作方法可以分開評估,再依任務組合。 Agent 下一戰也許是工作系統GPT、Claude、Gemini 都會持續更新,模型排行榜也會一直變。我現在更在意的是:工作流程有沒有留下來?Skill 能不能重複使用?工具能不能替換模型?資料能不能掌握?Harness 能不能檢查?Agent 能不能真正完成工作? 以前我會想「選一個最強的 AI,把工作交給它」。現在更傾向先建立自己的 AI 工作系統,再選合適的模型進來工作。 模型會換,Harness 也會進化;更值得自己留下來的,是 Skills、Tools、Workflow,以及累積下來的工作方法。也許以後大家討論 AI Agent,不只問「你用 GPT 還是 Claude?」,還會問「你現在用哪個 Harness?你的 Skill Library 裡有什麼?」 參考資料 OpenAI:Using your ChatGPT plan in other apps and sites OpenAI:Integrating Sign in with ChatGPT in your Open Source App Pi:Provider Authentication Pi issue #10184:Sign in with ChatGPT 登入回報 常見問答 (FAQ)Q1:Agent Harness 是什麼?Agent Harness 是讓模型在電腦與工具環境中執行任務的系統,通常包含上下文管理、檔案與 Shell 工具、權限控制、Agent Loop、錯誤處理及工作狀態等部分。 Q2:使用 Pi 連接 ChatGPT 方案一定要準備 API Key 嗎?Sign in with ChatGPT 的開源整合可讓符合資格的使用者登入,並在另外授權後使用方案內的 AI 用量,不需要自行建立或提供 OpenAI API Key。是否能使用仍取決於方案資格、工具整合與當下登入狀態。 Q3:Sign in with ChatGPT 會把我的 ChatGPT 對話交給 Pi 嗎?不會因登入或使用方案用量就取得 ChatGPT 對話或 API Key。登入身分與方案用量授權是不同權限;使用者仍應逐項檢查應用程式要求的權限及其資料處理方式。 Q4:開源 Agent Harness 就代表安全嗎?不代表。開源讓人有機會檢查原始碼,但不能保證沒有漏洞,也不能替第三方 Skills、Plugins 或 MCP 背書。使用前仍要檢查程式行為、資料流、工具權限與相依套件。

  • article-從 Prompt 到 Skill Library:我從吳奇老師的 Agent Skill 講座學到什麼?以及如何打造自己的 AI 工作能力庫

    2026/9/30

    AI工具 AI自動化 AI Agent
    從 Prompt 到 Skill Library:我從吳奇老師的 Agent Skill 講座學到什麼?以及如何打造自己的 AI 工作能力庫

    最近我看了「數位敘事力期刊」舉辦的一場直播講座,主講人是吳奇老師,主題是: 《Agent skill:為何需要 skill?與 skill 的極限》 直播原始影片: YouTube|Agent skill:為何需要 skill?與 skill 的極限 看完之後,我最大的感受不是「又多了一個 AI 新名詞」,反而是很多我最近一直在做的事情突然被串起來了。 這一兩年我們從 Prompt、GPTs、Gems、MCP、Agent,一路走到 Skills。 表面上工具一直換,但底層其實是在解決同一件事: 怎麼讓 AI 不只是回答問題,而是學會「我們平常到底怎麼工作」。 尤其我自己最近大量使用 Codex、Claude Code、Agent、MCP 做課程教材、簡報、網站、影片、自動化工作流,更能感受到一件事: 真正有價值的,已經慢慢不是那一句「神 Prompt」。 而是: 你有沒有辦法把自己做事的方法,整理成 AI 可以重複使用的 Skill。 這篇文章就是我從吳奇老師直播中吸收之後,再搭配目前 OpenAI、Anthropic 與 Agent Skills 官方規格,重新整理出來的一套理解。 最後也會實際設計我準備使用的: 「享哥 Skill Library」 一、先用一句話理解什麼是 Agent Skill我目前最喜歡的理解方式是: Tool / MCP 告訴 AI「你可以做什麼」,Skill 告訴 AI「這件事情應該怎麼做」。 例如我今天給 Agent: Gmail Google Drive Calendar Browser Terminal Python ImageGen 這代表它有很多工具。 但是: 有工具,不代表會工作。 就像今天公司請了一位新員工,給他: 電腦 Gmail ERP Excel 公司帳號 不代表他就知道: 收到客戶詢問後,可以依序判斷: 先確認什麼? 哪些資料要查? 哪些狀況要升級處理? 最後要填哪張表、寄什麼格式的信? 這中間缺的就是: SOP、判斷規則、範本與經驗。 而 Skill 就是在做這件事。 OpenAI 現在也把 Skill 定義為可重複使用的工作流程,讓 ChatGPT 或 Agent 不需要每一次都重新被解釋流程。 二、我會把 AI Agent 能力拆成四層從吳奇老師直播裡的 Workspace、Tools / MCP、Skill 架構,我自己重新整理成下面四層。 層級 解決問題 可以怎麼理解 Model AI 會不會思考 大腦 Workspace / Runtime AI 在哪裡工作 辦公室 Tool / MCP AI 可以操作什麼 工具 Skill AI 應該怎麼做 SOP+教師手冊 例如: 1234567GPT / Claude↓Codex / Claude Code / VM↓Google Drive / Gmail / Browser / CLI↓我的課程製作 Skill 這四層要放在一起看。 因為 Skill 並不是魔法。 假設 Skill 裡面寫: 打開瀏覽器登入後台,把資料輸入 ERP。 但是這個 Agent 根本: 沒 Browser 沒 Computer Use 沒帳號 沒權限 那 Skill 寫得再漂亮,也執行不了。 所以 Skill 能力永遠是: 123456789模型能力×執行環境×工具×權限×Skill 三、MCP 跟 Skill 到底差在哪?這是很多人第一次接觸 Skill 最容易混在一起的地方。 假設 MCP 提供三個工具: 123search_customer()check_calendar()send_email() 這代表 AI: 能查客戶、能查行事曆、能寄信。 可是它不知道什麼時候該用哪一個。 Skill 就可以寫: 12345678當使用者要求安排客戶會議時:1. 先搜尋客戶資料。2. 確認上次聯絡紀錄。3. 查詢雙方可用時段。4. 產生 3 個候選時段。5. 使用者確認後才建立行程。6. 建立完成後寄出確認信。 所以: 12MCP = CapabilitySkill = Workflow OpenAI 官方文件也把兩者定位為互補層:MCP Server 提供即時資料、授權與受控動作;Skill 則說明何時呼叫工具、依什麼順序處理,以及如何處理不完整結果與整理輸出。我會把它簡化記成:MCP 提供能力,Skill 描述工作流程。可參考 OpenAI Developers:Skills 與 MCP 的分工。 這個觀念非常重要。 因為我們以前很容易覺得: 「接上 MCP 就完成 Agent 了。」 其實不是。 MCP 比較像把工具箱交給 Agent。 Skill 才是在告訴它: 「我們公司拿這套工具到底怎麼做事情。」 四、Skill 不只是一個比較長的 Prompt第一次看到 Skill 很容易想: 那不就是把 Prompt 存成 Markdown? 某種程度沒錯。 但如果只這樣理解,又會低估 Skill。 一個正式 Skill 通常是一個資料夾。 目前 Agent Skills 開放規格要求每個 Skill 至少包含 SKILL.md;scripts/、references/、assets/ 則依需求加入: 12345my-skill/├── SKILL.md├── scripts/├── references/└── assets/ 其中: SKILL.md核心操作說明。 定義: 這個 Skill 做什麼 什麼時候使用 需要哪些輸入 工作流程 判斷規則 輸出格式 完成前檢查 references/參考知識。 例如: 123456課綱品牌規範公司 SOPAPI 文件報價規則產品規格 assets/可重複使用的素材。 例如: 123456PPTX 模板Word 模板CSV 樣板品牌 LogoJSON Schema範例檔案 scripts/需要確定性執行的程式。 例如: 123456PythonJavaScriptBash資料轉換檔案檢查格式驗證 這些目錄名稱對應 Agent Skills 開放規格列出的常見支援資源;除了 SKILL.md 之外,其餘目錄都是可選。 五、真正重要的設計:Progressive Disclosure吳奇老師直播中,我非常認同的一個關鍵概念叫: Progressive Disclosure中文可以理解成: 漸進式揭露。 以前我們很常幹一件事情: 把所有規則全部塞進 System Prompt。 例如: 123450 頁品牌規範30 頁課綱20 個範例100 條 SOP 然後每一次對話全部讀。 結果就是: Token 增加 Context 變亂 AI 抓不到重點 不相關的規則互相干擾 Skill 的做法不同。 第一層: 12namedescription AI 只先知道: 「有這個 Skill 存在。」 第二層: 只有判斷目前任務需要它時,才載入: 1SKILL.md 第三層: 真的遇到某種工作,才讀: 123references/assets/scripts/ Anthropic 把這套機制明確稱為 Progressive Disclosure;Agent Skills 官方規格也建議 Skill 啟動前先只載入名稱與描述,啟動後才載入完整 SKILL.md,需要時才讀其他資源。 所以好的 Skill Architecture 不是: 1一個 50,000 字 SKILL.md 而是: 12345678910SKILL.md↓需要才讀references/course-design.md需要才讀references/brand-guide.md需要才用assets/template.pptx 這一點對大型工作流非常重要。 六、Skill 真正封裝的是四種知識這是我看完直播之後,自己再整理出來最重要的一個框架。 一個成熟 Skill,其實可能封裝四種東西。 第一層:Declarative Knowledge也就是: 「知道什麼」例如: 1234AI 課程有哪些工具?公司的品牌色是什麼?勞基法規定是什麼?國中課綱有哪些素養指標? 這些比較適合放: 1references/ 第二層:Procedural Knowledge也就是: 「知道怎麼做」例如: 12345678910111213收到課程需求↓確認學員↓確認程度↓確認時數↓設計學習目標↓安排實作↓建立 Slide Manifest 這就是: 1SKILL.md 真正主要封裝的內容。 第三層:Executable Knowledge也就是: 「真的幫我做」例如: 1234scripts/├── export-pptx.py├── validate-csv.py└── generate-index.js 這時 Skill 不只是叫 AI: 「記得檢查。」 而是直接: 「執行檢查程式。」 這會比靠 LLM 自己判斷穩定很多。 第四層:Decision Knowledge這一層我認為最值錢。 也就是: 「專家為什麼這樣判斷?」例如我在規劃 AI 課程時,真正有價值的不只是: 12先做課綱再做簡報 而是: 123456789101112如果學員第一次接觸 Agent→ 不要先講架構→ 先做成功案例如果只有 3 小時→ 不做完整工作流如果行政人員居多→ Gmail / Excel / Drive 優先如果學員超過 50 人→ 降低需要逐一登入帳號的實作 這些東西不一定寫在書裡。 它們來自: 做過很多次之後形成的經驗。 而這也是我認為 Skill 最有價值的一件事: 把 Human Skill 慢慢轉成 Agent Skill。 七、直播裡提到的 5 種 Skill 建立方式吳奇老師整理了幾種 Skill 的建構方式。 我把它們重新整理一下。 方法一:Manual最直接。 自己寫: 1234SKILL.mdreferences/assets/scripts/ 適合: 本來就已經有完整 SOP 的人。 方法二:生成式建構不是自己從空白開始。 直接讓 Agent 幫你建立。 OpenAI 現在也有 Skill Creator。 在 Codex 裡可以呼叫: 1$skill-creator OpenAI 官方文件目前也推薦使用內建的 Skill Creator 開始建立 Skill。 例如: 1234567891011121314151617181920212223$skill-creator幫我建立 course-design skill。用途:將企業提供的課程需求轉換成完整 AI 課程架構。輸入:- 課程時數- 學員職務- AI 程度- 人數- 預期成果輸出:- 課程定位- 學習目標- 單元- 時數- 實作- 使用工具如果資料不足,先列出缺少資訊。 接著 Agent 就可以協助建立基本架構。 方法三:逆向工程/工作流蒸餾這是我自己最推薦的方法。 因為大部分人: 會做工作,但不一定會寫 SOP。 那怎麼辦? 先跟 AI 把工作做一次。 例如: 1234567891011討論需求↓修改課程架構↓調整簡報↓發現問題↓修正↓得到滿意結果 做到最後直接告訴 Agent: 1234567891011分析我們剛才完整的工作流程。找出:1. 固定步驟2. 判斷規則3. 必要輸入4. 常見錯誤5. 成功輸出格式6. 可以重複使用的參考資料把這套成功流程整理成 Agent Skill。 這件事情我會叫: Workflow Distillation工作流蒸餾。 它其實非常符合現在 Vibe Coding 的工作方式。 方法四:Record & Replay這種比較像: 「不要聽我解釋,看我做一次。」 例如: 123456登入網站→ 建立活動→ 填寫表單→ 上傳圖片→ 設定時間→ 發布 Agent 透過: Browser Use Computer Use RPA 學會操作順序。 這類 Skill 未來會跟 GUI Agent 高度整合。 方法五:Decision Distillation這比 Record & Replay 更進階。 不是觀察: 「你按哪個按鈕?」 而是觀察: 「你為什麼做這個決定?」 例如蒐集一位資深講師過去的: 12345650 個課程案例20 次退件30 次修改報價課綱學員反應 再抽出: 1234什麼情況用 A什麼情況不用 B什麼情況必須詢問什麼情況可以直接決定 這就從: 操作自動化 進化到: 決策經驗數位化。 八、其實這 5 種方法可以再濃縮成三類我後來發現,它們本質上就是: 1234567891011第一種我知道怎麼做→ 寫成 Skill第二種我已經做成功→ 把成功流程蒸餾成 Skill第三種觀察專家怎麼做→ 推導成 Skill 也就是: 123WriteDistillObserve 這樣一來 Skill 就不只是 AI 工程師的東西。 任何專業工作者都可以做。 九、Skill 跟 GPTs / Gems 有什麼不同?直播裡用了一個很好懂的方式,把 GPTs / Gems 理解成預設 Prompt,而 Skill 是完整工作流程。 這樣入門非常好懂。 不過如果要更精確,我會稍微補充。 GPT / Gem 比較像: 「一個已經設定好的 AI 助手」裡面可以包含: Instructions Knowledge Tools Persona 對話設定 Skill 比較像: 「這個 AI 助手可以學會的能力模組」例如: 123456789一個 Agent可以同時會:researchpresentationbrand-designcourse-designdata-analysis 所以我自己會用更簡單的方式教: GPT 比較像員工。 Skill 比較像員工會的技能。 而且 Skill 更強調: 模組化、可組合、可攜與按需載入。 目前 OpenAI 已支援 Agent Skills 開放格式,官方也把 SKILL.md 定義成可移植、可分享、可版本管理的工作流程格式。 十、Skill 最大的問題:不是越多越好這也是我最近特別有感的事情。 GitHub 現在 Skill 越來越多。 我前陣子也研究過一次: 146 個免費 Agent Skills。 第一反應很容易是: 全部裝! 但是其實這不一定是好事。 例如你裝: 123456presentation-designpptx-designbeautiful-slidesproduct-designslide-makerpresentation-pro 每一個 Description 都寫: 做簡報時使用。 那 Agent 到底選哪個? 這會產生: Trigger Collision所以一個 Skill 最容易被低估的欄位其實不是 Instructions。 而是: 1description: 因為它其實也是: RouterAgent Skills 官方規格明確要求 description 不只寫 Skill 做什麼,還應寫出「什麼情況使用」。OpenAI 也指出 Agent 主要根據 Skill 的 name 與 description 判斷是否需要呼叫。 例如不要寫: 1description: Helps create presentations. 而是: 1234description: > Converts a completed Slide Manifest into a structured presentation. Use only after the course outline and Slide Manifest have been approved. 這就清楚很多。 十一、Skill 有自己的極限看完直播後,我把 Skill 的極限整理成七個。 1. Model CeilingSkill 不會讓能力差的模型突然變成頂級模型。 它只能讓模型: 更了解怎麼使用既有能力。 2. Tool Ceiling沒有 Browser: 就不能瀏覽網站。 沒有 CLI: 就不能執行 Terminal。 3. Permission Ceiling有 Gmail Tool: 不代表有你的 Gmail 權限。 4. Context CeilingSkill 太長、太多: 還是可能造成 Context 干擾。 5. Knowledge CeilingSkill 不會自動擁有你的專業經驗。 你沒有把經驗整理進去: 它就不知道。 6. Environment Ceiling同一個 Skill 放到: 12345CodexClaude CodeChatGPTCursorComputer Use Agent 可以執行的內容未必完全相同。 因為環境能力不同。 7. Security Ceiling尤其外部 Skill 要非常小心。 因為 scripts/ 可能做: 123456執行 Bash下載程式讀 Environment Variable存取檔案呼叫外部 API刪除資料 OpenAI 現在也特別提醒,使用外部 Skills 前應檢查 Skill 與其支援檔案,尤其具有網路或 Shell 權限時,可能產生提示注入或資料外洩風險。 十二、模型越強,Skill 反而應該越薄這是一個很有趣的現象。 以前模型比較弱,我們寫: 12345第一步做什麼第二步想什麼第三步不要忘記什麼第四步怎麼判斷第五步…… 寫 300 條。 但模型越強之後: 很多事情其實它自己已經知道。 OpenAI 在 2026 年 9 月甚至特別發文提醒,新的模型能力提升後,要重新檢查累積已久的 Skill、AGENTS.md 與 Prompt,因為過度 scaffolding 可能造成 Context 膨脹與不必要限制。 所以未來好的 Skill 可能反而更像: 12345678910111213GoalInputsConstraintsDecision boundariesResourcesOutputQuality checks 而不是: 12345滑鼠往右 10px↓按一下↓等待 這很像管理人。 員工能力越強: 管理者越不應該 Micro Management。 十三、我自己認為真正的 Skill 成熟度,可以分成 8 層整理完直播內容後,我自己建立了一個 Skill 成熟度模型。 123456789101112131415161718192021222324252627282930313233343536373839404142434445Level 0Prompt這一次怎麼做?↓Level 1Template照這個格式做↓Level 2Workflow照這個流程做↓Level 3Skill以後遇到這類工作都這樣做↓Level 4Skill Library有很多能力可以選↓Level 5Agent自己判斷使用什麼 Skill 與 Tool↓Level 6Multi-Agent不同 Agent 分工合作↓Level 7AI Organization形成完整數位組織 我覺得這套分類也很好跟之前談過的: RPA Level 1~5 放在一起。 因為兩者其實描述兩個不同維度。 1234567Automation Level=AI 自己能做多少Skill Level=我們把多少工作知識交給 AI 十四、最終一定會走向 Multi-Agent直播最後談到: 1234校長 Agent教務 Agent學務 Agent總務 Agent 不同 Agent 各自帶著自己的 Skill。 表面是在講 Multi-Agent。 但我反而覺得真正的問題是: Organization Design因為你要回答: 12345678910111213誰負責什麼?誰能讀什麼資料?誰能修改資料?誰可以批准?什麼事情需要升級?工作完成交給誰?出錯誰負責處理? 也就是企業本來就在做的: 123456角色權限SOPRACI流程組織架構 所以未來 Multi-Agent 最大的問題可能根本不是: 「我要用 GPT 還是 Claude?」 而是: 「這份工作到底怎麼拆?」 這才是 Skill 往下一層走真正困難的地方。 十五、看完這場直播,我決定不要再只是收藏 Skill這就是整場直播對我自己最大的啟發。 最近我一直在研究: Codex Claude Code Agent Harness MCP Presentation Skill Product Design Slide Manifest Video Skill GSAP Skill 各種 GitHub Skill 如果一直照現在的方式,很容易變成: 12345收藏 50 個↓收藏 100 個↓收藏 500 個 結果: 真正屬於自己的工作方法沒有留下來。 所以我接下來比較想做的是: 「享哥 Skill Library」把這幾年真正累積的工作流程,一個一個數位化。 十六、享哥 Skill Library 不應該按照工具分類我不打算這樣分: 1234Gemini SkillClaude SkillCodex SkillChatGPT Skill 因為工具會換。 今年 Claude 強。 半年後可能 Codex 強。 再半年又有新東西。 真正不容易過時的是: 工作場景。所以我的 Skill Library 應該按照: 1我要完成什麼工作? 來分類。 十七、第一版「享哥 Skill Library」我目前會先規劃下面這些。 1234567891011121314151617181920212223xiang-skill-library/├── course-intake/│├── course-design/│├── slide-manifest/│├── presentation/│├── student-handout/│├── social-article/│├── social-visual/│├── video-script/│├── course-review/│├── workflow-distiller/│└── skill-security-review/ 01|course-intake用途: 收到邀課需求之後,先判斷資訊是否足夠。 輸入: 12345678910單位對象程度人數時數主題場地裝置AI 帳號預期成果 輸出: 12345已知條件缺少條件限制風險推薦課程方向 02|course-design用途: 123需求↓完整課程架構 包含: 定位 學習目標 單元 時數 工具 實作 成果 前置能力 03|slide-manifest這個是我最近特別重要的一個 Skill。 以前常遇到: 課程大綱跟最後 PPT 不一致。 所以現在增加中間層: 12345Course Outline↓Slide Manifest↓Presentation Slide Manifest 應記錄: 123456789slide_idtitlepurposekey_messagecontentvisualdemoexercisespeaker_notes 讓後續所有教材都吃同一份「簡報真相來源」。 04|presentation輸入: 1Slide Manifest 輸出: 1PPTX 同時加入: 我的簡報 DNA 字體 圖文比例 圖像風格 排版 ImageGen 規則 Speaker Notes 這樣就不需要每次重新解釋: 「我喜歡什麼簡報。」 05|student-handout把: 123課程內容↓Notion / Word 講義 並且保留: 123456提示詞變數實作注意事項摺疊區延伸練習 06|social-article把: 12345研究課程實驗工具心得 轉換成我的部落格與社群文章。 裡面可以慢慢累積: 12345我的語氣文章結構用詞不要使用的 AI 味CTA 07|social-visual輸入: 1文章 判斷: 1234567主視覺概念標題畫面構圖人物場景色彩ImageGen Prompt 08|video-script把文章轉: 1234567891011Hook↓30–90 秒腳本↓分鏡↓旁白↓字幕↓影像提示詞 09|course-review這個我覺得會非常重要。 每次教材完成後: 不要直接交件。 由另一個 Skill 做: 1對抗式 Review 檢查: 時數合理嗎? 新手做得完嗎? 工具有沒有過時? 提示詞太長嗎? 實作真的能執行嗎? Slide Manifest 跟 PPT 一致嗎? 講義跟簡報一致嗎? 10|workflow-distiller我覺得這會變成整套系統裡最重要的一個 Skill。 它的工作不是直接處理業務。 而是: 幫我製造 Skill。流程: 12345678910111213141516171819讀完整對話↓找成功工作流程↓找重複步驟↓找判斷規則↓找 Input / Output↓找 Edge Cases↓建立 SKILL.md↓建立 references↓建立 assets↓建立測試 也就是: Skill Factory。 11|skill-security-review這是我另外會加的。 任何 GitHub 下載下來的 Skill: 先不要直接安裝。 全部先過: 1skill-security-review 檢查: 12345678910SKILL.mdscripts/外部網址ShellNetworkEnvironment Variables檔案讀寫刪除命令依賴套件Prompt Injection 這會是未來 Skill 越來越普及之後,很實際的一個需求。 十八、實際開始:不要一次做 20 個 Skill我反而建議: 從一個最常重複的工作開始。對我而言,第一個很可能就是: 1course-design 十九、第一步:先找一個「已經成功過」的案例不要幻想 SOP。 直接找: 「我上一次做得很好的課程。」 把: 123456邀課需求對話課綱修改紀錄簡報學員實作 全部交給 Agent。 然後問: 123456789101112131415161718分析這個專案。不要只摘要內容。請逆向分析我實際採用的工作方法,包括:1. 任務輸入2. 固定工作步驟3. 決策點4. 我做過哪些修改5. 哪些判斷可以一般化6. 哪些只是這次案例特殊條件7. 最終輸出格式8. 常見錯誤9. 哪些內容適合放 SKILL.md10. 哪些內容應拆到 references / assets / scripts目標是把我的工作方法整理成可重複使用的 Agent Skill。 二十、第二步:請 Skill Creator 建立 Skill在 Codex 可以直接: 1$skill-creator 然後: 12345678910111213141516171819202122Create a skill named course-design.Goal:Turn training requirements into a practical AI course structure.The skill must:- identify missing requirements- classify learner skill level- determine realistic scope from course duration- prioritize hands-on exercises- avoid overloading beginners- generate structured course modules- include tool requirements- include learner outputsUse the attached successful course projects as reference examples.Separate:- workflow into SKILL.md- detailed teaching heuristics into references/- reusable course templates into assets/ 二十一、我會讓 SKILL.md 長這樣1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859---name: course-designdescription: > Designs practical AI training courses from client requirements. Use when planning a new workshop, corporate training session, or revising an existing course structure.---# GoalConvert training requirements into a realistic,hands-on course structure.# Required Inputs- audience- learner level- duration- number of learners- available devices- tool/account restrictions- expected outcome# Workflow1. Parse requirements.2. Identify missing information.3. Classify learner level.4. Define realistic learning outcomes.5. Divide the course into modules.6. Assign duration.7. Design hands-on exercises.8. Verify total duration.9. Produce final course outline.# Decision RulesIf learners are beginners:- reduce tool switching- prioritize one successful workflowIf duration <= 3 hours:- do not design a full multi-agent projectIf learner count > 50:- avoid exercises requiring individual account configuration# OutputReturn:- course positioning- audience- prerequisites- learning outcomes- module table- hands-on exercises- required tools- risks 你會發現: 真正好的 Skill 不一定要很長。 二十二、把詳細經驗拆出去例如: 1234567891011121314151617course-design/├── SKILL.md├── references/│ ├── beginner-course.md│ ├── corporate-training.md│ ├── course-duration-rules.md│ └── exercise-design.md├── assets/│ ├── course-outline-template.md│ └── course-intake-form.md└── examples/ ├── admin-course.md └── marketing-course.md 當課程是行政人員: 才讀: 1corporate-training.md 當課程是新手: 才讀: 1beginner-course.md 這就是 Progressive Disclosure。 二十三、第三步:一定要測試「什麼時候不該啟動」很多人測 Skill 只測: 「它會不會啟動?」 其實還要測: 「它會不會亂啟動?」 例如 course-design: 應該啟動: 1幫我規劃一堂 6 小時 Codex 課程 應該啟動: 1這堂 AI 課只有 3 小時,怎麼調整? 不應啟動: 1幫我查明天天氣 不應啟動: 1幫我修這段 JavaScript 這就是: Skill Routing Test。 二十四、Skill 不是做好就結束,而是要做 Evals這也是我認為下一階段很重要的觀念。 OpenAI 已經專門提出: Testing Agent Skills Systematically with Evals因為只靠感覺: 「好像 V2 比 V1 好。」 是不夠的。 應該建立固定測試題。 例如: 1234510 個應該啟動10 個不應該啟動10 個正常案例5 個極端案例5 個資料不完整案例 測: 1234567Trigger AccuracyWorkflow AccuracyOutput CompletenessError Handling OpenAI 官方現在也建議用 Evals 系統化測試 Skill 是否正確觸發、是否漏步驟,以及不同版本是否發生 Regression。 二十五、Skill 也應該像軟體一樣 Versioning例如: 12course-designv1.0 使用一段時間後發現: 人數超過 50 人的實作常失敗。 加入規則。 變成: 1v1.1 後來又發現: Windows / Mac 混合班不能設計太多 OS-specific 操作。 再加入: 1v1.2 久了之後: Skill 就變成: 我的數位工作經驗。 二十六、這其實才是 AI 時代真正的個人資產模型會換。 Prompt 會過時。 工具會消失。 今天: 1Claude 明天: 1Codex 後天: 又有新的 Agent。 但是: 12345678910111213我怎麼設計課程我怎麼判斷學員程度我怎麼做簡報我怎麼設計實作我怎麼 Review 教材我怎麼寫文章我怎麼做影片 這些東西: 才是真正屬於自己的。 而 Skill 做的事情,就是: 把 Human Skill 變成可以被 AI 使用的 Digital Asset。 二十七、我現在會把整個發展路線理解成這樣123456789101112131415Prompt↓Template↓Workflow↓Skill↓Skill Library↓Agent↓Multi-Agent↓AI Organization 以前大家問: 「Prompt 要怎麼寫?」 接下來可能會開始問: 「你的 Skill Library 裡面有什麼?」 再下一階段可能變成: 「你的 AI Organization 有哪些角色與能力?」 我覺得這才是 Agent 時代真正開始有趣的地方。 二十八、我的下一步:不是再找更多 Skill,而是開始蒸餾自己的工作看完吳奇老師這場直播之後,我最大的改變是: 以前看到: 146 個免費 Skill 我的第一反應可能是: 趕快下載。 現在我的第一個問題會變成: 「這個 Skill 能不能補我的工作流程?」 如果不能: 其實沒有必要裝。 真正值得做的反而是: 每完成一個重要專案,就問一次: 1這次有哪些做法值得留下來? 然後: 1234567891011Project↓Experience↓Workflow↓Distillation↓Skill↓Skill Library 如果一年做 100 個專案: 不需要留下 100 個 Skill。 但也許可以留下: 20 個真正代表自己工作方法的高品質 Skill。 那個東西的價值,很可能遠高於收藏 1,000 個別人的 Skill。 最後如果要我用三句話總結這次學到的內容: 第一句: MCP 給 Agent 工具,Skill 教 Agent 怎麼工作。 第二句: Skill 最有價值的地方,不是把 Prompt 存起來,而是把人的工作流程與判斷經驗保存下來。 第三句: 真正值得建立的,不是全世界最大的 Skill 收藏庫,而是最了解自己工作的 Skill Library。 所以我接下來真正想做的事情,就是: 享哥 Skill Library不是一次做完。 而是一個專案、一個流程、一個判斷慢慢累積。 最終把: 1234567我的課程我的簡報我的文章我的影片我的 Vibe Coding我的自動化我的顧問經驗 逐漸變成一組 AI 可以真正理解、呼叫、組合與執行的能力。 我覺得這才是 Skill 時代真正值得玩的地方。 延伸閱讀與參考資料1. 本文主要學習來源「數位敘事力期刊」直播講座,吳奇老師主講: 《Agent skill:為何需要 skill?與 skill 的極限》 YouTube 直播影片 2. OpenAI Academy|Using Skills適合第一次理解 Skill。 OpenAI 把 Skill 定義成可以重複使用、分享的工作流程。 OpenAI Academy:Using skills 3. OpenAI API|Skills比較技術面的官方規格,包括: SKILL.md references scripts assets Skills API Agent Sandbox Skill Discovery OpenAI Developers:Skills 4. OpenAI|Build Skills想使用 Codex 建立 Skill,這篇非常值得看。 包含: 1$skill-creator 以及 Skill 如何搭配 MCP。 OpenAI Developers:Build skills 5. OpenAI|Testing Agent Skills Systematically with EvalsSkill 做好之後不要只靠感覺測試。 這篇專門講: 123Skill EvalsTrigger TestingRegression Testing OpenAI Developers:Testing Agent Skills Systematically with Evals 6. OpenAI|Rethinking skills and prompts模型能力變強之後,Skill 不一定要越寫越長。 這篇很適合理解為什麼 Skill 也需要定期「瘦身」。 OpenAI Developers:Rethinking skills and prompts for GPT-6 Astra 7. Anthropic|Agent SkillsAnthropic 對 Agent Skills 的完整概念說明。 包含: Skill 架構 Progressive Disclosure VM Scripts References Skill Trigger Anthropic:Agent Skills 官方文件 8. Anthropic Engineering|Equipping agents for the real world with Agent Skills想理解 Progressive Disclosure,非常推薦這篇。 Anthropic Engineering:Equipping agents for the real world with Agent Skills 9. Agent Skills Open Standard如果你要自己開發 Skill,非常建議直接收藏規格。 目前核心格式就是: 12345skill-name/├── SKILL.md├── scripts/├── references/└── assets/ Agent Skills Specification 10. Agent Skills GitHub開放規格、文件與相關開源內容。 Agent Skills GitHub 11. OpenAI Developers|Skills 與 MCPOpenAI 對 Skills 與 MCP Server 分工的說明,可對照本文第三節。 OpenAI Developers:Skills 給自己的提醒以後再看到新的 Skill,不要第一時間問: 「我要不要安裝?」 先問: 「它解決的是我的哪一個工作流程?」 而每一次自己把一件事情做到滿意之後,也不要直接關掉對話。 最後多問 Agent 一句: 「把我們這次成功的流程蒸餾成一個 Skill。」 長期累積下來,那才會真正變成自己的 AI 能力庫。 常見問答 (FAQ)Q1:MCP 和 Agent Skill 的差別是什麼?MCP Server 提供 Agent 可使用的即時資料、工具、授權與受控動作;Skill 則描述完成一類工作的步驟、工具使用順序、判斷點與輸出要求。簡單記法是 MCP 提供能力,Skill 說明如何把能力用在工作流程裡。 Q2:建立自己的 Skill Library,第一步應該做什麼?先挑一個經常重複、而且已有成功案例的工作。整理它的輸入資料、固定步驟、決策規則、常見例外與成功輸出,再把穩定流程寫成一個 Skill;細節資料則視需要拆到 references/、assets/ 或 scripts/。 Q3:Skill 是不是越多越好?不是。從一個常見工作開始,確認它確實能減少重複說明或提升流程一致性,再逐步擴充。Skill 數量增加時,也要檢查描述是否重疊、觸發時機是否清楚,並用代表性案例測試它該啟動與不該啟動的情境。 Q4:使用外部 Skill 前需要檢查什麼?先閱讀 SKILL.md 和支援檔案,特別檢查 scripts/、依賴套件、網路請求、檔案讀寫、環境變數及刪除操作。只有在了解它會執行什麼、存取哪些資料與權限後,才決定是否使用。

  • article-Claude Opus 5.5 做影片到底有多強?一次看懂能力、Token 消耗與 AI 影片工作流

    2026/9/28

    AI工具 AI自動化 影音行銷
    Claude Opus 5.5 做影片到底有多強?一次看懂能力、Token 消耗與 AI 影片工作流

    最近我一直在研究 Claude Opus 5.5 做影片的案例。越看越覺得,這波值得注意的事情,不是「Claude 也會做影片了」,而是 AI 開始能把影片製作當成軟體工程專案來完成。 這和我們熟悉的 Veo、Seedance、MiniMax H3 等生成式影片工具,走的是不同路線。以前常見的流程是: 1提示詞 → 影片生成模型 → MP4 而程式化影片的流程更像: 1提示詞 → AI Agent → 程式碼 → 動畫引擎 → Render → MP4 Anthropic 在 2026 年 9 月 22 日推出 Claude Opus 5.5,官方將它定位為適合長時間 Agentic Coding 與知識工作的模型。這篇文章談的「做影片」,是讓模型在 Agent 工具、動畫框架與 Renderer 的協助下寫程式、反覆檢查並組裝成片;不是把 Opus 5.5 當成直接生成電影鏡頭的影片模型。Anthropic:Claude Opus 5.5 Claude Opus 5.5 做影片,實際上是在做什麼?如果你交代 Agent:「幫我製作一支 90 秒的科普動畫」,它可以先協助拆解主題與旁白,再規劃分鏡、場景、動畫節奏和字幕,接著在有提供適當工具與執行環境的前提下,建立 HTML、Canvas、SVG、Three.js 或 Remotion 專案,執行程式、檢查輸出、修改動畫,最後再串接 TTS、字幕或 FFmpeg。 所以更精確地說,Claude 負責理解需求、產生與修改程式、安排工具;動畫引擎負責呈現畫面;TTS、音效、FFmpeg 或剪輯工具則完成聲音與影片輸出。模型能否直接操作這些工具,要看你使用的 Agent、權限與環境設定。它不會只靠模型本身就自動完成上述每一步。 環節 Agent 可協助的工作 實際執行者 企劃與分鏡 拆解主題、旁白、Scene 與時間軸 Claude 與創作者 Review 動畫實作 建立 SVG、Canvas、Three.js 或 Remotion 程式 Agent 編輯檔案,動畫框架執行 聲音與字幕 整理旁白、字幕和時間標記,呼叫 TTS 外部 TTS、字幕工具或剪輯軟體 輸出與檢查 呼叫 Render、讀取輸出結果並修正問題 Renderer、FFmpeg 與可用的 QA 工具 **影片不是單純的媒體檔案,也可以是一套可重複產生影片的程式專案。**這個差異,是理解 Opus 5.5 影片工作流的起點。 為什麼 Agent 做影片可能會累積數百萬 Token?我看到的個別案例分享中,有人提到用 Opus 5.5 做一支科普動畫,約 30 分鐘完成,整段 Agent 工作階段累積約 500~600 萬 Token。這是單一案例的分享,不是 Anthropic 公布的影片製作平均值;如果沒有 API usage 明細、平台計算方式和完整執行紀錄,也無法單憑總 Token 數推算出精確費用。 Agent 不是只回答一次。它可能反覆讀取需求和程式、執行專案、檢查輸出、修正錯誤,再重跑 Render。程式碼量、工具輸出、Context 長度、修改輪數、QA 次數,都會讓不同專案的用量差很多。 比起只看成片幾分鐘,更有參考價值的問題是:有多少個 Scene?Agent 讀了多少程式和輸出?改了幾輪?重跑幾次?有沒有用 Prompt Caching?是否加入 TTS、音訊分析或自動 QA? Token 總量不等於同價的計費量以 Anthropic API 公布的 Claude Opus 5.5 標準價格為例,每百萬 Token 的一般 Input 為 US$4、Output 為 US$20;5 分鐘 Cache Write 為 US$5、1 小時 Cache Write 為 US$8,Cache Read 為 US$0.20。這些是本文撰寫時的 API 價格;不同產品方案、雲端平台、快速模式或後續調價可能不同,實際估價請以官方價格頁為準。 計費項目 用途概念 Opus 5.5 標準 API 價格(每百萬 Token) Input 送進模型、未命中快取的內容 US$4 Cache Write 首次將可重用內容寫入快取 5 分鐘 US$5;1 小時 US$8 Cache Read 後續讀取已快取的內容 US$0.20 Output 模型產生的文字或程式碼 US$20 假設一份用量報表中,Input 是 100 萬、Cache Read 是 400 萬、Output 是 100 萬,這三類加總是 600 萬 Token;依上述標準 API 價格試算,這三項約為 US$24.80,尚未計入 Cache Write、其他平台費用或可能適用的價格條件。這只是示範算法,不代表前面提到的個案實際帳單。 看帳單或用量頁面時,先確認 Input、Cache Write、Cache Read 與 Output 的定義,以及介面是否已將快取項目包含在總數裡,再分項估價;不要把所有 Token 都乘上 Output 的單價。 影片長度只能當粗略參考下面是原稿提出的工作量區間,只適合當作概念估算,不是官方規格、業界平均或保證值。影片腳本是否既有、場景複雜度、程式碼是否重用、Context 管理、Agent 次數及平台記帳方式,都可能讓結果大幅不同。 製作規模 原稿提出的 Token 概念區間 簡單 10~20 秒 Motion Graphics 數十萬 Token 等級 30~60 秒程式動畫 數十萬到百萬 Token 等級 約 90 秒科普動畫 百萬 Token 等級 複雜 MV 或多場景長時間自主 Agent 數百萬,甚至可能超過千萬 Token 哪些影片適合用程式來做?程式動畫特別適合畫面元素可明確描述、位置與時間能被控制的內容。它不是每種影片的替代方案,但在資訊正確、文字清晰或需要重複修改時,有自己的優勢。 Motion Graphics 與品牌動畫動態文字、Logo Animation、資訊圖表、數字動畫、線條、粒子、UI 動畫、字幕和轉場,都很適合用程式精準控制。若指定顯示「2026 AI Agent」,程式就能照規格排版,不會像影像生成一樣把字形畫錯。真正的品牌標誌仍應使用已核實的素材檔,不能讓模型憑空仿製。 科普與知識型動畫以「疫苗如何作用?」為例,可以將內容拆成免疫系統、抗原、抗體和記憶細胞,再為每個段落建立 Scene,串上旁白、字幕和動畫。這類影片若重點在資訊清楚、流程正確與方便修訂,SVG 或 Canvas 動畫有時比直接生成影像更合適。科學內容仍需專業查核,動畫只負責呈現,不能代替事實驗證。 像素風 MV 與歌詞動畫可將歌詞與音樂段落整理成時間軸,為每段設計 Pixel Art 場景,再用程式控制角色、背景和字幕切換,最後把音樂、畫面與字幕合成。這讓大量重複的時間軸工作更容易自動化,但美術方向、歌詞解讀與節奏感仍值得由人 Review。 Data Visualization Video給 Agent 一份 sales.csv,讓它協助找出重點、建立圖表、編寫旁白,再輸出 60 秒報告影片。這裡最重要的是數字從資料讀取,而不是讓生成模型自行猜測。例如營收 NT$3,582,000,就要由資料欄位帶入畫面,並驗證計算與標示正確。 生成式影片搭配 Motion Graphics實務上不必在「AI 影片」和「程式動畫」之間二選一。可以用生成式影片提供人物、場景或電影感素材,再由程式動畫加上字幕、Logo、圖表、歌詞、轉場與時間軸,最後使用 FFmpeg 或剪輯軟體合成。 工作路線 主要負責內容 常見適用場景 Generative Video 生成角色、場景、鏡頭與氛圍 真人感、電影畫面、場景運鏡 Programmatic Video 以程式控制文字、圖表、UI 和動畫 資訊圖表、教學、品牌字卡、歌詞動畫 混合工作流 生成式素材加上程式化資訊與剪輯 品牌影片、音樂 MV、知識型短片 影片也開始變成軟體專案以前要把片中的「2025」改成「2026」,可能得回剪輯軟體逐段修改。如果影片以程式生成,年份可以是變數;公司名稱、品牌色、業績資料與語言也可以從設定檔或資料表帶入。 同一套模板因此有機會產生 A 公司、B 公司和 C 公司版本,或依照不同資料自動更新圖表。這時,產物不只有 MP4,也包含一套可維護、可重複執行的 Video Generator。 但程式化並不代表沒有 QA。仍要檢查字幕是否正確、圖表是否引用正確資料、音畫是否同步、輸出解析度和影片長度是否符合規格。自動 Render 只是流程的一部分,不能取代成片檢查。 Video Engineering Prompt:把影片需求寫成規格傳統 AI Video Prompt 常描述鏡頭、光線、角色、運鏡與風格。程式化影片還需要把需求寫成 Agent 能執行的製作規格,例如: 解析度、畫面比例與輸出格式 每個 Scene 的內容、順序與 Duration Timeline、轉場、動畫與 easing 字型、Typography、字幕與安全區 旁白、TTS、音效、音樂和音訊時間點 使用的 Renderer、Render 指令和檔案結構 QA 條件:文字、資料、時間長度、解析度與輸出檔案 這已經很接近一份影片 PRD。Prompt 不只是說「做得漂亮一點」,還要交代輸入素材、限制、時間軸、驗收條件和交付格式。規格越清楚,Agent 就越容易在可檢查的範圍內工作。 下一階段:Agentic Video Production我會把這種做法稱為 Agentic Video Production(Agent 化影片製作):人提供主題、音樂、歌詞、素材和輸出要求,Agent 協助規劃、寫程式、呼叫工具、Render,再根據檢查結果修正。 人仍然要負責方向、審美、素材權利與最後 Review。Agent 可以接手很多重複的製作步驟,但工具是否能互相呼叫、影片能否一次做對、素材是否合用,都取決於實際工作流和 QA。 所以我看 Claude Opus 5.5 做影片,真正感興趣的不是「Claude 會生成影片了」,而是:**影片製作也開始能透過自然語言和程式工作流來建構。**這件事和 Vibe Coding 很像,讓不熟悉動畫或剪輯的人,也有機會把自己的影片製作流程做成可重複使用的工具。 如果你也在建立自己的影片流程,可以延伸閱讀用 Codex 打造 AI 影片工廠與AI 影片生成的價值轉移。 常見問答 (FAQ)Q1:Claude Opus 5.5 可以直接輸出 MP4 嗎?Opus 5.5 本身不是專門直接輸出影片畫面的生成模型。它可以在提供 Agent、程式執行環境與相關工具時,協助產生動畫程式、呼叫 Renderer 或 FFmpeg,再把輸出組合成影片;實際能力取決於你配置的工具和工作流。 Q2:Agent 工作階段累積 600 萬 Token,代表影片要花很多錢嗎?不能只看總 Token 數。一般 Input、Cache Write、Cache Read 與 Output 的價格不同,也要確認平台報表如何計算快取用量。最好取得實際用量明細,依模型、平台和當時價格分項估算;沒有明細時,個案總數只能作為工作量參考。 Q3:什麼類型的影片最適合用程式製作?需要精確文字、數據、圖表、UI、字幕、時間軸或多版本重複輸出的影片,通常較適合程式化動畫。真人表演、電影感鏡頭與複雜場景可搭配生成式影片,再用程式處理資訊圖層、字幕和剪輯。

  • article-Codex Skill 與 Plugin 到底差在哪?從個人工作流到團隊交付

    2026/9/27

    AI工具 AI Agent Codex
    Codex Skill 與 Plugin 到底差在哪?從個人工作流到團隊交付

    最近我在研究 Codex Skill,發現 Agent 的擴充方式正逐漸變得清楚。以前看到好用的 Skill,我會想:下載、放進 Codex,自己開始用。但如果做出一套能重複使用的工作流,想交給十位學員、五十位同事,甚至其他公司安裝,接下來就不只是「怎麼寫好一份 SKILL.md」了。 像是 MiniMax H3 影片提示詞整理、Slide Manifest 簡報流程、社群文章產生、課程企劃、AI 影片 Shot Manifest,或企業內部 SOP,都可能先從個人方法開始,最後變成團隊希望共用的能力。理解 Skill、Plugin 與 MCP 各自負責什麼,能幫我們用合適的結構保存這些方法。 先用四個概念拆開來看 元件 負責什麼 可以怎麼理解 Prompt 告訴 AI 這一次要做什麼 單次任務說明 Skill 描述一類工作怎麼完成,包含步驟、判斷、範例與資源 可重複使用的工作流程或 SOP MCP Server 提供 Agent 可呼叫的工具、即時資料或動作 能操作的工具入口 Plugin 把一個或多個 Skill,以及可選的 MCP、資源等組成套件 能安裝與管理的能力包 因此,我平常會把 Skill 記成「工作方法」,把 Plugin 記成「套件包裝」。Skill = Function、Plugin = Package 可以當作方便記憶的比喻,但它不是嚴格的技術等式:Plugin 裡可以只有一個 Skill,也可以加入 MCP Server 等元件。 Skill 是 Agent 能重複遵循的工作方法Skill 通常是一個資料夾,核心是 SKILL.md,必要時再放入參考資料、範本、資產或腳本。它會交代什麼情況適用、要收集哪些輸入、如何做判斷、按什麼順序執行,以及怎樣算完成。 例如 minimax-h3-prompt-standardizer 這類工作流,可以教 Codex 如何分析影片需求、拆分生成單元、處理人物與場景一致性、規劃鏡頭,再整理成適合模型使用的提示詞。Skill 教的是如何做這件事;影片仍由相應的模型或工具生成。 Skill 的價值在於把個人的 Know-how 寫成可以複用、檢查和持續修正的流程。模型可以更換,成熟的工作步驟、範本與品質標準仍能留下來。若你正在整理 Skill 與 Agent 執行環境的關係,也可以參考我之前寫的從 Skill 到 Agent Harness。 Plugin 是組合與交付能力的套件Plugin 的任務是把可重複使用的能力整理成一個有名稱、版本與結構的套件。官方架構允許 Plugin 包含一個 Skill,也可以放入多個相關 Skills;需要連接外部服務時,還能搭配 MCP Server。依套件需求,也可包含資產、生命週期 hooks 或選用介面。 可以想像一個「AI Video Production Plugin」包含故事規劃、Shot Manifest、H3 Prompt、影片檢查等 Skills,再視需求連接素材庫或其他工具。使用者安裝的是一套有關聯的能力,維護者則能一起整理套件版本與分發方式。 Plugin 不等於「把所有能力塞在一起」。官方建議從符合使用情境的最小結構開始;工作流程只需要說明和既有工具時,Skill-only Plugin 已經足夠。 2026 年 9 月的重要更新:官方明確支援 Skill-only Plugin截至 2026 年 9 月,我特別留意到 OpenAI 舊的 openai/skills repository 已標示 deprecated,並把目前的 Codex Skill 與 Plugin 範例導向新的 openai/plugins repository 與 Plugins 文件。官方文件也明確寫出,Plugin 可以只包含 Skills,不需要 MCP Server。 這不代表 Skill 失去獨立價值。Skill 仍是工作流程本身;改變的是,當我們需要依照新的 Plugin 格式整理、安裝或交付 Skills 時,可以直接用 skill-only plugin 作為套件結構。概念從 Skill 開始思考,交付時再判斷是否包成 Plugin,會是實用的路徑。 新版文件中的 portable Plugin 以根目錄 plugin.json 作為 manifest,Skills 放在 skills/,需要時再加入 mcp.json 與資產等內容。.codex-plugin/plugin.json 仍是相容格式;OpenAI 的 Plugin Creator 也能產生相容布局。開始建立套件前,請依目前目標平台與官方文件選擇格式,不要把舊範例路徑當成唯一結構。 一個最小的 Skill-only Plugin 可以概念化為: 12345my-first-plugin/├── plugin.json└── skills/ └── hello/ └── SKILL.md 這份套件可以只有說明、範本和其他工作資源,沒有 MCP、API、資料庫或 Connected App。它仍然是一個 Plugin,因為 Plugin 的核心價值是以可辨識的結構組合與交付能力,而不是一定要連外部服務。 MCP 與 Skill 的分工:一個教流程,一個提供工具如果希望 Agent 讀取 Google Drive、查詢 CRM、建立文件或更新 Notion,Skill 可以說明何時呼叫工具、如何判讀結果,以及怎樣完成後續步驟;MCP Server 則提供 Agent 實際可呼叫的工具與資料連線。 簡單來說: 123Skill = 說明怎麼完成工作MCP = 提供可呼叫的工具與即時資料Plugin = 將 Skill 與需要的工具配置等包在一起 技能文件不會自動帶來外部帳號權限,也不會讓沒有連接的服務突然可用。實際能做什麼,仍取決於已安裝的工具、使用者授權、服務端權限,以及執行環境。 什麼時候用 Skill,什麼時候包成 Plugin? 使用情境 建議起點 判斷方式 個人想固定文章、研究或簡報流程 Skill 流程清楚,現有工具已足夠 想讓一套成熟流程方便安裝與更新 Skill-only Plugin 交付與版本管理比額外工具更重要 多個緊密相關的 Skills 要一起使用 Plugin 使用者需要安裝一組有共同目的的工作流 流程還要讀寫外部服務 Plugin 加 MCP Server Skill 描述判斷步驟,MCP 提供受控工具 不需要等到 Skill 累積到某個固定數量才開始考慮 Plugin。只要一個成熟的 Skill 已經需要被標準化交付,skill-only plugin 就可能有用;反過來說,很多互不相關的 Skills 也未必適合硬包成一個 Plugin。關鍵是安裝、更新與使用情境是否一致。 從個人 Know-how 走到團隊工作流以公司 Sales Plugin 為例,可以先整理會議準備、客戶研究、會議摘要與 Follow-up Email 等工作方法,再確認哪些步驟需要 Gmail、Calendar、CRM 或 Drive 工具支援。Skill 寫清楚流程與判斷,MCP 讓 Agent 呼叫服務,Plugin 則把相關能力整理成團隊可管理的套件。 實際導入時,還要分別處理登入、資料範圍、使用者授權與企業政策。安裝套件不等同於取得 CRM 或公司雲端資料的存取權;這些存取能力必須由服務整合與管理設定明確提供。 這也提供一條較自然的發展路徑:先自己完成一項工作,記錄穩定的 SOP,整理成 Skill 並反覆使用;當流程需要工具時再連接 MCP 或 App;當能力需要成套維護與交付時,再包裝成 Plugin。先把真實工作做好,之後再依重複模式模組化,能避免一開始就替尚未驗證的需求建造太大的架構。 知識產品也可能從「教你做」變成「依方法幫你做」書、課程、影片、PDF 和範本通常傳遞的是知識,使用者還需要自己把它轉成行動。Skill 能把部分 Know-how 寫成 Agent 可遵循的工作流程;Plugin 則能進一步把相關流程、工具配置與資源組成一套交付物。 這讓課程設計也有新的方向:除了教 Prompt、圖像或影片工具,還可以教學員分析工作、建立 Skill、判斷何時需要 MCP,再把成熟且有共同目的的 Skills 包成 Plugin。交付的內容不只是「知道怎麼做」,也可以是讓 Agent 依照方法完成工作的起點。 結語:先設計 Skill,再依交付需求決定 Plugin我目前會這樣記:Prompt 交代這一次的需求;Skill 保存一類工作的 Know-how;MCP 或 App 提供 Agent 可使用的能力;Plugin 將一個或多個 Skills,以及需要的工具與資源整理成套件。 所以,個人工作流可以先從 Skill 開始。當它需要版本化、團隊共用、搭配多個相關工作流或連接工具時,再考慮用 Plugin 交付。OpenAI 在 2026 年 9 月明確提供 skill-only plugin 路徑,也讓「先設計 Skill,交付時採 Plugin 結構」成為值得採用的預設思路。 常見問答 (FAQ)Q1:Codex Skill 和 Plugin 最大的差異是什麼?Skill 描述 Agent 如何完成一類工作,通常包含指示、判斷步驟與支援資源;Plugin 是安裝與交付套件,可以包含一個或多個 Skills,並可選擇加入 MCP Server、資產等元件。 Q2:Skill-only Plugin 需要 MCP Server 嗎?不需要。OpenAI 官方 Plugin 架構支援只包含 Skills 的 Plugin。當工作流程仰賴外部服務資料或動作時,才需要再評估 MCP Server 或其他可用的工具連線。 Q3:要分享 Skill,就一定得包成 Plugin 嗎?不一定。個人使用或簡單分享可以先維持 Skill 的形式;若需要標準化安裝、一起管理版本,或與相關 Skills 和工具配置成套交付,就可以改用 Plugin。選擇應配合使用者與維護方式。 Q4:安裝 Plugin 後,Agent 就能操作我的 Google Drive 或 CRM 嗎?不一定。Plugin 需要包含或連接相應工具,服務端也要有適當的登入、授權與資料權限。Skill 說明工作流程,本身不會授予外部帳號的存取權。 官方參考資料 OpenAI Plugins 官方文件 OpenAI Plugins GitHub OpenAI Skills 說明 舊版 OpenAI Skills repository deprecated 公告 Plugin 架構 Plugin 封裝格式

  • article-MiniMax H3 提示詞怎麼寫?用 Codex Skill 建立 AI 影片工作流

    2026/9/27

    AI工具 Codex 影音行銷
    MiniMax H3 提示詞怎麼寫?用 Codex Skill 建立 AI 影片工作流

    做 AI 影片時,很多人會先研究「提示詞要怎麼寫」。但影片做得越多,越容易發現真正重複消耗時間的,是每次都得重新想:人物怎麼描述、鏡頭如何移動、動作要拆幾段、台詞怎麼保留、參考圖怎麼指定,以及哪些限制值得寫進提示詞。 與其每次從頭整理,不如把這些經驗交給一個可重複使用的 Skill。本文以 MiniMax H3 Prompt Standardizer 為例,介紹如何把一句畫面構想整理成較完整的影片提示詞,並說明如何在前面加上 Shot Manifest、在後面接續生成佇列與檢討紀錄,逐步建立一套自己的 AI 影片工作流。 先說清楚範圍:這個專案是 Codex Skill,負責整理提示詞與分段規劃;它本身不是 MiniMax H3,也不會直接生成或剪輯影片。提示詞是否能達到預期,仍取決於實際使用的模型、參考素材、產品版本與生成設定,不能保證一次成功。 MiniMax H3 Prompt Standardizer 在解決什麼問題?可以把這個 Skill 想成一個「Prompt Compiler」:使用者用自然語言描述想法,它再把人物、場景、動作、運鏡、聲音和限制整理成比較清楚、可複製的提示詞。 沒有固定整理流程時,工作大致是: 1234567畫面想法 ↓自己研究提示詞 ↓反覆修改 ↓交給影片模型 使用 Skill 後,提示詞整理步驟可以變得可重複: 123456789畫面想法或劇本 ↓Codex ↓MiniMax H3 Prompt Standardizer ↓整理後的 H3 提示詞 ↓MiniMax H3 或其他影片工具 專案的 SKILL.md 說明,它可以處理一句話、既有長提示詞、故事、劇本、對白、廣告構想、分鏡清單,以及參考圖片等輸入;依需求擴寫、精簡、修補提示詞,或規劃多段生成。它也把文字生成影片、圖片參考、多張參考圖、首尾幀、對白與聲音等列為提示詞整理情境。這些是 Skill 的提示詞工作範圍,不代表每個 MiniMax H3 介面或帳號都支援相同功能;使用前仍要確認目前產品可用的輸入模式與限制。 比方說,輸入: 1一個女生在雨夜車站等人,8 秒,16:9。 Skill 可以補出一份較清楚的描述,涵蓋人物、場景、主要事件、鏡頭流程、光線、色彩、聲音和必要的防錯條件。重點不在於把一句話變得很長,而是讓每一項資訊都有明確作用。 先決定一段影片要完成什麼,再寫提示詞這個 Skill 的一個實用做法,是在輸出前先判斷需求形狀:要用哪種生成方式、內容是對話還是動作、適合一鏡到底還是多鏡、需要什麼時長、故事是否要拆段,以及每段在哪個畫面節點結束。 它的規則建議在沒有指定時,為單次生成挑選合理時長,並以每段最多約 15 秒作為規劃參考。這是 Skill 的工作流建議,不是 MiniMax H3 的官方時長上限;實際能輸入的秒數要看當下使用的產品與模型設定。 故事很長時,切段也不應只依字數平均分配。每段最好是一個可以完整看見的微事件或情緒節點,避免把尚未完成的動作、姿勢或情緒硬拆在兩次生成之間。可以優先在下列變化處切開: 鏡頭景別或視角改變。 場景、時間或主要人物改變。 一個動作已經完成,下一段開始新的事件。 角色完成一個情緒節點,後面進入新的反應。 例如「跑進咖啡廳、認出前任、停下來對望、哭泣、放下戒指、轉身離開」其實包含場景建立、跑步、視線互動、表情變化、道具互動和情緒轉折。把所有事件都塞進短短幾秒,模型需要同時安排太多變化。可以先找出哪些動作能構成一個完整鏡頭,再決定每段提示詞要負責的內容。 這裡的關鍵是先定義 Generation Unit(單次生成單位),再寫 Prompt。與運鏡、攝影語言有關的延伸閱讀,可參考從 Google Flow 的 /orbit 學 AI 影片運鏡提示詞;更完整的 Skill 製片流程則可看從 Prompt 到專家 Skill 的 AI 影片製片工作流。 如何安裝與第一次使用?這個 GitHub 專案的根目錄包含 SKILL.md,因此可以從該 repo 安裝。若你的 Codex 版本提供內建 $skill-installer,可以在 Codex 輸入: 1$skill-installer install https://github.com/sengseng123/minimax-h3-prompt-standardizer 也可以把 Skill 放進個人技能資料夾。Codex 目前文件列出的個人本機 Skill 位置是 $HOME/.agents/skills: 123mkdir -p "$HOME/.agents/skills"git clone https://github.com/sengseng123/minimax-h3-prompt-standardizer \ "$HOME/.agents/skills/minimax-h3-prompt-standardizer" 安裝前先檢視 repo 裡的 SKILL.md 與其他檔案,確認這份指示適合你的工作方式。這個專案的核心內容集中在 SKILL.md,另有 agents/openai.yaml 供支援該格式的介面顯示名稱或描述。Codex 會自動偵測本機 Skill;若清單沒有出現,再依目前版本文件重新啟動 Codex。安裝目錄可能隨 Codex 版本與安裝方式不同,請以官方技能文件列出的載入位置為準。 第一次使用時,可以在 Codex 輸入: 1234使用 $minimax-h3-prompt-standardizer:一個女孩在雨夜車站等待某人。8 秒,16:9,真人風格,不要字幕。 短構想提供了主角、事件、時間、比例和一項畫面限制,其他細節再由 Skill 依規則補齊。若結果偏離原意,直接指出要改的人物、鏡頭、節奏或風格,不需要先學會專業術語。 什麼情況適合直接交給 Skill?單一情境、短時間、只有一個主要事件時,可以直接請它整理提示詞。例如: 12345使用 $minimax-h3-prompt-standardizer:幫我做一段 10 秒影片。台灣女生坐在深夜便利商店窗邊,窗外下著雨,她低頭讀到一則令人難過的訊息。真人實拍,16:9,不要字幕;情緒壓抑但不要過度戲劇化。 輸入可以口語、簡短,也可以是一段既有提示詞。使用者不必先決定所有鏡頭術語;若某個缺少的資訊真的會改變結果,Skill 才應該提出簡短問題。這符合專案的方向:讓人描述想完成的畫面,而不是要求每個人先學會 Prompt 工程。 長故事先加一層 Shot Manifest如果要做 MV、短劇、品牌影片、多場景廣告或一段較長的連續劇情,我會在提示詞整理前先建立 Shot Manifest(鏡頭規格表): 123456789故事或腳本 ↓Shot Manifest ↓H3 Prompt Standardizer ↓單段生成提示詞 ↓影片生成與檢查 Shot Manifest 是本文建議加在工作流前段的規格,不是這個 GitHub 專案內建的功能。它的用途是把故事邏輯和模型生成條件分開:編劇先決定角色、情節和情緒;分鏡規格再交代每一鏡的人物狀態、具體事件、動作方向和結尾。 我會讓每個 Shot 至少包含: Shot ID 與目的:這個鏡頭在故事裡要完成什麼? 建議時長與場景:預計生成多久、在哪裡、什麼時間? 人物與參考素材:畫面有哪些角色,哪些參考圖要鎖定人物或環境? 核心事件:這一鏡只需要讓觀眾看懂哪件事? 起始狀態與結束狀態:鏡頭開始時是什麼畫面,最後停在哪裡? 動作流程與運鏡:人物朝哪裡移動,鏡頭如何配合? 聲音:有哪些對白、環境聲、動作聲或配樂? 連續性與銜接點:服裝、道具、人物方向與光線如何延續?下一鏡從什麼畫面接起? 例如,故事「女孩走進空蕩的月台,停下來等待」可先拆成: 1234567891011121314SHOT 01目的:建立人物與月台環境建議時長:5 秒場景:夜晚、空蕩的室內月台人物:女孩核心事件:女孩走進月台中央並停下起始狀態:鏡頭看見空月台結束狀態:女孩站定,視線望向月台一側運鏡:中遠景緩慢推近參考素材:角色參考圖、月台場景參考圖聲音:遠處列車聲與室內環境音連續性:下一鏡延續同一服裝、站位與光線方向銜接點:以女孩轉向月台入口作為下一鏡起點 完成後再逐鏡轉成 H3 提示詞: 123使用 $minimax-h3-prompt-standardizer,把 SHOT 01 整理成 MiniMax H3 提示詞。保留人物、場景、起始狀態與結束狀態;不要新增事件。 這多一層整理,能先發現故事分段和素材規劃問題,不必等影片生成後才發現一段裡安排了太多事件。 多張參考圖要先標明各自用途如果會上傳多張圖片,先說清楚每張圖負責什麼,並指定有衝突時以哪張為準。比如: 123456789使用 $minimax-h3-prompt-standardizer。圖片 1 是人物主要參考,鎖定臉部與髮型。圖片 2 補充服裝與體型。圖片 3 是場景參考,鎖定空間與光線方向。圖片 4 是商品外觀參考。請整理一段 10 秒廣告提示詞:人物走進咖啡廳,坐下後拿起圖片 4 的商品。人物與商品外觀以主參考圖為準。 專案的規則建議在正式提示詞前,先以 @圖片1、@圖片2 等標記列出上傳順序、主要參考和鎖定資訊。參考圖可能彼此衝突,也可能帶著不需要的背景、姿勢、浮水印或介面文字;要說明哪些視覺資訊應保留,哪些應忽略。不要指示 Skill 描述它沒有收到的素材。 對白與 Lip Sync 要提供可執行的細節如果畫面裡有人說話,只提供一句台詞通常不夠。可以補充說話者、說話時間、視線、呼吸、停頓、情緒與聲音質地: 1234567說話者:台灣女生,約 25 歲,聲音自然,不要播音腔。情緒:像是忍住眼淚,語速稍慢,中間停頓一次。台詞:「你終於來了。」台詞必須逐字保留,不要改寫。請讓嘴型與說話時間對齊。 這個 Skill 的規則明確要求,除非使用者要求改寫,否則保留原始台詞;也建議交代誰在何時說話、聲音情緒、停頓和嘴型同步。實際對嘴表現仍受生成工具和素材影響,提示詞只能交代目標,不能保證結果。 把抽象形容詞換成看得見的描述「電影感」、「高級感」、「震撼」、「史詩」或「絲滑」,本身很難告訴模型畫面該如何安排。試著把這些詞拆成可以觀察的鏡位、動作、光線、色彩、節奏與材質。 例如: 12345模糊:人物以很有電影感的方式走過來。具體:低機位中景跟拍,人物由畫面左後方走向右前方;鏡頭穩定地緩慢後退,背景保持淺景深,暖色街燈在遠處形成柔和散景,人物臉部保留自然陰影。 如果要描述角色動作,則交代方向、重心、原因、反應、與環境的互動,以及動作結束時的姿勢。例如「男子向左揮拳,女子側身閃避,身體重心轉到左腳;拳頭擦過肩膀,碰倒後方桌上的紙杯,男子收拳後停在她右前方。」比「兩個人激烈打架」更容易讓人看懂要生成的事件。 轉場用畫面元素銜接,而不是只喊「絲滑」要接兩個場景,可以先找一個可見元素作為轉場錨點,也就是 Match Element。例如第一鏡推近一把紅色雨傘,直到傘面填滿畫面;下一鏡從相似的紅色開始,再拉遠揭露那是咖啡廳的紅牆。這樣交代了前後畫面如何匹配,不必只寫「使用絲滑轉場」。 長故事也可以記錄前一鏡的結尾姿勢、人物方向、道具位置和光線,並指定下一鏡從哪裡接續。每段可以獨立生成,但規格表仍保留全片的連續性資訊。 聲音分層,提示詞會更清楚聲音可以分成三層描述: 對白:角色說話或旁白,包括內容、說話者、時機、語氣和停頓。 畫面內聲音(Diegetic Sound):角色也處在其中的雨聲、腳步聲、門鈴、杯子碰撞或遠處車聲。 畫面外配樂(Non-diegetic Sound):觀眾聽得到、但不是場景裡物件發出的背景音樂。 不要把三種聲音混成「加一點有氛圍的音效」。可以指定哪些聲音要突出、哪些只當背景,並只保留這個鏡頭真正需要的聲音設計。 防錯限制要針對場景挑選人物一致性、服裝變化、道具重複、手指異常、口型不符、人物瞬移、軸線反轉、鏡頭跳動、光線不連續、意外文字或風格漂移,都是常見的影片生成問題。不代表每個提示詞都要把整份負面限制貼一遍。 先想清楚當前 Shot 最可能失敗的地方,再補對應限制。例如人物拿著一杯咖啡並轉身時,可能要注意杯子不要複製、人物轉向保持一致;若只有遠景空景,手指或 Lip Sync 就不是需要處理的條件。限制越貼近畫面任務,越容易看懂它要避免哪種錯誤。 把單次生成接成可管理的工作流如果一部影片包含許多鏡頭,我會把它擴充成以下流程。這是本文整理的工作流建議;Generation Queue 與失敗知識庫不是這個 Skill repo 的內建功能: 1234567891011121314151617想法 ↓故事與劇本 ↓Shot Manifest ↓參考素材規劃 ↓H3 Prompt Standardizer ↓Generation Queue ↓影片生成 ↓人工檢查與重生失敗鏡頭 ↓剪輯軟體組片 Queue 可以用 Markdown 或試算表記錄每一鏡的提示詞檔案、參考素材、狀態與失敗原因: 1234567891011121314SHOT 001Status: ReadyReference: character-a.pngPrompt: prompts/shot001.mdSHOT 002Status: WaitingReference: character-a.png, room-a.pngPrompt: prompts/shot002.mdSHOT 003Status: RegenerateReason: 人物臉部在鏡頭中途改變Prompt: prompts/shot003-v2.md 狀態名稱可以依自己的流程調整,例如 Ready、Generated、Approved、Regenerate。記錄可以回答:哪些還沒生成、哪些已通過、哪些要重做,避免只靠記憶管理一長串鏡頭。 每次重生前也可以先寫一筆 Review: 1234567SHOT 07 Review問題:人物臉部一致性下降發生時間:約 4 秒觀察:鏡頭旋轉後臉部特徵開始改變可能原因:鏡頭旋轉幅度過大下一次調整:減少環繞幅度,增加正面停留時間,重新指定人物主參考圖 累積一段時間後,失敗紀錄便能整理成自己的 Failure Knowledge Base:哪些動作容易失敗、哪些運鏡會影響角色一致性、哪些參考圖組合較合適。這些紀錄是團隊自己的經驗,不應直接當成 MiniMax H3 的永久規則。 讓 Skill 符合自己的製作習慣原版 Skill 可以作為起點。若想做個人版本,可以複製後再加入自己的偏好,例如預設使用繁體中文、預設不加字幕、人物一致性優先、長故事先產生 Shot Manifest,或對話鏡頭避免劇烈環繞運鏡。 建議把「普遍有幫助的規則」和「特定專案偏好」分開。工作流規則可以告訴 Skill 如何判斷、如何輸出;專案偏好則描述你的影片風格與製作要求。無論如何擴充,都要清楚標示必要條件與可選建議,避免把過去某次成功的設定說成每個模型都適用。 可以直接保存的短片提示詞指令123456789101112131415使用 $minimax-h3-prompt-standardizer。請把以下內容整理成適合 MiniMax H3 的影片提示詞。若單次生成可以完成,輸出一段提示詞;若事件太多,拆成數段完整的 Generation Unit。每段保留一個主要事件,不要切開尚未完成的動作;優先在場景、視角、時間、人物或完整動作結束處分段。維持人物、服裝、道具、移動方向與光線連續。有參考圖時標明每張圖片用途,對白逐字保留。只加入這一鏡真正需要的防錯限制。不要自行加入字幕、Logo、浮水印或畫面文字。我的構想:{{貼上故事、劇本、既有提示詞或畫面想法}} 長故事先產生規格,再逐鏡產生提示詞若要處理 MV、短劇或多場景廣告,可以先要求 Codex 不要立即輸出影片提示詞: 12345678910111213以下是一個完整故事,請先建立 Shot Manifest,不要直接產生影片 Prompt。每個 Shot 都要是一個可在單次生成內完成的完整微事件,並列出:Shot ID、故事目的、建議時長、人物、場景、核心事件、開始狀態、動作流程、結束狀態、運鏡、光線、聲音、參考素材、與前一鏡的連續性,以及與下一鏡的銜接方式。完成 Shot Manifest 後,逐鏡使用 $minimax-h3-prompt-standardizer產生提示詞,最後另建 Generation Queue,記錄 Ready、Generated、Approved 或 Regenerate 狀態。故事:{{貼上完整故事}} 這個順序先把「故事如何拆鏡」和「每一鏡如何寫成模型提示詞」分成兩個任務。若想從更完整的製片視角延伸,也可以參考AI 影片製片工作流。 五分鐘快速操作1234567891. 安裝並檢視 MiniMax H3 Prompt Standardizer。2. 單一短畫面直接使用 $minimax-h3-prompt-standardizer。3. 長故事、MV 或短劇先建立 Shot Manifest。4. 逐鏡整理 H3 提示詞。5. 標示人物、場景與商品參考圖用途。6. 用 Generation Queue 管理待生成與待重做鏡頭。7. 生成後檢查人物、動作、聲音與連續性。8. 只針對失敗的鏡頭修改提示詞並重生。9. 將通過的鏡頭交給剪輯流程組成成片。 影片模型會更新,某些特定提示詞寫法也可能隨產品調整;但把故事、鏡頭、參考素材、生成與檢查拆成清楚步驟,能讓經驗留在工作流裡。與其每次從頭重寫 Prompt,不如把可重複的判斷整理成 Skill,把影片製作變成可檢視、可修正的流程。 常見問答 (FAQ)Q1:MiniMax H3 Prompt Standardizer 會直接生成影片嗎?不會。它是給 Codex 使用的 Skill,負責把畫面想法、故事或現有提示詞整理成影片提示詞;要生成或剪輯影片,仍需使用支援相應功能的影片工具。 Q2:只輸入一句話也能使用嗎?可以。專案設計上接受一句話構想,會依可合理推定的資訊整理提示詞。若時長、比例或其他缺漏會明顯改變結果,再補充條件即可;不用先掌握專業提示詞術語。 Q3:每段 15 秒是 MiniMax H3 的硬性上限嗎?不是。約 15 秒是這個 Skill 用來規劃單次生成的建議,不是 MiniMax H3 的官方產品限制。實際可用時長、參考素材模式與生成參數,請查看目前使用的 MiniMax 介面說明。 Q4:Shot Manifest 和 Generation Queue 是 Skill 內建功能嗎?不是。MiniMax H3 Prompt Standardizer 的核心是提示詞整理與分段建議;Shot Manifest、Generation Queue 和失敗紀錄是本文建議加上的工作流層,可以用 Markdown 或試算表自行管理。 Q5:安裝後沒有看到這個 Skill 怎麼辦?先確認 SKILL.md 位於 Codex 目前會掃描的本機 Skill 資料夾,並查看 Codex 的 Skill 清單;如果尚未載入,再依官方文件重新啟動 Codex,或更新資料夾位置。個人和專案層級的載入路徑可能不同,安裝前請先檢查目前版本的說明。

  • article-AI 做簡報總是大綱、PPT、講義對不起來?先建立 Slide Manifest

    2026/9/26

    AI工具 AI自動化 自動化講師應用
    AI 做簡報總是大綱、PPT、講義對不起來?先建立 Slide Manifest

    最近用 AI 製作課程簡報時,我常遇到一個麻煩:一開始明明規劃好課程大綱,最後的投影片和講義卻對不起來。 大綱列了 30 個重點,PPT 少了幾個。 大綱中的第 12 頁,到了簡報變成別的內容。 簡報放了完整 Prompt,講義卻沒有收錄。 講義的實作順序和投影片不同。 修改簡報後,講義沒有跟著更新。 AI 覺得兩頁內容相似,就自行合併成一頁。 這些狀況不一定是 AI 不會做簡報,而是課程大綱、PPT、講義和 Prompt Card 各自被重新理解了一次。每多一次重新解讀,內容就多一個走樣的機會。 我會在課程大綱和各種教材之間加上一層規格:Slide Manifest。先把每張投影片要完成的任務寫清楚,再從同一份 Manifest 產生簡報、講義、Prompt Card 和講師備註。 Slide Manifest 是什麼?可以把 Slide Manifest 想成整份課程簡報的施工藍圖,也是逐頁的規格表。課程大綱通常說明要教哪些主題;Manifest 則進一步說明每張投影片的目的、重點、呈現方式,以及是否要進入講義。 一般大綱可能只寫: 12345## AI 提示詞實作- 提示詞基本架構- Role / Task / Context- 實作 Facebook 貼文 人看得懂這些主題,但還需要決定要拆成幾頁、哪些元素放在一起、是否提供完整 Prompt,以及哪些內容要放進講義。Slide Manifest 把這些決定先記錄下來: 1234567891011121314- id: slide_011 section: "03" type: concept title: 提示詞不是咒語,而是一份工作說明書 learning_objective: 讓學員理解提示詞的基本概念 key_points: - AI 需要明確任務 - 提供角色與背景 - 指定輸出格式 visual: type: diagram concept: 使用者 → Prompt → AI → Output handout: include: true 下一頁可以獨立記錄提示詞的組成: 1234567891011121314- id: slide_012 section: "03" type: framework title: Prompt 四大元素 learning_objective: 讓學員辨識 Prompt 的基本結構 key_points: - Role - Task - Context - Output visual: type: four_block handout: include: true 實作頁則應把完整提示詞和交付物寫進規格,而不是只留下一個主題名稱: 12345678910111213141516171819202122- id: slide_013 section: "03" type: practice title: 實作:產生 Facebook 貼文 learning_objective: 完成第一個行銷文案 Prompt prompt: text: | 你是一位社群行銷顧問。 請根據以下資料撰寫 Facebook 貼文: 商品: 目標客群: 主要特色: 請輸出: 1. 標題 2. 貼文正文 3. CTA handout: include: true type: prompt_card 這樣每張投影片都有自己的 ID 與規格,後續產物便能對回原始頁面,而不必靠標題猜它們是否相同。 為什麼大綱、簡報和講義容易不同步?如果工作流程是「大綱 → AI 做 PPT → AI 做講義 → AI 做 Prompt Card」,每個產物都可能重新從大綱推導一次內容。即使每次理解只差一點,差異最後還是會累積: 123課程大綱 → 第一次解讀 → PPT課程大綱 → 第二次解讀 → 講義課程大綱 → 第三次解讀 → Prompt Card 加入 Manifest 後,流程改成先確認逐頁規格,再由同一份資料分別產生需要的教材: 1234Course Brief → Course Outline → Slide Manifest → QA ├─ PPT 與講師備註 ├─ 學員講義 └─ Prompt Card 與實作 這不表示課程內容永遠不能修改。它表示在產生不同教材時,先共用同一份已確認的逐頁規格;課程方向改變時,也要同步更新 Manifest,再產生受影響的產物。 每張投影片的規格要包含哪些欄位?剛開始不必設計成複雜的資料庫。先記錄足以界定每張投影片工作的欄位: 123456789101112131415161718192021222324id: slide_021section: "04"type: practicetitle: 實作:建立你的第一個 AI 工作流程learning_objective: 學員可以完成一個從輸入到輸出的 AI 工作流程key_message: 先定義資料如何進來、處理,再確認結果如何交付key_points: - 定義輸入 - 定義處理方式 - 定義輸出 - 測試結果visual: type: workflow content: 使用者輸入 → AI 分析 → 產生結果speaker_notes: - 先展示完成品 - 再拆解流程 - 最後讓學員實作handout: include: true type: labduration: 10source: outline_section: 4.2 最基本的欄位可包括 id、section、type、title、learning_objective、key_points、visual、speaker_notes、handout 和 source。如果課程會產生示範或實作,再補上 demo、practice、prompt、duration 等資訊。 為教學簡報補上實作與講師資訊教學課程通常還需要 key_message、demo、practice、prompt 和 duration。這些欄位可以說明本頁要讓學員帶走什麼、老師要示範什麼、學員要完成什麼,以及這一段預計花多少時間。 欄位名稱不是重點,定義清楚才是重點。例如 practice 不能只寫「做一個流程」,還要列出學員要操作的步驟和完成條件;prompt 若要進入講義,就應放入完整可使用的文字,而不是只留一個 Prompt 標題。 用 type 指定每頁的功能替每張投影片指定 type,能讓製作流程知道這頁要負責什麼工作。常見類型可以是: 123456789101112coversectionconceptframeworkcomparisonworkflowcase_studydemopracticepromptsummaryqna type: comparison 表示要呈現比較關係;type: prompt 則代表需要適合閱讀與複製提示詞的版型。Manifest 因此不只管理內容,也能連接簡報的 Design System。 建立 Slide Manifest 的建議流程1. 先整理 Course Brief在排頁面前,先寫清楚上課對象、課程時間、學員程度、學習目標、實作數量、是否需要 Prompt 或 Demo,以及是否需要學員講義。需求若還不明確,後面的逐頁規格也很難一次到位。 2. 編寫 Course Outline接著整理課程章節與要教的概念。例如「AI 工作流程概念」底下列出 Agent 是什麼、與 Chatbot 有何不同,以及有哪些工作流程案例。這階段先定義課程涵蓋範圍,不急著決定每個主題要做幾張投影片。 3. 將大綱拆成逐頁 Manifest逐頁決定 ID、章節、類型、標題、學習目標、重點、視覺方式、示範、實作、Prompt、講師備註、講義設定與大綱來源。每一頁都應能回答:「這張投影片在課程中負責什麼?」 可以用以下提示詞建立初稿: 12345678請根據以下課程大綱建立 Slide Manifest。此階段只規劃完整的逐頁架構,不要設計簡報或產生 PPT。每張投影片都要有唯一 ID,並記錄 section、type、title、learning_objective、key_message、key_points、visual、demo、practice、prompt、speaker_notes、handout 與 source。一個 Manifest 項目對應一張投影片。請勿自行合併、刪除或新增頁面。 4. 先做 Manifest QA,再做 PPT先審逐頁架構,確認它涵蓋課程大綱、頁面順序合理、ID 不重複、頁數符合預期,而且沒有實作或 Prompt 遺漏。再逐項檢查: 每個大綱主題是否都有對應的投影片? ID 是否唯一、連續,且沒有重複頁面? 每個學習目標是否具體? 每張實作頁是否包含步驟和完成條件? 每張 Prompt 頁是否附上完整提示詞? 每個 Demo 是否寫出展示目標? 標記要放進講義的頁面是否都有足夠材料? 投影片、實作、Prompt 和案例的數量是否符合課程規劃? 越早發現缺頁,越不需要在整份簡報完成後重排內容。 5. 讓 PPT、講義與 Prompt Card 共用 Manifest確認規格後,再要求 AI 依 Manifest 產生簡報。一個 Manifest 項目對應一張投影片,保留 ID、標題、Prompt 和實作的原意;可以調整視覺呈現,但不應在製作時自行新增、刪除或合併內容。 產生講義時,只處理 handout.include: true 的項目;handout.type 可以指定它要成為 Prompt Card、練習單或 Lab。speaker_notes 則可整理成簡報的講師備註。完成後再回頭比對每頁 ID 與 Manifest,確認簡報和講義沒有少頁、漏 Prompt 或順序錯置。 6. Manifest 定稿後做版本管理Manifest 確認後,可以記錄版本、狀態與頁數,例如: 123manifest_version: 1.0status: approvedslide_count: 58 當 status 是 approved,製作簡報時就不要靜默改動架構。若要修改第 27 頁,更新該頁規格、版本與變更紀錄,並重新產生受影響的簡報或講義。這個做法能保留修改脈絡,也方便確認哪些產物需要更新。 Manifest 不一定要用 YAMLYAML 適合放在可版本管理的課程專案裡,但剛開始也可以用 Markdown 表格、CSV、Google Sheet 或 Notion 資料庫。只要每張投影片有穩定 ID,且欄位能清楚描述規格,就能當作 Manifest 使用。 ID Type Title Learning Objective Key Points Visual Handout S01 Cover AI 辦公自動化 建立課程期待 課程名稱 Hero No S02 Concept 什麼是 AI Agent 理解 Agent 概念 自主、多步驟 Diagram Yes S03 Comparison Chatbot vs Agent 理解兩者差異 對話與執行 Comparison Yes S04 Practice 找出可自動化工作 完成流程盤點 輸入、流程、輸出 Worksheet Yes 使用熟悉的格式開始,通常比一開始花很多時間設計完美 schema 更實際。之後若要自動生成教材,再逐步把欄位整理成 YAML 或 JSON。 用 Codex 整理課程專案如果你用 Codex 製作課程,可以把規格、素材和產物分開放,降低檔案混在一起的機會: 12345678910111213141516171819/course-project README.md /course course-brief.md course-outline.md /manifest slide-manifest.yaml /content prompts.md labs.md cases.md /assets /images /icons /screenshots /output course.pptx handout.md prompt-cards.md 工作流程就是 course-outline.md → slide-manifest.yaml → QA → PPT、講義、Prompt Card。之後要改課程時,先更新規格,再重新產生相關交付物。 Slide Manifest 與 Design System 各自管什麼?Slide Manifest 定義每頁要講什麼、要完成什麼;Design System 定義頁面要如何呈現。前者可以記錄 type: prompt 與 layout: prompt_card,後者則規範字體、色彩、區塊與版型。兩者分工清楚後,內容架構和視覺設計就能各自維護,也能一起產出簡報。 用一份逐頁規格,減少教材不同步Course Outline 說明課程要教什麼;Slide Manifest 說明每一張投影片負責什麼;Presentation 則決定內容最後長什麼樣子。 如果簡報、講義、Prompt Card 和講師備註都各自從大綱重新推導,很容易出現漏頁、順序不一致或修改不同步。先建立並審查 Slide Manifest,再讓各種教材依同一份規格產生,能讓每份產物都對回同一張投影片。對需要長期維護、反覆開課或大量製作課程的團隊,這是值得先建立的一層內容規格。 常見問答 (FAQ)Q1:Slide Manifest 和課程大綱有什麼不同?Course Outline 列出課程主題與內容範圍;Slide Manifest 會進一步把內容拆成逐頁規格,記錄每張投影片的 ID、目標、重點、呈現方式,以及是否要放入講義或 Prompt Card。 Q2:Slide Manifest 一定要用 YAML 嗎?不一定。Markdown 表格、CSV、Google Sheet 或 Notion 資料庫都可以。重點是每張投影片有穩定且唯一的 ID,欄位也足以說明它的目的與教材需求。 Q3:建立 Manifest 後,還能修改簡報內容嗎?可以。先更新 Manifest 的相關項目、版本或變更紀錄,再重新產生受影響的簡報、講義或 Prompt Card。這樣各份教材才能繼續對應同一份已確認的規格。 Q4:小型課程也需要 Slide Manifest 嗎?如果內容很少、只需製作一次簡報,簡單大綱可能就足夠;若同一課程會產生投影片、講義、Prompt Card 或多次更新,逐頁規格能更容易檢查遺漏與同步狀況。

  • article-AI Coding 技術債:寫程式快 10 倍,Temporary Fix 也可能快 10 倍

    2026/9/25

    AI工具 Vibe Coding
    AI Coding 技術債:寫程式快 10 倍,Temporary Fix 也可能快 10 倍

    最近看到一則工程師笑話:一家公司發現訂單偶爾會「消失」,工程師一路追查 Cache、Database、Replication、Redis、Kubernetes、Message Queue…… 查到最後才發現,整套龐大的企業架構,其實都在保護八年前的一個 Prototype。 最經典的是當年的 Commit: quick prototype, will redesign later 八年後,還是沒有 redesign。 我看完笑得很開心,笑完卻想到一件更可怕的事:如果這個故事發生在 AI Coding 時代呢? AI 讓 Prototype 更快,理解系統卻沒有變快以前,一個工程師可能花兩個星期寫出 Prototype。現在用 Codex、Claude Code 或其他 AI Agent,一個下午就可能做出雛形:需求丟進去,Agent 開始寫程式、建立資料庫、串 API、部署 Cloudflare、接 Google Sheet、做登入、補後台。 跑起來、測一下、能用、上線。爽。 問題是,我們把「做出軟體」的速度提高了,不代表「理解系統」的能力也跟著提高。以前自己寫三千行程式碼,至少大概知道東西放在哪;現在 Agent 一個晚上可能改了幾十個檔案、加上套件、補 Issue,隔天打開 GitHub,看起來很厲害,卻只能祈禱不要壞。 AI Coding 加速的是產出,不會自動替你補上理解、判斷與維護能力。 真正麻煩的不是程式寫錯,而是沒人知道它為什麼能跑AI 寫錯程式,通常還有訊號:測試失敗、CI 變紅、網站掛掉。至少我們知道某處出了問題。 更難處理的是一個「現在可以跑,但沒有人真正理解為什麼可以跑」的系統。它可能沒有明顯錯誤,還開始接到客戶、處理預約或帶來收入。這時候有人提議重構,第一個反應常常不是「好」,而是「現在不是能跑嗎?」 恭喜,第一筆技術債誕生了。 接著需求和臨時修補一層一層疊上去: 「這裡先加個判斷。」 「那邊先 Workaround。」 「這個欄位先不要動。」 「這個 Workflow 不知道為什麼不能刪。」 「這段是 AI 寫的,先不要碰。」 最後 README 可能出現一句 DO NOT MODIFY THIS SECTION. 沒有人知道原因,但大家都很尊重它。 Prototype 最危險的時刻,未必是它出 Bug,而是它開始被依賴、開始賺錢,卻沒有人敢改。 AI 降低開發成本,沒有自動降低維護成本以前一年可能做三個 Prototype,現在一年可以做三十個。這些雛形不一定都會留下來,但只要其中一部分開始接觸真實使用者、營運流程或收入,它們就從「先試試看」變成需要長期照顧的系統。 如果每次都只追求先跑起來,AI 就可能讓臨時作法累積得更快:一年多做了十倍 Prototype,也可能多留下十倍需要理解和維護的東西。效率提高了,技術債也能跟著自動化累積。🤣 所以 Vibe Coding 下一階段重要的能力,不只是「怎麼叫 AI 幫我寫程式」,而是「怎麼讓 AI 幫我建立一套未來還敢修改的系統」。這兩件事差很多。 把專案記憶留在 Repository,讓下一個 Agent 接得住比較大的 AI Coding 專案,我會開始要求 Agent 做幾件以前覺得很囉嗦的事: 先寫規格、拆 Issue: 把目標、範圍與完成條件留下來,讓每次修改都有依據。 記錄架構決策: 說明為什麼採用某個做法,以及有哪些限制,避免未來的人只看到程式碼、看不到背景。 補測試並做 Code Review: 不只確認功能能跑,也檢查變更有沒有破壞原本行為;重要修改還可以請另一個模型做對抗性驗證。 重要修改先 Commit: 留下可追蹤的變更邊界,搞砸時才知道從哪裡回復。 更新 README 與必要文件: 把執行方式、關鍵流程和已知限制放在下一個接手者找得到的地方。 更重要的是,別只問 AI:「可以跑嗎?」也問:「半年後,另一個完全不知道背景的 Agent 接手,它看得懂嗎?」 未來維護程式碼的人可能不是現在的你,也可能是下一代 Codex、Claude Code,或另一個從沒參與過這個專案的 Agent。Git、Issue、README、測試與 Architecture Decision Record,不只是寫給工程師看的文件,也是留給下一個 Agent 的專案記憶。 以前寫文件,是怕工程師離職;未來寫文件,可能是怕 AI 換模型。模型會變,Agent 的 Session 也可能重新開始。真正能留下來的,不是它「記得什麼」,而是 Repository 裡留下了什麼。 所以我現在看 Vibe Coding,已經不只是: Prompt → Code → Deploy 而更像: Spec → Issue → Agent → Test → Review → Commit → Documentation → Deploy AI 可以讓每一步都變快,但不能因為變快,就把那些步驟全部刪掉。 八年後,某個新人打開 Git,看到一段奇怪的程式碼。Git blame 一查:作者是享哥,Commit message 寫著 temporary fix。 新人問:「為什麼這段不能改?」 資深工程師喝一口咖啡:「不知道。」 「那為什麼還留著?」 「因為刪掉會出事。」 「會出什麼事?」 「不知道。」 「那到底誰知道?」 資深工程師指向 Git 紀錄:「可能要問 2026 年的 Codex。」 問題是,那個 Session 早就不見了。😂 常見問答 (FAQ)Q1:AI Coding 為什麼可能讓技術債累積得更快?AI 能加快 Prototype 和功能的產出,但不會自動增加人對系統的理解,也不會替未來維護補上文件、測試和架構決策。當更多雛形開始被客戶或營運流程依賴,沒有整理的臨時修補就可能變成更難修改的技術債。 Q2:Prototype 已經可以跑、也開始有使用者,還需要重構嗎?能跑和容易維護是兩件事。當系統開始被依賴時,應持續補上規格、測試、決策記錄與必要文件,並為重要修改保留可追蹤的 Commit;是否重構則要看實際風險與變更需求,不應只因為「現在能跑」就假設它永遠不需要整理。 Q3:怎麼讓下一個 AI Agent 看懂現有專案?把背景和理由留在 Repository:用規格與 Issue 說明目標和完成條件,用架構決策記錄說明取捨,維護 README、測試與清楚的 Commit。這些內容能讓沒有參與前一個 Session 的工程師或 Agent 有線索理解系統。