Комментарии 2
я в своей работе использую несколько специализированных промпто для контроля качества
1) Проведи глубокий аудит безопасности потоков данных: найди потенциальные утечки чувствительной информации и нарушения границ доверия
(смотрит на потенциальные кражи, некачественно собранную защиту, неправильное распределение по контурам безопасности и т.п.)
2) Выполни поиск уязвимостей контроля доступа (Broken Access Control) и векторов инъекций: проверь наличие IDOR (Insecure Direct Object Reference), путей горизонтальной и вертикальной эскалации привилегий, а также строгость серверной валидации бизнес-состояния (Client-Side Enforcement bypassing).
(ищет все потенциальные места для инъекций, нерешенные или упущенные блокировки перехвата управления, проверки полученных с фронт-энда запросов на соответствие текущему состоянию базы и наличия прав на запрос и на авторизацию)
3) Проанализируй end-to-end сценарии на предмет логических уязвимостей и состояний процессов: выяви тупиковые состояния (dead states), необработанные граничные случаи (edge cases) и возможные пути обхода бизнес-логики при прерывании сессии или нестандартном порядке запросов.
(сквозной анализ от первого нажатия до завершения сессии с учетом дерева потенциальных действий, тут лучше иметь изначально хотя бы кратко описанный сценарий пользователя, но даже без него они отлично его представляют и проверяют на "сквозноту")
4) Проведи теоретический Chaos-инжиниринг: выяви точки отказа (SPOF), проверь наличие и корректность паттернов "повторные попытки выполнения", "резервные сценарии работы", "предохранители при отказах". Опиши сценарии каскадного падения системы и выяви, где отсутствие плавной / изящной деградации приведет к неработоспособности всего функционала при неработоспособности одной компоненты / сервиса
(проверяет модули на устойчивость при незапланированных ситуациях, проверит что произойдет в случае отключения каждой из компоненты)
5) Выполни аудит производительности и потребления ресурсов: найди проблемы бесконечных запросов к базе данных, неоптимальные индексы, потенциальные утечки памяти, незакрытые соединения и места, уязвимые к атакам исчерпания ресурсов.
(тут все просто - анализ на то, что система не повесит сервак в аварийных случаях)
---
суть промптов (направление проверки) я уже давно выучил. А перед каждым использованием я скидываю в отдельный чат его краткий вид и прошу расписать подробнее гемини, а потом уже вставляю. Так что запуск "двухэтапный", чтобы не держать в голове все термины
Общая проблема единого запроса "проверь на production-ready" в том, что модель выберет каждый раз свой способ проверки, неконтролируемый, а скорее навязанный прошлым диалогом. А даже если посмотрит "сверху", то с большой вероятностью она не будет выписывать все - найдет первые 5-10-15 ошибок и про них напшет. И уж тем более она маловероятно будет проводить "стресс-устойчивость к форс-мажорам", "работоспособность сквозных сценариев" и "защищенность от точечных попыток обращаться с системой незадокументированными способами".
P.S. Не забудь заставить модель надеть маску или супер-тестировщика, или эксперта-разработчика или гуру-архитектора. А то под ролью "физика-теоретика" или "маркетолога" она эти проверки выполнит... спустя рукава -)
Спасибо!

Несколько тупых, но очень эффективных промптов для Codex для всех проектов