Сборник промптов для Kimi K3.1 Pro: 5 сценариев, которые можно скопировать и сразу получить результат

Kimi K3.1 Pro уже доступна на HiAPI, новым пользователям при регистрации начисляется 200 кредитов. Ниже — 5 реально рабочих промптов, охватывающих диагностику сбоев, ревью кода, сравнение решений, анализ длинных документов и обработку данных. Каждый промпт можно скопировать напрямую, а по ссылке он подставится автоматически.

1. Диагностика сбоев: найти первопричину по логам ошибок

Отдайте модели лог ошибок и попросите провести послойную проверку по цепочке вызовов, выдать первопричину и шаги исправления, а не общие фразы вроде «проверьте сетевое соединение».

Пример вывода: модель перечислит цепочку проверки (например, конфигурация обратного прокси Nginx → состояние работоспособности бэкенд-сервиса → пул подключений к базе данных), для каждого уровня приведёт команды проверки, ожидаемый результат и аномальное поведение, затем локализует первопричину (например, «исчерпание пула подключений PostgreSQL приводит к таймауту новых запросов в очереди») и предложит двухшаговый план исправления.

Ты инженер по диагностике бэкенда. Ниже приведён лог ошибок из производственной среды. Проведи диагностику по следующим шагам:

1. Построчно разбери ключевые моменты времени и коды ошибок в логе
2. По цепочке вызовов (точка входа → промежуточное ПО → сервис → база данных) послойно проанализируй возможные причины
3. Укажи наиболее вероятные первопричины (не более 3)
4. Для каждой первопричины приведи команды проверки и шаги исправления

Формат вывода:
## Разбор лога
## Послойная проверка
## Анализ первопричин
## Шаги исправления

Лог:
[вставьте ваш лог ошибок]

Диагностировать сбои с этим промптом →

kimi-k3.1-pro, reasoning_effort: high. Ориентир: около $0.03 (вход ~3000 токенов + выход ~2000 токенов).

Ключевые моменты: в промпте заданы структура вывода и цепочка проверки, поэтому модель не пропускает шаги и не выдаёт бесполезные советы вроде «попробуйте перезагрузить». Для задач диагностики reasoning_effort лучше ставить high или max — при low модель иногда пропускает промежуточные уровни и сразу угадывает вывод.

2. Ревью кода: структурированный вывод JSON

Попросите модель проверить код и вывести JSON — его можно сразу сохранить в базу и использовать для проверок в CI. Режим json_schema в K3.1 Pro гарантирует, что поля вывода, типы и значения перечислений строго соответствуют вашему определению.

Пример вывода: модель вернёт JSON-объект, содержащий массив issues (каждый элемент — с полями file, line, severity, category, description, suggestion), объект summary (со счётчиками по уровням серьёзности) и overall_score (0-100). Уровни серьёзности строго классифицируются по четырём категориям: critical / major / minor / style.

Тебе нужно проверить приведённый ниже код. Строго выведи результат проверки в формате JSON Schema, не выводи никакого текста вне JSON.

Аспекты проверки:
- Логические ошибки и граничные условия
- Проблемы производительности (N+1 запросы, лишние циклы)
- Риски безопасности (SQL-инъекции, XSS, непроверенный ввод)
- Стиль кода и читаемость

Схема вывода JSON:
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

Код:
[вставьте ваш код]

Проверить код с этим промптом →

kimi-k3.1-pro, response_format: json_schema. Ориентир: около $0.04 (вход ~4000 токенов + выход ~2500 токенов).

Ключевые моменты: чтобы закрепить формат вывода, необходимо передать response_format: {"type": "json_schema", "json_schema": {...}}. Дублирование Schema в самом промпте — страховка на случай, если json_schema не сработает: модель всё равно выведет в нужном формате. Для severity используются значения перечисления, а не описание на естественном языке, — это гарантирует, что нижестоящая система сможет сразу разветвлять логику по значению.

3. Сравнение технических решений: многомерная таблица оценок

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

Пример вывода: модель сгенерирует сравнительную таблицу по 5-6 измерениям, включая производительность, сопровождаемость, зрелость экосистемы, стоимость обучения, соответствие команде и т. д.; по каждому пункту выставит оценку от 1 до 10 и приведёт обоснование в одно предложение, затем вычислит взвешенный итоговый балл и даст рекомендацию.

Мне нужно выбрать одно из двух технических решений: вариант A или вариант B. Сравни их последовательно по следующим 6 измерениям, выставь оценку по каждому измерению (1-10) и напиши обоснование в одно предложение, в конце вычисли взвешенный итоговый балл и дай рекомендацию.

Измерения сравнения и веса:
- Производительность (вес 25%)
- Сопровождаемость (вес 20%)
- Зрелость экосистемы (вес 20%)
- Стоимость обучения (вес 15%)
- Соответствие текущему технологическому стеку команды (вес 15%)
- Активность сообщества (вес 5%)

Формат вывода:
| Измерение | Оценка варианта A | Оценка варианта B | Обоснование |
|---|---|---|---|
| Производительность | | | |
| ... | | | |
| **Взвешенный итоговый балл** | | | |

Последний абзац: обоснование рекомендации (не более 3 предложений)

Вариант A: [опишите вариант A, например, технологический стек, архитектуру, ключевые зависимости]
Вариант B: [опишите вариант B, например, технологический стек, архитектуру, ключевые зависимости]
Контекст: [опционально: размер команды, текущий технологический стек, бизнес-сценарий]

Сравнить решения с этим промптом →

kimi-k3.1-pro, reasoning_effort: high. Ориентир: около $0.04 (вход ~3000 токенов + выход ~3000 токенов).

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

4. Анализ длинных документов: извлечение ключевой информации из целого руководства

Загрузите десятки страниц технической документации, протоколов встреч или отзывов пользователей и попросите модель извлечь именно те моменты, которые вас действительно интересуют. Контекст K3.1 Pro в 1M токенов легко вмещает целое руководство.

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

Ниже приведён полный технический документ. Извлеки ключевую информацию по следующей структуре:

1. Обзор темы и структуры документа (один абзац)
2. Ответь на следующие конкретные вопросы:
   - [вопрос 1]
   - [вопрос 2]
   - [вопрос 3]
3. Все ограничения и предпосылки, упомянутые в документе (перечисли по пунктам)
4. Легко упускаемые граничные случаи (не менее 3)
5. Противоречивые или неясные места в документе (если есть)

Документ:
[вставьте полный текст документа]

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

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. Ориентир: около $0.07 (вход ~15000 токенов + выход ~3000 токенов). Токены входных данных для длинного документа рассчитываются по фактической длине документа; здесь приведена консервативная оценка примерно на 10 тысяч иероглифов.

Ключевые моменты: замените вопросы 2 и 3 на то, что вы действительно хотите узнать из документа, не оставляйте шаблонные [вопрос 1]. Для очень длинных документов ставьте reasoning_effort в max — при low в сценариях с длинным контекстом легко теряется информация. При повторном анализе одного и того же длинного документа начиная со второго раза чтение из кеша стоит всего $0.2156/M токенов (1/10 от цены входа).

5. Анализ данных: генерация отчёта с инсайтами из сырых данных

Дайте фрагмент данных в формате CSV или JSON и попросите автоматически посчитать статистику, выявить тренды, найти аномалии и сразу вывести отчёт, который можно вставить в еженедельный отчёт.

Пример вывода: модель сначала сделает обзор данных (число строк, поля, временной диапазон), затем выведет статистику ключевых метрик, описание трендов, отметит аномальные точки данных и в конце даст 2-3 выполнимые рекомендации.

Ты аналитик данных. Ниже приведены сырые данные. Выполни следующий анализ и выведи отчёт:

1. Обзор данных: число строк, список полей, временной диапазон, полнота данных (доля пропусков)
2. Статистика ключевых метрик: автоматически выбери подходящие статистики по типу поля
   - Числовые поля: среднее, медиана, максимум, минимум, стандартное отклонение
   - Категориальные поля: Top 5 категорий и их доли
3. Анализ трендов: если есть поле времени, агрегируй основные метрики по неделям/месяцам и опиши тренд
4. Обнаружение аномалий: отметь точки данных, отклоняющиеся от среднего более чем на 2 стандартных отклонения
5. Выводы и рекомендации: 2-3 выполнимые рекомендации

Формат вывода: отчёт в Markdown, заголовки по разделам, ключевые числа выделены жирным.

Данные:
[вставьте ваши данные CSV или JSON]

Проанализировать данные с этим промптом →

kimi-k3.1-pro, reasoning_effort: high. Ориентир: около $0.03 (вход ~2000 токенов + выход ~2000 токенов). При большом объёме данных входные токены соответственно увеличатся.

Ключевые моменты: в данных не должно быть конфиденциальной информации (реальные ID пользователей, номера телефонов, ключи). Если строк в данных много, первых 200 строк достаточно, чтобы модель обнаружила тренды и аномалии — K3.1 Pro не нужны все данные, чтобы дать точные статистические выводы.

Общие принципы написания промптов

K3.1 Pro — это рассуждающая модель, поэтому в промпт не нужно добавлять универсальные префиксы вроде «Ты профессиональный XX». Три ключевых принципа:

1. Давайте структуру, а не образ мыслей: определите формат вывода и обязательные измерения, а как их заполнять, пусть модель решает сама, — это работает лучше, чем пошаговое руководство.
2. Задавайте конкретные вопросы: «проанализируй этот лог» хуже, чем «найди в этих 500 строках лога самое раннее возникшее отклонение, его вышестоящего вызывающего и укажи, какие конфигурации нужно изменить для исправления».
3. Выбирайте reasoning_effort под сценарий: для диагностики и длинных документов — high или max, для простых вопросов и преобразования форматов — low; разница в стоимости может быть в разы.

Откройте страницу модели Kimi K3.1 Pro, выберите сценарий, скопируйте промпт и начинайте генерировать.

Серия статей о Kimi K3.1 Pro

• Страница модели
• Как пользоваться API? Первый вызов за 5 минут
• Сравнение цен
• Kimi K3.1 Pro vs Claude Opus 5.5