ИИ-промпты для Clean Code: как найти и избежать спагетти-код через Vibe Coding

Если ты сталкиваешься со спагетти-кодом, ИИ может стать мощным инструментом. В статье Избегаем спагетти-код мы рассмотрели основы. Здесь покажу, как использовать целевые ИИ-промпты и небольшие скрипты анализа, чтобы проверить проект на спагетти-код, рефакторить его согласно принципам Clean Code, SOLID и ООП, а также создать надёжные unit-тесты. Особое внимание уделим Vibe Coding, так как именно там часто рождается беспорядочный код.

Vibe Coding и риск спагетти-кода

Vibe Coding означает быстрое создание кода с помощью ИИ-ассистентов типа GitHub Copilot, ChatGPT или Claude. Для прототипов и небольших фич это работает впечатляюще хорошо. Минус в том, что ИИ оптимизирует код на его функциональность, а не на поддерживаемость. Если ты принимаешь каждое предложение без проверки, накапливаются длинные функции, дубликаты и запутанные зависимости.

Спагетти-код не возникает автоматически из Vibe Coding, но риск резко возрастает, если ты не ставишь перед ИИ явные требования к Clean Code, SOLID и тестируемой архитектуре. Решение — это workflow из автоматизированного анализа, чётких целей в промптах и ручного ревью.

Автоматическая проверка проекта на спагетти-код

Прежде чем обращаться к ИИ, полезно понять, где находятся основные проблемы. Небольшой Node.js скрипт просканирует проект в поиске типичных красных флагов.

// scripts/analyze-spaghetti.js
const fs = require('fs');
const path = require('path');

const TARGET_DIR = process.argv[2] || 'src';
const EXTENSIONS = ['.js', '.ts', '.jsx', '.tsx'];
const issues = [];

function scanDir(dir) {
  fs.readdirSync(dir, { withFileTypes: true }).forEach(entry => {
    const full = path.join(dir, entry.name);
    if (entry.isDirectory()) scanDir(full);
    else if (EXTENSIONS.includes(path.extname(full))) analyzeFile(full);
  });
}

function analyzeFile(file) {
  const lines = fs.readFileSync(file, 'utf8').split('\n');
  let functionStart = null;
  let braceDepth = 0;

  lines.forEach((line, index) => {
    const trimmed = line.trim();

    if (/^\s*(function\s+\w+|const\s+\w+\s*=|async\s+function|=>)/.test(line)) {
      functionStart = index;
    }

    braceDepth += (line.match(/\{/g) || []).length;
    braceDepth -= (line.match(/\}/g) || []).length;

    if (functionStart !== null && braceDepth === 0 && trimmed === '}') {
      const length = index - functionStart;
      if (length > 30) issues.push(`${file}:${functionStart + 1} - Функция примерно ${length} строк`);
      functionStart = null;
    }

    if (/^\s*if\s*\(.*\)\s*\{\s*$/.test(line)) {
      const next = lines.slice(index + 1, index + 4).join('\n');
      const nested = (next.match(/\n\s*if\s*\(/g) || []).length;
      if (nested > 0) issues.push(`${file}:${index + 1} - вложенные if-блоки`);
    }

    if (/\bvar\b/.test(line)) issues.push(`${file}:${index + 1} - использовано var`);
    const todoMatch = line.match(/(TODO|FIXME|HACK)\b/);
    if (todoMatch) issues.push(`${file}:${index + 1} - найдено ${todoMatch[1]}`);
  });
}

scanDir(TARGET_DIR);
if (issues.length === 0) console.log('Явных признаков спагетти-кода не обнаружено.');
else issues.forEach(i => console.log(i));

Скрипт намеренно простой. Для production систем лучше добавить ESLint, SonarQube или Codacy. Но он быстро выявит проблемные участки, которые можно обработать с помощью ИИ.

От проблемы к Clean Code

Когда скрипт отметит участок, скопируй нужный код в ИИ-ассистент и обработай его с помощью промптов ниже. Типичный workflow:

Найти проблемный участок
Описать его ответственность
Использовать промпт для осмысленных имён, компактных функций и тестов
Проверить результат на соответствие Clean Code, SOLID и ООП
Добавить unit-тесты

В следующих разделах собраны готовые к копированию промпты для каждого важного аспекта. Выделю промпты для отдельных блоков кода и промпты, охватывающие весь проект.

Принципы Clean Code и промпты

В статье Принципы Clean Code мы подробно объяснили правила. При работе с ИИ важно формулировать эти правила как конкретные требования в промпте. Вот промпт для каждого ключевого принципа Clean Code.

Осмысленные имена

Хорошие имена заменяют многие комментарии. Попроси ИИ целенаправленно на это, чтобы избавиться от x, data или tmp.

Ты опытный разработчик. Проанализируй следующий код на предмет неясных имён переменных, функций и классов. Предложи для каждого имени лучшую альтернативу и объясни, почему новое имя улучшает читаемость. Убедись, что имена отражают намерение и ответственность.

Код:
{{CODE}}

Компактные функции

Длинные функции — главный признак спагетти-кода. Каждая функция должна делать одно и в идеале умещаться на экран.

Ты опытный разработчик. Рефакторь следующий код так, чтобы каждая функция имела не более одной ответственности и умещалась на экран. Выдели вспомогательные функции, используй осмысленные имена и убери глубокую вложенность условных операторов через Early Returns или Guard Clauses. Верни рефакторенный код.

Код:
{{CODE}}

Принцип DRY

DRY означает Don’t Repeat Yourself. ИИ часто генерирует дублирующиеся паттерны. Промпт найдёт и устранит их.

Ты опытный разработчик. Найди в следующем коде дублирующуюся логику и объедини её в переиспользуемые функции, классы или константы. Объясни, где нарушен DRY, и как твоё решение улучшает поддерживаемость.

Код:
{{CODE}}

Принцип KISS

KISS означает Keep It Simple, Stupid. Обычно самый простой путь — лучший.

Ты опытный разработчик. Упрости следующий код согласно принципу KISS. Убери ненужные абстракции, лишние циклы и сложные условия. Код должен работать так же, но быть максимально простым и самообъясняющимся.

Код:
{{CODE}}

Хорошие комментарии

Комментарии должны объяснять Почему, а не Что. Плохие комментарии скрывают плохой код.

Ты опытный разработчик. Проверь следующий код на предмет значимых комментариев. Удали лишние или устаревшие комментарии, добавь недостающие комментарии, объясняющие Почему, и улучши код там, где он должен быть самообъясняющимся. Верни переработанный код.

Код:
{{CODE}}

Единообразное форматирование

Последовательное форматирование снижает когнитивную нагрузку. Промпт приведёт в порядок стиль и типы переменных.

Ты опытный разработчик. Отформатируй следующий код согласно стандартным соглашениям. Обрати внимание на отступы, пустые строки, скобки и переносы. Не используй var, предпочитай const и let, и следи за единообразием кавычек.

Код:
{{CODE}}

Обработка ошибок

Молчаливые ошибки, пустые блоки catch и неинформативные сообщения - это спагетти-код при возникновении проблем.

Ты опытный разработчик. Улучши обработку ошибок в следующем коде. Используй понятные сообщения об ошибках, избегай пустых блоков catch, проверяй входные данные на ранних этапах и применяй Guard Clauses. Верни улучшенный код.

Код:
{{CODE}}

Создание Unit Tests с помощью AI

Unit Tests проверяют изолированно наименьшую единицу программы, обычно функцию или метод. Они не только страхуют поведение кода, но и принуждают тебя структурировать его так, чтобы он был тестируемым. Тестируемый код, как правило, лучше структурирован.

При написании тестов обращай внимание на четкую структуру Arrange-Act-Assert, значимые имена тестов и покрытие нормальных случаев, граничных случаев и ошибок. Внешние зависимости вроде баз данных или API замени на Mocks или Stubs.

Ты опытный разработчик. Напиши Unit Tests для следующего кода. Обеспечь четкую структуру Arrange-Act-Assert, продумай тестовые случаи для нормальных ситуаций, граничных случаев и ошибок. Используй Mocks для внешних зависимостей и выразительные имена тестов. Верни код тестов.

Код:
{{CODE}}

Когда использовать какой prompt?

Не каждый prompt подходит для каждой ситуации. Вот простая ориентация, когда применять ту или иную группу.

Code-Detail-Prompts: используй их для отдельных функций или файлов, которые привлекли твое внимание. Они особенно полезны, когда ты работаешь над какой-то фичей и хочешь быстро улучшить читаемость, имена или обработку ошибок.
Unit-Test-Prompts: применяй их сразу после рефактора функции. Тесты страхуют поведение и принуждают тебя к проектированию с учетом тестируемости.
Security Audits: запускай их перед релизом, после крупных изменений или при добавлении новых фич, обрабатывающих пользовательский ввод.
Architecture Audits: используй их, когда проект становится сложным для расширения, растут технические долги или ты планируешь сеанс рефактора.
Итеративный подход для крупных проектов: разбей крупные кодовые базы на пакеты, слои или фичи. Дай AI анализировать области поочередно и объедини результаты в конце.

Security Audits с помощью AI

Уязвимости в AI-сгенерированном коде ты обнаруживаешь наиболее надежно, если проверяешь проект пошагово. Следующие prompts охватывают различные углы зрения.

1. Полный анализ безопасности

Ты опытный Security Auditor.

Проанализируй весь проект на наличие уязвимостей безопасности.

Ищи особенно:

- SQL Injection
- Command Injection
- Remote Code Execution (RCE)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Path Traversal
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Server Side Request Forgery (SSRF)
- Authentication Bypass
- Authorization-проблемы
- Session Hijacking
- Небезопасное хранение паролей
- Information Disclosure
- Hardcoded Secrets
- Небезопасную криптографию
- Race Conditions

Для каждой найденной уязвимости предоставь:

- Имя файла
- Номер строки
- Описание
- Пример атаки
- Уровень риска (Low/Medium/High/Critical)
- Конкретное предложение по улучшению

2. Поиск скрытых проблем

Ищи исключительно тонкие проблемы безопасности.

Игнорируй стиль и качество кода.

Сосредоточься на логических ошибках, которые может использовать злоумышленник.

Ищи особенно:

- отсутствие проверок разрешений
- проблемы с границами доверия
- пользовательский ввод без валидации
- опасные значения по умолчанию
- TOCTOU-проблемы
- Privilege Escalation
- обход проверок разрешений

3. Тест на проникновение с точки зрения злоумышленника

Перевоплотись в роль Penetration Tester.

Ищи исключительно атаки против приложения.

Для каждой уязвимости создай:

- Сценарий атаки
- Пример запроса
- Предусловия
- Влияние
- CVSS-оценку

4. Поиск всех мест с пользовательским вводом

Выдели все места, где обрабатывается пользовательский ввод.

Покажи:

- Источник ввода
- Обработка
- Валидация
- Escaping
- Обращения к БД
- Доступ к файлам
- Вызовы shell
- Сетевые обращения

Оцени каждое место с точки зрения риска.

5. Поиск опасных функций

Ищи в проекте все потенциально опасные функции.

Примеры:

eval
exec
system
shell_exec
popen
proc_open
passthru
include
require
require_once
fopen
unlink
rename
move_uploaded_file

Проверь каждое использование на возможность злоупотребления.

(Эту список ты можешь адаптировать под используемый язык программирования.)

6. OWASP Top 10

Полностью проверь проект по актуальным OWASP Top 10.

Создай таблицу:

OWASP-категория
затронутые файлы
Описание
Риск
Рекомендуемые меры

7. Анализ API

Если приложение имеет API:

Анализируй все API-эндпойнты.

Проверь на:

- отсутствие аутентификации
- отсутствие авторизации
- IDOR
- Rate Limiting
- Mass Assignment
- Injection
- Input Validation

8. “Думай как хакер”

Часто это мой любимый prompt:

Думай как опытный злоумышленник.

Какие три уязвимости ты бы использовал в первую очередь?

Опиши пошагово:

- почему
- как
- вероятность успеха
- возможные последствия

9. Снижение false positives

Очень полезно:

Сообщай только об уязвимостях, которые с высокой вероятностью действительно можно использовать.

Если ты не уверен, четко обозначь их как предположение.

Никаких теоретических или спекулятивных находок.

10. Вторая проверка

После того как AI что-то нашел:

Критически переверь собственный анализ.

Ищи:

- False Positives
- пропущенные проблемы безопасности
- логические ошибки
- дополнительные возможности для атак

После этого подготовь окончательный Security Report.

Дополнительный совет

Если проект крупный (например, несколько тысяч файлов), начни с обзора архитектуры вместо прямого поиска уязвимостей:

Сначала проанализируй архитектуру проекта.

Идентифицируй:

- язык(и) программирования
- framework(и)
- аутентификацию
- обращения к БД
- функции загрузки файлов
- Admin-области
- API-эндпойнты
- операции с файлами
- внешние зависимости

После этого создай план полного Security Audit и выполни его пошагово.

Это дает AI лучший общий обзор и часто приводит к более тщательным результатам, чем одноразовый “Проверь всё” prompt. Однако важно помнить: LLM-audit не заменяет специализированные инструменты (например, SAST, Dependency или DAST сканеры), а дополняет их. Лучшие результаты получаются, когда ты комбинируешь оба подхода.

Не менее важна и проверка архитектуры всего проекта. Отдельные prompts вроде “Проверь на SOLID” обычно дают только общие указания. Лучше работать с целенаправленными audits.

Architecture, Clean Code и SOLID Audits

Следующие prompts помогают тебе проверить весь проект с точки зрения поддерживаемости, дублирования логики и соответствия SOLID/OOP. Они дополняют Code-Detail-Prompts из предыдущего раздела и рассматривают проект как единое целое.

1. Полный архитектурный аудит

Ты опытный архитектор программного обеспечения.

Проанализируй весь проект по следующим аспектам:

- Clean Code
- OOP
- SOLID
- DRY (Don't Repeat Yourself)
- KISS
- YAGNI
- Separation of Concerns
- High Cohesion
- Low Coupling

Сначала создай обзор архитектуры проекта.

Затем выяви все места, где нарушены эти принципы.

Для каждой проблемы предоставь:

- Файл
- Класс
- Метод
- Описание
- Обоснование
- Предложение по улучшению
- Приоритет (Low/Medium/High)

2. Поиск дублирующейся логики (мой любимый)

Это именно то, что ты описал.

Проанализируй весь проект на предмет дублирующейся логики.

Ищи в особенности:

- идентичные функции
- почти идентичные методы
- скопированный код
- одинаковую бизнес-логику
- повторно реализованные вычисления
- повторную валидацию
- повторную логику базы данных
- повторные вызовы API

Для каждого случая покажи:

- оба файла
- оба метода
- степень сходства в %
- какой метод должен служить общей основой
- как можно объединить дубликаты

Игнорируй различия в названиях переменных.

3. Проверка SOLID-принципов по отдельности

Проверь каждый класс отдельно на соответствие SOLID-принципам.

Для каждого класса ответь на следующие вопросы:

Single Responsibility:
Есть ли у класса более одной ответственности?

Open/Closed:
Нужно ли изменять код вместо того, чтобы расширять его?

Liskov:
Правильно ли реализована наследование?

Interface Segregation:
Не слишком ли велики интерфейсы?

Dependency Inversion:
Используются ли конкретные классы вместо абстракций?

Дай конкретные предложения по улучшению.

4. Классы с чрезмерным функционалом

Ищи God Classes.

Узнаешь God Class по следующим признакам:

- более 500 строк
- очень много методов
- знает много других классов
- содержит бизнес-логику, UI и доступ к БД одновременно
- имеет много переменных членов класса

Предложи разумное разделение.

5. Плохие методы

Ищи методы, которые нарушают Clean Code.

Примеры:

- более 30 строк
- несколько ответственностей
- глубокая вложенность
- много параметров
- много булевых флагов
- дублирующаяся логика

Предложи рефакторинг.

6. Проверка ответственности

Проанализируй каждый класс.

Опиши в одном предложении его основную ответственность.

Если класс имеет несколько ответственностей,
точно указывай какие.

Затем предложи разумное разделение.

7. Зависимости

Создай диаграмму зависимостей проекта.

Отметь:

- циклические зависимости
- ненужные зависимости
- сильную связанность
- нарушения Dependency Inversion

Предложи улучшения.

8. Проверка наследования

Проанализируй все наследования.

Проверь:

- ненужное наследование
- можно ли использовать композицию вместо этого?
- нарушения Liskov
- дублирующиеся реализации

Предложи лучшие альтернативы.

9. План рефакторинга

Это часто самый полезный запрос.

Создай полный план рефакторинга.

Упорядочи все проблемы по приоритету.

Для каждой проблемы опиши:

- почему она существует
- какой SOLID-принцип нарушен
- как должен выглядеть класс после рефакторинга
- какие файлы затронуты
- объем работы (small/medium/large)

Цель:

- меньше кода
- без дублирования логики
- лучшая поддерживаемость
- лучшая тестируемость

10. Строгий архитектурный аудит

Веди себя как senior архитектор при code review.

Будь критичен.

Не допускай дублирования логики.

Не допускай классы с несколькими ответственностями.

Не допускай решения copy-paste.

Покажи все места, которые ты точно изменит перед merge в main branch.

Приоритизируй самые важные проблемы в первую очередь.

Ещё один совет

Если твой проект уже достаточно большой (например, более 20 000 строк кода), можешь дать Claude Code такой дополнительный задачу:

Работай итеративно.

Проходи по файлам один за другим.

После каждого файла создавай список найденных проблем.

В конце объедини все результаты.

Если найдешь похожие методы в разных файлах, сравни их между собой и проверь, можно ли их объединить в единую функцию или базовый класс.

Специально ищи нарушения DRY и повторно реализованную бизнес-логику.

Именно этот последний пункт важен: по умолчанию Claude часто оценивает файлы изолированно. Если явно задать ему поиск идентичной или похожей логики между файлами, он значительно надежнее находит дублирование и возможности централизации.

Пример рабочего процесса для сессии рефакторинга

Представь себе, что ты берешься за проект с большим количеством KI-генерированного кода. Примерно так может выглядеть рабочий день:

Запусти node scripts/analyze-spaghetti.js src и собери hotspots.
Скопируй самые проблемные функции в детальные запросы по названиям, форматированию и обработке ошибок.
Сгенерируй unit tests для отредактированных мест.
Если найдешь дубликаты или большие классы через границы файлов, запусти архитектурный аудит.
Создай план рефакторинга и работай по приоритетам.
Перед merge или release проведи аудиты безопасности.
Вручную просмотри все предложения KI. KI помогает найти проблемы, но решение принимаешь ты.

Итоги

KI и Vibe Coding это отличные инструменты, если знаешь, что спросить. Лучшие результаты получаются, когда сначала выявляешь Spaghetti Code простым скриптом, а затем с целенаправленными запросами приводишь его в порядок в соответствии с Clean Code, SOLID, OOP и Unit Tests. Так KI остается ускорителем вместо риска для качества кода.

Täglicher Artikel