Стили вывода (Output Styles): Меняем «программу», не меняя ведущего
📚 Навигация по серии: В предыдущей статье 31 settings.json: Настройки уровня пользователя / проекта мы разобрались, «в какой файл писать настройки и кто кого переопределяет». В этой статье мы продолжим разговор о переключателе, который живет в этих самых настройках — стилях вывода (output styles). Он управляет не тем, «что знает Claude», а тем, «как Claude вам отвечает». Одна строка настроек может превратить его из стандартного «молчаливого инженера» в наставника, который объясняет все по ходу дела, или даже в совершенно другую личность, которая вообще не пишет код.
Говорят: «Хочешь, чтобы Claude слушался, складывай всё в CLAUDE.md» — соглашения, правила, всё, что он должен помнить.
Честно говоря, это лишь половина правды. CLAUDE.md действительно отличное место для «контекста проекта» (подробнее в статье 18), но есть одна категория требований, которую ошибочно складывать туда.
Какая именно? «Я хочу, чтобы его тон / роль / формат ответов менялся каждый раз». Например: я хочу, чтобы он каждый раз сначала рисовал схему, а потом объяснял; я хочу, чтобы он, пока пишет код, объяснял мне, почему пишет именно так; или я вообще хочу использовать его как помощника писателя, а не программиста. Если вы запишете эти требования в CLAUDE.md, они будут работать раз через раз — потому что CLAUDE.md это «запрос пользователя, прикрепленный после системного промпта», а не переключатель, меняющий его «сущность». Настоящий переключатель, который меняет то, «как говорит Claude», называется output styles.
Скажем так: CLAUDE.md — это материалы по проекту, переданные новому сотруднику, а output styles — это прямое переписывание его должностной инструкции («на этой должности ты программист, который молча пишет код, или наставник, который объясняет по ходу работы»). В этой статье мы разберемся, как работает этот переключатель.
Представьте ситуацию, чтобы сразу понять суть: попросить человека, совершенно не разбирающегося в коде, использовать Claude Code для редактирования резюме. С включенной по умолчанию личностью инженера он то и дело захочет «помочь вам разбить этот абзац на функции» или спросит «не добавить ли нам тесты» — его мозг полон инженерного мышления, что совершенно не подходит для работы над резюме. Это не та проблема, которую решит CLAUDE.md, именно для этого и существуют output styles.
Прочитав эту статью, вы узнаете:
- В одном предложении: что именно меняют output styles (спойлер: это «как отвечать», а не «что знать»).
- Какие встроенные стили есть в Claude Code (по умолчанию, Proactive, Explanatory, Learning), для чего они нужны и когда их переключать.
- Как переключать стили — и подвох со сменой версий: старой команды
/output-styleбольше нет, как теперь переключаться. - Как создать свой собственный пользовательский стиль вывода: как написать Markdown-файл, за что отвечают поля frontmatter, и почему важно не ошибиться с переключателем
keep-coding-instructions. - В чем разница между output styles, CLAUDE.md,
--append-system-prompt, Subagent и Skill — разберем в одной таблице, чтобы больше не путаться.
01 Сначала поймем: он меняет «как отвечать», а не «что знать»
Давайте сначала закрепим самую важную фразу этой статьи, на которой строится все остальное:
Стили вывода меняют то, как Claude отвечает, а не то, что Claude знает.
Это точная цитата из официальной документации. Это означает: output styles не вливают в Claude новые знания о вашем проекте, они влияют на системный промпт Claude (system prompt — базовую инструкцию, которая загружается в начале каждого сеанса и определяет «кто такой Claude и как он должен работать») — задавая ему роль, тон и формат вывода.
Аналогия: один и тот же ведущий, но для разных телепередач он использует разный стиль ведения. Человек тот же, профессиональные навыки не изменились (словарный запас, база знаний — всё при нём); но новости он ведет серьезно, детскую передачу — с прыжками и веселой интонацией, а образовательный канал — в замедленном темпе, с паузами для вопросов. Меняется то, «как эта передача требует от него говорить», а не сам человек. output styles — это «смена программы» для Claude. Модель остается прежней, способности не тронуты, меняются только его роль, тон и формат общения с вами.
Так когда же это пригодится? Официальная рекомендация очень прагматична:
Используйте их, когда вы постоянно заново вводите один и тот же голос или формат в каждом раунде, или когда вы хотите, чтобы Claude выступал в роли, отличной от роли инженера-программиста.
(В оригинале так, под «голосом» здесь понимается тон / формат ответа.)
Проще говоря, есть два сигнала:
- «Я вынужден заново печатать одно и то же требование в каждом раунде» — например, вы каждый раз напоминаете: «при объяснении сначала нарисуй мне блок-схему». Написав это в пятый раз, пора подумать: не стоит печатать это вручную каждый раунд, нужно закрепить это как стиль.
- «Я хочу, чтобы он занимался чем угодно, только не написанием кода» — например, использовать его как помощника писателя или аналитика данных. По умолчанию системный промпт Claude Code настроен на «эффективное выполнение задач программной инженерии». Если вы попросите его написать роман, инструкции типа «сначала ограничь область изменений, напиши комментарии, проверь работу» будут только мешать.
Возвращаясь к сценарию с резюме из начала статьи — это типичный пример второго сигнала: вся личность по умолчанию в Claude Code настроена на программную инженерию. Если вы попросите его помочь с резюме, все эти инженерные инструкции станут помехой. Такую задачу «заставить его не быть инженером» не решить, написав в CLAUDE.md кучу фраз «пожалуйста, забудь, что ты программист». CLAUDE.md — это просьба, прикрепленная в конце, а output style — это нож, который переписывает его должностную инструкцию.
💡 Краткий итог: output styles изменяют системный промпт Claude — меняют роль, тон, формат. Они меняют «как отвечать», а не «что знать»; о них стоит вспомнить, когда: одно и то же требование печатается каждый раунд, или когда вы хотите, чтобы он занимался чем-то кроме программирования.
02 Четыре встроенных стиля: помимо стандартного, есть еще три готовых
Вам не нужно писать их самому, Claude Code уже имеет несколько встроенных стилей, готовых к использованию. Давайте сначала с ними познакомимся.
Стиль по умолчанию (Default), тот самый, который вы использовали на протяжении предыдущих тридцати одной статьи — его системный промпт специально настроен на «эффективное выполнение задач программной инженерии». Работать молча, делать изменения сдержанно, проверять работу там, где это необходимо — это «основная работа» Claude Code. Если нет особых требований, используйте его.
Кроме стиля по умолчанию, официально встроено еще три дополнительных стиля. Я объясню одной фразой, «чем они отличаются от дефолтного»:
Proactive (Проактивный) — смелее принимает решения сам, склонен действовать, а не планировать. Официальное описание: он будет «действовать немедленно, делать разумные предположения вместо того, чтобы приостанавливаться для рутинных решений, и отдавать предпочтение действиям над планированием». Проще говоря: меньше будет переспрашивать, меньше составлять планы, а при рутинных решениях будет действовать сам и двигаться вперед.
Здесь есть легко путающийся момент, который официально отмечен: Proactive предоставляет более сильное «руководство к автономному выполнению», чем автоматический режим, но его можно использовать без изменения вашего режима разрешений — поэтому перед запуском инструмента вы по-прежнему будете видеть запрос на разрешение. Режим разрешений (из статьи 20 «спрашивает ли стажер перед тем, как действовать») контролирует, «нужно ли останавливать и спрашивать вас», а Proactive контролирует, «насколько радикален его стиль работы» — это разные вещи, не путайте их.
Explanatory (Объясняющий) — по ходу работы выдает вам «порции знаний». Пока он помогает вам с инженерными задачами, он будет вставлять образовательные «Insights (инсайты)», помогая понять, «почему это реализовано так, какой паттерн используется в этой кодовой базе». Подходит, если вы хотите попутно разобраться в коде, а не просто получить результат.
Learning (Обучающий) — совместная работа в стиле «учимся, делая», еще и задает вам домашку. Это самый необычный стиль. Он не только делится инсайтами, как Explanatory, но и оставляет метки TODO(human) в коде, требуя, чтобы вы сами написали небольшой, стратегически важный фрагмент кода. Это значит, что Claude собирает каркас, а ключевые несколько строк оставляет вам — заставляя вас реально практиковаться, а не просто смотреть за его работой.
Сведем эти три стиля в реальную ситуацию, чтобы было понятнее:
- Одно и то же требование «добавить пагинацию к этому списку»: в режиме Proactive он, скорее всего, сразу начнет вносить изменения и меньше будет спрашивать «написать ли сначала план?»;
- В режиме Explanatory он будет писать код и параллельно объяснять: «здесь используется пагинация по курсору вместо offset, потому что... и в других местах проекта сделано так же»;
- В режиме Learning он напишет внешний каркас, а в самом главном теле функции оставит строку
// TODO(human): реализуйте парсинг курсора здесь, передав вам «ручку».
Сравнив их бок о бок, сразу становится ясно, когда кого вызывать:
| Встроенный стиль | Ключевое отличие от Default | Когда переключать | Будет ли ответ длиннее |
|---|---|---|---|
| Default (По умолчанию) | —— | Обычная программная инженерия, в большинстве случаев | Базовый |
| Proactive | Смелее принимает решения, меньше спрашивает, склонен к действию | Вас раздражает, что он переспрашивает, хотите дать ему свободу действий | Не обязательно |
| Explanatory | Попутно вставляет обучающие «Insights» | Хотите заодно понять логику реализации и паттерны кодовой базы | Длиннее (так задумано) |
| Learning | Объясняет + оставляет TODO(human) для вас | Сценарий обучения, хотите попрактиковаться | Длиннее (так задумано) |
Последний столбец «Будет ли ответ длиннее» нужно выделить отдельно: официально заявлено, что Explanatory и Learning по дизайну генерируют более длинные ответы, чем Default — потому что нужно вставлять объяснения и домашние задания. Длинный ответ означает больше токенов на вывод (о том, как тарифицируются токены, см. статью 06). Так что не держите их включенными постоянно как стиль по умолчанию; хотите поучиться — включайте, отучились — переключайте обратно на Default, чтобы сэкономить токены и не видеть каждый раз кучу объяснений.
Простой алгоритм использования: для повседневной работы используйте Default; столкнулись с незнакомым open-source репозиторием и хотите, пока он правит код, понять архитектуру — включайте Explanatory; если действительно хотите сесть и изучить новый фреймворк, не просто наблюдая, а написав пару строк своими руками, только тогда включайте Learning. Те, кто реже всего использует Proactive, обычно предпочитают, чтобы ИИ останавливался и давал взглянуть перед действием — это исключительно личные предпочтения. Если вас бесит медлительность, смело поступайте наоборот.
💡 Краткий итог: четыре встроенных режима — Default (работает молча), Proactive (меньше спрашивает, больше делает), Explanatory (делает и объясняет), Learning (объясняет и оставляет вам задания); последние два генерируют более длинные ответы и тратят больше токенов, включайте по необходимости, затем возвращайте по умолчанию.
03 Как переключать: команды /output-style больше нет
В этом разделе сначала вылью ушат холодной воды, потому что здесь кроется настоящая подстава со сменой версий — команда, которой до сих пор учат во многих старых туториалах и видео, теперь не работает.
Скорее всего, вы встретите такую рекомендацию: «используйте команду /output-style для переключения стиля». Эта отдельная команда была удалена. В официальной документации написано предельно ясно:
Отдельная команда
/output-styleбыла объявлена устаревшей в версии v2.1.73 и удалена в версии v2.1.91. Используйте/configили редактируйте настройкуoutputStyleнапрямую.
Итак, теперь для переключения стилей есть два правильных пути, я опишу оба.
Путь первый: через меню /config (рекомендуется, наглядно)
В сессии Claude введите /config, найдите в появившемся меню пункт Стили вывода (Output Styles) и выберите нужный стиль. Официальная цитата:
Запустите
/configи выберите Стили вывода, чтобы выбрать стиль из меню. Ваш выбор будет сохранен на уровне локального проекта в.claude/settings.local.json.
Обратите внимание на конец фразы — стиль, выбранный вами в меню, будет записан в .claude/settings.local.json текущего проекта. Это прямо продолжает тему прошлой (31-й) статьи про settings.json: settings.local.json — это тот файл, который действует на уровне проекта, принадлежит только вам и не попадает в контроль версий (его позиционирование мы разбирали в статье 31). Иными словами, переключенный вами стиль по умолчанию влияет только на вас и действует только в этом проекте, он не навязывается коллегам при коммите кода.
Путь второй: прямое редактирование поля outputStyle
Если не хотите кликать в меню, можно написать вручную. Просто добавьте поле outputStyle в файл settings:
{
"outputStyle": "Explanatory"
}В качестве значения впишите название стиля (для встроенных — Explanatory, Learning, Proactive, или имя пользовательского стиля). В какой файл settings вы это запишете, там оно и будет действовать: хотите сделать по умолчанию глобально — пишите в файл пользователя ~/.claude/settings.json, хотите только для этого проекта — пишите в файл уровня проекта. Правила приоритета (кто кого переопределяет) в точности такие же, как описано в статье 31, повторяться не будем.
Важный нюанс: когда это вступает в силу
Независимо от пути, после переключения есть правило «когда это начинает работать». Официальная документация отмечает очень точно:
Стили вывода являются частью системного промпта, который Claude Code читает один раз в начале сеанса. Изменения вступят в силу после
/clearили начала нового сеанса.
Аналогия: сценарий телепередачи выдается ведущему перед началом эфира. Если передача идет уже полчаса, а вы втихую подсовываете новый сценарий, в этом выпуске ничего не изменится — нужно ждать следующего. Со стилем вывода та же история: это часть системного промпта, и Claude читает его только один раз в начале сессии. Если вы переключили стиль посередине диалога, текущий сеанс мгновенно не трансформируется. Нужно либо очистить контекст командой /clear (в 19-й статье говорилось, что /clear — это «убрать всё со стола и начать заново»), либо просто открыть новую сессию — только тогда новый стиль выйдет на сцену.
Многие при первом переключении стиля спотыкаются именно здесь: меняют в /config стиль на Explanatory, возвращаются в диалог и видят, что он по-прежнему молча пишет код, ни слова не объясняя. И сразу мысль: «Эта функция сломалась!». И только через полчаса мучений приходит озарение — без /clear в этом диалоге все еще висит старый системный промпт. Сделайте /clear, и объяснения тут же появятся. Запомните эту подставу, это спасет вам десять минут нервотрепки.
💡 Краткий итог: старая команда
/output-styleудалена. Теперь стили переключаются двумя путями: через меню/config(сохраняется вsettings.local.json) или прямым редактированием поляoutputStyle; после переключения не забудьте сделать/clearили открыть новый сеанс, иначе стиль не применится.
04 Как создать свой собственный стиль: нужен только один Markdown-файл
Четырех встроенных стилей недостаточно? Вы легко можете написать свой собственный. Хорошая новость в том, что порог входа на удивление низок — один Markdown-файл и есть стиль вывода.
Официальная документация описывает структуру очень просто:
Пользовательский стиль вывода — это файл Markdown: frontmatter используется для метаданных, за которыми следуют инструкции, добавляемые к системному промпту.
Он состоит всего из двух частей: верхний frontmatter (метаданные, обрамленные ---) + основной текст ниже (инструкции, которые вы хотите добавить в системный промпт). Ниже мы создадим его в три шага.
Шаг первый: Сохраните файл в правильном месте
Как и другие точки расширения (Skill, Subagent), о которых мы говорили ранее, стили вывода делятся на три уровня хранения. То, где вы его сохраните, определит, в каких проектах его можно будет выбрать:
| Уровень | Каталог хранения | Кому доступен |
|---|---|---|
| Пользовательский | ~/.claude/output-styles | Можно выбрать во всех ваших проектах |
| Уровень проекта | .claude/output-styles (в корне проекта) | Только текущий проект, можно коммитить и шарить с командой |
| Управляемые политики | .claude/output-styles в каталоге управляемых настроек | Централизованно распространяется организацией |
Эта логика «уровень проекта vs пользовательский уровень» — та же самая концепция, что обсуждалась в статье 31 про настройки и в статье 25 про память: то, что вы используете каждый день и что применимо к разным проектам, кладите на уровень пользователя (~/.claude/output-styles); то, что специфично для одного проекта и чем вы хотите поделиться с соавторами, кладите на уровень проекта (.claude/output-styles), тогда это можно будет пушить через git.
Нужно запомнить еще одно правило именования:
Имя файла становится именем стиля, если вы не установите
nameво frontmatter.
То есть, если вы сохраните файл code-reviewer.md, его стиль по умолчанию будет называться code-reviewer; если только вы не пропишете name во frontmatter, тогда имя возьмется оттуда.
Шаг второй: Напишите frontmatter и основной текст
Давайте рассмотрим официальный пример — стиль «сначала рисуй диаграмму при каждом объяснении». Сначала покажу как есть, потом разберу по полям:
---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---
When explaining code, architecture, or data flow, start with a Mermaid diagram showing the structure, then explain in prose.
## Diagram conventions
Use `flowchart TD` for control flow and `sequenceDiagram` for request paths. Keep diagrams under 15 nodes.(Перевод основного текста: При объяснении кода, архитектуры или потока данных, сначала дай диаграмму Mermaid, показывающую структуру, а затем объясни словами. Соглашения по диаграммам: Используй flowchart TD для потока управления и sequenceDiagram для путей запросов. Ограничивай диаграммы до 15 узлов.)
Верхняя часть между --- — это frontmatter, нижняя часть — это инструкции основного текста. Этот основной текст будет добавлен в системный промпт Claude — и теперь при каждом объяснении он будет сначала рисовать диаграмму.
Frontmatter поддерживает всего четыре поля, давайте разберем каждое:
| Поле Frontmatter | За что отвечает | Значение по умолчанию |
|---|---|---|
name | Имя стиля (если не указано, используется имя файла) | Наследуется от файла |
description | Описание стиля, отображается в селекторе /config | Нет |
keep-coding-instructions | Оставлять ли встроенные инструкции по программной инженерии Claude Code | false |
force-for-plugin | Только для плагинов: при включении плагина автоматически применять этот стиль, без необходимости ручного выбора | false |
С первыми двумя все понятно — name это имя, а description это однострочное пояснение, которое вы увидите в меню. Последние два нужно обсудить отдельно, особенно keep-coding-instructions, так как это самый легко нажимаемый не туда переключатель во всем пользовательском стиле. Ему посвящен следующий раздел. Поле force-for-plugin касается только разработки плагинов (в 24-й статье мы говорили, что плагины могут упаковывать и распространять различные точки расширения, и стили вывода тоже), для создания собственных стилей в повседневной работе оно не понадобится, достаточно знать о его существовании.
Шаг третий: Переключитесь на ваш новый стиль
Сохраните файл, напишите содержимое, вернитесь в меню стилей вывода в /config, и ваш новый стиль появится в списке опций (рядом будет отображаться написанное вами description). Выберите его. И помните правило — вступает в силу после /clear или в новом сеансе.
💡 Краткий итог: Пользовательский стиль — это просто Markdown-файл: во frontmatter пишутся метаданные, в основном тексте — инструкции для добавления в системный промпт. Сохраняйте на правильном уровне (пользовательский для кросс-проектного использования, проектный для конкретного проекта). Имя файла = имя стиля. После написания выберите его в
/configи сделайте/clearдля применения.
05 Переключатель, в котором ошибаются чаще всего: keep-coding-instructions
В прошлом разделе была интрига вокруг поля keep-coding-instructions во frontmatter. Этому полю стоит посвятить отдельный раздел, потому что если ошибиться с ним, эффект от вашего стиля будет совершенно не таким, как вы ожидаете.
Сначала о том, чем оно управляет. Как говорилось ранее, системный промпт Claude Code по умолчанию напичкан «инструкциями по программной инженерии» — как ограничивать область изменений, как писать комментарии, как проверять работу. Когда вы пишете пользовательский стиль, эти встроенные инструкции по умолчанию «выбрасываются». Официальная цитата:
Пользовательский стиль вывода исключает встроенные инструкции Claude Code по разработке программного обеспечения... если только
keep-coding-instructionsне установлен вtrue.
По умолчанию это поле равно false, что означает: по умолчанию ваш пользовательский стиль полностью заменяет встроенные инженерные инструкции, оставляя только то, что написали вы. Оставить их или выбросить, зависит только от того, должен ли Claude в этом стиле по-прежнему писать код. Нужно задать себе лишь один вопрос:
«В этом стиле Claude по-прежнему пишет код?»
- Да, все еще пишет код, просто меняется стиль общения (например, «программируй как обычно, но каждый раз сначала рисуй диаграмму») → установите
keep-coding-instructions: true, чтобы сохранить встроенные инженерные инструкции. Пример «Diagrams first» из прошлого раздела как раз такой — он требует, чтобы «при объяснении сначала рисовалась диаграмма», но Claude продолжает нормально программировать, поэтому официально для него задано значениеtrue. - Вообще больше не пишет код (например, используете его как помощника писателя или аналитика данных) → опустите это поле (пусть по умолчанию будет
false), чтобы полностью избавиться от инженерных инструкций. Если он больше не программирует, инструкции типа «ограничь область изменений, напиши тесты» будут только мешать.
Официальная документация объясняет это правило очень четко, и его стоит запомнить дословно:
Сохраняйте их, когда вы меняете способ общения Claude, но он все еще программирует (например, если он всегда отвечает с использованием диаграмм). Опускайте их, когда Claude вообще не занимается программной инженерией (например, выступает в роли помощника писателя или аналитика данных).
Я сведу эти две ситуации в сравнительную таблицу, последствия ошибки будут видны как на ладони:
| Что должен делать ваш стиль | Каким должно быть keep-coding-instructions | Что будет, если ошибиться |
|---|---|---|
| ✅ Программирование как обычно, меняется только способ ответа (сначала рисует, фиксированный формат...) | true (сохранить инженерные инструкции) | ❌ Если установить в false: он потеряет инженерную дисциплину типа «ограничить область, проверить», и при редактировании кода будет допускать небрежности |
| ✅ Совершенно не программирует (писательство / анализ данных / перевод...) | Опустить (по умолчанию false) | ❌ Если установить в true: в его голове по-прежнему будут крутиться мысли о разбиении функций и добавлении тестов, и вы не получите того помощника писателя, которого хотели |
Возвращаясь к сценарию с резюме из раздела 01 — корень проблемы был именно здесь. Тогда нужна была личность «помощника писателя», которая вообще не должна нести в себе никаких инструкций по программированию. Если бы вы тогда умели писать пользовательские стили и опустили бы keep-coding-instructions (позволив инженерным инструкциям исчезнуть по умолчанию), он бы не пытался «разбить этот абзац на функции». Этот переключатель по сути отвечает на вопрос: «эта новая личность все еще подрабатывает инженером?».
💡 Краткий итог:
keep-coding-instructionsпо умолчаниюfalse, что полностью удаляет встроенные инженерные инструкции. Чтобы сделать выбор, задайте себе один вопрос: «в этом стиле Claude всё ещё программирует?» — если да, установитеtrue, чтобы сохранить их, если нет — опустите, чтобы убрать. Если перепутать, личность ИИ будет работать неправильно.
06 Как это работает под капотом: добавление фрагмента в системный промпт
В предыдущих разделах мы вскользь упоминали, что инструкции «добавляются в системный промпт», «читаются один раз в начале сессии», «выбрасывают инженерные инструкции». В этом разделе мы полностью разберем этот базовый механизм. Поняв, как он работает, вы ответите на все предыдущие «почему»: почему после смены стиля нужен /clear, почему он влияет на каждый ответ, и почему keep-coding-instructions может контролировать наличие инженерных инструкций.
В официальной документации принцип работы сведен к трем правилам. Я переведу их на понятный язык, чтобы их было легко запомнить:
- Все стили вывода добавляют свои пользовательские инструкции в конец системного промпта.
- Все стили вывода вызывают напоминания во время разговора, чтобы Claude придерживался инструкций стиля вывода.
- Пользовательские стили вывода исключают встроенные инструкции Claude Code по разработке программного обеспечения... если только
keep-coding-instructionsне установлен вtrue.
Правило первое: инструкции вашего стиля приклеиваются в самый «конец» системного промпта. Системный промпт — это базовые инструкции, которые загружаются в Claude в самом начале каждой сессии, а содержимое вашего output style добавляется в самый конец. Именно поэтому он влияет на каждый ответ в этой сессии, а не только на какую-то одну фразу.
Правило второе: в течение разговора система будет периодически «напоминать» Claude придерживаться стиля. При долгом общении ИИ часто забывает о настройках, заданных в начале. Механизм напоминаний периодически достает инструкции стиля и проговаривает их заново, чтобы Claude не отклонялся от курса.
Правило третье, как раз объясняющее переключатель из предыдущего раздела: пользовательские стили по умолчанию «вытаскивают» встроенные инженерные инструкции из системного промпта, оставляя только то, что написали вы; keep-coding-instructions: true говорит: «не вытаскивай, оставь». Вот почему это поле решает, «будет ли Claude по-прежнему программировать» — оно управляет наличием этого блока инженерных инструкций в системном промпте.
Схема того, как «собирается системный промпт»:
На схеме показано: в начале сессии Claude Code собирает системный промпт на основе выбранного вами стиля. Встроенные стили и пользовательские с keep=true содержат инженерные инструкции, а пользовательские с keep=false выкидывают их, оставляя только ваши пояснения. После сборки этот промпт действует на каждый ответ в данной сессии. И если вы измените стиль посередине, нужно сделать /clear или начать новую сессию, чтобы он заново собрал промпт с новым стилем (именно здесь кроется корень ошибки, описанной в разделе 03).
Напоследок пара слов о токенах (о тарификации см. статью 06). Официально сказано весьма честно:
Использование токенов зависит от стиля. Добавление инструкций в системный промпт увеличивает количество токенов на вход, хотя кэширование промптов (prompt caching) снижает эту стоимость после первого запроса в сеансе.
Говоря простым языком: инструкции стиля попадают в системный промпт и в некоторой степени занимают токены ввода. К счастью, у Claude Code есть prompt caching (кэширование промптов, которое кэширует неизменный системный промпт для повторного использования), поэтому после первого запроса в сессии эта стоимость снижается, и беспокоиться особо не о чем. Что действительно сильно увеличивает расход, так это такие стили, как Explanatory или Learning, которые «по дизайну генерируют длинные ответы» (основной расход идет на токены вывода). То же самое справедливо и для написанных вами стилей: чем длиннее инструкции и чем больше контента они заставляют генерировать Claude, тем больше токенов тратится. Используйте их по мере необходимости.
💡 Краткий итог: Инструкции output style добавляются в конец системного промпта, действуют на каждый ответ в сессии и периодически напоминаются ИИ. Пользовательские стили по умолчанию выбрасывают встроенные инженерные инструкции (оставляют их только при
keep=true). При смене стиля нужно сделать/clearдля пересборки. Стили занимают часть токенов, но выручает кэширование промптов; главный источник расходов — стили, генерирующие длинные ответы.
07 output styles vs CLAUDE.md / Skill / Subagent: В чем же разница?
Дочитав до этого момента, у вас, скорее всего, возникнет вопрос: чем эта штука отличается от изученных ранее CLAUDE.md, Skill и Subagent? Ведь все они звучат как «инструменты для настройки поведения Claude». В чем разница? В этом разделе мы все разложим по полочкам. В 30-й статье таблица «Как выбрать функцию» основывалась на потребностях, а здесь мы сфокусируемся именно на том, «как отличить их от output styles».
Сначала выделим самую уникальную черту output styles — он напрямую изменяет сам системный промпт, и это влияет на каждый ответ. Остальные функции либо «добавляют блок после системного промпта», либо «загружаются только в определенные моменты», ни одна из них не затрагивает основу системного промпта так глубоко. Официальная сравнительная таблица очень хорошо объясняет эту разницу. Я привожу ее, добавляя к каждому пункту пояснение простым языком:
| Функция | Принцип работы | Когда использовать её (а не output style) |
|---|---|---|
| Стили вывода | Прямое изменение системного промпта, применяется к каждому ответу | Вам нужно, чтобы в каждом раунде менялась «роль / тон / формат по умолчанию» |
| CLAUDE.md (Статья 18) | Добавляет пользовательское сообщение после системного промпта | Вам нужно залить соглашения по проекту и контекст кодовой базы, а не стиль общения |
--append-system-prompt | Добавляет содержимое к системному промпту, ничего не удаляя | Вы просто хотите добавить временные инструкции для одного конкретного вызова |
| Subagent (Статья 23) | Запускает дочернего агента со своим собственным системным промптом, моделью и инструментами | Вы хотите передать конкретную задачу отдельному помощнику с независимым контекстом, который вернет только результат |
| Skill (Статья 26) | Загружает специальные инструкции только при вызове / когда они релевантны | У вас есть переиспользуемый рабочий процесс (воркфлоу), который вызывается по требованию |
В этой таблице новичкам важнее всего различать первые две строки: output style vs CLAUDE.md. Их путают чаще всего, потому что оба инструмента «могут заставить Claude слушаться вас». Но суть у них абсолютно разная:
В CLAUDE.md хранится «содержимое / контекст», а в output style — «способ / роль». Один отвечает на вопрос «Что это за проект, какие тут соглашения?», а другой — на вопрос «Каким тоном и в каком формате ты должен отвечать?». Возвращаясь к аналогии из начала статьи: CLAUDE.md — это материалы по проекту для сотрудника, а output style — это его должностная инструкция. Вы не будете писать «Мы используем pnpm вместо npm» в output style (это проектное соглашение, ему место в CLAUDE.md), и точно так же не стоит писать «Пожалуйста, каждый раз сначала рисуй схему, а потом объясняй» как незыблемое правило в CLAUDE.md (это способ ответа, который должен стать output style). Разработчики специально оставили в документации указатель на этот счет, опасаясь путаницы:
Для инструкций о вашем проекте, соглашениях или кодовой базе используйте вместо этого CLAUDE.md.
Что касается --append-system-prompt, он кажется похожим на output style тем, что «оба трогают системный промпт», но один одноразовый, а другой постоянный: --append-system-prompt позволяет вам временно прилепить фразу в конец системного промпта при запуске claude, после чего о ней можно забыть; output style — это постоянная личность, которая сохраняется в настройках и применяется к каждой сессии. Это различие видно на уровне команд. Если нужно временно проверить какой-то стиль, вы запустите сессию так:
claude --append-system-prompt "В этот раз отвечай только на русском, максимально коротко"Закрыли и открыли заново — эффект пропал. Но если этот стиль нужен вам каждый день, не стоит каждый раз печатать этот параметр вручную, превратите это в output style, и дело с концом. Для временной проверки используйте первое, для фиксации — второе. В этом и заключается их разделение.
Также стоит сказать пару слов про Skill (Статья 26): Skill — это «загружаемый по требованию переиспользуемый рабочий процесс», он не занимает системный промпт постоянно. Он подключается только когда вы вводите /<имя> или когда Claude решает, что он релевантен; output style — это «настройка роли, которая всегда активна и применяется к каждому ответу». Один инструмент — это «рецепт, который достают по необходимости», другой — «стиль ведения шоу на протяжении всей передачи». Если нужен процесс для определенной задачи, создайте Skill; если нужен тон или роль для всего общения, создайте output style.
Есть еще одна частая путаница, но в обратном направлении. Если вы хотите, чтобы Claude «отвечал лаконично, без лишней воды», первая мысль — записать это в CLAUDE.md. В итоге это работает через раз — потому что стиль общения должен определяться изменением системного промпта (output style), а не напоминанием через «прикрепленный в конце запрос» (CLAUDE.md). Это та же самая ошибка, что и в 30-й статье, когда «трехсотстрочный API-интерфейс пытаются впихнуть в CLAUDE.md»: вещи кладут не в те ящики.
💡 Краткий итог: уникальность output styles в том, что он напрямую меняет системный промпт и применяется к каждому ответу; чаще всего его путают с CLAUDE.md — но CLAUDE.md хранит контекст проекта (содержимое), а output style — роль, тон и формат (способ); для временного добавления инструкций на один раз используйте
--append-system-prompt, а для помощника с независимой областью видимости — Subagent.
08 Практика: Создаем пользовательский стиль «Сначала рисуй, потом объясняй» и проверяем его работу
Хватит теории, перейдем к практике. В этом разделе мы с нуля создадим пользовательский стиль вывода, переключимся на него и воочию убедимся, что он работает. Мы реализуем классический официальный пример «сначала рисуй диаграмму, потом объясняй». Вам не потребуется никакой сложный проект, можно тренироваться в любой директории.
Шаг первый: Создаем файл стиля
Сохраним его в папку пользовательского уровня (~/.claude/output-styles), чтобы вы могли выбирать его в любом будущем проекте. Сначала создаем директорию, затем файл:
mkdir -p ~/.claude/output-stylesЗатем в удобном для вас редакторе создайте новый файл diagrams-first.md в папке ~/.claude/output-styles/ и вставьте туда следующее содержимое:
---
name: Diagrams first
description: Каждый раз при объяснении сначала рисует схему, потом объясняет текстом
keep-coding-instructions: true
---
При объяснении кода, архитектуры или потока данных, сначала предоставь диаграмму Mermaid, демонстрирующую структуру, а затем объясни словами.
## Соглашения для диаграмм
Используй `flowchart TD` для потока управления и `sequenceDiagram` для путей запросов. Ограничивай количество узлов на диаграмме до 15.Обратите внимание на keep-coding-instructions: true — поскольку в этом стиле Claude продолжает нормально программировать, у него просто появилась привычка «сначала рисовать», встроенные инженерные инструкции нужно сохранить (как мы обсуждали в правилах выбора в разделе 05).
Шаг второй: Переключаемся на этот стиль
Зайдите в сессию Claude, введите /config, перейдите в меню Output Styles (Стили вывода). Вы должны увидеть там Diagrams first (с написанным вами description рядом). Выберите его.
claudeВойдя, наберите /config, стрелками переместитесь на «Output Styles», нажмите Enter и выберите Diagrams first.
Ожидаемый результат: в меню появится пункт Diagrams first, рядом с которым будет висеть описание «Каждый раз при объяснении сначала рисует схему...». Наличие его в списке означает, что файл правильно распознан. Если его там нет, скорее всего, файл сохранен не в ту директорию, либо вы забыли написать --- во frontmatter.
Шаг третий: Делаем /clear, чтобы он вступил в силу
После выбора не спешите задавать вопросы — сначала выполните /clear (помните подвох из раздела 03? Системный промпт читается только в начале сессии):
/clearШаг четвертый: Задаем вопрос и проверяем, действительно ли он рисует сначала
После очистки задайте ему вопрос, «требующий объяснения», и посмотрите, послушно ли он выдаст схему в самом начале:
Объясни, как запрос на вход пользователя проходит от фронтенда к базе данных.Ожидаемый результат: в его ответе сначала появится диаграмма Mermaid (скорее всего, это будет sequenceDiagram, показывающая путь запроса: фронтенд → бэкенд → БД), и только затем пойдет текстовое объяснение. Вы увидели порядок «схема впереди, текст позади» = ваш пользовательский стиль сработал.
Для сравнения, вы можете через /config переключиться обратно на Default, затем сделать /clear и задать тот же самый вопрос — он выдаст только текст без диаграммы. Эта очевидная разница до и после — железное доказательство того, что output style действительно меняет то, «как отвечать».
Шаг пятый: Очистка (по желанию)
Если вы не хотите оставлять этот стиль, просто удалите файл:
rm ~/.claude/output-styles/diagrams-first.mdПосле удаления он исчезнет из меню /config. (Если в данный момент вы им пользуетесь, не забудьте сначала переключиться на Default в /config.)
Выполнив эти пять шагов, вы собственноручно прошли весь путь: «создание файла → переключение стиля → /clear для применения → проверка → удаление/очистка». В будущем при создании любого пользовательского стиля процесс будет таким же, изменится только содержимое инструкций и значение keep-coding-instructions в зависимости от задач.
💡 Краткий итог: Практика создания пользовательского стиля состоит из 5 шагов — создать файл
.md, выбрать в/config, сделать/clearдля применения, задать вопрос для проверки формата "диаграмма перед текстом", при необходимости удалить файл. Если переключиться на Default и задать тот же вопрос для сравнения, разница будет очевидна с первого взгляда.
09 Итоги
В этой статье мы подробно разобрали output styles — переключатель, который меняет то, «как Claude отвечает вам», а не то, «что он знает».
Давайте соберем ключевые моменты:
| Что вы хотите сделать | Как это сделать | Ключевой момент |
|---|---|---|
| Понять, что такое output styles | Изменяет роль / тон / формат в системном промпте | Меняет «как отвечать», а не «что знать» |
| Использовать готовые встроенные стили | Default / Proactive / Explanatory / Learning | Последние два генерируют более длинные ответы и тратят больше токенов, включайте по необходимости |
| Переключить стиль | Выбрать в меню /config или редактировать поле outputStyle | Старая команда /output-style удалена; после переключения обязателен /clear для применения |
| Создать пользовательский стиль | Написать Markdown-файл (frontmatter + основной текст) | Имя файла = имя стиля; на уровне пользователя — кросс-проектный, на уровне проекта — для текущего проекта |
| Решить, сохранять ли инженерные инструкции | keep-coding-instructions | Если продолжает программировать — true, если нет — опустить (по умолчанию false) |
| Отличить от CLAUDE.md | Смотрим, что хранится: «способ» или «содержимое» | Роль/тон/формат → output style; Контекст проекта/соглашения → CLAUDE.md |
Теперь вы должны уметь: в одном предложении объяснить, что именно меняют output styles; знать, когда включать каждый из четырех встроенных стилей; правильно переключать стили через /config (а не через устаревшую команду /output-style) и помнить о необходимости выполнять /clear; уметь самостоятельно писать пользовательские стили в Markdown, правильно используя переключатель keep-coding-instructions, а также четко понимать границы между output styles, CLAUDE.md, Skill и Subagent. Проще говоря, теперь у вас в руках «ключ для смены личности Claude» — одна и та же модель может по вашему желанию превращаться то в инженера, то в наставника, то в помощника писателя, подстраиваясь под нужную задачу.
Возвращаясь к фразе из начала статьи «Хочешь настроить — складывай в CLAUDE.md» — теперь вам всё должно быть ясно: Складывать контекст проекта в CLAUDE.md — это правильно, но всё, что касается изменения тона, роли и формата ответов (то, «как отвечать»), относится к ведению output styles. Раскладывайте вещи по правильным ящикам, и оба инструмента будут работать отлично.
Следующая статья: 33 «Хуки (Hooks)» — output styles меняют «как говорит Claude», но в конечном счете это зависит от того, что Claude «согласен» следовать инструкциям. Существует ли механизм, который сделает так, чтобы какое-то действие выполнялось железно, автоматически и не зависело от сознательности Claude? Например: «каждый раз, когда он изменяет файл, автоматически запускать форматирование» или «эта опасная команда должна быть жестко заблокирована». Именно для этого и существуют Хуки (Hooks) — автоматические триггеры, срабатывающие по событию, о которых мы вкратце упомянули в статье 30, а в следующей разберем досконально. Подумайте: какие вещи вы уже много раз просили Claude делать, но теперь хотите получить железную гарантию того, что «он точно сделает это каждый раз»?