跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

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

分類

標籤

AI工具 (82) ChatGPT (19) 商業策略 (32) AI自動化 (85) AI Agent (49) SEO (13) AEO (8) 內容行銷 (27) Cursor (2) Vibe Coding (45) Codex (17) MCP (3) 影音行銷 (44) Gemini (11) AI Coding (2) Meta Ads (1) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) AI繪圖 (8) n8n (28) 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)
  • 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-【Adobe 全家桶替代品來了？7 套開源創作工具開始為 AI Agent 設計】

    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 的授權印象。

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

    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 自動化真的會讓工作變輕鬆嗎？它可能縮短部分任務的處理時間，但省下的時間也可能被更大的目標、新的專案或更多協調工作填滿。是否更輕鬆，還取決於組織如何安排工作與分配效率收益。

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

    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。

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

    2026/9/30

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

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

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

    2026/9/28

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

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

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

    2026/9/26

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

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

  • article-2026 年了，現在做 AI 還有沒有搞頭？從 AI 工具到工作流程重設計

    2026/9/23

    商業策略 AI自動化 AI Agent
    2026 年了，現在做 AI 還有沒有搞頭？從 AI 工具到工作流程重設計

    今天有人問我： 現在 AI 還有搞頭嗎？ 我想了一下，答案是：有，而且我甚至覺得，現在才真正開始有搞頭。 只是有一件事情已經變了。 以前只要會用 ChatGPT、會下 Prompt、會生圖片、會做簡報，就可能被叫做「AI 專家」。現在不太一樣了，因為這些能力正在快速變成基本能力。 所以真正應該問的，不是「AI 還有沒有搞頭」，而是： 接下來 AI 的錢，到底在哪裡？ 我會把這個變化分成幾個階段來看。 第一階段：賣「會用 AI」還有價值嗎？前幾年最容易賺錢的，是資訊差。 很多人還不知道 ChatGPT 能做什麼，因此只要你會寫 Prompt、做簡報、生圖、寫文案、摘要文件，就能開課、接案或提供顧問服務。 這個市場沒有完全消失，但門檻已經快速降低。AI 越來越能理解自然語言，很多以前需要寫一大串 Prompt 的事情，現在只要用幾句話描述需求就能開始。 所以我一直覺得： Prompt 不會消失，但「只會 Prompt」會越來越不值錢。 Prompt 仍然是與模型溝通的方法，只是它不再是完整的商業護城河。真正的差異會逐漸移到你理解什麼問題、怎麼判斷結果，以及能不能把結果放進一個可交付的流程。 第二階段：只賣一個 AI 工具，風險越來越高接著市場出現大量 AI SaaS： AI 寫文案 AI 做簡報 AI 生成社群貼文 AI 客服 AI 摘要 AI 履歷 AI SEO 這些產品當然還有市場，尤其是能掌握特定資料、流程、權限或客戶關係的產品。但問題也越來越明顯：你今天辛苦做出一個功能，半年後 ChatGPT、Gemini、Claude、Canva 或其他大型平台，可能直接把它內建成一個按鈕。 所以我現在看一個 AI 產品時，會先問： 如果下一代模型直接把這個功能內建，我還剩下什麼？ 如果答案是「什麼都沒有」，那產品就很危險。能留下來的，通常不是單一生成按鈕，而是專屬資料、產業判斷、流程整合、權限管理、稽核紀錄、客戶關係，以及一套穩定交付結果的方法。 第三階段：AI 開始進入工作流程我認為這才是現在真正有意思的地方。 不要只想： AI 可以幫我寫一封 Email。 而是想像一整段工作： 客戶填完表單。 AI 自動判斷需求並整理資料。 根據規則為客戶分級。 產生合適的回覆並寄信。 透過 LINE 通知業務。 建立後續追蹤任務。 把結果寫回 Dashboard 或 CRM。 這時候 AI 已經不是單純的聊天機器人，而是公司流程的一部分。Google Sheet、GAS、n8n、MCP、AI Agent、Codex，單獨看每一個工具，其實都沒有那麼重要。 真正重要的是： 它們串起來之後，可以拿掉多少原本需要人工處理的工作？ 這也是企業導入 AI 時，應該從「哪個工具最好」轉向「哪段流程最值得重設計」的原因。若想延伸理解企業可以如何組合不同 AI 能力，也可以參考企業工作自動化不只有 ChatGPT：6 大 AI 自動化能力解析。 第四階段：專業知識開始軟體化這是我最近非常有感的一件事。 未來最有價值的人，可能不一定是最懂 AI 的人，而是： 最懂某個產業，又知道怎麼叫 AI 做事的人。 例如房仲。真正懂房仲的人知道屋主在意什麼、同社區競品怎麼比較、什麼叫價格問題、什麼叫曝光問題，以及物件掛了多久開始需要調整。 這些都不是 AI 原生知道的，它需要人的產業經驗。但過去這些經驗通常只能存在一個資深業務的腦袋裡，現在可以逐步整理成： 規則 流程 Prompt Skill Agent Web App 最後甚至可以變成一套軟體。 這就是我最近一直在講的：專業知識軟體化。 你以前賣的是自己的時間，現在可以開始賣： 你的經驗被 AI 執行之後的結果。 這不代表把所有判斷都丟給 AI。好的流程仍然需要定義輸入、判斷規則、例外情況與人工審核，並且持續檢查結果是否符合產業要求。關於把經驗整理成可重複執行能力，也可以延伸閱讀從經驗到 AI Skill：把專業知識變成可執行能力。 第五階段：不是導入 AI，而是重新設計公司這可能是我目前最看好的方向。 很多企業現在問的是： 我們公司要怎麼導入 AI？ 但我覺得這個問題還不夠深。真正應該問的是： 如果這家公司今天才成立，它還會用現在這套流程嗎？ 例如以前的流程可能是： 12345678客戶填表單→ 行政下載資料→ 整理 Excel→ 寄給主管→ 主管確認→ 行政再寄 Email→ 業務打電話→ 人工更新 CRM 以前只能這樣做，因為每一個系統彼此不會說話。但現在 AI Agent 可以理解內容、呼叫工具、跨系統搬運資料，也能在明確權限下完成多步驟任務，很多流程其實可以重新設計。 重點不是在原本流程裡塞一個 ChatGPT，而是： 把整條流程重新畫一次。 也許表單不需要由行政下載，也許 Excel 不需要被人工整理，也許主管只需要看例外案件，也許業務收到的不是一份待處理清單，而是一個已經完成分級、附上建議下一步的任務。 自動化是讓舊流程跑得更快；AI 原生設計則可能讓其中一部分流程直接消失。這也是我在AI 時代真正會被淘汰的，可能不是員工，而是「組織圖」一文中想繼續追問的問題。 所以現在做 AI，到底有沒有搞頭？我會說：非常有。 只是「AI」本身已經慢慢不是賣點了。 你不能只說： 我會 ChatGPT。 我會 Gemini。 我會 Claude。 我會生圖。 我會 Vibe Coding。 這些能力最後都會變成基本能力。真正值錢的是： 你能不能幫一個人完成一整件事情？ 你能不能把一個產業的 SOP 重新設計？ 你能不能把某個專家的知識變成 AI 可以執行的流程？ 你能不能把原本五個人做的工作，重新設計成一個人加 AI？ 我現在越來越認為，未來真正有競爭力的公式可能是： 產業知識 × AI × 工作流程 × 商業能力 而不是單純「AI 技術很強」。如果想從變現角度看另一條由時間、知識、能力、結果到資產的升級路徑，也可以參考AI 變現五階段：賣時間 → 賣知識 → 賣能力 → 賣結果 → 賣資產。 AI 最後會變成基礎設施再過幾年，我們可能根本不會特別講「AI 公司」。就像現在也很少有人說「我要成立一家 Internet 公司」。 Uber 是交通公司，Netflix 是娛樂公司，Shopify 是電商公司，只是它們都建立在 Internet 上。 未來應該也是一樣：房仲公司本來就會用 AI，行銷公司本來就會用 AI，製造業本來就會用 AI，教育公司本來就會用 AI。AI 最後會變成基礎設施，而不是每次都要被拿出來當成主標題。 所以如果今天再有人問我： 現在 AI 還有沒有搞頭？ 我可能會回答： AI 當然有搞頭，只是「靠 AI 兩個字賺錢」的時代正在慢慢結束。 下一個階段真正有搞頭的，是拿 AI 去改掉一個原本很爛、很慢、很貴的工作方式。 以前我們在學「AI 可以做什麼？」接下來更值得研究的是： 如果 AI 本來就存在，這件事情還需要這樣做嗎？ 我覺得真正的大機會，會藏在這個問題裡。 常見問答 (FAQ)Q1：2026 年只會使用 ChatGPT，還能算是 AI 專家嗎？只會使用 ChatGPT、下 Prompt 或生成內容，會越來越接近基本能力。更有價值的能力是把 AI 放進產業流程，定義判斷規則、處理例外，並且交付可以驗收的結果。 Q2：AI SaaS 會不會被 ChatGPT 或其他模型的內建功能取代？單一生成功能確實可能被大型平台內建，因此產品需要累積模型之外的價值，例如專屬資料、產業知識、流程整合、權限、稽核紀錄、客戶關係與穩定的交付能力。 Q3：什麼是「專業知識軟體化」？專業知識軟體化，是把原本存在專家腦中的判斷、規則與流程，整理成 Prompt、Skill、Agent、Workflow 或 Web App，讓 AI 能在明確條件與檢查機制下重複執行。 Q4：企業導入 AI，第一步應該做什麼？先盤點一段高頻、耗時、跨人員或跨系統的工作流程，畫出目前的輸入、判斷、交接與輸出，再問哪些步驟可以刪除、合併、交給 AI 執行或保留人工審核，而不是先決定要買哪一個 AI 工具。 Q5：未來最有競爭力的 AI 能力是什麼？最有競爭力的組合會是產業知識、AI 使用能力、工作流程設計與商業能力。單一工具會快速變動，但能把專業經驗轉成可執行流程並交付商業結果，通常更能持續累積價值。

  • article-我覺得 VoiceStudio 最值得注意的地方，根本不是免費

    2026/9/15

    AI工具 AI自動化 影音行銷
    我覺得 VoiceStudio 最值得注意的地方，根本不是免費

    最近看到一套開源 AI 語音工具 VoiceStudio。 它可以在自己的電腦執行，支援 TTS、語音複製、多角色語音與影片配音，也不需要每個月再付一筆訂閱費。 看到這裡，很多人的第一個反應可能是： 那我是不是可以不用訂 ElevenLabs 了？ 但我研究完之後，反而覺得「免費」可能是這套工具最不重要的地方。 真正讓我感興趣的是另外一件事情： AI 配音，正在從一個「工具」，變成 AI 工作流裡的一個「節點」。 本文談的是我對 VoiceStudio 與本地語音工作流的觀察，不是對不同語音服務的固定排名。實際功能、模型支援、硬體需求與授權方式，都應以當下的專案文件與模型授權條款為準。 我們現在用 AI，其實還是在「操作軟體」想一下現在大部分人怎麼做 AI 影片。 先叫 ChatGPT 寫腳本。 複製文字。 打開配音網站。 貼上文字。 選聲音。 按生成。 下載音檔。 再打開剪輯軟體。 匯入音訊、對字幕、找 B-roll、剪輯、輸出。 看起來整個流程用了很多 AI，但其實中間有一個很重要的角色一直沒有消失： 你。 你還是那個負責把 A 工具的結果複製到 B 工具，再把 B 工具的結果下載下來丟進 C 工具的人。 換句話說，AI 很厲害，但你還是一個「AI 工具操作員」。 這也是我之前思考 AI 影片工廠時，會把腳本、配音、字幕、素材與剪輯拆成不同能力的原因。可以先參考用 Codex 打造 AI 影片工廠：串接六大 AI 能力的完整工作流，影片工廠真正要處理的，不只是多找到幾個好用工具，而是讓每個能力可以被下一個步驟穩定接住。 真正的改變，是你連 VoiceStudio 都不用打開VoiceStudio 讓我感興趣的，不只是它可以在本地執行。 而是這類工具開始提供 API、MCP 之類可以讓其他程式直接呼叫的介面。 這件事情看起來很工程師，對內容創作者其實非常重要。 因為當一個 AI 工具可以被程式呼叫之後，「人」就不一定要站在中間了。 例如我最近一直在研究 AI 自動剪輯。 理想中的流程不是： 1我打開 ChatGPT → 打開配音軟體 → 打開剪輯軟體 而是： 1234567891011121314151617文章完成 ↓AI 自動整理成短影音腳本 ↓自動送進本地 Voice Clone ↓產生我的聲音 ↓自動分析旁白時間軸 ↓自動尋找 B-roll ↓自動產生字幕與字卡 ↓自動剪輯 ↓輸出成片 如果這條流程真的串起來，我根本不需要知道 VoiceStudio 的「生成」按鈕在哪裡，甚至不用打開 VoiceStudio。 因為它已經從「我要操作的軟體」，變成「我的 AI 員工背後會使用的一項能力」。 我覺得這才是接下來真正重要的改變。 以後我們可能不會在意「你用哪一套 AI」現在很多人在比較： ChatGPT 還是 Claude？ ElevenLabs 還是 VoiceStudio？ 這個生圖模型比較強，還是那個比較強？ 這些當然重要，但如果 Agent 的發展繼續下去，我猜這些問題的重要性會慢慢降低。 因為使用者最後看到的可能根本不是工具。 你只會跟 AI 說： 把這篇文章做成三支短影音。 剩下的事情由 Agent 自己決定。 1234567需要寫腳本，就呼叫文字模型需要圖片，就呼叫生圖模型需要我的聲音，就呼叫本地 Voice Clone需要字幕，就呼叫語音辨識需要素材，就去素材庫搜尋需要剪輯，就呼叫影片處理工具最後丟三支影片給我挑 這時候，ChatGPT、VoiceStudio、FFmpeg、Whisper 或其他模型，全部退到後台。 使用者根本不需要看到它們。 這不代表底層工具不重要，而是工具的價值開始從「使用者介面有多順」延伸到「能不能穩定成為其他系統可呼叫的能力」。 本地 AI 真正有趣的地方，也不只是省錢很多人談 Local AI，第一件事情就是算成本： ElevenLabs 一個月多少錢？ 本地模型是不是免費？ 跑在自己的電腦上是不是比較便宜？ 如果只是偶爾做幾支影片，我甚至覺得這不是最重要的問題。 雲端服務通常比較方便，模型可能也更穩定；本地方案則會多出硬體、安裝、更新、維護與排錯成本。軟體可以免費使用，也不代表每個語音模型都能免費商用，實際使用前仍要確認各自的授權條款。 真正有趣的是： 當 AI 能力搬到自己的電腦，它開始變成你可以控制的基礎設施。 不用每一次都開網頁。 不用每一次都上傳資料。 也不用每一次都等人按下「生成」。 只要電腦開著，Agent 就可以自己呼叫。 這對一天做一支影片的人，差異可能還不大。 但如果未來你不是一天做一支，而是讓 AI 一次處理 20 支、50 支，甚至 100 支內容，整個思考方式就完全不一樣了。 你不再是在找： 最好用的 AI 配音網站。 你是在建立： 我的 AI 內容基礎設施。 聲音，也正在變成一種可以重複使用的數位資產另外一個我覺得很有意思的變化，是「自己的聲音」。 以前聲音不是資產。我要錄一段新的內容，就必須重新開麥克風講一次。 講錯一句，重新錄。 課程改了一句，重新錄。 想做英文版，再錄一次。 但是 Voice Clone 出現之後，邏輯開始改變。 我的聲音可以被抽象成一個可以重複呼叫的能力。 今天拿來做短影音。 明天拿來補錄線上課程。 後天文章自動轉 Podcast。 甚至同一支內容自動產生不同語言版本。 所以未來自媒體經營者要管理的，可能不只有文章、圖片、影片與 Prompt，還會多一個東西： 自己的 Voice Profile。 它會跟 Logo、品牌色、字型、人物 LoRA 一樣，逐漸變成個人品牌的數位資產。 但這種資產也需要被好好管理：聲音樣本的保存、誰可以呼叫、哪些內容可以生成、是否允許商用，以及被濫用時如何撤銷，都不能只靠「模型很像」來處理。 把「我是誰」和「我要怎麼說」拆開這件事對自動剪影片非常重要。 一支短影音不可能從頭到尾都使用同一種情緒： 開頭 Hook 可能要比較興奮 中段解釋要穩定清楚 提醒風險時要嚴肅 講到反差時可能要驚訝 最後 CTA 又要比較親切 因此，Voice Engine 可以拆成兩層： 我是誰： 聲音的音色、辨識度與個人品牌特徵。 我要怎麼說： 情緒、語速、停頓、重音與表達方式。 理想的流程會是： 1234567891011腳本 ↓AI 理解內容 ↓判斷每一段情緒 ↓選擇語速與表達方式 ↓Voice Clone 生成 ↓送進剪輯流程 這時候 AI 就不只是單純「念稿」，而是開始理解：這句話應該怎麼說。 如果你也在處理影片聲音，可以延伸參考短影音音效怎麼選？從剪映內建到 AI 生成，一次搞懂 SFX 工作流。克隆旁白解決的是「誰在說」，SFX 與混音則決定觀眾「聽起來感覺如何」，兩者應該放在同一條聲音工作流裡設計。 我不太想問「VoiceStudio 能不能取代 ElevenLabs」因為我覺得這個問題太小了。 ElevenLabs 好不好用？當然好用。 VoiceStudio 免費嗎？軟體本身確實可以免費使用，但實際使用的語音模型仍要確認各自授權。 真正值得測試的是： 我能不能把 VoiceStudio 塞進自己的 AI Short Factory，然後以後根本不用打開它？ 如果可以，那代表配音這件事情已經從： 我要做的工作 變成： AI 自己會完成的一個步驟 再往後，生圖是一個節點，配音是一個節點，字幕是一個節點，B-roll 是一個節點，剪輯是一個節點，發布也可能是一個節點。 當這些節點全部串起來，我們真正建立的就不再是一堆 AI 工具，而是一條： AI 內容生產線。 所以 VoiceStudio 免費這件事情，我當然很開心。 但比免費更讓我興奮的是： 我們正在慢慢進入一個「不用操作 AI 工具」的時代。 真正值錢的能力，也會從「你會多少 AI 工具」，逐漸變成： 你能不能把這些 AI 能力，組成一套會自己工作的系統？ 這可能才是 AI 自媒體下一階段真正拉開差距的地方。 常見問答 (FAQ)Q1：VoiceStudio 最值得注意的地方是免費嗎？不只是免費。更值得注意的是，VoiceStudio 這類本地語音工具若能透過 API 或 MCP 被其他程式呼叫，就有機會成為 AI 內容工作流裡的語音節點，讓配音從手動操作變成可重複執行的步驟。 Q2：接進 AI 工作流後，還需要打開 VoiceStudio 嗎？理想上不需要。當 Agent 已經能透過 API 或 MCP 呼叫語音能力，使用者只要提出「把文章做成短影音」這類目標，VoiceStudio 可以在後台完成配音；但實際能否做到，仍取決於工具提供的介面、設定方式與整合品質。 Q3：本地 AI 語音一定比較省錢嗎？不一定。本地執行可能減少訂閱或按量計費，但仍要計入硬體、安裝、更新、維護、電力與排錯成本；此外，軟體免費也不代表所使用的語音模型都允許免費商用，必須逐一確認授權。 Q4：自己的 Voice Profile 可以當成個人品牌資產嗎？可以把它視為一種可重複呼叫的數位資產，但需要同時管理聲音樣本、存取權限、生成範圍、商用許可與撤銷機制。聲音相似度只是品質的一部分，不等於完整的品牌治理。

  • article-AI 自動剪片做到最後，我才發現真正缺的是自己的聲音 API

    2026/9/11

    AI工具 AI自動化 影音行銷
    AI 自動剪片做到最後，我才發現真正缺的是自己的聲音 API

    最近我一直在調整自己的 AI 自動剪影片流程。 文章可以自動改成短影音腳本。 知識圖卡可以自動生成。 字幕可以自動上。 B-roll 可以自動配。 重點遮罩、動畫、轉場，甚至剪輯節奏，也都可以慢慢交給 AI。 但做到最後，我突然發現一件事。 真正還沒有被自動化的，反而是： 我的聲音。 如果每一支影片最後還是要自己重新錄旁白，那前面再怎麼自動，其實都還差最後一哩。 所以我最近開始重新研究「克隆音」。 但這次我不是想找一個： 可以把我的聲音複製得很像的 AI 工具。 我想的是另一件事： 能不能把我的聲音，直接變成 AI 自動剪片系統裡的一個 API？ AI 自動剪片為什麼會卡在最後一哩？一條完整的影片工作流，現在已經可以拆成很多個可被自動化的能力： 文章自動改成短影音腳本 知識圖卡自動生成 字幕自動上稿 B-roll 自動配對 重點遮罩、動畫與轉場自動完成 剪輯節奏交給 AI 協助判斷 這些環節都完成後，旁白卻可能還是要由本人重新錄製。對個人創作者來說，這不只是多花一點時間，也會讓整套「內容工廠」在最後一步停住。 這也是我開始重新研究 Voice Clone 的原因。不過，我真正想找的不是另一個獨立工具，而是一個能被工作流穩定呼叫的聲音元件。 這個方向，也可以接到我之前整理的用 Codex 打造 AI 影片工廠：串接六大 AI 能力的完整工作流。影片工廠不只要能產生畫面，也要能把聲音當成可替換、可擴充的能力。 克隆音已經從模型訓練，走向可呼叫的工作流元件以前講 Voice Clone，很容易想到一個完整的模型訓練專案： 錄很多音訊。 整理資料。 訓練模型。 等待幾個小時。 得到一個自己的聲音模型。 但現在很多 Zero-shot TTS，已經可以只用一小段參考音訊，直接模仿聲音的音色。像是我目前正在看的： IndexTTS-2.5 Qwen3-TTS Chatterbox V3 GPT-SoVITS CosyVoice 3 Fish Speech 這些模型與版本是我目前的研究方向與工作流示例，不代表固定排名；支援的語言、情緒控制、硬體需求與授權方式，都可能隨版本和方案變動，實際使用前仍要回到各專案的官方文件確認。 有些情境甚至不需要 Fine-tune。你只要給它： 一段你的聲音 一段新的文字 它就可以直接嘗試用你的音色把文字說出來。 這讓克隆音慢慢從「模型訓練專案」，變成「可以被工作流直接呼叫的元件」。 對我來說，理想的介面不是讓剪輯系統知道底下使用哪一套模型，而是把底層差異藏起來： 12345請用我的聲音念這段文字 ↓ Voice Engine API ↓ 回傳 WAV 或音訊檔 為什麼我現在最想研究地端克隆音？如果要把克隆音塞進自動剪影片流程裡，地端有很多優勢。重點不只是省 API 費用，更重要的是控制權。 我可以自己決定： 腳本怎麼切句 一次生成多少字 情緒怎麼控制 專有名詞怎麼唸 要不要快取 生成失敗怎麼重試 哪些段落要重新生成 如何把引擎包成 REST API 最後，剪輯系統根本不用知道底下是哪一套模型。它只要送出文字與必要參數，拿回一段可以繼續進入剪輯流程的音訊。 這種抽象層很重要。今天底層是 IndexTTS，明天換成 Qwen3-TTS，甚至某一批任務改走雲端 API，上層的影片工作流都不必整套重寫。 MacBook 也能先把 Prototype 跑起來這是我最近覺得很有意思的地方。 以我目前看到的 IndexTTS-2.5 使用情境來說，它已經能在 Apple Silicon 的 MPS 環境進行推論。也就是說，M1、M2、M3、M4 這些 Mac，都有機會直接拿自己的 GPU 做實驗。 我自己的 MacBook Pro M2 Pro、16GB Unified Memory，也可以先拿來做 Prototype。 當然，16GB 記憶體不算多。如果一次生成很長的旁白，或同時開著許多應用程式，記憶體仍然會吃緊。這裡的重點不是宣稱 Mac 可以取代所有 GPU Server，而是： 30 秒短影音 1 分鐘旁白 課程分段音訊 這些任務已經足以讓個人開發者研究整條流程，先驗證切句、快取、重試與剪輯串接，再決定是否需要更大的硬體。 換句話說，不一定要先買 RTX 4090，也不一定要一開始就租 GPU Server。一台手邊的 Mac，就可以先把 Voice Engine 的 Prototype 跑起來。實際效能仍會受到模型版本、量化方式、音訊長度、背景程序與安裝環境影響。 評估克隆音，真正的重點不只是「像不像」以前評估克隆音，我們可能只問： 像本人嗎？ 但真正要放進內容工廠，至少還要再問： 台灣國語自然嗎？ 情緒夠不夠自然？ 長文會不會開始飄？ 停頓是不是像真人？ 專有名詞會不會亂唸？ 同一個 Voice 能不能跨語言使用？ 生成速度夠不夠快？ 「85% 像本人」可能還不夠。如果它每次都把 Claude 唸錯、Gemini 唸得怪怪的、ComfyUI 亂念，或把 n8n 的讀法弄得不一致，影片仍然會出戲。 所以我甚至開始想做一份自己的專有名詞發音字典。腳本進入 TTS 之前，先自動做文字前處理： 名詞 預期處理 Claude 固定適合旁白的讀法 Gemini 固定適合旁白的讀法 Anthropic 固定適合旁白的讀法 n8n 固定適合旁白的讀法 這些讀法不一定要交給模型臨場猜，而是先在 TTS 前統一替換或標記。久了以後，這套 Voice Engine 不只會越來越像我的音色，也會越來越接近我的內容風格。 如果你也在處理影片聲音，可以先參考短影音音效怎麼選？從剪映內建到 AI 生成，一次搞懂 SFX 工作流。克隆旁白解決的是「誰在說」，SFX 與混音則決定觀眾「聽起來感覺如何」，兩者應該放在同一條聲音工作流裡設計。 把「我是誰」和「我要怎麼說」拆開這件事對自動剪影片非常重要。 一支短影音不可能從頭到尾都使用同一種情緒： 開頭 Hook 可能要比較興奮 中段解釋要穩定清楚 提醒風險時要嚴肅 講到反差時可能要驚訝 最後 CTA 又要比較親切 因此，Voice Engine 可以拆成兩層： 我是誰： 聲音的音色、辨識度與個人品牌特徵。 我要怎麼說： 情緒、語速、停頓、重音與表達方式。 理想的流程會是： 1234567891011腳本 ↓AI 理解內容 ↓判斷每一段情緒 ↓選擇語速與表達方式 ↓克隆音生成 ↓送進剪輯流程 這時候 AI 就不只是單純「念稿」，而是開始理解：這句話應該怎麼說。 不想自己維護模型，雲端 TTS 也已經很成熟地端是我目前很想研究的方向，但如果不想自己維護模型，雲端方案其實已經很方便。以我目前的觀察，值得放進測試清單的包括： ElevenLabs MiniMax Fish Audio Qwen／CosyVoice Cloud Cartesia PlayHT Resemble AI Google Chirp 3 Azure Custom Voice HeyGen Synthesia 每一家定位不一樣，這份清單是研究與選型的起點，不是永久排名。若要找一個成熟基準，我會先看 ElevenLabs；如果主要做中文短影音，我會想測 MiniMax；如果在意情緒、角色感、Podcast 或漫劇，Fish Audio 會是值得研究的方向；如果以後要做即時 Voice Agent，則可以研究 Cartesia。 雲端最大的好處是不用自己處理： CUDA MPS 記憶體配置 模型環境損壞 硬體升級 API Key 拿到就可以接。對大量生產來說，這確實很省事；但費用、資料處理政策、延遲、速率限制與語音授權，仍然要依各家最新方案確認。 地端和雲端不是二選一，而是混合式 Voice Engine所以我現在反而不覺得這是一場「地端 vs 雲端」的戰爭。更合理的做法，可能是建立一層混合式 Voice Engine： 任務情境 可以優先測試的方向 平常的短影音與開發測試 地端 IndexTTS、Qwen3-TTS 或 Chatterbox 突然出現大量任務 切換 MiniMax API 英文或多語言內容 切換 ElevenLabs 情緒較重的內容 測試 Fish Audio 即時 AI Agent 對話 研究 Cartesia 這個概念其實跟現在使用 LLM 很像。我們已經不太會只問：「全世界最好的 AI 模型是哪一個？」而是開始問：「這個任務，現在應該用哪一個模型？」 未來 TTS 很可能也會一樣。真正重要的不是押中唯一答案，而是把模型做成可以替換的底層能力，讓上層工作流按照任務、成本、延遲、語言與情緒需求選擇引擎。 Voice Conversion：先把話說好，再換成我的聲音這次研究時，我看到 Seed-VC 這類 Voice Conversion 技術，反而讓我產生另一個想法。 也許不一定要要求同一套 TTS 同時做到： 聲音像我 情緒自然 節奏漂亮 表達生動 全部一次完成。 可以拆開處理：先找一個最會「說話」的 AI，讓它負責情緒、節奏、停頓與表達，再用 Voice Conversion 把聲音換成我的音色。 1234567最佳 TTS ↓先把話說好 ↓Voice Conversion ↓換成我的聲音 這個思路很有意思，因為它把「講得好」和「像我」拆成兩個不同問題。有時候，拆開反而更容易做到，也更容易針對每一段找出可以改善的地方。 我真正想做的，是自己的 Voice Layer所以我現在真正想做的，其實不是找最好用的克隆音。 我想做的是自己的Voice Layer。 未來不管是： 短影音 線上課程 Podcast AI 新聞 數位分身 AI Agent 互動式課程 全部都可以呼叫同一層聲音服務。 輸入文字以後，它自己決定： 該用哪個 Voice Engine 該用什麼情緒 語速多少 專有名詞怎麼念 是否需要快取或重新生成 最後回傳一段聽起來像我的聲音。 到了這一步，克隆音就不再只是一個 AI 工具，而會變成個人品牌的一層基礎設施。 我現在越來越覺得，AI 自動剪片真正的最後一哩，不是剪輯，而是： 讓整套系統，真正開始用你的聲音說話。 常見問答 (FAQ)Q1：什麼是個人的 Voice Layer？Voice Layer 是放在內容工作流和底層 TTS／Voice Conversion 模型之間的一層聲音服務。它可以統一處理音色、情緒、語速、專有名詞、快取、錯誤重試與模型切換，讓影片、課程、Podcast 或 AI Agent 都用同一個介面呼叫聲音能力。 Q2：做地端克隆音一定要先買 RTX 4090 嗎？不一定。以文章中的 Prototype 情境來說，Apple Silicon Mac 的 MPS 可以先用於短影音、短旁白或課程分段音訊測試；但長音訊、批次任務和多工執行仍可能受到 16GB Unified Memory 等硬體限制，實際速度要依模型版本與設定測試。 Q3：地端 Voice Clone 和雲端 TTS 應該怎麼選？如果在意資料控制、成本可預測、切句與重試邏輯，地端比較適合做日常與 Prototype；如果需要大量生產、快速接 API 或多語言服務，雲端比較省維護成本。更彈性的做法是建立混合式 Voice Engine，依任務切換不同引擎。 Q4：克隆音怎麼避免把 Claude、Gemini 或 n8n 唸錯？可以在文字送進 TTS 前建立專有名詞發音字典，先把 Claude、Gemini、Anthropic、n8n 等詞轉成固定讀法或標記，再進行語音生成。這比每次都讓模型自行猜讀音，更容易維持影片之間的一致性。 Q5：Voice Conversion 和 TTS 有什麼差別？TTS 主要負責把文字說成語音，通常也會處理語速、情緒、停頓與表達；Voice Conversion 則是在已有語音表現的基礎上轉換音色。兩者可以拆開使用：先用擅長表達的 TTS 把話說好，再用 Voice Conversion 換成個人音色。