# Техники промптинга

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Расширить арсенал **приёмов** помимо структуры: chain-of-thought, few-shot, роли, декомпозиция.

## Предварительно

- [Структура промпта](struktura-promta.md)

## Время

**60–90 минут**

---

## 1. Декомпозиция (разбиение)

Большую задачу делите на **независимые** подзадачи с отдельными промптами или субагентами:

```markdown
Эпик: OAuth2 login

Подзадача A: Модель User + миграция (только schema)
Подзадача B: Handler /auth/callback (только HTTP)
Подзадача C: Тесты e2e happy path
```

Каждая подзадача — свой Agent-запрос или субагент. Связь — через ваш ревью и git.

---

## 2. Chain-of-thought (CoT)

Просите **сначала рассуждение, потом код**:

```markdown
Сначала кратко (5–7 пунктов): как ты подойдёшь к задаче.
Затем реализуй только шаг 1. Остальное — после моего OK.
```

Снижает импульсивные правки во всех файлах сразу. Хорошо сочетается с **Plan mode**.

---

## 3. Few-shot (примеры)

Покажите **образец** желаемого результата:

```markdown
Добавь endpoint по образцу @internal/api/users.go (list handler).
Новый: GET /api/tags — тот же стиль ошибок и пагинации.
```

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

---

## 4. Ролевая постановка

```markdown
Ты — senior Go-разработчик, специализация HTTP middleware.
Ревьюь @handler.go на утечки context и missing error wrap.
```

Роль **не заменяет** контекст и DoD. Избегайте театра «ты лучший в мире» — давайте **конкретную** экспертизу.

В ECC роли формализованы как **agents** (`go-reviewer`, `django-reviewer`) — [раздел 06](../06-agents/README.md).

---

## 5. Негативные инструкции

Явно запретите типичные ошибки модели:

```markdown
НЕ:
- не рефакторь несвязанные файлы
- не добавляй библиотеку без согласования
- не удаляй тесты, чтобы «починить» CI
```

«НЕ» работает лучше вместе с позитивной альтернативой («используй stdlib»).

---

## 6. Контраст (A vs B)

```markdown
Сравни вариант A (session cookie) и B (JWT in header) для нашего SPA.
Критерии: безопасность, ops, мобильный клиент через год.
Рекомендация + риски. Без кода.
```

Идеально для Chat / Plan до реализации.

---

## 7. Сократический режим

Для обучения, не для скорости:

```markdown
Не давай готовый код. Задавай мне уточняющие вопросы по одному,
пока я сам не сформулирую решение для @problem.go.
```

---

## 8. Итеративное сужение

| Итерация | Техника |
|----------|---------|
| 1 | Широкий поиск: «где в проекте X?» |
| 2 | `@` найденные файлы + гипотеза |
| 3 | Fix + DoD |

Не смешивайте все три в одном гигантском промпте.

---

## 9. Spec-first

```markdown
Напиши только OpenAPI-фрагмент для POST /tags.
Без реализации. После моего OK — реализация handler + test.
```

Подходит для API и контрактов между командами.

---

## 10. Rubber duck для агента

```markdown
Объясни, как сейчас работает flow в @checkout.go, как будто я новый в команде.
Потом предложи одно улучшение с наименьшим риском.
```

Часто вскрывает неверные ваши предположения до правок.

---

## Матрица: техника → задача

| Задача | Техники |
|--------|---------|
| Bugfix | Few-shot, DoD, узкий @ |
| Новая фича | Декомпозиция, Spec-first |
| Архитектура | Контраст, CoT, Plan |
| Рефакторинг | Шаги, негативные инструкции |
| Обучение | Сократический |

---

## Практика

Возьмите одну задачу L3 и примените **три** техники из списка. Запишите, какая сэкономила больше итераций.

---

## Самопроверка

1. Когда few-shot лучше длинного описания?
2. Зачем CoT с «только шаг 1»?
3. Чем agent `planner` похож на декомпозицию в промпте?
4. Почему «ты лучший программист» — слабая роль?

## Дальше

→ [Шаблоны промптов](shablony-promtov.md)