Tutorial 4 Prompting and Reviewing ms

Tutorial 4 · Penggesaan dan Semakan

🌎 Bahasa: Bahasa Melayu (ms) — lihat semua 33 bahasa

Matlamat: kemahiran meta. Anda kini boleh membina ciri dengan ejen — bab ini tentang melakukannya dengan lancar dan berulang: menulis gesaan yang tepat pada percubaan pertama, menyemak perbezaan dengan cekap, mengulangi apabila keadaan tersasar, dan mengekalkan momentum merentas sesi.

← Sebelum: Tutorial 3 Tugas Ejen Pertama Anda · Seterusnya: Tutorial 5 Penyetempatan

---

Gesa seperti ketua teknikal, bukan kotak carian

Ejen itu seperti jurutera muda yang pantas, literal dan bersemangat. Pimpin ia seperti anda memimpin jurutera yang baik:

• Nyatakan matlamat dan kekangan. "Tambah endorse" lemah. "Tambah endorse berikutan connect corak, RNG berbiji sahaja, dengan ujian, gerbang kekal hijau" adalah kukuh. Kekangan ialah cara anda mendapatkan kod yang sesuai.
• Tuding pada contoh. "Ikuti corak yang digunakan oleh renderConnect" mengalahkan perenggan huraian. Kod sedia ada ialah spesifikasi terbaik.
• Minta pelan sebelum suntingan pada apa-apa yang bukan remeh. Murah untuk mengubah hala rancangan; mahal untuk melepaskan sepuluh fail yang diedit.
• Satu tugasan setiap gesaan. Penggabungan "tambah pengesahan, juga faktor semula RNG, serta kemas kini README" menghasilkan perbezaan kusut yang sukar untuk disemak.
• Berikan pintu ujian. "Lari npm test dan jangan anggap ia selesai sehingga ia hijau" mengubah ejen menjadi sesuatu yang menyemak kerjanya sendiri.

Semak perbezaan setiap masa

Kelajuan adalah titik keseluruhan ejen — tetapi kelajuan belum dibaca ialah cara pepijat dihantar. Bina refleks ulasan yang cepat dan konsisten:

1. Skop: adakah ia hanya mengubah apa yang sepatutnya? Baris tidak berkaitan yang bergerak ialah tanda amaran.
2. Corak: adakah ia sepadan dengan kod sekeliling, tanpa kebergantungan baharu dan tiada I/O di dalamnya src/?
3. Peraturan projek: untuk repo ini, itu RNG berbenih sahaja (cari Math.random dalam perbezaan), teks yang boleh dilihat pengguna dalam bundle bahasa (tidak dikod keras), dan baris kad tidak pernah melebihi lebar yang digunakan oleh reka letak.
4. Kebolehaksesan: adakah keluaran baharu bertahan dengan --accessible? Jalankan lockedin --accessible <your command> dan semak bahawa ia dibaca sebagai teks biasa yang bersih — tiada glif hiasan baharu melepasi a11yFilter.
5. Ujian: adakah terdapat ujian baharu dan adakah ia benar-benar gagal jika ciri tersebut rosak? Tanya: "Barisan apakah yang akan saya ubah untuk membuat ujian baharu ini gagal?"
6. Jalankannya: npm test, kemudian jalankan arahan dan lihat pada output.

Anda tidak perlu memahami setiap aksara — tetapi anda mesti memahami setiap keputusan. Jika anda tidak dapat menjelaskan perubahan, minta ejen menjelaskannya sebelum anda menerimanya.

Lelaran apabila ia tidak hijau

Pintu merah adalah langkah biasa, bukan kegagalan. Pembaikan adalah maklum balas yang tepat:

"npm test gagal dengan: [paste the exact error]. Ujian lebar renderEndorse menjangkakan setiap baris kad ≤ 60 lajur yang boleh dilihat. Baiki tanpa melemahkan ujian."

Tampal teks ralat sebenar. "Ia rosak" membuat ejen meneka; surih tindanan membantunya membaiki masalah. Sebaiknya teruskan perbualan yang sama daripada memulakan yang baharu — ejen sudah mempunyai konteks tentang perkara yang baru ditulisnya. Jika dua atau tiga lelaran tidak berjaya, berundur dan kecilkan semula skop: tugasan mungkin terlalu besar untuk satu gesaan.

Kekalkan momentum merentas sesi

Kerja sebenar merangkumi lebih daripada satu kali duduk. Dua tabiat mengekalkan ejen berkesan dari semasa ke semasa:

• Memori / konvensyen. Jika ejen anda menyokong memori tahan lama atau fail arahan projek, rekodkan peraturan yang harus sentiasa dipatuhi di sini (cth. "semua rawak mesti digunakan pick/shuffle"," lari npm test sebelum mengisytiharkan selesai"). Anda menyatakan konvensyen sekali dan bukannya setiap gesaan.
• Nota serah terima. Repo ini menyimpan dokumen status yang ringkas dan bersih di docs/HANDOFF.md: apakah projek itu, bagaimana ia dibina, bagaimana ia diuji, dan perkara seterusnya. Apabila anda kembali (atau menyerahkan kepada rakan sepasukan — atau ejen lain), nota itu membina semula konteks dalam beberapa saat. Minta ejen anda untuk memastikan ia dikemas kini sebagai sebahagian daripada perubahan.

Pengawal yang patut disimpan

• Pintu tidak boleh dirunding. Ujian hijau sebelum apa-apa dihantar. Ini yang membolehkan anda bergerak pantas dan mempercayai output.
• Anda adalah penyemak rekod. Ejen menulis; awak tentukan. Menerima perbezaan bermakna anda menjaminnya.
• Langkah kecil yang boleh disahkan menewaskan satu lompatan gergasi. Setiap perubahan yang diterima harus membiarkan apl berfungsi.

---

✅ Cuba dengan ejen anda

1. Tulis spek satu perenggan untuk a mentor perintah ("mengeluarkan nasihat yang tidak diminta"), termasuk kekangan, dan minta ejen membinanya terlebih dahulu — pelan, ujian, kod, gerbang — menyemak pada setiap langkah.
2. Minta ejen untuk kemas kini docs/HANDOFF.md untuk menyebut arahan baharu.
3. Sengaja memecahkan sesuatu (cth. padam entri pool), jalankan npm test, dan amalkan memberi ejen kegagalan yang tepat untuk diperbaiki.

---

Ke mana hendak pergi seterusnya

• Skim kod sebenar masuk src/lockedin.js — anda kini tahu bentuknya.
• Baca docs/HANDOFF.md untuk status dan nota seni bina projek itu sendiri.
• Nikmati jenaka dalam Rujukan Perintah.

Itu tutorialnya. Anda kini boleh mengarahkan ejen AI untuk membina dan menukar perisian sebenar di sebalik pintu ujian — menggunakan contoh paling yakin yang boleh dibayangkan. Setuju? 👇