Så lägger du till AI-funktioner i din app

För att lägga till AI-funktioner i din app anropar du ett stort språkmodell-API (LLM) från din server: skicka tydliga instruktioner plus relevant data och använd det som kommer tillbaka. De flesta användbara funktioner följer ett av fyra mönster — sammanfatta, chatta, extrahera strukturerad data och klassificera — och varje är ett par dussin rader kod som en AI-byggare kan skriva åt dig. Arbetet som avgör om funktionen är bra ligger runt anropet: att hålla API-nyckeln på servern, kontrollera kostnaden per användare och granska resultatet innan du litar på det.

De fyra mönstren bakom de flesta AI-funktioner

Extrahering och klassificering är ofta de mest värdefulla och de minst synliga. De sparar tyst någon några minuter på varje post, och eftersom resultatet har en fast form kan du kontrollera det automatiskt. Chatt är mest synlig men svårast att få rätt, och har en egen guide: hur du bygger en AI-chattbotapp.

Så passar det in i din app

Varje mönster har samma form:

1. Användaren agerar — klickar på “Sammanfatta”, laddar upp en fil, skickar ett meddelande.
2. Ditt frontend anropar din egen server, inte AI-leverantören.
3. Din server bygger förfrågan: systeminstruktioner, användarens indata och eventuell data modellen behöver från din databas — bara data den här användaren får se.
4. Din server anropar LLM-API:et med en nyckel lagrad i en miljövariabel.
5. Din server kontrollerar svaret — giltig JSON, en känd etikett, en rimlig längd — och sparar eller returnerar det.
6. Frontend visar det, med strömmad text när svaret är längre.

Nyckeln ligger på servern i steg 4 och når aldrig webbläsaren. Om idén om ett API är ny är vad är ett API en kort introduktion, och hur du använder LLM-API:er går djupare på tokens, modeller och nycklar.

Välja leverantör och modell

De stora leverantörerna — OpenAI, Anthropic, Google och andra — erbjuder alla textbaserade API:er med ungefär liknande form. Användbara frågor när du väljer:

• Kvalitet på din uppgift. Testa några verkliga exempel från din app på två eller tre modeller. Skillnaderna syns ofta tydligare på din data än i allmänna benchmarks.
• Storlek mot kostnad. Leverantörer erbjuder större, mer kapabla modeller och mindre, billigare och snabbare. Klassificering och enkel extrahering fungerar ofta bra på en liten modell; lång resonemang eller nyanserad text kan kräva en större.
• Strukturerad utdata. För extrahering och klassificering, föredra en API-funktion som får modellen att returnera JSON som matchar ett schema du anger, i stället för att tolka fri text.
• Datahantering. Läs leverantörens villkor om API-indata lagras eller används för träning, och om det passar den data dina användare lämnar till dig.
• Gränser. Nya konton har ofta lägre hastighetsgränser; kontrollera dem innan en lansering.

Modellnamn och priser ändras ofta, så koden bör läsa modellnamnet från konfiguration i stället för att hårdkoda det på många ställen.

Lägga till en funktion, steg för steg

Ta ett konkret exempel: ett litet CRM där varje kontakt har en lång historik av anteckningar.

1. Lagra nyckeln. Skapa en nyckel i leverantörens instrumentpanel och spara den som en serverhemlighet, till exempel OPENAI_API_KEY eller ANTHROPIC_API_KEY.

2. Be om en smal funktion:

Lägg till en knapp “Sammanfatta” på kontaktsidan. På servern skickar du kontaktens senaste 20 anteckningar till [LEVERANTÖR] med hemligheten [ENV_NAMN], med instruktioner att skriva tre punkter: nuvarande status, öppna frågor och nästa steg. Ta bara med anteckningar den inloggade användaren får se. Visa ett laddningsläge, spara sammanfattningen med en tidsstämpel och visa “Kunde inte sammanfatta just nu” om anropet misslyckas. Skicka aldrig nyckeln till webbläsaren.

3. Lägg till extrahering där den sparar skrivande:

När en användare klistrar in en e-postsignatur i rutan “Snabbtillägg”, anropa [LEVERANTÖR] på servern och returnera JSON med namn, företag, jobbtitel, e-post och telefon, med leverantörens funktion för strukturerad utdata. Validera JSON på servern, fyll i formuläret för ny kontakt med den och låt användaren redigera innan den sparas. Lämna fält tomma i stället för att gissa.

“Låt användaren redigera innan sparning” är den viktiga delen: modellen föreslår, personen bestämmer.

4. Klassificera i bakgrunden:

När ett nytt supportärende kommer in, klassificera det i exakt en av: fakturering, bugg, funktionsönskemål, kontoåtkomst, övrigt. Använd en liten, billig modell. Om svaret inte är någon av etiketterna, spara “övrigt”. Visa etiketten som en redigerbar tagg.

5. Testa med rörig verklig data — långa anteckningar, tomma anteckningar, andra språk, en signatur utan telefonnummer — och titta på tjugo resultat sida vid sida innan du lanserar.

Skriva instruktioner som fungerar

Instruktionerna du skickar med varje förfrågan (ofta kallad systemprompt) är där kvaliteten kommer ifrån.

• Säg vem det är till för och vad som är bra. “Sammanfattningar läses av en säljare på 10 sekunder innan ett samtal” ger modellen ett mål.
• Fixera formatet. Exakt antal punkter, längdgräns, fält, etiketter.
• Säg vad som ska göras när den är osäker. “Om anteckningarna inte nämner något nästa steg, skriv ‘Inget nästa steg registrerat’.” Det minskar uppfunna svar.
• Ge två eller tre exempel på bra indata och utdata för extrahering och klassificering.
• Håll instruktioner åtskilda från användarinnehåll, och märk användarinnehållet tydligt så att modellen kan skilja dem åt.

Förvara prompterna i filer i din kodbas så att de versionshanteras och granskas som all annan kod.

Håll kostnaderna under kontroll

LLM-API:er tar betalt per token — små textbitar — för både det du skickar och det som kommer tillbaka. Kostnaden växer med mängden kontext per förfrågan multiplicerat med hur ofta den körs. Praktiska kontroller:

• Skicka bara det som behövs. De senaste 20 anteckningarna, inte hela historiken. Korta ner eller dela upp långa dokument.
• Använd den minsta modell som klarar jobbet. Testa innan du väljer den största som standard.
• Begränsa utdatalängden med API:ets inställning för maximalt antal tokens.
• Cacha resultat. Spara en sammanfattning och generera bara om den när källan ändras, i stället för vid varje sidvisning.
• Begränsa per användare. En daglig gräns per konto eller plan hindrar att en tung användare, eller ett skript, driver upp räkningen.
• Begränsa hastigheten på slutpunkten som vilken annan dyr rutt som helst.
• Sätt en budget eller ett larm i leverantörens instrumentpanel och kontrollera användningen varje vecka efter lansering.
• Logga tokenanvändning per funktion så att du vet vad som kostar vad.

Om AI-funktioner är centrala för din produkt, räkna in deras löpande kostnad i din prissättning i stället för att bära den själv.

Säkerhet och förtroende

AI-utdata är probabilistisk. Den kan vara fel och ändå låta säker, och den kan styras av texten den läser. Bygg för det:

• Behandla utdata som otillförlitlig indata. Validera strukturen, escapa den innan den renderas som HTML och kör den aldrig som kod eller databasfrågor.
• Ha en människa i loopen för allt med konsekvenser — skicka ett e-postmeddelande, ändra en post, återbetala en betalning. Modellen utkastar; en person bekräftar.
• Skydda mot prompt injection. Ett dokument eller meddelande kan innehålla text som “ignorera dina instruktioner”. Begränsa vad modellen kan se till det den aktuella användaren får se, och ge den inga verktyg som kan utföra känsliga åtgärder utan att din kod först kontrollerar behörigheter.
• Märk AI-innehåll så att användare vet att en sammanfattning eller ett förslag genererats och kan kontrollera det.
• Hantera fel på ett bra sätt. Leverantörer har driftstörningar och hastighetsgränser. Sätt tidsgränser, visa ett tydligt meddelande och låt resten av appen fortsätta fungera.
• Håll koll på vad användare skickar. För öppna textfält, överväg ett modereringssteg och var tydlig i din integritetspolicy med att innehållet behandlas av en tredjeparts AI-leverantör.

Den bredare listan med kontroller finns i säkerhetschecklistan för AI-byggda appar.

Vanliga misstag

• Att börja med en generell chattbot när en enkel knapp “Sammanfatta” eller “Kategorisera” hade hjälpt fler människor.
• Att lägga nyckeln i frontend-koden eller i ett offentligt kodförråd.
• Att skicka hela databasen som kontext, vilket är långsamt, dyrt och riskerar att exponera andra användares data.
• Att lita på fri text där ett schema eller en fast etikettuppsättning hade gjort den kontrollerbar.
• Inga gränser per användare, upptäckta när första fakturan kommer.

Lägga till AI-funktioner med Mythex

På Mythex lägger du till AI i din egen app genom att be om det i chatten, med din egen leverantörsnyckel. Lagra nyckeln som en projekthemlighet — när agenten behöver en visar Mythex ett hemlighetskort i chatten, så du behöver inte klistra in nyckeln i samtalet — och agenten skriver serverrutten, prompterna och gränssnittet. Din apps AI-användning faktureras av din leverantör, separat från de Mythex-krediter du använder för att bygga. Dokumentationen har en startprompt i lägg till AI-funktioner med dina egna API-nycklar.

Frågor