跳到主要內容

部落格

不定期分享最新資訊文章

  • article-2026 數位廣告變了:兩年沒認真研究廣告,我回來一看「靠北,已經是另一個世界」

    2026/9/2

    商業策略 AI自動化 Meta Ads
    2026 數位廣告變了:兩年沒認真研究廣告,我回來一看「靠北,已經是另一個世界」

    這兩年,我把大量時間放在 AI、系統開發、自動化、內容與 SEO 上。 廣告反而真的比較少碰。 最近因為發現 GA4 居然已經可以直接串 Meta Ads、TikTok Ads 的廣告成本,我才開始回頭補這兩年的廣告更新。 結果越補越覺得: 靠北,我錯過的根本不是幾個新功能,而是整個「數位廣告怎麼玩」的底層邏輯,都快換了一輪。 先說明一下:本文提到的 Advantage+、Andromeda、AI Max、Symphony、GMV Max 等功能與名稱,會隨平台版本、帳戶、地區和方案調整。這篇文章真正想整理的,不是功能清單,而是 2026 年重新看廣告時,應該如何理解「產品、素材、資料與 AI 投放系統」之間的關係。 一、我錯過的不是幾個功能,而是廣告的底層邏輯1. 受眾設定正在退居二線以前做 Facebook 廣告,我們很愛研究受眾: 興趣怎麼切? 年齡怎麼拆? Lookalike 要幾 %? 再行銷怎麼分層? 廣告高手很大一部分的能力,是「我比別人更會找人」。 但 Meta 這兩年的方向非常明顯:你不要找了,讓 AI 找。 Advantage+ 不斷把受眾、版位、預算與素材最佳化自動化。更底層的改變,則是 Meta 在 2024 年底公開的 Andromeda——一套新的廣告推薦引擎。 簡單講,以前我們比較像是: 我先告訴 Meta 我要找誰,再讓 Meta 從裡面找可能會買的人。 現在越來越接近: 我把商品、素材與轉換資料給 Meta,讓它自己決定這個東西現在最適合給誰看。 所以我覺得,未來廣告人的核心能力,正在從 Targeting 慢慢轉成: Signal + Creative + Offer 不是你多會按受眾,而是你給演算法什麼訊號。 2. 素材不只是廣告外皮,而是 Targeting 本身以前我們會說:先選受眾,再做適合這群人的素材。 現在這兩件事情正在融合。 你拍一支「新手第一次買房最容易踩的三個坑」,跟你拍一支「資產 3,000 萬以上的人,買房最在意什麼」,演算法本身就能從內容、互動、觀看、轉換訊號中,逐漸理解這兩支素材適合誰。 換句話說:素材本身正在成為受眾訊號。 這也解釋了為什麼現在廣告越來越強調 Creative Diversification。 以前是: 一個受眾,測很多素材。 未來可能越來越像: 給系統大量不同 Angle、Hook、Persona、Format 的素材,讓 AI 自己完成「素材 × 人 × 時機」的配對。 所以素材量的重要性,比兩年前又更高了。但「素材多」不是把同一張圖片換 30 個背景,而是提出 30 個不同的市場假設。 3. AI 已經不只是幫你寫廣告文案Meta 已經可以用生成式 AI 做素材延展、尺寸調整與創意變體。Google 把 Gemini 放進廣告系統。TikTok 的 Symphony 則開始處理: 文字生成影片 圖片生成影片 商品生成影片 Avatar 配音 翻譯 從商品網址產生廣告素材 2026 年 TikTok 又推出 Symphony Agent,開始往「AI 幫你理解趨勢、想創意、找 Creator、產素材」的方向走。Google 也把 Veo 等生成能力放進廣告素材工具。 所以兩年前我們講「用 AI 幫忙做廣告」,現在比較接近:AI 本身開始成為廣告製作系統的一部分。 這差非常多。 4. Google Search Ads 也不是以前認識的 Search Ads 了以前搜尋廣告的世界很直覺: Keyword → Search Query → Ad → Landing Page 廣告人的重要工作就是關鍵字、Match Type、Negative Keyword、出價與廣告文案。 但 Google Search 本身正在 AI 化。AI Overviews、AI Mode、Lens 與多模態搜尋出現之後,「搜尋」已經不一定是一個短短的 Keyword。 Google 推出的 AI Max for Search,方向就是讓 AI 協助擴展搜尋意圖、動態調整文案與選擇 Landing Page。傳統 Dynamic Search Ads 也逐步往 AI Max 的方向遷移。 所以 Google Ads 也正在從: 我買哪些 Keyword? 慢慢走向: 我的產品、網站、素材與轉換訊號,能不能讓 AI 正確理解我要賣給誰? 這其實跟 SEO 最近發生的事情很像。若你也在處理 AI 搜尋,可以延伸閱讀「SEO 轉型攻略:AEO 與 GEO 時代的 AI 內容優化實戰指南」。 5. Performance Max 開始補黑盒子的洞我以前對 PMax 最大的不爽就是:你叫我把錢給你,然後叫我相信 AI。 到底錢花去哪裡?哪些搜尋有效?哪些素材有效?哪些受眾有效?以前真的看得很痛苦。 但這兩年 Google 一邊推 AI 自動化,一邊也在補控制權,包含: Campaign-level Negative Keywords Brand Exclusions Demographic Exclusions Search Terms Insights 更多素材與 Channel Reporting 這透露出一個有趣的方向:廣告平台不是停止自動化,而是開始研究怎麼讓人類「控制 AI」。 我覺得這才是未來廣告操作真正需要學的能力:不是跟 AI 搶方向盤,而是知道什麼時候該給 AI 開,什麼時候要把它拉回來。 6. TikTok 已經不只是買流量TikTok 這兩年也非常值得重新研究。 Smart+ 越來越像 TikTok 版的 Advantage+ 或 Performance Max,系統幫你處理受眾、版位、素材與最佳化。TikTok Shop 又有 GMV Max;到了 2026 年,甚至出現 Agentic Hub,可以透過 AI Skills 協助建立、管理、分析與最佳化廣告。 這件事情最值得注意的不是功能名稱,而是三大廣告平台最後居然走向同一條路: 平台 自動化產品方向 系統期待你提供的東西 Meta Advantage+、Andromeda 商業目標、素材、商品與轉換資料 Google Performance Max、AI Max 產品、網站、素材與轉換訊號 TikTok Smart+、GMV Max、Agentic Hub 商品、內容、目標與成效資料 名字不同,方向幾乎一樣:你給我商業目標、素材、產品與資料,剩下讓 AI 幫你跑。 7. 平台從流量最佳化走向商業結果最佳化以前我們餵平台的是 Click、Lead、Purchase。 現在越來越多平台想知道:這個客戶值多少錢?是不是新客?是不是高價值客戶?這筆轉換到底是不是廣告帶來的增量? Meta 開始往 Incremental Attribution 發展;Google 則持續往 Conversion Value、New Customer Acquisition 與 Value-based Bidding 發展。 廣告平台真正想學的,已經不只是「誰會買」,而是: 我應該把有限的廣告預算,花在哪一個人身上,才能替企業增加最多真正的商業價值? 這是完全不同的問題。 8. 歸因終於開始承認大家都有問題廣告產業最荒謬的一件事情就是: Meta 說這個訂單是我的。 Google 說也是我的。 TikTok 可能也說有我的功勞。 每一個平台的 ROAS 都很好看。全部加起來,公司應該賺爛了。 財報打開:咦? 所以當我看到 GA4 開始可以直接把 Meta、TikTok、Pinterest、Reddit、Snap 的 Cost、Clicks、Impressions 拉進來時,覺得特別有意思。 這不能解決所有 Attribution 問題,但是方向很重要:我們終於開始從「平台說自己多厲害」,走向「把大家放到同一個 Measurement Framework 裡比較」。 這時候以前大家懶得管的 UTM、CAPI、Enhanced Conversions、First-party Data 與 CRM Data,重要性全部跑出來了。 9. 廣告操作員的價值正在重新定義把這兩年的東西補完之後,我最大的感覺反而不是「AI 好厲害」,而是以前很多我們認為叫做「廣告技術」的東西,正在快速商品化: 切受眾 調版位 分預算 調 Bid 產文案 Resize 素材 甚至產影片 這些事情 AI 都越來越能做。 所以如果一個廣告人的價值只剩「我很熟 Ads Manager」,未來會非常危險,因為平台自己正在努力消滅這些操作。 反而真正越來越值錢的能力是: 你知不知道客戶為什麼買? 你能不能設計 Offer? 你能不能找到不同的 Creative Angle? 你能不能建立正確的 Conversion Signal? 你能不能判斷平台說的 ROAS 到底是不是真的? 你能不能把廣告、CRM、網站、營收與 LTV 串在一起? 如果要用一句話總結這兩年廣告發生什麼: 廣告正在從「人操作平台」,進入「人提供策略與訊號,AI 操作平台」的時代。 二、2026 年重新學 Meta Ads:以前教的哪些東西已經退居二線?前一節談的是整個數位廣告產業的方向,這一節把焦點縮回 Meta Ads,重新檢查以前那些很熟悉的操作觀念。 1. 興趣受眾沒死,但已經不是主角以前投廣告,很大一部分時間都花在猜「我的客戶對什麼有興趣?」 賣健身課程,就切健身、減脂、重訓、蛋白粉;賣行銷課程,就切數位行銷、創業、Facebook Marketing,然後一直拆 Ad Set。 以前這叫精準,現在有時候反而是在限制演算法。 Meta 手上有瀏覽、觀看、停留、互動、點擊、購買與轉換等大量行為訊號,再加上 Advantage+ Audience。現在比較合理的思維是:把受眾設定當成提示,而不是答案。 你可以告訴 Meta「我覺得這群人可能會買」,但不要再執著「只有這群人才會買」。 2. Lookalike 還活著,但地位下降了上傳顧客名單、建立 1% Lookalike,再建立 2%、3%、5%,這套方法到現在當然還能用,Custom Audience 也沒有消失。 但它已經從核心 Targeting 武器,慢慢變成演算法的其中一個 Signal。 真正重要的問題不再只是「我的 Lookalike 幾 %」,而是「我拿什麼資料給 Meta?」 100 個亂七八糟的 Lead,跟 100 個真的成交、甚至高 LTV 的客戶,都是 100 筆資料,但價值完全不同。 3. 超細受眾切割,很多時候真的可以放下了以前一個 Campaign 裡可能有:男性 25–34、男性 35–44、女性 25–34、興趣 A、興趣 B、Lookalike,Retargeting 再各自分層。最後 Ads Manager 看起來超級專業,二十幾個 Ad Set 排得整整齊齊。 現在回頭看,很多時候其實只是把資料切碎:每一組都只有一點預算,每一組都沒有足夠 Conversion Signal,每一組都在重新學習。 結果不是幫 Meta,而是在妨礙 Meta。 我的理解會偏向:能合併,就不要為了「看起來很會投廣告」硬拆。尤其預算不大的帳號更是如此。 4. ABO 與 CBO 還能討論,但不是最值得吵的問題ABO 與 CBO 到現在仍有各自的使用情境。如果要做比較受控的測試,我可能還是會想控制預算;但如果目標是「我有 10 萬元,幫我找到最多轉換」,越來越多決策本來就會交給演算法。 所以我現在反而會問:你為什麼要控制這筆預算? 如果答案只是「因為我以前都這樣投」,那就值得重新思考。 5. 廣泛受眾從偷懶投法變成正常策略以前如果跟客戶說「我受眾沒設什麼,直接 Broad」,客戶可能會想:那我找你幹嘛? 現在 Broad 反而越來越合理,因為 Broad 不代表 Meta 隨機亂撒。真正的 Targeting 發生在你看不到的地方:系統會根據素材、轉換事件、歷史資料、網站訊號、帳號行為與預測模型,持續決定下一次 Impression 應該給誰。 所以 Broad 真正的意思不是「我沒有 Targeting」,而是「我把 Targeting 的一部分交給模型」。 6. 素材測試重要性不減反增看到 Advantage+、Andromeda 與 AI 自動化,最容易得到的錯誤結論是:「那以後什麼都給 AI 就好了。」 完全相反。 當 Targeting 越自動化,Creative 的重要性反而越高。因為你可以控制的變數正在減少,真正可以製造差異的地方變成: Hook、Angle、Offer、Persona、Pain Point、Visual、Format、Story。 一支影片講「AI 可以幫你省時間」,另一支講「每天加班兩小時的人,其實都在做 AI 可以完成的事情」。產品一樣、受眾可能一樣,但後者本身就帶著完全不同的受眾訊號。 我現在會把素材理解成: Creative is Targeting. 素材不只是拿來吸引人的,它本身就在告訴演算法「什麼人會對這個訊息有反應」。如果你正在建立短影音素材系統,也可以參考建立你的短影音定位策略:用對內容才會被看見。 7. 一支神素材打天下,這個觀念反而更危險以前很愛找 Winning Creative。找到一支 ROAS 很高的,就複製、加預算、繼續操,操到死為止。 現在這個概念需要升級。不是 Winning Creative 不重要,而是演算法越強、素材生成成本越低之後,真正重要的開始變成 Creative Portfolio。 你需要的不是 20 支長得差不多的影片,而是: 不同 Persona 不同 Pain Point 不同 Hook 不同 Offer 不同使用情境 不同證據 不同敘事方式 「素材多」不是叫 AI 把同一張圖片換 30 個背景,那只是 30 個檔案,不是 30 個 Creative Concepts。 8. Pixel 沒有死,但只裝 Pixel 已經不夠了以前網站裝 Pixel,看到 Purchase 有回傳,大家就覺得好了。 現在如果真的重視廣告成效,就不能只想 Browser-side Tracking。瀏覽器限制、Cookie、iOS、Ad Blocker 與 Consent 都可能讓資料流失。 因此 Pixel 加上 Conversions API,已經是更完整的思考方式:一邊從 Browser 傳,一邊從 Server 傳,再透過 Event ID 等機制處理 Deduplication。 這背後真正重要的不是 CAPI 這三個字,而是 First-party Data Infrastructure:你的網站、CRM、會員、訂單與 Server,能不能把真正有價值的商業結果回傳給廣告系統? 這會直接影響 AI 最後學到什麼。 9. Purchase 也不是最終答案假設 A 客人買 399 元,B 客人買 30,000 元,C 客人第一次買 1,000 元但未來一年買 100,000 元。 如果三個人在廣告系統裡都只是 Purchase = 1,其實就丟掉了很多商業資訊。 所以更值得研究的是: Conversion Value Customer Value New Customer LTV Offline Conversion CRM Signal 這也是為什麼我覺得,廣告技術正在慢慢變成資料工程問題。 10. ROAS 不要完全相信平台自己講的Meta 說「這個人看過我的廣告,所以這筆訂單算我的」;Google 說「他搜尋之前點過我,所以也是我的」;其他平台也可能說自己曾經出現過。 最後 Meta ROAS 6、Google ROAS 8、TikTok ROAS 4,全部加起來公司應該準備上市。財報卻只會問:「你們到底在供三小?」 所以現在更需要在意 Incrementality,也就是: 如果我沒有投這筆廣告,這筆訂單還會不會發生? 這和 Attribution 是兩個不同問題: 問題 它想知道什麼? Attribution 這筆訂單算誰的? Incrementality 沒有這個廣告,這筆訂單還存在嗎? 後面這個問題,其實更接近老闆真正想知道的事情。若要先從行銷漏斗整理問題,可以延伸閱讀用 ChatGPT 解剖你的行銷漏斗,找出真正的痛點。 11. Retargeting 還有用,但不要把它想成魔法以前 Funnel 很漂亮: Cold Audience → Warm Audience → Retargeting → Purchase 所以我們會建立看過影片 25%、互動過粉專、網站訪客 30 天、Add to Cart 14 天、Checkout 7 天,然後每一層都建一個 Ad Set。 這套方法不是完全不能用,而是今天 Meta 本身已經能跨大量 Signal 做最佳化,很多帳號未必還需要切成這麼漂亮的「漏斗藝術品」。 真正要問的是:這個切割有沒有產生額外價值?而不是「因為 Funnel 教科書長這樣」。 12. 廣告投手到底還剩下什麼?Targeting、Placement、Bidding、Budget Allocation、Creative Variation、Copy,甚至圖片與影片,都越來越能交給 AI。 但真正的廣告高手反而會更值錢,只是值錢的地方換了。 以前我們賣的是平台操作能力;未來真正值錢的可能是商業判斷能力: 你知不知道誰會買? 你知不知道他為什麼買? 你知不知道真正的競爭對手是誰? 你能不能設計更好的 Offer? 你能不能做出 10 個真正不同的 Creative Angle? 你知不知道該回傳什麼 Conversion Signal? 你知不知道平台的 ROAS 有沒有在唬爛你? 你能不能把 Ads、Website、CRM、Revenue、LTV 接起來? 2026 年重新學 Meta Ads,第一堂課我可能不會先打開 Ads Manager,而是先講:不要再把 Meta Ads 當成一個廣告投放工具,它現在比較像是一個大型 AI 推薦系統。 你的工作不是一筆一筆告訴它「廣告要給誰看」,而是設計一個系統,持續給它好的產品、好的 Offer、好的 Creative、好的 Conversion Data 與好的 Business Signal。 三、如果重新投 Meta 廣告,我不會再建立一堆廣告組合知道 Meta 廣告變了之後,下一個問題一定是:如果今天真的拿錢出來投,到底要怎麼投? 假設網站、Pixel、CAPI 都準備好了,也有基本的購買資料,我分別拿每天 1,000 元、3,000 元與 10,000 元重新投一次 Meta Ads,會怎麼做? 先講最大的原則:2026 年,我會比以前更努力讓帳戶變簡單。 不是因為我懶,而是現在真正需要複雜的地方,已經從 Campaign Structure 移到 Creative、Offer 與 Data 了。 每天 1,000 元:拜託不要切了以前可能會忍不住建立興趣一組、Broad 一組、Lookalike 一組、Retargeting 一組,每組再塞三支素材。 看起來超級專業,但你一天只有 1,000 元,切四組之後每組 250 元,還期待 Meta 幫你學出什麼東西。 這有點像給四個業務員每人 250 元,叫他們出去開發市場,晚上再開會檢討誰比較強。 如果是我現在做,反而會非常單純: 一個主要 Sales Campaign 受眾盡量 Broad 最佳化真正想要的 Conversion 把大部分精神放到 Creative 素材可以準備痛點型、利益型、故事型、見證型、比較型、UGC 型與 Demo 型,搭配不同 Hook。 不是建立八個 Ad Set,而是建立八個不同的說服理由。 因為一天只有 1,000 元,我最怕的不是 Meta 找錯人,而是根本沒有足夠資料讓它學。 每天 3,000 元:開始建立 Creative System到了這個預算,我才會開始增加一些結構,但不是為了把受眾切得更細,而是為了回答不同問題。 例如: 主要 Campaign 負責 Scale 另外保留一小部分預算,專門做 Creative Testing 這兩個目的完全不同。 Scale Campaign 問的是「現在誰最能替我賺錢?」;Creative Testing 問的是「下一個可以替我賺錢的素材是什麼?」 很多人把這兩件事情混在一起,所以每次看到某支素材花不到錢,就說「Meta 不公平,它根本沒有測!」 其實 Meta 本來就沒有義務公平。它的工作不是當科展評審,而是替你的預算找最大機率的結果。 所以如果真的需要理解 Hook A 和 Hook B 到底誰比較強,我會另外設計測試,不會期待 Delivery System 自己幫我完成科學實驗。 每天 10,000 元:開始在意 Creative Research System一天 10,000 元,一個月大概就是 30 萬。這時候我在意的已經不是 Campaign 數量,而是我們每週可以提出多少個不同的市場假設。 同一個產品,可能有不同的 Persona: 老闆買,是為了省人力。 行銷買,是為了提高產能。 業務買,是為了多成交。 員工買,是為了不要加班。 主管買,是為了管理效率。 五個 Persona,就可能有五套完全不同的 Creative Angle。 再往下拆,也可能有怕麻煩、怕浪費錢、怕學不會、怕被淘汰、想賺更多、想省時間等不同 Motivation。 這時候素材已經不是「設計部幫我做幾張 Banner」,而是一套 Creative Research System。 一個 Ad Set 放幾支素材,不如先問它們有沒有真的不同三支、五支、八支都不是固定答案。我會先問:這五支到底有沒有真的不一樣? 如果只是同一個文案、同一個商品、同一個賣點,換五張背景,對人類來說有五個檔案,對市場來說可能只有一個 Idea。 真正有意義的五個 Creative,可以是: Creative 說服角度 A 用了之後可以得到什麼? B 不用會損失什麼? C 別人用了得到什麼? D 為什麼以前的方法錯了? E 直接 Demo 給你看。 我甚至會建立一張 Creative Matrix。 橫軸放 Persona,縱軸放 Pain Point、Desire、Objection、Use Case 與 Proof,然後開始組合:老闆 × Pain Point、老闆 × Proof、新手 × Objection、專業人士 × Use Case。 再搭配短影音、UGC、圖片、輪播、Demo 與 Testimonial,素材就不只是「這週要交五支影片」,而是「這週要驗證五個市場假設」。 這個差別非常大。 Conversion Signal 才是很多廣告課講太少的地方假設今天兩家公司都花 30 萬廣告費,Creative 差不多,產品也差不多。 第一家公司只告訴 Meta:有人 Purchase。 第二家公司告訴 Meta:Purchase、Purchase Value、新客戶、高價值客戶、CRM 成交、Offline Conversion,甚至後續 Customer Value。 長期下來,哪一個 AI 比較有機會找到真正值錢的人?答案其實很直覺。 所以我現在會把 Pixel、CAPI、CRM、GA4、UTM 與訂單資料全部當成廣告系統的一部分,不是報表做漂亮而已。因為這些資料最後都可能影響 AI 到底學到了什麼。 不只看 Ads Manager,要建立三層成效判斷Ads Manager 當然還是看,但我不會只看 Ads Manager,至少會拆成三層: 層級 指標範例 用途 Platform Metrics CPM、CTR、CPC、CPA、Platform ROAS 操作廣告與找出異常 Analytics Metrics GA4 Conversion、Revenue、Source / Medium、跨渠道成本 比較不同渠道 Business Metrics 真實訂單、毛利、新客成本、回購、LTV、總營收 判斷企業真正結果 這三層數字一定不會完全一樣,沒關係。重點是你知不知道為什麼不一樣。 ROAS 不是最後答案,尤其當預算開始變大假設廣告 A 的 ROAS 是 8,廣告 B 的 ROAS 是 4,以前很簡單:A 勝,預算加 A。 但是如果 A 全部都是本來就會買的老客戶,B 帶進來大量第一次購買的新客戶,而且這些新客戶一年平均會再買三次,那誰比較值錢?突然就不一定了。 所以預算越大,我會越想知道: New Customer CAC Contribution Margin LTV Incrementality 而不只是 Ads Manager 裡面那個漂亮的 ROAS。 Retargeting 要不要另外開?看商業邏輯答案不是一定要,也不是一定不要。 以前 Cold、Warm、Hot 一定要切,現在我不會為了讓 Funnel 看起來漂亮,硬拆一個每天只有幾百人的 Retargeting Audience。 但如果今天有特殊 Offer、棄單優惠、高客單商品、Lead Nurturing 或特定 Customer Journey,我還是可能拆。 原則只有一個:因為商業邏輯需要,所以拆;不是因為老師以前說 Funnel 要三層。 四、把 Meta Ads 看成一個 Learning Loop如果要我畫 2026 年 Meta Ads 的架構,我現在腦袋裡大概會長這樣: Market → Offer → Creative System → Meta AI Delivery → Website / Landing Page → Pixel + CAPI → CRM / Order Data → GA4 / Measurement → Revenue / LTV → 把好的 Signal 餵回去 它已經不只是一個廣告 Campaign,而是一個 Learning Loop。 你的產品與素材,教 Meta 哪些人可能有興趣;使用者的行為,教 Meta 哪些人可能會轉換;訂單與 CRM,再告訴 Meta 哪些轉換其實比較值錢。下一輪,AI 再重新分配曝光。 所以我現在越來越覺得,2026 年真正厲害的廣告人,不一定是 Ads Manager 裡面按得最快的人,而是那個可以把: 市場 → 素材 → 廣告 → 網站 → 資料 → 營收 → AI 全部串成一個循環的人。 以前我們叫這件事情「投廣告」,現在回頭看,它其實越來越像在訓練一套替公司找客戶的 AI 系統。 結語:工具變複雜,行銷核心反而變簡單兩年沒看廣告,回來一次補完,突然覺得還滿有趣的。 因為繞了一大圈,當平台把 Targeting、Bidding、Placement 與 Creative Production 全部慢慢自動化之後,最後真正拉開差距的,居然又回到最古老的那些問題: 你賣什麼? 你賣給誰? 他為什麼要買? 你要用什麼角度說服他? 工具變得非常複雜,但行銷的核心,好像反而又變簡單了。 常見問答 (FAQ)Q1:2026 年投 Meta Ads,還需要設定興趣受眾與 Lookalike 嗎?可以使用,但不必再把它們當成唯一答案。興趣受眾與 Lookalike 比較適合被視為提供給模型的提示或訊號;實際成效仍會受到素材、轉換事件、網站資料、Offer 與帳戶歷史學習影響。 Q2:每天只有 1,000 元的 Meta 廣告預算,應該怎麼開始?建議先維持一個主要 Sales Campaign,受眾盡量 Broad,最佳化真正想要的 Conversion,並把主要精力放在測試不同的 Creative Angle、Hook 與說服理由,避免把有限預算切成太多 Ad Set。 Q3:Pixel 與 Conversions API 有什麼差別?Pixel 主要從瀏覽器端回傳事件,Conversions API 則從伺服器端回傳事件。兩者搭配並使用 Event ID 做 Deduplication,可以建立較完整的轉換資料回傳,但仍需同步處理 Consent、資料品質與事件設計。 Q4:為什麼不能只看 Meta Ads Manager 的 ROAS?平台 ROAS 是依照平台自己的歸因規則計算,可能和 GA4、真實訂單、毛利、新客成本與 LTV 不一致。更完整的判斷方式,是同時比較 Platform Metrics、Analytics Metrics 與 Business Metrics,並進一步觀察 Incrementality。 Q5:素材測試和廣告放量應該放在同一個 Campaign 嗎?不一定。放量 Campaign 的任務是替目前預算找最大機率的結果;Creative Testing 的任務是回答下一個有效素材或市場假設是什麼。如果需要比較 Hook、Angle 或 Persona,最好設計相對獨立的測試,避免期待投放系統自動完成公平的科學實驗。

  • article-學 AI 影片,你最不該做的,可能是先去學怎麼當導演

    2026/8/30

    AI自動化 AI工具 影音行銷
    學 AI 影片,你最不該做的,可能是先去學怎麼當導演

    最近 AI 影片越來越強。 Seedance、Google Flow、Veo 這些工具出現之後,我發現一個很有趣的現象:很多人在學 AI 影片時,第一個反應竟然是—— 我要不要先學攝影? 我要不要學分鏡? 我要不要學景別與運鏡? 我要不要先去上導演課? 但我最近反而越來越覺得:如果你的目標是做 AI 短影音,最不需要做的事情,可能就是先把自己訓練成一個導演。 這不是因為導演不重要。恰恰相反,是因為導演本身是一門太專業、太完整的工作。 本文提到的 Seedance、Google Flow、Veo 與其他 AI 工具,是用來說明這個工作觀念的例子,不是永久性的工具排名。實際功能與品質仍會隨模型版本、方案與使用情境變動;真正值得留下來的,是你如何定義目標、判斷結果,以及指揮 AI 把作品完成。 先別急著把自己訓練成導演傳統影視教育有一套完整的知識體系:構圖、景別、鏡頭語言、燈光、場面調度、攝影機運動、剪輯、聲音與敘事。 這些知識當然都有價值。問題是:你真的需要全部學會,才有資格做 AI 影片嗎? 想想看,有了 Vibe Coding,你不需要先花一年把 Python、JavaScript、資料庫、前後端全部學完,才有資格請 AI 幫你做網站。 有了 Suno,你也不需要先學會和弦、編曲與完整樂理,才有資格做一首歌。 有了生成式 AI,你同樣不用先念完設計系,學完色彩學、排版與構圖,才能做一張社群圖片。 同樣的事情,正在發生在影片領域。 所以 AI 影片真正值得研究的問題,不是: 我要怎麼成為導演? 而是: 我要怎麼讓 AI 成為我的導演? 這個差別會改變你的學習順序。你不必先把所有專業技能都收集完,才開始創作;你應該先知道自己要達成什麼結果,再學會如何讓 AI 提出方案,最後判斷哪個方案值得留下。 導演知識仍然重要,但不必一次學完整套「不必先成為導演」很容易被誤解成「什麼都不用懂」。我認為也不是。 這就跟 Vibe Coding 一樣。真正厲害的人,不一定需要自己寫完每一行程式碼,但他通常看得出來 AI 哪裡寫得不好、哪裡不符合需求、哪裡可能造成風險。 AI 影片也是如此。你不一定要親自拍攝或操作攝影機,但最好能判斷: 為什麼這顆鏡頭沒有壓迫感? 為什麼人物看起來很假? 為什麼這個轉場的 AI 味很重? 為什麼角色明明沒有改變,下一個鏡頭卻像換了一個人? 為什麼故事此處應該緊張,觀眾看了卻完全沒有感覺? 你需要的不是完整的導演專業,而是足以看懂與驗收影片的基本素養。 AI Video Literacy 是什麼?我會把這種能力稱為 AI Video Literacy,也就是 AI 影片素養。 它不要求你親自完成所有拍攝工作,而是要求你能在 AI 參與製作時完成四件事: 能力 你需要做的事 看懂 看出畫面、節奏、角色與情緒是否符合預期。 判斷 分辨產出是有效解法,還是只是看起來很華麗。 指揮 把觀眾、情緒、故事與商業目標交代給 AI。 修正 找出失敗原因,提出下一輪更具體的調整。 這四件事比背熟多少個運鏡名詞,更接近 AI 時代的影片工作。 Prompt 應該從控制攝影機,轉向描述觀眾意圖以前我們寫 AI 影片提示詞,很容易寫成一張施工圖: 35mm 鏡頭,低機位,攝影機向右環繞,人物往左走兩步,鏡頭慢慢推近,接著快速切換特寫。 這種寫法並沒有錯。當你需要精準控制畫面、維持角色連貫,或模型還無法理解抽象指令時,具體的視覺描述仍然有用。 但如果模型本身已經越來越懂攝影、構圖與運鏡,另一種 Prompt 會變得更重要:不要只告訴 AI 攝影機怎麼動,也要告訴 AI 你希望觀眾感受到什麼。 例如: 前三秒必須讓觀眾感覺事情不太對勁。 人物表面非常有自信,但觀眾要比角色更早發現危險。 這一段需要逐漸增加壓迫感,最後兩秒突然反轉。 接下來才讓 AI 思考:要用低機位、推鏡、手持、快速切鏡、特寫,還是完全不同的方法? 這是一個重要轉變:從控制畫面,變成描述意圖。 好的 AI 影片工作流,不是永遠只用抽象描述,也不是把每一個畫面細節都寫死,而是先說清楚結果,再依照模型與任務需要補上視覺限制。順序可以是: 先定義觀眾與商業目標。 再描述希望觀眾產生的情緒與行動。 請 AI 提出腳本、分鏡與視覺方案。 人再挑選、修改並補充必要的攝影細節。 短影音的基本單位,可能已經不是鏡頭,而是注意力如果你今天做的是電影,當然可以研究電影導演;但如果你做的是 TikTok、Reels 或 Shorts,我反而會建議你多研究短影音創作者。 因為兩者面對的是完全不同的戰場。 電影導演思考的是: 這個故事怎麼說最好? 短影音創作者第一個問題卻是: 怎樣讓他不要滑走? 電影可以用五分鐘鋪陳一個角色,短影音可能連五秒都沒有。你的觀眾正躺在床上,一隻手拿著手機;上一支是美女,下一支是貓,再下一支是搞笑影片,而你的作品夾在中間。 他沒有義務理解你的藝術理念,甚至沒有義務給你十秒。 因此,短影音真正的基本單位,可能已經不是「鏡頭」,而是注意力。 我甚至會把「分鏡設計」重新稱為「注意力設計」。一支 30 秒短影音可以先用這樣的方式規劃: 時間 注意力任務 0–2 秒 停滑:讓觀眾立刻感覺有事情值得看。 2–5 秒 建立問題:讓觀眾知道自己為什麼要繼續看。 5–10 秒 第一次刺激:提供新的資訊、畫面或情緒變化。 10–18 秒 衝突升級:讓問題變得更難、更急或更意外。 18–25 秒 答案/反轉:回收前面的期待,或重新定義問題。 25–30 秒 高潮/CTA:把情緒推到最高點,再引導下一個行動。 這不是保證每支影片都有效的公式,而是一個讓你在安排鏡頭之前,先安排觀眾注意力的思考框架。 當你這樣看影片,景別、構圖與運鏡就會回到正確的位置:它們是工具,不是目的。真正的目的,是讓觀眾接下來三秒仍然想看。 如果你還在建立短影音的受眾與內容定位,也可以延伸閱讀本站的〈建立你的短影音定位策略:用對內容才會被看見〉,先把「誰會看」與「為什麼值得看」想清楚。 用五層能力,重新設計 AI 影片學習路徑如果要重新設計一套 AI 影片學習方法,我會把它拆成五層。這五層不是線性課綱,而是每一次製作都可以回頭檢查的順序。 1. Audience:誰會看?先不要急著問「要用哪個工具」,先問: 這支影片是給誰看的? 他現在處於什麼情境? 他為什麼會在這一秒停下來? 他看完之後,應該產生什麼理解或行動? 受眾不是影片完成後才拿來解釋成效的名詞,而是生成腳本與畫面之前的輸入條件。沒有受眾,AI 很容易做出所有人都看得懂、卻沒有人特別想看的內容。 2. Emotion:你要讓他感受到什麼?接著要決定主要情緒:好奇、害怕、爽、笑、驚訝、感動,或是其他更精準的感受。 情緒不是在 Prompt 裡塞幾個形容詞就完成了。你要知道情緒如何逐步發生:開頭先讓觀眾不安,中段讓他以為自己猜到了答案,最後再透過反轉改變理解。這些情緒變化,才是 AI 需要協助你設計的內容。 3. Story:怎麼讓人想知道結局?一支短影音不一定要有複雜劇情,但通常需要清楚的注意力路徑: Hook → 衝突 → 升級 → 反轉 → Payoff 這裡的 Hook 不只是第一句台詞或第一個畫面,而是觀眾願意繼續看下去的理由。衝突讓問題成立,升級讓觀眾不能太早離開,反轉重新安排理解,Payoff 則回收前面的期待。 如果故事本身沒有讓人想知道結局,再漂亮的 AI 畫面也可能只是短暫的視覺展示。 4. Visual:現在才讓 AI 規劃畫面到了這一層,才開始處理場景、角色、構圖、景別、運鏡、光影與視覺效果。 這時候導演知識就會變得很有用,但它的角色是「幫你判斷與溝通」,而不是一道必須先修完的入場考試。 你可以請 AI 根據前面三層提出多個版本,再檢查: 這個畫面是否真的服務情緒? 運鏡是否讓觀眾更接近衝突? 角色在不同鏡頭裡是否仍然一致? 視覺效果是否搶走了故事重點? 如果你想把這一層落成更具體的分鏡工作流,可以參考本站的〈用 AI 快速生成短影音?九宮格分鏡技巧解決人物變形〉。那是一種實作方法,不代表所有 AI 影片都必須使用九宮格。 5. Iteration:生成只是開始最後一層是 Iteration,也就是反覆迭代:生成、挑選、修改、A/B Test,再生成。 很多人把 AI 影片想成「Prompt 寫好,按下生成,作品完成」。但真正的製作能力,往往體現在你能不能看出第一版為什麼不對,並把問題轉成下一輪可執行的調整。 例如: 觀眾沒有停下來,可能是 Hook 不清楚,而不一定是畫質不夠高。 角色看起來不一致,可能需要先固定角色描述與參考素材,而不只是再加更多形容詞。 反轉沒有感覺,可能是前段沒有埋下足夠的期待,而不只是剪接速度太慢。 工具會換,模型會換,按鈕的位置也會換;但觀眾為什麼停下來、為什麼看完、為什麼分享與購買,沒有那麼快改變。 AI 短影音能力,是流量、故事、審美與 AI 的交集如果要重新定義 AI 短影音能力,我會把它寫成: AI 短影音能力 = 網紅的流量感 × 編劇的故事感 × 最低限度的導演審美 × AI 的執行力 你不需要變成 Joeman,也不需要變成電影導演,更不用先花三年把所有影視專業學完。 但你要開始知道: 什麼東西大家會看? 什麼故事大家會想知道結局? 什麼畫面看起來是好的? 什麼樣的節奏能讓人看完? 怎麼把這些意圖交給 AI? 這幾件事組合起來,才是能真正落地的 AI 影片能力。 下一步不只是 Vibe Filming,而是 AI 製片人現在的 AI 製片流程,大概還是: 人 → Prompt → AI → 影片 但再往下一個階段走,我認為可能會變成: 人 → 商業目標 → AI Agent → 完整影片 例如,未來你可能只需要說: 我要賣這盒中秋禮盒,TA 是 30–45 歲女性。請研究近期熱門的送禮短影音,整理爆款影片常見的 Hook,設計三個不同版本。每支 20 秒,前兩秒要能停滑,中間至少出現一次情緒反轉,最後導到 LINE。演員、場景、腳本、分鏡、B-roll、運鏡、音樂、字幕與剪輯節奏,請全部提出規劃。 接下來,Agent 可能協助完成研究爆款、分析模式、寫腳本、做分鏡、生成素材、配音、配樂與剪輯,最後把多個版本交給你比較。這裡描述的是一個未來工作流想像,不是對目前所有工具能力的保證。 到了那一天,人真正重要的工作,可能只剩下一件事:判斷。 這是不是我要的? 這是不是我的品牌? 這是不是我的觀眾會看的? 這是不是能達成我的商業目的? 所以 AI 時代,我們不一定每個人都需要成為導演,但每個人都要開始學會另一個角色:AI 製片人。 傳統導演想的是: 這顆鏡頭我要怎麼拍? AI 製片人想的卻是: 我要什麼結果? 誰會看? 我要讓他產生什麼感覺? 為什麼他會看完? AI,你給我三種最好的做法。 這可能才是 AI 影片真正的 Vibe Filming。 不是你把每一顆鏡頭都想清楚,再命令 AI 忠實執行;而是你知道自己要去哪裡,然後讓 AI 幫你找到更好的路。 結語:真正的差距在於判斷與指揮未來真正拉開差距的,可能不是誰最會下運鏡指令,而是誰最會提出意圖、判斷結果,然後指揮 AI 把作品做到最好。 這也是為什麼 AI 影片素養比「背熟某個工具的按鈕位置」更值得學。當工具與模型不斷更換,你仍然可以從受眾、情緒、故事、視覺與迭代五個層次重新開始。 如果你也在建立更完整的人機協作能力,可以延伸閱讀本站的〈4D Framework:比 Prompt Engineering 更完整的 AI Fluency 框架〉,把「委派、描述、判斷、盡責」的思考方式帶回 AI 影片之外的工作。 常見問答 (FAQ)Q1:學 AI 影片之前,一定要先學完整套導演或攝影專業嗎?不一定。若目標是製作 AI 短影音,應先學會定義受眾、情緒、故事與商業目標,再補足能看懂和判斷畫面的基本導演審美;不需要先把完整影視專業學完才開始創作。 Q2:AI 影片 Prompt 應該寫攝影機指令,還是描述觀眾感受?兩者都可以使用,但建議先描述觀眾、情緒與故事意圖,再依任務需要補充景別、運鏡、角色與畫面限制。這樣 AI 有機會提出多種視覺解法,而不是只照著一張固定施工圖執行。 Q3:為什麼短影音要先做注意力設計,而不是先做分鏡?因為短影音觀眾可能在幾秒內滑走。先規劃停滑、問題、刺激、衝突、反轉與 CTA 等注意力任務,能讓景別、構圖與運鏡服務觀眾留存,而不是只追求畫面漂亮。 Q4:AI Video Literacy 具體包含哪些能力?AI Video Literacy 包含看懂、判斷、指揮與修正四種能力。你要能看出影片哪裡不符合預期、說明問題原因、把意圖交給 AI,並根據結果提出下一輪可執行的修改方向。 Q5:什麼是 AI 製片人?AI 製片人是以商業目標、受眾、情緒與成果為核心,指揮 AI 規劃腳本、分鏡、素材、聲音與剪輯,並負責比較與判斷最終結果的人。他不必親自完成每一個技術步驟,但必須對作品方向與採用結果負責。

  • article-n8n 自架版 AI Assistant:One-line setup、Sandbox 與 Zeabur 架構

    2026/8/26

    AI自動化 n8n n8n新手教學
    n8n 自架版 AI Assistant:One-line setup、Sandbox 與 Zeabur 架構

    如果你跟我一樣是自己架 n8n,最近這個更新很值得注意。 n8n 官方社群公告指出,從 n8n 2.35 開始,Self-hosted AI Assistant 的設定流程變得簡單許多。以前要自己開啟相關模組、準備 Sandbox、設定模型,再視需要接上 Web Search;現在新的 Docker-based n8n instance 可以透過 One-line setup 預先建立 Sandbox、SearXNG 與 AI Assistant,最後再由你在 UI 中連接模型提供者。 不過,這次更新真正重要的地方,不只是「安裝變簡單」。 它讓 n8n 的使用方式開始從: 我自己拖 Node、寫 Expression、測試 Workflow。 慢慢走向: 我先把需求描述清楚,再讓 AI 協助我建構 Workflow。 官方目前仍將 Self-hosted AI Assistant 標示為 preview,功能與行為可能持續變動。本文因此會把版本與環境變數視為「目前文件的設定方式」,正式環境升級前仍要重新確認官方說明、備份與資料邊界。 先說結論:One-line setup 解決快速開始,不等於完成 Production 架構新的 One-line setup 適合: 第一次在本機學習 n8n。 想快速測試 AI Assistant 的 Workflow Builder。 想做 Demo 或驗證自動化想法。 不想一開始就手寫完整的 Docker Compose。 它不會替你完成所有事情。Docker 仍然要先安裝並啟動,模型 API 金鑰仍然要自己準備;SQLite、HTTPS、備份、權限與 Sandbox 隔離,也要按照正式環境需求重新設計。 可以先用這張表定位自己的路線: 你的情境 先選哪一條路線 判斷重點 新環境、本機測試或短期 Demo One-line setup + n8n-sandbox 先快速驗證 AI Workflow Builder。 已有 Zeabur + n8n + PostgreSQL + task-runner 保留既有服務,Sandbox 評估 Daytona 不必為了 AI Assistant 重建整套正式環境。 資料不能離開指定基礎設施 自架 n8n-sandbox,或暫不啟用 Builder 先確認 privileged Runner、資料政策與隔離邊界。 如果你已經有一套正在運作的 Zeabur + n8n + PostgreSQL 架構,也不需要為了 AI Assistant 直接打掉重來。比較合理的做法是先理解既有元件的責任,再決定要把 Sandbox 放在哪裡。 AI Assistant 不是 AI Agent Node:先分清楚兩個層次這兩個名字很像,但負責的工作不同。 AI Agent Node:工作流裡的一個節點以前我們在 n8n 裡使用 AI,通常會把 AI Agent 拉進 Workflow: 123456789Webhook ↓AI Agent ↓OpenAI / Claude / Gemini ↓Google Sheets ↓LINE 這裡的 AI Agent 是 Workflow 裡的一個處理步驟。它可以理解輸入、呼叫工具、查詢資料,再把結果傳給下一個 Node。 AI Assistant:幫你製作 Workflow 的助手AI Assistant 位於另一個層次。它不是你最後交付給使用者的 Workflow,而是協助你規劃、建立與修正 Workflow 的建構助手。 你可以這樣描述需求: 幫我建立一個 LINE 預約系統。收到 LINE Webhook 後判斷使用者操作;如果使用者要預約,就讀取 Google Calendar 的可預約時段,再產生 LINE Flex Message;預約成功後,把資料寫進 Google Sheets。 以前你可能要自己完成: 123456789找 Node ↓設定 Credential ↓寫 Expression ↓查 API 文件 ↓測試與除錯 AI Assistant 想協助的是: 12345678910111213理解需求 ↓規劃 Workflow ↓產生 Workflow 程式碼 ↓在 Sandbox 中編譯與測試 ↓修正錯誤 ↓產生有效的 Workflow JSON ↓儲存到 n8n 所以 n8n 的學習重點,會逐漸從「我知道每個 Node 在哪裡」延伸到「我能不能把需求、資料結構與限制描述清楚」。 如果你想先理解 LLM 與 AI Agent Node 的選擇差異,也可以延伸閱讀 何時該用 LLM?何時該派 AI Agent 上場?。 Self-hosted AI Assistant 其實由三個部分組成可以先用這個架構理解: 123456789101112 ┌─ OpenAI ├─ Anthropic你 → n8n AI Assistant ─ OpenRouter └─ OpenAI-compatible API │ ├──────── Web Search │ ├─ Brave Search │ └─ SearXNG │ └──────── Sandbox ├─ n8n-sandbox └─ Daytona 1. Model Provider:AI 的大腦你仍然要自行選擇模型提供者並準備 API Key,例如: Anthropic。 OpenAI。 OpenRouter。 其他 OpenAI-compatible API。 n8n 不會附送模型,也不會替你支付模型使用費。One-line setup 做的是準備 AI Assistant 所需的執行環境;模型連線與費用仍然由你的模型提供者決定。 2. Sandbox:AI 的隔離工作區AI Assistant 的 Workflow Builder 不是只回傳一段文字。它可能需要建立檔案、寫入 TypeScript、執行編譯器、安裝套件、執行程式,再根據錯誤反覆修正。 這些工作不應直接在正式 n8n Host 上執行,因此需要一個專用 Sandbox: 123456789AI Assistant ↓寫入 workflow.ts ↓TypeScript type-check ↓執行並產生 Workflow JSON ↓驗證成功後才交回 n8n 如果沒有可用的 Sandbox,Workflow Builder 的能力就無法完整使用。要注意的是,Sandbox 提供的是程式碼執行隔離,不等於自動完成權限控管、資料遮罩或人工作業確認。 3. Web Search:讓 AI 查得到最新資料如果你要求 AI 協助串接最新 API,它可能需要查詢官方文件、Endpoint、Authentication 或 Request Format。Web Search 就是提供這一層能力。 依照 n8n 目前的 Instance AI 設定文件,搜尋提供者的優先順序是: 12345Brave API Key ↓ 沒有SearXNG URL ↓ 都沒有Web Search disabled 沒有 Search Provider 時,fetch-url 仍可能可以使用,但 AI Assistant 不會具備主動 Web Search 能力。若希望搜尋也留在自己的基礎設施,可以考慮在同一個網路環境部署 SearXNG;若追求較少維護元件,則可評估 Brave Search。 新環境:One-line setup 會幫你準備什麼?執行前先準備 DockerOne-line setup 不會替你安裝 Docker。先確認 Docker Engine 或 Docker Desktop 已啟動,而且 Docker Compose v2 可以使用: 1docker compose version Windows 使用者若要依照 POSIX shell 流程執行,建議使用 Docker Desktop 搭配 WSL2,並在 WSL Terminal 中操作。不同平台與 Docker 版本仍應以官方文件的當期說明為準。 官方快速指令在準備好的目錄執行: 1curl -fsSL https://get.n8n.io | sh 它不是「免安裝 Docker」,而是把原本要自己撰寫與組合的 Docker Compose 設定、資料卷、Sandbox 與 Web Search 服務整理成較容易開始的流程。完成後通常可以從以下位置開啟 n8n: 1http://localhost:5678 One-line setup 背後的服務官方 Docker Compose 文件中的主要元件包括: 12345n8n├── sandbox-certs├── sandbox-api├── sandbox-runner-1└── searxng n8n:Workflow Editor 與主要應用程式。 sandbox-certs:產生 Sandbox 服務需要的 TLS 憑證。 sandbox-api:n8n 與 Sandbox 溝通的控制層。 sandbox-runner-1:建立與執行 Sandbox 的 Runner。 searxng:AI Assistant 的 Web Search 後端。 這個快速架構預設沒有另外建立 PostgreSQL 服務,測試環境通常會使用 SQLite。若要長期承載團隊或企業工作流,資料庫、備份與復原策略要另外規劃。 遠端腳本不要盲目直接執行curl ... | sh 很方便,但它也代表把遠端下載的內容直接交給 shell。即使來源是官方,重要主機仍可先下載、閱讀,再執行: 123curl -fsSL https://get.n8n.io -o get-n8n.shless get-n8n.shsh get-n8n.sh 正式環境還要確認目前目錄、資料卷、備份與更新策略,不要把測試環境的指令直接套到含有重要資料的主機。 既有 n8n:不要為了 AI Assistant 直接重建整套環境如果你已經使用 Docker 或 Zeabur 部署 n8n,建議採取漸進式流程: 123456789101112131415備份 Workflow、Credentials 與資料庫 ↓確認目前 n8n 版本與升級相容性 ↓升級到支援 AI Assistant 的版本 ↓確認原有 Workflow 正常 ↓設定 Model Provider ↓選擇 Sandbox Provider ↓選擇 Brave Search 或 SearXNG ↓用測試 Workflow 驗證 AI Assistant 官方公告將 n8n 2.35 或更新版本列為 Self-hosted AI Assistant 的前提之一,但版本與設定仍會更新。不要只因為看到一個新的功能,就直接替換正在服務中的 n8n;先確認資料庫、Encryption Key、Webhook、Credentials 與現有 Workflow 都能復原。 Sandbox 有兩種路線:n8n-sandbox 或 Daytona這是整篇最容易被忽略、但最值得先做決策的部分。 方案一:n8n-sandboxn8n-sandbox 是由你自己管理的 Sandbox 服務。以 Docker Compose 部署時,n8n、Sandbox API、Runner 與 SearXNG 可以放在同一套基礎設施中: 1234567自己的 VPS 或 Docker Host│├── n8n├── PostgreSQL├── SearXNG├── sandbox-api└── sandbox-runner-1 它的優點是控制權高,資料與執行環境可以盡量留在自己的 Infrastructure,適合: 本機開發。 課程 Demo。 測試 AI Workflow Builder。 有能力維護 Docker-in-Docker 的自架環境。 公司政策要求資料不能離開指定基礎設施。 但要注意,官方 Compose 中的 sandbox-runner-1 使用 privileged: true,而且透過 Docker-in-Docker 建立與執行其他 Sandbox Container。這不是一般的 PostgreSQL 或 n8n Container;官方文件也提醒不要把 Runner 的連接埠暴露到 Internet,並應將它視為高權限元件。 官方文件目前以至少 4 GB RAM、2 vCPU 作為這套 Compose Sandbox 的起始資源參考。實際需求仍會受到同時執行的 Workflow、模型與 Sandbox 工作量影響,不能把它當成所有 Production 環境的保證規格。 方案二:DaytonaDaytona 是另一個 Sandbox Provider。架構會變成: 1234567891011你的 n8n Host│├── n8n├── PostgreSQL└── Web Search │ │ API ↓ Daytona │ └── AI Sandbox Container n8n 透過 Daytona API 建立或管理隔離的 Sandbox,AI Assistant 在其中寫檔案、執行 TypeScript、檢查錯誤,再把通過驗證的 Workflow 交回 n8n。這樣 AI 建構程式碼的執行環境就不必與正式 n8n Host 共用同一個 Docker-in-Docker Runner。 Daytona 的代價是增加第三方服務依賴、API Key、使用量與費用。更重要的是,AI Assistant 建構過程所需的檔案與資料可能進入外部 Sandbox;如果你的流程包含高度機敏企業資料、金融資料或特殊個資,必須先做資料邊界與供應商政策審查。 兩種 Sandbox 怎麼選? 使用情境 建議與理由 個人電腦測試、課程或短期 Demo 選 n8n-sandbox,先用 Docker Compose 快速重現環境。 完全 Self-hosted、資料希望留在自己的基礎設施 選 n8n-sandbox,但要接受 privileged Docker-in-Docker Runner 的維運與安全責任。 已有正式 n8n、希望降低維運 評估 Daytona,避免自行維護高權限 Sandbox Runner。 Zeabur 上的既有 n8n 保留 n8n、PostgreSQL 與 task-runner,Sandbox 優先評估 Daytona。 資料不得離開指定環境 先以資料政策與隔離要求為前提,評估自架 n8n-sandbox 或暫不啟用 Builder。 Self-hosted 不代表「所有東西都一定要塞在同一台 Server」。比較成熟的判斷方式是:哪些核心資料與自動化服務值得自己管理,哪些短生命週期的 AI 執行環境可以交給專門的 Sandbox Provider。 Zeabur + n8n + PostgreSQL + task-runner:我會怎麼選?如果你的現有架構是: 12345Zeabur Project│├── PostgreSQL├── task-runner└── n8n 我會先保留這套核心環境,讓 AI Assistant 的 Sandbox 走 Daytona: 12345678910Zeabur│├── PostgreSQL├── task-runner├── n8n└── SearXNG(可選) │ └──────── API ──────── Daytona │ └── AI Sandbox 原因不是 Daytona 一定比較安全或一定比較便宜,而是這個選擇與 Zeabur 的部署方式比較相容。 task-runner 不等於 AI Assistant Sandbox這裡非常容易混淆。 官方 task runners 文件把 task runner 定位為執行 Code Node 中 JavaScript 與 Python 程式碼的機制;它可以作為 n8n 的外部 Runner,隔離一般 Workflow 執行時的使用者程式碼。 AI Assistant Sandbox 則負責另一個流程: 123456789AI Assistant ↓建立 workflow.ts ↓執行 TypeScript 編譯與測試 ↓修正錯誤 ↓產生有效 Workflow JSON 因此: 1task-runner ≠ AI Assistant Sandbox 即使 Zeabur 裡已經有 task-runner,也不代表 AI Assistant 的 Workflow Builder 已經具備可用的 Sandbox。兩者可以同時存在,角色也不互相取代。 為什麼不直接把 n8n-sandbox 塞進 Zeabur?Zeabur 官方目前說明,不能直接從 Docker Compose YAML 部署服務;可以改用 Dockerfile、Docker Image 或轉成 Zeabur Template YAML 等方式組合服務。 而 n8n 官方 Sandbox Compose 還包含 sandbox-api、sandbox-runner-1、TLS 憑證,以及 privileged: true 的 Docker-in-Docker Runner。這代表它不是把一個普通 Docker Image 加進專案就結束。 如果你真的想在 Zeabur 部署自架 Sandbox,需要逐項確認: 目前使用的 Server 或 Plan 是否支援所需的高權限容器能力。 Sandbox API 與 Runner 能否以 Zeabur 支援的 Template 或服務方式部署。 內部網路、TLS、Runner 註冊與持久化資料如何配置。 Runner 是否會被錯誤暴露到公開網路。 發生 Sandbox 失敗時,n8n 與 PostgreSQL 是否仍然可用。 如果只是想在既有 Zeabur n8n 上加入 AI Assistant,我不會把這些基礎設施風險當成第一個實驗步驟。 Zeabur + Daytona 的取捨12345678910正式自動化平台Zeabur├── n8n├── PostgreSQL├── task-runner└── SearXNG(可選)AI 建構工作區Daytona└── Sandbox 優點: 不用先改動目前正常運作的 n8n、PostgreSQL 與 task-runner。 不必在 Zeabur 內維護 Docker-in-Docker privileged Runner。 正式 n8n 與 AI 建構程式碼的執行環境分開。 Daytona 發生問題時,主要影響 AI Workflow Builder,不一定等於既有 Workflow Runtime 全部停止。 缺點: 多一個外部服務、帳號、API Key、費用與供應商依賴。 AI Assistant 的 Sandbox 資訊可能進入第三方環境,需要檢查資料政策。 Daytona 的 API、方案、計費與支援範圍會變動,不能把本文的選擇當成永久答案。 所以我的判斷會是: n8n、PostgreSQL、task-runner 與搜尋服務自己控制;AI Assistant 的臨時執行環境交給 Daytona。 但如果企業資料政策不允許資料離開指定 Infrastructure,就應該改評估自架 n8n-sandbox,或先不要啟用 AI Workflow Builder。 Web Search:Brave Search 還是 SearXNG?這個選擇可以獨立於 Sandbox Provider。 選 Brave Search適合希望減少自行維護服務的人: 12345Zeabur└── n8n ├── Model Provider ├── Daytona Sandbox └── Brave Search API 需要管理 API Key 與使用量,也要確認資料是否符合公司的第三方服務政策。 選 SearXNG適合希望把搜尋服務放在自己控制的網路環境的人: 12345Zeabur├── n8n└── SearXNG │ └── 內部網路 SearXNG 是一般服務,與需要 privileged Docker-in-Docker 的 Sandbox Runner 不同。這也是為什麼在 Zeabur 架 SearXNG,通常比直接照搬整套 n8n-sandbox Compose 更容易拆分與管理。 設定時可以參考哪些環境變數?以下只展示名稱與結構,不要把真實 API Key 寫進公開文章、Git Repository 或截圖: 1234N8N_INSTANCE_AI_SANDBOX_ENABLED=trueN8N_INSTANCE_AI_SANDBOX_PROVIDER=daytonaDAYTONA_API_URL=https://app.daytona.io/apiDAYTONA_API_KEY=請填入自己的金鑰 如果採用 n8n-sandbox,則要依目前版本的官方設定文件提供 Sandbox Service URL 與必要的認證資訊。以目前設定文件的概念,可以先理解成: 1234N8N_INSTANCE_AI_SANDBOX_ENABLED=trueN8N_INSTANCE_AI_SANDBOX_PROVIDER=n8n-sandboxN8N_SANDBOX_SERVICE_URL=http://sandbox-api:8080N8N_SANDBOX_SERVICE_API_KEY=請填入自己的 Sandbox 金鑰 不同 n8n 版本的 Compose 範例與環境變數名稱可能調整,不要直接複製舊文章中的設定到 Production;部署前應以當期官方文件與 UI 中的 Sandbox connection 為準。 Web Search 的設定概念則是: 12345# Brave 有設定時優先使用 BraveINSTANCE_AI_BRAVE_SEARCH_API_KEY=請填入自己的金鑰# 或使用自架 SearXNGN8N_INSTANCE_AI_SEARXNG_URL=http://searxng:8080 實際欄位可在 n8n UI 的 Instance AI 設定中管理;如果同時設定兩者,依目前官方 configuration 文件,Brave 會優先於 SearXNG。 我會用這五個能力迎接 Vibe Automation這個更新不代表以後不用學 n8n。相反地,以下五個能力會更重要: 1. 需求描述不要只說「我想自動化」,而要說清楚: 當 A 發生時,取得 B 資料,判斷 C 條件,再執行 D;如果失敗,要通知誰、留下什麼紀錄? 2. 流程設計AI 可以產生 Workflow,但你仍然要判斷流程是否合理: 1234567891011Trigger ↓驗證輸入 ↓讀取資料 ↓判斷條件 ├── 成功路徑 └── 例外路徑 ↓通知與紀錄 3. 資料結構你至少要看得懂輸入與輸出的 JSON,才能判斷 AI 是否接錯欄位: 12345678910{ "customer": { "name": "王小明", "phone": "09xxxxxxxx" }, "appointment": { "date": "2026-09-01", "time": "14:00" }} 4. 系統整合Workflow 的價值不在於 Node 越多,而在於它能否穩定串接 Webhook、資料庫、API、LINE、Google Calendar 與通知服務。 5. 判斷 AI 做得對不對AI 產生的 Workflow 仍然需要測試: 1234567891011正常輸入 ↓邊界條件 ↓Credential 失效 ↓API timeout ↓重複事件 ↓資料是否正確寫入 「可以產生」與「可以安全交付」是兩件不同的事。 我的建議:先保留現在的 n8n,再逐步接上 AI Assistant如果你的 n8n 已經架在 Zeabur,而且 PostgreSQL、task-runner、Webhook 與既有 Workflow 都正常,我會採用以下順序: 12345678910111213① 備份目前 n8n、PostgreSQL 與 Credentials ↓② 確認目前版本與官方 AI Assistant 相容性 ↓③ 升級 n8n,先驗證原有 Workflow ↓④ 在 n8n 設定 OpenAI / Anthropic / OpenRouter 等模型 ↓⑤ Sandbox 選 Daytona,或依資料政策自架 n8n-sandbox ↓⑥ Web Search 選 Brave,或在 Zeabur 部署 SearXNG ↓⑦ 用測試 Workflow 驗證建構、修正與儲存流程 不要因為想玩一個新功能,就先把正常環境打掉重來。 Self-hosted 真正重要的能力,不是「什麼東西都自己架」,而是: 哪些東西值得自己管理,哪些東西交給專門服務反而更合理? 對 Zeabur + n8n 來說,我目前會把界線畫在: 1234567核心自動化平台與資料 ↓由 Zeabur 控制AI Assistant 的短生命週期執行環境 ↓交給 Daytona,或依資料政策自架 Sandbox 這樣既保留 Self-hosted n8n 的控制力,也不必為了 AI Assistant 把所有基礎設施一次複雜化。 參考文件 n8n Community:AI Assistant on self-hosted n8n: easier setup in 2.35 n8n 官方 One-line setup 文件 n8n 官方 Docker Compose 安裝文件 n8n Instance AI configuration n8n Instance AI sandboxing n8n task runners 文件 Zeabur:Deploying with Dockerfile 常見問答 (FAQ)Q1:One-line setup 會自動安裝 Docker 嗎?不會。你必須先安裝並啟動 Docker,且 docker compose version 可以正常執行;One-line setup 主要負責建立 n8n、Sandbox、SearXNG 與相關 Docker Compose 設定。 Q2:n8n 的 task-runner 和 AI Assistant Sandbox 是同一個東西嗎?不是。task-runner 主要負責執行 Workflow 中 Code Node 的 JavaScript 或 Python 程式碼;AI Assistant Sandbox 則提供 Workflow Builder 建立檔案、編譯 TypeScript、執行測試與產生 Workflow JSON 的隔離工作區。 Q3:n8n-sandbox 和 Daytona 該怎麼選?n8n-sandbox 適合本機開發、測試與希望所有資料留在自己 Infrastructure 的環境;Daytona 適合希望把 AI 產生程式碼的執行環境與正式 n8n Host 分開、降低自維護 Docker-in-Docker 複雜度的 Production 情境。若資料不得離開指定環境,應優先評估自架 Sandbox 或暫不啟用 Workflow Builder。 Q4:如果我已經在 Zeabur 使用 n8n 和 task-runner,還需要 Sandbox 嗎?需要。task-runner 不會自動提供 AI Assistant Workflow Builder 所需的 Sandbox;兩者用途不同,可以同時存在。你仍然要另外設定 n8n-sandbox 或 Daytona 作為 Sandbox Provider。 Q5:Daytona 會帶來哪些風險或成本?Daytona 會增加第三方服務依賴、API Key、使用量與費用,而且 AI Assistant 建構過程的檔案與資料可能進入外部 Sandbox。使用前應檢查企業資料政策、供應商條款、敏感資料遮罩與可接受的服務中斷範圍。 Q6:沒有 Web Search Provider 時,AI Assistant 還能使用嗎?可以使用部分功能,但主動 Web Search 會被停用;依目前 n8n 設定文件,fetch-url 仍可能可用。若需要查詢最新 API 文件,應設定 Brave Search 或 SearXNG,並確認搜尋資料的合規要求。 Q7:One-line setup 適合直接拿來跑企業 Production 嗎?它適合快速學習、測試與 Demo,但不等於完整的企業 Production 架構。正式環境仍要評估 PostgreSQL、HTTPS、備份與復原、權限、監控、更新回滾、Sandbox 隔離與資料邊界。

  • article-n8n 自架新手指南:One-line setup 一行指令建立 Docker Compose、AI Assistant 與 Sandbox

    2026/8/26

    AI自動化 n8n n8n新手教學
    n8n 自架新手指南:One-line setup 一行指令建立 Docker Compose、AI Assistant 與 Sandbox

    如果你以前自己架過 n8n,應該很清楚第一次安裝時會遇到多少名詞:Docker、Docker Compose、Volume、環境變數、Secret,還有 AI Assistant 需要的模型與搜尋服務。 現在 n8n 官方提供了 One-line setup。準備好 Docker 並確認它正在執行後,只要在 Terminal 貼上一行指令,就能建立一套全新的 n8n 本機環境: 1curl -fsSL https://get.n8n.io | sh 這不代表 Docker 被「免安裝」了,而是 n8n 把原本要自己撰寫與組合的 Docker Compose 設定、資料卷、Secret,以及 AI Assistant 的支援服務,整理成一個較容易開始的安裝流程。 本文依照 n8n 官方 One-line setup 文件 整理。安裝指令、版本政策與支援的模型提供者都可能更新,實際執行前仍應以官方文件為準。 One-line setup 適合什麼情境?官方把這套流程定位為 全新 n8n instance 的快速安裝方式。它特別適合以下情境: 第一次在本機學習 n8n。 想快速做 Demo 或測試 AI Assistant。 不想一開始就手寫完整的 Docker Compose 檔案。 想先把環境跑起來,再逐步理解 Docker、Volume 與環境變數。 如果你已經使用自己的 Docker Compose 架構自架 n8n,不需要為了 One-line setup 重新安裝。它不是既有環境的強制遷移工具;正在使用 npm 安裝的既有 instance,目前也不會因為這個腳本出現就立刻失效。 執行前需要準備什麼?先安裝並啟動 DockerOne-line setup 不會替你安裝 Docker。你需要先安裝 Docker,並讓 Docker daemon 在背景執行。 這套流程特別需要 Docker Compose v2 plugin,也就是下面這個指令可以使用: 1docker compose version 不要把它和舊版的獨立指令混淆: 1docker-compose 官方文件要求的是 docker compose,不是舊式的 docker-compose。如果你使用 Podman、Colima 或其他相容引擎,也需要準備好帶有 Compose plugin 的 Docker CLI,並正確指向它的 socket。 macOS、Linux 與 Windows 的差異在 macOS 或 Linux 上,通常是安裝 Docker Desktop 或 Docker Engine,確認服務啟動後直接從 Terminal 執行指令。 Windows 的 PowerShell 與 Command Prompt 不能直接按照 POSIX shell script 的方式執行這套安裝流程。官方建議使用: 1234Docker Desktop+ WSL2+ Docker Desktop 的 WSL2 integration+ WSL Terminal Git Bash 理論上可以執行 shell script,但官方文件表示尚未完成端到端驗證;Windows 使用者優先採用 WSL 會比較穩妥。 一行指令會幫你建立什麼?在你想放置 n8n 的目錄開啟 Terminal,執行: 1curl -fsSL https://get.n8n.io | sh 腳本會依序檢查 Docker 是否存在、Docker daemon 是否正在執行,以及 Docker Compose v2 是否可用。接著在目前目錄建立 n8n/ 資料夾,並準備相關設定: 1234n8n/├── compose.yml├── .env└── searxng-settings.yml 第一次執行時,它還會下載需要的 Docker image、建立資料卷並啟動服務。正常完成後,可以開啟: 1http://localhost:5678 官方範例輸出也會顯示資料儲存在 ./n8n,並使用名為 n8n-data 的 Docker volume。若同一個資料夾已經完成設定,再次執行通常只會提示目前已經存在,不會任意覆蓋既有環境。 內建的服務包含哪些?One-line setup 的價值不只是把 n8n 主程式啟動,它也會準備 AI Assistant 需要的基礎服務。 1. n8n Workflow Editorn8n 本身是視覺化的 Workflow Editor,可以用節點串接 Trigger、Webhook、API、Google Sheets、Gmail、LINE 與 AI Agent 等服務。 如果你還不熟悉 n8n,可以先閱讀站內的 n8n 自動化工具介紹與 AI 輔助安裝教學,先建立工作流與節點的基本概念。 2. 內建資料庫:SQLite這套快速安裝預設使用 SQLite。它是一個直接存在檔案中的輕量資料庫,不需要另外架設資料庫伺服器,適合個人學習、測試與 Demo。 SQLite 會保存工作流、憑證與執行紀錄,因此「只是刪除容器」和「刪除 volume」是完全不同的操作。後面會專門說明資料風險。 3. AI Assistant 的 Sandbox當 AI Assistant 協助產生或執行程式碼時,One-line setup 會一併啟動 n8n 提供的 bundled sandbox。可以把它理解成一個與 n8n 主程式分開的執行環境,讓 AI 產生的程式碼有獨立的執行位置。 這對本機測試很方便,但「有 Sandbox」不等於完成企業級的安全架構。正式環境仍要評估權限、網路隔離、資源限制與 Sandbox provider。 4. 網頁搜尋支援服務安裝器會產生 searxng-settings.yml,並啟動 AI Assistant 使用的 bundled search tool。官方文件將它描述為預設的搜尋支援服務,讓 AI Assistant 可以在需要時查找網頁資料。 如果你想改用 Brave Search,也可以在 ./n8n/.env 設定 INSTANCE_AI_BRAVE_SEARCH_API_KEY。這不是啟用 n8n 的必要條件,而是替換搜尋提供者的選項。 AI 模型仍然要自己準備這裡是最容易誤會的地方:One-line setup 不會附送 AI 模型,也不會替你支付模型 API 費用。 它準備的是 AI Assistant 的執行環境;你仍然要在 n8n 介面中加入自己的模型提供者與 API key。官方文件提供兩種做法: n8n 啟動後,進入 instance 的 AI 設定介面加入模型 API key。 在登入前直接編輯 ./n8n/.env,填入 N8N_INSTANCE_AI_MODEL_API_KEY。 例如環境變數名稱會長這樣: 1N8N_INSTANCE_AI_MODEL_API_KEY= 填入自己的 key 後,重新啟動 n8n: 1docker compose -f ./n8n/compose.yml up -d 模型提供者與可用設定會隨 n8n 版本及方案變動,請以官方的 Set up the AI Assistant 文件 為準。API key 不要寫進公開文章、Git repository 或截圖中。 AI Assistant 和 AI Agent Node 不一樣這兩個名稱很像,但負責的事情不同。 AI Agent Node:工作流裡的 AIAI Agent Node 是你拖進工作流的節點。例如: 1234567LINE↓AI Agent↓Google Calendar↓回覆 LINE 它是工作流中的一個處理步驟,負責依照你的設定理解輸入、呼叫工具,再把結果傳給下一個節點。 AI Assistant:幫你製作工作流的助手AI Assistant 比較像工作流建構階段的協作者。你可以描述需求,例如: 收到 Gmail 後,自動判斷是不是客戶詢價信;如果是,就寫入 Google Sheets。 它的目標是協助你規劃或建立工作流,而不是取代工作流中的 AI Agent Node。 如果你想深入理解 LLM 和 AI Agent 的選擇差異,可以延伸閱讀 何時該用 LLM?何時該派 AI Agent 上場?。 安裝後最常用的 Docker 指令One-line setup 降低了第一次安裝的門檻,但基本的啟停指令仍然值得記住。 停止 n8n1docker compose -f ./n8n/compose.yml down 這會停止服務,通常不會主動刪除資料卷。 重新啟動 n8n1docker compose -f ./n8n/compose.yml up -d 升級到較新的版本1curl -fsSL https://get.n8n.io | sh -s -- --upgrade 官方腳本也提供版本控制參數。若要指定版本,請依官方文件當下支援的格式執行,例如: 1curl -fsSL https://get.n8n.io | sh -s -- --version 2.31.4 版本號只是範例,升級前要先確認相容性、備份資料與官方的版本說明。 只產生設定、不立即啟動如果你想先檢查設定檔,再決定何時啟動,可以使用: 1curl -fsSL https://get.n8n.io | sh -s -- --no-start 想查看腳本可用的選項,則可以使用: 1curl -fsSL https://get.n8n.io | sh -s -- --help 執行遠端腳本前,先檢查內容curl ... | sh 很方便,但它代表你把遠端下載的內容直接交給 shell 執行。即使來源是官方,也建議對公司環境或重要主機採用「先下載、先閱讀、再執行」的方式: 123curl -fsSL https://get.n8n.io -o get-n8n.shless get-n8n.shsh get-n8n.sh 檢查腳本時,可以特別留意它會連線到哪些服務、會建立或修改哪些檔案,以及目前版本是否符合你的部署計畫。不要把未知來源的安裝指令直接套用到含有重要資料的主機上。 down 和 down -v 的資料風險下面兩個指令看起來只差一個參數,後果卻完全不同: 1docker compose -f ./n8n/compose.yml down 1docker compose -f ./n8n/compose.yml down -v down 主要是停止並移除容器;down -v 會連同 Docker volume 一起刪除。官方卸載流程還會接著刪除 ./n8n 資料夾,因此工作流、憑證與執行紀錄都有可能一起消失。 只想暫停 n8n 時,不要把 -v 當成習慣性參數。真的要移除環境前,先確認備份、資料保留需求與目前所在的目錄。 One-line setup 可以直接拿來跑 Production 嗎?可以啟動,不代表已經完成 Production 架構。 One-line setup 的預設值非常適合「快速開始」:SQLite 不需要額外資料庫、bundled sandbox 不需要先設計 provider、服務也只需要從本機的 localhost:5678 開始使用。 但如果要把 n8n 放進團隊或公司的正式自動化環境,還要另外處理: PostgreSQL 或其他正式資料庫架構。 Domain、HTTPS 與 Reverse Proxy。 Workflow、Credential 與執行資料的備份及還原。 Sandbox 的隔離方式、權限與資源限制。 Webhook 對外開放後的驗證、監控與告警。 更新、回滾與版本相容性。 官方目前建議團隊或 Production 環境評估 PostgreSQL;Sandbox 則建議另外研究 Daytona 等正式 provider。這也是為什麼我會把 One-line setup 定位成「學習版與快速驗證的起點」,而不是企業部署的完整答案。 我會怎麼分三個階段使用?Level 1:本機學習版123Docker Desktop+ One-line setup+ SQLite 適合第一次接觸 n8n、課程教學、測試 AI Assistant 與驗證工作流想法。 Level 2:個人長期使用版12345VPS+ Docker Compose+ Domain+ HTTPS+ 備份 適合個人自動化、LINE Bot、Webhook 與需要 24 小時執行的流程。這個階段要開始理解資料卷、反向代理、更新與復原。 Level 3:企業 Production1234567Docker 或 Kubernetes+ PostgreSQL+ Reverse Proxy+ Backup+ Monitoring+ 隔離的 Sandbox+ 權限管理 這才是需要系統性評估可用性、安全性、權限、備份與維運成本的正式架構。 n8n 正在往 Docker-first 方向前進官方 One-line setup 文件目前寫明,預計在 2026 年 10 月推出 n8n 3.0 後,新的 n8n 安裝將不再採用以前的: 12npm install n8nnpx n8n 而是以 Docker 為主要發佈方式。這項時程與安裝政策仍可能隨官方版本調整,不能把文章中的日期當成永久不變的承諾;但方向已經很清楚:未來學習 n8n 自架,Docker Compose 會越來越接近基本功。 有趣的是,你不一定要在第一天就完全學會 Docker,才能開始使用 Docker。One-line setup 把「理解容器架構」與「先把服務跑起來」拆成兩個階段,讓新手可以先完成第一次成功啟動,再逐步補上 Compose、Volume、網路與安全性的知識。 結論:它解決的是快速開始,不是架構設計如果你以前看到「自架 n8n」就因為 Docker Compose 而放棄,現在確實值得重新試一次:先安裝並啟動 Docker,再用一行指令建立 n8n、SQLite、AI Assistant 支援服務與 Sandbox。 但也要記得三件事: Docker 仍然要自己安裝,One-line setup 只是簡化 n8n 的 Compose 設定。 AI 模型與 API key 仍然要自己準備,快速安裝不等於附送模型。 本機 Demo 與企業 Production 是兩種不同的架構問題,PostgreSQL、HTTPS、備份與安全隔離不能省略。 真正重要的改變,是把新手的起點從「我要先讀完所有 Docker 文件」變成「我先把 n8n 跑起來,再理解它怎麼運作」。自動化的入口,確實又降低了一階。 參考文件 n8n One-line setup 官方文件 n8n Set up the AI Assistant 官方文件 Docker 安裝文件 常見問答 (FAQ)Q1:One-line setup 會自動安裝 Docker 嗎?不會。你必須先安裝並啟動 Docker,而且需要可以使用 docker compose 的 Docker Compose v2 plugin;One-line setup 主要負責建立 n8n 的 Compose 設定與啟動相關服務。 Q2:One-line setup 有附送 AI 模型或 API key 嗎?沒有。它會準備 AI Assistant 使用的 Sandbox 與搜尋支援服務,但你仍然需要在 n8n 的 AI 設定介面或 ./n8n/.env 中加入自己的模型提供者 API key。 Q3:docker compose down 和 docker compose down -v 有什麼不同?docker compose down 主要停止並移除容器;docker compose down -v 會連同 Docker volume 一起刪除,可能造成工作流、憑證與執行紀錄遺失,因此不能把 -v 當成一般停機指令。 Q4:One-line setup 適合直接部署公司的 Production n8n 嗎?它適合快速學習、測試與 Demo;公司的 Production 環境通常還需要 PostgreSQL、HTTPS、Reverse Proxy、備份、監控、權限控管,以及更完整的 Sandbox 隔離設計。 Q5:AI Assistant 和 AI Agent Node 是同一個功能嗎?不是。AI Agent Node 是工作流裡負責理解輸入、使用工具或產生結果的節點;AI Assistant 則是協助你規劃或建立 n8n 工作流的建構助手。

  • article-4D Framework:比 Prompt Engineering 更完整的 AI Fluency 框架

    2026/8/23

    AI自動化 AI工具 AI Agent
    4D Framework:比 Prompt Engineering 更完整的 AI Fluency 框架

    很多人談 AI 素養時,第一個想到的仍然是:「Prompt 要怎麼寫才夠好?」 但 4D Framework 提供了一個更完整的視角:AI 能不能真正幫上忙,不只取決於你會不會下指令,也取決於你是否知道哪些工作適合交給 AI、能不能清楚描述需求、能不能判斷產出品質,以及最後是否願意對採用的結果負責。 先用一句話記住它: 會分工、會交代、會驗收、會負責,才是真正的 AI Fluency。 這裡的 4D 分別是: 能力 英文 核心問題 委派 Delegation 這件事該由誰做? 描述 Description 我要怎麼讓 AI 理解我的意圖? 判斷 Discernment AI 做得對不對、好不好? 盡責 Diligence 我能不能安全採用、發布並負責? 需要先釐清的是,4D Framework 並不是 Anthropic 從零發明的 Prompt 框架。依本文整理的來源,Rick Dakan 與 Joseph Feller 在 2023–2024 年發展出 AI Fluency Framework,之後 Anthropic 與兩位教授合作,把這套框架發展成 AI Fluency 課程。因此,更精確的說法是:Dakan/Feller 發展框架,Anthropic 合作將它課程化。 AI Fluency 是什麼?AI Fluency 可以簡單理解成:你能不能有效、有效率、合乎倫理,而且安全地與 AI 一起工作。 所以以下幾件事不一定代表你具備 AI 素養: 會使用 ChatGPT。 會寫一段看起來很完整的 Prompt。 會使用 Claude Code 或其他 AI Coding Agent。 真正的 AI Fluency 是你知道: 什麼問題值得交給 AI? 哪一個工具適合這個任務? 人與 AI 應該如何分工? 如何定義成果標準並驗收? 什麼資料不能直接提供給 AI? 什麼情況需要揭露 AI 的角色? 這也是 4D Framework 比單純 Prompt 教學更有價值的地方:它訓練的是人的工作能力,而不是某個模型的操作技巧。 ① Delegation:先決定這件事該不該交給 AI一般人打開 ChatGPT,第一句可能是:「幫我做一份課程。」 但在真正開始寫 Prompt 之前,應該先問:這件事情有哪些部分適合交給 AI?哪些部分必須由人做決定? Problem Awareness:先搞懂自己要解決什麼問題很多人以為 AI 用不好,是因為 Prompt 寫得不夠漂亮;實際上,更常見的原因是使用者自己還沒有定義清楚問題。 比較模糊的需求是: 幫我做一個網站。 比較可執行的需求則是: 我要讓第一次進站的公司採購,在 30 秒內了解我們提供什麼水果禮盒,最後加入 LINE 詢價。 後者還沒有進入 Prompt 設計,就已經先完成了重要的問題定義:對象、情境、目標與預期行動都比較清楚。 Platform Awareness:知道哪個工具適合哪種任務AI Fluency 也包括理解工具的能力邊界。例如: 查最新新聞,需要能夠搜尋網路的工具。 分析大量自己的文件,可以考慮 NotebookLM 或 Claude Projects 類型的工作區。 寫程式,可以使用 Codex、Claude Code 或其他 Coding Agent。 生成圖片,應選擇適合圖像生成的模型。 精確計算,不能只把語言模型當成計算機使用。 重點不是「我最喜歡哪一個 AI」,而是「這個任務需要什麼能力,而哪個工具真的具備這項能力」。 Task Delegation:把人與 AI 的工作切開以設計一門課程為例,合理的分工可能是: 工作 人 AI 決定課程目標 主導 提供分析與建議 蒐集大量案例 審核方向 協助整理 規劃課程大綱 共同設計 共同設計 產生內容初稿 設定標準 執行產出 判斷案例是否適合學員 最終判斷 協助比較 最終教學內容 驗證、編輯與負責 不直接取代 Delegation 的核心不是把工作全部丟給 AI,而是先做出有意識的分工決策。 ② Description:把意圖說清楚,不只是寫 PromptDescription 是大家最熟悉的部分,因為它確實包含 Prompt;但 4D Framework 沒有把 Prompt Engineering 神化,而是把 Description 看成一種「把意圖清楚傳達給合作對象」的能力。 這跟以下工作其實很像: 寫 Brief。 下需求。 跟設計師溝通。 跟員工交辦工作。 撰寫規格書。 一個好的 Description 通常可以拆成三層。 Product Description:你要什麼成果?這一層是在定義產出物本身,包括 Output、Format、Audience 與 Style。 例如: 請製作一份 20 頁的 AI 入門簡報,對象是完全沒有 AI 經驗的中小企業老闆,使用台灣繁體中文,每頁只呈現一個核心重點,並在每個單元加入一個生活化案例。 這比「幫我做一份 AI 簡報」更容易驗收,因為成果形式、讀者、語言與內容密度都已經先定義。 Process Description:你希望 AI 怎麼完成?這一層描述處理流程,而不是只描述最後長什麼樣子。 例如: 先分析學員的常見痛點,再決定課程順序;接著為每個單元設計案例,最後才產出簡報大綱。每一步完成後,先列出判斷依據,再進入下一步。 如果只說「我要一份好簡報」,AI 可能直接跳到產出;加入 Process Description 後,才有機會看見它如何拆解問題。 Performance Description:AI 應該怎麼跟你合作?這一層規定的是 AI 的互動方式與工作行為,例如: 不要一味認同我的想法。 發現邏輯問題時要直接指出。 不確定時要明確說明不確定,不要自行補完。 回答保持簡潔,先處理最關鍵的問題。 如果缺少必要資訊,先提出澄清問題再開始。 因此,一個完整的 Description 不只是「角色+背景+任務+格式+限制」的固定模板,而是同時交代:要做什麼、怎麼做,以及要用什麼方式與我合作。 ③ Discernment:判斷 AI 的成品、過程與互動AI 最危險的地方,往往不是完全不會回答,而是能把錯誤內容講得非常像真的。 所以 Discernment 的核心問題不是:「AI 有沒有回答?」而是: 這個答案到底能不能用? Product Discernment:成品符合需求嗎?檢查最後拿到的成果: 內容正確嗎? 是否完整回答了問題? 有沒有捏造資料或引用? 格式與語氣符合對象嗎? 是否真的解決了原本的問題? Process Discernment:AI 的做法可靠嗎?成果看起來漂亮,不代表產出的過程可靠。以市場研究為例,仍然要檢查: 樣本是否選錯? 是否把相關性誤當成因果關係? 引用資料是否過期? 是否漏掉重要競爭者? 推論是否跳得太快? 如果研究方法不可靠,最後的報告即使排版精美,也不應該直接拿去做決策。 Performance Discernment:互動方式適合這個任務嗎?假設你希望 AI 扮演一位批判型顧問,但它每次都只回答:「這個想法很棒!」即使內容沒有明顯錯誤,它的互動表現仍然不符合需求。 因此,驗收時也要問:AI 是否按照你要求的方式合作?它有沒有指出風險、提出反例,或在不確定時停下來? Description 與 Discernment 是一個循環真正有效的人機協作,不是: Prompt → AI → 複製 → 貼出去 而是: Description → AI 產出 → Discernment → 修改 Description → AI 產出 → 再次 Discernment 例如第一輪請 AI「設計一門 AI 課程」,看完後發現內容太技術;第二輪補充「學員沒有程式背景,刪除不必要的技術內容」,結果又變得太淺;第三輪再要求「保留實作,但所有概念都用生活案例解釋」。 這就是 Description–Discernment Loop:Prompt 不是一次性的神奇指令,而是人與 AI 對話中的控制迴路。 ④ Diligence:使用 AI,最後仍然由人負責Diligence 可以翻成「盡責」。它的重點不是要求 AI 自己負責,而是提醒使用者:你選擇採用 AI,就要對最後採用的成果負責。 如果你請 AI 寫客戶提案,AI 把數字寫錯,而你沒有檢查就寄給客戶,不能把責任推回「是 Claude 寫的」。 Creation Diligence:選對工具並安全使用在建立內容或執行任務前,先確認: 公司機密是否適合貼進免費 AI? 客戶個資是否可以直接上傳? 這個模型是否適合處理目前的任務? 是否需要限制工具權限、資料範圍或可執行的動作? 這些都不是「寫得更長的 Prompt」可以取代的判斷。 Transparency Diligence:適時揭露 AI 的角色不同情境對 AI 揭露的要求不一樣。研究論文、學生作業、客戶報告與媒體內容,都可能需要不同程度的說明。 Anthropic 的 AI Fluency 課程本身就是一個具體示範:官方課程頁揭露 Claude 協助了課程架構、練習設計、草稿、評論、編輯與改寫,但最終內容仍由人類作者驗證、編輯並負責。 這提醒我們,透明不是把所有工作都推給 AI,而是讓讀者知道 AI 在流程中扮演什麼角色,以及人類做了哪些驗證。 Deployment Diligence:在發布前問自己能不能背書在按下以下按鈕之前: 發布 寄出 部署 交件 最後問自己: 如果明天有人問我「這個資料是真的嗎?」,我能不能負責? 如果唯一的回答是「AI 告訴我的」,那代表 Diligence 還沒有完成。 4D 不是瀑布流程,而是兩個互相連動的 Loop4D 很容易被誤解成「委派 → 描述 → 判斷 → 盡責」的單向清單,但實際上它不是嚴格的瀑布流程。 最明顯的循環是: Description ↔ Discernment Loop:根據驗收結果,不斷修正需求描述與合作方式。 Delegation ↔ Diligence Loop:根據風險、權限與任務結果,重新調整哪些工作交給 AI,以及哪些工作必須保留人工核准。 而且 Diligence 也不是最後才做。從選工具、提供資料、查看中間結果,到最後發布,責任與風險意識都應該一路存在。 4D 與三種人機合作模式完整的 AI Fluency Framework 不只有 4D,還包含三種人機合作模式:Automation、Augmentation 與 Agency。 Automation:AI 幫我做人先定義規則,AI 執行明確任務。例如: 幫我把這 100 筆資料依照指定欄位分類。 這類任務的重點是規則清楚、輸出容易檢查,並且要確認資料權限與錯誤處理方式。 Augmentation:AI 跟我一起做人與 AI 互相提供輸入,再由人持續做判斷。例如: 跟我一起想這堂課怎麼設計,先提出三種課程方向,再指出每種方向可能的風險。 目前許多 ChatGPT、Claude 的日常使用都屬於這種協作方式。AI 提供草稿、選項與反饋,人則負責選擇、修正與決定。 Agency:AI 代表我持續做這種模式更接近 Agent、Skills、Workflow 與 MCP: 每天讀信、分類、查 CRM、草擬回覆,符合條件時建立任務,遇到高風險情況就通知我核准。 當 AI 的自主程度提高,4D 反而更重要。因為 Agent 如果每天自動執行大量錯誤操作,問題就不再只是一次 Prompt 寫錯,而可能擴大成資料、權限、成本與客戶影響的治理問題。 為什麼 4D 比單純 Prompt Engineering 更適合教 AI 素養?工具會一直改變。今天可能是 ChatGPT、Claude、Gemini,明天可能是 Agent、Skills、MCP 或 Computer Use。 但以下四種能力不會因為工具更換就失效: 能力 你真正要學會的事 Delegation 盤點問題,決定誰做、誰核准 Description 把成果、流程與合作方式說清楚 Discernment 驗收成品,也檢查方法與互動 Diligence 管理資料、風險、透明度與責任 Prompt 是 Description 的一部分,但不是全部。只把 Prompt 寫得更長,並不會自動解決工具選擇錯誤、成果驗收不足、敏感資料外洩或責任歸屬不清等問題。 每天使用 AI 前,可以先問自己的 6 個問題如果你想把 4D Framework 變成日常工作習慣,可以在開始任務前後快速檢查: 問題是什麼? 我是否能用一句話說明要解決的問題與成功標準? 工具適合嗎? 這個任務需要搜尋、文件分析、程式執行、圖片生成或精確計算嗎? 怎麼分工? 哪些步驟由 AI 做,哪些決策保留給人? 怎麼描述? 我是否說清楚成果、處理流程與合作方式? 怎麼驗收? 我會檢查成品、方法與 AI 的互動表現嗎? 敢不敢負責? 資料、權限、揭露與最後發布是否都在可接受的風險範圍內? 這 6 個問題,比背一套固定 Prompt 模板更能幫你把 AI 用在正確的地方。 結語:真正的 AI Fluency,主要是在訓練人4D Framework 最值得學的地方,是它把「AI 工具教學」往上一層提升成「AI 工作能力」。 AI 素養不是「會不會下 Prompt」,而是你有沒有能力決定: 誰來做? Delegation 怎麼做? Description 做得好不好? Discernment 敢不敢負責? Diligence 如果要把它濃縮成一句話,就是: 真正的 AI Fluency,不是訓練 AI 取代人的判斷,而是訓練人更有意識地分工、溝通、驗收與負責。 如果你想延伸閱讀,可以先看本站的〈Claude Academy 學習路徑完整指南:22 門免費課程與 289 項資源怎麼選?〉,再搭配〈從提示詞到 Skill:5 個實務做法打造高效率 AI 自動化工作流〉理解如何把協作方法封裝成可重複使用的工作模組;若想進一步理解自主型 AI,則可參考〈AI Chatbot 跟 AI Agent 到底差在哪?一篇文講到你懂,還教你怎麼用!〉。 常見問答 (FAQ)Q1:4D Framework 跟 Prompt Engineering 一樣嗎?不一樣。Prompt Engineering 主要處理如何描述任務,是 4D Framework 中的 Description;4D 還包括任務委派、成果判斷,以及資料安全、透明揭露與最終責任。 Q2:4D Framework 是誰提出的?依本文整理的正式來源,Rick Dakan 與 Joseph Feller 發展了 AI Fluency Framework,後來 Anthropic 與兩位教授合作,將框架發展成 AI Fluency 課程。因此不宜簡化成「Anthropic 發明 4D」。 Q3:Automation、Augmentation 與 Agency 有什麼差別?Automation 是 AI 依規則替人執行,Augmentation 是人與 AI 一起完成任務,Agency 則是 AI 代表人持續執行工作流程。AI 越自主,越需要明確的權限、驗收與人工核准邊界。 Q4:為什麼使用 AI 後,最後仍然是人負責?因為人決定了任務是否交給 AI、提供了哪些資料,也決定是否採用與發布結果。AI 可以協助產出,但不能替人承擔資料錯誤、個資外洩、著作權、客戶影響或決策失誤的責任。 Q5:剛開始學 4D Framework,最簡單的做法是什麼?先在每次使用 AI 前問六件事:問題是什麼、工具適合嗎、如何分工、如何描述、如何驗收,以及最後敢不敢負責。這能把 4D 從抽象框架轉成日常工作檢查表。 參考來源 AI Fluency Framework 官方網站 Anthropic:AI Fluency Framework & Foundations Claude Academy:AI Fluency for Small Businesses Anthropic Skilljar:AI Fluency Framework & Foundations HEA:Dakan & Feller AI Fluency Framework 正式文件

  • article-Claude Academy 學習路徑完整指南:22 門免費課程與 289 項資源怎麼選?

    2026/8/22

    AI自動化 AI工具 AI Agent
    Claude Academy 學習路徑完整指南:22 門免費課程與 289 項資源怎麼選?

    如果你一直想認真學 Claude,卻不知道應該先看哪一份教學,現在其實有一個更直接的入口:Anthropic 官方的 Claude Academy。 它不是單純把產品說明文件集中在一起,而是把 Claude 的日常應用、AI Fluency、Claude Code、Agent Skills、Subagents、MCP、API 與不同職業情境,整理成課程、教學與 use case 的學習平台。 Anthropic 在官方文章中也說明,Claude Academy 的目標不只是教大家操作產品,而是協助學習者建立更安全、更有效率、更有判斷力的 AI 協作能力。你可以直接進入 Claude Academy 瀏覽課程;登入後還能追蹤學習進度與完成徽章。 本文依我在 2026 年 8 月 22 日看到的公開頁面整理。課程、翻譯、資源數量與產品功能都可能持續更新,正式開始前仍建議以平台當日顯示為準。 Claude Academy 到底有多少內容?先把最容易混淆的三個數字拆開: 22 門課程:比較完整、適合按順序完成的 learning path。 21 門目前可看到繁體中文內容:包含課程頁、單元與部分測驗/完成頁;Claude Platform 101 目前是繁中支援較不完整的例外。 289 項資源:這個數字不只包含課程,也包含 tutorials 與 use cases。 我依官方課程頁列出的單門時數相加,22 門課程約為 69.5 小時。這是把課程頁標示的觀看/學習時間加總,不代表每個人都會在相同時間完成,也不包含你自行練習、做筆記與實作的時間。 因此,看到 289 項資源時,不需要把它理解成「有 289 門課要全部修完」。比較合理的做法是先選一條符合自己工作情境的路徑,再用 tutorials 與 use cases 補實作。 22 門官方課程完整清單與時數下面的名稱保留 Claude Academy 課程頁的英文標題,方便你直接在平台搜尋。繁中欄位代表目前可看到對應的 zh-TW 課程內容;翻譯狀態可能隨平台更新而變動。 # 課程 官方標示時數 繁中內容 1 AI Capabilities and Limitations 3.5 小時 ✓ 2 AI Fluency for Builders 3 小時 ✓ 3 AI Fluency for educators 1.5 小時 ✓ 4 AI Fluency for nonprofits 4 小時 ✓ 5 AI Fluency for pK-12 Train the Trainer 45 分鐘 ✓ 6 AI Fluency for pK-12 Educators 3 小時 ✓ 7 AI Fluency for Small Businesses 4 小時 ✓ 8 AI Fluency for students 3 小時 ✓ 9 AI Fluency: Framework & Foundations 4 小時 ✓ 10 Building with the Claude API 9 小時 ✓ 11 Claude 101 2.5 小時 ✓ 12 Claude Code 101 1 小時 ✓ 13 Claude Code in Action 1 小時 ✓ 14 Claude Platform 101 1.5 小時 — 15 Claude with Amazon Bedrock 8 小時 ✓ 16 Claude with Google Cloud’s Vertex AI 8.5 小時 ✓ 17 Introduction to agent skills 1 小時 ✓ 18 Introduction to Claude Cowork 2.5 小時 ✓ 19 Introduction to Model Context Protocol 1 小時 ✓ 20 Introduction to subagents 45 分鐘 ✓ 21 Model Context Protocol: Advanced Topics 1.5 小時 ✓ 22 Teaching AI Fluency 4.5 小時 ✓ 你可以直接開啟 Claude Academy Courses 查看課程分組、lesson 數量、測驗與是否顯示 Completion badge。若想把課程、tutorial 與 use case 放在一起瀏覽,可以使用 All resources。 這套課程不只是教你怎麼用 ClaudeClaude Academy 的內容大致可以分成四個層次。 1. 先建立正確的 AI 使用觀AI Fluency: Framework & Foundations 以 4D Framework 為核心,帶你理解 Delegation、Description、Discernment 與 Diligence。換成比較容易記的說法,就是: 判斷哪些工作適合交給 AI。 把任務、脈絡與限制說清楚。 分辨 AI 輸出的品質與風險。 對最後交付的結果負責。 這也是為什麼我不建議一開始就只追求最複雜的 Agent 技術。若連任務分工、驗證與資料界線都還沒有建立,工具越強,反而越容易把錯誤放大。 2. 從 Claude 101 進入日常工作Claude 101 是一般使用者最自然的起點,內容從第一次對話、提示、Projects、Artifacts、Skills 到連接工具,逐步建立基本操作能力。 它適合先拿來處理: 文章、電子郵件與文件初稿。 會議資料與研究內容整理。 腦力激盪、規劃與比較分析。 把一個工作任務拆成可以交給 AI 的步驟。 這一層學會的重點不是「背更多提示詞」,而是知道怎麼描述目標、提供必要背景,並設計檢查結果的方法。 3. 從 Claude Code 走向 Agent 工作流技術路線會進一步出現 Claude Code、Agent Skills、Subagents、MCP 與 API。它們分別處理不同問題: Claude Code:讓 Claude 在終端機與專案檔案中工作。 Agent Skills:把可重複的知識、規則與工作方法整理成技能。 Subagents:把複雜任務拆給不同的子 Agent,並集中協調結果。 MCP:讓模型透過標準協定連接外部工具、資料與服務。 Claude API:把模型能力整合進自己的產品或後端工作流。 如果想更完整理解這些名詞,也可以先讀站內的 AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景,再回到 Claude Academy 的實作課程。 4. 依照不同角色調整 AI Fluency平台也把 AI Fluency 拆成 builders、educators、pK-12 educators、students、nonprofits 與 small businesses 等不同版本。這種設計很實用,因為「會用 AI」不是所有人都要學同一套內容,而是要對應自己的責任、資料與決策情境。 四種身分的建議學習路徑下面不是官方唯一順序,而是我依課程難度、實用性與前置概念整理出的起步方式。 路徑一:行銷工作者適合內容企劃、社群、小編、廣告投手、品牌與電商行銷人員。 建議順序: Claude 101 AI Fluency: Framework & Foundations 從 Claude Academy Tutorials 搜尋 Marketing、內容、研究與分析相關主題。 從 Claude Academy Use cases 挑 3 個最接近日常工作的案例,例如內容改寫、活動分析、客群整理或電子報規劃。 想把單次提示變成可重複工作流,再選 AI Fluency for Builders 或 Introduction to Claude Cowork。 這條路徑的重點,是先把 Claude 放進現有行銷流程,而不是一開始就追求完全自動化。你可以先要求 Claude 協助研究、整理與產出,再由人確認品牌語氣、事實、素材權利與投放風險。 路徑二:中小企業主與管理者適合需要同時處理行銷、客服、營運、文件與內部溝通的企業主或主管。 建議順序: Claude 101 AI Fluency: Framework & Foundations AI Fluency for Small Businesses 使用 use cases 找出研究、客戶資料整理、流程文件與營運追蹤等高頻任務。 確認哪些步驟可以標準化後,再學 Introduction to Claude Cowork、Claude Code 101 或 Agent Skills。 這條路徑要特別注意資料權限。把工作流程交給 AI 之前,先區分公開資料、內部資料、個資、客戶機密與財務資訊;不要因為課程示範方便,就直接把真實敏感資料貼進練習環境。 路徑三:老師與學生適合教師、教育工作者、學生與需要建立 AI 學習規範的教學團隊。 教師可以這樣安排: AI Fluency: Framework & Foundations AI Fluency for educators 或 AI Fluency for pK-12 Educators Teaching AI Fluency 依課程需求挑選教學設計、學習材料、評量與 AI 協作案例。 學生可以這樣安排: Claude 101 AI Fluency: Framework & Foundations AI Fluency for students 把 Claude 當成學習夥伴,請它解釋、提問、比較與反饋,但保留自己的推理、查證與最後提交責任。 這條路徑最重要的不是讓 AI 代寫所有作業,而是建立「哪些工作可以委派、哪些思考必須自己保留,以及如何揭露 AI 使用方式」的能力。 路徑四:想往技術方向發展的人這是我最推薦給想從一般 Claude 使用者走向 AI Agent 工作流的人。 建議順序: Claude Code 101 Introduction to agent skills Introduction to subagents Introduction to Model Context Protocol Model Context Protocol: Advanced Topics Claude Code in Action 想把能力整合到產品,再進入 Building with the Claude API。 這個順序背後的邏輯是:先學會讓 Agent 在專案裡工作,再學會把工作方法封裝成 Skill;接著理解任務拆解、工具連接與協定,最後才把整套能力組成可以重複執行、監控與驗證的工作流。 如果你已經在研究 Skill 與 Agent,也可以延伸閱讀站內的 Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness,理解模型、上下文、工具、權限與技能如何一起形成可工作的環境。 289 項資源應該怎麼挑?我的建議很簡單:不要先收藏全部,先完成一個小閉環。 先選一門主課程第一次接觸 Claude,就先從 Claude 101 開始;已經每天使用 Claude,則可以從 AI Fluency: Framework & Foundations 或符合職業的 AI Fluency 課程開始。技術背景較強的人,再從 Claude Code 101 進入。 每門課搭配一個真實但已去識別化的任務例如: 行銷人員:把一份公開活動資料整理成三種受眾版本。 企業主:把重複性的內部流程整理成 SOP 草稿。 教師:把一個單元轉成分層提問與課堂活動。 開發者:讓 Claude 先閱讀一個小型專案,再完成一個可驗證的修改。 用結果判斷是否真的學會每完成一個 lesson,不要只按下一步。至少留下以下其中一項成果: 一個自己重寫過的 prompt。 一份可以重複使用的工作模板。 一次輸出品質比較紀錄。 一個有測試、檢查與人工覆核的工作流程。 收藏清單會讓人產生「我已經開始了」的錯覺,但真正累積能力的是練習、判斷與交付。 免費課程不代表所有實作都零成本Claude Academy 的課程可以免費開始,瀏覽課程也不一定要先完成完整訂閱;但如果進入 API、Amazon Bedrock 或 Google Cloud Vertex AI 的實作,可能仍需要各平台的帳號、金鑰、權限與用量費用。 開始技術課程前,建議先確認: 是否需要 Anthropic、AWS 或 Google Cloud 帳號。 API 金鑰要放在哪裡,是否會被提交到 Git 或分享給別人。 目前使用的方案、模型與雲端資源是否會產生費用。 課程示範的程式碼是否需要依當前文件版本調整。 免費的是學習平台與課程入口,不代表外部 API、雲端服務或你投入的時間沒有成本。 完成課程可以拿到什麼?目前 Claude Academy 課程頁多數會直接標示 lesson、quiz 與 Completion badge。因此比較準確的說法是:完成符合條件的課程與測驗後,可以依課程頁提示取得完成徽章或追蹤學習進度;不是 289 項資源全部都會發正式證書。 如果你需要把學習成果放進履歷或 LinkedIn,建議在完成課程後保存: 課程名稱與完成日期。 Completion badge 或平台提供的完成頁。 自己實作的作品、流程或程式碼。 你如何驗證 AI 輸出,以及在哪些地方保留人工決策。 真正能說服別人的通常不是「我收藏過多少課程」,而是你能不能展示一個可靠、可重複、知道邊界在哪裡的工作成果。 開始前的五個提醒1. 課程數量會變動Claude Academy 是持續更新的平台,22 門、289 項與 69.5 小時都是本文整理當下的快照。未來新增課程或調整時數時,文章數字可能需要同步更新。 2. 繁中支援不代表每個畫面永遠一致目前有 21 門課程可以看到繁體中文內容,但平台仍可能在某些導覽、外部連結、特定測驗或新上線單元暫時保留英文。進入課程後,請從語言選單確認當下版本。 3. 不要把課程推薦當成產品保證Claude、Claude Code、Cowork、MCP 與 Agent Skills 都會快速更新。課程適合用來建立概念與練習方法,實際操作時仍應回到官方最新文件確認參數、權限與限制。 4. 技術路徑需要逐步增加難度如果還不熟悉終端機、Git、API 或 JSON,不需要一開始就跳進 MCP Advanced Topics。先完成 Claude Code 101 與 Agent Skills,通常會比直接複製一段 MCP 設定更容易建立可維護的理解。 5. AI 輸出仍要依風險程度驗證學會使用 Claude,不等於把判斷責任交出去。涉及法律、醫療、財務、個資、客戶承諾或正式發布的內容,都要提高查證與人工覆核的強度。 結語:真正值得學的是 AI 協作能力Anthropic 現在公開的已經不只是「Claude 要怎麼用」,而是一套從日常對話、AI Fluency 到 Agent 工作流的學習地圖。 如果你是一般使用者,從 Claude 101 開始就好;如果你是行銷人員、企業主、老師或學生,先選符合自己工作情境的 AI Fluency 路徑;如果你想往技術方向發展,則可以沿著: Claude Code → Agent Skills → Subagents → MCP → Agent 工作流 一步一步往前走。 不要因為平台免費,就把 289 項資源全部塞進收藏夾。選一條路徑、完成一門課、做出一個能在工作中使用的成果,這樣才是真的開始學會 Claude。 常見問答 (FAQ)Q1:Claude Academy 是什麼?Claude Academy 是 Anthropic 官方的 AI 學習平台,整合 Claude 日常應用、AI Fluency、Claude Code、Agent Skills、MCP、API、雲端部署與不同職業情境的課程、tutorials 和 use cases。 Q2:Claude Academy 的課程需要付費嗎?Claude Academy 的課程目前可以免費開始;登入 Claude 帳號主要用於保存學習進度與取得符合條件的完成徽章。不過 API、Amazon Bedrock、Vertex AI 等外部實作可能需要另外的帳號、金鑰或用量費用。 Q3:22 門課程都有繁體中文嗎?目前整理到的狀態是 22 門課程中有 21 門可看到繁體中文內容,Claude Platform 101 的繁中支援較不完整。平台仍會更新,實際開始前請在課程頁確認語言選項與單元內容。 Q4:完全沒有技術背景,應該從哪一門開始?建議先修 Claude 101,接著選 AI Fluency: Framework & Foundations,再依自己的身分進入行銷、小型企業、教育或學生版本的 AI Fluency 課程。暫時不需要從 MCP 或 API 開始。 Q5:完成課程可以取得正式證書嗎?目前課程頁主要標示的是 Completion badge。完成課程與測驗後,能否取得徽章以及顯示方式,應以該門課程頁與登入後的完成狀態為準;tutorial 或 use case 不一定具有相同的完成認證機制。 Q6:想學 Claude Code、Agent Skills 與 MCP,順序怎麼排?建議依序學習 Claude Code 101、Introduction to agent skills、Introduction to subagents、Introduction to Model Context Protocol、Model Context Protocol: Advanced Topics,再用 Claude Code in Action 與 Building with the Claude API 延伸到完整 Agent 工作流。 官方入口 Claude Academy 首頁 Claude Academy Courses Claude Academy All resources Claude Academy Tutorials Claude Academy Use cases Anthropic’s approach to teaching and learning AI

  • article-cangjie-skill:把書籍與長影音蒸餾成 AI Agent 可用的 Skills

    2026/8/22

    AI自動化 AI工具 AI Agent 內容行銷
    cangjie-skill:把書籍與長影音蒸餾成 AI Agent 可用的 Skills

    很多人讀完一本書、看完一支一小時的 YouTube,或聽完一集 Podcast,最後留下來的通常是一篇摘要。 摘要當然有用,但它只能回答: 這份內容說了什麼? 真正困難的問題是: 遇到什麼情境時,我應該採用這套方法?要怎麼做?什麼時候反而不該用? 這也是 cangjie-skill 有意思的地方。它嘗試把書籍、長影音、Podcast、課程、訪談、演講與長文章裡的可遷移方法論,蒸餾成一組組可以被 AI Agent 呼叫的 Skills。 從知識管理走向知識能力化傳統的知識管理,通常是把內容保存下來:筆記、摘要、逐字稿、書摘與收藏清單。這些資料能幫助我們回想,但不一定能在需要做決策時直接派上用場。 Skill 的思路則更接近一個小型決策系統:它不只保存結論,也要描述觸發條件、判斷步驟、執行方式與使用邊界。 形式 主要回答的問題 典型產出 摘要 作者說了什麼? 一篇精華文章 RAG 哪些原文與目前問題相關? 檢索結果與引用 Agent Skill 目前是否該採用這套方法?接下來怎麼做? 可呼叫、可測試的工作模組 因此,「我看過這本書」不再只是個人的記憶,而可能變成「我的 Agent 知道什麼時候使用這本書的方法做事」。 cangjie-skill 會把內容拆成什麼?一本書或一段長影音裡,不是每一句話都值得被做成 Skill。比較適合被抽取的,通常是以下幾類內容: 可以重複使用的框架與方法論 能協助判斷的原則與決策方式 能說明方法如何運作的案例 能提醒 Agent 不要誤用的反例與限制 需要精確理解的專有名詞與概念 最後的產物也不是一份很長的 Markdown 摘要,而是一個具有結構的 Skill Repository,可能包含: BOOK_OVERVIEW.md:完整內容的全局理解 INDEX.md:各個 Skill 的地圖與關聯 DIGEST.md:給人閱讀的精華長文 GLOSSARY.md:重要術語與定義 多個 SKILL.md:可以獨立呼叫的能力模組 test-prompts.json:用來驗證觸發與拒用行為的測試案例 一套 Skill 如何從長內容被蒸餾出來?官方 repository 將流程整理成 RIA-TV++。它可以理解成一條從「理解原始內容」走到「驗證 Agent 行為」的蒸餾流程。 1. 先建立整體理解先處理整份內容的結構、解釋、批判與應用,不急著看到一句金句就立刻生成 Skill。這一步的目的,是避免把脫離上下文的片段誤當成完整方法。 2. 讓不同角度的提取器並行工作流程會分別尋找框架、原則、案例、反例與術語。不同提取角度可以減少只看「漂亮結論」的偏差,也比較容易發現一套方法的前提條件。 3. 用三重驗證篩選候選方法候選內容需要經過三項檢查: 原始內容中至少有兩處相對獨立的佐證 這套方法能回答內容沒有直接說出的新問題 它具有一定獨特性,不只是一般常識 這個步驟很重要,因為不是所有作者說過的句子,都值得變成 Agent 的長期行為規則。 4. 把方法整理成可執行格式通過驗證後,Skill 需要進一步整理出原文依據、自己的重述、原始案例、未來可能遇到的觸發場景、執行步驟,以及邊界與盲點。 其中「邊界與盲點」尤其關鍵。沒有邊界的 Skill,很容易變成遇到任何問題都硬套的萬用提示詞。 5. 建立 Skill 之間的關聯有些方法彼此互補,有些方法互相衝突,有些方法則必須先使用另一個 Skill 才能成立。把這些依賴、對比與組合關係整理出來,Agent 才比較有機會選對工具,而不是只根據關鍵字做表面匹配。 6. 用誘餌題進行壓力測試test-prompts.json 不只測試「該用的時候有沒有成功呼叫」,還會故意設計不該使用該 Skill 的情境,例如: 表面上相似,但缺少必要前提 其實應該使用另一個 Skill 問題需要更多資料,不能直接套用方法 方法本身與使用者目標互相衝突 這讓驗證目標從「AI 知不知道這個知識」,提升到「AI 能不能判斷什麼時候使用,以及什麼時候拒絕使用」。 為什麼「知道何時不用」比「知道更多」重要?Agent 最危險的情況,不一定是不知道某個框架,而是知道框架後到處套用。 例如,一套適合產品定位的行銷方法,可能不適合處理個人情緒;一套適合快速實驗的創業框架,也不一定適合高風險的醫療、法律或財務決策。如果 Skill 只有步驟,沒有前提與停用條件,內容越多,誤用的機會可能越高。 因此,一個成熟的 Skill 至少要讓 Agent 能回答: 目前問題是否符合觸發條件? 還缺少哪些必要資訊? 是否存在更適合的 Skill? 哪些情況下應該停止、轉交或改用其他方法? 它和摘要、RAG 是互補關係cangjie-skill 不必取代摘要或 RAG。比較合理的分工是: 摘要負責讓人快速掌握內容全貌 RAG 負責在需要時找回原文依據 Skill 負責把方法轉成可重複執行的決策與行動流程 在實務上,Skill 仍然需要保留來源脈絡。當 Agent 要做出高風險或高成本的決策時,應該能回到原始書籍、逐字稿或案例確認,而不是把蒸餾後的版本當成不可質疑的真理。 哪些內容適合拿來蒸餾?只要內容裡存在可抽取、可驗證、可遷移的方法論,就有機會被轉成 Skill。例如: 行銷與文案書籍 YouTube 或 Bilibili 長影音字幕 Podcast 轉錄稿 線上課程與企業內訓教材 專家訪談與演講逐字稿 產品、管理或創業相關長文章 相反地,如果內容主要是個人故事、情緒抒發、一次性的新聞或缺乏可重複判斷方式的觀點,就不一定適合強行 Skill 化。保留成摘要、引用資料或背景知識,可能更誠實也更有用。 實際使用前,還是要做四項檢查來源是否可靠?字幕錯誤、轉錄遺漏、版本不完整或二手整理,都可能讓後續 Skill 建立在錯誤材料上。蒸餾前要先知道來源是原書、官方字幕、人工逐字稿,還是未經確認的轉述。 方法是否適合目前情境?作者的框架通常有它的時代、產業、角色與資源前提。能從內容抽出來,不代表可以無條件套用到所有人身上。 測試是否包含拒用案例?如果測試只有正向案例,看到 AI 成功呼叫 Skill 不能代表路由正確。至少要加入相似但不適用、資料不足、目標衝突與跨 Skill 混淆等誘餌題。 是否符合來源授權?書籍、課程、字幕與 Podcast 轉錄內容可能受到著作權或平台條款限制。實驗可以從自己擁有、取得授權或適合內部使用的材料開始,並確認 Skill Repository 的分享範圍。 從「我讀過」到「我的 Agent 會用」cangjie-skill 最值得研究的地方,是它把知識管理的終點往前推了一步。 以前我們會問: 我有沒有把這本書讀完? 現在可以多問一個問題: 這本書裡哪些方法,值得在未來的工作情境中被 Agent 正確呼叫? 這個轉變意味著,知識庫不再只是收藏與搜尋的地方,也可以逐漸變成一組可組合、可驗證、可持續修正的能力模組。 當然,Skill 化不是把所有內容都拆得越細越好。真正重要的是保留來源、清楚寫出適用邊界,並用足夠的反例確認 Agent 不會亂用。只有這樣,「看過一本書」才有機會真正變成可重複使用的工作能力。 常見問答 (FAQ)Q1:cangjie-skill 和一般 AI 摘要有什麼不同?cangjie-skill 的目標不是只濃縮內容,而是把其中可遷移的方法論拆成具有觸發條件、執行步驟、使用邊界與測試案例的 Agent Skills。 Q2:哪些素材可以拿來蒸餾成 Skill?書籍、長影音字幕、Podcast 轉錄稿、課程、訪談、演講與長文章都可以嘗試,但前提是內容中存在可抽取、可驗證、可重複使用的方法或決策框架。 Q3:為什麼測試題要加入誘餌題?誘餌題可以檢查 Agent 是否只會看到關鍵字就亂用 Skill,也能驗證它在條件不足、目標衝突或存在更適合方法時,是否能拒用或改選其他 Skill。 Q4:蒸餾完成後可以直接相信 Skill 嗎?不應該完全直接相信。Skill 仍可能受到來源品質、模型理解與方法適用範圍影響;高風險決策應保留原文依據、人工審查與必要的專業驗證。 Q5:第一次實驗適合從什麼內容開始?建議先選一堂課、一場訪談或一本會在工作中反覆使用的方法書,並以「正確觸發、正確拒用、邊界判斷與實際產出」和單純摘要加提示詞的結果做比較。 延伸閱讀 cangjie-skill GitHub repository

  • article-用 Codex 打造 AI 影片工廠:串接六大 AI 能力的完整工作流

    2026/8/14

    AI自動化 AI工具 影音行銷 Codex
    用 Codex 打造 AI 影片工廠:串接六大 AI 能力的完整工作流

    很多人問我:「現在最好用的 AI 影片工具是哪一套?」 我的答案通常是:這個問題問錯了。 真正重要的,不是哪一套工具最厲害,而是你能不能把不同 AI 的能力串成一條穩定的工作流。 現在做影片,已經不像以前一樣,只靠一套剪輯軟體完成所有工作。比較理想的做法,是讓 Codex 這類 AI Coding Agent 擔任總指揮,依照不同任務,自動呼叫適合的模型與工具。 換句話說,Codex 串接的不是工具,而是 AI 的能力(Capabilities)。工具會一直變,模型會一直更新,但能力分工、檔案規格與工作流程,才是真正值得建立的資產。 先換一個問題:你真正要建立的是什麼?如果把影片製作拆開來看,會發現「做一支影片」其實包含許多不同任務:企劃內容、設計畫面、生成鏡頭、組合素材、整理聲音與字幕,最後還要輸出成不同平台需要的版本。 這些任務不一定要由同一個工具完成。更穩定的架構,是先定義每一段需要的能力,再讓 Codex 依序傳遞中間產物。 階段 AI 能力 主要輸出 工具例 1 內容企劃 腳本、分鏡、Prompt ChatGPT 2 視覺生成 人物、場景、商品與 B-roll 圖像 GPT Image、FLUX 3 影片生成 Image to Video、Text to Video 鏡頭 Higgsfield、Seedance 2、Google Veo 4 影片組裝 字幕、動畫、配樂與完整成片 HyperFrames 5 理解與剪輯 逐字稿、精彩片段與社群版剪輯 Whisper、FFmpeg、ChatCut 6 批量生產 不同平台與資料版本的影片 Remotion 這樣的分層有一個重要好處:未來即使替換其中一個模型,也不需要把整條生產線重新設計。 Codex 如何串起整條 AI 影片工作流?整個流程可以想像成一條由中間產物連接的 Pipeline: 1234567891011ChatGPT(腳本企劃) ↓GPT Image/FLUX(圖片生成) ↓Higgsfield/Seedance 2/Google Veo(影片生成) ↓HyperFrames(影片組裝) ↓Whisper/FFmpeg/ChatCut(字幕與剪輯) ↓Remotion(批量輸出) Codex 的角色不是把所有工作都自己做完,而是讀取前一步的成果、判斷下一步需要的能力、整理檔案與指令,並在每個階段保留可檢查的輸出。這種角色比較接近製片人、技術導演與自動化流程管理者的結合。 如果你還不熟悉如何把需求拆成 AI 能理解的任務,也可以先參考GPT-5-Codex Prompting 完全指南,先建立清楚描述目標、限制與輸出格式的習慣。 第一步:建立內容企劃能力影片的第一步不是生影片,而是先把內容想清楚。 Codex 可以先呼叫 ChatGPT,協助完成: 主題發想與受眾分析 市場與內容方向整理 腳本撰寫 分鏡規劃 人物與場景設定 生圖 Prompt 生影片 Prompt 這一階段的重點,是不要只留下聊天視窗裡的一段文字,而是把成果整理成下一階段可以讀取的檔案,例如: 123script.mdstoryboard.jsonprompts/ script.md 可以保存旁白與台詞,storyboard.json 可以描述鏡頭順序、場景與畫面任務,prompts/ 則集中保存圖片與影片生成提示。當格式固定下來,後續換主題或換模型時,就不必從零開始整理。 這一步就像整個影片團隊的企劃與編劇:先決定要說什麼,再決定要怎麼拍、怎麼生成。 第二步:建立視覺生成能力腳本完成後,才開始建立畫面。依照需求,可以生成: 人物形象 場景設計 商品圖片 B-roll 素材 背景素材 GPT Image 與 FLUX 可以作為視覺生成能力的工具例。若影片需要固定角色或品牌視覺,還要額外建立一致的人物設定、服裝、色彩與場景規則,讓每一張圖片都能回到同一套視覺語言。 這一階段相當於美術設計與攝影團隊。重要的不是一次生成一張漂亮圖片,而是讓圖片能夠服務分鏡,並且能在後續影片生成與剪輯階段持續使用。 第三步:建立影片生成能力有了圖片與腳本之後,再交給影片生成模型處理動態鏡頭。常見任務包括: Image to Video Text to Video 廣告運鏡 電影感鏡頭 AI 動畫 不同模型可以依鏡頭需求分工。以這篇文章的工作流示例來看,可以先把 Higgsfield 放在人物運鏡與廣告風格的候選位置,把 Seedance 2 放在電影感或創意鏡頭的候選位置,把 Google Veo 放在高品質影片生成的候選位置。 這不是一份永久不變的模型排名。模型能力、方案與使用限制都會更新,因此比較穩健的做法,是讓 Codex 根據鏡頭類型、角色一致性、畫面風格與當下可用資源選擇模型,而不是把整個流程綁死在單一服務上。 第四步:用 HyperFrames 組裝成真正的影片生成出許多片段,不等於完成一支影片。素材完成後,還需要把內容組裝成有節奏、有品牌識別的成片,例如加入: 字幕 動畫 Logo 配樂 視覺效果 片頭與片尾 HyperFrames 可以被理解成影片組裝引擎,而不只是單純的剪輯工具。它的價值在於能把素材、版面、動畫與時間軸規則整合起來,讓 Codex 可以透過程式與 Skills 參與影片製作流程。 如果專案已安裝相應的官方 Skills,Codex 就能讀取組裝規格,依照腳本與素材產出可重複調整的影片結構。這也讓「改一個標題、換一段素材、調整一個轉場」不必每次都重新手動排版。 第五步:加入影片理解與剪輯能力如果影片工作流還包含真人拍攝素材,Codex 可以再協調 Whisper、FFmpeg 與 ChatCut,處理過去最花時間的剪輯工作: 語音辨識與逐字稿 自動建立字幕 去除停頓 找出精彩片段 合併影片 節奏調整 畫面裁切 輸出社群短影音格式 這裡的關鍵是先讓影片被「理解」,再決定要怎麼剪。逐字稿可以協助找到重點段落,時間軸與音訊資訊則可以交給 FFmpeg 或其他剪輯工具處理,最後再由 ChatCut 等工具完成更細緻的整理。 第六步:用 Remotion 建立批量生產能力當單支影片的流程穩定後,下一步就是把它變成可以重複執行的模板。 Remotion 的優勢,在於可以用程式與資料驅動影片輸出。只要保留固定的版型與動畫規則,再替換標題、圖片、數字、旁白或產品資料,就能產生不同版本的影片。 適合批量生產的內容包括: YouTube 影片 Facebook Reels Instagram Reels TikTok Shorts AI 新聞 排行榜 KPI 報表 商品介紹 每日市場資訊 如果你想深入了解用 React 與 AI Agent 程式化製作影片,也可以延伸閱讀Remotion 與 AI Agent 的程式化影片實戰教學。 批量化的重點不是一次產生很多影片,而是先把輸入資料、模板規則與輸出格式定義清楚。當資料一換就能產生不同版本,影片才真正從「一次性作品」變成「可持續運轉的內容產品」。 如何把工具流程升級成能力流程?要讓這座 AI 影片工廠長期運作,可以先建立三個原則。 1. 為每一段定義輸入與輸出每個階段都應該清楚知道自己接收什麼、產生什麼。例如內容企劃輸出腳本與分鏡,視覺生成讀取分鏡並輸出圖片,影片生成再讀取圖片與鏡頭描述。輸入輸出越清楚,替換工具時越容易。 2. 保留中間產物,不要只保存最後的 MP4腳本、分鏡、Prompt、素材、逐字稿與剪輯設定,都是未來重做與批量生產的重要資產。只留下最後一支影片,就很難追蹤問題,也很難快速產出下一個版本。 3. 先自動化一個瓶頸,再逐步擴充不需要一開始就把六個階段全部自動化。可以先從最耗時的部分開始:沒有內容就先自動化企劃,有真人素材就先處理逐字稿與字幕,已經有固定版型則先導入 Remotion。當單段流程穩定後,再把它接到下一段。 真正該建立的是能力,不是工具很多人一看到新的 AI,就開始問:「要不要換工具?」 但更重要的問題是:你的工作流是否建立在可替換的能力上? 今天影片生成可能是 Seedance 2,明天可能換成另一套更新、更快或更符合預算的模型。如果流程建立在某一套工具的操作介面上,就得跟著工具重新學習;但如果流程建立在以下能力上: 內容企劃能力 視覺生成能力 影片生成能力 影片組裝能力 剪輯能力 批量生產能力 那麼未來只需要替換其中一個模型,整條工作流依然可以持續運作。 這也是 AI 影片工廠真正有價值的地方。AI 不只是幫你做出一支影片,而是幫你建立一座可以持續運轉、持續調整、持續產生內容的生產系統。 你目前最想自動化的是哪一段?是腳本、圖片、影片生成、剪輯,還是整條工作流?歡迎留言分享你的需求,之後也可以再依照不同情境拆解更多實戰案例。 常見問答 (FAQ)Q1:Codex 會直接取代所有 AI 影片工具嗎?不會。Codex 在這條工作流裡比較像總指揮與流程協調者,負責理解任務、整理檔案、呼叫合適的模型與傳遞中間產物;真正負責生成圖片、影片、字幕或動畫的,仍然是各階段對應的模型與工具。 Q2:第一次建立 AI 影片工作流,應該先自動化哪一段?應該先從目前最耗時、最容易重複的瓶頸開始。沒有穩定內容來源,可以先從腳本與分鏡企劃開始;有大量真人素材,可以先自動化逐字稿、字幕與精彩片段整理;已經有固定版型,則可以先用 Remotion 建立批量輸出。 Q3:Higgsfield、Seedance 2 與 Google Veo 要怎麼選?應該依照鏡頭任務、人物一致性、運鏡風格、畫面品質與當下可用的方案來選擇,而不是把某一個模型視為永久最佳答案。本文的工具分工是工作流示例,實際能力與限制仍應以使用當下的官方文件與測試結果為準。 Q4:要不要一開始就把整條影片流程全自動化?不建議。比較穩健的做法是先讓一個階段穩定運作,保留腳本、品牌視覺與成片的人工審核,再逐步把已驗證的規則交給下一階段。這樣能降低錯誤累積,也比較容易找到是哪一段造成品質問題。 Q5:這套工作流可以批量產生不同平台的影片嗎?可以。只要先把版型、資料欄位、字幕規則與輸出格式定義好,就能透過 Remotion 等程式化工具替換內容,產生 YouTube、Reels、TikTok 或 Shorts 等不同版本。不過每個平台的比例、節奏與文字安全區仍應個別設計與驗收。

  • article-Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    2026/8/14

    AI自動化 AI工具 AI Agent ChatGPT
    Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    昨天看到朱騏分享一篇文章,看完之後,我最大的收穫不是 ChatGPT Sites,而是突然想到一件事: AI 正在改變的,也許不是「課程」,而是「學習」本身。 這個想法讓我重新思考,我們未來真正需要的,可能不只是更多內容,而是一套能夠陪著自己持續運作、持續調整的學習系統。 以前我們找課程,未來我們建立課程以前想學一項技能,我們第一個反應通常是: 「有沒有推薦的線上課程?」 於是開始搜尋 YouTube、買課、看書、找部落格。最後收藏了一大堆內容,卻還是不知道: 到底該先學哪一個? 真正缺少的,其實從來不只是知識,而是一條適合自己的學習路徑。 每個人的背景、目標、程度與可投入時間都不一樣。對別人來說很適合的課程順序,未必適合現在的自己;一套設計給大多數人的教材,也不一定能回應每個人的實際問題。 AI 開始把零散知識整理成個人課程朱騏分享了一個很有啟發性的做法:利用 ChatGPT Sites 搭配 AI Agent,替自己建立一套專屬的穿搭課程。 輸入自己的身高、體重、身形特徵、常穿品牌與想改善的地方之後,AI 不只是推薦幾支 YouTube 影片,而是重新整理整個知識架構,依照難度安排順序,將原本散落在網路上的內容,整理成一套真正適合自己的課程。 我覺得,這才是 AI 最有價值的地方之一。 它不只是幫你找到資料,也可以協助你回答幾個更重要的問題: 我現在在哪一個程度? 我真正想解決的是什麼問題? 哪些內容應該先學,哪些可以晚一點再學? 我怎麼知道自己是真的理解,而不是只看過? 當 AI 開始處理這些問題時,它扮演的角色就不再只是搜尋工具,而更接近學習流程的規劃者。 Learning OS 是什麼?我想到的不是 Sites 本身,而是更大的概念:Learning OS(學習作業系統)。 Learning OS 不只是存放影片、文章或筆記的地方,也不只是一份課程清單。它更像是管理整個學習流程的一套個人系統,會把目標、資源、任務、測驗與成果串在一起。 一套理想的 Learning OS,可能包含以下能力: 學習流程 Learning OS 可以協助處理的事情 了解起點 分析目前能力、背景與程度 設定方向 建立符合目標的個人化學習地圖 整理資源 整合 YouTube、書籍、文章與最新資料 安排行動 設計每天或每週的學習任務 檢查理解 透過提問、練習與測驗確認是否真的學會 累積證據 記錄作品、心得與實作成果 持續調整 根據進步、弱點與新目標重新規劃內容 今天你是新手,它可以先協助你建立基礎;三個月後,它知道你已經進步,就能安排進階內容;半年後,它也可以根據你的作品與弱點,重新規劃下一階段的學習方向。 它不是一門上完就結束的課,而是一套會隨著你改變的學習流程。 從線上課程到 Learning OS,差異在哪裡?傳統線上課程通常先設計好內容、順序與進度,再交給一群背景不同的學習者使用。這種方式適合建立共同基礎,但不一定能即時回應每個人的差異。 Learning OS 的重點,則是把客製化從「教材內容」延伸到「學習流程」: 比較面向 傳統線上課程 Learning OS 內容安排 先由課程設計者固定 依照個人目標與程度調整 學習順序 大多數人共用同一條路徑 可以依照弱點與進步重新排序 資源來源 以課程內提供的內容為主 可整合影片、書籍、文章與其他資料 完成標準 看完課程或完成章節 以理解、練習與作品成果為依據 使用期限 課程結束後通常告一段落 持續追蹤並規劃下一階段 這不代表傳統課程沒有價值,而是兩者解決的問題不同:課程提供結構化內容,Learning OS 則試著管理從起點到成果的完整學習循環。 如果你想先建立一個明確的學習起點,也可以參考既有的結構化資源,例如 微軟《Generative AI for Beginners》課程。而當學習目標是 SEO 時,新手學 SEO 完整指南 也呈現了如何把免費資源、AI 工具與階段任務整理成學習地圖。 AI Agent 在 Learning OS 裡扮演什麼角色?AI Agent 最大的價值,不只是回答問題,而是協助執行一連串有前後關係的任務。 放進 Learning OS 裡,它可以成為一位會持續工作的 AI 教練,協助完成以下流程: 先理解學習者的目標、程度與限制。 將零散資料整理成可理解的主題與學習順序。 根據可投入的時間安排每日或每週任務。 用提問、練習或小測驗檢查理解程度。 根據作品、筆記與錯誤紀錄找出弱點。 依照學習成果調整下一階段的內容。 這種工作方式,和單次問答最大的差別在於:它關注的是整段學習流程,而不是某一個當下的答案。 未來真正客製化的,不只是教材,而是學習流程過去的線上課程,只能設計給大部分的人。但每個人的背景、目標與程度都不同。 有人缺理論,需要先補基礎概念;有人缺實作,需要直接做出作品;有人只想解決眼前的一個問題,不需要從頭看完一套完整課程。 AI Agent 的價值,就是能依照每個人的需求,重新建立一套屬於自己的學習流程。真正被客製化的,不再只是教材,而是: 學什麼 先學什麼 用什麼方式學 何時練習 如何驗證理解 下一步要往哪裡走 同樣的概念,也可以應用在不同主題: 想學 AI:從基本概念、工具操作到實作專案。 想學英文:依照程度、使用情境與口說弱點安排練習。 想學攝影:從構圖、曝光到拍攝作品與回饋。 想學健身:依照目標、經驗與可投入時間安排訓練。 想學寫作或簡報:從模仿、練習到作品修正與發布。 每個主題的內容不同,但核心都是同一件事:讓學習從「收藏資料」變成「持續完成任務並產生成果」。 Learning OS 仍然需要人的參與Learning OS 可以協助整理、規劃與追蹤,但知識被整理好,不代表能力就自動建立了。 學習者仍然需要做幾件重要的事: 說清楚自己真正想達成的目標。 真的完成練習,而不是只閱讀學習計畫。 提供作品、筆記或測驗結果,讓系統知道目前狀態。 判斷哪些建議符合自己的情境,必要時修正方向。 AI 可以讓學習流程更容易開始,也能降低整理資源與安排順序的成本;但最後能不能學會,仍然取決於是否持續練習、接受回饋與把知識用出來。 AI 的下一個戰場,也許就是教育我一直認為,AI 真正厲害的地方,不只是回答問題,也不是生成內容,而是幫我們建立一套可以持續運作的系統。 工作有 Workflow,開發有 Coding Workflow,未來學習也會有自己的 Learning Workflow。 想學 AI、英文、攝影、健身、寫作、投資或簡報,都可以建立一套專屬自己的 Learning OS。它會隨著你的程度、作品、弱點與目標變化,持續調整下一步。 未來我們買的可能不是一門「上完就結束」的線上課程,而是一套能陪著自己一起成長的學習作業系統。 最後,也謝謝朱騏分享這篇文章。好的文章,不一定是直接給你答案,而是讓你開始思考更多可能性。 如果你也對這個主題有興趣,可以看看朱騏分享的原文,也許會得到不同的啟發。 常見問答 (FAQ)Q1:Learning OS 和一般線上課程有什麼不同?一般線上課程通常提供固定的內容與學習順序;Learning OS 則把個人目標、程度、學習資源、任務、測驗與成果串在一起,並根據學習進度持續調整路徑。 Q2:建立個人化 Learning OS 需要先提供哪些資訊?至少需要提供學習目標、目前程度、背景、可投入時間、想改善的問題與偏好的學習資源。若能持續提供練習作品、筆記或測驗結果,系統就更容易依照實際進步調整內容。 Q3:AI Agent 可以保證我真的學會嗎?不能。AI Agent 可以協助規劃內容、安排任務、設計問題與追蹤成果,但真正學會仍需要學習者完成練習、接受回饋,並把知識應用在作品或實際問題上。 Q4:Learning OS 適合哪些學習主題?Learning OS 適合有明確目標、需要持續累積能力的主題,例如 AI、英文、攝影、健身、寫作與簡報。只要能定義學習階段、安排練習並留下成果,就有機會建立對應的學習流程。 Q5:Learning OS 會取代老師或線上課程嗎?不一定。線上課程仍然可以提供系統化教材,老師也能提供經驗、示範與深度回饋;Learning OS 比較像是把不同資源與學習行動串起來,協助學習者更有方向地使用課程與內容。

  • article-MiniMax H3 第三條路:先租 GPU,還是該買 RTX 5090?

    2026/8/14

    AI自動化 AI工具 影音行銷 Codex
    MiniMax H3 第三條路:先租 GPU,還是該買 RTX 5090?

    最近我一直在糾結一個問題: 如果接下來要認真玩 AI 生成影片,我到底要不要買一台地端設備? 原因很簡單。 最近開始研究 MiniMax H3、ComfyUI 這類開源影片生成模型,越研究越覺得有趣。尤其模型開放之後,除了生成影片,也可以自己控制 ComfyUI Workflow、安裝節點、替換模型、調整參數,甚至進一步交給 Codex 這種 AI Coding Agent 自動操作。 問題也跟著來了:硬體怎麼辦? 以我參考的 H3 實測來看,單張 RTX 5090 就能跑起來。聽起來很好,直到查了一下 RTX 5090 的價格…… 嗯。 冷靜。 我只是想生成影片,不是準備開礦場。 後來我才發現,這不一定是「買硬體」和「買平台點數」的二選一。中間還有一條路:租一台需要時才開機的 GPU 電腦。 為什麼想玩 MiniMax H3,卻先卡在硬體?開源影片模型最吸引人的地方,是自由度突然變高: 可以修改 ComfyUI Workflow。 可以選擇不同模型、量化版本與節點。 可以讀取完整 Log,自己找出錯誤原因。 可以把生成流程串進腳本、API 或 Agent 工作流。 但自由度通常也代表環境管理成本。CUDA、PyTorch、顯示卡記憶體、模型檔案、Custom Nodes,每一項都可能成為新的排錯題目。 所以真正要比較的,不只是「哪裡生成一支影片最便宜」,而是: 我需要的是一個幫我生成影片的服務,還是一台可以由我自己控制的 AI 工作站? 第一條路:自己買 RTX 5090,換取完整控制權自己買一台足夠強的電腦,安裝 RTX 5090,再架起 ComfyUI,當然是最自由的方案。 模型放在自己的機器裡,Workflow 自己改,Custom Nodes 想裝多少就裝多少,也不用擔心平台哪一天把某個模型或節點移除。若未來想做: 1Codex → ComfyUI → MiniMax H3 → 自動生成影片 地端設備的控制權確實最高。 買設備真正貴的,不只有顯示卡一張 RTX 5090 還需要足以餵飽它的 CPU、主機板、電源、散熱、記憶體與儲存空間。整套設備的前期成本,很快就不是「買張顯卡玩玩看」的等級。 而且還有一個容易被忽略的問題:你花十幾萬買設備,不代表每天都在生成影片。 可能今天研究 H3 三小時,明天忙著上課,接下來三天根本沒碰。GPU 就坐在那裡發呆,但設備的折舊、電力、維護與佔用空間仍然存在。 如果生成需求已經穩定、每天都會使用,這些固定成本可以被大量工作攤平;如果還在探索階段,買設備就未必是最合理的第一步。 第二條路:使用 LiblibAI,省下環境管理成本我前陣子一直在看 LiblibAI(有些人也會叫它 LibTV)。這種平台最大的優點只有一句話:真的很方便。 不用處理 CUDA,不用自己安裝 PyTorch,不用管理顯示卡記憶體,也不用先下載幾十 GB 的模型。通常只要購買點數、選擇模型、上傳圖片、輸入 Prompt,就可以開始生成。 對一般使用者來說,我仍然很推薦這條路。平台把底層 GPU、模型部署與大部分環境問題包起來,學習成本低很多;如果目標只是「幫我生成一支 H3 影片」,這樣的抽象化非常舒服。 但平台服務和自己的工作站是兩件事LiblibAI 的取捨也很明確: 平台提供什麼模型,基本上就從什麼模型裡選。 Workflow、Custom Nodes 與參數能改到什麼程度,取決於平台開放的範圍。 Log、依賴套件與底層錯誤不一定能完整取得。 如果想讓 Codex 自己安裝節點、修改 Workflow、讀 Log、修錯誤再重跑,會受到平台介面與 API 能力限制。 因此,LiblibAI 比較像是租用一個「AI 影片服務」;你得到的是快速產出,而不是一台完整可控的 GPU 電腦。 第三條路:租用雲端 GPU,保留 ComfyUI 的自由度我看到一篇 MiniMax H3 的實測文章後,才意識到原來還有第三種做法:不買 RTX 5090,而是直接租一張。 作者使用 RunPod 開啟 RTX 5090 GPU 主機,掛上 ComfyUI Template,自己下載 MiniMax H3、安裝節點、查看 Log;用完後直接 Terminate。文章記錄的整個上午帳單是 US$2.07。 RunPod 公開頁面在本文整理時顯示的 RTX 5090 價格約為 US$0.99/小時、32GB VRAM。價格、庫存、區域與方案都可能變動,實際使用時仍應以當下頁面為準。 這種模式的核心概念是: 1234今天要研究 H3 → 開一台 GPU研究三小時 → 依實際使用時間付費Workflow 跑完 → 關機或 Terminate明天沒工作 → 不啟動,就不支付 GPU 運算時間 你仍然要自己處理 ComfyUI、模型、節點與 Workflow,但也因此保留了足夠的控制權。對想把 Codex 接進流程的人來說,這更接近「租一台遠端工作站」,而不是使用一個封裝好的生成按鈕。 買硬體、買點數、租 GPU:差異在哪裡? 比較項目 買 RTX 5090 LiblibAI RunPod/Vast.ai 前期成本 高 低 低 你取得的東西 自己的完整工作站 AI 生成服務 可自行管理的 GPU 主機 ComfyUI 控制 完整 依平台提供 高,依主機與方案而定 自裝節點、替換模型 可以 受平台限制 可以,仍需自己部署 Log 與錯誤排查 完整 受平台限制 通常較完整 Codex 自動控制 很適合 取決於平台 API 很適合 硬體維護 自己處理 不用處理 由供應商處理主機,環境仍由自己管理 不使用時成本 設備仍然持有 依方案與點數規則 GPU 可不用就不開,但儲存等費用需另外確認 新手難度 高 最低 中高 這張表最重要的差異,不是誰的單價最低,而是「你租到什麼」。 LiblibAI 是租 AI 影片服務。 RunPod 或 Vast.ai 是租 GPU 電腦。 RunPod、Vast.ai、SaladCloud,應該怎麼看?RunPod:先把環境與 Workflow 玩熟如果是第一次從平台生成服務轉向自建 ComfyUI,我會先選 RunPod。原因不是它一定最便宜,而是比較符合「開一台機器,自己安裝、自己觀察、自己排錯」的學習方式。 適合先完成這幾件事: 確認 MiniMax H3 在目標 GPU 上能否穩定執行。 把模型、Custom Nodes 與 ComfyUI Workflow 記錄下來。 了解模型載入、生成、輸出與下載各階段的耗時。 讓 Codex 能透過腳本或遠端指令執行固定流程。 Vast.ai:更像 GPU 版的 AirbnbVast.ai 的特色是 GPU Marketplace,價格會受到供需、主機狀態、地區與租用方式影響。RTX 5090、4090、A100、H100 等不同規格,都可能在市場上找到可租用的主機。 它的彈性與價格可能很吸引人,但選擇主機時需要更仔細檢查 VRAM、磁碟、網路、映像檔、持久化方式與實際可用性。 SaladCloud:價格低,但更適合標準化的容器工作負載原文整理的公開資訊中,SaladCloud 的 Batch RTX 5090 價格約為 US$0.25~0.294/小時,比 RunPod 公開價格低很多。 不過,價格不能單獨拿來比較。SaladCloud 比較偏向 Container 化的工作負載,不一定適合第一次研究 ComfyUI 時,想登入一台機器慢慢安裝節點、看 Log、修改環境的情境。 我的順序會是: 12345先用 RunPod 熟悉環境 ↓再用 Vast.ai 比較不同 GPU 市場 ↓Workflow 與部署容器化後,再研究 SaladCloud Codex、ComfyUI 與 H3,可以組成什麼工作流?這件事情真正讓我興奮的,不只是省下幾美元,而是 GPU 運算可以和 Agent 工作流接在一起。 例如一支 60 秒影片,可以先由 Codex 協助拆解: 1234567891011121360 秒影片 ↓拆成 4 個 15 秒 Segment ↓每個 Segment 包含 3 個 Shot ↓MiniMax H3 生成 4 段影片 ↓FFmpeg 自動合併 ↓字幕/配音/BGM ↓完成 在這個流程裡,Codex 可以負責規劃與執行腳本,ComfyUI 負責節點式生成,雲端 GPU 負責短時間的大量運算,最後再把影片抓回本機完成後製。 本機的 Mac 不需要一直負責暴力運算,只要負責指揮與驗收即可。 多鏡頭 Prompt:減少人力審片,不代表可以省略驗收原文實測提到,作者原本以為 H3 的 15 秒長影片很容易自己亂切鏡,但在 Prompt 裡加入明確的時間與鏡頭標記後,模型曾按照指定時間切換鏡頭: 12345678[Shot A] At 00:00.000桌腳低角度,空鏡[Shot B] At 00:05.000切到整個房間的大遠景[Shot C] At 00:10.000切回桌腳特寫 這個結果很值得研究,因為它代表一支 15 秒影片不一定只能服務一個鏡頭。理論上,原本的: 15 秒 × 12 次生成 可能改成: 115 秒 × 4 次生成,每次包含 3 顆鏡頭 GPU 運算量不一定比較少,甚至可能更多;但人只需要先審 4 個 Segment,而不是 12 個短片段。 這裡仍要保留一個重要前提:時間標記是值得測試的 Prompt 策略,不代表每次生成都能完全照做。正式交付前,還是要檢查鏡頭切換、角色連貫性、動作與音畫同步。 用運算時間粗估 AI 影片的邊際成本假設一支 15 秒影片的生成時間約 5 分鐘,RunPod GPU 價格以 US$0.99/小時粗估: 1235 分鐘 ÷ 60 × US$0.99≈ US$0.0825≈ US$0.08 也就是說,在「GPU 持續運算、只計算 GPU 時間」的理論模型裡,一小時大約可以跑 12 支 15 秒影片,一支影片的 GPU 運算成本約為 US$0.08。 若用原文整理的 SaladCloud Batch 價格區間估算: 125 分鐘 ÷ 60 × US$0.25~0.294≈ US$0.021~0.0245 但這些都不是完整製作成本,至少還要納入: 啟動主機與載入模型的時間。 Prompt 測試與失敗重跑。 模型下載、磁碟與持久化儲存。 上傳、下載與網路流量。 GPU 閒置但仍在計費的時間。 人工審片、剪輯、字幕、配音與配樂。 這個粗估的價值,不是宣稱每支影片只要幾美分,而是讓人看見:當 Workflow 固定下來後,真正需要優化的可能是「讓 GPU 不要等待」以及「讓人不要陪著 GPU 等待」。 三種方案,分別適合什麼人?完全不想碰技術:選 LiblibAI如果只想快速生成內容,不想處理 CUDA、模型、節點和環境依賴,LiblibAI 這類平台會是最省時間的選擇。你付費購買的是便利性與整合好的生成服務。 每天大量生成,而且需求已經穩定:計算是否值得買地端如果每天都要生成、Workflow 長期固定,而且設備會持續使用,地端 RTX 5090 才有機會透過高使用率攤平前期成本。這時候還要把電力、維護、升級與設備折舊納入計算。 想玩最新開源模型,又想讓 Codex 控制流程:先租 GPU如果和我一樣,想自己改 ComfyUI、安裝節點、替換模型、讀 Log,也不想一開始就投入十幾萬買設備,RunPod 會是一個合理的起點。 等 Workflow、Prompt、模型版本與部署方式都穩定後,再比較 Vast.ai 或 SaladCloud,甚至重新計算是否值得購買地端設備。 我的結論:先租 GPU,再決定要不要買設備我現在對這三條路的理解很簡單: LiblibAI:租用 AI 影片服務,最省環境管理時間。 RunPod/Vast.ai:租用 GPU 電腦,保留 ComfyUI 與 Workflow 的控制權。 地端 RTX 5090:購買長期使用的 AI 工作站,固定成本高但自由度最高。 所以,如果只是偶爾研究模型,我不會急著買 RTX 5090。我會先租 GPU,把完整工作流跑通,並記錄實際的 GPU 使用時間、模型載入時間、失敗重跑比例、儲存費與人工審片時間。 半年後如果真的每天大量生成,再用這些真實數據回頭計算買設備是否划算;如果新模型需要更大的 VRAM,也可以直接更換租用的 GPU,不需要賣二手顯卡、升級電源、換主機板或處理散熱。 我最喜歡這個模式的地方是:把昂貴的 GPU,變成需要時才叫來上班的臨時 AI 員工。 當 ComfyUI Workflow、Prompt、模型與 Codex 自動化都整理好之後,AI 影片製作就不再只是「使用一個 AI 工具」,而可能變成一條可以由 Agent 自動執行的生產線。 真正值得期待的,也許不只是生成一支影片便宜多少,而是 GPU 可以自己跑,人不用陪它跑。 延伸閱讀 Qwen-Image-Edit 入門教學:不用安裝也能輕鬆玩轉 AI 圖像編輯:先從線上工具理解模型與 ComfyUI 的差異。 AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景:理解 AI Agent 如何透過不同工具執行工作。 參考資料與價格提醒 MiniMax H3 第三條路|原文實測 RunPod|RTX 5090 GPU LiblibAI|AI 生成/ComfyUI 平台 Vast.ai|GPU Marketplace SaladCloud|Container/GPU 運算 本文中的價格、GPU 規格、生成時間與成本試算,都是根據提供的原文實測與公開頁面資訊整理。雲端 GPU 價格、庫存、方案、儲存與流量費用會隨時間和使用條件變動,實際使用前請以各平台當下公告為準。 常見問答 (FAQ)Q1:想玩 MiniMax H3,一定要先買 RTX 5090 嗎?不一定。如果目前仍在研究模型、測試 Workflow,或每週只使用幾個小時,可以先租用雲端 GPU;只有在生成量穩定、長期高使用率時,才值得進一步計算購買地端設備的回本時間。 Q2:LiblibAI 和 RunPod 的本質差異是什麼?LiblibAI 比較像租用整合好的 AI 影片服務;RunPod 則比較像租用一台 GPU 電腦。前者省去環境管理,後者保留 ComfyUI、模型、節點與 Log 的較高控制權。 Q3:租用雲端 GPU 後,就完全不需要處理技術設定了嗎?不是。租用 GPU 可以省下購買與維護實體硬體,但你通常仍要處理 ComfyUI、模型下載、Custom Nodes、Workflow、依賴套件、儲存空間與錯誤排查。它的難度低於自行購買整台工作站,但高於直接使用點數平台。 Q4:一支 15 秒影片約 US$0.08,是否就是完整製作成本?不是。US$0.08 只是以 5 分鐘生成時間和 US$0.99/小時 GPU 價格計算的純運算時間粗估,尚未包含模型載入、失敗重跑、儲存、網路流量、GPU 閒置與人工後製成本。 Q5:為什麼把 60 秒影片拆成 4 段 15 秒,而不是生成 12 段 5 秒?在某些能理解時間與鏡頭標記的模型中,15 秒片段可以嘗試包含多個 Shot,讓人先審 4 個 Segment,而不是 12 個短片段。這可能降低人工審片數量,但不保證運算量更少,也仍需要檢查鏡頭切換與內容連貫性。