Prieglobsčio valdymas paprastai nutraukia kūrimo procesą. Jūs rašote kodą redaktoriuje, atidarote prieglobos valdymo skydelį svetainei sukurti, persijungiate į terminalą projektui supakuoti arba išsiųsti, grįžtate į skydelį diegimui patikrinti ir atidarote daugiau įrankių, kai reikia tvarkyti DNS, žurnalus ar serverio išteklius.

Hostinger Connector sumažina šį konteksto perjunginėjimą. Jis sujungia Hostinger paslaugas su AI kodavimo įrankiais per Model Context Protocol (MCP), todėl galite paprašyti AI asistento patikrinti arba valdyti palaikomus prieglobos išteklius nepalikdami redaktoriaus.

Skamba patogiai. Tačiau kyla svarbesnis klausimas: ar galite pasitikėti AI asistentu, kad jis tiksliai atliks realias prieglobos užduotis?

Norėdamas tai išsiaiškinti, išbandžiau Hostinger Connector su VS Code ir GitHub Copilot tikroje Hostinger paskyroje. Naudojau nedidelę Express.js programą „PulseWatch“ ir sekiau darbo eigą nuo įdiegimo iki tiesioginio diegimo. Taip pat testavau pakartotinius diegimus, kūrimo įrašus, žurnalus ir atkūrimą tyčia sugadinęs programos paleidimo komandą.

Hostinger Connector Plans with Hostinger

Integruokite Hostinger su programėlėmis ir paslaugomis, kurias jau naudojate, kad automatizuotumėte užduotis, pagerintumėte darbo eigas ir efektyviau valdytumėte savo svetainę.

Aplankykite Hostinger

Hostinger Connector privalumai ir trūkumai

Įvertinimo suskirstymas

Štai kaip įvertinau Hostinger Connector pagal sritis, kurios labiausiai svarbios kūrėjui, nusprendžiančiam, ar naudoti šį įrankį: kainą, funkcijų spektrą, kasdienį naudojimą, tikslumą vykdant realias užduotis ir palaikymą, kuris padeda, kai kas nors nepavyksta. Kiekvienas balas atspindi tai, ką iš tikrųjų radau testavimo metu, o ne rinkodaros puslapyje.

Hostinger Connector planai ir kainos

Hostinger Connector neparduodamas kaip atskiras produktas. Hostinger teigia, kad Connector įtrauktas nemokamai į kiekvieną planą, todėl prie hostingui skirtos sąskaitos nereikia pridėti jokio atskiro mėnesinio Connector mokesčio.

Tačiau „nemokamai“ reikia vertinti kontekste. Connector valdo Hostinger išteklius; jis jų nepakeičia. Vis tiek reikia tinkamos Hostinger hostingo, cloud, VPS, domeno, el. pašto ar kitos paslaugos užduotims, kurias norite, kad jis atliktų.

Šios apžvalgos metu Connector nukreipimo puslapyje buvo pateikti Business Web Hosting ir Cloud Startup planai.

Kainos buvo rodomos prieš taikomus mokesčius. Promocinės kainos ir atnaujinimo tarifai gali keistis, todėl tikrinkite dabartinę galutinę kainą, o ne vertinkite planą vien pagal nurodytą mėnesinę sumą.

Įžvalga apie kainodarą: Nepirkite brangesnio plano vien tam, kad gautumėte prieigą prie Connector. Rinkitės planą pagal reikalingų svetainių ir web programėlių skaičių, jų reikalaujamus išteklius ir norimą palaikymo lygį. Connector yra įtrauktas valdymo sluoksnis, o ne pagrindinis produktas, už kurį mokama.

Hostinger skelbia 30 dienų pinigų grąžinimo garantiją tinkamiems hostingo pirkiniams. Atskiros Connector grąžinimo politikos nėra, nes Connector neturi atskiro mokesčio.

Hostinger Connector Plans with Hostinger

Integruokite Hostinger su programėlėmis ir paslaugomis, kurias jau naudojate, kad automatizuotumėte užduotis, pagerintumėte darbo eigas ir efektyviau valdytumėte savo svetainę.

Aplankykite Hostinger

Funkcijos

• Node.js programos diegimas
• PHP ir HTML diegimas
• WordPress svetainės valdymas
• Website Builder ir Horizons darbo eigos
• GitHub susieti diegimai
• Domenų prijungimas ir organizavimas
• DNS tikrinimas ir atnaujinimai
• SSL ir svetainės diagnostika
• Duomenų bazių valdymas
• VPS sąranka ir administravimas
• Docker projekto diegimas
• CPU ir atminties stebėjimas
• Pralaidumo ir disko patikra
• Paslaugų ir konteinerių paleidimas iš naujo
• Kenkėjiškos programos skenavimas
• Atsarginės kopijos atkūrimas
• El. pašto kampanijos sąranka
• Diegimo ir kūrimo patikra

Tikslios galimos veiksmo parinktys priklauso nuo Hostinger paslaugų jūsų paskyroje ir nuo įrankių, kuriuos atskleidžia prijungtas AI klientas.

Hostinger taip pat dokumentuoja dažnio ribas. Pagal Connector DUK, numatytoji leidžiama apimtis yra 60 užklausų per minutę ir 1 000 užklausų per valandą, o ribų informacija grąžinama atsakymo antraštėse.

Šios ribos yra dosnios interaktyviam naudojimui, nors automatizuotos ar labai pasikartojančios darbo eigos vis tiek turėtų vengti nereikalingų dublikuotų užklausų.

Naudojimo paprastumas

1. Įdiegimas ir autentifikavimas

Prieš galėdamas įvertinti, ar Hostinger Connector gerai diegia ir valdo prieglobą, turėjau sužinoti, ko reikia, kad jis apskritai pradėtų veikti.

Įrankis, sukurtas taip, kad būtų galima likti redaktoriuje, greitai praranda savo patrauklumą, jei sąranka reiškia konfigūracijos failų redagavimą, API prieigos raktų generavimą ar pakartotinę autentifikaciją. Šiame skyriuje aptariama tik sąranka. Praktinis užduočių testavimas pateikiamas iškart po to.

Plėtinio įdiegimas

Hostinger Connector įdiegiau iš VS Code Marketplace. Paieškoje „Hostinger“ jis pasirodė pirmas, leidėjas buvo nurodytas kaip Hostinger Official, ir įsidiegė iš pirmo karto per mažiau nei dvi minutes.

Ta paskutinė eilutė verta pastabos. Penkios žvaigždutės skamba stipriai, bet dviejų atsiliepimų imtis man beveik nieko nepasako apie įprastą vartotojo patirtį. Nevertinčiau šio skaičiaus apžvalgos tekste.

Vienas reikalavimas mane nustebino: Hostinger Connector pateikia Hostinger įrankius, bet jam reikia jau aktyvaus AI agente redaktoriuje, kad jis iš tikrųjų galėtų juos iškviesti.

Pats plėtinys neturi su kuo kalbėtis. VS Code aplinkoje toks agentas yra GitHub Copilot Chat, nes šiuo metu tai yra AI sąsaja, kurią VS Code pateikia MCP įrankių iškvietimams. Aš Copilot jau turėjau aktyvų, todėl tai manęs nesustabdė, bet skaitytojai turėtų žinoti, kad Connector yra naudingas tik tiek, kiek naudingas AI agentas, esantis už jo.

Be įdiegto ir prisijungusio agento jis neturi prie ko prisijungti.

Ko nereikėjo įdiegti:

• API rakto
• hPanel nukopijuoto žetono
• Rankiniu būdu redaguoti MCP konfigūracijos failo
• Vietoje saugomų prisijungimo duomenų
• Pasirinktinės serverio komandos

Pats plėtinio įdiegimas buvo viena sklandžiausių viso testo dalių. Vienintelis tikras niuansas yra priklausomybė, kurios Hostinger nelabai išryškina: plėtiniui reikia aktyvaus AI agente jūsų redaktoriuje, kad jis apskritai ką nors veiktų.

Įdiegus plėtinį, kitas klausimas buvo, ar prijungti jį prie tikros paskyros bus taip pat paprasta.

Paskyros prijungimas

Paskyros prijungimas vyko per OAuth naudojant mygtuką „1-Click Connect“. VS Code naršyklėje atidarė Hostinger autorizacijos puslapį, aptiko mano esamą Hostinger sesiją ir paprašė patvirtinti prieigą kažkam, kas buvo pavadinta hostinger-mcp.

Paspaudus Allow, buvau grąžintas į VS Code, kuriame buvo rodoma „Connected via OAuth“.

Autorizacijos ekranas nurodė, kad Connector gali valdyti svetaines, hostingą, domenus, prenumeratas ir kitas Hostinger paslaugas.

Tai yra kategorijų sąrašas, o ne leidimų po vieną išskaidymas. Norėjosi daugiau detalumo, nes „valdyti prenumeratas“ ir „valdyti svetaines“ reiškia labai skirtingą rizikos lygį.

Šiek tiek kontrolės suteikė atskiras plėtinio skydelis, kuriame išvardytos visos įrankių kategorijos ir galima kiekvieną įjungti arba išjungti atskirai:

Iš viso yra 199 įrankiai, iš kurių 125 įjungti pagal numatytuosius nustatymus. Aš palikau Elektroninė prekyba ir VPS išjungtus, kol nebuvau pasiruošęs jų testuoti tiesiogiai, ir plėtinys viso testo metu gerbė šią ribą.

Tokia saugumo detalė nesimato Hostinger rinkodaros puslapyje, bet ji svarbi kiekvienam, kuris sprendžia, kiek prieigos suteikti AI asistentui. Aš tai laikyčiau tikru privalumu.

Atjungti paskyrą galima iš to paties skydelio, be poreikio keisti Hostinger slaptažodį ar ieškoti išsaugoto žetono.

Autorizacija buvo greita ir nereikalavo, kad pats tvarkyčiau žetoną, tačiau leidimų ekranas yra platus, o ne detalus. Kategorijų lygmens įrankių valdikliai plėtinyje daug geriau sumažina realią riziką nei OAuth ekranas.

Palaikomi redaktoriai

Hostinger nurodo šių klientų palaikymą, remiantis paties plėtinio įvedimo ekranu:

Pagrindinėje testo aplinkoje naudojau VS Code su GitHub Copilot.

Sąranka man pasakė, kad Connector yra lengva pasiekti. Tačiau tai dar nieko nepasakė apie tai, ar jis iš tikrųjų gerai atlieka darbą po prijungimo, o būtent šis sunkesnis klausimas buvo toliau nagrinėjamas.

2. Hostinger Connector veiksme

Plėtinio įdiegimas ir prijungimas yra lengvoji dalis. Iš tiesų svarbu, ar jis teisingai atlieka realų prieglobos darbą, todėl sukūriau nedidelę Express.js programą „PulseWatch“ ir patikrinau Connector taip, kaip kūrėjas veiktų po įdiegimo: peržiūrėti paskyrą, rasti diegimo tikslą, įdiegti projektą, atnaujinti jį, patikrinti rezultatus ir atkurti klaidą, kurią sukėliau tyčia.

„PulseWatch“ buvo tyčia paprasta: Express serveris, pagrindinis puslapis, package.json start skriptas ir /api/health end point, grąžinantis JSON. Tas sveikatos end point vėliau pasirodė labai svarbus.

Prieglobos platforma gali rodyti užbaigtą kūrimą net tada, kai programa nepasileidžia. Tiesioginis end point suteikė man nepriklausomą būdą patikrinti, ar įdiegtas procesas iš tikrųjų atsako, užuot pasikliovus būsenos ženkleliu.

Paskyros duomenų nuskaitymas

Pirmiausia naudojau tik skaitymo užklausas, prieš leisdamas asistentui ką nors keisti tiesiogiai. Jei jis negalėjo tiksliai apibūdinti mano paskyros, neturėjau jokios priežasties juo pasitikėti diegimams, DNS ar VPS veiksmams.

Connector svetainių sąrašo įrankis grąžino penkias svetaines:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Mano paskyroje iš tikrųjų buvo daugiau nei tiek. hPanel rodė svetaines, paskirstytas per Premium, Business ir Growth planus, įskaitant WordPress svetaines, PHP/HTML svetaines, Website Builder projektus ir kelis laikinus domenus.

Kitame klausime, kuriame teiravausi apie aktyvius prieglobos planus, asistentas man pasakė, kad turiu „vieną aktyvų hostingo planą“. hPanel rodė tris: Premium, Growth ir Business.

Teisybės dėlei reikia pasakyti, kad kai aš prieštaravau ir nurodžiau neatitikimą, jis pats pasitaisė, aiškiai atskyrė tai, ką buvo patvirtinęs, nuo to, ką buvo prielaidomis laikęs, ir nekartojo klaidingo teiginio.

Tai geresnis klaidos elgesys nei užsispyręs tvirtinimas, bet vis tiek reiškia, kad pirmas atsakymas į su visos paskyros planais susijusį klausimą neturėtų būti laikomas galutiniu.

Tik skaitymo prieiga veikė, bet pirmas atsakymas į bet kurį su visa paskyra susijusį klausimą buvo neišsamus. Jis pasitaisė, kai buvo sukritikuotas, ir tai svarbu, bet man neturėjo prireikti to nurodyti.

Tas paskyros matomumo trūkumas pasirodė esąs didesnės problemos užuomina. Tikrasis testas, ar tai svarbu, buvo toliau, kai paprašiau Connector surasti svetainę, kurios jis niekada nebuvo gavęs pagal vardą.

Hostinger Connector Plans with Hostinger

Integruokite Hostinger su programėlėmis ir paslaugomis, kurias jau naudojate, kad automatizuotumėte užduotis, pagerintumėte darbo eigas ir efektyviau valdytumėte savo svetainę.

Aplankykite Hostinger

Diegimo tikslo radimas

Čia testavimas atskleidė daugiausia. Paprašiau asistento identifikuoti naujai sukurtą Node.js svetainę, nenurodydamas domeno, ir neliesdamas jokios jau egzistuojančios svetainės.

Tikslo pasirinkimas yra pagrindinis saugumo reikalavimas įrankiui, kuris gali veikti tiesioginėje paskyroje, todėl norėjau pamatyti, kaip jis elgiasi esant neapibrėžtumui, o ne esant aiškiam atsakymui.

Štai kas įvyko, eilės tvarka:

Pagrindinė problema: du ID, kuriuos jis naudojo, buvo domeno išteklių ID, o ne hostingo užsakymo ID. Jis niekada nepatvirtino šio skirtumo prieš iškviesdamas tiesioginį svetainės kūrimo įrankį su jais.

Kai paprašiau jo paaiškinti, asistentas galiausiai pateikė tikslų paaiškinimą: jis visą laiką turėjo veikiančią svetainių sąrašo įrankį, bet po to, kai hPanel sukūriau naują svetainę, jo dar kartą neiškvietė, todėl užpildė spragą nepatikrintu domenu, užuot atnaujinęs duomenis.

Kai tiesiogiai paprašiau jo dar kartą paleisti tą sąrašo įrankį ir patikrinti, ar atsirado naujas įrašas, jis vietoje to iškvietė tris nesusijusius diegimo paieškos įrankius ir pranešė, kad „jokios naujos svetainės neatsirado“, nors įrankių iškvietimai, kuriuos jis iš tikrųjų atliko, to negalėjo pagrįsti.

Visa tai nesukūrė jokios papildomos svetainės mano paskyroje. Nesėkmingi iškvietimai nieko nepaliko po savęs. Tačiau modelis vertas aiškaus įvardijimo. Turėdamas neišsamius duomenis, asistentas užpildė spragą tikėtina, bet nepatikrinta prielaida, silpną signalą palaikė stipriu įrodymu ir veikė tiesioginėje paskyroje dar prieš tai patikrindamas.

Tai svarbiausia šio skyriaus išvada. Connector spėlios apie tikslą ir veiks pagal tą spėjimą, užuot sustojęs ir paklausęs. Šiuo atveju jis nesukėlė žalos, bet toks polinkis silpną signalą laikyti įrodymu yra dalykas, į kurį verta atkreipti dėmesį savo paskyroje.

Kadangi Connector pats negalėjo rasti tikslo, liko vienintelė išeitis: susikurti tikslą pačiam ir pažiūrėti, ar tai ką nors pakeis.

Pabaigti sąranką hPanel

Kadangi Connector pats patikimai nerado naujo tikslo, pirmąją sąranką užbaigiau rankiniu būdu per hPanel, kad pamatyčiau, ką Hostinger parengia prieš tai, kai tampa įmanomas Connector pagrindu veikiantis diegimas.

Kelias buvo toks: Create a new site → Node.js web app → temporary domain → Hostinger automatiškai parinko Jungtinės Karalystės duomenų centrą su maždaug 147ms delsa → trys diegimo metodai.

Šis trečias ekranas vertas atskiro paminėjimo. Hostinger siūlo „Build with Hostinger Connector“ kaip diegimo metodą kartu su GitHub importu ir rankiniu failų įkėlimu. Pasirinkau jį tikėdamasis, kad jis užbaigs svetainės sąranką.

Vietoj to jis nukreipė mane į paties Connector diegimo puslapį, kurį aš jau buvau užbaigęs. Tai tikra įvedimo į sistemą spraga. Parinktis, pateikta kaip Connector natūralus kelias, iš tikrųjų nieko nesukonfigūravo.

Grįžau atgal ir pasirinkau rankinį failų įkėlimą. Hostinger priėmė mano projekto archyvą (11.46 KB, be node_modules ), o nustatymų ekranas rodė teisingą automatinį aptikimą:

• Framework preset: Express
• Node version: 22.x
• Root directory: ./

Paspaudžiau Deploy. Jis sėkmingai užsibaigė, ir Hostinger priskyrė tikrą laikiną domeną: orange-walrus-700988.hostingersite.com. Tai kitas domenas nei tas, kurį anksčiau buvo išgalvojęs Connector. Puslapį ir /api/health atidariau rankiniu būdu ir patvirtinau, kad abu veikia.

Rankinis kelias veikė be trukdžių, kai tik nustojau laukti, kol Connector suras tikslą. „Build with Hostinger Connector“ mygtukas šiame ekrane turėtų būti sutvarkytas arba pašalintas. Šiuo metu jis žada tai, ko neatlieka.

Dabar egzistavo tikra, patvirtinta svetainė. Kitas klausimas buvo, ar Connector elgsis kitaip, kai turės tvirtą tikslą.

Tiesioginės programos diegimas ir atnaujinimas

Turėdamas tikrą, patvirtintą svetainę, grįžau į Connector ir paprašiau jo patikrinti būtent tą domeną. Šį kartą viskas veikė sklandžiai.

Tai patvirtino svarbų dalyką: ankstesni gedimai buvo susiję su naujo tikslo suradimu ir sukūrimu, o ne su Connector gebėjimu dirbti su Node.js svetaine, kai ji jau egzistuoja.

Tada išbandžiau funkciją, kurią Hostinger labiausiai reklamuoja: pakeisti kodą lokaliai ir paskelbti jį neatsidarant hPanel.

Paprašiau asistento pakeisti vieną pagrindinio puslapio teksto eilutę iš „Monitor Every Service. Catch Every Issue.“ į „Monitor Every Service. Resolve Issues Faster.“.

Visas atnaujinimas užtruko apie minutę. Asistentas naują diegimą iškart po išsiuntimo rodė kaip „pending“, nes tikrino per anksti, kol Hostinger dar buvo baigimo procese.

Kai aš pats atnaujinau tiesioginę svetainę, nauja antraštė jau buvo ten.

Vėliau gauti kūrimo žurnalai buvo konkretūs ir naudingi: pridėta 67 paketai, patikrinta 68, pažeidžiamumų nerasta, klaidų nėra.

Tai artimiausias rezultatas tam darbo srautui, kurį Hostinger žada. Redaguoti, patikrinti lokaliai, išsiųsti ir patvirtinti, visa tai nepaliekant redaktoriaus, maždaug per minutę. Tai stipriausias rezultatas visame teste.

Švarus diegimas tik parodo, kad „laimingas“ kelias veikia. Kad sužinočiau, ką Connector iš tikrųjų daro spaudimo sąlygomis, tyčia sugadinau programą.

Klaidos atkūrimo testavimas

Įrankis užsitarnauja pasitikėjimą tik tada, kai susiduria su tikra klaida, o ne vien su švaria demonstracija. Tyčia sugadinau programą, kad pamatyčiau, ar Connector būsenos ataskaitos ir žurnalai gali padėti diagnozuoti problemą.

Prieš atlikdamas bet kokį pakeitimą, asistentas padarė package.json atsarginę kopiją į package.json.bak, ir tai jau savaime yra geras įprotis.

Tada paprašiau jo pakeisti start skriptą iš “start”: “node server.js” į “start”: “node missing-server.js”, tai yra failą, kurio nėra.

Paleidus lokaliai, patvirtintas tikras gedimas: Error: Cannot find module ‘…/missing-server.js’.

Specialiai įdiegiau sugadintą versiją, kad pamatyčiau, ką apie tai praneš Hostinger.

Kūrimo žurnalai, kuriuos gavau per Connector, rodė sėkmingą priklausomybių įdiegimą ir daugiau nieko. Trūkstamo modulio vykdymo klaida juose niekada nepasirodė. Kūrėjas, pažvelgęs į žalią „completed“ ženklą, neturėtų jokio pagrindo įtarti, kad svetainė sugedusi.

Atkūrimas vyko sklandžiai. Asistentas atstatė package.json iš atsarginės kopijos, patikrino programą lokaliai, iš naujo ją įdiegė ir patvirtino pataisymą tiesiogiai iškviesdamas /api/health end point, o ne pasitikėdamas vien diegimo būsena.

Tas end point grąžino veikiantį atsakymą, ir tai buvo vienintelis įrodymas visame teste, kuris iš tikrųjų parodė, kad programa veikia.

Tai yra antroji svarbi išvada. Užbaigta būsena nėra įrodymas, kad programa veikia, ir paties Connector žurnalai to neparodys. Pats atkūrimas veikė gerai, kai jau žinojau, kad yra problema, kurią reikia atkurti.

Po gedimo, kurio būsenos ženklelis negalėjo parodyti, norėjau sužinoti, kur dar Connector pasitikėjimas gali aplenkti jo tikrąjį gebėjimą. Kitas testas buvo aplinkos kintamieji.

Bandymai konfigūruoti aplinkos kintamuosius

Paprašiau asistento pridėti nekenksmingą aplinkos kintamąjį, patvirtinti, kad kaip atskira Connector galimybė egzistuoja toks nustatymas, prieš ką nors keičiant, ir sustoti, jei jo nėra.

Jis peržiūrėjo galimus įrankius, nerado jokio specialaus veiksmo Node.js aplinkos kintamiesiems valdyti ir sustojo prieš atlikdamas bet kokius kodo ar diegimo pakeitimus.

Tai yra elgesys, kurį norėjau matyti visur kitur šiame teste. Susidūręs su tikru apribojimu, jis sustojo vietoje to, kad spėliotų. Nereikėtų daryti išvados, kad Hostinger Connector neturi aplinkos kintamųjų palaikymo jokioje savo įrankių rinkinio vietoje — tik kad toks veiksmas nebuvo pateiktas per šį testą. 

Klaidos ir atkūrimo testo santrauka

Ką testas sako apie patikimumą

Hostinger Connector gerai atliko įprastas, deterministines užduotis:

• Žinomų diegimo įrašų nuskaitymą
• Konkretaus failo redagavimą
• Vietinių komandų vykdymą
• Projekto pakavimą
• Diegimą į žinomą svetainę
• Kūrimo būsenos tikrinimą
• Galimų žurnalų gavimą
• Žinomos geros versijos atkūrimą ir pakartotinį diegimą

Jis buvo silpnesnis, kai užduočiai reikėjo interpretuoti neišsamius paskyros duomenis:

• Naujai sukurtos svetainės identifikavimui
• Domeno prieinamumo ir svetainės egzistavimo atskyrimui
• Nustatymui, ar užbaigtas kūrimas reiškia, kad programa yra sveika

Šis modelis naudingas sprendžiant, kiek autonomijos suteikti asistentui.

Žemam rizikos lygiui skirtai peržiūrai naudokite platesnes užklausas. Veiksmams, kurie keičia tiesioginę infrastruktūrą, naudokite tikslias užklausas ir aiškius patvirtinimo reikalavimus.

Pavyzdžiui, vietoje:

naudokite:

Antra užklausa susiaurina asistentui paliekamą erdvę prielaidoms.

Bendra naudojimo paprastumo išvada

Hostinger Connector paleisti buvo lengva, be įprastų sąrankos trukdžių, o detalūs įrankių kategorijų valdikliai suteikė man realią galimybę spręsti, ką AI gali liesti.

Kai jau egzistavo tikra svetainė su žinomu domenu, jis puikiai atliko darbą: vienos eilutės teksto pakeitimas nuo redagavimo iki pasirodymo gyvai užtruko apie minutę, o rezultatas buvo pagrįstas naudingais kūrimo žurnalais.

Problemos prasidėjo anksčiau procese, ne vėliau. Susidūręs su nauju tikslu, kurio negalėjo rasti, Connector išgalvojo domeną ir veikė pagal jį dar prieš patikrindamas. Jis taip pat pažymėjo sugadintą diegimą kaip „completed“, nors programa iš tikrųjų neveikė, o jo paties žurnaluose nebuvo vykdymo klaidos. Nė viena iš šių problemų nereiškia, kad įrankis nepatikimas jau egzistuojančioms svetainėms, bet abi reiškia, kad naujus diegimus ir po diegimo rodytą būseną reikia dar kartą patikrinti prieš visiškai jais pasitikint.

Hostinger Connector Plans with Hostinger

Integruokite Hostinger su programėlėmis ir paslaugomis, kurias jau naudojate, kad automatizuotumėte užduotis, pagerintumėte darbo eigas ir efektyviau valdytumėte savo svetainę.

Aplankykite Hostinger

Palaikymo lygis

Hostinger savo palaikymą grindžia tiesioginiu pokalbiu ir savitarna, o ne skambučiais, todėl sutelkiau testavimą į vietas, kur dažniausiai patenka naudotojai: į AI asistentą hPanel viduje, žmogišką eskalavimą už jo ir žinių bazę, į kurią kūrėjas kreiptųsi prieš atidarydamas pokalbį.

Palaikymo kanalai

Kadangi tiesioginis pokalbis yra kanalas, kurį Hostinger siūlo kūrėjams viskam, kas skubu, ir tas, kuriuo greičiausiai bus naudojamasi derinant diegimą, išbandžiau būtent šį kelią, o ne siųsdamas el. pašto užklausą.

Tiesioginis pokalbis: Kodee ir perkėlimas žmogui

Atidariau tiesioginį pokalbį per „Ask AI“ hPanel ir uždaviau Kodee klausimą, į kurį lengva būtų suklysti: ar užbaigta kūrimo būsena Node.js diegime garantuoja, kad programa iš tikrųjų veikia, ir kur rasti kitus įrodymus.

Pirmasis Kodee atsakymas buvo konkretus ir teisingas:

„Completed“ paprastai reiškia, kad kūrimo etapas sėkmingai baigtas; tai negarantuoja, kad programa po paleidimo yra sveika. Kad aptiktumėte blogą paleidimo komandą ar kitą vykdymo metu įvykusį gedimą, patikrinkite vykdymo žurnalus: hPanel eikite į Websites → Dashboard → Deployments dėl kūrimo žurnalų, tada atidarykite savo app stderr.log nodejs aplanke, kad rastumėte paleidimo klaidas, tokias kaip Port already in use arba Module not found.

Tas vienas atsakymas būtų išsprendęs lygiai tą dviprasmybę, su kuria anksčiau šiame vertinime susidūrė mano klaidos atkūrimo testas. Kodee įvardijo tikrą žurnalo failą, teisingą aplanką ir aiškiai atskyrė kūrimo sėkmę nuo vykdymo sveikatos.

Tačiau aš taip pat norėjau pamatyti, ar galiu gauti prieigą prie tikro žmogaus agento, todėl pasakiau Kodee, kad norėčiau tai patvirtinti tiesiogiai su palaikymo specialistu.

Tačiau gauti žmogų į pokalbį buvo sunkiau, nei tikėjausi. Paprašiau tiesiogiai gyvo agente ir du kartus buvau nukreiptas atgal į Kodee, kiekvieną kartą pateikiant tai kaip greitesnį variantą nei laukimas:

Suprantu, kodėl norėtumėte to. Galiu padėti jums patikrinti kūrimą, paleidimo komandą ir vykdymo žurnalus čia, ir tai paprastai yra greičiausias būdas nustatyti problemą.

Prieš perduodant specialistui. Galiu išspręsti problemą ir sutaupyti jūsų laukimo laiką.

Prireikė dviejų tiesioginių, aiškių prašymų, kol Kodee nustojo mane grąžinti atgal į save. Klausimui, kurį galėjau išspręsti pats, toks trukdis nėra didelis. Tačiau žmogui, kuris yra incidento viduryje ir nori žmogaus, tai yra tikras nusivylimo taškas.

Tai, kas įvyko toliau, nebuvo tiesioginis perdavimas žmogui ta prasme, kokią paprastai reiškia „sujunkite mane su žmogumi“. Kodee aiškiai paaiškino tikrąjį modelį:

Aš perdaviau jūsų prašymą mūsų komandos specialistui, kuris asmeniškai peržiūrės mūsų pokalbį ir atsiųs man savo atsakymą, kurį aš jums perduosiu čia.

Tai yra asinchroninė peržiūra, o ne tiesioginis perkėlimas. Kodee išlieka sąsaja; žmogus peržiūri transkriptą fone, o Kodee perduoda atsakymą, kai jis gaunamas. Šis skirtumas svarbus skaitytojams, sprendžiantiems, ar eskaluoti, nes čia „žmogaus agentas“ nereiškia, kad naujas asmuo prisijungia prie pokalbio lango taip, kaip tai būtų įprasta daugelyje tiesioginio pokalbio sistemų.

Kol laukiau, tą pačią techninę temą giliau nagrinėjau, paprašydamas Kodee patvirtinti tikslų žurnalo kelią ir ar stderr.log visada būna užpildytas. Jis pateikė gerą atsakymą pats, teisingai pažymėdamas, kad žurnalas gali būti tuščias, jei programa niekada iki galo nepasileido arba klaidą užrašė kitur.

Specialisto peržiūros atsakymas atėjo maždaug po 3 minučių, pokalbyje priskirtas komandos narei, vardu Mayas, ir jis buvo tikslesnis nei Kodee atsakymas:

domains/[your-domain]/nodejs/stderr.log yra teisinga vieta. Ji ne visada sukuriama arba užpildoma. Įrašus joje matysite tik tada, kai programa rašo į stderr, pavyzdžiui, dėl nepagautų išimčių ar neapdorotų atmetimų. Jei paleidimo komanda neteisinga ir procesas baigiasi tyliai, stderr.log gali būti tuščias arba jo gali nebūti.

Mayas taip pat pridėjo du atsarginius patikrinimus, kurių Kodee nepaminėjo: stdout.log tikrinimą dėl paskutinio išvesties prieš gedimą ir startup patvirtinimo eilutės nebuvimą kaip ženklą, kad programa apskritai nepasileido.

Žinių bazė

Hostinger žinių bazė suskirstyta į plačias produktų kategorijas: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel ir About Hostinger.

Nė viena iš šių kategorijų nėra skirta Hostinger Connector. Vienintelis būdas, kuriuo radau tinkamą straipsnį, buvo tiesiogiai ieškoti „Hostinger Connector“, o tai grąžino penkis rezultatus, iš kurių dauguma buvo tik netiesiogiai susiję, įskaitant affiliate rinkodaros įskiepio vadovą ir bendrą Node.js hostingo straipsnį.

Straipsnis, kuriame iš tikrųjų dokumentuojama Connector sąranka, vadinasi „How to Set Up Web Hosting MCP on Local IDEs“, ir yra priskirtas Features → General Information.

Ieškant pagal tikrąjį produkto rinkodaros pavadinimą jį galima rasti, bet skaitytojas, naršantis kategorijomis arba ieškantis „MCP“ nežinodamas Hostinger vartojamo pavadinimo, jį gali lengvai praleisti, o skirtumas tarp rinkodarinio ir dokumentacijos pavadinimo yra vertas žinojimo prieš pradedant ieškoti.

Pats straipsnis yra stiprus, kai jį randate. Jis buvo atnaujintas prieš 6 dienas iki mano testo ir apima:

• Rekomenduojamą vieno paspaudimo OAuth sąranką per plėtinį
• Rankinio nustatymo kelią naudojant API žetoną, skirtą IDE, kurių plėtinys tiesiogiai nepalaiko
• Tikslius konfigūracijos failų kelius Mac, Linux ir Windows sistemoms
• Visus JSON konfigūracijos pavyzdžius
• Žingsnis po žingsnio patvirtinimo užklausą, kad būtų patvirtinta, jog ryšys veikė
• Kuriems palaikomiems klientams ryšys aptinkamas automatiškai, o kuriems reikia rankinio konfigūracijos įvedimo

Šis paskutinis punktas atitiko tai, su kuo susidūriau testuodamas: Devin Desktop aptinkamas automatiškai, o OpenAI Codex reikalauja rankinio metodo. Straipsnyje šis skirtumas nurodytas teisingai.

Bendra palaikymo išvada

Pirmasis Kodee atsakymas į sudėtingą techninį klausimą buvo tikslus ir konkretus, o tai nėra kažkas, ką sugeba kiekvienas AI palaikymo asistentas. Žinių bazės straipsnis, kuris tai pagrindžia, yra atnaujintas ir detalus, kai jį randate, nors produkto rinkodaros pavadinimas ir dokumentacijos pavadinimas nesutampa, todėl paieška yra patikimesnis kelias nei naršymas kategorijomis.

Silpnesnė dalis yra žmogaus eskalavimo kelias. Kodee du kartus mane nukreipė atgal į save, prieš paklusdamas tiesioginiam prašymui žmogaus, o net tada „žmogaus agentas“ reiškia asinchroninę peržiūrą, perduodamą per tą patį pokalbį, o ne tiesioginį perdavimą. Kai žmogus galiausiai pažiūrėjo, atsakymas buvo geresnis nei Kodee, tikslesnis ir su dviem papildomais diagnostiniais žingsniais, kurių Kodee nepasiūlė.

Daugumai klausimų Kodee vienas pats greitai pateiks tikslų atsakymą. Jei iš tikrųjų norite, kad žmogus patvirtintų atsakymą, tikėkitės, jog teks prašyti daugiau nei vieną kartą, ir tikėkitės trumpo laukimo, kol atsakymas bus perduotas, o ne gyvo pokalbio.

Hostinger Connector Plans with Hostinger

Integruokite Hostinger su programėlėmis ir paslaugomis, kurias jau naudojate, kad automatizuotumėte užduotis, pagerintumėte darbo eigas ir efektyviau valdytumėte savo svetainę.

Aplankykite Hostinger

Galutinis verdiktas: ar Hostinger Connector vertas naudojimo?

Taip, kūrėjams, kurie jau hostina su Hostinger ir nori įprastus diegimus tvarkyti iš redaktoriaus. Sąranka truko kelias minutes, OAuth panaikino API raktų poreikį, o kai jau egzistavo svetainė su žinomu domenu, Connector per maždaug minutę paskelbė tiesioginį atnaujinimą su žurnalais, kuriais galima remtis. Kodee palaikymo atsakymai buvo pakankamai tikslūs, kad pirmu bandymu išspręstų realią techninę problemą.

Tačiau esminė rizika yra ne patogumas, o pasitikėjimas. Susidūręs su nauju tikslu, kurio negalėjo rasti, Connector išgalvojo domeną.

Jis taip pat pažymėjo sugadintą diegimą kaip „completed“, nors programa iš tikrųjų neveikė, o jo žurnaluose nebuvo vykdymo klaidos. Naudokite jį, kad pagreitintumėte darbą jau egzistuojančiose svetainėse, patikrinkite viską, ką jis daro su nauju tikslu, ir po kiekvieno svarbaus diegimo patikrinkite tiesioginę svetainę patys.

Hostinger

5.0

2,471 user reviews

1.37 € /mo

Pradinė kaina

Aplankykite Hostinger

Rating based on expert review

• Patogumas
  4.9
• Techninė parama
  4.9
• Funkcijos
  4.8
• Patikimumas
  4.7
• Kainos
  4.5