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

لیست مطالب
پرامپت تستمحور چیست و چرا مهم است؟
روش تستمحور یا «توسعهٔ آزمونمحور» (Test-Driven Development) سالهاست میان برنامهنویسها شناخته شده است: اول آزمون مینویسی، بعد کدی میسازی که آزمون را پاس کند. پرامپت تستمحور همین ایده را به همکاری با هوش مصنوعی میآورد. تفاوت کلیدی این است که در حالت معمولی، خودِ مدل هم کد را مینویسد و هم میگوید «کار میکند»؛ یعنی هم بازیکن است و هم داور. وقتی آزمونها را جدا و از قبل تعریف میکنی، یک داورِ بیطرف میسازی که قضاوتش به حرفِ مدل بستگی ندارد.
اهمیت این کار در یک جمله خلاصه میشود: آزمون، انتظارِ تو را به زبانِ ماشین ترجمه میکند. تا وقتی انتظارت مبهم باشد («یک تابع خوب برای اعتبارسنجی بنویس»)، مدل هم جوابِ مبهم میدهد. اما وقتی انتظارت پنج حالتِ مشخص است، مدل دقیقاً میداند هدف کجاست و تو هم دقیقاً میدانی کِی به آن رسیدهای.
چرخهٔ قرمز، سبز، پاکسازی؛ قلبِ روش تستمحور
کلِ این روش روی یک حلقهٔ سهمرحلهای میچرخد که در دنیای برنامهنویسی به «قرمز، سبز، پاکسازی» معروف است:
- قرمز: اول آزمونها را مینویسی. چون هنوز کدی وجود ندارد، همهٔ آزمونها شکست میخورند و چراغ قرمز است. این عمدی است؛ یعنی معیارت آماده شده.
- سبز: از مدل میخواهی سادهترین کدی را بنویسد که همهٔ آزمونها را پاس کند. هدف در این مرحله زیبایی نیست، فقط سبز شدن است.
- پاکسازی: حالا که آزمونها سبزند، از مدل میخواهی کد را خواناتر و تمیزتر کند، بدون اینکه هیچ آزمونی دوباره قرمز شود.
زیبایی این حلقه در آرامشِ خیال است: هر تغییری که بعداً بدهی، کافی است دوباره آزمونها را اجرا کنی. اگر همه سبز ماندند، خرابکاری نکردهای.
گام اول: خروجی و رفتار را دقیق توصیف کن
قبل از هر آزمونی، باید بدانی «درست» یعنی چه. یک جملهٔ روشن بنویس که بگوید تابع چه ورودیای میگیرد، چه خروجیای میدهد و در حالتهای خطا چه رفتاری دارد. همین توصیفِ کوتاه، هم راهنمای آزموننویسی توست و هم بخشی از پرامپت نهایی. مثلاً برای اعتبارسنجی شمارهٔ موبایل ایران: «تابعی میخواهم که یک رشته بگیرد و فقط وقتی True برگرداند که دقیقاً یازده رقم باشد، با ۰۹ شروع شود و همهاش رقم باشد؛ در غیر اینصورت False.»
هرچه این توصیف دقیقتر باشد، حالتهای مرزی زودتر خودشان را نشان میدهند: رشتهٔ خالی چه میشود؟ شمارهای که حرف دارد چطور؟ همین سؤالها ستونفقراتِ مجموعهٔ آزمون تو هستند.

گام دوم: از هوش مصنوعی بخواه اول آزمون بنویسد
حالا نوبت ساختن آزمونهاست. نکتهٔ مهم این است که آزمونها باید معیارِ تو را نشان بدهند، نه سلیقهٔ مدل را. بهترین کار این است که از مدل بخواهی چند حالتِ آزمون پیشنهاد بدهد، ولی خودت آنها را بازبینی و کامل کنی؛ مخصوصاً حالتهای مرزی و خطا را که مدلها معمولاً از قلم میاندازند. یک پرامپت نمونه:
«میخواهم با روش تستمحور پیش برویم. هنوز کد ننویس. برای تابعی به نام is_valid_mobile که اعتبارسنجی شمارهٔ موبایل ایران را انجام میدهد، فقط مجموعهای از آزمونهای pytest بنویس. این حالتها را حتماً پوشش بده: شمارهٔ درست، پیششمارهٔ اشتباه، طول کوتاه، وجود حرف در رشته، و رشتهٔ خالی.»
خروجی چیزی شبیه این خواهد بود؛ پنج آزمونِ روشن که هرکدام یک انتظارِ مشخص را میسنجند:
def test_valid():
assert is_valid_mobile("09123456789") is True
def test_wrong_prefix():
assert is_valid_mobile("08123456789") is False
def test_too_short():
assert is_valid_mobile("0912345") is False
def test_has_letters():
assert is_valid_mobile("0912345678a") is False
def test_empty():
assert is_valid_mobile("") is False
اگر همین حالا این آزمونها را اجرا کنی، همه شکست میخورند، چون هنوز تابعی وجود ندارد. این همان چراغ قرمز است؛ یعنی معیارت آماده و اجراپذیر شده.
گام سوم: کد را بگیر و آزمونها را واقعاً اجرا کن
حالا از مدل میخواهی کدی بسازد که این آزمونها را سبز کند. مهمترین قاعدهٔ این مرحله این است: به ادعای مدل که «این کد آزمونها را پاس میکند» اعتماد نکن؛ خودت آزمونها را اجرا کن. مدلها اغلب کدی میدهند که بهنظر درست میآید ولی یک حالت را جا انداخته است. یک پرامپت نمونه:
«حالا سادهترین نسخهٔ تابع is_valid_mobile را بنویس که همهٔ این پنج آزمون را پاس کند. فقط خودِ تابع را بده، بدون توضیح اضافه.»
فرض کن مدل این نسخه را میدهد:
def is_valid_mobile(s):
return len(s) == 11 and s.startswith("09")
بهنظر منطقی میآید. اما وقتی pytest را اجرا میکنی، یک آزمون قرمز میماند: test_has_letters. چرا؟ چون رشتهٔ «0912345678a» یازده کاراکتر است و با ۰۹ شروع میشود، پس تابع اشتباهاً True برمیگرداند. این دقیقاً همان باگی است که در روش «اول کد، بعد امید» بهراحتی منتشر میشد و بعداً دردسر میساخت. برای درک عمیقتر اینکه چرا وادار کردن مدل به استدلال گامبهگام جلوی این خطاها را میگیرد، نگاهی به زنجیرهٔ تفکر در کدنویسی و دیباگ هم بینداز.

گام چهارم: خطای آزمون را برگردان تا مدل خودش را اصلاح کند
اینجاست که قدرتِ واقعیِ روش تستمحور آشکار میشود. بهجای اینکه خودت دنبال باگ بگردی، خروجیِ دقیقِ آزمونِ شکستخورده را کپی میکنی و به مدل برمیگردانی. خطای آزمون یک بازخوردِ عینی و بیطرف است؛ مدل دیگر حدس نمیزند، بلکه دقیقاً میداند کجا اشتباه کرده. یک پرامپت نمونه:
«آزمون test_has_letters شکست خورد: ورودی «0912345678a» باید False برگردد ولی تابع True داد. کد را طوری اصلاح کن که این حالت هم درست شود و بقیهٔ آزمونها هم سبز بمانند.»
مدل حالا کمبود را میبیند و شرطِ «همه رقم باشد» را اضافه میکند:
def is_valid_mobile(s):
return len(s) == 11 and s.startswith("09") and s.isdigit()
دوباره pytest را اجرا میکنی و اینبار هر پنج آزمون سبز میشوند. حلقه کامل شد: قرمز، سبز، و حالا اگر بخواهی، پاکسازی. این چرخه را میتوانی برای هر حالتِ جدیدی که بعداً کشف میکنی تکرار کنی؛ فقط یک آزمونِ تازه اضافه کن و همان حلقه را دوباره بچرخان.
یک نمونهٔ کامل؛ از صفر تا سبز شدن همهٔ آزمونها
بیایید کل مسیر را یکجا کنار هم بگذاریم تا الگو در ذهنت بنشیند. فرض کن میخواهی تابعی برای محاسبهٔ قیمت بعد از تخفیف بسازی. مسیرِ تستمحور اینطور پیش میرود:
- توصیف: تابع price و percent میگیرد، قیمتِ نهایی را برمیگرداند؛ اگر percent بیرون از بازهٔ صفر تا صد باشد یا قیمت منفی باشد، خطا بدهد.
- آزمونها: از مدل میخواهی آزمون بنویسد برای: تخفیف عادی (۱۰۰ با ۲۰٪ میشود ۸۰)، تخفیف صفر (قیمت بیتغییر)، تخفیف صد (خروجی صفر)، درصدِ بیرون از بازه (باید خطا بدهد) و قیمتِ منفی (باید خطا بدهد).
- کد: مدل نسخهٔ اول را میدهد، ولی احتمالاً حالتِ درصدِ بیرون از بازه را فراموش میکند.
- بازخورد: آزمونِ شکستخورده را برمیگردانی؛ مدل شرطِ اعتبارسنجیِ ورودی را اضافه میکند و همهچیز سبز میشود.
نکتهٔ مهم این است که تو در هیچ مرحلهای مجبور نشدی خطِ به خطِ کد را وارسی کنی؛ آزمونها این کار را برایت کردند. اگر بخواهی مطمئن شوی که این پنج آزمون واقعاً معیارِ خوبی هستند، میتوانی همانطور که در آموزش ارزیابی پرامپت گفتیم، کیفیتِ خودِ آزمونها و پرامپت را هم بسنجی.
قالب آمادهٔ پرامپت تستمحور
این قالب را میتوانی ذخیره کنی و برای هر تابعی که میخواهی بسازی، جاهای خالیاش را پر کنی:
«با روش تستمحور پیش میرویم و مرحلهبهمرحله جلو میرویم.
یک) هدف: تابعی میخواهم که [توصیف دقیق ورودی، خروجی و رفتار در خطا].
دو) اول فقط آزمونهای pytest را بنویس و این حالتها را پوشش بده: [حالت عادی]، [حالت مرزی]، [حالت خطا]. هنوز کد ننویس.
سه) بعد از تأیید من، سادهترین کدی را بده که همهٔ آزمونها را پاس کند.
چهار) من نتیجهٔ اجرای آزمونها را برمیگردانم؛ اگر آزمونی قرمز بود، فقط همان را اصلاح کن و مطمئن شو بقیه سبز میمانند.»
همین ساختارِ ساده، مدل را از حالتِ «هرچه به ذهنم رسید» به حالتِ «قدمبهقدم و قابلسنجش» میبرد. اگر کارت چند تابعِ بههموابسته است، میتوانی این قالب را با سنجش کیفیت و تکنیکهای زنجیرهای ترکیب کنی تا هر تکه جداگانه سبز شود و بعد کنار هم بنشینند.
اشتباههای رایج در پرامپت تستمحور
چند دام هست که تازهکارها معمولاً در آن میافتند و ارزشِ روش را کم میکنند:
- گذاشتنِ آزمون بهعهدهٔ مدل، بدون بازبینی: اگر مدل هم کد را بنویسد و هم آزمون را، ممکن است آزمونها دقیقاً همان اشتباهِ کد را داشته باشند. تو باید معیار را مالک باشی.
- اجرا نکردنِ آزمونها: «بهنظر درست میآید» تلهٔ اصلی است. تا آزمون را واقعاً اجرا نکنی، نمیدانی سبز است یا نه.
- فراموش کردنِ حالتهای مرزی و خطا: بیشتر باگها در ورودی خالی، مقدار منفی، یا حالتِ نامعمول پنهاناند، نه در حالتِ عادی.
- نوشتنِ آزمونهای مبهم: آزمونی که خروجی مشخصی را چک نمیکند، عملاً هیچ چیزی را تضمین نمیکند.
پرسشهای پرتکرار
آیا برای هر کار کوچکی باید تست بنویسم؟
نه لزوماً. برای یک اسکریپتِ یکبارمصرف شاید ارزشش را نداشته باشد. اما هر جا که کد قرار است بماند، دوباره استفاده شود یا دیگران به آن تکیه کنند، حتی سه چهار آزمونِ ساده هم جلوی کلی دردسرِ بعدی را میگیرد.
اگر خودم بلد نباشم تست بنویسم چه کنم؟
اشکالی ندارد؛ از مدل بخواه چند آزمون پیشنهاد بدهد و برایت توضیح دهد هر آزمون چه چیزی را میسنجد. کارِ تو این است که آنها را بخوانی، حالتهای جامانده را اضافه کنی و تصمیم بگیری کدام رفتار درست است. مالکیتِ معیار مهمتر از نوشتنِ فنیِ آزمون است.
پرامپت تستمحور با کدام مدلها بهتر کار میکند؟
با مدلهای قویتر در کدنویسی مثل نسخههای پیشرفتهٔ ChatGPT و Claude نتیجهٔ روانتری میگیری، اما اصلِ روش مستقل از مدل است. حتی با یک مدل متوسط هم چون معیارت اجراپذیر و بیطرف است، کیفیتِ خروجی بهطور محسوسی بالا میرود.
فرق این روش با اینکه از مدل بخواهم کدش را چک کند چیست؟
وقتی از مدل میخواهی کدِ خودش را چک کند، همان مدلی که ممکن است اشتباه کرده باشد، دربارهٔ درستیِ خودش قضاوت میکند. آزمونِ مستقل یک سنجهٔ بیرونی است که به نظرِ مدل وابسته نیست؛ به همین دلیل خیلی مطمئنتر است.
در روش پرامپت تستمحور، ترتیب درستِ کار کدام است؟
این تمرین ویژهٔ اعضاست
برای دیدن این بخش باید عضو ویژه (VIP) باشی. با شمارهٔ موبایلت وارد شو تا ۱۴ روز دسترسی رایگان فعال شود.
🎁 ورود / ثبتنام و شروع ۱۴ روز رایگانجمعبندی
پرامپت تستمحور همان چیزی است که همکاری با هوش مصنوعی در کدنویسی را از «امیدوارم کار کند» به «مطمئنم کار میکند» میرساند. کافی است ترتیب را وارونه کنی: اول معیارِ درستی را بهشکل چند آزمونِ روشن بنویسی، بعد از مدل کد بخواهی، آزمونها را واقعاً اجرا کنی و خروجیِ خطا را برای اصلاح به مدل برگردانی. با همین حلقهٔ سادهٔ قرمز-سبز-پاکسازی، دیگر لازم نیست به هر تکه کدی که مدل میدهد کورکورانه اعتماد کنی؛ یک داورِ بیطرف داری که بهجای تو قضاوت میکند.
این درس بخشی از یک مسیر بزرگتر است. برای دیدن همهٔ سریهای آموزشی و ترتیبِ یادگیری، سری کاملِ راهنمای جامع پرامپتنویسی را ببین و از همانجا قدمبهقدم جلو برو.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
