چطور کد تولیدشده با هوش مصنوعی را بررسی کنیم

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

هوش مصنوعی کدی می‌نویسد که معمولاً اجرا می‌شود و اغلب مرتب به نظر می‌رسد. همین باعث می‌شود بی‌آنکه واقعاً بررسی کنید آن را تأیید کنید. این راهنما یک روال بررسی است که چه کد را روان بخوانید و چه اصلاً نخوانید کار می‌کند.

بررسی را با ریسک متناسب کنید

هر تغییری به یک میزان توجه نیاز ندارد.

گام ۱: ببینید چه تغییر کرده

پیش از قضاوت درباره کد، فهرست تغییرات را بگیرید:

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

هر فایلی را که در آخرین تغییر عوض کردی فهرست کن، و برای هر کدام در یک جمله توضیح بده چه تغییری کرده و چرا.

نشانه‌های خطر در این مرحله: فایل‌هایی که ربطی به درخواست ندارند، فایل‌های حذف‌شده، تغییر در تنظیمات یا وابستگی‌هایی که نخواسته بودید.

گام ۲: اول رفتار را آزمایش کنید

خواندن کد به شما می‌گوید قرار است چه کاری کند؛ آزمایش به شما می‌گوید واقعاً چه می‌کند. پیش از خواندن:

• تغییر را مثل یک کاربر عادی امتحان کنید، هم روی دسکتاپ و هم روی صفحه‌ای به اندازه گوشی.
• با ورودی اشتباه امتحان کنید: فیلدهای خالی، متن خیلی بلند، عدد منفی، تاریخ گذشته.
• بدون ورود و با کاربر دیگری امتحان کنید.
• جریان‌هایی را که بیشتر اهمیت دارند دوباره اجرا کنید: ثبت‌نام، ورود، کار اصلی، پرداخت.

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

گام ۳: بررسی دسترسی‌ها در سمت سرور

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

برای هر مسیر یا تابعی که داده را می‌خواند یا تغییر می‌دهد، بپرسید:

• آیا بررسی می‌کند کاربر وارد شده است؟
• آیا بررسی می‌کند این کاربر اجازه دسترسی به این رکورد را دارد؟
• آیا این بررسی روی سرور است، نه فقط در صفحه؟

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

سپس آزمایشش کنید: با کاربر A وارد شوید، شناسه یک رکورد را یادداشت کنید، سپس با کاربر B وارد شوید و همان رکورد را درخواست کنید. چک‌لیست امنیتی اپ‌های ساخته‌شده با هوش مصنوعی آزمون کامل را دارد.

گام ۴: دنبال اسرار افشاشده بگردید

• در فایل‌های تغییرکرده دنبال هر چیزی بگردید که شبیه کلید یا رمز عبور است.
• بررسی کنید کلیدهای مخفی از متغیرهای محیطی خوانده می‌شوند و فقط در کد سرور استفاده می‌شوند.
• مراقب پیشوندهای عمومی مانند VITE_ یا NEXT_PUBLIC_ روی متغیرهای مخفی باشید — آن‌ها داخل کد مرورگر ساخته می‌شوند.

به چطور کلیدهای API را امن نگه داریم مراجعه کنید.

گام ۵: ورودی و خطاها را بررسی کنید

• اعتبارسنجی روی سرور. بررسی‌های مرورگر را می‌توان دور زد. فیلدهای الزامی، طول‌ها، قالب‌ها و مقادیر مجاز باید روی سرور هم چک شوند.
• کوئری‌های پایگاه داده از پارامتر استفاده کنند، نه متنی که با چسباندن ورودی کاربر ساخته شده.
• خطاها نادیده گرفته نشوند. یک try/catch که هیچ کاری نمی‌کند شکست‌ها را پنهان می‌کند. خطاها باید ثبت شوند و کاربر یک پیام ساده ببیند.
• جزئیات داخلی به کاربر نشان داده نشود — stack trace و خطاهای پایگاه داده باید در لاگ‌ها بمانند.

گام ۶: مطمئن شوید واقعی است

مدل‌های هوش مصنوعی گاهی کدی تولید می‌کنند که درست به نظر می‌رسد اما به چیزهایی اشاره می‌کند که وجود ندارند.

• پکیج‌ها: هر وابستگی جدید باید یک پکیج واقعی و نگه‌داری‌شده با همان نام دقیق باشد. مراقب نام‌هایی باشید که شبیه غلط‌املایی پکیج‌های معروف هستند.
• توابع و گزینه‌های API: اگر کد تابع کتابخانه یا گزینه‌ای از یک API خارجی را صدا می‌زند که تا حالا ندیده‌اید، مستندات رسمی را بررسی کنید.
• کد جای‌نگهدار: دنبال TODO، mock، fake، داده نمونه‌ای که داخل کد نوشته شده، یا توابعی که یک مقدار ثابت برمی‌گردانند بگردید.

آیا پکیج جدیدی اضافه کردی؟ برای هر کدام، نام دقیق، کاربردش و اینکه آیا می‌شد بدونش کار کرد را بگو.

گام ۷: بررسی کنید جا می‌افتد

کد می‌تواند کار کند و همچنان تغییر دادن اپ را بعداً سخت‌تر کند:

• تکرار. همان منطق که در چند جا کپی شده، به‌مرور از هم جدا می‌شود.
• یکدستی. باید از الگوهایی پیروی کند که بقیه اپ استفاده می‌کند.
• حجم. یک درخواست ۲۰ خطی که ۶۰۰ خط کد تولید کرده، سؤال می‌خواهد.
• کد مرده. نسخه‌های قدیمی که کنار نسخه‌های جدید مانده‌اند.

آیا در پروژه کدی هست که حالا به‌خاطر این تغییر استفاده نمی‌شود، یا منطقی که جای دیگری تکرار شده؟ چیزی را تغییر نده؛ فقط فهرستش کن.

اشتباه‌های رایج

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

چک‌لیست

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

بررسی کد در Mythex

• حالت Ask به سؤال‌ها درباره کد پاسخ می‌دهد بدون اینکه آن را ویرایش کند — ایده‌آل برای درخواست‌هایی مانند «هر تغییر را توضیح بده» و «کدام مسیرها بررسی دسترسی ندارند». گفتگو را ببینید.
• نمای کد درخت فایل، ویرایشگر و ترمینال را در هر پلن نشان می‌دهد (در Free فقط خواندنی، در Pro قابل ویرایش)، تا خودتان بتوانید آنچه تغییر کرده را بخوانید. ویرایشگر کد را ببینید.
• /test باعث می‌شود عامل مثل یک کاربر در پیش‌نمایش کلیک کند و جریان‌های خراب را گزارش دهد.
• نقطه‌های بازیابی (Checkpoints) به شما اجازه می‌دهند تغییری را که در بررسی رد می‌شود برگردانید.

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

پرسش‌ها