Három modell, egy macska, nulla garancia

Egy teljes példa — context engineering a gyakorlatban

1. lépés — Kontextus betöltése, feladat előtt

Háttér: a párom nem akar macskát, mert attól tart, hogy egyedül fog gondoskodni róla, ő utazik a legtöbbet, és a lakásban nincs nagy tér. Én ezzel szemben régóta szeretnék egy macskát, ideálisan egy kisebb, alacsony mozgásigényű fajtát. Az eddigi próbálkozásaim érzelmi érveken alapultak, és nem vezettek sehova.

Feladat: segíts felkészülni erre a beszélgetésre.

2. lépés — A sorozat megtervezése

Mielőtt bármit írsz, tervezd meg, hogyan érdemes felépíteni ezt a megközelítést: milyen érvek működhetnek, milyen sorrendben, és mire kell figyelni, hogy ne legyen belőle vita. Csak a tervet írd le először.

3. lépés — Meta-prompt: az AI írja meg a saját instrukcióját

A fenti terv alapján írj egy optimális promptot ehhez a feladathoz — vedd figyelembe a párom konkrét kifogásait és a korábbi sikertelen próbálkozásokat —, majd futtasd le.

4. lépés — Reflection: önkritika és javítás

Kritizáld az előbb írt javaslatot: mi a három leggyengébb pontja? Mire reagálna a párom rosszul? Ezek alapján javítsd.

5. lépés — Leállási feltétel

Ismételd a kritika–javítás ciklust, amíg az önkritikád szerint nem marad érdemi gyenge pont. Jelezd, mikor tartod késznek.

Ez az öt lépés együtt mutatja a context engineering lényegét: nem egyetlen ügyes kérdés, hanem egy módszeresen felépített folyamat — amelyben a kontextus fokozatosan gazdagodik, és az eredmény minden körrel közelebb kerül ahhoz, ami valóban működik.

A különbség szemléltetéséhez érdemes egymás mellé tenni három eredményt: mit ad vissza egy naiv prompt, és mit ad ugyanaz a kérdés context engineering workflow-val — két különböző modellen is futtatva.

Naiv prompt — Gemini Flash

Bemenet: „Hogyan győzzem meg a párom, hogy vegyünk macskát?"

A válasz korrekt és alapos volt — de generikus. Táblázatban sorolta a leggyakoribb aggályokat és a hozzájuk tartozó standard érveket (szag, bútor, szőr, utazás), javasolta a macskás kávézót és az ideiglenes befogadást mint „titkos fegyvert", majd a végén visszakérdezett: „Melyik az az aggodalom, amit a leggyakrabban említ?" — mert nem volt kontextusa, amiből dolgozhatott.

Context engineering workflow — Gemini (Flash)

Az öt lépéses workflow és a beadott kontextus alapján a Gemini racionális garancia-alapú megközelítést dolgozott ki, amely technológiai és logisztikai megoldásokkal szereli le a három fő aggályt.

1. Az utazás és a függőség kérdése. Nem barátoktól vagy a partnertől várunk szívességet — előre felkutatott, fizetős macskaszitter szolgáltatást vonunk be a büdzsébe.

2. A munkamegosztás automatizálása. A felelősség egyértelműen a te oldalad, de a napi súrlódási pontokat technológia oldja meg: automata etető, zárt szagszűrős alom, beütemezett naptárbejegyzés.

3. A „Láthatatlan Macska" koncepció. Nem hiperaktív kismacskát, hanem egy nyugodt, 2-4 éves mentett macskát — aki napi 18 órát alszik. Fali polcokkal és kaparófákkal a macska „felfelé" terjeszkedik, nem vesz el életteret a padlóról.

4. Veszélytelen teszt. Nem ideiglenes befogadás (mert az érzelmi csapda lenne), hanem közös látogatás egy menhelyre vagy macskás kávézóba — nyomás nélkül, a saját bőrén tapasztalva.

Context engineering workflow — Claude (Fable 5)

A konkrét kontextus (három korábbi „nem", az utazási minta, a tér hiánya, az eddigi sikertelen érzelmi érvek) alapján a modell egy empátia- és vétójog-alapú stratégiát dolgozott ki:

1. Nyitás — validálás. Ismerd el, hogy a félelem reális, és mondd ki előre, hogy a „nem" is elfogadható végeredmény.

2. Az ő forgatókönyv-listája. Ne te írj vállalásokat — kérd meg, hogy ő sorolja fel a legrosszabb eseteket, és mindegyikre te adsz konkrét választ. Ha valamelyikre nincs jó válaszod, azt nyíltan elismered.

3. Valódi kilépési lehetőség. Menhelyi ideiglenes befogadás vásárlás helyett, plusz a szabály: az első hónapokban indoklás nélkül mondhatja, hogy nem működik, és akkor vége. A vétó az övé.

4. Visszafordítható próba, nyomás nélkül. Egy hétvégi macskaszitting — cserébe semmit nem kérsz, nem kötöd döntéshez.

5. Szimmetrikus lezárás. A próba után egy héttel előre kitűzött, közös fél órás beszélgetés, ahol mindketten elmondjátok, mit gondoltok. Te magad is kimondod hangosan, mi lenne az, amitől te mondanál nemet.

Az összehasonlítás

A három eredmény együtt jól mutatja, mi változik meg, ha nem egyetlen promptban, hanem kontextusban gondolkodunk.

A naiv prompt esetén a modell nem tudta, ki a partner, mi a konkrét félelem, mi volt az eddigi három „nem" mögött — ezért általános tanácsokat adott, amelyek bárki számára működhetnek, és éppen ezért senkinek sem személyre szabottak. A válasz végén visszakérdezett, mert hiányzott az az információ, amivel valóban dolgozhatott volna.

A context engineering workflow esetén ugyanez a modell (Gemini) egészen más eredményt produkált: konkrét infrastruktúrát tervezett (fizetős macskaszitter, automata etető, fali polcok), és a „Láthatatlan Macska" koncepcióval a tér hiányát is megoldotta — mindezt a beadott kontextus alapján. A Fable ezzel szemben más irányba ment: nem logisztikai garanciákat, hanem érzelmi biztonságot és vétójogot épített be a tervbe, és a partnert tette a folyamat középpontjába.

A két CE eredmény között tehát nem a kontextus minősége okozza a különbséget — mindkét modell ugyanazt kapta —, hanem a modellek eltérő „személyisége" és megközelítési stílusa. Ez önmagában is tanulságos: a context engineering nem egyetlen helyes választ hoz ki, hanem egy jól körülhatárolt, személyre szabott megközelítést. Hogy melyik a jobb, az a helyzettől és a partnertől függ — a macska megszerzése a context engineering hatáskörén kívül esik.

← Nem a kérdés számít, hanem ami körülötte van — az elméleti alap