Технический писатель, который освоил нейросети, пишет за день то, на что раньше уходила неделя. Звучит как реклама? Это просто статистика тех, кто уже попробовал. Промпты для технического писателя – не волшебная кнопка, но очень близко к ней, если знать, как их составлять.
В этой статье – 30 готовых рабочих запросов для нейросети, которые закрывают реальные задачи: от написания технических заданий до создания пользовательских инструкций и API-документации. Никаких абстракций – только конкретные тексты промптов, которые можно скопировать и использовать прямо сейчас.
Какие задачи здесь закрыты:
- Написание и структурирование технической документации
- Создание пользовательских руководств и инструкций
- Описание программных интерфейсов и технических спецификаций
- Редактура и упрощение сложных технических текстов
- Составление технических заданий и требований
- Перевод технического языка на понятный для конечного пользователя
- Создание шаблонов, стандартов и регламентов документирования
30 промптов для технического писателя: готовые запросы для нейросети
1. Написание пользовательской инструкции с нуля
Проблема: Технический писатель получает от разработчиков сырые описания функций – без структуры, без учета пользователя. Превратить это в понятную инструкцию с нуля занимает много времени.
Решение: Промпт создает полноценную пошаговую инструкцию для конечного пользователя на основе технического описания функционала.
Текст промпта:
*****
Ты – опытный технический писатель, специализирующийся на создании пользовательской документации для программных продуктов.
Задача: напиши пошаговую пользовательскую инструкцию по работе с функцией или продуктом на основе предоставленного технического описания.
Контекст: [опишите продукт или функцию, например, “модуль загрузки файлов в корпоративной системе документооборота”] предназначен для [укажите целевую аудиторию, например, “сотрудников бухгалтерии без технического образования”]. Уровень технической грамотности пользователей – [укажите уровень, например, “базовый: умеют пользоваться почтой и браузером”]. Техническое описание функции: [вставьте техническое описание от разработчиков].
Формат ответа:
– Краткое введение: что делает функция и зачем она нужна (2–3 предложения)
– Пошаговая инструкция с нумерацией (каждый шаг – одно действие)
– Для каждого шага: что нужно сделать и что произойдет после
– Раздел “Частые вопросы”: 3–5 типичных затруднений и решений
– Раздел “Внимание”: предупреждения об ошибках, которые нельзя совершать
Ограничения: не используй технический жаргон и аббревиатуры без расшифровки, не пиши длинные абзацы – только короткие четкие шаги, избегай пассивного залога.
Тон: нейтральный, уважительный, как в официальном руководстве крупного российского банка.
*****
Почему это работает: Промпт задает аудиторию и ее уровень, поэтому нейросеть автоматически адаптирует язык. Структура с разделом “Частые вопросы” убирает необходимость дополнительного итерирования.
2. Упрощение технического текста для неспециалистов
Проблема: Разработчики пишут документацию для себя – с терминами, аббревиатурами и предполагаемым знанием контекста. Конечный пользователь такой текст не понимает вовсе.
Решение: Промпт перерабатывает технический текст в понятный язык без потери смысла и точности.
Текст промпта:
*****
Ты – технический редактор с опытом адаптации сложных текстов для широкой аудитории.
Задача: перепиши предоставленный технический текст так, чтобы его понял человек без специального образования, сохранив при этом всю важную информацию.
Контекст: исходный текст написан для [укажите исходную аудиторию, например, “системных администраторов”]. Целевая аудитория переработанного текста – [укажите новую аудиторию, например, “руководители отделов, принимающие решение о внедрении системы”]. Исходный текст: [вставьте текст для переработки].
Логика действий:
- Выяви все термины и аббревиатуры – замени понятными словами или добавь расшифровку в скобках
- Разбей длинные предложения на короткие (не более 20 слов)
- Замени пассивный залог на активный
- Добавь конкретные примеры там, где есть абстрактные утверждения
- Сохрани все цифры, сроки и технические параметры – они важны
Формат ответа: переработанный текст, после него – список из 5–7 замен (что было → что стало), чтобы можно было проверить качество адаптации.
Ограничения: не упрощай до потери точности, не удаляй важные ограничения и предупреждения, не добавляй информацию, которой не было в исходном тексте.
Тон: деловой, доступный, без снисхождения к читателю.
*****
Почему это работает: Пошаговая логика внутри промпта заставляет нейросеть последовательно обрабатывать каждую проблему текста. Список замен в конце позволяет быстро проверить результат.
3. Составление технического задания на разработку
Проблема: Техническое задание, написанное “на словах” или в виде хаотичного списка пожеланий, приводит к тому, что разработчики делают не то, что имелось в виду. Переделки обходятся дорого.
Решение: Промпт структурирует сырые требования в полноценное техническое задание по стандартной структуре.
Текст промпта:
*****
Ты – технический писатель с опытом составления технических заданий для IT-проектов в соответствии с российскими стандартами документирования.
Задача: на основе предоставленных сырых требований составь структурированное техническое задание.
Контекст: проект – [опишите проект, например, “разработка личного кабинета для клиентов страховой компании”]. Заказчик – [укажите тип заказчика, например, “внутренний, отдел маркетинга”]. Исполнитель – [укажите исполнителя, например, “внешняя команда разработки на аутсорсе”]. Сырые требования: [вставьте список пожеланий, обсуждений или описаний].
Формат ответа – техническое задание со следующими разделами:
- Общие сведения о проекте (цель, назначение, участники)
- Описание текущей ситуации и проблемы
- Функциональные требования (что система должна делать)
- Нефункциональные требования (производительность, безопасность, совместимость)
- Ограничения и допущения
- Критерии приемки результата
Ограничения: каждое требование формулируй как проверяемое утверждение (можно ответить “выполнено / не выполнено”), не используй размытые слова “удобный”, “быстрый”, “современный” без конкретных параметров.
Тон: официальный, точный, как в документации для государственного тендера.
*****
Почему это работает: Требование формулировать каждый пункт как проверяемое утверждение – ключевое. Это автоматически устраняет главную болезнь технических заданий – расплывчатость.
4. Написание описания программного интерфейса (API)
Проблема: Документация к программным интерфейсам часто либо слишком краткая (“метод делает X”), либо написана так, что понять ее может только тот, кто его и создал.
Решение: Промпт создает полное описание одного метода или группы методов по стандартной структуре технической документации.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на документировании программных интерфейсов для разработчиков.
Задача: напиши полное описание метода (или группы методов) программного интерфейса на основе предоставленных технических данных.
Контекст: интерфейс относится к системе [укажите систему, например, “платежный шлюз для интернет-магазинов”]. Аудитория документации – [укажите аудиторию, например, “разработчики на стороне клиента, интегрирующие оплату”]. Технические данные о методе: [вставьте описание метода, параметры, коды ответов].
Формат ответа для каждого метода:
– Название и краткое описание (одно предложение)
– Назначение: когда и зачем вызывается этот метод
– Параметры запроса: таблица с полями (название, тип, обязательность, описание, пример значения)
– Структура ответа: таблица с полями ответа
– Коды ошибок: таблица (код, описание, возможная причина)
– Пример запроса и ответа в виде блока кода
– Важные замечания и ограничения
Ограничения: не придумывай параметры или коды, которых нет в исходных данных, все примеры значений должны быть реалистичными, не используй первое лицо.
Тон: технически точный, нейтральный, без лишних слов.
*****
Почему это работает: Таблицы как обязательный элемент формата заставляют нейросеть структурировать информацию, а не писать ее сплошным текстом – что является главным требованием к документации интерфейсов.
5. Создание глоссария технических терминов
Проблема: В документации одни и те же понятия называются по-разному в разных разделах. Пользователь теряется, а новые сотрудники тратят время на выяснение, что имелось в виду.
Решение: Промпт создает единый глоссарий терминов для конкретного продукта или проекта.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на стандартизации терминологии в корпоративной документации.
Задача: составь глоссарий технических терминов для документации на основе предоставленных материалов.
Контекст: продукт или проект – [опишите продукт, например, “система управления складом для розничной сети”]. Аудитория документации – [укажите аудиторию, например, “кладовщики и менеджеры склада”]. Исходные материалы с терминами: [вставьте тексты, из которых нужно извлечь и стандартизировать термины].
Логика действий:
- Выдели все термины, которые могут быть непонятны целевой аудитории
- Для каждого термина: дай определение в 1–2 предложениях простым языком
- Укажи синонимы и смежные термины, которые используются в документации
- Отметь термины, которые в данном продукте имеют специфическое значение (отличное от общепринятого)
Формат ответа: алфавитный список терминов. Каждая запись: термин (жирным) – определение – синонимы (если есть) – примечание (если термин используется нестандартно).
Ограничения: определения не должны содержать других сложных терминов без их расшифровки, не копируй определения из интернета – адаптируй под контекст продукта.
Тон: нейтральный, точный, без лишних слов.
*****
Почему это работает: Требование отмечать термины с нестандартным значением – критически важная деталь. Именно такие термины вызывают больше всего путаницы, и нейросеть без явного указания их просто пропустит.
6. Написание раздела “Часто задаваемые вопросы” для документации
Проблема: Раздел с вопросами и ответами либо содержит очевидное (“как войти в систему?”), либо написан так, что ответы снова требуют объяснения. Пользователи все равно обращаются в поддержку.
Решение: Промпт создает содержательный раздел часто задаваемых вопросов на основе реальных обращений или описания функционала.
Текст промпта:
*****
Ты – технический писатель с опытом работы в службе поддержки пользователей и создания самообслуживающей документации.
Задача: составь раздел “Часто задаваемые вопросы” для документации продукта.
Контекст: продукт – [опишите продукт, например, “мобильное приложение для записи к врачу в частной клинике”]. Целевая аудитория – [укажите аудиторию, например, “пациенты от 30 до 65 лет”]. Источник для формирования вопросов: [выберите и укажите – “реальные обращения в поддержку: [вставьте список]” или “описание функционала: [вставьте описание]”].
Логика действий:
- Сформулируй вопросы так, как их задает пользователь (не разработчик)
- Сгруппируй вопросы по темам (авторизация, основные функции, ошибки, оплата и т.д.)
- Для каждого ответа: дай решение, а не описание проблемы
- Если решение зависит от ситуации – дай несколько вариантов с условиями
Формат ответа: тематические группы с заголовками, в каждой группе – вопрос (жирным) и ответ под ним. Общий объем: [укажите нужное количество вопросов, например, “15–20 вопросов”].
Ограничения: не добавляй вопросы ради объема, каждый вопрос должен закрывать реальную проблему, ответы – не длиннее 5–6 предложений.
Тон: дружелюбный, помогающий, без технического жаргона.
*****
Почему это работает: Формулировка вопросов “как их задает пользователь, а не разработчик” – принципиальное требование, которое меняет весь характер раздела. Без этого указания нейросеть пишет вопросы с точки зрения системы, а не человека.
7. Составление регламента документирования для команды
Проблема: Когда в команде нет единого стандарта документирования, каждый пишет по-своему. В итоге документация выглядит как лоскутное одеяло и требует постоянной правки.
Решение: Промпт создает внутренний регламент документирования, которому может следовать вся команда.
Текст промпта:
*****
Ты – ведущий технический писатель, отвечающий за стандарты документирования в IT-компании.
Задача: разработай регламент документирования для команды на основе предоставленных требований и контекста.
Контекст: компания – [опишите компанию, например, “разработчик корпоративного программного обеспечения для логистики, 50 человек”]. Типы создаваемой документации – [перечислите, например, “технические задания, пользовательские инструкции, описания обновлений”]. Текущие проблемы с документацией – [опишите проблемы, например, “разный стиль у разных авторов, нет единой структуры разделов, термины используются непоследовательно”]. Инструменты, которые использует команда – [укажите, например, “Confluence, Google Документы”].
Формат ответа – регламент со следующими разделами:
- Принципы документирования (3–5 ключевых правил)
- Стандарты структуры для каждого типа документа
- Правила языка и стиля (что использовать, что запрещено)
- Правила работы с терминами и сокращениями
- Процесс проверки и утверждения документов
- Ответственность: кто создает, кто проверяет, кто утверждает
Ограничения: регламент должен быть практичным и выполнимым, не перегружай правилами – лучше 10 четких, чем 50 размытых, каждое правило должно быть проверяемым.
Тон: официальный, но не бюрократический – люди должны захотеть следовать этому документу.
*****
Почему это работает: Указание текущих проблем – ключевой контекст. Нейросеть создает регламент, направленный именно на устранение реальных болей команды, а не абстрактный набор правил.
8. Описание обновления продукта для пользователей
Проблема: Записи об обновлениях (“changelog”) пишут разработчики для разработчиков. Пользователи не понимают, что изменилось и зачем им это нужно.
Решение: Промпт превращает технический список изменений в понятное описание обновления, ориентированное на пользу для пользователя.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на коммуникации обновлений продукта пользователям.
Задача: перепиши технический список изменений в версии продукта в понятное описание обновления для конечных пользователей.
Контекст: продукт – [опишите продукт, например, “система управления задачами для малого бизнеса”]. Аудитория – [укажите аудиторию, например, “владельцы малого бизнеса и их администраторы”]. Технический список изменений: [вставьте список изменений от разработчиков]. Версия и дата выпуска: [укажите, например, “версия 3.2, выпуск 15 ноября”].
Логика действий:
- Для каждого изменения: сформулируй не что изменилось технически, а что теперь может делать пользователь или что стало лучше
- Сгруппируй изменения: новые возможности / улучшения / исправления ошибок
- Выдели 2–3 главных изменения, которые больше всего повлияют на работу пользователей
- Исправления критических ошибок опиши без технических деталей, но с указанием симптома, который теперь исчез
Формат ответа: заголовок с версией и датой, краткое вступление (2–3 предложения о главном), три раздела по группам изменений.
Ограничения: не используй технические термины без объяснения, не пиши “исправлен баг” – пиши “устранена проблема, при которой…”.
Тон: позитивный, деловой, ориентированный на пользу.
*****
Почему это работает: Переформулировка с “что изменилось технически” на “что теперь может делать пользователь” – это принципиальный сдвиг фокуса, который нейросеть без явного указания не делает.
9. Написание технической спецификации требований
Проблема: Требования к системе часто существуют в виде разрозненных переписок, презентаций и устных договоренностей. Когда приходит время разработки, никто не помнит, что именно было согласовано.
Решение: Промпт структурирует разрозненные требования в формальную спецификацию, которая служит единым источником правды для всей команды.
Текст промпта:
*****
Ты – технический писатель с опытом составления спецификаций требований для IT-проектов.
Задача: составь спецификацию требований к системе на основе предоставленных материалов.
Контекст: система – [опишите систему, например, “модуль отчетности для корпоративной ERP-системы”]. Заинтересованные стороны – [перечислите, например, “финансовый директор, главный бухгалтер, IT-отдел”]. Исходные материалы: [вставьте переписку, протоколы встреч, презентации или описания].
Формат ответа – спецификация требований:
- Назначение документа и область применения
- Заинтересованные стороны и их роли
- Функциональные требования (с уникальными идентификаторами: ФТ-001, ФТ-002…)
- Нефункциональные требования (производительность, безопасность, доступность)
- Ограничения системы
- Допущения и зависимости
- Открытые вопросы, требующие уточнения
Ограничения: каждое требование должно быть атомарным (одна мысль – один пункт), проверяемым (можно ответить “выполнено / нет”), без двусмысленных формулировок. Если в исходных материалах есть противоречия – вынеси их в раздел “Открытые вопросы”.
Тон: официальный, точный, без интерпретаций – только то, что явно следует из исходных материалов.
*****
Почему это работает: Уникальные идентификаторы требований (ФТ-001 и т.д.) – не формальность. Они позволяют ссылаться на конкретные требования в переписке и тестировании, что делает документ реально рабочим инструментом.
10. Создание шаблона для документации проекта
Проблема: Каждый раз, начиная новый проект, команда тратит время на придумывание структуры документации заново. Результат – каждый проект документируется по-разному.
Решение: Промпт создает готовый шаблон документации с заполненными разделами-образцами, который можно использовать повторно.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на создании корпоративных шаблонов документации.
Задача: создай шаблон документа для [укажите тип документа, например, “проектной документации IT-проекта” или “технического описания функции”].
Контекст: шаблон будет использоваться в [опишите контекст, например, “команде из 8 разработчиков и 2 аналитиков, работающих по гибкой методологии”]. Типичные проекты команды – [опишите, например, “разработка модулей для корпоративной системы управления персоналом”]. Уровень детализации – [укажите, например, “средний: достаточно для понимания, не перегруженный”].
Формат ответа:
– Готовый шаблон с разделами и подразделами
– В каждом разделе: заголовок, краткое описание что туда писать (курсивом), пример заполнения (для 2–3 ключевых разделов)
– Инструкция по использованию шаблона (5–7 пунктов)
– Список: что нельзя удалять из шаблона и почему
Ограничения: шаблон должен быть достаточно гибким для разных проектов, но достаточно конкретным, чтобы его нельзя было заполнить бессодержательно. Не создавай раздутую структуру ради видимости полноты.
Тон: деловой, практичный, с ориентацией на удобство использования.
*****
Почему это работает: Требование примеров заполнения для ключевых разделов критически важно – шаблон без образца заполняется так же произвольно, как и пустой лист.
11. Написание описания ошибок и способов их устранения
Проблема: Пользователь видит сообщение об ошибке и не знает, что делать. Документация либо отсутствует, либо объясняет причину технически, не давая конкретного решения.
Решение: Промпт создает раздел документации по ошибкам с понятными описаниями и пошаговыми инструкциями по устранению.
Текст промпта:
*****
Ты – технический писатель с опытом создания документации по устранению неисправностей для конечных пользователей.
Задача: составь раздел документации, описывающий ошибки системы и способы их устранения.
Контекст: система – [опишите систему, например, “система электронного документооборота для юридических фирм”]. Аудитория – [укажите, например, “юристы и секретари без технического образования”]. Список ошибок для документирования: [вставьте коды ошибок, их технические описания или скриншоты].
Формат ответа для каждой ошибки:
– Код ошибки и ее название
– Что видит пользователь (точный текст сообщения или описание симптома)
– Возможные причины (простым языком, без технических деталей)
– Пошаговые действия для устранения (с альтернативными путями, если причин несколько)
– Когда обращаться в поддержку (если самостоятельно не устраняется)
Ограничения: не используй технические термины без объяснения, каждый шаг решения должен быть конкретным действием (“нажмите кнопку X”, а не “обновите настройки”), не предлагай решения, требующие прав администратора, если аудитория – рядовые пользователи.
Тон: спокойный, помогающий, без технического снобизма.
*****
Почему это работает: Разграничение между тем, что видит пользователь, и технической причиной ошибки – ключевое. Пользователь ищет по симптому, а не по коду, и именно такая структура позволяет найти нужную информацию быстро.
12. Написание аннотации к техническому документу
Проблема: Объемные технические документы начинаются сразу с содержания. Читатель не понимает, нужен ли ему этот документ, и тратит время на просмотр, чтобы это выяснить.
Решение: Промпт создает информативную аннотацию, которая позволяет читателю за 30 секунд понять, нужен ли ему этот документ.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на создании вводной документации и аннотаций.
Задача: напиши аннотацию к техническому документу.
Контекст: документ – [укажите тип и название, например, “Руководство по интеграции платежного модуля”]. Объем документа – [укажите, например, “45 страниц”]. Аудитория документа – [укажите, например, “разработчики, интегрирующие оплату в интернет-магазины”]. Краткое содержание документа: [опишите или вставьте оглавление].
Формат ответа – аннотация объемом 150–200 слов, содержащая:
- Что описывает документ (1–2 предложения)
- Для кого предназначен и какие задачи решает (1–2 предложения)
- Что читатель узнает или сможет сделать после изучения (2–3 пункта)
- Предварительные знания, необходимые для работы с документом
- Связанные документы (если есть)
Ограничения: аннотация – не пересказ содержания, а ответ на вопрос “нужен ли мне этот документ?”, не используй расплывчатые формулировки вроде “подробно описывает” – только конкретика.
Тон: деловой, информативный, без лишних слов.
*****
Почему это работает: Четкая формулировка цели аннотации (“нужен ли мне этот документ?”) задает правильный фокус. Без этого нейросеть пишет пересказ оглавления, а не навигационный инструмент.
13. Создание процедурного описания бизнес-процесса
Проблема: Бизнес-процессы существуют “в головах” сотрудников. Когда ключевой человек уходит или заболевает, все останавливается – потому что никто не знает, как именно делается та или иная вещь.
Решение: Промпт создает формализованное описание бизнес-процесса, пригодное для обучения новых сотрудников и контроля исполнения.
Текст промпта:
*****
Ты – технический писатель с опытом документирования бизнес-процессов в корпоративной среде.
Задача: составь процедурное описание бизнес-процесса на основе предоставленной информации.
Контекст: процесс – [опишите процесс, например, “согласование и подписание договора с новым поставщиком”]. Участники процесса – [перечислите, например, “менеджер по закупкам, юрист, финансовый директор, руководитель отдела”]. Используемые системы – [укажите, например, “1С:Документооборот, корпоративная почта”]. Описание процесса (как он происходит сейчас): [опишите или вставьте информацию].
Формат ответа:
- Назначение процесса (одно предложение)
- Участники и их роли в процессе
- Триггер: что запускает процесс
- Пошаговое описание: каждый шаг – действие, ответственный, срок, результат шага
- Точки контроля и критерии качества
- Возможные исключения и как с ними поступать
- Результат процесса (что считается успешным завершением)
Ограничения: каждый шаг должен быть конкретным действием одного ответственного, не описывай шаги, которые выполняются автоматически системой, как действия человека.
Тон: официальный, точный, пригодный для регламента.
*****
Почему это работает: Разграничение автоматических действий системы и действий человека – важная деталь. Смешение этих двух видов шагов – типичная ошибка, которая делает инструкцию запутанной.
14. Написание раздела по безопасности в технической документации
Проблема: Разделы по безопасности либо копируются из других документов без адаптации, либо написаны так формально, что пользователи их просто пропускают.
Решение: Промпт создает конкретный и понятный раздел по безопасности, адаптированный под реальную аудиторию и реальные риски продукта.
Текст промпта:
*****
Ты – технический писатель с опытом создания документации по информационной безопасности и охране труда.
Задача: напиши раздел по безопасности для технической документации продукта или системы.
Контекст: продукт или система – [опишите, например, “промышленный контроллер управления конвейерной линией”]. Аудитория – [укажите, например, “операторы производственной линии”]. Реальные риски и угрозы, связанные с продуктом – [опишите, например, “механические травмы при нарушении последовательности операций, повреждение оборудования при неправильных настройках”]. Применимые нормативы – [укажите, если известно, например, “ГОСТ Р 12.0.230”].
Формат ответа:
– Вводный абзац: почему этот раздел важно прочитать (конкретно, без общих слов)
– Обязательные условия перед началом работы
– Запрещенные действия (с объяснением последствий для каждого)
– Действия в нештатных ситуациях
– Ответственность за нарушение требований безопасности
Ограничения: каждое требование должно быть конкретным, а не общим (“не трогать движущиеся части” – плохо; “не прикасаться к ременному приводу при включенном двигателе” – хорошо), не копируй стандартные формулировки без адаптации.
Тон: серьезный, предупреждающий, без запугивания – цель убедить, а не напугать.
*****
Почему это работает: Требование объяснять последствия для каждого запрещенного действия – принципиально. Запрет без объяснения причины игнорируется. Запрет с объяснением последствий – соблюдается.
15. Создание матрицы трассировки требований
Проблема: В крупных проектах теряется связь между требованиями, функциями системы и тестами. Непонятно, какое требование покрыто, а какое нет.
Решение: Промпт создает матрицу трассировки, связывающую требования с функциями и тестовыми сценариями.
Текст промпта:
*****
Ты – технический писатель и бизнес-аналитик с опытом документирования в проектах с формальными требованиями к качеству.
Задача: составь матрицу трассировки требований на основе предоставленной документации.
Контекст: проект – [опишите проект, например, “разработка системы мониторинга транспортных средств для логистической компании”]. Имеющиеся документы: [перечислите, например, “спецификация требований версии 2.1, описание архитектуры, список тестовых сценариев”]. Содержание документов: [вставьте или опишите].
Формат ответа – таблица со столбцами:
– Идентификатор требования
– Текст требования (кратко)
– Соответствующий функциональный модуль или компонент системы
– Идентификаторы связанных тестовых сценариев
– Статус (реализовано / в разработке / не реализовано)
– Примечания
После таблицы: краткий анализ – какие требования не покрыты тестами, какие компоненты не связаны с требованиями.
Ограничения: не придумывай требования или тесты, которых нет в исходных материалах, если связь неочевидна – отметь ее как “требует уточнения”.
Тон: технически точный, нейтральный.
*****
Почему это работает: Анализ пробелов в конце матрицы – ключевое дополнение. Матрица без анализа – просто таблица. Матрица с анализом пробелов – инструмент управления качеством.
16. Написание руководства по быстрому старту
Проблема: Полная документация продукта объемная и сложная. Новый пользователь хочет начать работу за 10 минут, а не изучать 200-страничное руководство.
Решение: Промпт создает компактное руководство по быстрому старту, которое позволяет пользователю получить первый результат за минимальное время.
Текст промпта:
*****
Ты – технический писатель, специализирующийся на создании документации для первого знакомства пользователей с продуктом.
Задача: напиши руководство по быстрому старту для продукта или системы.
Контекст: продукт – [опишите продукт, например, “облачная система управления проектами для малого бизнеса”]. Целевой пользователь – [опишите, например, “руководитель небольшой команды, который впервые открывает систему”]. Цель руководства – [укажите, например, “за 15 минут создать первый проект, добавить участников и поставить задачу”]. Описание функционала: [вставьте описание или ссылки на разделы полной документации].
Логика действий:
- Определи минимальный набор шагов для достижения цели (не более 7–10 шагов)
- Для каждого шага: одно конкретное действие, результат, который увидит пользователь
- Выдели предварительные условия (что должно быть готово до начала)
- Добавь 2–3 ссылки на разделы полной документации для тех, кто хочет узнать больше
Формат ответа: компактный документ на 1–2 страницы, с четкими шагами, без лишних объяснений. Время прочтения – не более 5 минут.
Ограничения: не пытайся охватить весь функционал – только путь к первому результату, не объясняй “почему” – только “что делать”.
Тон: энергичный, ободряющий, ориентированный на действие.
*****
Почему это работает: Четкое ограничение “только путь к первому результату” предотвращает главную ошибку руководств по быстрому старту – превращение их в сокращенную версию полного руководства.
17. Написание описания архитектуры системы
Проблема: Архитектурные решения существуют в головах архитекторов или в разрозненных диаграммах без пояснений. Новый разработчик тратит недели на понимание системы.
Решение: Промпт создает структурированное описание архитектуры системы, понятное как разработчикам, так и техническим менеджерам.
Текст промпта:
*****
Ты – технический писатель с опытом документирования программных архитектур в IT-компаниях.
Задача: составь описание архитектуры системы на основе предоставленных материалов.
Контекст: система – [опишите систему, например, “микросервисная система обработки заказов для маркетплейса”]. Аудитория документа – [перечислите, например, “новые разработчики команды, технические руководители, DevOps-инженеры”]. Имеющиеся материалы: [опишите, например, “диаграммы компонентов, описания сервисов от разработчиков, схема взаимодействия баз данных”].
Формат ответа:
- Обзор системы: назначение, основные функции, ключевые характеристики (1 страница)
- Компоненты системы: описание каждого компонента (название, назначение, технология, взаимодействие с другими)
- Схема взаимодействия компонентов (текстовое описание, если нет возможности вставить диаграмму)
- Потоки данных: как данные движутся через систему для ключевых сценариев
- Ключевые архитектурные решения и их обоснование
- Ограничения и известные технические долги
Ограничения: описывай архитектурные решения с обоснованием (“выбрано потому, что…”), не перечисляй технологии без объяснения их роли в системе.
Тон: технически точный, но доступный для читателя с общим техническим образованием.
*****
Почему это работает: Требование обосновывать архитектурные решения – ключевое. Без обоснований документ описывает “что есть”, но не объясняет “почему именно так”, что и является главной ценностью архитектурной документации.
18. Создание руководства по установке и настройке
Проблема: Инструкции по установке написаны для специалистов, которые уже все знают. Любой нестандартный шаг – и пользователь застревает без понимания, что пошло не так.
Решение: Промпт создает подробное руководство по установке с обработкой типичных проблем на каждом этапе.
Текст промпта:
*****
Ты – технический писатель с опытом создания документации по развертыванию и настройке программного обеспечения.
Задача: напиши руководство по установке и первоначальной настройке программного продукта.
Контекст: продукт – [опишите продукт, например, “корпоративный мессенджер для внутренних коммуникаций”]. Целевая аудитория – [укажите, например, “системный администратор компании с базовыми навыками работы с серверами”]. Поддерживаемые операционные системы – [укажите, например, “Windows Server 2019, Astra Linux”]. Техническая информация об установке: [вставьте техническое описание процесса установки].
Формат ответа:
- Системные требования (минимальные и рекомендуемые)
- Подготовка к установке (что нужно сделать до начала)
- Пошаговая инструкция по установке (с указанием ожидаемого результата каждого шага)
- Первоначальная настройка (обязательные параметры)
- Проверка корректности установки (как убедиться, что все работает)
- Типичные проблемы при установке и их решения
Ограничения: для каждого шага, где возможна ошибка, добавь подраздел “Если что-то пошло не так”, все команды и параметры – точно как они должны быть введены, без вариаций.
Тон: точный, пошаговый, без предположения “это и так понятно”.
*****
Почему это работает: Подраздел “Если что-то пошло не так” после каждого рискованного шага – это то, что отличает хорошую инструкцию от плохой. Большинство пользователей открывают документацию именно тогда, когда что-то уже не работает.
19. Написание описания интеграции между системами
Проблема: Интеграции между системами часто документируются фрагментарно – часть информации у одной команды, часть у другой. Когда интеграция ломается, никто не может быстро понять, где именно.
Решение: Промпт создает полное описание интеграции, включая потоки данных, форматы и сценарии ошибок.
Текст промпта:
*****
Ты – технический писатель с опытом документирования интеграций между корпоративными системами.
Задача: составь описание интеграции между двумя системами.
Контекст: системы – [опишите обе системы, например, “система управления складом (СУС) и бухгалтерская система 1С:Бухгалтерия”]. Назначение интеграции – [опишите, например, “автоматическая передача данных о движении товара из СУС в 1С для формирования проводок”]. Техническая информация об интеграции: [вставьте описание, схемы, форматы данных].
Формат ответа:
- Назначение и бизнес-цель интеграции
- Участвующие системы: краткое описание каждой и ее роли в интеграции
- Схема потока данных (текстовое описание: что, откуда, куда, когда)
- Описание передаваемых данных (структура, формат, частота передачи)
- Сценарии ошибок и поведение систем при сбоях
- Мониторинг и диагностика: как понять, что интеграция работает корректно
- Ответственные за поддержку интеграции
Ограничения: описывай поведение при ошибках для каждого критического шага, не ограничивайся сценарием “все работает”.
Тон: технически точный, структурированный, для аудитории разработчиков и технических аналитиков.
*****
Почему это работает: Раздел мониторинга и диагностики – часто упускаемый, но критически важный. Документация по интеграции без него бесполезна в момент сбоя, когда она нужна больше всего.
20. Составление плана документирования проекта
Проблема: Документирование начинается хаотично – когда вспомнили или когда уже поздно. В результате часть документов дублирует друг друга, часть критически важного не задокументирована вовсе.
Решение: Промпт создает структурированный план документирования проекта с распределением ответственности и сроками.
Текст промпта:
*****
Ты – ведущий технический писатель, планирующий документирование крупного IT-проекта.
Задача: составь план документирования проекта.
Контекст: проект – [опишите проект, например, “разработка и внедрение системы управления персоналом для сети розничных магазинов, 200 точек”]. Этапы проекта – [перечислите, например, “анализ требований, проектирование, разработка, тестирование, внедрение, поддержка”]. Команда документирования – [укажите, например, “1 технический писатель, поддержка от аналитиков и разработчиков”]. Общие сроки проекта – [укажите, например, “12 месяцев”].
Формат ответа – план документирования:
- Перечень документов, которые будут созданы (с обоснованием необходимости каждого)
- Для каждого документа: этап создания, ответственный, рецензент, срок
- Зависимости между документами (какой документ нужен до начала другого)
- Риски документирования и способы их снижения
- Стандарты и инструменты, которые будут использоваться
Ограничения: не включай документы ради формальности – только те, которые реально будут использоваться, обоснование каждого документа – одно конкретное предложение.
Тон: деловой, практичный, ориентированный на реализацию.
*****
Почему это работает: Требование обосновывать необходимость каждого документа заставляет избавиться от документации ради документации – главного врага реального использования документов в проектах.
21. Написание описания тестовых сценариев
Проблема: Тестовые сценарии пишутся разработчиками или тестировщиками, но не техническими писателями. Результат – сценарии понятны только автору и требуют постоянных уточнений.
Решение: Промпт создает четкие и воспроизводимые тестовые сценарии, которые может выполнить любой член команды без дополнительных объяснений.
Текст промпта:
*****
Ты – технический писатель с опытом документирования тестирования программного обеспечения.
Задача: составь описания тестовых сценариев для функции или модуля системы.
Контекст: функция или модуль – [опишите, например, “форма регистрации нового пользователя в системе”]. Описание функционала – [вставьте описание или требования]. Типы тестирования – [укажите, например, “функциональное тестирование, тестирование граничных значений, тестирование ошибочных данных”].
Формат ответа для каждого тестового сценария:
– Идентификатор (ТС-001, ТС-002…)
– Название (что проверяется)
– Предварительные условия (что должно быть готово до начала теста)
– Шаги выполнения (пронумерованный список конкретных действий)
– Ожидаемый результат (точно: что должно произойти)
– Фактический результат (поле для заполнения при выполнении)
– Статус (поле: пройден / не пройден / заблокирован)
Ограничения: каждый шаг – одно конкретное действие, ожидаемый результат должен быть измеримым и конкретным (не “система работает правильно”, а “пользователь получает письмо с кодом подтверждения в течение 2 минут”).
Тон: точный, однозначный, без интерпретаций.
*****
Почему это работает: Требование конкретного ожидаемого результата – ключевое. Расплывчатый ожидаемый результат делает тест бесполезным, потому что невозможно определить, пройден он или нет.
22. Написание политики использования системы
Проблема: Политики использования корпоративных систем написаны юридическим языком, который никто не читает. Сотрудники нарушают правила не из злого умысла, а просто потому что не знают о них.
Решение: Промпт создает политику использования, написанную понятным языком, которую сотрудники действительно прочитают и запомнят.
Текст промпта:
*****
Ты – технический писатель с опытом создания корпоративных политик и регламентов для нетехнической аудитории.
Задача: напиши политику использования корпоративной системы или ресурса.
Контекст: система или ресурс – [опишите, например, “корпоративная система хранения документов”]. Аудитория – [укажите, например, “все сотрудники компании, от рядовых до руководителей”]. Ключевые требования и ограничения, которые должна охватывать политика – [перечислите, например, “запрет хранения личных файлов, требования к именованию документов, ограничения доступа”]. Последствия нарушений – [укажите, например, “предупреждение, выговор, увольнение в зависимости от тяжести нарушения”].
Формат ответа:
- Назначение политики (зачем она существует, кого защищает)
- Область применения (кого касается)
- Основные правила (написанные как конкретные обязательства: “пользователь обязан…”, “пользователю запрещено…”)
- Ответственность за нарушения
- Порядок обращения с вопросами и исключениями
Ограничения: избегай юридических формулировок без необходимости, каждое правило – одно конкретное требование, не “рекомендуется”, а “обязательно” или “запрещено”.
Тон: официальный, но человечный – политика должна объяснять смысл правил, а не просто перечислять запреты.
*****
Почему это работает: Указание объяснять смысл правил – принципиально. Правило без объяснения причины воспринимается как произвол и игнорируется. Правило с объяснением – соблюдается.
23. Создание справочника по командам командной строки
Проблема: Справочники по командной строке либо слишком краткие (“команда делает X”), либо перегружены техническими деталями без примеров реального использования.
Решение: Промпт создает практичный справочник с примерами реального использования каждой команды.
Текст промпта:
*****
Ты – технический писатель с опытом документирования инструментов командной строки и системного программного обеспечения.
Задача: составь справочник по командам командной строки для инструмента или системы.
Контекст: инструмент – [опишите, например, “утилита управления резервными копиями баз данных”]. Аудитория – [укажите, например, “системные администраторы с базовым опытом работы в командной строке”]. Список команд для документирования: [вставьте список команд с описаниями или исходный код].
Формат ответа для каждой команды:
– Синтаксис команды
– Краткое описание (одно предложение)
– Параметры: таблица (параметр, тип, обязательность, описание, значение по умолчанию)
– Примеры использования: минимум 2–3 реальных примера с пояснением что делает каждый
– Типичные ошибки и их причины
Ограничения: примеры должны быть реалистичными (не “example.txt”, а “backup_2024-11-15.tar.gz”), не описывай поведение, которое не задокументировано в исходных материалах.
Тон: технически точный, практичный, ориентированный на быстрое нахождение нужной информации.
*****
Почему это работает: Требование реалистичных примеров (не “example.txt”) – важная деталь. Абстрактные примеры заставляют читателя переводить их в реальный контекст, что замедляет работу и увеличивает вероятность ошибки.
24. Написание обучающего материала для нового сотрудника
Проблема: Адаптация новых сотрудников занимает месяцы, потому что знания передаются устно от одного человека. Если ключевой сотрудник занят – новый просто ждет.
Решение: Промпт создает структурированный обучающий материал, позволяющий новому сотруднику освоить систему или процесс самостоятельно.
Текст промпта:
*****
Ты – технический писатель с опытом создания обучающих материалов для корпоративного обучения.
Задача: создай обучающий материал для нового сотрудника по работе с системой или процессом.
Контекст: система или процесс – [опишите, например, “работа с системой учета рабочего времени”]. Должность нового сотрудника – [укажите, например, “менеджер проектов”]. Что сотрудник должен уметь делать после изучения материала – [перечислите, например, “отмечать рабочее время, создавать отчеты, согласовывать отпуска”]. Имеющиеся материалы: [вставьте описание системы или процесса].
Формат ответа – обучающий модуль:
- Введение: зачем нужна эта система и как она связана с работой сотрудника
- Основные понятия (не более 5–7 ключевых терминов с объяснением)
- Пошаговые инструкции для каждой задачи из списка
- Практические упражнения (2–3 задания для самопроверки)
- Частые вопросы новых сотрудников
- Где получить помощь (контакты, ресурсы)
Ограничения: материал должен быть самодостаточным – новый сотрудник не должен нуждаться в дополнительных объяснениях для выполнения основных задач, не перегружай теорией – максимум практики.
Тон: доброжелательный, поддерживающий, ориентированный на действие.
*****
Почему это работает: Практические упражнения как обязательный элемент – важнейшее требование. Обучающий материал без возможности попрактиковаться усваивается на 20% от возможного.
25. Написание описания релиза для внутренней команды
Проблема: Команда узнает о выходе нового релиза из случайного сообщения в корпоративном мессенджере. Что изменилось, зачем и что нужно сделать – неизвестно.
Решение: Промпт создает структурированное описание релиза для внутренней команды с четким разделением на группы получателей.
Текст промпта:
*****
Ты – технический писатель, отвечающий за внутренние коммуникации в IT-компании.
Задача: составь описание релиза для внутренней команды.
Контекст: продукт – [опишите, например, “корпоративная CRM-система”]. Версия и дата выпуска – [укажите, например, “версия 4.1, выход 20 ноября”]. Получатели – [перечислите, например, “команда разработки, отдел продаж, служба поддержки, руководство”]. Технический список изменений: [вставьте список изменений].
Формат ответа:
- Краткая сводка для руководства (5–7 предложений: что выпущено и почему это важно)
- Для команды разработки: технические изменения, зависимости, что нужно обновить в окружении
- Для отдела продаж: новые возможности, которые можно показывать клиентам
- Для службы поддержки: изменения, которые повлияют на обращения пользователей, новые сценарии ошибок
- Действия, которые нужно выполнить каждой группе до начала использования новой версии
Ограничения: каждый раздел пишется на языке аудитории – разработчики говорят на техническом, продажи – на языке возможностей для клиентов, поддержка – на языке пользовательских проблем.
Тон: деловой, информативный, без избыточных деталей.
*****
Почему это работает: Разные разделы для разных аудиторий в одном документе – это и есть профессиональный подход к внутренним коммуникациям. Один текст “для всех” не работает ни для кого.
26. Написание описания данных и их структуры
Проблема: Структуры данных существуют в базах данных без документации. Аналитики и новые разработчики тратят дни на выяснение, что означает каждое поле.
Решение: Промпт создает словарь данных – документ, описывающий структуру, смысл и правила заполнения каждого поля.
Текст промпта:
*****
Ты – технический писатель с опытом документирования структур данных и баз данных в корпоративных системах.
Задача: составь словарь данных для таблицы или набора таблиц базы данных.
Контекст: система – [опишите систему, например, “система управления заказами интернет-магазина”]. Аудитория документа – [укажите, например, “аналитики данных и разработчики, работающие с базой”]. Структура данных: [вставьте схему таблиц, список полей или экспорт из базы данных].
Формат ответа – словарь данных:
- Общее описание набора данных (назначение, связи с другими таблицами)
- Для каждого поля – таблица:
– Название поля
– Тип данных
– Обязательность
– Описание (что содержит, бизнес-смысл)
– Допустимые значения или диапазон
– Пример значения
– Связи с другими таблицами (если есть)
– Примечания (правила заполнения, исторические изменения)
Ограничения: описание каждого поля должно объяснять бизнес-смысл, а не только технический тип, если значение поля неочевидно – добавь пример.
Тон: технически точный, нейтральный, ориентированный на быстрое нахождение информации.
*****
Почему это работает: Требование объяснять бизнес-смысл, а не только технический тип – ключевое. Поле типа “tinyint” без объяснения смысла бесполезно. Поле “статус заказа (1 – новый, 2 – в обработке, 3 – отправлен)” – уже информация.
27. Написание сравнительного анализа технических решений
Проблема: Решения о выборе технологий или подходов принимаются на совещаниях без документированного обоснования. Через полгода никто не помнит, почему было выбрано именно это решение.
Решение: Промпт создает структурированный документ сравнительного анализа с четким обоснованием рекомендации.
Текст промпта:
*****
Ты – технический писатель с опытом документирования технических решений и обоснований выбора в IT-проектах.
Задача: составь документ сравнительного анализа технических решений или подходов.
Контекст: задача, которую нужно решить – [опишите задачу, например, “выбор системы очередей сообщений для обработки событий в реальном времени”]. Сравниваемые решения – [перечислите, например, “Apache Kafka, RabbitMQ, самописное решение на базе PostgreSQL”]. Критерии выбора – [перечислите, например, “производительность, стоимость владения, наличие экспертизы в команде, поддержка российскими компаниями”]. Контекст принятия решения – [опишите, например, “нагрузка 10 000 событий в секунду, команда из 5 разработчиков”].
Формат ответа:
- Постановка задачи и контекст принятия решения
- Описание каждого рассматриваемого решения (кратко, без предвзятости)
- Сравнительная таблица по критериям (оценка каждого решения по каждому критерию)
- Анализ сильных и слабых сторон каждого решения в контексте задачи
- Рекомендация с обоснованием
- Риски выбранного решения и способы их снижения
Ограничения: анализ должен быть объективным – описывай слабые стороны рекомендованного решения наравне с сильными, не делай вывод без явного обоснования.
Тон: аналитический, взвешенный, без маркетинговых оценок.
*****
Почему это работает: Требование описывать слабые стороны рекомендованного решения – важнейшее условие доверия к документу. Анализ, в котором рекомендуемое решение лишено недостатков, воспринимается как предвзятый и игнорируется.
28. Создание шаблона протокола совещания по техническому проекту
Проблема: Совещания по техническим проектам заканчиваются без фиксации решений. Через неделю участники расходятся в понимании того, что было решено, и все обсуждается заново.
Решение: Промпт создает шаблон протокола совещания, который фиксирует решения и задачи в структурированном виде.
Текст промпта:
*****
Ты – технический писатель с опытом документирования проектных коммуникаций в IT-компаниях.
Задача: создай шаблон протокола совещания по техническому проекту и заполни его на основе предоставленных материалов.
Контекст: тип совещания – [укажите, например, “еженедельный статус по проекту” или “совещание по архитектурному решению”]. Участники – [перечислите роли, например, “руководитель проекта, архитектор, ведущий разработчик, представитель заказчика”]. Материалы совещания: [вставьте записи, тезисы или расшифровку].
Формат ответа – протокол совещания:
– Дата, время, место (или формат: онлайн/офлайн)
– Участники (с указанием роли)
– Повестка совещания
– По каждому пункту повестки: краткое изложение обсуждения, принятое решение
– Задачи по итогам: таблица (задача, ответственный, срок)
– Открытые вопросы, перенесенные на следующее совещание
– Дата следующего совещания
Ограничения: решения должны быть сформулированы как конкретные утверждения (“принято решение использовать X”), а не как описание обсуждения (“обсудили X”), задачи должны иметь конкретного ответственного и конкретный срок.
Тон: официальный, точный, без интерпретаций – только факты.
*****
Почему это работает: Разграничение между решениями и задачами – ключевое. Решение – это что принято. Задача – это что нужно сделать. Смешение этих двух вещей превращает протокол в бесполезный документ.
29. Написание описания пользовательских ролей и прав доступа
Проблема: Права доступа в системе настраиваются интуитивно, без документации. Когда приходит новый администратор или нужно провести аудит, никто не может объяснить, почему у той или иной роли такие права.
Решение: Промпт создает полное описание ролевой модели системы с обоснованием прав для каждой роли.
Текст промпта:
*****
Ты – технический писатель с опытом документирования систем управления доступом в корпоративных приложениях.
Задача: составь описание пользовательских ролей и прав доступа для системы.
Контекст: система – [опишите систему, например, “система управления договорами юридической компании”]. Аудитория документа – [укажите, например, “системный администратор и руководители отделов”]. Информация о ролях и правах: [вставьте описание ролей, матрицу прав или конфигурацию системы].
Формат ответа:
- Общее описание ролевой модели (принципы, по которым разграничены права)
- Для каждой роли:
– Название роли
– Кто относится к этой роли (должности, функции)
– Назначение роли в системе
– Права: что может делать (читать, создавать, редактировать, удалять – по каждому типу объектов)
– Ограничения: что явно запрещено и почему - Матрица прав: таблица (роль × объект × уровень доступа)
- Порядок назначения и изменения ролей
- Порядок запроса расширенных прав
Ограничения: обоснование ограничений обязательно – не “роль X не может удалять договоры”, а “роль X не может удалять договоры, так как это требует согласования руководителя юридического отдела”.
Тон: официальный, точный, пригодный для аудита.
*****
Почему это работает: Обязательное обоснование каждого ограничения превращает документ из справочника в реальный инструмент управления доступом. Без обоснований права меняются произвольно при смене администратора.
30. Написание итогового отчета по документированию проекта
Проблема: По завершении проекта документирование просто прекращается. Никто не фиксирует, что было создано, что осталось незадокументированным и что нужно обновить при следующем релизе.
Решение: Промпт создает итоговый отчет по документированию проекта, который служит основой для следующего цикла работы.
Текст промпта:
*****
Ты – ведущий технический писатель, подводящий итоги документирования завершенного IT-проекта.
Задача: составь итоговый отчет по документированию проекта.
Контекст: проект – [опишите проект, например, “разработка и внедрение системы управления складом, 8 месяцев”]. Что было задокументировано: [перечислите, например, “техническое задание, архитектурное описание, 3 пользовательских руководства, глоссарий, 2 регламента”]. Что осталось незадокументированным или требует доработки: [опишите, если известно]. Команда документирования – [укажите состав].
Формат ответа – итоговый отчет:
- Краткое резюме: что было сделано (для руководства, 1 страница)
- Реестр созданных документов: таблица (документ, версия, дата, ответственный, место хранения)
- Оценка соответствия плану документирования (что выполнено, что нет и почему)
- Документы, требующие обновления в ближайшем будущем (с обоснованием)
- Выявленные проблемы и рекомендации для следующего проекта
- Рекомендации по поддержке документации после завершения проекта
Ограничения: отчет должен быть честным – если что-то не было сделано, указывай причину, а не замалчивай, рекомендации должны быть конкретными и реализуемыми.
Тон: деловой, аналитический, ориентированный на улучшение следующего цикла.
*****
Почему это работает: Требование честно фиксировать невыполненное – принципиально. Отчет, в котором все хорошо, бесполезен для развития. Отчет с реальным анализом проблем – основа для улучшений.
Типичные ошибки при работе с промптами для технического писателя
- Не указывать аудиторию документа в промпте. Нейросеть пишет “для среднего читателя”, а средний читатель – понятие настолько расплывчатое, что результат не подходит ни для кого конкретного.
- Давать промпту только задачу без контекста продукта или системы. Нейросеть генерирует универсальный шаблон вместо документа для конкретного продукта – и потом приходится переписывать вручную то, что должен был сделать промпт.
- Не указывать формат и структуру ожидаемого результата. Без явного указания структуры нейросеть выбирает формат самостоятельно – и часто выбирает неподходящий: там, где нужна таблица, пишет список, и наоборот.
- Забывать указывать ограничения – что нельзя делать. Ограничения в промпте работают как фильтр качества: без них нейросеть добавляет термины без расшифровки, пишет длинные абзацы там, где нужны шаги, и использует пассивный залог.
- Вставлять в промпт слишком много исходных материалов без структурирования. Если вставить 10 страниц сырого текста без указания, что из этого главное, нейросеть теряет фокус и создает документ, в котором второстепенное занимает столько же места, сколько ключевое.
- Не проверять промпт на конкретном примере перед использованием в рабочих задачах. Промпт, который выглядит логичным в теории, может давать неудовлетворительный результат на реальных данных – и это выясняется только при первом использовании с настоящим техническим материалом.
- Использовать один и тот же промпт для разных типов документов. Промпт для пользовательской инструкции и промпт для технической спецификации требуют принципиально разных установок по уровню детализации, языку и структуре – универсальный промпт дает посредственный результат для обоих.
- Не указывать тон и стиль документа. Тон корпоративного регламента и тон обучающего материала для нового сотрудника – разные вещи. Без явного указания нейросеть выбирает нейтральный академический стиль, который не подходит ни для одного из них.
- Ожидать готового финального текста с первой попытки. Нейросеть дает хорошую основу, которую нужно доработать с учетом специфики конкретного продукта. Те, кто воспринимает первый результат как финальный, получают документацию, которая выглядит правдоподобно, но содержит неточности.
Сравнение слабых и сильных запросов для задач технического писателя
| Задача | Слабый запрос | Сильный запрос (ключевые улучшения) | Почему разница критична |
| Пользовательская инструкция | “Напиши инструкцию по работе с системой” | “Напиши пошаговую инструкцию для бухгалтеров без технического образования по функции загрузки платежных поручений. Максимум 10 шагов, каждый – одно действие. Добавь раздел с 3 частыми ошибками” | Без аудитории и структуры нейросеть пишет для “всех” – то есть ни для кого |
| Описание ошибки | “Опиши ошибку 404” | “Опиши ошибку 404 для пользователей интернет-магазина: что они видят, 3 возможные причины простым языком, пошаговые действия для каждой причины, когда обращаться в поддержку” | Техническое описание ошибки не помогает пользователю – ему нужно решение |
| Техническое задание | “Составь техническое задание на разработку сайта” | “Составь техническое задание на разработку личного кабинета для клиентов страховой компании. Каждое требование – проверяемое утверждение. Исполнитель – внешняя команда. Включи раздел с критериями приемки” | Без проверяемых требований ТЗ не защищает ни заказчика, ни исполнителя |
| Глоссарий | “Составь глоссарий терминов для документации” | “Составь глоссарий для документации системы управления складом. Аудитория – кладовщики. Отметь термины, которые в нашей системе используются нестандартно. Определения – не более 2 предложений” | Стандартный глоссарий не учитывает специфику продукта – главную причину путаницы |
| Описание релиза | “Перепиши список изменений в релизе понятным языком” | “Перепиши технический список изменений релиза 3.2 для трех аудиторий: руководство (что важно для бизнеса), отдел продаж (что показывать клиентам), поддержка (что изменится в обращениях пользователей)” | Один текст для всех не работает ни для кого – каждая аудитория ищет разную информацию |
| Политика использования | “Напиши политику использования корпоративной системы” | “Напиши политику использования системы хранения документов для всех сотрудников. Каждое правило – конкретное обязательство или запрет с объяснением причины. Избегай юридических формулировок” | Политика без объяснения смысла правил воспринимается как произвол и игнорируется |
| Архитектурное описание | “Опиши архитектуру системы” | “Составь описание архитектуры микросервисной системы обработки заказов для новых разработчиков. Для каждого компонента – назначение и роль. Для каждого архитектурного решения – обоснование почему именно так” | Описание без обоснований показывает “что есть”, но не объясняет “почему” – а это и есть главная ценность архитектурной документации |
Неочевидные советы по работе с запросами для нейросети в технической документации
- Передавайте нейросети реальные примеры существующей документации компании в качестве эталона стиля. Если вставить в промпт 2–3 абзаца из уже принятых документов организации с пометкой “придерживайся этого стиля”, результат будет в разы ближе к корпоративному стандарту, чем при любом словесном описании тона.
- Разбивайте создание сложного документа на несколько последовательных промптов, а не пытайтесь получить все за один запрос. Нейросеть качественнее прорабатывает каждый раздел отдельно, чем создает весь документ сразу – и итоговый результат требует значительно меньше правки.
- Используйте нейросеть для рецензирования уже написанного текста с конкретными критериями оценки. Промпт вида “проверь этот текст: найди все термины без расшифровки, предложения длиннее 20 слов и пассивный залог” дает более точную правку, чем просьба “улучши текст”.
- Формулируйте ограничения в промпте как конкретные запреты, а не как пожелания. “Не используй пассивный залог” работает лучше, чем “предпочтительно активный залог” – нейросеть воспринимает ограничения буквально, и четкий запрет соблюдается строже, чем размытое предпочтение.
- Сохраняйте промпты, давшие хороший результат, в отдельный файл с пометкой о типе документа и аудитории. Промпт, сработавший для инструкции по одному модулю системы, сработает для инструкции по любому другому модулю той же системы – переменные меняются, структура остается.
- Просите нейросеть выявить противоречия и пробелы в исходных материалах перед написанием документа. Этот шаг, выполненный отдельным промптом до начала написания, экономит время на правках: нейросеть находит то, что техническому писателю потребовало бы нескольких итераций согласования с командой.
- Указывайте в промпте, какие решения нейросеть должна принять самостоятельно, а о каких – спросить. Формулировка “если структура раздела неочевидна – спроси, если выбор касается только формулировки – решай сам” позволяет получить документ без лишних уточняющих вопросов и при этом не потерять контроль над важными решениями.
