Voice / Realtime konteksti: səsli ünsiyyətdə App-in davranışı

1. Kontekst: ChatGPT App üçün «səsli rejim» nə deməkdir

İlk öncə başa düşmək vacibdir ki, ChatGPT Apps SDK çərçivəsində siz öz audio‑klientinizi yazmırsınız, mikrofona nəzarət etmisiniz və audionu özünüz stream etmirsiniz. Bununla ChatGPT klienti (veb və ya mobil tətbiq) məşğul olur.

Hesab edək ki, siz artıq vidcet, callTool və əvvəlki modullardan GiftGenius barədə baza təsəvvürə sahibsiniz — burada biz eyni elementlərə səsli rejimin prizmasından baxırıq.

Sizin App tərtibatçısı kimi baxışınızdan hər şey belə görünür:

• İstifadəçi mikrofona danışır. ChatGPT klienti nitqi tanıyır və modelə artıq mətn göndərir.
• Siz axında istifadəçi yazsaydı görəcəyinizin aynısını «görürsünüz», sadəcə onlar daha sürətli və daha «danışıq» formada gəlir.
• Model mətnlə cavab verir, klient isə onu səsləndirir.
• Eyni vaxtda model sizin alətlərinizi çağıra bilər (callTool), vidcetin displayMode-unu dəyişə bilər, widgetState-i yeniləyə bilər və follow‑up təklif edə bilər — mətn rejimində olduğu kimi.

Əsas fərq ondadır ki, istifadəçi ekrana heç baxmaya bilər və ya telefona «kənar baxışla» nəzər sala bilər. Yəni, UI artıq əsas qarşılıqlı əlaqə kanalı olmur və səsin əlavəsinə çevrilir, əksinə deyil.

Bundan iki nəticə çıxır:

• Həqiqətən vacib olan hər şey «qulaqla» başa düşülməlidir — GPT-nin repliki vasitəsilə.
• Videt «yaxşı mənada parlaq» olmalıdır: qısa baxışda dərhal status və əsas seçimlər görünməlidir, xırda mətni oxumağa ehtiyac qalmasın.

Bizim GiftGenius üçün bu dərhal ipucudur: «maşında gedirəm, ana üçün hədiyyə seç» ssenarisi təkcə mətn çatı deyil. Bu, səsin aparıcı olduğu, UI-nin isə sığortaladığı multimodal dialoqdur.

2. Voice ssenarisi mətn ssenarisindən nə ilə fərqlənir

«Bu hər şey eynidir, sadəcə istifadəçi səslə danışır» tələsinə düşməmək üçün bir neçə ox üzrə mətn və səs rejimlərini müqayisə etmək faydalıdır.

Buradan bir neçə vacib nəticə çıxır.

• İstifadəçinin «kartda oxuyacağına» arxayın olmaq olmaz. Kritik şeylər səslə deyilməlidir: nə başa düşdünüz, nə etməyə hazırlaşırsınız, hansı nəticəni aldınız.
• UI «1 saniyəyə baxış» ssenarisinə davam gətirməlidir. Status, proqres, əsas seçim — hamısı böyük şriftlə göz önündə olmalıdır. Detallar — ikincildir.
• Pauzaları doldurmaq lazımdır. MCP serveriniz ağır sorğu üzərində işləyərkən, model baş verəni səsləndirməli, vidcet isə proqres göstərməlidir ki, «donmuş assistent» hissi olmasın.

Səsli rejimə illüstrasiyalı audio‑kitab kimi baxmaq olar: sizdə səsli rəvayətçi (GPT) var və «şəkillər» (vidcet) var. Onları elə sinxronlaşdırmaq lazımdır ki, bir-birini tamamlasınlar, nə təkrarlasınlar, nə də ziddiyyətə düşsünlər.

3. Səsli rejimdə vidcetin rolu: «idarə paneli»ndən «tablo»ya

Mətn ssenarisində vidcet tez-tez tam funksional interfeys olur: formalar, cədvəllər, filtrlərlə karusellər, hərəkət düymələri. Səsli rejimdə onun rolu dəyişir. Multimodal interfeyslər və VUI üzrə tövsiyələr göstərir ki, səs ssenarilərində UI daha çox informasiya tablosu (glanceable UI) olur: o, sıx oxumaq üçün yox, sürətli yoxlama və təsdiqlər üçün lazımdır.

GiftGenius üçün bu belə deməkdir.

İstifadəçi səsli ustad (master) ilə irəliləyərkən, ekranda inline vidceti və ya fullscreen göstəririk:

• Böyük status: «Addım 2/3: büdcə və hədiyyə növü».
• Mətn minimum, amma dəqiq yazılar: «Büdcə 50 $‑dək», «Rəqəmsal hədiyyəyə üstünlük verilir».
• Səs ssenarisi kliklərə icazə verirsə, bir neçə iri CTA düyməsi: «Büdcəni dəyiş», «Davam et».
• On kiçik indikator əvəzinə bir sadə proqres zolağı və ya stepper.

Səs ssenarisi üçün inline vidcetdə sadə «tablo» nümunəsi (TypeScript + React, xeyli sadələşdirilmiş):

type VoiceUiMode = "default" | "voiceGlance";

interface GiftStepProps {
  step: number;
  totalSteps: number;
  summary: string; // artıq toplananların qısa təsviri
  uiMode: VoiceUiMode;
}

export function GiftVoiceStep(props: GiftStepProps) {
  const fontSize = props.uiMode === "voiceGlance" ? "text-lg" : "text-sm";

  return (
    <div className="rounded-xl border p-3 flex flex-col gap-2">
      <div className={`${fontSize} font-semibold`}>
        Addım {props.step} / {props.totalSteps}
      </div>
      <div className={`${fontSize} text-muted-foreground`}>
        {props.summary}
      </div>
    </div>
  );
}

Burada xüsusi «səs» yoxdur, amma aydın fikir var: uiMode === "voiceGlance" olduqda hər şeyi daha iri və sadə edirik. Səsli rejimə dair siqnal müxtəlif yerlərdən gələ bilər: dolayı əlamətlərdən tutmuş modelin widgetState-də və ya alət cavabında qoyduğu açıq flaqadək.

4. Modaliteyin sinxronizasiyası: GPT nə deyir və App nə göstərir

Apps üçün voice‑UX-in əsas prinsipi — modaliteyin sinxronizasiyası: səs və vizual UI eyni hekayəni danışmalıdır, amma fərqli detallanma səviyyələrində.

Tipik səhv — tərtibatçının modeli vidcetdə göstərilənlərin hamısını ucadan oxumağa məcbur etməsi: hədiyyələrin uzun siyahıları, filtrlərlə JSON strukturları və s. Bu, işgəncəyə çevrilir. Tövsiyə: səs qısa yekun (summary) verir, UI isə detalları göstərir.

GiftGenius üçün düzgün sinxronizasiya nümunəsi.

İstifadəçi: «Anama hədiyyə seç, bağçılığı sevir, büdcə 50 dollaradək».

Model (səslə): «Bir neçə variant seçdim. Mənim fikrimcə, ən yaxşısı — 45 dollar dəyərində bağ alətləri dəstidir. Ekranda daha iki oxşar variant göstərdim. Ətraflı danışım, yoxsa birbaşa seçək?»

Videt (inline): üç hədiyyə kartı, qısa təsvir və CTA düymələri «Seç» / «Oxşarları göstər» göstərir.

Bir addımın dialoq‑JSON‑abzaslı təsviri (bu real protokol deyil, düşüncə illüstrasiyasıdır):

{
  "user": "Anama hədiyyə seç...",
  "assistant_text": "Bir neçə variant tapdım...",
  "widget": {
    "displayMode": "inline",
    "state": {
      "view": "gift_list",
      "items": [
        { "id": "g1", "title": "Bağ alətləri dəsti", "price": 45 },
        { "id": "g2", "title": "Bağban üçün önlük", "price": 30 },
        { "id": "g3", "title": "Gül toxumları dəsti", "price": 20 }
      ]
    }
  }
}

Vacib detal: system‑prompt‑da modelin UI haqqında necə danışmalı olduğunu açıq yazın ki, «JSON oxumasın»: «Əgər vidcetdə variantlar siyahısı göstərirsənsə, hər birini tam oxuma. Qısa olaraq ən yaxşı variantı təsvir et və digərlərinin ekranda göründüyünü de».

Gələcəkdə, Realtime API və öz voice‑klientlərinizlə işləyəndə də prinsip eyni qalacaq: UI və audio axın razılaşdırılmalıdır. Sadəcə orada sizdə stream üzərində birbaşa nəzarət olacaq.

5. Realtime və gecikmə: narahat sükutun qarşısını necə almaq

Texniki olaraq səsli rejimdə tool_calls mətn rejimindəki kimidir: model alətinizi çağırmaq qərarı verir, siz cavabı qaytarırsınız, vidcet yenilənir. Amma səsdə yeni bir UX problemi yaranır — gecikmələr. MCP serveriniz xarici API-lərə gedərkən və ya mürəkkəb hesabat hesablayarkən istifadəçi… heç nə eşitmir. Bu isə sadəcə çatda mətn gözləməkdən daha pis qəbul olunur.

Burada iki müdafiə səviyyəsi var: səsli və vizual.

• Səs səviyyəsində system‑prompt modelə «işləyirəm» deməyə və alət hələ hesablayarkən əlavə suallar verməyə icazə verməli (və həvəsləndirməli)dir. Məsələn: «İndi hədiyyələri seçəcəyəm, bu bir neçə saniyə çəkəcək. Bu arada əlavə məhdudiyyətlər varsa, de».
• Vizual səviyyədə vidcetiniz proqresi çox aydın göstərməlidir: yükləyici (loader), «Variantlar axtarıram…» statusu, cari addım. Bunsuz istifadəçi hər şeyin donduğunu düşünəcək və danışmağa davam edərək səs axınını poza bilər.

Praktikada bunu təxirə salınmış tapşırıqla həll etmək rahatdır: alət dərhal "pending" statusu və jobId qaytarır, uyğunlaşdırma isə fon rejimində gedir. Vidcet "pending" görəndə proqres göstərir, səs isə «işləyirəm» deyir.

Tam nəticəni gözləyib bloklanmaq əvəzinə job‑id ilə «stub» qaytaran belə bir server‑side alətin ən sadə sxemi belə görünə bilər:

// GiftGenius üçün server tərəf alətinin psevdokodu
export async function startGiftSearch(params: SearchParams) {
  const jobId = await createBackgroundJob(params); // tapşırığı növbəyə qoyuruq

  return {
    status: "pending",
    jobId,
    message: "Hədiyyə axtarışı başladıldı"
  };
}

Videt status: "pending" gördükdə UI-ni proqres rejiminə keçirə bilər:

if (toolOutput.status === "pending") {
  return (
    <div className="p-4 rounded-xl border flex items-center gap-3">
      <Spinner />
      <div className="text-base">
        Hədiyyələri seçirəm… Bu bir neçə saniyə çəkəcək.
      </div>
    </div>
  );
}

Həmin tool‑output-a cavab olaraq model, təlimatlara uyğun şəkildə, təxminən eyni şeyi səslə deyəcək və bəlkə də əlavə aydınlaşdırıcı sual verəcək. Sonra, fon tapşırığı bitəndə və, məsələn, MCP bildirişi ilə job.completed gəldikdə, vidcet hədiyyələr siyahısına yenilənir, səs isə onların yekununu səsləndirir.

Beləcə, backend dərhal işləməsə belə, real‑time‑a maksimal yaxın davranış əldə edirik.

6. Təhlükəsizlik və səsdə təsdiqlər

Səsli interfeys kritik hərəkətlər (ödəniş, məlumatların silinməsi, sazlamaların dəyişdirilməsi) söhbətə gələndə çox hiyləgərdir. Nitqin tanınması ideal deyil, istifadəçilər «yolda» danışır və «hə» asanlıqla «bəli, al»a çevrilə bilər. Buna görə səs ssenarilərində confirmation flows xüsusilə vacibdir.

İki baza pattern var.

• Aydın səs təsdiqi (Explicit Voice Confirmation). Təhlükəli hərəkətlər üçün konkret ifadə tələb edirsiniz. Məsələn: «Alışı təsdiqləmək üçün belə deyin: “Alışı təsdiq edirəm”» — və system‑prompt-da dumanlı «hə», «oldu», «gəlin» kimi sözlərlə ödənişi qadağan edirsiniz.
• Yalnız vizual təsdiq (Visual Confirmation Only). Model səslə istifadəçini hərəkətə gətirir («Sifarişi hazırladım, ekranda yekun məbləğ və səbətin məzmunu göstərilib»), amma faktiki tetik — vidcetdəki «Ödə» düyməsinə klikdir. Bu, xüsusilə commerce ssenarilərində aktualdır və biz buna 14‑cü moduldə qayıdacağıq.

GiftGenius üçün bu belə görünə bilər.

Model: «Mən 45 dollar dəyərində əla bağçılıq dəsti tapdım. ChatGPT vasitəsilə alışı rəsmiləşdirə bilərəm. Ekranda yekun qiymət və çatdırılma ünvanı göstərilib. Səs ilə təsdiq etmək üçün “Alışı təsdiq edirəm” deyin və ya ekrandakı “Ödə” düyməsini basın.»

Videt (fullscreen): yekun sifarişi göstərir, məbləği və ünvanı qalın vurğulayır və iki nəzərə çarpan düymə: «Ödə» və «Ləğv et».

Videt daxilində təsdiq statusunu əks etdirə bilərsiniz:

type CheckoutState = "review" | "waiting_voice_confirm" | "confirmed";

if (state.phase === "waiting_voice_confirm") {
  return (
    <div className="space-y-3">
      <h2 className="text-xl font-semibold">Demək olar ki, hazırdır</h2>
      <p className="text-base">
        Alışı səs ilə
        «Alışı təsdiq edirəm» ifadəsi ilə təsdiqləyin və ya «Ödə» düyməsini basın.
      </p>
      <Button variant="primary">Ödə</Button>
      <Button variant="ghost">Ləğv et</Button>
    </div>
  );
}

Beləliklə, model səsdə nəyisə səhv interpretasiya etsə belə, istifadəçinin vizual «sığorta» qatına çıxışı qalır.

7. Sadə səs komandaları və alət dizaynı

Səsli istifadəçi alətinizin dəyişənləri kimi komandaları dəqiq formalaşdırmayacaq. O, «birincini seç», «daha ucuzunu göstər», «gəlin texnikasız olsun» deyəcək. Tərtibatçının vəzifəsi — alətləri və system‑prompt-u elə dizayn etməkdir ki, model bu tip ifadələri alət çağırışları ilə (callTool) asanlıqla tutuşdursun.

GiftGenius üçün, məsələn, belə hərəkətləri nəzərdə tuta bilərsiniz:

• Ekranda göstərilən variantlardan birinin indeksə və ya id-yə görə seçilməsi.
• Büdcənin dəqiqləşdirilməsi: «daha ucuz», «30 dollaradək».
• Növ üzrə filtrasiya: «yalnız rəqəmsal hədiyyələr», «poçtla göndəriləni istəmirəm».

Bunu enum tipli sadə action parametrli və əlavə sahələri olan alətlə ifadə etmək rahatdır:

// TypeScript-də alətin psevdosxemi
type VoiceActionInput =
  | { action: "select_item"; itemId: string }
  | { action: "refine_budget"; maxPrice: number }
  | { action: "filter_type"; type: "digital" | "physical" };

export function handleVoiceAction(input: VoiceActionInput) {
  switch (input.action) {
    case "select_item":
      // hədiyyəni seçilmiş kimi işarələyirik
      break;
    case "refine_budget":
      // seçimləri yeni büdcəyə uyğun yenidən hesablayırıq
      break;
    case "filter_type":
      // mövcud siyahını filtrlayırıq
      break;
  }
}

System‑prompt-da bu hərəkətlərin səsli komandalarla necə əlaqələndiyini təsvir edirsiniz: «İstifadəçi “birinci variantı seç” deyirsə, gift.voiceAction alətini action="select_item" və ekrandakı birinci hədiyyənin identifikatoru ilə çağır» və s.

UX baxımından bu, kognitiv yüklənməni azaldır: istifadəçi «yalnız 30$‑dək rəqəmsal hədiyyələr olsun» kimi dəqiq formullar düşünməyə məcbur deyil. O, insani danışır, model isə bunu məlumat strukturlarına çevirir.

8. GiftGenius üçün səs ssenarisi: üç addım

Gəlin hər şeyi bir yerə yığaq və hələ ki, low‑level Realtime API-ə getmədən GiftGenius üçün tam səs ssenarisi dizayn edək.

İstifadəçini təsəvvür edin: maşında gedir və ChatGPT-nin səsli rejimini işə salır. Deyir: «Zəhmət olmasa, ana üçün hədiyyə seç, bağını sevir, büdcə 50 dollaradək».

Addım 1. Məlumatın səs ilə toplanması

Model: «Əla, gəlin hədiyyə seçək. Bir neçə məqamı dəqiqləşdirim: hədiyyə nə vaxt lazımdır — yaxın günlərdə, yoxsa sonra? Və məhdudiyyətlər varmı, məsələn, heç nə ağır və ya həcmli olmasın?»

Videt (inline): hələlik yalnız kiçik panel — «Kimin üçün seçirik: ana, bağçılıq, 50 $‑dək» statusu ilə. Şriftlər adi haldan bir az böyükdür ki, tək baxışla oxumaq mümkün olsun.

Videt vəziyyəti üçün kod belə görünə bilər:

interface GiftSessionState {
  mode: "voice" | "text";
  step: 1 | 2 | 3;
  recipientSummary: string;
  budget?: number;
}

const [state, setState] = useState<GiftSessionState>({
  mode: "voice",
  step: 1,
  recipientSummary: "Ana, bağçılıq sevir"
});

Server hissə istifadəçi cavablarına uyğun olaraq recipientSummary və budget-i yeniləyir, vidcet isə reaksiya verir.

Addım 2. Axtarış və gözləmə

Model kifayət qədər məlumat toplayandan sonra hədiyyə axtarışı alətinizi çağırır. O isə, uyğunlaşdırma çətindirsə, fon tapşırığı başlada və status: "pending" qaytara bilər. Fon işləyərkən model deyir: «İndi uyğun variantları axtaracağam, bu bir neçə saniyə çəkəcək. Bu arada, o, fiziki hədiyyələri üstün tutur, yoxsa rəqəmsal sertifikatlar da uyğundur, deyə bilərsən».

Videt istifadəçi interfeysin başqa hissəsinə keçərsə «PiP‑bənzər» rejimə keçir, ya da proqreslə inline qalır: «Hədiyyələr axtarıram…» və kiçik indikator.

Addım 3. Nəticələr və seçim

Nəticələr hazır olanda model: «Mən üç variant tapdım. Birinci — 45 dollar dəyərində bağ alətləri dəsti. İkinci — 30 dollara bağban üçün önlük. Onları ekranda göstərdim. “birincini seç” de və ya “daha ucuzunu göstər”».

Videt qiymətlər və qısa təsvirlərlə üç iri kart göstərir. Hər kartda «Seç» və «Oxşarları göstər» CTA-ları var. Üstəlik ayrıca «Daha çox variant göstər» düyməsi.

İstifadəçi «İkincini seç» deyirsə, model voiceAction alətinizi action="select_item" və ikinci hədiyyənin id-si ilə çağırır. Vidcet onu seçilmiş kimi vurğulayır, model isə səsləndirir: «Əla, 30 dollar dəyərində bağban üçün önlüyü seçdik».

İxtiyari Addım 4. Checkout

App ödənişlərlə inteqrasiya olunubsa (gələcək 14‑cü modulda), checkout başlayır. Model şərtləri səsləndirir və səs ilə və ya düymə ilə təsdiq istəyir. Vidcet fullscreen ustada «Sifarişin yoxlanması» → «Çatdırılma ünvanı» → «Təsdiqləmə» addımlarına keçir.

Vacibdir ki, hər addımda əsas məzmun səslə deyilsin, vidcet isə xüsusilə istifadəçi dayanıb ekrana baxanda vizual dayaq rolunu oynasın.

9. Reallaşdırma üzrə praktik qeydlər və Apps SDK sərhədləri

GiftGenius üçün təsvir olunan addımlar adi ChatGPT App daxilində reallaşır — ayrıca audio‑klient və WebRTC olmadan. Burada stack sərhədlərini unutmaq olmaz.

Realtime API, WebRTC, audio streaming mövzularına «uçmaq» və beyninizdə öz səs platformanızı qurmaq çox asandır. Bunun üçün kursda ayrıca 20‑ci modul var. Bu mühazirədə isə konkret olaraq ChatGPT klientinin içindəki ChatGPT App sərhədlərini xatırlamaq vacibdir.

Cari memarlıqda:

• Audio axınına ChatGPT klienti nəzarət edir. Siz vidcetdə audio baytları nə göndərir, nə də qəbul edirsiniz.
• Backend-də hələ də adi alət çağırışlarını və mətn mesajlarını görürsünüz, ancaq model səsli rejimdə ola bilər və cavablar səsləndiriləcək.
• Platforma hazırda voice rejiminin işarələrini dolayı yollarla verə bilər (user-agent və ya mühit sahələri vasitəsilə). Amma buna sərt asılılıq qurmaq olmaz: API dəyişə bilər və App-iniz sırf mətn rejimində də faydalı qalmalıdır.

Bu səbəbdən implementasiya üçün yaxşı strategiya belədir. Əvvəlcə həm mətn, həm də səs üçün normal işləyən UX dizayn edirsiniz: qısa statuslar, dəqiq CTA-lar, anlaşılan proqres mərhələləri. Sonra səs üçün bir neçə təkmilləşdirmə əlavə edirsiniz: "voiceGlance" rejimində bir az daha iri şriftlər, daha aşkar proqres, «Addım 2/3» kimi statuslara və «Təsdiqi gözləyirəm» kimi aydın vəziyyətlərə vurğu.

Əlavə olaraq system‑prompt-da modelin səs davranışını təsvir edirsiniz: vidcet vəziyyətini necə şərh edir, təsdiqlər üçün hansı ifadələrdən istifadə edir, hansı sözlərdən qaçır (məsələn, JSON oxumur, siyahıdakı hər xırdalığı səsləndirmir).

Sonralar Realtime API üzərində öz Custom Voice Client-inizi hazırlasanız, bu UX qərarlarının hamısı ora rahat «köçəcək». Fərq yalnız hadisələrə və streamingə çıxış səviyyəsində olacaq, prinsiplərdə yox.

10. Voice / Realtime konteksti ilə işləyərkən tipik səhvlər

Səhv №1: «UI-ı səs ilə oxumaq» əvəzinə qısa yekun.
Bəzən tərtibatçılar alətləri elə yazırlar ki, model JSON cavabının bütün məzmununu və ya kartların tam siyahısını ucadan oxumağa başlayır. Səsli rejimdə bu, UX-i öldürür: istifadəçi ipi itirir, siz isə tokenləri israf edirsiniz. Daha yaxşısı — səs qısa yekun versin və bir-iki varianta fokuslansın, qalanı ekranda qalsın.

Səhv №2: Səsdə vizual geribildirimin tam yoxluğu.
«İstifadəçi danışırsa, deməli, dinləyir, UI lazım deyil» kimi düşünmək cazibədardır. Praktikada istifadəçi tez-tez ekrana göz gəzdirir və ya bir dəqiqə sonra qayıdır. Bu an orada nə status, nə proqres, nə də aydın yekun yoxdursa, App-in donduğunu və ya heç nə etmədiyini düşünəcək. Mütləq «Düşünürəm», «Addım 2/3», «Nəticələr hazırdır» və s. göstərin.

Səhv №3: Güclü təsdiq olmadan təhlükəli hərəkətlər.
Mətn rejimində bir düymə ilə «Ödə» etmək risklidirsə, səsdə dumanlı «hə» ilə alışı yerinə yetirmək daha da təhlükəlidir. Aydın confirmation flow-ları (səsli və/və ya vizual) görməməzlikdən gəlmək səhv alışlara və App-ə inam problemlərinə gətirir. Hansı hərəkətlərin ikiqat təsdiq tələb etdiyini düşünün və bunu həm system‑prompt-da, həm də UI-da açıq təsvir edin.

Səhv №4: Gözə deyil, qulağa fokuslanmamaq.
Bəzən App elə dizayn edilir ki, guya istifadəçi həmişə mətni oxuyur: çox mürəkkəb ifadələr, uzun düymələr, yüklənmiş təsvirlər. Səs rejimində bütün bunlar səsləndirilməlidir — «söz şorbası» alınır. Əsas mənanı qulaqla asan qavranılan, qısa və sadə cümlələrə sığışdırmağa çalışın.

Səhv №5: Apps SDK ilə öz Voice‑klientinizi qarışdırmaq.
Bəzi tələbələr Apps SDK-da mikrofon hadisələri, audio streaming, WebRTC və s. axtarır, Realtime API-dəki kimi, və «bunların heç biri yoxdur» deyə məyus olurlar. Başa düşmək vacibdir: ChatGPT App, ChatGPT klientinin içində yaşayır və səsə platforma nəzarət edir. Siz mətn, alət çağırışları və vidcet vəziyyəti ilə işləyirsiniz və UX-i elə dizayn edirsiniz ki, səsli rejim «sadəcə yaxşı işləsin». Səs üzərində tam nəzarət lazımdırsa, bu artıq Realtime API ilə ayrıca, daha mürəkkəb layihədir.

Səhv №6: Gecikmələrlə iş üzrə strategiyanın olmaması.
Uzunmüddətli əməliyyatlar zamanı modelin nə dediyini və vidcetin nə göstərdiyini düşünməsəniz, istifadəçi sözünüzü kəsəcək, yeni suallar verəcək və flow-u pozacaq. Gecikmələr səsdə mətndən daha güclü hiss olunur. Sükutu «baga» çevirməmək üçün aralıq statuslardan, fon tapşırıq emalından və «düşünürəm, bu arada danış…» kimi səsli frazalardan istifadə edin.