Claude Code نسل تازه‌ای از ابزارهای هوش مصنوعی برای کدنویسی است. نسل‌های قبلی این ابزارها بیشتر روی «تکمیل خودکار» یک یا چند خط کد تمرکز داشتند؛ اما Claude Code کاملاً عامل‌محور (agentic) است و برای ساختن کل یک ویژگی، نوشتن کل یک فایل یا رفع کل یک باگ طراحی شده، نه تکمیل یک خط.

• با ابزارهای فعلی شما کار می‌کند: نیازی نیست ادیتور یا روال کاری‌تان را عوض کنید. چه از VS Code استفاده کنید، چه Xcode یا JetBrains، Claude Code با همه‌ی آن‌ها و همچنین با هر ترمینالی کار می‌کند.
• محیط‌مستقل است: می‌توان آن را به‌صورت لوکال، روی SSH ریموت یا داخل tmux اجرا کرد.
• روال کاری خاصی را تحمیل نمی‌کند: چون کاربرد آن بسیار گسترده است، تیم Anthropic عمداً کاربر را به یک الگوی مشخص هدایت نمی‌کند؛ مهندس باید بتواند آن را هر طور که خودش می‌خواهد به کار بگیرد.

همین گستردگی باعث می‌شود اولین برخورد با آن گیج‌کننده باشد: یک خط پرامپت باز می‌شود و معلوم نیست از کجا باید شروع کرد. ادامه‌ی این جزوه دقیقاً همین مسیر را قدم‌به‌قدم روشن می‌کند.

پیش از هر چیز، چند تنظیم اولیه‌ی ساده تجربه‌ی کار را بسیار بهتر می‌کند:

• تنظیم ترمینال: با اجرای دستور تنظیم ترمینال، کلید Shift + Enter برای خط جدید فعال می‌شود و دیگر نیازی به استفاده از بک‌اسلش برای شکستن خط نیست.
• تم: می‌توانید بین حالت روشن، تیره یا تم‌های مناسب کم‌بینایان رنگ (Daltonized) یکی را انتخاب کنید.
• نصب اپ گیت‌هاب: با نصب اپلیکیشن گیت‌هاب، می‌توانید مستقیماً روی هر Issue یا Pull Request در گیت‌هاب، Claude را منشن (mention) کنید تا وارد عمل شود.
• سفارشی‌کردن ابزارهای مجاز: می‌توانید فهرست ابزارهایی را که Claude اجازه‌ی استفاده‌ی خودکار از آن‌ها را دارد از پیش تعیین کنید تا هر بار برای تأیید یک ابزار مزاحم‌تان نشود.
• دیکته‌ی صوتی (فقط macOS): از مسیر System Settings ← Accessibility ← Dictation می‌توانید قابلیت دیکته را فعال کنید. با دوبار زدن کلید دیکته می‌توانید پرامپت‌تان را با صدا بگویید، دقیقاً مثل صحبت با یک همکار.

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

چرا برای همین کار مناسب است؟

• بدون ایندکس‌گذاری: هیچ پایگاه‌داده‌ی ریموتی از کد شما ساخته یا جایی آپلود نمی‌شود.
• کد شما لوکال می‌ماند و روی هیچ مدل مولدی هم برای آموزش استفاده نمی‌شود.
• بدون نیاز به راه‌اندازی: چون ایندکسی وجود ندارد، همان لحظه‌ی نصب می‌توانید ازش استفاده کنید؛ منتظر پردازش نمی‌مانید.

نمونه سؤال‌هایی که می‌توان پرسید

• برای سؤال اول، Claude Code به‌جای جست‌وجوی متنی ساده، نمونه‌های واقعی استفاده و نمونه‌سازی آن کلاس را در کد پیدا می‌کند و پاسخی در حد یک مستند یا ویکی خوب می‌دهد.
• برای سؤال دوم، Claude تاریخچه‌ی git را بررسی می‌کند، می‌فهمد این آرگومان‌ها در چه کامیت‌هایی اضافه شده‌اند، آن کامیت‌ها به چه Issueهایی مرتبط بوده‌اند و همه را خلاصه می‌کند، بدون این‌که لازم باشد به‌طور صریح بگویید «تاریخچه‌ی گیت را نگاه کن». طبق گفته‌ی سخنران، هیچ دستور خاصی هم در system prompt برای این کار وجود ندارد؛ مدل خودش می‌داند چطور از git استفاده کند.
• برای سؤال درباره‌ی Issue گیت‌هاب، Claude Code از قابلیت web fetch برای خواندن آن Issue استفاده می‌کند.
• سؤال «این هفته چه شیپ کردم؟» یک عادت هفتگی سخنران در جلسه‌ی standup دوشنبه‌هاست: Claude لاگ گیت را بررسی، نام کاربری را تشخیص و خلاصه‌ای آماده می‌دهد که می‌شود مستقیم در یک سند کپی کرد.

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

قبل از نوشتن کد، از او بخواهید برنامه بریزد

اگر مستقیم از Claude بخواهید یک ویژگی بزرگ (مثلاً چند هزار خط) را پیاده‌سازی کند، گاهی نتیجه دقیقاً چیزی نیست که می‌خواستید. ساده‌ترین راه برای گرفتن نتیجه‌ی درست این است که از او بخواهید اول ایده‌بریزی کند، یک برنامه بنویسد و پیش از شروع کدنویسی از شما تأیید بگیرد. برای این کار نیازی به فعال‌سازی حالت خاصی (Plan Mode) نیست؛ کافی است در پرامپت خودتان همین را بخواهید.

یک دستور رایج: «کامیت کن و push کن»

این یکی از پرکاربردترین دستورهای روزمره است. چیز خاصی در آن نیست، اما Claude به‌اندازه‌ی کافی هوشمند است که آن را کامل تفسیر کند: یک برنچ می‌سازد، تغییرات را کامیت می‌کند، push می‌کند و یک Pull Request در گیت‌هاب باز می‌کند، بدون این‌که جزئیات را برایش توضیح دهید. برای فهمیدن فرمت درست کامیت هم خودش تاریخچه‌ی کد و لاگ گیت را بررسی می‌کند.

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

• ابزارهای CLI داخلی تیم: کافی است به Claude بگویید چنین ابزاری وجود دارد و برای یادگیری نحوه‌ی استفاده، به راهنمای --help آن مراجعه کند. اگر زیاد از این ابزار استفاده می‌کنید، می‌توانید این را در فایل CLAUDE.md هم ذخیره کنید تا بین سشن‌های مختلف یادش بماند.
• ابزارهای MCP: به همان شکل، می‌توانید یک سرور MCP را معرفی کرده و به Claude بگویید چطور از آن استفاده کند.

۱. کاوش → برنامه‌ریزی → تأیید → کدنویسی

همان الگویی که پیش‌تر توضیح داده شد: کمی کاوش در کد، کمی برنامه‌ریزی، گرفتن تأیید از شما و بعد نوشتن کد.

۲. دادن یک راه برای «چک‌کردنِ کار خودش»

وقتی Claude راهی برای سنجیدن نتیجه‌ی کار خودش داشته باشد، مثلاً نوشتن تست واحد (unit test)، گرفتن اسکرین‌شات با Puppeteer، یا اسکرین‌شات از شبیه‌ساز iOS، می‌تواند نتیجه‌اش را با آن راه بسنجد و دوباره تکرار (iterate) کند. این الگو بسیار قدرتمند است.

نکته‌ی کلی: در هر حوزه‌ای که کار می‌کنید، چه تست واحد یا یکپارچگی، چه اسکرین‌شات اپ موبایل یا وب، فقط کافی است یک راه برای «دیدن نتیجه» در اختیار Claude بگذارید تا خودش تکرار کند و نتیجه‌ی بهتری بگیرد.

هرچه context بیشتری در اختیار Claude بگذارید، تصمیم‌هایش هوشمندانه‌تر می‌شود، چون شما به‌عنوان مهندس، حجم زیادی دانش درباره‌ی سیستم‌ها و تاریخچه‌ی پروژه در ذهن دارید که Claude از آن بی‌خبر است.

فایل CLAUDE.md

• ساده‌ترین محل قرار دادن آن، ریشه‌ی پروژه است؛ همان جایی که Claude Code را اجرا می‌کنید.
• این فایل به‌طور خودکار، در همان اولین پیام هر سشن، در context خوانده می‌شود.
• یک نسخه‌ی local هم وجود دارد که معمولاً در سورس‌کنترل commit نمی‌شود و فقط برای خود شماست؛ نسخه‌ی اصلی CLAUDE.md را باید commit کنید و با تیم به اشتراک بگذارید.
• چیزهایی که خوب است در آن باشد: دستورهای رایج bash، ابزارهای MCP پرکاربرد، تصمیم‌های معماری مهم، و فایل‌های کلیدی پروژه.
• آن را کوتاه نگه دارید؛ طولانی‌شدنش فقط context بی‌مورد مصرف می‌کند و معمولاً فایده‌ی چندانی هم ندارد.
• می‌توان در دایرکتوری‌های تودرتوی پروژه هم فایل CLAUDE.md گذاشت؛ این‌ها فقط وقتی Claude در همان دایرکتوری کار می‌کند به‌صورت خودکار بارگذاری می‌شوند.
• در سطح سازمانی هم می‌شود یک CLAUDE.md مشترک برای همه‌ی کدبیس‌های شرکت تعریف کرد که به‌طور خودکار برای همه لود می‌شود.

راه‌های دیگر برای دادن context

• Slash Commands اختصاصی: با فایل‌هایی در مسیر .claude/commands (هم در دایرکتوری خانگی و هم داخل خود پروژه) می‌توانید دستورهای اختصاصی بسازید. برای نمونه، در ریپوی خود Claude Code، برچسب‌گذاری خودکار Issueهای گیت‌هاب دقیقاً با همین روش (یک slash command به همراه یک GitHub Action) انجام می‌شود.
• منشن‌کردن فایل‌ها (@): با علامت @ می‌توانید فایل یا فولدر خاصی را مستقیماً به context اضافه کنید.

همان‌طور که CLAUDE.md سطوح مختلف دارد، این موضوع درباره‌ی تنظیمات، Slash Commandها، مجوزها و سرورهای MCP هم صادق است:

• سطح پروژه: مخصوص همان ریپوی گیت است؛ می‌تواند commit و با تیم مشترک شود یا فقط شخصی بماند.
• سطح Global: تنظیماتی که در همه‌ی پروژه‌های شما مشترک است.
• سطح Enterprise: سیاست‌های سراسری برای کل سازمان. برای نمونه، می‌توان یک دستور خاص را برای همه‌ی کارمندان از پیش تأیید‌شده (auto-approve) کرد، یا برعکس، دسترسی به یک URL خاص را برای همه مسدود کرد تا هیچ کارمندی نتواند آن را override کند.
• فایل mcp.json: اگر این فایل را در ریپو commit کنید، هر کسی که Claude Code را در آن ریپو اجرا کند، برای نصب همان سرورهای MCP پرامپت می‌شود.

اگر مطمئن نیستید از کجا شروع کنید، توصیه‌ی سخنران این است: از context مشترک در سطح پروژه شروع کنید، یک بار آن را بنویسید و با کل تیم به اشتراک بگذارید تا اثر شبکه‌ای (network effect) شکل بگیرد: یک نفر کمی کار می‌کند و همه از آن بهره می‌برند.

دو دستور کاربردی برای مدیریت حافظه

• دستور /memory تمام فایل‌های حافظه‌ای را که در حال حاضر لود شده‌اند (سیاست سازمانی، حافظه‌ی کاربر، CLAUDE.md پروژه، فایل‌های تودرتو) نشان می‌دهد و امکان ویرایش مستقیم آن‌ها را هم می‌دهد.
• با تایپ علامت # در ابتدای پیام، می‌توانید هر لحظه از Claude بخواهید چیزی را به‌خاطر بسپارد؛ خودش تشخیص می‌دهد در کدام فایل حافظه ذخیره‌اش کند.

چون Claude Code داخل ترمینال اجرا می‌شود، خیلی از این میانبرها به‌سادگی قابل کشف نیستند. این‌ها فهرست کاربردی‌ترین‌ها هستند:

هر کس با پرچم -p در Claude Code کار کرده باشد، در واقع با همین SDK آشنا شده؛ دقیقاً همان SDKای که خودِ Claude Code هم از آن ساخته شده است.

بهترین توصیف برای این SDK این است: مثل یک ابزار Unix فوق‌هوشمند رفتار کنید؛ یک پرامپت می‌دهید، JSON پس می‌گیرید و می‌توانید هر چیزی را به آن pipe کنید یا از آن خروجی بگیرید.

• در Anthropic از همین روش در CI، واکنش به incident و انواع pipelineهای دیگر استفاده می‌شود.
• می‌توان مثلاً یک لاگ بزرگ از یک باکت GCP خواند و پایپ کرد تا Claude نکات مهم آن را پیدا کند.
• می‌توان داده را از یک ابزار CLI مثل Sentry گرفت و به Claude پایپ کرد تا با آن کاری انجام دهد.
• نمونه‌ی واقعی: برچسب‌گذاری خودکار Issueهای ریپوی خودِ Claude Code، از طریق یک slash command و یک GitHub Action که همین SDK را صدا می‌زند.

سخنران خودش را یک کاربر «عادی» توصیف می‌کند: معمولاً یک Claude Code در یک لحظه اجرا می‌کند و شاید چند تب ترمینال برای چند ریپو باز داشته باشد. اما کاربران پیشرفته‌تر، چه داخل و چه خارج از آنتروپیک، معمولاً این الگوها را دارند:

• چند سشن SSH و تونل‌های tmux به سشن‌های Claude Code خود.
• چند نسخه‌ی checkout‌شده از یک ریپو، برای اجرای چند Claude Code به‌صورت موازی روی آن.
• استفاده از git worktrees برای ایزوله‌کردن هر سشن از دیگری.

می‌توانید هر تعداد سشن که بخواهید موازی اجرا کنید و کارهای زیادی را همزمان جلو ببرید.