# Инструкция устарела за месяц: как с этим жить

Сервисы меняются быстрее, чем обновляются документы про них: раздел переименовали, скриншот врёт. Разбираю, как писать инструкцию, которая переживёт редизайн.

URL: https://posts.danashkin.ru/guides/instrukciya-ustarela-za-mesyac
Обновлено: 2026-09-17

---

## Коротко

**Главное**

- Инструкция по работе с нейросетью устаревает быстрее, чем ты успеваешь её согласовать. За один прогон обучения у меня разошлись с реальностью два пункта из материалов: раздел меню переименовали, а нужной команды в тексте не было вовсе.
- Скриншот интерфейса - расходник, а не содержание. Он живёт месяцы, а иногда недели, и планировать его надо как расходник.
- Лечится не частотой обновлений, а сменой единицы описания: инструкция про смысл действия живёт годами, инструкция про расположение кнопки - до ближайшего обновления.
- Дата рядом с разделом стоит дороже, чем кажется: она превращает расхождение из «инструкция врёт» в «этот кусок написан в марте, проверь».
- Человек, наткнувшийся на несовпадение, по умолчанию винит себя и молчит. Это главная скрытая цена устаревшего текста.

## Что устаревает быстрее всего?

**Главное**

Названия пунктов меню, расположение настроек и скриншоты. Медленнее - последовательность шагов. Ещё медленнее - принципы, по которым принимается решение. Чем ближе описание к пикселям, тем короче его жизнь.

Случай, после которого я поменял подход к материалам обучения.

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

Второй клиент, другая программа, тот же эффект. Стало ясно, что это не случайность, а свойство: интерфейсы сервисов меняются чаще, чем обновляются документы про них.

Разложим по скорости устаревания:

| Что описано | Живёт | Пример |
|---|---|---|
| Расположение кнопки и вид экрана | недели | «нажми в правом верхнем углу» |
| Название пункта меню | месяцы | раздел переименовали одним обновлением |
| Порядок шагов | год и больше | сначала настроить, потом подключить |
| Принцип выбора | годы | что отдавать агенту, а что делать руками |

Отсюда простое следствие: если инструкция состоит в основном из первых двух строк таблицы, она обречена. Не потому что написана плохо, а потому что описывает самое подвижное.

## Почему это не лечится «обновлять чаще»

**Главное**

Потому что скорость изменений выше скорости согласований. Пока документ проходит правку и утверждение, интерфейс меняется снова, и команда получает свежий по дате и старый по сути текст.

Первая реакция на проблему всегда одинаковая: назначим ответственного, будем обновлять раз в месяц.

На практике это не работает по трём причинам.

- **Изменения приходят пачками и без предупреждения.** Обновление сервиса выходит тогда, когда выходит, а не по твоему графику.
- **Обновление документа стоит дороже, чем кажется.** Переснять скриншоты, проверить каждый шаг, согласовать - это часы, а не минуты.
- **Устаревшую версию продолжают читать.** У людей на руках скачанный файл, распечатка, копия в мессенджере. Обновление центральной версии их не догоняет.

Вывод, к которому я пришёл: бороться надо не за свежесть, а за устойчивость. То есть писать так, чтобы устаревало меньше.

Кстати, ровно тот же принцип я держу в статьях: где тема протухающая - цены, тарифы, ограничения сервисов, - стоит блок «актуально на дату» и обязательство сверять раз в квартал. Читатель видит дату сразу и понимает, чему верить. Пример такой темы - разбор про то, [какую нейросеть выбрать под задачу](/guides/kakuyu-neyroset-vybrat-pod-zadachu): состав сервисов там меняется каждые несколько месяцев.

## Как писать инструкцию, чтобы она жила дольше?

**Главное**

Описывать намерение, а не траекторию мыши. «Открой настройки доступа» переживёт три редизайна, «нажми шестерёнку справа сверху, потом третий пункт» не переживёт ни одного. Скриншот при этом остаётся, но как иллюстрация, а не как инструкция.

Приём, который я применяю ко всем материалам.

1. **Сначала цель шага**

   «Нужно разрешить агенту работать без подтверждения каждого действия». Человек понимает, что он делает и зачем, даже если экран выглядит иначе.

2. **Потом путь, словами**

   «Это в настройках, в разделе про разрешения». Название раздела может измениться, но смысл поиска сохранится.

3. **Потом картинка, отдельно**

   Скриншот идёт последним и подписывается датой. Когда он устареет, шаг всё ещё останется выполнимым.

4. **И признак успеха**

   «После этого агент перестанет спрашивать разрешение на каждый файл». Человек проверяет результат, а не совпадение с картинкой.

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

Есть и приём для совсем подвижных мест: не описывать их вообще, а отдавать [агенту](/concepts/ai-agent) вопросом. «Подскажи, где сейчас в этом сервисе настройка такая-то» - ответ будет актуальнее любого документа. Про то, как вообще формулировать такие запросы, разбирал в материале про то, [когда с агентом говорят командой, а когда обычной речью](/guides/komanda-ili-obychnaya-rech-s-agentom).

## Дата рядом с разделом и её эффект

**Главное**

Рядом с каждым разделом, который завязан на внешний сервис. Дата не делает текст свежее, но меняет отношение к расхождению: человек понимает, что смотрит на снимок момента, и проверяет, а не бросает.

Мелочь, которая меняет поведение читателя.

Документ без даты воспринимается как истина. Наткнувшись на несовпадение, человек думает одно из двух: либо инструкция врёт целиком, либо он всё делает не так. Оба вывода плохие.

Документ с датой воспринимается как снимок. Расхождение перестаёт быть катастрофой: понятно, что раздел написан в марте, а на дворе сентябрь, и надо просто поискать чуть иначе.

Что стоит датировать:

- Разделы про интерфейсы внешних сервисов.
- Всё, где есть цены, тарифы и лимиты.
- Списки инструментов и их возможностей.
- Скриншоты, каждый по отдельности.

Правило, которое я держу в своих проектах: меняющиеся значения не вписываются в текст вручную. Цены, лимиты, названия тарифов живут в одном месте, откуда их берут все документы. Тогда обновление делается однажды, а не поиском по десяти файлам.

## Что делать, когда человек пришёл с расхождением?

**Главное**

Поблагодарить и починить в тот же день. Расхождение, о котором сказали вслух, - подарок: на каждого сказавшего приходится несколько тех, кто споткнулся и промолчал, решив, что дело в нём.

Самое дорогое в устаревшей инструкции - не сама ошибка, а реакция человека на неё.

Наблюдение с обучений: ученик, наткнувшийся на несовпадение, по умолчанию винит себя. Он не пишет «у вас ошибка в материалах», он думает «я что-то делаю не так» и идёт разбираться в одиночку. Иногда возвращается через неделю с фразой «а вот этого в инструкции не было».

**Фраза, которую стоит писать в начале любой инструкции**

«Сервисы меняются. Если экран выглядит иначе, чем на картинке, - это нормально, напиши мне, поправлю. Ориентируйся на цель шага, она указана первой строкой».

Порядок работы с расхождениями:

1. Записать в одно место - список несоответствий, а не переписка в чате.
2. Поправить текст сразу, если правка на одну строку.
3. Пересъёмку картинок копить и делать пачкой раз в период.
4. Сказать людям, что поправлено. Иначе в следующий раз промолчат.

Барьер тут не технический, а человеческий, и он из того же ряда, что и другие барьеры внедрения: люди не сообщают о проблемах, пока не уверены, что это не их вина. Разбирал эту механику в материале про [три барьера внедрения ИИ в команде](/guides/tri-barera-vnedreniya-ii-v-komande).

## Ритм пересмотра: раз в квартал и по событию

**Главное**

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

Календарный ритм нужен, чтобы документ не гнил незаметно. Событийный - чтобы не ждать три месяца, когда всё уже сломалось.

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

Второй триггер важнее первого. Одно сообщение о расхождении может быть частным случаем, второе о том же месте - точная гарантия, что там сломано. Пороговое правило простое: два обращения об одном и том же означают, что чинить надо не человека, а текст.

И последнее наблюдение. Материал, вырезанный из инструкции после того, как его показали вживую, находится людьми обязательно. Человек помнит, что видел приём на занятии, ищет его в тексте, не находит и делает вывод, что упустил сам. Если что-то убрал - скажи, что убрал и почему. Это дешевле, чем разбираться с недоверием к документу целиком. Тот же принцип работает и с файлом-памятью проекта, где устаревшая строка живёт до тех пор, пока её не удалят руками: [что писать в файл-память](/guides/chto-pisat-v-claude-md).

## Частые вопросы

**Главное**

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

### Частые вопросы

**Может, вообще не вставлять скриншоты?**

Вставлять, но как иллюстрацию к описанному словами шагу. Картинка снимает тревогу у новичка, а инструкцией работает текст.

**Есть ли смысл писать инструкции, если всё так быстро меняется?**

Есть, если писать про смысл действий и порядок, а не про интерфейс. Такие материалы живут годами и как раз составляют ценность.

**Кто должен обновлять документ?**

Один человек с правом удалять устаревшее. Коллективная ответственность за текст приводит к тому, что в нём копятся слои разных лет.

**Что делать с копиями, которые люди скачали?**

Смириться и снизить цену вопроса: ставить дату прямо в заголовке файла и хранить актуальную версию в одном месте, ссылку на которое дают вместо файла.

## Главный вывод

**Главное**

Инструкции про нейросети устаревают не потому, что их плохо пишут, а потому что описывают самое подвижное. Смена единицы описания с расположения кнопки на цель шага продлевает жизнь документа в разы.

Запомнить стоит одно: скриншот - расходник, смысл действия - актив. Расходники планируют и списывают, активы поддерживают.

Практический минимум на сегодня: открой свою рабочую инструкцию и посмотри, с чего начинается каждый шаг. Если с описания экрана, а не с цели, - вот и вся причина, по которой её приходится переписывать каждый квартал.

А сколько людей в твоей команде уже споткнулись об устаревший пункт и решили, что дело в них?

### Источники

- [Software rot - почему техническое описание портится со временем, Википедия](https://en.wikipedia.org/wiki/Software_rot)
- [Technical documentation - жанр технической документации, Википедия](https://en.wikipedia.org/wiki/Technical_documentation)
- [Deprecation - как объявляют устаревшими функции и версии, Википедия](https://en.wikipedia.org/wiki/Deprecation)
- [Models overview - список актуальных моделей в документации Claude](https://platform.claude.com/docs/en/models/overview)