Standard

Linter językowy i reguły stylu

Standard językowy jest martwy bez narzędzia egzekucji. Ten rozdział definiuje, jak zbudować linter dla odpowiedzi modelu: od terminologii i tonu, przez format i zakazy, po reguły cytowań. Celem jest spójność oraz minimalizacja ryzyk — w sposób audytowalny.

Czas czytania: ~13 min Aktualizacja: 2026-01-09
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Standard językowy i ma formę Standard. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal ton i rejestr: profesjonalny, spójny, bez slangu.
  • Zdefiniuj terminologię: preferowane i zakazane terminy (słownik).
  • Określ formaty: akapity, listy, nagłówki, długości, CTA.
  • Zbuduj linter językowy: typowe błędy, skróty, kalki, interpunkcja.
  • Dodaj wyjątki i proces akceptacji odstępstw (rejestr wyjątków).
  • Wdróż w zespole: szablony, szkolenia, przeglądy jakości.

Najczęstsze pułapki

  • „Standard” jako PDF w szufladzie – bez narzędzia egzekucji nic się nie zmienia.
  • Brak słownika terminów – każdy pisze inaczej, rośnie chaos.
  • Zbyt drobiazgowe zasady – ludzie je obchodzą lub ignorują.
  • Brak wyjątku i ścieżki eskalacji – standard blokuje pracę.

Artefakty w Luage

policy:language dictionary templates lint_rules exception_log

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Fragment polityki językowej (skrócony)

language: pl-PL
style:
  tone: "profesjonalny, rzeczowy"
  avoid:
    - "ASAP"
    - "ticket"
  prefer:
    ASAP: "w ciągu 24 godzin roboczych"
    ticket: "zgłoszenie"

Dobrze działa: mało zasad, ale egzekwowanych konsekwentnie w narzędziu i szablonach.

Reguły, które warto mieć od razu
  • Zakazy: wrażliwe dane, obietnice bez pokrycia, „zgadywanie”.
  • Terminologia: słownik pojęć + forma firmowa.
  • Cytowania: claimy faktów wymagają źródeł (jeśli to domena RAG).
  • Format: nagłówki, listy, numeracja, JSON (gdy wymagany).
Linter jako element egzekucji standardu: reguły → severity → bramka → publikacja.
Linter jako element egzekucji standardu: reguły → severity → bramka → publikacja.
Luage Engine jest wartościowy wtedy, gdy „przestaje się dyskutować o stylu”. Linter przenosi decyzje z poziomu opinii na poziom reguł.

1. Cel

Linter językowy ma wymuszać standard w sposób powtarzalny: wykrywać naruszenia, sugerować poprawki i (gdy trzeba) blokować publikację.

2. Zakres i granice

  • Styl i ton: spójność marki, uprzejmość, zwięzłość.
  • Terminologia: słownik + preferowane formy.
  • Bezpieczeństwo: zakazy ujawniania danych wrażliwych.
  • Dowody: reguły cytowania i provenance (gdy wymagane).

Linter nie zastępuje redaktora ani audytu — ma eliminować najczęstsze błędy i wymuszać minimalny standard.

3. Klasy reguł

Strukturalne
Nagłówki, format odpowiedzi, schemat JSON, długość.
Leksalne
Zakazane frazy, słowa‑wytrychy, „wstawki” nieprofesjonalne.
Terminologiczne
Słownik pojęć, preferowane tłumaczenia, nazwy własne.
Dowodowe
Cytowania, odnośniki do źródeł, format provenance.

4. Severity i bramkowanie

PoziomCo oznaczaDecyzja
INFOWskazówka stylistyczna.Nie blokuje.
WARNRyzyko lub niespójność.Wymaga decyzji (approve) lub poprawki.
ERRORNaruszenie standardu lub bezpieczeństwa.Blokada (fail gate).

5. Wersjonowanie i wyjątki

Reguły powinny mieć wersję (lint_policy_vX) oraz rejestr wyjątków. Wyjątek jest dopuszczalny, ale musi mieć powód, termin i owner.

6. Przykładowe reguły

{
  "lint_policy": "v1.2",
  "rules": [
    { "id": "LNG-001", "severity": "ERROR", "type": "forbidden_phrase", "pattern": "na pewno", "hint": "Nie obiecuj bez dowodu." },
    { "id": "LNG-014", "severity": "WARN", "type": "term_preference", "pattern": "prompt", "replacement": "prompt (podpowiedź)" },
    { "id": "CIT-003", "severity": "ERROR", "type": "citation_required", "when": "factual_claim", "hint": "Dodaj źródło lub oznacz niepewność." }
  ]
}

7. Integracja z pipeline

  • Lint po generacji, przed publikacją.
  • Lint w trybie preflight (na szkicu) oraz gate (na produkcji).
  • Raportuj rule_id, severity, fragment i rekomendację.

8. Checklist

  • Reguły są wersjonowane i mają ownerów.
  • Severity jest spójne: ERROR blokuje, WARN wymaga decyzji.
  • Istnieje rejestr wyjątków i proces przeglądu.
  • Linter jest zintegrowany z audytem (trace_id) bez wycieku PII.

Powiązane

Najczęstsze błędy
  • Reguły „na sztywno” bez wersji.
  • Brak rozróżnienia WARN vs ERROR.
  • Wyjątki bez terminu i ownera.
Powiązane
Standard językowy Glosariusz Kontrakt cytowań