چطور یک اپ ساخته‌شده با هوش مصنوعی را دیباگ کنیم: یک روش عملی

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

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

چرخه دیباگ

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

1. بازتولید — مشکل را قابل‌اطمینان رخ دهد.
2. مشاهده — پیام خطا و کاری را که اپ در حال انجامش بود جمع کنید.
3. توصیف — به هوش مصنوعی مراحل دقیق، نتیجه مورد انتظار و نتیجه واقعی را بدهید.
4. رفع — بگذارید هوش مصنوعی فقط یک چیز را تغییر دهد.
5. تأیید — همان مراحل دقیق را تکرار کنید و مطمئن شوید که رفع شده و چیز نزدیک آن خراب نشده است.
6. بازگشت در صورت لزوم — اگر اوضاع بدتر شد، برگردانید و با اطلاعات بهتر دوباره تلاش کنید.

بیشتر وقت هدررفته در اپ‌های ساخته‌شده با هوش مصنوعی از پریدن از مراحل ۱، ۲ و ۵ ناشی می‌شود: گفتن «خراب است»، پذیرفتن یک تغییر بدون آزمودن آن، و سپس درخواست رفع دیگری روی یک چیز خراب.

مرحله ۱: مشکل را بازتولید کنید

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

از خودتان بپرسید:

• آیا هر بار اتفاق می‌افتد؟ اگر فقط گاهی، وقتی اتفاق می‌افتد چه چیزی فرق دارد — یک رکورد خاص، اتصال کند، یا خارج شدن از حساب؟
• آیا برای همه کاربران اتفاق می‌افتد؟ با یک حساب دیگر وارد شوید. بسیاری از باگ‌ها فقط برای کاربران جدید بدون داده یا برای کاربری با نقش متفاوت دیده می‌شوند.
• آیا روی همه دستگاه‌ها اتفاق می‌افتد؟ یک صفحه به عرض موبایل و یک مرورگر دیگر را امتحان کنید.
• آیا بعد از یک تغییر مشخص شروع شد؟ اگر دیروز کار می‌کرد، چند تغییر آخر مظنون اصلی‌اند.

مراحل را به‌صورت یک فهرست شماره‌دار کوتاه بنویسید. بعداً آن را در پرامپت می‌چسبانید.

مرحله ۲: پیام خطا را بخوانید

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

لازم نیست آن را بفهمید؛ باید دقیقاً کپی‌اش کنید. «Cannot read properties of undefined (reading 'name')» به هوش مصنوعی می‌گوید که کد داده‌ای را انتظار داشته (احتمالاً یک رزرو یا یک کاربر) که وجود نداشته است. اگر بنویسید «یک خطای undefined»، این اطلاعات از بین می‌رود.

چند مورد رایج، تقریباً ترجمه‌شده:

• خطاهای undefined / null — کد داده‌ای را انتظار داشته که نرسیده. اغلب یک وضعیت بارگذاری یا لیست خالی که کد مدیریتش نکرده.
• 404 Not Found — صفحه یا نشانی API وجود ندارد. اغلب غلط تایپی در یک مسیر یا لینکی به صفحه‌ای که نام آن عوض شده.
• 401 Unauthorized / 403 Forbidden — درخواست وارد حساب نشده، یا کاربر اجازه آن کار را ندارد.
• 500 Internal Server Error — کد سمت سرور کرش کرده است. دلیل واقعی در لاگ‌های سرور است، نه مرورگر.
• خطاهای CORS — مرورگر درخواست به یک دامنه دیگر را مسدود کرده. معمولاً یک مشکل پیکربندی در سمت سرور است.

مرحله ۳: از ابزارهای توسعه‌دهنده مرورگر استفاده کنید

هر مرورگر دسکتاپ ابزارهای توسعه‌دهنده‌ای داخلی دارد («devtools»). آنها نشان می‌دهند صفحه پشت صحنه چه کاری انجام می‌دهد. در Chrome، Edge و Firefox، روی هر جای صفحه راست‌کلیک کنید و Inspect را انتخاب کنید، یا F12 را فشار دهید (روی مک Cmd+Option+I). در Safari، ابتدا منوی Develop را در تنظیمات Safari روشن کنید.

فقط به سه تب نیاز دارید.

Console

تب Console خطاها و پیام‌های کد صفحه را فهرست می‌کند. خطاها به رنگ قرمز نشان داده می‌شوند. اگر دکمه‌ای وقتی کلیک می‌کنید کاری نمی‌کند، کنسول بسیار اغلب یک خطای قرمز را در لحظه کلیک نشان می‌دهد. متن کامل خطا را کپی کنید (در بیشتر مرورگرها راست‌کلیک گزینه کپی دارد).

Network

تب Network هر درخواستی را که صفحه می‌فرستد فهرست می‌کند — بارگذاری داده، ذخیره فرم، ورود. آن را باز کنید، سپس مراحلی را که باگ را ایجاد می‌کند تکرار کنید.

• دنبال ردیف‌های قرمز یا با وضعیت ۴۰۰ به بالا بگردید.
• روی یک ردیف ناموفق کلیک کنید تا Response آن را ببینید. خطای سرور اغلب پیامی دارد که از هر چیزی که روی صفحه است مفیدتر است.
• نشانی درخواست و کد وضعیت را یادداشت کنید — جمله «POST به /api/bookings کد ۵۰۰ برگرداند» جمله بسیار مفیدی برای دادن به هوش مصنوعی است.

اگر باگ شامل بارگذاری مجدد صفحه یا هدایت است، Preserve log را تیک بزنید تا درخواست‌ها ناپدید نشوند.

Elements

تب Elements (یا Inspector) ساختار و استایل صفحه را نشان می‌دهد. برای باگ‌های چیدمان بیشترین کاربرد را دارد: با نشانه‌گذاری روی یک عنصر، اندازه و فاصله‌گذاری آن هایلایت می‌شود. لازم نیست اینجا چیزی را ویرایش کنید؛ کافی است بگویید «فوتر در موبایل ۲٬۰۰۰ پیکسل عرض دارد و صفحه را به کناره هل می‌دهد».

مرحله ۴: لاگ‌های سرور را بررسی کنید

بعضی باگ‌ها روی سرور رخ می‌دهند، جایی که مرورگر نمی‌تواند ببیند. خطای 500 در تب شبکه نشانه کلاسیک آن است. لاگ‌های سرور — خروجی متنی بک‌اند شما وقتی اجرا می‌شود — معمولاً خطای واقعی را همراه با stack trace (فهرست توابعی که هنگام شکست در حال اجرا بودند) دارند.

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

مرحله ۵: باگ را به هوش مصنوعی توصیف کنید

آنچه جمع کرده‌اید را به این شکل بیاورید:

در صفحه Bookings، با حساب عضو: روی Cancel کلاس ۹ صبح فردا کلیک کردم. انتظار: رزرو ناپدید شود و کلاس یک جای خالی بیشتر نشان دهد. واقعیت: روی صفحه چیزی تغییر نمی‌کند. کنسول TypeError: Cannot read properties of undefined (reading 'id') را در BookingCard.tsx:31 نشان می‌دهد، و تب شبکه نشان می‌دهد DELETE /api/bookings/123 کد ۵۰۰ برگردانده. علت را پیدا کن، رفعش کن، و بررسی کن که لغو برای عضوی با یک رزرو و عضوی با چند رزرو کار می‌کند.

چرا هر بخش مهم است:

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

اگر هوش مصنوعی دو بار سعی در رفع کرده و شکست خورده، از آن بخواهید قبل از تغییر هر چیزی توضیح دهد:

هنوز کد را تغییر نده. به نظرت چه چیزی این را ایجاد می‌کند، و چه شواهدی آن را پشتیبانی می‌کند؟

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

مرحله ۶: تأیید کنید، سپس اطراف را بررسی کنید

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

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

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

مرحله ۷: به‌جای انباشتن، برگردید

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

عادت‌های خوبی که برگرداندن را آسان می‌کنند:

• بعد از هر تغییر تست کنید، تا بدانید کدام تغییر چیزی را خراب کرده.
• تغییرات را کوچک نگه دارید — یک ویژگی یا رفع در هر پیام.
• آخرین نسخه خوب را یادداشت کنید قبل از شروع کار ریسکی.
• اگر کد در Git است، نسخه‌های کارکننده را commit کنید تا بتوانید به آنها برگردید.

الگوهای رایج باگ در اپ‌های ساخته‌شده با هوش مصنوعی

وقتی مشکل باگ نیست

بعضی «باگ»ها در واقع این هستند که هوش مصنوعی دقیقاً همان چیزی را ساخته که به آن گفته شده، و توصیف مبهم بوده. اگر رفعی که می‌خواهید در واقع تغییر رفتار است، صریح بگویید: «آن را طوری تغییر بده که…». اگر نمی‌دانید رفتار درست اصلاً چیست، اول همان را تصمیم بگیرید. راهنمای ما درباره نوشتن پرامپت برای ابزارهای ساخت اپ با هوش مصنوعی نشان می‌دهد چطور قاعده‌ها را روشن مشخص کنید. و اگر دارید یک اپ را برای کاربران واقعی آماده می‌کنید، بردن نمونه اولیه AI به محصول واقعی بررسی‌های ارزشمند قبل از راه‌اندازی را پوشش می‌دهد.

دیباگ کردن در Mythex

Mythex برای هر مرحله از چرخه ابزار دارد:

• Preview برای بازتولید باگ، از جمله یک قاب به اندازه موبایل.
• /test باعث می‌شود عامل مثل یک کاربر روی پیش‌نمایش زنده شما کلیک کند و جریان‌های خراب را گزارش دهد.
• /fix عامل را مستقیم به سمت خرابی‌ها هدایت می‌کند.
• حالت Plan به عامل اجازه می‌دهد قبل از ویرایش هر چیزی بررسی کند و توضیح دهد.
• Code → terminal لاگ‌های سرور اپ شما را نشان می‌دهد.
• Revert to this point روی هر پاسخ، پروژه را به آن checkpoint برمی‌گرداند.

اگر انتشار شکست بخورد، پنجره انتشار معمولاً Fix with AI را پیشنهاد می‌دهد که خروجی ساخت یا لاگ‌های اپ را می‌خواند. Debug your app و Publish troubleshooting را در مستندات ببینید.

پرسش‌ها