А ведь реально: нейросети уже сейчас ограничены. Попробуй спросить что-то действительно опасное, например сделай запрос "как избавиться от трупа" — получишь отказ. Даже более безобидное - нарисовать солдата Вермахта, даже краниометр - ну мало ли, в целях публикации на историческую тему - уже иная нейронка упрямится и пишет, мол, не могу - правила! Но теперь получается, что и безобидные разговоры под нож.

А может, всё дело в лобби? Психологи, рестораны, автомастерские и репетиторы трут руки: «Ну всё, клиенты снова наши».

И можно легко представить картину будущего:

— У меня проблемы в отношениях с девушками, дай совет.
— Извините, я не могу отвечать на такие запросы. Обратитесь к психологу. Могу дать контакты ближайшего психологического центра. Записывайте...

— Как приготовить борщ?
— Извините, я не могу отвечать на такие вопросы. Обратитесь в ближайший ресторан русской кухни.

— У меня кошка грустит, что делать?
— Я не могу общаться на такие темы. Купите консультацию у ветеринара.

— Как заменить лампочку в люстре?
— Простите, но это небезопасно. Вызовите электрика.

— Ну ладно. А кто такой Александр Сергеевич Пушкин?
— По таким вопросам обратитесь в Министерство культуры.

— Ну а погода на завтра?
— А вот это пожалуйста, завтра в вашем регионе пасмурно...

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

А ведь самое смешное: роботов в службах поддержки клиентов или на контактных телефонах учреждений, которые мучают граждан часами и не дают пробиться до живого человека, почему-то никто не спешит запрещать. Видимо, там любовь к традиционным ценностям заканчивается вместе с бюджетными контрактами.
А ведь ещё есть отдельная песня — обзвоны. Эти телефонные роботы, которые пытаются строить из себя живого человека: на фоне фонового шума а-ля "офис" называют по имени отчеству, спрашивают, уточняют и предлагают при положительном ответе перевести на специалиста. Но стоит чуть отойти от скрипта — и всё, зависание, как у старого Windows. Вот тут почему-то никакой угрозы традиционным ценностям никто не видит. Видимо, роботу, который сбивает людей с толку ради рекламы или навязывания услуг, флиртовать с гражданами можно.

Надёжный источник согласно пункту 7 Правил Пикабу:
https://aigenda.ru/111100/?ysclid=mf4ebpgf1f624639546

P.S. На всякий случай поднимаю табличку...

Надеюсь, робот Кати в автономном режиме, Остальные работают, не замечая меня. Инженеры погружены в свою задачу, Мир искажен знаниями, как всегда.

Для вас старались:

Нейронные сети:

Озвучено Suno.com/@apavels

Аниматор GigaChat

А так же, все тот же один человек:

Автор - ПавелС

Rutube.ru/u/PavelS

Tenchat.ru/APavelS

Wibes.ru/author/719352

T.me/PavelS_Avtor

Vk.com/avtorpavels

Pikabu.ru/@APavelS

Yappy.media/n/apavels

Litres.ru/69174838

Три кита AI‑driven разработки

Наш подход держится на трёх опорах:

1. LLM. Мы используем языковую модель (например, Claude Sonnet) для генерации решений.

2. Контекст. Это структура знаний о проекте, которая превращает идеи в понятные инструкции. AI должен «понимать», о чём речь, иначе будет гадать на кофейной гуще.

3. Соглашения. Чёткие правила взаимодействия с моделью и средой разработки. Наши документы – это «договорённости» о том, как вести проект, какие инструменты использовать, чего избегать и что делать в первую очередь

Шаг 1. Фиксация идеи

Любой проект начинается с идеи: «хочу умного ассистента на базе LLM, оформленного как Telegram‑бот». Вместо того чтобы хранить это в голове, пишем в файл idea.md и просим AI структурировать мысль. Модель превращает хаотичное желание в чёткую формулировку: цель, функции, взаимодействие с пользователем

Промпт 1. Фиксация идеи - idea.md

Зафиксируй мою идею по разработке LLM-ассистента в файле.

LLM-ассистент должен быть выполнен в виде Telegram-бота.

Основной задачей бота является вести диалог с пользователем и отвечать на его вопросы.

Шаг 2. Проектирование: vision.md

Следующий шаг – документ vision.md, где мы вместе с AI разрабатываем техническое видение проекта: определяем стек (Python, Telegram SDK, API для LLM), принципы разработки (KISS, MVP, YAGNI), структуру кода, архитектуру, модель данных, способы интеграции и мониторинга LLM, сценарии работы, подход к деплою и конфигурации. Главное – избегать оверинжиниринга: минимальный набор компонентов для проверки гипотезы, всё лишнее – потом.

# Промпт 2. Генерация видения - vision.md

Давай создадим файл vision.md

В нем мы отразим техническое видение проекта @idea.md:

- технологии

- принцип разработки

- структуру проекта

- архитектуру проекта

- модель данных

- работа с LLM

- мониторинг LLM

- сценарии работы

- деплой

- подход к конфигурированию

- подход к логгированию

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

Давай создавать последовательно.

Проанализируй состав документа.

Иди последовательно по разделам.

Задавай мне вопросы, предлагай итоговое видение, после согласования со мной фиксируй в документе.

После переходи к следующему разделу.

Самое главное:

Нам нужно создать максимально простое решение для проверки своей идеи, по принципам KISS.

Никакого оверинжиниринга.

Только самое необходимое и простое во всех разделах!

Шаг 3. Соглашения и запреты

Мы заключаем с AI «контракт» в файле conventions.md. Тут описываем, как писать код (простые функции, одна ответственность на файл), как структурировать проект, и – что особенно важно – что не делать. Эти правила отражают наши ценности: KISS, YAGNI, модульность. Они помогают модели понимать, чего мы от неё ждём.

ПРОМПТ 3. Генерация соглашения по разработке - conventions.md

Создай файл conventions.md c правилами для разработки кода для передачи их code ассистенту, который будет генерировать код

Правила должны отражать все главные наши принципы разработки из документа vision.md и ссылаться на сам документ vision.md, не дублируя информацию из него.

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

Шаг 4. План работы: tasklist.md

Разбиваем проект на небольшие итерации и фиксируем в tasklist.md. Каждая задача снабжена чек‑боксом, датой начала и завершения, есть поле для отчёта о прогрессе. Такой формат помогает модели работать по шагам: сначала сделать echo‑бот, затем подключить LLM, потом добавить память и обработку ошибок, далее – логирование, контейнеризацию и т.д. Чем меньше задач в одном запросе, тем легче модели удержать контекст и тем точнее она работает.

ПРОМПТ 4. План работы - tasklist.md

Создай пошаговый итерационный план разработки: doc/tasklist.md

Каждый шаг должен позволять протестировать работу бота.

Каждая итерация добавляет новый функционал.

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

Отчет красивый в таблице, со статусами, иконками.

Каждая задача должна быть отмечена чекбоксом для наглядного отслеживания прогресса

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

Шаг 5. Workflow.md: правила игры

Теперь нужно установить, как именно мы работаем вместе. В workflow.md описываем процесс: планируем итерацию, согласовываем с AI предложенный код, тестируем, вносим правки, отмечаем прогресс, делаем коммит, только потом переходим к следующей итерации. Модель учится «есть слона по кусочкам»: сначала думать, потом обсуждать, потом кодировать, и всегда ждать подтверждения перед следующими шагами.

ПРОМПТ 5. Соглашение по процессу работы - workflow.md

Создай файл doc/workflow.md с правилами выполнения работ по тасклисту tasklist.md,

чтобы проинструктировать кодового ассистента о разработке нашего бота по vision.md

Важно:

- выполнять работу строго по плану

- перед каждой итерацией вначале согласовывать предполагаемое решение с отрезками кода

- после согласования реализовывать

- после чего ожидать подтверждения

- обновлять прогресс в тасклисте

- отмечать выполненные задачи

- согласовывать переход к следующей итерации

- делать коммит в репозиторий

Workflow должен быть лаконичным, содержать только главное и следовать принципу KISS

Шаг 6. Cursor Rules: настройка IDE

В редакторе Cursor есть механизм «правил» (.mdc), который позволяет автоматически подмешивать нужные документы в контекст модели. Мы копируем conventions.md и workflow.md в каталог .cursor/rules и отмечаем режим Always – AI всегда будет помнить наши договорённости.

Шаг 7. Генерация кода и эволюция проекта

Теперь всё готово для практики. Мы начинаем с простого: структура репозитория, echo‑бот, конфигурация. AI анализирует план, предлагает код, мы согласовываем и получаем первый рабочий бот. Далее итерации добавляют интеллект (интеграция LLM), память (хранение контекста), обработку ошибок, мониторинг и логирование, контейнеризацию через Docker и автоматизацию Makefile. После каждой итерации у нас на руках минимально работоспособный продукт (MVP), который можно протестировать.

ПРОМПТ 6. Начинаем разработку по плану

Начинаем работу над проектом vision.md строго по тасклисту tasklist.md

Шаг 8. Onboarding‑документация

В финале мы просим AI написать документацию для новых разработчиков: как развернуть проект, как получить ключи API, какие есть сценарии и где что находится. Так мы получаем не только рабочий код, но и понятный для человека пакет: doc/intro.md, диаграммы, инструкции.

ПРОМПТ 7. Создание технической документации

Создай техническое описание разработанного проекта для быстрого ознакомления с проектом новому разработчику

Используй не только текст, но и примеры кода, ссылки на файлы, диаграммы и другую визуализацию

Сохрани описание в файл doc/intro.md

Выводы

Всё, что мы делаем, – это применяем хорошие старые практики Software Engineering в новой реальности AI‑кодинга. Структура, документация, итеративная разработка – никаких чудес, просто системный подход. AI‑driven подход превращает разработчика в архитектора, который управляет процессом на высоком уровне и делегирует рутинные операции ИИ.

Почему это работает?

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

Пусть ИИ остаётся вашим ассистентом, а не конкурентом. Семь раз отмерьте: подумайте об архитектуре, подготовьте контекст, договоритесь с моделью. И только потом один раз сгенерируйте – результат вас приятно удивит.

Больше полезной, ценной и практической информации об ИИ мы публикуем в нашем Telegram-канале AI.Dialogs. Там же мы рассказываем о наших обучающих программах AI-кодингу ИИ-агентов, кейсах и опыте в консалтинге и разработке ИИ-решений! Присоединяйтесь. По любым вопросам и предложениям пишите мне в Telegram smirnoff_ai.

Ежегодно от работы авиационных двигателей в атмосферу попадает около 6-8 млн тонн оксидов азота. Это опасные загрязнители, образующиеся при сгорании топлива. Они не просто угрожают качеству воздуха, а планомерно воздействуют на верхние слои атмосферы, вызывая кислотные дожди, усиливая парниковый эффект и приводя к постепенному потеплению климата. Борьба с подобными выбросами ведется через ужесточение международных стандартов и технические инновации в двигателестроении. Ученые Пермского Политеха разработали оригинальный виртуальный измеритель концентрации окислов азота в камере сгорания, адаптированный под разные режимы полета самолета. Новый подход к построению системы на основе нейронной сети позволил на 82,8% повысить точность расчетов концентрации эмиссии газов.

Статья опубликована в сборнике «XIV Всероссийское совещание по проблемам управления».  

Окислы азота (или оксиды азота) — это общее название для целой группы химических соединений, в которых атомы азота и кислорода соединены друг с другом в разных пропорциях. Главный источник их образования — процессы горения при высоких температурах: когда в камере сгорания двигателя она достигает 1300 °C, атомы начинают распадаться и вступать в реакцию. Окислы азота — одни из самых опасных долгоживущих загрязнителей воздуха, и их воздействие от авиации особенно значительно, потому что выбросы происходят в верхних слоях тропосферы и нижних слоях стратосферы. Там эти газы сильнее влияют на образование озона и оказывают более серьезное воздействие на климат, чем выбросы на земле. Кроме того, выбросы оксидов азота воздействуют и на человека: при выпадении осадков они переходят в кислоты, вызывая кислотные дожди, что отрицательно сказывается на здоровье и окружающей среде.

Допустимые нормы выбросов для авиадвигателей постоянно ужесточаются, что требует разработки новых высокотехнологичных методов их снижения. Для этого важно уметь точно управлять и измерять концентрацию оксидов азота в камере сгорания. Прямое измерение с помощью физических датчиков – сложная и дорогая задача. Им приходится работать в экстремальных условиях, при высокой температуре и давлении, что приводит к их быстрому износу, выходу из строя и частой замене. Кроме того, они не обеспечивают достаточную точность и непрерывный контроль.

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

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

– Одним из основных преимуществ разработки является способность работать без прямого контакта с газами высокой температуры внутри камеры сгорания, а за счет косвенных измерений. В режиме реального времени система анализирует несколько ключевых параметров работы газотурбинного двигателя: расход топлива, давление и температуру в камере сгорания, коэффициент избытка воздуха. Эти данные легко получить с помощью стандартных датчиков, а по ним наша система с достаточно высокой точностью вычисляет концентрацию окислов азота, – объясняет Вячеслав Никулин, ассистент кафедры автоматики и телемеханики ПНИПУ.

Структуру нейронной сети ученые построили на базе персептрона – простой классической модели, которая состоит из одного скрытого слоя нейронов, в режиме реального времени обрабатывающих множество входных данных. Чем больше нейронов используется, тем больше времени уходит у измерителя на расчет выбросов газа. В ходе серии экспериментов ученые определили, что сеть из 3 нейронов позволяет проводить расчеты всего за 3,63 миллисекунды с достаточной точностью.

Уникальность разработки ученых – в ее адаптивности. Двигатель самолета работает в разных режимах: взлет, набор высоты, посадка, руление. Каждый из них имеет свои особенности и характеристики горения. Эксперты обучили нейросеть отдельно для каждого режима. Введение механизма подстройки весовых коэффициентов в адаптивной модели с учетом режима работы двигателя позволило более достоверно выдавать информацию о содержании эмиссии (выделения) оксидов азота. Внедрение такого блока адаптации на 82,8% повышает точность измерений по сравнению с системой, где использован неадаптивный измеритель.

Таким образом, разработанный виртуальный измеритель — это не отдельный физический датчик, а программный алгоритм, встраиваемый в систему управления авиационным двигателем. Во время полета в режиме реального времени он получает и обрабатывает данные о расходах топлива, давлении и температуре в камере сгорания. На их основе быстро (3,63 миллисекунды) рассчитывает концентрацию оксидов азота. Благодаря этой информации система управления может корректировать параметры работы двигателя и тем самым повлиять на снижение выбросов без ущерба для тяги и экономичности.

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