跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

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

分類

標籤

商業策略 (25) AI自動化 (72) AI工具 (41) AI Agent (24) SEO (13) AEO (8) 內容行銷 (21) Cursor (2) Vibe Coding (32) 影音行銷 (21) Meta Ads (1) Codex (6) AI風險控管 (5) Gemini (10) NotebookLM (1) GEO (1) ChatGPT (12) AI繪圖 (8) n8n (28) 自動化講師應用 (5) API串接 (13) 社群行銷 (4) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Claude (3) 工作流 (1) 技術選型 (1) Electron (1) Tauri (1) Git (1) 知識變現 (4) Google (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) Power Automate (1) 職場溝通 (2) Cloudflare (4) LINE (1) 資料處理 (1)
  • 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 是否真的能完成流程。

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

    2026/8/29

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

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

  • article-4D Framework：比 Prompt Engineering 更完整的 AI Fluency 框架

    2026/8/23

    AI自動化 AI工具 AI Agent
    4D Framework：比 Prompt Engineering 更完整的 AI Fluency 框架

    很多人談 AI 素養時，第一個想到的仍然是：「Prompt 要怎麼寫才夠好？」 但 4D Framework 提供了一個更完整的視角：AI 能不能真正幫上忙，不只取決於你會不會下指令，也取決於你是否知道哪些工作適合交給 AI、能不能清楚描述需求、能不能判斷產出品質，以及最後是否願意對採用的結果負責。 先用一句話記住它： 會分工、會交代、會驗收、會負責，才是真正的 AI Fluency。 這裡的 4D 分別是： 能力 英文 核心問題 委派 Delegation 這件事該由誰做？ 描述 Description 我要怎麼讓 AI 理解我的意圖？ 判斷 Discernment AI 做得對不對、好不好？ 盡責 Diligence 我能不能安全採用、發布並負責？ 需要先釐清的是，4D Framework 並不是 Anthropic 從零發明的 Prompt 框架。依本文整理的來源，Rick Dakan 與 Joseph Feller 在 2023–2024 年發展出 AI Fluency Framework，之後 Anthropic 與兩位教授合作，把這套框架發展成 AI Fluency 課程。因此，更精確的說法是：Dakan／Feller 發展框架，Anthropic 合作將它課程化。 AI Fluency 是什麼？AI Fluency 可以簡單理解成：你能不能有效、有效率、合乎倫理，而且安全地與 AI 一起工作。 所以以下幾件事不一定代表你具備 AI 素養： 會使用 ChatGPT。 會寫一段看起來很完整的 Prompt。 會使用 Claude Code 或其他 AI Coding Agent。 真正的 AI Fluency 是你知道： 什麼問題值得交給 AI？ 哪一個工具適合這個任務？ 人與 AI 應該如何分工？ 如何定義成果標準並驗收？ 什麼資料不能直接提供給 AI？ 什麼情況需要揭露 AI 的角色？ 這也是 4D Framework 比單純 Prompt 教學更有價值的地方：它訓練的是人的工作能力，而不是某個模型的操作技巧。 ① Delegation：先決定這件事該不該交給 AI一般人打開 ChatGPT，第一句可能是：「幫我做一份課程。」 但在真正開始寫 Prompt 之前，應該先問：這件事情有哪些部分適合交給 AI？哪些部分必須由人做決定？ Problem Awareness：先搞懂自己要解決什麼問題很多人以為 AI 用不好，是因為 Prompt 寫得不夠漂亮；實際上，更常見的原因是使用者自己還沒有定義清楚問題。 比較模糊的需求是： 幫我做一個網站。 比較可執行的需求則是： 我要讓第一次進站的公司採購，在 30 秒內了解我們提供什麼水果禮盒，最後加入 LINE 詢價。 後者還沒有進入 Prompt 設計，就已經先完成了重要的問題定義：對象、情境、目標與預期行動都比較清楚。 Platform Awareness：知道哪個工具適合哪種任務AI Fluency 也包括理解工具的能力邊界。例如： 查最新新聞，需要能夠搜尋網路的工具。 分析大量自己的文件，可以考慮 NotebookLM 或 Claude Projects 類型的工作區。 寫程式，可以使用 Codex、Claude Code 或其他 Coding Agent。 生成圖片，應選擇適合圖像生成的模型。 精確計算，不能只把語言模型當成計算機使用。 重點不是「我最喜歡哪一個 AI」，而是「這個任務需要什麼能力，而哪個工具真的具備這項能力」。 Task Delegation：把人與 AI 的工作切開以設計一門課程為例，合理的分工可能是： 工作 人 AI 決定課程目標 主導 提供分析與建議 蒐集大量案例 審核方向 協助整理 規劃課程大綱 共同設計 共同設計 產生內容初稿 設定標準 執行產出 判斷案例是否適合學員 最終判斷 協助比較 最終教學內容 驗證、編輯與負責 不直接取代 Delegation 的核心不是把工作全部丟給 AI，而是先做出有意識的分工決策。 ② Description：把意圖說清楚，不只是寫 PromptDescription 是大家最熟悉的部分，因為它確實包含 Prompt；但 4D Framework 沒有把 Prompt Engineering 神化，而是把 Description 看成一種「把意圖清楚傳達給合作對象」的能力。 這跟以下工作其實很像： 寫 Brief。 下需求。 跟設計師溝通。 跟員工交辦工作。 撰寫規格書。 一個好的 Description 通常可以拆成三層。 Product Description：你要什麼成果？這一層是在定義產出物本身，包括 Output、Format、Audience 與 Style。 例如： 請製作一份 20 頁的 AI 入門簡報，對象是完全沒有 AI 經驗的中小企業老闆，使用台灣繁體中文，每頁只呈現一個核心重點，並在每個單元加入一個生活化案例。 這比「幫我做一份 AI 簡報」更容易驗收，因為成果形式、讀者、語言與內容密度都已經先定義。 Process Description：你希望 AI 怎麼完成？這一層描述處理流程，而不是只描述最後長什麼樣子。 例如： 先分析學員的常見痛點，再決定課程順序；接著為每個單元設計案例，最後才產出簡報大綱。每一步完成後，先列出判斷依據，再進入下一步。 如果只說「我要一份好簡報」，AI 可能直接跳到產出；加入 Process Description 後，才有機會看見它如何拆解問題。 Performance Description：AI 應該怎麼跟你合作？這一層規定的是 AI 的互動方式與工作行為，例如： 不要一味認同我的想法。 發現邏輯問題時要直接指出。 不確定時要明確說明不確定，不要自行補完。 回答保持簡潔，先處理最關鍵的問題。 如果缺少必要資訊，先提出澄清問題再開始。 因此，一個完整的 Description 不只是「角色＋背景＋任務＋格式＋限制」的固定模板，而是同時交代：要做什麼、怎麼做，以及要用什麼方式與我合作。 ③ Discernment：判斷 AI 的成品、過程與互動AI 最危險的地方，往往不是完全不會回答，而是能把錯誤內容講得非常像真的。 所以 Discernment 的核心問題不是：「AI 有沒有回答？」而是： 這個答案到底能不能用？ Product Discernment：成品符合需求嗎？檢查最後拿到的成果： 內容正確嗎？ 是否完整回答了問題？ 有沒有捏造資料或引用？ 格式與語氣符合對象嗎？ 是否真的解決了原本的問題？ Process Discernment：AI 的做法可靠嗎？成果看起來漂亮，不代表產出的過程可靠。以市場研究為例，仍然要檢查： 樣本是否選錯？ 是否把相關性誤當成因果關係？ 引用資料是否過期？ 是否漏掉重要競爭者？ 推論是否跳得太快？ 如果研究方法不可靠，最後的報告即使排版精美，也不應該直接拿去做決策。 Performance Discernment：互動方式適合這個任務嗎？假設你希望 AI 扮演一位批判型顧問，但它每次都只回答：「這個想法很棒！」即使內容沒有明顯錯誤，它的互動表現仍然不符合需求。 因此，驗收時也要問：AI 是否按照你要求的方式合作？它有沒有指出風險、提出反例，或在不確定時停下來？ Description 與 Discernment 是一個循環真正有效的人機協作，不是： Prompt → AI → 複製 → 貼出去 而是： Description → AI 產出 → Discernment → 修改 Description → AI 產出 → 再次 Discernment 例如第一輪請 AI「設計一門 AI 課程」，看完後發現內容太技術；第二輪補充「學員沒有程式背景，刪除不必要的技術內容」，結果又變得太淺；第三輪再要求「保留實作，但所有概念都用生活案例解釋」。 這就是 Description–Discernment Loop：Prompt 不是一次性的神奇指令，而是人與 AI 對話中的控制迴路。 ④ Diligence：使用 AI，最後仍然由人負責Diligence 可以翻成「盡責」。它的重點不是要求 AI 自己負責，而是提醒使用者：你選擇採用 AI，就要對最後採用的成果負責。 如果你請 AI 寫客戶提案，AI 把數字寫錯，而你沒有檢查就寄給客戶，不能把責任推回「是 Claude 寫的」。 Creation Diligence：選對工具並安全使用在建立內容或執行任務前，先確認： 公司機密是否適合貼進免費 AI？ 客戶個資是否可以直接上傳？ 這個模型是否適合處理目前的任務？ 是否需要限制工具權限、資料範圍或可執行的動作？ 這些都不是「寫得更長的 Prompt」可以取代的判斷。 Transparency Diligence：適時揭露 AI 的角色不同情境對 AI 揭露的要求不一樣。研究論文、學生作業、客戶報告與媒體內容，都可能需要不同程度的說明。 Anthropic 的 AI Fluency 課程本身就是一個具體示範：官方課程頁揭露 Claude 協助了課程架構、練習設計、草稿、評論、編輯與改寫，但最終內容仍由人類作者驗證、編輯並負責。 這提醒我們，透明不是把所有工作都推給 AI，而是讓讀者知道 AI 在流程中扮演什麼角色，以及人類做了哪些驗證。 Deployment Diligence：在發布前問自己能不能背書在按下以下按鈕之前： 發布 寄出 部署 交件 最後問自己： 如果明天有人問我「這個資料是真的嗎？」，我能不能負責？ 如果唯一的回答是「AI 告訴我的」，那代表 Diligence 還沒有完成。 4D 不是瀑布流程，而是兩個互相連動的 Loop4D 很容易被誤解成「委派 → 描述 → 判斷 → 盡責」的單向清單，但實際上它不是嚴格的瀑布流程。 最明顯的循環是： Description ↔ Discernment Loop：根據驗收結果，不斷修正需求描述與合作方式。 Delegation ↔ Diligence Loop：根據風險、權限與任務結果，重新調整哪些工作交給 AI，以及哪些工作必須保留人工核准。 而且 Diligence 也不是最後才做。從選工具、提供資料、查看中間結果，到最後發布，責任與風險意識都應該一路存在。 4D 與三種人機合作模式完整的 AI Fluency Framework 不只有 4D，還包含三種人機合作模式：Automation、Augmentation 與 Agency。 Automation：AI 幫我做人先定義規則，AI 執行明確任務。例如： 幫我把這 100 筆資料依照指定欄位分類。 這類任務的重點是規則清楚、輸出容易檢查，並且要確認資料權限與錯誤處理方式。 Augmentation：AI 跟我一起做人與 AI 互相提供輸入，再由人持續做判斷。例如： 跟我一起想這堂課怎麼設計，先提出三種課程方向，再指出每種方向可能的風險。 目前許多 ChatGPT、Claude 的日常使用都屬於這種協作方式。AI 提供草稿、選項與反饋，人則負責選擇、修正與決定。 Agency：AI 代表我持續做這種模式更接近 Agent、Skills、Workflow 與 MCP： 每天讀信、分類、查 CRM、草擬回覆，符合條件時建立任務，遇到高風險情況就通知我核准。 當 AI 的自主程度提高，4D 反而更重要。因為 Agent 如果每天自動執行大量錯誤操作，問題就不再只是一次 Prompt 寫錯，而可能擴大成資料、權限、成本與客戶影響的治理問題。 為什麼 4D 比單純 Prompt Engineering 更適合教 AI 素養？工具會一直改變。今天可能是 ChatGPT、Claude、Gemini，明天可能是 Agent、Skills、MCP 或 Computer Use。 但以下四種能力不會因為工具更換就失效： 能力 你真正要學會的事 Delegation 盤點問題，決定誰做、誰核准 Description 把成果、流程與合作方式說清楚 Discernment 驗收成品，也檢查方法與互動 Diligence 管理資料、風險、透明度與責任 Prompt 是 Description 的一部分，但不是全部。只把 Prompt 寫得更長，並不會自動解決工具選擇錯誤、成果驗收不足、敏感資料外洩或責任歸屬不清等問題。 每天使用 AI 前，可以先問自己的 6 個問題如果你想把 4D Framework 變成日常工作習慣，可以在開始任務前後快速檢查： 問題是什麼？ 我是否能用一句話說明要解決的問題與成功標準？ 工具適合嗎？ 這個任務需要搜尋、文件分析、程式執行、圖片生成或精確計算嗎？ 怎麼分工？ 哪些步驟由 AI 做，哪些決策保留給人？ 怎麼描述？ 我是否說清楚成果、處理流程與合作方式？ 怎麼驗收？ 我會檢查成品、方法與 AI 的互動表現嗎？ 敢不敢負責？ 資料、權限、揭露與最後發布是否都在可接受的風險範圍內？ 這 6 個問題，比背一套固定 Prompt 模板更能幫你把 AI 用在正確的地方。 結語：真正的 AI Fluency，主要是在訓練人4D Framework 最值得學的地方，是它把「AI 工具教學」往上一層提升成「AI 工作能力」。 AI 素養不是「會不會下 Prompt」，而是你有沒有能力決定： 誰來做？ Delegation 怎麼做？ Description 做得好不好？ Discernment 敢不敢負責？ Diligence 如果要把它濃縮成一句話，就是： 真正的 AI Fluency，不是訓練 AI 取代人的判斷，而是訓練人更有意識地分工、溝通、驗收與負責。 如果你想延伸閱讀，可以先看本站的〈Claude Academy 學習路徑完整指南：22 門免費課程與 289 項資源怎麼選？〉，再搭配〈從提示詞到 Skill：5 個實務做法打造高效率 AI 自動化工作流〉理解如何把協作方法封裝成可重複使用的工作模組；若想進一步理解自主型 AI，則可參考〈AI Chatbot 跟 AI Agent 到底差在哪？一篇文講到你懂，還教你怎麼用！〉。 常見問答 (FAQ)Q1：4D Framework 跟 Prompt Engineering 一樣嗎？不一樣。Prompt Engineering 主要處理如何描述任務，是 4D Framework 中的 Description；4D 還包括任務委派、成果判斷，以及資料安全、透明揭露與最終責任。 Q2：4D Framework 是誰提出的？依本文整理的正式來源，Rick Dakan 與 Joseph Feller 發展了 AI Fluency Framework，後來 Anthropic 與兩位教授合作，將框架發展成 AI Fluency 課程。因此不宜簡化成「Anthropic 發明 4D」。 Q3：Automation、Augmentation 與 Agency 有什麼差別？Automation 是 AI 依規則替人執行，Augmentation 是人與 AI 一起完成任務，Agency 則是 AI 代表人持續執行工作流程。AI 越自主，越需要明確的權限、驗收與人工核准邊界。 Q4：為什麼使用 AI 後，最後仍然是人負責？因為人決定了任務是否交給 AI、提供了哪些資料，也決定是否採用與發布結果。AI 可以協助產出，但不能替人承擔資料錯誤、個資外洩、著作權、客戶影響或決策失誤的責任。 Q5：剛開始學 4D Framework，最簡單的做法是什麼？先在每次使用 AI 前問六件事：問題是什麼、工具適合嗎、如何分工、如何描述、如何驗收，以及最後敢不敢負責。這能把 4D 從抽象框架轉成日常工作檢查表。 參考來源 AI Fluency Framework 官方網站 Anthropic：AI Fluency Framework & Foundations Claude Academy：AI Fluency for Small Businesses Anthropic Skilljar：AI Fluency Framework & Foundations HEA：Dakan & Feller AI Fluency Framework 正式文件

  • article-Claude Academy 學習路徑完整指南：22 門免費課程與 289 項資源怎麼選？

    2026/8/22

    AI自動化 AI工具 AI Agent
    Claude Academy 學習路徑完整指南：22 門免費課程與 289 項資源怎麼選？

    如果你一直想認真學 Claude，卻不知道應該先看哪一份教學，現在其實有一個更直接的入口：Anthropic 官方的 Claude Academy。 它不是單純把產品說明文件集中在一起，而是把 Claude 的日常應用、AI Fluency、Claude Code、Agent Skills、Subagents、MCP、API 與不同職業情境，整理成課程、教學與 use case 的學習平台。 Anthropic 在官方文章中也說明，Claude Academy 的目標不只是教大家操作產品，而是協助學習者建立更安全、更有效率、更有判斷力的 AI 協作能力。你可以直接進入 Claude Academy 瀏覽課程；登入後還能追蹤學習進度與完成徽章。 本文依我在 2026 年 8 月 22 日看到的公開頁面整理。課程、翻譯、資源數量與產品功能都可能持續更新，正式開始前仍建議以平台當日顯示為準。 Claude Academy 到底有多少內容？先把最容易混淆的三個數字拆開： 22 門課程：比較完整、適合按順序完成的 learning path。 21 門目前可看到繁體中文內容：包含課程頁、單元與部分測驗／完成頁；Claude Platform 101 目前是繁中支援較不完整的例外。 289 項資源：這個數字不只包含課程，也包含 tutorials 與 use cases。 我依官方課程頁列出的單門時數相加，22 門課程約為 69.5 小時。這是把課程頁標示的觀看／學習時間加總，不代表每個人都會在相同時間完成，也不包含你自行練習、做筆記與實作的時間。 因此，看到 289 項資源時，不需要把它理解成「有 289 門課要全部修完」。比較合理的做法是先選一條符合自己工作情境的路徑，再用 tutorials 與 use cases 補實作。 22 門官方課程完整清單與時數下面的名稱保留 Claude Academy 課程頁的英文標題，方便你直接在平台搜尋。繁中欄位代表目前可看到對應的 zh-TW 課程內容；翻譯狀態可能隨平台更新而變動。 # 課程 官方標示時數 繁中內容 1 AI Capabilities and Limitations 3.5 小時 ✓ 2 AI Fluency for Builders 3 小時 ✓ 3 AI Fluency for educators 1.5 小時 ✓ 4 AI Fluency for nonprofits 4 小時 ✓ 5 AI Fluency for pK-12 Train the Trainer 45 分鐘 ✓ 6 AI Fluency for pK-12 Educators 3 小時 ✓ 7 AI Fluency for Small Businesses 4 小時 ✓ 8 AI Fluency for students 3 小時 ✓ 9 AI Fluency: Framework & Foundations 4 小時 ✓ 10 Building with the Claude API 9 小時 ✓ 11 Claude 101 2.5 小時 ✓ 12 Claude Code 101 1 小時 ✓ 13 Claude Code in Action 1 小時 ✓ 14 Claude Platform 101 1.5 小時 — 15 Claude with Amazon Bedrock 8 小時 ✓ 16 Claude with Google Cloud’s Vertex AI 8.5 小時 ✓ 17 Introduction to agent skills 1 小時 ✓ 18 Introduction to Claude Cowork 2.5 小時 ✓ 19 Introduction to Model Context Protocol 1 小時 ✓ 20 Introduction to subagents 45 分鐘 ✓ 21 Model Context Protocol: Advanced Topics 1.5 小時 ✓ 22 Teaching AI Fluency 4.5 小時 ✓ 你可以直接開啟 Claude Academy Courses 查看課程分組、lesson 數量、測驗與是否顯示 Completion badge。若想把課程、tutorial 與 use case 放在一起瀏覽，可以使用 All resources。 這套課程不只是教你怎麼用 ClaudeClaude Academy 的內容大致可以分成四個層次。 1. 先建立正確的 AI 使用觀AI Fluency: Framework & Foundations 以 4D Framework 為核心，帶你理解 Delegation、Description、Discernment 與 Diligence。換成比較容易記的說法，就是： 判斷哪些工作適合交給 AI。 把任務、脈絡與限制說清楚。 分辨 AI 輸出的品質與風險。 對最後交付的結果負責。 這也是為什麼我不建議一開始就只追求最複雜的 Agent 技術。若連任務分工、驗證與資料界線都還沒有建立，工具越強，反而越容易把錯誤放大。 2. 從 Claude 101 進入日常工作Claude 101 是一般使用者最自然的起點，內容從第一次對話、提示、Projects、Artifacts、Skills 到連接工具，逐步建立基本操作能力。 它適合先拿來處理： 文章、電子郵件與文件初稿。 會議資料與研究內容整理。 腦力激盪、規劃與比較分析。 把一個工作任務拆成可以交給 AI 的步驟。 這一層學會的重點不是「背更多提示詞」，而是知道怎麼描述目標、提供必要背景，並設計檢查結果的方法。 3. 從 Claude Code 走向 Agent 工作流技術路線會進一步出現 Claude Code、Agent Skills、Subagents、MCP 與 API。它們分別處理不同問題： Claude Code：讓 Claude 在終端機與專案檔案中工作。 Agent Skills：把可重複的知識、規則與工作方法整理成技能。 Subagents：把複雜任務拆給不同的子 Agent，並集中協調結果。 MCP：讓模型透過標準協定連接外部工具、資料與服務。 Claude API：把模型能力整合進自己的產品或後端工作流。 如果想更完整理解這些名詞，也可以先讀站內的 AI 工具名詞全解析：一次搞懂 MCP、Skill 與 CLI 的差異與應用場景，再回到 Claude Academy 的實作課程。 4. 依照不同角色調整 AI Fluency平台也把 AI Fluency 拆成 builders、educators、pK-12 educators、students、nonprofits 與 small businesses 等不同版本。這種設計很實用，因為「會用 AI」不是所有人都要學同一套內容，而是要對應自己的責任、資料與決策情境。 四種身分的建議學習路徑下面不是官方唯一順序，而是我依課程難度、實用性與前置概念整理出的起步方式。 路徑一：行銷工作者適合內容企劃、社群、小編、廣告投手、品牌與電商行銷人員。 建議順序： Claude 101 AI Fluency: Framework & Foundations 從 Claude Academy Tutorials 搜尋 Marketing、內容、研究與分析相關主題。 從 Claude Academy Use cases 挑 3 個最接近日常工作的案例，例如內容改寫、活動分析、客群整理或電子報規劃。 想把單次提示變成可重複工作流，再選 AI Fluency for Builders 或 Introduction to Claude Cowork。 這條路徑的重點，是先把 Claude 放進現有行銷流程，而不是一開始就追求完全自動化。你可以先要求 Claude 協助研究、整理與產出，再由人確認品牌語氣、事實、素材權利與投放風險。 路徑二：中小企業主與管理者適合需要同時處理行銷、客服、營運、文件與內部溝通的企業主或主管。 建議順序： Claude 101 AI Fluency: Framework & Foundations AI Fluency for Small Businesses 使用 use cases 找出研究、客戶資料整理、流程文件與營運追蹤等高頻任務。 確認哪些步驟可以標準化後，再學 Introduction to Claude Cowork、Claude Code 101 或 Agent Skills。 這條路徑要特別注意資料權限。把工作流程交給 AI 之前，先區分公開資料、內部資料、個資、客戶機密與財務資訊；不要因為課程示範方便，就直接把真實敏感資料貼進練習環境。 路徑三：老師與學生適合教師、教育工作者、學生與需要建立 AI 學習規範的教學團隊。 教師可以這樣安排： AI Fluency: Framework & Foundations AI Fluency for educators 或 AI Fluency for pK-12 Educators Teaching AI Fluency 依課程需求挑選教學設計、學習材料、評量與 AI 協作案例。 學生可以這樣安排： Claude 101 AI Fluency: Framework & Foundations AI Fluency for students 把 Claude 當成學習夥伴，請它解釋、提問、比較與反饋，但保留自己的推理、查證與最後提交責任。 這條路徑最重要的不是讓 AI 代寫所有作業，而是建立「哪些工作可以委派、哪些思考必須自己保留，以及如何揭露 AI 使用方式」的能力。 路徑四：想往技術方向發展的人這是我最推薦給想從一般 Claude 使用者走向 AI Agent 工作流的人。 建議順序： Claude Code 101 Introduction to agent skills Introduction to subagents Introduction to Model Context Protocol Model Context Protocol: Advanced Topics Claude Code in Action 想把能力整合到產品，再進入 Building with the Claude API。 這個順序背後的邏輯是：先學會讓 Agent 在專案裡工作，再學會把工作方法封裝成 Skill；接著理解任務拆解、工具連接與協定，最後才把整套能力組成可以重複執行、監控與驗證的工作流。 如果你已經在研究 Skill 與 Agent，也可以延伸閱讀站內的 Skill 之後，下一個 AI 開發者一定要懂的詞：Agent Harness，理解模型、上下文、工具、權限與技能如何一起形成可工作的環境。 289 項資源應該怎麼挑？我的建議很簡單：不要先收藏全部，先完成一個小閉環。 先選一門主課程第一次接觸 Claude，就先從 Claude 101 開始；已經每天使用 Claude，則可以從 AI Fluency: Framework & Foundations 或符合職業的 AI Fluency 課程開始。技術背景較強的人，再從 Claude Code 101 進入。 每門課搭配一個真實但已去識別化的任務例如： 行銷人員：把一份公開活動資料整理成三種受眾版本。 企業主：把重複性的內部流程整理成 SOP 草稿。 教師：把一個單元轉成分層提問與課堂活動。 開發者：讓 Claude 先閱讀一個小型專案，再完成一個可驗證的修改。 用結果判斷是否真的學會每完成一個 lesson，不要只按下一步。至少留下以下其中一項成果： 一個自己重寫過的 prompt。 一份可以重複使用的工作模板。 一次輸出品質比較紀錄。 一個有測試、檢查與人工覆核的工作流程。 收藏清單會讓人產生「我已經開始了」的錯覺，但真正累積能力的是練習、判斷與交付。 免費課程不代表所有實作都零成本Claude Academy 的課程可以免費開始，瀏覽課程也不一定要先完成完整訂閱；但如果進入 API、Amazon Bedrock 或 Google Cloud Vertex AI 的實作，可能仍需要各平台的帳號、金鑰、權限與用量費用。 開始技術課程前，建議先確認： 是否需要 Anthropic、AWS 或 Google Cloud 帳號。 API 金鑰要放在哪裡，是否會被提交到 Git 或分享給別人。 目前使用的方案、模型與雲端資源是否會產生費用。 課程示範的程式碼是否需要依當前文件版本調整。 免費的是學習平台與課程入口，不代表外部 API、雲端服務或你投入的時間沒有成本。 完成課程可以拿到什麼？目前 Claude Academy 課程頁多數會直接標示 lesson、quiz 與 Completion badge。因此比較準確的說法是：完成符合條件的課程與測驗後，可以依課程頁提示取得完成徽章或追蹤學習進度；不是 289 項資源全部都會發正式證書。 如果你需要把學習成果放進履歷或 LinkedIn，建議在完成課程後保存： 課程名稱與完成日期。 Completion badge 或平台提供的完成頁。 自己實作的作品、流程或程式碼。 你如何驗證 AI 輸出，以及在哪些地方保留人工決策。 真正能說服別人的通常不是「我收藏過多少課程」，而是你能不能展示一個可靠、可重複、知道邊界在哪裡的工作成果。 開始前的五個提醒1. 課程數量會變動Claude Academy 是持續更新的平台，22 門、289 項與 69.5 小時都是本文整理當下的快照。未來新增課程或調整時數時，文章數字可能需要同步更新。 2. 繁中支援不代表每個畫面永遠一致目前有 21 門課程可以看到繁體中文內容，但平台仍可能在某些導覽、外部連結、特定測驗或新上線單元暫時保留英文。進入課程後，請從語言選單確認當下版本。 3. 不要把課程推薦當成產品保證Claude、Claude Code、Cowork、MCP 與 Agent Skills 都會快速更新。課程適合用來建立概念與練習方法，實際操作時仍應回到官方最新文件確認參數、權限與限制。 4. 技術路徑需要逐步增加難度如果還不熟悉終端機、Git、API 或 JSON，不需要一開始就跳進 MCP Advanced Topics。先完成 Claude Code 101 與 Agent Skills，通常會比直接複製一段 MCP 設定更容易建立可維護的理解。 5. AI 輸出仍要依風險程度驗證學會使用 Claude，不等於把判斷責任交出去。涉及法律、醫療、財務、個資、客戶承諾或正式發布的內容，都要提高查證與人工覆核的強度。 結語：真正值得學的是 AI 協作能力Anthropic 現在公開的已經不只是「Claude 要怎麼用」，而是一套從日常對話、AI Fluency 到 Agent 工作流的學習地圖。 如果你是一般使用者，從 Claude 101 開始就好；如果你是行銷人員、企業主、老師或學生，先選符合自己工作情境的 AI Fluency 路徑；如果你想往技術方向發展，則可以沿著： Claude Code → Agent Skills → Subagents → MCP → Agent 工作流 一步一步往前走。 不要因為平台免費，就把 289 項資源全部塞進收藏夾。選一條路徑、完成一門課、做出一個能在工作中使用的成果，這樣才是真的開始學會 Claude。 常見問答 (FAQ)Q1：Claude Academy 是什麼？Claude Academy 是 Anthropic 官方的 AI 學習平台，整合 Claude 日常應用、AI Fluency、Claude Code、Agent Skills、MCP、API、雲端部署與不同職業情境的課程、tutorials 和 use cases。 Q2：Claude Academy 的課程需要付費嗎？Claude Academy 的課程目前可以免費開始；登入 Claude 帳號主要用於保存學習進度與取得符合條件的完成徽章。不過 API、Amazon Bedrock、Vertex AI 等外部實作可能需要另外的帳號、金鑰或用量費用。 Q3：22 門課程都有繁體中文嗎？目前整理到的狀態是 22 門課程中有 21 門可看到繁體中文內容，Claude Platform 101 的繁中支援較不完整。平台仍會更新，實際開始前請在課程頁確認語言選項與單元內容。 Q4：完全沒有技術背景，應該從哪一門開始？建議先修 Claude 101，接著選 AI Fluency: Framework & Foundations，再依自己的身分進入行銷、小型企業、教育或學生版本的 AI Fluency 課程。暫時不需要從 MCP 或 API 開始。 Q5：完成課程可以取得正式證書嗎？目前課程頁主要標示的是 Completion badge。完成課程與測驗後，能否取得徽章以及顯示方式，應以該門課程頁與登入後的完成狀態為準；tutorial 或 use case 不一定具有相同的完成認證機制。 Q6：想學 Claude Code、Agent Skills 與 MCP，順序怎麼排？建議依序學習 Claude Code 101、Introduction to agent skills、Introduction to subagents、Introduction to Model Context Protocol、Model Context Protocol: Advanced Topics，再用 Claude Code in Action 與 Building with the Claude API 延伸到完整 Agent 工作流。 官方入口 Claude Academy 首頁 Claude Academy Courses Claude Academy All resources Claude Academy Tutorials Claude Academy Use cases Anthropic’s approach to teaching and learning AI

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

    2026/8/22

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

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

  • article-cangjie-skill：把書籍與長影音蒸餾成 AI Agent 可用的 Skills

    2026/8/22

    AI自動化 AI工具 AI Agent 內容行銷
    cangjie-skill：把書籍與長影音蒸餾成 AI Agent 可用的 Skills

    很多人讀完一本書、看完一支一小時的 YouTube，或聽完一集 Podcast，最後留下來的通常是一篇摘要。 摘要當然有用，但它只能回答： 這份內容說了什麼？ 真正困難的問題是： 遇到什麼情境時，我應該採用這套方法？要怎麼做？什麼時候反而不該用？ 這也是 cangjie-skill 有意思的地方。它嘗試把書籍、長影音、Podcast、課程、訪談、演講與長文章裡的可遷移方法論，蒸餾成一組組可以被 AI Agent 呼叫的 Skills。 從知識管理走向知識能力化傳統的知識管理，通常是把內容保存下來：筆記、摘要、逐字稿、書摘與收藏清單。這些資料能幫助我們回想，但不一定能在需要做決策時直接派上用場。 Skill 的思路則更接近一個小型決策系統：它不只保存結論，也要描述觸發條件、判斷步驟、執行方式與使用邊界。 形式 主要回答的問題 典型產出 摘要 作者說了什麼？ 一篇精華文章 RAG 哪些原文與目前問題相關？ 檢索結果與引用 Agent Skill 目前是否該採用這套方法？接下來怎麼做？ 可呼叫、可測試的工作模組 因此，「我看過這本書」不再只是個人的記憶，而可能變成「我的 Agent 知道什麼時候使用這本書的方法做事」。 cangjie-skill 會把內容拆成什麼？一本書或一段長影音裡，不是每一句話都值得被做成 Skill。比較適合被抽取的，通常是以下幾類內容： 可以重複使用的框架與方法論 能協助判斷的原則與決策方式 能說明方法如何運作的案例 能提醒 Agent 不要誤用的反例與限制 需要精確理解的專有名詞與概念 最後的產物也不是一份很長的 Markdown 摘要，而是一個具有結構的 Skill Repository，可能包含： BOOK_OVERVIEW.md：完整內容的全局理解 INDEX.md：各個 Skill 的地圖與關聯 DIGEST.md：給人閱讀的精華長文 GLOSSARY.md：重要術語與定義 多個 SKILL.md：可以獨立呼叫的能力模組 test-prompts.json：用來驗證觸發與拒用行為的測試案例 一套 Skill 如何從長內容被蒸餾出來？官方 repository 將流程整理成 RIA-TV++。它可以理解成一條從「理解原始內容」走到「驗證 Agent 行為」的蒸餾流程。 1. 先建立整體理解先處理整份內容的結構、解釋、批判與應用，不急著看到一句金句就立刻生成 Skill。這一步的目的，是避免把脫離上下文的片段誤當成完整方法。 2. 讓不同角度的提取器並行工作流程會分別尋找框架、原則、案例、反例與術語。不同提取角度可以減少只看「漂亮結論」的偏差，也比較容易發現一套方法的前提條件。 3. 用三重驗證篩選候選方法候選內容需要經過三項檢查： 原始內容中至少有兩處相對獨立的佐證 這套方法能回答內容沒有直接說出的新問題 它具有一定獨特性，不只是一般常識 這個步驟很重要，因為不是所有作者說過的句子，都值得變成 Agent 的長期行為規則。 4. 把方法整理成可執行格式通過驗證後，Skill 需要進一步整理出原文依據、自己的重述、原始案例、未來可能遇到的觸發場景、執行步驟，以及邊界與盲點。 其中「邊界與盲點」尤其關鍵。沒有邊界的 Skill，很容易變成遇到任何問題都硬套的萬用提示詞。 5. 建立 Skill 之間的關聯有些方法彼此互補，有些方法互相衝突，有些方法則必須先使用另一個 Skill 才能成立。把這些依賴、對比與組合關係整理出來，Agent 才比較有機會選對工具，而不是只根據關鍵字做表面匹配。 6. 用誘餌題進行壓力測試test-prompts.json 不只測試「該用的時候有沒有成功呼叫」，還會故意設計不該使用該 Skill 的情境，例如： 表面上相似，但缺少必要前提 其實應該使用另一個 Skill 問題需要更多資料，不能直接套用方法 方法本身與使用者目標互相衝突 這讓驗證目標從「AI 知不知道這個知識」，提升到「AI 能不能判斷什麼時候使用，以及什麼時候拒絕使用」。 為什麼「知道何時不用」比「知道更多」重要？Agent 最危險的情況，不一定是不知道某個框架，而是知道框架後到處套用。 例如，一套適合產品定位的行銷方法，可能不適合處理個人情緒；一套適合快速實驗的創業框架，也不一定適合高風險的醫療、法律或財務決策。如果 Skill 只有步驟，沒有前提與停用條件，內容越多，誤用的機會可能越高。 因此，一個成熟的 Skill 至少要讓 Agent 能回答： 目前問題是否符合觸發條件？ 還缺少哪些必要資訊？ 是否存在更適合的 Skill？ 哪些情況下應該停止、轉交或改用其他方法？ 它和摘要、RAG 是互補關係cangjie-skill 不必取代摘要或 RAG。比較合理的分工是： 摘要負責讓人快速掌握內容全貌 RAG 負責在需要時找回原文依據 Skill 負責把方法轉成可重複執行的決策與行動流程 在實務上，Skill 仍然需要保留來源脈絡。當 Agent 要做出高風險或高成本的決策時，應該能回到原始書籍、逐字稿或案例確認，而不是把蒸餾後的版本當成不可質疑的真理。 哪些內容適合拿來蒸餾？只要內容裡存在可抽取、可驗證、可遷移的方法論，就有機會被轉成 Skill。例如： 行銷與文案書籍 YouTube 或 Bilibili 長影音字幕 Podcast 轉錄稿 線上課程與企業內訓教材 專家訪談與演講逐字稿 產品、管理或創業相關長文章 相反地，如果內容主要是個人故事、情緒抒發、一次性的新聞或缺乏可重複判斷方式的觀點，就不一定適合強行 Skill 化。保留成摘要、引用資料或背景知識，可能更誠實也更有用。 實際使用前，還是要做四項檢查來源是否可靠？字幕錯誤、轉錄遺漏、版本不完整或二手整理，都可能讓後續 Skill 建立在錯誤材料上。蒸餾前要先知道來源是原書、官方字幕、人工逐字稿，還是未經確認的轉述。 方法是否適合目前情境？作者的框架通常有它的時代、產業、角色與資源前提。能從內容抽出來，不代表可以無條件套用到所有人身上。 測試是否包含拒用案例？如果測試只有正向案例，看到 AI 成功呼叫 Skill 不能代表路由正確。至少要加入相似但不適用、資料不足、目標衝突與跨 Skill 混淆等誘餌題。 是否符合來源授權？書籍、課程、字幕與 Podcast 轉錄內容可能受到著作權或平台條款限制。實驗可以從自己擁有、取得授權或適合內部使用的材料開始，並確認 Skill Repository 的分享範圍。 從「我讀過」到「我的 Agent 會用」cangjie-skill 最值得研究的地方，是它把知識管理的終點往前推了一步。 以前我們會問： 我有沒有把這本書讀完？ 現在可以多問一個問題： 這本書裡哪些方法，值得在未來的工作情境中被 Agent 正確呼叫？ 這個轉變意味著，知識庫不再只是收藏與搜尋的地方，也可以逐漸變成一組可組合、可驗證、可持續修正的能力模組。 當然，Skill 化不是把所有內容都拆得越細越好。真正重要的是保留來源、清楚寫出適用邊界，並用足夠的反例確認 Agent 不會亂用。只有這樣，「看過一本書」才有機會真正變成可重複使用的工作能力。 常見問答 (FAQ)Q1：cangjie-skill 和一般 AI 摘要有什麼不同？cangjie-skill 的目標不是只濃縮內容，而是把其中可遷移的方法論拆成具有觸發條件、執行步驟、使用邊界與測試案例的 Agent Skills。 Q2：哪些素材可以拿來蒸餾成 Skill？書籍、長影音字幕、Podcast 轉錄稿、課程、訪談、演講與長文章都可以嘗試，但前提是內容中存在可抽取、可驗證、可重複使用的方法或決策框架。 Q3：為什麼測試題要加入誘餌題？誘餌題可以檢查 Agent 是否只會看到關鍵字就亂用 Skill，也能驗證它在條件不足、目標衝突或存在更適合方法時，是否能拒用或改選其他 Skill。 Q4：蒸餾完成後可以直接相信 Skill 嗎？不應該完全直接相信。Skill 仍可能受到來源品質、模型理解與方法適用範圍影響；高風險決策應保留原文依據、人工審查與必要的專業驗證。 Q5：第一次實驗適合從什麼內容開始？建議先選一堂課、一場訪談或一本會在工作中反覆使用的方法書，並以「正確觸發、正確拒用、邊界判斷與實際產出」和單純摘要加提示詞的結果做比較。 延伸閱讀 cangjie-skill GitHub repository