AI domyślnie korzysta z generycznej średniej swoich danych treningowych, więc aby uzyskać Twój styl, musisz go pokazać i egzekwować — poprzez przykłady, jawny plik reguł i pętlę lintera, która wyłapie to, co przejdzie niezauważone. Nie polegaj na tym, że będzie odgadywać Twoje standardy (WordPress Coding Standards, PSR-12, itp.).
.eslintrc, phpcs.xml lub .editorconfig. To są reguły w formie możliwej do sprawdzenia maszynowo, i AI może je przeczytać.CLAUDE.md lub systemowy prompt, który wyraźnie określa standard: "Ten projekt podąża za PSR-12. Używaj 4-spacjowego wcięcia, nawiasy na następnej linii dla funkcji, snake_case dla hooków." Stałe instrukcje są lepsze niż powtarzanie się w każdym prompcie.# 1. AI generates the change, then you run the project linter on it:
phpcs --standard=phpcs.xml src/NewClass.php
# => src/NewClass.php 12 | ERROR | Expected 1 space after FUNCTION keyword; 0 found
# src/NewClass.php 14 | ERROR | Line indented incorrectly; expected 4 spaces, found 2
# 2. Paste those exact errors back to the AI: "Fix these phpcs errors."
# 3. Re-run until clean. The linter — not the AI's claim — is the source of truth.
Ta pętla zbiega się szybko, ponieważ linter dostarcza precyzyjne, na poziomie linii, sprzężenie zwrotne, które AI może bezpośrednio wykorzystać, zamiast opisywania stylu w tekście.
Kod, który ignoruje konwencje projektu, tworzy tarcia w recenzji i niespójność, nawet jeśli jest funkcjonalnie poprawny — recenzenci marnują czas na formatowanie, a baza kodu dryfuje. AI nie ma świadomości Twojego stylu domu, chyba że go dostarczysz, więc zadaniem jest uczynienie reguł jawnymi i sprawdzalnymi: plik reguł na potrzeby intencji, reprezentatywny kod na potrzeby idiomów i linter jako egzekutor w pętli. Taka sama dyscyplina (konfiguracja + przykłady + zautomatyzowana kontrola) to sposób, w jaki wdrażasz członka zespołu do Twoich konwencji.