Claude را می‌توان از سه مسیر به‌کار برد، ولی اکثر کاربران ایرانی بدون تفکیک این سه مسیر وارد کار می‌شوند. نتیجه‌اش روشن است: هزینه‌ی بی‌مورد، خروجی ناسازگار با ساختار پروژه، و ناامیدی از ابزاری که واقعاً قدرتمند است. این آموزش، سه سطح استفاده (چت، Claude Code، API) را از هم جدا می‌کند، الگوهای میدانی مثل First Read Then Write و فایل CLAUDE.md را توضیح می‌دهد، و فرمول ساده‌ای برای مقایسه‌ی هزینه‌ی اشتراک و API ارائه می‌دهد.

سه سطح استفاده از Claude: چت، Claude Code و API — کدام برای چه کاری؟#

سه سطح استفاده از Claude هر کدام معماری و کاربرد کاملاً متفاوتی دارند. چت Claude برای ایده‌پردازی و بحث مفهومی ساخته شده، Claude Code یک ایجنت ترمینال‌محور (Terminal-based Agent) است که مستقیماً فایل‌سیستم را می‌خواند و دستور اجرا می‌کند، و API برای ساخت ایجنت‌های خودکار و یکپارچه‌سازی در محصول به‌کار می‌رود. اشتباه رایج این است که این سه را یک ابزار واحد با سه ظاهر بدانند.

بسیاری از کاربران تازه‌وارد، Claude Code را یک IDE هوشمند یا تکمیل خودکار (Autocomplete) پیشرفته تصور می‌کنند. این تصور، پرهزینه‌ترین اشتباه ورودی است — نه فقط به‌خاطر توکن‌های تلف‌شده، بلکه به‌خاطر اینکه مدل را در حالتی استفاده می‌کنند که برای آن بهینه نشده.

هر سه سطح، معماری متفاوتی دارند و برای کارهای متفاوتی ساخته شده‌اند.

الگوی First Read, Then Write در Claude Code — چرا خواندن قبل از نوشتن، پرهزینه‌ترین اشتباه را حذف می‌کند#

الگوی First Read, Then Write یعنی قبل از هر دستور تغییر فایل، ابتدا بگذارید Claude Code ساختار واقعی پروژه را بخواند، سپس در حالت برنامه‌ریزی (Plan Mode) طرح تغییر را بنویسد، و در نهایت با تأیید شما تغییرات اعمال شوند. بدون این الگو، مدل بر اساس حدس عمل می‌کند و خروجی‌اش ناسازگار با ساختار واقعی پروژه است.

Claude Code در حالت پیش‌فرض، فایل‌سیستم پروژه را نمی‌شناسد. اگر بدون خواندن، دستور تغییر فایل بدهید، مدل از روی الگوهای عمومی کدنویسی حدس می‌زند — و حدس‌زدن، دقیقاً همان چیزی است که باگ‌های بازگشتی تولید می‌کند.

این الگو در پروژه‌های اعضای کامیونیتی اسکول بارها تکرار شده و نتیجه‌اش یکسان است: کاهش باگ‌های بازگشتی و کاهش توکن مصرفی. دلیلش ساده است — وقتی مدل ساختار واقعی فایل‌ها را می‌خواند، context دقیق‌تری دارد و نیازی به تکرار و اصلاح نیست.

فایل CLAUDE.md به‌عنوان حافظه بلندمدت پروژه#

فایل CLAUDE.md یک فایل متنی در ریشه‌ی پروژه است که قوانین، استایل کد، ساختار پوشه‌ها و هر context ثابت دیگری را در خود نگه می‌دارد. Claude Code در ابتدای هر نشست کاری (Session) این فایل را می‌خواند و بر اساس آن عمل می‌کند. بدون آن، هر نشست از صفر شروع می‌شود.

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

محتوای پیشنهادی CLAUDE.md: ساختار پوشه‌ها، قوانین استایل کد (مثلاً TypeScript strict mode، نام‌گذاری camelCase)، دستورات build و test، و محدودیت‌های پروژه (مثلاً «این فایل را تغییر نده»). هرچه این فایل دقیق‌تر باشد، رفتار Claude Code قابل‌پیش‌بینی‌تر می‌شود.

پیش‌نیازها و راه‌اندازی عملی Claude Code#

پیش‌نیازهای راه‌اندازی Claude Code سه چیزند: Node.js نسخه LTS، یک API Key از کنسول Anthropic یا اشتراک Pro/Max، و یک ترمینال با دسترسی به پوشه‌ی پروژه. نصب از طریق npm انجام می‌شود و اولین نشست با اجرای دستور claude در ریشه‌ی پروژه شروع می‌شود.

مراحل نصب و اولین session#

مراحل نصب و راه‌اندازی Claude Code از صفر تا اولین تعامل، پنج گام مشخص دارد که هر کدام جای خطای خودش را دارد.

  1. Node.js نسخه LTS را نصب کنید (از سایت رسمی nodejs.org).
  2. از طریق npm، ابزار Claude Code را نصب کنید.
  3. API Key خود را از کنسول Anthropic دریافت کنید یا اشتراک Pro/Max را فعال کنید.
  4. در ترمینال، به پوشه‌ی پروژه بروید و دستور claude را اجرا کنید.
  5. اولین نشست را با یک تسک ساده شروع کنید: «فایل‌های این پوشه را بخوان و ساختار پروژه را خلاصه کن.»

نکته‌ی مهم: اگر از داخل IDE استفاده می‌کنید، ترمینال داخلی IDE هم کار می‌کند ولی ترمینال مستقل (مثل Terminal در macOS یا Windows Terminal) تجربه‌ی بهتری می‌دهد.

Plan Mode چگونه کار می‌کند و چرا قبل از هر تغییر فایل باید فعال باشد#

حالت برنامه‌ریزی (Plan Mode) در Claude Code به‌جای اجرای مستقیم، ابتدا برنامه‌ی تغییر را پیشنهاد می‌دهد. شما می‌خوانید، اصلاح می‌کنید و سپس تأیید می‌دهید. این حالت، حلقه‌ی تأیید انسانی (Human-in-the-Loop) را در چرخه‌ی کار حفظ می‌کند و از تغییرات ناخواسته جلوگیری می‌کند. قبل از هر تغییر فایل، فعال‌بودن Plan Mode نه یک توصیه، یک ضرورت است.

تفاوت دسترسی با اشتراک Pro و Max در مقابل API Key مستقیم: اشتراک Pro دسترسی محدودتری به مدل‌ها و نشست‌ها دارد، در حالی که Max سقف بالاتری برای استفاده‌ی سنگین روزانه فراهم می‌کند. API Key مستقیم، هر توکن را جداگانه محاسبه می‌کند و سقف ماهانه ندارد، ولی برای استفاده‌ی روزانه‌ی مکرر، معمولاً گران‌تر تمام می‌شود.

هزینه واقعی: اشتراک Max یا API Pay-as-you-go؟#

هزینه‌ی واقعی Claude Code به الگوی استفاده‌تان بستگی دارد، نه به قیمت اسمی. برای استفاده‌ی مکرر روزانه (چند ساعت در روز)، اشتراک Claude Max با قیمت ماهانه ثابت معمولاً به‌صرفه‌تر است. برای استفاده‌ی پراکنده یا حجم تولیدی بالا، API با Prompt Caching هزینه‌ی هر توکن ورودی تکراری را به‌شدت کاهش می‌دهد. تصمیم‌گیری بر اساس عدد، نه بر اساس حدس.

Prompt Caching در API — چگونه context ثابت را کش می‌کند#

Prompt Caching مکانیزمی است که در API ارائه می‌شود و بخش ثابت prompt — مثل فایل CLAUDE.md، توضیحات پروژه یا دستورالعمل‌های تکراری — را در حافظه نگه می‌دارد. در نشست‌های بعدی، این بخش دوباره پردازش نمی‌شود و هزینه‌ی توکن‌های آن به‌طور قابل‌توجهی کاهش می‌یابد.

اگر از API مستقیم استفاده می‌کنید و context ثابت دارید، Prompt Caching را فعال کنید. بدون آن، هر request تمام context را از نو می‌خواند و هزینه‌ی توکن ورودی بالا می‌رود.

انتخاب مدل: Sonnet، Opus یا Haiku#

انتخاب مدل Claude بر اساس پیچیدگی تسک، نه بر اساس «قوی‌تر بهتر است» انجام می‌شود. Claude 3.5 Sonnet برای اکثر تسک‌های کدنویسی تعادل بهتری بین سرعت و کیفیت دارد. Claude Opus برای تسک‌های تحلیلی پیچیده‌تر مثل طراحی معماری، دیباگ عمیق یا refactor ساختاری مناسب‌تر است ولی کندتر و گران‌تر عمل می‌کند. Claude Haiku برای تسک‌های ساده و سریع که فقط نیاز به تولید کد روتین دارند، کم‌هزینه‌ترین گزینه است.

فرمول ساده‌ی محاسبه: تعداد نشست در روز × میانگین توکن مصرفی هر نشست × نرخ API در برابر قیمت اشتراک ماهانه. اگر این عدد از قیمت اشتراک بیشتر می‌شود، اشتراک بخرید. اگر کمتر است، API با Prompt Caching ارزان‌تر تمام می‌شود.

Claude Code در برابر Cursor، Copilot، Windsurf و Aider#

Claude Code در برابر Cursor، Copilot، Windsurf و Aider، تنها ابزار ترمینال‌محور با دسترسی کامل به فایل‌سیستم و اجرای دستور است. Cursor و Copilot در IDE کار می‌کنند و بیشتر بر تکمیل خودکار تمرکز دارند. Aider هم ترمینال‌محور است ولی اکوسیستم ابزار و MCP را ندارد. انتخاب ابزار بستگی به نوع کاری دارد که انجام می‌دهید، نه به محبوبیت.

ابزارمعماریدسترسی فایل‌سیستماجرای shellپشتیبانی MCPمدل‌های پشتیبانی‌شده
Claude CodeAgent ترمینال‌محورکامل (خواندن و نوشتن)بلهبلهمدل‌های Anthropic
CursorIDE هوشمنداز طریق editorمحدود (terminal داخلی)بلهچند مدل (Anthropic، OpenAI و...)
GitHub CopilotPlugin در IDEمحدود (فایل باز)خیرخیرمدل‌های Microsoft/OpenAI
AiderCLI ترمینال‌محورکاملبلهخیرچند مدل (Anthropic، OpenAI و...)
WindsurfIDE هوشمنداز طریق editorمحدودبلهچند مدل

چه چیزی Claude Code را از Aider متمایز می‌کند: استفاده از ابزار (Tool Use) بومی — یعنی ابزارهای داخلی مثل خواندن فایل، نوشتن فایل و اجرای دستور به‌صورت native در مدل پیاده‌سازی شده‌اند — به‌علاوه‌ی Plan Mode و یکپارچگی با اکوسیستم Anthropic. Aider ساده‌تر است ولی این قابلیت‌ها را ندارد.

چه زمانی Cursor یا Copilot انتخاب بهتری است: وقتی تکمیل خودکار لحظه‌ای در IDE می‌خواهید، پروژه‌ی کوچک است و نیاز به اجرای shell command ندارید، یا تیم شما از GitHub Copilot Chat استفاده می‌کند. بسیاری از توسعه‌دهندگان Claude Code و Cursor را هم‌زمان استفاده می‌کنند — هر کدام برای بخش متفاوتی از workflow.

MCP و اتصال Claude Code به ابزارهای خارجی#

MCP (Model Context Protocol) یک پروتکل ارتباطی باز است که Claude Code را به دیتابیس، APIهای داخلی و هر سرویس دیگری وصل می‌کند. این کار با Prompt Engineering معمولی قابل انجام نیست، چون MCP یک contract مشخص بین مدل و ابزار تعریف می‌کند.

نوشتن یک MCP Server محلی#

نوشتن یک MCP Server محلی برای Claude Code، کاری است که به‌جای کپی‌پیست داده بین ابزارها، دسترسی مستقیم مدل به منابع خارجی را ممکن می‌کند. یک MCP Server می‌تواند به Node.js یا Python نوشته شود. ساختار کلی: یک فایل server که ابزارها (Tools) و منابع (Resources) را تعریف می‌کند، سپس در تنظیمات Claude Code ثبت می‌شود. پس از ثبت، مدل می‌تواند در طول نشست به دیتابیس داخلی شما کوئری بزند یا از API داخلی اطلاعات بخواند.

این الگو در پروژه‌های واقعی اعضای کامیونیتی اسکول دیده شده: اتصال به دیتابیس Postgres برای خواندن schema، یا اتصال به API داخلی برای گرفتن داده‌ی config. نتیجه: Claude Code بدون نیاز به کپی‌پیست دستی، مستقیماً به داده دسترسی پیدا می‌کند.

چرا MCP یک «پلاگین» نیست#

چرا MCP را نباید با یک plugin اختصاصی اشتباه گرفت؟ چون MCP یک پروتکل مستقل با contract مشخص است، نه یک افزونه‌ی بسته. یعنی هر ابزاری که MCP را پیاده‌سازی کند — Claude Code، Cursor، Windsurf و بقیه — می‌تواند از همان Server استفاده کند. این یعنی یک MCP Server که امروز برای Claude Code می‌نویسید، فردا در ابزار دیگری هم کار می‌کند.

اشتباهات رایج و الگوی صحیح شکستن تسک#

اشتباهات رایج در استفاده از Claude Code یک الگوی مشترک دارند: بزرگ‌دیدن تسک و کوچک‌دیدن context. پرهزینه‌ترین این اشتباهات، دادن یک تسک بزرگ یکجا (Mega Prompt) است. الگوی صحیح: شکستن به تسک‌های اتمی (Atomic Tasks)، استفاده از Plan Mode قبل از نوشتن، و گرفتن بازخورد بین هر مرحله. این الگو هم کیفیت خروجی را بالا می‌برد و هم هزینه‌ی توکن را کاهش می‌دهد.

اشتباه اول: Mega Prompt — یک دستور 10 خطی که همه‌چیز را یکجا می‌خواهد. نتیجه: خروجی ضعیف، هزینه‌ی بالا، و عدم قابلیت دیباگ. اگر خروجی اشتباه باشد، نمی‌دانید کدام بخش از prompt علت خطا بوده.

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

اشتباه سوم: فرض کردن دسترسی به اینترنت — Claude Code در حالت پیش‌فرض به اینترنت دسترسی ندارد. اگر انتظار دارید از یک API خارجی اطلاعات بگیرد، باید از طریق MCP یا دستور مشخص، دسترسی فراهم شود.

الگوی Agent as Teammate: چند ایجنت با نقش مشخص — یکی برای نوشتن کد، یکی برای تست، یکی برای refactoring. این الگو در کامیونیتی اسکول بارها آزمایش شده و نتایج بهتری نسبت به یک ایجنت تک‌نقشی می‌دهد. هر ایجنت context کوچک‌تر و هدف مشخص‌تری دارد، پس خطای کمتری تولید می‌کند.

چه زمانی Claude Code گزینه مناسبی نیست؟#

Claude Code گزینه‌ی مناسبی نیست وقتی تسک حساس به داده است (حذف فایل، اجرای shell بدون نظارت)، پروژه نیاز به تکمیل خودکار لحظه‌ای دارد، یا پنجره‌ی زمینه (Context Window) مدل برای حجم پروژه کافی نیست. در این موارد، ابزارهای دیگر یا ترکیب چند ابزار انتخاب درست‌تری است.

محدودیت Context Window روی پروژه‌های بزرگ تأثیر مستقیم دارد. اگر پروژه‌ی شما هزاران فایل دارد، Claude Code نمی‌تواند همه را هم‌زمان در context نگه دارد. راه‌حل: تسک‌ها را محدود به یک یا چند فایل مشخص کنید و از CLAUDE.md برای خلاصه‌سازی ساختار کلی استفاده کنید.

نیاز به حلقه‌ی تأیید انسانی: حذف فایل و اجرای shell command به تأیید انسانی نیاز دارد. این باگ نیست، ویژگی ایمنی است. اگر به یک ایجنت کاملاً خودکار بدون تأیید نیاز دارید، باید لایه‌ی ایمنی خودتان را روی API بسازید.

ساخت ایجنت چندمرحله‌ای با Tool Use و Agentic Loop#

ایجنت چندمرحله‌ای (Multi-step Agent) با Claude از طریق Tool Use و حلقه‌ی ایجنتیک (Agentic Loop) ساخته می‌شود: مدل تصمیم می‌گیرد، ابزار را صدا می‌زند، نتیجه را می‌خواند و دوباره تصمیم می‌گیرد تا تسک کامل شود. این الگو، قلب Claude Code و Skills کلود است.

حلقه‌ی تکراری اتصال شش ابزار درون یک ایجنت چندمرحله‌ای که فرآیند تصمیم‌گیری خودکار را به‌صورت بصری نشان می‌دهد
چرخه‌ی تصمیم‌گیری ایجنت: هر مرحله ورودی مرحله‌ی بعد است

معماری Agentic Loop#

معماری Agentic Loop چهار مرحله دارد: تصمیم (مدل بر اساس context فعلی تصمیم می‌گیرد چه ابزاری صدا بزند)، اجرا (ابزار اجرا می‌شود و نتیجه برمی‌گردد)، خواندن (مدل نتیجه را در context جدید می‌خواند)، و تکرار (تا زمانی که تسک کامل شود یا به تأیید انسانی برسد).

در Claude Code، این چرخه به‌صورت بومی پیاده‌سازی شده. شما تسک را می‌دهید، مدل خودش تصمیم می‌گیرد کدام فایل را بخواند، چه دستوری اجرا کند و چه تغییری اعمال کند. ایجنت فرعی (Subagent) در این معماری، ایجنتی است که تسک فرعی را از ایجنت اصلی تحویل می‌گیرد و نتیجه را برمی‌گرداند.

Human-in-the-Loop در کجای چرخه قرار می‌گیرد#

حلقه‌ی تأیید انسانی (Human-in-the-Loop) در چرخه‌ی Agentic Loop معمولاً قبل از نوشتن فایل یا اجرای shell command قرار می‌گیرد. یعنی مدل تصمیم گرفته و برنامه‌ی اجرا را نوشته، ولی قبل از اعمال تغییرات، منتظر تأیید شما می‌ماند. این نقطه‌ی توقف، همان Plan Mode است.

مثال عملی: ایجنتی که ابتدا لاگ خطا را می‌خواند، الگوی خطا را تشخیص می‌دهد، patch پیشنهاد می‌کند و شما قبل از اعمال، patch را بررسی می‌کنید. این workflow، پرهزینه‌ترین اشتباه — اعمال patch نادرست روی production — را حذف می‌کند.

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

جمع‌بندی عملی استفاده از Claude Code در سه تصمیم خلاصه می‌شود: CLAUDE.md را از الان بنویسید، الگوی First Read Then Write را عادت کنید، و هزینه‌ی اشتراک Max را با فرمول ساده‌ی نشست × توکن × نرخ API مقایسه کنید. Claude Code یک ایجنت ترمینال‌محور است، نه تکمیل خودکار. اگر این تفاوت را درک نکنید، هیچ‌کدام از الگوهای بالا به کارتان نمی‌آید.

اگر می‌خواهید این الگوها را در پروژه‌ی واقعی تمرین کنید و از تجربه‌ی بقیه‌ی کاربران استفاده کنید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول، مسیر ساختاریافته‌ای برای یادگیری عملی و Vibe Coding بدون کدنویسی سنگین ارائه می‌دهد. این دوره در کامیونیتی Claude اسکول در دسترس است.