برای کسی که نمیتواند از صفر کد بنویسد، کلود کد مثل جادو به نظر میرسد: توصیف میکنید چه میخواهید و آن را برایتان میسازد/انجام میدهد! این تا حدی دلیل است که کلود کد به یکی از پرکاربردترین اپلیکیشنهای من تبدیل شده، هرچند کدنویسی نمیکنم.
با این حال، فرض کردن اینکه کلود کد کاملاً خودکار است، اشتباه است. یعنی در مراحل مختلف این فرایند کدنویسی باید به پرسشها پاسخ دهید و پرامپتهای اضافی بدهید. این در پروژههای کوچک قابل تحمل است، اما اگر انتظار داشتید کلود کد خودش همهچیز را انجام دهد، آزاردهنده میشود.
بهتازگی اما متوجه شدم کلود کد یک تابع داخلی دارد که به همین کار کمک میکند. بیشتر از آن، اضافه کردن یک دستور ساده قبل از پرامپت کلود کد تفاوت چشمگیری ایجاد میکند: /goal.
دستور /goal پرامپتهایم را از چهار به یک کاهش داد
محاسبه آنچه تغییر کرد
پیش از آنکه بگویم دستور /goal چه میکند و چگونه تفاوت ایجاد میکند، بگذارید شما را در یک نشست ساخت با کلود کد بدون این دستور همراهی کنم. فرض کنیم میخواهم یک اپلیکیشن تحت وب ردیاب عادت بسازم با کلود کد، و تنها زبانی که باید بدانم انگلیسی است!
ترمینال را باز میکنم، کلود کد را راهاندازی میکنم و پرامپتی مینویسم که چیزی شبیه «یک ردیاب عادت تحت وب برایم بساز که همهچیز را روی مرورگر ذخیره میکند و کاملاً آفلاین کار میکند» میخواند. در یک ثانیه، کلود کد شروع به فکر کردن و ساختن میکند، اما در میان فرایند باید به پرسشها پاسخ دهم. مهمتر از آن، محصول نهایی کلود کد بیشتر احتمال دارد ناقص باشد، یعنی باید پرامپتهای بیشتری بدهم و صبر کنم تا اپلیکیشن همهچیز را کامل کند.
اضافه کردن دستور /goal این وضعیت را برای همیشه تغییر میدهد.
وقتی دستور /goal را قبل از پرامپت کلود کد اضافه میکنید، کلود کد پرامپت را بهعنوان شرطی که باید برآورده شود — یا هدفی که اپلیکیشن باید به آن دست یابد — در نظر میگیرد. یعنی بهجای درخواست پرامپت از سوی شما، کلود کد کارش را ادامه میدهد تا آن شرط برآورده شود. کلود کد پس از هر تسک یک مدل کوچکتر اجرا میکند تا تشخیص دهد آیا هدف محقق شده یا نه. اگر محقق شده باشد، نتیجه را روی صفحه میبینید. اگر نه، کلود کد به کار بهسوی آن هدف ادامه میدهد. بدانید که این با حالت Auto در کلود کد متفاوت است، که فقط فراخوان ابزار را میپذیرد اما نمیتواند یکی جدید آغاز کند.
حالا برای کاربر نهایی، دستور /goal یعنی پاسخ دادن به پرسشهای پیگیری کمتر یا هیچ پرسشی از کلود کد. همچنین متوجه شدم که صرفاً اضافه کردن دستور قبل از پرامپت پاسخ کلی بهتری نسبت به حذف آن میدهد. این روند را دنبال کردهام و تفاوت شب از روز بوده است.
اپلیکیشن ردیاب عادت من محاسبات را تأیید کرد
چهار چکاین به یک تبدیل شد و آن را زمانبندی کردم
در این نقطه، اضافه کردن /goal به پرامپت برایم با استفاده از کلود کد به امری طبیعی تبدیل شده. با این حال میخواستم دوباره بررسی کنم که آیا تفاوت آشکار است. پس تصمیم گرفتم همان پرامپت را دوبار اجرا کنم: یکبار با دستور /goal و یکبار بدون آن. بدانید که این دقیقاً همان پرامپتی است که استفاده کردم: «یک اپلیکیشن ردیابی عادت در فایل HTML واحد بساز که بتوانم عادتها را اضافه کنم، آنها را بهصورت روزانه علامت بزنم، دادهها پس از رفرش صفحه باقی بمانند و بدون بکاند باشد.»
نتیجه هنگام تلاش برای ساخت یک اپلیکیشن وب ردیابی عادت به این شکل بود.
بدون دستور /goal، کلود کد یک فایل HTML واحد ساخت که شامل اپلیکیشن ردیاب عادت بود و دستورالعملها را دنبال کرد. ابزار را بررسی کردم و امکان افزودن عادتهای جدید و مدیریت آنها را داشت؛ همهچیز نیز در مرورگر باقی میماند. با این حال، ابزار فاقد بسیاری از عناصری بود که یک اپلیکیشن وب چشمگیر میسازد.
از سوی دیگر، با دستور /goal، یک اپلیکیشن وب کاملاً کامل دریافت کردم که همه شرایطی را که مشخص کرده بودم برآورده میکرد. همانطور که در اسکرینشات زیر میبینید، اپلیکیشن وب شامل تعدادی از ویژگیهایی بود که در یک اپلیکیشن ردیاب عادت میخواهید ببینید. در واقع، چند دقیقه وقت میگذاشتم تا پرامپتهای اضافی به نشست اول بفرستم تا عناصری را که این نشست افزود، اضافه کند.
این اضافهکردن به این معنا بود که میتوانستم روی کارهای دیگر تمرکز کنم در حالی که کلود کد همهچیز را مدیریت میکرد. با این حال، باید به پوشه فضای کار اعتماد میکردم و حالت Auto را برای بهترین نتایج فعال میکردم. همچنین باید درک کنید که دستور /goal را بیشتر هنگام انجام یک پروژه پیچیدهتر قدر خواهید دانست.
هر شرط /goal لزوماً زمان را ذخیره نمیکند
اهداف مبهم بهاندازه پرامپتدستی دستی لوپ میشوند
با این حال، تصور کردن دستور /goal بهعنوان یک راهحل جادویی همهکاره ایده خوبی نیست. تنها با ساختار درستِ درخواست (prompt) خود میتوانید بیشترین بهره را از این قابلیت ببرید. هرچند متوجه میشوم که این دستور در بیشتر موارد نتایج بهتری تولید میکند، اما دلیل آن این است که درخواستهای من چیزی را شامل میشود که Claude Code بتواند بهعنوان یک شرط از آن استفاده کند. ممکن است یک ویژگی خاص یا یک وضعیت کلی اپلیکیشن یا اسکریپتی باشد که در حال ساخت آن هستم.
بهعنوان مثال، وقتی دستور /goal را با درخواستی درباره بازorganize کردن پوشه Downloads استفاده میکنم، شرطی به درخواست اضافه میکنم، مثلاً اینکه فایلها بر اساس دستهبندی مرتب شوند. به این ترتیب، پس از تکمیل هر کارِ بازچینش، Claude Code میتواند مدل کوچکتر خود را اجرا کند تا تأیید کند آیا شرط برقرار شده است یا خیر.
بدون این عنصر شرطی، همیشه بهترین نتایج را نخواهید داشت. در نهایت، اگر اهداف خود را مبهم نگه دارید، دوباره زمان بیشتری را صرف درخواستنویسی دستی خواهید کرد.
خودمختار به معنای بدوننظارت نیست
در نهایت، تابع goal، Claude Code را بسیار خودمختارتر از وضعیت کنونیاش میکند. در ترکیب با دسترسیهای مناسب و حالت Auto، میتواند در زمان کوتاهی نتایج بهتری به شما بدهد. با این حال، باید توجه داشته باشید که این قابلیت چند فرض درباره فرایند ساخت دارد. بنابراین ممکن است مواقعی پیش بیاید که نیاز باشد برگردید و زمان ذخیرهشده را دوباره سرمایهگذاری کنید. پس نمیتوان نظارت را از معادله حذف کرد. اما بله، با اضافه کردن این دستور زمان زیادی صرفهجویی میکنید و تفاوت بزرگی ایجاد میشود!
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Abhijith N Arjunan است. مشاهده مقاله اصلی