OpenClaw + Claude Code 超强教程：一个人就能搭建完整的开发团队！
OpenClaw + Claude Code 超强教程：一个 om poate construi o echipă completă de dezvoltare!
Astăzi împărtășesc un caz practic foarte impresionant. (Tutorialul este la sfârșitul articolului)
Un dezvoltator independent a folosit OpenClaw + Codex/CC pentru a construi un sistem AI Agent. Ce rezultate a obținut?
94 de commit-uri într-o zi, 7 PR-uri finalizate în 30 de minute, iar în acea zi a avut și 3 întâlniri cu clienții, fără să deschidă editorul.
Acest lucru s-a întâmplat cu adevărat în ianuarie 2026. Autorul a făcut publică întreaga arhitectură a sistemului, fluxul de lucru și configurația codului. După ce am citit, am realizat că această abordare merită să fie învățată, așa că am organizat-o în acest articol pentru a o împărtăși cu tine.
Dacă folosești Codex sau Claude Code, sau ești interesat de OpenClaw, acest articol îți va oferi multe inspirații.
O persoană, 94 de commit-uri de cod într-o zi
Să vedem câteva date pentru a simți puterea acestui sistem:
- Maximum de 94 de commit-uri într-o zi (în medie 50 de commit-uri pe zi)
- 7 PR-uri finalizate în 30 de minute
- Viteza de la idee la lansare este atât de rapidă încât poate "livra cerințele clienților în aceeași zi"
Costurile? 190 USD pe lună (Claude 100 USD + Codex 90 USD), începătorii pot începe cu 20 USD.
S-ar putea să te întrebi: nu cumva este vorba despre o grămadă de instrumente AI care generează cod de proastă calitate?
Nu este așa. Istoricul Git al autorului arată ca și cum "tocmai a angajat o echipă de dezvoltare", dar de fapt este doar el. Schimbarea cheie este: el a trecut de la "a gestiona Claude Code" la "a gestiona un majordom AI, care la rândul său gestionează o echipă de Claude Code".
- Înainte de ianuarie: scria cod direct cu Codex sau Claude Code
- După ianuarie: folosește OpenClaw ca strat de orchestrare, lăsându-l să coordoneze Codex/Claude Code/Gemini
De ce Codex și Claude Code nu sunt suficiente folosite separat?
În acest moment, s-ar putea să te întrebi: Codex și Claude Code sunt deja foarte puternice, de ce să adaugi un strat de orchestrare?
Răspunsul autorului este foarte direct: Codex și Claude Code nu știu aproape nimic despre afacerea ta. Ele văd doar codul, nu întreaga imagine a afacerii.
Există o limitare fundamentală aici: fereastra de context este fixă, poți alege doar una dintre două opțiuni.
Trebuie să alegi ce să pui înăuntru:
- Umple codul → nu mai este loc pentru contextul afacerii
- Umple istoricul clienților → nu mai este loc pentru biblioteca de cod
- Nu știe pentru ce client este această funcționalitate
- Nu știe de ce cerința similară a eșuat ultima dată
- Nu știe care este poziționarea și principiile de design ale produsului tău
- Poate lucra doar pe baza codului curent și a prompt-ului tău
Acesta acționează ca un strat de orchestrare, situat între tine și toate instrumentele AI. Rolul său este:
- A deține toate contextul afacerii (datele clienților, notele întâlnirilor, deciziile anterioare, cazurile de succes/eșec)
- A traduce contextul afacerii în prompt-uri precise, pe care le oferă agentului specific
- A permite acestor agenți să se concentreze pe ceea ce știu să facă cel mai bine: să scrie cod
- Codex/Claude Code = bucătari profesioniști, care se ocupă doar de gătit
- OpenClaw = bucătar-șef, care știe gusturile clienților, stocul de ingrediente, poziționarea meniului, dând instrucțiuni precise fiecărui bucătar
Arhitectura specifică a sistemului cu două straturi: strat de orchestrare + strat de execuție
Să aruncăm o privire asupra arhitecturii specifice a acestui sistem.
Două niveluri, fiecare cu rolul său:
Ce poate face OpenClaw (nivelul de orchestrare)?
- Citește toate înregistrările întâlnirilor din notele Obsidian (sincronizare automată)
- Accesează baza de date de producție (permisiuni doar pentru citire) pentru a obține configurația clientului
- Are permisiuni API de administrator, poate reîncărca direct clientul și elimina blocajele
- Alege agentul potrivit în funcție de tipul de sarcină
- Monitorizează progresul tuturor agenților, analizează motivele eșecului și ajustează promptul pentru a relua
- Notifică autorul prin Telegram după finalizare
Ce poate face Agentul (nivelul de execuție)?
- Citește și scrie în biblioteca de cod
- Rulează teste și construiește
- Trimite cod și creează PR
- Răspunde la feedback-ul revizuirii codului
Acest design este inteligent: limitele de securitate sunt clare, asigurând în același timp eficiența.
Flux de lucru complet: 8 pași de la cerințele clientului la fuzionarea PR-ului
Acum intrăm în partea esențială. Folosind un caz real al autorului din săptămâna trecută, te voi ghida prin întregul proces.
Context: Un client de afaceri a sunat, spunând că dorește să reutilizeze setările pe care le-au configurat deja, pentru a le partaja în echipă.
Pasul 1: Cerințele clientului → OpenClaw înțelege și descompune
După încheierea apelului, autorul a discutat cu Zoe (OpenClaw-ul său) despre această cerință.
Aici este partea magică: cost zero de explicație. Deoarece toate înregistrările întâlnirilor sunt sincronizate automat în Obsidian, Zoe a citit deja conținutul apelului, știe cine este clientul, care este scenariul lor de afaceri și configurația existentă.
Autorul și Zoe au descompus cerința în: a crea un sistem de șabloane care să permită utilizatorului să salveze și să editeze configurația existentă.
Apoi, Zoe a făcut trei lucruri:
- A reîncărcat clientul — a eliminat imediat restricțiile de utilizare ale clientului folosind API-ul de administrator
- A obținut configurația clientului — a extras setările existente ale clientului din baza de date de producție (doar pentru citire)
- A generat promptul și a lansat agentul — a împachetat tot contextul și l-a oferit lui Codex
Pasul 2: Lansarea agentului
Zoe a creat pentru această sarcină:
- Un git worktree independent (mediu de ramificare izolat)
- O sesiune tmux (pentru a permite Agentului să ruleze în fundal)
# 创建 worktree + 启动代理 git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install
tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high De ce folosim tmux? Pentru că permite intervenția în mijlocul procesului.
Dacă AI-ul deviază, nu trebuie să omori și să începi din nou, poți da comenzi direct în tmux:
# 代理方向错了 tmux send-keys -t codex-templates "Oprește-te. Fă mai întâi nivelul API, nu te preocupa de UI." Enter
代理需要更多上下文
tmux send-keys -t codex-templates "Definiția tipului este în src/types/template.ts, folosește-l." Enter În același timp, sarcina va fi înregistrată într-un fișier JSON:{ "id": "feat-custom-templates", "tmuxSession": "codex-templates", "agent": "codex", "description": "Funcția de șabloane de e-mail personalizate pentru clienți de afaceri", "repo": "medialyst", "worktree": "feat-custom-templates", "branch": "feat/custom-templates", "startedAt": 1740268800000, "status": "running", "notifyOnComplete": true }
Pasul 3: Monitorizare automată
O sarcină cron verifică starea tuturor agenților la fiecare 10 minute.
Punct cheie: nu este vorba de a "întreba" Agentul cum decurge progresul (asta ar consuma multe token-uri), ci de a verifica faptele obiective:
- sesiunea tmux mai este activă?
- A fost creat un PR?
- Care este starea CI?
- Dacă a eșuat, trebuie să fie repornit? (maxim 3 încercări)
Acest script de monitorizare este 100% determinist, foarte economic în token-uri, notificând autorul doar atunci când este necesară intervenția umană.
Aceasta este, de fapt, o versiune îmbunătățită a Ralph Loop, despre care vom vorbi în detaliu mai târziu.
Pasul 4: Agentul creează PR
Agentul finalizează codul, face un commit, îl împinge, apoi folosește gh pr create --fill pentru a crea PR.
Notă: în acest moment, autorul nu va primi o notificare. Deoarece un PR în sine nu reprezintă "finalizat".
Definiția "finalizat" este:
- ✅ PR a fost creat
- ✅ ramura a fost sincronizată cu main (fără conflicte)
- ✅ CI a trecut (lint, verificare de tip, teste unitare, teste E2E)
- ✅ Revizor Codex a aprobat
- ✅ Revizor Claude a aprobat
- ✅ Revizor Gemini a aprobat
- ✅ Dacă există modificări UI, trebuie să includă capturi de ecran
Numai dacă toate aceste condiții sunt îndeplinite, se consideră că este cu adevărat finalizat.
Pasul 5: Revizuirea automată a codului
Fiecare PR va fi revizuit de trei agenți:
- Revizor Codex — cel mai de încredere revizor - expert în identificarea cazurilor limită
- Poate detecta erori logice, gestionarea erorilor lipsă, condiții de competiție
- Rata falselor pozitive este foarte scăzută
- Revizor Gemini Code Assist — gratuit și ușor de utilizat - poate descoperi probleme de securitate și scalabilitate pe care alți revizori le-au omis
- Va oferi sugestii specifice de remediere
- Nu este degeaba
- Revizor Claude Code — practic inutil - excesiv de precaut, întotdeauna sugerează "consideră adăugarea..."
- Majoritatea sugestiilor sunt supra-proiectate
- Cu excepția cazului în care este marcat ca "critic", altfel se sare direct peste
Toți cei trei revizori vor comenta direct în PR.
Pasul 6: Testare automată
Pipelines CI vor rula:
- Verificări Lint și TypeScript
- Teste unitare
- Teste E2E
- Teste Playwright (rulate într-un mediu de previzualizare identic cu cel de producție)
Regula nouă adăugată săptămâna trecută: dacă PR a modificat UI, trebuie să includă capturi de ecran în descriere, altfel CI va eșua direct.
Această regulă a scurtat semnificativ timpul de revizuire - autorul poate vedea rapid ce s-a schimbat din capturile de ecran, fără a fi nevoie să acceseze mediul de previzualizare.
Pasul 7: Revizuire manuală
Acum, autorul primește o notificare pe Telegram: "PR #341 este gata, poate fi revizuit."
În acest moment:
- CI este complet verde
- Toți cei trei revizori AI au aprobat
- Captura de ecran arată modificările UI
- Toate cazurile limită sunt documentate în comentariile de revizuire
Revizuirea autorului durează doar 5-10 minute. La multe PR-uri, el nici măcar nu verifică codul, doar se uită la capturi de ecran și le fuzionează direct.
Pasul 8: Fuzionare
PR-ul este fuzionat. Există o sarcină cron zilnică care curăță worktree-urile izolate și înregistrările sarcinilor.Completați procesul, de la cerințele clientului până la lansarea codului, poate dura doar 1-2 ore, iar contribuția reală a autorului poate fi de doar 10 minute.
Trei mecanisme pentru a face sistemul mai inteligent
Mecanismul 1: Ralph Loop îmbunătățit — nu doar repetare, ci învățare
Este posibil să fi auzit de Ralph Loop: extragerea contextului din memorie → generarea de ieșiri → evaluarea rezultatelor → salvarea învățării.
Dar majoritatea implementărilor au o problemă: promptul folosit în fiecare ciclu este același. Ceea ce se învață îmbunătățește căutările viitoare, dar promptul în sine este static.
Acest sistem este diferit.
Când Agentul eșuează, Zoe nu va reporni cu același prompt. Ea va analiza cauza eșecului cu contextul de afaceri complet și apoi va rescrie promptul:
❌ Exemplu prost (prompt static): { "implementați funcția de șablon personalizat" }
✅ Exemplu bun (ajustare dinamică): { "Opriți. Clientul vrea X, nu Y. Acestea sunt cuvintele lor din întâlnire: Vrem să păstrăm configurația existentă, nu să creăm una nouă de la zero. Concentrați-vă pe reutilizarea configurației, nu pe crearea unui nou proces." }`Zoe poate face aceste ajustări pentru că are un context pe care Agentul nu-l are:
- Ce a spus clientul în întâlnire
- Ce face această companie
- De ce a eșuat cererea similară anterioară
- Dimineața: scanează Sentry → descoperă 4 erori noi → pornește 4 Agenți pentru a investiga și a remedia
- După întâlnire: scanează notele de întâlnire → descoperă 3 cerințe de funcționalitate menționate de clienți → pornește 3 Codex
- Seara: scanează git log → pornește Claude Code pentru a actualiza changelog-ul și documentația clientului
Modelele de succes vor fi înregistrate:
- "Această structură de prompt este foarte eficientă pentru funcția de facturare"
- "Codex trebuie să primească definițiile de tip în avans"
- "Trebuie să includă întotdeauna calea fișierului de testare"
Cu cât trece mai mult timp, cu atât prompturile scrise de Zoe devin mai bune, pentru că își amintește ce a avut succes.
Mecanismul 2: Strategia de selecție a Agenților — sarcini diferite, experți diferiți
Nu toți Agenții sunt la fel de puternici. Autorul a rezumat strategia de selecție:
- Codex(gpt-5.3-codex) — principalul agent - logică backend, bug-uri complexe, refacerea mai multor fișiere, sarcini care necesită raționament între biblioteci de cod
- Lent, dar temeinic
- Acoperă 90% din sarcini
- Claude Code(claude-opus-4.5) — agent rapid - muncă frontend
- Probleme de permisiune mai puține, potrivit pentru operațiuni git
- (Autorul l-a folosit mai des înainte, dar a trecut la Codex 5.3)
- Gemini — designer - are estetică de design
- Pentru UI-uri frumoase, mai întâi lasă Gemini să genereze specificațiile HTML/CSS, apoi le dă lui Claude Code pentru implementare în sistemul de componente
- Gemini proiectează, Claude construiește
Mecanismul 3: Unde este blocajul? RAM
Există o limitare neașteptată: nu costul token-urilor, nu rata API-ului, ci memoria.
Fiecare Agent are nevoie de:
- propriul său worktree
- propriile sale nodemodules
- rularea construcției, verificarea tipurilor, testarea
Mac Mini al autorului (16GB RAM) poate rula simultan maximum 4-5 Agenți, iar dacă sunt mai mulți, începe să facă swap, și trebuie să se roage să nu construiască simultan.Deci, el a cumpărat un Mac Studio M4 Max (128GB RAM, 3500$), care a sosit la sfârșitul lunii martie. A spus că va împărtăși dacă merită sau nu.
Poți construi și tu: de la zero la funcționare în doar 10 minute
Vrei să încerci acest sistem?
Cea mai simplă metodă:
Copiază întreaga acestă articol pentru OpenClaw și spune-i: "Conform acestei arhitecturi, implementează un sistem de cluster Agent pentru biblioteca mea de cod."
Apoi, va:
- citi designul arhitectural
- crea scripturi
- seta structura directorului
- configura monitorizarea cron
Trebuie să te pregătești:
- un cont OpenClaw
- acces API la Codex și/sau Claude Code
- un depozit git
- (opțional) Obsidian pentru a stoca contextul de afaceri
2026: compania de un milion de dolari a unei singure persoane
Autorul a spus un lucru la finalul articolului care mi s-a părut foarte inspirator:
"Vom vedea o mulțime de companii de un milion de dolari conduse de o singură persoană apărând începând cu 2026. Leverage-ul este uriaș, aparținând celor care înțeleg cum să construiască sisteme AI de auto-îmbunătățire recursive."
Așa arată:
- un orchestrator AI ca extensia ta (la fel ca Zoe pentru autor)
- delegarea muncii către agenți specializați, care se ocupă de diferite funcții de afaceri
- inginerie, suport pentru clienți, operațiuni, marketing
- fiecare agent se concentrează pe ceea ce știe să facă cel mai bine
- tu rămâi concentrat și ai control total
Acum, conținutul generat de AI este prea mult gunoi. Tot felul de hype, tot felul de demo-uri sofisticate ale "centrelor de control al sarcinilor", dar fără nimic cu adevărat util.
Autorul spune că vrea să facă exact opusul: mai puțin hype, mai multe înregistrări ale procesului real de construcție. Clienți reali, venituri reale, trimiteri reale publicate în medii de producție, și, de asemenea, eșecuri reale.
Acest articol se încheie aici.
Recapitulare a punctelor cheie:
- Arhitectură în două straturi: stratul de orchestrare deține contextul de afaceri, stratul de execuție se concentrează pe cod
- Automatizare completă: procesul de 8 pași de la cerințe la PR, majoritatea sarcinilor reușind din prima
- Învățare dinamică: nu este vorba de execuție repetată, ci de ajustarea strategiei în funcție de motivele eșecului
- Costuri controlabile: începere de la 20$/lună, utilizare intensă 190$/lună
Referință:[[HTMLPLACEHOLDER_0]]
