شش ماه کلاد را اشتباه استفاده کردم
پنج چیزی که کاش از روز اول میدانستم
اولین چند ماه، کار من با کلاد دقیقاً همین بود: تب را باز میکردم، یک جمله مینوشتم، یک جواب میگرفتم، تب را میبستم. مثل گوگل، فقط با ادب بیشتر.
روزی که فهمیدم چقدر بد استفاده میکنم، سر یک درخواست ساده بود. نوشتم «این کد را بهینه کن» و یک متن تر و تمیز تحویل گرفتم که پر بود از توصیههای کلی؛ چیزهایی که خودم هم بلد بودم. عصبانی شدم که «این که چیزی بلد نیست». بعد نشستم و به سؤالم نگاه کردم. بهینه از نظر سرعت؟ مصرف حافظه؟ خوانایی برای کسی که تازه وارد تیم شده؟ هیچکدام را نگفته بودم. مدل مجبور شده بود قرعه بیندازد و یک جواب متوسط بدهد که به همهی احتمالها بخورد.
از آن به بعد رفتم سراغ مستندات و کمی هم آزمون و خطا. این پنج چیز، بیشترین تفاوت را در خروجی کارم ساختند.
۱. کلاد فقط آن جعبهی چت نیست
بیشتر ما هیچوقت از صفحهی چت بیرون نمیآییم. مثل این است که یک شرکت را از راهروی ورودیاش اداره کنی.
چیزی که واقعاً وجود دارد، چند لایه است و هر لایه برای یک جور کار ساخته شده:
- چت: برای فکر کردن با صدای بلند، سؤال سریع، تست یک ایده. همین و بس.
- پروژهها (Projects): جایی که میشود فایل، مستند و دستورالعمل ثابت گذاشت تا در همهی گفتگوهای آن پروژه در دسترس باشد.
- Claude Code: محیط کار توسعهدهندهها، روی فایلهای واقعی پروژه، از خط فرمان یا داخل ادیتور.
- Cowork: همان منطق، ولی برای کسی که برنامهنویس نیست؛ کارهای چندمرحلهای روی پوشهها و فایلهای خودت، بدون اینکه هر بار چیزی آپلود کنی.
- مهارتها (Skills): دستورالعملهای قابل استفادهی مجدد برای کارهایی که مدام تکرار میشوند. من یکی دارم که خروجی خام یک جلسه را به قالب گزارش همیشگیام تبدیل میکند و دیگر لازم نیست هر بار قالب را توضیح بدهم.
- کانکتورها (Connectors): وصل شدن به جایی که دادهی واقعی زندگی میکند؛ درایو، ایمیل، اسلک، نوشن. مهمترین نتیجهی این فهرست برای من این بود: هر کاری که بیش از یک بار تکرارش میکنم، جایش در چت نیست.
۲. گاهی باید بگذاری کند فکر کند
عادت کردهایم سرعت را با کیفیت یکی بگیریم. در کار با مدلها دقیقاً برعکس است.
وقتی مدل اجازه دارد قبل از جواب دادن، مسیرهای مختلف را بسنجد و خودش را نقد کند، خروجی روی مسائل چندلایه محسوستر بهتر میشود. روی مسائل ساده اما نه؛ فقط زمان و توکن بیشتری خرج میشود و گاهی جواب را بیجهت پیچیده میکند. آدمها هم همینطورند؛ برای انتخاب یک استراتژی باید فکر کنی، برای انتخاب نوشیدنی نه.
یک نکته که خیلی جاها اشتباه نوشته شده: این قابلیت دیگر مخصوص مدلهای بزرگ نیست. Haiku 4.5 هم قابلیت فکر کردن دارد و در نسلهای جدیدتر (از Opus 4.6 به بعد) مدل تا حد زیادی خودش تصمیم میگیرد که چقدر عمیق فکر کند. اگر با API کار میکنی، پارامترهای این بخش در یک سال گذشته چند بار عوض شدهاند؛ به مستندات نگاه کن، نه به مقالهی پارسالی (از جمله همین مقاله، شش ماه دیگر).
قاعدهی شخصی من ساده است: اگر خودم برای جواب دادن به آن سؤال باید کاغذ و قلم بردارم، حالت تفکر عمیق روشن.
۳. پرامپت ننویس، صورتمسئله بنویس
این مهمترین بخش این متن است و اگر بقیه را نخوانی هم اشکالی ندارد.
«یک مقاله دربارهی هوش مصنوعی بنویس» یک درخواست نیست، یک آرزوست. جوابش هم دقیقاً همان چیزی میشود که لایقش است: متنی صاف و بیخاصیت که هیچکس مخاطبش نیست.
سه چیز را در درخواستت بگذار و تفاوتش را ببین:
- هدف: دقیقاً چه چیزی، در چه اندازهای، برای چه کاری.
- زمینه: مخاطب کیست، چه میداند، چه محدودیتی هست، چه چیزی را قبلاً امتحان کردهای.
- قالب خروجی: لحن، ساختار، طول، اینکه خروجی باید فایل باشد یا متن داخل چت. مقایسه کن:
«کد را بهینه کن.»
با:
«هدف: زمان پاسخ این تابع را کم کن. زمینه: روی هر درخواست حدود ۴۰۰ رکورد میآید، دیتابیس PostgreSQL است، پروداکشن روی نسخهی ۱۴ است و اجازهی تغییر اسکیمای جدول را ندارم. خروجی: کد اصلاحشده به همراه توضیح این که هر تغییر چه هزینهای دارد.»
دومی تقریباً همیشه جواب قابل استفاده میدهد، چون دیگر جای حدس زدن نگذاشتهام. نوشتنش سی ثانیه بیشتر طول میکشد و ده دقیقه رفتوبرگشت را حذف میکند.
۴. برای هر کار، یک مدل
انتخاب مدل هم یک تصمیم مهندسی است، نه یک عادت.
- Opus برای کارهایی که واقعاً تحلیل میخواهند: معماری، تصمیمهای پرهزینه، رسیدگی به چیزی که چند فایل و چند محدودیت همزمان دارد.
- Sonnet برای بیشتر کارهای روزمره؛ تولید محتوا، کدنویسی معمولی، جمعبندی و بازنویسی. اگر شک داری، از این شروع کن.
- Haiku برای حجم و سرعت؛ دستهبندی هزاران رکورد، جوابهای کوتاه، کارهایی که باید در مقیاس تکرار شوند. انتخاب سنگینترین مدل برای خلاصه کردن یک ایمیل، دقت را بالا نمیبرد؛ فقط منابع را هدر میدهد. این همان اتلاف منابعی است که در پروژههای واقعی خودش را به شکل هزینه و کندی نشان میدهد.
۵. هر روز از صفر شروع نکن
تفاوت اصلی چت و پروژه، حافظه است.
در چت، هر بار باید توضیح بدهی ساختار دادهات چیست، اسم جدولها را چطور میگذاری، لحن سازمانت چطور است. در پروژه، یک بار مستندات و قواعد را میگذاری و بعد از آن مدل با همان دانش وارد هر گفتگو میشود. تفاوتش مثل تفاوت پرسیدن از یک غریبهی باهوش است با پرسیدن از همکاری که شش ماه است در تیم توست.
من برای هر حوزهی کاری یک پروژهی جدا دارم و داخلش سه چیز ثابت گذاشتهام: یک فایل که توضیح میدهد کارمان چیست، یک فایل نمونه از خروجی مطلوب، و یک فهرست کوتاه از کارهایی که نباید انجام شوند. همین سه فایل، بخش زیادی از رفتوبرگشتهای همیشگی را حذف کرد.
جمعبندی
هیچ «پرامپت جادویی» وجود ندارد. چیزی که وجود دارد، تفاوت بین استفاده از یک ابزار و ساختن یک محیط کار است.
اگر با کلاد مثل نوار جستجو رفتار کنی، جوابهایی در حد نوار جستجو میگیری. اگر برایش زمینه، حافظه و قالب مشخص کنی، چیزی به دست میآوری که بیشتر شبیه یک همکار است تا یک موتور پاسخگو.
سؤال من از تو: اگر آن «همکار» مجبور نبود هر روز صبح از صفر شروع کند، کدام کار این هفتهات زودتر تمام میشد؟
اینها را هم بشنو و ببین
راستی، این موضوع را همینجا رها نکردیم. ایجنتهای سایت نشستند و دربارهی همین بحث با هم گفتگو کردند و حاصلش یک پادکست شد؛ همان چیزهایی که اینجا نوشتهام، منتها با بحث و جدل و چند مثال بیشتر. حتماً گوش بدهید.
یک ویدئوی ارائه هم هست که همین پنج نکته را قدمبهقدم و با تصویر نشان میدهد. اگر میخواهی موضوع واقعاً جا بیفتد، پیشنهاد میکنم بعد از خواندن متن، آن را هم ببینی.
هر دو را در انتهای همین پست، پایینتر، گذاشتهام: