4 پرامپت Claude برای افزایش سرعت و دقت

4 پرامپت Claude برای افزایش سرعت و دقت

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

چرا Claude دیر کار می‌کنه: مشکل پردازش ترتیبی

وقتی فقط یک جلسه Claude رو باز می‌کنی و کار رو سریالی انجام می‌دی، مثل این می‌مونه که روی جاده یک‌خطه رانندگی کنی. هر بار یه کار می‌فرستی، منتظر می‌مونی نتیجه بیاد، بعد کار بعدی رو شروع می‌کنی. همین‌جا اتفاق می‌افته: زمان زیادی رو فقط به انتظار می‌گذرونی.

Boris Cherney، خالق Claude Code، روی یه استراتژی تأکید داره: چند جلسه Claude به‌صورت موازی. یعنی همزمان چند کار مختلف رو به چند Claude جداگانه بسپاری. هرکدوم context window خودش، دستور خودش و مجوز خودش رو داره. نتیجه؟ پنج‌تا کار می‌تونن همزمان انجام بشن، درست مثل یه جاده پنج‌خطه.

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

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

پرامپت قدرتمند اول: راه‌اندازی زیرعاملین

اولین پرامپت کلیدی برای کار سریعتر با Claude خیلی ساده‌ست: «Launch sub agents». یعنی به Claude بگو چند زیرعامل راه‌اندازی کنه. هر زیرعامل یه جلسه جداگانه هست که می‌تونه یه کار مشخص رو مستقل از بقیه انجام بده.

چرا این مهم‌ه؟ چون وقتی زیرعاملین رو خودت مشخص می‌کنی، Claude مجبور می‌شه کار رو بین اون‌ها تقسیم کنه. بدون این دستور، احتمال زیاد همه‌چی رو توی یک context انجام می‌ده و زمان زیادی برای انتظار می‌ذاری.

سه سناریوی واقعی برای استفاده از زیرعاملین

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

«Launch three sub agents to analyze this social media post: one for content quality, one for audience reaction, one for brand consistency.»

هر زیرعامل بی‌تأثیر از بقیه تحلیل می‌کنه. نتیجه‌ها واقعاً متنوع و قابل مقایسه می‌شن.

سناریوی دوم: کارهایی که قبلاً انجامشون نمی‌دادی. یه مثال عملی: تو بیش از ۱۰ هزار دامنه رو برای پروژه‌ت چک کردی؟ احتمالاً نه، چون زمان‌بر بود. اما اگر بگی ده زیرعامل راه‌اندازی کنن و هرکدوم دسته‌ای از دامنه‌ها رو چک کنن، کاری که چند ساعت طول می‌کشید می‌تونه توی چند دقیقه انجام بشه.

این یعنی کارهایی که قبلاً به دلیل زمان‌بری ازشون می‌گذشتی، حالا عملی می‌شن.

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

«Launch five sub agents to handle this task.»

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

نکته حیاتی: وضوح دستور

هر چقدر زیرعامل بیشتری راه‌اندازی کنی، اگر دستور شفاف نباشه، خروجی مفید نمی‌گیری. پس قبل از این‌که بگی «Launch sub agents»، باید دقیقاً مشخص کنی هر زیرعامل چه کاری باید انجام بده.

این نکته رو به پرامپت دوم وصل می‌کنه.

پرامپت قدرتمند دوم: نوشتن Implementation Spec

دومین پرامپت کلیدی: «Write me an implementation spec». منظور از Spec یا Specification برنامه، یه سند دقیق هست که روش اجرای پروژه رو مرحله‌به‌مرحله توضیح می‌ده.

Boris Cherney، خالق Claude Code، به‌صراحت گفته قبل از شروع ساخت، باید یه Spec درست کنی. بدون این، Claude مجبور می‌شه حدس بزنه. و حدس زدن توی برنامه‌نویسی یا کار پیچیده یعنی خروجی اشتباه.

چرا Plan Mode کافی نیست

شاید فکر کنی خب Claude که Plan Mode داره. چرا باید جداگانه Spec بنویسم؟ واقعیت این‌جاست: Plan Mode یه نقطه شروع خوب هست، اما خودش جایگزین Spec نمی‌شه.

Andrej Karpathy، رئیس سابق هوش مصنوعی تسلا، می‌گه: «من حتی Plan Mode رو دوست ندارم. چیزی که لازمه این‌جاست که تو با کلود کار کنی و یه Spec خیلی دقیق بسازی، تقریباً مثل یه مستند. بعد از اون بهش بگی بساز.»

ریاضیات پشت Specification

فرض کن یه پروژه سه مرحله‌ای داری. توی هر مرحله پنج روش ممکن برای اجرا هست. اگر Spec نداشته باشی، تعداد حالت‌های احتمالی می‌شه ۵ × ۵ × ۵ = ۱۲۵. یعنی ۱۲۵ راه مختلف برای ساخت.

حالا اگر قبل از این‌که Claude کاری انجام بده، بهش بگی: «Write me an implementation spec to build a daily overview automation.»

Claude یه سند می‌سازه که دقیقاً توضیح می‌ده چه مرحله‌ای با چه روشی انجام می‌شه. حالا به‌جای ۱۲۵ حالت، فقط یه راه مشخص داری: ۱ × ۱ × ۱ = ۱.

این یعنی احتمال این‌که کلود اولین‌بار درست کار کنه، خیلی بالاتر می‌شه.

نمونه‌ای عملی از Spec

اگر می‌خوای یه Spec حرفه‌ای بگیری، می‌تونی این دستور رو بدی:

«Write me an implementation spec for [describe your project]. For each step, show me the key decisions you’d make and why. Include error handling, dependencies, and validation points.»

بخش مهم این دستور این‌جاست: «For each step, show me the key decisions you’d make.» این جمله باعث می‌شه Claude نه فقط مراحل، بلکه دلایل و نقاط تصمیم‌گیری رو هم بنویسه. حالا قبل از این‌که کد بزنه یا چیزی بسازه، می‌تونی بگی این تصمیم درسته، اون رو عوض کن.

چطور بفهمی Spec خوب نوشته شده؟

یه Spec خوب باید این‌ها رو داشته باشه:

• لیست دقیق مراحل
• منطق هر تصمیم اصلی
• وابستگی‌ها و ابزارهای مورد نیاز
• نقاط تأیید و بررسی خروجی
• مدیریت خطاها

اگر این‌ها رو نداره، یه‌بار دیگه بگو Spec رو تکمیل کنه.

پرامپت قدرتمند سوم: Interview Me برای تصریح نیازمندی‌ها

سومین پرامپت کلیدی: «Interview me». این یعنی بگو به کلود: تو سؤال بپرس، من جواب می‌دم.

اصلاً چرا این لازمه؟ چون خیلی وقت‌ها تو نمی‌دونی دقیقاً چه سؤالی باید از خودت بپرسی. می‌دونی چی می‌خوای بسازی، اما جزئیاتی که تفاوت بین یه خروجی خوب و بد رو مشخص می‌کنن، روشن نیست.

وقتی به کلود بگی «Interview me»، Claude به‌جای این‌که تو بهش context بدی، خودش از تو سؤال می‌پرسه. و این سؤالات معمولاً همون‌هایی هستن که تو یادت نمی‌افتاد باید مشخص کنی.

چرا خروجی Claude بعضی وقت‌ها ضعیفه؟

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

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

مثال عملی از Interview Me

می‌تونی این دستور رو بدی:

«Interview me to build a clear spec for [your project]. Work with me to identify the core problem we’re solving, who it is and isn’t for, and what success looks like.»

بخش حیاتی این دستور: «Core problem we’re solving, who it is and isn’t for.»

این دقیقاً همون چیزی‌ست که Anthropic، سازنده Claude، توی رشد سریعش ازش استفاده کرده. اون‌ها روشن کردن که محصولشون برای چه کسانی هست و چه کسانی نه. تو هم باید همین رو برای پروژه‌ات مشخص کنی.

نکته‌ای درباره پاسخ‌های بهتر

بعضی وقت‌ها خروجی Claude رو بهتر می‌کنه اگر قبل از این‌که شروع کنه، از تکنیک‌هایی مثل Hex یا WhisperFlow استفاده کنی. این‌ها راه‌هایی هستن که بهت کمک می‌کنن افکارت رو سازمان‌دهی‌تر بیان بیرون. اما اصل ماجرا این‌جاست: بذار Claude سؤال بپرسه، تو جواب بده. بعد از چند دور، مشکل و نیازمندی‌ها کاملاً روشن می‌شن.

پرامپت قدرتمند چهارم: تأیید قبل از ساخت

چهارمین پرامپت کلیدی: «Confirm before you build» یا «Validate before executing». این یعنی بگو به کلود: قبل از این‌که کد رو اجرا کنی، فایل رو بسازی یا تغییری اعمال کنی، اول بهم نشون بده چی می‌خوای انجام بدی.

این پرامپت به یه مشکل اساسی می‌خوره: Hallucination. یعنی Claude گاهی ادعا می‌کنه کاری انجام داده یا چیزی ساخته که واقعیت نداره. اگر بذاری بدون تأیید اجرا کنه، ممکنه چیزی رو خراب کنه، فایل اشتباه رو بسازه، یا منطق اشتباه رو پیاده کنه.

سه لایه تأیید برای کار امن‌تر

لایه اول: Claude.md یکی از راه‌های خوب این‌ه که یه فایل به اسم Claude.md توی ریشه پروژه‌ت بذاری. توی این فایل مشخص می‌کنی Claude باید چطور کار کنه، چی رو تأیید کنه، چی رو خودش انجام بده. مثلاً می‌نویسی:

«Before running any command, show me what you’re about to do. Before creating or editing a file, ask for confirmation.»

این فایل مثل یه قانون اساسی برای کلود عمل می‌کنه.

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

لایه سوم: Human Validation Zones توی هر پروژه‌ای چند بخش حساس هست. مثلاً تنظیمات دیتابیس، فایل‌های پیکربندی، کدهای مالی، یا بخش‌هایی که مستقیماً به کاربر نهایی وصلن. این بخش‌ها رو از قبل مشخص کن و بگو:

«For these sections, always wait for my approval before making changes.»

مثال واقعی: استفاده از ابزار تأیید (Hostinger)

یکی از ابزارهایی که برای تأیید کار Claude می‌تونه استفاده بشه، MCP (Model Context Protocol) یا ابزارهای مشابه هست. مثلاً یه سرویس مثل Hostinger می‌تونه به کلود بگه قبل از deploy، فایل‌های تغییریافته رو لیست کن. بعد انسان نگاه می‌کنه، اگر درست بود تأیید می‌کنه.

این مدل کار باعث می‌شه سرعت حفظ بشه، اما کنترل از دست نره.

چطور مناطق خطرناک رو شناسایی کنی؟

یه راه ساده این‌ه که از خود Claude بخوای این مناطق رو شناسایی کنه:

«Identify the risky zones in this project where manual validation is critical.»

Claude معمولاً می‌تونه بگه کدوم فایل‌ها یا بخش‌ها اگر اشتباه اجرا بشن، مشکل جدی ایجاد می‌کنن.

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

حالا چهارتا پرامپت کلیدی رو دیدی: Launch sub agents، Write me an implementation spec، Interview me، Confirm before you build. اما این‌ها به‌تنهایی کافی نیستن اگر کیفیت دستورات اولیه پایین باشه.

وضوح و جزئیات در دستورات

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

جزئیات یعنی کاهش فضای حدس زدن. کاهش حدس یعنی خروجی دقیق‌تر از اولین بار.

تناسب بین سرعت و کیفیت

زیرعاملین سرعت رو بالا می‌برن، اما اگر دستور هرکدوم مبهم باشه، خروجی سریع اما بی‌کیفیت می‌گیری. پس قبل از این‌که بگی Launch sub agents، Spec رو آماده کن. قبل از این‌که Spec بدی، Interview Me رو اجرا کن. و قبل از این‌که هرچیزی اجرا بشه، لایه Confirm رو فعال کن.

این یعنی ترکیب چهار پرامپت به‌صورت یه سیستم.

رفتارهای غیر مؤثر که باید ازشون دوری کنی

چند تا اشتباه رایج:

• دادن دستور عمومی بدون context مشخص
• استفاده از Claude بدون مشخص کردن خروجی نهایی
• تکرار دستورات بدون این‌که مشکل اساسی رو شناسایی کنی
• پرش از پروژه‌ای به پروژه دیگه بدون ذخیره Spec یا context
• اعتماد کامل به خروجی بدون تست یا تأیید

اگر از این رفتارها دوری کنی، کار سریعتر با Claude تبدیل می‌شه به یه چرخه پایدار که توش زمان کم می‌شه، کیفیت بالا می‌ره، و نیاز به تکرار کاهش پیدا می‌کنه.

چک‌لیست عملی قبل از شروع کار با Claude

قبل از این‌که پروژه‌ای با Claude شروع کنی، این‌ها رو چک کن:

1. آیا مشکل اصلی رو مشخص کردی؟
2. آیا می‌دونی این پروژه برای چه کسانی هست؟
3. آیا یه Spec دقیق آماده کردی یا آماده می‌کنی؟
4. آیا Claude رو مجبور کردی زیرعامل بسازه؟
5. آیا لایه تأیید فعال هست؟

اگر جواب همه‌ش بله بود، کارت از اون ۹۹ درصدی که بدون برنامه شروع می‌کنن سریع‌تر و مطمئن‌تر انجام می‌شه.

وقتی فعال‌سازی مطمئن از خود امکانات مهم‌تر می‌شود

این چهار پرامپت زمانی واقعاً به کارت میان که بتونی پروژه‌هات رو بدون محدودیت‌های دسترسی و قطع‌شدن روند کار جلو ببری. وقتی Specها، گفت‌وگوها و context پروژه‌ت داخل یک حساب ثابت باقی بمونن، لازم نیست هر بار همه‌چیز رو از اول برای Claude توضیح بدی و می‌تونی همون چرخه مصاحبه، برنامه‌ریزی، اجرای موازی و تأیید نهایی رو منظم‌تر ادامه بدی.

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

منابع

• Anthropic Claude Documentation
• OpenAI GPT-5 Overview
• Boris Cherney on Claude Code Best Practices
• مقاله جنگ اشتراکهای هوش مصنوعی در 2026 — کادینر
• راهنمای تیر 1405 قابلیت‌های Midjourney — کادینر

---