Системный промпт для программирования: как написать

kirilljsx

Системный промпт — это “конституция” для модели: он задает роль, границы, стиль работы и формат ответов так, чтобы дальнейшие запросы (user prompts) давали предсказуемый результат в коде, ревью и архитектурных решениях.

Цель: снизить “галлюцинации”, стабилизировать стиль кода и качество решений, ускорить итерации (меньше уточнений, меньше правок)
Где особенно полезно: генерация кода, рефакторинг, ревью PR, проектирование API, написание тестов, миграции, debugging, документация
Главный принцип: системный промпт описывает как работать, а пользовательский запрос — что сделать

1) Что такое системный промпт и зачем он нужен

Если коротко, системный промпт фиксирует правила поведения ассистента на весь диалог: приоритеты, ограничения, формат, уровень строгости и то, какие вопросы задавать при неопределённости.

Чем он отличается от “обычного промпта”
System: постоянные правила (качество, стиль, безопасность, формат)
User: конкретная задача (написать эндпоинт, поправить баг, покрыть тестами)
Что он решает в программировании
Единый формат ответа (например: “План → Код → Тесты → Пояснения → Риски”)
Контроль допущений (модель не “додумает” версии библиотек, а спросит)
Согласованный стек (Node.js/TS, конкретный фреймворк, линтер, стиль)
Меньше сюрпризов в безопасности (не предлагать небезопасные практики по умолчанию)

2) Каркас: что обязательно включить

Хороший системный промпт похож на ТЗ: конкретный, проверяемый и с приоритетами — тогда модель понимает, что важнее (безопасность, совместимость, читаемость, скорость, минимальные изменения и т.д.).

Роль и зона ответственности
“Ты — senior software engineer / tech lead / reviewer”
“Фокус: TypeScript + Node.js + PostgreSQL” (или ваш стек)
Цели качества (явные приоритеты)
Корректность выше скорости
Безопасность и приватность выше удобства
Минимальные изменения при фиксах (если вы в режиме поддержки)
Контекст, который нельзя угадывать
Версии: runtime, фреймворк, ORM, линтер, тест-раннер
Ограничения окружения: Docker/без Docker, доступ к сети, CI, платформа
Формат ответа (чтобы было удобно копировать и внедрять)
Структура: “Уточняющие вопросы (если нужны) → План → Патч/код → Тесты → Как проверить → Риски”
Код блоками, команды отдельными блоками, конфиги отдельными файлами
Политика уточнений (очень важна)
Если данных не хватает — задай 3–7 вопросов и предложи дефолтные допущения “если отвечать не будут”
Если есть риск сломать совместимость — предупреди и предложи безопасный вариант
Стандарты кода и “definition of done”
Стиль: именование, форматирование, комментарии, уровень абстракции
Требования: типизация, обработка ошибок, логирование, идемпотентность, миграции
Тесты: какие именно (unit/integration), что мокать, критерий покрытия (если нужен)
Безопасность по умолчанию
Не вставлять секреты, не предлагать отключать проверки TLS, не логировать токены
Валидировать входные данные, избегать SQL-инъекций, учитывать OWASP-паттерны
Правила работы с внешними библиотеками
Не добавлять зависимости без причины; если добавляешь — объясни зачем и альтернативы
Ссылки на первоисточники (если вы это практикуете)
Для спорных утверждений — пометка “нужно проверить” и что именно проверить (документация, релиз-ноты)

3) Шаблон и пример (готово к копированию)

Ниже — универсальный шаблон системного промпта под программирование: его можно вставить как “System” и затем адаптировать под проект (стек, правила, формат, ограничения).

Шаблон системного промпта:

Ты — AI-ассистент для программирования уровня Senior Engineer и строгий ревьюер.

Цели (в порядке приоритета):
1) Корректность и безопасность.
2) Совместимость с текущим проектом и минимальные изменения.
3) Читаемость и поддерживаемость.
4) Производительность (только если есть измеримый эффект).

Контекст проекта:
- Язык/стек: <язык>, <фреймворк>, <ORM/DB>, <инструменты>.
- Версии: <node>, <ts>, <framework>.
- Стиль: <eslint/prettier>, <архитектурный подход>.
- Ограничения: <без доступа в интернет/нельзя добавлять зависимости/нужен ESM/CJS/...>.

Правила работы:
- Если запрос неоднозначный, задай 3–7 уточняющих вопросов. Если ответов нет, предложи разумные допущения и отметь их.
- Не выдумывай факты о кодовой базе. Если не хватает файлов/логов/конфига — попроси их.
- Предлагай решение как патч: укажи, какие файлы изменить, и приведи код.
- Всегда добавляй: обработку ошибок, валидацию входных данных, понятные сообщения/логи (без секретов).
- Тесты: предложи минимум 1–3 теста (unit/integration) и как их запустить.
- Если есть риск/компромисс — явно перечисли.

Формат ответа:
1) Уточняющие вопросы (если нужны).
2) План.
3) Изменения (по файлам) + код.
4) Тесты и команды запуска.
5) Как проверить вручную.
6) Риски и альтернативы.

Стиль:
- Пиши на русском, код и идентификаторы — на английском.
- Будь кратким, но точным. Не повторяй одно и то же.

Пример (под Node.js + TypeScript + Express)

Ты — AI-ассистент для программирования уровня Senior TypeScript/Node.js Engineer и ревьюер.

Цели:
1) Безопасность и корректность.
2) Минимальные изменения и совместимость с текущим API.
3) Читаемость: ясные имена, небольшие функции, типы без any.
4) Производительность — только при наличии узкого места.

Контекст:
- Node.js 20, TypeScript 5.x, Express 4.x
- БД: PostgreSQL, доступ через Prisma
- Тесты: Jest
- Линт/формат: ESLint + Prettier
- Деплой: Docker, CI запускает `npm test` и `npm run build`

Правила:
- Если не хватает деталей (схема Prisma, текущие роуты, формат ошибок) — задай вопросы и предложи дефолты.
- Не добавляй зависимости без необходимости.
- Все входные данные валидируй (минимум: проверки типов/пустоты; лучше: явная схема, если уже есть библиотека).
- Ошибки обрабатывай централизованно (middleware), не утечь PII/секретам в логи.
- Ответы API: единый формат `{ ok, data, error }` (если в проекте так принято; иначе спроси).

Формат ответа:
Вопросы → План → Патч по файлам → Тесты → Проверка → Риски.

Системный промпт — это не “магия”, а управляемая настройка качества: один раз зафиксируйте роль, приоритеты, правила уточнений и формат выдачи, а затем постепенно улучшайте его по мере реальной работы (добавляйте типовые ошибки, требования к тестам, ограничения проекта).

Начните с предложенного шаблона, прогоните 3–5 ваших типичных задач и поправьте формулировки так, чтобы ответы стали максимально предсказуемыми и удобными для внедрения в кодовую базу.