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

مهندسی پرامپت چیست و چه فرقی با دستور ساده دارد؟#

مهندسی پرامپت طراحی ساختارمند ورودی متنی برای مدل زبانی (LLM) است تا خروجی قابل‌تکرار تولید شود. دستور ساده، یک درخواست یک‌باره و بدون ساختار است که نتیجه‌اش به شانس و حالت‌دهی اولیه‌ی مدل بستگی دارد. تفاوت بنیادی در تکرارپذیری است؛ نه در هوشمندی، نه در طول متن.

تعریف عملی: ورودی ساختارمند در برابر درخواست آزاد#

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

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

چرا «دستور بده و دعا کن» روش مهندسی نیست#

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

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

جایگاه مهندسی پرامپت در چرخه‌ی طراحی سیستم‌های مبتنی بر هوش مصنوعی#

مهندسی پرامپت یک مرحله از کل چرخه است، نه کل چرخه. در طراحی سیستم‌های مبتنی بر هوش مصنوعی (AI System Design)، پرامپت تنها بخشی از ورودی مدل است. انتخاب مدل، مدیریت زمینه، ارزیابی خروجی و بازخورد کاربر همگی در این چرخه نقش دارند. پرامپت خوب بدون سیستم خوب، مثل نقشه‌ی دقیق در خودرویی است که فرمان ندارد.

مستر پرامپت: سند مهندسی، نه متن توصیفی#

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

اجزای سند مستر پرامپت: مالک، نسخه، تاریخ ابطال، و تغییرات ثبت‌شده#

هر مستر پرامپت حداقل این فیلدها را دارد:

  • مالک: چه کسی مسئول به‌روزرسانی و اعتبارسنجی این پرامپت است؟
  • شماره‌ی نسخه: مثل نسخه‌ی نرم‌افزار، هر تغییر معنادار یک شماره‌ی جدید می‌گیرد.
  • تاریخ بازنگری: آخرین باری که پرامپت تست و تأیید شده.
  • شرایط ابطال: در چه صورتی این پرامپت دیگر معتبر نیست (تغییر مدل، تغییر قالب خروجی، تغییر حوزه‌ی کاربرد).
  • لاگ تغییرات: چه چیزی عوض شده و چرا.

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

تفاوت مستر پرامپت با پرامپت یک‌بارمصرف: تکرارپذیری و استنادپذیری#

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

مثال ساختاری یک مستر پرامپت با بلوک‌های XML#

راهنمای Anthropic استفاده از برچسب‌های XML برای تفکیک بخش‌های پرامپت را پیشنهاد می‌دهد. این ساختار به مدل کمک می‌کند مرزهای معنایی را تشخیص دهد:

در زیر یک قالب آماده برای کپی کردن دارید:

نمونه مستر پرامپت (قالب XML):

<master_prompt>
  <metadata>
    <version>2.1</version>
    <owner>تیم محتوا</owner>
    <last_reviewed>2025-01-15</last_reviewed>
    <expiration>با تغییر مدل از Claude به GPT ابطال می‌شود</expiration>
  </metadata>

  <role>
    تو یک ویراستار فنی متخصص در حوزه‌ی نرم‌افزار هستی.
  </role>

  <task>
    متن خام زیر را بازنویسی کن.
  </task>

  <context>
    مخاطب: توسعه‌دهندگان با 2 تا 5 سال سابقه.
    لحن: مستقیم، بدون تعارف، فنی.
  </context>

  <constraints>
    - از کلمات قلمبه‌سلمبه استفاده نکن.
    - هر جمله حداکثر 20 کلمه.
    - ادعای بدون منبع ممنوع.
  </constraints>

  <output_format>
    - تگ‌های HTML تمیز.
    - بدون H1 (عنوان جداگانه رندر می‌شود).
    - پاراگراف‌های 2 تا 4 خطی.
  </output_format>

  <input>
    {{raw_text}}
  </input>
</master_prompt>

ساختار یک پرامپت حرفه‌ای شامل چه بلوک‌هایی است؟#

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

بلوک‌های شفاف با مدارهای داخلی که به‌صورت عمودی در هم تراز می‌شوند، تصویری از چیدمان ماژولار یک پرامپت حرفه‌ای
هر بلوک یک وظیفه‌ی مشخص در معماری پرامپت دارد

بلوک وظیفه: تعریف صریح تکلیف بدون ابهام#

بلوک وظیفه باید یک فعل مشخص داشته باشد: «بازنویسی کن»، «خلاصه کن»، «تبدیل کن به جدول». افعال مبهم مثل «بررسی کن» یا «بهترش کن» خروجی ناپایدار تولید می‌کنند. مدل نمی‌داند «بهتر» یعنی چه.

یک استثنا که کمتر کسی می‌گوید: اگر تکلیف واقعاً باز است — مثلاً «برای این محصول سه ایده‌ی تبلیغاتی بده» — فعل مبهم اشکالی ندارد، چون ناپایداری مورد انتظار است. بلوک وظیفه باید صریح باشد، نه اینکه هر تکلیفی را صلب کند.

بلوک زمینه: داده‌ها، تاریخچه، و اطلاعات مرجع#

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

بلوک قالب خروجی: ساختار دقیق پاسخ مورد انتظار#

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

بلوک محدودیت‌ها: آنچه مدل نباید انجام دهد#

محدودیت‌های منفی (Negative Constraints) به‌اندازه‌ی دستورهای مثبت مهم‌اند. «بدون مقدمه‌چینی شروع کن»، «از کلمه‌ی بدون شک استفاده نکن»، «عدد بدون منبع ننویس». این‌ها خط‌قرمزهای مدل را مشخص می‌کنند.

تکنیک‌های بنیادین: نقش‌دهی، نمونه‌دهی، و زنجیره‌ی تفکر#

سه تکنیک Few-Shot Prompting، Chain-of-Thought و Role Prompting مؤثرترین روش‌های افزایش دقت خروجی در تکالیف ساختارمند هستند. هر کدام مشکل متفاوتی را حل می‌کنند و جایگزین یکدیگر نیستند. انتخاب غلط از این سه، هزینه‌ی توکن دارد بدون بهبود کیفیت.

Few-Shot Prompting: چرا نمونه‌ها باید از نظر قالب با خروجی مطلوب یکسان باشند#

نمونه‌دهی کم‌تعداد (Few-Shot Prompting) یعنی چند ورودی-خروجی کامل به پرامپت اضافه کنید تا مدل الگو را یاد بگیرد. نکته‌ی کلیدی: نمونه‌ها باید از نظر قالب و سبک دقیقاً با خروجی مطلوب یکسان باشند، نه فقط از نظر محتوا. اگر خروجی نهایی HTML است، نمونه‌ها هم HTML باشند.

معمولاً 2 تا 5 نمونه کافی است. بیشتر از این، توکن‌های اضافی مصرف می‌شود بدون بهبود محسوس کیفیت. در زیر یک نمونه‌ی آماده برای کپی کردن دارید:

نمونه Few-Shot (قالب بازنویسی):

<examples>
  <example>
    <input>در دنیای امروز، بدون شک باید بگویم که هوش مصنوعی مهم است.</input>
    <output>هوش مصنوعی ابزار مهمی است.</output>
  </example>
  <example>
    <input>شایان ذکر است که این روش در عصر حاضر کاربرد دارد.</input>
    <output>این روش کاربرد دارد.</output>
  </example>
</examples>

Chain-of-Thought: افزودن زنجیره‌ی تفکر برای تکالیف استدلالی#

زنجیره‌ی تفکر (Chain-of-Thought) یعنی مدل را وادار کنید مراحل استدلال را بنویسد، نه فقط پاسخ نهایی. این تکنیک برای تکالیف ریاضی، منطقی و تحلیل چندمرحله‌ای مؤثر است. برای تکالیف ساده‌ی خلاصه‌سازی یا بازنویسی، زنجیره‌ی تفکر فقط توکن اضافی مصرف می‌کند.

نکته‌ی عملی: مدل‌های استدلالی (Reasoning Models) مثل o1، زنجیره‌ی تفکر را خودکار انجام می‌دهند. برای این مدل‌ها، نوشتن «مراحل را توضیح بده» در پرامپت، زائد است.

Role Prompting: نقش‌دهی بدون ساختار نتیجه‌ی تصادفی تولید می‌کند#

نقش‌دهی (Role Prompting) یعنی به مدل بگویید «تو یک ویراستار فنی هستی». این تکنیک به‌تنهایی کافی نیست. نقش بدون محدودیت‌های صریح، فقط لحن را تغییر می‌دهد، نه ساختار را. نقش + محدودیت + قالب خروجی = پرامپت مهندسی‌شده.

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

مهندسی زمینه چه فرقی با مهندسی پرامپت دارد؟#

مهندسی پرامپت طراحی ورودی مدل است. مهندسی زمینه (Context Engineering) مدیریت کل فضای ورودی را پوشش می‌دهد: اسناد بازیابی‌شده، تاریخچه‌ی مکالمه، محدودیت‌های سیستم و ترتیب قرارگیری همه‌ی این‌ها. پرامپت، زیرمجموعه‌ی زمینه است.

تعریف عملی: پرامپت = طراحی ورودی، زمینه = مدیریت کل فضای ورودی#

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

چرا بیشتر مشکلات پرامپت در واقع مشکلات زمینه‌اند#

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

رابطه‌ی مهندسی زمینه با RAG و پنجره‌ی زمینه#

پنجره‌ی زمینه (Context Window) محدودیت فیزیکی مدل است. RAG (Retrieval-Augmented Generation) مکانیزم بازیابی اسناد مرتبط است. اگر RAG شما اسناد نامرتبط بازیابی کند، بهترین پرامپت دنیا هم نمی‌تواند خروجی درست تولید کند. مهندسی زمینه یعنی اطمینان از این‌که هر چیزی که وارد پنجره‌ی زمینه می‌شود، مرتبط و مرتب است.

اشتباهات رایج که پرامپت شما را بی‌اثر می‌کند#

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

«خروجی خوب بده» — ابهام در قالب و ناپایداری پاسخ#

«خوب» یک صفت کیفی است، نه یک معیار. مدل نمی‌داند «خوب» یعنی کوتاه، یعنی فنی، یعنی با مثال، یعنی بدون مقدمه. هر صفت کیفی را با یک نمونه‌ی ملموس یا یک معیار کمّی تعریف کنید.

«پرامپت بلندتر بهتر است» — هزینه‌ی توکن بدون بهبود کیفیت#

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

«مدل بد است» — وقتی مشکل از نبود محدودیت‌های صریح است#

اگر مدل خروجی ناسازگار می‌دهد، احتمالاً محدودیت‌های منفی ندارید. مدل در فضای باز، همه‌ی احتمالات را امتحان می‌کند. محدودیت‌های صریح، فضای تصمیم مدل را کوچک می‌کنند و ناپایداری را حذف می‌کنند.

«پرامپت انگلیسی همیشه بهتر جواب می‌دهد» — یک باور نادرست برای مدل‌های چندزبانه#

مدل‌های چندزبانه (Multilingual Models) مثل Claude و GPT-4o، فارسی را به‌خوبی درک می‌کنند. اگر پرامپت انگلیسی بهتر جواب می‌دهد، احتمالاً مشکل از توکنیزاسیون فارسی است (بخش بعد)، نه از زبان. راه‌حل: اصلاح ساختار پرامپت فارسی، نه ترجمه‌ی اجباری به انگلیسی.

چگونه پرامپت را تست و بهینه کنیم؟#

بهینه‌سازی پرامپت یک چرخه‌ی تکرار است: نوشتن، تست با ورودی‌های متنوع، ثبت نتایج و بازنگری. یک پرامپت قابل‌اتکا معمولاً در 2 تا 5 چرخه به بلوغ می‌رسد. نوشتن یک‌باره و انتظار نتیجه‌ی کامل، رویای مبتدیان است.

چرخه‌ی تکرار پرامپت: نوشتن، تست، ثبت، بازنگری#

مراحل چرخه‌ی بهینه‌سازی:

  1. نوشتن: پرامپت اولیه را با چهار بلوک اصلی بنویسید.
  2. تست: با حداقل 5 ورودی مختلف (شامل حالت‌های لبه) اجرا کنید.
  3. ثبت: خروجی‌ها را با تاریخ و شماره‌ی نسخه ثبت کنید.
  4. تحلیل: کدام ورودی‌ها خروجی نامطلوب دادند؟ چرا؟
  5. بازنگری: محدودیت یا قالب را اصلاح کنید. نسخه‌ی جدید ثبت شود.
  6. تکرار: تا پایداری مطلوب ادامه دهید.

طراحی ورودی‌های تست: حالت‌های لبه و ورودی‌های مبهم#

ورودی‌های تست باید سه دسته باشند: حالت معمولی (Happy Path)، حالت لبه (ورودی خیلی کوتاه، خیلی بلند، بدون محتوا) و حالت مبهم (ورودی ناقص یا متناقض). اگر پرامپت شما فقط در حالت معمولی کار می‌کند، در تولید شکست می‌خورد.

نسخه‌بندی پرامپت و ابزارهای مدیریت#

برای تیم‌های کوچک، یک فایل Markdown با جدول تغییرات کافی است. برای پروژه‌های بزرگ‌تر، ابزارهایی مثل LangChain و DSPy امکان نسخه‌بندی، تست خودکار و ارزیابی مقایسه‌ای ارائه می‌دهند. انتخاب ابزار به حجم تیم و پیچیدگی تکالیف بستگی دارد:

ابزار مناسب برای قابلیت اصلی پیچیدگی راه‌اندازی
فایل Markdown + Git تیم‌های 1 تا 3 نفره نسخه‌بندی ساده، لاگ تغییرات پایین
LangSmith تیم‌های 3 تا 10 نفره تست خودکار، ردیابی اجرا متوسط
DSPy پروژه‌های تحقیقاتی بهینه‌سازی خودکار پرامپت بالا

مهندسی پرامپت فارسی: چالش‌های توکنیزاسیون و نیم‌فاصله#

پرامپت فارسیِ بدون نیم‌فاصله و با اعداد فارسی در مرحله‌ی توکنیزاسیون (Tokenization) به قطعات معنایی‌شکسته تبدیل می‌شود و خروجی ناسازگار تولید می‌کند. این مشکل ساختاری است، نه محتوایی.

نیم‌فاصله و توکنیزاسیون: چرا «مهندسی پرامپت» با «مهندسی‌پرامپت» متفاوت پردازش می‌شود#

مدل‌های زبانی متن را به توکن‌های کوچک‌تر تقسیم می‌کنند. «مهندسی پرامپت» با فاصله‌ی کامل، دو توکن مجزا می‌شود. «مهندسی‌پرامپت» بدون فاصله، ممکن است به قطعات بی‌معنا شکسته شود. نیم‌فاصله (Zero-Width Non-Joiner) به توکنایزر کمک می‌کند مرزهای معنایی کلمات مرکب را تشخیص دهد.

قاعده‌ی عملی: هر جا در فارسی‌نویسی استاندارد نیم‌فاصله می‌گذارید، در پرامپت هم بگذارید. پرامپت فارسی، فارسی‌نویسی استاندارد است، نه تایپ بی‌قاعده.

اعداد لاتین در پرامپت فارسی: سازگاری خروجی و خوانایی ماشین#

اعداد فارسی (۱، ۲، ۳) در خروجی مدل ناسازگارند؛ گاهی لاتین برمی‌گردند، گاهی فارسی. اگر پرامپت شما شامل اعداد است، از ارقام لاتین (1, 2, 3) استفاده کنید. مدل‌ها اعداد لاتین را بهتر درک می‌کنند و خروجی‌شان سازگارتر است.

ساختارهای دستوری فارسی که مدل‌ها در درک آن‌ها خطا می‌کنند#

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

چه زمانی مهندسی پرامپت کافی نیست؟#

وقتی نیاز به تغییر رفتار بنیادین مدل دارید یا داده‌های ساختارمند تخصصی دارید، مهندسی پرامپت جایگزین تنظیم دقیق (Fine-Tuning) نیست. پرامپت، رفتار مدل را در چارچوب دانش از پیش‌آموزش‌شده هدایت می‌کند؛ آن را بازآموزی نمی‌کند.

مرز مهندسی پرامپت و Fine-Tuning: چه‌وقت پرامپت به‌تنهایی جواب نمی‌دهد#

اگر مدل شما در یک حوزه‌ی تخصصی خاص (مثلاً زبان پزشکی فارسی یا ساختارهای حقوقی ایران) مکرراً خطا می‌کند و با هیچ پرامپتی اصلاح نمی‌شود، نیاز به Fine-Tuning دارید. نشانه‌ی عملی: اگر بعد از 5 چرخه‌ی بهینه‌سازی، هنوز بیشتر از نیمی از ورودی‌ها خروجی نامطلوب می‌دهند، پرامپت به‌تنهایی کافی نیست.

تأثیر مدل‌های استدلالی بر آینده‌ی پرامپت‌نویسی#

مدل‌های استدلالی (Reasoning Models) مثل o1 و o3، زنجیره‌ی تفکر را خودکار انجام می‌دهند. این یعنی بخش زیادی از پرامپت‌نویسی سنتی (دستور دادن برای «مرحله به مرحله فکر کن») زائد می‌شود. اما محدودیت‌های خروجی، قالب، زمینه و شرایط ابطال هنوز باید صریح تعریف شوند. مهندسی پرامپت منسوخ نمی‌شود؛ از «دستور دادن» به «طراحی محدودیت» تغییر ماهیت می‌دهد.

قانون «هرچه پرامپت انتزاعی‌تر، خروجی ناپایدارتر»#

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

جمع‌بندی عملی#

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

اگر می‌خواهید این ساختارها را در پروژه‌های واقعی پیاده کنید و با تیمی کار کنید که روزانه با این چالش‌ها سروکار دارد، دورهٔ «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول، دقیقاً همین مسیر را پوشش می‌دهد — از پرامپت‌نویسی تا ساخت ایجنت.