Průvodce modely Claude od Anthropic

Úvod

Anthropic je americká firma, která se zabývá vývojem bezpečné AI - jejich hlavní produkt je rodina jazykových modelů Claude, v současnosti jedny z nejpokročilejších AI asistentů na trhu, které mají tři hlavní úrovně: Opus, Sonnet a Haiku. Když jsem poprvé začal s těmito modely pracovat, upřímně jsem nevěděl který kdy použít - všechny vypadaly podobně, ale rozdíly v kvalitě výstupu a ceně byly obrovské. V tomhle článku si projdeme co který model umí, kdy ho použít a proč, a sdílím zkušenosti z reálných projektů kde jsem každý z nich testoval.

Architektura rodiny Claude

Anthropic postavil třístupňovou hierarchii modelů, kde každá úroveň má svoje místo:

Všechny modely používají Constitutional AI framework pro bezpečnost a mají kontextové okno 200 000 tokenů (zhruba 150 000 slov), což v praxi znamená že můžeš nahrát celou kódovou bázi menšího projektu nebo technickou knihu a model si pamatuje všechno. Novější verze Opus a Sonnet nabízejí experimentální podporu až 1 milion tokenů - zkoušel jsem to s kompletní dokumentací ESP-IDF frameworku a fungovalo to překvapivě dobře, i když latence byla znatelně vyšší.

Claude Opus — hluboký myslitel

Co je Opus?

Opus je top tier model od Anthropic - navržený pro úlohy kde potřebuješ hluboké analytické uvažování, komplexní vícekrokové plánování, pokročilé programování a refaktoring, nebo práci s rozsáhlými kontexty jako jsou celé knihy nebo velké kódové báze. Když jsem poprvé testoval Opus na code review komplexní Flask aplikace s asynchronními tasky a Celery workers, byl jsem fascinovaný tím, jak model dokázal propojit souvislosti mezi moduly které byly od sebe vzdálené stovky řádků kódu a identifikovat potenciální race condition, kterou jsem já sám přehlédl.

Kdy použít Opus?

Ideální scénáře:

1. Code review před nasazením — Opus zachytí subtilní chyby jako memory leaky, async bugy nebo chybějící dispose volání, které ostatní modely přehlédnou
2. Architektonická rozhodnutí — Při návrhu systémové architektury nebo rozsáhlém refaktoringu
3. Výzkum a analýza — Sumarizace celých knih, analýza právních dokumentů, finanční modelování
4. Agentické workflow — Dlouhodobé autonomní úlohy vyžadující vícekrokové uvažování

Praktický příklad

Scénář: Máš komplexní Flask aplikaci s 50+ soubory a potřebuješ identifikovat 
bezpečnostní zranitelnosti.

Proč Opus: Model dokáže udržet kontext celé aplikace, propojit souvislosti mezi 
moduly a identifikovat zranitelnosti typu race condition nebo injection attacks, 
které vyžadují pochopení toku dat napříč celým systémem.

Cena

Opus 4.5 přinesl výrazné zlevnění oproti předchozím verzím (Opus 4/4.1 stál $15/$75), což zpřístupnilo prémiovou inteligenci širšímu spektru uživatelů - upřímně, při těch starých cenách jsem Opus používal jen na kritické review před nasazením do produkce, protože každý delší prompt stál dost peněz. Teď s novými cenami je to mnohem dostupnější, i když pořád ne na každodenní použití pokud máš omezený budget.

Claude Sonnet — spolehlivý kolega

Co je Sonnet?

Sonnet je vyvážený model - kombinuje vysokou inteligenci s rozumnou rychlostí a cenou, což z něj dělá ideální volbu pro většinu každodenní práce. Většina vývojářů tráví s tímhle modelem nejvíc času, a já nejsem výjimka - odhadem 80 % mých promptů jde na Sonnet, protože pro běžné programování, refaktoring nebo psaní dokumentace je naprosto dostačující a odpovídá rychle.

Kdy použít Sonnet?

Ideální scénáře:

1. Každodenní programování — Vývoj funkcí, práce s více soubory, správa stavu, připojení k API
2. Analýza a reporting — Strukturované analýzy, Q&A s dokumenty, vytváření reportů
3. Kreativní úlohy — Psaní obsahu, copywriting, technická dokumentace
4. Orchestrace agentů — Sonnet vytvoří plán a rozdělí úkoly pro Haiku instance

Praktický příklad

Scénář: Vyvíjíš React aplikaci s Tailwind CSS a potřebuješ implementovat
autentizaci s Firebase.

Proč Sonnet: Model zvládne multi-file logiku, správu stavu (Riverpod, Redux),
připojení k Firebase a generuje čistý, použitelný kód. Má vynikající výkon
v oblasti frontend/UI vývoje a generuje „pixel-perfect layouts".

Osobní zkušenost: Když jsem dělal redesign jednoho projektu s Flutter a Material 3,
Sonnet mi vygeneroval kompletní theme configuration včetně custom color schemes
a typography - kód fungoval na první pokus, což mě docela překvapilo protože
Material 3 API je dost komplexní a čekal jsem že budu muset něco ladit.

Cena

Sonnet nabízí výkon blížící se Opusu za zlomek ceny, což z něj dělá optimální volbu pro 90 % produkčních úloh - a tady je důležité si uvědomit že rozdíl mezi Sonnetem a Opusem není vždycky tak velký jak by se podle ceny mohlo zdát, takže pokud nejdeš do opravdu komplexních analýz nebo kritického code review, Sonnet ti bude stačit.

Claude Haiku — rychlý sprinter

Co je Haiku?

Haiku je nejrychlejší a nejlevnější model v rodině Claude - optimalizovaný pro minimální latenci (odpovědi pod sekundu), vysoký objem dotazů a nákladovou efektivitu. Upřímně, nejdřív jsem Haiku podceňoval a myslel si že je to jen "levná verze" pro lidi co chtějí ušetřit, ale když jsem ho začal používat na rychlé prototypování UI komponent, zjistil jsem že pro tento konkrétní use case je vlastně lepší než Sonnet - odpovídá skoro okamžitě a pro jednoduchý layout kód je kvalita naprosto dostačující.

Kdy použít Haiku?

Ideální scénáře:

1. Chatboti a zákaznická podpora — Real-time odpovědi bez čekání
2. UI prototypování — Rychlé generování layoutů a komponent
3. Klasifikace a moderace obsahu — Vysokoobjemové úlohy
4. Paralelní provádění subtasků — V orchestrovaném workflow s Sonnetem

Praktický příklad

Scénář: Potřebuješ rychle vytvořit Flutter screen s Material 3 designem.

Proč Haiku: Model vygeneruje layout téměř okamžitě. Pro brainstorming a rychlé
prototypy je ideální volbou. Ale pozor — v delších sessions „ztrácí nit"
a není vhodný pro komplexní logické stavby.

Osobní zkušenost: Zkoušel jsem s Haiku dělat složitější state management
s Riverpod providers a po třech čtyřech iteracích začal generovat kód který
nedával smysl - zapomínal na kontext z předchozích promptů a navrhoval řešení
která byla v rozporu s tím co jsme dělali předtím. Pro jednoduché úlohy super,
ale na komplexní logiku radši Sonnet.

Cena

Haiku je 5× levnější než Opus na vstupních tokenech, což z něj dělá ekonomickou volbu pro vysokoobjemové scénáře - pokud děláš chatbota nebo zákaznickou podporu kde potřebuješ zpracovat tisíce dotazů denně, rozdíl v ceně mezi Haiku a Sonnetem se rychle nasčítá na stovky dolarů měsíčně.

Srovnávací tabulka modelů

Orchestrační workflow — jak modely kombinovat

Když pracuješ na větším projektu, dává smysl kombinovat modely podle jejich silných stránek - tohle je něco co jsem se naučil až po pár měsících práce s Claude, protože na začátku jsem používal jen Sonnet na všechno a nevěděl jsem že můžu ušetřit čas i peníze tím že rozdělím úlohy mezi modely strategicky.

Fáze 1: Plánování (Sonnet)

Sonnet analyzuje požadavky, navrhuje architekturu a rozděluje úkoly na paralelizovatelné podúlohy.

Fáze 2: Implementace (Haiku)

Více instancí Haiku provádí subtasky paralelně — scaffolding, komponenty, API integrace.

Fáze 3: Review (Opus)

Před mergem provede Opus hlubokou revizi — zachytí async bugy, memory leaky a subtilní logické chyby.

Příklad z praxe:

Developer pracuje na mobilní aplikaci:
1. Používá Haiku pro rychlé UI prototypy
2. Přepne na Sonnet pro implementaci business logiky
3. Před releasem nechá Opus udělat finální code review

Výsledek: Opus odhalil rebuild issues a chybějící disposes,
které Haiku i Sonnet přehlédly.

Moje zkušenost: Přesně tenhle workflow jsem použil na jednom Flutter projektu
kde jsem dělal aplikaci pro správu IoT zařízení. Haiku mi vygeneroval asi 15
různých screen layoutů za pár minut, Sonnet implementoval komunikaci s MQTT
brokerem a state management, a Opus pak při finálním review našel memory leak
v subscription handleru který by v produkci způsobil problémy - model si všiml
že StreamSubscription není správně disposed při dispose() widgetu, což by
vedlo k postupnému nárůstu paměti. Tohle by Sonnet pravděpodobně přehlédl.

Rozhodovací strom: Který model zvolit?

START
  │
  ├── Je úloha časově kritická (real-time)?
  │     └── ANO → HAIKU
  │
  ├── Je to rutinní práce (coding, analýza, psaní)?
  │     └── ANO → SONNET
  │
  ├── Vyžaduje hluboké uvažování nebo rozsáhlý kontext?
  │     └── ANO → OPUS
  │
  ├── Je to finální review před nasazením?
  │     └── ANO → OPUS
  │
  └── Nejste si jistí?
        └── Začněte se SONNET, eskalujte na OPUS při potřebě

Cenové předplatné pro běžné uživatele

Pro ty, kteří nepoužívají API, nabízí Anthropic předplatné:

Praktické tipy pro optimalizaci nákladů

1. Začni s Haiku, eskaluj nahoru

Pro většinu dotazů postačí Haiku - na Sonnet nebo Opus přepni pouze pro složitější úlohy, což ti ušetří peníze a zároveň nezpomalí workflow, protože Haiku odpovídá tak rychle že rozdíl v latenci je znatelný.

2. Využij Prompt Caching

Při opakovaném dotazování na stejný kontext (např. velký dokument) snížíš náklady až o 90 % - tohle je obrovská úspora pokud pracuješ s rozsáhlou kódovou bází nebo dokumentací, protože model si cachuje kontext a při dalších dotazech ho nemusí znovu zpracovávat. Zkoušel jsem to s dokumentací k ESP-IDF a rozdíl v ceně byl dramatický - první prompt stál normálně, ale následující dotazy byly skoro zadarmo.

3. Batch API pro neurgentní úlohy

Asynchronní zpracování přes Batch API poskytuje 50% slevu na tokeny.

4. Optimalizuj prompty

Každý token stojí peníze. Odstraň zbytečný kontext a buď konkrétní.

Závěr

Každý model v rodině Claude má svoje místo:

• Opus je senior architekt — pomalejší, ale nejspolehlivější pro kritické rozhodnutí a hluboké analýzy
• Sonnet je spolehlivý kolega — zvládne 90 % každodenní práce kvalitně a efektivně, což z něj dělá můj go-to model
• Haiku je rychlý junior — ideální pro opakované úlohy a prototypování, překvapivě schopný pokud víš jak ho použít

Nejde o to používat jeden model na všechno. Jde o to strategicky kombinovat jejich silné stránky podle toho, co zrovna potřebuješ - a tohle pochopení přišlo až s praxí, protože na začátku jsem dělal chybu že jsem používal Sonnet i na úlohy kde by Haiku stačil, nebo naopak jsem se snažil ušetřit a používal Sonnet na code review kde by Opus odvedl mnohem lepší práci. Teď po několika měsících práce s těmito modely mám docela dobrý cit kdy který použít, a doufám že tento článek ti pomůže zkrátit tu learning curve.

Zdroje a další čtení

• Anthropic dokumentace
• Claude.ai
• API cenový přehled

Pro opravu diakritiky a překlepů byl použit model Claude Sonnet 4.5.

Článek aktualizován: březen 2026

The post Průvodce modely Claude od Anthropic first appeared on Hard Wired.

Prompt Engineering: Umění komunikace s umělou inteligencí

Jak se naučit mluvit s AI tak, aby vás pochopila – zkušenosti z několika let práce s velkými jazykovými modely

Pamatuju si ještě doby, kdy jsem GPT-3 posílal prompty typu "Napiš článek o marketingu" a divil se, proč dostávám obecné floskule místo užitečného obsahu. Dnes vím, že problém nebyl v modelu, ale v tom, jak jsem s ním komunikoval. Za posledních několik let práce s LLM jsem se naučil, že prompt engineering není jen o tom napsat správnou instrukci – je to umění vytvářet most mezi lidským a strojovým myšlením.

Proč prompt engineering vůbec existuje?

Když poprvé otevřete ChatGPT, připadá vám to jednoduché: napíšete otázku, dostanete odpověď. Jenže rychle zjistíte, že mezi "funguje to" a "funguje to dobře" je propast. Velké jazykové modely jsou neskutečně mocné, ale jsou také nepředvídatelné. Stejný prompt může dnes vrátit brilantní analýzu a zítra povrchní kecy.

Tady vstupuje do hry prompt engineering. Není to jen technická disciplína – je to způsob, jak z nepředvídatelného nástroje udělat spolehlivého partnera. V podstatě učíte model myslet způsobem, který vám vyhovuje.

Z mé zkušenosti: čím komplexnější úkol chcete vyřešit, tím víc záleží na tom, jak prompty formulujete. Prostý dotaz může fungovat na hello world úrovni, ale když potřebuje model analyzovat data, psát kód nebo vytvářet konzistentní obsah, kvalita promptu rozhoduje o úspěchu či neúspěchu celého projektu.

Anatomie dobrého promptu

Základní stavební kameny

Kontext je základ všeho. Model potřebuje vědět, v jaké roli má vystupovat a jaký je cíl úkolu. Místo "Analyzuj tenhle text" napíšu "Jsi senior marketingový analytik. Analyzuj následující text z pohledu efektivity brand communication a identifikuj tři klíčové silné stránky a tři oblasti pro zlepšení."

Instrukce musí být specifické, ale ne rigidní. "Buď kreativní" je horší než "Navrhni tři nestandardní přístupy k řešení tohoto problému, z nichž alespoň jeden by měl být kontroverzní."

Formát výstupu určete předem. Pokud chcete strukturovanou odpověď, řekněte to: "Odpověz ve formátu: 1) Problém, 2) Příčina, 3) Řešení, 4) Timeline implementace."

Praktický příklad z praxe

Špatný prompt:

Napiš mi email zákazníkovi o zpoždění.

Dobrý prompt:

Jsi customer success manager v SaaS firmě. Napiš profesionální, ale lidský email zákazníkovi, který čeká na implementaci našeho systému již 3 týdny místo původně slíbených 2 týdnů. 

Kontext: Zpoždění vzniklo kvůli neočekávaným technickým komplikacím s integrací jejich legacy systémů.

Tón: Omluvný, ale sebevědomý. Ukáže accountability, ale nevyzní zoufalě.

Struktura:
1. Upřímná omluva
2. Vysvětlení příčiny (bez technických detailů)
3. Konkrétní nový timeline
4. Kompenzace/gesture of goodwill
5. Následující kroky

Délka: 150-200 slov.

Rozdíl je obrovský. První prompt vám dá generickou šablonu, druhý konkrétní, použitelný obsah.

Klíčové techniky a strategie

Zero-shot vs Few-shot Learning

Zero-shot znamená, že modelu dáte jen instrukci bez příkladů. Funguje dobře na standardní úkoly:

Přelož následující text do angličtiny: [text]

Few-shot přidává příklady. Používám ho, když chci specifický styl nebo formát:

Převeď následující data do JSON formátu podle tohoto vzoru:

Vstup: Jan Novák, 25 let, Praha
Výstup: {"name": "Jan Novák", "age": 25, "city": "Praha"}

Vstup: Marie Svobodová, 34 let, Brno
Výstup: {"name": "Marie Svobodová", "age": 34, "city": "Brno"}

Nyní převeď: [vaše data]

Chain-of-Thought (CoT) prompting

Tohle je můj nejčastější trik pro složité úkoly. Místo toho, abych chtěl rovnou výsledek, požádám model, aby mi ukázal své uvažování:

Rozhodni, zda by firma měla investovat do tohoto projektu. Postupuj takto:

1. Nejdříve shrň klíčové finanční ukazatele
2. Identifikuj hlavní rizika a příležitosti
3. Porovnej s alternativními investicemi
4. Udělej finální doporučení s odůvodněním

Projekt: [detaily projektu]

Model tím pádem nejen dá doporučení, ale ukáže vám, jak k němu došel. Často objevím chyby v logice nebo argumentech, které bych jinak přehlédl.

Role-playing: Nechte model hrát roli

Jeden z nejsilnějších přístupů. Model se dokáže "vcítit" do role a měnit svůj styl myšlení:

Jsi skeptický investor, který už viděl stovky pitch decků. Analyzuj tento business plán očima někoho, kdo hledá díry v argumentaci a slabá místa v modelu. Buď konstruktivně kritický.

Versus:

Jsi optimistický venture partner, který hledá next big thing. Identifikuj potenciál a příležitosti v tomto business plánu.

Stejný input, úplně jiný pohled. Často kombinujem několik rolí pro komplexnější analýzu.

Praktické tipy z několika let experimentování

1. Iterace je klíč

Prvotní prompt neíní skoro nikdy finální. Mám workflow: napíšu základní verzi, testuji na několika vzorcích, identifikuji slabiny, refactoruju. Někdy projdu 5-10 iterací, než jsem spokojený.

2. Testování na edge cases

Modely selhávají na okrajových případech. Vždy testuji prompt na:

• Extrémně krátký input
• Extrémně dlouhý input
• Nejednoznačný input
• Input s chybami/typos

3. Teplotní parametr je váš přítel

Pro kreativní úkoly nastavuji vyšší teplotu (0.7-0.9), pro analytické nižší (0.1-0.3). Dělá to obrovský rozdíl v konzistenci výstupů.

4. Deadline a omezení explicitně

Máš 5 minut na brainstorming. Rychle vygeneruj 10 nápadů na titul článku. Nekomplikuj to, jdi na první nápad.

Omezení často vedou k lepším výsledkům než nekonečná volnost.

5. Meta-prompting

Někdy požádám model, aby mi pomohl vylepšit můj vlastní prompt:

Analyzuj následující prompt a navrhni tři způsoby, jak ho vylepšit pro konzistentnější a kvalitnější výsledky: [můj prompt]

Často dostanu zajímavé náměty, na které bych sám nepřišel.

Časté pasti a jak se jim vyhnout

Over-engineering promptů

Nejčastější chyba začátečníků: napsat prompt na tři odstavce pro jednoduchý úkol. Někdy stačí prostě "Shrň to ve třech bodech."

Závisení se na jednom přístupu

Každý model reaguje jinak. Co funguje na GPT-5, nemusí fungovat na Claude. Co funguje na Claude, nemusí fungovat na Llama. Musíte adaptovat.

Ignorování kontextu předchozí konverzace

V dlouhých konverzacích model "zapomíná" začátek. Občas refreshuju klíčové informace: "Připomínám, že pracujeme na projektu pro retailového klienta s rozpočtem 50K měsíčně."

Příliš vágní metriky úspěchu

"Napiš dobrý článek" vs "Napiš článek, který bude mít 800-1200 slov, zaujme B2B manažery a bude obsahovat alespoň tři konkrétní příklady."

Budoucnost prompt engineeringu

Budu upřímný: prompt engineering se pravděpodobně zjednoduší. Modely jsou čím dál chytřejší v interpretaci našich záměrů. Ale to neznamená, že umění dobrého promptingu zmizí.

Vidím dvě hlavní vývojové linie:

1. Specializace na komplexní workflows
Jednoduché úkoly budou zvládat modely "out of the box". Hodnota bude v orchestraci složitých multi-step procesů, kde prompt engineering splývá s workflow engineeringem.

2. Domain-specific prompting
Čím víc se modely používají v specializovaných oblastech (lékařství, právo, finance), tím víc bude záležet na znalosti domény kombinované s prompting skills.

Jedna věc je jistá: schopnost efektivně komunikovat s AI zůstane klíčovou dovedností. Možná se změní nástroje a techniky, ale základní princip – umět překládat lidský záměr do jazyka, kterému AI rozumí – zůstane.

Co si odnést

Prompt engineering není magie, ale řemeslo. Vyžaduje trpělivost, experimentování a ochotu učit se z chyb. Moje hlavní doporučení:

1. Začněte jednoduše – složitost přidávejte postupně
2. Testujte systematicky – neřešte prompt, dokud nevíte, že nefunguje
3. Dokumentujte – vedlejte si knihovnu osvědčených promptů
4. Nebojte se iterací – prvotní verze je jen draft
5. Kombinujte techniky – few-shot + CoT + role-playing může být mocná kombinace

A především: prompt engineering je jen nástroj. Nejlepší prompt na světě nevyřeší špatně definovaný problém. Začněte vždycky tím, že si ujasníte, co vlastně chcete dosáhnout.

Po několika letech práce s LLM si myslím, že prompt engineering je můj nejcennější skill. Není to jen o technických triků – je to o tom naučit se myslet jinak, být precizní v komunikaci a převádět kreativní nápady do strukturované formy. A to je dovednost, která se hodí daleko za hranicemi AI.

The post Prompt Engineering: Umění komunikace s umělou inteligencí first appeared on Hard Wired.