Lär dig avgränsa uppgifter med Claude Code för att förvandla röriga funktionsförfrågningar till tydliga acceptanskriterier, en minimal UI/API-plan och några små commits.
En vag förfrågan låter ofarlig: “Lägg till en bättre sökning”, “Gör onboarding smidigare”, “Användare behöver notiser.” I verkliga team kommer den ofta som ett enradigt chattmeddelande, en skärmbild med pilar eller ett halvt ihågkommet kundsamtal. Alla håller med, men alla föreställer sig olika saker.
Kostnaden syns senare. När scope är oklart bygger folk på gissningar. Den första demon blir en ny omgång förtydliganden: “Det var inte vad jag menade.” Arbete görs om och förändringen växer i tysthet. Designjusteringar kräver kodändringar, vilket kräver mer testning. Granskningar går långsammare eftersom en otydlig förändring är svår att verifiera. Om ingen kan definiera vad som är “korrekt” slutar granskare med att debattera beteende istället för att kontrollera kvalitet.
Du kan oftast upptäcka en vag uppgift tidigt:
En väl avgränsad uppgift ger teamet en mållinje: tydliga acceptanskriterier, en minimal UI- och API-plan och explicita gränser för vad som inte ingår. Det är skillnaden mellan “förbättra sökningen” och en liten ändring som är enkel att bygga och granska.
En praktisk vana: separera “definition of done” från “trevligt att ha.” “Klart” är en kort lista med kontroller du kan köra (till exempel: “Sök returnerar resultat efter titel, visar ‘Inga resultat’ när tomt och behåller frågan i URL”). “Trevligt att ha” är allt som kan vänta (synonymer, rankingjusteringar, markeringar, analytics). Att märka upp dessa i förväg förhindrar oavsiktlig scope-ökning.
Vaga förfrågningar börjar ofta som föreslagna fixar: “Lägg till en knapp”, “Byt till ett nytt flöde”, “Använd en annan modell.” Pausa och översätt förslaget till ett resultat först.
Ett enkelt format hjälper: “Som en [användare] vill jag [göra något] så att jag kan [nå ett mål].” Håll det enkelt. Om du inte kan säga det i en andningspaus är det fortfarande för otydligt.
Beskriv sedan vad som förändras för användaren när det är klart. Fokusera på synligt beteende, inte implementationsdetaljer. Till exempel: “Efter att jag skickat formuläret ser jag en bekräftelse och kan hitta den nya posten i listan.” Det skapar en tydlig mållinje och gör det svårare för “bara en tweak till” att smyga sig in.
Skriv också ner vad som förblir detsamma. Icke-mål skyddar ditt scope. Om förfrågan är “förbättra onboarding” kan ett icke-mål vara “ingen omskapning av dashboard” eller “inga ändringar i prismodellens logik”.
Välj till sist en primär väg att stödja först: den enkla end-to-end-skivan som bevisar att funktionen fungerar.
Exempel: istället för “lägg till snapshots överallt”, skriv: “Som projektsägare kan jag återställa den senaste snapshoten av min app så att jag kan ångra en dålig ändring.” Icke-mål: “ingen bulk-återställning, ingen UI-omsnyggning.”
En vag förfrågan saknar sällan ansträngning. Den saknar beslut.
Börja med begränsningar som tyst ändrar scope. Deadlines spelar roll, men det gör även åtkomstregler och compliance-krav. Om du bygger på en plattform med nivåer och roller, bestäm tidigt vem som får funktionen och under vilken plan.
Be sedan om ett konkret exempel. En skärmbild, ett beteende från en konkurrent eller en tidigare ticket visar vad “bättre” faktiskt betyder. Om beställaren inte har något, be dem återge sista gången problemet uppstod: vilken skärm var de på, vad klickade de, vad förväntade de sig?
Edge-cases är där scope exploderar, så namnge de viktiga tidigt: tom data, valideringsfel, långsamma eller misslyckade nätverksanrop, och vad “ångra” verkligen innebär.
Bestäm också hur ni kommer verifiera framgång. Utan ett testbart resultat blir uppgiften åsikter.
Dessa fem frågor tar vanligtvis bort det mesta av otydligheten:
Exempel: “Lägg till custom domains för kunder” blir tydligare när du bestämmer vilken nivå det tillhör, vem som kan konfigurera det, om hosting-plats påverkar compliance, vilket felmeddelande som visas vid ogiltig DNS och vad “klart” betyder (domän verifierad, HTTPS aktivt och en säker rollback-plan).
Röriga förfrågningar blandar mål, gissningar och halvihågkomna edge-cases. Jobbet är att göra det till uttalanden som vem som helst kan testa utan att läsa dina tankar. Samma kriterier ska styra design, kodning, granskning och QA.
Ett enkelt mönster håller det tydligt. Du kan använda Given/When/Then eller korta punkter som betyder samma sak.
Skriv varje kriterium som ett enda test någon kan köra:
Applicera nu. Anta att noteringen säger: “Gör snapshots enklare. Jag vill rulla tillbaka om sista ändringen sabbar saker.” Omvandla det till testbara uttalanden:
Om QA kan köra dessa kontroller och granskare kan verifiera dem i UI och loggar, är du redo att planera UI- och API-arbetet och dela upp det i små commits.
En minimal UI-plan är ett löfte: den minsta synliga förändringen som bevisar att funktionen fungerar.
Börja med att namnge vilka skärmar som förändras och vad en person kommer lägga märka till på 10 sekunder. Om förfrågan säger “gör det enklare” eller “städar upp”, översätt det till en konkret förändring du kan peka på.
Skriv det som en liten karta, inte en omsnyggning. Till exempel: “Orders-sidan: lägg till en filterrad ovanför tabellen”, eller “Settings: lägg till en ny toggle under Notiser.” Om du inte kan namnge skärmen och det exakta elementet som ändras är scope fortfarande oklart.
De flesta UI-ändringar behöver några förutsägbara states. Skriv bara upp dem som gäller:
UI-copy är en del av scope. Fånga etiketter och meddelanden som måste godkännas: knapptext, fältetiketter, hjälptrad och felmeddelanden. Om ordalydelsen fortfarande är öppen, markera det som placeholder-copy och notera vem som bekräftar den.
Behåll en kort “inte nu”-anteckning för allt som inte krävs för att använda funktionen (responsiv polish, avancerad sortering, animationer, nya ikoner).
En avgränsad uppgift behöver ett litet, tydligt kontrakt mellan UI, backend och data. Målet är inte att designa hela systemet utan att definiera minsta uppsättning requests och fält som bevisar att funktionen fungerar.
Börja med att lista data du behöver och varifrån den kommer: befintliga fält du kan läsa, nya fält du måste lagra och värden du kan beräkna. Om du inte kan namnge en källa för varje fält har du ingen plan ännu.
Håll API-yta liten. För många funktioner räcker en läsning och en skrivning:
GET /items/{id} returnerar det tillstånd som behövs för att rendera skärmenPOST /items/{id}/update accepterar endast det användaren kan ändra och returnerar det uppdaterade tillståndetSkriv inputs och outputs som enkla objekt, inte långa stycken. Inkludera obligatoriska vs valfria fält, och vad som händer vid vanliga fel (not found, validation failed).
Gör en snabb auth-genomgång innan du rör databasen. Bestäm vem som kan läsa och vem som kan skriva, och skriv regeln i en mening (till exempel: “valfri inloggad användare kan läsa, endast admins kan skriva”). Att hoppa över detta leder ofta till omarbete.
Bestäm vad som måste lagras och vad som kan beräknas. En enkel regel: lagra fakta, beräkna vyer.
Claude Code fungerar bäst när du ger ett tydligt mål och en snäv box. Klistra in den röriga förfrågan och eventuella begränsningar (deadline, berörda användare, dataregler). Be sedan om en avgränsad leverans som inkluderar:
När den svarar, läs den som en granskare. Om du ser fraser som “förbättra prestanda” eller “gör det snyggare”, be om mätbar formulerad text.
Förfrågan: “Lägg till ett sätt att pausa en prenumeration.”
En avgränsad version kan säga: “Användare kan pausa i 1 till 3 månader; nästa faktureringsdatum uppdateras; admin kan se pausstatus,” och out-of-scope: “Inga ändringar i proration.”
Därifrån blir commit-planen praktisk: en commit för DB och API-form, en för UI-kontroller, en för validering och fel-lägen, en för end-to-end-tester.
Stora ändringar döljer buggar. Små commits gör granskningar snabbare, gör rollback säkrare och hjälper dig lägga märke till när du avviker från acceptanskriterierna.
En användbar regel: varje commit ska låsa upp ett nytt beteende och inkludera ett snabbt sätt att bevisa det fungerar.
En vanlig sekvens ser ut så här:
Håll varje commit fokuserad. Undvik “medan jag ändå var här”-refaktoreringar. Håll appen fungerande end-to-end, även om UI är grundläggande. Paketera inte migrationer, beteende och UI i en commit om du inte har stark anledning.
En intressent säger: “Kan vi lägga till Exportera rapporter?” Det döljer många val: vilken rapport, vilket format, vem kan exportera och hur leverans fungerar.
Ställ bara de frågor som ändrar designen:
Anta svaren är: “Sales Summary-rapport, endast CSV, roll manager, direkt nedladdning, max 90 dagar.” Nu blir v1-acceptanskriterierna konkreta: managers kan klicka Export på Sales Summary-sidan; CSV motsvarar kolumnerna i tabellen; exporten respekterar filtren; export över 90 dagar visar ett tydligt fel; nedladdningen slutförs inom 30 sekunder för upp till 50k rader.
Minimal UI-plan: en Export-knapp vid tabellåtgärder, ett laddningsläge medan fil genereras, och ett felmeddelande som berättar hur användaren åtgärdar problemet (som “Välj 90 dagar eller färre”).
Minimal API-plan: en endpoint som tar filtren och returnerar en genererad CSV som filrespons, återanvänd samma fråga som tabellen samtidigt som servern upprätthåller 90-dagars-regeln.
Skicka sedan i några tighta commits: först endpoint för en fast happy path, sedan UI-wiring, sedan validering och användarvänliga fel, och slutligen tester och dokumentation.
Förfrågningar som “lägg till teamroller” döljer ofta regler om inbjudningar, redigering och vad som händer med befintliga användare. Om du fångar dig själv gissa, skriv antagandet och gör det till en fråga eller en explicit regel.
Team förlorar dagar när en uppgift innehåller både “få det att fungera” och “gör det snyggt.” Håll första uppgiften fokuserad på beteende och data. Lägg styling, animationer och mellanrum i en uppföljande uppgift om det inte krävs för att använda funktionen.
Edge-cases är viktiga, men inte alla behöver lösas omedelbart. Hantera de som kan förstöra förtroendet (dubbla submits, konfliktande redigeringar) och skjut upp resten med klara anteckningar.
Om du inte skriver ner dem kommer du missa dem. Inkludera åtminstone en olycklig väg och åtminstone en behörighetsregel i dina acceptanskriterier.
Undvik “snabbt” eller “intuitivt” om du inte bifogar ett nummer eller en konkret kontroll. Byt ut mot något du kan bevisa i granskning.
Spika uppgiften så en kollega kan granska och testa utan tankeläsning:
Exempel: “Lägg till sparade sökningar” blir “Användare kan spara ett filter och återanvända det senare,” med icke-mål som “ingen delning” och “inga sorteringsändringar.”
När du har en avgränsad uppgift, skydda den. Gör en snabb sanity-review med de som bad om förändringen innan kodstart:
Spara sedan kriterierna där arbetet sker: i ticketen, i PR-beskrivningen och var ditt team faktiskt tittar.
Om du bygger i Koder.ai (koder.ai) hjälper det att låsa planen först och sedan generera kod från den. Planning Mode passar bra i det arbetsflödet, och snapshots och rollback kan hålla experiment säkra när du behöver pröva ett angreppssätt och backa ur.
När nya idéer poppar upp mitt i bygget, håll scope stabilt: skriv dem i en uppföljningslista, pausa för att avgränsa om de ändrar acceptanskriterierna, och koppla commits till enskilda kriterier i taget.
Börja med att skriva resultatet i en mening (vad användaren kan göra när det är klart), och lägg sedan till 3–7 acceptanskriterier som en testare kan verifiera.
Om du inte kan beskriva det “korrekta” beteendet utan att debattera, är uppgiften fortfarande vag.
Använd det här snabba formatet:
Lägg sedan till ett konkret exempel på förväntat beteende. Om du inte kan ge ett exempel, replaya sista gången problemet uppstod och skriv vad användaren klickade och förväntade sig att se.
Skriv först en kort "Definition of done"-lista (kontroller som måste passera), och separera sedan en "Nice-to-have"-lista.
Standardregel: om det inte behövs för att bevisa att funktionen fungerar end-to-end, hamnar det under nice-to-have.
Ställ de få frågor som faktiskt ändrar scope:
Detta tvingar fram de saknade besluten.
Behandla edge-cases som scope-punkter, inte överraskningar. För v1, täck de som underminerar förtroende:
Allt annat kan uttryckligen skjutas upp som out-of-scope.
Använd testbara uttalanden som vem som helst kan köra utan gissningar:
Inkludera minst ett fel-fall och en behörighetsregel. Om ett kriterium inte går att testa, skriv om det tills det går.
Nämn de exakta skärmarna och den enskilda synliga förändringen per skärm.
Lista även nödvändiga UI-states:
Håll även copy (knapptext, fel) inom scope, även om det är placeholder-ord.
Håll kontraktet litet: för v1 räcker ofta en läsning och en skrivning.
Definiera:
Spara fakta; beräkna vyer när det är möjligt.
Be om en låda-leverans:
Be sedan att vaga formuleringar som “gör det snyggare” mätas konkret.
Standardsekvens:
Tumregel: en commit = ett nytt användarobserverbart beteende + ett snabbt sätt att bevisa att det fungerar. Undvik att slå ihop “medan jag är här” refaktoreringar.