Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Про новый Content Ops и почему через полгода хвастаться «фабрикой контента» станет стыдно
«Мы автоматизировали продакшн», «агенты сами пишут релизы», «редактор нажимает одну кнопку». Пол-ленты про это.
Прогноз от меня простой. Через полгода это будет гигиена, а не достижение. Генерить объём научатся все, а значит, объём окончательно перестанет что-либо стоить. Дальше все повернутся к content ops.
Термин content ops придумали не вчера. В оборот он вошёл в конце 2010-х и собран по прямой аналогии с DevOps. По сути это маркетинговая дисциплина. Люди, процессы, технологии, чтобы эффективно производить контент. Воркфлоу, CMS, согласования, календарь. Старый content ops оптимизировал производство. Но это больше не узкое место.
И тут стоит сказать, что content ops назван по аналогии с devops, сами механики devops — версии, CI, откаты, мониторинг — к контенту по-настоящему не прикладывались. Не к чему было. Текст — не код.
Теперь — код. Скилл агента это буквально код: он дрейфует, деградирует, ломается на регрессиях. Вчера писал в голосе, сегодня сползает в канцелярит. Факты галлюцинируют, модель уверенно ставит цифру, которой нет. Нужен слой проверки, как CI, только для фактуры. И появляется полноценный content ops с позицией инженера content ops — опыт редактора плюс владение пайплайном.
Почему будущее там, а не в промпт-инженерах
Промпт-инженер — это про «как попросить модель». Навык. Он встроится в редактора за квартал и перестанет быть профессией. Сейчас учить людей правильным промптам уже кажется устаревшим навыком.
Content ops в новом смысле — это про «как держать систему из моделей, людей и стандартов, чтобы она не разваливалась и ей можно было доверять».
Слово есть. Но курсов под эту новую задачу нет. Консенсуса, что это вообще другая работа, тоже пока нет.
Ровно поэтому туда и стоит смотреть. Все смотрят на генерацию, а на эксплуатацию не смотрит почти никто. А выигрывает всегда эксплуатация.
Что изменится внутри самой редакции
Напишу так: мне кажется, что уходить в контентпосера не должны все редакторы и контент-менеджеры. Это отдельная позиция, в которую будет расти кто-то внутри или на которую будут брать человека. Если редактор перестанет править тексты и начнёт править систему, то он потеряет в эффективности. Поправить абзац руками быстро, но завтра агент сделает так же снова. Поправить скилл — инвестиция: чинишь причину, а не симптом.
То есть в моём понимание над редакцией должен появиться человек, который наблюдает за процессами и чинит ошибки. Более того, у контента появится техдолг. Зоопарк агентов и скиллов от различных команд и коллег копится, они начинают противоречить друг другу. Никто уже не помнит, зачем это правило и можно ли его снять. Редакции впервые получат то, что раньше было головной болью только разработчиков. И эту проблему нужно закрывать уже сейчас, должна быть единая функция и точка входа и выхода.
Вот такой прогноз. Что скажете, коллеги?
#ai #contentops
«Мы автоматизировали продакшн», «агенты сами пишут релизы», «редактор нажимает одну кнопку». Пол-ленты про это.
Прогноз от меня простой. Через полгода это будет гигиена, а не достижение. Генерить объём научатся все, а значит, объём окончательно перестанет что-либо стоить. Дальше все повернутся к content ops.
Термин content ops придумали не вчера. В оборот он вошёл в конце 2010-х и собран по прямой аналогии с DevOps. По сути это маркетинговая дисциплина. Люди, процессы, технологии, чтобы эффективно производить контент. Воркфлоу, CMS, согласования, календарь. Старый content ops оптимизировал производство. Но это больше не узкое место.
И тут стоит сказать, что content ops назван по аналогии с devops, сами механики devops — версии, CI, откаты, мониторинг — к контенту по-настоящему не прикладывались. Не к чему было. Текст — не код.
Теперь — код. Скилл агента это буквально код: он дрейфует, деградирует, ломается на регрессиях. Вчера писал в голосе, сегодня сползает в канцелярит. Факты галлюцинируют, модель уверенно ставит цифру, которой нет. Нужен слой проверки, как CI, только для фактуры. И появляется полноценный content ops с позицией инженера content ops — опыт редактора плюс владение пайплайном.
Почему будущее там, а не в промпт-инженерах
Промпт-инженер — это про «как попросить модель». Навык. Он встроится в редактора за квартал и перестанет быть профессией. Сейчас учить людей правильным промптам уже кажется устаревшим навыком.
Content ops в новом смысле — это про «как держать систему из моделей, людей и стандартов, чтобы она не разваливалась и ей можно было доверять».
Слово есть. Но курсов под эту новую задачу нет. Консенсуса, что это вообще другая работа, тоже пока нет.
Ровно поэтому туда и стоит смотреть. Все смотрят на генерацию, а на эксплуатацию не смотрит почти никто. А выигрывает всегда эксплуатация.
Что изменится внутри самой редакции
Напишу так: мне кажется, что уходить в контентпосера не должны все редакторы и контент-менеджеры. Это отдельная позиция, в которую будет расти кто-то внутри или на которую будут брать человека. Если редактор перестанет править тексты и начнёт править систему, то он потеряет в эффективности. Поправить абзац руками быстро, но завтра агент сделает так же снова. Поправить скилл — инвестиция: чинишь причину, а не симптом.
То есть в моём понимание над редакцией должен появиться человек, который наблюдает за процессами и чинит ошибки. Более того, у контента появится техдолг. Зоопарк агентов и скиллов от различных команд и коллег копится, они начинают противоречить друг другу. Никто уже не помнит, зачем это правило и можно ли его снять. Редакции впервые получат то, что раньше было головной болью только разработчиков. И эту проблему нужно закрывать уже сейчас, должна быть единая функция и точка входа и выхода.
Вот такой прогноз. Что скажете, коллеги?
#ai #contentops
🔥3🤯2
Манифест контент-опса
Развивая тему ContenOps, я попробовал написать какой-то программный манифест. В DevOps философия базируется на принципах Agile, модели CALMS и концепции непрерывной поставки ценности. Если просто: писать код важно, нужно ещё важнее доставлять надёжно и отвечать за доставленное. Для контента развилка та же, только доставляем мы не код, а то, чему должны верить читатель и модель.
Что мы ценим. По мотивам Agile-манифеста разработки программного обеспечения
🔹 Проверяемость важнее объёма.
🔹 Правка системы важнее правки текста.
🔹 Голос как контракт важнее голоса как чутья.
🔹 Ответственность за выпущенное важнее скорости выпуска.
🔹 Формализованное знание важнее знания в голове у редактора.
🔹 Доверие читателя и модели важнее охвата.
При всей ценности того, что справа, левое мы ценим больше.
Три пути
Джин Ким свёл DevOps к трём принципам: поток, обратная связь, обучение. Они переносятся на редакцию не по аналогии, а по устройству: как только скилл становится кодом, у контента появляются те же поток, дефекты и техдолг, а значит и те же правила.
Поток. В инженерии дефект, ушедший вниз по потоку, дорожает на каждом следующем шаге и портит всё, что строится поверх него. С контентом то же самое, только дефект здесь — непроверенный факт. Пропущенный на своём этапе, он не остаётся ошибкой в одном черновике: его вплетают в аргумент, публикуют под брендом, на него ссылаются — и с каждой ссылкой он всё больше похож на правду. Поймать его при генерации почти ничего не стоит, а отозвать после того, как его опубликовали, уже невозможно. Отсюда правило: факт проверяют на том шаге, где он появился, и без проверки не пропускают дальше, как бы ни горели сроки. И оптимизируют весь поток целиком, а не отдельный скилл, потому что выигрыш на одном участке оборачивается узким местом на следующем.
Обратная связь. В DevOps смысл петли в том, что исправление возвращается к источнику ошибки, а не гасит её последствия. Иначе источник спокойно повторит тот же дефект завтра. У агента источник ошибки — это скилл, поэтому и правку возвращают в скилл, а не в текст. Поправить текст — разовый патч, работа на выброс: сам агент об этой правке не узнает и завтра ошибётся снова. Поправить скилл — значит замкнуть петлю, чтобы ошибка не вернулась. По той же причине проверку встраивают прямо в поток, как CI, а не оставляют на финальную вычитку: чем ближе к источнику пойман дефект, тем дешевле он обходится.
Обучение. В основе третьего пути простое наблюдение: если наказывать людей за сбои системы, они начинают эти сбои прятать, и система ломается незаметно. На редакцию это переносится дословно. Сбой агента — это дефект правила, а не вина редактора, поэтому его и разбирают без поиска виноватых: стоит начать наказывать и о сбоях просто перестанут докладывать. Дальше та же логика тянет за собой остальное. Скиллы копятся и конфликтуют друг с другом, как код, а значит, у контента появляется собственный техдолг и время на его разбор — это работа, а не отвлечение от неё. Устойчивость проверяют раньше читателя: агента нарочно гоняют на граничных случаях, потому что сломать систему самому всегда дешевле, чем ждать, пока это сделает аудитория.
И небольшой вывод
Ничего из вышеописанного не про то, как быстрее генерировать. Это делают все, поэтому объём и обесценивается. Манифест про то, как отвечать за сгенерированное: за цифру, которую не проверили, за голос, который поплыл, за материал, вышедший под твоим брендом.
Кто освоит контентопс в новом смысле, тот и будет редакцией через год. Остальные останутся фабрикой. А фабрика делает то, что дешевеет.
#ai #контентменеджерское #contentops
Развивая тему ContenOps, я попробовал написать какой-то программный манифест. В DevOps философия базируется на принципах Agile, модели CALMS и концепции непрерывной поставки ценности. Если просто: писать код важно, нужно ещё важнее доставлять надёжно и отвечать за доставленное. Для контента развилка та же, только доставляем мы не код, а то, чему должны верить читатель и модель.
Что мы ценим. По мотивам Agile-манифеста разработки программного обеспечения
При всей ценности того, что справа, левое мы ценим больше.
Три пути
Джин Ким свёл DevOps к трём принципам: поток, обратная связь, обучение. Они переносятся на редакцию не по аналогии, а по устройству: как только скилл становится кодом, у контента появляются те же поток, дефекты и техдолг, а значит и те же правила.
Поток. В инженерии дефект, ушедший вниз по потоку, дорожает на каждом следующем шаге и портит всё, что строится поверх него. С контентом то же самое, только дефект здесь — непроверенный факт. Пропущенный на своём этапе, он не остаётся ошибкой в одном черновике: его вплетают в аргумент, публикуют под брендом, на него ссылаются — и с каждой ссылкой он всё больше похож на правду. Поймать его при генерации почти ничего не стоит, а отозвать после того, как его опубликовали, уже невозможно. Отсюда правило: факт проверяют на том шаге, где он появился, и без проверки не пропускают дальше, как бы ни горели сроки. И оптимизируют весь поток целиком, а не отдельный скилл, потому что выигрыш на одном участке оборачивается узким местом на следующем.
Обратная связь. В DevOps смысл петли в том, что исправление возвращается к источнику ошибки, а не гасит её последствия. Иначе источник спокойно повторит тот же дефект завтра. У агента источник ошибки — это скилл, поэтому и правку возвращают в скилл, а не в текст. Поправить текст — разовый патч, работа на выброс: сам агент об этой правке не узнает и завтра ошибётся снова. Поправить скилл — значит замкнуть петлю, чтобы ошибка не вернулась. По той же причине проверку встраивают прямо в поток, как CI, а не оставляют на финальную вычитку: чем ближе к источнику пойман дефект, тем дешевле он обходится.
Обучение. В основе третьего пути простое наблюдение: если наказывать людей за сбои системы, они начинают эти сбои прятать, и система ломается незаметно. На редакцию это переносится дословно. Сбой агента — это дефект правила, а не вина редактора, поэтому его и разбирают без поиска виноватых: стоит начать наказывать и о сбоях просто перестанут докладывать. Дальше та же логика тянет за собой остальное. Скиллы копятся и конфликтуют друг с другом, как код, а значит, у контента появляется собственный техдолг и время на его разбор — это работа, а не отвлечение от неё. Устойчивость проверяют раньше читателя: агента нарочно гоняют на граничных случаях, потому что сломать систему самому всегда дешевле, чем ждать, пока это сделает аудитория.
И небольшой вывод
Ничего из вышеописанного не про то, как быстрее генерировать. Это делают все, поэтому объём и обесценивается. Манифест про то, как отвечать за сгенерированное: за цифру, которую не проверили, за голос, который поплыл, за материал, вышедший под твоим брендом.
Кто освоит контентопс в новом смысле, тот и будет редакцией через год. Остальные останутся фабрикой. А фабрика делает то, что дешевеет.
#ai #контентменеджерское #contentops
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯2
Раз у меня неделя разгона про content ops, то давайте посмотрим на него с другой стороны и поговорим про корпоративные базы знаний.
ИИ-энтузиасты последние пару лет носятся с идеей второго мозга. Личная вики, заметки, LLM поверх них и вот у тебя внешняя память, которая помнит всё и отвечает на любой вопрос.
Дальше следует вывод: раз работает для человека, то давайте так же для компании. Свалим в одно хранилище всю корпоративную документацию, натравим LLM, получим второй мозг организации. Единый разум, который знает про компанию всё.
Проблема в том, что это уже пробовали делать задолго до всякого ИИ. Оно называлось базой знаний, вики, порталом, единым источником правды — и оно умерло.
Что случилось с корпоративной базой знаний
Свежий Knowledge Work Benchmark 2026 от iManage, опрос более 3000 руководителей и технических ЛПР в 26 странах, даёт цифру: сотрудник тратит в среднем 37 минут в день на поиск информации. Это около 123 часов в год, три полные рабочие недели, потраченные на розыск документов, которые должны находиться за секунды. И главный вывод отчёта, проходящий через весь текст: информационная архитектура должна идти впереди искусственного интеллекта.
Отдельно про качество того, что находится. По данным KM-опросов, 54% организаций держат документацию более чем на пяти разных платформах, а треть менеджеров прямо говорит, что данные, с которыми они работают, устаревшие, неполные или неточные.
Потому что база гниёт по умолчанию. Механика распада знакома любому, кто работал в компании больше года:
— продукт меняется, а документация нет;
— политику обновляют в письме и на созвоне, но не в вики;
— новичок учится не по статьям в Confluence, а у коллеги или руководителя.
И «реальный процесс» медленно расходится с задокументированным. Автор статьи уволился два года назад, и теперь у неё нет владельца. Никто не помнит, актуальна ли она, и никто не решается удалить. Дальше самоподдерживающийся цикл. Люди перестают доверять базе. Раз не доверяют — не пользуются и не дают обратной связи. Раз нет обратной связи — база деградирует ещё быстрее.
Небольшая иллюстрация, поймал сам, пока писал этот текст. Собирая фактуру, я едва не поставил сюда популярную цифру: «сотрудники тратят 9,3 часа в неделю на поиск информации, источник McKinsey». Её бодро перепечатывают статьи 2026 года. Полез за первоисточником, а там исследование IDC 2012 года. Четырнадцать лет назад. Цифра давно оторвалась от источника и ходит по интернету как свежая, потому что её удобно цитировать и никто не проверяет. Вот это и есть протухшее знание в чистом виде: правдоподобное, авторитетно атрибутированное, всеми повторяемое и мёртвое. Ровно то, что ваша вики скормит модели, а модель вам.
И это не проблема технологии. Ни один переезд с Confluence на Notion, с Notion на что-то ещё этого не чинил. Это проблема эксплуатации. У знания не было ни владельца, ни срока годности, ни процесса проверки.
А теперь мы собираемся натравить на это LLM.
Почему LLM не чинит эту проблему, а усиливает её
Ваша база знаний — это ровно связный, хорошо структурированный, семантически однородный корпус. Сто статей про «процесс релиза», из которых три актуальные, а девяносто семь — археология разной степени древности, написанные одним и тем же корпоративным языком про одни и те же сущности. Для модели это худший из возможных входов: не шум, который легко отбросить, а плотный слой правдоподобных дистракторов, неотличимых от правды по форме.
Личный второй мозг это переживает, потому что он маленький и у него один куратор — ты сам. Ты помнишь, что заметка от 2023-го протухла. Корпоративный второй мозг с куратором-LLM этого не помнит. Он просто уверенно процитирует вам регламент, отменённый полтора года назад, со ссылкой, в нужном тоне, без единого признака сомнения.
Раньше протухшая статья лежала в вики мёртвым грузом, и её просто никто не читал. Теперь она попадает в контекст и получает голос. ИИ превратил плохой Confluence в измеримый провал. Ассистент, который врёт про регламент, — это конкретный, наблюдаемый инцидент.
Кто за это отвечает
Отвечать за это должен человек. Не «новая платформа, на которую переедем и заживём», не новая LMM, не «мы все вместе договорились обновлять документацию» — это ровно то, что не сработало ни разу за двадцать лет.
Это работа около content ops, только повёрнутая внутрь. Наружу content ops отвечает за то, что компания публикует. Внутрь — за то, чем компания думает. Владелец жизненного цикла знания. Тот, кто чистит корпус, следит за сроками годности, ловит дистракторы и удаляет мёртвое. Тот, кто понимает, что чистый контекст — это не гигиена ради гигиены, а прямое условие того, чтобы модель не врала.
Личный второй мозг работает, потому что у него один хозяин. У корпоративного хозяина нет. Пока не появится.
#ai #контентменеджерское #contentops
ИИ-энтузиасты последние пару лет носятся с идеей второго мозга. Личная вики, заметки, LLM поверх них и вот у тебя внешняя память, которая помнит всё и отвечает на любой вопрос.
Дальше следует вывод: раз работает для человека, то давайте так же для компании. Свалим в одно хранилище всю корпоративную документацию, натравим LLM, получим второй мозг организации. Единый разум, который знает про компанию всё.
Проблема в том, что это уже пробовали делать задолго до всякого ИИ. Оно называлось базой знаний, вики, порталом, единым источником правды — и оно умерло.
Что случилось с корпоративной базой знаний
Свежий Knowledge Work Benchmark 2026 от iManage, опрос более 3000 руководителей и технических ЛПР в 26 странах, даёт цифру: сотрудник тратит в среднем 37 минут в день на поиск информации. Это около 123 часов в год, три полные рабочие недели, потраченные на розыск документов, которые должны находиться за секунды. И главный вывод отчёта, проходящий через весь текст: информационная архитектура должна идти впереди искусственного интеллекта.
Отдельно про качество того, что находится. По данным KM-опросов, 54% организаций держат документацию более чем на пяти разных платформах, а треть менеджеров прямо говорит, что данные, с которыми они работают, устаревшие, неполные или неточные.
Потому что база гниёт по умолчанию. Механика распада знакома любому, кто работал в компании больше года:
— продукт меняется, а документация нет;
— политику обновляют в письме и на созвоне, но не в вики;
— новичок учится не по статьям в Confluence, а у коллеги или руководителя.
И «реальный процесс» медленно расходится с задокументированным. Автор статьи уволился два года назад, и теперь у неё нет владельца. Никто не помнит, актуальна ли она, и никто не решается удалить. Дальше самоподдерживающийся цикл. Люди перестают доверять базе. Раз не доверяют — не пользуются и не дают обратной связи. Раз нет обратной связи — база деградирует ещё быстрее.
Небольшая иллюстрация, поймал сам, пока писал этот текст. Собирая фактуру, я едва не поставил сюда популярную цифру: «сотрудники тратят 9,3 часа в неделю на поиск информации, источник McKinsey». Её бодро перепечатывают статьи 2026 года. Полез за первоисточником, а там исследование IDC 2012 года. Четырнадцать лет назад. Цифра давно оторвалась от источника и ходит по интернету как свежая, потому что её удобно цитировать и никто не проверяет. Вот это и есть протухшее знание в чистом виде: правдоподобное, авторитетно атрибутированное, всеми повторяемое и мёртвое. Ровно то, что ваша вики скормит модели, а модель вам.
И это не проблема технологии. Ни один переезд с Confluence на Notion, с Notion на что-то ещё этого не чинил. Это проблема эксплуатации. У знания не было ни владельца, ни срока годности, ни процесса проверки.
А теперь мы собираемся натравить на это LLM.
Почему LLM не чинит эту проблему, а усиливает её
Ваша база знаний — это ровно связный, хорошо структурированный, семантически однородный корпус. Сто статей про «процесс релиза», из которых три актуальные, а девяносто семь — археология разной степени древности, написанные одним и тем же корпоративным языком про одни и те же сущности. Для модели это худший из возможных входов: не шум, который легко отбросить, а плотный слой правдоподобных дистракторов, неотличимых от правды по форме.
Личный второй мозг это переживает, потому что он маленький и у него один куратор — ты сам. Ты помнишь, что заметка от 2023-го протухла. Корпоративный второй мозг с куратором-LLM этого не помнит. Он просто уверенно процитирует вам регламент, отменённый полтора года назад, со ссылкой, в нужном тоне, без единого признака сомнения.
Раньше протухшая статья лежала в вики мёртвым грузом, и её просто никто не читал. Теперь она попадает в контекст и получает голос. ИИ превратил плохой Confluence в измеримый провал. Ассистент, который врёт про регламент, — это конкретный, наблюдаемый инцидент.
Кто за это отвечает
Отвечать за это должен человек. Не «новая платформа, на которую переедем и заживём», не новая LMM, не «мы все вместе договорились обновлять документацию» — это ровно то, что не сработало ни разу за двадцать лет.
Это работа около content ops, только повёрнутая внутрь. Наружу content ops отвечает за то, что компания публикует. Внутрь — за то, чем компания думает. Владелец жизненного цикла знания. Тот, кто чистит корпус, следит за сроками годности, ловит дистракторы и удаляет мёртвое. Тот, кто понимает, что чистый контекст — это не гигиена ради гигиены, а прямое условие того, чтобы модель не врала.
Личный второй мозг работает, потому что у него один хозяин. У корпоративного хозяина нет. Пока не появится.
#ai #контентменеджерское #contentops
🔥6❤1
Ваши скиллы возможно написаны под модель, которой уже нет
Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.
1. Половина ваших правил — заплатки на провалы прошлых версий. «Не начинай с общих фраз», «не используй конструкцию X» — вы это добавляли, потому что модель так делала. Перестала делать, и правило работает вхолостую, а иногда против вас: запрет отнимает у сильной модели право решать по ситуации. Что сделать: пройти по скиллам и рядом с каждым правилом поставить дату и ошибку, из-за которой оно появилось. Где ошибку не вспомнить или ей больше полугода — кандидат на удаление.
2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.
3. Конфликтуют не правила, а источники правил. Редстандарт, скилл канала, CLAUDE.md, бриф — четыре места, где написано про тон. Модель разгребает противоречие вместо работы. Решение не в сокращении, а в иерархии: тон и позиция живут только в скилле канала, фактура и грабли — только в CLAUDE.md, задача выпуска — только в брифе. Правило встретилось дважды — одно вхождение удаляется, а не уточняется.
4. Эталонные тексты в скиллах, скорее всего, вредят. Приложил три идеальных поста — получил четвёртый такой же по каркасу. Меняем образцы на структуру: рубрикатор, обязательные элементы, признаки плохого лида. Образец оставляем там, где нужен формат — вёрстка, разметка, шаблон ответа.
5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.
Что переносится на другие модели
Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.
Переносится наполовину принцип «меньше правил — лучше». Это функция силы модели, а не тренд индустрии: чем модель слабее, тем нужнее ей явные правила и примеры. Если вы гоняете тяжёлое на топовой, а рутину на дешёвой, один облегчённый скилл на всех не сработает. Либо два профиля инструкций, либо пишете под самую слабую в связке и теряете на сильной.
Не переносятся архитектурные приёмы. Прогрессивное раскрытие, отложенная загрузка инструментов, автопамять — это свойства обвязки, а не модели. В чужом фреймворке эквивалента может не быть, и тогда «вынесите редкое в отдельный скилл» превращается в «вынесите в файл, который никто не подгрузит».
И главное
Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎
#ai_agents #contentops
Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.
1. Половина ваших правил — заплатки на провалы прошлых версий. «Не начинай с общих фраз», «не используй конструкцию X» — вы это добавляли, потому что модель так делала. Перестала делать, и правило работает вхолостую, а иногда против вас: запрет отнимает у сильной модели право решать по ситуации. Что сделать: пройти по скиллам и рядом с каждым правилом поставить дату и ошибку, из-за которой оно появилось. Где ошибку не вспомнить или ей больше полугода — кандидат на удаление.
2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.
3. Конфликтуют не правила, а источники правил. Редстандарт, скилл канала, CLAUDE.md, бриф — четыре места, где написано про тон. Модель разгребает противоречие вместо работы. Решение не в сокращении, а в иерархии: тон и позиция живут только в скилле канала, фактура и грабли — только в CLAUDE.md, задача выпуска — только в брифе. Правило встретилось дважды — одно вхождение удаляется, а не уточняется.
4. Эталонные тексты в скиллах, скорее всего, вредят. Приложил три идеальных поста — получил четвёртый такой же по каркасу. Меняем образцы на структуру: рубрикатор, обязательные элементы, признаки плохого лида. Образец оставляем там, где нужен формат — вёрстка, разметка, шаблон ответа.
5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.
Что переносится на другие модели
Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.
Переносится наполовину принцип «меньше правил — лучше». Это функция силы модели, а не тренд индустрии: чем модель слабее, тем нужнее ей явные правила и примеры. Если вы гоняете тяжёлое на топовой, а рутину на дешёвой, один облегчённый скилл на всех не сработает. Либо два профиля инструкций, либо пишете под самую слабую в связке и теряете на сильной.
Не переносятся архитектурные приёмы. Прогрессивное раскрытие, отложенная загрузка инструментов, автопамять — это свойства обвязки, а не модели. В чужом фреймворке эквивалента может не быть, и тогда «вынесите редкое в отдельный скилл» превращается в «вынесите в файл, который никто не подгрузит».
И главное
Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎
#ai_agents #contentops
👍1🔥1🤯1
Контент Claude теперь помечен. И это не новость про списывающих студентов
11 августа Anthropic подтвердила, что маркирует контент, который создают с помощью их моделей. Не видимой плашкой, а маркерами внутри . На следующий день TechCrunch вышел с материалом о том, как на это реагируют в реддите: заголовок про пользователей, которые злятся, потому что их поймают на работе и на учёбе. Но интереснее реакций механика.
Что сделали:
— причина - кодекс прозрачности в рамках EU AI Act, вступил в силу 2 августа. Требует помечать сгенерированный или отредактированный ИИ контент так, чтобы метку читали другие системы. Подписанты не только Anthropic.
— все модели, вышедшие после 2 августа, метят и текст, и файлы. Для файлов — открытый стандарт C2PA.
— метка ставится на уровне модели. То есть она есть везде, откуда бы текст ни вышел: API, чат, Claude Code, Cowork, Tag.
— метка едет вместе с текстом при копировании и, по формулировке справки, может пережить часть правок. Сколько правок её снимают не уточняется.
— на старые модели поддержку обещают дораскатить.
Претензии делятся на две неравные части. Одна честная: модели учили на чужих текстах, никого не спрашивая, а теперь метят своё. Ирония тут есть. Вторая сводится к «меня поймают», но подаётся как защита невинных: студент, попросивший переставить абзац, журналист, попросивший конспект стенограммы. Только конспект с меткой становится проблемой ровно в одном случае: если его вставляют в статью как свой текст. Тогда проблема не в метке. Показательно, что в тех же тредах большинство комментаторов встало на сторону маркировки.
Что меняется у редакции
Предупреждать, что вы генерируете с помощью ИИ перестало быть вашим решением. Раньше «говорить ли заказчику, что черновик собрал агент» было вопросом договорённостей и совести. Теперь это свойство файла. Вопрос только в том, узнает заказчик об этом от вас или без вас.
Стилевые детекторы съезжают на второй план. Я рассказывал про свой слой проверок на GitHub Actions — там среди прочего скрипт считает плотность тире и ищет следы машинного текста. Это эвристика, она угадывает по стилю. Метка не угадывает, она в источнике. Значит, такие детекторы перестают быть ответом на вопрос «писал ли это ИИ» и остаются тем, чем и должны быть, — проверкой качества, а не происхождения.
Асимметрия, которую легко упустить. Наличие метки — сильное свидетельство. Отсутствие не значит ничего: метят не все и не везде, старые модели дораскатывают, локальные модели никто не обязывает. Любая проверка сотрудников или студентов «на ИИ» по этому принципу будет ловить одних и пропускать других. Строить такие процедуры начнут уже осенью, а границы у метки пока нет.
И к тому, о чём уже писал
В манифесте контент-опса у меня стояла строчка: ответственность за выпущенное важнее скорости выпуска. Тогда это была позиция. Теперь у неё появился технический носитель — происхождение едет вместе с текстом и доезжает до читателя.
А ещё я обещал развернуть content sec ops. Вот его первый слой, и он не про доступы агента к базе знаний, а про провенанс: знаем ли мы, что именно в материале сгенерировано, зафиксировано ли это где-то помимо головы редактора, и что мы отвечаем, когда спросят. Редакция с логом пайплайна ответит за минуту. Таких пока мало.
Что имеет смысл сделать на этой неделе: записать в редполитику, где вы используете генерацию и что сообщаете об этом клиенту. Одна страница, до того как вопрос прилетит снаружи.
#ai #contentops
11 августа Anthropic подтвердила, что маркирует контент, который создают с помощью их моделей. Не видимой плашкой, а маркерами внутри . На следующий день TechCrunch вышел с материалом о том, как на это реагируют в реддите: заголовок про пользователей, которые злятся, потому что их поймают на работе и на учёбе. Но интереснее реакций механика.
Что сделали:
— причина - кодекс прозрачности в рамках EU AI Act, вступил в силу 2 августа. Требует помечать сгенерированный или отредактированный ИИ контент так, чтобы метку читали другие системы. Подписанты не только Anthropic.
— все модели, вышедшие после 2 августа, метят и текст, и файлы. Для файлов — открытый стандарт C2PA.
— метка ставится на уровне модели. То есть она есть везде, откуда бы текст ни вышел: API, чат, Claude Code, Cowork, Tag.
— метка едет вместе с текстом при копировании и, по формулировке справки, может пережить часть правок. Сколько правок её снимают не уточняется.
— на старые модели поддержку обещают дораскатить.
Претензии делятся на две неравные части. Одна честная: модели учили на чужих текстах, никого не спрашивая, а теперь метят своё. Ирония тут есть. Вторая сводится к «меня поймают», но подаётся как защита невинных: студент, попросивший переставить абзац, журналист, попросивший конспект стенограммы. Только конспект с меткой становится проблемой ровно в одном случае: если его вставляют в статью как свой текст. Тогда проблема не в метке. Показательно, что в тех же тредах большинство комментаторов встало на сторону маркировки.
Что меняется у редакции
Предупреждать, что вы генерируете с помощью ИИ перестало быть вашим решением. Раньше «говорить ли заказчику, что черновик собрал агент» было вопросом договорённостей и совести. Теперь это свойство файла. Вопрос только в том, узнает заказчик об этом от вас или без вас.
Стилевые детекторы съезжают на второй план. Я рассказывал про свой слой проверок на GitHub Actions — там среди прочего скрипт считает плотность тире и ищет следы машинного текста. Это эвристика, она угадывает по стилю. Метка не угадывает, она в источнике. Значит, такие детекторы перестают быть ответом на вопрос «писал ли это ИИ» и остаются тем, чем и должны быть, — проверкой качества, а не происхождения.
Асимметрия, которую легко упустить. Наличие метки — сильное свидетельство. Отсутствие не значит ничего: метят не все и не везде, старые модели дораскатывают, локальные модели никто не обязывает. Любая проверка сотрудников или студентов «на ИИ» по этому принципу будет ловить одних и пропускать других. Строить такие процедуры начнут уже осенью, а границы у метки пока нет.
И к тому, о чём уже писал
В манифесте контент-опса у меня стояла строчка: ответственность за выпущенное важнее скорости выпуска. Тогда это была позиция. Теперь у неё появился технический носитель — происхождение едет вместе с текстом и доезжает до читателя.
А ещё я обещал развернуть content sec ops. Вот его первый слой, и он не про доступы агента к базе знаний, а про провенанс: знаем ли мы, что именно в материале сгенерировано, зафиксировано ли это где-то помимо головы редактора, и что мы отвечаем, когда спросят. Редакция с логом пайплайна ответит за минуту. Таких пока мало.
Что имеет смысл сделать на этой неделе: записать в редполитику, где вы используете генерацию и что сообщаете об этом клиенту. Одна страница, до того как вопрос прилетит снаружи.
#ai #contentops
🔥2🤔1
Проверка, которую агент не может пропустить
Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто.
Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке.
Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки.
Что у меня стоит на хуках:
→ Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще.
→ Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов.
→ Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же.
И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать.
Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс.
#ai_agents #contentops
Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто.
Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке.
Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки.
Что у меня стоит на хуках:
→ Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще.
→ Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов.
→ Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же.
И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать.
Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс.
#ai_agents #contentops
1❤2👍2🔥1🤔1