مهندسی پرامپت (Prompt Engineering) یعنی طراحی سیستمی که خروجی مدل زبانی بزرگ را قابل‌پیش‌بینی، قابلنسخه و قابل‌بازاستفاده کند. اگر پرامپت‌هایتان شکست می‌خورند، مشکل معمولاً دستور غلط نیست؛ حذف زمینه‌ی لازم و نبود ساختار مشخص، مدل را در حالت حدس‌زدن قرار می‌دهد. سه سؤال عملی این حوزه را می‌سازند: الگوی شکست چیست، مستر پرامپت (Master Prompt) چطور ساخته میشود، و چه‌زمانی باید از پرامپت به RAG یا Fine-Tuning مهاجرت کرد.
مهندسی پرامپت چیست و چرا تشبیه آن به برنامه‌نویسی گمراه‌کننده است#
مهندسی پرامپت طراحی سیستم‌های دستوری است که رفتار مدل زبانی را قابل‌پیش‌بینی کند. برخلاف برنامه‌نویسی، خروجی قطعی نیست و باید با عدم‌قطعیت طراحی شود. تشبیه پرامپت به کد گمراه‌کننده است چون در کدنویسی ورودی مشخص خروجی مشخص می‌دهد؛ در پرامپتنویسی ورودی مشخص خروجی احتمالی می‌دهد و وظیفه‌ی شما طراحی چارچوبی است که آن احتمال را به نفع شما باریک کند.
این تفاوت بنیادین است، نه جزئی. کسی که پرامپت را مثل تابع می‌نویسد، انتظار دارد یک‌بار درست بنویسد و تمام. در عمل، پرامپت یک سیستم زنده است که باید با داده‌ی جدید، مدل جدید و سناریوی جدید سازگار شود. تشبیه درست‌تر، تشبیه به طراحی UX است، نه به برنامه‌نویسی.
تفاوت پرامپتنویسی با استفاده‌ی ساده از AI: از سؤالپرسیدن تا طراحی رفتار#
استفاده‌ی ساده یعنی «این را برایم بنویس». پرامپتنویسی یعنی «در این نقش، با این محدودیت، در این فرمت، با این نمونه، خروجی بده». اولین سؤال یک‌بار مصرف است. دومی یک سیستم است که بارها اجرا میشود و باید در هر اجرا نتیجه‌ی مشابه بدهد.
مرز این دو، تکرار و قابل‌نسخه‌بودن است. اگر خروجی‌تان را نمی‌توانید دو بار با همان ورودی بازتولید کنید، هنوز در مرحلهی سؤالپرسیدن هستید.
چرا پرامپتنویسی به طراحی UX نزدیک‌تر است تا به کدنویسی#
طراح UX فرض میکند کاربر اطلاعات را کامل نمی‌دهد و باید شکاف‌های اطلاعاتی را پر کند. پرامپت‌نویس هم دقیقاً همین کار را میکند: فرض میکند مدل زمینه‌ی لازم را ندارد و باید آن را در پرامپت بگنجاند. الگوهای شکست پرامپت، همان الگوهای شکست در رابط کاربری‌اند — ابهام، فرض‌های ضمنی و نبود بازخورد.
اشتباه پرهزینه‌ای که در کلاس‌ها و دوره‌های آموزشی مکرر دیده میشود: زبان‌شناسی پرامپت را با دستور زبان یکی می‌گیرند. نه، مسئله گرامر نیست. مسئله این است که مدل «نمی‌داند شما چه می‌دانید». دقیقاً مثل کاربری که روی فرم ثبت‌نام، فیلد آدرس را خالی می‌گذارد چون فکر میکند سیستم از قبل میداند کجا زندگی میکند.
پرامپت سیستم (System Prompt) و پرامپت کاربر (User Prompt): تفکیک لایهها#
پرامپت سیستم قوانین پایهی رفتار را تعریف میکند: نقش، محدودیت‌ها، فرمت خروجی. پرامپت کاربر داده‌ی لحظه‌ای را منتقل میکند: سؤال، ورودی، متغیرها. تفکیک این دو لایه، مستر پرامپت را از یک متن یکپارچه‌ی بی‌ساختار جدا میکند و امکان نسخه‌بندی و دیباگ را فراهم می‌آورد.
بدون این تفکیک، هر بار که می‌خواهید یک متغیر را عوض کنید، باید کل پرامپت را بازنویسی کنید. با تفکیک، فقط لایه‌ی کاربر تغییر میکند و لایه‌ی سیستم ثابت میماند.
مستر پرامپت چیست؟ تفاوت آن با قالب پرامپت#
مستر پرامپت یک سیستم قابل‌نسخه‌بندی با متغیرهای مشخص، بخشهای مجزا و قوانین بازگشتی است. قالب پرامپت صرفاً یک متن ثابت برای کپی‌پیست است. مستر پرامپت وقتی ساخته میشود که یک پرامپت را بیش از سه بار در سناریوهای متفاوت اجرا کرده‌اید و تغییراتش را ردیابی می‌کنید.
تفاوت عملی اینجاست: قالب پرامپت وقتی می‌میرد که مدل عوض شود. مستر پرامپت با تغییر یک متغیر زنده میماند.
اجزای ساختاری یک مستر پرامپت: نقش، زمینه، دستور، محدودیت، فرمت خروجی، نمونه‌ها#
هر مستر پرامپت از این شش لایه تشکیل میشود:
- نقش (Role): مدل در چه جایگاهی پاسخ می‌دهد
- زمینه (Context): اطلاعات پیش‌نیازی که مدل بدون آن حدس می‌زند
- دستور (Instruction): کار مشخصی که باید انجام شود
- محدودیت (Constraints): چه چیزهایی نباید در خروجی باشد
- فرمت خروجی (Output Format): ساختار دقیق پاسخ
- نمونه (Example): یک ورودی و خروجی مطلوب
لایه‌ی محدودیت، معمولاً بیشترین اثر را بر کیفیت دارد و هم‌زمان بیشترین حذف را میشود. الگوی تکرارشونده: تیم‌ها نقش و دستور را می‌نویسند، محدودیت را فراموش میکنند، و بعد تعجب میکنند چرا مدل مقدمه‌چینی اضافه و تکرار می‌فرستد.
متغیرها و پارامترها: چطور یک مستر پرامپت برای ده‌ها سناریوی متفاوت کار کند#
بخش‌هایی که در هر اجرا تغییر میکنند را به‌صورت متغیر مشخص کنید. مثلاً {topic}، {audience}، {tone}. بقیه‌ی پرامپت ثابت میماند. این کار یک مستر پرامپت را به ده‌ها سناریو قابل‌تبدیل میکند بدون اینکه ساختار شکسته شود.
یک نکته‌ی عملی که اغلب نادیده گرفته میشود: نام متغیرها باید خودسند باشند. {audience} بهتر از {x} است چون وقتی شش ماه بعد به پرامپت نگاه می‌کنید، بدون توضیح اضافه می‌فهمید چه چیزی جایگزین میشود.
نسخه‌بندی و دیباگ: چطور تغییرات مستر پرامپت را ردیابی کنید#
هر تغییر در مستر پرامپت را با شماره‌ی نسخه، تاریخ و دلیل تغییر ثبت کنید. بدون این کار، وقتی خروجی بدتر میشود، نمی‌دانید کدام تغییر مسئول است. الگوی رایج در پروژههای واقعی: یک خط تغییر در بخش محدودیت‌ها، کیفیت خروجی را در چندین سناریو هم‌زمان افت می‌دهد.
درست مثل git در کدنویسی، اما برای پرامپت. اگر مستر پرامپت‌تان بیش از سه نسخه دارد و هیچ changelog ندارد، دیباگ عملاً غیرممکن است.
نمونه‌ی مستر پرامپت آماده (نسخه‌ی 1.0):
نقش: تو یک ویراستار محتوای فارسی با تخصص در سئو هستی.
زمینه: مخاطب مقاله، توسعه‌دهندگانی هستند که با مفاهیم فنی آشنا‌اند اما فارسی می‌نویسند.
دستور: متن زیر را بازنویسی کن.
محدودیت: از واژه‌های عربی استفاده نکن. جمله‌های بیش از 20 کلمه را بشکن. از «بدون شک» و «شایان ذکر است» استفاده نکن.
فرمت خروجی: Markdown، با حداکثر 3 زیرسرتیتر.
نمونه:
ورودی: «در دنیای امروز، بدون شک مهندسی پرامپت شایان ذکر است.»
خروجی: «مهندسی پرامپت مهارت ارجحی است که...»
متن بازنویسی‌شده: {input_text}
تکنیک‌های مهندسی پرامپت: کدام برای کدام مسئله؟#
هر تکنیک مهندسی پرامپت برای نوع خاصی از مسئله طراحی شده است. زنجیره‌ی تفکر (Chain of Thought) برای استدلال چندمرحله‌ای، نمونه‌ی چندتایی (Few-Shot Prompting) برای الگوبرداری از فرمت، و خروجی ساختارمند (Structured Output) برای یکپارچه‌سازی با سیستم‌ها مؤثرند.
انتخاب تکنیک بر اساس حدس و گمان، پرهزینه‌ترین اشتباهی است که در این حوزه رایج شده. هر تکنیک هزینه‌ی توکنی دارد؛ اگر برای مسئله‌ی ساده، CoT بیاورید، هم وقت و هم بودجه‌ی API را هدر داده‌اید.
زنجیره‌ی تفکر (Chain of Thought): چه‌کمک میکند و چه‌کمک نمی‌کند#
وقتی مدل را مجبور کنید «مرحله به مرحله فکر کن»، برای مسائل ریاضی، استدلال منطقی و تحلیل چندگامی بهبود محسوس دارد. اما برای کارهای ساده‌ی تولید متن، زنجیره‌ی تفکر اضافه‌کاری است و context window را هدر می‌دهد. تشخیص: اگر مسئله بیش از دو مرحلهی وابسته دارد، CoT استفاده کنید.
نمونه‌ی چندتایی (Few-Shot Prompting): الگوبرداری از فرمت و سبک#
سه تا پنج نمونه‌ی ورودی-خروجی، مدل را به سمت فرمت و سبک مطلوب هدایت میکند. این تکنیک برای کارهایی مؤثر است که توضیح نوشتاری‌شان سخت‌تر از نمونه‌شان است — مثلاً طبقه‌بندی، استخراج داده، یا تولید متن با لحن خاص.
بعضی‌ها فکر میکنند هرچه نمونه بیشتر، بهتر. این غلط است. نمونه‌های زیاد، context window را پر میکنند و مدل از دستور اصلی فاصله می‌گیرد. سه نمونه‌ی دقیق، تقریباً همیشه بر هفت نمونه‌ی متوسط می‌چربد.
خروجی ساختارمند (Structured Output): JSON، جدول و فرمت‌های قابل‌پردازش#
وقتی خروجی پرامپت باید وارد سیستم دیگری شود، فرمت ساختارمند الزامی است. در پرامپت مشخص کنید: «خروجی فقط JSON باشد، بدون متن اضافی». مدلهای جدیدتر، APIهای dedicated برای structured output دارند که احتمال خطای فرمت را کاهش می‌دهد.
پرامپت معکوس (Reverse Prompting): خروجی بدهید، پرامپت بگیرید#
تکنیک کمتر شناخته‌شده: یک خروجی مطلوب به مدل بدهید و بخواهید پرامپتی بنویسد که آن خروجی را تولید کند. این کار برای کشف ساختار پرامپتهای مؤثر و دیباگ پرامپتهای شکستخورده بسیار کاربردی است.
نمونه‌ی پرامپت معکوس:
این خروجی را ببین:
{desired_output}
حالا پرامپتی بنویس که اگر به یک مدل زبانی داده شود، دقیقاً این خروجی را تولید کند. پرامپت باید شامل نقش، زمینه، دستور، محدودیت و فرمت خروجی باشد.
مهندسی پرامپت یا Fine-Tuning یا RAG؟ معیار انتخاب#
سه متغیر تعیین‌کننده‌اند: حجم داده‌ی مرجع، نیاز به به‌روزرسانی، و هزینه‌ی خطا. اگر داده‌ی مرجع کم و ثابت است، مهندسی پرامپت کافی است. اگر زیاد و متغیر است، RAG (Retrieval-Augmented Generation) لازم است. اگر رفتار پایهی مدل باید تغییر کند، Fine-Tuning تنها گزینه است.
معیار «داده‌ی مرجع» را جدی بگیرید. اگر اطلاعاتی دارید که مدل از قبل نمی‌داند، پرامپت آن را نمی‌سازد. باید RAG اضافه شود. این تصمیم را نمی‌توان با پرامپتنویسی بهتر دور زد.
جدول مقایسه‌ی Prompt Engineering در برابر Fine-Tuning در برابر RAG#
| معیار | مهندسی پرامپت | Fine-Tuning | RAG |
|---|---|---|---|
| هزینه‌ی اولیه | پایین | بالا | متوسط |
| سرعت پیاده‌سازی | ساعت‌ها | هفته‌ها | روزها |
| قابل‌نسخه‌بندی | بله | خیر | بله |
| به‌روزرسانی دانش | محدود به context window | نیاز به آموزش مجدد | لحظه‌ای |
| تغییر رفتار پایه | خیر | بله | خیر |
| مناسب برای | تسک‌های تعریف‌شده | تغییر سبک یا تخصص | پاسخ بر اساس دانش‌بیس |
چه‌زمانی مستر پرامپت کافی نیست و باید سراغ Fine-Tuning بروید#
وقتی مدل در هر اجرا با وجود پرامپت دقیق، رفتار پایهی مطلوب را نشان نمی‌دهد — مثلاً لحن تخصصی، فرمت بسیار خاص، یا درک اصطلاحات حوزهای که در آموزش مدل نبوده — Fine-Tuning لازم است. علامت هشدار: اگر سه بار پرامپت را تغییر دادید و هنوز رفتار پایه عوض نشد، مشکل پرامپت نیست.
نه، سه بار کم نیست. سه بار یعنی شما واقعاً همه‌ی لایه‌های ساختاری را امتحان کرده‌اید و مدل جواب نمی‌دهد. در این نقطه، هزینه‌ی ادامه‌ی پرامپتنویسی از هزینه‌ی Fine-Tuning بیشتر میشود.
ترکیب‌پذیری: پرامپت + RAG برای سیستم‌های تولیدی#
در محیط‌های تولیدی، معمولاً ترکیب مستر پرامپت + RAG بهترین نتیجه را می‌دهد. RAG دانش را از بیرون می‌آورد و مستر پرامپت رفتار و فرمت را کنترل میکند. این الگو در پروژههای واقعی مکرر دیده شده و جایگزین Fine-Tuning در بیشتر موارد میشود.
چرا پرامپت‌ها شکست می‌خورند؟ الگوی رایج و راه اصلاح#
بیشتر پرامپتهای شکستخورده نه به‌خاطر دستور غلط، بلکه به‌خاطر حذف زمینه‌ی لازم و نبود بخش محدودیت‌ها شکست می‌خورند. مدل در موارد لبه (edge case) رفتار غیرقابل‌پیش‌بینی پیدا میکند و شما متوجه می‌شوید فقط وقتی خروجی بد را در محیط واقعی دیدید.
سؤال‌هایی که باید از خودتان بپرسید قبل از نوشتن پرامپت: مدل میداند مخاطب کیست؟ میداند خروجی کجا مصرف میشود؟ میداند چه چیزهایی نباید بنویسد؟ اگر پاسخ هر سه «نه» است، پرامپت‌تان آماده نیست.
الگوی شکست ۱: حذف زمینه‌ی لازم (Context Gap)#
شما فکر می‌کنید مدل میداند مخاطب کیست، هدف چیست و خروجی کجا مصرف میشود. مدل نمی‌داند. هر فرض ضمنی در ذهن شما، یک شکاف اطلاعاتی در پرامپت است. راه اصلاح: قبل از نوشتن پرامپت، سؤال‌ها را از خودتان بپرسید و پاسخ‌ها را صریح بنویسید.
الگوی شکست ۲: نبود بخش محدودیت‌ها و خروجی‌های ناخواسته#
پرامپت بدون محدودیت، مدل را آزاد می‌گذارد. مدل شروع میکند به اضافه‌کاری: مقدمه‌چینی، تکرار، استفاده از عبارات کلیشه‌ای. بخش محدودیت‌ها دقیقاً به همین دلیل وجود دارد: «این کارها را نکن». بدون آن، کیفیت خروجی تصادفی است.
الگوی شکست ۳: پرامپتهای طولانی و بی‌ساختار که context window را هدر می‌دهند#
پرامپت بلند ≠ پرامپت خوب. وقتی پرامپت بی‌ساختار باشد، توجه مدل روی بخشهای مهم متمرکز نمی‌شود. الگوی مشاهده‌شده در پروژههای واقعی: پرامپتهای بالای یک صفحه بدون سرتیتر داخلی، خروجی‌های پراکنده‌تر تولید میکنند تا پرامپتهای کوتاه‌تر با ساختار مشخص.
ماتریس ارزیابی پرامپت (Prompt Evaluation Matrix): چطور کیفیت خروجی را بسنجید#
هر خروجی پرامپت را بر اساس چهار معیار بسنجید:
- دقت: آیا اطلاعات صحیح است؟
- ساختار: آیا فرمت خواسته‌شده رعایت شده؟
- محدودیت‌ها: آیا چیزهای ممنوع‌شده حضور ندارند؟
- ثبات: آیا اجرای مجدد خروجی مشابه می‌دهد؟
اگر دو یا بیشتر از این چهار معیار در چندین اجرا نقض می‌شوند، مستر پرامپت نیاز به بازنگری دارد.
تفاوت پرامپتنویسی برای Claude، GPT و Gemini#
مدلهای مختلف رفتار زبانی متفاوتی دارند. Claude با XML tagging و ساختار سلسله‌مراتبی بهتر کار میکند، GPT با Markdown و دستورهای صریح‌تر، و Gemini با تعداد مثال‌های بیشتر. یک پرامپت بهینه‌شده برای یک مدل لزوماً برای مدل دیگر بهینه نیست.
این بخش، عملی‌ترین قسمت مقاله است. اگر در پروژه‌تان از بیش از یک مدل استفاده می‌کنید و یک پرامپت واحد برای همه نوشته‌اید، بخشی از خروجی‌هایتان تصادفی است.
Claude و XML tagging: چرا برچسب‌گذاری ساختاری در Claude مؤثرتر است#
مدلهای Anthropic روی داده‌هایی آموزش دیده‌اند که ساختار XML و تگ‌های سلسله‌مراتبی در آن‌ها فراوان است. در عمل، وقتی بخشهای پرامپت را داخل تگ‌های XML قرار می‌دهید — مثلاً <context>، <instructions>، <constraints> — Claude دقیق‌تر به هر بخش توجه میکند و اختلال بین لایهها کمتر میشود.
GPT و دستورهای صریح: چرا مدلهای OpenAI به صراحت لحنی نیاز دارند#
مدلهای GPT به دستورهای صریح و لحن مستقیم بهتر پاسخ می‌دهند. «لطفاً این کار را بکن» برای GPT مؤثرتر از «این کار را انجام بده» است. همچنین بخشهای محدودیت را در انتهای پرامپت قرار دهید؛ GPT به دستورهای پایانی وزن بیشتری می‌دهد.
Gemini و قدرت مثال‌محوری: چرا تعداد نمونه‌ها در Gemini تأثیر بیشتری دارد#
مدل Gemini به تعداد نمونه‌های Few-Shot حساس‌تر است. الگوی مشاهده‌شده: 5 تا 8 نمونه در Gemini بهبود محسوس‌تری نسبت به 2 تا 3 نمونه ایجاد میکند. در مقابل، Claude با 2 نمونه‌ی دقیق به همان کیفیت می‌رسد.
ابزارها و فریمورک‌های مدیریت پرامپت#
برای پروژههای تک‌نفره، یک فایل متنی با نام‌گذاری منظم کافی است. برای تیم‌ها و محیط‌های تولیدی، ابزارهایی مثل PromptLayer برای ردیابی نسخه و LangChain برای زنجیره‌سازی پرامپت‌ها در سیستم‌های چندمرحله‌ای لازم‌اند. انتخاب ابزار به حجم تیم و تعداد سناریوهای فعال بستگی دارد.
قبل از معرفی ابزارها، یک هشدار: ابزار مدیریت پرامپت، پرامپت بد را بهتر نمی‌کند. اگر مستر پرامپت‌تان ساختار ندارد، هیچ فریمورکی نجاتش نمی‌دهد. اول ساختار، بعد ابزار.
PromptLayer: ردیابی نسخه‌ها و تست A/B پرامپت#
PromptLayer امکان ثبت هر تغییر در پرامپت، مقایسه‌ی خروجی نسخه‌های مختلف و تست A/B را فراهم میکند. برای تیم‌هایی که ده‌ها پرامپت فعال دارند و باید بدانند کدام تغییر کیفیت را بهبود یا افت داده، این ابزار ضروری است.
LangChain: زنجیره‌سازی پرامپت‌ها در سیستم‌های چندمرحله‌ای#
وقتی یک تسک به چند پرامپت متوالی نیاز دارد — مثلاً اول استخراج، بعد تحلیل، بعد تولید — LangChain این زنجیره را مدیریت میکند. خروجی هر مرحله ورودی مرحلهی بعد میشود و دیباگ هر حلقه جداگانه ممکن است.
چه‌زمانی ابزار لازم نیست و چه‌زمانی بدون آن نمی‌توانید مقیاس دهید#
علامت ساده: اگر پرامپت‌هایتان در یک فایل متنی قابل‌ردیابی‌اند و بیش از سه نفر هم‌زمان آن را ویرایش نمی‌کنند، ابزار لازم نیست. اگر نسخه‌بندی دستی به کابوس تبدیل شده یا تست A/B را نمی‌توانید انجام دهید، وقت آن است که ابزار بیاورید.
چه‌زمانی مهندسی پرامپت راه‌حل مناسبی نیست؟#
مهندسی پرامپت همه‌کاره نیست. وقتی مسئله به دانش تخصصی عمیقی نیاز دارد که در context window جا نمی‌شود، وقتی هزینه‌ی خطا بسیار بالاست و رفتار پایهی مدل باید تغییر کند، یا وقتی حجم داده‌ی مرجع از ظرفیت پرامپت فراتر است، باید سراغ Fine-Tuning یا RAG بروید.
این را صریح بگویم: اگر کسی به شما گفت «فقط پرامپتنویسی کافی است، RAG و Fine-Tuning پیچیدگی الکی‌اند»، دارد شما را به سمت شکست هدایت میکند. پرامپتنویسی مهارت لازم است، نه مهارت کافی.
محدودیت پنجره‌ی زمینه (Context Window) و اثر آن بر پرامپتهای بلند#
هر مدل زبانی بزرگ سقف مشخصی برای ورودی دارد. وقتی پرامپت + داده‌ی مرجع از این سقف فراتر می‌رود، مدل بخشی از اطلاعات را نادیده می‌گیرد یا فراموش میکند. این محدودیت ذاتی است و با پرامپتنویسی بهتر حل نمی‌شود؛ باید RAG اضافه کنید.
سناریوهایی که Fine-Tuning یا RAG اجباری‌اند#
سه علامت هشدار که پرامپت کافی نیست:
- داده‌ی مرجع بیش از چند ده هزار کلمه است و به‌روزرسانی مکرر دارد → RAG
- مدل با وجود پرامپت دقیق، لحن یا تخصص موردنظر را تولید نمی‌کند → Fine-Tuning
- هزینه‌ی خطا در هر خروجی بسیار بالاست و دقت 90% کافی نیست → ترکیب Fine-Tuning + RAG
آیا مهندسی پرامپت یک شغل مستقل است یا مهارت مکمل؟#
در بازار فعلی، «Prompt Engineer» بهعنوان شغل مستقل هنوز تعریف پایداری ندارد. اما مهندسی پرامپت بهعنوان مهارت مکمل در نقشهای توسعهدهنده، محصولمدار و تحلیلگر داده، تقریباً اجباری شده است. ارزش اصلی در ترکیب این مهارت با دانش حوزهای است، نه در خود پرامپتنویسی.
جمع‌بندی: پرامپتنویسی یک مهارت طراحی سیستم است#
مهندسی پرامپت، طراحی سیستمی است که عدم‌قطعیت مدل زبانی را به قابل‌پیش‌بینی تبدیل میکند. مستر پرامپت با متغیرهای مشخص، بخشهای مجزا و نسخه‌بندی، این طراحی را قابل‌تکرار و قابل‌دیباگ میکند. اگر پرامپت‌هایتان شکست می‌خورند، اول زمینه‌ی حذف‌شده و بخش محدودیت‌ها را بررسی کنید، نه دستور را.
اگر می‌خواهید این مهارت را در پروژههای واقعی تمرین کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در اسکول دقیقاً روی همین الگوها کار میکند: ساخت مستر پرامپت، دیباگ و ترکیب با ایجنت‌ها.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.