Claude Opus 4.8 для технической документации
Документацию читают не для того, чтобы узнать, что умеет система, а чтобы довести до конца конкретное дело: развернуть, настроить, починить. Claude Opus 4.8 хорошо превращает исходное сырьё — код, вывод команды, конфиг, текст ошибки — в проверяемую последовательность шагов. Опасность ровно одна и она серьёзная: без сырья модель дописывает несуществующие параметры так же уверенно, как настоящие.
Почему Claude Opus 4.8 подходит для этой задачи
Техдокумент держится на согласованности: имя параметра в разделе установки, в примере конфига и в описании ошибки обязано совпадать буквально. Расхождение в одну букву стоит читателю получаса. Opus 4.8 удерживает длинный документ целиком и поэтому ловит такие рассинхроны — в том числе те, что появились после ваших правок в середине текста, когда вы переименовали ключ в одном месте из трёх.
Вторая сильная сторона — жанровая дисциплина. Инструкция, справочник и объяснение решают разные задачи, и смешивать их вредно: в пошаговой инструкции рассуждение о внутреннем устройстве сбивает человека, который в этот момент чинит прод. Opus 4.8 держит заданный жанр на длинном тексте, не сползая в универсальный обзорный стиль — если жанр и адресат названы в первой строке запроса.
Это самая дорогая модель подписки, 65 токенов за запрос, около 185 обращений на месячном тарифе за 999 рублей. Тратить их на переформатирование списков смысла нет: черновую унификацию заголовков и вычитку дешевле отдать gpt-5.4 mini за 12 токенов, а Opus оставить на то, ради чего он здесь — свести код, лог и текст в один непротиворечивый документ и найти в нём дыры.
Какие входные данные подготовить
Реальное сырьё, а не пересказ: вывод команды с ключом справки, файл конфигурации, сигнатуры функций, схема таблицы. Всё, чего нет в сырье, модель придумает.
Адресат и его стартовая точка: коллега-разработчик с доступом ко всему или новый сотрудник на чистой машине. Это меняет документ сильнее, чем любые правки стиля.
Жанр документа: пошаговая инструкция, справочник параметров, объяснение архитектуры, README. Смешанный жанр — главная причина того, что документацию не читают.
Реальные ошибки и логи, которые уже случались у пользователей. Раздел про типичные сбои пишется по фактам поддержки, а не по воображению.
Соглашения проекта: терминология, формат примеров, что считается обязательным разделом. Иначе каждый новый документ будет написан немного по-своему.
Пошаговый процесс
Выберите жанр и адресата до первой строки
Скажите прямо: «пошаговая инструкция для человека, который видит систему впервые, у него чистая Ubuntu и доступ по SSH». Документ, написанный без адресата, получается усреднённым: новичку в нём не хватает шагов, специалисту мешает вода. Один и тот же материал в двух жанрах — это два документа, а не один универсальный.
Дайте исходники вместо описания
Вставьте вывод справки команды, конфиг целиком, сигнатуры и схему данных. Разница принципиальная: с исходником модель описывает существующие параметры, без исходника — правдоподобные. Второй вариант читается лучше первого и не работает совсем, что выясняется у первого же читателя.
Пропишите сквозной сценарий успеха
Основа инструкции — путь от нуля до работающего результата без ветвлений: что установить, что выполнить, что должно появиться на экране после каждого шага. Ожидаемый вывод обязателен: без него человек не знает, идёт ли он правильно, и обнаруживает ошибку через шесть шагов после того, как её допустил.
Добавьте раздел про сбои по реальным логам
Отдайте модели настоящие сообщения об ошибках из поддержки и попросите превратить их в раздел «симптом — причина — что сделать». Ценность такого раздела в дословных строках ошибок: человек ищет по тексту, который видит на экране, и находит нужный абзац поиском по странице.
Проверьте документ исполнением
Каждую команду выполнить на чистом окружении, каждый путь и каждый флаг сверить с исходником. Идеальная проверка — посадить человека, который систему не знает, и молча смотреть, где он остановится. Место остановки и есть недостающий шаг, который автору был очевиден.
Пример готового промпта
Ты — технический писатель. Пиши документ строго в одном жанре: пошаговая инструкция. Продукт: [ЧТО ЭТО И ЗАЧЕМ] Адресат: [КТО ЧИТАЕТ, ЧТО У НЕГО УЖЕ ЕСТЬ] Результат, к которому ведёт инструкция: [ЧТО ДОЛЖНО РАБОТАТЬ В КОНЦЕ] Окружение: [ОС, ВЕРСИИ, ДОСТУПЫ] Исходники — работай только по ним: Вывод справки команды: """ [ВСТАВЬ ВЫВОД] """ Файл конфигурации: """ [ВСТАВЬ КОНФИГ] """ Реальные ошибки пользователей: """ [ВСТАВЬ ЛОГИ] """ Структура документа: 1. Что понадобится до начала (доступы, версии, права). 2. Сквозной сценарий: шаги по порядку, у каждого — команда, ожидаемый вывод и признак того, что шаг прошёл. 3. Параметры: только те, что есть в исходниках. Таблица «имя — тип — значение по умолчанию — что делает». 4. Если что-то пошло не так: дословный текст ошибки, причина, действие. 5. Как откатить изменения. Жёсткие правила. Не придумывай флаги, ключи конфигурации, эндпойнты и имена файлов: если параметра нет в исходниках, ставь пометку [УТОЧНИТЬ У РАЗРАБОТЧИКА] и переходи дальше. Не пиши, что делает система, — пиши, что делает читатель. Никаких фраз про возможности и преимущества продукта. Одно действие — один шаг.
Пометка [УТОЧНИТЬ У РАЗРАБОТЧИКА] нужна, чтобы пробел в исходниках остался видимым. Без неё модель заполняет пропуск правдоподобным вариантом, и дыра переезжает в опубликованный документ уже незаметной.
Как проверить результат
Все команды выполнены на чистом окружении именно в том порядке, в котором они записаны.
Каждое имя параметра, пути и эндпойнта найдено поиском в исходном коде или конфиге.
Ожидаемый вывод указан у каждого шага и совпадает с тем, что реально печатает система.
Документ прочитан человеком не из команды: места, где он остановился, дописаны, а не объяснены устно.
Типичные ошибки
Выдуманные флаги и эндпойнты
Главная беда жанра. По названию утилиты модель реконструирует правдоподобный интерфейс: ключ вида для подробного вывода, параметр таймаута, метод в API — всё выглядит как настоящее, потому что похоже на соседние проекты. Читатель получает ошибку неизвестного аргумента и перестаёт доверять всему документу целиком. Единственная защита — давать сырьё и сверять каждое имя поиском по репозиторию.
Документ, написанный от лица системы
Формулировки вида «система обеспечивает синхронизацию» описывают продукт, а не действие читателя. Человек пришёл с задачей и ищет глагол в повелительном наклонении: выполните, откройте, замените. Текст от лица системы длиннее в полтора раза и не отвечает ни на один практический вопрос — при этом выглядит солидно, поэтому его редко правят.
Полнота вместо сценариев
Описаны все двести параметров и ни одного пути от установки до результата. Такой справочник формально безупречен и бесполезен: человек не знает, с чего начать, и идёт спрашивать в чат. Сначала два-три сквозных сценария, покрывающих реальные задачи, потом справочная часть — и обязательно ссылки из сценария в справочник.
Альтернативные модели для этой задачи
Claude Sonnet 4.6
Для сопровождения готовой документации: обновить раздел после изменения в коде, собрать список изменений, привести десяток страниц к общему стилю. 40 токенов вместо 65 при том же характере письма.
OpenAIGPT-5.4 mini
Черновая работа по тексту: комментарии к функциям пачками, унификация заголовков, перевод README на английский. 12 токенов за запрос — рутину такого рода дорогая модель делает не лучше.
Частые вопросы
Модель напишет документацию по коду сама?
По вставленному коду она разберёт сигнатуры и составит справочную часть довольно точно. Чего в коде нет — зачем эта система нужна, какие сценарии основные, что считается нормой в проде — приходит только от вас. Документ без этого получается формально верным и не отвечающим на вопросы, ради которых его открывают.
Почему в примерах появляются несуществующие параметры?
Модель достраивает интерфейс по аналогии с похожими инструментами: если у большинства утилит есть ключ подробного вывода, он появится и у вашей. Лечится сырьём в запросе и явным запретом придумывать имена с пометкой на месте пропуска. Проверка при этом остаётся обязательной — каждое имя ищется в репозитории.
Можно ли вести документацию на двух языках?
Да, и удобнее делать это в два прохода: сначала русский документ доводится до готовности, потом переводится целиком, а не пишется параллельно. Для перевода технического текста Opus избыточен — берите модель дешевле, а глоссарий терминов зафиксируйте отдельным списком, чтобы одно понятие не переводилось тремя способами.
Как быть с внутренним кодом компании?
Вставляйте в запрос только те фрагменты, которые нужны для документа, и убирайте из них ключи, пароли и адреса внутренних хостов. Секреты в конфигах заменяются метками до отправки — правило то же, что при публикации примера в открытом репозитории.
Сколько документов выйдет на подписке?
Claude Opus 4.8 стоит 65 токенов за запрос, месячный тариф за 999 рублей даёт около 185 обращений. Один раздел обычно занимает три-четыре запроса вместе с правками, то есть месяца хватает на полный комплект документации среднего сервиса. Недельный тариф за 399 рублей разумно взять под разовую задачу вроде описания одного модуля.
Модель Claude Opus 4.8 доступна в FatherGPT: без VPN, картой РФ, единый баланс токенов на все нейросети. Переключайтесь между моделями в одном чате — под каждую задачу своя.