مهارت اصلی کار حرفهای با Claude Code پرامپتنویسی نیست. Context Engineering (مهندسی زمینه) و درک لحظهی مداخله در چرخهی ایجنتی plan→execute→verify، دو چیزیاند که خروجی را از «کد کار میکند» به «معماری درست است» تغییر میدهند. این آموزش Claude Code بر پایهی همین دو ستون بنا شده — بدون مقدمهچینی، مستقیم به اصل.
Claude Code یک چتبات نیست: چرخهی ایجنتی plan → execute → verify#
چرخهی ایجنتی Claude Code سه مرحله دارد: برنامهریزی (plan)، اجرای کد و خواندن فایلها (execute)، و خودسنجی (verify). کاربر باید در مرحلهی plan مداخله کند تا خروجی بهسوی کیفیت برود، نه بعد از اجرای کد. اگر plan را بدون بازبینی بپذیرید، گامهای بعدی روی همان اشتباه سوار میشوند.
تفاوت بنیادین با چتبات در همین چرخه است. چتبات یک ورودی → یک خروجی میدهد. Claude Code ورودی را میگیرد و چندین گام خودکار با بازخورد اجرا میکند.
برای شروع، با دستور npm install -g @anthropic-ai/claude-code نصبش کنید و در ریشهی پروژه دستور claude را اجرا کنید. Node.js نسخه 18 به بالا و حساب Anthropic با اشتراک فعال پیشنیاز است.
یک مثال واقعی: فرض کنید میخواهید یک باگ در فایل TypeScript اصلاح کنید. Claude Code ابتدا فایلهای مرتبط را اسکن میکند (plan)، سپس تغییرات را اعمال میکند (execute)، و بعد با اجرای تستها صحت کار را میسنجد (verify). اگر در plan نگویید «فقط فایل utils.ts را لمس کن»، ممکن است سه فایل دیگر را هم تغییر دهد.
الگوی Pair Programmer نه Autonomous Agent: چرا کل پروژه را یکجا ندهید#
Claude Code در حالت پیشفرض خودش تصمیم میگیرد کدام فایلها را بخواند و تغییر دهد. اگر پروژه بزرگ است و شما بدون محدودیت درخواست بدهید، چرخهی execute روی فایلهایی میرود که اصلاً نباید دست بخورند. الگوی صحیح: در plan مشخص کنید دقیقاً کدام فایلها در محدودهی تغییر هستند.
محدودیتهای عملی چرخه: latency چند ثانیهای هر step و تأثیر آن بر workflow#
هر مرحله از چرخه — خواندن فایل، اجرای دستور، نوشتن پاسخ — چند ثانیه طول میکشد. اگر یک وظیفه نیاز به 10 بار تکرار دارد، زمان کل ممکن است از نوشتن دستی بیشتر شود. این محدودیت را در انتخاب وظایف جدی بگیرید.
Context Engineering بهجای Prompt Engineering: نقش CLAUDE.md#
در کار حرفهای با Claude Code، نحوهی ساختاردهی فایلها و ارائهی زمینهی پروژه — بهویژه فایل CLAUDE.md در ریشه — تعیینکنندهتر از جادوی پرامپت است. این فایل در شروع هر session خوانده میشود و نقش System Prompt محلی را بازی میکند.
ساختار پیشنهادی CLAUDE.md شامل چهار بخش است:
- معماری پروژه: چه فریمورکی، چه ساختار پوشهای، چه الگوی معماری (مثلاً Clean Architecture یا MVC).
- قوانین کدنویسی: نامگذاری، style guide، محدودیتهای فنی که باید رعایت شوند.
- دستورات build و test: دقیقاً چه دستوری برای build اجرا شود، چه دستوری برای test.
- محدودیتهای شناختهشده: فایلهایی که نباید تغییر کنند، وابستگیهایی که آپدیتشان خطرناک است.
پنجره بافت (Context Window) Claude 3.7 Sonnet برابر 200K توکن است. در پروژههای بزرگ، استراتژی file targeting و exclude patterns ضروریاند. بدون آن، Claude Code در انبوه فایلها گم میشود و context بیارزش مصرف میکند.
اشتباه رایج: کپی کردن کل README در CLAUDE.md. این کار context را اشباع میکند بدون ارزش افزوده. README برای انسان نوشته شده؛ CLAUDE.md باید برای ماشین بهینه باشد — مختصر، ساختارمند، و فقط شامل اطلاعاتی که Claude Code در هر session به آن نیاز دارد.
پروژههای monorepo و بیش از 1000 فایل: چرا Claude Code بدون exclude pattern فلج میشود#
در monorepo، Claude Code بهطور پیشفرض تمام فایلها را اسکن میکند. اگر exclude pattern تنظیم نکنید، زمان plan بهشدت بالا میرود و خروجی بیکیفیت میشود چون مدل در انبوه context گم میشود. فایلهای node_modules، build output و فایلهای binary را حتماً exclude کنید.
نقش Projects در Claude.ai برای کار با نسخه وب (نه CLI)#
Projects در Claude.ai برای فضای چت وب است، نه برای Claude Code CLI. System Prompt در Projects تنظیم میشود و بین sessionها ذخیره میشود. اما CLAUDE.md یک فایل فیزیکی در ریشهی پروژه است که فقط Claude Code (CLI) آن را میخواند. این دو جایگزین هم نیستند؛ مکمل هماند.
Claude Code یا Cursor، کدام برای جریان کار شما مناسبتر است؟#
Claude Code یک ایجنت خطفرمانی (CLI Agent) است که فایلسیستم را مستقیم میخواند و دستورات shell اجرا میکند. Cursor یک IDE مبتنی بر AI است که درون محیط ویرایشگر کار میکند. انتخاب بین آنها به نوع وظیفه و سطح خودمختاری مورد نیاز بستگی دارد.
| معیار | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| نوع تعامل | CLI / ایجنتی | GUI / IDE | GUI / inline suggestion |
| دسترسی به فایلسیستم | مستقیم و کامل | محدود به workspace | محدود به فایل باز |
| اجرای shell command | بله، native | با plugin | خیر |
| بهترین کاربرد | refactoring چندفایلی، نوشتن تست، کار با پروژهی global | ویرایش سریع درونفایل، autocomplete هوشمند | suggestion خطبهخط بدون ایجنت |
| سطح خودمختاری | بالا (ایجنت کامل) | متوسط (agent mode + chat) | پایین (تکخطی) |
تفاوت بنیادین در معماری است: Claude Code به فایلسیستم و terminal دسترسی دارد. Copilot و Cursor درون ویرایشگر محدود هستند. اگر وظیفهتان نیاز به اجرای تست، تغییر چند فایل همزمان، یا فهم ساختار global پروژه دارد، Claude Code ابزار درستتری است.
چهزمانی Claude Code گزینهی اشتباهی است؟#
Claude Code برای تکاسکریپتهای bash ساده، پروژههایی با build system بسیار پیچیده (مثل Bazel)، و وظایفی که latency ایجنتی چند ثانیهایشان از صرفهجویی زمانی بیشتر است، ابزار نادرستی است. sweet spot آن پروژههای متوسط با چندین فایل مرتبط است.
سه حالتی که نباید سراغ Claude Code بروید:
- تکاسکریپت کوچک: نوشتن یک تابع helper با 10 خط کد. overhead ایجنتی بیدلیل است. خودتان سریعتر مینویسید.
- Build system پیچیده: Bazel، Buck و monorepoهای بزرگ با graph وابستگی عمیق. Claude Code در فهم این ساختارها محدود است و ممکن است فایلهای اشتباهی را تغییر دهد.
- وظایف حساس به latency: وقتی هر step چند ثانیه طول میکشد و شما 20 بار تکرار میکنید، زمان کل از نوشتن دستی بیشتر میشود.
نکتهی امنیتی: Claude Code به کل فایلسیستم دسترسی دارد. اگر پروژه شامل فایلهای حساس (API key، credential) است، این یک ریسک است نه یک باگ. قبل از اجرای Claude Code، فایلهای حساس را از scope خارج کنید.
الگوی تصمیمگیری: یک flowchart ساده برای انتخاب ابزار#
سؤال اول: آیا وظیفه بیش از 3 فایل را درگیر میکند؟ اگر بله → Claude Code. اگر نه → آیا نیاز به اجرای shell command دارد؟ اگر بله → Claude Code. اگر نه → Cursor یا Copilot کافیاند. این سه سؤال، بخش عمدهای از تصمیمها را حل میکنند.
هزینهی واقعی Claude Max در برابر API per-token برای توسعهدهندهی تماموقت#
برای توسعهدهندهای که روزانه 6 تا 8 ساعت با Claude Code کار میکند، اشتراک Claude Max در مقایسه با پرداخت per-token از API صرفهی اقتصادی قابلتوجهی دارد. اما برای استفادهی پراکنده و سبک، API مقرونبهصرفهتر است.
سطوح اشتراک Pro و Max از نظر حجم استفاده متفاوتاند. برای اعداد دقیق به صفحهی pricing Anthropic مراجعه کنید، چون این اعداد مرتب تغییر میکنند. مدل هزینهی API بر اساس per-token pricing کار میکند — توکنهای ورودی و خروجی قیمت متفاوت دارند.
نکتهی پنهان که در مقایسهی ساده دیده نمیشود: Claude Code در حالت اشتراک از مدلهای Opus و Sonnet استفاده میکند و شما کنترل کمتری روی مدل دارید. در API، مدل را خودتان انتخاب میکنید و میتوانید برای کارهای ساده Haiku بگذارید. این یعنی در API، هزینهی هر وظیفه قابل بهینهسازی است.
استراتژی ترکیبی: Max برای کار روزانه + API برای ایجنتهای خودکار#
اگر همزمان با Claude Code کار میکنید و ایجنتهای خودکار (مثلاً با n8n) دارید، بهترین استراتژی ترکیبی است: اشتراک Max برای کار تعاملی روزانه، و API با انتخاب مدل مناسب برای ایجنتهای خودکار. اینطور هم هزینه کنترل میشود، هم مدل برای هر وظیفه بهینه انتخاب میشود.
MCP: پل اتصال Claude Code به ابزارهای خارجی#
Model Context Protocol (MCP) پروتکل متنبازی است که Anthropic معرفی کرد. ساخت یک MCP Server ساده — مثلاً اتصال به دیتابیس داخلی پروژه — Claude Code را از یک code generator به یک workflow tool کامل تبدیل میکند.

مفهوم MCP: پروتکل استاندارد برای اتصال مدلهای زبانی به ابزارهای خارجی مثل Database، API و File System. بدون MCP، Claude Code فقط فایلسیستم محلی را میخواند و دستورات shell اجرا میکند. با MCP، میتواند کوئری بزند، به APIها وصل شود و workflowهای پیچیده بسازد.
نصب MCP Server با دستور claude mcp add در تنظیمات Claude Code انجام میشود. یک مثال عملی: ساخت MCP Server برای اتصال به PostgreSQL داخلی پروژه. با این کار، Claude Code میتواند schema دیتابیس را بخواند و migrationهای درست بنویسد.
مهم: MCP فقط مخصوص Claude نیست. OpenAI نیز از آن پشتیبانی میکند. این یعنی اگر امروز MCP Server بسازید، با تغییر ابزار، آن server قابل استفاده است.
امنیت MCP: چقدر دسترسی به ابزارهای خارجی امن است؟#
MCP Server به ابزارهای خارجی دسترسی میدهد. اگر دسترسی دیتابیس یا API key را بدون محدودیت به MCP Server بدهید، Claude Code عملاً هر کاری میتواند با آن ابزارها انجام دهد. اصل minimum privilege را رعایت کنید: فقط دسترسیهایی که واقعاً لازماند.
اشتباهات رایج که خروجی Claude Code را بیکیفیت میکنند#
بیشتر خروجیهای ضعیف Claude Code نه از ضعف مدل، بلکه از سه اشتباه کاربر میآید: ندادن context کافی، مداخله نکردن در مرحلهی plan، و استفادهی از مدل اشتباه برای نوع وظیفه.
پنج اشتباهی که در پروژههای اعضای کامیونیتی بارها تکرار شده:
- پرامپت مبهم بدون ذکر فایلها و محدودیتها. Claude Code فایلسیستم را میخواند ولی نمیداند کدام بخش مرتبط است. نتیجه: تغییرات در فایلهای اشتباه.
- اجازه دادن به چرخهی execute بدون بازبینی plan. نتیجه: کد کار میکند ولی معماری غلط است. بعداً باید همه را بازنویسی کنید.
- استفاده از مدل اشتباه. Haiku برای وظایف پیچیده کیفیت را خراب میکند؛ Opus برای کارهای ساده هزینه را بالا میبرد.
- CLAUDE.md خالی یا کپی README. context بیارزش، context مضر است. مدل را گیج میکند.
- نادیده گرفتن محدودیتهای محیط واقعی. مثلاً انتظار اینکه Claude Code بدون MCP به دیتابیس وصل شود.
اگر این الگوها برایت آشناست و میخواهی مسیر درست را با ساختار مشخص طی کنی، کامیونیتی Claude اسکول از جعبهابزار تا پروژهی Vibe Coding را مرحلهبهمرحله پوشش میدهد.
مدلهای Claude برای وظایف مختلف: Haiku vs Sonnet vs Opus#
Claude 3.7 Sonnet اولین مدل hybrid reasoning Anthropic است که بین پاسخ سریع و تفکر عمیق سوئیچ میکند. برای refactoring، debugging پیچیده و کارهای معماری مناسب است. Claude 3.5 Haiku سبک و سریع است و برای کارهای روتین مثل نوشتن تستهای ساده، lint fix و توضیح کد کافی است. Opus برای وظایف تحلیلی عمیقتر است.
اگر تازه با Claude Code شروع کردهاید و میخواهید بدون کدنویسی ایدهتان را به محصول تبدیل کنید، دورهی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول مسیر ساختارمندی دارد. اگر هم ایجنت و اتوماسیون با n8n در کارتان هست، دورهی «ساخت Ai Agent با N8N» در کامیونیتی N8N اسکول همان چرخهی plan→execute→verify را در بستر workflow نشان میدهد.







دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.