# SOP-генератор: как AI создаёт документацию из хаоса

> Как использовать LLM для генерации Standard Operating Procedures из записей экрана, чатов и конфигов. Промпты, шаблоны и процесс от сырых данных к рабочему SOP.
> Author: Roman Belov · Published: 2026-03-11 · Source: https://futurecraft.pro/ru/blog/sop-generator-ai-documentation/

SOP (Standard Operating Procedures) — задокументированные пошаговые инструкции для повторяемых процессов. В корпорациях их создают выделенные команды. В небольших командах из 1–5 человек их не пишет никто: процесс деплоя существует в голове у одного человека, порядок запуска миграций хранится в чате трёхмесячной давности, нюансы настройки staging записаны в Loom-видео, которое никто не найдёт в нужный момент.

Это не вопрос дисциплины. Традиционное документирование процессов требует непропорционально много времени: описание 5-минутного деплоя занимает 40 минут, а через месяц половина шагов устаревает. Экономика работает против документирования, пока LLM не снижают стоимость создания документации на порядок.

Статья о том, как использовать LLM для генерации SOP из уже существующих артефактов: записей экрана, переписок, конфигов. Без отдельных «сессий документирования», без корпоративной бюрократии. Тот же подход к переиспользованию существующих данных, что и в [context engineering](/ru/blog/context-engineering-guide/) — только применённый к документации процессов.

## Почему SOP не пишутся в малых командах

**«Быстрее сделать самому, чем описывать».** Описание процесса занимает в разы больше времени, чем его выполнение. Эта арифметика работает ровно до момента, когда процесс нужно передать. Новому сотруднику, фрилансеру, или самому себе через полгода.

**«Процесс постоянно меняется».** В активной разработке всё эволюционирует. SOP, написанный вручную, устаревает за месяц. Поддержка документации становится отдельной задачей, на которую нет ресурса.

**«Все и так знают».** До первого отпуска, больничного или увольнения. Bus factor = 1. Стандартная ситуация для малых команд.

**«Это бюрократия».** Ассоциация с ISO-сертификацией и папками на 500 страниц. Но SOP для стартапа — это markdown-файл на 2 страницы, а не регламент.

LLM меняют экономику: генерация структурированной инструкции из сырых данных занимает минуты, не часы.

## Источники данных: что уже есть в команде

Ключевой принцип — не создавать новые артефакты, а переиспользовать существующие. Процессы уже объясняются коллегам в чатах, показываются на созвонах, формализуются в конфигах.

### Записи экрана и созвонов

Запись процесса через Loom или Google Meet с последующей транскрипцией (Whisper, встроенные транскриберы). Транскрипт подаётся в LLM с промптом на преобразование в пошаговую инструкцию. Выход: чистый SOP за 3–5 минут вместо ручного описания за 40.

### Чат-логи и переписки

Ответ на вопрос «как настроить staging?» в десяти сообщениях Slack — уже черновик SOP. Копирование переписки в LLM даёт структурированный документ без дополнительных усилий.

### Код и конфиги

CI/CD-пайплайн, Dockerfile, Makefile — формализованные процессы, уже записанные на языке, который LLM хорошо понимает. Модель читает `.github/workflows/deploy.yml` и генерирует человекочитаемую инструкцию: что делает каждый шаг, какие переменные окружения нужны, что проверить после выполнения.

| Тип процесса | Способ захвата | Обоснование |
|---|---|---|
| Деплой | Запись терминала (asciinema) | Точные команды, воспроизводимость |
| Онбординг | Loom-видео + транскрипт | Много визуального контекста |
| Обработка багов | Копия переписки в Slack | Артефакт уже существует |
| Обновление зависимостей | Скриншоты + заметки | Смешанный процесс (GUI + CLI) |

## Пошаговый процесс генерации SOP через LLM

### Шаг 1. Инвентаризация и приоритизация процессов

Перед документированием нужна приоритизация. Какие процессы документировать в первую очередь, определяется двумя параметрами: критичность (что произойдёт, если процесс сломается) и частота (как часто выполняется).

Промпт для приоритизации:

```
Вот список задач, которые выполняются регулярно в проекте:
- Деплой на продакшн
- Настройка нового окружения для разработчика
- Обработка баг-репортов от пользователей
- Ежемесячное обновление зависимостей
- Бэкап базы данных
- Выпуск нового релиза мобильного приложения
- Онбординг нового участника команды

Рассортируй по двум осям: критичность (что произойдёт, если процесс сломается)
и частота выполнения. Какие документировать в первую очередь?
```

Начинать стоит с пересечения «критично» и «часто». Обычно это деплой и инцидент-респонс.

### Шаг 2. Захват сырого материала

Для каждого процесса из топ-5 выбираем способ захвата из таблицы выше. Принцип: не выделять отдельное время на документирование. Запись делается прямо в момент выполнения процесса. Следующий деплой — с включённым asciinema. Следующий онбординг — с записью Loom.

### Шаг 3. Генерация SOP через LLM

Базовый промпт, дающий стабильный результат:

```
Ты — технический writer. Преобразуй сырой материал
в пошаговую инструкцию (SOP).

Правила:
- Каждый шаг начинается с глагола (Открой, Запусти, Проверь, Убедись)
- Команды терминала — в блоках кода
- Ожидаемый результат после каждого шага
- Секция "Что делать, если что-то пошло не так" в конце
- Время выполнения каждого шага
- Prerequisites: что должно быть настроено заранее

Формат: Markdown.
Уровень читателя: мидл-разработчик, знакомый с Linux и Git,
но не знакомый с этим конкретным проектом.

Сырой материал:
[транскрипт / переписка / заметки]
```

Ключевые элементы промпта: явное указание формата шагов (глагол в начале), требование ожидаемого результата после каждого шага (без этого инструкция становится неверифицируемой), и указание уровня читателя (определяет, какие вещи объяснять, а какие считать очевидными).

### Шаг 4. Верификация сгенерированного SOP

Сгенерированный документ требует проверки. Два подхода:

**Самопроверка.** Прохождение по шагам буквально. Не «ну да, это понятно», а реальное выполнение каждой команды. Пропущенный шаг или неточная формулировка обнаруживаются на первом прогоне.

**Проверка другим человеком.** Документ передаётся коллеге, не знакомому с процессом. Если выполнение прошло без вопросов — документ рабочий. Каждый вопрос — сигнал для дополнения.

### Шаг 5. Хранение и обеспечение доступности

SOP бесполезен, если его не найти в нужный момент. Основные варианты:

- **Базы знаний (Notion, Outline).** Поиск, тегирование, API для автоматизации. Каждый SOP — отдельный документ в коллекции «Operations» с тегами: `deploy`, `onboarding`, `incident-response`, `maintenance`.
- **Репозиторий.** Папка `docs/sop/` в Git. Плюс: версионирование, code review на изменения, близость к коду. Минус: нетехнические участники команды не полезут в Git.
- **CLAUDE.md / README.** Для процессов, специфичных для AI-агента или самого проекта. Деплой-чеклист, правила коммитов, структура — по сути тот же SOP, встроенный в рабочий контекст.

## Готовые шаблоны промптов по типам SOP

### Деплой и DevOps-процессы

```
На основе этого CI/CD конфига сгенерируй SOP для ручного деплоя
(на случай, если CI/CD сломался):

[YAML пайплайна]

Добавь:
- Чеклист pre-deploy проверок
- Команды для rollback
- Контакты/ссылки для эскалации
```

### Инцидент-респонс

```
Сгенерируй SOP для реагирования на инцидент в продакшне.
Контекст проекта: [стек, хостинг, мониторинг].

Структура:
1. Определение severity (P1/P2/P3)
2. Немедленные действия для каждого уровня
3. Коммуникация (кого уведомить, шаблон сообщения)
4. Диагностика (где смотреть логи, метрики)
5. Post-mortem шаблон
```

Если в проекте уже настроен мониторинг, промпт можно дополнить конкретными инструментами — как описано в статье про [observability с Langfuse](/ru/blog/llm-observability-langfuse/).

### Онбординг разработчика

```
Вот содержимое README.md и CLAUDE.md проекта:
[оба файла]

Сгенерируй SOP для онбординга нового разработчика:
- Установка окружения (пошагово, со всеми зависимостями)
- Получение доступов (список сервисов + кто выдаёт)
- Первая задача (что взять, как проверить, куда задеплоить)
- Ключевые контакты и каналы коммуникации
```

### Периодическое обслуживание

```
Вот заметки о последнем обновлении зависимостей проекта:
[заметки]

Преобразуй в ежемесячный чеклист. Добавь:
- Что проверить перед обновлением
- Порядок обновления (что сначала, что потом)
- Как протестировать после обновления
- Типичные проблемы и их решения
```

## Как поддерживать SOP в актуальном состоянии

Главная проблема SOP — устаревание. Несколько подходов к замедлению этого процесса.

**Дата ревизии в шапке документа.** Формат: `Last verified: 2026-03-15`. Если дата старше 3 месяцев — документ помечается как требующий проверки. Автоматизируется скриптом, сканирующим документы по cron.

**Обновление при выполнении.** Каждое выполнение процесса по SOP — возможность актуализировать. Заметил, что шаг 4 изменился? Правка сразу, пока контекст в голове. 30 секунд на обновление сейчас вместо полного переписывания через полгода.

**LLM для инкрементального обновления.** Старый SOP + diff изменений подаются в модель:

```
Вот текущий SOP для деплоя (написан 3 месяца назад):
[старый документ]

Вот что изменилось с тех пор:
- Перешли с Vercel на Cloudflare Pages
- Добавили шаг с IndexNow пингом
- Убрали ручной шаг с очисткой кеша (автоматизировали)

Обнови SOP, сохранив формат и стиль.
```

**Версионирование в Git.** Если SOP лежит в репозитории, каждое изменение видно в истории коммитов. Можно проследить эволюцию процесса и при необходимости откатиться.

## Что документировать, а что нет: три критерия

Типичная ошибка — начать документировать всё подряд. Три критерия для фильтрации:

1. **Повторяемость.** Процесс выполняется хотя бы раз в месяц.
2. **Передаваемость.** Процесс может и должен выполняться не только одним человеком.
3. **Критичность.** Сбой процесса наносит ощутимый урон.

Если процесс не проходит хотя бы два из трёх критериев — документировать его нерационально.

## Минимальный набор SOP для любого проекта

Пять документов, покрывающих основные риски:

1. **Деплой на продакшн** — включая rollback-процедуру
2. **Инцидент-респонс** — от определения severity до post-mortem
3. **Доступы и секреты** — где что хранится, как получить, как ротировать
4. **Онбординг** — от нуля до первого коммита
5. **Периодическое обслуживание** — бэкапы, обновления, мониторинг

Для edge-функций и serverless, где деплой-процесс специфичен, полезно добавить отдельный SOP с учётом паттернов вроде [circuit breaker](/ru/blog/circuit-breaker-deno-edge-functions/).

## Инструменты для создания и хранения SOP

| Инструмент | Роль в процессе |
|---|---|
| Claude / ChatGPT | Генерация SOP из сырых данных |
| Loom | Запись процессов с экрана |
| Whisper | Транскрипция аудио/видео |
| Outline / Notion | Хранение и поиск |
| Git | Версионирование SOP рядом с кодом |
| asciinema | Запись терминальных сессий |

## Типичные ошибки при AI-генерации SOP

**Галлюцинации в сгенерированных шагах.** LLM может добавить шаг, которого нет в исходном материале, или указать несуществующий флаг команды. Верификация обязательна: каждый сгенерированный SOP проходится вручную хотя бы один раз.

**Избыточная детализация.** Модель может разложить тривиальное действие на пять подшагов. Уровень детализации нужно калибровать под целевого читателя: мидл-разработчику не нужно объяснять, как открыть терминал.

**Контекстозависимые процессы.** Некоторые процессы зависят от состояния системы, и линейная инструкция не работает. В таких случаях помогает формат decision tree: «Если X — шаг A; если Y — шаг B».

**Ложное чувство безопасности.** Наличие SOP не гарантирует, что его прочитают. Документ должен быть доступен в момент, когда он нужен: в README проекта, в закреплённом сообщении канала, в CLAUDE.md.

## С чего начать уже сегодня

1. Выбрать один критичный процесс. Обычно это деплой на продакшн.
2. При следующем выполнении включить запись (asciinema для терминала, Loom для GUI).
3. Скормить запись/транскрипт в LLM с промптом из раздела «Генерация SOP».
4. Пройти по сгенерированному документу, выполняя каждый шаг буквально.
5. Исправить неточности, сохранить в доступном месте.
6. Повторить для следующего процесса из списка приоритетов.

По 15–20 минут на процесс. Пять процессов — полтора часа. После этого критичные знания перестают быть привязаны к одному человеку.

---

*Нужна помощь с автоматизацией документации и операционных процессов? Я помогаю стартапам внедрять AI-решения и строить продукты — [belov.works](https://belov.works).*