Cara Ulang Ubah Apl Dibina AI Tanpa Merosakkannya

Untuk mengubah suai apl yang dibina AI tanpa merosakkannya, tukar satu perkara setiap prompt, semak dalam pratonton, dan simpan titik semak sebelum meneruskan. Terangkan apa yang anda lihat dan bukan apa yang anda sangka kod itu lakukan, rancang perubahan besar sebelum membinanya, dan apabila perubahan tersasar, undur ke versi baik terakhir dan bukan minta AI membetulkan pembetulannya sendiri.

Versi pertama apl selalunya siap dalam beberapa minit. Bahagian yang sukar ialah perubahan kelima puluh, apabila setiap prompt baharu berisiko merosakkan sesuatu yang sudah berfungsi. Panduan ini ialah gelung yang mengelakkan perkara itu.

Gelung ulang ubah

1. Pilih satu perubahan. Satu ciri, satu pepijat, satu halaman.
2. Terangkannya dari segi apa yang pengguna lihat dan lakukan.
3. Untuk perubahan besar, rancang dahulu. Minta pelan, baca, kemudian bina.
4. Semak hasilnya dalam pratonton — perubahan itu dan aliran berhampiran.
5. Simpan titik semak atau commit.
6. Ulang.

Setiap langkah wujud untuk memastikan perubahan kecil dan boleh diundur.

Langkah 1: Simpan senarai pendek

Sebelum memberi prompt, tulis apa yang anda mahu ubah, mengikut kepentingan. Ini menghalang anda daripada menghantar perenggan sepuluh permintaan dalam satu mesej, dan memberi anda cara untuk berkata "belum sekarang" kepada idea yang muncul di tengah jalan.

Jika perubahan itu besar, pecahkannya. "Tambah akaun pasukan" menjadi: cipta pasukan, jemput ahli, tukar antara pasukan, hadkan data kepada pasukan semasa. Setiap satu ialah prompt sendiri. Menulis cerita pengguna ialah cara yang baik untuk melakukannya.

Langkah 2: Terangkan apa yang anda lihat

AI tidak dapat melihat skrin anda melainkan anda beritahunya. Tunjuk perkara tertentu, dan nyatakan apa yang sepatutnya berlaku:

Pada halaman harga di telefon, butang kad Pro dipotong di tepi kanan. Kekalkan susun atur desktop seperti sediakala; pada skrin di bawah 640px, susun kad secara menegak dan jadikan butang lebar penuh.

Bandingkan dengan "halaman harga nampak teruk pada mudah alih". Yang pertama boleh dibuat dan disemak sekali gus; yang kedua mengundang reka bentuk semula yang tidak anda minta.

Tangkapan skrin membantu. Jika pembina anda menerima imej, lampirkan satu dan bulatkan masalahnya.

Langkah 3: Rancang sebelum perubahan besar

Untuk apa-apa yang menyentuh beberapa bahagian apl — model data baharu, pembayaran, peranan pengguna — minta pelan sebelum sebarang kod berubah:

Jangan tukar kod lagi. Saya mahu pengguna tergolong dalam pasukan dan hanya melihat projek pasukan mereka. Rancang perubahan itu: jadual, halaman dan laluan API mana yang berubah, apa yang berlaku kepada data pengguna sedia ada, dan dalam susunan apa anda akan membinanya.

Baca pelan itu. Jika ia salah, membetulkan pelan jauh lebih murah berbanding membatalkan binaan.

Langkah 4: Nyatakan apa yang mesti kekal

Alat AI kadang-kadang "mengemas" perkara yang tidak anda minta. Lindungi apa yang berfungsi:

Tambah penapis tarikh pada jadual pesanan. Jangan ubah lajur, gaya atau butang eksport jadual itu.

Untuk peraturan yang terpakai di mana-mana — warna jenama, nada suara, "jangan sekali-kali padam data tanpa pengesahan" — letakkan dalam fail nota projek atau tetapan pengetahuan yang dibaca AI setiap kali, dan bukan mengulanginya.

Langkah 5: Semak lebih daripada perubahan itu

Selepas setiap prompt, uji:

• Perubahan itu sendiri. Adakah ia melakukan apa yang anda minta, pada desktop dan telefon?
• Jiran-jirannya. Perkara pada halaman yang sama, dan aliran yang menggunakan data yang sama.
• Laluan kritikal. Daftar, log masuk, tindakan utama, pembayaran. Semakan tiga puluh saat selepas setiap perubahan besar boleh menangkap kebanyakan kerosakan awal.

Jika ada yang tidak kena, laporkannya dengan tepat — lihat cara menulis laporan pepijat yang baik.

Langkah 6: Undur dan jangan menimbun

Apabila perubahan merosakkan sesuatu dan pembetulan pertama tidak berjaya, berhenti. Setiap "pembetulan" tambahan dibina atas keadaan yang rosak, dan masalah makin bertambah.

Sebaliknya:

1. Undur ke versi terakhir yang berfungsi (titik semak atau commit Git).
2. Fikirkan apa yang tidak jelas dalam prompt.
3. Cuba semula dengan permintaan yang lebih kecil atau lebih jelas.

Perubahan itu merosakkan penyimpanan draf. Saya dah undur. Kali ini: tambah penunjuk simpan automatik sebagai teks dalam pengepala sahaja. Jangan ubah cara draf disimpan.

Langkah 7: Tahu bila bina semula itu betul

Membina semula dari awal membuang banyak butiran yang sudah berfungsi. Ia berbaloi hanya apabila:

• Idea produk telah berubah sepenuhnya.
• Struktur asas tidak dapat menyokong apa yang anda perlukan sekarang — contohnya, ia dibina sebagai laman statik dan kini memerlukan akaun serta pangkalan data.
• Projek itu masih hampir kosong.

Apabila anda membina semula, senaraikan apa yang perlu dikekalkan: nama, warna, teks, bahagian yang disukai pengguna.

Contoh prompt

Sebelum kita teruskan, ringkaskan cara apl ini berfungsi sekarang: halaman, data yang disimpan, dan apa-apa yang anda rasa rapuh.

Saya mahu tambah tempahan berulang. Apakah versi terkecil yang berguna? Cadangkan sebagai tiga perubahan berasingan yang boleh kita buat satu demi satu.

Semak tiga perubahan terakhir untuk apa-apa yang mungkin merosakkan aliran pembayaran. Jangan edit lagi.

Kesilapan biasa

• Sepuluh permintaan dalam satu prompt. Sesetengahnya siap, sesetengahnya separuh siap, dan anda tidak tahu yang mana.
• Maklum balas yang kabur. "Ia rosak" atau "buat lebih baik" menghasilkan tekaan.
• Tidak pernah menyemak jiran. Perubahan pada komponen yang dikongsi boleh merosakkan tiga halaman lain.
• Membetulkan pembetulan. Empat prompt dalam ke dalam satu pepijat, undur.
• Mengulang konteks setiap kali dan bukannya menyimpan peraturan tetap dalam nota projek.
• Membina semula apabila buntu. Kebanyakan saat "mula semula" sebenarnya bermaksud "undur dua langkah".

Senarai semak

• Satu matlamat setiap prompt.
• Saya terangkan apa yang saya nampak dan apa yang sepatutnya berlaku.
• Perubahan besar mendapat pelan sebelum sebarang kod.
• Saya nyatakan apa yang mesti kekal.
• Selepas setiap perubahan saya uji perubahan itu, jirannya dan laluan kritikal.
• Saya simpan titik semak atau commit selepas setiap perubahan yang berfungsi.
• Apabila pembetulan gagal, saya undur dan bukan menimbun pembetulan.
• Peraturan tetap disimpan dalam nota projek yang AI baca setiap kali.

Mengulang ubah pada Mythex

Mythex dibina di sekitar gelung ini:

• Mod Plan, Ask dan Build. Plan membincangkan pendekatan sebelum menyunting; Ask menjawab tanpa menukar kod; Build membuat perubahan. Lihat Chat.
• Titik semak. Selepas setiap giliran yang berjaya, Mythex menyimpan titik semak git; Revert to this point membatalkan perubahan. Anda juga boleh mengedit mesej sebelumnya dan Discard & resend untuk mencuba prompt yang berbeza dari titik itu. Lihat Iterate without rebuilding.
• Pengetahuan. Tetapan projek → Knowledge menyimpan nota tetap yang diikuti ejen pada setiap mesej.
• /test meminta ejen mengklik pratonton seperti pengguna selepas perubahan besar.

Permintaan yang lebih kecil juga kurang menelan kredit. Untuk menulis prompt itu sendiri, lihat cara menulis prompt untuk pembina apl AI; apabila sesuatu rosak, lihat cara nyahpepijat apl dibina AI.

Soalan lazim