20 промтов для технической документации: пишите так чтобы понимали

Шпаргалка

Техническая документация — это не про технологии. Это про то чтобы человек смог сделать то что нужно, не звоня в поддержку. Большинство тех доков провальны потому что написаны для тех кто уже знает — а не для тех кто не знает. AI помогает писать документацию которую читают.

1. Структура технической документации

Продукт / система / API: [описание]. Аудитория: [разработчики / конечные пользователи / администраторы]. Разработай структуру документации: — Разделы в логичном порядке (от общего к частному) — Что включить в каждый раздел — Что вынести в Quick Start (для нетерпеливых) — Что в отдельные справочные разделы — Как организовать навигацию

2. Аудит существующей документации

Существующая документация: [вставить или описать]. Продукт: [описание]. Аудитория: [кто читает]. Сделай аудит: — Что отсутствует (пробелы) — Что устарело — Где непонятно (проблемы с ясностью) — Что лишнее (слишком подробно для этой аудитории) — Приоритеты для улучшения

3. Контент-план для документации

Продукт запускается через [N] недель. Команда: [кто пишет документацию]. Составь план: — Что нужно на дату запуска (минимум) — Что добавить в первый месяц — Что в долгосрочной перспективе — Приоритизация по ценности для пользователя — Кто пишет что

4. README для GitHub репозитория

Проект: [название и что делает]. Технологии: [стек]. Напиши README: — Одна строка: что это такое — Зачем это нужно (use cases) — Быстрый старт (установка и первый запуск — 5 минут) — Примеры использования (код) — Конфигурация — Как контрибьютить — Лицензия

5. API документация для эндпоинта

Эндпоинт: [метод + URL]. Что делает: [описание]. Параметры: [список с типами]. Ответ: [структура]. Напиши документацию: — Описание (что делает и когда использовать) — Параметры запроса (таблица: название / тип / обязательный / описание) — Пример запроса (curl + код на популярных языках) — Пример успешного ответа — Коды ошибок и их значение

6. Инструкция по установке

Продукт: [что устанавливаем]. Окружение: [ОС / требования]. Напиши инструкцию: — Предварительные требования (что должно быть установлено) — Шаги установки (нумерованные, один шаг = одно действие) — Проверка что всё работает — Типичные проблемы и их решение — Что делать если что-то пошло не так

7. Руководство пользователя (User Guide)

Продукт: [что делает]. Аудитория: [уровень технической грамотности]. Задача которую нужно выполнить: [конкретная]. Напиши руководство: — Введение (зачем это делать) — Предварительные условия — Пошаговые инструкции с скриншотами (опиши что показать) — Результат (как понять что сделано правильно) — Следующие шаги

8. Упростить технический текст

Технический текст для разработчиков: [вставить]. Нужно адаптировать для: [нетехнические пользователи / менеджеры / клиенты]. Упрости: — Замени термины на понятные объяснения — Добавь аналогии из реальной жизни — Сохрани точность (не упрощай до неправды) — Убери детали которые не нужны этой аудитории

9. Написать предупреждения и заметки

Контекст: [о чём документация]. Напиши предупреждения для: — Warning: [опасное действие которое может сломать систему] — Caution: [действие которое нужно делать осторожно] — Note: [важная информация которую могут пропустить] — Tip: [полезный совет который ускорит работу] Каждое: краткое, конкретное, без "пожалуйста".

10. Примеры кода: как писать хорошие

Функция / метод: [описание что делает]. Язык: [язык программирования]. Напиши пример кода для документации: — Минимально необходимый (не перегруженный) — С реалистичными данными (не foo / bar) — С комментариями к неочевидным местам — Показывает самый частый use case — Отдельно: пример с обработкой ошибок

11. Changelog / Release Notes

Что изменилось в версии [N.N.N]: [список изменений — технически]. Напиши release notes для: — Пользователей (что изменится для них) — Разработчиков (технические детали) Структура: Breaking Changes → New Features → Improvements → Bug Fixes. Каждый пункт: что изменилось + зачем + если нужно: как мигрировать.

12. Troubleshooting Guide

Продукт: [описание]. Типичные проблемы: [список ошибок / симптомов]. Для каждой проблемы напиши раздел: — Симптом (как пользователь это видит) — Возможные причины — Диагностика (как определить причину) — Решение пошагово — Если не помогло: что дальше

13. Глоссарий терминов

Продукт / область: [описание]. Термины которые нужно объяснить: [список]. Для каждого термина: — Краткое определение (1-2 предложения) — Как используется в контексте нашего продукта — Пример (если помогает) — Связанные термины Стиль: понятный пользователю продукта, не словарь.

14. Style Guide для технических писателей

Продукт: [описание]. Аудитория документации: [описание]. Создай style guide: — Тон и голос (как пишем) — Терминология (какие слова используем / не используем) — Форматирование (заголовки / списки / код / таблицы) — Примеры: правильно / неправильно — Как называть элементы интерфейса

15. Ревью технической документации

Документ для ревью: [вставить]. Целевая аудитория: [описание]. Сделай ревью: — Ясность (всё ли понятно без дополнительного контекста) — Полнота (нет ли пробелов) — Точность (нет ли технических ошибок) — Структура (логичен ли порядок) — Что улучшить в первую очередь

16. Видео-скрипт для технического туториала

Туториал о: [что показываем]. Аудитория: [уровень]. Длина: [N минут]. Напиши скрипт: — Открытие: что научатся делать (30 сек) — Предварительные условия (если есть) — Основные шаги (с тайтингом) — Что говорить пока показываешь экран — Закрытие и следующие шаги

17. FAQ для технического продукта

Продукт: [описание]. Частые вопросы от пользователей: [список или "придумай типичные"]. Напиши FAQ: — Вопросы сформулированы как пользователь (не как маркетолог) — Ответы: конкретные, с примерами — Ссылки на более подробную документацию — Структура: от простых к сложным

18. Onboarding документ для новых пользователей

Продукт: [описание]. Цель: пользователь должен получить первый результат за [N] минут. Напиши onboarding документ: — Приветствие (без корпоративного булшита) — 3 шага до первого результата — Что пропустить на первый раз (можно вернуться позже) — Как получить помощь — Что изучить дальше

19. Промт для генерации документации из кода

Код: [вставить функцию/класс/модуль]. Напиши документацию: — Docstring в формате [Google / NumPy / JSDoc] — Описание что делает — Параметры с типами и описанием — Возвращаемое значение — Примеры использования — Возможные исключения

20. Шаблон для технического specification

Фича / система: [описание]. Создай шаблон spec-документа: — Overview (что это и зачем) — Goals & Non-goals — Background (контекст) — Detailed Design — API Changes (если есть) — Data Model (если есть) — Testing Plan — Open Questions — Timeline