چطور برای ابزارهای ساخت اپلیکیشن با هوش مصنوعی پرامپت بنویسیم (با مثال‌های قبل و بعد)
پرامپت خوب برای ابزار ساخت اپلیکیشن با هوش مصنوعی، محصول را توصیف می‌کند، نه کد را: چه کسی از آن استفاده می‌کند، هر کاربر مرحله‌به‌مرحله چه کاری انجام می‌دهد، چه داده‌ای نگه داشته می‌شود و چه کسی اجازه دارد چه چیزی را ببیند. بعد از اینکه نسخه‌ی اول ساخته شد، در هر پیام یک تغییر مشخص بخواهید، بگویید چه چیزی باید ثابت بماند، و مشکلات را به شکل «این کار را کردم، انتظار داشتم Y را ببینم، X را دیدم» توصیف کنید. این سه عادت بیشتر نتایج ناامیدکننده را درست می‌کنند.
بقیه‌ی این راهنما الگوها را با جزئیات نشان می‌دهد، همراه با مثال‌های قبل و بعد که می‌توانید تطبیقشان دهید.
چرا پرامپت دادن به ابزار ساخت اپلیکیشن با چت با هوش مصنوعی فرق دارد
وقتی از یک دستیار چت سؤالی می‌پرسید، پرامپت مبهم جواب مبهم می‌گیرد و شما ادامه می‌دهید. اما وقتی به یک ابزار ساخت اپلیکیشن پرامپت می‌دهید، جوابش یک برنامه‌ی در حال اجراست. هر جای خالی در توضیح شما با یک حدس پر می‌شود، و این حدس‌ها تبدیل می‌شوند به کد، جدول دیتابیس و صفحاتی که باید با آن‌ها زندگی کنید یا برگردانیدشان.
پس هدف پرامپت این نیست که باهوش به نظر برسد. هدف این است که تعداد تصمیم‌های مهمی که به شانس سپرده می‌شوند کمتر شود. برای این کار لازم نیست واژگان فنی بدانید. فقط باید درباره‌ی چیزهایی که فقط خودتان می‌دانید دقیق باشید: کاربرانتان، جریان کاری و قوانینتان.
چه چیزی در پرامپت اول بگنجانیم
قبل از نوشتن هر چیزی، به این سؤال‌ها جواب دهید. هر کدام یک جای خالی را می‌بندد که وگرنه هوش مصنوعی حدس می‌زد.
| چه چیزی بگنجانید | چرا مهم است | مثال |
|---|---|---|
| محصول در یک جمله | چارچوب همه‌ی تصمیم‌های بعدی را مشخص می‌کند | «سایت رزرو برای یک آرایشگاه مردانه با دو صندلی» |
| چه کسی استفاده می‌کند | صفحات و لحن را تعیین می‌کند | «مشتری‌های بدون رزرو با گوشی، و صاحب آرایشگاه با لپ‌تاپ» |
| جریان اصلی، مرحله‌به‌مرحله | همان چیزی که اول باید کار کند | «یک خدمت انتخاب کن، یک زمان انتخاب کن، نام و تلفن را وارد کن، تأییدیه بگیر» |
| داده‌هایی که نگه داشته می‌شود | طراحی دیتابیس را می‌سازد | «خدمات، رزروها، مشتری‌ها» |
| چه کسی چه چیزی را می‌بیند یا تغییر می‌دهد | ورود و دسترسی‌ها را تعیین می‌کند | «فقط صاحب آرایشگاه همه‌ی رزروها را می‌بیند» |
| ظاهر و حس کلی، مختصر | از یک استایل پیش‌فرض عمومی جلوگیری می‌کند | «تیره، ساده، دکمه‌های بزرگ» |
| آنچه فعلاً کنار گذاشته می‌شود | نسخه‌ی اول را کوچک نگه می‌دارد | «فعلاً پرداخت و نظرات نداریم» |
ردیف آخر دست‌کم گرفته می‌شود. گفتن اینکه چه چیزی را نمی‌خواهید جلوی اضافه شدن وبلاگ، صفحه‌ی قیمت و فرم خبرنامه‌ای که هرگز نخواسته‌اید را می‌گیرد.
قبل و بعد: پرامپت اول
قبل:
برای باشگاه من یک اپ بساز.
ابزار باید همه‌چیز را حدس بزند: اعضا یا کارکنان؟ کلاس یا تمرین شخصی؟ پرداخت؟ نتیجه چیزی شبیه وبسایت باشگاه می‌شود که هیچ‌کدام از کارهای موردنیاز شما را انجام نمی‌دهد.
بعد:
یک اپ رزرو کلاس برای یک استودیوی کوچک یوگا بساز. اعضا کلاس‌های این هفته را می‌بینند (نام، مربی، زمان، جای خالی)، یک جا رزرو می‌کنند، و تا دو ساعت قبل از کلاس می‌توانند لغو کنند. اعضا با ایمیل و رمز عبور ثبت‌نام می‌کنند. صاحب استودیو با ورود به سیستم کلاس اضافه می‌کند، می‌بیند چه کسی رزرو کرده و حضور را ثبت می‌کند. کلاس‌ها، اعضا و رزروها را در دیتابیس نگه دار. طراحی آرام و روشن که روی گوشی خوب کار کند. فعلاً پرداختی نداریم.
نسخه‌ی دوم هنوز کوتاه است. فقط به پرسش‌های جدول بالا جواب می‌دهد.
رفتار را توصیف کنید، نه پیاده‌سازی را
اغلب با توصیف آنچه باید اتفاق بیفتد، به‌جای اینکه بگویید چطور باید ساخته شود، نتیجه‌ی بهتری می‌گیرید.
قبل:
یک useEffect اضافه کن که رزروها را می‌گیرد و یک کامپوننت مودال برای ویرایش.
بعد:
وقتی صاحب کسب‌وکار روی یک رزرو کلیک می‌کند، یک پنل باز شود که بتواند زمان را عوض کند یا آن را لغو کند. تغییرات باید بلافاصله در فهرست دیده شوند.
پرامپت اول هوش مصنوعی را به یک تکنیک خاص قفل می‌کند که شاید با روش ساخته شدن اپ جور نباشد. پرامپت دوم نتیجه را می‌گوید و اجازه می‌دهد برای کدی که قبلاً نوشته شده، رویکرد درست را انتخاب کند. اگر توسعه‌دهنده هستید و ترجیح قوی دارید، آن را بگویید، اما همراه با نتیجه‌ی موردنظر.
درباره‌ی قوانین دقیق باشید
قوانین کسب‌وکار جایی هستند که اپ‌های ساخته‌شده با هوش مصنوعی بیشتر اشتباه می‌کنند، چون برای شما بدیهی‌اند و برای هوش مصنوعی نامرئی. آن‌ها را کامل بنویسید.
- محدودیت‌ها: «یک عضو حداکثر می‌تواند سه رزرو آینده داشته باشد.»
- زمان‌بندی: «لغوها دو ساعت قبل از شروع کلاس بسته می‌شوند.»
- حالت‌های لبه: «اگر کلاسی پر است، به‌جای دکمه‌ی رزرو، دکمه‌ی لیست انتظار نشان داده شود.»
- دسترسی‌ها: «مربی‌ها می‌توانند حضور کلاس‌های خودشان را ببینند، نه کلاس‌های مربی‌های دیگر.»
هر کدام از این‌ها یک جمله است. جا انداختن هر کدام یعنی اپ یا آن قانون را اعمال نمی‌کند، یا نسخه‌ی خودش از آن را اختراع می‌کند.
بعد از نسخه‌ی اول: در هر پیام یک تغییر
وقتی چیزی در پیش‌نمایش در حال اجراست، از توصیف کل محصول به درخواست تغییرات کوچک و قابل بررسی بروید.
قبل:
طراحی درست نیست، رزرو درست کار نمی‌کند، و یک نمای تقویم و ایمیل هم می‌خواهم.
بعد (به‌صورت چهار پیام جدا):
۱. وقتی آخرین جای کلاسی را رزرو می‌کنم، کلاس هنوز «یک جای خالی» نشان می‌دهد. باید «تکمیل» نشان دهد و دکمه‌ی رزرو پنهان شود. ۲. یک نمای تقویم هفتگی در صفحه‌ی برنامه اضافه کن، با یک ستون برای هر روز. نمای فهرستی فعلی را به‌عنوان گزینه نگه دار. ۳. کارت‌های کلاس را روی گوشی فشرده‌تر کن: حاشیه‌ی کمتر، نام مربی هم‌خط با زمان. ۴. وقتی عضو رزرو می‌کند، برایش ایمیل تأییدیه بفرست.
چرا این روش جواب می‌دهد:
- هر تغییر آن‌قدر کوچک است که هوش مصنوعی بتواند در یک بار درست انجامش دهد.
- می‌توانید هر کدام را پیش از رفتن به بعدی تست کنید.
- اگر یکی اشتباه شد، فقط همان مرحله را برگردانید بدون اینکه بقیه را از دست بدهید.
بگویید چه چیزی را نگه دارد
وقتی تغییری در چیزی می‌خواهید که از قبل کار می‌کند، به هوش مصنوعی بگویید چه چیزی نباید عوض شود. این ساده‌ترین راه جلوگیری از رگرسیون است (چیزهایی که قبلاً کار می‌کردند و بعد از یک ویرایش خراب می‌شوند).
بخش اصلی صفحه‌ی اول را با یک تیتر بزرگ‌تر و یک عکس در سمت راست بازطراحی کن. ناوبری، رنگ‌ها و هر چیزی زیر بخش اصلی را دقیقاً همان‌طور که هست نگه دار.
همین قاعده برای داده‌ها هم صادق است: «یک فیلد شماره‌ی تلفن به اعضا اضافه کن. هیچ فیلد موجودی را حذف یا تغییر نام نده.»
از اسکرین‌شات و متن دقیق استفاده کنید
کلماتی مثل «اون چیزی که بالاست» مبهم‌اند. بیشتر ابزارهای ساخت اپلیکیشن تصویر را می‌پذیرند، و یک اسکرین‌شات با یک یادداشت کوتاه سریع‌تر از یک پاراگراف توصیف است.
- یک اسکرین‌شات پیوست کنید و بگویید «دکمه‌ای که دورش قرمز کشیده‌ام روی گوشی روی منو می‌افتد».
- متن دقیق هر پیام خطا را کپی کنید، نه اینکه آن را با کلمات خودتان بازگو کنید.
- برچسب‌های روی صفحه را دقیق نقل کنید: «دکمه‌ی ذخیره تغییرات در صفحه‌ی تنظیمات».
برای باگ‌ها، این شکل را به کار ببرید:
در صفحه‌ی رزروها، روی لغو یک رزرو برای فردا کلیک کردم. انتظار داشتم از فهرستم حذف شود. اما هیچ اتفاقی نیفتاد و بعد از رفرش هم رزرو هنوز آنجاست. درستش کن و بررسی کن که لغو کار می‌کند.
راهنمای ما درباره‌ی چطور یک اپ ساخته‌شده با هوش مصنوعی را دیباگ کنیم این موضوع را عمیق‌تر توضیح می‌دهد.
برای تغییرات بزرگ اول برنامه‌ریزی کنید
برای هر کاری که به بخش‌های زیادی از اپ دست می‌زند، مثل افزودن حساب کاربری به اپی که نداشت، افزودن پرداخت، یا تغییر ساختار داده‌ها، قبل از هر تغییری در کد، یک برنامه بخواهید.
قبل از تغییر هر چیزی، توضیح بده چطور حساب‌های تیمی را اضافه می‌کنی: چه جدول‌های جدیدی، کدام صفحات تغییر می‌کنند، و برای کاربران فعلی چه اتفاقی می‌افتد. هنوز کد را ویرایش نکن.
برنامه را بخوانید. اگر چیزی را اشتباه فهمیده، اصلاح یک پاراگراف خیلی ارزان‌تر از اصلاح یک قابلیت تمام‌شده است. بسیاری از ابزارها حالت مخصوص این کار دارند؛ در Mythex این حالت Plan است، در کنار Build و Ask.
از چه چیزهایی دوری کنید
| اجتناب کنید | چرا | به‌جایش |
|---|---|---|
| «بهترش کن» / «جذابش کن» | هدفی ندارد، پس هوش مصنوعی تصادفی چیزها را عوض می‌کند | تغییر را نام ببرید: «فاصله‌ی بیشتر بین بخش‌ها، تیترهای بزرگ‌تر» |
| یک پرامپت غول‌پیکر با ده قابلیت | خطاها روی هم جمع می‌شوند؛ تست آن سخت است | در هر پیام یک قابلیت |
| چسباندن کلید API در گفتگو | کلیدها در تاریخچه‌ی گفتگو می‌مانند | از بخش راز (secrets) یا تنظیمات محیطی ابزار استفاده کنید |
| بحث کردن با یک نتیجه‌ی خراب | هر اصلاح روی باگ قبلی سوار می‌شود | برگردید، سپس دوباره بنویسید |
| مشخص کردن کدی که نمی‌فهمید | جای نامناسب را قفل می‌کند | رفتاری که می‌خواهید را توصیف کنید |
| درخواست «امنیت در سطح سازمانی» | معنای مشخصی ندارد | قوانین واقعی را فهرست کنید: چه کسی چه چیزی را می‌بیند |
درباره‌ی کلیدهای API: اگر به سرویس پرداخت یا ایمیل نیاز دارید، کلیدهایش را در بخش رازهای پروژه بگذارید، نه در پرامپت. اگر این مفهوم برایتان تازه است، ببینید متغیرهای محیطی و رازها چیستند.
الگوهای پرامپت قابل استفاده‌ی مجدد
این‌ها را با جایگزین کردن بخش‌های داخل کروشه تطبیق دهید.
اپ جدید:
یک [نوع اپ] برای [چه کسانی] بساز. آن‌ها [جریان اصلی، مرحله‌به‌مرحله]. [نوع دوم کاربر] وارد می‌شود تا [کار او]. [داده‌ها] را در دیتابیس نگه دار. [ظاهر و حس کلی]. [چیزهای برای بعد] را فعلاً کنار بگذار.
قابلیت جدید:
[قابلیت] را به [صفحه] اضافه کن. وقتی [کاربر] [عمل] را انجام می‌دهد، [چه اتفاقی باید بیفتد]. فقط [چه کسی] می‌تواند [کار]. [چیزهای موجود] را همان‌طور که هستند نگه دار.
تغییر طراحی:
در [صفحه]، [عنصر مشخص] را به [تغییر مشخص] تغییر بده. [آنچه باید بماند] را نگه دار. بررسی کن که روی صفحه‌ای به عرض گوشی درست دیده شود.
باگ:
در [صفحه]، [مراحل] را انجام دادم. انتظار داشتم [انتظار]. اما [واقعیت، به‌همراه متن دقیق خطا]. درستش کن و بررسی کن که جریان کار می‌کند.
سؤال بدون تغییر:
هیچ کدی را تغییر نده. توضیح بده [بخشی از اپ] چطور کار می‌کند و [داده] کجا ذخیره می‌شود.
نوشتن یک مشخصات بلندتر
برای پروژه‌های بزرگ‌تر، کمک می‌کند ابتدا یک بریف یک‌صفحه‌ای بنویسید و آن را به‌عنوان اولین پرامپت بچسبانید: کاربران، جریان‌های اصلی، داده‌ها، قوانین و آنچه کنار گذاشته شده. حتی می‌توانید از هوش مصنوعی کمک بگیرید تا پیش‌نویسش را بنویسد؛ راهنمای ما درباره‌ی نوشتن سند نیازمندی‌های محصول با هوش مصنوعی نشان می‌دهد چطور. فقط درخواست اول ساخت را به جریان اصلی محدود کنید و بقیه را قدم‌به‌قدم اضافه کنید.
پرامپت‌نویسی در Mythex
همه‌ی این‌ها در Mythex کار می‌کند. چند نکته‌ی مشخص که کمک می‌کند:
- حالت‌های Build، Plan و Ask. برای تغییرات بزرگ یا پرخطر از Plan استفاده کنید و وقتی توضیح بدون ویرایش می‌خواهید از Ask.
- نقطه‌های بازیابی (Checkpoints). بعد از هر تغییر موفق، Mythex یک نقطه‌ی بازیابی ذخیره می‌کند و Revert to this point روی یک پاسخ، پروژه را به آن نقطه برمی‌گرداند. همچنین می‌توانید یک پیام قبلی را ویرایش کنید و دوباره بفرستید تا از همان نقطه، پرامپت دیگری امتحان کنید.
- کارت رازها (Secrets). وقتی عامل به یک کلید API نیاز دارد، از طریق یک کارت در گفتگو می‌پرسد تا مقدار به‌عنوان راز پروژه ذخیره شود، نه اینکه در پیام شما نوشته شود.
- تصاویر. اسکرین‌شات یا ماکت پیوست کنید؛ عامل آن‌ها را می‌بیند.
مستندات یک صفحه‌ی کوتاه درباره‌ی پرامپت‌های مؤثر و یکی درباره‌ی اصلاح بدون ساختن دوباره دارد. اگر از صفر شروع می‌کنید، چطور با هوش مصنوعی اپلیکیشن بسازیم یک پروژه‌ی کامل را قدم‌به‌قدم نشان می‌دهد، و چطور با هوش مصنوعی یک اپ خوش‌ظاهر طراحی کنیم پرامپت‌ها برای بهتر کردن ظاهر را پوشش می‌دهد.
پرسش‌ها
پرامپت برای ابزار ساخت اپلیکیشن با هوش مصنوعی چقدر باید باشد؟
برای نسخه‌ی اول، معمولاً یک پاراگراف کوتاه از چهار تا هشت جمله کافی است: چه کسانی اپ را استفاده می‌کنند، جریان اصلی چیست، چه داده‌ای نگه می‌دارد و چه کسی چه چیزی را می‌بیند. بعد از آن، پرامپت‌های کوتاهی که هر بار یک تغییر را درخواست می‌کنند، بهتر از پرامپت‌های بلند جواب می‌دهند.
آیا باید به هوش مصنوعی بگویم از کدام فریم‌ورک یا زبان استفاده کند؟
فقط اگر دلیلی دارید، مثل اینکه توسعه‌دهنده‌ای قرار است کد را ادامه دهد یا سرویسی فقط با یک پشته‌ی فنی کار می‌کند. در غیر این صورت، محصول را توصیف کنید و بگذارید ابزار گزینه‌های پیش‌فرض معقول را انتخاب کند.
چرا هوش مصنوعی چیزهایی را عوض می‌کند که از آن نخواسته‌ام؟
معمولاً به این دلیل که پرامپت کلی بوده (مثلاً «بهترش کن») یا نگفته چه چیزی باید ثابت بماند. دقیقاً همان چیزی را که باید عوض شود نام ببرید، بگویید چه چیزی باید همان‌طور بماند، و در هر پیام یک تغییر بخواهید.
برای اصلاح یک نتیجه‌ی بد، بهتر است با پرامپت بیشتر درستش کنم یا از اول شروع کنم؟
اگر آخرین تغییر اوضاع را بدتر کرده، به نسخه‌ی قبل از آن برگردید و دوباره بنویسید، به‌جای اینکه اصلاحات را روی هم انباشته کنید. فقط وقتی یک پروژه‌ی جدید شروع کنید که خود ایده عوض شده باشد.