وایب‌کدینگ چیست؟ راهنمای ساخت محصول با هوش مصنوعی، از ایده تا تحویل

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

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

۱. وایب‌کدینگ چیست و چه چیزی نیست؟

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

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

ابزار کدنویسی، مدل و API را جدا بشناسید. ابزار می‌تواند فایل‌ها را بخواند، تغییر پیشنهاد دهد و تست اجرا کند؛ مدل توان تحلیل و تولید را فراهم می‌کند؛ API یکی از مسیرهای اتصال به آن توان است. مستندات ابزارهایی مانند GitHub Copilot نیز از مسیر بررسی مخزن، برنامه‌ریزی، تغییر و بازبینی صحبت می‌کنند. [۱] امکانات دقیق هر ابزار را باید در همان ابزار بررسی کرد.

۲. برای چه پروژه‌هایی شروع مناسبی است؟

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

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

۳. برای وایب‌کدینگ کدام مدل را انتخاب کنیم؟

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

برای فهرست اولیه، خانواده‌های GPT و Claude، مدل‌های Gemini، Qwen Coder، DeepSeek، Kimi، GLM، MiniMax و MiMo را می‌توان بررسی کرد؛ انتخاب نهایی باید با نسخه دقیق و کار واقعی انجام شود. راهنمای مقایسه کاربردی مدل‌ها برای پروژه‌های مختلف توضیح می‌دهد چگونه گزینه‌ها را بدون تکیه بر تبلیغات رتبه‌بندی کنید.

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

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

۴. پیش از اولین پرامپت، یک صورت‌مسئله یک‌صفحه‌ای بنویسید

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

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

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

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

۵. چرخه عملی: بخوان، پیشنهاد بده، تغییر بده، ثابت کن

مرحله اول: شناخت وضعیت موجود

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

مرحله دوم: تعیین خروجی قابل مشاهده

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

مرحله سوم: یک تغییر محدود

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

مرحله چهارم: شواهد تحویل

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

۶. زمینه کافی بدهید؛ همه اطلاعات را یک‌جا نریزید

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

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

برای یک باگ، سه چیز بسیار ارزشمند است: ورودی مشخص، نتیجه واقعی و نتیجه مورد انتظار. مثلاً «در موبایل دکمه کار نمی‌کند» را به «در عرض ۳۹۰، بعد از بازکردن فیلتر، دکمه اعمال زیر پنل قرار می‌گیرد» تبدیل کنید. مدل در حالت دوم، مسئله هندسی یا لایه‌بندی را هدفمندتر بررسی می‌کند.

۷. چهار پرامپت کاربردی برای کار روزمره

پرامپت شناخت قبل از تغییر

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

پرامپت پیاده‌سازی یک قابلیت

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

پرامپت بازبینی

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

پرامپت تحویل

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

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

۸. چطور رابط خوب بخواهیم و نتیجه را بررسی کنیم؟

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

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

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

۹. اتصال مدل به محصول؛ محل کلید و کنترل هزینه

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

اگر ابزار یا محیط کدنویسی شما قابلیت اتصال سفارشی دارد، سازگاری آن را مرحله‌ای بررسی کنید: احراز هویت، مدل مجاز، یک پاسخ ساده و سپس ابزار یا قابلیت اختیاری. پشتیبانی از یک درخواست متنی به معنی پشتیبانی همه حالت‌های Agent، تصویر یا stream نیست. در IranNet AI API انتخاب مدل و مصرف از مسیر محصول یکپارچه دنبال می‌شود؛ قابلیت دقیق اتصال را با مستندات و دسترسی حساب تطبیق دهید.

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

۱۰. آزمون‌هایی که باید قبل از تحویل ببینید

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

برای کد موجود، تست رگرسیون لازم است: آیا رفتار سالم قبلی باقی مانده؟ اگر فیلتر اضافه شده، صفحه‌بندی و محدودیت دسترسی را دوباره بررسی کنید. اگر فقط رنگ دکمه عوض شده، بازآزمایی همه ماژول‌ها ممکن است ضرورتی نداشته باشد. آزمون باید ریسک واقعی را هدف بگیرد.

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

۱۱. وقتی مدل چند بار مشکل را حل نمی‌کند

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

مثال: دکمه فرم ظاهراً کار نمی‌کند. علت ممکن است handler وصل‌نشده، خطای اعتبارسنجی، درخواست شبکه ناموفق یا لایه‌ای روی دکمه باشد. هر کدام شواهد متفاوت دارد. یک بار خواندن console و وضعیت شبکه، می‌تواند از چند بازنویسی بی‌ربط جلوگیری کند.

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

۱۲. امنیت در کار با عامل کدنویسی

مدل برای کمک به توسعه به همه کلیدها، فایل‌های خصوصی یا محیط تولید نیاز ندارد. دسترسی را به فایل‌ها و عملیات لازم محدود کنید. OWASP درباره خطر ابزارهای بیش‌ازحد قدرتمند و اختیارات بیش‌ازحد در سیستم‌های عامل‌محور هشدار می‌دهد. [۲] برای شروع، داده ساختگی و محیطی با امکان برگشت انتخاب کنید.

متن README یک مخزن، نتیجه جست‌وجو یا محتوای یک فایل می‌تواند دستور نامرتبط داشته باشد. این داده نباید خودکار اجازه ارسال فایل، نصب ابزار یا اجرای فرمان حساس تلقی شود. خطر Prompt Injection فقط مربوط به چت‌بات عمومی نیست؛ در ابزار متصل به فایل و ترمینال هم مرز اعتماد اهمیت دارد. [۳]

پیش از اجرای فرمان مخرب یا migration، اثر را بفهمید. درخواست نصب یک وابستگی جدید را با مسئله واقعی تطبیق دهید: آیا لازم است؟ آیا بسته و نسخه معتبرند؟ آیا قابلیت موجود در پروژه کافی است؟ اضافه‌کردن وابستگی برای هر مشکل کوچک، سطح نگهداری را بزرگ می‌کند.

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

۱۳. تحویل حرفه‌ای: فقط یک ZIP نیست

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

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

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

۱۴. نمونه کامل یک مسیر کوچک از ایده تا نتیجه

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

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

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

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

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

۱۵. پرسش‌های متداول وایب‌کدرها