آموزش سری Claude Code قسمت ۴: موارد استفاده Claude Code کدامند؟

موارد استفاده معمول

من موارد استفاده را به چهار دسته تقسیم می‌کنم، به ترتیب فراوانی از زیاد به کم.

دسته اول: درک کد

این احتمالاً پرکاربردترین دسته است. وقتی پروژه دیگران را تحویل می‌گیرید، یک ماژول قدیمی را بررسی می‌کنید، یا یک مخزن بدون مستندات را باز می‌کنید، مستقیماً از آن بپرسید.

روش انجام:

claude "این پروژه چیست؟ ورودی کجاست؟" — آن package.json، ساختار دایرکتوری، فایل‌های کلیدی را می‌خواند و یک خلاصه ارائه می‌دهد.
یک تابع را باز کنید، از آن بخواهید منطق را توضیح دهد و جریان را (با توضیحات متنی) ترسیم کند.
از آن بخواهید مسیر کامل یک درخواست API از فرانت‌اند تا پایگاه داده را ردیابی کند.

کاری که اینجا انجام می‌دهد، اساساً انجام کار کثیف خواندن کد برای شماست. نیازی نیست خودتان ساعت‌ها grep کنید و سپس در ذهنتان پازل را بچینید. آن مسیر را مرتب می‌کند و شما قضاوت می‌کنید.

جایگزین این دسته از سناریوها: در مخزن کد به صورت دستی جستجو کنید، یادداشت بردارید، نمودار فراخوانی رسم کنید.

دسته دوم: نوشتن و تغییر کد

این پر بحث‌ترین دسته است، اما در واقع پرکاربردترین نیست. سناریوهای نوشتن کد معمولاً به این شکل هستند:

ایجاد قابلیت جدید: "یک API برای تغییر ایمیل زیر ماژول user اضافه کن، فرمت ایمیل را اعتبارسنجی کن، و تست واحد بنویس."
بازآرایی بین فایل‌ها: "همه moment() را در این سه فایل به dayjs() تغییر بده، منطق دیگر را تغییر نده."
مهاجرت و ارتقاء: "این کامپوننت Vue 2 را به روش Composition API Vue 3 تغییر بده."

کدی که تولید می‌کند لزوماً یکبار درست نیست، اما می‌تواند تمام تغییرات بین فایل‌ها را یکباره انجام دهد و شما می‌توانید فایل به فایل تفاوت را ببینید و یکی‌یکی بپذیرید یا رد کنید.

جایگزین این دسته: نوشتن دستی کدهای تکراری، جستجو و جایگزینی دستی ارجاعات بین فایل‌ها.

دسته سوم: اشکال‌زدایی و رفع

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

روش استفاده معمول:

خروجی تست ناموفق را به آن بدهید، کد مرتبط را می‌خواند، راه حل ارائه می‌دهد، پس از تغییر دوباره تست را اجرا می‌کند تا ببیند عبور می‌کند یا خیر.
وقتی خطای CI رخ می‌دهد، لاگ را بچسبانید، از آن بخواهید رفع کند، پس از رفع git diff را اجرا کنید تا تغییرات تأیید شود.

نقشی که در اینجا ایفا می‌کند بیشتر شبیه "بازرس دور اول" است. شما هستید که زمان صرف فکر کردن به مشکل می‌کنید، اما آن فایل‌ها را بررسی می‌کند، تفاوت‌ها را مقایسه می‌کند، و دستورات تأیید را اجرا می‌کند.

جایگزین این دسته: اجرای مکرر تست‌ها، خواندن لاگ‌های خطا، مقایسه دستی تفاوت‌های کد.

دسته چهارم: خودکارسازی متفرقه

این دسته از سناریوها کم‌اهمیت‌ترین به نظر می‌رسند، اما وقتی جمع شوند، بیشترین زمان را صرفه‌جویی می‌کنند.

مثال‌ها:

نوشتن پیام commit گیت: claude "بر اساس git diff فعلی یک پیام commit با فرمت Conventional Commits بنویس"
تولید توضیحات PR: از آن بخواهید تفاوت بین شاخه فعلی و main را مقایسه کند و خلاصه‌ای از تغییرات و توضیحات تست تولید کند.
نوشتن یادداشت انتشار: از Claude Code بخواهید تاریخچه commit هفته گذشته را بخواند و CHANGELOG تولید کند.
پاسخ به مسائل محیطی: "نصب این وابستگی خطا داد، خروجی ترمینال را برای من ببین و علت را پیدا کن."

نکته مشترک این کارها: پیچیده نیستند، اما خسته‌کننده هستند. انجامشان به صورت دستی نیاز به تعویض پنجره و تایپ زیاد دارد. واگذار کردن به آن، در چند ثانیه تمام می‌شود.

جایگزین این دسته: ویرایش دستی متن، نوشتن مستندات استاندارد، جستجوی مسائل پیکربندی محیط.

یک "نقشه"

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

دریافت یک پروژه ناآشنا
    │
    ▼
[درک کد] ─── فهم ساختار، ورودی، منطق کلیدی
    │
    ▼
شروع به نوشتن قابلیت جدید یا تغییر ماژول
    │
    ▼
[نوشتن/تغییر کد] ─── تولید پیاده‌سازی، بازآرایی بین فایل‌ها
    │
    ▼
اجرای تست، بروز باگ
    │
    ▼
[اشکال‌زدایی و رفع] ─── تحلیل خطا، مکان‌یابی، رفع، اجرای مجدد
    │
    ▼
آماده‌سازی برای commit
    │
    ▼
[خودکارسازی متفرقه] ─── نوشتن commit، توضیحات PR، یادداشت انتشار
    │
    ▼
commit، تکمیل

نیازی نیست از آن در هر چهار بخش استفاده کنید. برخی تیم‌ها فقط از آن برای درک کد استفاده می‌کنند، برخی فقط برای نوشتن تست و ارسال PR. هر مرحله‌ای که بیشتر شما را آزار می‌دهد، از آن سناریو شروع کنید.

دو معیار قضاوت کاربردی

اگر مطمئن نیستید که آیا کاری را باید به Claude Code بسپارید یا نه، دو سؤال از خود بپرسید:

۱. آیا این کار "مکانیکی" است تا "خلاقانه"؟

تغییر صد ارجاع، قالب‌بندی خروجی، تولید کدهای نمونه — انجام این کارها به صورت دستی در مجموع زمان‌بر است، اما ایده را از قبل دارید. مناسب است که به آن بسپارید.

۲. آیا "هزینه تأیید" این کار بالاست؟

اگر یک تغییر نیاز به جابجایی مکرر، اجرای تست، و مشاهده لاگ برای تأیید داشته باشد، اشکال‌زدایی دستی کند است. Claude Code می‌تواند چرخه "تغییر-اجرا-مشاهده-تغییر مجدد" را خودش انجام دهد و شما بسیار راحت‌تر خواهید بود.