客服信箱一早跳出十幾則表單通知，其中三封寫著報價、兩封問技術問題，剩下五封什麼都提到一點，分類欄位卻只填了「其他」。WPForms、Fluent Forms 這類外掛內建的條件邏輯只認得使用者自己勾選的固定選項，填表單的人為了省事隨便勾一個類別、或乾脆把細節全塞進留言欄，後台看到的分類標籤跟留言內容實際講的事常常對不上，還是得靠人一封封重新讀過才知道該轉給誰。
這幾年開始有人讓語言模型直接讀那段自由填寫的文字來判斷。這裡說的 WordPress AI 表單，指的正是表單送出之後交給 AI 判讀內容再自動分流的做法，不是表單本身怎麼設計出來的。這件事值得做，是因為它補上了現有分類機制的最大缺口，選項式勾選管得到使用者自己選了什麼，管不到使用者實際寫了什麼。搞懂三段骨架該怎麼接，就能把後台從被動等人工分類，變成送出當下就先分好類。
表單串 AI 是什麼？從留言內容直接判斷分類
整套機制可以拆成三段骨架：觸發、判讀、動作。表單外掛收到使用者送出的資料是觸發；把其中自由填寫的文字欄位，通常是需求說明或留言內容那一欄，交給語言模型讀，模型回傳一個類別標籤，像是報價詢問、技術支援、合作邀約、疑似垃圾訊息，這是判讀；拿到標籤之後，系統依標籤做不同處理，例如寄不同的通知信、在後台加標籤、觸發不同的自動回覆，這是動作。三段接起來，填表單的人不需要自己選任何分類，分類是 AI 讀完內容之後幫他決定的。
這跟 AI 幫你生成表單是完全不同的兩件事，而且很容易被搞混。WPForms 官方功能頁列出的 AI 功能，主打的是表單本身的建立與編輯：用一句話描述需求就能做出整張表單、用 Smart Edit 以對話方式修改既有表單、AI Choices 功能能幫下拉選單或核取方塊產生選項內容。這三項功能全部發生在表單建立的階段，也就是在後台設計這張表單的時候用得到，跟表單送出之後那段文字該怎麼判讀，是完全不同的時間點與用途。該頁完全沒有提到送出內容要怎麼做語意分類；這點正好說明，裝了這類主打建表單的外掛，不代表網站就自動具備讀懂留言內容、自動分類的能力，這兩件事得分開看。
搞懂這個分工之後，下一個問題是為什麼要多花工夫接 AI，而不是直接用外掛內建的條件邏輯就好。
客戶自己勾的類別，常常跟真正的需求對不上
WPForms、Fluent Forms 這類外掛原生就有條件邏輯，可以依欄位值分流通知信、或依選項顯示不同欄位，這套機制本身沒問題，問題出在它只認得使用者自己勾選的固定選項，下拉選單、單選題這種預先設好答案的欄位。碰到一大段自由填寫的文字，條件邏輯完全讀不懂，只能放著不管。
填表單的人也不會照著設計者的期待乖乖分類。為了省事隨便勾一個看起來差不多的選項是常態，或者乾脆整個跳過分類欄位、把所有細節一股腦寫進自由文字欄，理由很單純，分類欄位的選項永遠不夠貼近他實際想講的事。結果就是後台看到的標籤，跟留言內容實際在講的事對不上：標成一般諮詢的信，內文其實在問報價；標成其他的信，可能就是最急的那一封。
AI 分類補的正是這個缺口，它不靠使用者自己選，而是讓模型直接讀那段自由文字的內容去判斷。WPForms 官方功能頁在 Smart Conditional Logic 的說明裡提到，既有功能可以「Route form responses to the right department or team, automatically」，能自動依既定路徑轉送到對的部門。但要留意這項既有的自動路由功能，運作基礎仍是 AI 事先生成好的固定選項清單讓使用者去選，本質上還是選項式分流，不是讀懂自由文字語意去判斷。這也是為什麼接下來要講的三條路徑，做的都是同一件比它更進一步的事，讓 AI 直接讀內容，而不是讓使用者先選好一個近似值。
串接前要弄清楚的三個角色分工
表單外掛收資料、AI 模型判讀文字、串接工具把兩邊接在一起，後面幾種做法其實都是同一套骨架換零件而已。表單外掛，像 WPForms、Fluent Forms，扮演觸發角色，負責收使用者送出的資料；AI 模型，OpenAI 的 GPT 系列或其他語言模型，扮演判讀角色，負責讀那段文字、判斷屬於哪一類；串接工具則負責把表單的觸發事件跟 AI 的判讀動作接在一起，再決定判讀完之後要做什麼動作。
差別在於這三個角色有沒有被打包在同一個外掛裡。有些做法把判讀跟串接直接內建進表單外掛本身，Fluent Forms Pro 原生就整合了 ChatGPT，不必另外找工具，設定步驟最少。有些則要另外裝一支專門做觸發與動作串接的外掛或平台，把原本各管各的表單外掛跟 AI 服務接起來。先弄清楚這個分工，才知道自己實際要裝的是一個外掛還是兩個、要另外申請的帳號有哪些，這也決定了接下來三條路徑各自的門檻高低。
先看第一條路徑，本來就在用 Fluent Forms 的話，原生整合能讓你完全不必碰到串接工具這個角色。
路徑一，用 Fluent Forms 內建的 ChatGPT 整合直接串
Fluent Forms Pro 原生支援 ChatGPT 整合，不需要另外裝任何串接外掛。在 Fluent Forms 的全域設定裡連上自己的 OpenAI 帳號之後，就能直接在表單的動作設定裡加一個送給 ChatGPT 判斷的步驟，把某個欄位，通常是需求說明那欄自由文字，當作提示詞內容送出去，模型回傳的文字可以存進表單的隱藏欄位，或者直接當作後續動作的判斷依據。
這條路徑的優點很明確，設定步驟最少，不必額外申請自動化平台的帳號，前面提到的三個角色裡，串接工具這個角色直接被表單外掛內建吃掉了。限制也同樣明確，整套做法只綁定 Fluent Forms 這一款表單外掛，而且要用到付費的 Pro 版本才能開啟。
先在全域設定連上自己的 OpenAI 帳號
實際串接的第一步，是進 Fluent Forms 後台的 Global Settings，找到 Configure Integrations，選擇 ChatGPT Integration，填入自己在 OpenAI 後台申請的 API 金鑰完成連接，再選擇要用的模型。Fluent Forms 官方的 ChatGPT 整合說明頁確認這項功能標示 Plan Needed 為 Pro、Connection Type 為 Direct Integration，操作路徑就是 Global Settings、Configure Integrations、ChatGPT Integration 依序點選；可以選用的模型含 GPT-4、GPT-4 Turbo、GPT-4o、GPT-4o mini。
這一步要先在 OpenAI 建立帳號、綁定計費方式，才申請得到 API 金鑰，這部分屬於 OpenAI 平台本身的申請流程，跟 Fluent Forms 這款外掛無關。金鑰申請完成之後直接貼進上面那個設定欄位就完成連接，不需要再回 OpenAI 後台做任何額外設定。
表單欄位對應進提示詞就能拿到分類結果
金鑰連上之後，下一步是把表單欄位對應進提示詞。實務上的做法是把需求說明欄位的內容塞進提示詞，並要求模型只回傳類別名稱本身、不要多餘說明，這種輸出格式的限制很關鍵，寫提示詞的細節留到後面專門一節展開，這裡只需要知道這一步在做什麼：欄位對應完成、提示詞送出之後，模型就會回傳一個類別名稱。
取得回傳結果之後，可以直接存進表單的隱藏欄位，方便後台之後查詢比對；也可以當作後續動作的判斷依據，例如依類別決定通知信要寄給哪個收件人、或依類別觸發不同的條件式內容。這一步操作本身沒有額外需要具名佐證的數據，延伸的都是上一節 Fluent Forms 官方整合文件已經確認過的既有設定介面。
如果本來用的不是 Fluent Forms，而是 WPForms 這類沒有原生 ChatGPT 整合的外掛，就得換一條路徑，接下來的 Uncanny Automator 正是為了這種情況設計的。
路徑二，用 Uncanny Automator 幫任何表單外掛接上 AI
Uncanny Automator 是一款專門做觸發與動作自動化的外掛，可以把 WPForms、Fluent Forms 甚至其他它支援的表單外掛都當作觸發點，再接到 OpenAI，或 Claude、Gemini 等其他語言模型當作動作。它不綁定單一表單外掛，模型選擇也比原生整合更多，特別適合本來就在用 WPForms 這類沒有原生 ChatGPT 整合的人。
這條路徑另一個優點是免費版就能先測試效果好不好，不必馬上付費才能驗證分類準不準，這對還在評估 AI 分類值不值得導入的人來說，門檻比路徑一低不少。
免費帳號的額度和自帶金鑰兩種連結方式
連接 OpenAI 有兩種方式。免費版 Uncanny Automator 帳號會附贈一定額度的免費 credits，官方 OpenAI 串接說明頁明確寫出免費版會給 250 個免費 credits 可以直接用，不用自己申請 API 金鑰就能先跑一輪整合測試效果。
如果要長期使用或流量比較大，才需要另外自己申請 OpenAI API 金鑰、自行負擔 token 費用，或升級 Uncanny Automator Pro 版取得無限量使用。要留意免費版部分動作只能選到比較舊的 Curie、Babbage、Ada 模型，跟 ChatGPT 同款、支援 System message 欄位的 GPT 模型，需要用另一個叫 Use a prompt to generate text with the GPT model 的動作選項才能用到，挑動作的時候要對應選對，不要以為裝了免費版就自動能用到跟 ChatGPT 一樣的模型。
用觸發加動作兩塊拼出一個分類流程
Uncanny Automator 用 recipe 這個概念組裝流程，先選一個表單外掛當觸發，例如有人送出某張表單，再加一個 OpenAI 的動作，用提示詞產生文字。這個動作會把表單欄位資料當成提示詞的一部分送給模型，拿回一段文字當作後續可以引用的動作代碼；再加第二個動作，把這段回傳文字用在寄信、寫入文章紀錄，或接到其他外掛的後續處理上。
有一個限制要提前知道，在免費版裡，OpenAI 動作跑完拿到結果之前，後面接著的動作會先暫停等待，官方文件寫出等待 OpenAI 回應通常要 5 到 30 秒。流量大的網站如果每張表單都即時等這幾十秒，使用者在網頁上會明顯感覺卡頓，建議設定延遲，讓整個動作改成背景排程執行，而不是讓填表單的人乾等回應跑完才看到送出成功的畫面。
如果本來就在用 Zapier 或 Make 串接其他工具，像 CRM、Slack、Google 試算表，表單分類也可以直接併進同一套自動化裡，不必再另外裝 WordPress 外掛。
路徑三，不裝外掛改用 Zapier 或 Make 串接
用 Zapier、Make 這類通用自動化平台當串接工具，好處是完全不挑表單外掛，甚至連 Google 表單這種不是 WordPress 外掛的表單服務都能接上。Zapier 本身內建 AI by Zapier 的 Analyze and Return Data 這個現成動作，把文字分類進自訂標籤是它其中一種用途，不用自己從零寫判斷類別的提示詞框架，只要定義好幾個類別名稱，交給內建動作去跑就好。
Zapier 官方說明文件列出 AI by Zapier 目前的內建動作，核心是 Analyze and Return Data，可以依需求摘要、分類、擷取或產生資料，把文字分類進自己定義的標籤就是這個動作底下的一種用途，不必另外挑其他動作。同一份文件也寫明，透過 Zap 工作流程送出的資料是走 OpenAI 的 API，OpenAI 不會拿 API 送出的資料去訓練或改進模型，除非使用者自己明確選擇分享資料給這個用途。
這條路徑不是 WordPress 外掛，是完全在外部運作的另一個服務，適合本來就在用 Zapier 或 Make 串接其他工具的人，把表單分類也一併接進去。限制在於免費方案的可執行次數與流程複雜度都有上限，Zapier 官方定價頁確認免費方案每月只有 100 個 task，而且只支援兩步驟的 Zap 工作流程，也就是一個觸發加一個動作。分類流程至少需要觸發、AI 分類、通知或標記這三個步驟，免費方案連基本的三步驟分類流程都跑不完整，必須升級到支援多步驟的付費方案才能實際上線。
三條路徑各自的優缺點擺在一起看，最現實的差別往往不是功能夠不夠用，而是要申請哪種帳號、花多少門檻成本。
三條路徑最現實的差別是申請 OpenAI 金鑰的方式
Fluent Forms 原生整合最省事，不必另外申請串接工具帳號，直接在後台連上 OpenAI 金鑰就能用，但綁定這一款表單外掛，而且要用付費版才能開啟這個功能。Uncanny Automator 不挑表單外掛，免費額度可以先測試看看分類準不準，但長期使用通常還是得自己申請 OpenAI 金鑰、或升級 Pro 版才能穩定使用。Zapier 或 Make 完全不挑外掛，還能順便接其他工具一起自動化，但免費方案連基本的三步驟分類流程都跑不了，必須另外負擔一個自動化平台的月費。
三條路徑的共通點是最終都要有一組 OpenAI，或其他語言模型，的 API 金鑰或帳號額度，差別只在這組金鑰是自己申請、還是靠免費 credits 先頂著、或是包在自動化平台的訂閱費裡。給不同情境的建議：本來就在用 Fluent Forms 的人，直接走路徑一最省事；想先免費試水溫、而且熟悉 WordPress 外掛生態的人，適合走路徑二的 Uncanny Automator；本來就在用 Zapier 或 Make 串接其他工具、想把表單分類一起接進同一套自動化的人，才需要考慮路徑三。
不管走哪條路徑，決定判讀準不準的關鍵都不在串接工具怎麼選。
分類提示詞要靠類別定義、輸出格式與範例把答案釘死
決定 AI 判讀準不準的關鍵，不是選哪條串接路徑，而是提示詞怎麼寫。有幾件事要先做對。
第一、先把類別名稱列清楚，而且類別之間要互斥，例如報價詢問、技術支援、合作邀約、疑似垃圾訊息這幾種各自獨立、不會互相重疊。類別數量不要貪多，選項列得越細、彼此意思越接近，模型就越容易在相近的選項之間選錯，誤判率也會跟著墊高，抓在個位數以內、能各自清楚區分會比較穩定。
第二、明確要求模型只回傳類別名稱本身，不要多餘說明或標點。Zapier 官方部落格的教學示範了實際的提示詞寫法，在提示詞最後加一句「Return only the integer score, nothing else」，強制模型只回傳一個乾淨的數字，不夾帶任何解釋，這種格式化指令的邏輯可以直接類比套用到只回傳類別名稱的寫法上。少了這個限制，回傳的文字常常會夾帶一整段判斷理由與信心程度的說明，沒辦法直接拿去當自動化的判斷條件，後續動作也就沒辦法直接讀取。
第三、給一兩個範例句子跟對應的正確類別，也就是 few-shot 的做法，讓模型知道判斷的界線畫在哪裡。同一份提示詞教學裡示範的做法，是先給模型一個角色設定，再給出評分或分類的判斷邏輯，讓模型照著這套邏輯去套用到新的輸入內容，而不是憑空猜測。
第四、補一段角色設定，也就是 system message，交代這是哪一種業務的表單、判讀時該注意什麼細節。Uncanny Automator 官方文件說明 System message 欄位的作用，是加入上下文，讓模型知道該用什麼語氣、扮演什麼角色來回應，放進判斷這是哪一類業務、或分類要優先看哪個線索，能幫助模型抓對語境，不是只靠字面關鍵字硬猜。
這四件事做到位，分類流程才有機會穩定跑。
分類標籤能接進通知信、後台標記與自動回覆
分類結果出來之後，最基本的用法是依類別把通知信寄到不同信箱或收件人，報價詢問寄給業務，技術支援寄給客服，合作邀約寄給另一組窗口。進階一點的做法，是把類別寫進表單紀錄的備註或標籤欄位，方便後台直接用類別篩選、排序詢問單，不必再逐封點開才知道內容是什麼。
更進階的做法會依類別套用不同的自動回覆內容，但這裡有個提醒要先擺出來，自動回覆的文字內容建議接固定寫好的範本，不要讓 AI 直接生成對外發送的最終回覆文字，避免語氣或內容失控，詳細的把關原則留到後面專門一節展開。
WPForms 官方功能頁提到既有功能可以「Route form responses to the right department or team, automatically」，也能「Send different confirmation messages to users depending on the choices they select」，依使用者選擇的選項寄送不同的確認訊息。這說明分類完之後接通知信路由、接差異化回覆訊息，在既有外掛的設計裡本來就有對應的動作可以掛，差別只在原本這套動作是靠使用者自己選的固定選項驅動，現在改成用 AI 分類的結果去驅動同一套動作，操作介面不必重新學。
分類結果要送去哪裡是一回事，更前面一步，內容送進 AI 之前該不該過濾，也得先想清楚。
聯絡資訊不該送進語言模型的輸入內容
判斷類別通常只需要需求說明這類內容文字，不需要把姓名、電話、地址這些聯絡資訊一起送給 AI 模型。設計提示詞跟欄位對應的時候，只挑真正需要給模型判斷的那個文字欄位送出去，聯絡資訊留在表單紀錄裡、不進 AI 的輸入內容，這樣就能把外流風險降到最低，分類需要的只是這段話在講什麼，不需要知道這是誰講的。
這裡也有一個常被搞混的區別：透過 API 串接，Fluent Forms、Uncanny Automator、Zapier 走的都是 API，跟一般消費者直接用網頁版 ChatGPT，在資料使用政策上並不一樣。Zapier 官方說明文件在 OpenAI data usage with Zapier 這一段寫明，透過 Zap 工作流程送到 OpenAI 的資料是走 API，OpenAI 不會拿 API 送出的資料去訓練或改進模型，除非使用者自己明確選擇分享資料給這個用途。OpenAI 官方的企業隱私說明頁也同樣說明，透過 API 或商用方案送出的資料，預設不會用於訓練模型，這跟一般消費者版 ChatGPT 網頁版的預設資料使用方式不同，值得在導入前先弄清楚自己走的是哪一種。
也建議在網站的隱私權政策裡補一句，告知使用者表單內容可能透過 AI 服務進行自動分類處理，讓填表單的人知情，而不是悄悄把資料送出去判讀。
資料送出的範圍處理好了，接下來要面對的是 AI 判斷本身不會百分之百準確這件事。
AI 判斷之外，人工複核這一步不能省
分類偶爾會判錯，尤其是內容語意模糊、一段留言同時混著多種需求的時候，同一封信既問報價又問技術問題，模型得選一個主要類別，選錯的機率就會提高。如果連自動回覆或自動結案都全自動跑，一旦判錯，就會讓真正緊急或重要的詢問被晾在錯的分類夾裡，沒有人看到。
比較穩妥的做法，是讓 AI 分類先當作初篩、加標籤的角色，不是終局判斷。後台還是要固定檢查各個分類夾，尤其是保底的其他或無法判斷這類項目，確保沒有詢問被漏接。
牽涉到報價金額，或需要正式承諾內容的回覆，也不建議讓 AI 生成的文字直接對外發送。AI 在這類情境下只用來分類，不用來生成最終要送出去的正式回覆內容，這條界線跟前面提過的自動回覆接固定範本是同一個原則的延伸，AI 負責判斷屬於哪一類，人負責決定要對外講什麼。
確定了複核的分工之後，最後一步是在正式對外開放這套流程之前，先拿真實資料測過一輪。
上線前應該先拿舊詢問單測過準確率
上線前值得先做一次驗證，把過去累積的舊詢問單內容，或自己模擬幾種不同情境的測試內容，丟進設定好的分類流程裡跑一次，人工核對 AI 判斷的類別跟實際應該分到的類別對不對，找出容易判錯的情境，例如同一段留言同時問報價又問技術問題這種混合型內容，再回頭調整提示詞的類別定義或範例，把邊界案例補進 few-shot 裡。
確認誤判率能接受之後，才把會實際觸及使用者的自動通知或自動回覆這類動作打開。Zapier 官方部落格教學示範的流程裡有一步叫 Test Action，做法是先測試單一筆送出結果，確認回傳內容符合預期，才正式發布自動化，同樣的順序也適用在這裡：一開始只做分類、貼標籤這個最保守的動作，觀察一段時間，準確率穩定之後，再逐步打開後續會實際影響使用者的自動化動作。
填表單的人不會照著設計者的期待乖乖分類，這件事不會因為裝了哪支新外掛就改變；能改變的，只是後台要不要繼續花人力一封封重新讀過。把觸發、判讀、動作這三段接起來之後，分類從等人整理變成送出當下就先分好，後台看到的每一封，都已經知道該轉給誰、該用哪一種回覆。剩下要做到的是提示詞的類別邊界寫清楚、人工複核那一關別拿掉、上線前先拿舊資料測過一輪，這幾件事做到位，自動化才真正幫得上忙，而不是製造一批新的錯誤分類等人善後。