Тут попалось интересное. Anthropic выкатили новые правила контекст-инжиниринга,.
Суть: они убрали больше 80% системного промпта Claude Code для моделей вроде Claude Opus 5 и Claude Fable 5 без измеримой просадки на своих тестах по кодингу. Поняли, что сами же переограничивали модель: и системным промптом, и CLAUDE.md, и скиллами.
Что поменялось по сути:
1. Правила -> суждение. Раньше в промпте было жёсткое "по умолчанию не пиши комментарии, никогда не делай многострочных docstring". Сейчас: "пиши код, который читается как окружающий: попадай в его плотность комментариев, нейминг и идиоматику".
2. Примеры -> дизайн интерфейсов. Правило номер один раньше было "дай модели примеры использования инструментов". Теперь примеры загоняют её в узкий коридор. Лучше вложиться в сам инструмент: выразительные параметры, понятные enum'ы. Статус pending / in_progress / completed в Todo-туле сам подсказывает, как им пользоваться.
3. Всё вперёд -> progressive disclosure. Code review и верификацию вынесли в отдельные скиллы, которые Claude подгружает по необходимости. Часть инструментов вообще с отложенной загрузкой: агент сначала ищет их через ToolSearch. То же применимо к вашим файлам. Миф, что CLAUDE.md должен быть централизованным складом всех практик "на всякий случай". Лучше дерево файлов, подгружаемых в нужный момент.
Спека не обязана быть Markdown. Спекой может быть подробный тестовый набор, HTML-артефакт или функция из другой кодовой базы, которую надо портировать. Файлы в коде вообще предпочтительнее: HTML-макет дизайна даст результат лучше, чем его описание или скриншот.
Память. Раньше советовали сохранять всё в CLAUDE.md. Теперь Claude сам сохраняет релевантные воспоминания.
Отдельно про CLAUDE.md: коротко опишите, для чего репозиторий, а основные токены потратьте на подводные камни. Не пишите очевидное - то, что модель и так увидит, посмотрев на файловую систему.
И самое приятное: это не надо делать руками. Anthropic зашили эти практики в новую команду - /doctor в Claude Code сам порежет по размеру ваши скиллы и CLAUDE.md.
Это не только у Anthropic! OpenAI в гайде по GPT-5.5 пишут ровно то же самое: «Короткие промпты, ориентированные на результат, обычно работают лучше, чем тяжёлые процессные стеки инструкций. И прямым текстом: не переносите все инструкции из старого промпт-стека, потому что legacy-промпты часто переспецифицируют процесс - старым моделям нужна была помощь, чтобы не сбиться, а на GPT-5.5 это добавляет шум, сужает пространство поиска и делает ответы механическими. Плюс отдельный пункт: избегайте лишних абсолютных правил вроде ALWAYS / NEVER / must / only. Держите их для настоящих инвариантов - безопасность, обязательные поля. А для решений "когда искать, когда спрашивать, когда останавливаться" используйте decision rules.»
Прочитайте оригинал своих инструкций сегодня, а потом запустите /doctor и посмотрите, сколько лишнего накопилось у вас.
Ссылки на источники:
Материал Anthropic (Thariq Shihipar, 24 июля 2026)
https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
Базовая статья Anthropic про контекст-инжиниринг
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Field guide по Fable
https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
Гайды OpenAI по промптингу (GPT-5.5 и ниже)
https://developers.openai.com/api/docs/guides/prompt-guidance
Пользовательский гайд OpenAI по промптингу для ChatGPT и Codex
https://learn.chatgpt.com/docs/prompting
Суть: они убрали больше 80% системного промпта Claude Code для моделей вроде Claude Opus 5 и Claude Fable 5 без измеримой просадки на своих тестах по кодингу. Поняли, что сами же переограничивали модель: и системным промптом, и CLAUDE.md, и скиллами.
Что поменялось по сути:
1. Правила -> суждение. Раньше в промпте было жёсткое "по умолчанию не пиши комментарии, никогда не делай многострочных docstring". Сейчас: "пиши код, который читается как окружающий: попадай в его плотность комментариев, нейминг и идиоматику".
2. Примеры -> дизайн интерфейсов. Правило номер один раньше было "дай модели примеры использования инструментов". Теперь примеры загоняют её в узкий коридор. Лучше вложиться в сам инструмент: выразительные параметры, понятные enum'ы. Статус pending / in_progress / completed в Todo-туле сам подсказывает, как им пользоваться.
3. Всё вперёд -> progressive disclosure. Code review и верификацию вынесли в отдельные скиллы, которые Claude подгружает по необходимости. Часть инструментов вообще с отложенной загрузкой: агент сначала ищет их через ToolSearch. То же применимо к вашим файлам. Миф, что CLAUDE.md должен быть централизованным складом всех практик "на всякий случай". Лучше дерево файлов, подгружаемых в нужный момент.
Спека не обязана быть Markdown. Спекой может быть подробный тестовый набор, HTML-артефакт или функция из другой кодовой базы, которую надо портировать. Файлы в коде вообще предпочтительнее: HTML-макет дизайна даст результат лучше, чем его описание или скриншот.
Память. Раньше советовали сохранять всё в CLAUDE.md. Теперь Claude сам сохраняет релевантные воспоминания.
Отдельно про CLAUDE.md: коротко опишите, для чего репозиторий, а основные токены потратьте на подводные камни. Не пишите очевидное - то, что модель и так увидит, посмотрев на файловую систему.
И самое приятное: это не надо делать руками. Anthropic зашили эти практики в новую команду - /doctor в Claude Code сам порежет по размеру ваши скиллы и CLAUDE.md.
Это не только у Anthropic! OpenAI в гайде по GPT-5.5 пишут ровно то же самое: «Короткие промпты, ориентированные на результат, обычно работают лучше, чем тяжёлые процессные стеки инструкций. И прямым текстом: не переносите все инструкции из старого промпт-стека, потому что legacy-промпты часто переспецифицируют процесс - старым моделям нужна была помощь, чтобы не сбиться, а на GPT-5.5 это добавляет шум, сужает пространство поиска и делает ответы механическими. Плюс отдельный пункт: избегайте лишних абсолютных правил вроде ALWAYS / NEVER / must / only. Держите их для настоящих инвариантов - безопасность, обязательные поля. А для решений "когда искать, когда спрашивать, когда останавливаться" используйте decision rules.»
Прочитайте оригинал своих инструкций сегодня, а потом запустите /doctor и посмотрите, сколько лишнего накопилось у вас.
Ссылки на источники:
Материал Anthropic (Thariq Shihipar, 24 июля 2026)
https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
Базовая статья Anthropic про контекст-инжиниринг
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Field guide по Fable
https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
Гайды OpenAI по промптингу (GPT-5.5 и ниже)
https://developers.openai.com/api/docs/guides/prompt-guidance
Пользовательский гайд OpenAI по промптингу для ChatGPT и Codex
https://learn.chatgpt.com/docs/prompting
Claude
The new rules of context engineering for Claude 5 generation models | Claude by Anthropic
We removed over 80% of Claude Code's system prompt for more advanced models. How to apply the lessons we learned to your own context engineering in Claude Code and with your own agents.
👍5
Почему xhigh effort - это не режим "максимальной эффективности"
Закончил тесты GPT на десяти реальных задачах. Сравнивал обычные значения effort с переключением на xhigh.
Результат довольно однозначный: xhigh не улучшил качество ни у одной из моделей, зато существенно увеличил время работы и расход токенов.
У GPT-5.6 результат снизился с 70,18% до 69,21%, а количество полностью решенных задач - с 6 из 10 до 5 из 10. Время выросло с 21:39 до 55:40, объем входных токенов - с 3,32 до 7,08 млн, выходных - с 44,96 до 122,28 тыс.
У GPT-5.5 результат снизился с 61,38% до 59,05%, решенных задач стало 4 из 10 вместо 5 из 10. Время выросло с 38:12 до часа, выходных токенов стало больше примерно вдвое.
То есть в данном случае "не улучшил" фактически означает "ухудшил". Модель дольше работала, потратила больше токенов и в итоге решила меньше задач.
Высокий effort действительно может быть полезен, но не как настройка по умолчанию. Он нужен для задач, где требуется именно размышление:
аналитика рынка или ниши
формирование продуктовой карты
поиск неочевидных решениq
творческие задачи
работа с неявными критериями приемки
ситуации, где нужно не выполнить инструкцию, а сначала придумать, что именно следует делать
Но если агент просто выполняет понятные операции, пишет обычный код или оркестратор только управляет другими агентами, высокий effort ему не нужен.
Для кодинга он зачастую скорее вреден. Модель начинает дольше обдумывать простые действия, генерирует больше промежуточных рассуждений и медленнее приходит к тому же или даже худшему результату.
Отсюда, видимо, и рассказы о том, как люди постоянно сжигают лимиты своих тарифов, которых им вечно не хватает. Включают "максимальное мышление" для всех задач подряд и получают расход в два-три раза больше времени и токенов.
Но "больше думать" - вообще не синоним эффективности.
Иногда это буквально означает, что прежде чем выполнить ls или dir, модель долго размышляет, как эта команда повлияет на архитектуру всего проекта. 🙂
Короче, переключаться на xhigh для тестов было плохой идеей. Возвращаю модели на medium и дальнейшие сравнения буду проводить именно на нем.
Высокий effort оставлю для тех задач, где дополнительное размышление действительно является частью работы
Закончил тесты GPT на десяти реальных задачах. Сравнивал обычные значения effort с переключением на xhigh.
Результат довольно однозначный: xhigh не улучшил качество ни у одной из моделей, зато существенно увеличил время работы и расход токенов.
У GPT-5.6 результат снизился с 70,18% до 69,21%, а количество полностью решенных задач - с 6 из 10 до 5 из 10. Время выросло с 21:39 до 55:40, объем входных токенов - с 3,32 до 7,08 млн, выходных - с 44,96 до 122,28 тыс.
У GPT-5.5 результат снизился с 61,38% до 59,05%, решенных задач стало 4 из 10 вместо 5 из 10. Время выросло с 38:12 до часа, выходных токенов стало больше примерно вдвое.
То есть в данном случае "не улучшил" фактически означает "ухудшил". Модель дольше работала, потратила больше токенов и в итоге решила меньше задач.
Высокий effort действительно может быть полезен, но не как настройка по умолчанию. Он нужен для задач, где требуется именно размышление:
аналитика рынка или ниши
формирование продуктовой карты
поиск неочевидных решениq
творческие задачи
работа с неявными критериями приемки
ситуации, где нужно не выполнить инструкцию, а сначала придумать, что именно следует делать
Но если агент просто выполняет понятные операции, пишет обычный код или оркестратор только управляет другими агентами, высокий effort ему не нужен.
Для кодинга он зачастую скорее вреден. Модель начинает дольше обдумывать простые действия, генерирует больше промежуточных рассуждений и медленнее приходит к тому же или даже худшему результату.
Отсюда, видимо, и рассказы о том, как люди постоянно сжигают лимиты своих тарифов, которых им вечно не хватает. Включают "максимальное мышление" для всех задач подряд и получают расход в два-три раза больше времени и токенов.
Но "больше думать" - вообще не синоним эффективности.
Иногда это буквально означает, что прежде чем выполнить ls или dir, модель долго размышляет, как эта команда повлияет на архитектуру всего проекта. 🙂
Короче, переключаться на xhigh для тестов было плохой идеей. Возвращаю модели на medium и дальнейшие сравнения буду проводить именно на нем.
Высокий effort оставлю для тех задач, где дополнительное размышление действительно является частью работы
👍5🔥1
Сегодня не было настроения работать. Жарковато.
В общем решил продолжить развлечение. С очень неожиданной развязкой.
Sonnet 5 обошел всех в рейтинге. И terra от ГПТ оказалась лучше остальных ГПТ-моделей.
Для меня прямо открытие. Сижу, перевариваю.
Я «просто глянуть» эти две модели запустил…
И что теперь, Луну и Хайку тестить? :-)
В общем решил продолжить развлечение. С очень неожиданной развязкой.
Sonnet 5 обошел всех в рейтинге. И terra от ГПТ оказалась лучше остальных ГПТ-моделей.
Для меня прямо открытие. Сижу, перевариваю.
Я «просто глянуть» эти две модели запустил…
И что теперь, Луну и Хайку тестить? :-)
Опять эти загадочные "сайты, работающие в России".
Дебилы, блин. Практически любой сайт в мире открывается и "работает" в России - как и в любой другой стране с доступом в интернет. Сайт - это не магазин, который открыл филиал в Химках.
По такой формулировке российский номер телефона скоро потребуется для входа на сайт музея в Перу, форум японских аквариумистов и домашнюю страницу профессора из Огайо.
Осталось только объяснить всему интернету, что он теперь работает по российским законам.
Дебилы, блин. Практически любой сайт в мире открывается и "работает" в России - как и в любой другой стране с доступом в интернет. Сайт - это не магазин, который открыл филиал в Химках.
По такой формулировке российский номер телефона скоро потребуется для входа на сайт музея в Перу, форум японских аквариумистов и домашнюю страницу профессора из Огайо.
Осталось только объяснить всему интернету, что он теперь работает по российским законам.
👍3😁2
Друзья, у меня для вас внезапное предложение: помочь знакомому проекту получить хорошего CTO. Знакомый - это я 🙂
Многие из вас знают меня давно и именно как технического директора: я больше 20 лет работаю с web-системами, строю команды разработки и навожу порядок между «бизнесу нужно» и «разработка делает».
Сейчас ищу новый проект или постоянную работу в роли CTO. Лучше всего подойду действующему digital/web-бизнесу после MVP, где уже есть продукт, деньги на разработку и команда, но нужен человек, который возьмёт на себя технологическую функцию целиком.
Что умею:
- управлять несколькими командами разработки, QA и DevOps одновременно;
- нанимать, увольнять и развивать людей;
- вместе с командой отвечать за архитектуру, инфраструктуру, production,
безопасность и инциденты;
- выстраивать понятный delivery - от проработки задач до релиза и отката;
- готовить и обосновывать технический бюджет;
- разговаривать с собственниками и продуктовой командой на языке целей,
приоритетов и рисков.
Немного масштаба: до четырёх одновременных кросс-функциональных команд, 22 прямых технических подчинённых, рост инженерной организации с 3 до 15 человек. В одном из проектов сократили деплой с максимум 90 до примерно 10 минут. В более ранних системах были нагрузки до 700 тыс. авторизаций в сутки и около 3 млн транзакций в месяц.
Работаю из Москвы, преимущественно удалённо. Возможны встречи и редкие командировки, релокация - нет. Ищу именно CTO-функцию, а не работу программистом с красивым названием должности.
Теперь самое интересное. Если вы лично порекомендуете меня человеку со стороны компании и эта рекомендация приведёт к подписанному договору, я выплачу вам 20% от своей первой полной выплаты.
Правило действует для любого договора: штат, ИП или проектная работа. Даже если до вашей рекомендации я уже самостоятельно откликнулся в эту компанию.
Чтобы зафиксировать рекомендацию, просто напишите мне название компании и кому вы меня представили. Если рекомендаций в одну компанию будет несколько, учитывается первая зафиксированная.
Резюме: https://bukreev.pro/resume
Правила и готовый текст для пересылки: https://bukreev.pro/recommend-cto
Telegram: https://t.me/abukreev
А ниже оставляю короткий текст, который можно просто переслать нужному человеку.
Многие из вас знают меня давно и именно как технического директора: я больше 20 лет работаю с web-системами, строю команды разработки и навожу порядок между «бизнесу нужно» и «разработка делает».
Сейчас ищу новый проект или постоянную работу в роли CTO. Лучше всего подойду действующему digital/web-бизнесу после MVP, где уже есть продукт, деньги на разработку и команда, но нужен человек, который возьмёт на себя технологическую функцию целиком.
Что умею:
- управлять несколькими командами разработки, QA и DevOps одновременно;
- нанимать, увольнять и развивать людей;
- вместе с командой отвечать за архитектуру, инфраструктуру, production,
безопасность и инциденты;
- выстраивать понятный delivery - от проработки задач до релиза и отката;
- готовить и обосновывать технический бюджет;
- разговаривать с собственниками и продуктовой командой на языке целей,
приоритетов и рисков.
Немного масштаба: до четырёх одновременных кросс-функциональных команд, 22 прямых технических подчинённых, рост инженерной организации с 3 до 15 человек. В одном из проектов сократили деплой с максимум 90 до примерно 10 минут. В более ранних системах были нагрузки до 700 тыс. авторизаций в сутки и около 3 млн транзакций в месяц.
Работаю из Москвы, преимущественно удалённо. Возможны встречи и редкие командировки, релокация - нет. Ищу именно CTO-функцию, а не работу программистом с красивым названием должности.
Теперь самое интересное. Если вы лично порекомендуете меня человеку со стороны компании и эта рекомендация приведёт к подписанному договору, я выплачу вам 20% от своей первой полной выплаты.
Правило действует для любого договора: штат, ИП или проектная работа. Даже если до вашей рекомендации я уже самостоятельно откликнулся в эту компанию.
Чтобы зафиксировать рекомендацию, просто напишите мне название компании и кому вы меня представили. Если рекомендаций в одну компанию будет несколько, учитывается первая зафиксированная.
Резюме: https://bukreev.pro/resume
Правила и готовый текст для пересылки: https://bukreev.pro/recommend-cto
Telegram: https://t.me/abukreev
А ниже оставляю короткий текст, который можно просто переслать нужному человеку.
Bukreev.Pro
Александр Букреев - технический директор (CTO)
CTO с 20+ годами в web-системах и инженерном управлении. До 4 команд, 22 прямых технических подчинённых, архитектура, delivery, production и бюджеты.
👍4🤣3❤1
Есть знакомый сильный CTO - Александр Букреев. Более 20 лет работает с
web-системами и инженерными командами. Управлял до четырёх одновременных
кросс-функциональных команд и 22 прямыми техническими подчинёнными; отвечал за
найм, архитектуру совместно с командой, delivery, production, безопасность
и технический бюджет.
Умеет выстраивать технологическую функцию в действующем digital-бизнесе:
масштабировал инженерную организацию с 3 до 15 человек, сокращал деплой
с максимум 90 до примерно 10 минут, руководил системами с нагрузкой до
700 тыс. авторизаций в сутки и около 3 млн транзакций в месяц.
Сейчас рассматривает CTO-позиции и проектную работу. Работает удалённо из
Москвы, возможны встречи и редкие командировки. Если вам или кому-то из ваших
знакомых нужен опытный CTO для уже работающего продукта и команды, можно
написать Александру напрямую:
Резюме: https://bukreev.pro/resume
Telegram: https://t.me/abukreev
web-системами и инженерными командами. Управлял до четырёх одновременных
кросс-функциональных команд и 22 прямыми техническими подчинёнными; отвечал за
найм, архитектуру совместно с командой, delivery, production, безопасность
и технический бюджет.
Умеет выстраивать технологическую функцию в действующем digital-бизнесе:
масштабировал инженерную организацию с 3 до 15 человек, сокращал деплой
с максимум 90 до примерно 10 минут, руководил системами с нагрузкой до
700 тыс. авторизаций в сутки и около 3 млн транзакций в месяц.
Сейчас рассматривает CTO-позиции и проектную работу. Работает удалённо из
Москвы, возможны встречи и редкие командировки. Если вам или кому-то из ваших
знакомых нужен опытный CTO для уже работающего продукта и команды, можно
написать Александру напрямую:
Резюме: https://bukreev.pro/resume
Telegram: https://t.me/abukreev
Bukreev.Pro
Александр Букреев - технический директор (CTO)
CTO с 20+ годами в web-системах и инженерном управлении. До 4 команд, 22 прямых технических подчинённых, архитектура, delivery, production и бюджеты.
🤣5❤4👎1🔥1
Мне тут добрый человечек @Sprytru подкинул ключик для опенроутера и попросил протестить еще несколько моделек.
ОБновленный рейтинг на экране.
Если что - я думал какая-то ошибка. Сначала перепроверил, потом еще раз запустил GPT SOL. Неа, ровно тот же результат получился…
Мимо.Про удивила. Как и Соннет 5 в начале тестов.
ОБновленный рейтинг на экране.
Если что - я думал какая-то ошибка. Сначала перепроверил, потом еще раз запустил GPT SOL. Неа, ровно тот же результат получился…
Мимо.Про удивила. Как и Соннет 5 в начале тестов.
👍6
Псилохог подсказал одну интересную особенность мозга… Послушал несколько лекций по этой теме. Появилась идея.
Я давно заметил закономерность: у меня не проблема с силой воли вообще, а с тем, чтобы просто начать - выйти на прогулку, дойти до бассейна, сесть за домашние дела. Одно и то же напоминание в календаре я могу игнорировать неделями… 🙂
Решил сделать личного Telegram-бота, который превращает рутину в игру. Не трекер для галочек, а что-то, что напоминает по-разному, принимает отчёт обычным текстом («5 рабочих задач закрыл, 2 домашних, 4300 шагов, дневник заполнил») и сразу считает баллы.
Ключевая мысль: не требовать идеального дня. Каждый день - это просто «сколько баллов получилось набрать». Частичный результат лучше нулевого, и один плохой день не рушит всю неделю.
В основе - принцип PINCH (Passion, Interest, Novelty, Challenge, Hurry): игра, личный контекст, еженедельная новизна оформления, вызов самому себе прошлому, и мягкая срочность вместо давления. Никакого стыда и чувства вины - только похвала, подколы и очередной раунд.
Те по сути - это обычный игровой процесс. Где нужно набрать максимальное количество балов за неделю.
Продолжение в следующей серии… :-))
Я давно заметил закономерность: у меня не проблема с силой воли вообще, а с тем, чтобы просто начать - выйти на прогулку, дойти до бассейна, сесть за домашние дела. Одно и то же напоминание в календаре я могу игнорировать неделями… 🙂
Решил сделать личного Telegram-бота, который превращает рутину в игру. Не трекер для галочек, а что-то, что напоминает по-разному, принимает отчёт обычным текстом («5 рабочих задач закрыл, 2 домашних, 4300 шагов, дневник заполнил») и сразу считает баллы.
Ключевая мысль: не требовать идеального дня. Каждый день - это просто «сколько баллов получилось набрать». Частичный результат лучше нулевого, и один плохой день не рушит всю неделю.
В основе - принцип PINCH (Passion, Interest, Novelty, Challenge, Hurry): игра, личный контекст, еженедельная новизна оформления, вызов самому себе прошлому, и мягкая срочность вместо давления. Никакого стыда и чувства вины - только похвала, подколы и очередной раунд.
Те по сути - это обычный игровой процесс. Где нужно набрать максимальное количество балов за неделю.
Продолжение в следующей серии… :-))
👍11🔥2👎1💩1🤡1
Forwarded from Alexander Bukreev
Лимиты Кодекса кончились. Лимиты Клода кончились. Выпускаем Кракена (GLM) :-)
😁2
Как это выглядит на практике.
Утром в 11:00 приходит план на день: шаги, рабочие/домашние задачи, ведение дневника, что осталось из недельных целей вроде бассейна. Если не ответить - придёт мягкое напоминание ещё пару раз, максимум три сообщения.
Вечером - один опрос, без повторов. Отвечаю обычным текстом, свободной формулировкой, в любом порядке фактов. Бот разбирает сообщение сам и досчитывает необходимое но не выдумывает цифры, только уточняющий вопрос, если данных мало.
Каждый четверг стартует новый недельный раунд ровно на 7 дней, с отдельным отчётом за прошлую неделю: сумма баллов, разбивка по дням и активностям, средние шаги, посещения бассейна, прогресс. Раунд каждую неделю получает новую игровую обёртку: не сами правила, а подача и формулировки, чтобы не приедалось.
Баллы начисляются по чётким таблицам: сон, питание, шаги, рабочие и домашние задачи, дневник, плавание - у каждого свой диапазон и свой «вес». Плановый максимум недели фиксированный, а дополнительные заплывы сверх плана дают бонусные баллы, которые могут компенсировать слабый день - это разрешённое «читерство» в игре с самим собой.
Продожение в следующей серии (Технические подробности)… 🙂
Утром в 11:00 приходит план на день: шаги, рабочие/домашние задачи, ведение дневника, что осталось из недельных целей вроде бассейна. Если не ответить - придёт мягкое напоминание ещё пару раз, максимум три сообщения.
Вечером - один опрос, без повторов. Отвечаю обычным текстом, свободной формулировкой, в любом порядке фактов. Бот разбирает сообщение сам и досчитывает необходимое но не выдумывает цифры, только уточняющий вопрос, если данных мало.
Каждый четверг стартует новый недельный раунд ровно на 7 дней, с отдельным отчётом за прошлую неделю: сумма баллов, разбивка по дням и активностям, средние шаги, посещения бассейна, прогресс. Раунд каждую неделю получает новую игровую обёртку: не сами правила, а подача и формулировки, чтобы не приедалось.
Баллы начисляются по чётким таблицам: сон, питание, шаги, рабочие и домашние задачи, дневник, плавание - у каждого свой диапазон и свой «вес». Плановый максимум недели фиксированный, а дополнительные заплывы сверх плана дают бонусные баллы, которые могут компенсировать слабый день - это разрешённое «читерство» в игре с самим собой.
Продожение в следующей серии (Технические подробности)… 🙂
🔥7👍1😁1
Стек нарочно простой: Python-бот на Telegram Bot API (polling, без вебхуков), SQLite для всего состояния, Docker Compose для развёртывания на домашнем сервере.
Главный принцип архитектуры - разделение вероятностного и детерминированного. LLM (OpenAI Responses API, structured output) отвечает только за то, что действительно требует понимания языка: разобрать свободный русский текст в строгую схему (Pydantic), сформулировать похвалу, добавить недельному отчёту немного «человечности», иногда придумать новую тему раунда. Модель никогда не считает баллы, не хранит состояние и не имеет права отрицать то, что уже сохранено в базе - при обычном разговоре ей передаётся точный контекст из SQLite, и по нему она обязана сверяться.
Вся арифметика баллов живёт в одном модуле без единого обращения к LLM. Она детерминирована и покрыта тестами, а документация формул синхронизирована с кодом как источник истины.
Из инженерных деталей: обработка Telegram update идемпотентна по update_id, чтобы повторная доставка не начисляла баллы дважды; частичные отчёты - это upsert, неназванные поля не затираются; запись в уже закрытую неделю блокируется на уровне сервиса; плановые рассылки (утро/вечер/бэкап) идемпотентны через таблицу отправленных сообщений, что переживает рестарт контейнера.
Ежедневный бэкап SQLite с ретеншеном настроен отдельной джобой.
Ну, типа все 🙂
Главный принцип архитектуры - разделение вероятностного и детерминированного. LLM (OpenAI Responses API, structured output) отвечает только за то, что действительно требует понимания языка: разобрать свободный русский текст в строгую схему (Pydantic), сформулировать похвалу, добавить недельному отчёту немного «человечности», иногда придумать новую тему раунда. Модель никогда не считает баллы, не хранит состояние и не имеет права отрицать то, что уже сохранено в базе - при обычном разговоре ей передаётся точный контекст из SQLite, и по нему она обязана сверяться.
Вся арифметика баллов живёт в одном модуле без единого обращения к LLM. Она детерминирована и покрыта тестами, а документация формул синхронизирована с кодом как источник истины.
Из инженерных деталей: обработка Telegram update идемпотентна по update_id, чтобы повторная доставка не начисляла баллы дважды; частичные отчёты - это upsert, неназванные поля не затираются; запись в уже закрытую неделю блокируется на уровне сервиса; плановые рассылки (утро/вечер/бэкап) идемпотентны через таблицу отправленных сообщений, что переживает рестарт контейнера.
Ежедневный бэкап SQLite с ретеншеном настроен отдельной джобой.
Ну, типа все 🙂
👌2😁1🤩1😐1
Гугл в строку поиска воткнул кнопку «Режим ИИ». Я так понимаю скоро вполне себе этот режим станет режимом по умолчанию, вместо «Поиск в Google».
Ну или не станет. Я ж эксперт - должен все возможные варианты озвучивать :-)))
50/50 короче.
Из интересного: если задать запрос, то в режиме «Поиск в Google» будет блок с ИИ-ответом и там указаны источники откуда взята информация.
Если тот же запрос пульнуть в «Режим ИИ» - там будет более полная/подробная информация БЕЗ ссылок на источники. те из этого режима даже при цитируемости вебмастера трафика не получат совсем..
Круто, счастье, ЗБС :-)
Ну или не станет. Я ж эксперт - должен все возможные варианты озвучивать :-)))
50/50 короче.
Из интересного: если задать запрос, то в режиме «Поиск в Google» будет блок с ИИ-ответом и там указаны источники откуда взята информация.
Если тот же запрос пульнуть в «Режим ИИ» - там будет более полная/подробная информация БЕЗ ссылок на источники. те из этого режима даже при цитируемости вебмастера трафика не получат совсем..
Круто, счастье, ЗБС :-)
🤩1
‼️ Рунету сегодня нехорошо. И, похоже, причина довольно железная. В буквальном смысле.
Вечером посыпались жалобы сразу на десятки совершенно не связанных между собой сервисов: банки, маркетплейсы, операторов связи, VK, Steam, Discord, онлайн-кинотеатры и прочее. Жалобы идут из разных регионов России.
Почти одновременно в Москве погас свет в нескольких районах. Сообщалось о проблемах в Гагаринском, Даниловском районе, Замоскворечье и районе Октябрьской. Были проблемы с мобильной связью, магазинами, транспортом. На Калужско-Рижской линии метро некоторое время увеличивали интервалы движения.
А теперь самое интересное.
Мне тут злые языки подсказали: смотрите в сторону Бутлерова, 7.
Для тех, кому адрес ничего не говорит: это ММТС-9, она же M9.
И вот это уже не просто "где-то дата-центр моргнул".
M9 - одна из ключевых телекоммуникационных площадок российского интернета. Там сконцентрировано огромное количество операторского оборудования и межоператорских соединений. Там же находится площадка MSK-IX. Сам MSK-IX в свое время называл Бутлерова, 7 самой востребованной в России локацией для межоператорского взаимодействия - на ней присутствовали сотни операторов.
И сообщения об аварии с электропитанием на M9 действительно есть. Некоторые хостеры уже сообщили клиентам о проблемах с питанием и деградации связности на площадке.
По одной из появившихся технических версий, сначала произошёл сбой в московской энергосистеме, после чего проблемы зацепили в том числе инфраструктуру в районе M9. Именно это могло дать такой красивый каскад: электричество → операторские узлы → маршрутизация/связность → одновременно "падают" десятки вообще не связанных между собой сервисов.
Но тут аккуратно: окончательно эту причинно-следственную цепочку пока никто официально не подтвердил. Так что пока это наиболее логичная рабочая версия, а не установленная причина.
И маленький технический нюанс.
Фраза "упала точка обмена трафиком и поэтому упал Рунет" - слишком примитивное объяснение. Интернет так не устроен, MSK-IX вообще географически распределён, маршруты резервируются, питание резервируется и все взрослые люди заранее готовятся к отказам.
Но когда проблемы возникают на площадке такой концентрации инфраструктуры, как M9, эффект получается очень заметным.
Что мы сегодня, собственно, и наблюдаем.
Судя по сообщениям, электричество и часть сервисов уже возвращаются. Теперь будет интересно дождаться нормального технического разбора аварии.
Потому что если версия про M9 подтвердится, главный вопрос будет уже не "почему упало", а почему резервирование не спасло от настолько массового эффекта. 🙂
Причем резервирование питания именно на этой точке - МНОГОКРАТНОЕ.
Интересно, какое количество полыхающих поп будет завтра на совещаниях и разборах…
Вечером посыпались жалобы сразу на десятки совершенно не связанных между собой сервисов: банки, маркетплейсы, операторов связи, VK, Steam, Discord, онлайн-кинотеатры и прочее. Жалобы идут из разных регионов России.
Почти одновременно в Москве погас свет в нескольких районах. Сообщалось о проблемах в Гагаринском, Даниловском районе, Замоскворечье и районе Октябрьской. Были проблемы с мобильной связью, магазинами, транспортом. На Калужско-Рижской линии метро некоторое время увеличивали интервалы движения.
А теперь самое интересное.
Мне тут злые языки подсказали: смотрите в сторону Бутлерова, 7.
Для тех, кому адрес ничего не говорит: это ММТС-9, она же M9.
И вот это уже не просто "где-то дата-центр моргнул".
M9 - одна из ключевых телекоммуникационных площадок российского интернета. Там сконцентрировано огромное количество операторского оборудования и межоператорских соединений. Там же находится площадка MSK-IX. Сам MSK-IX в свое время называл Бутлерова, 7 самой востребованной в России локацией для межоператорского взаимодействия - на ней присутствовали сотни операторов.
И сообщения об аварии с электропитанием на M9 действительно есть. Некоторые хостеры уже сообщили клиентам о проблемах с питанием и деградации связности на площадке.
По одной из появившихся технических версий, сначала произошёл сбой в московской энергосистеме, после чего проблемы зацепили в том числе инфраструктуру в районе M9. Именно это могло дать такой красивый каскад: электричество → операторские узлы → маршрутизация/связность → одновременно "падают" десятки вообще не связанных между собой сервисов.
Но тут аккуратно: окончательно эту причинно-следственную цепочку пока никто официально не подтвердил. Так что пока это наиболее логичная рабочая версия, а не установленная причина.
И маленький технический нюанс.
Фраза "упала точка обмена трафиком и поэтому упал Рунет" - слишком примитивное объяснение. Интернет так не устроен, MSK-IX вообще географически распределён, маршруты резервируются, питание резервируется и все взрослые люди заранее готовятся к отказам.
Но когда проблемы возникают на площадке такой концентрации инфраструктуры, как M9, эффект получается очень заметным.
Что мы сегодня, собственно, и наблюдаем.
Судя по сообщениям, электричество и часть сервисов уже возвращаются. Теперь будет интересно дождаться нормального технического разбора аварии.
Потому что если версия про M9 подтвердится, главный вопрос будет уже не "почему упало", а почему резервирование не спасло от настолько массового эффекта. 🙂
Причем резервирование питания именно на этой точке - МНОГОКРАТНОЕ.
Интересно, какое количество полыхающих поп будет завтра на совещаниях и разборах…
🤮1