Claude Code یک ایجنت (Agent) خط‌فرمانی است که فایل‌سیستم پروژه‌ات را می‌خواند، کد را ویرایش می‌کند و دستورات shell اجرا می‌کند. اکثر کاربران، آن را مثل یک چت‌بات ساده به‌کار می‌گیرند: پرامپت می‌فرستند، خروجی را کپی می‌کنند، و وقتی نتیجه بد است، پرامپت را عوض می‌کنند. این الگو، کل ارزش معماری ابزار را بی‌اثر می‌کند. مهارت اصلی در کار با Claude Code، context engineering (مهندسی زمینه) و انضباط نشست (Session Discipline) است، نه نوشتن پرامپت‌های بهتر.

آموزش Claude Code: چرا آن را مثل چت استفاده نکنید#

Claude Code یک ابزار CLI (Command Line Interface) است که دسترسی کامل به فایل‌سیستم و shell دارد و خودش کد را ویرایش می‌کند. این تفاوت معماری، workflow (جریان کار) کاملاً متفاوتی می‌سازد؛ استفاده‌ی چت‌گونه از آن، نه‌تنها بی‌فایده بلکه مخرب است، چون مدل را از همان مسیری که برای آن طراحی شده بیرون می‌کشی.

معماری CLI در برابر مرورگر: چه چیزی واقعاً فرق می‌کند#

وقتی با Claude در مرورگر کار می‌کنی، فقط متن می‌فرستی و متن برمی‌گردانی. Claude Code در terminal اجرا می‌شود و مستقیماً فایل‌ها را باز می‌کند، ویرایش می‌کند و دستور build یا test را اجرا می‌کند. مدل خودش تصمیم می‌گیرد کدام فایل را بخواند و کدام را تغییر بدهد.

در مرورگر، تو context را دستی مدیریت می‌کنی. در Claude Code، مدل خودش context را جمع می‌کند — و اگر context بدی بهش بدهی، خروجی بد می‌گیری. این تنها تفاوت نیست؛ تفاوت اصلی در مسئولیت است. در چت، تو مسئول انتخاب فایل‌های مرتبطی. در Claude Code، این مسئولیت به مدل سپرده شده و تو فقط باید محیط را درست بچینی.

الگوی «prompt → observe → correct → re-prompt» به‌جای «پرامپت کامل بنویس»#

در چت معمولی، سعی می‌کنی یک پرامپت کامل و دقیق بنویسی تا خروجی درست باشد. در Claude Code این الگو جواب نمی‌دهد. workflow واقعی این است: یک task کوتاه بده، خروجی را ببین، اصلاح بده، دوباره بده. مدل در هر iter (تکرار) فایل‌ها را دوباره می‌خواند و context تازه می‌گیرد.

این الگو یعنی به‌جای مهندسی پرامپت، باید مهندسی context و مهندسی session بلد باشی. و این جایی است که اکثر کاربران تازه‌کار، هفته‌ها وقتشان را صرف یادگیری تکنیک‌های پرامپت‌نویسی می‌کنند که در Claude Code تقریباً بی‌اثرند.

تفاوت Claude Code با Anthropic API و MCP#

Anthropic API یک endpoint خام است که خودت باید همه‌چیز را بسازی. Claude Code یک ابزار آماده با دسترسی فایل‌سیستم و shell است. MCP لایه‌ی واسطی است که ابزارهای خارجی را به Claude Code وصل می‌کند — مثل دیتابیس، مرورگر یا APIهای سوم. این سه، مکمل یکدیگرند نه رقیب: API برای ساخت محصول، Claude Code برای کار روزانه روی کد، MCP برای اتصال هر دو به دنیای بیرون.

context engineering: الگویی که نتایج را عوض می‌کند#

context engineering یعنی مدیریت آنچه مدل در هر لحظه می‌بیند — از فایل CLAUDE.md در ریشه‌ی پروژه تا مرزهای session — و این مهم‌تر از هر تکنیک پرامپت‌نویسی است. اگر context را درست نچینی، بهترین پرامپت دنیا هم خروجی قابل‌قبول نمی‌سازد.

ساختار CLAUDE.md: system prompt سطح‌پوشه که Claude Code در هر session می‌خواند#

فایل CLAUDE.md در ریشه‌ی پروژه قرار می‌گیرد و Claude Code در ابتدای هر session آن را به‌عنوان context پایه می‌خواند. این فایل مثل یک system prompt عمل می‌کند اما در repo commit می‌شود و همه‌ی اعضای تیم یک context یکسان دارند.

محتوای مؤثر CLAUDE.md شامل ساختار پروژه، قوانین کدنویسی، نام‌های متغیر و تابع مورد استفاده، و محدودیت‌های فنی است. نه داستان بنویس، نه توضیح آموزشی بده. فقط حقایقی که مدل بدون آن‌ها تصمیم غلط می‌گیرد.

یک اشتباه پرهزینه که در کلاس‌ها مکرر دیده می‌شود: نوشتن CLAUDE.md به‌عنوان مستندات پروژه. این فایل، راهنمای تصمیم‌گیری مدل است نه راهنمای توسعه‌دهنده‌ی جدید. اگر یک خط را می‌توانی از CLAUDE.md حذف کنی و خروجی مدل عوض نمی‌شود، آن خط زائد است.

نقطه‌ی بحرانی session: چه زمانی باید fresh session باز کنید#

هر session یک context window دارد. وقتی session طولانی می‌شود، مدل در انباشت context قبلی گم می‌شود و پاسخ‌هایش ناسازگار می‌شود. نشانه‌های رسیدن به نقطه‌ی بحرانی: مدل فایل‌هایی را ویرایش می‌کند که قبلاً دست نزده، قوانین CLAUDE.md را نادیده می‌گیرد، و همان باگ را دوباره معرفی می‌کند.

قاعده‌ی عملی: بعد از هر task مستقل، session جدید باز کن. اگر task ادامه‌دار است، هر چند iter یک‌بار session را fresh کن و در CLAUDE.md خلاصه‌ی وضعیت بنویس.

few-shot و chain-of-thought (CoT) در context engineering عملی#

few-shot prompting (نمونه‌دهی کم) در CLAUDE.md مؤثرتر از داخل پرامپت است. دو یا سه نمونه از کد مورد نظرت را در فایل بگذار؛ مدل در هر session آن‌ها را می‌بیند. chain-of-thought (زنجیره‌ی تفکر) در Claude Code به‌صورت خودکار فعال است؛ لازم نیست «قدم‌به‌قدم فکر کن» بنویسی. نوشتن چنین دستوراتی در واقع کیفیت خروجی را پایین می‌آورد، چون مدل را به الگویی مجبور می‌کند که خودش طبیعی‌تر اجرا می‌کند.

نصب Claude Code و اولین session موفق#

برای نصب Claude Code به Node.js نسخه‌ی LTS، یک اشتراک فعال Claude Pro یا Max و یک پروژه‌ی git کافی است؛ فرایند نصب چند دقیقه طول می‌کشد. پیچیدگی واقعی بعد از نصب شروع می‌شود: اولین task را درست انتخاب کردن.

پیش‌نیازهای فنی و نرم‌افزاری#

  • Node.js نسخه‌ی LTS (Long Term Support)
  • اشتراک فعال Claude Pro یا Claude Max
  • یک پروژه‌ی git با ساختار مشخص
  • آشنایی پایه با terminal و دستورات shell

گام‌به‌گام نصب و اولین session#

  1. Node.js را از سایت رسمی نصب کن و نسخه را با node --version بررسی کن.
  2. پکیج Claude Code را با npm install -g @anthropic-ai/claude-code نصب کن.
  3. در terminal با claude وارد ابزار شو و با /login احراز هویت انجام بده.
  4. به پوشه‌ی پروژه‌ات برو و claude را اجرا کن.
  5. اولین task را بده: «ساختار پروژه را توضیح بده» و خروجی را بررسی کن.
  6. فایل CLAUDE.md در ریشه‌ی پروژه بساز و قوانین پایه را بنویس.

اولین CLAUDE.md را بنویسید: الگوی عملی برای شروع#

نمونه‌ی حداقلی CLAUDE.md برای شروع:

## ساختار پروژه src/ → کد اصلی، tests/ → تست‌ها، docs/ → مستندات ## قوانین کدنویسی - TypeScript strict mode - نام‌گذاری camelCase برای متغیر، PascalCase برای کلاس - هر فایل زیر 200 خط ## محدودیت‌ها - از any استفاده نکن - dependency جدید بدون تأیید اضافه نکن

این فایل کوتاه، مدل را از نوشتن کد نامنظم و اضافه‌کردن dependencyهای بی‌مورد بازمی‌دارد. نکته‌ای که بقیه نمی‌گویند: اولین CLAUDE.md را با ۴ تا ۵ خط شروع کن، نه ۲۰ خط. بقیه را بعد از دیدن اولین خروجی‌های نادرست اضافه کن.

Claude Code در برابر Cursor و GitHub Copilot: کدام برای چه کاری؟#

Cursor برای کار تعاملی در IDE با پیشنهاد کد مناسب است؛ Claude Code برای ویرایش مستقیم فایل‌ها، refactoring گسترده و workflow ایجنتی طراحی شده؛ Copilot برای تکمیل خطی. انتخاب بین این سه، انتخاب از بین ابزارهای هم‌پوشان نیست؛ انتخاب از بین سه معماری متفاوت است.

جدول مقایسه‌ی workflow، دسترسی، و نوع خروجی#

معیارClaude CodeCursorGitHub Copilot
نوع اجراCLI در terminalIDE مستقلافزونه در VS Code
دسترسی فایل‌سیستمکامل (خواندن و نوشتن)محدود به فایل بازفقط متن انتخاب‌شده
اجرای دستورات shellبلهبله (در terminal داخلی)خیر
مدیریت contextCLAUDE.md + sessionفایل‌های باز + .cursorrulesخودکار (محدود)
مناسب برایrefactoring گسترده، task چندفایلیویرایش تعاملی، یادگیری حین کارتکمیل خطی، boilerplate

چه زمانی ترکیب Cursor + Claude Code بهتر از هرکدام به‌تنهایی است#

در پروژه‌های واقعی، ترکیب این دو مؤثر است: Claude Code برای ویرایش‌های گسترده و taskهای چندفایلی، Cursor برای ویرایش‌های ریز و تعاملی در IDE. بین این دو، CLAUDE.md و .cursorrules را هم‌زمان نگه‌دار تا context یکسان باشد.

ترکیب این دو، جایی که واقعاً جواب می‌دهد: Claude Code یک module را بازنویسی می‌کند، بعد در Cursor فایل‌های تغییر‌یافته را باز می‌کنی و ریزه‌کاری‌های UI را دستی تنظیم می‌کنی. این تقسیم کار، سرعت را نسبت به استفاده از هر ابزار به‌تنهایی چند برابر می‌کند.

نقش Aider و جایگاهش در طیف ابزارهای AI pair programmer#

Aider یک ابزار CLI دیگر است که روی diff و commit تمرکز دارد. برخلاف Claude Code که به‌صورت ایجنتی چند فایل را هم‌زمان مدیریت می‌کند، Aider معمولاً یک فایل مشخص را ویرایش و commit می‌کند. برای پروژه‌هایی که می‌خواهی هر تغییر مستقیماً در git history ثبت شود، Aider گزینه‌ی مناسب‌تری است. اما این تمرکز بر commitهای granular، در taskهای چندفایلی کندتر از workflow ایجنتی Claude Code عمل می‌کند.

ساخت ایجنت با Claude Code و MCP server#

ایجنت هوش مصنوعی در Claude Code یعنی تعریف tool use و function calling با MCP serverها تا مدل خودش تصمیم بگیرد و اجرا کند؛ اما بدون guardrail (محدوده‌ی حفاظتی)، hallucination در loop خودکار خطرناک است. ایجنت‌سازی با Claude Code، نه یک قابلیت بلکه یک مسئولیت است.

ایجنت مرکزی با بازوهای نورانی متصل به نودهای سرور، نمایش معماری MCP در کار حرفه‌ای با کلود کد
هر نود در این شبکه، یک MCP server است که توانایی‌های جدیدی به ایجنت اضافه می‌کند

MCP server چیست و چطور به Claude Code متصل می‌شود#

MCP server یک سرویس محلی یا راه‌دور است که ابزارهای اضافی را به Claude Code وصل می‌کند. مثلاً یک MCP server دیتابیس به مدل اجازه می‌دهد query بزند، یا یک MCP server مرورگر به آن اجازه می‌دهد صفحه‌ای را بخواند. اتصال از طریق تنظیمات MCP در Claude Code انجام می‌شود.

الگوی verification step: جلوگیری از hallucination در autonomous loop#

در workflow ایجنتی، مدل خودش تصمیم می‌گیرد و اجرا می‌کند. بدون verification step (گام راستی‌آزمایی)، یک hallucination در iter اول به iterهای بعدی سرایت می‌کند. الگوی عملی: بعد از هر action خودکار، یک assertion (ادعای قابل‌بررسی) بنویس که باید درست باشد. اگر assertion fail شد، session را متوقف کن.

این الگو، همان چیزی است که در پروژه‌های اعضای کامیونیتی بارها تکرار شده: بدون verification، یک مدل با hallucination در فایل اول، سه فایل بعدی را هم خراب می‌کند و تو تا آخر session متوجه نمی‌شوی.

محدودیت‌های واقعی ایجنت‌سازی با Claude Code#

Claude Code برای ایجنت‌های تک‌sessionی و taskهای با طول مشخص مناسب است. برای ایجنت‌هایی که باید چندین ساعت کار کنند، state را حفظ کنند، یا با چند کاربر هم‌زمان سروکار داشته باشند، ابزارهای مثل N8N یا LangChain مناسب‌ترند. ایجنت‌سازی با Claude Code، اتوماسیون سطح task است نه سطح محصول.

اشتباهات رایج و زمان‌هایی که Claude Code جواب نمی‌دهد#

رایج‌ترین اشتباه، treat کردن Claude Code مثل چت و نگه‌داشتن session بیش‌ازحد طولانی است؛ در پروژه‌های monorepo با build system سفارشی یا debugging با breakpoint، ابزارهای دیگری مناسب‌ترند. شناخت مرزهای ابزار، به‌اندازه‌ی یادگیری قابلیت‌هایش حیاتی است.

پنج خطای تکرارشونده از پروژه‌های واقعی#

  1. CLAUDE.md را ننویسند و بعد از مدل انتظار کد منظم داشته باشند.
  2. session را ساعت‌ها باز نگه دارند تا context window پر شود.
  3. task بزرگ را یکجا بدهند به‌جای شکستن به subtask.
  4. خروجی را بدون بررسی commit کنند.
  5. فایل‌های غیرمرتبط (node_modules، build output) را در context رها کنند.

از این پنج، خطای چهارم پرهزینه‌ترین است. یک commit بدون بررسی، اگر باگ داشته باشد، در CI/CD زنجیره‌ای از شکست ایجاد می‌کند که ردیابی‌اش ساعت‌ها طول می‌کشد.

پروژه‌های با dependency graph پیچیده: چرا Claude Code اینجا شکست می‌خورد#

وقتی پروژه‌ای با چند صد فایل و dependency graph عمیق داری، مدل در خواندن همه‌ی فایل‌ها محدود است. Claude Code فایل‌ها را یکی‌یکی می‌خواند؛ اگر ترتیب خواندن اشتباه باشد، context ناقص می‌ماند و مدل فرضیات غلط می‌سازد. راه‌حل عملی: قبل از task، در CLAUDE.md نقشه‌ی dependency را به‌صورت متنی تعریف کن تا مدل بداند کدام فایل‌ها به هم وابسته‌اند.

موارد security-sensitive و دسترسی runtime: استثناهایی که بقیه نمی‌گویند#

در کدهای مرتبط با authentication، encryption یا payment، Claude Code ممکن است placeholder بگذارد به‌جای پیاده‌سازی واقعی. این رفتار برای کدهای production خطرناک است. در این موارد، از Claude Code فقط برای توضیح و review استفاده کن، نه برای نوشتن. و این یک استثنا نیست؛ یک قانون مطلق است.

خودکاسازی workflow: debugging، refactoring و code review#

Claude Code برای debugging کد legacy و refactoring moduleهای بزرگ مؤثر است، به‌شرطی که task را به sessionهای مجزا بشکنید و برای هرکدام context مستقل بدهید. بدون این انضباط، ابزار در پروژه‌های متوسط هم گیج می‌شود.

الگوی debugging با Claude Code: از stack trace تا fix#

stack trace (ردپای پشته) را در session جدید بده و بگو «این خطا را در پروژه پیدا کن و fix کن». مدل فایل‌های مرتبط را می‌خواند و patch پیشنهاد می‌دهد. اگر fix اول جواب نداد، session را fresh کن و فقط فایل مربوطه را در context بگذار.

نکته‌ی عملی که در گفتگوهای اعضا مدام برمی‌گردد: به‌جای paste کردن کل stack trace، فقط ۵ خط اول و آخرین خط را بده. بقیه، noise است و context را بیهوده پر می‌کند.

refactoring گسترده: شکستن task به sessionهای کوچک#

refactoring یک module با 2000 خط کد را در یک session انجام نده. الگوی عملی: هر فایل را در یک session جداگانه refactor کن، در CLAUDE.md بنویس که کدام فایل‌ها انجام شده، و بعد از هر فایل test را اجرا کن. این الگو خسته‌کننده به نظر می‌رسد، اما یک session طولانی که در میانش مدل گیج شود، ساعت‌ها کار را به عقب برمی‌گرداند.

code review خودکار: pipeline ساده با CLAUDE.md و tool use#

یک session code review (بازبینی کد) باز کن و بگو «فایل‌های modified را با git diff بگیر و review کن». در CLAUDE.md قوانین review را بنویس: نام‌گذاری، پیچیدگی، edge case. خروجی را به‌عنوان comment در PR بگذار. این کار، reviewهای روتین را حذف می‌کند و وقت تیم را برای تصمیمات معماری آزاد می‌کند.

هزینه‌ی واقعی Claude Code: نه قیمت API، بلکه session به task#

هزینه‌ی واقعی Claude Code را باید بر حسب تعداد session مورد نیاز برای یک task واقعی محاسبه کرد، نه توکن‌های خام API؛ یک refactoring با چند هزار خط کد ممکن است به چند session نیاز داشته باشد. این جایی است که اکثر مقایسه‌های هزینه‌ای، ابزار را اشتباه می‌سنجند.

مدل قیمت‌گذاری Claude Pro و Claude Max#

Claude Code با اشتراک Claude Pro یا Claude Max کار می‌کند. این اشتراک‌ها به‌صورت ماهانه هستند و محدودیت usage دارند. برای جزئیات دقیق قیمت و سطوح usage، به صفحه‌ی اشتراک‌های Anthropic مراجعه کن.

تخمین هزینه‌ی ماهانه: الگوی محاسبه‌ی session-based#

به‌جای محاسبه‌ی توکن، این الگو را استفاده کن: یک task متوسط = یک session. اگر روزانه 5 task داری، ماهانه حدود 100 session. اگر هر session 5 iter می‌برد، 500 iter ماهانه. این عدد را با limit اشتراکت مقایسه کن.

البته این الگو، خوش‌بینانه است؛ در پروژه‌های واقعی، یک task متوسط گاهی 2 تا 3 session مصرف می‌کند چون اولین خروجی قابل‌استفاده نیست. محاسبه‌ی واقع‌بینانه‌تر: task × 2.5.

بهینه‌سازی مصرف توکن در context window 200,000 تایی#

context window Claude 200,000 توکن است. برای پروژه‌های بزرگ، این فضا زود پر می‌شود. بهینه‌سازی: فایل‌های غیرمرتبط را exclude کن (در .gitignore یا با exclude در CLAUDE.md)، sessionهای کوتاه‌تر باز کن، و به‌جای خواندن کل فایل، فقط بخش مورد نظر را بخواه.

Claude Code را چطور یاد بگیرم؟#

بهترین راه یادگیری Claude Code، کار روی یک پروژه‌ی واقعی است نه تماشای ویدیو. یک repo کوچک انتخاب کن، CLAUDE.md بنویس، و هر روز یک task واقعی را با آن حل کن. بعد از دو هفته، الگوهای session management و context engineering برایت عادت می‌شود.

دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین مسیر را طی می‌کند — از نصب تا ایجنت‌سازی با MCP — و برای کسی که می‌خواهد بدون کدنویسی ایده‌اش را با Vibe Coding و ایجنت‌ها به محصول تبدیل کند طراحی شده است.