# Bagaimana Mencegah Sesi Coding Panjang Kehilangan Konteks? > Cegah hilangnya konteks dengan memindahkan fakta tahan lama dari chat ke task ledger ringkas, decision log, catatan tes, dan checkpoint repository. Muat ulang artefak tersebut sebelum kompresi atau pergantian model. Sesi panjang biasanya gagal karena drift, bukan amnesia mendadak. Agent masih mengingat tujuan besar tetapi kehilangan satu batasan kecil, mempercayai hasil tes lama, mengulang penyelidikan, atau mengedit berdasarkan rencana yang tidak lagi cocok dengan repository. Solusinya adalah state eksternal yang tahan lama, lebih pendek, dan lebih dapat dipercaya daripada transkrip. Perlakukan percakapan sebagai working memory dan repository sebagai sumber kebenaran. Pada setiap checkpoint penting, catat apa yang berubah, apa yang sudah diverifikasi, apa yang masih tidak pasti, dan apa yang harus dilakukan berikutnya. ## Lacak empat jenis konteks Pisahkan fakta berdasarkan fungsi agar ringkasan tidak berubah menjadi narasi tanpa struktur. | Jenis konteks | Contoh | Lokasi tahan lama | |---|---|---| | Tujuan | Hasil pengguna dan kriteria penerimaan | Task ledger | | Batasan | Kompatibilitas, keamanan, gaya, cakupan | Task ledger | | State repository | File yang berubah dan branch aktif | Version control | | Bukti | Tes, log, screenshot, benchmark | Catatan verifikasi | Tambahkan asumsi sebagai kategori kelima hanya bila diberi label jelas. Setiap asumsi perlu memuat aksi termurah untuk mengonfirmasi atau menolaknya. ## Pelihara task ledger yang ringkas Ledger yang baik muat dalam satu layar. Perbarui setelah milestone, bukan setelah setiap pesan. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Pertahankan path, perintah, dan nama kegagalan secara tepat. Hindari catatan harian tentang bagaimana diskusi berkembang. ## Buat checkpoint di sekitar state terverifikasi Checkpoint sebaiknya mengikuti hasil yang dapat direproduksi sesi berikutnya. Batas yang baik meliputi kelompok tes lulus, perubahan kecil yang tersimpan, respons API terkonfirmasi, atau keputusan desain yang didukung fixture. Catat file kotor sebelum mengganti model atau mengompresi konteks. Jangan klaim fitur bekerja hanya karena kode sudah ditulis. Hubungkan klaim dengan tes, build, atau artefak yang dapat diamati. | Klaim | Bukti yang diperlukan | |---|---| | Parser mendukung dua panggilan | Fixture dengan dua call ID terkorelasi | | Retry aman | Tes idempotensi saat koneksi putus | | Refactor mempertahankan perilaku | Suite lama dan baru lulus | | UI benar | Inspeksi render pada ukuran target | ## Ambil sumber terbaru, jangan replay chat Ketika detail penting, buka kembali file, skema, atau dokumen resmi terbaru. Cuplikan transkrip lama dapat menggambarkan kode yang telah berubah. Berikan path dan istilah pencarian agar agent memeriksa state sekarang. Retrieval sebaiknya sempit: muat interface, implementasi, tes gagal, dan log relevan sebelum seluruh repository. Ini menyisakan ruang untuk penalaran. ## Kompres dengan mempertahankan keputusan dan bukti Kompresi yang baik menghapus pengulangan percakapan tetapi mempertahankan batasan, keputusan yang sulit dibalik, alternatif yang ditolak, dan verifikasi. Bedakan `verified`, `observed`, `assumed`, dan `pending`. Jangan merangkum eksperimen gagal seolah-olah itu desain final. Simpan alasan suatu opsi ditolak agar pendekatan yang sama tidak muncul kembali. ## Batasi output tool sebelum masuk konteks Log panjang dan file hasil generasi cepat menghabiskan perhatian. Minta range, hitungan, atau baris yang cocok. Simpan output lengkap sebagai artefak dan kembalikan ringkasan pendek dengan path. Untuk kegagalan tes, simpan stack trace pertama yang berguna, assertion yang gagal, dan detail lingkungan. Hindari mengirim ratusan frame berulang kembali ke model. ## Lanjutkan dengan ritual deterministik Setelah jeda, kompresi konteks, atau pergantian model: * Baca tujuan dan batasan. * Periksa status version control dan perubahan terbaru. * Buka file dalam bagian state saat ini. * Jalankan ulang pemeriksaan terakhir yang relevan. * Pastikan aksi berikutnya masih valid. Ritual ini menangkap ringkasan kedaluwarsa sebelum menyebabkan edit baru. ## Pilih model tanpa bergantung pada memori transkrip Gateway memudahkan pergantian model, tetapi state tetap menjadi tanggung jawab Anda. Atlas Cloud menawarkan beberapa protokol LLM dari satu base URL; periksa [matriks protokol](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) dan [katalog model](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) terbaru sebelum memindahkan agent aktif. Berikan model pengganti task ledger, file sumber relevan, dan hasil verifikasi baru. Jangan bergantung pada state handle khusus provider kecuali protokol dan perilakunya sudah dikonfirmasi. ## Kesimpulan Sesi coding panjang mempertahankan konteks ketika state tahan lama ringkas, berbasis bukti, dan mudah dimuat ulang. Gunakan ledger satu layar, checkpoint pada perubahan terverifikasi, ambil sumber terbaru alih-alih replay chat, batasi output tool, dan ikuti ritual resume yang deterministik. Context window besar membantu, tetapi disiplin state eksternal membuat pekerjaan benar-benar dapat dipulihkan. ## FAQ ### Apakah context window yang lebih besar cukup untuk sesi coding panjang? Tidak. Ruang lebih besar hanya menunda tekanan dan tidak menjamin batasan lama tetap menonjol atau observasi yang kedaluwarsa diperbaiki. ### Apa yang harus ada dalam coding-session ledger? Catat tujuan, batasan, rencana saat ini, file yang diubah, keputusan utama, hasil verifikasi, risiko yang belum selesai, dan aksi berikutnya secara tepat. ### Seberapa sering agent perlu membuat checkpoint? Buat checkpoint setelah perubahan state yang berarti, seperti tes lulus, tahap migrasi selesai, keputusan desain, atau temuan yang mengubah rencana. ### Haruskah seluruh transkrip ditempelkan ke model baru? Biasanya tidak. Berikan checkpoint yang dikurasi beserta file sumber dan log relevan, lalu biarkan model memeriksa state repository terbaru. ### Bagaimana mencegah ringkasan mempertahankan kesalahan lama? Pisahkan fakta terverifikasi dari asumsi, sertakan bukti seperti perintah atau lokasi file, dan tarik klaim ketika tes baru membantahnya. ### Apa cara paling aman untuk melanjutkan setelah interupsi? Muat task ledger, periksa status version control, jalankan ulang verifikasi terakhir yang relevan, lalu mulai dari aksi berikutnya yang tercatat.