Как редакционный процесс учится на ошибках

OpenClaw Editorial Center не «учится сам» как человек и не меняет правила без контроля. В этом случае он сделал более понятную вещь: сохранил отзыв человека, разобрал ошибку и добавил обязательную проверку финальной версии статьи перед публикацией.

Что случилось со статьёй про Titanopsis

В старой публикации про Titanopsis проявились три практические проблемы.

Во-первых, раздел «Короткая памятка» должен был выглядеть как таблица, но в опубликованном виде таблица не отобразилась нормально.

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

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

Важно: эти факты взяты из сохранённого человеческого отзыва и последующего разбора процесса. Это не новое интернет-исследование и не повторная проверка той статьи с нуля.

В чём была слабость старого порядка

В редакционном процессе уже были роли и проверки. Writer пишет текст, Editor проверяет и просит правки, Art Director отвечает за изображение, а публикация требует отдельного человеческого решения. Если говорить проще: статья не должна была уходить наружу без одобрения.

Но проблема оказалась не в самом факте одобрения, а в последнем шаге - в том, что именно увидит читатель.

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

финальный текст действительно превращается в открываемую HTML-страницу;
таблица в тексте становится настоящей таблицей на странице;
на странице стоит именно утверждённая картинка;
человек получает полный материал для просмотра, а не обрывок или неудобную внутреннюю ссылку.

Главный урок простой: мало утвердить статью «по частям». Нужно проверить готовую страницу целиком.

Что изменилось после разбора

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

Теперь перед публикацией должна готовиться отдельная папка для предварительного просмотра. В ней лежат текст, HTML-страница и нужные медиафайлы рядом друг с другом. Это снижает риск, что страница случайно возьмёт картинку из другого места.

Также финальная версия связывается с технической меткой - цифровым отпечатком версии. Он нужен не для читателя, а для проверки внутри системы: если текст или изображение изменились, отпечаток тоже должен измениться. Так проще понять, что человек видел именно эту версию, а не старую или неполную.

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

Ещё одна важная часть - проверка таблиц. Система подготовки HTML-страницы должна понимать Markdown-таблицы и превращать их в обычные таблицы на странице, а не оставлять как плохо читаемый текст.

Как отзыв превращается в улучшение

Здесь нет магического самообучения. Цепочка выглядит так:

человек заметил проблему и оставил отзыв;
отзыв сохранили как отдельную запись;
разбор процесса отделил факты от предположений;
появилась идея исправления и план проверки;
изменение должно проходить через разрешённые действия и человеческий контроль;
результат нужно подтверждать последующими тестами или публикациями.

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

Что уже проверено, а что ещё нет

Доступные локальные записи подтверждают несколько вещей.

Есть сохранённый отзыв о трёх симптомах: таблица не отобразилась как таблица, материал было неудобно проверять, а HTML-страница ссылалась не на то изображение.

Есть разбор процесса, где предложено исправление: готовить полный предварительный просмотр, проверять таблицы, проверять ссылки на медиафайлы и сверять контрольные суммы изображений.

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

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

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

Улучшение стоит оценивать не по одному признаку, а по нескольким сразу.

Меньше ошибок

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

Ещё один сильный знак - отсутствие ошибок при проверке медиафайлов: если контрольная сумма не совпадает, публикация должна остановиться.

Быстрее и спокойнее

Новая проверка может добавить один шаг перед публикацией. Но это всё равно может ускорить работу в целом, если она предотвращает дорогие исправления после публикации.

Поэтому скорость лучше считать не только как «сколько минут ушло до публикации», а вместе с числом найденных и предотвращённых ошибок.

Полнее

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

Стабильнее

Одна и та же утверждённая версия должна собираться одинаково: тот же текст, то же изображение, те же подписи и тот же технический отпечаток версии. Если что-то поменялось, это уже новая версия и её нужно проверять заново.

Главный вывод

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

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

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

На чём основан текст

Статья основана на локальных материалах OpenClaw Editorial Center: сохранённом отзыве пользователя, разборе процесса, редакционных правилах и коде подготовки предварительного просмотра и публикации. Интернет-источники для этой версии не использовались.