![]()
Список коммитов рассказывает, что меняли разработчики. Пользователю нужно понять, что теперь можно сделать и касается ли это его. Нейросеть помогает перевести технические записи в понятный язык, но она не знает сама, попала ли функция в выпуск и доступна ли всем.
В Чатиуме можно собрать редактор новостей продукта с подтверждёнными изменениями, условиями доступности и черновиком публикации. Тогда красивый текст не обгонит реальный выпуск.
Создай редактор новостей продукта. Для изменения храни прежнее и новое поведение, аудиторию и статус выпуска. Предлагай понятный текст только для подтверждённых возможностей. Дай проверять формулировки, группировать связанные изменения и сохранять опубликованные версии.
Коммит не равен пользовательской возможности
Изменение может быть внутренним, экспериментальным или ещё не включённым. Исправление кэша не обязательно означает, что продукт «стал в два раза быстрее». Переименование компонента вообще может не менять видимое поведение.
Поэтому модели нужны дополнительные сведения: что происходило раньше, что происходит теперь, где это доступно и как проверить. Если этих данных нет, лучше получить список вопросов редактору, чем выдуманную новость.
Пример: исправили возврат к списку
Техническая запись условного изменения: «Сохраняем параметры фильтра при переходе из карточки». Пользовательский смысл: после просмотра заявки человек возвращается к тому же отфильтрованному списку и продолжает работу.
Хорошая новость может звучать так: «Выбранные фильтры теперь сохраняются при возврате из заявки. Можно открыть карточку и продолжить разбор того же списка». Она описывает наблюдаемое изменение без обещания, что вся навигация стала идеальной.
| Техническое изменение | Что нужно уточнить для публикации |
|---|---|
| Сохранение фильтра | На каких страницах и при каких переходах |
| Новый экспорт | Кому доступен и какие данные входят |
| Исправление ошибки | Какой сценарий раньше не работал |
| Внутренняя оптимизация | Есть ли измеримый пользовательский эффект |
Объединяйте по задаче пользователя
Несколько коммитов могут относиться к одному улучшению. Если публиковать каждый отдельно, новость превратится в технический журнал. И наоборот, один большой коммит может содержать несколько независимых пользовательских изменений.
Попросите модель группировать по сценарию: поиск заявки, настройка доступа, подготовка отчёта. Для каждого пункта сохраните связь с исходными записями, чтобы редактор мог проверить, откуда взялась формулировка.
Не скрывайте ограничения, которые влияют на использование. Если функция доступна только руководителю, это часть новости. Если старые записи не поддерживают новый формат, нужно объяснить поведение, а не просто сообщить «теперь всё можно выгрузить».
Короткий вызов GPT Luna в Чатиуме
В sourceText передайте подтверждённые изменения с описанием поведения и статуса выпуска. Код не определяет автоматически, что уже развёрнуто на сервере.
Это фрагмент серверного обработчика Чатиума. ctx передаёт платформа, sourceText содержит проверенный текст из формы. done и failed — заранее зарегистрированные маршруты app.function для результата и ошибки. Они проверяют, что вызов пришёл от приложения start: caller.type === 'plugin' && caller.appSlug === 'start'.
import { startCompletion } from '@start/sdk'
const { completionId } = await startCompletion(ctx, {
model: 'openai/gpt-6-luna',
system: 'Сгруппируй подтверждённые изменения по пользовательским задачам. Опиши прежнее и новое поведение, сохрани ограничения. Не объявляй невыпущенные функции доступными и не выдумывай показатели улучшения.',
messages: [{
role: 'user',
content: [{ type: 'text', text: sourceText }],
}],
onCompletionCompleted: done,
onCompletionFailed: failed,
})
Метод возвращает completionId. Сам ответ приходит позже в onCompletionCompleted, ошибка — в onCompletionFailed; до этого приложение показывает ожидание. Это схема вызова, а не полный код приложения.
Встроенный помощник Чатиума создаёт редактор, историю и согласование. Черновик новости связывается с версией выпуска. Если статус функции поменялся, текст возвращается на проверку, а не публикуется по старому плану.
Как проверить текст перед публикацией
Попросите человека открыть продукт и повторить описанный сценарий. Если новость обещает экспорт, он должен найти действие и получить ожидаемый файл под подходящей ролью. Такая проверка связывает слова с реальным поведением.
Отдельно проверьте числа и сравнительные обещания. «Быстрее», «удобнее» и «надёжнее» требуют понятного основания, если используются как фактические заявления. Иногда точное описание изменения полезнее общей оценки.
Частые вопросы
Нужно ли сообщать о каждом исправлении?
Нет. Выбирайте изменения, которые помогают пользователю понять поведение продукта или вернуться к ранее проблемному сценарию. Внутренние детали можно оставить технической команде.
Можно ли писать новости только по названиям коммитов?
Для черновой группировки — иногда. Для публикации обычно нужны контекст и подтверждение доступности. Название коммита не является полной спецификацией.
Как сделать из новости рассылку?
Выбрать адресата, повод и нужное действие. Отдельный рабочий процесс описан в редакторе рассылок, а приёмка функции — в проверке результата Codex.