跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

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

分類

標籤

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

  • article-AI 時代，40 歲後最值錢的不是經驗，而是把經驗「編譯」成 AI 能執行的能力

    2026/9/6

    AI自動化 AI Agent 內容行銷
    AI 時代，40 歲後最值錢的不是經驗，而是把經驗「編譯」成 AI 能執行的能力

    最近看到一篇文章，裡面有一句話讓我想了很久： AI 愈強，40 歲以後累積的人生經驗，反而愈值錢。 我很認同，但我覺得這件事還可以再往下一層。 未來真正值錢的，可能不只是「你有多少經驗」，而是： 你能不能把自己的經驗，編譯成 AI 可以執行的能力？ 做了 20 年，不代表擁有 20 年的專業我們很容易把「年資」跟「經驗」畫上等號，但其實不一定。 有人工作 20 年，只是把第一年的工作方式重複了 20 次。也有人工作 5 年，卻做過幾百個案子、碰過不同產業、失敗過很多次，也不斷修改自己的做法。 所以真正形成差距的，可能不是年齡，而是你的「判斷密度」： 你看過多少不同案例？ 遇過多少種問題？ 做錯過多少決定？ 後來為什麼改變做法？ 什麼情況下 A 有效？什麼情況下你反而會選 B？ 這些東西才慢慢形成所謂的專業判斷。 AI 不必活過你的經驗，才能使用它很多人會說： AI 可以讀很多資料，但是 AI 沒有真正活過。 這句話現在沒有錯，可是我覺得不能因此太樂觀。 因為 AI 根本不需要自己活過。一個顧問做 20 年，可能服務過 500 個客戶；未來的 AI，則可能讀過大量案例、研究報告、客戶對話、論壇討論、專案紀錄與失敗經驗。 因此真正難被取代的，不應該只是「這件事情我做過」，而是： 我做過很多次之後，形成了一套別人沒有的判斷方式。 更重要的是，這套判斷有沒有辦法被留下來、被驗證，甚至被重複執行。 從經驗到 Skill：把判斷編譯成 AI 能執行的能力這是我最近研究 AI Agent、Skills、MCP 與 Agent Harness 時，愈來愈強烈的一個感覺。 以前一個專家累積很多經驗之後，大概有幾種做法：寫書、寫文章、開課或做顧問。因為我們能做的，通常就是把腦袋裡面的知識說出來。 但現在多了一條完全不同的路： 經驗 → 判斷 → Framework → SOP → Skill → Agent 這不是把文章換一個檔案格式，而是把「在什麼情況下，做什麼判斷，接著採取什麼行動」整理成可執行的結構。 先問對問題，再決定要不要用 AI例如，一家企業來找我說： 我們想導入 AI 客服。 剛接觸 AI 的人，可能第一個問題是：要用 GPT、Claude 還是 Gemini？ 但如果做過很多專案，你可能第一個問題根本不是模型，而是： 每天有多少客服量？ 哪些問題一直重複？ 哪些回答需要查公司資料？ 哪些情況涉及訂單或交易？ 哪些事情 AI 絕對不能自己決定？ 什麼時候必須轉真人？ 問完之後，你才會判斷：這家公司需要的是 FAQ、RAG、Workflow、Agent，還是根本暫時不需要 AI。 注意一件事情：這已經不只是「經驗」了，它其實是一棵 Decision Tree。 如果我們把每一個問題、條件、判斷與下一步整理出來，就有機會先寫成 SOP，再進一步變成 Skill，最後交給 Agent 執行。原本只能存在資深顧問腦袋裡的能力，第一次開始可以被軟體化。 如果你想先了解如何把長篇提示詞整理成可重複使用的 Skill，可以參考從提示詞到 Skill：5 個實務做法打造高效率 AI 自動化工作流。 Experience Debt：專業沒有被留下來的代價我最近想到一個詞：Experience Debt，經驗債。 很多做了十幾、二十年的專業工作者，其實非常有價值，但那些價值散落在： 腦袋裡 LINE 對話裡 Email 裡 簡報裡 客戶會議裡 課堂回答裡 客戶問一個問題，你馬上知道答案；新人做錯一件事情，你一眼就知道問題在哪裡。但是如果有人問：「為什麼你知道？」你可能只能回答： 做久了就知道。 這句話其實很危險，因為它代表這套能力還沒有被結構化。 你知道，但是你的團隊不知道；你的學生不知道；甚至 AI 也不知道。AI 無法使用你沒有留下來的經驗。 所以很多 40、50 歲的專業工作者，第一件事情不一定是急著經營自媒體，而是開始把自己的腦袋數位化。 不只建立內容庫，而是建立 Judgment Library以前我們經營自媒體，很習慣建立文章庫、影片庫、素材庫與 Prompt 庫。但我覺得下一階段更重要的是： Judgment Library——判斷庫。 例如，每次做完一個案子，我們都可以留下這些句子： 大家通常以為是 A，但我後來發現其實是 B。 遇到 X 情況，我通常不建議做 Y。 如果客戶同時出現這三個條件，我會優先選擇 Z。 以前我也相信這個做法，但做過幾十次之後，我改變想法了。 這些句子看起來很普通，卻是專業人士腦袋裡最值錢的東西。因為 Google 找得到答案，AI 也可以整理知識；但是「什麼情況應該用哪一個答案」，才是真正的判斷。 一個可以持續累積的判斷紀錄格式每次完成專案後，不必寫成完整文章，先留下以下六項就足夠： 欄位 要記錄的內容 情境 當時遇到什麼問題、對象與限制？ 常見假設 多數人第一時間會怎麼想？ 觀察證據 哪些案例、結果或訊號改變了你的看法？ 核心判斷 你最後選了什麼做法？為什麼？ 適用邊界 什麼情況下這個判斷不成立？ 下一步 如果再遇到類似情境，第一個要做什麼？ 當這些紀錄累積到一定程度，就能看見反覆出現的條件、例外與決策順序。那時候才有機會把零散經驗整理成真正可用的 Framework。 個人品牌會從內容入口，走向可執行產品這也會改變我們經營個人品牌的方法。 以前做內容，我們會問：「今天要寫什麼？」以後可以多問三個問題： 這件事情讓我形成了什麼判斷？ 這個判斷什麼時候成立，什麼時候不成立？ 這個判斷能不能變成 AI 可以執行的規則？ 久了以後，你累積的可能就不只是 500 篇 Facebook 文章，而是一套能力鏈： 層次 主要作用 可能形成的產品 案例庫 記錄真實情境與結果 案例資料庫 觀點庫 說明你如何理解問題 文章、影片與課程 判斷庫 說明何時採用哪個做法 決策規則 Framework 把判斷整理成可重複的方法 顧問方法論 Skill 把方法寫成 AI 可遵循的指令與檢查 可執行模組 Agent 讓 AI 使用工具、處理情境並完成工作 AI 服務 內容只是入口，Framework 是方法，Skill 是產品，Agent 則可能成為服務。 未來我們可能不是「賣知識」，而是在「出租判斷」以前專家的商業模式很簡單： 顧問：「我幫你判斷。」 講師：「我教你怎麼判斷。」 作者：「我把我的判斷寫給你。」 AI 時代開始多出第四種可能： 我把我的判斷方式封裝成 AI，讓它持續替你處理相似問題。 這代表一個人的專業能力，第一次可以從「內容產品」變成「可執行產品」。以前一本書賣的是知識，一堂課賣的是方法；未來一個 Skill 或 Agent，賣的可能是專家的判斷能力。 這不代表把所有決定都交給 AI。真正成熟的 Skill，應該同時寫清楚適用條件、禁止事項、需要查證的資料，以及什麼時候一定要交還給人處理。 從 SEO、AEO 到 Agent：讓 AI 不只引用你，也使用你這也是我覺得個人 IP 下一階段很有趣的地方。 SEO 時代，我們努力讓人搜尋到你。 AEO 時代，我們開始思考讓 AI 引用你。 Agent 時代，可能還會再往下一步：讓 AI 使用你。 不只是讓 ChatGPT 回答問題時說「某某專家曾經提出……」，而是當 AI Agent 遇到某個問題時，直接呼叫你的 Framework、Skill 或工具來完成工作。 到了那一天，衡量一個專業工作者影響力的方式，可能也會改變。除了粉絲、瀏覽與訂閱，還可能包括： 你的 Framework 被多少 Agent 使用？ 你的 Skill 一天被呼叫多少次？ 你的判斷模型參與了多少真實世界的決策？ 這些仍是需要持續觀察的未來可能，但方向已經值得現在開始準備。 40 歲後，現在可以從哪裡開始？如果你已經累積十年、二十年的專業，不必一開始就做一個完整 Agent，可以先從以下五步開始： 每週留下一個案例。 不只記錄做了什麼，也記錄當時為什麼這樣做。 把「反直覺判斷」寫下來。 特別是大家以為 A、你卻選 B 的時刻。 補上成立條件與例外。 沒有邊界的經驗，無法安全地交給 AI 執行。 找出重複出現的判斷。 把它整理成 Framework，再寫成 SOP 或 Skill。 保留必要的人類審核。 涉及金流、個資、合約、品牌風險或重大決策時，先設定清楚的交接點。 如果你想延伸理解「專業如何被留下來並形成個人品牌資產」，可以參考AI 時代，你真正該累積的不是內容，而是「專業證據」；若想進一步理解 Agent 如何在工具與權限邊界內完成工作，也可以閱讀Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness。 結語：把二十年的自己，編譯成 AI 可以執行的能力如果你問我：AI 愈來愈強，我們累積十年、二十年的經驗還有沒有價值？ 我的答案當然是有，但我會再多補一句：不要只滿足於「我有經驗」。 因為經驗如果永遠只存在你的腦袋裡，它的延展性仍然非常有限。 真正值得做的，是開始把： 經驗變成判斷，判斷變成方法，方法變成 Skill，Skill 再變成 Agent。 以前我們花了二十年，讓自己成為一個更厲害的專家。接下來也許要開始思考另一件事：怎麼把這二十年的自己，編譯成 AI 可以執行的能力。 我覺得這才是 AI 時代，「資深」真正厲害的地方。 常見問答 (FAQ)Q1：40 歲後累積的經驗，如何轉化成 AI 時代的競爭力？關鍵不是單純累積年資，而是把案例、錯誤、選擇理由與適用邊界整理成專業判斷。當判斷能被寫成 Framework、SOP 或 Skill，就能被團隊、AI 與 Agent 重複使用。 Q2：什麼是 Experience Debt（經驗債）？Experience Debt 是指專業價值散落在個人腦袋、對話、Email、簡報與會議裡，卻沒有被整理成團隊或 AI 可理解的結構。它會讓個人知道怎麼做，但其他人無法複製，也讓 AI 無法使用這些經驗。 Q3：Judgment Library（判斷庫）和一般內容庫有什麼不同？內容庫主要保存文章、影片或知識；判斷庫則保存「什麼情況應該選哪個做法、為什麼，以及什麼時候不適用」。判斷庫的核心是條件、取捨、例外與下一步，而不只是答案本身。 Q4：要先學會 GPT、Claude 或 Gemini，才能把經驗做成 Skill 嗎？不一定。文章中的重點是先整理問題、判斷條件、禁止事項與交接邊界，再決定適合的模型或工具。若沒有清楚的方法，換模型通常只會把同樣混亂的流程交給另一個系統。 Q5：AI 可以讀過大量案例，專業人士還能靠什麼建立差異？「我做過這件事」本身不是最穩固的護城河；更有價值的是你從大量案例中形成的判斷方式，以及能清楚說明成立條件、例外與取捨的專業模型。這些內容被留下並可執行後，才有機會形成可持續的差異。

  • article-AI 時代，你真正該累積的不是內容，而是「專業證據」

    2026/9/6

    AI Agent AEO 內容行銷
    AI 時代，你真正該累積的不是內容，而是「專業證據」

    最近看到一篇文章，裡面有一句話讓我想了很久： 「以後客戶可能先問 AI，再決定找誰。」 以前我們經營個人品牌，想的是： 我要不要寫文章？ 這篇有多少人看？ 有多少讚？ 有沒有被分享？ 粉絲有沒有增加？ 但如果未來大家尋找專家、顧問、講師、合作夥伴的方式，慢慢從 Google 搜尋變成直接問 ChatGPT、Gemini、Claude： 「台灣有哪些懂 AI Agent 的講師？」 「推薦熟悉 LINE API 的顧問。」 「有沒有懂中小企業 AI 導入的人？」 「誰真的做過 MCP 的企業應用？」 那問題就完全不一樣了。 因為這時候你真正要問的，不再只是： 「有多少人看過我？」 而是： 「網路上有多少證據，可以證明我真的懂這件事？」 這也是我最近研究 AEO、AXO、AI Agent、Skill，以及「專業知識軟體化」之後，開始慢慢串起來的一件事。 當客戶先問 AI，個人品牌的問題就變了假設有兩個顧問。 A 做了 15 年，能力很好、服務過很多客戶，也解決過很多困難的問題。 但是這 15 年的經驗，全部存在他的腦袋、LINE 對話、會議紀錄和客戶現場，網路上幾乎沒有東西。 另一個 B 同樣做了 15 年，但他持續留下： 自己的專業判斷 實際處理過的案例 客戶經常遇到的問題 失敗經驗與修正方式 產業觀察 做完之後得到的新理解 如果今天有人問 AI： 「誰比較擅長處理這類問題？」 我不是說 AI 一定會推薦 B，也不是說公開文章多就代表能力一定比較好。 但是至少有一件事很現實： AI 要理解 A，很困難。 因為沒有足夠的公開資料，讓它辨識 A 的專業範圍、服務經驗與判斷方式。 這讓我開始覺得，未來個人品牌真正重要的資產，可能不是「文章數量」，而是： Professional Evidence：專業證據。 它不是替自己加上的形容詞，而是網路上可以被交叉理解的紀錄：你做過什麼、如何判斷、解決過哪些問題，以及什麼情況下你會選擇不要做某件事。 知識會越來越便宜，但判斷反而越來越值錢以前我們很喜歡寫： 「使用 ChatGPT 的 10 個技巧」 「做 SEO 一定要知道的 7 件事」 「經營 LINE 官方帳號的 5 個方法」 這些內容不是沒有價值，但 AI 已經可以很快整理出一份看起來完整的清單。 所以未來真正稀缺的內容，反而是： 「我做過之後，發現了什麼？」 例如： 「我實際教了幾十個完全不懂程式的人使用 MCP 後，發現大家真正卡住的不是技術。」 這句話就不一樣了。因為後面的答案不是單純從網路整理來的，而是來自你在真實情境中反覆觀察、判斷與修正後的經驗。 所以我現在越來越認為，AI 時代最值得累積的內容，不只是 What，也不只是 How，而是： Why：為什麼要這樣做？ When：什麼情況適合這樣做？什麼情況反而不要？ Which：兩種方法都能用時，為什麼選 A 不選 B？ 再加上：失敗過幾次之後，我改變了什麼判斷？這些才是真正難以被通用答案取代的專業。 如果你想進一步理解如何把領域經驗拆成規則、工作流程與軟體功能，也可以延伸閱讀把專業知識變成軟體：產業專家就是下一代產品經理。 寫案例時，留下完整的判斷軌跡未來寫案例，我覺得不能只寫： 「我們成功幫客戶導入 AI。」 更有價值的案例，應該留下完整的判斷軌跡： 客戶原本以為問題在哪？ 我進去之後發現真正的問題是什麼？ 為什麼我沒有選大家最常用的方法？ 第一次做失敗在哪？ 後來改了什麼？ 最後我得到什麼新的判斷？ 這些東西累積久了，其實已經不是單純的「內容」，而是一個人的： Professional Evidence Database：專業證據資料庫。 它不一定要一開始就做成複雜的系統。你可以先從每次專案結束後，留下五個簡短欄位開始：問題、判斷、選擇、失敗、結果。 專業證據如何變成 Skill 與 AI Agent？這也是我在思考「專業知識軟體化」之後，又往下一層看到的事情。 一個專家的能力，最早存在： 腦袋裡。 接著我們把它： 寫成文章。 再把文章整理成： 結構化知識。 接著把方法、規則、判斷條件整理成： Skill。 最後甚至可以變成： Software / AI Agent。 所以完整路徑可能是： 123456專業經驗→ 專業證據→ 結構化知識→ Skill→ Software→ Agent 這條路徑不是把人變成沒有溫度的自動化機器，而是把原本只能靠口述、陪跑或臨場反應傳承的判斷，整理成可以被檢查、教學與重複使用的資產。 以前一個專家離開現場，他腦袋裡很多東西可能就消失了。但如果你有意識地把判斷、案例、流程、例外狀況與決策邏輯留下來，你的專業就有機會慢慢變成一套「可以被機器使用的能力」。 關於如何讓 Skill 真正支撐 Agent 完成任務，而不只是提供一段漂亮的說明，也可以參考Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness。 每一堂課，都可能是一份真實世界 Dataset這點是我自己特別有感的，因為我經常上課。 以前上完一堂課： 學生問問題 我回答 下課 很多很好的問題，就這樣消失了。 但如果換一個角度，每一個學生問的問題、每一次操作失敗、每一個誤解的地方、每一個成功案例，以及每一次我臨場改變教法的原因，其實全部都是資料。 假設一年上 100 堂課，每堂課只留下 10 個真正有價值的問題，一年就是： 1,000 個真實世界的 AI 應用問題。 這是文章中的假設計算，不是對任何課程成果的宣稱。它想指出的是：你親自面對的問題，往往比你從網路整理來的熱門資訊，更能形成自己的專業辨識度。 新聞大家都有，但這些問題是你在真實工作裡遇到的。 於是整件事情可以形成一個飛輪： 123456789實際工作→ 發現問題→ 專業判斷→ 寫成內容→ 結構化知識→ Skill→ 工具→ Agent→ 再回到真實世界驗證 這已經不只是內容行銷，而是在累積自己的「專業模型」。 從 AEO 走向 Expert AEO：AI 怎麼認識你？現在大家談 AEO、GEO，大部分都在討論： 「怎麼讓品牌被 AI 找到？」 但我覺得下一個值得觀察的方向可能是： Expert AEO。 醫師、律師、講師、顧問、房仲、設計師、會計師、教練，每一個靠專業吃飯的人，未來都可能要開始思考： AI 知不知道我是誰？ AI 認為我擅長什麼？ 網路上有哪些證據支持這件事？ 當使用者問相關問題時，我會不會出現在答案裡？ AI 描述我的方式正確嗎？ 我的競爭者為什麼被提到，而我沒有？ 這甚至可能形成一個新的個人品牌觀察指標： AI Share of Voice。 以前我們追蹤 Google 排名，未來或許可以追蹤： 「在 100 個跟我專業相關的問題裡，AI 有幾次提到我？」 目前「AI Share of Voice」比較適合作為一個觀察框架，不是已經普遍採用的標準指標。它的價值不在於追求每一次回答都被提到，而在於幫你檢查：AI 是否正確理解你的專業範圍、案例與適用情境。 如果想先理解 AI 如何從 SEO、AEO 走向能執行網站任務的 AXO，可以閱讀SEO、AEO 之後的 AXO：讓 AI Agent 真正完成網站任務。 現在就能開始累積的專業證據不要只問： 「這篇文章會不會爆？」 可以換成以下幾個更長期的問題： 這篇文章，有沒有替我的專業多留下一份證據？ 我是否說清楚自己處理過什麼問題？ 我是否留下「為什麼選 A、不選 B」的判斷？ 我是否誠實記錄失敗、限制與不適用情境？ 這份經驗能不能被整理成下一次可重複使用的規則？ 可以從這些內容開始： 專案結束後的決策紀錄 不只寫成果，也寫問題定義與修正過程的案例 課程中反覆出現的真實提問 失敗經驗與不適用情境 對工具、方法與流程的選型理由 讀者可以獨立引用的 FAQ 與定義 流量可能三天就沒了，Facebook 貼文也可能一個星期後就沉下去，演算法更會一直改變。但你留下來的判斷、案例、方法、失敗與成果，可能會慢慢構成 AI 對你的理解。 所以我現在反而覺得： 不要只是經營內容，要開始經營你的 Professional Evidence。 讓網路上有足夠的證據說明： 你是誰 你懂什麼 你做過什麼 你怎麼判斷 以及你能解決什麼問題 再下一步，把這些證據整理成 AI 能理解的知識，再把知識封裝成 Skill，最後讓 Skill 變成 Agent 可以執行的能力。 這可能才是 AI 時代個人品牌真正值得累積的長期資產。 因為未來當客戶問 AI： 「這件事情，我應該找誰？」 真正重要的可能不是你自己說你很專業，而是： 網路上有沒有足夠的證據，讓 AI 也知道你很專業。 常見問答 (FAQ)Q1：什麼是「Professional Evidence」？Professional Evidence，也就是專業證據，指的是能在網路上說明一個人做過什麼、如何判斷、解決過哪些問題，以及哪些情境不適用的公開紀錄。它不等於文章數量，而是由案例、方法、失敗經驗、判斷理由與結果共同構成。 Q2：為什麼個人品牌不能只追求流量與文章數量？流量與文章數量能反映內容的曝光，但不一定能證明作者具備哪一種專業、處理過哪些真實問題，或在不同情境下如何做選擇。AI 時代更需要可理解、可交叉比對的案例、判斷與方法，讓讀者和 AI 都能更準確掌握你的專業範圍。 Q3：一篇有價值的專業案例應該留下哪些內容？至少可以記錄客戶原本認為的問題、實際發現的問題、選擇某種方法的理由、第一次失敗的地方、後續如何修正，以及最後得到的新判斷。這些內容比單純宣稱「成功導入」更能呈現專業思考。 Q4：專業證據如何進一步變成 Skill 或 AI Agent？可以先把案例與判斷整理成結構化知識，再將方法、規則、條件、例外與檢查標準封裝成 Skill。當 Skill 能被軟體或 Agent 呼叫，並在真實工作中反覆驗證與修正時，專業經驗就有機會轉化成可重複使用的 AI 能力。 Q5：什麼是 AI Share of Voice？AI Share of Voice 是本文提出的觀察框架，用來思考在一組與自己專業相關的問題中，AI 有多少次正確提到自己。它目前不是普遍採用的標準指標，不能單獨代表專業能力；更重要的是檢查 AI 是否正確理解你的專業、案例與適用情境。

  • article-Vibe Coding 下一階段：把專業知識變成軟體，產業專家就是下一代產品經理

    2026/8/31

    商業策略 AI Agent Vibe Coding
    Vibe Coding 下一階段：把專業知識變成軟體，產業專家就是下一代產品經理

    最近看到一個很有意思的案例。 一位房仲做了一套 591 競品分析工具。貼上一個 591 網址，就可以自動整理同社區競品、價格、刊登時間與曝光狀況，甚至判斷一間房子到底是「價格有問題」，還是「根本沒曝光」。 有趣的不是這個工具本身，而是他說： 「我一行程式都不會寫。」 但光是其中一個競品分析功能，就有 15 個程式檔案、9,324 行程式，前後修改 75 次；整個系統甚至累積到 3,000 多次修改。他主要靠 Claude Code，把這套東西慢慢做出來。 很多人看到這裡，第一個反應可能是：「現在 AI 真的太強了，不會寫程式也能做 App。」 但我看到的，其實是另外一件更大的事情。 Vibe Coding 真正改變的，可能不是程式設計以前我們談 No-Code、Low-Code，到現在談 Vibe Coding，大家一直在討論： 以後是不是不用學寫程式了？ 但我覺得，這可能問錯問題了。 真正正在發生的是：大量原本只能存在「專家腦袋裡」的東西，開始可以被軟體化。 這才是我認為 Vibe Coding 最重要的改變。 真正值錢的不是那 9,324 行程式假設今天叫一個很厲害的工程師完成「591 資料抓取 → 整理 → Dashboard → 報表」，技術上可能完全沒問題。 但工程師怎麼知道： 刊登超過幾間叫供給過剩？ 多少瀏覽才算曝光不足？ 同一間房子被三個仲介刊登，到底算三筆還是一筆？ 什麼情況代表價格有問題？ 這些東西不是只靠寫程式就能得出來的。它來自一個房仲做過幾百次成交、看過幾千個物件之後，慢慢形成的判斷。 以前我們會叫這種東西「經驗」。但 AI Coding 出現之後，我開始覺得應該換一個角度看： 這些其實都是還沒有被寫成程式的商業邏輯。 未來值錢的能力，是把「我覺得」變成「如果……就……」例如，一個資深房仲可能會說：「這間我一看就知道不好賣。」 以前這句話很難交給電腦。但如果繼續追問「為什麼」，他可能慢慢拆出： 如果同社區待售超過 15 間； 如果價格高於近期成交行情 8%； 如果刊登 30 天但瀏覽不到 500； 如果照片數量低於某個數字； 如果三週都沒有有效詢問； 那麼成交機率就會開始下降。 這時候事情就完全不同了，因為專業經驗可以沿著一條清楚的路徑被轉換： 經驗 → 判準 → 規則 → Workflow → 軟體 這就是我最近越來越在意的一個概念：專業知識軟體化。 AI Coding 的最大機會，不是讓所有人變成工程師真正的機會是：讓每一個產業專家，都第一次有機會把自己的 Know-how 變成軟體。 所以，接下來很有優勢的可能不只是最會寫程式的人，也包括： 做了 20 年帳務的會計師； 看過幾千個案件的律師； 成交過幾百間房子的房仲； 教過幾千個學生的老師； 做過幾百個廣告專案的行銷人； 跑過幾百間工廠的顧問。 以前這些人的專業很難複製，因為 Know-how 在腦袋裡。新人只能跟著老師傅看、問、學、犯錯，再慢慢累積經驗。 但現在多了一條路：你可以開始問自己，**「我每天到底在做哪些判斷？」**然後一條一條把它寫出來。 這也延續了我在〈AI 讓程式碼越來越便宜，但「知道什麼值得做」正在變得越來越貴〉談過的觀察：真正稀缺的，往往不是把功能做出來，而是知道哪個產業問題值得被做成產品。 為什麼 Prompt 不是終點？很多人學 AI 還停在：「幫我寫一個厲害 Prompt。」 但 Prompt 本身很難形成太大的護城河。真正有價值的是 Prompt 後面的判斷規則。 例如，不是只叫 AI「幫我分析這個網站的 AEO」，而是明確告訴它： 什麼情況代表 Entity 不清楚？ 什麼情況代表內容缺乏可引用性？ 什麼結構不容易被 Answer Engine 理解？ 哪些 Schema 缺失？ 品牌資訊在不同來源出現矛盾時，風險怎麼計算？ 最後甚至可以進一步形成完整流程： 檢查 → 評分 → 找問題 → 排優先級 → 提出修改 → 自動修正 這時候，它就不再只是一個 Prompt，而開始變成 Software。 Coding Agent 如何補上最後一塊拼圖？Claude Code、Codex 這類 Coding Agent 真正重要的地方，不只是「比較會寫程式」，而是它們開始可以： 讀取與建立檔案； 修改與執行程式； 查看錯誤並修正； 執行測試； 操作工具； 拆解任務並持續工作。 所以我們正在從「AI 告訴你怎麼做」，進入**「AI 幫你把它做出來」**。 這也是為什麼最近大家開始談 Agent Harness。Model 決定 AI 有多聰明；Harness 則決定：它到底能不能工作。 如果想更完整理解這個架構，可以接著閱讀〈Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness〉。 當寫程式越來越便宜，知道該寫什麼反而越來越貴以前，「我有一個 Idea，但是我不會寫程式」是一個很大的障礙。 未來真正的障礙可能變成：「你到底懂不懂這個產業？」 因為 App 可以生成、Dashboard 可以生成、Database 可以建立、API 可以串、UI 可以改。真正難複製的是： 你做過 300 次之後，知道第 301 次應該怎麼判斷。 AI 原生產品的四個必要元素我現在會用另一個公式看 AI 原生產品： AI 原生產品 = Domain Expertise × Explicit Rules × Agent Harness × Iteration 這四個元素分別代表： Domain Expertise：真實累積的產業經驗。 Explicit Rules：把經驗講清楚、拆成明確判準的能力。 Agent Harness：讓 AI 能讀取資訊、使用工具並真正動手工作的環境。 Iteration：一次又一次測試、修正與調整。 少一個，都很難變成真正可用的 AI 原生產品。 專業知識軟體化，可能催生下一波 Vertical AI今天是一個房仲做 591 分析；明天可能是一個會計師，把自己的查帳流程做成系統。 也可能是一個老師，把自己批改幾千份作文的判斷做成工具；一個行銷顧問，把做過幾百個案子的診斷方法做成產品；一個製造業老師傅，把「聽聲音就知道機器哪裡不對」的經驗拆成判斷系統。 最後會發現，他們根本不是在「學寫程式」，而是在做另一件事情： 把自己的職業經驗，編譯成軟體。 學 Vibe Coding 前，先問自己這三個問題如果你最近正在學 Vibe Coding，我反而不建議第一個問題是：「我要做什麼 App？」 你可以先問自己： 有什麼事情，是別人每次都跑來問我的？ 有什麼判斷，我做 30 秒，新手可能研究三小時？ 有什麼工作，我已經重複做過 100 次以上？ 那裡面很可能就藏著你的第一套 AI 工具，甚至是你的第一個 SaaS。 以前軟體公司的邏輯是： 找到產業需求 → 找專家訪談 → 寫規格 → 找工程師 → 做軟體 現在開始可能反過來： 專家自己就是產品經理，AI Coding Agent 就是他的工程團隊。 而他腦袋裡累積十年、二十年的 Know-how，就是最重要的原始碼。 所以我越來越相信：Vibe Coding 的終局，不是人人都變成工程師，而是每一個真正有專業的人，都有機會變成一家軟體公司。 常見問答 (FAQ)Q1：不會寫程式，也能用 Vibe Coding 做出軟體嗎？可以，但重點不只是會不會下 Prompt。你仍需要清楚描述問題、把專業經驗拆成判準與規則，並透過 Coding Agent 反覆建立、測試與修正。AI 可以降低實作門檻，卻不會自動補上你不具備的產業知識。 Q2：什麼是「專業知識軟體化」？專業知識軟體化，是把專家長期累積的經驗，從模糊的直覺拆成可說明的判準，再轉換為規則、Workflow 與軟體功能，讓原本只能靠個人判斷的 Know-how 可以被重複使用。 Q3：Prompt、Workflow 與軟體有什麼差別？Prompt 通常是一次性的指令；Workflow 把多個步驟、條件與工具串成可重複流程；軟體則進一步加入資料、介面、權限、錯誤處理與持續迭代。當 Prompt 背後有明確判斷規則並能穩定執行時，就開始具備軟體產品的雛形。 Q4：Agent Harness 在 AI 原生產品中扮演什麼角色？Agent Harness 是讓 AI Agent 能取得情境、讀寫檔案、使用工具、執行任務、處理錯誤並遵守權限邊界的工作環境。Model 決定 Agent 的能力上限，Harness 則影響它能不能可靠地把工作完成。 Q5：如何找到適合自己的第一個 AI 工具題目？先盤點別人經常請教你的問題、你能快速完成但新手需要研究很久的判斷，以及你已重複執行上百次的工作。優先選擇規則相對清楚、資料可取得、結果可以驗證的小流程，再逐步擴充成產品。

  • article-SEO、AEO 之後的 AXO：讓 AI Agent 真正完成網站任務

    2026/8/29

    AI Agent SEO AEO
    SEO、AEO 之後的 AXO：讓 AI Agent 真正完成網站任務

    這幾年，網站優化一直在改變問題的問法。 SEO 時代，我們關心的是： Google 搜不搜尋得到我？ 生成式 AI 普及後，問題變成： ChatGPT、Gemini 或 Perplexity 能不能理解我、引用我、推薦我？ 這是 AEO（Answer Engine Optimization，解答引擎優化）所處理的問題。 但看完 Greg Isenberg 訪談 Vinny、介紹 WebMCP 的影片後，我開始思考：下一個網站優化階段，可能不只是讓 AI 看懂內容，而是讓 AI Agent 能直接替使用者完成任務。 這個方向可以先用一個概念來描述： AXO（Agent Experience Optimization，AI Agent 體驗優化）。 本文的 AXO 是一個用來理解下一代網站體驗的觀念框架，目前並不是所有平台都採用的統一標準。文中提到的 WebMCP 也仍處於實驗／提案階段，實際規格、瀏覽器支援與產品做法都可能持續變動。 為什麼 AEO 還不夠？假設你問 AI： 幫我找一台適合每天做兩杯 Flat White，而且寬度不能超過 32 公分的義式咖啡機。 現在的 AI 已經可以搜尋資料、比較規格，再整理出幾個推薦選項。這是 AEO 很重要的價值：讓 AI 能夠理解產品、條件與內容，並用比較容易閱讀的方式回答問題。 但是，得到答案之後，使用者往往還要自己完成一長串工作： 打開商品網站，確認機器尺寸。 找到相容的磨豆機、把手與濾杯。 比對不同配件的規格與價格。 將商品加入購物車。 尋找折扣碼並完成結帳。 AI 可以告訴你答案，但不一定能替你把事情做完。這正是 AEO 與 AXO 的差別： 階段 核心問題 優化目標 SEO 搜尋引擎找不找得到我？ 讓網站被搜尋與點擊 AEO AI 能不能理解我？ 讓內容被理解、整理與引用 AXO AI Agent 能不能使用我？ 讓 Agent 能操作網站並完成任務 也可以用三個英文單字記住這條演進線： SEO → Search AEO → Answer AXO → Action 什麼是 AXO？我會這樣定義 AXO： AXO 是針對 AI Agent 存取、理解、操作網站，以及完成使用者任務的整體體驗進行優化。 它關心的已經不只是「AI 看不看得懂你的內容」，還包括： Agent 知不知道你的網站可以做什麼？ Agent 能不能搜尋你的商品或服務？ Agent 能不能理解商品之間的相容性？ Agent 能不能查看使用者有權限查看的資料？ Agent 能不能預約、加入購物車或修改設定？ Agent 能不能完成交易，並正確回報結果？ 操作失敗時，Agent 能不能知道原因並恢復流程？ 因此，AXO 的終點不是讓 Agent「來過網站」，而是讓 Agent 在權限、安全與確認機制都清楚的前提下，完成使用者交代的任務。 WebMCP 可能是 AXO 的一塊拼圖影片中介紹的 WebMCP，是一個很值得觀察的方向。最容易理解的說法是： 網站主動告訴 AI Agent：「你可以怎麼操作我。」 過去的 Browser Agent 通常要模仿人類操作網頁：讀取 DOM、分析 HTML、尋找按鈕與輸入框、點擊，再透過畫面或頁面狀態確認是否成功。Computer Use 與 Browser Automation 並不是不能使用，但流程可能較慢，也可能因網站改版而失效。 WebMCP 所代表的思路則不同：網站提供一組結構化、可描述的工具，讓 Agent 不必只靠猜測畫面上的按鈕，而能直接理解可使用的操作。 例如牙醫診所可以提供這類工具： 123456search_servicesget_doctor_schedulecheck_available_slotsbook_appointmentget_my_appointmentscancel_appointment 當 Agent 看到 book_appointment，它可以知道這是預約動作；看到 check_available_slots，則可以知道這是查詢可用時段。這比讓 Agent 猜「這個藍色按鈕是不是預約」更接近一個可理解、可測試的操作介面。 不過，工具名稱只是起點。要讓 Agent 真正可靠地使用網站，還需要進一步處理： 工具描述是否清楚，能不能讓模型選對工具？ 參數與資料格式是否明確？ 哪些資料需要登入後才能取得？ 哪些動作需要使用者確認？ 付款、刪除、取消等高風險操作如何避免誤用？ 失敗時要回傳什麼錯誤，Agent 才能繼續處理？ 任務成功後，系統如何提供可驗證的結果？ 這些問題都屬於 Agent Experience，而不只是某一個 Web API 的問題。 網站未來可能同時存在三層介面以前我們談網站，通常從 Human Interface 開始；未來的網站可能同時提供三種不同的理解與操作層。 1. Human Layer：給人看的介面這一層包括： HTML、CSS 與 JavaScript。 圖片、文字、選單與按鈕。 CTA、表單、結帳頁與動畫。 人類用來理解品牌與完成操作的視覺介面。 例如，人看到的是「立即預約」、「加入購物車」與「查詢訂單」。 2. Answer Layer：給 AI 理解的資訊這一層包括： Entity 與品牌資訊。 Schema 與結構化資料。 Metadata、FAQ 與清楚的內容結構。 可供 AI 驗證、整理與引用的知識。 這是 AEO 關注的範圍，目標是讓 AI 正確知道你是誰、提供什麼，以及內容之間如何互相關聯。 3. Action Layer：給 Agent 操作的能力這一層包括： Tools 與 Actions。 Authentication 與 Permission。 Transaction、Workflow 與 Confirmation。 Error Handling 與 Task Completion。 人看到「立即預約」，Agent 可能需要理解的是 book_appointment()；人看到「加入購物車」，Agent 需要理解的是 add_to_cart()；人看到「查詢訂單」，Agent 需要理解的是 get_my_orders()。 WebMCP 可能協助網站補上這個 Action Layer，而 AXO 關注的是整個操作層是否容易被發現、理解、執行與驗證。 AXO 會怎麼改變電子商務？影片裡 Vinny 示範了一個義式咖啡機器材商店的購物情境。重點不是問「哪一台咖啡機最好」，而是要求 Agent 根據多個條件，找出最適合使用者的一整套組合： 每天製作兩杯 Flat White。 咖啡機必須放進指定大小的櫃檯。 咖啡機要搭配正確的把手與濾杯。 磨豆機與其他配件也要符合需求。 這類任務很適合 Agent，因為它需要同時理解需求、搜尋商品、比較規格、確認相容性，再把多個步驟串起來。 Agent 的工作流程可能是： 了解使用者的需求與限制。 搜尋相關商品與規格。 比較尺寸、功能與相容性。 找到適合的配件組合。 將選定商品加入購物車。 在需要時套用折扣，並交由使用者確認交易。 這就不只是傳統搜尋，也不只是推薦系統，而是 Agent Commerce：由 AI Agent 協助使用者完成消費流程。 未來最大的網站訪客，可能不一定是人傳統網站流量大致是： 123456789Google ↓搜尋結果 ↓使用者點擊 ↓進入網站 ↓瀏覽與轉換 Agent 參與之後，流程可能變成： 123456789使用者提出任務 ↓AI Agent 搜尋與比較 ↓Agent 呼叫網站工具 ↓網站執行服務或交易 ↓Agent 回報完成結果 使用者甚至可能沒有直接打開網站，但 Agent 已經替他完成搜尋、預約或購物。這會讓一些傳統網站分析指標不再足以描述完整價值，例如： Page View Session Time on Site Bounce Rate 這些指標仍然有用，但未來可能還要觀察新的任務型指標： Agent Discoverability：Agent 能不能找到網站與可用工具？ Tool Success Rate：工具被呼叫後，成功執行的比例是多少？ Task Completion Rate：使用者交代的任務，有多少能完整完成？ Agent Conversion Rate：Agent 促成預約、加購或交易的比例是多少？ 這些名稱目前比較像是分析方向，而不是已經完全統一的產業標準。重點在於：網站價值可能要從「有多少人瀏覽」延伸到「有多少任務被成功完成」。 SEO、AEO、AXO 是同一條演進線把網站優化的問題拉遠來看，可以看到三個階段： SEO：讓搜尋引擎找得到SEO 會處理關鍵字、Title、Meta Description、Sitemap、站內連結與 Structured Data 等基礎，目標是讓搜尋引擎更容易發現、理解並呈現網站。 AEO：讓 AI 理解與回答AEO 更關心 Entity、Schema、FAQ、權威來源、內容結構與品牌 Identity，目標是讓 AI 能夠理解、驗證、整理與引用你的資訊。 AXO：讓 Agent 使用與執行AXO 所處理的問題則是 Tools、Actions、Authentication、Permission、Transaction、Confirmation、Error Handling 與 Task Completion。 也就是說，網站的設計可能會從 Information Architecture，逐步延伸到 Action Architecture。 WebMCP 不等於 AXO這一點需要特別釐清。 WebMCP 可能是 AXO 的技術元件，但 WebMCP 不等於完整的 AXO。 這就像 Schema.org 不等於完整的 SEO。Schema 可以協助搜尋引擎理解資料，但 SEO 還包括內容、網站結構、權威性與使用者體驗；同樣地，提供工具也不代表整個 Agent 體驗已經做好。 完整的 AXO 還要問： Agent 找不找得到網站？ Agent 能不能理解品牌、商品與服務？ Agent 取得的資料是否正確且最新？ 工具名稱、描述與參數是否足夠清楚？ 登入後的權限邊界是否明確？ 高風險操作是否需要使用者確認？ 操作失敗後，Agent 能不能知道下一步？ 交易成功後，Agent 能不能取得可驗證的結果？ WebMCP 解決的可能是「如何把網站能力描述給 Agent」；AXO 要解決的則是「Agent 能不能可靠地使用整個網站完成任務」。 哪些產業可能最早需要 AXO？第一波最需要 AXO 的，可能不是單純提供資訊的內容型網站，而是「任務複雜，且完成任務本身具有商業價值」的服務。 複雜型電商汽車零件、相機配件、咖啡器材、電腦零組件與工業設備，都可能需要規格比對、相容性判斷與多商品組合。Agent 若能理解這些關係，就不只是推薦單一商品，而是協助組出可用的方案。 預約型服務牙醫、醫美、美容、健身教練、顧問、律師與居家服務，都可能讓 Agent 代為查詢服務、比較時段與完成預約。這類流程的重點不只是找到店家，而是取得正確服務、時間、地點與預約結果。 SaaS 工具CRM、廣告管理、Email Marketing、分析工具與 ERP，都有大量需要登入、查詢與設定的操作。未來使用者可能不必打開二十個選單，而是直接告訴 Agent： 把這個月沒有回覆的 Lead 找出來，建立 Follow-up Campaign。 企業內部系統企業內部的 CRM、ERP、報表與管理後台，可能是 AXO 最早落地的場景之一。企業可以先在受控環境中讓 Agent 操作內部系統，權限與風險範圍較容易管理，也比較容易計算任務成功率與投資報酬。 Agent 神秘客：下一種網站稽核服務？如果越來越多 Agent 會使用網站，企業就會需要知道： 我的網站對 Agent 到底好不好用？ 過去網站會做 SEO Audit、UX Audit 與 Conversion Audit；未來可能出現 Agent Experience Audit，甚至直接派 Agent 當「神秘客」測試網站。 一個 Agent 神秘客可以依照指定任務測試： 能不能找到指定商品或服務？ 能不能正確理解規格與限制？ 能不能完成登入與權限流程？ 能不能加入購物車、輸入折扣或預約時段？ 需要人工確認時，是否能清楚停下來等待？ 失敗時，是否能產生可理解的錯誤原因？ 最後產出的報告，可能包含： 稽核項目 想回答的問題 Agent Readiness 網站是否具備讓 Agent 使用的基本條件？ Agent Discoverability Agent 能否找到網站與可用能力？ Tool Design 工具、描述與參數是否容易理解？ Task Completion Agent 是否能完成指定任務？ Transaction Safety 登入、付款與高風險操作是否安全？ Agent Conversion Agent 是否能帶來有效預約、加購或交易？ 這些分數不應被視為放諸四海皆準的標準，而是幫助企業找出 Agent 在哪一步失敗，以及哪個資訊或流程造成轉換流失。 網站現在可以如何準備？AXO 還在發展中，不代表所有網站現在都要立刻重做成 Agent 專用系統。比較務實的做法，是先從最重要、最常發生的任務開始盤點： 1. 先列出使用者真正想完成的任務不要只問「網站有哪些頁面」，而要問：使用者來到網站後，最希望完成哪三件事？可能是查詢規格、預約時段、提交申請、查詢訂單或修改設定。 2. 讓內容與資料可以被清楚理解品牌、商品、服務、價格、規格、庫存、地點與限制條件，都應該以一致、可讀、可驗證的方式呈現。這是 AEO 的基礎，也會影響 Agent 是否能正確做決策。 3. 把可執行的能力描述清楚如果網站支援預約、查詢、加購或修改設定，就要思考這些能力如何用清楚的工具、動作、參數與結果描述出來。工具命名要讓人與 Agent 都容易理解，不能只依賴畫面上的顏色與位置。 4. 先設計權限、確認與錯誤處理查詢公開資訊與付款、刪除、取消等高風險操作，應該有不同的權限與確認要求。每個操作也要有明確的成功、失敗、需要補資料與需要人工介入等狀態。 5. 用真實任務測試，而不是只測單一按鈕真正的 AXO 測試，應該從使用者的完整任務開始，例如「找到符合條件的商品並加入購物車」，而不只是確認 add_to_cart 這個工具能不能被呼叫。只有把整條流程跑過，才知道 Agent 是否真的能完成工作。 結語：下一代網站要問的是「Agent 能不能使用我？」以前我們做網站，會問： Google 搜不搜尋得到我？ 後來我們開始問： ChatGPT 會不會理解並推薦我？ 接下來真正重要的問題可能是： 當 AI Agent 選擇了我，它能不能順利使用我？ 這就是： SEO → AEO → AXO 從被搜尋，到被理解，再到被執行。 WebMCP 值得注意的地方，也不只是多了一個網站 API，而是它讓我們看見一種可能：Web 正在開始為 AI Agent 重新設計。 未來網站的競爭力，不只在於誰的介面漂亮、SEO 做得好或內容寫得完整，也可能取決於： 你的網站，準備好被 Agent 使用了嗎？ 參考來源本文觀點整理自 Greg Isenberg 訪談 Vinny 的影片：WebMCP: Let AI Agents pay you money。WebMCP、瀏覽器支援與 Agent 操作方式仍可能持續演進，實作前應以當時可取得的官方文件與產品規格為準。 常見問答 (FAQ)Q1：AXO 是什麼？AXO（Agent Experience Optimization）是針對 AI Agent 存取、理解、操作網站，以及完成使用者任務的整體體驗進行優化。它的重點不只在內容能否被理解，也包括工具、權限、交易、確認、錯誤處理與任務完成度。 Q2：AEO 和 AXO 有什麼差別？AEO 主要讓 AI 理解、整理與引用網站內容；AXO 則進一步讓 AI Agent 能搜尋資料、呼叫網站能力、執行操作並完成預約、購物或其他任務。AEO 偏向 Answer，AXO 偏向 Action。 Q3：WebMCP 就等於 AXO 嗎？不等於。WebMCP 可以視為協助網站向 Agent 描述可用工具與操作方式的技術方向，而完整的 AXO 還要處理資料品質、工具設計、登入權限、使用者確認、交易安全、錯誤恢復與任務完成驗證。 Q4：哪些網站最適合優先思考 AXO？需要多步驟、規格比對或交易操作的網站，通常更適合優先思考 AXO，例如複雜型電商、預約服務、SaaS 後台與企業內部系統。單純提供文章閱讀的網站，則可以先從 SEO、AEO 與內容結構打好基礎。 Q5：網站要如何開始準備 AXO？可以先盤點使用者最常想完成的任務，再把商品、服務與限制條件整理成一致且可理解的資料，接著設計清楚的工具、參數、權限、確認與錯誤回應，最後用完整任務測試 Agent 是否真的能完成流程。