اتصال وردپرس به هوش مصنوعی با رابط PiGPT

اتصال وردپرس به هوش مصنوعی می‌تواند برای پیشنهاد پیش‌نویس، خلاصه‌کردن محتوای موجود یا ساخت ابزار داخلی تحریریه مفید باشد؛ اما باید میان «رابط برنامه‌نویسی موجود» و «افزونهٔ آمادهٔ انتشار» تفاوت بگذاریم. در وضعیت فعلی PiGPT، صفحهٔ /docs/api دسترسی API را توضیح می‌دهد، ولی همان صفحه صریح می‌گوید افزونهٔ وردپرس فعلاً منتشر نشده است.

بنابراین این مقاله اسکرین‌شات یا گردش‌کار ساختگی از افزونه ارائه نمی‌کند. مسیر واقعی برای توسعه‌دهنده، گرفتن کلید مجاز و ساخت یک اتصال سمت‌سرور با رعایت امنیت است. اگر دنبال بستهٔ آمادهٔ نصب هستید، وضعیت انتشار را در چنج‌لاگ وردپرس بررسی کنید و تا اعلام نسخهٔ عمومی، وجود افزونه را فرض نکنید.

دسترسی واقعی API اکنون چگونه است؟

صفحهٔ عمومی /docs/api هنوز عبارت «فقط پلن اولترا» را نشان می‌دهد، اما مسیر زندهٔ مدیریت کلید و API فعلی ساخت کلید را به پلن اولترا محدود نکرده است. در وضعیت بررسی‌شده، کاربر واردشده می‌تواند کلید بسازد و درخواست‌ها با همان حساب، پلن فعال، موجودی و سقف مصرف او پردازش می‌شوند. این تفاوت میان متن مستند و رفتار فعلی مهم است و نباید محدودیت اولترا را به‌عنوان واقعیت قطعی تکرار کرد.

کلید از تنظیمات حساب یا صفحهٔ PiCode ساخته می‌شود. رابط مدیریت، فهرست کلیدهای فعال، ساخت کلید و باطل کردن آن را دارد. حداکثر هشت کلید فعال مجاز است و مقدار کامل توکن فقط یک‌بار پس از ساخت نمایش داده می‌شود. برای وضعیت روز حساب، همان صفحهٔ مدیریت کلید و صفحهٔ پلن‌ها را مبنا قرار دهید.

اتصال باید برای صاحب سایت یا تیم فنی دارای حساب PiGPT طراحی شود. بازدیدکنندگان وردپرس نباید کلید شخصی شما را ببینند یا مستقیماً از مرورگر خود با آن درخواست بفرستند.

معماری امن اتصال وردپرس

اتصال مناسب سه بخش دارد. نخست، یک صفحهٔ تنظیمات مدیریتی در وردپرس که فقط مدیر مجاز بتواند کلید را وارد یا عوض کند. دوم، کد PHP سمت‌سرور که درخواست را به https://pigpt.ir می‌فرستد. سوم، رابط مدیریتی یا فرایند پس‌زمینه‌ای که نتیجه را به نویسنده نشان می‌دهد.

کلید API نباید در JavaScript صفحه، HTML، ویژگی داده، URL یا لاگ عمومی قرار گیرد. اگر درخواست از مرورگر مستقیماً به سرویس بیرونی برود، هر کاربری که ابزار توسعه را باز کند می‌تواند هدر را ببیند. درخواست باید از سرور وردپرس عبور کند.

برای درخواست‌های بیرونی در افزونه، از WordPress HTTP API استفاده کنید تا timeout، خطا و سازگاری محیط طبق قرارداد وردپرس مدیریت شود. استفاده از فراخوانی خام و پراکندهٔ cURL در بخش‌های مختلف افزونه، کنترل امنیت و خطا را دشوار می‌کند.

ساخت و نگهداری کلید API

در /app/cli بخش «کلید اتصال» برای یکپارچه‌سازی از جمله وردپرس دیده می‌شود. هنگام ساخت، نامی قابل تشخیص مانند «سایت اصلی - تولید» انتخاب کنید. نام کلید به شما کمک می‌کند هنگام باطل کردن، اتصال درست را تشخیص دهید.

توکن کامل را همان لحظه در محل امن ثبت کنید؛ بعداً فقط پیشوند و اطلاعات کلید دیده می‌شود. توکن را در پیام، تیکت عمومی، مخزن Git یا فایل پشتیبان بدون رمز قرار ندهید. اگر احتمال افشا وجود دارد، کلید را باطل و یک کلید تازه بسازید.

برای محیط توسعه و تولید کلید جدا داشته باشید. این جداسازی باعث می‌شود آزمایش محلی سهمیه و لاگ محیط اصلی را مخلوط نکند و در صورت افشای یک کلید، محیط دیگر مستقل بماند. نام‌گذاری کلید باید محیط و مالک را مشخص کند.

احراز هویت و نشانی پایه

نشانی پایه در مستند رسمی https://pigpt.ir است. احراز هویت با هدر Bearer انجام می‌شود:

text Authorization: Bearer YOUR_KEY

توکن را در query string نفرستید؛ URLها ممکن است در تاریخچه، پراکسی، تحلیل‌گر یا لاگ ذخیره شوند. هدر نیز باید فقط روی ارتباط HTTPS با دامنهٔ دقیق PiGPT ارسال شود. تغییر مسیر ناخواسته به دامنه‌ای دیگر نباید هدر محرمانه را همراه خود ببرد.

صفحهٔ /docs/api در حال حاضر مسیر چت CLI یعنی POST /api/v1/cli/chat را مستند کرده و سقف ۶۰ درخواست در دقیقه را برای آن ذکر می‌کند. سهمیهٔ کلید از چت وب جداست. این عدد را برای ظرفیت واقعی سامانهٔ وردپرسی خود تضمین همیشگی ندانید؛ کد باید پاسخ محدودیت و خطا را مدیریت کند.

نمونهٔ حداقلی سمت‌سرور

نمونهٔ زیر فقط الگوی معماری PHP است و باید با قرارداد دقیق بدنه و پاسخ در مستندات زندهٔ همان endpoint تطبیق داده شود. کلید در این مثال از ثابت امن سمت‌سرور خوانده می‌شود، نه از کد فرانت‌اند:

php $response = wp_remote_post( 'https://pigpt.ir/api/v1/cli/chat', [ 'timeout' => 30, 'headers' => [ 'Authorization' => 'Bearer ' . PIGPT_API_KEY, 'Content-Type' => 'application/json', ], 'body' => wp_json_encode([ 'message' => $prompt, ]), ] );

نام فیلد message در این قطعه نباید بدون بررسی مستندات و پاسخ واقعی مبنای انتشار قرار گیرد؛ صفحهٔ عمومی فعلی فرمان CLI و مسیر HTTP را اعلام می‌کند، اما طرح کامل بدنه را نمایش نمی‌دهد. توسعه‌دهنده باید درخواست آزمایشی کنترل‌شده بسازد و قرارداد واقعی را از مستندات یا پاسخ معتبر تأیید کند.

بعد از فراخوانی، نخست is_wp_error را بررسی کنید، سپس کد وضعیت HTTP و در پایان ساختار JSON را اعتبارسنجی کنید. فرض نکنید هر پاسخ ۲۰۰ حتماً فیلد دلخواه شما را دارد. پیام خطا را برای مدیر قابل فهم کنید، اما بدنهٔ کامل پاسخ یا هدر Authorization را در لاگ نشان ندهید.

کاربردهای مناسب در وردپرس

بهترین نقطهٔ شروع یک ابزار داخلی و کم‌خطر است: خلاصهٔ پیشنهادی برای نوشته‌ای که نویسنده قبلاً آماده کرده، بازنویسی یک پاراگراف یا پیشنهاد چند تیتر. خروجی باید به‌صورت پیش‌نویس نمایش داده شود و انتشار خودکار نداشته باشد.

برای خلاصه‌سازی، متن و معیار را روشن بفرستید: «فقط بر اساس این نوشته، یک خلاصهٔ ۱۲۰ کلمه‌ای بساز؛ نام‌ها و عددها تغییر نکنند.» اصول کامل‌تر در مقالهٔ پرامپت فارسی آمده است. درخواست دقیق‌تر، کنترل خروجی را آسان می‌کند.

کاربردهای پرخطر شامل انتشار خودکار خبر، تغییر انبوه نوشته‌ها، تولید ادعای پزشکی یا مالی و پاسخ خودکار به کاربر بدون نظارت است. پیش از چنین استفاده‌ای باید مجوز، بازبینی، ثبت رویداد، محدودیت نرخ و راه توقف اضطراری طراحی شود.

اعتبارسنجی ورودی در وردپرس

متنی که از فرم مدیریت می‌آید باید مجوز، nonce و پاک‌سازی متناسب داشته باشد. فقط کاربران دارای capability مناسب بتوانند درخواست بفرستند. طول ورودی را محدود کنید تا یک اشتباه یا حمله، درخواست بسیار بزرگ و پرهزینه نسازد.

اگر متن نوشته را برای سرویس می‌فرستید، شورت‌کد، HTML نامربوط، اطلاعات خصوصی و دادهٔ فرم را حذف کنید. مشخص کنید کدام بخش واقعاً برای کار لازم است. اصل کمینه‌سازی داده هم امنیت را بهتر می‌کند و هم پرامپت را واضح‌تر.

خروجی نیز دادهٔ قابل اعتماد نیست. پیش از نمایش در HTML، escaping مناسب انجام دهید. اگر قرار است JSON یا ساختار خاصی مصرف شود، نوع و کلیدهای مجاز را اعتبارسنجی کنید. هرگز خروجی مدل را به‌عنوان PHP، SQL یا فرمان سیستم اجرا نکنید.

مدیریت خطا، محدودیت و هزینه

اتصال شبکه همیشه ممکن است شکست بخورد. timeout معقول بگذارید و در صورت خطای موقت، retry محدود با فاصلهٔ افزایشی داشته باشید. retry بی‌نهایت هم صف را شلوغ می‌کند و هم ممکن است یک درخواست را چند بار هزینه‌دار کند.

برای خطای ۴۰۱ یا ۴۰۳، کلید و مجوز پلن را بررسی کنید و خودکار دوباره تلاش نکنید. برای ۴۲۹، نرخ درخواست را کم کنید و زمان مناسب را رعایت کنید. برای خطاهای سرور، پیام عمومی به کاربر بدهید و جزئیات غیرحساس را برای مدیر ثبت کنید.

در رابط مدیریتی، وضعیت «در حال پردازش»، «موفق» و «ناموفق» را جدا نشان دهید. دکمه را هنگام درخواست غیرفعال کنید تا کلیک تکراری چند فراخوانی نسازد. قبل از عملیات انبوه، شمار نوشته‌ها و برآورد دامنهٔ کار را به مدیر نشان دهید.

حریم خصوصی و بازبینی انسانی

قبل از ارسال، به صاحب سایت بگویید چه داده‌ای از وردپرس به PiGPT می‌رود. اطلاعات کاربر، سفارش، پروندهٔ خصوصی یا پیش‌نویس محرمانه را بدون مبنای روشن و کنترل دسترسی ارسال نکنید. سیاست حریم خصوصی سایت باید با استفادهٔ واقعی هماهنگ باشد.

هر خروجی تولیدی باید پیش از انتشار توسط انسان بررسی شود. مدل ممکن است عدد، منبع یا ویژگی محصول را نادرست بازنویسی کند. رابط خوب تفاوت متن اصلی و پیشنهاد را کنار هم نشان می‌دهد و پذیرش تغییر را به نویسنده می‌سپارد.

ثبت رویداد مفید است، اما متن کامل و توکن را ذخیره نکنید مگر ضرورت و سیاست نگهداری مشخص دارید. شناسهٔ درخواست، زمان، کاربر، نوع عملیات و نتیجهٔ کلی معمولاً برای عیب‌یابی کافی است.

افزونهٔ آماده چه وضعیتی دارد؟

مستند زندهٔ API می‌گوید افزونهٔ وردپرس فعلاً منتشر نشده است. وجود صفحهٔ چنج‌لاگ وردپرس به معنای در دسترس بودن فایل عمومی در همین لحظه نیست؛ آن صفحه مرجع وضعیت محصول است. تا وقتی مسیر دانلود و نسخهٔ عمومی رسماً اعلام نشده، از معرفی دکمه‌ها و صفحات افزونه خودداری کنید.

اگر توسعه‌دهنده هستید و صفحهٔ حساب به شما امکان ساخت کلید می‌دهد، می‌توانید با API موجود یک اتصال اختصاصی سمت‌سرور بسازید؛ مصرف تابع پلن، موجودی و سهمیهٔ همان حساب است. اگر کاربر غیرفنی هستید و افزونهٔ نصب‌شدنی می‌خواهید، منتظر اعلام نسخهٔ عمومی بمانید. این دو مسیر را نباید در راهنما با هم مخلوط کرد.

چک‌لیست پیش از راه‌اندازی

• امکان ساخت کلید، پلن فعال و سهمیهٔ حساب در صفحهٔ PiGPT تأیید شده است.
• کلید جدا برای توسعه و تولید ساخته و امن نگهداری می‌شود.
• درخواست فقط از سرور وردپرس به https://pigpt.ir می‌رود.
• endpoint و طرح بدنه با مستندات زنده آزمایش شده‌اند.
• مجوز کاربر، nonce، محدودیت طول و پاک‌سازی ورودی اجرا می‌شوند.
• timeout، خطای HTTP و محدودیت نرخ مدیریت می‌شوند.
• خروجی پیش‌نویس است و بدون تأیید انسان منتشر نمی‌شود.
• توکن و دادهٔ حساس در لاگ، HTML یا Git قرار نمی‌گیرند.

جمع‌بندی

اتصال وردپرس به هوش مصنوعی با رابط PiGPT اکنون برای توسعه‌دهنده‌ای که در حساب خود کلید می‌سازد از مسیر API معنا دارد، نه از طریق افزونهٔ عمومی آماده. مستندات را در /docs/api ببینید، دسترسی واقعی و کلید را در صفحهٔ PiCode بررسی کنید و اتصال را سمت‌سرور، محدود و قابل بازبینی بسازید. وضعیت افزونهٔ رسمی را فقط از چنج‌لاگ وردپرس دنبال کنید.