نحوه کار با یک توسعه‌دهنده روی اپلیکیشنی که با هوش مصنوعی ساخته شده
برای کار خوب با یک توسعه‌دهنده روی اپلیکیشنی که با هوش مصنوعی ساخته‌اید، کد را در یک مخزن Git، یک خلاصهٔ یک‌صفحه‌ای از کاری که اپلیکیشن انجام می‌دهد و چرایی آن، و یک کار روشن‌تعریف‌شده با تعریف پایان کار در اختیارش بگذارید. توافق کنید چه کسی کدام بخش‌ها را تغییر می‌دهد تا شما و هوش مصنوعی کار او را بازنویسی نکنید، مخزن و حساب‌های میزبانی را به نام خودتان نگه دارید، و رازها را از طریق تنظیمات مناسب به اشتراک بگذارید، نه در پیام‌ها.
خیلی‌ها نسخهٔ اول اپلیکیشن را با هوش مصنوعی می‌سازند و بعد یک توسعه‌دهنده می‌آورند — برای افزودن پرداخت، رفع چیزی که هوش مصنوعی مدام اشتباه انجام می‌دهد، بررسی امنیت، یا تحویل گرفتن کد وقتی اپلیکیشن بزرگ می‌شود. اگر هنوز تصمیم نگرفته‌اید که اصلاً استخدام کنید یا نه، استخدام توسعه‌دهنده یا ساخت با هوش مصنوعی را ببینید. این راهنما فرض می‌کند تصمیم گرفته‌اید و می‌خواهید همکاری روان پیش برود.
چه زمانی یک توسعه‌دهنده ارزشش را دارد
دلایل رایج برای آوردن کسی:
- یک مشکل که هوش مصنوعی بعد از چند تلاش روشن و برگشت به عقب حلش نمی‌کند.
- حوزه‌های پرریسک: پرداخت‌ها، دسترسی‌ها، داده‌های حساس، مهاجرت‌های پایگاه داده.
- بررسی امنیت یا کد پیش از انتشار یا پیش از پذیرش مشتریان بزرگ‌تر.
- عملکرد وقتی ترافیک واقعی برسد.
- رشد: اپلیکیشن به یک کسب‌وکار تبدیل شده و به کسی نیاز دارد که مالک کد باشد.
روشن بودن اینکه کدام‌یک از این‌ها مدنظر است، همه‌چیز پایین‌تر را شکل می‌دهد.
مرحلهٔ ۱: کد را در جایی قابل اشتراک قرار دهید
توسعه‌دهندگان از مخازن Git کار می‌کنند. پیش از تماس با کسی:
- پروژه را به یک مخزن خصوصی GitHub (یا مشابه) وصل کنید، یا آن را خروجی بگیرید.
- مطمئن شوید هیچ رازی در کد یا تاریخچه نیست. ببینید نحوهٔ نگه‌داری امن کلیدهای API.
- بررسی کنید که پروژه از یک نسخهٔ تازه اجرا می‌شود — از هوش مصنوعی بخواهید مراحل راه‌اندازی را بنویسد.
یک README برای توسعه‌دهنده‌ای که به این پروژه می‌پیوندد بنویس: اپلیکیشن چه کاری انجام می‌دهد، پشته فناوری، نحوهٔ نصب و اجرای محلی، متغیرهای محیطی لازم (فقط نام‌ها)، ساختار پوشه‌ها، و هر چیز شکننده یا غیرعادی.
اگر Git برایتان تازه است، نحوهٔ استفاده از Git با اپلیکیشنی که با هوش مصنوعی ساخته شده مبانی را پوشش می‌دهد.
مرحلهٔ ۲: یک بریف یک‌صفحه‌ای بنویسید
توسعه‌دهنده تاریخچهٔ گفتگوی شما را ندیده است. زمینه را در یک صفحه بدهید:
- اپلیکیشن چه کاری می‌کند، برای چه کسانی، و چند نفر از آن استفاده می‌کنند.
- چه چیزی بیش از همه اهمیت دارد — جریان‌هایی که هرگز نباید خراب شوند.
- مشکلات شناخته‌شده و آنچه قبلاً امتحان کرده‌اید.
- کار، و اینکه چطور تشخیص می‌دهید تمام شده.
- محدودیت‌ها: بودجه، مهلت، چیزهایی که نباید عوض کنند.
یک «تعریف پایان کار» خوب قابل آزمایش است: «کاربر واردشده می‌تواند با Stripe Checkout یک طرح ماهانه بخرد، طرح در صفحهٔ حساب او نمایش داده شود، و لغو در پورتال مشتری او را در پایان دوره به سطح پایین‌تر ببرد.» نه «پرداخت‌ها را سروسامان بده».
مرحلهٔ ۳: دسترسی را امن بدهید
- کد: او را به‌عنوان همکار به مخزن اضافه کنید. بعد از شروع کار، فایل ZIP بین خودتان رد و بدل نکنید.
- ابزار ساخت: اگر ابزار ساخت اپلیکیشن با هوش مصنوعی شما از اعضای تیم پشتیبانی می‌کند، او را به یک فضای کاری دعوت کنید که فقط همین پروژه را داشته باشد.
- رازها: آن‌ها را در تنظیمات میزبان اضافه کنید، یا از طریق یک مدیر رمز عبور به اشتراک بگذارید. هرگز کلیدها را در ایمیل یا گفتگو قرار ندهید.
- حساب‌های آزمایشی: با داده‌های آزمایشی بسازیدشان، به‌جای اینکه ورود خودتان را به اشتراک بگذارید.
- داده‌های واقعی: فقط اگر واقعاً نیاز دارد، و فقط آنچه لازم دارد.
مخزن، دامنه و حساب‌های میزبانی را به نام خودتان نگه دارید. افراد را اضافه کنید؛ حساب‌ها را تحویل ندهید.
مرحلهٔ ۴: توافق کنید چه کسی چه چیزی را تغییر می‌دهد
بزرگ‌ترین منبع اصطکاک این است که دو طرف — شما با یک هوش مصنوعی، و توسعه‌دهنده — همزمان یک کد را تغییر دهند. یک قاعده انتخاب کنید:
| رویکرد | چطور کار می‌کند | مناسب برای |
|---|---|---|
| تقسیم بر اساس حوزه | شما و هوش مصنوعی متن، صفحات و استایل را انجام می‌دهید؛ توسعه‌دهنده پرداخت‌ها، داده‌ها و API را در اختیار دارد | همکاری مستمر |
| نوبتی | وقتی توسعه‌دهنده روی یک branch کار می‌کند، شما هوش مصنوعی را متوقف می‌کنید، و بعد تغییراتش را pull می‌کنید | یک کار واحد و روشن |
| تحویل کامل | توسعه‌دهنده کنترل را می‌گیرد؛ شما درخواست‌ها و گزارش خطاها را ثبت می‌کنید | اپلیکیشن از ابزار ساخت بزرگ‌تر شده |
هر کدام را که انتخاب کنید: قبل از هر جلسهٔ پرامپت، آخرین کد را pull کنید، و تغییرات بزرگ را روی branchهایی بگذارید که طرف دیگر بتواند بازبینی کند.
مرحلهٔ ۵: کتبی ارتباط برقرار کنید
- مشکلات را با مراحل، نتیجهٔ مورد انتظار و نتیجهٔ واقعی گزارش دهید. ببینید نحوهٔ نوشتن یک گزارش خطای خوب.
- تصمیم‌ها را در یک جا نگه دارید: یک ردیاب مسئله، یک سند مشترک، یا نظرهای pull request.
- از او بخواهید در هر pull request تغییرات را با زبان ساده توضیح دهد.
- توافق کنید هر چند وقت یک‌بار بررسی کنید.
مرحلهٔ ۶: کار او را بازبینی کنید
برای بازبینی کار لازم نیست کد بخوانید. بررسی کنید:
- آیا طبق بریف عمل می‌کند، روی پیش‌نمایش یا نسخهٔ staging.
- آیا چیز دیگری خراب نشده — جریان‌های حیاتی‌تان را اجرا کنید.
- آیا توضیح داده چه چیزی را و چرا تغییر داده.
- آیا رازی در کد ظاهر نشده.
برای نگاه دقیق‌تر، نحوهٔ بازبینی کد تولیدشده با هوش مصنوعی یک چک‌لیست دارد که برای کد نوشته‌شده توسط انسان هم کار می‌کند. همچنین می‌توانید از ابزار ساخت با هوش مصنوعی بخواهید pull request توسعه‌دهنده را با زبان ساده برایتان توضیح دهد.
مرحلهٔ ۷: مالکیت را روشن نگه دارید
- مخزن، میزبانی، دامنه و حساب‌های شخص‌ثالث به نام شما می‌مانند.
- مالکیت کدی که می‌نویسند را پیش از شروع کار کتبی کنید. برای پرسش‌های قراردادی قوانین محلی یا یک مشاور را بررسی کنید.
- وقتی کار تمام شد، دسترسی‌شان را بردارید و هر کلیدی که دیده‌اند را عوض کنید.
نمونه پرامپت‌ها
توسعه‌دهنده در آخرین pull کد پرداخت را تغییر داده. با زبان ساده توضیح بده چه چیزی را تغییر داده و آیا چیز دیگری در اپلیکیشن به آن وابسته است.
بخش‌هایی از این اپلیکیشن را که پیچیده‌ترین یا پرریسک‌ترین هستند فهرست کن، تا بتوانم به یک توسعه‌دهنده بگویم بازبینی را روی کجا متمرکز کند.
پرداخت‌ها را به یک توسعه‌دهنده می‌سپارم. از این به بعد به هیچ فایلی زیر src/payments یا مسیرهای /api/billing دست نزن. اگر تغییری به آن‌ها نیاز دارد، به‌جایش به من بگو.
اشتباهات رایج
- نداشتن بریف. توسعه‌دهنده ساعت‌های پولی را صرف حدس زدن آنچه می‌خواستید می‌کند.
- حوزهٔ مبهم مثل «باگ‌ها را درست کن» یا «آن را آمادهٔ تولید کن».
- ویرایش همزمان هر دو طرف بدون pull کردن اول، و بعد از دست رفتن کار بر اثر تعارض.
- به اشتراک گذاشتن ورود خودتان یا چسباندن کلیدها در گفتگو.
- حساب‌هایی به نام توسعه‌دهنده، که جدا شدن را سخت می‌کند.
- فراموش کردن برداشتن دسترسی و عوض کردن کلیدها بعد از پایان کار.
چک‌لیست
- کد در یک مخزن خصوصی به نام من است، و هیچ رازی در آن نیست.
- یک README راه‌اندازی را توضیح می‌دهد؛ یک بریف یک‌صفحه‌ای اپلیکیشن و کار را توضیح می‌دهد.
- کار یک تعریف پایان قابل آزمایش دارد.
- دسترسی از طریق دعوت همکاری است، و رازها از طریق تنظیمات یا مدیر رمز عبور.
- توافق کرده‌ایم چه کسی چه چیزی را تغییر دهد، و قبل از پرامپت pull می‌زنم.
- کار با بریف و جریان‌های حیاتی بازبینی می‌شود.
- مالکیت کتبی است؛ وقتی کار تمام شد دسترسی برداشته و کلیدها عوض می‌شوند.
کار با یک توسعه‌دهنده در Mythex
- او را به یک فضای کاری دعوت کنید. مالکان می‌توانند همکاران نامحدود دعوت کنند بدون هزینهٔ هر صندلی؛ اعضا روی پروژه‌های فضای کاری کار می‌کنند. از یک فضای کاری جدا استفاده کنید تا فقط این پروژه را ببیند. اعتبار اپلیکیشن‌های منتشرشده به مالک فضای کاری صورتحساب می‌شود. ببینید دعوت‌ها.
- GitHub sync و export (Pro). یک مخزن را وصل کنید و push/pull بزنید، یا پروژه را با رازهای حذف‌شده خروجی بگیرید. ببینید GitHub, export, and import.
- یک لینک پیش‌نمایش به اشتراک بگذارید تا کار در حال انجام را به کسی که حساب Mythex ندارد نشان دهید؛ وقتی تمام شد حذفش کنید.
- حالت Ask به سؤالات دربارهٔ کد پاسخ می‌دهد بدون تغییر آن — برای فهمیدن تغییرات توسعه‌دهنده مفید است.
اگر توسعه‌دهنده قرار است اپلیکیشن را جای دیگری اجرا کند، ببینید نحوهٔ خروجی گرفتن و self-host اپلیکیشنی که با هوش مصنوعی ساخته شده.
پرسش‌ها
آیا یک توسعه‌دهنده می‌تواند روی کدی که هوش مصنوعی نوشته کار کند؟
معمولاً بله. ابزارهای ساخت اپلیکیشن با هوش مصنوعی بیشتر کد استاندارد در چارچوب‌های رایج مثل React و TypeScript تولید می‌کنند که توسعه‌دهندگان از قبل با آن‌ها آشنا هستند. انتظار داشته باشید که اول کمی وقت صرف خواندن آن کنند و در بعضی جاها پیشنهاد پاکسازی بدهند.
بعد از استخدام یک توسعه‌دهنده، باید همچنان از ابزار ساخت با هوش مصنوعی استفاده کنم؟
می‌توانید، اما اول روی قواعد توافق کنید. ساده‌ترین تقسیم، بر اساس حوزه است؛ مثلاً شما متن و تغییرات صفحات را انجام می‌دهید و توسعه‌دهنده مسئول پرداخت‌ها و داده‌هاست. همیشه قبل از پرامپت، آخرین کد را pull کنید تا هیچ‌کدام از طرفین کار دیگری را بازنویسی نکند.
چطور مطمئن شوم کدی که توسعه‌دهنده می‌نویسد مال من است؟
مخزن و حساب‌های میزبانی را به نام خودتان نگه دارید و توسعه‌دهنده را به‌عنوان همکار اضافه کنید. مالکیت کار را پیش از شروع کتبی کنید، و برای پرسش‌های قراردادی قوانین محلی یا یک مشاور را بررسی کنید.
پیش از شروع، چه چیزی به توسعه‌دهنده بدهم؟
دسترسی به کد، توضیح کوتاه دربارهٔ کاری که اپلیکیشن انجام می‌دهد و چه کسانی از آن استفاده می‌کنند، فهرست مشکلات شناخته‌شده، کاری که می‌خواهید انجام شود همراه با نحوهٔ سنجش پایان کار، و حساب‌های آزمایشی. رازها را از طریق تنظیمات میزبان یا یک مدیر رمز عبور به اشتراک بگذارید، نه در گفتگو.