کار حرفهای با کلود و کلود کد سه ستون اصلی دارد: تنظیم context، ساختاردهی به CLAUDE.md و تفکیک تسک‌ها به subagentها. بدون این سه، Claude Code به یک chatbot گران‌قیمت تبدیل میشود که مدام context را آلوده میکند و خروجی بی‌کیفیت تولید میکند. این مقاله الگوهای عملی هر سه ستون را از پروژه‌های واقعی استخراج کرده است.
Claude Code چیست و چرا با Cursor فرق دارد؟#
Claude Code یک ایجنت (AI Agent) ترمینال‌محور است که به filesystem، bash و git دسترسی مستقیم دارد و خودش فایلها را باز و ویرایش میکند. در Cursor شما فایل را در IDE می‌بینید و مدل پیشنهاد میدهد؛ این تفاوت در مدل تعامل، هزینه و سرعت کار را کاملاً عوض میکند.
Anthropic این ابزار را به‌عنوان یک research preview منتشر کرد. تفاوت بنیادین با IDE محورهای موجود در این است که Claude Code خودش تصمیم می‌گیرد کدام فایل را بخواند، کدام دستور را اجرا کند و کدام تغییر را اعمال نماید. شما دستور می‌دهید، ایجنت عمل میکند.
مدل تعامل: پیشنهاد در برابر اجرا#
در Cursor، مدل یک پیشنهاد diff تولید میکند و شما آن را accept یا reject میکنید. در Claude Code، مدل خودش فایل را ویرایش میکند و شما نتیجه‌ی نهایی را در filesystem می‌بینید. این یعنی feedback loop متفاوتی دارید: در Cursor قبل از اجرا review میکنید، در Claude Code بعد از اجرا review میکنید.
این تفاوت کوچک نیست. در پروژه‌هایی که فایلهای زیادی دارند، Claude Code میتواند چند فایل را همزمان بخواند و تغییرات هماهنگ بین آن‌ها اعمال کند. Cursor این کار را نمی‌کند چون هر پیشنهاد محدود به یک فایل یا یک selection است.
چه زمانی Claude Code توجیه‌پذیر نیست؟#
اگر فقط یک اسکریپت bash تک‌خطی می‌نویسید یا یک فایل config را ویرایش میکنید، overhead نصب و مصرف توکن Claude Code توجیه اقتصادی ندارد. این ابزار برای کارهای چندفایلی، refactoringهای گسترده و تسک‌هایی که نیاز به خواندن context دارند طراحی شده است.
الگوی مشاهده‌شده در پروژه‌های کامیونیتی: توسعه‌دهندگانی که از Cursor به Claude Code مهاجرت کرده‌اند، کاهش زمان context switching را گزارش می‌دهند اما افزایش مصرف توکن را نیز تجربه می‌کنند. این trade-off را باید آگاهانه بپذیرید.
| معیار | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| مدل تعامل | اجرایی مستقل در ترمینال | پیشنهاد در IDE | پیشنهاد در IDE |
| دسترسی به filesystem | مستقیم و کامل | محدود به فایل فعال | محدود به فایل فعال |
| مدیریت context | ایجنت خودش تصمیم می‌گیرد | کاربر فایلها را attach میکند | کاربر فایلها را attach میکند |
| مناسب برای | refactoring چندفایلی، taskهای پیچیده | ویرایش سریع، autocomplete | autocomplete، تولید کد ساده |
| هزینهی نسبی | بالا (مصرف توکن زیاد) | متوسط | پایین |
CLAUDE.md را چطور بنویسیم که واقعاً مؤثر باشد؟#
CLAUDE.md فایل حافظه‌ی پروژه است که فقط در root پروژه یا مسیر global (~/.claude/CLAUDE.md) خوانده میشود. مؤثرترین ساختار آن شامل سه بخش است: forbidden patterns (الگوهای ممنوعه)، command references دقیق برای build/test/deploy، و conventions پروژه‌ای که در README نیست.
اشتباه رایج اول: قرار دادن CLAUDE.md در زیرپوشه‌ها. این فایل فقط در root پروژه و مسیر global خوانده میشود. اگر آن را در src/ یا packages/ بگذارید، نادیده گرفته میشود و شما فکر میکنید مدل به دستورات شما گوش میدهد.
ساختار سه‌بخشی مؤثر#
بخش اول: forbidden patterns. این‌ها الگوهایی هستند که مدل نباید تولید کند. مثال واقعی: «هرگز از var در جاوااسکریپت استفاده نکن»، «هرگز فایلهای .env را ویرایش نکن»، «هرگز dependency جدید بدون تأیید اضافه نکن». این بخش بیشترین تأثیر را بر کاهش خطاهای تکراری دارد.
بخش دوم: command references. دستورات دقیق build، test، lint و deploy را بنویسید. مدل این دستورات را در workflow خودش استفاده میکند. اگر بنویسید «npm run build»، مدل دقیقاً همان را اجرا میکند. اگر بنویسید «پروژه را build کنید»، مدل باید حدس بزند.
بخش سوم: conventions. توافقاتی که در README نیست: الگوی نام‌گذاری فایلها، ساختار پوشه‌ها، نوع state management مورد استفاده، الگوی error handling. این بخش مدل را از guess و check نجات میدهد.
گام‌به‌گام نوشتن CLAUDE.md مؤثر#
- ابتدا forbidden patterns را از خطاهای تکراری گذشته استخراج کنید. هر بار که مدل اشتباهی تکرار کرد، آن را به این بخش اضافه کنید.
- دستورات build، test و lint را دقیقاً از package.json یا Makefile کپی کنید. paraphrase نکنید.
- conventions پروژه را بنویسید. سؤال کلیدی: «اگر یک توسعه‌دهنده‌ی جدید وارد شود، چه چیزی را باید بداند که در README نیست؟»
- با یک task واقعی تست کنید. یک تسک ساده بدهید و ببینید آیا مدل به forbidden patterns احترام می‌گذارد و دستورات را درست اجرا میکند.
الگوی مشاهده‌شده در پروژه‌های کامیونیتی: فایلهای CLAUDE.md که صرفاً توضیح پروژه هستند، تأثیر ناچیزی بر کیفیت خروجی دارند. اما فایلهای ساختاریافته با forbidden patterns، خطاهای تکراری را بهطور محسوسی کاهش می‌دهند. تفاوت این است که «این پروژه یک API است» به مدل چیزی نمی‌آموزد، اما «هرگز endpoint بدون auth middleware تعریف نکن» مستقیماً جلوی یک خطای امنیتی را می‌گیرد.
مدیریت context و پیشگیری از context rot#
مدل «هرچه context بیشتر، نتیجه بهتر» غلط است. context rot (افت کیفیت در contextهای طولانی) در Claude واقعی است. حرفه‌ای‌ها بهجای context stuffing (پرکردن context با فایلهای بیربط)، از استراتژی context surgery استفاده می‌کنند: پاککردن context با /clear و reload هوشمند.
Context window در مدل‌های پیشرفته‌ی Claude معمولاً بسیار بزرگ (مثلاً 200K توکن و بیشتر) است، اما این یعنی context stuffing بی‌حد و مرز نیست. کیفیت پاسخ در contextهای پر از اطلاعات بیربط افت میکند. مدل نمی‌تواند همه‌ی توکن‌ها را با یک وزن پردازش کند.
Context surgery: استراتژی عملی#
context surgery یعنی: قبل از شروع هر تسک جدید، context را با /clear پاک کنید. سپس فقط فایلهای مرتبط با تسک فعلی را reload کنید. این الگو در آموزش‌های عمومی تقریباً وجود ندارد، اما در پروژه‌های بزرگ توسط توسعه‌دهندگان حرفهای به‌عنوان راه‌حل عملی برای حفظ کیفیت و کاهش هزینه استفاده میشود.
نکته‌ی مهم: توصیه‌ی «کل کدبیس را paste کنید» باعث context overflow و هزینهی بیهوده میشود. Claude Code بهصورت agentic فایلها را جداگانه می‌خواند. شما نیازی ندارید همه‌چیز را در context بگذارید. مدل خودش فایلهای مورد نیاز را باز میکند.
مقایسه‌ی استراتژی‌های context management#
| استراتژی | هزینه | کیفیت خروجی | پیچیدگی |
|---|---|---|---|
| Context stuffing (پرکردن با همه فایلها) | بسیار بالا | افت کیفیت در context طولانی | کم |
| Context surgery (/clear + reload هوشمند) | متوسط | ثابت و قابل‌پیش‌بینی | متوسط |
| Subagent delegation (تفکیک به ایجنت‌های مستقل) | پایین‌تر برای هر تسک | بالا (context محدود و مرتبط) | بالا |
برای درک عمیق‌تر این الگوها، اصول پرامپت‌نویسی پیشرفته و معماری ایجنت‌های هوش مصنوعی را بررسی کنید.
ساخت ایجنت چندمرحله‌ای با Subagentها#
Subagent یک الگوی delegation در Claude Code است که برای تسکهای بزرگ استفاده میشود. هر subagent context مستقل دارد و میتواند بخشی از کار را انجام دهد بدون اینکه context اصلی را آلوده کند. این الگو عملاً در آموزش‌های موجود پوشش داده نشده است.
تفاوت subagent با یک session ساده: session یک گفتگوی معمولی است که context آن به‌تدریج پر میشود. subagent یک تسک مستقل است که context محدود و مشخصی دارد و نتیجه‌اش به session اصلی برمی‌گردد.
الگوی task decomposition#
تسک بزرگ را به subtaskها بشکنید. هر subtask را به یک subagent با context مستقل اختصاص دهید. مثال واقعی: یک subagent برای نوشتن test، یک subagent برای refactor، و یک subagent برای review. هر کدام فقط فایلهای مربوط به خودش را می‌خواند.
الگوی مشاهده‌شده در پروژه‌های کامیونیتی: استفاده از subagentها برای جلوگیری از context rot در تسکهای چندمرحله‌ای، کیفیت خروجی را نسبت به یک session طولانی بهبود میدهد. دلیلش ساده است: هر subagent context محدودی دارد، پس مدل با دقت بیشتری روی آن تمرکز میکند.
گام‌به‌گام پیاده‌سازی اولین subagent workflow#
- تعریف تسک: تسک بزرگ را به ۲ تا ۴ subtask مستقل بشکنید. هر subtask باید ورودی و خروجی مشخص داشته باشد.
- تخصیص context: برای هر subtask، فقط فایلهای مرتبط را مشخص کنید. subagent نباید به کل کدبیس دسترسی داشته باشد.
- تجمیع نتایج: بعد از اتمام همه‌ی subagentها، نتایج را در session اصلی جمع کنید و یک review نهایی انجام دهید.
Hook System و خودکارسازی workflow#
Hook System در Claude Code امکان خودکارسازی workflow را فراهم میکند. این سیستم میتواند lint-on-save، auto-format قبل از commit، و اجرای تست‌ها را بهصورت خودکار انجام دهد. این الگو در آموزش‌های فارسی‌زبان تقریباً پوشش داده نشده است.
هوک‌ها نقاط اتصال خودکار در workflow هستند. شما تعریف میکنید «وقتی این اتفاق افتاد، این کار را بکن». مدل بعد از هر ویرایش فایل، hook مربوطه را اجرا میکند.
سه هوک کاربردی#
- lint-on-save: بعد از هر ویرایش فایل، linter اجرا میشود. اگر خطایی پیدا کرد، مدل خودش آن را اصلاح میکند. این hook زمان debug را بهطور محسوسی کاهش میدهد.
- pre-commit format: قبل از commit، formatter اجرا میشود. کد همیشه در فرمت استاندارد پروژه باقی می‌ماند و reviewهای بیربط درباره‌ی formatting حذف می‌شوند.
- post-edit test: بعد از ویرایش یک فایل، تست‌های مرتبط اجرا می‌شوند. اگر تست fail شد، مدل متوجه میشود تغییرش مشکل‌ساز بوده و اصلاح میکند.
نکته‌ی امنیتی: هوک‌ها را در محیط development تست کنید. یک hook که بهطور خودکار دستور bash اجرا میکند، اگر اشتباه تنظیم شود، میتواند در محیط production رفتار غیرمنتظره داشته باشد. هوک‌ها را اول در یک sandbox ساده فعال کنید و رفتارشان را monitor کنید.
MCP Server را چطور به Claude Code وصل کنیم؟#
Model Context Protocol (MCP) یک استاندارد باز است که Anthropic در نوامبر 2024 معرفی کرد و امکان اتصال مدل‌های هوش مصنوعی به ابزارها و منابع داده‌ی خارجی را فراهم میکند. اتصال یک MCP Server به Claude Code امکان دسترسی به دیتابیس، APIها و ابزارهای تخصصی را ایجاد میکند.
MCP را می‌توان مثل USB برای ایجنت‌ها تصور کرد. هر دستگاهی که درایور USB داشته باشد، به کامپیوتر وصل میشود. هر ابزاری که MCP Server داشته باشد، به Claude Code وصل میشود.
گام‌به‌گام اتصال اولین MCP Server#
- نصب: MCP Server مورد نظر را نصب کنید. برای مثال، یک server که به دیتابیس PostgreSQL وصل میشود.
- تنظیم: در تنظیمات Claude Code، آدرس و پیکربندی server را اضافه کنید. نحوه‌ی دقیق تنظیم را از مستندات رسمی Anthropic بررسی کنید.
- تعریف ابزار: مشخص کنید کدام ابزارهای این server در دسترس Claude Code باشند. همه‌ی ابزارها را فعال نکنید.
- تست: یک query ساده بفرستید و مطمئن شوید server درست جواب میدهد.
نکته‌ی کالایی‌ستیز: استفاده از MCP فقط زمانی منطقی است که واقعاً به داده‌ی خارجی نیاز دارید. برای کارهای ساده‌ی کدنویسی که همه‌چیز در filesystem است، MCP overhead اضافه ایجاد میکند. اگر مدل میتواند فایل را مستقیم بخواند، نیازی به server واسط نیست.
Permission Modes و امنیت در محیط تولید#
Claude Code سه permission mode دارد: default، acceptEdits و bypassPermissions. استفاده از bypassPermissions بدون دلیل، ریسک امنیتی جدی دارد و بعضی آموزش‌ها آن را به‌عنوان «راحت‌ترین حالت» معرفی می‌کنند. در محیط تولید، فقط از default یا acceptEdits استفاده کنید.
موضع متخصصان امنیتی: استفاده از permission modes نامناسب، یکی از رایج‌ترین خطاهای امنیتی در ابزارهای ایجنتی است. یک ایجنت که بدون اجازه هر فایلی را ویرایش میکند، میتواند به داده‌های حساس دسترسی پیدا کند یا تغییرات مخرب اعمال کند.
| Mode | سطح دسترسی | ریسک امنیتی | مناسب برای |
|---|---|---|---|
| default | هر عملیات نیاز به تأیید دارد | پایین | محیط production، پروژه‌های حساس |
| acceptEdits | ویرایش فایلها خودکار، دستورات bash نیاز به تأیید | متوسط | توسعه‌ی روزمره با اعتماد نسبی |
| bypassPermissions | همه‌چیز خودکار، بدون تأیید | بالا | فقط sandbox و تست |
الگوی پیشنهادی: اعتماد تدریجی#
با default mode شروع کنید. وقتی اعتمادتان به مدل در یک پروژه بالا رفت، به acceptEdits تغییر دهید. bypassPermissions را فقط در محیط‌هایی استفاده کنید که اگر خراب شد، هیچ خسارتی ندارد. بعضی آموزش‌ها bypassPermissions را توصیه می‌کنند تا workflow را «ساده» جلوه دهند، اما این توصیه در پروژه‌های واقعی خطرناک است.
Claude Code برای چه پروژه‌هایی مناسب نیست؟#
Claude Code برای پروژه‌های کوچک overhead بی‌دلیل دارد. برای اسکریپت‌های تک‌خطی، ویرایش‌های یک‌بار مصرف، و پروژه‌هایی که نیاز به دسترسی مستقیم به GUI دارند، مناسب نیست. شناخت این مرزها، هزینه و زمان را نجات میدهد.
الگوی مشاهده‌شده در پروژه‌های کامیونیتی: توسعه‌دهندگانی که Claude Code را برای پروژه‌های خیلی کوچک استفاده کرده‌اند، گزارش داده‌اند که زمان setup بیشتر از زمان خود کار بوده است. این ابزار برای پروژه‌هایی با چندین فایل و نیاز به خواندن context طراحی شده، نه برای یک اسکریپت ۲۰ خطی.
۵ نشانه که پروژه‌تان برای Claude Code مناسب نیست#
- پروژه کمتر از چند ده فایل دارد و همه‌چیز در یک یا دو فایل جا میشود.
- تسک شما یک ویرایش ساده در یک فایل config است.
- نیاز به تعامل با GUI دارید (مثلاً تنظیمات یک اپلیکیشن دسکتاپ).
- پروژه build/test pipeline مشخصی ندارد و مدل نمی‌تواند تغییراتش را validate کند.
- budget توکن شما محدود است و نمی‌خواهید overhead خواندن فایلها را بپردازید.
پیش‌نیازهای عملی#
Claude Code به Node.js، دسترسی به terminal و یک پروژه با ساختار مشخص نیاز دارد. اگر این سه را ندارید، اول آن‌ها را فراهم کنید. نصب ابزار بدون این پیش‌نیازها فقط شما را در یک workflow شکسته قرار میدهد.
جمع‌بندی عملی: Claude Code ابزاری قدرتمند است، اما فقط اگر سه ستون آن را درست تنظیم کنید — context را بهجای stuffing با surgery مدیریت کنید، CLAUDE.md را با forbidden patterns بسازید، و تسکهای پیچیده را به subagentها تفکیک کنید. بدون این سه، ابزار به یک chatbot گران‌قیمت تبدیل میشود.
اگر می‌خواهید این الگوها را بهصورت عملی تمرین کنید و روی پروژه‌های واقعی بازخورد بگیرید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول این مسیر را با تمرین‌های ساختاریافته پوشش میدهد.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.