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

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

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

حلقه بهبود

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

هر قدم برای این است که تغییرات کوچک و قابل برگشت بمانند.

قدم ۱: یک فهرست کوتاه نگه دارید

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

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

قدم ۲: آنچه می‌بینید را توصیف کنید

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

در صفحه قیمت‌گذاری روی گوشی، دکمه کارت Pro از لبه راست بریده شده. چیدمان دسکتاپ را همان نگه دار؛ در صفحه‌های کمتر از ۶۴۰ پیکسل، کارت‌ها را زیر هم بچین و دکمه‌ها را تمام‌عرض کن.

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

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

قدم ۳: قبل از تغییرات بزرگ برنامه‌ریزی کنید

برای هر چیزی که چند بخش اپ را لمس می‌کند — مدل داده جدید، پرداخت، نقش‌های کاربر — قبل از تغییر کد برنامه بخواهید:

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

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

قدم ۴: بگویید چه نباید تغییر کند

ابزارهای هوش مصنوعی گاهی چیزهایی را که نخواسته‌اید «مرتب» می‌کنند. از آنچه کار می‌کند محافظت کنید:

یک فیلتر تاریخ به جدول سفارش‌ها اضافه کن. ستون‌ها، استایل جدول و دکمه خروجی را تغییر نده.

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

قدم ۵: بیشتر از خود تغییر را بررسی کنید

بعد از هر پرامپت این‌ها را بیازمایید:

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

اگر چیزی درست نیست، دقیق گزارش دهید — چطور یک گزارش باگ خوب بنویسیم را ببینید.

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

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

به‌جای آن:

1. به آخرین نسخه‌ای برگردید که کار می‌کرد (یک نقطه ذخیره یا کامیت Git).
2. بفهمید در پرامپت چه چیزی مبهم بود.
3. با یک درخواست کوچک‌تر یا روشن‌تر دوباره امتحان کنید.

آن تغییر ذخیره پیش‌نویس‌ها را خراب کرد. برگشتم. این بار فقط نشانگر ذخیره خودکار را به‌صورت متن در هدر اضافه کن. روش ذخیره پیش‌نویس‌ها را تغییر نده.

قدم ۷: بدانید کی ساخت دوباره درست است

ساختن دوباره از صفر، جزئیات کاری زیادی را دور می‌ریزد. فقط وقتی ارزش دارد که:

• ایده محصول کاملاً عوض شده باشد.
• ساختار زیرین از نیازهای فعلی پشتیبانی نکند — برای مثال با یک سایت ایستا ساخته شده و حالا به حساب کاربری و پایگاه داده نیاز دارد.
• پروژه هنوز تقریباً خالی باشد.

وقتی دوباره می‌سازید، فهرست کنید چه چیزهایی را نگه دارید: نام، رنگ‌ها، متن‌ها، بخش‌هایی که کاربران دوست داشتند.

نمونه پرامپت‌ها

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

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

سه تغییر آخر را بررسی کن و ببین چیزی جریان پرداخت را خراب کرده یا نه. هنوز ویرایش نکن.

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

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

چک‌لیست

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

بهبود در Mythex

Mythex دور همین حلقه ساخته شده است:

• حالت‌های برنامه، ساخت و پرسش. برنامه قبل از ویرایش رویکرد را بحث می‌کند؛ پرسش بدون تغییر کد جواب می‌دهد؛ ساخت تغییر را انجام می‌دهد. گفت‌وگو را ببینید.
• نقاط ذخیره. بعد از هر نوبت موفق، Mythex یک نقطه ذخیره Git می‌سازد؛ بازگشت به این نقطه برمی‌گرداند. همچنین می‌توانید یک پیام قبلی را ویرایش کنید و لغو و ارسال دوباره را بزنید تا از همان نقطه پرامپت دیگری امتحان کنید. بهبود بدون ساخت دوباره را ببینید.
• دانش. تنظیمات پروژه ← دانش، یادداشت‌های ثابتی را نگه می‌دارد که عامل در هر پیام دنبال می‌کند.
• /test بعد از یک تغییر بزرگ، عامل را وادار می‌کند مثل یک کاربر در پیش‌نمایش کلیک کند.

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

پرسش‌ها