Mengapa ujian ini penting

Pembantu kod dipacu AI sering membiarkan pasukan meletakkan fail "peraturan" dalam repositori dan mengharapkan model mematuhi arahan tersebut pada setiap permintaan. Dalam praktiknya, model mungkin tidak pernah melihat fail tersebut, atau ia melihatnya tetapi mengabaikan kandungannya. Eksperimen terbaru dengan Claude Code menunjukkan kedua-dua masalah ini. Alat tersebut melangkau fail AGENTS.md bersaiz 72 KB secara senyap; apabila fail yang sama dinamakan semula kepada CLAUDE.md, pembantu tersebut memuatkannya dan meningkatkan jumlah token bagi setiap permintaan. Bajet token tambahan itu meningkatkan kependaman (latency), kos, dan boleh menyebabkan permintaan melebihi had model.

Pembangun yang menganggap "fail wujud" bermaksud "model mematuhi peraturan" berisiko menghadapi ketidakcekapan tersembunyi dan output yang tidak dapat diramalkan. Ujian tiga langkah ini memerlukan bukti konkrit pada setiap peringkat: konfigurasi, pemuatan, dan kegunaan.

Tiga soalan yang perlu ditanya

  1. Dikonfigurasi – Adakah fail diletakkan di tempat pembantu mencarinya? Alat yang berbeza menggunakan laluan atau konvensyen nama fail yang ditetapkan secara keras (hard-coded); ketidakpadanan bermakna fail tersebut tidak akan masuk ke dalam saluran paip (pipeline) prom.
  2. Dimuatkan – Adakah pembantu menunjukkan sebarang bukti bahawa ia telah menerima fail tersebut? Hash boleh mengesahkan identiti fail pada cakera, tetapi hanya jejak penghantaran (contohnya, baris log atau jumlah token) yang membuktikan model benar-benar memerhatikannya.
  3. Berguna – Adakah kehadiran fail tersebut menambah baik hasil tugasan? Fail yang dimuatkan tetapi menambah token tanpa mengubah hasil adalah satu kerugian bersih.

Menjalankan ujian

Prosedur ini sengaja dibuat seminimal mungkin supaya ia boleh diulang pada mana-mana platform.

  1. Cipta peraturan yang nyata – Tulis arahan yang ringkas dan boleh diperhatikan. Contohnya: “Senaraikan tepat dua fail sebelum menyunting.” Kesan peraturan tersebut boleh disemak dalam respons pembantu.

  2. Semak versi alat dan model – Buka sesi baharu, catat rentetan versi dan pengenal pasti model. Versi yang berbeza mungkin mengubah nama fail yang mereka kenali.

  3. Laksanakan dua larian Larian A: Gunakan nama fail yang tidak dikenali oleh alat tersebut (contohnya, AGENTS.md). Larian B: Gunakan nama fail asli alat tersebut (contohnya, CLAUDE.md).

    Rekodkan:

    • Hash sumber fail (untuk membuktikan kandungan pada cakera tidak berubah).
    • Laluan tepat yang digunakan.
    • Sebarang bukti yang dicatatkan oleh pembantu tentang pemuatan fail (peningkatan jumlah token, mesej eksplisit “loaded X.md”, dll.).
    • Jumlah token bagi setiap permintaan.
    • Hasil tugasan (adakah pembantu menyenaraikan tepat dua fail?).

Jika Larian B menunjukkan peraturan dipatuhi dan jumlah token meningkat pada jumlah yang dijangkakan, fail tersebut telah dimuatkan dan berguna. Jika peraturan diabaikan walaupun terdapat peningkatan token, fail tersebut sedang dibaca tetapi pemprosesan prom model membuang arahan tersebut. Dalam kes itu, menambah lebih banyak teks ke dalam fail tidak akan membantu; sebaliknya, pindahkan peraturan tersebut ke gerbang polisi yang ditetapkan secara keras atau ke kerangka ujian (test harness).

Apa yang didedahkan oleh data

Kes Claude Code menunjukkan jurang yang ketara antara konfigurasi dan pemuatan. Fail 72 KB tersebut wujud, mempunyai hash yang betul, dan telah diselaraskan ke repositori, namun pembantu tersebut tidak pernah merujuknya. Menamakan semula fail kepada CLAUDE.md yang asli mencetuskan pemuatan, tetapi juga menambah beban token yang besar. Setiap token tambahan menggunakan kitaran pengkomputeran dan boleh menyebabkan permintaan melebihi had kadar (rate limits).

Ujian tiga langkah ini mendedahkan kos tersembunyi sedemikian sebelum ia menjadi penghalang produksi (production blockers). Dengan menangkap perbezaan (delta) token, pasukan boleh memutuskan sama ada manfaat peraturan tersebut melebihi kosnya.

Kesimpulan

Jangan sesekali menganggap fail peraturan sedang berfungsi hanya kerana ia berada dalam repositori. Gunakan ujian tiga langkah—konfigurasi, muat, buktikan kegunaan—untuk menukar andaian tersebut kepada bukti yang boleh diukur. Apabila bukti menunjukkan fail tersebut hanyalah pembaziran token (token sink), pindahkan logik tersebut keluar daripada prom dan ke dalam gerbang deterministik. Hasilnya ialah aliran kerja pengekodan AI yang lebih ramping, pantas, dan lebih mudah diramalkan.