انتخاب ابزار هوش مصنوعی کدنویسی، مسئله‌ی نمره‌ی benchmark نیست. مسئله‌ی این است که حلقه‌ی تصمیم‌گیری — خواندن فایل، اجرای دستور، توقف — در دست کیست. اگر پاسخ را نمی‌دانید، وقت و هزینه‌تان بی‌دلیل می‌سوزد. این آموزش Claude و Claude Code همان مرز را ترسیم میکند: برای هر وظیفه، کدام ابزار، کدام مدل، کدام حالت اجرا.
Claude Code چه تفاوتی با Cursor و GitHub Copilot دارد؟#
Claude Code ایجنتمحور (Agentic Architecture) است؛ مدل خودش تصمیم می‌گیرد چه فایلی را بخواند، چه دستوری را اجرا کند و چه زمانی بایستد. Cursor و GitHub Copilot خودتکمیلی‌اند؛ برنامه‌نویس حلقه را در دست دارد و مدل فقط در خط فعلی پیشنهاد میدهد. همین یک تفاوت معماری، ابزار مناسب هر وظیفه را تعیین میکند.
معماری ایجنتمحور در برابر خودتکمیلی#
در معماری خودتکمیلی، مدل یک تابع ساده است: context فعلی را می‌گیرد، ادامه‌ی کد را پیش‌بینی میکند، و منتظر می‌ماند شما Tab بزنید یا رد کنید. هیچ تصمیمی درباره‌ی فایل بعدی، ابزار بعدی یا توقف نمی‌گیرد.
در معماری ایجنتمحور، مدل یک حلقه‌ی کامل را مدیریت میکند. ابتدا نقشه می‌کشد، سپس فایل می‌خواند، دستور اجرا میکند، نتیجه را تحلیل میکند و دوباره تصمیم می‌گیرد. این حلقه تا رسیدن به هدف یا توقف دستی ادامه دارد.
جدول مقایسه‌ی ابزارها از نظر مالک حلقه و scope تغییرات#
| ابزار | مالک حلقه | Scope تغییرات | نیاز به بازبینی انسانی |
|---|---|---|---|
| Claude Code | مدل | چندفایلی، اجرای shell، refactor | Plan Mode قبل از اجرا |
| Cursor | برنامه‌نویس | خط فعلی تا چند بلوک | هر پیشنهاد جداگانه |
| GitHub Copilot | برنامه‌نویس | خط فعلی | هر پیشنهاد جداگانه |
| Windsurf | ترکیبی | چندفایلی درون IDE | در محیط خود IDE |
چه زمانی Cursor بهتر است و چه زمانی Claude Code#
اگر در حال نوشتن کد جدید هستید و می‌خواهید کنترل لحظه‌ای روی هر خط داشته باشید، Cursor یا Copilot اصطکاک کمتری دارند. اما اگر وظیفه‌تان refactor یک ماژول چندفایلی، نوشتن migration، یا رفع باگ در کد موجود است، Claude Code چون خودش context را جمع‌آوری میکند، کار را سریع‌تر تمام میکند.
یک نکته که کمتر جایی گفته میشود: الگوی تکرارشونده در پروژههای اعضای کامیونیتی این است که هر دو را همزمان استفاده میکنند. Cursor برای نوشتن کد روزمره و Claude Code برای وظایف چندمرحلهای. این ترکیب، نه رقابت، بهترین نتیجه را میدهد.
نصب و اولین پروژه با Claude Code در 10 دقیقه#
Claude Code یک ابزار CLI (Command Line Interface) است که با npm نصب میشود و مستقیم در terminal یا به‌عنوان extension در VS Code اجرا می‌گردد. پیش‌نیاز اصلی، یک حساب Anthropic فعال و Node.js نسخه‌ی 18 یا بالاتر است.
پیش‌نیازهای فنی#
- Node.js نسخه‌ی 18 یا بالاتر (برای اجرای CLI)
- حساب Anthropic با دسترسی به API (اشتراک Pro یا API key)
- Git نصب‌شده روی سیستم (برای شناسایی repository)
- ترجیحاً یک پروژه‌ی کوچک با ساختار مشخص برای تست اولیه
گام‌های نصب CLI و اولین session#
- در terminal دستور نصب را اجرا کنید:
npm install -g @anthropic-ai/claude-code - وارد پوشه‌ی پروژه شوید و دستور
claudeرا بزنید - در اولین اجرا، احراز هویت با حساب Anthropic انجام میشود
- پس از ورود به session، اولین prompt را بنویسید — مثلاً: «این پروژه را توضیح بده و بگو از چه تکنولوژی‌هایی استفاده شده»
پیکربندی CLAUDE.md به‌عنوان حافظه‌ی پروژه#
فایل CLAUDE.md در ریشه‌ی پروژه قرار می‌گیرد و در هر session بهصورت خودکار خوانده میشود. این فایل نقش حافظه‌ی بلندمدت (Long-term Memory) ایجنت را بازی میکند. در آن بنویسید: ساختار پروژه، قوانین کدنویسی تیم، ابزارهای مجاز، و محدودیت‌هایی که ایجنت باید رعایت کند. هرچه این فایل دقیق‌تر باشد، رفتار ایجنت قابل‌پیش‌بینی‌تر است.
اتصال به VS Code از طریق extension#
اگر ترجیح می‌دهید در محیط IDE کار کنید، extension رسمی Claude Code در marketplace VS Code موجود است. پس از نصب، پنل Claude در کنار IDE باز میشود و session همان terminal است، اما با دسترسی به فایلهای باز و selection فعلی. تفاوت عملکردی با CLI ندارد؛ فقط UX متفاوت است.
کدام مدل Claude را برای کدنویسی انتخاب کنم؟#
Claude 3.5 Sonnet برای اکثر وظایف روزمره‌ی کدنویسی تعادل مناسبی بین سرعت و کیفیت دارد. Claude 4 Opus برای refactorهای پیچیده و تحلیلی ارزش هزینهی بیشتر را دارد، اما برای bugfixهای کوچک ضرورتی ندارد. انتخاب مدل باید بر اساس نوع وظیفه باشد، نه همیشه بالاترین مدل.
ماتریس تصمیم نوع وظیفه × مدل × حالت اجرا#
| نوع وظیفه | مدل پیشنهادی | حالت اجرا |
|---|---|---|
| Bugfix کوچک، تغییر 1-2 خط | 3.5 Sonnet | Auto-Accept |
| نوشتن ماژول جدید | 3.5 Sonnet | Plan Mode + Manual Review |
| Refactor چندفایلی | 4 Opus | Plan Mode + Manual Review |
| تحلیل الگوریتمی / معماری | 4 Opus | Plan Mode + بازبینی کامل |
| مهاجرت دیتابیس / Migration | 4 Opus | Plan Mode + Dry Run |
Claude 3.5 Sonnet در برابر Claude 4 Opus: هزینه و کیفیت#
Sonnet سریع‌تر است و هزینهی توکن پایین‌تری دارد. برای وظایفی که الگوی مشخصی دارند (CRUD، نوشتن تست، رفع باگ ساده) تفاوت خروجی محسوسی با Opus ندارد. Opus در وظایف تحلیلی عمیق — مثل تشخیص علت یک race condition در کد async یا طراحی معماری microservice — خروجی بهتری تولید میکند. اگر وظیفه‌تان «فقط کد بنویس» است، Sonnet کافی است. اگر «فکر کن و بعد بنویس» است، Opus را امتحان کنید.
اشتباه رایج: استفاده از Opus برای همه‌چیز#
این فرض که «بالاترین مدل = بهترین خروجی» پرهزینه‌ترین اشتباه رایج است. نتیجه‌اش: هزینهی توکن بالاتر بدون بهبود محسوس در کیفیت. الگوی بهینه این است: با Sonnet شروع کنید، اگر خروجی کافی نبود، همان prompt را با Opus تکرار کنید و مقایسه کنید. این cost-benefit analysis ساده، هزینهی ماهانه را به‌طور محسوس کاهش میدهد.
پرامپت‌نویسی برای Claude: الگوهای عملی که خروجی را نجات می‌دهند#
پرامپت‌نویسی مؤثر برای Claude به‌جای «فقط خوب بنویس»، روی سه محور استوار است: system prompt برای نقش‌دهی، Few-shot برای الگودهی، و Chain-of-Thought برای وظایف تحلیلی چندمرحلهای. هر محور، یک لایه از رفتار ایجنت را کنترل میکند.
ساختار system prompt و تأثیر آن بر رفتار ایجنت#
System prompt نقش، محدودیت‌ها و سبک خروجی را تعریف میکند. برای Claude Code، این نقش در CLAUDE.md نوشته میشود. یک system prompt مؤثر شامل سه بخش است: هویت («تو یک senior backend developer هستی»)، محدودیت («فقط از TypeScript strict mode استفاده کن»)، و خروجی («قبل از نوشتن کد، فرضیاتت را لیست کن»). هرچه این سه بخش شفاف‌تر باشند، خروجی قابل‌پیش‌بینی‌تر است.
Few-shot prompting با مثال واقعی از کد پروژه#
2 تا 3 مثال واقعی از کد پروژه‌تان — نه مثال‌های عمومی از اینترنت — بهترین الگودهی هستند. وقتی یک نمونه‌ی واقعی از نحوه‌ی نوشتن service layer، error handling یا naming convention پروژه را در prompt بگذارید، مدل همان سبک را کپی میکند. این کار، نیاز به توضیح متنی سبک کدنویسی را حذف میکند و خروجی را به کد موجود نزدیک میکند.
Chain-of-Thought برای دیباگ و تحلیل الگوریتمی#
برای وظایف تحلیلی، از مدل بخواهید مرحله‌به‌مرحله فکر کند. الگوی ساده: «قبل از نوشتن fix، علت باگ را تحلیل کن. سپس گزینههای رفع را لیست کن. در نهایت بهترین گزینه را انتخاب و اجرا کن.» این ساختار، مدل را مجبور میکند استدلالش را بیرونی کند و خطاهای منطقی را زودتر آشکار میکند.
نقش Plan Mode: اول نقشه، بعد اجرا#
Plan Mode مهم‌ترین feature ایمنی Claude Code است. در این حالت، مدل ابتدا یک نقشه‌ی تغییرات تولید میکند — چه فایل‌هایی تغییر میکنند، چه دستورهایی اجرا میشوند، چه ریسک‌هایی وجود دارد — و منتظر تأیید شما می‌ماند. بدون Plan Mode، تغییرات مخرب بدون بازبینی اعمال میشوند. برای هر وظیفه‌ای که بیش از یک فایل را لمس میکند، Plan Mode را فعال نگه دارید.
Model Context Protocol چیست و چطور Claude را به ابزارهایم وصل کنم؟#
Model Context Protocol (MCP) پروتکل استانداردی است که Anthropic در نوامبر 2024 معرفی کرد و به Claude اجازه میدهد از طریق یک رابط واحد به دیتابیس، فایل‌سیستم، APIها و ابزارهای خارجی دسترسی پیدا کند. این پروتکل، جایگزین اتصال‌های سفارشی و شکننده‌ی قبلی شده است.
معماری MCP: server، client و tool definition#
معماری MCP سه جزء دارد: MCP Server که ابزارها را expose میکند، MCP Client که درخواست‌ها را ارسال میکند (Claude Code یا Claude API)، و Tool Definition که schema ورودی/خروجی هر ابزار را تعریف میکند. ارتباط بین client و server از طریق JSON-RPC انجام میشود. هر server میتواند چندین tool داشته باشد و هر tool یک ورودی و خروجی مشخص دارد.
ساخت یک MCP server واقعی#
برای شروع، یک MCP server ساده بنویسید که به یک SQLite database وصل شود. مراحل: نصب SDK رسمی MCP، تعریف tool با نام و schema ورودی، پیاده‌سازی handler که query را اجرا میکند، و اجرای server در حالت stdio یا SSE. پس از راه‌اندازی، این server را در تنظیمات Claude Code اضافه کنید تا مدل بتواند مستقیم کوئری بزند.
اتصال MCP به Claude Code برای دسترسی به دیتابیس و CI/CD#
در فایل پیکربندی Claude Code، آدرس MCP serverها را تعریف میکنید. پس از اتصال، مدل میتواند در حین session ابزارهای آن server را صدا بزند. برای CI/CD، یک MCP server بنویسید که به API سرویس CI شما وصل شود و toolهایی مثل «اجرای pipeline»، «خواندن لاگ build» و «cancel کردن job» را expose کند.
ساخت ایجنت چندمرحلهای با Claude API#
ایجنت چندمرحلهای با Claude API بر پایه‌ی الگوی ReAct (Reasoning + Acting) ساخته میشود: مدل بین هر ابزار، استدلال میکند، ابزار را صدا می‌زند، نتیجه را می‌خواند و دوباره تصمیم می‌گیرد. حلقه تا رسیدن به هدف یا فراخوانی شرط توقف ادامه دارد.
الگوی ReAct: حلقه‌ی استدلال و عمل#
در هر iteration از حلقه، سه مرحله اتفاق می‌افتد: Reason (مدل فکر میکند چه باید بکند)، Act (یک tool call اجرا میکند)، Observe (نتیجه را می‌خواند و در context قرار میدهد). این سه مرحله در response مدل بهصورت structured output برمی‌گردند و شما آن‌ها را parse و اجرا میکنید.
Tool Use / Function Calling در Claude API#
در Claude API، ابزارها را در فیلد tools تعریف میکنید. هر tool شامل نام، توضیح، و JSON Schema ورودی است. وقتی مدل تصمیم می‌گیرد ابزاری را صدا بزند، در response یک content block از نوع tool_use برمی‌گرداند. شما آن را اجرا میکنید و نتیجه را به‌عنوان tool_result در پیام بعدی برمی‌گردانید.
مدیریت حلقه و شرایط توقف#
حلقه‌ی ایجنت باید شرایط توقف مشخصی داشته باشد: حداکثر تعداد iterations، تشخیص رسیدن به هدف (مدل خودش می‌گوید «تمام شد»)، و timeout. بدون این شرایط، حلقه میتواند بی‌پایان بچرخد و هزینهی توکن را به‌طور فاجعه‌بار بالا ببرد. الگوی عملی: یک counter نگه دارید و پس از N iteration، حلقه را اجباراً متوقف کنید و خروجی فعلی را به کاربر نشان دهید.
Prompt Caching برای کاهش هزینه در sessionهای طولانی#
در sessionهای چندمرحلهای، بخش‌های ثابت prompt (system prompt، tool definitions، فایلهای context) در هر iteration دوباره ارسال میشوند. Prompt Caching این بخش‌ها را در سمت سرور کش میکند و هزینهی توکن آن‌ها را به‌طور محسوس کاهش میدهد. هرچه تعداد iterationها بیشتر باشد، سود Prompt Caching محسوس‌تر میشود.
مدیریت Context Window و بهینه‌سازی هزینه در پروژههای واقعی#
Context Window در پروژههای واقعی به‌سرعت پر میشود. اگر فایلهای زیادی به context اضافه کنید، کیفیت خروجی به‌طور محسوس افت میکند و مدل شروع به «فراموش کردن» بخش‌های اولیه‌ی context میکند. راه‌حل: فیلتر هوشمند فایل‌ها، خلاصه‌سازی، و استفاده از CLAUDE.md.
سناریوی واقعی context overflow و نشانه‌های degraded output#
نشانه‌های degraded output در Claude Code: مدل شروع به تکرار میکند، دستورات shell را اشتباه اجرا میکند، فایل‌هایی که قبلاً خوانده را دوباره می‌خواند، یا به‌طور ناگهانی از سبک کدنویسی تعریف‌شده در CLAUDE.md منحرف میشود. هرکدام از این‌ها یعنی context پر شده و مدل دیگر به همه‌چیز دسترسی مؤثر ندارد.
استراتژی‌های مدیریت context#
- File Filtering: در CLAUDE.md مشخص کنید کدام فایل‌ها در context قرار بگیرند. فایلهای node_modules، dist، build و test fixtures را exclude کنید.
- Summarization: برای فایلهای طولانی، خلاصه‌ی ساختاری (نه محتوایی) در context بگذارید و مدل را راهنمایی کنید که جزئیات را مستقیم بخواند.
- Chunking: وظایف بزرگ را به subtasks تقسیم کنید. هر subtask context جداگانه‌ای می‌گیرد و نتیجه‌ی آن به‌عنوان ورودی subtask بعدی استفاده میشود.
محاسبه‌ی هزینهی توکن و نقش Prompt Caching#
هزینهی هر session تقریباً برابر است با تعداد توکن‌های ورودی (شامل context) + تعداد توکن‌های خروجی. در ایجنت‌های چندمرحلهای، ورودی در هر iteration بزرگتر میشود چون نتیجه‌ی tool call قبلی به context اضافه میشود. Prompt Caching بخش‌های تکراری ورودی را کش میکند و هزینهی آن‌ها را کاهش میدهد. هرچه تعداد iterationها بیشتر باشد، تفاوت هزینهی محسوس‌تر میشود.
Claude Projects برای کانتکست بلندمدت تیمی#
Claude Projects محیطی است برای سازماندهی کانتکست بلندمدت، فایلهای مرجع و دستورالعملهای تیم. در مقابل استفادهی مستقیم از API که هر request مستقل است، Projects کانتکست را بین sessionها حفظ میکند و برای کار تیمی مناسبتر است. اگر تیم شما از Claude Code استفاده میکند، یک Project مشترک بسازید و CLAUDE.md تیمی را در آن نگه دارید.
اشتباهات رایج در استفاده از Claude Code و مرزهای آن#
اشتباهات رایج در استفاده از Claude Code چهار دسته‌اند: over-prompting (پرامپت‌های طولانی بدون ساختار)، نادیده‌گرفتن Plan Mode، افزودن بی‌رویه‌ی فایل به context، و استفاده از Claude Code برای کارهایی که determinism می‌خواهند. هرکدام از این اشتباهات، هزینهی زمانی و مالی مشخصی دارد.
Over-prompting: پرامپت‌های طولانی بدون ساختار#
وقتی یک پرامپت 500 کلمه‌ای بدون ساختار می‌نویسید، مدل در تشخیص اولویت‌ها گیج میشود. الگوی بهینه: پرامپت کوتاه + CLAUDE.md برای قوانین ثابت + Few-shot برای سبک. هرچه پرامپت کوتاه‌تر و ساختارمندتر باشد، خروجی قابل‌پیش‌بینی‌تر است. این یک مشاهده‌ی تکرارشونده در پروژههای واقعی است.
بدون Plan Mode: تغییرات مخرب بدون بازبینی#
اگر Plan Mode را غیرفعال کنید، Claude Code مستقیم فایل‌ها را تغییر میدهد و دستورات shell را اجرا میکند. برای وظایف ساده که scope مشخصی دارند، این قابل‌قبول است. اما برای refactorهای چندفایلی یا تغییر schema دیتابیس، بدون Plan Mode ریسک از دست دادن کار چند ساعته وجود دارد. الگوی ایمن: Plan Mode برای همه‌چیز به‌جز تغییرات یک‌خطی.
مرز determinism: چه زمانی باید به script سنتی برگشت#
Claude Code برای کارهایی که خروجی byte-for-byte identical می‌خواهند مناسب نیست. اگر نیاز دارید یک script دقیقاً همان خروجی قبلی را تولید کند — مثلاً code generation با template مشخص، یا migration با ترتیب دقیق — باید به script سنتی برگردید. ایجنت‌های زبانی ذاتاً probabilisticاند و determinism ندارند.
پروژه‌هایی که Claude Code برای آن‌ها مناسب نیست#
- پروژه‌هایی با معماری microservice بسیار بزرگ که context هر سرویس مستقل است و ایجنت باید همزمان چند سرویس را بفهمد
- کارهایی که نیاز به debug با breakpoint و step-by-step execution دارند
- پروژه‌هایی که خروجی باید دقیقاً مطابق spec ثابت باشد (مثل codegen برای protobuf)
- تولید کد با نیاز به اجرای مستقیم test suite در هر iteration (هنوز integration کامل نیست)
نتیجه‌ی عملی: Claude Code ابزار قدرتمندی است، اما جایگزین تفکر مهندسی نیست. حلقه‌ی ایجنت را وقتی به او بسپارید که وظیفه scope مشخص و قابل‌بازبینی دارد. برای کارهای تحلیلی عمیق، Opus + Plan Mode. برای کارهای روزمره، Sonnet + Auto-Accept. و همیشه CLAUDE.md را به‌عنوان سند onboarding تیم نگه دارید، نه یادداشت شخصی.
اگر می‌خواهید این الگوها را در یک مسیر ساختارمند تمرین کنید و از صفر تا ساخت ایجنت واقعی برسید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین مسیر را پوشش میدهد — بدون کدنویسی، با Vibe Coding و ایجنت‌ها.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.