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

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

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

اشتباه اول: کدی را قبول می‌کنی که نمی‌فهمی

این پرتکرارترین الگوست. دستیار صد خط می‌نویسد، برنامه اجرا می‌شود، تو Accept می‌زنی و می‌روی سراغ کار بعدی. چند روز بعد، پروژه پر است از تکه‌هایی که نمی‌توانی توضیح بدهی چه می‌کنند — و درست همان لحظه‌ای که باید تغییرشان بدهی، هیچ نقشه‌ای در ذهن نداری.

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

درمان

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

یک قالب کوتاه که می‌توانی همیشه دم دست داشته باشی:

قبل از نوشتن کد، این‌ها را بگو:
۱. چه فایل‌هایی عوض می‌شود و در هرکدام چه چیزی؟
۲. چه فرض‌هایی درباره‌ی پروژه‌ی من گذاشته‌ای؟
۳. ساده‌ترین راهی که همین نتیجه را بدهد چیست؟
منتظر تأیید من بمان، بعد کد بنویس.

اشتباه دوم: خیلی می‌سازی، قبل از اینکه به کسی نشان بدهی

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

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

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

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

اشتباه سوم: بدون Git کار می‌کنی

پرهزینه‌ترین اشتباه این فهرست است و در عین حال ساده‌ترین‌شان برای پیشگیری. دستیار هوش مصنوعی گاهی به‌جای اصلاح یک تابع، کل فایل را بازنویسی می‌کند؛ اگر Git نداشته باشی، تنها راه بازگشتت Ctrl+Z است، همان چیزی که با بستن ادیتور از دست می‌رود.

Git برای تو در وهله‌ی اول ابزار همکاری نیست؛ دکمه‌ی بازگشت به آخرین وضعیت سالم است. همین.

git init
git add src/booking.js        # file by file, not "git add ."
git commit -m "booking flow works end to end"
git switch -c feature/payment # one branch per feature
git restore .                 # drop the broken edits
git log --oneline             # find the last good point

• هر بار که چیزی کار کرد کامیت کن، حتی اگر کوچک باشد. پیام کامیت را در حد یک جمله‌ی قابل‌فهم بنویس تا دو هفته بعد به کارت بیاید.
• قبل از هر بازنویسی بزرگ، یک نقطه‌ی سالم داشته باش تا بتوانی بی‌ترس اجازه‌ی تغییر بدهی.
• فایل‌های حساس مثل .env و کلیدهای API را در .gitignore بگذار. کلیدی که یک بار کامیت شود در تاریخچه می‌ماند و پاک‌کردنش از تاریخچه دردسر دارد؛ امن‌ترین کار این است که همان کلید را باطل کنی و کلید تازه بسازی.
• عادت کن فایل‌ها را تک‌تک stage کنی و قبل از هر کامیت یک بار git status بگیری. دستیار ممکن است فایل‌هایی را دست بزند که اصلاً حواست به آن‌ها نبوده.

اشتباه چهارم: خطاها و هشدارها را نادیده می‌گیری

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

الگوی خطرناک‌تر این است که متن خطا را نخوانی و فقط بنویسی «کار نمی‌کند، درستش کن». دستیار هم حدس می‌زند و اغلب به‌جای ریشه، علامت را می‌پوشاند: یک try/catch خالی، یک شرط اضافه، یا مقدار پیش‌فرضی که باگ را چند لایه عقب‌تر پنهان می‌کند.

درمان

• متن کامل خطا را کپی کن، نه خلاصه‌اش. خط اول و مسیر فایل مهم‌ترین بخش‌اند.
• بگو چه‌کار کردی که خطا ظاهر شد و چه انتظاری داشتی. باگِ تکرارپذیر، نصفِ باگِ حل‌شده است.
• سه جا را با هم نگاه کن: کنسول مرورگر، تب Network و لاگ سمت سرور. خطای واقعی معمولاً در یکی از این‌هاست و پیام مبهم در آن یکی.
• بار دوم که همان خطا برگشت، به‌جای «درستش کن» بپرس «ریشه‌اش چیست و چطور مطمئن شویم دیگر برنمی‌گردد؟».

اشتباه پنجم: به جواب‌های مطمئن اما غلط اعتماد می‌کنی

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

دو جای پرخطر را جدی بگیر: هر چیزی که به دنیای بیرون وصل است (نام کتابخانه، امضای API، ساختار پاسخ یک سرویس) و هر چیزی که مدل نمی‌تواند ببیند (نسخه‌ی دقیق ابزارهای تو، داده‌ی واقعی دیتابیس، پیکربندی سرور).

• هر ادعای بیرونی را با اجرا بسنج، نه با خواندن. سریع‌ترین داور، خودِ اجرای کد است.
• وقتی از قابلیتی در یک کتابخانه حرف می‌زند، از مستندات رسمی همان نسخه تأیید بگیر. جواب‌ها به نسخه‌ای گره خورده‌اند که مدل دیده، و پروژه‌ی تو ممکن است جلوتر باشد.
• بپرس «چطور خودم تأییدش کنم؟». پاسخ خوب، راه تأیید را هم می‌دهد؛ پاسخ توخالی معمولاً همین‌جا لو می‌رود.
• برای منطق حساس — پول، دسترسی، محاسبه‌ی تاریخ — یک تست کوچک بنویس. اینجا دقیقاً جایی است که هوش مصنوعی برایت وقت می‌خرد: نوشتن تست برایش سریع است و معیار درستی دست تو می‌ماند.

پرسیدن همان سؤال از دو مدل مختلف هم گاهی کمک می‌کند، ولی این بیشتر سلیقه و بسته به موضوع است تا قاعده‌ای قطعی؛ برای تصمیم‌های معماری معمولاً می‌ارزد، برای رفع یک باگ مشخص بیشتر وقت تلف کردن است.

جدول تشخیص سریع

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

روالی که جلوی هر پنج‌تا را می‌گیرد

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

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

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

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

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

محمدرضا حسینی

مهندس نرم‌افزار و مدرس وایب کدینگ. بیش از ۱۰ سال تجربه ساخت محصولات وب، و سه سال تمرکز روی ساخت محصول با ابزارهای هوش مصنوعی. تا امروز بیش از ۴٬۰۰۰ نفر در دوره‌هایش شرکت کرده‌اند.