部落格

不定期分享最新資訊文章

徐享／享哥

AI應用規劃師

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

AI工具 (85) ChatGPT (19) 商業策略 (32) AI自動化 (87) AI Agent (49) SEO (13) AEO (8) 內容行銷 (27) Cursor (2) Vibe Coding (45) Codex (17) MCP (3) 影音行銷 (47) Gemini (11) AI Coding (2) Meta Ads (1) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) AI繪圖 (8) n8n (29) API串接 (13) 社群行銷 (4) 自動化講師應用 (6) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Cloudflare (6) Claude (6) Claude API (1) AI創業 (1) 工作流 (1) 享哥宇宙 (10) 科幻喜劇 (8) AI故事 (8) Seedance (2) 技術選型 (1) Electron (1) Tauri (1) 奇幻喜劇 (2) 台灣民間信仰 (2) Git (1) 知識變現 (4) Google (1) Google Colab (1) Google Vids (1) GSAP (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) 資料處理 (1) 個人品牌 (1) Power Automate (1) Playwright (1) 職場溝通 (2) LINE (1) 雲端部署 (1)

2026/10/20
AI工具 AI自動化影音行銷

【Openverse API 教學】用 Codex 自動搜尋影片圖片、音樂與音效

用 AI 製作影片時，腳本和旁白可能很快就準備好了，接下來卻常要花時間搜尋圖片、背景音樂與環境音效。像是要剪一支 AI 發展史短片，就可能需要老電腦、科技場景和鍵盤聲等素材。 Openverse 是一個搜尋開放授權與公眾領域作品的服務，也提供 API。本文會示範如何用 Codex 建立本機搜尋工具，讓它按照影片腳本整理素材候選、預覽資訊和授權紀錄。流程會保留人工挑選：搜尋結果不等於授權已核實，也不會自動下載或剪成影片。 Openverse、Codex 與 FFmpeg 各自負責什麼？整套流程可以想成一條素材工作線：Codex 先把腳本拆成分鏡與搜尋詞，再透過 Openverse API 找出圖片和音訊候選；你確認內容和授權後，才下載、整理素材，最後交給 FFmpeg 或其他剪輯工具。名詞白話說明 API 讓程式向服務查詢資料的介面。 JSON 常見的結構化資料格式，可保存素材標題、作者、來源和授權欄位。 FFmpeg 可用指令處理、轉換及合成影音的開源工具。 Openverse 目前直接搜尋圖片與音訊；影片素材會由外部來源提供，因此不能把它當成可直接搜尋、下載 MP4 的影片庫。Openverse 官方介紹開始前要準備哪些工具？本文以 macOS 為例，會用到： Codex CLI 或 Claude Code，擇一即可。本文的提示詞以 Codex 專案工作流為主。 Python 3，用來執行本機搜尋工具。 FFmpeg，等素材確認後再用來處理影片。網路連線，用來查詢 Openverse API。如果已安裝 Homebrew，可在終端機安裝 Python 和 FFmpeg： 1brew install python ffmpeg 確認工具可用： 12python3 --versionffmpeg -version Openverse API 可以匿名查詢，初步試用不必先申請 API 金鑰；不過匿名與註冊使用者都有速率及資料瀏覽限制。若要提高呼叫量，再依官方 API 文件註冊應用程式並遵守服務條款。Openverse API 文件先用 curl 試搜圖片與音訊先確認電腦能收到搜尋結果，再請 Codex 建工具。圖片查詢範例： 123curl -G "https://api.openverse.org/v1/images/" \ --data-urlencode "q=technology" \ --data-urlencode "page_size=3" 其中 q 是搜尋詞，page_size 是每頁回傳的結果數。搜尋音訊可以改用 /v1/audio/，例如查找雨聲： 123curl -G "https://api.openverse.org/v1/audio/" \ --data-urlencode "q=rain" \ --data-urlencode "page_size=3" 回應是 JSON，可能包含標題、作者、授權名稱與版本、原始作品頁面、媒體網址及縮圖等欄位。實際欄位會依素材和 API 版本不同；請以當下 API 文件與回應為準。若收到 429 Too Many Requests，代表碰到速率限制，應減少請求並稍後再試，不要用大量翻頁或反覆重試來抓取整個目錄。Openverse 條款禁止以 API 爬取資料集。讓 Codex 建立本機素材搜尋工具建立專案資料夾並啟動 Codex： 123mkdir -p ~/Projects/openverse-videocd ~/Projects/openverse-videocodex 接著貼上這段提示詞。它要求 Codex 先做搜尋與預覽，不自行下載素材，也不安裝額外套件： 123456789101112131415161718192021222324請在目前專案建立一個 Openverse 圖片與音訊搜尋工具，供影片分鏡挑選素材使用。實作要求：1. 使用 Python 標準函式庫呼叫 https://api.openverse.org/v1/images/ 與 /v1/audio/。2. 提供簡單的命令列介面，可指定 images 或 audio、搜尋詞、每頁筆數和授權篩選。3. 將結果整理成 JSON，保留 id、title、creator、creator_url、license、license_version、license_url、foreign_landing_url、url、thumbnail 等 API 有提供的欄位；另記錄搜尋詞和查詢時間。4. 產生可在本機開啟的候選預覽頁，清楚顯示縮圖、標題、作者、授權和原作品頁連結。輸出外部文字時要做 HTML escaping。5. 429 或網路錯誤時顯示清楚訊息；不要無限重試或大量翻頁。6. 只搜尋及產生預覽，不下載媒體、不合成影片、不把結果宣稱為已完成授權確認。7. 不安裝套件、不讀取或建立 API 金鑰、不修改專案以外的檔案。若你認為需要新增依賴，先說明原因並等我同意。建議目錄：openverse-video/├── main.py├── README.md├── assets/│ ├── images/│ └── audio/├── metadata/│ └── attribution.json└── previews/ └── index.html請先檢查目前專案，再列出預計建立的檔案與查詢流程；確認後再實作。完成時提供一組只會搜尋少量結果的本機操作範例。 API 結果可用來做候選清單，但不代表媒體網址一定可下載，也不代表欄位中的授權一定正確。預覽頁應保留原作品頁，方便回到來源核對。用影片腳本產生分鏡與素材候選假設要製作一支 60 秒的直式短片，主題是「AI 如何改變我們的工作方式？」可以先把腳本拆成五段，再替每段產生數個英文搜尋詞：時間畫面方向搜尋詞範例 0–10 秒傳統辦公室與紙本文件 old office, paperwork 10–20 秒電腦與科技發展 computer technology, early computer 20–35 秒 AI、自動化與機器人 artificial intelligence, robotics 35–50 秒人們使用電腦工作 people working with computers 50–60 秒未來城市與科技 futuristic city, technology 可以把腳本貼給 Codex，再給它以下指令： 12345678我要製作一支 60 秒、9:16 直式的知識型短影音，主題是「AI 如何改變我們的工作方式？」請先把腳本拆成 5 個分鏡段落，每段列出畫面描述、2–4 個英文搜尋詞、建議素材類型與畫面停留時間。接著使用目前專案的 Openverse 搜尋工具：1. 每段搜尋最多 5 張圖片候選。2. 另外搜尋最多 3 個適合的音樂或音效候選。3. 只把授權欄位符合我指定條件的結果列為候選；缺少授權資料的結果標示「待確認」，不要自行補值。4. 建立 storyboard.json 和本機素材預覽頁，列出作者、來源頁、授權名稱與版本。5. 不要下載素材、不合成影片。先讓我檢查畫面和授權，再等我選擇。搜尋詞可以由 AI 根據腳本翻譯或延伸；候選內容則要由人檢查是否切題、解析度是否足夠、來源頁是否仍有效，以及授權是否符合影片用途。先確認授權，再下載與整理素材Openverse 聚合了不同來源的作品，也會呈現授權與署名資訊；但 Openverse 不會逐一核實每件作品的授權是否準確或署名是否完整。使用前要點回原作品頁，查看當前授權、作者名稱及來源資訊。Openverse 授權說明常見 Creative Commons 標示可以先這樣理解： BY：使用時須依條件標示作者。 NC：限非商業用途；若影片有營利或商業推廣情境，要特別檢查。 ND：不得散布改作版本；若要裁切、混音或整合進影片，先確認這種使用是否允許。 SA：散布改作作品時，須遵守相同或相容的授權條件。 CC0：作者以公眾領域貢獻方式放棄權利，但仍建議留下來源紀錄。 Creative Commons 授權也不一定涵蓋肖像、商標、隱私或其他第三方權利。詳細條件依作品使用的授權版本與來源頁為準。Creative Commons 授權說明確認要使用的作品後，再下載到專案資料夾。建議每筆素材至少保留： 12345678910111213{ "title": "作品標題", "creator": "作者名稱", "creator_url": "作者頁網址", "license": "授權名稱", "license_version": "授權版本", "license_url": "授權網址", "foreign_landing_url": "原作品頁網址", "media_url": "下載的媒體網址", "search_query": "使用的搜尋詞", "retrieved_at": "查詢或下載日期時間", "local_file": "assets/images/檔名.jpg"} 實際欄位可依 API 回應調整；請保留當時取得的原始資訊，並記錄你選用了哪個檔案。這樣日後替換素材或檢查署名時，能追溯到作品來源。把已確認素材交給 FFmpeg 剪輯素材經過挑選、下載及授權核對後，才進入剪輯。FFmpeg 適合做基本合成與批次處理；需要細緻調色、混音或逐格調整時，也可以改用 DaVinci Resolve、Remotion 等工作方式。各工具的安裝與操作方式會依電腦環境而不同。給 Codex 的剪輯指令可以寫成： 123456789101112請只使用 storyboard.json 中標記為「已確認」且已下載的本機素材，先整理剪輯計畫，包含素材順序、各段秒數、Ken Burns 推近或平移效果、轉場、旁白和背景音量。目標規格：- 長度：60 秒- 畫面：1080 × 1920、9:16- 輸出：MP4、H.264、30 FPS- 依 storyboard.json 排列素材，避免人物或重要物件被裁切。- 若沒有旁白音檔，輸出無旁白版本；不要假裝已產生配音。- 使用已確認授權的音樂與音效，並整理 credits.md。- 輸出影片與檢查報告到 outputs/。請先顯示剪輯計畫，等我確認後再開始渲染。若素材、檔案或授權狀態不清楚，先提出問題，不要自行替換。不要只看 FFmpeg 是否回報成功；輸出後仍要檢查影片長度、解析度、聲音、字幕與畫面裁切，並實際播放確認結果。把重複流程整理成 Codex Skill如果每次都要重新說明搜尋和授權規則，可以把確認過的流程整理成專案內的 Skill，例如： 123456789.agents/skills/openverse-media/├── SKILL.md├── scripts/│ ├── search_media.py│ ├── download_media.py│ └── check_license.py└── references/ ├── api.md └── license-policy.md 往後可以用一句話啟動，例如：「請依影片腳本整理 Openverse 圖片與音訊候選，保留授權紀錄並等我確認。」Skill 應清楚說明它能搜尋哪些媒體、把檔案存在哪裡、如何保存署名，以及哪些動作必須等使用者確認。不要讓自動化跳過授權核對或擅自使用付費服務。從 V1 開始，逐步擴充剪輯工作流可以分三階段建置： V1 素材搜尋助理：依分鏡搜尋候選、預覽並整理授權資訊；先驗證搜尋與紀錄流程。 V2 剪輯助理：在人選定並核對素材後，加入旁白、字幕、音樂、轉場與 FFmpeg 輸出。 V3 素材庫：整合其他授權來源、素材去重、快取與重複使用紀錄；再次使用素材時仍要保留原授權條件。第一次先把 V1 做穩，比一開始就要求 AI 自動完成整支影片更容易檢查和修正。延伸閱讀：AI 影片製片 SOP：從分鏡到粗剪、從 Prompt 到專家 Skill 的 AI 影片工作流。常見問答 (FAQ)Q1：使用 Openverse API 需要申請金鑰嗎？基本搜尋可先用匿名請求，不必一開始申請 API 金鑰；但匿名使用也有速率和資料瀏覽限制。若應用需要較高呼叫量，再查看官方註冊與授權方式。 Q2：Openverse API 可以搜尋影片嗎？Openverse 目前直接搜尋圖片和音訊；影片搜尋由外部來源提供。本文的工作流以圖片、音樂和音效候選為主，不會直接從 Openverse 搜尋 MP4 影片檔。 Q3：Openverse 找到的素材都能商用嗎？不能一概而論。每筆作品有不同授權，而且 Openverse 不保證作品授權或署名資料完全正確。要回到原作品頁核對授權條件、作者與其他可能涉及的權利。 Q4：可以讓 Codex 找到素材後直接下載和剪片嗎？可以請 Codex 建立搜尋、下載和 FFmpeg 處理工具；但建議先預覽候選並人工確認素材內容與授權，再允許下載或渲染，避免把錯誤的授權資訊一路帶進成品。 Q5：第一次應該先做哪一部分？先完成素材搜尋、候選預覽和署名紀錄。確認這些步驟可靠後，再增加自動下載、分鏡排列、字幕與影片渲染。相關資源 Openverse 繁體中文網站 Openverse API Openverse GitHub 專案 Openverse 開發文件 Creative Commons 授權說明
2026/10/19
AI工具影音行銷

AI 影片打光教學：從 8 種光線到三點布光、倫勃朗光

同樣是 AI 生成的人物，有些畫面像電影，有些卻像塑膠公仔。提示詞明明寫了「電影級畫質、超高解析度、專業攝影」，成品還是少了想要的氛圍。很多時候，差別不只在模型，而在光線有沒有說清楚。我最近看到一張整理八種電影打光技巧的圖片，裡面提到頂光、逆光、丁達爾光、蝴蝶光、柔光、硬光、側光和底光。這也讓我想到，學會生成圖片與影片之後，還可以補一些真正的攝影知識：什麼光線適合什麼情緒，畫面為什麼看起來立體，觀眾又會先注意到哪裡。 AI 可以幫忙生成畫面，但我們仍需要判斷什麼畫面好看、光線是否合理，以及它想說什麼故事。這篇就從八種常見光線開始，再介紹三點布光、倫勃朗光與適合新手的練習方式。不必先買攝影燈，也不需要背完所有術語；有常用的 AI 圖片或影片工具，就能開始比較練習。為什麼光線會改變畫面情緒？想像一位女生獨自坐在房間裡看手機。人物、服裝與場景都不變，只調整光線：溫暖柔光可能讓畫面顯得療癒；窗邊側光像是在思考；強烈逆光能做出人物即將登場的感覺；手機從下方照亮臉部，則可能變得詭異。打光不只是把人物照亮，也能引導注意力、塑造立體感，並傳達故事情緒。開始下提示詞前，可以先想五件事：方向：光從正面、側面、背面、上方還是下方照來？軟硬：陰影邊緣是柔和漸層，還是清楚銳利？強度與對比：亮部和暗部差多少？陰影要保留多少細節？色彩：光偏暖、偏冷，還是冷暖混合？來源：畫面中的光從哪裡來，方向是否符合場景？柔光不等於亮度弱，硬光也不等於亮度強；兩者主要描述陰影的過渡方式。陰天的天空像大型柔光源，直射的中午陽光則容易形成邊界清楚的影子。畫面偏暖或偏冷，也會受到光源、白平衡和後製調色影響。鎢絲燈約 3200K、日光常以約 5600K 作為參考，但實際色溫會因光源而異。「動機式打光」（Motivated Lighting）則是讓光線看起來有合理的場景來源。例如沒有窗戶、也沒有開燈的房間裡，人物臉上若出現一大片強烈陽光，觀眾可能會覺得不自然。因此，除了寫「側光」，也可以交代「午後光線從人物左側窗戶照入」。八種常見光線：先看方向與陰影這八種名稱不是同一種分類。頂光、逆光、側光和底光描述方向；柔光、硬光描述陰影性質；蝴蝶光是人像布光模式；體積光則描述光束在霧、塵等介質中可見的效果。它們可以搭配使用，不必八選一。 01｜頂光：壓迫、權力與孤獨光從上方照下來，眼窩和下巴容易形成陰影，人物可能顯得嚴肅或有壓迫感。可用於審問、懸疑、黑幫或角色陷入困境的場景。 1一位身穿黑色西裝的中年男性獨自坐在昏暗會議室中央，頭頂唯一的吊燈向下照射，額頭和肩膀較亮，眼窩與下巴留下深色陰影，背景逐漸隱入黑暗。 02｜逆光：輪廓、希望與登場感光源位於人物後方，頭髮或衣物邊緣可能形成明亮輪廓。若正面沒有補光，人物也可能成為剪影。可用於英雄登場、夕陽告別或故事轉折。 1一位披著長披風的劍客站在山頂迎向夕陽，金色逆光勾勒頭髮與披風邊緣，正面保留少量柔和補光，遠方雲海翻騰。 03｜體積光：讓光束在空氣中可見陽光穿過森林、霧氣中的車燈，或教堂窗戶投下的光束，都是常見的影像效果。電影與電腦圖學常用「體積光」（Volumetric Lighting）、「God Rays」或「Light Shafts」描述這類可見光束。「丁達爾效應」是光被微粒散射的物理現象，常被創作圈用來形容光束穿過薄霧或塵埃的畫面；若要讓影像模型理解場景，可以直接描述光束、霧氣、塵埃與光源位置。 1古老教堂的彩繪玻璃窗透進金色陽光，空氣中有薄霧與細微塵埃，數道清楚可見的體積光束落在中央石製祭壇上，氛圍安靜而神聖。 04｜蝴蝶光：優雅、精緻的人像主光放在人物正前方、略高於眼睛的位置，再往下照。鼻子下方通常會出現小型蝴蝶狀陰影，因此也稱為 Paramount Lighting。常見於美妝、時尚與形象照。 1時尚女性站在攝影棚中，主光位於鏡頭正前方略高處，臉部受光對稱，鼻子下方形成小型蝴蝶狀陰影，顴骨輪廓自然清楚，搭配柔和下方補光。 05｜柔光：親切、自然與療癒柔光的陰影邊緣較模糊，明暗過渡平順。窗簾後的日光、陰天的天空，常能呈現這種效果。適合日常生活、人物特寫、品牌形象或講師影片。 1一位年輕女性坐在窗邊閱讀，陰天自然光穿過白色薄紗窗簾照亮臉部，陰影柔和、明暗過渡平順，保留自然膚質細節。 06｜硬光：力量、衝突與張力硬光會形成邊界清楚的陰影，例如直射陽光或小型光源直接照射。它能突出輪廓與材質，適合格鬥、運動、街頭風格或強烈個性的角色。 1拳擊手站在昏暗拳擊場中央，左上方硬質聚光燈照亮臉部與肩膀，形成清楚銳利的陰影，汗水反射高光，畫面充滿力量與張力。 07｜側光：立體、沉思與故事感光從人物側面照來，讓臉部一側受光、另一側留在陰影裡。側光可以是柔和的，也可以很銳利；不代表一定要把半張臉壓暗。適合訪談、人物獨白、紀實影像或懸疑短片。 1白髮老人坐在木屋窗邊看信，午後陽光從畫面右側照入，照亮右側臉頰與手部，左側保留柔和陰影，鼻樑和顴骨呈現自然層次。 08｜底光：不安、詭異與超自然光源在人物下方時，鼻子、眉骨與臉部陰影會違反日常熟悉的光線方向，容易產生不安感。常用於恐怖片、驚悚短影音或超自然題材。 1年輕女子獨自站在黑暗房間裡，手持位於胸口下方的冷白色手電筒，光由下往上照亮臉部，眉骨與鼻子形成反常陰影，背景幾乎全黑。把光線混搭，畫面會更具體先選擇一種方向，再搭配光線質地和色彩，就能組合出更明確的視覺效果：光線組合畫面感受常見情境蝴蝶光＋柔光精緻、親切 AI 講師、美妝人像側光＋柔光自然、有層次訪談、情感故事逆光＋柔和補光輪廓鮮明、仍看得清人物夕陽、英雄登場側光＋體積光空間感、可見光束森林、古堡、教堂頂光＋硬光明暗銳利、壓迫懸疑、審問場景底光＋冷色詭異、不安恐怖、超自然題材例如生成仙俠人物時，可以寫「夕陽從人物身後形成逆光，金色體積光束穿過雲海與薄霧，臉部保留少量柔和補光，衣袍邊緣有明亮輪廓」，比只寫「丁達爾光、電影感」更容易讓畫面方向清楚。三點布光：安排主光、補光與輪廓光三點布光（Three-Point Lighting）是人物訪談、廣告和影像製作常見的基本配置，三個光源各有工作：主光（Key Light）：主要照亮人物，決定臉部立體感與主要光線方向。補光（Fill Light）：減輕主光形成的陰影，但不必把陰影完全消掉。背光／輪廓光（Back Light／Rim Light）：從人物後方勾勒頭髮或肩膀，幫助人物與背景分開。新手可先從主光放在人物斜前方、略高於眼睛的位置開始，再用較弱的補光保留陰影細節，最後視需要加一點背後輪廓光。角度不是硬性規定，還是要依人物、背景與想要的效果調整。三點布光不代表一定要買三盞燈：窗戶可以當主光，白牆或反光板可以補光，畫面裡的檯燈也可能成為合理的實景光源。ARRI 的燈光手冊也將 Key、Fill、Separation 與 Background 列為人物布光中不同的工作角色，可參考其燈光手冊。 1一位成熟穩重的男性講師站在攝影棚內。左前方略高處的大型柔光源作為主光，照亮臉部；右前方較弱的補光保留自然陰影；人物後上方有微弱輪廓光，勾勒頭髮與肩膀，讓人物和深灰背景分開。中近景，直式構圖，膚質自然。七種值得認識的人像布光模式人像布光模式看的是光線在臉上形成的影子，而不只是燈架放在哪裡。除了前面介紹的蝴蝶光，以下幾種也很實用。倫勃朗光（Rembrandt Lighting）主光從人物斜前上方照來，暗側臉頰、眼睛下方會留下一塊小三角形亮區。它常用於成熟、有戲劇感的人像。只有「半張臉亮、半張臉暗」還不足以稱為倫勃朗光，需看三角形亮區是否出現。 1成熟男性坐在深色背景前，暖色主光從右前上方照射，暗側眼睛下方保留清楚的小三角形亮區，陰影深邃但仍有細節，呈現古典人像光影。環形光（Loop Lighting）主光通常在人物斜前上方，鼻子旁會形成一小段彎曲、沒有連到臉頰大陰影的鼻影。這裡的 Loop Lighting 指的是人像布光，不是直播常用的 Ring Light 圓環燈。分割光（Split Lighting）光線從接近人物正側面的位置照來，讓臉部兩側形成明顯明暗分界。它比一般側光更戲劇化，常用於神秘或情緒強烈的角色。寬面光與窄面光（Broad／Short Lighting）這兩種布光要看人物臉部朝向鏡頭的角度，以及哪一側受光。寬面光照亮較朝向鏡頭、可見面積較大的那側；窄面光則照亮較遠離鏡頭、可見面積較小的一側，常用來增加立體感。它們描述的是受光面和鏡頭的關係，不是光線軟硬或人物臉型。蛤殼式布光（Clamshell Lighting）主光放在人物正前上方，補光或反光板放在正前下方，從側面看像打開的蛤殼。這種安排能柔化眼下、鼻下與下巴的陰影，常見於美妝和精緻人像。模式觀察重點可先嘗試的情境蝴蝶光鼻子正下方的小陰影美妝、形象照環形光鼻子側下方的短鼻影自然人像倫勃朗光暗側眼睛下方的三角亮區戲劇人像分割光臉部明暗分界明顯懸疑、角色照寬面光朝向鏡頭的較大臉部受光明亮、開放的人像窄面光遠離鏡頭的較小臉部受光立體、有張力的人像蛤殼式布光上方主光、下方補光美妝、精品人像延伸的電影打光術語先知道術語在解決什麼問題即可，不必一次全背起來：術語白話說明常見用途輪廓光（Rim Light）讓人物邊緣受光，與背景分開人像、登場畫面高調照明（High-Key）整體明亮、暗部相對少廣告、清爽人像低調照明（Low-Key）以暗部為主，控制局部受光懸疑、黑色電影明暗對照（Chiaroscuro）用強烈明暗塑造立體與戲劇性古典或戲劇人像實景光源（Practical Light）畫面中看得到的燈、蠟燭或手機室內劇情場景動機式打光（Motivated Lighting）讓光線看起來有合理來源寫實影像負補光（Negative Fill）用黑布或黑板減少反射光，讓陰影更深戲劇人像反射補光（Bounce Lighting）把現有光反射回人物自然人像遮光造影（Gobo）遮住部分光線，投出窗格或樹影場景氣氛光比（Lighting Ratio）比較亮部與暗部的明暗關係人像控制光線衰減（Light Falloff）光線隨距離改變而變弱空間與局部照明眼神光（Catchlight）眼睛表面反射出的光點人像特寫體積光（Volumetric Lighting）光在霧、塵等介質中形成可見光束森林、奇幻場景黃金時刻（Golden Hour）日出後或日落前的低角度陽光旅行、愛情影像藍色時刻（Blue Hour）日出前或日落後的藍調時段夜景、城市影像高調不等於過曝，低調也不等於把整張圖直接調暗；兩者都要保留有意識的明暗安排。負補光不是「黑色的燈」，而是利用深色表面減少環境反射。冷色螢幕光搭配暖色檯燈，也能形成有層次的冷暖對比。丁達爾效應的基本原理是光被懸浮微粒散射。若想了解這個物理現象，可參考愛荷華大學的丁達爾實驗說明；若是在 AI 提示詞描述電影畫面，通常直接寫「薄霧中的體積光束」會更具體。把攝影知識寫進 AI 提示詞可以用這個公式整理提示詞：人物與場景＋光源位置＋光線軟硬＋陰影效果＋色彩＋情緒氛圍例如，不只寫「一位男性坐在辦公室，電影級打光」，而是補充光從哪裡來、照亮哪一側，以及另一側要留下什麼陰影： 1一位成熟男性坐在深色辦公室內，午後柔和自然光從人物左前方的窗戶照入，照亮左半邊臉，右側臉頰保留細膩陰影；背景檯燈提供溫暖輔助光，整體沉穩、專業，像電影訪談畫面。 AI 不會真的拿尺測量 45 度，實際陰影也不一定完全符合指定方向。因此，重要要求最好同時寫「光源方向」與「臉上要出現的陰影」，再依生成結果修正。文生圖和圖生影片要寫不同重點文生圖需要描述人物、場景、光線、構圖與風格。圖生影片則已經有首幀提供人物外觀、場景和大致光線，提示詞可以把更多篇幅放在動作、運鏡和時間變化，並提醒模型延續原圖的光線特徵： 110 秒寫實電影短片，一鏡到底。男性原本低頭沉思，緩慢抬起頭並望向鏡頭，目光逐漸堅定。鏡頭從中近景緩慢向前推進，最後停在臉部特寫。延續原始畫面的主光方向與倫勃朗光影，保持人物五官和服裝一致，動作自然、微表情細膩。新手實戰：同一個人物比較八種打光一次只改變光線，其他條件盡量維持一致，才看得出光線本身造成的差異。步驟一：準備固定的角色參考圖可以使用自己有權使用的形象照，或先生成一位固定的虛擬人物。正面或接近正面的半身照、簡單背景，會比較方便觀察光線變化。步驟二：請 AI 先規劃提示詞123請參考我提供的角色圖片，盡量保持人物五官、髮型、服裝、拍攝角度與背景一致。我要比較八種電影打光：頂光、逆光、體積光、蝴蝶光、柔光、硬光、側光、底光。請先為每一種列出光源位置、陰影特徵與情緒方向，再一次生成一個版本，方便比較。不同工具對角色參考與提示詞的遵循程度可能不同；如果人物、背景也一起改變，先簡化要求，讓比較條件盡量接近。步驟三：觀察光線，不只挑最漂亮的一張光大致從哪個方向來？哪一側臉比較亮，鼻子和下巴的陰影怎麼變？陰影邊緣是柔和還是銳利？背景有沒有被照亮？不看表情，光線本身帶來什麼情緒？步驟四：再比較人像布光模式使用同一角色，分別嘗試三點布光、倫勃朗光、環形光、分割光、高調與低調照明，觀察它們在臉部形成的差異。步驟五：挑三種光線做短片從靜態圖中挑三種效果，分別生成 5 至 10 秒短片。先不要要求同一支影片不斷切換八種光線，因為模型還要處理人物動作、運鏡、場景與時間變化；拆開練習會比較容易找到問題來源。想繼續學，可以按四個階段練習看懂光線：從頂光、側光、逆光、底光、柔光與硬光開始，練習判斷光源方向和陰影位置。安排光線：認識主光、補光、輪廓光、三點布光與基本光比，理解每道光各自的作用。用光設計情緒：練習倫勃朗光、環形光、分割光、蝴蝶光、高調與低調照明。用光說故事：進一步觀察動機式打光、實景光源、冷暖色對比、體積光、負補光，以及鏡頭之間的光線連續性。可以延伸搜尋 Three-Point Lighting Tutorial、Rembrandt Lighting Photography、Portrait Lighting Patterns、Cinematic Lighting for Beginners、Motivated Lighting Cinematography 等英文關鍵字，搭配燈位示範和前後比較來練習。若想延伸到運鏡與鏡頭描述，也可以閱讀AI 攝影語言與 Google Flow 運鏡提示詞；想從故事角度規劃影片，則可參考AI 影片故事與敘事能力。以前談 AI 影片，常常先比模型、工具與提示詞。現在生成門檻降低了，我反而覺得攝影、打光、構圖、色彩、運鏡和故事節奏更值得補上。新手不必先背完名詞，可以從看懂光開始，再練習如何安排光線、用光表達情緒。當你知道光從哪裡來、陰影應該落在哪裡，以及這道光想說什麼故事，你就不只是叫 AI 生成影片，而是在學影像創作。常見問答 (FAQ)Q1：為什麼寫了倫勃朗光，AI 卻沒有生成三角形亮區？模型可能只抓到「強烈明暗對比」，沒有準確還原臉部陰影結構。可以補充「人物暗側眼睛下方保留一塊清楚的小型三角形亮區」，並先用靜態圖片確認光影，再拿來生成影片。 Q2：AI 人像看起來像塑膠娃娃，改善打光就夠了嗎？不一定。柔和側前光、自然陰影和真實皮膚紋理可能有幫助，但臉部細節、生成模型特性與後製也會影響真實感；打光不是唯一因素。 Q3：為什麼圖生影片後，人物臉上的光線會變來變去？影片生成時，模型可能無法在角色轉頭、移動或運鏡後穩定維持光線方向。可以先減少大幅度轉頭與運鏡，並保持簡單明確的光源設定；若情節需要明顯從白天轉夜晚，可拆成不同鏡頭處理。 Q4：一定要用英文提示詞，AI 才懂打光嗎？不一定。可以先用中文說清楚場景、光源方向和陰影，再補上必要的英文術語，例如 Rembrandt Lighting、Soft Light 或 Volumetric Lighting。若效果不理想，再把關鍵句改成英文比較。 Q5：學會三點布光後，所有影片都應該用三點布光嗎？不是。三點布光適合建立清楚、穩定的人物照明，但有些故事需要保留大量陰影、只用自然窗光，甚至不補光。攝影知識是幫助你判斷何時用光，也知道何時應該把光拿掉。
2026/10/19
AI工具影音行銷

AI 影片人物表情太假？用提示詞拆解微表情與情緒節奏

明明只想讓 AI 影片裡的女生開心地笑一下，結果生成出來卻張大嘴巴、露出整排牙齒，像在拍牙膏廣告；想讓角色有點委屈，卻變成嚎啕大哭；想呈現害羞，最後表情反而僵住。這不一定代表模型不夠強。很多時候，提示詞只交代「開心、委屈、緊張」這類抽象情緒，卻沒有說明角色要怎麼表現。把情緒轉成觀眾看得見的表情、動作和變化順序，通常更容易得到細膩的演出。這套描述方式可以用在支援文字生成影片或圖片生成影片的工具，例如 Google Flow、MiniMax H3、Wan 等；不同工具、模型版本與方案對提示詞的理解會有差異，範例是可調整的寫法，不保證每次都生成相同結果。為什麼 AI 人物看起來像在「演」？假設你想生成一段男女主角在咖啡廳約會的影片，提示詞寫著：「女生聽見男生說笑話後，非常開心地笑了起來。」「非常開心」沒有說明笑容的幅度、眼神怎麼變、角色是否要做其他動作。模型可能把這個情緒演成大笑，也可能只生成一張笑臉。若你想要的是電影裡含蓄、自然的反應，就要把情緒拆成具體畫面：女生先愣一下，接著嘴角微微上揚、眼神變柔和，最後不好意思地低頭輕笑。重點不是堆更多形容詞，而是把抽象情緒改寫成能被看見的表演細節。技巧一：把情緒拆成嘴角、眼神與臉部變化可以先用這個簡單公式整理提示詞：人物表情 = 嘴角與嘴唇 + 眼神與眉毛 + 臉部狀態這不是醫學上的表情辨識標準，而是一種把情緒說清楚的寫作方法。以下是可用來起稿的例子：情緒嘴角與嘴唇眼神與臉部開心嘴角緩慢上揚眼神柔和，眼睛微微彎起委屈嘴角輕輕下壓眼眶逐漸濕潤，表情短暫停住緊張雙唇輕抿目光短暫閃避，眉頭略微繃緊生氣嘴唇緊閉，下顎收緊眉頭皺起，目光集中驚訝嘴唇微張眉毛抬起，眼睛短暫睜大害羞嘴角含蓄上揚眼神閃躲，臉頰略微泛紅悲傷嘴角自然下垂眼神黯淡，眼眶泛淚同一種情緒不只有一種表情，實際寫法要依角色個性和劇情調整。也可以把太概括的描述改成更具體的句子：一般寫法：「女生露出開心的笑容。」具體寫法：「女生嘴角輕輕上揚，眼神逐漸柔和，雙眼微微彎起，臉頰自然放鬆，露出含蓄的微笑。」一般寫法：「女生覺得委屈，快要哭出來。」具體寫法：「女生嘴角微微下壓，眉頭輕輕皺起，眼眶逐漸濕潤，原本想說話的表情突然停住，努力忍住眼淚。」技巧二：加入少量肢體動作與視線方向臉部表情之外，手部動作、身體姿態和視線也能補足角色的反應。可以把提示詞擴充成：人物情緒 = 表情細節 + 手部動作 + 身體姿態 + 視線方向描述項目白話說明提示詞例子微表情短暫、細微的臉部變化嘴角微微上揚手部動作手指或手掌正在做什麼用手輕輕遮住嘴巴身體姿態肩膀、頭部和身體的姿勢身體微微前傾視線方向角色正在看哪裡從咖啡杯抬眼看向對方例如，不只寫「女生害羞地笑了起來」，還可以寫：「女生聽見對方說的笑話，嘴角慢慢上揚，忍不住露出微笑。她輕輕抬起右手遮住嘴巴，肩膀隨著輕笑微微起伏，眼神閃爍，最後不好意思地低下頭。」動作要留白。新手可以先安排一種主要情緒，再加上一到兩個明顯的肢體動作。若短短幾秒內同時要求角色轉頭、揮手、站起來、眨眼、甩頭髮和拿起杯子，模型可能難以維持動作順序，也容易出現肢體或物件不連貫的畫面。技巧三：安排情緒發生的先後順序自然的情緒通常有變化過程。收到期待已久的生日禮物時，角色可能先愣住，認出禮物後眼神亮起，最後才笑出來。可以把反應拆成三段：情緒觸發 → 情緒變化 → 情緒收斂時間情緒階段畫面描述 0–3 秒情緒觸發女生聽到對方稱讚，短暫愣住 3–7 秒情緒變化嘴角逐漸上揚，眼睛微彎 7–10 秒情緒收斂不好意思地低頭，再抬起眼睛微笑時間區間是幫助整理動作順序的提示，不代表每個模型都能精準在指定秒數完成表情。若時間切分沒有被遵循，可以改用「先、接著、最後」描述，或縮短影片、減少情緒變化。新手可直接套用的 AI 影片提示詞公式把提示詞按順序整理成：場景 + 人物 + 情緒原因 + 微表情 + 肢體動作 + 情緒節奏 + 鏡頭要求提示詞元素要交代什麼範例場景人物在哪裡溫暖的咖啡廳人物誰在演出成年女性，穿米白色上衣情緒原因發生了什麼事聽見朋友說了一句有趣的話微表情眼睛與嘴角怎麼變化嘴角上揚，眼神變柔和肢體動作手部與身體怎麼反應低頭輕笑，肩膀微微起伏情緒節奏反應先後如何變化先聆聽，再微笑，最後低頭鏡頭要求觀眾如何看見人物穩定中近景、柔和自然光想寫得更快，可以先填好故事和情緒，再讓 ChatGPT、Gemini 或 Claude 協助整理。以下提示詞可直接複製後修改：你是一位電影導演與演員表演指導。我想製作一段 10 秒的 AI 人物情緒短片。故事情境是：【填入你的故事】主要情緒是：【填入開心、害羞、委屈等情緒】請把抽象情緒拆解成具體可見的表演細節，包括嘴角與嘴唇、眼神與眉毛、臉部變化、手部動作、身體姿態和視線方向。請依照 0–3 秒、3–7 秒、7–10 秒安排自然連續的情緒變化。若時間切分不適合，請用「先、接著、最後」描述順序。整體表演寫實、細膩、克制，避免誇張表情與過多動作。最後整理成可直接貼入 AI 影片生成工具的繁體中文提示詞，並加入適合的鏡頭、光線與構圖描述。 AI 整理的提示詞仍需要人工刪減。有時候少寫幾個不必要的表情或動作，反而更容易得到清楚的演出。三種人物情緒的影片提示詞範例練習一：咖啡廳裡自然開心的女生這個範例先練一種情緒和一個主要動作：生成一段 10 秒的寫實風格電影影片。場景是一間溫暖舒適的咖啡廳，一位成年女性穿著米白色針織上衣，坐在木桌旁，面對正在聊天的朋友。先讓女生安靜聆聽，表情自然，眼神專注。聽見朋友有趣的話後，嘴角慢慢上揚，眼神變得柔和，眼睛微微彎起，露出自然的微笑。最後她短暫低頭輕笑，肩膀隨著呼吸微微起伏，再抬頭看向對方。整體表演自然、細膩、克制，情緒逐漸變化，沒有誇張的大笑。鏡頭保持穩定，使用中近景構圖，暖色自然光線，真實皮膚紋理，背景輕微模糊。不要字幕、不要畫面文字、不要誇張的表情變化。練習二：收到生日禮物，感動但忍住眼淚這個練習用表情、視線和手部動作呈現感動，不要求角色直接大哭：生成一段 10 秒的電影寫實風格影片。一位成年女性坐在溫暖的生日派對房間裡，雙手輕輕捧著一個紅色小禮物盒。一開始她低頭看著手中的禮物，表情從平靜逐漸轉為驚訝，眉毛輕輕抬起，雙眼稍微睜大。接著她認出這是自己期待已久的禮物，眼神逐漸柔和，眼眶微微濕潤，嘴角輕輕抿住，雙手自然地握緊禮物。最後她慢慢抬頭看向送禮的人，露出含蓄的微笑，眼神帶著感動，努力忍住眼淚。肩膀自然放鬆，動作緩慢真實，情緒細膩內斂。使用固定中景、柔和暖光和電影感景深。不要突然大哭、不要誇張張嘴、不要快速切換表情、不要字幕。練習三：害羞的約會反應這個情境適合戀愛短劇或情感短影音練習：生成一段 10 秒的電影寫實風格影片。傍晚的咖啡廳裡，一位成年女性與喜歡的對象面對面坐著，對方位於鏡頭外。女生原本自然地看著對方，聽見真誠的稱讚後短暫愣住。接著她的嘴角緩緩上揚，眼神變得柔和，臉頰略微泛紅，不好意思地把視線移向桌面。最後她輕輕整理耳邊的頭髮，再抬眼看向對方，露出害羞而含蓄的微笑。表情自然細膩，動作連貫，眼神變化真實，沒有過度表演。使用固定中近景、溫暖夕陽光線和電影寫實風格。不要突然大笑、不要誇張臉紅、不要字幕。如果想延伸學習鏡頭描述，可以接著看AI 攝影語言與 Google Flow 運鏡提示詞；若想理解 AI 影片敘事與整體製作，也可參考AI 影片製作工作流。生成結果不自然時，可以先檢查這五件事常見狀況可以怎麼調整笑容太誇張把「大笑、非常開心、興奮」改成「嘴角輕輕上揚、含蓄微笑、眼神柔和」，也避免同時加入多個高強度情緒形容詞。眼神空洞寫清楚視線方向，例如「原本看著咖啡杯，聽見聲音後慢慢抬眼看向對方」。人物一直亂動減少動作數量，先使用固定鏡頭、坐姿和單一手部動作，穩定後再增加其他動作。不同片段人物長相不同準備角色參考圖，使用工具支援的角色參考或圖片生成影片功能，並盡量維持髮型、服裝和場景一致。參考圖也不保證每個模型都能完全鎖定人物長相。沒有照指定秒數變化改用「先、接著、最後」描述順序，或縮短影片、減少同一段中的情緒變化。用同一張人物照片，練習三種情緒想觀察哪些細節會影響生成結果，可以先用同一張人物照片做三個版本：開心：嘴角輕輕上揚，眼神柔和，微微低頭笑。委屈：嘴角慢慢下壓，眼眶略微濕潤，短暫移開視線。緊張：輕輕抿住嘴唇，目光短暫閃避，手指自然交握。三段影片盡量使用相同場景、鏡頭角度、片長與模型設定。生成後並排比較，再一次只調整一兩個描述。這樣比較容易看出哪些表情或動作有效、哪些細節模型還不穩定；如果整段提示詞一次全部重寫，就很難知道差異從哪裡來。享哥的觀點：AI 影片提示詞也在描述演出生成影片時，人物漂亮、畫面精緻只是其中一部分。眼神、嘴角、呼吸、手勢和情緒停頓的時機，都會影響觀眾是否相信角色正在經歷某種情緒。同樣是笑，露齒大笑和偷偷抿嘴笑呈現出的個性就很不一樣。我們不一定要懂攝影機操作或演員訓練，但可以練習觀察表情與動作，再把觀察轉成提示詞。先練會讓角色自然地笑一次，再慢慢把這些方法整理成 AI Agent 能使用的角色表演規則。常見問答 (FAQ)Q1：怎麼讓 AI 影片角色的笑容看起來自然？不要只寫「開心地笑」，改寫嘴角、眼神和臉部狀態，例如「嘴角緩緩上揚、眼神柔和、眼睛微微彎起，露出含蓄的微笑」。再搭配少量動作，避免同時要求大笑和多種複雜表演。 Q2：提示詞要寫每個表情發生的秒數嗎？可以用時間區間整理變化順序，但各工具不一定能精準遵守秒數。若生成結果沒有照時間切分，可以改成「先、接著、最後」的敘述，或縮短片長、減少一段影片中的情緒變化。 Q3：只靠提示詞能讓不同片段的人物長相完全一致嗎？不能保證。可以準備角色參考圖，使用工具支援的角色參考或圖片生成影片功能，並盡量維持髮型、服裝和場景設定一致；不同模型與版本的角色一致性仍可能不同。 Q4：人物動作太多或一直亂動時，應該先改哪裡？先刪減動作，只保留一種主要情緒和一到兩個明顯動作，再使用固定鏡頭與清楚的視線方向。等結果穩定後，再逐步加入其他表演細節。
2026/10/19
AI自動化 n8n 雲端部署

Zeabur 停止營運後，n8n 搬去哪？Railway、Coolify 費用與搬遷教學

原本穩定運作的 n8n 自動化，突然遇到部署平台宣布停止營運，接下來該怎麼辦？我原本把 n8n 部署在 Zeabur，用它串接 LINE 官方帳號、Google 服務、Webhook 和 AI 工作流程。真正讓人擔心的，不只是重新部署 n8n，而是工作流程、Credentials、資料庫和加密金鑰能不能完整搬走。我整理了兩個方向：**Railway 適合先把服務快速搬起來；Coolify 搭配 VPS，適合願意自行管理伺服器、也準備部署更多服務的人。**本文包含費用參考、備份清單和切換步驟。這是一份搬遷規劃與教學整理，並不表示我已完成 Railway 或 Coolify 的實際遷移驗證。 Zeabur 什麼時候停止營運？Zeabur 在 2026 年 10 月 17 日公告將逐步結束平台營運。官方也說明，2026 年 10 月 14 日發生內部系統及部分客戶服務遭外部人士入侵的資安事件，調查與後續報告仍在進行。時程官方公告的安排 2026 年 10 月 17 日起停止新購專用伺服器與網域，開始受理帳戶餘額退款等申請 2026 年 12 月 1 日起共享叢集服務暫停；專用伺服器停止續費 2026 年 12 月 1 日至 31 日專用伺服器依個別到期日陸續關閉 2026 年 12 月 31 日所有專用伺服器和共享叢集停止服務 **12 月 31 日是全部服務停止的最後日期，不代表每一個服務都能運作到那一天。**共享叢集自 12 月 1 日起會暫停運作，但公告表示使用者仍可手動恢復服務以備份資料；專用伺服器則要依自己的到期日安排。資料刪除日期、最晚匯出期限和 Support 停止服務日期仍待另行公告。建議先確認自己使用的服務類型與到期日，盡早做一份獨立備份。完整時程以 Zeabur 停止營運公告為準。 Railway 和 Coolify，哪一種比較適合搬 n8n？兩者都能部署 n8n，但你要負責的事情不一樣。項目 Railway Coolify + VPS 服務型態雲端應用平台，提供部署、網域、Volume 和用量介面自架部署管理平台，安裝在自己租用或管理的伺服器上主機維護平台處理較多底層工作自己處理作業系統、Coolify、網路和安全更新費用模式方案最低費用加上資源用量 Coolify 自架軟體免平台授權費，另付 VPS、備份和儲存費比較適合想先恢復單套 n8n、降低伺服器管理工作想在同一台 VPS 管理多個網站、資料庫或自動化服務主要取捨用量上升時帳單也會變動主機可自行管理，但維護和故障排查責任較多 Railway 有新加坡部署區域，對台灣使用者可以列入考慮；Coolify 的連線品質則會跟你選的 VPS 機房有關。Railway 官方有 n8n 部署指南，Coolify 官方列出 SQLite、PostgreSQL，以及 PostgreSQL 加 Worker 的 n8n 部署方式，見 Coolify 的 n8n 文件。如果現在最重要的是縮短停機時間，先選熟悉度較高、能快速驗證的方案。只有一套 n8n 時，Railway 通常比較省管理工；如果平常就會管理 Linux、Docker 和備份，而且還要部署其他服務，Coolify 才比較容易發揮主機共享的彈性。哪個方案比較便宜，要連同實際用量、備份和維護時間一起比較。 Railway 和 Coolify 每月大約多少錢？以下列出 2026 年 10 月 19 日查到的官方價格，金額以美元計；方案、費率、稅金和地區供應可能調整，開通前請再看服務商的最新帳單說明。 Railway：US$5 是最低月費，不是固定上限Railway Hobby 每月最低 US$5，這筆費用包含 US$5 的資源用量額度。若當月資源使用 US$3，仍支付 US$5；若使用 US$8，總額約為 US$8。超過額度後，CPU、記憶體、Volume 儲存和網路傳輸都會影響帳單。資源 Railway 公布的費率 RAM US$10／GB／月 CPU US$20／vCPU／月 Volume 儲存 US$0.15／GB／月對外流量 US$0.05／GB 這些費率是按實際使用量計費，不代表服務設定了多少上限就一定會用滿。n8n 長時間開機時，記憶體與持久化儲存都會持續影響費用；Workflow 執行量、AI 節點、檔案處理和對外流量則會讓 CPU 或流量成本增加。Railway 建議先部署並觀察一段時間，再從 Workspace 的用量頁估算帳單。更多細節見 Railway 方案與價格和官方定價頁。 Coolify：軟體免費，主機和備份仍需付費Coolify 自架版不用支付平台授權費，但 VPS、公開 IPv4、主機備份、額外儲存和異地備份仍會產生成本。以下用歐洲 Hetzner Cloud 與 DigitalOcean 的公開價格作示例，並把主機備份計入試算：方案示例主機費 IPv4／每日備份約計月費 Hetzner CX23 US$6.49 IPv4 US$0.60、主機備份約 US$1.30 約 US$8.39 Hetzner CX33 US$9.99 IPv4 US$0.60、主機備份約 US$2.00 約 US$12.59 DigitalOcean Basic Droplet，4GB RAM／2 vCPU US$24.00 每日 Droplet 備份約 US$7.20 約 US$31.20 Hetzner 兩個價格是德國／芬蘭區域、未含 VAT、未含 IPv4 的月價；備份費以該主機月價的 20% 計。DigitalOcean 每日 Droplet 備份按 Droplet 費用的 30% 計算。費用只供初步比較，沒有包含獨立異地備份、網域、額外磁碟、超額流量、可能的稅金，以及自行維護所花的時間。來源可查看 Hetzner 2026 年價格調整、Hetzner IPv4 價格、Hetzner 雲端備份費用說明和 DigitalOcean Droplet 價格。 Coolify 官方建議執行它的伺服器至少有 2 個 CPU 核心、2GB RAM 和 10GB 可用磁碟；這是 Coolify 本身的最低需求，不等於同一台主機也執行 n8n、PostgreSQL 和其他服務時一定足夠。請按實際負載留出資源，並監測磁碟和記憶體。完整條件見 Coolify 自架指南。搬家之前，先備份這四類資料只匯出 Workflow JSON 不等於完成 n8n 系統備份。搬遷前先盤點資料庫類型、n8n 版本、Volume 掛載、網域、環境變數名稱、自訂節點，以及是否有外部檔案儲存。 1. 匯出 Workflow 和 Credentials可以在 n8n 介面逐一匯出重要 Workflow；若有服務 Terminal，也可使用 CLI 批次匯出： 12n8n export:workflow --backup --output=/home/node/.n8n/migration/workflows/n8n export:credentials --backup --output=/home/node/.n8n/migration/credentials/ --backup 會分別輸出 Workflow 和 Credentials。這份匯出不包含使用者、執行紀錄、Variables、整個 n8n 設定或加密金鑰，因此不能取代完整備份。Credentials 和其匯出檔都要當成機密資料保存，不可上傳到公開 GitHub 或貼在公開討論區。 2. 備份 SQLite 或 PostgreSQL先確認目前使用哪種資料庫。若環境變數有 DB_TYPE=postgresdb 或 DB_POSTGRESDB_HOST，通常代表使用 PostgreSQL；如果沒有另外設定，可能是預設 SQLite，仍要透過服務設定和實際檔案確認。 **SQLite：**先停止 n8n 的寫入，再備份 .n8n 持久化目錄。n8n 官方提醒，n8n 正在寫入時直接複製 SQLite 資料庫，備份可能不一致。Zeabur 的離線備份只涵蓋服務掛載的持久化 Volume；備份前要確認 .n8n 確實在該 Volume 中，備份完成再下載並確認檔案可讀。 **PostgreSQL：**備份資料庫，也要另外保存 n8n 的 .n8n 目錄。Zeabur 官方文件說 PostgreSQL 備份使用 pg_dumpall 並輸出標準 .sql 格式；這種 SQL 備份應依格式使用 psql 還原，不能把所有 .sql 檔都當成 pg_restore 使用的 custom archive。若另外使用 pg_dump 匯出單一資料庫，先確認輸出格式，再選擇相符的還原工具，並處理資料庫角色及權限差異。 Zeabur 文件也說明，備份保留 7 天；需要長期留存時要自行下載到 Zeabur 以外的位置。操作方式與格式可查閱 Zeabur 備份文件。 3. 保存原本的加密金鑰n8n 的 Credentials 以原本的加密金鑰加密。金鑰可能在 .n8n/config，也可能由 N8N_ENCRYPTION_KEY 提供。還原到新環境時必須沿用原本的金鑰；如果資料庫搬過去卻使用新的金鑰，既有 Credentials 可能無法解密。不要為了搬遷任意更換這個金鑰。 n8n 官方完整備份說明指出，SQLite 需要 .n8n 資料夾；PostgreSQL 則需要資料庫備份和 .n8n 資料夾。若使用外部 S3 等二進位檔案儲存、自訂檔案路徑或自訂節點，也要另外備份。詳細內容見 n8n 備份與還原文件。 4. 留一份可實際還原的備份下載完成不代表還原一定成功。建議至少保留兩份備份，其中一份放在 Zeabur 以外的安全位置；以測試環境確認 Workflow 可以載入、Credentials 可以解密、資料庫可連線，再進行正式切換。備份檔及金鑰不要放在公開 Git 儲存庫。若想先熟悉舊環境的部署方式，可以參考站內的 n8n 部署到 Zeabur 教學；LINE Webhook 的檢查方式也可參考 n8n 串接 LINE Bot Webhook。如何把 n8n 搬到 Railway？Railway 的官方指南提供 n8n Docker Image 和一鍵範本兩種方式。搬遷時先沿用原本的 n8n 版本和資料庫類型，讓「換平台、升級 n8n、切換資料庫」不要同時發生；確認服務運作後，再另外安排升級。 1. 建立服務和持久化 Volume建立 Railway Project，選擇接近使用者的區域；Railway 有 Singapore 的 Southeast Asia Metal 區域。建立 n8n 服務時可用官方範本，或從 Docker Image 部署 n8nio/n8n。 n8n 預設將資料放在 /home/node/.n8n。建立 Volume 並掛載到這個路徑，否則重新部署後，SQLite 資料庫或本機設定可能不會保留。若使用 PostgreSQL，資料庫也需要自己的持久化與備份規劃。 2. 設定網域、時間與 Webhook依 Railway 導引設定服務連接埠與公開網址。常見設定如下，實際值依你的網域與 n8n 版本調整：環境變數設定方向 N8N_PORT Railway 官方 n8n 指南使用 ${{PORT}} N8N_PROTOCOL 公開 HTTPS 網站使用 https N8N_WEBHOOK_URL 設為完整的公開網址，例如 https://n8n.example.com/ GENERIC_TIMEZONE、TZ 例如 Asia/Taipei，並確認排程時區 N8N_EDITOR_BASE_URL 若有自訂網域，設為編輯器網址 N8N_ENCRYPTION_KEY 使用原本的值，透過平台安全的 Secret／Variables 欄位設定反向代理層數要依實際網路架構判斷，只有符合 n8n 的代理設定情境時才設定 N8N_PROXY_HOPS。n8n 官方文件標示，從 2.35.0 起 WEBHOOK_URL 已棄用，改用 N8N_WEBHOOK_URL；舊名稱目前仍是別名，但會出現棄用提醒。Railway 指南仍列出 WEBHOOK_URL 範例，部署時請以正在使用的 n8n 版本和 n8n 官方文件為準。如果原本使用 PostgreSQL，在新服務設定 DB_TYPE=postgresdb 和對應資料庫連線變數；恢復資料庫後仍要保留 /home/node/.n8n，其中可能存有加密金鑰和其他本機資料。Railway 的 Docker Image、Volume 與變數範例見 Railway n8n 部署指南，n8n 的 Webhook 變數說明見 n8n Endpoints 環境變數文件。 3. 還原後先在測試環境驗證SQLite 和 SQLite 搬遷時，確認 n8n 已停止寫入，再將原本 .n8n 資料還原到 Volume；PostgreSQL 則先建立目標資料庫，再依備份格式匯入，並確認使用原本的加密金鑰。不要把 SQLite 備份檔直接當成 PostgreSQL 備份匯入。先用新網址登入，檢查 Workflow、Credentials、使用者和自訂節點。建立少量測試 Workflow 確認觸發和輸出正常，最後再處理正式 Webhook 與排程切換。 Railway Volume 可建立手動或排程備份，但官方說明指出，Volume 備份只能還原到同一個 Project 和 Environment。它適合平台內復原，不能取代下載到其他平台的獨立備份。參考 Railway Volume 備份說明。如何在 VPS 上安裝 Coolify 並部署 n8n？Coolify 是自架的部署管理工具，並不附送 VPS。你要先租用 Linux 主機，再維護作業系統、Coolify、網路、資料庫和備份。Coolify 官方建議自架管理主機至少具備 2 個 CPU 核心、2GB RAM 和 10GB 磁碟；如果同機執行 n8n 和 PostgreSQL，應依實際負載預留更多資源。 1. 準備 VPS 和 Coolify選擇有 SSH 權限的 VPS，確認機房、規格和備份價格。Coolify 官方提供自動安裝方式，執行前請從 Coolify 官方安裝文件核對主機需求和最新指令；該文件的安裝範例如下： 1curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash 安裝後盡快建立管理員帳號，限制管理介面的公開存取，並備份 /data/coolify/source/.env。這個檔案含有復原 Coolify 所需的重要秘密值，不要提交到 Git 或貼到公開頁面。防火牆只開放服務實際需要的連接埠；n8n 的內部連接埠和 PostgreSQL 5432 通常不應直接暴露到公網。 2. 選擇 n8n 部署組合Coolify 的 n8n 文件列出三種常見組合：n8n + SQLite 適合簡單或測試用途；n8n + PostgreSQL 適合需要獨立資料庫的正式服務；n8n + PostgreSQL + Redis + Worker 則增加佇列和並行執行元件。服務越多，資源、監控和還原流程也越複雜，不需要一開始就採用 Worker 組合。綁定自己的網域並啟用 HTTPS 後，還原原本的 .n8n 與資料庫。搬遷前後都沿用同一個 Encryption Key，並逐一確認環境變數名稱和檔案掛載位置。Coolify 的 PostgreSQL 備份可以排程，也可上傳到 S3 相容儲存；但 Coolify 平台自身的備份與應用程式、資料庫、Volume 的備份是不同項目，請分開設計。官方資料可參考 Coolify 資料庫備份和 Coolify 執行個體備份。 Webhook 和排程切換，怎麼避免重複執行？n8n 換了網域後，LINE 官方帳號、表單服務、網站和其他外部平台可能仍呼叫舊的 Webhook URL。請逐一更新來源平台的 Webhook 網址和 OAuth Callback／Redirect URI。若有串 LINE 官方帳號，可到 LINE Developers Console 更新 Webhook URL，先按 Verify，再實際傳送一則訊息，檢查 n8n 是否收到事件並正常回覆。**Verify 成功只代表驗證請求能到達端點，不能代替完整 Workflow 測試。**Google OAuth、Gmail、Google Calendar 等整合也要檢查重新導向網址和授權狀態。切換正式排程時，不要讓新舊 n8n 同時執行相同的正式 Workflow，否則可能重複寄信、寫入資料或回覆 LINE。可以照以下順序操作：先在新環境用測試資料驗證 Workflow 和 Credentials。暫停舊環境的正式排程，等待進行中的執行結束。做一次最後備份，將最後變更同步到新環境。更新 Webhook、OAuth Callback 和 DNS 等外部設定。啟用新環境的正式 Workflow，送出真實但可控的測試事件。觀察執行紀錄和外部回應，再依備份政策處理舊環境。搬遷時要一起檢查哪些資安設定？這次搬家也是重新盤點憑證與備份的時機。平台帳號和 n8n 管理員帳號使用強密碼並啟用 MFA；備份存放在受控位置，保留異地副本並定期測試還原。API Key、OAuth Client Secret 或資料庫密碼若可能受到資安事件影響，請依服務商建議和憑證用途逐一輪替。 **不要把 n8n 的 Encryption Key 當成一般 API Key 隨意更換。**它用來解密資料庫中已儲存的 Credentials。搬遷時要先帶著原金鑰完成還原；若日後要更換，應先查閱 n8n 官方支援的作法，並確認有可還原的完整備份。不要把包含 Credentials、Encryption Key、Coolify .env 或資料庫密碼的檔案放進公開 GitHub。Workflow 和設定範本若需版本管理，先移除秘密值，使用平台提供的 Secret 管理功能保存真實憑證。我會怎麼選？如果目標是先讓一套 n8n 盡快恢復，我會先評估 Railway：部署入口較直接，有新加坡區域，費用可以從使用量開始觀察。Hobby 的 US$5 是最低月費和包含的用量額度，不是無上限的固定價。如果你已經會管理 Linux 和 Docker，也有多個網站、資料庫或自動化服務要集中管理，再評估 Coolify + VPS。Coolify 軟體自架免費，但主機、備份、異地儲存、資安更新和故障排除都由自己負責；把這些時間也算進總成本，才看得出是否真的划算。我會分成三階段處理：先完成安全備份和測試還原；再用熟悉的平台恢復正式流程；最後把環境變數範本、備份清單、Webhook 更新和還原步驟整理成 SOP。這樣下一次更換平台時，搬遷就不必從頭猜一次。常見問答 (FAQ)Q1：只匯出 n8n Workflow JSON，可以完整搬家嗎？不行。完整搬遷還要依資料庫類型備份 SQLite 或 PostgreSQL、保存原本的 Encryption Key，並檢查 .n8n 目錄、自訂節點和外部檔案儲存。CLI 匯出主要是 Workflow 和 Credentials，不包含完整執行紀錄與所有系統設定。 Q2：Railway Hobby 每月只要 US$5 嗎？US$5 是 Railway Hobby 的最低月費，並包含 US$5 的資源用量額度。若實際用量超過額度，帳單會隨 CPU、記憶體、Volume 和流量增加；部署後應查看用量頁，不要把最低費用當成固定上限。 Q3：Coolify 一定比 Railway 便宜嗎？不一定。Coolify 自架軟體免平台授權費，但 VPS、IP、備份、異地儲存、維護時間和故障處理都要納入。只有一套 n8n 時，Railway 省下的管理工可能更有價值；多個服務共用主機時，Coolify 才可能降低整體單位成本。 Q4：搬遷時可以讓新舊 n8n 同時運作嗎？可以在測試期間讓新環境保持未啟用正式排程，但不要讓兩邊同時執行相同的正式 Workflow。正式切換前先暫停舊排程、等待執行完成、做最後備份，再更新 Webhook 並啟用新環境，避免重複寄信或處理資料。 Q5：如果現在無法登入 Zeabur，資料是不是就救不回來？不一定。請先查看 Zeabur 官方公告並聯絡 Zeabur Support，詢問服務狀態、可用的備份和資料匯出方式。公告指出共享叢集服務暫停後仍可手動恢復以備份資料；是否能存取個別服務，則要以當下狀況和官方支援回覆為準。官方參考資料 Zeabur 停止營運公告 Zeabur 備份文件 Railway 方案與價格 Railway n8n 部署指南 Railway 部署區域 Railway Volume 備份 n8n 備份與還原 n8n Webhook 環境變數 Coolify 自架指南 Coolify n8n 部署文件 Coolify 資料庫備份 Coolify 執行個體備份 Hetzner 2026 年價格調整 Hetzner IPv4 價格 Hetzner 雲端備份費用說明 DigitalOcean Droplet 價格 DigitalOcean 備份價格本文整理日期：2026 年 10 月 19 日。平台時程、價格、功能與介面可能調整，請以官方最新資料為準。本文是搬遷規劃與教學整理，並未宣稱已完成實際搬遷。 #n8n #Zeabur #Railway #Coolify #AI自動化 #雲端部署 #VibeCoding
2026/10/18
Codex MCP 影音行銷

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

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

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

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

Vibe Coding 新手教學：Void 是什麼？Vinext 又是什麼？用 Codex 建站與選擇 Cloudflare 部署

最近看到 MUKI WU 分享影片《Vite 被 Cloudflare 買了？Void 開源能取代 Vercel 嗎？》，我也開始研究 Void 和 Vinext。這兩個名稱都和 Vite 有關，也都出現在 Cloudflare 的開發工具消息裡，但它們解決的問題並不相同。Void 適合從 Vite 專案開始，整合全端功能與部署；Vinext 則讓既有 Next.js 專案改用 Vite 工具鏈。這篇會用一個新手能跟上的例子，帶你用 Codex 建立 Void 練習網站，再認識什麼時候才需要研究 Vinext。安裝與指令依本文整理時的官方文件編寫；文章中的範例不是每種環境都已實機驗證，實際操作仍要以所安裝版本的文件為準。 Vite、Void、Vinext、Vercel 和 Cloudflare 有什麼不同？先把幾個常一起出現的名稱分開看：名稱主要工作可以先這樣理解 Vite 網頁開發伺服器與建置工具協助開發、即時預覽和打包網頁 Vite+ 整合 JavaScript 開發工具鏈把建置、測試與程式碼檢查等工具放在一起 Next.js React 全端框架提供頁面路由、伺服器渲染等網站開發功能 Vinext 以 Vite 重新實作 Next.js API 的外掛讓既有 Next.js 專案有機會改由 Vite 工具鏈執行 Void Vite 全端 SDK、CLI 與部署平台協助建立 API、連接資料資源並部署 Vite 應用 Vercel 雲端部署與代管平台提供部署、預覽和團隊開發流程 Cloudflare 雲端基礎設施與全球網路平台提供 Workers、D1、KV、R2 等服務 **Void 和 Vinext 不是同一種工具。**Void 的重點是從 Vite 應用出發，建立全端功能並管理部署；Vinext 的重點是讓 Next.js 專案沿用熟悉的應用目錄結構，改由 Vite 處理建置與執行。 Cloudflare 在 2026 年 10 月介紹 Void 時，說明 VoidZero 已加入 Cloudflare，並公開 Void SDK、CLI 和 Platform。這不代表 Vite、Void 和 Vinext 是同一個產品，也不代表原有的 Vite 專案會自動變成 Void 專案。Cloudflare 的 Void 公告用一句話記住它們的差異 Vite：負責開發和建置前端應用。 Void：在 Vite 工作流上加上全端路由、資源管理與部署。 Vinext：讓 Next.js 專案改用 Vite 工具鏈，並保留大量 Next.js 開發介面。 Vercel 和 Cloudflare：提供網站部署及執行所需的雲端服務。 Void 不是 Vercel 的直接替代品，Vinext 也不是把所有 Next.js 專案自動搬到 Cloudflare 的保證。選擇時應先看手上的專案、需要的功能和可接受的遷移成本。為什麼 Void 適合拿來學習 Vibe Coding？假設你想請 Codex 做一個活動報名網站。它可能需要網頁表單、API、資料庫和部署環境。過去，這些部分常要分別設定；Void 的目標是把 Vite 應用和 Cloudflare 資源放進較連貫的開發流程。 Void 主要由三個部分組成： Void SDK：在 Vite 專案中開發前端、伺服器路由及資源操作。 Void CLI：初始化專案、建置、建立或綁定 Cloudflare 資源、套用資料庫遷移並部署。 Void Platform：供團隊共用的部署平台，可自行架設並設定使用者權限和資源限制。初學者通常可以先從 SDK 和 CLI 開始，不需要一開始就安裝團隊用的 Platform。你可以先在自己的 Cloudflare 帳號裡建立一個小型練習，再視需要研究共用平台。 Void 的功能可以組合使用，也能和一些既有的 Vite 架構合作。不過官方目前將 Vinext adapters 列為實驗性支援；第一次學習時，先分開理解 Void 和 Vinext，會更容易判斷問題來自哪一層。Void Cloudflare 整合說明如何在 Mac 安裝 Void 並建立第一個專案？以下範例以 macOS 和 npm 說明。你需要 Node.js、終端機和 Void；若要部署到 Cloudflare，還需要 Cloudflare 帳號。Void 官方目前要求 Node.js 24.21.0 以上版本，其他作業系統也可依官方支援條件操作。Void 官方 GitHub 先確認 Node.js 版本打開 Mac 的「終端機」，輸入： 12node -vnpm -v 若 Node.js 版本低於 Void 目前要求的版本，請先更新。若你電腦上有其他 Node.js 專案，可以用 nvm 管理多個版本，避免更新後影響舊專案。建立練習資料夾並初始化在終端機輸入： 1234mkdir void-playgroundcd void-playgroundnpm install -D voidnpx void init 初始化指令會啟動設定流程，讓你選擇 UI 框架、起始範本和部署目標。Void 的 Vite+ 工具鏈是預設選項；如果只想先在本機學習，可以先略過部署設定。Void Quickstart 這篇用活動報名系統作為範例，可以選擇下列方向：設定項目練習選擇適合原因 Toolchain Vite+（預設）使用 Void 提供的整合工具鏈 Frontend React 建立常見的互動式網頁 Starter D1 練習網站、API 與 SQL 資料庫 Deployment Cloudflare 之後可部署到自己的 Cloudflare 帳號初始化時，Void 也會準備 Agent 可讀的專案指引。若要重新設定 Codex 等 Coding Agent，可以在專案根目錄執行： 1npx void init --agents 它會建立或更新 AGENTS.md，並依照可偵測到的 Agent 設定連結對應技能；這樣 Codex 可以讀取專案所安裝版本的 Void 文件，而不是只依賴模型記憶。Void Coding Agents 指南在本機啟動網站和 API初始化完成後，在專案資料夾輸入： 1npm run dev 依照終端機顯示的網址開啟瀏覽器，Quickstart 範例通常使用： http://localhost:5173 如果範本沒有 API 範例，可以新增 routes/api/hello.ts： 1234567import { defineHandler } from 'void';export const GET = defineHandler(() => { return { message: 'Hello from Void' };}); 再打開： http://localhost:5173/api/hello 你會看到類似以下 JSON： 123{ "message": "Hello from Void"} 這個路由的檔案路徑對應到 /api/hello，而 GET 表示用讀取方式回傳資料。Void 的官方 Quickstart 使用相同的入門範例；各種範本的檔案是否已預先建立，則要依初始化結果確認。Void Quickstart：呼叫伺服器路由如何用 Codex 開發一個報名網站？先把剛剛的 void-playground 專案開在 Codex。接著可以把以下提示詞貼給 Codex，請它先閱讀專案說明和已安裝版本的 Void 文件： 1234567891011121314151617181920212223242526272829你是一位熟悉 Void、React、TypeScript 與 Cloudflare Workers 的全端工程師。請先閱讀專案中的 AGENTS.md，以及 node_modules/void/ 內目前安裝版本的官方文件，再開始修改程式。我要建立一套簡單的活動報名網站。前台功能：1. 顯示活動名稱、日期和地點。2. 提供姓名與 Email 欄位。3. 在瀏覽器與伺服器端檢查必填欄位和 Email 格式。4. 成功寫入資料後，再顯示報名完成訊息。後端功能：1. 使用 Void 官方伺服器路由。2. 使用 Cloudflare D1 儲存報名資料。3. 使用資料庫 migration 管理結構變更。4. 防止同一個 Email 重複報名。管理功能：1. 管理頁必須有身分驗證和權限檢查。2. 未完成授權前，不能公開報名名單或 Email。開發規則：1. 優先使用專案已安裝版本的官方 API。2. 不要使用過時的 Void 語法。3. 不要建立不必要的第二套伺服器或部署流程。4. 先在本機完成開發與檢查，不要直接修改正式環境，也不要擅自部署。完成後請說明建立了哪些檔案、API 如何運作、資料存在哪裡、如何在本機測試，以及部署前還需要確認什麼。接著你可以在瀏覽器測試表單，並確認資料真的寫進本機 D1。不要只看畫面有沒有出現「報名成功」，還要檢查 API 回應和資料庫內容。正式網站也需要補上個資告知、垃圾報名防護和管理者權限。練習時不要使用真實的客戶資料，也不要把公開的名單頁當成登入驗證。如何將 Void 網站部署到 Cloudflare？本機功能確認完成後，若初始化時已選 Cloudflare 作為部署目標，可執行： 1npx void deploy 若當時略過部署設定，也可以指定 Cloudflare： 1npx void deploy --platform cloudflare 首次部署時，Void 可能會開啟瀏覽器要求登入並選擇 Cloudflare 帳號。CLI 會建置應用、建立所需資源、套用 migrations 並回報部署網址。Void 的 Cloudflare 部署指南部署後可到 Cloudflare 控制台的 Workers & Pages 檢查 Worker 狀態；若使用 D1，也要確認資料庫已建立並收到測試資料。本機 D1 與正式環境的 D1 是不同資料庫，本機測試資料不會自動複製到正式環境。部署前也要檢查 migration。程式碼回復到舊版本，不代表資料庫結構會自動回到舊狀態。第一次公開部署前，先理解哪些資源會建立、資料存在哪裡、帳號目前使用的方案與額度。 Vinext 是什麼？什麼時候才需要它？Vinext 是一個以 Vite 重新實作 Next.js API 的 Vite 外掛。它的目標是讓既有 Next.js 專案能保留許多熟悉的路由、元件和設定方式，再透過 Vite 建置並選擇合適的部署平台。 **如果你從零開始做一般 Vite 網站，通常不需要先安裝 Vinext。**它主要適合已經有 Next.js 專案、想評估 Vite 工具鏈或 Cloudflare Workers 部署的開發者。怎麼辨認既有專案是不是 Next.js？可以查看專案根目錄的 package.json。如果依賴中有 next，通常就是 Next.js 專案。app/、pages/ 和 next.config.js 或 next.config.ts 也常見於 Next.js 專案。如何先檢查相容性，再試用 Vinext？不要直接在正式專案上遷移。先建立 Git 備份或測試分支，再在專案目錄執行： 1npx vinext check 這會掃描部分已知相容性問題。檢查結果不能代替完整測試，但可以先找出值得注意的差異。若要建立 Vinext 設定，可接著執行： 1npx vinext init Cloudflare 文件中的典型流程會加入 dev:vinext 和 build:vinext 等 scripts。初始化後請先檢查 package.json，再依實際產生的指令啟動開發伺服器與正式建置： 12npm run dev:vinextnpm run build:vinext 部署到 Cloudflare Workers 的範例指令是： 1npx @vinext/cloudflare deploy 詳細流程請參考Cloudflare 的 Next.js／Vinext 指南。Cloudflare 也提供建立 Cloudflare-ready 專案的 C3 流程；若你是在既有 Next.js 專案上遷移，請以目前文件和 vinext init 的輸出為準。 Vinext 1.0 是否代表完全相容 Next.js？不是。Vinext 在 2026 年 9 月發布 1.0，代表它自身的公開 API 開始依循穩定版本規則；這不等於所有 Next.js API 和功能都已完整相容。官方文件仍列出部分功能差異，包括 Cache Components 和 Partial Prerendering，遷移正式網站前應查看相容性差異並實際測試。Vinext 1.0 說明・Vinext 相容性差異 Cloudflare 目前推薦在 Workers 上評估 Vinext；如果既有應用仍有相容性缺口，也仍保留 OpenNext adapter 等其他路徑。若網站只需要靜態輸出，Cloudflare Pages 也是另一種情境。選擇前先看專案實際用到的功能，不要只根據版本號或建置速度決定。 Vibe Coding 專案該選哪一種架構？可以先用下面幾種情境縮小範圍：專案情境可以先評估選擇時要注意品牌網站、作品集、簡單活動頁 Vite + 靜態網站代管如果沒有後端資料需求，不必增加全端架構從零開始做表單、預約或內部工具 Void + Vite + Cloudflare Workers + D1 確認資料庫、使用權限、個資與資源額度已有 Next.js 專案，想評估 Workers Next.js + Vinext + Cloudflare Workers 先跑相容性檢查，測試實際使用到的功能已有穩定的 Worker + D1 維持現有架構，按需要改善不要只為了新框架而重寫有會員、訂單、金流或多人維護需求先定義資料、權限、金流與維運需求需要比較完整架構與維護成本，不能只看部署一鍵化簡單來說：從零開始、想在 Cloudflare 上建立 Vite 全端應用，可以研究 Void；已經有 Next.js，才需要評估 Vinext；既有系統運作正常，就先確認遷移能解決什麼問題。若專案已經使用 Next.js 並依賴特定功能，可以比較 Vinext 的相容性差異，或繼續評估 OpenNext 等現有部署方式。Void 對 Vinext 的 adapter 目前仍是實驗性支援，正式系統要先做獨立驗證。Void Cloudflare 整合說明開始寫程式前，先請 Codex 做技術選型把需求交給 AI 後，不一定要馬上讓它寫程式。你可以先請 Codex 說明架構選擇、風險和還需要確認的資訊： 123456789101112131415161718你是一位熟悉 Vite、Next.js、Void、Vinext、Cloudflare 與 Vercel 的技術架構顧問。我準備建立一個網站。請先詢問並整理：1. 網站主要用途。2. 是否需要會員、資料庫、檔案上傳或金流。3. 是否已有現成專案，以及目前使用的框架。4. 是否指定部署平台、團隊流程或預算範圍。在開始寫程式前，請評估以下選項是否符合需求：A. Vite + 靜態網站代管B. Void + Cloudflare WorkersC. Next.js + Vinext + Cloudflare WorkersD. Next.js + VercelE. Cloudflare Worker + D1請比較學習成本、現有專案相容性、部署與維護需求、資料庫和權限設計，以及遷移風險。區分官方已說明的能力和仍需實測的部分。先提出推薦方案、理由和待確認事項；等我確認後再開始修改程式。不要直接部署正式環境。這段提示詞不保證 AI 每次都選對架構，但能讓你在程式碼產生前先看見方案取捨。架構不複雜時，也可以直接沿用熟悉且已運作穩定的工具。新手可以怎麼安排學習順序？如果要安排一門 Vibe Coding 入門實作課，我會拆成四個階段：先做一個簡單網站：用 Codex 和 Vite 建立互動網頁，認識本機開發與正式網站的差異。再加入 API 和資料庫：用 Void 建立表單、路由和 D1，確認資料如何從前端寫進資料庫。了解部署與環境：學習 Workers、D1、環境變數和 migration，理解測試資料與正式資料的區別。最後看既有 Next.js 專案：用測試分支檢查 Vinext 相容性，再比較不同部署路徑。這個順序會先建立網站與資料的基本概念，再逐步加入部署和遷移。新手不必在第一天就同時學會 Vite、Void、Vinext、Next.js、資料庫、Docker 和雲端維運。常見問答 (FAQ)Q1：Void 免費嗎？使用 Void 會不會產生 Cloudflare 費用？Void SDK、CLI 和 Platform 的原始碼以 MIT 授權公開，但 Cloudflare Workers、D1、R2 等雲端服務仍有各自的方案、額度和使用條件。軟體開源不代表雲端資源無限制免費；部署前請查看 Cloudflare 目前的方案與服務用量。 Q2：使用 Void 一定要架設 Void Platform 嗎？不需要。個人專案可以用 Void SDK 和 CLI，部署到自己的 Cloudflare 帳號。Void Platform 主要提供團隊共用的部署環境、權限和資源管理功能。 Q3：Void 可以完全取代 Vercel 嗎？不能一概而論。Void 適合需要 Vite 全端功能並希望部署到 Cloudflare 的情境；Vercel 有自己的 Next.js 整合、預覽部署和團隊工作流程。應依專案需求、既有架構和維護方式比較，而不是只看平台名稱。 Q4：Next.js 專案可以直接改用 Vinext 嗎？不能保證直接替換就能運作。Vinext 提供相容性檢查與遷移指引，但仍有尚未完整支援的 Next.js 功能。先備份專案、執行 npx vinext check，再在測試分支驗證實際使用的頁面、資料載入、快取與部署行為。 Q5：Void 和 Vinext 可以一起使用嗎？可以把兩者放在同一個架構評估中，但 Void 官方目前將 Vinext adapters 標示為實驗性支援。入門時先分開學習兩者；若要整合到正式專案，請查閱相同版本的官方文件並自行完整測試。結語：AI 幫你寫程式，選型仍需要理解Void 和 Vinext 代表兩種不同的開發需求：Void 把 Vite 全端應用、Cloudflare 資源和部署流程連在一起；Vinext 則讓既有 Next.js 專案有機會改用 Vite 工具鏈。使用 Codex 或其他 Coding Agent 時，不妨先確認網站是否需要後端、資料應存在哪裡、誰能存取資料，以及部署後由誰維護。AI 可以協助你寫程式，工具可以簡化部署，但是否值得採用某個架構，仍要回到專案本身。如果你想先補上 Vibe Coding 的基礎，可以接著閱讀從零開始用 AI 寫程式的 Vibe Coding 指南；若想了解 Cloudflare 專案的 API 與安全考量，也可以參考Vibe Coding、Cloudflare API 與安全設定。官方學習資源本文依據 2026 年 10 月 18 日可查閱的官方文件整理；指令和功能可能隨版本更新，請以安裝版本的文件為準。 Void 與 Cloudflare： Void 官方網站 Void Quickstart Void Coding Agents 指南 Void Cloudflare 整合與限制 Void 官方 GitHub Cloudflare：Deploy with Void Cloudflare Workers 文件 Cloudflare D1 文件 Vinext： Vinext 官方網站 Vinext 1.0 說明 Vinext 文件 Vinext 相容性差異 Cloudflare：Next.js 與 Vinext 部署指南 Node.js： Node.js 下載頁面
2026/10/18
AI工具 ChatGPT 影音行銷

【六首歌如何寫成一季故事？用 ChatGPT、Suno 規劃 AI 音樂 MV】

最近看到有人分享一個 GitHub 開源專案，搭配「金曲獎作詞家秘訣也開源了」這類說法，讓人忍不住想點進去看看。先說明：目前不能只憑這份文件確認作者具有金曲獎作詞家身分，也不適合把它說成官方作詞秘訣。真正值得看的，是如何先規劃一整季的歌曲與 MV，再一集一集製作。這個專案叫 autoip-mv-maker。它的 README 介紹的是一套 AI 音樂 MV 製作流程；本文聚焦在其中獨立的系列企劃文件，並把觀念改寫成新手可以用 ChatGPT 和 Suno 練習的步驟。這些提示詞是入門練習，不代表必須先安裝該專案。以前用 AI 寫歌，常常是想到一個主題，就請它「寫一首關於失戀的歌」，再把歌詞交給音樂生成工具。第一首完成後，下一首又從零開始想，歌與歌之間未必有關聯。另一種做法是先規劃整個系列：六首歌可以各自成立，也能依序講完一段故事。第一首相遇、第二首曖昧、第三首告白，直到最後一首重逢。當故事主軸、角色、音樂特色和畫面方向先有共識，後續寫歌詞、生成歌曲與安排 MV 都比較容易接起來。先認識這個 GitHub 專案與系列企劃文件GitHub 專案本身涵蓋歌曲分析、分鏡、影像生成、剪輯、字幕與上架素材等 MV 製作流程；SERIES_PLANNING.md 則是規劃一季內容的文件。兩者的用途不同：你可以先讀系列規劃文件、用 ChatGPT 和 Suno 做創作練習；如果之後要執行專案中的完整自動化流程，再依 README 準備需要的環境。初學時先搞懂這幾個詞就夠了：名詞白話解釋 GitHub 放置程式碼與開源文件的平台 Prompt 你交代 AI 工作的指令 Hook 歌曲中容易被記住、可能反覆出現的一句歌詞或旋律 Suno 可依文字描述生成歌曲的 AI 音樂工具系列企劃開始做第一首歌前，先定義整季的故事與共同特色第一步：替整季歌曲定主軸系列企劃文件建議先用一句話說明整季，再找一條能把各集排出順序的主軸，接著挑出幾個跨集固定的風格錨點，並為每集寫企劃卡。季數、題材與故事結局都可以自行決定；文件中的 4 到 8 集只是系列規劃的例子。例如：都市愛情流行 × 六首歌，每首歌推進兩個人之間的距離，從相遇走到重逢。這句話同時交代題材、形式、集數和故事變化方向。接著可以把六首歌排成一條故事線：集數歌曲概念故事位置可發展的 MV 畫面 EP01 那天的雨雨天第一次相遇捷運出口、雨傘、街燈 EP02 多走一站兩人開始曖昧一起搭車、錯過下車提醒 EP03 我想告訴你終於鼓起勇氣告白夜晚散步、停在路口的對話 EP04 沒說出口誤會讓兩人分開沒有送出的訊息、空下來的座位 EP05 你的城市分開後各自生活兩個城市、相似的雨景 EP06 還好是你多年後再次相遇熟悉的街角、再次撐起的雨傘每首歌都可以自己聽，但角色與事件會逐步往前走。除了愛情故事，也可以用季節、一天的時間、人物選擇、距離變化或逐步揭曉的線索當主軸。用幾個穩定錨點保留系列感系列企劃文件把固定項目稱為「錨點」。你可以挑 3 到 5 個跨集保留，例如：同一組主角、固定的歌曲段落結構、某個反覆出現的物件、相似的 MV 畫面語言，或固定的縮圖與標題格式。其他項目仍可依每首歌的故事調整。這樣做是為了讓觀眾感覺「這些作品屬於同一個系列」，不代表每首歌都要使用一模一樣的曲風、場景或旋律。四種可以自行採用的歌曲敘事練習以下是把系列故事轉成歌曲的創作方式，供新手練習；它們不是原專案規定的固定結構。練習方式怎麼使用簡單例子問答式讓前後兩首歌互相回應男生唱「如果那天我沒有轉身，你會不會等我？」；下一首由女生回答「我其實一直都在等。」變形 Hook 保留熟悉句型，依劇情改變結尾「如果時間能夠重來」，從「我還是會遇見你」變成「我依然會選擇你」章回式每首歌代表故事的一個階段相遇、靠近、衝突、分開、重新選擇首尾呼應讓最後一首回到第一首的場景或意象開場在雨中相遇，結尾多年後又在雨中相逢新手可以先試「章回式＋變形 Hook」：前者幫你排故事順序，後者讓觀眾在不同歌曲裡聽到熟悉的線索。實際創作時仍要讓旋律、節奏和編曲有變化，避免每首歌聽起來只是同一首歌的改寫。第二步：先請 ChatGPT 規劃歌曲清單先不要一次寫完六首歌詞。打開 ChatGPT，請它先做系列企劃卡，讓你確認故事方向、歌曲情緒與畫面是否合理。提示詞：規劃一季歌曲12345678910111213141516你是一位華語流行音樂企劃人、作詞人與音樂製作人。我是沒有作詞經驗的新手，想製作一個六首歌的音樂系列。系列主題：從相遇到重逢的都市愛情故事。請幫我規劃六首歌，每首歌列出：1. 歌曲名稱2. 主要故事與它在整季中的位置3. 情緒氛圍與建議曲風4. 男聲、女聲或男女合唱5. 一句可以發展成 Hook 的歌詞概念6. 未來製作 MV 時可以呈現的視覺場景六首歌要有連續劇的感覺，但每首也能獨立欣賞。請使用自然的台灣繁體中文，不要過度文青或生硬。先用表格提供企劃，不要直接寫完整歌詞。收到企劃後，先檢查每一集是否真的改變了故事狀態。例如第二首是否讓兩人更靠近、第四首是否有足以造成衝突的事件、最後一首是否回應前面留下的問題。若只是六首歌都在重複「很愛你、很想你」，就回頭調整主軸或每集企劃卡。第三步：挑一首歌，分段寫歌詞先挑 EP01 試做，確認角色、語氣與 Hook 是否自然，再把相同的系列設定帶到下一首。提示詞可以像這樣：提示詞：寫第一首完整歌詞12345678910111213141516171819202122請根據剛才規劃的六首歌系列，開始寫 EP01《那天的雨》。故事：男女主角在雨天的捷運出口第一次相遇。曲風：華語流行抒情，溫暖自然，帶一點電影感。演唱：溫暖的男性聲線。歌詞要求：1. 使用自然的台灣繁體中文。2. 句子長短可以有變化，不要為了押韻使用奇怪的詞。3. 副歌有一句容易記住的 Hook。4. 使用雨傘、捷運出口、街燈等具體畫面，避免空泛形容。5. 歌曲要能接上後續五首的故事。請用以下段落標籤輸出，並檢查唱起來是否自然：[Verse 1][Pre-Chorus][Chorus][Verse 2][Chorus][Bridge][Final Chorus][Outro] Verse 是主歌、Pre-Chorus 是預副歌、Chorus 是副歌、Bridge 是橋段、Outro 是結尾。這些標籤可以協助描述歌曲段落，但生成結果仍要實際聽過再調整。第四步：把歌詞交給 Suno 生成歌曲打開 Suno，使用目前介面中可以自行輸入歌詞與音樂描述的創作方式。按鈕名稱與功能可能隨平台更新而變動；先確認現在的介面支援你要使用的輸入方式。準備三項內容： Title：例如「那天的雨」。 Lyrics：貼上整理好的歌詞和段落標籤。 Style：描述曲風、樂器、情緒與演唱方向。例如： 123Mandarin pop ballad, warm male vocal, emotional storytelling,soft piano, acoustic guitar, gentle drums, cinematic atmosphere,memorable melodic chorus, natural vocal delivery. 也可以用中文描述： 12華語流行抒情，溫暖成熟男聲，鋼琴與木吉他編曲，柔和鼓組，有電影感，副歌旋律容易記住，演唱自然有情緒。生成後先聽歌詞是否順口、Hook 是否記得住、情緒是否符合這一集。若不滿意，先找出問題來自歌詞、旋律、演唱或編曲，再針對該項修改，不必立刻把整首歌全部推倒重來。第五步：整理系列風格設定在繼續做 EP02 前，把整季固定的錨點整理成一份 style.md。不需要把所有細節鎖死；保留幾個跨集共同點，讓每首歌仍有自己的變化。提示詞：建立系列風格設定1234567891011請根據這六首歌的企劃，整理一份系列風格設定草稿 style.md。請先挑出 3 到 5 個值得跨集固定的錨點，例如：- 整季故事主題與主軸- 主角外觀或人物關係- 歌曲段落結構、人聲配置或反覆出現的聲音記號- 歌詞用字與語言風格- MV 的共同視覺元素或包裝方式另外列出每集可以自由變化的項目，例如曲風、場景、主色或象徵物。說明每首歌如何連到下一首，並保留人工調整空間。相同的曲風文字不保證每次生成都會得到完全相同的歌聲或編曲。若你需要較一致的人聲，請依目前平台提供的設定測試，並以實際生成結果為準。第六步：從歌曲企劃發展 MV 分鏡先完成歌曲，再把故事和歌詞拆成畫面。初學可以先用簡單流程：歌曲 → 故事分鏡 → 角色參考圖 → AI 影片片段 → 剪輯成 MV 以 EP01《那天的雨》為例，可以從下列畫面開始：分鏡畫面內容 01 台北雨夜，行人穿過捷運站出口 02 男主角走出車站，發現有人在屋簷下躲雨 03 他把雨傘往對方身邊移了一點 04 兩人在街燈下對視，音樂進入副歌 05 女主角離開，男主角回頭看向她的方向提示詞：把歌曲轉成 MV 分鏡123456789101112131415我已經完成歌曲《那天的雨》。請根據歌詞設計一支 AI 音樂 MV 分鏡表。影片比例：16:9。視覺方向：台灣都市愛情電影、寫實攝影、溫暖色調。場景：捷運站出口、雨天街道、便利商店、夜晚街燈。請依歌曲實際長度安排每個分鏡，列出：1. 開始與結束時間2. 對應歌詞3. 畫面與角色動作4. 攝影機運動5. 靜態圖片提示詞與影片提示詞以 5 到 10 秒片段作為初步規劃單位，維持角色外觀、服裝與場景連續。先給我分鏡表審核，不要直接生成影片。依照歌曲時間安排畫面，也要考慮生成片段可能需要裁切、延長或重新剪接。不要期待每段 AI 影片剛好符合節拍；最後仍要在剪輯軟體中調整鏡頭長度、音樂進點與轉場。進階：再考慮使用完整 MV 自動化專案如果只是練習系列企劃、寫歌詞和生成歌曲，可以先不下載或安裝 autoip-mv-maker。若要實際執行該專案，請先讀取它的官方 README：目前文件提到 AutoIP API、ffmpeg、字型與 API key 等前置條件，生成影像任務會使用點數。請在送出前查看靜圖與成本資訊，並依專案文件保管 API key；不要把 key 寫進一般檔案或貼進提示詞。若你只是想用 Codex 整理自己的企劃，也可以先建立簡單資料夾，管理故事設定和素材版本： 1234567891011121314151617my-ai-music-series/├── README.md├── style.md├── research.md├── characters/│ ├── male.md│ └── female.md├── episodes/│ ├── EP01/│ │ ├── lyrics_v1.txt│ │ ├── suno_style.txt│ │ └── storyboard.md│ └── EP02/└── assets/ ├── images/ ├── audio/ └── videos/ 這只是方便自己管理的資料夾範例，不是 autoip-mv-maker 安裝後自動建立的目錄。你可以請 Codex 協助整理企劃、比對每首歌是否符合 style.md，或把歌詞改寫成分鏡表；真正的歌詞、生成歌曲與影片仍要逐項檢查。開始前，先確認這四件事用一句話說清楚整季的題材與變化方向。每首歌都有自己的故事位置，而不是重複同一種情緒。選出 3 到 5 個跨集錨點，其他細節保留變化空間。先完成一首歌和一支 MV 的分鏡，再決定如何延伸整季。 AI 可以幫忙發想、整理和生成素材，但歌曲是否自然、故事是否說得通、角色是否連貫，仍要由創作者檢查。製作或發布作品前，也要確認歌曲、角色圖、字型與其他素材的使用權，並遵守所用平台的內容揭露規範。常見問答 (FAQ)Q1：這個專案證實作者是金曲獎作詞家嗎？不能只憑系列企劃文件確認作者具有金曲獎作詞家身分。本文聚焦的是文件中的系列規劃方法，不把網路貼文的說法當成已證實事實。 Q2：只用 ChatGPT 和 Suno 練習，需要安裝 GitHub 專案嗎？不需要。你可以先用 ChatGPT 整理故事與歌曲企劃，再用 Suno 試做歌曲；若要執行 autoip-mv-maker 的完整 MV 流程，才依官方 README 準備 API、ffmpeg、字型等環境。 Q3：把相同的 Style 提示詞貼給 Suno，就能固定歌手聲音嗎？不能保證。相同的描述可能產生不同的聲音或編曲；可依平台當前提供的聲音或延續功能測試，並以實際生成結果確認。 Q4：一定要做六首歌，才能叫音樂系列嗎？不一定。六首只是本文的示範規模。你可以依故事調整集數，重點是有清楚的共同主軸，並讓每一集既能獨立欣賞，也能推進整體內容。
2026/10/16
AI工具 Vibe Coding AI Coding

AI 讓寫程式越來越便宜，但真正值錢的是產品判斷力

AI Coding、Vibe Coding 讓更多人做得出網站、系統，甚至一個完整的 SaaS。當開發速度愈來愈快，真正該問的問題也跟著改變：我們做出來的功能，真的有人需要嗎？我最近讀到一篇文章，標題是〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。文中用一個產品團隊的情境開場：導入 AI Coding Agent 後，團隊每個 Sprint 能完成的功能增加了，轉換率卻沒有提升，客訴反而增加。有人因此說：「我們好像只是把『做錯的東西』做得更快而已。」這是原作者設定的情境，不是實際研究數據；但它提醒了我，做得出來，不代表有人需要。 AI 降低了實作門檻，沒有替我們確認需求以前做網站或開發系統，常見的難題是「做不出來」。現在有了 Codex、Claude Code 等 AI Coding 工具，即使不是專業工程師，也能更快做出過去需要整個團隊才能完成的功能。但技術門檻降低，不會自動讓產品更符合需求。若只是把想像中的功能快速做完，可能只是更快地解決一個尚未證實的問題。先用兩張地圖看清楚問題與解法Customer Journey Map：找出使用者在哪裡卡住Customer Journey Map（顧客旅程地圖）從使用者的角度，整理他接觸產品、評估、購買、使用到後續服務的過程。它協助團隊找到使用者在哪一段遇到疑問或阻礙，而不是一開始就列出想開發的功能。例如，有人看到 AI 課程介紹後進入網站，可能想知道課程適不適合初學者、實體課與錄播課有什麼差別、購買後能觀看多久，或臨時無法上課時該怎麼辦。這些疑問不一定需要新功能；清楚的文案、簡化的購買流程或一段 FAQ，也可能更直接地解決問題。 User Story Map：把使用者目標拆成可交付的步驟User Story Map（使用者故事地圖）則從使用者想完成的目標出發，把過程拆成活動、步驟與支援功能，接著安排 MVP 先做哪些、哪些留待後續。以報名課程為例，學員可能需要瀏覽課程、比較方案、完成付款、收到通知，最後取得上課權限。整理出這些步驟後，團隊才能討論第一版要支援哪些必要流程。簡單來說，Customer Journey Map 協助我們發現問題，User Story Map 協助我們規劃解法，AI 則可以協助實作。 AI 能整理需求，也會把假設寫得像事實假設你告訴 Codex：「我要開發線上課程平台，學員應該很在意學習證書，請幫我規劃完整的證書系統。」AI 可能很快列出自動發證、QR Code 驗證、證書下載、公開查詢與管理後台，而且規格看起來完整又合理。但在投入開發前，仍要確認學員是否真的需要證書。如果他們更在意課程內容是否實用、影片能不能重複觀看，那套證書系統可能只是解決了我們想像中的問題。 AI 可以協助整理需求，卻不能代替真實資料。沒有訪談、客服紀錄、行為數據或其他證據支持的需求分析，仍然只是待驗證的假設。使用者遇到問題，也不代表一定要增加功能。從 Story Map 再往下寫成開發規格User Story Map 能說明使用者想完成什麼，卻未必包含 AI Coding Agent 實作所需的細節。例如，「身為學員，我希望購買課程後可以觀看教學影片」還需要回答：影片放在哪裡？付款失敗怎麼處理？觀看權限如何判斷？課程到期後會發生什麼事？直播回放尚未發布時要顯示什麼？這些細節需要進一步整理成開發規格（Spec）、業務規則與驗收標準。可以先用 Journey Map 和 Story Map 理清方向，再讓 AI 協助產出詳細規格，而不是直接開始寫程式。也可以把產品規劃整理在 docs/product/，並透過 AGENTS.md 指引 Codex 閱讀相關背景，讓它理解功能的目的與前後流程。再加一張成果地圖，確認功能是否真的有用我還會多問一個問題：功能完成後，我們怎麼知道它改善了使用者的處境？我把這個思考方式稱為 Outcome Map（成果地圖）；這是本文用來描述成果導向規劃的方式，不是某套特定的標準工具。假設學員常因為看不懂購買方案而猶豫，團隊決定把三種方案的權益說明得更清楚。完成方案比較頁只是交付了功能，接著還要觀察學員是否更容易選擇、付款完成率是否有改善、詢問方案差異的客服訊息是否減少。這些是要驗證的結果，不是預先保證會發生的成效。規劃工具協助回答的問題 Customer Journey Map 使用者在哪個階段遇到問題？ User Story Map 使用者要完成目標，需要哪些步驟與支援？ Outcome Map（本文的延伸用法）我們要觀察什麼，才能判斷改善是否有效？根據實際觀察再決定下一個版本要改什麼，才不會落入「想到功能、交給 AI、開發完成、再想到新功能」的循環，讓網站愈做愈大，卻說不清楚改善了什麼。下次使用 Codex，先請它協助規劃與其一開始就說「幫我做一個有會員、金流、後台和課程管理的網站」，不妨先用一段提示詞，要求 AI 整理需求、假設、MVP 與驗收方式：先不要寫程式。請扮演產品經理與 UX 顧問，協助我分析目標使用者、使用情境及主要痛點。請區分已知事實與待驗證假設，建立 Customer Journey Map 和 User Story Map，規劃 MVP，並提出每項功能的驗收標準與成功指標。最後告訴我哪些功能目前不建議開發，以及原因。等我確認規劃後，再開始寫程式。這樣可以讓 AI 先協助思考需求、檢查假設與規劃產品，再進入開發。最後是否採納規劃、是否真的要做，仍然需要由我們判斷。功能愈容易開發，愈要考慮維護成本程式碼變便宜，不代表維護系統也變便宜。每增加一個功能，都可能帶來資料庫、權限、測試、資安、客服與後續維護工作。透過 AI Coding 一個人能做更多事，也可能變成一個人要維護更多複雜系統。這和我在 AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍談到的維護問題相通。 AI 時代需要培養的不只是 Prompt 技巧或寫程式的能力，也包括產品判斷力：理解使用者遇到什麼問題、判斷哪些事情值得做、哪些可以先不做，並設法驗證結果。若你正在從想法評估產品，也可以延伸閱讀如何從產業痛點找到值得做的微型 AI 產品。以前軟體開發最怕「想得到，卻做不到」。現在更值得警惕的是「想得到，也做得到，卻沒有人需要」。未來厲害的 AI 開發者，未必是一天讓 Codex 寫出一百個功能的人，也可能是能判斷哪些功能根本不需要寫的人。產品的價值，從來不是功能有多少，而是解決了多少真正的問題。 📌 閱讀啟發：〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。本文從原作者對 Customer Journey Map 與 User Story Map 的討論出發，延伸分享我對 AI Coding、需求驗證、開發規格與產品成果衡量的看法。標籤： #AICoding #Codex #ClaudeCode #VibeCoding #產品思維 #CustomerJourneyMap #UserStoryMapping #AI應用常見問答 (FAQ)Q1：Customer Journey Map 和 User Story Map 有什麼不同？Customer Journey Map 從使用者經歷出發，幫助找出旅程中的疑問與阻礙；User Story Map 則把使用者目標拆成活動、步驟與支援功能，協助安排 MVP 與後續工作。 Q2：User Story Map 可以直接交給 AI Coding Agent 開發嗎？它能提供使用者目標與流程脈絡，但通常還需要補上開發規格、業務規則、錯誤情境與驗收標準，例如付款失敗、觀看權限或課程到期時要如何處理。 Q3：文中提到的 Outcome Map 是標準產品工具嗎？不是。本文以 Outcome Map 稱呼「定義功能完成後要觀察哪些使用者或業務結果」的思考方式，並明確將它作為作者的延伸用法，而非特定標準工具。 Q4：AI Coding 讓開發成本趨近於零了嗎？AI Coding 可以降低部分實作成本，但不會讓資料、權限、測試、資安、客服與維護工作自動消失。每個新功能仍要評估它帶來的長期成本與實際價值。
2026/10/16
AI工具 Vibe Coding Codex

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

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