Jak ověřit závěry AI o cizím projektu

Předali jste Claude Code neznámý projekt a dostali odpověď: "Historie se ukládá v prohlížeči, uchovává posledních 100 záznamů a po obnovení stránky se načte zpět." Zní to dost konkrétně na to, abyste tu větu přenesli do README. Nejdřív je ale dobré otevřít zdroje, o které se odpověď opírá.

Podíváme se na jeden takový závěr: převedeme požadavek na otázky, přečteme krátký úryvek kódu a určíme, jaké chování je třeba ověřit při spuštění. Nakonec vznikne stručná zpráva, ze které bude jasné, co funguje a co se ještě musí ověřit.

Jeden požadavek místo přehledu celého projektu

Haiku 50 je malá aplikace, která z klíčových slov generuje básně o třech řádcích. Uživatel si vybere jazyk, dostane text a vidí historii svých generování. Pro naši analýzu stačí jeden požadavek: v prohlížeči se má uchovávat posledních 100 generování, dostupných i po obnovení stránky.

Ilustrace k Haiku 50. Chování aplikace rozebereme podle kódu a scénářů níže.

Haiku 50 tu slouží jako výukový příklad. Kód i odpovědi agenta jsou připravené pro analýzu; očekávané chování odvodíme z kódu. Zdrojový archiv projektu zde neověřujeme. Vše potřebné najdete v článku: aplikaci není třeba stahovat, získávat API klíč ani spouštět generování.

Místo "vysvětli, jak to celé funguje" si položíme tři otázky. Ukládá se nové generování do úložiště? Načte aplikace uložená data při příštím otevření? Co se stane, když záznamů bude víc než sto?

První dotaz pro Claude Code může vypadat takto:

Prozkoumej pouze historii generování. Kód zatím neměň.
Najdi cestu od získání nové básně k jejímu uložení,
pak cestu od otevření stránky k zobrazení historie.
Zjisti, kde se omezuje počet uložených záznamů.
U každého závěru uveď soubor, řádky a krátký úryvek.
Zvlášť vypiš, co je ještě potřeba ověřit spuštěním.

Takový dotaz jasně vymezí oblast hledání. Pokud agent zjistí, že historie souvisí s jiným souborem, může vysvětlit, proč se na něj podívat. Vám se pak bude snáz ověřovat několik klíčových míst než celý popis aplikace.

Odkaz na soubor je třeba také přečíst

Představme si výukový soubor history.js. Po úspěšném generování zavolá rozhraní addToHistory(item), zatímco renderHistory pouze zobrazí předaný seznam. V tomto příkladu nejsou žádné další obslužné funkce historie.

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();

Při čtení tohoto úryvku stačí rozlišovat dvě místa, kde se data uchovávají. Pole history žije v paměti otevřené stránky. localStorage uchovává data webu v prohlížeči i mezi návštěvami; aplikace do něj data zvlášť zapisuje a také je z něj čte. Úložiště je vázané na protokol, hostitele a port, takže při ověřování musíte použít stejnou adresu i profil prohlížeče. Toto chování popisuje dokumentace localStorage.

Předpokládejme, že agent odpověděl:

Historie ukládá posledních 100 generování a po obnovení stránky
se načte zpět. Podklad: history.js:4-13,
používají se localStorage a slice(0, 100).

Soubor i řádky uvedl. Teď ověříme, zda skutečně potvrzují celé tvrzení. Ve výukovém souboru začíná první řádek výrazem const STORAGE_KEY; do číslování se počítají i prázdné řádky.

• řádek 5, history.unshift(item), přidá nový záznam na začátek pole;
• řádek 6, volání localStorage.setItem, uloží do úložiště celé pole. Převod na JSON je potřeba, aby se data uložila jako řetězec;
• řádek 7, renderHistory(history.slice(0, 100)), předá k zobrazení prvních 100 položek. slice vytvoří nové pole a původní nezkrátí, jak uvádí dokumentace této metody;
• při spuštění vytvoří řádek 2, let history = [], prázdné pole a funkce startHistory spolu s jejím voláním na řádcích 10-13 ho předá k zobrazení. K načtení dat z úložiště tu nedochází.

Po přečtení odpověď vypadá jinak: kód počítá s ukládáním historie a omezuje zobrazení na sto položek. V této implementaci však při spuštění nedochází k obnovení historie a omezení počtu uložených záznamů jsme nenašli.

V reálném projektu by tento úryvek nemusel stačit: načítání dat může být v jiném modulu. Proto se agenta vyplatí zeptat: "Ukaž všechna místa, kde se tento klíč čte a zapisuje, a kdo tyto funkce volá." V našem výukovém příkladu jsou hranice jasné, můžeme pokračovat dál.

Ověřme chování po obnovení stránky

Čtení kódu napovědělo, kde hledat nesoulad. Teď určíme podmínky pozorování. Stránka je otevřená v běžném profilu prohlížeče na jedné adrese, ukládání je povolené a historie je zpočátku prázdná. Ve výukovém scénáři proběhne jedno úspěšné generování s rozpoznatelnou značkou A; kód se mezi kroky nemění.

Níže je očekávaný průběh scénáře podle kódu. Přidáme ještě jeden krok: po obnovení stránky získáme nový záznam B.

Při skutečném pozorování si obsah úložiště můžete prohlédnout v nástrojích pro vývojáře prohlížeče, v části s daty webu. Otevřete hodnotu konkrétního klíče a porovnejte záznam s tím, který jste právě přidali. Prázdný seznam na obrazovce nestačí.

Tvrzení "po obnovení se všechno smazalo" by nebylo přesné. Data v úložišti zůstala, aplikace je ale nenačetla. V této implementaci se tok dat přeruší mezi uloženým řetězcem a polem, které se předává k zobrazení.

Další přidání ukazuje důsledek této chyby. Po obnovení je pole v paměti prázdné, takže se do něj dostane jen B a localStorage.setItem nahradí uloženou historii polem s jediným záznamem. Podle požadavku mají zůstat B i A; podle kódu zůstane jen B. Problém se týká zobrazení i uchování historie.

Závěr podle kódu už můžeme zapsat: "Ve startHistory se uložená historie nenačítá; další přidání přepíše předchozí záznamy." Chcete-li potvrdit chování při spuštění, projděte všechny čtyři kroky a po každém porovnejte seznam na obrazovce s obsahem úložiště.

Ověřme počet 100

S obnovením historie jsme hotovi. Zbývá druhá část požadavku: uchovávat posledních 100 generování. Hranici nelze ověřit na jediném záznamu.

Vezměme samostatný scénář s prázdnou historií. Postupně předáme stejné funkci pro přidávání 101 připravených záznamů označených od 1 do 101, bez obnovení stránky mezi přidáními. Pro ověření samotné historie není potřeba 101krát volat generátor: zajímá nás, co se stane po získání hotového záznamu.

Nový záznam se přidá na začátek pole. Po posledním přidání se proto na obrazovce zobrazí značky od 101 do 2, celkem 100. Řádek s ukládáním ale dostal celé pole: v úložišti zůstanou značky od 101 do 1, celkem 101. Je třeba ověřit počet i složení záznamů. Jinak si nemusíte všimnout, že aplikace ponechává nejstarší místo posledních.

Tady byla odpověď agenta příliš obecná. Číslo 100 se v kódu opravdu objevuje, ale vztahuje se k zobrazení. Přesný závěr podle kódu: "Rozhraní zobrazuje posledních 100 záznamů; v popsaném scénáři jich úložiště obsahuje 101, takže požadavek na počet uložených záznamů není splněn."

Sestavme krátkou zprávu

Výsledek analýzy se hodí uložit vedle projektu, abyste zítra nemuseli znovu číst celý rozhovor. V příkladu soubor pojmenujeme HANDOFF_REVIEW.md. Název je jen ukázkový; důležité je, aby se z poznámek dal průběh ověření zrekonstruovat.

Tady je zpráva založená na čtení výukového kódu. Oddíl s očekávaným chováním napovídá, co hledat při spuštění:

Oblast: historie generování, výuková verze history.js z článku.
Způsob zkoumání: čtení výukového úryvku.
Test v prohlížeči neproběhl.

Požadavek: uchovávat posledních 100 generování v prohlížeči
a zobrazovat je po obnovení stránky.

Podle kódu:
- history.js:6, localStorage.setItem, ukládá celé pole;
- history.js:7, renderHistory(history.slice(0, 100)),
  omezuje pouze zobrazení;
- history.js:10-13, startHistory a její volání,
  spouštějí zobrazení bez načtení uložených dat.

Očekávané chování podle kódu:
- po přidání se záznam A objeví na obrazovce i v úložišti;
- po obnovení stránky zůstane A v úložišti, seznam bude prázdný;
- přidání B po obnovení nahradí uloženou historii:
  zůstane jen B místo B a A;
- v samostatném scénáři po 101 přidáních z prázdného stavu
  bude na obrazovce 100 záznamů (101..2), v úložišti 101 (101..1).

Nesoulad podle kódu: při spuštění se historie neobnoví,
proto další přidání přepíše předchozí historii;
uložená historie není omezena na posledních 100 záznamů.

Neověřeno: fungování generátoru, chyby při ukládání,
současná práce ve více kartách.

Další krok: zopakovat oba scénáře a zaznamenat pozorování.
Pak opravit načítání při spuštění a omezení ukládaného
pole a stejné scénáře zopakovat.

Ve své zprávě místo "výukové verze" uveďte ověřenou verzi projektu, například commit a informaci o necommitnutých změnách. Po spuštění přidejte samostatný oddíl "Skutečná pozorování" a přiložte výsledky nebo záznam ručně provedených kroků. Porovnejte je s očekávaným chováním; pokud se aplikaci nepodařilo spustit, nechte oddíl prázdný a uveďte to. Tady se všechny podklady vejdou do článku; u většího projektu by k zopakování ověření samotné odkazy na řádky nestačily.

Taková zpráva pomůže zadat agentovi další úkol. Má už dvě konkrétní nesrovnalosti místo žádosti "udělej historii spolehlivější". Zároveň je vidět, které závěry jsou zatím předčasné.

Ověřte si závěr sami

Do stejné výukové implementace jsme přidali tlačítko pro vymazání. Jeho obslužná funkce vypadá takto:

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

Před kliknutím byl v seznamu i úložišti záznam A. Po kliknutí se seznam vyprázdnil. Agent napsal: "Tlačítko úplně smaže uloženou historii."

Co je potvrzené: zmizela historie z obrazovky, byl záznam smazán z localStorage, nebo obojí? A co byste měli ověřit dál? Zkuste odpovědět ještě před vysvětlením.

Vysvětlení

Potvrzené je zmizení seznamu z obrazovky. Z kódu je vidět i vynulování pole v paměti. Obslužná funkce ale localStorage nemění a renderHistory podle zadání pouze vykreslí seznam, takže uložený záznam A zůstává.

Další ověření: hned po kliknutí přečtěte hodnotu klíče haiku-history. Až bude implementované obnovení historie, hodí se stránku také znovu načíst a ověřit, že smazané záznamy se nevrátily. V původní verzi by samotné znovunačtení stránky nepomohlo: při spuštění zobrazuje prázdný seznam i bez vymazání. Taková nenápadná překážka ověřování.

Jak zadávat podobné úkoly Claude Code

V pracovním projektu začněte jedním tvrzením, které ovlivní vaše další rozhodnutí. Například zda lze historii používat, nebo je nejdřív potřeba opravit její obnovování. Zadejte agentovi formát odpovědi, ve kterém snadno otevřete zdroj a ověříte závěr:

Ověř tvrzení: [konkrétní chování aplikace].
Nejprve najdi soubory, které s ním souvisejí, a přečti příslušná místa.
Kód zatím neměň.

Vrať:
1. Co potvrzuje kód: soubor, řádky, krátký úryvek.
2. Jaký scénář ověřuje chování při spuštění.
3. Co se skutečně provedlo a co bylo pozorováno.
4. Přesný závěr a zbývající neznámé.

Pokud aplikaci nelze spustit, napiš to přímo.
Navržený scénář nevydávej za provedené ověření.

Po odpovědi otevřete zdroje klíčového závěru, porovnejte pozorování s požadavkem a teprve potom výsledek přeneste do poznámek nebo dokumentace. Pokud zdroj nestačí, další dotaz je jasný: najít načítání historie, ověřit hodnotu klíče a zopakovat scénář se 101 záznamy. Tak se analýza posouvá po malých, ověřitelných krocích.

U jednoduché otázky na název funkce stačí odkaz na kód. Když odpověď zahrnuje ukládání dat, jejich obnovení nebo omezení velikosti, vyplatí se příslušné chování sledovat až do konce. Rozsah ověření určuje to, co chcete tvrdit.