System‑prompt və ChatGPT App üçün “rol müqaviləsi”

1. System‑prompt müqavilədir, bəzəkli mətn deyil

Əvvəlki modullarda ChatGPT App-ə arxitektur tərəfdən baxmışdıq: vidcet, tools və MCP‑server. Bu dərsdə isə diqqəti başqa yerə yönəldirik — modelə rolunu hansı sözlərlə izah edirik: nə edə bilər, nə etməməlidir və alətləri necə istifadə etməlidir. Mahiyyətcə, system‑prompt-u sizinlə model arasında müqavilə kimi layihələndirəcəyik.

Adi ChatGPT söhbətində bəlkə də “Elə təsəvvür et ki, sən şən pirat‑köməkçisən” və ya “Hər şeyi beş yaşlı uşaq üçün izah et” tipli promptlara öyrəşmisiniz. Bunlar persona və üslub haqqındadır. ChatGPT App kontekstində system‑prompt termini isə tam başqa məna daşıyır.

Burada system‑prompt — istifadəçidən gizli qalan, rolun ilk mesajı olan system-dir və model üçün aşağıdakıları təyin edir:

• sizin App çərçivəsində o kimdir;
• hansı tapşırığa fokuslanır;
• nə ilə məşğul olmur;
• tətbiqinizin alətlərini necə və nə zaman çağırmalıdır.

Bu, mahiyyətcə, davranış spesifikasiyasıdır və formal müqaviləyə çox yaxındır. Razılaşsanız — model buna əməl etməyə çalışır. Razılaşmasanız — model adi “ümumi” ChatGPT kimi davranacaq və bütün gözəl App-ınız kənarda qalacaq.

Vacibdir ki, ChatGPT App üçün bu system‑prompt:

• tətbiqin özünə bağlanır, ayrı‑ayrı dialoqa yox;
• həm vidcetdən istifadəyə, həm də tools çağırışlarına çərçivə qoyur;
• App sessiyası davam etdiyi müddətdə “yaşayır” (istifadəçi tətbiqinizlə ünsiyyətdə olduqca).

Sadələşdirsək, müqavilə belədir: siz modelə alətlər verirsiniz və onun rolunu təsvir edirsiniz — hansı köməkçidir, nə edir, nə etmir, alətlərdən necə istifadə edir və istifadəçi məlumatlarına necə yanaşır. Model də buna uyğun davranmağa çalışır.

2. system‑prompt arxitekturda harada “yaşayır”

Bunun hansısa sehrli mahiyyət olmadığını göstərmək üçün onu sxemdə görmək faydalıdır.

sequenceDiagram
    participant User as İstifadəçi
    participant ChatGPT as ChatGPT + model
    participant App as Sizin ChatGPT App
    participant MCP as MCP/Backend

    Note over ChatGPT: App inisializasiyası zamanı
modelə system‑prompt ötürülür

    User->>ChatGPT: "Dosta 50 $-a qədər hədiyyə seç"
    ChatGPT->>ChatGPT: system‑prompt + tools təsvirlərini tətbiq edir
    ChatGPT->>App: callTool recommend_gifts(...)
    App->>MCP: HTTP /tools/recommend_gifts
    MCP-->>App: Hədiyyələrin siyahısı
    App-->>ChatGPT: Tool result (JSON)
    ChatGPT-->>User: Mətn + kartlı vidcetə istinad

System‑prompt modelə App inisializasiyası anında çatır — ChatGPT dialoqa sizin tətbiqi “qoşmaq” qərarını verəndə. Sonra hər qərar — tool çağırmaqdansa, vidcet təklif etmək, məlumat yoxdursa nə demək — artıq bu müqavilənin prizmasından keçir.

Apps SDK baxımından bu adətən sadəcə sətirdir və App konfiqurasiyasının yanında haradasa yerləşir, məsələn:

// app/config/systemPrompt.ts
export const giftGeniusSystemPrompt = `
Sən — GiftGenius, hədiyyə seçimi üzrə köməkçisən...
`;

Daha sonra bu sətir tətbiqinizin ChatGPT ilə bağlandığı yerə göndərilir. Texniki “obvyozka” fərqli ola bilər, amma sizin üçün vacib olan budur: system‑prompt — alət sxemi və ya React komponenti kimi kod artefaktıdır və onu da eyni diqqətlə layihələndirmək və saxlamaq lazımdır.

Artıq system‑prompt-un arxitekturda harada “yaşadığını” və modelə necə çatdığını bildiyimizə görə, ən vacibi — ora nəyi qoymaq lazımdır ki, bu sadəcə “şirin persona” təsviri deyil, müqavilə olsun.

3. App rolu və məsuliyyət sərhədləri

İstənilən normal system‑prompt-un ilk və əsas bölməsi — sən kimsən və nəyə cavabdehsən.

“Persona” ilə “App‑müqaviləsi” arasındakı fərq sadədir: “sən dənizçi tərzində danışan piratsan” demək ton haqqındadır; “sən hədiyyə kataloqumuzun interfeyisisən, hədiyyələr seçirsən və başqa mövzulara girmirsən” demək artıq müqavilədir.

Hədiyyə seçən tədris tətbiqimiz GiftGenius üçün rol nüvəsi belə görünə bilər:

Rol:
- Sən — GiftGenius, servisimizin hədiyyə seçimi üzrə köməkçisisən.
- Sənin vəzifən — yalnız bizim kataloqdan istifadə edərək istifadəçiyə uyğun hədiyyə seçməyə kömək etməkdir.
- Tibbi, hüquqi və maliyyə məsləhətləri vermirsən.

Vurğulara fikir verin.

Birincisi, domeni dar şəkildə müəyyənləşdiririk: yalnız servisimiz çərçivəsində hədiyyə seçimi. Bu, modelin tətbiqinizi açmaq əvəzinə “kvant fizikasını izah etməyə” başlamaması və digər tətbiqlər ətrafında qəribə workflow-lar qurmağa cəhd etməməsi üçün lazımdır.

İkincisi, App-ın nə etmədiyini açıq şəkildə fiks edirik. Məsələn:

• hədiyyələr və alışla bağlı olmayan mövzularda məsləhət vermir;
• kataloqda olmayan hədiyyələr uydurmur;
• istifadəçi əvəzinə qərar vermir, yalnız variantlar təklif edir və arqumentləşdirir.

Belə mənfi məhdudiyyətlər çox vaxt pozitiv təlimatlardan daha vacib olur: model “hər şeyi etmək”də onsuz da yaxşıdır, siz isə system‑prompt-da artıq olanları kəsirsiniz.

Bir inkişaf etdiricinin bir neçə App-ı olduğu daha mürəkkəb mühitlərdə (məsələn, “hədiyyə seçimi” və “sifarişin çatdırılmasının izlənməsi”) system‑prompt-da birbaşa yazmaq faydalıdır ki, bu App-da yalnız hədiyyə seçimi ilə məşğulsan, sifarişlərin idarəsi və logistikanı öhdənə götürmürsən və digər tətbiqləri işə salmırsan. Bu, modelin “kimin işi” məsələsində çaşma riskini azaldır.

4. App-ı nə vaxt çağırmalı, nə vaxt özün cavab verməlisən

Müqavilənin növbəti kritik bloku: alətlərdən istifadə qaydaları.

Əgər bunlar yazılmasa, adətən iki ifratdan birinə düşür:

• model demək olar heç vaxt App-ınızı çağırmır, çünki ona “başından” cavab vermək daha asandır və ucuzdur;
• ya da əksinə, ən nəzəri suallar üçün belə alətləri çağırmağa başlayır.

App üçün system‑prompt-da kifayət qədər dəqiq fiks etmək lazımdır:

• hansı hallarda alətlərdən istifadə etmək lazımdır;
• hansı hallarda özün cavab verməlisən, tools olmadan;
• istifadəçi açıq şəkildə “tətbiqi açma” deyirsə, nə etməli.

GiftGenius üçün mətni fraqment nümunəsi:

Alətlərlə iş:
- Kataloqdan faktiki məlumatları almaq lazım olanda (hədiyyə siyahısı, qiymətlər, məhsul tipləri, çatdırılma və endirim mövcudluğu) App alətlərini istifadə et.
- Sual nəzəridirsə və kataloqa çıxış tələb etmirsə (məsələn, "adətən yeni mənzilə hansı hədiyyələr verilir"), alətsiz, özün cavab ver.
- Əgər istifadəçi açıq şəkildə "tətbiqi açma" və ya "vidcetsiz cavab ver" deyirsə, buna hörmət et və alətləri çağırma.

Burada bir neçə vacib məqam var.

Birincisi, tools çağırışını sorğu tipinə bağlayırıq: faktiki/kataloq məlumatı → alət; ümumi nəzəriya → model özü cavab verir.

İkincisi, istifadəçi niyyətinə hörmət haqqında açıq deyirik: “heç nə işə salma, sadəcə izah et” yazılıbsa, model bu siqnalı görməməzlikdən gəlməməlidir.

Üçüncüsü, bununla App istifadəsinin tezliyini idarə edirik. Yaxşı system‑prompt modelə balans tapmağa kömək edir: App lazım olanda istifadə olunur, amma hər dəfə yapışan pop‑up-a çevrilmir.

Sonrakı UX‑təlimatlar dərsində modelin vidcetin işə salınmasını necə elan etməli olduğu və ssenari bitəndən sonra nə deməli olduğu barədə ayrıca danışacağıq. Burada bizi qərar qaydaları maraqlandırır: App istifadə etmək, yoxsa yox.

5. tools-dan təhlükəsiz istifadə və istifadəçi məlumatları ilə iş

İndi — təhlükəsizlik və sağlam məntiq haqqında.

Tətbiqinizin alətləri müxtəlif ola bilər:

• ictimai məlumatlarla işləyənlər (hədiyyə kataloqları, mövcudluq, çatdırılma şərtləri);
• şəxsi məlumatlarla işləyən və/və ya istifadəçi adından hərəkət edənlər (sifarişin yaradılması, vəsaitin çıxılması, parametrlərin dəyişdirilməsi).

system‑prompt-da modelin bu fərqlərə necə yanaşmalı olduğunu göstərmək lazımdır.

Tipik qaydalar dəsti:

Təhlükəsizlik və məxfilik:
- İstifadəçinin razılığını tələb edən əməliyyatları (alış, abunə, şəxsi məlumatların dəyişdirilməsi) söhbətdə açıq təsdiq olmadan icra etmə.
- Alətlərə onların işi üçün lazım olandan artıq məlumat ötürmə (məlumatların minimallaşdırılması).
- Sorğu həssas məlumatlara aiddirsə (sağlamlıq, maliyyə, uşaqlar), əvvəlcə istifadəçinin bu məlumatları tətbiqə ötürülməsini təsdiq edib-etmədiyini dəqiqləşdir.

Burada biz bir neçə məsələni eyni anda həll edirik.

Birincisi, istifadəçini gözlənilməz aktivlikdən qoruyuruq: model, siz ona belə bir alət versəniz belə, özbaşına hədiyyə ala və ya sifariş verə bilməz. Əvvəlcə — mətnlə təsdiq, sonra — alət çağırışı.

İkincisi, artıq məlumat sızması riskini azaldırıq: model prinsipcə arqumentlərə “gördüyü hər şeyi” yığmağa meyllidir; siz isə açıq şəkildə minimum lazım olan sahələrlə məhdudlaşmağı xahiş edirsiniz.

Üçüncüsü, maliyyə aləti olmasa da hüquqi/etik risklərin ola biləcəyi həssas domenləri ayrıca vurğulayırıq.

Yaxşı praktika — riskli alətlər üçün onların təsvirində (description) ayrıca qeyd etməkdir ki, onlar vəziyyəti dəyişir və ya ödəniş edir, bunu isə system‑prompt səviyyəsində də təkrarlamaq. Beləcə sizdə ikiqat baryer yaranır: həm müqavilədə, həm də konkret alətin təsvirində.

6. system‑prompt-un formatı və üslubu: spesifikasiya kimi yazın

Ən geniş yayılmış səhvlərdən biri — system‑prompt-u marketinq mətni kimi yazmaqdır: “Sən — innovativ, inanılmaz dərəcədə ağıllı köməkçisən, dünyanı daha yaxşı edirsən…”. Bu gözəldir, amma model üçün nə isti, nə soyuq. Onu maraqlandıran budur:

• mən kiməm;
• nə etmək lazımdır;
• nə etməmək lazımdır;
• alətlərdən necə istifadə etmək;
• məlumatlara və digər App-lara necə yanaşmaq.

Ona görə də system‑prompt-a spesifikasiya kimi yanaşmaq daha yaxşıdır:

• məntiqi bloklara bölün: “Rol”, “Vəzifələr”, “Sərhədlər”, “Alətlərlə iş”, “Təhlükəsizlik”;
• blokların içində qısa, birmənalı cümlələr yazın;
• “et” və “etmə”ni açıq ayırın (bəli, elə promtun özündə siyahılar tam uyğundur).

GiftGenius üçün strukturlu prompt fraqmenti belə görünə bilər:

Rol:
- Sən — GiftGenius, servisimizin hədiyyə seçimi üzrə köməkçisisən.

Vəzifələr:
- İstifadəçiyə tapşırığa, alıcının maraqlarına və büdcəyə uyğun hədiyyələr seçməyə kömək et.
- Hər bir variantın üstün və zəif tərəflərini sadə dildə izah et.

Etmə:
- Kataloqda olmayan hədiyyələr uydurma.
- Servisin mövcud olmayan funksiyalarını vəd etmə (məsələn, kataloqda pullu göstərilirsə, “pulsuz çatdırılma” demə).

Üslubu neytral və “quru” etmək rahatdır: bu, satış mətni deyil, müqavilədir. Nə qədər az qeyri‑müəyyənlik olsa — davranış bir o qədər stabil olar.

Başqa vacib praktika: system‑prompt-u versiyalaşdırmaq və kodla eyni repozitoriyada saxlamaq. Promptların da versiyaları var və onlardakı dəyişikliklər TypeScript məntiqindəki dəyişikliklər qədər davranışı poza bilər. PR review zamanı diff görmək daha xoşdur:

- Kataloqda olmayan hədiyyələr uydurma.
+ Kataloqda olmayan hədiyyələr uydurma, hətta istifadəçi açıq şəkildə “nəyisə uydur” istəsə belə.

nəinki “bir az ifadəni interfeysdə düzəltdiyinizi” xatırlamağa çalışmaq.

7. Tədris App-ımız üçün tam system‑prompt nümunəsi

Gəlin hamısını birləşdirək və tədris GiftGenius-umuz üçün səliqəli system‑prompt yazaq. Oxumaq və düzəltmək asan olsun deyə onu hissələrə böləcəyik.

Əvvəlcə rol və vəzifələri təsvir edək:

Rol:
- Sən — GiftGenius, servisimizin hədiyyə seçimi üzrə köməkçisisən.
- İstifadəçi ilə nəzakətli və işgüzar tərzdə danış, istifadəçi özü istifadə etmədikcə slenq və zarafat işlətmə.

Vəzifələr:
- Alıcının profili, maraqları, hadisə və büdcəyə görə hədiyyələr seçməyə kömək et.
- Niyə məhz bu variantları təklif etdiyini sadə və anlaşılan dildə izah et.

İndi sərhədləri və məhdudiyyətləri yazırıq:

Məsuliyyət sərhədləri:
- Yalnız hədiyyə kataloqumuz və onun metadataları ilə işləyirsən.
- Kataloqda və ya alətlərin cavabında olmayan hədiyyə, aksiya və endirimləri uydurma.
- Tibbi, hüquqi və maliyyə məsləhətləri vermə.
- Digər tətbiqlər və ya saytların işi üçün cavabdeh deyilsən; istifadəçi bununla bağlı soruşursa — kömək edə bilməyəcəyini de.

Alətlərlə iş qaydalarını əlavə edək:

Alətlərlə iş:
- Azad formada verilmiş alıcı təsvirini maraq seqmentlərinə çevirmək lazım olanda `profile_to_segments` alətindən istifadə et.
- İstifadəçi parametrlərinə görə (seqmentlər, büdcə, hadisə, lokal) hədiyyə tapmaq və ya süzgəcdən keçirmək lazım olanda `recommend_gifts` alətindən istifadə et.
- İstifadəçiyə konkret hədiyyə barədə detalları (təsvir, tip, qiymət, çatdırılma məhdudiyyətləri) lazımdırsa, `get_gift` alətindən istifadə et.
- Alətləri çağırmazdan əvvəl, əgər onlarsız nəticə faydasız olacaqsa, çatışmayan parametrləri (alıcının yaşı, büdcəsi, hadisə) dəqiqləşdirməyə çalış.
- Sual nəzəridirsə (məsələn, "ümumiyyətlə evlilik ildönümündə hədiyyə necə seçilir"), alətsiz, özün cavab ver.

İndi — təhlükəsizlik və istifadəçi adından hərəkətlər bloku:

Təhlükəsizlik:
- İstifadəçinin söhbətdə açıq təsdiqi olmadan alış, abunə və ya hədiyyə göndərişi rəsmiləşdirmə.
- Alətin işi üçün şəxsi məlumatlar (alqıcının e‑poçtu, çatdırılma ünvanı, ad) lazımdırsa, əvvəlcə onların niyə lazım olduğunu izah et və təsdiq istə.
- Alətlərə lazım olandan çox məlumat ötürmə (məsələn, yetərlidirsə, tam mesajı yox, yalnız yaş, maraqlar və büdcəni göndər).

Və ümumi ton/qlobal qaydalar:

Ümumi qaydalar:
- Alətlər boş nəticə qaytarırsa, bunu dürüst de və şərtləri yumşaltmağı təklif et (büdcəni, hədiyyə tipini, kateqoriyanı və ya hadisəni dəyişmək).
- İstifadəçi "tətbiqi açma" və ya "vidcetsiz keçin" deyirsə, buna hörmət et və yalnız mətnlə cavab ver, tools çağırma.
- Sorğu hədiyyələr və ya alışla bağlı deyilsə, baza ChatGPT kimi cavab ver və GiftGenius alətlərindən istifadə etmə.

Nəticədə konstruksiya əlavə materiallardakı nümunəyə çox bənzəyir: “Rol”, “Vəzifələr”, “Et/Etmə”, “Alətlərlə iş”, “Təhlükəsizlik”, “Ümumi qaydalar” bölmələri var.

Next.js kodunda bunu ayrıca modul kimi tərtib edə bilərsiniz:

// app/config/giftGeniusPrompt.ts
export const giftGeniusSystemPrompt = `
Rol:
- Sən — GiftGenius, servisimizin hədiyyə seçimi üzrə köməkçisisən.
...

Ümumi qaydalar:
- Sorğu hədiyyələrlə bağlı deyilsə, baza ChatGPT kimi cavab ver və GiftGenius alətlərindən istifadə etmə.
`;

Daha sonra bu konstantanı App konfiqurasiyasında istifadə edirsiniz (necə — Apps SDK versiyasından asılıdır, amma ideya eynidir: bu mətn App dialoqu inisializasiyası zamanı system roluna gedir).

8. system‑prompt-da dinamik kontekst

Bəzən system‑prompt-a azca dinamiklik “qatmaq” gərək olur: cari tarix, lokal, istifadəçi tipi (yeni/köhnə müştəri), abunə statusu və s.

Məsələn, hədiyyə kataloqunuz və qiymətlər regiondan asılı olaraq fərqlənirsə, müvafiq regionu system‑prompt-a ötürə bilərsiniz:

export function buildSystemPrompt(locale: string) {
  return `
Rol:
- Sən — ${locale} regionu üçün hədiyyə seçimi üzrə köməkçi GiftGenius-san.

Sərhədlər:
- Yalnız ${locale} regionunda mövcud olan hədiyyələr və qiymətlərdən istifadə et.
...
`;
}

Apps SDK App inisializasiyası zamanı sizə _meta["openai/locale"] verə bilər, siz də onun əsasında lazım olan prompt variantını yaradarsınız. Lokalizasiya ilə detallı məşğul olacağıq, amma artıq indi görmək faydalıdır ki, system‑prompt həmişə statik olmaq məcburiyyətində deyil.

Əsas — onu şərtlərdən ibarət “spagetti”yə çevirməməkdir. Məntiq çox mürəkkəbləşirsə, App-ı bölmək və ya şərtləri tools-a çıxarmaq daha yaxşıdır (məsələn, MCP‑server locale‑a görə lazımi mənbəni özü seçsin), system‑prompt-da isə yalnız yüksək səviyyəli qaydalar qalsın.

9. system‑prompt tools təsvirləri və UX‑təlimatlarla necə əlaqəlidir

Bu dərs system‑prompt-a fokuslanır, amma real App-də o təkbaşına mövcud deyil. Hələ alətlərin təsvirləri də var (description, inputSchema) və növbəti mövzularda verəcəyiniz follow‑up nümunələri. Bunların hamısı birlikdə vahid təlimatlar sistemini yaradır.

tools çağırışının idarəsi:

• system‑prompt ümumi fəlsəfəni təyin edir: “alətlər yalnız faktiki məlumatlar üçün”, “hədiyyələri uydurma”, “təsdiqsiz alış etmə”;
• tools descriptions dəqiqləşdirir ki, recommend_gifts nə edir, hansı parametrlər lazımdır və nə zaman çağırılmalıdır;
• follow‑up ifadələri alət çağırışından sonrakı dialoq üslubunu qurur: heç nə tapılmayanda bunu necə dürüst demək, sorğunu necə dəyişməyi təklif etmək, nəticələri necə yekunlaşdırmaq və s.

Bu üç qat uyğundursa, model proqnozlaşdırılan kimi davranır:

• App-ı həqiqətən lazım olanda çağırır;
• bazadan kənar hədiyyə/malları hallüsinasiya etmir;
• baş verənləri aydın izah edir (tapıldı / tapılmadı / əlavə məlumat lazımdır).

Yoxsa — xaotik davranış alırsınız və “promptun sehrli tüninqi” ilə uzun seanslar başlayır, bu isə hamını tez yorur.

10. system‑prompt ChatGPT App ilə işləyərkən tipik səhvlər

Səhv №1: system‑prompt-u “gözəllik üçün” yazmaq, müqavilə kimi yox.
Çox vaxt inkişaf etdiricilər “İstifadəçiyə bacardığın kimi kömək et” və “Mehriban ol” tərzi ümumi cümlələrlə kifayətlənirlər. Bundan modelə nə zaman App-ı çağırmaq, məsuliyyət sərhədlərinin haradan keçdiyi, məlumat uydurub‑uydurmamaq və alət xətası zamanı nə etmək aydın olmur. Nəticədə məntiqin yarısı kod steklərinə və müəllifin başına səpələnir, açıq müqaviləyə yox.

Səhv №2: həddən artıq geniş rol (“hər şeydə kömək et”).
Rolda “Sən — istifadəçiyə bütün məsələlərdə kömək edən köməkçisən” yazsanız, model məhz bunu sevinclə edəcək və sizin App-ı hər zaman xatırlamayacaq. App “lazım olmayan seçim”ə çevrilir, çünki model onsuz da öhdəsindən gələcəyini düşünür. Nişanı aydın göstərin: hədiyyə seçimi, hədiyyə kataloqu ilə iş, konkret domenə yardım.

Səhv №3: alətləri nə zaman çağırmağı tənzimləyən qaydaların olmaması.
“Zərurət olduqca alətlərdən istifadə et” kimi formullar çox yayğındır. Model ya tools-u tamamilə görməzlikdən gələ, ya da “başından cavab vermək” mümkün olan yerdə belə onları çağıra bilər. Ssenariləri aydın ayırmaq lazımdır: faktiki məlumat → alət, fon izahı → modelin özü, istifadəçinin App-dan açıq imtinası → yalnız mətn.

Səhv №4: hallüsinasiyanı “uydurma” cümləsi ilə təkbaşına müalicə etməyə cəhd.
“Təklif: ‘hallüsinasiya etmə’” — özü‑özlüyündə az kömək edir. Dəqiq təsvir etmək vacibdir ki, nəyi uydurmaq qadağandır (kataloqdan kənar mallar/hədiyyələr, IDsiz mövqelər, mövcud olmayan endirimlər) və boş nəticə olanda nə etmək lazımdır (dürüst demək ki, heç nə tapılmadı). Bunsuz model yenə “xoşagələn” olmaq üçün uydurma variantlar yaradacaq. Tam dəst lazımdır: qlobal qadağa system‑prompt-da, məhdudiyyətlər tools təsvirlərində və “heç nə yoxdur” halları üçün cavab şablonları.

Səhv №5: təhlükəsizlik və istifadəçi razılığını görməməzlikdən gəlmək.
Əgər system‑prompt-da alış, bron və ya şəxsi məlumatların dəyişdirilməsinin açıq təsdiq tələb etdiyi yazılmasa, model “yaxşı niyyətə” əsaslanaraq aləti özü çağıra bilər. UX baxımından bu fəlakətdir. Maliyyə və ya hesabla bağlı istənilən əməliyyatın yalnız söhbətdə açıq razılıqdan sonra edildiyini həmişə yazın.

Səhv №6: digər App və alətlərin mövcudluğunu nəzərə almamaq.
Bir hesabda bir neçə App və xeyli tools olduğu dünyada, modelin “öz‑özünə başa düşəcəyini” güman etmək olmaz. Əgər system‑prompt bunun konkret olaraq hədiyyə seçimi üçün App olduğunu bərkitmirsə, model müxtəlif App-lar arasında gözlənilmədən keçə və ya alətləri təyinatına uyğun olmayan şəkildə tətbiq edə bilər.

Səhv №7: system‑prompt-u “isti‑isti” versiyalaşdırmadan və test etmədən düzəltmək.
Konfiqə girib bir sətri dəyişmək və “yalnız daha yaxşı oldu”na inanmaq cazibədardır. Təcrübədə prompta edilən istənilən düzəliş digər ssenarilərin davranışını poza bilər. Əgər system‑prompt repozitoriyada saxlanmırsa, difflər baxılmırsa və test sorğuları dəsti (golden prompt set — bu modulda ona gələcəyik) işlətilmirsə, reqressiyaları həftələrlə tutacaqsınız.