Анатомия рабочего промта для Solar LLM: схема, шаги и готовые шаблоны

Анатомия рабочего промта для Solar LLM

Solar отлично следует инструкциям, если задать чёткую иерархию: роль → контекст → задача → формат → ограничения. Материал разбирает структуру, даёт пошаговый алгоритм и готовые шаблоны для типовых задач.

Структура Примеры Шаблоны

Большинство неудовлетворительных ответов Solar возникает не из-за ограничений модели, а из-за неявного промта. Модель не «думает» за вас — она исполняет инструкцию. Чем точнее описаны роль, входные данные и критерии результата, тем меньше свободы для галлюцинаций.

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

Пять слоёв качественного промта

Представьте промт как вложенные кольца. В центре — суть задачи, вокруг — слои контекста, которые сужают пространство решений до единственно верного.

Роль (Persona). Кто отвечает: старший разработчик, технический редактор, аналитик данных. Это загружает релевантные паттерны обучения.
Контекст (Context). Входные данные, предыстория, ограничения окружения. Всё, что модель не знает сама.
Задача (Task). Чёткий глагол действия: «напиши», «проанализируй», «преобразуй», «классифицируй». Без лишних слов.
Формат (Format). Markdown, JSON, XML, таблица, буллеты. Указание схемы вывода исключает «разговорчивость».
Ограничения (Constraints). Длина, тон, запреты, обязательные элементы. Границы допустимого.

Визуальная модель: задача в центре, роль задаёт внешнюю границу

Разбор каждого компонента

Роль (Persona)

Определяет «голос» и базу знаний. Solar имеет сильные веса на коде и технических текстах. Роль «Senior TypeScript Engineer» даст другой код, чем «Fullstack Newbie».

Role: Senior Rust Engineer, expert in async runtimes and memory safety.

Контекст (Context)

Вставляйте код, логи, выдержки из документации, пользовательские сценарии. Solar поддерживает большой контекст — используйте это. Разделяйте блоки разметкой ### INPUT / ### DOCS.

Context: Legacy Python 3.8 codebase, no type hints, sync HTTP calls. Target: Python 3.11 + asyncio + aiohttp.

Задача (Task)

Один императив. Не «посмотри на код и, если есть время, исправь баги», а «Найди и исправь все места, где блокирующий I/O вызывается в async-функции».

Task: Refactor sync HTTP calls to async aiohttp. Preserve public API signatures.

Формат (Format)

Жёсткая спецификация вывода. Для парсинга — JSON Schema. Для чтения — Markdown с заголовками. Для кода — только файл(ы) без пояснений.

Format: Unified diff (git apply). No markdown fences. No commentary.

Ограничения (Constraints)

Отрицательные условия работают лучше позитивных: «Не используй regex», «Не меняй сигнатуры», «Максимум 80 символов в строке». Это режет хвосты распределения.

Constraints: Zero external deps. Keep cyclomatic complexity < 10 per function. No regex.

Алгоритм сборки: 5 шагов от идеи к рабочему промту

Сформулируйте цель

Одна фраза: что должно появиться на выходе, чего не было на входе.

Назначьте эксперта

Подберите роль, которая решает такую задачу профессионально. Добавьте уровень сеньорности.

Соберите досье

Скопируйте код, логи, требования, примеры в/вы. Разметьте заголовками. Уберите шум.

Жёстко задайте форму

JSON Schema, Markdown-структуру, diff-формат, список файлов. Solar точно следует синтаксису.

Прогоните тест

Запустите промт. Если результат рядом — доработайте Constraints. Если далеко — проверьте Context и Role.

Разбор полётов: как не надо и как надо

Антипаттерн: размытый промт

# Плохо
Сделай код лучше и быстрее.
Вот файл:
[вставлен код на 500 строк]

Пожалуйста, не ломай ничего.

✗ Нет роли — модель угадывает уровень экспертизы.
✗ «Лучше и быстрее» — субъективно, не измеримо.
✗ Контекст не размечен — код смешивается с инструкцией.
✗ Формат не задан — получим разговорный ответ с пояснениями.
✗ «Не ломай» — негативная инструкция без критериев.

Паттерн: структурированный промт

### ROLE
Senior Performance Engineer. Expert in Python asyncio, profiling, memory optimization.

### CONTEXT
Service handles 5k RPS. Current p99 latency 1.2s. Target p99 < 300ms.
Bottleneck: synchronous PostgreSQL calls in async handlers (see code below).

### CODE
```python
[code snippet ~80 lines]
```

### TASK
Refactor DB layer to asyncpg with connection pooling. Keep handler signatures.
Add retry logic with exponential backoff (max 3 attempts).

### FORMAT
Unified diff for files: db.py, pool.py, handlers/*.py.
No markdown, no commentary.

### CONSTRAINTS
- Zero blocking calls in async functions.
- Pool size: CPU * 4.
- Preserve existing transaction semantics.
- Type hints mandatory (Python 3.11).

✓ Роль загружает релевантные паттерны asyncpg.
✓ Контекст даёт метрики и локализует проблему.
✓ Задача — императивы с конкретными библиотеками.
✓ Формат — diff, готовый к git apply.
✓ Ограничения — измеримые технические требования.

Готовые шаблоны: копируйте и адаптируйте

Шаблон: Code Review & Refactor

### ROLE
Principal Software Architect. Language: {LANG}. Focus: {FOCUS: performance / readability / security}.

### CONTEXT
Project: {PROJECT_TYPE}. Constraints: {CONSTRAINTS}.
Codebase style: {STYLE_GUIDE_LINK_OR_DESC}.

### CODE
```{LANG}
{CODE_SNIPPET}
```

### TASK
1. Identify code smells, anti-patterns, {FOCUS} issues.
2. Propose refactored version.
3. Explain why each change improves {FOCUS}.

### FORMAT
Markdown table:
| Line | Issue | Severity | Fix | Reason |

Then full refactored file in ```{LANG}``` fence.

### CONSTRAINTS
- Do not change public API.
- Max line length: {LINE_LENGTH}.
- Preserve test coverage.
- No external deps unless justified.

Шаблон: Structured Data Extraction (JSON)

### ROLE
Data Extraction Specialist. Output: valid JSON only.

### CONTEXT
Source: {SOURCE_TYPE: email / log / doc / html}.
Domain: {DOMAIN}.

### INPUT
{RAW_TEXT_OR_DOCUMENT}

### TASK
Extract entities matching schema. Normalize values (dates → ISO 8601, amounts → float, enums → UPPER_SNAKE).
If field missing → null. If ambiguous → most likely value + "_confidence": 0.x.

### FORMAT
Strict JSON matching this JSON Schema:
```json
{SCHEMA_DEFINITION}
```

### CONSTRAINTS
- No markdown, no commentary, no preamble.
- Single JSON object or array at root.
- Escape control chars.
- Max output tokens: {MAX_TOKENS}.

Шаблон: Decision Support / Trade-off Analysis

### ROLE
Staff Engineer. Pragmatic, bias for boring technology, aware of operational cost.

### CONTEXT
Current stack: {STACK}.
Team size: {TEAM_SIZE}. Expertise: {EXPERTISE}.
Traffic: {RPS} RPS, {DATA_VOL}.
Decision: {DECISION_TOPIC: e.g., migrate to Kubernetes / choose message queue / rewrite module}.

### TASK
Analyze {N: 3-5} viable options. For each:
1. Architecture fit.
2. Operational complexity (1-5).
3. Migration effort (person-weeks).
4. Risk profile.
5. Cost estimate (infra + engineering).
Recommend ONE with justification.

### FORMAT
Markdown:
## Recommendation: {OPTION}
## Comparison Table
| Option | Fit | Ops | Effort | Risk | Cost |
## Detailed Analysis per Option
...

### CONSTRAINTS
- No vendor lock-in unless critical.
- Prefer managed services.
- Must run in {CLOUD/ONPREM}.
- Decision reversible in < 4 weeks if wrong.

Промт — это код на естественном языке

Сolar не «понимает» в человеческом смысле. Он предсказывает продолжение последовательности токенов, максимально вероятное при заданном префиксе. Ваша задача — сделать правильное продолжение единственно возможным.

ПринципЯвное лучше неявного. Конкретное лучше абстрактного. Измеримое лучше качественного.

ПривычкаСохраняйте библиотеку проверенных промтов. Версионируйте их. Делитесь с командой. Промт-инжиниринг — это разработка.

РезультатПредсказуемый, детерминированный (в пределах temperature), готововый к использованию артефакт, а не черновик для доработки.

Анатомия рабочего промта для Solar LLM: схема, шаги и готовые шаблоны