Как пользоваться готовыми промптами
Эти примеры можно копировать целиком и заменять фразы в квадратных скобках своими данными. Промпт не обязан быть длинным: для простой задачи достаточно ясной цели. Чем выше цена ошибки и чем больше проект, тем важнее добавить контекст, ограничения и признаки готового результата.
Хорошее задание для Codex отвечает на четыре вопроса: что нужно получить, где искать нужный контекст, что нельзя менять и как проверить готовность. Именно на этой схеме построены все промпты ниже.
Что дать Codex перед началом
Перед отправкой задания откройте правильную папку или проект и приложите материалы, которые действительно меняют результат. Для важной или неоднозначной работы сначала запросите план и разрешите изменения только после его проверки.
- Цель: конкретный наблюдаемый результат.
- Контекст: файлы, ссылки, ошибки, примеры и аудитория.
- Границы: что нельзя менять, отправлять, удалять или публиковать.
- Готово, когда: тест, сценарий, формат или другой способ проверки.
1. Разобраться в незнакомом проекте
Полезно перед первой правкой, передачей проекта или аудитом чужой работы. На этом этапе Codex только изучает материалы и ничего не меняет.
Изучи проект в папке [путь]. Ничего не меняй. Объясни простыми словами: для чего он нужен, как устроен, где находятся ключевые файлы, как его запустить и проверить. Отдельно перечисли непонятные места, риски и вопросы, которые нужно задать владельцу.
2. Составить план работы до изменений
Используйте для многошаговой задачи, где ошибка в направлении обойдётся дороже, чем несколько минут на согласование плана.
Цель: [результат]. Изучи текущий проект и подготовь план без изменений в файлах. Для каждого шага укажи затрагиваемые файлы, проверку и возможный риск. Если данных не хватает, сначала задай вопросы. Готово, когда план можно выполнить без догадок.
3. Превратить сырую идею в техническое задание
Подходит, когда вы понимаете желаемый эффект, но ещё не знаете точный состав продукта или страницы.
У меня есть идея: [описание]. Пока ничего не создавай. Проведи короткое интервью: задай не более [число] вопросов о пользователе, сценарии, ограничениях и критериях успеха. Затем подготовь одностраничное задание: цель, пользователь, состав первой версии, что не входит, критерии готовности и открытые вопросы.
4. Расставить приоритеты в списке задач
Такой запрос помогает превратить хаотичный backlog в последовательность работы, но окончательное решение о приоритетах остаётся за вами.
Изучи список задач [файл или текст]. Раздели их на критичные, важные и необязательные. Для каждой оцени ценность, срочность, сложность, зависимость и риск. Предложи порядок выполнения на [период]. Не меняй исходный список; результат представь таблицей.
5. Найти и исправить причину ошибки
Ключевое требование — сначала воспроизвести проблему и собрать доказательства. Это уменьшает риск исправить симптом и оставить настоящую причину.
Ошибка: [сообщение или симптом]. Сначала воспроизведи проблему и собери доказательства. Найди корневую причину, а не только место падения. До исправления объясни гипотезу и минимальный план. Затем внеси самое узкое исправление, добавь проверку от повторения и перечисли выполненные команды.
6. Реализовать небольшую функцию
Лучше всего работает для одной законченной возможности с понятным пользовательским сценарием.
Добавь [функция] для [пользователь]. Сохрани текущий стиль и архитектуру. Не меняй [ограничения]. Сначала найди похожую реализацию, затем внеси минимальные изменения. Готово, когда [сценарий] работает, тесты проходят и нет правок вне задачи.
7. Безопасно провести рефакторинг
Рефакторинг должен сохранять наблюдаемое поведение. Просьба сначала зафиксировать его проверками создаёт точку сравнения.
Упрости [файл или модуль], не меняя внешнее поведение. Сначала зафиксируй текущее поведение тестами или проверками. Удали дублирование и улучши читаемость небольшими шагами. Не меняй публичные интерфейсы без моего подтверждения. В конце сравни поведение до и после.
8. Добавить полезные тесты
Хорошие тесты проверяют результат, а не повторяют устройство реализации. Обязательно включайте ошибочные и граничные входные данные.
Изучи [функция или модуль] и существующий стиль тестов. Добавь проверки обычного, ошибочного и граничного сценариев. Не подгоняй тесты под текущую реализацию: проверяй наблюдаемое поведение. Запусти релевантный набор и объясни, какие риски теперь покрыты, а какие остались.
9. Проверить изменения перед публикацией
Отдельная проверка особенно полезна после большой задачи. Сначала нужен отчёт без автоматических исправлений, иначе новые правки могут скрыть исходную проблему.
Проведи независимую проверку текущих изменений. Ничего не исправляй. Сначала прочитай исходную задачу, затем diff и тесты. Ищи ошибки, регрессии, лишние правки, секреты и непроверенные допущения. Выдай замечания по приоритету с файлом, доказательством и способом проверки.
10. Найти лишний код и зависимости
Не просите удалять всё найденное сразу. Для безопасной очистки нужны доказательства использования и план отката.
Проведи аудит [папка или проект] на неиспользуемые файлы, функции, зависимости и дублирование. Ничего не удаляй. Для каждого кандидата покажи доказательство, риск удаления и способ убедиться в безопасности. Раздели уверенные находки и места, требующие ручной проверки.
11. Ускорить страницу или процесс
Оптимизация без исходного измерения легко превращается в набор случайных правок. Сначала зафиксируйте базовое состояние.
Найди основные причины медленной работы [страница или команда]. Сначала измерь базовое состояние и покажи узкие места. Предложи изменения по влиянию и сложности. Реализуй только согласованный безопасный минимум, повтори измерение и сравни результат с исходным.
12. Проверить доступность интерфейса
Промпт охватывает не только автоматические правила, но и реальные сценарии клавиатуры, фокуса, ошибок и мобильного использования.
Проверь [страница] на доступность: клавиатура, фокус, подписи полей, заголовки, контраст, состояния ошибок и мобильный сценарий. Ничего не меняй до отчёта. Раздели блокирующие и желательные улучшения, затем предложи минимальный план исправления и способ повторной проверки.
13. Провести технический SEO-аудит
Такой аудит проверяет техническую основу страницы. Позиции и частотность нельзя выводить из кода сайта — для них нужны реальные данные поисковых систем.
Проверь [URL или проект] по техническому SEO: title, description, H1, canonical, robots, sitemap, индексируемость, структурированные данные, внутренние ссылки и коды ответа. Не придумывай поисковые данные. Подготовь таблицу: проблема, доказательство, приоритет, исправление и проверка.
14. Обновить документацию после изменений
Codex сначала находит расхождения, а затем меняет только связанные разделы. Так проще сохранить структуру и стиль документа.
Сравни [документ] с текущим состоянием проекта. Сначала перечисли устаревшие, неверные и отсутствующие места. Затем обнови только затронутые разделы, сохранив стиль. Проверь команды, пути, ссылки и названия интерфейса. Не добавляй факты, которые нельзя подтвердить.
15. Превратить заметки в статью
Укажите аудиторию, тему и допустимые источники. Для SEO-материала сначала полезно согласовать поисковое намерение и структуру.
Используй заметки [файл] и источники [список], чтобы подготовить статью для [аудитория] о [тема]. Сначала предложи поисковое намерение и структуру. Не выдумывай факты и цитаты. В готовом тексте дай конкретные шаги, примеры, FAQ, внутренние ссылки и места, где требуется дополнительный источник.
16. Сравнить две версии документа
Особое внимание стоит уделить числам, датам, именам и обязательствам: небольшое отличие в них может иметь большое значение.
Сравни [файл A] и [файл B]. Не переписывай документы. Покажи таблицу: раздел, что изменилось, влияние, противоречие и рекомендуемое решение. Отдельно перечисли числа, даты, имена и обязательства, которые нужно перепроверить вручную.
17. Очистить и проанализировать таблицу
Оригинал нужно сохранить неизменным, а все преобразования — перечислить. Это позволяет проверить очистку и вернуться к исходным данным.
Изучи таблицу [файл]. Сначала сохрани исходные данные и опиши проблемы качества: пропуски, дубликаты, форматы и аномалии. Затем создай очищенную версию, не затирая оригинал. Проверь формулы и итоги, подготовь краткие выводы и перечисли все преобразования.
18. Подготовить понятный отчёт
Хороший отчёт начинается с решения, а не с длинного описания процесса. Также важно отделить факты от предположений.
На основе [файлы или данные] подготовь отчёт для [аудитория]. В начале дай вывод и решения, затем факты, риски и следующие шаги. Отделяй подтверждённые данные от предположений. Перед завершением проверь числа, даты, источники и наличие владельца у каждого действия.
19. Автоматизировать повторяющуюся задачу
Сначала нужно описать процесс без нейросети и выбрать обратимый пилот. Отправка, публикация, удаление и оплата остаются за отдельным подтверждением человека.
Процесс: [описание]. Сначала опиши текущие входы, шаги, решения, исключения и результат. Предложи самый простой обратимый вариант автоматизации. Не выполняй отправку, оплату, удаление или публикацию без подтверждения. Создай прототип, тесты на обычных и ошибочных данных и инструкцию запуска.
20. Улучшить правила работы Codex
После нескольких задач полезно провести ретроспективу: одноразовые условия оставить в промпте, правила проекта перенести в AGENTS.md, а стабильный повторяемый процесс — в skill.
Проанализируй эту задачу и нашу переписку. Найди повторяющиеся уточнения, ошибки и удачные инструкции. Предложи, что оставить в одноразовом промпте, что перенести в AGENTS.md, а что оформить как skill. Ничего не меняй автоматически. Для каждой рекомендации покажи конкретный пример и ожидаемую пользу.
Фраза, которая усиливает любой промпт
Для важных задач добавьте в конец короткое требование к самопроверке. Оно не заменяет вашу проверку, но заставляет Codex явно показать доказательства и ограничения результата.
Перед завершением проверь результат, перечисли изменённые файлы и выполненные проверки. Отдельно укажи допущения, риски и то, что не удалось проверить.
Когда промпт пора превратить в правило или skill
Если вы копируете один текст снова и снова, он перестаёт быть одноразовым заданием. Правила конкретного проекта лучше хранить в AGENTS.md. Повторяемый метод с понятными входами и выходами стоит оформить как skill. Расписание имеет смысл добавлять только после того, как процесс стабильно работает вручную.
- Повторяющееся ограничение проекта — в AGENTS.md.
- Личная разовая цель — в текущем промпте.
- Повторяемая последовательность действий — в skill.
- Стабильная задача с понятным результатом — в автоматизацию по расписанию.
Частые вопросы
Можно ли копировать эти промпты без изменений?
Можно, но результат будет лучше, если заменить все квадратные скобки, удалить ненужные условия и добавить конкретные файлы, ссылки, примеры и критерии готовности.
Нужно ли писать длинный промпт для каждой задачи?
Нет. Простая и хорошо ограниченная задача может начинаться с одной-двух фраз. Контекст, границы и проверку стоит добавлять там, где ошибка создаст реальный риск или лишнюю работу.
Что делать, если я не умею составить техническое задание?
Используйте третий промпт и попросите Codex сначала провести интервью. Не разрешайте изменения, пока не станет понятна цель, состав первой версии и признаки готового результата.
Почему в промптах часто написано «сначала ничего не меняй»?
Это разделяет исследование и действие. Вы успеваете проверить диагноз или план до того, как Codex внесёт изменения, которые могут оказаться лишними.
Как проверить результат Codex?
Просмотрите изменённые файлы, запустите релевантные тесты и повторите реальный пользовательский сценарий. Для важной работы используйте отдельный проход проверки без автоматических исправлений.
Где хранить удачные промпты?
Одноразовые задания можно хранить в своей библиотеке. Постоянные правила проекта переносите в AGENTS.md, а повторяемые рабочие процессы оформляйте как skills.