AI по умолчанию использует обобщённый стиль из своих данных обучения, поэтому чтобы получить ваш стиль, вы должны показать и принудительно применить его — через примеры, явный файл правил и лупу линтера, которая ловит ошибки. Не полагайтесь на то, что AI угадает ваши стандарты (WordPress Coding Standards, PSR-12 и т. д.).
.eslintrc, phpcs.xml или .editorconfig. Это правила в машиночитаемом виде, и AI может их читать.CLAUDE.md или системный промпт, который явно указывает стандарт: «Этот проект следует PSR-12. Используйте 4-пробельный отступ, скобки на следующей строке для функций, snake_case для хуков.» Постоянные инструкции лучше, чем повторять себя в каждом промпте.# 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.
Эта лупа сходится быстро, потому что линтер даёт точную, построчную обратную связь, на которую AI может сразу действовать, вместо того чтобы вы описывали стиль прозой.
Код, который игнорирует соглашения проекта, создаёт трение при ревью и несогласованность даже если он функционально верный — ревьюеры тратят время на форматирование, и кодовая база дрейфует. AI не имеет осознания вашего домашнего стиля, если вы его не предоставите, поэтому работа заключается в том, чтобы сделать правила явными и проверяемыми: файл правил для намерений, репрезентативный код для идиом и линтер как инструмент проверки в лупе. Та же дисциплина (конфиг + примеры + автоматическая проверка) — это то, как вы вводите нового человеческого члена команды в соглашения вашего проекта.