بزرگ‌ترین خطای رایج در کار با Claude Code، استفاده‌ی آن مثل یک autocomplete پیشرفته است. این ابزار یک ایجنت ترمینالی (Terminal Agent) است که بدون الگوی مشخص، فایلسیستم پروژه را مستقیماً دستکاری میکند. آموزش Claude برای کار حرفهای یعنی یادگیری سه مهارت: نوشتن CLAUDE.md، مدیریت context window، و ساخت ایجنت چندمرحلهای. بدون این سه، کیفیت خروجی به‌شدت افت میکند.
Claude Code چیست و چرا جایگزین IDE نیست#
Claude Code یک ایجنت ترمینالی است که مستقیماً در CLI اجرا میشود و دسترسی read/write به فایلسیستم پروژه دارد. اما جایگزین IDE نیست؛ چون برخلاف افزونه‌های ویرایشگر، هیچ visual diffای به شما نشان نمی‌دهد و تصمیماتش را تا commit متوجه نمی‌شوید. این تفاوت ساختاری، نه نقص است نه برتری — فقط یک انتخاب معماری متفاوت است.
تفاوت با Cursor و Copilot بنیادی است. این دو در لایهی editor کار می‌کنند؛ شما تغییرات را قبل از apply می‌بینید. Claude Code در terminal اجرا میشود، دستورات shell می‌زند و فایل‌ها را بدون نمایش مستقیم تغییر میدهد. اگر پرامپت مبهم باشد، مدل خودش تصمیم می‌گیرد چه چیزی را دستکاری کند.
محدودیت جدی‌ترین بخش ماجراست. در پروژه‌هایی با معماری microservice و ده‌ها فایل وابسته، Claude Code بدون human-in-the-loop می‌تواند کدبیس را تخریب کند. مستندات Anthropic خود این ریسک را ذکر کرده، اما در عمل کمتر کسی جدی می‌گیرد.
benchmarkهای عمومی مثل SWE-bench عملکرد کلی مدل را نشان میدهند، اما عملکرد واقعی در workflow تیم شما به ساختار کدبیس، زبان‌های برنامه‌نویسی و الگوهای معماری بستگی دارد. یک پروژه‌ی Python ساده با Claude Code عالی کار میکند؛ یک monorepo با 200 فایل TypeScript و importهای چرخشی، نه.
آموزش Claude Code: نصب، پیکربندی و الگوی CLAUDE.md#
آموزش Claude Code با یک دستور npm شروع میشود، اما پیکربندی واقعی در فایل CLAUDE.md است. این فایل، معماری پروژه و قوانین کدنویسی تیم را به‌عنوان نقشه‌ی اولیه به مدل میدهد. بدون آن، هر session از صفر شروع میشود و مدل هیچ‌گاه کدبیس شما را نمی‌شناسد.
الگوی اسکن-سپس-اقدام که در مستندات Claude Code توصیف شده، یعنی: مدل اول باید بفهمد پروژه چه ساختاری دارد، چه قوانینی دارد، و چه چیزهایی ممنوع است. بعد از آن، تسک اجرایی را انجام دهد. CLAUDE.md دقیقاً همین نقشه را به‌صورت persistent در هر session تزریق میکند.
نصب و پیکربندی اولیه#
پیش‌نیازها: Node.js نسخهی LTS، دسترسی به ترمینال و یک API Key معتبر از Anthropic.
- دستور نصب:
npm install -g @anthropic-ai/claude-code - تنظیم
ANTHROPIC_API_KEYدر environment variables - اجرای
claudeدر ریشه‌ی پروژه و اولین تعامل - ایجاد فایل
CLAUDE.mdدر ریشه‌ی پروژه
اولین اجرا معمولاً ساده است: مدل فایل‌ها را اسکن میکند و خلاصه‌ای از ساختار پروژه میدهد. اما بدون CLAUDE.md، این خلاصه موقتی است و در session بعدی از بین می‌رود.
فایل CLAUDE.md: نقشه‌ی معماری پروژه#
ساختار پیشنهادی CLAUDE.md چهار بخش دارد: Overview (توصیف یک‌خطی پروژه)، Tech Stack (فریمورک‌ها و کتابخانه‌ها)، Coding Rules (قوانین lint، naming conventions، الگوهای طراحی) و Forbidden Patterns (کارهایی که مدل نباید انجام دهد).
چرا این فایل هر session را متحول میکند؟ چون Claude Code بدون آن، هر بار باید کدبیس را از صفر بفهمد. با CLAUDE.md، مدل از همان اولین پرامپت می‌داند که state management در این پروژه با Zustand انجام میشود، نه Redux. یا که استفاده از any در TypeScript ممنوع است.
نمونه‌ی واقعی از یک CLAUDE.md در پروژه‌ی production:
## Overview Next.js 14 App Router project with TypeScript strict mode. ## Tech Stack - State: Zustand (NOT Redux) - Styling: Tailwind CSS - Auth: NextAuth.js - DB: Prisma + PostgreSQL ## Coding Rules - Always use functional components - File naming: kebab-case for components, camelCase for utils - All API routes must validate input with Zod ## Forbidden Patterns - Do NOT use class components - Do NOT add new dependencies without asking - Do NOT modify prisma/schema.prisma without explicit instruction
این الگو در مستندات Anthropic آمده، اما در آموزش‌های فارسی‌زبان تقریباً هیچ‌جا به‌صورت عملیاتی پوشش داده نشده. همین شکاف، دلیل اصلی افت کیفیت خروجی Claude Code در پروژههای واقعی است.
پرامپتنویسی حرفهای برای Claude 3.5 Sonnet با XML Tagging#
پرامپتنویسی حرفهای برای Claude 3.5 Sonnet یعنی استفاده از XML tags به‌جای Markdown. این مدل به‌طور خاص روی XML آموزش دیده و structured output با XML بسیار قابل‌اعتمادتر از Markdown است. برخلاف GPT که با Markdown هم خوب کار میکند، Claude با XML ساختاردهی‌شده پایدارتر عمل میکند.
تفاوت رفتاری در عمل محسوس است. وقتی از Claude 3.5 Sonnet بخواهید با XML tag خروجی بدهد، احتمال اینکه schema را رعایت کند بالاتر است. این موضوع در تسک‌هایی که خروجی را parse می‌کنید — مثلاً در ایجنت چندمرحلهای — حیاتی است.
ساختار system prompt حرفهای سه بخش دارد: نقش (مثلاً «تو یک senior TypeScript developer هستی»)، محدودیتها (قوانینی که نباید بشکند)، و فرمت خروجی مورد انتظار. هر سه را با XML tag جدا کنید.
Chain-of-Thought (CoT) در Claude همیشه لازم نیست. برای تسکهای ساده‌ی کدنویسی، overhead بی‌مورد اضافه میکند. اما برای architectural decisions که tradeoff دارند، CoT کیفیت را بالا میبرد. معیار ساده: اگر تسک بیش از یک مرحلهی استدلالی دارد، CoT بخواهید.
Temperature برای brainstorming معماری روی 0.3 تا 0.5 بهتر از صفر است. صفر تکراری و خشک تولید میکند؛ 0.3 تا 0.5 تنوع کنترل‌شده میدهد بدون اینکه coherence از بین برود. برای تسکهای کدنویسی با جواب مشخص، temperature پایین‌تر مناسب‌تر است.
الگوی ضدّکارآمد: «فقط یک پرامپت ساده بنویس و بقیه را به مدل بسپار» برای Claude 3.5 Sonnet غلط است. این مدل به‌طور خاص برای structured instructions آموزش دیده و پرامپت مبهم را با فرضیات خودش پر میکند — که اغلب فرضیات اشتباه‌اند.
چطور context window را در sessionهای طولانی مدیریت کنم؟#
مدیریت context window در sessionهای طولانی یعنی context pruning دستی، نه reliance روی عدد تبلیغاتی. با وجود context window 200K توکن، در عمل با فایلهای بزرگ و sessionهای طولانی کیفیت پاسخ افت میکند. حذف فایلهای irrelevant از context، مؤثرترین روش حفظ کیفیت است.
واقعیت عملی: مدل‌های زبانی در انتهای context window ضعیف‌تر کار می‌کنند. اگر 150K توکن فایل وارد context کرده‌اید، احتمالاً 50K آخر (که فایلهای کم‌اهمیت‌ترند) کیفیت را پایین آورده‌اند.
در CLAUDE.md می‌توانید exclude بنویسید: فایل‌ها یا دایرکتوری‌هایی که مدل نباید بخواند. این ساده‌ترین و مؤثرترین روش context pruning است.
الگوی session hygiene: اگر session آلوده شده — یعنی مدل در پاسخ‌هایش گیج می‌زند و فایلهای اشتباه را reference میکند — ادامه ندهید. session جدید باز کنید. خلاصه‌سازی نتایج میانی قبل از ورود به مرحلهی بعد، از آلودگی context جلوگیری میکند.
نکات دیباگ: وقتی Claude Code در فایلهای بزرگ گیج میشود، اول context را کوچک کنید نه پرامپت را پیچیده. error message کامل را با XML tag بپیچید و از مدل بخواهید hypothesis بدهد، نه patch. بعد از تأیید hypothesis، patch بخواهید.
Claude Code در برابر Cursor و GitHub Copilot: مقایسه بر اساس workflow#
تمایز واقعی بین Claude Code، Cursor و GitHub Copilot در feature list نیست، در workflow است. Claude Code برای terminal-first و CI/CD integration ساخته شده، Cursor برای IDE-first و visual feedback، و Copilot برای autocomplete درون-editor. انتخاب یکی به‌جای ترکیب هر سه، معمولاً گران‌تر از چیزی است که به‌نظر می‌رسد.
| معیار | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| نوع تعامل | Terminal / CLI | IDE / Visual diff | Inline autocomplete |
| Context awareness | فایلسیستم کامل پروژه | فایل باز + workspace | فایل باز + context محدود |
| Refactoring capability | قوی اما ریسکی بدون review | قابل‌کنترل با visual diff | محدود به فایل فعال |
| CI/CD integration | مستقیم (shell execution) | غیرمستقیم | GitHub Actions native |
| Batch operations | عالی (scripted tasks) | محدود | نامناسب |
| مناسب برای | Terminal-first developers | IDE-first developers | Fast autocomplete |
اشتباه رایج: مقایسه‌ی صرف benchmarkهای عمومی با عملکرد واقعی در پروژه‌ی خاص. SWE-bench یک عدد میدهد، اما پروژه‌ی شما 200 فایل TypeScript با importهای چرخشی است. عملکرد واقعی به ساختار کدبیس بستگی دارد.
مقایسه‌ی عملکرد در تسکهای واقعی#
حل باگ در فایل تک‌منبعی: هر سه ابزار قابل قبول‌اند. تفاوت محسوسی نیست.
Refactoring cross-file: Claude Code بدون review خطرناک عمل میکند چون مستقیماً فایل‌ها را تغییر میدهد. Cursor با visual diff قابل‌کنترل‌تر است چون قبل از apply می‌بینید چه چیزی عوض شده.
Code review خودکار: Copilot در این تسک ضعیف است چون context محدودی دارد. Claude Code با CLAUDE.md قوی عمل میکند چون قوانین تیم را می‌داند.
تصمیم واقعی: ترکیب هر سه ابزار منطقی‌تر از انتخاب یکی است. Copilot برای autocomplete روزمره، Cursor برای pair programming با visual feedback، Claude Code برای batch operations و scripted tasks در CI/CD.
ساخت ایجنت چندمرحلهای با Claude API و الگوی multi-agent orchestration#
الگوی multi-agent orchestration با Claude 3.5 Haiku به‌عنوان router ارزان و Claude 3.5 Sonnet به‌عنوان worker، هزینهی API را به‌طور محسوس کاهش میدهد. این الگو در پروژههای واقعی بارها تکرار شده و در کلاس‌های آموزشی، دانش‌پذیرانی که از همان ابتدا فقط Sonnet استفاده می‌کنند، با قبض‌های غافلگیرکننده مواجه می‌شوند.
معماری router-worker ساده است: یک مدل کوچک و ارزان (Haiku) تسک را طبقهبندی میکند، سپس یک مدل قوی‌تر (Sonnet) تسک را اجرا میکند. اگر تسک ساده است، Haiku خودش جواب میدهد و هزینهی Sonnet صرف نمی‌شود.
Function Calling در Claude API به شما اجازه میدهد toolها را تعریف کنید و خروجی را parse کنید. Structured Output با XML tags در system prompt، JSON valid را تضمین میکند — بدون retry.
اتصال به LangChain برای orchestration چندمرحلهای، الگوی رایج در پروژههای اعضای کامیونیتی است. LangChain state management بین مراحل را handle میکند و شما فقط promptها را تعریف می‌کنید.
مدل‌سازی هزینه: هر مرحلهی router با Haiku به‌مراتب ارزان‌تر از Sonnet است. در یک workflow 5 مرحله‌ای که فقط 2 مرحله نیاز به Sonnet دارند، صرفه‌جویی محسوس است.
MCP چیست و چطور ابزارهای خارجی را به Claude Code وصل کنم؟#
Model Context Protocol (MCP) یک پروتکل استاندارد برای اتصال ابزارهای خارجی به مدل‌های Claude است که توسط Anthropic معرفی شده و به Claude Code اجازه میدهد با database، API و سرویس‌های بیرونی تعامل کند. به‌جای اینکه مدل خودش SQL بنویسید و شما اجرا کنید، مدل از طریق MCP مستقیماً query می‌زند و نتیجه را در context می‌گیرد.
مثال‌های عملی شامل اتصال به PostgreSQL، filesystem server و web scraping است. نصب MCP Server در Claude Code از طریق تنظیمات پروژه انجام میشود.
ساخت MCP Server سفارشی برای ابزار داخلی تیم، یکی از الگوهای تکرارشونده در پروژههای واقعی است. اگر یک API internal دارید که مدل باید با آن کار کند، یک MCP Server کوچک می‌نویسید و به Claude Code وصل می‌کنید.
محدودیتهای امنیتی در production جدی‌اند. MCP Server با دسترسی read/write به database، اگر در context نامناسبی باشد، می‌تواند داده حساس را در پاسخ مدل قرار دهد. در production حتماً scopeبندی دسترسی را محدود کنید.
هزینهی واقعی Claude: اشتراک Pro، Max یا API؟#
هزینهی واقعی Claude به الگوی استفاده بستگی دارد. برای توسعه‌دهنده‌ی فردی، اشتراک Claude Pro کافی است؛ اما تیمهای توسعه‌ای که workflow خودکار و ایجنت چندمرحلهای دارند، باید هزینهی API را بر اساس token consumption مدل‌سازی کنند. مقایسه‌ی قیمت اشتراک با API بدون در نظر گرفتن volume، گمراه‌کننده است.
Claude Pro برای استفاده‌ی تعاملی روزمره مناسب است. Claude Max برای کاربرانی که حجم بالایی استفاده دارند و محدودیت rate limit برایشان مشکل‌ساز است.
مدل هزینهی API به‌صورت مجزا روی input tokens و output tokens محاسبه میشود. این یعنی یک request با context بزرگ (مثلاً 100K توکن فایل) حتی اگر خروجی کوتاه باشد، گران است.
بهینه‌سازی هزینه: Haiku برای router، Sonnet برای worker، Opus فقط برای تسکهای بحرانی که عمق استدلال می‌خواهند. این الگوی سه‌لایه در پروژههای واقعی بارها تکرار شده و مؤثر است.
اشتباه رایج: اگر روزانه 50 request با context 50K توکن دارید، هزینهی API ممکن است از اشتراک بیشتر باشد. اما اگر workflow خودکار دارید که اشتراک محدودش میکند، API تنها گزینه است.
جمع‌بندی عملی: از کجا شروع کنم؟#
شروع عملی با Claude Code سه قدم دارد: اول نوشتن CLAUDE.md، دوم context pruning با exclude فایلهای irrelevant، سوم human-in-the-loop در PRها. به‌جای اینکه مدل مستقیم commit کند، از او بخواهید patch پیشنهاد دهد و شما review کنید. بدون این سه، خروجی «قابل استفاده» باقی می‌ماند و به «قابل اعتماد در production» نمی‌رسد.
آموزش Claude برای کار حرفهای، یک مهارت واحد نیست. ترکیب پرامپتنویسی XML، مدیریت context، و طراحی معماری ایجنت است. هر سه با هم، خروجی را از «قابل استفاده» به «قابل اعتماد در production» تبدیل میکند.
اگر می‌خواهید این الگوها را در پروژه‌ی واقعی پیاده کنید و سوال‌هایتان را با کسانی که همین مسیر را رفته‌اند مطرح کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول را بررسی کنید. 53 جلسه با تمرکز روی Vibe Coding و ساخت ایجنت بدون کدنویسی سنگین.
دیدگاه‌ها
برای گذاشتن دیدگاه وارد شو
دیدگاه‌ها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.