Ako overiť tvrdenia AI o cudzom projekte

Odovzdali ste Claude Code neznámy projekt a dostali ste odpoveď: "História sa ukladá v prehliadači, uchováva posledných 100 záznamov a po opätovnom načítaní stránky sa obnoví." Znie to dosť konkrétne na to, aby ste túto vetu vložili do README. Najprv si však otvorte zdroje, o ktoré sa odpoveď opiera.

Pozrime sa na jedno takéto tvrdenie: premeníme požiadavku na otázky, prečítame krátky úryvok kódu a rozoberieme, aké správanie treba overiť pri spustení. Na konci budete mať krátku správu, z ktorej bude jasné, čo funguje a čo ešte treba preveriť.

Jedna požiadavka namiesto prehľadu celého projektu

Haiku 50 je malá aplikácia na tvorbu trojriadkových básní podľa kľúčových slov. Používateľ si vyberie jazyk, dostane text a vidí históriu svojich generácií. Na naše overenie stačí jedna požiadavka: v prehliadači sa má uchovávať posledných 100 generácií, dostupných aj po obnovení stránky.

Ilustrácia k Haiku 50. Správanie aplikácie si nižšie rozoberieme podľa kódu a scenárov.

Haiku 50 tu slúži ako učebný príklad. Kód aj odpovede agenta sú pripravené na rozbor; očakávané správanie odvodíme z kódu. Zdrojový archív projektu tu nekontrolujeme. Všetko potrebné nájdete v článku: aplikáciu netreba sťahovať, získavať API kľúč ani spúšťať generovanie.

Namiesto požiadavky "vysvetli, ako to tu celé funguje" položíme tri otázky. Zapisuje sa nová generácia do úložiska? Načíta si ju aplikácia pri ďalšom otvorení? Čo sa stane, keď je záznamov viac ako sto?

Prvá požiadavka pre Claude Code môže vyzerať takto:

Preskúmaj iba históriu generácií. Kód zatiaľ nemeň.
Nájdi cestu od získania novej básne až po jej uloženie,
potom cestu od otvorenia stránky po zobrazenie histórie.
Over, kde sa obmedzuje počet uložených záznamov.
Pri každom tvrdení uveď súbor, riadky a krátky úryvok.
Samostatne uveď, čo ešte treba overiť spustením.

Takáto požiadavka jasne vymedzí, čo hľadať. Ak agent zistí, že história súvisí s iným súborom, môže vysvetliť, prečo si ho treba prečítať. A vám bude jednoduchšie overiť niekoľko kľúčových miest než celý opis aplikácie.

Odkaz na súbor treba ešte prečítať

Predstavme si učebný súbor history.js. Po úspešnom generovaní rozhranie zavolá addToHistory(item) a renderHistory iba zobrazí odovzdaný zoznam. V tomto príklade nie sú žiadne ďalšie obslužné funkcie histórie.

const STORAGE_KEY = "haiku-history";
let history = [];

function addToHistory(item) {
  history.unshift(item);
  localStorage.setItem(STORAGE_KEY, JSON.stringify(history));
  renderHistory(history.slice(0, 100));
}

function startHistory() {
  renderHistory(history);
}
startHistory();

Na čítanie tohto úryvku stačí rozlišovať dve miesta, kde sa údaje ukladajú. Pole history žije v pamäti otvorenej stránky. localStorage uchováva údaje webu v prehliadači aj medzi jednotlivými otvoreniami; aplikácia ich tam osobitne zapisuje a znova načítava. Úložisko je viazané na protokol, hostiteľa a port, preto pri overovaní používajte tú istú adresu aj profil prehliadača. Toto správanie opisuje dokumentácia localStorage.

Predstavme si, že agent odpovedal:

História ukladá posledných 100 generácií a obnoví sa
po opätovnom načítaní stránky. Zdroj: history.js:4-13,
používajú sa localStorage a slice(0, 100).

Cestu k súboru aj čísla riadkov máme. Teraz overme, či potvrdzujú celé tvrdenie. V učebnom súbore sa prvý riadok začína výrazom const STORAGE_KEY; do číslovania sa počítajú aj prázdne riadky.

• riadok 5, history.unshift(item), vloží nový záznam na začiatok poľa;
• riadok 6, volanie localStorage.setItem, uloží do úložiska celé pole. Prevod na JSON je potrebný, aby sa dalo uložiť ako text;
• riadok 7, renderHistory(history.slice(0, 100)), odovzdá na zobrazenie prvých 100 položiek. slice vytvorí nové pole a pôvodné neskráti, ako uvádza dokumentácia tejto metódy;
• pri spustení riadok 2, let history = [], vytvorí prázdne pole a funkcia startHistory spolu s jej volaním na riadkoch 10-13 ho zobrazí. Načítanie z úložiska tu chýba.

Po prečítaní sa záver mení: kód zapisuje históriu a obmedzuje zobrazenie na sto položiek. Obnovenie pri spustení v tejto implementácii chýba a obmedzenie počtu uložených záznamov sme nenašli.

V skutočnom projekte by tento úryvok nemusel stačiť: načítanie údajov môže byť v inom module. Preto sa oplatí agenta dopýtať: "Ukáž všetky miesta, kde sa tento kľúč číta a zapisuje, a kto tieto funkcie volá." V našom učebnom príklade poznáme hranice, môžeme pokračovať.

Overte správanie po obnovení stránky

Čítanie kódu napovedalo, kde hľadať nesúlad. Teraz si stanovme podmienky pozorovania. Stránka je otvorená v bežnom profile prehliadača na jednej adrese, ukladanie je povolené a história je na začiatku prázdna. V učebnom scenári prebehne jedno úspešné generovanie s ľahko rozpoznateľnou značkou A; kód sa medzi krokmi nemení.

Nižšie je očakávaný priebeh scenára podľa kódu. Pridajme ešte jeden krok: po obnovení stránky získame nový záznam B.

Pri skutočnom pozorovaní si obsah úložiska môžete pozrieť v nástrojoch pre vývojárov prehliadača, v časti s údajmi webu. Otvorte hodnotu konkrétneho kľúča a porovnajte záznam s tým, ktorý ste práve pridali. Samotný prázdny zoznam na obrazovke nestačí.

Veta "po obnovení sa všetko vymazalo" by nebola presná. Údaje zostali v úložisku, aplikácia ich však nenačítala. V tejto implementácii sa reťazec preruší medzi uloženým textom a poľom, ktoré sa odovzdáva na zobrazenie.

Ďalšie pridanie ukáže dôsledok tejto chyby. Po obnovení je pole v pamäti prázdne, takže sa doň dostane iba B a localStorage.setItem nahradí uloženú históriu poľom s jediným záznamom. Podľa požiadavky by mali zostať B aj A; podľa kódu zostane iba B. Problém sa týka zobrazenia aj uchovania histórie.

Záver podľa kódu už môžete zapísať: "V startHistory sa uložená história nenačítava; ďalšie pridanie prepíše predchádzajúce záznamy." Ak chcete správanie potvrdiť spustením, prejdite všetky štyri kroky a po každom porovnajte zoznam na obrazovke s obsahom úložiska.

Overte počet 100

Obnovovanie histórie máme objasnené. V požiadavke zostáva druhá časť: uchovávať posledných 100 generácií. Túto hranicu nemožno overiť jediným záznamom.

Vyskúšajme samostatný scenár s prázdnou históriou. Do tej istej funkcie postupne pošleme 101 pripravených záznamov označených číslami od 1 do 101, bez obnovenia stránky medzi pridaniami. Na overenie samotnej histórie netreba posielať 101 požiadaviek generátoru: zaujíma nás správanie po získaní hotového záznamu.

Nový záznam sa vloží na začiatok poľa. Po poslednom pridaní preto na obrazovke uvidíme značky od 101 po 2, spolu 100. Riadok s uložením však dostal celé pole: v úložisku zostanú značky od 101 po 1, spolu 101. Overiť treba počet aj zloženie záznamov. Inak si nemusíte všimnúť, že aplikácia ponecháva najstaršie namiesto posledných.

Práve tu bol záver agenta príliš široký. Číslo 100 sa v kóde naozaj nachádza, týka sa však zobrazenia. Presný záver podľa kódu: "Rozhranie zobrazuje posledných 100 záznamov; úložisko v uvedenom scenári obsahuje 101, takže požiadavka na rozsah uloženej histórie nie je splnená."

Zostavte krátku správu

Výsledok skúmania si môžete uložiť vedľa projektu, aby ste si zajtra nemuseli znovu čítať celý rozhovor. V príklade súbor pomenujeme HANDOFF_REVIEW.md. Názov je len príklad; dôležité je, aby sa zo záznamu dal zrekonštruovať postup overovania.

Tu je správa po prečítaní učebného kódu. Časť s očakávaným správaním napovedá, čo sledovať pri spustení:

Oblasť: história generácií, učebná verzia history.js z článku.
Spôsob skúmania: čítanie učebného úryvku.
Test v prehliadači sa nevykonal.

Požiadavka: uchovávať posledných 100 generácií v prehliadači
a zobrazovať ich po obnovení stránky.

Podľa kódu:
- history.js:6, localStorage.setItem, zapisuje celé pole;
- history.js:7, renderHistory(history.slice(0, 100)),
  obmedzuje iba zobrazenie;
- history.js:10-13, startHistory a jej volanie,
  spustia zobrazenie bez načítania uložených údajov.

Očakávané správanie podľa kódu:
- po pridaní sa záznam A zobrazí na obrazovke aj v úložisku;
- po obnovení stránky zostane A v úložisku, zoznam bude prázdny;
- pridanie B po obnovení nahradí uloženú históriu:
  zostane iba B namiesto B a A;
- v samostatnom scenári po 101 pridaniach od prázdneho stavu
  bude na obrazovke 100 záznamov (101..2), v úložisku 101 (101..1).

Nesúlady podľa kódu: pri spustení sa história nenačíta,
preto ďalšie pridanie prepíše predchádzajúcu históriu;
uložená história nie je obmedzená na posledných 100 záznamov.

Neoverené: fungovanie generátora, chyby pri ukladaní,
súbežná práca vo viacerých kartách.

Ďalší krok: prejsť oba scenáre a zaznamenať pozorovania.
Potom opraviť načítanie pri spustení a obmedzenie ukladaného
poľa a zopakovať tie isté scenáre.

Vo vlastnej správe namiesto "učebnej verzie" uveďte overenú verziu projektu, napríklad commit a informáciu o necommitnutých zmenách. Po spustení pridajte samostatnú časť "Skutočné pozorovania" a priložte výsledky alebo záznam ručne vykonaných krokov. Porovnajte ich s očakávaným správaním; ak sa aplikáciu nepodarilo spustiť, nechajte túto časť nevyplnenú s príslušnou poznámkou. Tu sa všetky vstupné údaje zmestia do článku; pri veľkom projekte samotné odkazy na riadky nebudú stačiť, aby sa overenie dalo zopakovať.

Takáto správa pomôže zadať agentovi ďalšiu úlohu. Má už dva konkrétne nesúlady, nie iba požiadavku "urob históriu spoľahlivejšou". Zároveň vidno, ku ktorým záverom je ešte priskoro dospieť.

Overte si záver sami

Do tej istej učebnej implementácie sme pridali tlačidlo na vymazanie. Jeho obslužná funkcia vyzerá takto:

function clearHistory() {
  history = [];
  renderHistory(history);
}

Pred kliknutím bol v zozname aj v úložisku záznam A. Po kliknutí sa zoznam vyprázdnil. Agent napísal: "Tlačidlo úplne vymaže uloženú históriu."

Ktorý záver je potvrdený: história zmizla z obrazovky, záznam sa vymazal z localStorage alebo oboje? A čo sa oplatí overiť ďalej? Skúste odpovedať ešte pred rozborom.

Rozbor

Potvrdené je, že zoznam zmizol z obrazovky. Kód ukazuje aj vynulovanie poľa v pamäti. Obslužná funkcia však nemení localStorage a podľa zadania renderHistory iba vykresľuje zoznam, takže uložený záznam A zostáva na mieste.

Ďalším krokom je hneď po kliknutí načítať hodnotu kľúča haiku-history. Po doplnení obnovovania histórie sa oplatí stránku aj znovu načítať a overiť, že vymazané záznamy sa nevrátili. V pôvodnej verzii by samotné opätovné načítanie stránky nepomohlo: pri spustení zobrazuje prázdny zoznam aj bez vymazania. Aj toto vie overovanie nenápadne skomplikovať.

Ako zadávať takéto úlohy Claude Code

V pracovnom projekte začnite jedným tvrdením, ktoré ovplyvní vaše ďalšie rozhodnutie. Napríklad či sa dá históriu používať, alebo treba najprv opraviť jej obnovovanie. Zadajte agentovi formát odpovede, pri ktorom ľahko otvoríte zdroj a overíte záver:

Over tvrdenie: [konkrétne správanie aplikácie].
Najprv nájdi súbory, ktoré s ním súvisia, a prečítaj potrebné miesta.
Kód zatiaľ nemeň.

Uveď:
1. Čo potvrdzuje kód: súbor, riadky, krátky úryvok.
2. Aký scenár overí správanie pri spustení.
3. Čo sa skutočne vykonalo a čo sa pozorovalo.
4. Presný záver a zostávajúce neznáme.

Ak aplikáciu nemožno spustiť, napíš to priamo.
Navrhnutý scenár neuvádzaj ako vykonané overenie.

Po odpovedi otvorte zdroje kľúčového záveru, porovnajte pozorovanie s požiadavkou a až potom výsledok preneste do poznámok alebo dokumentácie. Ak zdroj nestačí, ďalšia požiadavka je jasná: nájsť načítanie histórie, overiť hodnotu kľúča a zopakovať scenár so 101 záznamami. Takto postupuje skúmanie v malých, overiteľných krokoch.

Pri jednoduchej otázke na názov funkcie stačí odkaz na kód. Keď odpoveď zahŕňa ukladanie údajov, obnovovanie alebo obmedzenie veľkosti, oplatí sa sledovať príslušné správanie až do konca. Rozsah overenia určuje to, čo chcete tvrdiť.