آموزش Claude Code را اگر با ذهنیت autocomplete شروع کنید، خروجی‌اش ضعیف می‌ماند. این ابزار یک ایجنت ترمینالی (terminal-native AI agent) است که خودش plan میکند، tool call می‌زند و iterate میکند. تفاوت بنیادی اینجاست: در assistant شما دستور می‌دهید و خروجی می‌گیرید؛ در agent شما goal تعریف می‌کنید و agent خودش مسیر را می‌چیند. همین یک جمله، معماری prompt، context و permissions شما را از ریشه عوض میکند.
Claude Code چیست و چه فرقی با Cursor و Copilot دارد؟#
Claude Code یک ایجنت ترمینالی است که goal شما را می‌گیرد و خودش plan، edit و test را انجام میدهد. Cursor یک assistant درون IDE است که instruction مرحله‌به‌مرحله می‌خواهد. Copilot یک autocomplete است که فقط خط بعدی را حدس می‌زند. این سه در معماری متفاوت‌اند و نحوه‌ی تعامل با هر کدام کاملاً فرق دارد.
تفاوت بنیادی مدل ذهنی: assistant در برابر agent#
در مدل assistant، شما یک instruction مرحله‌به‌مرحله می‌نویسید: «این تابع را بنویس، این خط را عوض کن، این import را اضافه کن.» assistant دقیقاً همان را انجام میدهد. در مدل agent، شما یک goal تعریف می‌کنید: «این API را از REST به GraphQL migrate کن.» agent خودش فایل‌ها را می‌خواند، plan می‌چیند، edit میکند، test اجرا میکند و اگر fail شد، اصلاح میکند.
این تفاوت یعنی prompt شما باید context و constraint بنویسد نه instruction. به‌جای «تابع f را بنویس»، بنویسید «تابع f را با توجه به conventions موجود در پوشه‌ی utils بنویس و test بنویس.»
مقایسه‌ی معماری Claude Code، Cursor، Windsurf و GitHub Copilot#
| معیار | Claude Code | Cursor | Windsurf | GitHub Copilot |
|---|---|---|---|---|
| محل اجرا | ترمینال | IDE (VS Code fork) | IDE (VS Code fork) | Plugin در IDE |
| نوع تعامل | Agent (goal-based) | Assistant (instruction-based) | Assistant + Cascade | Autocomplete |
| دسترسی به فایل‌سیستم | مستقیم، با permission tiers | از طریق IDE | از طریق IDE | محدود به فایل باز |
| مدیریت context | CLAUDE.md سلسلهمراتبی | Codebase indexing خودکار | Flow awareness | Context از فایل‌های مجاور |
| مناسب برای | Refactoring چندفایلی، greenfield، migration | Iterative coding در IDE | Workflowهای in-IDE | Micro-edit و autocomplete |
چرا این تفاوت، نحوه‌ی نوشتن prompt را عوض میکند#
وقتی با یک agent کار می‌کنید، prompt شما شبیه spec یک task در Jira است: هدف، محدودیت‌ها، معیارهای موفقیت. نه شبیه دستور به یک کارمند که هر قدم را باید بگویید. اگر از Claude Code انتظار دارید مثل Copilot رفتار کند، عملاً از یک ایجنت‌باکس به‌عنوان autocomplete استفاده می‌کنید و تمام overhead ایجنتی را بی‌دلیل می‌پردازید.
الگوی رایج در پروژههای واقعی کامیونیتی این است که کاربران تازه‌کار، promptهای مرحله‌به‌مرحله به Claude Code می‌دهند و وقتی خروجی ضعیف است، ابزار را مقصر می‌دانند. مشکل از مدل ذهنی است، نه از ابزار. و اصلاح مدل ذهنی، ارزان‌تر از عوض کردن ابزار است.
نصب، پیکربندی و مدیریت permissions: از ترمینال تا اولین session#
Claude Code بهصورت native در ترمینال اجرا میشود، نیاز به IDE خاص ندارد و پس از دوره‌ی research preview عمومی شد؛ نصب از طریق CLI انجام میشود و اولین گام تنظیم permission tiers است.
پیش‌نیازها و نصب گام‌به‌گام در ترمینال#
برای اجرای Claude Code به Node.js و یک اشتراک فعال Anthropic (Claude Pro یا Max) یا دسترسی مستقیم به API نیاز دارید. نصب معمولاً یک‌خطی است و در پوشه‌ی پروژه اجرا میشود. جزئیات دقیق نسخه‌ی Node و دستورات نصب را از مستندات رسمی Anthropic بررسی کنید، چون این بخش ممکن است تغییر کند.
سه سطح permission برای هر tool#
هر tool در Claude Code — file read، file write، bash command، MCP tool — سه سطح permission دارد: allow (اجازه‌ی خودکار)، ask (پرسیدن از کاربر)، deny (مسدود کامل). انتخاب بین این سه، مستقیماً workflow و امنیت را تعیین میکند.
همه را allow گذاشتن یک اشتباه امنیتی جدی است: اگر agent به‌خاطر hallucination یا prompt injection یک rm -rf بزند، جلوی آن را کسی نمی‌گیرد. همه را ask گذاشتن هم workflow را می‌کُشد؛ هر file read یک confirmation می‌خواهد و session عملاً غیرقابل استفاده میشود.
الگوی عملی: file read را allow بگذارید (بدون ریسک است)، file write را در پوشه‌ی پروژه allow و خارج از آن deny کنید، bash command را ask بگذارید و MCP toolها را بر اساس اعتماد به server انتخاب کنید.
یکپارچهسازی با Git#
Claude Code بهصورت native با Git کار میکند — branch ساختن، commit زدن و merge را خودش انجام میدهد. با hook میتوانید قبل از هر commit یک lint یا type check اجباری کنید تا کد نادرست اصلاً وارد تاریخچهی Git نشود. این الگو در پروژههای واقعی members کامیونیتی بارها دیده شده و یکی از مؤثرترین guardrails است.
CLAUDE.md: چرا هرچه بنویسید بهتر نیست#
فایل CLAUDE.md context پروژه را به Claude Code میدهد، اما context stuffing باعث پدیده‌ی lost in the middle و افت کیفیت پاسخ میشود؛ الگوی صحیح، CLAUDE.md سلسلهمراتبی با index file و on-demand loading است.
ساختار سلسلهمراتبی#
به‌جای یک CLAUDE.md بزرگ که همه‌چیز را توصیف میکند، یک فایل ریشه‌ای مختصر بنویسید که فقط conventions کلان و architecture decisions را شامل شود. سپس در هر زیرپوشه، یک CLAUDE.md محلی بگذارید که context آن پوشه را تعریف کند. وقتی agent وارد پوشه‌ای میشود، فقط context مربوط به همان پوشه را می‌خواند.
مشکل lost in the middle#
وقتی context window پر شود، مدل روی بخش‌های میانی «فراموش» میکند. این پدیده در ادبیات پژوهشی با نام lost in the middle شناخته میشود و در تمام مدلهای بزرگ زبانی دیده شده. راه‌حل: index file + on-demand loading. یعنی CLAUDE.md ریشه فقط یک فهرست از فایل‌های موجود باشد و agent خودش تصمیم بگیرد کدام را بخواند.
چه چیزی در CLAUDE.md بنویسیم و چه چیزی نه#
- بنویسید: conventions نام‌گذاری، architecture decisions کلان، gotchas و اشتباهات رایج پروژه، الگوهای تکرارشونده
- ننویسید: توضیح هر فایل، کد نمونه‌ی طولانی، تاریخچهی پروژه، چیزهایی که از خود کد قابل استنتاج‌اند
اشتباه رایج: کاربران فکر می‌کنند هرچه بیشتر در CLAUDE.md بنویسند، agent باهوش‌تر میشود. در عمل، context stuffing باعث میشود agent روی جزئیات بیاهمیت تمرکز کند و از conventions کلان غافل شود. یک CLAUDE.md 200 خطی که 150 خطش توضیح فایل‌هاست، از یک CLAUDE.md 30 خطی که فقط gotchas و architecture decisions را فهرست میکند، بدتر عمل میکند.
MCP را چطور فعال کنم و چه ارزشی اضافه میکند؟#
MCP (Model Context Protocol) پروتکل باز Anthropic برای اتصال ابزارهای خارجی به مدلهای هوش مصنوعی است که به‌عنوان استاندارد de facto تبدیل شده؛ در Claude Code با یک config ساده فعال میشود و به agent اجازه میدهد به دیتابیس، APIهای داخلی و ابزارهای devops وصل شود.
MCP چیست و چرا استاندارد شده#
پیش از MCP، هر ابزار AI coding یک روش proprietary برای اتصال به external tool داشت. MCP این را به یک پروتکل مشترک تبدیل کرد: یک server تعریف می‌کنید، capabilities را expose می‌کنید، و هر client که MCP support کند میتواند از آن استفاده کند. این decoupling یعنی server شما بین Claude Code، Cursor و هر ابزار سازگار دیگر قابل استفادهی مجدد است.
فعال‌سازی MCP در Claude Code#
فعال‌سازی از طریق یک فایل config انجام میشود که در آن serverها تعریف می‌شوند. هر server یک command و argument دارد. برای جزئیات دقیق فرمت config، مستندات رسمی Anthropic را بررسی کنید چون این بخش در حال تکامل است.
نمونه‌های کاربردی MCP server#
- اتصال به دیتابیس داخلی برای query زدن مستقیم
- اتصال به APIهای داخلی شرکت برای fetch کردن data
- اتصال به ابزارهای devops مثل Kubernetes یا Terraform
- اتصال به سیستم‌های ticketing مثل Jira برای context گرفتن از task
تفاوت MCP با plugin معمولی#
Plugin معمولی vendor-specific است و فقط در یک ابزار کار میکند. MCP server یک واحد مستقل است که هر client سازگار میتواند مصرف کند. این یعنی اگر امروز Claude Code استفاده می‌کنید و فردا به ابزار دیگری مهاجرت کنید، serverهای MCP شما بدون تغییر قابل استفاده‌اند.
Subagent و orchestration چندلایه: role separation در عمل#
Subagent در Claude Code یک ایجنت مستقل با context و permissions متفاوت است؛ به‌جای اینکه یک agent همزمان همه‌ی وظایف را انجام دهد، subagentهای مجزا با نقش مشخص می‌سازید. این الگو کیفیت خروجی را بهطور محسوس بالا می‌برد.
مفهوم subagent و تفاوتش با یک session معمولی#
هر subagent یک context window مستقل، permissions مستقل و حتی میتواند model مستقل داشته باشد. یعنی subagent test-writing میتواند با Haiku کار کند (ارزان و سریع) در حالی که subagent architecture-review با Opus کار کند. parent agent این‌ها را orchestrate میکند.
الگوی role separation#
در پروژههای واقعی members کامیونیتی، این الگو بارها دیده شده: یک subagent فقط برای test writing، یکی برای documentation، یکی برای code review. هر کدام context مخصوص خود را دارد و permissions محدودتر. نتیجه: کمتر hallucinate میکند، چون focus narrowتر است.
Orchestration: ترکیب نتایج#
Parent agent subagentها را فراخوانی میکند، نتایج را جمع میکند و تصمیم نهایی را می‌گیرد. مثلاً: subagent اول code را می‌نویسد، subagent دوم test می‌نویسد، subagent سوم review میکند. اگر review fail شد، parent agent feedback را به subagent اول برمی‌گرداند و iterate میشود.
Hookها و slash command: خودکارسازی workflow و guardrails#
Hookها event-based actionهایی هستند که قبل یا بعد از عملیات Claude Code اجرا می‌شوند و به‌عنوان fail-fast guardrails عمل می‌کنند؛ slash commandها workflowهای تکرارشونده‌ی سفارشی هستند که با یک دستور اجرا می‌شوند.
Hook چیست و چه زمانی اجرا میشود#
سه نوع hook اصلی وجود دارد: pre-tool (قبل از اجرای هر tool)، post-tool (بعد از اجرای هر tool)، و application-level (در نقاط خاص lifecycle session). hookها می‌توانند یک bash command اجرا کنند و بر اساس exit code، عملیات را block یا allow کنند.
الگوی fail-fast با hook#
مؤثرترین استفاده از hook: lint check یا type check قبل از هر file write. اگر lint fail شود، hook exit code غیرصفر برمی‌گرداند و agent نمی‌تواند فایل را بنویسد. این یعنی کد نادرست اصلاً وارد پروژه نمی‌شود. الگوی رایج در پروژههای واقعی: eslint یا tsc --noEmit به‌عنوان pre-write hook.
ساخت slash command سفارشی#
Slash command یک workflow تکرارشونده است که در یک فایل تعریف میشود و با اجرای دستور مربوطه در session قابل فراخوانی است. مثلاً یک command که: subagent test را فراخوانی کند، coverage را چک کند، و اگر coverage زیر threshold بود، testهای جدید بنویسد.
هزینه‌ی Claude Code و معیار انتخاب پلن#
اشتراک Claude Pro با قیمت 20 دلار در ماه ارائه میشود و Claude Max شامل دو پلن 100 و 200 دلار در ماه است؛ معیار انتخاب، حجم وظایف ایجنتی و نیاز به modelهای سنگین‌تر مثل Opus است. این قیمت‌ها مربوط به زمان نگارش این مقاله‌اند و ممکن است تغییر کنند.
مدلهای Claude و انتخاب بر اساس نوع وظیفه#
- Opus: کارهای پیچیده‌ی reasoning، معماری، refactoring چندفایلی با dependencies پیچیده
- Sonnet: کدنویسی روزانه، نوشتن test، documentation — balance بین سرعت و کیفیت
- Haiku: taskهای ساده، lint fixing، formatting، subagentهای ارزان
اشتباه رایج: استفاده از Opus برای همه‌ی وظایف#
Opus کندتر و گران‌تر است. برای کارهای روتین مثل نوشتن یک CRUD endpoint یا fix کردن یک typo، Sonnet یا حتی Haiku کافی‌اند. در session میتوانید model را تغییر دهید؛ برای وظایف روتین کدنویسی Sonnet کافی است و Opus را فقط برای کارهای پیچیده‌ی reasoning و معماری نگه دارید. استفادهی Opus برای همه‌ی وظایف، پرهزینه‌ترین اشتباهی است که در کلاس‌ها مکرر تکرار میشود.
محاسبه‌ی ROI بر اساس نوع وظیفه#
Claude Code در greenfield coding و refactoring چندفایلی ROI مثبت دارد چون taskهای بزرگ را در یک session انجام میدهد. برای micro-edit تک‌خطی، overhead ایجنتی (خواندن context، plan کردن، tool call زدن) بیشتر از خود کار هزینه دارد و توجیه اقتصادی ندارد و بهتر است از IDE + autocomplete استفاده کنید.
چه کارهایی را به Claude Code بسپاریم و چه کارهایی را نه#
Claude Code در greenfield coding، refactoring چندفایلی، و وظایف نیازمند plan و iterate برتری محسوس دارد؛ برای micro-edit تک‌خطی یا وظایفی که context طولانی ندارند، overhead ایجنتی توجیه اقتصادی ندارد و بهتر است از IDE + autocomplete استفاده کنید.
وظایف ایده‌آل Claude Code#
- ساخت پروژه‌ی جدید از صفر با architecture مشخص
- Refactoring legacy code با چند فایل وابسته
- نوشتن test suite کامل برای یک module
- Migration بین frameworkها یا نسخه‌های API
- Debugging چندلایه‌ای با trace کردن flow
وظایف نامناسب#
- تغییر یک خط کد در یک فایل
- Autocomplete ساده‌ی یک variable name
- Taskهایی که context چند فایل ندارند
- کارهایی که نیاز به feedback loop لحظه‌ای در IDE دارند
الگوی ترکیبی#
در پروژههای واقعی، الگوی ترکیبی رایج‌تر از استفادهی صرف است: Claude Code برای ساختار و refactoringهای بزرگ، Cursor یا Copilot برای micro-edit در کنار هم. این یعنی یک workflow دو-ابزاری که هر ابزار در نقطه‌ی قوت خودش استفاده میشود.
نتیجه‌ی عملی: اگر مدل ذهنی‌تان را از autocomplete به agent تغییر دهید، CLAUDE.md سلسلهمراتبی بنویسید، permission tiers را درست تنظیم کنید و hookهای fail-fast اضافه کنید، کیفیت خروجی Claude Code چند برابر میشود. اگر تازه شروع کرده‌اید و می‌خواهید این مدل ذهنی را در یک مسیر ساختارمند یاد بگیرید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً برای همین طراحی شده.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.