Skip to content

Tutorial 4 Prompting and Reviewing id

James Morris edited this page Jul 29, 2026 · 1 revision

Tutorial 4 · Memberi Prompt dan Meninjau

🌎 Bahasa: Bahasa Indonesia (id)lihat semua 33 bahasa

Tujuan: menguasai keterampilan meta. Kamu sudah dapat membangun fitur bersama agen; sekarang lakukan dengan lancar dan berulang: menulis prompt yang tepat, meninjau diff secara efisien, beriterasi saat melenceng, dan menjaga momentum antarsesi.

← Sebelumnya: Tutorial 3 Tugas Agen Pertamamu · Berikutnya: Tutorial 5 Lokalisasi


Beri prompt seperti lead, bukan kotak pencarian

Anggap agen sebagai junior engineer yang cepat, literal, bersemangat, dan perlu arah jelas:

  • Nyatakan tujuan dan batasan. “Tambah endorse” lemah. “Tambah endorse mengikuti pola connect, hanya seeded RNG, dengan tes, gerbang tetap hijau” kuat. Batasan membuat kode cocok dengan proyek.
  • Tunjuk contoh. “Ikuti pola renderConnect” lebih efektif daripada paragraf panjang. Kode yang ada adalah spesifikasi terbaik.
  • Minta rencana sebelum edit untuk pekerjaan nontrivial. Mengarahkan ulang rencana murah; membongkar sepuluh file mahal.
  • Satu tugas per prompt. Menggabungkan fitur, refactor RNG, dan update README menghasilkan diff kusut yang sulit ditinjau.
  • Berikan gerbang tes. “Jalankan npm test dan jangan anggap selesai sampai hijau” membuat agen memeriksa pekerjaannya sendiri.

Selalu review diff

Kecepatan adalah manfaat agen, tetapi kecepatan yang tidak dibaca mengirim bug. Bangun refleks review yang konsisten:

  1. Cakupan: apakah hanya hal yang perlu yang berubah? Baris tak terkait yang berpindah adalah bau.
  2. Pola: apakah sesuai kode sekitar, tanpa dependency baru dan tanpa I/O di src/?
  3. Aturan proyek: di sini berarti hanya seeded RNG—cari Math.random pada diff—teks yang terlihat pengguna berada di bundle bahasa, bukan hardcoded, dan baris kartu tidak melebihi lebar layout.
  4. Aksesibilitas: jalankan lockedin --accessible <your command> dan pastikan teks polosnya bersih tanpa glyph dekoratif yang lolos a11yFilter. Flag dasarnya tetap --accessible.
  5. Tes: apakah ada tes baru dan apakah benar-benar gagal jika fitur rusak? Tanyakan, “Baris apa yang harus diubah agar tes baru ini gagal?”
  6. Jalankan: npm test, lalu jalankan command dan lihat outputnya.

Kamu tidak harus memahami setiap karakter, tetapi harus memahami setiap keputusan. Jika tidak dapat menjelaskan perubahan, minta agen menjelaskannya sebelum menerima.

Beriterasi ketika belum hijau

Gerbang merah adalah langkah normal, bukan kegagalan. Berikan feedback presisi:

npm test gagal dengan: [paste the exact error]. Tes lebar renderEndorse mengharapkan setiap baris kartu ≤ 60 visible column. Perbaiki tanpa melemahkan tes.”

Tempel teks error sebenarnya. “Rusak” membuat agen menebak; stack trace memberinya fakta. Lanjutkan percakapan yang sama agar konteks perubahan tetap tersedia. Jika dua atau tiga iterasi tidak konvergen, mundur dan perkecil cakupan; mungkin tugasnya terlalu besar untuk satu prompt.

Menjaga momentum antarsesi

Pekerjaan nyata berlangsung lebih dari sekali duduk. Dua kebiasaan membantu:

  • Memori / konvensi. Jika agen mendukung memori tahan lama atau file instruksi proyek, catat aturan seperti “semua randomness memakai pick/shuffle” dan “jalankan npm test sebelum selesai”. Kamu cukup menyebut konvensi sekali.
  • Catatan handoff. Repository ini menyimpan status singkat yang sudah disanitasi di docs/HANDOFF.md: apa proyeknya, cara membangun, cara menguji, dan langkah berikutnya. Saat kembali atau menyerahkan ke rekan/agen lain, catatan itu memulihkan konteks dengan cepat. Minta agen memperbaruinya sebagai bagian perubahan.

Guardrail yang layak dipertahankan

  • Gerbang tidak dapat ditawar. Tes hijau sebelum apa pun dikirim.
  • Kamu reviewer yang bertanggung jawab. Agen menulis; kamu memutuskan. Menerima diff berarti menjamin isinya.
  • Langkah kecil yang dapat diverifikasi lebih baik daripada satu lompatan besar. Setiap perubahan yang diterima harus meninggalkan aplikasi tetap bekerja.

✅ Coba bersama agenmu

  1. Tulis spesifikasi satu paragraf untuk command mentor yang “membagikan nasihat tanpa diminta”, lengkap dengan batasan. Minta agen membuatnya test-first: rencana, tes, kode, gerbang, dan review.
  2. Minta agen memperbarui docs/HANDOFF.md untuk menyebut command baru.
  3. Sengaja rusak satu hal, misalnya hapus entri pool, jalankan npm test, lalu latih memberi agen kegagalan persis untuk diperbaiki.

Langkah selanjutnya

  • Baca sekilas src/lockedin.js; sekarang kamu memahami bentuknya.
  • Baca docs/HANDOFF.md untuk status dan catatan arsitektur proyek.
  • Nikmati lelucon di Referensi Command.

Tutorial selesai. Sekarang kamu dapat mengarahkan agen AI membangun dan mengubah software nyata di balik gerbang tes, dengan contoh paling percaya diri yang mungkin. Setuju? 👇

📘 LockedIn CLI wiki

Tutorial

Reference


Satire · Sátira · 風刺. Not affiliated with LinkedIn. GPL-3.0-or-later.

Clone this wiki locally