کدهای مخفی Chatgpt؛ ۳۶ دستور کاربردی برای پاسخ‌های بهتر

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

در این راهنما ۳۶ دستور قابل‌استفاده را در چهار گروه می‌بینید: کنترل لحن، تعیین فرمت، بررسی استدلال و اصلاح متن فارسی. برای هر گروه نمونه‌هایی گذاشته‌ایم که می‌توانید کپی کنید و موضوع خودتان را جایگزین کنید. بخش ویژهٔ فارسی‌نویسی کمک می‌کند خروجی را از حالت ترجمه‌ای و شلخته دور کنید.

نکتهٔ مهم این است که عبارت‌هایی مثل ELI5 یا FORMAT: TABLE فرمان رسمیِ تضمین‌شده نیستند؛ آن‌ها برچسب‌هایی‌اند که درخواست شما را روشن‌تر می‌کنند. پس از خواندن مقاله می‌توانید چند دستور متناسب با کارتان انتخاب کنید، نتیجه را بسنجید و دستورهای همیشگی‌تان را در تنظیمات شخصی‌سازی حساب قرار دهید. برای اطلاعات حساس یا تصمیم‌های مهم نیز خروجی را مستقل بررسی کنید.

کدهای مخفی Chatgpt چیست؟

کدهای مخفی Chatgpt معمولاً پرامپت‌های کوتاه یا برچسب‌های متنی مانند ELI5 و FORMAT: TABLE هستند که خواستهٔ شما را دقیق‌تر بیان می‌کنند. این عبارت‌ها دسترسی پنهانی به تنظیمات OpenAI نمی‌دهند؛ برای تعیین سطح توضیح، لحن، ساختار خروجی یا شیوهٔ بررسی یک مسئله به کار می‌روند و نتیجه‌شان تضمینی نیست.

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

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

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

جدول سریع کدهای دستوری چت‌جی‌پی‌تی

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

دستور نمونه	ورودی مناسب	خروجی درخواستی	هنگام بررسی به چه دقت کنیم؟
ELI5	مفهوم دشوار	توضیح ساده	ساده‌سازی، معنای اصلی را تغییر ندهد
TL;DR	متن بلند	خلاصهٔ کوتاه	نکات تعیین‌کننده حذف نشوند
FORMAT: TABLE	چند گزینه و معیار	جدول مقایسه	خانه‌های نامعلوم با حدس پر نشوند
OUTPUT: JSON	داده و نام فیلدها	خروجی ساختاریافته	ساختار و مقادیر اعتبارسنجی شوند
FORMAT: MERMAID	مراحل یا ارتباط‌ها	متن نمودار	کد در ابزار مقصد بررسی شود
HALF_SPACE	متن فارسی	ویرایش فاصله‌گذاری	نام‌ها و متن نقل‌شده ناخواسته عوض نشوند

برچسب‌ها را می‌توانید به فارسی هم بنویسید. آنچه اهمیت دارد، تعریف دقیق کار است: «متن را به جدول تبدیل کن؛ ستون‌ها مسئله، راه‌حل و پرسشِ باز باشند» معمولاً از نوشتن تنها «TABLE» قابل‌فهم‌تر است. برای یادگیری روش ساخت چنین درخواست‌هایی، راهنمای اصول پرامپت‌نویسی مکمل خوبی است.

کدهای مخفی برای کنترل لحن و سبک پاسخ‌دهی

در این بخش، برچسب‌ها را به‌عنوان نام کوتاه یک درخواست ببینید. می‌توانید چند مورد را ترکیب کنید، ولی دستورهای ناسازگار ندهید؛ مثلاً «بسیار کوتاه» و «تمام جزئیات را توضیح بده» بدون تعیین اولویت، نتیجه را مبهم می‌کند.

۱. ELI5؛ ساده‌سازی: بنویسید «ELI5: تورم را برای دانش‌آموزی که اقتصاد نخوانده، با یک مثال روزمره توضیح بده؛ در پایان بگو مثال کجا دقیق نیست.» این بخش آخر مهم است، چون تشبیه ساده ممکن است همهٔ جنبه‌های موضوع را نشان ندهد.

۲. TL;DR؛ خلاصه‌سازی: بنویسید «TL;DR: متن زیر را در حداکثر ۸۰ واژه خلاصه کن و تصمیم‌های ذکرشده را حذف نکن.» خلاصه را با متن اصلی تطبیق دهید، به‌ویژه وقتی استثنا یا شرط دارد.

۳. JARGONIZE؛ تخصصی‌تر کردن: «این توضیح ساده دربارهٔ نرخ تبدیل را برای تیم بازاریابی بازنویسی کن؛ اصطلاح تخصصی را فقط در جای درست به کار ببر.» اصطلاح‌سازی بی‌دلیل کیفیت متن را پایین می‌آورد.

۴. VOICE؛ تعیین صدا: «با صدای یک راهنمای آموزشی صبور بنویس، نه لحن فروشنده.» تعیین ویژگی‌های لحن از درخواست تقلید دقیق از یک فرد مشخص کاربردی‌تر است.

۵. MOOD؛ تنظیم حال‌وهوا: «پاسخ آرام و اطمینان‌بخش باشد، اما خطرها را پنهان نکند.» برای پیام پشتیبانی، این قید از «خیلی مثبت بنویس» دقیق‌تر است.

۶. AUDIENCE؛ شناخت مخاطب: «این توضیح را برای صاحب کسب‌وکاری بنویس که برنامه‌نویس نیست؛ واژهٔ API را یک‌بار تعریف کن.» سطح دانش مخاطب، مقدار توضیح لازم را تعیین می‌کند.

۷. LENGTH؛ محدود کردن طول: «در دو پاراگراف کوتاه پاسخ بده و هر پاراگراف فقط یک ایدهٔ اصلی داشته باشد.» اگر شمارش دقیق واژه برایتان حیاتی است، آن را بعداً هم کنترل کنید.

۸. EXAMPLE_FIRST؛ شروع با نمونه: «اول یک نمونهٔ پیام پیگیری سفارش بنویس، سپس در دو جمله توضیح بده چرا مؤدبانه است.» این دستور برای کسی مناسب است که می‌خواهد پیش از توضیح نظری، نتیجه را ببیند.

۹. ASK_FIRST؛ پرسیدن پیش از پاسخ: «پیش از پیشنهاد برنامهٔ مطالعه، حداکثر سه سؤال دربارهٔ زمان، هدف و سطح من بپرس؛ فعلاً برنامه ننویس.» وقتی دادهٔ کافی ندارید، این روش از دریافت برنامه‌ای ظاهراً کامل اما نامتناسب جلوگیری می‌کند. پس از پاسخ دادن به سؤال‌ها، خروجی را با شرایط واقعی خودتان بسنجید.

کدهای فرمت‌دهی برای جدول، JSON و برنامه‌نویسی

برای خروجی ساختاریافته، قبل از هر چیز فیلدها، ترتیب و رفتار در برابر دادهٔ نامعلوم را تعیین کنید. قالب مرتب می‌تواند خطای محتوایی را پنهان کند؛ جدول زیبا یا JSON معتبر، به‌تنهایی به معنی درست بودن اطلاعات نیست.

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

۱۱. OUTPUT: JSON؛ دادهٔ قابل‌پردازش: «برای هر مورد فقط فیلدهای title و priority را در آرایهٔ JSON برگردان؛ مقدار نامعلوم را null بگذار و متن اضافه ننویس.» پیش از استفاده در برنامه، ساختار و مقدارها را بررسی کنید.

OUTPUT: JSON؛ از یادداشت‌های زیر آرایه‌ای با فیلدهای task، owner و deadline بساز. چیزی را حدس نزن؛ مقدار ذکرنشده null باشد. فقط خروجی خواسته‌شده را بده. یادداشت‌ها: [متن شما]

۱۲. FORMAT: MERMAID؛ نمایش روند: «مراحل دریافت سفارش تا تأیید را به صورت فلوچارت Mermaid بنویس؛ برای هر تصمیم دو مسیر مشخص بگذار.» Mermaid.js زبان متنیِ توصیف نمودار است؛ کدی که دریافت می‌کنید را در محیط مقصد اجرا و خطاهایش را اصلاح کنید.

۱۳. FORMAT: MARKDOWN؛ ساختاربندی متن: «گزارش را با تیترهای وضعیت، مانع و اقدام بعدی در قالب Markdown بده.» وقتی محتوا را در جایی با قالب‌بندی متفاوت می‌چسبانید، نمایش نهایی را بررسی کنید.

۱۴. LISTIFY؛ تبدیل متن به موارد: «از این پاراگراف فقط اقدام‌های قابل‌انجام را استخراج کن؛ هر مورد با فعل شروع شود.»

۱۵. OUTPUT: CSV؛ انتقال داده: «ردیف‌ها را با ستون‌های نام، وضعیت و توضیح به صورت CSV بده؛ اگر در مقدارها ویرگول هست، آن را درست نقل‌قول‌گذاری کن.» برای دادهٔ فارسی، نمایش حروف و جداکننده‌ها را پس از انتقال کنترل کنید.

۱۶. SCHEMA؛ تعریف ساختار: «قبل از تولید نمونه، ساختار شیء سفارش را با نام فیلد، نوع داده و اجباری بودن پیشنهاد بده؛ نیازمندی‌های نامعلوم را سؤال کن.»

۱۷. CODE_ONLY؛ محدود کردن پاسخ: «فقط تابع و نمونهٔ فراخوانی را بنویس؛ توضیح را بعداً می‌پرسم.» این دستور برای کپی سریع مناسب است، ولی کد باید پیش از استفاده آزمایش شود.

۱۸. DIFF؛ دیدن تغییرات: «نسخهٔ اصلاح‌شدهٔ تابع را بده و تغییرهای مهم نسبت به کد قبلی را جداگانه توضیح بده؛ رفتارهای حفظ‌شده را مشخص کن.»

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

دستورهای بررسی استدلال و تصمیم‌های پیچیده

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

۱۹. STEPS؛ مراحل قابل‌پیگیری: «راه‌حل را در گام‌های کوتاه و قابل‌بررسی توضیح بده؛ در پایان پاسخ نهایی را جدا کن.» به جای درخواست نمایش فرایند ذهنی پنهان یا استفاده از برچسب CHAIN_OF_THOUGHT، توضیحی بخواهید که خودتان بتوانید صحت آن را بررسی کنید.

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

۲۱. ASSUMPTIONS؛ آشکار کردن فرض‌ها: «پیش از پیشنهاد بودجه، فرض‌هایی را که به آن‌ها نیاز داری بنویس و برای موارد نامعلوم سؤال بپرس.»

۲۲. TREE_OF_THOUGHTS؛ بررسی چند مسیر: «برای حل این مشکل سه رویکرد متفاوت پیشنهاد بده؛ هزینهٔ اجرایی، خطر و شرط مناسب بودن هرکدام را مقایسه کن.» این عبارت نام یک شیوهٔ درخواست است، نه دکمه‌ای برای فعال‌سازی یک قابلیت مخفی.

۲۳. DEVILS_ADVOCATE؛ نقد مخالف: «فرض کن با پیشنهاد من مخالفی؛ سه ایراد جدی پیدا کن و برای هرکدام بگو چه داده‌ای می‌تواند آن را رد یا تأیید کند.»

۲۴. REVERSE_ENGINEER؛ تحلیل نمونه: «ساختار این متن معرفی محصول را بررسی کن؛ بگو آغاز، توضیح مزیت و دعوت به اقدام چگونه چیده شده‌اند، بدون اینکه عبارت‌هایش را بازنویسی کنی.» اولی برای سنجش تصمیم و دومی برای یادگیری از ساختار مفید است.

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

۲۵. COMPARE؛ مقایسه بر اساس معیار: «دو شیوهٔ یادگیری را بر پایهٔ زمان در دسترس و هدف من مقایسه کن؛ برندهٔ مطلق معرفی نکن.»

۲۶. UNCERTAINTY؛ نمایش عدم‌قطعیت: «ادعاهای پاسخ را به دانسته، فرض و نیازمندِ بررسی تقسیم کن.» این برچسب به‌خصوص وقتی دادهٔ به‌روز در اختیار مدل نگذاشته‌اید اهمیت دارد.

۲۷. EDGE_CASES؛ حالت‌های مرزی: «برای این تابع، ورودی خالی، مقدار نامعتبر و دادهٔ تکراری را بررسی کن و رفتار موردانتظار هرکدام را بگو.»

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

کدهای مخفی Chatgpt برای نویسندگان و کاربران فارسی‌زبان

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

۲۸. FA_ORTHOGRAPHY؛ یکدست‌سازی نگارش: «متن را از نظر نشانه‌گذاری، ی و ک فارسی و فاصله‌گذاری ویرایش کن؛ معنا و ترتیب جمله‌ها را حفظ کن.»

۲۹. HALF_SPACE؛ نیم‌فاصله: «نیم‌فاصله‌های لازم را، از جمله در می‌ و نمی‌ و جمع‌های مناسب، بررسی کن؛ هرجا دربارهٔ شکل درست واژه مطمئن نیستی، آن را جداگانه مشخص کن.» درخواست دوم جلوی بعضی اصلاح‌های عجولانه را می‌گیرد.

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

۳۰. NATURAL_FA؛ روان‌سازی: «این متن را برای خوانندهٔ ایرانی روان‌تر کن؛ عبارت‌های ترجمه‌ای را با بیان طبیعی جایگزین کن، اما اطلاعات تازه اضافه نکن.»

۳۱. TERM_KEEP؛ حفظ اصطلاح: «اصطلاح‌های SEO، API و conversion rate را مطابق فهرست واژگان من نگه دار؛ نخستین بار برای هرکدام توضیح کوتاهی بده.» فهرست واژگان دلخواهتان را ضمیمه کنید تا یک اصطلاح در بخش‌های مختلف به چند شکل نوشته نشود.

۳۲. TYPO_FIX؛ اصلاح غلط: «غلط‌های املایی را اصلاح کن و تغییرهایی را که ممکن است معنی را عوض کنند، پیش از اعمال علامت بزن.»

۳۳. DIALECT؛ انتخاب میزان محاوره: «برای پیام دوستانه، لحن محاوره‌ایِ ملایم به کار ببر؛ از شکسته‌نویسی افراطی و اصطلاح‌های منطقه‌ای نامأنوس دوری کن.» محاوره‌ای بودن برای پیام خصوصی مناسب است، ولی برای متن رسمی معمولاً انتخاب خوبی نیست.

۳۴. RTL_CHECK؛ بررسی نمایش: «در متن فارسیِ دارای کد و عبارت انگلیسی، جای علائم و ترتیب بخش‌ها را بررسی کن و مواردی را که ممکن است پس از انتشار به‌هم بریزند مشخص کن.» خودِ نمایش نهایی را باید در محل انتشار ببینید.

۳۵. EDIT_ONLY؛ ویرایش محدود: «فقط جمله‌های نامفهوم را اصلاح کن؛ بخش‌های سالم را دست‌نخورده بگذار.»

۳۶. FA_TRANSLATION؛ ترجمهٔ طبیعی: «این متن انگلیسی را برای مخاطب فارسی‌زبان ترجمه کن؛ اصطلاح‌های فنیِ تعیین‌شده را حفظ کن و جمله‌های تحت‌اللفظی را روان بنویس.»

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

چگونه دستورهای دلخواه را در Custom Instructions نگه داریم؟

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

در بخشی که اطلاعات مربوط به شما یا نیازتان را می‌پرسد، فقط زمینهٔ پایدار و ضروری را وارد کنید؛ مثلاً «برای مخاطب فارسی‌زبان محتوای آموزشی می‌نویسم». گذرواژه، دادهٔ خصوصی دیگران یا جزئیات محرمانهٔ کار را به‌عنوان ترجیح همیشگی ثبت نکنید. در بخشی که دربارهٔ شیوهٔ پاسخ‌گویی است، خواسته‌هایی مثل لحن، ساختار و رفتار با اطلاعات نامعلوم را بنویسید.

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

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

دستورهای مربوط به یک پروژه را بهتر است در همان گفت‌وگو هم تکرار کنید. ترجیح همیشگی برای قواعد کلی مناسب است؛ تعداد ستون‌های یک جدول یا محدودیت‌های یک قطعه کد به درخواست همان کار تعلق دارد. اگر به ابزارهای برنامه‌ریزی و پیگیری کار علاقه دارید، راهنمای قابلیت Task در ChatGPT موضوع متفاوت اما مرتبطی را توضیح می‌دهد.

نسخهٔ رایگان یا ChatGPT Plus؛ برای این دستورها کدام لازم است؟

برای امتحان کردن بیشتر دستورهای این صفحه، لازم نیست از ابتدا اشتراک پولی تهیه کنید. یک متن کوتاه انتخاب کنید و با چند برچسب ساده مثل TL;DR، AUDIENCE و HALF_SPACE نتیجه را بسنجید. ارزش پرامپت دقیق به نوع حساب وابسته نیست، هرچند دسترسی به مدل‌ها، ابزارها و سقف استفاده می‌تواند با حساب و زمان تغییر کند.

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

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

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

جمع‌بندی؛ از کدام دستور شروع کنیم؟

یک دستور کوتاه را با مسئله‌ای واقعی امتحان کنید: برای متن طولانی TL;DR، برای مقایسه FORMAT: TABLE و برای ویرایش فارسی HALF_SPACE همراه با محدودیت «معنا را تغییر نده». سپس نتیجه را بررسی کنید و هرجا مدل حدس زده یا قالب را رعایت نکرده است، درخواستتان را اصلاح کنید. بهترین میان‌بر، همان دستوری است که خروجی‌اش برای کار شما قابل‌سنجش باشد.

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

پرسش‌های پرتکرار دربارهٔ کدهای مخفی Chatgpt

آیا چت‌جی‌پی‌تی کدهای مخفی واقعی دارد؟

عبارت‌هایی مثل ELI5 و FORMAT: TABLE معمولاً برچسب‌هایی در متن درخواست شما هستند، نه رمز دسترسی به تنظیمات پنهان. کارشان این است که هدف و شکل پاسخ را روشن‌تر کنند؛ نتیجه به متن کامل درخواست وابسته است.

آیا استفاده از این دستورها خطر مسدود شدن حساب را دارد؟

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

چرا بعضی دستورها روی حساب من نتیجهٔ دلخواه نمی‌دهند؟

ممکن است درخواست مبهم یا متناقض باشد، دادهٔ کافی نداده باشید یا ابزار موردنیازتان در حساب فعلی در دسترس نباشد. ابتدا برچسب را به یک دستور روشن با ورودی، قالب خروجی و معیار بررسی تبدیل کنید.

چطور لحن پاسخ را تغییر بدهم؟

مخاطب و ویژگی‌های لحن را مشخص کنید؛ مثلاً «برای دانشجوی تازه‌کار، رسمی اما روان بنویس و اصطلاح‌ها را توضیح بده». اگر نمونه‌ای از لحن دلخواه خودتان دارید، آن را همراه درخواست بدهید و بخواهید از معنا یا اطلاعاتش فراتر نرود.

برای خلاصه کردن متن بلند چه دستوری بنویسم؟

از TL;DR همراه با محدودیت روشن استفاده کنید: «این متن را در دو پاراگراف خلاصه کن و تصمیم‌ها و شرط‌های مهم را نگه دار». بعد خلاصه را با متن اصلی تطبیق دهید، چون نکته‌ای تعیین‌کننده ممکن است حذف شود.

چگونه پاسخ را به شکل جدول بگیرم؟

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

چطور پاسخ‌های فارسی را با نیم‌فاصله دریافت کنم؟

در Custom Instructions ترجیح نگارشی خود را ثبت کنید و در کارهای مهم، دستور HALF_SPACE را در همان گفت‌وگو هم بیاورید. متن نهایی را بازخوانی کنید؛ هیچ تنظیم متنی‌ای رعایت کامل و بی‌خطای نیم‌فاصله را تضمین نمی‌کند.