به ایجنت میگی «این باگ رو درست کن» و ده ثانیه بعد میگه «درستش کردم!». یه try/catch اضافه کرده، یا یه شرط گذاشته که علامت رو قایم کنه. باگ هنوز هست؛ فقط دیگه نمی‌بینیش.
مشکل از ایجنت نیست، از درخواست ماست. وقتی «درستش کن» میگی، ایجنت دنبال سریع‌ترین راه برای ساکت کردن خطا می‌گرده. این پرامپت ترتیب رو برعکس می‌کنه: اول تحقیق، بعد گزارش، آخرش اصلاح.
متن پرامپت
قسمت‌های داخل کروشه رو با اطلاعات باگ خودت پر کن:
«یه باگ دارم و نمی‌خوام فعلاً چیزی رو تغییر بدی. فقط تحقیق کن. علامت: [اینجا دقیقاً بنویس چی میشه، کِی میشه و پیام خطا چیه]. انتظار داشتم: [رفتار درست]. این‌ها رو به ترتیب انجام بده: ۱) قدم‌های بازتولید باگ رو پیدا کن و اگه می‌تونی با یه تست یا دستور اجرایی ثابت کن که باگ واقعاً هست. ۲) مسیر اجرای کد رو از نقطه‌ی ورود تا جایی که خراب میشه دنبال کن و فایل‌ها و خط‌های مهم رو نام ببر. ۳) حداقل سه فرضیه برای علت ریشه‌ای بنویس و برای هر کدوم بگو چه شاهدی تأییدش می‌کنه یا ردش می‌کنه. ۴) فرضیه‌ها رو با خوندن کد، لاگ یا اجرای دستور تست کن تا فقط یکی بمونه. ۵) قبل از هر تغییری، یه گزارش کوتاه بده: علت ریشه‌ای در یک جمله، شاهد، و پیشنهاد اصلاح با کمترین تغییر ممکن. اگه جایی مطمئن نیستی، حدس نزن و ازم بپرس. تا وقتی نگفتم «برو»، هیچ فایلی رو ویرایش نکن.»
چرا جواب میده؟
توی Claude Code می‌تونی همین رو توی Plan Mode بفرستی؛ بخش «Fix bugs efficiently» توی مستندات رسمی هم دقیقاً همین روحیه رو داره.
- بازتولید باگ با تست یعنی بعد از اصلاح، یه راه قطعی برای چک کردنش داری
- سه فرضیه نوشتن جلوی این رو می‌گیره که ایجنت روی اولین حدسش گیر کنه
- جمله‌ی «هیچ فایلی رو ویرایش نکن» همون حالت پلن رو بدون هیچ تنظیمی بهت میده
بعد از اصلاح
وقتی ایجنت اصلاح رو انجام داد، دیفش رو با پرامپت بازبینی امنیتی دیف چک کن. اگه دیدی این روند رو مدام تکرار می‌کنی، اسکیل diagnosing-bugs توی اسکیل‌های Matt Pocock همین کار رو به‌صورت دائمی به ایجنت یاد میده.
باگی که فقط ساکت شده، درست نشده.