دیباگ با هوش مصنوعی: چه چیزی بفرستیم تا جواب درست بگیریم

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

ولی یک شرط دارد: مدل باید همان چیزهایی را ببیند که یک همکار باتجربه برای کمک‌کردن لازم داشت.

چه چیزی بفرستیم#

۱. متن کامل خطا#

نه خلاصه، نه ترجمه، نه «یک خطای ۵۰۰ می‌دهد». کل پیام همراه با رد پشته (stack trace).

SQLSTATE[42000]: Syntax error or access violation: 1071
Specified key was too long; max key length is 1000 bytes
(Connection: mysql, SQL: alter table `users` add unique
`users_email_unique`(`email`))

این چهار خط به مدل می‌گوید مشکل کجاست، در کدام جدول و روی کدام ستون. توصیف «مایگریشن خطا می‌دهد» هیچ‌کدام را نمی‌گوید.

۲. کدی که خطا از آن می‌آید#

نه کل پروژه؛ همان تابع یا فایلی که رد پشته به آن اشاره می‌کند، به‌علاوه‌ی هر چیزی که مستقیم صدا می‌زند.

۳. نسخه‌ها و محیط#

PHP 8.4 - Laravel 13 - MySQL 5.7
هاست اشتراکی سی‌پنل، بدون دسترسی root

همین دو خط جلوی نصف راه‌حل‌های بی‌ربط را می‌گیرد. مدل دیگر پیشنهاد نمی‌دهد تنظیمات سرور را عوض کنید وقتی دسترسی‌اش را ندارید.

۴. انتظار و واقعیت#

«انتظار داشتم این اتفاق بیفتد، ولی آن اتفاق افتاد.» این جمله در خطاهایی که پیام خطا ندارند (خروجی غلط، رفتار عجیب) تنها سرنخ مدل است.

۵. آنچه امتحان کرده‌اید#

اگر نگویید، همان سه راه‌حل اولی را می‌گیرید که خودتان یک ساعت پیش امتحان کردید.

قبل از فرستادن: پاک‌سازی#

کد و لاگ اغلب چیزهایی دارند که نباید بیرون بروند:

مدل برای پیدا کردن خطا به مقدار واقعی این‌ها نیاز ندارد. جزئیات بیشتر در چه چیزهایی را هرگز به هوش مصنوعی ندهیم.

مسئله را کوچک کنید#

اگر خطا در یک فایل ۸۰۰ خطی است، قبل از فرستادن سعی کنید آن را کوچک کنید:

1. بخش‌هایی را که به خطا ربط ندارند کنار بگذارید.
2. دوباره اجرا کنید. هنوز خطا هست؟
3. تکرار کنید تا به کوچک‌ترین کدی برسید که همان خطا را می‌دهد.

دو اتفاق خوب می‌افتد: خیلی وقت‌ها وسط همین کار خودتان علت را پیدا می‌کنید، و اگر نکردید، مدل با ۳۰ خط خیلی دقیق‌تر از ۸۰۰ خط جواب می‌دهد.

نشانه‌هایی که مدل دارد حدس می‌زند#

• «این را امتحان کنید» پشت سر هم. اگر سه پیشنهاد متفاوت بدون توضیح علت داد، علت را نمی‌داند.
• تابع یا گزینه‌ی ناآشنا. قبل از استفاده در مستندات رسمی جستجویش کنید. اگر نبود، ساخته‌ی ذهن مدل است.
• عوض‌کردن چیزهای بی‌ربط. اگر برای رفع یک خطا نصف فایل را بازنویسی کرد، بایستید.
• تأیید هر چه شما می‌گویید. اگر حدس شما را بدون دلیل تأیید کرد، بپرسید چرا.

وقتی این نشانه‌ها را دیدید، درخواست را عوض کنید:

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

بخواهید علت را توضیح بدهد#

راه‌حلی که نمی‌فهمید، بدهی فنی است. دفعه‌ی بعد که همان خطا در جای دیگری پیش بیاید، دوباره گیر می‌کنید.

این راه‌حل کار کرد. حالا توضیح بده چرا خطا پیش آمده بود
و چطور جلوی تکرارش را در بقیه‌ی پروژه بگیرم.

آزمایش قبل از اعتماد#

1. کد را بخوانید. اگر خطی را نمی‌فهمید، بپرسید.
2. روی محیط آزمایشی اجرا کنید، نه سایت زنده.
3. موردهای مرزی را امتحان کنید: ورودی خالی، ورودی فارسی، عدد خیلی بزرگ.
4. اگر به دیتابیس دست می‌زند، اول بک‌آپ بگیرید.

مدل کد را اجرا نکرده است. وقتی می‌گوید «این کار می‌کند»، یعنی «به نظر من باید کار کند».

وقتی گفتگو به بن‌بست می‌رسد#

اگر بعد از چهار پنج پیام هنوز حل نشده، ادامه ندهید. هر تلاش ناموفق در متن گفتگو می‌ماند و مدل را گیج‌تر می‌کند.

گفتگوی تازه باز کنید و این‌بار بنویسید چه چیزهایی جواب نداد. اینکه چرا گفتگوی بلند بدتر می‌شود را در توکن، پنجره‌ی متن و توهم توضیح داده‌ایم.

ادامه‌ی این مسیر#

اگر این مطلب به کارتان آمد، این مقاله‌ها همین موضوع را عمیق‌تر و کاربردی‌تر ادامه می‌دهند:

خلاصه#

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