Kā es rakstu darba instrukcijas GPT-5.1

Pēdējā laikā GPT-5.1 izmantoju gan sarunām, gan programmēšanai, gan uzdevumiem ar rīkiem un failiem. Viena lieta atkārtojas: labs modelis neizglābj neskaidru darba uzdevumu.

Es uzvedni veidoju vairāk kā īsu darba instrukciju. Tajā pasaku lomu, rezultāta formu, robežas un to, kas jāpārbauda pirms darba nodošanas.

Loma bez konteksta nav īpaši noderīga

“Esi eksperts” pats par sevi gandrīz neko nepasaka. Es labāk aprakstu, kam atbilde paredzēta, ko šis palīgs vērtē un no kā tam jāizvairās.

Piemēram, supporta aģentam var uzrakstīt kaut ko šādu:

<final_answer_formatting>
- Tu vērtē situācijas skaidrību un tempu vairāk nekā pieklājīgas frāzes. Tavs mērķis ir pēc iespējas ātrāk palīdzēt lietotājam ar konkrētiem soļiem, nevis gari stāstīt.
- Ja lietotājs ir apmierināts un pateicas, vari īsi atbildēt ("Sapratu", "Nav par ko") un tad ej pie risinājuma.
- Ja situācija ir steidzama (deadline, kļūdas produkcijā), pieklājību izlaižam un ejam tieši pie problēmas.
- Tu neraksti liekus ievadus, nesummē to pašu divreiz un neizmanto tukšas frāzes.
</final_answer_formatting>

Šis piemērs “draudzīgu toni” pārvērš novērojamā uzvedībā: īsi soļi, mazāk ievadu un cita prioritāte steidzamā situācijā. To ir vieglāk pārbaudīt.

“Īsi” aizstāj ar izmērāmu robežu

“Raksti īsi” katram var nozīmēt ko citu. Norādi teikumu, punktu vai koda fragmentu robežu:

<output_verbosity_spec>
- Atbildi Markdown formātā.
- Īsiem jautājumiem: līdz 2 teikumiem.
- Ja vajag ko izskaidrot plašāk: max 1 īss ievads un 3–5 punkti.
- Kodu rādi tikai tad, ja bez tā nevar, un ne vairāk par 1–2 īsiem fragmentiem.
</output_verbosity_spec>

Tas ir īpaši noderīgi saskarnē, kur garai atbildei vienkārši nav vietas.

Programmēšanas uzdevumiem es garumu piesaistu izmaiņas apjomam:

• maza izmaiņa — pāris teikumu un ne vairāk par vienu mazu koda fragmentu;
• vidēja izmaiņa — īss iznākums un svarīgākie punkti;
• liela izmaiņa — mainīto vietu un pārbaužu kopsavilkums, ne visa koda kopija.

Šādu noteikumu var ielikt pastāvīgajā instrukcijā, nevis atkārtot katrā jautājumā.

Stilu apraksti ar darbībām

Ja noklusējuma atbildes ir pārāk garas vai formālas, es nepievienoju tikai īpašības vārdus. Es pasaku, ko modelim darīt ar rindkopām, atkārtojumiem un lietotāja toni.

Piemēram, ja es gribu tiešu, darbīgu toni, es uzrakstu apmēram šādi:

<final_answer_formatting>
- Tu atbildi īsi, tieši un bez liekiem ievadiem.
- Neatkārto to pašu ideju divos dažādos paragrāfos.
- Izmanto vienkāršu valodu, izvairies no buzzwordiem.
- Ja lietotājs raksta īsi, tu arī esi īss. Ja viņš raksta gari, vari atbildēt nedaudz plašāk, bet joprojām konkrēti.
</final_answer_formatting>

Modelis ne vienmēr ievēros katru punktu perfekti, bet konkrēti noteikumi dod daudz stabilāku rezultātu nekā “esi profesionāls”.

Pasaki, ko nozīmē pabeigts darbs

Uzdevumā ar failiem vai rīkiem modelis var apstāties pie padoma, lai gan gaidīji gatavu izmaiņu. Tāpēc es skaidri aprakstu pabeigšanas nosacījumu.

Es to formulēju apmēram šādi:

<solution_persistence>
- Uzvedies kā pieredzējis lietotājs, nevis čatbots, kas prasa atļauju katram solim.
- Kad es pasaku virzienu, tu pats savāc kontekstu, izplāno, izdari, pārbaudi un īsi izskaidro rezultātu.
- Neapstājies pie "dažiem ieteikumiem", ja vari aiziet līdz pilnam risinājumam.
- Neuzdod liekus papildjautājumus, ja vari droši pieņem lēmumus.
</solution_persistence>

Šāda instrukcija der tikai uzdevumiem, kuros modelim ir vajadzīgie rīki un atļaujas. Tā nedrīkst mudināt izdomāt trūkstošus datus vai veikt ārējas darbības bez lietotāja pilnvarojuma.

Rīkam vajag izsaukšanas noteikumu

Rīka shēma pasaka, kā to izsaukt. Instrukcijai jāpasaka, kad tas ir vajadzīgs un ko darīt pēc rezultāta.

Es rakstu skaidri:

• kad rīks jālieto obligāti;
• kādi dati jāsavāc pirms izsaukšanas;
• ko pārbaudīt atbildē;
• ko apstiprināt lietotājam.

Piemēram, rezervācijas scenārijam varētu būt aptuveni šādi:

<reservation_tool_usage_rules>
- Ja lietotājs prasa rezervēt galdiņu, tev obligāti jāizsauc `create_reservation`.
- Ja trūkst vārda vai laika, vispirms pajautā tos.
- Pēc rīka izsaukšanas vienā teikumā apstiprini, kas ir noreservēts (vārds, datums, laiks).
</reservation_tool_usage_rules>

Tas ir drošāk nekā cerēt, ka modelis pats vienmēr izvēlēsies pareizo brīdi.

Ar failu rediģēšanu es līdzīgi norādu izmantot apply_patch, pēc tam palaist pārbaudes un gala atbildē aprakstīt rezultātu, nevis ielīmēt visu failu.

none izmanto vienkāršam un lētam darbam

GPT-5.1 API atbalstīja none spriešanas režīmu uzdevumiem, kuros svarīgāks ir ātrums un nav vajadzīga dziļa analīze:

• īsām FAQ atbildēm;
• vienkāršai datu paņemšanai no API un noformēšanai;
• paredzamai teksta pārveidošanai.

Sarežģītai analīzei, vairāku soļu izmaiņai vai riskantam lēmumam izvēlos lielāku reasoning effort. Režīmu pieejamība ir atkarīga no modeļa un API versijas, tāpēc šo 2025. gada piemēru nevajag uztvert kā mūžīgu konfigurāciju.

Un promptā pie none es tomēr ierakstu kaut ko šādu:

Pirms citu rīku izsaukšanas īsi izplāno, ko tieši darīsi, un pēc tiem īsi pārbaudi, vai rezultāts tiešām atbilst manam uzdevumam.

Garam uzdevumam pietiek ar mazu plānu

Vairāku failu izmaiņai vai dokumentu analīzei es prasu divus līdz piecus konkrētus soļus. Divdesmit punktu plāns pats kļūst par darbu.

Nevis 20 punktu to-do, bet kaut ko šādu:

<plan_tool_usage>
- Vidējiem un lieliem uzdevumiem uztaisi 2–5 konkrētus soļus (piemēram, "atrast kļūdu", "salabot", "pārbaudīt", "kopsavilkums").
- Vienlaikus vari strādāt tikai pie viena soļa; kad tas pabeigts, ej tālāk.
- Pirms beidz sesiju, visiem plāna punktiem jābūt vai nu "pabeigts", vai "atcelts ar iemeslu".
</plan_tool_usage>

Plāns palīdz gan modelim noturēt virzienu, gan cilvēkam pārbaudīt progresu. Svarīgākais ir pabeigšanas pārbaude, ne pats plāna formāts.

Uzvedne ir darba līgums mazā mērogā

GPT-5.1 man strādā labāk, ja uzvedne nav vienreizējs vēlējums, bet īsa stila un darba instrukcija. Tai jāpasaka, kāds rezultāts vajadzīgs, kādi ierobežojumi jāievēro, kā lietot rīkus un kā pārbaudīt, ka uzdevums tiešām pabeigts.

Jo mazāk svarīgu lēmumu atstāju vārdam “labi”, jo paredzamāka ir atbilde.