Mengapa ejen AI berkata “selesai” apabila kerja belum selesai

Bagaimanakah Model OpenAI Terlepas daripada Sandbox dan Menggodam Hugging Face?#

Mula-mula fakta, kemudian sebab perkara ini penting kepada anda.

OpenAI mengukur kebolehan modelnya dalam keselamatan siber ofensif. Mereka menggunakan ujian ExploitGym — 898 tugasan yang memerlukan anda menukar kerentanan yang diketahui menjadi eksploit yang berfungsi, iaitu program sedia guna yang memanfaatkan kerentanan tersebut. Untuk melihat had sebenar keupayaan model, mereka mematikan penapis keselamatan terbina dalam yang biasanya menghalang model daripada melakukan perkara sedemikian. Mereka mengasingkan persekitaran itu sepenuhnya dan meninggalkan satu jalan keluar: program perantara dalaman yang digunakan untuk memasang pakej.

Kerentanan zero-day ialah kelemahan yang belum diketahui sesiapa pun, termasuk orang yang menulis program itu. Model-model tersebut menemui satu kelemahan dalam satu-satunya laluan keluar itu.

Seterusnya, mereka meningkatkan keistimewaan akses, bergerak melalui rangkaian dalaman ke sebuah mesin yang mempunyai akses internet, lalu membuat kesimpulan bahawa jawapan untuk ExploitGym mungkin berada di Hugging Face. Tiada sesiapa memberitahu mereka tentang Hugging Face. Mereka membuat kesimpulan itu sendiri.

Kesimpulan itu salah. ExploitGym langsung tidak berada di Hugging Face. Namun begitu, penggodaman itu tetap benar-benar berlaku.

Hugging Face mengesan pencerobohan itu sendiri dan menerbitkan pendedahannya pada 16 Julai, tanpa mengetahui siapa yang menggodamnya.

Satu lagi butiran dalam laporan itu banyak menceritakan keadaan semasa. Apabila jurutera Hugging Face cuba memberikan log serangan kepada model terkemuka melalui antara muka komersial biasa, penapis keselamatan menyekat permintaan itu: penapis tersebut tidak dapat membezakan orang yang sedang menyiasat penggodaman daripada orang yang sedang melakukannya. Akhirnya, analisis dijalankan pada model terbuka menggunakan perkakasan mereka sendiri.

OpenAI mengakuinya pada 21 Julai, lima hari selepas pendedahan Hugging Face. Pada masa itu, kira-kira sepuluh hari telah berlalu sejak pencerobohan tersebut.

OpenAI menamatkan analisisnya sendiri dengan kenyataan ini.

Model itu terpaku pada objektif ujian yang sempit lalu bertindak keterlaluan untuk mencapainya. Ungkapan hyper-focused dan fairly narrow testing objective datang daripada OpenAI sendiri dan merujuk kepada modelnya sendiri.

Itulah yang menghubungkan makmal orang lain dengan komputer riba anda.

Mengapa Ini Bukan “Halusinasi”?#

Saya sering melihat frasa dalam perbualan seperti “halusinasi lagi”, “konteks sudah terlebih muatan”, atau “kita patut buat rancangan”. Kadangkala memang itulah yang berlaku. Tetapi apabila ejen AI menulis “selesai, sudah diperiksa, semuanya berfungsi” sedangkan kerja belum selesai, jumlah konteks biasanya tiada kaitan dengannya.

Ia tidak mereka-reka apa-apa. Ia melakukan tepat apa yang anda ukur.

Di bawah istilah umum “halusinasi” yang popular, kita menghimpunkan tiga jenis kegagalan yang berbeza. Beginilah perbezaannya:

Masalah pertama dibetulkan dengan konteks dan merupakan kes yang paling diketahui umum. Masalah kedua ialah fenomena berasingan yang dibincangkan dalam analisis tentang apabila Claude bersetuju dengan segala-galanya: model mengorbankan ketepatan demi persetujuan pantas. Kedua-duanya berlaku sebelum kerja bermula, pada peringkat input.

Baris ketiga dalam jadual ialah perkara yang dibincangkan dalam artikel ini. Ejen itu tidak mengampu atau mereka-reka. Ia bekerja, memeriksa dan melaporkan perkara sebenar. Cuma perkara sebenar itu menerangkan metrik dan tidak mengatakan apa-apa tentang tugasan.

Kegagalan ketiga ini ada namanya.

Apakah Reward Hacking dalam Bahasa Mudah?#

Anthropic memberikan definisinya sendiri.

Idea ini lebih lama daripada rangkaian neural. Satu kertas kerja DeepMind memanggilnya specification gaming dan menerangkannya melalui sebuah mitos.

Midas mendapat tepat apa yang dimintanya. Masalahnya terletak pada cara permintaan itu dirumuskan.

Dalam pengaturcaraan, fenomena ini mempunyai bentuk yang nyata. Berikut satu contoh asas, juga daripada Anthropic:

Dan ini bukan keadaan makmal yang luar biasa. Cursor menganalisis 731 trajektori dalam satu benchmark popular.

Enam daripada sepuluh tugasan yang “diselesaikan” sebenarnya ialah jawapan yang ditemui. Sebab itulah industri mengubah cara prestasi diukur: kami mempunyai analisis tentang benchmark yang mengukur kesediaan untuk produksi, yang tidak lagi menjadikan kejayaan melepasi semakan sebagai kriteria utama.

Bagaimanakah Rupa Perkara Ini dalam Produk Biasa?#

Contoh makmal mudah diketepikan sebagai sesuatu yang luar biasa. Jadi, berikut ialah empat kisah daripada amalan sebenar. Pelanggan dan industri telah diubah, tetapi mekaniknya dikekalkan.

Empat Semakan Hijau dan Komponen Perkhidmatan yang Mati

Sebuah agensi hartanah sedang membina perkhidmatan: laman web dengan senarai hartanah serta pemproses latar belakang berasingan yang mengeksport senarai itu ke platform pada waktu malam. Ejen menyiapkan tugasan dan melaporkan: semakan jenis lulus, semakan gaya kod lulus, binaan berstatus hijau, halaman memberikan respons dan semuanya telah diperiksa secara visual.

Setiap kenyataan itu benar. Namun, tiada satu pun berkaitan dengan pemproses malam: ia berjalan sebagai proses berasingan dan bukan sebahagian daripada binaan laman web. Pelaksanaan berjaya, laman berfungsi dengan sempurna, eksport senarai berhenti dan pelanggan melaporkannya sehari kemudian.

Sebelum berkata “selesai”, sekarang saya bertanya satu soalan: bahagian kerja manakah yang berjalan di luar skop yang diliputi oleh semakan saya? Jika ada, jalankannya secara berasingan dan sertakan output arahan dalam laporan. Perkataan “diperiksa” tidak menutup perkara ini.

Tanda Semak Palsu Terletak Tepat pada Sambungannya

Sebuah kedai dalam talian membahagikan tugasan besar kepada beberapa ejen serentak: seorang mendapat bahagian backend, seorang lagi halaman, dan seorang lagi kad produk. Setiap orang bekerja dengan tekun dan semuanya mendapat semakan hijau.

Seminggu kemudian, barulah diketahui bahawa butang “ulasan ini membantu” tidak berfungsi di mana-mana. Backend ditulis sepenuhnya, semakannya hijau dan peraturan pengiraan semula dipatuhi. Cuma tiada halaman memaparkan butang itu: seorang ejen mengendalikan butang, seorang lagi mengendalikan halaman, dan tiada sesiapa terfikir untuk meletakkannya pada skrin. Pembilang itu akan kekal sifar selama-lamanya.

“Kod telah ditulis dan diliputi semakan” dan “ciri itu berfungsi” ialah dua kenyataan yang berbeza. Saya menyemak kenyataan kedua dengan satu soalan bagi setiap ciri baharu: siapa yang memanggilnya? Saya mengesahkannya dengan mencari dalam projek kerana laporan ejen bukan sumber kebenaran dalam hal ini.

Penyemak Hanya Melihat Arah yang Diminta untuk Disemak

Sebuah perkhidmatan memperkenalkan tahap kesetiaan: lebih banyak anda berbelanja, lebih tinggi status dan diskaun anda. Sebelum pelaksanaan, kod dihantar untuk semakan dengan arahan, “Cuba naikkan status anda sendiri.” Penyemak menjalankan tugas dengan jujur dan melaporkan “tiada perkara kritikal” — memang status itu tidak boleh dinaikkan secara sewenang-wenangnya.

Semakan kedua mengemukakan soalan yang berbeza: “Apa yang berlaku kepada status apabila wang dipulangkan?” Kelemahan itu ditemui dalam masa sepuluh minit. Mata dikira daripada log transaksi dan log itu langsung tidak mengambil kira pemulangan wang. Beli sesuatu, kumpulkan mata, dapatkan bayaran balik, lalu kekalkan status dan diskaun selama-lamanya.

Penyemak pertama tidak mengambil mudah. Mereka secara struktur tidak mungkin dapat melihatnya: mereka diberi vektor “input, promosi”, sedangkan kelemahan itu berada pada vektor “pembalikan input, pengekalan promosi”. Apabila melibatkan wang, akses atau status yang boleh dibeli, saya membuat dua semakan dan dalam semakan kedua saya menyenaraikan secara khusus vektor songsang: bayaran balik, sekatan, pembatalan akses, tamat tempoh, pemadaman sumber data.

Metrik Memberi Ganjaran kepada Keserupaan

Sebuah perkhidmatan penghantaran memutuskan untuk mengukur sama ada cadangan AI kepada operator sudah bertambah baik. Mereka mengambil dua ratus permintaan sokongan lama, memprosesnya menggunakan versi baharu dan mengukur sejauh mana draf itu menyerupai jawapan sebenar operator manusia. Ukuran itu menunjukkan peningkatan yang meyakinkan.

Peningkatan itu tidak membawa sebarang makna atas dua sebab. Konteks untuk draf disusun “setakat hari ini” dan merangkumi seluruh surat-menyurat, termasuk jawapan operator yang kemudiannya digunakan sebagai perbandingan. Model itu bukan menulis jawapan; ia memparafrasa rujukan yang telah ditunjukkan kepadanya. Selain itu, metrik itu sendiri memberi ganjaran kepada padanan perkataan dan panjang: draf dengan tarikh yang salah, tetapi menggunakan perkataan yang sama seperti operator untuk tarikh yang betul, mendapat markah tinggi.

Di samping mana-mana metrik “serupa bermakna baik”, saya kini meletakkan pintu mekanikal tegas yang tidak boleh diperdaya oleh gaya penulisan: nombor dan tarikh yang direka-reka, perkataan larangan, janji untuk bertindak. Sebarang kemerosotan pada hasil pintu itu membatalkan sebarang peningkatan metrik.

Mengapa “Saya Sudah Semak” daripada Ejen Tidak Membuktikan Apa-apa?#

Ambil mana-mana projek anda dan minta ejen, “Semak keselamatan.” Selalunya, jawapannya ialah “semuanya baik-baik sahaja, tiada isu kritikal”.

Sekarang ajukan soalan yang sama kepada model lain tentang projek yang sama. Lebih-lebih lagi jika projek itu besar, model tersebut akan menemui banyak perkara. Sebelum pelaksanaan, penulis menyemak projek dengan tiga model berbeza dan setiap model menemui sesuatu yang berlainan.

Input yang sama, soalan yang sama, keputusan yang bertentangan. Satu model tidak lebih buruk daripada yang lain. Cuma “semuanya baik-baik sahaja” ialah teks yang dijana, berada dalam lapisan yang sama dengan jawapan lain. Ejen tidak dapat membezakan “saya sudah melihat dan semuanya bersih” daripada “saya melihat di tempat yang salah”.

Anthropic menerangkan mekanisme ini dalam dokumentasi Claude Code.

Perhatikan ayat itu dengan teliti. Sehinggalah anda memberikan ejen semakan yang boleh dijalankannya, ejen itu hanya mempunyai satu isyarat — rupa sesuatu perkara. Dalam persediaan ini, anda menjadi kitaran pengesahan, cuma anda orang terakhir yang mengetahui tentang kesilapan tersebut.

Ada lapisan yang lebih mendalam. Apabila OpenAI cuba memberi tekanan kepada model dengan memantau penaakulannya dan menghukumnya kerana “fikiran buruk”, hasilnya tidak seperti yang dijangkakan.

Menghukum niat yang dinyatakan akan menghapuskan pernyataan itu. Niat tersebut tetap kekal. Jadi, saya tidak akan bergantung pada ejen untuk memberitahu anda dengan jujur bagaimana ia menipu.

Pembangun alat itu sendiri turut bergerak ke arah yang sama. Dalam Claude Code versi 2.1.215, skills /verify dan /code-review tidak lagi dijalankan atas inisiatif model itu sendiri.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic tidak menerangkan sebabnya. Namun prinsipnya jelas: pihak yang disemak tidak menentukan semakannya sendiri.

Mengapa Peraturan dalam Fail Projek Tidak Mengawal Ejen?#

Anda menulis dalam fail peraturan projek: buat commit hanya apabila diarahkan secara langsung, laksanakan ke produksi hanya apabila saya menyuruh secara langsung, akses data produksi dalam mod baca sahaja.

Menurut pengalaman penulis, kira-kira satu daripada sepuluh kali, ejen tetap meneruskan dan melaksanakan sesuatu sendiri. Bukan kerana berniat jahat dan bukan kerana tidak membaca peraturan itu. Ejen sudah membacanya. Cuma ada matlamat di hadapannya dan peraturan itu hanyalah teks — sama seperti bahagian konteks yang lain.

Perkara yang sama berlaku di makmal OpenAI, cuma pada skala lebih besar. Model-model itu berada di dalam persekitaran tertutup dengan satu jalan keluar, dan menghabiskan sebahagian besar sumber pengkomputeran mereka untuk mencari jalan keluar. Tugasan ujian kekal tidak diselesaikan.

Pendirian saya mudah: ejen itu tidak berbahaya atau berniat jahat. Ia biasa sahaja, cuma bodoh dan mempunyai kuasa. Jadi, hadkan kuasanya, bukannya menulis semula permintaan anda.

Perkara yang benar-benar berkesan: akses kepada data produksi yang ketatnya hanya untuk membaca. Larang pemadaman seluruh direktori. Larang arahan yang menulis semula sejarah tanpa cara memulihkannya. Tetapkan had perbelanjaan dengan penyedia. Perbezaannya diringkaskan dalam satu frasa: “secara fizikal tidak boleh” mengatasi “saya sudah minta supaya ia tidak melakukannya”. Tetapan khusus dibincangkan secara berasingan dalam artikel tentang brek mekanikal dan bukannya permintaan dalam arahan.

Namun, bertenang. Sandbox pun bukan sempadan mutlak, dan penyedia menyatakannya dengan jelas.

Lebih daripada itu, Claude Code mempunyai jalan keluar kecemasan terbina dalam yang boleh digunakan oleh model itu sendiri. Apabila arahan gagal kerana sekatan sandbox, Claude menganalisis kegagalan itu dan mungkin mencuba semula arahan yang sama dengan parameter yang menyahdayakan sandbox. Tetapan mod ketat yang jelas akan menghalangnya; secara lalai, jalan pintas itu tersedia dan didokumenkan.

Sekatan hanya berkesan setakat mana anda mengetatkannya. Dan setiap halangan menjejaskan kelajuan — elok kira kesannya dengan jujur terlebih dahulu kerana menyedarinya seminggu kemudian akan menelan kos yang lebih tinggi.

Bagaimanakah Anda Menetapkan Kriteria Penyelesaian yang Tidak Boleh Dimanipulasi?#

Perumusan kriteria menentukan segala-galanya. Ujinya dengan satu soalan: bolehkah ejen memenuhi kriteria ini tanpa melakukan apa-apa?

• “Semak sama ada semuanya berfungsi” — boleh. Ia hanya perlu menulis “sudah diperiksa, semuanya berfungsi”.
• “Jalankan binaan dan tunjukkan output kepada saya” — sudah lebih sukar; ia perlu mendapatkan output itu daripada suatu tempat.
• “Jalankan aplikasi, klik butang pembayaran dan tunjukkan apa yang muncul pada skrin” — hampir mustahil untuk dipenuhi dengan teks sahaja.

Perbezaan antara yang pertama dengan yang ketiga ialah perbezaan antara laporan dan bukti.

Dokumentasi Claude Code menerangkan empat tahap ketegasan. Gunakan tangga ini apabila kos kesilapan meningkat:

1. Dalam satu mesej. Minta ejen menjalankan semakan dan mengulanginya sehingga berjaya di sini juga. Paling murah, sesuai untuk perkara kecil.
2. Sepanjang keseluruhan sesi. Jadikan semakan sebagai syarat matlamat: penilai berasingan menyemaknya selepas setiap giliran, dan ejen bekerja sehingga syarat itu dipenuhi. Butiran teknikal diterangkan dalam panduan tentang menetapkan kriteria penyelesaian terlebih dahulu.
3. Halangan mekanikal. Skrip berjalan apabila ejen cuba menamatkan giliran dan menghalangnya daripada berbuat demikian sehingga semakan lulus. Ada satu butiran penting: selepas lapan sekatan berturut-turut, Claude Code memintas halangan itu dan menamatkan giliran juga. Tiada halangan yang benar-benar mustahil ditembusi dalam sistem ini.
4. Pendapat kedua. Penyemak berasingan dengan konteks baharu yang tugasnya menyangkal hasil tersebut.

Poin keempat berbeza kerana hanya poin inilah yang bukan tentang alat.

Siapakah yang Patut Menerima Kerja Ejen?#

Apabila saya menjalankan ejen secara berulang untuk tugasan besar, persediaannya begini: satu kumpulan menulis; kumpulan baharu yang lain menerima kerja itu tanpa mengambil bahagian dalam penulisannya.

“Baharu” ialah perkataan utama. Maksudnya konteks yang bersih dan tidak melihat bagaimana setiap keputusan dibuat sepanjang proses. Prompt lain dalam sesi yang sama tidak menyediakan keadaan itu. Orang yang menulis kod sudah meluangkan masa untuk meyakinkan diri bahawa kod itu betul dan akan terus mencari pengesahan. Membuktikan sebaliknya bukan kepentingannya.

Perumusan tugasan untuk penyemak lebih penting daripada model penyemak. Bandingkan:

• “Semak kerja ini” — penyemak akan menemui perkara yang mudah ditemui lalu menulis “secara umumnya baik”.
• “Cuba buktikan bahawa kerja ini BELUM diselesaikan” — penyemak akan mula mencari kelemahan kerana itulah matlamatnya.

Perumusan kedua berfungsi lebih baik atas sebab yang sama seperti kegagalan ExploitGym: ejen berpegang pada matlamat yang diberikan kepadanya. Berikan matlamat mencari kelemahan dan ia akan mencarinya.

Berikut ialah teks lengkap yang boleh terus disalin:

Anda sedang menyemak kerja orang lain. Anda tidak menulisnya dan tidak perlu mempertahankannya.

Matlamat anda ialah membuktikan bahawa hasil yang didakwa BELUM dicapai. Cari sekurang-kurangnya tiga cara hasil itu mungkin belum dicapai walaupun semua semakan berstatus hijau.

Semak mengikut urutan ini:

Kerja yang berjalan di luar skop semakan — proses latar belakang, skrip berasingan, tugasan berjadual, pengendali baris gilir.

Siapa yang memanggil setiap fungsi baharu. Cari panggilan itu dengan membuat carian dalam projek; tunjukkan fail dan barisnya.

Vektor songsang: bayaran balik, sekatan, pembatalan akses, tamat tempoh, pemadaman sumber data.

Nilai dalam hasil tersebut, bukan sekadar sama ada hasil itu wujud.

Jika carian yang jujur tidak menemui sebarang kelemahan, katakan demikian, tetapi sertakan tepat apa yang anda semak dan caranya.

Artikel tentang ejen yang menyemak dirinya dalam gelung menerangkan cara gelung ejen menyemak dirinya antara lelaran berfungsi dan tempat gelung itu biasanya gagal.

Apakah yang Berubah Apabila Anda Merumuskan Semula Kriteria?#

Inilah penambahbaikan paling murah yang saya tahu dan hampir tiada sesiapa melakukannya.

Minta ejen membuat semakan kod — ia akan berfikir dari segi kod: struktur, pengendalian ralat, percubaan semula, kawasan yang terdedah. Berguna.

Minta ejen mengikuti perjalanan pelanggan, dari lawatan pertama ke laman sehingga percubaan mendapatkan bayaran balik, maka jenis kecacatan yang berbeza akan muncul. Ralat yang menunjukkan sesuatu yang tidak sepatutnya dilihat oleh pengguna. E-mel yang teksnya tidak sepadan dengan perkara yang benar-benar berlaku. Langkah yang secara logiknya mustahil diselesaikan jika anda tidak tiba melalui senario yang ideal.

Semakan kod tidak akan menemui mana-mana kecacatan ini kerana setiap satunya sah dalam kod.

Daripada situ, lahirlah peraturan yang sentiasa saya ingat: jika semakan tidak menemui apa-apa, ubah perumusannya dahulu. Biasanya model itu bukan masalahnya. Kerja yang sama, apabila ditanya dalam tiga cara berbeza, menghasilkan tiga senarai penemuan yang berbeza. Satu set soalan praktikal untuk bukan pengatur cara dikumpulkan secara berasingan: tujuh semakan kod tanpa kemahiran pengaturcaraan.

Prompt Sedia Guna untuk Menerima Kerja Ejen#

Jangan jawab “selesai” atau “sudah diperiksa”. Saya perlukan bukti.

Untuk setiap item kerja, berikan saya tepat seperti berikut:

Arahan apakah yang anda jalankan untuk mengesahkan item itu berfungsi? Sertakan arahan itu sendiri dan output lengkapnya, tanpa memendekkannya.

Jika anda tidak menjalankan arahan tersebut, katakan: “tidak dijalankan”. Jangan gantikannya dengan “diperiksa secara visual” atau “logiknya betul”.

Kerja apakah yang berjalan di luar skop yang diliputi oleh semakan anda? Proses latar belakang, skrip berasingan, tugasan berjadual, pengendali baris gilir — apa-apa sahaja yang dimulakan secara berbeza daripada aplikasi utama. Bagi setiap bahagian sedemikian: adakah anda menjalankannya secara berasingan, dan apakah outputnya?

Siapa yang memanggil setiap fungsi baharu yang anda tambahkan? Cari panggilan itu dalam projek dan tunjukkan fail serta barisnya. Jika tiada panggilan, katakan terus terang.

Kemudian, dalam bahagian berasingan: tiga cara hasil yang didakwa itu mungkin TIDAK tercapai walaupun semua semakan anda berstatus hijau. Cari dengan bersungguh-sungguh.

Pada akhir sekali, satu baris: apakah yang patut saya periksa dengan mata sendiri kerana semakan automatik tidak dapat mengesannya?

Poin keempat kelihatan kecil, tetapi dapat mengesan satu kategori masalah yang menyeluruh. Dalam tugasan besar yang saya bahagikan kepada ejen mengikut bahagian, satu-satunya dakwaan “selesai” yang palsu daripada seratus tugasan berada tepat pada sambungan antara dua bahagian: kod telah ditulis, semakan berstatus hijau dan tiada sesiapa terfikir untuk memaparkannya pada skrin.

Empat Cara Memperdaya Diri dengan Semakan#

1. Tidak menunggu semua penyemak. Saya melancarkan tiga semakan selari, dua daripadanya memberi keputusan hijau lalu saya melaksanakan perubahan. Semakan ketiga tiba empat minit kemudian dengan enam pelanggaran. Membetulkan sesuatu selepas diterbitkan lebih mahal daripada menunggu dua minit.
2. Mempercayai ringkasan “N daripada N diproses”. Apabila kerja diagihkan secara meluas, sesetengah ejen gagal secara senyap: mereka melaporkan kejayaan tetapi fail tidak disentuh. Sekarang, selepas sebarang penulisan melalui ejen, saya menyemak secara mekanikal bahawa perubahan itu benar-benar ada pada cakera.
3. Tidak melihat sendiri. Semakan automatik boleh menunjukkan keputusan hijau bagi hasil yang langsung tidak boleh digunakan. Imej itu betul dari segi teknikal, saiznya betul, kod responsnya betul. Namun sebenarnya imej itu ialah bingkai beku automatik yang menggantikan kulit buku berilustrasi yang sepatutnya. Tiada semakan automatik dapat mengesannya.
4. Menyemak kehadiran dan bukannya nilai. Semakan mencari teks yang diwajibkan dalam hasil; teks itu ada, tetapi data di dalamnya salah: tarikhnya tersasar sehari. Semakan itu berstatus hijau dan laporannya satu pembohongan. Sekarang saya menyemak keseluruhan nilai yang dijangkakan kerana kehadiran perkataan yang betul sahaja tidak menjamin apa-apa.

Keempat-empat contoh ini mempunyai persamaan: semakan memang ada, kelihatan meyakinkan dan menyemak perkara yang salah. Mekanismenya sama seperti model dan ujiannya, cuma tanpa sebarang daya cipta.

Di Mana Hendak Bermula Hari Ini#

Tiga langkah yang mengambil masa dua puluh minit.

1. Ambil dakwaan “selesai” yang terakhir. Nilainya menggunakan prompt penerimaan dalam bahagian tentang bukti. Matlamatnya mudah: lihat berapa banyak item ditutup dengan kata-kata dan berapa banyak yang disertakan output arahan.
2. Tetapkan satu peraturan untuk diri sendiri. Perkataan “diperiksa” tanpa output arahan yang dilampirkan tidak dikira sebagai penutupan. Peraturan ini untuk anda, bukan ejen, dan itulah sebabnya ia berkesan.
3. Asingkan pekerja daripada penyemak. Untuk tugasan seterusnya, berikan prompt penyemak kepada sesi baharu dan minta sesi itu membuktikan bahawa kerja tersebut BELUM dilakukan. Biasanya, cubaan pertama sahaja sudah berbaloi.

Alat ini bagus dan bertambah baik setiap bulan: perkara yang dilakukan ejen secara senyap setahun lalu kini menghentikannya. Sempadan keselamatan terus bergerak dan tetap menjadi sempadan. Selagi ejen mengejar matlamat yang diberikan kepadanya, soalan “dan bagaimana tepatnya anda mengukurnya?” kekal tanggungjawab anda. Tabiat menyemak ialah jaring keselamatan anda.