跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

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

分類

標籤

商業策略 (29) AI自動化 (77) AI工具 (51) AI Agent (33) SEO (13) AEO (8) 內容行銷 (25) Cursor (2) Vibe Coding (37) 影音行銷 (30) Gemini (11) Meta Ads (1) Codex (7) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) ChatGPT (14) AI繪圖 (8) n8n (28) API串接 (13) 社群行銷 (4) 自動化講師應用 (5) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Cloudflare (5) 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) 個人品牌 (1) Power Automate (1) 職場溝通 (2) LINE (1)
  • article-AI 影片真正的分水嶺：從 Prompt 到專家 Skill 的製片工作流

    2026/9/14

    AI工具 AI Agent 影音行銷
    AI 影片真正的分水嶺：從 Prompt 到專家 Skill 的製片工作流

    AI 影視最近兩個案例，指向同一件事AI 影片最近有兩件事，我覺得值得放在一起看。 第一件，是 Higgsfield 公開了 95 分鐘 AI 長片《HELL GRIND》的製作專案，讓外界能查看影片背後的提示詞與製作素材。Higgsfield 官方專案頁 第二件，是我看到一位漫劇創作者在抖音談劇本創作與進階 Skill；他也公開了一套把編劇、角色與場景資產、分鏡、提示詞和品質檢查串起來的工作流程。抖音影片｜公開的漫劇製作 Skill 乍看之下，這是兩種不同的 AI 影片案例。但放在一起，我看到的是同一個轉變：AI 影視真正的分水嶺，可能已不只是模型，而是「工作流」。 我把這種變化濃縮成一句有點殘酷的話：「學得慢的，直接不用學了。」不是專業不重要，而是有些人不必再從空白頁開始，把流程每一步都重新摸索一次；他們可以先安裝一套專家整理好的 Skill，再把時間用在判斷和修正上。 以前學 AI 影片，我們常常是在學怎麼抽卡人物不像？改 Prompt。場景跑掉？再補幾句。角色換個角度就變了樣？重抽。運鏡不對？繼續試。 所以過去一段時間，大家忙著學提示詞、運鏡術語和模型參數。但模型、介面與生成能力一直在變，今天摸熟的技巧，下一次更新後可能就被新的功能或工作方式取代。 反覆試生成並沒有消失，只是單靠「再改幾個字、再抽一次」很難穩定地做完一支片。更值得整理的，是故事如何拆解、角色和場景如何管理、鏡頭如何判斷，以及什麼結果可以留下。 專家的方法，開始被封裝成 Skill以小說改編成短劇為例，完整工作不只有「寫一段好 Prompt」。它可能包括故事分析、劇本結構、節奏與 Hook、角色設定、場景和道具資產、分鏡規劃、生成提示，以及逐步檢查成品。 這些步驟可以整理成一套 Skill：明確說明何時使用、要收哪些輸入、依什麼規則執行、要輸出什麼，以及在哪些地方停下來檢查。AI Agent 便能按照這套流程做事，而不是每次都靠使用者在聊天視窗重講一遍。 公開的漫劇 Skill 範例，就把製作拆成劇本、台詞診斷、資產鎖定、分鏡、提示詞渲染和獨立質檢等階段。這不是保證任何人安裝後都能做出熱門作品；它展示的是，原本藏在熟手腦中的步驟，開始能以結構化方法傳給 AI 執行。 一條可理解的製作管線大致會是： 1234567891011小說／故事 ↓編劇 Skill ↓角色與場景 Asset ↓Storyboard Skill ↓大量生成與品質檢查 ↓剪輯與輸出 這和我先前寫過的從提示詞到 Skill：打造高效率 AI 工作流有相同的底層觀念：把反覆重講的規則、固定格式、機械式步驟和修正經驗拆開，整理成可以重複使用的模組。 為什麼 Asset 會比一段角色 Prompt 更可靠？Higgsfield 公開《HELL GRIND》的專案素材，讓大家看到長片製作不只是每一鏡各寫一段描述。角色、場景、服裝、道具與不同狀態，都可以先整理成可重複引用的 Asset。 角色不是只有一張「長相描述」。製作時可能需要正常、淋濕、受傷或換裝等不同狀態；場景也不只是一段文字，還可能需要固定的空間關係、光線和可用角度。先把這些資料整理起來，之後做新鏡頭就不必每次從頭解釋整個世界。 這不代表模型從此不會漂移。Asset 的價值是提供更穩定的參照、減少重複整理，讓團隊更容易定位問題和重新生成；最後仍然需要有人檢查角色、場景和鏡頭是否接得起來。 《HELL GRIND》提醒我們：沒有告別抽卡，只是把抽卡工程化《HELL GRIND》的製作數字，讓我更確定這點。Screen Daily 報導引述製作方資料指出，前 25 分鐘用了 16,181 次影片生成，最後選出 253 個鏡頭，約是每個入選鏡頭對應數十次生成的量級。Screen Daily 報導 這是單一製作案例的數字，不是每部 AI 影片都適用的固定比例。但它清楚提醒我們：AI 影片不是按一次生成，就會自動得到可用成片。生成失敗並不可怕；更重要的是流程能不能記錄素材、比較版本、辨認問題，並只重跑需要修正的鏡頭。 於是製作方式從： 1人 → Prompt → 抽卡 → 不滿意 → 重抽 逐漸往這種工作流靠近： 1234567891011Story Bible ↓Character Bible 與場景 Asset ↓Storyboard 與 Shot 規格 ↓多輪生成 ↓人工／AI 輔助 QC ↓挑選、重跑與剪輯 抽卡仍然存在，只是它不再只是隨手試運氣，而是被納入一套可追蹤、可重跑、可檢查的製作管線。 未來稀缺的，可能是把專業整理成系統的人未來真正厲害的人，不一定是 Prompt 寫得最長的人，而是最會把專業拆成可執行步驟的人。 導演知道鏡頭怎麼服務情緒；編劇知道衝突和節奏如何推進；攝影師知道光線、構圖和視角如何影響觀感；剪輯師知道什麼時候該留下、什麼時候觀眾會離開。這些專業判斷，才是建立 Skill 時最有價值的內容。 一套可用的 Skill，也不只是把 Prompt 改個名字。它通常還需要清楚的輸入與輸出、可重用的素材、檢查標準、失敗時的處理方式，以及必要的人工作業關卡。少了這些，Agent 只會更快速地重複同一種錯誤。 如果想把 AI 影片流程往更完整的製作系統延伸，也可以參考我整理的用 Codex 打造 AI 影片工廠。而在生成能力普及、產量快速增加之後，為什麼「會生成影片」本身可能不再稀缺，也可延伸閱讀生成影片普及後，真正稀缺的是什麼。 學 AI，不如開始把自己會的東西教給 AIPrompt 的寫法會變，模型也會更新；但故事怎麼拆、角色怎麼管理、畫面怎麼判斷、什麼內容值得留下，仍然是專業的一部分。 所以現在學 AI，我不會只叫大家背更多提示詞。我更想問：哪些判斷你每天都在重複？哪些規則每次都要重新交代？哪些錯誤其實可以用檢查表提早抓到？ 把這些經驗整理起來，先讓 AI 照流程執行，再由你把關品質。以前我們學會使用 AI；下一個階段，或許是把自己會的事情整理成 Skill，教會 AI 如何一起完成工作。 當越來越多人的專業被封裝成 Skill，真正的競爭才正要開始。 常見問答 (FAQ)Q1：AI 影片製作中的 Skill 是什麼？Skill 是一套可由 AI Agent 依循的任務規則與流程，通常會定義使用時機、輸入資料、執行步驟、輸出格式和檢查標準。它能減少每次重講流程，但不保證生成結果一定正確或符合品質要求。 Q2：有了 Skill，就不用學 Prompt 或專業知識了嗎？不是。Skill 可以把重複的操作規則整理起來，但使用者仍要提供目標與背景，並運用故事、影像、節奏和品質判斷來驗收結果。減少的是每次從零描述流程，不是專業判斷本身。 Q3：為什麼角色與場景要先整理成 Asset？把角色、場景、服裝、道具和狀態整理成可重複引用的 Asset，有助於維持不同鏡頭的參照一致，也讓團隊更容易找出需要修正的素材。模型仍可能產生偏差，因此 Asset 不能取代逐鏡檢查。 Q4：《HELL GRIND》的生成次數代表每個 AI 鏡頭都要生成 64 次嗎？不代表。製作方提供給媒體的數字是《HELL GRIND》前 25 分鐘用了 16,181 次影片生成，選出 253 個鏡頭，約為 64 次生成對應一個入選鏡頭的整體比值；這是該片的製作案例，不是普遍標準。 Q5：要怎麼開始把自己的專業整理成 Skill？先挑一個反覆執行、容易出錯的工作，記錄必要輸入、每一步的判斷規則、預期輸出和驗收條件；再把可重用的角色／場景／素材與檢查表整理好，讓 AI 先依流程執行，並在關鍵步驟保留人工審核。

  • article-我把 ChatGPT 接上自己的開發台 MCP，AI Coding 開始變成一條「軟體開發流水線」

    2026/9/14

    AI Agent Codex ChatGPT
    我把 ChatGPT 接上自己的開發台 MCP，AI Coding 開始變成一條「軟體開發流水線」

    最近我開始把 ChatGPT 接進原本提供給 Codex、Claude 使用的開發台 MCP。最有意思的地方，不是讓 ChatGPT 跟 Codex 搶著寫程式，而是把需求討論、工作規劃、程式實作與 Review 拆成不同角色。 我可以先讓 ChatGPT 查看開發台允許提供的專案脈絡，協助分析問題、整理風險與驗收條件，再透過 MCP 建立 Ticket，交給 Codex 接手。完成後，再把差異與測試結果交回來 Review。 以這個工作方式來看，分析和由 ChatGPT 發起的 MCP 操作使用 ChatGPT 端的可用額度，Codex 的工程執行則在 Codex 的工作環境中進行。乍看之下，好像終於能把 ChatGPT 每月訂閱用得更完整了 😂。但額度和費用會依方案、整合方式與工具呼叫而變化，這不是接上 MCP 就一定省錢的保證。 真正值得注意的，是 AI Coding 開始從「一個 Agent 包辦所有事」，走向「一組 Agent 按照分工接力完成工作」。 ChatGPT 不一定要寫程式，也能參與開發使用 Codex 時，我們常把需求理解、讀取 Context、規劃、修改、測試、Review 和下一步討論，全塞在同一個 Agent 裡。專案越大，耗費的時間和額度往往不只來自寫程式，也包括理解專案、追蹤進度、檢查結果和重新安排工作。 如果有一套開發台 MCP 能提供必要的專案狀態、Session 摘要或 Ticket 操作，ChatGPT 就可以先負責需要大量溝通和判斷的工作：釐清需求、找出風險、拆出可執行的工作，再把任務交給 Codex。 以一次長時間的工作樹合併任務為例，當 Codex 已經執行很久，我不一定要繼續在同一個 Agent 裡討論下一步。我可以請 ChatGPT 根據開發台提供的狀態，檢查目前結果、列出可改善處與潛在風險，再整理成一張 Codex 能接手的票。 這樣一來，ChatGPT 的價值不在於「代替 Codex 寫另一份程式」，而在於把模糊的討論轉成清楚、有優先順序、可以驗收的工作。 把不同角色接成一條開發流程如果把工作拆開來看，分工可以是： ChatGPT：需求分析與 Review。 協助釐清問題、檢查現況、拆解任務、補充驗收條件，並Review Codex 回報的結果。 開發台 MCP：提供連接與操作能力。 依照開發台實際設計，讀取被允許的 Context、建立或更新 Ticket、傳遞執行結果與工作狀態。 Codex：工程實作與驗證。 根據 Ticket 修改程式、執行測試，並回報差異、失敗項目和未解風險。 人：決定優先順序與重要操作。 確認需求、核准高影響變更，決定是否 Commit、Merge 或關閉 Ticket。 整體流程就會像這樣： 12345678910111213人提出需求 ↓ChatGPT 取得允許使用的專案脈絡並分析 ↓MCP 建立 Ticket，記錄工作範圍與驗收條件 ↓Codex 實作並執行測試 ↓開發台回報差異、測試結果與阻礙 ↓ChatGPT Review，整理下一步 ↓人確認是否 Commit、Merge 或關票 這條流程不代表每個 MCP 都有 Session、Ticket 或 Git 管理功能。MCP 規格提供的是連接模型應用與外部能力的通用介面；例如伺服器可以依實作提供可呼叫的 Tools、可讀取的 Resources 和 Prompts。開發台是否保存狀態、能不能開票或執行 Git 操作，仍要看實際 MCP Server 和周邊系統怎麼設計。MCP 官方規格：Server Features 因此我會把 MCP 想成這條流程的「連接層」，而不是整套開發管理系統本身。Session 保存、Ticket 欄位、權限控管、測試流程與工作狀態，都是 Harness 和開發台需要另外規劃的部分。 Agent Harness 讓模型有地方工作這個分工也呼應我最近一直在研究的觀念：Agent = Model + Harness。 大家常比較 GPT、Claude、Gemini 或 Codex 的模型能力。模型當然重要，但如果整條流程、專案脈絡和驗收方式都綁在單一模型裡，每次換模型都可能得重新建立工作方式。 如果自己的開發 Harness 已經整理好 Context、Tools、Ticket、Memory、Test、Git 和 Review Loop，模型就比較像其中一個可以調度的元件。今天可以 ChatGPT 規劃、Codex 執行；明天也可以換成另一個模型負責分析或 Review，再由適合的 Agent 實作。 這種可替換性不是插上另一個模型就會自動發生。不同模型可用的工具、輸入輸出格式和權限都可能不同，還是要有穩定的工作契約：任務怎麼交接、結果怎麼回報、測試如何判斷通過、失敗時誰要處理。 如果你想延伸理解 Harness 在 AI 開發流程中的位置，也可以閱讀從 Skill 到 Agent Harness：讓 AI 從知道怎麼做，走到真正完成工作；MCP、Skill 與 CLI 的分工則可參考AI 工具名詞全解析。 把 Ticket 寫成 Agent 能接手的工作Ticket 是這條流程能不能穩定運作的關鍵。若只有一句「幫我改善這段程式」，接手的 Agent 仍要猜背景、範圍和完成標準。每張票可以固定包含： 12345678910111213ticket_id: 自動產生title: 清楚描述要交付的結果background: 相關的專案脈絡problem: 目前遇到的問題priority: 優先級affected_files: 已知的相關檔案dependencies: 前置工作或相依項目acceptance_criteria: - 可明確驗收的條件test_requirements: - 完成前必須執行的檢查review_notes: 已知風險、限制或 Review 重點 其中 affected_files 可以列出已知範圍，但不應阻止 Codex 在檢查專案後指出還有其他必要檔案。真正重要的是 problem 說得清楚，acceptance_criteria 可以驗收，test_requirements 也符合專案實際狀況。 當 Ticket 結構固定，ChatGPT 就比較能把分析結果轉成工程任務；Codex 也能根據明確的交付條件回報完成、未完成與阻礙，而不是只回一句「已處理」。 下一場競爭可能是誰的 Harness 更完整當多個 Agent 開始分工，真正需要設計的就不只 Prompt，還包括它們共同使用的工作環境： Agent 能讀到哪些 Context，哪些資料不能取用？ 誰能建立 Ticket、修改程式或執行 Git 操作？ 測試失敗時，系統如何保留輸出並回報阻礙？ 每個階段的完成條件是什麼，由誰 Review？ Agent 交接時，下一位能否知道前一位做過什麼、為什麼這樣做？ 當 MCP 工具可以建立或改變外部資料時，也要設計清楚的權限與人工確認邊界。不要只因為模型「做得到」，就讓所有操作都自動執行。 這些環節加起來，才是 Agent Harness 真正提供的工作條件。若系統有持續的 Context、明確的 Ticket、可執行的測試與可靠的回報方式，就能讓模型專注在任務，而不是每一輪都重新猜專案發生了什麼事。 從一張結構化 Ticket 開始如果你也想嘗試這種 AI Coding 工作方式，可以先挑一個範圍小、容易驗收的任務，整理出背景、問題、優先順序、驗收條件和測試要求，再觀察 ChatGPT 與 Codex 分工後有哪些地方仍需要人工補充。 接著再逐步加入專案 Context、Ticket 狀態、工具權限與 Review 流程。先讓交接清楚、失敗能回報，再決定哪些步驟適合自動化。 AI Coding 正從「我跟一個 AI 一直聊天，直到網站做完」，走向「我在管理一條由多個 AI Agent 組成的軟體開發流程」。ChatGPT 不一定要負責寫程式，Codex 也不必負責想完所有事情；把規劃、執行、測試和 Review 拆開，再讓 Harness 接得住每次交接，才會真正累積成自己的 AI 開發台。 常見問答 (FAQ)Q1：在這種 AI Coding 流程裡，ChatGPT 和 Codex 怎麼分工？ChatGPT 可以負責需求討論、專案分析、Ticket 規劃與結果 Review；Codex 可以接手明確定義的實作與測試工作。實際分工仍取決於各自可讀取的 Context、可用工具和權限。 Q2：MCP 會自動替我保存 Session 或建立 Ticket 嗎？不會。MCP 提供模型應用與外部 Tools、Resources、Prompts 溝通的介面；Session 保存、Ticket 系統與 Git 操作必須由實際 MCP Server 或周邊開發台提供。 Q3：把規劃交給 ChatGPT，能保證省下 Codex 額度嗎？不能保證。不同產品方案、帳戶額度、工具呼叫方式和任務執行環境都會影響使用量。這種分工可以把分析與工程執行分開觀察，但是否省錢要依自己的實際方案和用量判斷。 Q4：想開始使用多個 AI Agent 協作，第一步該做什麼？先挑一個小型、可驗收的任務，寫清楚背景、問題、完成條件與測試要求，再讓不同 Agent 接力執行。確認工作交接和失敗回報可靠後，再逐步擴充工具權限、Ticket 狀態與自動化程度。

  • article-【GPT-6 Astra 正在把 Vibe Coding，推向 Vibe World Building】

    2026/9/14

    AI工具 AI Agent Vibe Coding
    【GPT-6 Astra 正在把 Vibe Coding，推向 Vibe World Building】

    以前我們講 Vibe Coding，常見的想像是：「一句話，AI 幫我做網站、寫 App。」 但最近看到幾個 GPT-6 Astra 搭配 Unreal Engine、Blender 與 Three.js 的案例，我開始覺得，下一階段可能不只是 Vibe Coding，而是 Vibe World Building。 你不只是叫 AI 寫程式，而是讓 Agent 進入專業工具，協助建立角色、遊戲與可以互動的世界。更有意思的是：AI 越能操作專業軟體，我反而越覺得 Domain Knowledge 會變得更重要。 以下案例依照作者公開展示整理，重點是觀察工作方法，不代表每個人使用相同模型、方案與工具設定都能得到相同結果；實際能力也會隨版本、權限與專案環境變動。 AI 開始進入專業工具，而不只生成程式碼Vibe Coding 把「描述需求、產出程式」變得更容易；而這幾個 3D 案例再往前一步：Agent 開始操作 Unreal Engine、Blender 或 Three.js 專案，建立內容、反覆修改，並把場景、規則與互動組合在一起。 這個轉變不只是「AI 會不會 3D」，而是工作環境開始從人操作的軟體，變成 Agent 也能操作與檢查的執行環境。 案例一：從一個物件，走向逐街建構曼哈頓Matt Shumer 分享 GPT-6 Astra 在 Unreal Engine 中建構曼哈頓場景的過程，並描述它花了一週逐街完成細節。這已經不是只要求 AI「放一棟房子、加幾棵樹」，而是把工作尺度拉到街道與街區。 他也展示過另一個 Unreal Engine 世界：場景裡有以 Astra 驅動的角色 Agent，並以共同生存為目標互動。這讓「建構世界」不只包含空間，也開始包含世界中的行動者與互動規則。 當場景從單一物件擴大到街區，問題自然會延伸到道路與建築的空間關係、資產管理、場景分工與驗收方式。若要進一步投入正式製作，效能、碰撞、載入策略與可維護性仍需要另外檢查；一段令人驚豔的展示，不等於所有製作環節都已完成。 來源：Matt Shumer 的曼哈頓建構展示、Astra Agent 世界展示。 案例二：拓撲不一致，就改用離散 Mesh 切換角色表情常用 Blendshape 做平滑變化，但這類頂點形變通常仰賴相容的網格拓撲與頂點對應。若不同 AI 生成的表情 Mesh 拓撲不一致，就不一定能直接做傳統的平滑 Morph。 Nano 分享的 Blender 做法不是硬把所有網格變成同一種拓撲，而是換個解題方向：先把不同表情的 Mesh 對齊；切換時顯示目標表情，並把未啟用的 Mesh 縮小、藏進角色頭部，再透過 Blender Driver 控制切換。 這不是 Blendshape 的平滑融合，而是離散表情切換。它用明確的取捨避開拓撲限制，適合某些表情展示情境，卻不能因此宣稱能取代所有臉部動畫流程或提供連續的表情過渡。 我覺得這個案例特別值得看，不是因為 Astra 知道 Blender 哪個按鈕在哪裡，而是 Nano 知道問題來自哪裡，並知道還有哪些方法可以繞過去。 來源：Nano 在 Blender 中切換角色表情的展示與提示詞。 案例三：一款跑酷遊戲背後，是一整套產品規則MSB 使用 GPT-6 Astra 搭配 Three.js 分享豎屏跑酷遊戲《THE LAST GATE》。看起來是讓角色往前跑，拆開需求後卻是一組完整的遊戲系統： 玩家通過加減乘除算術門時，隊伍人數會即時改變。 撞上障礙物會造成實際隊員損失，而且畫面人數要和遊戲中的真實人數一致。 終點遭遇會依最後存活的隊員人數決定。 需求包含三條短路線、即時重試，以及帶 Seed 的輸入回放。 這已經不是「幫我做一個 Three.js Demo」，而是把玩法規則、3D 場景、互動、狀態變化與可重現測試一起交給 Agent 處理。作品是否能投入正式產品，仍要再驗收效能、操控手感與程式維護性；但需求本身已經從一句畫面描述，長成可檢查的產品規格。 來源：MSB 的《THE LAST GATE》公開貼文。 三個案例，代表三種建構尺度 尺度 案例 真正要處理的問題 世界級 Unreal Engine 曼哈頓與 Agent 世界 空間關係、場景組織、資產與行動者 角色級 Blender 離散表情切換 拓撲限制、替代方案與表情控制 產品級 Three.js《THE LAST GATE》 遊戲規則、互動狀態、重試與回放 我看到的不是「GPT-6 Astra 很會 3D」而已，而是 AI 開始透過專業工具，把世界、角色與產品的不同層次串起來。 AI 越會操作軟體，Domain Knowledge 為什麼越重要？很多人看到 AI 越來越會用 Blender，第一個反應可能是：「那以後是不是不用學 Blender 了？」 我反而覺得，答案可能剛好相反。 真正厲害的不是 Agent 知道哪個按鈕在哪裡，而是有人知道問題為什麼發生、有哪些限制、什麼 workaround 可行，以及最後怎樣才算完成。 如果你知道 Blendshape、Topology、Mesh、Driver 是什麼，才比較可能看出表情網格不相容的原因，並想到可以改用離散切換。若連問題的語言都不熟悉，就很難把這種解法交代給 Agent，也不容易判斷結果有沒有真的做到。 所以 AI 淘汰的可能不是「懂 Blender 的人」，而是只知道 Blender 按鈕在哪裡、卻說不清楚問題與完成標準的人。 以前你懂 Blender，還得親手操作每一步；懂遊戲設計，也可能得等工程師把規則寫出來。Agent 改變的是專業知識的產能：你可以把問題、限制、不要採用的方法、可行的 workaround 與驗收標準交給 Agent，再由專業工具把它落地。 Domain Knowledge × Agent × Professional Tools 專業知識負責判斷，Agent 負責執行，專業工具負責把想法變成可以檢查與迭代的成果。 如果你想延伸看「如何把領域經驗交給 AI 軟體化」，可以讀我之前寫的把專業知識變成軟體；關於 Vibe Coding 如何改變軟體價值，也可參考專業知識與 Vibe Coding 的商業機會。 Vibe Coding 的下一階段，可能是 Vibe Anything以前學 Photoshop、Blender 或 Unreal Engine，常常代表自己要親手完成大量操作。未來你或許不必逐一操作每個按鈕，但仍需要理解這個領域有哪些物件與規則、問題通常出在哪裡、有哪些解法，以及如何驗收。 Vibe Coding 可能只是第一站。接下來還會有 Vibe 3D、Vibe Game Development、Vibe Animation，甚至 Vibe Engineering 與 Vibe World Building。關鍵不是「每套軟體的按鈕都記熟了沒」，而是當 AI 已經能操作工具時，你知不知道該交代什麼、該限制什麼，又該如何判斷它做得對不對。 常見問答 (FAQ)Q1：Vibe World Building 和 Vibe Coding 有什麼不同？Vibe Coding 通常聚焦於用自然語言描述需求、讓 AI 產生或修改程式；Vibe World Building 則把 Agent 帶進 Unreal Engine、Blender、Three.js 等專業環境，處理場景、角色、規則與互動，目標尺度從一段程式碼擴大到可探索或可玩的世界。 Q2：為什麼 AI 越會操作 Blender，專業知識反而越重要？專業知識能幫你定義問題、提供限制、選擇 workaround，並訂出驗收標準。Agent 可以執行很多操作，但仍需要有人判斷網格、表情或動畫是否符合實際用途。 Q3：不同拓撲的表情 Mesh 可以直接做平滑 Blendshape 嗎？不一定。傳統 Blendshape 的頂點形變需要相容的網格與頂點對應；若拓撲不同，可能要先整理網格，或採用像案例中的離散 Mesh 切換。離散切換不等於平滑表情融合，也不是適用所有角色動畫的通用替代方案。 Q4：AI 做出的 3D 遊戲展示，就等於可以正式上線嗎？不等於。除了畫面與主要玩法，仍要測試效能、操控、錯誤狀態、裝置相容性與後續維護。案例呈現的是 Agent 能協助建構與實作的範圍，正式產品仍需要明確的驗收與測試。 Q5：想開始用 Agent 建立 3D 或遊戲專案，最先要準備什麼？先把目標拆成可檢查的規則：有哪些物件、它們如何互動、哪些限制不能違反，以及怎樣算完成。從小範圍任務開始，讓 Agent 執行後再用專業知識檢查結果，會比只要求「做得漂亮」更容易迭代。

  • article-【AI 會寫 API 還不夠：Vibe Coding 下一個機會，是把台灣產業經驗做成 Skill】

    2026/9/14

    商業策略 AI Agent Vibe Coding
    【AI 會寫 API 還不夠：Vibe Coding 下一個機會，是把台灣產業經驗做成 Skill】

    最近看到一個很有意思的開源專案：ecommerce-cia。 它不是另一套電商系統，也不是幫你做購物車，而是一套專門給 AI Coding Agent 使用的「台灣電商 Skill」。 看到這個專案，我第一個想到的是：Vibe Coding 發展到現在，真正的瓶頸可能已經慢慢從「AI 會不會寫程式」，轉移到「AI 懂不懂這個產業」。 因為現在要 AI 幫你寫一個購物車，其實已經不難。商品頁、購物車、會員、訂單後台，甚至串 API，AI 都可以很快幫你生出來。 真正痛苦的是後面。 「我要接綠界。」「我要用藍新。」「LINE Pay 怎麼串？」「7-11 取貨付款怎麼做？」「ATM 付款超過三天沒付，訂單怎麼辦？」 然後你會發現一個很有趣的狀況：Coding Review 沒有 Error，API 文件也看了，每一段程式碼單獨看，好像都沒有問題。 但真的把整間商店跑起來，就是不順。😂 最麻煩的 Bug，可能發生在兩個正確的 Function 之間一般我們叫 AI Review 金流，很容易只檢查幾個局部問題： API 呼叫對不對？ 簽章對不對？ Callback Route 有沒有建立？ 資料庫有沒有寫入？ 庫存 Function 有沒有執行？ 每一個地方都可能是對的，但問題可能發生在兩個「正確的 Function」中間。 以一筆交易為例，流程可能像這樣： 客人建立訂單。 系統保留庫存。 客人前往金流服務付款。 金流通知商店付款結果。 系統驗證通知並更新訂單狀態。 庫存、顧客通知與出貨流程依照訂單狀態接續處理。 如果 Callback 重送兩次呢？客人付款成功，但瀏覽器沒有跳回網站呢？ATM 建立虛擬帳號後幾天都沒有付款，庫存要什麼時候釋出？如果付款成功但庫存更新失敗，或訂單取消時付款通知剛好進來，系統又該怎麼辦？ 這些才是真正把電商系統跑起來後，會遇到的問題。 所以 Review 金流不該只逐個看 Function，而要沿著「錢」和「貨」走過完整流程：下單、訂單、庫存、金流、Callback 驗證、狀態更新、出貨，到交易完成，逐段找可能的斷點。 ecommerce-cia 示範了另一種 AI 稽核方式ecommerce-cia 不是另一套購物車或電商平台，而是給 AI Coding Agent 使用的台灣電商 Skill。它有意思的地方，在於把注意力放到金流、庫存、訂單等環節如何互相影響。 依照專案 README 的說明，它有檢查既有交易流程的 Audit Mode，也有引導新手準備與串接金流的 Setup Mode；文件提到藍新、綠界、PAYUNi、TapPay 與 LINE Pay 等台灣常見情境。這些內容呈現了一個值得參考的方向：除了問 AI「這段程式碼有沒有寫錯」，也可以要求它沿著整條交易生命週期檢查系統行為。 這已經不只是一般的 Coding Skill，而是把產業流程和判斷方式整理成可重複使用的 Domain Engineering Skill。 AI 會看 API 文件，稀缺的是踩過坑的經驗這件事讓我想到我之前一直在談的「把專業知識軟體化」。 假設一個台灣電商工程師做了十年。他真正值錢的可能不是「我知道怎麼呼叫綠界 API」，因為這件事情 AI 看文件就能協助。 真正值錢的，是這些踩過坑才知道的事： 綠界或藍新的 Callback 曾經出過什麼狀況。 ATM 訂單逾期後，何時釋放庫存才符合商業規則。 超商取貨付款訂單的狀態該怎麼轉換。 使用者付款成功但沒有跳回網站，不能因此就判定付款失敗。 Webhook 重送不能重複扣庫存或重複通知。 退款、取消與付款通知同時發生時，訂單狀態要如何處理。 這些東西通常不會完整寫在 API 文件裡。它們存在工程師的腦袋裡，來自踩坑、Debug、客訴、事故，以及凌晨三點修 Production 的經驗。😂 API 文件能說明端點、欄位和簽章方式；把這些技術細節放進真實商業情境後，流程上的例外與判斷往往還要靠產業經驗補足。 專業知識除了軟體化，也可以 Skill 化以前我們會想：我做了十年房仲，可不可以把我的判斷方法做成一套房仲 SaaS？我做了十年行銷，可不可以把我的 SOP 做成一套行銷系統？ 我之前也寫過把專業知識變成軟體，讓產業專家成為下一代產品經理。現在可能又多了一條路：不一定要先做 SaaS，也可以先把專業知識整理成 Skill。 從產業經驗到 AI 可執行 Skill 的概念示意。 一個資深電商工程師的經驗，如果要整理成 AI 能使用的 Skill，可以從常見情境開始，逐步寫清楚： 什麼情況下要啟動檢查。 要沿著哪些訂單、金流和庫存流程追蹤。 哪些例外狀況需要特別確認。 要用什麼證據判斷流程真的完成，而不是只看單一測試顯示綠燈。 如此一來，AI 就不只是「會寫程式」，還能重複參照一套做過許多台灣電商專案的人累積的判斷方式。 下一波 Vibe Coding 機會，可能是台灣產業 Domain Skills未來 Skill 最有價值的地方，不一定是 React Skill、Next.js Skill 或 Python Skill。這些通用技術知識，模型本身會越來越強。 更可能形成差異化的，是懂得台灣產業實際怎麼運作的 Domain Skills，例如： 台灣電商金流與物流。 台灣電子發票、統編與發票規則。 LINE 官方帳號與會員流程。 政府 Open Data 與台灣個資保護情境。 房仲成交流程、補教招生、餐飲訂位、美容預約與傳統產業報價。 這些領域的共同點是：模型可能知道技術，但不一定知道台灣的商業流程、例外情境與在地作法。而真正掌握這些 Know-how 的人，往往是已經在產業裡工作十年、二十年的實務工作者。 Skill 不只是提示詞，而是可以交給 Agent 使用的 SOP我現在看 Skill，已經不只把它當成「提示詞」，而是可以被 AI Agent 使用的產業 SOP。 以前經驗存在腦袋裡，後來我們把它寫成 SOP，再把 SOP 做成軟體。現在又多了一種形式：把 SOP 整理成 AI Agent 能參照與執行的 Skill。 Vibe Coding 的競爭，可能不只是誰比較會下 Prompt、誰比較會用 Claude Code 或 Codex，而是誰能把自己十年、二十年的產業經驗，整理成 AI 可以重複使用的能力。 模型會越來越強，寫程式會越來越便宜，API 串接也會越來越簡單。但有一件事情不會因此自動出現：你踩過的那些坑。 而那些坑，可能才是 AI 時代真正值得被「程式化」的專業知識。 這也是我看到 ecommerce-cia 之後，覺得最值得研究的地方。它表面上是在處理台灣電商金流、物流與流程稽核，背後示範的也許是一個更大的方向：下一波 Vibe Coding，不只是讓 AI 幫我們寫軟體，而是開始把一個產業真正的 Know-how，寫進 AI 裡。 常見問答 (FAQ)Q1：什麼是台灣產業 Domain Skill？台灣產業 Domain Skill 是把在地產業常見的情境、判斷方式、執行流程與例外處理整理成 AI Agent 可重複參照的規範。它能補足通用技術知識與實際商業流程之間的落差。 Q2：Domain Skill 和一般 Code Review 有什麼不同？一般 Code Review 多半檢查程式碼或單一 Function 的正確性；Domain Skill 可以引導 AI 沿著跨系統流程檢查狀態如何傳遞，例如金流通知、訂單更新、庫存處理與出貨。兩者處理的問題不同，實務上可以搭配使用。 Q3：如何把產業經驗整理成 AI Agent Skill？先整理常見情境與踩坑案例，再把觸發條件、判斷方式、處理步驟、例外狀況與驗證證據寫清楚，最後交由熟悉該產業的人用真實案例檢查。這樣的 Skill 才能承載可重複使用的專業判斷，而不只是一段泛用提示詞。

  • article-全民修仙時代來了：AI 給每個普通人一個重新選擇靈根的機會

    2026/9/10

    AI自動化 AI Agent Vibe Coding
    全民修仙時代來了：AI 給每個普通人一個重新選擇靈根的機會

    最近看到一篇分析修仙小說的文章，裡面有個觀點讓我想了很久。 為什麼這幾年修仙小說這麼紅？ 因為修仙小說賣的可能從來都不是「成仙」。 它真正賣的，是一套普通人的生存想像： 你可能沒有背景、沒有資源，甚至連靈根都很差。 但只要肯學、肯熬、找到自己的功法，再加上一點機緣，人生就還有翻盤的可能。 看到這裡，我突然發現： 這跟現在的 AI 時代，實在太像了。 以前沒有靈根，很多事情你連門都進不去以前想做一個網站，你最好會寫程式。 想做漂亮的廣告，你要懂設計。 想拍影片，你要懂腳本、攝影、剪輯。 想做音樂，你最好懂一點樂理。 想成立一家公司，你還需要行銷、業務、客服、行政等不同專業的人。 這就像傳統修仙世界。 你沒有火靈根，人家告訴你別學煉丹。 你沒有劍道天賦，就不要妄想成為劍修。 你的「出生能力值」，很大程度決定了你能做什麼。 但 AI 出現之後，一件很有趣的事情發生了： 雜靈根，也可以修仙了。 不會寫程式，可以 Vibe Coding。 不會畫圖，可以 AI 生圖。 不會剪影片，可以 AI 剪輯。 不會作曲，可以生成音樂。 不懂自動化，可以跟 AI 一起建立 Workflow。 一個普通人第一次可以用非常低的成本，同時碰觸過去需要很多年才能跨入的專業領域。 AI 並沒有讓所有人突然變成天才。 它只是讓大量原本沒有「靈根」的人，第一次拿到了進入仙門的門票。 ChatGPT 是法寶，Prompt 是符籙，Workflow 是陣法如果真的把 AI 時代翻譯成修仙世界，其實非常有趣： AI 時代 修仙世界 ChatGPT、Claude、Gemini、Codex 法寶 Prompt 符籙 Skills 功法 Token、算力與訂閱費 靈石 GitHub、YouTube 與網路知識庫 藏經閣 新模型、新平台與新技術 突然開啟的秘境 Vibe Coding 煉器 AI 內容製作 煉丹 n8n 與各種 Workflow 陣法 Agent 靈獸、傀儡，甚至是分身 這裡的工具名稱與能力會隨版本、方案和使用情境變動，所以重點不在於替某個法寶排出永久排名，而在於理解自己想解決什麼問題。 這時候再回頭看現在很多人在問的問題： 到底要學哪一個 AI？ 其實就很像一個剛進仙門的弟子，每天跑去問： 師兄，哪一把劍最強？ 問題可能一開始就問錯了。 真正重要的從來不是哪把劍最強，而是： 你到底修什麼道？ 你想解決誰的問題？ 你能不能把法寶組合成自己的方法？ 如果想把這條路拉回實作，可以先從 非工程背景也能開始的 Vibe Coding 開始，再把經驗整理成 Prompt 到 Skill 的工作流。 當所有人都有法寶，法寶就不值錢了2023 年，你會使用 ChatGPT，可能還算是一種優勢。 到了今天，如果你告訴別人： 我會用 AI。 其實已經跟修仙者說： 我有一把飛劍。 差不多。 因為大家都有。 當法寶變成標準配備，真正產生差距的，就不再是「有沒有法寶」，而是： 你會不會使用？ 你修的是什麼功法？ 你能不能把不同法寶組合起來？ 你有沒有自己的陣法？ 最後能不能形成一套自己的戰鬥體系？ 所以我最近越來越覺得，AI 能力其實也有自己的修仙境界。 AI 能力也有自己的修仙境界 境界 AI 能力 具體轉變 煉氣 會問 AI 開始把 AI 當成日常協作工具 築基 會寫 Prompt 能把需求與上下文說清楚 金丹 建立自己的 Workflow 把重複工作整理成穩定流程 元嬰 開始建立 Agent 讓 AI 代替自己執行一段任務 化神 讓多個 Agent 協作 組織 AI 團隊，打造自動化體系 煉虛 把專業知識封裝成 AI 系統 讓經驗變成可以重複使用的能力 合體 人的判斷與 AI 工作流程融合 人機協作成為日常工作方式 大乘 駕馭過去一家公司才有的生產力 一個人也能調度多種專業能力 渡劫 持續面對模型與環境變化 幾乎每隔一段時間就要重新適應天地靈氣 然後呢？ 渡劫。 而且 AI 世界的天劫，可能每隔幾個月就來一次。 最可怕的是：你好不容易築基，全世界突然都築基了這大概是 AI 時代最殘酷，也最有趣的地方。 你花半年學會的能力，下一代模型可能直接內建。 以前很會寫 Prompt，是競爭力。 模型變聰明之後，Prompt 的門檻開始下降。 以前 AI 生圖需要研究一大堆參數，後來一句自然語言就能完成。 以前 Vibe Coding 已經讓不會寫程式的人可以做網站。 接下來 Agent 可能連需求分析、寫程式、測試、除錯、部署都自己完成。 你昨天還覺得自己終於築基成功。 一覺醒來： 天地靈氣復甦，全民築基。 所以 AI 時代真正危險的事情，不是不學新工具。 而是把某一個暫時稀缺的操作技能，誤認成自己長期的護城河。 所以 AI 時代反而更需要「修心」這也是我覺得修仙小說最有趣的地方。 修仙小說寫到最後，真正決定一個人能走多遠的，往往不是靈根，也不是手上的法寶。 而是「心性」。 因為法寶可以撿。 功法可以學。 丹藥可以買。 唯有道心，要自己修。 放到 AI 時代也是一樣。 當工具越來越強、取得成本越來越低，最後真正拉開人與人差距的，反而會重新回到一些看起來很「老派」的東西： 判斷力 審美 經驗 信用 選擇 持續學習 解決問題的能力 在還看不到成果的時候，持續累積的能力 這些東西，AI 很難直接送給你。 AI 時代，每個人都要選自己的「修仙百藝」修仙小說裡有煉丹、煉器、符籙、陣法、靈植。 不一定每個人都要成為最強劍修。 只要找到一門市場需要的能力，把它練深，一樣可以換到靈石、累積資源，甚至建立自己的勢力。 AI 時代也是如此。 有人修 AI 影片。 有人修 Vibe Coding。 有人修自動化。 有人修 Agent。 有人修 AI 行銷。 有人修 AI 教學。 有人修內容與個人品牌。 你不需要全部精通。 真正重要的是： 找到一條可以跟自己原本專業結合的「道」，然後持續修下去。 因為真正能賺錢的人，未必是每天知道最多新模型的人。 而是能把其中一門能力，修到真的可以解決別人的問題。 如果你想把「一個人駕馭多種能力」落地，也可以延伸閱讀 零人公司：不是沒人，而是沒有當下做決策的人。 AI 最大的機會，不是讓強者變得更強當然，有錢、有資源、有技術背景的人，使用 AI 一樣有巨大優勢。 世家依然是世家。 大宗門依然有更多靈石、更多算力、更多人才。 AI 並沒有突然讓世界變公平。 但它帶來了一個很重要的改變： 普通人可以用更低的成本，獲得以前根本碰不到的能力。 一個人可以寫程式。 可以做設計。 可以剪影片。 可以做行銷。 可以建立自動化。 甚至可以開始指揮一群 AI Agent 工作。 這才是我認為 AI 真正有趣的地方。 它不是讓每個人站在同一條起跑線，而是讓原本連比賽資格都沒有的人，突然拿到了一張入場券。 真正的「飛升」，可能不是更會用 AI所以如果真的要替 AI 修仙設計最後一個境界，我反而覺得不是： 我可以同時操作十個 AI。 真正的飛升應該是： 你已經不再親自操作每一個 AI，而是在設計 AI 如何工作。 你把自己的經驗變成方法。 把方法變成 Prompt。 把 Prompt 變成 Skill。 把 Skill 變成 Workflow。 把 Workflow 交給 Agent。 最後把 Agent 組成一套可以持續運作的系統。 到那個時候，你真正放大的就不是「AI 的能力」，而是你自己累積二十年的能力。 所以我現在越來越相信： AI 時代真正值得修的，從來不是 ChatGPT、Claude、Gemini 或哪一個模型。 那些都只是法寶。 真正值得修的是自己的「道」。 以前比的是誰有天賦。 後來比的是誰有工具。 當人人都有 AI，最後比的，可能又會回到誰的道更深。 AI 沒有保證普通人一定可以翻身，就像拿到一本功法，也不代表一定能飛升。 但是它至少讓這個時代多了一種可能： 沒有背景、沒有團隊、沒有頂級天賦的普通人，也能開始修仙。 現實世界沒有系統提示。 努力也不一定會顯示： 恭喜你，經驗值 +100。 但如果 AI 真的是這個時代突然出現的一場「靈氣復甦」，那麼現在真正值得問的，可能已經不是： 哪一個 AI 最強？ 而是： 你的道，準備怎麼修？ 常見問答 (FAQ)Q1：AI 真的能讓每個普通人都變成專業者嗎？不能。AI 主要降低的是專業領域的入場門檻，讓普通人更容易開始嘗試與製作；真正能走得長久，仍然需要判斷力、經驗、審美、信用與持續解決問題的能力。 Q2：AI 時代到底該先學哪一個工具？先從自己想解決的問題與想修的方向開始，再選擇適合的工具。ChatGPT、Claude、Gemini、Codex 或其他模型都只是法寶，工具能力也會隨版本、方案與使用情境變動。 Q3：不會寫程式的人可以從哪裡開始學 AI？可以先從能立即驗證成果的任務開始，例如用 AI 協助寫內容、做設計、剪影片、建立簡單 Workflow，或嘗試 Vibe Coding。重點不是一次學會所有工具，而是把一次任務逐步整理成可重複的方法。 Q4：如何把 AI 能力變成長期競爭力？把自己的專業經驗整理成方法，再依序沉澱成 Prompt、Skill、Workflow 與 Agent；當這些工具和你的領域知識、判斷力及信用結合，才比較可能形成不容易被下一代模型取代的工作系統。

  • article-【342 個免費 3D Prompt，我看到的不是提示詞資料庫，而是 3D Vibe Coding 正在成形】

    2026/9/10

    AI工具 AI Agent Vibe Coding
    【342 個免費 3D Prompt，我看到的不是提示詞資料庫，而是 3D Vibe Coding 正在成形】

    最近發現一個滿值得收藏的網站：Tripo 3D Prompts。 它整理了超過 300 個免費的 AI 3D Prompt 與實際案例，內容涵蓋 Three.js、Blender、WebGPU、Browser Game、角色建模、3D 世界與各種互動效果。 資料註記：2026 年 9 月 10 日查閱時，官方頁面顯示 342 個案例，數量會持續更新。網站會區分作者公開的原始 Prompt，以及依公開作品整理的任務描述；使用時可以先查看個別案例的來源標示。 如果只是把它當成「Prompt 大全」，其實有點可惜。 因為我看了一輪之後，真正讓我感興趣的不是這 300 多條 Prompt，而是： 3D Vibe Coding 的方法論，好像已經慢慢成形了。 以前 Vibe Coding 做網站，現在開始「做世界」這一兩年大家講 Vibe Coding，最常看到的還是： 「幫我做一個官網。」 「幫我做一個管理後台。」 「幫我做一個 SaaS。」 「幫我做一個小工具。」 本質上，大部分還是 2D Web UI。 但 Tripo 3D Prompts 裡面，已經開始出現很多完全不同的東西。 例如 Three.js 3D 遊戲、卡丁車競速、飛行模擬器、第三人稱射擊遊戲、3D 解謎、互動式中國庭院、梵谷畫作 3D 世界、WebGPU Soft Body、Blender 建模與動畫…… 甚至可以拿一張圖片或一段影片當參考，要求 AI 重建成可以互動的 Three.js 3D 場景。官方就收錄了依參考影片重建 Three.js 場景的案例，呈現這種從視覺參考出發的需求描述。 這件事代表一個很有意思的變化。 以前我們 Vibe Coding 是： Prompt → 網頁 現在開始變成： Prompt → 場景 → 物件 → 物理 → 互動 → 世界 我會把它叫做：3D Vibe Coding。 這個網站真正值得學的，不是 Copy Prompt看到 300 多個 Prompt，第一個直覺一定是：「太好了，以後直接複製貼上。」 但我反而覺得，這是最可惜的使用方式。 因為真正值得研究的是：這些厲害的 3D Prompt，到底是怎麼描述需求的？ 我整理之後發現，好的 3D Vibe Coding Prompt，大致可以拆成類似的結構： Reference → World → Assets → Mechanics → Interaction → Camera → UI → Feedback Loop → Acceptance Criteria 這是我從案例整理出的需求拆解方式，不是網站規定的唯一格式。換成比較好理解的問題，就是： 需求層次 要描述清楚的事情 Reference：參考資料 參考哪張圖片、哪段影片或哪個作品？ World：世界 場景長什麼樣？空間與路線怎麼安排？ Assets：素材 需要哪些角色、車輛、建築與道具？ Mechanics：機制 移動、物理、碰撞與遊戲規則如何運作？ Interaction：互動 玩家可以做什麼？怎麼控制？ Camera：鏡頭 鏡頭要跟隨、環繞，還是自由移動？ UI：介面 操作提示、狀態與 HUD 要顯示什麼？ Feedback Loop：回饋迴圈 怎麼執行、觀察結果，再修改？ Acceptance Criteria：驗收標準 哪些條件成立，才算完成？ 這跟我們平常說「幫我做一個 3D 賽車遊戲」，差非常多。 例如今天我要做卡丁車。與其只描述「我要一款賽車遊戲」，不如拆成： 世界長什麼樣？賽道怎麼設計？ 車子如何控制？有沒有甩尾？ 碰撞怎麼處理？鏡頭怎麼跟車？ 怎麼計算圈數？有沒有 Checkpoint？ AI 對手怎麼跑？HUD 顯示什麼？ 什麼情況算完成遊戲？ 當這些東西被描述清楚之後，AI 面對的就不再是一句模糊的願望，而是一份可以執行的規格。 不要 Copy Prompt，要 Copy Architecture這也是我現在看這類 Prompt Library 最大的心得。 Prompt 本身很快就會過時。 今天 GPT-6 Astra 很強，明天可能又有新的模型。今天某一條 Prompt 很厲害，幾個月後模型能力提升，也許一句話就做得到。模型的表現也會隨版本、方案與任務改變，不需要把當下的選擇當成永久排名。 但是，Architecture 不容易過時。 例如你找到一個很棒的 Kart Racing 案例，真正應該留下來的是： 12345678910賽道系統→ 車輛控制→ Vehicle Physics（車輛物理）→ Drift（甩尾）→ Checkpoint（檢查點）→ Lap System（圈數系統）→ AI Opponent（AI 對手）→ Follow Camera（跟隨鏡頭）→ HUD（遊戲資訊介面）→ Win Condition（獲勝條件） 這整組就是一個 Racing Game Pattern。 下一次根本不需要重新想。 你可以把 Roblox 風格換成科幻城市，也可以換成台灣夜市，甚至可以變成「享哥 AI 賽車學院」。 美術全部換掉，但是底層 Pattern 保留下來。 這才是我認為 AI 時代真正值得累積的東西。 更大的變化，是 AI 開始自己「看結果」還有一個地方，我覺得比 3D 本身更值得注意。 以前我們使用 AI Coding 的流程通常是： 下 Prompt → AI 寫程式碼 → 執行 → 人類看結果 → 告訴 AI 哪裡不對 → AI 修改 問題是，中間那個「看結果的人」一直都是我們。 但現在開始不一樣。 當工作環境具備執行、截圖與視覺理解能力，新的工作流可以變成： 1234567891011121314151617Prompt↓AI 建構↓執行↓Screenshot↓AI 自己看畫面↓跟 Reference 比較↓找出差異↓修改↓重新執行 這個差異非常大。 因為 AI 不再只是 Coding Agent，它開始變成 Visual QA Agent。 以前我們叫 AI：「幫我寫 Three.js。」 未來比較可能變成：「這是我要的參考畫面，你自己做到像為止。」 當然，「畫面像」還不是全部驗收。卡丁車能不能控制、圈數有沒有算對、碰撞是否正常，仍要搭配實際操作與功能測試；截圖主要幫助檢查視覺差異。 這也呼應我之前整理的 Agent Harness 觀念：除了模型會不會寫程式，讓它能執行、觀察、修正的工作環境，同樣關鍵。 Tripo 在這裡扮演什麼角色？這也是我一開始容易搞混的地方。 Tripo 3D Prompts 本身比較像 3D Vibe Coding 靈感與 Pattern Library。 真正需要 3D 模型時，則可以再透過 Tripo Studio 之類的 AI 3D 工具，從文字或圖片產生角色、車輛、建築、道具等 3D Assets。Tripo 官方功能介紹也將文字與圖片生成 3D 模型列為核心能力。 於是整條 Workflow 就變得很有意思。如果由我來串接，會是： 1234567891011Tripo Prompts 找案例→ 找到接近的 Pattern→ Codex 分析案例→ 產生 PRD（產品需求文件）→ 建立 Three.js Prototype→ AI 產生 3D Assets→ 匯入場景→ 執行測試→ Screenshot→ AI 視覺檢查→ 自動修改 這已經不是以前那種「AI 幫我產一個 3D 模型」，而是一條逐漸完整的 AI 3D Production Pipeline。 這裡描述的是把不同工具接起來的工作流程構想；免費 Prompt Library 與模型生成服務是不同環節，實際生成的可用功能與額度，仍以各工具當下的方案為準。 如果是我，我甚至不會只收藏 342 個 Prompt我反而會再做下一步：把這 300 多個案例重新分類。 例如： Three.js Interactive Pattern Racing Game Pattern Third Person Game Pattern 3D World Pattern Blender Modeling Pattern Physics Simulation Pattern WebGPU Interaction Pattern Product Visualization Pattern 然後把它們做成自己的 3D Vibe Coding Skill。 以後我只需要跟 Codex 說：「幫我做一款 3D 卡丁車遊戲。」 Skill 自己判斷： Game → Racing → Third Person → Vehicle Physics 接著載入對應的 Pattern，然後自己： Plan → Build → Run → Screenshot → Compare → Fix 這是我希望進一步做出的 Skill 設計方向。要讓它實際運作，還需要把分類規則、範例、工具操作與驗收條件整理好。 如果你還不熟悉 Skill、MCP 與 CLI 的分工，可以先看這篇工具名詞整理。 到了這時候，「342 個 Prompt」就不再只是收藏在瀏覽器書籤裡面的資料，而是變成 AI 可以重複使用的能力。 我覺得 3D Vibe Coding 會是下一個很好玩的方向前幾天我才在想：現在用 Three.js + Vibe Coding，到底能不能做一款類似卡丁車的瀏覽器遊戲？ 看完這批案例之後，我的答案已經不是「能不能」，而是： 我們接下來可以做到多複雜？ 因為當 Coding Agent、Three.js、Blender、AI 3D Model、Browser Automation、Computer Use、Visual QA 這些能力開始接起來之後，門檻正在快速下降。 以前做一個 3D 世界，你可能要會建模、材質、Lighting、動畫、Three.js、物理引擎、Game Logic、UI、程式設計…… 現在慢慢變成： 你負責描述世界，AI 負責把世界建構出來。 所以 Tripo 3D Prompts 最值得收藏的，可能不是那 342 個 Prompt，而是它讓我們提前看到了一件事情： Vibe Coding 的下一站，可能不只是做網站。 而是開始做遊戲、做空間、做互動、做模擬，甚至直接做一個可以走進去的世界。 而我們現在，可能才剛走到 3D Vibe Coding 的第一章。 常見問答 (FAQ)Q1：Tripo 3D Prompts 是什麼？可以免費使用嗎？Tripo 3D Prompts 是免費瀏覽的 AI 3D 提示詞與案例資料庫，涵蓋 Three.js、Blender、瀏覽器遊戲與互動場景。2026 年 9 月 10 日查閱時顯示 342 個案例；部分是作者原始 Prompt，部分是依公開作品整理的任務描述。免費瀏覽案例，不代表搭配使用的模型生成或程式開發工具都沒有費用。 Q2：3D Vibe Coding 與一般 Vibe Coding 有什麼不同？本文用 3D Vibe Coding 描述透過 AI 建構 3D 場景與互動體驗的做法。相較於常見的 2D 網頁介面，它還需要把世界、物件、物理、操作、鏡頭與遊戲規則描述清楚，讓需求從一句願望變成可以執行及驗收的規格。 Q3：為什麼要 Copy Architecture，而不只複製 Prompt？Prompt 的效果容易隨模型與任務改變，但架構與互動模式可以重複使用。例如賽車遊戲的車輛控制、甩尾、檢查點、圈數、對手、跟隨鏡頭與獲勝條件，都可以整理成 Racing Game Pattern，再換成不同場景與美術風格。 Q4：AI 可以只靠 Screenshot 完成 3D 遊戲驗收嗎？不行。Screenshot 適合協助比較構圖、材質、光線與介面等視覺差異；車輛操作、碰撞、圈數與獲勝條件，仍需要實際操作與功能測試。完整回饋迴圈應包含建構、執行、截圖、比較、修改，以及相關功能的再次驗證。 Q5：如何把 Tripo 案例整理成自己的 3D Vibe Coding Skill？可以先按賽車、第三人稱遊戲、3D 世界、Blender 建模、物理模擬或產品展示分類，再把各類案例的需求結構、操作方式、參考素材與驗收條件整理成 Pattern。最後將選擇 Pattern 的規則與 Plan、Build、Run、Screenshot、Compare、Fix 流程寫入 Skill，並接上實際可用的工具。

  • article-從「周同學」我開始想：個人品牌的下一步，可能不是做更多內容，而是把自己變成一個 IP

    2026/9/8

    AI Agent 內容行銷 個人品牌
    從「周同學」我開始想：個人品牌的下一步，可能不是做更多內容，而是把自己變成一個 IP

    最近研究了一個很有意思的案例：「周同學」。 如果你不知道周同學是誰，它是周杰倫的官方二次元 IP 形象。一開始看到它，你可能會覺得： 不就是把周杰倫畫成卡通人物嗎？ 但我深入研究之後，發現真正值得研究的，完全不是「把真人畫成卡通」這件事，而是它背後正在做的轉換： 把一個真人的影響力，轉換成一個可以獨立運作的 IP 資產。 以下不是在盤點周同學所有合作或授權成果，而是從這個案例拆出一個品牌命題：真人的影響力，如何被轉換成可以延伸的角色、內容與世界。 我從「周同學」看見的，不只是卡通角色周杰倫本人是一個超級 IP，但真人 IP 有一個天然限制：本人只有一個。 一天只有 24 小時，也不可能每一場活動、每一個品牌、每一座城市、每一項商品都由本人親自出席。真人的時間、體力與出場頻率，會限制影響力能夠延伸的速度。 「周同學」做的事情很有意思。它把周杰倫身上的辨識度、文化符號與粉絲記憶抽取出來，重新建立成一個二次元角色。 接著，這個角色就能進入不同場景，例如： 潮玩與文創 3C、食品與品牌聯名 藝術展與商場活動 城市活動與文旅場景 數位角色與 AI 應用 這時候我才發現： 公仔只是產品，角色 IP 才是資產。 真正的商業模式不是「周杰倫 → 卡通版周杰倫 → 賣公仔」，而是一條可以持續延伸的路徑： 1234567891011周杰倫 ↓人物符號化 ↓周同學 ↓角色 IP ↓內容、商品、品牌聯名與場景 ↓授權、數位角色與 AI 也就是把「一個人」，慢慢延伸成「一個世界」。 為什麼角色 IP 比單一商品更有延展性？單一商品的價值，通常來自一次交易；角色 IP 的價值，則來自它能不能被反覆放進新的內容、媒介與使用情境。 一個有辨識度的角色，可以成為： 漫畫或動畫裡的主角 商品與聯名活動的視覺入口 展覽、商場或城市活動的互動人物 品牌故事裡的共同角色 數位服務與 AI Agent 的使用介面 這些形式表面上不一樣，但背後共享同一個角色記憶。讀者或粉絲不需要每次重新認識一個陌生品牌，而是可以在不同場景裡持續遇見同一個角色。 因此，IP 的重點不是「最後有沒有做出公仔」，而是角色能不能承載一套穩定的個性、價值觀、內容語言與世界觀。 這也讓我重新思考「享哥」這個品牌這幾年我累積了很多東西： 文章、課程與演講 AI 工具、Prompt 與網站 影片、教學案例與工作流程 AI 漫畫、AI 漫劇與 Podcast 的研究 AI Agent、Skill 與實際應用經驗 以前我常常把它們看成不同的內容或專案。這篇文章、那堂課、某一個工具，彼此之間好像各自存在。 但如果換成 IP 的角度來看，可能完全不同。 它們其實都可以被放進同一個世界： SeanVerse。 我目前想像中的架構，大致會是： 123456789101112131415享哥 ↓角色 IP ↓SeanVerse ↓漫畫／漫劇／知識內容 ↓課程／教材／Prompt ↓數位商品／實體商品 ↓AI Agent ↓品牌聯名與授權 這樣思考之後，我突然發現： 我真正要做的，也許不是把享哥畫成動漫，而是把享哥這個真人品牌，轉換成一套可以持續延伸的 IP 系統。 這個想法也和我之前思考「專業證據」以及「如何把經驗編譯成 AI 能執行的能力」有關。內容不是彼此孤立的作品，而是可以逐步累積成知識資產的材料。 如果想理解個人品牌如何累積案例、判斷與方法，可以延伸閱讀〈AI 時代，你真正該累積的不是內容，而是「專業證據」〉；如果想進一步看經驗如何走向 Skill 與 Agent，則可以參考〈AI 時代，40 歲後最值錢的不是經驗，而是把經驗「編譯」成 AI 能執行的能力〉。 我不想只做一個「Q 版享哥」如果只是： 1享哥 → Q 版 → LINE 貼圖 → 公仔 我覺得有點可惜。 因為角色真正有價值的地方，不只是「長得像我」，而是它能不能承載我的知識、價值觀、個性與世界觀。 例如，SeanVerse 裡可以慢慢建立自己的品牌語言： AI Core：代表知識與 AI 的核心。 Knowledge Particles：代表我們在工作與學習中累積的經驗與知識碎片。 Future Library：所有文章、課程、案例與方法匯聚的地方。 Knowledge Gate：通往不同學習領域的入口，例如 Vibe Coding、AI 行銷或 AI Agent。 AI Bird：陪著角色探索新科技世界的夥伴，也可以成為引導讀者學習的角色。 這些名詞不是為了把畫面做得更像科幻作品，而是希望逐步建立一套可以被辨認、被使用、被延伸的品牌語言。 當讀者看到 Knowledge Gate 時，知道那是一條學習路徑；看到 Future Library 時，知道那是一座知識庫；看到 AI Bird 時，知道它可能會陪著角色探索新的工具與問題。 這時候角色就不只是我的分身，它開始有自己的世界。 周同學 IP 化的是明星影響力，SeanVerse 想 IP 化的是知識我跟周同學有一個很大的不同。 周杰倫原本就擁有巨大的明星影響力，所以周同學很適合把明星的辨識度、粉絲記憶與文化符號商品化。 但我不是明星。 我是一個老師、一個創作者，也是一個每天都在研究新科技的人。所以如果我要走這條路，我真正能夠 IP 化的東西，不是明星光環，而是： 知識。 這也是我目前覺得最有意思的方向。 周同學是在把「明星影響力」IP 化；而 SeanVerse 想做的，是把「知識」IP 化。 這裡的知識，不只是把文章整理成一個資料夾，也不只是把課程換成角色講解。它還包括： 我如何拆解一個新工具 我如何判斷某個方法適不適合使用 我在不同案例中看過哪些失敗 為什麼某些做法在特定情境有效，換個情境卻不適用 如何把複雜的 AI 概念轉成初學者可以實作的路徑 這些反覆出現的觀點、判斷與教學方法，才是知識型 IP 最值得留下來的部分。 角色不只是拿來看的，而是真的可以教你東西這也是 AI 時代跟以前最大的不同。 以前的角色 IP，主要存在於漫畫、動畫、商品、公仔或遊戲。但現在多了一個全新的可能： AI Agent。 未來你看到 SeanVerse 裡面的角色，不一定只是看它講一句話，也不一定只是在社群上按讚或分享。 你甚至可以直接問： 我想學 Vibe Coding，應該怎麼開始？ 角色可以帶你進入 Vibe Coding 的 Knowledge Gate，幫你規劃學習路線、給你任務、解釋觀念、檢查成果，甚至陪你完成第一個作品。 這時候，角色與 AI 系統之間可以形成清楚的分工： 層次 在 SeanVerse 裡的角色 角色 UI，讓人用熟悉、具辨識度的形象進入服務 人格 UX，決定互動時的語氣、價值觀與陪伴方式 文章、課程與經驗 Knowledge Base，提供內容、案例與判斷素材 LLM Brain，負責理解問題與組織回應 Agent Action Layer，負責規劃任務、呼叫工具與協助完成行動 SeanVerse World，承載角色、內容、產品與互動場景 角色是 UI，人格是 UX；我的文章、課程與經驗是 Knowledge Base；LLM 是 Brain；Agent 是 Action Layer；而 SeanVerse，就是承載這一切的 World。 這件事情很有趣，因為角色不再只是被動展示知識，而是可以成為知識服務的入口。 如果想了解 AI Agent 與工具、Skill 之間的分工，也可以延伸閱讀〈Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness〉。 個人品牌的媒介，可能不等於真正的資產以前我們講個人品牌，通常會從媒介開始思考： 我要不要經營 Facebook？ 要不要拍 YouTube？ 要不要做 Podcast？ 要不要寫文章？ 但這些其實都只是媒介。 更往下一層思考，我們真正累積的到底是什麼？ 如果有一天： 文章可以被 AI 大量產生 影片可以被 AI 大量產生 Podcast 可以自動生成 社群也可以由 AI Agent 協助經營 那麼真正稀缺的，可能就不再只是內容本身，而是： 你是誰。 你的經驗、觀點、人格、方法論、故事、價值觀，以及別人對你的信任，才是難以快速複製的部分。 這不代表內容不重要。內容仍然是建立信任、傳遞知識與留下證據的方式；只是內容不應該停留在一篇篇彼此分散的作品，而是要逐漸形成： 1觀點 → 方法 → 案例 → 知識庫 → 角色 → 服務與互動 當這些東西累積到一定程度之後，其實就開始具備 IP 的條件。 真人負責建立信任，角色負責突破人的限制這可能是我研究周同學之後，得到最大的一個啟發。 未來的個人品牌，也許會慢慢變成： 真人 IP × 角色 IP × AI Agent 三者的分工可能是： 資產層 主要任務 享哥本人 透過真實經驗、教學與互動建立信任 角色 IP 跨越文章、漫畫、影片、商品與活動等媒介傳播 AI Agent 讓知識可以被查詢、被練習、被執行與被互動 SeanVerse 承載上述資產的世界觀、內容架構與商業延伸 所以我目前想像中的 SeanVerse，最後可能會有三層： 123享哥本人＝信任資產角色 IP＝品牌資產SeanVerse＝可以持續延展的知識世界 而 AI 從頭到尾都不是主角。 AI 只是讓這個世界可以被建立、被放大、被互動的一種技術。真正的主角依然是： 人與知識。 如果要開始，第一步不是做公仔，而是整理世界觀這個想法不代表今天就要立刻做出完整的角色商品，也不代表只要畫一個角色就會自動形成 IP。 比較務實的起點，可能是先把以下幾件事情整理清楚： 定義角色要代表什麼：角色的個性、語氣、價值觀與讀者關係是什麼？ 整理知識領域：哪些主題可以成為不同的 Knowledge Gate？ 建立內容與方法的對應：每一篇文章、每一堂課，能解決哪一種問題？ 留下判斷與案例：不只保存答案，也保存選擇、取捨、例外與失敗經驗。 從一個 Agent 場景開始：先讓角色協助完成一個具體的學習或工作任務，再逐步擴展。 這樣做的目的，是讓角色不只「看起來像享哥」，而是真的能代表一套可被使用的知識與方法。 SeanVerse 可能真正代表的事情AI 時代的個人品牌，下一場競爭可能已經不只是： 誰的內容做得比較多？ 而是： 誰能把自己累積多年的知識、人格與信任，建立成一個可以持續運作的 IP 世界？ 我想試著把這件事情做出來。 也許未來的享哥，不只是一個寫文章、做課程、上台演講的人；也可能是一個有角色、有知識入口、有學習路徑，甚至能透過 AI Agent 陪人完成事情的世界。 這可能就是 SeanVerse 真正的開始。 常見問答 (FAQ)Q1：個人品牌為什麼需要發展成 IP？個人品牌發展成 IP，不是為了追求流行，而是讓累積的經驗、人格、方法論與信任，可以被延伸到更多內容、媒介、產品與互動場景，降低真人只能親自出場的限制。 Q2：知識型 IP 和一般角色 IP 有什麼不同？一般角色 IP 可能以故事、外觀與情緒連結為主；知識型 IP 除了角色辨識度之外，還要承載可被學習與使用的觀點、案例、方法、判斷與學習路徑。 Q3：SeanVerse 是什麼？SeanVerse 是我用來想像「享哥品牌如何延伸」的知識世界，未來可以承載角色 IP、漫畫、漫劇、課程、Prompt、數位商品、實體商品、AI Agent、品牌聯名與授權等內容。 Q4：AI Agent 在 SeanVerse 裡扮演什麼角色？AI Agent 是 SeanVerse 的互動與行動層。它可以根據知識庫與角色人格回答問題、規劃學習路線、安排任務、檢查成果，或協助使用者完成具體工作。 Q5：不是明星，也能建立個人 IP 嗎？可以。非明星的個人品牌不一定要 IP 化明星光環，而是可以從專業知識、真實案例、個人觀點、教學方法與長期信任開始，建立一個具有辨識度且能持續延伸的知識型 IP。

  • article-AI 變現五階段：賣時間 → 賣知識 → 賣能力 → 賣結果 → 賣資產

    2026/9/8

    商業策略 AI自動化 AI Agent
    AI 變現五階段：賣時間 → 賣知識 → 賣能力 → 賣結果 → 賣資產

    最近很多人問我： 現在學 AI，到底可以怎麼變現？ 接案？開課？做顧問？賣 Prompt？用 Vibe Coding 做 SaaS？還是弄一堆 AI Agent，包裝成「AI 員工」？ 這些當然都可以。 但我最近越來越覺得，如果只是整理「100 種 AI 賺錢方法」，其實沒有太大意義。因為工具一直換、模型一直進步，今天還能單獨販售的東西，半年後可能就變成 AI 的內建功能。 真正值得研究的是： 你到底在賣什麼？ 如果從這個角度來看，我認為 AI 變現其實可以分成五個階段： 賣時間 → 賣知識 → 賣能力 → 賣結果 → 賣資產 而且越往後走，你的收入就越不需要完全跟自己的時間綁在一起。 AI 變現五階段，差別在於你交付什麼 階段 你正在販售的東西 常見形式 收入與時間的關係 賣時間 親自執行的服務 接案、代做、客製專案 高度綁定個人時間 賣知識 可傳遞的方法與經驗 課程、顧問、內訓、教材 同一份經驗可以重複販售 賣能力 被軟體化的專業判斷 Prompt、Workflow、Skill、Agent、程式 開始具備複製與自動執行能力 賣結果 客戶真正想要的產出 名單、預約、內容、報告、成交 以成果而非工具作為價值單位 賣資產 長期累積的商業系統 品牌、資料、產品、流量、通路 有機會產生長期複利 這五個階段不是互相排斥的商業模式，而是一條可以逐步升級的路徑。第一階段能幫你建立現金流，後面的階段則讓每一次交付都留下可以持續使用的東西。 第一階段：賣時間，先把效率差轉成現金流這是最容易開始的 AI 變現方式。 例如： 幫客戶製作 AI 圖片 製作 AI 影片 撰寫文案 製作簡報 用 Vibe Coding 建立網站 串接自動化流程 整理資料 建立客服系統 以前一個網站可能需要做兩個禮拜。現在搭配 AI，可能兩三天就能完成。 以前剪一支影片需要幾個小時，現在 AI 可以協助處理腳本、配音、字幕、素材，甚至完成初剪。 於是你產生了一個非常大的「效率差」：市場還按照過去的價值付錢，但你的生產成本已經下降。 這其實就是現在很值得把握的一波：AI Service Arbitrage。 你利用 AI，把原本需要大量人工的服務成本壓低，再把節省下來的效率轉換成利潤或更有競爭力的報價。 問題是：你還是在賣自己的時間。 一天終究只有 24 小時。當案件變多，你會開始遇到交付上限，也一定會開始思考： 能不能不要每次都從頭做？ 這個問題，就會把你帶到第二階段。 第二階段：賣知識，讓一次經驗可以重複交付當你做過十次、二十次之後，就會開始累積方法。 你會逐漸知道： 第一步應該做什麼 第二步應該問什麼 哪些地方最容易出錯 什麼 Prompt 比較有效 哪些流程可以省下時間 這時候你就可以開始販售： 課程 顧問服務 企業內訓 Workshop 教材 模板 你不再只是說： 我幫你做。 而是開始說： 我教你怎麼做。 這一步最大的改變，是同一份經驗開始可以賣很多次。你把過去在專案裡累積的做法整理成知識產品，交付的就不再只有一次性的勞動。 但它還有一個問題：你教完了，對方還是得自己做。 如果對方沒有時間、沒有經驗，或是不知道如何處理例外情況，那麼一份教材仍然不一定能直接變成成果。於是 AI 時代開始出現一個非常重要的第三階段。 第三階段：賣能力，把 Know-how 編譯成 AI 可以執行的能力這可能是我目前最看好的方向之一。 以前我們只能把 Know-how 寫成： 教材 SOP 書籍 課程 但現在開始可以把 Know-how 寫成： Prompt Workflow Skill Agent 程式 假設你很會寫廣告文案。以前你的變現方式可能是幫別人寫，或是教別人寫。 現在你可以把自己的判斷標準、文案架構、檢查流程、修改邏輯與產業經驗，全部整理成一套 Skill。 以後別人不一定需要「學會你」。他可以直接呼叫你的能力。 這是一個非常巨大的改變，因為我們第一次有機會把： 專業知識 → 編譯成 AI 可以執行的能力 例如： 房仲競品分析 Skill 短影音剪輯 Workflow AEO 分析 Agent 廣告法規檢查 Agent 行銷企劃 Skill 這些東西本質上都不只是 Prompt，而是被軟體化的專業能力。Prompt 比較像一次性的指令；Skill、Workflow 或 Agent 則可以把規則、步驟、判斷與檢查方式組合成可重複呼叫的模組。 如果想進一步理解 Prompt 與 Skill 的差異，也可以延伸閱讀：從提示詞到 Skill：5 個實務做法打造高效率 AI 自動化工作流。 當很多能力串在一起，就會開始變成 AI 系統，甚至是一間 AI 公司。 第四階段：賣結果，從工具服務走向 Outcome as a Service這一層我覺得很多人還沒有真正開始思考。 今天如果你賣的是： AI 業務 Agent，一個月 3,000 元。 客戶可能會問： 為什麼我要每個月付你 3,000 元？ 但如果你說： 每帶來一個符合條件的潛在客戶，我收 500 元。 客戶思考的問題就會完全改變。他開始問的可能是： 那你一個月可以給我幾個？ 這就是從 Software as a Service 慢慢往 Outcome as a Service 移動。 你不再只是販售工具，而是販售客戶真正想要的結果： 名單 預約 影片 報告 成交 流量 轉換 AI 只是你背後的生產機器。 客戶甚至不需要知道你使用的是 GPT、Claude、Gemini，還是十個 Agent。他只在乎一件事情： 結果有沒有出來？ 當然，這種模式的前提是結果必須能被清楚定義、量測與驗收，雙方也要先約定交付範圍與品質標準。否則「賣結果」很容易變成責任不清的承諾。 我認為未來很多所謂的「AI 員工」，最後都會走到這一步。因為企業真正想買的從來不是 AI，企業想買的是產出。 第五階段：賣資產，讓前面的累積開始產生複利這才是我認為 AI 變現最後真正有意思的地方。 前面四層做久了，你會累積什麼？ 客戶 資料 品牌 內容 SOP Skills Agents 軟體 流量 通路 Know-how 這些東西開始組合成一個不完全依賴你本人工作的商業資產。 例如你原本只是幫別人做 AI 短影音，後來把方法做成課程，再把流程寫成 Skill，接著做成自動剪輯工具。累積使用者之後，又產生大量資料與客戶。 最後你擁有的就不再只是： 我很會做 AI 影片。 而是一整套： 內容＋技術＋客戶＋資料＋品牌＋產品 這時候 AI 已經不是你的商品，AI 變成公司的基礎設施。 這也是為什麼我認為，把專業知識做成軟體，會是 Vibe Coding 之後很值得關注的方向。可以延伸閱讀：Vibe Coding 下一階段：把專業知識變成軟體，產業專家就是下一代產品經理。 同一份專業，其實可以賣五次假設你很懂「AI 短影音」，同一份 Know-how 可以有五種不同的交付方式： 第一次，賣時間： 我幫你剪。 第二次，賣知識： 我教你剪。 第三次，賣能力： 我把剪輯方法做成 Skill，讓 AI 幫你剪。 第四次，賣結果： 你不用管怎麼剪，我每個月直接交付 30 支影片。 第五次，賣資產： 把整套系統變成產品、品牌、平台與客戶群。 你會發現，Know-how 從頭到尾可能根本沒有換。改變的只是你怎麼包裝它、怎麼交付它，以及價值如何被客戶理解。 這個例子中的 30 支影片，是交付形式的示意，不是對任何服務的固定承諾。真正的數量、品質與價格，仍然要依服務範圍與客戶需求定義。 如何把每一次交付，逐步變成資產？如果你現在還在第一階段，完全沒有問題。賣時間本來就是最快建立現金流的方法。重點不是跳過第一階段，而是在完成工作時，刻意留下可以累積的部分。 每做完一個案子，可以多問自己幾個問題： 這次交付裡，哪些步驟會重複出現？ 哪些問題客戶每次都會問？ 哪些判斷其實可以整理成規則？ 哪些流程可以變成 SOP 或模板？ 哪些經驗可以變成課程或 Workshop？ 哪些能力可以變成 Skill、Workflow 或 Agent？ 這個服務是否有機會按照成果收費？ 長期下來，哪些內容、資料、客戶或通路會留下來？ 你不需要一次把所有事情都做完。可以先保留一份 SOP，再把其中一個重複步驟整理成模板；接著，把模板變成 AI 可以執行的模組，最後才思考如何產品化與規模化。 如果每做一個案子，都留下其中一部分，事情就會開始不一樣。 AI 變現真正值得學的，是把勞動變成資產所以我現在看 AI 變現，已經不太看「用什麼工具」。 我反而會先問一個人： 你現在在哪一層？ 你現在是不是還在接一個案子、做一次、收一次錢？ 如果是，那沒有問題。第一階段本來就是最快建立現金流的方法。但完成交付後，可以多問一句： 這次交付裡，有什麼東西可以留下來？ 賣時間，是今天做、今天有收入。 賣知識，是把昨天的經驗再賣一次。 賣能力，是讓 AI 開始替你執行專業。 賣結果，是把 AI 變成背後看不見的生產機器。 賣資產，則是讓前面所有累積開始產生複利。 所以如果今天有人再問我： 學 AI 到底要怎麼變現？ 我的答案可能不會先叫他去學哪個工具。我會先問： 你現在有什麼能力，是市場原本就願意付錢的？ 然後我們再來想，怎麼利用 AI，把這份能力從「只能賣一次」，一路變成「可以被複製、被執行、被規模化，最後成為資產」。 這可能才是 AI 變現真正值得走的路。 常見問答 (FAQ)Q1：AI 變現五階段分別是什麼？AI 變現五階段是「賣時間、賣知識、賣能力、賣結果、賣資產」。它描述的是同一份專業如何從一次性服務，逐步變成可複製的知識、可執行的 AI 能力、可驗收的成果，以及不完全依賴個人時間的商業資產。 Q2：AI 變現新手應該從哪一個階段開始？多數人可以先從賣時間開始，利用 AI 提升服務效率並建立現金流。完成數次交付後，再把重複流程整理成 SOP、教材、模板或 AI 模組，逐步往賣知識與賣能力前進。 Q3：Skill 或 Agent 和 Prompt 有什麼不同？Prompt 通常是一次性的指令；Skill 或 Agent 則能把專業規則、工作步驟、判斷標準與檢查流程組合成可重複呼叫或執行的模組。因此，Skill 與 Agent 更接近被軟體化的專業能力，而不只是更長的 Prompt。 Q4：什麼情況適合從賣工具改成賣結果？當客戶真正關心的是名單、預約、影片、報告、成交或轉換，而且這些產出可以被清楚定義、量測與驗收時，就可以思考 Outcome as a Service。此時要先與客戶約定交付範圍、品質標準與計價方式，避免把模糊期待當成結果承諾。 Q5：AI 時代所說的「賣資產」是什麼意思？賣資產是把長期累積的客戶、資料、品牌、內容、SOP、Skills、Agents、軟體、流量與通路組合成一套商業系統。這套系統即使不需要你親自參與每一個細節，也能持續支援產品、服務與收入。

  • article-AI 時代真正會被淘汰的，可能不是員工，而是「組織圖」

    2026/9/8

    商業策略 AI自動化 AI Agent
    AI 時代真正會被淘汰的，可能不是員工，而是「組織圖」

    最近看到一篇文章，標題下得很狠： 「市面上那些 AI 員工，將來多數都會是垃圾。」 文章裡有一句話讓我停下來想了很久： 「差別在於它取代的是一段流程，不是一個職稱。」 我覺得這句話，其實點出了現在很多企業導入 AI 時最大的問題。 我們嘴巴上說 AI 是全新的技術，但真正開始設計 AI 的時候，腦袋裡裝的卻還是幾十年前的公司組織圖。 公司有人資，所以做一個 AI 人資；公司有客服，所以做一個 AI 客服；公司有業務，所以做一個 AI 業務；公司有行銷，所以做一個 AI 行銷助理。 最後我們得到一間很有趣的公司：原本有十個人，現在變成一個人管理十個 AI 員工。 看起來很 AI，但仔細想想，公司的運作方式根本沒有改變。我們只是把組織圖裡面的人，換成 AI。 AI 真正取代的，可能不是職稱，而是一段流程傳統企業習慣用「職位」描述工作：客服負責回答問題、業務負責開發客戶、行政負責整理資料、行銷負責產出內容。 但客戶真正需要的，從來不是「某個職位完成自己的工作」，而是問題被解決、訂單被推進、報價被送出、客戶被妥善服務。 這中間的職位、部門與交接，很多時候只是人類在能力、時間、管理與協作都有限的情況下，發明出來的組織方式。 因此，AI 導入最值得問的問題，不一定是： 哪一個職位可以交給 AI？ 而是： 哪一整段工作，可以重新設計成更短、更直接、更少交接的流程？ 我們可能正在用「職缺」限制 AI今天的 AI 已經不只是聊天機器人。它可以搜尋資料、操作瀏覽器、處理文件、分析資料、寫程式、使用工具、串接 API，甚至建立完成任務所需要的小工具。 那麼問題來了：為什麼我們還要跟它說： 你是一個行銷助理，所以只負責行銷。 你是一個客服，所以只回答客戶問題。 你是一個業務，所以只負責開發客戶。 這其實很奇怪。 就像你買了一台可以挖土、搬運、測量，甚至自己規劃施工路線的機器，最後卻告訴它：「你的職稱是搬運工，所以你只能搬磚頭。」 不是 AI 不夠強，而是我們對 AI 的想像太小。我們把人類為了管理方便而設計的職缺，誤認成 AI 也必須遵守的能力邊界。 AI 導入的五個階段：從工具到 AI 原生組織如果把企業導入 AI 的路徑往前推，我會把它分成五個階段。 第一階段：AI 工具化這是大部分人現在最熟悉的階段： 幫我寫 Email。 幫我整理會議紀錄。 幫我做簡報。 幫我分析 Excel。 這個階段的 AI 是「工具」。人還是原本那個工作的人，只是完成工作的速度變快了。 它能提升個人生產力，但公司的基本分工、流程與責任邊界通常沒有改變。 第二階段：AI 職位化接下來是現在市場上很流行的： AI 客服 AI 行銷助理 AI 業務開發員 AI 人資助理 企業開始把一部分工作交給 AI，並且用人類熟悉的職稱來包裝它。這當然不是沒有價值，因為它能降低使用門檻，也容易讓組織理解「誰負責什麼」。 但如果停在這裡，我們其實只是把原本的人類組織數位化：人類客服變成 AI 客服，人類業務變成 AI 業務，舊有的交接方式與 SOP 仍然存在。 第三階段：AI 流程化真正有意思的轉變，是問題從： 哪一個工作可以交給 AI？ 變成： 哪一整段流程可以交給 AI？ 例如，以前客戶詢價可能要經過： 12345678910客戶填表單→ 行政整理資料→ 業務確認需求→ 查詢 CRM→ 找產品資料→ 計算價格→ 主管確認→ 製作報價→ 寄出 Email→ 三天後追蹤 如果 AI Agent 可以跨網站、CRM、Email、資料庫與內部系統工作，那麼我們為什麼還需要按照原本的十個步驟走？ Agent 收到需求之後，可以自己理解問題、取得資料、計算價格、產生報價、更新 CRM、寄信，甚至安排下一次 Follow-up。這時候 AI 取代的已經不是某一個人，而是一整段工作流。 想進一步理解企業如何把不同 AI 能力組合成工作流，也可以參考企業工作自動化不只有 ChatGPT：6 大 AI 自動化能力解析。 第四階段：不是自動化流程，而是刪掉流程這可能才是未來企業 AI 導入真正拉開差距的地方。 很多企業現在談 Automation，做的事情其實是：原本有十個步驟，想辦法讓 AI 自動跑完這十個步驟。 但更值得問的是：這十個步驟真的有必要存在嗎？ 為什麼需要填這張表？因為以前行政人員需要整理。 為什麼要整理成 Excel？因為主管需要查看。 為什麼主管需要查看？因為他要決定下一步。 如果 AI 能直接讀取原始資料、理解內容、做出判斷，再依照規則執行下一步，這張表還需要存在嗎？ 那張表可能根本不需要存在，那份 Excel 可能不需要存在，甚至某些簽核、資料搬運與中間系統也可能不需要存在。 這時候真正省下來的，不只是「一個員工的薪水」，而是以下這些長期累積的成本： 等待與排隊 跨部門轉交 資料重打 格式轉換 跨系統搬運 重複確認與溝通 自動化是讓舊流程跑得更快；AI 原生設計則可能直接讓其中一部分流程消失。 第五階段：AI 原生組織如果繼續往前推，我甚至懷疑「AI 員工」這個詞本身都可能變得很奇怪。 真正成熟的 Agent，不一定需要固定職稱。今天它幫你研究市場，下一秒寫一支程式取得資料，接著分析資料；發現缺少工具，就自己建立工具，然後操作 CRM、更新網站、寄出 Email，再把結果整理給你。 你很難說它到底是工程師、研究員、行銷、業務，還是行政。它只是為了完成一個 Goal，動態呼叫自己需要的能力。 這也解釋了為什麼我最近越來越關注 Agent Harness。模型只是大腦，真正決定 AI 能做到多少事情的，還包括： 元件 在 AI 原生組織中的作用 Model 理解、推理與產生下一步行動 Context 提供目前任務、專案與環境所需的背景 Memory 保留可重複使用的歷史資訊與工作狀態 Skills 封裝特定領域的做法、規則與判斷方式 Tools 讓 Agent 搜尋資料、操作檔案、呼叫 API 或使用服務 Permissions 限制哪些資料與操作可以被存取 Workflow 定義任務如何拆解、串接與交接 Evaluation 驗證結果是否符合品質與安全要求 Harness 把上述能力組合成可持續執行的工作環境 因此，未來我們管理的可能不是「我有幾個 AI 員工」，而是： 為了完成這個目標，我可以調度多少模型、Skills、Tools、Memory、資料、權限與 Agent？ 如果想深入了解 Skill 與 Harness 的差別，可以閱讀Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness。 AI 導入真正該計算的 ROI：消滅多少工作我開始覺得，AI 導入真正的 ROI，不應該只算「取代多少人」，而應該算「消滅多少工作」。 這兩件事情完全不同。 一家公司可能完全沒有裁員，但原本每個月需要 500 小時的行政流程，最後只剩下 50 小時。那些人力並沒有消失，而是可以轉去做客戶關係、產品、策略、創意，以及真正需要人類判斷的事情。 這種轉變的價值，不只是節省薪資，還包括： 更短的回應時間 更少的交接錯誤 更即時的決策 更少的重複溝通 更高比例的時間投入在高價值工作 所以，評估 AI 專案時，可以把問題從「省了幾個人」改成以下幾個更接近實際營運的問題： 這段流程原本每月消耗多少工時？ 有多少時間只是等待、搬運、重打與確認？ AI 導入後，哪些步驟可以合併或直接刪除？ 哪些決策仍然需要人類核准？ 省下來的時間是否真的被轉移到更高價值的工作？ 這樣算出來的 ROI，會比單純計算「少請一個人」更接近 AI Transformation 的真實價值。 重新設計公司，而不是替換組織圖上的人所以我現在反而不太想問：「我要哪一個 AI 員工？」 我會想問另外一個問題： 如果今天重新建立這家公司，而且一開始就知道 AI Agent 存在，我還會設計出現在這套組織與 SOP 嗎？ 很多公司的答案可能是不會。 因為很多工作、職位與流程，其實都是過去技術限制下形成的產物。當限制改變，組織本身也應該重新設計。 可以把傳統問法改成這樣： 傳統問法 AI 原生問法 我需要哪一個 AI 員工？ 我需要完成哪一個 Goal？ 哪個部門負責這件事？ 完成任務需要哪些資料與權限？ 哪個人接手下一步？ 哪個 Agent 或工具可以直接承接？ 如何讓十個步驟自動執行？ 哪些步驟可以合併或消失？ 我有幾個 AI 員工？ 我能調度多少能力來交付結果？ 如果最後只是把「人類客服 → AI 客服」、「人類業務 → AI 業務」、「人類行政 → AI 行政」、「人類行銷 → AI 行銷」全部替換一次，那可能只是把舊公司的組織圖重新畫了一遍。 真正的 AI 原生企業，可能連那張組織圖都不一樣。 一人公司的下一步：建立 AI Operating System對一人公司來說，未來也不一定是一個老闆帶著十個有名字、有頭像、有職稱的 AI 員工。 更可能是：一個人擁有一套可以根據目標，動態組合模型、Agent、Skills、Tools、Memory 與工作流程的 AI Operating System。 在這種架構裡，人的角色不一定是每天親自執行所有步驟，而是： 定義想完成的目標 設計可接受的規則與權限 建立可重複使用的 Skills 決定哪些節點需要人工核准 檢查結果品質與風險 把省下來的時間投入關係、創意與決策 這和「用 AI 取代所有人」是兩件不同的事情。前者是重新設計工作的系統，後者只是把裁員當成導入 AI 的唯一答案。 結語：AI 改變的可能是公司存在的方式不要只是拿「職缺」去想像 AI，也不要只是用 AI 重現今天的公司。 真正值得思考的是： 如果 AI 的能力沒有被現在的職稱與 SOP 限制，我公司的哪些工作，甚至哪些流程，可以直接消失？ 因為 AI 真正可能改變的，從來不只是某一個人的工作，而是我們過去認為「公司本來就應該這樣運作」這件事情本身。 常見問答 (FAQ)Q1：AI 員工和 AI 流程有什麼不同？AI 員工通常以人類職稱或部門為單位，模擬客服、業務或行政等角色；AI 流程則以「完成一個目標」為單位，讓 Agent 跨越多個系統與職能，直接處理一整段工作。 Q2：企業導入 AI，應該先從哪裡開始？應先盤點一段完整的端到端流程，記錄其中的交接、等待、資料重打、重複確認與人工決策，再選擇低風險、規則清楚的流程做小範圍試點，而不是先購買一個對應職稱的 AI 工具。 Q3：是不是所有流程都應該自動化？不是。導入 AI 前應先檢查每個步驟是否仍有存在必要，能合併或刪除的流程不必自動化；涉及高風險決策、法律責任、資金交易或個資的節點，仍應保留適當的權限控管與人工核准。 Q4：什麼是 AI 原生組織？AI 原生組織不是把每個人類職位各自換成一個 AI，而是以目標為中心，動態調度模型、Agent、Skills、Tools、Memory、資料、權限與工作流程來交付結果。 Q5：AI 原生組織會讓人類完全失去工作嗎？不一定。更合理的目標是消除低價值、重複與等待型工作，讓人類把時間轉向客戶關係、產品、策略、創意與需要責任判斷的任務。是否減少人力，取決於企業的策略與治理方式，不是 AI 導入的唯一衡量標準。

  • article-【AI 幫你做網站還不夠：下一代網站，應該讓 AI Agent 能直接操作】

    2026/9/7

    AI自動化 AI Agent Vibe Coding
    【AI 幫你做網站還不夠：下一代網站，應該讓 AI Agent 能直接操作】

    最近看到有人分享「MCP 網站」的概念。 他舉了一個很直覺的例子： 以前網站做好之後，想改一個標題、換一段服務說明，可能還得登入後台，甚至重新找工程師；但網站接上 MCP 之後，可以直接告訴 AI： 把首頁這段改成今年的活動內容。 AI 就能直接替你處理。 一開始我也在想： 現在 ChatGPT、Codex、Claude Code 都已經可以幫我們做網站了，那我用 AI 做出來的網站，不就算 MCP 網站嗎？ 深入拆解後，我才發現這其實是兩件完全不同的事。 而且真正值得注意的，不只是 MCP。它背後其實正在浮現一種新的網站架構： Agent-native Website。 也就是網站不再只設計給「人」操作，同時也開始設計給「AI Agent」操作。 這可能會是 Vibe Coding 下一個很值得注意的發展方向。 AI 幫你做網站，不等於 MCP 網站先釐清第一個最容易混淆的地方。 假設今天我跟 ChatGPT Sites、Codex 或 Claude Code 說： 幫我做一個品牌官網。 AI 幫我完成： 首頁 商品頁 表單 後台 資料庫 部署 這叫做 AI-assisted Website Development，也就是「AI 幫我做網站」。 但網站上線之後，如果 AI 沒辦法透過標準介面去讀取、查詢、修改與操作網站，那它並不會因為是 AI 做的，就自動變成「MCP 網站」。 這兩件事情必須分開： AI 幫你建立網站≠AI 可以操作網站 前者解決的是「開發」；後者解決的是「營運」。 我反而覺得，後者可能更值得關注。 MCP 到底在網站裡扮演什麼角色？MCP 是 Model Context Protocol 的縮寫。如果用很簡化的方式理解，可以把它想成： 讓 AI Agent 知道外部系統有哪些能力，並且可以使用這些能力的一套標準介面。 傳統網站通常長這樣： 123456789使用者 ↓Browser ↓Frontend ↓Backend / API ↓Database 管理網站的人則可能走另一條路： 1234567管理者 ↓/admin ↓Backend ↓Database 所以網站其實一直都是： Human-first。 所有東西都是設計給人點的：按鈕、選單、表單、Dashboard 與 CMS。 但 MCP 加進來後，會多出另一個入口： 123456789AI Agent ↓MCP Client ↓MCP Server ↓Website Services ↓Database / CMS / API 這時候 AI 不需要像人一樣： 登入後台 → 找到文章 → 點編輯 → 修改 → 按發布。 它可能直接呼叫： 1234567get_pages()update_page()create_article()get_products()update_product()get_orders()get_analytics() 這才是 MCP 真正有意思的地方。 MCP 不是裝在網站前台這也是我一開始很容易誤解的地方。 既然叫「MCP 網站」，是不是代表要在網站裡面裝一個 MCP？ 其實不應該這樣理解。比較好的架構應該是： 12345678910 ┌─ Website Frontend │Website Services ──────┼─ Admin │ ├─ REST API │ └─ MCP Server ↑ │ AI Agent Frontend 是給消費者使用。 Admin 是給管理者使用。 API 是給其他程式使用。 MCP 則是提供給 AI Agent。 所以我反而比較喜歡一個更精準的名稱： MCP-enabled Website。 因為 MCP 並不是「網站本身」，而是網站額外提供的一個 Agent Interface。 MCP 跟 API 到底差在哪裡？這也是另一個很常見的問題。 既然網站本來就有 API： 123GET /api/productsPOST /api/articlesPATCH /api/pages/123 為什麼還需要 MCP？ 因為 API 主要是設計給： 程式使用。 MCP 則更進一步讓： AI Agent 理解這個系統有哪些能力，以及什麼時候該使用它。 例如原本網站有： 1GET /api/orders 可以再包裝成 Agent 容易理解的工具： 1234get_orders({ date, status}) 並且描述： 取得指定日期與狀態的網站訂單。 Agent 就比較容易知道：「當使用者問我昨天有哪些訂單時，我應該使用 get_orders。」 因此底層甚至可以完全共用同一套 Service，差別主要在於介面服務的對象不同： 1234567API ↓Program InterfaceMCP ↓Agent Interface 真正重要的其實是 Service Layer這是我研究完後，覺得 Vibe Coding 特別應該注意的一件事情。 很多人用 AI 做網站，很容易把所有商業邏輯直接寫進 UI： 12345Button ↓onClick() ↓Database 網站當然還是可以跑。 但以後想串 API、手機 App、Agent 或 MCP，就會變得很麻煩。 所以如果現在重新設計我的 Vibe Coding 網站 SOP，我會要求 Codex 或 Claude Code： 所有核心商業功能不得只存在於 UI Event Handler，必須抽象成可重複呼叫的 Service Layer，為未來 REST API、MCP Server 與 AI Agent 操作預留介面。 例如： 12345678getProducts()getOrders()getCustomers()createArticle()updateArticle()updateProduct()getAnalytics()updateHomepage() 最後變成： 123456789101112Frontend ↓ ┌────────┐Admin ─────────→│ Service│←──────── REST API │ Layer │ └────┬───┘ ↑ │ MCP ↑ │ AI Agent 這樣即使今天沒有 MCP，網站本身也已經 Agent Ready。未來要增加 MCP，就不需要把整個網站重新打掉。 如果你正在設計自己的 AI Coding 工作流，也可以延伸閱讀Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness；它能幫助你理解 Model、Context、Tools、Skills 與權限如何組成一個可持續工作的 Agent 系統。 從 AI Website 到 Agent-native Website：五個階段我現在會把這件事情分成五個 Level。 Level 1：AI 幫你做網站12345人 ↓ChatGPT Sites / Codex / Claude Code ↓Website AI 是開發工具，網站本身仍然是傳統網站。 Level 2：AI 幫你修改網站例如： 1234567891011你 ↓Codex ↓GitHub ↓修改程式碼 ↓Commit ↓Cloudflare / Vercel 這已經很好用了，但仍然比較接近 AI Software Engineering，而不是 Agent-native Website。 Level 3：MCP-enabled Website開始讓 AI Agent 直接使用網站能力： 1234567你 ↓AI Agent ↓MCP ↓Website Services 例如： 把首頁的活動改成櫻桃季。 Agent 不一定需要修改程式碼，而是直接呼叫： 123get_campaign()update_campaign()update_homepage() 這時網站才真正開始「AI 可操作」。 Level 4：Agent-native Website這一層就更有意思了。 網站從設計第一天就同時考慮兩種使用者： Human + AI Agent。 架構可能變成： 1234567891011121314┌──────────────────────────┐│ Human Interface ││ ││ Frontend /admin │└─────────────┬────────────┘ │ Website Services │ ┌────────┼────────┐ ↓ ↓ ↓ Database API MCP ↑ │ AI Agents 這時候網站已經不只是一堆網頁，而是一組： 可以被人使用，也可以被 Agent 呼叫的商業能力。 Level 5：Self-Optimizing Website再往前一步，Agent 不只操作網站，還可以持續監測、分析、提出修改建議，並在人工核准後執行優化。 這時網站開始具備一個新的循環： 12345678910111213監測 ↓分析 ↓提出建議 ↓人工核准 ↓修改網站 ↓重新驗證 ↓持續追蹤 這條演進路線，也可以和我先前整理的 MCP、Skill 與 CLI 差異一起閱讀：前者偏向網站如何成為 Agent 可操作的系統，後者則整理 AI 工具各自扮演的角色。 Brand Agent：網站營運者不一定是人拿「鮮生小姐」來想，就會非常具體。 例如我自己的實驗專案「鮮生小姐」，未來如果把網站 Agent 化，可以提供： 12345678910get_productsupdate_productget_campaignscreate_campaignget_articlescreate_articleget_homepageupdate_homepageget_customer_inquiriesget_site_analytics 於是我不一定要登入網站後台，而是直接告訴自己的 Brand Agent： 櫻桃季快到了，幫我檢查網站有哪些內容應該更新。 Agent 可以先查詢： 1234get_productsget_campaignsget_homepageget_articles 然後告訴我： 首頁還在主推上一檔活動。 櫻桃商品頁的產季資訊需要更新。 今年還沒有建立送禮相關內容。 我再說： 幫我準備新版，但先不要發布。 Agent 建立 Draft。 我確認： OK，發布。 Agent 再透過 MCP 更新。 這時候 AI 已經不是「網站製作工具」，而是開始變成： 網站營運者。 甚至，鮮生小姐的擬人化 AI 代言人 Cherry，也可以不只是品牌角色，而是 Brand Agent。 她可以同時理解： 網站資料 訂單 商品 內容 Analytics SEO、AEO 與 GEO 接著回答： 最近櫻桃禮盒頁面的流量上升，但轉換率下降，我建議調整首頁 CTA，另外建立一篇今年櫻桃送禮指南。 這時候 IP 就開始從「虛擬代言人」進化成「可以工作的 AI 員工」。 SEO、AEO、GEO、AXO 與 MCP 如何串起來？我最近本來就在研究另一件事情：網站到底要怎麼讓 AI 更容易找到、理解、引用？ 傳統網站第一層還是 SEO，例如 Title、Meta、H1-H3、Schema、內部連結與網站效能等。 接著進入 AEO／GEO，要思考的不只是排名，而是： AI 能不能理解並引用我的內容？ 所以內容開始需要注意： 是否直接回答問題。 是否有明確定義。 是否標示來源、作者與更新日期。 段落能不能獨立理解。 是否有問題式標題。 是否提供比較與步驟。 是否有真正的原創經驗與案例。 再下一層則是 AXO： AI Agent 能不能理解這個網站？ 最後再往下一層： AI Agent 能不能操作這個網站？ 這時候 MCP 就出現了。 我開始把整套網站優化流程重新理解成： 12345678910111213141516171819Website ↓SEO讓搜尋引擎找到 ↓AEO / GEO讓 AI 理解、引用 ↓AXO讓 Agent 理解網站與能力 ↓Agent Ready整理 Service / API / 權限 ↓MCP-enabled讓 Agent 可以操作 ↓Agent Automation讓 Agent 可以持續工作 這可能會變成我以後做網站時的新 SOP。 如果想先理解 AXO 與 WebMCP 的差異，可以閱讀SEO、AEO 之後的 AXO：讓 AI Agent 真正完成網站任務。那篇文章偏向 Agent Experience 與任務完成；本文則進一步把焦點拉到網站內部的 Service、MCP 與營運治理。 Self-Optimizing Website：網站自己優化自己我原本就在規劃 AI 搜尋能見度健檢工具。 不是只給一個「GEO 72 分」，而是實際測量品牌是否被 AI 提及、是否被列為推薦選項、引用哪個頁面，以及競品出現頻率。 以前做到這裡，下一步通常是： 12345發現問題 ↓產生報告 ↓交給人修改 如果加入 Agent + MCP，流程就可能變成： 12345678910111213141516171819SEO / AEO / GEO Agent ↓掃描網站 ↓發現問題 ↓提出修改方案 ↓Human Approval ↓MCP ↓修改 Website ↓重新檢測 ↓記錄結果 ↓持續追蹤 例如 AI 發現「櫻桃送禮推薦」這個頁面被 AI 引用率偏低，就可以分析原因，建議增加： 比較表 FAQ 作者資訊 原創資料 更明確的答案段落 人工核准後，Agent 再修改網站，重新測試 ChatGPT、Gemini 或 Claude 等 AI 能見度，一個月後比較變化。 這時候網站就不只是「做好 → 上線 → 放著」，而是： 監測 → 分析 → 建議 → 修改 → 驗證 → 再優化。 MCP 很可能就是這個循環中缺少的最後一塊： Execution Layer。 Agent 權限不能全部開放當 AI 可以直接操作網站後，問題也跟著出現。 例如： 12345delete_customerrefund_orderchange_pricepublish_pagedelete_product 如果全部交給 Agent 自由操作，風險太高。 所以我認為 Agent-native Website 至少應該把權限拆成四層： 權限層級 可以做什麼 建議治理方式 Read 查詢文章、商品、訂單與流量 可讓 Agent 自動處理 Draft 建立文章草稿、活動草稿與 SEO 修改建議 可自動建立，但不直接發布 Write 修改商品、內容與首頁 視情況授權，必要時要求確認 Critical 刪除資料、退款、修改權限與重要交易 必須 Human Approval 而且所有 Agent 操作都應該留下 Audit Log： 123456Agent: SEO-AgentAction: update_pagePage: /cherry-giftReason: AEO OptimizationApproved by: SeanTime: 2026/09/07 08:30 這才會是一個真正能進企業環境的 Agent 架構。 網站後台可能會被重新定義以前 CMS 解決的是： 不會寫程式的人，怎麼修改網站？ 所以我們做出了 WordPress、網站後台與 Page Builder。 但 Agent 時代開始出現另一個問題： 如果我根本不用自己操作後台呢？ 我只需要說： 把今年所有過期活動整理出來。 先幫我更新成 2026 版本。 發布之前給我看。 這三頁 OK，其他先不要動。 AI 自己完成剩下的工作。 這不代表 /admin 會消失。後台仍然很重要，因為需要： 人工檢視 權限管理 Audit Log 緊急操作 資料校正 但 /admin 可能會從： 主要工作介面 慢慢變成： 管理、監督與治理介面。 真正每天工作的入口，反而可能是 AI Agent。 Vibe Coding 的下一階段，也許不是更快做網站過去兩年大家在比： 誰能更快用 AI 做出網站？ 從幾天做到幾小時，再做到一句 Prompt 就能建立。 但當「建立網站」越來越便宜之後，下一個問題自然會變成： 網站做好之後，誰來經營它？ 所以 Vibe Coding 下一階段可能不是： AI 幫你做網站。 而是： AI 幫你經營網站。 再下一階段甚至是： AI Agent 成為網站的一級使用者。 所以我現在會把這幾個概念清楚分開： 階段 核心能力 AI Website AI 幫你建立網站 AI-maintained Website AI 幫你修改網站 MCP-enabled Website AI 可以操作網站能力 Agent-native Website 網站從架構開始同時為 Human 與 Agent 設計 Self-Optimizing Website Agent 可以監測、分析、改善並驗證網站 這條演進路線，我覺得才是 MCP 對網站真正有趣的地方。 未來做網站，我可能不會再只問： 手機版做好了嗎？ SEO 做好了嗎？ AEO／GEO 做好了嗎？ 還會多問兩個問題： 這個網站 Agent Ready 了嗎？ 以及： 我的 AI Agent，可以安全地替我操作這個網站了嗎？ 當答案是 Yes 的時候，這個網站才真正從一個「網頁集合」，開始變成一個： 可以被 AI 理解、呼叫、操作，甚至持續改善的數位商業系統。 結語：下一代網站要問的是 Agent 能不能使用我？以前我們做網站，會問： Google 搜不搜尋得到我？ 後來我們開始問： ChatGPT 會不會理解並推薦我？ 接下來真正重要的問題可能是： 當 AI Agent 選擇了我，它能不能順利使用我？ 這就是： SEO → AEO → AXO。 從被搜尋，到被理解，再到被執行。 MCP 值得注意的地方，也不只是多了一個網站 API，而是它讓我們看見一種可能：Web 正在開始為 AI Agent 重新設計。 未來網站的競爭力，不只在於誰的介面漂亮、SEO 做得好或內容寫得完整，也可能取決於： 你的網站，準備好被 Agent 使用了嗎？ 常見問答 (FAQ)Q1：AI 幫我做網站，就代表這是 MCP 網站嗎？不代表。AI 幫你建立網站屬於 AI-assisted Website Development；只有當網站提供可供 AI Agent 理解、查詢與操作的標準化介面時，才更接近 MCP-enabled Website。 Q2：MCP 和一般 API 有什麼差別？API 主要提供程式呼叫的介面；MCP 則進一步描述系統有哪些能力、工具何時適用、需要哪些參數，以及操作結果如何回傳，讓 AI Agent 更容易選擇並使用。 Q3：為什麼網站需要 Service Layer？Service Layer 能把核心商業邏輯從前端按鈕與 UI Event Handler 抽離，讓同一套能力可以被 Frontend、Admin、REST API 與 MCP 共用，降低未來擴充 Agent 操作的成本。 Q4：Agent-native Website 可以讓 AI 自由修改所有資料嗎？不建議。網站應至少區分 Read、Draft、Write 與 Critical 權限；查詢與建立草稿可以較高程度自動化，修改、發布、退款、刪除資料或變更權限等高風險操作則應保留人工核准與 Audit Log。 Q5：網站要如何開始準備 Agent-native 架構？可以先盤點使用者最常想完成的任務，再把商品、服務與限制條件整理成一致且可理解的資料，接著抽離可重複呼叫的 Service Layer，設計 API、工具描述、權限、確認與錯誤回應，最後用完整任務測試 Agent 是否真的能完成流程。