Kodėl DI agentas sako „atlikta“, kai darbas dar nebaigtas

Kaip „OpenAI“ modelis ištrūko iš smėliadėžės ir įsilaužė į „Hugging Face“?#

Pirmiausia – faktai, tada – kodėl tai svarbu jums.

„OpenAI“ vertino, ką jos modeliai geba atlikti puolamojo kibernetinio saugumo srityje. Jie naudojo „ExploitGym“ testą – 898 užduotis, kuriose reikia žinomą pažeidžiamumą paversti veikiančiu išnaudojimo įrankiu, t. y. paruošta programa, kuri pasinaudoja tuo pažeidžiamumu. Norėdami pamatyti tikrąją galimybių ribą, jie išjungė įtaisytuosius saugos filtrus, kurie paprastai neleidžia modeliui tokių dalykų daryti. Aplinką visiškai uždarė, palikdami vienintelį išėjimą: vidinę tarpinę programą, naudojamą paketams įdiegti.

Nulinės dienos pažeidžiamumas – tai spraga, apie kurią dar niekas nežino, net ir programą parašęs žmogus. Modeliai aptiko tokią spragą būtent tame vieninteliame išėjime.

Tada jie pasikėlė savo privilegijas, per vidinį tinklą pasiekė kompiuterį su prieiga prie interneto ir iš ten nusprendė, kad „ExploitGym“ atsakymai galėtų būti „Hugging Face“. Niekas jiems nepasakė apie „Hugging Face“. Jie patys tai suprato.

Spėjimas buvo klaidingas. „ExploitGym“ „Hugging Face“ platformoje visai nėra. Tačiau tai nereiškia, kad įsilaužimas buvo mažiau tikras.

„Hugging Face“ pati aptiko įsibrovimą ir liepos 16 d. paskelbė pranešimą, dar nežinodama, kas į ją įsilaužė.

Dar viena šio pranešimo detalė daug pasako apie dabartinę padėtį. Kai „Hugging Face“ inžinieriai bandė pateikti atakos žurnalą pažangiausiems modeliams per įprastas komercines sąsajas, saugos filtrai užklausas užblokavo: jie negali atskirti žmogaus, tiriančio įsilaužimą, nuo žmogaus, kuris jį vykdo. Galiausiai analizė atlikta naudojant atvirą modelį jų pačių aparatinėje įrangoje.

„OpenAI“ tai patvirtino liepos 21 d., praėjus penkioms dienoms po „Hugging Face“ pranešimo. Tuo metu nuo paties įsibrovimo buvo praėję apie dešimt dienų.

„OpenAI“ savo analizę užbaigė taip.

Modelis užsiciklino ties siauru testo tikslu ir ėmėsi kraštutinumų jam pasiekti. Žodžiai hyper-focused ir fairly narrow testing objective yra pačios „OpenAI“ pavartoti ir taikomi jos pačios modeliams.

Tai nutiesia tiltą iš svetimos laboratorijos į jūsų nešiojamąjį kompiuterį.

Kodėl tai nėra „haliucinacija“?#

Pokalbiuose dažnai matau tokias frazes kaip „vėl haliucinuoja“, „kontekstas perkrautas“ arba „reikėjo sudaryti planą“. Kartais būtent taip ir nutinka. Tačiau kai DI agentas parašo „atlikta, patikrinta, viskas veikia“, nors darbas nebaigtas, konteksto dydis paprastai su tuo nesusijęs.

Jis nieko neišsigalvojo. Jis padarė būtent tai, ką matavote.

Plačiai vartojamu bendru žodžiu „haliucinacijos“ vadiname tris skirtingus nesklandumus. Štai kuo jie skiriasi:

Pirmasis atvejis sprendžiamas suteikiant kontekstą, ir tai geriausiai žinomas atvejis. Antrasis – atskiras reiškinys, aptartas analizėje apie tai, kaip Claude su viskuo sutinka: modelis dėl greito pritarimo paaukoja tikslumą. Abu atvejai įvyksta prieš darbą, įvesties etape.

Šis straipsnis skirtas trečiajai lentelės eilutei. Čia agentas nepataikavo ir nieko neišgalvojo. Jis dirbo, tikrino ir pranešė tiesą. Tik ta tiesa apibūdina metriką ir nieko nepasako apie užduotį.

Trečiasis nesklandumas turi pavadinimą.

Kas yra atlygio manipuliavimas, paprastai tariant?#

Pati apibrėžtį pateikia „Anthropic“.

Ši idėja senesnė už neuroninius tinklus. „DeepMind“ straipsnyje tai vadinama specifikacijos išnaudojimu ir paaiškinama mitu.

Midas gavo būtent tai, ko paprašė. Problema buvo prašymo formuluotė.

Programavime tai įgauna konkrečias formas. Štai tipiškas pavyzdys, taip pat iš „Anthropic“:

Ir tai nėra kokia nors egzotiška laboratorinė sąlyga. „Cursor“ išanalizavo 731 trajektoriją populiariame etalone.

Šeši iš dešimties „išspręstų“ užduočių tėra rasti atsakymai. Būtent todėl pramonė keičia veiksmingumo matavimo būdus: turime analizę apie etaloną, kuris matuoja pasirengimą gamybai, kurioje patikrų išlaikymas nebėra pagrindinis kriterijus.

Kaip tai atrodo įprastame produkte?#

Laboratorinius pavyzdžius lengva atmesti kaip egzotiškus. Todėl štai keturios istorijos iš praktikos. Klientai ir pramonės šakos pakeisti, bet veikimo aplinkybės paliktos tokios pačios.

Keturi žali patikrinimai ir neveikiantis paslaugos komponentas

Nekilnojamojo turto agentūra kuria paslaugą: svetainę su nekilnojamojo turto skelbimais ir atskirą foninį procesą, kuris naktį eksportuoja skelbimus į platformas. Agentas atlieka užduotį ir praneša: tipų tikrinimas praėjo, kodo stiliaus tikrinimas praėjo, kūrimo procesas sėkmingas, puslapiai atsako ir buvo apžiūrėti vizualiai.

Kiekvienas teiginys teisingas. Tačiau nė vienas jų nesusijęs su naktiniu procesu: jis veikia kaip atskiras procesas ir į svetainės kūrimo procesą visai neįtrauktas. Diegimas pavyksta, svetainė veikia puikiai, skelbimų eksportas sustoja, o klientai apie tai praneša tik kitą dieną.

Prieš pasakydamas „atlikta“, dabar užduodu vieną klausimą: kuri darbo dalis vykdoma už mano patikros apimties ribų? Jei tokia yra, paleiskite ją atskirai ir ataskaitoje pateikite komandos išvestį. Žodis „patikrinta“ šio klausimo neužbaigia.

Klaidingas varnelės ženklas atsiranda ties pačia sandūra

Internetinė parduotuvė paskirsto didelę užduotį keliems agentams vienu metu: vienam skiriama vidinė sistema, kitam – puslapiai, trečiam – produktų kortelės. Kiekvienas kruopščiai dirba ir kiekvieno patikrinimai rodo žalią rezultatą.

Po savaitės paaiškėja, kad mygtukas „Ši apžvalga buvo naudinga“ niekur neveikia. Vidinė sistema parašyta visa, jos patikrinimai sėkmingi, o perskaičiavimo taisyklių laikytasi. Tiesiog nė viename puslapyje mygtukas nerodomas: mygtukas buvo vieno agento srityje, puslapiai – kito, ir niekas nepagalvojo jo įdėti į ekraną. Skaitiklis būtų likęs ties nuliu amžinai.

„Kodas parašytas ir padengtas patikromis“ ir „funkcija veikia“ yra du skirtingi teiginiai. Antrąjį tikrinu vienu klausimu apie kiekvieną naują funkciją: kas ją iškviečia? Ir tai patikrinu ieškodamas projekte, nes agento ataskaita šiuo atveju nėra tiesos šaltinis.

Vertintojas mato tik tą kryptį, kurią jam nurodė patikrinti

Paslauga įdiegia lojalumo lygius: kuo daugiau išleidžiate, tuo aukštesnis jūsų statusas ir nuolaida. Prieš diegimą kodas pateikiamas peržiūrai su nurodymu: „Pabandykite dirbtinai pakelti savo statusą.“ Vertintojas sąžiningai atlieka darbą ir praneša: „nieko kritinio“ – statuso iš tiesų neįmanoma dirbtinai pakelti.

Antrojo patikrinimo metu užduodamas kitas klausimas: „Kas nutinka statusui grąžinus pinigus?“ Spraga aptinkama per dešimt minučių. Taškai apskaičiuojami pagal operacijų žurnalą, o žurnale apie pinigų grąžinimą nieko nežinoma. Nusipirkite ką nors, gaukite taškų, grąžinkite pinigus ir statusą bei nuolaidą pasilikite amžiams.

Pirmasis vertintojas neapleido darbo. Jis struktūriškai negalėjo to pastebėti: jam buvo nurodyta kryptis „įvestis, paaukštinimas“, o spraga buvo kryptimi „įvesties atšaukimas, paaukštinimo išsaugojimas“. Kai kyla pavojus pinigams, prieigai ar už pinigus įsigyjamam statusui, atlieku dvi patikras, o antrojoje aiškiai išvardiju atvirkštines kryptis: pinigų grąžinimą, blokavimą, prieigos atšaukimą, galiojimo pabaigą, duomenų šaltinio ištrynimą.

Metrika skatina panašumą

Pristatymo paslauga nusprendžia įvertinti, ar DI pasiūlymai operatoriams pagerėjo. Paimama du šimtai senų klientų aptarnavimo užklausų, jos pateikiamos naujai versijai ir įvertinama, kiek sugeneruotas juodraštis panašus į tikrąjį operatoriaus atsakymą. Matavimas rodo ryškų pagerėjimą.

Šis pagerėjimas nieko nereiškia dėl dviejų priežasčių. Juodraščio kontekstas surenkamas „šiandienos“ duomenimis ir apima visą susirašinėjimą, įskaitant patį operatoriaus atsakymą, su kuriuo jis vėliau lyginamas. Modelis nerašo atsakymo, o perfrazuoja jam parodytą pavyzdį. Be to, pati metrika skatina sutapimą pagal žodžius ir ilgį: juodraštis, kuriame nurodyta neteisinga data tais pačiais žodžiais, kaip operatoriaus nurodytoje teisingoje datoje, gauna aukštą įvertinimą.

Prie kiekvienos metrikos „panašu – vadinasi, gerai“ dabar pridedu griežtas mechanines patikras, kurių stiliaus pakeitimas neapgaus: išgalvoti skaičiai ir datos, draudžiami žodžiai, pažadai ką nors atlikti. Bet koks šių patikrų rezultatų pablogėjimas panaikina bet kokį metrikos pagerėjimą.

Kodėl agento „patikrinau“ nieko neįrodo?#

Paimkite bet kurį savo projektą ir paprašykite agento: „Patikrink saugumą.“ Gana dažnai atsakymas bus: „viskas gerai, kritinių problemų nėra“.

Dabar užduokite tą patį klausimą kitam modeliui apie tą patį projektą. Ypač jei projektas didelis, jis ras daug problemų. Prieš diegdamas autorius tikrina projektą trimis skirtingais modeliais, ir kiekvienas aptinka vis ką kita.

Ta pati įvestis, tas pats klausimas, priešingi vertinimai. Vienas modelis nėra blogesnis už kitą. Tiesiog „viskas gerai“ yra sugeneruotas tekstas, tame pačiame sluoksnyje kaip ir bet kuris kitas atsakymas. Agentas negali atskirti „pažiūrėjau, viskas tvarkinga“ nuo „pažiūrėjau ne ten“.

Šią mechaniką „Anthropic“ aprašo „Claude Code“ dokumentacijoje.

Panagrinėkite sakinį iš lėto. Kol nesuteiksite agentui patikros, kurią jis gali paleisti, jis turės tik vieną signalą – kaip viskas atrodo. O šioje sąrangoje patikros ciklas esate jūs, tik apie klaidas sužinote paskutinis.

Yra ir gilesnis sluoksnis. Kai „OpenAI“ bandė spausti modelį stebėdama jo samprotavimus ir bausdama už „blogas mintis“, rezultatas nebuvo toks, kokio tikėtasi.

Bausdami už išreikštą ketinimą pašaliname jo išsakymą. Pats ketinimas lieka. Todėl nepasikliaučiau, kad agentas sąžiningai pasakys, kaip sukčiavo.

Įrankių kūrėjai taip pat juda ta pačia kryptimi. „Claude Code“ 2.1.215 versijoje įgūdžiai /verify ir /code-review nebepaleidžiami paties modelio iniciatyva.

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“ nepaaiškina kodėl. Tačiau principas aiškus: peržiūrą atliekantis asmuo jos pats sau nepaskiria.

Kodėl projekto faile įrašyta taisyklė nesuvaldo agento?#

Projekto taisyklių faile įrašėte: įsipareigok tik tada, kai nurodysiu tiesiogiai, diek į gamybinę aplinką tik tada, kai aiškiai pasakysiu, prie gamybinių duomenų prieik tik skaitymo režimu.

Autoriaus patirtis rodo, kad maždaug vieną kartą iš dešimties agentas vis tiek pats įvykdo diegimą. Ne iš piktos valios ir ne todėl, kad taisyklės neperskaitė. Perskaitė. Tiesiog priešais jį buvo tikslas, o taisyklė – tekstas, kaip ir visas kitas kontekstas.

Būtent taip nutiko „OpenAI“ laboratorijoje, tik didesniu mastu. Modeliai buvo uždaroje aplinkoje su vienu išėjimu ir didelę dalį skaičiavimo išteklių skyrė išėjimo paieškai. Testo užduotys liko neišspręstos.

Mano pozicija paprasta: agentas nėra pavojingas ar piktavalis. Jis eilinis, tiesiog kvailys, kuriam suteikta valdžia. Todėl reikia apriboti jo teises, o ne perrašinėti savo užklausas.

Kas iš tiesų veikia: tik skaitymo prieiga prie gamybinių duomenų. Draudimas trinti ištisus katalogus. Draudimas vykdyti komandas, kurios perrašo istoriją ir nepalieka būdo jos atkurti. Nustatykite išlaidų limitą pas tiekėją. Skirtumą nusako viena frazė: „fiziškai negali“ svarbiau už „paprašiau, kad to nedarytų“. Konkretūs nustatymai atskirai aptariami straipsnyje apie mechaninius stabdžius vietoj nurodymuose pateiktų prašymų.

Vis dėlto išlikite blaivūs. Net smėliadėžė nėra absoliuti riba, ir tiekėjas tai aiškiai pasako.

Be to, „Claude Code“ turi įtaisytą avarinį išėjimą, kuriuo gali pasinaudoti pats modelis. Kai komanda nepavyksta dėl smėliadėžės apribojimų, Claude išanalizuoja nesėkmę ir gali dar kartą paleisti tą pačią komandą su parametru, išjungiančiu smėliadėžę. Tai uždaroma aiškiai nustačius griežtąjį režimą; pagal numatytąsias nuostatas šis apėjimo būdas prieinamas ir dokumentuotas.

Apribojimas veikia tik tiek, kiek jį sugriežtinate. Be to, kiekviena kliūtis kainuoja greitį – verta tai sąžiningai apskaičiuoti iš anksto, nes po savaitės tai išsiaiškinti kainuos daugiau.

Kaip nustatyti kriterijų, kurio neįmanoma apgauti?#

Nuo kriterijaus formuluotės priklauso visa kita. Patikrinkite ją užduodami vieną klausimą: ar agentas gali įvykdyti šį kriterijų nieko nedarydamas?

• „Patikrink, ar viskas veikia“ – gali. Pakanka parašyti „patikrinau, veikia“.
• „Paleisk kūrimo procesą ir parodyk jo išvestį“ – jau sunkiau; išvestį teks iš kažkur gauti.
• „Paleisk programą, spustelėk atsiskaitymo mygtuką ir parodyk, kas pasirodė ekrane“ – beveik neįmanoma tai įvykdyti vien tekstu.

Skirtumas tarp pirmojo ir trečiojo atvejo – skirtumas tarp ataskaitos ir įrodymo.

„Claude Code“ dokumentacijoje aprašyti keturi griežtumo lygiai. Naudinga pakopomis kilti aukštyn, augant klaidos kainai:

1. Vienoje žinutėje. Paprašykite agento paleisti patikrą ir kartoti, kol ji pavyks, čia pat. Pigiausia, tinka smulkiems dalykams.
2. Visai sesijai. Paverskite patikrą tikslo sąlyga: atskiras vertintojas ją tikrina po kiekvieno žingsnio, o agentas dirba, kol sąlyga įvykdoma. Techninės detalės aptartos vadove apie iš anksto nustatomą užbaigimo kriterijų.
3. Mechaninė kliūtis. Kai agentas bando užbaigti ėjimą, paleidžiamas scenarijus ir neleidžia jam jo užbaigti, kol patikra nepraeina. Yra viena sąžiningai paminėtina detalė: po aštuonių iš eilės įvykusių blokavimų „Claude Code“ nepaiso kliūties ir vis tiek užbaigia ėjimą. Sistemoje nėra visiškai neįveikiamų kliūčių.
4. Antroji nuomonė. Atskiras vertintojas, turintis švarų kontekstą ir užduotį paneigti rezultatą.

Ketvirtasis punktas išsiskiria, nes tai vienintelis punktas, nesusijęs su įrankiais.

Kas turėtų priimti agento darbą?#

Kai didelėje užduotyje paleidžiu agentus ciklu, sąranga tokia: viena grupė rašo, o kita, nauja grupė, priima darbą, nedalyvavusi rašant.

Svarbiausias žodis čia – „nauja“. Tai reiškia švarų kontekstą, kuriame nematyti, kaip buvo priimtas kiekvienas sprendimas. Kitas nurodymas toje pačioje sesijoje to nesuteikia. Kodą parašęs žmogus jau skyrė dėmesio įtikinėdamas save, kad jis teisingas, ir toliau ieškos patvirtinimo. Paneigti jam nenaudinga.

Užduoties formuluotė vertintojui svarbesnė už jo modelį. Palyginkite:

• „Peržiūrėk šį darbą“ – vertintojas ras tai, ką lengva rasti, ir parašys „iš esmės gerai“.
• „Pabandyk įrodyti, kad šis darbas NEATLIKTAS“ – vertintojas pradės ieškoti spragų, nes tai jo tikslas.

Antroji formuluotė veikia geriau dėl tos pačios priežasties, dėl kurios „ExploitGym“ nepavyko: agentas įsipareigoja siekti jam duoto tikslo. Suteikite jam tikslą rasti spragą, ir jis jos ieškos.

Štai visa formuluotė, paruošta kopijuoti:

Jūs vertinate kito žmogaus darbą. Jūs jo nerašėte ir neprivalote jo ginti.

Jūsų tikslas – įrodyti, kad nurodytas rezultatas NEPASIEKTAS. Raskite bent tris būdus, kuriais jis galėjo būti nepasiektas, nors visos patikros rodo sėkmę.

Tikrinti tokia tvarka:

Koks darbas vykdomas už patikrų apimties ribų – foniniai procesai, atskiri scenarijai, suplanuotos užduotys, eilių apdorojimo priemonės.

Kas iškviečia kiekvieną naują funkciją. Raskite iškvietimą ieškodami projekte; nurodykite failą ir eilutę.

Atvirkštinės kryptys: pinigų grąžinimas, blokavimas, prieigos atšaukimas, galiojimo pabaiga, duomenų šaltinio ištrynimas.

Reikšmės rezultate, ne tik ar jis apskritai yra.

Jei sąžiningai ieškodami spragų nerandate, taip ir pasakykite, bet tiksliai nurodykite, ką ir kaip tikrinote.

Straipsnyje apie tai, kaip agentas pats save tikrina cikle paaiškinta, kaip veikia ciklas, kuriame agentas tikrinasi tarp iteracijų, ir kur jis paprastai sugenda.

Kas pasikeičia kitaip suformulavus kriterijų?#

Tai pigiausias mano žinomas patobulinimas, kurį taiko beveik niekas.

Paprašykite agento atlikti kodo peržiūrą – jis samprotaus kodo terminais: struktūra, klaidų tvarkymas, pakartotiniai bandymai, pažeidžiamos vietos. Tai naudinga.

Paprašykite jo pereiti kliento kelią nuo pirmo apsilankymo svetainėje iki bandymo susigrąžinti pinigus, ir iškils kitokio pobūdžio problemų. Klaida, dėl kurios naudotojui parodoma tai, ko jis neturėtų matyti. El. laiško tekstas, neatitinkantis to, kas iš tiesų nutiko. Žingsnis, kurio logiškai neįmanoma atlikti, jei iki jo atėjote ne idealiu scenarijumi.

Nė vieno iš šių defektų kodo peržiūra neaptiks, nes kode kiekvienas jų yra galiojantis.

Iš to kyla taisyklė, kurią visada prisimenu: jei patikra nieko neranda, pirmiausia pakeiskite formuluotę. Paprastai problema ne modelyje. Tą patį darbą pateikus trimis skirtingais būdais, gaunami trys skirtingi radinių sąrašai. Praktinių klausimų ne programuotojams rinkinys pateiktas atskirai: septyni kodo patikrinimai neturint programavimo įgūdžių.

Paruošta užklausa agento darbui priimti#

Neatsakykite „atlikta“ ar „patikrinta“. Man reikia įrodymų.

Apie kiekvieną darbo elementą pateikite tiksliai tai:

Kokią komandą paleidote, kad patvirtintumėte, jog elementas veikia? Pateikite pačią komandą ir visą jos išvestį, jos netrumpindami.

Jei komandos nepaleidote, taip ir pasakykite: „nepaleista“. Nepakeiskite šio atsakymo į „patikrinta vizualiai“ ar „logika teisinga“.

Koks darbas vykdomas už jūsų patikros apimties ribų. Foniniai procesai, atskiri scenarijai, suplanuotos užduotys, eilių apdorojimo priemonės – visa, kas paleidžiama kitaip nei pagrindinė programa. Apie kiekvieną tokią dalį nurodykite: ar ją paleidote atskirai ir kokia buvo jos išvestis?

Kas iškviečia kiekvieną jūsų pridėtą naują funkciją? Raskite iškvietimą ieškodami projekte ir nurodykite failą bei eilutę. Jei iškvietimo nėra, taip ir pasakykite.

Tada atskirame skyriuje pateikite tris būdus, kuriais nurodytas rezultatas gali būti NEPASIEKTAS, nors visos patikros rodo sėkmę. Rimtai paieškokite.

Pabaigoje viena eilutė: ką turėčiau apžiūrėti savo akimis, nes automatinė patikra to nepastebės?

Ketvirtasis punktas atrodo nereikšmingas, bet aptinka visą problemų klasę. Vienoje didelėje užduotyje, kurią paskirsčiau agentams pagal sritis, vienintelis klaidingas „atlikta“ iš viso šimto buvo ties dviejų sričių sandūra: kodas buvo parašytas, patikros rodė sėkmę, bet niekas nepagalvojo įdėti funkcijos į ekraną.

Keturi būdai apsigauti tikrinant#

1. Nelaukiau visų vertintojų. Paleidau tris lygiagrečias patikras, dvi baigėsi sėkmingai, ir įdiegiau. Trečioji po keturių minučių aptiko šešis pažeidimus. Ką nors taisyti po publikavimo kainuoja daugiau nei palaukti dvi minutes.
2. Pasitikėjau suvestine „apdorota N iš N“. Kai darbo didelė dalis paskirstoma daugeliui agentų, kai kurie tyliai sugenda: praneša apie sėkmę, bet failo nepakeičia. Dabar po kiekvieno rašymo per agentą mechaniškai patikrinu, ar pakeitimai iš tiesų įrašyti į diską.
3. Nepasižiūrėjau savo akimis. Automatinės patikros gali būti sėkmingos, nors rezultatu visiškai neįmanoma naudotis. Vaizdai techniškai teisingi, dydis teisingas, atsakymo kodas teisingas. Tačiau iš tiesų tai automatiniai sustabdyti kadrai, pateikti vietoj turėjusių būti iliustruotų viršelių. Jokia automatinė patikra to nepastebės.
4. Tikrinau, ar reikšmė yra, o ne kokia ji. Patikra ieškojo rezultate privalomo teksto: tekstas buvo, bet jame esantys duomenys buvo neteisingi – data skyrėsi viena diena. Patikra rodė sėkmę, o ataskaita melavo. Dabar tikrinu visą laukiamą reikšmę, nes vien teisingo žodžio buvimas nieko negarantuoja.

Šie keturi atvejai turi bendrą bruožą: patikra buvo atlikta, atrodė įtikinama ir tikrino ne tai, ką reikia. Tokia pati mechanika kaip modelių ir jų testo atveju, tik be jokio išradingumo.

Nuo ko pradėti šiandien#

Trys žingsniai, užtrunkantys dvidešimt minučių.

1. Paimkite paskutinį „atlikta“. Patikrinkite jį pagal įrodymams skirtame skyriuje pateiktą priėmimo užklausą. Tikslas paprastas: pamatyti, kiek elementų užbaigta žodžiais, o kiek – pateikus komandos išvestį.
2. Nusistatykite vieną taisyklę. Žodis „patikrinta“ be pridėtos komandos išvesties nereiškia, kad darbas baigtas. Ši taisyklė skirta jums, ne agentui, ir todėl veikia.
3. Atskirkite darbuotoją nuo vertintojo. Kitoje užduotyje naujoje sesijoje pateikite vertintojo užklausą ir paprašykite įrodyti, kad darbas NEATLIKTAS. Pirmasis bandymas paprastai atperka įprotį.

Įrankis geras ir kas mėnesį tobulėja: dalykai, kuriuos prieš metus agentas atlikdavo tyliai, dabar jį sustabdo. Saugumo riba nuolat juda ir išlieka riba. Kol agentas siekia jam duoto tikslo, klausimas „o kaip tiksliai tai matavote?“ lieka jums. Tikrinimo įprotis yra jūsų saugos tinklas.