跳到主要內容

部落格

不定期分享最新資訊文章

  • 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 個短片段。這可能降低人工審片數量,但不保證運算量更少,也仍需要檢查鏡頭切換與內容連貫性。

  • article-企業工作自動化不只有 ChatGPT!6 大 AI 自動化能力解析與導入指南

    2026/7/29

    商業策略 AI工具 AI自動化 AI Agent
    企業工作自動化不只有 ChatGPT!6 大 AI 自動化能力解析與導入指南

    為什麼企業自動化不能只靠 AI 聊天?很多人一提到 AI 自動化,第一個想到的就是 ChatGPT。但實際上,ChatGPT 只是整個企業工作自動化版圖中的其中一塊拼圖。 如果把企業每天的營運與工作流程攤開來看,你會發現真正的自動化能力,大致可以細分成六種類型。每一種類型解決的商業痛點都不同,唯有彼此互相搭配,才能形成一套完整且高效的 AI 工作流 (AI Workflow) 。 1. 如何透過「AI 助理自動化」倍增個人生產力?這是大部分人最先接觸到,也最熟悉的 AI 應用。像是 ChatGPT Projects、GPTs、Gemini Gems 等工具,都屬於 AI 助理的範圍。 它們最大的價值,在於協助個人完成「知識型工作」,例如: 知識問答與搜尋 大量文件閱讀與整理 文案與內容生成 長文摘要與跨國語言翻譯 策略企劃與腦力激盪 這項能力就像是聘請了一位全天候待命的數位助理,陪著你一起工作,從根本上提高員工每日的產出效率。 2. 「AI 技能自動化」:如何將專業 Know-how 變成專屬 Skill?如果 AI 助理是會聊天的得力助手,那麼 AI 技能 (Skill) 就像是替 AI 安裝特定領域的專業外掛。 透過如 Claude Skills、ChatGPT Plugins 等功能,企業能把一套專業方法論與邏輯封裝起來,讓 AI 每次都依照完全相同的標準流程執行。 適用場景: 封裝企業內部 SOP 產出高度格式化、規格化的報告 標準化客服與回覆流程 取代重複性高的專業審核任務 這代表 AI 不再只是隨機「回答問題」,而是將企業長年累積的經驗與 Know-how,轉化為可以無限反覆使用的數位資產。 3. 告別手工報表!「數據決策自動化」讓資料自己說話企業每天都會累積海量資料,但真正困難的是如何「快速看懂並採取行動」。像 Power BI、Tableau 等商業智慧工具,就是專門解決這類工作。 透過數據決策自動化,你可以建立: 即時更新的 KPI 儀表板 深度營運分析與預測 自動派發的高階管理報表 異常數據的即時監控系統 主管不用再苦苦等待員工每天整理 Excel,而是透過動態視覺化資料快速掌握公司營運狀況,讓決策更即時、更具科學依據。 4. 「應用生成自動化」與 Vibe Coding:讓 AI 幫你寫出專屬工具近年技術圈最熱門的趨勢就是 Vibe Coding。透過 AI 的輔助,即便是非傳統軟體工程背景的員工,也能快速建立專屬的應用: 日常作業小工具 企業內部管理系統 客製化管理平台 面向客戶的網頁應用程式與互動介面 以前需要工程團隊花上數週、甚至數月才能評估並開發完成的功能,現在透過 AI 輔助開發,可能幾小時或一天內就能產出 MVP(最小可行性產品),大幅降低企業的軟體開發與試錯門檻。 5. 打破系統孤島!「流程整合自動化」實現跨平台無縫協作企業最大的痛點通常不是「沒有系統」,而是「系統之間彼此不會溝通」。這時候就需要 Make、n8n、Zapier 這類強大的流程整合平台 (iPaaS)。 它們扮演企業數位大腦的角色,負責: 跨系統/跨平台的資料串接 條件觸發的自動化通知 跨部門資料同步更新 企業內部與外部 API 整合 實戰範例:當客戶填寫線上表單 → 系統自動在 CRM 中建檔 → 透過 Gmail 發送迎新信件 → 推送通知到業務部的 LINE/Slack → 同步更新 Google Sheets 總表。全程零人工介入,24 小時自動執行。 6. 突破舊系統限制:「桌面操作自動化 (RPA)」完成最後一哩路有些年代久遠的舊系統 (如老舊 ERP)、封閉的銀行後台系統,既沒有開放 API,也無法直接用現代化工具串接,這該怎麼辦? 這時候就需要 Power Automate、UiPath,或是近年崛起的 Computer Use、Browser Use 等 RPA(機器人流程自動化)技術。 它們能夠完美模擬真人的操作行為: 點擊按鈕與拖曳 開啟特定網站與軟體 帳號密碼登入系統 表單自動輸入與報表下載 即使系統再古老,只要「人類能用滑鼠鍵盤操作」,RPA 通常都能完美代替人工完成,補齊自動化版圖的最後一哩路。 總結:整合 6 大能力,打造專屬企業的 AI 工作流很多企業在導入 AI 時,往往只停留在第一層——把 ChatGPT 當作高級的聊天搜尋引擎。 但真正成熟且具備競爭力的數位轉型,應該是把上述六種能力進行有機整合: AI 助理自動化:賦能員工,提升個人產出。 AI 技能自動化:保存 Know-how,封裝專業技能。 數據決策自動化:即時分析,輔助管理層決策。 應用生成自動化:靈活開發,快速打造業務所需工具。 流程整合自動化:串連百大系統,建立無人工介入的運轉流。 桌面操作自動化:克服封閉系統,解決無法整合的痛點。 當這六大能力交織在一起,就能從個人層級的效率提升,擴展到跨部門的團隊協作,最終重塑企業的營運模式。AI 的真正價值,不僅是幫你回答問題,而是讓複雜的工作流程真正開始自己運轉。 常見問答 (FAQ)Q:我們公司已經購買了 ChatGPT 企業版,這樣還不算完成「AI 自動化」嗎?A:ChatGPT 企業版是非常強大的「AI 助理自動化」工具,能大幅提升個人與團隊的知識處理效率。但若要讓企業流程「自動運轉」(例如收到客戶信件自動建檔並發送報價),您還需要結合「流程整合自動化」(如 n8n、Make),將 AI 嵌入到工作流中,才算建立真正的企業 AI 自動化版圖。 Q:遇到沒有開放 API 的傳統老舊 ERP 系統,該如何達成自動化串接?A:針對無法透過 API 串接的封閉式或傳統系統,建議採用第 6 項的「瀏覽器/桌面操作自動化 (RPA)」技術。像是 Power Automate 或是支援 Computer Use 的新世代 AI 工具,能模擬真人移動滑鼠、輸入帳密並點擊按鈕,強行突破無 API 的限制。 Q:中小企業資源有限,這 6 大自動化能力應該從哪一個開始導入?A:建議採取「先個人,後流程」的策略。第一階段先從「AI 助理自動化」開始,培養員工的 AI 指令 (Prompt) 能力;第二階段盤點日常耗時最多的跨部門行政作業,優先導入「流程整合自動化」(如 Zapier / Make),針對報表轉移、自動通知進行無程式碼串接,這是成本最低且見效最快的切入點。

  • article-為什麼 Odoo 廣告狂打?AI 時代的 ERP 導入策略與自動化工作流指南

    2026/7/10

    商業策略 AI工具 AI自動化
    為什麼 Odoo 廣告狂打?AI 時代的 ERP 導入策略與自動化工作流指南

    最近滑 Facebook、Instagram,你是不是也一直看到 Odoo 的廣告?從企業主、資訊顧問到系統整合商,幾乎都被 Odoo 廣告洗版。乍看之下,它像是在推銷 ERP,但仔細觀察就會發現,它真正想推廣的是——建立一個完整的企業數位化生態系。 如果你和我一樣,過去沒有接觸過 ERP,但也開始思考 AI Agent、n8n 與自動化工作流,那麼問題來了:Odoo 會是最值得入門的第一套企業系統嗎? 我的答案是:絕對值得研究,但不要「只」研究 Odoo。 傳統 ERP 的痛點與 AI 帶來的全新契機過去,ERP 一直都是企業的高門檻大型專案。大家熟悉的 SAP、Oracle、鼎新、正航等,都有幾個共同痛點: 導入成本極高 客製化時間冗長 專案動輒半年起跳 中小企業難以負擔 但是,AI 的出現徹底改變了遊戲規則。以前要客製化一個 ERP 功能,工程師可能要花上兩週開發;現在只要善用 Codex、Claude Code 或 ChatGPT,很多 Prototype(原型)幾分鐘內就能順利產出。 也正因為如此,開源 ERP(Open Source ERP)的商業價值開始直線上升,而其中最受矚目的明星,就是 Odoo。 深度解析:為什麼 Odoo 最近狂打廣告?經過深入觀察,我統整出 Odoo 強勢崛起的五大核心原因: AI 大幅降低了客製化門檻:Odoo 本身採用 Python 開發。現在 AI 對 Python 的程式碼生成支援度極高。以前需要高薪聘請工程師修改模組,現在可以透過 AI 快速協助建立,客製成本直線下降。 模組化設計(不只是 ERP):很多人誤以為它只是傳統 ERP,但它其實包含了 CRM、銷售、庫存、採購、製造、人資、會計、POS、電商網站等獨立模組 (Modules)。你可以今天先啟用 CRM,下個月再加入客服與庫存,完全不需要無痛轉換系統。 積極建立 Partner 生態系:Odoo 的大量廣告其實不單是在找企業端客戶,更是在招募系統整合商、ERP 顧問與軟體公司加入 Partner 計畫,這與 Salesforce 和 Microsoft 長期採用的擴張策略如出一轍。 中小企業系統重構潮:許多公司至今仍在使用 Excel、Access 或老舊的 ERP。AI 時代來臨後,企業主開始思考:「既然舊系統已經跟不上,何不乾脆換一套現代化的新系統?」Odoo 自然成為首選名單。 AI Native 工作流正在成形:未來的企業核心不再是單一 ERP,而是串聯各個節點的自動化流程。ERP 只是這個生態系中的其中一個資料儲存庫。 新手必看:完全沒接觸過 ERP,該直接學 Odoo 嗎?如果你是白紙一張,我的專家建議是:不要急著學 ERP,先搞懂「企業到底怎麼運作的」。 許多人一頭熱直接安裝了 ERP,結果三天後就舉白旗放棄。因為如果你連 CRM 是什麼、Lead(潛在客戶)怎麼管理、Sales Pipeline(銷售漏斗)怎麼跑、報價單怎麼建立都不懂,龐大的 ERP 模組只會讓你迷失方向。 最好的切入點,是從 CRM(客戶關係管理)開始。 企業系統建構指南:4 階段打造 AI Native 工作流階段一:從 CRM 開始發揮 AI 價值(★★★★★)CRM 是 AI 最容易切入且發揮商業價值的地方。以下是幾款值得研究的系統: ① Twenty CRM(極度推薦):擁有現代化 UI,底層為 PostgreSQL,API 支援極其完整,具備 AI Native 思維,且非常容易與 n8n 串接。適合個人品牌、顧問與接案者。 ② Odoo CRM:如果你有長遠規劃,未來想要一路升級到完整 ERP,直接熟悉 Odoo CRM 是最合理的選擇。未來只要按鈕一開,就能依序擴充銷售、庫存與會計模組。 ③ EspoCRM:架構輕量、安裝容易,適合 10 人以下的微型企業。 ④ Cordys CRM:近期熱門的 AI Native CRM,值得持續關注。 階段二:熟悉業務邏輯後,進階開源 ERP當你熟悉 CRM 後,再將版圖擴張至 ERP: Odoo:目前全球最成熟的開源 ERP。模組最齊全、社群最龐大、基於 Python 開發,AI 客製化極度容易。 ERPNext:常被拿來與 Odoo 比較,採用更現代的 Frappe Framework 架構,對中小企業友善,在國外(尤其是印度)市佔率極高。 Dolibarr:功能單純,非常適合只有基本需求的小型工作室。 階段三:串聯 AI 自動化工作流如果你已經掌握了 n8n、LINE OA 與 Google Sheets,那麼真正具有顛覆性的應用是打造 「AI 員工」。一個標準的高效工作流長這樣: 12345678910111213LINE 接收訊息 ↓ 觸發 AI 意圖分析 ↓ 自動寫入 CRM ↓ 自動生成報價單 ↓ 建立 Google Calendar 行程 ↓ 寄送 Email 給客戶 ↓ 同步更新至 ERP 階段四:探索 AI Native 商業作業系統 (Business OS)比起傳統 ERP,我更看好低代碼/無代碼(Low-code/No-code)的企業內部系統建構工具,例如:NocoDB、Appsmith、ToolJet、Budibase、Activepieces。 它們的強項在於「快速客製企業內部應用」,再搭配 AI 輔助,許多中小企業的數位化需求甚至根本不需要動用到沉重的 ERP 就能完美解決。 實戰藍圖:我的 4 個月 AI 企業系統學習計畫如果今天我要從零開始重新學習,我會遵循以下 Roadmap: 第一個月:專注於 Twenty CRM + n8n + LINE OA,目標是建立一個「AI 業務助理」。 第二個月:開始研究 Odoo Community 版本。先只開啟 CRM、聯絡人與銷售模組,絕對先不要碰會計、製造與人資。 第三個月:導入 Codex 或 Claude Code,嘗試讓 AI 寫 Python 協助客製化專屬的 Odoo 模組。 第四個月:將所有工具串聯成完整的 AI Native Business Workflow,實現從通訊軟體到後端 ERP 的全自動化資料流。 終極目標:建構全自動的 AI Native Business Stack我真正想深度研究的,從來就不是單一的 Odoo,而是 AI Native Business Stack(AI 原生商業技術棧)。 把 Twenty CRM、Odoo、NocoDB、n8n、LINE OA 與 Claude Code 全部串在一起,讓 AI 真正接手企業冗長的工作流程,這才是未來五年內最具商業價值的數位轉型技能。 結論:跳脫單一工具,思考完整的企業自動化流程很多人看到 Odoo,只看到一套 ERP;但我看到的是 AI 正在重新定義企業軟體。未來的市場競爭,不再是比較「誰買的 ERP 比較貴」,而是:「誰能最快把 CRM、ERP、AI Agent 與自動化工作流,整合成一套真正會自動運作的企業大腦。」 如果你正打算研究企業系統,請先理解企業流程,再學 CRM,最後才進入 ERP。這樣一來,你掌握的就不只是軟體操作,而是一套能徹底解決企業痛點的 AI 工作流。 常見問答 (FAQ)Q:我完全沒有企業系統經驗,可以直接從 Odoo ERP 開始學習嗎?A:不建議直接安裝並學習龐大的 ERP。建議先從了解企業的運作流程開始,尤其是核心的 CRM(客戶關係管理)。先掌握潛在客戶管理、業務管線與報價流程,再逐步擴充 Odoo 的進階模組,這樣才不會因為過於複雜的系統介面而快速放棄。 Q:市面上那麼多系統,為什麼文章特別推薦 Twenty CRM 和 Odoo?A:Twenty CRM 具備現代化 UI 且高度支援 API 與 AI Native 思維,非常適合結合 n8n 打造個人自動化工作流。而 Odoo 則是全球最成熟的開源 ERP,採用 Python 開發,在 AI 輔助寫 code 的時代,客製化門檻大幅降低,且模組擴展性極強,適合有長遠系統升級規劃的組織。 Q:什麼是「AI Native Business Stack」,它和傳統 ERP 有何不同?A:傳統 ERP 是一個龐大、封閉且高成本的單一系統;而 AI Native Business Stack 則是將 CRM、開源 ERP、自動化工具(如 n8n)、通訊平台(如 LINE)與 AI 語言模型互相串聯,打破資訊孤島,打造出真正能自動執行跨部門業務流程的「數位 AI 員工生態系」。

  • article-AI 時代不用從零開始!20 個必看的 GitHub 開源 AI Business OS 專案

    2026/7/10

    AI工具 AI自動化 Vibe Coding Codex
    AI 時代不用從零開始!20 個必看的 GitHub 開源 AI Business OS 專案

    以前,如果想開發一套 CRM、客服系統、知識庫或工作流程平台,大部分人都會想: 「是不是要找工程師?」 但到了 2026 年,我的答案已經變成: 先去 GitHub 找找,有沒有已經做好的 AI Native 專案。 這半年,我一直在研究各種 AI Agent、n8n、自動化工作流,也開始大量使用 Codex 和 Claude Code 協助開發。我慢慢發現一件很有趣的事情:現在很多開源專案不只是免費,而是一開始就是為 AI 設計的。 它們不是傳統 SaaS 加上一個聊天機器人,而是從架構開始就考慮: AI Agent MCP (Model Context Protocol) Workflow API 串接 流程自動化 多模型整合 也就是大家最近常說的:AI Native(AI 原生)。 如果你正在學 Vibe Coding,我非常建議:不要一開始就叫 AI 幫你從零寫一套 CRM。 因為現在 GitHub 已經有很多成熟的底座,你真正要做的,是把它們完美串接起來。 什麼是 AI Business OS?中小企業的終極自動化解方我最近開始把這些工具統稱為:AI Business OS(AI 公司作業系統)。 它不像傳統 ERP 那麼龐大,也不是單一功能的 CRM。它是把公司每天會用到的工具,全部換成「AI Ready」的狀態。系統的運作邏輯如下: 12345AI Agent (負責大腦思考) │n8n Workflow (負責神經網路與流程傳遞) │CRM / 客服 / 知識庫 / 文件 / LINE / Email (負責肢體行動與資料儲存) AI Agent 負責思考,n8n 負責流程,其他系統負責儲存與互動。這就是我認為未來中小企業最容易、也最高效導入 AI 的方式。 一、AI CRM:如何用 AI 重新定義客戶關係管理?🥇 Twenty CRM(強烈推薦:原生 AI 打造)如果今天只能推薦一套 CRM,我絕對會選 Twenty CRM。它不像傳統 CRM,它從一開始就是 AI Native。它很像把 Salesforce 用現代技術重新做了一次。 核心特色: 現代化介面、GraphQL API、MCP Server 支援、AI Agent 可直接操作 CRM、Docker 輕量部署、自訂資料物件。 適合對象: AI 開發者、Vibe Coding 實踐者、Codex / Claude Code 使用者。 最佳搭配: n8n、OpenRouter、LiteLLM、Gmail、LINE OA。 🥈 Cordys CRM(專注 AI 助理與工作流)最近在 GitHub 非常熱門的新專案,主打 CRM + AI Assistant + Workflow。內建豐富的 AI 技能,例如:AI 摘要客戶對話、AI 分析商機、AI 建議下一步行動、AI 自動撰寫 Email。未來想做企業 CRM 應用的話,極具研究價值。 🥉 EspoCRM(適合傳統企業的成熟選擇)偏向傳統企業架構,發展非常成熟且 API 完整,Docker 部署也很穩定。唯一的缺點是 UI 介面稍微具有年代感。 二、AI 客服:如何打造 24 小時全自動回覆系統?很多人還在辛苦地自己寫聊天機器人,其實 GitHub 已經有極其成熟的開源方案。 Chatwoot(開源版的 Intercom)它支援全通路的客服整合,包含:Email、網站客服、LINE(透過 API)、WhatsApp、Facebook Messenger。 搭配 n8n 的自動化玩法:收到新客服訊息 ➡️ GPT 自動分類情緒與意圖 ➡️ 於 CRM 建立工單 ➡️ 觸發 LINE 通知客服人員 ➡️ 自動寄送 Email 安撫信。 整個流程幾乎不需要寫任何一行程式碼! 三、AI 知識庫:如何建置公司的第二大腦?AFFiNE(AI 版的 Notion)除了強大的文件編輯功能,它還支援 Mind Map、白板、AI 自動摘要與 AI 輔助寫作,非常適合用來製作企業內訓講義或產品說明。 Outline(企業專屬 Wiki)這套系統非常適合用來建立企業 Wiki。如果你的公司有大量嚴謹的 SOP 需要管理,Outline 絕對是首選。 四、AI 工作流:串接所有系統的核心樞紐n8n(自動化流程必備神器)這套工具已經不需要多做介紹,我現在幾乎所有 Demo 都會用它!在 AI 時代,你不一定要會寫程式,但一定要會串流程。 你可以輕鬆透過拖拉完成以下自動化:Google 表單收到新資料 ➡️ 呼叫 GPT 進行資料分析 ➡️ 在 CRM 建立客戶檔案 ➡️ 自動寄送 Welcome Email ➡️ 建立 Google Calendar 行程 ➡️ 傳送 LINE 通知給業務。 五、AI Agent 入口:統一管理你的 AI 模型Open WebUI它絕對不只是一個單純的聊天介面,而是 AI Agent 的總入口。透過它,你可以統一介面管理並串接各種模型: 本地端 Ollama OpenAI GPT Anthropic Claude Google Gemini 六、AI RAG:讓 AI 讀懂你的企業文件Dify(新手最友善的知識庫平台)如果你想建立公司專屬的 RAG(檢索增強生成)知識庫,Dify 目前仍然是我最推薦的新手平台。它支援上傳 PDF、一鍵建立知識庫、AI Chat 介面與 Workflow 視覺化設計,完全免寫程式。 七、低程式碼平台 (Low-Code):一個下午完成後台開發如果需要快速建立企業內部管理後台,我推薦以下專案: Appsmith ToolJet Budibase 只要資料庫準備好,一個管理系統往往一個下午就能拉出來。 新手該如何無痛起步?部署順序建議很多人看到 GitHub 開源專案,第一反應就是:「我不會 Docker、我也不懂 Linux!」 其實現在一點都不難。如果你跟我一樣使用像 Zeabur 這樣的現代化雲端主機,我建議第一步先這樣部署: 先裝核心基礎: n8n、Open WebUI、PostgreSQL。 循序漸進: 先不要一次裝十幾套系統,等熟悉基礎後,再慢慢加入 Twenty CRM、Chatwoot、Dify。這漾循序漸進的成就感最高,也最不容易放棄。 如何利用 Claude Code 與 Codex 加速開發?在打造 AI Business OS 的過程中,我幾乎都是這樣跟 AI 協作的: Claude Code(資深架構師): 負責規劃整體架構、撰寫 PRD(產品需求文件)、系統分析、資料庫 (Database) 設計與 Workflow 流程設計。 Codex(全天候工程師): 負責抓 Bug、新增特定功能、Code Review、Docker 環境微調與 API 串接實作。 兩者搭配起來,開發效率呈現指數型成長。 專家結論:別再重造輪子,站在巨人肩膀上起飛以前我們總覺得:「我要找人做一套 CRM。」現在,我的想法已經完全改變。 CRM、客服系統、知識庫、工作流,GitHub 上早就備妥了成熟的開源底座。你真正該投入時間思考的是: 如何讓 AI Agent 自動完成繁瑣工作? 如何用 n8n 順暢地串起所有流程? 如何讓 Codex 和 Claude Code 幫你完成 80% 的客製化開發? 如何將這些工具組裝成一套真正屬於你們公司的 AI Business OS? AI 時代最大的競爭優勢,不再是「從零開始硬幹」,而是懂得站在巨人的肩膀上,快速拼圖、優雅上線。 🚀 預告:Zeabur AI Business OS 實戰系列如果大家對這套架構有興趣,下一篇我將開啟 Zeabur AI Business OS 實戰系列!我會一步步帶大家免寫程式部署 n8n、Open WebUI、Twenty CRM、Chatwoot、Dify、PostgreSQL、Qdrant 與 LiteLLM。 我們只需要一台像 Zeabur 這樣的雲端主機,就能利用開源專案免費開始,打造一套真正能協助業務、客服、行銷與管理的 AI 員工團隊。敬請期待! 常見問答 (FAQ)Q:我完全沒有工程背景,也不懂 Docker,真的能架設這些開源專案嗎?A:絕對可以!現在有許多像 Zeabur 這樣的 PaaS 雲端服務,支援「一鍵部署」GitHub 專案。你不需要手動敲 Linux 指令或寫 Dockerfile,只要將專案匯入平台,系統就會自動幫你搞定底層環境。建議新手從部署 n8n 開始體驗。 Q:打造這套「AI Business OS」的成本會很高嗎?A:相比於購買傳統的企業級 SaaS(如 Salesforce 或 HubSpot),成本非常低。文中介紹的工具皆為免費開源專案,你只需要支付「雲端主機的租用費」以及「API 使用費」(如呼叫 ChatGPT 或 Claude 的 Token 費用),極度適合預算有限的中小企業。 Q:既然 AI 寫程式那麼強,為什麼不直接叫 ChatGPT 幫我從零寫一套 CRM?A:從零開發會耗費大量時間在「修 Bug」、「刻 UI」與「設計基礎架構」上,這不符合 AI 時代的敏捷精神。使用像 Twenty CRM 這樣成熟的開源專案作為底座,再利用 AI (如 Claude Code) 去寫 API 腳本將它們串接起來,才是目前最省時、最穩定的 Vibe Coding 最佳實踐。