Никита Арипов | 1С, DevExp

Поддержка типовых конфигураций 7.7 прекратится с 2027 года

Фирма "1С" доводит до сведения пользователей типовых конфигураций "1С:Предприятия 7.7" о том, что с 01.01.2027 прекращается выпуск обновлений и поддержка на линии консультаций программных продуктов системы "1С:Предприятие 7.7" для РФ. Обращаем внимание, что в соответствии с информационным письмом № 32303 от 25.10.2024 с 2026 года в типовых конфигурациях "1С:Предприятия 7.7" прекращено обновление форм регламентированной отчетности.

Подробнее в информационном письме №34620 от 03.07.2026

Почти все инструменты, которые сегодня подключают ИИ к 1С, идут по одному пути. Они анализируют исходный код. Читают .bsl и .mdo, разбирают XML, строят собственные индексы, пытаются восстановить типы и связи между объектами.

Но есть реализация, которая задает совсем другой вопрос. А зачем вообще анализировать исходники, если рядом уже есть тот, кто все это сделал? Наша IDE.

Среда разработки уже построила модель проекта. Она знает типы выражений, связи между объектами, результаты проверок, умеет выполнять рефакторинги и гарантирует корректность изменений. Самая сложная работа уже выполнена.

Остается не повторять ее заново, а получить доступ к этой модели.
Именно эту идею реализует плагин для EDT EDT-MCP (или вот тут легче версия с тем же подходом - edt-bridge). Он публикует модель IDE наружу по протоколу MCP.

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

Интересно именно это смещение взгляда. Вместо того чтобы учить ИИ понимать проект с нуля, можно использовать знания, которые IDE уже накопила. Выглядит многообещающе!

Шпаргалка по современным терминам ИИ

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

Базовые понятия
1. LLM - большая языковая модель. Генерирует ответы на запросы пользователя
2. Prompt (промпт) - запрос, который отправляется модели. Определяет, какой ответ получит пользователь
3. System Prompt (системный промпт) - набор правил и роль модели, заданные на весь диалог. Определяет поведение модели независимо от конкретных запросов пользователя
4. Token (токен) - единица текста, по которой измеряются объем и стоимость работы модели. Используется для расчета лимитов и стоимости
5. Context Window (контекстное окно) - максимальный объем контекста, который модель может учитывать одновременно. Позволяет работать с длинными документами и историей переписки
6. Temperature (температура) - параметр, влияющий на вариативность ответов. Позволяет сделать модель более точной или более творческой
7. Hallucination (галлюцинация) - уверенный, но фактически неверный ответ модели. Одна из главных причин проверять важные ответы перед использованием
8. RAG - поиск информации перед генерацией ответа с последующим добавлением ее в промпт. Позволяет использовать актуальные документы и внутренние базы знаний
9. MCP (Model Context Protocol) - стандарт подключения внешних инструментов и источников данных к модели. Позволяет использовать один интерфейс для интеграции различных сервисов
10. Agent (агент) - система, которая самостоятельно планирует решение задачи и использует инструменты. Автоматизирует выполнение сложных сценариев

Часто встречаются
11. Tool Calling (вызов инструментов) - возможность модели вызывать внешние функции и сервисы. Позволяет работать с API, файлами и другими системами
12. Skills (скиллы) - готовые инструкции и материалы для агента, например гайд по созданию таблиц или шаблон отчета. Агент подгружает их под конкретную задачу вместо того чтобы каждый раз объяснять контекст заново
13. Few-shot / Zero-shot prompting (промптинг с примерами и без примеров) - передача примеров желаемого ответа в промпте против просто инструкции без примеров. Влияет на качество и предсказуемость ответа
14. Structured Output (структурированный вывод) - ответ модели в строго заданном формате, например JSON. Упрощает интеграцию с другими системами
15. Embeddings (эмбеддинги) - векторное представление текста для поиска по смыслу. Используются для семантического поиска
16. Vector Database (векторная база данных) - база данных для хранения embeddings. Позволяет быстро находить похожие документы
17. Workflow (воркфлоу) - заранее определенная последовательность действий. Используется для автоматизации повторяющихся процессов
18. Short-term Memory (краткосрочная память) - память текущего диалога. Позволяет модели помнить предыдущие сообщения
19. Long-term Memory (долгосрочная память) - память, сохраняющая информацию между сессиями. Позволяет учитывать прошлые взаимодействия с пользователем
20. Guardrails (гардрейлы) - ограничения и проверки, обеспечивающие безопасную работу модели. Помогают избежать нежелательных ответов и действий

Для разработки AI-приложений
21. Chunking (чанкинг) - разбиение документов на небольшие части. Повышает качество поиска и работы RAG
22. Reranking (реранкинг) - повторная сортировка найденных документов по релевантности. Помогает выбрать наиболее полезные результаты
23. Context Engineering (инженерия контекста) - подход к осознанному формированию того, что попадает в контекст модели на каждом шаге. Расширение prompt engineering для агентных систем с длинными сценариями
24. Planning (планирование) - построение плана выполнения задачи. Позволяет разбивать сложные задачи на этапы
25. Reflection (рефлексия) - самопроверка и корректировка собственного ответа. Помогает уменьшить количество ошибок
26. Multi-Agent (мультиагентность) - совместная работа нескольких специализированных агентов. Позволяет распределять обязанности между агентами
27. Subagents (субагенты) - узкоспециализированные агенты внутри одного оркестратора. Решают отдельную часть задачи и возвращают результат основному агенту
28. Orchestration (оркестрация) - управление всеми этапами работы AI-приложения. Координирует взаимодействие модели, инструментов и памяти
29. Evaluation (оценка) - автоматическая оценка качества ответов. Позволяет отслеживать качество модели после изменений
30. Harness (харнесс) - обвязка вокруг модели для тестирования, логирования и трейсинга. Используется для запуска тестов, сбора метрик и сравнения результатов
31. Benchmark (бенчмарк) - набор тестов для сравнения моделей. Позволяет объективно оценить их качество
32. Observability (обсервабилити) - мониторинг работы системы: стоимость, токены, задержки, ошибки. Используется для контроля и диагностики AI-приложений
33. Sandbox (песочница) - изолированная среда для безопасного выполнения кода. Защищает основную систему при работе с потенциально опасными операциями

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

Продолжаю собирать статьи про ИИ и вот попалась интересная:

По прогнозу аналитической компании Gartner, к 2028 году стоимость разработки с использованием искусственного интеллекта превысит среднемировую зарплату разработчика (в расчётах Gartner около 2000 долларов в месяц). Причиной станет рост потребления токенов и переход поставщиков ИИ на модель оплаты по фактическому использованию.

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

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

Статья: Gartner Predicts AI Coding Costs Will Surpass Average Developer’s Salary by 2028 as Token Consumption Surges

Пока мой план оптимизации выглядит примерно так:
1. Не здороваемся
2. Не благодарим
3. Не используем как калькулятор
4. ...
5. Profit!

Ландшафт технологий - Яндекс.Метрика

Неделю назад опубликовал масштабный проект Ландшафт технологий.

Вот немного цифр.
Уникальных посетителей - 2404 человек, среднее время на сайте чуть меньше 3 минут.

Вид отображения Путь на втором месте (307 просмотров) - это прикольно. Есть идея сделать на базе этого roadmap для обучения 1С, но это уже другая большая история.

Инструментом очень доволен. Получилось круто и залипательно! И 533 вернувшихся посетителя это подтверждают.

Спасибо, что делитесь им!

Вопросы для подкаста про 1С:Бухгалтерию

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

Уже вышел выпуск про 1С:ERP - там Алексей Кислов, руководитель подразделения развития практики ERP в фирме "1C", рассказал про историю продукта и планы на будущее

Теперь на очереди 1С:Бухгалтерия

Что хотите узнать? Пишите вопросы в комментарии - лучшие попадут в эфир

Ландшафт технологий 1С

Вокруг 1С давно выросла целая вселенная: EDT и git, Vanessa и YAxUnit, SonarQube и BSL LS, мониторинг, CI/CD, брокеры, BI… Уследить за всем нереально - а понять, что нужно именно тебе и с чего начать, еще сложнее

Собрал все это в одну интерактивную карту
landscape1c.ru

Выбираешь, кто ты и где работаешь - и сразу видишь свой стек, без лишнего

Что внутри:
• 206 инструментов в 24 категориях: описание, зачем нужен, с чего начать
• фильтры по зрелости, лицензии, происхождению и доступности
• путь освоения по ролям - от базового к продвинутому
• схема-постер всего ландшафта с экспортом в SVG/PNG/PDF - распечатай и повесь в офисе
• граф связей - аналоги и зависимости между инструментами

Разметку выверяю не один.
За осями стоит экспертный совет - практики из своих областей:
• Матвей Серегин — разработка
• Игорь Апресов — разработка
• Евгений Акпаев — администрирование
• Дмитрий Абрамов — инфраструктура
• Татьяна Головкина — тестирование
• Александр Кунташов — тестирование
• Роман Данилов — аналитика
• Мария Серегина — аналитика

Проект бесплатный, методология открыта, код на GitHub. Любой инструмент можно предложить или поправить

Заходи, найди свой стек и расскажи, чего не хватает

landscape1c.ru

Буду благодарен за репост - так карту увидит больше коллег

Тренажер: Код-ревью 1С

Подготовил редизайн приложения - https://codereview1c.ru

Новое в версии:
1. Новый дизайн и цветовая схема
2. Оптимизирован показ бейджей и статистики
3. Переработана таблица лидеров (аватарки, больше данных)
4. Добавлена возможность загрузить аватарку
5. Переработан интерфейс для неавторизованного пользователя

Если при входе вы видите пустую таблицу лидеров, то нужно будет перевойти в профиль (нажать на свое имя - откроется форма - под именем будет гиперссылка Выйти. А затем на главной в правом верхнем углу Войти).

Попробуйте сами и покажите коллегам:
Тренажер: Код-ревью для 1С

Цугцванг, а не цейтнот

Цейтнот - это когда не хватает времени

Цугцванг - когда любой твой следующий ход делает ситуацию хуже

А есть те кто никогда не был и очень хочет побывать в Желтом Клубе в этот четверг в Москве?

м. Бауманская, в 19:00

Upd: Билеты розданы. Хорошего вечера и до встречи в четверг!

Разработчики, ориентированные на продукт

Продолжаем читать Гергели Орош. На этот раз о хороших разработчиках, которые делают продукт для конечного пользователя. Чем они отличаются:

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

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

- Постоянно задают вопрос "почему?"
Почему именно эта фича? Почему сейчас, а не другая? При этом стараются делать это так, чтобы не раздражать. Для этого нужно выстраивать отношения с командой

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

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

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

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