Как промптить ИИ правильно: урок из бага с доступом к чужим данным

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

Баг, который объясняет всё

Один разработчик строил платформу для управления школами. Без плана и спецификации: открыл ИИ-среду, попросил «собери школьную систему», потом добавлял функции одну за другой. Инструмент справлялся, и это создало иллюзию, что всё в порядке. Когда разработчик наконец сел с ИИ разбирать написанное — не добавлять, а именно анализировать — нашлись уязвимости, проблемы с производительностью и мёртвый код. Не потому, что ИИ плохо пишет. А потому, что ему никогда не сказали, что значит «готово».

Конкретный пример. В платформе есть маршрут, который позволяет учителю или администратору обновлять экзаменационные вопросы. Промпт звучал как «сделай способ редактировать вопросы». ИИ построил проверку: человек владеет экзаменом, в котором работает. Но не проверил, что сам вопрос принадлежит этому экзамену. Если у вас был валидный ID вопроса из любого другого места — даже из другой школы на этой же платформе, — вы могли авторизоваться через свой экзамен и перезаписать чужой вопрос.

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

Исправление заняло один дополнительный запрос к базе. Перед обновлением система теперь проверяет, что вопрос действительно относится к тому экзамену, к которому у пользователя есть доступ. Маленькая проверка, но она появилась только потому, что кто-то сел и осознанно поискал уязвимости — а не попросил ИИ «починить всё сразу».

Инструмент не спасает

Можно подумать, что правильный ИИ-ассистент сам найдёт такие вещи. Разработчик перепробовал Codex, Gemini Antigravity, Claude и Warp. Сценарий одинаковый во всех. Выбор инструмента определяет потолок — насколько большой контекст и хороший агентный режим сами заметят проблему. Но пол — ваша способность сформулировать, что должно быть правдой, — инструменты не заменяют.

Что изменилось в подходе после этого случая?

• Технические требования записываются до промпта. Формат не важен — важен честный ответ на вопрос: что система должна обрабатывать? Не «что нужно сделать», а «что должно быть истинно». Для того самого маршрута разница между «дать учителям редактировать вопросы» и «дать учителям редактировать вопросы, которыми они владеют, привязанные к экзаменам, которыми они владеют, и отклонять всё несовпадающее».
• Кодовая база остаётся читаемой: декомпозиция функций, понятные имена, минимальная вложенность. ИИ пишет лучше, когда может прочитать уже существующий код. Хаос в проекте даёт хаотичные подсказки сверху. Читаемость — это не любезность будущему разработчику, а контекст, который ваш ИИ читает при каждом промпте.

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

Промпт без спецификации и с ней: таблица для сравнения

Чтобы стало нагляднее, вот как меняется запрос, если добавить в него «что должно быть правдой».

Разница не в количестве слов. Разница в том, что второй вариант задаёт инварианты, которые ИИ не обязан угадывать. Он их просто выполняет, а если не может — это сразу видно.

Итог простой. ИИ — это не коллега, который «должен понимать». Это очень буквальный исполнитель. Чем точнее вы описываете не только действие, но и ограничения вокруг него, тем меньше потом приходится закрывать дыр. Один запрос к базе данных стоил дешевле, чем спецификация на полстраницы. Но именно спецификация заставляет этот запрос появиться.