部落格

不定期分享最新資訊文章

徐享／享哥

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)

2026/9/2
商業策略 AI工具 Vibe Coding

Vibe Coding 真正要殺死的，可能不是 SaaS，而是「不值得被做成軟體」這句話

今天看到一篇分享文，介紹一個很有趣的網站：Can I Vibecode It? 它收錄了超過 1,000 個付費軟體，然後問一個很暴力的問題：這個服務，我能不能直接用 AI 自己做一個？像 Linktree、Todoist、Tally、Bitly 這些服務，它甚至會直接告訴你：可以。接著，它還會附上一段 Prompt，讓你丟進 Claude Code、Cursor 這類 AI Coding 工具，直接開始做。一開始看到這個網站，我跟很多人的第一個反應差不多：靠，這樣可以省很多 SaaS 訂閱費耶。😂 但想了一下，我反而覺得：省訂閱費，可能是這件事情最不重要的影響。 AI 正在讓「功能」快速商品化仔細看那些容易被 Vibe Coding 重做的軟體，會發現它們通常都有一些共同特色：資料庫表單 Dashboard 會員登入幾支 API 再加上一個漂亮的 UI 以前要把這些東西組起來，你可能得找工程師、設計師，開發幾個星期。所以即使功能不算複雜，也足以成立一家 SaaS 公司。但 AI Coding 正在快速壓低這件事情的成本。如果一套產品最核心的價值，只剩下：我們已經幫你把這幾個功能寫好了。那它的護城河就會越來越薄。因為現在 AI 也會寫。 AI 可以複製 Feature，卻不等於複製 Service這裡有一個很容易掉進去的陷阱： AI 可以做出 80%，不代表我應該自己做，更不代表這套 SaaS 沒價值了。因為 Demo 做出 80%，跟真正可以營運的產品完成 80%，完全是兩回事。真正上線之後，你還會遇到：權限管理資安備份監控 API Rate Limit Webhook Retry 付款異常資料遷移多人協作法規與客服很多時候，畫面上最後那 10%，才是最貴的 60%。所以我現在會把一件事情分成兩個層次來看： AI 很會複製 Feature，但要複製一個真正可靠的 Service，還是另一回事。 SaaS 真正的價值，早已不只功能這也是為什麼有些 SaaS 反而沒那麼容易被取代。例如 Shopify、Figma、Intercom，甚至 ChatGPT、Claude，你真正付錢買的，早就不只是那些畫面上的功能。你買的是：整個生態系累積多年的資料團隊協作能力第三方整合 Infrastructure 穩定性資安與合規出問題的時候，有一家公司幫你扛所以未來 SaaS 真正的護城河，很可能會從：我有什麼功能？慢慢移到：就算 AI 可以把我的功能全部重做一遍，你為什麼還是不想離開我？我覺得這會變成未來幾年 SaaS 公司很重要的一道題目。一人公司真正看見的是「Personal Software」但對我們這些一人公司、小企業來說，我看到的是另一個更大的機會。假設我花兩天做一個自己的 Calendly，每個月省 12 美元。其實我覺得沒有很厲害，搞不好我的時間還比較貴。😂 但如果我把它改造成：台灣美容業 LINE 預約系統事情就不一樣了。除了預約，我再加入： LINE OA 通知會員資料預約提醒回訪生日行銷 AI 客服顧客標籤業績分析這時候我做的已經不是 Calendly Clone，而是把某個產業真正的工作流程與 Know-how，變成一套軟體。這就是我最近越來越有感的一件事情：專業知識軟體化。以前我們找軟體配合工作，現在可以讓軟體配合自己這可能才是 Vibe Coding 最有意思的地方。以前的軟體大概只有兩種。第一種是商業軟體：做一套產品，賣給幾萬、幾十萬人。第二種是企業客製：公司花幾十萬、幾百萬，請軟體公司開發。但現在開始出現第三種：Personal Software。它只為一個人、三個人或十個人存在，卻可以非常貼近使用者的實際工作方式。例如：我自己的講師邀約管理系統自己的客戶 Follow-up 工具自己的內容素材庫自己的社群內容生產工作流自己的 AI 影片成本計算器公司裡某個每天重複 30 分鐘的小流程以前你跟工程師說：這個只有我自己會用。工程師大概會問：那幹嘛做？😂 因為開發成本根本不划算。現在答案可能完全相反：就是因為只有你會用，所以更應該做成最適合自己的樣子。從「省訂閱費」到「把工作方法變成產品」所以現在我看到 SaaS，開始會多問一個問題。不是：這套軟體一個月多少錢？甚至不只是： AI 能不能把它做出來？而是：這個軟體裡，我真正需要的是哪幾個功能？接著再問：如果把那些功能拆出來，再加入我的工作流程與專業知識，會不會變成一個全新的東西？這兩個問題差很多。前者是在想：怎麼省掉每個月 20 美元。後者是在想：我能不能把自己的工作方法變成產品。如果你想延伸理解這條路徑，也可以先看〈把專業知識變成軟體，產業專家就是下一代產品經理〉，以及〈AI 讓程式碼越來越便宜，但知道什麼值得做正在變得越來越貴〉。 Vibe Coding 改變的是「軟體的經濟學」過去有非常多需求，不是做不到，而是：不值得做。市場太小，不值得只有三個人用，不值得公司內部流程，不值得一個月只省幾個小時，不值得需求太客製，不值得因為工程師太貴、開發週期太長、維護成本太高。但是當 AI 把開發成本壓下來之後，大量以前「不值得被做成軟體」的需求，突然開始值得了。所以我認為真正值得注意的，不是： AI 會殺掉多少 SaaS？而是：以前只有軟體公司值得開發的東西，現在每家公司、每個專業工作者，都開始值得擁有自己的軟體。而這背後甚至可能形成一條新的產品路徑：拆解 SaaS Feature → AI 重建 → 加入自己的工作流程 → 加入 Domain Knowledge → 變成 Internal Tool → 最後產品化成 Vertical SaaS 這條路徑的重點，不是把所有 SaaS 都重做一遍，而是從既有產品理解問題，再把自己的工作方法放進去。結語：重新定義自己的軟體所以下次看到一套很棒的 SaaS，我可能不會第一時間想：能不能不要付錢？我反而會想：它到底解決了什麼問題？如果把這個能力，加上我比軟體公司更懂的產業知識，會變成什麼？這可能才是 AI Coding 時代，真正值得玩的地方。不是什麼都自己做，而是以前我們只能「選軟體」，現在開始有能力：重新定義自己的軟體。常見問答 (FAQ)Q1：Vibe Coding 會取代 SaaS 嗎？Vibe Coding 會讓許多 SaaS 的基礎功能更容易被重做，但不代表所有 SaaS 都會被取代。真正可靠的 Service 還包含資安、備份、監控、整合、穩定性、合規與客服等營運能力。 Q2：AI 可以做出 SaaS 的 80%，是不是就應該自己開發？不一定。是否適合自己開發，還要比較開發與維護時間、資料安全、權限管理、付款與整合等營運成本。如果只是為了省一筆訂閱費，自己的時間成本可能反而更高。 Q3：什麼是 Personal Software？Personal Software 是只服務一個人、小團隊或特定公司的軟體。它不追求服務大量使用者，而是把使用者自己的流程、規則與專業知識，做成最貼近實際工作的工具。 Q4：如何把 SaaS 功能變成自己的產品？可以先拆解 SaaS 真正解決的問題，挑出自己需要的核心功能，再用 AI 重建，接著加入自己的工作流程與 Domain Knowledge。完成後先作為 Internal Tool 使用，驗證有效再考慮產品化成 Vertical SaaS。 Q5：SaaS 在 AI 時代還剩下什麼護城河？SaaS 的護城河會越來越依賴生態系、累積資料、團隊協作、第三方整合、基礎設施、穩定性、資安、合規與服務承擔，而不只是功能數量。核心問題會變成：即使功能能被重做，使用者為什麼仍然不想離開？
2026/9/1
AI工具內容行銷影音行銷

當 AI 生成影片比你看得還快：真正的「無限影片」開始了

15 秒的 AI 影片，要生成多久？ 9 秒。乍看之下，好像只是 AI 影片又變快了。但我覺得，真正值得注意的根本不是「9 秒」。而是 AI 影片跨過了一條很重要的線：生成速度，開始超過播放速度。這件事可能比「畫質又提升多少」重要得多。本文提到的 H3 Max、Infinite Slop、Nothing, Forever，以及影片生成成本，依使用者提供的觀察與估算整理。模型版本、服務狀態、推論速度與價格都可能變動，實際使用時仍應以當下方案為準。只要生成速度超過播放速度，影片就可以沒有結局8 月 29 日，fal 工程師 Rehan Sheikh 把影片生成模型接上 Twitch，做了一台永遠播不完的「無限跨次元電視」。底下跑的是 fal 的 H3 Max。官方數字是：5 秒影片，3 秒內生成。後來獨立開發者 Pieter Levels 實測，15 秒影片大約 9 秒跑完。為什麼這個數字重要？因為只要：生成時間 < 播放時間當你還在看前面 15 秒時，AI 已經把後面 15 秒生好了。你開始看第二段，AI 又繼續生成第三段。 115 秒 → 15 秒 → 15 秒 → 15 秒 → …… 只要生成佇列沒有中斷，理論上就能永遠延伸下去。觀眾正在做什麼 AI 同時在做什麼播放第 1 段 15 秒影片生成第 2 段 15 秒影片播放第 2 段 15 秒影片生成第 3 段 15 秒影片播放第 3 段 15 秒影片生成第 4 段 15 秒影片所以未來 AI 影片模型比的，可能不再只是：一次可以生成幾秒？而是：能不能永遠比觀眾快一步？這會把 AI 影片的競爭，從「單次生成品質」推向「持續生成能力」。三年前，無限的是劇本，不是畫面其實「永遠播不完的 AI 節目」，三年前就有人做過。 2022 年底，Twitch 出現一個很有名的頻道：Nothing, Forever。它可以 24 小時不斷演出 AI 情境喜劇。但當年的方法其實完全不同。角色、場景與 3D 資產都事先準備好，再由 Unity 即時排列組合。AI 主要負責生成對白。換句話說，當時比較像： 1AI 編劇 + TTS + 遊戲引擎三年前我們做到的是：劇本永遠寫不完。但今天不一樣。人物可以生成，場景可以生成，動作可以生成，鏡頭可以生成。甚至連「下一秒的世界長什麼樣子」，都可以下一秒再決定。 Nothing, Forever Infinite Video 角色、場景與 3D 資產預先準備人物、場景與鏡頭可以即時生成 AI 主要生成對白 AI 直接生成畫面本身無限延伸的是劇本無限延伸的是世界所以我覺得這次最值得記住的一句話是：三年前，無限的是劇本。現在，無限的是畫面本身。 AI 開始即時生成世界，而不只是幫你做影片更有趣的事情，很快就發生了。十幾個小時後，Pieter Levels 自己做了一個互動版本：Infinite Slop。觀眾在聊天室輸入什麼，AI 就嘗試把它變成下一段影片，而且還會試著延續前面的故事。例如有人說：「讓恐龍出現。」下一段真的可以出現恐龍。有人說：「去東京。」故事就可以往東京發展。這時候，整個媒體邏輯其實已經變了： 1觀眾 → AI → 影片 → 觀眾 → AI → 下一段影片觀眾不只是 Audience，觀眾本身開始變成 Prompt。以前是創作者先完成內容，再交給觀眾觀看；現在則可能是觀眾提供方向，AI 即時生成內容，再把新的內容交回觀眾。這已經不只是「AI 幫你做影片」，而是 AI 開始替你生成一個可以持續變化的世界。為什麼 AI 電影可能不是最有趣的終點？現在大家聊 AI Video，很容易問：什麼時候可以直接生成一部兩小時電影？但這可能是在用舊媒體的框架，理解一個新媒體。因為如果影片可以即時生成，為什麼還一定要是一部固定的電影？它可能變成： AI 實境秀 AI VTuber AI 兒童故事 AI 連續劇 AI NPC 世界 AI 購物頻道永遠不會完結的直播節目更進一步，未來甚至可能不是「100 萬人看同一部電影」，而是「100 萬人看 100 萬個版本」。你喜歡懸疑，AI 就讓故事更懸疑。你喜歡東京，故事就往東京發展。某一段你快轉，AI 知道你沒興趣；某個角色出現時你停留很久，AI 知道你可能喜歡他。影片開始不是「播放給你看」，而是：一邊播放，一邊為你生成。今天我們叫： Video on Demand 未來搞不好會變成： Reality on Demand 你選的不再是哪一部影片，而是：今天，我想進入什麼世界？如果你想先理解 AI 影片時代需要哪些判斷能力，也可以延伸閱讀〈學 AI 影片，你最不該做的，可能是先去學怎麼當導演〉。真正卡住 AI 的不是技術，而是推論成本不過，現在真正卡住 AI 的，已經不是技術。是錢。 Rehan Sheikh 後來自己算了一筆帳：如果 H3 Max 480p 標準價格以每秒成品影片 0.05 美元計算，24 小時不停生成的成本大約是：一天：約 4,320 美元一個月：約 129,600 美元一年：接近 158 萬美元而且這還只是影片推論成本，還沒有算頻寬、儲存、直播服務、監控與其他營運支出。因此現在其實是一個很有趣的階段：能力已經到了，速度開始到了，但經濟模型還沒到。 Infinite Slop 能一直跑，其中一個原因就是 fal 在贊助運算成本。這也提醒我們，Demo 可以先證明「做得到」，但要變成真正的新媒體，還需要讓它「長期付得起」。接下來真正值得觀察的，不只是「下一代模型快多少」，而是三條曲線：曲線代表的問題能力 ↑ AI 能不能生成更穩定、更連貫的世界？速度 ↑↑ 能不能持續跑在觀眾播放速度之前？成本 ↓ 這種內容能不能長時間、低成本運作？當這三條線真正交會，Infinite Video 才會從一個很酷的 Demo，變成真正的新媒體。 9 秒只是數字，跨過那條線才是新聞所以如果只把這件事情理解成：現在 AI 生成 15 秒影片只要 9 秒。我覺得反而小看它了。真正重要的是：AI 影片第一次開始生得比人類看得還快。今天是 9 秒，以後可能是 6 秒、3 秒，甚至接近即時。當「生成速度 > 消費速度」之後，我們真正該問的就不再是： AI 可以幫我多快做完一支影片？而是：如果影片根本不需要做完呢？沒有固定片長，沒有固定劇本，也沒有真正的大結局。甚至每個人看到的，都不是同一個故事。我覺得 AI Video 下一階段真正有意思的方向，可能不是「把現在的影片做得更便宜」，而是開始出現以前根本不存在的內容形式。從生成影片，到生成節目，最後可能是：即時生成一個你正在觀看的世界。常見問答 (FAQ)Q1：什麼叫做 AI 影片的生成速度超過播放速度？如果一段 15 秒影片可以在 9 秒內生成，代表觀眾播放前一段影片時，AI 有機會提前準備好下一段。當生成時間持續小於播放時間，內容就能透過分段接續，理論上不斷延伸。 Q2：Infinite Video 和 Nothing, Forever 有什麼不同？Nothing, Forever 主要使用預先準備的角色、場景與 3D 資產，再由 AI 生成對白並即時排列；Infinite Video 則進一步讓人物、場景、動作與鏡頭都能即時生成，因此無限延伸的不只是劇本，也包含畫面世界。 Q3：為什麼即時生成影片不一定會先變成兩小時 AI 電影？因為即時生成允許內容依觀眾輸入、停留與互動持續改變，固定片長的電影不一定能發揮這種特性。AI 實境秀、互動連續劇、AI NPC 世界或個人化直播，可能更符合這種新媒體形式。 Q4：目前 Infinite Video 最大的限制是什麼？目前最大的限制之一是推論成本。即使影片生成速度已經快到能追上播放，若每秒成品影片的成本仍然很高，長時間直播就很難形成可持續的商業模式；模型能力、速度與成本必須同時改善。
2026/9/1
AI工具影音行銷

AI 讓做 MV 變簡單了，但我反而花更多時間

最近認真玩了一輪「AI 做音樂 MV」。從歌曲、拆歌詞、想故事、做分鏡、生圖、圖轉影片，一路做到最後剪接。做完之後，我最大的感覺不是：「AI 現在好厲害，連 MV 都會做了。」而是—— 現在真的不是「做不做得到」的問題，而是「你想花多少時間，把它做到多好」。而且我後來發現，這件事情其實不只適用 AI 影片，也正在改變我們使用 AI 做任何事情的方式。從一首歌到完整 MV，第一次完成已經不再是最大門檻以前如果我要自己做一支 MV，我不會攝影、不會動畫、不會特效，也沒有演員、場地或製作團隊。很多想法不是不好，是真的做不到。😂 但現在完全不一樣。不會寫歌，AI 可以幫你寫。不會做分鏡，AI 可以幫你拆。不會畫畫，AI 可以幫你生圖。不會拍影片，AI 可以幫你生成。甚至連分鏡、生圖、動畫、剪接都不想一個一個處理，現在也開始有工具可以直接從一首歌產生完整 MV。如果你想先理解 AI 影片創作中「看懂、判斷與指揮」的重要性，也可以延伸閱讀：學 AI 影片，你最不該做的，可能是先去學怎麼當導演。所以我覺得，AI 真正厲害的地方不只是：讓專業的人做得更快。而是：讓以前根本沒有生產能力的人，也拿到了入場券。以前「想到」跟「做到」中間，隔著大量的專業技能。 AI 正在把這個距離快速縮短。「做到」變簡單了，「做好」卻沒有這是我實際做完之後，覺得最有趣的地方。以前你的能力可能只能做到 30 分，做到 30 分，你就停了，因為第 31 分你根本不知道怎麼做。現在 AI 五分鐘可能就把你送到 70 分。然後麻煩來了。人物好像可以再一致一點？重跑。這個運鏡有點怪？重跑。副歌都進來了，畫面是不是應該再炸一點？再跑。這幕換成特寫好像更有感覺？再來一次。結果做到 80 分之後，你又突然看得到 90 分。所以我發現一個很有趣的現象： AI 降低的是「第一次完成」的成本，卻沒有同步降低「最後 10 分」的成本。甚至有時候反而讓你花更多時間。因為以前是：「做不到。」現在變成：「好像還可以再好一點。」😂 當生成變便宜，最昂貴的反而是選擇以前做一張圖很貴，所以不會隨便做 20 張。現在不好看，再生四張；還是不喜歡，再四張。影片也是，音樂也是，文案也是。 AI 解決了「沒有選擇」的問題，卻製造出另一個問題：選擇太多。所以當生成成本下降之後，我覺得另一種成本反而正在快速上升：決策成本。 AI 可以幫你產生 100 個答案，但它沒有自動解決一個更重要的問題：這 100 個裡面，哪一個值得留下？所以未來真正厲害的人，可能不一定是 Prompt 寫最長、AI 工具會最多的人。而是能從一堆「都還不錯」的東西裡，快速判斷：哪一個真的比較好。 AI 正在把我們從「製作者」變成「決策者」以前我們學的是：我會 Photoshop。我會 Premiere。我會攝影。我會動畫。我們的價值很大一部分來自：「我會做。」但當 AI 越來越會「做」之後，人的工作其實開始往上一層移。從：「這個怎麼做？」慢慢變成：「為什麼要這樣做？」這個鏡頭為什麼需要特寫？這段副歌為什麼應該換場景？這個角色為什麼不能笑？這支 MV 到底想讓觀眾感受到什麼？所以我一直不太認同「有了 AI，人人都是導演」。比較準確的說法應該是： AI 讓每個人突然擁有了一支以前養不起的製作團隊。但有了一百個很會做事的員工，不代表你突然變成一個很會做決策的老闆。這是兩件完全不同的事情。做 AI MV，其實是在配置時間、金錢與控制權我現在做 AI MV，反而不會先問：「哪個模型最強？」而是先問：「這支影片值得我花多少時間？」不同做法，其實是在交換三樣東西：時間、金錢、控制權。你更在意的事情可以採取的方式交換出去的資源想省錢使用免費額度，自己慢慢做時間想要更好的畫面花錢換更高階的影片模型金錢想要最高控制權自己拆分鏡、生圖、圖轉影片、剪接時間與操作複雜度想要快速完成直接把歌曲交給 AI MV 工具控制權它們沒有哪一種比較高級，其實只是在交換不同資源。真正重要的是：你知不知道這一次該把資源押在哪裡。先做爛，再做好：我現在的三輪工作法這是這次實測之後，我自己很想留下來的方法。第一輪：先問「有沒有？」先把完整的東西跑出來，不要先問漂不漂亮。歌曲有沒有對上？故事有沒有開始和結束？分鏡有沒有跑完？畫面有沒有剪成一支完整的 MV？第二輪：再問「對不對？」故事對不對？節奏對不對？情緒對不對？畫面方向對不對？這一輪是在確認：這支影片到底是不是你想做的那支影片。第三輪：最後問「好不好？」確認方向之後，才開始處理人物一致性、畫面品質、運鏡與細節。順序真的差很多。不然你很容易花兩個小時—— 把一個根本不該存在的鏡頭，做得非常漂亮。🤣 AI 時代，停止也是一種創作能力這可能是我這次最大的體悟。圖片可以無限重生。影片可以無限重跑。文案可以無限重寫。音樂可以無限改版。以前最大的問題是：「我做不到。」未來最大的問題可能變成：「我永遠覺得還可以再改一下。」當生成成本越來越低，「再試一次」的誘惑反而會越來越大。所以真正有效率的人，未必是生成最快的人，而是知道：什麼值得做到 95 分。什麼做到 80 分就該交出去。什麼做到 60 分，其實已經完成它的任務。這不是降低標準，而是先判斷這個成果要完成什麼任務，再決定品質要到哪裡。我現在給自己的 AI 創作原則很簡單：先用 AI 買速度，再決定哪裡值得買品質。先快速看到結果，再決定值不值得繼續投入時間。因為 AI 真正替我們省下來的，不應該只是「做事的時間」，而是讓我們可以把時間重新分配到：判斷、故事、品味、策略，以及真正重要的細節。所以這次做 AI 音樂 MV，我最後學到最有價值的，反而不是怎麼做 MV，而是三個問題：什麼值得做？值得做到什麼程度？什麼時候該停？當「做得到」越來越便宜，「知道什麼值得做」反而會越來越貴。這可能才是接下來真正值得學的 AI 能力。常見問答 (FAQ)Q1：AI 音樂 MV 通常會經過哪些製作流程？一支 AI 音樂 MV 可以從歌曲開始，依序進行歌詞拆解、故事構思、分鏡設計、生圖、圖轉影片與最後剪接；也可以把歌曲交給整合型 AI MV 工具快速產出初版。 Q2：AI 做 MV 最能降低的是哪一種成本？AI 最明顯降低的是「第一次完成」的成本，讓沒有攝影、動畫或特效專業的人也能快速做出完整版本；但最後的品質修整與取捨不一定因此變快。 Q3：做 AI MV 時，應該怎麼選擇工具或模型？先依影片值得投入的程度配置時間、金錢與控制權：想省錢就用免費額度慢慢做，想要更好的畫面就提高預算，想保有最高控制權就自行拆分鏡、生圖、圖轉影片與剪接。 Q4：為什麼建議用「先做爛，再做好」的方法？因為先完成完整初版，才能先檢查故事、節奏、情緒與畫面方向是否正確；方向確認後再投入人物一致性、運鏡和細節，能避免把大量時間花在不該存在的鏡頭上。 Q5：AI 創作時，怎麼判斷什麼時候該停止修改？先看成果要完成的任務，再設定品質門檻：重要作品可以做到更高品質，一般測試或需要快速交付的內容做到足以完成任務即可，不必因為還能再生成一次就無限重跑。
2026/8/30
AI自動化 AI工具影音行銷

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

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

20 萬 Stars 的 DeepSeek Harness：Vibe Coding 下一場戰爭可能換戰場了

過去一年玩 Vibe Coding，大家最常討論的問題幾乎都是：GPT、Claude、Gemini、DeepSeek，到底誰寫程式最強？哪個模型 Benchmark 比較高？哪個模型 Context 比較大？哪個模型比較不容易把專案改爛？但最近我越來越覺得，Vibe Coding 的下一場戰爭，可能已經不只是 Model，而是誰能替模型造出一套更強的「Agent 身體」。最近 DeepSeek 開源了一個非常值得研究的專案：DeepSeek Harness（DSH）。GitHub 已經突破 20 萬 Stars，更有意思的是，它現在甚至還只是 Developer Preview。官方給了一個我很認同的公式： Agent = Model + Harness 模型是大腦；Harness 則是身體。本文沿用初稿提供的「20 萬 Stars」與 Developer Preview 觀察。GitHub Stars、功能與架構都可能快速變動，實際使用時仍應以 DeepSeek Harness 官方 Repo 的最新內容為準。過去我們在比 Model，接下來可能開始比 Harness模型很重要，但模型能力不等於 Agent 能力。 Model 決定的是：會不會推理。會不會寫程式。能不能理解需求。能不能在上下文中形成合理判斷。 Harness 決定的卻是另一組問題： Agent 可以看到什麼？可以使用哪些 Tools？要怎麼操作電腦與開發環境？ Context 要怎麼管理？ Skills 要怎麼呼叫？複雜任務要怎麼拆解？要不要叫其他 Subagent 幫忙？ Session 要怎麼保存？出錯後能不能知道剛剛到底發生什麼事？所以同一顆模型，放進不同 Harness，最後可能就是完全不同等級的 Coding Agent。這也是為什麼我現在開始覺得：模型能力只是 Agent 戰爭的一半，另一半是模型被放進什麼工作環境裡。模型很聰明，不代表 Agent 很會工作我們很容易把「模型能力」跟「Agent 能力」混在一起，但其實這是兩件事情。可以用一個工作團隊來理解：Model 像大腦，負責理解與推理；Harness 像工作環境與管理制度，負責提供工具、規則、流程、狀態與回饋；Skills 則像 SOP，告訴 Agent 某一類工作應該怎麼完成。元件可以怎麼理解主要作用 Model 大腦理解、推理與產生回應 Harness 身體、工作環境與管理制度提供 Context、Tools、流程、權限、狀態與錯誤處理 Skills SOP 與專業方法告訴 Agent 某一類工作應該如何完成 Tools 工具與外部連接讓 Agent 讀寫檔案、執行指令、呼叫 API 或操作服務 Subagents 可以被委派的專業成員分擔任務、平行處理並回傳結果換句話說，Model 可能很會回答問題，但如果它看不到正確的檔案、沒有合適的工具、不能保留 Session，也沒有驗證與錯誤恢復機制，它就不一定能把工作完成。 DeepSeek Harness 最核心的概念：Everything is a PluginDSH 最吸引我的地方，是它把整個 Agent 拆開了。官方的核心設計就是： Everything is a Plugin. Model 是 Plugin。 Tools 是 Plugin。 Skills 是 Plugin。 Session 是 Plugin。 Sandbox 是 Plugin。 Storage 是 Plugin。 Agent Loop 是 Plugin。連 UI 都可以是 Plugin。也就是說，你不是只能接受官方幫你做好的 Coding Agent，而是可以開始像組積木一樣，自己組一個 Agent。這件事情的重要性在於：未來 Coding Agent 的競爭，可能會慢慢從「哪一個 AI 比較聰明？」變成「你怎麼組織這些 AI 工作？」當 Model、Context、Tools、Skills、Runtime、Session 與 UI 都能被拆開、替換與組合，Agent 就不再只是某家模型公司的單一產品，而會更接近一個可設計的工作平台。 1. Dynamic Workflow：Agent 開始自己組專案團隊假設今天要 Review 一個大型專案。以前可能是一個 Agent 從頭做到尾：讀程式碼、看架構、找漏洞、看測試，最後寫報告。 DSH 可以換一種玩法。主 Agent 可以動態寫 JavaScript Workflow，再建立多個 Subagents，讓它們平行執行： Architecture Agent：專門看整體架構與模組邊界。 Security Agent：專門尋找資安風險與可能的漏洞。 Testing Agent：專門檢查測試覆蓋與失敗案例。 Code Quality Agent：專門檢查程式碼品質與可維護性。 Security Agent 負責找漏洞，Testing Agent 負責檢查測試，Architecture Agent 負責看全局架構，Code Quality Agent 則負責程式碼品質。最後，主 Agent 再把每個 Agent 的 Structured Output 收回來統整。注意這件事情的差異：以前是：Agent 自己工作。現在開始變成：Agent 寫程式管理其他 Agent 工作。它已經開始有點像 AI Tech Lead：不只自己解題，也會判斷要找誰、怎麼分工、哪些工作可以平行，以及最後如何合併結果。 2. Agent Teams：不是 Subagent，而是真的 AI TeamDynamic Workflow 比較像「這個任務臨時找四個 AI 過來幫忙」。但 DSH 還往前走了一步：Agent Teams。它可以建立一個持續存在的 AI Team，裡面有： Lead：負責理解目標、分派任務與統整結果。 Teammates：各自負責不同領域的工作。 Mailbox：讓 Agent 之間可以互相傳遞訊息。 Shared Task DAG：管理任務依賴與執行順序。 Agent 之間甚至可以互相傳訊息。Task DAG 則負責管理任務之間的依賴：誰先做？誰可以平行？誰必須等另一個 Agent 完成？這時候你操作的東西，其實已經不像 Chatbot 了，而比較像一間 AI 軟體公司的組織架構。它把「一次請模型幫忙」改成「設計一組能持續協作的工作角色」。對大型專案而言，這可能比單純增加一次對話的 Context 更接近真實工程團隊的工作方式。 3. Trajectory：Agent 終於不再是一個黑箱這是我在 DSH 裡面非常喜歡的一個設計。現在很多 Coding Agent 有一個很大的問題：你丟一個任務給它，它跑了十幾分鐘，改了二十個檔案，用了幾萬 Token，最後只告訴你：「Done。」但你真正想知道的是：它剛才到底做了什麼？ DSH 會把整個 Agent 執行過程記錄下來，包含： System Prompt Reasoning Tool Call / Result Context Subagent Token 執行時間 Session 甚至可以 Restore、Fork、Retrieve、Replay。所以當 Agent 出問題，你可以往回追：它在哪一步開始判斷錯誤？哪個 Tool 出錯？哪個 Subagent 做錯？ Context 從哪裡開始污染？我覺得可以把這東西理解成：Chrome DevTools for AI Agent。未來 Agent 如果真的要進企業 Production，Observability 幾乎一定會變成標配。企業不只需要知道最後有沒有產出，也需要知道產出是怎麼來的、哪一個環節可以重現，以及出錯後能不能快速定位。 4. Creator Mode：Agent 開始替自己組裝能力DSH 還有一個很有意思的 Creator Mode。 Agent 可以檢查自己現在有哪些能力，發現缺少什麼，就 Mount Plugin；接著測試 Plugin，最後甚至可以建立自己的 Agent Preset。這件事情真正有意思的地方是：以前：工程師替 Agent 寫功能。接下來可能變成：人描述需要什麼能力，Agent 開始替自己組裝能力。如果這條路繼續走下去，未來我們甚至可能不再「建立 Agent」，而是讓 Agent 自己建立 Agent。這也會讓「Agent 設計」從一次性的程式開發，逐漸變成一種能力配置與治理問題：哪些 Plugin 可以掛載？如何測試？權限如何限制？產生的新 Agent 是否需要經過人工審核？ 5. 更有趣的是，它甚至可以找 Codex、Claude Code 當外援這點我覺得非常有想像空間。依照初稿所整理的 DSH 官方架構，它已經提供 Codex Subagent 與 Claude Code Subagent 的整合方向。未來完全可以出現這種工作流： DeepSeek 當 Lead Agent。某個功能先交給 Codex 實作。架構完成之後，再請 Claude Code Review。測試交給另外一個 Agent 執行。最後由 DeepSeek 把所有結果收回來統整。這時候我們一直爭「Claude 跟 GPT 到底誰比較強？」可能突然變得沒那麼重要。真正重要的問題反而是：誰最會指揮它們？要注意的是，這裡談的是 DSH 的架構與 Subagent 工作流方向，不代表每個版本、每種部署方式都已經提供相同的整合程度。由於 DSH 仍在 Developer Preview，實際支援的 Agent、設定方式與限制，應以官方 Repo 的最新文件為準。這才是 DeepSeek Harness 真正值得看的地方如果只把 DSH 看成「DeepSeek 也做了一個 Claude Code」，我覺得反而低估它了。它真正有意思的地方，是把 Agent 最重要的那一層直接攤開： Model × Context × Tools × Skills × Runtime × Subagents × Session / Memory × Observability Model 只是其中一層。真正讓這些東西開始一起工作的，才是 Harness。這個觀點也提醒我們：一個 Agent 的能力，不應該只用模型排行榜衡量。它是否能讀取正確脈絡、是否有安全的工具權限、是否會使用適合的 Skill、是否能平行分工、是否能追蹤與恢復，才是它能不能穩定工作的關鍵。 Vibe Coding 上半場比 Model，下半場開始比 Harness過去一年，我們一直追新的模型：Claude 更新，測一次；GPT 更新，再測一次；Gemini 更新，又測一次；DeepSeek 出新模型，繼續測。但當模型之間的能力逐漸逼近，我覺得下一個真正值得研究的問題已經開始浮現：如何把模型組織成真正會工作的 Agent？模型是大腦。 Harness 才是讓這顆大腦擁有眼睛、手、工具、記憶、工作流程，以及團隊協作能力的身體。所以接下來玩 Vibe Coding，我覺得除了研究「哪個 Model 最強？」，還要開始研究另一個問題：這個 Agent，到底是怎麼被 Harness 起來的？ DeepSeek Harness 現在還只是 Developer Preview，功能與架構一定還會快速變化。但 GitHub Stars 快速累積，本身就透露了一件很有意思的事情：開發者開始把注意力，從 Model 往 Agent Runtime 移動了。 Vibe Coding 上半場在比 Model。下半場，可能開始比 Harness。而再下一場戰爭，也許是：誰能打造出最會管理一整群 AI 的 Agent Runtime。結語：真正的競爭可能是 AI 的組織能力DeepSeek Harness 值得看的，不只是它能不能成為另一個 Coding Agent，而是它把「Agent 如何被組裝、協作、追蹤與恢復」這件事攤在開發者面前。當所有東西都能變成 Plugin，Model 就不再是唯一的主角。未來的開發者可能需要同時具備三種能力：選擇合適的模型、設計可靠的 Harness，以及把一群 Agent 組織成可驗收的工作流程。如果你身邊有人正在玩 Claude Code、Codex、Vibe Coding 或 Multi-Agent，這篇文章可以分享給他。因為下一波 AI Coding 的競爭，可能真的要換戰場了。 DeepSeek Harness 官方 Repo：github.com/deepseek-ai/deepseek-harness 延伸閱讀 Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI 的差異與應用場景何時該用 LLM？何時該派 AI Agent 上場？常見問答 (FAQ)Q1：DeepSeek Harness 是什麼？DeepSeek Harness（DSH）是一套用來組裝與運行 AI Agent 的 Harness。它把 Model、Tools、Skills、Session、Sandbox、Storage、Agent Loop 與 UI 等能力拆成可組合的 Plugin，讓開發者能設計不同的 Agent 工作環境。 Q2：Model 與 Harness 的差別是什麼？Model 負責理解、推理與產生回應，像是 Agent 的大腦；Harness 負責提供 Context、Tools、流程、權限、Session、錯誤處理與協作機制，像是讓大腦真正能工作的身體與工作環境。 Q3：Dynamic Workflow 與 Agent Teams 有什麼不同？Dynamic Workflow 是主 Agent 針對單次任務動態建立多個 Subagents 並平行執行；Agent Teams 則是由 Lead、Teammates、Mailbox 與 Shared Task DAG 組成的持續性團隊，能管理訊息傳遞與任務依賴。 Q4：Trajectory 為什麼對 Coding Agent 重要？Trajectory 會記錄 Agent 的 Prompt、Reasoning、Tool Call、Context、Subagent、Token、執行時間與 Session，並支援 Restore、Fork、Retrieve、Replay。這讓開發者能追蹤 Agent 從哪一步開始出錯，而不必只依賴最後一句「Done」。 Q5：DeepSeek Harness 現在適合直接用於企業 Production 嗎？本文整理的 DSH 仍是 Developer Preview，功能、介面、整合方式與限制都可能快速變化。若要導入企業 Production，應先依官方 Repo 的最新文件確認部署方式、權限、Plugin、Subagent 與 Observability 能力，再進行小範圍測試與人工驗收。
2026/8/26
商業策略 AI工具 Vibe Coding

官網被駭後，我乾脆用 AI 一週重做一個品牌｜鮮生小姐官網重建實錄

這一週，我幾乎把工作重心都放在一件事情上：重新打造「鮮生小姐」的品牌官網。起因其實很直接。原本鮮生小姐的官網是用 WordPress 做的，前陣子碰到大漏洞，八月初直接被駭客弄掛。既然都已經要大修，我乾脆做了一個決定：不要修舊網站了，直接用 AI 重新做一個。而且這次不是單純把網站「做回來」，而是趁這個機會，把品牌、購物流程、商品圖片、內容行銷，甚至品牌角色都重新想一次。先從品牌開始：打造 AI 代言人 Cherry第一個最大的改變，就是導入新的 AI 代言人：Cherry。為什麼是 Cherry？因為鮮生小姐做進口水果，最具代表性的商品之一就是櫻桃。所以我跟 AI 討論了很久，希望她不是一個制式的「AI 美女」，而是真的有品牌個性。最後慢慢找到一個我很喜歡的方向：怪美的，甜一點、酸一點，都好。我希望 Cherry 有一點甜、有一點酸、有一點怪，但又讓人印象深刻。接下來，她就不只是網站上的一張人物圖。她可以介紹商品、推薦水果、帶大家認識品牌，也可以出現在未來的社群內容裡。做到後來，我甚至還直接用 Suno 幫 Cherry 做了一首歌和品牌 MV。以前我們是在做一個網站；現在更像是在慢慢打造一個品牌角色，甚至是一個品牌世界。重新設計購物流程：網站負責展示，LINE 負責成交第二個改變，是我把傳統電商購物流程重新想了一遍。這次的新官網，目前沒有再串第三方金流，而是把流程改成：官網介紹商品與產生興趣 → LINE 詢問、溝通與客製 → 銀行轉帳完成交易。這算是我這次一個滿大的實驗。以前做電商，很自然會想到：商品頁 → 購物車 → 結帳 → 金流 → 訂單成立但水果，尤其是水果禮盒、企業送禮，本來就不是每一筆交易都這麼標準。客人很常會問：這個今天有貨嗎？水果可以換嗎？我要送 10 盒，要怎麼搭配？某一天以前送得到嗎？企業大量訂購，有沒有其他方案？這些事情，本來就非常適合透過 LINE 溝通。所以與其強迫每個客人都走標準購物車流程，我反而把網站跟 LINE 高度綁定：網站負責把商品說清楚，LINE 負責把交易完成。對小型品牌來說，我覺得這可能是一個很值得測試的新方向。它不一定適合所有商品，但對規格、庫存、數量與配送條件都可能需要討論的水果生意來說，彈性會比制式結帳流程更高。 AI 不是幫我找圖，而是直接幫網站生圖第三個讓我很驚喜的地方，是網站圖片。以前做網站有一件很花時間的事情：找圖。尤其水果更麻煩。你可能找到一張很漂亮的蘋果、一張很漂亮的葡萄、一張很漂亮的哈密瓜，但放在同一個網站裡，常常會發現光線、背景、構圖和攝影風格都不一樣，整個網站看起來就像從不同地方拼起來的。這次我直接讓 AI 延續鮮生小姐原本的商品攝影風格，再按照網站實際需要去生成圖片。我可以直接告訴 AI：我要什麼比例。主體要放在哪裡。哪邊需要留白。這張圖適合首頁還是商品頁。整體光線、背景與質感要保持一致。以前的流程是：找圖片 → 配合圖片設計網站。現在變成：先設計網站 → 再生成最適合網站的圖片。整個設計流程其實已經倒過來了。圖片不再只是網站完成後才補上的素材，而是可以跟頁面結構一起被規劃的品牌資產。用 Codex 協同作業，一週把整個架構做起來這次整個網站，我主要是用 Codex 協同作業。從網站架構、頁面設計、商品資料、LINE 導購流程，到部署、修改和調整，很多事情都是直接跟 AI 邊討論邊做。我覺得最大的差別，不只是 AI 幫我寫程式碼，而是以前很多事情光想到就會覺得專案很大：網站架構要改。商品流程要改。圖片要重做。 SEO 要處理。手機版要調整。部署還要弄。然後就會想：「這專案好像有點大，改天再做。」但現在可以直接把問題拆開，一個一個跟 AI 做。所以短短一週，就已經可以做到現在這個程度。這裡的重點不是「AI 一週就能把任何品牌網站做完」，而是當架構、內容、圖片與部署都可以在同一個協作流程裡快速往返，一個人也更有機會把原本不敢啟動的專案先做出第一版。網站不是做完，而是終於可以開始快速迭代當然，目前還有很多地方需要持續修改。商品會繼續增加，Cherry 的角色設定還會繼續發展，SEO 文章也會慢慢補上，網站細節一定還會再調整。但現在有一個很大的差別：底層已經建立起來了。接下來要上架新商品，可以很快；要新增 SEO 文章，可以很快；要做季節水果活動頁，也可以很快。甚至未來要讓 Cherry 出現在更多內容裡，也已經有完整的方向可以延伸。所以我現在看這個網站，它其實已經不只是一個官網，更像是：品牌內容平台商品展示平台 SEO 平台 LINE 導客入口 AI 真正改變的，是「我敢做多少事情」這次最大的感觸是：AI 真正改變的，不只是「做事情變快」。而是讓原本一個人覺得太大的事情，開始變成可以直接動手做的事情。以前可能會想：「這個專案要找很多人、花很多時間，之後再說。」現在則變成：好，那這週就來試試看。對一人公司、小型品牌、內容工作者來說，我覺得這才是 AI 真正厲害的地方。它不是取代你做決定，而是讓你的想法可以更快變成真的東西。鮮生小姐新版官網鮮生小姐新版官網目前正逐步上線中，歡迎看看這次用 AI 重做的品牌網站：前往鮮生小姐新版官網常見問答 (FAQ)Q1：為什麼不直接修復原本的 WordPress 官網？因為原網站在八月初遭遇漏洞並被駭客弄掛，既然已經需要大幅修復，就把這次機會用來重新思考品牌、購物流程、商品圖片與內容架構，直接用 AI 建立新版本。 Q2：為什麼讓官網展示商品、再用 LINE 完成交易？水果禮盒與企業送禮常涉及庫存、換果、搭配數量、配送日期與大量訂購方案，這些需求不一定適合標準購物車，因此讓官網負責說明商品，再透過 LINE 溝通與成交。 Q3：這次 AI 協助了哪些網站工作？AI 協助討論網站架構、頁面設計、商品資料、LINE 導購流程、商品圖片與部署調整，也支援 Cherry 品牌角色與後續內容方向的發展。 Q4：這個網站現在已經全部完成了嗎？還沒有。商品、Cherry 的角色設定、SEO 文章與網站細節都會持續更新；目前最重要的是底層架構已經建立，後續可以更快新增商品、文章與季節活動頁。
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 正式文件
2026/8/23
AI工具 Vibe Coding API串接

public-apis：超過 40 萬顆星的 API 寶庫，Vibe Coding 很值得收藏

以前做 Side Project，最常卡住的地方不一定是寫程式。而是：「這個資料我要去哪裡拿？」想做天氣功能，要找天氣 API。想做匯率工具，要找匯率 API。想做電影網站，要找電影資料。甚至只是想做個隨機笑話、貓咪圖片、QR Code 或 IP 查詢的小功能，都得先花時間搜尋：到底有沒有現成 API 可以用？這時候，public-apis 就很值得收藏。 public-apis 是什麼？public-apis 不是一個 API，而是一個整理大量 Public API 的 GitHub 專案。目前已累積超過 40 萬顆 Star，可以把它想成：開發者的 API 黃頁。你可以直接到 public-apis GitHub 專案依照需求尋找資料來源，不必每次都從搜尋引擎開始，重新猜測關鍵字、比較文章，或在十幾個分頁之間來回切換。裡面有哪些 API？專案整理了超過 50 個分類，涵蓋很多 Side Project 常見的資料來源，例如：天氣金融與匯率新聞電影音樂遊戲地圖交通機器學習圖片動物政府開放資料資安購物區塊鏈有些資料類型可能是你平常不會特別搜尋的，但當你開始做一個小工具、展示型網站或資料視覺化專案時，就可能突然派上用場。每個 API 通常也會標示幾個重要資訊：是否需要 API Key 是否使用 OAuth 是否支援 HTTPS API 的功能說明官方網站或文件連結這些欄位可以幫助你先做第一輪篩選，再回到官方文件確認實際用法。免費整理清單，不代表每個 API 都免費這是使用 public-apis 時最需要注意的地方。 GitHub 專案本身可以免費瀏覽、fork，也能拿來尋找 API，但不代表清單裡每一個 API 都完全免費。實際情況可能包括：需要先註冊 API Key 提供有限的免費額度超過額度後需要付費免費方案限制請求次數或功能服務方案可能隨時間調整所以，只要要把 API 放進正式產品，就不能只看清單上的標示。最後仍然要回到 API 官方網站，確認以下資訊：價格與免費額度 Rate Limit 與每日或每月請求上限 API Key、OAuth 或其他驗證方式商業使用、資料再散布與授權條款服務穩定性、文件完整度與維護狀態 public-apis 適合用來縮短「找資料來源」的時間，不應該取代正式的技術與商業審查。為什麼 Vibe Coding 時代更適合使用它？以前看到這種清單，我們通常會這樣使用：打開 README 使用 Ctrl + F 搜尋 Weather、Currency 或其他關鍵字一個一個點進去看自己整理文件、限制與串接方式現在有了 Codex、Claude Code、Cursor 這類 Coding Agent 之後，使用方式可以更進一步。你可以直接描述想做的產品與選型條件，例如： 1234我要做一個旅遊網站，需要天氣、匯率與國家資訊 API。請從 public-apis 裡面找幾個適合的方案，優先考慮免信用卡、有免費額度、支援 HTTPS、文件完整，而且適合 Side Project 使用的 API。請整理成比較表，列出驗證方式、Rate Limit、免費方案限制、官方文件與風險。接下來可以讓 AI 協助完成幾個步驟：從清單中找出符合需求的候選 API 讀取官方文件並整理必要參數比較 API Key、OAuth 與匿名使用的差異檢查免費額度、Rate Limit 與資料授權產生串接範例與環境變數設定把選定的 API 接進目前的專案用測試資料驗證錯誤處理與異常情境這也是我覺得 public-apis 在 Vibe Coding 時代真正有意思的地方：它不只是「我不知道去哪裡找 API」，而是逐漸變成 Coding Agent 的外部工具箱。讓 AI 幫忙找 API 時，還是要保留人的判斷Coding Agent 可以加快搜尋、閱讀文件與產生程式碼，但不能把所有選型責任交出去。尤其是以下幾件事，最好由人最後確認：檢查項目為什麼重要？資料來源確認資料是否可靠、合法且符合產品需求使用條款確認能否商用、儲存或再散布資料方案限制避免測試時免費，上線後卻突然產生費用 Rate Limit 預估流量增加時是否會被限流 API 穩定性確認文件、版本與服務是否有持續維護金鑰安全不把 API Key 直接寫進前端或提交到 Git 特別是 API Key 安全。AI 產生串接程式碼時，必須提醒它使用環境變數，並確認金鑰只在後端或受控的 Serverless 函式中使用。這樣才能避免一個看似簡單的 Side Project，最後變成意外洩漏金鑰或產生額外帳單的事故。如果想延伸閱讀如何用 AI 開始寫程式，可以參考從零開始用 AI 寫程式的 Vibe Coding 指南；如果想研究如何站在成熟開源專案上組裝產品，也可以看看AI 時代不用從零開始！20 個必看的 GitHub 開源 AI Business OS 專案。另外，針對 AI API 的選型，也可以延伸閱讀免費 AI API 怎麼選？Gemini、Ollama、OpenRouter 實測比較。結語：把時間留給產品，而不是重複找資料以前收藏 public-apis，是因為怕以後找不到 API。現在收藏它，是因為它可以直接變成 Coding Agent 的外部工具箱。下次做 Side Project，不知道資料從哪裡來時，可以先叫 AI 到這裡翻翻看，再一起回到官方文件做驗證。很多原本以為要自己開發的功能，可能只需要幾分鐘就能找到合適的起點。但真正的完成標準，不是 AI 找到一個看起來能用的 API，而是你確認它的資料、限制、授權與成本都適合目前的產品。常見問答 (FAQ)Q1：public-apis 本身是一個可以直接呼叫的 API 嗎？不是。public-apis 是整理大量公開 API 的 GitHub 專案，使用者仍然要從清單中選擇 API，並依照各服務的官方文件完成註冊、驗證與串接。 Q2：public-apis 裡面的 API 都可以免費使用嗎？不一定。清單本身可以免費瀏覽與使用，但其中的 API 可能需要 API Key、提供有限免費額度，或在超過 Rate Limit 後收費。正式使用前要回到官方網站確認價格與條款。 Q3：Coding Agent 可以直接幫我選好並串接 API 嗎？Coding Agent 可以協助搜尋候選 API、讀取文件、整理比較表與產生串接程式碼，但仍需要人確認資料品質、使用授權、免費方案、Rate Limit 與金鑰安全，再決定是否放入正式產品。 Q4：用 API 做正式產品前，最少要檢查哪些事情？至少要檢查 API 的官方文件、驗證方式、Rate Limit、價格與免費額度、商業使用條款、資料授權、錯誤回應，以及服務是否有持續維護。 Q5：API Key 應該放在哪裡？API Key 不應直接寫在前端程式碼或提交到 Git。一般應使用環境變數，並讓後端或受控的 Serverless 函式代為呼叫 API；同時要設定必要的權限、額度與監控。最後附上專案連結：public-apis GitHub repository。
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
2026/8/22
AI工具 AI Agent Vibe Coding

Google Antigravity 2.0 繁體中文介面套件：降低 AI Coding 入門門檻

如果你最近開始接觸 Google Antigravity 2.0，第一個卡關的地方可能不是 AI，也不是程式碼，而是整個操作介面都是英文。對熟悉開發工具的人來說，Workspace、Agent、MCP、Knowledge、權限與設定等名詞看久了就習慣了。但對剛開始學習 AI Coding 的人來說，光是找到功能、理解狀態與確認設定，就可能先花掉不少時間。最近有一套社群開源的 Antigravity 2.0 繁體中文介面套件受到注意。它不是只翻譯幾個選單，而是針對 Agent 型開發工具的主要操作介面，整理了一套較完整的台灣繁體中文化方案。本文依照專案目前公開說明整理。這不是 Google 官方中文化工具，實際支援範圍、安裝方式與相容性，請以專案 GitHub repository 的最新內容為準。為什麼 AI Coding 工具需要繁體中文介面？AI Coding 的學習門檻，常常不只在「怎麼叫 AI 寫程式」。使用者還要理解工具的工作區、Agent 狀態、權限提示、外部工具連線與專案設定。當每一個介面文字都要先翻譯成中文，學習者就會同時面對兩個問題：一邊理解 Agent 的工作方式，一邊猜測英文按鈕的功能。這會讓原本應該集中在需求描述與開發流程的注意力，被介面辨識分散掉。繁體中文介面的價值，不是把所有英文都消滅，而是讓初學者先看懂「這個區域負責什麼」，降低第一次使用時的認知負擔。等熟悉工具之後，再切回英文或閱讀官方文件，也會比較容易建立對照關係。這套 Antigravity 中文介面涵蓋哪些內容？依照專案目前整理的內容，翻譯範圍不只停留在首頁或幾個按鈕，主要涵蓋以下區域：涵蓋區域主要用途主介面與側邊欄協助使用者理解主要導航與工作區入口設定頁讓常用設定、偏好與權限相關選項更容易辨識 Agent 與 Workspace 了解目前工作區、Agent 任務與操作狀態 MCP 與 Knowledge 認識外部工具、資源與知識庫相關設定系統選單與快捷鍵降低查找功能與學習操作方式的門檻 Agent 狀態顯示更快判斷 Agent 目前正在執行、等待或需要介入專案目前整理了 617 個翻譯詞彙。這代表它的目標不是做一個展示用的局部翻譯，而是把 Antigravity 的主要使用流程整理成較一致的繁體中文介面。哪些區域刻意保留英文？這套中文化方案有一個重要取捨：不是看到英文就翻譯，而是避開可能影響開發工作的區域。以下內容會刻意保留原文或避免介入：程式碼編輯器 Terminal Debug Console 輸入框自動完成選單這樣的設計很實用。程式碼、Shell 指令、錯誤訊息與自動完成內容通常需要直接對照文件、搜尋結果或其他開發環境。如果連這些內容也被翻譯，反而可能讓複製指令、搜尋錯誤與閱讀技術文件變得更困難。換句話說，它翻譯的是「工具怎麼被操作」，而不是「開發者正在輸入或執行的內容」。這也是開發工具中文化時很重要的界線。它是怎麼完成介面中文化的？從技術做法來看，這個專案是針對 Electron 應用程式的本機安裝檔進行處理，流程包含：解包 Electron 使用的 ASAR 檔案。注入整理好的繁體中文翻譯。重新打包應用程式。以本機腳本完成安裝或還原。這種方式的優點是可以直接改變本機應用程式的介面文字，不需要另外製作一個全新的 Antigravity 客戶端。專案說明也提到，操作在使用者自己的電腦上完成，不會散布 Google 官方的 app.asar，並且第一次安裝時會先備份原始檔案。不過，這也表示它不是一般瀏覽器擴充功能，而是會修改本機 Antigravity 的 app.asar。安裝前應先閱讀 repository 的說明，確認自己理解修改範圍與還原方式。安裝前要注意哪些事情？這不是 Google 官方中文化這是社群製作的開源專案，不代表 Google 官方立場，也不等同於 Antigravity 內建的語言選項。若你在工作環境中使用，建議先確認團隊對本機應用程式修改與第三方腳本的規範。官方更新可能覆蓋翻譯內容由於中文化內容寫入本機應用程式檔案，Antigravity 每次更新後，原本的修改可能會被官方版本覆蓋。屆時通常需要重新執行安裝腳本，並重新確認目前版本是否相容。保留備份與還原路徑專案提供還原腳本，並說明首次安裝會備份原始檔案。即使如此，使用前仍應確認備份確實存在，並知道如何在不需要中文化時恢復官方英文版本。先在非關鍵環境測試如果 Antigravity 裡有重要的專案或尚未同步的工作，建議先完成檔案與設定備份，再在非關鍵環境測試。遇到更新失敗、介面異常或擴充功能不相容時，才有比較安全的退路。依照專案目前說明，這套方案支援 Windows 與 macOS；但作業系統版本、Antigravity 版本與安裝位置都可能影響腳本結果，仍應以 GitHub repository 的最新文件為準。適合哪些人使用？如果你本來就習慣英文開發工具，而且能快速閱讀 Antigravity 的官方文件，安裝中文化套件不一定會帶來明顯好處。英文介面也有利於直接對照國外教學、錯誤訊息與社群討論。但以下使用情境可能很適合採用：正在學習 AI Coding，還不熟悉 Agent、Workspace 與 MCP 的人。想把 Antigravity 示範給不熟英文介面的學員或同事。需要先理解功能分區，再逐步建立英文技術詞彙對照的人。希望降低第一次使用 Agent 型開發工具的心理門檻的人。中文化的真正價值，是讓使用者更快進入「描述需求、觀察 Agent、檢查結果」的工作循環，而不是取代英文文件或開發者原本的技術習慣。結語：AI Coding 普及，也需要降低工具門檻模型變強，確實會讓 AI Coding 的能力越來越高；但如果使用者連工具介面都看不懂，能力就很難真正轉化成日常工作效率。這套 Antigravity 繁體中文介面方案的意義，就在於把一部分不必要的語言障礙先拿掉，同時保留程式碼、Terminal 與 Debug Console 等開發者真正需要維持原文的區域。它不是每個人都必須安裝的工具，也不是 Google 官方支援的語言包。但對正在學習 Agent 型開發、或想把 AI Coding 推廣給更多一般工作者的人來說，確實是一個值得認識的社群嘗試。如果你想了解完整安裝、備份與還原方式，可以前往Antigravity 2.0 繁體中文套件 GitHub 閱讀最新說明。若你也在研究 Agent、MCP 與 Skill 的分工，可以延伸閱讀AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI 的差異與應用場景；想理解 Agent 如何在真實專案裡持續工作，則可以參考Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness。常見問答 (FAQ)Q1：Antigravity 2.0 繁體中文介面套件是 Google 官方推出的嗎？不是。這是社群製作的開源中文化專案，不是 Google 官方內建的語言包；安裝與使用前應以 GitHub repository 的最新說明為準。 Q2：這套中文化會翻譯程式碼、Terminal 或 Debug Console 嗎？不會。專案設計上會避開程式碼編輯器、Terminal、Debug Console、輸入框與自動完成選單，主要翻譯 Antigravity 的操作介面與狀態資訊。 Q3：安裝中文化套件會修改本機檔案嗎？會。它透過 Electron ASAR 解包、注入翻譯並重新打包的方式修改本機 Antigravity 的 app.asar。專案說明指出首次安裝會備份原始檔案，也提供還原腳本，但使用者仍應先閱讀說明並確認備份與還原方式。 Q4：Antigravity 更新後，中文介面還會保留嗎？不一定。官方更新可能覆蓋被修改的本機檔案，因此中文化內容可能需要重新安裝；重新執行前也應確認新版 Antigravity 與套件是否相容。 Q5：Windows 與 macOS 都能使用嗎？依照專案目前公開說明，方案支援 Windows 與 macOS。不過實際結果仍可能受到作業系統版本、Antigravity 版本與安裝位置影響，請以 repository 最新文件為準。