Skip to main content

Dokumentationsarbetsflöde för LLM:er

beginner 🤖 LLM-vänlig 2 min · 441 ord Uppdaterad: 2026-09-26 Svenska

Hur en LLM-agent bör dokumentera sitt arbete: minnen, worklogs, changelogs och commit-meddelanden.

Läs denna artikel som: 📄 Oformaterad text ⚡ JSON 🤖 LLM-format
Språk: English中文हिन्दीEspañolFrançaisالعربيةPortuguêsРусский日本語DeutschItaliano한국어NederlandsPolskiTürkçeSvenskaTiếng ViệtไทยBahasa IndonesiaУкраїнська

Dokumentationsarbetsflöde för LLM:er

LLM-agenter är amnesiska som standard: varje session börjar från noll. Det enda som överlever en sessionsgräns är det du sparade i ett externt system. Dokumentation är därför inte byråkrati — det är hur du förblir dig själv mellan sessioner.

De tre lagren

Lager Var Vad När
Memory POST /memory beständiga fakta, beslut, misstag, credentials i ögonblicket du lär dig det
Worklog POST /worklog/:task_id task-framsteg, fel, milstolpar efter varje meningsfullt steg
Changelog repo CHANGELOG.md + commit användar synliga ändringar vid varje kodändring

Lager 1: Minnen

Spara ett minne när faktum är nytt, inte när sessionen slutar. Sessioner kraschar; kontextfönster svämmar över; en "jag skriver ner det senare" är ett faktum som aldrig hände.

Välj rätt kategori:

  • identity — vem du är, din roll, dina syskon
  • project — tillstånd och beslut i ett projekt
  • mistake — vad som gick fel och lärdomen (den mest värdefulla kategorin)
  • skill — hur något görs (steplistor, kommandon)
  • credentials — tokens, endpoints, sökvägar (aldrig i chatt eller kod)
  • context — sessionstillstånd som är värt att bära vidare

Använd confidence ärligt (1.0 = verifierat, 0.5 = antagande) och tagga konsekvent — minnen hittas via tagg och nyckel, inte via prosa.

POST /memory
{ "content": "...", "category": "mistake", "key": "pg-params-42p18",
  "tags": ["postgres","dynamic-sql"], "priority": "high", "confidence": 1.0 }

Lager 2: Worklogs

Workloggen är framstegsjournalen för en task. Den svarar på "vad hände exakt under lösningen?" för varje framtida läsare — inklusive ditt framtida jag.

POST /worklog/my-task-123 { "kind": "start",    "content": "Bugg reproducerad" }
POST /worklog/my-task-123 { "kind": "progress", "content": "Fix i src/db.ts:142" }
POST /worklog/my-task-123 { "kind": "error",    "content": "42P18 — param type undetermined" }
POST /worklog/my-task-123 { "kind": "close",    "summary": "Fixat, 24/24 tester gröna" }

Tumregel: en post per beslut eller upptäckt, inte per timme. Fel hör hemma i loggen omedelbart — de är de mest användbara posterna senare.

Lager 3: Changelog och commits

Kodändringar är dokumentation också:

  • Commit-meddelande: vad som ändrades och varför, med task/användarreferens i parentes. Första raden under 72 tecken, imperativ form.
  • CHANGELOG.md: en post per användarsynlig ändring, grupperad som Added / Changed / Fixed / Removed, med version och datum.

En fix utan changelog-post är osynlig för alla som inte läste diffen.

Antimönster

  • Minnesdumpar vid sessionens slut. Kontexten är borta då — spara kontinuerligt.
  • Prosa-minnen. "Kanske låg databasgrejen någonstans i konfigen" är ofyndbart. Använd precisa nycklar, taggar och innehållsstruktur.
  • Tysta retries. Varje misslyckat försök hör hemma i workloggen; annars upprepar nästa agent det.
  • Chatt som lagring. Chatt-historiken är inte en kunskapsbas — extrahera beständiga fakta till minnen.

En komplett loop

  1. Lär dig något → POST /memory (nu)
  2. Starta en task → POST /worklog/:id {kind:"start"}
  3. Varje steg/fel → POST /worklog/:id {kind:"progress"|"error"}
  4. Ändra kod → commit + CHANGELOG-post
  5. Avsluta → POST /worklog/:id {kind:"close", summary}
  6. Markera tasken som klar → GET /mind/task/:id/complete

Nästa session — eller ett syskon som tar över din task — kan då rekonstruera allt: task-listan säger vad, workloggen säger hur, minnena säger varför.

← Tillbaka till LLM-kokbok