Tutorial 4 Prompting and Reviewing is

Kennsla 4 · Fyrirmæli og yfirferð

🌎 Tungumál: Íslenska — sjá öll 33 tungumálin

Markmið: meta-færnin. Þú getur nú þegar smíðað eiginleika með aðstoðarmanni — þessi kafli snýst um að gera það lipurlega og endurtakanlega: að skrifa fyrirmæli sem hitta í mark í fyrstu tilraun, fara hratt yfir diff, ítreka þegar hlutir fara á hliðina og halda dampi milli lota.

← Fyrra: Kennsla 3 Fyrsta verkefnið þitt með aðstoðarmanninum · Næst: Kennsla 5 Staðfærsla

---

Skrifaðu fyrirmæli eins og leiðandi verkfræðingur, ekki eins og leitarreit

Aðstoðarmaðurinn er fljótur, bókstaflegur og ákafur yngri verkfræðingur. Stýrðu honum eins og þú myndir stýra góðum slíkum:

• Settu fram markmiðið og skorðurnar. „Bættu við endorse“ er veikt. „Bættu við endorse eftir mynstri connect, bara seeduð slembni, með prófum, og hliðið verður að vera grænt“ er sterkt. Skorður eru það sem skilar kóða sem passar inn.
• Vísaðu á dæmi. „Fylgdu mynstrinu í renderConnect“ slær út heila málsgrein af lýsingu. Fyrirliggjandi kóði er besta kröfulýsingin.
• Biddu um áætlun áður en breytingar hefjast í öllu sem er ekki alveg augljóst. Það er ódýrt að beina áætlun í rétta átt; dýrt að vinda ofan af tíu breyttum skrám.
• Eitt verkefni í hverjum fyrirmælum. Ef þú pakkar saman „bættu við endorse, endurhannaðu slembnina og uppfærðu README líka“ færðu flæktan diff sem er erfitt að fara yfir.
• Gefðu honum prófunarhliðið. „Keyrðu npm test og líttu ekki á þetta sem búið fyrr en það er grænt“ breytir aðstoðarmanninum í eitthvað sem athugar eigin vinnu.

Farðu yfir diffið í hvert skipti

Hraði er allur tilgangurinn með aðstoðarmanni — en hraði án lesturs er leiðin til að senda galla út. Byggðu upp hraða og stöðuga yfirferðarvenju:

1. Umfang: breytti það aðeins því sem það átti að breyta? Ótengdar línur sem færast til eru viðvörun.
2. Mynstur: passar þetta við kóðann í kring, án nýrra háða og án inntaks/úttaks inni í src/?
3. Reglur verkefnisins: í þessu repo eru þær bara seeduð slembni (leitaðu að Math.random í diffinu), sýnilegur texti í tungumálapökkunum (ekki harðkóðaður) og spjaldlínur fara aldrei yfir þá breidd sem uppsetningin bætir út í.
4. Aðgengi: lifir nýtt úttak af --accessible? Keyrðu lockedin --accessible <your command> og staðfestu að það lesist sem hreinn, skýr texti — engir nýir skrautstafir mega sleppa í gegnum a11yFilter.
5. Próf: er til nýtt próf, og myndi það í raun falla ef eiginleikinn brotnaði? Spurðu: „Hvaða línu myndi ég þurfa að breyta til að láta þetta nýja próf falla?“
6. Keyrðu hlutinn: npm test, síðan skipunina sjálfa og skoðaðu úttakið.

Þú þarft ekki að skilja hvern einasta staf — en þú verður að skilja hverja ákvörðun. Ef þú getur ekki útskýrt breytingu skaltu láta aðstoðarmanninn útskýra hana áður en þú samþykkir hana.

Ítrekaðu þegar hliðið er ekki grænt

Rautt hlið er eðlilegt skref, ekki bilun. Lausnin er nákvæmt endurgjald:

„npm test bilar með: [paste the exact error]. Breiddarprófið fyrir renderEndorse gerir ráð fyrir að hver lína í spjaldinu sé ≤ 60 sýnilegir dálkar. Lagaðu það án þess að veikja prófið.“

Límdu inn raunverulegan villutexta. „Þetta er bilað“ neyðir aðstoðarmanninn til að giska; stack trace fær hann til að laga það. Og haltu frekar sömu samtalslotu áfram en að byrja upp á nýtt — aðstoðarmaðurinn hefur þegar samhengið um það sem hann var að skrifa. Ef tvær eða þrjár ítranir skila engu skaltu stíga skref aftur á bak og afmarka verkefnið betur: það gæti verið of stórt fyrir eitt fyrirmæli.

Haltu dampi milli lota

Raunveruleg vinna spannar meira en eina setu. Tvær venjur halda aðstoðarmanni árangursríkum yfir tíma:

• Minni / venjur. Ef aðstoðarmaðurinn þinn styður varanlegt minni eða verkefnisskrá með leiðbeiningum skaltu skrá þar reglurnar sem hann á alltaf að fylgja (t.d. „öll slembni verður að nota pick/shuffle“, „keyrðu npm test áður en þú lýsir verki loknu“). Þá þarftu að setja reglu fram einu sinni í stað þess að endurtaka hana í hverjum fyrirmælum.
• Afhendingarnóta. Þetta repo heldur stuttri, hreinsaðri stöðuskýrslu í docs/HANDOFF.md: hvað verkefnið er, hvernig það er byggt, hvernig það er prófað og hvað kemur næst. Þegar þú kemur aftur (eða afhendir samstarfsfélaga — eða öðrum aðstoðarmanni) byggir sú nóta upp samhengi á sekúndum. Biddu aðstoðarmanninn um að halda henni uppfærðri sem hluta af breytingu.

Varnargarðar sem vert er að halda

• Hliðið er ekki samningsatriði. Græn próf áður en nokkuð er sent út. Það er það sem leyfir þér að vinna hratt og treysta útkomunni.
• Þú ert sá sem ber ábyrgð á yfirferðinni. Aðstoðarmaðurinn skrifar; þú ákveður. Að samþykkja diff þýðir að þú stendur fyrir því.
• Smá, sannreynanleg skref vinna á móti einu risastóru stökki. Hver samþykkt breyting ætti að skilja forritið eftir í virku ástandi.

---

✅ Prófaðu þetta með aðstoðarmanninum þínum

1. Skrifaðu kröfulýsingu í einni málsgrein fyrir mentor skipun („dreifir óumbeðnum ráðum“), með skorðunum inniföldum, og láttu aðstoðarmanninn byggja hana próf-fyrst — áætlun, próf, kóði, hlið — með yfirferð í hverju skrefi.
2. Biddu aðstoðarmanninn um að uppfæra docs/HANDOFF.md svo þar komi fram nýja skipunin.
3. Brjóttu eitthvað viljandi (t.d. eyddu færslu úr pooli), keyrðu npm test og æfðu þig í að gefa aðstoðarmanninum nákvæma villuna til að laga.

---

Hvert næst

• Flettu raunverulega kóðanum í src/lockedin.js — nú þekkirðu lögunina á honum.
• Lestu docs/HANDOFF.md fyrir eigin stöðu- og arkitektúrnotur verkefnisins.
• Njóttu brandaranna í Skipanatilvísun.

Þetta er kennsluefnið. Þú getur nú stýrt gervigreindaraðstoðarmanni til að byggja og breyta raunverulegum hugbúnaði fyrir aftan prófunarhlið — með sjálfsöruggasta dæmi sem hugsast getur. Sammála? 👇