# Hur förhindrar du att långa kodsessioner tappar kontext? > Förhindra kontextförlust genom att flytta beständig kunskap från chatten till en kompakt uppgiftsjournal, beslutslogg, testhistorik och versionskontrollerade checkpoints. Ladda dessa artefakter före komprimering eller modellbyte. Långa sessioner misslyckas oftare genom gradvis drift än genom plötslig minnesförlust. Agenten minns huvudmålet men tappar en liten begränsning, litar på ett gammalt testresultat, upprepar en undersökning eller redigerar efter en plan som inte längre stämmer med repot. Lösningen är ett beständigt externt tillstånd som är kortare och mer tillförlitligt än transkriptet. Behandla konversationen som arbetsminne och repot som sanningskälla. Vid varje meningsfull checkpoint ska det stå vad som ändrades, vad som verifierats, vad som är osäkert och vad som ska göras härnäst. ## Spåra fyra slags kontext Separera fakta efter funktion så att sammanfattningen inte blir en enda berättelse. | Kontexttyp | Exempel | Beständig plats | |---|---|---| | Mål | Användarens resultat och acceptanskriterier | Uppgiftsjournal | | Begränsningar | Kompatibilitet, säkerhet, stil, omfattning | Uppgiftsjournal | | Repotillstånd | Ändrade filer och aktuell gren | Versionskontroll | | Bevis | Tester, loggar, skärmbilder, benchmarks | Verifieringsjournal | Lägg endast till antaganden som en femte kategori när de är tydligt märkta. Ange den billigaste åtgärden som kan bekräfta eller förkasta varje antagande. ## Underhåll en kompakt uppgiftsjournal En bra journal ryms på en skärm. Uppdatera den efter milstolpar, inte efter varje meddelande. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Behåll exakta sökvägar, kommandon och felbenämningar. Undvik en dagbok över hur diskussionen utvecklades. ## Skapa checkpoints runt verifierat tillstånd En checkpoint bör följa ett resultat som nästa session kan återskapa. Bra gränser är en godkänd testgrupp, en liten ändring, ett bekräftat API-svar eller ett designbeslut med fixture. Registrera smutsiga filer före modellbyte eller kontextkomprimering. Påstå inte att något fungerar bara för att kod har skrivits; koppla påståendet till ett test, bygge eller synligt artefakt. | Påstående | Nödvändigt bevis | |---|---| | Parsern stöder två anrop | Fixture med två korrelerade anrops-ID | | Återförsök är säkert | Idempotenstest vid avbrott | | Refaktorering bevarar beteende | Gamla och nya tester passerar | | Gränssnittet är korrekt | Renderad kontroll i målstorlekar | ## Hämta källan i stället för att spela upp chatten Öppna den aktuella filen, schemat eller officiella dokumentet när en detalj spelar roll. Äldre transkript kan beskriva kod som redan har ändrats. Ge agenten sökvägar och sökord så att den kan inspektera det senaste tillståndet. Hämtningen bör vara smal: läs gränssnittet, implementationen, det fallerande testet och relevant logg före hela repot. Det lämnar utrymme för resonemang. ## Komprimera med beslut och bevis bevarade En bra komprimering tar bort upprepning men behåller begränsningar, irreversibla beslut, avvisade alternativ och verifiering. Skilj mellan `verified`, `observed`, `assumed` och `pending`. Sammanfatta inte ett misslyckat experiment som slutlig design. Bevara varför ett lockande alternativ avvisades så att det inte återkommer. ## Begränsa verktygsutdata före kontexten Långa loggar och genererade filer förbrukar snabbt uppmärksamhet. Be verktyg om relevanta intervall, antal eller matchande rader. Spara hela resultatet som artefakt och returnera ett kort utdrag med sökväg. För testfel räcker den första användbara stackspårningen, den fallerande assertionen och miljöinformationen. Skicka inte hundratals upprepade ramar tillbaka till modellen. ## Återuppta med en deterministisk rutin Efter paus, komprimering eller modellbyte: * Läs mål och begränsningar. * Inspektera versionskontrollstatus och senaste ändringar. * Öppna filerna i avsnittet om aktuellt tillstånd. * Kör om den senaste relevanta kontrollen. * Bekräfta att nästa åtgärd fortfarande gäller. Rutinen fångar inaktuella sammanfattningar innan de orsakar nya redigeringar. ## Välj modeller utan att förlita dig på transkriptminne En gateway gör modellbyte enklare, men tillståndet är fortfarande ditt ansvar. Atlas Cloud erbjuder flera protokoll från samma bas-URL; kontrollera [protokollmatrisen](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) och den aktuella [modellkatalogen](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) innan en levande agent flyttas. Ge ersättningsmodellen uppgiftsjournalen, relevanta filer och ett färskt verifieringsresultat. Förlita dig inte på leverantörsspecifika tillståndshandtag om samma protokoll och beteende inte har bekräftats. ## Slutsatsen Långa kodsessioner behåller kontext när beständigt tillstånd är kort, bevisbaserat och enkelt att ladda om. Använd en journal på en skärm, skapa checkpoints kring verifierade ändringar, hämta aktuella källor, begränsa verktygsutdata och följ en fast återupptagningsrutin. Ett större kontextfönster hjälper, men disciplinerat externt tillstånd gör arbetet återställbart. ## FAQ ### Räcker ett större kontextfönster för en lång kodsession? Nej. Mer utrymme skjuter upp trycket men garanterar inte att gamla begränsningar förblir framträdande eller att inaktuella observationer korrigeras. ### Vad ska finnas i en uppgiftsjournal för kodning? Registrera mål, begränsningar, aktuell plan, ändrade filer, viktiga beslut, verifieringsresultat, olösta risker och exakt nästa åtgärd. ### Hur ofta bör agenten skapa en checkpoint? Efter en meningsfull tillståndsändring, till exempel ett godkänt test, ett avslutat migreringssteg, ett designbeslut eller en upptäckt som ändrar planen. ### Bör hela transkriptet klistras in i en ny modell? Vanligen inte. Ge modellen en kuraterad checkpoint, relevanta källfiler och loggar och låt den inspektera det aktuella repotillståndet. ### Hur hindrar jag en sammanfattning från att bevara ett gammalt misstag? Skilj verifierade fakta från antaganden, bifoga bevis som kommandon eller filplatser och dra tillbaka påståenden när nya tester motsäger dem. ### Vilket är det säkraste sättet att fortsätta efter ett avbrott? Läs uppgiftsjournalen, inspektera versionskontrollstatus, kör om den senaste relevanta kontrollen och börja vid den registrerade nästa åtgärden.