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

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

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

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

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

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

«Процесс постоянно меняется». В активной разработке всё эволюционирует. 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.

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

Вот содержимое 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.

Инструменты для создания и хранения 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 минут на процесс. Пять процессов — полтора часа. После этого критичные знания перестают быть привязаны к одному человеку.