O czym jest ten film
- Autor zbudował grywalną w przeglądarce grę 3D, która uczy, jak działa Codex — z maskotką-logiem jako przewodnikiem, dwunastoma stacjami nauki i kartami z pytaniami kontrolnymi.
- Stosowany stack: model Astra do sterowania pracą, Blender do tworzenia zasobów 3D, Babylon do renderowania ich w przeglądarce oraz hosting na here.now (alternatywy: Vercel, Railway).
- Blendera nie trzeba instalować ręcznie — robi to wtyczka „Build 3D game rooms” w aplikacji Codex, która dodatkowo zawiera „skill”, rodzaj ściągi skracający rozmowę z modelem.
- Projekt zaczyna się od prostego pomysłu i dialogu z agentem, z wyraźnym poleceniem, żeby sięgnął po dokumentację OpenAI.
- Serce metody to przesycany szczegółami plan: opis pierwszych sekund doświadczenia, „definicja ukończenia” z konkretnym zakresem, wytyczne dla maskotki, oświetlenia, fizyki, kamery i dydaktyki.
- Zanim ruszy pełna produkcja, model ma dostarczyć „pakiet wzorcowy” — jedną dopracowaną scenę do oceny wyglądu i wyłapania usterek.
- Warunkiem możliwości odejścia od komputera na kilkanaście godzin są testy w wewnętrznej przeglądarce agenta: scenariusze awaryjne, pomiar opóźnień i pełne logi.
- Jakość ocenia się według rubryki (tożsamość maskotki, światło, dydaktyka, nawigacja), a nie według subiektywnych wrażeń, których nie da się przekazać modelowi.
- Rezultat: około 18 godzin pracy agentów i 8 milionów tokenów; komendę /goal użyto wyłącznie dlatego, że Astra przechodziła wówczas fazę „lenistwa”.
- Zdaniem autora to podejście wykracza poza nowinkę — może realnie zmienić edukację i edtech, w odróżnieniu od masowo powstających gier, w których nikt nie gra dłużej niż tydzień.
Redakcyjne tłumaczenie
Nauka w trzech wymiarach
Wokół każdego tematu, który chcesz zgłębić, można dziś zbudować cały trójwymiarowy świat. To, co właśnie oglądacie, to nasz mały pomocnik z Codexa oprowadzający po immersyjnym świecie 3D, w którym poznaje się Codexa od kuchni — od środka, mechanizma po mechanizmie. Ja zbudowałem ten świat za pomocą Astry i programu Blender. Mój uczy o Codexie, ale wasz może uczyć anatomii, budowy samochodu albo czegokolwiek, na co macie ochodę.
W tym materiale pokażę, jak przejść całą drogę: od pomysłu, przez plan, budowę, aż po publikację w sieci — tak żebyście wy i każdy, kogo zaprosicie, mogli z efektu korzystać. Zamiast marnować czas i tokeny na domową podróbkę Mario Karta albo „GTA 7”, można je wydać na coś, co faktycznie przeniesie waszą naukę na wyższy poziom.
Spacer po świecie: dwanaście stacji
Zanim pokażę, jak stworzyć własne doświadczenie, odwiedźmy moje. Po kliknięciu „wejdź do środka” nasz przewodnik odprowadza nas do pierwszej z dwunastu stacji. Nie pokażę wszystkich — chcę raczej dać wam próbkę, żeby było widać, ile jest tu warstw.
Pierwsza stacja dotyczy zarządzania kontekstem. Każdy element tego świata reaguje na kliknięcie i synchronizuje się z kartą przewodnią po prawej stronie ekranu. Karty służą do zadawania pytań — zwykle testowych — które utrwalają pojęcia. Przykład: „Jakie podstawowe elementy środowiska są niezbędne, żeby Codex mógł wykonać swoją robotę?”. Jeśli nie znasz odpowiedzi, możesz poprosić o podpowiedź albo wyświetlić całe rozwiązanie, przejrzeć je i wrócić.
Im dalej idziemy, tym więcej warstw. Stacja o zarządzaniu plikami ma przycisk „eksploruj w środku” — odsłania kolejne karty i pozwala zejść naprawdę głęboko, z konkretnymi przykładami: jak Codex obchodzi się z PDF-em, z notatką, z plikiem CSV. Potem trafiamy na zarządzanie modelami: nie tylko można klikać poszczególne modele, ale każde kliknięcie rozwija wyjaśnienie, kiedy sięgnąć po Soula, kiedy po Lunę, a kiedy po Astrę.
(Informacja dodatkowa: Soul, Luna i Astra to nazwy modeli, między którymi można wybierać w ekosystemie Codexa.)
Sedno jest takie: zamiast czytać PDF, kazać sztucznej inteligencji streścić go za siebie albo oglądać serię tutoriali, wchodzisz do środka narzędzia, poznajesz je po kawałku i schodzisz coraz głębiej we własnym tempie. A ponieważ to nadal gra, masz menu, w którym zmniejszysz lub zwiększysz intensywność ruchu, dodasz dźwięki otoczenia albo dopieścisz kolejne poziomy. Parter może być poświęcony fundamentom, a każda kolejna kondygnacja dokładać będzie głębi i interakcji.
To było „co”. Teraz zostaje „jak”.
Krok 1. Blender bez ręcznej instalacji
Zanim wyślecie jakikolwiek prompt, trzeba mieć Blendera. Zwyczajowa droga prowadzi przez stronę producenta, pobieranie i konfigurację — ale jest skrót. W aplikacji Codex wchodzimy w wtyczki, wyszukujemy „Blender” i dostajemy dwie pozycje: „Game Development Studio” oraz „Build 3D game rooms”. Ja zainstalowałem obie, bo przy testach okazało się, że pierwsza też bywa przydatna, ale w praktyce wystarczy druga. Nie tylko wykrywa, instaluje i konfiguruje Blendera automatycznie — zawiera też „skill”, czyli ściągę, dzięki której Astra tworzy doświadczenia 3D z mniejszą liczbą rund wymiany zdań.
Krok 2. Od pomysłu do pierwszego promptu
Gdy to działa, można wpisać pomysł. Pokazuję swoje pierwsze, autentyczne wejście — nic wymyślnego, właśnie po to, żeby pokazać, jak prosto można zacząć.
Po lewej stronie napisałem: „A co, gdybyśmy zrobili grę 3D, w której da się, bawiąc się, nauczyć, jak Codex działa w każdym calu? Przemyśl to ze mną w dialogu. Prawdopodobnie przyda ci się skill z dokumentacją OpenAI — jeśli sam z niego nie skorzystasz, zmuć się, żebyś poczytał, czym jest Astra, jak działa Codex i z czego składa się jego techniczna otoczka”.
Po prawej widać, że to prawdziwa korespondencja robocza, a nie wygładzony przykład — bo odpowiedź była bezczelna. Odpisałem więc: „Słodkie, ale potrzebuję najwyższej wierności wykonania. Maskotką ma być logo Codexa oprowadzające po całym ekosystemie. Przygotuj wyczerpujący plan budowy każdego elementu gry oraz — to bardzo ważne — plan testów i oceny gry w twojej wewnętrznej przeglądarce”.
Cel nadrzędny był taki, żeby model nie tylko wyrenderował grę i stworzył zasoby w Blenderze, ale żebym mógł odejść od komputera na cały dzień — w moim przypadku na 17 godzin — i wrócić do gry zbudowanej, przetestowanej i ocenionej według rubryki. Ostatni punkt: hosting. Ja wybrałem here.now (nie mam z tą usługą żadnych powiązań), równie dobrze nadają się Vercel czy Railway. Model musi tylko wiedzieć, że efekt ma wyjść poza wasz lokalny dysk.
Krok 3. Plan przeglądany pod lupą
Gdy ustalenia dobiegną końca, plan trzeba przeczytać z dużą uwagą, linia po linii. Ja omówię najważniejsze jego fragmenty — te, przy których pierwszy raz popełniłem błąd.
Mój plan powstał w okresie, gdy Astra leniwie podchodziła do zadań, więc świadomie „przekarmiałem” ją instrukcjami: wpisałem każdy parametr i każdy wymiar, żeby zostawić modelowi jak najmniej zgadywania i nie dopuścić do tego, by cokolwiek zakładał za mnie.
Dla nadania tonu służy akapit w rodzaju: „Prezentacyjna, grywalna w przeglądarce — to bardzo ważne — trójwymiarowa wycieczka po ekosystemie Codexa, prowadzona przez uosobione logo Codexa. Gracz nauczy się kierować agentem przy użytecznej pracy, przekazywać kontekst, dobierać odpowiedni model i poziom wysiłku” — i tak dalej, przez wszystko, co chcemy pokryć.
Jeśli nie chcecie powtarzać się dziesiątki razy i odkrywać po 12–15 godzinach oraz milionach, jeśli nie miliardach wydanych tokenów, że efekt nie jest tym, o co chodziło — opiszcie maksymalnie konkretnie, co ma się dziać dziesięć sekund po otwarciu aplikacji i co po minucie. Chcecie wciągającej, grywalnejroboty od pierwszej chwili, bez przerabiania gotowego kodu. Zaplanowanie podejścia jest zawsze bez porównania prostsze niż budowanie, cofanie się i refaktoryzowanie.
Dlatego tak ważne jest jedno zdanie definiujące ukończenie. U mnie brzmiało: „Wydanie początkowe jest kompletne w obiecanych ramach: 12 misji głównych, trzy rozdziały, jeden projekt wieńczący, atlas funkcji i przydatne materiały do pobrania”. Samo z tego zdania model wyciąga kolejne wymagania techniczne — u mnie na przykład konieczność magazynu danych w przeglądarce, żeby dało się pobierać pliki Markdown czy PDF.
Mockupy, zanim wydasz tokeny
Jak przy każdej stronie czy platformie, przed zaangażowaniem całego czasu i tokenów warto najpierw obejrzeć makiety i projekty. Wysyłam więc prompt w stylu: „Zanim wyprodukujesz wszystkie pomieszczenia, stwórz pakiet wzorcowy: ujęcie powitalne, zbliżenie maskotki, jedną ekspozycję edukacyjną, arkusz materiałów i 15–20-sekundową próbkę animacji”.
Dostajecie w ten sposób mały fragment świata — do oceny wyglądu i odczucia. Wady na pewno się znajdą, o to chodzi. Sprawdzacie, czy obraz się rozmywa, czy detail jest wysoki, a potem oddajecie feedback z pewnością, że model go podchwyci i rozwinie.
Gdy budowałem pierwszą stację, usterek było mnóstwo. Nie dało się porządnie przybliżać obrazu, a po zoomie wszystkie etykiety zamieniały się w rozmytą plamę — podobnie napis w tle. Przy poruszaniu się nie było śladu porządnej fizyki: światło nie odbijało się od maskotki, a tła nie było wcale — czarna pustka. Wnioszek praktyczny: najlepiej dopracować jedną scenę tak, żeby zawierała całą mechanikę naraz, a resztę świata Codex ekstrapoluje już sam.
Dwa narzędzia, dwie role: Blender i Babylon
Czego nie wiedziałem na starcie: sam Blender nie wystarczy. Potrzebny jest jeszcze Babylon. Blender służy do tworzenia zasobów 3D, a Babylon do tego, by te zasoby wyrenderować w przeglądarce — żeby świat był w niej naprawdę grywalny.
Maskotka, światło, kamera i diagram przepływu
Szybko przejdę przez kolejne sekcje planu, o których możecie nie pomyśleć, jeśli robicie to pierwszy raz.
Jeśli pozwolicie Codexowi na meta-prompting — to znaczy, że to sztuczna inteligencja pisze prompt za was — dostaniecie bardzo rozbudowane wyjaśnienia. U mnie model na kilku ekranach opisywał, jak dokładnie ma wyglądać maskotka. I dobrze: celem nie była jakaś mglista, statyczna grafika 2D, tylko postać z głębią i osobowością, umiejąca się ruszać, trząść, tańczyć — zrobić wszystko, czego potrzeba.
Wspomniałem już o oświetleniu, ale warto wydzielić osobne sekcje: jak ma działać fizyka, jak światło ma odbijać się od głównej postaci — zwłaszcza gdy obracamy kamerę dookoła. Potem kamera i ruch: moja wycieczka zaczynała się od dynamicznego najazdu na maskotkę Codexa, a dopiero potem przewodnik zabierał nas od stacji do stacji.
Bardzo pomaga też dołączenie diagramu w składni Mermaid, obrazującego przebieg klatka po klatce. (Informacja dodatkowa: Mermaid to składnia pozwalająca rysować diagramy i schematy przepływu z zwykłego tekstu.) Jeśli model łatwo pojmie przepływ, testowanie staje się bez porównania prostsze. U mnie rozpiska obejmowała misję główną, pokój sterowania, co robi gracz, co zrozumie po przejściu danej stacji i jaki praktyczny wniosek zabierze do swojej pracy. Nawet na etapie projektowania pojęć — a także dodatkowych, klikalnych warstw — doprecyzowanie lekcji płynącej z każdego fragmentu jest kluczowe.
Dalsze sekcje planu opisują: jak ma przebiegać interakcja między użytkownikiem a grą, jak ma działać dydaktyka, gdzie i kiedy pokazywać podpowiedzi oraz co mają zawierać, a także architekturę techniczną i strukturę plików oraz folderów. Możecie to przejrzeć samodzielnie — wystarczy wiedzieć, że poziom szczegółowości służy jednemu: żeby Codex jak najmniej kręcił się w kółko.
Testy, które pozwalają odejść od biurka
Sekcja, na której chcę się skupić, to testowanie — bo od niej zależy, czy w ogóle da się odejść od komputera na 5, 10, 15 godzin i wrócić do produktu na tyle dobrego, by zacząć go używać i publikować.
W wymianie zdań ustaliłem z Codexem poziom odniesienia: jak będzie korzystać ze swojej wewnętrznej przeglądarki — to słowa kluczowe: „internal browser” — żeby mógł testować niezależnie i nie konkurował z moim Chrome’em o okno przeglądarki.
Żeby testy były naprawdę użyteczne i nie wpadały w nieskończone pętle, warto dopisać: „uwzględnij uszkodzone stare zapisy, wyłączony magazyn danych, brakujące zasoby, wolne sieci” — to ostatnie jest bardzo ważne, jeśli chcecie mierzyć opóźnienia renderowania, czyli to, jak wolno scena pojawia się na ekranie podczas gry — a także „porwane pobierania, błędy dekodera, utratę kontekstu graficznego i niewspieraną grafikę”. Do tego pełne logi i zapis śladu wszystkiego, co się dzieje, żeby w razie potrzeby cofnąć się w czasie albo do konkretnego punktu kontrolnego.
Rubryka jakości zamiast „testu klimatu”
Jedno jest przejść testy techniczne, a zupełnie co innego — przejść test odbioru. A wrażeń nie da się po prostu opisać modelowi. Dlatego tak ważne jest stworzenie rubryki definiującej jakość i sukces. U mnie znalazły się w niej osobne wymiary: tożsamość maskotki, popis postaci, charakter przestrzeni, oświetlenie, dydaktyka, interakcja oraz nawigacja kamerą — w tym możliwość przeskoku ze stacji pierwszej od razu na siódmą bez zgrzytu w płynności. Gra nie musi być przechodzona po kolei, ale jeśli ktoś chce — może.
Rozliczenie: co dokładnie masz dostać
Gdy całość jest skończona, trzeba mieć pewność, że otrzymujemy wszystko, czego się spodziewamy — łącznie z działającym adresem URL i hostowaną grą. Dlatego wprost piszemy: „dostarcz źródłowe pliki projektowe Blendera”, czyli komplet surowców do wszystkich zasobów 3D. Dalej: „proweniencję zasobów” — elegancka nazwa dla wiedzy o tym, skąd wziął się każdy element sceny. Dzięki temu, gdy coś się zepsuje, nie trzeba przebudowywać całego świata czy całej aplikacji — wymienia się sprawdzony fragment i gotowe. Potem: powtarzalna procedura budowy wraz z katalogiem źródeł lekcji, który można swobodnie modyfikować. Na koniec: dowody wizualne z przeglądarki oraz finalny, hostowany adres — u mnie na here.now, choć równie dobrze mógłby to być Vercel.
Warto też dopisać: „przed każdym wydaniem treści sprawdź na nowo zmienione funkcje OpenAI i dostępność modeli”. Chodzi o aktualność informacji — skoro narzędzia i ich otoczka ciągle się zmieniają, nasz świat ma nadążać za tymi zmianami.
Bilans: 18 godzin i 8 milionów tokenów
To, co widzieliście na ekranie, zajęło około 18 godzin — od wysłania planu, przez renderowanie i testy, aż po dostarczony adres URL — i pochłonęło 8 milionów tokenów, przy Astrze ustawionej na średni poziom wysiłku.
Jedno zastrzeżenie: budowałem to w okresie, gdy Astra miewała wyraźnie lenia. Zamiast wysłać plan jako zwykły prompt planistyczny — jak normalnie zrobiłbym to choćby z Fable 5.1 — użyłem komendy /goal. Jeśli nie znasz tej funkcji: trzyma ona wszystkie agenty przy pracy, wytrwale i pozornie bez końca, dopóki model nie poczuje — to jest kluczowe słowo — że spełnił wszystkie kryteria. Skoro OpenAI wprowadziło już poprawki, po których Astra mniej się wymiguje, nie użyłbym /goal ponownie. Zamiast tego przeprowadziłbym planowanie Astrą na średnim lub wysokim poziomie wysiłku, a całe wykonanie od deski do deski próbował zlecić Soulowi albo Lunie na poziomie ekstra high.
Niezależnie od wyboru modelu samo tworzenie i renderowanie zasobów 3D pochłania mnóstwo tokenów — ale można eksperymentować, generując je tańszymi modelami.
Dlaczego to wykracza poza jeden przypadek
Pokazałem jeden przypadek użycia: świat 3D do end-to-endowej nauki jednego narzędzia. Ale ta sama recepta sprawdzi się przy nauce Claude’a czy Gemini, budowy ludzkiego ciała, rozbieraniu silnika na części, podróży w głąb historii, budowaniu takich światów dla innych — wszędzie tam, gdzie wiedzę lepiej pokazać w ruchu niż wczytywać ją z płaskiego obrazka albo PDF-a.
Z wszystkich zastosowań, jakie widziałem — a większość to bezużyteczne gry, w których nikt nie zagra po paru tygodniach — właśnie ten typ projektu ma szansę realnie przeobrazić edukację i cały edtech.
Na koniec
Mam nadzieję, że to dobry wstęp do tego, co jest możliwe, gdy połączy się Astrę z Blenderem i zbuduje trójwymiarowe światy do nauki czegokolwiek od A do Z. Jeśli chcecie wypróbować moją grę i dostać wszystkie prompty oraz plan, który pod nią leży, a do tego pełny przewodnik, którym można wczytać kontekst własnej sztucznej inteligencji — co może się przydać, żeby dojść do podobnego efektu — wszystko zostawiam pod drugim linkiem, całkowicie za darmo.
A jeśli chcecie wejść głębiej w dodatkowe materiały, które publikuję w mojej społeczności — i zrozumieć każdy etap tego procesu, tu raczej streszczony z uwagi na czas oglądania — zajrzyjcie pod pierwszy link. Poza takimi treściami znajdziecie tam stale rosnącą bazę pojęć, omówień, głębokich analiz i kompletnych systemów do natychmiastowego użycia z Claude’em i Codexem — by przenieść swoją naukę, działalność doradczą albo praktykę na wyższy poziom. Jeśli chcecie mieć dostęp, kliknijcie pierwszy link — może zobaczymy się w środku. A jeśli ten materiał wam pomógł, polubienie i komentarz bardzo docenię. Do zobaczenia w następnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Blender przez wtyczkę, nie przez instalator
Na czym polega: Zamiast ręcznie pobierać i konfigurować Blendera, w aplikacji Codex w zakładce wtyczek wyszukaj „Blender” i zainstaluj „Build 3D game rooms”. Wtyczka sama wykrywa, instaluje i konfiguruje Blendera, a dołączony „skill” działa jak ściąga — skraca liczbę rund rozmowy potrzebnych Astrze do zbudowania doświadczenia 3D.
Jak stosować: Zrób to jako krok zero, przed wysłaniem pierwszego promptu. Druga wtyczka („Game Development Studio”) bywa pomocnicza, ale nie jest warunkiem sukcesu.
Na co uważać: Samo zainstalowanie wtyczki nie zwalnia z myślenia o zasobach 3D — bez Blendera w tle projekt po prostu nie ruszy, a problem ujawni się dopiero w trakcie budowy.
2.Zacznij od rozmowy i dopilnuj, by agent sięgnął po dokumentację
Na czym polega: Pierwszy prompt autora to jedno zdanie z pomysłem plus prośba o wspólny brainstorm i o skorzystanie ze skilla z dokumentacją OpenAI, żeby model wiedział, czym jest Astra i jak zbudowany jest Codex, zanim cokolwiek zaprojektuje.
Jak stosować: Napisz prosto, o co ci chodzi, i potraktuj pierwszą wymianę zdań jak rozmowę z partnerem projektowym. Jeśli agent sam nie sięgnie po dokumentację — dopominaj się wprost.
Na co uważać: Dialog na starcie nie zastępuje planu; jego rolą jest doprecyzowanie pomysłu, a nie rozliczenie z wykonania.
3.Przesyc plan szczegółami — mniej domysłów, mniej poprawek
Na czym polega: Plan powstawał, gdy Astra leniwie podchodziła do zadań, więc autor wpisał w niego każdy parametr i każdy wymiar — wygląd maskotki, oświetlenie, fizykę, kamerę, strukturę plików, reguły podpowiedzi — żeby model niczego nie musiał zgadywać ani zakładać samodzielnie.
Jak stosować: Zanim pozwolisz agentowi budować, rozpisz konkretne wymiary jakości i zachowania. Traktuj plan jak kontrakt, w którym każdy brak precyzji to miejsce na interpretację po twojej nieobecności.
Na co uważać: To faza tania względem produkcji, ale da się przesadzić: przy „pracowitym” modelu część mikro-poleceń jest zbędna i tylko wydłuża dokument.
4.Opisz pierwsze sekundy doświadczenia i zdefiniuj ukończenie
Na czym polega: W planie znalazły się konkretne wskazania, co ma się dziać 10 sekund i minutę po otwarciu aplikacji, oraz zdanie „definicji ukończenia”: 12 misji głównych, trzy rozdziały, projekt wieńczący, atlas funkcji i materiały do pobrania. Z takiego zakresu model sam wyprowadza wymagania techniczne, np. magazyn danych w przeglądarce.
Jak stosować: Pisz tak, jakbyś opisywał grę komuś przez telefon — od pierwszego ujęcia po listę tego, co składa się na „gotowe”. Każde kryterium zakresu przetłumacz na wymaganie techniczne.
Na co uważać: Bez progu ukończenia projekt wpada w stan wiecznego „prawie gotowe”; zbyt wąski zakres sprawi z kolei, że efekt będzie ciekawostką, a nie narzędziem.
5.Najpierw jedna dopracowana scena, potem cały świat
Na czym polega: Zanim model wygeneruje wszystkie pomieszczenia, żąda się „pakietu wzorcowego”: ujęcia powitalnego, zbliżenia maskotki, jednej ekspozycji edukacyjnej, arkusza materiałów i kilkunastosekundowej próbki ruchu — czyli małego fragmentu świata do oceny stylu i wyłapania wad.
Jak stosować: Obejrzyj próbkę pod kątem rozmyć, fizyki, odbić światła i tła, a potem oddaj konkretny feedback. Jedna scena z całą mechaniką wystarczy — resztę model rozszerzy sam.
Na co uważać: Pierwsza wersja u autora miała rozmyte etykiety, czarną pustkę zamiast tła i brak fizyki oświetlenia. Takie usterki trzeba wyłapać teraz — po rozmnożeniu na cały świat ich naprawa kosztuje wielokrotnie więcej.
6.Blender tworzy, Babylon renderuje
Na czym polega: Blender służy do tworzenia zasobów 3D, ale żeby świat był grywalny w przeglądarce, potrzebny jest dodatkowo silnik Babylon, który te zasoby renderuje.
Jak stosować: Przy rozliczaniu efektów żądaj „źródłowych plików projektowych Blendera” — kompletu surowców do wszystkich modeli — żeby móc później cokolwiek poprawiać.
Na co uważać: Pominięcie któregoś z elementów oznacza projekt działający wyłącznie lokalnie albo nie do naprawienia bez przebudowy od zera.
7.Testuj awarie w wewnętrznej przeglądarce, nie na szczęśliwej ścieżce
Na czym polega: Agent ma testować w swojej wewnętrznej przeglądarce (kluczowe sformułowanie: „internal browser”), żeby nie konkurować z twoim Chrome’em. Scenariusze obejmują uszkodzone zapisy, wyłączony magazyn danych, brakujące zasoby, wolne sieci, porwane pobierania, błędy dekodera, utratę kontekstu graficznego i niewspieraną grafikę.
Jak stosować: Dołącz wymóg pełnych logów i śladu wykonania, żeby można było cofnąć się do punktu kontrolnego; celowo spowolnione sieci pozwalają mierzyć opóźnienia renderowania.
Na co uważać: Bez wymuszonych scenariuszy awarii testy albo wpadają w pętle bez wyjścia, albo potwierdzają wyłącznie przebieg idealny — a to nie jest test.
8.Rubryka zamiast wrażeń
Na czym polega: Testy techniczne nie gwarantują dobrego odbioru, a „klimatu” nie da się opisać modelowi wprost. Dlatego jako kryteria jakości służy rubryka z osobnymi wymiarami: tożsamość maskotki, popis postaci, przestrzenność, oświetlenie, dydaktyka, interakcja i nawigacja kamerą.
Jak stosować: Dopisz do rubryki przypadki brzegowe — np. przeskok ze stacji 1 od razu na 7 bez utraty płynności. Gra nie musi być liniowa, ale nie może się sypać przy niestandardowej kolejności.
Na co uważać: Zbyt ogólne kryteria („ma ładnie wyglądać”) agent zaliczy formalnie; każdy wymiar rubryki musi być możliwy do zweryfikowania.
9.Rozlicz deliverables co do pliku i dbaj o aktualność treści
Na czym polega: Wprost wymienione efekty pracy: źródłowe pliki Blendera, „proweniencja zasobów” (wiedza, skąd wziął się każdy element sceny), powtarzalna procedura budowy i katalog źródeł lekcji, dowody wizualne z przeglądarki oraz finalny, hostowany URL.
Jak stosować: Dzięki „proweniencji” przy usterce wymienisz jeden fragment zamiast przebudowywać cały świat. Przed każdym wydaniem treści sprawdzaj na nowo zmienione funkcje OpenAI i dostępność modeli.
Na co uważać: Świat uczący o narzędziu, które się zmieniło, uczy nieprawdy — bez wbudowanego punktu aktualizacji szybko się zestarzeje.
10.Dobierz model do fazy projektu i pilnuj budżetu
Na czym polega: Całość zajęła około 18 godzin i 8 milionów tokenów przy Astrze na średnim poziomie wysiłku. Komendy /goal użyto wyłącznie dlatego, że Astra przechodziła wtedy fazę „lenistwa”; dziś autor planowałby Astrą (medium/high), a wykonanie end-to-end zlecał Soulowi lub Lunie na extra high.
Jak stosować: Rozdziel planowanie od wykonania i dopasuj poziom wysiłku do etapu; generowanie zasobów testuj na tańszych modelach, zanim zaangażujesz droższe.
Na co uważać: 8 milionów tokenów to realny rząd wielkości dla takiego projektu — zacznij od małego fragmentu świata, żeby zweryfikować jakość, nim wydasz pełny budżet.