Perplexity AI 管理 WordPress：開發與維護實戰

你的 WordPress 網站突然噴出一片白屏，你把那段錯誤訊息貼進 Google，翻了五篇論壇討論、三篇早就過期的部落格教學，得到的結論互相打架，有人叫你關外掛、有人叫你改 wp-config、有人叫你直接換主機。一個下午就這樣不見了。實務上許多 WordPress 站都遇過類似情境，這種場景幾乎每個月都會上演一次，而 Perplexity AI 對 WordPress 維運人員最大的價值，從來不是「它會寫程式」，而是它把散落在 WordPress.org 官方文件、開發者手冊、外掛 changelog、GitHub issue 與核心 trac 票單裡的答案，即時拉成一份附上來源連結的摘要。

Perplexity 的基本功能與註冊方式及Perplexity AI 搜尋指南可先協助建立基礎。把 Perplexity 納入 WordPress 的開發、除錯、效能、資安與內容維護流程時，適合用它搜尋來源、整理可能原因與起草操作步驟；所有程式碼、設定與安全建議仍須對照官方文件，並在測試環境驗證後再上線。

為什麼 WordPress 維運特別需要一個「會附來源」的 AI

WordPress 的知識體系有一個很有趣的特性：它同時是全世界最受歡迎的內容管理系統，也是文件最破碎的系統之一。根據 W3Techs 的長期追蹤（2026 年 6 月），WordPress 在所有使用內容管理系統的網站裡，市佔長年維持在六成以上，整個網際網路有超過四成的網站跑在它上面。這個規模帶來一個副作用：同一個問題，你在網路上找得到 2012 年的舊解法、2018 年的過時外掛、2024 年的核心更新，三種答案混在一起，哪一個還有效，往往要你實際打開測試站才知道。

這正是 Perplexity 跟一般對話式 AI 最大的差異點。它的檢索優先（retrieval-first）設計，會在回答你之前先去抓一手資料，並且把每一段主張都掛上對應的網頁來源。對 WordPress 這種「官方文件、開發者手冊、外掛發行說明、社群討論」分散在十幾個地方的生態來說，等於它幫你做了一輪初篩。你問它「PHP 8.2 之後動態屬性的過時警告會不會影響 WordPress 6.x」，它不會憑印象回答，它會去翻 WordPress 核心的版本說明與 Make WordPress Core 部落格，再把結論還有原文連結一起給你。

換個方式想。你身邊如果有一位同事，每次回答你問題都會附上「我是從哪裡看到的、什麼時候更新的」，你是不是會比信任另一位「憑感覺講得很篤定」的同事更敢把任務交給他？對許多維運工作者來說，Perplexity 就是那位會附出處的同事。而 ChatGPT 跟 Claude 各有強項，但在「即時查證 WordPress 這種文件更新飛快的生態」這件事上，檢索優先的工具天生就佔便宜。

這對獨自顧站、或只靠一兩個人撐起整個 WordPress 維運的團隊來說，意義特別大。過去你要查證一個冷門 hook 的用法、或釐清某個外掛在不同版本的行為差異，往往得翻論壇、問社團、甚至付費諮詢，整個流程要好幾天才有結論。現在有一個能即時把一手資料彙整成摘要、又附上連結讓你自行複核的工具，等於把「資深同事隨侍在側」這件事，變成每個人都能負擔的日常配備。這也是許多維運工作者會反覆向團隊強調的觀念：AI 在維運場景最大的價值，是降低取得可信知識的門檻，把你的時間釋放出來，留給真正需要人類判斷的決策與創意。

Perplexity 與 ChatGPT、Claude 在 WordPress 工作流的分工

很多人會問：已經在用 ChatGPT 或 Claude 了，還有必要再裝一個 Perplexity 嗎？答案是要看你拿它做什麼。這三套工具在 WordPress 工作流程裡其實是互補的，不是誰取代誰。搞清楚各自的強項，你才不會把查證類的工作交給一個擅長寫作的工具，把創意發想交給一個擅長檢索的工具，結果兩邊都做不好。底下這張表，是實際用了一輪之後整理出來的分工方式。

工作場景	Perplexity 的強項	ChatGPT / Claude 的強項	建議選擇
查某個 WP 函式或 hook 的目前用法	即時抓官方 Codex 與開發者手冊，附連結	依賴訓練資料，可能過時	Perplexity
起草一段 functions.php 客製邏輯	會附參考，但創意較保守	程式碼生成較靈活、較完整	Claude 或 ChatGPT
排查白屏、500、外掛衝突	能即時比對多方來源，附 changelog	推理能力強，適合拆解錯誤鏈	兩者搭配
把一段舊 PHP 程式碼重構成現代寫法	附官方遷移指南	重構品質較高	Claude
查證外掛漏洞、資安通報	即時抓 Patchstack、Wordfence、官方公告	訓練截止前的資訊	Perplexity
寫一篇 SEO 文章的初稿	附來源、事實查核較紮實	敘事與結構較有層次	看階段分工

說穿了，Perplexity 的位置是「研究助理 + 事實查核員」，Claude 跟 ChatGPT 則是「撰稿手 + 工程師」。如果你的工作大量需要查證（外掛相容性、版本差異、資安通報、官方政策），Perplexity 會為你省下無數開分頁的時間。如果你想深入了解 AI 工具之間的特性分野，站上也整理過一篇AI 工具總整理，可以對照著看。

把 Perplexity 丟進開發流程：五個每週都在用的查詢模板

光講觀念太虛。底下這五個查詢模板，是每週管理 WordPress 站常會反覆拿出來用的實戰動作。你可以直接把引號裡的問句改成你自己的情境，套進 Perplexity 的對話框。

範本一：自訂文章類型與 WP_Query 的草稿與查證

當需要在佈景主題新增一個「課程」的自訂文章類型（Custom Post Type），可以這樣問 Perplexity：「請依照 WordPress 6.x 目前最佳實務，給一段註冊 custom post type 名為 course 的程式碼，要支援區塊編輯器、有 archive 頁、menu_position 設在 5，並附上官方 register_post_type 的說明連結。」

它會回一段相對乾淨的程式碼，而且每個關鍵參數後面都會掛上 WordPress 官方開發者手冊的對應頁面。這個「掛連結」的動作看似雞婆，其實是關鍵防護網。因為 register_post_type 的參數會隨版本演進，過去很常用的 menu_icon 寫法、capability_type 預設值，在不同版本之間都調整過。有官方連結，你就能一鍵跳過去確認目前的有效值，免得自己盲目複製貼上一段三年前的範例。

需要撈資料的時候，可以把問題再推一步：「用 WP_Query 撈出過去三十天內、課程分類為線上、有設定特色圖片的課程，依照發佈日期降序，只回傳 ID 跟標題。請附上 WP_Query 官方參數說明。」這種問法的好處是它會主動提醒你一些容易踩雷的細節，例如 date_query 跟 meta_query 的巢狀寫法、posts_per_link（對，這個參數拼錯了，正確是 posts_per_page，這裡故意寫錯讓你感受一下這個坑有多常見）會被看漏的情境。更多把 AI 用在外掛與功能挑選的思路，站上也寫過一篇用 AI 找 WordPress 外掛的方法論，有興趣可以延伸閱讀。

範本二：Hook 與 filter 的查證，順便防 AI 幻覺

WordPress 的動作鉤點（action）與過濾器（filter）超過兩千個，記名字這件事交給 AI 最划算。但 AI 最經典的翻車現場，也在這裡。它會偶爾發明一個聽起來很合理、但其實根本不存在的 hook 名字，例如把 woocommerce_after_single_product_summary 拼成 woocommerce_after_single_product_summary_hook，多了一個尾巴，你複製貼上去，當然什麼事都不會發生。

這就是 Perplexity 的附來源設計最能救你的地方。可以刻意這樣問：「要在 WooCommerce 商品頁加入一段自訂 HTML，請列出 5 個可在 content-single-product.php 使用的 action hook，每一個都要附上 WooCommerce 官方文件或 WordPress codex 的連結，並標註目前版本是否仍然有效。」這個問句強迫它「附連結」，一旦它需要附連結，它就得真的去抓文件，不能只憑印象編。如果你對 AI 為什麼會這樣胡謅感到好奇，站上也寫過一篇AI 幻覺的成因與避免技巧，把背後機制講得很清楚。把這個問法記下來，它幾乎可以套用在所有需要查證的場景。

範本三：讀懂繼承來的舊外掛或佈景主題程式碼

很多 WordPress 維運人員接手網站時，最痛苦的常常不是要寫新功能，而是要搞懂前任工程師留下來的那一坨 functions.php。常見做法是把整段程式碼貼進 Perplexity（注意，要先把任何 API key、密碼、資料庫連線字串拿掉），然後問它：「這段程式碼做了哪些事？它用了哪些 WordPress hook？有沒有已經被官方標記為 deprecated 的函式？如果有，目前建議的替代方案是什麼？請附上官方 deprecated 函式清單的連結。」

它通常會給你一份相當有條理的拆解，例如「這裡用了 create_function，它在 PHP 7.2 以後被棄用、PHP 8.0 以後被移除，請改用匿名函式」，並附上 PHP 官方移除公告。這對判斷「這個站到底多久沒被照顧」是非常快速的健檢。實務上也會把這個動作跟安全檢查綁在一起，搭配資安掃描工具一起做，效率會比單看原始碼高很多。

範本四：從錯誤訊息反推衝突點

當 WordPress 後台或前台跳出一段你沒見過的錯誤訊息，與其在 Google 一頁一頁翻，可以直接把整段錯誤（包括 stack trace 如果有）貼進 Perplexity，問它：「這段錯誤訊息代表什麼？最可能的 3 個原因是什麼？每個原因對應到哪個外掛或核心檔案？請附上相關的 WordPress trac 票單或 GitHub issue。」

它的價值在於會幫你把錯誤訊息、外掛名稱、版本號交叉比對。例如你貼了一段關於 memory_size 的致命錯誤，它會告訴你這通常是某個圖片處理外掛在處理超大圖檔時觸發，並附上該外掛在 GitHub 上對應的 issue 討論，甚至會附上社群建議的 wp-config.php 記憶體調整寫法。這比你自己盲猜快太多了。再多走一步，你可以把同一個錯誤丟回 Perplexity，追問「這個外掛的開發者在這個 issue 裡給的 workaround 是什麼？有沒有進入某個版本正式修掉？」它會幫你把整個修補進度濃縮成兩三句摘要，你一眼就知道現在是該等更新、該降版、還是該直接換掉這個外掛。

範本五：WooCommerce 結帳流程的客製與除錯

如果你管的是電商站，WooCommerce 絕對是你花最多時間糾纏的區塊。結帳表單的欄位調整、運費邏輯、金流回傳的 hook，每一個都暗藏陷阱。可以這樣用 Perplexity：「想在 WooCommerce 結帳頁把公司統編欄位設為必填、並在訂單完成後把統編寫進訂單 meta，請列出需要的 filter 跟 action、對應的 WooCommerce 版本、以及 frontend 跟 backend 各要在哪裡掛鉤。請附 WooCommerce 官方開發者文件。」

它通常會回你一份相對完整的鏈路，從 woocommerce_checkout_fields 這個 filter 開始改欄位屬性、用 woocommerce_checkout_update_order_meta 把值存進訂單、再到 woocommerce_admin_order_data_after_order_details 把欄位顯示在後台訂單頁。每一個環節都附上官方文件的連結，你照著走，比自己翻十篇過時的問答回答快太多。結帳表單更細緻的欄位調整手法，站上也整理過一篇WooCommerce 結帳表單客製化教學，可以對照著操作。這套問法的核心精神，跟前面四個範本一樣：要求附連結，迫使 AI 去抓真實文件，把幻覺風險壓到最低。

維運層的實戰：用 Perplexity 排查問題、看懂報表

開發之外的另一半時間，WordPress 維運人員其實是在「救火」跟「看報表」。這兩件事 Perplexity 都能幫上忙，但用法要對。

白屏與 500 錯誤的第一時間判斷

白屏（White Screen of Death）是 WordPress 維運的國民病。標準 SOP 是：第一步先開 wp-config.php 的 WP_DEBUG，第二步把噴出來的 fatal error 訊息貼進 Perplexity，問它「這個錯誤最可能由哪一個外掛觸發？這個外掛最近一次更新有沒有相關的 issue？」。它會幫你快速指向嫌疑犯，省去你一個一個停用外掛的二分法苦工。這個動作看似簡單，但在接手一個裝了四十幾個外掛的客戶網站時，能為你省下至少一兩個小時。

需要強調的是，Perplexity 給你的是「嫌疑犯清單」，不是判決書。你還是要回到測試站實際驗證，這是底線。AI 給的是方向，方向對了，你的除錯就會快很多。

把 PageSpeed 報告餵給它，產出可執行清單

另一個 CP 值很高的用法，是把 PageSpeed Insights 的報告變成維運工作清單。Google 自己的 PageSpeed Insights 是公認的網站效能權威檢測工具，但它給的建議有時候技術味很重，例如「減少長任務」、「避免大量的版面位移」、「剔除轉譯阻塞資源」，對非工程背景的站長來說，讀完還是不知道下一步要做什麼。

做法是把網站的 PageSpeed 報告截圖或文字內容貼進 Perplexity，問它：「根據這份報告，請針對一個跑在 WordPress 上的網站，給 5 個今天就能做的具體動作，每個動作要附上預計能改善的指標（LCP / INP / CLS）跟難度評分。」它會回你一份清單，例如「啟用快取外掛（改善 LCP，難度低）」、「把首圖加上 fetchpriority 高優先順序（改善 LCP，難度中）」、「延遲載入下方摺疊區的圖片（改善 LCP 跟 CLS，難度低）」。這份清單你再拿去對照Core Web Vitals 完全攻略與我們整理的速度指南，就會有一套很完整的優化路徑。

講到為什麼速度這件事值得這麼費工，背後有非常扎實的數字支撐。Google 在 web.dev 的〈Why does speed matter?〉一文明白指出，載入時間每多一秒，使用者滿意度與轉換率都會明顯下滑。而早在 2020 年，Google Search Central 部落格就正式預告，網頁體驗訊號會成為排名因素之一。也就是說，網站速度早就不是「做心安」的裝飾品，而是會直接影響你的排名與營收。

外掛漏洞與資安通報的即時查證

WordPress 因為市佔率太高，一直是攻擊者的熱門目標，而絕大多數的入侵事件，源頭都是某個沒有及時更新的脆弱外掛。當你在社群或新聞看到某個你網站正在用的外掛傳出漏洞，第一時間把外掛名稱加版本號丟進 Perplexity 問「目前有沒有已公開的 CVE 或 Patchstack 通報？官方有沒有發佈修補版本？目前建議的處置是什麼？」，它會即時去抓 Patchstack、Wordfence、WPScan 跟外掛官方頁面，給你一份附連結的狀態摘要。這比你在十個網站之間跳來跳去快太多。資安防護的整體佈局，你也可以參考WordPress 安全外掛評比這篇，把工具補齊。

資料庫與備份的常識查證

資料庫是 WordPress 維運裡最少被談論、卻最容易讓網站在幾年後變慢的一環。wp_options 裡堆積的 transient、過期的 revision、沒清乾淨的 post meta，這些東西累積到一定程度，會讓你的後台開始卡頓、讓 WP-CLI 的查詢變慢。當你想動資料庫之前，先用 Perplexity 問清楚安全邊界，是非常省事的習慣。

可以這樣問：「想清理 wp_options 裡的 _site_transient 條目，請列出 3 個安全原則、2 個絕對不能碰的欄位（例如 siteurl、home、recently_activated），以及清理前應該做的備份動作。請附上 WordPress 官方對 wp_options 的說明跟 WP-CLI 的相關指令文件。」這種問法的好處，是它會強迫 Perplexity 去把官方文件、社群共識跟工具指令湊在一起，給你一份附來源的 checklist。你照著走，遠比自己在 phpMyAdmin 裡亂點保險。

備份這件事也是同樣的邏輯。很多人裝了備份外掛就以為高枕無憂，卻從來沒做過還原演練。可以把備份檔的格式、還原步驟丟進 Perplexity 問清楚，確認真的能在一個空白主機上把站救回來。這套演練的完整流程，站上備份教學裡有一步步拆解，建議每季跑一次。畢竟備份沒測試過，等於沒有備份，這句老話在 WordPress 維運圈從來沒失效過。

Comet 瀏覽器上線之後，WordPress 維運多了一條捷徑

2025 年 Perplexity 推出了 Comet，一套把 AI 直接內建在瀏覽器裡的產品，這對 WordPress 維運人員來說是個值得認真看待的進化（見 Perplexity 2025 年的 Introducing Comet 發布文）。它跟一般 AI 瀏覽器擴充功能最大的不同，在於它不只是「幫你總結這個分頁」，而是能跨分頁、跨操作去理解你正在做的事。

對 WordPress 維運的實際意義是這樣：你現在可以一邊打開自己的後台、一邊打開 PageSpeed 報表、一邊打開某個外掛的設定文件，然後直接問 Comet「幫我比對我後台目前的快取外掛設定，跟這份效能報告提到的問題，最該先調的是哪一項？」它有機會把這幾個分頁的脈絡串起來給你答案。這在過去是你得自己複製貼上三方資訊才能做的事，現在門檻大幅降低。

保守的做法是這樣：把 Comet 用在「讀」跟「比對」，例如同步看幾份外掛的 changelog、比對兩個相似功能的工具的差異。但牽涉到「寫入」的動作（直接在後台改設定、安裝外掛、修改文章），還是回到原本習慣的流程，一步步確認。原因很簡單，AI 代理（AI Agent）在「理解意圖」上越來越強，但「執行後的可逆性」永遠是維運人員要自己把關的底線。如果你對這類自主代理工具的運作邏輯有興趣，站上也寫過一篇AI Agent 入門指南，把風險與機會都講了一遍。

給你一個特別能感受 Comet 價值的場景。假設你剛接手一個 WooCommerce 站，結帳轉換率一直偏低，你打開 Comet，一個分頁開著你的結帳頁、一個分頁開著 GA 的結帳漏斗、一個分頁開著一篇討論結帳摩擦點的長文，然後問它「比對我這個結帳頁跟這篇文章提到的常見摩擦點，最該先處理的是哪三項？」它能跨這幾個分頁把脈絡串起來，給你一份比你單看報表更立體的判斷。這條路徑在過去是你得自己把三份資料讀完再歸納，現在等於把歸納這一步交給了 AI。當然，最後的判斷跟動手改，還是回歸你自己。

用 Spaces 把一個網站的脈絡長期累積下來

Perplexity 有一個被很多維運人員低估的功能，叫 Spaces（空間）。簡單講，它是一個可以讓你把特定主題的對話、檔案、設定集中在同一個工作區的功能。對 WordPress 維運來說，它的價值在於「脈絡延續」。

假設你同時顧三個網站，你可以開三個 Space：客戶 A 的電商站、自己的部落格、某個非營利組織的官網。每一個 Space 裡，你可以上傳這個網站目前裝的外掛清單、佈景主題版本、wp-config 的關鍵設定（記得拿掉密碼）、過去遇過的錯誤紀錄。之後你在這個 Space 裡問任何問題，Perplexity 會把這些背景資訊納入考量，回答會更貼近這個站的實際狀況，省得你每次從頭解釋一次「我用的是 Astra 佈景主題、WooCommerce 9.x、PHP 8.2」。

這個用法對接案工作者尤其有用。你每接一個新客戶的 WordPress 維運合約，就開一個 Space，把它當成這個客戶的技術知識庫。三個月、半年後你回來處理同一個站，打開 Space，它還記得這個站的特性。這比你自己翻過去的 LINE 對話紀錄或筆記有效率得多。對照一下，網站維護的成本結構其實有很大一塊是「重新理解這個站發生了什麼事」，你可以在網站維護費用分析這篇看到完整的拆解。能降低「重新理解」的成本，等於直接壓低維運的人事開銷。

一個 WordPress Space 該放哪些資訊

為了讓你快速上手，下面這張表是每開一個客戶 Space 一定會放的資訊。這些東西放進去之後，你在這個 Space 問任何問題，回答的精準度會明顯提升。

資訊類型	具體內容	放進去的原因
環境設定	PHP 版本、MySQL 版本、主機商、WP 版本	避免 AI 給出過時或不相容的建議
外掛清單	所有啟用中的外掛名稱與版本	排查衝突時能直接交叉比對
佈景主題	主題名稱、子主題、是否用頁面編輯器	客製邏輯往往跟主題架構綁在一起
歷史事件	過去遇過的錯誤、做過的修補	避免重複踩同一個坑
已知地雷	不能升級的外掛、特定設定不能改的原因	防止 AI 建議你動不該動的東西

這張表真正的重點是持續更新。你不必一次到位，但每次解決一個新問題，就回頭把結論補進 Space，這個知識庫才會越用越聰明。把它想成你幫這個站寫的長期病歷，AI 則是讀著病歷幫你問診的助理，病歷越詳細，問診越準。

內容與 SEO 層面：Perplexity 怎麼幫 WordPress 內容站

如果你的 WordPress 網站是內容導向（部落格、媒體、知識站），Perplexity 還能在另一個戰場上幫你，那就是內容企劃與 SEO 研究。但這裡要特別小心，因為這也是最多人誤用 AI、把網站做爛的地方。

較穩妥的用法，是把 Perplexity 當成主題叢集的研究助手。以「WordPress 多語系」為例，可要求它根據指定的官方文件、論壇與公開討論整理候選問題，例如外掛選擇、TranslatePress 與 Polylang 的差異、效能影響及 hreflang 設定。這份清單只能作為初步骨架，仍要用 Search Console、關鍵字工具、客服紀錄或訪談驗證實際需求與優先順序。

但錯誤的用法，是直接叫 Perplexity 「幫我寫一篇關於 WordPress 多語系的 3000 字文章」，然後複製貼上發佈。這是把一句常被強調的原則反面示範：內容要為真人而寫，為機器人而優化。AI 量產、沒有第一手經驗的內容，正是 Google 在AI 搜尋時代的 SEO 全攻略這類討論裡反覆警告的地雷。Google 官方的立場一直很清楚，它要的是有幫助、以人為本的內容（見 Google Search 的 Create helpful, people-first content 說明）。而根據 HubSpot 整理的行銷報告，已經有相當比例的行銷人員把 AI 用在內容產製的某個環節，但同時讀者對「明顯 AI 味」內容的疲勞也快速上升（HubSpot Marketing Statistics 引自 2026 年 State of Marketing Report）。結論是，AI 可以幫你研究、幫你起草、幫你查證，但最後署名上線的那份經驗跟觀點，必須是你自己的。WordPress 站的整體 SEO 佈局，你可以對照WordPress SEO 全攻略這篇一起看，會更完整。

三個常見、你也會踩的坑

講了這麼多好處，接下來這段可能比前面都重要。底下這三個坑，都是許多維運人員（還有很多同行）真的踩過的，列出來讓你少走點冤枉路。

坑一：把過期的 Codex 答案當現行解

Perplexity 雖然會附來源，但它附的不一定是「最新」的來源。它有時會抓到一篇 2016 年寫得很好的教學，給你一個已經被官方停用的函式。防禦動作是：任何牽涉到具體函式名、hook 名、參數名的回答，都要再點進它附的連結，確認那份文件的更新日期，並且交叉比對一份官方 developer.wordpress.org 的頁面。養成這個「點開來源看日期」的習慣，是 WordPress 維運人員活下來的基本功。

坑二：把 AI 起草的程式碼直接送上正式站

這聽起來很基本，但每天還是有大量的人在犯。Perplexity（或任何 AI）給你的程式碼，預設是「看起來合理」，不是「已經測過」。正確的流程是：先丟到本機或 staging 站，開 WP_DEBUG，跑過你想得到的情境，確認沒有 deprecated notice、沒有 fatal error，再考慮上線。實務上建議永遠保留一個跟正式站等比的測試站，這筆錢不能省。如果你還沒建立備份跟還原的安全網，先從UpdraftPlus 備份教學跟WordPress 備份與還原這兩篇開始，把保險做好，再來談任何 AI 自動化。

坑三：把 Perplexity 當萬能助手，忽略它在 WordPress 之外的盲點

Perplexity 對 WordPress 生態很熟，但你的網站不只有 WordPress。它對你的主機商後台、你的 CDN 設定、你的 Cloudflare rules、你的特定付費外掛授權機制，理解往往很表面。當問題出在這一層，不要過度依賴它的判斷，直接去找該服務的官方文件或客服，會比跟 AI 對話快。AI 是助理，不是你外包出去的維運公司，這條界線劃清楚，你才不會在最該找人類專家的時候，繼續跟機器人耗。

跟 Claude Code、MCP 搭配的雙工具工作流

如果你想再往前走一步，把 Perplexity 跟 Claude Code 搭配起來，會得到一套目前最順手的 WordPress 工作流。簡單講就是「Perplexity 負責查證、Claude Code 負責執行」。遇到一個問題，先用 Perplexity 把背景釐清、把官方文件抓出來、把可能的解法附上來源列出來。確定方向之後，再交給 Claude Code 在程式碼庫裡實際動手改、跑測試、產生 diff。

更進階的玩法，是透過 MCP（Model Context Protocol）讓 Claude Code 直接跟你本機的 WordPress 檔案、資料庫、甚至外掛資料夾連動。等於你的 AI 助理不再只是「給建議」，而是「真的能動手」。這套搭配站上也寫了一篇完整的Claude Code 搭配 WordPress 的 MCP 實戰，把架設流程跟注意事項都記下來了，這裡就不重複。你只要記得一個原則：查證交給檢索優先的 Perplexity，執行交給能動手的 Claude，兩者各司其職，你會比單押一個工具的人效率高一截。

訂閱前的現實考量：免費、Pro、Max 的差異

截至 2026 年，Perplexity 個人方案包含 Free、Pro 與 Max，模型、Research、檔案和其他功能額度各不相同。Free 提供基本搜尋與少量進階查詢；Pro 提供進階模型、較高用量與檔案功能；Max 則提供更高的模型和進階功能額度。原本稱為 Spaces 的工作區目前稱為 Projects，可集中對話、檔案與自訂指令。團隊若需要席次管理、共用資料庫與企業資料政策，應另外比較 Enterprise Pro 與 Enterprise Max。實際額度仍以Perplexity 官方方案表為準。

建議是這樣：如果你一週只開 WordPress 後台一兩次，只是個人部落格等級，免費版就夠用，先別花錢。如果你是接案工作者、電商站長、或同時顧一個以上的網站，Pro 幾乎是必要投資，它為你省下的時間，遠超過每個月那點訂閱費。把這筆開銷放進你網站的維運成本裡一起看，會發現它其實很小，相關成本結構可以對照WordPress 架站費用這篇一起估算。

團隊導入時還有一個配套特別建議：把 Perplexity 的使用規範寫進你的維運手冊，明訂哪些情境可以用、哪些情境必須有人工複核、哪些機敏資訊絕對不能貼進任何 AI 工具。這份規範跟你的密碼管理政策、備份政策，是同一個層級的基礎建設。很多團隊導入新工具時只談「能做什麼」，忘了先界定「不能做什麼」，結果就是有人不小心把客戶的資料庫連線字串、或訂單裡的個資貼進對話框，造成難以挽回的風險。先把紅線畫清楚，再談效率，順序對了，工具才會是助力。

三十天上手行動方案

這份計畫有個前提：你已經有一個可以放手實驗的測試站，以及一份最新版的外掛與主題清單。如果連這兩樣都還沒就位，先把基礎打穩再回來跟進。AI 工具放大的是你既有流程的效率，一個混亂的站加上再聰明的 AI，產出的還是混亂。底下的節奏刻意排得很慢，因為真正的目標，是讓你三十天後把這套工具內化成直覺，會用只是起點。每天推進一點點，比週末熬夜狂學一輪更容易養成長期習慣，這也是把計畫拆成週為單位的原因，慢慢來反而走得遠。

看到這裡，如果你打算真的把 Perplexity 用起來，這裡幫你把動作拆成三十天的上手計畫，不要一次學全部，按這個節奏走，一個月後你會把它內化成自然的維運工具。

1. 第 1 到 7 天，只做查證。把你這週遇到的所有 WordPress 問題，無論大小，先丟進 Perplexity 問一次，再決定要不要動手。目標是養成「問之前先附來源」的習慣。
2. 第 8 到 14 天，建立第一個 Space。挑一個你正在顧的網站，把它的外掛清單、佈景主題版本、主機環境、最近遇過的錯誤，整理成 Space 的背景資訊。之後這個站的問題都在這個 Space 裡問。
3. 第 15 到 21 天，跑一次完整健檢。把這個站的 PageSpeed 報告、外掛清單、PHP 版本、最後更新時間全部丟進 Perplexity，請它列出風險跟優化建議，產出一份可執行清單。
4. 第 22 到 28 天，嘗試開發協作。挑一個小需求（例如新增一個自訂短碼、調整 WooCommerce 商品頁佈局），用本節五個範本的問法，讓 Perplexity 起草，你在測試站驗證、修改、上線。
5. 第 29 到 30 天，回顧跟優化。把這一個月問過的問題瀏覽一次，整理出你自己的提問模板，存成筆記。找出哪些問法效果最好，哪些會得到錯誤方向，建立專屬你的提問資料庫。

走完這三十天，你大概會發現一件有趣的事：你問問題的方式變精準了，這其實比拿到答案本身更珍貴。當你學會把問題拆得夠細、把需求講得夠清楚，任何 AI 工具給你的回饋品質都會跟著提升，這個能力會跟著你一輩子。工具永遠是工具，能不能把它變成你維運流程的一部分，關鍵還是在於你願不願意先把基本動作練紮實。WordPress 這套系統的最大優點是彈性，最大風險也是彈性，而 Perplexity 幫你做的是把「理解這個彈性系統」的成本降下來，讓你把省下的心力，留給真正只有人類能做的事：判斷、決策、與對使用者的同理。把這條界線顧好，AI 才會是你的副駕，而不是把你帶進雷區的駕駛。