跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

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

分類

標籤

商業策略 (24) AI自動化 (71) AI工具 (40) AI Agent (23) AEO (8) Cursor (2) SEO (13) 內容行銷 (20) Meta Ads (1) Vibe Coding (31) Codex (6) 影音行銷 (21) AI風險控管 (5) Gemini (10) NotebookLM (1) GEO (1) ChatGPT (12) AI繪圖 (8) n8n (28) API串接 (13) 社群行銷 (4) 自動化講師應用 (5) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Claude (3) 工作流 (1) 技術選型 (1) Electron (1) Tauri (1) Git (1) 知識變現 (4) Google (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) 資料處理 (1) Power Automate (1) 職場溝通 (2) Cloudflare (4) LINE (1)
  • article-Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness

    2026/8/22

    AI工具 AI Agent Codex
    Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness

    最近如果你有在使用 Codex、Claude Code 或其他 AI Coding Agent，應該會一直看到一個詞：Skill。 我自己這陣子也花了不少時間研究 Skill，因為它解決了一個很重要的問題：怎麼把「我做事情的方法」交給 AI。 以前我們寫 Prompt，後來開始把 SOP、規則、範例與檢查標準整理成 Skill。這樣 AI 不只是知道我們想要什麼，也開始知道一件事情應該怎麼做。 但研究 Skill 到後來，我發現下一個同樣關鍵的概念已經浮現出來了：Agent Harness。 本文把 Agent Harness 當成一個工作架構來討論。這個詞在不同社群裡未必有完全一致的正式定義，以下採用的意思是：讓 Agent 能夠取得資訊、使用工具、執行任務、處理失敗並在權限邊界內持續工作的整套環境與機制。 Skill 解決「怎麼做」，Harness 解決「怎麼工作」假設今天我要一個 AI 幫我開發網站，我可以寫一個 frontend Skill，告訴它： UI 應該怎麼設計 React 元件怎麼拆分 Accessibility 怎麼檢查 測試怎麼執行 完成前要驗收哪些事情 這些內容是在教 AI：「怎麼把前端做好。」這就是 Skill。 但接下來還有一連串問題： AI 要怎麼讀取我的專案？ 它要怎麼修改檔案與執行指令？ 哪些工具可以使用？ 執行失敗後要不要重試？ 做到一半要怎麼保留狀態？ 哪些事情可以自行完成，哪些事情一定要先詢問？ 這些就不是單一 Skill 可以解決的問題。讓 Agent 真正「工作起來」的環境、流程與控制機制，就是 Agent Harness 所處理的範圍。 模型是大腦，Skill 是 SOP，Harness 是整間公司我現在會用下面這個方式理解 AI Agent： Model → Harness → Skills → Tools / MCP → Product 如果把 AI 想成一位員工： 元件 可以怎麼理解 主要作用 Model 大腦 理解、推理與解決問題 Harness 工作環境與管理制度 提供上下文、流程、權限、狀態與錯誤處理 Skills SOP 與專業方法 告訴 Agent 某一類工作應該怎麼完成 Tools / MCP 工具與外部連接 讓 Agent 搜尋資料、操作檔案、呼叫 API 或使用服務 Product 最終工作場景 把前面的能力組合成使用者真正需要的產品 因此，Harness 決定的不是某一個專業步驟，而是這個 AI 能不能從「想」走到「做」，再從「做」走到「驗收完成」。 為什麼同一個模型，在不同工具裡差這麼多？這是很多人使用 AI Coding 工具後都會遇到的疑問：明明底層可能使用能力相近的模型，為什麼放進不同 Coding Agent，體感卻可以差很多？ 原因之一就在 Harness。 我們實際使用的從來不只是 Model，而是： Model × Context × Tools × Skills × Harness 你怎麼把檔案提供給它、怎麼讓它搜尋程式碼、怎麼讓它執行 Shell、怎麼把錯誤回饋給它、怎麼讓它修改後重新測試，以及怎麼讓它在長任務裡維持方向，都會直接影響最後結果。 所以未來比較 AI Agent 時，可能不能只問：「它用哪一個模型？」還要開始問：「它的 Harness 怎麼設計？」 為什麼 Codex 值得研究？OpenAI 的 Codex GitHub repository 是一個值得研究的 Coding Agent 實作樣本。 如果只把它看成「一個 AI Coding CLI」，可能會錯過更值得觀察的部分：一個模型是如何被組織成可以在專案裡工作的 Agent。 可以從以下幾個方向閱讀它的設計： Agent 的執行流程 Context 如何取得與整理 工具呼叫與結果回傳 Shell 與檔案系統操作 Sandbox、權限與 Approval MCP 與 Skills 的整合 長任務中的狀態與錯誤處理 這些能力加在一起，才構成一個真正可以工作的 Agent。模型本身很重要，但它只是整個系統中的一層。 Agent Harness 不只適合寫程式Agent Harness 的思維不一定只能拿來做 Coding Agent。只要一項工作需要多步驟執行、外部工具、領域規則與可驗收的結果，就可以思考如何組裝自己的工作環境。 應用方向 Harness 組合方式 可能的產品形態 SEO Agent Agent Harness＋SEO Skill＋Search Console／GA4 工具＋網站資料 SEO 分析與優化助手 Google Ads Agent Agent Harness＋投放策略 Skill＋廣告工具＋公司 SOP AI 投放助理 標案 Agent Agent Harness＋標案 Skill＋政府規範＋PDF／Excel／Drive 工具 企業內部標案助手 這時候我們做的就不只是聊天機器人，而是在替不同工作組裝不同的 AI 員工。 Skill 其實只是其中一層一開始很容易以為：「只要把 Skill 寫好，AI 就會變專業。」這句話只說對了一半。 Skill 解決的是： AI 知不知道這件事情應該怎麼做？ Harness 解決的則是： AI 有沒有能力沿著這套方法一路做到完成？ 一個 Skill 即使寫得很完整，如果 Agent 沒有讀取檔案的能力、沒有適合的工具、沒有錯誤回饋、沒有驗收流程，最後仍可能只能產生一段看起來合理的回答，而不是完成一項工作。 反過來說，Harness 也不能取代 Skill。沒有專業方法與檢查標準，Agent 可能很會操作工具，卻不知道什麼才是好的結果。 AI 產品的競爭正在改變前幾年的 AI 產品，很多競爭集中在 Prompt：誰的 Prompt 寫得好，誰的結果看起來比較漂亮。 後來大家開始做 RAG、Knowledge Base 與 Tools，接著又出現 Skills、MCP 與 Agent。下一階段的競爭，很可能會落在如何把這些元件組成一套穩定工作的系統： Model + Harness + Skills + Tools + Domain Knowledge + Product UX 模型會持續變強，工具協定也會逐漸標準化，Skill 甚至可能大量開源。最後真正拉開差距的，反而可能是你怎麼替 AI 設計工作方式，以及能不能把結果穩定交付給使用者。 開始研究 Agent Harness，可以先問這五個問題如果你想開始設計自己的 Agent Harness，可以先從這五個問題開始： Agent 需要哪些專案資料與 Context？ 它需要讀寫哪些檔案、資料庫或外部服務？ 哪些工具可以自動使用，哪些操作需要 Approval？ 指令失敗、工具回傳錯誤或結果不完整時，應該如何處理？ 任務完成的驗收條件是什麼，誰負責最後確認？ 這些問題會把討論從「我要一個會聊天的 AI」推進到「我要一個可以完成工作的系統」。 結語：從教 AI 回答，到設計 AI 完成工作如果你最近才剛開始研究 Skill，下一個關鍵字可以直接記起來：Agent Harness。 我們正在從「教 AI 怎麼回答問題」，進入「設計 AI 怎麼完成工作」的階段。 當大家都能取得差不多的模型、MCP，甚至差不多的 Skill 時，真正重要的就會變成：誰能替 AI 設計出更好的工作方式，讓它在清楚的邊界裡持續執行、修正與交付結果。 延伸閱讀： 從提示詞到 Skill：5 個實務做法打造高效率 AI 自動化工作流 AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI 的差異與應用場景 GPT-5-Codex Prompting 完全指南：從新手入門到情境實戰 常見問答 (FAQ)Q1：Agent Harness 是什麼？Agent Harness 是讓 AI Agent 能在真實環境中工作的整套環境與機制，通常包含 Context 管理、工具呼叫、檔案與 Shell 操作、狀態保存、錯誤處理、權限與 Approval，以及任務驗收流程。 Q2：Skill 和 Agent Harness 有什麼差別？Skill 教 Agent 某一類工作應該怎麼做，像是 SOP 或專業方法；Agent Harness 則負責讓 Agent 取得資料、使用工具、執行步驟、處理失敗並在權限邊界內持續完成任務。 Q3：為什麼同一個模型放在不同 AI Agent 裡，效果可能不同？因為最後結果不只由模型決定，也受到 Context、Tools、Skills 與 Harness 影響。檔案怎麼提供、工具怎麼呼叫、錯誤怎麼回饋、權限怎麼控制，都可能改變 Agent 的工作品質。 Q4：設計 Agent Harness 時，最先要處理什麼？最先要定義任務邊界、可使用的資料與工具、需要人工核准的操作，以及明確的完成與驗收條件。這些規則確定後，再決定要加入哪些 Skills 與模型能力。 Q5：Agent Harness 只能用來開發網站或程式嗎？不只能。SEO 分析、廣告投放、標案整理等工作，只要具備多步驟流程、外部工具、領域規則與可驗收結果，都可以用 Agent Harness 加上對應的 Skill 與資料來源來設計。

  • 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-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-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 最佳實踐。

  • article-如何用 AI 快速串接台灣金流？綠界科技 Skill 實戰教學

    2026/3/6

    Vibe Coding Codex
    如何用 AI 快速串接台灣金流？綠界科技 Skill 實戰教學

    大家好，我是享哥。今天要來分享一個非常實用的 Vibe Coding 擴充工具 (Skill) —— 專門用來串接台灣第三方金流的開源專案。這個工具涵蓋了台灣常見的藍新金流、綠界科技與統一金流，讓你在使用 AI 進行程式碼開發時，能更輕鬆地完成付款流程的整合。 Demo 網站展示 為什麼需要台灣金流 Skill 工具？在開發電商或銷售網站時，串接在地化金流往往是一大痛點。這個發布在 GitHub 上的開源專案 paid-tw/skills 整理了台灣主流的第三方支付模組，讓開發者可以直接透過指令將金流能力導入專案中。 無論你是使用 Claude Code、Codex 還是其他 AI Coding Agents，都可以透過安裝這個 Skill 來大幅節省查閱 API 文件與手動刻寫串接邏輯的時間。 如何快速安裝金流 Skill？你可以直接使用 npx 指令來安裝需要的金流模組。如果你不知道如何操作，也可以把 GitHub 網址直接丟給 ChatGPT，請它教你如何使用。 以下是幾種常見的安裝指令： 12345678910# 查看可用的 skillsnpx skills add paid-tw/skills --list# 選擇特定金流安裝npx skills add paid-tw/skills --skill newebpay # 只安裝藍新金流npx skills add paid-tw/skills --skill ecpay # 只安裝綠界科技npx skills add paid-tw/skills --skill payuni # 只安裝統一金流# 安裝全部npx skills add paid-tw/skills --all 實戰示範：用 Cursor 快速建立一頁式銷售網站為了驗證這個 Skill 的效果，我使用 Cursor 進行了實際測試。我請 AI 幫我建立一個一頁式的服飾銷售網站，並指定使用高品質網路圖庫。最重要的是，我要求 AI 使用剛安裝的 Skill 來建置「綠界科技」的金流功能，並預設使用綠界的測試帳號進行開發。 AI 接收到指令後，會先產出一份完整的開發計畫（包含建立 Next.js 專案、設計頁面、串接金流 API 等），接著便開始自動建置。建置完成後，我們就有了一個具備購物車結帳功能、且畫面美觀的一頁式網站。 綠界金流測試卡號與結帳流程驗證進入結帳畫面後，填寫基本資料並選擇信用卡付款，系統便會自動跳轉至綠界科技的付款測試環境。 請注意，在測試環境中，務必使用官方提供的測試信用卡號，切勿輸入真實的信用卡資訊。 綠界常用測試信用卡資料：123卡號：4311-9522-2222-2222有效年月：填寫大於今天的未來日期即可 (例如：12 / 28)安全碼：222 輸入測試卡號與姓名後，系統會要求輸入手機號碼以接收測試用的 OTP 驗證簡訊。輸入收到的驗證碼並送出，即可看到付款流程完成的結果頁面，並取得測試的訂單編號與交易編號。這些交易紀錄也都能在綠界測試金流的後台查詢到。 (小提醒：由於目前是在本地端測試，若沒有設定公開的 Webhook 回呼網址如 Cloudflare Tunnel 或 ngrok，訂單狀態可能會停留在 pending，這是正常的測試現象。) 內網穿透與後續應用因為我們是在本機測試環境，並沒有設定公開的 API 回呼網址。如果大家要在開發環境中實際接收金流狀態，推薦使用內網穿透工具。例如 Cloudflare Tunnel 就是個絕佳的選擇，能輕鬆解決回呼問題。 進階技巧：如何提升 Codex 開發的成功率？在這次測試中，我也發現了一個實用的小技巧。當我們使用 Codex 處理如串接金流這類較複雜的任務時，建議大家在介面上進行以下兩個設定優化： 提高推理程度 (Reasoning Effort)： 將模型的推理程度設定為「最高」或「超高」(Extra high reasoning depth for complex problems)。雖然 AI 思考和產出程式碼的時間會變長，但犯錯的機率會大幅降低。 開啟規劃模式 (Planner Mode)： 讓 AI 在動手寫程式碼之前，先擬定好清楚的實作步驟，確認無誤後再執行。 這兩個設定能顯著提升 AI 自動化開發的成功率。透過 Vibe Coding 結合開源的台灣金流 Skill，我們能以極高的效率完成以往繁瑣的支付串接工作。大家有興趣的話趕快去測試看看，有任何心得也歡迎一起討論！ 常見問答完全不會寫程式，也能用 AI 串接綠界科技金流嗎？可以，但前提是你願意照著步驟操作，並理解每一段流程在做什麼。這篇分享的重點不是手刻所有程式，而是善用 AI 與現成 Skill，幫你快速建立一個可運作的付款流程雛型。即使你不是工程師，也能先做出測試版，再逐步優化。 這篇教學適合哪些類型的網站？很適合一頁式銷售頁、課程報名頁、小型電商網站、活動售票頁，或任何需要信用卡付款與訂單流程驗證的專案。只要你的網站需要台灣在地金流，這種做法就很有參考價值。 為什麼要搭配台灣金流 Skill，而不是自己從頭研究 API？因為自己從零研究第三方支付文件，通常要花很多時間理解欄位、簽章、測試流程與回呼設定。透過已整理好的 Skill，能先把常見整合邏輯快速建立起來，再把時間放在畫面設計、商業流程與例外處理上，效率會高很多。 綠界科技測試環境可以直接用真實信用卡付款嗎？不行。測試環境只能使用官方提供的測試卡號與測試流程，不能輸入真實信用卡資訊。你應該先在測試環境完成流程驗證，確認訂單建立、付款頁跳轉與回傳資料都正常後，再進一步處理正式環境設定。 如果金流付款成功，但網站沒有收到訂單狀態更新，通常是什麼原因？最常見的原因是本機開發環境沒有公開可被綠界回呼的網址，因此金流平台雖然完成付款頁流程，網站後端卻收不到伺服器通知。這時可以透過 Cloudflare Tunnel、ngrok 等內網穿透工具，先建立測試用公開網址來驗證回呼機制。 用 AI 做金流串接，還需要自己檢查哪些重點？需要。像是訂單金額是否正確、測試與正式環境參數是否分開、回呼網址是否可連通、付款成功與失敗頁是否正常導回、敏感金鑰是否妥善保管，這些都還是要人工確認。AI 可以大幅加快開發，但不能省略驗證與安全檢查。

  • article-GPT-5-Codex Prompting 完全指南：從新手入門到情境實戰

    2025/9/25

    Vibe Coding Codex
    GPT-5-Codex Prompting 完全指南：從新手入門到情境實戰

    資料來源：GPT-5-Codex Prompting Guide 為什麼要學習 GPT-5-Codex Prompting？如果你是程式新手，常常遇到「不會寫」、「不懂錯在哪」、「怎麼轉換語言」的困擾，GPT-5-Codex 就像一個會幫你補全、解釋、改寫、測試程式的好夥伴。這份指南的重點在於： 少即是多：不要塞太多廢話，直接告訴模型你要什麼。 明確任務：用一句話清楚定義需求。 用程式碼區塊：把程式碼放在 ``` 裡面，模型讀得更準確。 指南閱讀重點：如何快速上手？ 先看模式分類 → 知道常見用途（補全、轉換、解釋、修正）。 再看提示設計原則 → 學會怎麼下指令。 最後看範例 → 複製幾個試試看，邊練習邊體會。 把它當成一本「範例字典」，要用什麼就翻到那一段。你不需要一次全記住，只要知道它能幫你做什麼。 新手入門實戰路徑1. 從最簡單的補全開始試著給一個不完整的程式，請模型幫你補齊： 1def fibonacci(n): # 請補齊遞迴版本 👉 模型會自動幫你完成。 2. 嘗試解釋程式碼如果你看不懂某段程式，可以讓模型解釋： 123解釋以下 Python 程式碼的功能：s = "hello"print(s[::-1]) 👉 模型會告訴你這是反轉字串的寫法。 3. 動手除錯給一段有 bug 的程式，請模型幫忙修正： 123找出以下 Python 程式碼錯誤並修正：def add(a, b): return a - b 👉 模型會改成正確的 a + b。 4. 嘗試轉換程式語言想學不同語言，可以試著轉換： 123將以下 Python 程式轉換成 JavaScript：for i in range(5): print(i) 👉 模型會輸出 JavaScript 版本。 實戰情境應用：讓 AI 成為你的專屬助教理論看完了，讓我們看看在真實學習場景中，Codex 能如何幫你。 情境一：我想寫個小工具，但不知從何下手假設你想寫一個 Python 小爬蟲，抓取某個網頁的所有圖片連結，但你完全沒頭緒。 你可以這樣問： 1234567# Python# 寫一個函式，接收一個 URL 作為參數# 功能是：# 1. 使用 requests 函式庫抓取網頁 HTML 內容# 2. 使用 BeautifulSoup4 函式庫解析 HTML# 3. 找出所有 <img> 標籤的 src 屬性# 4. 回傳一個包含所有圖片 URL 的列表 💡 學習點：即使你不會寫，但只要能用文字描述出「步驟」和「想用的工具」，Codex 就能幫你生成初步的程式碼，讓你從「無」到「有」，再從範本去修改和學習。 情境二：在 GitHub 看到一段酷炫程式碼，但完全看不懂看到一段 JavaScript 特效程式碼，你想學習它的原理。 你可以這樣問： 1234567# 解釋以下 JavaScript 程式碼# 請逐行為我加上中文註解，並在最後總結它的功能// 貼上你看不懂的程式碼...const arr = [1, 2, 3];const double = arr.map(num => num * 2);console.log(double); 💡 學習點：Codex 是絕佳的程式碼閱讀器。它能幫你把複雜的邏輯拆解成易懂的語言，讓你專注於理解演算法和設計模式，而不是卡在語法細節。 情境三：我的函式寫好了，但要怎麼測試它對不對？你寫好了一個判斷電子郵件格式是否正確的函式，但你不確定是否考慮了所有情況。 你可以這樣問： 12345678910# 我寫了一個 Python 函式 is_valid_email# 請幫我使用 pytest 框架，為它產生 5 個測試案例# 包含 3 個應該通過的正確 email 格式# 以及 2 個應該失敗的錯誤 email 格式def is_valid_email(email): import re # 一個簡單的 regex 範例 pattern = r"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$" return re.match(pattern, email) is not None 💡 學習點：透過讓 AI 產生測試案例，你可以學到如何從「測試者」的角度思考，找出程式的邊界條件與潛在漏洞，這對寫出更穩健的程式非常有幫助。 新手常見問答 (FAQ)Q1: 為什麼模型給我的答案是錯的或不完整？🤔 答： 最常見的原因是「提示不夠精確」。請檢查： 任務是否單一：避免在一個提示中要求太多事。例如，不要同時要求「寫程式、加註解、產生測試、還要解釋」。一次只做一件事。 上下文是否充足：如果你在處理一段既有程式，記得把相關的程式碼片段也貼給它。 是否有給予範例：如果你想要特定的輸出格式，可以先給它一個範例（Few-shot prompting），它會學得更快。 Q2: 我可以直接複製貼上 AI 產生的程式碼嗎？✅ 答： 絕對不要！ 請將 AI 視為一位資深但偶爾會出錯的顧問。它給的程式碼可能有以下問題： 安全漏洞：可能包含不安全的寫法。 版本問題：可能使用過時的函式庫或語法。 邏輯錯誤：在複雜情境下可能存在 Bug。 最佳實踐：先讀懂它給你的程式碼，理解每一行的作用，然後親手測試、修改，最後才整合到你的專案中。 Q3: 使用 AI 寫程式，會不會讓我變懶、學不到東西？🧠 答： 這完全取決於你「如何使用」它。 錯誤用法：把它當作答案產生器，只會複製貼上。 正確用法：把它當作學習加速器。卡關時，請它給你方向；看不懂時，請它解釋給你聽；寫完後，請它幫你優化或找出錯誤。 關鍵在於保持好奇心，把 AI 的輸出當成學習素材，而不是最終答案。 核心心法總結 從簡單的任務開始（補全、解釋）。 每次只做一件事（避免複雜要求）。 漸進擴充（debug → 重構 → 測試）。 多動手練習，模型就是你的即時教練。 👉 建議：每天花 10-15 分鐘，用 Codex 解決一個你在學習上遇到的小問題，無論是搞懂一個語法，還是寫一個小功能，持續累積會讓你進步飛快。