Инженер Контекста
Ir al canal en Telegram
Евгений Левашов, контент-лид в VK Tech, отвечаю за VK Cloud, VK Data Platform, Tarantool и другой технохардкор. Редактирую ИТ-компании, консультирую, учу. Здесь всё про Ai в контенте, дату, облака и остальной ИТ. Писать — @levashove CC BY-NC-SA 4.0
Mostrar más940
Suscriptores
Sin datos24 horas
+47 días
+4130 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
septiembre '26
septiembre '26
+13
en 0 canales
agosto '26
+42
en 0 canales
Get PRO
julio '26
+23
en 1 canales
Get PRO
junio '26
+5
en 0 canales
Get PRO
mayo '26
+10
en 1 canales
Get PRO
abril '26
+12
en 1 canales
Get PRO
marzo '26
+29
en 2 canales
Get PRO
febrero '26
+6
en 0 canales
Get PRO
enero '26
+7
en 0 canales
Get PRO
diciembre '25
+22
en 1 canales
Get PRO
noviembre '25
+10
en 3 canales
Get PRO
octubre '25
+4
en 0 canales
Get PRO
septiembre '25
+4
en 0 canales
Get PRO
agosto '25
+6
en 0 canales
Get PRO
julio '25
+15
en 3 canales
Get PRO
junio '25
+11
en 3 canales
Get PRO
mayo '25
+5
en 1 canales
Get PRO
abril '25
+10
en 0 canales
Get PRO
marzo '25
+11
en 0 canales
Get PRO
febrero '25
+16
en 0 canales
Get PRO
enero '25
+12
en 0 canales
Get PRO
diciembre '24
+23
en 0 canales
Get PRO
noviembre '24
+15
en 0 canales
Get PRO
octubre '24
+17
en 0 canales
Get PRO
septiembre '24
+25
en 0 canales
Get PRO
agosto '24
+16
en 0 canales
Get PRO
julio '24
+8
en 3 canales
Get PRO
junio '24
+12
en 0 canales
Get PRO
mayo '24
+10
en 1 canales
Get PRO
abril '24
+22
en 0 canales
Get PRO
marzo '24
+33
en 0 canales
Get PRO
febrero '24
+67
en 1 canales
Get PRO
enero '24
+22
en 0 canales
Get PRO
diciembre '23
+33
en 0 canales
Get PRO
noviembre '23
+32
en 2 canales
Get PRO
octubre '23
+19
en 1 canales
Get PRO
septiembre '23
+24
en 0 canales
Get PRO
agosto '23
+23
en 0 canales
Get PRO
julio '23
+23
en 0 canales
Get PRO
junio '23
+19
en 0 canales
Get PRO
mayo '23
+21
en 0 canales
Get PRO
abril '23
+11
en 0 canales
Get PRO
marzo '23
+22
en 0 canales
Get PRO
febrero '23
+16
en 0 canales
Get PRO
enero '23
+36
en 0 canales
Get PRO
diciembre '22
+33
en 0 canales
Get PRO
noviembre '22
+34
en 0 canales
Get PRO
octubre '22
+39
en 0 canales
Get PRO
septiembre '22
+30
en 0 canales
Get PRO
agosto '22
+37
en 0 canales
Get PRO
julio '22
+39
en 0 canales
Get PRO
junio '22
+44
en 0 canales
Get PRO
mayo '22
+58
en 0 canales
Get PRO
abril '22
+81
en 0 canales
Get PRO
marzo '22
+188
en 0 canales
Get PRO
febrero '22
+20
en 0 canales
Get PRO
enero '22
+37
en 0 canales
Get PRO
diciembre '21
+19
en 0 canales
Get PRO
noviembre '21
+13
en 0 canales
Get PRO
octubre '21
+18
en 0 canales
Get PRO
septiembre '21
+40
en 0 canales
Get PRO
agosto '21
+20
en 0 canales
Get PRO
julio '21
+32
en 0 canales
Get PRO
junio '21
+43
en 0 canales
Get PRO
mayo '21
+69
en 0 canales
Get PRO
abril '21
+31
en 0 canales
Get PRO
marzo '21
+34
en 0 canales
Get PRO
febrero '21
+27
en 0 canales
Get PRO
enero '21
+39
en 0 canales
Get PRO
diciembre '20
+1 314
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 17 septiembre | 0 | |||
| 16 septiembre | 0 | |||
| 15 septiembre | +1 | |||
| 14 septiembre | 0 | |||
| 13 septiembre | +1 | |||
| 12 septiembre | +1 | |||
| 11 septiembre | +3 | |||
| 10 septiembre | 0 | |||
| 09 septiembre | 0 | |||
| 08 septiembre | +1 | |||
| 07 septiembre | 0 | |||
| 06 septiembre | 0 | |||
| 05 septiembre | +1 | |||
| 04 septiembre | 0 | |||
| 03 septiembre | +1 | |||
| 02 septiembre | +2 | |||
| 01 septiembre | +2 |
Publicaciones del Canal
| 2 | Обещал на 1000 подписчиков, но получилось раньше. Отдельный скилл clean-ai-patterns для проверки текстов на ИИ-паттерны. Показывает конкретные места и предлагает конкретные правки. | 87 |
| 3 | Обещанная история про косяки и разработку агентов, написанная во время перелёта в Москву
То, о чём я сейчас буду рассказывать, наверняка очень хорошо известно любому разработчику. И даже может вызвать у них улыбку. Итак, первую половину года я постоянно писал агенты для контента. Проектировал, вайбкодил, дописывал руками, что не нравилось, снова вайбкодил. Постоянно хотелось что-то улучшить, ускорить, оптимизировать, а затем опять усложнить. На каком то этапе там появился пайтон, экшены в гитхабе, синхронизация с другими репозиториями. И в какой-то момент для меня самого стало казаться, что этот процесс бесконечный.
Почему я вспомнил разработку в начале. Довольно часто знакомые программисты рассказывали, что долго не решались показать какой-то новый продукт, потому что опасались критики и провала. Процесс доработки становился бесконечным, а пока они стремились к идеалу, конкуренты выпускали сырую версию и уже начинали на ней зарабатывать.
Я свой mvp, конечно, раскатал на коллег практически в первые месяцы, но ситуация похожая. От той первой версии, которую забрали коллеги, до следующей анонсированной прошло три-четыре месяца. По своей внутренней нумерации я скакнул от v.1 до 4.55. Это приблизительно, в самолёте не посмотришь ченжлог, да и смысла в этом нет. То есть после первой раскатки я просто ушёл в лютые доработки и не смотрел по сторонам.
К чему это привело лично для меня:
Сложность и монструозность системы. Для всех кроме меня
Я то знаю, почему и зачем все эти проверки и экшены. И даже документацию написал, но кто её читает. Система, которую нельзя объяснить за десять минут, принадлежит одному человеку, даже если лежит в общем репозитории.
Я оптимизировал то, что видел сам
Да, видел много, но только по своим направлениям. Четыре месяца я честно доводил систему до идеала на выборке, которую сам же и составил. В ML для этого есть точное определение: переучился на тестовом наборе. Загуглите сами, что это.
Коллеги остались с v.1
Вот, кстати, это больнее всего. Пока я разгонялся, у них работала первая версия и они к ней приспособились. Придумали обходные пути, завели свои агенты и скиллы, привыкли к её странностям. Моя новая версия для них стала не улучшение, а ломкой того, что уже как-то жило. Чем дольше пауза, тем дороже обходится каждое обновление.
Точка остановки не наступила сама.
Я почему-то ждал, что в какой-то момент станет «готово» и я сам это почувствую. Не чувствуется. Список идей не заканчивается никогда, каждая следующая выглядит как последняя недостающая. Остановиться можно только решением, а не ощущением.
Следующие пару месяцев я не трогал ничего. Просто работал с системой как обычный пользователь, слушал коллег и смотрел по сторонам.
Первое, что выяснилось: половина того, что я написал, используется только мной. Не потому что плохо сделано, потому что не нужно. Я решал задачи, которые люди предпочитают решать другими способами. А то, что реально болит, казалось мне скучным, и я это четыре месяца обходил стороной. Теперь нагоняю.
Второе: пока не трогаешь, наконец видишь, что ломается. Когда каждую неделю выкатываешь новую версию, любой сбой списывается на свежие правки. Когда система стоит неподвижно, становится ясно, что она разваливается стабильно и в одном и том же месте.
Третье, и самое неприятное. За эти два месяца вышло столько всего нового, что какие-то мои проверки и промпты просто перестали иметь смысл. Я месяцами обходил ограничения, которое теперь снято на уровне инструмента. Смотреть по сторонам тоже работа, и я её не делал, потому что был занят.
Так что пауза оказалась не простоем. Она оказалась единственным способом узнать, что строить дальше. Разработка ослепляет: пока пишешь, видишь только следующий шаг.
Теперь стараюсь держать ритм: месяц строю, месяц живу с тем, что построил. Второй месяц даёт больше, чем первый, хотя это до сих пор кажется мне контринтуитивным.
#ai_agents | 77 |
| 4 |  Раньше любил написать что-то про новые айфоны, сравнить. Сейчас лень, потому что по ощущениям весь Apple выглядит как-то так. | 79 |
| 5 |  Вышел DeepSeek V4.1-Flash. Что там по применимости для контента?
Если лень всё читать, то вот сразу вывод: модели дешевеют быстрее, чем умнеют. Читать миллион токенов теперь почти ничего не стоит, а фактология осталась на прежнем уровне. Значит, на первый план выходит не выбор модели, а то, что мы кладём ей в контекст. Кто собирает хороший контекст, тот получает хороший текст. Кто надеется на модель, получит уверенную ошибку, просто дешевле. Контент-инженерия всё больше превращается в инженерию контекста.
Теперь подробности. В отчёте DeepSeek на 51 страницу нет ни одного теста на качество текста и ни слова о русском языке. Модель делали под агентов и код. Но часть выводов прямо переносится на контент-пайплайны.
1. Редстандарты в начало промпта
Главное в релизе — дешёвый контекст. Префилл стал почти вдвое дешевле, KV-кэш — вчетверо компактнее. Кэш префикса DeepSeek хранит не меньше 72 часов. В контент-пайплайне постоянная часть промпта большая: редстандарт, tone of voice, эталоны, описание продукта. Её выгодно ставить первой и не менять между запусками. Всё переменное: задание, исходник, дату — в конец. Если поставить дату в первую строку системного промпта, кэш будет сбрасываться каждый день.
2. Факты давать, а не спрашивать
Слабое место модели — фактология. На SimpleQA-Verified базовая модель набирает 42,3, а V4-Pro — 55,2. Длинные рассуждения не спасают: при переходе с уровня 25 на 100 результат меняется на пару пунктов. Если модель чего-то не знает, додумать это она не сможет.
Для контента вывод простой: имена, даты, цифры и названия продуктов берутся только из источников в контексте. Особенно это касается тех, кто работает на deepseek-v4-pro: с 14 сентября такие запросы молча уйдут на V4.1-Flash.
3. Миллион токенов не значит понимание миллиона токенов
На LongBench-V2 у модели 45,2, у V4-Pro — 51,5. Когда адаптируете длинный отчёт, отдавайте нужные разделы, а не весь PDF целиком.
4. Картинки на вход рабочий инструмент
Модель нативно мультимодальная, на DocVQA у неё 95,6. Слайды спикера, скриншоты интерфейса и таблицы из PDF можно отдавать как есть и просить черновик. При этом картинка сжимается примерно до 1344×1344, так что длинные скриншоты и плотную инфографику лучше резать на части. И цифры, снятые с графиков, стоит проверять: на Chartography у модели 78,9, у Opus 5 — 84.
5. Max не по умолчанию
В API три уровня: low, high и max, внутри это 50, 75 и 100. Переход с 25 на 100 даёт плюс 8–9 пунктов на тестах и примерно в 2,5 раза больше токенов. Большая часть прироста набирается уже к 60–80. Эти данные только по математике и коду, по текстам замеров нет. Моя гипотеза: для рерайта, адаптаций и анонсов хватит low, для аналитики стоит брать high.
Забрать DeepSeek V4.1-Flash, опубликовано под лицензией MIT
#ai | 90 |
| 6 |  +5🚀К 2030 году российский рынок софта для ИИ вырастет почти в 4 раза
Apple Hills Digital исследовали рынок AI/ML/GenAI за 2022–2025 годы и подготовили прогноз до 2030 года. Посмотрели на динамику разных сегментов, переход бизнеса от экспериментов к измеримому ROI, роль облачных решений и основные ограничения для дальнейшего роста.
Главные выводы собрали в карточках, а полное исследование можно найти здесь 👀
📬 Мы в МАХ | 84 |
| 7 | Почти написал. Но пока почитайте исследование.
Интересно. | 83 |
| 8 |  Перелет до Москвы — прекрасная возможность написать про контент-заводы и все такое без нейронок. По старинке.
Главное — не уснуть. | 92 |
| 9 | Пятничное, отпускное, написанное с телефона.
Смотрите:
— 1 сентября Anthropic выпускает Claude Fable 5.1
— 2 сентября Google свою очередную Gemini 3.8 Flash, кстати, очень дешевую.
— 3 сентября вышла Muse Spark 1.3.
Ждем буквально на днях ещё релиз новой модели OpenAI ASTRA и новый Grok 4.7.
Конкуренция растет, токены дешевеют. Кажется выиграет сейчас тот, будет быстрее внедрять нужную модель на нужном шаге.
Ну и как анонс: сел писать, что я делал в своей системе агентов два месяца. Спойлер: ничего до двух последних дней. | 130 |
| 10 | Зашли с вопросом про стратегию или концепцию AI-first в контент. Но спросили с пониманием, что это когда в любом процессе буквально сначала ИИ. Сгенерили, потом посмотрели, что вышло.
Можно со мной тут поспорить, конечно, но «first» в таких терминах никогда не значило «сначала». Mobile-first — не про то, что мобильную версию рисуют раньше десктопной, а про то, что мобильный экран учитывается в каждом решении. Так же и здесь: AI-first — не порядок шагов, а то, что ИИ встроен во весь процесс, а не стоит отдельным этапом в начале или посередине.
Когда ИИ отдельный этап, вы, например, ускоряете написание черновика втрое, но материал упирается в проверку. Текстов стало больше, проверять чужое дороже, чем писать своё, редактор тонет. Локальное ускорение, глобальное замедление — знакомая история же?
Когда ИИ встроен, вы смотрите на весь маршрут материала: от идеи до разбора после публикации, и на каждом отрезке спрашиваете, что здесь меняется теперь, когда есть модель.
На планировании раньше спорили, какую тему взять: производство стоило дорого, ошибиться было больно. Теперь дешевле накидать три черновика и посмотреть, какой живой, чем неделю обсуждать один.
На брифе выясняется, что модель не читает мысли. Приходится проговаривать вслух: что на входе, что на выходе, что считается браком. Побочный эффект: люди тоже начинают понимать задачу с первого раза.
По той же причине из головы главреда наконец переезжает в файл редстандарт. Больно, зато у команды появляется общий критерий вместо «мне не нравится».
На проверке — главное. Сверить факт с источником, поймать разнобой в терминах, прогнать текст по стандарту: всё это машина делает лучше и дешевле, чем пишет. Но ставят её обычно на написание, потому что генерация эффектнее.
И на разборе после публикации: что зашло, что нет, почему. Раньше на это просто не хватало рук.
Проверить себя просто: спросите, что у вас изменилось, кроме того, что тексты теперь пишет модель. Если ничего — это не AI-first, а новый инструмент на одном этапе. Нормально, все с этого начинают, просто не надо называть это стратегией.
И то, что не меняется при любой встроенности: последний шаг человеческий, кто-то ставит подпись. В этом вся разница между «сначала ИИ» и «ИИ везде». В первом случае вы ищете, что бы ему отдать. Во втором понимаете, что оставляете себе и почему.
Брюзжание off. Пойду дальше работать. Постараюсь следующими публикациями дать что-то прикладное, а не только теорию, как нужно строить новые редакции.
#контентменеджерское #ai | 149 |
| 11 | «Что сейчас самое лучшее?» — неправильный вопрос
Давайте сегодня не про технину и агентов опять. Я начал со сложного и пропустил самое начало, а спрашивают как раз про него. С чего начать, что сейчас на острие, какая модель лучше, пора ли переезжать.
Отвечу сначала как спросили. Потом объясню, почему спросили не то.
По существу вопроса: берите то, что подходит вам, а не то, что вышло вчера.
Инструмент, в котором вы работаете каждый день, окупается не характеристиками, а наработанностью. Вы знаете, где он врёт. Знаете, какая формулировка даёт результат. У вас накопились заготовки, шаблоны, контекст. Это капитал, и переносится он плохо: на новом инструменте вы снова новичок, только теперь с завышенными ожиданиями. Три месяца притирки ради пятнадцати процентов на бенчмарке — плохая сделка.
А переезжают именно ради процентов на бенчмарке. Хотя бенчмарк меряет не вашу работу. Модель, которая решает олимпиадную математику, не обязательно держит ваш тон голоса. Победитель агентных задач не обязательно аккуратнее с фактами. Единственный честный тест — десять ваших типовых задач через оба варианта. Вечер работы.
А теперь забудьте всё, что я написал выше.
Не потому что неправда. Потому что не туда пошли изначально.
За вопросом «какую модель взять» почти всегда стоит надежда, что правильный выбор всё решит. Но я пока не видел ни одного случая, когда это срабатывает. Упираются не в модель.
Упираются в то, что стандарт не сформулирован: он живёт в голове главреда и достаётся оттуда в режиме «мне не нравится». В то, что источники не описаны и каждый берёт цифры откуда придётся. В то, что никто не знает, где текст проверяется и кем, потому что проверяет его тот, у кого сегодня есть время.
Более сильная модель не чинит ни одну из этих вещей. Она делает ровно одно: быстрее производит то, что вы всё равно не умеете принять. Вы получаете больше текста, который некому оценить по критерию, которого нет.
Поэтому мой ответ на «с чего начать» звучит скучно. Возьмите то, что уже под рукой. Найдите одну задачу, которая повторяется каждую неделю и от которой воет вся команда. Опишите её словами: что на входе, что на выходе, что считается браком. Не «пиши хорошо», а что именно делает текст непригодным. Пропишите процесс и доведите до состояния, когда он идёт без вашего участия в каждом шаге.
Вот тогда вопрос про модель станет осмысленным. Вы упрётесь и будет видно во что: в модель, в окружение или в собственное описание задачи. До этой точки ответить на него нечем.
И последнее, неприятное. Гонка за релизами — это способ не делать скучную часть. Читать про новое приятно, ощущается как работа, не требует ни одного решения и никого не злит. А сесть и выписать редполитику, договориться, кто отвечает за факты, и признать вслух, что ваш стандарт нигде не зафиксирован, — это конфликт, время и неудобные разговоры.
Поэтому все обсуждают модели. Модели обсуждать безопасно.
#контентменеджерское | 136 |
| 12 |  Понедельничное | 127 |
| 13 | Дело не в гуманитариях, а в конфигурации задачи. Или размышления о том, как внедрять ИИ в редакциях.
Давайте не про агенты, а про процессы. На митапе для редакторов в IT от YADRO я очень коротко рассказывал про то, как улучшить качество материалов, которые мы получаем от ИИ. И сам в процессе понял, что тема интересна даже не механиками, а психологией. Ведь я долго объяснял сопротивление ИИ у редакторов складом ума. Технари любят новое, гуманитарии, коих среди коллег большинство, держатся за ремесло. Удобная рамка, все кивают.
Рамка неверная. Я видел, как в её тени принимаются решения: «наймём тех, кто помоложе», «проведём воркшоп, они привыкнут». Не привыкают. Потому что сопротивление растёт не из склада ума, а из конфигурации задачи. Условий три, и у редакторов совпадают все три сразу.
Первое. Задача выглядит субъективной
Текст — это вкусовщина. Так его видит редактор, и не без оснований: он не может объяснить, почему эта фраза плохая, он её слышит. Там, где нет проверяемого критерия, доверять алгоритму не за что. Нечем поверить его выход.
Тут ловушка в слове «выглядит». Внутри редактуры полно вполне объективных кусков: факт сходится с источником или нет, термин единообразен или нет, структура соблюдена или нет. Но они не отделены, поэтому весь процесс окрашивается субъективным. Мы сами склеили проверяемое с непроверяемым и потом удивляемся, что доверие не выдаётся частями.
Второе. У человека есть экспертиза именно здесь
Десять лет практики, свёрнутые в интуицию. Это капитал, и он работает: редактор правит быстро и точно, не проговаривая ни одного правила.
Он же главное препятствие. Эксперт вообще плохо принимает советы, любые, не только машинные. Попробуйте предложить сильному редактору правку от другого сильного редактора И увидите ту же реакцию, что и на нейросеть. Просто человеку мы такое прощаем, а модели нет.
Третье. Модель спорит с твоим суждением, а не с чужим
Вот это самое недооценённое. Разница между «вот вариант коллеги, сравни со своим» и «вот вариант вместо твоего» кажется формальной. Она не формальная.
Почти все внедрения устроены по второй схеме. Модель отдаёт готовый текст, человек ставит оценку. То есть каждый раз ставится вопрос «ты или она», и каждый раз человек защищает себя. Мы буквально спроектировали процесс так, чтобы включалась самозащита, а потом называем результат технофобией.
Проверка на технарях
Если бы дело было в гуманитарной природе, разработчики принимали бы ИИ гладко. Не принимают.
Сеньор, который десять лет живёт в своей кодовой базе, тормозит ровно так же. У него та же тройка: качество кода он оценивает по неписаному стандарту, экспертизы вагон, и ассистент предлагает вместо его решения. Разница только в том, что он реже говорит об этом вслух — не принято.
Это, кстати, лучший аргумент в разговоре с руководством. Как только «наши редакторы боятся нового» превращается в «у наших редакторов совпали три условия, и у наших сеньоров они тоже совпали» — разговор переезжает с людей на процесс. А чинить процесс можно.
Что делать по каждому пункту
Расщепить задачу. Вытащить из «редактуры» то, что проверяемо, и назвать это отдельно. Редполитика в файле: что считается фактом, откуда берутся цифры, какие конструкции запрещены, что делаем с вендорскими заявлениями. Это больно, так как впервые заставляет команду проговорить то, о чём она молчаливо договорилась. Зато появляется предмет спора: критерий, а не вкус. И спорить начинают редакторы между собой, а не редактор с нейросетью.
Дать право править. Разница между «принять или отклонить» и «вмешаться внутрь» больше, чем кажется. В первом случае человек оценивает чужой результат целиком и потому придирается к целому. Поэтому одна кривая фраза хоронит нормальный текст, отправляя его на перегенерацию. Во втором он эту фразу просто переписывает и идёт дальше. Причём объём вмешательства почти не важен: достаточно, чтобы возможность править существовала. И вот что из этого следует. Чем плотнее вы закрываете процесс — «модель сама всё сделает, вам останется утвердить», — тем больше сопротивления получите на входе. Не потому что качество хуже, а потому что человеку не оставили места. Пайплайн, где нельзя ничего подкрутить, будет отвергнут скорее, чем пайплайн, который иногда выдаёт ерунду, которую можно поправить.
Поставить рядом, а не вместо. Обычная схема: редактор жмёт кнопку, получает готовый текст и ставит «ок» или «переделать». Но это не помощь, а экзамен, где экзаменуют его самого: свой вариант у него уже есть в голове, и принять чужой значит признать, что его был хуже. Он защищает себя, а не оценивает текст. Переставьте два шага: сначала свой заголовок, потом ещё три от модели — и он уже не сдаёт экзамен, а выбирает из четырёх, один из которых его. Отсюда три правила, и все они про то, кто в процессе автор:
1. Модель работает в начале, а не в конце: даёт сырьё — конспекты и черновики, — а не финал на утверждение, потому что чужой финал тяжело судить и хочется зарубить целиком, а из сырья просто собирают.
2. Вариантов всегда несколько: один — это закрытый вопрос «да или нет», где отказ стоит дорого, а три — открытый «какой», и даже слабые варианты работают, на их фоне видно, чем хорош сильный.
3. И своя версия появляется первой. Стоит один раз прочитать вариант модели и мысль уже не своя: дальше вы либо соглашаетесь с ним, либо спорите, но в обоих случаях думаете про её текст, а не про свой. Собственная идея просто не успевает родиться. Поэтому сначала набросайте свой заголовок — хоть кривой, хоть за тридцать секунд, — и только потом смотрите, что предложила модель.
Что не чинится
Под материалом стоит фамилия человека. Не модели. Пока это так, редактор будет проверять, и правильно сделает. Задача не в том, чтобы он перестал проверять, а в том, чтобы проверка стоила дешевле, чем написать самому.
И тут уже можно возвращаться к тому, о чём я рассказывал на митапе и рассказываю в канале. Но начинать, конечно, лучше вот с вышеописанных решений и договорённостей.
#контентменеджерское | 135 |
| 14 | На Хабре вышла статья коллеги о том, как развернуть локальный ИИ-агент в своём контуре — Ollama плюс OpenClaw. Рабочая инструкция, пользуйтесь.
#ai_agents #habr | 136 |
| 15 |  Пятничное | 247 |
| 16 |  DeepSeek открыл свой харнесс. За неделю вокруг него собрался каталог из 97 плагинов
Сначала база, потому что «харнесс» стало жаргоном, а объясняют его редко.
Модель — это функция «текст → текст». Она не умеет читать ваш репозиторий, запускать тесты, разбирать чужой стектрейс, откатываться после падения и продолжать работу на сороковом шаге. Всё это делает обвязка: агентный цикл, набор инструментов, системные промпты, права доступа, компакция контекста, песочница, логирование. Это и есть харнесс. Claude Code — харнесс. Модель — мозг, харнесс — руки, глаза и правила игры.
Отсюда следствие: цифра на агентном бенчмарке — это результат связки модель+харнесс, а не только свойство модели.
13 августа DeepSeek выложил Harness v0.1 в developer preview. MIT, пакет @deepseek-ai/dsh в npm, запуск одной строкой, веб-морда на 127.0.0.1:3080. За двое суток — больше 95 тысяч звёзд.
Как устроено
Главный принцип — «всё есть плагин». В обычном агенте ядро зашито: разработчики решили, какая модель, какие инструменты, как выглядит интерфейс, — а вы дописываете что-то по краям. Здесь сменное всё: модель, инструменты, скиллы, сессии, песочница, работа с файлами, сам цикл агента и интерфейс. Меняется конфигом, лезть в исходники не надо. Ставите и снимаете плагины на ходу, без перезапуска и без мусора после них — за это отвечает Cordis, микроядро под капотом.
Работать можно в четырёх режимах. Standard — обычный полноценный агент. Minimal — всего два инструмента, режим для замеров на бенчмарках. Creator — чтобы собрать свою сборку. И Code — самый любопытный.
Про Code стоит объяснить отдельно. Обычно агент дёргает инструменты по одному, и результат каждого целиком уезжает в контекст. Поиск нашёл сорок файлов — все сорок путей в контексте. Прочитали эти сорок файлов — ещё сорок портянок текста, которые модель перечитывает на каждом шаге. В Code-режиме модель вместо этого пишет маленькую программу, харнесс запускает её целиком, и назад приходит только итог — три строки вместо восьмидесяти простыней. Экономия контекста огромная. Минус — программу надо написать без ошибок с первого раза: если ошибётся, упадёт вся, а не один шаг.
И третье — всё пишется. Правило простое: что увидела модель, то и записано. В лог попадают промпты, рассуждения, вызовы инструментов и их результаты, каждая подгрузка контекста. Из этой записи можно продолжить сессию, ответвиться от любой точки, найти нужный момент и проиграть заново. Кто хоть раз пытался понять, почему агент на тридцатом шаге снёс тесты, оценит.
Что произошло за неделю
Появился каталог того, что успели написать под dsh. 97 плагинов, CC0, семь категорий, свой сайт и бейдж. У самого каталога 54 звезды — это ещё заявка на роль справочника, не справочник. И читать «97 плагинов» как «97 независимых авторов» не стоит: больше трети позиций — репозитории одной организации, omdsh-dev.
Показательно, за что взялись в первую очередь. Три плагина решают одну проблему — контекст:
→ dsh-context-doctor — аудит инъекций, токен-стоимость цепочек инструкций, каталогов скиллов и схем инструментов, детект дублей и конфликтов
→ dsh-tool-search — выдача схем инструментов по требованию вместо загрузки всех сразу
→ dsh-agent-budget — бюджет токенов на дерево агентов
И самый интересный плагин в списке: dsh-chat-import — тянет истории из Claude Code, Codex, ChatGPT и Cursor и превращает их в возобновляемые сессии dsh. Экосистема прекрасно понимает, откуда приходят люди.
Прежде чем идти ставить
Отбора в каталоге нет: пул-реквест — это одна строка в двух README, английском и китайском. Ни ревью качества, ни аудита безопасности. При том что часть плагинов лезет в файловую систему, в базы и в управление компьютером. Кстати, искать плагины можно и мимо каталога — по тегу dsh-plugin.
Сам харнесс — v0.1, и в README капслоком обещаны ломающие изменения. Писать плагин под dsh сегодня — не «поставил и забыл», а подписка на чужой рефакторинг.
Подробный разбор архитектуры и таблица по всем лабам, у которых уже есть свой харнесс, — есть на Хабре.
#ai #ai_plugin | 126 |
| 17 |  Давно хотел ввести новую более менее постоянную рубрику про полезные плагины — #ai_plugin
Начнём с максимально полезного — diagram-design — это новое дополнение к Claude Code, Codex и Pi. Уже 3,3 тысячи звёзд на GitHub, раздаётся бесплатно, лицензия MIT.
Что оно умеет
38 видов схем. Есть таймлайн, воронка, пирамида, квадрант «важность / трудозатраты», оргструктура, диаграмма Венна, столбики, линии, Гант. Всё, что обычно нужно в статье, лендинге или презентации.
Каждая схема — в трёх версиях: светлая, тёмная и «журнальная» с подписями-карточками. Файл открывается в браузере без установки чего-либо ещё и выгружается в PNG или SVG. Можно унести в статью, в слайды или отдать дизайнеру.
Главное — подстройка под ваш стиль
Пишете: «возьми фирменный стиль с такого-то сайта». Инструмент открывает главную страницу, находит цвета и шрифты, показывает, что предлагает применить, и ждёт вашего «да». Фон сайта становится фоном схемы, цвет кнопки — цветом акцента, ваш основной шрифт — шрифтом подписей.
Заодно проверяет читаемость: если фирменный цвет на мелком тексте плохо виден, предлагает подправить и объясняет, почему.
И приятная мелочь: при первом запуске в новом проекте он останавливается и спрашивает — настроить стиль или рисовать в дефолтном. Молча выдать безликую картинку не даст.
Автор зашила свой редстандарт: один акцентный цвет, один-два элемента, на которые читатель должен посмотреть первыми, тонкие линии, никаких теней. Целевая плотность — 4 из 10. Принцип: каждый блок должен заслужить своё место. | 126 |
| 18 | Проверка, которую агент не может пропустить
Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто.
Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке.
Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки.
Что у меня стоит на хуках:
→ Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще.
→ Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов.
→ Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же.
И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать.
Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс.
#ai_agents #contentops | 128 |
| 19 | Прочитал у Базы, что в Москве разработчика заподозрили в прохождении собеседования с помощью ИИ. И теперь СБ, как там написано "крупной ИТ-компании", на полном серьёзе присылает список вопросов, среди которых есть "знакомы ли Вам программы Codex и ShadowHint".
Интересно, как можно в августе 2026 года разработчику не знать, что такое Codex? И что это за ИТ-компания такая, что не пользуется тем, о чём спрашивает.
При этом логику безопасников я понимаю. Собеседование — проверка человека, а не его подписок. Если кандидат сидит с суфлёром в оверлее, вы нанимаете не инженера, а чужой инференс с задержкой в полсекунды. Это честная проблема, и она реально выросла за последний год. А если он ещё и использует ИИ вне контура и без разрешения, сливая туда код, то это уже прямая дыра в ИБ.
Но кажется, что разработка без ИИ в 2026 — это не безопасность, это утопия. Причём утопия задним числом: она описывает мир, которого уже нет, и предлагает нанимать людей, как будто он ещё есть.
То есть при найме должны быть другие вопросы уже. Не ответь на базовые вопросы, а объясни, что вот эта штука делает, и почему ты оставил её именно так. Тридцать минут разговора по чужому коду закроют вопрос понимания профпригодности человека. В собеседованиях на контентные позиции такая же проблема, кстати. Просить написать текст уже кажется очень глупой задачей на тестовое.
А при работе запрещать ИИ, потому что ИБ. Ну удачи... Это как запрещать пользоваться смартфоном уже.
Короче, любопытный кейс. Интересно, напишут ли чем закончилась проверка. | 147 |
| 20 |  Не забывайте классику! Только надо еще про «сделай нейросетью» добавить. | 150 |
