1. Multi‑App ssenariləri nədir və niyə sizə lazımdır
İndiyə qədər GiftGenius‑a ayrıca bir söhbətdə yeganə xarici tətbiq kimi baxırdıq: istifadəçi sizin App‑ı siyahıdan seçir, ChatGPT sizin tools‑ları qaldırır və siz “hekayənin əsas qəhrəmanı” olursunuz. Real Store‑da isə başqa cürdür: istifadəçi eyni anda bir neçə App qoşa bilər və ChatGPT konkret sorğuya cavab olaraq hansı tətbiqi çağıracağını özü qərar verir.
Məsələn, bir söhbətdə belə App‑lar ola bilər:
- şirkət təqvimi App‑ı, əməkdaşların ad günlərini bilir;
- GiftGenius, hədiyyə ideyaları seçir;
- şirkətin commerce‑App‑ı, sifarişləri və ödənişi rəsmiləşdirə bilir.
İstifadəçi yazır: “Mənə həmkarların ad günlərini xatırlat və dərhal nə hədiyyə etmək və necə almaq barədə təklif ver”. Model ardıcıl olaraq üç fərqli App çağıra bilər: biri — təqvim üçün, ikinci — hədiyyə ideyaları üçün, üçüncü — checkout üçün.
Vacib məqam: istifadəçinin “xahiş, App №2‑ni çağır və budur onun HTTP‑endpoint‑i” düyməsi yoxdur. O, təbii dildə danışır, ChatGPT isə router kimi çıxış edir — bütün əlçatan tətbiqlərin descriptions və meta‑məlumatlarını oxuyur və kimi, nə vaxt çağıracağını qərarlaşdırır.
Buradan üç əsas fikir çıxır:
- Kontekst uğrunda rəqabət gedir. App‑ınız onlarla başqası arasından təsvirlər, adlar və davranış əsasında seçilməlidir.
- Meta‑məlumatlar sizin “LLM üçün SEO”nuz olur — məhz onlar müəyyənləşdirir ki, model lazımi anda GiftGenius‑u görəcəkmi, yoxsa görməyəcək.
- İnteroperabellik haqqında düşünmək lazımdır: cavablarınız təkcə söhbətdəki insana deyil, eyni konteksti oxuyan digər App‑lara da faydalı olmalıdır.
Əslində, izolyasiya olunmuş ChatGPT App‑ını daha böyük bir sistemin komponentinə çeviririk.
2. Model App‑ı necə seçir: routing üçün mental model
Multi‑App ssenarilərində routing təxminən belə işləyir (çox sadələşdirərək, amma inkişaf üçün faydalıdır):
- ChatGPT‑nin əlçatan App siyahısı və onların tools‑ları haqqında meta‑məlumatı var (ad, təsvir, JSON Schema parametrləri, annotasiyalar və _meta).
- İstifadəçi mesaj yazır.
- Model daxili niyyət (intent) təsviri qurur və mahiyyətcə descriptions — həm tools, həm də tətbiqlər üzrə semantik axtarış edir ki, hansı alətlər uyğundur anlasın.
- Kriteriyalar uyğun gəlirsə — tool çağırır və ya App açmağı təklif edir.
Burada vacib nüans var: descriptions kifayət qədər fərqləndirici olmalıdır. “Məhsul axtarışı” formulu “Hədiyyə axtarışı” və ya “Kitab axtarışı”ndan az fərqlənir, amma “GiftGenius tərəfdaş bazası üzrə hədiyyə ideyalarının axtarışı” domeni ciddi daraldır və məhz sizin alətin hədiyyə sorğuları üçün seçilmə şansını artırır.
İkinci detal — ad koliziyalarından yayın. get_data adlı alət onlarla App arasında demək olar heç nə demir, amma giftgenius_get_gift_catalog xeyli aydındır. Xüsusən də dəqiq description ilə birlikdə.
Və nəhayət, model kontekstə söykənir: söhbətdə artıq “hədiyyələr”, “ad günləri” və hətta GiftGenius adı çəkilibsə, bu, sizin App‑ınızı routerin gözündə vurğulayır.
3. Meta‑məlumatlar və descriptions LLM‑SEO kimi
Meta‑məlumatları sadəcə “JSON‑da məcburi formalıq” kimi deyil, məhsul kopiraytinqi kimi düşünmək faydalıdır. Rəsmi tövsiyələr açıq deyir: treat metadata like product copy və “one job per tool” prinsipini layihələndirin.
Şərti olaraq bir neçə təsvir səviyyəsi ayırmaq olar:
| Səviyyə | Kim üçün | Nəyi təsvir edir |
|---|---|---|
| Manifest description | İnsan + model | Bütün App‑ın vəzifəsi: niyə onu söhbətə qoşmaq lazımdır |
| Tool description | Model (routing) | Konkret tool nə vaxt və hansı tapşırıqlar üçün istifadə olunur |
| Parameter descriptions | Model (slot fill) | Argümentləri necə doldurmaq, hansı dəyərlər uyğundur |
|
Model (UI) | Vidcetdə nə göstəriləcəyini və bunu modelin mətn cavabında təkrarlamaq lazım olub‑olmadığını |
widgetDescription vidcetlər dünyasında xüsusilə önəmlidir: model sizin React kodunuzu “görmür”, yalnız hansı props verəcəyinizi və nə üçün verdiyinizi bilir. Yaxşı doldurulmuş sahə ona sizin yerinizə “uydurmaq” əvəzinə, göstərilən UI‑ni nəzərə alaraq mətn cavablarını uyğunlaşdırmağa imkan verir.
Apps SDK sənədləri vurğulayır: ChatGPT meta‑məlumatlara əsaslanaraq, konnektorunuzu (App) nə zaman və necə çağıracağını qərar verir. Dəqiq descriptions və parametrlərə dair sənədlər recall‑u artırır — modelin ümumiyyətlə App‑ınızı xatırladığı situasiyaların payını — və yalnış çağırışları azaldır.
Mini‑nümunə: GiftGenius üçün köhnə vs yeni description
Tutaq ki, bizdə əvvəl belə bir şey var idi:
export const appDescription = `
GiftGenius — hədiyyələri tapmaq və almaq üçün köməkçi.
`;
İnsan baxımından pis deyil, amma Multi‑App dünyasında routing üçün daha yaxşısı App‑ın nə zaman istifadə olunacağını və nələri etmədiyini vurğulamaqdır:
export const appDescription = `
GiftGenius — hədiyyə ideyaları üzrə asistenti.
İstifadəçi konkret bir şəxs və ya münasibət üçün və büdcəyə uyğun hədiyyə istədikdə bu tətbiqdən istifadə et.
Ümumi onlayn alış-veriş və ya şəxsi maliyyə planlaşdırması üçün istifadə etmə.
`;
İndi model üçün GiftGenius‑u ümumi e‑commerce App‑ından və ya maliyyə məsləhətçisindən ayırd etmək daha asandır.
4. _meta["openai/widgetDescription"]: modelə UI‑mizi izah edirik
Yuxarıdakı cədvəldə ayrıca _meta["openai/widgetDescription"] qeyd etdik. İndi bu səviyyəyə fokuslanaq: o, modelə vidcetinizi “təsəvvür etməyə” və cavabın hansı hissələrinin artıq UI ilə əhatə olunduğunu, hansını isə mətnlə deməyin daha yaxşı olduğunu anlamağa kömək edir.
Tutaq ki, əsas alətimiz suggest_gifts hədiyyə siyahısı qaytarır və vidcet onları üfüqi kart karuseli kimi göstərir. Alətin təsvirində artıq nə zaman istifadə olunacağını izah etmişik, widgetDescription hissəsində isə nəticənin necə göründüyünü izah edirik.
Alət deskriptorundan fraqment nümunəsi (sadələşdirilmiş, tövsiyələr əsasında):
const suggestGiftsTool = {
name: "suggest_gifts",
description: "Use this to generate gift ideas within user's budget.",
inputSchema: { /* ... */ },
_meta: {
"openai/widgetDescription":
"Üfüqi hədiyyə kartları siyahısını qiymət və 'Al' düyməsi ilə göstərir. Mətn cavabında hədiyyə adlarını təkrarlama."
}
};
Burada bir anda bir neçə məqsədə çatırıq:
- Model bilir ki, UI artıq adları və qiymətləri göstərəcək — deməli, mətn cavabında siyahını təkrarlamaq əvəzinə izah və məsləhətlərə fokuslana bilər.
- Digər App‑lar (model vasitəsilə) başa düşür ki, toolOutput sadəcə mətn abzası deyil, “öz kontekstlərində” istifadə edə biləcəkləri strukturlu siyahıdır.
Və bəli, etiraf edək: belə təsvirlər yazmaq kod yazmaqdan daha cansıxıcıdır, amma məhz onlar sonradan modelin qəribə davranışlarını debug etməyə sərf olunan saatları sizə qənaət etdirəcək.
5. Alət annotasiyaları: readOnlyHint, destructiveHint, openWorldHint
Multi‑App dünyasında təkcə “nə vaxt çağırmaq” deyil, həm də konkret aləti nə dərəcədə təhlükəsiz çağırmaq vacibdir. Bunun üçün Apps SDK alət deskriptorlarında annotasiyalar toplusu təqdim edir.
İdeya belədir: annotasiyalar əməliyyatın xarakteri barədə modelə yumşaq ipuclarıdır. Onlar server tərəfli avtorizasiyanı əvəz etmir, lakin ChatGPT‑nin zəncirlərdə necə davranmasına ciddi təsir edir.
Qısa xülasə (konseptual):
| Annotasiya | Məna | Modelin tipik davranışı |
|---|---|---|
|
Məlumatları dəyişmir | Artıq təsdiq olmadan, tez‑tez çağırmaq olar |
|
Vəziyyəti dəyişir (alış, silmə) | Çağırışdan əvvəl istifadəçidən təsdiq istə |
|
“Xarici dünyaya” çıxır (axtarış, veb) | Model nəticənin həcmi və keyfiyyəti ilə daha ehtiyatlıdır |
Annotasiyalar (readOnlyHint, destructiveHint, openWorldHint) — alətin standart təsvirinin bir hissəsidir və təkcə ChatGPT tərəfindən istifadə olunmur. _meta["openai/isConsequential"] — daha dar, ChatGPT‑yə məxsus siqnaldır; modelə “təhlükəsiz” və “nəticəli” çağırışları daha yaxşı ayırd etməyə əlavə kömək edir.
GiftGenius‑un iki alətinə baxaq:
- suggest_gifts — kataloqu oxumaq, təhlükəsizdir.
- create_checkout_session — checkout yaradılması, açıq side‑effect əməliyyat.
suggest_gifts alətinin təsviri nümunəsi
const suggestGiftsTool = {
name: "suggest_gifts",
description:
"Use this when the user asks for gift ideas for a person or occasion.",
inputSchema: { /* ... */ },
annotations: {
readOnlyHint: true
},
_meta: {
"openai/widgetDescription": "Qiymət və keçidlə hədiyyə karuseli.",
"openai/isConsequential": false
}
};
Belə aləti model ard‑arda bir neçə dəfə, hətta “preventiv” olaraq da çağıra bilər — variantları əvvəlcədən hazırlamaq üçün, hər dəfə istifadəçidən icazə istəmədən.
create_checkout_session alətinin təsviri nümunəsi
const createCheckoutTool = {
name: "create_checkout_session",
description:
"Finalize purchase of selected gifts via Instant Checkout.",
inputSchema: { /* ... */ },
annotations: {
destructiveHint: true
},
_meta: {
"openai/isConsequential": true
}
};
Burada açıq siqnal veririk: bu, yazma (write) əməliyyatıdır, nəticələri var (pul silinir, sifariş yaradılır) və model, xüsusən bir neçə App ilə uzun zəncirlərdə, çağırmazdan əvvəl istifadəçidən təsdiq istəməlidir.
Sehrə arxalanmayın: hətta destructiveHint ilə belə, serverdə daxil olan məlumatları, tokenləri və hüquqları yenidən yoxlamağa borclusunuz — təhlükəsizlik və avtorizasiya barədə modullarda danışdığımız kimi. Lakin Multi‑App orkestrasiyası baxımından annotasiyalar modelin belə alətləri ehtiyac olmadan “atəşləməsinə” mane olur.
6. İzolyasiya olunmuş App vs ekosistem: GiftGenius‑un sərhədlərini dəqiqləşdiririk
GiftGenius söhbətdə yeganə App olanda, xeyli geniş scope‑a icazə vermək olardı: hədiyyə seçimi, qablaşdırma məsləhətləri, bayram xatırlatmaları, hətta təbrik üçün kiçik motivasiya mətnləri. Model onsuz da yalnız sizin alətləri çağıracaqdı.
Multi‑App ssenarisində belə “hər şeyi mən edirəm” yanaşması zərər verməyə başlayır:
- router hansı hallarda ideal namizəd olduğunuzu, hansı hallarda isə başqa App‑ın daha yaxşı olduğunu pis ayırd edir;
- təqvim, ümumi tapşırıq meneceri, maliyyə planlaşdırıcısı və s. ilə kəsişirsiniz;
- bir neçə tətbiqin birgə istifadəsində model “yanlış” icraçını seçə və alətlərdə çaşıb qala bilər.
Ən yaxşı yanaşma — məsuliyyət zonasını dəqiq çəkməkdir:
- GiftGenius: yalnız hədiyyə ideyaları + ACP/Checkout vasitəsilə alışda kömək;
- CalendarApp: hadisələr və xatırlatmalar;
- Finance‑App: istifadəçinin ümumi büdcəsi, şəxsi maliyyə planı.
App və alət təsvirlərində təkcə “Use this when…” deyil, həm də “Do not use when…” yazmaq faydalıdır. Rəsmi discovery‑playbook məhz bunu tövsiyə edir.
Alət təsviri üçün mini‑nümunə:
description: `
Use this tool when the user explicitly asks for gift suggestions.
Do not use for generic product discovery or price comparison.
`
Belə məhdudiyyətlər routing‑ə kömək etməklə yanaşı, App‑ınızın davranışını məhsul və QA üçün daha proqnozlaşdırıla bilən edir.
7. Apps kompozisiyası nümunələri: pipeline, handoff, shared context
Multi‑App ssenarilərində praktikada üç bağlı ideya üzə çıxır:
- pipeline — bir neçə App ardıcıl gedir (təqvim → hədiyyələr → commerce), hərəsi öz addımını yerinə yetirir;
- handoff — bir App‑ın çıxışı növbətinin girişi olur;
- shared context — bu ötürmə birbaşa HTTP çağırışları olmadan söhbətin ümumi mətn konteksti vasitəsilə baş verir.
Artıq qeyd etdiyimiz kimi, Multi‑App ssenarisi “App A HTTP ilə App B‑ni çağırır” sehrindən ibarət deyil. Cari ChatGPT Apps reallaşdırmasında izolyasiya xeyli sərtdir: tətbiqlər bir‑birini birbaşa çağırmır, kommunikasiya ümumi mətn konteksti ilə gedir.
Əsas nümunəni belə formalaşdırmaq olar:
- App A söhbətə mətn və ya JSON qaytarır (tez‑tez structuredContent/vidcet daxilində).
- Model bu çıxışı oxuyur.
- Növbəti addımda App B‑ni çağıra bilər və A‑nın cavabındakı detalları onun tools arqumentlərinə yerləşdirə bilər.
Buna text/context handoff deyilir: “App A çıxışı → model → App B girişi”.
Nümunə: CalendarApp + GiftGenius + CommerceApp
Konret ssenarini nəzərdən keçirək.
İstifadəçi: “Rəhbərin sabah ad günüdür, hədiyyə seç və dərhal alışı rəsmiləşdir”.
Addım‑addım:
-
Model əvvəlcə tarixi və şəxsi anlamaq lazım olduğunu başa düşür. O, təqvim App‑ının alətini çağırır, şərti corporate_calendar.list_upcoming_birthdays, və belə bir struktur alır:
[ { "name": "Aleksey Bykov", "date": "2025-11-22", "relation": "manager" } ] -
Sonra model qərar verir ki, GiftGenius‑u çağırmaq vaxtıdır. O, sizin suggest_gifts alətinizi təqvimdən götürülmüş arqumentlərlə çağırır:
{ "recipientName": "Aleksey", "occasion": "birthday", "budget": 150, "relationship": "manager" }GiftGenius vidceti hədiyyələrin karusellərini göstərir, mətn cavabı isə bu ideyaların niyə yerində olduğunu izah edir.
-
İstifadəçi bir‑iki variant seçir (vidcet düyməsi → widgetState), və model artıq commerce‑App alətini çağırır, məsələn corp_checkout.create_gift_order, seçilmiş SKU‑ların ID‑si və çatdırılma ünvanı ilə.
ChatGPT baxımından bu üç fərqli tətbiqdir, istifadəçi üçün isə vahid söhbət. Bunun işləməsinin açarı:
- hər App‑ın alətləri üçün dəqiq descriptions;
- səliqəli adlar (corporate_calendar.list_upcoming_birthdays, sadəcə list_events yox);
- uyğunlaşdırılmış strukturlu məlumat formatı (hədiyyə ideyası commerce‑App‑ın anlaya biləcəyi şəkildə təsvir olunmalıdır).
Vizual sxem
Bu pipeline‑ı belə təsvir etmək olar:
sequenceDiagram
participant U as Istifadəçi
participant C as ChatGPT (Router)
participant Cal as CalendarApp
participant G as GiftGenius
participant Com as CommerceApp
U->>C: Rəhbərin sabah ad günüdür, hədiyyə seç və alışı rəsmiləşdir
C->>Cal: tools.call(list_upcoming_birthdays)
Cal-->>C: [{ name, date, relation }]
C->>G: tools.call(suggest_gifts, { recipient, occasion, budget })
G-->>C: gift suggestions (+ widget)
C-->>U: İzahlar + GiftGenius vidceti
U->>C: #2 variant xoşuma gəldi, onu al
C->>Com: tools.call(create_gift_order, { skuId, address })
Com-->>C: Order confirmation
C-->>U: Hazırdır, sifariş rəsmiləşdirildi
GiftGenius inkişafçısı kimi sizin vəzifəniz — bu xorun içində səsinizin dəqiq və yerində səslənməsi, başqalarına qarışmamasıdır.
8. İnteroperabellik: cavabları digər Apps üçün yararlı etmək
Multi‑App dünyasında təkcə “istifadəçiyə gözəl cavab vermək” kifayət deyil. Yaxşı olardı ki, sizin toolOutput digər tətbiq tərəfindən maşınla işlənə bilsin: commerce‑App, analitik agent, workflow orkestratoru və s.
Bu bir neçə praktik şeyi ifadə edir:
- alət cavablarında serializə olunmuş “insani” mətn əvəzinə strukturlu JSON istifadə etmək;
- sabit, aydın sahələrə sadiq qalmaq.
Məsələn, suggest_gifts nəticəsini belə tipləşdirmək olar:
export type GiftSuggestion = {
id: string;
title: string;
description: string;
price: number;
currency: string;
forPerson: string;
occasion: string;
purchaseUrl: string;
};
Və alət cavabında belə obyektlərdən ibarət massiv qaytarmaq:
{
"gifts": [
{
"id": "sku_123",
"title": "Masaüstü planetarium",
"description": "Ulduzlu səmanı göstərən mini proyektor...",
"price": 89.99,
"currency": "USD",
"forPerson": "Aleksey",
"occasion": "birthday",
"purchaseUrl": "https://shop.example.com/sku_123"
}
]
}
GiftGenius vidceti bunu props kimi götürüb kartları gözəl render edəcək, commerce‑App isə bu JSON‑u kontekstdə görüb id və purchaseUrl sahələrini növbəti checkout üçün “tutub” istifadə edə biləcək.
Multi‑App ssenariləri təcrübəsi göstərir: yaxşı App məlumatları elə qaytarır ki, onu təkcə insan gözü deyil, başqa App da “yesin”.
9. Multi‑App üçün GiftGenius‑un praktiki refaktorinqi
Gəlin hər şeyi tədris tətbiqimizdə bir neçə konkret dəyişikliyə endirək.
Manifest‑description dəqiqləşdirilir
Tutaq ki, bizdə openai-app.json (və ya Next.js şablonunda ekvivalenti) təsviri var:
{
"name": "GiftGenius",
"description": "Gift assistant for finding and buying presents."
}
Routing üçün onu daha aydın edək:
{
"name": "GiftGenius",
"description": "Assistant for gift ideas and purchase flows. Use this app when the user asks what to gift a specific person or for a specific occasion within a budget. Do not use for generic online shopping or personal finance planning."
}
İndi bu mətndən artıq görünür ki, bu nə ümumi alış‑veriş, nə maliyyə məsləhətçisi, nə də təqvimdir.
Alətlərin descriptions mətnlərini yenidən yazırıq
Hədiyyə axtarışı aləti:
const suggestGiftsTool = {
name: "giftgenius_suggest_gifts",
description: `
Use this when the user asks for gift ideas for a specific person or group,
optionally with a budget or occasion.
Do not use for non-gift product recommendations or travel booking.
`
};
Kataloqunuzdan SKU detalları gətirən alət (read‑only):
const getGiftDetailsTool = {
name: "giftgenius_get_gift_details",
description: `
Use this to fetch more details for a gift suggested earlier by GiftGenius,
for example when the user asks “tell me more about option #2”.
`,
annotations: { readOnlyHint: true }
};
Alış aləti — destructiveHint ilə, artıq göstərdiyimiz kimi.
_meta["openai/widgetDescription"] yenilənir
Tutaq ki, vidcetimizdə artıq “Al” CTA‑lı kartlar var. Bunu modelə bildirək:
const giftWidgetMeta = {
_meta: {
"openai/widgetDescription": `
Hədiyyə kartları siyahısını təsvir, qiymət və 'Al' düyməsi ilə göstərir.
Model mətn cavabında tam siyahını təkrarlamamalı, seçimə rəy bildirməli və qərar verməyə kömək etməlidir.
`
}
};
İndi model vidcetdə onsuz da görünən on hədiyyənin siyahısını söhbətdə təkrar‑təkrar yazma ehtimalını azaldacaq və izah və məntiqə fokuslanacaq — bu da həm UX, həm də token dəyəri üçün faydalıdır.
10. Gələcək məhsulunuz üçün Multi‑App düşüncəsi
Başınızı “bütün rəqibləri necə məğlub edim və istifadəçinin yeganə App‑ı olum” rejimindən “öz App‑ımı böyük ekosistemdə ideal modul necə edim” rejiminə keçirmək vacibdir.
Belə yanaşma bir neçə praktiki fayda verir:
- istifadəçiyə və Store rəyçilərinə nəyə görə App‑ınızın lazım olduğunu və nə vaxt yerində olduğunu izah etmək asanlaşır;
- model üçün routing qərarı sadələşir: daha az qarışıqlıq, daha az “yanlış” çağırış;
- kompozisiyaları şüurlu şəkildə layihələndirə bilirsiniz: bu gün — təqvim və commerce ilə, sabah — korporativ HR botu və ya daxili CRM ilə.
Discovery üzrə rəsmi qaydalar vurğulayır: “one job per tool” layihələndirin və meta‑məlumatlara dəyişməyən mətn kimi yox, test və yenilənməsi gərəkən canlı artefakt kimi yanaşın.
Burada Modul 20‑də artıq etdikləriniz çox kömək edəcək: golden‑case‑lər, LLM‑evals, CI‑run. “Söhbətdə həm GiftGenius, həm CalendarApp var” ssenariləri ilə case dəstini genişləndirə və təsvirlərdəki dəyişikliklərin App seçiminə və cavab keyfiyyətinə necə təsir etdiyini izləyə bilərsiniz.
11. Multi‑App və kompozisiya ilə işləyərkən tipik səhvlər
Səhv №1: App təsviri “mən hər şeyi bacarıram”.
Əgər manifest‑description daxilində “istənilən tapşırıq üçün ağıllı köməkçi” kimi yazırsınızsa, siz təkcə digər App‑larla deyil, həm də əsas ChatGPT ilə rəqabət aparırsınız. Router üçün nə vaxt mütləq sizi çağırmalı olduğunu, nə vaxt isə daxili imkanların bəs edəcəyini anlamaq çətinləşir. Multi‑App dünyasında dəqiq, dar təyinatlı tətbiqlər qalib gəlir: “hədiyyə seçimi”, “təqvim idarəetməsi”, “log analizi”.
Səhv №2: alətlərin qeyri‑dəqiq descriptions mətnləri və ad koliziyaları.
get_data, process_request kimi adlar və “istifadəçi məlumatlarını emal edir” izahı modeli çaşdırmaq üçün idealdır. Bir neçə App dünyasında alətiniz tam başqa domenlə bağlı yerdə çağırıla bilər. Düzgün yol — domen və əməliyyatı bağlamaqdır (giftgenius_get_gift_catalog, calendar.list_birthdays) və açıq şəkildə “Use this when… / Do not use when…” yazmaq.
Səhv №3: _meta["openai/widgetDescription"] sahəsini görməməzlikdən gəlmək.
İnkişafçılar çox vaxt yalnız description doldurur, _meta isə ən yaxşı halda lokal üçün yadlarına düşür. Nəticədə model vidcetin nə göstərdiyini anlamır və ya UI‑ni mətndə təkrarlayır, ya da əksinə, istifadəçiyə vidcetinizdə olmayan “qiymətlərlə cədvəl” vəd edir. widgetDescription daxilində cəmi bir neçə sətir belə anlaşılmazlıqların çoxunun qarşısını alır.
Səhv №4: annotasiyaların olmaması readOnlyHint/destructiveHint.
Bütün alətləriniz “neytral” görünürsə, model hansılarının tez‑tez və təhlükəsiz çağırıla biləcəyini, hansılarının isə istifadəçi təsdiqi tələb etdiyini ayırd etmir. Bir neçə App ilə çoxaddımlı ssenarilərdə bu xüsusilə kritikdir: təsadüfən istifadəçinin açıq iştirakı olmadan ardıcıl bir neçə write əməliyyatı baş verə bilər. Read‑only alətləri qeyd etməyi və consequential/destructive hərəkətləri açıq vurğulamağı unutmayın.
Səhv №5: yalnız insan üçün hesablanmış, digər App‑lar üçün yox, cavablar.
Alətdən bir cümləlik “hədiyyələr siyahısı” qaytarmaq cazibədardır, amma bu halda başqa App‑ın bu nəticədən istifadə etməsi çətinləşir. Aydın sahələri olan strukturlu JSON (id, price, currency, purchaseUrl, occasion) sizə həm UI‑da, həm də kompozisiyada üstünlük verir: model bu məlumatları digər tools arqumentlərinə təbii dili parse etmədən yerləşdirə bilər.
Səhv №6: bir App daxilində istifadəçiyə potensial lazım ola biləcək hər şeyi reallaşdırmağa cəhd.
Bəzən adamın canı istəyir: “artıq GiftGenius hazırlamışamsa, qoy təqvimi də aparsın, həmkarlar üçün məktublar da yollasın, büdcəni də planlaşdırsın”. İzolyasiya olunmuş dünyada bu hələ dözüləndir, amma Multi‑App kontekstində digər dar, yaxşı itilənmiş App‑larla konflikt yaradan “kombayn”a çevrilirsiniz. Özünüzlə razılaşmaq daha doğrudur: mənim App‑ım X edir və bunu əla edir; qalanı başqasının məsuliyyətidir. Belə dizayn həm UX‑i, həm də ekosistemin inkişafını xeyli sadələşdirir.
Səhv №7: digər App‑ların olduğu mühitdə davranışı test etməmək.
İnkişafçılar tez‑tez tətbiqlərini Dev Mode‑da “təmiz” söhbətdə, yəni başqa App yoxkən test edirlər. Amma Store‑da istifadəçinin asanlıqla onlarla qoşulmuş tətbiqi ola bilər və onların bir hissəsi konseptual olaraq sizinki ilə kəsişir. Tənbəllik etməyin, qonşu App‑ların (təqvim, ümumi alış‑veriş, maliyyə) olduğu test ssenarisi yaradın və golden‑case‑ləri işə salın: model hədiyyə sorğularında GiftGenius‑u düzgün seçirmi və onu digər iştirakçılarla səhv salmırmı?
GO TO FULL VERSION