Weboldalkészítés ChatGPT-vel: így építettük fel az OkosHorizontot az ötlettől az éles indulásig

Lehet egy beszélgetésből működő weboldal? Az OkosHorizont készítése közben ezt próbáltuk ki: magyar nyelvű tudásportált építettünk cikkekkel, kalkulátorokkal, gazdasági hírfigyelővel és közösségi fórummal. A tervezésben és a megvalósításban ChatGPT segített. A munkához egy engedélyezett Windows laptopot és egy hagyományos webtárhelyet használtunk.

Ebben a cikkben elmagyarázzuk, hogyan tudott az asszisztens a laptopon fájlokat szerkeszteni, hogyan kezeltük a tárhelyet egy már bejelentkezett böngészőben, és mit ellenőriztünk az éles indulás előtt. Bemutatjuk a hibákat is: a megszakadó távoli kapcsolatot, a nem megfelelő PHP-binárist, a gyorsítótárazott regisztrációs kódot és az adatbázis-meghajtó eltérését.

A cikk saját tapasztalatainkra épül, nem ígér minden szolgáltatónál azonos telepítést. Ahol általános beállítás szerepel, azt külön jelezzük. Az alkalmazások elérhetősége, kezelőfelülete és előfizetési feltételei változhatnak. A forrásokat az írás végén találod.

1. Mit készítettünk, és ki mit csinált?

Az OkosHorizont célja az volt, hogy gyakorlati magyar útmutatókat adjon az okosotthon, a technológia, a mesterséges intelligencia, az adatok és a pénzügyi alapfogalmak témájában. A tartalmak mellé hasznos eszközöket és olyan közösségi felületet szerettünk volna, ahol az olvasók kérdezhetnek és cikkötleteket javasolhatnak.

A projektgazda fogalmazta meg az igényeket, választotta ki az irányt, ellenőrizte a megjelenést és jóváhagyta az éles változtatásokat. A ChatGPT terveket és szövegeket készített, kódot írt, az engedélyezett eszközökön keresztül fájlokat kezelt, teszteket futtatott és dokumentálta az eredményeket.

Ehhez háromféle segítséget használtunk:

• Beszélgetés és tervezés: célok, oldalszerkezet, tartalom, következő lépések.
• Helyi fejlesztés: fájlszerkesztés, parancsok, ellenőrzések a csatlakoztatott laptopon.
• Böngészős munka: weboldalak tesztelése és a tárhely kezelése az engedélyezett munkamenetben.

A szöveges válasz önmagában nem igazolta, hogy valami elkészült. Ha az asszisztens azt írta, hogy sikerült a feltöltés, utána a fájl visszaolvasásával és az oldal tényleges megnyitásával is ellenőriztük az eredményt.

Használható induló feladatleírás

Az alábbi minta új projektre vonatkozó példa, nem korábbi beszélgetés szó szerinti idézete:

Magyar nyelvű tudásportált szeretnék. Először mérd fel a megadott projektmappát, és készíts megvalósítási tervet. Első körben ne változtass az éles weboldalon. Írd le, milyen hozzáférésre van szükséged, és milyen ellenőrzés igazolja majd az elkészült munkát. Jelszót és hozzáférési kulcsot ne kérj a beszélgetésbe.

Egy ilyen feladatból kiderül a cél, a munkaterület és az ellenőrzés módja. Később ezt lehet konkrét végrehajtási engedéllyel bővíteni.

2. Milyen eszközök kapcsolódtak össze?

A weboldalt kiszolgáló szerver és a fejlesztői laptop két külön gép volt. A ChatGPT nem kapott magától hozzáférést egyikhez sem.

Az OpenAI a Remote Desktop Commandert olyan kapcsolódó eszközként mutatja be, amellyel egy felhasználó által engedélyezett számítógép fájljai és terminálja elérhető. A rendelkezésre állás függhet a csomagtól és a munkaterület beállításaitól. Nem állítjuk, hogy minden ChatGPT-fiókban azonos menüpontok és jogosultságok vannak. [1]

3. Hogyan kapcsoltuk a Windows laptopot a ChatGPT-hez?

3.1. Először kijelöltük a munkaterületet

A projekt külön mappát kapott. A cikkben szereplő általánosított példa:

C:\Webprojekt\
  src\
  public\
  deployment\
  editorial\
  docs\

A valódi felhasználónév, gépazonosító és belső tárhelyútvonal nem szükséges a módszer megértéséhez. Új projektnél érdemes külön Windows-felhasználót vagy elkülönített környezetet használni, és a szükséges legkisebb jogosultságot biztosítani.

A chatben megadott „csak ebben a mappában dolgozz” utasítás fontos munkaszabály. Nem helyettesít operációs rendszer szintű jogosultságot vagy elkülönítést. A Desktop Commander fájleszközeinek mappakorlátja sem jelenti azt, hogy a terminál minden más fájltól el lenne zárva; ezt a fejlesztő dokumentációja is külön jelzi. [4]

3.2. Ellenőriztük a futtatókörnyezetet

A Remote Device indításához Node.js szükséges. Telepítésnél a hivatalos Node.js letöltési oldal és az adott eszköz aktuális követelménye az irányadó. Ne egy régi képernyőképről kiválasztott verziót telepíts. [5]

Windows PowerShellben az ellenőrzés például:

node --version
npm.cmd --version

Ha valamelyik parancs nem található, előbb a telepítést vagy az elérési utat kell rendezni. A böngészőben megnyitott ChatGPT ettől még nem fér hozzá a géphez.

3.3. Elindítottuk és engedélyeztük a távoli kapcsolatot

A fejlesztő dokumentációjában szereplő indítási parancs:

npx.cmd @wonderwhy-er/desktop-commander@latest remote

A parancs kódot tölt le és indít el a gépeden. Előbb ellenőrizd a csomag nevét és a hivatalos forrást; az itt szereplő @latest az indításkori legújabb csomagot jelenti, nem rögzített verziót. A mi történetünkben ezt az eszközcsaládot használtuk, a ma telepített változat nem feltétlenül azonos a projekt korábbi verziójával.

A párosításnál a böngészőben megjelenő jóváhagyó kódot össze kell vetni a terminálban látottal. Eltérésnél nem szabad jóváhagyni az eszközt. Ezután a saját szolgáltatói fiókoddal engedélyezed a gép csatlakoztatását, majd a ChatGPT-ben a hivatalos alkalmazáskapcsolaton keresztül hozzáadod a szolgáltatást. A pontos felülethez a szolgáltató aktuális beállítási útmutatóját kövesd. [2]

A helyi folyamatnak futnia kell ahhoz, hogy a kérések eljussanak a gépig. A parancsok a laptopon, az ottani felhasználó jogosultságaival hajtódnak végre. [3]

3.4. Egy ártalmatlan olvasási próbával kezdtünk

Elsőként nem telepítést vagy feltöltést kértünk, hanem hozzáférés-ellenőrzést. Új projektnél jó első feladat:

Ellenőrizd, hogy eléred-e a C:\Webprojekt mappát. Csak a fájlneveket sorold fel, és olvasd el a projekt leírását. Semmit ne módosíts, és ne indíts telepítést.

Ez megmutatja, hogy a megfelelő számítógépen, a megfelelő mappában dolgozik-e az asszisztens. Az „online” jelzés hasznos, de a tényleges fájlolvasás eredménye erősebb bizonyíték a működő kapcsolatra.

3.5. Az ideiglenes leállítás és a visszavonás külön művelet

A helyi folyamat Ctrl+C-vel megállítható. Ettől a mentett engedély még megmaradhat, és az újraindítás ismét összekapcsolhatja a gépet.

Tartós megszüntetésnél a szolgáltatói felületen az eszköz engedélyét is vissza kell vonni. A helyi mentett kapcsolat eltávolítása és a ChatGPT alkalmazáskapcsolatának törlése külön lépés; egyikből sem következik automatikusan a másik. A fejlesztő ezek különbségét részletesen dokumentálja. [3]

3.6. A közvetítő szolgáltatást is figyelembe kell venni

A fájlművelet a laptopon fut, de a kérés és az eredmény a kapcsolódó szolgáltatásokon keresztül jut el a beszélgetéshez. Nem állítható általánosan, hogy minden adat kizárólag a számítógépen marad. A használat előtt a ChatGPT és a kapcsolódó szolgáltató adatkezelési feltételeit is át kell nézni.

A projektben ezért sem a teljes felhasználói mappa, sem személyes iratok tömeges átolvasása nem volt cél. A feladathoz szükséges fájlokat választottuk ki, és a jelentésekbe csak a szükséges adatokat emeltük át.

4. Mit tanultunk a kapcsolat megszakadásaiból?

A fejlesztés során a laptop újraindult, és olyan hibaüzeneteket is láttunk, mint a transport failure vagy a Presence track not acknowledged. Volt, hogy a szolgáltatáshoz kapcsolódás sikerült, de a gép még nem volt elérhető parancsok számára.

Ilyenkor ebben a sorrendben érdemes gondolkodni:

1. Fut még a laptopon a kapcsolódási folyamat?
2. Van tényleges internetkapcsolat, és működik más weboldal?
3. A szolgáltatás elérhetőként jelzi a gépet?
4. Sikerül egy egyszerű, csak olvasó eszközhívás?
5. Ha egy munka félbeszakadt, mi történt meg belőle a megszakadás előtt?

Nálunk a mobilinternet kipróbálása is része volt a vizsgálatnak. Ez nem bizonyította önmagában, hogy az otthoni Wi-Fi hibás. A naplók alapján nem minden megszakadás pontos okát lehetett utólag megállapítani.

A legfontosabb szabály: egy félbeszakadt műveletet előbb felmérünk, utána folytatunk. Egy fájl feltöltése például megtörténhetett akkor is, ha a sikeres válasz már nem érkezett vissza.

5. Hogyan tudott a ChatGPT a böngészővel dolgozni?

A fájlkezelés és a böngésző vezérlése két külön képesség. A projektben a laptopon futó segédprogramok között Playwright is volt. Ez csatlakozott egy elkülönített Chrome-munkamenethez, és azon belül nyitott oldalakat, kattintott, ellenőrzött űrlapokat.

Nem volt elég annyi, hogy „nyitva van a böngésző”. Az automatizálásnak ahhoz a konkrét böngészőpéldányhoz kellett kapcsolódnia, amelyet erre előkészítettünk.

Külön böngészőprofil a munkához

A személyes, mindennapos böngészőprofil helyett külön projektprofilt használtunk. A Chrome dokumentációja is elkülönített adatkönyvtárat javasol a hibakereséshez; a Chrome 136-tól a szokásos alapértelmezett adatkönyvtárral a távoli hibakeresési kapcsolók viselkedése korlátozott. [6]

Az alábbi csak általánosított haladó példa, nem a valódi gép beállítása:

$chromePath = Join-Path $env:ProgramFiles 'Google\Chrome\Application\chrome.exe'
$projectProfile = Join-Path $env:LOCALAPPDATA 'Webprojekt-Bongeszo'

if (-not (Test-Path -LiteralPath $chromePath)) {
    throw 'A Chrome telepítési útvonalát ellenőrizni kell.'
}

& $chromePath '--remote-debugging-address=127.0.0.1' '--remote-debugging-port=9222' "--user-data-dir=$projectProfile"

A vezérlőport csak a helyi gépről legyen elérhető. Nem kell hozzá routeres porttovábbítás vagy a tűzfal kikapcsolása. A figyelő címet Windowsban külön is ellenőrizheted:

Get-NetTCPConnection -LocalPort 9222 -State Listen |
    Select-Object LocalAddress, LocalPort

Ha a szolgáltatás minden hálózati interfészen figyel, állj meg és javítsd a beállítást. A hibakeresési hozzáférés a böngésző munkameneteihez is hozzáférést jelenthet; a külön profil nem szünteti meg ezt a kockázatot.

A Playwright a Chromium-alapú böngészőkhöz Chrome DevTools Protocolon, röviden CDP-n keresztül is csatlakozhat. Az ehhez használt hívás például chromium.connectOverCDP('http://127.0.0.1:9222'). Ez egy csatlakozási részlet, nem önmagában teljesen futtatható program: kell hozzá a Playwright-csomag és az előkészített böngésző. [7]

A saját projektben az automatizálás előtt ellenőriztük, melyik lap van megnyitva és melyik szolgáltatáshoz tartozik. A teljes címet nem írtuk naplóba, ha munkamenet-azonosítót vagy belépési tokent tartalmazhatott.

6. Hogyan léptünk be a tárhelyszolgáltatóhoz?

A tárhely ügyfélkapus bejelentkezését a projektgazda végezte. Ő írta be a saját jelszavát, és ha kellett, elvégezte az emberi megerősítést. A chatbe nem kellett bemásolnia a jelszót.

A mi tárhelyünkön a munkamenet útja ez volt:

1. A projektgazda megnyitotta a szolgáltató hivatalos ügyfélkapuját a projektböngészőben.
2. Bejelentkezett a saját adataival.
3. A tárhelyszolgáltatás részleteit nyitottuk meg.
4. Az „Access your panel” gombon át jutottunk a wePanel felületére.
5. A már hitelesített felületen dolgoztunk tovább.

Ez a saját szolgáltatónknál megfigyelt folyamat. Más tárhelyen más név, más vezérlőpanel és más belépési mód lehet.

A jelszó chatbe másolásának elkerülése nem teszi érzéketlenné a munkamenetet. Egy bejelentkezett böngészőben a megfelelően engedélyezett automatizálás műveleteket végezhet. Ezért a használt profilhoz és eszközhöz adott hozzáférést is gondosan kell kezelni, a munka végén pedig szükség szerint ki kell jelentkezni.

Mely felületeket használtuk?

A fájlkezelővel az engedélyezett fájlokat olvastuk és töltöttük fel. Az adatbázis-kezelővel a fórumhoz tartozó adatbázison dolgoztunk, illetve mentést és célzott ellenőrzéseket végeztünk. A Cron felületen az időzített szerverfeladatokat kezeltük.

Nem kapcsoltunk be SSH-hozzáférést csak azért, hogy egyszerűbb legyen a fejlesztés. A webes kezelőfelület és az engedélyezett eszközök elegendőnek bizonyultak a végrehajtott lépésekhez.

A projekt korábbi szakaszában FTPS-alapú feltöltés és visszaállítás is készült. A későbbi tárhelymunkáknál a böngészős panel lett a működő munkafolyamat egyik fontos része. A cikk ezért nem állítja, hogy végig kizárólag egyetlen feltöltési módszert használtunk.

7. Miért kellett külön tesztoldal?

Az éles weboldalt a látogatók használják. A tesztoldalon viszont egy változtatás hibázhat anélkül, hogy a nyilvános szolgáltatást rögtön elrontaná.

Általánosított címekkel:

https://pelda.hu/          → éles weboldal
https://teszt.pelda.hu/    → elkülönített tesztoldal
https://forum.pelda.hu/    → közösségi fórum

A külön cím önmagában még nem biztosít elkülönítést. Meg kellett néznünk a kiszolgáló könyvtárakat, az adatbázisokat és a hozzáféréseket is. Egy véletlenül közös adatbázis miatt a tesztoldali módosítás az éles fórumra is hathatna.

A tesztet jelszó védte. A noindex keresőutasítás ezt nem helyettesíti: egy nem indexelt oldal is elérhető annak, aki ismeri a címét.

Minden feltöltés előtt az volt a kérdés, hogy a célútvonal valóban a teszthez vagy az engedélyezett éles kiadáshoz tartozik-e. Az elérési út ellenőrzése sokkal kevesebb munka, mint egy téves feltöltés utáni helyreállítás.

8. Hogyan lett a forrásfájlokból weboldal?

A fő portál Astro-alapú statikus weboldalként épült. A szerkeszthető forrásokból elkészült a feltölthető HTML, CSS és JavaScript. A böngésző ezeket jeleníti meg; a dinamikus szerverfeladatok külön alkalmazásként működnek.

Egy kalkulátor például működhet a látogató böngészőjében. A hírgyűjtő ezzel szemben szerveroldali programot és ütemezést igényelhet. A fórum pedig adatbázist, fiókkezelést és levelezést is használ.

A munkánkban három ellenőrzést különböztettünk meg:

• Elkészül a kimenet? A fordítás nem akad meg.
• Helyesen működik a funkció? A számítás, űrlap vagy szűrő a várt eredményt adja.
• Használható az oldalon? A gomb látható, a mobilnézet nem lóg ki, a navigáció működik.

A sikeres build nem jelenti automatikusan azt, hogy egy fehér gomb jól látszik fehér háttéren. A szerkesztési munka közben a projektgazda visszajelzése és a tényleges böngészős próba ezért végig fontos maradt.

9. Hogyan készítettük el a hírfigyelőt?

A hírfigyelő kialakításánál meg kellett oldani a hírek lekérését, feldolgozását és rendszeres frissítését. Később külön magyar és angol nyelvű belépési lehetőség készült.

A hírfigyelő nem adott automatikus engedélyt más oldalak teljes cikkeinek átvételére. A forrás, a hivatkozás és a felhasználás feltétele külön szerkesztői kérdés maradt.

A PHP-bináris tanulsága

Az egyik feltételezett PHP-elérési út futtatható volt, mégsem azt a parancssori környezetet adta, amelyre szükségünk volt. CGI/FastCGI-változatként viselkedett; a CLI-védelmet tartalmazó ellenőrzőprogram megállította a nem megfelelő futást.

Ebből azt tanultuk, hogy a „van PHP” kijelentés kevés. Külön ellenőrizni kell a verziót, a futási módot és a szükséges bővítményeket. A jó útvonal másik tárhelyen eltérhet, ezért nem adunk minden szolgáltatóra érvényes kiszolgálói PHP-útvonalat.

A minimális diagnosztikához például ezek a PHP-adatok elegendők lehetnek:

<?php
echo json_encode([
    'version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
    'curl_loaded' => extension_loaded('curl'),
    'simplexml_loaded' => extension_loaded('SimpleXML'),
], JSON_PRETTY_PRINT);

Ez a részlet önmagában a bővítmények betöltését jelzi. Nem bizonyítja egy konkrét hírforrás elérését vagy XML-adatainak sikeres feldolgozását; azt funkcionális próbával is ellenőrizni kell.

A diagnosztikát a nyilvános webkönyvtáron kívül végeztük. Nem tettünk ki teljes phpinfo() oldalt és nem listáztunk környezeti változókat.

Az egyszerinek szánt Cron-próba tényleg csak egyszer fusson

A Cron rendszerint ismétlődő időzítést kínál. Egy próba céljára létrehozott bejegyzés ezért veszélyes lehet, ha megfeledkezünk róla.

Nálunk felügyelt időablak, atomi egyszeri jelölő, privát kimeneti fájl és utólagos törlés alkotta a diagnosztika védelmét. Az atomi művelet a párhuzamos indulási kísérleteket is korlátozta. Ez legfeljebb egy indulási engedélyt biztosít; áramszünet vagy programhiba mellett nem garantál sikeres befejezést.

A diagnosztikai bejegyzést utána töröltük és a listát ellenőriztük. Ez nem azonos a később szándékosan létrehozott üzemi időzítésekkel, például a rendszeres hírfrissítéssel.

10. Hogyan készült a közösségi fórum?

A kérdésekhez, tapasztalatokhoz és cikkötletekhez önálló fórumot alakítottunk ki. A nyilvános indulás előtt ellenőriztük a regisztrációt, az e-mail-megerősítést, a jelszó-visszaállítást és a moderációt.

A felhasználó nem egy késznek látszó, de valójában üres űrlapot kapott. A teljes folyamatot saját próbafiókkal jártuk végig:

1. Regisztráció a böngészőből.
2. A szabályzat elfogadásának és verziójának rögzítése.
3. Valódi megerősítő levél kézbesítése.
4. A fiók megerősítése.
5. Jelszó-visszaállítás levélből.
6. Belépés az új jelszóval, a régi elutasításának ellenőrzése.
7. Új téma és válasz beküldése, majd adminisztrátori jóváhagyás.
8. A saját próbaadatok eltávolítása.

Ezek a próbák saját technikai postafiókkal történtek. Az ideiglenes jelszavakat nem tettük a jelentésekbe, és a teszt végén eltávolítottuk a hozzájuk tartozó ideiglenes helyi tárolót.

A MySQL–MariaDB eltérés

Egy bejegyzésküldési próba adatbázishibát adott. A hiba vizsgálata alapján a fórum MySQL-meghajtót használt a MariaDB-adatbázishoz. Egy JSON-művelet eltérő SQL-szintaxisa miatt akadt meg a kérés.

A konfiguráció megfelelő meghajtóra állítása után a téma és a válasz létrehozása működött. A Flarum dokumentációja külön hangsúlyozza, hogy a konfigurált meghajtónak meg kell felelnie a tényleges adatbázisszervernek. [8]

Ez célzott javítás volt, nem adatbáziscsere. Előtte mentés készült, és a kapcsolódási jelszó változatlan maradt.

A jóváhagyás szándékos működés

Az új tag bejegyzése nem feltétlenül jelenik meg azonnal. A mi induló fórumunkon előzetes jóváhagyást állítottunk be.

Ez segíti a moderációt, de rendszeres emberi figyelmet is igényel. Az asszisztenssel elkészített fórum sem válik magától gondozott közösséggé: a kérdések megválaszolása és a jelentések kezelése üzemeltetői feladat.

11. Milyen hibákat találtunk még a tesztelés során?

Régi JavaScript és új szerveroldali ellenőrzés

A regisztrációs szerver már az új szabályzatverziót várta, de a böngésző még a régi gyorsítótárazott kódot kapta. A kérés ezért elutasítást kapott. A szerver ezzel a beállított feltételt érvényesítette.

Az alkalmazás gyorsítótárának frissítése és a megismételt valódi próba igazolta a javítást. A jövőbeli változtatásoknál a kliens- és szerveroldali verzió összehangolását is ellenőrizni kell.

A tesztszkript is hibázhat

Az egyik saját ellenőrzőszkript rosszul olvasott ki egy HTTP-válaszállapotot. Ettől a beküldés már megtörténhetett, miközben a teszt hibát jelzett.

Nem kattintottunk újra automatikusan. Előbb visszaolvastuk a fórum tényleges állapotát, majd a már létrejött próbaválaszt ellenőriztük. Így nem készítettünk indokolatlan ismétlést.

Máskor a túl gyors beküldéseket az áradásvédelem korlátozta. A védelmet megtartottuk, és később folytattuk a próbát.

Egy gomb hibáját a látogató oldaláról is meg kell érteni

Az indulás után visszajelzés érkezett, hogy a fórumgomb nem működik. Friss vendégböngészőben a tényleges kattintás már megnyitotta a fórumot. A projektgazdánál az oldal frissítése után szintén működött.

Ebből nem következik, hogy minden hasonló hiba gyorsítótár-probléma. Nálunk a frissítés megoldotta a helyzetet, a korábbi hibát pedig nem sikerült reprodukálni. Nem neveztünk meg utólag bizonyítatlan biztos okot.

12. Mitől lett ellenőrizhető a munka?

A „kész” állítás mellé konkrét bizonyítékot tettünk.

Egy HTTP 200-as válasz önmagában nem bizonyítja, hogy a tartalom helyes. A képernyőkép pedig nem igazolja, hogy egy űrlap mögött működik az adatbázis. A különböző ellenőrzések más kérdésre adnak választ.

A mobiltesztek egy része böngészős emuláció volt. Ezt nem neveztük minden valódi telefonon végzett vizsgálatnak. Az automatikus ellenőrzéseket a projektgazda saját eszközön adott visszajelzései egészítették ki.

13. Hogyan védtük a mentéseket és a hozzáférési adatokat?

A nyilvános webkönyvtár, a privát alkalmazásfájlok és a mentések külön szerepet kaptak. Adatbázismentést és részletes diagnosztikai kimenetet nem hagytunk nyilvánosan letölthető helyen.

A fórum mentéseinél titkosítást és visszafejtéssel ellenőrzött tartalmi egyezést használtunk. A helyreállítási kulcs külön tárolásáról a projektgazda gondoskodott. A fájl egyezését mutató SHA-256 önmagában nem titkosítás és nem bizonyítja, hogy a tartalom biztonságos.

A Windows által védett helyi hitelesítőtárolás segített elkerülni a jelszavak egyszerű szövegként való kezelését. Ettől még az adott felhasználó nevében futó programok hozzáférhetnek a számukra visszafejthető adatokhoz. Ez nem helyettesíti a megfelelő Windows-jogosultságot és a körültekintő eszközhasználatot.

A felhőben szinkronizált meghajtón készített másolatot visszaolvastuk és összehasonlítottuk. Ez a helyi példány egyezését igazolta; a felhőszinkron tényleges befejezését nem állítottuk külön bizonyíték nélkül.

Egy visszaállításnál az adatokat is figyelembe kell venni. Ha az indulás óta valódi felhasználók regisztráltak vagy hozzászóltak, egy régi adatbázismentés vak visszaállítása elveszítheti a munkájukat.

14. Hogyan élesítettünk?

Az indulás előtt rögzítettük a módosítandó fájlokat, a kiinduló állapotot és a visszaállítás menetét. A fórumot először jelszóvédett környezetben próbáltuk ki. A sikeres ellenőrzések és a próbaadatok eltávolítása után nyitottuk meg a vendégelérést és a regisztrációt.

A fő weboldalról csak ezután kapcsoltuk be a fórumhoz vezető belépési pontot. Végül külön, bejelentkezés nélküli böngészőben is kipróbáltuk az oldalt.

A projekt egy későbbi pontján a helyi forrás és az éles tartalom már eltért egymástól. Ilyenkor nem indítottunk ellenőrizetlen teljes újraépítést: az engedélyezett aloldal célzott módosítását végeztük el, és az eltérést dokumentáltuk.

Általános tanulságként érdemes egyetlen, naprakész forrásállapotra és ismételhető kiadási folyamatra törekedni. Egy eseti javítás után ezt rendezni kell, különben a következő feltöltés régebbi szöveget vagy beállítást hozhat vissza.

15. Mikor találja meg a Google a weboldalt?

A nyilvános elérés és a keresőbeli megjelenés külön dolog. Az egyik azt jelenti, hogy az ember meg tudja nyitni a címet. A másikhoz a keresőnek fel kell fedeznie, le kell kérnie és fel kell dolgoznia a tartalmat.

A fejlesztési szakaszban a fórum keresőkorlátozásokat kapott. A nyilvános indulás után ezeket külön lépésben oldottuk fel.

A robots.txt a feltérképezéshez ad utasítást. A noindex az indexelést tiltja. Ha a robot nem olvashatja be az oldalt, a rajta lévő noindex jelölést sem feltétlenül látja. Egyik sem hozzáférés-védelem. [9]

A főoldalhoz és a fórumhoz is oldaltérképet biztosítottunk. A fórum változó nyilvános témalistájából automatikusan készülő változatot használtunk. Az adminisztrációs és fiókkezelő oldalak nem kerültek a nyilvános keresőcélok közé.

Az oldaltérképek címét a megfelelő robots.txt fájlban megadtuk. Ez a Google által támogatott felfedezési mód. Az oldaltérkép nem garantálja minden oldal felvételét vagy jó helyezését; a feldolgozás Search Console-ban később követhető. [10]

16. Miért vezettünk átadási dokumentumot?

A projekt több napon és beszélgetésen át készült. Egy idő után a „folytassuk onnan” nem volt elég pontos.

Az átadási dokumentumban ezért feljegyeztük:

• mi működik ténylegesen;
• milyen fájl és beállítás változott;
• mi a teszt és mi az éles környezet;
• milyen ellenőrzések sikerültek vagy maradtak el;
• milyen hiba történt, és mit bizonyít a javítása;
• hol van mentés, és mi kell a helyreállításhoz;
• mely kérdések maradtak nyitva.

Az operatív átadás privát dokumentum: lehetnek benne belső elérési utak és munkafolyamat-azonosítók. Ezt nem szabad ellenőrzés nélkül nyilvános cikké alakítani. A mostani íráshoz a tanulságokat általánosítottuk, a belső adatokat kihagytuk.

17. Mit javaslunk annak, aki most kezdene hasonló projektet?

Először egy kicsi, működő változatot készíts: főoldal, néhány valódi cikk és egyszerű navigáció. Utána adj hozzá egyenként dinamikus funkciókat.

A kezdési sorrend lehet:

1. Írd le a célközönséget és az első öt hasznos tartalmat.
2. Válassz tárhelyet a szükséges technológiák alapján.
3. Készíts külön projektmappát és tesztkörnyezetet.
4. Ellenőrizd a távoli eszköz hozzáférését olvasási feladattal.
5. Készíts egy kis, tesztelhető változtatást.
6. Ellenőrizd a működést és a megjelenést.
7. Készíts mentést és visszaállítási tervet.
8. Csak ezután lépj tovább az éles kiadásra.

A tárhely és domain, az esetleges ChatGPT-csomag, a kapcsolódó szolgáltatások és a saját időd költségét is számold bele. A mi projektünkből nem következik általános „ingyenes, egykattintásos” megoldás vagy garantált elkészülési idő.

A szerver üzemeltetését, a frissítéseket, a szerzői jogi és adatkezelési kérdéseket, valamint a közösség moderálását az AI-val készített kód sem oldja meg egyszer és mindenkorra. Nálunk is maradtak pontosítandó szolgáltatói részletek. Az éles technikai működést nem neveztük teljes jogi megfelelőségi tanúsításnak.

Minta a következő feladat kiadásához

Készítsd el a megadott funkciót az elkülönített tesztkörnyezetben. Előbb olvasd el az aktuális átadást, majd rögzítsd a kiinduló állapotot. A szükséges, jóváhagyott változtatásokat végezd el, és ellenőrizd a működést. A jelentésben külön nevezd meg a megfigyelt eredményt és a bizonytalan pontokat. Titkot ne írj a beszélgetésbe. Ha emberi bejelentkezés szükséges, jelezd.

Ez nem minden projektre kötelező szabályzat. Olyan munkaminta, amely nálunk segített abban, hogy egy hosszabb fejlesztés követhető és folytatható maradjon.

18. Mire jutottunk?

Az OkosHorizont készítése megmutatta, hogy ChatGPT engedélyezett helyi eszközökkel és ellenőrzött munkafolyamattal a tervezéstől a működő weboldalig tud segíteni. A laptop elérését a külön csatlakoztatott szolgáltatás, a böngészős munkát az előkészített profil és automatizálás, a tárhelyhez való hozzáférést pedig a projektgazda bejelentkezése tette lehetővé.

A munka közben az AI által írt kód és a saját tesztszkriptek is hibáztak. Az előrehaladást a valódi működési próbák, a mentések és a visszaolvasott eredmények igazolták.

Ha hasonló projektet indítasz, az első jó kérdésed ez lehet: „Mivel tudjuk majd bizonyítani, hogy ez a lépés valóban sikerült?”

Hivatalos források és további olvasnivaló

Az alábbi dokumentumokat a kézirat készítésekor, 2026. október 18-án ellenőriztük. A külső szolgáltatások útmutatóit használat előtt ismét érdemes megnyitni.

1. OpenAI: Remote Desktop Commander – képességek és hozzáférhetőség.
2. Desktop Commander: Remote kapcsolat beállítása – párosítás és alkalmazáskapcsolat.
3. Desktop Commander: Remote Device útmutató – indítás, leállítás és engedély-visszavonás.
4. Desktop Commander: projektleírás – működés és jogosultsági korlátok.
5. Node.js: hivatalos letöltés – aktuális kiadások.
6. Chrome: a távoli hibakeresési kapcsolók biztonsági változásai – elkülönített profil használata.
7. Playwright: connectOverCDP – csatlakozás Chromium-böngészőhöz.
8. Flarum: telepítés és adatbázis-követelmények – a megfelelő adatbázis-meghajtó kiválasztása.
9. Google Search Central: noindex – az indexelési tiltás és a feltérképezés kapcsolata.
10. Google Search Central: oldaltérképek készítése és megadása – oldaltérkép és keresőbeli feldolgozás.

---

A cikkben szereplő számítógépes útvonalak és telepítési példák általánosítottak. Személyes adatot, valódi eszközazonosítót, jelszót, belépési tokent és helyreállítási kulcsot nem közlünk.