• Агент ведёт реестр запросов вне утверждённого объёма в реальном времени, строка за строкой
  • Разделитель — одно правило: замечание к спецификации бесплатно, изменение утверждённой стадии — платно
  • У клиента и студии одна согласованная запись того, что изменилось после утверждения

Задача

Две недели продакшна. Клиент пишет между обсуждением ракурса и вопросом о сроках: «а эту деталь надо развернуть в другую сторону». Продюсер читает. Через двести сообщений он уже не помнит, было это в объёме или нет, и вопрос откладывается на «разберёмся в конце». В конце переделка сделана, в счёт не попала, расход тихо проглочен. Сорок таких мелочей за проект съедают маржу, и ни одну из них никто не назовёт.

flowchart LR
    M[Правка<br/>в чате] --> F[Через 200 сообщений:<br/>в объёме или нет?]
    F --> L[Разберёмся<br/>в конце]
    L --> X[Переделка<br/>не в счёте]
    classDef key stroke:#FF3600,stroke-width:2px
    class X key

Это структурный провал, а не лень. У продюсера на живом проекте четыре ограничения, которые дисциплиной не снимаются: объём (тысячи сообщений в двух чатах за месяц, каждое требует вопроса «это расширение объёма?»), непостоянство критериев (одна и та же правка утром в объёме, в полночь — вне), давление отношений (мелочи списываются, чтобы не портить контакт, спорят только о крупном) и невозможность восстановить список задним числом, потому что реконструкция по истории чата стоит столько же, сколько сам проект. Продюсер ведёт себя рационально. Ему не хватает не аккуратности, а свободного внимания. У агента оно есть.

Приём

Агент ведёт реестр: структурированный учёт каждого расширения объёма, замеченного в чате, с классификацией против стадий утверждения и сохранением контекста исходного сообщения. Реестр ведётся открыто: у клиента и студии есть одна согласованная запись того, что изменилось после утверждения, и к моменту счёта она существует как проверяемый артефакт, а не как упражнение на память.

Реестр держится на трёх вещах.

Стадии утверждения. Производство разложено на именованные стадии, у каждой — явное событие утверждения. В CG-пайплайне это, например, входные файлы, моделирование, текстуры, камера, свет и рендер; каждая следующая стадия строится на утверждённой предыдущей.

Без стадий у реестра нет опоры: проект, идущий как одна лента «итерируем», не имеет базы «утверждено», от которой можно отсчитывать изменения.

flowchart LR
    S1[Входные<br/>файлы] --> S2[Моделирование]
    S2 --> S3[Текстуры]
    S3 --> S4[Камера<br/>и свет]
    S4 --> S5[Рендер]

Разделитель. Одно предложение: замечание по исходной спецификации (чертежи, фото, утверждённые файлы) — бесплатно; новые вводные или изменение уже утверждённой стадии тарифицируются. Это весь интеллектуальный контент реестра. Оно не требует интеллекта — оно требует последовательного применения, и именно в этом агент силён. На каждое сообщение клиента три вопроса: какая модель, какая стадия, по какую сторону разделителя.

flowchart TD
    M[Сообщение клиента] --> Q1[Какая модель,<br/>какая стадия?]
    Q1 --> Q{По какую сторону<br/>разделителя?}
    Q --> F[Замечание<br/>по спецификации:<br/>бесплатно]
    Q --> R[Новые вводные или<br/>правка утверждённого]
    R --> L[Строка<br/>в реестре]
    classDef key stroke:#FF3600,stroke-width:2px
    class L key

Строка. Пять колонок: модель, стадия, описание, категория стоимости, контекст. Контекст — это одно предложение с указанием породившего сообщения:

Модель A | Сборка | Развернуть деталь, пересчитать задние ракурсы
| переделка после утверждения
| клиент заметил в чате: деталь собрана в обратную сторону

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

За четыре недели одного проекта набралось 22 строки. Две показывают, как работает классификация.

Развёрнутая деталь. Правка маленькая, но стадия уже утверждена, значит, по разделителю это строка в реестре. Без разделителя её списали бы как мелочь.

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

flowchart TB
    subgraph t[До рендера]
        direction LR
        A[Правка<br/>спецификации] --> A2[Одна<br/>переделка]
    end
    subgraph r[После рендера: примерно на порядок дороже]
        direction LR
        B[Та же<br/>правка] --> B2[Все финальные<br/>кадры заново]
    end
    t ~~~ r
    classDef key stroke:#FF3600,stroke-width:2px
    class B2 key

Обновление, сентябрь 2026. Урок каскада потом вшили в процесс. Перед финальным рендером стоит проверка соответствия: сетап сверяется с референсами по чек-листу, критичные зоны смотрятся в полном разрешении, и расхождение, найденное до рендера, чинится дёшево. Найденное после рендера стоит пересчёта всей пачки.

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

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

flowchart LR
    A[Агент: строка<br/>в момент появления] --> O[Оператор: ревью<br/>и согласование]
    O --> C[Счёт<br/>клиенту]

Большая часть того, что делает агент в продакшне, — это работа того же типа, что делает продюсер, в большем объёме. Реестр устроен иначе: непрерывная классификация тысяч сообщений не помещается в одну голову ни при каком навыке. Здесь агент не ускоряет работу, а делает возможной ту, что без него не делается вовсе.

Где ломается

  • Дрейф разделителя. Правило начинается как «изменение утверждённой стадии платно», под давлением смягчается до «только крупное изменение», и объективного разделителя больше нет. Разделитель должен оставаться острым, даже если оператор на ревью иногда отказывается от конкретной строки.
  • Нет стадий. Без событий утверждения классифицировать не против чего. Стадии нужно фиксировать до старта; без них не работает ни реестр, ни любой другой учёт изменений.
  • Реестр без контекста. Строка с категорией, но без ссылки на сообщение, при расхождении стоит не больше памяти продюсера.
  • Классификация без чтения чата. Агент смотрит на одно сообщение, а не на тред, и путает уточнение с новым требованием. См. контекст перед действием.

Итог

  • Стадии утверждения плюс одно правило-разделитель плюс строка с контекстом — вся конструкция.
  • Правка после рендера обходится многократно дороже правки до него; реестр показывает каскад по строкам.
  • 22 строки за месяц; ни одна не восстановилась бы из памяти, и обе стороны видели одну и ту же запись.
  • Агент идентифицирует, оператор договаривается, клиент видит цену добавления в момент запроса.

© Александр Никулин. Цитирование — с указанием автора и ссылкой · Версия для LLM