Интересные мысли по работе с ЛЛМ здесь
Краткие выжимки:

1. Контекст — главный ресурс, не модель
Модель статична и без памяти, единственное, чем вы управляете, — какие токены попадают в окно контекста и в какой последовательности.
Плохие/лишние токены ухудшают траекторию диалога: если история диалога — «ошибся → ругань → снова ошибка», модель статистически продолжает этот паттерн.
Нужно оптимизировать контекст по четырём осям: корректность, полнота, размер и «траектория» (как развивается диалог).
Принцип для работы с LLM: думать не «какой промпт», а «какой набор и порядок фрагментов контекста я даю на этом шаге».

2. «Умная зона» и частая компакция
Большое окно контекста обманчиво: после ~40% заполнения качество часто падает — начинается «dumb zone».
Если пускать в окно всё подряд (логов, JSON, MCP-инструменты, длинные доки), вы почти постоянно работаете в «тупой зоне».
Решение — frequent intentional compaction: регулярно сжимать историю в краткий markdown‑конспект (файлы, строки, важные выводы) и начинать новый диалог уже с этим сжатием.
Принцип: на длинных задачах регулярно просить модель «суммировать и структурировать» достигнутое (код, гипотезы, решения) и работать дальше уже от этих сжатых артефактов, а не от бесконечной переписки.
...
4. Не аутсорсить мышление, а усиливать его
LLM не заменяет мышление, только усиливает уже проделанное или, симметрично, усиливает отсутствие мысли.
Ошибка на уровне research (неправильное понимание системы) масштабируется в сотни строк плохого кода; ошибка в плане даёт «сто плохих строк» одним махом.

Как бы всё это намекает на приоритет архитектуры перед кодингом.
Архитектуру мы как раз пытаемся зашить в СППР.

Мысль что входную информацию в ЛЛМ/контекст надо фильтровать/обрабатывать противоречит моим убеждениям
(считаю что обрабатывать не надо, потому как RAG/LLM сами по себе уже обработчики).

В этом ролике про модернизацию процесса проектирования на основе LLM то,
что мы делаем в СППР де-факто называют ADR (Architecture Decision Record).
ADR определяется как бы "атомарная" запись об архитектурном решении.
Но на самом деле ADR это комплекс, т.е.

ADR (Architecture Decision Record) — это короткая, формальная запись об одном важном архитектурном решении: какую опцию выбрали, в каком контексте, какие рассматривались альтернативы и почему именно это решение принято.

Типичная структура ADR:
контекст (ситуация, требования, ограничения);
решение (что именно делаем: паттерн, технология, способ интеграции);
альтернативы (какие варианты рассматривались и почему отклонены);
последствия (плюсы, минусы, риски, влияние на дальнейший дизайн и код).

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

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

Вот вам новый термин и идеология работы с СППР.
СППР = архитектурная память проекта

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

Ну, конечно, вывод через руку шлангом, кто на github ведёт качественное ADR - там либо динамят
это в принципе, либо весьма условно и непостоянно что-то формализуют.

Если бы ADR фиксировали в СППР жёстко и строго как один атомарный тезис требования
к атомарному решению (строка техпроекта), а потом скормили бы ЛЛМ,
то результат работы ЛЛМ был бы качественнее в разы.

Опыт итшника, которого бросили на утопающий в анархии бизнес-проект
(1500+ бизнес-процессов и срок месяц)
и где он описывает как он, нетипично для проектного управления, обошёлся без похода аналитиков в народ с опросами.

Схематично его подход выглядит как
- из головы (прошлого опыта) и кусков имеющейся информации составить метамодель архитектуры
- взять наработки по процессам из TОGAF, SAP, отраслевых решений (видимо, взял списки бизнес-процессов высокого уровня, которые в любом бизнесе одинаковые)
- покрутил всё это на ML-моделях и RAG. (как понял его - промэппил описание as is на to be, результат автора самого не на 100% устроил, но допилил напильником)
- инструментарий: git+plantUML + скриптики

Что считает получил в результате - ИТ управляемое через архитектуру
Т.е. сделал верхнеуровневое стратегическое описание и под него подгибать будет реализацию в натуре.

Что получил по его словам как выводы

Практически не было сопротивления за счет моментальных эффектов и появления экспертизы

Значимых «Поворотов ни туда» не было. Не было глобальных переработок модели

Чем больше паттернов знаешь - тем легче справиться с ситуацией.

Чем больше ответственности - тем качественнее результат.

В копилку знаний:
есть на kinescope видео от Виталия Тупицына

Опыт применения 1C СППР для формирования документа. Описание проектного решения (ЧТЗ)

Виталий - участник нашего чата, у него можно попросить ссылку или материал или рассказ здесь.

Рекомендую статью про MCP 1C RAG Server
Самое интересное в комментах от ondysss (Алексей Орлик)
Он является автором конкурирующей разработки,
его комментарии очень по делу, а детальные ответы автора помогают прояснить собственное понимание своих подходов к RAG/MCP
Автор озвучивает свою разработку как умеющую работать с кодом, метаданными конфигурации
как с текстом с учетом зависимостей и связей и с быстрым инкрементальным обновлением векторной БД RAG после обновления конфигурации.
ondysss, как разраб решения основанного на EDT, де-факто, утверждает что RAG при работе с EDT лишняя конструкция.
EDT, мол, умеет в базе и знает полный индекс и граф зависимостей и много прочего про МД.
А вы за какой подход?

Через пару-тройку дней ждём инфу в этом канале
о новой ступени развития СППР.

С помощью СППР в Дизайнере процессы можно декомпозировать до объектов метаданных.
Есть тепловая (цветовая) карта покрытия бизнес-процессов функциональностью используемых конфигураций.
В СППР появится интеграционная матрица в виде шахматки между конфигурациями.
Клик по ячейке переводит к карточке описания интеграции (тут совсем немного осталось - привинтить Конвертацию данных, да?).
Есть оценка вариантов архитектуры приложений (типа сравнить перед выбором на ERP или ERPУХ будем работать).
Есть запись и контроль архитектурных решений (ADR).
Обещается включение ИИ для работы с требованиями и увязки с бизнес-процессами.
Лидер проекта (владелец продукта) Станислав Султанов есть в нашем чате, можете задать ему вопросы или дать предложения и идеи/потребности.
Весьма мощный движ получился, как по вашему?

Участникам чата СППР включена новая функция Телеграм - изменение своего тега у имени.

Статья со ссылкой на книгу Дэвида А. Марка и Клемента МакГоуэн


«Технология структурного анализа и проектирования – SADT»
СППР основана на базисе SADT.
SADT - методологическая основа для графического отражения систем через IDEF0 (функциональное описание)
и IDEF3 (процессное описание) и IDEF1X (информационное описание).
В СППР реализована только идеология и графика IDEF0.
Книга и статья, как очень краткий дайджест книги, помогут осознать
и выстроить собственные подходы к работе с СППР.
Автор статьи сделал два очень интересных наблюдения - вывода:
Таким образом, можно научиться с помощью SADT, получать ответы
на все актуальные для каждой конкретной организации профессиональные вопросы.


(типа, аналитик, используй SADT и ничего не проспишь)




«М моделирует А, если М отвечает на вопросы относительно А»


(последнее к нашему недавнему обсуждению что такое Модель и Архитектура и есть ли между ними различие.
как видите - модель это что упрощенно описывает отражаемую Систему, но позволяет используя её понимать Систему.
Архитектура получается это то что описывает Систему рамочно перед её построением или построением модели)

Статья
Создаём пользовательскую инструкцию для 1С быстро и без боли
от Султанова.
в первом же комментарии от автора говорится про превращение в функциональную модель в СППР (????)

Статья сразу же вызывает вопросы:
1. А чего самый важный пункт 5 не поручить бы ИИ
2. Бесплатные ИИ столько файлов зараз не прожуют - лимиты-сс

А вот то что описано в этой статье
не является ли уже устаревшим подходом?
Архитектура как код, Документы как код, Требования как код...
В статье предложено всё это в виде текстовых массивов хранить в github как версии,
как основу для построения задач на проектах.
А по сути то предложено вести текстовую "RAG" базу.
Если хранить тексты, то уж лучше в векторной базе в формате ИИ сразу.
Что из этого не было бы возможным хранить в СППР?
Фактически предложено вместо сппр использовать гит.
Такая вот идея.

Давайте попробуем спроектировать реальное проектное решение?
Вот статья с исходными данными.
Какое бы решение предложили вы?
Стали бы вы (и каким образом) отражать такой проект в СППР,
если бы стало понятным, что проект займёт не менее чем 3 месяца?

Идея: GraphRAG для построения AST-дерева из кода 1С
и фиксация его (дерева) в СППР для подачи в дальнейшем как условия исполнения промптов
Кто изучал тему?
Ваши мнения или опыт использования?

Создана интеграция BPMN 2.0 и 1С
Теперь полноценный редактор BPMN внутри 1С.
Интеграция двусторонняя между 1С и онлайн сервисом bpmn.io
Среди форматов svg, xml, html с автоматическим сохранением
Качаем пробуем и говорим спасибо Станиславу Султанову и ИИ (надо же! от Сбера!)
:)

Здесь про использование СППР на проектах по ЗУП
Но тут стандартно как руководству по СППР и только для тестирования на Ванессе.
СППР выбрали из-за наличия связки Процессы (шаги) - Функциональное описание - тестирование.

Попробовал вот этот ИИ для аналитиков 1С
Задал вопрос такого типа:
"В 1С ERP в 1 квартале 2026 года в функции "закрытие периода" появилась новая
подфункция ручного распределения. Объясни порядок работы с ней и в чем отличие от релиза предыдущего периода"
Я зевнул момент когда в ЕРП эту фичу объявляли и её смысл мне напрочь непонятен.
В результате я вместо автоматического закрытия периода вынужден был вручную делать распределения.
Хорошо статей чуть. А было бы сотни две?

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

Тем не менее, авторы разработки идут в ОЧЕНЬ правильном направлении.
Именно так должен выглядеть инструмент для консультантов, аналитиков и пользователей
- в простом окне задаёшь вопрос и получает свод из нескольких источников.
Конечно, над полезностью ответов для пользователей там ещё работать и работать.
Как я понял, создана база методических ресурсов под отдельные конфигурации 1С,
плюс ещё есть галка включения добора информации в интернет.

PS Хотелось бы попросить авторов разработки включить в систему конфигурацию СППР,
чтобы можно было задавать вопросы и по ней.
Материалы для неё можно набрать и с этого канала/чата.

PPS Можно регистрацию сделать не на корпоративную почту?
Больше народа придёт тестировать вашу разработку.

PPS Было бы здорово, если бы кто-то поделился зачем в ЕРП добавили странную
функцию дополнительного распределения. Кто сумел с ней справиться и как.

Заново на новом боте реализован мост
между Телеграм и МАХ в чатах СППР.
Адрес чата в МАХ....... а бог его знает, даже не найдёшь
можно лишь по пригласительной ссылке для участников

Теперь без разницы где писать сообщения в ТГ или МАХе
они ходят туда-сюда