Voitot:
- Kyky kartoittaa chat-tila oikeaan tehtävätyyppiin upotettuna
- Kyky kirjoittaa tehokkaita tuotantokehotteita, jotka sisältävät syöttö-/tulostussopimuksia, reunatapauksia ja tyylirajoituksia
- Mahdollisuus vahvistaa luotu koodi ja mahdolliset uudet ehdotetut riippuvuudet ennen yhdistämistä
Kehittäjän ensimmäinen kontakti tekoälyyn on usein automaattinen täydennys – ominaisuus, joka ehdottaa seuraavaa riviä kirjoittaessasi – tai sanomalla "kirjoita tämä toiminto" chat-ikkunaan. Molemmat käyttävät samaa moottoria, mutta vaativat eri tieteenaloja. Tässä yksikössä muunnamme koodin generoinnin satunnaisesta "kirjoituksesta" suunnitteluvaiheeseen, jonka tulos on ennustettavissa ja todennettavissa.
Tavoitteena on muuttaa tekoäly työkalusta, joka nopeuttaa kirjoituskonettasi, oppipoikaksi, joka toimii asetamiesi rajoitusten puitteissa. Hyvin ohjattu oppipoika säästää aikaa; Ohjaamaton oppipoika tuottaa sotkun, joka sinun on siivottava myöhemmin.
Kaksi käyttötilaa: Inline Completion ja Chat
Tekstin sisäinen täydennys tulee näkyviin, kun kirjoitat editoriin; Kirjoitat funktion allekirjoituksen tai kommenttirivin ja se ehdottaa loput. Se on loistava nopeus, mutta sillä on kapea konteksti: se näkee koodin vain välittömässä läheisyydessä. Siksi se toimii parhaiten, kun kirjoitat aikomuksesi selkeästi kommentissa. Esimerkiksi //validate käyttäjän sähköpostiosoite, kirjoita ValidationError, jos virheellinen kommentti parantaa merkittävästi alla olevaa ehdotusta.
Chat-tila on tarkoitettu suuremmille ja jäsennellyille tehtäville: "Lisää sivutus tähän luokkaan", "Pura kyseisen palvelun käyttöliittymä". Täällä sinulla on ylellisyys antaa rooli, konteksti ja muoto. Pääsääntönä on: pienten ja sujuvien tehtävien suorittaminen, ajattelua ja rakennetta vaativissa tehtävissä keskustelu.
Vinkki: Älä sokeasti hyväksy täydennysehdotusta "Sarkaimella". Lue ehdotettu rivi sekunnin ajan; Väärä muuttujan nimi tai käänteinen ehto yleisimmin vuotaa täältä.
Vaiheet aikomuksen kääntämiseksi koodiksi
- Määrittele sopimus. Mikä on funktion tulo-, tulos- ja virhekäyttäytyminen? Kuten "Hae sähköposti, normalisoi, jos kelvollinen, heittäkää virhe, jos virheellinen".
- Ilmoita rajoitukset. Älä käytä ulkoista riippuvuutta? Tietty tyyliopas? Onko suorituskykyrajaa?
- Anna esimerkki. Tulo-lähtö-pari ("ali@x.com → valid, ali@ → error") siirtää mallin tarkoituksen ymmärtämisen ennusteesta tarkkuuteen.
- Pyydä pieniä paloja. Yksi toiminto, yksi vastuu. Siirry sitten seuraavaan.
- Lue ja suorita luotu koodi. Kääntäminen + nopea manuaalinen kokeilu on halvin varmistusvaihe.
Kolme minikoteloa
Tapaus 1 – Kommentteihin perustuva tuotanto lisää tarkkuutta. Kehittäjä pyysi ensin päivämäärän jäsennystoimintoa tyhjällä rungolla ja sai oikean tuloksen 3 kierroksella. Toisella yrityksellä, kun määritin funktion 4-rivisellä kommentilla (hyväksytyt muodot, aikavyöhykesääntö, virheehto) ja pyysin sitä, tuli ensimmäisellä kierroksella toiminut koodi. Sama malli, sama päivä; ero oli vain tarkoituksen selkeys.
Tapaus 2 – Version ilmoittamatta jättäminen on kallista. Eräs tiimi kamppaili vanhan takaisinsoittopohjaisen API:n kanssa, joka korvasi fs.promises Node.js:lle tuotetussa koodissa. Kun rivi "Käytä solmua 20, ESM, async/wait" lisättiin kehotteeseen, tuotanto seurasi projektia ensimmäistä kertaa; Korjaukseen käytetty 12 minuutin keskiarvo nollattiin.
Tapaus 3 – Todellinen lisäys kaavakoodissa. Mikropalvelu vaati 6 uutta DTO:ta (Data Transfer Object – yksinkertainen tietoluokka, joka kuljettaa tietoja kerrosten välillä) ja niiden validointisäännöt. Se, mikä aiemmin oli noin 90 minuuttia manuaalista työtä, väheni 35 minuuttiin, kun tekoäly on tuottanut ja tarkistanut sen; Koska koodin toisto on korkea ja kuvio on selkeä, tekoäly toimi tässä tehokkaimmalla alueellaan.
Neljä kopioitavaa mallia
Sopimuspohjaisten toimintojen luominen:
Rooli: Olet ahkera {{kieli}} kehittäjä. Tehtäväsopimus:- Nimi: {{nimi}}- Syöttö: {{tyypit ja niiden merkitys}}- Tulos: {{tyyppi ja merkitys}}- Virheen tila: {{mitä heitetään/palautetaan, kun}}Rajoitukset: {{ei ulkoisia riippuvuuksia / tyyli_/suorituskyky {}} -ampeeri {{output_1}}- {{entry_2}} -> {{error_2}}Anna ensin allekirjoitus + lyhyt suunnitelma ja sitten koodi. Kirjoituskokeet, vain toiminta.
Vastaamaan olemassa olevaa tyyliä (sopeuta koodipohjaan):
Alla on esimerkkitoiminto projektistamme; Opi nimeäminen, virheiden käsittely ja kommentointityyli täältä. Kirjoita funktio kohteelle {{new_task}} SAMALLA tyylillä. Esimerkki: {{current_code}}
Rungosta täyttöön (tynkä → toteutus):
Täytä alla oleva funktiorunko kommenteissa olevien TEHTÄVIEN mukaisesti. MUUTA allekirjoitus ja palautustyyppi. Älä tee aputoimintoa, jota ei ole olemassa; ilmoita tarvittaessa "tätä avustajaa tarvitaan". {{skelet_kod}}
Vaihtoehtoinen sovellusten vertailu:
Anna kaksi erilaista toteutusta {{tehtävälle}}: (a) luettavuuden priorisointi, (b) suorituskyvyn priorisointi. Kirjoita jokaisen alle 1 lause "milloin on parempi".
Heikko kehote / Vahva kehote
Heikko: "Kirjoita minulle sähköpostin vahvistustoiminto."
Vahva: "TypeScript 5, vain vakiokirjasto. Kirjoita isValidEmail(syöte: merkkijono): boolean. Leikkaa välilyönnit, tee siitä erotteleva, a@b.co on kelvollinen, a@, @b.co, tyhjä merkkijono on virheellinen. Jos aiot käyttää regexiä, älä ole liian monimutkainen; lisää 2 riviä kommentteja."
Tehokas versio; Palauttaa kielen, version, allekirjoituksen, reunakirjaimet ja tyylirajoituksen. Näin luotu koodi toimii ja sopii projektiisi.
Lähestymistapa
Milloin käyttää
Huomio
Sisäänrakennettu täydennys
Pienet insertit virtauksessa
Älä hyväksy ehdotusta lukematta sitä
Sopimuspohjainen tuotanto chatissa
Uusi toiminto/luokka
Anna esimerkki ja reunatapaus
Tuotanto tyylinäytteen mukaan
Lisätään olemassa olevaan koodiin
Valitse nykyinen mallikoodi
luurankotäyte
Allekirjoitus korjattu, runko tyhjä
Allekirjoituksen vaihtaminen
Koodin monistaminen ja riippuvuusloukku
Tekoäly suosittelee usein uutta kirjastoa työnsä helpottamiseksi. Joskus tämä pitää paikkansa, joskus se lisää tarpeettoman riippuvuuden projektiisi tai ehdottaa pakettia, jota ei ole olemassa (hallusinaatio). Sääntö: vahvistat jokaisen uuden riippuvuuden. Älä lisää sitä projektiin varmistamatta, että paketti on todella olemassa, sitä ylläpidetään ja että sillä on asianmukainen lisenssi. Useimmiten jo projektissa oleva apulainen on parempi kuin uusi paketti.
Varoitus: Tarkista tekoälyn ehdottamat tuontirivit. Olematon paketin nimi (joka voi myös muistuttaa väärennettyjä paketteja, joita kutsutaan "typo-squattingiksi") sekä katkaisee kääntämisen että aiheuttaa turvallisuusriskin.
Yleisiä virheitä
- Mallin määrittelemä allekirjoitus. Jos et korjaa syöttö-/tulostustyyppejä, jokaisessa tuotannossa tulee erilainen allekirjoitus ja integrointi vaikeutuu.
- Reunatapauksista puhumattakaan. Tyhjä syöte, nolla, negatiivinen luku, erittäin suuri arvo – jos et määritä näitä, malli kirjoittaa "onnisen polun" ohittaen reunat.
- Yhdistetään ehdotus testaamatta sitä. Koodi, joka näyttää toimivan, ei tarkoita, että se toimii.
- Tarpeettoman riippuvuuden hyväksyminen. Kokonaisen kirjaston lisääminen yksilinjaiseen luo teknistä velkaa.
- Tyylin epäjohdonmukaisuus. Muusta projektista poikkeava nimeäminen ja virheiden käsittely tekee koodipohjasta hajanaisen.
Yhteenvetona
Koodin luominen on tehokasta, kun muutat tarkoituksen selkeäksi sopimukseksi. Käytä upotettua täyttöä pienissä in-stream-tehtävissä ja tehtävissä, jotka luovat keskustelun rakenteen. Määrität syöttö-/tulostustyypit, reunatapaukset, version ja tyylin; Anna esimerkki mallista; tarkista jokainen uusi riippuvuus; ja juokse ja lue jokainen tuotettu kappale. Tekoäly kannattaa parhaiten kaavallisessa, toistuvassa koodissa – suorita se siellä, määrittämiesi rajojen sisällä.
Sovellustehtävä
Valitse projektistasi pieni funktio, joka sinun on kirjoitettava. Tulosta se ensin tekoälylle "sopimuspohjaisen funktion luonti" -mallin avulla, joka antaa syöttö-/tulostustyypit, kaksi reunatapausta ja tyylirajoituksen. Käännä luotu koodi ja kokeile sitä kahdella eri syötteellä. Kysy sitten uudelleen samaa funktiota, tällä kertaa "kirjoita minulle tämä" ilman kontekstia ja vertaa kahta tulostetta rivi riviltä: mitkä reunatapaukset jäivät huomioimatta, kuinka monta korjausta vaadittiin?
tarkistuslista
- [ ] Tiedän, missä käytän chat-tilaa tekstinsisäisellä täydennyksellä.
- [ ] Määritän tulo/tulostussopimuksen ja reunatapaukset funktioiden generoinnissa.
- [ ] Olen ottanut tavan lisätä kehotteeseen kieli- ja versiotiedot.
- [ ] Kokoan ja testaan jokaisen valmistetun kappaleen ennen kokoamista.
- [ ] Vahvistan jokaisen tekoälyn ehdottaman uuden riippuvuuden varmistamalla sen olemassaolon ja tarpeellisuuden.
- [ ] Tarkistan, että luotu koodi vastaa projektin tyyliä.