部落格

不定期分享最新資訊文章

徐享／享哥

AI應用規劃師

具有 10 年經驗在數位行銷與電商廣告領域，專精生成式AI應用與個人資料保護，致力於以獨特商業洞察與實戰案例研討，助力品牌突破成長瓶頸。

AI工具 (85) ChatGPT (19) 商業策略 (32) AI自動化 (87) AI Agent (49) SEO (13) AEO (8) 內容行銷 (27) Cursor (2) Vibe Coding (45) Codex (17) MCP (3) 影音行銷 (47) Gemini (11) AI Coding (2) Meta Ads (1) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) AI繪圖 (8) n8n (29) API串接 (13) 社群行銷 (4) 自動化講師應用 (6) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Cloudflare (6) Claude (6) Claude API (1) AI創業 (1) 工作流 (1) 享哥宇宙 (10) 科幻喜劇 (8) AI故事 (8) Seedance (2) 技術選型 (1) Electron (1) Tauri (1) 奇幻喜劇 (2) 台灣民間信仰 (2) Git (1) 知識變現 (4) Google (1) Google Colab (1) Google Vids (1) GSAP (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) 資料處理 (1) 個人品牌 (1) Power Automate (1) Playwright (1) 職場溝通 (2) LINE (1) 雲端部署 (1)

2026/10/8
AI工具 AI自動化 AI Agent

【Adobe 全家桶替代品來了？7 套開源創作工具開始為 AI Agent 設計】

最近看到一個有點狂的專案。 ArtCraft 團隊公開了一系列叫做 Crafting Apps 的創作工具。它不是只做一套 Photoshop 替代品，而是把圖片、向量、影片、RAW、PDF、視覺特效和排版出版都放進同一個產品方向。看起來像是要把「Adobe 全家桶」重新做一次。但我研究後覺得，更值得注意的不是免費，而是這些工具從架構上就讓 CLI、JSON Control Channel 與 MCP 成為操作入口。換句話說，AI Agent 不只提供剪輯建議，還有機會直接呼叫創作軟體裡的功能。以下內容以 2026 年 10 月 8 日查閱的官方專案頁與版本資訊為準。這些專案更新很快，功能、版本與成熟度都可能變動。 ArtCraft Crafting Apps 有哪七套工具？官方目前列出七個獨立的創作工具。表中的 Adobe 名稱是工作流程上的類比，並不代表功能相同、檔案完全相容，或由 Adobe 背書。工具大致用途工作流程類比 PhotoCraft 圖層、遮色片、修圖與 PSD／PSB Photoshop VectorCraft 向量插畫與繪圖 Illustrator FilmCraft 影片剪輯、調色與音訊 Premiere Pro LightCraft 照片管理與 RAW 開發 Lightroom PrintCraft PDF 閱讀、整理與保護 Acrobat EffectCraft Motion Graphics 與視覺特效 After Effects DesignCraft 頁面排版與出版 InDesign 這些不是把網頁包成 Electron 桌面程式的產品。官方將它們描述為以 Rust 從頭打造的原生創作工具，各工具 repo 也公開程式碼。支援平台與瀏覽器版本則要看個別工具：例如 PhotoCraft 與 EffectCraft 已有 WebAssembly／瀏覽器方向，FilmCraft 的引擎可編譯到 WebAssembly，但官方目前仍把瀏覽器前端列為下一步。所以比較準確的說法是：這是一組正在發展中的原生創作軟體，不是已經完成、可以整批取代 Adobe 的產品套裝。為什麼我覺得 Agent-ready 比「免費」更有意思？傳統創作軟體的主要操作方式，是人用滑鼠和鍵盤操作 GUI： 1人 → GUI → 創作軟體 Crafting Apps 想加入另一條路： 1AI Agent → CLI／JSON Control Channel／MCP → 創作軟體以 FilmCraft 為例，官方說明 GUI、CLI、JSON 控制通道和 MCP Server 會呼叫同一組命令。也就是說，剪輯、修剪、調色、混音和輸出等操作，不只存在於按鈕後面，也能用結構化方式觸發。官方 repo 也附有 .mcp.json 設定；CLI 文件中的 MCP 啟動方式則是： 1filmcraft-cli mcp 這表示 Agent 有機會直接操作軟體提供的命令。它不代表 AI 自動理解素材、每次都能剪出好作品，也不代表整套流程已經穩定到可以無人審核。素材規劃、操作權限、結果檢查和人工 Review 仍然重要。我之前也寫過 Agent-native Website 的概念；這次有趣的地方，是類似的想法開始進到專業桌面創作軟體。目前最值得先看的是 FilmCraftFilmCraft 是目前較容易直接開始嘗試的一套。官方 v0.2.1 release 提供 macOS Universal DMG，也有 Windows 與 Linux 的發行檔。它已經具備多軌 Timeline、Source／Program Monitor、剪輯與 Trim、Keyframe、色彩調整、音訊 Mixer、字幕和轉場等專業剪輯架構；輸出可用 H.264 與 ProRes。這些功能讓它看起來不只是簡單的影片剪輯器。但有個容易誤讀的地方：依官方目前的格式表，HEVC 可解碼，尚不能輸出；H.264 是可輸出格式，ProRes 也支援輸出。官方說明還列出大型素材效能、外掛與不同平台實測等限制，因此不宜把它的格式能力直接寫成「H.264／HEVC／ProRes 都能輸出」。官方目前也用兩種不同指標描述成熟度：功能清單約完成 87%，但對「能否取代 Premiere 用於真實專案」的自我估計約為 50–60%。這是開發團隊的估計，不是獨立測試分數；不過它清楚提醒我們，功能項目存在，不等於工作流程已經全面成熟。我最想嘗試的工作流會是： 123456789Codex ↓MCP ↓FilmCraft ↓匯入素材、整理時間軸、調色與字幕 ↓人 Review 後輸出這是我想驗證的方向，不是我已經跑通的完整自動剪輯流程。 EffectCraft 讓 Motion Graphics 也能程式化如果 FilmCraft 對應影片剪輯，EffectCraft 就是往 After Effects 的 Motion Graphics 與合成工作流程走。官方目前列出 Composition、Layer、Keyframe、Graph Editor、Expression、3D Camera、Light 和 Render Queue 等能力，並表示已有 306 種效果。這個數字會隨開發改變，實際功能與成熟度仍要看最新版本。 EffectCraft 同樣有 CLI、JSON 控制通道與 MCP。官方文件提到可以在 Headless 模式操作專案、設定屬性並進行 Render。換句話說，未來確實有機會把這類工作串成： 1設計規範＋Motion Skill＋AI Agent＋EffectCraft 再由人確認結果。不過官方也明確說它仍然很年輕，行為不一定與 After Effects 相同，.aep／.aepx 專案和 After Effects 外掛目前也不能直接沿用。因此我會把它當成值得追蹤的 Agent-native Motion Graphics 實驗，而不是現成的 After Effects 替代品。 PhotoCraft 的 PSD 數字要怎麼看？PhotoCraft 對標 Photoshop，已經涵蓋圖層、遮色片、調整圖層、Smart Object、筆刷、色彩管理，以及 PSD／PSB 開啟與儲存。關於 PSD 相容測試，要分清楚「重新存檔後渲染一致」與「檔案逐位元相同」。PhotoCraft 官方 repo 目前列出：PSD 文件重新開啟與儲存後，渲染結果在 psd-tools 測試集的 307／309 份、另一組混合測試集的 169／170 份相符。這些數字是官方特定測試資料集的結果，不等於整份 PSD 檔案都能 byte-for-byte 原樣往返。官方把逐位元相同的說法限定在較底層的 PSD 解析／寫入 crate 和可解析的測試檔案。這類數據很容易被一句「PSD 完全相容」過度簡化。正式工作前，仍要用自己的 PSD、字型、效果和色彩設定實際檢查。如果未來這些操作介面與批次處理能力成熟，我會想到一種「AI 社群圖卡工廠」：讀活動資料、替換標題和照片、套用尺寸，再輸出多個平台版本。這是從目前 Agent 操作架構延伸出的想像，還不是官方承諾的現成自動化功能。免費、開源與授權不能混為一談不同 repo 的授權條款要逐一查看。例如 PhotoCraft 與 EffectCraft 的程式碼採 MIT 或 Apache-2.0 雙授權；但 ArtCraft 主專案是另一個獨立產品，其 repo 目前標示為 Fair Source，並在授權說明中列出商業銷售與開發競品等限制。因此，不能只因它們都屬於 ArtCraft 生態，就把整個生態的授權概括成同一種「毫無限制的開源」。若你要把程式碼納入商業產品、重新散布或建立服務，應直接查閱對應 repo 的 license、NOTICE 與品牌使用條款。我看到的是 Agent-native 創作軟體的雛形這系列工具最值得觀察的方向，是軟體的使用者不再只假設為人類。除了按鈕、選單、滑鼠與快捷鍵，產品也開始提供 CLI、MCP、JSON 控制介面、可讀的專案格式與 Headless 執行方式。我不會現在就把 Adobe 刪掉。FilmCraft、EffectCraft 和 PhotoCraft 都還在快速發展，與成熟工作流程之間仍有差距。但它們帶來一個值得問的問題：我們挑選創作軟體時，除了問「人用起來順不順」，是不是也該問「AI Agent 能不能安全、穩定地操作」？我最想先驗證的，還是 Codex → MCP → FilmCraft → 剪出一支影片。等這種流程跑順，創作軟體的設計方式可能真的會改變。想釐清 CLI、Skill 和 MCP 的分工，也可以接著讀這篇：AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI。常見問答 (FAQ)Q1：ArtCraft Crafting Apps 現在可以完整取代 Adobe 嗎？目前不適合這樣期待。FilmCraft、PhotoCraft 和 EffectCraft 的官方頁面都提到仍有成熟度或相容性限制；適合先下載試用、觀察工作流程，不建議直接把它們當成已完成的專業替代品。 Q2：Codex 可以透過 MCP 操作 FilmCraft 嗎？FilmCraft 官方提供 MCP Server，repo 也附有 MCP 設定範例；具體仍需安裝相容版本、設定本機 CLI，並依官方文件連接。MCP 提供的是操作入口，不會保證 Agent 自動做出符合創作意圖的結果。 Q3：FilmCraft 目前能輸出 HEVC 嗎？依查閱時的官方格式表，HEVC 支援解碼，尚未支援輸出；H.264 和 ProRes 則列有輸出支援。版本更新可能改變這項狀態，使用前應再查看最新 release 與格式文件。 Q4：PhotoCraft 的 PSD 往返測試代表檔案完全相容嗎？不代表。官方目前列出的是測試集中的渲染結果，以及較底層解析／寫入元件的 byte-for-byte 測試；兩者不是「任意 PSD 都能與 Photoshop 完全互換」的保證。 Q5：Crafting Apps 和 ArtCraft 主專案使用同一種授權嗎？不一定。個別創作工具與 ArtCraft 主專案是不同 repo，必須分別查看 license 和相關聲明；例如主專案目前使用 Fair Source 授權說明，不應直接套用 PhotoCraft 或 EffectCraft 的授權印象。
2026/10/4
AI工具 AI自動化 AI Agent

AI 不會讓你的工作更輕鬆，只會讓你有能力接下更大的工作

最近讀到周加恩的〈AI 不會帶來更輕鬆的工作〉，我看完一直點頭，但有一個地方想再往前推一步。他提到，自己和 AI 合作的方式，已經從早期追求「全部自動化」，慢慢轉成減少自動化的比例。其中一句話我特別有感：自動化也是一種負債——更精確地說，過早的自動化是一種負債。這也呼應我這一年大量使用 Claude、Codex、AI Agent、Skill、MCP、Harness，甚至讓不同 AI 分工合作的感受。不過換成我的說法，我會把它改成：不要追求最低自動化，而要追求「最晚自動化」。我不是反對自動化。相反地，我每天都在做自動化。只是越做越發現，真正危險的不是沒有自動化，而是一件事情都還沒搞懂，就急著把它規模化。為什麼我不再追求「全部自動化」？剛開始使用 AI 時，我也很容易有「AI First」的想法：這件事可以交給 AI 嗎？如果可以，下一步就是能不能全部交出去？最好只要送出一個 Prompt，AI 就自己規劃、搜尋、執行、整理、檢查，最後把成果交回來。如果過程還需要人工介入，好像就代表 Agent 不夠厲害。於是我開始研究 Prompt、Workflow、n8n、MCP、Skill 和 Agent，希望最後能變成：輸入 → AI → 完成這個流程看起來很漂亮。但做過越多 AI 工作流，我越不迷信「全自動」。很多系統出問題，不一定是模型不夠強，而是我們在還沒理解工作之前，就先把它自動化了。混亂乘上 AI，只會得到自動化的混亂假設你請 AI：「幫我建立一套完整的公司知識管理系統。」現在的 AI 很可能幾分鐘就規劃好資料夾、分類、標籤、Metadata、命名規則、工作流程、Agent 和 Skill。第一眼看起來完整得不得了，真的開始使用後，才發現分類太多、規則太多、每次產出的東西也太多；Context 越塞越肥，真正需要的資訊反而埋在一堆看起來很專業的內容裡。最後，你原本想減少管理工作，卻每天都在管理 AI 幫你建立的管理系統。所以我現在會提醒自己：不要用 AI，把一個還沒想清楚的流程規模化。混亂乘上 AI 不會變成效率，只會變成自動化的混亂。先手動跑幾次，才知道什麼值得自動化有人問我：「這個東西能不能做成 AI Agent？」我通常會先問：「這個流程你自己跑過幾次？」如果還沒跑過，我會建議先自己做一次，再多跑幾次。實際操作之後，才會看見哪些資訊重要、哪些步驟每次都相同、哪些地方需要判斷、哪裡最容易出錯、會遇到哪些例外，以及怎樣才算完成。最後還要回答一個更關鍵的問題：你打算怎麼驗收 AI？我喜歡的發展順序是：手動 → 跑熟 → SOP → Skill → 半自動 → 自動化 → Agent 手動不是落後，而是在蒐集自動化需求。每次做到某一步，心裡都冒出「這個怎麼又要重做一次？」時，就記下來。等你知道它何時重複、例外怎麼處理、輸出如何驗收，那才是可能值得自動化的地方。從 Prompt Engineering 走向 Context Engineering這一年我也感覺到，重要的問題不再只有「我要跟 AI 說什麼？」還包括「這次任務應該讓 AI 知道哪些事情？」 Prompt Engineering 仍然有用，但在 Agent 工作流裡，任務資料、歷史、規則、工具與記憶該在什麼時候提供或移除，往往同樣關鍵。這也是我開始重視 Context Engineering 的原因。很多人第一次使用長 Context 模型，會直覺把能找到的資料全部塞進去：文件、歷史對話、公司規範、所有 Skills，越多越安心。但 AI 看過更多，不代表它做得更好。真正有用的，是這次任務需要的資訊；舊規則、不相關文件和過期決策，可能只是雜訊。如果用一個很粗略的比喻，我會把 AI 的有效能力想成：有效 AI 能力 ≈ 模型能力 × Context 訊噪比這不是測量模型能力的正式公式，而是提醒自己：模型再強，脈絡太雜也可能拖累結果。 Skill Library 不是收集越多越強我最近花很多時間整理自己的 Skill Library。以前看到「必裝 50 個 Skills」或「100 個 Agent Skills 免費下載」，也會想全部裝起來。後來才發現，Skill 不是 Pokémon，並非收集越多就越強。更重要的是確認哪些工作流程真的反覆使用、哪些規則已經穩定、哪些是自己的寫作習慣與驗收標準，還有哪些經驗值得沉澱成 Skill。我也開始做 Session Review 和 Voice Calibration，因為有價值的不是 AI 知道很多，而是它知道我做這件事時怎麼做。如果你也在整理經驗、判斷與方法，可以延伸閱讀從經驗到 AI Skill：把專業整理成 AI 能執行的能力。 AI 越強，越需要界定它能做什麼以前我希望一個 AI 從頭做到尾；現在反而會拆開工作：有人負責規劃、Agent 負責執行，其他模型找問題，真正開始寫程式前也可以先做不同角度的 Review。不是因為 AI 太弱，而是它太強了。一個能力很強、權限很大、Context 又混亂的 Agent，可能非常有效率地把錯的事情全部做完，而且還做得漂漂亮亮。因此我會把成熟的工作流想成： Context → Plan → Skill → Agent → Review → Feedback 每一層都有自己的責任，也要設計權限邊界、人工檢查的時機、完成條件，以及做錯之後如何 rollback。若想了解 Skill 如何和 Agent 的執行環境搭配，可以接著看從 Skill 到 Agent Harness。 AI 沒讓工作消失，而是把工作往上移以前做網站時，我可能會問：「這段 JavaScript 怎麼寫？」有了 Codex 之後，這部分可以交給 AI，但我的工作沒有消失，問題變成「這個功能應該怎麼設計？」接著要想資料怎麼流、權限怎麼分、Agent 能看到哪些資料、哪些決定可以交給 AI、哪些地方一定要 Human Review、做錯怎麼 rollback，以及怎麼確認 AI 說的完成是真的完成。工作的重心慢慢從 Operator 轉向 Orchestrator：設計誰來做、怎麼做、看見哪些資訊、可以做到哪裡、誰來檢查，以及什麼條件才算完成。我的體感是，工作沒有消失，而是往更高一層移動。效率提升後，目標也可能變大以前準備一份簡報可能要一天，現在 AI 也許一小時就能幫上忙。省下來的時間會不會自動變成休息？不一定。公司也可能看到新的產能，接著問：「既然一天能做五份，是不是可以多接四個案子？」我認為 AI 帶來的效率，很可能有一部分會變成更大的目標。以前一個人只能經營一個專案，之後可能同時管理多個 Agent、專案或內容流程；以前小團隊才能做的事，現在更小的團隊也能挑戰。實際結果會因工作與組織而異，但工作的範圍確實可能跟著能力一起擴大。這也是我為什麼看好「一人公司」的槓桿。值得期待的不只是少工作兩小時，而是以前需要十個人完成的事，能不能由一到三個人完成。未來厲害的一人公司，背後可能有 Claude、Codex、不同 Agent、自己的 Skill Library、Harness，以及跑熟的自動化工作流；真正重要的能力，是設計工作。我的版本不是減少自動化，而是最晚自動化先讓人跑，跑到理解流程；再整理成 SOP，確認流程穩定；接著把可重複的能力沉澱成 Skill，再逐步半自動化、自動化，最後才讓 Agent 接手完整工作。等到一個步驟已知、重複、穩定而且可驗收，自動化才比較可能成為資產。否則，它也可能只是另一種技術債。 AI 時代稀缺的能力，是設計脈絡AI 用得越多，我越覺得模型能力不是全部。結果常常取決於你怎麼設計 AI 看見的世界：哪些資料要給、哪些不該給、哪些規則寫進 Skill、哪些判斷留給人；誰負責規劃、誰負責執行、誰負責 Review，又要符合什麼條件才算完成。這些都是脈絡設計。未來擅長使用 AI 的人，不一定最會寫 Prompt，而是知道什麼時候該給 AI 哪些 Context、什麼時候該把 Context 拿掉，以及哪些事情根本不該交給 AI。 Slow is smooth, smooth is fast繞了一大圈，我現在反而回到一個老派的方法：先自己做，先手動跑懂，再建立 SOP；SOP 穩定後做 Skill，Skill 穩定後做 Agent，最後設計驗收條件並串起工作流。看起來比較慢，最後卻可能比較快。因為我們建立的不是 Demo 看起來厲害、三天後沒人敢碰的 AI 系統，而是三個月、半年後，甚至模型換掉之後，仍能繼續運作的流程。 AI 不一定讓我們工作更少；它真正帶來的，是讓一個人有能力完成以前一個團隊才能完成的事。人要做的，是決定什麼值得做、設計 AI 怎麼做，並知道什麼時候不該讓 AI 做。延伸閱讀／觀點來源本文受到周加恩〈AI 不會帶來更輕鬆的工作〉中「過早自動化是一種負債」與脈絡設計等觀點啟發，再從我實際使用 Claude、Codex、AI Agent、Skill、MCP、Harness 與多 Agent 協作的經驗，延伸出「最晚自動化」這個想法。常見問答 (FAQ)Q1：什麼時候適合把工作流程交給 AI Agent？先親自跑過幾次，確認重複步驟、例外情況、需要人工判斷的環節，以及可驗收的完成條件。流程穩定後，再逐步把可重複的部分交給 Skill、自動化或 Agent。 Q2：為什麼不一開始就把整個流程自動化？流程還沒理解清楚時，需求和規則容易改變。太早自動化會把錯誤假設與混亂一起規模化，後續還得花時間維護和修正。 Q3：Context Engineering 和 Prompt Engineering 有什麼不同？Prompt Engineering 著重怎麼寫指令；Context Engineering 還會考慮任務需要哪些資料、規則、歷史與工具資訊，以及何時提供或移除它們。Agent 工作流通常需要同時設計兩者。 Q4：Skill 裝得越多，AI 就會越好用嗎？不一定。應優先保留符合實際工作方式、反覆使用且規則穩定的 Skills。過多或不相關的內容可能增加脈絡雜訊，讓當前任務更難聚焦。 Q5：AI 自動化真的會讓工作變輕鬆嗎？它可能縮短部分任務的處理時間，但省下的時間也可能被更大的目標、新的專案或更多協調工作填滿。是否更輕鬆，還取決於組織如何安排工作與分配效率收益。
2026/10/4
AI工具 AI Agent 影音行銷

【別再一鏡一鏡抽卡：我整理出一套真正能拍完整故事的 AI 短片製片 SOP】

最近我一直在研究 AI 影片。研究到後來，我發現真正困難的，早就不是「哪個模型生成的影片最好看？」而是：怎麼把十幾個 AI 生成鏡頭，變成一支角色一致、空間合理、故事看得懂，而且可以持續修改的影片？最近看到漢森建築整理的 Kling AI 母女短片製作案例：從 12 格分鏡到 V2。再加上我前陣子研究的多人同場戲、平面圖與空間一致性、Blender 灰模、角色一致性、Risk Shot、AI 影片逐鏡生成、DaVinci Resolve MCP 和 AI Agent 自動粗剪，我開始把它們接成一套完整的 AI Film Pipeline。以下是我整理給自己反覆使用的「享哥 AI 短片製片 SOP」。它不是綁定某個模型的提示詞大全，而是把故事、鏡頭、參考資料、版本和驗收接起來的製片流程。先把故事拆成 Shot List，再開影片模型很多人做 AI 影片時，會直接對模型說：「一個媽媽看著多年沒回家的女兒，感動流淚，電影感。」生成不滿意就再抽一次。這樣很容易把時間和生成額度花在還沒定義清楚的故事上。比較穩定的起點是先寫劇本，再拆成 Shot List。以兩分鐘短片為例，可以先列出 Shot 01 到 Shot 12，再為每一鏡定義：時間與地點出場人物、景別與鏡頭位置人物在畫面中的位置、動作和視線台詞、情緒，以及鏡頭結束時的狀態例如 Shot 08 可以寫成：「地點是客廳；女兒站在玄關右側，母親坐在沙發左側。女兒停下腳步，轉頭看向母親，保持眼神接觸並說：『媽，我回來了。』母親不說話，停頓兩秒，眼眶開始泛淚。」「母親不說話」和「停頓兩秒」都是製片規格的一部分。若不寫清楚，模型可能自行加上台詞或動作。Shot List 的目的不是寫得更像小說，而是讓每一鏡都有能執行、能驗收的條件。建立 Character Bible，先穩住角色角色一致性是多鏡頭影片最容易失控的地方。主要角色可以先建立 Character Bible，整理正面、左右 3/4 側面、半身與全身參考，以及年齡、髮型、服裝、身高比例和表情特徵。角色跨越不同年齡時，分開整理，例如 Mother_Young、Mother_MiddleAge、Mother_Old，以及 Daughter_Child、Daughter_Teen、Daughter_Adult。每次生成只提供當下鏡頭需要的角色參考，避免把所有版本都塞進同一個 Context，讓模型多做不必要的判斷。用 Location Bible 和 Spatial Map 固定空間單張圖漂亮，不代表剪在一起會像同一個地方。沙發、窗戶、門和主要光源若在不同鏡頭裡反覆換位置，觀眾會感覺空間跳掉。重要場景可以建立 Location Bible，列出大門、沙發、電視、窗戶、餐桌、光源和人物活動區域，並畫一張 Top View 平面圖。多人同場戲再加 Spatial Map，固定人物 A、B、C 的站坐位置、彼此視線、前後景、攝影機位置，以及換機位後不能改變的相對關係。三個人以上、走位、遮擋或多機位的場景，可以先在 Blender 做灰模 Blocking。放入房間、家具、人物方塊和 Camera，確認人物會不會被擋、構圖是否合理、攝影機高度是否適合，再截圖作為 Composition Reference。這一步的重點不是做出漂亮模型，而是先把空間和機位講清楚。 Storyboard 是 Keyframe，不只是分格漫畫規格和空間建立後，再為每個 Shot 製作 Keyframe，例如 shot_01_keyframe.png、shot_02_keyframe.png。需要控制重要動作時，可以再補 Start Frame、Middle Frame 和 End Frame。這些圖像參考要一起沿用 Character Bible、Location Bible、Spatial Map 和需要的 Blender Blocking，讓生圖模型有明確的構圖與人物依據。此時目標不是讓模型自由改編，而是先建立剪接時能接得起來的畫面。先測 Risk Shot，別按順序一路生成12 個鏡頭不一定要從 Shot 01 開始做。先找出最可能失敗的 Risk Shot，例如多人互看、擁抱、手碰臉、擦眼淚、嘴型、快速走位，或鏡頭和人物同時移動。假設 Shot 03、08、12 最難，就先做這三鏡的測試。若最難的鏡頭目前拍不出來，趁早改劇本、鏡位或表演設計；不要等前面十一鏡都完成，才發現結尾無法成立。順序應該是： Storyboard → Risk Shot Test → Production 把 Prompt 寫成可以驗收的動作序列「電影感、溫暖、感人、細膩」可以描述氣氛，但很難用來判斷生成結果哪裡出錯。更可控的寫法，是把鏡頭拆成連續動作：女兒停下腳步。慢慢轉頭看向母親。維持眼神接觸，再開口說：「媽，我回來了。」說完自然閉口，保持視線，不再說話。每個鏡頭的 Prompt 可以依序整理成： Subject + Position + Camera + Action Sequence + Eye Contact + Dialogue Timing + Emotion + End State 這樣比較容易判斷問題出在轉頭、視線、嘴型，還是結尾多出不需要的動作。模型版本和功能會變，鏡頭規格與驗收邏輯則可以保留下來。逐鏡生成並管理版本Risk Shot 通過後，再逐鏡進入正式 Production。Kling、Google Flow、Veo、MiniMax 等可以是不同階段的候選工具；具體能力、開放狀態和方案限制會隨版本變動，選擇時要以當下實際可用的功能為準。每個 Shot 都保留規格、參考圖、Prompt、模型、版本和狀態，例如： 1234shot_08_v01.mp4 人物正確，視線錯shot_08_v02.mp4 視線正確，嘴型錯shot_08_v03.mp4 Passshot_08_final.mp4 記下每次失敗的具體原因，之後才知道要改提示詞、參考圖、運鏡還是表演，而不是讓整支影片反覆重生。先完成 Rough Cut V1，再修單鏡第一輪素材不用每鏡都做到滿分。先把 Shot 01 到 Shot 12 放進 Timeline，完成 Rough Cut V1，再從整支影片檢查節奏。剪在一起後，可能發現 Shot 03 太長、Shot 06 可以刪掉、Shot 08 情緒不足，或 Shot 11 和 Shot 12 應該交換。先看整體，再修局部。單看一鏡覺得漂亮，不代表它適合整支影片的節奏和情緒。讓 AI Agent 和剪輯工具協助管理素材當每一鏡都整理成結構化資料，AI Agent 才有條件協助管理影片。例如為每個 Shot 記錄： 12shot_id, duration, character, location, prompt, model,version, status, issue, selected_version Agent 可以依 Shot List 檢視時長、黑畫面、重複畫面、音訊斷裂、字幕缺漏和對白 Timing，也可以協助標記待人工確認的角色或畫面問題。這些檢查結果是 review 線索，不能直接當成最終判斷。若手上已有可用的 DaVinci Resolve MCP 或其他剪輯操作介面，可以把 Shot Metadata、素材搜尋、selected_version、時間軸排列、字幕和 Rough Cut 輸出接成一條流程。工具串接方式會依實際環境而異；每次操作仍應保留人工檢查和可回復的版本。 V1 之後只修有問題的 ShotReview 時逐鏡記錄問題，例如 Shot 03、04 通過，Shot 05 嘴型不準、Shot 07 手部異常、Shot 08 節奏太慢。接著只處理需要修的鏡頭：嘴型問題可評估 Audio Fix 或 Lip Sync，手部問題可重生 Shot 07，節奏問題則可 Trim、調速或重生 Shot 08。替換後輸出 Rough Cut V2，再重新檢查前後鏡的銜接。保留其他已通過的鏡頭，才能把修改成本集中在真正出問題的地方。 Technical QA 通過後，仍要 Human Final Review影片輸出後，先做 Technical QA：解析度、FPS、Codec、Bitrate、Duration、音訊取樣率、字幕數量、黑畫面、靜音與完整解碼。這些檢查能確認檔案是否符合技術條件。 Technical QA Pass 不等於影片好看。最後還是要從頭看到尾，確認角色有沒有變臉、視線和空間方向是否合理、嘴型自然不自然、情緒有沒有中斷、音樂音量是否合適，以及故事是否看得懂。把流程接成一套 AI Film Production System整套流程可以整理成： 123456789101112131415161718192021Idea ↓Script → Shot List ↓Character Bible → Location Bible → Spatial Map ↓Blender Blocking（複雜鏡頭需要時） ↓Storyboard / Keyframe ↓Risk Shot Test ↓逐鏡生成 → Version Management ↓Rough Cut V1 → AI Agent Review → 剪輯工作流 ↓局部修正／重生 → Rough Cut V2 ↓字幕／BGM／混音 → Technical QA ↓Human Final Review → Master Export 研究到這裡，我反而覺得「AI 導演」比「AI 生影片」更值得學。模型會換，提示詞寫法也會變；但怎麼說故事、拆 Shot、控制角色和空間、安排鏡位、驗收素材與管理版本，仍然是製片能力。我想把 Shot List、Character Bible、Prompt、Reference、Version、Issue、Status 和 Selected Clip 都整理成結構化資料，再讓 AI Agent 協助管理。理想分工是：人負責導演和決策，Agent 協助製片管理，生成模型提供鏡頭素材，剪輯工具完成後期。這不是按一下就能完成整部片，而是一套能持續修正的 AI 影片工作流。想先從故事本身開始，可以接著讀AI 影片新手最容易學錯的：把「高級感」當成影片能力；想把鏡頭描述得更清楚，也可以看AI 攝影語言與 Google Flow 運鏡提示詞。常見問答 (FAQ)Q1：製作 AI 短片前，應該先生成影片嗎？建議先寫劇本和 Shot List，為每鏡定義人物、位置、動作、視線、台詞與結束狀態，再建立角色和場景參考。這能讓影片生成有明確規格，也方便判斷結果要修哪裡。 Q2：什麼是 AI 短片的 Risk Shot？Risk Shot 是整支影片中最可能失敗的鏡頭，例如多人互看、擁抱、手部接觸、嘴型或複雜走位。先測這些鏡頭，可以在大量生成前調整劇本、鏡位或表演。 Q3：Blender 灰模是 AI 影片製作的必要步驟嗎？不是。單人鏡頭或簡單對話通常可用平面圖和空間參考處理；多人、遮擋、走位或多機位等複雜場景，才值得用 Blender 灰模預演人物位置與構圖。 Q4：AI Agent 可以直接決定哪些鏡頭要保留嗎？Agent 可以整理 Shot Metadata、標記技術問題或提供 review 線索，但角色一致性、情緒、空間連戲和故事可讀性仍需要人工從頭檢視，不能把自動檢查結果當成最終通過。 Q5：Rough Cut V1 之後，要整支影片重新生成嗎？通常先定位有問題的鏡頭，再局部修正或重生並輸出 V2。保留已通過的版本，能避免把修改成本擴大到整支影片。
2026/10/3
AI工具 AI Agent AI Coding

AI Coding 成本最佳化：多模型分工取代單一高價方案

最近我一直在想：AI Coding 有沒有必要每個月都花到 200 美元？我曾同時使用好幾個高階方案，處理 ERP、電商、遊戲化功能、自有平台，以及已上線的商用專案。按我當時的帳號組合計算，相關月費一度超過 1,100 美元。這是我的實際成本背景，不是各家目前的統一價目表。實際開發一段時間後，我開始重新拆解工作流程。我的結論不是「便宜模型比高價模型聰明」，而是：不要讓最貴的模型長時間處理它不必親自完成的重複工作。 AI Coding 最花錢的，不一定是第一次寫程式一個功能通常不只包含產生程式碼。開發過程還要理解需求、讀取 Repository、找出相關檔案、建立上下文、執行測試、閱讀錯誤、修改，再跑一次回歸檢查。以我的工作經驗，成本容易在這些反覆往返中累積。程式碼第一次產生出來，只是整個交付循環的一部分；「確認它有沒有做對」也需要時間、工具使用量與人工注意力。如果同一個模型從規劃一路做到測試、Debug 和 Code Review，它當然可能全部完成，但每個回合都可能重新讀取大量脈絡。這就像讓資深技術主管每天親自改 CSS、修 lint、重跑測試和讀 log：做得到，不代表每件事都值得用同一種成本處理。先分配工作，再挑選模型我現在會把 AI Coding 流程拆成幾個角色。Claude、Codex、DeepSeek、Kimi 等名稱只是我使用過或評估過的例子；模型能力、工具整合與方案額度會變動，分工原則比固定排名耐用。角色主要工作交付內容規劃者釐清需求、找出限制、設計模組邊界、拆分任務 SPEC、Issue、驗收條件獨立審查者從另一個角度找邏輯漏洞、權限與資料風險、測試缺口有證據的問題清單與修正建議實作者按照明確範圍完成程式碼、測試與必要修正可檢查的程式碼差異與測試結果最終驗收者核對需求、測試結果與整體風險，決定是否合併驗收紀錄與合併決策讓強模型把方向想清楚規劃階段會影響後續每一個 Issue。這時我會優先使用自己熟悉、能處理複雜上下文的模型，請它整理需求、資料流、模組邊界、依賴條件與可能的失敗情境。 SPEC 不必很長，但要讓下一個角色能知道要改什麼、不能改什麼，以及如何判斷完成。把模糊的「做一個登入功能」改成明確的行為與驗收條件，通常比不停追加長提示更容易控制工作範圍。請另一個模型獨立找問題規劃模型很容易沿著自己的假設往下推。讓不同模型閱讀同一份 SPEC 與 Issues，可以增加一個獨立檢查角度，但不保證一定找到所有缺陷，也可能產生不成立的疑慮。審查者應指出依據，最後仍由人判斷並透過測試確認。我會用類似以下的任務說明： 12345678910請獨立檢查這份 SPEC 與工作項目，先不要開始實作。請找出：- 未定義的邊界情況- 權限與資料一致性風險- API 或模組設計上的衝突- 測試條件不足或互相矛盾之處每個問題請附上對應段落、影響與可驗證的修正建議。不確定的地方請標明假設，不要把推測寫成已確認的缺陷。同一個模型自行規劃再自行審查，也可能有幫助；只是它未必能跳出先前採用的假設。換一個模型是增加檢查角度，不是把責任交出去。把明確的實作工作交給合適成本的模型當需求、檔案範圍和驗收方式已經清楚，實作者不一定每次都要重新推演整個產品背景。可以把工作拆成一個有邊界的 Issue，附上必要檔案與驗收條件，再依任務風險選擇模型或 API。 12345Issue：新增訂單狀態篩選依驗收條件實作，只修改訂單列表相關模組。新增或更新對應測試，執行測試並修正失敗。回報修改檔案、測試指令與結果；不要變更無關功能。如果便宜模型無法完成，或實作牽涉安全、付款、資料遷移等高風險範圍，就應提高模型能力或安排更多人工審查。省下的 API 費用若換來大量重工，整體成本仍可能更高。一套可試跑的多模型工作流程123456789101112131415需求 ↓規劃模型：釐清需求、整理 SPEC 與 Issues ↓另一個模型：獨立審查假設、風險與驗收缺口 ↓修正規格，由人確認範圍 ↓實作模型：逐項完成工作並執行測試 ↓獨立檢查：核對差異、測試與風險 ↓必要時請規劃模型處理重大設計問題 ↓人工決定是否合併高價模型集中在開始前的關鍵決策與結束前的重要審查；大量、界線清楚的實作與修正，則可由成本較低且足以勝任的模型處理。不同任務的比例不必相同，也不需要為了湊出「三個模型」硬加一個角色。 $20、$60 與 $200 要怎麼比較？「20 美元團隊打敗 200 美元方案」比較像工作流的比喻，不是每個人都能複製的保證結果。比較方案時，先把固定月費、API 用量、超額費用和人工檢查時間一起算進去。截至 2026 年 10 月 3 日，官方頁面列出的美國月繳價中，Claude Pro 為每月 20 美元，ChatGPT Plus 也為每月 20 美元。ChatGPT 方案的 API 用量另計，Codex 的可用功能與使用額度會依方案及帳戶狀態變動；DeepSeek API 則依模型與 Token 用量計價。地區定價、稅金、額度與方案內容可能不同，請以自己帳戶當下顯示的資訊為準。因此，20 + 20 + 20 = 60 只有在第三筆 API 預算實際用了 20 美元時，才是當月約 60 美元的情境估算。API 並不是固定每月 20 美元的訂閱；不用或少用時可能低於預算，長任務也可能超出預算。若把比較基準設成 200 美元月費，60 美元確實是算術上少 70%；這不代表每個專案都能以相同品質和時間完成。本文提到的高階方案支出是作者當時的個人經驗；上述方案資訊是依官方頁面於 2026 年 10 月 3 日查閱的美國月繳標價整理。價格、額度與模型可用性可能變動，應以官方頁面和帳戶實際顯示為準。更實用的比較單位是「每個通過驗收的工作項目花多少成本」。可以先挑一種低風險、可重複的任務，記錄 API 費用、修正回合、人工檢查時間與測試結果，再比較單一模型和分工流程。只看 Token 單價或訂閱金額，容易忽略重新交代上下文與返工的成本。怎麼開始試，而不讓多模型增加混亂？選一個低風險任務。暫時不要把付款、權限或正式資料遷移當成第一個試驗。先寫好規格與驗收條件。明列目標、修改範圍、不能變動的內容，以及要執行的測試。讓審查者先看規格。要求它列出有依據的風險與缺口，先由人確認哪些需要修正。把實作切成小工作項目。每項工作都應能單獨檢查，並有明確的完成條件。記錄總成本與結果。除了 API 帳單，也記下返工時間、失敗案例與人工驗收時間。依數據調整分工。如果模型切換讓你花更多時間搬運上下文，合併角色或改用單一模型可能更有效率。把程式碼、Issue 或內部文件交給不同服務前，也要先確認公司的資料政策與各服務的資料使用設定，不要把金鑰、.env 或不該外傳的內容放進提示。多模型協作會增加資料流向的服務數量，資料邊界應一起納入架構決策。如果想看更具體的需求討論、建立 Ticket，再交由 Codex 實作與 Review 的接力方式，可參考我把 ChatGPT 接上開發台後整理的 AI Coding 工作流。不需要把 200 美元方案視為浪費如果高階方案每月替你省下的時間或帶來的價值遠高於費用，它可能很划算。當下時間有限、專案複雜、需要更高使用額度，或一個錯誤的代價很高時，集中使用能力更強的模型也有合理性。我真正想改變的是「唯一最強模型包辦全部」這個預設。規劃、審查、實作和驗收是不同工作；先定義角色，再看現有模型與方案能不能勝任。模型是可以更換的供應者，流程、驗收條件和風險控制才是團隊長期要維護的資產。常見問答 (FAQ)Q1：多模型分工一定比單一 AI Coding 方案便宜嗎？不一定。多模型可能降低高價模型處理重複工作的支出，也會增加 API 用量、切換上下文和人工整合成本。應以通過驗收的成果、API 帳單與人工時間一起比較。 Q2：每月 60 美元就能取代 200 美元的高階方案嗎？這是 20 + 20 + 20 的情境算術，第三筆若是 API 預算，實際帳單會按用量變動。模型額度、任務複雜度和返工時間也會影響結果，因此不能把 60 美元當成固定套餐或品質保證。 Q3：為什麼要讓另一個模型審查規格或程式碼？不同模型可能採用不同假設，獨立審查有機會發現規劃階段漏掉的邊界條件、風險或測試缺口。但審查也可能誤報，必須提供依據並以程式碼、測試和人工判斷確認。 Q4：怎麼判斷哪些任務可以交給較便宜的模型？先從範圍小、驗收明確、出錯容易回復的任務開始。觀察它能否在可接受的修正次數內完成，並確認測試、權限和資料要求都符合專案標準。 Q5：ChatGPT Plus 月費是否包含 OpenAI API 使用？不包含。OpenAI 說明 Plus 訂閱與 API 計費分開；Codex 功能和額度則依方案、帳戶及當下可用性而異。採用 API 工作流前，應分開估算訂閱費和 API 帳單。官方方案與 API 資訊以下官方頁面用來確認本文的方案／計費邊界，查閱日期為 2026 年 10 月 3 日。實際使用前請再次查看最新資訊： Anthropic 方案價格 ChatGPT Plus 方案與 API 計費說明 Codex 與 ChatGPT 方案的可用性和額度 DeepSeek API 模型與 Token 價格
2026/10/3
AI工具 AI自動化 AI Agent

不要再蒐集 Skill 了：我開始建立自己的 Skill Factory

最近我一直在研究 Agent Skill。GitHub 上每天都有人分享新的 Skill，從「必裝清單」到上百個 Skill 的合集，我自己也常常看到不錯的就安裝。前陣子算了一下，我裝的 Skill 加上 Plugin 指令已經超過 100 個。但我開始問自己：裝了這麼多，AI 真的有變得比較懂我嗎？答案沒有想像中明顯。最近看到理工威森分享〈不用懂技術，3 步把一本書蒸餾成你的 AI 技能〉，他談到把書中的方法 Distill 成 Agent 能使用的規則。我很喜歡這個方向，也開始想：蒸餾的材料，為什麼只能是書？我真正想建立的，可能不只是 Skill Library，而是一座會把知識、經驗和工作紀錄轉成可用能力的 Skill Factory。 Skill 越多，為什麼 AI 不一定更懂我？看到 GitHub 上不錯的 Skill，就安裝；看到別人推薦，又安裝。Skill Library 很容易變成另一種「稍後閱讀」：收藏了一大堆，真正工作時卻不確定該用哪一個。更重要的是，那些 Skill 描述的是別人的工作方法。它可能很好，卻不一定符合我的寫作方式、課程設計流程、簡報架構、網站驗收標準、Agent 工作流程或客戶溝通方式。所以我現在更在意的，不是「我安裝了多少 Skill」，而是： AI 到底學會了多少我的工作方法？ Skill 的價值，在於它能不能讓 Agent 理解一項工作何時開始、該怎麼判斷、如何完成，以及什麼情況才算驗收通過。蒸餾的不是摘要，而是判斷規則假設讀完一本談判的書，請 AI 摘要，可能會得到幾個核心觀念、金句和技巧。看完當下覺得有收穫，過一段時間卻不一定記得怎麼用。如果我希望 AI 學會用這本書的方法處理客戶殺價，問題就不只是「這本書在講什麼」，而是「遇到這種情境時，AI 要怎麼判斷與行動」。例如客戶說太貴，Agent 可以先協助釐清：是真的預算不足、還沒理解價值、正在測試議價空間，還是拿競爭對手比較？可能原因不同，下一步就不該一律回覆同一句話。這類「遇到什麼情況、先確認什麼、依什麼條件分流、最後如何檢查」的規則，才比較接近能放進 SKILL.md 的工作方法。一本書最後留下的，不必是完整摘要，而可以是 Agent 在實際任務中用得上的流程。真正值錢的，也許是我自己的工作經驗一本暢銷書或熱門 Skill，很多人都能取得；但我過去十幾年的工作經驗，只有我自己有。我長期做 AI 教學、企業內訓、數位行銷、網站、AI Agent、Vibe Coding、LINE API 和自動化流程。這些經驗的價值，不只在於我知道哪些工具，更在於遇到不同狀況時，我會怎麼判斷。例如製作一套課程，我逐漸形成了這樣的流程：需求分析 → 學員分析 → 課程架構 → 實作設計 → Slide Manifest → 簡報 → 講義 → Prompt Card → 實際操作 → 驗收這套流程不是哪一本書直接教我的，而是做過許多次後慢慢磨出來的。如果每次開新的 Agent Session 都要從頭解釋，這些方法就沒有真正累積下來。把「我糾正 Agent 的地方」留下來建立 Skill 時，我不想只靠回想「自己通常怎麼工作」。人描述自己怎麼做，和實際工作時做出的選擇，有時並不完全相同。更直接的材料，是我和 Agent 一起完成工作的 Session。過程裡，我可能會說：「這頁不對，實作比例太低。」「這個提示詞要給建議填值。」「簡報大綱跟講義對不起來。」「先做 Slide Manifest。」「新手在這裡一定看不懂。」這些修正看起來只是聊天紀錄，背後卻可能藏著課程比例、教材一致性、提示詞易用性和讀者理解門檻等專業判斷。如果我反覆要求 Agent 修改同一類問題，或每次都得重新解釋相同規則，那就值得回頭檢查：這是一次性的需求，還是已經穩定到可以成為工作規則？我會從三種來源蒸餾 Skill1. Knowledge Distill：把外部知識變成可執行方法材料可以是書籍、YouTube、Podcast、課程、文章或研究報告。目標不是把來源濃縮成摘要，而是抽出適用情境、判斷方式、步驟和限制，讓 Agent 能在工作中使用。 2. Experience Distill：把實務經驗整理成自己的 Know-how把自己做過多次的工作拆開來看，例如如何設計 AI 課程、規劃企業內訓、寫粉專文章、驗收網站、設計 Agent Workflow，或拆解 Vibe Coding 專案。這些經驗不必一開始就寫成很大的 Skill。先把一項工作中反覆出現的判斷和品質標準說清楚，就已經是有價值的原料。 3. Session Review：從和 Agent 的工作紀錄找出規則回顧過去的 Session，觀察自己反覆要求修改、最常否決、重複說明或固定採用的決策。這些重複出現的訊號，可以幫助我找到那些平常不一定會主動說出口的工作方法。把 Skill Library 變成 Skill Factory我想把建立 Skill 的流程整理成五個階段： Capture：先留下真實工作過程先照常完成一項真實任務。讓 Agent 參與實際工作，保留足以看出需求、修改、判斷與結果的過程，不急著在開始前猜測自己應該怎麼做。 Distill：抽出能重複使用的規則任務完成後，請 Agent 協助找出自己曾經糾正、修改、否決、補充或重複要求的地方，再把它們整理成偏好、SOP、判斷規則、品質標準、禁止事項和驗收條件。一條規則最好能說清楚觸發情境、要採取的行動，以及怎麼判斷結果合格；遇到例外時，也要知道何時該停下來確認。 Test：拿另一個真實任務試用寫完 Skill 不代表它已經有效。可以把它用在另一個相似但不同的工作上，觀察自己是不是少講了重複要求、Agent 是否更接近預期，以及規則有沒有造成新的問題。例如，若以前一份教材要反覆修改很多次，套用 Skill 後所需的修正明顯減少，這是值得追蹤的訊號；但重點不是達到固定數字，而是確認工作結果與協作過程是否真的改善。 Review：請另一個模型找出盲點我也想使用多模型做對抗性 Review。例如一個模型協助規劃，另一個模型負責執行，再請第三個模型檢查完成的 Skill。不同模型可以從不同角度找出規則衝突、描述模糊、無法執行、限制過多、缺少例外或難以驗證等問題。模型提供的是審查意見，最後仍要回到實際工作驗證：規則是否符合我的目的、是否改善結果、是否保留了必要的彈性。 Promote：通過驗證後再納入穩定版本Skill 可以先放在 Experimental，經過實際任務測試後進入 Testing，確認適用範圍、品質和例外都清楚，再升級到 Stable。不是每個聊天指令都要變成 Skill。單次需求可能只適用於那個任務；經常重複、可清楚描述而且能在別的任務中驗證的方法，才比較值得正式留下來。 GitHub 不只是放 Skill 的地方如果持續累積，Skill 的組織方式也會慢慢清楚。初期可能有課程設計、文章寫作、簡報 Manifest、網站 Review 和 Agent Workflow；之後再依工作領域整理：教學：課程設計、實作活動、Prompt Card。內容：部落格文章、Facebook 貼文、教學文件。開發：專案規劃、對抗性 Review、驗收。商務：提案、客戶需求、報價。這時 GitHub 就不只是擺放 Skill 的地方，也能協助記錄每個工作方法如何形成、如何修改，以及目前驗證到什麼程度。它逐漸累積的會是「我的數位工作方法」。 AI 之間的差距，可能也來自它有多了解你以前我常比較 GPT 和 Claude 哪個比較強、不同模型寫程式的能力如何。隨著模型能力演進，我也開始思考：另一個差異會不會是 Agent 已經掌握多少你的工作方法？兩個人即使使用同一個模型，一個每次都要從零說明，另一個已經累積多年工作規則和經過驗證的 Skill，實際合作起來可能就會很不一樣。因此我現在不只把 Skill 看成外掛或工具清單，也把它當成一種能被整理、測試和更新的經驗。若你想先了解我對 Skill 與 Skill Library 的想法，可以接著閱讀從 Prompt 到 Skill Library：我從 Agent Skill 講座學到什麼。以後完成一件工作，我想多問自己一句：這次有沒有什麼值得留下來，變成 Skill？看到一本好書，可以 Distill；完成一個專案，可以 Distill；和 Agent 來回修正很多次，也可以回頭檢查那些反覆出現的判斷。我不再只追蹤「我有幾個 Skill」，而想知道：「有多少原本要我親自判斷的事情，Agent 已經真正學會了？」當這個數字慢慢增加，我建立的就不只是 AI 工作流，而是一套越來越像我的 AI 工作系統。常見問答 (FAQ)Q1：Skill Factory 和 Skill Library 有什麼不同？Skill Library 著重收納 Skill；Skill Factory 則著重把知識、實務經驗和工作紀錄，經過整理、測試與 Review，逐步製作成可重複使用的 Skill。 Q2：什麼樣的工作經驗值得整理成 Skill？如果一項判斷或要求在多次工作中反覆出現，而且能說清楚適用情境、處理方式與驗收條件，就值得評估是否整理成 Skill。只適用於單一任務的指令，不一定需要升級成固定規則。 Q3：要怎麼知道 Skill 有沒有用？把它用在另一個真實任務，觀察 Agent 是否少了重複提醒、結果是否更符合預期，以及 Skill 是否帶來新的錯誤或限制。用實際工作表現來修正規則。 Q4：可以把每一次糾正 Agent 的內容都寫進 Skill 嗎？不必。先分辨那是單次需求，還是跨任務都適用的工作方法。反覆出現、能清楚說明並且可以驗證的規則，通常更適合成為 Skill。 Q5：多模型 Review 可以取代實際測試嗎？不行。其他模型可以幫忙找模糊描述或規則衝突，但是否符合你的工作方式，仍要透過真實任務驗證，再決定要不要升級到 Stable。
2026/10/2
AI Agent Vibe Coding GSAP

GSAP AI Skills 教學：我把官方 Skills 裝進 Codex，讓 Vibe Coding 網站動起來

最近看到 GSAP 官方推出一組 AI Agent Skills，我第一個反應不是「又多一個 AI 工具」，而是：這很適合放進 Vibe Coding 工作流。現在用 Codex、Claude Code 或 Cursor 做網站，AI 通常很快就能生出 Landing Page。但開始要求它加上文字進場、卡片依序出現或 Scroll 動畫時，會動不代表動得好：動畫可能搶走閱讀焦點、手機版跑出畫面，或因為缺少清理而影響效能。我想研究 GSAP，正是因為網站互動不只要「有動」，還要知道什麼時候動、怎麼安排節奏，以及怎麼照顧不同裝置的使用者。 GSAP 是控制網頁即時動畫的 JavaScript 函式庫如果你不是專門做前端動畫的，可以先把 GSAP 想成一套用來安排網頁元素動作的工具。它控制的是使用者瀏覽網站時，瀏覽器即時呈現的動畫；它不是 AI 影片生成器，也不負責把動畫輸出成 MP4。像是標題逐行出現、圖片滑進畫面、卡片依序浮現、數字往上遞增、SVG 路徑動畫、按鈕微互動，或畫面隨著使用者捲動而演出，都是 GSAP 常見的使用情境。如果你正在做 Landing Page、產品官網、活動網站、作品集或一頁式銷售頁，GSAP 可以幫你更精準地控制動畫的順序、時間與互動方式。它的官方文件也整理了 Core、Timeline、ScrollTrigger 與各類 Plugins 的使用方式。 GSAP 官方 AI Skills 把動畫實務帶進 Coding Agent以前請 AI 用 GSAP 做動畫，通常得自己描述需求，再期待模型能正確找出文件、安排程式結構並處理框架細節。現在 GSAP 官方把常見用法整理成 AI Agent Skills，可透過 npx skills add https://github.com/greensock/gsap-skills 安裝到 Codex 等支援的 Agent。官方 repository 將 Skills 分成幾個方向： GSAP Core：gsap.to()、from()、緩動、stagger 等核心 API。 Timeline：管理多段動畫的先後、標籤與時間軸。 ScrollTrigger：處理捲動觸發、pin、scrub、refresh 與清理。 Plugins：說明各種 GSAP 外掛的使用方式。 React：涵蓋 useGSAP()、scope、cleanup 與 SSR 注意事項。 Frameworks：介紹 Vue、Svelte 等框架的生命週期與清理。 Performance：優先使用 transform，減少不必要的版面計算。 Utils：提供 clamp、mapRange、interpolate 等工具函式。這件事值得注意的地方，不只是多了一套動畫函式庫，而是可以把官方累積的使用方式與常見注意事項，交給 AI Agent 在工作時參照。Skill 提供的是工作指引，不代表生成結果自然就正確；仍要看實際畫面、程式碼與裝置表現。第一步：先請 AI 規劃，不要一開始就叫它加特效我會先把 AI 當成「動態設計顧問」，請它分析目前網站哪裡值得動。這一步能避免 Hero、卡片、按鈕和背景全部同時飛進來，讓動畫反而打斷閱讀。可以先這樣下指令： 12345678910分析目前網站，找出 3 個最適合加入 GSAP 動畫的位置。不要為了動畫而動畫，先不要修改程式碼。優先評估：1. Hero 首屏進場2. 使用者 Scroll 時的內容節奏3. CTA 與卡片微互動請說明每個建議想改善的體驗、觸發時機、動畫順序與可能風險。同時考慮手機版、避免 layout shift、動畫效能與 prefers-reduced-motion。第二步：依照規劃實作並照顧不同裝置確認動畫規劃後，再請 Agent 按範圍實作。多段動作用 Timeline 管理，Scroll 動畫交給 ScrollTrigger，並要求它把清理與無障礙需求一起納入： 12345678910按照剛才確認的動畫規劃開始實作，參照 GSAP 官方 Skills 的建議。- 多段動畫使用 Timeline 管理，不要用大量 delay 硬接。- Scroll 動畫使用 ScrollTrigger，版面改變後確認是否需要 refresh。- 優先使用 transform 與 opacity，避免不必要的 layout reflow。- 確認手機版不會爆版或遮住重要內容。- 支援 prefers-reduced-motion，讓偏好減少動態效果的使用者能正常閱讀。- 若使用 React，處理好動畫 scope 與 component cleanup。完成後檢查 console error、ScrollTrigger refresh、動畫清理和效能問題。 prefers-reduced-motion 是需要明確考慮的使用者偏好。可以請 AI 為減少動態效果的情境提供較安靜的呈現方式，也可以直接讓內容以靜態狀態呈現；重點是不能讓動畫成為閱讀內容的門檻。第三步：請 AI 用 Performance Skill 再 Review 一輪程式寫完還不算結束。AI 很容易把「做動畫」解讀成讓更多東西動起來，所以我會再開一輪 Review，要求它只找問題，不增加特效： 123456789101112現在不要增加任何新動畫。請參照 GSAP Performance Skill 與相關官方建議，Review 目前所有動畫。檢查：- 手機效能與不必要的 layout reflow- ScrollTrigger 的使用與 refresh- Timeline 管理方式- 事件監聽器與 React cleanup- prefers-reduced-motion 的處理- 動畫是否干擾 CTA、內容閱讀或操作只修正發現的問題，不增加新特效；完成後列出修改處與仍需人工確認的項目。好的網站動畫不是動得越多越好，而是出現得恰到好處。多一輪 Review，可以讓動畫重新回到它該服務的目標：引導視線、補足回饋，或讓內容更容易理解。 Vibe Coding 下一步，是讓 AI 做出更好的互動體驗Vibe Coding 一開始常從「AI 幫我把網站做出來」開始，接著是「AI 幫我把 UI 做漂亮」，現在也可以往前一步，請 AI 一起規劃和實作互動體驗。我會把三者想成這樣：LLM 負責理解需求與撰寫程式；GSAP 提供動畫工具；Skill 則把專業做法、Coding Standard 和檢查步驟整理成 Agent 能參考的工作方式。把能力裝進工作流後，AI 不只知道「可以怎麼寫」，也多了一套更有方向的實作參考。如果你已經在用 Codex、Claude Code 或 Cursor 做網站，可以從一個做好的頁面開始，依序跑過「動畫規劃 → Hero 或卡片實作 → ScrollTrigger → 手機與效能檢查 → AI Review」。先從一兩個真正能改善體驗的位置開始，通常就能看出差異。若你也在整理 Agent 的工作方式，可以延伸閱讀從 Skill 到 Agent Harness與Codex Skill 與 Plugin 的差異。延伸閱讀 GSAP 官方 AI Skills GSAP 官方 GitHub GSAP 官方文件常見問答 (FAQ)Q1：使用 GSAP AI Skills 前，需要先學會 GSAP 嗎？不必先把 GSAP 全部學完才開始。你可以先讓 Agent 根據網站提出動畫規劃，再從它產生的 Timeline、ScrollTrigger 或 React 實作反向學習。不過仍建議閱讀重要程式碼、確認執行結果，逐步建立判斷能力。 Q2：GSAP AI Skills 會自動替網站加入動畫嗎？Skill 是提供給 AI Agent 參照的說明與實務指引，本身不會替網站修改程式碼。你仍要提出需求並確認修改範圍；安裝後的生成結果也要經過程式碼與畫面檢查。 Q3：怎麼避免 Scroll 動畫在手機上卡頓或影響閱讀？先減少動畫數量，優先選擇能改善資訊節奏的區塊，並檢查手機上的捲動、效能與內容可讀性。也要考慮 prefers-reduced-motion，並在框架元件卸載時清理動畫與事件監聽器。
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 工作能力庫
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
2026/10/1
AI Agent 影音行銷 Claude

Claude 程式碼動畫怎麼做？從 Prompt 拆出 Motion Design Skill

最近看到一個很有意思的 GitHub 專案：awesome-opus5-5-videos。截至 2026 年 9 月 29 日，專案 README 列出 475 個 Prompt 檔，並從中精選 100 個案例展示。它的特別之處，是把動畫成品和創作者分享的 Prompt 放在一起，讓人有機會研究這些作品是怎麼被描述、再被做出來的。先補上一個容易誤會的地方：這不是 475 份都完整公開的 Prompt。專案也註明，有些創作者只分享了部分 Prompt，或只留下原始貼文連結。至於 Claude 產生的實作程式碼，也不一定附在每個案例裡；如果創作者沒有另外公開，你可以重跑 Prompt，再觀察自己得到的 HTML、Canvas、SVG 或 Three.js 程式碼。我最近也一直在研究 Claude 用「寫程式」做動畫。看得越多，我越覺得這個集合真正值得看的，不是能不能一次複製大量 Prompt，而是我們可以從成品回頭研究：一句動畫需求，如何變成有時間、有物件、有動作的可執行規格？這些案例走的是程式碼動畫路線這批作品不是把一句描述直接交給影片模型，再由模型輸出一段影片。依專案的說明，創作者會請 Claude Opus 5.5 把動畫寫成程式；常見做法包括 HTML、Canvas、SVG 和 Three.js。瀏覽器負責執行動畫，若需要影片檔，再把播放畫面錄製或輸出成影片。可以先用這個流程理解： Prompt → Claude 寫動畫程式 → 瀏覽器執行 → 需要時錄成影片因此，Claude 在這個流程中同時接到導演、動畫師和前端工程師的工作：它要理解畫面、安排動作，也要把想法轉成瀏覽器能執行的程式。一支動畫可以拆成畫面、動作與聲音從案例可以看出，程式碼動畫大致有三個互相配合的部分：部分常見技術主要負責的內容畫面怎麼畫 Canvas、SVG、Three.js、GLSL 文字、圖形、粒子、3D 場景、材質與光影畫面怎麼動 CSS Animation、GSAP、JavaScript timeline 元素何時出現、移動路徑、縮放、速度與緩動聲音與節奏 Web Audio API 或音訊素材音效、節拍與畫面轉場的搭配；也可以完全不加聲音有些作品把樣式、動畫與程式包進單一 HTML，打開瀏覽器就能預覽；要分享成影片時，再另外錄製播放結果。重點不是一定要採用哪個框架，而是讓畫面、動作和節奏彼此對得上。好的動畫 Prompt 更像一份 Motion Design 規格寫程式做動畫時，cinematic、dramatic lighting 或 epic 這類形容詞仍能傳達美術方向，但通常不足以告訴模型一支動畫要怎麼走。更有用的資訊是時間、物件、動作和輸出方式。先安排時間，再描述每段畫面例如，想做一支 10 秒的科普動畫，可以先列出節奏：時間畫面與動作 0–2 秒主視覺淡入，主題物件由小放大 2–4 秒標題從側邊滑入，停在畫面安全區 4–7 秒圖表逐步成長，重點數字依序出現 7–10 秒鏡頭拉遠，收束成結尾畫面這比只說「做一支很有電影感的動畫」更能讓模型掌握段落長度、先後順序和畫面轉換。說清楚畫面有哪些物件把文字、圖表、角色、圓形或背景元素列出來，並說明它們的位置、大小關係和視覺層級。若標題要優先被讀到，可以直接交代標題與圖表不要互相遮擋，重要內容要留在畫面中央的安全範圍。描述物件如何移動除了「要出現什麼」，還要指定誰先動、往哪裡移動、移動多久、是否放大或淡出，以及動作要急促還是平滑。這些都是動畫規格的一部分，能幫助模型把靜態構想轉成有節奏的畫面。補上風格與輸出條件最後再補色彩、字體感受、比例、背景、是否需要聲音，以及希望怎麼預覽。若想快速在瀏覽器查看，可以要求輸出單一 HTML 檔；如果結果要再剪輯，也要先想好影片比例和結尾如何銜接。為什麼不該只複製 Prompt？只收集提示詞，很容易變成「看過很多範例，卻不知道怎麼自己改」。更有效的讀法是把成品、原始 Prompt 和自己重跑後的程式碼對照起來：先看成品：留意它為什麼順、哪裡吸引你，以及畫面如何轉場。再看 Prompt：找出創作者如何描述時間、構圖、物件與動作。專案也提醒，有些檔案只提供節錄或原始貼文。自己重跑一次：觀察模型選了什麼技術、如何切分動畫，以及結果和原始成品有哪些差異。一次只改一個條件：例如配色、文字、速度或畫面比例，才看得出修改造成的差異。整理有效規則：記下哪些描述能穩定改善節奏、版面或可讀性。先挑和自己用途相近的案例就好。README 目前精選的分類包括 Motion Graphics、Explainers、3D Scenes，以及 Games & Interactive。若目標是做 AI 科普短片，可以先從 Explainers、Typography 和 Data Visualization 類型找靈感，不需要依序研究所有案例。把反覆驗證過的方法整理成 Animation Skill當你研究過一批相似作品，就可以把有效的方法整理成自己的 Skill。它不只是保存一段長 Prompt，而是說明 Agent 每次接到任務時要如何完成工作，例如：輸入與目標：影片主題、觀眾、時長、比例和發布平台。畫面規格：場景、物件、文字層級、構圖與色彩方向。時間軸：每段的開始與結束時間、動作順序、轉場和節奏。實作與輸出：選擇 Canvas、SVG、CSS 或 Three.js 等合適方式，交付可預覽的檔案。驗收方式：檢查文字、時間軸、畫面比例、播放效果與需要修正的地方。等這些規則經過幾次實際製作與修正，你就可以把文章、課程或數據內容交給 Agent，再要求它依照自己的 Explainer Animation Skill 開始規劃。模型和工具可能改變，但你整理出的判斷方法、範本與驗收步驟仍然可以繼續累積。若你也在整理 Skill 與 Agent 工作方式，可以延伸閱讀從 Skill 到 Agent Harness和Codex Skill 與 Plugin 的差異。新手可以怎麼開始？從專案中挑三個和自己目標相近的案例。先完整看完成品，再讀它附的 Prompt 或原始貼文。用相同 Prompt 跑一次，觀察模型實際產生的程式和動畫。每次只改一個變數，記錄畫面和節奏怎麼變。把反覆有效的規則整理起來，再逐步形成自己的 Skill。最後要建立的，不是「我收藏了多少 Prompt」，而是自己能否把作品拆成規格，再把有效做法整理成可重複使用的 Library、Skill 和 Workflow。這才是這批程式碼動畫案例最值得研究的地方。專案連結：awesome-opus5-5-videos。專案 README 指出，影片與 Prompt 歸原創作者所有，並在各案例連回原始來源；公開可看不等於可以任意重用素材。常見問答 (FAQ)Q1：這些案例是 Claude 直接生成影片檔嗎？不是。專案介紹的是 Claude 先把動畫需求寫成程式，再由瀏覽器執行；若需要影片檔，還要錄製或輸出播放結果。 Q2：專案裡的 475 個 Prompt 都能看到完整內容嗎？不一定。截至 2026 年 9 月 29 日，README 列出 475 個 Prompt 檔，但也說明部分創作者只分享節錄或原始貼文。每個案例可取得的資訊要以該項目的連結為準。 Q3：研究案例時，為什麼還要自己重跑 Prompt？專案提供案例和創作者分享的提示詞，但不保證每筆都附上生成後的完整程式碼。自己重跑後，才能檢視實際實作方式，並比較它與原始成品的差異。 Q4：Prompt 和 Animation Skill 有什麼不同？Prompt 通常描述一次任務的需求；Animation Skill 則把可重複的方法整理成流程，包含輸入、規格、實作方式和驗收步驟，讓 Agent 能依同一套方法處理不同內容。
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 背書。使用前仍要檢查程式行為、資料流、工具權限與相依套件。