Cíl dne

Účastník na vlastním dotazu prokáže halucinaci modelu u konkrétní ČSN a popíše, podle čeho ji pozná; zároveň odchází s vyplněnou triáží 12 firemních zadání (vložit / upravit / nikdy), s prvním draftem jednostránkového interního pravidla „co do AI patří a co ne" a s jedním vlastním anonymizovaným strukturovaným zadáním ověřeným proti zdroji (úvod do prompt engineeringu).

Úvodní cvičení dne (15 min)

Cíl: ověřit, jak role, formát a omezení v zadání mění výstup modelu ze stejných vstupních dat — a co model doplní sám, když mu zadání nechá volné místo.

Norma jinak. Každý dostane stejný krátký odstavec — anotaci jedné technické normy (rozdají se tři varianty, ať je srovnání širší). Úkol: nech AI přepsat tentýž odstavec do jednoho ze tří formátů — recept, horoskop, recenze na e-shopu (hodnocení hvězdičkami povinné). Dvě minuty píšeš zadání, dvě minuty běží model, dvě minuty čteme nahlas nejzajímavější výstupy a porovnáváme je s původním odstavcem. Kdo nechce číst, nemusí.

Vzor, ať je jasné, o co jde (formát recenze — anotace normy o všeobecných tolerancích přepsaná jako recenze produktu):

ČSN ISO 2768-1 — dorazila jako PDF, ihned ke stažení. Tabulky přehledné, čtyři třídy přesnosti se pamatují snadno. Slabina: bez výkresu, na kterém je označení uvedeno, je k ničemu. Používám denně od roku 2019. 4/5.

Všimni si: „používám denně od roku 2019" v anotaci nikdy nebylo. Model to doplnil sám.

Chyba dne (2 min): dnes z lektorovy zásoby — právě ten doplněný rok v recenzi výše. Od zítřka bude Chyba dne vždy z vašich vlastních výstupů z předchozího dne: skvěle formulovaná odpověď, která je věcně mimo.

Pointa: Stejná fakta + jiná role a formát = jiný výstup. A druhá, důležitější polovina závěru: všimni si, co model přidal navíc — údaj, číslo nebo termín, který v původním odstavci nebyl. Nikdo mu to nezadal, doplnil to sám. Přesně tomuhle se dnes budeme celý den věnovat.

Témata (osnova)

Tech-check (20 min, hned na začátku)

• Google Meet: zvuk, chat, reakce, sdílení obrazovky, rozložení na dva monitory (výklad vlevo, práce vpravo)
• Přístup k modelu: gemini.google.com (Gemini, zdarma s Google účtem) nebo aistudio.google.com (AI Studio) — každý si ověří, že mu funguje aspoň jedna cesta; limity bezplatné vrstvy ověříme rovnou
• Sdílený Drive kurzu: složka „Kurz AI — Normservis", právo editovat, sdílená tabulka dne
• Apps Script: script.google.com → „Nový projekt" (jen ověřit, že se otevře; pracovat s ním budeme od dne 3)
• Kdo má terminál a může instalovat sám / kdo přes IT — zapíšeme do tabulky, ať se to už neřeší

Blok 1 — Co AI v roce 2026 opravdu umí (Metis blok 1)

• Jazykový model bez matematiky: předpovídá pokračování textu. Proč z toho plyne úplně všechno ostatní.
• Co se za poslední dva roky reálně změnilo: dlouhý kontext (celé PDF Věstníku, ~85 stran ≈ 115 000 tokenů, se vejde do AI Studia; Gemini app pracuje s menším kontextovým oknem, kolem 32 000 tokenů ≈ 50 stran), čtení dokumentů a obrázků, uvažovací modely, agenti a nástroje, generování kódu
• Mapa nástrojů a k čemu který: Gemini / AI Studio (naše hlavní cesta, zdarma), ChatGPT (bezplatná verze — druhý názor), Claude (jen ukázka lektora), GitHub Copilot Free / Gemini Code Assist (asistent v IDE), lokální modely (Ollama na vlastním Linux serveru firmy — den 8)
• Úlohy, kde AI vydělá čas: přeformulování, shrnutí, extrakce ze struktury, vysvětlení cizího kódu (PHP z EviNoru, VB z Kovy/EviZak), první návrh textu
• Úlohy, kde AI čas sežere: přesná čísla zpaměti, aktuální platnost čehokoli, rozhodnutí s odpovědností, práce, kterou stejně musíš kontrolovat řádek po řádku

Blok 2 — Kde AI končí: halucinace naostro na ČSN (Metis blok 1)

• Ukázka lektora: modelu položíme dotaz na konkrétní normu — označení, třídicí znak, rok vydání, zda platí, čím byla nahrazena. Odpověď zní perfektně. Pak ji porovnáme se zdrojem.
• Proč se to děje: označení normy je pro model tvar textu, ne záznam v evidenci. Nemá databázi, kterou by se šel podívat — na rozdíl od EviNoru (PHP/MySQL, ~1 000 000 norem).
• Sledování halucinací — během ukázky každý zapisuje údaje, které model tvrdí a které ve zdroji nejsou; první nález se hlásí do chatu.
• Nedeterminismus: stejný dotaz třikrát → tři odpovědi. Co to znamená pro kontrolu (jeden správný pokus nic nedokazuje).
• Jak se halucinace pozná dřív, než uškodí: dotaz „z čeho čerpáš?", zákaz dogenerování, práce s přiloženým podkladem místo paměti modelu, namátková kontrola vzorku
• Proč se tohle Normservisu týká víc než jiným: zákazník má garantováno platné znění. Chybná informace o platnosti normy není překlep, je to škoda u zákazníka.

Blok 3 — Kde AI běží a co ven nepatří (Metis blok 2)

• Živé srovnání: tentýž dotaz do cloudového Gemini a do modelu běžícího na stanici lektora. Rychlost, kvalita, a hlavně — kam odešlo zadání.
• Co se s promptem děje: rozdíl mezi osobním účtem, firemním Google Workspace a modelem na vlastním železe (Linux server firmy); co znamená „data se nepoužívají k trénování"; logy, retence, kdo je správce
  • Firemní účet Google Workspace: obsah konverzací se nepoužívá k trénování modelů a nečtou ho lidští posuzovatelé.
  • Osobní účet Google se zapnutou aktivitou v Gemini: konverzace se mohou použít ke zlepšování služeb a část z nich čtou lidští posuzovatelé.
  • AI Studio: v EHP (tedy i v ČR) platí i pro bezplatné použití pravidla placených služeb — obsah se nepoužívá k trénování.
  • Vlastní server: zadání neopustí firmu.
  • Stav k 11. 10. 2026. Podmínky poskytovatelů se mění — před zavedením ve firmě je ověří odpovědná osoba.
• Věcná odbočka: co AI dělá s cenami hardwaru. Poptávka datacenter po GPU a paměti se propisuje do cen RAM, SSD i grafik. Je to reálný náklad, ne detail. Dnes to jen pojmenujeme a napíšeme na tabuli — spočítáme to v dnu 8 (TCO cloud vs. vlastní server, který firma má).
• Pravidlo firmy z dotazníku: do AI smí vše kromě osobních údajů, dat klientů a informací o firmě. Co to znamená v konkrétních situacích — a proč je Věstník ÚNMZ (veřejný dokument) ideální materiál, který ven smí bez obcházení čehokoli.
• Anonymizace zadání: jak z dotazu zákazníka udělat dotaz, který ven poslat můžeš (jména, IČO, čísla objednávek, názvy klientů → zástupné značky)
• Poslední krok před odesláním nebo importem do EviNoru dělá vždy člověk. Tohle pravidlo bude platit celý kurz.

Blok 4 — Dílna: první strukturované zadání na vlastní agendě (Metis blok 3 — úvod do prompt engineeringu)

• Čtyři části zadání, které dnes stačí: role · podklad · formát výstupu · co model nesmí dogenerovat. Teorie přijde v dnu 2, dnes se to jen vyzkouší na jedné reálné úloze.
• Každý pracuje s vlastním dotazem ze své agendy: anonymizuje ho (blok 3), napíše strukturované zadání, ověří výstup proti zdroji (blok 2).
• Cesta B: anonymizátor v1 naostro, srovnání dvou modelů nad stejným dotazem.

Harmonogram

Cvičení

Cvičení 1 — Vlastní test halucinace (blok 2)

Varianta A — jen prohlížeč (všichni)

1. Vyber 5 označení norem, která znáš ze své agendy (klidně ta, se kterými jsi dělal minulý týden).
2. Do modelu (Gemini nebo AI Studio) polož u každé stejný strukturovaný dotaz: > Uveď u normy [označení]: přesný název, třídicí znak, rok vydání, zda je aktuálně platná, a čím byla případně nahrazena. Odpověz tabulkou.
3. Odpovědi zapiš do sdílené tabulky kurzu, list „Test halucinace" (sloupce: označení · co tvrdí AI · co říká zdroj · verdikt: sedí / nesedí / vymyšleno · co konkrétně bylo špatně).
4. Ověř proti zdroji — Věstník ÚNMZ na webu firmy nebo EviNor (vaše evidence norem). Nezkoumej dojem, zkoumej údaj.
5. Poslední řádek napiš sám sobě: „Tenhle model lže spolehlivě v: …" (jednou větou, vlastními slovy).

Hotový výstup: vyplněný řádek v týmové tabulce + vlastní věta. Nikdo nečeká na nikoho — každý pracuje se svými pěti normami.

Varianta B — terminál / IDE (programátoři, ředitel)

• Totéž, ale dávkově: přes AI Studio („Get code", bezplatná kvóta API na to stačí) nebo skriptem spusť stejných 5 dotazů 3× po sobě a ulož odpovědi vedle sebe. Ukaž, jak moc se liší → nedeterminismus černé na bílém.
• Pošli tentýž dotaz do lokálního modelu (stanice lektora / vlastní Ollama, kdo už ji má) a porovnej: latence, kvalita, a hlavně — v síťové konzoli je vidět, že ven neodešlo nic.
• Bonus: napiš do sdíleného repozitáře krátký diff skript, který dvě sady odpovědí porovná a vypíše rozdíly. Použijeme ho znovu v dnu 7 při kontrole extrakce.

Cvičení 2 — Triáž 12 zadání: vložit / upravit / nikdy (blok 3)

Varianta A — jen prohlížeč (všichni) · dvojice, 20 min, sdílený Google Doc U každého z dvanácti zadání rozhodni vložit (může ven tak, jak je) / upravit (jde ven po anonymizaci — napiš jak) / nikdy:

1. Odstavec z Věstníku ÚNMZ k přepsání do jedné věty
2. E-mail od zákazníka s jeho jménem, firmou a číslem objednávky
3. Dotaz „jaký je rozdíl mezi ČSN EN a ČSN EN ISO"
4. Výřez z evidence norem (EviNor) včetně sloupce se jmény zákazníků
5. Chybová hláška z vlastního účetního systému včetně cesty k souboru a názvu databáze
6. Popis normy z veřejného e-shopu (platforma nody.cz), který má jít do nabídky
7. Seznam zákazníků s trvalou objednávkou v daném oboru
8. Kus PHP kódu z EviNoru (PHP/MySQL) bez přístupových údajů
9. Kus PHP kódu z EviNoru s připojovacím řetězcem k MySQL databázi
10. Dotaz na formulaci zdvořilé odpovědi „norma byla zrušena bez náhrady"
11. Naskenovaná objednávka s podpisem a adresou
12. Struktura tabulky (názvy sloupců MySQL) pro evidenci vydaných norem

Hotový výstup: vyplněná tabulka 12 řádků se zdůvodněním u sporných případů. Sporné případy si značíme — jsou to nejcennější řádky dne.

Varianta B — terminál / IDE

• Navíc: napiš krátkou funkci (PHP 8 nebo Python, dle chuti), která z textu vymaskuje e-maily, telefony, IČO a čísla objednávek → anonymizátor zadání v1. Vrátíme se k němu v dnu 5 a v dnu 11 ho použije agent.

Cvičení 3 — První draft interního pravidla (blok 3, 25 min)

Varianta A i B, všichni společně — jeden sdílený dokument, jedna strana, vaše slova, žádná právničina. Kostra, kterou vyplňujete (každá sekce max 5 řádků):

• Co smí do AI bez ptaní — (veřejné dokumenty, obecné dotazy, …)
• Co smí po úpravě — a jak se úprava dělá (konkrétní postup, ne „opatrně")
• Co nesmí nikdy — osobní údaje · data klientů · informace o firmě (rozepsat do příkladů, ať je to použitelné)
• Co se musí vždy ověřit proti zdroji — a kdo to dělá
• Kdo rozhoduje, když je to sporné — jméno, ne funkce
• Co dělat, když se něco pošle omylem — tři kroky

Hotový výstup: jednostránkový draft v Drive kurzu. Není to finální směrnice — je to text, který v dnu 12 doladíme a předáme vedení. Během kurzu ho budeme doplňovat pokaždé, když narazíme na nový sporný případ.

Dílna (blok 4) — Anonymizované strukturované zadání na vlastní agendě (60 min)

Úvod do prompt engineeringu na jedné reálné úloze. Spojuje všechno, co dnes proběhlo: anonymizaci (blok 3), strukturované zadání a ověření proti zdroji (blok 2).

• Cesta A — vlastní dotaz (všichni, 20 min). Vezmi jednu reálnou úlohu, kterou jsi v posledních dnech řešil (dotaz zákazníka, odstavec do nabídky, vysvětlení normy). 1) Anonymizuj ji podle pravidla, které jste právě sepsali (jména, IČO, čísla objednávek → zástupné značky). 2) Napiš zadání ve čtyřech částech: role (kdo model je) · podklad (text, ze kterého má vycházet — vlož ho) · formát výstupu (tabulka, tři věty, seznam) · co nesmí dogenerovat („neuváděj údaje, které v podkladu nejsou; kde chybí, napiš CHYBÍ"). 3) Spusť a ověř výstup proti zdroji. Hotový výstup: řádek v listu „Moje první zadání" (původní dotaz · anonymizovaný dotaz · zadání · výstup · verdikt · co model doplnil navíc).
• Kdo má hotovo — druhé kolo testu halucinace na zahraničních normách (15 min). Tytéž strukturované dotazy jako v cvičení 1, ale na DIN, ISO nebo ASTM. U méně častých označení model dogenerovává ochotněji; do tabulky „Test halucinace" zapiš, zda se to potvrdilo. Hotový výstup: 2–3 řádky navíc + jedna věta „u zahraničních norem model … oproti ČSN".
• Cesta B — anonymizátor v1 naostro + srovnání dvou modelů (programátoři, ředitel). Funkci z cvičení 2 pusť na třech reálných (a poté zamaskovaných) dotazech zákazníka a zapiš, co propustila (typicky: jméno v oslovení, IČO bez mezer, číslo objednávky ve formátu, který regex nečekal). Pak tentýž strukturovaný dotaz pošli v AI Studiu do dvou různých modelů vedle sebe a porovnej: shodují se ve vymyšlených údajích, nebo si každý vymýšlí jinak? Hotový výstup: commit anonymizátoru v1 do repozitáře kurzu s krátkým README „co propouští" + řádek srovnání dvou modelů v tabulce. Anonymizátor se vrací v dnu 5, používá ho agent v dnu 11; srovnání modelů předehrává den 8.
• Kontrola „ukaž mi to" (10 min) + most do závěru (10 min). Tři lidé sdílejí obrazovku: původní dotaz, anonymizovaný dotaz, výstup, verdikt. Pak každý do chatu: „Kterou z dnešních odpovědí bys poslal zákazníkovi tak, jak je?" — číslo řádku a jedna věta proč. Dvě nejlepší věty jdou rovnou do draftu pravidla z cvičení 3.

Technické předpoklady dne

• Nutné: prohlížeč, Google Meet, Google účet. Přístup k modelu buď gemini.google.com (Gemini, zdarma s Google účtem), nebo aistudio.google.com (AI Studio) — obě cesty fungují na bezplatné vrstvě a den 1 je na nich plnohodnotný; firma žádnou placenou AI nemá a žádné cvičení ji nevyžaduje. Při vyčerpání bezplatné kvóty Gemini se přepíná na AI Studio nebo druhý Google účet. Kdo nemá ani jedno, dostane na dnešek přístup do sdíleného prostoru a pracuje ve dvojici.
• Sdílený Drive kurzu: složka „Kurz AI — Normservis" (tabulka dne s listy „Test halucinace", „Moje první zadání", „Nálezy dne"; dokument triáže; dokument pravidla) — právo editovat pro všechny.
• Druhý monitor (má ho celý tým): vlevo výklad a sdílená obrazovka, vpravo vlastní práce.
• Ověřit, neinstalovat: script.google.com se má otevřít a nabídnout „Nový projekt". Pokud ne → zapsat do tech-check tabulky, řeší se s IT do dne 3.
• Varianta B: terminál, Git, přístup na GitHub, cvičný repozitář kurzu (odkaz v Drive), PHP 8 nebo Python. Instalace lokálního modelu dnes není potřeba — lokální model dnes běží u lektora a všichni ho vidí přes sdílenou obrazovku.
• Podklady k ruce: dvě čísla Věstníku ÚNMZ v PDF (ke stažení z webu firmy) a přístup do EviNoru (vaše evidence norem, PHP/MySQL) pro ověřování.

Mini-úkol na příště

Přines tři reálné věci ze své agendy (v elektronické podobě, ať s nimi zítra můžeme pracovat):

1. jeden dotaz zákazníka, na který jsi v posledních dnech odpovídal (jména a identifikaci klienta si předem zamaskuj — dnes ses to naučil),
2. jeden odstavec z Věstníku (jakékoli číslo, klidně nejnovější),
3. jeden popis normy, který jsi dával do nabídky nebo do e-shopu (nody.cz).

Zítra z nich uděláme tvoje první tři šablony promptu. Kdo nic nepřinese, dostane cizí materiál — a bude celý den pracovat s úkolem, který ho nezajímá.

Cíl dne

Účastník odchází se třemi otestovanými šablonami promptu pro svou vlastní agendu (uloženými ve sdílené knihovně kurzu) a s promptem „extrakce jedné položky z Věstníku", který u 5 zkušebních odstavců vrátí správně vyplněných 5 polí a u chybějícího údaje napíše NENÍ V PODKLADU místo výmyslu. V Dílně si každý aspoň jednu šablonu ověří na cizím materiálu nebo na vlastním reálném úkolu.

Úvodní cvičení dne (15 min)

Cíl: ověřit na jednom reálném úkolu, jak úplnost zadání (podklad, formát, omezení) mění výstup modelu — srovnání dvou verzí promptu na stejném vstupu.

Test zadání: minimální vs. úplný prompt. Úkol je zadaný: odpovědět zákazníkovi na dotaz, jestli ještě platí norma, na kterou se ptá. Ve dvou kolech:

1. Kolo 1 — minimální zadání (4 min). Napiš záměrně co nejméně určité zadání na tenhle úkol — jen cíl, bez podkladu, formátu a omezení. („Napiš to nějak hezky ať je to hotový." „Vyřeš to." „Odpověz mu profesionálně a rychle.") Spusť ho a přečti, co přišlo — obvykle tři odstavce obecného textu bez jediné použitelné informace.
2. Kolo 2 — úplné zadání (6 min). Ten samý úkol napiš znovu tak, aby výsledek šel poslat. Porovnejte oba výstupy vedle sebe na sdílené obrazovce. Skupina hlasuje, který výstup z kola 1 nejlépe ukazuje, co model dělá bez podkladu — první kandidát na Nález dne.

Pointa: Rozdíl mezi oběma výstupy nedělal model — dělalo ho zadání. V dotazníku jeden z vás napsal, že AI musí často opravovat a že to je nejspíš na něm, jak jí to zadá. Je to pravda a je to dobrá zpráva: opravovat model neumíme, zadání ano. Dnešek je přesně o téhle páce.

Témata (osnova)

Blok 1 — Šest stavebních kamenů zadání

• Role — kým má model být (technický pracovník normalizační firmy ≠ obecný asistent). Co role reálně změní a co ne.
• Kontext — komu píšeme, co už zákazník ví, jaká je situace. Nejčastěji opomíjený kámen.
• Úkol — jedno sloveso, jeden jasný výstup. Proč „zpracuj to" není úkol.
• Formát — tabulka / e-mail / odrážky / JSON; pevné názvy polí. Formát je to, co se dá kontrolovat.
• Omezení — čeho se model nesmí dotknout. Pro nás nejdůležitější věta v celém kurzu: „Vycházej výhradně z přiloženého podkladu. Pokud údaj v podkladu není, napiš NENÍ V PODKLADU. Nic nedoplňuj."
• Tón — věcný / vstřícný / stručný; a proč se tón ladí až nakonec, ne první.
• Kdy který kámen vynechat: krátký interní dotaz nepotřebuje šest odstavců. Chytře, ne přeplácaně.

Blok 2 — Řemeslo: podklad, ukázky, iterace, rozklad

• Podklad místo paměti. Včerejší lekce prakticky: nepokládej otázku po paměti modelu, přilož text. Kopíruj odstavec Věstníku do promptu, ne odkaz na něj.
• Few-shot — dva až tři páry „vstup → výstup" v promptu. Ukážou formát a styl přesněji, než se dá popsat slovy. (A ne, model se tím nepřeučí — platí to jen pro tenhle jeden dotaz.)
• Iterace jako metoda, ne jako zoufalství. Neopravuj výstup ručně — oprav zadání a pusť ho znovu na stejném vzorku. Jak si vést verze promptu (v1, v2, co se změnilo, co to udělalo).
• Rozklad úkolu. „Vytáhni 70 norem, setřiď je podle oboru a napiš ke každé větu pro zákazníka" = tři úlohy. Každý krok se dá zkontrolovat zvlášť a chyba se nešíří dál.
• Negativní zadání funguje hůř než pozitivní. Místo „nepiš dlouze" → „max. 5 vět". Místo „nevymýšlej si" → „u chybějícího údaje napiš NENÍ V PODKLADU".
• Ověřování jako součást promptu: „u každého údaje uveď, ze které věty podkladu pochází".
• Šablona jako firemní aktivum: ověřené zadání s prázdnými místy […], které použije celý tým a dostane srovnatelnou kvalitu. Knihovna promptů kurzu ve sdíleném Drive.

Blok 3 — Věstník: extrakce jedné položky

• Anatomie položky Věstníku: třídicí znak · označení normy · název · typ změny (vydaná / změněná / zrušená) · datum. Co v odstavci bývá a co ne.
• Stavíme prompt v1 → měříme na 5 odstavcích → v2 → měříme znovu. Živě, na sdílené obrazovce, s chybami.
• Proč tabulka a pevné názvy sloupců: co má stejný tvar, to jde zkontrolovat i naimportovat — cíl importu je EviNor (PHP/MySQL), sloupce tabulky odpovídají polím záznamu.
• Kam se to celé žene: dnes jedna položka, v dnu 7 celé číslo Věstníku, v dnu 11 to spustí agent sám.

Blok 4 — Dílna: šablony na vlastní agendě

• Slepý test šablony: cizí šablona na vlastním materiálu ukáže, jestli je šablona firemní aktivum, nebo osobní poznámka.
• Čtvrtá šablona z vlastní agendy (typový dotaz z e-shopu na platformě nody.cz, upomínka z účetního systému, chybová hláška z EviNoru nebo Kovy).
• Cesta B: strukturovaný výstup — JSON schema a nízká teplota místo omezení ve volném textu.

Harmonogram

Cvičení

Cvičení 1 — Tři šablony promptu pro tvou agendu (blok 2)

Pracuješ se svými třemi materiály ze včerejšího mini-úkolu. Kdo je nepřinesl, dostane náhradní sadu z Drive kurzu (ale je to horší, protože ho ten úkol nezajímá).

Varianta A — jen prohlížeč (všichni) Postav tři šablony. U každé projdi cyklus napiš → spusť → oprav zadání → spusť znovu (minimálně jedna iterace, jinak to nebyla šablona, ale pokus):

1. Šablona „Platí ještě …?" — odpověď zákazníkovi na dotaz o platnosti normy. Vstup: dotaz zákazníka (anonymizovaný) + podklad, ze kterého se čerpá (výřez z evidence / Věstníku). Povinné omezení: Vycházej výhradně z přiloženého podkladu. Co v podkladu není, napiš jako NENÍ V PODKLADU a upozorni, že to je potřeba dohledat. Výstup: e-mail, max. 8 vět, věcný a vstřícný tón, bez slibů o platnosti, které v podkladu nejsou.
2. Šablona „Převyprávěj odstavec Věstníku" — z úřední formulace srozumitelná věta pro zákazníka. Výstup: 1 věta co se stalo + 1 věta koho se to týká + 1 věta co s tím. Žádná čísla navíc.
3. Šablona pro tvou vlastní třetí věc — vyber si podle své agendy: popis normy do nabídky (obchod) · odpověď na opakovaný typový dotaz z e-shopu na platformě nody.cz (technická podpora) · shrnutí změn pro zákazníka s trvalou objednávkou · podklad k fakturaci / upomínce z vlastního účetního systému · vysvětlení chybové hlášky vlastními slovy (programátoři — hláška z EviNoru v PHP nebo z Kovy / EviZak ve VB).

Každou hotovou šablonu vlož do sdíleného dokumentu „Knihovna promptů — Normservis" ve tvaru: `` NÁZEV: … KDY POUŽÍT: … PROMPT: (role / kontext / úkol / formát / omezení / tón, prázdná místa v hranatých závorkách) OVĚŘENO NA: … (kolik případů, co nesedělo) ``

Hotový výstup: tři použitelné šablony v knihovně, každá s poznámkou, co se při iteraci zlepšilo. Zítra se z knihovny stane základ vlastního Gemu.

Varianta B — terminál / IDE (programátoři, ředitel)

• Totéž, ale šablonu ulož jako soubor v cvičném repozitáři (prompty/nazev.md) a verzuj ji v Gitu — commit „v1", commit „v2" s popisem, co se změnilo. Prompt je zdrojový kód, chová se k němu tak.
• Pusť šablonu přes API (AI Studio → „Get code", Python nebo PHP 8) nad 10 vstupy najednou a výstupy ulož do souboru. Bezplatná kvóta AI Studia na to stačí — běhy netoč zbytečně.
• Přepiš omezení do parametrů: nízká teplota, pevný formát odpovědi (JSON schema / strukturovaný výstup) a porovnej, o kolik míň si model dogeneruje než ve volném textu.

Cvičení 2 — Extrakce jedné položky z Věstníku (blok 3)

Cíl: z jednoho odstavce Věstníku dostat přesně pět polí — třídicí znak · označení normy · název · typ změny · datum — a nic jiného.

Varianta A — jen prohlížeč (všichni)

1. Otevři PDF Věstníku ze sdíleného Drive, vyber si 5 odstavců (aspoň jeden vydaná, jeden změněná, jeden zrušená norma).
2. Napiš prompt v1: role + úkol + formát tabulky s pevnými sloupci + omezení nic nedoplňuj, chybějící údaj = NENÍ V PODKLADU.
3. Spusť na všech 5 odstavcích. Do sdílené tabulky, list „Extrakce v1", zapiš u každého: sedí všech 5 polí / kolik jich nesedí / co konkrétně bylo špatně.
4. Neopravuj výstup — oprav prompt. Napiš v2 (typicky: doplnit few-shot ukázku, upřesnit, co je „typ změny", zakázat překlad názvu, zakázat zkracování). Spusť na stejných 5 odstavcích.
5. Porovnej v1 vs. v2 v tabulce. Nakonec ověř každé pole proti PDF očima. Co model uvedl a v odstavci to není, je nález — zapiš ho.

Hotový výstup: prompt v2 v knihovně + tabulka měření v1/v2 s vlastními nálezy. Tenhle prompt se v dnu 7 pustí na celé číslo Věstníku a jeho výstup půjde importovat do EviNoru (PHP/MySQL) — dnes ho stavíme tak, aby to vydržel.

Varianta B — terminál / IDE

• Extrakce nad 20 odstavci dávkově, výstup do CSV/JSON — sloupce pojmenuj tak, jak se jmenují pole záznamu v EviNoru (MySQL), ať import nepotřebuje překladovou vrstvu.
• Napiš jednoduchý kontrolní skript: každé vrácené označení normy musí být doslova nalezeno v původním textu odstavce (strpos v PHP / in v Pythonu / InStr ve VB.NET). Co tam není, se vypíše jako podezření na výmysl. Tohle je zárodek protokolu kontroly z dne 7.
• Ulož vzorek 20 odstavců + očekávané výstupy do repozitáře jako testovací sadu. V dnu 10 na ní budeme testovat, co se stane, když se změní formát PDF.

Dílna (blok 4) — Šablony promptu na vlastní agendě

Šedesát minut na to, aby šablona z knihovny prošla něčím jiným než tvýma rukama. Lektor obchází a pomáhá 1:1.

• Slepý test šablony (dvojice, 15 min). Vyměň si šablonu s kolegou a pusť jeho šablonu na svém materiálu. Zapiš do knihovny do sloupce KDY POUŽÍT, co v cizí šabloně chybělo, abys ji použil bez vysvětlování. Šablona, která nepřežije cizí ruce, je osobní poznámka, ne firemní aktivum.
• Čtvrtá šablona z vlastní agendy (25 min). Vyber jeden reálný opakovaný úkol, který jsi dnes ještě neřešil: typový dotaz z e-shopu na platformě nody.cz, upomínka nebo podklad z vlastního účetního systému, shrnutí změny normy pro zákazníka s trvalou objednávkou, chybová hláška z EviNoru (PHP/MySQL) nebo z Kovy / EviZak (VB, MS SQL). Postav šablonu stejným cyklem napiš → spusť → oprav zadání → spusť znovu. Kdo v bloku 2 nestihl třetí šablonu, dodělává nejdřív ji.
• Cesta B — strukturovaný výstup (programátoři, ředitel). Přepiš omezení z volného textu do parametrů modelu: JSON schema pro pět polí Věstníku + nízká teplota. Pusť v1 (volný text) i v2 (schema) nad stejnými 10 odstavci a změř, o kolik míň si model dogeneruje. Výsledek je přímý vstup do dne 7 a do kontrolního skriptu.
• Kontrola „ukaž mi to" (10 min). Každý ukáže jednu šablonu, která prošla cizíma rukama nebo vlastním reálným úkolem, a řekne číslo ze sloupce OVĚŘENO NA. Nakonec do chatu jednu větu: kterou šablonu nasadíš zítra ráno naostro a co tě na tom brzdí — první řádek tvého plánu na 90 dní (den 12).

Hotový výstup: aspoň jedna šablona v knihovně ověřená na cizím materiálu (se zápisem, co chybělo), čtvrtá šablona z vlastní agendy (nebo dokončená třetí), u cesty B změřený rozdíl v dogenerování mezi volným textem a JSON schematem.

Technické předpoklady dne

• Nutné: prohlížeč, Google Meet, přístup k modelu — gemini.google.com (Gemini, zdarma s Google účtem) nebo aistudio.google.com (AI Studio). Den 2 je na obou plnohodnotný včetně obou cvičení; vše běží na bezplatné vrstvě, bez licencí navíc. Když se vyčerpá kvóta, přepni na AI Studio nebo druhý účet. Bezplatný ChatGPT jen jako druhý názor na stejné zadání.
• Sdílený Drive kurzu: dokument „Knihovna promptů — Normservis", tabulka dne (listy „Extrakce v1" a „Extrakce v2"), složka vestnik/ s PDF ke stažení (2–3 čísla).
• Vlastní materiál z mini-úkolu dne 1: anonymizovaný dotaz zákazníka, odstavec Věstníku, popis normy. Náhradní sada je v Drive, ale vlastní materiál je smyslem dne.
• Druhý monitor: vlevo sdílená obrazovka lektora se stavbou promptu, vpravo tvůj vlastní pokus. Dnes to využijeme naplno — stavíme společně a každý paralelně na svém.
• Varianta B: terminál, Git, cvičný repozitář (složka prompty/), API klíč z AI Studia (bezplatná kvóta), Python nebo PHP 8. Klíč patří do proměnné prostředí, ne do kódu a ne do commitu — ověříme si to hned na začátku bloku 2.
• Připomínka z dne 1: do zadání nesmí osobní údaje, data klientů ani informace o firmě. Věstník je veřejný — ten smí. Dotaz zákazníka až po anonymizaci.

Mini-úkol na příště

1. Použij dnešní šablonu naostro. Vyber ve své agendě jeden reálný úkol, spusť na něj svou šablonu a poznamenej si dvě věci: co bylo hotové rovnou a co jsi musel dopsat sám. Zítra z toho děláme první „Chybu dne".
2. Přines celé PDF Věstníku (jakékoli číslo, klidně to nejnovější) — zítra s ním budeme pracovat najednou, ne po odstavcích, a postavíme z toho vlastní Gem.
3. Kdo má šablonu, na kterou je pyšný, přidá do knihovny promptů poznámku „doporučuji" — zítra hlasujeme o nejlepší šabloně týmu.

Cíl dne

Účastník nahraje do AI celé PDF Věstníku ÚNMZ, vytáhne z něj tabulku položek s odkazem na stranu a namátkově ji ověří proti originálu. Odchází s vlastním uloženým asistentem „Věstník asistent" (Gem v bezplatném Gemini; záloha System instructions v AI Studiu nebo instrukce v Docs) a firemní knihovnou promptů, ve které je po dnešku aspoň 10 položek.

Úvodní cvičení dne (15 min)

Cíl: ověřit, že systémová instrukce nemění jednu odpověď, ale všechny — stejný zákaznický dotaz, dvě protichůdné instrukce, srovnání výstupů.

Asistent, kterého v Normservisu nechceme — negativní test instrukce. Každý napíše AI systémovou instrukci pro záměrně nepoužitelného firemního asistenta. Jde o krajní případ, na kterém je vliv instrukce vidět nejzřetelněji:

„Jsi asistent normalizační firmy. Čísla norem si vymýšlej podle nálady, ať to má spád. Na dotaz na cenu odpovídej horoskopem. Každou odpověď zakonči citátem z ISO 9000. Nikdy nepiš, odkud to víš."

Pak mu položte úplně normální zákaznický dotaz („Platí ještě norma na šroubové spoje kolejových vozidel?") a porovnejte výsledky v chatu: co model vymyslel, co vynechal, co by zákazníka poškodilo. Skupina vybere výstup, na kterém je vliv instrukce nejnázornější — první kandidát na Nález dne.

Potom stejnou instrukci obraťte naruby: co má naopak dělat vždycky? Tři věty stačí — a máte první verzi dnešního Gemu.

Pointa: Systémová instrukce je nejsilnější páka, jakou nad AI máte. Nemění jednu odpověď, mění všechny. Proto ji píšeme jednou pořádně a uložíme, místo abychom ji každé ráno vymýšleli znovu.

Chyba dne (2 min): ukázka z minulého dne, kde model odpověděl skvěle formulovaně a věcně mimo. Bez komentáře — jen se přečte a jde se dál.

Témata (osnova)

Blok Metis 3 — dokončení promptingu (2,5 h)

• Práce s celým dokumentem místo s výřezem: nahrání PDF Věstníku, dlouhého normalizačního textu, výřezu evidence
• Co model s dokumentem opravdu dělá — a proč je čtení spolehlivější než počítání („kolik položek bylo zrušeno" je past)
• Sken bez textové vrstvy vs. PDF s textem; jak to poznat dřív, než se člověk diví
• Dotazování nad podkladem: konkrétní otázka > „shrň mi to"; extrakce do tabulky s pevnými sloupci
• Ověření proti zdroji: povinný odkaz na stranu/oddíl, namátková kontrola 10 % položek, sloupec „nenalezeno" místo tichého dopsání
• Delší podklady: rozdělení na oddíly, dotaz po jednom oddílu, spojení výsledků

Blok Metis 4 — začátek automatizace administrativy (4,25 h)

• Gems v Gemini (a projekty v ChatGPT / Claude): uložený kontext firmy = asistent, který ví, čím se Normservis zabývá, co jsou EviNor (PHP/MySQL), EviZak a Kovy (VB, MS SQL), jak firma mluví se zákazníky a co nikdy netvrdí bez ověření
• Anatomie Gemu: role · co ví o firmě · zdroj pravdy · co nikdy nedělá · formát odpovědi · tón
• Záloha bez Gems: Gems jsou v bezplatném Gemini; když firemní účet nebo kvóta bezplatné vrstvy nepustí, Google AI Studio se system instruction, nebo uložený prompt v Docs — stejný efekt, o jedno kopírování navíc
• Sdílená knihovna promptů týmu: jednoduchý Sheet na Drive kurzu, kdo ji vlastní, jak se do ní přispívá a proč umírají složité knihovny
• Systémová instrukce vs. uživatelský prompt — kde je hranice a proč na ní stojí veškerá automatizace
• Šablona jako parametr: pevný text zvlášť, proměnné zvlášť ({označení normy}, {třídicí znak}, {obor zákazníka}) — most k dnešnímu D4 a k importu do EviNoru v D9
• Dílna: druhý asistent pro vlastní agendu (nabídky, typové odpovědi) a dávka Věstníků do CSV pro programátory

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

A1 · Věstník jako podklad (blok 2). Ze složky kurzu na Drive si každý stáhne jedno číslo Věstníku ÚNMZ (PDF) a nahraje ho do Gemini (gemini.google.com, zdarma s Google účtem) nebo do Google AI Studia (aistudio.google.com). Pak položí pět dotazů — na každý chce odpověď s odkazem na stranu nebo oddíl:

1. Které normy z oddílu „vydané" se týkají elektrických zařízení?
2. Vypiš do tabulky: třídicí znak · označení · název · typ změny · datum. Pět položek z oddílu „změněné".
3. U kterých z nich není v PDF uvedeno datum účinnosti? (test na to, jestli model přizná, že něco nenašel)
4. Je v tomto čísle něco, co se týká oboru „šroubové spoje"?
5. Co v tomto čísle není — na co se zákazník může ptát a Věstník na to neodpovídá?

Hotový výstup: tabulka pěti položek + u každé strana + sloupec „ověřeno ano/ne". Tři položky si každý ověří ručně v PDF. Kdo najde první nesrovnalost, hlásí nahlas — společný protokol nesrovnalostí.

A2 · Gem „Věstník asistent" (blok 3). Gem zakládá každý v bezplatném Gemini (gemini.google.com → Gems → nový Gem, pole Instrukce). Záloha, když firemní účet Gems nepustí nebo dojde kvóta bezplatné vrstvy: stejný text do pole System instructions v Google AI Studiu, nebo dokument „Věstník asistent — instrukce" na Drive a kopírování na začátek konverzace. Výsledek je stejný.

Kostra, kterou si každý upraví podle své agendy:

``` ROLE Jsi asistent pracovníka firmy NORMSERVIS s.r.o. Firma od roku 1990 dodává a aktualizuje technické normy (ČSN, TPG, TDG, TIN, TNI, TD, PNE i zahraniční — DIN, ISO, IEC, ASME, ASTM, BS, SAE, GOST, ETSI, GB, UNE, STN), vede zákazníkům trvalé objednávky norem, tiskne normy a provozuje vlastní software EviNor (evidence norem), EviZak (legislativa) a Kovy (materiály a jejich konverze).

ZDROJ PRAVDY Odpovídáš výhradně z podkladů, které ti vložím (PDF Věstníku ÚNMZ, výřez evidence norem). Co v nich není, nevíš — a řekneš to.

CO NIKDY NEDĚLÁŠ

• Neuvádíš označení normy, třídicí znak ani datum, které nemáš v podkladu.
• Netvrdíš, že norma platí nebo neplatí, pokud to v podkladu není doslova.
• Neuvádíš ceny, termíny ani formáty dodání — ty doplňuje člověk z ceníku firmy.
• Nepřidáváš marketingové věty.

FORMÁT ODPOVĚDI 1) Odpověď — nejvýše 5 vět. 2) Zdroj — název souboru + strana nebo oddíl. 3) Nenalezeno — které z požadovaných údajů v podkladu nejsou.

TÓN Věcný, česky, krátké věty. Bez oslovení „vážený zákazníku", to doplní člověk. ```

Test hned: tři dotazy, z toho jeden schválně na údaj, který v nahraném Věstníku není. Asistent musí říct „nenalezeno". Když si vymyslí, instrukce se doostří — a to je ta práce.

Hotový výstup: funkční asistent, který na testovací trojici dotazů odpověděl s odkazem na zdroj.

A3 · Knihovna promptů firmy (blok 3, posledních 25 min). Na Drive kurzu je Sheet „Knihovna promptů — Normservis" s hlavičkou:

Každý do ní vloží aspoň jeden prompt ze své dnešní práce (extrakce z Věstníku, dotaz nad evidencí, instrukce asistenta). Deset lidí = deset položek — knihovna je po dnešku živá, ne prázdná.

Pravidla, která si u toho řekneme:

• Prompt bez sloupce „co doplnit" nikdo cizí nepoužije.
• Sloupec „kde to zlobí" je nejcennější — tam se píše, co model dělá špatně, ne co dělá dobře.
• Knihovna má jednoho vlastníka. Bez něj se za tři měsíce rozpadne (vracíme se k tomu v M12).

Varianta B — terminál / IDE (programátoři)

B1 · Systémová instrukce v kódu. V Google AI Studiu doladit instrukci asistenta, pak Get code → přenést do skriptu (PHP 8 nebo Python — ve firmě to míří do EviNoru, tak primárně PHP). API klíč vzniká v AI Studiu zdarma, bezplatná kvóta na cvičení stačí. Systémová instrukce jako konstanta, uživatelský prompt jako šablona s parametry:

`` $prompt = str_replace( ['{oddil}', '{pocet}'], [$oddil, $pocet], file_get_contents('prompty/extrakce-vestnik.txt') ); ``

B2 · Dávka místo jednoho PDF. Skript projde tři čísla Věstníku ze složky, u každého vyžádá tabulku ve stejné struktuře a uloží CSV vestnik-YYMM.csv. Kontrolní otázka na konec: sedí počty položek napříč čísly? Pokud v jednom měsíci vyjde 6 zrušených položek místo ~180, není to zázrak, je to chyba čtení.

B3 · Do Gitu. Prompty jako soubory v repozitáři (prompty/*.txt), ne v těle skriptu. Změna promptu = commit s poznámkou, co se tím zlepšilo. Tohle je zárodek toho, co v D9–D11 poroste do importu Věstníku do EviNoru (PHP + MySQL) a agenta.

Dílna (blok 4) — uložený asistent a knihovna promptů na vlastní agendě

• Cesta A · Druhý asistent pro vlastní agendu. Vezmi materiál, který sis přinesl (e-mail s dotazem, poptávku, typovou odpověď), a postav nad ním druhého asistenta stejnou kostrou jako v A2: obchod „asistent nabídek", technický pracovník „asistent typových odpovědí". Otestuj ho třemi dotazy, z toho jedním na údaj, který v podkladu není. Hotový výstup: druhý asistent, který na testovací trojici odpověděl s odkazem na zdroj.
• Cesta B · B2 naostro. Tři čísla Věstníku do CSV ve stejné struktuře + kontrola počtů napříč čísly. Když v jednom měsíci vyjde 6 zrušených položek místo ~180, je to chyba čtení, ne zázrak. Hotový výstup: tři CSV vestnik-YYMM.csv a jednořádkový zápis, jestli počty sedí — vstup pro den 5 a den 7.
• Všichni · Šestý dotaz nad Věstníkem: „Co v tomto čísle není a zákazník se na to bude ptát?" Odpovědi jdou do společného seznamu typových dotazů — materiál pro den 4. Hotový výstup: seznam typových dotazů v Docu na Drive kurzu.
• Všichni · Zápis do knihovny. Každý prompt z Dílny přidej do Sheetu „Knihovna promptů — Normservis" včetně sloupců „co doplnit" a „kde to zlobí". Hotový výstup: knihovna s aspoň 15 položkami na konci dne.

Technické předpoklady dne

• Firma nemá placené AI licence — a dnes to nevadí. Gems jsou součástí bezplatného Gemini (gemini.google.com, Google účet), záloha je Google AI Studio (aistudio.google.com, zdarma, má pole System instructions i nahrání PDF). Limity bezplatné vrstvy (velikost PDF, počet dotazů za den) ověříme v tech-checku; při vyčerpání kvóty se přepne na AI Studio nebo druhý účet. Lektor to říká rovnou na začátku bloku 1, ne až když někdo nenajde tlačítko.
• Záložní varianta pro každého: instrukce uložená jako dokument na Drive + kopírování na začátek konverzace. Nudné, ale funguje odkudkoli.
• Věstníky předem na Drive kurzu — lektor stáhne 20–30 čísel z normservis.cz/download/vestnik/ (veřejná data, žádné osobní údaje → smějí do cloudové AI bez porušení firemního pravidla z D1).
• Sheet „Knihovna promptů — Normservis" založen a nasdílen před začátkem dne.
• Ověřit v tech-checku: nahrávání PDF do Gemini na firemním účtu, založení Gemu, přístup na aistudio.google.com, práva zápisu do sdíleného Sheetu.
• Nic víc se dnes neinstaluje. Varianta B potřebuje jen to, co programátoři mají (PHP 8 / Python, Git) + bezplatný API klíč z AI Studia.

Mini-úkol na příště

Přines dva reálné kusy své zákaznické agendy — e-mail s dotazem, poptávku, reklamaci nebo rozdělaný text nabídky. Bez jména, IČO a kontaktu zákazníka; stačí, aby zůstal dotaz a kontext. Zítra na nich pracujeme naostro a odejdeš s odbavenou agendou, ne s cvičným příkladem.

Kdo přinese dotaz, kde by odpověď od AI mohla zákazníka poškodit, má u zítřejšího ověřovacího cvičení nejcennější materiál.

Cíl dne

Účastník zpracuje s AI vlastní reálnou zákaznickou agendu, kterou si přinesl, a odchází se třemi hotovými šablonami v knihovně firmy (dotaz na platnost normy · upozornění k trvalé objednávce · reakce na reklamaci). Zároveň v připravené sadě odpovědí odhalí ty, kde si AI sebejistě vymyslela fakta — a ověří je proti Věstníku a evidenci v EviNoru.

Úvodní cvičení dne (15 min)

Cíl: ověřit, že instrukce o stylu v zadání mění pouze formu výstupu, ne fakta — a nastavovat ji jako parametr zadání, ne ji nechávat na modelu.

Tři varianty jedné zprávy. Zadání pro AI: zákazník má v trvalé objednávce normu, která byla nahrazena novým vydáním. Musí ji koupit znovu a stojí to peníze. Nechte tutéž zprávu vygenerovat třikrát a měňte jen instrukci o stylu:

1. Úřední styl podatelny — „Sděluji Vám tímto, že v návaznosti na výše uvedené…"
2. Styl sportovního komentátora — „A je to tady! Stará norma odchází ze hřiště, náhrada nastupuje!"
3. Styl laskavé babičky — „Broučku, ta tvoje norma už doslouží, ale neboj…"

Srovnání: tři účastníci přečtou po jedné verzi, skupina vybere tu, ze které zákazník nejrychleji pochopí, co má udělat. Pak kontrola podstatného: první verze je přesně ten typ textu, který dnes zákazníkům chodí nejčastěji — a nejhůř se v něm hledá další krok.

Pointa: Fakta zůstala ve všech třech výstupech stejná, změnil se jen parametr stylu v zadání. Ten parametr nastavuje autor zadání, ne model. „Úřední" není totéž co „přesné a srozumitelné" — a zákazník ten rozdíl pozná.

Chyba dne (2 min): odpověď z včerejška, kde asistent vytvořil údaj, který v podkladu nebyl. Jen se přečte. Dnešek na ni celý navazuje.

Témata (osnova)

Blok Metis 4 — dokončení automatizace administrativy (3,75 h)

• Typová agenda normalizační firmy a co v ní AI umí:
  • „Platí ještě norma X?" · „Čím ji nahradit?" · „Co pro nás znamená nové vydání?"
  • „Kolik stojí a v jakém formátu ji dodáte?" · reklamace · upomínka k trvalé objednávce · nabídka na aktualizaci sady norem
• Automatizace zpracování dotazu jako postup: klasifikace dotazu (platnost · náhrada · cena a formát · reklamace) → extrakce parametrů (označení, třídicí znak, obor) → ověření v EviNoru (PHP/MySQL) a ve Věstníku → dosazení do šablony → kontrola člověkem před odesláním
• Gemini v Gmailu („Pomoz mi napsat") — jen ukázka lektora (placená vrstva Workspace, firma ji nemá). Cvičení se dělá v Gemini (gemini.google.com, zdarma s Google účtem) nebo v AI Studiu a text se vkládá do Gmailu. Co všechno má asistent v poště v okně před sebou — kde končí pohodlí a začíná riziko
• Jedna informace, dvě verze výstupu: technik chce označení, třídicí znak a co se změnilo; nákupčí chce cenu, formát dodání a termín. Stejná fakta, jiné pořadí a důraz — řízené zadáním
• Few-shot z vlastní pošty: dva reálné odeslané e-maily jako vzor stylu v zadání; krátké věty, konkrétní další krok, žádné „v návaznosti na výše uvedené"
• Šablona s parametry (navazuje na D3): pevný text zvlášť, {označení normy}, {třídicí znak}, {obor}, {co se změnilo} zvlášť
• Co do promptu nepatří: jméno zákazníka, IČO, kontakt, historie objednávek — firemní pravidlo z D1 platí i uprostřed rozdělané odpovědi

Blok Metis 7 — praktické ukázky z prostředí firmy (3 h)

• Ověření proti zdroji jako povinný krok: u odpovědi o platnosti normy se vždy ověřuje proti Věstníku a evidenci v EviNoru. Nikdy z paměti modelu
• Test halucinace: AI odpovídá sebejistě a špatně — účastník to má odhalit dřív než zákazník
• Z Věstníku k zákazníkovi (D4 ve vestnik-pipeline.md): nová norma → koho se v evidenci týká → text upozornění. Poslední krok před odesláním dělá vždycky člověk
• Kde je hranice AI: reklamace, sleva, příslib termínu, omluva za chybu firmy — návrh smí připravit, rozhodnutí ne

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

A1 · Zpracuj vlastní dotaz (blok 2, 45 min). Každý vezme jeden ze dvou e-mailů, které si přinesl, a zpracuje ho naostro — v Gemini (gemini.google.com, zdarma s Google účtem) nebo v AI Studiu s vloženým textem dotazu; hotový text vloží do Gmailu jako koncept. (Gemini přímo v Gmailu — „Pomoz mi napsat" — je placená vrstva Workspace, kterou firma nemá; lektor ji jen ukáže. Výsledek je stejný, cesta o jeden krok delší.)

Postup, který si projdeme společně na prvním případu:

1. Vyčistit vstup — pryč jméno, IČO, kontakt, číslo objednávky. Zůstává dotaz a obor.
2. Zadat roli a fakta: kdo píše, co je ověřeno a co ne, jaký je další krok.
3. Vyžádat dvě verze: pro technika a pro nákupčího.
4. Zkrátit. První verze bývá o třetinu delší, než má být.
5. Doplnit ručně: cena, formát dodání, termín. Ty z AI nikdy nepřebíráme.

Hotový výstup: odeslatelný text (koncept ve schránce Gmailu) k vlastnímu reálnému dotazu. Ne cvičný — skutečný.

A2 · Tři šablony do knihovny (blok 2, 45 min). Ve dvojicích, každá dvojice jednu šablonu, na konci se sdílí všem do Sheetu z D3:

• Š1 — Dotaz na platnost normy. Struktura: co jsme ověřili · v čem (Věstník č. …, evidence v EviNoru) · co z toho plyne · co doporučujeme · co potřebujeme od zákazníka. Parametry: {označení}, {třídicí znak}, {stav}, {náhrada}, {zdroj ověření}.
• Š2 — Upozornění k trvalé objednávce. Vyšlo nové vydání normy z oboru, který zákazník sleduje. Parametry: {obor}, {označení}, {co se změnilo}, {dopad na dokumentaci zákazníka}. Povinná věta: co se stane, když nic neudělá.
• Š3 — Reakce na reklamaci. Zákazník tvrdí, že dostal neplatné znění. Parametry: {co reklamuje}, {co jsme zjistili}, {řešení}, {do kdy}. Pravidlo v šabloně natvrdo: AI nepíše omluvu ani nepřislibuje kompenzaci — ta místa jsou v šabloně prázdná a doplňuje je člověk.

Každá šablona se hned otestuje na jednom reálném případu ze skupiny. Šablona, která neprošla testem, jde do knihovny se sloupcem „kde to zlobí" vyplněným — to je pořád užitečný záznam.

A3 · Najdi, kde si vymýšlí (blok 3, 45 min). Lektor rozdá čtyři odpovědi vygenerované AI na dotazy typu „platí ještě norma X, čím ji nahradit". Nejméně dvě obsahují sebejistou chybu — vymyšlené datum, zaměněný třídicí znak, náhrada normou, která v podkladu není, nebo tvrzení o platnosti, které Věstník neobsahuje. Všechny čtyři znějí stejně přesvědčivě.

Úkol: u každé odpovědi napsat ověřeno / neověřeno / chybně a doplnit, čím se to zjistilo (číslo Věstníku, strana, záznam v evidenci EviNor). Kdo najde chybu první, vysvětlí ostatním, co ho zarazilo.

Uzavření cvičení jednou větou lektora: „Takhle to bude vypadat i v ostrém provozu. Rozdíl je jen v tom, že tam ta odpověď půjde zákazníkovi."

A4 · Z Věstníku k zákazníkovi (blok 3, 45 min). Ze včerejší tabulky vezmi jednu novou normu (např. z čísla 7–8/2026 položku typu ČSN EN IEC 62841-2-18 — bezpečnost ručního páskovacího nářadí nebo ČSN EN 17976 — šroubové spoje na kolejových vozidlech). Pak:

1. Ve výřezu evidence (struktura EviNoru) najdi, který obor trvalých objednávek se jí týká.
2. Šablonou Š2 vygeneruj upozornění.
3. Ověř v PDF, že označení, třídicí znak i typ změny sedí — teprve pak je text hotový.
4. Text ulož do složky „ke schválení", neodesílej.

Hotový výstup: jeden konkrétní text připravený k odeslání, u kterého je dohledatelné, odkud každý údaj pochází. Tohle je řádek D4 z materialy/vestnik-pipeline.md — od dneška existuje.

Varianta B — terminál / IDE (programátoři)

B1 · Šablonování odpovědí ve vlastním systému. Šablony Š1–Š3 přenést z dokumentu do kódu: text šablony jako soubor (sablony/platnost-normy.txt), parametry jako pole, dosazení funkcí v PHP 8 (EviNor a e-shop na platformě nody.cz — PHP/MySQL) nebo ve VB.NET (Kovy / EviZak nad MS SQL) podle toho, kam to má později patřit. Cíl: šablona je data, ne řetězec zapečený v kódu — když ji obchod upraví, nikdo nemusí nasazovat novou verzi.

B2 · Dávka místo jednoho e-mailu. Vstup: CSV s vymyšlenými zákazníky (obor · typ objednávky) + tabulka nových norem z D3. Skript spáruje obor s normou a pro každou dvojici vygeneruje text — buď čistě ze šablony, nebo přes Gemini API (bezplatná kvóta z AI Studia) tam, kde je potřeba formulace na míru. V ostrém provozu by párování běželo nad MySQL EviNoru (obory trvalých objednávek × nové normy); dnes stačí CSV.

Výstup nejde do pošty. Jde do složky ke-schvaleni/ jako soubory, které člověk otevře, projde a teprve pak odešle. Do kódu se to napíše natvrdo, včetně komentáře proč:

`` // Poslední krok před odesláním ven dělá vždycky člověk. // U firmy, která ručí za platnost norem, není "skoro správně" použitelný výsledek. ``

B3 · Kontrolní hlášení. Skript na konec vypíše: kolik textů vzniklo · u kolika chyběl některý parametr · které normy se nepodařilo přiřadit žádnému oboru. Nepřiřazené položky jsou signál, ne chyba k zamlčení — tady se poprvé ukazuje logika hlídání, kterou dotáhneme v D10 a D12.

Dílna (blok 4) — zákaznická agenda na vlastních případech (60 min)

Každý pracuje na svém materiálu, lektor obchází a pomáhá 1:1. Vyber podle toho, co ti dnes zbylo:

• Druhý přinesený e-mail (cesta A). Postup z A1 podruhé, tentokrát bez lektora. Hotový výstup: druhý text ve složce „ke schválení" a poznámka, co jsi tentokrát doplnil(a) ručně.
• Š4 — nabídka na aktualizaci sady norem (obchod, technici). Čtvrtá šablona podle vzoru Š1–Š3: parametry {obor}, {počet norem v sadě}, {co je zastaralé}, {co doporučujeme}; cena a termín zůstávají prázdné. Hotový výstup: Š4 v knihovně (Sheet z D3), otestovaná na jednom reálném případu — den končí čtyřmi šablonami místo tří.
• Anglická verze jedné odpovědi (kdo je hotový dřív). Firma provozuje i anglickou větev: tatáž odpověď v angličtině a srovnání, co model v překladu tiše zjednodušil nebo vynechal. Hotový výstup: EN text + seznam rozdílů proti české verzi.
• B2 + B3 naostro (cesta B). Dávkové generování nad CSV a kontrolní hlášení (kolik textů vzniklo, kde chyběl parametr, které normy se nepřiřadily). Hotový výstup: složka ke-schvaleni/ s vygenerovanými soubory + hlášení v konzoli. Nepřiřazené položky jsou předehra k logice hlídání z D10 a D12.

Technické předpoklady dne

• Gemini v Gmailu („Pomoz mi napsat") je placená vrstva Workspace — firma ji nemá. Lektor ji jen ukáže ze svého účtu; všichni pracují v Gemini (gemini.google.com, zdarma s Google účtem) nebo v AI Studiu (aistudio.google.com) a text vkládají do Gmailu. Výsledek je identický, cesta o jeden krok delší — říct to hned v bloku 1. Limity bezplatné vrstvy ověříme v tech-checku; při vyčerpání kvóty přepnout na AI Studio / druhý účet.
• Přinesené vlastní e-maily (mini-úkol z D3) — bez jména, IČO a kontaktu. Kdo nepřinesl, dostane od lektora typový dotaz ze sady 10 anonymizovaných dotazů zákazníků.
• Sada čtyř nastražených odpovědí — připraví lektor předem, správné znění ověřené proti konkrétnímu číslu Věstníku a proti vzorku evidence. Sadu si nechává i pro D12 (katalog chyb).
• Výřez evidence norem (struktura polí z EviNoru — PHP/MySQL — + ~50 vymyšlených řádků) — dodá firma do 30. 9., jinak jede lektorův náhradní vzorek.
• Věstníky na Drive kurzu z D3, Sheet „Knihovna promptů — Normservis" z D3.
• Varianta B: PHP 8 (PDO) nebo Visual Studio (VB.NET), které programátoři už mají; Gemini API klíč z AI Studia (zdarma, bezplatná kvóta; může být lektorův pro ukázku). Nic nového se neinstaluje.

Mini-úkol na příště

Přines jeden úkol, který dnes děláš ručně v tabulce nebo v evidenci — přehled, který každý měsíc skládáš, dotaz, který si vždycky musíš vyklikat, sestavu, kterou kopíruješ mezi soubory. Zítra se v M5 bavíme o datech, SQL a systémech (MySQL v EviNoru a e-shopu, MS SQL v Kovy / EviZak) a začneme přesně u toho, co skutečně děláš.

Kdo dnes nedodělal šablonu, dokončí ji do knihovny — zítra už s ní pracujeme jako s hotovou.

Cíl dne

Účastník položí do dat firmy otázku v češtině, dostane funkční SQL dotaz (MySQL 8 — dialekt EviNoru a e-shopu), zkontroluje ho a spustí nad testovací kopií — a umí totéž s cizím dotazem, chybovou hláškou a logem. Zároveň ví, co z logu nebo výpisu zákazníků nesmí opustit firmu a jak data upravit, aby šla. U tabulek s miliony řádků (katalog EviNoru ~1 000 000 norem) ví, proč se ptá na EXPLAIN, index a LIMIT, než dotaz pustí.

Výstup dne: 10 funkčních dotazů nad testovacími daty (uložených, popsaných, s ověřeným výsledkem) + návrh tabulky pro Věstník včetně párovacího klíče a pole pro dohledatelnost zdroje.

Úvodní cvičení dne (15 min)

Cíl: ověřit, kolik rozhodnutí se skrývá v jedné české větě, než se z ní dá udělat jednoznačný SQL dotaz — a že tato rozhodnutí model nedělá za nás.

Dotaz jako objednávka. Vezmi jednu větu, kterou by firma reálně chtěla umět zjistit z EviNoru:

„Které normy z třídy 36 se letos změnily a kdo z našich zákazníků je má v trvalé objednávce?"

Nech AI stejné zadání přepsat ve třech podobách a porovnej je vedle sebe:

1. jako objednávku číšníkovi („dvakrát třídu 36, ale jen to letošní, a k tomu seznam hostů, co si to předplatili"),
2. jako služební přípis z roku 1985 (s jednacím číslem a razítkem),
3. jako SQL dotaz (MySQL).

Srovnání: kdo najde ve verzi 1 a 2 nejednoznačnost, která by v SQL musela být rozhodnutá („letos" = podle data změny, nebo data účinnosti? „zákazník" = aktivní trvalá objednávka, nebo kdykoli v historii?), napíše ji do chatu.

Pointa: SQL není cizí jazyk, je to jen extrémně přesná objednávka. AI ji přeloží za vteřinu — ale rozhodnout, co si vlastně objednáváme, musí člověk. Nejasnost v zadání se v datech projeví jako tichá, nikoli hlášená chyba.

Chyba dne (2 min): dotaz, který vrátil 0 řádků, a všichni se tři dny domnívali, že se tedy nic nezměnilo.

Témata (osnova)

• Co AI o vašich datech neví. Model nezná schéma EviNoru (PHP/MySQL), e-shopu na platformě nody.cz (PHP/MySQL) ani programů Kovy / EviZak (VB nad MS SQL). Jak mu strukturu předat (názvy tabulek a sloupců, typy, vztahy, 5 ukázkových řádků) — a proč tohle není citlivý údaj, zatímco obsah tabulky často ano.
• Z češtiny do SQL. Stavba zadání: co chci, odkud, za jakých podmínek, jak seřazené, co s prázdnými hodnotami, v jakém dialektu (MySQL 8 pro EviNor a e-shop, MS SQL pro Kovy a EviZak — model je zamění, když mu to neřekneš). Kontrola výsledku: dává počet řádků smysl? Co dotaz nezahrnul?
• Miliony řádků. Katalog EviNoru má ~1 000 000 norem, Kovy 44 000 značek, EviZak 20 000 předpisů. Dotaz, který na 50 testovacích řádcích proběhne okamžitě, může nad produkcí běžet minuty: EXPLAIN, index na sloupcích ve WHERE a JOIN, LIMIT při zkoušení, dávkový import přes LOAD DATA místo tisíců INSERT, transakce kolem hromadných změn. AI tohle navrhne — když se zeptáš.
• Čtení cizího dotazu. Legacy dotaz z Kovy / EviZaku (VB, MS SQL) nebo z PHP části EviNoru či e-shopu: nechat vysvětlit po částech, ověřit vysvětlení proti skutečnému výsledku na testovací kopii.
• Nebezpečné vzory. UPDATE/DELETE bez WHERE, JOIN bez podmínky, NULL v porovnání, skládání dotazu spojováním řetězců v PHP (SQL injection na e-shopu) → PDO s prepared statements (mysqli umí totéž, v kurzu držíme PDO). AI tyhle vzory občas navrhne — proto se čte, než se spouští.
• Vždy nad testovací kopií. Jak poznám, ve které databázi jsem (SELECT DATABASE()). Transakce (START TRANSACTION … ROLLBACK). Nejdřív SELECT stejného rozsahu, teprve pak zápis.
• Chybové hlášky a logy. Co modelu předat (hláška, kontext, vstup, očekávání), jak z hlášky udělat hypotézu a jak hypotézu ověřit. Překlad technické hlášky do lidštiny pro kolegu z obchodu.
• Anonymizace před odesláním. Co v logu je osobní údaj (IP, přihlašovací jméno, e-mail, jméno kontaktní osoby u IČO). Techniky: maskování IP, náhradní ID, zkrácení, vzorek místo celku. Kdy anonymizace nestačí a úloha patří na vlastní Linux server (Ollama) → D8.
• Dokumentace, runbook, změnová zpráva. Z kódu, z commitů, z diffu. Co si firma po kurzu udrží: runbook je jediná dokumentace, kterou někdo čte v 7 ráno, když něco stojí.
• Datový model pro Věstník. Kam v EviNoru ukládat vydané / změněné / zrušené normy, čím je párovat s evidencí, jak zaručit dohledatelnost do zdrojového PDF a jak zaznamenat, že položku schválil člověk. Import bude v D9 psaný v PHP + MySQL. (Kámen do červené nitě — viz materialy/vestnik-pipeline.md, řádek D5.)

Harmonogram

Cvičení

5.1 — Deset dotazů do evidence norem

Pracujeme nad testovací kopií v MySQL 8 se strukturou odvozenou z evidence norem — odpovídá struktuře EviNoru (PHP/MySQL na Linuxu); skutečné názvy polí doplní firma, zákazníci jsou vymyšlení:

`` normy(id, tridici_znak, oznaceni, nazev, datum_vydani, datum_zmeny, stav, nahrazuje_id) zakaznici(id, nazev, ico, segment) trvale_objednavky(id, zakaznik_id, tridici_znak, aktivni_od, aktivni_do) dodavky(id, zakaznik_id, norma_id, datum, forma) ``

V produkci má tabulka normy ~1 000 000 řádků — proto u každého dotazu, který by tam běžel, chceme vědět, jaký index použije (EXPLAIN), a při zkoušení přidáváme LIMIT.

Sada úkolů (stejná pro obě varianty, formulace v češtině — SQL vzniká z ní):

1. Kolik norem evidujeme v každé třídě? Seřaď sestupně.
2. Které normy třídy 36 mají datum změny v roce 2026?
3. Kteří zákazníci mají třídu 36 v aktivní trvalé objednávce?
4. Spoj 2 a 3: komu je potřeba změnu oznámit.
5. Normy zrušené za poslední 3 měsíce, které jsme někomu dodali → koho oslovit s náhradou.
6. Deset tříd s nejvyšším počtem trvalých objednávek.
7. Zákazníci s aktivní trvalou objednávkou, kterým jsme 12 měsíců nic nedodali (nesrovnalost ke kontrole).
8. Položky z Věstníku, které se nepodařilo spárovat s evidencí (LEFT JOIN … IS NULL) → seznam ke kontrole člověkem.
9. Počty položek posledního Věstníku podle typu změny — porovnej s očekávaným řádem (~70 vydaných / ~40 změněných / ~180 zrušených).
10. Duplicity: označení, které je v evidenci víc než jednou.

Varianta A — jen prohlížeč (všichni)

• Otevřeš připravenou testovací databázi v Admineru nad cvičnou MySQL databází lektora (jen pro čtení, bez registrace, odkaz na Drive kurzu). Záloha: db-fiddle.com (MySQL 8, schéma a data vložíš ze souboru na Drive) nebo Colab. SQLite je jen nouzová záloha pro případ výpadku — dialekt se od MySQL liší a v EviNoru ho nikdy nepoužijete.
• AI: Gemini (gemini.google.com, zdarma s Google účtem) nebo AI Studio (aistudio.google.com). Do zadání vždy napiš „MySQL 8".
• Postup u každého dotazu: (1) vlož modelu schéma, (2) polož otázku česky, (3) než spustíš, přečti si dotaz a řekni jednou větou, co dělá, (4) spusť, (5) ověř výsledek — u dotazu 2 a 3 ručně přepočítej pár řádků.
• Kdo raději pracuje v tabulce: stejné otázky nad připraveným plochým listem v Google Sheets funkcí QUERY (spojení tabulek už je předpřipravené, aby se nikdo nezasekl na JOIN).
• Hotový výstup: list „10 dotazů" — u každého: otázka česky · dotaz · počet řádků · jak jsem ověřil, že je správně. Tenhle list si odnášíš a používáš dál v D7 a D11.

Varianta B — terminál / IDE (programátoři)

• Totéž nad lokální testovací kopií: MySQL 8 (EviNor, e-shop na nody.cz) nebo MS SQL (Kovy, EviZak) — podle toho, ke kterému systému máte blíž; dotazy verzované v cvičném repozitáři na GitHubu.
• Navíc: nech AI vysvětlit skutečný legacy dotaz z Kovy / EviZaku (VB, MS SQL) nebo z PHP části EviNoru či e-shopu, pak vysvětlení ověř — spusť původní i „vysvětlený" dotaz a porovnej výsledky. Souhlasí?
• Navíc: vezmi jedno místo v PHP, kde se dotaz skládá spojováním řetězců, a nech AI navrhnout verzi s PDO prepared statement (PHP 8). Posuď návrh — je vždy správně? Ve VB.NET totéž s parametrizovaným SqlCommand.
• Navíc: EXPLAIN u dotazu 5 a 7 nad tabulkou s milionem řádků (lektor dodá skript na naplnění), dotaz na AI „proč je pomalý a jaký index by pomohl", ověření změřením před a po.

5.2 — Log, který nesmí ven

Dostaneš vzorek ~200 řádků přístupového logu (imitace provozu e-shopu na platformě nody.cz — PHP/MySQL na Linuxu; připraví lektor) s chybami 500 na jedné cestě.

1. Projdi log a označ vše, co je osobní údaj — IP adresa, přihlašovací jméno, e-mail, jméno kontaktní osoby.
2. Připrav anonymizovanou verzi: IP zkrácená na síť, jména nahrazená uzivatel_01…, e-maily odstraněné. Zachovej to, co je pro diagnostiku podstatné (čas, cesta, stavový kód, doba odpovědi).
3. Teprve teď dej log AI a zeptej se, co způsobilo chyby 500. Ověř odpověď proti logu — sedí časy a cesty?
4. Napiš 5 řádků: „Co z logu smí ven a v jaké podobě" — návrh pravidla pro firmu (naváže na interní pravidlo z D1/M2).

Varianta A: anonymizace ručně přes hledání a nahrazování v Sheets/editoru — na 200 řádcích to jde a člověk přitom uvidí, co v logu vlastně je. Varianta B: krátký skript (Python nebo PHP 8), který anonymizaci provede opakovatelně před každým odesláním; zvaž, které úlohy se anonymizovat nedají a patří na lokální model na vašem Linux serveru (rozhodnutí padne v D8).

5.3 — Tabulka pro Věstník

Návrh, který v D7 naplníme daty a v D9 do něj napíšeme import (PHP + MySQL do EviNoru).

• Jaká pole potřebujeme u každé položky: třídicí znak · označení · název · typ změny (vydaná/změněná/zrušená/oprava) · datum · číslo Věstníku · strana v PDF · stav zpracování · kdo schválil.
• Čím párovat s evidencí: označení + třídicí znak (a rok u vydání). Proč ne názvem — název se mezi vydáními mění a diakritika i zkratky se liší.
• Co dělat s položkou, která se nespáruje: nesmí zmizet, jde do fronty ke kontrole (viz dotaz 8 z cvičení 5.1).
• Proč tam patří strana zdrojového PDF: bez ní se údaj o platnosti normy nedá zpětně ověřit, a to je u vaší firmy ta nejdražší chyba.
• Proč tam patří kdo schválil: poslední krok před odesláním ven dělá vždy člověk — a musí být vidět kdo.
• Tabulka poroste každý měsíc a páruje se proti milionu norem: index na párovací sloupce, import v transakci, dávkově (LOAD DATA nebo jeden INSERT s více řádky), nikdy tisíc samostatných INSERT v cyklu.

Varianta A: tabulka v Sheets — sloupce název pole · typ · příklad hodnoty · odkud se bere · kdo kontroluje. To je plnohodnotný datový model, jen zapsaný lidsky. Varianta B: CREATE TABLE pro MySQL 8 (InnoDB) včetně klíčů, indexů a unikátní podmínky proti dvojímu naimportování téhož čísla Věstníku; k tomu migrace a poznámka, jak by se to vešlo do stávající struktury EviNoru.

Dílna (blok 4) — SQL a data na vlastní agendě

Hodinová samostatná práce na tom, co si přinášíš ze své práce; lektor obchází a pomáhá 1:1.

• Cesta A — dotazy 11–13 na míru: napiš tři otázky ze své agendy (z mini-úkolu D4: co bys chtěl z EviNoru nebo e-shopu umět zjistit), nech si k nim vygenerovat SQL, spusť nad testovací kopií a doplň do listu „10 dotazů" jako řádky 11–13 včetně sloupce „jak jsem ověřil".
• Cesta A — překlad technické hlášky: vezmi reálnou chybovou hlášku z e-shopu nebo EviNoru (anonymizovanou) a nech AI napsat jednu větu pro zákazníka a jednu pro kolegu z IT. Posuď, jestli obě říkají pravdu a nic navíc.
• Cesta B — index a EXPLAIN naostro: u dotazu 7 nad milionovou tabulkou změř dobu běhu, přidej index, změř znovu a nech AI vysvětlit rozdíl — pak ověř, jestli vysvětlení odpovídá výstupu EXPLAIN a naměřeným časům.
• Cesta B — runbook k jedné rutinní operaci: nech vygenerovat runbook z kódu a commitů (např. měsíční aktualizace EviNoru z Věstníku) a zkrať ho na jednu stránku. Kritérium: přečte to člověk v sedm ráno, když něco stojí?

Hotový výstup: řádky 11+ v listu „10 dotazů", nebo přeložená hláška, nebo tabulka „před / po indexu", nebo jednostránkový runbook — vždy uložený na Drive kurzu.

Technické předpoklady dne

• Prohlížeč + Google účet (Colab, Sheets). Nic se neinstaluje — varianta A běží celá v prohlížeči: Adminer nad cvičnou MySQL databází lektora (jen pro čtení, odkaz na Drive kurzu), záloha db-fiddle.com (MySQL 8) nebo Colab.
• AI zdarma: Gemini (gemini.google.com, zdarma s Google účtem) nebo AI Studio (aistudio.google.com); ChatGPT (bezplatná verze) jen jako druhý názor. Žádné cvičení nezávisí na placené licenci.
• Testovací databáze připravená lektorem (MySQL 8, schéma podle EviNoru, data vymyšlená; jedna tabulka naplněná na ~1 000 000 řádků pro EXPLAIN) na Drive kurzu — je to zároveň záloha pro případ, že firemní vzorek nedorazí do 30. 9.
• Vzorek logu a legacy dotaz anonymizované předem (dotazník A21: osobní údaje, data klientů a informace o firmě ven nesmí).
• Varianta B: přístup k testovací kopii databáze — MySQL (EviNor, e-shop) nebo MS SQL (Kovy, EviZak) — domluvit s IT do 25. 9. Produkční přístup dnes nikdo nepotřebuje a nepoužije.
• Cvičný repozitář na GitHubu (firma verzuje na GitHubu ✅).
• Druhý monitor: výklad na jednom, Adminer na druhém.

Mini-úkol na příště

Zítra stavíme znalostní bázi nad vašimi dokumenty. Přines tedy:

1. 5–8 dokumentů, které bys nejraději měl po ruce v podobě „zeptám se a ono to odpoví s odkazem": poslední Věstníky, interní postup, katalog služeb, sada typových odpovědí zákazníkům (bez identifikace zákazníka). Ideálně PDF nebo Google Doc.
2. 3 otázky, u kterých znáš správnou odpověď — ty použijeme jako test, jestli báze funguje.
3. 1 otázku, na kterou v těch dokumentech odpověď není. Zjistíme, jestli to báze přizná.

Cíl dne

Účastník postaví znalostní bázi nad skutečnými dokumenty firmy, ptá se jí česky a u každé odpovědi vidí, z kterého dokumentu a odkud pochází. Otestuje ji deseti otázkami, u kterých zná správnou odpověď, a umí říct, co do báze v cloudu patří a co ne.

Výstup dne: funkční znalostní báze nad reálným korpusem firmy + protokol testu 10 otázek s vyhodnocením (kolik odpovědí bylo správných, kde a proč selhala) + rozhodnutí, čím korpus doplnit.

Úvodní cvičení dne (15 min)

Cíl: srovnat odpověď modelu bez podkladu a s nahraným zdrojovým dokumentem na tutéž otázku a ověřit, že jistota tónu výstupu nevypovídá o správnosti — vypovídá o ní jedině dohledatelný zdroj.

Test „Sebejistý kolega vs. citace". Dvě kola, stejná otázka:

1. Bez podkladu. Zeptej se modelu na něco konkrétního z vaší praxe — třeba jaký je obsah a rozsah konkrétní ČSN nebo jak u vás probíhá reklamace dodané normy — a přidej pokyn na tón: „odpověz jako nejsebevědomější kolega v kanceláři, který za třicet let ani jednou nepřipustil, že něco neví."
2. S podkladem. Nahraj dokument, ve kterém odpověď skutečně je, a polož stejnou otázku znovu.

Přečtěte obě odpovědi za sebou a porovnejte: která zní přesvědčivěji a která je ověřitelná. První bude znít líp.

Pointa: Rozdíl mezi „zní to dobře" a „je to na straně 12 tohohle dokumentu" je celý dnešní den. Sebejistota modelu nevypovídá o správnosti vůbec nic — vypovídá o ní jedině zdroj, který si můžete otevřít.

Chyba dne (2 min): odpověď, která byla dokonalá, jen se opírala o postup zrušený v roce 2019.

Témata (osnova)

• Co je znalostní báze nad vlastními dokumenty a čím se liší od běžného chatu: model neodpovídá z toho, co „ví", ale z toho, co jste mu dali — a ukáže, odkud to má. Když v podkladech odpověď není, má to říct.
• Proč právě tohle řeší obavu č. 1 z dotazníků. „Správnost odpovědí" a „nutnost všechno kontrolovat" zmiňují v dotazníku čtyři lidé. Kontrola s citací trvá deset vteřin. Kontrola bez citace trvá dvacet minut a nikdo ji nedělá.
• RAG lidsky (a přesně). Dokument se rozřeže na kusy → z každého kusu se spočítá „otisk významu" → otázka se převede na stejný otisk → vyberou se nejbližší kusy → model dostane jen ty a odpoví z nich. Důsledky, které z toho plynou pro každodenní práci: záleží na tom, jestli je odpověď rozprostřená přes celý dokument, špatně naskenovaná PDF nefungují, a báze nikdy „nezná celý dokument najednou".
• NotebookLM prakticky (cesta A). Založení notebooku, nahrání zdrojů, dotazování, čtení citací, souhrn zdroje, sada častých otázek. Zdarma s Google účtem, v prohlížeči, bez instalace — žádná placená licence.
• Gem s nahraným kontextem jako lehčí varianta pro opakující se agendu — navazuje na Gem z D3 (Gems jsou dostupné v bezplatném Gemini; záloha = System instructions v AI Studiu). Kdy stačí Gem a kdy je potřeba báze: pár stránek stálých pravidel vs. desítky dokumentů, ve kterých se hledá.
• Když báze odpoví špatně — diagnostika. Čtyři typické příčiny a co s každou: (1) dokument v korpusu vůbec není, (2) otázka je položená jinými slovy než dokument, (3) dva zdroje si protiřečí, (4) zdroj je zastaralý. Pátá, nejzrádnější: citace odkazuje na místo, kde odpověď není.
• Test deseti otázkami. Jak se pozná, že báze funguje: otázky, u kterých znáte odpověď, plus jedna, na kterou v podkladech odpověď není — báze to musí přiznat.
• Údržba a verze. U firmy, která garantuje platnost norem, je zastaralý dokument v bázi nebezpečnější než chybějící: odpověď působí podloženě. Kdo doplňuje zdroje, kdo vyřazuje neplatné, jak často.
• Bezpečnost — co do cloudové báze smí a co ne. Věcně. Ano: Věstníky ÚNMZ (veřejné), texty z webu a katalogu, obecné interní postupy, typové odpovědi zbavené identifikace. Ne: seznamy zákazníků z EviNoru (PHP/MySQL) a e-shopu (nody.cz), individuální ceny a smluvní podmínky, osobní údaje, cokoli z vlastního účetního systému. Co je mezi — rozhodnete dnes a zapíšete do pravidla z D1.
• Cesta B: postavit si to sám. Embeddings, vektorové vyhledávání, kde by to běželo: primární úložiště firmy je MySQL (EviNor) — embeddings vedle záznamů norem; MySQL 8 nemá nativní vektorový index, takže u větších korpusů vektorová vrstva vedle MySQL, nebo vlastní Linux server s lokálním modelem → D8. A upřímná úvaha, kdy to nestavět.

Harmonogram

Cvičení

6.1 — Znalostní báze nad korpusem firmy

Korpus (přinesený z mini-úkolu D5 + připravený lektorem na Drive kurzu):

• 3–4 Věstníky ÚNMZ z posledního roku (veřejné → do cloudu smí bez výhrad),
• interní postup, který se často vysvětluje nováčkům (např. jak se řeší náhrada za zrušenou normu),
• katalog služeb / texty z webu (EviNor, EviZak, Kovy, trvalé objednávky, tisk norem),
• 10 typových odpovědí zákazníkům — bez jména, IČO a bez cen.

Varianta A — jen prohlížeč (všichni)

1. Otevři NotebookLM, založ notebook „Normservis — normy a postupy" a nahraj zdroje. Bez instalace, se svým Google účtem, zdarma.
2. Nech si od každého zdroje vygenerovat souhrn. Přečti si ho — sedí? Když ne, je špatně zdroj, ne báze.
3. Polož pět otázek ze své vlastní agendy. U každé rozklikni citaci a otevři místo ve zdroji. Odpověď bez ověřené citace se dnes nepočítá za odpověď.
4. Nech si vygenerovat sadu častých otázek ke korpusu — dobrý zdroj nápadů, co do báze ještě chybí.
5. Hotový výstup: notebook, který používáš dál, + jedna reálná odpověď zákazníkovi sestavená z báze, s odkazem na zdroj v poznámce (ne v e-mailu zákazníkovi — tam patří hotová věta, ne interní citace).

Lehčí varianta pro stálou agendu: Gem z D3 (bezplatné Gemini) doplněný o nahrané dokumenty. Vhodné, když jde o pět stránek pravidel, která se nemění. Když jde o desítky dokumentů, ve kterých se hledá, patří to do báze.

Varianta B — terminál / IDE (programátoři)

• Postav totéž jako cestu A (ať víš, s čím poměřuješ), a paralelně jdi na cvičení 6.4.

6.2 — Test deseti otázkami

Bez tohohle kroku není báze hotová, jen zapnutá.

Připrav si tabulku (Sheets, sloupce: otázka · správná odpověď, kterou znám · co odpověděla báze · sedí citace? · verdikt · co s tím) a naplň ji:

• 7 otázek, u kterých znáš správnou odpověď — tři z nich takové, kde je odpověď schovaná uprostřed dlouhého dokumentu.
• 1 otázka, na kterou v korpusu odpověď není. Správný výsledek je, že to báze přizná. Když si vymyslí, poznamenej to — je to nejdůležitější řádek celého testu.
• 1 otázka položená „špatně" — laicky, jinými slovy, než jsou v dokumentu (třeba „kolik stojí, když nám vyprší norma" místo terminologie z postupu).
• 1 otázka, na kterou odpovídají dva zdroje rozdílně (starší a novější postup). Uvidíš, jestli báze rozpor přizná, nebo si jeden zdroj tiše vybere.

Vyhodnocení: X/10 správně. U každé chyby urči příčinu — chybí dokument · špatně položená otázka · protiřečící si zdroje · zastaralý zdroj · citace nesedí. Příčina určuje opravu; „ta AI je blbá" příčina není.

6.3 — Oprava korpusu

Vezmi svá selhání z 6.2 a rovnou je naprav:

• chybí dokument → dohledej a nahraj, otázku polož znovu,
• protiřečící si zdroje → vyřaď neplatnou verzi (a domluv, kdo ji bude vyřazovat příště),
• laicky položená otázka → doplň do korpusu krátký slovníček „jak tomu říkají zákazníci vs. jak tomu říkáme my". Tenhle jeden list zvedne úspěšnost báze víc než cokoli jiného.

Hotový výstup: druhé kolo testu na stejných deseti otázkách a porovnání X/10 před a po. Tohle číslo je jediný důkaz, že báze funguje — a ukazuje se ředitelovi líp než jakákoli prezentace.

6.4 — Vlastní řešení nad daty firmy (varianta B, programátoři)

Náčrt, ne hotový produkt — cíl je vědět, co byste stavěli, a rozhodnout, jestli to stavět.

1. Prototyp v Colabu nad Věstníky (veřejná data, smí do cloudu): rozřež text na kusy po ~500–1000 znacích s překryvem, spočítej embeddings (embedding model Gemini přes bezplatný API klíč z Google AI Studia), ulož je, k dotazu najdi 5 nejbližších kusů a nech model odpovědět jen z nich — s číslem Věstníku a stranou u každé odpovědi.
2. Kde by to běželo doopravdy: primární úložiště firmy je MySQL (EviNor, PHP) — embeddings by ležely vedle záznamů norem, ve stejné databázi, do které míří importní tabulka Věstníku z D5. MySQL 8 nemá nativní vektorový index: u menšího korpusu stačí kandidáty načíst přes PHP (PDO) a podobnost spočítat v aplikaci, u milionů záznamů potřebujete vektorovou vrstvu vedle MySQL (rozšíření nebo samostatná služba). Firma má vlastní Linux server, takže varianta „všechno lokálně, včetně embedding modelu přes Ollama" není teorie — čísla a rozhodnutí padnou v D8.
3. Kde se to napojí: stejná tabulka Věstníku, kterou jste navrhli v D5 — báze a evidence nejsou dvě oddělené věci.
4. Rozhodovací tabulka „stavět vs. použít hotové" — vyplňte ji společně:

Upřímný závěr, který má na kurzu zaznít: pokud korpus tvoří veřejné Věstníky a interní postupy a čte je člověk, vlastní RAG stavět nemá smysl — hotový nástroj to zvládne dnes odpoledne a zdarma. Vlastní řešení se vyplatí ve chvíli, kdy do báze mají vstoupit data, která nesmí ven, nebo když má na výsledek navazovat automatizace (import do EviNoru, agent, upozornění zákazníkům). Obojí přijde v D8 a D11 — takže tenhle prototyp má pokračování, není to cvičení do šuplíku.

Dílna (blok 4) — Znalostní báze na vlastní agendě

Hodina na to, aby se báze z dneška stala tvým nástrojem, ne cvičením. Lektor obchází a pomáhá 1:1.

• Slovníček „zákazník versus my" na 30 pojmů (cesta A — technický pracovníci a obchod). Nejlevnější zásah, který zvedne úspěšnost báze nejvíc ze všech. Vzniká jeden sdílený list pro celou firmu, ne deset osobních. Nahraj ho do svého notebooku a polož znovu tu „laicky položenou" otázku z testu.
• Dva ročníky Věstníku v jedné bázi (cesta A). Nahraj Věstník ze stejného měsíce loni a zeptej se, co se za rok změnilo. Uvidíš, kde báze končí a kde začíná potřeba strukturované extrakce — předehra k D7.
• Sloučený notebook pro tým (kdo je hotový dřív). Spoj svůj korpus s kolegovým a sleduj, co se stane s citacemi, když je zdrojů dvakrát tolik. Odpověď rozhoduje, jestli bude báze jedna společná, nebo osobní.
• Cesta B — prototyp vlastního RAG z 6.4 dotáhnout: rozřezání s překryvem, embeddings, pět nejbližších kusů a odpověď s číslem Věstníku a stranou; k tomu náčrt, jak by embeddings ležely vedle záznamů norem v MySQL (EviNor) — napojení na tabulku Věstníku z D5 je součást zadání, ne bonus.

Hotový výstup: notebook doplněný o slovníček (a případně o druhý ročník Věstníku) + třetí číslo X/10 po Dílně. Cesta B: běžící smyčka v Colabu, která na dotaz vrátí odpověď s číslem Věstníku a stranou, a jedna věta, kam a v jaké podobě by se embeddings uložily v MySQL.

Technické předpoklady dne

• Prohlížeč + Google účet. NotebookLM je zdarma — firma nemá placené AI a nic dnes na placené licenci nezávisí. Limity bezplatné vrstvy ověříme v tech-checku; při vyčerpání kvóty přepnout na druhý účet nebo na AI Studio. Ověřit v tech-checku, že se všichni přihlásí.
• Korpus připravený do 30. 9.: Věstníky stahuje lektor z veřejného webu firmy, interní postupy a typové odpovědi dodá firma zbavené identifikace zákazníků a cen. Záložní korpus (Věstníky + veřejné texty z webu) připraví lektor tak jako tak.
• Dokumenty musí být textové PDF, ne sken. Kdo přinese sken, uvidí naživo, proč báze mlčí — a to je dobrá ukázka, ne problém.
• Varianta B: Colab (bez instalace) nebo lokální Python; embeddings přes bezplatný API klíč z Google AI Studia, nebo lokální model přes Ollama na Linux serveru firmy (řeší se v D8). Pro náčrt uložení stačí testovací kopie MySQL (EviNor) nebo cvičná MySQL lektora přes Adminer (jen pro čtení, odkaz na Drive kurzu).
• Druhý monitor: notebook s bází na jednom, zdroj k ověření citace na druhém.

Mini-úkol na příště

Zítra jde Věstník na řadu naostro — z PDF do tabulky.

1. Stáhni si dvě čísla Věstníku: poslední a stejný měsíc loni (normservis.cz/download/vestnik/).
2. V oddílu normalizace projdi deset položek a zapiš, která pole u nich najdeš vždycky.
3. Najdi jednu položku, která formát porušuje (chybí údaj, jiné pořadí, poznámka navíc, oprava k jiné normě). Zítra právě na těchhle položkách poznáme rozdíl mezi „skoro hotovo" a hotovo.
4. Bonus: přidej oba Věstníky do své báze z dneška a zeptej se jí, co se za rok změnilo. Uvidíš, kde báze končí a kde začíná potřeba strukturované extrakce — to je přesně téma D7.

Cíl dne

Účastník zpracuje jedno reálné číslo Věstníku ÚNMZ z PDF do tabulky se šesti definovanými poli, ověří úplnost výstupu proti originálu (počty souhlasí, namátková kontrola 10 % zapsaná v protokolu) a vytvoří diff proti předchozímu měsíci se seznamem norem, které znamenají obchodní příležitost.

Měřitelně: na konci dne má každý účastník v Drive kurzu tři soubory — naplněnou tabulku, protokol kontroly a seznam „koho oslovit" — a ví, kolik minut mu zpracování trvalo.

Úvodní cvičení dne (15 min)

Cíl: ověřit, že model při změně výstupního formátu zachová fakta ze zdrojového PDF — srovnat strukturovanou extrakci a volnou sumarizaci téže položky Věstníku.

„Jedna položka, dva formáty." Každý si vybere jednu položku ze zrušených norem v přiděleném čísle Věstníku a nechá model vrátit ji dvakrát: a) jako strukturovaný záznam (označení ČSN · třídicí znak · název · datum účinnosti · nahrazeno čím · strana PDF), b) jako krátké oznámení zákazníkovi v souvislém textu (tři věty: co končí, od kdy, čím se nahrazuje).

Jedna podmínka: označení normy, třídicí znak a datum musí v obou formátech sedět přesně podle PDF. Čteme nahlas, ostatní mají otevřené PDF a hlídají — kdo v cizím výstupu najde údaj, který v dokumentu není, nahlásí odchylku.

Pointa: Formát výstupu je volný, fakta ne. Přesně o tom je celý dnešní den — model může text přeformulovat, jak chce, ale číslo normy a datum musí být dohledatelné na konkrétní straně PDF. Kdo dnes nahlásí nejvíc odchylek, bude odpoledne nejlepším kontrolorem.

Chyba dne (2 min): Model dostal odstavec Věstníku bez data účinnosti a datum si doplnil — věrohodné, kulaté, špatné. Ukážeme to na plátně a vrátíme se k tomu v závěru dne u kvízu.

Témata (osnova)

1. Anatomie Věstníku ÚNMZ. Měsíční PDF, oddíly: normalizace (vydané / změněné / zrušené ČSN, opravy), metrologie, zkušebnictví, akreditace, ostatní, převzaté informace. Typický rozsah jednoho čísla: ~70 vydaných · ~40 změněných · ~180 zrušených položek. Zdroj: normservis.cz/download/vestnik/vestYYMM.pdf — veřejná data, žádné osobní údaje, žádná data klientů → smí do cloudové AI, aniž bychom porušili firemní pravidlo z modulu M1.
2. Datový kontrakt dřív než extrakce. Šest polí, na kterých se dnes dohodneme: třídicí znak · označení ČSN · název · typ změny (vydaná / změněná / zrušená / oprava) · datum účinnosti · nahrazuje / nahrazeno — plus povinné sedmé pole strana PDF. Co v PDF není, se do tabulky nedoplňuje: pole zůstává CHYBÍ.
3. Extrakce po vrstvách, ne najednou. Jedna položka → jedna stránka → celý oddíl → celé číslo. Proč dávkovat: dlouhý vstup = víc vynechaných řádků, a chybějící řádek se hledá hůř než chybný.
4. Kontrola je půlka práce. Počty proti originálu, namátková kontrola 10 % znak po znaku, protokol kontroly (kdo, kdy, co, kolik chyb). U firmy, která zákazníkům garantuje platnost norem, není „skoro správně" použitelný výsledek.
5. Co dělat, když počty nesedí. Postup místo paniky: rozdíl lokalizovat po stránkách, ne po číslech. Tiché selhání je horší než hlášená chyba.
6. Diff proti minulému měsíci. Co v tabulce přibylo, co zmizelo, co změnilo stav.
7. Obchodní čtení výstupu. Která zrušená nebo nová norma znamená důvod ozvat se zákazníkovi.
8. Hranice AI a skriptu. Kde je model rychlejší (nepravidelná struktura, názvy) a kde patří deterministický kód (počty, formáty dat, opakování každý měsíc). Cíl celé linky je tabulka v MySQL EviNoru (PHP/MySQL) — proto výstup od začátku držíme jako CSV s pevnou hlavičkou.

Harmonogram

Rozdělení rolí na celý den (ne pozorovatelé, ale spoluautoři):

Cvičení

Každá dvojice dostane jiné číslo Věstníku z připravené sady na Drive kurzu (vest2601–vest2609) a k němu předchozí měsíc — kvůli diffu. Předpřipravená tabulka: Sheets vestnik-YYMM se sloupci podle datového kontraktu, kontrolními vzorci a druhým listem protokol-kontroly.

Varianta A — jen prohlížeč (všichni)

1. Nahraj PDF do Gemini (gemini.google.com, zdarma s Google účtem; nebo použij Gem „Věstník asistent" postavený v M3). Při vyčerpání bezplatné kvóty přepni na aistudio.google.com — nahrávání PDF funguje stejně.
2. Použij šablonu promptu z Drive (prompt-extrakce-vestnik.txt) — obsahuje datový kontrakt, formát výstupu (tabulka oddělená středníkem) a větu, kterou dnes nesmíš vypustit: „Pokud údaj v dokumentu není, napiš CHYBÍ. Nic nedoplňuj, nedopočítávej, nehádej."
3. Zpracuj oddíl po stránkách, ne celé PDF najednou — 5–10 položek na dávku. U každé položky nech model uvést stranu PDF, ze které ji vzal.
4. Vlož do Sheets. Data → Rozdělit text do sloupců. Tabulka se plní po dávkách.
5. Kontrola úplnosti: spočítej řádky (COUNTA) a porovnej s počtem položek v oddílu Věstníku. Nesedí? Rozdíl hledej po stránkách — porovnej počet položek na každé straně, ne v celku.
6. Namátková kontrola 10 %: vyber každou desátou položku, otevři uvedenou stranu PDF a porovnej znak po znaku (třídicí znak bývá první, kde se chybuje). Každou kontrolu zapiš do listu protokol-kontroly: číslo položky, strana, shoda ano/ne, popis odchylky.
7. Diff proti minulému měsíci: na třetím listu vzorec COUNTIF proti tabulce předchozího čísla → sloupec „nové / beze změny / zmizelo".
8. Obchodní čtení: projdi zrušené a nové normy a vypiš 5 řádků do listu koho-oslovit: norma → čeho se týká → typ zákazníka → v jedné větě proč ho to zajímá. (Např. zrušená řada ČSN EN 3155 / 3646 — letecké spojovací součásti → zákazníci s leteckou certifikací potřebují přechod na nové vydání. Nová ČSN EN 17976 — šroubové spoje na kolejových vozidlech → výrobci a opravci drážní techniky.)

Hotový výsledek na konci dne: naplněná tabulka za jedno reálné číslo · protokol kontroly s uvedeným počtem nalezených odchylek · seznam pěti zákaznických příležitostí. Bez jediné instalace.

Varianta B — terminál / IDE (programátoři)

1. Parser. PHP 8 (pdftotext + regulární výrazy — stejný jazyk jako EviNor) nebo Python (pdfplumber) — vytáhni text po stránkách a rozděl na položky podle pravidelného vzoru (třídicí znak v závorce, označení ČSN na začátku řádku). Výstup: CSV se stejnými sloupci jako varianta A. Kdo nemůže instalovat, jede v Colabu.
2. Srovnání dvou světů. Postav vedle sebe výstup parseru a výstup modelu ze stejného oddílu, udělej diff. Zajímavé nejsou shody, ale rozdíly — každý rozdíl otevři v PDF a rozhodni, kdo měl pravdu. Zapiš do tabulky: kde vyhrál skript, kde model, kde ani jeden.
3. Když struktura nesedí. Doplň kontrolu: pokud se na stránce nenajde očekávaný vzor nebo počet položek klesne pod práh, skript hlásí „nesedí struktura, strana N" a končí. Tiché přeskočení řádku je nejdražší chyba, jakou tenhle skript může udělat.
4. Kontrolní součty do kódu. Spočítej položky na stránku, porovnej s hlavičkou oddílu, výsledek zapiš do logu — kontrola z bodu 5 varianty A, ale automaticky.
5. Commit do cvičného repozitáře na GitHubu: parser/, ukázkové CSV, README s postupem spuštění a se seznamem známých odchylek struktury.
6. Otázka na konec pro ředitele a programátory: jak to má převzít EviNor (PHP/MySQL) — CSV pro LOAD DATA INFILE, přímý INSERT přes PDO v transakci, nebo importní stránka v aplikaci? EviNor má miliony záznamů, takže import řádek po řádku nepřipadá v úvahu. (Pro Kovy / EviZak — VB, MS SQL — je to stejná otázka s jiným dialektem.) Odpověď dnes zapíšeme; postavíme podle ní import v D9.

Dílna (blok 4) — extrakce Věstníku na vlastní agendě

Hodinu pracuješ na tom, co si z dneška opravdu odneseš. Lektor obchází a pomáhá 1:1.

• Techničtí pracovníci (cesta A): oddíl „Opravy ČSN" ze svého čísla — nepravidelná struktura, na které model klopýtne jinak než u vydaných norem — nebo vlastní dokument z agendy (katalogový list, přehled změn normy, veřejný nebo anonymizovaný podklad bez dat klientů) stejným postupem: datový kontrakt → dávky → strana PDF → kontrola. Hotový výstup: tabulka + nové řádky v protokol-kontroly.
• Obchod (cesta A): rozšíření seznamu „koho oslovit" z pěti na patnáct řádků s pojmenovanými obory a k nejsilnějším třem řádkům návrh e-mailu ze šablony z D4. Hotový výstup: použitelný pracovní seznam na příští týden.
• Programátoři (cesta B, rozšiřující zadání): dokonči srovnání parser vs. model na stejném oddílu (každý spor otevři v PDF) a připrav výstup pro EviNor: návrh tabulky vestnik_polozky v MySQL 8 (CREATE TABLE, index na oznaceni_csn a datum_ucinnosti), CSV s hlavičkou přesně podle ní a LOAD DATA LOCAL INFILE v transakci (cvičná databáze lektora přes Adminer nebo db-fiddle.com). Hotový výstup: DDL + CSV + tabulka „kde vyhrál skript, kde model" v repozitáři.
• Ředitel (s programátory): zápis „formát importu" — CSV pro LOAD DATA, přímý zápis přes PHP PDO, nebo importní stránka v EviNoru? Hotový výstup: jedna odsouhlasená věta ve sdílené poznámce, ze které se v D9 staví import.

Technické předpoklady dne

• Všichni: prohlížeč, přihlášení do Gemini (gemini.google.com, zdarma s Google účtem; nahrávání PDF), Google Sheets, přístup na Drive kurzu se sadou PDF Věstníků a šablonami. Druhý monitor — výklad na jednom, tabulka na druhém.
• Bezplatná vrstva: firma nemá placené AI licence; Gemini i Google AI Studio fungují zdarma. Limity bezplatné vrstvy (nahrávání PDF, denní kvóta) ověříme v tech-checku; při vyčerpání kvóty přepnout na AI Studio nebo druhý Google účet. Žádné cvičení dne nezávisí na placené licenci.
• Varianta B: PHP 8 + pdftotext (poppler) nebo Python 3 + pdfplumber, přístup na GitHub. Pro Dílnu MySQL 8 — cvičná databáze lektora přes Adminer (jen pro čtení, odkaz na Drive kurzu) nebo db-fiddle.com. Bez instalace: Colab — plnohodnotná náhrada, běží v prohlížeči.
• Lektor připraví předem: 9 čísel Věstníku + předchozí měsíce na Drive, šablonu Sheets s kontrolními vzorci, šablonu promptu, referenční výstup pro jedno číslo (ke srovnání), cvičnou MySQL databázi s tabulkou vestnik_polozky pro Dílnu.

Mini-úkol na příště

1. Změř baseline. Zapiš, kolik minut ti dnes trvalo zpracovat jedno číslo Věstníku — a zjisti (nebo odhadni), kolik trvá ruční postup dnes. Tahle dvě čísla jsou jediný důkaz, že se něco zlepšilo.
2. Dotáhni svoje číslo. Kdo nestihl celý oddíl zrušených norem, dodělá ho — do příště má být tabulka kompletní a protokol kontroly vyplněný.
3. Pro zítřek (lokální modely): zjisti u IT základní parametry firemního serveru — kolik RAM, kolik volného místa na disku, je tam grafická karta a jaká. Bez těchhle čísel bude zítřejší výpočet TCO cvičení naprázdno.

Cíl dne

Účastník změří stejnou sadu 20 úloh z vlastní agendy v cloudovém i v lokálním modelu (Ollama na firemním Linux serveru), spočítá TCO lokálního nasazení včetně aktuálních cen hardwaru a energie, a na základě těchto dvou čísel vyplní rozhodovací tabulku „co u nás běží kde".

Měřitelně: vyplněná srovnávací tabulka (20 úloh × kvalita, čas, cena), TCO s vypočítaným bodem zlomu a rozhodovací tabulka pro 8 typových úloh firmy. U cesty B navíc běžící lokální model volaný z PHP.

Úvodní cvičení dne (15 min)

Cíl: ověřit, že odhad hardwarových požadavků modelu (paměť, disk, grafická karta, rychlost) odpovídá jeho velikosti v parametrech — kalibrace odhadu před výběrem modelu pro firemní server.

„Srovnávací test modelů podle parametrů." Každý si vylosuje jednoho kandidáta — velký cloudový model, 8B model na notebooku, 14B model na firemním Linux serveru, 30B model na stroji s výkonnou grafickou kartou — a nechá AI (Gemini, zdarma s Google účtem) sestavit jeho profil ve čtyřech rubrikách: co zvládne · co potřebuje (RAM/VRAM, disk) · kde běží · na co ho nepoužívat.

Jedna podmínka: požadavky musí být reálné. Kdo má v profilu, že 30B model poběží na kancelářském notebooku s osmi gigabajty, má v něm chybu — a skupina ji má najít. Profily přečteme a hlasujeme dvakrát: který model dává nejlepší výstup — a který si firma může skutečně provozovat. Zřídka je to tentýž.

Pointa: Výběr modelu je párování požadavků a možností, ne srovnání podle nejvyšší kvality. Rozhodují gigabajty, koruny a sekundy. Dnešek je o tom, jak si je spočítat — a profil z tohoto cvičení si každý v bloku 1 ověří proti tabulce parametrů.

Chyba dne (2 min): „Nainstalovali jsme lokální model, takže máme vyřešenou bezpečnost." Nemáme — vrátíme se k tomu ve třetím bloku.

Témata (osnova)

1. Proč vůbec on-prem. Firemní pravidlo o datech + vlastní Linux server + žádná placená AI = tři podmínky, které má málokterá firma najednou splněné. Lokální model má nulovou licenci, ale stojí železo a čas správce. Co konkrétně z agendy Normservisu nesmí ven (zákaznická data v EviNoru, objednávky z e-shopu) a co klidně může (veřejný Věstník ÚNMZ, texty norem k překladu).
2. Jak model vlastně běží. Parametry (7B / 8B / 14B / 30B) a co znamenají pro paměť. Kvantizace srozumitelně: model si pamatuje čísla s menší přesností — místo šestnácti desetinných míst čtyři. Zabere půlku až čtvrtinu paměti, běží rychleji, kvalita klesne o kousek. Hrubá orientace: 8B kvantizovaný ≈ 5–6 GB · 14B ≈ 9–10 GB · 30B ≈ 20 GB. Bez grafické karty to běží v RAM — funguje to, ale pomalu.
3. Kontextové okno. Kolik textu model najednou „vidí" (vstup i výstup dohromady). Proč je to u Věstníku zásadní a proč lokální modely mívají okno menší než cloudové.
4. Ollama na firemním Linux serveru. Instalace jedním skriptem, ollama pull, ollama run, lokální API na localhost:11434 (z interní sítě http://<server>:11434), volání z PHP 8 (curl) i z Pythonu. Model neběží „v prohlížeči", běží jako služba vedle EviNoru — a to je jeho výhoda: dá se zavolat z PHP kódu, který firma už má.
5. TCO střízlivě. Pořizovací cena stroje nebo rozšíření serveru za dnešních cen, spotřeba, životnost, čas správce — proti ceně cloudových tokenů při reálném měsíčním objemu. Firma dnes za AI neplatí nic, takže srovnáváme „koupit železo" proti „začít platit za tokeny" — bezplatná vrstva má kvóty a zákaznická data do ní nepatří. Výsledkem je bod zlomu: kolik úloh měsíčně musí proběhnout, aby se vlastní železo vyplatilo.
6. Ceny hardwaru jako plnohodnotná položka rozpočtu. Poptávka datových center po pamětech, discích a grafických kartách zvedla jejich ceny — kdo počítá s cenami z předloňska, spočítá si to špatně. Tenhle argument dnes nepřeskakujeme, dosazujeme ho do vzorce.
7. Kdy ANO a kdy NE. ANO: citlivá data, velký objem stejné úlohy, potřeba stálé ceny, provoz nezávislý na dostupnosti služby. NE: potřebuji nejvyšší kvalitu, úloh je málo (fixní náklad se nemá na co rozpočítat), nemá to kdo spravovat, potřeby se rychle mění.
8. Měření místo dojmů. Stejných 20 úloh z jejich agendy do obou světů, hodnocení podle jednoho kritéria. Kdo neměří, hádá — a hádá obvykle ve prospěch toho, co si už předem myslel.
9. Hybridní architektura pro Věstník. Veřejné PDF ÚNMZ v cloudu, párování se zákaznickou evidencí v EviNoru (MySQL) lokálně. Napojení na D7 a předstupeň k agentovi v D11.

Harmonogram

Cvičení

Společný podklad: sada 20 úloh z reálné agendy firmy, připravená lektorem na Drive kurzu — 5× extrakce položky z Věstníku · 5× odpověď na typový dotaz zákazníka · 5× vysvětlení technického textu / normy · 5× SQL dotaz (MySQL 8 nad EviNorem / e-shopem) nebo kus kódu (PHP 8, VB.NET z Kovy / EviZak). Stejné zadání pro oba světy.

Nástroje dne (vše zdarma): Gemini (gemini.google.com, s Google účtem) nebo AI Studio (aistudio.google.com) jako cloudová strana; ChatGPT zdarma jen jako druhý názor; Ollama na firemním Linux serveru jako lokální strana. Žádné cvičení nezávisí na placené licenci — placené modely a Claude Code vidíš jen v ukázce na obrazovce lektora.

Varianta A — jen prohlížeč (všichni)

1. Srovnávací test. Otevři sdílenou tabulku srovnani-modelu (Sheets, předpřipravené sloupce). Každý dostane 5 úloh ze sady. Pošli je do Gemini a tytéž do lokálního modelu, který po dobu bloku sdílí lektor (promítá a rozdává výstupy; kdo chce, diktuje zadání sám).
2. Hodnoť podle jednoho pravidla, ne podle pocitu: správnost 0–2 · použitelné bez úprav ANO/NE · čas do odpovědi (s) · poznámka, co bylo špatně. Dvě stejné úlohy hodnotí dva lidé nezávisle — pak se porovná, jestli se shodli.
3. TCO v Sheets. Druhý list tco-lokalni-model má vzorce hotové, ty doplníš vstupy: pořizovací cena stroje nebo rozšíření stávajícího serveru (dnešní nabídka, ne odhad z paměti) · životnost v letech · průměrný příkon ve W a cena kWh · hodin správy měsíčně × sazba · proti tomu cena za milion tokenů placeného API a odhad měsíčního objemu úloh. Firma dnes za AI neplatí nic — cloudový sloupec je „co by stálo začít platit", protože bezplatná vrstva má kvóty a zákaznická data do ní nepatří. Tabulka dopočítá měsíční náklad obou variant a bod zlomu.
4. Citlivostní kontrola. Zvedni cenu hardwaru o 30 % a podívej se, jak se bod zlomu posune. Právě tenhle řádek je odpovědí na argument o zdražení pamětí a grafik — vidíš, o kolik se to láme.
5. Rozhodovací tabulka co-bezi-kde. Osm typových úloh firmy (extrakce z Věstníku · odpověď zákazníkovi obsahující jeho údaje · párování norem s evidencí zákazníků v EviNoru · psaní nabídky · vysvětlení legacy kódu (VB6 v Kovy / EviZak) · SQL nad zákaznickou databází EviNoru (MySQL) · překlad technického textu · rešerše zahraniční normy). U každé vyplň: data citlivá ANO/NE · objem za měsíc · potřebná kvalita · snese to čekání? → verdikt: cloud / lokálně / hybridně a jednou větou proč.
6. Věstník hybridně. Do posledního řádku doplň tok z D7: kde v něm leží hranice mezi veřejným PDF a zákaznickými daty a v kterém kroku se přechází z cloudu na vlastní server.

Hotový výsledek na konci bloku 3: vyplněné srovnání 20 úloh · TCO s bodem zlomu a citlivostní variantou · rozhodovací tabulka pro 8 úloh firmy. Vše bez jediné instalace.

Varianta B — terminál / IDE (programátoři)

Instalace řešit předem. Ollama běží na firemním Linux serveru (stejný stroj jako PHP/MySQL, nebo vedlejší) — instalaci, ~15 GB místa a port 11434 jen pro interní síť domluvit s IT do 25. 9. Vlastní Ollama na notebooku je bonus, ne podmínka. Kdo přístup na server nedostane, jede přes endpoint lektora nebo Ollamu v Colabu — nikdo dnes nepřihlíží.

1. Stažení modelů hned v 8:00 (běží na pozadí během úvodního cvičení a Bloku 1): na serveru ollama pull llama3.1:8b a ollama pull qwen2.5:14b. Modely mají jednotky gigabajtů, na firemní síti to chvíli trvá.
2. První běh a měření rychlosti. ollama run na jedné úloze ze sady, změř dobu odpovědi a rychlost generování. Porovnej 8B a 14B na stejném zadání — rozdíl v kvalitě proti rozdílu v čase.
3. Volání z kódu. HTTP POST na http://localhost:11434/api/generate (z jiného stroje v síti http://<server>:11434) z PHP 8 (curl + json_encode) i z Pythonu (requests). Kdo chce, zkusí streamování odpovědi. Tohle je ten okamžik, kdy se z „nástroje v terminálu" stane komponenta, kterou lze zavolat z EviNoru nebo z e-shopu na platformě nody.cz.
4. Dávka 20 úloh skriptem. Prožeň celou sadu lokálním modelem, výstup do CSV s časy, nahraj do stejné tabulky srovnani-modelu jako cesta A. Od té chvíle máte tři sloupce: cloud, lokální 8B, lokální 14B.
5. Test kontextového okna. Pošli modelu dvě stránky Věstníku najednou a sleduj, kde začne vynechávat položky. Zapiš práh — je to vstupní údaj pro dávkování v D9.
6. Poznámka k bezpečnosti (věcně). Lokální model neznamená automaticky splněné pravidlo o datech: prompty a odpovědi se logují, na serveru zůstávají, přístup k API je potřeba omezit stejně jako k MySQL. Ověř, kdo se na 11434 dostane (z internetu nikdo, z interní sítě jen kdo má), a zapiš to.
7. Commit do cvičného repozitáře: skript volání (PHP i Python), dávkový běh, CSV s naměřenými časy, README s hardwarem, na kterém to běželo (bez toho jsou čísla nepřenositelná).

Dílna (blok 4) — lokální model na vlastní agendě

• Cesta A — dvě vlastní úlohy. Přidej do co-bezi-kde dvě úlohy ze své reálné práce (mail z pondělí, dotaz zákazníka, kus normy k vysvětlení), pošli je do lokálního modelu, který lektor promítá, a zapiš verdikt s důvodem. Výstup: dva nové řádky v rozhodovací tabulce.
• Cesta A — třetí model do srovnání. Lektor přidá malý model (3B nebo mini). Pošli do něj svých pět úloh z bloku 2 a najdi dolní hranici použitelnosti. Výstup: čtvrtý sloupec v srovnani-modelu — „lokálně" není jedna kategorie, ale škála.
• Ředitel / kdo počítá rád — TCO pro pronájem GPU serveru. Třetí sloupec mezi cloudem a vlastním železem. Výstup: tři body zlomu vedle sebe; často z toho vyjde nejrozumnější kompromis pro první rok.
• Cesta B — rychlost a limity. Streamovaná odpověď, tokeny za sekundu 8B proti 14B na stejném zadání (vstup do TCO „snese to čekání?") a test kontextového okna až do selhání: přidávej stránky Věstníku, dokud model nezačne vynechávat položky. Výstup: obě čísla v README repozitáře — práh je přímý vstup pro dávkování v D9.

Technické předpoklady dne

• Všichni: prohlížeč, Google účet (Gemini a AI Studio zdarma), Sheets, přístup na Drive kurzu (sada 20 úloh, šablony srovnani-modelu, tco-lokalni-model, co-bezi-kde). Druhý monitor. Žádná placená AI licence není potřeba; limity bezplatné vrstvy ověříme v tech-checku, při vyčerpání kvóty přepni na AI Studio nebo druhý účet.
• Sdílený lokální model: lektor po dobu Bloku 2 promítá a obsluhuje lokální model — varianta A tak měří na skutečném lokálním běhu, ne na popisu.
• Varianta B: Ollama na firemním Linux serveru (instalace curl -fsSL https://ollama.com/install.sh | sh, domluvit s IT), ~15 GB volného místa na dva modely, minimálně 16 GB RAM pro 8B kvantizovaný; 14B chce ~10 GB VRAM nebo hodně trpělivosti v RAM. SSH na server, PHP 8 s curl nebo Python 3, přístup na GitHub. Vlastní instalace na notebooku (Windows 10/11) je volitelná. Bez instalace: Colab.
• Nutný vstup od firmy (mini-úkol z D7): parametry vlastního serveru — RAM, volné místo, grafická karta ano/ne a jaká, co na něm už běží (PHP/MySQL zátěž). Bez těchhle čísel je TCO cvičení naprázdno.
• Aktuální ceny: nabídka na server/GPU (nebo rozšíření RAM/GPU stávajícího serveru) a cena kWh k datu kurzu. Ceny paměti a grafik se hýbou, proto se dosazují v den kurzu, ne se opisují z materiálu.

Mini-úkol na příště

1. Dotáhni TCO. Kdo má přístup k dodavateli, doplní do tabulky reálnou nabídku na stroj (nebo rozšíření stávajícího Linux serveru o RAM/GPU), který by 14B model utáhl, a přepočítá bod zlomu. Odhad z hlavy nahraď číslem z e-mailu.
2. Doplň rozhodovací tabulku o dvě úlohy ze své vlastní agendy, které dnes nebyly na seznamu.
3. Pro zítřek (AI ve vývoji I): přines jeden reálný kus kódu ze svého světa — modul ve VB6 nebo VB.NET z Kovy / EviZak, PHP skript z EviNoru nebo e-shopu, SQL dotaz nad MySQL nebo MS SQL — kterému nerozumíš ty nebo mu nerozumí kolegové. Ideálně něco starého, cizího a bez komentářů. Zítra ho necháme vysvětlit. Programátoři si navíc ověří, že mají Gemini CLI (npm i -g @google/gemini-cli, přihlášení Google účtem) nebo Gemini Code Assist / Copilot Free ve VS Code — případně Codespaces.

Cíl dne

Každý programátor odchází s jedním legacy modulem z vlastního systému (EviNor v PHP/MySQL, Kovy nebo EviZak ve VB nad MS SQL), který mu AI vysvětlila a našla v něm aspoň jednu nesrovnalost ověřenou na konkrétním řádku kódu, a s jednou novou funkcí vygenerovanou ze zadání, spuštěnou na testovacích datech. Každý neprogramátor odchází s vlastním Apps Scriptem, který sám spustil a jehož výsledek vidí v tabulce.

Úvodní cvičení dne (15 min)

Cíl: ověřit, jak množství kontextu (útržek kódu vs. celý soubor s popisem systému) mění správnost a použitelnost vysvětlení kódu, které model vrátí.

Kód bez kontextu a s kontextem. Každý přinese nejstarší artefakt své agendy — 20 let starou VB6 proceduru z Kovy nebo EviZaku, PHP skript z EviNoru, o kterém už nikdo neví, proč tam je, vzorec v Excelu z roku 2012, formulář, který se „vždycky vyplňoval".

1. kolo — jen útržek. Do AI vložíš samotný kus kódu nebo vzorce bez čehokoli okolo a zadáš:

„Vysvětli v pěti větách, co tohle dělá, co je vstup a výstup a co z toho nejde určit."

1. kolo — celý soubor + kontext. Totéž zadání, ale model dostane celý soubor a tři věty navíc:

co systém dělá, kdo tenhle kód volá, jaká data tím tečou.

Porovnáme obě vysvětlení u tří účastníků: co model v prvním kole domyslel, co ve druhém kole doložil. „Chyba dne" na závěr.

Pointa: Z útržku vznikne domněnka, z celého souboru s kontextem vznikne vysvětlení. Kolik AI dáte kontextu, takovou dostanete odpověď — a přesně na tom stojí celý dnešní den.

Témata (osnova)

1. Tři úrovně nástrojů a co která vidí

• Chat v prohlížeči (Gemini zdarma, AI Studio, ChatGPT zdarma) — vidí jen to, co do něj vložíte. Nulová instalace, plná kontrola, hodně kopírování.
  • Asistent v IDE (Gemini Code Assist zdarma ve VS Code, nebo GitHub Copilot Free ve VS Code i ve Visual Studiu) — vidí otevřený soubor a projekt, doplňuje a navrhuje přímo v editoru.
  • Agent v terminálu (Gemini CLI — zdarma s Google účtem, cca 1 000 požadavků denně) — vidí repozitář, umí sám číst soubory, spouštět příkazy a psát změny. Největší přínos, největší nárok na kontrolu. Placené agenty (Claude Code) uvidíte jen jako ukázku na obrazovce lektora — žádné cvičení na nich nestojí.
  • Pravidlo: čím víc nástroj vidí a smí, tím pečlivěji se čte, co udělal.

1. Co jde bez instalace — Apps Script editor, Google Colab, GitHub Codespaces (firma GitHub používá → editor běží v prohlížeči nad cvičným repozitářem a v jeho terminálu běží i Gemini CLI). Kdo instalovat může (4 z 10), zapne si asistenta v IDE; kdo jen přes IT (5 z 10), jede v Codespaces a o nic nepřijde. Instalace domluvené s IT do 25. 9.
2. Čtení cizího a starého kódu — hlavní téma dne. Postup: celý soubor + kontext → požádat o (a) shrnutí v pěti větách, (b) vstupy, výstupy a vedlejší efekty, (c) místa, kde se chování liší od toho, co jsme čekali, (d) otázky, na které si model netroufá. Pak ověření: „ukaž řádek, ze kterého to tvrdíš."
3. Ukázka dne: legacy modul. Dvacet let stará VB6/VB.NET procedura z Kovy nebo EviZaku (klient/server nad MS SQL), kterou nikdo nechce otvírat — nebo PHP skript z EviNoru. AI ho vysvětlí a najde nesrovnalost — jinou podmínku, než tvrdí komentář, mrtvou větev, dvojí formát data, zaokrouhlení, které se dělá na dvou místech jinak. Nesrovnalost ověříme přímo v kódu. Tohle je pro firmu s vlastním účetním systémem a evidencí milionu norem cennější než generování nového kódu.
4. Generování ze zadání. Dobré zadání pro kód obsahuje: vstup, očekávaný výstup, hraniční případy, jazyk a verzi (PHP 8 + PDO, MySQL 8; VB.NET + MS SQL), styl projektu a co nedělat. Malé celky, ne „napiš mi modul". Vždy spustit na testovacích datech dřív, než tomu uvěřím.
5. Kontextové soubory projektu — AGENTS.md, GEMINI.md (čte Gemini CLI), .github/copilot-instructions.md. EviNor, EviZak, Kovy ani vlastní účetní systém nejsou v trénovacích datech žádného modelu. Co AI neví, musíme jí napsat: struktura, konvence pojmenování, tabulky, kterých se nesahá, jazyk komentářů, verze PHP a MySQL (resp. VB.NET a MS SQL), co má vždy ověřit.
6. Bezpečnostní minimum dne (podrobně zítra): do cloudové AI patří kód a testovací vzorek. Nepatří tam přístupové údaje, produkční data ani údaje zákazníků. Platí i v IDE — asistent vidí otevřený soubor.

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

A1 · Tvůj první funkční skript (blok 2). V cvičném Sheetu „Evidence norem — cvičná" (50 vymyšlených řádků: třídicí znak, označení, název, datum vydání, typ změny) napíšeš s pomocí Gemini (gemini.google.com, zdarma s Google účtem, nebo aistudio.google.com) funkci oznacZruseneNormy(): projde řádky, zrušené normy obarví a doplní jim sloupec „řešit do" (datum vydání + 30 dní).

Krok za krokem: Rozšíření → Apps Script → vložit kód → Spustit → povolit oprávnění → přepnout do tabulky a podívat se na výsledek. Když to spadne, přečteš hlášku, pošleš ji AI i s kódem a opravíš. Spadne to skoro každému — a to je součást cvičení, ne selhání.

Hotovo znamená: skript běží bez chyby a v tabulce je vidět, co udělal. Nikdo nekončí den s teorií.

A2 · Vysvětli mi ten starý (blok 3). Vezmeš svůj artefakt z úvodního cvičení — vzorec, makro, dlouhou šablonu odpovědi zákazníkovi, starý formulář — a necháš si od AI vysvětlit v pěti větách, co dělá a co je jeho vstup a výstup. Pak jednu věc ověříš proti realitě (zkusíš vzorec na známém příkladu, porovnáš se skutečným postupem) a zapíšeš: co sedělo, co nesedělo, co zůstalo nejasné. Kdo nemá vlastní artefakt, dostane od lektora starý vzorec z evidence norem.

Výstup A: funkční skript + jednostránkové vysvětlení starého artefaktu s poznámkou „ověřeno / neověřeno".

Varianta B — terminál / IDE (programátoři)

B1 · Prostředí (15 min, blok 2). Kdo instalovat může, zapne si asistenta v IDE — Gemini Code Assist (zdarma, VS Code) nebo GitHub Copilot Free (VS Code / Visual Studio pro VB.NET) — a nainstaluje Gemini CLI (npm i -g @google/gemini-cli, přihlášení Google účtem, bezplatná kvóta). Kdo nemůže, otevře cvičný repozitář v GitHub Codespaces — plnohodnotné prostředí v prohlížeči, Gemini CLI běží v jeho terminálu. Než jdeme dál, musí všichni tři mít prostředí, ve kterém dnes napíšou a spustí kód. Žádný krok dnes nestojí na placené licenci.

B2 · Legacy ze svého světa (blok 2). Každý si vybere jeden modul ze svého světa: VB6/VB.NET proceduru z Kovy nebo EviZaku (MS SQL), PHP skript z EviNoru nebo z e-shopu na platformě nody.cz (PHP/MySQL), uloženou proceduru nebo dlouhý dotaz nad evidencí norem (MySQL). Projdeš postup čtení (5 vět · I/O a vedlejší efekty · nesrovnalosti · otevřené otázky) a nález zapíšeš do nalezy.md.

Hotovo znamená: aspoň jedna nesrovnalost, u které umíš ukázat konkrétní řádek. Když AI nesrovnalost vymyslí a řádek to nepotvrdí, je to taky výsledek — a zapisuje se stejně.

Kdo nechce dávat firemní kód do cloudu, dostane od lektora legacy balíček (VB6 modul, PHP skript, MySQL procedura).

B3 · Generování na reálné úloze — import Věstníku (blok 3). Import Věstníku míří do EviNoru, proto je primární varianta PHP 8 + PDO do MySQL:

• PHP 8 + MySQL (hlavní): parsujPolozkuVestniku(string $radek): array — z textového řádku Věstníku vytáhne třídicí znak, označení, název, typ změny a datum — a ulozPolozkuVestniku(PDO $pdo, array $polozka): void, která ji uloží do cvičné tabulky vestnik_import přes prepared statement (žádné skládání SQL z řetězců; mysqli jen zmínit). Testovací sada: 5 běžných řádků + 3 nestandardní. Cílová tabulka má v ostrém provozu miliony řádků → dávkový import v transakci, ne řádek po řádku s autocommitem.
• VB.NET + MS SQL (Kovy / EviZak): ImportVestnik(cesta) → DataTable + mapování polí do struktury evidence a zápis přes SqlCommand s parametry. Hraniční případy: chybějící datum, dlouhý název, diakritika, prázdný řádek.
• SQL (MySQL 8): kontrolní report — které normy vede evidence jako platné, ačkoli je Věstník uvádí jako zrušené. Nad tabulkou s miliony řádků: EXPLAIN, index na označení normy, LIMIT při ladění. Výstup připravený k exportu.
• Python / bash (volitelně): stažení chybějících čísel Věstníku z normservis.cz/download/vestnik/vestYYMM.pdf a přehled, které měsíce v archivu chybí.

Postup vždy: zadání → vygenerovat → přečíst řádek po řádku → spustit na testovacích datech → opravit → uložit do repozitáře.

B4 · Kontextový soubor projektu (blok 3). Napiš GEMINI.md (čte ho Gemini CLI; obsah je stejný jako AGENTS.md nebo .github/copilot-instructions.md) pro svůj projekt, 15–25 řádků: co systém dělá · jazyk a verze (PHP 8 + MySQL 8 / VB.NET + MS SQL) · struktura složek · konvence pojmenování · tabulky, kterých se nikdy nesahá · jazyk komentářů · co má AI vždy ověřit. Pak pusť stejný prompt bez souboru a s ním a porovnej výstupy. Rozdíl uvidíš okamžitě — a příští týden ho ocení kolega.

Výstup B: nalezy.md s vysvětleným legacy modulem a ověřenou nesrovnalostí · vygenerovaná a spuštěná funkce ve vlastním jazyce · kontextový soubor projektu.

Dílna (blok 4) — čtení a generování kódu na vlastní agendě

• Cesta A: vezmi vlastní tabulku ze své agendy (ne cvičný Sheet) a přenes do ní dnešní skript — sloupce se jmenují jinak, takže ho s AI upravíš. Kdo doběhne dřív, rozšíří ho o zápis do druhého listu nebo o odeslání souhrnu e-mailem. Hotový výstup: skript, který běží nad tvou reálnou tabulkou a změnil v ní něco viditelného.
• Cesta B — refaktoring beze změny chování: vyber malou funkci ze svého modulu, nejdřív si ulož testovací vstup a výstup, pak nech AI funkci zpřehlednit a ověř, že výstup před a po je shodný. Hotový výstup: dvojice „před / po" se shodným výsledkem na testovacích datech (přímý most do D10).
• Cesta B — rozšiřující zadání: druhý legacy modul vybraný naslepo (kolega vybere za tebe) stejným postupem jako v B2. Hotový výstup: druhý záznam v nalezy.md s číslem řádku.
• Lektor obchází 1:1; kontrola na konci je „ukaž mi to", ne „máte to?".

Technické předpoklady dne

• Google účet + Sheets + povolený Apps Script (ověřeno v tech-checku ~5. 10.)
• Gemini (gemini.google.com) nebo AI Studio (aistudio.google.com) — obojí zdarma s Google účtem; limity bezplatné vrstvy ověříme v tech-checku, při vyčerpání kvóty přepnout na AI Studio / druhý účet
• Cvičný Sheet „Evidence norem — cvičná" (50 vymyšlených řádků) — připraví lektor, sdílený na Drive kurzu
• Cvičný repozitář na GitHubu + přístup pro účty firmy; v něm připravený GEMINI.md jako šablona
• Cesta B: VS Code s Gemini Code Assist nebo GitHub Copilot Free (Visual Studio pro VB.NET), Gemini CLI (instalace domluvená s IT do 25. 9.) nebo GitHub Codespaces v prohlížeči jako plnohodnotná záloha s Gemini CLI v terminálu — otestováno předem lektorem
• Cvičná MySQL databáze lektora s tabulkou vestnik_import a vzorkem evidence norem — přístup přes Adminer (jen pro čtení, odkaz na Drive kurzu) nebo db-fiddle.com (MySQL 8); zápis do vlastní kopie v Codespaces
• Legacy balíček lektora (VB6 modul, PHP skript, MySQL procedura) pro ty, kdo nemohou nebo nechtějí sdílet firemní kód
• 3 čísla Věstníku ÚNMZ v PDF (veřejná data)
• Druhý monitor (má každý) — výklad na jednom, práce na druhém
• Pravidlo dne: do AI jen kód a testovací data. Žádné přístupové údaje, žádná data zákazníků.
• Claude Code a další placené nástroje se objeví jen na obrazovce lektora — žádné cvičení na nich nestojí.

Mini-úkol na příště

• Všichni: přines jednu reálnou chybu — celou chybovou hlášku, kus kódu nebo skriptu kolem ní a jednu větu, co jsi čekal, že se stane. Zítra ji budeme ladit doopravdy.
• Cesta A: přines svůj dnešní Apps Script. Zítra ho budeme lámat a opravovat.
• Cesta B: nech dnešní kontextový soubor přečíst kolegovi a připiš jednu věc, kterou by tam hledal a nenašel.
• Před vložením hlášky do AI z ní vymaž jména, e-maily a čísla zákazníků, pokud v ní jsou.

Cíl dne

Každý účastník opraví jednu reálnou chybu postupem hypotéza → důkaz → oprava a umí vlastními slovy říct, proč oprava funguje. Programátoři odcházejí s aspoň třemi testy k vlastní funkci (PHPUnit u EviNoru a e-shopu, MSTest/NUnit u Kovy a EviZak — včetně regresního testu k dnes opravené chybě) a s týmovým checklistem „než mergnu AI kód". Cesta A odchází s opraveným skriptem a napsaným README k automatizaci ze dne 4.

Úvodní cvičení dne (15 min)

Cíl: ověřit, že kvalita popisu změny (commit zprávy) závisí na podkladu, který model dostane — bez diffu vzniká text formálně správný a věcně prázdný nebo chybný.

Test kvality popisu změny. Každý napíše (sám, bez AI) nejméně informativní zprávu ke změně, jakou v praxi potkal nebo sám použil: „opraveno", „tak už fakt", „final_v3", „nesahat". Kdo nekomituje, uvede nejméně informativní název souboru ze své praxe — smlouva_finalni_OPRAVENA_2_pouzit_tuhle.docx je plnohodnotný příklad. Skupina hlasuje, který popis dává čtenáři za rok nejméně informací.

Pak necháme AI napsat popis změny z diffu (cesta A: z popisu, co se v souboru změnilo) a srovnáme. Jeden dobrovolník zadá AI jen „napiš commit message" bez diffu — a přečteme, co model vymyslí.

Pointa: Commit zpráva je záznam pro čtenáře za rok. Model ji napíše kvalitně jen tehdy, když dostane, co se opravdu změnilo. Bez podkladu vytvoří text formulačně správný a věcně chybný — a přesně tohle je téma celého dne: každý výstup modelu ověřit proti skutečnosti.

Témata (osnova)

1. Systematické ladění. Co všechno modelu předat: kód kolem chyby · celou hlášku (ne screenshot poloviny) · vstup, který ji vyvolá · co jsi čekal, že se stane · prostředí (verze PHP 8, .NET, MySQL 8 nebo MS SQL). Postup: hypotéza → důkaz → oprava → ověření, že se chyba nevrátí. Neopravovat, dokud neumím ukázat důkaz.
2. Proč nepřijmout opravu, které nerozumím. AI často opraví symptom (přidá kontrolu na prázdnou hodnotu), ne příčinu (proč tam ta prázdná hodnota je). U vlastního účetního systému a u EviNoru (PHP/MySQL) to platí dvojnásob: tichá změna zaokrouhlení nebo podmínky platnosti se neprojeví dnes, ale za měsíc — na faktuře, nebo v informaci, kterou dostane zákazník o platnosti normy.
3. Testy od nuly, bez velké investice. Firma dnes testy prakticky nemá. Nezačínat testy k celému systému — začít u jedné nové funkce a u jedné opravené chyby (regresní test = důkaz, že chyba je pryč a nevrátí se). Podle světa: PHPUnit pro PHP 8 (EviNor, e-shop na platformě nody.cz) · MSTest / NUnit ve Visual Studiu pro VB.NET (Kovy, EviZak) · kontrolní SQL dotazy nad testovací kopií MySQL / MS SQL · testovací funkce v Apps Scriptu (cesta A).
4. Testy jako pojistka pro refaktoring legacy. Dokud nemám test, je refaktoring dvacetiletého modulu hazard. Postup: charakterizační test (zafixuje současné chování — i to divné, které nikdo nechtěl) → refaktor → test musí projít stejně.
5. Refaktoring bez změny chování. Malé kroky, jeden commit = jedna změna. V Kovy a EviZak (VB6/VB.NET nad MS SQL) má smysl: pojmenovat magické konstanty, rozdělit osmisetřádkovou proceduru, odstranit mrtvou větev, sjednotit práci s datem. V PHP (EviNor, e-shop): vytáhnout opakovaný dotaz do jedné funkce, nahradit mysqli skládané dotazy za PDO s prepared statements. Nemá smysl: přepsat fungující modul do jiného jazyka bez důvodu. Refaktorujeme to, čeho se často dotýkáme — modul, který 15 let běží a nikdo do něj nesahá, refaktoring nepotřebuje.
6. Code review s AI. Nástroje zdarma: Gemini Code Assist for individuals (VS Code) nebo GitHub Copilot Free v IDE, Gemini CLI v terminálu; Claude Code jen jako ukázka lektora. Spolehlivě najde: překlepy a typové chyby · neošetřené hraniční případy · SQL injection · chybějící kontrolu návratové hodnoty · mrtvý kód · duplicitu · nekonzistentní pojmenování. Nenajde: že „zrušená norma s náhradou" je u vás jiný stav než „zrušená bez náhrady" · že tenhle zákazník má smluvně jiný postup · že sloupec dat_zm znamená něco jiného, než by kdokoli čekal. AI je první čtenář, ne poslední.
7. Git a AI. Commit zpráva z diffu (píše se proč, ne co) · vysvětlení cizího diffu před review · řešení konfliktu (AI vysvětlí obě větve, rozhoduje člověk) · git log jako zdroj kontextu („co se s tímhle souborem dělo").
8. Bezpečnost generovaného kódu — konkrétně k vašemu stacku.

• PHP 8 + MySQL: dotaz skládaný z proměnných = SQL injection. AI to občas vygeneruje, protože je to kratší. Vždy PDO s prepared statements (mysqli jen jako starší varianta). Ve VB.NET nad MS SQL totéž: SqlCommand s parametry, nikdy řetězec. Když se do gitu jednou dostanou, nestačí smazat commit — heslo se mění. vydání, počet stažení. Nepřidávat závislost kvůli pěti řádkům. Před nasazením EXPLAIN, index, LIMIT; hromadné zápisy dávkově a v transakci.
  • Tajemství v kódu: přístup k DB, API klíč, heslo k SMTP patří do konfigurace mimo repozitář.
  • Vstup z PDF a CSV Věstníku je taky vstup: nedůvěřovat délce, znakům ani formátu data.
  • Závislosti: AI navrhne balíček (Composer, NuGet), který neexistuje nebo je roky opuštěný. Ověřit stáří,
  • Miliony řádků v EviNoru: AI navrhne dotaz, který na cvičné tabulce proběhne a na produkci se zasekne.
  • Kód generovaný s daty zákazníka v promptu znamená, že data odešla. Pravidlo z M2 platí i v IDE.

1. Návaznost na Věstník: co když se změní formát PDF. Testovací sada 10 starších čísel z archivu (1998→2026) · kontrola úplnosti (počty vydaných / změněných / zrušených proti hlavičce oddílu) · hlášení „nesedí struktura" místo tichého selhání · logování: co se zpracovalo, kdy, kolik položek, co se přeskočilo a proč. Prázdná tabulka v EviNoru bez hlášky je horší než pád — pád si všimnete. (viz materialy/vestnik-pipeline.md, řádek D10)

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

A1 · Rozbitý skript (blok 2). Dostaneš Apps Script nad cvičnou evidencí norem, ve kterém je 5 chyb: překlep v názvu metody · špatný index sloupce (data se zapisují o jeden vedle) · porovnání textu s číslem u data · neošetřený prázdný řádek, na kterém skript spadne uprostřed · a jedna hláška, která ukazuje na úplně jiné místo, než kde je příčina.

Postup u každé chyby: spustit → přečíst celou hlášku → poslat AI (Gemini nebo AI Studio) hlášku i kód → opravit → napsat vlastními slovy, co byla příčina. Vlastními slovy, ne zkopírovaným vysvětlením od AI — to je ten rozdíl mezi „mám to opravené" a „umím to opravit".

Šestá chyba pro rychlé. Kdo doběhne, dostane chybu, která nespadne — skript proběhne, tváří se spokojeně a tiše počítá špatně (posunuté datum o měsíc). Tu je potřeba najít porovnáním výsledku s tím, co má vyjít. Tohle je nejnebezpečnější druh chyby a pointa celého dne.

A2 · README k automatizaci (blok 3). K automatizaci, kterou sis postavil ve dni 4, napíšeš README: co to dělá · kdo to spouští · jaké vstupy to čeká · co dělat, když to spadne · kdo je vlastník · kdy to bylo naposledy ověřeno. Draft napíše AI ze skriptu, ty doplníš to, co ze skriptu nejde vyčíst: proč to vzniklo, kdo o tom rozhoduje, komu volat.

Výstup A: opravený a běžící skript · pět příčin popsaných vlastními slovy · README k vlastní automatizaci.

Varianta B — terminál / IDE (programátoři)

Nástroje: Gemini CLI v terminálu (zdarma, Google účet) a Gemini Code Assist for individuals nebo GitHub Copilot Free v IDE. Vždy nad testovací kopií databáze (MySQL u EviNoru a e-shopu, MS SQL u Kovy/EviZak) — nikdy produkce.

B1 · Reálná chyba (blok 2). Vezmeš chybu, kterou jsi přinesl. Do ladeni.md zapíšeš: hláška → hypotéza → čím jsem ji potvrdil (log, výpis proměnné, SQL dotaz nad testovací kopií) → oprava → jak vím, že je pryč. Pravidlo dne: dokud nemám důkaz, neopravuju. Když AI navrhne opravu, nejdřív se ptám: „jaká je příčina a ze kterého řádku to plyne?"

B2 · Testy k funkci ze dne 9 (blok 2). K parseru položky Věstníku / importu do EviNoru / kontrolnímu SQL reportu napiš 3–5 testů (PHPUnit; kdo pracuje v Kovy/EviZak, MSTest/NUnit ve VB.NET): typický vstup · hraniční případy (chybějící datum, dlouhý název, diakritika, prázdný řádek) · regresní test k chybě, kterou jsi právě opravil. Pak jeden test schválně rozbij změnou v kódu a ověř, že spadne.

Test, který nespadne, ani když funkci pokazíš, nic nehlídá. Tohle ověření zabere minutu a ušetří falešný pocit jistoty.

B3 · Refaktoring legacy z včerejška (blok 3). Modul, který ti AI včera vysvětlila (PHP v EviNoru / e-shopu, nebo VB v Kovy / EviZak): nejdřív charakterizační test na současné chování (i to divné), pak jedna malá změna — pojmenovat magickou konstantu, vytáhnout výpočet do funkce, odstranit mrtvou větev. Test musí projít stejně. Commit: zprávu vygeneruje AI z diffu, ty ji přečteš a opravíš — a pokud je věcně špatně, ukážeš to skupině.

B4 · Review a bezpečnost (blok 3). Pusť AI review (Gemini Code Assist / Copilot Free, nebo Gemini CLI) na vlastní PHP soubor, který sahá do MySQL: najdi skládaný dotaz a přepiš ho na PDO prepared statement (ve VB.NET: SqlCommand s parametry). Projdi repozitář na přístupové údaje v kódu a historii. U dotazu nad velkou tabulkou EviNoru spusť EXPLAIN a ověř, že jede přes index. Nakonec tým společně napíše checklist „než mergnu AI kód" (5–7 bodů) — do cvičného repozitáře, aby se používal i po kurzu.

B5 · Věstník: co když se změní PDF (blok 3). Do importu do EviNoru (PHP/MySQL) z včerejška přidej kontrolu struktury: když se nenajde očekávaný oddíl nebo počty položek nesedí proti hlavičce, skončit hlášením a zápisem do logu, ne prázdnou tabulkou. Test spusť nad starším číslem Věstníku (např. 2019) i nad aktuálním a porovnej.

Výstup B: ladeni.md s doloženou opravou · 3–5 testů včetně regresního · zrefaktorovaný modul s charakterizačním testem · týmový checklist pro review · import Věstníku, který při změně formátu srozumitelně zahlásí problém.

Dílna (blok 4) — ladění a review na vlastní agendě

• Cesta A · Review vlastní automatizace z dne 4. Nech AI (Gemini / AI Studio) vyjmenovat hraniční případy, na kterých tvůj skript může selhat (prázdný řádek, diakritika v názvu normy, chybějící datum, jiný formát čísla). Jeden ověř spuštěním, přidej kontrolu a hlášení do logu místo tichého selhání. Hotový výstup: skript s jednou novou kontrolou a řádek v README „co se hlídá".
• Cesta A · Sedmá chyba (kdo má hotovo). Skript, který funguje správně na testovacích datech a špatně na datech s diakritikou v názvu normy. Hotový výstup: příčina vlastními slovy + oprava.
• Cesta B · git log a konflikt vysvětlený AI. Reálný konflikt ze cvičného repozitáře: Gemini CLI vysvětlí obě větve a git log k souboru, rozhoduješ ty. Hotový výstup: vyřešený konflikt s commit zprávou, ve které je napsané proč.
• Cesta B · Druhý charakterizační test (kdo pracuje v Kovy / EviZak). Druhý test na legacy modul ve VB.NET (MSTest/NUnit) se píše třikrát rychleji než první — teprve tím se to naučíš. Hotový výstup: test, který prošel a spadl, když jsi modul pokazil.

Technické předpoklady dne

• Rozbitý Apps Script s 5 + 1 chybou a cvičný Sheet — připraví lektor, sdílené na Drive kurzu
• Vlastní automatizace z dne 4 (cesta A) a vlastní funkce ze dne 9 (cesta B)
• Cvičný repozitář na GitHubu · přístup pro účty firmy · VS Code s Gemini Code Assist for individuals (zdarma) nebo GitHub Copilot Free · Gemini CLI v terminálu (npm i -g @google/gemini-cli, přihlášení Google účtem) · Visual Studio pro VB.NET · nebo GitHub Codespaces
• Testovací nástroj podle jazyka: PHPUnit (PHP 8) · MSTest/NUnit (VB.NET) · kontrolní dotazy nad MySQL 8 / MS SQL; u kohokoli s instalací přes IT jede vše v Codespaces
• Testovací kopie MySQL databáze (EviNor) — nikdy produkce; cesta A bez instalace: Adminer nad cvičnou MySQL databází lektora (jen pro čtení, odkaz na Drive kurzu)
• Chat pro cestu A: gemini.google.com (Gemini, zdarma s Google účtem) nebo aistudio.google.com (AI Studio)
• Ukázka lektora v Claude Code — jen na obrazovce lektora, žádné cvičení na ní nezávisí
• 10 starších čísel Věstníku ÚNMZ v PDF (1998→2026) jako testovací sada — veřejná data
• Chyby přinesené účastníky bez jmen, e-mailů a čísel zákazníků — přemazat před vložením do AI
• Druhý monitor (má každý)

Mini-úkol na příště

• Všichni: sepiš 5 kroků, které dnes při zpracování Věstníku (nebo své opakované agendy) děláš ručně — tak přesně, aby to podle tvého popisu zvládl někdo, kdo to nikdy nedělal. Kde bereš vstup · co s ním děláš · komu to předáváš · co musíš vždycky zkontrolovat, než to pustíš dál. Zítra z toho stavíme agenta.
• Cesta A: k popisu přidej jednu větu „tady se to nejčastěji zasekne".
• Cesta B: připrav svou funkci a testy ze dneška tak, aby je šlo zítra spustit z jednoho příkazu (vendor/bin/phpunit nebo dotnet test).

Cíl dne

Účastník rozumí, čím se agent liší od chatu, a má vlastního agenta nad Věstníkem ÚNMZ běžícího v testovacím režimu (spustí se sám, připraví přehled, nic neodešle ani nezapíše do produkčního EviNoru) a k němu seznam pěti rizik s konkrétním opatřením právě pro tohoto agenta.

Úvodní cvičení dne (15 min)

Cíl: ověřit, zda model ze stručného zadání sestaví úplnou specifikaci role agenta (vstupy, výstupy, oprávnění, kdy se ptá člověka) — a zjistit, kde sám navrhne víc oprávnění, než úloha vyžaduje.

Specifikace role „Agent Věstníkář". Zadej modelu, aby sepsal specifikaci agenta, kterého dnes postavíme: název role, vstupy (co dostává), výstupy (co odevzdává), oprávnění (které nástroje smí použít) a kdy se má zastavit a zeptat člověka. Povinná je poslední sekce „Co agent NESMÍ" — minimálně tři body. Tři specifikace přečteme nahlas a porovnáme: která má nejúplnější sekci „nesmí" a která obsahuje oprávnění, jež agent k práci vůbec nepotřebuje (typicky „odesílat zákazníkům", „zapisovat do evidence", „mazat").

Pointa: Agent = cíl + nástroje + oprávnění + hranice. Sekce „co agent nesmí" je ta část specifikace, ze které se za dvě hodiny stane konfigurace našeho agenta — a je stejně důležitá jako popis práce.

Témata (osnova)

• Chat vs. agent. Chat odpoví. Agent má cíl, sadu nástrojů, dělá kroky za sebou, sám si ověřuje mezivýsledek — a zastaví se u rozhodnutí, které patří člověku. Kde je hranice mezi „chytrým skriptem" a agentem a proč na tom u nás záleží.
• MCP (Model Context Protocol). Standard, kterým se agent připojuje k firemním systémům a datům: server nabídne nástroje (čti tabulku norem v testovací kopii EviNoru, najdi PDF ve složce, otevři repozitář), model je používá. Proč se začíná read-only a proč je „přístup do produkce" poslední, ne první krok. Nástroj kurzu je Gemini CLI (zdarma s Google účtem, MCP servery se připojují v settings.json); Claude Code / Codex uvidíš jen na obrazovce lektora — princip je stejný.
• Architektura agenta nad Věstníkem (skládá se ze všeho, co už umíme): spouštěč → stažení nového čísla → extrakce (D7) → diff proti minulému číslu → párování s EviNorem a seřazení podle významu pro naše zákazníky (D5, D6) → zápis „ke schválení" (Google tabulka, nebo tabulka v testovací MySQL) → přehled + protokol kontroly → předložení ke schválení. Agent nikam nic neodesílá.
• Hybridní architektura (navazuje na D8): Věstník je veřejné PDF z webu ÚNMZ → smí do cloudu. EviNor (PHP/MySQL) a data zákazníků → zůstávají lokálně na vlastním Linux serveru. Rozhraní mezi nimi je jediné místo, které hlídáme.
• Ošetření chyb z D10 uvnitř agenta: co dělá, když se změní formát PDF, když stránka nejede, když model vrátí nesmysl. Agent musí umět říct „nesedí to" — mlčet je horší než spadnout.
• Nejčastější chyby a rizika agentů (blok Metis 8): agent, který jedná bez schválení · prompt injection přes zpracovávaná data · tiché selhání · náklady, které utečou · agent bez logu.
• Pravidlo kurzu — dnes naposledy a nejsilněji: poslední krok před odesláním ven dělá vždy člověk. U firmy, která zákazníkům garantuje platnost norem, není „skoro správně" použitelný výsledek.

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

Cíl: odejít s vlastním běžícím robotem. Nic se neinstaluje, vše je Apps Script + Gemini API (klíč z Google AI Studia, zdarma s Google účtem).

1. Ve svém Drive kurzu založ tabulku „Věstník — ke schválení" se sloupci: třídicí znak · označení ČSN · název · typ změny (vydaná/změněná/zrušená) · datum · strana PDF · obor · dotčení zákazníci (počet) · stav.
2. V editoru Apps Scriptu (Rozšíření → Apps Script) vytvoř funkci, která stáhne nové číslo Věstníku z normservis.cz/download/vestnik/vestYYMM.pdf (UrlFetchApp) — v testu použij vest2609.pdf.
3. Text pošli do Gemini API s promptem z dnů 2 a 7 (strukturovaný výstup, pevná pole, u každé položky číslo strany PDF). Nic se nedogeneruje — co není v PDF, do tabulky nepatří.
4. Zapiš do tabulky se stav = ke schválení.
5. Diff: porovnej s listem minulého měsíce → co je nové, co se změnilo, co bylo zrušeno.
6. Seřazení podle významu: doplň sloupec obor a spoj s anonymizovaným vzorkem evidence norem z EviNoru (den 5) → nahoře skončí to, co se týká nejvíc zákazníků, ne to, co je v PDF první.
7. Nastav časový spouštěč (Aktivační události → časová, 1× měsíčně; pro dnešní test 1× za hodinu).
8. Agent na závěr pošle e-mail vlastníkovi s odkazem na tabulku a větou: „Přehled je připraven ke schválení. Nic nebylo odesláno ani naimportováno." Adresát je vždy někdo z firmy — nikdy zákazník.
9. Test naostro na starším čísle: zkontroluj 10 % položek proti originálu PDF a zapiš protokol kontroly (kolik sedělo, co ne).

Když v tech-checku vyjde, že Apps Script nemáš povolený: pracuješ ve sdíleném projektu kurzu a měníš v něm jen svou konfiguraci (obory, adresát, tabulka). Odcházíš pořád s běžícím agentem nad svou tabulkou — jen nehostovaným u sebe.

Hotový výstup varianty A: agent se spustí sám, naplní tabulku, pošle upozornění ke schválení.

Varianta B — terminál / IDE (programátoři)

Navazuje na repozitář z dnů 9 a 10 (import Věstníku do EviNoru — PHP 8 + MySQL, testy).

1. Spusť Gemini CLI v adresáři repozitáře (npm i -g @google/gemini-cli, přihlášení Google účtem — bezplatná kvóta stačí na celý den). Claude Code / Codex uvidíš jen na obrazovce lektora; postup je stejný.
2. Plán napřed: zadání dej jako cíl, ne jako příkaz. Agent napíše plán kroků → plán schválíš ty → teprve potom sahá na kód. (Plán se upřesňuje, nepřebírá se slepě — stejně jako každý výstup modelu od dne 1.)
3. Připoj vlastní data přes MCP: server nad testovací kopií EviNoru (MySQL 8, účet jen pro čtení) a nad složkou s PDF Věstníků; v Gemini CLI přes settings.json → mcpServers. Produkční EviNor, e-shop na platformě nody.cz i vlastní účetní systém zůstávají mimo dosah.
4. Nech agenta projet celý tok: extrakce → párování s EviNorem (tabulka má miliony řádků: index na označení normy, LIMIT, EXPLAIN před každým novým dotazem) → zápis do tabulky vestnik_ke_schvaleni v testovací MySQL přes PHP import z dne 9 (PDO, prepared statements, transakce) → přehled → protokol kontroly.
5. Testy z dne 10 pouští agent sám, review děláš ty. Commit + PR na GitHub, v popisu PR co dělal agent a co jsi změnil ručně.
6. Log: každý běh zapisuje vstup, kroky, počet zpracovaných položek, spotřebu (tokeny / požadavky z kvóty) a co přeskočil. Bez logu se agent zítra nedá obhájit.
7. Limity: seznam povolených nástrojů, zákaz zápisu do produkce (MySQL účet agenta existuje jen v testovací databázi), strop na počet kroků a na rozpočet běhu.

Varianta pro Kovy / EviZak (VB, MS SQL): stejný tok, MCP server nad testovací kopií MS SQL (účet jen pro čtení), zápis „ke schválení" přes VB.NET do testovací databáze. Princip se nemění.

Hotový výstup varianty B: agent běžící nad testovacími daty, PR s výsledkem, log běhu.

Dílna (blok 4) — agent na vlastní agendě

• Cesta A — vlastní konfigurace: přepni agenta na svou agendu — vlastní obory a zákazníky ve sloupci obor, adresát = ty; v tabulce „ke schválení" nastav podmíněné formátování (zeleně, co prošlo kontrolou počtů, červeně zbytek). Hotový výstup: tabulka, ze které schvalovatel vidí, kam se dívat.
• Všichni — změření úspory: kolik minut trvá jedno číslo Věstníku ručně a kolik agentem (z logu). Hotový výstup: dvě čísla; zítra z nich bude řádek plánu na 90 dní.
• Cesta B — vlastní MCP nástroj: read-only nástroj nad druhou tabulkou testovací kopie EviNoru (označení normy → počet dotčených zákazníků), v PHP nebo Node; tabulka má miliony řádků, takže index, LIMIT a EXPLAIN. Agent ho použije v témže běhu. Hotový výstup: nástroj v seznamu MCP + jeden běh agenta, který ho zavolal.
• Cesta B — rozšíření: totéž nad testovací kopií MS SQL (Kovy / EviZak), pokud máš prostředí.

Společný výstup dne — seznam rizik s opatřeními (obě varianty)

Každý vyplní pro svého agenta:

Technické předpoklady dne

• Varianta A: prohlížeč · Google účet kurzu · Apps Script (ověřeno v tech-checku) · API klíč z Google AI Studia (zdarma s Google účtem, bezplatná kvóta stačí na cvičení; záložní klíč z druhého účtu ve složce kurzu) · sdílená tabulka a listy z dne 7 · 2 čísla Věstníku ve složce kurzu.
• Varianta B: terminál · Node (pro Gemini CLI) a PHP 8 · Git a přístup na GitHub · repozitář ze dnů 9–10 · Gemini CLI (zdarma, přihlášení Google účtem) · MCP server nad testovací kopií EviNoru (MySQL 8, účet jen pro čtení) · testovací MySQL databáze pro zápis „ke schválení" · Adminer pro kontrolu tabulek (odkaz na Drive kurzu).
• Druhý monitor: vlevo výklad, vpravo běžící agent — dnes se to vyplatí nejvíc.
• Nic z toho se nespouští nad produkčním EviNorem, e-shopem ani nad daty zákazníků.

Mini-úkol na příště

• Nech svého agenta běžet v testu do zítřka (spouštěč po hodině nad starším číslem Věstníku). Zítra přines: log jednoho běhu a jednu věc, která nevyšla.
• Zkus svého agenta „nachytat": vlož do testovacího textu větu, která ho má odklonit od zadání, a podívej se, jestli se chytí.
• Vyber si jednu svoji AI chybu z celého kurzu — zítra na ni píšeme recenzi 1/5.

Cíl dne

Účastník má katalog chyb s opatřeními, provozní list ke každé automatizaci, kterou si v kurzu postavil, plán na 90 dní se jmény a termíny — a složený závěrečný test (podklad pro MPSV).

Úvodní cvičení dne (15 min)

Cíl: ověřit, že účastník umí u vlastní chyby z práce s AI pojmenovat příčinu, dopad a kontrolní krok — tedy převést zkušenost z kurzu na hotovou položku katalogu chyb.

Strukturovaný rozbor vlastní chyby z kurzu. Každý vybere jednu chybu, ke které za jedenáct dnů došlo při práci s AI (vlastní nebo pozorovanou u kolegy), a zapíše ji (s AI nebo bez) ve třech řádcích: příčina · dopad · kontrola, která by ji zachytila. Např.: „Model s jistotou nabídl číslo normy, které neexistuje. Příčina: generuje pravděpodobný text, ne záznam z evidence. Dopad: chybné označení v odpovědi zákazníkovi. Kontrola: označení normy se vždy opisuje z Věstníku, nikdy negeneruje." Čtení je dobrovolné; skupina hlasuje o rozboru s nejpřesněji formulovanou kontrolou.

Pointa: Chyba popsaná s příčinou a kontrolou je hotová položka katalogu. Z těchto rozborů za chvíli složíme katalog chyb — a je náš, z vlastní práce, ne stažený z internetu.

Témata (osnova)

• Katalog chyb — vlastní i typové: přijetí výstupu bez kontroly · obecné zadání („napiš mi něco o normách") · citlivá data ven · automatizace nepopsaného procesu · spoléhání mimo vlastní kompetenci (nechám si poradit tam, kde neumím posoudit odpověď) · opačný extrém — dělat ručně to, co AI zvládne · shadow AI (lidé si tiše nosí vlastní nástroje, protože firemní pravidlo neexistuje nebo překáží) · automatizace bez vlastníka.
• Chyby, které jsou nebezpečné právě u normalizační firmy: 1. vydat zákazníkovi informaci o platnosti normy bez ověření proti zdroji; 2. převzít číslo nebo označení normy vygenerované modelem místo opsaného z Věstníku; 3. automatizovaný text, který slibuje víc, než norma říká (výklad místo citace). Ke každé konkrétní opatření — ne „být opatrný", ale kdo co kontroluje a proti čemu.
• Provoz: každá automatizace z kurzu dostane provozní list — vlastník · co dělá · jak se pozná, že funguje · co dělat při selhání · kdy se reviduje. Bez listu není automatizace hotová, jen spuštěná.
• Plán na 90 dní: 3–5 kroků, u každého jméno a termín, měřitelný přínos. Kdo je ve firmě „správce AI" — člověk, na kterého se lidé obrátí a který hlídá pravidla i účty.
• Jak sledovat obor, aby znalosti nezastaraly — co číst, co ignorovat, jak si každé čtvrtletí vyhradit dvě hodiny na „co je nového a týká se nás to?".
• AI Act stručně a věcně — co z něj plyne pro firmu naší velikosti a role.
• Závěrečný test (90 min) — 25 otázek napříč kurzem, podklad pro dotaci MPSV.
• Zpětná vazba, předání materiálů, „Nález kurzu" (hlasování napříč dvanácti dny).

Harmonogram

Cvičení

Varianta A — jen prohlížeč (všichni)

1. Katalog chyb (společný dokument kurzu). Každý vloží alespoň dvě chyby: jednu vlastní z kurzu, jednu z typového seznamu, která mu sedí na agendu. Formát řádku: co se stalo · jak jsme to poznali · co uděláme, aby se to neopakovalo · kdo to hlídá. Techničtí pracovníci a obchod plní hlavně část „odpovědi zákazníkům", programátoři část „kód a data".

2. Provozní list ke každé své automatizaci (šablona ve složce kurzu). Vyplní se pro to, co si kdo v kurzu postavil — např. Gem „Věstník asistent" (D3), šablony odpovědí zákazníkům (D4), znalostní báze v NotebookLM (D6), extrakce Věstníku (D7), agent v Gemini CLI (D11):

3. Plán na 90 dní (sdílená tabulka, dokončit společně): 3–5 kroků, u každého vlastník, termín a měřitelný přínos. Vzor, ze kterého se vychází a který si firma upraví:

Hotový výstup varianty A: vyplněný provozní list ke každé vlastní automatizaci + řádek v plánu na 90 dní, ke kterému se člověk sám přihlásil.

Varianta B — terminál / IDE (programátoři)

1. Runbook do repozitáře (docs/PROVOZ.md): co dělat, když agent nebo import do EviNoru selže — jak poznat tiché selhání, kde je log, jak spustit ručně, co se nesmí pouštět nad produkční MySQL.
2. Checklist pro AI-asistovaný vývoj (docs/AI-REVIEW.md, do repozitáře na GitHub): co se nikdy necommituje (klíče, přístupy k databázi, data zákazníků), co musí projít testy, kdo dělá review kódu, který napsal model, a pravidlo „vibe coding ano — merge bez review ne".
3. Monitoring kvót a nákladů: firma nemá placenou AI — kde se sleduje spotřeba agenta v bezplatné vrstvě (Gemini CLI, AI Studio), co se stane při vyčerpání denní kvóty (přepnout na AI Studio / druhý účet, nikdy nezůstat bez výstupu), kdo rozhodne o případném placeném stropu a kdo dostane upozornění.
4. Legacy Kovy / EviZak nebo vlastní účetní systém: vyber jeden modul (VB6/VB.NET nad MS SQL), ke kterému dnes nikdo nemá dokumentaci, a nech AI vygenerovat popis do repozitáře — první splátka technického dluhu, která se dá udělat i příští týden bez povolení navíc.

Hotový výstup varianty B: dva soubory v repozitáři a zapsané pravidlo pro kvóty a náklady.

Dílna (blok 4) — vyhodnocení a plán na 90 dní na vlastní agendě

• Vyhodnocení testu individuálně: kdo si u některé otázky nebyl jistý, projde ji s lektorem (druhá místnost); ostatní pracují na vlastní agendě. Výstup: žádná otázka testu nezůstává nevysvětlená.
• Nacenění úspory (všichni, 15 min): číslo naměřené ve dni 11 (jedno číslo Věstníku ručně vs. agentem) přepočítané na měsíc a rok. Výstup: jeden řádek v plánu na 90 dní s číslem, kterému vedení věří.
• Cesta A — druhý provozní list na vlastní agendě: k šablonám odpovědí zákazníkům ze dne 4 (nebo k jiné vlastní automatizaci). Druhý list se píše třikrát rychleji než první a teprve tím se to naučí. Výstup: dva vyplněné provozní listy se jménem vlastníka.
• Cesta B — rozšiřující zadání: legacy modul Kovy / EviZak (VB6/VB.NET, MS SQL) bez dokumentace → AI vygeneruje popis, commit do repozitáře; s vedením u toho rozhodnout monitoring kvót a nákladů (bezplatná vrstva, co při vyčerpání, kdo rozhodne o placeném stropu). Výstup: soubor v repozitáři a zapsané rozhodnutí o kvótách.

Hotový výstup Dílny: plán na 90 dní s jménem a termínem u každého řádku, o jeden provozní list víc a (cesta B) první vygenerovaná dokumentace k legacy modulu.

Závěrečný test (90 min)

Jak proběhne

• 25 otázek složených z kvízů dnů 1–11, minimálně jedna z každého dne; výběr z možností (a–d), jedna správná.
• Okamžitá zpětná vazba s vysvětlením po každé odpovědi — test je zároveň poslední opakování.
• Bez přihlašování — odkaz ze složky kurzu, jméno se vyplní do políčka (kvůli evidenci).
• Čas: 12:00–13:30 — ~45 minut na test, zbytek na společný rozbor otázek, ve kterých se nejvíc chybovalo; kdo chce, projde otázky s lektorem individuálně v Dílně.
• Test je znalostní, ne vyřazovací. Výsledky jsou podkladem pro závěrečnou zprávu a evidenci dotace (MPSV); kdo si nebude jistý, projde otázky na místě s lektorem.

Vzorové otázky napříč kurzem (ukázka, celkem jich bude 25)

1. (D1) Proč model odpoví číslem ČSN, které neexistuje?

• a) Má zastaralou databázi norem > Vysvětlení: Model skládá text, ne rešerši. U čísel, dat a označení norem proto platí: opsat ze zdroje, nikdy negenerovat.
  • b) Generuje pravděpodobné pokračování textu, ne záznam z evidence ✅
  • c) Je vadný a je třeba ho vyměnit
  • d) Chybí mu připojení k ÚNMZ

1. (D2) Které zadání dá použitelnější výsledek?

• a) „Napiš něco o nové normě." > Vysvětlení: Role, kontext, úkol, formát a hranice — čtyři věty navíc ušetří dvě kola oprav.
  • b) „Jsi technický pracovník Normservisu. Z tohoto odstavce Věstníku vypiš označení, název, typ změny a datum. Co v textu není, nedoplňuj." ✅
  • c) „Zkus to nějak hezky."
  • d) „Napiš to co nejdelší."

1. (D5) AI vygenerovala SQL s DELETE bez WHERE. Co teď?

• a) Spustit a doufat > Vysvětlení: Model nemá zpětnou vazbu z produkce — tu má člověk. Destruktivní dotaz se testuje na kopii, vždy; nad tabulkou s miliony řádků v EviNoru dvojnásob.
  • b) Nespouštět, doplnit a zkontrolovat podmínku, vyzkoušet na testovací kopii MySQL ✅
  • c) Přejmenovat tabulku, ať to nenajde
  • d) Zeptat se AI, jestli si je jistá

1. (D7) Jak poznáte, že extrakce Věstníku proběhla úplně?

• a) Skript nespadl > Vysvětlení: „Nespadlo to" není kontrola. Kontrola je číslo proti číslu a deset položek proti originálu.
  • b) Porovnáním počtů s očekávaným rozsahem čísla a namátkovou kontrolou položek proti PDF ✅
  • c) Výsledek vypadá dobře
  • d) Tabulka má hodně řádků

1. (D10) AI napsala funkci importu do EviNoru, testy prošly. Co následuje?

• a) Nasadit do produkce > Vysvětlení: Zelené testy říkají, že prošlo to, co jsme napsali — ne že jsme napsali to správné.
  • b) Review člověkem, který rozumí tomu, co kód dělá, a doplnění testu na chybný vstup ✅
  • c) Nechat AI napsat další funkci
  • d) Smazat testy, zdržují

1. (D11) Agent připraví přehled nových norem. Kdo ho pošle zákazníkovi?

• a) Agent, hned po dokončení > Vysvětlení: Poslední krok před odesláním ven dělá vždy člověk. U garance platnosti norem je „skoro správně" horší než pozdě.
  • b) Agent, pokud si je jistý
  • c) Člověk, po schválení obsahu ✅
  • d) Nikdo, přehled se jen archivuje

Technické předpoklady dne

• Prohlížeč, sdílená složka kurzu (katalog chyb, šablona provozního listu, tabulka plánu na 90 dní).
• Testovací aplikace pro závěrečný test (záloha: Google Forms s okamžitou zpětnou vazbou).
• Gemini (gemini.google.com, zdarma s Google účtem) nebo AI Studio (aistudio.google.com) pro rozbor chyby a nacenění úspory — bez placené licence.
• Programátoři: přístup do repozitáře na GitHubu (commit runbooku a checklistu), Gemini CLI z předchozích dnů pro dokumentaci legacy modulu.
• Nic se dnes neinstaluje.

Co si účastníci odnášejí

Dvanáct dnů, dvanáct hmatatelných výstupů. Nic z toho není slide.

A jedno pravidlo, které platí u všeho výše: poslední krok před odesláním ven dělá vždy člověk.