Vad händer när AI-tjänsten ligger nere? Prova appens reservläge utan kod

Appen är större än sitt AI-svar

När en AI-tjänst blir långsam eller otillgänglig är det frestande att visa ”något gick fel” och kalla saken löst. Men användaren har en annan fråga: vad hände med arbetet jag just gjorde? Om personen fyllde i ett formulär, laddade upp ett dokument eller godkände en beställning behöver appen skilja mellan inmatningen, AI-bearbetningen och den slutliga åtgärden.

Reservläge betyder inte att appen måste kunna generera utan AI. Det betyder att den misslyckas på ett kontrollerat sätt. En ansökan kan sparas som utkast. En textsammanfattning kan vänta. En sökfunktion kan erbjuda vanlig filtrering. En riskfylld åtgärd kan stoppas helt med tydlig information.

HTTP-standarden använder statusen 503 för en tjänst som tillfälligt inte kan hantera begäran. Ett svar kan också ange Retry-After. Din användare behöver inte se koden 503, men appen behöver kunna skilja ett tillfälligt avbrott från felaktig inmatning och ett definitivt nej.

Välj en enda viktig användarresa

Börja inte med alla knappar. Välj den resa där ett avbrott skulle kosta mest tid eller skapa störst osäkerhet. Skriv den som en mening: ”Användaren klistrar in mötesanteckningar och ber om ett utkast till protokoll” eller ”Användaren laddar upp en bild och beställer en produktbeskrivning”.

Om du inte kan skilja AI-steget från effekten ska du inte börja avbrottsprovet än. Be byggverktyget rita flödet och markera exakt var extern AI anropas. Annars riskerar du att simulera fel på fel plats.

Prova i en säker miljö med påhittade uppgifter

Stäng inte av en verklig produktionsnyckel och blockera inte riktiga användare. Gör provet i en separat testversion med påhittat innehåll. Be byggverktyget lägga till ett testläge som bara finns i testmiljön och som returnerar samma typ av tillfälliga fel som appens AI-anslutning kan ge.

Arbeta bara i testmiljön. Ändra inte produktionsnycklar eller riktiga data.

Lägg till ett tillfälligt testläge för AI-anropet i följande användarresa:
[beskriv resan i en mening].

När testläget är på ska AI-anropet svara som ett tillfälligt avbrott.
Ingen extern AI-tjänst ska anropas och ingen slutlig åtgärd ska köras.

Visa först vilka filer och flöden som påverkas. Implementera sedan minsta
möjliga testkoppling. Testläget ska vara tydligt avskilt från produktion
och enkelt att ta bort efter provet.

Sju kontroller som användaren kan se

1. Beskedet är sant

Appen får inte säga ”klart”, ”sparat” eller ”skickat” om AI-steget misslyckades. Ett bra besked skiljer mellan bevarad inmatning och uteblivet resultat: ”Ditt utkast finns kvar, men AI-bearbetningen kunde inte slutföras.” Undvik att skylla på användarens internet om orsaken inte är känd.

2. Arbetet finns kvar efter omladdning

Skriv något som är lätt att känna igen, utlös avbrottet och ladda om sidan. Kontrollera exakt vad som återkommer. Om texten bara låg i ett formulärminne får appen inte lova att den är sparad. Antingen ska utkastet lagras på beslutad plats eller ska beskedet tydligt säga att användaren behöver kopiera det innan sidan stängs.

3. Väntan har en gräns

Ett snurrande hjul utan slut är inget reservläge. Mät hur länge det dröjer innan appen byter till ett begripligt fel. Automatiska återförsök ska vara få och avgränsade. Om tjänsten anger en lämplig väntetid kan appen respektera den, men användaren ska fortfarande kunna lämna sidan eller spara sitt arbete.

4. Nästa steg går att utföra

”Försök senare” är bara användbart om det som ska försökas finns kvar. Ge en knapp för att försöka igen, spara som utkast, kopiera inmatningen eller gå vidare utan AI – beroende på vad resan tillåter. En reservväg ska inte vara en död informationsruta.

5. Knappen skapar inte flera beställningar

Tryck två gånger på ”Försök igen” när tjänsten börjar svara. Resultatet ska visas en gång. Om resan skickar mejl, gör bokningar eller ändrar data är kontrollen extra viktig: osäkerheten efter ett avbrott får inte göra varje klick till en ny åtgärd.

6. Appen återhämtar sig utan omloggning

Stäng av testläget och prova igen i samma session. Användaren ska inte behöva rensa webbläsaren eller skapa ett nytt konto för att lämna felläget. Ett gammalt felmeddelande ska inte ligga kvar över ett lyckat resultat.

7. Supporten får ett användbart spår

Felrutan kan visa ett kort händelse-ID som användaren kan lämna till supporten. Loggen bakom ID:t ska ange tid, funktion och tekniskt utfall utan att kopiera promptar, dokument eller hemliga nycklar i onödan.

Skriv ett protokoll med bevis, inte intryck

ANVÄNDARRESA: [vad personen försökte göra]
TESTMILJÖ OCH VERSION: [länk eller versionsnamn]
TESTFEL: [tillfälligt AI-avbrott / timeout / annat]

BESKED SOM VISADES: [ordagrant]
UTKAST EFTER OMLADDNING: [helt / delvis / borta]
MÖJLIGT NÄSTA STEG: [knapp eller väg]
ANTAL FÖRSÖK: [automatiska + manuella]
ANTAL SKAPADE RESULTAT: [ska normalt vara högst ett]
ÅTERHÄMTNING: [vad hände när testfelet stängdes av]
HÄNDELSE-ID: [om det visades]

UTFALL: [godkänt / underkänt]
FÖRSTA BLOCKERANDE HINDER: [ett konkret observerat problem]

Godkänt betyder inte ”det såg okej ut”. Sätt förväntningen före provet. Exempel: utkastet ska finnas kvar efter omladdning, felbeskedet ska visas inom 15 sekunder, användaren ska kunna försöka igen och endast ett protokollutkast ska skapas.

Beställ en rättning i taget

Om fem saker faller, börja med dataförlust eller falskt lyckat besked. Skicka observationen till byggverktyget och avgränsa ändringen. ”Gör felhanteringen bättre” är för brett och leder lätt till nya komponenter utan testbart resultat.

I testmiljön simulerade vi ett tillfälligt avbrott i AI-tjänsten.

Förväntat: [ett mätbart beteende].
Observerat: [vad användaren såg och vad som hände med arbetet].
Risk: [dataförlust / falskt lyckat besked / dubblett / död väg].

Föreslå den minsta ändring som rättar just detta. Behåll övrigt flöde.
Beskriv var utkastet lagras, när ett nytt försök får göras och hur du
förhindrar dubbla slutliga åtgärder. Vänta på godkännande före ändring.
Lägg till ett automatiskt test för det observerade felet.

Välj reservläge efter konsekvens

Reservläget ska inte smyga in ett sämre AI-resultat från en okänd modell eller hoppa över en kontroll bara för att huvudtjänsten är nere. Om den alternativa vägen ändrar kvalitet, kostnad eller databehandling ska användaren och ansvarig verksamhet veta det.

Gör om samma prov från samma startläge

Efter rättningen återställer du samma testdata, samma testfel och samma förväntningar. Prova både ett avbrott före AI-tjänsten har tagit emot begäran och ett avbrott där svaret försvinner efter att tjänsten kan ha arbetat klart. Det senare avslöjar dubbletter.

Spara avbrottsprovet bredvid appens vanliga provlista. Kombinera det med femminuters användartest: reservläget måste både fungera tekniskt och gå att förstå utan att byggaren står bredvid och förklarar.