` | Lygiagretus mechaninis refaktoringas | v2.1.63+ | Kiekvienas vienetas gauna savo git worktree |
`/goal` labiausiai primena Ralph Loop. Viduje vertinimo modelis (pagal numatytuosius nustatymus Haiku) kiekviename ėjime tikrina, ar tikslas pasiektas. Jei ne, kitai iteracijai pateikiama užuomina, ką tiksliai pataisyti. Jei taip, darbas sustabdomas. Išsamiai apie `/goal` rašiau vadove apie [autonominį Claude Code paleidimą per naktį naudojant /goal](https://ailoot.ai/blog/lt/goal-mode-claude-code-codex/) — jame pateikti paruošti naudoti 14 valandų darbo scenarijai.
`/batch` — reta, bet galinga komanda. Kai reikia atlikti tą patį pakeitimą daugiau nei 100 failų (API migracija, komponentų pakeitimas, pervadinimas), `/batch` kiekvieną failą perduoda atskiram subagentui jo paties git worktree. Pakeitimai nesikerta — kiekvienas agentas dirba izoliuotoje kopijoje. Daugiau apie subagentus skaitykite vadove apie [įdėtinius subagentus](https://ailoot.ai/blog/lt/claude-code-nested-subagents/).
Autorius šį metodą apibūdina paprastai:
Griežti `/loop` ir `/goal` apribojimai:
- Užduotis vykdoma tol, kol Claude Code yra atidarytas. Uždarykite terminalą ir ciklas sustos. Rimtam naktiniam ciklui naudokite nuotolinį serverį arba savo shell wrapper.
- Maksimali pasikartojančios užduoties trukmė yra **7 dienos** (po to ji automatiškai pašalinama kaip apsauga nuo pamirštų ciklų).
- Vienoje sesijoje gali būti iki **50 vienu metu vykdomų užduočių**.
## Kaip per 5 minutes paleisti pirmą autonominį ciklą
Svarbiausios įžvalgos
Greičiausias būdas pradėti — naudoti integruotą `/goal`. Atidarykite Claude Code, įveskite komandą su tikslu ir patikrinama sustabdymo sąlyga, tada užsiimkite savo reikalais. Claude generuoja kodą, paleidžia testus, perskaito klaidas, jas ištaiso ir vėl paleidžia testus, kol jie praeina.
5 žingsniai:
1. ### Atidarykite projektą Claude Code
Terminale pereikite į projekto šakninį katalogą ir paleiskite `claude`. Palaukite, kol Claude perskaitys `CLAUDE.md` ir suindeksuos saugyklą.
2. ### Apibrėžkite tikslą ir sustabdymo sąlygą
Tikslas nusako, ką reikia atlikti. Sustabdymo sąlyga nusako, kaip Claude supras, kad baigė. Geriausia, jei tai komanda, grąžinanti 0 arba 1. Pavyzdys: „Tikslas: turi praeiti visi 23 testai faile `tests/api/*.test.ts`. Sustokite, kai `pnpm test` grąžins exit 0.“
3. ### Paleiskite /goal
Komanda:
```
/goal Turi praeiti visi testai faile tests/api/*.test.ts. Paleiskite pnpm test, perskaitykite klaidas, jas ištaisykite ir paleiskite dar kartą. Sustokite, kai išėjimo kodas = 0. Daugiausia 20 iteracijų.
```
Claude pradeda ciklą: paleidžia testus — pamato nesėkmę — atidaro failą — pataiso — paleidžia juos dar kartą.
4. ### Nustatykite biudžeto ribą
Fone atidarytame skirtuke naudokite `/usage` ir stebėkite sąnaudas. Nustatykite dienos tokenų arba pinigų limitą, kad per vieną ciklą neišeikvotumėte viso savo likučio. Daugiau informacijos rasite vadove apie [tai, kaip neišeikvoti Claude Code limitų](https://ailoot.ai/blog/lt/claude-code-token-limits-saving/).
5. ### Užsiimkite savo reikalais
Grįžkite po 30 minučių. Jei užduotis paprasta, jau matysite „DONE, visi testai praėjo“. Jei ji sudėtingesnė, perskaitykite ataskaitą: „sustabdyta per 20 iteraciją, priežastis X“. Rankomis pataisykite tai, ko ciklui nepavyko atlikti, ir paleiskite jį iš naujo.
## Tikrintuvo šablonas: kaip Claude ciklu tikrina savo darbą
Svarbiausios įžvalgos
Claude visada turi turėti galimybę patikrinti savo darbą. Be patikros cikle veikiantis agentas pradeda haliucinuoti — nusprendžia, kad užduotis atlikta, nors iš tikrųjų viskas sugadinta. Tikrintuvas yra komanda (testai, lint, vertinimo modelis, pasirinktinė patikra), grąžinanti nedviprasmišką atsakymą „atlikta / neatlikta“.
Yra trys tikrintuvų tipai:
**1. Techninis (išėjimo kodas)** — patikimiausias. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. Jie grąžina 0 arba 1, todėl nieko nereikia interpretuoti. Taip pat veikia ir `/goal` — viduje naudojamas Haiku vertinimo modelis, kuris kiekviename ėjime tikrina, ar įvykdyta sąlyga (iki 4000 simbolių).
**2. Vertinimo modelis** — antras modelis peržiūri pirmojo modelio rezultatą ir įvertina jį pagal kriterijus. Tinka užduotims, kurių neįmanoma patikrinti formaliai („Ar rašymo stilius geras?“ „Ar dizainas atitinka prekės ženklą?“). Anthropic tai vadina `Claude Code Review` — režimu, kai atskiras peržiūros agentas pagrindinio agento darbe ieško loginių klaidų, ribinių atvejų ir saugumo problemų. Remiantis vidiniais Anthropic duomenimis, jis aptinka **84 % problemų** dideliuose PR (palyginti su 16 % taikant bazinį metodą).
**3. Pasirinktinė patikra** — jūsų pačių parašytas shell script. „Jei žurnaluose nėra žodžio ERROR, užduotis atlikta.“ „Jei failas `output.json` egzistuoja ir jį galima išanalizuoti, užduotis atlikta.“ „Jei puslapis `/pricing` grąžina 200, užduotis atlikta.“
Autoriaus metode įgūdžiai apima atskirą priešišką Claude patikrą po kiekvieno etapo. Štai nurodymo šablonas, kurį įrašau į `CLAUDE.md` arba komandą:
```
Raskite 10 priežasčių, dėl kurių šis projektas galėjo visiškai žlugti.
Įsivaizduokite, kad kažkas nutiko ne taip.
Šią istoriją galiu peržiūrėti daugybę kartų –
prieš paskelbdamas ją viešai.
```
Dažniausia pradedančiųjų klaida — **paleisti ciklą be tikrintuvo**. Agentas sukasi vietoje: rašo kodą, jo netikrina, mano, kad baigė, pereina prie kitos iteracijos ir perrašo tai, ką jau padarė. Po trijų valandų viskas virsta chaosu, o sąskaita siekia $200.
Geriausia taisyklė, kurią išmokau: **pirmiausia parašykite tikrintuvą, o tada paleiskite ciklą**. Jei negalite vienu sakiniu nusakyti sustabdymo sąlygos, užduotis dar neparuošta autonominiam vykdymui.
## Kaip neišleisti tūkstančių dolerių per naktį: biudžeto ribos ir sustabdymo sąlygos
Svarbiausios įžvalgos
Ciklas be biudžeto ribos, išlaidų sustabdymo sąlygos ar tikrintuvo gali nepastebimai sukaupti didelę sąskaitą. To išvengti gali trys apsaugos priemonės: iteracijų limitas, tokenų arba pinigų limitas ir stagnacijos detektorius.
Trys būtini stabdžiai kiekvienam naktiniam ciklui:
**1. Iteracijų limitas.** `--max-iterations 20`. Ciklas negali veikti daugiau nei N kartų — net jei tikrintuvas nesuveikia. Jei po 20 iteracijų nepasiekta sustabdymo sąlyga, užduotis įstrigo ir reikia žmogaus įsikišimo.
**2. Tokenų arba pinigų limitas.** `/usage limit 50` — ne daugiau kaip $50 per dieną. Artėdamas prie ribos ciklas sustoja pats ir išsiunčia įspėjimą. Taip apsisaugoma nuo nekontroliuojamo scenarijaus.
**3. Pažangos patikra su aiškiu susitarimu.** Toliau pateiktas `HEAD` palyginimas aptinka naujus įrašus, o ne visus kodo pakeitimus. Jį naudokite tik izoliuotoje darbo kopijoje, kur kiekviena kodą keičianti iteracija prieš palyginimą išsaugo vietinį kontrolinio taško įrašą. Naudingi neįrašyti pakeitimai nekeičia `HEAD`; be tokio susitarimo nepakitęs maišos kodas gali klaidingai signalizuoti stagnaciją. Taip pat išsaugokite tikrintuvo rezultatą: naujas įrašas įrodo užfiksuotą pakeitimą, bet ne užduoties pagerėjimą ar sėkmę.
Pavyzdinė wrapper struktūra su šiomis trimis patikromis. Išlaidų ataskaitos ir agento iškvietimo eilutės yra konkrečiam vykdytojui skirti pavyzdžiai, o ne patikrintas CLI diegimo receptas; prieš pritaikydami patvirtinkite šias įdiegtos versijos sąsajas. Įrašais pagrįstai pažangos patikrai reikalaukite vietinio kontrolinio taško įrašo po kiekvienos kodą keičiančios iteracijos. Jei vykdytojas palieka neįrašytų pakeitimų, sustokite peržiūrai, užuot vadinę tai pažangos nebuvimu.
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# Pinigų limitas
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: pasiekta biudžeto riba $MAX_COST_USD"
break
fi
# Vykdymas
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Užbaigimo patikra
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: užbaigimo signalas"
break
fi
# Tik įrašų pažanga: kiekviena kodą keičianti iteracija turi išsaugoti įrašą.
# HEAD neaptinka naudingų pakeitimų, kurie dar neįrašyti.
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: stagnacija 3 iteracijas"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
Prieš plėsdami šį karkasą patikrinkite pažangos patikrą: pakeitimą be įrašo reikia laikyti neužfiksuotu darbu; kontrolinio taško įrašas pakeičia `HEAD`; tik atskiras tikrintuvas gali patvirtinti sėkmę. Trys nepakitę įrašai pagal nurodytą susitarimą reiškia, kad neužfiksuota pakeitimų, bet neįrodo, kad visi darbiniai failai liko tokie patys. Vėliau galite pridėti „Slack“ įspėjimą ciklui sustojus, automatinę rytinę ataskaitą per „Telegram“ ir push pranešimą, kai biudžetas pasiekia 80 %. Principas tas pats: ciklui reikia **stabdžių**, ne vien greičio pedalo.
## 5 paruošti naudoti naktinių ciklų scenarijai
Svarbiausios įžvalgos
Ne kiekviena užduotis tinka autonominiam ciklui. Geras pasirinkimas — iteratyviai atliekamos užduotys su nedviprasmišku tikrintuvu: testavimas, refaktoringas, stebėjimas, straipsnių procesai, duomenų importas. Netinka užduotys be formalių patikrų arba su keliais subjektyviais kriterijais.
**1 scenarijus: pataisykite, kad nepraeinantys testai praeitų**
```
/goal Kataloge tests/ yra 47 nepraeinantys testai. Tikslas: priverskite juos visus praeiti.
Paleiskite pnpm test, perskaitykite stderr, atidarykite failą su klaida, ją pataisykite ir vėl paleiskite pnpm test.
Sustokite, kai išėjimo kodas bus 0. Daugiausia 30 iteracijų.
```
**2 scenarijus: didelis 200 failų refaktoringas**
```
/batch Visuose failuose, esančiuose po `src/**/*.ts`, seną apiV1 API klientą pakeiskite nauju apiV2.
Kiekvienam failui priskirkite atskirą worktree. Pakeitę paleiskite tsc --noEmit; ištaisykite visas klaidas.
Pabaigoje sujunkite worktree.
```
**3 scenarijus: naktinis produkcinės aplinkos stebėjimas**
```
/loop 30m Kas 30 minučių patikrinkite https://your-app.example.com/api/health.
Jei atsakymas nėra 200, perskaitykite žurnalus, raskite priežastį, ją ištaisykite ir įdiekite iš naujo.
Kiekvieną iteraciją įrašykite į /tmp/night-monitor.log.
```
**4 scenarijus: didelio duomenų rinkinio importavimas pašalinant dublikatus**
```
/goal Importuokite CSV failą /tmp/import.csv (12,000 eilučių) į lentelę clients.
Kiekvienoje eilutėje pagal el. paštą patikrinkite, ar yra dublikatas; jei nėra, įterpkite, o jei yra, atnaujinkite.
Konfliktus įrašykite į /tmp/conflicts.log. Sustokite apdoroję paskutinę eilutę.
```
**5 scenarijus: straipsnių procesas (tipinė sąranka)**
Internetinei paslaugai ar agentūrai, kuriai reguliariai reikia SEO straipsnių, scenarijus atrodytų taip:
```
/loop 8h Kas 8 valandas atidarykite užduočių sąrašo failą ir raskite temas, kurių būsena yra 'queued'.
Jei tema yra, paleiskite vadovų rašymo įgūdį.
Paskelbkite dev. Pakeiskite būseną į 'review'. Praneškite atsakingam asmeniui per Telegram.
```
## Ką pateikti kiekvienoje iteracijoje: CLAUDE.md ir Second Brain kaip būsena
Svarbiausios įžvalgos
Be atminties Claude kiekvieną iteraciją pradeda nuo pradžių — vėl atidaro projektą, skaito failus ir pamiršta ankstesnės iteracijos sprendimus. Be `CLAUDE.md` jis nežino architektūros; be `business/` (Second Brain) nežino produkto konteksto; be skills neprisimena jūsų taisyklių ir stiliaus. Būseną tarp iteracijų išsaugo šie trys failų sluoksniai. Be jų ciklas pradeda prastėti jau per 5 iteraciją.
Trys projekto „atminties“ sluoksniai vienkartinį nurodymą paverčia valdomu ciklu:
**1. CLAUDE.md** — projekto konstitucija. Kas yra produktas, koks jo technologijų rinkinys, kokios taisyklės ir ko niekada negalima daryti. Pradėdamas kiekvieną sesiją ir kiekvieną ciklo iteraciją Claude perskaito šį failą. Be jo Claude kaskart turi „iš naujo atidaryti“ projektą — eikvojamas kontekstas ir didėja haliucinacijų rizika. Paruoštą šabloną ir 6 taisykles rasite vadove [CLAUDE.md](https://ailoot.ai/blog/lt/claude-md-template/).
**2. Second Brain** — verslo žinių aplankas: produktas, auditorija, tikslai, ekonomika, rinkodara. Ne kodas — prasmė. Kai ciklas rašo straipsnį arba ieško atsakymo klientų aptarnavimui, jis perskaito Second Brain ir atsako remdamasis projekto kontekstu, o ne iš tuštumos.
**3. Context engineering** — ką tiksliai pateikiate Claude kiekvienoje iteracijoje. Ne visą Second Brain aplanką, ne visą saugyklą — tik tai, kas aktualu. Padeda Plan Mode: Claude nustato, kurių failų reikia užduočiai, ir perskaito tik juos. Daugiau informacijos rasite vadove [Plan Mode](https://ailoot.ai/blog/lt/claude-code-plan-mode/).
Pagrindinis praktinis principas, kurį teko įsisąmoninti per klaidas:
Be visų trijų sluoksnių ciklas virsta nesibaigiančiu ciklu, kurio sąskaita nuolat auga.
Kas vyksta kiekvienoje sesijoje? Skirtingos užduotys: vienas ciklas taiso klaidas, kitas rašo naujas funkcijas, trečias peržiūri komandos PR, ketvirtas optimizuoja našumą, penktas rengia dokumentaciją. Ne vienas didelis bendrosios paskirties agentas. Dešimtys specializuotų agentų, kiekvienas turintis savo skill, tikslą ir tikrintuvą.
Svarbiausias požiūrio pokytis:
Verslininkui, neturinčiam programuotojų, tai reiškia štai ką. Turite vieną Claude paskyrą už $200 per mėnesį ir įprastą nešiojamąjį kompiuterį. Galite paleisti **5 ciklus lygiagrečiai** — klientų aptarnavimo, straipsnių, metrikų, naujo produkto testavimo ir konkurentų stebėjimo. Kiekvienas veikia atskirame Claude Code skirtuke. Ryte perskaitote santrauką. 2026 m. vasarą tai jau yra įprastas darbo būdas.
## Keturios dažnos autonominių ciklų nesėkmės
Svarbiausios įžvalgos
Dauguma autonominių ciklų nesėkmių atitinka keturis scenarijus: nėra tikrintuvo — agentas pats nusprendžia, kad baigė; nėra biudžeto ribos — ciklas per naktį gali išleisti didelę sumą; nėra būsenos tarp iteracijų — sprendimai prieštarauja vieni kitiems; neaiški sustabdymo sąlyga — ciklas nežino, kada sustoti.
**1 nesėkmė: „Haliucinacijų ciklas“**
Agentas nusprendžia, kad baigė, nors tikrintuvas nesuveikė. Arba tikrintuvo išvis nėra. Po trijų valandų Claude sako: „Viskas atlikta!“ — bet testai nepraeina, puslapis neatsidaro ir niekas neveikia. Jau išleidote $80 beprasmiškoms iteracijoms.
**Sprendimas:** griežtas tikrintuvas (komandos `exit code`), o ne žodinis patvirtinimas.
**2 nesėkmė: „Biudžetas išeikvotas per naktį“**
Be biudžeto ribos ciklas yra granata be žiedo.
**Sprendimas:** `/usage limit` arba išorinis scenarijus, naudojantis `claude usage --json`, kuris sustabdo ciklą pasiekus ribą.
**3 nesėkmė: „Tarp iteracijų ciklas prarado kontekstą“**
1 iteracijoje Claude priėmė architektūrinį sprendimą. Iki 7 iteracijos jis jį pamiršo ir priėmė priešingą sprendimą. Po 15 iteracijų kodas yra betvarkė.
**Sprendimas:** būsenos sluoksnis per `CLAUDE.md` ir Second Brain aplanką. Ciklas **įrašo** kiekvieną architektūrinį sprendimą į failą, kurį perskaito kitoje iteracijoje.
**4 nesėkmė: „Sustabdymo sąlyga neaiški — ciklas veikia amžinai“**
`/goal "Padaryk puslapį gražų"` — ką reiškia „gražų“? Neturėdamas aiškios metrikos, ciklas niekada nesustos. Jis veiks, kol pasieks iteracijų arba biudžeto limitą.
**Sprendimas:** sustabdymo sąlyga visada turi būti **išmatuojama**. Ne „gražus“, o „Lighthouse Performance ≥ 90, Accessibility ≥ 95“. Ne „veikia“, o „testai faile `tests/pricing.test.ts` praeina“.
## Kada loop engineering nereikalingas
Svarbiausios įžvalgos
Loop engineering yra pasikartojančių, patikrinamų užduočių įrankis. Jo nereikia vienkartinėms kūrybinėms užduotims, užduotims be formalaus tikrintuvo ir užduotims, kurioms būtinas subjektyvus vertinimas. Svarbiau žinoti technikos ribas nei ją išmanyti.
Autonominis ciklas netinka:
- **Vienkartinei kūrybinei užduočiai.** Viena svetainė naujam produktui, vienas logotipas, vienas strateginis memorandumas. Ciklas čia būtų perteklinis; paprasčiau parašyti vieną nurodymą ir rezultatą patobulinti rankomis.
- **Užduočiai be tikrintuvo.** Jei negalite sustabdymo sąlygos išreikšti išėjimo kodu arba nedviprasmišku signalu, nepradėkite ciklo, kitaip tai taps nesibaigiančiu laužu.
- **Užduočiai, kuriai reikia subjektyvaus vertinimo.** „Padaryk, kad skambėtų geriau“, „pagerink UX, kad juo būtų maloniau naudotis“ — tam reikia jūsų, o ne ciklo.
- **Naujai, nepažįstamai sričiai.** Jei patys nesuprantate, kaip turi atrodyti „atlikta“, neleiskite Claude veikti ciklu. Pirma išsiaiškinkite, o tada automatizuokite.
Ir pagrindinė taisyklė, kurią išmokau per klaidas:
Pagrindinis klausimas prieš paleidžiant ciklą: **Ar galiu vienu sakiniu apibūdinti, kaip suprasiu, kad Claude baigė?** Jei taip, ciklas gali padėti. Jei ne, pirmiausia apibrėžkite patikrinamą sąlygą ir tik tada pradėkite.
### Šaltiniai
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - oficialus papildinys
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - šaltinio kodas
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - kelių agentų PR peržiūros tyrimo peržiūra, aptikimo rodiklis 84 %
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - oficiali komandos dokumentacija
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - oficiali dokumentacija
Loop engineering yra sluoksnis, papildantis visa tai, ką jau žinote apie Claude Code. Be visų trijų sluoksnių ciklas pradeda prastėti jau per 5 iteraciją. Toliau susipažinkite su Ailoot svetainėje [ailoot.ai](https://ailoot.ai/).
## Klausimai ir atsakymai
### Kodėl nepakitęs HEAD gali klaidingai rodyti, kad ciklas nepadarė pažangos?
HEAD identifikuoja įrašą. Naudingi darbo medžio pakeitimai jo nepakeičia, kol nėra įrašyti. Todėl pavyzdinis detektorius po kiekvienos kodą keičiančios iteracijos reikalauja vietinio kontrolinio taško įrašo; be šio susitarimo sustokite ir peržiūrėkite neįrašytą darbą, užuot vadinę tai stagnacija.
### Ar naujas įrašas įrodo, kad ciklas pagerino rezultatą?
Ne. Jis įrodo tik užfiksuotą pakeitimą. Kartu su kontroliniu tašku laikykite tikrintuvo rezultatą ir sustokite pagal tikrąją priėmimo sąlygą. Prieš naudojant wrapper būtina patikrinti jo konkrečiam vykdytojui skirtas iškvietimo ir išlaidų sąsajas.
## Ailoot · Įmonė ir jos projektų portfelis
Ailoot remiasi sukaupta veiklos patirtimi, plačia klientų baze, stabiliomis paslaugomis ir nuolatine KPI kontrole.
Įmonė ir jos projektų portfelis: milijonai klientų; mėnesio pardavimai siekia milijardus.
Ailoot šią veiklos patirtį pritaiko teikdama API prieigą prie DI funkcijų klientų produktuose, agentuose, programose ir automatizavimo sprendimuose.