Endelig her! Ralph TUI, Visualisert Ralph Loop

Jeg har tidligere skrevet en tutorial om ralph-loop, og mange venner har gitt tilbakemelding etter å ha kjørt den: Det er digg, Claude Code kan endelig kjøre lenge. Men noen ganger ser det ut til å stå stille, og du blir urolig: "Går den fremover, eller spinner den bare rundt?"

Dette er grunnen til at jeg har jobbet med ralph-tui i det siste.

ralph-tui tvinger ikke binding til Claude Code, den arver og utvikler essensen av ralph loop, og visualiserer oppgaveutførelse og prosess, noe som reduserer terskelen for å la store modeller jobbe lenge. Du kan bruke andre agenter, andre modeller, innenlandske, billige, de du har råd til å kjøre lenge. Med ralph-tui er det for oss vanlige folk som å bytte fra manuell girkasse til automatgir med cruisekontroll.

Hva er det egentlig?

Du kan tenke på ralph-tui som en "AI coding agent sin loop-orkestrator", men den er ikke bare fornøyd med å "kunne kjøre", den er mer opptatt av at "du kan se, kontrollere og gjenopprette".

Dens grunnleggende arbeidsmåte er veldig enkel:

• Du gir den en haug med oppgaver (fra PRD eller andre oppgavesystemer)
• Den velger den med høyest prioritet
• Setter sammen prompt
• Starter agenten for å utføre
• Vurderer om oppgaven er fullført
• Skriver status
• Fortsetter til neste runde

Viktigst: Du kan se alt dette i terminalen, og du kan stoppe og overta når som helst. Den offisielle beskrivelsen er også veldig tydelig: en agent loop orchestrator med interaktiv TUI, og støtter TUI / headless / remote.

Hvorfor sier jeg at den er mer egnet for "langvarig kjøring"?

Det største problemet med å kjøre en loop i et skript er ikke at det ikke kan kjøre, men at du ikke vet hvor langt det har kommet.

Du ser at loggene ruller raskt, og viften spinner fornøyd, men du er usikker:

• Gjentar den den samme feilen?
• Endrer den hele tiden den samme koden frem og tilbake?
• Er den allerede ferdig, men har bare ikke avsluttet?
• Har den hengt seg opp i en test i en evig løkke?

ralph-tui sin løsning er veldig "ingeniørmessig":

• Har et session-konsept, status lagres på disk (.ralph-tui/session.json)
• Kan gjenoppta etter krasj (crash recovery)
• Har en låsemekanisme for å unngå at du åpner flere instanser og roter til katalogen
• Kan også kjøres headless i CI, og til og med remote med en listener på en ekstern server, og koble til med lokal TUI

Kort sagt: Det er mer som at "du styrer en arbeider som kan kode", i stedet for at "du overvåker et skript som oppfører seg merkelig".

Hvordan installere

ralph-tui er et Bun/TypeScript-økosystem, så det er ganske enkelt å installere. Den offisielle siden har også en installasjonsveiledning.

Først, sjekk at du har bun installert:

bun --version Deretter installerer du ralph-tui (jeg gir et typisk eksempel, se den offisielle installasjonsveiledningen for detaljer):

bun add -g ralph-tui Etter installasjonen, sjekk:

ralph-tui --help Hvis du er en Node-bruker og ikke vil bruke bun, kan du også gjøre dette:

npm i -g ralph-tui

Ikke start med store prosjekter, kjør en minimal loop

Jeg anbefaler at du ikke starter med å "rekonstruere hele repoet" første gang du bruker den. Gjør bare én ting: Få den til å kjøre gjennom en liten, akseptabel oppgave.

Initialisering

Åpne en hvilken som helst katalog:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setup Dette vil starte en interaktiv veiviserprosess, som i utgangspunktet betyr å "installere ralph-tui i dette depotet". Den vil:

• Oppdager automatisk hvilke agenter som er installert på maskinen din (f.eks. Claude Code, OpenCode osv.)
• Genererer en konfigurasjonsfil i prosjektet: .ralph-tui/config.toml
• Installerer PRD-generering/oppgavekonverteringsrelaterte ferdigheter (skills) (slik at du slipper å fikse dette manuelt senere)

Jeg anbefaler personlig: Ikke vær lat første gang, kjør setup en gang.

Generer prosjekt PRD

Når setup er kjørt, er neste trinn det mest sentrale i den offisielle opplæringen, og også det mest passende for å skrive en demo for en offentlig konto: create-prd.

ralph-tui create-prd --chat kommandoen vil gå inn i en dialogbasert prosess, den vil stille deg spørsmål om dine behovsmål, grensebetingelser og akseptkriterier som en produktleder. Etter å ha spurt, vil den direkte spy ut to ting i prosjektet (dette er poenget):

• En PRD markdown-fil: ./tasks/prd-feature.md
• En kjørbar oppgavefil: ./prd.json

På dette stadiet har du virkelig gått inn i ralph-tui sin "standard lukkede sløyfe":

Behov (PRD) → Oppgave (prd.json) → Utførelse (run)

Kjør den

Med prd.json er det naturlig å kjøre:

ralph-tui run --prd ./prd.json Du vil se TUI starte opp og begynne å loope: velge oppgave → utføre → vurdere fullførelse → skrive status → avslutte eller neste runde.

Første gang jeg kjører, anbefaler jeg sterkt å legge til en iterasjonsgrense, først sette den i et bur:

ralph-tui run --prd ./prd.json --iterations 5 Etter at du har kjørt den, se endringene, kjør tester, se om PRD og oppgaver er som forventet. Bekreft at denne lenken er åpen, og slipp deretter iterasjonene, og gå deretter til headless/remote, dette er det pålitelige tempoet.

På dette tidspunktet kan du i utgangspunktet bekrefte: Denne loopen kjører virkelig.

Hvordan velge modell/Agent? Ærlighet om å spare penger

Jeg vet at mange er mest opptatt av: "Kan jeg unngå å bruke Claude Code? Kan jeg bruke billigere modeller?"

Svaret er: Ja.

ralph-tui i seg selv støtter deg i å spesifisere agent og modell (det er eksempler i den offisielle run-dokumentasjonen).

For eksempel ved å bruke Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Men ærlig talt, jeg ville ikke brukt Opus til å gjøre ting som "fylle ut tester, fikse lint", det er for dyrt. Min vane er lagdeling:

• Billige modeller: Kjør mye repetitivt arbeid (fyll ut tester, fyll ut kommentarer, fiks formatering, legg til grenser)
• Dyrem odeller: Vises bare på viktige noder (arkitekturjusteringer, vanskelige feil, kjerne logikk)

Hvis du er en vanlig utvikler, er denne tankegangen enda viktigere. Fordi du ikke er et stort selskap med budsjett, må du gjøre kostnadene kontrollerbare for å kunne kjøre lenge.

Vil du ha det enda bedre? Overlat "skriving av PRD" til agenten

ralph-tui har et design jeg liker veldig godt: det støtter skills (i utgangspunktet et sett med agentens eksterne kommandoer).

Den offisielle installasjonsmetoden er å bruke add-skill:

bunx add-skill subsy/ralph-tui --all Eller installer den på en spesifikk agent, for eksempel claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Etter installasjon kan du bruke slash-kommandoen i agent-sesjonen:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Dette er som å installere et plugin i IDE, bortsett fra at dette pluginet er for agenten. Betydningen er å redusere tiden for "manuell flytting av behov", slik at behov → oppgave → utførelse ligner mer på en samlebånd.

Når skal du bruke den? Når skal du ikke bruke den?Jeg liker ikke den fortellingen om at "AI kan fikse alt", det er lett å bli villedet. Verktøy er bare verktøy, de er bare verdifulle i riktige scenarier.

Scenarier der ralph-tui passer

Du har en haug med slike oppgaver:

• Fylle ut tester (spesielt for gamle prosjekter)
• Fikse lint / format
• Små trinnvise refaktoreringer (samle repeterende kode)
• Legge til typer i bulk, fylle ut grenser
• Dele opp krav og skyve dem sakte gjennom oppgavekøen

Disse oppgavene har en ting til felles: Mange oppgaver, høy grad av repetisjon, kan aksepteres, kan itereres frem.

Scenarier der det ikke er lurt å tvinge ralph-tui

Du skal gjøre dette:

• Engangs stor refaktorering, uklare akseptkriterier
• Krav i seg selv er vage, avhengig av din implisitte kunnskap
• Krever mye kommunikasjon/bekreftelse på tvers av team
• Krever at du tar produktbeslutninger

I slike oppgaver vil agent loop bare forsterke kaoset.

Hva er forskjellen mellom den og ralph-loop (ralph-claude-code)?

ralph-claude-code er mer som en "autonom kjøre-plugin for Claude Code": Skriptet starter den, kjører loopen, og utgangsdeteksjon, hastighetsbegrensning og strømbryter er alle dekket for deg. Du vil ha "rask", og den er veldig rask.

ralph-tui er mer som en "ingeniørkonsoll for agent loop": Den er ikke låst til en bestemt modell, og den er heller ikke låst til et bestemt oppgavesystem. Den prøver å løse ingeniørproblemer som "langvarig kjøring, observerbar, kontrollerbar, gjenopprettelig, fjernstyrt".

Så du spør meg hvordan du skal velge?

• Du er en Claude Code-bruker og vil raskt få den til å kjøre → ralph-claude-code
• Du vil koble til forskjellige modeller, spare penger, behandle loopen som en tjeneste → ralph-tui

Til slutt: Ikke la den behandle depotet ditt som et laboratorium

Jeg har noen jernregler for å kjøre agent loop, skriv dem ned og følg dem, så er det mindre sannsynlig at du krasjer:

• Kjør på en branch, ikke lek deg på main.
• Første gang du kjører, må du legge til --iterations, bekreft i små trinn at den ikke blir gal.
• Oppgaven må være akseptabel: Enten kan den kjøre tester, eller den kan kjøre lint, eller den kan sammenligne utdatafiler.
• Du må lære å stoppe: Det er smartere å pause enn å fortsette å brenne penger når du ser at den begynner å gå i sirkler.
• Billige modeller gjør grovarbeidet, dyre modeller gjør det kritiske arbeidet: Kostnadene kommer fra drift, ikke fra bønn.Prosjektadresse: https://github.com/subsy/ralph-tui