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

Для работы аналитика точнее подходит термин вайб-спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.

Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.

В статье разберём, какие задачи можно делегировать такому помощнику и где его выводы всё равно должен проверять специалист.

Что можно поручить ИИ-агенту

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

В описываемом примере используется облачный режим «Эксперт по 1С» в MAKER-STUDIO. Он работает в браузере: для первичного анализа не нужно запускать конфигуратор, 1С:EDT или разворачивать отдельную инфраструктуру. На момент подготовки материала агент ориентируется в следующих типовых решениях:

•  1С:Документооборот;

•  1С:Бухгалтерия;

•  1С:Управление торговлей;

•  1С:Зарплата и управление персоналом;

•  1С:ERP;

•  1С:Цифровое животноводство;

•  1С:Управление нашей фирмой.

Это не означает, что его ответ можно сразу переносить в рабочее ТЗ. Версия конфигурации, расширения, настройки функциональных опций и данные конкретной информационной базы способны заметно изменить картину.

Как формулировать запросы

Запрос полезно строить не вокруг абстрактного «напиши ТЗ», а вокруг результата, который нужен на текущем этапе. Например:

1.  «Есть ли в типовой конфигурации учёт совмещения должностей и как он проводится?»

2.  «Опиши процесс приёма на работу: документы, кадровые регистры, роли и доступ к формам».

3.  «При проведении больничного нужно запрещать расчёт, если не указан стаж. Какие типовые объекты затрагивает изменение и куда корректнее встроиться?»

4.  «Составь чек-лист приёмки для отчёта по остаткам отпусков, включая негативные сценарии».

5.  «Подготовь разделы ТЗ: цель, as is, to be, объекты, права, исключения и критерии приёмки».

Хороший рабочий цикл выглядит так:

Аналитик задаёт бизнес-цель и ограничения → агент собирает факты по типовой конфигурации и предлагает каркас → аналитик проверяет сведения и адаптирует документ под процессы заказчика.

Пример 1. Найти объекты интеграции ERP с 1С:Документооборотом

Допустим, нужно выяснить, существует ли в ERP типовая интеграция с 1С:Документооборотом и какие объекты к ней относятся. Без помощника аналитику пришлось бы обратиться к разработчику либо самостоятельно изучать дерево метаданных.

Запрос агенту можно сформулировать так:

Есть ли модуль интеграции с 1С:Документооборотом в ERP? Если да, перечисли основные объекты подсистемы, их назначение, точки расширения и ограничения. Укажи версию конфигурации, на которой основан ответ.

Для ERP 2.5.27 агент выделил подсистему интеграции с редакциями 2 и 3 «1С:Документооборота» и разложил объекты по назначению:

•  план обмена и регламентное задание фонового обмена;

•  обработки настройки и администрирования;

•  общие модули базовой логики и отдельных редакций;

•  правила сопоставления объектов ERP и документооборота;

•  регистры очередей, истории отправки, статусов согласования и авторизации;

•  функциональные опции, команды интерфейса, роли и подписки на события.

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

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

Пример 2. Подготовить ТЗ с критериями приёмки

Второй сценарий — напоминания сотрудникам о незаполненных ежедневных отчётах в «1С:Документообороте». Напоминание должно приходить не всем, учитывать график работы и отсутствия, а изменение требуется реализовать через расширение.

В запросе стоит сразу назвать:

•  бизнес-цель;

•  версию конфигурации;

•  обязательные ограничения;

•  способ реализации;

•  ожидаемую структуру ответа.

Например:

Подготовь ТЗ для «1С:Документооборот 3.0.21». Нужно напоминать обязанным сотрудникам о незаполненном ежедневном отчёте за предыдущий рабочий день. Учти выходные, отпуска и другие отсутствия. Доработка — через расширение. Предложи архитектуру, состав объектов, риски, вопросы заказчику и критерии приёмки.

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

Отсюда появился рабочий вариант архитектуры:

1.  В расширении хранится список сотрудников, обязанных вести отчёт.

2.  Регламентное задание проверяет предыдущий рабочий день.

3.  Из выборки исключаются выходные и полнодневные отсутствия по согласованному правилу.

4.  Проверяется наличие проведённого ежедневного отчёта.

5.  Уведомление помещается в типовую очередь, чтобы использовать штатные каналы доставки.

6.  Для контролёра формируется список сотрудников со статусами «сдан», «не сдан» и «не требовался».

Критерии приёмки при этом получаются проверяемыми:

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

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

•  уведомление не отправляется за выходной или день полного отсутствия;

•  после проведения отчёта повторы прекращаются;

•  повторный запуск задания не создаёт дубли;

•  контролёр видит список несдавших за выбранный период;

•  при отключённом функционале ежедневных отчётов регламент ничего не делает;

•  расширение устанавливается без изменения основной конфигурации.

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

Пример 3. Построить карту процесса в УНФ

Третий тип задачи — описать сквозной процесс «заявка клиента → производство → отгрузка» в УНФ 3.0.13.

Базовая цепочка выглядит так: Заказ покупателя → Заказ на производство → Производство → Расходная накладная → Оплата покупателя. Если материалов не хватает, между заказом на производство и выпуском добавляются заказ поставщику и поступление. Если готовый товар уже есть на складе, производственный блок можно пропустить.

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

Дальше агент может разложить работу по документам:

1.  Заказ покупателя фиксирует заявку или подтверждённый заказ и связывает дальнейшие операции.

2.  Заказ на производство планирует выпуск и потребность в материалах.

3.  При нехватке материалов создаются Заказ поставщику и Приходная накладная.

4.  Документ Производство (СборкаЗапасов) отражает фактический выпуск и списание материалов.

5.  При необходимости продукция перемещается на склад отгрузки.

6.  Расходная накладная отражает отгрузку и закрывает заказ.

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

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

Где проходит граница доверия

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

Перед передачей результата разработчику или заказчику стоит проверить:

•  совпадает ли версия конфигурации;

•  действительно ли перечисленные объекты существуют и используются;

•  не изменены ли они расширениями и доработками;

•  какие функциональные опции включены;

•  что определяется метаданными, а что — данными конкретной базы;

•  отделены ли подтверждённые факты от предположений;

•  можно ли однозначно проверить критерии приёмки.

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

Что меняется в работе аналитика

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

Вайб-спекинг — это не способ получить готовое ТЗ одной командой. Это управляемый диалог, в котором аналитик остаётся автором решения, а ИИ ускоряет поиск, структурирование и оформление материала.

Источник и дополнительные скриншоты: оригинальная публикация на Инфостарте.