بهترین تمرین‌های پرامپت‌نویسی کلود؛ صریح بنویس، دلیل بده، مثال درست بزن

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

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

آنچه در این درس یاد می‌گیرید

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

قاعدهٔ یکم؛ صریح باشید، نه مؤدب

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

کم‌اثر: «یک داشبورد تحلیلی بساز.»

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

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

قاعدهٔ دوم؛ دلیل دستورتان را بگویید

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

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

قاعده را این‌طور به یاد بسپارید: قانون بدون دلیل، فقط همان یک مورد را پوشش می‌دهد؛ قانون با دلیل، خانوادهٔ آن موارد را.

قاعدهٔ سوم؛ مثال‌ها را جدی بگیرید

مدل به جزئیات مثال‌های شما دقت می‌کند — گاهی بیش از خود دستورتان. اگر در نمونه‌ای که گذاشته‌اید سهواً یک جملهٔ تبلیغاتی مانده باشد، آن جمله برای مدل «قسمتی از سبک مطلوب» است، نه یک اشتباه. پیش از افزودن هر مثال، یک بار آن را با این پرسش بخوانید: «آیا هر ویژگی این نمونه، چیزی است که می‌خواهم تکرار شود؟»

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

قاعدهٔ چهارم؛ مثبت بگویید، نه منفی

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

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

الگوی آماده برای کارهای بلند

<task>
Refactor the payment module so it supports partial refunds.
</task>

<why>
Support agents currently issue partial refunds by hand in the admin panel,
which causes ledger mismatches at month end. Correctness of the ledger
matters more than speed of the implementation.
</why>

<rules>
- Read and understand the relevant files before proposing any edit.
  Do not speculate about code you have not inspected.
- Write a general-purpose solution that works for all valid inputs,
  not just the cases covered by the existing tests.
- Avoid over-engineering: make only the changes that are requested or
  clearly necessary. No speculative abstractions.
- If you create temporary scripts while iterating, delete them at the end.
</rules>

<progress>
After each step, append a JSON line to progress.json with:
{step, files_touched, tests_passing, next_action}
so work can resume in a fresh session.
</progress>

در این قالب هر چهار قاعده حاضرند: صراحت در بند دستور، دلیل در بند چرایی، دستورهای مثبت در بند قواعد، و مکانیزمی برای پیوستگی کار در بند پیشرفت.

قواعد ویژه وقتی پای کد در میان است

چهار توصیهٔ عملی که آنتروپیک صریحاً می‌آورد و هرکدام یک خرابی رایج را می‌بندد:

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

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

کارهای طولانی و ردیابی وضعیت

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

جمع‌بندی

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

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

منبع این درس، مستندات رسمی آنتروپیک است؛ ما آن را برای فارسی‌زبان‌ها درس کرده‌ایم.