Ghid practic: folosirea AI (ChatGPT, Copilot, Claude) – ce contează cu adevărat

Publicat de Simedru Florin pe decembrie 12, 2025

Ghid practic: folosirea AI (ChatGPT, Copilot, Claude) – ce contează cu adevărat

AI-ul de tip LLM (Large Language Model) poate accelera redactarea, analiza, programarea și documentarea. Totuși, rezultatele depind masiv de context, constrângeri și verificare. În acest articol ai un set de principii, tipare de prompt și exemple concrete, inclusiv pentru scenarii cu MCP.

Cuprins

Ce este un LLM și când e util
ChatGPT vs Copilot vs Claude – cum alegi
Principii de lucru: prompt engineering simplu și robust
Exemple de comenzi (prompturi) pentru LLM
MCP: ce este și cum se folosește (cu exemple)
Workflow recomandat (business + software)
Capcane frecvente + checklist de verificare
Template-uri reutilizabile

1) Ce este un LLM și când este util

Un LLM este un model AI antrenat pe cantități mari de text pentru a genera răspunsuri, a rezuma, a explica și a produce conținut (inclusiv cod). Un LLM nu “știe” în sens uman; el estimează următorul text probabil, bazat pe contextul oferit.

Folosește AI când vrei:

draft rapid pentru emailuri, documentație, articole, proceduri
analiză de text: rezumate, extragere cerințe, comparări
asistență la cod: explicații, refactor, test cases, review
idei și alternative: opțiuni de arhitectură, planuri de proiect
învățare accelerată: concepte, exemple, analogii

Ai grijă când:

datele sunt sensibile (confidențial, NDA, PII)
e “high stakes”: legal, medical, financiar, safety
ai nevoie de adevăr factual verificat (date, cifre, citate)
cerințele sunt ambigue și nu definești criterii de acceptanță

Regula de aur Tratează AI-ul ca pe un coleg junior foarte rapid: bun la draft și idei, dar are nevoie de brief clar și de o revizie atentă.

2) ChatGPT vs Copilot vs Claude – cum alegi

Platformele diferă prin integrare, stil și capabilități. În practică, alegerea corectă depinde de contextul de lucru: browser, IDE, documente, date, automatizări.

ChatGPT

puternic la conversație, structurare, scriere, analiză
bun pentru brainstorming, specificații, planuri și QA
util când vrei “un consultant” care întreabă și rafinează

GitHub Copilot

focalizat pe cod în IDE (autocomplete, sugestii)
excelent pentru boilerplate, pattern-uri, refactor rapid
util când ai deja repo + context în fișiere

Claude

adesea apreciat pentru texte lungi, rezumate, claritate
bun pentru documente, policy, contracte (cu prudență)
util când vrei un stil foarte “curat” și coerent

Recomandare practică: folosește Copilot pentru cod în IDE, iar ChatGPT/Claude pentru analiză, specificații, documentație și prompturi elaborate.

3) Principii: cum scrii prompturi care chiar funcționează

3.1 Context → Constrângeri → Output

Context: ce problemă rezolvi, pentru cine, în ce mediu
Constrângeri: limbaj, format, stil, limite, compatibilitate
Output: ce livrabil vrei (listă, tabel, cod, pași, diagrame)

3.2 Criterii de acceptanță

definește “gata când…” (ex. include test, edge cases, exemple)
cere validări (ex. “nu inventa API-uri”, “marchează incertitudini”)
impune structură (titluri, secțiuni, bullet points)

3.3 Iterație controlată

pas 1: draft rapid
pas 2: îngustează (restricții, exemple, date reale)
pas 3: verifică (test, referințe, contradicții)

Atenție: dacă promptul e vag, AI-ul va completa “golurile” cu presupuneri. Pentru proiecte serioase, cere explicit: “Dacă lipsește o informație critică, listeaz-o ca întrebare/assumption, nu ghici.”

4) Exemple de comenzi (prompturi) pentru LLM

4.1 Prompt “de analiză” (cerințe + risc + plan)

Rol: ești un arhitect software.
Context: dezvolt o aplicație web (PHP + JS + MySQL) pentru administrarea unei firme.
Obiectiv: propune o arhitectură modulară + plan de implementare în 4 sprinturi.

Constrângeri:
- Stack: PHP 8.2, MySQL 8, frontend simplu (fără build tools).
- Securitate: autentificare, roluri, audit log.
- Output: (1) diagramă textuală a modulelor, (2) backlog pe sprinturi, (3) riscuri + mitigări.

Criterii de acceptanță:
- Include minim 10 user stories cu criterii de acceptanță.
- Include minim 5 riscuri.
- Nu presupune servicii cloud; totul self-hosted.

4.2 Prompt “de cod” (implementare + test + edge cases)

Scrie o funcție în C care parsează un buffer circular de bytes.
Format frame:
- start marker: 0x55 0xBA 0x55 0xBA (4 bytes)
- end marker:   0x55 0xED 0x55 0xED (4 bytes)
- payload: variabil, max 512 bytes

Cerințe:
- datele din buffer sunt overwritable; trebuie să gestionezi wrap-around
- output: extrage frame-urile complete într-o coadă
- include teste unitare simple (fără framework extern)
- explică edge cases (marker în payload, frame incomplet, overflow)

4.3 Prompt “de redactare” (articol / documentație / procedură)

Scrie un articol în română (HTML) despre: "Cum aleg un senzor pentru detectarea palei unei turbine".
Include:
- comparație senzori optici vs inductivi vs vibrații
- criterii: distanță, praf/ulei, turație, sincronizare
- schemă de conectare (text) și recomandări HW reale (generic, nu brand-specific)
- secțiune finală: checklist de implementare

4.4 Prompt “de verificare/critic” (QA pentru un draft)

Te rog să faci QA pe textul următor:
- identifică afirmațiile care necesită surse/verificare
- semnalează ambiguități și contradicții
- propune o versiune îmbunătățită, păstrând sensul și structura
Text:
[lipește textul aici]

Tip tactic: când ceri cod, specifică întotdeauna (1) versiuni, (2) mediul (OS/IDE), (3) standard (C99/C11), (4) ce e “interzis” (biblioteci externe, alocări dinamice, etc.).

5) MCP: ce este și cum se folosește (cu exemple)

MCP (Model Context Protocol) este un mod standardizat prin care un “client” (aplicația ta/IDE/agent) conectează un model LLM la tool-uri (de exemplu: fișiere, baze de date, API-uri interne, Git, sisteme de ticketing), astfel încât modelul să poată cere și primi context în mod controlat, fără copy/paste manual.

Ideea centrală În loc să trimiți tu loguri, fișiere și rezultate de query în chat, configurezi “servere” MCP care expun tool-uri. LLM-ul solicită tool-ul potrivit, primește datele, apoi generează output-ul.

5.1 Exemple de “comenzi” MCP (conceptual)

Formatele diferă în funcție de client, dar conceptual ai trei tipuri de interacțiuni: listare tool-uri, apel tool și folosire rezultat.

// 1) Modelul cere ce tool-uri sunt disponibile (descoperire)
{
  "type": "mcp.tools.list"
}

// 2) Clientul răspunde cu tool-uri (exemple)
{
  "tools": [
    {"name": "repo.search", "description": "Caută text în repo"},
    {"name": "repo.readFile", "description": "Citește un fișier"},
    {"name": "db.query", "description": "Rulează un query SQL read-only"},
    {"name": "tickets.search", "description": "Caută tichete după cuvinte cheie"}
  ]
}

// 3) Modelul cere un apel concret de tool (ex: citește un fișier)
{
  "type": "mcp.tools.call",
  "tool": "repo.readFile",
  "arguments": {"path": "src/auth/login.php"}
}

// 4) Clientul returnează rezultatul, iar modelul îl folosește
{
  "type": "mcp.tools.result",
  "tool": "repo.readFile",
  "content": "…conținutul fișierului…"
}

5.2 Scenariu practic: “Agent” pentru debugging într-un proiect

Rol: ești un senior software engineer.
Obiectiv: investighează eroarea "Invalid Product localized property link_rewrite".
Instrucțiuni:
1) Folosește tool-ul repo.search ca să găsești unde se setează link_rewrite.
2) Citește fișierele relevante cu repo.readFile.
3) Propune fix (minim 2 variante) și explică impactul.
4) Dacă ai nevoie de date din DB, cere db.query pentru a verifica limbile/configurile.

Securitate MCP: tratează tool-urile ca pe “permisiuni”. Expune doar ce e necesar, preferă read-only, loghează accesul și evită să oferi modelelor acces direct la secrete (token-uri, chei, parole).

6) Workflow recomandat (business + software)

6.1 Pentru documente / management

Brief (1 pagină): scop, audiență, ton, structură
Draft AI + 2 iterații de clarificare
QA: consistență, termeni, date, riscuri
Final: format (HTML/PDF/Doc) + checklist de publicare

6.2 Pentru coding

Definire contract (input/output, erori, edge cases)
Generare implementare minimă + teste
Refactor + review de securitate
Benchmark / profiling (dacă e critic)

6.3 Pentru “agentic” (MCP/tooling)

Tool-uri read-only la început
Log pentru apeluri + limite (rate/size)
Politici: ce fișiere/DB sunt accesibile
Validare umană înainte de acțiuni destructive

7) Capcane frecvente + checklist de verificare

Capcane

Halucinații: răspunsuri fluente dar false
Confuzie de versiuni: API/SDK/standard schimbat
Overfitting la exemplu: soluție bună doar pentru un caz
Prompt incomplet: lipsesc constrângeri critice

Checklist (rapid)

Am cerut format clar de output?
Am dat exemple input/output?
Am definit criterii de acceptanță?
Am cerut explicit “nu ghici / marchează assumptions”?
Am verificat prin test / surse / rulare reală?

8) Template-uri reutilizabile (copy/paste)

8.1 Template universal (orice problemă)

Rol:
Context:
Obiectiv:

Date de intrare (dacă există):
- ...

Constrângeri:
- Tehnologii:
- Format output:
- Interdicții/limitări:

Criterii de acceptanță:
- ...

Dacă îți lipsește o informație critică:
- listeaz-o ca întrebare sau assumption, nu inventa.

8.2 Template pentru cod (calitate + test)

Scrie [funcție/modul] în [limbaj + versiune].
Cerințe funcționale:
- ...
Cerințe non-funcționale:
- performanță / memorie / thread-safety / compatibilitate
Edge cases:
- ...

Output:
1) cod complet
2) exemple de utilizare
3) teste (minim 5)
4) explicație succintă a designului

8.3 Template pentru MCP (agent cu tool-uri)

Ești un agent care are acces la următoarele tool-uri (prin MCP): [lista].
Obiectiv:
- ...

Reguli:
- Folosește repo.search înainte de repo.readFile când nu știi locația.
- Preferă read-only; nu modifica fără să explici impactul.
- Când ai rezultat din tool, citează exact fișierul/linia (dacă tool-ul oferă).
- Dacă există ambiguități, enumeră 2-3 ipoteze și ce ar schimba fiecare.

Automatic house blog

Faceți căutări pe acest blog