Как принимать функцию, написанную нейросетью, и не сломать соседнее

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

Другой условный случай: дата считается в UTC, а отчёт нужен за вчера по местному времени. Около полуночи запись попадёт не в тот день. В обоих случаях надо назвать класс ошибки и проверить все места, где значение читают и показывают. Постановку задачи до начала работы разбираю отдельно; здесь речь о приёмке результата.

Как это выглядит в работе

Внизу экрана КОСМЕТ_А поясняется значение прочерка. Для проверки функции подготовьте два входа: подтверждённый ноль и отсутствие цифры. Они должны дать разные состояния в отчёте.

На другом экране, в отчёте сети салонов, есть строка без указанного подрядчика и с нулевым расходом. Проверка должна сохранить оба факта раздельно: неизвестный источник и подтверждённый нулевой расход.

Перед проверкой: назвать изменение одной фразой

Если агент «исправил заявки», это слишком широко. Нужна проверяемая фраза: «При пустом обязательном поле форма показывает ошибку и не создаёт заявку». Затем запишите один успешный случай и несколько отказов: пустое поле, ошибочный формат, повторная отправка. Для расчёта нужны примеры на границах диапазона и правило округления. Для прав доступа нужны роли, которым действие разрешено и запрещено.

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

Передайте агенту три действия:

• найдите все вызовы изменяемой функции;
• назовите прежний результат для каждого вызова;
• после правки проверьте эти результаты на тех же входах.

rg -n 'имяФункции' .
git status --short
git diff --stat

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

Проверить разные классы входных данных

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

Это схема проверки. Она не описывает четыре функции одного моего проекта. Для своего проекта подставляйте фактические поля и правила. Если ожидаемый результат нельзя назвать заранее, сначала выясните его у владельца процесса. Уверенный ответ ИИ не заменяет правило компании.

Как читать diff после правки

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

git diff --check
git diff --stat
git diff

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

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

Запустите проверки, принятые в репозитории. Для сайта «Мастерская» это проверка статей и сборка:

npm run check:stati
npm run build

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

Сравните результат с исходной формулировкой задачи. Не принимайте дополнительную «улучшенную» функцию без проверки: она могла поменять правило, которое клиент не просил менять. Если обнаружен повторяющийся механизм ошибки, например неверное обращение с нулём, найдите все места того же класса. Исправление одного экрана при общем неправильном помощнике лишь отложит следующую поломку.

Что записать в результат приёмки

Короткий итог полезен и через неделю: что изменено, какие команды прошли, какой ручной сценарий проверен и какое ограничение осталось. Слово «проверено» без способа проверки не помогает. Хорошая запись говорит, какой вход дали, что увидели и в какой среде. Отдельно укажите, если на рабочий сервер ничего не выкладывали: локально собранная версия ещё не равна опубликованной.

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

npm audit --omit=dev --audit-level=high
pip‑audit

Первую команду запускают для Node-проекта, вторую для Python-проекта с установленным pip‑audit. Приложение должно слушать 127.0.0.1 за nginx, а служба работать от своего пользователя, не от root. Приёмка функции и выкладка относятся к разным этапам, у каждого свои свидетельства результата.

Частые вопросы

Достаточно ли успешной сборки?

Нет. Она не проверяет бизнес-правило и пользовательский путь. Нужен хотя бы один правильный и один ошибочный вход по задаче.

Нужно ли писать тест для каждой правки?

Для повторяемого расчёта или ошибки на границе тест помогает сохранить правило. Для небольшой текстовой правки достаточно точной проверки страницы и источника факта.

Как понять, что соседнее не сломано?

Найдите все вызовы изменённой функции и пройдите минимум один прежний сценарий каждого затронутого места.

Что делать, если ИИ изменил больше файлов, чем ожидалось?

Попросите объяснить связь каждого файла с задачей. Лишнюю правку не принимайте только потому, что она уже есть в diff.

Когда можно считать задачу завершённой?

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

На обучении я показываю этот порядок на действующем проекте: формулируем результат, читаем правку и проверяем её на понятных входах.