آموزش Claude برای کسی که فقط می‌خواهد سؤال بپرسد و پاسخ بگیرد، یک صفحه هم تمام می‌شود. اما اگر توسعه‌دهنده‌ای هستید که با کدبیس (codebase) چندفایلی کار می‌کنید، سه لایه‌ی مجزا را باید یاد بگیرید: پرامپت‌نویسی ساختارمند، کار با Claude Code به‌عنوان ابزار عامل‌محور در ترمینال، و اتصال به ابزارهای بیرونی با پروتکل MCP. این مقاله همان مسیر escalation را با مثال قبل/بعد و الگوهای ضدکارآمد (anti-pattern) پوشش می‌دهد — آن‌هایی که وقت و بودجه‌ی واقعی را می‌سوزانند.

Claude Code چیست و چطور در ۵ دقیقه نصبش کنیم؟#

Claude Code یک ابزار کدنویسی عامل‌محور (agentic coding) است که در ترمینال اجرا می‌شود، به کل کدبیس دسترسی دارد و ویرایش‌های چندفایلی انجام می‌دهد. نصبش با یک دستور npm و احراز هویت از طریق حساب Anthropic در کمتر از پنج دقیقه تمام می‌شود.

پیش‌نیازها: Node.js، حساب Anthropic و ترمینال سازگار#

سه چیز لازم دارید: Node.js نسخه‌ی ۱۸ به بالا، یک حساب Anthropic با اشتراک فعال یا API key، و یک ترمینال سازگار (bash، zsh یا PowerShell). دانش اولیه‌ی خط‌فرمان و Git کمک‌کننده است، ولی بدون آن هم می‌شود شروع کرد.

مراحل نصب گام‌به‌گام#

نصب Claude Code سه گام بیشتر ندارد:

  1. دستور npm install -g @anthropic-ai/claude-code را در ترمینال اجرا کنید.
  2. دستور claude را بزنید تا فرآیند احراز هویت شروع شود.
  3. به مرورگر منتقل می‌شوید، با حساب Anthropic لاگین می‌کنید و دسترسی را تأیید می‌کنید.

بعد از این سه گام، در هر پروژه‌ای که cd کنید و claude بزنید، ابزار به فایل‌های همان پوشه دسترسی پیدا می‌کند. همین.

اولین workflow: از cd project تا اولین multi-file edit#

فرض کنید یک پروژه‌ی React دارید و می‌خواهید یک component را به دو فایل تقسیم کنید. در Claude Code کافی است بنویسید: «component UserCard را از فایل اصلی جدا کن و در فایل جداگانه با export قرار بده، سپس import را در فایل والد اصلاح کن.» ابزار خودش فایل‌ها را می‌خواند، تغییرات را اعمال می‌کند و diff نشان می‌دهد.

این دقیقاً همان کاری است که IDEهای معمولی با autocomplete خطی هرگز از پسش برنمی‌آیند.

تفاوت ساختاری با IDE: context-aware reasoning در مقابل autocomplete خطی#

Copilot و Cursor در سطح خط یا تابع فکر می‌کنند. Claude Code در سطح کدبیس فکر می‌کند. یعنی قبل از ویرایش، ساختار پروژه را می‌خواند، وابستگی‌ها را درک می‌کند و سپس تصمیم می‌گیرد کدام فایل‌ها باید تغییر کنند.

این تفاوت سرعت نیست. تفاوت معماری تفکر است. کسی که این دو را با «سرعت» مقایسه کند، هنوز سطح اول را نفهمیده.

Claude Code در برابر Cursor و GitHub Copilot: مقایسه‌ی workflow واقعی#

Claude Code برای ویرایش چندفایلی عامل‌محور و استدلال آگاه از کدبیس ساخته شده، Cursor تجربه‌ی IDE-native با context window محدودتر می‌دهد، و Copilot برای autocomplete درون-editor بهینه است. انتخاب بین این سه به نوع task و اندازه‌ی پروژه بستگی دارد، نه به عدد بنچمارک.

جدول مقایسه‌ای: نوع تعامل، context، مدل‌ها و بهترین use case#

معیارClaude CodeCursorGitHub Copilot
نوع تعاملچت عامل‌محور در ترمینالچت + autocomplete در IDEautocomplete درون-editor
دسترسی به کدبیسکل پروژه، چندفایلیفایل‌های باز + indexedفایل جاری + tab‌های نزدیک
مدل پیش‌فرضClaude Sonnet / Opusچندمدل (GPT، Claude، Gemini)GPT-4o / Codex
بهترین use caserefactoring چندفایلی، debugging پیچیده، ساخت ایجنتویرایش روزمره در IDE، چت با context محدودتکمیل سریع خط، boilerplate
مدل هزینهاشتراک ماهانه یا API per-tokenاشتراک ماهانهاشتراک ماهانه

چه زمانی Claude Code انتخاب بهتری است#

وقتی task شما چندفایلی است — مثلاً باید یک API endpoint را تغییر دهید و هم‌زمان model، controller و test را update کنید — Claude Code با خواندن کل کدبیس و اعمال تغییرات هماهنگ، برتری واضحی دارد. debugging با race condition، ساخت ایجنت چندمرحله‌ای و migration دیتابیس از جمله مواردی هستند که ابزارهای autocomplete در آن‌ها عملاً بی‌فایند.

چه زمانی Cursor یا Copilot منطقی‌ترند#

اگر در حال نوشتن یک تابع ساده هستید و فقط یک خط کد کم دارید، Copilot در چند میلی‌ثانیه آن را پیشنهاد می‌دهد. Cursor وقتی بهتر است که در IDE نشسته‌اید و نمی‌خواهید context-switch کنید. برای پروژه‌های کوچک تک‌فایلی، Claude Code overhead بی‌مورد دارد.

الگوی تکرارشونده از پروژه‌های واقعی#

در پروژه‌های اعضای کامیونیتی، الگوی رایج این است: Copilot یا Cursor برای ویرایش روزمره، Claude Code برای taskهای پیچیده‌ی چندفایلی که هفته‌ای چند بار پیش می‌آید. این سه ابزار رقیب یکدیگر نیستند؛ لایه‌های مختلف یک workflow‌اند. کسی که فقط یکی را انتخاب کند، عملاً دو سوم ظرفیتش را قفل کرده.

پرامپت‌نویسی برای Claude: چرا ساختارمند و کوتاه بهتر از بلند است#

در Claude با تفکر گسترده (extended thinking) و مدیریت context، پرامپت ساختارمندِ کوتاه‌تر معمولاً نتیجه‌ی بهتری تولید می‌کند. الگوی «هرچه پرامپت بلندتر، بهتر» یک ضدالگو است که بودجه‌ی توکن (token budget) را بی‌دلیل مصرف می‌کند.

System Prompt و نقش آن در رفتار مدل#

System Prompt (پرامپت سیستمی) دستوری است که قبل از هر interaction به مدل داده می‌شود و لحن، محدودیت‌ها و نقش مدل را تعیین می‌کند. در Claude Code، فایل CLAUDE.md عملاً نقش system prompt را بازی می‌کند: قوانین پروژه، ساختار دایرکتوری‌ها و conventions را یک‌بار تعریف می‌کنید و مدل در هر session آن‌ها را رعایت می‌کند.

Few-shot vs Chain-of-Thought: کدام‌کدام در Claude جواب می‌دهد#

برای taskهای classification و extraction، چندنمونه‌ای (few-shot prompting) مؤثرتر است. برای taskهای تحلیلی و استدلال چندمرحله‌ای، extended thinking بهتر عمل می‌کند چون مدل خودش زنجیره‌ی استدلال را می‌سازد بدون اینکه شما نمونه بدهید. ترکیب این دو برای taskهای پیچیده‌تر هم ممکن است.

Extended Thinking چیست و چه تفاوتی با reasoning ساده دارد#

Extended Thinking حالتی است که مدل قبل از پاسخ نهایی، زنجیره‌ی استدلالش را در یک بلوک جداگانه می‌سازد. برای باگ‌های چندفایلی، race condition و taskهای تحلیلی مفید است. برای typo و syntax error؟ صرفاً توکن می‌سوزاند.

الگوی قبل/بعد: پرامپت پرشده در مقابل پرامپت ساختارمند با CLAUDE.md#

نمونه‌ی قبل: کاربر ۱۵ فایل را یکی‌یکی paste می‌کند، توضیح می‌دهد که این فایل چیست، آن فایل چیست، و بعد می‌گوید «این باگ را fix کن». نتیجه: مدل در انبوه context گم می‌شود و پاسخ ناقص می‌دهد.

نمونه‌ی بعد: یک CLAUDE.md با ساختار پروژه و conventions نوشته شده. کاربر فقط می‌گوید: «تابع getUserById در فایل user.service.ts null برمی‌گرداند درحالی‌که record وجود دارد. علت را پیدا کن و fix کن.» مدل خودش فایل‌های مرتبط را می‌خواند و پاسخ دقیق‌تری می‌دهد.

چه taskهایی extended thinking می‌خواهند و چه taskهایی standard mode کافی است#

Extended thinking را برای این taskها فعال کنید: debugging چندفایلی، تصمیم معماری، code review با implication امنیتی، و migration که وابستگی‌های پیچیده دارد. Standard mode برای این taskها کافی است: rename متغیر، اضافه کردن import، نوشتن test ساده، و اصلاح typo.

MCP چیست و چطور Claude Code را به ابزارهای بیرونی وصل می‌کند؟#

MCP یا پروتکل زمینه‌ی مدل (Model Context Protocol) یک استاندارد باز برای اتصال مدل‌های زبانی به ابزارها و منابع خارجی است. بدون آن، Claude Code محدود به فایل‌های local می‌ماند و عملاً نصف ظرفیتش قفل است.

معماری MCP: server، client و protocol handshake#

MCP از سه جزء ساخته شده: یک server که ابزارها و منابع را expose می‌کند، یک client که درخواست‌ها را ارسال می‌کند، و یک protocol که نحوه‌ی handshake و exchange را تعریف می‌کند. در عمل، Claude Code نقش client را بازی می‌کند و شما serverهایی برای database، API یا filesystemهای دوردست می‌سازید.

اتصال سرور MCP به Claude Code: تنظیمات و نمونه‌ی عملی#

در فایل تنظیمات Claude Code، یک section به نام mcpServers اضافه می‌کنید که نام server، command اجرا و arguments را تعریف می‌کند. بعد از restart، مدل به ابزارهای آن server دسترسی پیدا می‌کند. مثلاً اگر یک MCP server برای PostgreSQL دارید، Claude Code می‌تواند query بنویسد، execute کند و نتیجه را در reasoning خودش استفاده کند.

ساخت MCP server سفارشی برای database داخلی یا API اختصاصی#

SDK رسمی MCP برای TypeScript و Python موجود است. یک server سفارشی معمولاً شامل سه بخش است: تعریف tools (با schema ورودی/خروجی)، تعریف resources (داده‌های قابل‌خواندن)، و پیاده‌سازی handlerها. برای یک API اختصاصی، هر endpoint را به‌عنوان یک tool تعریف می‌کنید و مدل خودش تصمیم می‌گیرد کدام را call کند.

چرا بسیاری از آموزش‌ها MCP را advanced جا می‌زنند درحالی‌که هسته‌ی workflow حرفه‌ای است#

MCP در ظاهر ساده است — یک config اضافه می‌کنید و تمام — اما آموزش‌های سطحی آن را به‌عنوان «feature پیشرفته» معرفی می‌کنند چون فرض می‌کنند کاربر هنوز در سطح چت است. در عمل، بدون MCP شما عملاً Claude Code را به یک chatbot با دسترسی filesystem محدود کرده‌اید. اتصال به database، CI/CD و monitoring بدون MCP ممکن نیست. این یک optional نیست؛ این همان چیزی است که ابزار را از «جالب» به «ضروری» تبدیل می‌کند.

ساخت ایجنت چندمرحله‌ای با Claude Code و sub-agentها#

Claude Code با قابلیت هماهنگی ایجنت‌های فرعی (sub-agent orchestration) امکان می‌دهد taskهای پیچیده‌ی چندمرحله‌ای را به زیر-ایجنت‌ها تقسیم کنید؛ هر sub-agent context مستقل و tool set محدود خودش را دارد.

الگوی escalation path: چت ساده → Claude Code → MCP server → sub-agent orchestration#

هر مرحله یک سطح قدرت و یک سطح پیچیدگی اضافه می‌کند. چت ساده برای سؤال و جواب. Claude Code برای ویرایش چندفایلی. MCP برای دسترسی به ابزارهای بیرونی. Sub-agent orchestration برای taskهایی که یک ایجنت به‌تنهایی نمی‌تواند همه‌ی مراحل را مدیریت کند.

تعریف sub-agent: نقش، دسترسی‌ها و محدودیت‌های هر عامل#

هر sub-agent یک نقش مشخص دارد (مثلاً «فقط lint check کن» یا «فقط security vulnerability پیدا کن»)، به مجموعه‌ی محدودی tool دسترسی دارد، و context خودش را مستقل از سایر agentها نگه می‌دارد. این جداسازی باعث می‌شود هر agent روی یک مسئله تمرکز کند و نتیجه‌ی دقیق‌تری بدهد.

Human-in-the-loop: چه زمانی approve/deny حیاتی است#

وقتی sub-agent قرار است فایل production را تغییر دهد، database را migrate کند یا dependency جدید اضافه کند، حتماً باید نظرات انسانی در حلقه (human-in-the-loop) فعال باشد. برای taskهای read-only مثل analysis و reporting، auto-accept مجاز است.

مثال عملی: ساخت ایجنت code-review با ۳ sub-agent#

یک ایجنت code-review ساده با سه sub-agent ساخته می‌شود:

  1. Linter agent: فقط lint errors و style violations را بررسی می‌کند. به فایل‌های source دسترسی دارد ولی به database نه.
  2. Security scanner agent: vulnerabilityهای امنیتی، hardcoded secret و injection risk را پیدا می‌کند.
  3. Performance analyzer agent: N+1 query، memory leak و algorithmic inefficiency را شناسایی می‌کند.

ایجنت اصلی هر سه را موازی اجرا می‌کند، نتایج را aggregate می‌کند و یک report نهایی تولید می‌کند. این الگو در پروژه‌های واقعی کامیونیتی بارها تکرار شده و هر بار نتیجه‌ی بهتری از یک ایجنت monolithic می‌دهد.

مدیریت context window در پروژه‌های بزرگ: الگوی CLAUDE.md و slash commands#

مدیریت context در پروژه‌های با بیش از ۱۰۰ فایل با ریختن همه‌چیز در یک پرامپت شکست می‌خورد؛ الگوی صحیح استفاده از فایل CLAUDE.md، slash commands و مهندسی زمینه (context engineering) است.

ساختار سازمان‌یافته‌ی دانش فنی به صورت بلوک‌های مدولار متصل که مسیرهای اطلاعاتی را در پروژه‌های بزرگ روشن می‌کند
هر بلوک نماینده‌ی یک فایل یا دستور است و مسیرهای نورانی نشان می‌دهند چگونه context در هر لحظه فعال می‌ماند

ساختار فایل CLAUDE.md: چه اطلاعاتی بنویسیم و چه چیزی را حذف کنیم#

CLAUDE.md باید شامل این موارد باشد: ساختار دایرکتوری‌ها، conventions پروژه (naming، file organization)، قوانین linting، و محدودیت‌های معماری. نباید شامل محتوای فایل‌ها، توضیح business logic هر تابع، یا duplicate از README باشد.

هر چیزی که مدل می‌تواند خودش از فایل‌ها بخواند، در CLAUDE.md بی‌فایند است. این فایل نقشه‌ی پروژه است، نه کپی پروژه.

Slash Commands در Claude Code: /clear، /compact و دستورهای سفارشی#

Slash commands ابزارهای مدیریت session هستند:

  • /clear: context را کاملاً پاک می‌کند. وقتی موضوع کار عوض می‌شود، بهترین گزینه است.
  • /compact: context را خلاصه می‌کند. وقتی می‌خواهید ادامه دهید ولی بودجه‌ی توکن کم است.
  • دستورهای سفارشی: در تنظیمات می‌توانید commandهای سفارشی تعریف کنید که یک workflow مشخص را trigger کنند.

الگوی context engineering: چگونه بدون تغییر پرامپت، رفتار agent را تنظیم کنیم#

Context engineering یعنی به‌جای نوشتن پرامپت‌های بلندتر، محیطی بسازید که مدل خودش اطلاعات درست را در زمان درست داشته باشد. CLAUDE.md یک ابزار context engineering است. محدود کردن دسترسی sub-agent به tools خاص، نوع دیگری است. حتی ترتیب فایل‌ها در پروژه می‌تواند روی کیفیت پاسخ تأثیر بگذارد.

اشتباه رایج prompt stuffing: نمونه‌ی قبل/بعد و هزینه‌ی واقعی آن در توکن#

Prompt stuffing (پر کردن بی‌رویه‌ی پرامپت) رایج‌ترین اشتباه در پروژه‌های بزرگ است. کاربر ۲۰ فایل paste می‌کند و می‌گوید «همه را بخوان و fix کن». هزینه: هم بودجه‌ی توکن بی‌دلیل مصرف می‌شود، هم مدل در انبوه اطلاعات، اطلاعات میانی را فراموش می‌کند. الگوی صحیح: فقط فایل‌های مستقیماً مرتبط را در context قرار دهید و بقیه را به مدل بسپارید که خودش بخواند.

هزینه‌ی واقعی استفاده حرفه‌ای: اشتراک، API pricing و مقایسه‌ی اقتصادی تیم#

Claude Pro اشتراک ماهانه‌ی پایه است، Claude Max برای مصرف سنگین‌تر پلن‌های بالاتر دارد، و API به‌صورت per-token هزینه می‌شود. برای یک تیم ۵ نفره، انتخاب بین این مدل‌ها به مصرف واقعی بستگی دارد نه به قیمت اسمی.

ساختار اشتراک‌ها: Pro، Max و Enterprise#

برای جزئیات دقیق قیمت، صفحه‌ی رسمی Anthropic را بررسی کنید چون پلن‌ها و قیمت‌ها تغییر می‌کنند. اما ساختار کلی این است: Pro برای مصرف شخصی و متوسط، Max برای مصرف سنگین (مثلاً استفاده‌ی روزانه‌ی چندساعته با Claude Code)، و Enterprise برای تیم‌ها با نیاز به SSO، audit log و SLA.

API pricing: مقایسه‌ی مدل‌های Claude Opus و Sonnet از نظر هزینه‌ی per-token#

مدل Opus قوی‌تر و گران‌تر است، Sonnet سریع‌تر و ارزان‌تر. برای taskهایی که extended thinking لازم ندارند، Sonnet از نظر هزینه-مصرف بهینه‌تر است. برای reasoning چندمرحله‌ای و codebase-aware tasks، Opus کیفیت بهتری می‌دهد. جزئیات قیمت per-token را از مستندات API Anthropic بگیرید.

سناریوی مصرف واقعی تیم ۵ نفره#

اگر هر نفر روزانه دو ساعت با Claude Code کار کند و هر session ده‌ها هزار توکن مصرف کند، در ماه به‌صورت API direct هزینه قابل‌توجهی می‌شود. در این سناریو، اشتراک Max برای هر نفر مقرون‌به‌صرفه‌تر است. اما اگر فقط هفته‌ای چند بار task پیچیده دارید، API direct با مدل Sonnet ارزان‌تر تمام می‌شود. معیار تصمیم، مصرف واقعی است نه قیمت اسمی.

چگونه token budget را در Claude Code ردیابی و بهینه کنیم#

در Claude Code، مصرف توکن در هر session قابل مشاهده است. برای بهینه‌سازی: از /clear بین taskهای مختلف استفاده کنید، CLAUDE.md را مینیمال نگه دارید، و برای taskهای ساده extended thinking را غیرفعال بگذارید. این سه اقدام به‌تنهایی مصرف توکن را در پروژه‌های واقعی کاهش می‌دهند.

اشتباهات رایج در استفاده از Claude که وقت و پول را می‌سوزاند#

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

اشتباه ۱: Claude Code را autocomplete فرض کردن#

اگر فقط می‌خواهید یک خط کد بنویسید و از Claude Code استفاده می‌کنید، عملاً یک ابزار چندفایلی را به‌عنوان یک ابزار تک‌خطی مصرف می‌کنید. هزینه‌ی هر توکن بالاتر از autocomplete ساده است و latency بیشتر. برای این کار، Copilot یا tab completion IDE خودش کافی است.

اشتباه ۲: مقایسه بر اساس MMLU و HumanEval به‌جای performance در task چندمرحله‌ای#

بنچمارک‌های آکادمیک مثل MMLU و HumanEval نشان می‌دهند مدل در تست‌های بسته چقدر خوب است. هیچ‌کدام نشان نمی‌دهند مدل در یک کدبیس واقعی با صدها فایل، dependency پیچیده و conventions خاص چقدر عمل می‌کند. معیار انتخاب باید workflow واقعی شما باشد.

اشتباه ۳: نادیده‌گرفتن MCP و محدود کردن Claude به چت#

بدون MCP، Claude Code فقط فایل‌های local را می‌بیند. نمی‌تواند query بزند، به CI/CD وصل شود، یا از API داخلی سازمان بخواند. بسیاری از توسعه‌دهندگان که MCP را نادیده می‌گیرند، عملاً ظرفیت چندلایه‌ی ابزار را به یک چت‌باکس پیشرفته تقلیل داده‌اند.

اشتباه ۴: extended thinking برای taskهای ساده#

هر بار extended thinking فعال باشد، مدل زنجیره‌ی استدلال می‌سازد و توکن بیشتری مصرف می‌کند. برای rename کردن یک متغیر یا اضافه کردن یک import، این overhead بی‌مورد است. Task-driven تصمیم بگیرید، نه default-on.

اشتباه ۵: فایل‌به‌فایل feeding در پروژه‌های بزرگ به‌جای context engineering#

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

نقشه‌ی راه یادگیری Claude: از چت ساده تا ایجنت‌سازی حرفه‌ای#

مسیر یادگیری Claude چهار مرحله دارد: تسلط بر چت و پرامپت ساختارمند، کار با Claude Code و CLAUDE.md، اتصال MCP serverها، و در نهایت ساخت ایجنت چندمرحله‌ای با sub-agent orchestration. هر مرحله پیش‌نیاز مرحله‌ی بعدی است.

مرحله ۱: پرامپت‌نویسی و شناخت مدل‌ها#

در دو هفته‌ی اول، فقط با Claude در چت کار کنید. System Prompt بنویسید، few-shot تست کنید، extended thinking را فعال و غیرفعال کنید و تفاوت نتیجه را ببینید. هدف: درک اینکه مدل چه زمانی نیاز به context دارد و چه زمانی خودش می‌فهمد.

مرحله ۲: Claude Code و context engineering#

سه هفته برای این مرحله واقع‌بینانه است. یک پروژه‌ی واقعی انتخاب کنید، CLAUDE.md بنویسید، slash commands را تمرین کنید، و multi-file edit انجام دهید. هدف: تبدیل شدن به کسی که به‌جای paste کردن فایل‌ها، محیط می‌سازد.

مرحله ۳: MCP و اتصال ابزارهای خارجی#

دو هفته برای اتصال اولین MCP server کافی است. یک server ساده برای database یا API داخلی بسازید و تست کنید. هدف: فهمیدن اینکه Claude Code بدون MCP عملاً نصف ظرفیتش قفل است.

مرحله ۴: ایجنت‌سازی و orchestration#

این مرحله مستقیم است و پایان مشخصی ندارد. sub-agent تعریف کنید، human-in-the-loop تنظیم کنید، و workflowهای چندمرحله‌ای بسازید. هدف: رسیدن به جایی که یک task بزرگ را به ایجنت‌ها بسپارید و فقط review کنید.

منابع پیشنهادی#

مستندات رسمی Anthropic برای Claude Code و MCP، نمونه‌های باز در GitHub برای MCP serverها، و پروژه‌های کامیونیتی که الگوهای CLAUDE.md را به اشتراک گذاشته‌اند. برای یادگیری ساختاریافته‌تر، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول از چت شروع می‌کند تا ایجنت‌سازی. برای دیدن سرفصل‌ها و شروع دوره، صفحه‌ی دوره در اسکول را ببینید.

جمع‌بندی عملی#

Claude Code یک ابزار عامل‌محور است، نه autocomplete. پرامپت ساختارمند کوتاه بهتر از پرامپت بلند غیرساختارمند عمل می‌کند. مدیریت context با CLAUDE.md و slash commands انجام می‌شود نه با paste کردن فایل‌ها. و MCP لایه‌ی اتصال به دنیای بیرون است که بدون آن workflow ناقص می‌ماند. اگر می‌خواهید این مسیر را با ساختار و تمرین طی کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی اسکول دقیقاً همین escalation path را از صفر پوشش می‌دهد.