یادگیری Claude Code با یادگیری هر ابزار دیگری فرق دارد. اینجا مسئله‌ی نصب و پیکربندی نیست؛ مسئله‌ی اصلی جابه‌جایی مدل ذهنی است. «دستور بده، پاسخ بگیر» باید جای خود را به «معیار تعریف کن، ایجنت اجرا کند، خروجی را تأیید کن» بدهد. بدون این تغییر، حتی با نصب موفق، خروجی‌های بی‌ربط و contextهای پرشده سر از کارتان درمی‌آورد.
Claude Code در ترمینال چه چیزی است که در چت‌باکس نیست#
Claude Code در ترمینال یک ایجنت خودمختار (autonomous agent) است که در حلقهی read → think → act → verify فایل‌ها را ویرایش میکند، دستورات shell را اجرا میکند، commit ایجاد میکند و خروجی test را میخواند. چت‌باکس این حلقه را ندارد؛ فقط یک پاسخ متنی تولید و تحویل می‌دهد.
پارادایم agent-loop: چرا «چت‌بات در ترمینال» توصیف نادرستی است#
در یک چت‌باکس، سؤال می‌پرسید، پاسخ می‌گیرید، حلقه بسته میشود. تمام. در Claude Code حلقه ادامه دارد: ابزار فایل میخواند، تصمیم می‌گیرد، ویرایش میکند، test اجرا میکند، خروجی را میخواند و در صورت شکست دوباره ویرایش میکند. این حلقهی عامل (agent-loop) است — و تفاوتش با چت‌باکس تفاوت «دستیار» با «کارمند مستقل» است.
سه پیام عملی از همین تفاوت پارادایم بیرون می‌آید:
- پرامپت شما باید «معیار پذیرش» داشته باشد، نه فقط «توصیف خروجی». بدون معیار، ایجنت نمی‌داند کی کار تمام شده.
- وسط حلقه نمی‌توانید دخالت کنید مگر با interrupt. یعنی اگر اشتباهی در iteration دوم رخ دهد، تا iteration پنجم ادامه پیدا میکند.
- context window به‌سرعت پر میشود چون هر iteration توکن مصرف میکند. حلقهی چهارمرحله‌ای (read → think → act → verify) در هر دور، context بیشتری نسبت به یک پاسخ چت‌باکس مصرف میکند.
تفاوت عملی با چت‌باکس Claude: دسترسی مستقیم به فایلسیستم، اجرای shell و Git#
در چت‌باکس، کد را copy-paste می‌کنید و خودتان اجرا می‌کنید. در Claude Code، ابزار مستقیماً فایل را باز میکند، ویرایش میکند، دستور bash اجرا میکند و در صورت نیاز commit ایجاد میکند. نقش شما از «نویسنده» به «ناظر» جابه‌جا میشود. این جابه‌جایی نقش، ساده‌ترین توضیحی است که در گفتگوهای اعضای کامیونیتی مکرر برمی‌گردد.
معماری داخلی: system prompt، tool use و context window 200K توکنی#
Claude Code روی مدل‌های Claude Anthropic می‌دود و از پنجره‌ی بافت (context window) بزرگ‌تری استفاده میکند. system prompt داخلی شامل دستورالعمل‌های tool use است: خواندن فایل، نوشتن فایل، اجرای command، جست‌وجو. هر ابزار بهصورت یک function call تعریف شده و مدل تصمیم می‌گیرد کدام را صدا بزند. این معماری یعنی شما با یک API battle-facing طرف نیستید؛ با یک runtime تعامل دارید که خودش ابزار انتخاب میکند.
نصب، اولین session و اتصال به اشتراک: گام‌های عملی#
آموزش Claude Code از نصب با یک دستور npm شروع میشود؛ اتصال به اشتراک Pro/Max یا API key از طریق متغیر محیطی یا فایل پیکربندی صورت می‌گیرد. اولین session معمولاً ساده‌ترین قدم است، ولی نحوه‌ی ورود به آن تعیین میکند که آیا ابزار را درست پیکربندی کرده‌اید یا نه.
پیش‌نیازها: Node.js، دسترسی به ترمینال و یک اشتراک فعال#
قبل از نصب، به Node.js نسخه‌ی LTS نیاز دارید. همچنین باید اشتراک Claude Pro یا Max فعال داشته باشید، یا یک API key از پنل Anthropic ساخته باشید. بدون یکی از این دو، ابزار کار نمیکند. اگر روی سیستمی کار می‌کنید که proxy سازمانی دارد، قبل از نصب خروجی node -v و دسترسی به registry npm را چک کنید؛ این ساده‌ترین قدمی است که اغلب نادیده گرفته میشود و بعداً به خطاهای مبهم منجر میشود.
مراحل نصب و اولین session#
- Node.js را نصب یا آپدیت کنید.
- با
npm install -g @anthropic-ai/claude-codeابزار را نصب کنید. - در ترمینال، به پوشه‌ی پروژه‌ی خود بروید.
- دستور
claudeرا اجرا کنید. - اولین بار، ابزار شما را به صفحه‌ی احراز هویت می‌فرستد. با اشتراک یا API key وارد شوید.
- پس از ورود، با نوشتن یک درخواست ساده شروع کنید: «فایل‌های این پوشه را لیست کن و بگو پروژه چه ساختاری دارد».
در اولین session، ابزار فایلسیستم شما را میخواند و خلاصه‌ای از ساختار پروژه می‌دهد. از اینجا به بعد، هر درخواست شما یک iteration از حلقهی عامل است.
اتصال به API key در مقابل اشتراک Pro/Max: کدام برای چه کسی مناسب است#
اشتراک Pro/Max برای استفاده‌ی فردی با حجم معقول طراحی شده. API key برای محیط‌های تیمی، CI/CD و استفاده‌ی برنامه‌نویسی‌شده لازم است. اگر می‌خواهید Claude Code را در pipeline خودکار اجرا کنید، API key تنها گزینه است. انتخاب غلط اینجا پرهزینه‌تر از آن است که به‌نظر می‌رسد: کسی که با اشتراک Pro شروع میکند و بعد مجبور میشود به API key مهاجرت کند، باید پیکربندی احراز هویت را از صفر بنویسد.
مدیریت session و resume: ادامه‌ی کار در طول چند روز بدون از دست دادن context#
Claude Code sessionها را در پوشه‌ی محلی ذخیره میکند. با دستور claude --resume می‌توانید به آخرین session برگردید. برای کارهای چندروزه، این ویژگی حیاتی است چون context build شده در session قبلی را بازیابی میکند. بدون resume، هر بار باید پروژه را از صفر به مدل معرفی کنید — یعنی توکن و وقت از دست رفته.
مدیریت context window و جلوگیری از هالوسینیشن#
مدیریت context window در Claude Code یعنی محدودکردن scope هر درخواست، استفاده از --allowedTools برای فیلتر ابزارها و تجزیه‌ی کارهای بزرگ به sub-taskهای مستقل. بدون این سه لنگر، انفجار context و تولید پاسخ بی‌ربط اجتناب‌ناپذیر است.
الگوی context budgeting: هر درخواست یک محدوده‌ی مشخص داشته باشد#
مهم‌ترین اشتباه رایج، درخواست «همه‌ی پروژه را بررسی و اصلاح کن» است. این درخواست context را در چند iteration اول پر میکند و مدل در iterationهای بعدی اطلاعات قبلی را فراموش میکند. الگوی درست: هر درخواست فقط یک فایل یا یک ماژول مشخص را هدف بگیرد.
اگر پروژه‌ی شما 20 فایل دارد و می‌خواهید همه را refactor کنید، 20 درخواست جداگانه بنویسید، نه یک درخواست کلی. این الگو در پروژه‌های اعضای کامیونیتی بارها و بارها تکرار شده و هر بار نتیجه یکی بوده: scope بزرگ‌تر، کیفیت پایین‌تر.
--allowedTools و --disallowedTools: فیلتر سطح ابزار#
با این flagها مشخص می‌کنید Claude Code کدام ابزارها را مجاز دارد. مثلاً اگر فقط می‌خواهید فایل بخواند و ویرایش کند ولی shell اجرا نکند، Read و Edit را allow کنید و Bash را disallow. این هم امنیت را بالا می‌برد، هم context را تمیز نگه می‌دارد چون مدل برای ابزارهای غیرمجاز توکن مصرف نمیکند.
نشانه‌های هالوسینیشن (hallucination) در Claude Code و روش verification#
هالوسینیشن در Claude Code معمولاً به این شکل ظاهر میشود: مدل فایلی را ویرایش میکند که وجود ندارد، import یک ماژول را می‌نویسد که در پروژه نیست، یا تابعی را صدا می‌زند که تعریف نشده. راه‌حل: بعد از هر ویرایش، یک درخواست test بفرستید. اگر test شکست خورد، مدل خودش در حلقهی بعدی اصلاح میکند — به شرطی که معیار پذیرش را از اول تعریف کرده باشید.
استراتژی فشرده‌سازی: خلاصه‌سازی context بین مراحل#
وقتی context نزدیک پر شدن میشود، Claude Code خودش خلاصه‌سازی میکند. ولی شما می‌توانید دستی هم کمک کنید: بعد از اتمام یک sub-task، خلاصه‌ای از آنچه انجام شده را در یک فایل CLAUDE.md بنویسید. این فایل در هر session جدید به‌عنوان context اولیه بارگذاری میشود. این ترفند ساده، هزینهی بازسازی context را در پروژه‌های چندروزه به‌شدت کم میکند.
Claude Code یا Cursor؟ تفاوت در workflow نه در کیفیت مدل#
Claude Code یا Cursor را انتخاب کردن، تصمیم workflow است نه تصمیم مدل. Cursor برای مشاهده‌ی تغییرات قبل از اعمال و workflow تعاملی IDE ساخته شده؛ Claude Code برای اجرای خودکار چندمرحله‌ای با verification مناسب است. اگر هر دو را روی یک پروژه‌ی واقعی امتحان کرده باشید، می‌دانید که این دو ابزار اصلاً رقیب هم نیستند.
جدول مقایسه‌ی workflow-based#
| ابزار | مدل تعامل | نقطه‌ی قوت | نقطه‌ی ضعف |
|---|---|---|---|
| Claude Code | agent-loop خودمختار در ترمینال | refactoring انبوه، scaffolding، اجرای test | عدم مشاهده‌ی لحظه‌ای تغییرات |
| Cursor | تعاملی در IDE با diff view | مشاهده و کنترل هر تغییر قبل از اعمال | محدود به workflow IDE |
| GitHub Copilot | completion در خط کد | سرعت بالا برای کدهای تکراری | عدم درک ساختار کل پروژه |
| Aider | agent-loop با Git commit | سبک، متن‌باز، قابل‌شخصی‌سازی | context window کوچک‌تر |
| Windsurf | تعاملی در IDE با flow-aware | درک flow بین فایل‌ها | جدید، اکوسیستم کوچک |
الگوی hybrid: Claude Code برای scaffolding و refactoring انبوه + IDE برای logic پیچیده#
در پروژه‌های واقعی، بهترین نتیجه از ترکیب این دو می‌آید. الگوی تکرارشونده در کامیونیتی: Claude Code را برای ساخت ساختار اولیه، rename انبوه و نوشتن testهای boilerplate استفاده کنید. سپس در IDE (با Cursor یا بدون آن) logic پیچیده را دستی بنویسید. این الگو یعنی هر ابزار را در نقطه‌ی ضعف دیگری قرار دهید.
چه زمانی هر ابزار برتری دارد: سه سناریوی واقعی#
- یک ماژول با 15 فایل دارید که همه باید از callback به async/await مهاجرت کنند. Claude Code برنده است چون حلقهی ویرایش + test را خودش اجرا میکند. دستی انجام دادن این کار، ساعت‌ها وقت می‌گیرد.
- یک تابع پیچیده با logic شرطی چندلایه دارید و می‌خواهید خط‌به‌خط تغییر را ببینید. Cursor برنده است چون diff view دارد.
- پروژه از صفر شروع میشود و باید scaffolding بسازید. Claude Code برنده است چون میتواند چند فایل، package.json و config اولیه را در یک session بسازد.
MCP و گسترش Claude Code به ابزارهای خارجی#
MCP (Model Context Protocol) لایهی extensibility Claude Code است؛ بدون آن ابزار بسته باقی می‌ماند و فقط فایلسیستم محلی و shell را میشناسد. با اضافه‌کردن MCP server به database، browser یا API داخلی، Claude Code به ایجنت قابل‌توسعه تبدیل میشود.
MCP چیست و چرا بدون آن Claude Code محدود است#
MCP یک پروتکل استاندارد است که به مدل‌های زبانی اجازه می‌دهد به منابع خارجی متصل شوند. بدون MCP، Claude Code فقط فایلسیستم محلی و shell را میشناسد. با MCP server، میتواند به PostgreSQL، Notion، Slack یا هر API داخلی سازمان دسترسی پیدا کند. محدودیت بدون MCP این است که ایجنت در یک جزیره‌ی محلی زندانی میشود.
اتصال به MCP server: گام‌های پیکربندی#
برای اضافه‌کردن یک MCP server، باید یک فایل پیکربندی (معمولاً .claude/settings.json یا flag زمان اجرا) بنویسید که آدرس و روش اتصال server را مشخص کند. مستندات رسمی Anthropic بخش MCP را پوشش می‌دهد.
الگوهای رایج MCP server: database query، browser automation و API داخلی#
در پروژه‌های واقعی، سه الگوی تکرارشونده دیده میشود:
- Database query: Claude Code مستقیماً schema را میخواند و migration می‌نویسد.
- Browser automation: برای تست E2E، صفحه را باز میکند و خروجی را بررسی میکند.
- API داخلی: به سرویس‌های microservice سازمان متصل میشود و payload می‌سازد.
الگوهای پرامپت‌نویسی: از خروجی معمولی به قابل‌اتکا#
پرامپت‌نویسی مؤثر در Claude Code نه یک پرامپت جادویی واحد است، نه یک template ثابت؛ ترکیب context محدود + iteration + verification است. درخواست باید شامل محدوده‌ی فایل، معیار پذیرش و مرحله‌ی تست باشد. هر سه جزء لازم‌اند و حذف هرکدام، خروجی را بی‌ثبات میکند.
ساختار پرامپت قابل‌اتکا: scope + constraint + verification#
یک پرامپت قابل‌اتکا سه جزء دارد:
- Scope: دقیقاً بگویید کدام فایل‌ها یا ماژول‌ها درگیرند.
- Constraint: محدودیت بگذارید — «تابع را تغییر نده»، «API contract ثابت بماند»، «بیش از 3 فایل را لمس نکن».
- Verification: معیار پذیرش مشخص کنید — «بعد از تغییر، testها باید پاس شوند»، «خروجی build خطا نداشته باشد».
مثال واقعی: «فایل src/utils/date.ts را طوری refactor کن که تمام توابع از Date به dayjs مهاجرت کنند. API exports ثابت بماند. بعد از تغییر، npm test باید پاس شود.»
اشتباه رایج: درخواست «همه‌ی پروژه را refactor کن» بدون محدودیت#
این درخواست در پروژه‌های متوسط به حلقهی ویرایش بیپایان منجر میشود. مدل یک فایل را عوض میکند، import فایل بعدی می‌شکند، فایل بعدی را اصلاح میکند، فایل اول دوباره می‌شکند. الگوی مشاهده‌شده در کامیونیتی: هر بار scope را به یک ماژول محدود کنید. این اشتباه پرهزینه‌تر از آن است که به‌نظر می‌رسد — چون فقط وقت شما را نمی‌گیرد، بلکه توکن‌های مصرف‌شده‌ی بی‌فایده هم هزینهی API را بالا می‌برند.
الگوی iteration: تقسیم کار بزرگ به sub-taskهای مستقل با خروجی قابل‌سنجش#
بهجای یک پرامپت بزرگ، چند پرامپت کوچک با خروجی قابل‌سنجش بنویسید. هر sub-task باید مستقل قابل test باشد. این الگو، context را تمیز نگه می‌دارد و اگر یک sub-task شکست خورد، بقیه آسیب نمی‌بینند. دقیق‌تر بگویم، شکست یک sub-task حتی مفید هم هست: مدل در حلقهی بعدی همان sub-task را اصلاح میکند بدون اینکه کل پروژه را دوباره بخواند.
هزینه، مدل‌ها و انتخاب اشتراک مناسب#
هزینهی استفاده از Claude Code از طریق اشتراک Pro/Max یا API key قابل مدیریت است؛ انتخاب مدل بین Sonnet و Opus trade-off سرعت و هزینه دارد و بزرگ‌ترین مدل برای همه‌ی کارها بهینه نیست. الگوی عملی: Sonnet برای کارهای مکانیکی، Opus برای reasoning پیچیده.
سطوح اشتراک Claude Pro و Max و محدودیت‌های هرکدام#
اشتراک Pro حجم محدودتری از استفاده‌ی روزانه دارد. اشتراک Max حجم بالاتری ارائه می‌دهد و برای استفاده‌ی سنگین‌تر طراحی شده. اگر از Claude Code روزانه چند ساعت کار می‌کنید، Pro ممکن است به‌سرعت به سقف برسد. مستندات رسمی Anthropic جزئیات سطوح را به‌روزرسانی میکند.
مقایسه‌ی مدل‌ها: Claude 3.5 Sonnet، Claude 4 Sonnet و Claude 4 Opus برای کدنویسی#
مدل‌های Sonnet سرعت بالاتر و هزینهی کمتری دارند. Opus دقت بالاتری در reasoning پیچیده ارائه می‌دهد ولی کندتر و گران‌تر است. الگوی عملی: برای scaffolding و refactoring مکانیکی، Sonnet کافی است. برای logic پیچیده و debugging، Opus ارزش هزینه را دارد. نگه‌داشتن Opus برای کارهای ساده، پول دور ریختن است.
هزینهی API در مقابل اشتراک: چه زمانی کدام ارزان‌تر تمام میشود#
اگر استفاده‌ی شما تحت‌پروژه و متناوب است، اشتراک به‌صرفه‌تر است چون هزینه ثابت دارد. اگر استفاده‌ی مداوم و سنگین دارید، API با pricing per-token ممکن است ارزان‌تر تمام شود چون فقط مصرف واقعی را می‌پردازید. این محاسبه بستگی به حجم کار شما دارد.
چه زمانی Claude Code گزینه‌ی اشتباه است#
Claude Code برای پروژه‌های کوچک یک‌فایلی، کارهایی که نیاز به مشاهده‌ی لحظه‌ای تغییرات دارند و پروژههایی با وابستگیهای ضمنی زیاد گزینه‌ی نادرستی است. در این سه سناریو، ابزارهای ساده‌تر سریع‌تر و کم‌هزینه‌تر جواب می‌دهند.
نقطه‌ی شکست: حلقهی ویرایش بیپایان در implicit dependencies#
وقتی یک فایل تغییر میکند و 10 فایل دیگر بهصورت ضمنی به آن وابسته‌اند، Claude Code وارد حلقهی ویرایش میشود. هر اصلاح، وابستگی جدیدی را می‌شکند. این الگو در پروژههایی با coupling بالا و بدون type system قوی (مثلاً JavaScript بدون TypeScript) مکرر مشاهده شده. راه‌حل: وابستگی‌ها را explicit کنید یا scope را محدود نگه دارید.
پروژه‌های کوچک یک‌فایلی: overhead تنظیمات بیشتر از فایده است#
اگر یک اسکریپت 50 خطی دارید، Claude Code فقط overhead اضافه میکند. در این موارد، یک چت‌باکس ساده یا completion در IDE سریع‌تر جواب می‌دهد. ابزار قدرتمند را برای کارهای بزرگ نگه دارید.
محدودیت‌های امنیت و مجوز دسترسی: چه چیزهایی نباید به Claude Code بدهید#
- دسترسی به پوشه‌های خارج از پروژه.
- اجازه‌ی اجرای arbitrary command بدون review.
- دسترسی به secrets و environment variables حساس.
- push مستقیم به branch اصلی بدون PR.
در محیط تیمی، مجوزها را با --allowedTools محدود کنید و حتماً از branch protection استفاده کنید.
یکپارچگی با Git، CI/CD و جریان کاری تیمی#
Claude Code مستقیماً commit ایجاد میکند و میتواند در pipeline تیمی برای scaffolding اولیه، code review خودکار و refactoring انبوه به‌کار رود؛ اما مجوز دسترسی باید محدود و audit شود. بدون این محدودیت، یک ایجنت خودمختار در محیط تیمی به ریسک امنیتی تبدیل میشود.
الگوی استفاده در code review: Claude Code به‌عنوان reviewer اولیه#
در چند پروژه‌ی کامیونیتی، الگوی زیر تکرار شده: Claude Code روی branch feature اجرا میشود، تغییرات را review میکند و یک commit با خلاصه‌ی مشکلات احتمالی اضافه میکند. سپس human developer فقط موارد باقی‌مانده را بررسی میکند. این الگو، زمان review را کم میکند ولی جایگزین review انسانی نیست.
یکپارچگی با CI/CD: اجرای خودکار در pipeline#
با API key، Claude Code را می‌توان در GitHub Actions یا GitLab CI اجرا کرد. سناریوی رایج: بعد از هر push، ابزار تغییرات را بررسی و یک comment در PR می‌نویسد. برای این کار، دسترسی read-only به فایل‌ها و محدودیت روی ابزارها الزامی است. بدون این محدودیت، یک pipeline خودکار میتواند بهجای review، فایل‌ها را دستکاری کند.
مدیریت مجوز و امنیت در محیط تیمی#
در محیط تیمی، هر عضو باید مجوزهای خودش را داشته باشد. فایل CLAUDE.md را در root پروژه commit کنید تا همه از context مشترک استفاده کنند. برای secrets، از environment variables استفاده کنید و هرگز آن‌ها را در فایل config ذخیره نکنید.
Claude Code ابزار قدرتمندی است، ولی قدرت آن مشروط به درک محدودیت‌هایش است. حلقهی ویرایش بیپایان، انفجار context و وابستگیهای ضمنی، سه نقطه‌ی شکست واقعی‌اند که با الگوهای درست قابل‌مدیریت‌اند. اگر می‌خواهید این الگوها را در پروژه‌ی واقعی تمرین کنید و از تجربه‌ی دیگران در کامیونیتی یاد بگیرید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در اسکول این مسیر را ساختاردهی میکند.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته میشوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.