Tutorial 4 Prompting and Reviewing fi

Tutorial 4 · Promptaus ja arviointi

Tavoite: metataito. Osaat nyt rakentaa ominaisuuden agentin kanssa — tämä luku käsittelee sen tekemistä sulavasti ja toistettavasti: prompttien kirjoittamista, jotka osuvat ensimmäisellä kerralla, diffien tehokasta arviointia, iterointia kun asiat menevät pieleen, ja vauhdin pitämistä yllä sessioiden välillä.

← Edellinen: Tutorial 3 Ensimmäinen agenttitehtäväsi · Seuraava: Tutorial 5 Lokalisointi

---

Promptaa kuin tiiminvetäjä, ei kuin hakukenttä

Agentti on nopea, kirjaimellinen, innokas junior-insinööri. Johda sitä samoin kuin johtaisit hyvää sellaista:

• Kerro tavoite ja rajoitteet. "Lisää endorse" on heikko. "Lisää endorse seuraten connect-mallia, vain siemennetty RNG, testien kanssa, portti pysyy vihreänä" on vahva. Rajoitteet ovat se, miten saat koodia, joka sopii.
• Osoita esimerkkejä. "Seuraa renderConnect:in käyttämää mallia" voittaa kappaleen kuvausta. Olemassa oleva koodi on paras spesifikaatio.
• Pyydä suunnitelmaa ennen muokkauksia kaikessa ei-triviaalissa. Halpaa ohjata suunnitelmaa uudelleen; kallista purkaa kymmentä muokattua tiedostoa.
• Yksi tehtävä per prompti. "Lisää endorse, myös refaktoroi RNG, myös päivitä README" -yhdistäminen tuottaa sotkuisen diffin, jota on vaikea arvioida.
• Anna sille testiportti. "Aja npm test äläkä pidä sitä valmiina ennen kuin se on vihreä" muuttaa agentin joksikin, joka tarkistaa oman työnsä.

Arvioi diffi joka kerta

Nopeus on koko agentin pointti — mutta lukematon nopeus on tapa, jolla bugit julkaistaan. Rakenna nopea, johdonmukainen arviointirefleksi:

1. Laajuus: muuttiko se vain sitä, mitä pitäisi? Asiaan kuulumattomat siirtyneet rivit ovat huono merkki.
2. Mallit: täsmääkö se ympäröivän koodin kanssa, ilman uusia riippuvuuksia ja ilman I/O:ta src/:n sisällä?
3. Projektin säännöt: tälle repolle se on vain siemennetty RNG (grep diffistä Math.random), käyttäjälle näkyvä teksti kielipaketeissa (ei kovakoodattuna), ja korttirivit eivät koskaan ylitä leveyttä, johon asettelu pehmustaa.
4. Saavutettavuus: selviääkö uusi tuloste --accessible:sta? Aja lockedin --accessible <your command> ja tarkista, että se toimii siistinä pelkkänä tekstinä — ei uusia koristeellisia merkkejä livahtamassa a11yFilter:in ohi.
5. Testit: onko uusi testi, ja epäonnistuisiko se todella, jos ominaisuus rikkoutuisi? Kysy: "Mitä riviä muuttaisin saadakseni tämän uuden testin epäonnistumaan?"
6. Aja se: npm test, sitten aja komento ja katso tulostetta.

Sinun ei tarvitse ymmärtää jokaista merkkiä — mutta sinun täytyy ymmärtää jokainen päätös. Jos et voi selittää muutosta, pyydä agenttia selittämään se ennen kuin hyväksyt sen.

Iteroi kun se ei ole vihreä

Punainen portti on normaali vaihe, ei epäonnistuminen. Korjaus on täsmällinen palaute:

"npm test epäonnistuu viestillä: [paste the exact error]. renderEndorsein leveystesti odottaa jokaisen korttirivin olevan ≤ 60 näkyvää saraketta. Korjaa se heikentämättä testiä."

Liitä oikea virhe teksti. "Se on rikki" saa agentin arvaamaan; pinojälki saa sen korjaamaan. Ja suosi saman keskustelun jatkamista uuden aloittamisen sijaan — agentilla on jo konteksti siitä, mitä se juuri kirjoitti. Jos kaksi tai kolme iteraatiota eivät konvergoidu, astu taaksepäin ja mieti tehtävä uudelleen: se voi olla liian iso yhdelle promptille.

Pidä vauhti yllä sessioiden välillä

Oikea työ ulottuu useamman istunnon yli. Kaksi tapaa pitää agentin tehokkaana ajan myötä:

• Muisti / käytännöt. Jos agenttisi tukee pysyvää muistia tai projektiohjetiedostoa, kirjaa sinne säännöt, joita sen tulisi aina noudattaa (esim. "kaiken satunnaisuuden täytyy käyttää pick/shuffle:a", "aja npm test ennen valmiiksi julistamista"). Määrittelet käytännön kerran jokaisen promptin sijaan.
• Luovutusmuistio. Tämä repo pitää lyhyttä, siistittyä tilaraporttia osoitteessa docs/HANDOFF.md: mikä projekti on, miten se on rakennettu, miten sitä testataan, ja mitä seuraavaksi. Kun palaat (tai luovutat tiimikaverille — tai toiselle agentille), tuo muistio rakentaa kontekstin uudelleen sekunneissa. Pyydä agenttiasi pitämään se ajan tasalla osana muutosta.

Suojakaiteet, jotka kannattaa pitää

• Portti ei ole neuvoteltavissa. Vihreät testit ennen kuin mitään julkaistaan. Se on se, mikä antaa sinun liikkua nopeasti ja luottaa tulosteeseen.
• Sinä olet virallinen arvioija. Agentti kirjoittaa; sinä päätät. Diffin hyväksyminen tarkoittaa, että takaat sen.
• Pienet, todennettavat askeleet voittavat yhden jättihypyn. Jokaisen hyväksytyn muutoksen pitäisi jättää sovellus toimivaksi.

---

✅ Kokeile agenttisi kanssa

1. Kirjoita yhden kappaleen spesifikaatio mentor-komennolle ("jakaa pyytämätöntä neuvoa"), mukaan lukien rajoitteet, ja anna agentin rakentaa se testit ensin — suunnitelma, testit, koodi, portti — arvioiden jokaisessa vaiheessa.
2. Pyydä agenttia päivittämään docs/HANDOFF.md mainitsemaan uuden komennon.
3. Riko jotain tahallaan (esim. poista poolimerkintä), aja npm test, ja harjoittele antamalla agentille tarkka virhe korjattavaksi.

---

Mihin mennä seuraavaksi

• Silmäile oikeaa koodia src/lockedin.js:ssä — tiedät nyt sen muodon.
• Lue docs/HANDOFF.md projektin oman tila- ja arkkitehtuurimuistiinpanojen osalta.
• Nauti läpistä sivulla Command Reference.

Se on opetusohjelma. Voit nyt ohjata tekoälyagenttia rakentamaan ja muuttamaan oikeaa ohjelmistoa testiportin takana — käyttäen kuviteltavissa olevaa itsevarminta esimerkkiä. Samaa mieltä? 👇