跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

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)
  • article-Codex × Concat 實測：打造 AI 短影音自動剪輯工作流

    2026/10/18

    Codex MCP 影音行銷
    Codex × Concat 實測：打造 AI 短影音自動剪輯工作流

    以前要做一支短影音，得自己找素材、排時間軸、剪接、上字幕、配樂，再匯出影片。AI 即使幫忙寫好文案，接下來仍要打開剪輯軟體，一段一段手動調整。 最近我改用開源剪輯軟體 Concat 做了一次實驗：讓 Codex 透過本機 MCP Bridge 呼叫 Concat 的 API，先輸出短測試片，再完成一支 30 秒招生短影音。接著，我把反覆驗證過的操作方式整理成專案內的 concat-video-editor Skill，讓剪輯流程可以再次使用。 這次經驗最有意思的地方，不是「講一句話就能剪出完美影片」，而是把一套剪輯流程拆成 Codex 能執行、檢查和重複操作的步驟。 本文記錄的是 2026 年 10 月 18 日，以 Concat 0.2.7 進行的本機實測。Concat 仍在持續開發，功能與 API 可能更新。官方 MCP 文件當日仍標示內建 MCP 尚未發布；同日的 Issue #337 則宣布官方開始投入內建 MCP 傳輸的開發。若要照本文操作，請先查看官方最新版本與文件。 Concat、MCP Bridge 和 Skill 各自負責什麼？Concat 是一套本機影片剪輯軟體，提供多軌時間軸、動態文字、配樂等剪輯能力，也有可供程式呼叫的 JSON-RPC API。這次實測使用的是 Concat 0.2.7。 串接時有三個容易混淆的部分： 元件 工作 這次實作 Concat API 讓外部程式呼叫剪輯功能 使用 Concat 提供的本機 JSON-RPC API MCP Bridge 把 AI 工具的 MCP 呼叫轉成 Concat API 指令 自行建立的本機 Python Bridge Skill 告訴 Codex 如何依照 SOP 規劃剪輯、操作和驗收 專案內的 concat-video-editor Skill 可把整體流程想成： 123456789剪輯需求 → Codex → concat-video-editor Skill ↓ MCP Bridge ↓ Concat JSON-RPC API ↓ 時間軸、影片與剪輯專案 ↓ 輸出與驗收 Bridge 解決「怎麼連上工具」；Skill 解決「連上之後怎麼按照規則完成工作」。只有 Skill、沒有可用的 MCP 連線，Codex 就不能呼叫 Concat；只有 Bridge、沒有剪輯 SOP，也不代表每次操作都會排出正確時間軸。 先看清楚 Concat 的 MCP 狀態這篇的實測版本是 0.2.7。官方開發者文件在 2026 年 10 月 18 日標示：Concat 的 API 與 JSON-RPC 傳輸已存在，但正式隨產品發布的 MCP Server 尚未到位；官方提供的當下作法，是以一個 MCP Server 包裝 JSON-RPC socket。官方同日也在 Issue #337 宣布開始開發內建的 MCP 傳輸。因此，本文的 Bridge 是我當時實際建立與測試的方案，不能直接推論為目前所有版本都需要自建 Bridge。 建立本機 Bridge：先連線，再操作剪輯這次使用 Apple Silicon MacBook Pro M2。Bridge 以 Python FastMCP 建立，共提供 22 個 MCP 工具，涵蓋專案管理、媒體匯入、片段編輯、文字、預覽影格、匯出及工作狀態查詢。這是我自行實作的工具數量，不代表 Concat 官方 MCP Server 的工具清單。 Concat Remote API 在本機監聽，例如 127.0.0.1:7420，並使用 Token 驗證。我的 Bridge 將 Token 放在本機環境檔，限制檔案權限，不把憑證寫進程式碼或公開文章。實際設定時也應把專案與輸出限制在指定工作資料夾，並先用全新的測試專案驗證。 在修改 Codex 的 MCP 設定前，我先備份原設定，再請 Codex 依實際位置填入 Bridge 執行檔與程式路徑。這次的 Bridge 另外加入了 macOS 自動啟動：連線被拒絕時，嘗試執行 /usr/bin/open -g -b app.concat.editor，最多等 15 秒讓 Remote API 就緒。這是我自行加入的 Bridge 功能，不是每一套串接都會自動啟動 Concat；一般情況仍要先開啟軟體。 Codex 的 MCP 設定會指向本機 Python 執行環境與 Bridge 程式，概念如下；路徑要換成自己的實際位置： 12345[mcp_servers.concat]command = "/你的工作目錄/.venv/bin/python"args = ["-u", "/你的工作目錄/concat_mcp.py"]startup_timeout_sec = 20tool_timeout_sec = 90 註冊後重新載入 MCP，再先做唯讀連線檢查： 123請呼叫 concat_version，回報 Concat 版本、API 版本、apiCompatible、可用能力與目前 MCP 工具。不要建立、修改或刪除任何專案。 我當時讀到的結果是 Concat 0.2.7、API 0.2、apiCompatible: true，能力包含 events 與 json-rpc。這只表示 Bridge 能連上相容的 API，還沒有證明影片可以順利匯出；因此下一步應用新測試專案完成端到端驗證。 先輸出一支 2.5 秒測試片我先使用簡單測試影片與繁體中文標題「Codex 連線測試」，輸出約 2.5 秒的 H.264 MP4。測試同時檢查： 匯出工作是否收到 export.done。 解析度、影格率、片長是否符合預期。 影片與音訊能否完整解碼。 指定時間點的預覽影格是否正確。 Concat 原生專案能否儲存與重新開啟。 原始測試素材是否保持不變。 匯出工具回傳「已啟動」不等於檔案已完成。Concat 的匯出工作是非同步的，必須追蹤 job 並等待完成事件；若連線在等待期間中斷，也先確認舊工作與輸出狀態，再決定是否重跑，避免重複輸出。 再完成 30 秒招生短影音小測試通過後，我才交給 Codex 三段素材與一段已授權的配樂，製作「AI 新時代」招生短影音。需求是： 9:16 直式，輸出 1080 × 1920。 整理操作畫面精華，加入大字文案與簡單動態文字。 不加旁白，搭配背景音樂。 片尾安排課程名稱與「立即洽詢課程」CTA。 保留原始素材和 Concat 專案，輸出新版本，不上傳、不發布。 最後輸出 AI新時代-30秒招生短影音-v02.mp4，並檢查片長、影像與音訊。這次成果證明的是：在這批素材與這套工作流程下，Codex 能透過 Concat 完成一支 30 秒影片；它不能代表任何素材、長度或畫幅都會有同樣結果。 把成功流程封裝成 concat-video-editor Skill第一次剪成功後，我把如何讀取素材、挑選片段、安排軌道、加文字和配樂、等待匯出、檢查結果等操作，整理成專案內的 concat-video-editor Skill。它保留在專案裡，不修改全域 Skill，也不包含 MCP Bridge、Python 虛擬環境或 Token。使用 Skill 前，Bridge 必須已經能正常連線。 固定規格的影片可以再寫成 manifest.json，例如設定畫幅、片長、幀率、片尾長度、文字與素材路徑： 123456789101112131415161718{ "ratio": "9:16", "duration": 30, "fps": 30, "cta_duration": 5, "title": "AI 新時代", "cta": "立即洽詢課程", "sources": [ { "path": "/完整路徑/A.mp4", "headline": "把 AI 變成你的工作助力" }, { "path": "/完整路徑/B.mp4", "headline": "課堂現場直接動手實作" } ]} 若沒有指定來源入點，這次的腳本會依素材順序分配片長並擷取中央區域；也能為素材指定 source_start 和 duration。但設定時間碼不等於 AI 已理解影片內容。若要挑出講師最精彩的一句話或最有感染力的畫面，仍要另外進行語音、影格或語意分析。 使用者不一定要自己撰寫 JSON。可以先請 Codex 根據需求整理 manifest，再用 –plan-only 預覽剪輯計畫，確認素材、時間與輸出規格後才執行。正式操作要在正確專案目錄進行，並避免覆蓋來源影片與既有版本。 為了保留可回復的成果，這次 Skill 也讓每次輸出使用遞增版本，例如 v001、v002、v003，不覆蓋先前影片；整合測試還比對舊版本的雜湊，確認它沒有被重跑流程改寫。 四輪整合測試與實際遇到的問題為了確認 Skill 不只對單一招生影片有效，我另外製作了三種解析度與影格率的合成測試影片，以及一段 WAV 配樂： 橫式 960 × 540、30 fps。 直式 540 × 960、25 fps。 方形 720 × 720、24 fps。 30 秒 WAV 音樂。 四輪測試各輸出 30 秒、30 fps、900 影格的影片，涵蓋建立專案、匯入素材、多軌剪輯、文字與 CTA、配樂混音、H.264／AAC 匯出、影格與音訊檢查，以及儲存、重開、修改、還原專案。測試也比對來源素材雜湊，確認原檔沒有變動，並檢查新版本不會覆蓋舊檔。 機器驗收全數通過，Codex 也檢視輸出影片的關鍵影格與文字效果。不過，完整播放、人耳聽感與 GUI 操作體驗仍需要人工檢查。規格檢查通過，不等於影片節奏、文案與音樂一定適合觀眾。 遇到的狀況 原因與修正方式 片段位置沒有落在預期時間 不同欄位要用對應的 API 命令。這次以 trimClip、moveClips 處理裁切與移動，操作後重新讀取時間軸確認位置。 標題被排到影片後面 同一軌道的片段可能互相推移。影片、標題、補充文字、品牌字樣與 CTA 視需要分軌，新增後再檢查時間軸。 時間軸有文字，輸出畫面卻看不到 文字本身的垂直位移和動畫位移疊加，可能把文字推到畫面外。要從實際輸出的 MP4 擷取影格確認。 裁切後片段短到不合理 裁切順序受相鄰片段影響。先移到沒有相鄰片段干擾的位置裁切，確認來源入點與片長後再移回時間軸。 有 AAC 音軌但聽起來太小聲 有音訊軌不代表混音合適。除了檢查峰值與訊號，也要實際聆聽人聲和配樂的平衡。 這些修正最後都寫回 Skill，讓下一輪可以重用檢查步驟，而不是只記得「上次成功了」。 這套工作流目前做得到與做不到的事MCP 操作不等於語意剪輯腳本可以照固定規則安排素材，也能透過 MCP 呼叫剪輯功能；要讓 AI 真正理解人物說了什麼、哪個鏡頭最有感染力，再依敘事挑選片段，還需要額外的轉錄或影像分析流程。不能把依序平均分配片長說成 AI 已完成精彩片段判斷。 本機 API 不會讓 Codex Cloud 直接連到你的 Mac127.0.0.1 指的是目前執行程式的那台電腦。Codex Cloud 裡的 127.0.0.1 是雲端執行環境，不是使用者的 Mac。本文這套 Bridge 因此以本機 Codex App 或 CLI 為使用情境。 GUI 正在開啟的專案有使用限制在 0.2.7 實測中，Remote API 不能同時操作 GUI 正在持有的同一個專案。工作時要讓 MCP 操作未被 GUI 開啟的專案，完成後儲存、關閉，再由 GUI 重新打開檢查。官方 Issue #337 正在討論即時操作開啟中專案與 MCP 傳輸；此項限制應以實際使用的 Concat 版本為準。 語音、字幕功能要看介面和 Bridge 有沒有串接Concat GUI 有文字轉語音與自動字幕功能，但我這次的 Bridge 沒有把這些功能包裝成 MCP 工具。測試完成的是文字標題、動態大字與 CTA；若要自動產生中文旁白或逐字字幕，還需要額外整合 TTS 或語音辨識，不能只因 GUI 有功能就宣稱 Bridge 已經支援。 若只是想先試 Concat 內建中文旁白，可以在 GUI 的語音設定下載 Kokoro compact 模型；官方教學列出的檔案大小約 132 MB。這是軟體介面裡的功能，和這次 MCP Bridge 有沒有提供 TTS 工具是兩回事。 三種畫幅測試不代表長片或 4K 保證可用這次測過 9:16、16:9、1:1，仍要針對每種畫幅重新檢查人物位置、文字換行與安全區。短影音成功也不代表一小時影片或 4K 專案有相同速度；素材數量、編碼、特效、記憶體與長度都會影響結果。初次練習可從 15～30 秒、1080p 開始。 費用也要拆開看：Concat 本身是免費開源軟體；Codex 的模型使用則取決於方案或 API 計費，電腦運算與儲存空間、外部 TTS 或音樂服務也可能有成本。 新手可以照五個階段練習 先會用 Concat：匯入影片、放到時間軸、加入標題並輸出 MP4。 再連上 Codex：建立 Bridge、設定 Token，唯讀呼叫版本資訊確認 API 相容。 完成最小測試：用新專案輸出 2～3 秒影片，檢查影片、音訊和匯出完成事件。 試做 30 秒短片：加入多段素材、動態文案、配樂和片尾 CTA，保留素材與專案。 最後封裝 Skill：把成功步驟、錯誤修正、驗收方式整理成可重複使用的工作流程，再用不同素材和畫幅測試。 如果你也在整理 AI 影片流程，可以延伸閱讀從 Shot List 到粗剪的 AI 短片製片 SOP。本篇則聚焦在另一個環節：讓 AI Agent 透過 API 實際操作剪輯軟體。 結語：把剪輯判斷整理成可以重複執行的規則這次我從第一次不知道該下載哪個語音模型，到建立本機 Bridge、匯出 2.5 秒測試片、完成 30 秒招生短影音，再把流程封裝成 Skill。過程中遇到時間軸跑位、片段裁太短、文字消失和音樂太小聲，逐一找出原因後再把修正方法寫進 SOP。 AI Agent 的價值不在於保證一句話就剪出神片，而是讓一次成功的工作經驗成為下一次可以檢查、修改和重複執行的能力。剪輯判斷仍然重要：你要知道什麼畫面好看、節奏是否合理，再把這些標準講清楚，才能讓 AI 照著做並協助驗收。 常見問答 (FAQ)Q1：讓 Codex 操作 Concat，需要準備哪些東西？需要可使用的 Concat 本機 API、一個相容的 MCP Bridge，以及 Codex 的 MCP 設定。若還希望 Codex 按照固定剪輯 SOP 工作，再加上 Skill。Token 應保存在本機的安全設定中，不要放進程式碼或公開內容。 Q2：Concat 0.2.7 已經內建 MCP Server 了嗎？依 2026 年 10 月 18 日的官方開發者文件，內建 MCP Server 當時尚未隨產品發布，文件提供以 MCP 包裝 JSON-RPC 的 Bridge 作法。官方同日宣布開始開發內建 MCP 傳輸；請在實際操作前確認最新 release 與文件。 Q3：這個 Skill 能自動找出影片中最精彩的片段嗎？不能只靠固定剪輯腳本做到。腳本可以依素材順序、入點和片長安排時間軸；要根據講話內容或畫面情緒挑選精彩片段，還需要語音轉錄或影像理解等分析步驟。 Q4：為什麼 Codex Cloud 不能直接操作我 Mac 上的 Concat？Bridge 連到的是本機 127.0.0.1。在雲端執行時，這個位址指向雲端環境本身，不會自動連回使用者的 Mac。因此本文流程使用本機 Codex App 或 CLI。 Q5：Concat 有配音和自動字幕，為什麼 Bridge 沒有？軟體 GUI 有某項功能，不代表 MCP Bridge 已經把它做成可呼叫的工具。這次的 22 個自製工具沒有直接包裝 TTS 或語音辨識；若要納入自動流程，需要另外接好相應工具並驗證輸出。 官方資源與本次實測參考 Concat GitHub 專案 Concat 官方下載與版本 Concat MCP 開發者文件 Concat JSON-RPC 文件 Concat API 方法 Concat 文字轉語音教學 Codex MCP 設定說明 本次實測資料：Concat MCP Bridge README、Concat MCP 測試報告（2026/10/18）、concat-video-editor Skill v001、Skill 四輪整合測試報告。 本文依據 2026 年 10 月 18 日的本機實測與當時官方文件整理。Concat 仍在持續開發，未來的功能、介面與 MCP 支援方式可能不同。

  • article-不用買高階顯示卡，也能用 AI 做影片！Google Colab × Codex 零基礎實戰教學

    2026/10/18

    Codex 影音行銷 Google Colab
    不用買高階顯示卡，也能用 AI 做影片！Google Colab × Codex 零基礎實戰教學

    一台普通 MacBook，能不能搭配雲端 GPU，開始做 AI 影片？ 可以先從 Google Colab 的免費 Notebook 體驗雲端運算，再讓 Codex 協助閱讀開源專案、檢查環境與規劃工作流程。但「能用雲端 GPU」不代表每個帳號都能取得同一種 GPU，也不代表模型授權一定允許在分配到的機房執行。 本文以 MacBook 為例，帶你從零開始認識 Colab、Google Colab CLI 與 AI Agent 工作流。先做不會啟動 GPU 的練習；等你看懂費用、執行環境與模型授權，再決定是否繼續。 先看這個重要限制： 上游專案回報，它測試到的 Colab G4 執行階段位於美國或歐盟；MiniMax H3 開放權重授權目前排除美國、歐盟、英國與南韓。不要因為成功分配到 GPU，就直接下載或執行 H3。先確認最新授權、實際執行地區與你的使用方式；有疑問就停下來詢問權利人或改用條款適用的替代方案。 本文的 Colab 配額與模型授權資訊會隨方案及條款變動。Colab GPU 型號、使用限制與供應狀況也可能改變；本文不保證你能取得 G4，也不把上游作者的測試值當成每個人的預期成本。 Google Colab 是什麼？為什麼能用一般 MacBook 做運算？Google Colab 是 Google 提供的雲端 Jupyter Notebook 服務。你可以在瀏覽器裡執行 Python 程式，運算工作由遠端執行階段處理；自己的電腦則負責操作、管理專案與下載成果。 可以先把它想成： MacBook： 你操作的工作桌，負責編輯、管理素材與發出指令。 Colab 執行階段： 暫時租用的遠端電腦，依帳號方案與當時供應情況提供 CPU、GPU 或 TPU。 Codex： 可以讀取你開啟的專案，協助理解程式、規劃步驟與整理檔案的 AI 助手。 GPU： 適合大量平行運算的硬體，可用於部分 AI 圖像與影片模型。 Colab 的免費層可以用來練習 Notebook；但資源有使用限制，GPU 種類與可用性會變動。付費方案也不等於保證取得指定 GPU。Google 官方建議把 GPU 可用性視為依帳號與當下資源供應變動的服務。 先認識幾個常見名詞 名詞 入門理解 Google Colab Google 提供的雲端 Notebook 服務 GPU 執行部分 AI 模型時使用的平行運算硬體 CCU Colab 運算單元；依方案和使用情況扣抵 GitHub Repo 放置程式碼、文件與設定檔的專案資料夾 CLI 用文字指令操作服務的命令列介面 AI Agent 能讀取任務、使用工具並協助完成多步驟工作的 AI 助手 本文提到的 Google Colab CLI 是 Google 維護的命令列工具，可以建立與停止 Colab 執行階段、執行程式及傳送檔案。它會連接你的 Colab 帳號，因此登入授權碼要由你自己操作，不要貼到 Codex 對話或公開分享。 開始前要準備什麼？這篇教學的練習環境是 MacBook。即使電腦沒有 NVIDIA 顯示卡，也可以先完成 Colab 的基本 Notebook 體驗；真正能否使用特定雲端 GPU，則要以帳號裡的實際選項為準。 工具或帳號 用途 需要注意的事 MacBook 操作終端機、Codex 與專案檔案 本文指令以 macOS 為例 Google 帳號 登入 Colab 確認登入的是有 Colab 權益的帳號 Google Colab 練習 Notebook 與租用雲端執行階段 GPU、限制與價格依當下方案而變 Git 下載公開專案 下載前先閱讀專案文件與授權 uv、Python 3.12 安裝 Colab CLI，執行專案提供的 Python 指令 以專案 README 與工具最新說明為準 Codex App 開啟本機資料夾，協助閱讀專案 使用者仍要審查命令與執行結果 Colab 運算單元 使用部分付費 GPU 資源 先看帳號餘額及當下費率，不要把測試數字視為保證 Codex 的方案額度與 Colab 的 GPU 費用是分開的。 使用 Codex 不會自動附送 Colab 運算單元。 符合資格的 Google AI 訂閱可能包含 Colab 權益，但實際內容依方案、地區與帳號而不同。不要依照舊文章中的固定 CCU 數量或價格購買；先到 Colab 帳號設定與付款頁，確認目前方案、餘額、費率與有效期限。 第一步：先免費體驗 Colab，不用安裝模型先打開 Google Colab 並登入 Google 帳號。 新增一個 Notebook。 在程式碼儲存格輸入： 1print("我的第一個 Google Colab 程式成功了！") 按儲存格左側的播放按鈕，或按 Shift + Enter。 看見輸出文字後，就完成了第一次雲端 Python 練習。 這一步不需要高階 GPU，也不需要下載影片模型。 如果只是熟悉介面，可以先使用一般 CPU 執行階段。上方「執行階段」選單裡的硬體選項會依帳號與時間不同；先查看有哪些選項即可，不用急著啟用 GPU。 工作完成後，從「執行階段」選單中停止或刪除執行階段。Colab 執行階段是暫時環境，重要檔案要下載回自己的電腦或另存到你信任的位置。 第二步：先看懂山獅霸開源專案本文使用的範例是 山獅霸 AI 影片工作流 Colab 版。它把劇本、角色圖片、影片生成、配音、配樂、字幕與剪輯拆成多個階段，並提供給 AI Agent 閱讀的文件。 下載之前，先認識幾個重要檔案： 檔案或資料夾 用途 README.md 專案介紹、硬體版本與快速開始方式 AGENT_SETUP.md 提供 AI Agent 的專案閱讀與環境檢查指引 cloud/README.md Colab 操作、雲端費用、授權與機房注意事項 THIRD_PARTY_NOTICES.md 第三方程式與模型授權資訊 docs/hardware.md 各硬體版本與執行條件 cloud/ 連接 Colab 與執行雲端流程的程式 pipeline/template_local/ 建立新影片時可參考的範本流程 這是公開原始碼專案，但「開源」不等於每個模型都能自由商用，也不表示所有程式都適合直接執行。下載後先閱讀 README、安裝文件、授權與第三方告示；要執行任何安裝或雲端操作腳本前，請先讓 Codex 列出它會讀寫哪些檔案、下載什麼模型、連線到哪些服務、是否會啟動付費執行階段，再由你檢查。 上游專案的流程涵蓋角色定妝、場景與首幀、配音、H3 影片、配樂、字幕和剪輯。原始專案也提醒，部分模型只供非商業用途；若要製作商用影片，必須逐一核對模型、素材、音訊與輸出的授權，不要只看整個 GitHub Repo 的授權名稱。 第三步：在 Mac 安裝基本工具開始前先確認專案文件與程式碼。以下是上游文件提供的 Mac 操作方向；執行前仍應核對該專案與 Colab CLI 的最新安裝說明。 1. 確認 Git打開「終端機」，輸入： 1git --version 若系統提示安裝 Command Line Developer Tools，依照 macOS 顯示的官方提示操作。 2. 安裝 uv 與 Python 3.12已安裝 Homebrew 的 Mac 可以用： 1brew install uv 也可以參考 uv 官方安裝文件選擇適合自己的方式。 確認 uv 可用後，安裝 Python 3.12： 12uv --versionuv python install 3.12 3. 安裝 Google Colab CLIGoogle 官方 CLI 文件目前提供 uv 安裝方式： 12uv tool install google-colab-clicolab version 如果系統找不到 colab 指令，可以依 uv 文件更新 shell 路徑，然後重新開啟終端機再確認。 Google Colab CLI 官方目前支援 macOS 與 Linux；Windows 尚未列為支援平台。不要直接把網路上找到的 Windows patch 套用到其他版本；先確認專案作者提供的修補方式、修改內容與備份方法，再決定是否使用。 4. 登入 Google 帳號輸入： 1colab usage 第一次使用時，CLI 可能會要求你在瀏覽器登入並完成授權。請由你本人在自己的終端機操作。 不要把 Google 顯示的授權碼貼到 Codex 對話、聊天室或程式碼檔案中。 授權碼與帳號登入資訊一樣，需要妥善保管。登入後，colab usage 可以查看帳號運算單元的使用率與餘額。 第四步：下載專案，讓 Codex 先做唯讀檢查先在終端機建立工作資料夾，再下載公開 Repo： 1234mkdir -p ~/AI-Video-Testcd ~/AI-Video-Testgit clone https://github.com/mathruffian-dot/shanshiba-workflow-colab.gitcd shanshiba-workflow-colab 下載 Repo 不代表已經下載所有模型。模型可能很大；上游 Colab 版本會在遠端執行階段準備所需環境，Mac 的硬碟仍需保留專案檔案與下載成果的空間。 如果你使用 Codex App，可以開啟這個本機資料夾，讓 Codex 先閱讀 README、AGENT_SETUP.md、cloud/README.md、docs/hardware.md 和 THIRD_PARTY_NOTICES.md。初次檢查時，不要讓 Agent 自動安裝套件、啟動 GPU、下載模型或執行影片任務。 給 Codex 的環境檢查提示詞123456789101112131415161718192021222324你是我的 Google Colab 與 AI 影片工作流助教。我第一次使用 Google Colab，也第一次操作這個 GitHub 專案。我的設備是 MacBook，沒有 NVIDIA CUDA 顯示卡。請先唯讀閱讀：1. README.md2. AGENT_SETUP.md3. cloud/README.md4. docs/hardware.md5. THIRD_PARTY_NOTICES.md請整理以下資訊：1. Mac 本機需要哪些工具與版本。2. 哪些命令只會讀取資訊，哪些命令會安裝套件、修改檔案或連線到外部服務。3. 哪些命令會建立 Colab 執行階段、可能消耗 CCU 或產生費用。4. 專案中各模型、素材與輸出的授權限制。5. 使用 MiniMax H3 時，執行地區與目前授權是否相容；若無法確認，請明確標為未知。6. 完成範例影片所需的本機空間、下載內容與預估步驟。這一輪只做閱讀和檢查：不要執行安裝指令、不要修改檔案、不要登入帳號、不要啟動 GPU、不要下載模型，也不要開始影片生成。先列出檢查結果與仍需我確認的項目。 這樣可以先取得操作清單，再由你決定是否繼續。AI Agent 的建議仍需要人工檢查，尤其是任何會執行外部程式、寫入檔案、傳送素材或啟動付費資源的步驟。 先做帳號與專案檢查在專案目錄中，上游提供的檢查指令是： 1uv run --no-project --python 3.12 cloud/colab_h3.py check 執行前先確認這支程式的內容與目前文件一致。依上游文件，check 用來檢查 CLI 與帳號用量；它不應替你啟動 GPU。若實際程式行為與文件不符，先停止並查明原因。 第五步：看清額度與 H3 授權，再考慮 GPU第一次操作不必急著購買 CCU 或啟動 GPU。若要使用付費方案，先打開 Colab 當下的方案頁，核對價格、帳號權益、額度到期規則與硬體供應情況。 有餘額也不代表一定拿得到 G4。建立 GPU 執行階段前，先了解 Colab 可能分配的地區與硬體，再確認該執行環境是否符合模型授權。 MiniMax H3 的地區限制是重要停步點MiniMax H3 開放權重的授權文件目前將美國、歐盟、英國與南韓列為排除地區。上游專案表示，它測試到的 Colab G4 執行階段位於美國或歐盟；因此「成功取得 G4」不代表「可以在這個執行階段使用 H3」。 實際條款可能更新，且授權文件未必能回答每種跨境雲端情況。請直接閱讀目前的 MiniMax H3 Community License與上游Colab 機房說明。如果地區或適用方式不清楚，不要下載或執行 H3 權重；先向權利人確認，或選擇授權明確適用的模型與雲端環境。 上游文件提到可用 IP 地理位置服務作為線索，但 IP 顯示的城市不等於法律上的機房位置證明；向第三方地理位置服務查詢也會把執行階段的公開出口 IP 傳給該服務。不要把這種查詢結果當成授權確認。 若已確認可以測試，再單獨檢查 GPU只有在你已了解可能費用，並確認所在地與模型授權條件後，才考慮建立 GPU 執行階段。上游文件範例為： 1colab new -s h3 --gpu G4 這會嘗試建立名為 h3 的 G4 執行階段。建立前先確認帳號餘額與當下費率；建立後，運算單元可能隨執行時間扣抵。 若不確定授權或費用，停在這裡即可。不要為了測試能否開機，就先建立 GPU 再說。 若你已確認條件並建立了執行階段，可以用 CLI 查看狀態，並依官方命令將簡單檢查傳到遠端： 12colab status -s h3echo 'import subprocess; print(subprocess.getoutput("nvidia-smi"))' | colab exec -s h3 nvidia-smi 可以顯示遠端 GPU 資訊，但只能確認硬體狀態，不能證明模型授權、商用權利或 GPU 後續仍可取得。 檢查完就停止執行階段完成硬體檢查後，若不打算繼續，立即停止： 123colab stop -s h3colab sessionscolab usage 第一行停止名為 h3 的執行階段；後兩行可再次檢查目前連線與帳號用量。 關閉 Codex、終端機或瀏覽器分頁，不等於遠端執行階段已停止。每次使用後，都要親自確認 Colab session 已停止。 第六步：在授權允許的環境執行範例工作流只有在 H3 授權與執行地區已確認相容、費用可接受，而且你已檢查上游腳本之後，才進入這一節。 上游專案的完整流程指令包括： 12345uv run --no-project --python 3.12 cloud/colab_h3.py startuv run --no-project --python 3.12 cloud/colab_h3.py smokeuv run --no-project --python 3.12 cloud/colab_h3.py film pipeline/template_local chars masters framesuv run --no-project --python 3.12 cloud/colab_h3.py film pipeline/template_local voices h3 amb edl music ending cut reviewuv run --no-project --python 3.12 cloud/colab_h3.py stop 這些不是單純查看資訊的命令： start 會建立雲端工作環境、安裝或準備多項依賴與模型。 smoke 會執行多個功能檢查。 film ... chars masters frames 會產生角色、場景和鏡頭首幀。 film ... voices h3 ... review 會生成配音、影片與其他素材，並執行後製檢查。 stop 會停止雲端執行階段；仍應用 colab sessions 確認停止狀態。 先檢查每個命令會下載什麼、寫入哪個資料夾、連線哪些模型服務，以及哪些階段可能消耗 CCU。不要把整段流程一次交給 Agent 自動執行；分階段審核輸出，必要時手動停止。 先驗收角色與首幀，再決定是否繼續在授權與費用條件都通過後，先產生範例角色和首幀，再人工檢查角色外觀、服裝、場景與構圖。若第一張圖就偏離劇本，先修正設定，不要直接進入大量影片生成。 上游範例會把部分結果同步到專案資料夾。請核對目前版本的文件，確認實際輸出路徑與生成內容後再繼續；目錄名稱可能隨上游版本調整。 影片生成、配音、下載或 GPU 連線失敗時，可能需要排錯或重跑。失敗重跑也可能增加運算時間與額度消耗，因此不保證第一次就能完成，也不應把作者某一次測試的耗時當成你的預估值。 第一次測試要準備多少 CCU？可以先參考上游作者在 2026 年 10 月 10 日公開的測試紀錄，但它只代表該專案版本與該次執行情況，不是 Google 的固定價目或每支影片的保證成本。 上游測試項目 作者記錄值 G4 測試耗用 約 8.90 CCU／小時 完整環境安裝 約 1.5 CCU 單獨生成 30 鏡 H3 影片 約 3 CCU 安裝、測試並完成 38.5 秒範例 合計約 8 CCU 以 8.90 CCU／小時換算，100 CCU 理論值 約 11.2 小時 作者的「30 鏡影片約 3 CCU」只計算 H3 生成部分，不含所有配音、生圖、配樂與剪輯；「38.5 秒範例約 8 CCU」也不代表其他長度或不同設定會有相同消耗。 購買或啟動前，請直接查看 Colab 帳號目前的方案、費率與餘額。可以先訂一個自己願意承擔的測試上限，逐階段檢查 colab usage；但這只是人工預算目標，不代表 Colab 已替你設定自動硬性上限。 確認範例可用後，如何改成自己的影片？上游專案以 pipeline/template_local/film.json 管理範例影片設定。它包含影片名稱、人物、場景、分鏡、台詞與剪輯等資料。 不要直接覆蓋原始範例。先複製成自己的工作資料夾，確認新資料夾沒有帶入舊的生成快取，再讓 Codex 協助整理設定。每次生成前，先審核劇本、角色、鏡頭、輸出比例、素材來源、預計消耗與使用授權。 給 Codex 的原創短劇規劃提示詞1234567891011121314151617181920我已閱讀並理解這個專案的工作流。我想製作一支自己的原創 AI 短劇，請先協助規劃，不要執行生成。片名：《當 AI 助理請假》影片長度：20～30 秒比例：先依目前範例設定風格：台灣職場喜劇人物：一位老闆、一位 AI 助理故事：老闆什麼都依賴 AI，結果 AI 突然宣布今天休假。請先協助：1. 寫出完整劇本。2. 設計角色外觀與個性。3. 規劃 4～6 個鏡頭。4. 列出各鏡的角色、動作、台詞與預期畫面。5. 說明需要修改或新增哪些檔案，以及是否會影響原始範例。這一輪只整理提案，不要複製檔案、修改 film.json、啟動 GPU、下載模型或產生素材。等我確認劇本、費用與授權後，再列下一階段計畫。 讓 AI Agent 先整理可檢查的提案，等你確認後再進入會寫檔、連線或花費的操作。 如果你對「先租雲端 GPU 還是購買設備」也想比較，可以延伸閱讀先租 GPU，還是該買 RTX 5090？；想了解 Codex 如何串起影片工作的各階段，可以接著看用 Codex 打造 AI 影片工廠。 常見問題Q1：MacBook M2 沒有 NVIDIA 顯示卡，也能做 AI 影片嗎？可以用 MacBook 操作 Colab、管理專案並下載成果；需要大量 GPU 的階段則要看雲端資源是否可用，以及模型授權是否允許在該執行環境使用。這不表示所有模型都能在 Mac 本機執行，也不保證 Colab 一定提供指定 GPU。 Q2：第一次使用 Google Colab 一定要購買 CCU 嗎？不一定。你可以先用免費 Notebook 練習 Python 與 Colab 介面。若要取得付費方案或特定加速器，先確認帳號目前的方案與供應情況；付費也不保證分配到 G4。 Q3：取得 Colab G4 後，就能直接執行 MiniMax H3 嗎？不能只憑取得 GPU 就判定可以。MiniMax H3 開放權重授權目前排除美國、歐盟、英國與南韓，而上游專案回報它測試到的 Colab G4 位於美國或歐盟。執行前要確認最新授權和雲端執行環境；不確定時先停止並向權利人確認。 Q4：關閉 Codex 或終端機，Colab GPU 會自動停止嗎？不要這樣假設。請使用 colab stop -s <session> 停止遠端執行階段，再用 colab sessions 確認 session 已結束，並查看 colab usage 檢查用量。 Q5：這套專案產出的影片可以商業使用嗎？不能直接假設整套工作流都能商用。要逐一確認 H3、圖像與語音模型、音樂、角色素材、訓練或參考資料及輸出內容的授權；專案作者也標示部分模型僅供非商業用途。商用前請閱讀各模型與素材的現行條款。 參考資料與延伸閱讀 山獅霸 AI 影片工作流 Colab 版 GitHub 山獅霸的多重宇宙｜YouTube 原始影片 Google Colab Google Colab 官方常見問題 Google Colab CLI 官方 GitHub MiniMax H3 Community License uv 官方安裝文件 OpenAI Codex App 文件 本文依上游專案文件與官方說明整理，最後檢視日期為 2026 年 10 月 18 日。Colab 方案、GPU 供應、運算單元費率、CLI 功能與模型授權都可能更新；操作前請查看各官方頁面及專案目前版本。

  • article-Codex 新手教學：用 3 個 Markdown 檔案讓 AI 接續你的專案

    2026/10/16

    AI工具 Vibe Coding Codex
    Codex 新手教學：用 3 個 Markdown 檔案讓 AI 接續你的專案

    昨天才和 AI 討論好網站要做什麼，今天開啟新對話，它卻又問：「你想做什麼網站？」 或者，原本用 Claude Code 寫到一半，想換 Codex 接手，卻得把需求、決策和目前進度重新說一次。更麻煩的是，明明已經說過某個功能不要做，換個對話，AI 又把它加回來。 對剛開始學 AI Coding 的人來說，有個實用的習慣：把重要的專案資訊寫進檔案，讓每次工作的 AI 都能重新讀取。 這篇不教複雜語法，也不需要先安裝外掛。我們會用一個簡單的網站練習，建立三份 Markdown 文件，並準備「初始化、開工、收工」提示詞，讓新對話有機會從上次的進度繼續。 三個 Markdown 檔案各自負責什麼？這個做法參考三師爸 Sense Bar 在「AI Agent 基本功」EP06 分享的跨電腦專案管理流程，再加上一份 project.md，把長期需求和每天的工作進度分開。 檔案 可以把它想成 記錄內容 project.md 專案企劃書 專案目標、使用者、已確認需求、暫不處理的項目、重要決策和驗收標準 AGENTS.md AI 工作守則 AI 在這個專案裡要遵守的規則，以及需要讀取哪些文件 handoff.md 工作交接簿 目前進度、已驗證與未驗證項目、問題、下一步和最後更新時間 三份檔案都是純文字 Markdown，可以用文字編輯器打開。你不必先學會 Markdown；用一般文字和標題整理內容就能開始。 其中，AGENTS.md 是 Codex 支援的指示檔，Codex 會依照檔案所在位置讀取適用的專案指示。project.md 和 handoff.md 則是我們自行約定的檔名；若希望 AI 使用它們，請在提示詞中要求讀取，或在 AGENTS.md 裡清楚指示何時讀取。OpenAI 官方文件也說明了 Codex 如何發現 AGENTS.md。 第一次實作：先建立專案文件我們用「製作一個 AI 入門課程介紹網站」當作練習。先在 Finder 建立一個資料夾，例如 my-first-ai-website，接著在 ChatGPT 桌面版中選擇這個資料夾作為工作位置，並在新對話中選擇 Codex。介面名稱可能隨版本調整；官方 Codex Quickstart 有目前的桌面版入門說明。 第一步先不要叫 AI 寫網站，請它建立需求和交接文件。可以貼上這段提示詞： 提示詞 ①｜初始化我的第一個專案 12345678910111213141516171819202122232425262728293031323334353637383940414243你現在是我的 Codex 入門教練。我完全不懂程式設計，請用台灣繁體中文、新手能理解的方式協助我。我要建立一個「AI 入門課程介紹網站」。目標：讓一般人可以透過網站了解課程內容，包含課程介紹、學習特色、適合對象、常見問題及聯絡方式。請先不要製作網站程式。第一步，請確認目前專案的工作目錄。第二步，在專案根目錄建立三份 Markdown 文件：1. project.md記錄專案目標、目標使用者、確定要做的功能、暫時不做的功能、重要決策及驗收標準。2. AGENTS.md記錄 AI 工作規則。要求 AI 在接續任務時，按需要讀取project.md 和 handoff.md。不得擅自增加功能、改變已確認需求，或把尚未完成的工作說成已完成。3. handoff.md記錄目前進度、完成事項、驗證狀態、待辦事項及下一步工作。第三步，說明這三份文件各自的用途。要求：- 不要安裝任何套件- 不要部署網站- 不要推送到 GitHub- 不要修改專案資料夾以外的檔案- 如果已有同名文件，先檢查，不要直接覆蓋- 完成後確認三份檔案確實存在 這段提示詞也要求 AI 確認工作目錄、檢查同名文件，並在完成後確認檔案確實存在。AI 在聊天裡說「完成」不代表檔案已經寫入；可以回到 Finder，確認資料夾裡看得到： 1234my-first-ai-website/├── AGENTS.md├── project.md└── handoff.md 文件準備好後，再請 AI 製作網站三份文件建立後，請 AI 先讀取規格，再依規格動工。這能讓已確認的需求和限制比較容易帶進下一步。 提示詞 ②｜按照專案規格製作網站 12345678910111213141516171819202122請先讀取 project.md、AGENTS.md和 handoff.md，確認目前的專案目標與限制。接著開始製作第一版網站。需求：1. 使用 HTML、CSS 和必要的 JavaScript2. 暫時不使用資料庫或後端服務3. 網站要有課程介紹、課程特色、 適合對象、常見問題、聯絡方式4. 使用繁體中文5. 電腦與手機都要能正常閱讀6. 版面簡潔、專業，適合 AI 入門課程7. 聯絡功能先使用示範內容， 不要假裝已經完成正式報名或付款系統完成後：- 確認程式檔案已建立- 檢查是否有明顯錯誤- 告訴我如何在 Mac 上開啟網站- 區分已驗證與尚未驗證的功能- 用新手能理解的方式解釋結果 網站完成後，可以依照 AI 提供的方法預覽，再把瀏覽器視窗縮小，檢查手機版是否容易閱讀。如果發現 FAQ 字太小，可以具體要求：「手機版 FAQ 文字太小，請加大字體、調整行距，但不要修改其他區塊。」 用自然語言描述想看到的結果，是 AI Coding 對初學者很有幫助的地方；仍要親自檢查畫面和功能，不能只看 AI 的完成摘要。 每天結束前更新交接簿準備休息時，請 AI 根據專案檔案和實際成果更新 handoff.md。交接內容要分清楚哪些已完成、哪些真的驗證過，以及哪些還沒檢查。 提示詞 ③｜收工，保存交接進度 12345678910111213141516171819202122今天先做到這裡，請幫我收工。請檢查目前專案檔案與實際工作成果。更新 handoff.md，包含：- 這次完成了什麼- 哪些功能已驗證- 哪些功能尚未驗證- 有哪些問題或阻礙- 下次建議先做的三件事- 最後更新時間如果本次沒有改變已確認的需求，就不要修改 project.md。如果有重要需求變更，先列出差異供我確認，不要自行定案。請不要刪除檔案、部署網站，也不要自動推送到 GitHub。最後告訴我文件實際更新了哪些內容。 例如，「表單介面已經寫好」不代表「報名資料已成功送出」。這兩種狀態分開記錄，下一次接手時才不會把未驗證的功能誤認為完成。 隔天開新對話時，先開工再修改隔天重新開啟同一個專案資料夾，開始新對話。先請 Codex 讀取三份文件，並檢查專案目前的 Git 狀態，再決定今天要做什麼。 提示詞 ④｜開工，接續昨天的工作 12345678910111213141516171819202122今天要繼續這個專案，請幫我開工。先確認目前工作目錄。讀取：1. AGENTS.md2. project.md3. handoff.md如果專案有使用 Git，也請檢查目前版本與未提交的變更。請先不要修改程式。告訴我：- 這是什麼專案- 已經完成了什麼- 哪些地方還沒驗證- 上次停在哪裡- 今天最適合先做哪三件事請不要重新製作已完成的功能。 這份交接不是昨天聊天紀錄的摘要，而是要求 AI 對照專案目前的檔案與變更。若交接文件已經過期，或實際程式和文件不一致，就要先核對再動工。 想自動化開工和收工時，再了解 Skill每次複製長提示詞可能有點麻煩。熟悉基本流程後，可以再研究把常用指示整理成 Skill，減少重複輸入。 三師爸 Sense Bar 開源的 cross-device-agent-skills 提供三個流程：project-init（初始化專案）、startup（開工）和 shutdown（收工）。它也介紹 GitHub 和 Obsidian 等延伸整合，實際效果會依安裝、設定和可用工具而不同。 要先看清楚 Skill 會讀寫哪些檔案、需要哪些權限，以及是否會操作 Git。該專案 README 說明 shutdown 流程可能執行 git commit 和 git push；如果你不希望 AI 自動提交或推送，就要在使用前檢視流程並調整規則。想延伸了解 Skill 與 Plugin 的差異，可以參考站內的 Codex Skill 與 Plugin 指南。 GitHub 和 Google Drive 要一開始就設定嗎？剛開始練習時，可以先只在本機完成三件事： Codex 在正確的資料夾建立了專案文件。 新對話能照指示讀取前一次的進度。 收工時能根據實際成果更新交接簿。 熟悉之後再學 GitHub。GitHub 能保存版本歷史，也可讓不同電腦取得專案；但「本機 commit」只代表建立了一筆本機版本紀錄，還要成功 push 才會送到遠端。 Google Drive 桌面版可以同步一般檔案，但若多台電腦同時修改同一個專案，可能發生同步衝突。跨裝置工作前，先了解雲端同步和 Git 的使用方式；不要把「檔案在雲端資料夾」當成「版本備份和同步都已驗證」。 已經寫一半的專案，也能補上交接文件嗎？可以。先請 AI 檢查目前專案和既有文件，再根據實際內容整理，不必從頭重做。遇到資訊不足的地方，標記「待確認」，不要猜測，也不要覆蓋原有設定。 提示詞 ⑤｜替舊專案補上交接機制 12345678910111213141516171819202122232425262728我已經有一個正在開發中的專案。請先檢查現有的資料夾、程式檔案和專案文件。不要重新製作網站，也不要覆蓋原有設定。請根據實際內容，協助我整理：- project.md：專案目標、需求、限制、 已確認決策及驗收標準- AGENTS.md：AI 工作守則和文件入口- handoff.md：目前進度、驗證狀態與下一步如果已經存在相關文件，請優先整合，避免產生互相矛盾的規則。請嚴格區分：使用者已確認的要求、AI 自己提出的建議、實際完成的功能、尚未驗證的工作。不確定的事項請標記「待確認」，不要自行猜測。完成後提供文件摘要與差異，不要擅自變更功能或部署網站。 專案文件讓接手更清楚，仍要核對實際成果project.md、AGENTS.md 和 handoff.md 不會自動讓 AI 永遠記得所有事情。它們的用途是把重要需求、工作規則和目前進度放在容易找到的位置，讓每次接手時有一份可查閱的依據。 文件可能過期，AI 也可能漏讀；開始修改前仍要對照程式、版本控制狀態和實際驗收結果。對 AI Coding 新手而言，先學會保存需求、標示驗證狀態和更新交接內容，往往比多背幾段提示詞更能讓專案順利延續。 常見問答 (FAQ)Q1：project.md 和 handoff.md 會被 Codex 自動讀取嗎？預設情況下，Codex 會依規則發現適用的 AGENTS.md。project.md 和 handoff.md 是自訂檔名，應在提示詞中明確要求讀取，或透過 AGENTS.md 指示 Codex 何時讀取。 Q2：不會寫程式，也能使用這三份文件嗎？可以。你可以用一般文字描述目標、限制和進度，再請 Codex 協助整理文件。仍要親自確認需求和驗收結果是否正確。 Q3：建立 handoff.md 就等於已經備份專案嗎？不是。handoff.md 只是記錄工作的文字檔。若要保存程式版本或在不同裝置取得專案，還需要設定 Git、遠端儲存或同步工具，並確認相關操作確實成功。 Q4：已經開發一半，還能開始使用嗎？可以。先檢查現有檔案和文件，再整理專案目標與進度；不確定的內容標記待確認，避免把建議誤寫成已確認需求。 Q5：交接文件可以完全避免 AI 重做或誤解需求嗎？不能保證。文件能降低重新交代的成本，但仍需要定期更新，並在每次工作開始時對照實際檔案、程式狀態和驗收結果。 參考資料與延伸學習三師爸 Sense Bar｜AI Agent 基本功 EP06：如何讓多個 AI Agent 跨電腦協作專案 影片：https://www.youtube.com/watch?v=mnFdJaAmeUM cross-device-agent-skills 開源專案 GitHub：https://github.com/mathruffian-dot/cross-device-agent-skills OpenAI｜Codex AGENTS.md 官方文件 OpenAI｜Codex AGENTS.md 官方文件 OpenAI｜Codex／ChatGPT 桌面版入門文件 OpenAI｜Codex／ChatGPT 桌面版入門文件 #Codex #AICoding #VibeCoding #AI教學 #AGENTSmd #ChatGPT #ClaudeCode #AI工作流

  • article-用 Codex 製作風格一致的 AI 簡報：YAML Image Deck 實作教學

    2026/10/11

    AI工具 AI自動化 Codex
    用 Codex 製作風格一致的 AI 簡報：YAML Image Deck 實作教學

    不用先學 YAML，也不用自己寫生圖提示詞。你要準備的是簡報需求、可靠內容與視覺方向，再讓 Codex 分階段完成。 第一次建議拿一個小單元練習。本文以「8 頁、20 分鐘的小店社群行銷教學」示範，保留可直接貼進 Codex App 的各階段提示詞，文末附練習素材包。 本文依 2026 年 10 月 11 日可查到的 YAML Image Deck 原專案 與官方文件整理。工具能力與額度可能調整；需求表、案例、試批頁數與重試次數屬於本教學建議。 很多人第一次用 AI 做簡報，會直接下指令： 幫我把這份教材做成漂亮的簡報。 但這句話把好幾個不同的任務混在一起：整理內容、安排教學順序、設計版型、生成圖片、組裝簡報，以及檢查成品。 這篇教學把它拆開： 準備資料 → 確認大綱 → 建立規格 → 確認樣張 → 分批生成 → 組裝驗收 → 局部修改。 YAML Image Deck 的角色，是讓 Codex 把整份簡報的視覺規則、版型與逐頁內容寫成規格，再依規格生成。**它不是一套安裝完就能獨立運作的簡報軟體，也不會光靠 YAML 就自動產生 PPTX。**最後仍需要實際可用的生圖與簡報組裝工具。 一、先決定：你要「圖片式簡報」，還是「文字可修改的簡報」？這會影響後面整個流程。 模式 實際做法 適合什麼用途 baked 圖片、文字、排版一起生成在圖片裡 視覺展示、短篇分享、不太需要改字的簡報 plate 先生成無字底圖，再疊上 PowerPoint 原生文字 教材、企業簡報、經常修改的內容 這篇教學選 plate。 例如投影片寫著「發布前，檢查三件事」，日後想改成「發布前，先核對這三點」，應該只需要修改文字，不必整張重新生圖。 但要注意： plate 是「底圖仍是圖片，文字另外編輯」，不是把 AI 插畫自動變成可拆解的 PowerPoint 圖形。 原專案也要求，在精確性重要時，把公式、圖表、數字等內容保留為原生可編輯元素。參見 原專案 SKILL.md。 這篇範例的設定我們要做的是： 給小店老闆的 AI 社群貼文入門8 頁，20 分鐘，台灣繁體中文，16:9，文字可修改。 以下的店家與案例都是教學用的虛構資料，不代表任何真實商家的活動或成效。 二、階段 0：先讓 Codex 準備工作環境你先做什麼？在 Mac 建立一個獨立資料夾，例如： 1yaml-image-deck-starter 再用 Codex App 開啟這個資料夾。 你也可以直接使用文末附的練習素材包，解壓縮後開啟，不用自己一個一個建立檔案。 先在獨立練習專案測試，不要一開始就要求 Codex 改動既有的正式教材專案。 Skill 安裝在哪裡才找得到？作者 README 使用的是 .codex/skills 安裝方式；但目前 OpenAI 官方文件列出的本機 Skill 搜尋位置，包含專案內的 .agents/skills，以及使用者層級的 ~/.agents/skills。 這篇採用專案內安裝，比較容易知道這個 Skill 是為哪份教材服務。已經裝過的人，先檢查實際位置，不必再裝第二份。官方也說明，同名 Skill 不會自動合併；安裝後沒有出現時，可以重新啟動 Codex。 OpenAI Developers 貼給 Codex：環境準備提示詞1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950請幫我準備 YAML Image Deck 的練習環境。這一階段只檢查環境與安裝 Skill，不要開始生圖。我的環境是 macOS，使用 Codex App。請先回報目前工作區的絕對路徑。所有專案檔案都放在目前工作區，不操作其他專案。請依序處理：1. 檢查是否已安裝 yaml-image-deck Skill。 若已安裝，讀取並回報實際路徑與來源，不重複安裝或覆蓋。2. 若未安裝，先檢視這個專案的 README、SKILL.md 與腳本： https://github.com/mathruffian-dot/yaml-image-deck 先回報來源版本、預計安裝方式、讀寫路徑、網路目的地與憑證需求。 需要 git clone 後執行腳本、npx skills add 或 sudo 時， 先取得明確同意，再繼續安裝。 審查與必要授權完成後，將其中的 skills/yaml-image-deck 安裝到： .agents/skills/yaml-image-deck/ 記錄安裝來源與版本資訊。3. 檢查目前環境是否具備： - 可以實際呼叫的內建生圖工具。 - Python 3。 - PyYAML 與 Pillow。 - 可以建立 PPTX 的工具。 - 可以將 PPTX 渲染成圖片的工具。 - Skill 指定的繁體中文圓體。4. 缺少 Python 套件時，安裝於本專案的 .venv。 缺少系統軟體或字型時，先回報。 不要自行啟用 API 計費。5. 建立下列資料夾，已有內容不要覆蓋： sources/ prompt/ slides/images/ slides/previews/ output/ qa/把檢查結果寫入 qa/environment.md。請分清楚：「工具存在」、「已執行測試」、「尚未測試」。不要把尚未測試的能力直接寫成通過。 這一步要看什麼？不是看到「安裝成功」就往下走，而是要看清楚這三件事： 有沒有讀到 Skill？能不能生圖？能不能組裝與檢查 PPTX？ 原專案預設使用 Codex 內建生圖，並沒有要求使用者一開始就申請 API 金鑰。但這不等於無限免費；官方文件說明，內建生圖會計入 Codex 的使用額度。 ChatGPT Learn 三、階段 1：準備要交給 Codex 的三種資料不用先寫好每一頁，但一定要說清楚：這份簡報要教誰、教會什麼，以及哪些資料可以使用。 我建議準備三種內容。 第一種：簡報需求表 項目 這次的範例 主題 給小店老闆的 AI 社群貼文入門 對象 會使用聊天式 AI，但不熟悉提示詞的店家 教學目標 能提供店家資料，產生一篇草稿，再人工核對 頁數與時間 8 頁，20 分鐘，包含練習 核心訊息 先說清楚，再讓 AI 起稿，最後由人核對 輸出形式 16:9、繁體中文、plate 模式 不能做的事 不捏造價格、優惠、日期、成效或客戶見證 這張表的作用，是避免 Codex 把「給新手的實作課」做成「給主管看的產業趨勢報告」。 第二種：真正要教的內容你原本的 PPT、PDF、文章、筆記，都可以作為素材。 但我建議第一次只放跟這次主題直接相關的一小批資料，不要把整個歷年教材資料夾全部丟進去。 例如： 1234sources/├── 社群行銷舊教材.pptx├── 這次要講的重點.md└── 店家案例資料.md 如果沒有舊教材，也可以先寫一段這樣的原始內容： 1234567891011121314151617181920212223本次要教的內容：一、請 AI 寫貼文前，先提供四種資訊：對象、目的、事實、格式。二、建議流程：提供資料 → 產生草稿 → 人工核對 → 調整發布。三、虛構案例：店名：晨光咖啡。商品：新品燕麥拿鐵。受眾：附近上班族。目的：邀請讀者留言分享喜歡的咖啡口味。語氣：親切自然。格式：120–180 字，最後一句提問。沒有提供價格、優惠、日期、產地或健康效果，所以不能自行添加。四、發布前檢查：事實是否正確、語氣是否自然、行動是否清楚。五、最後讓學員用自己的產品資料練習。 這樣就已經能開始規劃，不需要先寫成完整文章。 第三種：視覺方向不用懂設計名詞，也能寫得很清楚： 奶油白底、深藍綠主色、橘色重點。插畫乾淨、有一點紙感，適合成人上課，不要像幼兒教材。文字要大、留白要夠，不要滿版小字，也不要大量霓虹科技元素。 有參考圖片時，再補一句： 只參考這張圖的配色與插畫感，不要複製裡面的品牌、人物或文字。 貼給 Codex：內容整理提示詞1234567891011121314151617181920212223242526272829這一階段只整理教學內容，不做設計、不生圖。請先讀取：- prompt/brief.md：簡報需求- prompt/brand.md：視覺方向- sources/：原始教材與案例先列出實際存在的檔案。不要假設不存在的附件已經提供。請把資料整理成 prompt/content-notes.md，分成：1. 本次一定要教的觀念。2. 可直接使用的範例。3. 適合放進練習的內容。4. 與本次主題無關、可以略過的內容。5. 資料不足、矛盾或需要查證的地方。如果讀取 PPT 或 PDF：- 保留來源檔名與頁碼。- 不要只靠萃取文字猜測圖表。- 無法讀取的頁面要明確列出。- 不要修改原始檔案。請區分：「來源提供的事實」、「教學用虛構案例」與「你的建議」。不要自行補出價格、優惠、日期、統計數字或成效。完成後停在內容審查，不開始製作簡報。 這一步你要確認什麼？最重要的是： Codex 整理出來的內容，真的是你這次要教的東西嗎？ 不要等到畫面很漂亮之後，才發現核心觀念講錯了。 四、階段 2：先確認逐頁大綱，不要急著生圖這一步不是單純列八個標題，而是決定： 每一頁要讓學員理解什麼。 我們這份範例可以安排成： 頁碼 投影片內容 這頁的任務 1 先說清楚，再讓 AI 寫 說明這堂課的目標 2 卡住的不是打字速度 引出對象、目的與資料不清楚的問題 3 同樣請 AI，差在資訊 比較模糊指令與完整指令 4 四步完成一篇貼文 展示從資料到發布的流程 5 先填這四格 教對象、目的、事實、格式 6 晨光咖啡，這樣開始 帶入虛構案例 7 發布前，檢查三件事 教人工核對 8 換你完成第一篇 讓學員動手練習 關鍵：把「投影片文字」與「講者要說的話」分開例如第 5 頁： 畫面上： 先填這四格對象｜目的｜事實｜格式 講者備註裡： 對象是希望誰看到；目的不是一定要成交，也可以是讓讀者留言；事實只能放已確認的商品資訊；格式包含語氣、字數與結尾行動。 這樣才不會變成把講義全文塞進投影片。 貼給 Codex：大綱規劃提示詞123456789101112131415161718192021222324252627請依照 prompt/brief.md 與已核對的內容，規劃 8 頁、20 分鐘的教學簡報。每一頁都要列出：- 頁碼與用途。- 唯一的核心訊息。- 精確的上版文字。- 圖像應該表達什麼。- 資料來源。- 講者備註。- 建議講解或練習時間。本次內容密度建議：- 標題盡量控制在 16 個中文字內。- 一般內容頁以 3 個重點為原則。- 四格分類與四步流程，可以依實際結構呈現。- 完整解釋與長篇提示詞放在講者備註或練習講義。不要為了湊頁數重複內容。不要自行補出來源沒有提供的事實。輸出：prompt/outline.mdprompt/speaker-notes.md現在不要生圖。先讓我確認教學順序與每頁文字。 這裡的字數與頁數，是這份練習的建議，不是 Skill 的硬性限制。 大綱看完沒有問題後，你再回覆： 大綱與文字確認，請以這個版本進入設計規格階段，先不要生圖。 五、階段 3：讓 Codex 把白話需求轉成 YAMLYAML 到底是什麼？在這個工作流程裡，你可以把它理解為： 一份有固定欄位的簡報製作規格。 它會記錄受眾、頁數、配色、字體方向、版型，以及每一頁要出現的內容。 但原作者特別強調，YAML 是設計契約，不是精確到每個像素的渲染程式碼。因此，寫好規格之後仍然要生成、檢查與調整。欄位定義可對照 原專案 schema。 你只需要看懂幾個欄位 欄位 白話意思 deck 整份簡報要做什麼 canvas 畫面比例與安全邊界 design_system 配色、字體感、共同視覺規則 slides 每一頁的內容 layout.id 這一頁採用哪種版型 visible_text 最後投影片上要出現的文字 visual 圖片應該表達什麼 原專案的版型選擇是依「資訊關係」分派，例如比較、流程、分類、案例、總結，而不是每頁隨機換裝飾。 例如第 3 頁的規格片段可能長這樣： 12345678910111213141516171819# 這是單頁示意片段，不是完整可執行的 spec.yaml。page: 3role: "comparison"core_point: "提供清楚資訊，讓草稿有明確方向"semantic_structure: "contrast"layout: id: "comparison_split" variant: "left_right"visible_text: title: "同樣請 AI，差在資訊" labels: - "模糊：幫我寫貼文" - "清楚：對象＋目的＋事實＋格式"visual: "左右比較，左側凌亂紙片，右側整理好的資料卡。"output: "slides/images/page_03.png" **你不需要自己寫這段。**讓 Codex 依原專案模板產生即可。 plate 還需要多一份「文字放哪裡」的規格例如標題放在上方、比較文字放左右兩欄，這些都需要有明確位置。 原專案提到 overlay_blocks，但沒有提供一套完整、通用的文字疊加渲染器。實務上要讓 Codex 配合你當前使用的簡報工具，補上文字方塊的位置、大小、字級與對齊。 貼給 Codex：設計規格提示詞1234567891011121314151617181920212223242526272829303132333435363738394041424344使用 $yaml-image-deck。這一階段只建立設計規格，不生圖。請讀取：- 已核准的 prompt/outline.md- prompt/brand.md- 這個 Skill 的 spec-template.yaml- references/schema.md- references/layout-library.md- references/prompting.md請建立 prompt/spec.yaml，設定：- output_mode: plate- planning_mode: yaml_spec- generation_strategy: sequential- style_lock: golden_sample- 16:9- 台灣繁體中文每頁要依資訊關係選擇原專案支援的 layout.id。相同版型不要連續使用超過兩頁。沒有真正生成並核准樣張之前，design_system.style_reference 保持空白，不要假造一個已存在的參考圖片路徑。plate 模式的 visible_text 是後續要疊加的文字，不能要求生圖工具把這些字畫進底圖。另建立 prompt/overlay-plan.yaml：定義每頁文字內容、位置、尺寸、座標單位、字型、字級、顏色與對齊方式。這份 overlay-plan 是本專案的組裝規格。請說明實際簡報工具如何讀取，不要假稱原專案已經內建完整的文字疊加功能。檢查 Skill 指定的圓體是否已安裝；缺少時先回報，不要偷偷換成其他字型。執行原專案的 validate_spec.py，保存執行結果。完成後顯示設計摘要與待確認事項，不開始生圖。 這一步你要看什麼？不必逐行閱讀 YAML。請 Codex 用白話回報： 這份簡報用什麼配色？字體是否可用？每一頁為什麼用這個版型？哪些內容是圖片，哪些內容可以編輯？ 這幾件事講得清楚，就比較容易發現方向是否跑掉。 六、階段 4：只生成一張黃金樣張先不要做整份簡報。 這裡的「黃金樣張」，就是你核准的視覺基準。後面各頁參考它的配色、插畫材質與視覺語言，而不是重新猜一次。 原專案要求先生成一張代表性的內容頁，確認後再存入風格參考路徑。 為什麼這次選第 3 頁，不選封面？這是我的實作建議：第 3 頁同時有標題、比較文字、插畫與留白，比只有大標題的封面更能測試整套規則。 封面好看，不代表一般內容頁也放得下。 貼給 Codex：黃金樣張提示詞1234567891011121314151617181920212223242526272829303132333435363738394041使用 $yaml-image-deck。這次只製作第 3 頁作為黃金樣張，不要生成其他頁。請讀取：prompt/spec.yamlprompt/overlay-plan.yaml以及相關 Skill 規則。先編譯這一頁的生圖提示詞，儲存為：prompt/image-prompts/page_03_v01.md提示詞必須包含：- 完整 16:9 投影片底圖，不是螢幕或投影幕示意。- 左右各 6%、上下各 10% 的重要內容安全邊界。- 左右比較的構圖與閱讀順序。- 左側是凌亂紙片，右側是整理好的資料卡。- 為標題與兩側文字保留安靜、清楚的區域。- 沿用已確認的配色與插畫風格。- 不生成文字、偽文字、Logo、頁碼或浮水印。使用目前實際可用的內建生圖工具，產生無字底圖並保存到：slides/images/page_03_v01.png接著依規格疊加原生可編輯文字，輸出：output/golden-sample_v01.pptx再從該 PPTX 渲染完整預覽：slides/previews/page_03_v01.png請讓我同時檢視：1. 無字底圖。2. 疊上文字後的完整投影片。若無法生圖或渲染 PPTX，明確回報未完成項目。不要以其他結果冒充。完成後停下，等我核准。 你怎麼知道樣張可以通過？不要只看「圖片漂亮不漂亮」，而要看完整頁面： 標題好不好讀？文字區夠不夠？圖像有沒有幫助理解？是不是你想要的成人教學風格？ plate 模式尤其要看含字預覽。光核准一張漂亮底圖，還不知道文字疊上去會不會擠。 不滿意時，這樣改不要只說： 再漂亮一點。 改成： 12345678910請只修改第 3 頁樣張：保留目前配色、左右比較結構與標題文字。右側插畫縮小一些，增加文字留白。移除右下角與教學內容無關的裝飾。標題提高可讀性，但不要超過安全邊界。整體更像成人工作坊教材，不要增加可愛玩偶。請輸出 v02，保留 v01，不要改其他頁。 真正看過、同意之後，再鎖定樣張12345678910111213我已檢視並核准第 3 頁這個版本的底圖與完整版面。請先確認實際檔案存在。保留原始版本，將核准底圖另存為：slides/images/page_03.png將 design_system.style_reference指向這張真實存在的無字底圖。把這次核准與檔案路徑記錄到 qa/approval-log.md。後續頁面參考配色、材質與插畫語言，但不要全部複製第 3 頁的左右比較版型。 這段核准提示詞，要在你真的看過圖片之後才貼。 七、階段 5：分批生成，不要一次賭完整份樣張通過後，我建議先做第 4、5 頁。 因為這兩頁分別是「流程」與「四格分類」，剛好能測試： 同一套風格，換成其他版型之後是否仍然成立？ 原專案預設循序生成；只有使用者明確要求，而且環境允許時，才使用多代理平行生圖。第一次練習不需要先開平行模式。 貼給 Codex：試批生成提示詞1234567891011121314151617181920212223242526272829303132333435使用 $yaml-image-deck。沿用已核准的：prompt/spec.yamlprompt/overlay-plan.yaml第 3 頁黃金樣張底圖。請先確認參考圖片實際存在並讀取。需要把它提供給生圖工具作為參考時，請實際提供；不能只在文字裡寫路徑，就宣稱已參考圖片。這次只生成第 4、5 頁，一頁一次呼叫。要求：- 維持共同配色、材質與插畫語言。- 第 4 頁採流程版型，第 5 頁採四格分類。- 不要把每一頁都做成左右比較。- 底圖不生成任何文字。- 不修改已核准的上版文字。每頁都要保存：- 實際使用的生圖提示詞。- 原始底圖。- 用於組裝的最終底圖。- 疊上原生文字後的完整頁面預覽。記錄實際圖片尺寸。若不是 16:9，只能在不損失重要內容的前提下裁切或補邊；不要硬拉伸。檢查物件數量、留白、風格與文字區。失敗時只重做有問題的頁面。本次每頁最多重試 2 次，仍不合格就回報問題。完成兩頁後停下，先讓我檢查。 「每頁最多重試兩次」是這篇教學的成本控制建議，不是原專案的限制。 第 4、5 頁也通過後，再貼： 試批通過。請沿用相同規格完成第 1、2、6、7、8 頁，不重做已核准的第 3、4、5 頁。 額度不足怎麼辦？保存已完成頁面、規格與待辦即可，不要為了湊完頁數，偷偷改成另一種製作方式。 例如可以要求： 生圖額度不足時，請保留成果並列出缺頁。不要自行改用付費 API，也不要把程式畫出的替代插畫宣稱成原定的 AI 生圖成果。 八、階段 6：組裝 PPTX，並檢查「真正交付的檔案」這個階段最容易出現一種誤會： 原始圖片看起來正常，所以 PPTX 一定正常。 但你最後拿去上課的是 PPTX，因此要檢查的是匯出後的 PPTX 渲染結果。 原專案的驗收流程包含：檢查圖片、組裝 PPTX、重新渲染，再檢查整份總覽與溢出問題。 先看懂兩個檢查腳本的能力範圍 腳本 主要檢查什麼 不能因此保證什麼 validate_spec.py 必要欄位、頁碼、頁數、支援的版型等 教學內容正確、排版好看 verify_images.py 預期圖片存在、比例接近 16:9 沒錯字、沒遮擋、符合樣張風格 所以，VALID 不等於「可以直接交付」。這是根據 validate_spec.py 與 verify_images.py 的檢查範圍所做的區分。 貼給 Codex：組裝與驗收提示詞1234567891011121314151617181920212223242526272829303132333435363738394041424344454647請進行 PPTX 組裝與驗收。先確認 8 頁素材與上版文字都齊全，不要把缺頁或未核准頁當成完成。請執行：- validate_spec.py- verify_images.py把實際命令、輸出與退出碼保存到 qa/。使用目前環境實際可用的簡報製作工具，輸出：output/ai-social-post_v01.pptx本次是 plate 模式：- 每頁放入 AI 生成的無字底圖。- 標題、標籤、重點與頁碼使用原生可編輯文字。- 精確流程箭頭需要時使用原生物件。- 不准把整張含字預覽貼進 PPTX 冒充文字可編輯。文字依核准大綱，不自行改寫。加入講者備註與來源。保留可重新執行的組裝程式碼或指令。完成後，重新渲染這份匯出的 PPTX。逐頁檢查：- 頁數與順序。- 缺字與異常換行。- 文字遮擋與超出邊界。- 圖片是否被拉伸。- 文字區是否清楚。- 整份風格是否一致。建立完整總覽圖：slides/previews/contact-sheet_v01.png建立：qa/QA_REPORT.md報告分開記錄：1. 腳本檢查結果。2. 匯出 PPTX 的渲染檢查。3. 尚待人工確認的項目。沒有執行的檢查寫「未驗證」，不要寫 PASS。不要自行提交或推送 Git。 你最後要親手做的一個測試用你上課實際使用的軟體開啟 PPTX，點選一段文字，試著修改。 這能直接確認：你拿到的到底是原生文字方塊，還是一張把文字畫死的圖片。 同時切到播放模式，看一下標題、字型、換行與順序。若只在 Keynote 檢查過，就記錄為 Keynote 檢查，不要把它當成已完成 PowerPoint 原生驗收。 九、階段 7：修改時，先判斷「要不要重新生圖」這是選擇 plate 的主要好處。 你要改什麼？ 建議做法 標題、錯字、句子 修改原生文字，不生圖 字級、文字位置 調整文字層，不一定需要生圖 講者備註 修改備註，不生圖 插畫物件、場景、構圖 只修改或重生該頁底圖 整份視覺風格 先做新樣張，再決定哪些頁要重做 貼給 Codex：只改文字的提示詞12345678910111213141516171819以 output/ai-social-post_v01.pptx 為基準，建立 v02，保留 v01。只把第 3 頁標題改成：「先給資訊，再請 AI 寫」其他文字、所有底圖與頁面順序都保持不變。這次不呼叫生圖工具。請同步更新：- prompt/outline.md- prompt/spec.yaml- prompt/overlay-plan.yaml重建 PPTX 後，重新渲染第 3 頁，檢查換行、字級與重疊。確認其他頁面沒有非預期差異，將修改內容與驗證結果記錄到 qa/。 還有一個很容易忽略的問題假設你後來自己在 PowerPoint 改了標題，但沒有更新 YAML，下次 Codex 重新組裝，就可能使用舊文字。 因此，重建之前最好加一句： 我可能在 PowerPoint 手動修改過內容。請先比對 PPTX 與 YAML，列出差異，不要直接用舊規格覆蓋我的修改。 重點不是所有修改都要經過 AI，而是最後要留下能夠重做同一份成果的規格。 十、常見卡關，直接這樣處理 卡住的情況 你可以怎麼說 Codex 找不到 Skill 「請回報實際安裝路徑，確認 .agents/skills/yaml-image-deck/SKILL.md 存在；不要反覆安裝。」 一開始就要求 API 金鑰 「先確認是否能用內建生圖；本次未授權改用 API 計費。」 每頁都長得差不多 「參考的是風格，不是同一版型。請依比較、流程、分類重新分派。」 plate 底圖出現亂碼 「底圖不得生成任何文字或偽文字，所有文字由原生文字層處理。」 圖片漂亮，但字放不下 「先調整文字區與內容密度，不要只把字縮小。」 Codex 說完成，卻沒有 PPTX 「請列出實際存在的交付檔案；圖片完成不等於簡報組裝完成。」 十一、你已經有 Codex 簡報流程，應該怎麼接進去？不必把原本的流程全部丟掉。 我建議把 YAML Image Deck 加在「需要 AI 視覺的部分」。 例如，你原本已經有內容大綱、講者備註、精確流程圖，以及可編輯的表格，就保留這些成果。先選封面、觀念比較頁、案例情境頁來測試這個 Skill。 當視覺流程穩定後，再逐步擴大範圍。 對長期備課來說，我更建議分清楚兩類檔案： **可以重用的：**配色、字體方向、版型規則、已核准的風格樣張。 **每次課程要換的：**受眾、教學目標、案例、逐頁內容、講者備註。 這樣你下一次不是從零開始，而是： 沿用同一套視覺規則，換成適合新受眾的教學內容。 練習素材包我把這次範例整理成可以直接放進 Codex 專案的檔案： 下載 YAML Image Deck｜Codex 練習素材包（ZIP） 包含需求表、視覺方向、虛構教材、8 頁大綱草稿、完整範例 YAML，以及各階段提示詞。 依素材包所附 qa/EXAMPLE_VALIDATION.md 的紀錄，8 頁 YAML 曾通過原專案 validate_spec.py 的結構檢查（紀錄日期：2026-10-11）；這是素材提供時的驗證紀錄，不代表圖片與 PPTX 已經完成，也不代表讀者目前環境已通過驗證。素材包沒有代你安裝 Skill，也沒有預先生成圖片或簡報。 開始時只做一件事：解壓縮，用 Codex App 開啟資料夾，貼上「階段 0」提示詞。 整個流程最重要的不是一次講出完美提示詞，而是： 內容先確認，樣張先確認，再讓 Codex 批次製作；修改時只動需要變更的部分。 延伸閱讀 Claude Skill 可以用在 Codex 嗎？Agent Skills 遷移指南：理解哪些工作方法可以共用、哪些平台設定需要調整。 Codex Skills 與 Plugins 的使用觀念：釐清專案技能與插件的分工。 常見問答 (FAQ)Q1：不會 YAML，也能用 Codex 製作這份簡報嗎？可以。先提供簡報需求、可靠內容與視覺方向，再讓 Codex 整理大綱與 YAML 規格。你主要確認教學順序、上版文字與含字樣張，不必從零手寫 YAML。 Q2：baked 和 plate 模式差在哪裡？baked 把文字與圖像一起生成在圖片中；plate 先生成無字底圖，再由簡報工具疊上原生文字。需要經常修改的教材適合 plate，但底圖中的插畫仍是圖片，不能因此當成可拆解的 PowerPoint 圖形。 Q3：安裝 YAML Image Deck 後，就能直接輸出 PPTX 嗎？不能只靠安裝 Skill 或寫好 YAML 就保證輸出。還需要實際可呼叫的生圖工具、PPTX 組裝工具、字型與渲染工具；plate 模式另外需要文字位置與字級的組裝規格。開始前應確認各工具是否可用。 Q4：為什麼要先核准黃金樣張，再生成其他頁？黃金樣張用來確認配色、插畫材質與文字留白。先檢視無字底圖和疊上文字的完整投影片，通過後再測試其他版型，有助於提早發現風格或內容密度問題，避免整份重做。 Q5：素材包通過 VALID，是否代表簡報已經完成？不是。素材包所附紀錄只表示範例 YAML 曾通過結構檢查；沒有附上已生成圖片或完成的 PPTX。實際製作仍需檢查圖片、組裝 PPTX、重新渲染，並在上課使用的軟體中確認文字可編輯、字型與換行正常。

  • article-不會剪片也能做 MG 動畫：用 Codex、Claude、Canvas 與 FFmpeg 從零入門

    2026/10/9

    AI工具 Codex 影音行銷
    不會剪片也能做 MG 動畫：用 Codex、Claude、Canvas 與 FFmpeg 從零入門

    以前要做一支漂亮的動態圖形影片，可能得學 After Effects、研究關鍵影格、調整動畫曲線，甚至還要懂一點 3D。 現在還有另一種做法：讓 AI Coding Agent 撰寫動畫程式，由瀏覽器繪製畫面，再用影片工具輸出 MP4。 Claude Code 或 Codex 可以協助規劃畫面、修改程式和執行工具；實際渲染仍由瀏覽器與 FFmpeg 等工具完成。能不能自動跑完整流程，取決於你的專案、工具安裝與權限設定。最後也要自己播放影片，確認畫面和聲音。 更有趣的是，同一套動畫技術也能拿來做網站首頁、互動式教學頁面、產品展示和動態資訊圖表。 這篇文章會從完全零基礎開始，一步一步帶大家了解： MG 動畫是什麼？與 AI 生成影片有什麼不同？ 需要準備哪些工具？哪些可以免費使用？ 如何利用 Claude 製作第一個動畫作品？ 如何讓 Codex 或 Claude Code 自動產出 MP4？ 如何加入旁白、音效與自動品質檢查？ 同一套技術怎麼用在網站、課程和商業行銷？ 常見專業名詞究竟代表什麼？ 整篇文章的目標不是讓你成為動畫工程師，而是讓你學會指揮 AI 完成一個真正能交付的作品。 如果你想先看 AI Agent 如何串起完整影片工作流，可接著讀Claude Opus 5.5 影片工作流解析；若想從作品反推動畫提示詞，則可參考Claude 程式碼動畫與 Motion Design Skill。本文聚焦在實際搭建、逐格輸出與互動網站。 一、什麼是 MG？為什麼現在 AI 可以做？MG 是 Motion Graphics 的縮寫，中文通常稱為「動態圖形」。 它不是一般拍攝的影片，而是利用文字、幾何圖形、線條、數字、圖示與動畫效果，呈現內容或傳達資訊。 例如： 一個 Logo 從粒子聚合成形、一句標語隨著音樂節奏跳出、複雜的 AI 工作流程逐步展開，或是網站首頁充滿科技感的動態背景。 這些都屬於 MG 的常見應用。 與 AI 生成影片有什麼差別？一般的 AI 生成影片，例如利用文字提示詞生成寫實人物、風景或電影場景，核心是由 AI 模型直接生成影像。 MG 的程式化製作則是另一條路線。 我們讓 AI 撰寫 JavaScript、Canvas、SVG 或 Three.js 程式碼，再交給瀏覽器繪製動畫。 比較項目 一般 AI 生成影片 程式化 MG 動畫 生成方式 AI 直接生成影像 AI 寫程式，由瀏覽器繪圖 文字正確性 依模型能力，可能出錯 可以精確指定文字 修改品牌顏色 有時需要重新生成 可直接修改色碼 動畫時間 取決於模型控制能力 可精準到影格 角色寫實度 通常較有優勢 不擅長複雜寫實人物 重複製作 可能每次結果不同 可重複產生一致畫面 最適合 人物、情境、電影感 資訊動畫、品牌、產品介紹 所以，並不是 MG 一定比 AI 影片好，而是兩者擅長的事情不同。 想拍一隻狐狸在雪地奔跑，通常適合影像生成模型；想用漂亮的動畫講解 RAG、AI Agent 或行銷流程，就非常適合 MG。 二、一句提示詞，就能讓 AI 展現動畫能力？這次看到一個很有意思的示範。 它的提示詞大意是： 製作一段充滿動感的 15 秒 Motion Graphics 影片，展現你身為頂尖動態設計師的實力，就像求職作品集中的 Showreel。全力以赴。 Showreel 指的是設計師或動畫師用來展示自己能力的精華作品集。 這種提示詞的巧妙之處，不是指定每個特效，而是直接告訴 AI： 「我要看到你最好的動態設計作品。」 AI 就可能自行規劃動態文字、幾何變形、粒子特效、轉場以及視覺節奏。 相關示範可參考這個 Claude Artifact 動畫作品。 如果開啟時要求登入，或無法檢視程式碼，仍可依照下面的方法製作自己的版本。 第一個實驗：直接讓 Claude 做動畫前往 Claude，開啟新的對話。 貼上以下提示詞： 提示詞 A：15 秒 MG 作品集 12345678910111213141516171819202122232425你是一位世界級 Motion Graphics 動態設計師。請製作一段充滿動感的 15 秒 MG 動畫，如同專業動態設計師求職時展示的 Showreel。動畫必須包含：1. Kinetic Typography 動態文字2. Geometric Morphing 幾何變形3. 流暢且富有節奏感的轉場4. 具有空間感的動態構圖5. 強烈且一致的視覺風格6. 令人印象深刻的結尾畫面比例 16:9。請使用 HTML、CSS、SVG、Canvas或適合的 JavaScript 動畫技術製作。優先產生可以在瀏覽器預覽的動畫。請注意：此階段的目標是確認動畫創意，不必假裝已經完成 MP4 匯出。請發揮你的最佳動態設計能力。 如果 Claude 產生可以預覽的 Artifact，就先播放，看看作品的視覺表現。 這時候不必急著追求完美。 我們先學會一件事： AI 可以把文字描述變成真正會動的網頁。 截至 2026 年 10 月，Claude Motion 仍是 Beta 範本，官方說明列在 Team 與 Enterprise 方案，並支援將動畫匯出成 MP4；一般互動式 Artifact 或 HTML／JavaScript 程式碼，不代表一定有相同的 MP4 匯出功能。方案與功能會調整，使用前請查看Claude Artifacts 官方說明。 三、真正的重點：怎麼把網頁動畫變成 MP4？剛剛我們做的是「網頁動畫」。 它可以播放，但如果想上傳 YouTube、Facebook、Instagram，通常還是需要 MP4 影片。 這時就要認識整個流程中最重要的五個階段。 提出需求 → 編寫動畫 → 渲染合成 → 檢查改進 → 匯出 MP4 這裡會用到三個非常重要的工具。 工具 白話解釋 負責工作 Canvas 瀏覽器裡的一張數位畫布 繪製每一個動畫畫面 Playwright 能自動操作瀏覽器的工具 控制動畫時間並擷取影格 FFmpeg 影音處理工具 把影格和聲音合成影片 可以把整個過程想像成拍動畫片。 Canvas 是畫師，負責把每一格畫面畫出來。 Playwright 是攝影師，負責把每一格拍下來。 FFmpeg 是剪輯輸出師，負責把所有照片變成影片，再加入聲音。 例如我們要做 30 秒、每秒 30 格的影片，就需要： 30 × 30 = 900 個影格。 程式可以產生這 900 張畫面，再由 FFmpeg 合成 30 秒影片。 但要注意，正式渲染時應該讓每一格的畫面由固定時間決定，而不是靠電腦即時播放 30 秒再錄影。 這樣即使電腦運算速度不同，也不容易造成動畫長度與節奏不一致。 四、開始實作！先準備工具這裡以 Mac 為主要示範環境，Windows 也可以操作。 我們需要準備四項工具。 工具 做什麼 官方網址 Claude Code 或 Codex 幫忙寫動畫程式碼 Claude Code／Codex Node.js 讓電腦執行 JavaScript 工具 nodejs.org Playwright 控制瀏覽器、擷取畫面 playwright.dev FFmpeg 合成 MP4 與音訊 ffmpeg.org 如果已經安裝 Codex 或 Claude Code，就不用重新安裝。 步驟 1：安裝 Node.js前往 Node.js 官方網站： https://nodejs.org/en/download 新手建議使用 LTS 長期支援版本。 下載適合自己作業系統的安裝程式，依照指示完成。 安裝完畢後打開「終端機」。 Mac 可使用 Terminal，Windows 可以使用 PowerShell。 輸入： 12node -vnpm -v 如果分別顯示版本號碼，代表安裝成功。 npm 是 Node.js 的套件管理工具，接下來會用它安裝 Playwright。 步驟 2：安裝 FFmpegMac 如果已經安裝 Homebrew，可以輸入： 1brew install ffmpeg 如果沒有 Homebrew，先到 https://brew.sh/ 查看官方安裝方式。 Windows 使用者可從 FFmpeg 官方下載頁 選擇適合自己的 Windows build。不同發行版本可能包含不同編碼器；安裝後確認 ffmpeg 和 ffprobe 都能在終端機呼叫。 安裝完成後，重新開啟終端機並輸入： 12ffmpeg -versionffprobe -version 如果看到版本資訊，就代表 FFmpeg 可以正常使用。 步驟 3：建立第一個動畫專案在 Mac 的終端機輸入： 123456mkdir -p ~/Desktop/mg-studio/agent-explainercd ~/Desktop/mg-studio/agent-explainernpm init -ynpm install --save-dev playwrightnpx playwright install chromium 這幾行指令的意思是： 建立一個新的動畫工作資料夾。 進入資料夾。 初始化 Node.js 專案。 安裝 Playwright。 安裝 Playwright 使用的 Chromium 瀏覽器。 Windows 不需要照抄 Mac 的資料夾路徑，可以先在桌面建立 mg-studio 資料夾，再用 Codex 或編輯器開啟。 現在我們已經準備好讓 AI 開始製作動畫了。 五、第一支作品：用 MG 講解什麼是 AI Agent第一次不建議直接做 30 秒。 因為動畫每增加一秒，就需要更多影格和渲染時間。 我會先做 5 秒、1280 × 720 的短版測試，確定流程通了，再擴充到 30 秒、1920 × 1080。 這次選擇的主題是： 「AI Agent 就像你的數位員工。」 我們希望觀眾看到三個畫面： 時間 畫面 想表達的概念 0–1.5 秒 AI Agent 標題進場 吸引注意 1.5–3.5 秒 AI 接收任務、執行任務 自動化工作 3.5–5 秒 三個工作節點連線 展示多步驟流程 步驟 4：開啟 Codex 或 Claude Code在 AI Coding 工具中，開啟剛剛建立的專案資料夾。 貼上以下提示詞。 提示詞 B：建立第一個可播放的 MG 動畫 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354你是一位 Motion Graphics 動態設計師，也是熟悉 JavaScript Canvas 的前端工程師。請在目前專案資料夾內，幫我製作第一支 MG 知識講解動畫。【主題】什麼是 AI Agent？核心比喻：AI Agent 就像數位員工，能接收任務並執行多個工作步驟。【第一階段規格】影片長度：5 秒畫面大小：1280 × 720比例：16:9影格率：30 FPS語言：正體中文【分鏡】0–1.5 秒：顯示大標題「什麼是 AI Agent？」使用動態文字和幾何圖形進場。1.5–3.5 秒：展示使用者將任務交給 AI Agent，再由 Agent 自動執行的流程。3.5–5 秒：畫面展開「理解 → 執行 → 回報」三個工作節點，最後收尾。【技術規範】1. 使用 JavaScript + HTML Canvas。2. 建立 index.html 和動畫程式碼。3. 必須可以在瀏覽器中預覽。4. 提供 window.renderFrame(frame) 函式。5. 每個影格都依 frame / fps 計算畫面。6. 不得依賴 requestAnimationFrame 的實際執行速度決定輸出畫面。7. 動畫使用固定亂數種子。8. 所有字體必須支援正體中文。9. 文字不可超出安全區域。10. 所有動畫必須可重複產生相同結果。【視覺風格】高級科技感、深色背景、藍紫色強調、簡潔文字、流暢但不過度花俏。請先完成可以預覽的動畫，並告訴我如何在本機開啟。目前先不要加入音訊，也不要直接製作 30 秒完整版。 這個提示詞最重要的地方，其實不是視覺設計，而是： window.renderFrame(frame) 這個函式代表我們可以要求動畫跳到指定影格。 例如第 0 格、第 30 格、第 90 格。 這是後面能夠穩定渲染 MP4 的基礎。 步驟 5：預覽動畫讓 Codex 完成程式碼後，可以請它啟動本機預覽伺服器。 也可以在專案目錄執行： 1python3 -m http.server 3000 --bind 127.0.0.1 開啟瀏覽器進入： http://127.0.0.1:3000 如果看到會動的動畫，代表第一階段完成。 如果沒有看到動畫，不必急著重新建立專案。直接告訴 Codex： 1234567891011請檢查目前動畫為什麼無法正常顯示。請自行檢查：1. 瀏覽器 Console 錯誤2. Canvas 是否正確初始化3. 動畫是否正常播放4. 中文字體是否正常5. 本機伺服器是否啟動修正後重新預覽，不要只修改程式碼就宣稱完成。 六、讓 AI 把動畫輸出成 MP4現在動畫已經可以在網站播放了。 接下來要做最重要的一件事： 讓 Playwright 一格一格擷取畫面，再讓 FFmpeg 合成影片。 步驟 6：要求 AI 建立自動渲染程式提示詞 C：Playwright + FFmpeg 自動匯出 123456789101112131415161718192021222324252627282930313233343536373839404142目前專案已有可播放的 Canvas 動畫。請建立完整的 MP4 輸出流程。【渲染要求】使用 Playwright 控制 Chromium，呼叫 window.renderFrame(frame)產生每個指定影格。請建立 render.mjs，讓它完成：1. 啟動或連接本機預覽頁面。2. 等待字體和素材載入完成。3. 逐格呼叫 renderFrame(frame)。4. 將 Canvas 擷取成 PNG。5. 存放至 frames/ 資料夾。6. 使用連續影格檔名。7. 發生錯誤時停止並回報。【影片規格】5 秒1280 × 72030 FPS總共 150 個影格【輸出】使用 FFmpeg 編碼成 H.264 MP4。輸出路徑：out/agent-intro-5s.mp4【驗收】必須實際確認：- PNG 影格數量正確- MP4 可以播放- 影片長度正確- 解析度正確- 無明顯黑格- 沒有文字被裁切請提供我可直接執行的指令。不要只產生程式碼而不驗證。 如果 AI 依照要求建立了 render.mjs，通常就可以執行： 1node render.mjs 但要以 AI 實際建立的檔案與執行說明為準。 有些專案需要先保持本機伺服器執行，有些則會由渲染腳本自行啟動伺服器。 如果採用逐幀 PNG 的方式，FFmpeg 合成影片的基本指令如下。這裡假設你的 FFmpeg build 包含 libx264；若指令回報找不到 encoder，請使用包含該編碼器的 FFmpeg build。 1234567ffmpeg -y \ -framerate 30 \ -i frames/frame_%05d.png \ -c:v libx264 \ -pix_fmt yuv420p \ -movflags +faststart \ out/agent-intro-5s.mp4 這裡的 %05d 代表五位數的連續編號，例如 frame_00000.png。 如果你的 AI 使用其他檔名，記得請它同步調整指令。 完成後，應該可以在 out 資料夾找到第一支 MP4。 恭喜！如果真的可以正常播放，你就已經完成一次從程式碼到影片的製作流程。 七、從 5 秒升級成 30 秒知識講解影片現在不要重新建立專案。 只需要讓 Codex 延伸既有動畫即可。 這次我們把內容變得更完整。 時間 主題 動畫內容 0–4 秒 開場 Hook AI Agent 是什麼？ 4–9 秒 傳統 AI 人問一次，AI 回答一次 9–15 秒 AI Agent 接收目標，自行規劃步驟 15–22 秒 實際案例 收集資料、整理、回報 22–27 秒 比較 Chatbot 與 Agent 差別 27–30 秒 結尾 AI Agent = 數位工作夥伴 提示詞 D：擴充成 30 秒完整版 1234567891011121314151617181920212223242526272829303132請以目前已驗證成功的 5 秒動畫專案為基礎，擴充為完整 30 秒 MG 知識講解影片。主題：什麼是 AI Agent？規格：- 1920 × 1080- 16:9- 30 FPS- 共 900 個影格- 正體中文- H.264 MP4請依照以下分鏡製作：0–4 秒：提出問題4–9 秒：傳統 AI 對話模式9–15 秒：AI Agent 自主規劃15–22 秒：三步驟任務示範22–27 秒：Chatbot 與 Agent 比較27–30 秒：核心概念與結尾請保持：1. 視覺設計一致2. 每個場景有明確資訊重點3. 文字有足夠閱讀時間4. 動畫轉場流暢5. 畫面不得裁切6. 所有影格可以獨立渲染先完成動畫與無聲 MP4。確認正常後，再進行音訊階段。 我特別建議「先做無聲版本」。 因為動畫、音樂、旁白同時出問題時，新手很難知道該從哪裡修正。 分階段完成，成功率反而比較高。 八、進階：加入旁白與音樂動畫完成後，接下來可以讓它變成真正的知識講解短片。 這裡有兩種方式。 方法 A：沒有旁白，只有配樂適合品牌影片、科技產品展示、視覺 Showreel。 可以請 AI 使用 Web Audio API 或程式化音效生成方式，製作簡單的背景節奏，再透過 FFmpeg 合成。 提示詞 E：加入程式化配樂 1234567891011121314151617請為目前的 30 秒 MG 動畫加入配樂。音樂風格：現代科技感、電子節奏、簡潔俐落。請優先使用可合法使用的原創音效，可利用程式碼合成音訊。要求：1. 配樂長度與影片一致。2. 場景切換盡量對齊音樂節拍。3. 主要轉場可加入簡潔音效。4. 音量不能過大。5. 開頭與結尾避免突兀切斷。6. 輸出合成後的 MP4。請保留無聲版本作為備份。 這種做法通常不需要購買商業音樂素材，但程式生成的聲音品質仍需要實際聆聽。 方法 B：加入 AI 旁白或真人旁白如果要做知識教學影片，我會更推薦旁白版本。 先用自己的聲音錄製，或利用授權合適的文字轉語音服務產生旁白。 把音訊檔命名成： voice.mp3 放進專案的 assets 資料夾。 接著讓 AI 進行語音轉文字，並取得時間資訊。 這裡要認識 Whisper 與 WhisperX。 工具 用途 Whisper 語音辨識，取得逐字稿與時間區段 WhisperX 結合時間對齊模型，提供更細的詞級時間資訊 Forced Alignment 將已知文字與音訊時間位置進行對齊 Whisper 原始輸出主要以語音片段時間為主；如果需要逐詞同步，可評估 WhisperX 或其他強制對齊工具。WhisperX 需要相應語言的對齊模型；中文及臺灣華語的可用模型與結果都要先確認，辨識和對齊結果仍需人工檢查。 提示詞 F：讓動畫跟著旁白同步 123456789101112131415161718192021222324專案 assets/voice.mp3 是正式旁白音訊。請將它與 30 秒 MG 動畫整合。工作流程：1. 使用合適的語音辨識工具取得逐字稿。2. 取得句子與重要詞語的時間資訊。3. 需要精細同步時，使用適合中文的 Forced Alignment 工具。4. 將旁白時間對應動畫場景。5. 調整文字、圖形及重點動畫出現時間。6. 保持旁白與畫面語意一致。7. 合成旁白、背景音樂與 MP4。如果旁白長度不是 30 秒，請先回報並提出調整建議，不要自行裁切重要內容。如對齊結果不精準，請標記需要人工確認的段落。完成後檢查音訊有無缺失、爆音與音量失衡問題。 這也是為什麼我們需要前面提到的固定時間軸。 因為有了絕對時間，就可以在旁白說到某句話時，精準顯示對應圖形。 九、影片做完還不夠！要讓 AI 自己檢查品質這次教學最讓我感興趣的，其實是它的檢查循環。 抽取關鍵影格 → 查看拼圖 → 修正問題 → 重新渲染 這個流程可以降低 AI 宣稱完成、實際影片卻有問題的機率。 什麼是 Contact Sheet？Contact Sheet 就是把不同時間點的影片影格，排列成一張圖片。 原本要看完 30 秒影片才能檢查畫面，現在一張圖就可以快速看到整體分鏡、構圖和視覺一致性。 例如我們要每五秒擷取一格，可使用： 12345ffmpeg -y \ -i out/agent-explainer-30s.mp4 \ -vf "fps=1/5,scale=480:-1,tile=3x2" \ -frames:v 1 \ out/contact-sheet.png 以上假設影片檔已經正確產生，而且輸出資料夾存在。 如果要檢查轉場，還應該多擷取轉場前後的畫面，而不只是每五秒一張。 提示詞 G：讓 AI 自動驗收12345678910111213141516171819202122232425262728293031323334353637383940請對最終 MG 影片執行完整 QA。QA 工作包括：1. 使用 FFprobe 檢查影片： - 解析度 - FPS - 實際長度 - 音訊是否存在2. 使用 FFmpeg 製作 Contact Sheet。3. 針對每個場景轉場， 額外擷取前後影格。4. 檢查： - 文字是否裁切 - 中文字是否缺字 - 是否有黑格 - 是否有畫面閃爍 - 是否有元素重疊 - 音訊與畫面是否同步 - 結尾是否完整5. 將問題分級： P0：無法交付 P1：明顯品質問題 P2：可改進項目6. 自動修正可以明確判斷的問題。7. 修正後重新渲染並重新檢查。8. 輸出 qa-report.md。請不要只根據程式執行成功就判定影片通過驗收。視覺與節奏等主觀項目，請保留人工審片狀態。 我會建議把這個提示詞保留下來，未來每次製作影片都使用。 因為真正商業化的差異，不只是 AI 能不能做出影片，而是能不能持續做出品質穩定的影片。 十、除了製作影片，還能拿來做網站？這裡就是我認為 MG 很值得延伸的地方。 如果已經有一套 JavaScript 動畫，不一定要全部轉成 MP4；同一組圖形、文字與動態概念，也能成為網站的一部分。 但要記得，Canvas 本身是點陣畫布，畫在裡面的文字和圖形不會自動成為螢幕閱讀器可讀的語意內容。網站的重要標題、說明與操作控制應使用 HTML 元素，並提供動畫暫停、重播和減少動態效果等選項。 不過要先區分三種用途。 應用 建議方式 特點 網站純裝飾動畫 CSS／SVG／GSAP 載入相對輕量，易控制 複雜互動式動畫 Canvas／Three.js 可跟隨滑鼠、點擊或捲動 固定的影片展示 MP4／WebM 結果穩定、容易嵌入 案例一：企業官網的科技感首頁假設我們正在做一家 AI 顧問公司的網站。 一般首頁可能只有一張大圖，加上標題和服務介紹。 如果改用 MG，就可以讓首頁出現： 粒子聚合成品牌 Logo。 服務項目隨動畫展開。 AI、資料、自動化三個節點彼此連結。 使用者往下捲動時，流程逐步展開。 點選服務時，動畫切換對應內容。 這就不再只是看影片，而是變成真正可以互動的網站。 提示詞 H：建立 MG 動態首頁 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647你是一位 Creative Frontend Developer，擅長 Motion Graphics、GSAP、Canvas 和互動式網站設計。請幫我製作一個具有高級 MG 動畫效果的AI 顧問公司官方網站首頁。【網站目的】展示 AI 顧問公司的專業能力，並引導訪客預約諮詢。【網站內容】主標題：讓 AI 從工具，變成你的工作夥伴。副標題：AI 工作流、自動化行銷與企業應用。服務項目：1. AI 教育訓練2. AI 自動化工作流3. AI 行銷與內容製作【動態效果】- 首頁標題採用 Kinetic Typography- 背景具有科技感的粒子動畫- 服務項目使用 Scroll Animation- 工作流程使用動態節點連線- 按鈕具有精緻 Hover 效果【技術要求】可使用 HTML、CSS、JavaScript、GSAP、Canvas、SVG。請依照必要性選擇工具。【效能要求】1. 支援手機與桌面。2. 不得讓動畫阻塞頁面操作。3. 提供 prefers-reduced-motion 支援。4. 文字必須是真正可讀取的 HTML 內容。5. 不因動畫而犧牲基本 SEO 與無障礙性。6. 不要自動播放有聲音的內容。7. 動畫失敗時仍可正常瀏覽網站。請先製作首頁原型，完成後使用瀏覽器實際驗收。 這裡有一個很重要的觀念： 網站動畫應該服務內容，而不是讓內容變成動畫的陪襯。 如果每個元素都在跳動、旋轉，訪客可能連資訊都看不清楚。 所以真正專業的 MG 網站，還是要重視閱讀動線、速度與使用者體驗。 案例二：互動式教學網站想像我們要教學員理解「AI Agent 工作流程」。 一般簡報可能就是一張流程圖： 使用者 → AI Agent → 工具 → 結果 但如果用程式化動畫，可以讓學員點選每一個步驟。 例如點選「工具」，就展示 AI 如何呼叫搜尋工具；點選「結果」，就顯示任務回報。 這樣就不只是動畫，而是互動式教材。 提示詞 I：製作互動式 MG 教學網頁 12345678910111213141516171819202122232425262728293031323334請製作一個互動式教學網頁。主題：AI Agent 如何工作？教學對象：沒有程式背景的一般職場工作者。請設計四個步驟：1. 接收目標2. 規劃任務3. 呼叫工具4. 檢查結果每一個步驟都要有：- 動態圖形- 簡短白話說明- 真實工作案例- 下一步按鈕使用者可以：- 暫停動畫- 重播動畫- 切換步驟- 控制動畫進度- 回到上一個畫面請製作適合投影教學的桌面版，並支援手機操作。使用 HTML、CSS、JavaScript，必要時可以使用 GSAP 或 Canvas。請特別注意中文字體、畫面安全區域和可讀性。 做完之後，這個網站不只可以拿來上課，也能放到官網，成為公開的互動教材。 十一、MG 網站怎麼發布？Cloudflare 可以嗎？可以。 如果成品只是 HTML、CSS、JavaScript 與靜態素材，可以部署到 Cloudflare Pages 等靜態網站託管服務。 基本流程是： 請 Codex 整理可以獨立運作的網站輸出資料夾。 確認裡面有 index.html 和必要素材。 在 Cloudflare 開啟 Workers & Pages。 使用 Direct Upload 或 Git 整合進行部署。 部署後取得 pages.dev 網址並測試。 有需要再設定自己的網域。 選擇前先想好部署方式：Direct Upload 專案之後不能直接切換成 Git 整合；若希望每次 push 後自動建置與部署，建立專案時就選 Git 整合。詳情見 Cloudflare Pages Direct Upload 說明。 Cloudflare 官方文件： https://developers.cloudflare.com/pages/get-started/direct-upload/ 要特別注意： 部署網站動畫，不等於 Cloudflare 會自動替你渲染 MP4。 網站上的 Canvas 動畫可以由使用者的瀏覽器執行。 但若要在雲端大量產出 MP4，還需要額外規劃影片渲染環境，例如本機、CI 工作流程或專用渲染服務。 因此，新手最簡單的方式是： 本機製作影片 → 本機輸出 MP4 → 將完成的影片或網站素材部署到 Cloudflare。 不需要第一天就把整套影片工廠搬到雲端。 十二、進階工具：GSAP、Three.js、GLSL、Remotion 怎麼選？前面使用 Canvas，是為了讓大家先理解核心原理。 但實際開始製作更多作品後，就會發現不同動畫，適合不同工具。 工具 最適合做什麼 新手建議 CSS Animation 簡單淡入、移動、縮放 最容易開始 SVG Logo、圖示、線條動畫 適合品牌與教學 Canvas 粒子、幾何、資訊動畫 很適合這篇教學 GSAP 時間軸、緩動、捲動動畫 網站動畫值得學 Three.js 3D 物件、鏡頭、空間場景 有需要再使用 GLSL Shader、光影、液態與特殊材質 進階視覺效果 Remotion React 動畫、影片編排與輸出 適合規模化影片製作 如果目標是互動網站，通常先評估 CSS、SVG、GSAP，再視需求使用 Canvas 或 Three.js。 如果目標是大量產出可以下載的影片，我會優先評估 Remotion。 Remotion 是什麼？Remotion 是一套利用 React 程式碼製作影片的框架。 它可以讓每一個畫面依照影格編號產生，再輸出成正式影片。 也支援將文字、圖片、動畫、音訊組合成可以重複使用的影片元件。 而且官方提供 Agent Skills，讓 Claude Code、Codex 等 Coding Agent 在 Remotion 專案中參考官方慣例。安裝前仍要確認來源和版本，閱讀 Skill 的檔案與會執行的步驟，不要把任何第三方安裝器當成免檢查的捷徑。 如何開始使用 Remotion？先確認 Node.js 已安裝，再執行官方提供的專案初始化指令： 1234npx create-video@latest --yes --blank my-videocd my-videonpx remotion skills addnpm run dev 這個流程會建立新專案，並啟動 Remotion 的開發預覽介面。 如果要額外使用官方 Agent Skills，可參考： 1npx skills add remotion-dev/skills 官方說明： https://www.remotion.dev/docs/ai/skills 之後可以要求 Codex 使用 Remotion 建立具有固定解析度、影格率與長度的動畫。 例如： 123456789101112131415161718192021請使用目前 Remotion 專案，製作一支 30 秒正體中文 MG 教學短片。主題：什麼是 AI Agent？請採用可重複使用的 React 元件，使用固定影格時間控制動畫。包含：- 開場標題- 動態流程圖- 概念比較- 文字重點動畫- 結尾 CTA請先在 Remotion Studio 預覽，確認 Composition 正確，再輸出 H.264 MP4。請使用官方 Remotion Skills，並提供完成的檔案及 QA 報告。 截至 2026 年 10 月 9 日，Remotion 官方的免費授權適用於個人與符合條件的三人以下組織，商業用途仍須遵守官方條款；四人以上組織及自動化服務可能適用不同方案與費用。GSAP 的標準授權目前允許一般商業專案免費使用，但仍有使用範圍限制。正式使用前，請重新查看 Remotion 授權與價格及 GSAP 標準授權。 這條路線和前面的 Canvas + Playwright + FFmpeg 都可行。 但對初學者，我建議一次先學一條。 想理解網頁動畫原理，從 Canvas 開始；想建立大量影片生產流程，再研究 Remotion。 十三、五種最值得落地的商業應用學會這套技術後，我認為可以從以下幾種場景開始。 應用場景 實際作品 商業價值 AI 知識短影音 30 秒解釋 RAG、Agent 社群曝光、建立專業形象 課程動畫 教學開場、章節動畫 提升教材表現與重複使用性 企業官網 動態首頁、品牌視覺 增加品牌識別與互動 SaaS 產品介紹 功能流程、介面展示 讓客戶快速理解產品 電商與活動行銷 商品賣點、倒數、促銷動畫 大量生產不同版本素材 應用 A：AI 知識短影音工廠輸入：「什麼是 RAG？」 AI 自動把概念拆解成幾個畫面。 接著製作圖形、文字與動畫，最後輸出一支 30 秒短片。 當這套流程成熟，就可以更換主題，繼續製作： 什麼是 MCP？ 什麼是 AI Agent？ 什麼是 Vibe Coding？ 什麼是向量資料庫？ Chatbot 與 Agent 有何不同？ 其中動畫框架可以共用，改變的只有腳本、文字、圖示與內容。 應用 B：產品操作動畫例如製作 LINE 自動化行銷系統。 不一定要拍攝真實系統操作。 可以用 MG 呈現： 客戶加入 LINE → 填寫資料 → 系統建立名單 → AI 自動分類 → 發送通知。 這種動畫非常適合放在銷售頁，讓客戶快速理解一套複雜的系統。 如果要展示真實產品，記得使用正確的系統截圖與功能資訊，不要讓 AI 自行編造尚未存在的功能。 應用 C：品牌動態識別假設我們有固定的 Logo、色彩與品牌字型。 就可以將它們做成： 3 秒 Logo 片頭。 5 秒品牌結尾。 課程片頭動畫。 社群貼文動態版本。 網站首頁動畫。 未來只要更換標題與內容，就不必重新設計整套視覺。 應用 D：互動式教學頁面對教育訓練而言，這可能是最有潛力的用途。 因為同一個流程可以產出兩種成果： 第一種是固定時間的 MP4，拿來上傳社群、放進簡報。 第二種是可以點擊、暫停、拖曳、互動的網站，拿來實際教學。 同一份概念設計，變成影片與互動式教材，這才是內容資產的真正重複使用。 應用 E：大量客製化動畫假設我們要替十家企業製作品牌短片。 如果每支影片都從零開始，修改成本很高。 但如果先建立可參數化的動畫範本，就可以讓不同企業使用： 不同 Logo。 不同品牌顏色。 不同標語。 不同產品圖片。 不同 CTA。 不同影片尺寸。 這樣就能把動畫製作從「一次性的創作」，逐步變成「可重複的生產流程」。 十四、遇到問題先檢查哪裡？ 症狀 優先檢查 完全不會 JavaScript Coding Agent 可以代寫程式，但仍要會開啟資料夾、執行指令、預覽結果，並確認輸出檔真的存在。 動畫能在瀏覽器播放，MP4 卻是黑畫面 確認 Canvas 已完成初始化、字型和圖片已載入，Playwright 有呼叫指定影格函式，並檢查擷取的是正確的 Canvas。 輸出影片節奏不穩 讓每一格由影格編號或絕對時間計算，避免只依賴即時播放速度；確認輸入與輸出的 FPS 一致。 中文變成方塊 使用支援繁體中文的字型，並在擷取畫面前等待字型載入；檢查該字型是否真的安裝或能由頁面取得。 網站動畫無法互動或不易閱讀 將重要文字和控制項做成 HTML，加入暫停與減少動態效果，並以手機尺寸檢查版面。 想把網站放到 Cloudflare 靜態網站可以託管在 Pages；雲端大量渲染影片則要另備執行環境。建立 Pages 專案時也要先選 Direct Upload 或 Git 整合。 不確定實際費用 分開計算 Coding Agent 方案或 API、語音服務、運算時間、儲存空間與商業授權；工具可免費取得，不代表整體製作零成本。 想安裝 Animation Skill 優先查官方文件；安裝前讀取來源、版本、檔案存取與執行步驟，再決定是否採用。 十五、專業名詞懶人包下面把這篇用到的重要名詞整理成表格，之後忘記可以直接回來查。 專業名詞 中文說法 白話解釋 MG 動態圖形 讓文字、圖形和資訊動起來 Motion Graphics 動態圖形設計 MG 的英文全名 Showreel 作品精華集 設計師展示能力的短片 Kinetic Typography 動態文字排版 讓文字配合節奏移動與變化 Morphing 形狀變形 圓形逐漸變成方形等效果 Particle Animation 粒子動畫 利用大量小點組成動態效果 Easing 緩動曲線 控制動畫加速、減速的感覺 Timeline 時間軸 安排每個動畫何時出現 Keyframe 關鍵影格 動畫中特別指定的狀態或時間點 Frame 影格 影片中的單一畫面 FPS 每秒影格數 30 FPS 就是一秒 30 格 Render 渲染 把動畫資料轉換成實際畫面 Canvas 網頁繪圖畫布 使用 JavaScript 繪圖的技術 SVG 向量圖形 放大不容易失真的圖形格式 GSAP JavaScript 動畫函式庫 控制動畫與時間軸的工具 Three.js 3D 圖形函式庫 在網頁中製作 3D 場景 GLSL Shader 程式語言 控制 GPU 圖形與特效 Shader 著色器 計算材質、顏色、光影的程式 Playwright 瀏覽器自動化工具 自動操作瀏覽器與擷取畫面 FFmpeg 影音處理工具 影片編碼、轉檔、音訊合成 FFprobe 影音資訊檢查工具 查詢影片長度、編碼與解析度 Codec 編碼格式 將影像與聲音壓縮儲存的方法 H.264 影片編碼標準 常見且相容性高的影片格式 MP4 多媒體容器格式 常見的影片交付格式 Whisper 語音辨識模型 將語音轉成文字 WhisperX 語音辨識與對齊工具 用於更細緻的語音時間對齊 Forced Alignment 強制時間對齊 將文字與實際語音時間對應 Contact Sheet 關鍵影格拼圖 將多張影片截圖排列成一張 QA 品質驗收 檢查作品是否符合標準 CTA 行動呼籲 例如「立即預約」「了解更多」 Hero Section 網站首頁主視覺區 訪客進站時最先看到的大區塊 Scroll Animation 捲動動畫 隨著頁面捲動觸發動畫 Hover 滑鼠懸停狀態 游標移到元素上時的效果 Responsive Design 響應式設計 自動適應手機與電腦畫面 Remotion React 影片框架 利用程式碼編排與渲染影片 Composition 影片組合定義 指定影片內容、長度和解析度 Skills AI 工作技能指引 讓 AI 依特定規則執行工作的指引 十六、從做一支影片，到建立自己的 MG 影片工廠如果只想體驗 AI 動畫，可以停在 Claude Artifact。 如果想做社群短片，可以學會 Canvas、Playwright、FFmpeg。 如果想做互動網站，就可以繼續研究 GSAP、SVG 和 Three.js。 如果想長期、大量製作影片，則值得進一步研究 Remotion、參數化模板與自動品質驗收。 我會把整個學習過程分成四個階段： 階段 目標 應該完成的作品 Level 1 讓 AI 產生動畫 5–15 秒網頁動畫 Level 2 自動輸出影片 30 秒 MP4 知識短片 Level 3 重複使用動畫技術 網站首頁與互動教材 Level 4 建立生產流程 可替換內容的 MG 影片模板 當做到第四階段，真正重要的就不是這次用了哪一個模型。 而是已經擁有一套能夠持續使用的動畫製作方法。 例如先建立一套視覺規則，讓不同影片都能沿用同樣的字體、配色、鏡頭語言與轉場風格。 之後只要更換主題和旁白，就能用相近的品質持續產出新作品。 這也很適合延伸成線上課程、教材製作或品牌行銷的自動化工作流。 十七、我的最後建議：先完成一支影片，再開始追求特效很多人第一次看到 AI 做出的 MG，就會想立刻加入更多功能。 要 3D、要粒子、要液態金屬、要音樂、要自動旁白，最好還能一次做十支。 但對初學者而言，我反而建議先照著這個順序： 第一天： 完成 5 秒 Canvas 動畫，並確定可以在瀏覽器播放。 第二天： 使用 Playwright 與 FFmpeg，真的產生第一支 MP4。 第三天： 把內容延伸成 30 秒，加上旁白與品質檢查。 第四天： 把動畫改造成一個互動式網站，或製作第二支不同主題的短片。 四個階段完成後，才開始研究更複雜的動態設計和批量生成。 因為 AI Coding 最有價值的地方，不是把所有最新技術塞進同一個專案，而是把一個能運作的成果，慢慢變成可以重複使用的系統。 以前做影片，我們要學的是「怎麼把動畫做出來」。 現在多了一種可能： 我們可以先讓 AI 幫忙建立一套會做動畫的工具，再利用這套工具不斷產生新的作品。 這也許才是 AI 對影片製作流程更深遠的改變。 常見問答 (FAQ)Q1：完全不會 JavaScript，也能用 AI 做 MG 動畫嗎？可以先讓 Claude Code 或 Codex 協助撰寫動畫程式，但你仍需要建立專案、執行指令、預覽成品，並確認 MP4 的畫面、長度和聲音。AI 產生程式不等於成品已驗收。 Q2：Claude Artifact 會動，為什麼還要 Playwright 和 FFmpeg？互動式網頁動畫與影片檔是不同輸出。Claude Motion Beta 範本可依帳號方案直接匯出 MP4；若是一般 HTML／Canvas 動畫，就可以用 Playwright 固定影格、擷取 PNG，再由 FFmpeg 合成影片。 Q3：5 秒、30 FPS 的動畫需要幾格？需要 150 格，計算方式是秒數乘上每秒影格數。若從第 0 格開始編號，影格索引會是 0 到 149。 Q4：Remotion 可以免費用於商業專案嗎？官方目前對個人與符合條件的三人以下組織提供免費授權，商業使用仍受條款限制。組織規模或服務型態不同時，費用也可能不同；請在採用前查看官方最新授權頁。 Q5：可以把 MG 網站部署到 Cloudflare Pages，順便在雲端輸出影片嗎？Pages 可以部署靜態網站，但不會自動替網站執行大量影片渲染。要在雲端輸出影片，需要另外準備渲染服務或自動化執行環境。 參考資料與延伸閱讀以下整理這次研究與實作相關的公開資源。 原始示範與案例 Claude Artifact 動畫示範 Claude Opus 5.5 的 13 個動態影片案例與原始提示詞（Zenn） Claude Artifacts 官方使用說明（包含 Motion Beta 方案與 MP4 匯出說明） 動畫與影片製作技術 MDN：Canvas API Playwright 官方文件 FFmpeg 官方文件 GSAP 官方文件 Three.js 官方網站 Remotion 官方文件 Remotion Agent Skills 語音與網站部署 OpenAI Whisper WhisperX GitHub Cloudflare Pages Direct Upload 授權與成本 Remotion License & Pricing GSAP Standard License 本文於 2026 年 10 月 9 日依官方文件與公開案例整理。工具功能、方案、授權條件與免費額度都可能變動，正式商業使用前請再次確認。

  • article-Claude Skill 可以用在 Codex 嗎？Claude → Codex Agent Skills 遷移指南

    2026/10/2

    Vibe Coding Codex Claude
    Claude Skill 可以用在 Codex 嗎？Claude → Codex Agent Skills 遷移指南

    最近看到六角學院卡斯柏整理的「Claude Code Skill 設計風格圖鑑」，我第一個念頭是：這些設計方法都包成 Claude Skill 了，如果我平常主要用 Codex，還能不能拿來用？ 簡單說：**很多 Skill 的核心方法可以沿用，但不代表 Claude 與 Codex 的功能可以直接一鍵互換。**如果內容主要是設計規則、檢查清單和工作步驟，通常很容易搬；如果它仰賴特定工具權限、Hook、子代理或插件設定，就要逐項調整並實際驗證。 本文用卡斯柏的圖鑑當例子，整理如何把一份 Claude Skill 轉成 Codex 可發現、可執行，也方便持續維護的工作方法。 本文依 2026 年 10 月 2 日可查到的官方文件整理。Agent Skills 與 Codex 插件規格仍會演進；安裝或遷移前，請再核對當下文件與工具版本。 先分清楚 Skill 格式和執行平台Agent Skill 通常是一個資料夾，核心是 SKILL.md，可以再附上 references/、assets/ 和 scripts/。SKILL.md 描述何時使用這份 Skill，以及 Agent 要遵循的工作方法。這套目錄概念採用開放的 Agent Skills 標準，Claude Code 和 Codex 都有自己的 Skill 支援方式。 兩邊載入本機 Skill 的路徑不同。Claude Code 的專案 Skill 常放在 .claude/skills/<skill-name>/；Codex 則會從專案中的 .agents/skills/ 掃描。Codex 的官方文件也說明，這個目錄適合專案內使用；若要散布給其他人，則可把 Skill 包裝成 Plugin。 所以，看到兩邊都有 SKILL.md，可以先把它理解成「可攜的工作方法格式」，不要直接推論裡面的每個欄位、指令或執行行為都相容。 只有 SKILL.md 和參考資料時，怎麼搬？如果 Skill 的內容是設計原則、操作步驟、範例和檢查清單，通常可以先做小幅遷移： 讀完 SKILL.md，確認它要求 Agent 做什麼、何時啟用。 一併保留 Skill 用到的 references/、assets/ 和 scripts/。 複製到 Codex 專案的 .agents/skills/<skill-name>/。 把 Claude 專屬路徑、工具名稱和呼叫方式改成 Codex 可用的寫法。 在實際任務中明確呼叫一次，再檢查產出是否遵循 Skill 的規則。 例如，先確認目標資料夾不存在，再複製整個 Skill 資料夾： 12mkdir -p .agents/skillscp -R .claude/skills/<skill-name> .agents/skills/<skill-name> 若 Skill 原本就在個人目錄或某個插件裡，來源路徑要依實際位置調整。複製前先看過其中的腳本與外部依賴；不要只因為資料夾名稱叫 Skill，就直接執行裡面的程式。 以設計風格 Skill 為例，核心內容可能是字體層級、版面網格、留白、圖片運用、動態效果、響應式規則與反模式。這些方法通常不依賴特定模型，搬移後仍然有參考價值。 哪些 Claude 設定不能直接照搬？實際要花心力的地方，往往是 SKILL.md 的前置資料，以及文字背後預設的產品行為。 allowed-tools 不等於 Codex 的權限設定。 Agent Skills 標準將這個欄位列為實驗性項目，各家支援程度可能不同。Codex 的遷移參考也提醒，工具清單可以轉成文字指引，但不會因此成為嚴格的權限邊界。真正的權限要在執行環境或平台設定中處理。 **model、effort、context、user-invocable 和 disable-model-invocation 等欄位，可能是 Claude 專屬或語意不同的設定。**逐項查清楚它們在來源平台控制什麼，再決定要刪除、改寫為一般指引，或放到 Codex 支援的設定中。 **Hooks、子代理與指令需要分開檢查。**例如，Claude 的 Slash Command 可以轉成 Skill 的概念，但參數代換、工具呼叫和執行時機未必相同；Hook 的事件種類與行為也不保證一對一對應。 **MCP 設定不是 Skill 內容本身。**Skill 可以說明如何使用工具，但伺服器設定、認證與工具權限要在 Codex 支援的整合方式中另外處理。 若原本的 Claude Skill 帶有 hooks、agents、.mcp.json、commands/ 或 plugin.json，先列清楚每一項功能，再決定要手動改寫、用 MCP／Plugin 重建，或保留為人工處理事項。不要只移動資料夾就宣稱遷移完成。 官方遷移工具可以參考，但要先檢查新舊版本OpenAI 的舊版 Skills Catalog for Codex 曾提供 migrate-to-codex Skill。它設計的流程包含掃描來源、產生計畫、檢查風險、Dry Run、執行遷移，再驗證目標檔案。 **時效提醒：截至本文查核日，該 GitHub 專案首頁已標示 deprecated；其中的遷移 Skill 仍可查閱，但不應把它當成保證持續更新的安裝或遷移入口。**它的差異參考文件也標註最後檢查日期為 2026 年 4 月。若要用這份工具，先確認目前版本、命令選項和 Codex 官方文件，再檢查 Dry Run 的檔案清單；不要未審查就執行會寫入或刪除檔案的步驟。 目前 OpenAI 的文件說明 Codex 可從 .agents/skills/ 載入本機 Skill；若要跨專案散布或搭配連接器，則可依現行 Plugin 文件打包。OpenAI 也提供 Claude Code Plugin 遷移指引，逐項說明哪些 skills/、commands/、Hook 和設定需要保留、改寫或另外處理。這些文件比沿用舊版範例更適合當下的檢查起點。 我會採用的遷移工作流把 Skill 當成程式一樣檢查，比「搬過去應該就能跑」可靠： 1234567891011盤點來源 ↓確認 Codex 支援範圍 ↓複製 Skill 和必要資源 ↓改寫平台專屬欄位與呼叫方式 ↓檢查腳本、路徑和權限假設 ↓用一個真實任務驗證 只有單一 SKILL.md 的情況，可以手動遷移並逐段檢查；如果整個 Claude Plugin 還包含 MCP、Hook、Subagent 和 Marketplace 設定，就先分拆成不同能力處理。每完成一類設定，都要確認它在 Codex 端的實際替代方式，並檢查遷移後的 Skill 能否找到原本依賴的檔案。 完成檔案搬移後，不要只看資料夾出現就算過關。先確認 Codex 能發現這個 Skill，再用明確的提示詞呼叫它；觀察它是否真的套用設計規則、遵循限制並找到參考資料。遇到結果不符時，修正 Skill 後再跑一次相同任務。 npx skills add 是社群工具，不是 OpenAI 官方指令另一種常見做法是使用 Vercel Labs 維護的 Skills CLI： 1npx skills add OWNER/REPO 它可以協助從 GitHub 等來源安裝 Skill，不過這是第三方工具，不是 OpenAI Codex 的官方指令。使用前先確認來源 Repo、版本、Skill 實際內容、會執行的腳本、權限和檔案寫入位置。若只是移轉單一 Skill，手動檢視及複製往往更容易知道哪些內容真的進入 Codex。 把設計風格圖鑑變成自己的 Design Skill Library我覺得卡斯柏圖鑑最值得帶走的，不是收集一大堆別人的 Skill，而是拆解它們背後的設計方法。看到喜歡的網站時，可以問：它怎麼使用字體、留白、網格、層次、圖片、動態、互動與響應式版面？哪些反模式值得寫進檢查清單？ 再把反覆會用到的方法整理成小而清楚的 Skill，例如： 123456.agents/skills/├── editorial-web-design/├── landing-page-design/├── dashboard-design/├── motion-design/└── design-review/ 開始設計頁面時，按需求組合相關 Skills，再請 Agent 依 design-review 檢查層級、留白、手機版與動畫。這種模組化方式比較容易逐項維護，也比把 UI、UX、SEO、動畫、框架、文案和部署全塞進一個超大型 Skill 更清楚。 Skill 累積的是可重複執行的工作方法，不是某個模型的永久能力保證。模型和產品功能會改版，Skill 的路徑、工具與規則也要跟著實際環境檢查；能跨平台重用的部分，才是真正留下來的專業方法。 如果你也在整理 Codex 和 Claude 的工作流程，可以延伸閱讀我把 ChatGPT 接上開發台 MCP，讓 Codex 接手實作的流程。 常見問答 (FAQ)Q1：Claude 的 SKILL.md 可以直接放進 Codex 嗎？若內容主要是一般文字指令、範例與參考檔案，通常可以先複製到專案的 .agents/skills/<skill-name>/ 再測試；但 Claude 專屬的 frontmatter、Hook、工具權限與呼叫方式需要檢查，不能假設完全相容。 Q2：Codex 專案 Skill 應該放在哪個資料夾？Codex 官方文件列出的專案 Skill 位置是 .agents/skills/。每個 Skill 資料夾至少要有含 name 與 description 的 SKILL.md；參考資料、腳本和資產可依需要放在同一個資料夾。 Q3：Claude Plugin 的 Hooks、MCP 和 Subagents 也會一起搬過去嗎？不一定。這些功能和 Skill 指令使用不同的執行方式，要依 Codex 支援的 Hook、MCP、Plugin 或 Agent 設定分別檢查；有些行為沒有直接對應，需要人工重寫或保留為手動步驟。 Q4：npx skills add 是 Codex 官方安裝工具嗎？不是。它是 Vercel Labs 維護的跨 Agent Skills CLI。它可以安裝 Skill，但使用前仍要檢查來源與內容；Codex 本身也有官方文件描述本機 Skill 的位置和 Plugin 發佈方式。 參考資料 卡斯柏｜Claude Code Skill 設計風格圖鑑 Anthropic｜Claude Code Skills OpenAI｜Build skills for ChatGPT and Codex OpenAI｜Skills Plugin concept OpenAI｜Submit your Claude Code plugin Agent Skills｜Open Standard OpenAI｜舊 Skills Catalog 與 migrate-to-codex 資料（查閱時請留意該 Repository 的 deprecated 標示） Vercel Labs｜Skills CLI

  • 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 Agent 寫成一本開源教科書，這幾章最值得先啃

    2026/9/22

    AI Agent Codex MCP
    華為「天才少年」把 AI Agent 寫成一本開源教科書，這幾章最值得先啃

    最近看到一個 GitHub 專案時，我原本以為又是一本 AI Agent 教學。 點進去之後才發現，規格有點誇張。 《深入理解 AI Agent：設計原理與工程實踐》不只免費開源，目前的 2.0 版還整理成：10 章正文、109 個配套實驗、PDF、EPUB、繁體中文版與 15 種語言版本，程式碼也一併公開。 我更在意的是，這不是把一堆工具名詞排在一起的入門書。它試圖回答一個更根本的問題：一個能在真實世界工作的 Agent 系統，到底要怎麼被設計出來？ 作者李博杰的背景也讓這件事更有意思。公開資料顯示，他曾就讀中國科大少年班學院，完成中科大與微軟亞洲研究院聯合培養博士，並曾入選華為首批「天才少年」計畫；他的個人資料頁也列出系統、研究與工程相關經歷。中國科大資料與作者個人頁都可交叉參考。 所以我特別想看：一個實際做過系統、Infra、研究與工程的人，會怎麼拆解現在大家都在談的 AI Agent？ 先記住這個公式：Agent = LLM + Context + Tools這本書一開始就把 Agent 壓成一個非常簡單的公式： Agent = LLM + Context + Tools LLM 是大腦：理解、推理、產生下一步。 Context 是它此刻知道什麼：任務、歷史、規則、檔案、記憶與工具描述。 Tools 是它做得到什麼：搜尋、查資料庫、改檔案、跑程式、操作瀏覽器或電腦。 看起來很簡單，但整本書就是沿著這三件事一路拆下去：Coding Agent、MCP、Computer Use、Memory、Multi-Agent，甚至 Agent 如何從執行紀錄持續進化。 這正是我覺得它值得讀的原因。 現在學 Agent，很容易學成「會 n8n、會串 API、會 MCP、會做 RAG、會用 Codex 或 Claude Code」。但這些其實比較像零件。 再往上一層，真正該問的是： 一個好的 Agent 系統，怎麼在正確的時候取得正確資訊、選對工具、完成任務，並且被驗證？ 如果你已經開始用 Codex、Claude Code、MCP 或 Computer Use，我反而不建議一開始從第一章一路線性讀完。下面這幾章會更有感。 第一個最推薦：Context Engineering以前大家都在談 Prompt Engineering；但在 Agent 工作流裡，Prompt 往往只是 Context Engineering 的一小部分。 Agent 表現好不好，很大程度取決於： 它目前到底看到了哪些資訊？ 哪些資料應該放進 Context，哪些要移出去？ Skill 該在什麼時候載入？ 對話與工作紀錄要如何壓縮？ 工具說明要全部塞進去，還是動態發現？ 工作做到一半 Context 撐不住時，系統要怎麼恢復？ 書中的第二章直接談 KV Cache、提示工程、Agent Skills 與 Context Compression。對已經在使用 Coding Agent 的人來說，這一章的價值很高，因為你會開始理解：為什麼同一顆模型放在不同工作環境裡，結果可能差那麼多。 下一階段的競爭未必只是「哪個模型 IQ 更高」，而是： 誰能在正確的時候，把正確的 Context 給模型。 這也和我先前整理的從 Skill 到 Agent Harness很接近：模型能力只是其中一層，工作環境如何供應 Context、工具、規則與回饋，才決定它能不能把任務走完。 第二個必看：Tools 與 MCP第四章談工具，當然也包含 MCP；但我覺得比 MCP 名稱本身更重要的，是它背後的觀念： 工具就是 Agent 的手。 LLM 再聰明，如果只能產生文字，它仍然比較像聊天機器人。 接上搜尋，它能查資料；接上資料庫，它能查詢與寫入；接上 Gmail 或 ERP，它能處理企業流程；接上瀏覽器與 Computer Use，它甚至可以操作沒有 API 的網站與 GUI 軟體。 所以 MCP 不是終點，而是讓模型應用與外部能力更容易連接的介面。真正值得思考的是： Agent 怎麼知道現在需要哪一個工具？ 工具描述是否足以讓它選對？ 它沒有能力時，能不能發現並載入合適的 Skill、MCP 或 API？ 任務結束後，怎麼把不必要的工具說明移出 Context？ 這才是走向通用 Agent 的方向。若你還在釐清 MCP、Skill 與 CLI 的角色分工，可以先讀站內這篇：AI 工具名詞全解析。 第三個可以直接跳讀：Coding Agent這本書有一句我很喜歡： 程式碼，是「可以建立新工具的工具」。 這句話很能解釋，為什麼這一兩年 Coding Agent 會變得這麼重要。 以前的 Agent 遇到沒有工具的事情，可能只能停下來；現在的 Coding Agent 可以嘗試自己寫一個小工具、跑測試、修 bug，再拿這個程式完成原本的任務。 所以 Codex、Claude Code 真正值得注意的地方，不只是「幫你寫程式」，而是它們讓 Agent 開始具備擴充自己能力的能力。 當然，這不代表可以放任 Agent 任意執行。工具權限、Sandbox、測試、Review 與明確的完成條件，仍然是系統設計的一部分。會寫程式不等於任務一定完成；能測試、能回報、能被人驗收，才是可靠的工程流程。 第四個：從 Computer Use 看 Agent 的行動範圍過去自動化多半依賴 API、CLI、MCP 或 Browser Automation。但企業裡有大量系統根本沒有 API：ERP、MES、老舊 Windows 軟體、內部行政平台，甚至只能靠滑鼠點擊的工具。 這時候 Computer Use 的意義，就不只是「AI 會控制滑鼠」。書裡從兩個角度理解它： Observation Space：Agent 可以觀察到多少世界？文字、圖片、語音、螢幕，或實體環境。 Action Space：Agent 可以對世界做多少事？產生文字、呼叫工具、點擊 GUI，甚至控制機器人。 從這條線看，Agent 正在從聊天介面走向可以工作、可以觀察結果、也能根據結果再行動的代理人。 不過，Computer Use 也會把安全與可靠性問題放大：畫面改版、權限不足、不可逆操作、錯誤回饋不清楚，都需要在流程中設計 guardrail，而不是只追求「它能不能點」。 做企業 AI，一定要補：Agent Evaluation我覺得這是現在很多課程最容易略過、但企業最需要的一章。 我們常說 Claude 比較聰明、GPT 比較穩、Gemini 的 Context 比較大，或某個 Agent「感覺」比較好用。但當 Agent 要進入企業流程，不能只靠感覺。 更好的做法是建立自己的任務集，例如 100 個真實任務，然後觀察： 要測什麼 為什麼重要 成功率 任務是否真的被完成，而不只產生看似合理的回答 成本 Token、工具呼叫與人工覆核是否能負擔 延遲 工作流程是否能在可接受時間內交付 人工介入率 哪些步驟仍需要人，以及原因是什麼 重試次數 Agent 是否經常卡住、繞圈或選錯工具 錯誤類型 問題是 Context、工具、權限、模型還是流程設計 最後才有根據決定：哪個模型、哪個 Agent、哪種 Prompt、哪個 Harness，適合這一項工作。 Evaluation 不是最後才補的報表，而是用來推動系統改進的方向盤。 更接近「AI 員工」的關鍵：持續進化我自己也非常想看第九章的 Agent 持續進化。 現在很多所謂 AI 員工，本質上仍是： 固定 Prompt + 固定 Workflow + 幾個工具 它可以每天重複執行，但不一定會從結果學到東西。 更有意思的問題是：Agent 完成一個任務後，能不能留下可分析的執行軌跡（trajectory）？這次為什麼成功？失敗在哪裡？下一次要更新 Knowledge、Prompt、Skill、工具選擇，還是程式碼？ 1234567891011任務 ↓執行 ↓留下 Trajectory ↓分析成功與失敗 ↓更新 Knowledge / Prompt / Skill / Code ↓下一次做得更好 這時候才開始接近「會成長的 AI 員工」，而不只是換了皮的 Chatbot。 前提是，你必須先有明確的成功標準與可觀測紀錄；否則 Agent 留下的只是一大串 log，沒有辦法轉成真正的改善訊號。 Multi-Agent 不是畫一張公司組織圖Multi-Agent 也很容易被玩成「行銷 Agent、PM Agent、工程 Agent、財務 Agent」排成一張組織圖。 但真正困難的工程問題反而是： Agent 之間應該分享多少 Context？哪些資訊必須隔離？ 誰負責拆任務？誰擁有最後決策權？ 交接資料如何結構化，才不會在對話中流失？ Agent 意見衝突時怎麼處理？ 怎麼避免它們彼此聊天、消耗 Token，卻沒有推進結果？ 這些都是協作系統設計問題，不是多開幾個聊天視窗就會自然解決。 如果你已經會用 Agent，我建議這樣讀如果你已經在玩 Codex、Claude Code、MCP 或 Computer Use，我會建議先走這條路： 1234567Context Engineering → Tools / MCP → Coding Agent → Computer Use → Agent Evaluation → Agent 持續進化 → Multi-Agent 再回頭補 Memory / RAG、模型後訓練、SFT / RL，通常會更有感。因為你已經知道這些零件要被放進什麼樣的工作系統裡。 而且這套內容最棒的地方，不是只讓你讀。專案目前提供 109 個配套實驗，很多概念可以直接跑、直接觀察、直接改。比起再追 20 個剛推出的 AI 工具，我更想從中挑出大約 20 個最值得玩的實驗，再拿 Codex、Claude Code、MCP 與 Computer Use 重新實作一次。 工具會換，模型也會換；但 Context 如何設計、工具如何選擇、Memory 如何管理、Agent 如何評估、任務如何拆解、執行紀錄如何轉成改善，才是更能留下來的能力。 如果你最近也覺得 AI 工具已經多到追不完，或許現在正是回頭把「Agent 到底怎麼運作」真正弄懂一次的好時間。 資料來源與延伸閱讀 bojieli/ai-agent-book：深入理解 AI Agent：設計原理與工程實踐 作者李博杰公開個人資料 中國科大：李博杰獲 2017 年微軟學者獎學金 從 Skill 到 Agent Harness：讓 AI 從知道怎麼做，走到真正完成工作 常見問答 (FAQ)Q1：這本《深入理解 AI Agent》適合完全沒有程式背景的人嗎？可以先讀第一章建立全貌，但書內不少實驗需要讀懂並修改中等複雜度的 Python，並熟悉命令列、Git、JSON 與 REST API。若你的目標是實作，建議先從自己最常用的工具與一個小任務開始，再回頭閱讀對應章節。 Q2：為什麼已經會寫 Prompt，還要學 Context Engineering？Prompt 是一次交代模型怎麼回應的指令；Context Engineering 則處理整個工作過程中，哪些任務資料、歷史、規則、工具描述與記憶應該在何時被提供或移除。長任務與工具型 Agent 的品質，通常更受後者影響。 Q3：MCP 就是讓 AI Agent 變強的關鍵嗎？MCP 能讓模型應用以較一致的方式連接外部 Tools、Resources 與 Prompts，但它不是完整的 Agent 系統。工具選擇、權限、Context、錯誤處理、驗證與工作流程，仍需要由 Agent Harness 與產品設計處理。 Q4：企業要怎麼評估 Agent 是否真的可用？先建立由真實工作組成的任務集，為每個任務設定成功條件與不可接受的錯誤，再追蹤成功率、成本、延遲、人工介入率、重試次數與錯誤類型。不要只用單次展示或主觀體感選模型與工具。 Q5：Multi-Agent 一定比單一 Agent 好嗎？不一定。只有在任務能清楚分工、交接格式明確、資訊隔離與最終決策權都設計好時，多個 Agent 才可能帶來效益。若問題本來可由一個 Agent 穩定完成，多 Agent 反而可能增加成本、延遲與溝通失誤。

  • article-我以為 Modal 每月免費 30 美金，可以養一個 Kimi K3；結果一句話都還沒問，就先燒了 34 美金

    2026/9/17

    AI工具 AI Agent Codex
    我以為 Modal 每月免費 30 美金，可以養一個 Kimi K3；結果一句話都還沒問，就先燒了 34 美金

    前幾天看到 Modal 的 Starter 方案，我注意到一件很有意思的事： 每個月都有 US$30 的免費 Compute 額度。 不是註冊時送一次，而是每個月都有。Modal 目前的官方定價頁也把 Starter 的 Included compute 列為 US$30／月，同時把 Included token usage 列為 0。 我第一個想到的不是拿來生圖，也不是跑 Whisper。 而是： 能不能把這 30 美金，變成 Codex 裡面的另一顆大腦？ 我最近剛好想測 Kimi K3。 依我這次看到的 Kimi K3 Model Library 與部署設定，Kimi K3 是 Moonshot AI 推出的 MoE 模型，總參數規模 2.8T，每次推論約啟動 104B 參數，支援 1M context，Coding、Reasoning、Knowledge Work 與長時間 Agent 任務都是它主打的方向。 所以我原本想做的架構很簡單： Codex → MCP → Modal → Kimi K3 平常我還是在 Codex 裡工作。 遇到複雜的架構問題，我就跟 Codex 說： 這個問題再叫 Kimi K3 看一次。 需要第二模型 Code Review： 把這次修改交給 Kimi K3 Review。 需要長上下文分析： 請 Kimi K3 從另一個角度分析。 這樣 Codex 是主腦，Kimi K3 是外部顧問，而 MCP 就負責在兩個模型之間傳遞任務。 聽起來很漂亮。 於是我真的下去做了。 結果第一個坑馬上就來了。 這篇不是 Modal 的官方計費說明，而是我在 2026 年 9 月 17 日這次帳號與部署紀錄上的實測。方案名稱、價格、模型版本、硬體配置與計費規則都可能更新；真正部署前，仍然要以當下的官方文件與帳務頁面為準。 我原本搞錯了 Modal 的「免費 30 美金」是什麼Modal Starter 每月提供的 US$30，正確來說是： Compute Credits。 它可以拿來支付 GPU、CPU、Memory、Container、Function，以及 Dedicated Endpoint 這類實際運算資源。 但 Modal 還有另一種產品叫： Shared Endpoint。 Shared Endpoint 是 Modal 已經把模型架好了，你直接按 token 使用。Modal 的官方 Shared Endpoints 文件明確寫著：Shared Endpoint 由 Modal 管理硬體與自動擴縮，使用量按 token 計費，而且方案內的 credits 不能用來抵扣 Shared Endpoint 使用量。 這代表 Modal 的計費要拆成兩個錢包： 類型 計費方式 Starter 每月 US$30 Compute 可抵嗎？ Dedicated Endpoint、Functions、Containers GPU、CPU、Memory 等運算資源 可以，依適用規則計算 Shared Endpoint Prompt、Cached Prompt、Completion tokens 不可以，另按 token 計費 所以我一開始腦中的想像： 「每月送我 30 美金，然後慢慢拿來問 Kimi K3。」 其實不成立。 這 30 美金不是 Modal 帳戶裡可以任意使用的通用餘額，而是一張限定用途的雲端運算抵用券。 那我就自己架 Kimi K3 好了？既然 Shared Endpoint 不能吃免費額度，那我就走另一條： Dedicated Endpoint。 這樣 GPU Compute 理論上可以扣每月 US$30。 Modal 也真的支援 moonshotai／Kimi-K3，所以我想： 有工作才開機，跑完 scale down。 這不正是 Serverless GPU 最適合的場景嗎？ 於是我建立 Kimi K3 Dedicated Endpoint，然後開始 provisioning。 一分鐘。 五分鐘。 十分鐘。 二十分鐘。 最後： 29 分 22 秒，Endpoint Failed。 原因不是模型掛掉，也不是第一個 Prompt 回答錯誤。 而是： 我的 US$30 額度不夠了。 更精確一點，畫面一度顯示 workspace 已經使用 107%，用量是 US$31.97；後來把 Billing Report 拆開，最後看到的數字是： 帳務項目 金額 Metered Cost US$34.16 Credits -US$30.00 Billed Cost US$4.16 最精彩的是： 我連第一個 Prompt 都還沒送。 Kimi K3 一句話都還沒回答我，US$34.16 的 Metered Cost 已經產生了。😂 錢到底燒去哪裡？這次 Billing Report 裡的主要成本是： 資源 主要成本 B300 GPU 約 US$27.61 Memory 約 US$3.98 CPU 約 US$0.37 這是主要項目，不是完整帳務明細；但已經足夠看出問題：我以為自己是在問一個模型，實際上是在付一整套大模型推論環境的啟動與運行成本。 看到 B300，我一開始也懷疑： 「是不是 Modal 幫我選太貴的 GPU？如果換便宜一點的不就好了？」 但繼續挖 Log 後，答案比「換卡」複雜很多。 Kimi K3 真的用了 8 張 B300Log 裡可以看到： CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 SGLang 的啟動參數也直接寫著： –tp 8 Tensor Parallel 等於 8。 更進一步的 Log 還寫著： Kimi-K3 … on B300／GB300world_size=8 所以不是我猜測它用了 8 張 B300。 這次部署真的就是一套 8 × B300 的 Kimi K3 推論環境。 更誇張的是，這 8 張 GPU 有很長一段時間都還在載入模型。 從開始 Load weight 到完成，大約是： 1352 秒，也就是 22 分 32 秒。 而且每張 GPU 載入模型後，記憶體使用量大約都在 190GB 左右。 這也回答了我原本另一個想法： 「那換便宜一點的 GPU 不就好了？」 不能只看每張 GPU 的單價，還要看模型權重怎麼切、每個 Tensor Parallel Rank 需要多少記憶體，以及總 GPU 數量會不會因此增加。 GPU 單價比較便宜，不代表整個模型推論比較便宜。 Modal 預設把 K3 火力全開我繼續看啟動參數，才發現 Modal 幫我架的不是什麼「個人測試版 Kimi K3」。 這套部署直接準備了： 1M context context-length 1048576 FP8 KV Cache DFLASH speculative decoding Multimodal CUDA Graph 最高 48 個 running requests 各種 FlashInfer、TensorRT 與 Blackwell 最佳化 另外載入 Kimi-K3-DFlash Draft Model 換句話說，它幫我準備的是一套可以提供大量 API 流量的高效能 Kimi K3 Server。 而我真正需要的是： 「偶爾叫 Kimi K3 幫 Codex 看一下程式碼。」 這是完全不同的需求。 我想要的是低頻率、可控成本的外部顧問；Dedicated Endpoint 給我的卻是需要先付出高額啟動成本、再等待模型載入的大型服務環境。 Spend limit = 0，也不該被當成唯一硬控因為我一開始就怕爆預算，所以很認真地把 Modal 設定成： Usage limit：US$30 Spend limit：US$0 我原本的理解是： 「免費額度 US$30 用完，就停止；一毛錢都不付。」 但實際結果是，這次最後仍然出現 US$4.16 的 Billed Cost。 這裡要把兩件事分開看。 Modal 目前的預算文件把 Workspace budget 定義成整個 Workspace 的用量上限，把 spend limit 定義成套用 credits 後的自付費用上限。官方也說，達到 spend limit 後，會停止還會產生額外自付費用的工作負載。 但這種平台層級的 Budget，不等於 MCP 在送出任務前的即時交易鎖。 如果 GPU workload 已經啟動，帳務資料、超額偵測與停止工作之間存在時間差；而 Kimi K3 是 8 張 B300 同時燒，幾分鐘的延遲就可能不是幾分錢。 所以我現在的結論不是「Spend limit 完全沒用」，而是： 不能只把平台上的 Spend limit 當成唯一防線。 平台 Budget 負責最後一層；MCP Budget Guard 要在任務送出前先攔一次。 我還踩到一個認證坑：Shared Endpoint 需要 Proxy Token在測試 Endpoint 時，Modal 曾經直接顯示： Create a proxy token to require authentication for this Endpoint, or create the Endpoint with unauthenticated access. 這不是單純的錯誤訊息，而是提醒我：Endpoint 的「可以呼叫」和「應該公開」是兩件事。 依照 Modal 的Endpoints 文件，Shared Endpoint 一律需要 Proxy Token，Dedicated Endpoint 預設也需要 Proxy Token；只有在建立 Dedicated Endpoint 時，才可以選擇 unauthenticated。 如果之後要把它接進 Codex 或 MCP，正確的方向應該是： 建立權限範圍清楚的 Proxy Token。 Token 只放在 MCP Server 的環境變數或 Secret 管理裡。 不把完整 Token 貼進 Codex 對話、文章、Log 或 Git。 MCP 只把模型結果回傳給 Codex，不把平台憑證暴露給工具使用者。 若是 Shared Endpoint，還要處理並行限制、逾時、重試與 429 回應。 Modal 官方也提供給 Codex 的 Endpoint 整合方式，會以 OpenAI-compatible API 與 Proxy Token 呼叫 Endpoint。這表示真正要做的不是把 Token 寫死在某個腳本裡，而是把認證、成本與資料邊界一起放進 MCP 的設計。 Shared Endpoint 反而才是我原本需求的正確模式Dedicated Endpoint 走不通，不代表 Kimi K3 不適合接進 Codex。 答案其實就在 Modal 自己的另一個選項： Shared Endpoint。 Modal 已經幫大家養好那套昂貴的 GPU infrastructure，我只需要按 token 付費，不用自己啟動 8 張 B300。 這次 Kimi K3 Shared Endpoint 在我的帳號畫面上看到的價格是： 用量 價格 Prompt US$3／1M tokens Cached Prompt US$0.30／1M tokens Completion US$15／1M tokens 這些價格和模型可用性可能調整，實際使用前應以Kimi K3 Model Library與 Endpoint 的 Usage view 為準。 假設一次 Codex Code Review： 輸入：50,000 tokens 輸出：5,000 tokens 輸入成本： 50K × US$3／1M = US$0.15 輸出成本： 5K × US$15／1M = US$0.075 合計約： US$0.225。 這個經濟模型反而很合理。 不用付模型開機費，不用等 22 分鐘 Load weight，也不用為了問一個問題，先花 US$30 把模型叫醒。 但要注意：Shared Endpoint 不能用 Starter 的 US$30 Compute Credits 抵扣，所以它需要另一個「Token Budget」，不能和免費 Compute 共用同一個錢包。 三種模式，現在要分清楚 模式 主要計費 能用 Modal 每月 US$30 Compute 嗎？ 適合情境 Kimi K3 Dedicated GPU、CPU、Memory 運算資源 可以依適用規則抵扣 大量流量、隔離容量、可控 autoscaling Kimi K3 Shared Prompt、Cached Prompt、Completion tokens 不可以 偶爾從 Codex 呼叫 K3 小型／中型模型 Dedicated GPU、CPU、Memory 運算資源 可以依適用規則抵扣 把 Starter Compute 額度真正用在低頻實驗 所以我會把 Modal 每月 US$30 的用途重新定義成： Codex ↓MCP ↓Modal ↓Qwen、GLM 或其他小型／中型開源模型 這種才有機會真的把免費 GPU 額度玩出價值。 至於 Kimi K3，則走另一條： Codex ↓AI Consultant MCP ↓Kimi K3 Shared Endpoint ↓按 token 計費 ↓結果回 Codex MCP Budget Guard 要改成兩個錢包我原本只設計 Compute Budget Guard，因為我以為所有成本都會從每月 US$30 裡扣。 現在看來，MCP 至少要分成兩個預算池： 預算池 控制內容 範例 Compute Budget Dedicated Endpoint、Function、Container 的 GPU／CPU／Memory 成本 US$27 警告、US$29 停止 Token Budget Shared Endpoint 的 Prompt、Cached Prompt、Completion 成本 另設每月 token 預算與單次上限 Compute Budget 的設定可以先維持： 項目 設定 用意 每月預算上限 US$29 不把免費 Compute 用到最後一美元 安全警告線 US$27 接近上限時提醒 Modal 免費 Compute US$30 目前方案假設，依官方頁面更新 每次 Codex 要呼叫外部模型前，MCP 可以先做： 判斷這次要走 Shared 還是 Dedicated。 讀取對應預算池的本月已使用量。 讀取尚未完成任務的預估成本。 加上這一次請求的預估成本。 先做原子化的預算預約，再送出任務。 接近警告線時提醒；達到上限時拒絕新的請求。 任務完成後，用實際 token 或 Compute 成本結算預約。 如果目前帳面只用了 US$26.80，還沒超過 US$27，此時 Codex 同時送出三個任務，而 Modal 的帳務資料還沒反映這三個任務，三個請求可能都會得到「可以執行」。 所以 Budget Guard 不能只讀已完成帳務，還要把已送出但尚未結算的工作加入暫時預約： 目前已入帳用量 ＋進行中任務的預估用量 ＋這次請求的預估用量 ＝預計本月用量 此外，預約動作本身也要有鎖定或原子更新，避免多個並行請求同時讀到同一個舊數字。 Budget Guard 不是精準預言帳單的工具，而是一個讓「不小心超支」變得比較難發生的防線。 這次之後，我想做的已經不只是 Kimi K3 MCP繞了一大圈之後，我反而更確定原本的方向沒有錯。 只是 Backend 選錯了。 我想做的其實不是： 「在 Modal 免費跑 Kimi K3。」 而是： 「讓 Codex 能在需要的時候，呼叫另一個 AI。」 第一版 MCP 可以先放： MCP 工具 用途 第一版限制 ask_kimi_k3 詢問 Kimi K3 一般問題 只回傳分析結果，不直接修改專案 review_code 請模型 Review 程式碼或 diff 只傳必要內容，先遮罩 secrets analyze_architecture 分析架構、取捨與潛在風險 輸出建議，不自動採用決策 get_modal_usage 查詢本月 Compute 或 Token 用量 清楚標示資料時間與帳務延遲 check_budget 檢查對應預算池與進行中預約 在其他模型工具前先呼叫 但 MCP 不一定只接 Kimi K3。 未來更有趣的架構可能是： Codex │ └─ AI Consultant MCP │ ├─ Kimi K3：高難度、長上下文 ├─ Qwen：Coding 與一般分析 ├─ GLM：Agent 與工具使用 └─ DeepSeek Flash：便宜任務 │ └─ Modal Shared Endpoints 不同問題叫不同模型，便宜的工作交給便宜模型，真正困難的工作才叫 Kimi K3。 然後 MCP 統一處理： Token 統計 成本計算 月預算 模型 Routing Proxy Token Code Review 結果回傳 逾時與重試 這比只做一個 Kimi K3 MCP 有趣很多。 這次真正讓我有感的，不是 Kimi K3而是我開始越來越確定一件事。 以前我們都在想： ChatGPT、Claude、Kimi、Gemini，我到底要選哪一個？ 但 Agent、MCP、API 越成熟後，這個問題可能會慢慢變成： 我的主 Agent，需要哪些外部能力？ Codex 可以是主要工作的 Agent。 Kimi K3 不一定要取代它。Kimi 甚至不用是一個我每天打開的聊天網站。 它只需要是： Codex 工具箱裡的一個 Tool。 需要它時才叫它，不需要就完全不用。 這才是我覺得 MCP 真正開始有意思的地方。 它不只是讓 AI 可以操作更多工具，而是你開始可以自己組裝一個 AI 的能力邊界。 搜尋是一個 Tool。 資料庫是一個 Tool。 瀏覽器是一個 Tool。 你的公司系統是一個 Tool。 甚至： 另一個更強的 AI，也可以只是一個 Tool。 至於 Modal 每個月那 US$30？ Kimi K3 我是不敢再拿它養了。😂 下個月我準備換一個小一點的模型，把這 30 美金真的榨乾。 我接下來會怎麼做？這次實驗讓我的順序重新排過： 先確認模型的 serving mode，是 Shared 還是 Dedicated。 先看清楚 Compute Credits 與 Token Usage 是否使用同一套額度。 先設定平台層級的 Workspace budget 與 spend limit。 在 MCP 裡再加一層預算池、單次上限與進行中任務預約。 先用小型／中型模型驗證 Modal 免費 Compute 的實際用途。 Kimi K3 改用 Shared Endpoint，先做低成本的單次請求測試。 最後才把它接進 Codex，觀察什麼時候真的值得叫第二個模型。 真正好的多模型工作流，不是把所有模型都開起來，而是知道什麼任務該叫誰、要花多少錢、哪些資料可以送出去，以及什麼時候應該停止。 常見問答 (FAQ)Q1：Modal Starter 每月 US$30 免費 Compute，可以拿來使用 Kimi K3 Shared Endpoint 嗎？不可以直接這樣理解。Modal 官方文件明確區分 Shared Endpoint 的 token 計費與方案內的 Compute Credits；Included Compute 不能拿來抵 Shared Endpoint 使用量。Shared Endpoint 應該另外設定 Token Budget，並以當下 Endpoint Usage 顯示的價格為準。 Q2：為什麼我沒有送出 Prompt，還是產生了 US$34.16？因為這次走的是 Dedicated Endpoint。8 張 B300 在 provisioning、載入模型、初始化推論環境的期間，就可能產生 GPU、Memory、CPU 與其他運算成本；模型還沒回答第一個 Prompt，不代表完全沒有使用計費資源。 Q3：Spend limit 設成 US$0，為什麼還可能看到自付費用？平台層級的 spend limit 是重要防線，但不是送出任務前的 MCP 交易鎖。正在執行的工作、帳務資料更新與停止動作可能存在時間差，因此還是要在 MCP 送出請求前做預算檢查、預約與拒絕新任務的控制。 Q4：Shared Endpoint 一定要建立 Proxy Token 嗎？Modal 目前的官方 Endpoints 文件說，Shared Endpoint 一律需要 Proxy Token，Dedicated Endpoint 預設也需要。Proxy Token 應留在 MCP Server 的 Secret 或環境變數中，不要放進文章、Git、Codex 對話或公開前端。 Q5：偶爾從 Codex 呼叫 Kimi K3，應該選 Shared 還是 Dedicated？以這次需求來看，Shared Endpoint 比較合理，因為 Modal 管理硬體與自動擴縮，你按 token 使用；Dedicated Endpoint 比較適合需要隔離容量、可控 autoscaling 或大量流量的服務。最後仍要以實際價格、延遲、並行限制與資料政策決定。 Q6：那 Modal 每月 US$30 Compute 最適合拿來做什麼？比較適合小型／中型 LLM、Whisper、Embedding、Reranker、OCR／Vision、TTS、FLUX／SDXL、Agent Sandbox、Batch GPU 工作，以及其他有工作才啟動的 GPU Function。重點是先估算模型載入與執行時間，不要只看「免費」兩個字。 參考資料 Modal Pricing Kimi K3 Model Library Modal Shared Endpoints 官方文件 Modal Endpoints 與 Proxy Token 文件 Modal Budgets 文件 如果想先釐清 MCP、Skill 與 CLI 的分工，可以參考AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI 的差異與應用場景。如果想看另一種 ChatGPT、MCP 與 Codex 的分工方式，也可以延伸閱讀我把 ChatGPT 接上自己的開發台 MCP，AI Coding 開始變成一條「軟體開發流水線」。