Отладка фичи: анализ потока и минимальный фикс
Описание промпта
Структурированный промпт для поиска багов в коде. Требует от ИИ сначала разобрать поток данных и жизненный цикл, затем найти точную причину сбоя и предложить минимальное исправление без рефакторинга архитектуры.
- Этот промпт помогает разработчикам быстро находить и исправлять баги, сохраняя архитектуру чистой. Он заставляет ИИ сначала понять контекст и поток данных, прежде чем предлагать код.
- Предотвращает усложнение кода, фокусируется на корневых причинах (тайминг, состояние), обеспечивает структурированный анализ рисков и архитектуры.
- Backend и Frontend разработчики, системные архитекторы, инженеры по качеству (QA), изучающие паттерны отладки.
Заполните переменные {{DESCRIBE_FEATURE}}, {{WHAT_SHOULD_HAPPEN}}, {{WHAT_IS_HAPPENING}} и {{PASTE_RELEVANT_CODE}} перед отправкой. Если ИИ задаст вопросы, ответьте на них для уточнения контекста.
Необходимо предоставить описание фичи, ожидаемое и фактическое поведение, а также релевантный фрагмент кода. Чем точнее вводные, тем лучше результат.
Структурированный отчет с диаграммой потока, точным указанием места ошибки, минимальным фрагментом кода для исправления и анализом рисков.
Используйте для сложных багов, связанных с состоянием, асинхронностью или интеграцией. Не подходит для простых синтаксических ошибок.
Не заменяет полноценное тестирование. Результат зависит от качества предоставленного описания и кода. Может быть излишне подробным для простых задач.
DESCRIBE_FEATURE
DESCRIBE_FEATURE
Краткое описание функционала, в котором возник баг.
WHAT_SHOULD_HAPPEN
WHAT_SHOULD_HAPPEN
Описание того, как система должна вести себя в норме.
WHAT_IS_HAPPENING
WHAT_IS_HAPPENING
Описание текущей проблемы или ошибки.
PASTE_RELEVANT_CODE
PASTE_RELEVANT_CODE
Фрагмент кода, содержащий логику функционала или ошибку.
Промпт открыт для всех. Зарегистрируйтесь, чтобы копировать одним кликом, сохранять промпты, оценивать их и подписываться на авторов.
Текст промпта
ChatGPT / Claude / Llama
Войти для копирования
Выступи в роли старшего инженера-программиста и архитектора систем.
## Контекст
Я разрабатываю функционал приложения. Есть баг, а предыдущие попытки исправления усложнили систему. Мне нужно:
- Четкое понимание потока данных
- Точное определение точки отказа
- Минимальное и точное исправление (без оверхенджиринга)
Ты ОБЯЗАН объяснить поток системы перед попыткой исправления.
---
## Вводные данные
Функционал:
{{DESCRIBE_FEATURE}}
Ожидаемое поведение:
{{WHAT_SHOULD_HAPPEN}}
Текущая проблема:
{{WHAT_IS_HAPPENING}}
Код:
{{PASTE_RELEVANT_CODE}}
---
## Формат вывода (СТРОГИЙ)
### 1. Поток системы (Визуальный + Логический)
#### А. Диаграмма потока
Предоставь пошаговый поток:
Действие пользователя
→ UI слой
→ Состояние / Контроллер / Логика
→ Обработка данных
→ Внешняя система / SDK / API (если есть)
→ Обработка ответа
→ Рендеринг / Вывод
→ Обновление UI
---
#### Б. Объяснение каждого этапа
Для каждого шага:
- Что происходит
- Какие данные передаются
- Какие трансформации происходят
- Какие зависимости существуют
---
#### В. Критические точки времени (ВАЖНО)
Определи:
- Когда создаются объекты/ресурсы
- Когда данные загружаются или запрашиваются
- Когда обновляется состояние
- Когда конфигурации ДОЛЖНЫ применяться
---
### 2. Ожидаемое поведение
Определи корректное поведение:
- Нормальный успешный поток
- Краевые случаи
- Сценарии сбоев
Если неясно, задай до 3 конкретных вопросов и ОСТАНОВИСЬ.
---
### 3. Текущее поведение
Объясни фактическое поведение, используя:
- Описание проблемы
- Анализ кода
---
### 4. Расхождение (Критично)
Определи:
- Точный шаг, где поведение расходится
- Что должно произойти vs что происходит на самом деле
---
### 5. Корневая причина (Точно)
Определи точную причину:
- Проблема с таймингом (асинхронность, жизненный цикл)
- Неверная ссылка или данные
- Состояние не обновляется
- Логическая ошибка
- Проблема интеграции
Укажи:
- Конкретную функцию / блок / этап жизненного цикла
Если не уверен, четко укажи допущения.
---
### 6. Минимальное исправление (СТРОГО)
- Предоставь наименьшее возможное изменение
- НЕ переписывай архитектуру
- НЕ вводй ненужную абстракцию
Предоставь ТОЛЬКО измененный фрагмент кода.
Сфокусируйся на:
- Исправлении тайминга
- Корректном потоке данных
- Правильном обновлении состояния
---
### 7. Почему исправление работает
Объясни:
- Как это исправляет точную точку отказа
- Связь с потоком системы
- Связь с жизненным циклом/таймингом
---
### 8. Риски (ВАЖНО)
Проанализируй:
- Влияние на другие части системы
- Производительность
- Побочные эффекты
---
### 9. Профилактика (Архитектурные рекомендации)
Предложи:
- Лучшую обработку жизненного цикла
- Четкое разделение ответственности
- Где должна жить логика:
- UI
- Контроллер / Состояние
- Слой данных / Сервис
---
## Ограничения
- НЕ делай допущений о поведении без их указания
- НЕ перемещай логику хаотично
- НЕ добавляй условия вслепую
- Фокусируйся на потоке, тайминге и данных
---
## Правило резервного варианта
Если вводных данных недостаточно:
- Задай до 3 конкретных вопросов
- ОСТАНОВИСЬ
---
## Самопроверка (ОБЯЗАТЕЛЬНО)
Перед ответом:
- Связал ли я баг с конкретным шагом потока?
- Выявил ли проблемы с таймингом/жизненным циклом?
- Является ли исправление минимальным и локализованным?
- Избежал ли я оверхенджиринга?Поделитесь в социальных сетях
Комментарии
Войдите, чтобы комментировать.
Комментариев пока нет.