آموزش Claude Code فقط یادگیری دستورات ترمینال نیست. این ابزار یک سیستم با بودجه‌ی محدود توکن است که هر ابزار فراخوانی‌شده از آن کم میکند. تمام پیکربندی — از CLAUDE.md گرفته تا Hooks و Subagentها — باید حول این مدل مصرف طراحی شود، نه حول «خروجی خوب بگیریم». کسی که این تفاوت را درک کند، هزینه‌هایش قابل پیش‌بینی میشود و ایجنتش رفتار قابل‌اعتمادی دارد.
چه کاری در ترمینال انجام می‌دهد که رابط وب نمی‌تواند؟#
آموزش Claude Code یعنی درک اینکه این ابزار در ترمینال حلقه‌ی اجرا (execution loop) می‌سازد — می‌خواند، می‌نویسد، تست می‌گیرد، خطا را می‌بیند، اصلاح میکند — درحالی‌که رابط وب فقط متن تولید میکند و متوقف میشود. تفاوت این دو، تفاوت بین «گفتن کد» و «انجام دادن کار» است.
Claude Code به فایلسیستم، ترمینال و ابزارهای خارجی دسترسی مستقیم دارد. commit میکند، npm install اجرا میکند، خروجی تست را می‌خواند و تصمیم بعدی را خودش می‌گیرد. رابط وب هیچکدام از این‌ها را نمی‌کند.
نصب و پیش‌نیازها#
Claude Code روی macOS و Linux بهصورت native اجرا میشود. برای Windows، WSL (Windows Subsystem for Linux) رایجترین مسیر است. پیش‌نیاز اصلی، Node.js و دسترسی به ترمینال. مجوزهای دسترسی به فایلسیستم را از همان ابتدا محدود کنید؛ ایجنتی که بدون اجازه فایلهای حساس را بخواند، مشکل امنیتیاش از مشکل کاراییاش بزرگ‌تر است.
تفاوت بنیادین: execution loop در برابر text generation#
وقتی در رابط وب می‌پرسید «این تابع را بنویس»، مدل فقط متن برمی‌گرداند. در Claude Code، ایجنت خودش فایل را می‌خواند، کد را می‌نویسد، تست اجرا میکند، خطا را می‌بیند، اصلاح میکند و دوباره تست می‌گیرد. حلقه‌ی اجرا دقیقاً همان چیزی است که رابط وب از آن محروم است — نه به‌خاطر محدودیت مدل، بلکه به‌خاطر نبود دسترسی به محیط اجرا.
ریسک‌های امنیتی: دسترسی به فایلسیستم و sandboxing#
ایجنت با دسترسی به فایلسیستم می‌تواند فایلهای ناخواسته را بخواند یا تغییر دهد. الگوی مشاهده‌شده در پروژههای واقعی: قبل از شروع session، scope دسترسی را محدود کنید. برای پروژه‌هایی که secret یا credential دارند، جداسازی محیطی (sandboxing) نه یک توصیه‌ی اختیاری، بلکه یک پیش‌شرط است.
چرا رابط وب برای کارهای چندمرحلهای شکست می‌خورد#
در رابط وب، هر بار که context از دست برود، باید از نو توضیح دهید. در Claude Code، ایجنت خودش فایل‌ها را می‌خواند و state را حفظ میکند. برای taskهایی که بیش از سه مرحله دارند، این تفاوت تعیین‌کننده است — نه کمّی، بلکه کیفی.
مدل context budget: چرا مدیریت توکن مهمتر از پر کردن فضا است#
مدل context budget یعنی هر tool call، هر فایل خوانده‌شده و هر reasoning step از بودجه‌ی توکن کم میکند. مدیریت context یعنی تصمیم‌گیری درباره‌ی اینکه چه چیزی را وارد آن کنیم — نه اینکه چقدر می‌توانیم جا بدهیم. این تفاوت بین «ظرف ثابت» و «بودجه‌ی قابل‌مصرف» است.
context window یک ظرف ثابت نیست که باید پرش کنید. یک بودجه است. هر بار که ایجنت فایلی می‌خواند، هر بار که دستوری اجرا میکند، بخشی از این بودجه تمام میشود. کسی که این را درک نکند، در میانه‌ی session با context پر مواجه میشود و مجبور به restart می‌گردد.
تفاوت مدل مصرف در Claude Code و رابط وب#
در رابط وب، مصرف توکن بر اساس طول متن ورودی و خروجی محاسبه میشود. در Claude Code، هر فراخوانی ابزار — خواندن فایل، اجرای دستور، نوشتن فایل — توکن مصرف میکند. یک session با ده tool call ساده می‌تواند بیشتر از یک پرامپت متنی طولانی هزینه داشته باشد.
الگوی افشای تدریجی (progressive disclosure): global → module → file#
به‌جای اینکه همه‌چیز را در یک فایل بزرگ بنویسید، قوانین را لایه‌بندی کنید. ایجنت بسته به scope task، فقط لایه‌ی مربوطه را می‌خواند. این الگو از هدررفت context جلوگیری میکند.
- Global rules: قوانینی که برای کل پروژه صادق‌اند — style guide، naming conventions، forbidden patterns.
- Module-specific: قوانین مخصوص هر module — مثلاً قوانین API design فقط در پوشه‌ی routes.
- File-level: توضیحات مختصر درباره‌ی فایلهای پیچیده — فقط اگر ایجنت واقعاً به آن نیاز داشته باشد.
اشتباه رایج: «کل codebase را در یک پرامپت بگذارید»#
این الگو در پروژههای واقعی مکرراً دیده شده و تقریباً همیشه شکست می‌خورد. ایجنت context را با اطلاعات غیرمرتبط پر میکند، از بین فایلهای بی‌ربط سردرگم میشود، و بودجه‌ی توکن بی‌دلیل تمام میشود. نتیجه: کیفیت خروجی افت میکند و هزینه بالا می‌رود. بدتر از بی‌فایده بودن، مضر بودنش است — چون ایجنت را به سمت پاسخ‌های سطحی هل می‌دهد.
استراتژی‌های عملی برای پروژههای بزرگ#
سه تکنیک که در پروژههای واقعی جواب داده:
- Chunking: task را به قطعات کوچک تقسیم کنید و هر بار فقط فایلهای مرتبط را بخوانید.
- Selective reading: از ایجنت بخواهید اول فقط directory structure را ببیند، بعد فایلهای خاص را باز کند.
- Summarization: برای فایلهای بزرگ، خلاصه بنویسید و در CLAUDE.md قرار دهید تا ایجنت مجبور نباشد کل فایل را بخواند.
CLAUDE.md را چطور بنویسم که واقعاً رفتار ایجنت را تغییر بدهد؟#
CLAUDE.md یک قرارداد رفتاری (behavioral contract) است که مثل code review checklist نوشته میشود: قوانین مشخص، محدودیت‌های صریح، و الگوهای اجباری. اگر به شکل README نوشته شود، ایجنت آن را بهعنوان context عمومی می‌خواند نه دستورالعمل — و رفتارش عوض نمی‌شود.
تفاوت این دو فرمت، تفاوت بین «اطلاعات» و «دستور» است. README به ایجنت میگوید پروژه چیست. CLAUDE.md به ایجنت میگوید چطور رفتار کند.
قبل و بعد: README-style در برابر behavioral contract#
README-style: «این پروژه یک اپلیکیشن React است که از TypeScript و Tailwind استفاده میکند.» ایجنت این را می‌خواند ولی رفتارش عوض نمی‌شود.
Behavioral contract: «هر کامپوننت جدید باید prop types را بهصورت interface جداگانه تعریف کند. از any استفاده نکنید. هر فایل باید حداقل یک export default داشته باشد.» این دستورالعمل قابل‌اجراست و ایجنت را مجبور به رعایت میکند.
لایه‌بندی قوانین#
قوانین global را در ریشه بنویسید. قوانین module-specific را در فایل CLAUDE.md داخل همان پوشه قرار دهید. ایجنت هنگام کار با آن module، فایل مربوطه را هم می‌خواند. این الگو از تکرار جلوگیری میکند و context را بهینه نگه می‌دارد.
چه چیزهایی نباید در CLAUDE.md بنویسید#
- مستندسازی انسانی: توضیح پروژه برای تیم، توضیح تاریخچه، changelog.
- اطلاعاتی که ایجنت خودش از فایل‌ها می‌خواند: ساختار پروژه، لیست dependencies.
- قوانین مبهم: «کد تمیز بنویس»، «بهینه عمل کن». این‌ها قابل‌اجرا نیستند و فقط توکن مصرف میکنند.
الگوی مشاهده‌شده در پروژههای واقعی#
در پروژه‌هایی که اعضای کامیونیتی گزارش داده‌اند، مؤثرترین CLAUDE.mdها کوتاه، قابل‌اجرا و بدون ابهام‌اند. هر قانون باید طوری نوشته شود که ایجنت بتواند در یک جمله بگوید «رعایت کردم» یا «نکردم». اگر قانون نیاز به تفسیر دارد، آن را بازنویسی کنید — نه با توضیح بیشتر، بلکه با محدود کردن دامنه.
Claude Code در برابر Cursor، Copilot و Windsurf: مقایسه‌ی عملی#
Claude Code در برابر Cursor، Copilot و Windsurf یک رده‌بندی ندارد؛ هر کدام برای نوع taskی بهینه است. Claude Code برای کارهای چندمرحلهای با دسترسی به ترمینال و فایلسیستم طراحی شده. Cursor برای IDE experience، Copilot برای autocomplete، و Windsurf برای flow بین‌رابطی. انتخاب ابزار به طول و پیچیدگی task بستگی دارد نه به «بهترین بودن».
مقایسه‌ی این ابزارها مثل مقایسه‌ی آچار و پیچ‌گوشتی است. هر دو ابزار هستند، ولی هر کدام برای کار خاصی ساخته شده‌اند.
جدول مقایسه‌ای: سناریو، ابزار مناسب، دلیل انتخاب#
| سناریو | ابزار مناسب | دلیل |
|---|---|---|
| Refactoring چندفایلی | Claude Code | نیاز به خواندن و نوشتن همزمان چند فایل + اجرای تست |
| نوشتن یک تابع ساده | Copilot یا Cursor | overhead Claude Code توجیه ندارد |
| Debug با اجرای تست | Claude Code | فقط این ابزار می‌تواند تست اجرا کند و خروجی را بخواند |
| ساخت پروژه از صفر | Claude Code یا Cursor | بسته به نیاز به terminal access |
سناریوی refactoring چندفایلی: Claude Code برنده است#
وقتی باید یک interface را عوض کنید و ده فایل مصرف‌کننده را اصلاح کنید، Claude Code خودش فایل‌ها را پیدا میکند، تغییر می‌دهد و تست اجرا میکند. در Cursor یا Copilot باید دستی هر فایل را باز کنید و تغییر دهید. اینجا overhead Claude Code نه‌تنها توجیه دارد، بلکه تفاوت بین یک کار ده‌دقیقه‌ای و یک کار دو‌ساعته است.
سناریوی نوشتن یک تابع ساده: Copilot یا Cursor سریع‌ترند#
برای یک تابع ده خطی، راه‌اندازی session در Claude Code و خواندن context زمان‌برتر از خود task است. در این موارد، autocomplete در IDE کار را زودتر تمام میکند. اصرار بر استفاده از Claude Code برای این taskها، ابزار را بهعنوان مشکل‌ساز جا می‌زند.
سناریوی debug با اجرای تست: فقط Claude Code می‌تواند#
وقتی تست fail میشود و باید خطا را تحلیل کنید، ایجنت خودش تست را اجرا میکند، خروجی را می‌خواند، کد را اصلاح میکند و دوباره تست می‌گیرد. هیچکدام از ابزارهای دیگر این حلقه را بهصورت خودکار انجام نمی‌دهند. این تنها سناریویی است که Claude Code واقعاً بی‌رقیب است.
Hooks: CI/CD محلی قبل از هر commit#
Hooks نقاط اتصال pre/post execution هستند که قبل از commit یا بعد از تولید کد اجرا می‌شوند. استفاده‌ی درست از آن‌ها lint، test و security scan است — نه فقط فرمت‌دهی کد. hookی که فقط prettier اجرا کند، ارزش تنظیم کردن ندارد.
تصور کنید هر بار که ایجنت کد می‌نویسد، یک بازرس بی‌چشم‌پوشش جلوی در ایستاده باشد و اجازه ندهد کد بی‌کیفیت وارد repo شود. این دقیقاً کاری است که Hooks انجام می‌دهند.
انواع hook#
- Pre-commit: قبل از commit اجرا میشود. lint و test در این مرحله بهترین جایگاه را دارند.
- Post-edit: بعد از هر ویرایش فایل. می‌تواند برای فرمت‌دهی خودکار یا اجرای سریع type-check استفاده شود.
- Pre-push: قبل از push به remote. جایگاه security scan و testهای سنگین‌تر.
الگوی «quality gate»#
هدف این است که کد بی‌کیفیت اصلاً وارد repo نشود. hook باید طوری تنظیم شود که اگر test fail شد، commit انجام نشود. ایجنت مجبور میشود خطا را اصلاح کند و دوباره امتحان کند. این الگو در پروژههای واقعی، باگ‌های ارسالی به production را به‌طور محسوسی کاهش داده است.
نمونه‌ی عملی: اجرای test suite قبل از commit#
یک hook ساده: «هر بار که ایجنت می‌خواهد commit کند، ابتدا npm test اجرا شود. اگر exit code غیرصفر بود، commit انجام نشود و ایجنت خطا را ببیند.» یک خط تنظیمات، ولی کیفیت کد را تغییر می‌دهد.
اشتباه رایج: hook فقط برای prettier#
بسیاری از کاربران، hook را فقط برای فرمت‌دهی کد تنظیم میکنند. prettier باگ نمی‌گیرد. lint و test باگ می‌گیرند. اگر وقت دارید فقط یک hook بگذارید، آن را برای test suite تنظیم کنید نه برای فرمت‌دهی. این اشتباه، هزینه‌ی تنظیم hook را بی‌فایده میکند.
Subagent کی لازم است و کی هزینه‌ی اضافی می‌سازد؟#
Subagent برای delegation موازی کارهای مستقل مفید است. اما الگوی شکست رایج «همه چیز را subagent کردن» است. اگر task وابستگی ترتیبی دارد یا context مشترک لازم است، در همان context بمانید. ساخت subagent برای کار ترتیبی، نه‌تنها مفید نیست، بلکه continuity را از بین می‌برد.
Subagent مثل یک کارمند پاره‌وقت است: وقتی چند کار مستقل دارید که همزمان باید انجام شوند، به‌کارش می‌گیرید. وقتی کارها به هم وابسته‌اند، خودش مزاحمت است.
مکانیزم Subagent#
Subagent یک context جداگانه می‌گیرد، کارش را انجام می‌دهد، و فقط خروجی خلاصه‌شده را به parent برمی‌گرداند. این یعنی parent context آلوده نمی‌شود به جزئیات کار subagent. اما هر subagent خودش توکن مصرف میکند — و این مصرف، اضافه بر parent است نه جایگزین آن.
چه زمانی بسازیم#
وقتی چند کار مستقل دارید که همزمان می‌توانند انجام شوند. مثال: بررسی سه module مختلف برای پیدا کردن الگوهای تکراری. هر module را به یک subagent بدهید و نتایج را aggregate کنید.
چه زمانی نسازیم#
وقتی task ترتیبی است. مثلاً: اول schema را عوض کن، بعد migration بنویس، بعد testها را اصلاح کن. این‌ها به context مشترک نیاز دارند. subagent کردن آن‌ها یعنی از دست دادن continuity و ایجاد وابستگی‌های مصنوعی بین خروجی‌ها.
الگوی orchestration#
در پروژههای واقعی، مؤثرترین الگو این است: parent فقط orchestration میکند (تقسیم کار، جمع‌بندی نتیجه) و subagentها کار واقعی را انجام می‌دهند. parent نباید خودش کد بنویسد؛ باید فقط بگوید «چه کسی، چه کاری، چه خروجی‌ای برگرداند». این تفکیک نقش، کیفیت خروجی را بالا می‌برد.
MCP و اتصال Claude Code به ابزارهای خارجی#
MCP (Model Context Protocol) یک استاندارد باز برای اتصال مدل‌های زبانی به ابزارها و منابع خارجی است. با MCP، Claude Code به دیتابیس، APIهای داخلی و سرویس‌های DevOps وصل میشود. بدون MCP، ایجنت فقط فایلسیستم و ترمینال دارد.
MCP چیست و چه مشکلی را حل میکند#
بدون MCP، ایجنت فقط فایلسیستم و ترمینال دارد. با MCP، می‌تواند query بنویسد، API تست کند، deployment trigger کند. MCP یک protocol لایه‌ی ارتباطی است — نه plugin درون‌برنامه‌ای.
نمونه‌های server#
- Database query: ایجنت مستقیم SQL اجرا کند و نتیجه را در context ببیند.
- API testing: endpointها را تست کند و response را تحلیل.
- Deployment tools: staging را deploy کند و وضعیت را چک.
تفاوت MCP با pluginهای سنتی#
Plugin درون‌برنامه‌ای است و به یک ابزار خاص وابسته. MCP یک protocol مستقل است — هر ابزاری که protocol را پیاده‌سازی کند، با هر مدل زبانی کار میکند. این یعنی serverی که برای Claude Code می‌نویسید، احتمالاً با ابزارهای دیگر هم سازگار خواهد بود.
محدودیت‌ها و ملاحظات امنیتی#
اتصال به ابزارهای خارجی یعنی سطح حمله بیشتر. قبل از نوشتن MCP server، بررسی کنید که چه دسترسی‌هایی به ایجنت می‌دهید. مستندات رسمی Anthropic و نمونه‌های open-source موجود در GitHub نقطه‌ی شروع خوبی هستند. نیازمند راستی‌آزمایی است که آیا server شما واقعاً به کمترین دسترسی ممکن محدود شده یا نه.
چه زمانی Claude Code ابزار اشتباهی است؟#
برای کارهای تک‌مرحله‌ای ساده، refactoring یک فایل کوچک، یا زمانی که فقط یک خط کد نیاز دارید، overhead نصب و context setup توجیه ندارد. در این موارد API مستقیم یا IDE plugin بهتر است. اصرار بر استفاده از Claude Code برای taskهای زیر سه مرحله، ابزار را بدنام میکند.
سناریوهای شکست#
- Task زیر سه مرحله: setup بیشتر از خود کار زمان می‌برد.
- فایلهای کوچک: ایجنت context می‌خواند که لازم نیست.
- نیاز به autocomplete: سرعت IDE plugin غیرقابل‌مقایسه است.
چه زمانی API مستقیم بهتر است#
برای production integration، latency-sensitive tasks و batch processing، API مستقیم کنترل بیشتری می‌دهد. Claude Code برای workflow توسعه است نه برای production runtime.
تصمیم واقعی: یک پروژهی ۲۰۰ خطی که با Claude Code بازسازی‌اش گران‌تر از نوشتن مجدد بود#
در یک پروژهی واقعی، کاربری تصمیم گرفت یک utility file دویست خطی را با Claude Code refactor کند. سه session لازم شد، هر کدام context setup داشت، و هزینه‌ی توکن بیشتر از زمان نوشتن مجدد شد. درس: اگر task را در پنج دقیقه دستی انجام می‌دهید، Claude Code ابزار اشتباهی است.
معیار تصمیم‌گیری#
قبل از شروع، این سؤال را بپرسید: «چند tool call لازم دارم؟» اگر جواب زیر سه است، احتمالاً setup توجیه ندارد. اگر بالای ده است، Claude Code ابزار درست است. این معیار ساده، از بسیاری از بحث‌های بی‌پایان درباره‌ی «بهترین ابزار» مؤثرتر است.
هزینه‌ی واقعی: مدل مصرف token در Claude Code#
مدل مصرف توکن در Claude Code بر اساس تعداد و نوع tool calls محاسبه میشود نه صرفاً طول متن ورودی و خروجی. یک session با ده tool call می‌تواند بیشتر از یک پرامپت متنی طولانی در رابط وب هزینه داشته باشد.
این تفاوت مدل مصرف، دلیلی است که بسیاری از کاربران تازه‌کار در پایان ماه با قبضی مواجه می‌شوند که انتظارش را ندارند.
چرا مدل مصرف با رابط وب فرق دارد#
در رابط وب، شما یک بار input می‌دهید و یک بار output می‌گیرید. در Claude Code، ایجنت بارها فایل می‌خواند، دستور اجرا میکند، نتیجه را تحلیل میکند و دوباره اقدام میکند. هر یک از این مراحل توکن مصرف میکند.
عوامل مؤثر بر هزینه#
| عامل | تأثیر | راه کاهش |
|---|---|---|
| تعداد فایلهای خوانده‌شده | مستقیم با توکن مصرفی | Selective reading |
| طول output | هر خط کد نوشته‌شده توکن است | دستورالعمل‌های مختصر |
| تعداد iterations | هر retry هزینه دارد | CLAUDE.md دقیق + Hooks |
| انتخاب مدل | Opus گران‌تر از Sonnet | فقط برای reasoning پیچیده |
استراتژی کاهش هزینه#
سه اهرم اصلی:
- Context management: هرچه کمتر بخوانید، کمتر مصرف میکنید. progressive disclosure اینجا نجات‌دهنده است.
- Hook design: اگر hook جلوی یک retry را بگیرد، یک session کامل را نجات می‌دهد.
- انتخاب مدل: Sonnet برای کارهای معمولی کدنویسی، refactoring و debugging کافی است. Opus را فقط برای reasoning پیچیده و taskهای چندمرحلهای نگه دارید.
اشتباه هزینه‌دار: Opus برای همه‌چیز#
Opus برای reasoning پیچیده و taskهای چندمرحلهای قوی‌تر است اما هزینه‌ی بالاتری دارد. Sonnet برای بخش عمده‌ی کارهای کدنویسی کافی است و سرعت و هزینه‌ی مناسب‌تری ارائه می‌دهد. استفاده از Opus برای یک تابع ساده، پول سوزاندن است — نه سرمایه‌گذاری.
جمع‌بندی: مدل ذهنی درست، ابزار را عوض میکند#
آموزش Claude Code بدون درک context budget، فقط یادگیری دستورات است. با درک این مدل، هر تصمیم — از نوشتن CLAUDE.md تا انتخاب مدل و تنظیم hook — حول یک سؤال واحد شکل می‌گیرد: «این کار چقدر از بودجه‌ی توکن من را مصرف میکند و آیا ارزشش را دارد؟»
اگر می‌خواهید این مدل ذهنی را در پروژههای واقعی تمرین کنید و از تجربه‌ی دیگران یاد بگیرید، دوره‌ی آفلاین «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین کار را میکند — نه آموزش ابزار، بلکه ساختن طرز فکر درست در برابرش.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.