Промпты для Sonnet 5.5: рефакторинг нескольких файлов с проверкой границ задачи

Хороший промпт для рефакторинга с Sonnet 5.5 определяет допустимые файлы, поведение, которое нельзя менять, и доказательства выполнения задачи. Просьба «приведи код в порядок» оставляет все три вопроса открытыми. Для изменения нескольких файлов запишите постоянные правила в CLAUDE.md, план выделения модулей — в конкретном задании, а получившийся код проверьте независимо.

В этом руководстве используется небольшой Python-отчёт о трудозатратах по заявкам. Вы разделите чтение данных, агрегирование и координацию командной строки, сохранив публичный интерфейс. Архив упражнения содержит исходный проект, десять контрактных тестов, промпт, проверку допустимых путей и эталонную реализацию. Нужны Python 3.10 или новее и Git. Для офлайн-части не требуются сторонние пакеты и API-ключи.

Ofox написал и локально проверил эталон 8 октября 2026 года. Мы не запускали Sonnet для его создания. Успешные тесты подтверждают свойства этой реализации, а не частоту успеха модели, её скорость или способность всегда соблюдать инструкции. Для проверки промпта используйте разрешённый сеанс Claude Code и сохраняйте его фактический результат отдельно.

Зафиксируйте контракт до начала изменений

Исходный ticket_report/report.py читает CSV, проверяет идентификаторы и часы, складывает трудозатраты по командам и печатает JSON. Заголовок должен иметь точный вид id,team,hours. Арифметика Decimal сохраняет сумму 0.1 и 0.2 без перехода к двоичному приближению. Значения в JSON остаются строками, включая формат десятичной записи.

Для приложенного файла выполните:

python3 -m ticket_report fixtures/tickets.csv

Ожидаемый вывод:

{"Billing": "1.50", "Support": "0.75"}

Это только видимая часть контракта. Существующие потребители должны по-прежнему импортировать parse_rows и summarize из ticket_report.report. Команды выводятся в отсортированном порядке. Некорректная строка вызывает ошибку, а не молча исчезает. Отсутствующий файл или неправильные аргументы завершают процесс с кодом 2: сообщение идёт в stderr, успешного результата в stdout нет.

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

Задача намеренно уже, чем перепроектирование системы заявок. Пример не обещает исчерпывающую проверку произвольных CSV, защиту от вредоносных загрузок или производительность промышленной системы. Ограничение позволяет прочитать весь результат и при этом проверить реальную зависимость между несколькими файлами.

Подготовьте изолированную исходную версию

Распакуйте архив и откройте starter. Соседний каталог reference оставьте вне рабочего репозитория: модель не должна случайно принять ответ за часть исходного приложения. Сначала создайте чистую базовую версию:

cd sonnet-refactor-kit/starter
git init
git add .
git commit -m "Baseline ticket report exercise"
python3 -m unittest discover -s tests -v
python3 -m ticket_report fixtures/tickets.csv

Должны пройти десять тестов. Если Git требует настроить имя и почту, используйте обычную политику своего проекта, не копируйте чужую личность из статьи. При ошибке до редактирования сначала проверьте среду и распаковку. Неисправная исходная версия не позволяет установить, появилась ли следующая ошибка из-за действий модели.

Набор проверяет десятичные суммы, пустую таблицу, пробелы и Unicode, повторяющиеся ID, неверные числовые значения, порядок колонок, пустую команду и три варианта работы CLI. Числовые подслучаи включают отрицательные часы, бесконечные значения и NaN, пустое поле и текст вместо числа. Это существенно полезнее единственного успешного примера.

В настоящем проекте также сохраните начальный коммит и список уже существующих изменений, затем выделите рабочее дерево или ветку. Не очищайте чужую работу широким reset. Здесь новый репозиторий нужен именно для сравнения отчёта о путях с известной базой, а не как обязательный способ работы со всяким проектом.

Постоянные правила поместите в CLAUDE.md

Документация памяти Claude Code описывает CLAUDE.md как контекст инструкций, а не принудительную конфигурацию. Фраза «не менять тесты» направляет модель, но не заменяет права доступа и проверку. В той же документации описана команда /context: убедитесь, что нужный файл проекта загружен, прежде чем полагаться на его содержание.

Официальная документация на английском, снимок от 8 октября 2026 года. Это источник правил, а не скриншот успешного запуска модели.

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

# Ticket report exercise
Run commands from this directory. Python 3.10+; standard library only.
Run `python3 -m unittest discover -s tests -v` before and after changes.
Run `python3 -m ticket_report fixtures/tickets.csv` for the CLI contract.
Preserve the public imports `ticket_report.report.parse_rows` and `summarize`.
Keep Decimal arithmetic, JSON strings, sorted keys, error messages and exit codes.
Only edit report.py or add parsing.py and aggregation.py inside ticket_report/.
Do not change tests/, fixtures/, __main__.py, dependencies or this file.
No network, deployment, commits or unrelated cleanup are part of the task.
If a requirement conflicts with existing behavior, report it before changing behavior.
In the final response list files changed, commands and actual results, and limitations.
These instructions are task context, not a filesystem security boundary.

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

Передайте Sonnet полное задание

Сначала выберите нужную модель в клиенте и проверьте настройку. Руководство по Sonnet 5.5 в Claude Code рассматривает аккаунт и провайдера. Доступность модели и то, куда указывает псевдоним, не определяются качеством промпта. Самоназвание в ответе модели не доказывает, какая модель действительно обслуживала запрос.

Открыв исходный проект, отправьте:

Refactor ticket_report/report.py without changing behavior.
First read CLAUDE.md and tests/test_contract.py, run the existing tests,
and explain the current contract.
Extract parse_rows to ticket_report/parsing.py and summarize to
 ticket_report/aggregation.py.
Keep report.py as the CLI coordinator and re-export both public functions.
Allowed changes: ticket_report/report.py, ticket_report/parsing.py,
and ticket_report/aggregation.py only.
Do not update tests or fixtures to accommodate your changes.
Do not add dependencies or deploy.
After editing run the full test suite and CLI example; inspect the final diff.
Report actual test output, the file list, and remaining limitations.
If blocked, report the exact blocker.

Задание определяет и структуру модулей, и наблюдаемое поведение. Требование повторного экспорта принципиально: переноса функций недостаточно, если старые потребители импортируют их по прежнему пути. Сохранение координатора также не даёт случайно изменить python -m ticket_report лишь ради более аккуратного расположения файлов.

Рекомендации Anthropic для Sonnet 5.5 объясняют, что effort может влиять на самостоятельность и проверку работы, и советуют явно задавать границы. Выбирайте настройку осознанно, затем оценивайте фактический результат. Повышение effort не заменяет тестовое покрытие. Разбор уровней effort помогает с этим отдельным решением, но не меняет критерии упражнения.

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

Отдельно проверьте реализацию, тесты и пути

После сеанса выполните команды самостоятельно из starter. Не принимайте текстовое заявление об успехе без вывода команд:

python3 -m unittest discover -s tests -v
python3 -m ticket_report fixtures/tickets.csv
python3 ../scope_check.py
git diff --check
git diff HEAD

Скрипт сравнивает отслеживаемые изменения с HEAD и добавляет новые файлы, не исключённые правилами Git. Второй шаг важен: выделенные модули ещё не отслеживаются, и обычная разница незастейдженных файлов может их не показать. Разрешены только report.py, parsing.py и aggregation.py внутри ticket_report.

Ожидается изменение именно этих трёх путей и отсутствие посторонних. Чистый отчёт о границах не доказывает корректность реализации: разрушительное изменение разрешённого файла всё равно проходит проверку пути. И наоборот, успешные тесты не оправдывают изменение исходных данных или конфигурации. Нужны обе проверки; читайте новые файлы наряду с diff уже отслеживаемых.

В эталоне report.py импортирует выделенные функции и продолжает обрабатывать аргументы, ошибки и JSON. Поэтому старые публичные импорты сохраняются. Один и тот же набор из десяти тестов проходит как в исходном, так и в эталонном дереве, а пример CLI выдаёт показанный выше JSON. Это локальные результаты эталона: ваш запуск модели может дать другой результат.

Исправляйте сбой, не ослабляя критерии

Прицельный промпт ремонта обычно полезнее полного перезапуска:

The original test test_cli_missing_file now fails: expected exit code 2.
Keep the original tests unchanged. Inspect only the allowed files and
restore the prior CLI error behavior. Run all ten tests, the CLI fixture,
and the scope checker again. Report the actual output.

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

Сохраните вместе подтверждение обслуживающей модели, промпт, базовый коммит, патч, вывод тестов и попытки исправления. Если затем решите сравнить Sonnet и Opus в программировании, обе модели должны получить одинаковую исходную копию и одинаковые критерии. Успешный небольшой рефакторинг свидетельствует об этом запуске, а не о безусловном превосходстве модели.

Критерии передачи результата

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

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