Icke-interaktivt läge

I praktiken blir -p ett steg i ett jobb. Körningen checkar ut koden och anropar sedan Claude med en exakt instruktion. Eftersom processen avslutas när loopen når end_turn går pipelinen naturligt vidare.

Håll prompten avgränsad och tydlig – det finns ingen människa som kan klargöra tvetydigheter under körningen, så instruktionen måste stå på egna ben.

Vanlig text fungerar bra för en människa som läser loggar, men en pipeline behöver vanligtvis agera utifrån resultatet – publicera en kommentar, ange status för en kontroll eller blockera en sammanfogning.

Lägg till --output-format json så att Claude genererar ett strukturerat, maskinläsbart resultat i stället för fri text. Nästa steg kan då deterministiskt tolka fälten med jq eller ett skript.

JSON i sig låter fortfarande modellen välja sin struktur. För tillförlitlig automatisering kombinerar du --output-format json med ett schema så att varje körning returnerar samma fält. Det eliminerar syntaxöverraskningar och låter dig kräva exakt de nycklar som pipelinen använder.

Använd samma principer för strukturerad utdata som i API:t: markera ett fält som obligatoriskt endast om det alltid finns – tvinga aldrig fram ett fält som legitimt kan saknas, eftersom modellen då kommer att fabricera det.

En subtil men viktig punkt inför provet är att när Claude både genererar kod och sedan granskar den i samma session blir granskningen partisk – upphovet behåller sitt eget resonemang och kommer inte att ifrågasätta sig självt.

Kör granskningen i CI i en ny, isolerad session, separat från all genereringskontext. En oberoende instans har mycket större sannolikhet att upptäcka verkliga fel. Detta återspeglar den allmänna regeln: oberoende granskning är bättre än självgranskning i samma session.

En CI-granskare som ropar ”vargen kommer” ignoreras. Målet är precision: lyft fram verkliga blockerande problem och var annars tyst.

Det som gör skillnad är prompten, inte vaga vädjanden. Uttryckliga kriterier slår otydliga önskemål: "flagga en kommentar endast när den motsäger koden" fungerar bättre än "var mer exakt". Några riktade few-shot-exempel (2–4) på sanna respektive falska positiva hjälper dessutom till att kalibrera modellen för dina gränsfall.

En headless-körning utförs utan mänskligt godkännande, så obegränsad åtkomst till verktyg är riskabel. Ge endast körningen det som jobbet behöver.

För en skrivskyddad granskning vill du vanligtvis ha Read, Grep och Glob – inte Write, Edit eller godtycklig Bash. Detta är samma princip om minsta behörighet som du tillämpar på agentens verktygsuppsättningar: begränsa verktygen efter rollen och håll uppsättningen liten för tillförlitligt val.

Även i headless-läge är den agentiska loopen oförändrad: begäran -> kontrollera stop_reason -> om tool_use, kör verktygen och fortsätt -> upprepa tills end_turn. Processen avslutas när modellen når end_turn.

Omslut inte Claude med ett skript som söker efter ord som ”done” eller ”finished” i utdatan för att avgöra om körningen är klar. Avslutningen styrs av stopporsaken. En eventuell iterationsgräns är ett säkerhetsnät, aldrig den primära stoppmekanismen.

CI körs om hela tiden – varje push startar jobbet på nytt. Om granskaren rapporterar samma fem problem varje gång drunknar signalen i brus.

Vid en ny körning skickar du tillbaka de tidigare resultaten och instruerar Claude att endast rapportera nya eller fortfarande olösta problem. Då förblir varje kommentar åtgärdbar och du tar hänsyn till att utvecklarna redan har sett de tidigare resultaten.

Blanda inte ihop icke-interaktiv CLI-körning med Message Batches API. De löser olika problem.

• -p / --print: synkront, blockerande, returnerar direkt – rätt för en pre-merge-kontroll där pipelinen väntar på resultatet.
• Batch API: 50 % billigare, upp till 24 timmars tidsfönster, ingen latens-SLA och inget stöd för flerturnsverktygsanrop – rätt för icke-blockerande granskningar över natten, aldrig för en tidskänslig blockerande kontroll.

En granskning före merge måste blockera, så använd -p; använd Batch endast för offlinejobb som inte är brådskande.

Viktiga slutsatser för icke-interaktivt läge:

• -p / --print är den flagga som krävs för headless-körning i CI – kör loopen till slutet, skriver ut till stdout och avslutas.
• --output-format json (helst tillsammans med ett schema) gör resultaten möjliga att tolka, så att pipelinen kan agera utifrån dem; kräv endast fält som alltid finns.
• Kör granskningen i en isolerad, ny session – en oberoende granskning är bättre än en partisk självgranskning i samma session.
• Öka precisionen med tydliga kriterier och few-shot-exempel för att minimera falska positiva resultat.
• Använd verktyg med minsta nödvändiga behörighet vid obemannade körningar; vid omkörningar ska du endast rapportera nya eller ännu inte åtgärdade problem.
• Avslut styrs av stop reason, aldrig av textanalys; iterationsgränser är endast ett säkerhetsnät.
• Använd -p för blockerande pre-merge-kontroller; reservera Batch API för icke-blockerande jobb som inte är brådskande.