> ## Documentation Index
> Fetch the complete documentation index at: https://docs.windsurf.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cazuri de utilizare comune

> Cazuri de utilizare comune pentru Windsurf, inclusiv generarea de cod, generarea de teste unitare, documentarea codului, integrarea cu API-uri și refactorizarea codului.

Windsurf acoperă o gamă variată de cazuri de utilizare la nivel înalt. Totuși, observăm că unele cazuri sunt mai răspândite decât altele, în special în rândul clienților noștri Enterprise, în bazele lor de cod de producție.

<div id="code-generation">
  ## Generare de cod
</div>

<AccordionGroup>
  <Accordion title="Cod boilerplate">
    **Ghid:** Windsurf ar trebui să funcționeze bine pentru acest caz de utilizare. Funcțiile Windsurf includ sugestii pe o singură linie, pe mai multe linii și completări fill-in-the-middle (FIM).

    **Cele mai bune practici:** Folosirea Next Completion (`⌥ + ]`), Context Pinning, @ Mentions și Custom Context va oferi cele mai bune rezultate.
  </Accordion>

  <Accordion title="Sarcini de dezvoltare front-end">
    **Ghid:** Windsurf ar trebui să funcționeze bine pentru acest caz de utilizare. Funcțiile Windsurf includ sugestii pe o singură linie, pe mai multe linii și completări fill-in-the-middle (FIM).

    **Cele mai bune practici:** Folosirea Next Completion (`⌥ + ]`), Context Pinning, @ Mentions și Custom Context va oferi cele mai bune rezultate.
  </Accordion>

  <Accordion title="Sarcini de dezvoltare back-end">
    **Ghid:** Windsurf ar trebui să funcționeze bine pentru acest caz de utilizare. Funcțiile Windsurf includ sugestii pe o singură linie, pe mai multe linii și completări fill-in-the-middle (FIM).

    **Cele mai bune practici:** Folosirea Next Completion (`⌥ + ]`), Context Pinning, @ Mentions și Custom Context va oferi cele mai bune rezultate.
  </Accordion>
</AccordionGroup>

<div id="unit-test-generation">
  ## Generarea testelor unitare
</div>

<AccordionGroup>
  <Accordion title="Generează teste unitare și elimină automat cazurile de test redundante">
    **Recomandări:** Utilizarea de bază a Windsurf pentru generarea testelor unitare ar trebui să producă în mod fiabil 60–70% dintre teste. Acoperirea cazurilor limită va fi pe măsura modului în care utilizatorul formulează prompturile pentru model.

    **Cele mai bune practici:** Folosește mențiuni cu @. Aplică bunele practici de Prompt Engineering. Exemple:

    Scrie un test unitar pentru `@function-name` care acoperă toate cazurile limită pentru X și pentru Y (de ex., domeniu de e-mail).

    Folosește `@testing-utility-class` pentru a scrie un test unitar pentru `@function-name`.
  </Accordion>

  <Accordion title="Generează date de exemplu pentru execuția testelor">
    **Recomandări:** Potrivit pentru cazuri simple, cu beneficii imediate. Pentru specificații API foarte precise sau biblioteci interne, Windsurf s-ar putea să nu cunoască suficient de bine particularitățile pentru a garanta calitatea datelor de exemplu generate.

    **Cele mai bune practici:** Fii foarte specific cu privire la interfața așteptată. Gândește-te la complexitatea sarcinii (și dacă un singur apel LLM este suficient pentru a o rezolva).
  </Accordion>
</AccordionGroup>

<div id="internal-code-commentary">
  ## Comentarii interne în cod
</div>

<AccordionGroup>
  <Accordion title="Generează comentarii inline și descrieri ale codului">
    **Recomandări:** Windsurf ar trebui să funcționeze bine pentru acest caz de utilizare. Folosește Windsurf Command sau Windsurf Chat pentru a genera comentarii inline și descrieri ale codului.

    **Bune practici:** Folosește @mentions și Code Lenses cât mai mult posibil pentru a te asigura că aria apelului LLM este corectă.
  </Accordion>

  <Accordion title="Sugerează îmbunătățiri și clarificări">
    **Recomandări:** În general, butonul Refactor / Windsurf Command sunt cele mai bune modalități de a solicita îmbunătățiri. Windsurf Chat este locul potrivit pentru explicații sau clarificări. Formularea e puțin vagă, dar Windsurf se descurcă bine la ambele.

    Windsurf Chat este locul potrivit pentru explicații sau clarificări.

    Formularea e puțin vagă, dar Windsurf se descurcă bine la ambele.

    **Bune practici**: Folosește prompturile din dropdown (denumite și butonul Refactor din Windsurf) – avem prompturi personalizate, concepute mai bine pentru a oferi răspunsul pe care cel mai probabil îl aștepți.
  </Accordion>

  <Accordion title="Automatizează antetele funcțiilor (C/C++/C#)">
    **Recomandări**: Cel mai bun mod este să creezi fișierul header, să deschizi Chat, să menționezi cu @ funcția din fișierul .cpp și să ceri scrierea declarației în header. Apoi repetă iterativ pentru fiecare funcție din fișierul .cpp. Astfel reduci riscul de halucinații pe parcurs.

    **Bune practici**: În general, evită să încerci să scrii un întreg fișier header cu un singur apel LLM. Fragmentarea lucrului pe pași mai mici crește semnificativ calitatea codului generat.
  </Accordion>
</AccordionGroup>

<div id="api-documentation-and-integration">
  ## Documentație API și integrare
</div>

<AccordionGroup>
  <Accordion title="Creați documentație pe măsură ce sunt create API‑urile și oferiți context adecvat">
    **Recomandări**: Este similar cu acoperirea testelor, unde părți ale specificației API, comune multor biblioteci, pot fi completate cu acuratețe de Windsurf. Însă, pentru componente create special pentru cazurile interne de utilizare, Windsurf ar putea să nu atingă calitatea așteptată.

    **Bune practici**: Ca la acoperirea testelor, pe cât posibil, ghidați modelul AI al Windsurf cu cea mai bună abordare pentru a înțelege ce face API‑ul, iar acesta va putea completa mai bine.
  </Accordion>

  <Accordion title="Căutați în repo API‑uri în limbaj natural și generați cod pentru integrări">
    **Recomandări**: Lungimea de context a Windsurf pentru un singur apel LLM este de 16.000 de tokeni. Astfel, în funcție de amploarea căutării, capabilitățile de căutare la nivelul întregului repo ale Windsurf pot să nu fie suficiente. Sarcinile la nivel de întreg repo, în mai mulți pași și cu multiple modificări vor fi susținute în produsele Windsurf viitoare.

    Aceasta este, în esență, o problemă în mai mulți pași pe care apelurile LLM de tip single‑shot (adică funcționalitatea actuală a tuturor asistenților AI de cod) nu sunt bine echipate să o abordeze. În plus, acuratețea rezultatului trebuie să fie mult mai mare decât în alte cazuri de utilizare, deoarece integrările sunt deosebit de fragile.

    **Bune practici**: Windsurf nu este bine echipat să rezolve această problemă astăzi. Dacă doriți să testați limitele funcționalității existente a Windsurf, construiți un plan pas cu pas și solicitați Windsurf, separat, pentru fiecare pas, oferind un nivel ridicat de detalii pentru a ghida AI‑ul.
  </Accordion>
</AccordionGroup>

<div id="code-refactoring">
  ## Refactorizarea codului
</div>

<AccordionGroup>
  <Accordion title="Simplificarea și modularizarea codului">
    **Recomandări**: Asigurați o delimitare corectă a contextului folosind Windsurf Code Lenses sau @ Mentions, pentru a vă asigura că tot contextul necesar este transmis către LLM.

    Lungimile de context pentru un singur apel LLM sunt finite. Prin urmare, în funcție de anvergura refactorizării, această limită poate deveni o problemă (ca, de altfel, în orice paradigmă LLM de tip single-shot). Sarcinile la nivel de repository, pe mai mulți pași și cu multiple editări sunt acum acceptate în [Cascade](/ro/windsurf/cascade) de la Windsurf.

    **Cele mai bune practici**: Încercați să fragmentați promptul cât mai mult posibil. Cu cât comanda de refactorizare este mai simplă și mai scurtă, cu atât mai bine.
  </Accordion>

  <Accordion title="Restructurarea codului pentru a îmbunătăți lizibilitatea/mentenabilitatea">
    **Recomandări**: Asigurați o delimitare corectă a contextului folosind Windsurf Code Lenses sau @ Mentions, pentru a vă asigura că tot contextul necesar este transmis către LLM.

    Lungimea de context a Windsurf pentru un singur apel LLM este de 16.000 de tokeni. Prin urmare, în funcție de anvergura refactorizării, această limită poate deveni o problemă (ca, de altfel, în orice paradigmă LLM de tip single-shot). Sarcinile la nivel de repository, pe mai mulți pași și cu multiple editări vor fi acceptate în viitoarele produse Windsurf.

    **Cele mai bune practici**: Încercați să fragmentați promptul cât mai mult posibil. Cu cât comanda de refactorizare este mai simplă și mai scurtă, cu atât mai bine.
  </Accordion>
</AccordionGroup>
