|
最近常用 AI 產生程式碼,結果一堆程式自己都看不懂,只有錯誤發生時才會回頭研究到底寫了什麼。想說乾脆寫篇文章記錄一下,當作學習筆記。本篇主題是 OpenAI API 與 WordPress 的整合,讓 AI 能直接操作 WordPress。 初探工具請求(Function calling)像 GPT 這類自然語言模型是靠訓練資料回應問題,但資料若過時,或想取得即時資訊,模型本身無法處理。這時可以透過「工具請求(Function calling)」來解決。 原理是:先告訴 AI 有哪些工具可用,當對話中出現相關需求,AI 就能自動判斷是否要使用某個工具。這些工具可以是 WordPress 的函式(如 WP_Query 查文章),也可以是外部 API(例如 Google 搜尋),執行後把結果再交給 AI 處理並產出回應,自然語言化地回答使用者。 適用場景1. 整合客服機器人如果你想設計聊天介面給其他人使用,像是客服機器人外掛,就很適合採用這個技術來取得網站內的資訊,像是讓客人查詢商品、訂單相關資訊、搜尋產品使用說明文件,或是讓管理員查詢營業額、網站瀏覽數據。 近期在開發的網站助理就是使用這個技術來讓管理者查詢訂單資料: https://oberonlai.blog/dwp-site-assist/ 2. 整合 LINE 聊天機器人只要透過 Messaging API 的 webhook 呼叫指定的 API,再讓這個 API 去執行 OpenAI 的工具請求,就能把執行結果回傳到 LINE 裡面,這樣就能讓有加入官方帳號或是群組裡的好友直接使用你提供的工具。 例如查星座運勢、摘要表單內容、根據提交資料自動整理資訊等,都能透過工具組合不同資料來源,提供有脈絡的回答。像是萬一有客人問 A 產品的相關資訊,除了先讀取產品描述外,還能讀取近期的訂單資料、產品評價、相關問題,最後整理成有脈絡的回應給客戶: 「您詢問的 A 產品功能包含 XXX,最近有 X 位客人選購,其中 Y 留下好評,對於 XXX 特別讚譽,解決了原本的 X 問題。」 設定工具時需要以下要素:
AI 使用流程:
這邊以 OpenAI API 為範例,設計一個根據文章 ID 來取得文章內容的工具。在設計上我們先處理工具的回應結果,這邊用 get_post_content_by_id 來取得文章內容,這個函式帶有一個參數也就是文章 ID:
接下來定義工具的清單,需要包含上述提及的幾個基本要素:
不管是工具描述還是屬性描述,記得要寫清楚,因為這是 AI 判斷呼叫工具的依據,然後工具名稱要跟上一步驟定義的函式名稱一樣,AI 才知道要呼叫誰,工具屬性 post_id 以及函式參數 $post_id 的也是要相同。 準備好工具後就可以開始請求 API 進行聊天:
在 body 的地方傳入 $functions 就代表這次的對話有提供我們的工具,回應的結果如果帶有 tool_calls 的話,就代表使用者的提問有觸發到我們的工具,接下來我們需要拆解 AI 從使用者提問中拿到的工具名稱以及屬性:
判斷 $function_name 是 get_post_content_by_id 的話,就執行我們的函式取得工具執行的結果,這邊要注意的是回應給 AI 的結果有固定結構化格式,要依照每一家模型的規定組成要求的格式:
然後連同工具執行結果再一次請求 API 來取得實際的回應內容,在第一次請求回傳的 tool_call 也要一併放在 message 中進行呼叫,才會讓 AI 知道第二次的請求是執行工具的結果,不然它會看成是一段新的對話請求:
注意事項以上的基本架構就能完成最簡單的工具使用,可以進一步擴展並整合更多的工具。在使用多個工具的情況下有可能會回傳多個 $tool_call 陣列,因此要記得處理多筆資料的情境,另外如果你有實作對話紀錄讓 AI 可以根據上下文進行回答的話,記得要在提示詞裡面指定優先使用工具來取得資訊,不然不會觸發到工具的使用。 我用的提示詞如下:
另外有一些動態的資訊想要讓 AI 知道的話,也可以在提示詞裡面用變數的方式加入,我卡最久的是讓 AI 取得今天日期。由於要查詢報表需要有日期區間,每次問結果都錯誤,後來才發現它根本不知道今天是幾號就胡亂回答一通。 另外還有時區的問題,因此我先把這些資訊用 PHP 拿到後再放到提示詞裡面,確保它能正確理解這些背景知識:
結語AI 實在太方便,連範例程式碼都可以不用自己寫。這篇記錄也讓我回頭終於看懂之前 Cursor 產的程式碼到底在幹嘛 XD 果然寫文章是最好的學習方式!我們下週見~ 參考資料 |
大家端午快樂,這週分享一下我目前的主力開發工具~ 開發工具的使用歷程 在 AI 時代前,我都是使用 PhpStorm。PHPStorm 確實順手——跳到函式定義、儲存時自動格式化和檢查,這些功能讓開發效率提升不少。 進入 AI 時代後,我用了 Cursor 好幾個月。自動補全和聊天介面加速了不少開發流程。但用了一段時間,我發現自己還是需要理解程式碼的能力,最後回到 PHPStorm 搭配 Claude Code 的組合。 後來也試過 Google 的 Antigravity。除了免費額度以外,用起來跟 VS Code 差不多。直到某天我打開系統監控,發現 Antigravity 的記憶體佔用竟然到了 40 幾 GB。 40 幾 GB,只為了一個程式碼編輯器。 程式碼視窗還重要嗎? 這讓我開始重新思考一個問題:傳統 IDE 的設計核心是「程式碼」。整個介面以程式碼編輯器為主體,側邊欄、終端機、除錯面板都是輔助角色。 但我現在的開發流程已經變了。大部分時間我在跟 Claude Code 對話,描述需求、確認方向、審查它產出的結果。真正需要自己打開檔案逐行閱讀的時候,一天可能不到三成。...
前陣子,我教會一位朋友使用 Claude Code。他完全不會寫程式,連終端機是什麼都沒聽過。但他有一個很清楚的產品想法,一直找不到工程師幫他做。 兩週後,他把那個產品完整地實作出來了。 不是原型、不是 wireframe,是一個可以實際運作的產品。他全程沒有寫過任何一行程式碼——他只是用中文描述他要什麼功能,Claude Code 就幫他把程式寫出來、跑起來、除完錯。 你可能會想:那它跟 ChatGPT 到底差在哪? 一、你說中文,它寫程式 大部分人聽到「Claude Code」就先退了一步。Code,程式碼,那不是工程師的事嗎? 試試看跟它說這句話:「幫我把這個資料夾裡所有 PDF 的檔名,整理成一份清單。」 它會自己寫一段程式碼、跑完、把清單生出來。你完全不需要看懂那段程式碼。同樣的事在 ChatGPT 上做,它會把程式碼貼給你看,然後你得自己想辦法找地方執行。 你需要學的不是程式語言,而是怎麼把需求講清楚。但光是能下指令還不夠——如果它每次只能做一件事就停下來等你,那跟比較聰明的 Siri 也沒什麼兩樣。 二、它不是聊天機器人,它是 Agent 用過 ChatGPT 或...
如果你有在使用 AI 開發 WordPress 外掛,並且要設計一些自訂的後台管理介面時,一定遇過資料送出時無法正確儲存,或是儲存後被導向到奇怪的頁面。 根據我的經驗,這十之八九是 Nonce 的問題,AI 在處理 Nonce 這一塊常常會出錯,為了讓 AI 更好地理解該怎麼處理 Nonce,這篇文章就來分享 Nonce 的作用,以及如何讓 AI 不要再犯這種錯。 Nonce 是為了擋 CSRF 而生的 所謂的 Nonce,最主要的功能是要防止跨站請求偽造(也就是俗稱的 CSRF)。 CSRF 主要的攻擊方式,是攻擊者誘導已經登入受害者的瀏覽器,自動發送請求到你的網站,也就是說,攻擊者不需要入侵你的網站,只要你的瀏覽器在登入狀態下點擊了惡意網址,攻擊就會開始。 舉個例子: 站長登入了某個 WordPress 網站的後台沒登出,繼續開著分頁 站長切換到另一個由惡意攻擊者準備好的頁面,這個惡意頁面藏了一段惡意程式 程式裡面的連結會指向站長 WordPress 後台 瀏覽器在送出這個請求時,會自動帶上站長已經登入的 Cookie(因為原本分頁沒關) 站長踩到這個惡意網址、讀到那段...