Сюжет и изображения я разрабатывал с Codex, программирование поручал Claude Code. На вычитке эти занятия встречаются: новая реплика должна звучать по-человечески, но кнопка обязана по-прежнему запускать то действие, которое написано в коде. Просьба «сделать текст живее» без этой границы слишком свободна.
Открыть игру «Осквернённый Грааль: Ненаписанная легенда».
Два прохода редактуры сохранились в коммитах 22 сентября. По ним можно точно сравнить формулировки, но нельзя восстановить, кто предложил каждое слово. Ниже — реальные замены и устроенный в проекте процесс работы с помощником, без приписывания конкретной реплики конкретной модели.
Что дать Codex перед редактурой
В локальном пакете skill translations направлял к терминологии мира и DIALOGUE_GUIDE. Он отделял интерфейсные сообщения от авторских текстов, запрещал раскрывать тайны через клиентский словарь и добавлять незапрошенную английскую локализацию. Для этой задачи слово translations означало работу с текстовым контрактом проекта, а не обязательный перевод.
Процедура frontend-design начинала с решения игрока и доступного ему знания: происходящее, известная цена, действие, последствие. Поэтому помощнику нужен контекст сцены вместе с ценой и результатом кнопки. Если передать только список подписей, он не сможет отличить выразительную замену от ложного обещания.
Человеческое решение на входе — голос персонажа и неизменяемый смысл. Я могу выбрать более мягкую реплику, но не должен незаметно отменить нехватку еды или цену помощи. Полезный результат от ИИ — варианты с объяснением изменения, а не самовольное улучшение мотивов персонажа.
Кнопка должна называть действие
В прологе была подпись «Сначала помочь соседу с его работой». После вычитки она стала «Сначала помочь соседу с тележкой». Смысл выбора не перевёрнут: герой по-прежнему помогает и тратит время. Но действие теперь можно представить до нажатия.
Такая замена не требует расширять сцену. Она использует уже существующий предмет и убирает обобщение. Игрок видит, что именно обещает кнопка, а следующая реплика про колесо продолжает тот же поступок.
При работе с ИИ это полезный критерий отбора: не просто попросить «сделать живее», а проверить, называет ли подпись конкретное действие из сцены. Модель может предложить выразительный глагол, который обещает больше, чем исполняет код. Тогда красивую замену нужно отклонить.
Подсказка объясняет отказ
Другой пример — закрывающийся брод. Старая подсказка: «Брод закроется в 10:00: этот путь уже не закончится раньше». Новая: «Брод закроется в 10:00, и перейти его до этого ты уже не успеешь».
Вторая формулировка связывает срок с действием героя. Не «путь заканчивается», а человек не успевает перейти. При этом время не спрятано за атмосферой: игрок сохраняет числовой ориентир, необходимый для решения.
Это важная граница художественной вычитки интерфейса. Техническая точность не означает технический язык. Можно говорить естественно и всё ещё явно называть цену, срок и причину недоступности.
Не потерять намерение персонажа
В первом проходе изменилось приглашение к ужину. Фраза «Странников кормить нечем. Для тебя суп найдётся» получила связку: «Странников кормить особо нечем, но для тебя суп найдётся». Изменение небольшое, но отношение между нехваткой еды и личным приглашением теперь прочитывается без резкого обрыва.
В соседнем описании «один удержать ось и поставить колесо он не может» заменили на «одному ему не удержать ось и не надеть колесо». Редактура убрала неловкую конструкцию, сохранив наблюдаемую ситуацию: соседу нужна помощь с тележкой.
Такие пары удобны для обсуждения с помощником. Нужно показать исходную сцену, предполагаемое намерение говорящего и то, что нельзя поменять. Без этого запрос на улучшение легко превращает сдержанного персонажа в многословного рассказчика или добавляет неподтверждённый мотив.
Передать правку программированию без смены правил
Второй коммит меняет исполняемые главы, авторский каталог, генераторы, правила и тесты. Это фактический состав diff. Он показывает, что текст имеет потребителей: правка одного готового JSON могла бы пропасть при следующей сборке. Но diff не доказывает, каким клиентом сделана каждая строка.
В моей общей схеме программирование выполнял Claude Code. На такой передаче ему требуется согласованный текст и список мест, где он хранится или проверяется. Проектный repo-discovery предписывает найти потребителей контракта, а delivery-docs — обновить документацию вместе с результатом. Эти процедуры описывают, как не потерять редакторское решение при технической синхронизации.
Реконструкция ограниченного поручения:
Применить согласованную подпись в источнике и производных файлах.
Сохранить ID выбора, условия, цену и эффекты.
Найти тесты, которые ищут старый текст; обновить только после
проверки, что они по-прежнему выбирают тот же игровой вариант.
Указать, распространяется ли правка на уже начатые кампании.Последний вопрос нельзя решать по красоте фразы. Сохранения привязаны к релизам контента; изменение исходников само по себе не разрешает заменить документ старой кампании. Редакторская приёмка и политика обновления — отдельные решения.
Два прохода проверки вместо одного «стало лучше»
Сначала я читаю новые фразы как игрок: понятно ли действие, сохранён ли голос, нет ли языка разработчика. Затем проверяю связку с программой: та же кнопка, то же условие, та же цена. В коммите есть изменения браузерных и серверных тестов; при подготовке статьи эти тесты не запускались заново.
Роль code-reviewer в пакете позволяет оформить отдельное поручение на diff и зависимости. Это подготовленная инструкция, не доказательство, что историческую вычитку делал отдельный субагент. Если подключать проверяющего сейчас, ему стоит дать один риск — например, не изменилась ли цена помощи вместе с подписью.
В тот же день отдельный коммит переработал игровой экран. Это не результат одной замены слов: текст ещё нужно увидеть среди соседних блоков и на телефоне. Процедура visual-qa прямо различает браузерный просмотр и чтение исходников. Окончательно принять реплику должен человек, видящий и сцену, и действие, которое она обещает.
