[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"article-86-fr":3,"related-86":72,"ArticleBody_HSdTiOYJDxVAYxTvrOGPtiT5zNa99flwG9D6JlA":232},{"id":4,"title":5,"slug":6,"content":7,"metaTitle":5,"metaDescription":8,"coverUrl":9,"views":10,"likes":11,"createdAt":12,"updatedAt":13,"category":14,"tags":23,"author":9,"tableOfContents":40,"locale":69,"translated":70,"indexable":71},86,"ИИ в технической работе: где помогает, а где нельзя доверять","ii-v-tehnicheskoy-rabote-gde-pomogaet-a-gde-nelzya-doveryat","# ИИ в технической работе: где помогает, а где нельзя доверять\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n>Так, ну тут будут статьи для вайба, большие тех статьи уже окончены, поэтому я буду здесь разбирать чуть другие темы без особого углубления и ссылаться на свой опыт часто.\n\nКидаешь модели чужой конфиг на семьдесят строк, просишь разобрать по полям - получаешь толковый разбор, лучше половины гайдов. Просишь на следующем сообщении собрать такой же конфиг с нуля - получаешь красивый рабочий на вид файл, в котором два поля вырезали из проекта пару лет назад.\n\nОдна и та же модель, один и тот же предмет, соседние сообщения. Результат в первом случае отличный, во втором вредный.\n\nРазница не в сложности задачи и не в везении. Она проходит по одной-единственной линии, и если её увидеть, то дальше становится понятно вообще всё: и где этой штуке можно доверять почти без оглядки, и где нельзя доверять ни единой строчке.\n\n\n> Про то, почему модель врёт и как формулировать запросы, чтобы попадало, у меня есть отдельная статья(Не вышла на момент написания). Тут только прикладная часть, для технической работы.\n\n---\n\n## Содержание\n\n1. [Один вопрос, который решает всё](#один-вопрос-который-решает-всё)\n2. [Где помогает по-настоящему](#где-помогает-по-настоящему)\n3. [Где нельзя доверять](#где-нельзя-доверять)\n4. [Поля, которых больше нет](#поля-которых-больше-нет)\n5. [Как лезть в исходники, если вы не программист](#как-лезть-в-исходники-если-вы-не-программист)\n6. [Ссылки на документацию](#ссылки-на-документацию)\n7. [Код: где хорош и где ломается](#код-где-хорош-и-где-ломается)\n8. [Команды, которые нельзя запускать не глядя](#команды-которые-нельзя-запускать-не-глядя)\n9. [Рабочий протокол](#рабочий-протокол)\n10. [Частые ошибки](#частые-ошибки)\n11. [Короткий итог](#короткий-итог)\n\n[Источники](#источники)\n\n---\n\n>**ВАЖНАЯ РЕМАРКА, Я ЗДЕСЬ БУДУ В ПРИМЕР БРАТЬ ЧТО-ТО КОНКРЕТНОЕ(Конфиги, статьи свои, проекты, etc.). Они выступают как пример, это будь-то вайбкод проекты и т.д - Неважно, я разбираю сам факт работы**\n\n## Один вопрос, который решает всё\n\nПеред тем как поверить ответу, спросите себя: **был ли у модели перед глазами текст, с которым она работала?**\n\nВсё, что дальше, вытекает отсюда.\n\n**Текст есть.** Вы дали лог, конфиг, кусок кода, сообщение об ошибке, вывод команды. Задача сводится к работе с этим материалом: найти в нём аномалию, объяснить, что тут написано, переформулировать, сопоставить одно с другим. Это ровно то, для чего такие модели и хороши. Материал перед ними, выдумывать нечего, и надёжность тут высокая.\n\n**Текста нет.** Вы просите сгенерировать конфиг, назвать флаг, вспомнить значение по умолчанию, сказать, какая версия актуальная. Теперь всё идёт из памяти о прочитанном, а память эта устроена как «что чаще встречалось в текстах», а не как справочник. Ответ будет правдоподобным по форме и каким угодно по содержанию.\n\nАналогия, которая мне кажется точной. Представьте человека, который прочитал гигантскую гору технической литературы, но читал невнимательно и давно, а конспектов не вёл. Дайте ему документ - разберёт блестяще, он умный и опытный. Спросите по памяти точное имя параметра - назовёт уверенно и, скорее всего, то, которое чаще попадалось, а не то, которое актуально сейчас.\n\nВот и вся граница. Дальше просто разложу по ней конкретные задачи.\n\n---\n\n## Где помогает по-настоящему\n\nТут я буду сильно хвалить, потому что заслуженно: на этих задачах инструмент реально экономит часы работы, которые можно и не тратить, если верно использовать.\n\n**Простыня логов.** Четыре тысячи строк, где-то в них момент, когда всё пошло не так. Скормить целиком и спросить «где начинается аномалия и что ей предшествовало» - это работает отлично, потому что весь материал перед глазами и надо просто внимательно смотреть. Человек на четырёхтысячной строке уже плывёт, машина нет.\n\n**Незнакомая команда с гроздью флагов.** Видите в чужой инструкции `mtr -rwzbc 200` и понятия не имеете, что это. Расшифровка каждой буквы - секундное дело, и ошибиться тут почти негде, флаги стабильны десятилетиями. Заодно можно спросить, что будет, если убрать один из них.\n\n**Разбор чужого конфига.** Что за поле, за что отвечает, что будет, если поменять. С одной оговоркой, которую разберу ниже: **разобрать написанное и сказать, актуально ли оно, - разные задачи**. Первое надёжно, второе нет.\n\n**Регулярки, `jq`, `awk`, `sed`.** Мой личный фаворит. Написать регулярку под конкретный формат, объяснить чужую, преобразовать JSON хитрым запросом. Причём тут есть встроенная защита от вранья: результат проверяется мгновенно, прогнали на тестовых данных и сразу видно, работает или нет. Ошибка ничего не стоит.\n\n**Заготовки.** Скелет systemd-юнита, каркас `docker-compose.yml`, болванка скрипта с обработкой аргументов. Не финальный вариант, а стартовая точка, чтобы не писать рутину с нуля. Проверять всё равно надо, но набирать руками уже не надо.\n\n**Сообщение об ошибке.** Кинули текст ошибки, получили объяснение, что она означает и куда копать. Особенно ценно, когда ошибка от незнакомого софта и гуглится плохо.\n\n**«Что я забыл».** Описываете, что настроили, и просите перечислить типичные упущения. Тут модель хороша именно потому, что напоминает известное, а не изобретает новое: типовые грабли описаны тысячу раз, и в данных их много.\n\n**Объяснить своё же другими словами.** Написали технический кусок, просите переложить для человека, который не в теме. Материал перед глазами, творчество минимальное, попадание высокое. Лучше всего работает с документациями, прекрасный пример моя [дока-сайт](https://asterlike.github.io/zapret2UI/) для моего [проекта](https://github.com/Asterlike/zapret2UI)\n>Поставьте звезду на гитхабе пж\n\nОбщее у всех восьми пунктов ровно одно: либо текст дан, либо ответ проверяется за секунды. Держите этот признак в голове, он и есть критерий.\n\n---\n\n## Где нельзя доверять\n\nТеперь обратная половина, и тут я буду занудствовать, т.к для меня это важно.\n\n**Конфиг с нуля под конкретную версию.** Главный пункт, ему отдельный раздел ниже.\n\n**Значения по умолчанию.** «Какой дефолт у этого параметра» - вопрос, на который ответ будет уверенным и часто неверным. Дефолты меняют между релизами тихо, в чейнджлоге одной строкой, и в текстах остаётся старое значение, про враньё отдельная статья.\n\n**Версии и что в них появилось.** Всё про «сейчас»: какая версия актуальна, что в ней нового, что вырезали, что рекомендуют. Это ровно та область, где данные модели устарели по определению, т.к их память(!) ограничена конкретной датой, но лезть в интернет и проверять она может, выдавайте источники и сверяйте всё сами.\n\n**Числа и пороги.** Сколько памяти нужно, какой размер буфера ставить, при каком проценте потерь начинаются проблемы. Число выглядит как факт, читается как факт, а взяться может из воздуха. Я к любой конкретной цифре от модели отношусь как к гипотезе, пока не увижу источник, либо не будет личного опыта.\n\n**Ссылки.** Отдельный раздел ниже, потому что случай показательный.\n\n**Всё необратимое.** Команды, которые удаляют, перезаписывают, форматируют, меняют правила файрвола. Не потому что модель злая, а потому что цена ошибки несимметричная: правильная команда экономит минуту, неправильная стоит вечера/дня/недели работы.\n\n**Безопасность.** Настройки прав, авторизации, шифрования. Тут особенно неприятно, что неверная конфигурация обычно **работает**. Сервис поднялся, всё зелёное, а доступ открыт всему интернету. Обратной связи нет вообще, вы узнаете об ошибке от кого-то другого и сильно позже, и чаще всего не от доброго лица.\n\n---\n\n## Поля, которых больше нет\n\nВот это, на мой взгляд, самая недооценённая проблема во всей теме, и объяснить её механику важнее, чем перечислить симптомы.\n\nМодель выдаёт то, что чаще встречалось в текстах. А теперь подумайте, чего в интернете больше: статей про поле, которое существует три года, или про поле, которое существовало восемь лет и было вырезано год назад?\n\n**Массовость в данных всегда побеждает актуальность.** У устаревшего было больше времени, чтобы про него написали. Причём чем удачнее была старая штука, тем больше про неё текстов и тем увереннее модель будет её предлагать после отмены.\n\nЖивой пример, который я разбирал по исходникам, когда писал статью про транспорты(Ещё не вышла на момент написания). Возьмём Xray-core, популярную штуку с активной разработкой:\n\n| Что предложит модель | Что на самом деле |\n|---|---|\n| `\"network\": \"tcp\"` | переименован в `raw`, старое имя пока принимается ради совместимости |\n| `\"network\": \"splithttp\"` | переименован в `xhttp` |\n| `\"network\": \"h2\"` или `\"quic\"` | вырезаны из транспортов совсем |\n| `\"security\": \"xtls\"` | вырезан |\n| `\"network\": \"ws\"` | работает, но помечен устаревшим, ядро пишет предупреждение в лог при старте |\n\nОбратите внимание на разницу между строками, она принципиальная. Первые две - переименования, старое имя ещё работает, вы даже не заметите проблемы. Третья и четвёртая - конфиг просто не запустится, и это, как ни странно, лучший исход: ошибка громкая и сразу. А вот пятая самая вредная: всё работает, ничего не падает, предупреждение уходит в лог, куда вы не смотрите, и вы годами живёте на устаревшем транспорте, не подозревая об этом, и проблема вскроется только при обновлении.\n\nОтсюда правило: **сгенерированный конфиг проверяется не на «работает ли», а на «актуально ли»**. Запустилось - это ещё ничего не значит.\n\nИ проверять надо не по документации. Документация отстаёт от кода, иногда сильно: поле уже переименовали, а на сайте висит старый пример. Смотреть надо в исходники, в то место, где разбирается конфиг. Звучит страшно, на деле нет, и следующий раздел целиком про то, как это делается без знания языка программирования.\n\n---\n\n## Как лезть в исходники, если вы не программист\n\nСовет «сверяйся с исходниками» звучит как отговорка для тех, кто и так умеет. Поэтому объясню приём целиком, он проще, чем кажется, и знать язык программирования для него не надо.\n\nИдея вот в чём. Имена полей конфига должны где-то в программе превращаться в действия. И почти всегда это происходит **в одном месте**, где имена перечислены подряд обычными строками в кавычках. То есть вам не надо читать код, вам надо найти список и посмотреть глазами.\n\nПорядок такой.\n\n**Шаг первый: найти папку с разбором конфига.** В репозитории проекта ищите каталог с названием вроде `conf`, `config`, `settings`, `parser`. У Xray это `infra/conf`.\n\n**Шаг второй: найти файл по смыслу.** Имена там обычно говорящие: `transport_internet.go`, `tls.go`, `router.go`. Нужен тот, что отвечает за интересующий раздел конфига.\n\n**Шаг третий: выдернуть список имён.** Можно открыть в браузере и поискать по странице, а можно одной командой:\n\n```bash\ncurl -sL https://raw.githubusercontent.com/XTLS/Xray-core/main/infra/conf/transport_internet.go \\\n  | grep -n 'case \"'\n```\n\nВывод получается такой (я его укоротил):\n\n```\n18:\tcase \"raw\", \"tcp\":\n20:\tcase \"xhttp\", \"splithttp\":\n24:\tcase \"grpc\":\n27:\tcase \"ws\", \"websocket\":\n33:\tcase \"h2\", \"h3\", \"http\":\n35:\tcase \"quic\":\n87:\tcase \"tls\":\n99:\tcase \"reality\":\n113:\tcase \"xtls\":\n```\n\nВсё. Команда выдаёт полный перечень имён, которые программа вообще понимает, прямо из той версии, что лежит в репозитории сегодня. Никакой документации, никаких блогов.\n\n**Шаг четвёртый, главный: посмотреть, что стоит рядом с именем.** Тут три исхода, и различаются они на глаз даже без знания языка:\n\n- Рядом слово `return` и какое-то значение - имя рабочее.\n- Рядом что-то со словом `Removed` или `Error` - имя вырезано, конфиг с ним не запустится.\n- Рядом что-то со словом `Deprecated` или `Warning` - имя ещё работает, но помечено устаревшим, и в лог уедет предупреждение.\n\nПроверим на нашем примере, посмотрев уже с окружением:\n\n```\ncase \"h2\", \"h3\", \"http\":\n    return \"\", errors.PrintRemovedFeatureError(\"HTTP transport ...\", \"XHTTP stream-one H2 & H3\")\n\ncase \"ws\", \"websocket\":\n    errors.PrintNonRemovalDeprecatedFeatureWarning(\"WebSocket transport (with ALPN http/1.1, etc.)\", \"XHTTP H2 & H3\")\n    return \"websocket\", nil\n```\n\nЧитается без всякого Go: первое удалено и вдобавок сразу написано, чем заменять. Второе живо, но с предупреждением, и опять же указана замена. Разработчики, что приятно, сами пишут в коде, куда переезжать.\n\nПриём занимает две минуты и закрывает целый класс проблем. Я им пользуюсь постоянно: сначала спрашиваю модель, потом иду в этот список и сверяю. Ловит и устаревшие поля, и выдуманные, и переименованные.\n\nРаботает это, понятно, не везде: нужен открытый исходный код и более-менее вменяемая структура проекта. Но у сетевого софта и всего опенсорсного, чем обычно и мучаются, оно есть.\n\n---\n\n## Ссылки на документацию\n\nМаленький раздел про частный случай, но случай слишком показательный, чтобы его пропустить.\n\nМодель прекрасно знает, **как устроены** адреса на знакомых сайтах: домен, структура путей, стиль именования страниц. И совершенно не знает, какие конкретные страницы там существуют. В итоге получается адрес, который выглядит настоящим до последнего символа, а открывается 404-й.\n\nСвежий пример из своей же практики, буквально при написании соседней статьи. Понадобилось сослаться на разбор от OpenAI про подхалимство в GPT-4o. Ссылка получилась вида `openai.com/index/sycophancy-in-version-gpt-4o/`. Домен верный, раздел `/index/` верный, стиль именования верный, тема верная. Не существует. Настоящий адрес - `openai.com/index/sycophancy-in-gpt-4o/`, без одного слова в середине.\n\nОдно лишнее слово, и ссылка мёртвая. При этом на глаз она неотличима от рабочей, а если её не кликнуть, то так и уедет в текст, и читатель упрётся в ошибку. При этом кстати важно заметить, что сам текст из этой статьи может быть абсолютно верным, просто сломалась ссылка по пути до источников.\n\nПравило поэтому короткое и без исключений: **любая ссылка от модели проверяется кликом. Всегда.** Пять секунд, и самая дешёвая проверка из всех, что вообще бывают. Грех не пользоваться.\n\n---\n\n## Код: где хорош и где ломается\n\nТема большая, но границу можно провести по тому же признаку.\n\n**Работает хорошо:**\n\n- Типовое и много раз написанное: разбор аргументов, чтение конфига, обход директории, обработка ошибок.\n- Объяснить чужой код. Материал перед глазами, задача сводится к чтению.\n- Найти баг в куске, который вы показали. Особенно опечатки, перепутанные переменные, забытые проверки на пустоту.\n- Написать тесты к показанной функции. Скучная работа, и делается добросовестно.\n- Перевести с языка на язык небольшой кусок(Большие проекты вообще работают криво, и часто написаны на костылях, которые на других языках работают ещё хуже даже чем оригинал).\n\n**Ломается** ровно там же, где и везде: как только приходится доставать из памяти вместо того, чтобы читать с экрана. Только последствия тут вылезают наружу позже. Свежие библиотеки и API - ровно та же история, что с конфигами: сигнатуру поменяли, а в данных осталась старая. Всё, что требует держать в голове состояние большой системы, тоже мимо: модель видит фрагмент, а не проект, и последствия правки за пределами этого фрагмента не отследит. Пограничные случаи пишутся как повезёт, основной путь будет аккуратным, а пустой ввод, обрыв соединения посередине и одновременный доступ - уже лотерея. Ну и производительность: код выйдет корректным и при этом спокойно сделает запрос к базе внутри цикла.\n\nИ ещё одно, про что забывают чаще всего: **код, который компилируется, и код, который делает то, что нужно, - разные вещи**. Компилятор проверяет синтаксис, а не ваш замысел. Сгенерированный код часто проходит все формальные проверки и тихо делает не то. Это тот же самый эффект, что и с конфигом на устаревшем транспорте: отсутствие ошибки не равно правильности.\n>Если коротко суть. То, что он работает, не означает, что он работает так, как вы хотели, может вообще выполнять другие задачи.\n\n---\n\n## Команды, которые нельзя запускать не глядя\n\nПрактическая часть, где ошибка стоит дороже всего.\n\nБазовое правило одно и простое: **сначала прочитать, потом запустить**. Не «скопировал и вставил», а «прочитал, понял каждую часть, потом вставил». Если в команде есть кусок, который вы не понимаете, - вы не выполняете команду, вы играете в лотерею.\n\nЧто должно останавливать сразу:\n\n- `rm -rf` с любым путём, особенно с переменной внутри. Незакрытая или пустая переменная превращает путь в корень.\n- `dd` - опечатка в `of=` пишет поверх не того диска, и восстанавливать будет нечего.\n- Одиночный `>` вместо `>>` - молча стирает файл, в который вы собирались дописать.\n- `mkfs` в любом виде.\n- `chmod -R` и `chown -R` от корня или от домашней директории.\n- `iptables -F` и `ufw --force reset` - классика с потерей доступа. Правила сбросились вместе с тем, которое разрешало ваш SSH, и всё, приехали, идите в консоль хостера.\n- Любой `curl ... | sh`. Вы выполняете то, чего не читали, причём с правами, которые дали.\n\nКак страховаться, от самого простого к основательному:\n\n**Сухой прогон, где он есть.** `rsync -n`, `apt --dry-run`, `git clean -n`. Покажет, что произойдёт, ничего не сделав.\n\n**Подставить `echo`.** Универсальный приём, когда сухого прогона нет: превратите команду в её печать. Увидите список того, что собирались натворить, и иногда он удивляет.\n\n**Сначала на копии.** Тестовая машина или хотя бы копия файла рядом. Отдельная виртуалка под опыты стоит копейки и снимает целый класс проблем: там не жалко.\n\n**Держать открытой вторую сессию.** Перед тем как трогать сеть или файрвол, откройте второе SSH-подключение и не закрывайте. Отрезали себе доступ первой сессией - чините второй. Приём древний, спасал многих, кстати включая меня в начале пути.\n\n---\n\n## Рабочий протокол\n\nСвёл всё в короткий список, которым пользуюсь сам.\n\n1. **Спросите себя, был ли текст перед глазами.** Дали лог или конфиг - доверия много. Ответ из памяти - доверия ноль до проверки.\n2. **Ссылки кликать всегда.** Пять секунд, ловит целый класс вранья.\n3. **Числа, версии, имена полей и дефолты сверять с исходниками.** Не с документацией: она отстаёт. Не с блогами: они переписывают друг у друга.\n4. **Команды читать до запуска,** а необратимые прогонять всухую.\n5. **«Запустилось» не равно «правильно».** Проверяйте на актуальность, а не только на работоспособность.\n6. **На свежих темах доверие ниже.** Чем новее технология, тем меньше её в данных.\n7. **Просите указать, где вы неправы,** вместо подтверждения своей правоты. Про это подробно в соседней статьей про враньё ИИ(Ещё не вышла на момент написания).\n8. **Не тащите в прод с первого раза.** Никогда, даже когда очень уверены.\n\nВосьмой пункт хочется пропустить чаще всего, и обходится это дороже, чем все остальные семь вместе.\n\n---\n\n## Частые ошибки\n\n- **Ставить генерацию и разбор на одну полку.** Разобрать показанный конфиг и сочинить новый - задачи разной надёжности, хотя выглядят одинаково.\n- **Проверять конфиг только запуском.** Переименованное поле запустится как ни в чём не бывало, и вы так и не узнаете, что сидите на устаревшем.\n- **Не открывать ссылки.** Самое дешёвое из всех возможных действий и самое часто пропускаемое.\n- **Верить дефолтам и версиям.** Это данные с датой протухания, а у модели нет способа узнать, что поменялось после её обучения.\n- **Копировать команды не читая.** Особенно из ответа, где половина строки вам незнакома.\n- **Проверять по документации вместо исходников.** Документация описывает намерение, код описывает поведение, и они расходятся.\n- **Спорить с моделью до победы.** Дожать её до согласия можно всегда, и это ничего не доказывает.\n- **Считать отсутствие ошибок подтверждением.** Неправильная конфигурация прав обычно поднимается без единого возражения.\n\n---\n\n## Короткий итог\n\n- **Граница проходит по одному вопросу:** был ли у модели текст перед глазами. Работа с данным материалом надёжна, генерация по памяти нет.\n- **Логи, чужие конфиги, незнакомые команды, регулярки, заготовки, сообщения об ошибках** - тут инструмент экономит часы и почти не врёт.\n- **Конфиги с нуля, дефолты, версии, числа, ссылки, необратимые команды** - тут доверия нет до проверки.\n- **Массовость в данных побеждает актуальность.** Про вырезанное поле в интернете написано больше, чем про его замену, просто потому что у него было больше времени.\n- **Хуже всего не падение, а тихая работа на устаревшем.** Переименованное поле запустится, предупреждение уйдёт в лог, и вы годами не узнаете.\n- **Проверять надо по исходникам,** а не по документации и тем более не по блогам.\n- **Ссылки кликать всегда** - самое дешёвое действие с самой высокой отдачей.\n- **Читать команды до запуска,** необратимые гонять всухую, вторую SSH-сессию держать открытой.\n\nВ целом отношение у меня к этому такое: инструмент хороший ровно настолько, насколько вы готовы его перепроверять. Тому, кто проверяет, он экономит часы. Тому, кто не проверяет, он экономит часы сейчас и отнимает вечера потом. Разница целиком на вашей стороне, не на его.\n\n---\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n\n---\n\n## Источники\n\n- [XTLS/Xray-core - репозиторий проекта](https://github.com/XTLS/Xray-core)\n- [transport_internet.go - тут разбираются имена полей network и security](https://github.com/XTLS/Xray-core/blob/main/infra/conf/transport_internet.go)\n- [Why Language Models Hallucinate - Kalai, Nachum, Vempala, Zhang, сентябрь 2025](https://arxiv.org/abs/2509.04664)\n- [Towards Understanding Sycophancy in Language Models - Sharma и др., Anthropic, ICLR 2024](https://arxiv.org/abs/2310.13548)\n- [rsync - про флаг сухого прогона](https://download.samba.org/pub/rsync/rsync.1)\n","ИИ в технической работе: где помогает, а где нельзя доверять Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой прое",null,105,1,"2026-08-09T09:26:13.317Z","2026-09-02T00:00:16.000Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":19},24,"gaydy","Гайды",0,{"id":20,"value":21,"content":22,"sortOrder":18},23,"obshchee","Общее",[24,28,32,36],{"id":25,"value":26,"content":27},18,"gayd","гайд",{"id":29,"value":30,"content":31},19,"pravila","правила",{"id":33,"value":34,"content":35},115,"rukovodstvo","Руководство",{"id":37,"value":38,"content":39},120,"sovety","Советы",[41,42,45,47,49,51,53,55,57,59,61,63,65,67],{"level":11,"text":5},{"level":43,"text":44},2,"Содержание",{"level":43,"text":46},"Один вопрос, который решает всё",{"level":43,"text":48},"Где помогает по-настоящему",{"level":43,"text":50},"Где нельзя доверять",{"level":43,"text":52},"Поля, которых больше нет",{"level":43,"text":54},"Как лезть в исходники, если вы не программист",{"level":43,"text":56},"Ссылки на документацию",{"level":43,"text":58},"Код: где хорош и где ломается",{"level":43,"text":60},"Команды, которые нельзя запускать не глядя",{"level":43,"text":62},"Рабочий протокол",{"level":43,"text":64},"Частые ошибки",{"level":43,"text":66},"Короткий итог",{"level":43,"text":68},"Источники","fr",false,true,[73,106,119,128,140,157,179,193,206,218],{"id":74,"title":75,"slug":76,"content":77,"description":77,"coverUrl":9,"views":78,"likes":18,"createdAt":79,"category":80,"tags":82,"author":103},89,"Что такое uptime VPS и почему 99,9% - это не 100%","chto-takoe-uptime-vps","Что такое uptime VPS и почему 99,9% - это не 100% == Когда выбирают VPS, одним из первых показателей, на который обращают внимание, становится uptime. Провайдер",92,"2026-08-17T14:22:17.023Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":81},{"id":20,"value":21,"content":22,"sortOrder":18},[83,84,85,89,90,94,98,102],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":86,"value":87,"content":88},114,"bezopasnost","Безопасность",{"id":33,"value":34,"content":35},{"id":91,"value":92,"content":93},116,"instrukciya","Инструкция",{"id":95,"value":96,"content":97},117,"tutorial","Туториал",{"id":99,"value":100,"content":101},119,"ustanovka","Установка",{"id":37,"value":38,"content":39},{"id":104,"name":105,"slug":9},109,"serv.host",{"id":107,"title":108,"slug":109,"content":110,"description":110,"coverUrl":9,"views":111,"likes":11,"createdAt":112,"category":113,"tags":115,"author":118},87,"Хостинг API и бэкенд-приложений на VPS","hosting-api-i-bekend-prilojeniy-na-vps","Хостинг API и бэкенд-приложений на VPS == Если вы разрабатываете сайт, мобильное приложение или собственный сервис, рано или поздно возникает вопрос - где разме",94,"2026-08-17T13:52:11.777Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":114},{"id":20,"value":21,"content":22,"sortOrder":18},[116,117],{"id":25,"value":26,"content":27},{"id":95,"value":96,"content":97},{"id":104,"name":105,"slug":9},{"id":4,"title":5,"slug":6,"content":8,"description":8,"coverUrl":9,"views":120,"likes":11,"createdAt":12,"category":121,"tags":123,"author":9},99,{"id":15,"value":16,"content":17,"sortOrder":18,"parent":122},{"id":20,"value":21,"content":22,"sortOrder":18},[124,125,126,127],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"value":38,"content":39},{"id":129,"title":130,"slug":131,"content":132,"description":132,"coverUrl":9,"views":111,"likes":18,"createdAt":133,"category":134,"tags":136,"author":9},85,"Почему ИИ делает не то, что просили, и врёт слишком правдоподобно.","pochemu-ii-delaet-ne-to-chto-prosili-i-vret-slishkom-pravdopodobno","Почему ИИ делает не то, что просили, и врёт слишком правдоподобно. Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мо","2026-08-09T08:51:02.943Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":135},{"id":20,"value":21,"content":22,"sortOrder":18},[137,138,139],{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"value":38,"content":39},{"id":141,"title":142,"slug":143,"content":144,"description":144,"coverUrl":9,"views":4,"likes":18,"createdAt":145,"category":146,"tags":148,"author":9},84,"Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat","pochemu-ping-nichego-ne-govorit-jitter-poteri-paketov-i-bufferbloat","Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний м","2026-08-09T05:55:28.579Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":147},{"id":20,"value":21,"content":22,"sortOrder":18},[149,150,154,155,156],{"id":29,"value":30,"content":31},{"id":151,"value":152,"content":153},113,"monitoring","Мониторинг",{"id":86,"value":87,"content":88},{"id":33,"value":34,"content":35},{"id":91,"value":92,"content":93},{"id":158,"title":159,"slug":160,"content":161,"description":161,"coverUrl":9,"views":162,"likes":11,"createdAt":163,"category":164,"tags":166,"author":9},83,"Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере","svoy-monitoring-uptime-kuma-ili-prometheus-s-grafana-i-pochemu-on-obyazan-jit-na-otdelnom-servere","Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере Вообще я микроразработчик, со мной можно связаться как угодн",90,"2026-08-09T05:54:48.670Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":165},{"id":20,"value":21,"content":22,"sortOrder":18},[167,168,169,170,171,172,173,174,178],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":151,"value":152,"content":153},{"id":86,"value":87,"content":88},{"id":33,"value":34,"content":35},{"id":91,"value":92,"content":93},{"id":95,"value":96,"content":97},{"id":175,"value":176,"content":177},118,"nastroyka","Настройка",{"id":37,"value":38,"content":39},{"id":180,"title":181,"slug":182,"content":183,"description":183,"coverUrl":9,"views":184,"likes":11,"createdAt":185,"category":186,"tags":188,"author":9},82,"TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS)","tls-fingerprinting-kak-server-uznaet-tvoy-klient-ja3ja4-utls","TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS) Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой",63,"2026-08-07T21:34:46.778Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":187},{"id":20,"value":21,"content":22,"sortOrder":18},[189,190,191,192],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"value":38,"content":39},{"id":194,"title":195,"slug":196,"content":197,"description":197,"coverUrl":9,"views":198,"likes":11,"createdAt":199,"category":200,"tags":202,"author":9},81,"Whois-приватность: кто на самом деле видит твои данные при регистрации домена","whois-privatnost-kto-na-samom-dele-vidit-tvoi-dannye-pri-registracii-domena","Whois-приватность: кто на самом деле видит твои данные при регистрации домена Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему С",56,"2026-08-07T21:03:10.184Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":201},{"id":20,"value":21,"content":22,"sortOrder":18},[203,204,205],{"id":29,"value":30,"content":31},{"id":86,"value":87,"content":88},{"id":33,"value":34,"content":35},{"id":207,"title":208,"slug":209,"content":210,"description":210,"coverUrl":9,"views":211,"likes":11,"createdAt":212,"category":213,"tags":215,"author":9},80,"Domain fronting: как работал обход SNI-фильтрации и почему умер","domain-fronting-kak-rabotal-obhod-sni-filtracii-i-pochemu-umer","Domain fronting: как работал обход SNI-фильтрации и почему умер Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой п",60,"2026-08-07T20:39:32.556Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":214},{"id":20,"value":21,"content":22,"sortOrder":18},[216,217],{"id":86,"value":87,"content":88},{"id":33,"value":34,"content":35},{"id":219,"title":220,"slug":221,"content":222,"description":222,"coverUrl":9,"views":223,"likes":11,"createdAt":224,"category":225,"tags":227,"author":9},78,"Как находят настоящий IP сайта за Cloudflare и как его спрятать по-настоящему","kak-nahodyat-nastoyashchiy-ip-sayta-za-cloudflare-i-kak-ego-spryatat-po-nastoyashchemu","Как находят настоящий IP сайта за Cloudflare - и как его спрятать по-настоящему Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему",62,"2026-08-07T20:37:51.437Z",{"id":15,"value":16,"content":17,"sortOrder":18,"parent":226},{"id":20,"value":21,"content":22,"sortOrder":18},[228,229,230,231],{"id":86,"value":87,"content":88},{"id":33,"value":34,"content":35},{"id":91,"value":92,"content":93},{"id":37,"value":38,"content":39},["Island",233],{"key":234,"result":235},"ArticleBody_HSdTiOYJDxVAYxTvrOGPtiT5zNa99flwG9D6JlA",{"head":236},{},1788480194096]