Kā uzrakstīt labu specifikāciju mākslīgā intelekta aģentam
Strādājot ar mākslīgā intelekta aģentiem, lielākās problēmas rodas no neprecīzi formulētām domām, nevis tehnoloģijām. Mēs bieži domājam: “Jo vairāk paskaidrošu, jo labāk.” Taču ar valodas modeļiem tas strādā citādi. Ja iedod pārāk daudz nestrukturētas informācijas, modelis sāk ignorēt daļu prasību vai sajauc prioritātes. Laba specifikācija nav gara. Tā ir skaidra, strukturēta un fokusēta.
Darbojoties ar Claude Code vai Gemini CLI, kļūst skaidrs, ka mākslīgais intelekts nav brīnumlīdzeklis. Tas strādā labi tikai tad, ja tam dod skaidras instrukcijas.
Zemāk, praktiska, sabalansēta pieeja ar vienkāršiem piemēriem.
1. Skaidrs mērķis pirms tehniskās realizācijas
Specifikācijai jāsākas ar “kāpēc” un “ko”, nevis ar “kā”.
Tā vietā, lai rakstītu:
Izveido React aplikāciju ar Node backend un PostgreSQL.
Sāc šādi:
Izveido web aplikāciju, kur lietotāji var pievienot un atzīmēt uzdevumus kā izpildītus. Datiem jāsaglabājas arī pēc pārlādes.
Šis formulējums nosaka mērķi. Tehnoloģijas var pievienot nākamajā solī.
Kad mērķis ir skaidrs, vari lūgt mākslīgajam intelektam izveidot detalizētāku plānu. Šajā brīdī tu joprojām kontrolē virzienu, bet ļauj modelim strukturēt detaļas.
2. Strukturē tekstu, lai mākslīgais intelekts to vieglāk saprastu
Mākslīgais intelekts daudz labāk strādā ar strukturētu tekstu nekā ar brīvu aprakstu. Iedomājies, ka raksti instrukciju ļoti burtiskam kolēģim.
Vienkārša struktūra var izskatīties šādi:
## Mērķis
Vienkārša uzdevumu aplikācija.
## Funkcijas
- Pievienot uzdevumu
- Atzīmēt kā izpildītu
- Dzēst uzdevumu
## Komandas
npm test
npm run build
## Robežas
- Nekad nekomitē .env failus
- Pirms datubāzes maiņas pajautā
Nav jābūt 20 sadaļām. Bet dažas skaidras nodaļas jau būtiski uzlabo rezultātu.
Balstoties uz GitHub analīzi, tieši skaidras komandas, testēšana un robežas ir tās lietas, kas visvairāk palīdz aģentiem darboties pareizi.
3. Sadali darbu mazākos soļos
Ja projekts ir lielāks par pāris failiem, necenties visu izdarīt vienā reizē.
Slikts piemērs:
Izveido pilnu aplikāciju ar autentifikāciju, API, UI un testiem.
Labāks variants:
- “Izveido datu modeli uzdevumiem.”
- “Tagad izveido API endpoint uzdevuma pievienošanai.”
- “Tagad izveido vienkāršu UI saraksta attēlošanai.”
Katrs solis ir konkrēts un pārskatāms. Tas uzlabo kvalitāti un samazina kļūdu skaitu.
4. Skaidri definē, kas ir atļauts un kas nav
Mākslīgais intelekts ne vienmēr zina, kur beidzas droša darbība un sākas riskanta.
Ļoti labi strādā vienkārša trīs līmeņu pieeja, skaidri pasaki, ko mākslīgais intelekts drīkst darīt pats, kad tam jāprasa atļauja un ko tas nedrīkst darīt nekad.
Vienmēr dari:
- palaid testus pirms commit
Pajautā vispirms:
- pirms jaunu bibliotēku pievienošanas
Nekad nedari:
- nekomitē slepenās atslēgas
- nerediģē node_modules
Šāda skaidrība novērš daudz problēmu.
5. Liec mākslīgajam intelektam pārbaudīt savu darbu
Vari prompta beigās pievienot vienu teikumu:
Pēc ieviešanas pārbaudi, vai visas prasības no šīs specifikācijas ir izpildītas.
Tas bieži liek modelim pašam pamanīt, ja kaut kas ir aizmirsts.
6. Pievieno savas zināšanas un kontekstu
Ja tu zini, ka:
- konkrēta bibliotēka rada problēmas,
- jāizmanto konkrēts arhitektūras princips,
- jāievēro uzņēmuma standarti.
Tad uzraksti to. Mākslīgais intelekts neuzminēs tavas iekšējās vadlīnijas.
Specifikācija ir vieta, kur tu ieliec savu domāšanu. Mākslīgais intelekts tikai izpilda.
7. Uztver specifikāciju kā dzīvu dokumentu
Specifikācija nav statiska. Ja prasības mainās, atjaunini to un tikai tad pielāgo kodu.
Piemēram:
Atjauninājums: uzdevumiem jāpievieno prioritāte (low, medium, high).
Šī viena rindkopa var būtiski mainīt datu modeli un UI. Ja to nepievienosi specifikācijai, mākslīgais intelekts turpinās balstīties uz veco versiju.
Noslēgumā
Laba specifikācija mākslīgajam intelektam:
- sākas ar skaidru mērķi,
- ir strukturēta, bet ne pārlieku sarežģīta,
- sadala darbu mazākos posmos,
- definē robežas,
- iekļauj nelielu kvalitātes kontroli,
- tiek regulāri atjaunināta.
Domā par mākslīgo intelektu kā ļoti ātru, bet burtisku junior izstrādātāju. Ja uzdevums ir skaidrs, rezultāts būs labs. Ja instrukcijas ir haotiskas, rezultāts būs haotisks.