پرامپت نویسی

پرامپتنویسی برای برنامهنویسها: ۱۰ الگوی کاربردی برای کدنویسی با هوش مصنوعی
خلاصه: تو این درس یاد میگیری چرا پرامپتنویسی برای برنامهنویسی با پرامپتنویسی معمولی فرق داره، یه پرامپت خوب برای کد از چه اجزایی ساخته میشه و ۱۰ الگوی آماده کپی برای برنامهریزی، نوشتن، دیباگ، تست و review کد رو با مثال واقعی میبینی. آخرش هم یاد میگیری این الگوها رو با هم ترکیب کنی.
احتمالاً برات پیش اومده: به ChatGPT یا Claude میگی «یه فرم لاگین بساز»، یه کد تمیز و خوشگل تحویلت میده، ولی با پروژهت جور نیست. کتابخونهای رو استفاده کرده که نداری، اسم متغیرها با بقیه کدت نمیخونه و اعتبارسنجی شماره موبایل ایرانی رو هم کلاً یادش رفته.
مشکل از مدل نیست؛ از پرامپته. تو این درس قراره پرامپتنویسی برای برنامهنویسی رو مثل یه مهارت فنی یاد بگیری، نه یه سری جمله جادویی. اگه درس اول رو نخوندی، مهندسی نرمافزار با هوش مصنوعی چیست؟ تصویر کلی این دانشنامه رو بهت میده.
قبل از پرامپت: ۳ چیز که باید درباره مدل بدونی
هر الگویی که پایینتر میبینی، جواب یکی از این سه واقعیته. پس اول اینها رو بشناس.
۱. مدل فقط چیزی رو میدونه که بهش میدی. پروژهت رو ندیده، نمیدونه از چه کتابخونهای استفاده میکنی و ذهنت رو هم نمیخونه. Anthropic تو راهنمای رسمیش میگه مدل رو مثل یه کارمند تازهوارد ولی فوقالعاده باهوش ببین که از روال کاری تیمت هیچی نمیدونه (Anthropic).
۲. حافظهش محدوده. همه حرفهایی که زدی، فایلهایی که خونده و خروجی دستورها، تو یه فضای محدود به اسم پنجره context (Context Window) جمع میشن. وقتی این فضا پر بشه، مدل دستورهای قبلی رو «فراموش» میکنه و اشتباهاتش بیشتر میشه (Claude Code Docs). برای همین چتهای طولانی و شلوغ معمولاً نتیجه بدتری میدن.
۳. با اعتمادبهنفس کامل اشتباه میکنه. مدل وقتی چیزی رو نمیدونه، معمولاً نمیگه «نمیدونم»؛ یه جواب قانعکننده میسازه. تو نظرسنجی استکاورفلو، ۶۶٪ برنامهنویسها بزرگترین مشکلشون با AI رو جوابهایی دونستن که «تقریباً درسته، ولی نه کاملاً» (TechRepublic). تو کد، «تقریباً درست» یعنی باگ.
چرا پرامپتنویسی برای برنامهنویسها فرق داره؟
اگه از AI یه متن تبریک تولد بخوای و یه کم بد دربیاد، خیلی بد نمیشه. ولی کد یا کار میکنه یا نمیکنه. یا امنه یا نیست. برای همین پرامپتنویسی برای برنامهنویسی بیشتر از اینکه «هنر» باشه، مهندسیه:
- دقیقتره: باید اسم فایل، نسخه فریمورک و رفتار انتظاری رو بگی، نه حالوهوا رو.
- قابلبررسیه: خروجی رو میشه با تست سنجید، پس باید از اول بگی «درست» یعنی چی.
- تکراریه: یه پرامپت خوب رو دهها بار برای کارهای مشابه استفاده میکنی. پژوهشگرهای دانشگاه وندربیلت هم برای همین الگوهای پرامپت رو مثل design patternهای نرمافزار، قالبهای قابلاستفادهی دوباره میدونن (White et al., 2023).
آناتومی یه پرامپت خوب برای کدنویسی

هر پرامپت کدنویسی خوب، این ۴ جزء رو داره:
| جزء | سؤالی که جواب میده | مثال |
|---|---|---|
| هدف | دقیقاً چی میخوای؟ | یه تابع برای اعتبارسنجی شماره موبایل ایرانی |
| Context | تو چه محیطی؟ | TypeScript، پروژه Next.js، فایل lib/validators.ts |
| محدودیتها | چی نباید عوض بشه؟ | بدون کتابخونه جدید، توابع فعلی دست نخورن |
| معیار تمام شدن | از کجا بفهمیم درسته؟ | این ۴ ورودی نمونه باید این جوابها رو بدن و تستها پاس بشن |
حالا ببین فرقش چقدره:
❌ پرامپت ضعیف:
یه تابع برای چک کردن شماره موبایل بنویس
✅ پرامپت خوب:
تو فایل lib/validators.ts (پروژه Next.js با TypeScript) یه تابع به اسم validatePhone بنویس که شماره موبایل ایرانی رو چک کنه.
شمارههای ۱۱ رقمی که با 09 شروع میشن معتبرن.
اعداد فارسی (مثل ۰۹۱۲...) هم باید قبول بشن.
از هیچ کتابخونه جدیدی استفاده نکن.
بعدش برای این تابع تست بنویس و اجراشون کن.
یه تست ساده هم برای پرامپتت هست که Anthropic بهش میگه قانون طلایی: پرامپتت رو به یه همکار نشون بده که از کار خبر نداره. اگه اون گیج شد، مدل هم گیج میشه (Anthropic).
۱۰ الگوی پرامپتنویسی برای کدنویسی با هوش مصنوعی
این ۱۰ الگو رو میتونی تو ChatGPT، Claude، Cursor یا هر ایجنت کدنویسی دیگهای استفاده کنی. جاهایی که داخل [ ] نوشته شده رو با اطلاعات پروژه خودت عوض کن.
۱. قالب پایه ۴ جزئی
کی به کارت میاد: همیشه. این قالب پیشفرض هر درخواستیه که میخوای کد تحویل بگیری.
هدف: [دقیقاً چی باید ساخته یا درست بشه]
Context: [زبان، فریمورک و نسخه، فایلهای مرتبط]
محدودیتها: [چی نباید عوض بشه، کتابخونههای مجاز]
معیار تمام شدن: [تست یا خروجیای که نشون بده کار درسته]
نکته: لازم نیست همیشه این عنوانها رو بنویسی. کافیه این ۴ تا تو پرامپتت باشن، حتی تو یه پاراگراف معمولی.
۲. اول سؤال بپرس (Clarify First)
کی به کارت میاد: وقتی فیچر بزرگه یا خودت هنوز همه جزئیاتش رو نمیدونی.
میخوام [توضیح کوتاه فیچر] رو بسازم.
قبل از نوشتن هر کدی، سؤالهایی که برای انجام درست این کار لازمه رو ازم بپرس؛ مخصوصاً درباره edge caseها و چیزهایی که ممکنه بهشون فکر نکرده باشم.
سؤالهای بدیهی نپرس. تا جواب ندادم، کد ننویس.
مثال: برای «سبد خرید» احتمالاً ازت میپرسه اگه موجودی کالا وسط خرید تموم شد چی بشه، یا سبد کاربر مهمون بعد از لاگین چی میشه. سؤالهایی که اگه الان جواب ندی، بعداً به شکل باگ برمیگردن.
راهنمای رسمی Claude Code هم برای فیچرهای بزرگ دقیقاً همین رو پیشنهاد میده: بذار مدل ازت «مصاحبه» کنه (Claude Code Docs). نسخه کامل این کار، یعنی نوشتن مشخصات (Spec) قبل از کد، موضوع درس ۱۰ هست.
۳. اول برنامه، بعد کد (Plan First)

کی به کارت میاد: وقتی تغییر چند فایل رو درگیر میکنه یا با اون بخش کد آشنا نیستی.
فایلهای [مسیر یا پوشه] رو بخون و بفهم [بخش مورد نظر] الان چطور کار میکنه. هنوز هیچ تغییری نده.
بعد یه برنامه بهم بده: چه فایلهایی باید عوض بشن، به چه ترتیبی، و چه ریسکهایی داره.
برنامه رو بخون، اصلاحش کن و بعد بگو اجراش کنه. اگه مستقیم بری سراغ کد، ممکنه مدل یه مسئله اشتباه رو خیلی تمیز حل کنه!
دام: برای کارهای کوچیک لازم نیست. Anthropic یه قاعده ساده داره: اگه میتونی تغییر رو تو یه جمله توضیح بدی، برنامه لازم نیست (Claude Code Docs).
۴. یه قدم در هر پرامپت (Small Steps)
کی به کارت میاد: وقتی کار بزرگه و برنامهش رو داری.
از برنامهای که دادی، فقط قدم ۱ رو انجام بده: [توضیح قدم].
بعدش وایستا تا خروجی رو بررسی کنم.
چرا جواب میده: بررسی یه تغییر ۳۰ خطی راحته؛ بررسی تغییر ۸۰۰ خطی تو ۱۲ فایل تقریباً غیرممکنه. قدمهای کوچیک یعنی هر اشتباه زود پیدا میشه و برگردوندنش هم ارزونه.
۵. از روی نمونه بساز (Show an Example)

کی به کارت میاد: وقتی میخوای کد جدید دقیقاً شبیه بقیه پروژهت باشه.
به [فایل نمونه] نگاه کن و ببین [کامپوننتها / endpointها]ی این پروژه چطور نوشته شدن.
دقیقاً با همین الگو، [چیز جدید] رو بساز.
فقط از کتابخونههایی استفاده کن که الان تو پروژه هست.
مثال: «به ProductCard.tsx نگاه کن و با همون سبک، یه ArticleCard بساز.» Anthropic مثال دادن رو یکی از مطمئنترین راهها برای کنترل شکل و ساختار خروجی میدونه (Anthropic). تو کدنویسی، بهترین مثال کد خود پروژهته.
۶. محدوده رو قفل کن (Scope Lock)
کی به کارت میاد: وقتی مدل عادت داره «یه کم بیشتر» کار کنه: فایلهای دیگه رو هم عوض میکنه، کتابخونه جدید نصب میکنه یا چیزی رو بازنویسی میکنه که کسی نخواسته بود.
فقط فایل [X] رو تغییر بده.
فقط از کتابخونههایی استفاده کن که الان تو package.json هست.
اسم و ورودی و خروجی توابع عمومی رو همونطور نگه دار.
اگه فکر میکنی برای این کار باید چیزی خارج از این محدوده عوض بشه، اول بهم بگو.
نکته: دقت کن که به جای «این کار رو نکن»، تا جای ممکن گفتیم «این کار رو بکن». Anthropic هم همین رو توصیه میکنه: به مدل بگو چی کار کنه، نه فقط چی کار نکنه (Anthropic). محدود کردن کتابخونهها جلوی یه خطر واقعی رو هم میگیره: پکیجهایی که مدل از خودش اسمشون رو میسازه. این خطر رو تو معایب وایب کدینگ کامل توضیح دادیم.
۷. گزارش باگ کامل (Bug Report)
کی به کارت میاد: هر وقت چیزی خراب شده. «درستش کن» بدترین پرامپت دیباگه!
مشکل: [چی اتفاق میافته]
انتظار: [چی باید اتفاق بیفته]
مراحل بازتولید:
۱. [...]
۲. [...]
خطای کامل:
[متن کامل خطا یا stack trace، بدون خلاصه کردن]
جای احتمالی: [فایل یا بخش]
علت اصلی رو پیدا و درست کن؛ خطا رو سرکوب نکن.
اول یه تست بنویس که این باگ رو نشون بده، بعد درستش کن.
چرا جواب میده: مدل نمیتونه صفحه تو رو ببینه. متن کامل خطا، مراحل بازتولید و رفتار انتظاری همون چیزهاییان که یه برنامهنویس ارشد هم اول ازت میپرسه. جمله «خطا رو سرکوب نکن» هم مستقیماً از راهنمای Claude Code میاد (Claude Code Docs). بدون اون، مدل گاهی فقط یه try/catch میذاره که خطا دیده نشه!
۸. معیار تمام شدن (Definition of Done)
کی به کارت میاد: همیشه، ولی مخصوصاً با ایجنتها.
تابع validatePhone رو بنویس. اینها باید درست کار کنن:
"09121234567" → true
"9121234567" → false
"۰۹۱۲۱۲۳۴۵۶۷" (اعداد فارسی) → true
"0912123456" (۱۰ رقم) → false
بعد از نوشتن، تستها رو اجرا کن و خروجیشون رو نشونم بده.
چرا مهمه: مدل وقتی کار «به نظر» تموم شده، وایمیسته. اگه یه چیز قابلاجرا مثل تست یا build بهش بدی، خودش کار رو چک میکنه و تا درست نشه ادامه میده. راهنمای Claude Code این رو فرق بین «جلسهای که باید بالای سرش باشی» و «جلسهای که میتونی ولش کنی» میدونه (Claude Code Docs).
دام: گاهی مدل برای پاس کردن تست، جوابها رو hard-code میکنه. یه جمله اضافه کن: «راهحل باید برای همه ورودیهای معتبر کار کنه، نه فقط این تستها» (Anthropic). ورکفلو کامل تستنویسی رو تو درس ۲۸ میبینی.
۹. نقش منتقد (Critic)

کی به کارت میاد: بعد از اینکه کد نوشته شد و قبل از اینکه commit کنی.
این کد رو مثل یه reviewer سختگیر بررسی کن: [کد یا مسیر فایل]
فقط مشکلاتی رو گزارش کن که روی درستی، امنیت یا نیازمندیها اثر دارن؛ مسائل سلیقهای رو نگو.
برای هر مشکل: خط، دلیل و پیشنهاد اصلاح.
دو نکته:
- تو یه چت تازه بپرس. مدلی که خودش کد رو نوشته، نسبت بهش سوگیری داره. review تو context تازه بهتر جواب میده (Claude Code Docs).
- محدودش کن. منتقدی که بهش گفتی ایراد پیدا کنه، همیشه یه چیزی پیدا میکنه، حتی وقتی کد سالمه. اگه همه پیشنهادهاش رو قبول کنی، کدت پر از لایههای اضافه میشه. برای همین تو قالب گفتیم فقط ایرادهای مهم.
چکلیست کامل review کد تولیدشده رو تو درس ۲۹ داریم.
۱۰. یادم بده (Explain to Learn)
کی به کارت میاد: وقتی کدی تحویل گرفتی که کار میکنه، ولی دقیقاً نمیدونی چطور.
این کد رو برای کسی توضیح بده که [سطح تو، مثلاً «جاوااسکریپت بلده ولی با React تازه آشنا شده»].
۱. تو یه پاراگراف بگو کلاً چی کار میکنه.
۲. بخشهای مهمش رو خطبهخط توضیح بده.
۳. یه جایی که ممکنه بعداً خراب بشه رو نشونم بده.
۴. آخرش ۳ سؤال ازم بپرس تا مطمئن بشی فهمیدم.
چرا مهمه: هر خط کدی که نمیفهمی، یه بدهیه که یه روز باید پسش بدی؛ معمولاً همون روزی که کد خراب شده و مشتری منتظره. این الگو کمک میکنه کدنویسی با هوش مصنوعی تو رو تنبل نکنه، بلکه سریعتر یادت بده.
جدول تقلب: ۱۰ الگو در یک نگاه
| # | الگو | کی استفاده کنم | جمله کلیدی |
|---|---|---|---|
| ۱ | قالب پایه | همیشه | هدف + context + محدودیت + معیار |
| ۲ | اول سؤال بپرس | فیچر بزرگ یا مبهم | «تا جواب ندادم، کد ننویس» |
| ۳ | اول برنامه | تغییر چندفایلی | «هنوز هیچ تغییری نده» |
| ۴ | یه قدم | کار بزرگ | «فقط قدم ۱، بعد وایستا» |
| ۵ | از روی نمونه | حفظ سبک پروژه | «دقیقاً با همین الگو» |
| ۶ | قفل محدوده | جلوگیری از تغییر اضافه | «فقط فایل X» |
| ۷ | گزارش باگ | دیباگ | «علت اصلی، نه سرکوب خطا» |
| ۸ | معیار تمام شدن | همیشه، مخصوصاً با ایجنت | «تستها رو اجرا کن و نشونم بده» |
| ۹ | منتقد | قبل از commit | «فقط مشکلات مهم» |
| ۱۰ | یادم بده | کدی که نمیفهمی | «۳ سؤال ازم بپرس» |
ترکیب الگوها در عمل: یه فیچر از صفر با ۵ پرامپت
الگوها وقتی واقعاً خفن میشن که پشت سر هم استفادهشون کنی. فرض کن میخوای به صفحه محصولات یه فروشگاه جستوجو و فیلتر قیمت اضافه کنی:
پرامپت ۱، اول سؤال بپرس:
میخوام به صفحه app/products/page.tsx جستوجو و فیلتر بازه قیمت اضافه کنم.
قبل از کد، سؤالهای لازم رو ازم بپرس.
مدل میپرسه: جستوجو سمت سرور باشه یا کاربر؟ فیلترها تو URL بمونن که لینکش قابلاشتراک باشه؟ قیمت به تومان باشه یا ریال؟ جواب میدی.
پرامپت ۲، اول برنامه:
با این جوابها، کد فعلی صفحه محصولات و API مربوطش رو بخون و یه برنامه چندقدمی بده. هنوز چیزی رو تغییر نده.
پرامپت ۳، یه قدم با قفل محدوده:
فقط قدم ۱ برنامه رو انجام بده: اضافه کردن پارامترهای q و minPrice و maxPrice به API.
فقط فایل app/api/products/route.ts رو تغییر بده. بعد وایستا.
پرامپت ۴، معیار تمام شدن:
برای این API تست بنویس: جستوجوی «کفش» فقط محصولات مرتبط رو برگردونه، minPrice بزرگتر از maxPrice خطای 400 بده، و پارامتر خالی همه محصولات رو برگردونه. تستها رو اجرا کن و خروجی رو نشونم بده.
پرامپت ۵، منتقد (تو یه چت تازه):
تغییرات فایل app/api/products/route.ts رو بررسی کن. فقط مشکلات مربوط به درستی، امنیت (مثلاً تزریق در جستوجو) و کارایی رو گزارش کن.
میبینی؟ هیچکدوم از این پرامپتها جادویی نیستن. فقط هرکدوم یه کار مشخص دارن و تو کنترل کل مسیر رو نگه داشتی.
پرامپت در چت، ادیتور و ایجنت چه فرقی داره؟
اصول یکیه، ولی هر محیط یه نکته خودش رو داره:
- چت (ChatGPT، Claude، Gemini): مدل هیچی از پروژهت نمیبینه. هر contextای لازمه، از کد مرتبط تا خطای کامل، رو خودت باید تو پیام بذاری. الگوهای ۱ و ۷ اینجا از همه مهمترن.
- ادیتور هوش مصنوعی (Cursor، GitHub Copilot): مدل فایلهای پروژه رو میبینه و میتونی با
@به فایلها اشاره کنی. پس به جای کپی کردن کد، بگو «به@ProductCard.tsxنگاه کن». الگوی ۵ اینجا خیلی قویه. - ایجنت کدنویسی (Claude Code، Codex): ایجنت خودش فایل میخونه، دستور اجرا میکنه و تست میگیره. یعنی الگوی ۸ (معیار تمام شدن) قدرتمندترین ابزارته و الگوی ۶ (قفل محدوده) مهمترین ترمزت. هرچی اختیار ایجنت بیشتر باشه، این دوتا حیاتیترن.
کار با هرکدوم از این ابزارها رو از درس ۱۲ به بعد قدمبهقدم یاد میگیری.
۶ اشتباه رایج در پرامپتنویسی برای کد

- پرامپت مبهم: «درستش کن»، «بهترش کن»، «یه صفحه خوشگل بساز». مدل حدس میزنه و حدسش معمولاً با چیزی که تو ذهنته فرق داره.
- کل پروژه تو یه پرامپت: «یه فروشگاه کامل با پنل ادمین و درگاه پرداخت بساز.» نتیجهش یه عالمه کده که نه میشه بررسیش کرد، نه درستش کرد.
- خلاصه کردن خطا: «یه ارور میده درباره undefined.» متن کامل خطا رو کپی کن؛ معمولاً جواب همون خط آخرشه.
- اصرار تو یه چت خراب: اگه دو بار اصلاحش کردی و هنوز اشتباهه، context پر از تلاشهای غلط شده. راهنمای Claude Code میگه یه چت تازه با یه پرامپت بهتر تقریباً همیشه از یه چت طولانی پر از اصلاحیه بهتر جواب میده (Claude Code Docs). برای گیرهای جدیتر، درس ۸ رو ببین.
- یه لیست بلند «نکن» بدون گفتن جایگزین: «اینو نکن، اونو نکن، این یکی هم نه...» به جاش بگو دقیقاً چی میخوای.
- گذاشتن اطلاعات حساس تو پرامپت: کلید API، رمز دیتابیس یا اطلاعات واقعی مشتریها رو هیچوقت تو پرامپت نذار. به جاش از مقدارهای نمونه و فایل
.envاستفاده کن.
سوالات پرتکرار درباره پرامپتنویسی برای برنامهنویسی
پرامپت رو فارسی بنویسم یا انگلیسی؟
هر دو کار میکنن و مدلهای جدید فارسی رو خوب میفهمن. ولی دو نکته رو بدون:
- اصطلاحات فنی رو انگلیسی بنویس: اسم فایل، تابع، کتابخونه و متن خطا رو همونطور که هست بذار. ترجمهشون فقط ابهام درست میکنه.
- متن فارسی معمولاً توکن بیشتری مصرف میکنه. یه پژوهش نشون داده یه محتوای یکسان تو زبانهای مختلف میتونه تا ۱۵ برابر تعداد توکن متفاوت داشته باشه. این روی هزینه، سرعت و پر شدن context اثر داره (Petrov et al., NeurIPS 2023). برای پرامپتهای کوتاه مهم نیست، ولی برای متنهای خیلی طولانی مثل مستندات بهتره انگلیسی باشن.
پرامپت کوتاه بهتره یا بلند؟
دقیق بهتره، نه لزوماً بلند. یه پرامپت سهخطی با هدف، فایل و معیار مشخص، از یه پرامپت سیخطی پر از توضیح اضافه بهتره. فقط وقتی داری کاوش میکنی، مثلاً «تو این فایل چی رو بهتر میکنی؟»، پرامپت باز و کوتاه میتونه ایدههایی بده که خودت بهشون فکر نکرده بودی (Claude Code Docs).
برای Cursor و Claude Code پرامپت جدا لازمه؟
نه، همین ۱۰ الگو همهجا کار میکنن. فرقشون فقط تو اینه که context رو چطور بدی؛ تو ادیتور با @ و تو ایجنت با اسم فایل یا پوشه. انتخاب بین این ابزارها رو تو درس ۳ بررسی کردیم.
جمله «تو یه برنامهنویس ارشدی» هنوز جواب میده؟
تا حدی. Anthropic میگه دادن نقش، رفتار و لحن مدل رو متمرکزتر میکنه (Anthropic). ولی تو کدنویسی، یه جمله نقش هیچوقت جای context واقعی رو نمیگیره. «تو یه برنامهنویس ارشدی» بدون اسم فایل و معیار تمام شدن، فقط یه پرامپت مبهم با کلاس بیشتره!
پرامپتهای خوبم رو کجا نگه دارم؟
اول یه فایل ساده تو پروژهت بساز و پرامپتهایی که خوب جواب دادن رو اونجا جمع کن. قدم بعدی اینه که قوانین ثابت پروژه رو تو فایلهایی مثل AGENTS.md بنویسی که ایجنت هر بار خودش بخونه (درس ۲۱)، و ورکفلوهای تکراری رو به Skill تبدیل کنی (درس ۲۳).
حرف آخر و قدم بعدی تو
پرامپتنویسی برای برنامهنویسی یعنی همون کاری که یه مهندس خوب با همتیمی تازهواردش میکنه: واضح بگه چی میخواد، context لازم رو بده، محدوده رو مشخص کنه و بگه کار کی تموم حساب میشه. هیچ جمله جادوییای وجود نداره؛ فقط وضوح، و یه کم تمرین.
این ۱۰ الگو رو یه جا ذخیره کن و این هفته حداقل سهتاشون رو تو کار واقعیت امتحان کن. بعد برو سراغ درس ۳ تا ببینی کدوم ابزار و مدل هوش مصنوعی برای کدنویسی به کار تو میاد.
اگه از Claude Code استفاده میکنی و میخوای این الگوها رو تو ورکفلو روزانهت حرفهایتر پیاده کنی، دوره آموزش Claude Code استارکوچ رو هم ببین.
یادت نره: مدل ذهنت رو نمیخونه، ولی هرچی بنویسی رو خیلی جدی میگیره. پس دقیق بنویس.
تمرین درس
مهمترین نکتهای که از درسنامهی «پرامپت نویسی» یاد گرفتید چه بود و آن را در چه کاری به کار میبرید؟