Näin tarkistat tekoälyn tuottaman koodin

Tekoälyn tuottaman koodin tarkistamiseksi aloita siitä, mikä muuttui – mitkä tiedostot ja miksi – ja testaa toiminta itse ennen kuin luet yhtään koodiriviä. Sen jälkeen tarkista alueet, joilla tekoälyn koodi useimmin menee pieleen: puuttuvat palvelinpuolen käyttöoikeustarkistukset, selaimelle näkyvät salaisuudet, validoimaton syöte, paketit tai funktiot, joita ei ole olemassa, ja muokkaukset asioihin, joita et koskaan pyytänyt koskemaan.

Tekoäly kirjoittaa koodia, joka yleensä toimii ja näyttää siistiltä. Se tekee siitä helppoa hyväksyä koodi tarkistamatta sitä kunnolla. Tämä opas on tarkistusrutiini, joka toimii riippumatta siitä, luetko koodia sujuvasti vai et lainkaan.

Mitoita tarkistus riskin mukaan

Kaikki muutokset eivät vaadi samaa huomiota.

Vaihe 1: Katso, mikä muuttui

Ennen koodin arvioimista hanki luettelo muutoksista:

• Jos projekti on Gitissä, katso diff: tiedostot ja rivit, jotka muuttuivat edellisen commitin jälkeen. Katso kuinka käyttää Gitiä tekoälyllä rakennetun sovelluksen kanssa.
• Tai kysy tekoälyltä suoraan:

Listaa jokainen tiedosto, jonka muutit viimeisimmässä muutoksessa, ja selitä jokaisesta yhdessä lauseessa, mitä muuttui ja miksi.

Punaiset liput tässä vaiheessa: pyyntöön kuulumattomat tiedostot, poistetut tiedostot, konfiguraatio- tai riippuvuusmuutokset, joita et pyytänyt.

Vaihe 2: Testaa toiminta ensin

Koodin lukeminen kertoo, mitä sen on tarkoitus tehdä; testaus kertoo, mitä se tekee. Ennen lukemista:

• Kokeile muutosta tavallisena käyttäjänä, tietokoneella ja puhelimen kokoisella näytöllä.
• Kokeile väärää syötettä: tyhjiä kenttiä, todella pitkää tekstiä, negatiivisia lukuja, menneisyyden päivämäärää.
• Kokeile uloskirjautuneena ja eri käyttäjänä.
• Aja uudelleen tärkeimmät virrat: rekisteröityminen, kirjautuminen, pääasiallinen toiminto, maksu.

Jos testaus epäonnistuu, olet säästänyt lukuaikaa – raportoi se selkeästi ja anna tekoälyn korjata se. Katso kuinka kirjoittaa hyvä bugiraportti.

Vaihe 3: Tarkista käyttöoikeudet palvelimella

Tärkein tarkistettava asia. Tekoälytyökalut piilottavat usein painikkeen sivulta, mutta jättävät palvelimen valmiiksi tekemään toiminnon kenelle tahansa, joka pyytää.

Kaikille reiteille tai funktioille, jotka lukevat tai muuttavat dataa, kysy:

• Tarkistaako se, että käyttäjä on kirjautunut sisään?
• Tarkistaako se, että tällä käyttäjällä on oikeus päästä tähän tietueeseen?
• Onko tarkistus palvelimella, eikä vain sivulla?

Jokaiselle API-reitille, jonka lisäsit tai muutit, kerro, mikä käyttöoikeustarkistus sillä on palvelimella, lainaten rivin. Merkitse jokainen reitti, jolta sellainen puuttuu.

Testaa sitten: kirjaudu käyttäjänä A, merkitse tietueen ID, kirjaudu käyttäjänä B ja pyydä sitä. Tekoälyllä rakennettujen sovellusten tietoturvatarkistuslista sisältää koko testin.

Vaihe 4: Etsi vuotaneet salaisuudet

• Etsi muuttuneista tiedostoista kaikki, mikä näyttää avaimelta tai salasanalta.
• Tarkista, että salaisuusavaimet luetaan ympäristömuuttujista ja niitä käytetään vain palvelinkoodissa.
• Varo julkisia etuliitteitä, kuten VITE_ tai NEXT_PUBLIC_, salaisissa muuttujissa – ne rakennetaan selainkoodiin.

Katso kuinka pitää API-avaimet turvassa.

Vaihe 5: Tarkista syöte ja virheet

• Validointi palvelimella. Selaintarkistukset voidaan ohittaa. Pakolliset kentät, pituudet, muodot ja sallitut arvot pitää tarkistaa myös palvelimella.
• Tietokantakyselyt käyttävät parametreja, eivät tekstiä, joka on rakennettu liittämällä käyttäjän syöte kyselyyn.
• Virheitä ei nielaista. try/catch, joka ei tee mitään, piilottaa vikoja. Virheet pitää kirjata, ja käyttäjät näkevät selkeän viestin.
• Sisäisiä yksityiskohtia ei näytetä käyttäjille – pinojäljet ja tietokantavirheet kuuluvat lokeihin.

Vaihe 6: Tarkista, että se on todellista

Tekoälymallit tuottavat joskus koodia, joka näyttää oikealta mutta viittaa asioihin, joita ei ole olemassa.

• Paketit: jokaisen uuden riippuvuuden pitää olla oikea, ylläpidetty paketti täsmälleen tällä nimellä. Varo nimiä, jotka näyttävät suosittujen nimien kirjoitusvirheiltä.
• Funktiot ja API-asetukset: jos koodi kutsuu kirjastofunktiota tai ulkoisen API:n asetusta, jota et ole koskaan nähnyt, tarkista virallinen dokumentaatio.
• Paikanvaraajakoodi: etsi TODO, mock, fake, kovakoodattua näytedataa tai funktioita, jotka palauttavat kiinteän arvon.

Lisäsitkö uusia paketteja? Anna jokaiselle tarkka nimi, mihin se on tarkoitettu ja voisimmeko pärjätä ilman sitä.

Vaihe 7: Tarkista, että se sopii

Koodi voi toimia ja silti tehdä sovelluksesta vaikeamman muuttaa myöhemmin:

• Päällekkäisyys. Sama logiikka kopioituna useisiin paikkoihin erkaantuu toisistaan.
• Johdonmukaisuus. Sen pitäisi noudattaa muun sovelluksen käyttämiä malleja.
• Koko. 20 rivin pyyntö, joka tuotti 600 riviä, ansaitsee kysymyksen.
• Kuollut koodi. Vanhoja versioita, jotka jäivät uusien rinnalle.

Onko projektissa koodia, joka on nyt käyttämätöntä tämän muutoksen vuoksi, tai logiikkaa, joka on kopioitu muualle? Älä muuta mitään; listaa vain.

Yleisimmät virheet

• Hyväksyminen, koska se näyttää siistiltä. Siisti koodi voi silti ohittaa käyttöoikeustarkistuksen.
• Lukeminen testaamisen sijaan. Testaa ensin; lue toiseksi.
• Vain onnistuneen polun testaus. Kokeile väärää syötettä, väärää käyttäjää ja uloskirjautuneena.
• Muiden tiedostomuutosten ohittaminen. Kysy, miksi jokainen tiedosto muuttui.
• Itsearvioinnin täysi luottaminen. Käytä tekoälyn arviointia ensimmäisenä kierroksena ja vahvista testaamalla.
• Viikon muutosten tarkistaminen kerralla. Tarkista pienet muutokset niiden tapahtuessa.

Tarkistuslista

• Tiedän, mitkä tiedostot muuttuivat ja miksi, eikä mitään epäliittyvää muuttunut.
• Muutos toimii tietokoneella ja puhelimella, väärällä syötteellä, uloskirjautuneena ja toisena käyttäjänä.
• Jokainen datareitti tarkistaa kirjautumisen ja omistajuuden palvelimella.
• Koodissa tai selainpaketeissa ei ole salaisuuksia.
• Syöte validoidaan palvelimella; kyselyt käyttävät parametreja.
• Virheet kirjataan eikä niitä nielaista, eikä niitä näytetä käyttäjille yksityiskohtaisesti.
• Uudet paketit ovat oikeita ja tarpeellisia; keksittyjä funktioita tai paikanvaraajia ei ole jäljellä.
• Korkean riskin muutokset on luettu huolellisesti ja tarvittaessa toinen tarkistaja on katsonut ne.

Koodin tarkistaminen Mythexissä

• Ask-tila vastaa kysymyksiin koodista muokkaamatta sitä – ihanteellinen kehotteisiin "selitä jokainen muutos" ja "mistä reiteistä puuttuu käyttöoikeustarkistus". Katso Chat.
• Koodinäkymä näyttää tiedostopuun, editorin ja terminaalin jokaisessa paketissa (vain luku Free-paketissa, muokattava Pro-paketissa), joten voit lukea itse, mitä muuttui. Katso Koodieditori.
• /test saa agentin klikkaamaan esikatselun läpi käyttäjänä ja raportoimaan rikkinäiset virrat.
• Tallennuspisteet antavat sinun palauttaa muutoksen, joka ei läpäise tarkistusta.

Jos kehittäjä tarkistaa koodin puolestasi, kuinka työskennellä kehittäjän kanssa tekoälyllä rakennetussa sovelluksessa kertoo luovutuksesta; jos tarkistus paljastaa bugin, katso kuinka debugata tekoälyllä rakennettu sovellus.

Kysymykset