Сначала задайте контекст продукта. Пожалуйста.

Почему результат так сильно плавает

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

Запрос: «Напиши критерии приёмки для тикета: пользователь может настраивать параметры провайдера ИИ».

Первая попытка — без контекста: результат выглядит как дежурный список. «Пользователь может выбрать провайдера ИИ из выпадающего списка. Пользователь может сохранить настройки. Пользователь видит сообщение об успехе». Это мог бы быть любой продукт, любая платформа и любой десяток лет. Формально ничего плохого. Практической пользы почти ноль.

Вторая попытка — с контекстом продукта: результат уже ссылается на страницы администратора в Jira Cloud, права Forge resolver, проверку API-ключей по каждому провайдеру (OpenAI, Anthropic, Google, Mistral, xAI), поведение на уровне организации и проекта, а также на действия записи, завязанные на лицензии. Он упоминает, что настройки сохраняются через @forge/sql, а интерфейс использует компоненты Atlaskit и токены xcss. Это уже выглядит так, как будто ответ писал человек, реально работавший в этой кодовой базе.

Модель не поменялась. Температура не поменялась. Поменялся только вход. И этот разрыв — между общим и точным — и есть вся тема статьи.

Когда результат от ИИ кажется нестабильным, первый импульс — винить модель: сменить провайдера, поднять тариф, подкрутить температуру. Почти всегда это не тот рычаг.

Каждый запрос стартует с нуля. У модели нет памяти о вашем продукте, пользователях, ограничениях или прошлом разговоре, если вы явно не дали ей эту информацию. «Напиши критерии приёмки» означает совсем разное для встроенного в Jira приложения на Forge для продуктовых и инженерных команд на 10–100 человек и для потребительского мобильного приложения про фитнес.

Модель отвечает на тот мир, который вы ей описали. Если не описать ничего — она выдумает свой. И почти никогда это не будет ваш мир.

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

Если хочешь сначала посмотреть на более широкую картину того, почему это так болезненно проявляется именно в Jira, начни со статьи ИИ не чинит рассинхрон. Он его прячет.

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

Четыре слоя контекста

Контекст продукта — это не один большой комок текста. Он естественно распадается на четыре слоя, и каждый делает свою работу.

• Описание продукта объясняет, что делает продукт, для кого он и какие результаты важны — рабочую суть, а не маркетинговый текст. Разница огромна. «Инструмент управления проектами для команд» может описывать что угодно. А вот «Just — это встроенный в Jira ИИ-ассистент для продуктовых и инженерных команд на Jira Cloud. Его основная задача — превращать расплывчатые Jira-задачи в структурированные планы выполнения: уточнения, пошаговые планы и аккуратную запись обратно в поля Jira — не выходя из панели задачи. Это не чат-бот и не отдельный инструмент. Он построен на Atlassian Forge» — уже описывает один-единственный продукт.
• Аудитория описывает, кто эти пользователи, что им нужно, чего они ожидают и чего не знают.
• Дизайн-язык описывает визуальные паттерны, библиотеку компонентов, привычки взаимодействия и то, чего вы принципиально не делаете.
• Стек и ограничения описывает реальные фреймворки, пределы среды выполнения, интеграции и решения, которые явно находятся вне допустимых границ.

Плохая версия каждого поля подходит тысячам продуктов. Хорошая — только одному. В этом и есть главный тест.

Аудитория — место, где общий контекст ломается

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

Полезное описание аудитории конкретно объясняет состав команды, уровень знакомства с ИИ, ожидания по доверию и то, чего пользователи не хотят. Для Just это значит продактов и сильных инженеров в командах Jira Cloud на 10–100 человек, со средним уровнем знакомства с ИИ, которые сами управляют API-ключами и больше ценят надёжный результат, чем эффектную картинку.

Строка «Не для» важна не меньше. Фраза о том, что продукт не для команд вне Jira Cloud и не для пользователей, которые ждут полностью автономных агентов, сразу убирает целые классы неверных допущений ещё до их появления.

Именно так контекст становится привязанным к реальности, а не декоративным. Модели не просто говорят, кто пользователь. Ей одновременно объясняют, в каком мире этот пользователь работает и какие сценарии для него будут ощущаться неправильными.

Достань то, что уже существует

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

Из репозитория: направь агента для кода — Claude Code, Codex или что-то подобное — на кодовую базу и попроси краткую сводку в markdown, которая покрывает назначение продукта, стек, границы реализации и известные ограничения. Хорошо структурированный репозиторий выдаёт рабочий первый черновик за считанные минуты.

Из дизайн-файлов: зафиксируй название библиотеки компонентов, 3–5 ключевых паттернов взаимодействия, на которых держится продукт, и 3 вещи, которые интерфейс никогда не делает. Анти-паттерны здесь так же важны, как и паттерны.

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

Из собственной головы: если ничего из этого пока нет, просто открой пустой документ и напиши по одному короткому абзацу на каждое поле. Это будет неровно. Но даже неровный контекст всё равно намного лучше, чем никакого.

Тебе не нужна идеальная документация. Тебе нужно компактное и честное описание мира, в котором живёт продукт.

Сохрани один раз и используй везде

Контекст начинает окупаться только тогда, когда его можно переиспользовать. Написать его один раз и вставить в одну сессию полезно для этой сессии. Сделать его постоянным — полезно для всех последующих.

• В Just в административной панели есть отдельные поля для каждого из четырёх слоёв: описание продукта, аудитория, дизайн-язык и стек. Ты один раз вставляешь контент в каждое поле на проект, и все будущие инсайты, уточнения, планы и шаги выполнения для этого проекта автоматически получают этот фундамент.
• Если ты не используешь Just, заведи один файл context.md в корне репозитория или в общей документации. Структурируй его на те же четыре секции. И вставляй его в начало любой ИИ-сессии — помощники для кода, чат-инструменты, генераторы документов. Формат менее важен, чем привычка: сначала контекст, потом запрос.

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

Контекст — это не магия промптов

Контекст продукта — это не магия промптов. Не трюк, не шаблон и не хитрый приём. Это просто тот же брифинг, который ты бы дал новому подрядчику в первый день: вот что мы строим, для кого, как это должно выглядеть и на чём всё это работает.

Команды, которые делают это один раз — и затем последовательно переиспользуют, — получают результат, который ощущается так, будто его делал человек, действительно понимающий продукт. Потому что во всех функциональных смыслах так и есть. Модель не стала умнее. Ты просто перестал просить её гадать.