Cara Bekerja dengan Pembangun pada Aplikasi yang Dibina AI

Untuk bekerja dengan baik bersama pembangun pada aplikasi yang anda bina dengan AI, berikan mereka kod dalam repositori Git, ringkasan satu halaman tentang apa yang aplikasi itu lakukan dan sebabnya, serta tugas yang diskopkan dengan jelas beserta definisi siap. Bersetuju siapa menukar bahagian mana supaya anda dan AI tidak menimpa kerja mereka, simpan repositori dan akaun hosting atas nama anda, dan kongsi rahsia melalui tetapan yang betul dan bukan melalui mesej.

Ramai orang membina versi pertama aplikasi dengan AI dan kemudian membawa masuk pembangun — untuk menambah pembayaran, membetulkan sesuatu yang AI terus tersilap, menyemak keselamatan, atau mengambil alih apabila aplikasi berkembang. Jika anda masih memutuskan sama ada mahu mengupah sesiapa, lihat upah pembangun atau bina dengan AI. Panduan ini mengandaikan anda sudah membuat keputusan, dan mahu kerjasama berjalan lancar.

Bila pembangun berbaloi

Sebab biasa untuk membawa seseorang masuk:

• Masalah yang AI tidak dapat selesaikan selepas beberapa percubaan yang jelas dan pemulihan.
• Bahagian berisiko: pembayaran, kebenaran, data sensitif, migrasi pangkalan data.
• Semakan keselamatan atau kod sebelum pelancaran atau sebelum menerima pelanggan yang lebih besar.
• Prestasi apabila trafik sebenar tiba.
• Pertumbuhan: aplikasi telah menjadi perniagaan dan memerlukan seseorang yang memiliki kod.

Kejelasan tentang yang mana satu daripada perkara ini membentuk segala-galanya di bawah.

Langkah 1: Letakkan kod di tempat yang boleh dikongsi

Pembangun bekerja daripada repositori Git. Sebelum anda hubungi sesiapa:

1. Sambungkan projek ke repositori GitHub (atau yang serupa) yang persendirian, atau eksportnya.
2. Pastikan tiada rahsia dalam kod atau sejarah. Lihat cara menjaga kunci API anda selamat.
3. Semak projek boleh dijalankan dari salinan baharu — minta AI menulis langkah persediaan.

Tulis README untuk pembangun yang menyertai projek ini: apa yang aplikasi ini lakukan, susunan teknologinya, cara memasang dan menjalankannya secara tempatan, pembolehubah persekitaran yang diperlukan (nama sahaja), struktur folder, dan apa-apa yang rapuh atau luar biasa.

Jika Git masih baharu kepada anda, cara guna Git dengan aplikasi yang dibina AI merangkumi asasnya.

Langkah 2: Tulis taklimat satu halaman

Pembangun tidak melalui sejarah sembang anda. Berikan konteks dalam satu halaman:

• Apa yang aplikasi lakukan, untuk siapa, dan berapa ramai orang yang menggunakannya.
• Apa yang paling penting — aliran yang tidak boleh sekali-kali rosak.
• Masalah yang diketahui dan apa yang sudah anda cuba.
• Tugasnya, dan bagaimana anda akan tahu ia selesai.
• Kekangan: bajet, tarikh akhir, perkara yang tidak boleh mereka ubah.

Definisi "siap" yang baik boleh diuji: "Pengguna yang log masuk boleh membayar untuk pelan bulanan dengan Stripe Checkout, pelan itu muncul pada halaman akaunnya, dan membatalkan dalam portal pelanggan menurunkan tarafnya pada akhir tempoh." Bukan "selesaikan pembayaran".

Langkah 3: Berikan akses dengan selamat

• Kod: tambah mereka sebagai kolaborator pada repositori. Jangan hantar fail ZIP bolak-balik apabila kerja sudah bermula.
• Pembina: jika pembina aplikasi AI anda menyokong ahli pasukan, jemput mereka ke ruang kerja yang hanya mengandungi projek ini.
• Rahsia: tambah mereka dalam tetapan hos anda, atau kongsi melalui pengurus kata laluan. Jangan sekali-kali tampal kunci dalam e-mel atau sembang.
• Akaun ujian: cipta dengan data ujian, dan bukannya kongsi log masuk anda sendiri.
• Data pengeluaran: hanya jika mereka benar-benar memerlukannya, dan hanya apa yang diperlukan.

Simpan repositori, domain dan akaun hosting atas nama anda. Tambahkan orang; jangan serahkan akaun.

Langkah 4: Bersetuju siapa menukar apa

Punca geseran yang terbesar ialah dua pihak — anda dengan AI, dan pembangun — menukar kod yang sama pada masa yang sama. Pilih satu peraturan:

Apa pun yang anda pilih: pull kod terkini sebelum setiap sesi memberi arahan, dan buat perubahan besar pada cawangan yang boleh disemak oleh pihak yang satu lagi.

Langkah 5: Berkomunikasi secara bertulis

• Laporkan masalah dengan langkah, hasil yang dijangka dan hasil sebenar. Lihat cara menulis laporan pepijat yang baik.
• Simpan keputusan di satu tempat: penjejak isu, dokumen yang dikongsi, atau komen pull request.
• Minta mereka menerangkan perubahan dalam bahasa mudah dalam setiap pull request.
• Bersetuju berapa kerap anda akan menyemak perkembangan.

Langkah 6: Semak kerja mereka

Anda tidak perlu membaca kod untuk menyemak kerja. Semak:

• Ia melakukan apa yang dinyatakan dalam taklimat, pada pratonton atau salinan staging.
• Tiada apa lain yang rosak — jalankan aliran kritikal anda.
• Mereka menerangkan apa yang mereka ubah dan sebabnya.
• Tiada rahsia muncul dalam kod.

Untuk pemeriksaan yang lebih rapi, cara menyemak kod yang dijana AI mempunyai senarai semak yang juga berfungsi untuk kod yang ditulis manusia. Anda juga boleh minta pembina AI anda menerangkan pull request pembangun kepada anda dalam istilah mudah.

Langkah 7: Pastikan pemilikan jelas

• Repositori, hosting, domain dan akaun pihak ketiga kekal milik anda.
• Nyatakan pemilikan kod yang mereka tulis secara bertulis sebelum kerja bermula. Semak peraturan tempatan atau dapatkan nasihat penasihat untuk soalan kontrak.
• Apabila kerja tamat, buang akses mereka dan tukar sebarang kunci yang mereka lihat.

Contoh arahan

Pembangun menukar kod checkout dalam pull terakhir. Terangkan dalam bahasa mudah apa yang mereka ubah dan sama ada ada bahagian lain dalam aplikasi yang bergantung padanya.

Senaraikan bahagian aplikasi ini yang paling kompleks atau berisiko, supaya saya boleh memberitahu pembangun di mana untuk memberi tumpuan semakan.

Saya menyerahkan pembayaran kepada pembangun. Mulai sekarang jangan sentuh mana-mana fail di bawah src/payments atau laluan /api/billing. Jika sesuatu perubahan memerlukannya, beritahu saya.

Kesilapan biasa

• Tiada taklimat. Pembangun menghabiskan jam berbayar untuk menerka apa yang anda mahukan.
• Skop yang kabur seperti "betulkan pepijat" atau "jadikan sedia pengeluaran".
• Kedua-dua pihak mengedit serentak tanpa pull dahulu, kemudian kehilangan kerja akibat konflik.
• Berkongsi log masuk anda sendiri atau menampal kunci dalam sembang.
• Akaun atas nama pembangun, menjadikan perpisahan sukar.
• Lupa membuang akses dan menukar kunci selepas kerja tamat.

Senarai semak

• Kod berada dalam repositori persendirian atas nama saya, tanpa rahsia.
• README menerangkan persediaan; taklimat satu halaman menerangkan aplikasi dan tugasnya.
• Tugas mempunyai definisi siap yang boleh diuji.
• Akses melalui jemputan kolaborator, rahsia melalui tetapan atau pengurus kata laluan.
• Kami bersetuju siapa menukar apa, dan saya pull sebelum memberi arahan.
• Kerja disemak berbanding taklimat dan aliran kritikal.
• Pemilikan dinyatakan secara bertulis; akses dibuang dan kunci ditukar apabila kerja tamat.

Bekerja dengan pembangun di Mythex

• Jemput mereka ke ruang kerja. Pemilik boleh menjemput kolaborator tanpa had dengan tiada yuran setiap kerusi; ahli bekerja pada projek ruang kerja. Gunakan ruang kerja berasingan supaya mereka hanya melihat projek ini. Kredit untuk aplikasi yang diterbitkan dicaj kepada pemilik ruang kerja. Lihat Jemputan.
• GitHub sync dan eksport (Pro). Sambungkan repositori dan push/pull, atau eksport projek dengan rahsia dikecualikan. Lihat GitHub, eksport dan import.
• Kongsi pautan pratonton untuk menunjukkan kerja yang sedang berjalan kepada seseorang tanpa akaun Mythex; padamkannya apabila anda selesai.
• Mod Ask menjawab soalan tentang kod tanpa mengubahnya — berguna untuk memahami perubahan pembangun.

Jika pembangun akan menjalankan aplikasi di tempat lain, lihat cara mengeksport dan self-host aplikasi yang dibina AI.

Soalan lazim