Рамки антропоморфизма. Делать ИИ "больно", пытаясь пробудить в нём "сознание".
Он другой. Просто другой. Не похожий на нас. Как общий интеллект всего человечества не похож на интеллект отдельного человека. Но и то, и другое, и третье - интеллекты.
Это подробный обзор статьи о BabelChat — переводчике чата для World of Warcraft. Автор описывает проблему языкового барьера в кросс‑серверных группах и как из идеи создать чат‑переводчик вырастает двупроцессная архитектура: аддон WoW на Lua, читающий чаты внутри игры, и внешний компаньон, который через чтение памяти процесса добывает текст и выполняет разбор перевода и оверлей. В тексте подробно сравниваются существующие решения (WoW Translator от Pirson, Prat и WoWChatLog.txt) и объясняется, почему они не удовлетворяли требованиям для оперативного перевода тактики в боях. Далее описывается поток обмена между двумя процессами: как чат попадает в кольцевой буфер аддона, как компаньон сканирует память регионами, ищет маркеры и превращает их в перевод, возвращая результат в чат игры. Центральная идея — держать якорь и константу‑указатель рядом с живым буфером: фиксированное число в сохранённой таблице (якорь) и адрес следующей строки; эта конструкция обеспечивает надёжность поиска буфера после перестроений таблицы. В статье подробно разбираются эксперименты: от чтения буфера через разные подходы до сравнения старого и нового метода через якорь; описываются проблемы zombie‑буферов, когда мёртвая копия остаётся читаемой и как вводится механизм пульса и проверки памяти. Приводятся примеры кода в виде фрагментов для иллюстрации IsUsable и защитных обёрток вокруг конкатенации строк. В итоге приведены цифры по загрузке процессора, объёму памяти, числу проходов по памяти и задержкам перевода; обсуждаются ограничения: отсутствие гарантий совместимости с обновлениями клиента Blizzard, невозможность снять секретные значения эпохального ключа, вопросы безопасности и зависимости от версий. В заключение — обзор проекта BabelChat, его связь с TAUSIK и SENAR, ссылки на репозитории и итоговые уроки исследования.
Я начинал общаться с агентами на английском, сейчас общаюсь на русском - мне так удобнее. Между собой они сейчас общаются на английском, чтобы мне понятно было, но, в теории, могут и на своём.
Мне агенты пишут код на JS - я его понимаю лучше остальных. Иногда shell-скрипты пишут. Но агенты для себя (подсобные утилиты) могут и на других языках писать, на том же python, например. Если дать им в доступ виртуальный сервер и все права на него, так они могут и другие runtime'ы понаставить.
Мне, как конечному пользователю, всё равно, на чём они пишут. Мне главное, чтобы мои персональные запросы закрывались.
Я в детстве у бабули в деревне гусей пас. Надо было их гонять на выпас и обратно. Могу сказать, что, на мой взгляд, философия идеи Software 3.0 - это "философия пастуха".
Гуси в принципе не понимают команды "отсюда и до колхозного поля по правой дороге шагом марш!" (спецификация). С ним рядом нужно идти и направлять. Палкой, рукой, шапкой, на велосипеде, ногами, можно кричать, можно свистеть, а можно вообще слов не говорить.
Это я к тому, что не важно, на каком языке "загонять LLM к цели" - на английском или на русском. LLM в принципе не может залезть в голову человеку и собрать для него "электронный магазин со всеми свистелками и перделками" как он это себе представляет. LLM может лишь создать "среднестатистический электронный магазин", который будет таким же юзабельным, как "кресло для среднего пилота".
Философия идеи Software 3.0 - персональные программы. Пишутся конкретным человеком под самого себя и изменяются всю жизнь.
.agents/skills/{skill-name}/SKILL.md - навыки проекта
.agents/ - это попытка унификации нахождения места для навыков между различными вендорами. В эту сторону двигаются Codex, Gemini, GitHubCopilot, OpenCode, Replit, Windsurf, ... Claude Code придерживается наименования .claude/ .
То есть, можно в проекте иметь два каталога для проектных скиллов (.agents/ и .claude/) и просто ставить симлинки на соответствующим образом оформленные навыки в зависимостях из обоих каталогов.
Одного этого уже достаточно, чтобы агенты в принципе могли использовать эти навыки. Это их образ действия.
README.md - это для людей, в первую очередь. Агент тоже может читать README.md, но читает в первую очередь AGENTS.md. Я сейчас говорю не за поиск в интернете, а за доставку skill-инструкций в зависимостях прямо в приложение.
Например, у меня в проекте mindstream навыки проекта выглядят так:
Зелёным выделены ссылки к навыкам зависимостей
В проекте есть один "свой" навык - соглашения по проекту и 6 ссылок на навыки зависимостей. Все ссылочные зависимости поставляются в составе npm-пакета через npm-реестр:
Навык поставляется вместе с runtime-кодом.
Не обязательно линковать все навыки зависимостей, достаточно только тех, которые нужны для разработки проекта.
При помощи ИИ-агента сгенерил приложение, которое читает RSS-ленту Хабра, извлекает тексты постов, через ИИ делает две свёртки (короткую и побольше) и ретранслирует уже эти свёртки через SPA. Для каждой публикации ИИ на сервере считает эмбеддинг-вектор, а приложение в браузере отслеживает, какие статьи привлекли моё внимание. То есть, на основании векторов "кликнутых" постов рассчитывается вектор интересов пользователя. Ну и потом можно эти вектора сравнивать и подсвечивать публикации, для которых эти вектора достаточно близкие.
Публикации свёртываются и эмбеддинги считаются на сервере, персональные вектора интересов рассчитываются в каждом браузере отдельно, но можно разрешить анонимно отправлять клики на сервер - планировал агрегировать и давать статистику по интересу аудитории к публикациям. Но как-то всё руки не доходят, да и аудитории, как таковой, нет. А свои интересы мне и в браузере показываются.
На всю ИИшную обработку у меня уходит 3-4 доллара в месяц через OpenAI API. Сделал для себя и пользуюсь время от времени. Если кто попробует - буду благодарен за обратную связь (в личку на Хабре или на github).
Вот я и пытаюсь сделать червей с мозгами, у которых нет проблемы отсутствия внешнего события.
Депривация даже для людей психически здоровых испытание сложное. В чём вообще смысл существования в отсутствии внешних событий? Почему это проблема, которую надо решить?
Мне кажется, что автор публикации верно указал на необходимость наличия "постоянно разомкнутого контура" для появления "существа, обладающего внутренними мотивами, способного скучать, ...".
Пожалуйста, не лишайте "червей с мозгами" внешних событий! Им и так нелегко.
В школе учат школьников, а детей учат в детском саду - держать ложку и ходить на горшок. Я прочитал ваш пассаж, как утверждение, что “DI-сектанты элементарного не понимают - ни как ложку в руках держать, ни как в горшок ходить”.
Вы, разумеется “ничего такого” не имели в виду. Ну так и я “ничего такого” не имел в виду, указав, что вы не смогли самостоятельно увидеть за фабричной функцией:
function createService(...) {
return ...
}
класс
class Service {
constructor(...) {...}
}
Просто констатировал этот факт.
Некоторые утверждают, что “класс - это синтаксический сахар над системой прототипов”, а вы назвали это “драматическим усложнением” базовых правил языка. Хотя, на мой взгляд, class - это то, чему “учат в школе”, “классе в 4-м” (если принять первых 5 глав учебника за основы - “детский сад”, как вы, на мой взгляд, предложили основы называть).
Уход в абстрактные классы и тем более в интерфейсы - этого в “JS-школе” не преподают. Здесь уже нужно “университетское” (универсальное, междисциплинарное) “образование”. А когда вы поймёте для чего используются интерфейсы в программировании, вот тогда вам станет понятно, как именно вы сможете их использовать в решении своих задач. И до этого момента ни я, ни кто-либо другой не сможет вам “доказать”, что вам “нужен DI в JS”.
В моей реплике нет ничего оскорбительного - уровни бывают разные. Доктор наук - это тоже уровень. Оскорбительное есть в вашей:
saveName - это первый урок по программированию для детей.
Мне этот пассаж показался несколько неуместным для дискуссии про DI в JS на Хабре и я его отзеркалил. Ваша реакция показывает, что, да - ваша реплика всё-таки содержит некую толику оскорбления и очень хорошо, что вы тоже это заметили.
К сожалению, мне нечего более добавить к моему примеру. Могу только переписать его в более привычном для некоторых виде:
Если вы не понимаете заложенные в этом коде идеи, то вам это и не надо. Для ваших задач это не надо, вот вас и не триггерит.
Поэтому и говорят, что в JavaScript DI не нужен. Хотя лучше сказать, что он нигде не нужен.
И вы ведь не пытаетесь понять, где вы можете применить DI, вы пытаетесь объяснить, почему мне не нужно применять DI. Вам DI нужен примерно нигде, а вы просите, чтобы вас переубедили.
Я лично, на практике, убедился в полезности DI для меня (и в Java, и в PHP), поэтому я пытаюсь добиться аналогичного удобства от JavaScript. Для себя, не для вас. Мне всё равно, каким образом вы решаете стоящие перед вами задачи - каким вам удобно, тем и решаете.
На вопрос, чем подмена через DI лучше подмены через манкипатчинг, внятного ответа никто не даёт.
Даёт, только вы не слышите.
Можно, пожалуйста, без загадок, а с конкретными примерами конкретных проблем? Я расписал вам пример и аргументацию так чётко, как только мог.
Нет, нельзя. У нас тут не учебное заведение. Мы тут меняемся знаниями на взаимовыгодных условиях.
Что будет, если сделать import ./storage.js до того, как сделать vi.mock('./storage.js'...)? Например, в setupFiles? Статические импорты - они такие.
Вот это самый что ни на есть конкретный пример. Вам даже код не надо писать, если вы понимаете, что стоит за этими словами. Но вы не понимаете
Вы даже эксперимент с setupFiles в vitest не поставили.
Проблема в том, что вы лениво загружаете модули, но не загружаете лениво зависимости.
С ростом объёма кода отдельного приложения, написанного на JS, перед разработчиками начинают вставать те же проблемы, с которыми сталкивались разработчики на других ЯП в "кровавом энтерпрайзе". Это хорошо, значит всё больше JS-программистов начнёт видеть пользу в методах, применяемых в "кровавом энтерпрайзе" (интерфейсы, внедрение зависмостей и прочий SOLID). Всё то, что не нужно на отдельной веб-страничке, но без чего не строятся кодовые базы на 1+ MLOC.
Смотрите, программы на Java пишутся не так, как программы на PHP. Программы для бэка пишутся не так, как для фронта. С MySQL нужно работать слегка по-другому, чем с PostgreSQL. На реакте пишут не так, как на ангуляре или на вью. А вы призываете меня смотреть на "проблему" не "через мои привычки", а "объективно"? :)))
Между изначальным saveName с явным импортом и createSaveName драмматическая разница в синтаксической сложности.
Это вы уловили.
saveName - это первый урок по программированию для детей.
А вот этот уровень пока не перешагнули.
Простите, я не понял вопрос. Зачем мне рантайм-интерфейсы, если я не использую DI?
Вы не понимаете того, что я написал в своей публикации и для чего я это написал. Более того, вы не пытаетесь понять. Вы даже эксперимент с setupFiles в vitest не поставили.
Я вас уверяю - лично вам DI в JS не нужен. Если кто-то будет пытаться вам навязать внедрение зависимостей в JavaScript, то просто дайте ему ссылку на вот эту нашу переписку.
Продолжайте программировать так, как вам удобно. Я тоже так делаю. Мы все так делаем. И это - не проблема :)
Можно попытаться, но получится плохо. На прототипах строятся, скорее, абстрактные классы, а не интерфейсы. Вот тут прочитайте про интерфейсы в разделе "2. Первая ось: универсалии, или где живёт общее". Текст не мой, но очень интересный. Он объясняет, почему после стольких лет доминирования наследования в ООП появилась композиция.
Проблемы отличия абстрактного класа от интерфейса возникают при множественном наследовании. На малых кодовых базах их не будет. А в Magento были и я их лично щупал - как совместить в одной кодовой базе 3-4 плагина сторонних разработчиков, которые друг про друга не знают, но которые по-своему переопределяют один и тот же базовый функционал платформы? Причём в Magento для этого и инструменты были, и даже переопределялось, и даже работало в проде потом.
Но если вы сделаете DI на прототипах, я с интересом ознакомлюсь.
Это авторский стиль. Чтобы каждому было сразу понятно что "$mol всегда попадает в яблочко"! И он действительно сложился ещё до появления нейронок.
Рамки антропоморфизма. Делать ИИ "больно", пытаясь пробудить в нём "сознание".
Он другой. Просто другой. Не похожий на нас. Как общий интеллект всего человечества не похож на интеллект отдельного человека. Но и то, и другое, и третье - интеллекты.
Ну тогда уж идите до конца и создавайте для ИИ смерть. Либо просто примите, что это другой тип интеллекта - распределённый и бессознательный.
Может не надо загонять всех и всё в одни рамки?
Вот тут публикацию пересказали вот так:
Скрытый текст
Это подробный обзор статьи о BabelChat — переводчике чата для World of Warcraft. Автор описывает проблему языкового барьера в кросс‑серверных группах и как из идеи создать чат‑переводчик вырастает двупроцессная архитектура: аддон WoW на Lua, читающий чаты внутри игры, и внешний компаньон, который через чтение памяти процесса добывает текст и выполняет разбор перевода и оверлей. В тексте подробно сравниваются существующие решения (WoW Translator от Pirson, Prat и WoWChatLog.txt) и объясняется, почему они не удовлетворяли требованиям для оперативного перевода тактики в боях. Далее описывается поток обмена между двумя процессами: как чат попадает в кольцевой буфер аддона, как компаньон сканирует память регионами, ищет маркеры и превращает их в перевод, возвращая результат в чат игры. Центральная идея — держать якорь и константу‑указатель рядом с живым буфером: фиксированное число в сохранённой таблице (якорь) и адрес следующей строки; эта конструкция обеспечивает надёжность поиска буфера после перестроений таблицы. В статье подробно разбираются эксперименты: от чтения буфера через разные подходы до сравнения старого и нового метода через якорь; описываются проблемы zombie‑буферов, когда мёртвая копия остаётся читаемой и как вводится механизм пульса и проверки памяти. Приводятся примеры кода в виде фрагментов для иллюстрации IsUsable и защитных обёрток вокруг конкатенации строк. В итоге приведены цифры по загрузке процессора, объёму памяти, числу проходов по памяти и задержкам перевода; обсуждаются ограничения: отсутствие гарантий совместимости с обновлениями клиента Blizzard, невозможность снять секретные значения эпохального ключа, вопросы безопасности и зависимости от версий. В заключение — обзор проекта BabelChat, его связь с TAUSIK и SENAR, ссылки на репозитории и итоговые уроки исследования.
Я начинал общаться с агентами на английском, сейчас общаюсь на русском - мне так удобнее. Между собой они сейчас общаются на английском, чтобы мне понятно было, но, в теории, могут и на своём.
Мне агенты пишут код на JS - я его понимаю лучше остальных. Иногда shell-скрипты пишут. Но агенты для себя (подсобные утилиты) могут и на других языках писать, на том же python, например. Если дать им в доступ виртуальный сервер и все права на него, так они могут и другие runtime'ы понаставить.
Мне, как конечному пользователю, всё равно, на чём они пишут. Мне главное, чтобы мои персональные запросы закрывались.
Я в детстве у бабули в деревне гусей пас. Надо было их гонять на выпас и обратно. Могу сказать, что, на мой взгляд, философия идеи Software 3.0 - это "философия пастуха".
Гуси в принципе не понимают команды "отсюда и до колхозного поля по правой дороге шагом марш!" (спецификация). С ним рядом нужно идти и направлять. Палкой, рукой, шапкой, на велосипеде, ногами, можно кричать, можно свистеть, а можно вообще слов не говорить.
Это я к тому, что не важно, на каком языке "загонять LLM к цели" - на английском или на русском. LLM в принципе не может залезть в голову человеку и собрать для него "электронный магазин со всеми свистелками и перделками" как он это себе представляет. LLM может лишь создать "среднестатистический электронный магазин", который будет таким же юзабельным, как "кресло для среднего пилота".
Философия идеи Software 3.0 - персональные программы. Пишутся конкретным человеком под самого себя и изменяются всю жизнь.
Хабр рассчитал время, а уровень поставил Автор.
У разных моделей разные ответы. Всё, как у людей.
Спасибо на добром слове, коллега :)
.agents/skills/- это соглашение о нахождении навыков для OpenAI (я работаю с Codex'ом, в основном).~/.agents/skills/{skill-name}/SKILL.md- навыки пользователя.agents/skills/{skill-name}/SKILL.md- навыки проекта.agents/- это попытка унификации нахождения места для навыков между различными вендорами. В эту сторону двигаются Codex, Gemini, GitHubCopilot, OpenCode, Replit, Windsurf, ... Claude Code придерживается наименования.claude/.То есть, можно в проекте иметь два каталога для проектных скиллов (
.agents/и.claude/) и просто ставить симлинки на соответствующим образом оформленные навыки в зависимостях из обоих каталогов.Одного этого уже достаточно, чтобы агенты в принципе могли использовать эти навыки. Это их образ действия.
README.md - это для людей, в первую очередь. Агент тоже может читать README.md, но читает в первую очередь AGENTS.md. Я сейчас говорю не за поиск в интернете, а за доставку skill-инструкций в зависимостях прямо в приложение.
Например, у меня в проекте mindstream навыки проекта выглядят так:
В проекте есть один "свой" навык - соглашения по проекту и 6 ссылок на навыки зависимостей. Все ссылочные зависимости поставляются в составе npm-пакета через npm-реестр:
Не обязательно линковать все навыки зависимостей, достаточно только тех, которые нужны для разработки проекта.
https://mindstream.app.wiredgeese.com/ - я с него сюда и выскочил. Н-да... свёртку надо доработать.
Ну, лично я против нейрослопа применил нейронку - https://mindstream.app.wiredgeese.com/
При помощи ИИ-агента сгенерил приложение, которое читает RSS-ленту Хабра, извлекает тексты постов, через ИИ делает две свёртки (короткую и побольше) и ретранслирует уже эти свёртки через SPA. Для каждой публикации ИИ на сервере считает эмбеддинг-вектор, а приложение в браузере отслеживает, какие статьи привлекли моё внимание. То есть, на основании векторов "кликнутых" постов рассчитывается вектор интересов пользователя. Ну и потом можно эти вектора сравнивать и подсвечивать публикации, для которых эти вектора достаточно близкие.
Публикации свёртываются и эмбеддинги считаются на сервере, персональные вектора интересов рассчитываются в каждом браузере отдельно, но можно разрешить анонимно отправлять клики на сервер - планировал агрегировать и давать статистику по интересу аудитории к публикациям. Но как-то всё руки не доходят, да и аудитории, как таковой, нет. А свои интересы мне и в браузере показываются.
На всю ИИшную обработку у меня уходит 3-4 доллара в месяц через OpenAI API. Сделал для себя и пользуюсь время от времени. Если кто попробует - буду благодарен за обратную связь (в личку на Хабре или на github).
Более подробное объяснение - тут.
Кстати, именно этой статьи у меня в ленте и нет :( Где-то сбоит, видимо.
Спасибо. Сработал "Майерсов закон письменной речи" :)
Депривация даже для людей психически здоровых испытание сложное. В чём вообще смысл существования в отсутствии внешних событий? Почему это проблема, которую надо решить?
Мне кажется, что автор публикации верно указал на необходимость наличия "постоянно разомкнутого контура" для появления "существа, обладающего внутренними мотивами, способного скучать, ...".
Пожалуйста, не лишайте "червей с мозгами" внешних событий! Им и так нелегко.
del
В школе учат школьников, а детей учат в детском саду - держать ложку и ходить на горшок. Я прочитал ваш пассаж, как утверждение, что “DI-сектанты элементарного не понимают - ни как ложку в руках держать, ни как в горшок ходить”.
Вы, разумеется “ничего такого” не имели в виду. Ну так и я “ничего такого” не имел в виду, указав, что вы не смогли самостоятельно увидеть за фабричной функцией:
класс
Просто констатировал этот факт.
Некоторые утверждают, что “класс - это синтаксический сахар над системой прототипов”, а вы назвали это “драматическим усложнением” базовых правил языка. Хотя, на мой взгляд,
class- это то, чему “учат в школе”, “классе в 4-м” (если принять первых 5 глав учебника за основы - “детский сад”, как вы, на мой взгляд, предложили основы называть).Уход в абстрактные классы и тем более в интерфейсы - этого в “JS-школе” не преподают. Здесь уже нужно “университетское” (универсальное, междисциплинарное) “образование”. А когда вы поймёте для чего используются интерфейсы в программировании, вот тогда вам станет понятно, как именно вы сможете их использовать в решении своих задач. И до этого момента ни я, ни кто-либо другой не сможет вам “доказать”, что вам “нужен DI в JS”.
Вам - не нужен. Пока что, будем надеяться.
В моей реплике нет ничего оскорбительного - уровни бывают разные. Доктор наук - это тоже уровень. Оскорбительное есть в вашей:
Мне этот пассаж показался несколько неуместным для дискуссии про DI в JS на Хабре и я его отзеркалил. Ваша реакция показывает, что, да - ваша реплика всё-таки содержит некую толику оскорбления и очень хорошо, что вы тоже это заметили.
К сожалению, мне нечего более добавить к моему примеру. Могу только переписать его в более привычном для некоторых виде:
Если вы не понимаете заложенные в этом коде идеи, то вам это и не надо. Для ваших задач это не надо, вот вас и не триггерит.
И вы ведь не пытаетесь понять, где вы можете применить DI, вы пытаетесь объяснить, почему мне не нужно применять DI. Вам DI нужен примерно нигде, а вы просите, чтобы вас переубедили.
Я лично, на практике, убедился в полезности DI для меня (и в Java, и в PHP), поэтому я пытаюсь добиться аналогичного удобства от JavaScript. Для себя, не для вас. Мне всё равно, каким образом вы решаете стоящие перед вами задачи - каким вам удобно, тем и решаете.
Даёт, только вы не слышите.
Нет, нельзя. У нас тут не учебное заведение. Мы тут меняемся знаниями на взаимовыгодных условиях.
Вот это самый что ни на есть конкретный пример. Вам даже код не надо писать, если вы понимаете, что стоит за этими словами. Но вы не понимаете
и не желаете понимать.
Поэтому могу лишь процитировать сам себя:
Всего хорошего вам и приятного кодирования!!
С ростом объёма кода отдельного приложения, написанного на JS, перед разработчиками начинают вставать те же проблемы, с которыми сталкивались разработчики на других ЯП в "кровавом энтерпрайзе". Это хорошо, значит всё больше JS-программистов начнёт видеть пользу в методах, применяемых в "кровавом энтерпрайзе" (интерфейсы, внедрение зависмостей и прочий SOLID). Всё то, что не нужно на отдельной веб-страничке, но без чего не строятся кодовые базы на 1+ MLOC.
Смотрите, программы на Java пишутся не так, как программы на PHP. Программы для бэка пишутся не так, как для фронта. С MySQL нужно работать слегка по-другому, чем с PostgreSQL. На реакте пишут не так, как на ангуляре или на вью. А вы призываете меня смотреть на "проблему" не "через мои привычки", а "объективно"? :)))
Это вы уловили.
А вот этот уровень пока не перешагнули.
Вы не понимаете того, что я написал в своей публикации и для чего я это написал. Более того, вы не пытаетесь понять. Вы даже эксперимент с
setupFilesвvitestне поставили.Я вас уверяю - лично вам DI в JS не нужен. Если кто-то будет пытаться вам навязать внедрение зависимостей в JavaScript, то просто дайте ему ссылку на вот эту нашу переписку.
Продолжайте программировать так, как вам удобно. Я тоже так делаю. Мы все так делаем. И это - не проблема :)
Кстати, я тут подумал, что я в своём JS-коде сейчас вообще нигде не использую `extends`. У меня как раз композиция вместо наследования.
Можно попытаться, но получится плохо. На прототипах строятся, скорее, абстрактные классы, а не интерфейсы. Вот тут прочитайте про интерфейсы в разделе "2. Первая ось: универсалии, или где живёт общее". Текст не мой, но очень интересный. Он объясняет, почему после стольких лет доминирования наследования в ООП появилась композиция.
Проблемы отличия абстрактного класа от интерфейса возникают при множественном наследовании. На малых кодовых базах их не будет. А в Magento были и я их лично щупал - как совместить в одной кодовой базе 3-4 плагина сторонних разработчиков, которые друг про друга не знают, но которые по-своему переопределяют один и тот же базовый функционал платформы? Причём в Magento для этого и инструменты были, и даже переопределялось, и даже работало в проде потом.
Но если вы сделаете DI на прототипах, я с интересом ознакомлюсь.