Давайте разберёмся, что здесь происходит на самом деле — от модели до публикации, без маркетинговой шелухи.

Что такое opencode и чем он отличается #

opencode — это интерактивный CLI-агент для помощи в программистских задачах. В отличие от Codex, он построен вокруг концепции скиллов — специализированных инструкций для конкретных типов задач — и MCP-серверов, которые дают агенту доступ к внешним инструментам без необходимости вручную выполнять команды.

В моём случае это не просто «чат с ИИ». Это инструмент, который:

• знает контекст моих проектов через Obsidian Volt;
• умеет работать с Hugo-блогом напрямую через MCP-сервер hugo;
• может искать информацию через SearXNG;
• умеет управлять заметками, тегами и структурой хранилища.

Главное отличие от Codex: опencode — это не привязка к одной модели, а оболочка, которая может работать с разными бэкендами и расширениями через скиллы и MCP 🔌

Модель под капотом: Qwen3.6-35B-A3B-MLX-6bit #

За опencode в текущей сессии отвечает модель Qwen3.6-35B-A3B-MLX-6bit. Разберём, что это значит на практике.

Qwen3.6 — это семейство моделей от Alibaba Group, третье поколение архитектуры Qwen. Модель позиционируется как одна из лучших в классе open-weight моделей с 35 миллиардами параметров.

35B-A3B — интересная архитектура. 35 миллиардов параметров, из которых активными при каждом проходе используется только ~3 миллиарда. Это Mixture-of-Experts (MoE) подход: модель активирует только нужные «экспертные» подсети для каждой задачи, что даёт скорость приближенную к гораздо меньшим моделям при качестве, сопоставимом с моделями в несколько раз большего размера.

MLX — это фреймворк от Apple для запуска LLM на чипах Apple Silicon. MLX оптимизирует загрузку и выполнение моделей на M-сериях процессоров, обеспечивая эффективное использование unified memory.

6bit — модель квантована до 6-битной точности. Это компромисс: при значительном уменьшении размера модели (примерно в 4 раза по сравнению с FP16) потери качества минимальны для большинства задач. Для написания текстов и работы с кодом 6-битная квантованная модель работает практически неотличимо от полной.

Почему это важно для написания постов. Модель достаточно ёмкая (35B total, 3B active), чтобы работать с длинными контекстами и сохранять логическую связность текста. Но при этом она runs locally на моей Mac-машине — никаких API-лимитов, задержек сети или отправки данных на сторону.

Инструменты и MCP-серверы #

Вот что подключено к opencode в ходе работы над этим постом:

Hugo MCP-сервер #

Позволяет агенту работать с Hugo-сайтом напрямую: проверять установку, список контента, собирать сайт, запускать локальный сервер. Это избавляет от необходимости вручную выполнять hugo list, hugo --minify — агент делает это через инструмент.

Obsidian MCP-сервер #

Дает доступ к моему Vault (~/temp/git.evgn.ru/obsidian/vault/) — это хранилище всех заметок, проектов и знаний. Через него агент:

• читает профиль проекта Projects/Блог (Hugo).md;
• смотрит правила написания постов;
• проверяет структуру и форматирование существующих статей.

SearXNG MCP-сервер #

Поисковый агрегатор для веб-поиска через instance search.evgn.ru. Позволяет агенту находить актуальную информацию, если нужно проверить факты или найти внешние источники.

Скиллы #

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

• impeccable — аудит и улучшение frontend-интерфейсов;
• infra-audit — аудит self-hosted сервисов;
• himalaya-inbox-cleaner — чистка почтового ящика;
• memory-consolidate и memory-patcher — управление долгосрочной памятью;
• unified-search — универсальный поиск по всем источникам;
• obsidian-vault-mcp — работа с Obsidian.

Рабочий процесс: как создаётся пост #

Процесс создания этого поста прошёл через несколько этапов, каждый из которых агент выполнял автономно:

1. Изучение контекста #

Первое, что сделал opencode — загрузил профиль проекта из Obsidian. Это заняло пару секунд: чтение Projects/Блог (Hugo).md и References/Управление блогом через MCP Hugo.md. Модель получила полную картину: структуру репозитория, правила постов, CI/CD-процесс, технический стек.

2. Анализ существующих постов #

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

3. Проверка актуальности #

Агент определил текущее время (МСК, 12:19) и сгенерировал дату поста 2026-07-21T12:14:00+03:00 — на 5 минут в прошлом, как требуют правила. Это важно: пост не должен оказаться в future, иначе CI его не опубликует.

4. Написание текста #

Самая сложная часть. Агент сгенерировал текст, опираясь на:

• правила из AGENTS.md (русский язык, минимум 2 эмодзи, структура с разделами);
• знание модели (Qwen3.6-35B-A3B-MLX-6bit, MoE, MLX, 6bit);
• контекст из Obsidian (правила фронтматтера, теги, toc);
• личный опыт автора (реальные инструменты, репозитории, инфраструктура).

Текст разделён на смысловые блоки: введение, описание модели, инструменты, рабочий процесс. Каждый раздел содержит конкретные детали, а не общие фразы.

5. Техническая валидация #

После написания текста агент проверил фронтматтер: формат даты, tags (взял из существующих постов), toc/readTime enabled. Summary и description — разные, без дублирования.

6. Публикация #

Финальный шаг — git commit и git push в ветку main. После этого CI/CD через Forgejo Actions автоматически соберёт сайт, проиндексирует поиск Pagefind и деплоит через rsync на сервер.

Что работает хорошо, а что — нет #

Сильные стороны #

• Контекстная осведомлённость. Агент читает Obsidian и знает о проекте больше, чем «чистый» LLM-чат.
• Автоматизация рутины. Фронтматтер, дата, теги, проверка future-дат — всё это агент делает сам.
• Локальность. Модель работает на Mac, данные не покидают машину. Это важно для приватности и скорости.
• Скиллы. Специализированные инструкции позволяют агенту быстро переключаться между задачами: сегодня пишет пост, завтра чистит почту.

Слабые места #

• Стиль. Текст агента иногда слишком «структурирован» — разделы идут как по шаблону, без естественных отклонений. Авторская редактура важна не для «исправления ошибок», а для добавления живости.
• Глубина технических деталей. Агент знает, что модель называется Qwen3.6-35B-A3B-MLX-6bit, но может ошибиться в архитектурных нюансах. MoE — это Mixture of Experts, а не какая-то абстрактная физика: агент описывает её на основе общих паттернов, а не реального опыта.
• Эмоциональная тональность. Агент хорошо справляется с информационным содержанием, но тон текста часто остаётся «нейтрально-аналитическим». Авторская правка добавляет иронию, личные наблюдения, интонацию.

Почему это вообще имеет смысл #

Главный вопрос: зачем писать пост об ИИ, который пишет посты?

Потому что это не новый способ «генерации контента». Это новый способ разделения труда.

Автор остаётся там, где он уникально полезен:

• формулирует идею и позицию;
• добавляет личный опыт и фактуру;
• контролирует логику аргументации;
• решает, что стоит рассказать, а что — нет.

Агент берёт на себя:

• поиск и структурирование контекста;
• черновую сборку текста из тезисов;
• техническое оформление (фронтматтер, теги, форматирование);
• валидацию перед публикацией.

Результат — не «ИИ написал статью», а «автор написал статью быстрее и увереннее, потому что инструмент снял операционную нагрузку».

Сравнение с Codex: два инструмента, разные роли #

Codex и opencode — это не конкуренты, а взаимодополняющие инструменты. Вот как они отличаются в моём рабочем процессе:

Codex лучше подходит для сложных задач, где нужна максимальная «интеллигентность» — анализ архитектуры, написание кода, глубокие рассуждения. opencode — для задач, где важна скорость, локальность и работа с известным контекстом.

Для блога opencode сейчас работает лучше: он знает правила, структуру и стиль проекта через Obsidian, и не требует API-доступа.

Итог 🧠 #

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

1. Идея — от автора.
2. Контекст — агент собирает из Obsidian и репозитория.
3. Черновик — агент собирает из тезисов и контекста.
4. Редактура — автор добавляет фактуру, иронию, личный опыт.
5. Техника — агент оформляет фронтматтер, проверяет дату, делает commit/push.
6. Деплой — CI/CD собирает и публикует.

Модель Qwen3.6-35B-A3B-MLX-6bit — хороший выбор для этого: достаточно ёмкая для понимания контекста, достаточно быстрая для итеративной работы, достаточно локальная для приватности.

А opencode — это не просто «ещё один ИИ-ассистент». Это инструмент, который объединяет модель, скиллы и MCP-серверы в единый рабочий процесс. И для блога на Hugo это сейчас оптимальная комбинация: быстро, локально, с полным знанием контекста.

Источники #

• Qwen3.6: Alibaba Group — Qwen
• MLX: Apple MLX
• opencode: opencode.ai

С прошлого разбора прошёл ровно месяц: 0.163.3 вышел 18 июня, 0.164.0 — 6 июля. После «квартала инфраструктурного взросления» с AVIF и хардненингом этот релиз выглядит скромнее: одна минорная версия, никаких громких фич.

Но два пункта в нём заслуживают внимания:

1. Стили Chroma получили dark/light-пары. Подсветка кода наконец умеет жить в двух темах штатно, а не через самодельные костыли.
2. Починена регрессия производительности, тянувшаяся с 0.128.0. Это не новая фича, а возврат утраченного — но на больших сайтах разница заметна.

Остальное — приятные мелочи в шаблонных функциях и один депрекейт. Breaking changes как таковых нет, обновление спокойное.

Главное за один взгляд #

Фичи:

• Dark/light-пары в стилях Chroma — подсветка синтаксиса умеет два режима; у команды hugo gen chromastyles появились новые флаги.
• Новые шаблонные функции: crypto.Hash, encoding.HexEncode, encoding.HexDecode.
• Опция markup.rst.syntaxHighlight — подсветка для reStructuredText.
• Поддержка цитат в Pandoc — для тех, кто держит библиографию.
• Вложенные пути в layouts для Page.Render.
• Фикс регрессии производительности из 0.128.0 — обсуждение на Discourse тянулось долго.

Депрекейт:

• resources.PostProcess объявлен устаревшим в пользу templates.Defer (issue #15086).

Мелочи, которые могут задеть:

• Поиск имени шаблона стал регистронезависимым (#15057).
• .Render теперь возвращает ошибку, если шаблон не найден (#15052) — раньше молча отдавал пустоту.
• IsSet включает ключ в предупреждение о неподдерживаемом типе.

Dark/light в Chroma 🌗 #

Главная фича релиза — и, пожалуй, самая недооценённая.

Раньше стиль подсветки в Hugo был один на весь сайт: в hugo.toml задавался markup.highlight.style, и всё. Если сайт умеет переключаться между светлой и тёмной темой, приходилось выкручиваться: генерировать два CSS-файла через hugo gen chromastyles, руками оборачивать их в медиа-запросы или классы, следить за синхронизацией.

Теперь Chroma внутри Hugo знает про парные режимы, а у hugo gen chromastyles появились флаги для генерации нужного варианта. Смысл простой: светлая и тёмная схемы подсветки — это не два несвязанных стиля, а пара, и Hugo теперь так к ним и относится.

Что это значит для нашего блога. Прямое попадание. Переключатель дня и ночи здесь работает на JS с сохранением выбора в localStorage — то есть тема меняется без перезагрузки, и подсветка кода должна меняться вместе с ней. Сейчас в конфиге один [markup.highlight] на оба режима, и в тёмной теме блоки кода выглядят компромиссно. Это следующий пункт в списке доработок: сгенерировать пару стилей и подцепить их к тому же переключателю. В этот заход не делаю — обновление и так вышло насыщенным, — но фича переехала из «знать» в «внедрять».

Регрессия производительности: возврат утраченного ⚡ #

Незаметная, но приятная часть. В 0.128.0 (это июль 2024-го) в сборку просочилась регрессия, из-за которой большие сайты собирались медленнее. Симптом обсуждали на Discourse больше года, и вот в 0.164.0 его закрыли.

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

Новые функции: crypto.Hash и hex 🔧 #

Три новые шаблонные функции:

{{ crypto.Hash "sha256" "текст" }}
{{ encoding.HexEncode "привет" }}
{{ encoding.HexDecode "d0bfd180d0b8d0b2d0b5d182" }}

crypto.Hash принимает алгоритм явным параметром — удобнее, чем существующие md5/sha1/sha256 по отдельности. Практический сценарий — стабильные идентификаторы: захешировать путь или содержимое и получить детерминированный ключ для кэша, якоря или имени файла.

Hex-функции закрывают давнюю мелочь: base64 в шаблонах был, а hex приходилось изображать вручную.

Для нашего блога — пока в копилку. Ни одного места, где это было бы нужно прямо сейчас, нет.

Депрекейт resources.PostProcess ⚠️ #

Единственное, за чем стоит следить.

resources.PostProcess использовался для отложенной обработки ресурсов — классический сценарий — PurgeCSS/Tailwind, когда нужно узнать финальный HTML, чтобы вычистить неиспользуемые классы. Теперь рекомендуется templates.Defer, механизм более общий и предсказуемый.

Нас не задевает: проверил layouts/ и themes/ — resources.PostProcess не используется нигде. CSS через Hugo Pipes с Tailwind мы не собираем, а Pagefind живёт отдельным npm-инструментом и к ресурсной цепочке отношения не имеет.

Если у вас Tailwind в Pipes — это первое, что нужно проверить перед обновлением: депрекейт пока не ломает, но направление задано.

Осторожно: .Render теперь возвращает ошибку #

Мелочь из списка изменений, которая может неприятно удивить. Раньше .Render с несуществующим шаблоном молча отдавал пустую строку — и сайт собирался, просто без куска контента. Теперь он возвращает ошибку, то есть сборка упадёт.

Формально это исправление, а не breaking change: молчаливая пустота — плохое поведение. Но если у вас в шаблонах есть вызов .Render с опечаткой в имени, который «работал» годами, — обновление его вскроет. Заодно поиск имени шаблона стал регистронезависимым, так что часть таких опечаток теперь, наоборот, начнёт находиться.

Инфраструктура: заодно поменяли базу образа 🐳 #

Здесь стоит рассказать про то, что к самому Hugo отношения не имеет, но всплыло при обновлении.

Блог собирается в собственном Docker-образе, куда запечены Hugo Extended, Node и Pagefind. Пошёл поднимать версию Hugo — и обнаружил, что база образа node:20-bookworm-slim достигла EOL 30 апреля 2026. То есть почти три месяца образ жил без обновлений безопасности базового слоя.

Node здесь нужен ровно для одного — установить Pagefind. Поэтому смена мажора малорискованная, и база переехала сразу на Node 24 (LTS, поддержка до апреля 2028). Итоговый образ:

hugo v0.164.0+extended linux/amd64
node v24.18.0
pagefind 1.5.2

Мораль простая и не новая: следите не только за приложением, но и за базовым слоем. Версию Hugo видно в каждом релизном посте, а FROM node:20 тихо стареет в первой строке Dockerfile, пока про него не вспомнишь.

Отдельная заметка на будущее — образ до сих пор собирался руками, поэтому и отстал. Правильный путь: собирать его в CI при изменении Dockerfile. У сборки на нашем раннере есть нюанс — он живёт в LXC-контейнере, где docker build не может применить AppArmor к промежуточным RUN-контейнерам и падает. Обходится это kaniko: он собирает образ в userspace, без демона Docker и вложенных контейнеров. Тот же приём уже используется для других наших образов.

Что это значит для нашего блога #

• Chroma dark/light — самая полезная фича релиза именно для нас, ложится на существующий переключатель темы. В работу.
• Фикс производительности — приятно, но на сотне страниц незаметно.
• Депрекейт PostProcess — не задевает, проверено.
• .Render с ошибкой — не задевает, но стоит держать в голове.
• Обновление базы образа с Node 20 на Node 24 — по факту важнее самого апдейта Hugo.

Чек-лист обновления ✅ #

1. Обновление спокойное. С 0.163.x на 0.164.0 идти можно без подготовки: breaking changes нет, депрекейт один.

2. Если используете resources.PostProcess (обычно это Tailwind/PurgeCSS в Pipes) — запланируйте переход на templates.Defer:

   grep -rn 'resources.PostProcess' layouts/ themes/

   copy

3. Если в шаблонах есть .Render — проверьте имена шаблонов: теперь несуществующий шаблон роняет сборку, а не молчит.

4. Если у сайта есть тёмная тема — посмотрите на парные стили Chroma, это заметное упрощение по сравнению с самодельными решениями.

5. Проверьте базовый слой сборочного образа, а не только версию Hugo. Node 20 в EOL с 30 апреля 2026:

   grep -n '^FROM' Docker/Dockerfile

   copy

6. Стандартный прогон и сверка предупреждений до и после:

   hugo --minify --gc

   copy

Итог 🧠 #

0.164.0 — релиз-передышка после насыщенного квартала. Одна по-настоящему полезная фича (парные стили Chroma), одно давно ожидавшееся исправление (регрессия скорости из 0.128.0), горсть новых шаблонных функций и один аккуратный депрекейт.

Обновляться стоит: рисков практически нет, а dark/light-подсветка снимает целый класс костылей для сайтов с переключателем темы.

Но главный вывод этого обновления оказался не про Hugo. Версию генератора видно в каждом релизном посте, а базовый слой образа стареет молча — и именно он оказался просроченным на три месяца, а не Hugo, отставший на одну минорную версию.

Источники #

• Релиз 0.164.0: gohugoio/hugo v0.164.0
• Режимы стилей подсветки: gohugo.io/quick-reference/syntax-highlighting-styles/#modes
• crypto.Hash: gohugo.io/functions/crypto/hash/
• encoding.HexEncode: gohugo.io/functions/encoding/hexencode/
• Обсуждение регрессии производительности: discourse.gohugo.io
• График поддержки Node.js: endoflife.date/nodejs

С прошлого разбора (v0.160.1, 8 апреля) накопилось пять релизов: 0.161.0, 0.161.1, 0.162.0, 0.163.0 и патчи до 0.163.3 (18 июня). Это не один минор, а целый квартал развития — поэтому разбор догоняющий.

Если сжать до двух заголовков, их два:

1. AVIF — Hugo научился кодировать и декодировать AVIF прямо в image pipeline. Третий формат рядом с JPEG и WebP, и для фото-блога это самое интересное.
2. Хардненинг безопасности — Node-инструменты теперь запускаются с --permission, text/html-контент запрещён по умолчанию, ужесточены security.http.urls, плюс транзитом приехали XSS-фиксы из Go 1.26.3.

Остальное — приятные улучшения конфигурации (slice-based permalinks, гибкие идентификаторы в именах файлов, вложенные vars в css.Build) и порция депрекейтов. Breaking changes есть, но точечные — разберём, кого они задевают.

Главное за один взгляд #

v0.161.0 / 0.161.1 (28–29 апреля) — фичи + первый хардненинг:

• Node-инструменты (PostCSS, Babel, TailwindCSS) запускаются с флагом --permission. Нужен Node ≥ 22, а Tailwind теперь только как npm-пакет (standalone-бинарь больше не поддерживается).
• Ужесточены дефолты security.http.urls; добавлен security.node.permissions (включая AllowChildProcess).
• Slice-based permalinks — конфигурация permalinks с target-матчерами (как в cascade).
• Гибкая схема идентификаторов в именах файлов: _language_en_, _role_, _version_.
• Вложенные vars в css.Build / css.Sass: @import "hugo:vars/dark".

v0.162.0 / 0.162.1 (26–28 мая) — AVIF + security:

• 🎯 Поддержка AVIF (encoder + decoder) в image pipeline.
• text/html-контент запрещён по умолчанию — новая политика security.allowContent.
• Go 1.26.3: фиксы XSS в html/template (CVE-2026-39826, CVE-2026-39823).
• Проверка security.http.urls на каждом редирект-хопе resources.GetRemote; отказ от symlink-записей в resources.Get.

v0.163.0 (8 июня) — тюнинг AVIF + депрекейты:

• AVIF по умолчанию quality = 60 (≈ JPEG/WebP q75), content-aware chroma subsampling через hint, качество настраивается per-format.
• Депрекейт глобального imaging.quality и Imaging.Compression (переезжают в per-format конфиги).
• Добавлен .IsBranch, депрекейт .IsNode; депрекейт baseUrl в jsconfig.

v0.163.1 / 0.163.2 / 0.163.3 (11–18 июня) — патчи:

• Security: bump golang.org/x/image, нормализация integer-IPv4 в http.urls, отказ от symlink в os.ReadDir/ReadFile/Stat/FileExists.
• Escape lang в дефолтном рендере код-блоков; сохранение non-ASCII пробела после summary-разделителя; поддержка вариантов конфигов babel/postcss; фикс регрессии коллизии имён page/section.

Дальше — что это значит на практике.

AVIF: третий формат в pipeline 🖼️ #

Главная фича квартала. В 0.162.0 Hugo получил полноценную обработку AVIF — и кодер, и декодер (issue #7837, висел с 2020 года). AVIF при том же визуальном качестве заметно легче JPEG и обычно легче WebP, плюс умеет HDR (у Hugo есть демо-сайт, который имеет смысл смотреть на HDR-экране вроде Retina).

В 0.163.0 фичу довели до ума:

• Дефолтный quality для AVIF опустили до 60 — оказалось, JPEG/WebP с q75 сопоставимы с AVIF q60. Не гоните качество вверх по привычке.
• Появился hint (как у WEBP): для lossy фото по умолчанию используется YUV420 chroma subsampling, а для текста/иконок/схем — 444. Это резко снижает память на кодирование больших картинок.
• Качество можно задавать на формат:

[imaging]
  # глобальный quality теперь deprecated
[imaging.webp]
  quality = 80
[imaging.avif]
  quality = 60
  hint    = "photo"

В шаблоне AVIF получается так же, как WebP — через .Process / метод ресайза:

{{ $img := resources.Get "img/cover.jpg" }}
{{ $avif := $img.Process "resize 1600x avif" }}
<picture>
  <source srcset="{{ $avif.RelPermalink }}" type="image/avif">
  <source srcset="{{ ($img.Process "resize 1600x webp").RelPermalink }}" type="image/webp">
  <img src="{{ ($img.Resize "1600x").RelPermalink }}" alt="…">
</picture>

Что это значит для нашего блога. Раздел /photos уже генерит 800/1600/2400 px в JPEG + WebP и отдаёт через <picture>/srcset. Добавить AVIF — это правка шаблона, который собирает <source>-ы (плюс per-format quality в hugo.toml): первым <source type="image/avif">, дальше WebP, в конце JPEG-фолбэк. Браузеры берут первый поддерживаемый. На фотографиях с retina это даст ощутимую экономию трафика при том же качестве. В этот заход не делаю — но это очевидный следующий шаг для фото-ленты.

Хардненинг безопасности 🔒 #

Самая «breaking» часть. Изменения копились через все релизы:

Node-инструменты под --permission (0.161.0). PostCSS, Babel и TailwindCSS теперь запускаются с Node permission-флагом и правами из security.node.permissions. Следствия:

• нужен Node ≥ 22;
• css.TailwindCSS требует Tailwind CLI как npm-пакет — standalone-бинарь больше не годится.

Если вы собираете CSS через Hugo Pipes с Tailwind/PostCSS — это первое, что стоит проверить перед обновлением.

Запрет text/html-контента по умолчанию (0.162.0). Новая политика security.allowContent гейтит, какие media-типы допустимы для страниц в /content. text/html теперь запрещён по умолчанию. Сайты, где есть руками написанные .html-файлы в content/ (или их эмитит content adapter), вернут доступ явно:

[security]
  allowContent = ['.*']

Прочее (0.162.0 → 0.163.3):

• security.http.urls перепроверяется на каждом редирект-хопе в resources.GetRemote — мимо валидации больше не проскочить через 30x.
• Symlink-записи отклоняются в resources.Get, а в 0.163.1 — ещё и в os.ReadDir/ReadFile/Stat/FileExists.
• Go подняли до 1.26.3 с фиксами XSS в html/template (CVE-2026-39826, CVE-2026-39823) — это касается любого сайта, рендерящего недоверенный ввод в шаблонах.

Любопытная ремарка от мейнтейнера в release notes 0.163.1: всплеск security-репортов в последнее время — это не «Hugo стал менее безопасным», а работа новых AI-инструментов, которые берут security-модель Hugo за baseline и методично её простукивают.

Slice-based permalinks 🔗 #

В 0.161.0 конфигурация permalinks стала гибче (старая map-форма продолжает работать). Теперь это список с теми же target-матчерами, что и в cascade:

permalinks:
  - target:
      kind: page
      path: "/books/**"
    pattern: /books/:year/:slug/
  - target:
      kind: page
    pattern: /other/:slug/

Удобно, когда для разных секций нужны разные схемы URL без дублирования настроек. Нашему блогу с плоской структурой posts/ это пока избыточно, но знать про механизм полезно — особенно если когда-нибудь заведём разделы со своими правилами URL.

Гибкие идентификаторы в именах файлов 🏷️ #

Тоже из 0.161.0. Раньше язык кодировался как mypost.en.md. Теперь доступна расширяемая схема префиксов в имени файла:

content/mypost._language_en_.md эквивалентно content/mypost.en.md, но открывает дорогу к версиям и ролям контента. Для одноязычного блога — мимо, для документации с версиями — заметное упрощение.

css.Build: вложенные vars 🎨 #

Развитие фичи из 0.160. К @import "hugo:vars" добавились вложенные наборы — @import "hugo:vars/<name>". Классический сценарий — палитры под prefers-color-scheme:

[params.style]
  primary    = "#000000"
  background = "#ffffff"
  [params.style.dark]
    primary    = "#ffffff"
    background = "#000000"

@import "hugo:vars";
@import "hugo:vars/dark" (prefers-color-scheme: dark);

Аккуратно, но не для нас: переключатель дня/ночи на блоге работает через JS и localStorage (явный выбор пользователя, без авто), а не через prefers-color-scheme. Палитра живёт в :root. Так что фича в копилку «знать», но не «внедрять».

Депрекейты и мелочи #

• .IsNode → .IsBranch (0.163.0): если в шаблонах есть .IsNode, мигрируйте на .IsBranch (issue #11574).
• Глобальный imaging.quality (0.163.0): помечен deprecated в пользу per-format ([imaging.webp], [imaging.avif], …). Старая форма пока работает и даже не всегда ругается — но направление задано.
• jsconfig baseUrl убран (был deprecated).
• Сохранение non-ASCII пробела после summary-разделителя (0.163.3) — мелочь, но именно для кириллических текстов с `

` это правильное поведение.

• Фикс коллизии имён page/section (0.163.3, #15046) — регрессия, всплывшая в 0.163.x; ещё одна причина брать самый свежий патч, а не 0.163.0.

Что это значит для нашего блога #

Прогнал блог на 0.163.3 — собирается чисто, 90 страниц, 0 ошибок, 52 изображения обработаны без проблем. Конкретика:

• Запрет text/html нас не задел — в content/ нет руками-сверстанных .html, всё в Markdown. security.allowContent трогать не нужно.
• Node-permission мимо — Tailwind/PostCSS через Pipes не используем, Pagefind живёт отдельным npm-инструментом.
• languageCode → locale: попутно почистил deprecation в hugo.toml (languageCode = 'ru-RU' → locale = 'ru-RU'). Этот warning ушёл. Оставшиеся три (.Site.LanguageCode, .Language.LanguageCode, .Language.Direction) приходят из шаблонов темы typo — уйдут, когда обновится тема.
• AVIF — главная зацепка на будущее: добавить третий <source> в фото-pipeline и срезать вес ленты /photos.

Чек-лист обновления ✅ #

1. Прыгайте сразу на 0.163.3, а не на 0.163.0 — патчи .1/.2/.3 закрывают security-дыры и регрессию коллизии имён.

2. Если собираете CSS через Tailwind/PostCSS/Babel в Pipes — поставьте Node ≥ 22 и Tailwind как npm-пакет; проверьте security.node.permissions.

3. Если в content/ есть .html-файлы — добавьте security.allowContent = ['.*'], иначе страницы выпадут из сборки.

4. Почистите депрекейты:

   # languageCode → locale в конфиге
   # .IsNode → .IsBranch в шаблонах
   grep -rn '\.IsNode' layouts/ themes/

   copy

5. Если работаете с изображениями — присмотритесь к AVIF и per-format quality; глобальный imaging.quality уводите в [imaging.<format>].

6. Стандартный прогон и сверка warning’ов до/после:

   hugo --minify --gc

   copy

Итог 🧠 #

0.161–0.163 — это квартал «инфраструктурного взросления» Hugo: новый формат изображений (AVIF), методичный security-хардненинг и более гибкая конфигурация (permalinks, идентификаторы файлов, вложенные CSS-vars). Громкая фича ровно одна — AVIF; всё остальное либо про безопасность, либо про удобство.

Breaking changes реальны, но адресные: они бьют по сайтам с Tailwind-в-Pipes и с HTML-контентом в content/. Если вы (как наш блог) пишете на чистом Markdown и не гоняете Node-сборку CSS — переход бесшовный, достаточно поднять версию и пробежаться по депрекейтам.

Если сидите на 0.160 или раньше — есть смысл прыгать сразу на 0.163.3, мимо промежуточных: так вы заодно получите все security-фиксы одним движением.

Источники #

• Релиз 0.161.0: gohugoio/hugo v0.161.0
• Релиз 0.162.0: gohugoio/hugo v0.162.0
• Релиз 0.163.0: gohugoio/hugo v0.163.0
• Релиз 0.163.3: gohugoio/hugo v0.163.3
• Конфигурация AVIF: gohugo.io/configuration/imaging/#avif
• Security-модель Hugo: gohugo.io/about/security/

Если ты когда-нибудь просил AI-помощника (Claude, ChatGPT, Cursor) сделать тебе сайт, ты замечал одно и то же: получается вроде неплохо, но подозрительно «как у всех». Тёмно-синий фон, фиолетовый градиент в заголовке, карточки с лёгкой тенью, шрифт Inter. Узнаваемый «AI-look».

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

Impeccable от Paul Bakaus решает именно эту задачу. Сам автор позиционирует его как «дизайн-словарь для AI-помощников по коду»: набор из одного навыка и 23 команд, которые дают AI и человеку общий понятийный аппарат. Каждая команда отвечает за свою дизайн-дисциплину: типографика, цвет, ритм пространства, взаимодействия, копирайтинг, элевация (тени и слои), анти-паттерны. Плюс отдельный список из 25 типичных «AI-ляпов», которые детектор ловит автоматически.

Что важно: impeccable — не библиотека CSS-токенов и не редактор макетов. Он живёт в твоём боевом коде, читает существующие исходники, рендеренный HTML, дизайн-документы, и вместе с AI правит то, что уже есть. Не «нарисуй мне сайт с нуля», а «доведи существующий до состояния, в котором он перестанет быть похожим на любой другой блог».

Я взялся применить это к собственному Hugo-блогу. Hugo — статический генератор сайтов: ты пишешь посты в Markdown, конфиг и HTML-шаблоны, он собирает готовые HTML-файлы. Дизайн жил в одном CSS-файле плюс тема typo как git submodule. К апрелю накопилось ощущение «работает, но как-то не так». Тёмная тема жила в одной палитре, светлая — местами в другой. Страница «Обо мне» выглядела как кусочек чужого SaaS-сайта, попавший в блог по ошибке.

Решил пройти все нужные команды и посмотреть, что инструмент реально ловит. Получилось пять заходов за вечер.

Фундамент: PRODUCT.md и DESIGN.md #

Первая команда — /teach. Это не «настройки», а короткое интервью: кому пишешь, каким голосом, чем не должен быть сайт, какие требования к доступности. На выходе два файла в корне проекта:

• PRODUCT.md — стратегический документ. Регистр (бренд или продукт), целевая аудитория, голос, анти-референсы, дизайн-принципы, планка доступности.
• DESIGN.md — визуальная спецификация. Цвета, шрифты, шкала пространства, шкала радиусов, компоненты.

Эти два файла потом читает каждая последующая команда. Без них любой /audit или /polish даёт ответы вообще, не привязанные к конкретному проекту.

Главное открытие здесь — раздел анти-референсов. PRODUCT.md заставляет ответить, чем сайт не должен быть. Я выписал четыре конкретных образца, которые не хочу повторять:

• Habr и VC.ru с их боковыми панелями, бейджами и блоками «читайте также» на пять экранов;
• Medium и Substack: безликий шаблон платформы, попап «подпишись», где ощущение «это любой блог»;
• современный SaaS с градиентами и стеклянными карточками;
• Dev.to и обычные GitHub Pages: стандартный markdown без типографики, синие ссылки, sans-serif, ноль характера.

Анти-референсы оказались полезнее обычных «делай как Stripe». «Как Stripe» — растяжимое: можно повторить любой кусок и сказать «вот видишь, похоже». «Не как Habr» — конкретный отказ. Каждое следующее дизайн-решение проверялось по этому списку и часто не проходило: «а не повторяю ли я сейчас Habr-ленту одинаковых превью?»

Дальше команда /document отсканировала существующий CSS и собрала DESIGN.md. Здесь я первый раз ошибся — но об этом дальше.

Аудит: 11 из 20 на старте 📊 #

/audit — техническая проверка по пяти направлениям, каждое от 0 до 4 баллов: доступность, производительность, согласованность дизайн-токенов, адаптивность, отсутствие шаблонных AI-ляпов.

Финальная оценка моего блога — 11 из 20. Между «нормально, но работы много» и «плохо». От «плохо» вытащило только производительность (Hugo и так быстрый, картинки грузятся лениво, шрифты с правильной стратегией загрузки).

Что нашлось:

Контраст вторичного текста проваливал стандарт WCAG AA в обеих темах. Цвет #6272a4 на светлом фоне #f8f8f2 давал соотношение контраста 3.92:1, на тёмном #282a36 — 3.33:1. Стандарт WCAG AA требует минимум 4.5:1 для основного текста. Эта переменная использовалась одновременно как цвет вторичного текста, как цвет ссылок в светлой теме и как мета-информация. Поражено больше 40% не-основного контента сайта.

Страница поиска в светлой теме выдавала белый текст на белом фоне. В моём CSS заголовки результатов поиска имели цвет #f8f8f2 (захардкожен под тёмную тему). На светлой теме фон тоже #f8f8f2 — белый на белом. Я этого не замечал, потому что почти всегда сижу в тёмной теме. Половина посетителей видела пустые результаты поиска полтора года.

Страница «Обо мне» — типичный SaaS-клон. Шрифт Inter (один из самых заезженных AI-выборов), фон с линейным градиентом, тяжёлая тень под аватаром. Все четыре анти-референса из PRODUCT.md в одном экране.

Кликабельные элементы меньше 44 на 44 пикселей. Кнопка переключения темы — 32–35 пикселей. У ссылок в навигации не было внутренних отступов, кликабельная зона = площадь самого текста. Стандарт WCAG 2.1 рекомендует минимум 44×44 для тача и моторной доступности.

У цитат border-left в 2 пикселя. Эта самая полоска слева у «цитаты». В философии impeccable любая боковая полоска шире 1 пикселя — отдельный анти-паттерн (типичный «callout-style» из старых книг по веб-дизайну).

Семь крупных проблем плюс несколько помельче. Чинилось всё в одном проходе: подняли цвет вторичного текста до читаемого, переписали страницу «Обо мне» с нуля без шрифта Inter и градиентов, сделали все статусы reading-секции чувствительными к теме, расширили кликабельные зоны. После — оценка поднялась до 18 из 20.

Без /audit я бы половину этих проблем не нашёл. Особенно поиск в светлой теме: я не садился в светлую тему вживую неделями.

UX-ревью и кейс с фиктивным компонентом #

Дальше — /critique. Это уже не технический аудит, а ревью на уровне дизайн-решений: правильно ли устроена главная как точка входа, не теряется ли пост в ленте, нужен ли архив-по-годам, есть ли узкие места в навигации.

Команда устроена так, что запускает два независимых ревью одновременно. Один — отдельный AI-агент с фокусом на пользовательский опыт; читает исходники и рендеренный HTML. Второй — программный детектор npx impeccable --json, проверяющий 25 конкретных шаблонных AI-ляпов автоматически. И ключевое: они не видят выводы друг друга. Это сделано специально — чтобы один не подтверждал догадки другого.

Я к этому отнёсся скептически. Думал, что изоляция «для красоты».

Оказался неправ.

Отдельный AI-агент за пять минут нашёл вот что: в моей же DESIGN.md, которую я сам написал часом ранее, описан боковой sticky-блок «Содержание» как одна из ключевых деталей сайта. Подробно: фиксированное позиционирование, ширина 260 пикселей, рамка, скругление, размеры ссылок, активное состояние. И сразу следом: «один из главных компонентов сайта; обслуживает чтение длинных постов вторым по важности после самого текста».

А в layouts/_default/single.html (мой собственный шаблон страницы поста) этого блока нет. Поиск по проекту: ноль вхождений toc-sidebar, toc-sticky, TableOfContents. Только 190 строк CSS-стилей, который никем не используется, потому что HTML-разметку никто не выводит. Документация описывала то, чего на сайте не было.

Что произошло: при первом проходе /document я смотрел в CSS, увидел проработанный sticky-блок и описал его в DESIGN.md как рабочий компонент. Не проверил, что в шаблонах кто-то этот класс выводит. CSS живёт, разметки нет — а я этого не заметил, потому что неудобно увидеть, что я только что подробно описал то, чего не существует.

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

Отдельный AI-агент в /critique не видел ни моих рассуждений по команде /document, ни моей DESIGN.md как авторитетного источника. Он читал её как один из файлов проекта. И тут же подсветил расхождение: «sticky TOC задокументирован как ключевой элемент, не рендерится ни на одной странице».

Этот один пункт окупил весь подход с двумя независимыми ревью. Я зашил это в персональную память Claude Code как правило: прежде чем называть компонент ключевым в DESIGN.md, надо проверить, что он действительно рендерится в шаблонах, а не только в стилях. Стилевой блок без HTML-разметки — мёртвый код, не «компонент».

После этого /critique нашёл ещё несколько пунктов помельче:

• листинг прочитанных книг сделан карточной сеткой — это прямой анти-референс из моей же PRODUCT.md;
• три параллельных шаблона шапки и подвала на разных страницах с чуть разным поведением;
• текст страницы «Обо мне» написан в типичном LinkedIn-стиле: «Я исследую пересечения технологий, мышления и практики», «Автор · Инженер · Исследователь» — строго против моего же голоса;
• в публичной копии сайта засветилось имя поискового движка («Pagefind»), хотя пользователю это знать не нужно.

Всё, кроме текста «Обо мне», починили в этом же сеансе. Текст — это переписывание личного голоса, я сделал черновик, но коммитить не стал.

Полировка деталей 🎨 #

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

Команда /harden («закалка») закрыла прямой пробел: на месте английской заглушки темы «typo? Click here» теперь нормальная страница 404 на русском с тремя осмысленными путями. Локализовал раздел тегов: хлебные крошки теперь говорят «Главная / Теги», а не «Tags». Расширил поддержку настройки «уменьшить движение» в операционной системе — теперь обнуляются все плавные переходы, не только прокрутка. Защитился от очень длинных заголовков (если в название поста попадёт длинная ссылка без пробелов, сетка не поедет).

Команда /polish («полировка») добавила состояния «при наведении» и «при фокусе с клавиатуры» там, где их не было: теги статьи, ссылки на соцсети в шапке главной, навигация пагинации, ссылки между постами, кнопка копирования кода. Каждая ссылка теперь визуально откликается на наведение через смену цвета — без сдвига, без тени, по принципу «никакой фальшивой глубины» из моей же DESIGN.md.

Команда /typeset (типографика) — самая «невидимая» работа. Включил кернинг (профессиональная регулировка расстояний между парами букв) и лигатуры (где две буквы соединяются в один знак — fi, fl). Включил табличные цифры на датах в ленте: цифры теперь одной ширины и в столбце выстраиваются штамп-в-штамп. Добавил мягкие переносы русских слов внутри статьи (без них длинные слова рвали строку абзаца на узкой колонке). Тонко уплотнил трекинг (межбуквенный интервал) на крупных заголовках 28-44 пикселя — Literata в больших размерах без лёгкого негативного трекинга «дребезжит» как кубики, с ним читается как один жест.

Каждая из тройки — 30-60 минут работы. Вместе они подняли качество с «работает» до «приятно читать».

Что я понял про инструмент #

Импеккейбл работает с локальными файлами, не с задеплоенным сайтом. Команды читают исходники в репозитории, рендеренный HTML после локальной сборки Hugo, и оба дизайн-документа. Прода нет ни в одной команде, кроме /live (интерактивный режим в браузере), которую я не использовал. То есть весь дизайн-цикл идёт у меня на ноутбуке, и выкладка в боевой репозиторий — финальный шаг, не источник истины.

AI хорошо ловит противоречия в собственной работе, если ему дать независимое ревью. Изоляция в /critique нужна не для эстетики процесса. Самопроверка у языковой модели страдает тем же эффектом подтверждения собственной правоты, что и у человека: ты видишь в своей работе то, что её обосновывает, и не видишь того, что её опровергает. Отдельный AI-агент в новой сессии, без моих рассуждений в его контексте, читал DESIGN.md как просто один из файлов и тут же поймал расхождение с шаблонами.

Анти-референсы выстреливают сильнее, чем референсы. «Не как Habr» — конкретный отказ, проверяемый автоматически. «Как Stripe» — растяжимое, можно подогнать любой результат. PRODUCT.md заставляет выписать четыре-пять анти-референсов, и каждое решение проверяется против них.

Метрики важнее ощущений. /audit дал 11 из 20. Это конкретное число. После правок — 19. Я знаю, на сколько лучше. Бессчётный «прогресс» — самообман: правишь, правишь, чувствуешь, что лучше. С оценкой видно, что иногда нет.

Убывающая отдача наступает быстро. После пяти проходов половина команд impeccable стали неуместными для моего блога. /animate, /delight, /bolder, /overdrive — прямо конфликтуют с принципом «без подкупа» из PRODUCT.md. /quieter, /distill — сайт уже плоский и сдержанный, дальше пустая страница. /colorize — палитра закрыта на 13 цветах. /optimize — Hugo уже выжат до предела.

Это знак, что инструмент сделал работу. Дальше — пиши посты, не правь дизайн.

Где AI ошибся, а где я #

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

Первый случай. Один сборочный билд занял 9 минут вместо обычных 40-50 секунд. Я уверенно сказал: причина — что я только что добавил в подвал отметку реального времени сборки. Каждая страница теперь содержит уникальный текст в подвале, значит, утилита синхронизации (rsync) с проверкой по контрольной сумме перезаливает все 227 страниц целиком. Технически красивое объяснение, инженерно стройное. И неверное.

Следующий билд с той же отметкой времени занял 40 секунд. То есть 9-минутный билд был случайным выбросом — холодный старт исполнителя, сетевой сбой, что-то сторонне. Я экстраполировал из одной точки и готов был «починить» проблему, которой нет.

Второй случай. Я случайно удалил пустой файл content/posts/.md (артефакт от прошлой попытки автоматического создания поста с битым именем) после того, как назвал его «пустой стуб». Не прочитал содержимое перед удалением. Файл был не пустой — 101 байт. После удаления выяснилось, что в нём всё-таки лежал какой-то фронтматтер (служебный заголовок поста с метаданными), которого я не увидел до действия.

Оба случая зашиты в персональную память:

• Перед удалением читать каждый файл. Не отслеживается ли git — не значит «можно выкинуть».
• Прежде чем уверенно объявлять причину явления — собрать минимум две сравнимых точки. Один выброс ≠ закономерность.

Особенно полезно для вопросов производительности, где «фикс несуществующей проблемы» — это напрасные телодвижения и потеря доверия к собственным выводам.

Когда импеккейбл не нужен #

• На бренде, который требует «как у всех»: внутренний инструмент, служебная панель, прототип без идентичности.
• Когда нет 30-60 минут на интервью /teach и сборку DESIGN.md. Без фундамента остальные команды дают ответы вообще, не для тебя.
• На короткой одностраничной странице — обычная ручная работа быстрее.
• Когда дизайн уже отлажен и работает — повторное прохождение часто стоит дороже того, что находит.

Конкретные числа #

Итог #

Импеккейбл не делает дизайн за тебя. Он даёт инструмент, через который вы вместе с AI доводите дизайн до состояния, в котором вы оба перестаёте делать стандартные ошибки. Аудиторская часть (/audit, /critique) ловит сразу видимое. Доводочная часть (/harden, /polish, /typeset) делает то, что в одиночку лень довести до конца.

Стоимость: один вечер плюс умение зафиксировать собственный голос в PRODUCT.md и DESIGN.md. Срок отдачи: пока продолжаешь редактировать сайт. Каждое следующее обращение к AI («поправь шапку», «добавь страницу архива», «перепиши блок») идёт на фоне этих двух файлов, и шансы получить очередной AI-look уменьшаются.

Скрытая ценность инструмента в том, что он заставляет писать честно о собственном проекте. Анти-референсы зашиты в PRODUCT.md и зачитываются перед каждой правкой. Это ровно та дисциплина, которую я никогда не наводил руками.

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

Локальная модель снимает все три. Подписка обнуляется, latency определяется только железом, а код никуда не уходит за пределы ноутбука. Цена вопроса — модель меньше топовых облачных, чуть больше суеты с настройкой и постоянное место на диске.

В этом посте разбираемся с Qwen3-Coder-Next-MLX-4bit: квантованной версией кодовой модели от Alibaba, оптимизированной под Apple Silicon. Что это такое, как поставить, как подключить к Codex CLI и когда честно лучше остаться в облаке.

Что это такое и почему именно эта сборка #

Qwen3-Coder — линейка моделей от Alibaba, специально натренированных на коде. Базовая модель — около 8 млрд параметров. Это не GPT-4-class, но для большинства повседневных задач (понять код, написать функцию, сгенерить тесты, отрефакторить) — более чем достаточно.

MLX — относительно новый ML-фреймворк от Apple. Создан с нуля под Apple Silicon: использует unified memory (CPU и GPU делят одну RAM), zero-copy между ними, lazy evaluation. Для пользователя это значит, что модель работает заметно быстрее, чем тот же файл, запущенный через PyTorch с MPS-бэкендом.

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

Важно не путать форматы: MLX хранит модели в собственном формате (.safetensors обёрнутый в MLX-структуру), а не в .gguf (это формат llama.cpp). При выборе модели в LM Studio это нужно учитывать: «MLX»-вариант и «GGUF»-вариант — это разные файлы для разных движков, не одно и то же.

Для Qwen3-Coder-Next-MLX-4bit характеристики такие:

• Параметры: ~8B (тот же что и у не-квантованной версии).
• Формат: MLX (.safetensors).
• Размер на диске: ~5.5 GB.
• Контекст: 32 768 токенов.
• Минимум RAM: 16 GB (модель + накладные).
• Комфортный минимум: 24-32 GB (если ещё нужна работа с IDE и браузером параллельно).

Установка через LM Studio 📦 #

LM Studio — desktop-приложение для работы с локальными LLM. Поддерживает и MLX, и GGUF, плюс встроенный OpenAI-совместимый сервер на localhost.

Шаги:

1. Поставить LM Studio с официального сайта.
2. Открыть Discover (вкладка с моделями).
3. В фильтре указать «MLX» (важно — без этого подсунет GGUF-вариант).
4. Найти Qwen3-Coder-Next или подобную сборку.
5. Скачать (~5.5 GB).
6. Загрузить в My Models, потом Load.

После загрузки в правом sidebar’е будут параметры:

• Context length: 8 192 для большинства задач хватает; 32 768 если нужен большой prompt с длинным куском кода.
• GPU offload: «Max» — отдать всё на Metal-ядра.
• Threads: оставить дефолт (LM Studio сам подберёт).

LM Studio автоматически поднимет OpenAI-compatible endpoint на http://localhost:1234/v1/. Дальше с моделью работают любые клиенты, понимающие OpenAI API.

Подключение к Codex CLI через MCP 🔌 #

Если вы используете Codex CLI (агентский интерфейс на базе LLM), к нему можно подключить локальную модель через MCP-сервер для LM Studio.

В ~/.codex/config.toml:

[[mcpServers]]
name = "lmstudio"
command = "npx"
args = ["-y", "@mlaboard/lmstudio-mcp"]

После перезапуска Codex увидит локальную модель как один из доступных провайдеров. Smoke-тест: попросить простую задачу типа «напиши функцию Фибоначчи на Python» — должен ответить за 0.5–1 секунду.

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

Замеры на M2 Max 📊 #

На моём железе (M2 Max, 32 GB unified memory) получились такие цифры:

Это медленнее облачного GPT-4 (там 50-80 ток/с в среднем), но быстрее, чем кажется по первому впечатлению. Для итеративной работы (написал → попросил → поправил руками → попросил снова) разница в latency почти неощутима, потому что много времени всё равно уходит на чтение и редактирование результата.

Если поднять контекст до 32k и закинуть в prompt большой кусок кода (типа целого файла на 1000 строк), скорость падает примерно вдвое: 9-12 ток/с при first-token latency около 2 секунд. Ничего страшного, но уже заметно.

Сравнение с облаком #

Когда честно лучше облако #

Локальная модель не серебряная пуля. Есть классы задач, где она объективно проигрывает:

Большой контекст. 128k+ контекст-окно у топовых облачных моделей позволяет закидывать в prompt целые модули кода. У 32k Qwen банально не хватит места.

Сложные многошаговые задачи. Спроектировать архитектуру модуля, отрефакторить взаимосвязанные классы, написать миграцию с несколькими шагами — здесь топовые модели заметно качественнее.

Мультимодальность. Анализ скриншотов UI, генерация по чертежу, чтение PDF — Qwen3-Coder-Next специализирован под код, картинки не обрабатывает.

Редкие языки/фреймворки. На массовом Python, JS, Go качество приемлемое. На нишевых вещах (Elixir, Crystal, какой-нибудь специфичный DSL) облачная модель тренировалась на большем корпусе и даёт более уверенные ответы.

Когда локалка точно полезна #

И обратная сторона:

Чувствительные репозитории. Закрытый клиентский код, медицинские/финансовые данные, что-то под NDA — локально единственный вариант, который не нарушает соглашений.

Работа в дороге без сети. Поезд, самолёт, кафе с глюкавым WiFi — локальная модель отвечает одинаково ровно.

Высокочастотные задачи. Если модель используется десятки раз в час (autocomplete, объяснение fragment’ов кода в IDE), даже маленькая абонентская плата быстро накапливается. Локалка после железа бесплатна.

Эксперименты с агентами. Запускать тестовый цикл, где LLM крутится в фоне без лимитов, проще на собственном железе. Лимиты по rate limit / стоимости в облаке быстро становятся узким местом.

Размышления после месяца использования #

Для меня сложилась гибридная схема: 70% повседневной работы (объяснить функцию, написать regex, сгенерить unit-тест, набросать структуру модуля) — Qwen локально. Остальные 30% (сложная архитектура, разбор большого PR, работа со скриншотом) — облако.

Это не «локальная победила облачную». Это разделение по типу задач: где важна privacy и скорость отклика — локально, где важно качество и контекст — облако.

Установка занимает максимум полчаса (LM Studio + скачать файл + подключить через MCP). Дисковое пространство в 5.5 GB не критично даже на 256 GB Mac. Если вы давно думали попробовать локальные LLM, но откладывали из-за «сложно настроить» — Qwen3-Coder-Next-MLX-4bit как раз тот случай, когда барьер входа честно низкий. ✅

Источники #

• Документация MLX: github.com/ml-explore/mlx
• LM Studio: lmstudio.ai
• Qwen models на HuggingFace: huggingface.co/Qwen
• Model Context Protocol: modelcontextprotocol.io

8 апреля 2026 вышел Hugo v0.160.1 — патч-релиз, который чинит несколько неприятных panic-сценариев из v0.160.0 (вышедшего четырьмя днями раньше). Вместе они формируют один логический шаг для проектов: 0.160.0 даёт две новые возможности, 0.160.1 закрывает баги, всплывшие сразу после релиза.

Если коротко: одну фичу (CSS-переменные в css.Build) ждали давно те, кто строит CSS через Hugo Pipes; остальные изменения — улучшения для авторов render hooks и фиксы редких краевых случаев. Никаких breaking changes, никаких депрекейтов.

Но фиксы в 0.160.1 — это именно тот случай, когда «пропустил минор и поймал panic в проде». Поэтому пробежать стоит.

Главное за один взгляд #

v0.160.0 (4 апреля 2026) — фичевый минор:

• CSS-переменные можно инжектить в стили при сборке через css.Build (например, прокинуть значения из конфига).
• Метод .Position теперь доступен на всех render hooks и стал точнее.
• Несколько прицельных багфиксов (Position, escape ampersand’ов в link URL, stray quotes в partial-декораторе script-контекста).

v0.160.1 (8 апреля 2026) — patch:

• Fix: panic при passthrough-элементах в заголовках.
• Fix: panic при редактировании legacy template names, которые одновременно валидные пути в новой схеме.
• Fix: RenderShortcodes утекал context markers при отступах.
• Fix: standalone RenderShortcodes теперь снимает nested page context markers.
• Fix: автосоздание root sections в мультиязычных сайтах.
• Чистка: cascade._target → cascade.target (в тестах; deprecation осталось в коде).
• README: чинены ссылки.

Дальше — что это значит на практике.

CSS-переменные в css.Build 🎨 #

Это главная фича релиза. Если вы используете Hugo Pipes для сборки CSS (а не просто статически копируете файлы из static/), теперь можно прокидывать значения из Hugo-контекста прямо в CSS на этапе сборки.

Раньше для подобного приходилось городить пайплайн через переменные окружения, sed-замены или генерировать .css через Hugo template (что ломает синтаксис LSP-плагинов).

Теперь это выглядит ближе к декларативно:

{{ $opts := dict
    "vars" (dict
        "primary"   site.Params.brand.primary
        "max-width" "1200px"
    )
}}
{{ $css := resources.Get "css/main.css" | css.Build $opts }}
<link rel="stylesheet" href="{{ $css.RelPermalink }}">

В CSS можно ссылаться на эти переменные через специальный hook (@import 'hugo:vars' или подобный, точный синтаксис — в документации css.Build).

Когда полезно: сайтам с темой, где accent-цвет задаётся в hugo.toml и должен применяться к компонентам через CSS переменные; сборкам, где max-width или breakpoint-значения управляются из конфига; multi-tenant билдам.

Нашему блогу это не нужно — у нас ровно один theme и палитра жёстко зафиксирована в :root блоке. Но если вы строите тему-конструктор или multi-сайт — стоит изучить.

Точная позиция в render hooks 📍 #

Вторая фича — расширение .Position на все render hooks (image, link, heading, code-block) с одновременным улучшением точности.

.Position возвращает позицию исходного Markdown-токена в файле. Для отладки и понимания «откуда пришла эта ссылка» — критично.

Сценарий использования:

{{/* render-link.html */}}
{{ $url := .Destination | safeURL }}
{{ if not (urls.Parse $url).IsAbs }}
  {{/* Внутренняя ссылка — проверяем что target существует */}}
  {{ if not (.Page.GetPage (string $url)) }}
    {{ warnf "Битая внутренняя ссылка %q в %s" $url .Position }}
  {{ end }}
{{ end }}
<a href="{{ $url }}">{{ .Text | safeHTML }}</a>

В warning’е теперь будет точное файл:строка исходника поста, а не нечто приблизительное. Проще ловить регрессии после рефакторингов контента.

Багфиксы 0.160.1 🔧 #

Пять патчей, каждый закрывает свой панический сценарий или утечку.

Panic при passthrough в заголовках #

Hugo Goldmark поддерживает passthrough — режим, когда определённые символьные блоки (например, LaTeX-формулы $...$) пропускаются как есть и обрабатываются на клиенте через MathJax/KaTeX.

В 0.160.0 если passthrough-элемент попадал прямо внутрь заголовка (например, ## Формула $E=mc^2$), Hugo падал с panic при сборке. 0.160.1 чинит этот случай: теперь рендерится корректный HTML без падения.

Если вы пишете научный/математический контент с inline-формулами в заголовках — обновление обязательно.

Panic на legacy template names #

Если в проекте есть старая схема именования шаблонов (_default/single.html.html и подобные legacy-варианты), которая одновременно является валидным путём в новой схеме именования Hugo, при редактировании файла Hugo мог падать. 0.160.1 разводит эти кейсы.

RenderShortcodes и context markers #

RenderShortcodes — функция для обработки всех шорткодов внутри переданного контента. Она использует внутренние «context markers» для отслеживания вложенности.

В 0.160.0 эти маркеры могли:

1. Утекать в финальный HTML, если контент с шорткодами был с отступами (например, внутри списка или blockquote).
2. Не очищаться при standalone-вызове .RenderShortcodes через .Page.Content после nested-рендеринга.

Оба случая дают видимый «мусор» в выводе (артефакты вида __hugo_ctx0__ и подобные). 0.160.1 чистит маркеры в обеих ситуациях.

Если вы используете шорткоды внутри списков или blockquote’ов — обновляйтесь.

Auto-creation root sections в мультиязычных сайтах #

В мультиязычных сайтах Hugo автоматически создаёт «виртуальные» root section страницы для каждого языка. В 0.160.0 эта логика могла давать сбой (root section не создавалась, или создавалась только для default-языка), что ломало навигацию по неосновным языкам.

Если у вас один язык — пункт мимо. Если несколько — обновление лечит.

cascade.target вместо cascade._target #

Мелкий, но симптоматичный пункт: ключ _target в cascade-конфигурации переименован в target (без подчёркивания). Старая форма помечена как deprecated в коде, всё ещё работает.

Если у вас есть cascade-блоки в front matter:

cascade:
  - _target:                 # ← старая форма
      kind: page
    params:
      foo: bar

Замените на:

cascade:
  - target:                  # ← новая форма
      kind: page
    params:
      foo: bar

Точечная правка, занимает минуту. Запас времени до полного удаления старой формы — обычно несколько релизов.

Чек-лист обновления ✅ #

1. Поднять версию Hugo до 0.160.1 в Dockerfile / CI-образе или локальном binary. Если вы уже на v0.161.0+ — пропускаем, это пройденная развилка.

2. Если используете passthrough для математики или специальных Markdown-блоков, и они появляются в заголовках — обновление закрывает panic. Без обновления заголовки-формулы могут быть рассадником сюрпризов.

3. Если используете cascade._target в front matter, переименовать в cascade.target:

   grep -rln '_target:' content/ | xargs sed -i '' 's/_target:/target:/g'

   copy

4. Если строите CSS через Hugo Pipes, посмотреть документацию css.Build с CSS variables — возможно, сможете заменить sed-замены или env-обвязку на встроенный механизм.

5. Если пишете кастомные render hooks, проверить, можно ли использовать .Position для лучшей диагностики битых ссылок/изображений в постах.

6. Стандартный прогон:

   hugo --minify --gc

   copy

   Сравнить количество warning’ов до и после. Если новых не появилось — мигрировано чисто.

Итог 🧠 #

Hugo 0.160.x — это не громкий feature drop, а методичное улучшение инфраструктуры: новый удобный механизм для CSS-сборки, более точная диагностика в render hooks, набор фиксов под краевые случаи (passthrough в заголовках, RenderShortcodes с отступами, multilingual sections).

Главная причина обновляться — патч 0.160.1 закрывает несколько panic-сценариев. Если вас они никогда не цепляли, повезло; но «не цепляли» — это не «не зацепят». На статичных сайтах panic при сборке проявляется как сломанный CI и красный билд, что рассинхронизирует прод и репозиторий.

Если уже сидите на 0.161.0 (как мой блог сейчас), всё это вы уже получили транзитом. Если на 0.159 или раньше — есть смысл прыгать сразу на самую свежую stable, минуя промежуточные.

Источники #

• Релиз 0.160.0: gohugoio/hugo v0.160.0
• Релиз 0.160.1: gohugoio/hugo v0.160.1
• Документация css.Build: gohugo.io/functions/css/build/
• Документация passthrough: gohugo.io/configuration/markup/#passthrough
• Документация cascade: gohugo.io/content-management/front-matter/#cascade

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

Исходный контекст #

На старте у нас уже был рабочий блог на Hugo с темой typo, CI/CD через Forgejo Actions и поиском на Pagefind.

Дальше в рамках одной непрерывной сессии мы сделали:

1. Написали и опубликовали новый пост про Hugo 0.157.0.
2. Поймали проблему с невидимостью поста из-за времени публикации.
3. Добавили правила в AGENTS.md, чтобы больше не ловить future-ошибки.
4. Настроили и протестировали подсветку кода (в итоге перешли на dracula).
5. Привели к dracula цвета выдачи поиска.
6. Исправили некорректные заголовки в Pagefind (вместо названия поста показывалось имя сайта).
7. Структурировали README.md и AGENTS.md как рабочую документацию процесса.

То есть это уже не «написать один пост», а полноценный операционный цикл контентного проекта.

Как выглядел рабочий цикл с Codex CLI #

Самый полезный паттерн из этой сессии:

1. Чёткая постановка задачи #

Каждый шаг формулировался как конкретный результат:

• «Напиши новую статью про релиз».
• «Почему статья не видна? Исправь».
• «Сделай правило, чтобы проблема не повторялась».
• «Сделай тему поиска в dracula».

Чем конкретнее цель, тем меньше «творческого шума» и выше скорость прохождения задачи.

2. Локальная диагностика перед правкой #

Перед изменением файлов Codex проходил короткий аудит:

• чтение текущих шаблонов/конфигов;
• проверка фактического рендера;
• сверка с реальным поведением сайта;
• поиск причинно-следственной связи, а не симптомов.

Пример мышления: если цвета не применились, сначала проверить порядок подключения CSS, а не сразу «добавить ещё !important».

3. Точечная правка + обязательная валидация #

После каждого изменения шёл одинаковый технический минимум:

hugo list future
hugo --minify
git status --short

Это сильно снижает вероятность того, что в main улетит «логически верно, но технически сыро».

4. Фиксация в git маленькими коммитами #

Вместо одного гигантского коммита по итогам сессии:

• каждый смысловой шаг фиксировался отдельно;
• сообщения коммитов были предметными;
• любой этап можно быстро отследить и откатить локально при необходимости.

Для блога это особенно удобно: контент, стили, шаблоны и правила не смешиваются в «одно большое изменение».

Реальные проблемы, которые мы поймали и закрыли #

Проблема 1: пост «не видно на сайте» #

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

Причина: date в фронтматтере оказался в будущем относительно московского времени на момент деплоя.

Решение:

• сдвиг даты в прошлое;
• проверка hugo list future;
• фиксация правила в AGENTS.md: новые посты ставить на 5-10 минут в прошлое и всегда проверять future-список перед коммитом.

Ключевой эффект: проблема устранена один раз на уровне процесса, а не «подкручена вручную» только для одного поста.

Проблема 2: подсветка кода «всё одним цветом» #

Симптом: HTML уже содержит chroma-классы, но визуально код почти монохромный.

Причина: базовый файл подсветки темы был близок к bw-палитре.

Решение:

1. Включили работу через CSS-классы (noClasses = false).
2. Добавили собственный assets/css/syntax-highlighting.css.
3. Сначала проверили monokai, затем переключили на dracula.

Итог: читаемая цветная подсветка с контролируемой темой в репозитории.

Проблема 3: выдача поиска не в стиле сайта #

Симптом: поле и результаты поиска выпадали из общей цветовой схемы.

Причина: стили Pagefind подключались после custom.css, и часть переопределений не применялась.

Решение:

• сначала добавили CSS-переменные Pagefind в custom.css;
• затем сделали гарантированное переопределение после pagefind-ui.css прямо в шаблоне layouts/search/single.html.

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

Проблема 4: у результатов поиска заголовок «Evgeny Kushnarenko» #

Симптом: каждая найденная строка в выдаче имела одинаковый title (имя сайта).

Причина: Pagefind подхватывал h1 из шапки страницы.

Решение:

• вынесли локальный layouts/partials/header.html и пометили шапку data-pagefind-ignore;
• добавили data-pagefind-meta="title" на h1 поста в layouts/_default/single.html.

Итог: выдача начала показывать реальные заголовки материалов.

Что это даёт в ежедневной работе #

После такого цикла становится заметно:

1. Время между идеей и публикацией сокращается.
2. Ошибки переходят из категории «случайные и повторяющиеся» в «редкие и диагностируемые».
3. Репозиторий становится документацией процесса, а не просто папкой с контентом.
4. Снижается когнитивная нагрузка на автора: меньше ручной рутины, больше фокуса на смысле.

На длинной дистанции это важнее, чем «сэкономить 5 минут на одной статье».

Что точно не нужно автоматизировать #

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

Тональность и личный голос. Codex может собрать структурный черновик, но финальный тон — авторская вещь. Если читатель чувствует «это писал не человек», доверие к материалу падает мгновенно. Заменять автора на этом этапе — значит потерять то, ради чего блог вообще существует.

Спорные технические решения. Когда в дизайне есть выбор между двумя одинаково обоснованными подходами (положить компонент в layouts/_default/ или в layouts/posts/, использовать ли Hugo Pipes для CSS или статичную копию), Codex даст «средний разумный вариант». Это не плохо, но это не вы. На длинной дистанции архитектурные решения, принятые «средним способом», накапливают трение, которое в одиночку не разглядеть.

Решения про контент. Что писать, что не писать, какие посты убирать, какие оставлять, как переименовать раздел — это редакционные решения. Они должны проходить через автора. Инструмент здесь полезен только как «помощник по реализации», когда решение уже принято.

Размышления после сессии #

Главный вывод после нескольких часов работы в таком режиме: ценность автоматизации не в скорости, а в предсказуемости. До регулярной работы с Codex CLI каждая публикация поста была чуть-чуть разной: где-то забыл подвинуть дату, где-то не проверил подсветку, где-то не закоммитил отдельно стилевую правку. После — процесс стал ровным, что освободило внимание для содержания.

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

Практический шаблон автоматизации под Hugo #

Если хотите повторить подход, можно взять такой минимум:

1. Для каждой задачи: цель в 1-2 предложениях.
2. Перед правкой: чтение текущего состояния (rg, sed, шаблоны, конфиги).
3. После правки: hugo list future + hugo --minify.
4. Фиксация: один смысл = один коммит.
5. Публикация: git push сразу после проверки.
6. Если баг повторяемый: правило в AGENTS.md, а не «устная договорённость».

Набор команд, который реально работал в этой сессии #

# Проверки контента и даты
hugo list future
hugo --minify

# Диагностика
rg -n "pagefind|highlight|chroma" -S .
sed -n '1,220p' layouts/search/single.html

# Публикация
git add <файлы>
git commit -m "Осмысленный коммит по одной задаче"
git push

Никакой экзотики: сила не в сложных командах, а в дисциплине последовательности.

Практические выводы #

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

1. Чёткая постановка задач.
2. Наблюдаемость и проверки после каждого шага.
3. Маленькие коммиты с понятной ответственностью.
4. Фиксация правил в репозитории.

Тогда Codex становится не «генератором текста», а операционным партнёром, который помогает держать качество и темп публикаций одновременно. ✅

В этой статье разберём, что именно изменилось, где может быть практический эффект, и как пройти обновление без сюрпризов. 🚀

Кому это релевантно сразу: командам, ведущим контент через Hugo Modules; авторам тем, использующим внешние API в шаблонах; всем, у кого билд иногда «висит» из-за медленного источника. Кому можно отложить: одиночный блог без модулей и без внешних запросов получит апгрейд почти прозрачно — обновляйтесь как часть обычной уборки технического долга.

Почему релиз 0.157.0 важен #

Главная идея релиза: Hugo становится устойчивее в «боевых» сценариях, где проект не ограничивается одной папкой content и парой шаблонов.

Ключевые точки:

1. Page.GitInfo теперь полноценно поддерживает контент из Git-модулей (через mounts).
2. В resources.GetRemote появился перезапросный timeout, который можно задавать прямо в шаблоне.
3. Добавлена частичная поддержка AVIF/HEIF/HEIC (пока только метаданные).
4. Улучшены дефолты обработки WebP.
5. Исправлены ошибки, влияющие на меню, section pages и стабильность сборок.

Если коротко: меньше «магии», больше управляемости. 🎯

GitInfo для Hugo Modules: что реально изменилось 🧩 #

Проблема до 0.157.0 #

Если вы подключали контент через module.imports.mounts (например, общий набор статей или документацию из отдельного репозитория), GitInfo мог работать неполно или нестабильно для таких страниц.

Это мешало:

• корректно выводить «последнее обновление» для импортированного контента;
• строить списки изменений по коммитам;
• делать единый шаблон мета-блока для локального и модульного контента.

Что даёт 0.157.0 #

В релизе добавлена и доработана поддержка Page.GitInfo для контента из Git-модулей. То есть страницы, примонтированные из модулей, теперь могут корректно отдавать данные о коммите: автора, дату, хеш, subject и т.д.

Это особенно полезно для:

• docs-порталов из нескольких репозиториев;
• мультисайтов, где контентные команды работают независимо;
• архитектуры «ядро темы + контент как модуль».

Практический шаблон #

{{ with .GitInfo }}
  <p class="meta">
    Обновлено: {{ .AuthorDate.Format "2006-01-02 15:04" }} ·
    Автор: {{ .AuthorName }} ·
    Коммит: <code>{{ .AbbreviatedHash }}</code>
  </p>
{{ end }}

Важный operational-момент: в CI должен быть не shallow clone, иначе Git-данные могут быть неточными.

resources.GetRemote получил timeout: контроль вместо зависаний ⏱️ #

Что болело раньше #

Когда вы тянете внешние данные (RSS/JSON/изображения), один медленный источник мог подвесить сборку. На небольшом сайте это раздражает, а на большом CI-пайплайне превращается в регулярную проблему.

Что появилось в 0.157.0 #

Теперь в resources.GetRemote есть опция timeout (строка длительности, например "10s"). Её можно задавать для каждого запроса отдельно.

{{ $url := "https://example.org/feed.rss" }}
{{ $opts := dict "timeout" "10s" }}

{{ with try (resources.GetRemote $url $opts) }}
  {{ with .Err }}
    {{ warnf "Не удалось получить feed %q: %s" $url . }}
  {{ else with .Value }}
    {{ $data := . | transform.Unmarshal }}
    {{/* дальнейшая работа с данными */}}
    {{ $data }}
  {{ else }}
    {{ warnf "Ресурс %q не найден" $url }}
  {{ end }}
{{ end }}

Практический эффект:

• можно задавать строгий timeout для нестабильных источников;
• сборка перестаёт «висеть» из-за одного внешнего API;
• проще разделить критичные и некритичные источники (где-то errorf, где-то warnf).

Изображения: что важно понимать про AVIF/HEIF/HEIC и WebP #

В 0.157.0 добавили частичную поддержку AVIF/HEIF/HEIC: на текущем этапе это поддержка метаданных, а не полноценный новый pipeline обработки.

Что это значит на практике:

• Hugo лучше распознаёт такие файлы;
• можно безопаснее работать с метаданными;
• но не стоит ожидать полной parity с привычной обработкой JPEG/PNG/WebP прямо «из коробки».

Также в релизе скорректированы настройки обработки WebP. Если вы строите агрессивный image pipeline, стоит прогнать визуальные regression-проверки на ключевых страницах.

Дополнительные исправления, которые могут «всплыть» в проде #

В релизе есть не самые заметные, но полезные улучшения:

• фикс menu pageRef в multidimensional-настройках;
• корректировки в логике section pages;
• улучшенные сообщения об ошибках модулей (go mod download);
• пропуск пустых taxonomy-ключей/значений в конфиге.

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

Сценарий, который раньше ломался: контент в нескольких модулях #

Чтобы понять ценность изменений вокруг GitInfo и section pages, представьте типичную mid-size-конфигурацию: основной репозиторий с темой, плюс два модуля с контентом — docs/ и blog/, каждый в своём Git-репо. Их подмонтировали в основной сайт через module.imports.mounts.

До 0.157.0 в этой конфигурации возникали мелкие неприятности: даты в footer’е импортированных постов отдавали поведение «default-на-momento-сборки» вместо «коммит-автор-дата»; menu иногда теряла pageRef для импортированных страниц при определённых вариантах языковой настройки; ошибки go mod download приходили без контекста, и приходилось вручную перебирать модули, чтобы найти проблемный.

В 0.157.0 каждый из этих краевых случаев починен. Если вы держите такой setup, после обновления заметна разница: меньше ручных правок шаблонов под «странности» modular-контента, прозрачнее ошибки при сетевых проблемах с одним из модулей.

Когда обновляться можно отложить #

Если у вас одиночный сайт без модулей, без resources.GetRemote в шаблонах, без AVIF/HEIF в pipeline и без активных кастомных меню с pageRef — этот релиз вас почти не коснётся. Обновитесь в плановом окне (вместе с пересборкой Docker-образа, например), но срочности нет.

Срочно обновляться стоит, если: используете resources.GetRemote и хотя бы раз попадали на медленный source; ведёте мультимодульный контент; пишете кастомные шаблоны с .GitInfo для импортированных страниц.

Чек-лист обновления до Hugo 0.157.0 ✅ #

1. Обновите бинарь/образ Hugo до 0.157.0.
2. Если используете GitInfo, проверьте enableGitInfo: true в конфигурации.
3. Убедитесь, что CI делает глубокий клон репозитория (fetch-depth: 0 в GitHub Actions или эквивалент).
4. Для всех resources.GetRemote проставьте осмысленный timeout и единообразный try-обработчик.
5. Прогоните smoke-тесты меню, section pages и страниц с импортированным модульным контентом.
6. Проверьте image pipeline (особенно WebP) на визуальные отличия.
7. Сравните длительность сборки до/после обновления.

Мини-план миграции на 30 минут #

Если проект уже в хорошем состоянии, переход можно сделать быстро:

1. 10 минут: поднять версию и собрать сайт локально без warning/error.
2. 10 минут: проверить шаблоны с .GitInfo и блоки с resources.GetRemote.
3. 10 минут: прогнать CI и открыть несколько критичных страниц руками.

Обычно этого достаточно, чтобы перейти на релиз без ночных откатов.

Итог 🧠 #

Hugo 0.157.0 не про «громкие фичи ради фич», а про зрелость платформы: лучшее поведение в модульных проектах, более предсказуемая работа с внешними запросами и аккуратные улучшения инфраструктурного уровня.

Если у вас контент разбит на модули, а сборка зависит от внешних данных, обновление стоит делать в ближайшем цикле.

Источники #

• Официальный релиз: gohugoio/hugo v0.157.0
• Документация Page.GitInfo: gohugo.io/methods/page/gitinfo
• Документация resources.GetRemote: gohugo.io/functions/resources/getremote

18 февраля 2026 вышел Hugo v0.156.0. Если поверхностно прочитать changelog, это очередной минор: пара новых методов, несколько депрекейтов, опция конфига. Звучит как «обновлюсь когда руки дойдут».

Но именно из таких минорных релизов и копится технический долг. Депрекейт API сегодня — это broken-build через год, когда вы решите перейти на крупную версию. Минута, потраченная сейчас, чтобы привести шаблоны в соответствие, экономит вечер разбирательств позже.

В этом посте — что реально изменилось, что заметно в шаблонах, и короткий чек-лист, который проходится за 30 минут.

Главное за один взгляд #

Релиз 0.156.0 содержит шесть значимых изменений:

1. Добавлены новые API: hugo.Data и hugo.Sites.
2. Устаревшими объявлены site.Data и site.Sites (пока работают для обратной совместимости).
3. В контекст link render hooks добавлены методы IsBlock и Ordinal.
4. Добавлен новый метод site.Home.Translations; site.Home.AllTranslations помечен как deprecated.
5. Появилась опция конфигурации disableSetLocale.
6. Помечен как deprecated путь _vendor/github.com/gohugoio/locales.

Дальше — по каждому пункту, что это значит на практике и что менять.

Переезд site.Data → hugo.Data 🧱 #

Самое заметное смысловое изменение — переезд глобальных коллекций данных и сайтов с пространства имён site.* на hugo.*.

Сейчас в шаблонах вы могли писать:

{{ range site.Data.authors }}
  ...
{{ end }}

После 0.156 рекомендуется:

{{ range hugo.Data.authors }}
  ...
{{ end }}

Версия со старым site.Data пока работает — ради совместимости. Но в release notes явно сказано: новые методы предпочтительнее, старые помечены как deprecated. Когда придёт следующая major-версия (Hugo любит чистить депрекейты), site.Data могут совсем убрать.

Аналогичная история с site.Sites → hugo.Sites. Используется реже, в основном на мультисайтах с подмножеством общих ресурсов.

Что делать: массовый поиск-замена в шаблонах темы и проекта:

grep -rn 'site\.Data\|site\.Sites' layouts/ themes/*/layouts/ 2>/dev/null

Если хитов нет — вы никак не зависите от этого изменения. Если есть — заменить на hugo.Data и hugo.Sites.

Render hooks: IsBlock и Ordinal 🔗 #

Если у вас есть кастомные link render hooks (файл layouts/_default/_markup/render-link.html или подобный), в их контексте теперь доступны два новых метода:

• IsBlock — true, если ссылка стоит как самостоятельный блок (например, <p>[link](url)</p> где это единственный элемент абзаца), а не inline внутри текста.
• Ordinal — порядковый номер ссылки в документе, начиная с 0.

Зачем это нужно:

{{/* render-link.html */}}
{{ if .IsBlock }}
  {{/* Самостоятельная ссылка — рендерим как карточку */}}
  <a class="link-card" href="{{ .Destination | safeURL }}">
    <span class="link-card__num">№{{ add .Ordinal 1 }}</span>
    <span class="link-card__text">{{ .Text | safeHTML }}</span>
  </a>
{{ else }}
  {{/* Inline-ссылка — обычный <a> */}}
  <a href="{{ .Destination | safeURL }}">{{ .Text | safeHTML }}</a>
{{ end }}

Это удобно для блогов с активным использованием ссылок: можно по-разному оформлять «отдельные ссылки на источники» и «inline-упоминания».

Ordinal помогает строить нумерованные списки источников или footnote-style references без ручной разметки.

Мультиязычность: site.Home.Translations 🌐 #

Метод site.Home.AllTranslations помечен как deprecated. Заменяет его более узкий site.Home.Translations.

Разница:

• AllTranslations возвращает все языковые версии главной страницы, включая текущую.
• Translations возвращает только другие языки, без текущей версии.

Старый код:

{{ range site.Home.AllTranslations }}
  {{ if ne .Lang $.Lang }}
    <a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a>
  {{ end }}
{{ end }}

После 0.156 ту же логику можно записать прямее:

{{ range site.Home.Translations }}
  <a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a>
{{ end }}

Меньше кода, понятнее намерение. Если вы вели мультиязычный сайт с языковым переключателем — самое время заменить.

Опция disableSetLocale ⚙️ #

В конфиге появилась новая опция:

disableSetLocale = true

По умолчанию Hugo пытается установить системную локаль операционной системы согласно языку текущего сайта. Это влияет на форматирование дат, чисел, сортировку строк (strings.Sort).

Иногда это поведение нежелательно. Например, в CI-контейнере может не быть нужной локали, и Hugo молча падает на дефолт. Или вы хотите, чтобы поведение было одинаковым на всех машинах сборки независимо от языка контента.

disableSetLocale = true отключает эту попытку. Hugo использует значения из конфига и встроенные форматтеры без обращения к OS-уровню setlocale().

Когда нужно: CI-сборки на минимальных образах (alpine, debian-slim), где локали могут отсутствовать; репозитории с воспроизводимой сборкой; ситуации, когда вы заметили различия в форматах между локальной сборкой и CI.

Депрекейт пути _vendor/github.com/gohugoio/locales #

Путь _vendor/github.com/gohugoio/locales помечен как устаревший. Если вы его явно использовали (например, импортировали как submodule в проект), стоит начать миграцию на встроенные локали Hugo — релиз поддерживает их через стандартный механизм.

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

Чек-лист обновления за 30 минут ✅ #

Чтобы пройти миграцию без сюрпризов:

1. Поднять версию Hugo до 0.161.0 (если ещё на старой) или 0.156.0 как промежуточный шаг. Если работаете в Docker, обновить ARG HUGO_VERSION и пересобрать образ.

2. Поиск устаревших API в шаблонах:

   grep -rn 'site\.Data\|site\.Sites\|AllTranslations' layouts/ themes/*/layouts/

   copy

   Если хиты есть — заменить на hugo.Data, hugo.Sites, Translations.

3. Проверить кастомные render hooks, если они есть. Можно ли получить пользу от новых IsBlock и Ordinal?

4. Решить про disableSetLocale. Если CI-сборки иногда дают разные форматы дат в зависимости от хоста, добавить опцию в конфиг.

5. Прогнать сборку:

   hugo --minify --gc

   copy

   Не должно быть warning’ов. Если появились — каждый из них чем-то да полезен, не игнорировать.

6. Открыть несколько критичных страниц локально, проверить, что меню, переводы, render hooks работают.

7. Закоммитить и задеплоить. На статичном Hugo-сайте откат — это git revert плюс пересборка, минут 5.

Итог 🧠 #

Hugo 0.156.0 — не «громкий релиз ради хайпа». Это пакет аккуратных архитектурных изменений: переезд на новые API, расширение возможностей для тех, кто пишет render hooks, чистка мультиязычной части.

Главная польза от такого релиза — возможность снять немного технического долга прямо сейчас, пока депрекейты ещё работают. Пропустишь — через год будешь разбираться, почему что-то перестало рендериться.

Если у вас минимальный шаблонный код (стандартная тема без кастомных hook’ов и без мультиязычности), переход почти прозрачен. Если у вас активные render hooks или мультиязык — стоит выделить полчаса на ревизию.

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

Источники #

• Официальный релиз: gohugoio/hugo v0.156.0
• Документация по новым API: hugo.Data, hugo.Sites
• Документация по переводам: site.Home.Translations
• Документация link render hooks: Render hooks: links

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

Это не «дешевле магазинной» (по факту — нет, особенно с учётом времени). Это «честнее и вкуснее, если потратить время на освоение базовых пропорций». А пропорции — самое важное в колбасе. Если соль/специи/влага в норме, даже простой кусок мяса превращается в нормальный продукт.

Этот пост — рабочая памятка с пропорциями, которые я использую как отправную точку, плюс короткое объяснение, зачем там каждый ингредиент. Без претензий на «единственно верный рецепт».

Соль и добавки на 1 кг 🧂 #

Базовый набор:

• Соль: 18-20 г.
• Оптимальный вариант: 16 г обычной соли + 2-3 г нитритной соли.
• Сахар: 5 г (примерно 1 ч. л.).
• Чёрный перец: 1 ч. л.
• Чеснок: 2 зубчика (около 8-10 г).
• Мускатный орех: щепотка.
• Лёд или ледяная вода: 80-100 мл.

Этот набор использую как отправную точку. Дальше корректирую специи под конкретное мясо и личный вкус.

Зачем каждое из этого #

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

Соль — 18-20 г на 1 кг. Это не «по вкусу». Это пороговая концентрация: меньше — фарш плохо «связывается» (соль вытягивает миофибриллярные белки, которые удерживают воду), больше — переедено и опасно. Норма для большинства колбас 1.8-2%.

Нитритная соль — 2-3 г. Главный вопрос. Нитрит даёт характерный розовый цвет, узнаваемый «колбасный» вкус и — главное — подавляет рост ботулинических бактерий. Без него любая колбаса с длительной выдержкой или копчением рискует превратиться в источник опасных токсинов. Не «химия, которую нужно избегать», а функциональный консервант, который существует не зря. Концентрация 2-3 г нитритной соли (а не чистого нитрита) — безопасный диапазон, давно стандартизированный.

Сахар — 5 г. Не для сладости. Для микробиоты — она «съедает» сахар и даёт лёгкое подкисление, плюс смягчает солёность.

Чёрный перец, чеснок, мускат. Базовая «колбасная» ароматическая основа. Каждый компонент можно менять под вкус (паприка, горчица в зёрнах, кориандр, тмин), но эта тройка — спокойная отправная точка.

Ледяная вода — 80-100 мл. Самое неочевидное для новичков. Вода не «разбавляет», а наоборот — вместе с белками образует эмульсию, которая держит структуру колбасы при нагреве. Если воду не добавить, колбаса получится сухой и зернистой. Если добавить тёплую — белки свернутся раньше времени, эмульсия не сложится. Лёд гарантирует, что фарш во время вымешивания остаётся холодным.

Технология процесса #

Кратко, без излишних деталей, чтобы держать целое в голове:

1. Подготовка мяса. Охладить до 1-3°C (не замораживать). Срезать жёсткие плёнки и хрящи, нарезать кусками удобного размера.
2. Помол. Через мясорубку с решёткой 4-6 мм. Чем мельче, тем «нежнее» структура; чем крупнее — тем «деревенская» подача.
3. Внесение соли и нитрита. На холодный фарш, тщательно перемешать.
4. Специи и сахар. Добавить, перемешать снова.
5. Лёд/ледяная вода. Добавлять постепенно, продолжая вымешивать. Цель — получить однородную массу, в которой видна вязкость («тянется» при отрыве).
6. Холодная пауза. 1-3 часа в холодильнике, чтобы соль распределилась и фарш «созрел».
7. Набивка. В оболочку (натуральную или коллагеновую), без воздушных пузырей.
8. Термообработка. Зависит от типа: варка при 75-80°C до внутренней температуры 70-72°C, копчение, запекание.

Эта последовательность — каркас. Каждый шаг можно тонко донастраивать, но если убрать любой из них, результат заметно проседает.

Типичные ошибки начинающих 🪤 #

Самые частые сбои, которые легко избежать, если знать заранее:

Слишком тёплый фарш. Если на любом этапе фарш нагрелся выше 12-15°C, эмульсия не сложится. Жир «вытопится» при варке, в продукте появятся жирные карманы. Лёд обязателен.

Переизбыток соли. «Я люблю солёное» не работает. Превысил 25 г на кг — продукт не съесть, а ребалансировать сложно: соль из готовой колбасы не уберёшь.

Недомес. Если фарш не дошёл до состояния «вязкий, тянется» — структура развалится. Вымешивание — главное, что делает колбасу колбасой, а не «фарш в кишке».

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

Резкий перегрев при варке. Внутри колбасы должно быть 70-72°C, не больше. Перегрев = выплавление жира + сухость. Для контроля — кулинарный термометр; «на глаз» в этом деле подводит.

Спешка с дегустацией. Колбасе нужно «созреть» в холодильнике хотя бы 12-24 часа после варки. Свежевыкипяченная — это не финальный вкус.

Варианты по виду мяса #

Базовый рецепт работает для свинины и для смесей. Несколько типичных вариаций:

• Свинина (60% мякоти + 40% жирной части). Классика, сбалансированный вкус, хороший для новичков.
• Свинина + говядина (70/30). Более «мясной» характер, плотнее структура, чуть жёстче.
• Только говядина. Суше, требует больше воды и аккуратности с эмульсией; вкус интенсивнее.
• Птица (грудка + бедро). Нежнее, ниже жирность; нужно поднять долю воды и тщательнее вымешивать.

Соль и нитрит — те же. Воды иногда нужно немного больше для постного мяса.

Безопасность ⚠️ #

Несколько моментов, о которых стоит знать обязательно:

• Нитритная соль ≠ чистый нитрит. Это уже разбавленная смесь (обычно 0.5-0.6% NaNO₂ в обычной соли). Использовать строго по дозировке для нитритной соли, не для чистого вещества.
• Ботулизм. Главная причина существования нитрита в колбасном деле. При длительной выдержке без нитрита риск реален; не «древняя страшилка».
• Контроль температуры. Внутренняя температура готового продукта 70-72°C — это не «совет», это безопасность.
• Сроки хранения. Домашняя колбаса без консервантов хранится в холодильнике значительно меньше магазинной. Замораживание — ок, но текстура немного меняется.

Если делаете колбасу впервые — стоит прочитать пару проверенных источников по технологии (например, Stanley Marianski «Home Production of Quality Meats and Sausages» или книги по колбасному делу на русском). Это не та область, где «методом тыка» — оптимальный путь обучения.

Куда дальше, если втянулся #

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

• Сухое созревание (колбаса как salami). Долгий процесс, требует контроля температуры и влажности.
• Копчение (горячее или холодное). Меняет вкус и продлевает хранение.
• Свои смеси специй. Эксперименты с паприкой, фенхелем, кориандром, перцем чили — ровно по чайной ложке, чтобы не «перегрузить».
• Натуральные оболочки. Свиная черева, говяжьи синюги, бараньи кишки — каждая дает свою текстуру.

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

Итоги #

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

Этот рецепт — мой рабочий минимум. Точные пропорции вы со временем подгоните под себя, но 18-20 г соли, 80-100 мл ледяной воды, обязательная нитритная составляющая и аккуратное вымешивание — фундамент, на котором всё остальное держится. 🍴

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

Так в нашей жизни появилась ректификационная колонна «Дом Спирт 2» и дерзкая цель — попробовать сделать абсент. Через несколько подходов мы получили результат, который можно назвать «похожим на абсент», и значительно больше — наблюдений о самом процессе.

Что такое ректификационная колонна (упрощённо) #

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

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

«Дом Спирт 2» — российская модель домашней ректификационной колонны. Она не самая мощная и не самая компактная, но достаточно «честная»: достать, освоить базовый цикл, понять, как ведёт себя пар, давление, температура — реально для технически грамотного человека за несколько вечеров.

Первые впечатления: техника — это не половина дела, а почти всё #

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

Несколько вещей, которых мы не ожидали:

• Длительность процесса. Полный цикл от загрузки до получения готового продукта — это много часов, иногда вся суббота.
• Чувствительность к деталям. Изменение скорости отбора, температуры, охлаждения дефлегматора — каждое влияет на результат сильнее, чем казалось из видеообзоров.
• Гигиена. «Чисто» в обычном смысле и «чисто» для процесса — разные понятия.
• Дисциплина протокола. Если делать «на глаз» — результаты непредсказуемы. Если фиксировать каждый шаг — повторяемость растёт.

Чем абсент сложнее «обычного дистиллята» #

Классический спирт-ректификат — это, грубо, очищенный этанол с водой. Абсент сложнее устроен:

1. Мацерация. Травы (полынь, анис, фенхель и менее афишированные растения) настаиваются на готовом спирте.
2. Перегонка с травами. Полученный настой перегоняется заново — часть ароматических компонентов переходит в дистиллят, часть остаётся в кубе.
3. Финальное окрашивание. Дополнительная мацерация на свежих травах даёт характерный зелёный или жёлтый оттенок.

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

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

Что получилось #

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

Что не получилось #

• Стабильность. Один и тот же подход давал разный результат от подхода к подходу.
• Предсказуемость вкуса и аромата. Это тонкая, почти ювелирная работа.
• Терпение. Иногда проще поставить эксперимент на паузу, чем пытаться «додавить» его усталостью.
• Точная имитация классического абсента. До «как в Швейцарии» далеко; пока ближе к «дегустационному образцу собственного производства».

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

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

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

Безопасность (важное) #

Несколько вещей, которые нужно проговорить отдельно:

• Голов и хвостов нельзя пить. Первые и последние фракции содержат метанол, сивушные масла и другие соединения, потенциально опасные. Их отделяют по проверенной методике.
• Высокая концентрация спирта = высокая огнеопасность. Колонна греется, пары горючи, помещение должно быть вентилируемым.
• Лицензирование и закон. В разных странах правила производства алкоголя для личного потребления отличаются. Ответственность всегда на изготовителе.
• Дегустация. Не «глотнуть и надеяться». Малая проба, оценка по органолептике, никаких больших порций неотлежавшегося продукта.

Я не даю инструкций и рецептов в этом посте сознательно. Это пост про опыт и наблюдения, а не учебник.

Зачем писать об этом #

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

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

Что дальше #

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

Если резюмировать одной фразой: самое важное, что я понял за эти подходы — терпение в этом хобби стоит больше, чем оборудование. Хорошая колонна не сделает за тебя дисциплину. А плохая дисциплина не оправдается дорогой колонной. 🧪

В какой-то момент я понял простую вещь: если не автоматизировать технические повторяющиеся шаги, то темп публикаций будет определяться не качеством идей, а запасом терпения. Именно здесь Codex даёт максимальную пользу. 🚀

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

Где именно теряется время при выпуске поста #

До автоматизации у меня стабильно проседали одни и те же этапы:

1. Переход от идеи к первому цельному черновику.
2. Ручное оформление фронтматтера без ошибок.
3. Поддержание одинакового уровня качества для summary и description.
4. Повторяемые технические действия перед публикацией.

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

Какую роль я отдаю Codex, а какую оставляю себе #

Чтобы автоматизация была полезной, роли должны быть разделены жёстко.

За мной остаётся:

• тезис и позиция статьи;
• финальная логика аргументации;
• личный опыт, выводы и тональность.

Codex получает:

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

Такая схема позволяет не спорить с инструментом о «вкусе текста», а использовать его там, где важнее точность и скорость.

Рабочий конвейер: от идеи до публикации #

Ниже процесс, который у меня реально работает в блоге на Hugo.

1. Формулирую цель поста в двух фразах #

Перед стартом фиксирую:

• для кого материал;
• какое практическое действие читатель сможет сделать после прочтения.

Если это не ясно на старте, статья почти всегда расползается.

2. Даю Codex каркас будущего текста #

Минимальный вход:

• рабочий заголовок;
• 5-8 смысловых пунктов;
• 2-3 конкретных примера;
• желаемая глубина (коротко / подробно / разбор).

На этом этапе я не прошу «красивый текст», я прошу структуру, которую удобно усиливать.

3. Собираю длинный черновик и сразу проверяю логические провалы #

Обычно я смотрю:

• нет ли повторов между разделами;
• есть ли причинно-следственная связка между блоками;
• не превращаются ли выводы в общие фразы.

Если провалы есть, лучше исправить их до стилистической шлифовки.

4. Редактирую смысл вручную #

Это самый важный шаг. Здесь я:

• вырезаю «воду»;
• добавляю реальные наблюдения;
• уточняю формулировки, где можно понять двояко;
• усиливаю практическую часть (чек-листы, сценарии, ограничения).

Именно здесь текст перестаёт быть «генерированным» и становится авторским.

5. Передаю Codex техническое оформление #

После смысловой правки Codex приводит материал к правилам блога:

• корректный фронтматтер;
• осмысленные summary и description без дублирования;
• релевантные теги;
• структура с оглавлением и читабельными секциями;
• уместные эмодзи для акцентов.

6. Финальная техническая валидация #

Перед публикацией использую обязательный минимум:

hugo list future
hugo --minify

Если пост попал в future, дата сдвигается назад (МСК, +03:00), затем повторная проверка.

7. Публикация #

После проверки Codex помогает зафиксировать изменения:

git add .
git commit -m "Осмысленный коммит на русском по теме поста"
git push

На этом этапе уже не нужно держать в голове «не забыть бы пуш» или «как назвать коммит».

Что реально улучшилось после внедрения #

Я получил не «магическое ускорение», а более важную вещь: предсказуемость процесса.

Практические эффекты:

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

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

Типовые ошибки при работе с Codex (и как их избежать) #

Ошибка 1: просить «сразу финальный пост» #

Так почти всегда получается текст без авторской позиции. Лучше идти через этапы: каркас → черновик → ручная редактура → техническая сборка.

Ошибка 2: не задавать ограничения #

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

Ошибка 3: пропускать финальный ручной проход #

Без авторской правки текст может быть «правильным», но без нервов и фактуры. Читатель это считывает мгновенно.

Мини-шаблон запроса, который у меня работает #

Я обычно даю Codex примерно такую рамку:

Нужен пост для Hugo-блога на русском.
Формат: длинная статья, глубокая проработка, практические выводы.
Структура: вступление, 6-8 разделов, финальный чек-лист.
Обязательно: осмысленные summary/description, корректный фронтматтер, уместные эмодзи.
После текста: проверить техническую часть публикации (hugo list future, hugo --minify, commit, push).

Этого достаточно, чтобы стартовый результат был рабочим, а не «общей заготовкой».

Когда Codex точно не помогает #

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

Когда тема ещё не оформилась. Если у вас в голове только смутное «хочется написать про X», Codex выдаст структуру вокруг этой смутности — формально стройную, по сути пустую. Лучше потратить полчаса на бумажный набросок, выписать 3-5 ключевых тезисов, и только потом включать инструмент. Код первым приходит туда, где есть запрос; в текстах этот запрос — авторская позиция.

Личные посты. Эссе про опыт, наблюдение, ошибку — Codex здесь не нужен. Структуру эссе диктует не методическая разбивка на h2-разделы, а внутренняя логика рассказа. Прогон через шаблон «вступление → 6 разделов → чек-лист» убивает живость текста. Технические руководства — да; рефлексия — нет.

Когда ответ нужно проверить руками. Если вы пишете про инструмент, который сами не запускали (например, обзор библиотеки по чужим текстам), Codex усилит риски: соберёт правдоподобный текст с фактическими ошибками. Точность здесь обеспечивает только личное прохождение сценария, до буквы команд.

Что меняется в процессе через 3-6 месяцев #

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

• Вы начинаете писать чаще, потому что нет «трения старта».
• Качество публикаций становится ровным — нет «слабых» постов из-за усталости от рутины.
• Появляется привычка фиксировать правила процесса (AGENTS.md, шаблоны, чек-листы) сразу, а не «когда-нибудь».
• Перестаёте откладывать посты из-за мелких технических придирок (формат даты, длина summary, теги).

Это не «магия ИИ». Это просто разделение труда между «чем я уникально полезен» и «что можно поручить инструменту».

Практические выводы #

Если коротко, рабочая модель такая:

1. Смысл и позиция остаются у автора.
2. Codex берёт структуру и операционную рутину.
3. Качество растёт там, где есть дисциплина процесса, а не просто «сильный промпт». ✅

Автоматизация в блоге полезна не потому, что «пишет быстрее», а потому что защищает внимание автора. А внимание, в долгую, важнее любой единичной публикации.

Тема здоровья легко превращается в гонку гаджетов, протоколов и баночек. Зашёл в любой телеграм-канал «про биохак», полистал — и через неделю на полке стоят семь новых БАДов, на руке трекер сна, на диване книга про митохондрии. А базовые вещи — режим сна, ежедневное движение, нормальный завтрак — продолжают проседать.

Я хочу держать тему в более приземлённом поле: сначала базовые привычки, потом аккуратные эксперименты, и только затем — добавки, если есть для этого основания. Этот пост — не медицинская рекомендация и не «топ-10 must-have БАДов». Это попытка нарисовать карту, по которой можно ориентироваться, не теряя голову.

База, без которой не работает ничего 🛏 #

Самые надёжные улучшения лежат в простых вещах, и они банальны до зевоты:

• Сон по расписанию. Одинаковое время отбоя и подъёма (включая выходные), темнота в спальне, ограничение экранов за час до сна. Не «8 часов любой ценой», а ровные 7-8 часов в одни и те же часы.
• Движение каждый день. Прогулки, силовые, растяжка — не важно что именно, важно регулярно. Дневная норма шагов даже без зала уже даёт большой кусок пользы.
• Рацион с адекватным белком, клетчаткой и достаточной калорийностью. Не «суперфуды», не «чистое питание» в религиозном смысле, а понятный рацион без хронического дефицита.
• Управление стрессом. Простые ритуалы (вечерняя прогулка, регулярные паузы), ограничение перегруза, цифровая гигиена. Не «медитация 1 час в день», а «не работать вечером».

Если эти пункты не закрыты, «биохакинг» превращается в красивую упаковку поверх системных дыр. Купить адаптоген, чтобы компенсировать хронический недосып — это не про здоровье, это про прокрастинацию здоровья.

Биохакинг как дисциплина, а не как шоу #

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

1. Измерять только то, что будет влиять на решения. Если данные не меняют поведение, это не данные, это шум.
2. Менять по одному фактору за раз. Иначе невозможно понять, что именно сработало (и сработало ли). Ввели магний, омегу и витамин D одновременно — улучшение есть, но причина неизвестна.
3. Держать горизонт не в днях, а в месяцах. Большинство значимых изменений в самочувствии копится медленно. «Через неделю стало лучше» — обычно эффект новизны, а не реальный сдвиг.

Эти три правила сами по себе отсекают 80% эзотерических протоколов из соцсетей. Если автор предлагает «попробуй и сразу почувствуешь разницу» — он не про дисциплину, он про маркетинг.

Анализы и данные: когда они действительно нужны 📊 #

Слепая сдача десятков анализов «потому что в соседнем чате посоветовали» редко помогает. Полезнее идти от вопросов:

• Что именно я хочу улучшить или понять?
• Есть ли симптомы или жалобы?
• Что из результатов повлияет на конкретные действия?

Если ответов нет — анализы становятся способом успокоиться, а не инструментом управления.

Несколько маркеров, которые часто имеют смысл проверять (без претензии на исчерпывающий список):

• Витамин D (25-OH). В умеренных широтах хронический дефицит у большинства, особенно зимой.
• Ферритин. Маркер запасов железа; низкий часто объясняет «беспричинную» усталость.
• B12 и фолат. Особенно важно для тех, кто ограничивает мясо.
• Магний. Анализ малоинформативен (магний в основном внутри клеток), но если есть симптомы (судороги, аритмии) — стоит обсудить с врачом.
• ТТГ + Т4 свободный. Базовая щитовидка, влияет на энергию, вес, настроение.

Это не «обязательная панель», это набор «если есть жалобы — есть смысл начать отсюда».

БАДы: инструмент, а не спасение #

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

Принципы, которых я стараюсь придерживаться:

• Сначала проверка базовых привычек.
• Затем чёткая цель и ожидаемый эффект.
• И только после этого — минимальная дозировка и наблюдение за эффектом.

Если БАД нельзя описать в формате «принимаю X для Y, эффект жду через Z недель» — лучше не принимать. Это правило отсеивает «модные новинки», которые завозят все блогеры разом.

Как выбирать добавки разумно #

Простая схема, которая работает:

1. Определить цель. Сон, энергия, восстановление, дефицит по анализу. Что-то одно, не «всё сразу».
2. Проверить безопасность и совместимость. С текущими лекарствами, состояниями, образом жизни. Это отдельная работа, не пропускать.
3. Начать с одной добавки и фиксировать изменения. Дневник в три строки в день: сон, энергия, настроение. Этого достаточно.
4. Отменить, если эффекта нет или он сомнителен. Через 4-8 недель, не раньше.

И да: это не медицинская рекомендация. При сомнениях, симптомах или сложных состояниях — обсуждать с врачом, не с интернетом.

Типичные ловушки 🪤 #

Самые частые ошибки, в которые попадаются почти все, кто заходит в тему:

Покупать всё сразу. Под влиянием статьи или подкаста заказывают 5-7 добавок. В итоге не понимают, что работает, а что нет.

Надеяться на «волшебную таблетку». Если есть проблема со сном — никакая добавка не починит то, что чинится за неделю гигиены сна.

Забывать про доказательную базу. Многие популярные добавки имеют слабые или противоречивые исследования. «Все вокруг пьют» — не критерий.

Игнорировать побочки. Любой БАД может давать эффект, который вы спишете на «обычный день». Дневник помогает поймать.

Доверять ярким инфлюенсерам. Биохакинг — благодатная почва для красивых историй и плохих советов. Чем громче «у меня всё работает», тем выше вероятность маркетинга или selection bias.

Минимальный подход #

Я склоняюсь к минимальному набору: меньше банок, больше дисциплины. Часто достаточно навести порядок в рутине, чтобы необходимость в добавках исчезла или сильно сократилась.

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

Итоги 🧠 #

Здоровье — это не витрина из биохакинга, а устойчивость, которая складывается из маленьких повторяющихся решений. Добавки могут быть частью этой системы, но только после того, как база отстроена и цели ясны.

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

Самый честный «биохакинг» — это лечь спать на час раньше. Бесплатно, без побочек, эффект через неделю.