Практика · 7 мин
Как запросить доказанный план изменения
Формат задачи, который оставляет явными допущения, проверки и откат.
Запрос «исправь обработку ошибки» оставляет агенту слишком много скрытых решений: какую версию считать целевой, где менять код, чем проверять и что делать при неудаче.
Доказанный план делает цель, область влияния, источники, проверки и откат видимыми до изменения файлов.
Начните с запрета на преждевременное изменение
Первая строка исследовательского запроса: «Только исследуй изменение и составь доказанный план доработки. Ничего не изменяй». Она разделяет анализ и применение и сохраняет возможность проверить допущения.
Шесть обязательных полей плана
Хороший план называет цель, целевую версию, источники, затронутые места, проверки и способ отката. Отдельно перечисляются неизвестные данные и действия, требующие разрешения.
Какое поведение должно измениться.
Для какой координаты применим вывод.
Библиотека, проект и Exact-факты.
Что вызывает изменяемую функцию.
Синтаксис, тесты и выполнение.
Как безопасно вернуть прежнее состояние.
Копируемый запрос
Шаблон сохраняет дисциплину и подходит для адаптации под конкретную задачу.
Только исследуй изменение и составь доказанный план доработки. Ничего не изменяй. Цель: <наблюдаемое поведение>. Целевая версия: <подтверждённая координата>. Покажи библиотечные источники, факты проекта и область влияния. Отдельно перечисли предположения и неизвестное. Предложи минимальное изменение, проверки и откат. Не выполняй команды, меняющие состояние, без отдельного разрешения.
Передайте запрос своему агенту. Сайт ничего не выполняет.
План должен уметь остановиться
Если не найдена версия, область влияния или безопасный тест, результатом исследования может быть блокирующий вопрос. Это полезнее, чем подробный план, построенный на неподтверждённом предположении.
План для конфликта без преждевременного патча
Пусть обработчик 1С получил ROUTE-409-DUPLICATE. Первый этап плана — открыть карточку ошибки и стандарт журналирования синтетического корпуса. Второй — по исходникам конкретного проекта найти обработчик и вызывающие места. Пока второго слоя нет, в плане нельзя писать имя изменяемого модуля как факт.
Критерий готовности плана: указаны та же версия библиотеки, безопасная реакция на конфликт, запрет нового ключа, тест на отсутствие чувствительных данных в журнале и способ отменить будущий патч. Если нет тестового контура, агент должен остановиться с вопросом о проверке, а не пометить план выполненным.
Обработка ROUTE-409-DUPLICATE
Агенту нужно исследовать конфликт ключа, но не менять синтетический клиент.
- Найти правило ошибки и безопасные метаданные.
- Найти обработчик и места его вызова.
- Проверить запрет нового ключа и журналирования requestFingerprint.
- Предложить тест конфликта и откат без применения патча.
Сам текст промпта и план учебные; автоматическое принятие или применение изменения не подразумевается.
Что уже можно утверждать, а что нужно проверить
- Корпус фиксирует правила идемпотентности, ошибок и безопасного журналирования.
- Исследование можно отделить от применения изменения.
- Реальную область влияния в проекте.
- Доступность тестового контура и допустимость команд.