很開心今年又有 WordCamp 可以參加，每次參加都很珍惜，每年都靠著志工們的無私付出，才能有這麼多精彩的活動可以參與。今年是第一次舉辦在高雄，高雄展覽館超大氣，整個會場超舒服，真希望新北也能有這麼棒的場地～

今年我的攻略路線就是專心聽演講，以往都覺得在現場跟人聊天交流比較重要，演講的內容事後還可以去看 WordPress.tv 回顧，結果最後都沒去看XD，自己當過講者也知道，每次上台前要花好多時間準備、練習再練習才有辦法呈現一場演講，所以與其只是在哪邊喇賽，還不如好好享受每位講者精心準備的內容。

為了達成此目標，我六點起床，搭了 6:54 的高鐵直達高雄，再坐小黃 30 分鐘拼第一場演講，然後趁著每場中間的休息時間去贊助商攤位認識一下，午餐過後找不到咖啡可以喝，只能撐著睡意，努力聽到最後一場，最後為了趕高鐵放棄了閉幕抽獎，度過非常充實的一天。

為了更精準的吸收每場的內容，我聽的場次我都有用語音備忘錄錄下來，然後回到家再用 Gemini 整理出逐字稿與重點整理，這邊我把有聽的七個場次整理出來並補上自己的心得，分享給當天無法參與的朋友們。

​高效率人才管理，讓 WordPress 成為你的組織槓桿​

講者：Calvin、阿竣

選擇這場的原因：想知道 WordPress 更多的可能性

AI 摘要

這場由敲敲設計創辦人 Calvin 與科技零售業技術長阿竣的雙人對談，深入探討了 WordPress 在企業經營、人才管理與數位轉型中的應用與價值。

1. WordPress 生態圈的價值與組成

核心價值來自社群： WordPress 的成功並非只因其免費開源，而是由全球使用者、開發者、設計師和贊助商共同參與創造出的龐大生態圈。

不只是開發者的工具： 生態圈成員多元，包含行銷人員、內容創作者、企業主等，共同協作創造出互惠的價值。

企業支持社群的雙贏： 阿竣強調，企業支持開源社群是雙贏。不僅能確保核心軟體的安全性與更新（由社群免費維護），也能建立公司與個人的專業聲譽，並從中找到解決方案與人才。

2. 企業導入 WordPress 的策略與優勢

降低內部訓練成本： Calvin 指出，對於人員流動率高的組織（如 NGO），WordPress 的標準化介面能大幅縮短新進人員的學習曲線，讓行銷或內容人員快速上手。

標準化帶來的效益： 阿竣分享，企業應遵循官方文件與核心原則，避免修改核心程式碼。這讓企業能專注於開發自身業務所需的外掛或佈景主題，將核心維護的重任交給全球社群，大幅節省成本。

從「救火」到「中控」： 阿竣以自身經驗說明，企業往往在內部系統（如 Notion、Google Sheets）混亂到「病入膏肓」時，才意識到需要整合。WordPress 可作為一個強大的「中控」平台，串接電商通路、倉儲（WMS）、訂單（OMS）與企業資源規劃（ERP）系統，實現流程自動化與高效管理。

導入的規模與時機： 針對中小企業，阿竣建議當年營收達到 3000萬（可能面臨國稅局查帳與ERP需求）是一個考慮導入IT人才與系統的契機。但更重要的是解決當下的痛點，即使是小型團隊，若有資安或 CRM 整合需求，也應及早規劃。

3. WordPress 人才的招募、管理與價值

人才市場的流動性： WordPress 的標準化創造了一個流動且公平的人才市場。熟悉 WordPress 的人才在求職時擁有更多選擇，企業在招募時也更容易找到合適人選。

如何定義客戶與專案成本： Calvin 將客戶依對 WordPress 的熟悉度分類。客戶的熟悉程度直接影響專案中的「教育時間」與溝通成本，越懂 WordPress 的客戶，專案執行效率越高。

精準的招募策略： 徵才時應先定義職務（如內容行銷、網站設計師），再將「熟悉 WordPress」列為加分項或必要技能，避免使用過於深奧的技術詞彙，才能找到符合業務需求的人才。

有效的教育訓練方式： Calvin 建議採用「線上工作坊」形式進行教學，並全程錄影。這比提供靜態文件更有效，不僅能確保學員專注，錄影檔也能作為未來新進人員的訓練教材。

4. 面對未來的挑戰：AI 與 WordPress

AI 是輔助而非取代： 講者一致認為，AI 是強大的工具，但仍需具備專業知識的人來操作。AI 的知識庫來自網路，而 WordPress 驅動了全球超過 40% 的網站，因此，理解 WordPress 的運作原理，才能更有效地利用 AI 進行網站開發與內容管理。AI 將讓 WordPress 變得更好，而非取代它。

我的心得

老實說今年自己的外掛產品販售之路遇到不少挫折，不知道聽過多少次台灣市場太小、用的人不多，因此單靠賣外掛是無法存活的論點，本來自己是不相信的，但隨著業績沒有達到理想數字，慢慢開始懷疑 WordPress 在台灣是不是真的沒有人在用。

當我聽著講者在台上分享時，回頭看著與會的人數，比我想像中多好多，再聽到阿竣利用 WordPress 作為公司內部的知識管理平台，以及 Calvin 分享的接案數據，突然覺得 WordPress 在台灣還是很多人在用啊～

有了這樣的信心後，讓我重新思考產品的路線，可以朝著協助接案者與企業溝通的角度下手，因為 WordPress 的標準化是真的能夠大幅加速系統導入或是職務交接的流程，再搭配 AI 的輔助更能加強 WordPress 的威力。

​Getting to Yes: The Art of Selling Ideas, Not Just Designs​

講者：Corey Weddington

選擇這場的原因：想知道如何正確傳達產品理念

AI 摘要

這場演講的核心在於如何有效地向客戶「銷售」你的想法，無論是設計、技術決策還是專案計畫，以獲得他們的認同與支持。講者 Cory 指出，提案失敗通常不是簡報本身的問題，而是「前期準備工作」的失敗。

1. 常見的提案錯誤

電子郵件突襲 (Email Ambush): 未經溝通，直接將完成的設計稿或提案用 email 寄出，並詢問「你覺得如何？」。

「相信我」提案 (Trust Me Pitch): 只給出結論，卻不解釋背後的邏輯，要求對方僅憑信任就接受。

開放式問題 (Open-ended Questions): 提出如「你喜歡嗎？」這類問題，容易引來大量主觀意見，而非有建設性的策略回饋，導致無盡的修改。

2. 提案中的「三個對話」

每一次提案，你其實都在同時進行三種層次的對話，任何一個環節出錯都可能導致失敗：

邏輯對話 (Logical Conversation):「這能解決問題嗎？」

這是最表層的對話，需要用數據、案例研究、事實來證明你的想法是正確且有效的。

政治對話 (Political Conversation):「這是誰的地盤？」

即使你的點子再好，如果讓某個重要利害關係人感到被排除在外、驚訝或被搶了風頭，提案依然會失敗。

關鍵在於讓相關人士有主導感，感覺自己是共同建構者。

情感對話 (Emotional Conversation):「這感覺安全嗎？」

這是最微妙也最危險的層次。客戶的情感猶豫很少說出口，但殺傷力極大。

核心在於建立信任，讓客戶對你的提案感到安全、有信心。

3. 解決方案：「共識階梯」(The Alignment Ladder)

與其一次性地在單一會議或 email 中處理所有問題，不如透過一個四步驟的「共識階梯」來逐步建立理解、共識與信任。

第一步：問題協議 (Problem Agreement)

在提出任何解決方案前，先與客戶就「問題是什麼」達成共識。

關鍵行動： 讓客戶用自己的話闡述問題，並將其記錄下來。詢問「如果問題不解決會怎樣？」以建立急迫性。

第二步：方法協議 (Approach Agreement)

針對已定義的問題，提出至少兩種不同的解決方向，並明確說明每種方法的優劣取捨（如：時間 vs. 預算 vs. 功能）。

關鍵行動： 讓客戶在權衡利弊後做出選擇，並確認需要參與決策的利害關係人。

第三步：檢查點協議 (Checkpoint Agreement)

逐步展示低保真度 (low-fidelity) 的工作成果（如線框稿、概念模型），目的是驗證結構與方向，而非視覺風格。

關鍵行動： 讓客戶感覺自己參與了建構過程，逐步建立熟悉感與安全感。

第四步：最終呈現 (Presentation)

當走完前三步後，最終的簡報不再是「說服」，而是「確認」。

關鍵行動： 重新串連起之前的共識（我們同意了什麼問題、選擇了什麼方法、驗證了什麼方向），展示最終成果，重點放在成果而非功能。

4. 如何面對「不」

當客戶說「不」時，不要急著為自己辯護，而是要去診斷問題出在哪裡。

回頭檢視是哪個對話環節出了問題：

邏輯崩潰？ 他們不相信你的方法能解決問題嗎？

政治崩潰？ 是否有重要的利害關係人被忽略了？

情感崩潰？ 他們是否對這個提案感到不安全或不信任？

我的心得

這場演講在我賣產品的經營上給了我很多想法，為了要開發出客戶需要的功能，我都是在 LINE 官方帳號上面做需求訪談，我的方式是先提出我的假設，然後直接問客戶有沒有需要，當累積到一定數量的正面回饋時我才會進行開發。

但依照 Coray 共識階梯的四個步驟，我這樣的做法忽略了讓客戶自行描述問題的機會，也沒有提供多個解決方案以及驗證方案是否為客戶所需，只有開發完後直接請客戶進行測試。

雖然客戶會提供一些回饋，但我會先以多數客戶共有的問題作為優先事項，也許因此失去了一些客戶的信任。另一方面我提出的假設可能對客戶來說無關痛癢，有的話不錯，但不是必要項目，可能要先跟客戶一起討論出最需要解決的問題是什麼，同時也要建立起有問題可以來找我的信任感。

​AI 世代的 WordPress：Elementor + CRM 整合的未來​

講者：Simon Huang

選擇這場的原因：想了解 CRM 產品

AI 摘要

這場演講由講者 Simon 主講，他是一位在北美有超過15年接案經驗的 WordPress 專家，專注於探討如何透過整合 Elementor、CRM 與 AI 自動化，將傳統的靜態網站轉變為能24小時工作的「最佳夥伴」。

1. 問題核心：你的網站只是「影片」嗎？

問題： 大多數網站只是靜態的展示頁面（像海報或影片），雖然美觀，但無法有效地與訪客互動或跟進潛在客戶。訪客填寫表單後，如果沒有即時且自動化的跟進，這些潛在商機就流失了。

結論： 一個沒有自動化跟進流程的網站，基本上是「無用的」。

2. 解決方案：三大工具整合

要解決這個問題，Simon 提出了三位一體的解決方案，將不同的工具串連起來，形成一個高效的自動化系統。

網站 (Website)： 使用 Elementor 快速建構。因為其拖拉式的介面非常直觀，即使非設計師也能在一天內完成網站，符合現代商業快速迭代的需求。

客戶關係管理 (CRM)： 導入任何適合的 CRM 系統。從高階的 Salesforce、HubSpot 到中小企業適用的 Zoho，甚至是講者自己開發的 Axl System。CRM 是整個自動化流程的核心。

人工智慧 (AI)： 整合 AI 工作流程（AI Workflow），特別是大型語言模型（LLM）的應用，讓系統能自動化執行後續任務。

3. 關鍵流程 (The Flow)

整合這三大工具的目的是實現一個完整的客戶旅程自動化流程：

訪客 (Visitor) → 網站 (Website)： 訪客瀏覽網站，從首頁到產品頁，最後進入聯絡或結帳頁面。

網站 → CRM： 訪客填寫表單或完成特定操作後，資料會透過 Webhook、API 或直接嵌入的表單，自動傳送到 CRM 系統。

CRM → AI 工作流程 (AI Workflow)： CRM 觸發 AI 自動化流程，開始執行一系列預設好的跟進行動，例如：

發送個人化 Email 或簡訊 (SMS)。

透過 Social Media 發送訊息。

提醒客戶預約或完成購買。

AI 工作流程 → 成交 (Deal Closed)： 透過持續、自動化的跟進，提高成交率。

4. 實施策略與工具選擇

工具選擇的哲學： 流程（Flow）比工具（Tool）更重要。先釐清你的商業流程，再選擇適合的工具去實現它。

Elementor 的優勢： 快速、簡單，適合快速產出。講者建議使用乾淨的 Hello Theme 作為基礎。

CRM 的重要性： 不要將自動化流程建構在 WordPress 內部，這會讓網站變得臃腫且緩慢。應將自動化任務交由獨立的 CRM 伺服器處理，保持網站效能。

如何「教導」AI： AI 就像一個嬰兒或新員工，你需要提供非常詳細、明確的指令（SOPs），它才能準確地執行任務。不要期待 AI 能「猜到」你的心思。

5. 案例分享與 Q&A

案例成效： 透過這套整合系統，講者的客戶成功提高了轉換率、增加了產能，並顯著降低了客戶預約未到的爽約率。

Elementor 與 WooCommerce 整合：

設計層面： Elementor 本身就能處理好 WooCommerce 的所有設計需求，不一定需要第三方外掛。

功能與自動化： 建議將自動化功能（如廢棄購物車提醒、追加銷售等）交由外部 CRM 處理，以維持網站效能。

自動化工具的選擇（N8N/Make vs. 獨立系統）：

N8N、Make、Zapier 這類工具適合在不寫程式的情況下串接不同的服務（如 HubSpot + Google Sheets）。

缺點： 當串接的服務過多時，維護會變得很複雜（只要一個環節出錯就很難排查），且 API Token 的費用會隨著使用量增加而變高。

獨立 CRM 系統（如講者自建的系統）的好處是將所有功能整合在一個生態系中，維護相對單純，且成本較可控。

我的心得

有些朋友建議我可以把外掛產品 SaaS 化，也就是不要只能讓 WordPress 使用，而是變成一個線上服務整合不同的平台，Simon 他們家的產品就是這樣的概念，從搜集客戶名單到付款完成通知的整個流程，都能在同一個平台上搞定。

他們的產品就我的理解有點像是帶有 CMS 功能的 n8n，除了可以設計自動化流程外，還能管理訂單、會員以及預約資料，同時也能付款做線上金流，但從網路上是沒有查到有 WordPress 相關的外掛或是 API，不太確定它是否能與 WooCommerce 整合。

對我來說，如果要做類似的平台需要花費的工程太浩大，而且與 WordPress 的功能有部分重疊，我個人是覺得以 WordPress 為基礎再加上自動化流程的功能會比較適合我。

​Engineering Maintainable WordPress Websites​

講者：Toru Miki

選擇這場的原因：想知道有經驗的工程師是如何維護 WordPress 網站

AI 摘要

這場演講的核心主軸是：不要只打造「堪用」的網站，要打造「能夠長久維運」的網站。 講者 Toru 認為，許多 WordPress 的糟糕體驗都源自於「低落的可維護性」。他從一個專業機構的角度，提出了四個關鍵實踐，來提升網站的品質與生命週期。

核心理念：軟體工程 = 程式設計 + 時間 (Software Engineering = Programming + Time)

引用 Google 的觀點，真正的「軟體工程」不僅是寫出能運作的程式碼，更要考慮到程式碼隨著時間演進所需的一切，包含修改、維護、擴展。

許多網站「只求能動，不求長久 (built just to work, not built to last)」，導致後續維護成本極高，讓開發者和客戶都感到痛苦。

提升網站維護性的四大實踐

1. 視錯誤日誌為金礦 (Treat Error Logs as Gold)

停止猜測：遇到問題時，第一步永遠是檢查錯誤日誌 (Error Logs)，而不是靠猜測或經驗。

確保日誌可及性：選擇的主機服務必須能方便地存取與查看日誌。他舉了一個廉價日本主機只能看「當天」日誌的反面教材。

日誌視覺化：利用圖表工具 (如 AWS CloudWatch) 將錯誤日誌視覺化，能快速辨識錯誤模式、頻率，並優先處理最嚴重的「致命錯誤 (Fatal Errors)」。

2. 謹慎選擇外掛 (Select Plugins Carefully)

超越功能列表：選擇外掛時，不能只看它提供了哪些酷炫功能，更要評估其「長期可行性 (long-term viability)」。

評估維護責任：檢查外掛是否被「負責任地維護 (responsibly maintained)」。

反面教材：一個外掛的安全性問題在論壇上被提出超過 9 個月，作者卻毫無回應，只更新了無關緊要的 CSS 樣式。

正面教材：一個佈景主題的作者在接到 Bug 回報後，隔天就迅速回應並推出修復。

記住：使用第三方外掛，等於是將網站一部分的責任「丟」給了別人，必須謹慎託付。

3. 關注點分離 (Separation of Concerns)

明確分工：

佈景主題 (Theme) 只該處理 呈現 (Presentation)。

外掛 (Plugin) 應該處理 功能 (Functionality)。

避免萬能的 functions.php：不要把所有客製化功能都塞進 functions.php。如果某個功能需要在更換佈景主題後依然存在，它就應該被寫成一個獨立的客製化外掛。

提升可發現性：將客製化功能模組化（例如用外掛隱藏後台選單，而不是在 functions.php 寫程式碼），讓非工程師也能輕易從外掛列表看出網站做了哪些修改。

4. 導入開發流程與自動化 (Implement Development Processes & Automation)

版本控制 (Version Control)：所有客製化程式碼都應該使用 Git 進行版控。

工作流程 (Workflow)：採用 拉取請求 (Pull Request, PR) 的工作流程，即使是單人開發也應如此。這能留下審查紀錄，並觸發自動化檢查。

靜態分析 (Static Analysis)：導入 PHPCS、ESLint 等工具，在開發階段就自動檢查程式碼是否符合規範、是否存在潛在錯誤。

CI/CD (持續整合/持續部署)：將測試、建置、部署等流程自動化。透過 GitHub Actions 等工具，確保每次部署前都通過所有檢查，大幅提升程式碼品質與穩定性。

我的心得

對於這場十分有感，之前經手的專案都是維護超過三年以上的 WordPress 網站，時間一久，很容易被自己寫的或是第三方外掛弄到，而現在自己在賣外掛，也很注意整個程式碼的品質，避免給客戶的網站帶來負擔。

Toru 提到在挑選外掛時，最好只挑僅有一種功能的外掛，不要選擇功能太多的，保持單一職責原則，我在接案時也是盡量秉持這樣的做法，不然就自己開發比較好維護，但換了位置換了腦袋，產品要好賣需要有賣點來行銷，因此開發商很容易不知不覺把產品加入了太多功能。

當我意識到這問題時採用的解決方法是額外建立擴充功能的機制，讓主外掛僅保留核心功能，當有客戶需要各別功能時再另外安裝擴充外掛，盡量讓主程式保持精簡。至於 Toru 介紹的單人 PR 工作流程我覺得很有趣，有機會來實作看看。

​從 WordPress Components 開始，打造你自己的區塊外掛​

講者：李東霖

選擇這場的原因：本次 WordCamp 唯一能看到程式碼的場次

AI 摘要

重點整理

這場議程介紹了如何使用 React 和官方的 @wordpress/scripts 套件，來進行 WordPress 區塊編輯器（Gutenberg）的進階開發。

1. 核心概念：WordPress 如何運行 React

傳統方法：過去在 WordPress 中載入 JavaScript 檔案，是使用 PHP 的 wp_enqueue_script 函式。

新方法 (React)：開發者編寫 React（JSX）程式碼，透過 @wordpress/scripts 這類的建置工具，將其**編譯（Compile）**成瀏覽器看得懂的單一 JavaScript 檔案。最後，再用傳統的 wp_enqueue_script 方式將這個編譯好的 JS 檔載入到 WordPress 中。

2. 關鍵工具：@wordpress/scripts

這是 WordPress 官方提供的開發工具包，大幅簡化了 React 的開發環境設定。

它整合了 Webpack，能自動處理程式碼的編譯、打包、相依性管理與版本控制。

安裝與啟動：

透過 npx @wordpress/create-block 初始化或手動安裝。

執行 npm start 即可啟動開發模式，它會即時監控 src 資料夾中的檔案變動並自動重新編譯。

3. 開發流程與架構

資料夾結構：開發的核心檔案都放在 src 資料夾，進入點是 src/index.js。

編譯結果：編譯後的檔案會自動生成在 build 資料夾，包含 build/index.js 和 build/index.asset.php（用於管理相依性）。

PHP 整合：在 PHP 檔案中，必須載入 build/index.asset.php，並使用 wp_enqueue_script 函式將 build/index.js 載入到 WordPress 頁面（例如 block_editor_assets）。

4. WordPress Components：加速 UI 開發

WordPress 提供了一個龐大的 UI 元件庫（@wordpress/components），包含按鈕（Button）、面板（Panel）、顏色選擇器（ColorPicker）、輸入框（TextControl）等預先設計好的元件。

開發者可以像逛街一樣，從官方文件中找到想要的元件，透過 import 匯入，再以類似 HTML 的語法直接使用，大幅提升開發效率。

5. 整合 AI 輔助開發

講者示範了如何利用 AI（如 ChatGPT）來生成 React 程式碼。

只要給予 AI 明確的指令（例如：「使用 WordPress components 創建一個包含標題和作者輸入框的設定面板」），AI 就能快速生成所需的程式碼，開發者再進行複製貼上與微調即可。

6. Q&A 重點

資料儲存：資料的存取是透過 wp-data 套件（WordPress 版本的 Redux）來管理。開發者需先在 PHP 中註冊 meta field，再於 React 中使用 useSelect 讀取和 useDispatch 更新資料。

TypeScript/Sass 支援：@wordpress/scripts 原生支援 TypeScript 和 Sass 的編譯。

套件版本問題：WordPress 的套件更新頻繁，名稱和用法可能改變。開發時需留意官方文件，確保使用的是正確的元件名稱和 API。

總結： 這場議程為熟悉 PHP 的 WordPress 開發者，提供了一條進入現代化 React 開發的清晰路徑。透過掌握 @wordpress/scripts 和善用內建的元件庫與 AI 工具，開發者可以更高效地為區塊編輯器打造豐富且原生的使用者介面。

我的心得

曾經與東霖一起合作接案過一段時間，對於他的開發能力沒話說，區塊外掛幾年前自己有手刻寫過，但早已失憶，透過東霖的介紹得知現在區塊技術目前的發展狀態，而且相關的 UI 元件庫非常豐富，很喜歡可以打造出原生 WordPress 介面的感覺。

每次看到外掛廠商重新設計一套自己的使用者介面時就會皺眉頭，因為這對使用者來說會產生額外的學習成本，也會讓開發者要重新造輪子，能夠利用 WordPress 原生的工具來打造應該會方便許多。

記得前幾年區塊的開發技術變化非常快，常常沒過多久就會出現新的套件或是建議寫法，所以寫到後來就沒力氣追下去了，這次聽完東霖的分享後覺得開發區塊的技術應該越來越成熟了，也許哪天又可以撿回來試試看，搭配 AI 應該就能很好上手。

​How to use AI agents to click, configure and care for Your WordPress site​

講者：Nathan Onn

選擇這場的原因：想學習如何使用 AI 管理網站

AI 摘要

這場演講的核心主軸是介紹如何使用「瀏覽器 AI 代理 (Browser Using AI Agents)」來自動化 WordPress 網站管理中重複、耗時的任務，從而解放開發者的時間，讓他們能專注於更有創造性的工作。

1. 什麼是瀏覽器 AI 代理？

定義：它是一種能像真人一樣操作瀏覽器的 AI。它可以瀏覽網頁、點擊按鈕、填寫表單，完成任何線上任務。

優勢：無需編寫程式碼，也不需要像 Zapier 或 n8n 這類複雜的自動化工具。

為何適用於 WordPress：WordPress 的後台是基於圖形介面 (UI-based) 設計的，專為人類點擊而生。因此，AI 代理可以無縫地模仿人類操作。

主要工具：演講中提到了 ChatGPT agents、Comet 等工具。

2. AI 代理的核心：清單 (Checklist) 的力量

成功的秘訣：要讓 AI 代理有效工作，關鍵在於提供一份極其詳細、步驟清晰的「清單」（也就是 Prompt）。

清單的作用：這份清單會明確指示 AI 該去哪裡、點擊什麼、輸入什麼數值，AI 會完全按照指示執行。

3. 如何建立有效的清單？(兩種方法)

「採訪我」方法 (Interview Me Method)：

你先給 AI 一個大概的想法（例如：建立一個電商網站）。

AI 會反過來問你一系列詳細的問題（例如：稅率多少？用什麼金流？），直到它有 95% 的信心能完成任務。

你回答完所有問題後，AI 會生成一份完整的、可執行的詳細清單。

「錄製我」方法 (Record Me Method)：

你親自操作一次任務，並用螢幕錄影軟體把過程錄下來。

將影片上傳給能處理影片的 AI（例如 Gemini）。

AI 會分析影片中的每一步操作，自動生成一份詳細的步驟清單。

4. 實際應用範例

從零建立 WooCommerce 網站：

講者展示了一段影片，AI 代理根據一份預設好的清單，自動完成了安裝外掛、設定網站時區、設定稅率、設定複雜的運費規則（基於重量）、設定 Stripe 金流、建立產品及多規格選項、設定優惠券等所有繁瑣步驟。

完成後，AI 代理甚至還進行了一次「結帳測試」，以確保整個流程正常運作。

安全地更新外掛：

展示了另一個情境，AI 代理被要求更新網站外掛。

它遵循了安全的標準作業流程 (SOP)：先備份 -> 逐一更新外掛 -> 每更新一個就檢查網站是否出錯。

當更新某個外掛導致網站出現嚴重錯誤時，AI 能偵測到問題、自動停用出錯的外掛，並在最後生成一份報告，清楚說明哪個外掛更新成功、哪個失敗以及它採取了什麼行動。

5. 如何安全地使用 AI 代理？(三大規則)

風險管理：講者認為 AI 並未帶來新風險，而是幫助我們更好地管理既有的風險（如人為疏失、忘記更新等）。

規則一：不洩漏憑證：絕不直接給 AI 你的帳號密碼。應使用「無密碼登入」外掛或手動登入後再讓 AI 接手。API Key 等敏感資訊應儲存在 wp-config.php 中，而非資料庫。

規則二：在測試環境工作：永遠讓 AI 在 Staging (測試站) 環境中操作，絕對不要直接在正式上線的網站上執行。在測試站確認一切正常後，再手動同步到正式站。

規則三：永遠先備份：在進行任何重大變更前，務必進行完整備份，並確保你知道如何還原。這是無論是否使用 AI 都應遵守的基本原則。

結論與挑戰​
講者鼓勵聽眾拋棄重複性的勞動，將時間投入到真正有價值的工作上。他提出的挑戰是：

• 找出一個你本週做過的重複性任務。
• 為這個任務創建一份清單。
• 將清單交給 AI 代理執行。
• 親身體驗自動化的強大，並思考「為什麼我還要手動做這些事？」

我的心得

我在開發的時候用過 Playwright MCP 讓 AI 操作瀏覽器做測試與除錯，但執行的速度慢到總是讓我忍不住跳下來自己處理，因此對於目前的 AI 瀏覽器我一直抱持著觀望的態度。

在聽了這場後讓我大開眼界，驚艷的地方不是使用 ChatGPT Agent 速度有多快，而是 Nathan 示範如何透過 AI 產出一份超～長的待辦清單，然後讓 AI 用這份清單來執行操作，這份清單詳細到每個按鈕的點擊、檢查哪些內容、對應的處理行為等等。

待辦清單除了可以自己先文字敘述讓 AI 來反問你之外，我覺得最方便的還是透過錄製影片後，請 AI 分析影片中的內容來整理最直覺，目前 ChatGPT Agent Plus 方案查到說一個月可以用 40～50 次，要拿來練習應該是夠用。

我一直想要做一個新的英文版網站，然後把以前寫過的文章翻譯成英文後貼過去，之前自己手動做了幾篇之後就放棄了，剛好現在可以把這當作第一個實驗項目。

​在台灣做 WordPress，商模還能怎麼玩？一場從接案到自助開站的轉型故事​

講者：許皓 (站長路可)

選擇這場的原因：想學習商業模式

AI 摘要

這場演講由「站長路可」分享他從零開始的創業歷程，核心在於如何從傳統的接案模式，逐步轉型為一個可規模化、自動化的網站服務商業模式。

1. 創業起點：從接案到自我修煉

背景： 講者自稱「沒有富爸爸」，從零開始，透過自學 WordPress 與數位行銷技能，展開接案生涯。

初期心態： 不怕被客戶「凹」，將每個案子都視為學習與修煉的機會，因此累積了大量實戰經驗與客戶口碑。

模式瓶頸： 接案模式的天花板很低，營收很難突破每月20萬，因為完全依賴個人時間與勞力。

2. 商業模式轉型：建立自媒體與線上課程

建立品牌： 創立「站長路可」自媒體，透過撰寫專業長文並下廣告的方式，累積了第一批精準粉絲。

知識變現： 將接案過程中累積的經驗（如架站、下廣告）製作成線上課程，成功將「服務」轉化為可規模化的「產品」。

成效： 透過線上課程，成功達到年營業額破千萬的成績，證明了知識產品化的巨大潛力。

3. 規模化的關鍵：自動化與經銷商模式

痛點發現： 意識到傳統接案者即使在度假時也需處理客戶問題，生活品質低落，因此萌生了「自助開站」的想法。

技術導入： 找到一種能讓客戶在線上付費後「自動開站」的技術，客戶下單後，系統會自動建立 WordPress 網站、設定帳密並寄送教學文件。

經銷商機制： 為了進一步擴大市場，他建立了一套經銷商系統：

賦能他人： 讓不懂技術的合作夥伴（如他的學員、各領域老師）也能擁有自己的「網站商店」，銷售他預先做好的模板網站。

利潤共享： 經銷商可以自行定價，賺取其中的利差。

客服分離： 建立一個中立的客服系統，直接服務終端客戶，讓經銷商完全不必處理技術問題。

成果： 這個模式成功地讓商業規模快速擴大，其中一位經銷商甚至賣出了超過500個網站。

4. 底層架構的升級之路：從共享主機到 K8s

為了支撐不斷擴大的業務並降低成本，講者分享了他一路以來的主機架構演進，這也是整場演講最硬核的部分：

階段一：共享主機 (Shared Hosting)： 初期最常見的選擇，但效能有限。

階段二：VPS (Virtual Private Server)： 為了更好的效能與控制權，升級到 VPS。

階段三：自建實體主機 (Bare Metal) + 虛擬化： 為了極致的成本控制，他開始自己購買硬體、組裝伺服器，並學習虛擬化技術，將一台實體主機切分成多個 VPS。他比喻這就像自己買生豆來烘焙，成本能降到外購的三分之一。

階段四：IDC 機房 (Co-location) + K8s (Kubernetes)： 這是目前的階段。將自己的實體主機託管到專業的 IDC 機房，並導入 K8s 容器化架構。

優勢： K8s 能實現「水平擴展」，當網站面臨瞬間大流量時，系統能自動開啟多個「分身」（容器）來分擔負載，確保網站穩定。同時，它也提高了資源使用效率與後台操作速度。

5. 核心心法與結論

商業模式的演進是關鍵： 從勞力密集的接案，轉向知識產品化，再到平台化與經銷商模式，是實現規模化成長的必經之路。

技術是護城河： 不斷升級底層架構，雖然過程痛苦且充滿挑戰，卻是降低成本、提升服務品質、並建立競爭壁壘的核心。

解決自己的痛點，就能找到商機： 整個創業歷程都圍繞著解決自己作為一個接案者所遇到的問題，並將解決方案產品化。

我的心得

與路可合作過幾年的時間，對於他創業的歷程與回饋社群的心讓我佩服不已，我有許多跟我買外掛的客戶也都是他介紹來的，更不用說合作期間他讓我過上好幾年穩定的生活，並讓我現在有底氣經營自己的事業，他絕對是我生命中的貴人之一。

這場演講他提到的許多痛點我也踩過，也讓我思考不做主機與課程的路線外，只靠開發產品該如何生存下去，也許是增加產品線或是進入國際市場，我還在實驗適合自己的模式，但不管如何，每次的實驗都會讓我想到「路可」的精神：努力找到可以走下去的那一條路！

Dev with WP

今年參加 WordCamp 發現不少我完全不認識的開發者，想要跟他們交流卻沒有空檔，雖然很多人說在台灣開發 WordPress 的工程師不多，就檯面上那幾位常露面的大大，但就我的了解有不少大神都很低調，想要交流不太容易。

另一方面，事實上有很多開發者做了很多很厲害的東西，身為開發者，我很想多跟大家做深度的交流，因此掙扎許久後，還是決定開一個專注在 WordPress 開發的 LINE 社群，希望可以跟其他開發者學習以及做經驗的分享，甚至未來有機會可以辦專為開發者的小聚。

如果你有開發過 WordPress 的佈景主題或是外掛、幫客戶加過客製化程式碼，甚至是想要入坑學習 WordPress 開發，都非常歡迎加入。在這邊你可以分享你完成的小功能，或是花了好幾個月時間開發的大型外掛，也能獲得各位大大的開發經驗，像是如何透過 AI 加速開發以及開發工具，希望透過這些交流讓彼此少走一些開發歪路，讓大家一起學習成長！

有興趣的大大可以透過此連結加入喔：

​https://line.me/ti/g2/0e11jWdIE4PTZD_NVfODxyFXLR_hSj1JRqbqCA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default ​

結語

花了兩天時間終於把七場演講的內容整理出來了，另外我沒聽的七場就等其他大大接力分享了，最後附上逐字稿，有些場次我遲到&早退以及收音不太好，沒有完整的話還請見諒：https://docs.google.com/document/d/1lAI0LRtR8K8vG2KCM9flK8lKetpZ1CwAkUoHDok1gko/edit?usp=sharing​