Техники итеративного уточнения

Суть

Конкретные пары вход/выход эффективнее прозаических описаний для задания преобразований: модель обобщает по примерам, а не по инструкциям. Тест-ориентированная итерация использует падающие тесты как однозначный сигнал, что менять.

Пакет против последовательности

Взаимосвязанные проблемы чините одним сообщением; независимые — последовательно. Итеративная регрессия (починил одно — сломал другое) — признак неполных критериев приёмки. Паттерн интервью поднимает соображения дизайна до реализации, снижая слепые зоны.

Конкретные пары вход/выход вместо прозы

Вход:   { "created": "2024-01-15T14:30:00Z" }
Выход:  { "created": "Jan 15, 2024 at 2:30 PM UTC" }

Вход:   { "created": 1705329000 }
Выход:  { "created": "Jan 15, 2024 at 2:30 PM UTC" }

Вход:   { "created": null }
Выход:  { "created": "Unknown" }

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Описывать преобразование прозой при нестабильном результате	Проза трактуется по-разному; модель обобщает по примерам	Дать 2–3 конкретные пары вход/выход, включая краевые случаи
Слать взаимосвязанные баги по одному	Каждый фикс меняет состояние; второй фикс может обнулиться первым	Все взаимосвязанные — одним сообщением; последовательно лишь независимые
Сначала реализация, потом тесты «для проверки»	Такие тесты подгоняются под реализацию; краевые случаи теряются	Сначала набор тестов на поведение; итерировать, делясь падающими тестами

Exam traps

Ловушка	Почему не работает	Верный паттерн
Проза там, где для стабильности нужны примеры	Неоднозначность сохраняется	Конкретные пары вход/выход
Чинить взаимосвязанное последовательно	Промежуточное состояние рождает новые ошибки	Пакетировать взаимосвязанные правки
Итерация без полных критериев приёмки	Цикл «починил — сломал»	Определить полный чек-лист приёмки до итерации

Практическое задание (T5)

Найти задачу-преобразование, где проза даёт нестабильный вывод; заменить 3 конкретными парами и измерить рост стабильности.
Написать набор тестов до реализации; итеративно делиться падающими тестами, пока все не пройдут.
Применить паттерн интервью к незнакомой области (напр. «распределённая блокировка») и отметить вопросы дизайна, которые всплыли.
Найти 2 взаимосвязанных бага; починить одним сообщением; сравнить с последовательным и увидеть проблему промежуточного состояния.
Задокументировать свои эвристики уточнения: когда тянуться к каждой из четырёх техник.

Проверка знаний

Продуктивность разработчика с Claude

Разработчик просит «привести все ответы API к единому формату». Claude выдаёт разные форматы: где camelCase, где snake_case, где вложенно, где плоско. Как эффективнее всего донести ожидаемое преобразование?

A В CLAUDE.md: «всегда camelCase для ответов API с плоской структурой»
B Попросить Claude разобрать нестабильные выводы и самокритично оценить перед следующим ответом
C Дать 2–3 конкретные пары «было/стало» с точной структурой входа и выхода, включая обработку null
D Запустить преобразование трижды и выбрать формат большинством голосов

Продуктивность разработчика с Claude

Рефакторинг модуля аутентификации. Первая попытка — верная структура, но устаревшая JWT-библиотека. После «используй jose вместо jsonwebtoken» вторая теряет multi-tenant claim tenant_id. К третьей пропадает другое обязательное поле. Каждая итерация чинит одно и ломает другое. Корень и решение?

A Задача слишком сложна — разбить на мелкие подзадачи по функциям
B Каждый правящий промпт слишком узок и не задаёт, как выглядит «правильно» целиком. Определить полный чек-лист приёмки до итераций (библиотека, все JWT-claims, обработка ошибок, покрытие тестами) и проверять каждую попытку по нему, а не по последней правке
C Взять модель с лучшей памятью, чтобы удерживать все прошлые правки
D Запустить рефактор 3 раза параллельно с разными промптами и взять прошедший больше всего тестов

Продуктивность разработчика с Claude

Просят сгенерировать REST-эндпоинт. Первый черновик — хороший happy path, без валидации ввода. После 6 последовательных правящих промптов эндпоинт уже не очевидно лучше первого черновика. Какой подход к уточнению был бы эффективнее?

A Написать полную спецификацию в первом промпте, исключив итеративные правки вовсе
B Принять первый черновик и руками починить известные проблемы
C После черновика оценить его по заранее заданной рубрике (валидация, коды ошибок, схема ответа, авторизация, логирование), выявить все пробелы разом и выдать один комплексный правящий промпт вместо 6 одиночных
D Использовать /compact после каждой итерации, чтобы накопление контекста не портило качество